事件起因是这样的，新来的开发小弟在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)