老规矩，还是先上个代码：

2026/7/23 10:20:01

这个代码的逻辑非常简单，首先我们搞了一个线程池，然后起一个 for 循环往线程池里面仍了 5 个任务，这是核心逻辑。

对于这几个任务，我们的这个自定义线程池处理起来，不能说得心应手吧，至少也是手拿把掐。

其他的 StopWatch 是为了统计运行时间用的。至于 CountDownLatch，你可以理解为在业务流程中，需要这五个任务都执行完成之后才能往下走，所以我搞了一个 CountDownLatch。

这个代码运行起来是没有任何问题的，我们在日志中搜索“执行完成”，也能搜到 5 个，这个结果也能证明程序是正常结束的：

同时，可以看到运行时间是 4s。

示意图大概是这样的：

然后歪师傅看着这个代码，发现了一个可以优化的地方：

这个地方从数据库捞出来的数据，它们之间是没有依赖关系的，也就是说它们之间也是可以并行执行的。

所以歪师傅把代码改成了这样：

在异步线程里面去处理这部分从数据库中捞出来的数据，并行处理加快响应速度。

对应到图片，大概就是这个意思：

把程序运行起来之后，日志变成了这样：

我们搜索“执行完成”，也能搜到 5 个对应输出。

而且我们就拿“任务2”来说：

当前线程pool-1-thread-3,—【任务2】开始执行—
当前线程pool-1-thread-3,—【任务2】执行完成—
当前线程pool-1-thread-1,【任务2】开始处理数据=1
当前线程pool-1-thread-2,【任务2】开始处理数据=2
从日志输出来看，任务 2 需要处理的两个数据，确实是在不同的异步线程中处理数据，也实现了我的需求。

但是，程序运行直接就是到了 9.9ms：

这个优化这么牛逼的吗？

从 4s 到了 9.9ms？

稍加分析，你会发现这里面是有问题的。

那么问题就来了，到底是啥问题呢？

你也分析分析大概是啥问题，别老是想着直接找答案啊。

问题就是由于转异步了，所以 for 循环里面的任务中的 countDownLatch 很快就减到 0 了。

于是 await 继续执行，所以很快就输出了程序运行时间。

然而实际上子任务还在继续执行，程序并没有真正完成。

9.9ms 只是任务提交到线程池的时间，每个任务的数据处理时间还没算呢：

从日志输出上也可以看出，在输出了 StopWatch 的日志后，各个任务还在处理数据。

这样时间就显得不够真实。

那么我们应该怎么办呢？

很简单嘛，需要子任务真正执行完成后，父任务的 countDownLatch 才能进行 countDown 的动作。

具体实现上就是给子任务再加一个 countDownLatch 栅栏：

我们希望的运行结果应该是这样的：

当前线程pool-1-thread-3,—【任务2】开始执行—
当前线程pool-1-thread-1,【任务2】开始处理数据=1
当前线程pool-1-thread-2,【任务2】开始处理数据=2
当前线程pool-1-thread-3,—【任务2】执行完成—
即子任务全部完成之后，父任务才能算执行完成，这样统计出来的时间才是准确的。

思路清晰，非常完美，再次运行，观察日志我们会发现：

呃，怎么回事，日志怎么不输出了？

是的，就是不输出了。

不输出了，就是踩到这个坑了。

不论你重启多少次，都是这样：日志不输出了，程序就像是卡着了一样。

坑在哪儿
上面这个 Demo 已经是我基于遇到的生产问题，极力简化后的版本了。

现在，这个坑也已经呈现在你眼前了。

我们一起来分析一波。

首先，我问你：真的在线上遇到这种程序“假死”的问题，你会怎么办？

早几年，歪师傅的习惯是抱着代码慢慢啃，试图从代码中找到端倪。

这样确实是可以，但是通常来说效率不高。

现在我的习惯是直接把现场 dump 下来，分析现场。