--极客时间学习笔记
在计算机的发展历程中，CPU、内存、I/O三者之间的性能差异是其一直存在的一个核心矛盾，三者的速度由快到慢依次为：CPU > 内存 > I/O
为了解决木桶效应的短板，平衡三者之间的速度差异，计算机体系结构、操作系统、编译程序做出了如下贡献：
- CPU增加了缓存，以均衡与内存的速度差异（很多时候的木桶是没有I/O的，即程序的运行不涉及I/O，因此解决CPU与内存之间的性能差异是有意义的）
- 操作系统增加了进程、线程，以分时复用CPU，进而均衡CPU与I/O设备的速度差异
- 编译程序优化指令执行顺序，使得缓存能够得到更加合理地利用
解决一些问题的同时必然会带来新的问题，这些问题就是线程安全问题：
- 缓存导致的可见性问题（针对多核CPU）
一个线程对共享变量的修改，另一个线程能够立即看见，我们称为可见性
public class Test {
private long count = 0;
private void add10K() {
int idx = 0;
while(idx++ < 10000) {
count += 1;
}
}
public static long calc() {
final Test test = new Test();
// 创建两个线程，执行add()操作
Thread th1 = new Thread(()->{
test.add10K();
});
Thread th2 = new Thread(()->{
test.add10K();
});
// 启动两个线程
th1.start();
th2.start();
// 等待两个线程执行结束
th1.join();
th2.join();
return count;
}
}
以上程序在单线程中的执行结果应该是20000，但是在这里结果是在10000-20000之间的某个值。原因就是两个线程的计算都是对各自缓存中的值进行计算的。
以上程序如果将循环次数改为1亿，可能最终的结果会更加接近1亿。而循环次数为10000的时候，可能会更加接近20000，原因是两个线程不是同时启动的，有一个时间差。
- 线程切换带来的原子性问题（一个或者多个操作在cpu执行过程中不被中断的特性称为原子性）
由于I/O太慢，早期的操作系统发明了多进程，即使在单核CPU上我们也可以一边听音乐，一边写Bug，这就是多进程的功劳。
操作系统允许某个进程执行一小段时间，每经过一个“时间片”，操作系统就会重新选择一个进程来执行。在一个时间片内，如果一个进程进行一个IO操作，这个时候该进程可以把自己标记为“休眠状态”
支持多进程分时复用在操作系统的发展史上具有里程碑意义，Unix就是因为解决了这个问题而名噪天下。
早期的操作系统基于进程来调度cpu，不同的进程间是不共享内存空间的，所以进程要做任务切换就要切换内存映射地址，而一个进程创建的所有线程，都是共享一个内存空间的（上述的可见性问题针对的是多核处理器中每颗cpu的缓存对其他线程是不可见的，即线程的工作空间），所以线程做任务切换成本就很低了。现代的操作系统都基于更轻量级的线程来调度，现在我们提到的“任务切换”都是指“线程切换”。
线程切换带来的非原子操作引发的线程安全问题：
count+=1；
上述代码对应的cpu指令：
指令一：变量count从内存加载到cpu的寄存器；
指令二：在寄存器执行+1操作；
指令三：将结果写入内存（缓存机制导致可能写入的是cpu缓存而不是内存，即可见性问题）
在上述示意图中，我们两个线程分别执行了count+=1操作，期望的执行结果应该是2，但实际执行结果却是1，这就是非原子操作引发的线程安全问题。
- 编译优化带来的有序性问题
cpu的指令执行顺序有时候会发生改变，即编译优化，进而引发线程安全问题。以单例模式的双重锁验证方式为例：
public class Singleton {
private static Singleton instance;
private Singleton() {
}
public static Singleton getInstance() {
if (instance == null) {
synchronize(Singleton.class) {
if (instance == null) {
instance = new Singleton();
}
}
}
return instance;
}
}
case1: 假设两个线程调用getInstance()方法，两个线程均判断instance==null，只有一个线程能加锁成功，完成instance初始化。另一个线程加锁成功，判断instance不为null，返回insatnce。但是存在一个问题，即可见性问题，也就是说instance初始化完成对另一个线程可能是不可见的。
case2: 假设一个线程调用getInstance()方法，判断instance==null，加锁成功，判断instance==null，初始化步骤如下：1.分配一块内存M；2.在内存上初始化Singleton对象；3.将M的内存地址赋值给instance对象。经过编译优化后的顺候为1，3，2。假设执行完步骤三之后发生了线程切换（不会释放锁），此时另一个线程调用getInstance()方法，发现instance!=null，所以直接返回instance。但此时的instance是尚未初始化完成的，会触发空指针异常。而导致这一问题的源头就是有序性问题。
解决方案：增加volatile关键字（可解决可见性与有序性问题）
public class Singleton { private static volatile Singleton instance; private Singleton() { } public static Singleton getInstance() { if (instance == null) { synchronize(Singleton.class) { if (instance == null) { instance = new Singleton(); } } } return instance; } }
课后思考：在32位的机器上（32位和64位表示CPU一次能处理的最大位数）对long型变量进行加减操作是否会引发线程安全问题。
答案：由于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的相关内容会保存到内存里，切换回来的时候，会从内存把内容加载到寄存器。可以理解为每个线程有自己的寄存器
人贵有志，学贵有恒！
Singleton