前言
前两天有人问我个问题: Java 引用设值的是不是原子操作？如果不是，是不是所有引用操作需要用同步来保证保证？
说实话，我当时不记得了，所以在脑子里推导了下，当时回答是非原子操作。但是这个答案是不准确！
因为翻了下书，结合自己的回忆来梳理下这块。
1. Java 中引用的原子性
引用类型的定义，参考：
Chapter 2. The Structure of the Java Virtual Machine 中 2.4 和 2.6.1
可以看出，引用在内存中占用一个slot，也就是说其写入只需要一次内存总线操作就可以完成，那么从单个写入操作来说，对引用的修改的确是原子的。
但是：
- 现在的服务器大都是多CPU的，就是单CPU也是多核的，这就有缓存一致性的问题。所以从实际中在多线程中共享的引用来说，引用设值无法说是原子的。(后面详细解释)。
- 除了
instance a = null;这样的立即数操作，大部分修改引用都是instance a = b;，那么这个操作本身就是非原子，因为需要先读取 b 在写入 a -
instance a = new class(...);如这个引用是新建的，还需要担心另一个问题 - "this逃逸问题"，当然这个实际上是类构造函数应该解决的问题
那么对存在共享的引用解决同步的方法有：
- 使用 AtomicReference
- 使用
synchronized控制 -
某些场景可以用
volatile修饰
2. 普遍意义上同步问题
在这个问题上有很多人写了很多很好的文章，这里本人只从自己理解的角度简短描述下，如有错误，烦请指出
2.1 同步问题的本质
一个 32 值在一个32位CPU中修改时走过的最短路线：
如果有两个线程共享的值修改可能会怎么样：
注意， 在实际CPU的调度中，可能：
1. CPU０和CPU１ 可能是同一个，更可能是不同的
2. 执行顺序是无法预料的
3. 任何一步都可能会暂停的
4. 如果值本身长度超过数据线位数，比如现在是个64值 - 那么上述每一步操作本身实际都是两步，也就是操作本身非原子 (实际CPU指令上就复杂了，一些指令一个就操作多个数据)
这样一个修改，另一个也修改时，结果就会出现各种随机情况，比如：
- 一切正常
- 两个都修改成功了，但是最终结果错误，比如两个递增应该加2，实际只加1
- 部分修改，比如64位数据的高位正确，但低位错误
这就可能会导致程序处理中出现随机错误。
这个问题的本质是：
- 共享资源操作顺序的不可控导致处理逻辑的随机错误
- 更进一步抽象 -- 信息的不同步导致后续错误
从第二个角度看，这个问题在非常多的领域会遇到：
- 数据库数据的修改问题 - ACID
- 代码库多人修改 - 提交、合并代码要小心哦 😀
- 两个描述同一个大象，只是一个从鼻子开说，一个从尾巴开说；吵了半天才发现是相同的，或者气的老死不相往来
解决之道
所以呢：
- 开会时，尽量让人把话说完，不明白的再问清楚，相互理解了再争不迟
- 代码提交时，先拉到本地解决冲突了再提交，不要把 remote 搞乱了
- 数据库事务用好了
那数据这块怎么办呢？
- 避免共享，釜底抽薪！比如：全局变量尽量不要有，函数要尽量可重入，在恰当的地方使用线程私有变量等
这里额外说一点，Java 里的
StringBuilder虽然总是说时线程非安全的，但实现上，我们绝大部分使用场景都不会共享一个StringBuilder实例，都是在一个函数内new一个，所以也就无谓了。
- 排队，使用消息/事务机制，将对相同数据的操作在同一个线程里排队
- 加锁，各种锁 - 从硬件到软件、从 spinlock 到信号量
