推荐直接使用 ThreadPoolExecutor 构造函数创建线程池，因其可精细控制 corePoolSize、maximumPoolSize、workQueue 等7个参数，规避无界队列OOM和无限创建线程风险，并支持按CPU/IO密集型任务差异化配置、有界队列、自定义拒绝策略与命名线程工厂，实现可控、可观测、生产就绪的线程池。
直接用 ThreadPoolExecutor 构造函数创建线程池，而不是依赖 Executors 工厂方法，是生产环境最稳妥的起点。关键不在“会不会用”，而在参数是否贴合真实负载——CPU 密集型任务和 IO 密集型任务的配置逻辑完全不同，队列选错、拒绝策略默认、线程名模糊，都可能在线上压测或流量高峰时暴露为响应延迟、OOM 或排查困难。
明确 corePoolSize 和 maximumPoolSize 的业务依据
这两个数值不是拍脑袋定的，必须结合任务类型与系统资源判断：
- CPU 密集型（如图像压缩、数值计算）：核心线程数建议设为
Runtime.getRuntime().availableProcessors() + 1；最大线程数通常与核心一致，避免频繁上下文切换。此时线程几乎始终忙碌，扩线程反而降低吞吐。 - IO 密集型（如 HTTP 调用、数据库查询）：核心线程可设为 CPU 核心数，最大线程数常设为
2 × CPU 核心数或更高，需通过压测确定——因为线程大量时间在等待，适当扩容能提升 CPU 利用率。 - 混合型任务建议拆分：把纯计算和远程调用分离到不同线程池，避免慢 IO 拖垮整个池的响应能力。
工作队列必须是有界的，且容量要合理
无界队列（如 LinkedBlockingQueue 默认构造）是线上事故高发点。任务持续涌入时，队列无限堆积，最终耗尽堆内存。
- 优先选用
ArrayBlockingQueue，显式指定容量（例如 100 或 500），配合拒绝策略形成“背压”机制。 - 若任务到达速率极不均衡且允许短时丢弃，可用
SynchronousQueue——它不存任务，只做“交接”，迫使线程池立刻扩容或触发拒绝，适合对延迟敏感的场景。 - 避免使用
PriorityBlockingQueue除非真有优先级调度需求，它无界且排序开销大，容易掩盖容量问题。
拒绝策略不能用默认，要匹配业务语义
AbortPolicy（抛异常）是默认策略，但对多数 Web 接口并不友好——用户请求直接 500，体验差且无补偿手段。
立即学习“Java免费学习笔记（深入）”；
- 对关键任务（如支付回调、库存扣减），推荐
CallerRunsPolicy：由提交线程自己执行，相当于降级为同步处理，虽慢但不丢。 - 对日志采集、监控上报等弱一致性任务，可用
DiscardPolicy静默丢弃，或自定义策略将任务写入本地文件/消息队列，后续重试。 - 避免
DiscardOldestPolicy用于有状态任务——丢掉队列头的老任务，可能破坏业务顺序（如订单创建先于支付）。
线程工厂和生命周期管理不可省略
一个没命名的线程池，在日志里只会显示 pool-1-thread-1，出问题时根本无法定位是哪个模块、哪类任务出了问题。
- 务必通过
ThreadFactory设置有意义的前缀，例如"order-process-pool-" + counter.getAndIncrement()。 - 线程设为非守护线程（
setDaemon(false)），确保 JVM 退出前有机会完成清理。 - 应用关闭时调用
shutdown()，再配合awaitTermination()等待任务结束；紧急情况下才用shutdownNow()，但需注意中断可能未被任务正确响应。
