你真的理解 volatile 关键字了吗？

volatile 不只是"线程可见"。这篇文章用几个具体的 case，把它在 JMM 里的工作方式说清楚。

一、从最简单的 volatile 开始

volatile int flag = 0;

// 线程 A
flag = 1;

// 线程 B
if (flag == 1) {
    // ...
}

volatile 做了什么？

建立 happens-before：

线程 A 对 flag 的写 happens-before 线程 B 对 flag 的读

还有一条容易忽略的规则：

volatile 写之前的所有普通写，在 volatile 读之后对读线程可见

二、volatile 不是"广播"，而是"同步点"

一个常见的误解是：只要加了 volatile，其他线程就会自动看到变化。

这是错的。

Case 1：写了 volatile，但没读

int A = 0;
volatile int B = 0;

// 线程 A
A = 1;
B = 1;

// 线程 B
int x = A;   // 能看到 1 吗？

结论：❌ 不能保证

volatile 的 happens-before 只在"读发生时"生效。线程 B 没有读 B，没有同步点，就没有可见性保证。

volatile 是拉模型，不是推模型。

三、volatile + 普通变量的正确发布模式

Case 2：volatile 作用的传递性

线程 B 能正确读到 A 吗？

int A = 0;
volatile boolean ready = false;

// 线程 A
A = 1;
ready = true;

// 线程 B
if (ready) {
    System.out.println(A);
}

结论：✅ A 一定是 1

原因是 happens-before 的传递性：

如果 A happens-before B，B happens-before C
那么 A happens-before C

链路完整：

线程 a:
A = 1
  ↓  (线程内顺序)
B = 1  (volatile 写)
  ↓  (volatile 写-读)
线程 b:
if (B == 1)
  ↓  (传递性)
读取 A == 1

这是 JMM 官方认可的发布-订阅模式：

// producer
data = ...; // 普通写
ready = true; // volatile 写

// consumer
if (ready) { // volatile 读
    use(data); // 安全
}

四、多个 volatile 变量 ≠ 自动传递

Case 3：A 普通，B / C 是 volatile

int A = 0;
volatile int B = 0;
volatile int C = 0;

// 线程 A
A = 1;
B = 1;

// 线程 B
int c = C;
int a = A;

结论：❌ 不能保证看到 A = 1

volatile 的 happens-before 只对同一个 volatile 变量生效：

写 B → 读 B：有保证
写 B → 读 C：没有任何语义关系

volatile 不会跨变量广播内存可见性。

五、对象字段里有 volatile，就能"顺带同步"吗？

Case 4：对象里 ABC，只有 C 是 volatile

class Obj {
    int A;
    int B;
    volatile int C;
}

// 线程 A
obj.A = 1;
obj.B = 2;
obj.C = 3;

// 线程 B
int a = obj.A;
int b = obj.B;

结论：❌ 不能保证

volatile 是变量级别的，不是对象级别的。不读 C，就不会触发 volatile 读，A / B 仍然是普通读。

六、"我读了 volatile，但没用它"，算吗？

Case 5：返回 volatile，但返回值没用

volatile int C;

int foo() {
    return C;
}

// 线程 B
foo();  // 返回值未使用

结论：⚠️ 不一定算

语义上确实是一次 volatile 读，但如果返回值没被使用，JIT 有权把这次读整个消掉。

两个层面分开看：

① Java 语言语义层面

return C; 在规范里就是一条 volatile 读指令，没有争议。

② JVM / JIT 实际执行层面

JMM 允许 JVM 这么做：

如果一个 volatile 读的结果对程序行为没有任何影响，JVM 可以消除这个读。

这个返回值没有赋给变量、没有用于条件判断、没有参与计算，对可观察行为没有影响，JVM 会把它当死代码处理。

需要澄清一点：

volatile 的内存语义，不是 Java 语言层面的可观察副作用。

volatile 只约束重排序与可见性，不算 I/O、不算异常、不算锁，除非它被实际执行，否则不是 happens-before 的强制保留点。

七、什么时候 volatile 读一定成立？

Case 6：volatile 参与了判断

volatile int C;

boolean foo() {
    return C == 0;
}

结论：✅ 一定是 volatile 读，不可消除

return C == 0; 和上面的 return C; 区别在于：这里读取 C 的结果直接参与了比较，影响了方法返回值。

方法返回值是可观察行为，JVM 没有任何空间把它优化掉。

八、volatile 的本质

可以把 volatile 理解为：

写 volatile = release
读 volatile = acquire

它同步的不是"某个变量"，而是一个时间点：

在这个点之前，数据已经写完了

九、volatile 在 Disruptor 中的应用

用 Disruptor 来验证一下这个模型。

很多人用 Disruptor 时有这个疑惑：Event 字段没有 volatile，生产者写完数据，消费者却总能看到最新值。

原因是：Disruptor 同步的不是数据，而是"数据写完"这件事。

核心结构

Event 普通字段
     ↑
Sequence（volatile）

生产者逻辑（简化）

Event e = ringBuffer.get(seq);
e.x = ...;
e.y = ...;
sequence.set(seq); // volatile 写（发布）

消费者逻辑

long s = sequence.get(); // volatile 读
Event e = ringBuffer.get(s);

happens-before 链

写 Event 字段
  ↓
volatile 写 sequence
  ↓ happens-before
volatile 读 sequence
  ↓
读 Event 字段

和前面的发布-订阅模式一模一样。

Event 字段不需要 volatile，因为它不是并发访问，而是被发布的快照。一个 event slot 只被一个生产者写，之后只被一个消费者读，靠 Sequence 做交接。这是所有权转移，不是共享访问。

如果 Event 字段都是 volatile：每个字段访问都有内存屏障，cache line 来回抖，false sharing 风险暴涨。

Disruptor 用一次 volatile 发布整个对象，相当于一次内存批量提交，比字段粒度的 volatile 快得多。

十、小结

volatile 不是"自动可见"，而是同步点
不读 volatile，就没有 happens-before
volatile 不会跨变量传播可见性
可能被优化掉的 volatile 读，不是同步点
高性能无锁结构，都是"数据 + volatile 发布点"

写在最后

volatile 在 JMM 里的行为比大多数人理解的要复杂。不是"加了就有可见性"，而是"读的那一刻建立了同步"。把这个模型理解清楚，写并发代码时才能真正知道自己在保证什么。

此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。原文来自 — 版权归原作者所有。

推荐订阅源

博客园_首页