1. 计算机原理
Java内存模型即Java Memory Model，简称JMM。JMM定义了Java 虚拟机(JVM)在计算机内存(RAM)中的工作方式。JVM是整个计算机虚拟模型，所以JMM是隶属于JVM的。Java1.5版本对其进行了重构，现在的Java仍沿用了Java1.5的版本。
根据《Jeff Dean在Google全体工程大会的报告》我们可以看到
计算机在做一些我们平时的基本操作时，需要的响应时间是不一样的。
2. Java内存模型
从抽象的角度来看，JMM定义了线程和主内存之间的抽象关系：线程之间的共享变量存储在主内存（Main Memory）中，每个线程都有一个私有的本地内存（Local Memory），本地内存中存储了该线程以读/写共享变量的副本。本地内存是JMM的一个抽象概念，并不真实存在。它涵盖了缓存、写缓冲区、寄存器以及其他的硬件和编译器优化。
2.1 可见性
可见性是指当多个线程访问同一个变量时，一个线程修改了这个变量的值，其他线程能够立即看得到修改的值。
由于线程对变量的所有操作都必须在工作内存中进行，而不能直接读写主内存中的变量，那么对于共享变量V，它们首先是在自己的工作内存，之后再同步到主内存。可是并不会及时的刷到主存中，而是会有一定时间差。很明显，这个时候线程 A 对变量 V 的操作对于线程 B 而言就不具备可见性了 。
要解决共享对象可见性这个问题，我们可以使用volatile关键字或者是加锁。
2.2 原子性
原子性：即一个操作或者多个操作 要么全部执行并且执行的过程不会被任何因素打断，要么就都不执行。
我们都知道CPU资源的分配都是以线程为单位的,并且是分时调用,操作系统允许某个进程执行一小段时间，例如 50 毫秒，过了 50 毫秒操作系统就会重新选择一个进程来执行（我们称为“任务切换”），这个 50 毫秒称为“时间片”。而任务的切换大多数是在时间片段结束以后,
那么线程切换为什么会带来bug呢？因为操作系统做任务切换，可以发生在任何一条CPU 指令执行完！注意，是 CPU 指令,而不是高级语言里的一条语句。比如count++，在java里就是一句话，但高级语言里一条语句往往需要多条 CPU 指令完成。其实count++包含了三个CPU指令！
2.volatile详解
2.1 volatile特性
可见性。对一个volatile变量的读，总是能看到（任意线程）对这个volatile变量最后的写入。
原子性：对任意单个volatile变量的读/写具有原子性，但类似于volatile++这种复合操作不具有原子性。例如：volatile虽然能保证执行完及时把变量刷到主内存中，但对于count++这种非原子性、多指令的情况，由于线程切换，线程A刚把count=0加载到工作内存，线程B就可以开始工作了，这样就会导致线程A和B执行完的结果都是1，都写到主内存中，主内存的值还是1不是2。
抑制重排序：有volatile修饰的变量，赋值后多执行了一个“load addl $0x0, (%esp)”操作，这个操作相当于一个内存屏障（指令重排序时不能把后面的指令重排序到内存屏障之前的位置）。
指令重排序：处理器为了提高程序运行效率，可能会对输入代码进行优化，它不保证程序中各个语句的执行先后顺序同代码中的顺序一致，但是它会保证程序最终执行结果和代码顺序执行的结果是一致的。
2.2 volatile的实现原理
为了探究Volatile的底层实现原理，我们需要先将java代码编程成字节码，然后通过java工具看汇编代码就可以知道底层原理。下面来看看
public class TestVolatile {
private static volatile int i = 0;
public static void main(String[] args) {
}
}使用javap -c 文件名 或者AndroidStudio的ASM插件看字节码
static <clinit>()V
L0
LINENUMBER 8 L0
ICONST_0
// 下面这行字节码无论是否使用volatile修饰，都是一样的
PUTSTATIC com/example/threadtest/volatilesynchronized/TestVolatile.i : I
RETURN
MAXSTACK = 1
MAXLOCALS = 0然后继续往下探索
java -XX:+UnlockDiagnosticVMOptions -XX:+PrintAssembly TestVolatile > 1.txt查看汇编码
Line 2521: 0x000000000356fecc: lock cmpxchg qword ptr [rdx],rdi
Line 2528: 0x000000000356feed: lock cmpxchg qword ptr [rdx],rdi
Line 2534: 0x000000000356ff0b: lock add dword ptr [rsp],0h ;*putstatic
Line 2538: 0x000000000356ff1a: lock cmpxchg qword ptr [rdx],rsi
Line 2816: 0x0000000003570338: lock cmpxchg qword ptr [rdi],rsi
Line 2941: 0x0000000003570479: lock cmpxchg qword ptr [rsi],rdi可以看到
汇编指令中会有很多加“lock”前缀的指令。
加入volatile关键字和没有加入volatile关键字时所生成的汇编代码发现，加入volatile关键字时，会多出一个lock前缀指令。我们发现，volatile变量在字节码级别没有任何区别，在汇编级别使用了lock指令前缀。
lock是一个指令前缀，Intel的手册上对其的解释是：
Causes the processor’s LOCK# signal to be asserted during execution of the accompanying instruction (turns the instruction into an atomic instruction). In a multiprocessor environment, the LOCK# signal insures that the processor has exclusive use of any shared memory while the signal is asserted.
简单理解也就是说，lock后就是一个原子操作。原子操作是指不会被线程调度机制打断的操作；这种操作一旦开始，就一直运行到结束，中间不会有任何 context switch （切换到另一个线程）。
当使用 LOCK 指令前缀时，它会使 CPU 宣告一个 LOCK# 信号，这样就能确保在多处理器系统或多线程竞争的环境下互斥地使用这个内存地址。当指令执行完毕，这个锁定动作也就会消失。
乍一看是不是感觉和Java的synchronized锁。但volatile底层使用多核处理器实现的lock指令，更底层，消耗代价更小。
因此有人将Java的synchronized看作重量级的锁，而volatile看作轻量级的锁 并不是全无道理。
lock前缀指令其实就相当于一个内存屏障。内存屏障是一组CPU处理指令，用来实现对内存操作的顺序限制。volatile的底层就是通过内存屏障来实现的。
编译器和执行器 可以在保证输出结果一样的情况下对指令重排序，使性能得到优化。插入一个内存屏障，相当于告诉CPU和编译器先于这个命令的必须先执行，后于这个命令的必须后执行。
**内存屏障另一个作用是强制更新一次不同CPU的缓存。**例如，一个写屏障会把这个屏障前写入的数据刷新到缓存，这样任何试图读取该数据的线程将得到最新值，而不用考虑到底是被哪个cpu核心或者哪个CPU执行的。这正是volatile实现内存可见性的基础。
3.3 synchronized的实现原理
Synchronized在JVM里的实现都是基于进入和退出Monitor对象来实现方法同步和代码块同步，虽然具体实现细节不一样，但是都可以通过成对的MonitorEnter和MonitorExit指令来实现。
// 测试代码
public class Test {
private static volatile int i = 0;
private final Object lock = new Object();
public void a() {
synchronized (lock) {
i++;
}
}
public synchronized void b() {
i++;
}
}对同步块，MonitorEnter指令插入在同步代码块的开始位置，当代码执行到该指令时，将会尝试获取该对象Monitor的所有权，即尝试获得该对象的锁，而monitorExit指令则插入在方法结束处和异常处，JVM保证每个MonitorEnter必须有对应的MonitorExit。
public a()V
......
DUP
ASTORE 1
MONITORENTER // 同步块开始
L0
LINENUMBER 15 L0
GETSTATIC com/example/threadtest/volatilesynchronized/Test.i : I
ICONST_1
IADD
PUTSTATIC com/example/threadtest/volatilesynchronized/Test.i : I
L5
LINENUMBER 16 L5
ALOAD 1
MONITOREXIT // 同步块结束
L1
GOTO L6
......对同步方法，从同步方法反编译的结果来看，方法的同步并没有通过指令monitorenter和monitorexit来实现，相对于普通方法，其常量池中多了ACC_SYNCHRONIZED标示符。
// access flags 0x1 没有synchronized修饰
public a()V
// access flags 0x21 synchronized修饰
public synchronized b()VJVM就是根据该标示符来实现方法的同步的：当方法被调用时，调用指令将会检查方法的 ACC_SYNCHRONIZED 访问标志是否被设置，如果设置了，执行线程将先获取monitor，获取成功之后才能执行方法体，方法执行完后再释放monitor。在方法执行期间，其他任何线程都无法再获得同一个monitor对象。
synchronized使用的锁信息是存放在Java对象头里面。
具体位置是对象头里面的MarkWord，MarkWord里默认数据是存储对象的HashCode等信息，
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-jQ0ecigJ-1610692229134)(https://upload-images.jianshu.io/upload_images/13838098-c78ecc4cb3e78dd4.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)]
但是会随着对象的运行改变而发生变化，不同的锁状态对应着不同的记录存储方式
3.4 各种锁
3.4.1.1 自旋锁 (轻量级锁)
自旋锁原理非常简单，如果持有锁的线程能在很短时间内释放锁资源，那么那些等待竞争锁的线程就不需要做内核态和用户态之间的切换进入阻塞挂起状态，它们只需要等一等（自旋），等持有锁的线程释放锁后即可立即获取锁，这样就避免用户线程和内核的切换的消耗。
3.4.1.2 自旋锁的优缺点
自旋锁尽可能的减少线程的阻塞，这对于锁的竞争不激烈，且占用锁时间非常短的代码块来说性能能大幅度的提升，因为自旋的消耗会小于线程阻塞挂起操作的消耗。
但是如果锁的竞争激烈，或者持有锁的线程需要长时间占用锁执行同步块，这时候就不适合使用自旋锁了，因为自旋锁在获取锁前一直都是占用cpu做无用功。
3.4.1.3 自旋锁时间阈值
JVM对于自旋次数的选择，jdk1.5默认为10次，在1.6引入了适应性自旋锁
，适应性自旋锁意味着自旋的时间不在是固定的了，而是由前一次在同一个锁上的自旋时间以及锁的拥有者的状态来决定，基本认为一个线程上下文切换的时间是最佳的一个时间。
JDK1.6中-XX:+UseSpinning开启自旋锁； JDK1.7后，去掉此参数，由jvm控制
3.4.2.1 偏向锁
研究人员经过大量统计，发现一把锁总是被同一线程竞争拿到，所以就引入偏向锁概念，当在进行CAS自旋拿锁之前，先判断自己是不是在竞争这把锁，如果是就直接执行。
偏向锁，顾名思义，它会偏向于第一个访问锁的线程，如果在运行过程中，同步锁只有一个线程访问，不存在多线程争用的情况，则线程是不需要触发同步的，减少加锁／解锁的一些CAS操作（比如等待队列的一些CAS操作），这种情况下，就会给线程加一个偏向锁。 如果在运行过程中，**遇到了其他线程抢占锁，则持有偏向锁的线程会被挂起，JVM会消除它身上的偏向锁，将锁恢复到标准的轻量级锁。**它通过消除资源无竞争情况下的同步原语，进一步提高了程序的运行性能。
偏向锁获取过程：
- 第一步，访问Mark Word中偏向锁的标识是否设置成1，锁标志位是否为01，确认为可偏向状态。
- 第二步，如果为可偏向状态，则测试线程ID是否指向当前线程，如果是，进入步骤5，否则进入步骤3。
- 第三步，如果线程ID并未指向当前线程，则通过CAS操作竞争锁。如果竞争成功，则将Mark Word中线程ID设置为当前线程ID，然后执行5；如果竞争失败，执行4。
- 第四步，如果CAS获取偏向锁失败，则表示有竞争。当到达全局安全点（safepoint）时获得偏向锁的线程被挂起，偏向锁升级为轻量级锁，然后被阻塞在安全点的线程继续往下执行同步代码。（撤销偏向锁的时候会导致stop the word）
- 第五步，执行同步代码。
偏向锁的释放：
偏向锁的撤销在上述第四步骤中有提到。偏向锁只有遇到其他线程尝试竞争偏向锁时，持有偏向锁的线程才会释放偏向锁，线程不会主动去释放偏向锁。偏向锁的撤销，需要等待全局安全点（在这个时间点上没有字节码正在执行），它会首先暂停拥有偏向锁的线程，判断锁对象是否处于被锁定状态，撤销偏向锁后恢复到未锁定（标志位为“01”）或轻量级锁（标志位为“00”）的状态。
偏向锁的适用场景
始终只有一个线程在执行同步块，在它没有执行完释放锁之前，没有其它线程去执行同步块，在锁无竞争的情况下使用，一旦有了竞争就升级为轻量级锁，升级为轻量级锁的时候需要撤销偏向锁，撤销偏向锁的时候会导致stop the word操作；
在有锁的竞争时，偏向锁会多做很多额外操作，尤其是撤销偏向所的时候会导致进入安全点，安全点会导致stw，导致性能下降，这种情况下应当禁用。
jvm开启/关闭偏向锁
开启偏向锁：-XX:+UseBiasedLocking -XX:BiasedLockingStartupDelay=0
关闭偏向锁：-XX:-UseBiasedLocking
3.4.3 轻量级锁
轻量级锁是由偏向锁升级来的，偏向锁运行在一个线程进入同步块的情况下，当第二个线程加入锁争用的时候，偏向锁就会升级为轻量级锁；
轻量级锁的加锁过程：
在代码进入同步块的时候，如果同步对象锁状态为无锁状态且不允许进行偏向（锁标志位为“01”状态，是否为偏向锁为“0”），虚拟机首先将在当前线程的栈帧中建立一个名为锁记录（Lock Record）的空间，用于存储锁对象目前的Mark Word的拷贝，官方称之为 Displaced Mark Word。
拷贝成功后，虚拟机将使用CAS操作尝试将对象的Mark Word更新为指向Lock Record的指针，并将Lock record里的owner指针指向object mark word。如果更新成功，则执行步骤4，否则执行步骤5。
- 如果这个更新动作成功了，那么这个线程就拥有了该对象的锁，并且对象Mark Word的锁标志位设置为“00”，即表示此对象处于轻量级锁定状态
- 如果这个更新操作失败了，虚拟机首先会检查对象的Mark Word是否指向当前线程的栈帧，如果是就说明当前线程已经拥有了这个对象的锁，那就可以直接进入同步块继续执行。否则说明多个线程竞争锁，当竞争线程尝试占用轻量级锁失败多次之后，轻量级锁就会膨胀为重量级锁，重量级线程指针指向竞争线程，竞争线程也会阻塞，等待轻量级线程释放锁后唤醒他。锁标志的状态值变为“10”，Mark Word中存储的就是指向重量级锁（互斥量）的指针，后面等待锁的线程也要进入阻塞状态。
3.4.4 不同锁之间的区别
JVM虚拟机对synchronized关键字的优化引入了自适应性CAS锁、偏向锁和轻量级锁机制。
测试用例代码见： git@github.com:oujie123/UnderstandingOfThread.git
