线程池死锁：设计反对或检测(Threadpool Deadlock: designing against or detecting)

 我希望这不是过分广泛; 我的问题是“如何设计一个具有多个Threadpool的服务，这些服务不会自行死锁？”。 
 
 我拥有一个Web服务，可以在单个用户请求中扇出100个线程，以低延迟执行数据聚合。 在我的服务中有许多ExecutorServices包装固定线程池，我需要帮助解决一个有趣的方法，这可能会造成死锁。 
 
 我有一个线程池A ，用于保存发出网络请求的线程，另一个线程池B ，用于保存它们的“拥有”线程; 业务逻辑的聚合位可能会散布到少数请求中。 此外，当聚合可以通过聚合3个更简单的子聚合来完成聚合时， B线程偶尔会向线程池B提交一些工作。 
 
 这种模式就是问题所在。 让我们考虑一个提交给B的请求x样式，这会导致另外一个请求x'被提交给B 我们还要考虑B是50个线程的固定线程池。 当x类型的50个请求同时进入时， B中的所有线程都用于处理这些请求。 所有这些都将他们的x1提交给B ，它位于等待线程的队列中。 然后，所有请求的所有处理都处于死锁状态60秒，直到达到超时并且x请求所有返回异常。 
 
 我考虑/试过的事情： 
 
 
 
 调整数字。 可以连接的最大用户数为50， B线程数为100.防止出现问题，但是当另一个开发人员在一年内调整不相关的数字并且无法解决为什么我们在负载下每周锁定一次时，这似乎是一个破解。 我想在设计中解决这个问题。 
 
 
 B向B' （一个新的线程池）提交了工作。 不起作用，因为这个扇出可能会走多步（我创建B'' ， B''' ，......？） 
 
 
 B没有最大线程。 可能接受，似乎很危险。 
 
 
 另一个模型（更多回调？）线程不提交并等待相同的工作单元; 而是他们提交工作并向“run-after”池提交“回调”。 这样，没有什么可以在自己的池中等待某些东西。 有先例，这是个好主意吗？ 
 
 
 将所有线程池折叠在一起并删除最大值？ 
 

I hope this isn't overly broad; my question is "How do I design a service with multiple Threadpools which can't deadlock itself?".
 
I own a web service which fans out to 100s of threads on a single user request, to perform data aggregation with low latency. There are a number of ExecutorServices wrapping fixed-thread pools sprinkled throughout my service, and I need help solving an interesting way this can create deadlock.
 
I have a threadpool A which is used to hold Threads making network requests, and another threadpool B which is used to hold their "owning" threads; aggregation bits of business-logic which might fan out into a handful of requests. Additionally, threads in B occasionally submit bits of work to threadpool B, when an aggregation can be done by aggregating 3 simpler sub-aggregations.
 
This pattern is the problem. Let's consider a style of request x submitted to B which causes an additional request x' to be submitted to B. Let's also consider B is a fixed thread pool of 50 threads. When 50 requests of type x come in at the same time, all threads in B are used to handle these requests. All of them submit their x1 to B, which sits in the queue waiting for a thread. And then all processing of all requests sits in deadlock for 60 seconds until a timeout is hit and the x requests all return Exceptions.
 
Things I've considered/tried:
 
 
 
Tweak numbers. Maximum users who can connect is 50, threads in B is 100. Prevents the problem, but seems like a hack that will break when another dev tweaks unrelated numbers in a year and no one can figure out why we lock up once a week under load. I want to solve this in the design.
 
 
B submits fanned out work to B', a new threadpool. Doesn't work because this fan-out can potentially go multiple steps (do I create B'', B''', ...?)
 
 
B has no max threads. Possibly acceptable, seems dangerous.
 
 
Another model (more callbackish?) where threads don't submit and wait for the same unit of work; rather they submit work and submit a "callback" into the "run-after" pool. This way nothing can wait for something in its own pool. Is there precedent, is this a good idea?
 
 
Collapse all thread pools together and remove the max?
 

原文：https://stackoverflow.com/questions/28329682