c# SafeHandle 和 CriticalFinalizerObject 在并发资源管理中的作用_技术教程

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);
    }
}