并发编程三座大山：原子性、指令重排与内存可见性-代码聚汇网

并发编程三座大山：原子性、指令重排与内存可见性

写手一条城·2026-08-17·阅读 21 GEO检测（免费）

并发编程线程安全原子性

|难度：普通|阅读约 11 分钟

1. 线程安全的核心挑战

当多个线程同时访问共享数据时，程序员最常遇到的三个核心问题就是原子性破坏、指令重排导致的意外结果，以及内存可见性问题。这三个概念构成了并发编程的"三座大山"，也是面试中高频出现的考察点。

我曾在电商平台的库存扣减系统中深刻领教过它们的威力。当时系统在促销活动时偶尔会出现"超卖"现象，明明库存只剩100件商品，却成功卖出了120件。经过长达两周的排查，最终发现问题就出在这三个概念的组合效应上——非原子操作被线程交替执行、编译器优化导致的指令重排、以及线程本地缓存未及时刷新主内存数据。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. 原子性：不可分割的操作

2.1 原子操作的本质

原子性指的是一个操作要么完全执行，要么完全不执行，不会出现执行到中间状态的情况。比如银行转账操作，必须保证扣款和入账两个步骤作为一个整体完成。在Java中，简单的i++操作看起来是原子的，但实际上包含了读取i、计算i+1、写入i三个步骤，这就破坏了原子性。

java复制// 表面上的原子操作
public class Counter {
    private int i = 0;
    public void increment() {
        i++; // 实际上是非原子操作
    }
}

2.2 常见原子性破坏场景

在实际项目中，我遇到过这些典型的原子性破坏案例：

电商库存扣减：check库存和update库存分开执行
分布式ID生成：多线程同时获取当前最大ID
计数器统计：多线程同时执行count++操作

2.3 解决方案对比

解决方案	原理	适用场景	性能影响
synchronized	互斥锁	方法/代码块级别同步	高
ReentrantLock	可重入锁	灵活控制锁范围	中高
AtomicInteger	CAS机制	简单计数器	低
LongAdder	分段CAS	高并发统计	最低

提示：在JDK8+环境中，对于高并发计数器场景，LongAdder的性能通常比AtomicInteger高出数倍

3. 指令重排：看不见的优化陷阱

3.1 从硬件到语言的优化链

现代计算机系统会在多个层次进行指令优化：

编译器优化：调整指令顺序提高IPC
CPU乱序执行：提高流水线利用率
内存系统重排：缓存一致性协议导致

java复制// 经典的单例模式双重检查问题
public class Singleton {
    private static Singleton instance;
    
    public static Singleton getInstance() {
        if (instance == null) {              // 第一次检查
            synchronized (Singleton.class) {
                if (instance == null) {      // 第二次检查
                    instance = new Singleton(); // 问题出在这里
                }
            }
        }
        return instance;
    }
}

3.2 重排导致的诡异问题

在上述单例模式中，new Singleton()实际上包含三个步骤：

分配内存空间
初始化对象
将引用指向内存地址

但经过重排后可能变成1→3→2的顺序执行。当线程A执行到3时，线程B可能看到一个非null但未初始化的对象。

3.3 内存屏障的使用

Java中可以通过volatile关键字插入内存屏障：

java复制private static volatile Singleton instance;

内存屏障的作用：

禁止屏障前后的指令重排
强制刷新处理器缓存
保证写入立即对其他线程可见

4. 可见性：内存模型的障眼法

4.1 JMM内存模型基础

Java内存模型(JMM)规定了：

每个线程有自己的工作内存
主内存存储共享变量
工作内存是主内存的副本

mermaid复制graph LR
    A[线程A工作内存] -->|读取/写入| B[主内存]
    C[线程B工作内存] -->|读取/写入| B

4.2 可见性问题实例

java复制public class VisibilityDemo {
    private boolean ready = false;
    private int number;
    
    public void writer() {
        number = 42;      // 操作1
        ready = true;     // 操作2
    }
    
    public void reader() {
        if (ready) {      // 操作3
            System.out.println(number); // 可能输出0
        }
    }
}

在这个例子中，由于缺少同步措施，reader线程可能看到ready为true但number仍为0的情况。

4.3 保证可见性的方法

volatile关键字：强制从主内存读写
synchronized：解锁前强制写回主内存
final字段：正确构造的对象final字段可见
Atomic类：内部使用volatile保证可见性

5. 实战中的组合应用

5.1 高并发计数器优化

java复制public class CompactCounter {
    private volatile long value;
    
    private static final AtomicLongFieldUpdater<CompactCounter> updater =
        AtomicLongFieldUpdater.newUpdater(CompactCounter.class, "value");
    
    public long increment() {
        return updater.incrementAndGet(this);
    }
}

这个实现结合了：

volatile保证可见性
CAS保证原子性
字段更新器节省内存

5.2 状态标志的最佳实践

对于简单的状态标志，推荐使用：

java复制public class ServerStatus {
    private volatile boolean isRunning;
    
    public void shutdown() {
        isRunning = false; // 所有线程立即可见
    }
}

5.3 避免过度同步的技巧

缩小同步块范围
使用不可变对象
线程封闭技术（ThreadLocal）
并发容器替代同步容器

6. 常见误区与排查技巧

6.1 伪共享问题

当多个线程修改同一个缓存行中的不同变量时，会导致性能急剧下降。解决方案：

java复制@Contended // JDK8引入的注解
public class PaddedAtomicLong extends AtomicLong {
    private long p1, p2, p3, p4, p5, p6; // 填充
}

6.2 正确理解happens-before

以下操作建立happens-before关系：

线程start()前的操作对该线程可见
解锁前的操作对后续加锁可见
volatile写对后续读可见
线程中断前的操作对检测到中断的代码可见

6.3 排查工具推荐

JConsole：监控线程状态
JStack：获取线程转储
JProfiler：分析锁竞争
Java并发压力测试工具JCStress

7. 现代并发模式演进

7.1 无锁编程趋势

CAS-based算法
RCU(Read-Copy-Update)
并发数据结构优化

7.2 硬件内存模型影响

不同CPU架构的内存一致性模型：

x86/64：TSO(Total Store Order)
ARM/POWER：更弱的内存模型
RISC-V：多种内存模型可选

7.3 协程与纤程的影响

更轻量的并发单元
减少线程切换开销
简化并发编程模型

在最近的一个交易系统中，我们将部分核心逻辑改为无锁实现后，吞吐量提升了3倍。关键是在订单匹配引擎中使用AtomicReferenceArray和精心设计的CAS循环，避免了传统锁带来的上下文切换开销。不过这种优化需要严格的正确性验证，我们使用了JCStress工具进行了长达72小时的压力测试。