线程池满载时任务丢弃需先确认是否真满，应监控队列大小和活跃线程数；默认linkedblockingqueue无界时“满”实为内存耗尽；四种拒绝策略行为迥异，选错会掩盖瓶颈；自定义策略须轻量、异步、避免阻塞；源头控流（如限速、拆分任务、优化外部依赖）比依赖拒绝策略更关键。
线程池满载时任务直接丢弃？先确认是不是真满了
很多问题其实不是线程池“满”，而是任务提交速度远超处理能力，或队列堆积严重导致响应延迟。用 ThreadPoolExecutor.getQueue().size() 和 getActiveCount() 实时观察，比盲目调大核心线程数更有效。尤其注意：如果用了 LinkedBlockingQueue 且没设容量上限（即默认 Integer.MAX_VALUE），那“满载”往往发生在内存耗尽或 GC 频繁时，而非拒绝策略触发点。
四种内置拒绝策略的实际表现差异
Java 的 RejectedExecutionHandler 四种实现行为完全不同，选错会掩盖真实瓶颈：
-
AbortPolicy（默认）：抛RejectedExecutionException，适合监控告警场景，但若上游无 try-catch，会导致调用方线程中断 -
CallerRunsPolicy：由提交任务的线程自己执行该任务，能自然降速，但可能拖慢业务线程、引发响应时间毛刺 -
DiscardPolicy：静默丢弃，适合日志采集等可丢失场景，但完全无反馈，难定位丢失点 -
DiscardOldestPolicy：丢掉队列头任务（最老的），再尝试提交当前任务；对有严格时效性的任务（如实时计算）可能误伤关键数据
自定义拒绝策略怎么写才不踩坑
常见错误是把日志、告警、重试全塞进拒绝逻辑里——这会让线程池的拒绝路径变慢，反而加剧堵塞。正确做法是只做轻量动作：
- 记录关键字段：
task.toString()、当前队列大小、executor.getPoolSize() - 触发异步告警（如发消息到 Kafka 或调用 Prometheus pushgateway），绝不阻塞
- 避免在拒绝逻辑里调用
executor.submit()或操作共享集合，易引发死锁或并发异常 - 示例片段：
public class LoggingRejectHandler implements RejectedExecutionHandler { public void rejectedExecution(Runnable r, ThreadPoolExecutor executor) { log.warn("Task rejected: {}, queueSize={}, poolSize={}", r, executor.getQueue().size(), executor.getPoolSize()); alertAsync("thread_pool_rejected", Map.of("queue", executor.getQueue().size())); } }
比换策略更关键的是源头控流
拒绝策略只是兜底，真正可持续的方案得从提交端入手：
立即学习“Java免费学习笔记（深入）”；
- 用
Semaphore或RateLimiter在入口限速，比靠线程池背压更可控 - 异步任务考虑拆分：把“提交即执行”改成“提交→落库→定时扫描执行”，解耦生产与消费节奏
- 检查任务本身是否有外部依赖阻塞（如未设超时的 HTTP 调用、数据库长查询），这类任务哪怕在线程池里也会卡住线程
- 动态调整参数需谨慎：
setCorePoolSize()不会立即生效，且频繁变更可能引发线程震荡；优先通过allowCoreThreadTimeOut(true)让空闲核心线程也能回收
线程池不是越大越好，拒绝也不是失败信号——它是系统在告诉你：此刻的负载模式和当前资源配置不匹配。盯紧队列长度和任务平均耗时，比纠结用哪个策略更能解决问题。
