SafeHandle 通过构造时标记“已拥有”和在 CER 中强制执行 ReleaseHandle() 避免句柄泄漏；它不保证资源访问线程安全，需业务层同步，且不可在 ReleaseHandle() 中抛异常或调用非 CER 方法。
SafeHandle 为什么能避免句柄泄漏
在多线程环境下直接用 IntPtr 管理 Windows 句柄（如文件、事件、互斥体）极易出问题：线程可能在 Dispose() 调用前被中止，或 GC 在析构时发现句柄已被关闭，导致重复释放或访问无效句柄。而 SafeHandle 通过两个关键机制堵住这些漏洞：构造时标记句柄为“已拥有”、Finalize 阶段保证调用 ReleaseHandle()，且该释放逻辑运行在 CriticalFinalizerObject 保障的受限执行区域（CER）内。
实操建议：
- 继承
SafeHandle时必须重写IsInvalid（判断句柄是否无效，如handle == IntPtr.Zero || handle == new IntPtr(-1)）和ReleaseHandle()（执行CloseHandle()或对应 API） - 构造函数里必须调用基类
base(isInvalid: false, ownsHandle: true)，否则 GC 不会触发最终释放 - 不要在
ReleaseHandle()中抛异常——CER 内未处理的异常会终止进程
CriticalFinalizerObject 的实际约束边界
CriticalFinalizerObject 本身不管理资源，它是 SafeHandle 的父类之一，作用是**确保其 Finalize 方法能被调度执行**，哪怕在 AppDomain 卸载、线程中止或宿主强制回收等极端条件下。但它不解决并发安全——ReleaseHandle() 仍可能被多个终结器线程并发调用。
常见错误现象：
- 自定义
SafeHandle子类中在ReleaseHandle()里调用了非 CER 兼容代码（如Marshal.AllocHGlobal、任意托管对象分配、锁竞争），导致运行时拒绝执行并静默跳过释放 - 误以为继承
CriticalFinalizerObject就自动线程安全——其实ReleaseHandle()无内置同步，需自行用Interlocked.CompareExchange或静态object锁保护共享状态
并发场景下 SafeHandle 的正确使用姿势
多数人以为只要用了 SafeHandle 就高枕无忧，但实际并发资源访问（如多个线程同时读写同一文件句柄）仍需额外同步。SafeHandle 解决的是“生命周期终点”的可靠性，不是“生命周期中段”的线程安全。
使用场景与参数差异：
- 若封装的是可共享句柄（如
CreateEvent返回的跨进程事件），多个线程可安全调用Set()/WaitOne()—— 因为 Win32 事件本身是线程安全的；但若封装的是不可共享句柄（如CreateFile打开的独占文件），则需在业务层加锁，不能依赖SafeHandle自身 -
SafeHandle.DangerousGetHandle()返回原始IntPtr，一旦暴露给非托管代码或跨线程传递，就脱离了 SafeHandle 的保护范围，此时必须确保调用方严格配对CloseHandle()，否则泄漏 - 在
async方法中持有SafeHandle实例时，注意不要在 await 后继续使用已释放的句柄——SafeHandle 不阻止你犯这种错
为什么不能绕过 SafeHandle 直接用 IntPtr + finalizer
手动实现 finalizer（如重写 Object.Finalize()）看似灵活，但无法获得 CER 保证：.NET 运行时可能在 AppDomain 卸载期间跳过你的 finalizer，尤其当存在大对象堆压力或宿主（如 SQLCLR、IIS）主动抑制终结队列时。而 SafeHandle 是唯一被运行时特殊标记、强制排队执行的句柄包装类型。
性能与兼容性影响：
- .NET Core 3.0+ 对
SafeHandle做了优化，终结器调用延迟显著降低，但仍有约 1–2 秒窗口期（取决于 GC 周期），因此绝不能依赖 Finalize 作为主要释放路径，必须坚持显式Dispose() - 在 .NET Framework 中，若自定义 finalizer 抛异常，整个终结器线程会崩溃；而
SafeHandle.ReleaseHandle()抛异常会被捕获并记录到AppDomain.UnhandledException，不中断其他终结操作
public sealed class SafeFileHandle : SafeHandle
{
public SafeFileHandle(IntPtr preexistingHandle, bool ownsHandle)
: base(IntPtr.Zero, ownsHandle)
{
SetHandle(preexistingHandle);
}
public override bool IsInvalid => handle == IntPtr.Zero;
protected override bool ReleaseHandle()
{
// 注意：此处不能 throw，不能调用任何非 CER 方法
return Interop.Kernel32.CloseHandle(handle);
}
}
真正容易被忽略的是：SafeHandle 的线程安全性仅限于“自身释放逻辑的执行保障”，它不提供句柄所代表资源的并发访问保护。写并发代码时，该加锁的地方一个都不能少，别被“Safe”二字带偏了方向。 
