线程池任务提交机制通过四层决策链实现压力过滤：核心线程执行→入队→扩容非核心线程→触发拒绝策略，每步配置不当均可能导致雪崩；队列类型决定背压能力，拒绝策略是系统自我保护信号，需按业务隔离线程池并监控指标。
线程池的任务提交机制直接决定系统在高并发下的行为边界，稍有不当就可能引发雪崩——不是任务执行慢，而是任务堆积、内存溢出或线程失控。
任务提交的四层决策链影响资源水位
每次 submit() 调用都会触发固定流程：先尝试用核心线程执行 → 核心满则入队 → 队列满再扩容非核心线程 → 扩容到顶仍无法接纳，就触发拒绝策略。这四步像一道“压力过滤阀”，每一步的配置都对应一个风险点：
- 核心线程数过小：大量任务被迫进队列，若队列又无界（如默认 LinkedBlockingQueue），任务持续堆积，最终耗尽堆内存
- 队列容量过大或无界：掩盖真实处理瓶颈，系统看似“还在运行”，实则响应延迟飙升、GC 频繁，监控指标失真
- maximumPoolSize 设置过高：短时流量高峰导致线程数暴涨，引发频繁上下文切换和 CPU 抢占，反而降低吞吐
- 拒绝策略选错：比如用 CallerRunsPolicy，会让主线程同步执行任务，在 Web 场景中直接拖垮请求线程池（如 Tomcat 的 worker 线程）
队列类型决定系统是“缓冲”还是“假稳”
队列不是越“大”越好，它本质是背压（backpressure）的载体：
- SynchronousQueue：不存任务，提交即需线程承接。适合任务到达速率与处理速率接近的场景，能快速暴露处理能力不足，迫使上游限流或降级
- 有界 LinkedBlockingQueue（如容量 100）：提供可控缓冲，配合 AbortPolicy 可及时失败告警，便于定位瓶颈环节
- 无界队列：等于放弃背压控制，系统稳定性完全依赖 JVM 堆大小，极易因 OOM 而宕机
拒绝策略是最后的安全闸门
当线程池真正“扛不住”时，拒绝策略不是异常兜底，而是系统自我保护的信号出口：
立即学习“Java免费学习笔记（深入）”；
- AbortPolicy（默认）：抛 RejectedExecutionException，要求调用方捕获并做降级/重试/告警，最利于问题暴露
- DiscardPolicy：静默丢弃，适合可丢失任务（如日志聚合），但需确保业务语义允许
- DiscardOldestPolicy：丢掉队列头任务，适用于希望“保新舍旧”的实时性敏感场景
- 自定义策略：可记录指标、触发熔断、推送告警，把拒绝变成可观测事件
线程池隔离避免故障横向蔓延
单个全局线程池一旦打满，所有依赖它的业务都会卡住。实践中应按业务维度拆分：
- 支付回调、消息投递、报表生成等不同 SLA 要求的任务，使用独立线程池
- 每个池配专属队列 + 合理拒绝策略 + Prometheus 指标暴露（如 activeCount、queueSize、rejectedTasks）
- 配合 Hystrix 或 Resilience4j 做熔断，当某池拒绝率持续超标，自动切断该通道，保主链路
