虽然 Sun Microsystems 的 Solaris 如今已基本退出历史舞台，但它的技术遗产仍深刻影响着现代系统工程。Solaris 首创的多项技术，悄然塑造了当代操作系统、Web 浏览器和语言运行时的架构，并成为如今高性能软件体系中沿用至今的基础设计范式。
以内存管理和存储为例。Slab 分配器最初为 Solaris 发明，通过缓存预先初始化的内核对象，大幅降低了分配开销和内存碎片，并成为现代内核和数据库的设计范本。同样，OpenZFS将文件系统与逻辑卷管理器结合起来，并引入自动校验和与数据自修复功能，革新了存储系统。DTrace则改变了系统可观测性：这一动态追踪框架能够实时检查运行中的内核和用户空间，并直接启发了 Linux eBPF 等现代工具。此外，早在容器化成为云基础设施主流之前，Solaris 就推出了 Zones，开创了安全的操作系统级虚拟化技术。
除了这些突破，Solaris 还催生了转门（turnstile）机制。这是一种巧妙的同步机制，旨在解决阻塞式互斥锁的开销和优先级反转问题。
Solaris 大量依赖阻塞式互斥锁，以实现低延迟的软实时行为，但这带来了两大难题。首先，细粒度锁需要成千上万个小型锁；如果在每把锁中都嵌入大量管理数据，就会浪费大量内存。其次，当高优先级任务等待低优先级任务持有的锁，而后者又被中优先级任务抢占时，就会发生优先级反转，可能导致系统无限期停滞。为了在不增大锁体积的情况下解决这一问题，内核会采用优先级继承，暂时提高锁持有者的优先级，但高效追踪依赖链一直很困难。
转门机制通过将等待状态与单个锁结构分离来解决这个问题。每个线程在创建时都会分配一个转门。当线程因锁竞争而阻塞时，它会将预先分配的转门交给该锁，并通过一张以锁的虚拟地址为键、按桶组织的全局哈希表建立映射。这样既能动态遍历优先级继承关系，又能让没有发生竞争的锁保持极小的体积，通常只需一个字节或一个机器字。不过，这也带来了典型的工程权衡：为了尽量减少每把锁占用的内存，高竞争情况下的锁操作需要以全局哈希桶查找和更多总线同步，取代对本地缓存的访问，并可能因哈希桶的锁竞争而遇到瓶颈。
这一架构思路深深延续到了现代软件中，影响着语言运行时、浏览器引擎和用户空间程序库。
在 Go 中，运行时需要管理数百万个 goroutine 的大规模并发，同时避免让每个同步原语都背负庞大的状态开销。Go 通过内部运行时信号量实现这一点，相关实现位于 Go 运行时的 sema.go。Go 不会在每把锁、每个互斥量或每次 channel 操作中嵌入等待队列，而是使用一张名为 semtable 的全局根节点表。当 goroutine 在某个同步点阻塞时，运行时会对该同步点的内存地址进行哈希计算，找到对应的 semaRoot 桶，再将代表该 goroutine 的 sudog 结构链接到该桶的等待树中。这使相关开销完全外置，让同步变量保持轻量，也让 Go 能够在不付出额外内存代价的情况下高效扩展。
对于 Web 浏览器，内存效率和加锁速度同样至关重要，因此浏览器引擎也采用了相同的状态分离思路。WebKit 为此引入了 WTF::ParkingLot，一种可移植的用户态线程挂起机制。WebKit 没有让 WTF::Lock 之类的锁携带庞大的操作系统互斥量或条件变量状态，而是将标准锁缩减到很小的体积。当线程必须阻塞时，它会在 ParkingLot 管理的全局并发哈希表中登记其地址，从而将自己“挂起”。这将锁本身与线程休眠、唤醒机制彻底分离，消除了无竞争锁的冗余开销。
这一设计模式也深刻影响了浏览器和托管运行时之外的用户空间生态。一个典型例子是 Rust 的 parking_lot crate，它明确将 WebKit 的 ParkingLot 设计移植到了 Rust 生态中。该 crate 在外部维护一张以锁地址为键的全局等待队列哈希表，使同步原语保持极小体积，同时提供优于标准操作系统同步原语的性能和公平性。
在所有这些现代环境中，其基本原则都与 Solaris 早期的转门机制相同：将线程协调的繁重工作集中到共享的外部数据结构中，让每把锁都保持精简、快速且低成本。
原文链接：https://www.infoq.com/news/2026/09/turnstile-system-design/
