生产环境线程池调优需按任务类型（CPU或IO密集型）动态设定corePoolSize、maximumPoolSize及keepAliveTime；队列必选有界ArrayBlockingQueue，拒绝策略应自定义告警而非默认AbortPolicy；上线前须压测验证线程数、GC日志与队列水位。
生产环境调优不是套公式，而是根据任务特性、硬件资源和流量模式做动态权衡。核心目标就一个：让线程数既不浪费资源，也不成为瓶颈。
先分清任务类型：CPU密集型还是IO密集型
这是所有参数计算的起点，错判类型，后续全错。
- CPU密集型（如加解密、图像处理、复杂计算）：线程太多反而引发频繁上下文切换，拖慢整体吞吐。推荐 corePoolSize = maximumPoolSize = CPU核心数（Runtime.getRuntime().availableProcessors()获取）；keepAliveTime 可设为0，因为不需要额外线程。
- IO密集型（如HTTP调用、数据库查询、文件读写）：线程大部分时间在等响应，可适当“超售”。常见经验是 corePoolSize ≈ 2 × CPU核心数，maximumPoolSize ≈ 4 × CPU核心数；keepAliveTime 设为30–60秒，便于低峰期回收冗余线程。
队列选有界，别碰无界LinkedBlockingQueue
无界队列（如new LinkedBlockingQueue()）是生产事故高发区——它会让maximumPoolSize失效，任务全堆进内存，最终OOM或Full GC风暴。
JavaStoryDevelop
下载
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
- 优先选ArrayBlockingQueue：容量固定，能及时触发拒绝策略，把压力暴露在前端而非JVM堆里。
- 容量设置建议：按平均QPS × 平均任务耗时 × 安全系数（1.5–2）粗略估算；例如QPS=100、平均耗时200ms，则队列大小建议设为30–40。
- 慎用SynchronousQueue：适用于任务提交频率稳定、希望“直传”给空闲线程的场景（如短平快IO任务），但要求maximumPoolSize必须足够大，否则极易触发拒绝。
拒绝策略要真实可用，别只用默认AbortPolicy
默认的AbortPolicy直接抛异常，在Web接口里等于把错误甩给上游，用户体验差且难监控。
立即学习“Java免费学习笔记（深入）”；
- CallerRunsPolicy：由提交线程自己执行任务。适合后台批处理类任务，能自然降级，避免雪崩，但会阻塞调用方线程。
- DiscardOldestPolicy：丢掉队列最老任务，腾出位置。适合消息类、日志类等允许少量丢失的场景。
- 更稳妥的做法是自定义拒绝策略，记录告警日志+打点监控，比如发企业微信/钉钉告警，让运维第一时间感知线程池已饱和。
上线前必须验证三件事
调优不是配置完就结束，得用真实数据验证：
- 压测时观察活跃线程数是否稳定在corePoolSize附近（说明没频繁扩容）；
- 检查GC日志，确认没有因队列堆积导致Old Gen持续增长；
- 监控workQueue.size()指标，长期高于队列容量70%，说明要么线程数不够，要么任务本身变慢，需排查下游依赖。
