Thread-per-request模型与并发上限

Servlet 容器（如 Tomcat）处理 HTTP 请求的默认方式是每个请求独占一个线程，直到返回响应为止；如果处理过程涉及 I/O（比如查数据库），这个线程会一直阻塞等着，这就是”同步阻塞”模型的由来。线程池里线程的数量因此直接划定了系统能同时处理多少请求的上限——线程都被占满时，新请求只能排队等，这也是排查性能问题时最先该看的地方。云原生场景下遇到这个上限，倾向于加实例做水平扩展而不是调大线程池数字，因为线程池调优没有万能公式，纯粹增加线程数在阻塞式模型下边际收益有限。发散：这个模型的本质缺陷是”线程在等 I/O 结果的时候被白白占着不能干别的事”，第8章要讲的响应式编程/事件循环模型正是冲着这一点去的——用少量线程处理海量并发连接，代价是编程模型变复杂。