dispatch_async和[NSURLConnection sendSynchronousRequest]

Question

围绕这个主题存在各种各样的问题，并且许多建议说不要在dispatch_async中使用sendSynchronousRequest，因为它会阻塞线程，GCD将产生许多新的工作线程来为所有同步URL请求提供服务。

似乎没有人对iOS 5，[NSURLConnection sendAsynchronousRequest：queue：completionHandler：]在幕后做什么有明确的答案。

我读过的一篇文章指出它可能会“优化”，并且“可能”使用运行循环 - 但肯定不会为每个请求创建一个新线程。

当我在使用sendAsynchronousRequest：queue：completionHandler时暂停我的调试器时，堆栈跟踪如下所示：

..现在看起来sendAsynchronousRequest：queue：completionHandler实际上正在调用sendSynchronousRequest，当我使用异步方法而不是同步方法时，我仍然创建了大量的线程。

是的，使用异步调用还有其他好处，我不想在这篇文章中讨论。

所有我感兴趣的是性能/线程/系统使用情况，如果我更糟糕的是在dispatch_async中使用同步调用而不是使用异步调用。

我也不需要使用ios4异步调用的建议，这纯粹是出于教育目的。

有没有人对此有任何有见地的答案？

由于

Answer 1

这实际上是开源的。 http://libdispatch.macosforge.org/

与Apple的实施相比，您不太可能更有效地管理工作线程。在这种情况下，“异步”并不意味着选择/轮询，它只是意味着调用将立即返回。因此，实现产生线程并不奇怪。

Answer 2

如前所述，GCD（libdispatch）和libblocksruntime都是open source。在内部，iOS / OS X管理全局pthread池，以及您在用户代码中创建的任何特定于应用程序的池。由于OS线程和调度任务之间存在1：N映射，因此您不必（也不应该）担心线程创建和处理。为此，GCD任务在调用之后不会在应用程序的运行循环中使用任何时间，因为它被惩罚到后台线程。

大多数NSURL操作都是I / O绑定的;没有多少并发voodo可以掩盖这一点，但如果Apple自己的异步实现在后台使用其同步对应物，它可能表明它已经相当高度优化。与前面的回答所说的相反，libdispatch 在内部使用可扩展的I / O（在OS X / iOS / BSD上kqueue），如果你自己动手推出一些东西，你就拥有了自己处理文件描述符准备就绪以产生类似的性能。

虽然可能，投资的准时回报可能是微不足道的。坚持使用Apple的实现并停止担心线程！