生产环境必须显式构造threadpoolexecutor，禁用executors快捷方法；按任务类型隔离线程池，配置有界队列、合理核心/最大线程数、自定义拒绝策略与线程工厂，并暴露监控指标、规范生命周期管理。
直接用 Executors 工厂方法创建的线程池，大概率撑不住真实业务流量。真正稳健的线程池不是“能跑就行”，而是参数可解释、行为可预测、故障可兜底。
必须显式构造 ThreadPoolExecutor
禁用 newFixedThreadPool、newCachedThreadPool 等快捷方式——它们默认使用无界队列或无限线程数，线上极易触发 OOM 或雪崩。所有生产环境线程池都应通过 ThreadPoolExecutor 显式传参构建，确保每个参数都有明确业务依据：
- corePoolSize：按平均并发压力设，CPU 密集型 ≈ CPU 核数；IO 密集型可适度放大（如 ×1.5），但需压测验证，不盲目套公式
- maximumPoolSize：与队列类型强绑定；若用有界队列，它代表系统能承受的瞬时峰值线程上限
-
workQueue：优先选
ArrayBlockingQueue（指定容量），杜绝LinkedBlockingQueue默认无界风险 -
handler：拒绝策略禁用默认
AbortPolicy；推荐CallerRunsPolicy（自然降速）或自定义策略（记录日志 + 降级返回）
按任务类型严格隔离线程池
混用任务会相互干扰，比如慢 SQL 占满线程，导致健康检查超时或定时任务堆积。应按职责拆分：
- HTTP 请求、RPC 调用等短耗时任务 → 独立池，
keepAliveTime设为 60 秒，队列容量控制在 1024 以内 - 异步日志、消息投递等低优先级任务 → 单独池，允许稍高排队容忍度，但队列上限仍需硬限制（如 2048）
- 定时调度（如 Quartz）→ 专用池，线程数严格限定为 1～3，避免调度器自身被阻塞
- 阻塞 IO 操作（文件读写、同步 HTTP）→ 绝不允许放入计算型线程池；应改用 NIO 或移交至专用 IO 池
暴露监控指标并接入统一观测体系
线程池是黑盒，不监控等于裸奔。必须通过 JMX、Micrometer 或自定义埋点暴露关键指标：
- 活跃线程数（
getActiveCount）、队列积压任务数（getQueue().size()） - 已执行任务总数（
getCompletedTaskCount）、拒绝任务数（需自定义 handler 计数） - 核心/最大线程数配置值（便于核对是否生效）
- 建议对接 Prometheus + Grafana，设置告警阈值：队列积压 > 80% 容量、拒绝率 > 0.1% 触发预警
规范生命周期管理
线程池不是静态工具，启停必须受控：
- 应用启动时初始化，避免首次调用才创建带来延迟
- 优雅关闭用
shutdown()+awaitTermination()，确保队列中任务完成；紧急场景用shutdownNow()，但需处理中断逻辑 - 禁止在 Spring Bean 中仅靠
@PreDestroy关闭，应结合SmartLifecycle确保关闭时机可靠 - 线程工厂务必自定义，命名格式如
"biz-http-pool-%d"，便于日志和线程 dump 定位问题
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
