线程池参数需依业务场景定制：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秒，太短易频繁启停，太长浪费资源。
workQueue：任务等待队列。优先选有界队列（如ArrayBlockingQueue），容量建议设为预估峰值QPS × 平均处理耗时（单位秒）。避免用无界队列，否则OOM风险高。
threadFactory：用于自定义线程命名、是否守护线程等。建议设置有意义的线程名（如“order-processor-pool-%d”），便于问题排查。
handler：拒绝策略。生产环境慎用AbortPolicy（直接抛异常）。推荐使用：
- CallerRunsPolicy：由调用线程自己执行任务，可自然降速
- DiscardPolicy：静默丢弃，适合允许丢失的场景
- 自定义拒绝逻辑（如记录日志+告警+降级）
典型场景配置示例
高并发Web接口（如订单提交）：
corePoolSize=20，maximumPoolSize=50，keepAliveTime=6
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()，确保任务完成再退出
