CLR线程概览（下）

作者：施懿民
链接：https://zhuanlan.zhihu.com/p/20866017
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

同步: 托管代码

托管代码可以访问很多在System.Threading里定义的同步原语。包括操作系统原语的简单封装如：互斥（Mutex），事件（Event）和旗标（Semaphore）对象，也包括类似的栅栏（Barrier）和自旋锁（SpinLock）等抽象。但托管代码用的最多的同步机制是System.Threading.Monitor，其提供了针对 任意托管对象 的高性能同步锁机制，还提供了被其保护的状态发生变化时的通知机制的“条件变量”语义。

Monitor是通过一个“混合锁”来实现的，其有自旋锁和类似互斥（Mutex）这些基于操作系统内核锁的功能。这个思路源自于大部分锁都是短暂获取的，因此自旋等待锁被释放的所耗费的时间比调用内核API从而阻塞线程更少。当然将CPU的时钟周期浪费在自旋上也是很严重的，因此如果锁在一段时间内没有被释放的话，那么CLR则会退回到调用内核API的实现上。

因为任意一个对象都是潜在的锁／条件变量，每个对象都需要有一个地方用来保存锁信息。这个就是在“对象头（object headers）”和“同步块（sync blocks）”里完成的。

对象头是一个在每个托管对象前面机器字长大小的字段。它在很多地方会用到，例如保存对象的哈希值。其中一个目的就是保存对象的锁状态。如果对象头需要保存更多的信息，我们通过创建一个“同步块”的方式扩充对象。

同步块保存在同步块表（Sync Block Table）里，通过同步块索引来寻址。对象的同步块索引保存在对象头里。

关于对象头和同步块的细节在syncblk.h/.cpp里定义。

如果对象头里还有空间，Monitor将锁住对象的线程的托管线程ID（如果没有线程锁住对象则是0）保存在其中。在这种情形下，获取锁的过程其实就是自旋等待对象头的线程ID为0，然后原子操作设置其值为当前线程的托管线程ID。

如果自旋一些次数后还不能获取锁，或对象头已经用作其它目的，那么就会为这个对象创建同步块。它包含一些额外数据，包括用来阻塞当前线程的事件对象，这样运行我们停止自旋并等待锁被释放。

一个用来作为条件变量的对象（通过Monitor.Wait 和 Monitor.Pulse）总是会被扩充的，因为同步块里已经没有足够的空间来保存必要的状态。

同步: 原生情况

CLR的原生部分也必须要有线程意识，因为其可能在多个线程上调用托管代码。这样要求原生的同步机制，例如锁，事件等等。

ITaskHost API 允许一个CLR宿主修改托管线程的很多方面，包括线程的创建、销毁和同步。这种允许宿主修改原生同步机制要求虚拟机的代码不能直接使用原生的同步原语（即临界区，互斥锁，事件等），而是需要使用虚拟机在其上的封装）。

除了上述细节之外，GC悬停是一个特殊的“锁”，而且几乎影响CLR的方方面面。如果必须处理GC堆上的对象，虚拟机的原生代码可能要进入“合作”模式，这样“GC悬停锁”就变成原生虚拟机代码里最重要的同步机制，在托管世界里也一样。

原生虚拟机代码里主要用到的同步机制是GC模式和Crst。

GC 模式

如上所述，所有托管线程都在合作模式中运行，因为其可能操作GC堆。一般来讲，原生代码不会碰托管对象，因此运行在优先模式。但有些虚拟机里的原生代码需要访问GC堆，需要运行在合作模式。

原生代码通常不会直接操作GC模式，而是通过两个宏：GCX_COOP and GCX_PREEMP 来进入期望的模式，并创建“支持物”以便线程在退出范围的时候返回到之前的模式。

需要注意的是GCX_COOP从GC堆上获取一个锁。在线程处于合作模式时，不能执行GC。而且原生线程也不能像托管线程那样被“劫持”，因此线程在切换回优先模式时都是处于合作模式。

因此在原生代码里进入合作模式是不被鼓励的。如果必须要进入合作模式，那么时间越短越好。线程在此模式时不能被阻塞，而且实际上不能安全的获取锁。

类似的，GCX_PREEMP 释放 线程拥有的锁。在进入优先模式之前必须要万分小心来确保所有GC引用都被妥善保护。

代码规范 文档描述了安全进行GC模式切换的必要原则。

Crst

正如Monitor对象是托管代码里推荐的锁机制，Crst是虚拟机代码里的推荐机制。与Monitor类似，Crst是一个知道宿主和GC模式的混合锁。Crst通过“层级锁”机制来规避死锁，该实现可参考 BotR的层级锁章节.

虽然有一些必须这么做的异常情况，在合作模式下获取一个Crst锁通常是不合适的。

特殊线程

除了托管代码创建的托管线程，CLR自身还创建了一些“特殊”线程。

终结者（Finalizer）线程

每个进程都创建了这个线程用来运行托管代码。当GC决定一个可终结（finalizable）的对象不再被引用，其将该对象置于终结队列。当GC结束后，终结者线程会被唤醒并处理队列里的所有终结对象。对象一个一个出列，其终结（finalizer）函数被依次调用。

该线程还用来处理一些CLR内部的清理工作，并等待一些外部事件通知（如低内存情形下，GC会被告知尽量凶悍的回收垃圾）。详情请参见GCHeap::FinalizerThreadStart。

GC 线程

当运行在“并行”或“服务器”模式时，GC创建一个或多个后台线程来并行执行垃圾回收的不同阶段。这些线程完成由GC管理，而且永远不会执行托管代码。

调试器线程

CLR为每个托管进程维护了一个原生线程，其用来在附加到托管调试器时执行多个调试操作。

应用程序域卸载线程

这个线程负责卸载应用程序域。其通过一个单独的CLR内部线程，而不是在请求卸载应用程序域的线程里完成。因为 a) 为卸载过程提供受保证的堆栈空间，b) 在必要时允许请求卸载的线程从应用程序域里向上展开。

线程池线程

CLR线程池维护一个托管线程集合用来执行用户的“工作”。这些托管线程都绑定到线程池管理的原生线程。线程池还维护一小部分的原生线程来处理类似“线程注入”，定时器以及“已注册的等待”等等功能。