直接用Executors.newFixedThreadPool()易OOM，根本原因是默认Integer.MAX_VALUE的LinkedBlockingQueue导致任务堆积；应改用显式容量的ArrayBlockingQueue，配合理想容量估算、CallerRunsPolicy拒绝策略、线程数与队列匹配、命名线程工厂及实时监控。
直接用 Executors.newFixedThreadPool() 容易 OOM，根本原因不是线程开得多，而是它背后那个默认容量为 Integer.MAX_VALUE 的 LinkedBlockingQueue——任务持续提交，Runnable 对象（含请求体、DTO、数据库参数等）在堆里越堆越多，几百个就可能吃掉几百 MB，最终触发 OutOfMemoryError: Java heap space。要真正防住，得把队列“管住”、把拒绝“用活”。
用 ArrayBlockingQueue 替代无界队列，容量必须显式设小
无界队列不是“稳”，是把风险藏起来；有界队列才是把上限亮出来。关键不是容量越大越安全，而是容量可算、可控、可观测：
- 选
ArrayBlockingQueue，别用无参的LinkedBlockingQueue；构造时必须传具体数字，比如new ArrayBlockingQueue(256) - 容量值不能拍脑袋：按“峰值任务速率 × 最大容忍等待时间 ÷ 平均处理速率”估算。例如每秒进 100 个任务、单个耗时 100ms（即每秒处理 10 个）、允许最多等 3 秒，则理论积压上限是 300，加 20% 缓冲设为 360 较合理
- 避免设成 10000 或更大——这不是防 OOM，只是把 OOM 推后，等堆撑爆才暴露问题
拒绝策略不能只用默认，要能反压、能记录、能降级
队列满了怎么办？不是丢任务，也不是让调用线程卡死，而是把“满”变成一个可响应的信号：
-
CallerRunsPolicy是常用选择：队列满时由提交线程自己执行任务，天然实现反压，防止任务无节制涌入；但注意高并发下可能拖慢上游，需配合监控看响应延迟是否飙升 - 禁用
AbortPolicy（只抛异常），尤其在关键路径；推荐自定义策略，比如记录日志 + 上报指标 + 触发熔断（返回兜底响应或写本地文件） - 如果业务不允许丢失，可结合 Redis 做溢出兜底：内存队列满时自动把任务存到 Redis 列表，后续再捞回处理——既防 OOM，又保不丢
线程数和队列容量要匹配，命名线程工厂不可少
光有界队列还不够，参数之间得互相咬合，否则“有界”就形同虚设：
立即学习“Java免费学习笔记（深入）”；
- 核心线程数 = 最大线程数（如都设为 8），保持稳定调度能力；不要设成 1 和 Integer.MAX_VALUE 这种极端组合
- 队列容量要跟线程处理能力对齐：若线程池每秒最多处理 50 个任务，队列却设了 5000，那意味着系统能默默积压 100 秒的任务——这已经不是缓冲，是隐患
- 必须传命名的
ThreadFactory，例如用ThreadFactoryBuilder设为"notify-service-%d"，这样线程名清晰，出问题时日志、jstack、监控都能快速定位到具体业务线程池
运行时监控要跟上，拒绝就是告警信号
配置再好，没监控等于没配。队列满不是故障，而是系统压力的真实反馈：
- 把
queue.size()、queue.remainingCapacity()、拒绝次数作为核心指标上报 Prometheus 或类似系统 - 设置规则：队列使用率持续 >80% 超过 1 分钟，或每分钟拒绝超 10 次，就自动触发告警
- 在
offer()返回false时主动打日志、记指标、做降级，而不是静默忽略——这是把“拒绝”从错误变成运维依据的关键动作
