DispatchQueue是否使用RunLoop向线程分发任务？交互机制是怎样的

首先给出明确结论：DispatchQueue（GCD）的核心任务调度逻辑是独立实现的，完全不依赖RunLoop完成基础分发，仅在少数特定场景下会和线程专属RunLoop产生交互。

GCD 独立的核心调度逻辑 #

DispatchQueue的底层实现是libdispatch库，它自己维护了一套全局的工作线程池，整套任务分发链路和RunLoop没有绑定关系：

• 当任务被提交到任意DispatchQueue后，libdispatch会根据队列类型（串行/并发）、任务QoS优先级、当前系统负载情况，从自身管理的工作线程池中选取可用线程执行任务，整个选取、唤醒线程执行任务的流程由libdispatch在内核事件（kevent/epoll等）的支撑下独立完成。
• GCD管理的普通工作线程默认不会主动启动RunLoop，任务执行完成后，线程会被放回线程池等待下次调度，或是在空闲超时后被销毁，整个生命周期不需要RunLoop参与。
• 不要混淆「每个线程可以拥有专属RunLoop」和「每个线程必然运行着RunLoop」：RunLoop是懒加载的，只有你主动调用CFRunLoopGetMain()/CFRunLoopGetCurrent()的时候才会为当前线程创建RunLoop对象，大部分GCD工作线程的整个生命周期里都不会生成RunLoop实例。

两者产生交互的特殊场景 #

只有在下面几种特定情况下，DispatchQueue才会和对应线程的RunLoop产生交互：

• 主队列（DispatchQueue.main）的特殊适配：主队列固定绑定主线程，而主线程的RunLoop是系统在应用启动时就默认开启的。libdispatch针对主队列做了专门适配，通过向主线程RunLoop注册自定义的Source0事件，在主队列有任务待执行时唤醒主线程RunLoop，在RunLoop的对应回调阶段执行队列里的任务。这是最常见的交互场景，但属于主队列的专属逻辑，不是所有队列的通用实现。
• 自定义常驻线程的绑定场景：如果你手动通过dispatch_queue_set_specific或者Target Queue机制，把某个DispatchQueue的执行上下文绑定到你自己创建的、已经开启RunLoop常驻的子线程上，这时候libdispatch会通过向该线程的RunLoop注册事件源的方式触发任务执行。这个场景需要开发者手动完成绑定，默认创建的全局队列、自定义串行/并发队列都不会走这个逻辑。
• 任务内主动调用RunLoop的场景：如果提交到GCD的任务代码里主动调用了RunLoop.current.run()，那么当前被GCD占用的工作线程会进入RunLoop循环，暂时不会归还给线程池，直到RunLoop退出。这也是很多开发者踩坑的来源：如果给这个RunLoop没有添加任何能维持生命周期的事件源（Port、Timer等），RunLoop会立刻空跑退出，根本实现不了线程常驻的效果。

常见认知误区 #

不要搞反两者的底层依赖关系：RunLoop本身的部分能力（比如主线程唤醒、GCD定时器的调度）反而是构建在libdispatch的能力之上的，libdispatch的调度链路比RunLoop更靠近系统底层，不存在「GCD靠RunLoop实现分发」的通用逻辑。

内容的提问来源于stack exchange，提问作者Grigorii