1. 并发编程的挑战
2. 并发编程需要解决的两大问题
3. 线程通信机制
4. 内存模型
5. volatile
6. synchronized
7. CAS
8. 锁的内存语义
9. DCL 双重检查锁定
10. final
11. txt
java 内存模型（JMM）
并发编程的挑战
线程上下文切换
定义：CPU通过给每个线程分配CPU时间片来实现多线程机制，使得即使是单核处理器也支持多线程。CPU通过时间片分配算法来循环执行任务，任务从保存到再次加载的过程就是一次上下文切换
多线程不一定快，当并发执行累加操作不超过百万次时速度比串行执行累加操作要慢。因为线程有创建和上下文切换开销
测试上下文切换的次数和时长
使用Lmbench3可以测量上下文切换的时长
使用vmstat 可以测量上下文切换的次数CS(Content Switch)
减少上下文切换
无锁并发编程
多线程竞争锁时，会引起上下文切换，不用锁，如将数据的ID按照Hash算法取摸分段，不同的线程处理不同段的数据
CAS算法
JAVA的Atomic包使用CAS算法来更新数据，而不需要加锁
使用最少线程
避免创建不需要的线程，减少线上大量WAITING的线程
协程
在单线程里实现多任务的调度，并在单线程里维持多个任务间的切换
死锁
避免死锁的常用方法
避免一个线程同时获取多个锁
避免一个线程在锁内同时占用多个资源
尝试使用定时锁，使用lock.tryLock(timeout)来替代使用内部锁机制
数据库锁，加锁解锁必须在一个数据库连接里，否则会出现解锁失败
原因
互斥
不可剥夺
请求和保持
循环等待
对应措施
将独占性资源改成虚拟资源
占有一个的同时还请求另一个锁，前一个释放
预先分配
有序分配
资源限制的挑战
资源限制了程序的执行速度，受限制于资源，仍然是在串行，并且额外增加了上下文切换和资源调度所需要的时间
资源限制
硬件
带宽的上传下载速度
硬盘读写速度
CPU处理速度
软件
数据库的连接
socket连接数
如何解决资源限制
硬件
集群
软件
资源池复用资源
资源限制情况下如何并发编程
根据不同的资源限制调整程序的并发度
并发编程需要解决的两大问题
线程之间如何通信
线程之间如何同步
同步是指程序中用于控制不同线间操作发生相对顺序的机制
线程通信机制
内存共享
隐式通信，显示同步
java采用
JMM通过控制主内存和每个线程的本地内存之间的交互，来提供内存可见性保证
处理器：内存屏障
as-if-serial 语义保证单线程内程序的执行结果不被改变
happens-before 关系保证正确同步的多线程程序的执行结果不被改变
理论：顺序一致性
因为隐式通信，所以会遇到内存可见性问题（这里的内存是指堆内存——实例域、静态域和数组元素，不包括局部变量、方法定义参数和异常处理参数）
4种方式
1. A线程写volatile变量，随后B线程读这个volatile变量
2. A线程写volatile变量，随后B线程用CAS更新这个volatile变量
3. A线程用CAS更新这个volatile变量，随后B线程用CAS更新这个volatile变量
4. A线程用CAS更新这个volatile变量，随后B线程读这个volatile变量
消息传递
显示通信，隐式同步
内存模型
处理器内存模型
硬件级的内存模型
重排序
为了程序的性能，处理器、编译器都会对程序进行重排序处理，但是会产生内存可见性问题
背景
现代处理器使用写缓冲区临时保存向内存写入数据，避免由于处理器停顿下来等待向内存写入数据而产生的延迟，但仅对它所在的处理器可见，导致处理器对内存的读写顺序不一定与内存实际发生的读写顺序一致！因此允许对写-读操作进行重排序
问题
重排序在多线程环境下可能会导致数据不安全
3大类型
编译器优化的重排序
intra-thread semantics 在单线程环境下不能改变程序运行的结果的条件下才能重排序
指令级并行的重排序
存在数据依赖关系的不允许重排序
内存系统的重排序
因为处理器使用缓存和读写缓冲区，使得加载和存储操作看上去是乱序的
处理器的重排序规则
常见的处理器都允许Store-Load重排序，因为使用了写缓冲区
常见的处理器都不允许对存在数据依赖的操作重排序，遵守数据依赖性，遵循as-if-serial语义
5大类
Load-Load
Load-Store
Store-Store
Store-Load
数据依赖
如果两个操作访问同一个变量，并且这两个操作中有一个为写操作，此时两个操作之间就存在数据依赖性
3大类
写后读
读后写
写后写
处理器的内存屏障
内存屏障是一组处理器指令，用于实现对内存操作的顺序限制
为了保证内存可见性，Java编译器再生产指令序列的适当位置会插入内存屏障制定来禁止特定类型的处理器重排序
内存屏障（Memory Barrier，或有时叫做内存栅栏，Memory Fence）是一种CPU指令，用于控制特定条件下的重排序和内存可见性问题。
4大类内存屏障指令
LoadLoad Barriers
LoadStore Barriers
StoreStore Barriers
StoreLoad Barriers
全能型的屏障，同时具有其他三个屏障的效果，但执行该屏障开销会很大，因为Buffer Fully Flush
x86处理器只会对写读作重排序，故只有一个屏障StoreLoad
处理器遵循as-if-serial语义 ，单线程满足顺序一致性
不管怎么重排序（编译器和处理器为了提高并行度），单线程程序的执行结果不能改变。编译器，runtime和处理器都必须遵守as-if-serial语义
为了遵循协议，编译器和处理器不会对存在数据依赖关系的操作做重排序。
单线程程序中，对存在控制依赖的操作重排序，不会改变执行结果，顾as-if-serial允许对控制依赖的操作重排序，但在多线程程序中，控制依赖操作重排序可能会改变程序运行结果
as-if-serial语义使得单线程程序员无须担心重排序会干扰他们，也无需担心内存可见性问题
顺序一致性内存模型
多线程环境下的理想化的理论参考模型，处理器的内存模型和编程语言的内存模型都会以顺序一致性内存模型作为参照
为程序提供了极强的内存可见性保证
数据竞争
定义
在一个线程中写一个变量，在另一个线程中读同一个变量，而且写和读没有通过同步来排序
当程序未正确同步时，就可能会存在数据竞争
如果程序是正确同步的，程序的 执行将具有顺序一致性
这里的同步是广义上的同步，包括常用同步原语的正确使用（Synchronized、volatile 、lock和 final）
特性
一个线程中的所有操作必须按照程序的顺序来执行
不管程序是否同步，所有程序都只能看到一个单一的操作执行顺序，每个操作都必须原子执行且立即对所有的线程可见
JMM
语言级的内存模型
JMM的内存可见性保证3方面
基本方针：在不改变（正确同步的）程序执行结果的前提下，尽可能地为编译器和处理器的优化打开方便之门（重排序）
1. 单线程程序。编译器，runtime和处理器都必须遵守 as-if-serial 语义共同确保单线程程序的执行结果与该程序在顺序一致性模型中的执行结果相同
2. 正确同步的多线程程序。happens-before 保证正确同步的多线程程序，程序的执行结果与该程序在顺序一致性内存模型中执行结果相同，JMM通过限制OR禁止编译器和处理器的重排序来为程序员提供内存可见性保证。（内存屏障）
3. 未同步或未正确同步的多线程程序。JMM只提供最小安全性保障：保证线程读到的值不是无中生有的，要么是之前某个线程写入的值，要么是默认值（0，null, false），但并不保证线程读取到的值一定是正确的。
happens-before
JMM中最核心的理论，保证跨线程的内存的可见性（可以在一个线程之内，也可以再不用线程之间）通过内存屏障实现
背景
JMM设计的两大核心目标
为程序员提供足够强的内存可见性保证
对编译器和处理器的约束尽可能放松（只要不改变程序的执行结果，编译器处理器怎么优化都行）首先保证正确性，然后再追求执行效率
简单定义
在JMM中，如果一个操作执行的结果需要对另一个操作可见，那么这两个操作之间必须存在happens-before关系
定义
JMM对程序员保证
如果一个操作happens-before另一个操作，那么第一个操作的执行结果对第二个操作可见，而且第一个操作的执行顺序排在第二个操作之前
JMM对编译器和处理器重排序的约束原则
两个操作之间存在happens-before关系,并不意味着一定要按照happens-before原则判定的顺序来执行。如果重排序之后的执行结果与按照happens-before关系来执行的结果一致，那么这种重排序并不非法。
原生java满足8大规则
1. 程序顺序规则：一个线程内，按照代码顺序，书写在前面的操作先行发生于书写在后面的操作；
2. 监视器锁规则：一个unLock操作先行发生于后面对同一个锁额lock操作；
3. volatile变量规则：对一个变量的写操作先行发生于后面对这个变量的读操作；
4. 传递规则：如果操作A先行发生于操作B，而操作B又先行发生于操作C，则可以得出操作A先行发生于操作C；
5. 线程启动规则：Thread对象的start()方法先行发生于此线程的每个一个动作；
6. 线程中断规则：对线程interrupt()方法的调用先行发生于被中断线程的代码检测到中断事件的发生；
7. 线程终结规则：线程中所有的操作都先行发生于线程的终止检测，我们可以通过Thread.join()方法结束、Thread.isAlive()的返回值手段检测到线程已经终止执行；
8. 对象终结规则：一个对象的初始化完成先行发生于他的finalize()方法的开始；
happens-before与JMM的关系
happens-before规则是JMM呈现给程序员的视图
一个happens-before规则对应于一个或者多个编译器和处理器重排序规则
happens-before VS as-if-serial
as-if-serial 语义保证单线程内程序的执行结果不被改变；程序顺序执行
happens-before 关系保证正确同步的多线程程序的执行结果不被改变；happens-before制定的顺序执行
三者的区别和联系
JMM VS 处理器内存模型 VS 顺序一致性
处理器内存模型（x86 TSO PSO）和语言内存模型（JAVA C++）都比顺序一致性内存模型弱，换来的是高效的执行性能。
常见的处理器内存模型比常用的语言内存模型弱
处理器的内存模型和语言内存模型都会以顺序一致性内存模型作为参照
JMM VS 处理器内存模型
JMM屏蔽了不同处理器内存模型的差异，为程序员呈现了一个一致的内存模型
常见的处理器内存模型比JMM弱（限制少，都能重排序，追求性能），Java编译器在生成字节码时，会在执行指令序列的适当位置插入内存屏障来限制处理器的重排序
JMM在不同的处理器中需要插入的内存屏障的数量和种类也不同，从而展示了一个一致的内存模型
JMM VS 顺序一致性
1. 顺序一致性模型保证单线程内的操作会按照程序的顺序执行，而JMM不保证（临界区的重排序，但是不允许临界区的代码溢出到临界区之外，那样会破坏监视器的语义）
2. 顺序一致性模型保证所有的线程只能看到一致的整体操作执行顺序，而JMM不保证（因为线程的本地缓存没有及时刷新到主内存中，其他线程不可见）
3. 顺序一致性模型保证对所有的内存读写操作都具有原子性，而JMM不保证对64位的long和double型变量的写操作具有原子性
4. as if serial 和 hapens-before语义 满足顺序一致性（程序的执行结果与该程序在顺序一致性模型中的执行结果相同）
Java 并发机制的底层原理实现
volatile
synchronized
原子操作
处理器
使用总线锁保证原子性
使用缓存锁保证原子性
JMM
锁
CAS
final
2大重排序规则
1. 在构造函数内对一个final域的写入，与随后把这个被构造对象的引用赋值给一个引用变量，这两个操作之间不能重排序
2. 初次读一个包含final域的对象的引用，与随后初次读这个final域，这两个操作之间不能重排序。
final语义在处理器中的实现
写final域：编译器会在构造函数final域写之后,return之前插入StoreStore屏障
读final域：编译器在读final域的操作前面插入一个LoadLoad屏障
x86处理器只会对写读作重排序，故只有一个屏障StoreLoad，所以对final域的读写不会插入任何内存屏障
禁止重排序保证了2点
在对象引用为任意线程可见之前，对象的final域已经被正确初始化过了，而普通域不具有这个保证
在读一个对象的final域之前，一定会先读包含这个final域的对象的引用
还需要的另一个保证
在构造函数内部，不能让这个被构造函数的引用为其他线程可见，也就是对象引用不能在构造函数中溢出OR溢出
DCL 双重检查锁定(Double-Checked Locking）
在Java多线程中有时候需要采用延迟初始化来降低初始化类和创建对象的开销
双重检查锁定是常见的延迟初始化技术，但是它是一个错误的用法
历史
1. 非线程安全：普通“懒汉式”单例模式的实现
2. 同步方法：Synchronized,线程安全但性能开销大
3. 采用DCL降低同步开销，两次判断为null可以提高性能，但是有重排序问题
4. volatile实现线程安全的静态字段和实例字段的延迟初始化
5. 基于类初始化的解决方法（静态内部类）实现的静态字段的延迟初始化
问题根源
1. 分配对象的内存空间；2.初始化对象；3.设置instance指向刚分配的内存地址； 其中2和3可能发生重排序
解决方案
禁止重排序
基于volatile的解决方案
静态字段和实例字段都能实现延迟初始化
允许重排序
允许重排序，但不允许其他线程看到这个重排序。happens-before 监视器锁规则
基于类初始化的解决方案
利用classloader的机制来保证初始化instance时只有一个线程，JVM在类初始化阶段会获取一个初始化锁，这个锁可以同步多个线程对同一个类的初始化。并且每个线程至少获得一次锁来确保这个类已经被初始化了。
只能让静态字段实现延迟初始化
单例模式
立即加载/饿汉模式
静态实例初始化
私有构造方法
静态getInstance
延迟加载/懒汉模式
静态实例声明
私有构造方法
静态getInstance{
if(是null){
初始化
}
}
解决
声明synchronized关键字
尝试同步代码块
针对重要代码进行单独的同步
使用DCL双检查锁机制
使用静态内置类实现单例模式
序列化和反序列化的单例模式实现
readResolve()
使用static代码块来实现单例模式
使用enum枚举数据类型实现单例模式
锁的内存语义
锁的功能
让临界区互斥执行
锁的内存语义
锁的释放与获取的内存语义
释放锁的线程向获取同一个锁的线程发送消息
线程释放锁时，JMM会把该线程对应的本地内存中的共享变量刷新到主内存
线程获取锁时，JMM会把该线程对应的本地内存置为无效，从而使被监视器保护的临界区代码必须从内存中读取共享变量
volatile的写读与 锁的释放获取 有相同的内存效果：volatile写和锁的释放有相同的内存语义，volatile读和锁的获取有相同的内存语义。这也是增强volatile的原因，提供了一种比锁更轻量级的线程之间的通信机制。
锁的释放与获取的内存语义两种实现
1. 利用volatile 变量的 写读 锁具有的内存语义
2. 利用CAS（AQS里面的一个调用本地的方法，调用处理器cmpxchg指令添加lock前缀）所附带的volatile读和volatile写的内存语义
公平锁和非公平锁的内存语义
公平锁和非公平锁释放时，最后都要写一个volatile变量state
公平锁获取时，首先会去读volatile变量。
非公平锁获取时，首先会用CAS更新volatile变量，CAS同时具有volatile读和volatile写的内存语义
JUC 包的实现
通用化的实现模型
1. 声明共享变量为volatile
2. 使用CAS的原子条件更新来实现线程之间的同步
3. 同时配合volatile的读写和CAS具有的volatile读写的内存语义来实现线程之间通信
4. 基础类基于123：AQS、非阻塞结构、原子变量类
5. 高层类基于4：Lock、同步器、阻塞队列、Executor、并发容器
锁的升级与对比
JAVA1.6中，锁一共有4中状态，级别从低到高依次是：无锁状态，偏向锁状态，轻量级锁状态和重量级锁状态
这几种状态会随着竞争情况的逐渐升级，锁可以升级但是不能降级，这种策略是为了提高获得锁和释放锁的效率
无锁
偏向锁
背景
大多数情况下，锁不仅不存在多线程竞争，而且总是由同一线程多次获得，为了让线程获得锁的代价更低而引入了偏向锁。
偏向锁使用了一种等到竞争出现才释放锁的机制。当其他线程尝试竞争偏向锁时持有偏向所的线程才会释放锁。
重要操作
获得偏向锁
1. 一个线程访问同步块并获得锁时，会在对象头和栈帧中的锁记录里存储锁偏向的线程ID
2. 以后该线程在进入和退出同步块时不需要进行CAS操作来加锁和解锁，只需要看对象头Mark Word里面是否存储着指向当前线程的偏向锁，如果有，表示线程已经获得了锁，如果没有，下一步
3. 判断Mark Word中偏向锁的标识是否设置成1(表示当前是偏向锁)，如果没有，使用CAS竞争锁； 如果有，则尝试使用CAS将对象头的偏向锁线程ID指向当前线程
撤销偏向锁
其他线程访问同步块，尝试获得偏向锁，失败，启动撤销偏向锁
1. 首先暂停持有偏向锁的线程
2. 解锁，将线程ID设为空
3. 恢复线程
关闭偏向锁
java 7里默认是启用的
关闭延迟
XX:BiasedLockingStartupDelay=0
关闭偏向锁,程序默认会进入轻量级锁
XX:UseBiasedLocking=false
应用
优点
加锁和解锁不需要额外的消耗，和执行非同步方法相比仅存在纳秒级的差别
缺点
如果线程间存在锁竞争，会带来额外的锁撤销的消耗
使用场景
适用于只有一个线程访问同步块场景
轻量级锁
注意，轻量级锁解锁失败,锁就会膨胀成为重量级锁，就不会恢复到轻量级锁状态，当线程处于这个状态，其他线程试图获取锁时，会被阻塞住，当持有所得线程释放锁之后会唤醒这些线程，被唤醒的线程会进行新一轮的夺锁之争。
重要操作
轻量级加锁
1. 访问同步块，分配空间并复制Mark Word到栈 Displaced Mark Word
2. CAS尝试将对象头中Mark Word替换为指向锁记录的指针，成功则获得锁，执行同步体；失败表示其他线程竞争锁，当前线程通过使用自旋来获取锁
轻量级解锁
1. 解锁时，会使用原子的CAS操作将Displaced Mark Word替换回到对象头
2. 如果成功，表示没有竞争发生，如果失败，表示当前锁存在竞争(因为别的线程在争夺锁)，锁就会膨胀成为重量级锁（别的线程阻塞），释放锁并唤醒等待的线程
应用
优点
竞争的线程不会阻塞，提高了程序的响应速度
缺点
如果始终得不到锁竞争的线程，使用自旋会消耗CPU
使用场景
追求响应时间
同步块执行速度非常快
重量级锁
应用
优点
线程竞争不使用自旋，不会消耗CPU
缺点
线程阻塞，响应时间缓慢
使用场景
追求吞吐量
同步块执行速度较长
CAS
Compare And Swap, 整个JUC体系最核心、最基础理论，Java中通过锁和CAS实现原子操作
内存地址V,旧的预期值A，要更新的值B，当且仅当内存地址V中的值等于旧的预期值A时才会将内存值V得值修改为B，否则什么也不干
native中存在四个参数
JVM中的CAS操作利用了处理器提供的CMPXCHG指令实现的。
缺陷
ABA问题
检查不到值的变化，实际上却变化了
解决方案
变量前追加版本号版本号
AtomicStampedReference
这个类的compareAndSet方法的作用是首先检查当前引用是否等于预期引用，并且检查当前标志是否等于预期标志，如果全部相等，则以原子的方式将该引用和该标志的值设置为给定的更新值。
循环时间太长
自旋CAS如果长时间不成功，会给CPU带来非常大的执行开销
解决方法
JVM如果能支持处理器提供的pause指令，那么效率一定会提升
pause作用
1. 可以延迟流水线执行指令（depipeline），使CPU不会消耗过多的执行资源
2. 避免在退出循环的时候因内存顺序冲突而引起的CPU流水线被清空，从而提高CPU的执行效率
只能保证一个共享变量原则操作
对多个共享变量操作时，CAS无法保证操作的原子性，需要用锁
解决方案
AtomicReference类保证引用对象之间的原子性，可以把多个变量放在一个对象里来进行CAS操作
原子操作类Atomic
java.util.concurrent.atomic里的原子操作类提供了线程安全地更新一个变量的方式
4大类型13个原子操作类
基本类型类
AtomicBoolean
AtomicInteger
AtomicLong
数组
AtomicIntegerArray
AtomicLongArray
AtomicReferenceArray
引用
AtomicReference
AtomicReferenceFieldUpdater
AtomicMarkableReference
属性
AtomicIntegerFieldUpdater
AtomicLongFieldUpdater
AtomicStampedReference
核心底层
CAS
Unsafe只提供了3中CAS方法
final native boolean compareAndSwapObject()
final native boolean compareAndSwapInt()
final native boolean compareAndSwapLong()
CAS V.S. 锁
JVM中除了偏向锁，其他锁（轻量级锁、互斥锁）的实现方式都用了循环CAS，即当一个线程想进入同步块的时候使用循环CAS的方式来获取锁，当它退出同步块的时候使用循环CAS释放锁。
synchronized
同步、重量级锁
只有使用Synchronized线程处于阻塞，其他Lock, AQS, LockSupport等线程都是处于等待状态
原理
synchronized可以保证方法或者代码块在运行时，同一时刻只有一个方法可以进入到临界区，同时它还可以保证变量的内存可见性。
锁对象
1. 普通同步方法锁，是当前实例对象
2. 静态同步方法，锁是当前类的class对象
3. 同步方法块，锁是括号里面的对象
java中的每一个对象都可以作为锁
实现机制
Java对象头
synchronized用的锁是保存在Java对象头里的
包括两部分数据
Mark Word(标记字段)
Mark Word被设计成一个非固定的数据结构以便在极小的空间内存存储尽量多的数据，它会根据对象的状态复用自己的存储空间
包括：哈希码（HashCode）、GC分代年龄、锁状态标志、线程持有的锁、偏向线程ID、偏向时间戳
Klass Pointer(类型指针)
monitor
java 中 Object和Class中都关联了一个Monitor，一个monitor只能被一个线程拥有
Owner 活动线程
初始时为NULL表示当前没有任何线程拥有该monitor record, 当线程成功拥有该锁后保存线程唯一标识，当锁被释放时又设置为NULL
实现
同步代码块采用 monitorenter、monitorexit指令显示的同步
同步方法使用ACC_SYNCHRONIZED标记符隐式的实现
锁优化
自旋锁
该线程等待一段时间，不会被立即挂起，循环看持有锁的线程是否会很快释放锁
自旋数字难以控制（XX: preBlockSpin）
存在理论：线程的频繁挂起、唤醒负担较重，可以认为每个线程占有锁的时间很短，线程挂起再唤醒得不偿失。
缺点
自旋次数无法确定
适应性自旋锁
自旋的次数不再是固定的，它是由前一次在同一个锁上的自旋时间及锁的拥有者的状态来决定
自旋成功，则可以增加自旋次数，如果获取锁经常失败，那么自旋次数会减少
锁消除
若不存在数据竞争的情况，JVM会消除锁机制
判断依据
变量逃逸
锁粗化
将多个连续的加锁、解锁操作连接在一起，扩展成一个范围更大的锁。例如for循环内部获得锁
轻量级锁
在没有多线程竞争的前提下，减少传统的重量级锁使用操作系统互斥量产生的性能消耗
通过CAS（CompareandSwap）,即比较并替换，来获取和释放锁
缺点
在多线程环境下，其运行效率比重量级锁还会慢
性能依据
对于绝大部分的锁，在整个生命周期内部都是不会存在竞争的
偏向锁
为了在无多线程竞争的情况下尽量减少不必要的轻量级锁执行路径
主要尽可能避免不必要的CAS操作，如果竞争锁失败，则升级为轻量级锁
volatile
特性
volatile可见性：对一个volatile的读，总可以看到任意线程对这个变量最终的写
volatile原子性：volatile对单个读/写具有原子性（64位Long、Double）,但是复合操作除外，例如 i++
volatile有序性：编译器在生成字节码时，会在指令序列中插入内存屏障来禁止特定类型的处理器重排序。
内存语义
当写一个volatile变量时，JMM会把该线程对应的本地内存中的共享变量值立即刷新到主内存中
当读一个volatile变量时，JMM会把该线程对应的本地内存设置为无效，直接从主存中读取共享变量
volatile的写-读与 锁的释放-获取 有相同的内存效果：volatile写和锁的释放有相同的内存语义，volatile读和锁的获取有相同的内存语义。这也是增强volatile的原因，提供了一种比锁更轻量级的线程之间的通信机制。
重排序规则
1. 当第二个操作是volatile写操作时，不管第一个操作是什么，都不能重排序
2. 当第一个操作是volatile读操作时，不管第二个操作是什么，都不能重排序
3. 当第一个操作是volatile写操作，第二个操作是volatile读操作，不能重排序
内存语义的实现
内存屏障
内存屏障是一组处理器指令，用于实现对内存操作的顺序限制
基于保守策略的JMM内存屏障插入策略
在每个volatile写操作的前面插入一个StoreStore屏障
保证之前的都能刷新到主存
在每个volatile写操作的后面插入一个StoreLoad屏障
保证先写后读，能提高效率
在每个volatile读操作的后面插入一个LoadLoad屏障
在每个volatile读操作的后面插入一个LoadStore屏障
实际执行时，只要不改变volatile写-读的内存语义，编译器可以根据具体情况省略不必要的屏障
x86处理器只会对写读作重排序，故只有一个屏障StoreLoad即可正确实现volatile写-读的内存语义
操作系统语义
主存、高速缓存（线程私有）缓存一致？
解决方案
通过在总线加 Lock 锁的方式，有些是缓存锁定
通过缓存一致性协议 MESI协议（修改、独占、共享、无效）
实现原则
Lock前缀指令会引起处理器缓存回写到内存
一个处理器的缓存回写到内存会导致其他处理器的缓存失效
内存模型
内存屏障 限制重排序
happens-before中的volatile规则
volatile VS synchronized
volatile是轻量级的synchronized
使用恰当，它比synchronized使用和执行成本更低，因为不会引起线程上下文的切换和调度
12. 参考网址
- 参考来源：http://cmsblogs.com/wp-content/resources/img/sike-juc.png
- 《Java并发编程的艺术》_方腾飞PDF 提取码：o9vr
- http://ifeve.com/the-art-of-java-concurrency-program-1/
- Java并发学习系列-绪论
- Java并发编程实战
- 死磕 Java 并发精品合集
