临界区 vs Thread.Abort()：如何保护锁代码免受线程中止影响？

首先得明确一点：Thread.Abort()本质上就是个不安全的API——微软早就不推荐使用它了，因为它能在代码执行的任意位置抛出ThreadAbortException，而且这个异常哪怕被catch也会自动重新抛出，很容易搞出资源泄漏、锁不一致这种棘手问题。你的问题本质上就是这个API的设计缺陷带来的。

分析你的两种实现问题 #

最初的实现 #

private IDisposable GetLock() { _lock.Wait(); return new Disposable(()=> _lock.Release()); }

这里的风险点非常明确：当线程在_lock.Wait()成功获取锁之后、return返回Disposable之前被Thread.Abort()击中，锁已经被持有，但调用方根本没拿到那个能释放锁的Disposable，结果就是锁永远被卡住，后续线程都拿不到，直接导致状态不一致甚至死锁。

改进后的实现 #

private IDisposable GetLock() { 
    var l = _lock; 
    l.Wait(); 
    try { 
        var result = new Disposable(()=> _lock.Release()); 
        l = null; 
        return result; 
    } finally { 
        l?.Release(); 
    } 
}

你试图用l=null来避免finally重复释放，但Thread.Abort()可能在l=null和return之间触发——这时候l已经是null了，finally不会释放锁，但调用方也没拿到Disposable，锁就永远被持有了。另外，如果Disposable被意外多次调用Dispose，还可能导致_lock.Release()被执行多次，引发锁状态混乱。

解决方案 #

最优方案：抛弃Thread.Abort()，改用协作式取消 #

最根本的解决办法是彻底放弃使用Thread.Abort()，改用.NET官方推荐的协作式取消机制（CancellationToken）。协作式取消是让线程在安全的检查点主动响应取消请求，而非被强制打断。

比如，你可以把锁的获取改成支持取消的版本（以SemaphoreSlim为例）：

private IDisposable GetLock(CancellationToken token)
{
    _lock.Wait(token); // 等待锁时响应取消信号
    bool isDisposed = false;
    return new Disposable(() =>
    {
        lock (this) // 加锁确保线程安全，避免重复释放
        {
            if (!isDisposed)
            {
                isDisposed = true;
                _lock.Release();
            }
        }
    });
}

这种方式下，线程永远不会被强制打断，所有锁的获取和释放都是可控的，从根源上避免了锁不一致的问题。

迫不得已的妥协：用CER保护关键区域 #

如果你的场景必须兼容Thread.Abort()（比如维护老代码），可以用.NET的**受约束执行区域（CER）**来标记关键代码段，CLR会确保CER内的代码不会被Thread.Abort()或内存不足中断。

实现示例：

using System.Runtime.CompilerServices;

private IDisposable GetLock()
{
    bool lockAcquired = false;
    IDisposable disposable = null;

    try
    {
        RuntimeHelpers.PrepareConstrainedRegions();
        try
        {
            _lock.Wait();
            lockAcquired = true;
            // CER内的代码要尽量简单，避免复杂内存分配或非CER兼容调用
            disposable = new Disposable(() =>
            {
                lock (this)
                {
                    if (lockAcquired)
                    {
                        lockAcquired = false;
                        _lock.Release();
                    }
                }
            });
        }
        finally
        {
            // 若锁已获取但Disposable未创建成功，主动释放锁
            if (lockAcquired && disposable == null)
            {
                _lock.Release();
                lockAcquired = false;
            }
        }

        return disposable;
    }
    catch (ThreadAbortException)
    {
        // 若在return前被中止，确保锁被正确释放
        if (lockAcquired && disposable != null)
        {
            _lock.Release();
            lockAcquired = false;
        }
        // 可选：重置中止，但谨慎使用——可能引发其他未知问题
        Thread.ResetAbort();
        throw;
    }
}

注意：CER有严格限制，内部不能分配大量内存、不能调用非CER兼容的方法，否则CLR无法保证代码执行的原子性。同时要确保你的_lock的Wait()方法是CER兼容的（比如Monitor.Enter或SemaphoreSlim.Wait）。

额外注意事项 #

• 永远不要让Thread.Abort()成为常规的取消手段，它应该只作为极端情况下的最后选择。
• 所有锁的释放逻辑都要加线程安全保护（比如lock或原子变量），避免重复释放导致的状态混乱。
• 如果你用的是自定义锁实现，确保它的Wait()和Release()方法本身是线程安全的，并且能正确处理异常情况。

内容的提问来源于stack exchange，提问作者eocron