线程池拒绝策略必须选用 CallerRunsPolicy 或自定义策略，配合有界队列（如 ArrayBlockingQueue）和显式构造的 ThreadPoolExecutor；禁用 Executors 工厂方法；需监控活跃线程数、队列积压量及拒绝次数；多业务应拆分独立线程池实现风险隔离。
线程池拒绝策略不是摆设，得选对并重写
默认的 AbortPolicy 遇到饱和直接抛 RejectedExecutionException，线上服务一压就崩。这不是“防耗尽”，是“等出事”。真要防控，至少得换成 CallerRunsPolicy（让调用线程自己执行任务，自然降速），或自定义策略——比如记录日志 + 降级返回默认值 + 触发告警。
常见错误：只改了拒绝策略，却没配合理的核心/最大线程数与队列容量，导致策略根本没机会触发。
-
CallerRunsPolicy适合任务可延迟、且调用方能承受阻塞的场景 - 自定义策略里别做耗时操作（如远程写日志），否则会卡住整个拒绝流程
- 所有策略都依赖
workQueue.offer()返回 false 才触发，所以队列类型必须是**有界队列**（如ArrayBlockingQueue），LinkedBlockingQueue默认无界，等于关掉了拒绝机制
别用 Executors 工厂方法创建线程池
Executors.newFixedThreadPool(10) 看似省事，但背后是 LinkedBlockingQueue（容量为 Integer.MAX_VALUE）。只要任务提交速度 > 消费速度，队列无限堆积，内存迟早 OOM，线程数却卡死在 10 —— 这不是资源耗尽？是伪装成稳定的资源泄漏。
正确做法：用 ThreadPoolExecutor 构造器，显式指定：
立即学习“Java免费学习笔记（深入）”；
- 核心线程数（
corePoolSize）和最大线程数（maximumPoolSize） - 有界队列（如
new ArrayBlockingQueue(100)） - 拒绝策略（见上一条）
- 线程工厂（加名称前缀，方便排查线程归属）
示例：
new ThreadPoolExecutor(4, 8, 60L, TimeUnit.SECONDS,
new ArrayBlockingQueue<>(200),
new NamedThreadFactory("order-processor"),
new CallerRunsPolicy());
监控线程池状态比调参更重要
再合理的初始配置也扛不住流量突变或下游变慢。不看指标，等于蒙眼开车。关键字段必须定期采集：
-
getActiveCount()：当前正在工作的线程数，持续接近maximumPoolSize是危险信号 -
getQueue().size()：队列积压量，非零且持续增长 = 消费跟不上 -
getCompletedTaskCount()与getTaskCount()的差值：反映积压总任务量 - 拒绝次数（需自定义策略中计数）：一旦非零，说明已进入防御状态
注意：getPoolSize() 返回的是当前存在的线程总数（含空闲），不是核心数；而 isTerminated() 只在 shutdown() 后全部结束才为 true，日常监控别误用。
线程池不能复用就别硬复用
一个线程池被多个业务模块共用，表面节省资源，实则互相干扰。A 模块突发任务打满队列，B 模块的紧急任务只能排队或被拒——这已经不是耗尽，是“跨业务污染”。
判断是否该拆分，看三点：
- 任务执行时间差异大（如 IO 密集型 vs CPU 密集型）
- 失败影响范围不同（支付任务失败不能拖垮日志上传）
- 流量模式不一致（定时任务凌晨批量跑，和用户请求实时响应混在一起）
拆分后各自独立配置、独立监控、独立熔断，才是真正的风险隔离。共享线程池省下的那点内存，远不如一次生产事故的代价。
