共计 820 个字符，预计需要花费 3 分钟才能阅读完成。
事件起因是这样的，新来的开发小弟在 controller 写了一个阻塞的申请，而且间接用了 while(true)，抛异样时外面的跳出条件永远不满足。(当然提交代码时被咱们发现了)
于是咱们就钻研起了他会怎么影响程序。
首先咱们的理论知识是，tomcat 在接管到申请时，会从线程池里拿一个闲暇线程去解决这个申请，所以死循环只限于以后线程，当再发动一个申请时，也会是新线程，所以申请会没响应，然而不会导致程序间接挂掉(tomcat 最大能匀出 200 个线程还 hold 住本人测试的大量申请)。
于是我关上两个浏览器 tab 页面同时发一样的申请时，查看控制台显示。
线程的确是不一样的，然而为啥申请时间差了 20 多秒？
一开始我认为理论知识出问题了，起初又想了一会儿，新开一个浏览器再来一次。
一个申请用 edge 发，一个申请用 chrome 发，这时两个申请工夫距离就是按回车的时间差了。
所以浏览器外部肯定有什么机制阻止了多个 tab 页面对同一个 url 发申请的状况(阻塞的)。
查了下材料，下面有解决方案。
1. 只有把浏览器的缓存禁用, 就会发现不存在串行化的问题
这时屡次申请是同时发动的,5s 后同时完结
2. 如果浏览器的缓存不禁用
浏览器是冀望雷同的 URL 服务器返回 304 的响应, 但惋惜的是第一次响应内容没有缓存, 因而每次申请都是串行, 执行程序是 5s+5s+5s
但如果浏览器发送了 cache 响应, 那么
第一次执行 5s, 之后均为缓存 那么执行程序是是 5s +0 +0
总结, 这个性能其实是给网页上的图片筹备的
下面的逻辑也有一些破绽，实际上应该是有个超时工夫，在超时工夫内，会阻塞，超过了超时工夫，才会发动新申请。
在 edge 下关上开发者页面，点设置
于是我试了下，关上 3 个 tab 并同时关上开发者页面，后端的确能够间接响应了。
所以这个景象的起因是浏览器会缓存大文件 / 图片，进步加载速度。
查到的材料原地址，看着也像是翻译的页面。
浏览器多 tab 关上同一 URL 串行化的问题 – 风雪之隅 (laruence.com)
