顺序一致性（SC）是理想化规范而非硬件保证，要求线程内程序序与全局内存序统一；多核中因写缓冲、缓存延迟和指令重排而难以自然满足，需显式同步（如seq_cst、锁）逼近其语义。
顺序一致性（Sequential Consistency，SC）模型本身不“保证”多核架构下的变量执行顺序——它是一个理想化规范，描述程序“应该看起来怎样运行”，而非硬件或编译器“实际如何实现”。真正的挑战恰恰在于：现代多核系统为了性能，天然违背SC的直观要求；而程序员又依赖SC直觉编写逻辑。这种张力构成了并发编程的核心难点。
为什么SC在多核上难以自然成立
SC要求两点同时满足：
• 每个线程内部指令严格按程序顺序（program order）执行；
• 所有线程观察到的全局内存操作顺序完全一致。
但多核系统中，以下机制会悄悄打破这一图景：
- 写入缓冲区（Store Buffer）：CPU发出写操作后，常先存入本地缓冲区再异步刷入缓存/内存。这导致本线程后续读取可能仍看到旧值（Store-Load重排），其他核更无法立即感知该写入。
- 缓存行无效延迟（MESI协议响应时间）：一个核修改共享变量时，需广播使其他核对应缓存行失效。但该过程非瞬时，期间其他核若读取，可能命中旧副本。
- 编译器与CPU的合法重排：只要不改变单线程语义，编译器可调整指令顺序；CPU可在寄存器和流水线层面乱序执行——这些优化对单线程透明，却直接破坏跨线程的SC观感。
SC不是硬件默认行为，而是需显式争取的语义
真实硬件（如x86）提供的是比SC弱、但比完全松散强的一致性模型（如TSO）。它允许某些重排（如Store-Load），但禁止其他（如Load-Load、Store-Store）。这意味着：
- 不加同步地写两个变量，另一线程可能看到一个已更新、另一个仍为初始值——这在SC下是不允许的（因全局顺序必须一致）。
- C++中用
std::memory_order_seq_cst原子操作，或Java中用volatile字段+正确同步块，才能强制逼近SC语义。 - mutex、synchronized等锁机制之所以“看起来符合SC”，是因为它们内部插入了内存屏障（fence），阻断了重排并刷新了缓存可见性。
典型反例：为何r1==0且r2==0在SC下不可能出现
回到经典双线程示例：
x = y = 0;Thread1: x = 1; r1 = y;
Thread2: y = 1; r2 = x;
在SC模型中，所有合法执行都对应某个全局串行顺序，例如：
- x=1 → r1=y → y=1 → r2=x ⇒ r1=0, r2=1
- y=1 → r2=x → x=1 → r1=y ⇒ r1=1, r2=0
- x=1 → y=1 → r1=y → r2=x ⇒ r1=1, r2=1
但r1==0且r2==0意味着：x=1尚未发生时r2读到了0，y=1也尚未发生时r1读到了0——这要求x=1和y=1都在两条读操作之后，与各自线程的program order矛盾。因此SC明确排除该结果。而现实中若无同步，该结果可能因缓冲区延迟和缓存未及时失效而出现。
应对思路：不追求“全系统SC”，而保障关键路径SC
完全启用SC语义代价高昂（禁用大部分重排与缓存优化）。实践中更可行的是：
- 识别关键共享点（如状态标志、计数器、锁变量），对其使用
seq_cst或volatile，让这些操作成为全局顺序锚点。 - 用锁或无锁结构封装临界区，在进入/退出时建立happens-before关系，使区内的操作对其他线程呈现SC-like视图。
- 避免依赖“隐含顺序”：不假设a=1; b=1; 后，其他线程必先看到a再看到b——除非显式同步。
