Spring Boot中@RestController并行处理行为随查询字符串变化的原因

你观察到的差异和Spring Boot控制器本身的处理逻辑无关，核心是请求进入应用之前的前置环节差异，常见原因有两类：

• 浏览器同源GET请求并发限制
  主流浏览器默认会对**完全相同的GET请求URL（路径+查询字符串完全一致）**做串行排队处理：相同GET请求被默认判定为可能存在可缓存响应，为避免重复请求浪费资源，浏览器会等待前一个同URL请求返回响应后，再发起第二个请求。如果查询字符串不同，浏览器会直接判定为不同请求，并行发起。
  验证方式：使用两个独立终端运行curl命令同时调用curl http://localhost:8080/test，日志会显示UUID交错输出，也就是控制器本身是支持并行处理的。
• Tomcat会话锁机制
  Tomcat默认对同一个JSESSIONID对应的会话请求加互斥锁，避免会话属性并发修改的线程安全问题。如果你的两个请求来自同一个会话（比如同一浏览器的两个标签页，共享JSESSIONID），就会触发串行逻辑。
  部分Tomcat版本会对不带查询参数的URL优先触发会话锁，带查询参数的动态请求会跳过会话锁判断，因此出现你观察到的行为差异。你可以通过配置关闭Tomcat会话锁验证：在项目的application.properties中添加配置：

  server.tomcat.session-lock-enabled=false
  

  重启后再调用不带参数的接口，即可看到并行处理的日志。

内容的提问来源于stack exchange，提问作者Daigo