01 | 可见性、原子性和有序性问题：并发编程Bug的源头

对于双重锁的问题，我觉得任大鹏分析的蛮有道理，线程A进入第二个判空条件，进行初始化时，发生了时间片切换，即使没有释放锁，线程B刚要进入第一个判空条件时，发现条件不成立，直接返回instance引用，不用去获取锁。如果对instance进行volatile语义声明，就可以禁止指令重排序，避免该情况发生。 对于有些同学对CPU缓存和内存的疑问，CPU缓存不存在于内存中的，它是一块比内存更小、读写速度更快的芯片，至于什么时候把数据从缓存写到内存，没有固定的时间，同样地，对于有volatile语义声明的变量，线程A执行完后会强制将值刷新到内存中，线程B进行相关操作时会强制重新把内存中的内容写入到自己的缓存，这就涉及到了volatile的写入屏障问题，当然也就是所谓happen-before问题。

long类型64位，所以在32位的机器上，对long类型的数据操作通常需要多条指令组合出来，无法保证原子性，所以并发的时候会出问题🌝🌝🌝

周末了 对留言问题总结一下   ------可见性问题------ 对于可见性那个例子我们先看下定义: 可见性:一个线程对共享变量的修改，另外一个线程能够立刻看到   并发问题往往都是综合证，这里即使是单核CPU，只要出现线程切换就会有原子性问题。但老师的目的是为了让大家明白什么是可见性 或许我们可以把线程对变量的读可写都看作时原子操作，也就是cpu对变量的操作中间状态不可见，这样就能更加理解什么是可见性了。   ------CPU缓存刷新到内存的时机------ cpu将缓存写入内存的时机是不确定的。除非你调用cpu相关指令强刷   ------双重锁问题------ 如果A线程与B线程如果同时进入第一个分支，那么这个程序就没有问题   如果A线程先获取锁并出现指令重排序时，B线程未进入第一个分支，那么就可能出现空指针问题，这里说可能出现问题是因为当把内存地址赋值给共享变量后，CPU将数据写回缓存的时机是随机的   ------ synchronized------ 线程在synchronized块中，发生线程切换，锁是不会释放的   ------指令优化------ 除了编译优化,有一部分可以通过看汇编代码来看，但是CPU和解释器在运行期也会做一部分优化，所以很多时候都是看不到的，也很难重现。   ------JMM模型和物理内存、缓存等关系------ 内存、cpu缓存是物理存在，jvm内存是软件存在的。 关于线程的工作内存和寄存器、cpu缓存的关系 大家可以参考这篇文章 https://blog.csdn.net/u013851082/article/details/70314778/   ------IO操作------ io操作不占用cpu，读文件，是设备驱动干的事，cpu只管发命令。发完命令，就可以干别的事情了。     ------寄存器切换------  寄存器是共用的，A线程切换到B线程的时候，寄存器会把操作A的相关内容会保存到内存里，切换回来的时候，会从内存把内容加载到寄存器。可以理解为每个线程有自己的寄存器   请老师帮忙看看，有没问题。希望我的总结能帮到更多人😄😄

对于阿根一世同学的那个疑问，我个人认为CPU时间片切换后，线程B刚好执行到第一次判断instance==null，此时不为空，不用进入synchronized里，就将还未初始化的instance返回了

针对阿根一世的问题，问题其实出现在new Singleton()这里。 这一行分对于CPU来讲，有3个指令： 1.分配内存空间 2.初始化对象 3.instance引用指向内存空间 正常执行顺序1-2-3 但是CPU重排序后执行顺序可能为1-3-2，那么问题就来了 步骤如下： 1.A、B线程同时进入了第一个if判断 2.A首先进入synchronized块，由于instance为null，所以它执行instance = new Singleton(); 3.然后线程A执行1-> JVM先画出了一些分配给Singleton实例的空白内存，并赋值给instance 4.在还没有进行第三步（将instance引用指向内存空间）的时候，线程A离开了synchronized块 5.线程B进入synchronized块，读取到了A线程返回的instance，此时这个instance并未进行物理地址指向，是一个空对象。 有人说将对象设置成volatile，其实也不能完全解决问题。volatile只是保证可见性，并不保证原子性。 现行的比较通用的做法就是采用静态内部类的方式来实现。 public class MySingleton { //内部类 private static class MySingletonHandler{ private static MySingleton instance = new MySingleton(); } private MySingleton(){} public static MySingleton getInstance() { return MySingletonHandler.instance; } }

对于双重锁检查那个例子，我有一个疑问，A如果没有完成实例的初始化，锁应该不会释放的，B是拿不到锁的，怎么还会出问题呢？

刚看过《java并发实战》，又是看了个开始就看不下去了😂😂，希望订阅专栏可以跟老师和其他童鞋一起坚持学习并发编程😄😄 思考题：在32位的机器上对long型变量进行加减操作存在并发隐患的说法是正确的。 原因就是文章里的bug源头之二：线程切换带来的原子性问题。 非volatile类型的long和double型变量是8字节64位的，32位机器读或写这个变量时得把人家咔嚓分成两个32位操作，可能一个线程读了某个值的高32位，低32位已经被另一个线程改了。所以官方推荐最好把long\double 变量声明为volatile或是同步加锁synchronize以避免并发问题。 贴一段java文档的说明 https://docs.oracle.com/javase/specs/jls/se8/html/jls-17.html#jls-17.7 17.7. Non-Atomic Treatment of double and long 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. Writes to and reads of references are always atomic, regardless of whether they are implemented as 32-bit or 64-bit values. Some implementations may find it convenient to divide a single write action on a 64-bit long or double value into two write actions on adjacent 32-bit values. For efficiency's sake, this behavior is implementation-specific; an implementation of the Java Virtual Machine is free to perform writes to long and double values atomically or in two parts. Implementations of the Java Virtual Machine are encouraged to avoid splitting 64-bit values where possible. Programmers are encouraged to declare shared 64-bit values as volatile or synchronize their programs correctly to avoid possible complications.

Singleton instance改为volatile或者final就完美了，这里面其实涉及Java的happen-before原则。

synchronized修饰的代码块里，会出现线程切换么？我理解的synchronized作用就是同步执行，不会线程切换，请作者给我解答下。

王老师，你文章中讲的 优化指令的执行次序 使得缓存能够更加合理的利用是什么意思？