Java锁

锁概念

公平锁与非公平锁

公平锁：线程获取锁的顺序与其申请顺序一致

非公平锁：线程获取锁的顺序并不是按照申请锁顺序，有可能后申请锁的线程先获取锁。

可重入锁与不可重入锁

可重入锁：线程获取锁后，可以重复进入同步代码区，不需要重复申请锁

不可重入锁：线程每次进入同步代码区时，均需要获取锁，即使已经获取过该锁。

悲观锁与乐观锁

悲观锁：总是持有悲观的态度，认为并发冲突一般会发生

乐观锁：总是持有乐观的态度，认为并发冲突一般不会发生

锁消除与锁粗化

锁消除：消除是Java虚拟机在JIT编译期间，通过对运行上下文的扫描，去除不可能存在共享资源竞争的锁，通过锁消除，可以节省毫无意义的请求锁时间。

锁粗化：在遇到一连串地对同一锁不断进行请求和释放的操作时，把所有的锁操作整合成对锁的一次请求，从而减少对锁的请求同步次数

自旋锁和自适应自旋

自旋锁：线程尝试获取锁，发现被占用后，不放弃cpu执行时间，进入阻塞状态，而是进入进行循环重试，重试指定次数后，仍未获取锁，则进入阻塞过程。

自适应自旋：重试次数不固定，而是由前一次在同一个锁上的自旋时间及锁的拥有者的状态来决定。

Java锁升级

对象内存布局

Java对象在内存中存储的布局可以分为3块区域: 对象头、实例数据、对齐填充。

对象头,分为两个部分,第一个部分存储对象自身的运行时数据，又称为Mark Word,32位虚拟机占32bit，64位虚拟机占64bit。如图所示，不同锁状态下，Mark Word的结构，理解下面要介绍的各种锁，和锁升级过程，都需要先充分了解Mark Word的结构。

第二部分是类型指针，指向类元数据指针，虚拟机通过此指针，确定该对象属于那个类的实例。

偏向锁

引入偏向锁的目的是在没有多线程竞争的前提下，进一步减少线程同步的性能消耗。

• 偏向锁的获取

  开启偏向锁模式后，锁第一次被线程获取的时候，虚拟机会把对象头中是否为偏向锁的标志位设位1,

  同时使用CAS操作把获取到这个锁的线程的ID记录在对象的Mark Word之中。当有另外一个线程去尝试获取这个锁时， 偏向模式就宣告结束。

  根据锁对象目前是否处于被锁定的状态, 撤销偏向（ Revoke Bias） 后恢复到未锁定（ 标志位为“01”）或轻量级锁定（ 标志位为“00”） 的状态

• 偏向锁的释放

  偏向锁，并没有显式的锁释放过程，主要依靠锁的批量再偏向（Bulk Rebias）机制实现锁释放。

  该机制的主要工作原理如下：

  • 引入一个概念 epoch, 其本质是一个时间戳 ， 代表了偏向锁的有效性，从前文描述的对象头结构中可以看到，

    epoch 存储在可偏向对象的 MarkWord 中。

  • 除了对象中的 epoch, 对象所属的类 class 信息中， 也会保存一个 epoch 值，每当遇到一个全局安全点时， 如果要对 class 进行批量再偏向， 则首先对 class 中保存的 epoch 进行增加操作， 得到一个新的 epoch_new

  • 然后扫描所有持有 class 实例的线程栈，根据线程栈的信息判断出该线程是否锁定了该对象， 仅将epoch_new 的值赋给被锁定的对象中。

  • 退出安全点后， 当有线程需要尝试获取偏向锁时， 直接检查 class中存储的 epoch 值是否与目标对象中存储的 epoch 值相等，如果不相等， 则说明该对象的偏向锁已经无效了， 可以尝试对此对象重新进行偏向操作。

轻量级锁

轻量级锁是相对于重量级锁(Synchrnoized)而言的，本意是在没有多线程竞争的前提下，减少传统的重量级锁使用操作系统互斥量产生的性能消耗。

• 轻量级锁的获取

  • 线程进入同步块时，如果此同步对象没有被锁定(即锁标志位为01,是否为偏向锁为0)，虚拟机在当前线程的栈帧中建立一个名为锁记录(Lock Record)的空间，用于存储锁对象目前的一个Mark Word的copy ，ower设置为当前线程。

    

  • 然后虚拟机使用CAS操作，尝试将Mark World更新为指向Lock Record的指针，如果更新成功，那么线程拥有了该对象的锁，并且将锁标志位置位00，如图所示

    

  • 如果只有一个线程尝试获取轻量级锁，会进行自旋等待，一旦有两条以及以上的线程抢占该锁，轻量级锁会升级为重量级锁。

    锁标志位置为10,Mark Word存储的就是指向重量级锁的指针

• 轻量级锁释放

  • 如果对象的Mark Word仍然指向着线程的锁记录， 那就用CAS操作把对象当前的Mark Word和线程中复制的Displaced Mark Word替换回来， 如果替换成功， 整个同步过程就完成了。如果替换失败， 说明有其他线程尝试过获取该锁，轻量级锁膨胀为重量级锁,那就要在释放锁的同时， 唤醒被挂起的线程。

整个锁升级过程

参考文章

偏向锁，轻量级锁与重量级锁的区别与膨胀

Java中的偏向锁，轻量级锁， 重量级锁解析

锁的4中状态：

无锁状态、偏向锁状态、轻量级锁状态、重量级锁状态（级别从低到高）

一、锁升级

1. 为什么要引入偏向锁？

因为经过HotSpot的作者大量的研究发现，大多数时候是不存在锁竞争的，常常是一个线程多次获得同一个锁，因此如果每次都要竞争锁会增大很多没有必要付出的代价，为了降低获取锁的代价，才引入的偏向锁。

2. 偏向锁的升级

当线程1访问代码块并获取锁对象时，会在java对象头和栈帧中记录偏向的锁的threadID，因为偏向锁不会主动释放锁，因此以后线程1再次获取锁的时候，需要比较当前线程的threadID和Java对象头中的threadID是否一致，如果一致（还是线程1获取锁对象），则无需使用CAS来加锁、解锁；如果不一致（其他线程，如线程2要竞争锁对象，而偏向锁不会主动释放因此还是存储的线程1的threadID），那么需要查看Java对象头中记录的线程1是否存活，如果没有存活，那么锁对象被重置为无锁状态，其它线程（线程2）可以竞争将其设置为偏向锁；如果存活，那么立刻查找该线程（线程1）的栈帧信息，如果还是需要继续持有这个锁对象，那么暂停当前线程1，撤销偏向锁，升级为轻量级锁，如果线程1 不再使用该锁对象，那么将锁对象状态设为无锁状态，重新偏向新的线程。

3. 偏向锁的取消：

偏向锁是默认开启的，而且开始时间一般是比应用程序启动慢几秒，如果不想有这个延迟，那么可以使用-XX:BiasedLockingStartUpDelay=0；

如果不想要偏向锁，那么可以通过-XX:-UseBiasedLocking = false来设置；

4. 为什么要引入轻量级锁？

轻量级锁考虑的是竞争锁对象的线程不多，而且线程持有锁的时间也不长的情景。因为阻塞线程需要CPU从用户态转到内核态，代价较大，如果刚刚阻塞不久这个锁就被释放了，那这个代价就有点得不偿失了，因此这个时候就干脆不阻塞这个线程，让它自旋这等待锁释放。

5. 轻量级锁什么时候升级为重量级锁？

线程1获取轻量级锁时会先把锁对象的对象头MarkWord复制一份到线程1的栈帧中创建的用于存储锁记录的空间（称为DisplacedMarkWord），然后使用CAS把对象头中的内容替换为线程1存储的锁记录（DisplacedMarkWord）的地址；

如果在线程1复制对象头的同时（在线程1CAS之前），线程2也准备获取锁，复制了对象头到线程2的锁记录空间中，但是在线程2CAS的时候，发现线程1已经把对象头换了，线程2的CAS失败，那么线程2就尝试使用自旋锁来等待线程1释放锁。

但是如果自旋的时间太长也不行，因为自旋是要消耗CPU的，因此自旋的次数是有限制的，比如10次或者100次，如果自旋次数到了线程1还没有释放锁，或者线程1还在执行，线程2还在自旋等待，这时又有一个线程3过来竞争这个锁对象，那么这个时候轻量级锁就会膨胀为重量级锁。重量级锁把除了拥有锁的线程都阻塞，防止CPU空转。

注意：为了避免无用的自旋，轻量级锁一旦膨胀为重量级锁就不会再降级为轻量级锁了；偏向锁升级为轻量级锁也不能再降级为偏向锁。一句话就是 锁可以升级不可以降级，但是偏向锁状态可以被重置为无锁状态。

二、锁粗化

通常情况下，为了保证多线程间的有效并发，会要求每个线程持有锁的时间尽可能短，但是大某些情况下，一个程序对同一个锁不间断、高频地请求、同步与释放，会消耗掉一定的系统资源，因为锁的讲求、同步与释放本身会带来性能损耗，这样高频的锁请求就反而不利于系统性能的优化了，虽然单次同步操作的时间可能很短。锁粗化就是告诉我们任何事情都有个度，有些情况下我们反而希望把很多次锁的请求合并成一个请求，以降低短时间内大量锁请求、同步、释放带来的性能损耗。

public void doSomethingMethod(){
    synchronized(lock){
        //do some thing
    }
    //这是还有一些代码，做其它不需要同步的工作，但能很快执行完毕
    synchronized(lock){
        //do other thing
    }
}

上面的代码是有两块需要同步操作的，但在这两块需要同步操作的代码之间，需要做一些其它的工作，而这些工作只会花费很少的时间，那么我们就可以把这些工作代码放入锁内，将两个同步代码块合并成一个，以降低多次锁请求、同步、释放带来的系统性能消耗，合并后的代码如下:

public void doSomethingMethod(){
    //进行锁粗化：整合成一次锁请求、同步、释放
    synchronized(lock){
        //do some thing
        //做其它不需要同步但能很快执行完的工作
        //do other thing
    }
}

注意：这样做是有前提的，就是中间不需要同步的代码能够很快速地完成，如果不需要同步的代码需要花很长时间，就会导致同步块的执行需要花费很长的时间，这样做也就不合理了。

另一种需要锁粗化的极端的情况是：

for(int i=0;i<size;i++){
    synchronized(lock){
    }
}

上面代码每次循环都会进行锁的请求、同步与释放，看起来貌似没什么问题，且在jdk内部会对这类代码锁的请求做一些优化，但是还不如把加锁代码写在循环体的外面，这样一次锁的请求就可以达到我们的要求，除非有特殊的需要：循环需要花很长时间，但其它线程等不起，要给它们执行的机会。

锁粗化后的代码如下：

synchronized(lock){
    for(int i=0;i<size;i++){
    }
}

三、锁消除

锁消除是发生在编译器级别的一种锁优化方式。
有时候我们写的代码完全不需要加锁，却执行了加锁操作。

比如，StringBuffer类的append操作：

@Override
public synchronized StringBuffer append(String str) {
    toStringCache = null;
    super.append(str);
    return this;
}

从源码中可以看出，append方法用了synchronized关键词，它是线程安全的。但我们可能仅在线程内部把StringBuffer当作局部变量使用：

package com.leeib.thread;
public class Demo {
    public static void main(String[] args) {
        long start = System.currentTimeMillis();
        int size = 10000;
        for (int i = 0; i < size; i++) {
            createStringBuffer("Hyes", "为分享技术而生");
        }
        long timeCost = System.currentTimeMillis() - start;
        System.out.println("createStringBuffer:" + timeCost + " ms");
    }
    public static String createStringBuffer(String str1, String str2) {
        StringBuffer sBuf = new StringBuffer();
        sBuf.append(str1);// append方法是同步操作
        sBuf.append(str2);
        return sBuf.toString();
    }
}

代码中createStringBuffer方法中的局部对象sBuf，就只在该方法内的作用域有效，不同线程同时调用createStringBuffer()方法时，都会创建不同的sBuf对象，因此此时的append操作若是使用同步操作，就是白白浪费的系统资源。

这时我们可以通过编译器将其优化，将锁消除，前提是java必须运行在server模式（server模式会比client模式作更多的优化），同时必须开启逃逸分析:

-server -XX:+DoEscapeAnalysis -XX:+EliminateLocks

其中+DoEscapeAnalysis表示开启逃逸分析，+EliminateLocks表示锁消除

逃逸分析：比如上面的代码，它要看sBuf是否可能逃出它的作用域？如果将sBuf作为方法的返回值进行返回，那么它在方法外部可能被当作一个全局对象使用，就有可能发生线程安全问题，这时就可以说sBuf这个对象发生逃逸了，因而不应将append操作的锁消除，但我们上面的代码没有发生锁逃逸，锁消除就可以带来一定的性能提升。

java中对象锁有4种状态：（级别从低到高）
1.无锁状态
2.偏向锁状态
3.轻量级锁状态
4.重量级锁状态

对象头分两部分信息，第一部分用于存储哈希码、GC分代年龄等，这部分数据被称为"Mark Word"。在32位的HotSpot虚拟机中对象未被锁定的状态下，Mark Word的32bit空间中的25bit用于存储对象哈希码，4bit用于存储对象分代年龄，2bit用于存储锁标志位，1bit固定为0，在其他状态(轻量级锁定、重量级锁定、GC标记、可偏向)下对象的存储内容见下表：

锁升级的方向是：无锁——>偏向锁——>轻量级锁——>重量级锁，并且膨胀方向不可逆。

1.偏向锁
偏向锁是JDK6中引入的一项锁优化，大多数情况下，锁不仅不存在多线程竞争，而且总是由同一线程多次获得，为了让线程获得锁的代价更低而引入了偏向锁。
偏向锁会偏向于第一个获得它的线程，如果在接下来的执行过程中，该锁没有被其他的线程获取，则持有偏向锁的线程将永远不需要同步。

2.轻量级锁
如果明显存在其它线程申请锁，那么偏向锁将很快升级为轻量级锁。

3.自旋锁
自旋锁原理非常简单，如果持有锁的线程能在很短时间内释放锁资源，那么那些等待竞争锁的线程就不需要做内核态和用户态之间的切换进入阻塞挂起状态，它们只需要等一等（自旋），等持有锁的线程释放锁后即可立即获取锁，这样就避免用户线程和内核的切换的消耗。

4.重量级锁
指的是原始的Synchronized的实现，重量级锁的特点：其他线程试图获取锁时，都会被阻塞，只有持有锁的线程释放锁之后才会唤醒这些线程。

锁升级场景：

场景1： 程序不会有锁的竞争。
那么这种情况我们不需要加锁，所以这种情况下对象锁状态为无锁。

场景2： 经常只有某一个线程来加锁。
加锁过程：也许获取锁的经常为同一个线程，这种情况下为了避免加锁造成的性能开销，所以并不会加实际意义上的锁，偏向锁的执行流程如下：
1、线程首先检查该对象头的线程ID是否为当前线程；
2、A：如果对象头的线程ID和当前线程ID一直，则直接执行代码；B：如果不是当前线程ID则使用CAS方式替换对象头中的线程ID，如果使用CAS替换不成功则说明有线程正在执行，存在锁的竞争，这时需要撤销偏向锁，升级为轻量级锁。
3、如果CAS替换成功，则把对象头的线程ID改为自己的线程ID，然后执行代码。
4、执行代码完成之后释放锁，把对象头的线程ID修改为空。

场景3： 有线程来参与锁的竞争，但是获取锁的冲突时间很短。
当开始有锁的冲突了，那么偏向锁就会升级到轻量级锁；线程获取锁出现冲突时，线程必须做出决定是继续在这里等，还是回家等别人打电话通知，而轻量级锁的路基就是采用继续在这里等的方式，当发现有锁冲突，线程首先会使用自旋的方式循环在这里获取锁，因为使用自旋的方式非常消耗CPU，当一定时间内通过自旋的方式无法获取到锁的话，那么锁就开始升级为重量级锁了。

场景4： 有大量的线程参与锁的竞争，冲突性很高。
我们知道当获取锁冲突多，时间越长的时候，我们的线程肯定无法继续在这里死等了，所以只好先休息，然后等前面获取锁的线程释放了锁之后再开启下一轮的锁竞争，而这种形式就是我们的重量级锁。