万万没想到在生产环境翻车了，之前以为很熟悉 CountDownLatch

• 前言

• 需求背景

• 具体实现

• 解决方案

• 总结

前言 

之前我们分享了CountDownLatch的使用。这是一个用来控制并发流程的同步工具，主要作用是为了等待多个线程同时完成任务后，在进行主线程任务。然而，在生产环境中，我们万万没想到会出现问题。这是因为我们没有考虑到一些场景，导致了CountDownLatch出现了问题。

让我们来深入地了解一下由于CountDownLatch导致的问题。首先，我们需要明确的是，CountDownLatch是一个非常强大的工具。它可以帮助我们控制多个线程的执行过程，从而提高程序的并发性和效率。然而，如果我们没有正确地使用它，就可能会出现一些问题。

 

需求背景

先简单介绍下业务场景，针对用户批量下载的文件进行修改上传

为了提高执行的速度，我们採用了线程池来执行下载-修改-上传的操作。此外，我们还引入了CountDownLatch来控制线程之间的同步，以确保所有的操作都被正确执行。在所有线程完成之后，我们会将文件的地址保存到数据库中，以便之后的使用。这种方法不仅提高了程序的效率，而且减轻了线程的压力，从而使程序更加稳定可靠。

 

具体实现

根据服务本身情况，自定义一个线程池

 

模拟执行 

一开始我个人感觉没有什么问题，反正finally都能够做减一的操作，到最后调用await方法，进行主线程任务 

由于任务数量较多，阻塞队列中已经塞满了，所以线程池默认的拒绝策略会生效。当队列满时，处理策略会报错，并抛出异常。需要注意的是，这个异常是线程池自己抛出的，而非我们在循环中打印出来的。这种情况也会导致在线程池中断后，主线程会被打断，而await方法将无法执行。为了解决这个问题，我们可以利用jstack工具来查看线程池中的异常情况，并进行详细的分析和调试。此外，我们还可以进行一些优化措施，例如增加线程池的容量、调整任务队列的大小、优化任务处理策略等等，以提高线程池的性能和稳定性。 

解决方案 

为了解决阻塞队列过小导致的问题，我们可以考虑将其调大，但问题在于，应该调到多大才合适呢？如果调得太大，可能会带来内存溢出等其他问题。因此，我们需要在实际运行中不断测试和调整，找到一个适合当前情况的队列大小。

除了调整阻塞队列大小，我们还可以修改拒绝策略。在触发拒绝策略时，可以使用调用者所在的线程来执行任务。这种做法可以避免因线程池过载导致的任务执行失败。当然，这也可能会带来一些新的问题，例如如果调用者线程本身就很繁忙，可能会导致更多任务积压。因此，我们需要根据实际情况进行权衡和调整。

你可能会担心任务数量太多，导致调用者所在的线程执行不过来，从而导致任务提交的性能急剧下降。但是，不要担心，我们可以通过自定义拒绝策略来解决这个问题。我们可以将排队的消息记录下来，采用补偿机制的方式去执行，从而避免任务数量太多的问题。这样，您就可以放心地提交任务，无需担心性能问题。

同时，我们也需要注意线程池可能会抛出异常。因此，我们需要在代码中加入try catch语句，以记录问题数据。在finally中，我们还需要执行countDownLatch.countDown语句，以避免线程池的使用出现问题。这样，我们就可以更好地使用线程池，并且避免出现不必要的问题。

总结 

根据业务部门的反馈，我们发现在实际业务中任务数量并不是很多。这可能是因为我们的系统中存在一些瓶颈，导致流程无法顺畅地进行。因此，我们决定先采用第二种方式来尝试解决这个线上问题。虽然这种方式可以解决目前的问题，但我们需要注意到，如果没有正确地关闭countDownLatch，就会导致一直等待。为了避免这个问题，我们需要对代码进行一些修改，以确保其正常运行。

另外，我们需要意识到，工具虽然是好的，但其使用也可能带来一些问题。如果我们没有正确地处理，就会引发一系列连锁反应。因此，我们需要仔细地评估工具的使用，以确保我们能够使其发挥最大的效益，同时避免潜在的问题。我们可以考虑对新工具进行一些测试，以确保其稳定性和可靠性。此外，我们还可以开发一些新的功能，以提高我们的工作效率。这些功能可以包括自动化流程、数据分析和报告生成等。