从 Java 引用的原子性说到同步问题的本质

前言

前两天有人问我个问题: Java 引用设值的是不是原子操作？如果不是，是不是所有引用操作需要用同步来保证保证？

说实话，我当时不记得了，所以在脑子里推导了下，当时回答是非原子操作。但是这个答案是不准确！

因为翻了下书，结合自己的回忆来梳理下这块。

1. Java 中引用的原子性

引用类型的定义，参考：

Chapter 2. The Structure of the Java Virtual Machine 中 2.4 和 2.6.1

可以看出，引用在内存中占用一个slot，也就是说其写入只需要一次内存总线操作就可以完成，那么从单个写入操作来说，对引用的修改的确是原子的。

但是：

1. 现在的服务器大都是多CPU的，就是单CPU也是多核的，这就有缓存一致性的问题。所以从实际中在多线程中共享的引用来说，引用设值无法说是原子的。(后面详细解释)。
2. 除了 instance a = null; 这样的立即数操作，大部分修改引用都是 instance a = b;，那么这个操作本身就是非原子，因为需要先读取 b 在写入 a
3. instance a = new class(...); 如这个引用是新建的，还需要担心另一个问题 - "this逃逸问题"，当然这个实际上是类构造函数应该解决的问题

那么对存在共享的引用解决同步的方法有：

1. 使用 AtomicReference
2. 使用 synchronized 控制
3. 某些场景可以用 volatile 修饰

2. 普遍意义上同步问题

在这个问题上有很多人写了很多很好的文章，这里本人只从自己理解的角度简短描述下，如有错误，烦请指出

2.1 同步问题的本质

一个 32 值在一个32位CPU中修改时走过的最短路线：

单

如果有两个线程共享的值修改可能会怎么样：

双

注意，　在实际CPU的调度中，可能：

1.　CPU０和CPU１ 可能是同一个，更可能是不同的
2.　执行顺序是无法预料的
3.　任何一步都可能会暂停的
4.　如果值本身长度超过数据线位数，比如现在是个64值 - 那么上述每一步操作本身实际都是两步，也就是操作本身非原子　(实际CPU指令上就复杂了，一些指令一个就操作多个数据)

这样一个修改，另一个也修改时，结果就会出现各种随机情况，比如：

1. 一切正常
2. 两个都修改成功了，但是最终结果错误，比如两个递增应该加2，实际只加1
3. 部分修改，比如64位数据的高位正确，但低位错误

这就可能会导致程序处理中出现随机错误。

这个问题的本质是：

1. 共享资源操作顺序的不可控导致处理逻辑的随机错误
2. 更进一步抽象 -- 信息的不同步导致后续错误

从第二个角度看，这个问题在非常多的领域会遇到：

1. 数据库数据的修改问题 - ACID
2. 代码库多人修改 - 提交、合并代码要小心哦 😀
3. 两个描述同一个大象，只是一个从鼻子开说，一个从尾巴开说；吵了半天才发现是相同的，或者气的老死不相往来

解决之道

所以呢：

1. 开会时，尽量让人把话说完，不明白的再问清楚，相互理解了再争不迟
2. 代码提交时，先拉到本地解决冲突了再提交，不要把 remote 搞乱了
3. 数据库事务用好了

那数据这块怎么办呢？

1. 避免共享，釜底抽薪！比如：全局变量尽量不要有，函数要尽量可重入，在恰当的地方使用线程私有变量等

这里额外说一点，Java 里的 StringBuilder 虽然总是说时线程非安全的，但实现上，我们绝大部分使用场景都不会共享一个 StringBuilder 实例，都是在一个函数内 new 一个，所以也就无谓了。

2. 排队，使用消息/事务机制，将对相同数据的操作在同一个线程里排队
3. 加锁，各种锁 - 从硬件到软件、从 spinlock 到信号量