Synchronized与锁升级

前言

  java的线程是映射到操作系统原生线程之上的，如果要阻塞或唤醒一个线程就需要操作系统介入，需要在户态与核心态之间切换，这种切换会消耗大量的系统资源，因为用户态与内核态都有各自专用的内存空间，专用的寄存器等，用户态切换至内核态需要传递给许多变量、参数给内核，内核也需要保护好用户态在切换时的一些寄存器值、变量等，以便内核态调用结束后切换回用户态继续工作.
  在Java早期版本中，synchronized属于重量级锁，效率低下，因为监视器锁（monitor）是依赖于底层的操作系统的Mutex Lock来实现的，挂起线程和恢复线程都需要转入内核态去完成，阻塞或唤醒一个Java线程需要操作系统切换CPU状态来完成，这种状态切换需要耗费处理器时间，如果同步代码块中内容过于简单，这种切换的时间可能比用户代码执行的时间还长”，时间成本相对较高，这也是为什么早期的synchronized效率低的原因
Java 6之后，为了减少获得锁和释放锁所带来的性能消耗，引入了轻量级锁和偏向锁

为什么每个Java对象都可以上锁

C++底层源码

Java的基类Object是由C++底层源码实现的,每一个Object对象都有一个ObjectMonitor实例
Monitor可以理解为一种同步工具，也可理解为一种同步机制，常常被描述为一个Java对象。Java对象是天生的Monitor，每一个Java对象都有成为Monitor的潜质，因为在Java的设计中 ，每一个Java对象自打娘胎里出来就带了一把看不见的锁，它叫做内部锁或者Monitor锁

Monitor(监视器锁)

**Monitor是在jvm底层实现的，底层代码是c++。本质是依赖于底层操作系统的Mutex Lock实现，操作系统实现线程之间的切换需要从用户态到内核态的转换，状态转换需要耗费很多的处理器时间成本非常高。**所以synchronized是Java语言中的一个重量级操作。

Monitor与java对象以及线程如何关联的

• 如果一个java对象被某个线程锁住，则该java对象的Mark Word字段中LockWord指向monitor的起始地址
• Monitor的Owner字段会存放拥有相关联对象锁的线程id

java6以后开始优化Synchronized

Java 6之后，为了减少获得锁和释放锁所带来的性能消耗，引入了轻量级锁和偏向锁,不会直接就是重量级锁了,但是注意一点,只会有锁升级,不会有锁降级,他是不会自动去降级的

synchronized锁升级

synchronized用的锁是存在Java对象头里的Mark Word中.锁升级功能主要依赖MarkWord中锁标志位和释放偏向锁标志位

MarkWord存储的hashCode

注意:只有调用过对象的hashCode()才会在MarkWord中存储hashCode的值,是一种懒加载的策略
注意这个jol打印出来的结果是要倒着去读数据的,实际生成的hashCode二进制码可能不够32位,所以就会进行补码,会占用前面25位unused的位数

        Object o = new Object();
        System.out.println(o.hashCode());
        System.out.println(Integer.toHexString(o.hashCode()));
        System.out.println(Integer.toBinaryString(o.hashCode()));
        System.out.println(ClassLayout.parseInstance(o).toPrintable());

1956725890
74a14482
1110100101000010100010010000010
java.lang.Object object internals:
 OFFSET  SIZE   TYPE DESCRIPTION                               VALUE
      0     4        (object header)                           01 82 44 a1 (00000001 10000010 01000100 10100001) (-1589345791)
      4     4        (object header)                           74 00 00 00 (01110100 00000000 00000000 00000000) (116)
      8     4        (object header)                           e5 01 00 f8 (11100101 00000001 00000000 11111000) (-134217243)
     12     4        (loss due to the next object alignment)
Instance size: 16 bytes
Space losses: 0 bytes internal + 4 bytes external = 4 bytes total

无锁的情况

无锁的情况下上面那个输出结果最后是 001 在对象头中表示是属于无锁的状态

偏向锁

当一段同步代码一直被同一个线程多次访问,由于只有一个线程那么该线程在后续访问时便会自动获得锁
会修改偏向锁位置为1,并且前面的54位放入当前线程的指针JavaThread*,标识目前的偏向锁被哪一个线程所持有

理论说明

  在实际应用运行过程中发现，“锁总是同一个线程持有，很少发生竞争”，也就是说锁总是被第一个占用他的线程拥有，这个线程就是锁的偏向线程。
  那么只需要在锁第一次被拥有的时候，记录下偏向线程ID。这样偏向线程就一直持有着锁(后续这个线程进入和退出这段加了同步锁的代码块时，不需要再次加锁和释放锁。而是直接比较对象头里面是否存储了指向当前线程的偏向锁)。
  如果相等表示偏向锁是偏向于当前线程的，就不需要再尝试获得锁了，直到竞争发生才释放锁。以后每次同步，检查锁的偏向线程ID与当前线程ID是否一致，如果一致直接进入同步。无需每次加锁解锁都去CAS更新对象头。如果自始至终使用锁的线程只有一个，很明显偏向锁几乎没有额外开销，性能极高。
  假如不一致意味着发生了竞争，锁已经不是总是偏向于同一个线程了，这时候可能需要升级变为轻量级锁，才能保证线程间公平竞争锁。偏向锁只有遇到其他线程尝试竞争偏向锁时，持有偏向锁的线程才会释放锁，线程是不会主动释放偏向锁的

技术实现

一个synchronized方法被一个线程抢到了锁时，那这个方法所在的对象就会在其所在的Mark Word中将偏向锁修改状态位,同时还会有占用前54位来存储线程指针作为标识。若该线程再次访问同一个synchronized方法时,该线程只需去对象头的Mark Word中去判断一下是否有偏向锁指向本身的ID，无需再进入 Monitor 去竞争对象了。

JVM参数说明

实际上偏向锁在JDK1.6之后是默认开启的，但是启动时间有延迟，所以需要添加参数**-XX:BiasedLockingStartupDelay=0让其在程序启动时立刻启动，只是实验用，平时默认设置就好
开启偏向锁： -XX:+UseBiasedLocking -XX:BiasedLockingStartupDelay=0
关闭偏向锁： -XX:-UseBiasedLocking 关闭之后程序默认会直接进入轻量级锁状态。**

偏向锁的撤销

偏向锁使用一种等到竞争出现才释放锁的机制，只有当其他线程竞争锁时，持有偏向锁的原来线程才会被撤销。撤销需要等待全局安全点(该时间点上没有字节码正在执行)，同时检查持有偏向锁的线程是否还在执行：

• 第一个线程正在执行synchronized方法(处于同步块)，它还没有执行完，其它线程来抢夺，该偏向锁会被取消掉并出现锁升级。此时轻量级锁由原持有偏向锁的线程持有，继续执行其同步代码，而正在竞争的线程会进入自旋等待获得该轻量级锁。
• 第一个线程执行完成synchronized方法(退出同步块)，则将对象头设置成无锁状态并撤销偏向锁，重新偏向

轻量级锁（本质就是CAS自旋）

说明介绍

轻量级锁是为了在线程近乎交替执行同步块时提高性能。
主要目的： 在没有多线程竞争的前提下，通过CAS减少重量级锁使用操作系统互斥量产生的性能消耗，本质就是先进行CAS自旋，实在不行了再去升级为重量级锁。
升级时机： 当关闭偏向锁功能或多线程竞争偏向锁会导致偏向锁升级为轻量级锁
假如线程A已经拿到锁，这时线程B又来抢该对象的锁，由于该对象的锁已经被线程A拿到，当前该锁已是偏向锁了。
而线程B在争抢时发现对象头Mark Word中的线程ID不是线程B自己的线程ID(而是线程A)，那线程B就会进行CAS操作希望能获得锁。
此时线程B操作中有两种情况：
如果锁获取成功，直接替换Mark Word中的线程ID为B自己的ID(A → B)，重新偏向于其他线程(即将偏向锁交给其他线程，相当于当前线程"被"释放了锁)，该锁会保持偏向锁状态，A线程Over，B线程上位；
如果锁获取失败，则偏向锁升级为轻量级锁，此时轻量级锁由原持有偏向锁的线程持有，继续执行其同步代码，而正在竞争的线程B会进入自旋等待获得该轻量级锁。

缺陷与解决方案

与所有的CAS操作一样，都有着相同的缺陷，就是线程过多，或者同步代码块耗时过长时，大量的CAS操作会导致CPU空转，消耗性能资源，拖慢整个操作系统。
所以在自旋达到一定的次数或者程度的时候,轻量级锁就会升级为重量级锁，在Java6之前这个次数是固定的，而在java6之后这个次数是进行了自适应的，大概是依据于同一个锁上一次自旋的时间和拥有锁线程的状态来决定的，是一个黑盒的东西，由jvm优化过的。

重量级锁

这个没什么好讲的了，就是Java5最开始的synchronized锁，也是最开始讲解的monitor那部分

最终总结

各种锁优缺点、synchronized锁升级和实现原理

锁	优点	缺点	适用场景
偏向锁	加锁和解锁不需要额外的消耗,和执行非同步方法相比仅存在纳秒级的差距	如果线程间存在锁竞争,会带来额外的锁撤销的消耗	适用于只有一个线程访问同步块的场景
轻量级锁	竞争的线程不会阻塞,提高了程序的响应速度	如果始终得不到锁竞争的线程,使用CAS自旋会白白消耗CPU资源	追求响应时间,同步块执行速度非常快
重量级锁	线程竞争不使用自旋,不会消耗CPU	线程阻塞,响应时间缓慢	追求吞吐量,同步块执行速度比较慢

synchronized锁升级过程总结：本质就是就是先自旋，不行再阻塞。
实际上是把之前的悲观锁(重量级锁)变成在一定条件下使用偏向锁以及使用轻量级(自旋锁CAS)的形式.
synchronized在修饰方法和代码块在字节码上实现方式有很大差异，但是内部实现还是基于对象头的MarkWord来实现的。
JDK1.6之前synchronized使用的是重量级锁，JDK1.6之后进行了优化，拥有了无锁->偏向锁->轻量级锁->重量级锁的升级过程，而不是无论什么情况都使用重量级锁。
偏向锁:适用于单线程适用的情况，在不存在锁竞争的时候进入同步方法/代码块则使用偏向锁。
轻量级锁：适用于竞争较不激烈的情况(这和乐观锁的使用范围类似)， 存在竞争时升级为轻量级锁，轻量级锁采用的是自旋锁，如果同步方法/代码块执行时间很短的话，采用轻量级锁虽然会占用cpu资源但是相对比使用重量级锁还是更高效。
重量级锁：适用于竞争激烈的情况，如果同步方法/代码块执行时间很长，那么使用轻量级锁自旋带来的性能消耗就比使用重量级锁更严重，这时候就需要升级为重量级锁。

总体的流程图

64位的MarkWord标记图

文末小知识(JIT的锁优化)

JIT是什么

JIT就是即时编译器,大家应该都知道,之前读过jvm的书大家都清楚,他能把咱们写的一些不好的代码,自动优化成比较高性能或者更加简略的字节码去执行,他的工作原理很复杂,之前读过的周志明老师的书也只是简单讲了下他的影响,比如你写的if-else分路,但是有一个分路从来不走,或者一些废话代码,他可能就直接给你省略掉了,属于编译器和JVM运行期方法的一种优化,有兴趣的可以去看看书.这里主要讲一下JIT对synchronized关键字的优化

锁消除

这个就相当于你给每个线程都new了一个对象然后对这个线程加锁,这么写本身就是线程隔离的(正常人不会这么干),所以JIT直接就无视了这个synchronized关键字,让他变得和执行普通方法一样
示例代码

public void m1()
    {
        //锁消除,JIT会无视它，synchronized(对象锁)不存在了。不正常的
        Object o = new Object();

        synchronized (o)
        {
            System.out.println("-----hello LockClearUPDemo"+"\t"+o.hashCode()+"\t"+objectLock.hashCode());
        }
    }

    public static void main(String[] args)
    {
        LockClearUPDemo demo = new LockClearUPDemo();

        for (int i = 1; i <=10; i++) {
            new Thread(() -> {
                demo.m1();
            },String.valueOf(i)).start();
        }
    }

锁粗化

这个也很简单,假如方法中首尾相接,前后相邻的都是同一个锁对象,那JIT编译器就会把这几个synchronized块合并成一个大块,加粗加大范围,一次申请锁使用即可,避免次次的申请和释放锁,提升了性能
示例代码

new Thread(() -> {
            synchronized (objectLock) {
                System.out.println("11111");
            }
            synchronized (objectLock) {
                System.out.println("22222");
            }
            synchronized (objectLock) {
                System.out.println("33333");
            }
        },"a").start();