核心是禁用无界队列，改用显式容量的arrayblockingqueue(500)或linkedblockingqueue(1000)，配callerrunspolicy拒绝策略，禁用executors工具类，全程手动构造threadpoolexecutor并监控关键指标。
Java线程池避免内存溢出，核心是用有界队列代替无界队列，并配合合理容量与拒绝策略。无界队列（如 LinkedBlockingQueue() 无参构造）默认容量为 Integer.MAX_VALUE，任务持续堆积会不断创建对象、占用堆内存，最终触发 OutOfMemoryError。这不是理论风险，而是生产环境高频事故原因。
明确指定有界队列类型和容量
必须显式使用带容量参数的有界队列，不能依赖默认行为：
- 首选
ArrayBlockingQueue：底层是数组，内存占用可控、性能稳定，例如new ArrayBlockingQueue(500) - 次选带容量的
LinkedBlockingQueue：如new LinkedBlockingQueue(1000)，注意它仍是链表结构，对象头开销略高 - 避免
SynchronousQueue单纯用于“无队列”场景——它不缓存任务，所有提交都依赖即时线程可用，不适合需要缓冲的业务
容量设置要结合实际资源估算
队列容量不是拍脑袋定的，需兼顾单任务内存开销与JVM堆上限：
- 假设单个任务对象平均占 2KB，堆内存设为
-Xmx4g，预留 70% 可用空间（约 2.8G），理论最大队列长度 ≈ 2.8 × 1024 × 1024 / 2048 ≈ 14336 —— 但实际应远低于该值 - 推荐起步值：4C8G 机器用 500～1000；8C16G 用 1000～2000；再通过压测观察 GC 频率与 Full GC 次数调整
- 切忌设过大（OOM风险）或过小（频繁触发拒绝，影响可用性）
搭配匹配业务的拒绝策略
有界队列满后必须有明确应对方式，不能让异常穿透到上层丢失上下文：
-
CallerRunsPolicy：由提交线程自己执行任务，天然限流，适合对延迟不敏感、能接受调用方阻塞的场景 -
DiscardPolicy或DiscardOldestPolicy：适合可丢弃的低优先级任务（如日志聚合） - 自定义策略：记录告警 + 落库/发消息重试，保障关键任务不丢失（例如订单异步通知）
配套必须做的几件事
光换队列不够，还需闭环保障：
- 禁用
Executors工具类（如newFixedThreadPool），它们内部全用无界队列，不符合生产要求 - 给线程池命名（如
new ThreadFactoryBuilder().setNameFormat("order-async-%d").build()），方便排查时识别线程归属 - 暴露核心指标：活跃线程数、队列剩余容量、拒绝任务数，接入 Prometheus + Grafana 实时监控
- 任务体内部确保资源释放（如关闭流、归还连接），防止因单任务泄漏引发连锁 OOM
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
