本文来自微信公众号： 宇众不同的露萱 ，作者：宇众不同的露萱

大概是在七八年前，我当时在学习 Unix 系统的内核代码，特别是 open ( ) 返回的那个简单至极的整数文件描述符（File Descriptor）。那时候身边不少做 Windows 开发的朋友，提到系统底层，嘴里永远绕不开一个词：HANDLE。

一个指针大小的 32 位或 64 位无符号整数，指向一个在用户态完全看不见的内核对象。

当时我其实有一个很粗暴的偏见：Windows 搞出 HANDLE，无非就是微软习惯了搞封装、搞抽象，非要把原本简单的整数索引包装成某种看起来很 " 面向对象 " 的东西。甚至在很长一段时间里，我都觉得它只是 C++ 时代产物下的某种过度设计。

直到后来我去翻早期微内核与操作系统设计的历史，尤其是阅读 Dave Cutler（Windows NT 的首席架构师）在 VMS 和 NT 时代的设计记录，我才意识到，我以前完全理解错了。

HANDLE 不是微软为了秀面向对象抽象而凭空发明出来的。它的出现，本质上是一场关于 " 谁有权解释内核内存 " 的死斗。

在 1980 年代末，Dave Cutler 带着一帮 DEC 的工程师被比尔 · 盖茨挖到微软开荒 Windows NT 时，他们面临的硬件环境和设计目标，和 Linus Torvalds 后来写 Linux 时有着微妙但决定性的不同。

当时的 Unix 哲学非常优雅，" 一切皆文件 "。你打开一个文件，系统给你一个 fd（实际上就是进程文件描述符表里的一个数组下标）。要读取数据？read ( fd,buff,size ) 。

这种设计在 C 语言的纯粹世界里美得像诗。但这种优雅建立在一个隐性假设上：所有的资源，在语义上都可以被抽象成字节流。

但 NT 设计之初，目标就不是只做一款 " 更好的 Unix"。微软当时要面对的是极其混乱的商业计算环境：要支持多处理器（SMP）、要支持复杂的进程间同步、要支持精细到用户级的权限控制，还要在同一个内核上模拟 POSIX、OS/2 和 Win32 多种子系统。

如果你去仔细看 NT 内核的对象管理器（Object Manager）设计，你会发现一个很残酷的事实：

在操作系统内核里，信号量（Semaphore）、互斥锁（Mutex）、命名管道（Named Pipe）、物理内存映射（Section Object）、甚至是进程（Process）和线程（Thread）本身，它们根本无法被平滑地抽象成 " 字节流 "。

一个线程对象，它有自己的执行上下文、挂起计数、优先级、亲和性掩码（Affinity Mask）。你不可能对一个线程去 read ( ) 或者 write ( ) 。

如果你强行把所有东西都套进文件描述符的壳子里，你很快就会碰到那个 Unix 社区折腾了几十年的老坑：ioctl ( ) 爆炸。所有无法用字节流表达的控制逻辑，最后都会变成一堆堆难以维护的二进制控制码。

如果不把所有资源都看作文件，那内核资源在用户态应该怎么表达？

最直白的做法，是直接给用户态返回一个内核对象的内存指针。

在 C 语言占据统治地位的年代，这种诱惑太大了。如果 CreateThread 直接返回一个 ETHREAD 结构体的指针，用户态程序要查询线程状态，直接 thread->State 读一下不就行了吗？连系统调用的开销都省了。

但 Cutler 他们在 DEC 时代就已经踩过这个血窟痛坑。

一旦你把内核结构的内存地址暴露给用户态，不管你加了多少层内存保护，用户程序就会不可避免地对这个地址产生依赖。哪怕你禁止写入，用户态代码也会开始依赖这个指针的偏置（Offset），依赖结构体里某个字段的大小。

后果就是：操作系统内核将永远无法重构。内核只要改动一个字段的位置，全天下所有的应用软件都会崩溃。

更致命的是安全。用户态进程是一个完全不可信的黑暗森林。如果传入一个指针，内核每次使用它，都必须做复杂的寻址检查、页面校验、抢占防御。如果用户态故意传进来一个精心构造的伪造指针，内核一不小心解引用，整个系统就直接 Blue Screen。

所以，内核必须建立一道绝对隔离的墙。

这就是 HANDLE 真正诞生的时刻。

在 Windows NT 的设计里，HANDLE 在逻辑上是一个间接表（Handle Table）的索引，但在语义上，它是一个携带了访问权限（Access Mask）的能力令牌（Capability Token）。

很多人以为 HANDLE 只是个指针掩码或者简单的数组下标，但其实它背后的机制非常硬核。

当你的进程调用 OpenProcess 时，内核做了三件事：

发现这个设计精妙的地方了吗？

用户态拿到的 HANDLE，本质上是一串没有任何物理意义的符号。你把它加一、减一、或者强转成指针，对内核来说毫无意义。

更重要的是，句柄是绑定在进程上下文里的。进程 A 里的 HANDLE 0x0000000C，和进程 B 里的 HANDLE 0x0000000C，在内核句柄表里指向的可能是完全不同的内核对象，拥有完全不同的权限。

当你拿着这个 HANDLE 调用 TerminateProcess 时，内核做的事情不是 " 去执行终止动作 "，而是拿着你的句柄去查表：

这个句柄存在吗？不存在，返回错误。

这个句柄指向的是进程对象吗？类型不对，返回错误。

这个句柄在创建时，是否赋予了 PROCESS_TERMINATE 权限？没有，拒绝访问。

三关过完，内核才会真正解引用那个内部指针。

这种设计在当年付出了不小的代价——每一次通过 HANDLE 操作内核资源，都必须经过一次查表和权限硬校验，带来了一点点性能损耗。但是在工程上，它换来了一个极度可怕的优势：系统的强壮性与可演进性。

微软可以在 Win95 到 Win11 的三十年间，把内核里的 EPROCESS 结构体改得妈都不认识，添加无数个调试字段，修改无数次内存布局，而上层的 Win32 应用程序完全不需要重新编译。因为应用程序手里只有 HANDLE，它永远触碰不到内核结构的真相。

这种 " 用间接性（Indirection）换取解耦与安全 " 的思路，后来的很多高并发和虚拟化系统都在沿用。

但是，如果只把 HANDLE 理解成 " 带权限的间接指针 "，其实只理解了一半。

HANDLE 能够支撑起整个 Windows 生态，最重要的另一个拼图，是 NT 内核强行抽离出的统一同步模型：WaitForSingleObject/WaitForMultipleObjects。

在 Unix 世界里，很多年来，同步机制都是碎片化的。你等一个文件可读用 select/poll；你等一个子进程退出用 waitpid；你等一个信号量用 sem_wait。它们是完全不同的范式，很难优雅地组合在一起。

而在 Windows 里，所有内核对象在头头部都有一个共同的底层结构：DISPATCHER_HEADER。

不论是进程、线程、事件（Event）、定时器（Timer）、还是互斥量（Mutex），只要它们是内核对象，内部都有这个 Header。这意味着，它们都可以处于两种状态之一：Signaled（有信号）或 Nonsignaled（无信号）。

这就导致了一个极其优雅的工程结果：

应用层不需要关心这个 HANDLE 到底是一个耗时下载的网络套接字、一个正在运行的后台线程、还是一个等待触发的定时器。只要它是一个 HANDLE，你就可以直接把它扔进 WaitForMultipleObjects。

" 当这三个线程结束、或者这个定时器超时、或者这个互斥量被释放，只要其中任意一个发生，就唤醒我。"

这种把所有异步和同步原语统一步骤的设计，在 1990 年代初的操作系统领域，是极其震撼的。它把复杂的多线程并发控制，收拢到了极少数几个统一的 API 上。

那这个设计是完美的吗？当然不是。

天下没有免费的午餐，HANDLE 的代价同样深刻地影响了 Windows 的生态。

首先是资源泄漏的诊断成本极其高昂。在 Unix 上，fd 泄露通常很容易定位，因为就那么几个文件。但在 Windows 上，因为一切皆可 HANDLE，当一个大型程序运行几天出现 " 句柄泄漏 " 时，你面对的是几万个不知名的内核对象。你根本不知道这个 leaked handle 到底是个没关的事件，还是某个第三方 SDK 偷偷创建却忘了释放的线程句柄。

其次，句柄表变成了进程间通信的天然壁垒。因为 HANDLE 是强绑在进程私有句柄表里的，你想把一个句柄传给另一个进程使用，你不能直接发个整数过去。你必须调用极其繁琐的 DuplicateHandle API，让内核在目标进程的句柄表里也拷贝一份槽位。这种设计极大地增加了进程间协同（IPC）的编写复杂度。

更有意思的是，近十年来，随着高性能网络和 I/O 时代的到来，传统基于 HANDLE 的同步机制也开始显现疲态。

WaitForMultipleObjects 有一个写死在内核里的致命限制：最多只能同时等待 64 个句柄（MAXIMUM_WAIT_OBJECTS）。

当现代服务器需要处理数万个并发连接时，这种基于对象句柄的等待模型彻底崩塌了。微软不得不后来引入了 IOCP（I/O 完成端口），乃至近年来在 Windows 上推行类似 io_uring 的 IORING 机制，以此来绕过句柄检索的巨大开销。

现在回看历史，有时候挺有意思的。

Linux 在经历了几十年的发展后，也遇到了同样的困境。比如：如何安全地管理进程？早期 Linux 依靠 PID 杀进程，但 PID 会重用。如果在你发信号的瞬间，目标进程刚好退出了，新进程用了同一个 PID，你就会误杀一个完全无关的进程。

为了解决这个问题，Linux 在内核 5.1 引入了 pidfd_open ——通过一个文件描述符来代表一个进程。

当 Linux 开始把进程、定时器（timerfd）、信号（signalfd）、甚至是事件（eventfd）全都封装成 fd，并且在 fd 上附加各种 anon_inode 和权限检查时……

你仔细想想，这不就是换了个名字的 HANDLE 吗？

技术演进到最后，大路通天，大家终究会在同一个物理约束面前相遇。

Unix 选择了 " 一切皆文件 "，最后为了解决复杂对象的管理，把 fd 演变成了能力令牌；Windows 选择了 " 一切皆对象 "，通过 HANDLE 直接把能力令牌做成了底座，代价是承载了数十年的对象系统包袱。

没有哪一种是天生高贵的 " 优雅 "，有的只是工程团队在特定历史时期，为了应对特定复杂度所做出的权衡和妥协。