Java线程池怎么做预热？从硬编码到pool.prestartCoreThread

Java线程池怎么做预热？从简单到复杂一步步聊聊

在Java开发中，线程池是个老生常谈的话题，尤其是用它来处理并发任务的时候，大家都希望它能跑得又快又稳。不过你有没有想过，刚建好的线程池就像一台刚出厂的车，冷不丁上高速总得有个热身过程吧？今天咱们就聊聊线程池的"预热"，从最简单粗暴的办法开始，慢慢推到现如今大家都认可的高效方案，顺便看看每一步能怎么优化。

先来个最朴素的策略：啥也不干，直接用

假设我们用Java的ThreadPoolExecutor建了个线程池，核心线程数设成5，最大线程数10，队列用个LinkedBlockingQueue，容量给个100。代码大概长这样：

java 复制代码

ThreadPoolExecutor pool = new ThreadPoolExecutor(
    5, 10, 60L, TimeUnit.SECONDS,
    new LinkedBlockingQueue<>(100)
);

好了，线程池搭好了，任务一来就直接往里扔，比如提交100个任务，每个任务睡个1秒模拟工作：

java 复制代码

for (int i = 0; i < 100; i++) {
    pool.execute(() -> {
        try {
            Thread.sleep(1000);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
    });
}

这时候会发生啥？线程池默认是"懒加载"的，核心线程数5意味着一开始只有0个线程，任务来了才会慢慢创建线程，最多到5个。如果任务量猛增，队列会先塞满（100个容量），然后才会扩到最大线程数10。这种冷启动的玩法有啥问题呢？

启动慢：线程创建是有开销的，操作系统得分配资源、初始化栈啥的，假设创建1个线程要10毫秒，5个就是50毫秒，任务高峰一来，前几批任务处理明显会卡。
响应抖动：线程数从0到5再到10，队列从空到满，这个过程中任务的执行时间不稳定，用户体验可能就差了。

发现问题后咋整？手动塞任务预热

既然冷启动慢，咱们就先给线程池"热热身"。最直观的办法就是在启动时手动扔几个任务，让核心线程先跑起来。比如：

java 复制代码

ThreadPoolExecutor pool = new ThreadPoolExecutor(
    5, 10, 60L, TimeUnit.SECONDS,
    new LinkedBlockingQueue<>(100)
);
// 预热：塞5个空任务
for (int i = 0; i < 5; i++) {
    pool.execute(() -> {});
}

这招管用吗？确实能让5个核心线程提前创建好，任务一来就不用等线程初始化了。开销呢？5个空任务几乎没啥成本，挺划算。但这方案也有短板：

不够灵活：核心线程数写死了5，如果业务改成10怎么办？每次改配置还得改预热代码，太麻烦。
预热不彻底：只起了核心线程，最大线程数10的场景没覆盖。如果业务高峰一来，队列满了还得临时扩线程，还是会抖。

优化方向呢？得让预热跟线程池配置挂钩，别写死数字，还得考虑高峰场景。

再进一步：动态预热核心线程

Java的ThreadPoolExecutor有个方法叫prestartCoreThread()，每次调用会启动一个核心线程，直到达到核心线程数。咱们改进下：

java 复制代码

ThreadPoolExecutor pool = new ThreadPoolExecutor(
    5, 10, 60L, TimeUnit.SECONDS,
    new LinkedBlockingQueue<>(100)
);
// 预热所有核心线程
int corePoolSize = pool.getCorePoolSize();
for (int i = 0; i < corePoolSize; i++) {
    pool.prestartCoreThread();
}

或者直接用prestartAllCoreThreads()，一行搞定：

java 复制代码

pool.prestartAllCoreThreads();

这比手动塞任务强在哪？首先，代码跟核心线程数绑定了，配置改了预热自动适应，维护成本低。其次，prestartCoreThread()是线程池原生支持的，干净利落。不过问题还在：

最大线程数没管：高峰期还是得临时扩线程。
资源浪费风险：如果业务量一直不高，5个线程老闲着，白占内存和CPU。