【多线程】synchronized底层实现的方式

前言

在java 开发中对于锁的应用非常的常见，如果对于什么时候该用什么锁，以及锁实现的原理有所不知道的，或者面试过程中面试官问你不知道怎么回答的，欢迎来看下面的文章

1、synchronized和ReentrantLock的区别

2、synchronized的一些特性和底层原理的实现

2.1 synchronized 的锁升级过程

在 JVM 中，锁升级是不可逆的，即一旦锁被升级为下一个级别的锁，就无法再降级。

首先默认的无锁状态，当我们加锁以后，可能并没有多个线程去竞争锁，此时我们可以默认为只有一个线程要获取锁，即偏向锁，当锁转为偏向锁以后，被偏向的线程在获取锁的时候就不需要竞争，可以直接执行。

当确实存在少量线程竞争锁的情况时，偏向锁显然不能再继续使用了，但是如果直接调用重量级锁在轻量锁竞争的情况下并不划算，因为竞争压力不大，所以往往需要频繁的阻塞和唤醒线程，这个过程需要调用操作系统的函数去切换 CPU 状态从用户态转为核心态。因此，可以直接令等待的线程自旋，避免频繁的阻塞唤醒 ,此时升级为轻量级锁。

当竞争加大时，线程往往要等待比较长的时间才能获得锁，此时在等待期间保持自旋会白白占用 CPU 时间，此时就需要升级为重量级锁，即 Monitor 锁，JVM 通过指令调用操作系统函数阻塞和唤醒线程。

2.2 synchronized的锁优化

2.2.1 自适应自旋锁

自旋锁依赖于 CAS，我们可以手动的设置 JVM 的自旋锁自旋次数，但是往往很难确定适当的自旋次数，如果自旋次数太少，那么可能会引起不必要的锁升级，而自旋次数太长，又会影响性能。在 JDK6 中，引入了自适应自旋锁的机制，对于同一把锁，当线程通过自旋获取锁成功了，那么下一次自旋次数就会增加，而相反，如果自旋锁获取失败了，那么下一次在获取锁的时候就会减少自旋次数。

2.2.2 锁消除

在一些方法中，有些加锁的代码实际上是永远不会出现锁竞争的，比如 Vector 和 Hashtable 等类的方法都使用 synchronized 修饰，但是实际上在单线程程序中调用方法，JVM 会检查是否存在可能的锁竞争，如果不存在，会自动消除代码中的加锁操作。

2.2.3 锁粗化

我们常说，锁的粒度往往越细越好，但是一些不恰当的范围可能反而引起更频繁的加锁解锁操作，比如在迭代中加锁，JVM 会检测同一个对象是否在同一段代码中被频繁加锁解锁，从而主动扩大锁范围，避免这种情况的发生。

2.3 synchronized的底层原理的实现

synchronized 意为同步，它可以用于修饰静态方法，实例方法，或者一段代码块。其中修饰代码块和方法有一点不同
它是一种可重入的对象锁。当修饰静态方法时，锁对象为类；当修饰实例方法时，锁对象为实例；当修饰代码块时，锁可以是任何非 null 的对象。由于其底层的实现机制，synchronized 的锁又称为监视器锁。

同步代码块

    public void synchronizedMethod3() {