线程池与连接池关系：线程模型影响连接管理
很多人在调并发参数时，会分开调线程池和连接池——调完线程数再调连接数，仿佛它们是两个独立的黑盒。但我想说，这种思路其实容易踩坑。线程池和连接池是共生关系，线程模型一旦变了，连接池的管理策略就得跟着改。
我过去在一个高并发 push 服务里，就吃过“线程池调大但连接池没跟上”的亏，结果 CPU 空闲但连接池排队严重。反过来也有线程池太小，连接池一堆空闲连接在那空转。今天我们就梳理一下它们之间的绑定关系。
1. 线程如何“绑定”连接
大部分 SDK 的典型流程是这样的：
- 请求进入，线程池分配一个工作线程。
- 工作线程从连接池借出一条连接。
- 使用连接完成收发数据。
- 工作线程将连接归还给连接池。
你发现没有？线程和连接的生命周期是 一一对应 的。一个线程在某一时刻只能持有 n 条连接（通常 n=1），而一条连接也同时只被一个线程使用。
核心关系：
最大并发连接数 = 工作线程数 × 每个线程持有的连接数（通常为1）
当然在一些异步框架里，单线程可以复用连接（比如 Netty 的 EventLoop），这时关系就变成多路复用。我们后面会单独对比。
2. 三种线程模型下的连接管理
我习惯按线程的“等待/回调”模式把常见模型分为三类：同步阻塞、同步非阻塞（轮询/多路复用）、异步回调。它们对连接池的诉求差异非常大。
| 线程模型 | 典型代表 | 连接获取方式 | 连接持有时间 | 连接池压力 |
|---|---|---|---|---|
| 同步阻塞 | Tomcat BIO、JDK 线程池 + 阻塞 IO | 线程阻塞等待连接 | 整个请求周期 | 高（连接数≈线程数） |
| 同步非阻塞（多路复用） | Tomcat NIO、Netty BossGroup | select/poll 后获取 | 数据读写完毕后归还 | 中（连接可以复用） |
| 异步回调 | Netty EventLoop、WebFlux | 回调中复用连接 | 极短，甚至多个请求共用一个连接 | 低（连接数远小于请求数） |
我曾经在一个 Tomcat BIO 配置里，直接套用 NIO 的连接池参数——线程池设了 200，连接池只给了 20。结果线上一压，20 个线程抢到连接，剩下 180 个线程全在等连接超时。说白了，同步阻塞下连接数和线程数应该等比例设置。
同步阻塞模型的调优经验
如果你还在用 Tomcat BIO 或者类似模式，记住一条公式：最大连接数 ≥ 最大线程数 × 平均每个请求需要的连接数。一般平均需求是 1，所以连接池大小可以略大于线程池大小（留一点缓冲）。比如线程池设 200，连接池设 220～250。
异步回调模型的调优经验
异步模型下，线程不再死等连接。比如 Netty 的 EventLoop，单线程可以管理上千条连接。这时候连接池反而变成“连接复用池”——只为了复用 TCP 握手成本。连接数通常设为 1～5 就够，剩下全靠多路复用。
我记得有一次帮一个 WebFlux 网关调优，连接池设为 4，线程池只有 CPU 核数 8，压测时连接池几乎不排队。换成同步模型，同样规模直接挂。
3. 线程池大小如何影响连接池的“空闲”与“爆满”
我们来拆个场景：假设线程池核心线程数 = 最大线程数 = 16，连接池最大连接数 = 32。
- 并发请求 ≤ 16：每个线程拿到一条连接，连接池还有 16 条空闲。没问题。
- 并发请求 20：线程池只能起 16 个线程，剩下 4 个请求丢到队列里等待。线程拿到连接后，连接池剩余 12 条空闲。但线程在排队等 CPU，连接其实在空转。
- 并发请求 40：线程池满，队列满，新请求被拒绝。但连接池只用了 16 条，剩下 16 条连接完全没用上。这就是线程池瓶颈导致的连接浪费。
反过来，如果线程池很大（比如 100），连接池很小（比如 10），那就会出现：10 个线程持有连接干活，剩下 90 个线程在连接池阻塞等待，线程池本身有大量线程处于 BLOCKED 状态，CPU 上下文切换爆炸。
我建议先确定线程池规模（通常 CPU 密集型设 N+1，IO 密集型设 2N 或更高），再让连接池大小 = 线程池最大大小 × 1.1～1.3，留一点余量应对突发。如果是异步模型，连接池直接缩小到个位数。
4. 一张图理解整体关系
下面这张 SVG 把线程池、连接池、工作任务之间的流转画了出来，你可以对照自己项目里的架构看看遗漏在哪。
5. 常见坑与补救方法
我曾经在调优一个支付 SDK 时，把连接池最大连接数设成了 1000，线程池最大线程数设成了 500。结果压测一运行，500 个线程同时从连接池里拿 500 条连接，剩下 500 条连接闲置。但更糟的是，这 500 条闲置连接一直在后台发送心跳保活，白白浪费了服务器资源。后来我把连接池降到了 600（比线程池多 20%），同时开启了连接池的空闲回收，问题才解决。
另一个常见坑是：线程池用了无界队列，导致线程数从不增长，所有请求全排队。连接池虽然空闲，但线程没机会去拿。结果就是 QPS 上不去，连接池空转。我的建议是：在 IO 密集型场景，一定要给线程池设一个有界队列，让新请求快速触发线程扩容，然后连接池才能被充分利用。
如果你用 async 模式（比如 CompletableFuture + 共享连接），可以尝试把连接池的 maxTotal 设小，比如 2 或 4，并配合 maxWaitMillis 设置成 -1（无限等待）。这样失败时不会爆连接超时，只是请求排队等待复用连接，吞吐反而更高。
6. 总结三条实用规律
- 先定线程模型，再定连接池大小。同步阻塞下连接数≈线程数，异步多路复用下连接数<<线程数。
- 线程池和连接池的瓶颈要对称。线程池满了就扩容线程或队列，同时调整连接池，否则总有一方在空转。
- 连接池的超时和线程池的超时要联动。如果线程等待连接超时设为 5s，连接池获取超时设为 3s，那线程池队列里的请求会因为连接超时而频繁失败，白白消耗资源。
嗯，这些规律说起来简单，但在实际项目中，很多人（包括早期的我）都是分开调两个池子的参数，结果反反复复测试都找不到最优值。你可千万别踩同一个坑。