防止线程池OOM的关键是“有界、可退、可观、可控”：使用显式容量的ArrayBlockingQueue，配CallerRunsPolicy拒绝策略，配套监控与命名ThreadFactory，禁用Executors工厂方法。
防止线程池因任务提交过快导致队列堆积撑爆内存，关键不是“让队列装得更多”，而是让系统在压力到来时能及时感知、合理缓冲、主动反馈。核心思路是：有界、可退、可观、可控。
用有界队列明确容量边界
默认的 LinkedBlockingQueue 无参构造等价于容量为 Integer.MAX_VALUE，本质是“伪无界”，任务持续涌入就会把堆内存当缓存用，最终 OOM。必须显式选用有界队列：
- 优先选
ArrayBlockingQueue，构造时强制指定容量，例如new ArrayBlockingQueue(200) - 容量不能拍脑袋定：需交叉校准——一边按业务流量（QPS × 平均 RT × 安全系数 1.2～1.5）估算缓冲需求；另一边按单任务对象大小和可用堆内存反推上限，取两者中较小值
- 避免用
SynchronousQueue单独搭配高并发场景，它不缓存任务，会直接触发线程扩容，易引发线程数爆炸
配合理性的拒绝策略形成反压
拒绝策略不是补救措施，而是背压开关。它要让上游知道“我吃不下了”，而不是默默吞下再崩掉：
- 推荐
CallerRunsPolicy：队列满时由提交线程（如 Tomcat worker）同步执行任务，天然限流、不丢数据、便于定位瓶颈 - 禁用
DiscardPolicy（静默丢弃）和AbortPolicy（直接抛异常中断主链路），尤其在关键路径上 - 关键业务可自定义策略：记录任务 ID、大小、时间戳，写入日志或 Kafka，并返回“服务繁忙，请稍后重试”等友好降级响应
配套可观测与运行时加固
没有监控的线程池就像没有仪表盘的飞机。手动构造线程池后，才能拿到真实指标并闭环防控：
立即学习“Java免费学习笔记（深入）”；
- 定期采集
getQueue().size()，队列使用率持续 > 80% 就该告警 - 监控
getActiveCount()和 CPU 使用率，判断是线程打满还是资源瓶颈 - 用
Micrometer或Prometheus暴露指标，支持高峰自动调参（如临时提升corePoolSize） - 务必使用命名的
ThreadFactory（如"order-async-%d"），方便日志追踪和线程识别
禁用 Executors 工厂方法
Executors.newFixedThreadPool()、newCachedThreadPool() 等方法封装了不可见参数，无法获取底层 ThreadPoolExecutor 实例，也就无法监控、无法调整、无法诊断。所有生产环境线程池都应手写构造，确保每个参数清晰可控。
