线程池通过复用线程、削峰填谷、可控调度提升并发能力，需依任务类型合理配置参数，并规避默认工具类、监控缺失等陷阱。
线程池能显著提升系统并发能力，但效果取决于是否用对、配准、管好。它不是“开箱即快”的银弹，而是需要结合任务特征和资源约束精细调控的基础设施。
线程池如何切实提升并发能力
核心在于三点：复用线程、削峰填谷、可控调度。
- 避免线程创建销毁开销：每次 new Thread() 需分配栈内存（默认 1MB）、触发内核调度、经历 JVM 线程生命周期管理。高并发下频繁新建极易引发 OOM 和上下文切换风暴；线程池让线程“一次创建，多次使用”，把这部分成本摊薄到大量任务上。
- 平滑任务执行节奏：通过有界队列缓冲突发请求，防止瞬时流量直接压垮下游；配合拒绝策略（如 CallerRunsPolicy），让调用方感知压力并主动降速，形成自然背压机制。
- 限制资源占用边界：明确设定 corePoolSize、maxPoolSize 和队列容量，使系统在 CPU、内存、文件句柄等维度始终处于可预期范围内，避免因线程数失控导致服务雪崩。
关键配置决定实际效果上限
参数设错，性能可能不升反降。
- CPU 密集型任务：核心线程数建议设为 Runtime.getRuntime().availableProcessors() ± 1。线程过多只会加剧上下文切换，拖慢整体吞吐；此时推荐搭配 SynchronousQueue，避免任务堆积，让线程“忙完即走”。
- I/O 密集型任务：线程常阻塞在等待网络或磁盘响应，可适当放大核心线程数至 CPU 核数的 2–4 倍；队列宜选 ArrayBlockingQueue（如容量 100–1000），防无界增长导致 OOM。
- 拒绝策略不能忽略：AbortPolicy 在高并发下直接抛异常，易引发上游级联失败；CallerRunsPolicy 虽简单，但能有效缓解压力；生产环境建议自定义策略，记录日志+告警+降级处理。
线程池本身的局限性
它解决的是“线程怎么管”的问题，不是“业务怎么快”的万能解。
立即学习“Java免费学习笔记（深入）”；
- 无法消除 I/O 或锁竞争瓶颈：若任务本身依赖慢 SQL、长链路 HTTP 或全局锁，增加线程只会加重争抢，响应时间反而恶化。
- 扩容能力有限：maximumPoolSize 的扩容仅在队列满且核心线程全忙时触发，这个过程本身有开销；它不适合扛持续洪峰，更适合应对短时毛刺。
- 不解决任务内部阻塞：比如 submit 一个含 Thread.sleep(5000) 的任务，该线程就卡住 5 秒——再多线程也救不了单个任务的低效，需从异步化、非阻塞 IO 等层面优化。
- 监控盲区风险：若未暴露活跃线程数、队列长度、拒绝次数等指标，就等于开着飞机不看仪表盘；压测和线上观察缺一不可。
绕不开的实践陷阱
很多故障源于“图省事”的默认配置。
- Executors 工具类慎用：newFixedThreadPool 使用无界 LinkedBlockingQueue，任务积压必 OOM；newCachedThreadPool 允许创建 Integer.MAX_VALUE 个线程，突发流量下机器直接假死。
- keepAliveTime 易被误读：它只对“超出 corePoolSize 的空闲线程”生效；核心线程默认永驻——若想夜间自动缩容，必须显式调用 setAllowCoreThreadTimeOut(true)。
- execute() vs submit() 混用埋雷：execute 抛异常直接打印 stderr，容易漏掉；submit 返回 Future，异常藏在 get() 里——不调 get 就永远不知道任务失败，建议带超时调用 future.get(3, TimeUnit.SECONDS)。
