bug历程——记一次由chrome浏览器Stalled优化缓存导致的请求bug

故事的开始是这样的

在一个月黑风高的夜晚，秋名山小白依旧在写着bug，这次他想实现的是解决重复请求问题。其实这个问题解决方案很普通，小白准备使用AOP+Redis分布式锁。

一切都很愉快的进行着，问题是出现在测试阶段，(注：小白代码是对的)

问题呈现

小白理想得到的结果

然而现实是这样的

解决bug历程

这里很容易发现，理想得到的结果是当两个请求同时到达时，server只执行一个请求，然而这里两次都执行了。小白为了增加可视性，在controller里添加了十秒的延时，神奇的事情发生了，这两个请求一共执行了20s，先执行的请求执行结束，第二个请求才开始执行的。这让人就很蒙逼了。思想过于发散的小白，差点怀疑springboot的controller层是不是串行执行。还好这种思维没过几秒钟，小白就清醒过来了，这是不可能的。检查了一下自己的代码逻辑后，小白把问题定位到了浏览器上。接下来，小白就用了不同的浏览器进行结果验证，答案是理想结果，那么现在问题就锁定在了Chrome浏览器上。现在开始抓包分析：

顺势进行分析灰色部分是啥

这里有个Stalled时间，查阅资料得到是停滞的意思。同样抓包手法在别的浏览器上没有该Stalled时间，这里猜想是Chrome浏览器优化问题。这里，经过科学上网得到结论。

问题描述：https://stackoverflow.com/questions/27513994/chrome-stalls-when-making-multiple-requests-to-same-resource

这里一切就真相大白了，因为小白因为勉强自己能看懂，这里就不翻译了。自己意会吧。

强烈建议

血的教训告诉我们，测试接口不要懒，PostMan了解一哈

我要接着去写bug了，拜拜！