线程池参数需依业务场景定制：CPU密集型宜设corePoolSize为CPU核数+1，IO密集型可设2×CPU核数或20~50；maximumPoolSize为队列满时允许创建的最大线程数。
线程池参数配置没有统一标准，关键看业务场景——CPU密集型任务要控制并发数避免争抢，IO密集型则可适当放大线程数提升吞吐，同时必须防止资源耗尽和队列无限堆积。
核心参数含义与常见取值
corePoolSize：线程池常驻最小线程数。任务少时保持活跃，避免频繁创建销毁。CPU密集型建议设为 CPU核数 + 1；IO密集型可设为 2 × CPU核数 或更高（如20~50），具体需压测验证。
maximumPoolSize：线程池最大线程数。当队列满且当前线程数
keepAliveTime：空闲线程存活时间。仅对超出 corePoolSize 的线程生效。建议设为 60秒，太短易频繁启停，太长浪费资源。
立即学习“Java免费学习笔记（深入）”；
本书是全面讲述PHP与MySQL的经典之作，书中不但全面介绍了两种技术的核心特性，还讲解了如何高效地结合这两种技术构建健壮的数据驱动的应用程序。本书涵盖了两种技术新版本中出现的最新特性，书中大量实际的示例和深入的分析均来自于作者在这方面多年的专业经验，可用于解决开发者在实际中所面临的各种挑战。 本书内容全面深入，适合各层次PHP和MySQL开发人员阅读，既是优秀的学习教程，也可用作参考手册。
workQueue：任务等待队列。优先选有界队列（如ArrayBlockingQueue），容量建议设为预估峰值QPS × 平均处理耗时（单位秒）。避免用无界队列，否则OOM风险高。
threadFactory：用于自定义线程命名、是否守护线程等。建议设置有意义的线程名（如“order-processor-pool-%d”），便于问题排查。
handler：拒绝策略。生产环境慎用AbortPolicy（直接抛异常）。推荐使用：
- CallerRunsPolicy：由调用线程自己执行任务，可自然降速
- DiscardPolicy：静默丢弃，适合允许丢失的场景
- 自定义拒绝逻辑（如记录日志+告警+降级）
典型场景配置示例
高并发Web接口（如订单提交）：
corePoolSize=20，maximumPoolSize=50，keepAliveTime=60s，queue=new ArrayBlockingQueue(200)，handler=new CallerRunsPolicy()
CPU密集计算任务（如图像压缩）：
corePoolSize=4（4核机器），maximumPoolSize=4，keepAliveTime=60s，queue=new SynchronousQueue()，handler=new AbortPolicy()
后台异步通知（如发短信、邮件）：
corePoolSize=5，maximumPoolSize=10，keepAliveTime=300s，queue=new ArrayBlockingQueue(50)，handler=new DiscardPolicy()
配置不当的典型问题
• 队列过大+core小 → 大量任务积压，响应延迟飙升，监控看不出CPU高但RT暴涨
• maximumPoolSize远大于core，又配无界队列 → 线程数始终不超core，maximum形同虚设
• keepAliveTime设为0 → 新建线程后立刻回收，失去“缓冲弹性”作用
• 拒绝策略用默认AbortPolicy → 突发流量直接打崩上游，缺乏缓冲和降级能力
• 线程工厂未命名 → 日志中全是pool-1-thread-1，无法区分业务来源
配置后的必要动作
• 上线前用JMeter或wrk做阶梯压测，观察线程数、队列长度、GC、错误率变化
• 在应用中暴露ThreadPoolExecutor指标（如getActiveCount、getQueue().size()），接入Prometheus/Grafana
• 设置JVM参数-Xms=Xmx，避免堆内存动态扩容影响线程调度
• 关闭线程池时务必调用shutdown() + awaitTermination()，确保任务完成再退出
