Solaris转门机制仍影响Go与Rust

Sun Microsystems 的 Solaris 已不再是主流操作系统，但它留下的底层工程思想仍在现代软件中延续。Slab 分配器通过复用预初始化对象降低内核分配成本和碎片率，OpenZFS 将文件系统与卷管理结合并引入校验、自修复，DTrace 推动了内核与用户态动态追踪，Zones 则较早实践了操作系统级隔离。

在这些技术之外，Solaris 的转门（turnstile）机制同样重要。它主要面向阻塞式互斥锁，试图在低延迟和软实时需求下，解决锁数量庞大带来的内存开销，以及高优先级线程等待低优先级线程持锁时可能出现的优先级反转。

其做法是把等待队列等状态从锁对象中移出。线程创建时预先拥有转门，发生锁竞争并阻塞时再把转门关联到目标锁；内核通过以锁虚拟地址为键的全局哈希表查找相关等待关系。这样无竞争锁可以保持极小体积，通常只需一个字节或一个机器字，但高竞争场景会引入哈希桶查找、总线同步和桶锁竞争等额外成本。

类似思路后来出现在多种现代运行时中。Go 运行时需要支撑大量 goroutine，因此不会在每个互斥量、锁或 channel 操作里内置等待队列，而是通过 sema.go 中的运行时信号量和全局 semtable，将同步点地址哈希到对应的 semaRoot，再把代表 goroutine 的 sudog 挂入等待结构。

浏览器引擎也采用了状态外置的设计。WebKit 的 WTF::ParkingLot 将线程挂起、唤醒逻辑放入全局并发哈希表，使 WTF::Lock 等锁对象无需携带大型系统互斥量或条件变量状态，从而减少无竞争锁的常驻成本。

Rust 生态中的 parking_lot crate 也延续了这一模式，它以锁地址为键维护外部全局等待队列，让同步原语保持小体积，并在性能、公平性上优于许多标准系统同步设施。总体来看，Solaris 转门机制的核心原则仍未过时：把复杂的线程协调集中到共享结构中，让单个锁尽可能轻量、快速。