java 多线程 备忘

java 多线程 备忘

由于计算机的存储设备与处理器的运算能力之间有几个数量级的差距，所以现代计算机系统都不得不加入一层读写速度尽可能接近处理器运算速度的高速缓存（cache）来作为内存与处理器之间的缓冲：将运算需要使用到的数据复制到缓存中，让运算能快速进行，当运算结束后再从缓存同步回内存之中，这样处理器就无需等待缓慢的内存读写了。

基于高速缓存的存储交互很好地解决了处理器与内存的速度矛盾，但是引入了一个新的问题：缓存一致性（Cache Coherence）。在多处理器系统中，每个处理器都有自己的高速缓存，而他们又共享同一主存，如下图所示：多个处理器运算任务都涉及同一块主存，需要一种协议可以保障数据的一致性，这类协议有MSI、MESI、MOSI及Dragon Protocol等

为了使得处理器内部的运算单元能尽可能被充分利用，处理器可能会对输入代码进行乱序执行（Out-Of-Order Execution）优化，处理器会在计算之后将对乱序执行的代码进行结果重组，保证结果准确性。与处理器的乱序执行优化类似，Java虚拟机的即时编译器(JIT)中也有类似的指令重排序（Instruction Recorder）优化。

Java内存模型(JMM)

内存模型可以理解为在特定的操作协议下，对特定的内存或者高速缓存进行读写访问的过程抽象，不同架构下的物理机拥有不一样的内存模型，Java虚拟机也有自己的内存模型，即Java内存模型（Java Memory Model, JMM）。在C/C++语言中直接使用物理硬件和操作系统内存模型，导致不同平台下并发访问出错。而JMM的出现，能够屏蔽掉各种硬件和操作系统的内存访问差异，实现平台一致性，是的Java程序能够“一次编写，到处运行”。

主内存和工作内存

Java内存模型的主要目标是定义程序中各个变量的访问规则，即在虚拟机中将变量存储到内存和从内存中取出变量这样底层细节。此处的变量与Java编程时所说的变量不一样，指包括了实例字段、静态字段和构成数组对象的元素，但是不包括局部变量与方法参数，后者是线程私有的，不会被共享。

Java内存模型中规定了所有的变量都存储在主内存中，每条线程还有自己的工作内存（可以与前面讲的处理器的高速缓存类比），线程的工作内存中保存了该线程使用到的变量到主内存副本拷贝，线程对变量的所有操作（读取、赋值）都必须在工作内存中进行，而不能直接读写主内存中的变量。不同线程之间无法直接访问对方工作内存中的变量，线程间变量值的传递均需要在主内存来完成，线程、主内存和工作内存的交互关系如下图所示，和上图很类似。

注意：这里的主内存、工作内存与Java内存区域的Java堆、栈、方法区不是同一层次内存划分，这两者基本上没有关系。

内存交互操作

由上面的交互关系可知，关于主内存与工作内存之间的具体交互协议，即一个变量如何从主内存拷贝到工作内存、如何从工作内存同步到主内存之间的实现细节，Java内存模型定义了以下八种操作来完成：

lock（锁定）：作用于主内存的变量，把一个变量标识为一条线程独占状态。
unlock（解锁）：作用于主内存变量，把一个处于锁定状态的变量释放出来，释放后的变量才可以被其他线程锁定。
read（读取）：作用于主内存变量，把一个变量值从主内存传输到线程的工作内存中，以便随后的load动作使用
load（载入）：作用于工作内存的变量，它把read操作从主内存中得到的变量值放入工作内存的变量副本中。
use（使用）：作用于工作内存的变量，把工作内存中的一个变量值传递给执行引擎，每当虚拟机遇到一个需要使用变量的值的字节码指令时将会执行这个操作。
assign（赋值）：作用于工作内存的变量，它把一个从执行引擎接收到的值赋值给工作内存的变量，每当虚拟机遇到一个给变量赋值的字节码指令时执行这个操作。
store（存储）：作用于工作内存的变量，把工作内存中的一个变量的值传送到主内存中，以便随后的write的操作。
write（写入）：作用于主内存的变量，它把store操作从工作内存中一个变量的值传送到主内存的变量中。

如果要把一个变量从主内存中复制到工作内存，就需要按顺寻地执行read和load操作，如果把变量从工作内存中同步回主内存中，就要按顺序地执行store和write操作。Java内存模型只要求上述两个操作必须按顺序执行，而没有保证必须是连续执行。也就是read和load之间，store和write之间是可以插入其他指令的，如对主内存中的变量a、b进行访问时，可能的顺序是read a，read b，load b， load a。Java内存模型还规定了在执行上述八种基本操作时，必须满足如下规则：

不允许read和load、store和write操作之一单独出现
不允许一个线程丢弃它的最近assign的操作，即变量在工作内存中改变了之后必须同步到主内存中。
不允许一个线程无原因地（没有发生过任何assign操作）把数据从工作内存同步回主内存中。
一个新的变量只能在主内存中诞生，不允许在工作内存中直接使用一个未被初始化（load或assign）的变量。即就是对一个变量实施use和store操作之前，必须先执行过了assign和load操作。
一个变量在同一时刻只允许一条线程对其进行lock操作，lock和unlock必须成对出现
如果对一个变量执行lock操作，将会清空工作内存中此变量的值，在执行引擎使用这个变量前需要重新执行load或assign操作初始化变量的值
如果一个变量事先没有被lock操作锁定，则不允许对它执行unlock操作；也不允许去unlock一个被其他线程锁定的变量。
对一个变量执行unlock操作之前，必须先把此变量同步到主内存中（执行store和write操作）。

这8种内存访问操作很繁琐，后文会使用一个等效判断原则，即先行发生(happens-before)原则来确定一个内存访问在并发环境下是否安全。

指令重排

在执行程序时为了提高性能，编译器和处理器经常会对指令进行重排序。从硬件架构上来说，指令重排序是指CPU采用了允许将多条指令不按照程序规定的顺序，分开发送给各个相应电路单元处理，而不是指令任意重排。重排序分成三种类型：

编译器优化的重排序。编译器在不改变单线程程序语义放入前提下，可以重新安排语句的执行顺序。
指令级并行的重排序。现代处理器采用了指令级并行技术来将多条指令重叠执行。如果不存在数据依赖性，处理器可以改变语句对应机器指令的执行顺序。
内存系统的重排序。由于处理器使用缓存和读写缓冲区，这使得加载和存储操作看上去可能是在乱序执行。

as-if-serial语义

不管怎么重排序（编译器和处理器为了提高并行度），（单线程）程序的执行结果不能被改变。编译器，runtime 和处理器都必须遵守as-if-serial语义。

double pi = 3.14; //A
double r = 1.0; //B
double area = pi * r * r; //C


A->C B->C; A,B之间不存在依赖关系； 故在单线程情况下， A与B的指令顺序是可以重排的，C不允许重排，必须在A和B之后。

结论性的总结：
as-if-serial语义把单线程程序保护了起来，遵守as-if-serial语义的编译器，runtime 和处理器共同为编写单线程程序的程序员创建了一个幻觉：单线程程序是按程序的顺序来执行的。as-if-serial语义使单线程程序员无需担心重排序会干扰他们，也无需担心内存可见性问题。

核心点还是单线程，多线程情况下不遵守此原则。

在多线程下的指令重排

public class ReorderExample {
    public int a = 0;
    public boolean flag = false;

    public void writer() {
        a = 1;                   //1  
        flag = true;             //2  
    }

    public void reader() {
        if (flag) {                //3  
            int i =  a * a;        //4  
        }
    }
    public static void main(String[] args) throws InterruptedException{
        for(int i=0;i<1000;i++){
            ReorderExample obj= new ReorderExample();
            Thread th1=new Thread(){
                @Override
                public void run(){
                    obj.writer();
                }
            };
            Thread th2=new Thread(){
                @Override
                public void run(){
                    obj.reader();
                }
            };
            th1.start();
            th2.start();
        }
    }
}

假设有A和B两个线程同时来执行这个代码片段， 两个可能的执行流程如下：

指令重排的原因分析

主要还是编译器以及CPU为了优化代码或者执行的效率而执行的优化操作；应用条件是单线程场景下，对于并发多线程场景下，指令重排会产生不确定的执行效果。

如何防止指令重排

volatile关键字可以保证变量的可见性，因为对volatile的操作都在Main Memory中，而Main Memory是被所有线程所共享的，这里的代价就是牺牲了性能，无法利用寄存器或Cache，因为它们都不是全局的，无法保证可见性，可能产生脏读。
volatile还有一个作用就是局部阻止重排序的发生，对volatile变量的操作指令都不会被重排序，因为如果重排序，又可能产生可见性问题。
在保证可见性方面，锁（包括显式锁、对象锁）以及对原子变量的读写都可以确保变量的可见性。但是实现方式略有不同，例如同步锁保证得到锁时从内存里重新读入数据刷新缓存，释放锁时将数据写回内存以保数据可见，而volatile变量干脆都是读写内存。

JIT 汇编指令查看(hsdis-amd64.so安装)

java -XX:+UnlockDiagnosticVMOptions -XX:+PrintAssembly ReorderExample

通过汇编指令确认指令重排是否发生

Memory Barrier

从Java源代码到最终实际执行的指令序列，会经过三种重排序。但是，为了保证内存的可见性，Java编译器在生成指令序列的适当位置会插入内存屏障指令来禁止特定类型的处理器重排序。对于编译器的重排序，JMM会根据重排序规则禁止特定类型的编译器重排序；对于处理器重排序，JMM会插入特定类型的内存屏障，通过内存的屏障指令禁止特定类型的处理器重排序。这里讨论JMM对处理器的重排序，为了更深理解JMM对处理器重排序的处理，先来认识一下常见处理器的重排序规则：

其中的N标识处理器不允许两个操作进行重排序，Y表示允许。其中Load-Load表示读-读操作、Load-Store表示读-写操作、Store-Store表示写-写操作、Store-Load表示写-读操作。可以看出：常见处理器对写-读操作都是允许重排序的，并且常见的处理器都不允许对存在数据依赖的操作进行重排序（对应上面数据转换那一列，都是N，所以处理器不允许这种重排序）。

那么这个结论对我们有什么作用呢？比如第一点：处理器允许写-读操作两者之间的重排序，那么在并发编程中读线程读到可能是一个未被初始化或者是一个NULL等，出现不可预知的错误，基于这点，JMM会在适当的位置插入内存屏障指令来禁止特定类型的处理器的重排序。内存屏障指令一共有4类：

LoadLoad Barriers：确保Load1数据的装载先于Load2以及所有后续装载指令
StoreStore Barriers：确保Store1的数据对其他处理器可见（会使缓存行无效，并刷新到内存中）先于Store2及所有后续存储指令的装载
LoadStore Barriers：确保Load1数据装载先于Store2及所有后续存储指令刷新到内存
StoreLoad Barriers：确保Store1数据对其他处理器可见（刷新到内存，并且其他处理器的缓存行无效）先于Load2及所有后续装载指令的装载。该指令会使得该屏障之前的所有内存访问指令完成之后，才能执行该屏障之后的内存访问指令。

数据依赖性

根据上面的表格，处理器不会对存在数据依赖的操作进行重排序。这里数据依赖的准确定义是：如果两个操作同时访问一个变量，其中一个操作是写操作，此时这两个操作就构成了数据依赖。常见的具有这个特性的如i++、i—。如果改变了具有数据依赖的两个操作的执行顺序，那么最后的执行结果就会被改变。这也是不能进行重排序的原因。例如：

写后读：a = 1; b = a;
写后写：a = 1; a = 2;
读后写：a = b; b = 1;

重排序遵守数据依赖性，编译器和处理器不会改变存在数据依赖关系的两个操作的执行顺序。但是这里所说的数据依赖性仅针对单个处理器中执行的指令序列和单个线程中执行的操作，不同处理器之间和不同线程之间的数据依赖性不被编译器和处理器考虑。

volatile

关键字volatile是JVM中最轻量的同步机制。volatile变量具有2种特性：

保证变量的可见性。对一个volatile变量的读，总是能看到（任意线程）对这个volatile变量最后的写入，这个新值对于其他线程来说是立即可见的。
屏蔽指令重排序：指令重排序是编译器和处理器为了高效对程序进行优化的手段，下文有详细的分析。

volatile语义并不能保证变量的原子性。对任意单个volatile变量的读/写具有原子性，但类似于i++、i–这种复合操作不具有原子性，因为自增运算包括读取i的值、i值增加1、重新赋值3步操作，并不具备原子性。

由于volatile只能保证变量的可见性和屏蔽指令重排序，只有满足下面2条规则时，才能使用volatile来保证并发安全，否则就需要加锁（使用synchronized、lock或者java.util.concurrent中的Atomic原子类）来保证并发中的原子性。

运算结果不存在数据依赖（重排序的数据依赖性），或者只有单一的线程修改变量的值（重排序的as-if-serial语义）
变量不需要与其他的状态变量共同参与不变约束

因为需要在本地代码中插入许多内存屏蔽指令在屏蔽特定条件下的重排序，volatile变量的写操作与读操作相比慢一些，但是其性能开销比锁低很多。

volatile demo

 public class VolatileObjectTest implements Runnable {
    private   ObjectA a; // volatile   
    public VolatileObjectTest(ObjectA a) {
        this.a = a;
    }

    public ObjectA getA() {
        return a;
    }

    public void setA(ObjectA a) {
        this.a = a;
    }

    @Override
    public void run() {
        long i = 0;
        boolean flag =a.isFlag();
        //while (a.isFlag()) {     
        while (flag) {
            i++;
            //System.out.println("------------------");  
        }
        System.out.println("stop My Thread " + i);
    }

    public void stop() {
        a.setFlag(false);
    }

    public static void main(String[] args) throws InterruptedException {
         // 如果启动的时候加上-server 参数则会 输出 Java HotSpot(TM) Server VM  
        System.out.println(System.getProperty("java.vm.name"));

        VolatileObjectTest test = new VolatileObjectTest(new ObjectA());
        new Thread(test).start();

        Thread.sleep(1000);
        test.stop();
        Thread.sleep(1000);
        System.out.println("Main Thread " + test.getA().isFlag());
    }

    static class ObjectA {
        private boolean flag = true;

        public boolean isFlag() {
            return flag;
        }

        public void setFlag(boolean flag) {
            this.flag = flag;
        }

    }
}

1.如果你在循环体内加一些语句，比如注释掉的sysout或者其他耗时操作(具体看机器下性能)，这种稍微复杂而耗时的操作，你就会发现就算没有volatile，线程一样会被中断。因为经过高耗时操作后，CPU会“怀疑人生”，担心自己的对flag的缓存不是最新的了，所以它会去主存当中取得当前sub.flag的值，最终线程结束。在这种情况下，线程会结束，只不过不及时而已。

2.run 中使用局部变量flag,也不能及时跳出循环,因为,线程一直访问的是cpu高速缓存中的线程的临时变量的值,而实际上并没有去使用volatile更新后的的主存数据. 注意使用 volatile 场景时,要直接基于volatile 修饰的变量进行访问,尤其在使用对象,数据场景的时候.果你在循环体内加一些语句，比如楼主注释的sysout或者new个对象什么的，这种稍微复杂而耗时的操作，你就会发现就算没有volatile，线程一样会被中断。因为经过高耗时操作后，CPU会“怀疑人生”，担心自己的对sub.flag的缓存不是最新的了，所以它会去主存当中取得当前sub.flag的值，最终线程结束。在这种情况下，线程会结束，只不过不及时而已。

Volatile 常见应用(双检锁)

class Singleton{
    private volatile static Singleton instance = null;

    private Singleton() {

    }

    public static Singleton getInstance() {
        if(instance==null) {
            synchronized (Singleton.class) {
                if(instance==null)
                    instance = new Singleton();
            }
        }
        return instance;
    }
}

voltale 相同效果代码实现

public class VolatileTest{
    private volatile int a=0;
    public int getA(){
        return a;
    }
    public void setA(int tmp){
        a = tmp;
    }
    public int getAndIncrease(){
        return a++;
    }
}

public class VolatileTest2{
    private  int a=0;
    public synchronized  int getA(){
        return a;
    }
    public synchronized void setA(int tmp){
        a = tmp;
    }
    public int getAndIncrease(){
        int tmp= getA();
        setA(tmp+1);
        return tmp;
    }
}

volatile 实现原理

volatile变量写，汇编指令会多出Lock前缀，Lock前缀在多核处理器下的作用：

将当前处理器缓存行的数据写回主存；
令其他CPU里缓存该内存地址的数据无效 

1. 针对编译器重排序：JMM针对编译器指定了volatile重排序规则表，规定哪些先后操作不能进行编译器重排序：
   

   当第二个操作是volatile写时，不管第一个操作是什么，都不能重排序。这个规则确保volatile写之前的操作不会被编译器重排序到volatile写之后。
   当第一个操作是volatile读时，不管第二个操作是什么，都不能重排序。这个规则确保volatile读之后的操作不会被编译器重排序到volatile读之前。
   当第一个操作是volatile写，第二个操作是volatile读时，不能重排序。
   当第一个操作是volatile写，第二个操作是volatile读时，不能重排序。

2. 针对处理器重排序：编译器在生成字节码指令时，通过在指令序列中插入内存屏障指令来禁止特定类型的处理器重排序，以实现volatile内存语义：volatile底层通过内存屏障指令实现
   

   在每个volatile变量写操作之前插入StoreStore屏障，之后插入StoreLoad屏障；
   之前插入StoreStore屏障：禁止volatile写之前的写操作与其重排序，保证之前的所有写操作都写回主存，对volatile写可见；
   之后插入StoreLoad屏障：禁止volatile写之后的读写操作与其重排序，实现volatile写结果对后续操作可见；
   在每个volatile变量读操作之后，接连插入LoadLoad屏障，LoadStore屏障；
   插入LoadLoad屏障：禁止volatile变量读之后的读操作与其重排序；
   插入LoadStore屏障：禁止volatile变量读之后的写操作与其重排序；
   通过插入两次内存屏障，实现volatile读结果对后续操作可见；

JMM通过上述内存屏障插入策略，保证在任意平台上volatile的内存语义一致；(volatile 写的性能损耗要高于读的开销)

volatile 伪共享

缓存系统中是以缓存行（cache line）为单位存储的。缓存行是2的整数幂个连续字节，一般为32-256个字节。最常见的缓存行大小是64个字节。当多线程修改互相独立的变量时，如 果这些变量共享同一个缓存行，就会无意中影响彼此的性能，这就是伪共享.
解决伪共享的办法是使用 缓存行填充|refernce.

perf stat -e L1-dcache-loads -e L1-dcache-load-misses -e LLC-loads -e LLC-load-misses -e dTLB-loads -e dTLB-load-misses java FalseSharing 观察伪共享效果

CAS原理

• 性能优势,避免用锁,避免用户太内核太的切换,锁的阻塞唤醒,上下文切换本身就是一个耗时的操作.
• cas 会导致 ABA问题,CAS需要在操作值的时候检查下值有没有发生变化，如果没有发生变化则更新，但是如果一个值原来是A，变成了B，又变成了A，那么使用CAS进行检查时会发现它的值没有发生变化，但是实际上却变化了
• cas 循环时间长开销大
• 只能保证一个共享变量的原子操作
• JAVA中提供了AtomicStampedReference/AtomicMarkableReference来处理会发生ABA问题的场景，主要是在对象中额外再增加一个标记来标识对象是否有过变更

AQS解析 | refrence| refrence2

LockSupport park unpark

• unpark 可以先于 park调用
• unpark 多次调用只能给一个许可,如线程B连续调用了三次unpark函数，当线程A调用park函数就使用掉这个“许可”，如果线程A再次调用park，则进入等待状态。

对比 wait notify

在Java5里是用wait/notify/notifyAll来同步的。wait/notify机制有个很蛋疼的地方是，比如线程B要用notify通知线程A，那么线程B要确保线程A已经在wait调用上等待了，否则线程A可能永远都在等待。

另外，是调用notify，还是notifyAll？

notify只会唤醒一个线程，如果错误地有两个线程在同一个对象上wait等待，那么又悲剧了。为了安全起见，貌似只能调用notifyAll了。阻塞是基于对象来做的,没有真正做到基于线程自身的阻塞唤醒机制.

park/unpark模型真正解耦了线程之间的同步，线程之间不再需要一个Object或者其它变量来存储状态，不再需要关心对方的状态。

interrupt、interrupted 、isInterrupted

• interrupt
  interrupt方法用于中断线程。调用该方法的线程的状态为将被置为”中断”状态。
  注意：线程中断仅仅是置线程的中断状态位，不会停止线程。需要用户自己去监视线程的状态为并做处理。支持线程中断的方法（也就是线程中断后会抛出interruptedException的方法）就是在监视线程的中断状态，一旦线程的中断状态被置为“中断状态”，就会抛出中断异常。
• interrupted是静态方法，返回的是当前线程的中断状态。
  例如，如果当前线程被中断（没有抛出中断异常，否则中断状态就会被清除），你调用interrupted方法，第一次会返回true。然后，当前线程的中断状态被方法内部清除了。第二次调用时就会返回false。
• isInterrupted 测试线程是否已经中断。线程的中断状态 不受该方法的影响。
  如果你刚开始一直调用isInterrupted，则会一直返回true，除非中间线程的中断状态被其他操作清除了。

JUC 总结如下:

JUC(Java Util Concurrency)仅用简单的park, unpark和CAS指令就实现了各种高级同步数据结构，而且效率很高。

工具类	工具类作用	工具类加锁方法	工具类释放锁方法	Sync覆盖的方法	Sync非覆盖的重要方法	state的作用	锁类型	锁维护
Semaphore	控制同时访问某个特定资源的操作数量	acquire：每次请求一个许可都会导致计数器减少1，，一旦达到了0，新的许可请求线程将被挂起	release：每调用 添加一个许可，释放一个正在阻塞的获取者	tryAcquireShared tryReleaseShared		表示初始化的许可数	共享锁	每一次请求acquire()一个许可都会导致计数器减少1，同样每次释放一个许可release()都会导致计数器增加1，一旦达到了0，新的许可请求线程将被挂起。
CountDownLatch	把一组线程全部关在外面，在某个状态时候放开。一种同步机制来保证一个或多个线程等待其他线程完成。	await：在计数器不为0时候阻塞调用线程，为0时候立即返回	countDown ：计数递减	tryAcquireShared tryReleaseShared		维护一个计数器	共享锁	初始化一个计数，每次调用countDown方法计数递减，在计数递减到0之前，调用await的线程都会阻塞
ReentrantLock	标准的互斥操作，也就是一次只能有一个线程持有锁	lock：如果没有线程使用则立即返回，并设置state为1；如果当前线程已经占有锁，则state加1；如果其他线程占有锁，则当前线程不可用，等待 tryLock：如果锁可用，则获取锁，并立即返回值 true。如果锁不可用，则此方法将立即返回值 false	unlock：尝试释放锁，如果当前线程占有锁则count减一，如果count为0则释放锁。如果占有线程不是当前线程，则抛异常	tryAcquire tryRelease	nonfairTryAcquir	state表示获得锁的线程对锁的重入次数。	排他锁。	获取锁时，如果没有线程使用则立即返回，并设置state为1；如果当前线程已经占有锁，则state加1；如果其他线程占有锁，则当前线程不可用。释放锁时，在该方法中主要作用是state状态位减少release个，表示释放锁，如果更新后的state为0，表示当前线程释放锁，如果不为0，表示持有锁的当前线程重入数减少
ReentrantReadWriteLock	读写锁。允许多个读线程同时持有锁，但是只有一个写线程可以持有锁。写线程获取写入锁后可以再次获取读取锁，但是读线程获取读取锁后却不能获取写入锁	ReadLock#lock ：获取读锁 ReadLock#tryLock:尝试当前没有其他线程当前持有写锁时获取读锁 WriteLock#lock：获取写锁 WriteLock#tryLock：尝试当前没有其他线程持有写锁时，呼气写锁。	ReadLock#unlock：释放读锁 WriteLock#unlock：释放写锁	acquireShared releaseShared tryAcquire tryRelease	tryReadLock tryWriteLock	高16位表示共享锁的数量，低16位表示独占锁的重入次数	读锁：共享 写锁：排他	对于共享锁，state是计数器的概念。一个共享锁就相对于一次计数器操作，一次获取共享锁相当于计数器加1，释放一个共享锁就相当于计数器减1；排他锁维护类似于可重入锁。
FutureTask	封装一个执行任务交给其他线程去执行，开始执行后可以被取消，可以查看执行结果，如果执行结果未完成则阻塞。	V get()	run() set(V) cancel(boolean)	tryAcquireShared tryReleaseShared	innerGet innerRun() innerSet innerIsCancelled	state状态位来存储执行状态RUNNING、RUN、CANCELLED	共享锁	获取执行结果的线程(可以有多个)一直阻塞，直到执行任务的线程执行完毕，或者执行任务被取消。

LOCK简介

锁从宏观上分类，分为悲观锁与乐观锁。
- cas 是乐观锁
- java中的悲观锁就是Synchronized,AQS框架下的锁则是先尝试cas乐观锁去获取锁，获取不到，才会转换为悲观锁

偏向锁

Java偏向锁(Biased Locking)是Java6引入的一项多线程优化。
偏向锁，顾名思义，它会偏向于第一个访问锁的线程，如果在运行过程中，同步锁只有一个线程访问，不存在多线程争用的情况，则线程是不需要触发同步的，这种情况下，就会给线程加一个偏向锁。
如果在运行过程中，遇到了其他线程抢占锁，则持有偏向锁的线程会被挂起，JVM会消除它身上的偏向锁，将锁恢复到标准的轻量级锁。

轻量级锁

如果偏向锁失败，Java虚拟机就会让线程申请轻量级锁，轻量级锁在虚拟机内部，使用一个成为BasicObjectLock的对象实现的，这个对象内部由一个BasicLock对象和一个持有该锁的Java对象指针组成。BasicObjectLock对象放置在Java栈帧中。在BasicLock对象内部还维护着displaced_header字段，用于备份对象头部的Mark Word.

重量级锁Synchronized

• 用于方法时，锁住的是对象的实例(this)；
• 当作用于静态方法时，锁住的是Class实例，又因为Class的相关数据存储在永久带PermGen（jdk1.8则是metaspace），永久带是全局共享的，因此静态方法锁相当于类的一个全局锁，会锁所有调用该方法的线程；
• synchronized作用于一个对象实例时，锁住的是所有以该对象为锁的代码块

• Synchronized是非公平锁
  
  它有多个队列，当多个线程一起访问某个对象监视器的时候，对象监视器会将这些线程存储在不同的容器中。

  • Contention List：竞争队列，所有请求锁的线程首先被放在这个竞争队列中；

  • Entry List：Contention List中那些有资格成为候选资源的线程被移动到Entry List中；

  • Wait Set：哪些调用wait方法被阻塞的线程被放置在这里；

  • OnDeck：任意时刻，最多只有一个线程正在竞争锁资源，该线程被成为OnDeck；

  • Owner：当前已经获取到所资源的线程被称为Owner；

  • !Owner：当前释放锁的线程。

synchronized的执行过程：
1. 检测Mark Word里面是不是当前线程的ID，如果是，表示当前线程处于偏向锁
2. 如果不是，则使用CAS将当前线程的ID替换Mard Word，如果成功则表示当前线程获得偏向锁，置偏向标志位1
3. 如果失败，则说明发生竞争，撤销偏向锁，进而升级为轻量级锁。
4. 当前线程使用CAS将对象头的Mark Word替换为锁记录指针，如果成功，当前线程获得锁
5. 如果失败，表示其他线程竞争锁，当前线程便尝试使用自旋来获取锁。
6. 如果自旋成功则依然处于轻量级状态。
7. 如果自旋失败，则升级为重量级锁。

自旋锁

自旋锁可以使线程在没有取得锁的时候，不被挂起，而转去执行一个空循环，（即所谓的自旋，就是自己执行空循环），若在若干个空循环后，线程如果可以获得锁，则继续执行。若线程依然不能获得锁，才会被挂起。

使用自旋锁后，线程被挂起的几率相对减少，线程执行的连贯性相对加强。因此，对于那些锁竞争不是很激烈，锁占用时间很短的并发线程，具有一定的积极意义，但对于锁竞争激烈，单线程锁占用很长时间的并发程序，自旋锁在自旋等待后，往往毅然无法获得对应的锁，不仅仅白白浪费了CPU时间，最终还是免不了被挂起的操作 ，反而浪费了系统的资源。

在JDK1.6中，Java虚拟机提供-XX:+UseSpinning参数来开启自旋锁，使用-XX:PreBlockSpin参数来设置自旋锁等待的次数。

在JDK1.7开始，自旋锁的参数被取消，虚拟机不再支持由用户配置自旋锁，自旋锁总是会执行，自旋锁次数也由虚拟机自动调整。