跨异步代码块使用AutoResetEvent是否安全？现有实现存隐患吗？

我尝试给一段同步代码加锁，在异步代码块（任务执行完成后）释放锁。了解到AutoResetEvent后，想在调用方与被调用方之间实现信号功能——目标是锁定验证交易是否已处理的代码段，待检查完成并保存交易后释放锁；检查与保存操作是异步的，锁释放在ContinueWith委托中完成。

以下是AutoResetEvent的抽象与实现代码：

public interface IThreadLockKeyProvider 
{ 
    public AutoResetEvent PayLock { get;  } 
}

public class ThreadLockKeyProvider : IThreadLockKeyProvider
{
    public static readonly AutoResetEvent _payLock;

    static ThreadLockKeyProvider()
    {
        _payLock = new AutoResetEvent(true);
    }

    public AutoResetEvent PayLock { get { return _payLock; } }
}

该实例以单例形式注入.NET Core依赖注入容器。

EventHandler方法代码：

public Task<Unit> Handle(ProcessPaymentCommand command, CancellationToken cancellationToken)
{ 
    _threadLockKeyProvider.PayLock.WaitOne();
    var res = _brandDepositStrategy.AdministerDeposit().Result; 
    return Task.FromResult(Unit.Value);
}

释放锁的AdministerDeposit方法代码：

public override async Task<Task> AdministerDeposit()
{
    Task<PaymentTransactions> dbOperation = _transactionAdministrationFacade.UpdateDbTransactionAsync(_IPNRequestDto);

    return await dbOperation.ContinueWith(async x =>
    {
        _threadLockKeyProvider.PayLock.Set();

        if (x.IsFaulted)
            throw x.Exception;

        _transactionAdministrationFacade.CallBackDto = await _responseComposer.GetPaymentResponseDto(x.Result, _IPNRequestDto);

        await CreateDepositSF();
    });
}

目前代码可正常运行且通过单元测试，但想确认该实现是否存在问题？

你的实现存在几个关键问题，虽然当前能运行，但在高并发或复杂场景下可能引发严重问题：

1. 同步阻塞导致性能与死锁风险 #

在Handle方法中使用.Result强制阻塞当前线程等待异步任务完成，违背了异步编程的初衷，会浪费线程池资源。尤其在ASP.NET Core环境中，这种阻塞可能导致线程池耗尽，甚至引发死锁（比如异步任务需要回到原上下文时）。

2. ContinueWith使用不当 #

• ContinueWith中传入async委托会返回Task<Task>，当前Handle方法只调用一次.Result，意味着后续的GetPaymentResponseDto和CreateDepositSF操作可能未完成，方法就已返回，业务逻辑执行不完整。
• ContinueWith默认不捕获当前上下文，在需要上下文的场景（比如ASP.NET Core的HttpContext）会引发异常。
• 用await替代ContinueWith，代码可读性和可靠性更高。

3. 锁释放时机错误 #

你在数据库操作完成后立即调用Set释放锁，但后续还有GetPaymentResponseDto和CreateDepositSF两个异步操作——这部分代码未被锁保护，不符合你“检查完成并保存交易后释放锁”的目标（实际保存交易后还有后续业务操作）。若此时有新请求进入，会在后续操作完成前进入临界区，可能引发数据不一致。

4. 同步原语不适用于异步场景 #

AutoResetEvent是同步原语，WaitOne会阻塞线程。异步编程中应使用支持异步等待的同步原语，比如SemaphoreSlim（支持WaitAsync方法），避免线程阻塞，提升系统吞吐量。

改进后的代码示例 #

1. 替换锁原语为SemaphoreSlim #

public interface IThreadLockKeyProvider 
{ 
    public SemaphoreSlim PayLock { get;  } 
}

public class ThreadLockKeyProvider : IThreadLockKeyProvider
{
    public static readonly SemaphoreSlim _payLock;

    static ThreadLockKeyProvider()
    {
        // 初始计数为1，代表同时允许1个线程进入临界区
        _payLock = new SemaphoreSlim(1, 1);
    }

    public SemaphoreSlim PayLock { get { return _payLock; } }
}

2. 修改Handle方法为全异步 #

public async Task<Unit> Handle(ProcessPaymentCommand command, CancellationToken cancellationToken)
{ 
    await _threadLockKeyProvider.PayLock.WaitAsync(cancellationToken);
    try
    {
        await _brandDepositStrategy.AdministerDeposit(cancellationToken);
    }
    finally
    {
        _threadLockKeyProvider.PayLock.Release();
    }
    return Unit.Value;
}

3. 重构AdministerDeposit方法，去掉ContinueWith #

public override async Task AdministerDeposit(CancellationToken cancellationToken)
{
    var dbResult = await _transactionAdministrationFacade.UpdateDbTransactionAsync(_IPNRequestDto, cancellationToken);
    
    _transactionAdministrationFacade.CallBackDto = await _responseComposer.GetPaymentResponseDto(dbResult, _IPNRequestDto, cancellationToken);
    
    await CreateDepositSF(cancellationToken);
}

关键改进点说明 #

• 用SemaphoreSlim的WaitAsync替代AutoResetEvent的WaitOne，实现异步等待，避免线程阻塞。
• 使用try/finally确保锁一定会被释放，即使出现异常也不会导致锁一直持有。
• 去掉.Result和ContinueWith，全程用await实现异步流程，保证业务逻辑完整执行，同时提升代码可读性。
• 将锁的释放逻辑统一放在Handle方法的finally块中，确保所有临界区操作（包括后续异步步骤）完成后再释放锁，符合业务需求。

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