线程池需按业务特征配置：cpu密集型设核心数+1，io密集型依w/c比估算；必用有界队列如arrayblockingqueue；拒绝策略首选callerrunspolicy实现反压；须自定义threadfactory并监控活跃线程、队列积压、拒绝任务量。
处理大规模并发任务，线程池不是“配个数就完事”的黑盒，关键在于参数与业务特征的匹配。盲目套用默认配置或Executors工厂方法，极易引发OOM、线程爆炸或响应延迟飙升。
按任务类型定核心线程数
CPU密集型任务（如图像压缩、实时计算）应避免过多线程争抢CPU，核心线程数建议设为 CPU核心数 + 1；IO密集型任务（如HTTP调用、数据库查询）因大量时间在等待，可设为 CPU核心数 × 2～4，具体倍数需结合平均IO等待时长与CPU耗时比估算。例如：若单任务平均耗时500ms，其中450ms在等网络响应，则W/C ≈ 9，理论线程数可接近核心数×10，但需配合队列与拒绝策略做压力验证。
必须用有界队列，禁用LinkedBlockingQueue无界构造
无界队列是高并发场景下最隐蔽的OOM诱因。即使maximumPoolSize设为100，只要用了new LinkedBlockingQueue()（默认容量Integer.MAX_VALUE），所有新任务都会排队，内存随请求量线性增长。推荐使用ArrayBlockingQueue并显式指定容量，例如1000或根据TPS×平均排队容忍时长预估；若追求低延迟且能控制提交速率，可选SynchronousQueue，它不缓存任务，直接触发扩容逻辑，倒逼系统暴露真实吞吐瓶颈。
拒绝策略优先选CallerRunsPolicy
当线程池和队列都满时，CallerRunsPolicy让提交任务的线程自己执行该任务，天然形成反压：上游调用方被阻塞，从而减缓请求流入速度。这比AbortPolicy（直接丢弃）、DiscardPolicy（静默丢失）更利于系统稳定。尤其在Web层接入线程池时，它能把压力传导回Nginx或网关限流层，避免后端雪崩。
务必自定义ThreadFactory并监控关键指标
用new DefaultThreadFactory()或自定义命名规则（如"order-processor-pool-%d"），方便日志追踪与JVM线程快照分析。生产环境必须监控三项指标：活跃线程数（是否长期逼近maximumPoolSize）、队列积压量（是否持续增长）、拒绝任务数（是否突增）。可用Micrometer对接Prometheus，设置告警阈值，例如队列使用率＞80%持续1分钟即触发预警。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
