C#多线程编程中跨线程读取闭包捕获的局部变量是否安全？

这种写法不存在始终可行的保证，看似能跑通只是测试场景下的偶然情况，本质是典型的未定义数据竞争行为。

两个语言对局部变量跨lambda捕获的实现逻辑完全不同，这是语法表现差异的根本原因：

• Java 早期要求跨线程访问的局部变量必须添加final修饰，本质是Java的lambda/匿名内部类捕获规则为值拷贝：将局部变量的值复制一份存入匿名类的私有字段，为了避免拷贝值和原变量出现不一致，直接禁止对捕获的变量做修改；即便现在Java支持effectively final，依然遵循值拷贝逻辑，从语法层面就不允许在捕获后修改变量值。
• C# 的lambda闭包采用完全不同的实现：编译器会把所有被lambda捕获的局部变量，直接从原栈存储位置提升为堆上自动生成的闭包类实例的普通实例字段。你写的示例代码，经过编译器转换后大致等价于：

// 编译器自动生成的闭包类
class AutoGeneratedClosure {
    public bool isDone;
    // lambda对应的方法
    public void RunBackgroundJob() {
        // 原lambda内的后台逻辑
        isDone = true;
    }
}

void DoSomeJob() {
    // 原局部变量直接变成闭包对象的字段
    var closureInstance = new AutoGeneratedClosure();
    closureInstance.isDone = false;
    
    var bgThread = new Thread(closureInstance.RunBackgroundJob);
    bgThread.Start();
    
    while (closureInstance.isDone == false) {
        // 原循环内的前台逻辑
    }
}

可以看到，代码里根本不存在“栈上的局部变量isDone”，前后两个线程读写的都是同一个堆上的普通实例字段，自然不存在值拷贝的限制，语法上自然允许在lambda里修改这个变量。

这个由编译器生成的isDone实例字段，默认没有任何内存同步语义，存在两个层面的优化可能，会直接导致程序不符合预期：

• CPU层面的缓存不一致：不同CPU核心对内存的写入可能暂存在本地私有缓存中，没有及时刷入主存，前台线程所在的核心可能长时间读不到后台线程的写入结果。
• JIT编译器的激进优化：因为这个字段没有同步标记，JIT完全有权将循环中对isDone的重复读取操作提升到循环外部，只在循环开始前读一次值做判断。按照这个优化逻辑，哪怕后台线程把isDone改成true，前台循环也根本不会重新读取这个值，直接进入永久死循环。

你测试时Debug、Release模式都跑通，完全是场景巧合：

• Debug模式下JIT默认关闭大部分激进优化，每次循环都会重新从内存读取字段值。
• Release模式下如果循环体逻辑比较复杂、测试时间极短、后台线程赋值动作发生在JIT完成优化之前，就刚好不会触发优化导致的死循环，但这不属于规范保证的行为。

只要是跨线程读写的闭包捕获变量，必须给对应的字段加上volatile标记，才能从根本上禁止JIT的读取提升优化，同时强制CPU读写操作的内存屏障，保证不同线程对这个变量的修改对其他线程可见。
没有同步标记的跨线程内存访问，即便程序在测试时数百次、数千次都运行正常，依然属于规范允许的未定义行为，随时可能在硬件环境、运行时版本、代码改动后出现卡死、逻辑错误的问题。

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