Java synchronized锁类 java锁synchronized底层实现

一、概述

synchronized作用

原子性：synchronized保证语句块内操作是原子的；（原子操作可以是一个步骤，也可以是多个操作步骤，但是其顺序不可以被打乱，也不可以被切割而只执行其中的一部分（不可中断性）。将整个操作视为一个整体是原子性的核心特征）
可见性：synchronized保证可见性（通过“在执行unlock之前，必须先把此变量同步回主内存”实现）
有序性：synchronized保证有序性（通过“一个变量在同一时刻只允许一条线程对其进行lock操作”）

synchronized的使用

Java中每一个对象都可以作为锁，这是synchronized实现同步的基础。

• 普通同步方法，对当前实例对象加锁
• 静态同步方法，对当前类的Class对象加锁
• 同步方法块，对synchronized括号内的对象加锁

二、实现原理

JVM是基于进入和退出monitor对象来实现方法同步和代码块同步。

这里要注意：

• synchronized是可重入的，所以不会自己把，自己锁死
• synchronized锁一旦被一个线程持有，其他试图获取该锁的线程将被阻塞。

synchronized同步原理

synchronized 仅是Java中的一个关键字，在使用的过程中并没有看到显示的加锁和解锁过程。因此有必要通过 javap 命令，查看相应的字节码文件。

synchronized修饰代码块

public class Test implements Runnable {
    @Override
    public void run() {
        // 加锁操作
        synchronized (this) {
            System.out.println("hello");
        }
    }

    public static void main(String[] args) {
        Test test = new Test();
        Thread thread = new Thread(test);
        thread.start();
    }
}

代码块的同步是利用monitorenter和monitorexit这两个字节码指令。它们分别位于同步代码块的开始和结束位置。当jvm执行到monitorenter指令时，当前线程试图获取monitor对象的所有权，如果未加锁或者已经被当前线程所持有，就把锁的计数器+1；当执行monitorexit指令时，锁计数器-1；当锁计数器为0时，该锁就被释放了。如果获取monitor对象失败，该线程则会进入阻塞状态，直到其他线程释放锁。

为什么会有两个monitorexit呢？

这个主要是防止在同步代码块中线程因异常退出，而锁没有得到释放，这必然会造成死锁（等待的线程永远获取不到锁）。因此最后一个monitorexit是保证在异常情况下，锁也可以得到释放，避免死锁。

synchronized修饰方法

public class Test implements Runnable {
    @Override
    public synchronized   void run() {
            System.out.println("hello again");
    }

    public static void main(String[] args) {
        Test test = new Test();
        Thread thread = new Thread(test);
        thread.start();
    }
}

方法级的同步是隐式的，即无需通过字节码指令来控制的，它实现在方法调用和返回操作之中。JVM可以从方法常量池中的方法表结构(method_info Structure) 中的 ACC_SYNCHRONIZED 访问标志区分一个方法是否同步方法。当方法调用时，调用指令将会检查方法的 ACC_SYNCHRONIZED 访问标志是否被设置，如果设置了，执行线程将先持有monitor（虚拟机规范中用的是管程一词）， 然后再执行方法，最后在方法完成(无论是正常完成还是非正常完成)时释放monitor。

synchronized可重入的原理

重入锁是指一个线程获取到该锁之后，该线程可以继续获得该锁。底层原理维护一个计数器，当线程获取该锁时，计数器加一，再次获得该锁时继续加一，释放锁时，计数器减一，当计数器值为0时，表明该锁未被任何线程所持有，其它线程可以竞争获取锁。

三、理解Java对象内存模型

在JVM中，对象在内存中的布局分为三块区域：对象头、实例数据和对齐填充。

HotSpot虚拟机的对象头分为两部分信息，第一部分用于存储对象自身运行时数据，如哈希码、GC分代年龄等，这部分数据的长度在32位和64位的虚拟机中分别为32位和64位，官方称为Mark Word，即对象标记；另一部分用于存储指向对象类型数据的指针，即类型指针，JVM根据该指针确定该对象是哪个类的实例化对象，如果是数组对象的话，还会有一个额外的部分存储数组长度。

实例变量：存放类的属性数据信息，包括父类的属性信息，如果是数组的实例部分还包括数组的长度，这部分内存按4字节对齐。

填充数据：由于虚拟机要求对象起始地址必须是8字节的整数倍。填充数据不是必须存在的，仅仅是为了字节对齐。

由于对象头的信息是与对象自身定义的数据没有关系的额外存储成本，因此考虑到JVM的空间效率，Mark Word 被设计成为一个非固定的数据结构，以便存储更多有效的数据，它会根据对象本身的状态复用自己的存储空间。

为什么Java的任意对象都可以作为锁？

在Java对象头中，存在一个monitor对象，每个对象自创建之后在对象头中就含有monitor对象，monitor是线程私有的，不同的对象monitor自然也是不同的，因此对象作为锁的本质是对象头中的monitor对象作为了锁。这便是为什么Java的任意对象都可以作为锁的原因。

四、JVM对synchronized的锁优化

Synchronized是通过对象内部的一个叫做监视器锁（monitor）来实现的，监视器锁本质又是依赖于底层的操作系统的Mutex Lock（互斥锁）来实现的。而操作系统实现线程之间的切换需要从用户态转换到核心态，这个成本非常高，状态之间的转换需要相对比较长的时间，这就是为什么Synchronized效率低的原因。因此，这种依赖于操作系统Mutex Lock所实现的锁我们称之为“重量级锁”。

Java SE 1.6为了减少获得锁和释放锁带来的性能消耗，引入了 “偏向锁” 和 “轻量级锁” ：锁一共有4种状态，级别从低到高依次是：无锁状态、偏向锁状态、轻量级锁状态和重量级锁状态。锁可以升级但不能降级。

1、偏向锁

偏向锁是JDK1.6中引用的优化，它的目的是消除数据在无竞争情况下的同步原语，进一步提高程序的性能。

偏向锁的获取

• 线程A第一次访问同步块时，先检测对象头Mark Word中的锁标志位是否为01，依此判断此时对象锁是否处于无锁状态或者偏向锁状态（匿名偏向锁）；
• 然后判断偏向锁标志位是否为1，如果不是，则进入轻量级锁逻辑（使用CAS竞争锁），如果是，则进入下一步流程；
• 如果为可偏向状态，则判断线程ID是否是当前线程，如果是进入同步块；
• 如果线程ID并未指向当前线程，利用CAS操作竞争锁，如果竞争成功，将Mark Word中线程ID更新为当前线程ID，进入同步块；
• 如果竞争失败，等待全局安全点，准备撤销偏向锁，根据线程是否处于活动状态，决定是转换为无锁状态还是升级为轻量级锁；
• 最后唤醒暂停的线程，从安全点继续执行代码。

当锁对象第一次被线程获取的时候，虚拟机会把对象头中的标志位设置为“01”，即偏向模式。同时使用CAS操作把获取到这个锁的线程ID记录在对象的Mark Word中。如果CAS操作成功，持有偏向锁的线程以后每次进入这个锁相关的同步块时，虚拟机都可以不再进行任何同步操作。

偏向锁的释放

偏向锁只有当出现竞争时，才会出现锁撤销。

• 等待全局安全点（safe point，代表了一个状态，在该状态下所有线程都是暂停的），首先会暂停拥有偏向锁的线程，检查持有锁的线程状态（遍历当前JVM的所有线程，如果能找到，则说明偏向的线程还存活）。
• 如果线程还存活，则检查线程是否在执行同步代码块中的代码，如果是，则升级为轻量级锁，进行CAS竞争锁；
• 如果持有偏向锁的线程未存活，或者持有偏向锁的线程未在执行同步代码块中的代码，则进行校验是否允许重偏向，如果不允许重偏向，则撤销偏向锁，将Mark Word设置为无锁状态（未锁定不可偏向状态），然后升级为轻量级锁，进行CAS竞争锁；
• 如果允许重偏向，设置为匿名偏向锁状态,CAS将偏向锁重新指向线程A（在对象头和线程栈帧的锁记录中存储当前线程ID）

注：每次进入同步块（即执行monitorenter）的时候都会以从高往低的顺序在栈中找到第一个可用的Lock Record，并设置偏向线程ID；每次解锁（即执行monitorexit）的时候都会从最低的一个Lock Record移除。所以如果能找到对应的Lock Record说明偏向的线程还在执行同步代码块中的代码。

2、轻量级锁

偏向锁考虑的是不存在多个线程竞争同一把锁，而轻量级锁考虑的是，多个线程不会在同一时刻来竞争同一把锁。

加锁过程

• 在代码进入同步块的时候，如果此对象没有被锁定（锁标志位为“01”状态），虚拟机首先在当前线程的栈帧中建立一个名为锁记录（Lock Record）的空间，用于存储对象目前Mark Word的拷贝（官方把这份拷贝加了一个Displaced前缀，即Displaced Mark Word）。
• 然后虚拟机使用CAS操作尝试将对象的Mark Word更新为指向锁记录（Lock Record）的指针。如果更新成功，那么这个线程就拥有了该对象的锁，并且对象的Mark Word标志位转变为“00”，即表示此对象处于轻量级锁定状态；
• 如果更新失败，虚拟机首先会检查对象的Mark Word是否指向当前线程的栈帧，如果说明当前线程已经拥有了这个对象的锁，那就可以直接进入同步块中执行，否则说明这个锁对象已经被其他线程占有了，当前线程便使用自旋来不断尝试。
• 如果有两条以上的线程竞争同一个锁，那轻量级锁不再有效，要膨胀为重量级锁，锁标志变为“10”，Mark Word中存储的就是指向重量级锁的指针，而后面等待的线程也要进入阻塞状态。

解锁过程

• 【正常解锁】如果对象的Mark Word仍然指向线程的锁记录，那就用CAS操作将对象当前的Mark Word与线程栈帧中的Displaced Mark Word交换回来，如果替换成功，整个同步过程就完成了；
  -【锁升级】 如果替换失败，说明有其他线程尝试过获取该锁（自旋次数达到一定值，对象头中锁标志位将变为 10（重量级锁），MarkWord 中存储的也就是指向互斥量（重量级锁）的指针），那就要在释放锁的同时，唤醒被挂起的线程。

如果没有竞争，轻量级锁使用CAS操作避免了使用互斥量的开销，但如果存在竞争，除了互斥量的开销外，还额外发生了CAS操作，因此在有竞争的情况下，轻量级锁比传统重量级锁开销更大。

3、重量级锁

重量级锁描述同一时刻有多个线程竞争同一把锁。

当多个线程共同竞争同一把锁时，竞争失败得锁会被阻塞，等到持有锁的线程将锁释放后再次唤醒阻塞的线程，因为线程的唤醒和阻塞是一个很耗费CPU资源的操作，因此此处采取自适应自旋来获取重量级锁。

4、自旋锁

互斥同步对性能影响最大的是阻塞的实现，挂起线程和恢复线程的操作都需要转入到内核态中完成，这些操作给系统的并发性能带来很大的压力。

于是在阻塞之前，我们让线程执行一个忙循环（自旋），看看持有锁的线程是否释放锁，如果很快释放锁，则没有必要进行阻塞。

• 缺点：若线程占用锁时间过长，导致CPU资源白白浪费。
• 解决方式：当尝试次数达到每个值的时候，线程挂起。

5、自适应自旋锁

如果在上一次自旋时获取到锁，则此次自旋时间稍微变长一点；如果在上一次自旋结束还没有获取到锁，此次自旋时间稍微短一点。

6、锁消除

锁消除是指虚拟机即时编译器（JIT）在运行时，对一些代码上要求同步，但是检测到不可能发生数据竞争的锁进行消除。比如线程的私有变量，不存在并发问题，没有必要加锁，即使加锁编译后，也会去掉。

7、锁粗化

如果虚拟机检测到有这样一串零碎的操作都对同一个对象加锁，将会把加锁同步的范围扩展（粗化）到整个操作序列的外部。比如当一个循环中存在加锁操作时，可以将加锁操作提到循环外面执行，一次加锁代替多次加锁，提升性能。

拓展：CAS（Compare And Swap）

• CAS（无锁操作）：使用比较、交换来判断是否出现冲突，出现冲突就重试当前操作直到不冲突为止。
• 悲观锁（JDK1.6之前的内建锁）：假设每一次执行同步代码块均会产生冲突，所以当线程获取锁成功，会阻塞其他尝试获取该锁的线程。
• 乐观锁（Lock机制）：假设所有线程访问共享资源时不会出现冲突，既然不会出现冲突自然就不会阻塞其他线程。线程不会出现阻塞状态。

CAS操作

CAS的操作过程和（V，O，N）三个值有关

CAS在最开始的时候V和O的是相等的，N中的每次线程要进行CAS操作时要新放入的值。当要进行CAS操作时，要先判断一下V和O，若相等，说明没有V中的值还没有被其他线程更改，这时就可以将N中的值替换到V中。若不相等表明V中的值已经被其他的线程所更改，这时直接将V中的值返回即可；

当多个线程同时进行CAS操作时，只有一个线程会成功，并且更新V的值，其余的线程会失败。失败后可以选择不断的进行CAS操作，也可以直接挂起进行等待。

CAS操作与内建锁的对比

为什么说CAS是乐观锁

乐观锁，严格来说并不是锁，通过原子性来保证数据的同步，比如说数据库的乐观锁，通过版本控制来实现，所以CAS不会保证线程同步。乐观的认为在数据更新期间没有其他线程影响。

CAS总结

• CAS（Compare And Swap）比较并替换，是线程并发运行时用到的一种技术
• CAS是原子操作，保证并发安全，而不能保证并发同步
• CAS是CPU的一个指令（需要JNI调用Native方法，才能调用CPU的指令）
• CAS是非阻塞的、轻量级的乐观锁

CAS应用

由于CAS是CPU指令，我们只能通过JNI（Java本地接口）与操作系统交互，关于CAS的方法都在sun.misc包下Unsafe的类里，java.util.concurrent.atomic 包下的原子类等通过CAS来实现原子操作。

使用乐观锁还是悲观锁

从上面对两种锁的介绍，我们知道两种锁各有优缺点，不可认为一种好于另一种，像乐观锁适用于写比较少的情况下（多读场景），即冲突真的很少发生的时候，这样可以省去了锁的开销，加大了系统的吞吐量。但如果是多写的情况，一般会经常发生冲突，这就会导致CAS算法会不断的进行retry，这样反倒是降低了性能，所以一般多写的场景下用悲观锁就比较合适。

CAS指令和具体源代码

原子类例如AtomicInteger里的方法都很简单，我们看一下getAndIncrement方法：

//该方法功能是Interger类型加1
public final int getAndIncrement() {
        //主要看这个getAndAddInt方法
        return unsafe.getAndAddInt(this, valueOffset, 1);
    }

//var1 是this指针
//var2 是地址偏移量
//var4 是自增的数值，是自增1还是自增N
public final int getAndAddInt(Object var1, long var2, int var4) {
        int var5;
        do {
            //获取内存值，这是内存值已经是旧的，假设我们称作期望值E
            var5 = this.getIntVolatile(var1, var2);
            //compareAndSwapInt方法是重点，
            //var5是期望值，var5 + var4是要更新的值
            //这个操作就是调用CAS的JNI,每个线程将自己内存里的内存值M
            //与var5期望值E作比较，如果相同将内存值M更新为var5 + var4,否则做自旋操作
        } while(!this.compareAndSwapInt(var1, var2, var5, var5 + var4));

        return var5;
    }

解释一下getAndAddInt方法的流程：

假设有一下情景：
1、A、B两个线程；
2、jvm主内存的值1，A、B工作内存的值为1（工作内存会拷贝一份主内存的值）；
3、当前期望值为1，做加1操作；
4、此时var5 = 1，var4 = 1；

1. A线程将var5与工作内存值M比较，比较var5是否等于1；
2. 如果相同则将工作内存值修改为var5 + var4 即修改为2并同步到主存，此
   时this + valueOffset指针里，示例变量value的值就是2，结束循环；
3. 如果不相同，则是B线程修改了主内存的值，说明B线程已经先于A线程做了加1操作，A线程没有更新成功需要继续循环，注意此时var5更新为新的内存值，假设当前的内存值是2，那么此时var5 = 2，var5 + var4 = 3，重复上述步骤直到成功（自旋），成功之后，内存地址中的值就改变为3。

CAS优缺点

优点

• 非阻塞的轻量级的乐观锁，通过CPU指令实现，在资源竞争不激烈的情况下性能高，相比synchronized重量锁，synchronized会进行比较复杂的加锁、解锁和唤醒操作。

缺点

• ABA问题： 线程C、D；线程D将A修改为B后又修改为A，此时C线程以为A没有改变过，java的原子类AtomicStampedReference，通过控制变量值的版本号来保证CAS的正确性。
  解决思路：就是在变量前追加上版本号，每次变量更新的时候把版本号加一，那么A - B - A就会变成1A - 2B - 3A。（JDK1.5提供atomic包下 AtomicStampedReference类来解决CAS的ABA问题）
• 自旋时间过长，消耗CPU资源，如果资源竞争激烈，多线程自旋长时间消耗资源。
  解决思路：为了解决这个问题，CPU就采取了一种处理机制：自适应自旋，即根据以往自旋等待时能否获取到锁，来动态调整自旋的时间（循环尝试数量）。如果在上一次自旋时获取到锁，则此次自旋时间稍微变长一点；如果在上一次自旋结束还没有获取到锁，此次自旋时间稍微短一点。

关于公平性

• 公平模式：比如一个锁被很多线程等待是时，锁会选择等待时间最长的线程访问它的临界资源，可以和队列类比一下理解为先到先得原则（lock锁）它就是公平的；
• 非公平模式：当一个锁是可以被后来的线程抢占时，它就是非公平性的，比如内建锁（饥饿问题：由于访问权限总是分配给了其他线程，而造成一个或多个线程被饿死的现象）。

自旋也是一种不公平的模式：处于阻塞状态的线程无法立刻竞争被释放的锁；而处于自旋状态的线程很有可能先获取到锁。