系统最大并发承受能力需匹配cpu、i/o、下游依赖三类硬约束：cpu密集型任务线程数宜设为核数+1并据cpu利用率微调；i/o密集型需按阻塞时长估算并发度但须受限于下游承载力；必须用有界队列与callerrunspolicy暴露瓶颈，并通过压测找资源劣化拐点。
评估系统最大并发承受能力，关键不是拍脑袋定数字，而是把线程池参数和真实资源瓶颈对齐。核心在于：线程数不是越多越好，也不是越少越稳，它得匹配 CPU、I/O、下游依赖这三类硬约束。
看 CPU 利用率反推线程上限
CPU 密集型任务（如加解密、图像处理）几乎不等待，线程一运行就占满核。此时线程数过多只会引发频繁上下文切换，CPU 负载飙升但吞吐不增。
- 观察生产环境 平均 CPU 使用率 和 系统负载（load average）：若 load average 持续 > CPU 核数 × 1.2，说明线程争抢严重，该减 maximumPoolSize
- 用 jstat -gc 或 arthas thread 查看线程状态，确认是否存在大量 runnable 但未被调度 的线程（即“就绪态排队”）
- 推荐起步值：corePoolSize = maximumPoolSize = Runtime.getRuntime().availableProcessors() + 1，再根据压测中 CPU 利用率是否稳定在 70%~85% 微调
按 I/O 等待时间估算可并行线程数
I/O 密集型任务（如 DB 查询、HTTP 调用）大部分时间在等响应，CPU 利用率低，可容纳更多线程。但线程数不能只看 CPU，更要卡住下游承载力。
- 统计单个任务的 平均阻塞时长（比如 DB 查询平均耗时 120ms，其中 CPU 计算仅 5ms），用公式粗估理论并发度：≈ CPU 核数 × (总耗时 ÷ CPU 耗时) → 例如 8 核 × (120 ÷ 5) = 192
- 但必须向下游验证：数据库连接池是否够？第三方接口限流是多少？若下游只能扛 50 并发，线程池设 200 就是自毁
- 实践中更稳妥的做法：从 corePoolSize = CPU × 2 起步，maximumPoolSize 设为下游允许并发的 1.2~1.5 倍，留缓冲不越界
用有界队列 + 拒绝策略暴露真实瓶颈
无界队列（如 LinkedBlockingQueue 默认构造）会掩盖压力，让任务悄悄堆积、吃光内存。真正衡量系统承受力，得让它“喊疼”。
- 强制使用 有界队列（如 ArrayBlockingQueue(200)），容量按预估峰值 TPS × 平均处理时间（秒）计算，宁小勿大
- 拒绝策略选 CallerRunsPolicy：当线程和队列都满时，由提交线程自己执行任务。这会让上游（如 Web 容器线程）变慢甚至超时，天然反压，帮你快速发现哪里扛不住
- 监控三项指标：活跃线程数（activeCount）、队列长度（queueSize）、被拒绝任务数（rejectedTasks）。若 rejectedTasks 持续增长，说明当前配置已达系统实际瓶颈，不是参数问题，是资源或架构要升级
结合压测数据动态校准
理论值只是起点，真实承载力必须靠压测验证。重点不是“打到多少 QPS 不挂”，而是看资源水位是否健康。
- 用 JMeter 或 wrk 模拟阶梯式流量（如每 30 秒 +100 TPS），同步采集：JVM 堆内存、GC 频次、线程池 activeCount/queueSize、下游响应 P95、服务器 load average
- 找到第一个出现明显劣化的拐点：比如 TPS 达 800 时，DB 响应 P95 从 80ms 暴涨到 400ms，或 load average 突破 20（16 核机器），这就是当前配置下的实际天花板
- 此时调整方向明确：若 CPU 还闲置，加大 maximumPoolSize；若 DB 成瓶颈，优化 SQL 或加缓存，而不是盲目扩线程
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
