你真的理解 Java 中的线程池吗？一次“查不出原因的接口变慢”的真实排查经历

我是做 Java 后端的，这两年最频繁被问到的问题之一就是： "你线程池是怎么配置的？"

说实话，线程池这东西------面试时你会答几个参数；写代码的时候 Executors.newFixedThreadPool(10) 敲完就完事。但一旦你线上接口开始时不时变慢、线程卡死、请求堆积......你就不得不深入理解它。

这篇文章不是讲什么原理八股，而是分享一个真实线上问题的排查过程，以及我自己对线程池的重新理解。

大概一个月前，有业务方反馈说我们的一个导出接口偶发性响应很慢，大部分时间都正常，但一旦慢了就是十几秒甚至 timeout。

我们初步排查日志，没有异常、没有超时、数据库也不慢，怎么看都正常。

直到我用 jstack 分析线程，发现：

vbnet 复制代码

"pool-3-thread-8" #55 prio=5 ... WAITING on java.util.concurrent.FutureTask"pool-3-thread-7" #54 prio=5 ... BLOCKED on org.apache.poi.XSSFWorkbook...

是的，导出任务用到了 Apache POI 写 Excel，而我们把任务统一交给了一个线程池处理。

项目中我们用的是：

ini 复制代码

private ExecutorService exportExecutor =  Executors.newFixedThreadPool(5);

看起来没毛病。几个异步导出任务而已，5 个线程够用了吧？

后来我们发现了几个关键点：

最终导致的问题是：线程池任务队列堆满 + 全部线程阻塞 = 新任务进不来

换句话说，我们用线程池来"优化"接口性能，结果变成了"绞杀"系统的元凶。

不是说线程池不好，而是我们用了一个"看起来简单、但其实暗藏风险"的默认配置。

Executors.newFixedThreadPool(n) 背后的真实构造：

arduino 复制代码

return new ThreadPoolExecutor(n, n,    0L, TimeUnit.MILLISECONDS,    new LinkedBlockingQueue<Runnable>());

复制代码

注意：它的队列是无限长的！

也就是说，一旦任务速度大于线程处理速度，就会堆、堆、堆，直到 OOM 或超时。

我们最终的做法是：

arduino 复制代码

new ThreadPoolExecutor(    4,    8,    60, TimeUnit.SECONDS,    new ArrayBlockingQueue<>(50),    new ThreadPoolExecutor.CallerRunsPolicy());

几个点必须说清楚：

这个问题让我明白了一件事：

你配的不是线程池，是系统的承载能力。

线程池不是让你"异步更快"，而是让你更稳、可控 。

特别是高并发、长耗时任务混在一起的场景，乱用一个全局线程池，只会把自己坑死。