for循环嵌套带来的超长耗时

1.场景描述
我们在做增量库存同步的时候，有这样的逻辑：
(1).从库存系统拿到指定时间到当前时间期间库存变动的货品编码;
(2).从本系统的数据库和redis中拿到本店铺的货品编码[涉及到重复铺货]；
(3).取出两者的交集，就是本店铺中这段时间有库存变动的货品编码集合；
(4).用这个交集做入参查询对应的库存；
(5).将这个变动的库存送到淘宝平台；

2.故障现象
如果我们设定的时间距离当前时间比较长，那么运行几乎是假死，其实是运算时间特别长，7万多的商品数据，运行了3天。
这个时间距离长，那么这个时间范围内库存变动的商品量就大，但是也不至于这么长时间。

可以看出，运行时间特别长，需要找出原因。

3.问题分析
这个问题，时间短、数据量小就看不出问题；时间长、数据量大就暴露问题，表面上好像代码逻辑是对的。
最后通过加各种日志到生产环境排查的。

我们可以看到各个地方的数据量有多大，并且每个小步骤运行的时间有多长，问题代码如下：

根据日志可以看出这个数据量：tbSkuList 的量到了64797，chainStoreList 数据量64144，tempModifiedList 数据量64797.
这种for循环嵌套，导致的结果是6万与6万的循环运算，达到上亿次，中途并没有break；

4.解决方案
for循环嵌套需要进行改造，首先想到的是，加上break，减少循环次数，实际上，这样做，只能缩短一半的时间，是二分查找的结果；
对于超大循环，最好不要嵌套循环。
所以，将内部的for循环的数据结构改为 key-value 形式，用 map.get(key)，这样的效率就高很多了。
将亿级别的运算降低到万级别。

5.优化建议
大数据量不要做嵌套循环，即使加入了break，还不是好的解决方案。改造为 key-value 数据结构，这样取值就非常快了。