C++多线程环境下全局变量的内存共享及线程安全问题咨询

问题1：多线程中全局变量的副本情况 #

全局变量在进程地址空间内仅存在一份物理内存实例，所有线程本质上读写的是同一块内存。但出于性能优化，现代CPU的各级缓存（L1/L2/L3）会为每个核心缓存该变量的副本——这是硬件层面的缓存机制，并非线程拥有独立的全局变量实例。

在你指定的C++/VS/Windows环境下，编译器默认不会为全局变量自动创建线程本地副本，除非显式使用thread_local关键字声明变量为线程本地存储（TLS）。

问题2：互斥锁Lock/Unlock能否确保数据同步至全局变量 #

是的。互斥锁的Lock()（Windows下如EnterCriticalSection）和Unlock()（LeaveCriticalSection）操作隐含**内存屏障（Memory Barrier）**语义：

• 调用Lock()时，会强制刷新当前线程缓存，确保后续读取的是主存最新数据；
• 调用Unlock()时，会将当前线程缓存中修改的数据同步回主存，同时让其他核心的缓存失效，保证其他线程后续能读到最新值。

这完全符合C++标准中同步操作的内存可见性要求，可确保线程间的数据同步。

问题3：给定伪代码是否安全 #

这段代码完全不安全，必须添加同步机制，原因如下：

1. 内存可见性问题：ThreadAFinished是普通bool变量，ThreadA对它的赋值无同步语义，ThreadB可能永远看不到它被设为true（CPU缓存未同步、编译器优化重排），导致无限循环；
2. 指令重排风险：编译器或CPU可能重排ThreadA的指令顺序——比如先设置ThreadAFinished = true，再完成Variable1的最后几次自增，导致ThreadB读到Variable1 < 1000，触发错误输出；
3. 非原子操作隐患：Variable1++是读-改-写的非原子操作（x86架构下32位int自增可能是原子的，但这是硬件特性而非C++标准保证），即使单线程写，缺乏同步也无法保证其他线程的可见性。

修复方案：用互斥锁保护Variable1和ThreadAFinished的读写，或将变量声明为std::atomic<int>和std::atomic<bool>，利用原子类型的内存可见性保证。

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