在lock代码块内将异步逻辑移至独立方法是否安全？

先看一段基于双重检查锁实现的非异步懒加载代码，确保昂贵资源仅由首个线程完成初始化：

public class LazyExample
{
    private object ExpensiveResource = null;

    private object ExpensiveResourceSyncRoot = new object();

    public object GetExpensiveResource()
    {
        if (ExpensiveResource != null) // Checkpoint 1
            return ExpensiveResource;

        lock (ExpensiveResourceSyncRoot) // 首次会有一批已通过Checkpoint 1的线程在此排队
        {
            if (ExpensiveResource != null) // 阻止后续通过Checkpoint 1的线程重复初始化
                return ExpensiveResource;

            // 先创建资源实例，暂不赋值
            object expensiveResource = new object();

            // 同步初始化资源（示例操作）
            // - 调用API...
            // - 查询数据库...
            Thread.Sleep(1); 

            // 锁释放前的最后一步，赋值完全初始化好的资源
            ExpensiveResource = expensiveResource;
        }

        return ExpensiveResource;
    }
}

由于项目异步调用增多，而lock代码块内无法直接使用await，于是将异步逻辑封装到独立方法，修改后的代码如下：

public class LazyExample
{
    private object ExpensiveResource = null;

    private object ExpensiveResourceSyncRoot = new object();

    public async Task<object> GetExpensiveResourceAsync()
    {
        if (ExpensiveResource != null) // Checkpoint 1
            return ExpensiveResource;

        lock (ExpensiveResourceSyncRoot) // 首次会有一批已通过Checkpoint 1的线程在此排队
        {
            if (ExpensiveResource != null) // 阻止后续通过Checkpoint 1的线程重复初始化
                return ExpensiveResource;
            
            // 赋值完全初始化好的资源
            ExpensiveResource = CreateAndInitializeExpensiveResourceAsync().Result;
        }

        return ExpensiveResource;
    }

    private async Task<object> CreateAndInitializeExpensiveResourceAsync()
    {
        object expensiveResource = new object();

        // 异步初始化资源（示例操作）
        await Task.Delay(1);

        return expensiveResource;
    }
}

实际使用中这种写法会随机出现死锁问题，只能用ExpensiveResource = Task.Run(CreateAndInitializeExpensiveResourceAsync).Result;规避，但这会强制逻辑在新线程运行，带来额外开销。现疑问：在lock代码块内将异步逻辑移至独立方法（即新栈帧）是否安全？是否确实违背了安全机制？

核心结论 #

这种写法并非“违背安全机制”，但完全不安全，问题根源不在“把异步逻辑移到独立方法”，而在于同步阻塞调用.Result的操作。

死锁的本质原因 #

在带await的异步方法中，默认会捕获当前的SynchronizationContext（比如UI线程上下文、传统ASP.NET上下文）。当你在lock块内调用.Result时：

1. 主线程进入lock后调用CreateAndInitializeExpensiveResourceAsync()，执行到await Task.Delay(1)时方法挂起，返回一个未完成的Task。
2. 主线程调用.Result同步等待这个Task完成，此时主线程被阻塞，且仍持有lock。
3. 当Task.Delay(1)完成后，异步逻辑需要回到之前捕获的SynchronizationContext继续执行，但主线程正被.Result卡死，无法处理后续逻辑，最终形成循环等待，触发死锁。

把异步逻辑移到独立方法只是改变了栈帧结构，完全没解决.Result同步阻塞+上下文捕获的核心矛盾，所以死锁依然会发生。

为什么Task.Run能规避死锁？ #

Task.Run会把异步逻辑放到线程池线程执行，此时await捕获的是线程池的无特定同步上下文。异步逻辑完成后，不需要回到原来的主线程，直接在线程池线程上完成Task，主线程的.Result就能正常获取结果，不会形成循环等待。但这种方式确实会额外占用线程池线程，带来不必要的开销。

正确的异步懒加载实现 #

应该使用专门的异步懒加载工具类Lazy<Task<T>>，它天然支持异步场景下的双重检查语义，不需要手动加lock：

public class LazyExample
{
    private readonly Lazy<Task<object>> _lazyExpensiveResource = new Lazy<Task<object>>(CreateAndInitializeExpensiveResourceAsync);

    public Task<object> GetExpensiveResourceAsync()
    {
        return _lazyExpensiveResource.Value;
    }

    private static async Task<object> CreateAndInitializeExpensiveResourceAsync()
    {
        object expensiveResource = new object();
        await Task.Delay(1); // 异步初始化逻辑
        return expensiveResource;
    }
}

Lazy<Task<T>>会确保初始化方法只被调用一次，同时完全适配异步流程，彻底避免手动锁和同步阻塞带来的死锁风险。

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