我对 GCD 的工作原理有一个扎实的了解，但我想了解更多关于吹捧的“操作系统管理”内部结构的信息。似乎几乎所有关于 Grand Central Dispatch 如何与“操作系统”配合使用的技术解释都完全不同。我将解释我的一些发现。
“它是一个对操作系统来说是全局的守护进程，它在许多内核上分配任务。”
我还没有傻到相信这一点。
“内核中内置了支持以了解所有 GCD 应用程序。GCD 应用程序与内核协同工作，以就如何管理应用程序内的线程做出逻辑决策。”
听起来这种同步方案比仅管理应用程序中的逻辑要慢得多。
“GCD 仅存在于应用程序中，并使用当前系统负载作为衡量其行为方式的指标。”
这对我来说听起来更现实，但我只在一个地方看到过这样的声明。
这里到底发生了什么？它只是一个库，还是一个完整的“系统”？
它是一个库，但有一些内核优化允许系统级控制。特别是，有一个附加接口pthread_workqueue允许 GCD 告诉内核它想要一个线程运行某个特定功能，但实际上并不启动一个线程（它基本上是一个延续）。此时，内核可以根据系统负载选择是否启动该延续。
所以是的，有一个全局系统范围的基础设施来管理内核中的 GCD 线程，第二个答案是正确的。您所犯的错误是认为那里正在进行同步，这将花费一些东西。调度器无论如何都会运行，GCD 所做的是使用了一个新接口，它让调度器不仅可以根据线程的相对优先级决定是否运行线程，还可以根据线程的相对优先级来决定是否创建或销毁线程好。
这是一个（重要的）优化，但不是绝对必要的，而且 FreeBSD 端口实际上并不支持系统范围的东西。如果您想查看实际的接口，这里是pthread_workqueue.h，实现在 Apple 的pthread.c中，您可以在start_wqthread.s的 asm 存根中看到内核用于启动工作队列的存根入口点。如果你真的想要的话，你也可以通过 xnu 来查看它是如何调用存根的。