JMM基础-计算机原理
Java 内存模型 即 Java Memory Model, 简称 JMM. JMM 定义了 Java虚拟机(JVM) 在计算机内存(RAM) 中的工作方式。 JVM 是整个计算机虚拟模型，所以 JMM 是隶属于 JVM 的，Java1.5版本对其进行了重构，现在的 Java 仍沿用了Java1.5的版本。JMM 遇到的问题与现代计算机中遇到的问题是差不多的。
物理计算机中的并发问题
物理机遇到的并发问题与虚拟机中的情况有不少相似之处, 物理机对并发的处理方案对于虚拟机的实现也有相当大的参考意义。
根据 《Jeff Dean在Google全体工程大会的报告》 我们可以看到
（以下案例仅做说明，并不代表真实情况。）
如果从内存中读取
1M的 int 型数据由CPU进行累加，耗时要多久？做个简单的计算，
1M的数据，Java里int型为32位，4个字节，共有1024 * 1024 / 4 = 262144个整数,
则 CPU 计算耗时：262144 *0.6 = 157 286 纳秒, 而我们知道(上图数据)从内存读取 1M 数据需要250000纳秒, 两者虽然有差距（当然这个差距并不小，十万纳秒的时间足够CPU执行将近二十万条指令了）, 但是还在一个数量级上。但是, 没有任何缓存机制的情况下，意味着每个数据都要从内存中读取，这样加上 CPU 读取一次内存需要 100纳秒, 262144 个数据从内存中读取到 CPU 加上计算时间 需要262144*100+250000 = 26 464 400 纳秒 , 这样就存在数量级上的差异了。
而且现实情况中绝大多数的运算任务都不可能只靠处理器 "计算" 就能完成, 处理器至少要与内存交互，如 读取运算数据、存储运算结果 等, 这个 I/O 操作基本上是无法消除的(无法仅靠寄存器来完成所有运算任务)。早期计算机中 CPU和内存 的速度是差不多的，但在现代计算机中，CPU 的指令速度远超内存的存取速度, 由于 计算机的存储设备与处理器 的运算速度有几个数量级的差距, 所以现代计算机系统都不得不加入一层读写速度尽可能接近处理器运算速度的 高速缓存 (Cache) 来作为内存与处理器之间的缓冲： 将运算需要使用到的数据复制到缓存中，让运算能快速进行，当运算结束后再从缓存同步回内存之中，这样处理器就无须等待缓慢的内存读写了。
L0寄存器是 L1一级缓存 的缓存，L1是L2的缓存，依次类推。每一层的数据都是来自它的下一层，所以每一层的数据都是下一层数据的子集。
在现代 CPU 上，一般来说L0， L1，L2，L3 都集成在 CPU 内部，而 L1 还分为一级数据缓存(Data Cache，D-Cache，L1d) 和 一级指令缓存(Instruction Cache，I-Cache，L1i) 分别用于存放数据和 执行数据的指令解码 。 每个核心拥有独立的运算处理单元、控制器、寄存器、L1、L2 缓存，然后一个 CPU的多个核心共享最后一层 CPU 缓存 L3。
Java内存模型(JMM)
从抽象的角度来看，JMM 定义了线程和主内存之间的抽象关系，线程之间的共享变量存储在主内存(Main Memory)，每个线程都有一个 私有 的本地内存(Local Memory)，本地内存中存储了该线程 读写共享变量的副本。本地内存是 JMM 的一个抽象概念，并不真实存在。 它涵盖了 缓存 、写缓冲区、寄存器 以及其他的硬件和编译器优化。
可见性
可见性是指当多个线程访问了同一个变量时，一个线程修改了变量的值，其他线程能够立即看得到修改的值。
由于线程对变量的所有操作都必须在工作内存中进行，而不能直接读写主内存中的变量，那么对于共享变量 V，它们首先是在自己的工作内存，之后再同步到主内存。可是并不会及时的刷新到主内存中，而是会有一定的时间差。 显然，这个时候线程A 对 变量V 的操作对于 线程B 而言就不具备可见性了。
解决共享对象可见性，我们可以使用 volatile 关键字或者 加锁
原子性
原子性：即一个操作或者多个操作，要么全部执行并且执行的过程中不被任何因素打断，要么就都不执行。
CPU 资源的分配是以线程为单位的，并且是分时调用，操作系统运行某个进程执行一小段时间，例如50毫秒，过了50毫秒操作系统就会重新选择一个进程来执行 (我们称为 "任务切换")，这个50毫秒称为时间片，而任务的切换大多是在时间片段结束以后。
那么线程切换为什么会带来bug呢？因为操作系统做任务切换，可以发生在任意一条 CPU指令 执行完！！注意，是 CPU 指令，CPU 指令，CPU 指令，而不是高级语言里的一条语句。比如: count++ ，在Java里就是一句话，而高级语言里一条语句往往需要多个 CPU 指令 来完成。其实count++包含了三个CPU指令。
volatile
volatile特性
可以把对volatile变量的单个读/写，看成是使用同一个锁对这些单个读/写操作做了同步。
所以volatile变量自身具有下列特性：
- 可见性 ： 对一个volatile变量的读，总能看到(任意线程) 对这个
volatile变量最后的写入 - 原子性： 对任意单个
volatile变量的读写具有原子性，但是volatile++这种复合操作不具有原子性。
volatile 虽然能够保证执行完及时把变量刷新到主内存中，但对于 count++ 这种非原子性，多指令的情况，由于线程切换，线程 A 刚把 count = 0 加载到工作内存中，线程 B 就开始工作了， 这样就导致 线程 A 和 B 执行完的结果都是 1 ，都写到主内存中，主内存的结果还是1 而不是 2
volatile实现原理
通过对 OpenJDK 中的 unsafe.cpp 源码的分析，会发现 volatile 关键字修饰的变量会存在一个 Lock: 的前缀。
Lock 前缀，Lock不是一种内存屏障，但是它能完成类似内存屏障的功能，lock会对 CPU 总线和告诉缓存加锁，可以理解为 CPU指令级 的一种锁。
同时，该指令会讲当前处理器缓存行的数据只接写回到系统内存中，这个写会内存的操作会使 CPU 其他缓存了改地址的数据无效。
volatile在DCL上的作用
volatile是会保证被修饰的变量的可见性和 有序性，保证了单例模式下，保证在创建对象的时候的执行顺序一定是：
- 分配内存空间
- 实例化对象
instance - 把
instance引用指向已分配的内存空间,此时instance有了内存地址,不再为null了
从而保证了instance要么为null 要么是已经完全初始化好的对象.
synchronized
synchronized使用方式
synchronized实现原理
synchronized 在jvm 里的实现都是基于进入和退出 Monitor 对象来实现方法同步和代码块同步的，虽然具体实现细节不一样，但是都可以通过成对的MonitorEnter和MonitorExit指令来实现。
对同步代码块， MonitorEnter 指令插入在同步代码块的开始位置，当代码执行到该指令时，将会尝试获取 Monitor 对象的所有权，即尝试获得该对象的锁，而 MonitorExit 指令在插入在方法结束处和异常处，JVM 保证每个 MonitorEnter 必须有对应的 MonitorExit
对同步方法，从同步方法反编译的结果来看，方法的同步并没有通过指令monitorenter和monitorexit来实现，相对于普通方法，其常量池中多了ACC_SYNCHRONIZED标示符
JVM 就是通过标识符来实现方法的同步的：当方法被调用时，调用指令将会检查方法 ACC_SYNCHRONIZED 访问标志是否被设置，如果设置了，执行线程讲先获取 monitor， 获取成功之后才能执行方法体，方法执行完成之后再释放 monitor。在方法执行期间，其他任何线程都无法再获取到同一个 monitor
synchronized 使用的锁是放在 Java对象头 里面的
MarkWord，MarkWord里默认数据是存储对象的HashCode等信息，
synchronized的优化
synchronized 引入了自旋锁，自适应自旋锁，锁粗化，偏向锁，轻量级锁，逃逸分析等技术，来减少锁操作的开销，
- 逃逸分析：如果证明一个对象不会逃逸方法外或者线程外，则可针对此变量进行优化，同步消除
synchronization Elimination，如果一个对象不会逃逸出线程，则对此变量的同步错失可以消除。 - 锁消除 ： 虚拟机的运行时编译器在运行时如果检测到一些要求同步的代码上不可能发生共享数据竞争，则会去掉这些锁。
- 锁粗化：将临近的代码块用同一个锁合并起来，消除无意义的锁获取和释放，提高程序运行性能
优化后synchronized锁的分类
一共有四种状态，无锁状态，偏向锁状态，轻量级锁状态和重量级锁状态，它会随着竞争情况逐渐升级。锁可以升级但不能降级，目的是为了提高获得锁和释放锁的效率。
偏向锁
目的：大多数情况下，锁不仅不存在多线程竞争，而且总是由同一线程多次获得，为了让线程获得锁的代价更低而进入了偏向锁，减少不必要的 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 world 操作。
在有锁竞争时，偏向锁会做很多额外操作，尤其是撤销偏向锁的时候会导致进入安全点，安全点会导致stw，导致性能下降，这种情况下应当禁用。
jvm开启/关闭偏向锁
开启偏向锁：-XX:+UseBiasedLocking -XX:BiasedLockingStartupDelay=0
关闭偏向锁：-XX:-UseBiasedLocking
轻量级锁
轻量级锁是由偏向锁升级来的，偏向锁运行在一个线程进入同步块的情况下，当第二个线程加入锁争用的时候，偏向锁就会升级为轻量级锁。
轻量级锁的加锁过程
在代码进入同步块的时候，如果同步锁状态为无锁状态，并且不允许进行偏向锁( 锁标志位为 "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 中存储的就是指向重量级锁（互斥量）的指针，后面等待锁的线程也要进入阻塞状态。
自旋锁
原理
如果持有锁的线程能在很短时间内释放锁资源，那么那些等待竞争锁的线程就不需要做内核态和用户态之间的切换进入阻塞挂起状态，它们只需要等一等（自旋），等持有锁的线程释放锁后即可立即获取锁，这样就避免用户线程和内核的切换的消耗。
是线程自旋是需要消耗CPU的，说白了就是让CPU在做无用功，线程不能一直占用CPU自旋做无用功，所以需要设定一个自旋等待的最大时间。
如果持有锁的线程执行的时间超过自旋等待的最大时间扔没有释放锁，就会导致其它争用锁的线程在最大等待时间内还是获取不到锁，这时争用线程会停止自旋进入阻塞状态。
自旋锁的优缺点
自旋锁尽可能的减少线程的阻塞，这对于锁的竞争不激烈，且占用锁时间非常短的代码块来说性能能大幅度的提升，因为自旋消耗会小于线程阻塞挂起操作的消耗。
但如果锁的竞争激烈，或者持有锁的线程需要长时间占用锁执行同步块，这时候就不适合自旋锁了，因为自旋锁在获取锁前一直都是占用 CPU 做无用功，线程自旋的消耗大于线程阻塞挂起操作的消耗，其它需要 CPU 的线程又不能获取到 CPU，造成 CPU 的浪费。
自旋锁时间阈值
自旋锁的目的是为了占着CPU的资源不释放，等到获取到锁立即进行处理。但是如何去选择自旋的执行时间呢？如果自旋执行时间太长，会有大量的线程处于自旋状态占用CPU资源，进而会影响整体系统的性能。因此自旋次数很重要。
JVM对于自旋次数的选择，jdk1.5默认为10次，在1.6引入了适应性自旋锁 ，适应性自旋锁意味着自旋的时间不在是固定的，而是由前一次在同一个锁上的自旋时间以及锁的拥有者的状态来决定，基本认为一个线程上下文切换的时间是最佳的一个时间。
JDK1.6中-XX:+UseSpinning开启自旋锁；JDK1.7后，去掉此参数，由jvm控制；
