避免线程池任务积压需动态匹配提交与执行速度，关键在于采用有界队列（如ArrayBlockingQueue）、按任务类型合理设置线程数、启用CallerRunsPolicy拒绝策略，并实时监控queueSize和activeThreads指标。
避免线程池任务积压，关键不是堆更多线程，而是让“提交速度”和“执行速度”动态匹配。积压本质是生产快于消费，解决它需要从队列控制、线程弹性、拒绝策略和可观测性四方面协同发力。
用有界队列掐住积压源头
无界队列（如默认的 LinkedBlockingQueue()）是积压的温床——任务会无声无息地堆积在内存里，直到触发 OOM。必须改用容量明确的有界队列：
- 优先选
ArrayBlockingQueue，显式指定容量（例如new ArrayBlockingQueue(256)） - 容量要与线程数匹配：若核心线程为 8，队列设 256，意味着系统最多缓冲 256 个待执行任务，超出即触发拒绝策略，不隐忍、不拖延
- 避免设成 10000 或 Integer.MAX_VALUE——这不是扩容，是把崩溃延后
按任务类型配准线程数量
线程数不是越多越好，错配反而加剧积压：
-
IO 密集型任务（调外部 API、查库、发消息）：线程常等待，可设为
CPU 核心数 × 2～5；例如 8 核服务器，corePoolSize 设 16，maximumPoolSize 设 40 -
CPU 密集型任务（图像处理、加解密）：线程几乎不等待，设为
CPU 核心数 + 1即可，避免上下文切换开销 - 不要用
Executors.newFixedThreadPool()等工厂方法——它们默认用无界队列或无限线程，生产环境必须手动构造
用 CallerRunsPolicy 实现自然背压
拒绝策略不是兜底摆设，而是反压的关键开关：
立即学习“Java免费学习笔记（深入）”；
- 别用默认
AbortPolicy（直接抛异常），尤其在关键业务路径上 - 推荐
CallerRunsPolicy：当队列满、线程已达上限时，由提交任务的线程自己执行该任务——这会让上游调用方变慢，天然降低提交速率，形成闭环调节 - 如需记录或降级，可自定义拒绝策略，在日志中打标 + 走异步补偿或返回默认值
监控 queueSize 和 activeThreads 才算真正可控
不监控的线程池等于盲开——积压发生时，指标比日志更早预警：
- 重点关注两个实时指标：
getQueue().size()（当前排队数）、getActiveCount()（正在干活的线程数） - 设置告警阈值：队列使用率 > 80% 持续 2 分钟，或拒绝率 > 0.5% 持续 1 分钟，立刻触发告警
- 注意：SynchronousQueue 的 queueSize 恒为 0，不能用来判断积压；此时应盯紧拒绝异常频率和响应延迟
