GCD调度并发队列冻结,崩溃日志中的"Dispatch Thread Soft Limit Reached:64"

Question

我的程序是一个处理传入请求的服务器.每个有效请求都被包装NSOperation并传递给法线NSOperationQueue.

每个都NSOpearation处理它的请求.在某些情况下,NSDictionary我使用dispatch_queue(并发队列),dispatch_barrier_async(当设置值时)和dispatch_sync(当获取值时)存在争用,以使此NSDictionary线程安全.

我同时用100个请求测试我的程序,然后该过程有时冻结.我用SIGSEGV查看崩溃日志来终止进程.

大多数线程都停留在dispatch_sync此队列中.下面有一张纸条

达到调度线程软限制:64(同步操作中阻塞的调度线程太多)

这个音符到底意味着什么？它的行为是什么？我找不到有关此限制的信息.我该如何解决这个问题？

我可以想出两种可能的方法来避免这个问题.(我将测试它们并稍后更新)

1. 使用dispatch_semaphore限制块提交给该并发队列.
2. 限制maxConcurrentOperationCount的NSOperationQueue

你有更好的解决方案吗？

Answer 1

\n

我可以想到两种可能的方法来避免这个问题。（我将对其进行测试并稍后更新）

\n\n

\n
1. 用于dispatch_semaphore限制将块提交到此并发队列。
\n
2. maxConcurrentOperationCount的极限NSOperationQueue。
\n

\n

\n\n

是的，这是两种常见的模式。为了未来的读者，解决这个\xe2\x80\x9cexhausting工作线程\xe2\x80\x9d问题的另一个解决方案是Objective-C\'s dispatch_apply，也称为concurrentPerformSwift，它允许以一种获胜的方式进行并发操作。 \xe2\x80\x99t 耗尽你的工作线程池。但是，\xe2\x80\x99s 实际上仅适用于预先启动一系列任务（例如，您想要并行化循环for），而不适用于您在问题中概述的场景。但是，根据记录，dispatch_apply/仍然concurrentPerform是这个普遍问题的第三种常见解决方案。

\n\n

\n

我找不到有关此限制的信息。

\n

\n\n

WWDC 2012 视频《使用块、GCD 和 XPC 的异步设计模式》曾经很好地介绍了这一点，但该视频不再可用（奇怪的是，其他 WWDC 2012 视频可用，但不是那个）。但他们确实在 WWDC 2015 视频使用 GCD 构建响应式且高效的应用程序中解决了有限工作线程问题。

\n