Java线程池通过任务缓存队列缓冲突发任务，而非无限制增线程，以控制资源开销、保障稳定性并平衡响应性与吞吐量；线程创建销毁开销大，过多线程引发上下文切换风暴、GC压力及OOM风险；合理配置线程数与队列类型（如SynchronousQueue、LinkedBlockingQueue、ArrayBlockingQueue）并配合拒绝策略（如CallerRunsPolicy），可实现弹性、可观测与可控的并发治理。
Java 线程池不靠无限制增加线程来应对突发任务，而是用任务缓存队列作缓冲带——核心原因是控制资源开销、保障系统稳定性，同时兼顾响应性与吞吐量的平衡。
线程创建和销毁本身有显著开销
每次 new Thread() 都会触发操作系统级资源分配：栈内存（默认 1MB）、内核线程结构、上下文切换准备等。频繁创建/销毁线程不仅拖慢任务提交速度，还会引发 GC 压力和 CPU 上下文切换风暴。尤其在高并发短任务场景下，线程数翻倍可能让吞吐反而下降。
- 一个空闲线程平均占用约 0.5–1MB 堆外内存
- 线程切换一次通常消耗 1–10 微秒，千线程规模下调度开销不可忽视
- JVM 对线程总数有限制（受 -Xss 和系统 ulimit 影响），硬扩容有物理上限
队列缓冲能平滑负载峰谷
真实业务流量常呈脉冲式（如秒杀、定时报表生成），短暂高峰后迅速回落。队列把“瞬时压力”转化为“可排队等待”，让固定数量的工作线程以稳定节奏消化任务，避免线程数剧烈震荡带来的抖动。
- SynchronousQueue（无缓冲）适合低延迟场景，但要求线程即时可用
- LinkedBlockingQueue（无界）提供柔性缓冲，但需防 OOM（任务积压过久）
- ArrayBlockingQueue（有界）强制背压，配合拒绝策略可及时反馈系统过载
线程数膨胀会破坏关键服务质量目标
过多线程会稀释 CPU 时间片、加剧锁竞争（如 ThreadPoolExecutor 内部的 mainLock）、干扰 GC 停顿行为，甚至导致部分任务长期得不到执行（饥饿）。而合理大小的线程池 + 合适队列，能让每个线程保持较高利用率（理想 70%–90%），同时保留弹性余量。
立即学习“Java免费学习笔记（深入）”；
- CPU 密集型任务：线程数 ≈ CPU 核心数，队列宜小或无界（避免阻塞）
- IO 密集型任务：线程数可适度放大（如 2×CPU），队列可稍大，容忍等待
- 混合型任务：推荐使用 ScheduledThreadPool 或分层线程池隔离不同优先级任务
拒绝策略比盲目扩容更可控
当队列也满时，线程池不是继续加线程，而是触发拒绝策略（如 AbortPolicy、CallerRunsPolicy）。这相当于主动设下“熔断点”，把压力反馈给上游（调用方），促使其降级、重试或限流——这种显式反馈机制，比隐式线程爆炸更利于故障定位和容量治理。
- CallerRunsPolicy 让调用线程自己执行任务，天然限流且不新增资源
- 自定义拒绝策略可记录日志、发告警、写入死信队列，形成可观测闭环
- 扩容应基于长期监控指标（如平均队列长度、拒绝率 > 1%），而非瞬时波动
