Java ThreadPoolExecutor 动态调整核心线程数：方法与注意事项
不得不承认，这两年我的头发越来越少了，罪魁祸首之一就是给服务器的线程池随意添加特性。比如今天要聊的主角——让 ThreadPoolExecutor 的核心线程数动态调整。刚上手时信心满满，结果在一些细节上翻了几个跟头。接下来，用闲聊的方式，复盘这段“线程池养成记”。
动态调整线程池的初衷
场景很简单，公司后台每天会经历任务激增和低谷期。起初设定了50个核心线程：
ThreadPoolExecutor executor = new ThreadPoolExecutor(50, 200,
60L, TimeUnit.SECONDS,
new LinkedBlockingQueue<>());
初期运行良好，但某天监控告警显示CPU波动异常。明明核心线程充足，为何资源利用率不稳？这让我开始怀疑自己的配置是否合理。
动态调整的核心方法
经过一番研究，发现 setCorePoolSize 方法可以动态调整核心线程数。但实际使用中，需要注意以下几点：
- 正在执行的任务不受影响：核心线程数减少不会终止正在执行的任务。
- 核心线程超时设置：若
allowCoreThreadTimeOut(false)，核心线程即使空闲也不会退出。 - 线程创建的延迟性：增加核心线程数不会立即生效，需等待新任务到来。
- 队列的影响：队列任务过多时，调整核心线程数的效果有限。
- 任务与线程数的平衡：核心线程数不能低于队列中的任务数，否则线程池会尽力维持核心线程数量。
实践中的解决方案
总结出以下调整思路：
- 开启核心线程超时：
executor.allowCoreThreadTimeOut(true); - 逐步调整核心线程数：
executor.setCorePoolSize(20); - 监控和观察：定期检查队列和线程池状态，避免盲目调整。
配合这些设置，线程池能够更灵活地释放资源，避免过多空闲线程占用资源。
经验总结
以下是几点关键经验：
| 坑/建议 | 核心要点 |
|---|---|
setCorePoolSize |
仅修改数值，不会主动终止线程 |
allowCoreThreadTimeOut |
必须开启才能让核心线程自动退出 |
| 队列的影响 | 队列任务过多时，动态调整效果有限 |
| 新增核心线程 | 只有新任务到来时才会创建新线程 |
| 平滑调整，避免激进 | 最好配合监控，逐步调整，避免对系统造成过大波动 |
结语
动态调整线程池确实很实用，但需要细心维护。别指望Java能自动适应所有需求，尤其是在线上压力不同的情况下。改天再遇上“线程池发疯”，也能顺嘴把这些故事拿出来聊聊，顺便放松下发际线压力。欢迎大家留言交流！
—— 继续搬砖，溜了溜了 🏃♂️
随时随地看视频
