Volatile可见性
比如现在我们有这样一段代码：线程等待另一个线程将数据装载完就输出success，可是最后程序一直卡在while循环里没有往下执行。
public class VolatileDemo {
private static boolean flag = false;
//private static volatile boolean flag = false;
public static void main(String[] args) throws Exception{
new Thread(()->{
System.out.println("等待装载数据。。。。");
while(!flag){
}
System.out.println("====== SUCCESS =====");
}).start();
Thread.sleep(2000);
new Thread(()->{
System.out.println("开始装载");
flag = true;
System.out.println("装载完毕");
}).start();
}
}
/* 控制台输出
等待装载数据。。。。
开始装载
装载完毕
*/
造成这个问题出现的原因是jmm原子操作造成的。jmm内存模型就是java内存模型、准确的说是java线程内存模型。它和cpu缓存模型类似、是基于cpu缓存模型来建立的。
jmm一共有8种原子操作：
read(读取)：从主存读取数据
load(载入)：将内存数据读到工作内存
use (使用)：取出工作内存中的数据来计算
assign(赋值)：将计算好的值重新赋予到工作内存中
store(存储)：将工作内存数据写入主存
write(写入)：将store过去的变量值赋值给主内存中的变量
lock(锁定)：将主内存变量加锁，标识为线程独占状态
unlock(解锁)：将主存变量解锁，解锁后其他线程可以锁定该变量
可以看到线程1已经把变量副本加载到工作内存了，而线程2将计算后的值存到主存之后，却没有办法告诉线程1，所以就出现了线程安全问题。其实cpu与主存交互会经过"总线"这么一个概念，cpu为了解决这种数据不一致问题有两种方案：
总线加锁(性能太低)
早期cpu是对总线加锁，lock住这个数据，这样其它线程就没法对它读或写，直到这个线程用完这个数据 unlock之后才能被其他线程操作。也就是说从read开始后直到write结束才释放锁。
MESI缓存一致性协议
多个线程将同一个数据读取到各自的缓存区后，某个cpu修改了缓存的数据之后，会立马同步给主存，这都是汇编语言实现的。其他cpu通过总线嗅探机制(可以理解为监听)可以感知到数据的变化从而将自己缓存里的数据失效，从而去读取主存的值。所以mesi协议是从store开始加锁，锁的粒度更小，时间更短。实际上volatile就是这么实现可见性的。同时由于这中间过程中有store和write几步操作、还要让其他cpu缓存的数据置空都是要耗时的，可能这个过程中数据被别人改了，所以它是非原子操作的。
volatile与指令重排
指令重排
指定重排只会发生在多线程情况下，单线程是不会出现指定重排的。所谓的指令重排就是JVM在编译Java代码的时候，或者CPU在执行JVM字节码的时候，对现有的指令顺序进行排序优化。但不会对有依赖关系的做重排序。比如：
int a = 1;
int b = 2;
int c = a*c;
a 和 b 没有任何关系，所以它们的顺序无所谓，但是 c 依赖于a、b。只能存在于a、b后面，不然就乱套了。
在一个变量被volatile修饰后会被禁止指令重排，JVM会为我们做两件事：
1.在每个volatile写操作前插入StoreStore屏障，在写操作后插入StoreLoad屏障。
2.在每个volatile读操作前插入LoadLoad屏障，在读操作后插入LoadStore屏障。
Synchronization原子性
synchronized (a){} 锁住的就是（）里面的对象，多个线程对同一个对象操作时，就会形成互斥效果，如果是操作两个不同的对象，那么就不会受synchronized影响
public class SynchronizedDemo { public static void main(String[] args) { SynchronizedDemo s = new SynchronizedDemo(); Integer a = 1; Integer b = 2; new Thread(()->{ s.sync(a); }).start(); new Thread(()->{ s.sync(b); //s.sync(a); }).start(); } public void sync(Integer a){ synchronized (a){ System.out.println("线程："+Thread.currentThread().getName()+" 获取到变量"+a); try { Thread.sleep(8000); } catch (InterruptedException e) { e.printStackTrace(); } } } }
在jdk中，Synchronization同步是基于Monitor对象实现的，它里面主要有两个指令：
monitorenter： 插入到同步代码块的开始位置
monitorexit： 插入到同步代码块结束的位置
它们对应着JMM模型8大原子操作的lock与unlock，lock获取锁后把对象加载到工作内存，数据操作完之后重新赋值到主内存，最后unlock解锁。JVM需要保证每一个monitorenter都有一个monitorexit与之对应。为了保证在方法异常时，monitorenter和monitorexit指令也能正常配对执行，编译器会自动产生一个异常处理器，它的目的就是用来执行 异常的monitorexit指令。Monitor(监视器锁)是依赖操作系统的Mutex Lock(互斥锁)实现的，需要向内核申请资源，此时cpu将由用户态转换为内核态，它是一个低性能重量级锁。
jdk1.6对Synchronization的优化
jdk1.6之后就对这个synchronized锁进行了各种优化，如适应性自旋锁、轻量级锁和偏向锁，并默认开启偏向锁。从 无锁—>偏向锁—>轻量级锁—>重量级锁 ，锁升级的这个过程是不可逆的。被加锁的对象 jvm中为它定义了一种对应的数据结构，通过判断数据结构的对象头就知道目前是什么锁状态。例如通过倒数第三个bit的值 0/1 就知道目前是无锁还是偏向锁了。
三种锁的区别
偏向锁：仅有一个线程进入临界区(主要用于不存在锁竞争，而是一个线程多次获得锁时，为的使线程获取锁使用最小的代价(因为只需要修改获取锁的线程id就好了))
轻量级锁：多个线程交替进入临界区(当其他线程尝试竞争偏向锁时,会升级为轻量锁)
重量级锁：多个线程同时进入临界区
锁的升级过程
1. 无锁：此时还没有线程获取所得资源
2. 获取偏向锁：第一个线程获取到锁就会将前面的23个bit位修改为自己线程的id，将无锁升级为偏向锁。
3. 升级轻量锁：此时另一个线程尝试获取锁，发现锁里的线程id并不是自己的，就会释放锁，将对象头重的Mark Word替换为指向锁记录的指针，将其升级为轻量锁。
4. 若刚才将对象头重的Mark Word替换为指向锁记录的指针失败，则会自旋(循环等待)来获取锁，此时若有另一个线程同时竞争，锁会升级为重量级锁。
ReentrantLock
ReentrantLock和Synchronization一样是并发编程的核心，Synchronization是sun公司开发，而ReentrantLock是一个叫Doug Lea的人写出来的。它控制锁的状态是通过AQS(队列同步器)来实现的，主要用到了2点技术点。
1. volatile关键字
在AQS中定义一个volatile修饰的int变量state，有线程获取到锁之后state就加一，其他线程发现锁被占用之后就会进入等待队列。线程释放锁之后state就会减一，然后唤醒队列中的其他线程。
2. CAS(比较替换算法)
我们知道volatile不是线程安全的，那么如何保证只有一个线程对state在操作呢？其实就用到了CAS算法，它是一个无锁算法是乐观锁的体现。CAS需要有3个操作数：内存地址V，旧的预期值A，即将要更新的目标值B。只有A==V的时候才把V的值修改成B，否则不做任何操作。源码调用了Unsafe类的原子方法，都是被native修饰的，整个比较并替换的操作是一个原子操作。
ReentrantLock和Synchronization比较
ReentrantLock和synchronized在低并发的时候性能差距不大，高并发时ReentrantLock性能要稍微高一些。虽然sync做了优化但是在竞争激烈的时候还是会从偏向锁升级为重量级锁，是用户态切换到内核态的一个过程 比较消耗资源，lock有利用CAS自旋操作来实现锁则会稍微好一点。