连接池极限吞吐量指其在高并发下稳定支撑的最高TPS，需通过阶梯压测、禁用缓存、校准参数并结合DB侧监控确定，关键拐点为连接获取耗时＞50ms且等待线程数持续＞0。
直接测连接池的极限吞吐量，本质是测它在高并发请求下能稳定支撑多少 TPS（每秒事务数），同时不出现连接耗尽、超时或错误率飙升。关键不在“压到崩溃”，而在“找到稳态上限”。
明确测试边界和事务定义
连接池本身不处理业务逻辑，它的吞吐表现取决于你让它执行什么操作：
- 定义一个最小但真实的数据库事务：比如一次带主键查询 + 一次 UPDATE（避免只读缓存干扰）
- 确保该事务与生产一致：表结构、索引、数据量（建议用 100 万级真实数据量，而非空库）
- 禁用二级缓存（如 MyBatis 的 localCache、Hibernate 的 L2 cache），防止掩盖连接瓶颈
- 关闭连接池的自动重连或 failover 逻辑，聚焦纯连接调度能力
用 JMeter 模拟阶梯式并发压力
不要一次性拉满线程——那样只能测出“雪崩点”，不是可用极限：
- 使用 JMeter 的 Ultimate Thread Group 插件，设置阶梯加压：从 50 线程开始，每 2 分钟增加 50，直到 1000+
- 每个线程循环执行：获取连接 → 执行定义好的事务 → 归还连接（不 close）→ 休眠 100ms（模拟真实请求间隔）
- 监控项必须包含：连接获取平均耗时（connection acquisition time）、活跃连接数（active connections）、等待连接的线程数（threads awaiting connection）
- 当“连接获取耗时 > 50ms”且“等待线程数持续 > 0”时，说明连接池已成瓶颈，此时的 TPS 即为实际极限
校准连接池核心参数并观察拐点
别依赖默认值。针对你的应用并发模型，动态调整并对比：
立即学习“Java免费学习笔记（深入）”；
- maxOpen / maximumPoolSize：设为 50、100、200 三档分别压测，记录 TPS 增长是否饱和
- maxIdle / minimumIdle：调低（如设为 5）可暴露连接复用效率；调高（如 50）看是否缓解冷启动抖动
- connectionTimeout：设为 3000ms，一旦大量请求在此超时，说明池子太小或后端数据库响应变慢
- 重点观察指标曲线拐点：TPS 不再随并发线程数线性上升、错误率突增 0.5%、连接获取耗时跳升 3 倍——这三个信号任一出现即为极限
配合数据库侧交叉验证
连接池再快，也受限于数据库服务能力。需同步确认：
- MySQL 的 max_connections 必须 ≥ 连接池最大值 + 管理连接（建议预留 20% 余量）
- 监控 MySQL 的 Threads_connected 和 Threads_running，若前者接近上限而后者长期
- 检查 innodb_row_lock_time_avg 和 slow queries：若锁等待飙升或慢查增多，说明事务设计或索引有问题，不是连接池问题
- 用 show processlist 抓取压测中正在运行的连接状态，确认是否大量卡在 “Sending data” 或 “Locked”
