全网最硬核 Java 新内存模型解析与实验 - 2. 原子访问与字分裂 java

个人创作公约：本人声明创作的所有文章皆为自己原创，如果有参考任何文章的地方，会标注出来，如果有疏漏，欢迎大家批判。如果大家发现网上有抄袭本文章的，欢迎举报，并且积极向这个 github 仓库提交 issue，谢谢支持~
本篇文章参考了大量文章，文档以及论文，但是这块东西真的很繁杂，我的水平有限，可能理解的也不到位，如有异议欢迎留言提出。本系列会不断更新，结合大家的问题以及这里的错误和疏漏，欢迎大家留言
如果你喜欢单篇版，请访问：全网最硬核 Java 新内存模型解析与实验单篇版（不断更新QA中）
如果你喜欢这个拆分的版本，这里是目录：

全网最硬核 Java 新内存模型解析与实验 - 1. 什么是 Java 内存模型

全网最硬核 Java 新内存模型解析与实验 - 2. 原子访问与字分裂

全网最硬核 Java 新内存模型解析与实验 - 3. 硬核理解内存屏障（CPU+编译器）

全网最硬核 Java 新内存模型解析与实验 - 4. Java 新内存访问方式与实验

全网最硬核 Java 新内存模型解析与实验 - 5. JVM 底层内存屏障源码分析

JMM 相关文档：

Java Language Specification Chapter 17

The JSR-133 Cookbook for Compiler Writers - Doug Lea's

Using JDK 9 Memory Order Modes - Doug Lea's

内存屏障，CPU 与内存模型相关：

Weak vs. Strong Memory Models

Memory Barriers: a Hardware View for Software Hackers

A Detailed Analysis of Contemporary ARM and x86 Architectures

Memory Model = Instruction Reordering + Store Atomicity

Out-of-Order Execution

x86 CPU 相关资料：

x86 wiki

Intel? 64 and IA-32 Architectures Software Developer Manuals

Formal Specification of the x86 Instruction Set Architecture

ARM CPU 相关资料：

ARM wiki

aarch64 Cortex-A710 Specification

各种一致性的理解：

Coherence and Consistency

Aleskey 大神的 JMM 讲解：

Aleksey Shipil?v - 不要误解Java内存模型（上）

Aleksey Shipil?v - 不要误解Java内存模型（下）

相信很多 Java 开发，都使用了 Java 的各种并发同步机制，例如 volatile，synchronized 以及 Lock 等等。也有很多人读过 JSR 第十七章 Threads and Locks（地址：https://docs.oracle.com/javase/specs/jls/se17/html/jls-17.html），其中包括同步、Wait/Notify、Sleep & Yield 以及内存模型等等做了很多规范讲解。但是也相信大多数人和我一样，第一次读的时候，感觉就是在看热闹，看完了只是知道他是这么规定的，但是为啥要这么规定，不这么规定会怎么样，并没有很清晰的认识。同时，结合 Hotspot 的实现，以及针对 Hotspot 的源码的解读，我们甚至还会发现，由于 javac 的静态代码编译优化以及 C1、C2 的 JIT 编译优化，导致最后代码的表现与我们的从规范上理解出代码可能的表现是不太一致的。并且，这种不一致，导致我们在学习 Java 内存模型（JMM，Java Memory Model），理解 Java 内存模型设计的时候，如果想通过实际的代码去试，结果是与自己本来可能正确的理解被带偏了，导致误解。
我本人也是不断地尝试理解 Java 内存模型，重读 JLS 以及各路大神的分析。这个系列，会梳理我个人在阅读这些规范以及分析还有通过 jcstress 做的一些实验而得出的一些理解，希望对于大家对 Java 9 之后的 Java 内存模型以及 API 抽象的理解有所帮助。但是，还是强调一点，内存模型的设计，出发点是让大家可以不用关心底层而抽象出来的一些设计，涉及的东西很多，我的水平有限，可能理解的也不到位，我会尽量把每一个论点的论据以及参考都摆出来，请大家不要完全相信这里的所有观点，如果有任何异议欢迎带着具体的实例反驳并留言。
3. 原子性访问原子性访问，对于一个字段的写入与读取，这个操作本身是原子的不可分割的。可能大家不经常关注的一点是根据 JLS 第 17 章中的说明，下面这两个操作，并不是原子性访问的：

文章图片

因为大家当前的系统通常都是 64 位的，得益于此，这两个操作大多是原子性的了。但是其实根据 Java 的规范，这两个并不是原子性的，在 32 位的系统上就保证不了原子性。我这里直接引用 JLS 第 17 章的一段原话：

For the purposes of the Java programming language memory model, a single write to a non-volatile long or double value is treated as two separate writes: one to each 32-bit half. This can result in a situation where a thread sees the first 32 bits of a 64-bit value from one write, and the second 32 bits from another write.
Writes and reads of volatile long and double values are always atomic.

翻译过来，简单来说非 volatile 的 long 或者 double 可能会按照两次单独的 32 位写更新，所以是非原子性的。volatile 的 long 或者 double 读取和写入都是原子性的。
为了说明我们这里的原子性，我引用一个 jcstress 中的一个例子：

文章图片

【全网最硬核 Java 新内存模型解析与实验 - 2. 原子访问与字分裂】我们使用 Java 8 32bit （Java 9 之后就不再支持 32 位的机器了）的 JVM 运行这里的代码，结果是：

文章图片

可以看到，结果不止 -1 和 0 这种我们代码中的指定的值，还有一些中间结果。
4. 字分裂（word tearing）字分裂（word tearing）即你更新一个字段，数组中的一个元素，会影响到另一个字段，数组中的另一个元素的值。例如处理器没有提供写单个 byte 的功能，假设最小维度是 int，在这样的处理器上更新 byte 数组，若只是简单地读取 byte 所在的整个 int，更新对应的 byte，然后将整个 int 再写回，这种做法是有问题的。Java 中没有字分裂现象，字段之间以及数组元素之间是独立的，更新一个字段或元素不能影响任何其它字段或元素的读取与更新。
为了说明什么是字分裂，举一个不太恰当的例子，即线程不安全的 BitSet。BitSet 的抽象是比特位集合（一个一个 0，1 这样，可以理解为一个 boolean 集合），底层实现是一个 long 数组，一个 long 保存 64 个比特位，每次更新都是读取这个 long 然后通过位运算更新对应的比特位，再更新回去。接口层面是一位一位更新，但是底层却是按照 long 的维度更新的（因为是底层 long 数组），很明显，如果没有同步锁，并发访问就会并发安全问题从而造成字分裂的问题：

文章图片

结果是：

文章图片

这里用了一个不太恰当的例子来说明什么是字分裂，Java 中是可以保证没有字分裂的，对应上面的 BitSet 的例子就是我们尝试更新一个 boolean 数组，这样结果就只会是 true true：

文章图片

这个结果只会是 true true
接下来，我们将进入一个比较痛苦的章节了，内存屏障，不过大家也不用太担心，从我个人的经验来看，内存屏障很难理解的原因是因为网上基本上不会从 Java 已经为你屏蔽的底层细节去给你讲，直接理解会很难说服自己，于是就会猜想一些东西然后造成误解，所以本文不会上来丢给你 Doug Lea 抽象的并一直沿用至今的 Java 四种内存屏障（就是 LoadLoad，StoreStore，LoadStore 和 StoreLoad 这四个，其实通过后面的分析也能看出来，这四个内存屏障的设计对于现在的 CPU 来说已经有些过时了，现在用的更多的是 acquire, release 以及 fence）希望能通过笔者看的一些关于底层细节的文章论文中提取出便于大家理解的东西供大家参考，更好地更容易的理解内存屏障。

微信搜索“我的编程喵”关注公众号，加作者微信，每日一刷，轻松提升技术，斩获各种offer：

文章图片

我会经常发一些很好的各种框架的官方社区的新闻视频资料并加上个人翻译字幕到如下地址（也包括上面的公众号），欢迎关注：

知乎：https://www.zhihu.com/people/...

B 站：https://space.bilibili.com/31...