Java八股：线程池与并发为什么总出问题

先说结论

并发题之所以总是高频，不是因为它炫，而是因为它真的容易出事故。线程池配错了会堆积，锁用错了会死锁，队列无限大了会把内存吃光，任务一多还可能把下游直接打挂。

所以并发题的核心不是“你会不会背类名”，而是“你能不能预判风险”。真正成熟的并发理解，是能提前想到任务会不会堆、线程会不会爆、锁会不会争、数据会不会乱。

线程池到底解决什么

线程池的目标不是让线程变多，而是让线程复用起来，并且把并发控制在可接受范围内。

如果没有线程池，每来一个任务都创建一个线程，成本会很高。线程太多时，系统还会在上下文切换上消耗大量时间，最后 CPU 看起来很忙，真正干活的时间却不多。

线程池通常解决三件事：

• 复用线程，减少创建和销毁成本
• 限制并发，避免系统被打爆
• 缓冲任务，让高峰流量有地方排队

线程池为什么会出问题

很多线上故障都不是线程池“坏了”，而是线程池把原本就存在的问题暴露出来了。

常见问题有：

• 核心线程数太大，CPU 被切换拖垮
• 队列太长，任务堆积导致延迟越来越高
• 拒绝策略没设计好，流量一来直接报错
• 业务线程和线程池共用，互相影响

线程池本身不是问题，问题是你把它当成了万能缓冲垫。

一个线程池的执行过程

这个流程很像现实里的工厂：任务先排队，空闲工人再处理，超出产能时就得选择拒绝、降级或者延后处理。你只要理解这个比喻，线程池的很多参数就好理解了。

为什么锁总是和并发题一起出现

因为并发的本质问题就是共享数据的安全性。多个线程同时读写同一个资源，如果没有约束，就很容易出现脏数据、覆盖写、顺序错乱。

锁的作用，就是在关键资源前面排队，保证同一时间只有一个线程进入临界区。

但锁也不是免费的：

• 锁太粗，会让并发度下降
• 锁太细，会让管理复杂度上升
• 锁用不好，可能直接死锁

所以并发设计永远是在“安全”和“性能”之间找平衡。

面试最常问的几个点

你至少应该能把这些说清楚：

1. 核心线程和最大线程的区别
2. 队列长度为什么会影响吞吐和延迟
3. 拒绝策略分别适合什么场景
4. 为什么锁会带来性能下降
5. 为什么高并发下更要重视幂等和限流

如果再往下延伸一点，你还可以讲限流、超时、隔离和熔断，因为它们本质上都是为了控制并发风险。

实战里怎么设计更稳

如果是业务系统，线程池设计最好别靠拍脑袋。可以按下面思路思考：

• CPU 密集型任务，线程数不要盲目开大
• IO 密集型任务，可以适当放大线程数，但要看下游承受能力
• 不同业务链路最好隔离线程池
• 明确拒绝策略，不要让任务无限堆积
• 配合超时和降级，避免请求无休止等待

很多系统不是处理能力不够，而是没有边界。线程池的价值就在于给系统加边界。

一个更稳的回答模板

如果被问“为什么线程池重要”，你可以这样答：

线程池的主要作用是复用线程、控制并发和缓冲任务。它能减少频繁创建线程的开销，但如果线程数、队列和拒绝策略设计不合理，也会带来堆积、延迟和资源耗尽的问题。并发里更重要的不是让系统尽量跑快，而是让系统在高压下依然可控。

这段话听起来不花哨，但很稳，也很工程化。

结尾

并发不是让系统更“猛”，而是让系统在并发条件下仍然稳定。线程池、锁、队列、拒绝策略，这些看似基础的东西，实际上决定了你的服务能不能扛住高峰。