Java自定义线程池防OOM的核心是控制资源边界、切断隐式引用、分层设防与持续可观测：显式使用有界队列（如ArrayBlockingQueue）、合理配置容量与拒绝策略、清理共享引用、约束JVM参数并监控线程池指标。
Java 自定义线程池防止内存溢出，核心是控制资源增长边界、切断隐式引用链、分层设防并持续可观测。不是靠“不创建线程”或“不加任务”，而是让系统在压力下可降级、可告警、不崩溃。
显式使用有界队列，限制待处理任务堆积
避免用 LinkedBlockingQueue 无参构造（默认容量 Integer.MAX_VALUE），改用 ArrayBlockingQueue 并明确指定容量：
- 容量值需结合单任务对象大小与可用堆内存估算。例如：堆上限 2GB，典型任务携带约 500KB 数据 → 安全队列容量建议 ≤ 2000
- 容量不能脱离线程池参数独立设置。若 corePoolSize=8、maxPoolSize=16，队列容量设为 1000 比设为 1 更合理——它决定了系统能容忍多少“等待中的负载”
- 通过配置中心或启动参数传入容量值，避免硬编码；禁止依赖经验值或测试环境随意拍定
搭配拒绝策略，主动应对过载而非被动抛异常
仅设队列容量不够，必须显式指定 RejectedExecutionHandler：
- CallerRunsPolicy：提交线程自己执行任务，天然限流，适合不允许丢任务且吞吐可控的场景
- DiscardOldestPolicy：丢弃队列最老任务，为新任务腾位置，适合时效敏感型任务（如实时行情更新）
- 自定义策略更实用：记录日志 + 上报监控 + 返回降级结果（如缓存旧值、空响应），避免上游因异常中断流程
- 切忌沿用默认 AbortPolicy，它直接抛 RejectedExecutionException，容易引发调用方未捕获异常而雪崩
切断共享引用，防止对象长期滞留堆中
很多 OOM 并非来自线程或队列本身，而是任务中无意持有的强引用：
立即学习“Java免费学习笔记（深入）”；
- 禁用静态集合（static List/Map）无限累积；若必须用，加容量上限 + 定时清理或 LRU 淘汰逻辑
- 事件监听器、回调容器等注册型结构，必须提供反注册方法，并在业务结束时显式调用
- 大对象（如 byte[]、图片缓冲区、XML Document）优先用局部变量；确需跨任务传递时，考虑 SoftReference 或 WeakReference
- 用 ThreadLocal 存储线程私有状态，但每次使用后务必调用 remove()，尤其在线程池复用场景下
分区域设防 + 运行时监控，把问题挡在爆发前
内存溢出可能发生在堆、元空间、栈等多个区域，需分别约束和观测：
- JVM 启动参数强制设定：-Xms2g -Xmx2g（避免动态扩容抖动）、-XX:MaxMetaspaceSize=256m（防类加载膨胀）、-Xss256k（高并发下调低单线程栈）
- 实时采集线程池指标：队列使用率（size / capacity）、活跃线程数、拒绝任务总数、已完成任务数
- 将队列水位 >80% 持续 1 分钟作为告警阈值；结合 GC 日志（jstat -gc）观察老年代增长趋势
- OOM 发生后立即用 jmap -histo:live 查对象分布，再用 MAT 分析 heap dump 定位泄漏根因（如某个静态 Map 持有上万未释放对象）
