java - 线程池死锁 : designing against or detecting

Question

我希望这不是太宽泛；我的问题是“我如何设计一个具有多个不会死锁的线程池的服务？”。

我拥有一项网络服务，可根据单个用户请求扇出 100 个线程，以低延迟执行数据聚合。有许多 ExecutorServices 包装固定线程池散落在我的服务中，我需要帮助解决一个有趣的方法，这可能会造成死锁。

我有一个线程池 A 用于保存发出网络请求的线程，还有另一个线程池 B 用于保存它们“拥有”的线程；业务逻辑的聚合位可能会分散到少数请求中。此外，当可以通过聚合 3 个更简单的子聚合来完成聚合时，B 中的线程偶尔会向线程池 B 提交一些工作。

这个模式就是问题所在。让我们考虑提交给 B 的请求 x 的样式，它导致将附加请求 x' 提交给 B .我们还考虑 B 是一个包含 50 个线程的固定线程池。当50个x类型的请求同时进来时，使用B中的所有线程来处理这些请求。他们都将他们的 x1 提交给 B，后者在队列中等待线程。然后所有请求的所有处理都处于死锁状态 60 秒，直到超时并且 x 请求所有返回异常。

我考虑/尝试过的事情:

• 调整数字。可以连接的最大用户数是 50，B 中的线程是 100。防止出现问题，但似乎是一个 hack，当另一个开发人员在一年内调整不相关的数字并且没有人能弄清楚为什么我们在负载下每周锁定一次。我想在设计中解决这个问题。
• B 将展开的工作提交给新的线程池 B'。不起作用，因为此扇出可能会进行多个步骤(我是否创建 B''、B'''、...？)
• B 没有最大线程数。可能是可以接受的，但似乎很危险。
• 另一种模型(更回调？)，其中线程不提交并等待相同的工作单元；相反，他们提交工作并将“回调”提交到“追赶”池。这样，没有什么可以等待自己池中的东西。有先例吗，这是个好主意吗？
• 合并所有线程池并移除最大值？

Answer 1

您的“更具回调性”的答案似乎大部分都可以通过 CompletionStage 为您解决Java 8 中的 API - 缺少“runAfterAllAsync”方法意味着您可能必须做一些外部工作才能在您的 3 个子任务组之后发生某些事情，但这就是我开始关注的地方。 This tutorial有一个可能有帮助的例子。