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”二字带偏了方向。 
