在多线程编程中，synchronized 一直都是元老级别的存在，很多人都称之为重量级锁。本文来简单介绍synchronized的实现原理，以及为减少获得锁和释放锁所带来的性能损耗而引进的偏向锁与轻量级锁。

    Java中使用synchronized来实现同步的基础是什么呢？Java中每一个对象都可以作为锁！

        对于普通同步方法，锁是当前实例对象。

        对于静态同步方法，锁是当前类的Class对象。

        对于同步方法块，锁是synchronized括号里配置的对象。

    当一个线程想要访问同步代码块时，它首先必须先得到锁，退出或抛出异常时需要释放锁。那么锁到底存在于哪里呢？

synchronized实现原理

    先来看一下synchronized的实现原理，JVM基于进入和退出Monitor对象来实现方法和代码块同步，使用monitorenter和monitorexit指令实现。monitorenter指令是在编译后插入到同步代码块的开始位置，而monitorexit是插入待方法结束处和异常处，JVM要保证每一个monitorenter必须有一个monitorexit与之对应。任何一个对象都有一个monitor与之关联，当一个monitor被持有后，它将处于锁定状态，当线程执行到monitorenter处时，会尝试获取monitor对象，即尝试获得对象的锁！

Java对象头

    synchronized用的锁是存在Java对象头里的。

    Java对象头里的Mark Word 里默认存储对象的HashCode、分代年龄和锁标记位。

锁的升级与自旋锁、公平锁

    Java 1.6后为了减少获得锁与释放锁所带来的性能损耗，引入了偏向锁与轻量级锁，在Java1.6中锁一共有四种状态，分别是：无锁状态、偏向锁状态、轻量级锁状态、重量级锁状态，这几种状态会随着竞争情况逐渐升级。锁状态只能升级而不能降级。

    偏向锁

        HotSpot的作者经过研究发现，大多数情况下，锁不仅不存在多线程竞争，而且总是由一个线程多次获得，为了让线程获得锁的代价更低而引入了偏向锁。当一个线程访问同步块并获取锁时，会在对象头和栈帧中存储锁偏向的线程ID，以后该线程再进入和退出同步块时不需要进行CAS操作来加锁和解锁，只需要简单的测试一下对象头的Mark Word里是否存储着指向当前线程的偏向锁。如果测试成功，表示线程已经获得了锁。如果测试失败，则需要再测试一下Mark Word中偏向锁标识是否设置成1（标识当前是偏向锁）：如果没有设置，则使用CAS竞争锁；如果设置了，则尝试使用CAS将对象头偏向锁指向当前线程。

    自旋锁

        在多线程条件下，由于Java的线程与系统内核线程是一一对应的，所以挂起线程和恢复线程的操作都需要转到内核中完成，这会给系统的并发性能带来很大的压力。同时，在许多应用上，共享数据的锁定状态只会持续很短的时间，为了这段时间挂起恢复线程并不值得。如果机器上能让两个或两个以上的线程同时执行，我们就可以让后面请求锁的线程“稍等一下”，但不放弃处理器的执行时间，看看持有锁的线程是否很快会释放锁。为了让线程等待，我们只需要让线程执行一个忙循环（自旋），这项技术就是所谓的自旋锁。

        当然，如果一个线程等待另一个线程释放锁，自旋的时间过长，那也将会浪费系统资源。JDK 1.6中引入了自适应的自旋锁。自旋等待的时间不再固定，由前一次在同一个锁上的自旋时间及锁的拥有者的状态来决定。如果在同一个锁对象上，自旋等待刚刚成功过，并且持有锁的线程正在运行中，那么虚拟机将会认为这次自旋也很有可能会成功，进而它将允许自旋等待相对更长的时间。

    轻量级锁

        轻量级锁并不是来替代重量级锁的，它是为了在没有多线程竞争下，减少操作系统的性能消耗。

      在代码进入同步块的时候，如果此对象没有被锁定，虚拟机首先将在当前线程的栈帧中创建一个名为锁记录（Lock Record）的空间，用于存储对象目前的Mark Word拷贝。当虚拟机将使用CAS操作尝试将对象的Mark Word更新为指向Lock Record的指针。如果这个动作成功了，那么这个对象就获得了对象的锁。如果这个更新失败了，虚拟机将会先检查对象的Mark Word是否指向当前的栈帧，如果是，则当前线程已经拥有了这个对象的锁，否则说明这个锁对象已经被其他线程抢占了。如果有两个以上的线程争用同一个锁，那么轻量级锁将会膨胀为重量级锁。

        轻量级锁能提升程序同步性能的根据是：对于绝大多数的锁，在整个同步周期内都是不存在竞争的。

    公平锁

        公平锁是指多个线程在等待同一个锁时，必须按照申请锁的时间顺序来依次获得锁；非公平锁不能保证这一点，在锁被释放时，任何一个等待的线程都有机会获得锁。synchronized中的锁时非公平的，ReentrantLock默认情况下也是非公平的，可以通过构造函数要求使用公平锁。

参考资料：《并发编程的艺术》、《深入理解Java虚拟机》

————————————————

版权声明：本文为CSDN博主「Zhang_hongxin」的原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接及本声明。

原文链接：https://blog.csdn.net/Zhang_hongxin/article/details/81631708