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

真正容易被忽略的是：SafeHandle 的线程安全性仅限于“自身释放逻辑的执行保障”，它不提供句柄所代表资源的并发访问保护。写并发代码时，该加锁的地方一个都不能少，别被“Sa

fe”二字带偏了方向。