详解synchronize关键字

键盘歌唱家

已于 2022-07-09 14:09:55 修改

阅读量372

点赞数

分类专栏： javase 文章标签： java spring 开发语言

于 2022-06-25 10:49:33 首次发布

本文链接：https://blog.csdn.net/MoastAll/article/details/125455378

版权

javase 专栏收录该内容

20 篇文章 0 订阅

订阅专栏

一、sychronized的使用

sychronized关键字的使用比较常见的分为以下的几种形式：

public class Test{
	//1.对象锁（如果使用相同的对象调用该方法，则认为是一把锁）
	public synchronized void aa(){  
		......
    }
    //2.对象锁2(跟1本质上是一样的)
    public void bb(){
        synchronized (this) {
            ......
        }
    }
	
	//3.类锁(该类的不同对象调用该方法，都认为是一把锁)
	public static synchronized void cc(){
        ......
    }
    //4.类锁2
    public void bb(){
        synchronized (Test.class) {
            ......
        }
    }
}

比较特殊的使用是synchronized可以将任意一个对象当成锁，这在Spring源码中就有体现：
在这里插入图片描述

二、sychronized加锁的本质

1.从字节码的角度来看

1.synchronized代码块，底层是利用monitorenter和monitorexit来实现的。（一般情况是1个monitorenter对应2个monitorexit）

在这里插入图片描述

2.如果是静态同步方法则是通过给flags加上标识来完成的！
方法级的同步是隐式的，无须通过字节码指令来控制，它实现在方法调用和返回操作之中。虚拟机可以从方法常量池中的方法表结构中的ACC_SYNCHRONIZED访问标志得知一个方法是否被声明为同步方法。当方法调用时，调用指令将会检查方法的ACC_SYNCHRONIZED访问标志是否被设置，如果设置了，执行线程就要求先成功持有管程，然后才能执行方法，最后当方法完成(无论是正常完成还是非正常完成）时释放管程。在方法执行期间，执行线程持有了管程，其他任何线程都无法再获取到同一个管程。如果一个同步方法执行期间抛出了异常，并且在方法内部无法处理此异常，那这个同步方法所持有的管程将在异常抛到同步方法边界之外时自动释放.（普通的同步方法是没有ACC_STATIC标识！）

在这里插入图片描述

2.从对象内存布局的角度来看

加锁的本质就是修改了对象头的markword信息，以下对象的内存布局的结构图：
在这里插入图片描述

我们可以通过openjdk提供的jol工具来分析对象的内存布局，可以引入以下的依赖：

   <dependency>
       <groupId>org.openjdk.jol</groupId>
       <artifactId>jol-core</artifactId>
       <version>0.10</version>
   </dependency>

    public static void main(String[] args) {
    	//try{TimeUnit.SECONDS.sleep(5);}catch(Exception e){e.printStack()}
        Object o = new Object();
        System.out.println(ClassLayout.parseInstance(o).toPrintable());
        System.out.println("=============================");
        synchronized (o) {
            System.out.println(ClassLayout.parseInstance(o).toPrintable());
        }
    }

经过运行，我们发现加锁后的对象的object header（对象头）发生了改变，如下图所示：
在这里插入图片描述

从上图的第一行的object header可以看出此时是轻量级锁。（如果取消掉代码第一行的注释信息，则结果会是偏向锁因为偏向锁机制在4秒以后才会启动）
在这里插入图片描述

3.jvm底层cpp源码分析

在HotSpot虚拟机中，monitor采用的是ObjectMonitor实现的（对应Java的Object类）。有兴趣的小伙伴可以下载openJDK查看ObjectMonitor.cpp和ObjectMonitor.hpp两个文件。Monitor的本质是依赖于底层操作系统的Mutex Lock实现，操作系统实现线程之间的切换.
为什么每个对象都能当成锁，原因请看ObjectMonitor.hpp，因为每个对象天生都带有对象监视器，每一个被锁的对象都和monitor关联起来！
在这里插入图片描述

1.当执行monitorenter时，如果目标锁对象的计数器为零，那么说明它没有被其他线程所持有，Java成拟机会将该锁对象的持有线程设置为当前线程，并且将其计数器加1。
2.在目标锁对象的计数器不为零的情况下，如果锁对象的持有线程是当前线程，那么Java虚拟机可以将其计数器加1，否则需要等待，直至持有线程释放该锁。
3.当执行monitorexit时，Java虚拟机则需将锁对象的计数器减1。计数器为零代表锁已被释放。

三、锁升级流程

下图是锁升级的过程，主要由对象头中的Mark Word根据锁标志位的不同而被复用及锁升级策略
在这里插入图片描述

在这里插入图片描述

1.JAVA5的锁

java5以前，只有Synchronized，这个是操作系统级别的重量级操作，假如锁的竞争比较激烈的话，性能下降（因为有用户态和内核态的切换！）
在这里插入图片描述

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

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

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

2.锁指向

synchronized主要有四种锁状态：无锁、偏向锁、轻量锁、重量锁。
在这里插入图片描述

3.无锁状态

在这里插入图片描述
下图是对上面的一种证明：

4.偏向锁（单线程竞争）

4.1 当线程A第一次竞争到锁时，通过操作修改Mark Word中的偏向线程ID、偏向模式。如果不存在其他线程竞争，那么持有偏向锁的线程永远不需要进行同步。（当一段同步代码一直被同一个线程访问，由于只有一个线程那么该线程在后续访问时便会自动获取锁。）

Hotspot作者经过研究发现：多线程情况下，锁不仅不存在多线程竞争，还存在锁由同一线程多次获得的情况，偏向锁就是在这种情况下出现的，它的出现是为了解决只有在一个线程执行同步时提高性能。
备注：偏向锁会偏向于第一个访问锁的线程，如果在接下来的运行过程中，该锁没有被其他线程访问，则持有偏向锁的线程永远不需要触发同步。也即偏向锁在资源没有竞争情况下消除了同步语句，懒得连CAS操作都不做了，直接提高程序性能。

4.2 更详细的解释：

锁总是被第一个占用他的线程拥有，这个线程就是锁的偏向线程。那么只需要在锁第一次被拥有的时候，记录下偏向线程id，这样偏向线程就一直持有着锁（后续这个线程进入和退出这段加了同步锁的代码块时，不需要再次加锁和释放锁，而是直接去检查锁的Mark Word里面是不是放着自己的线程ID）
1.如果相等：表明偏向锁是偏向当前线程的，就不需要再尝试获得锁了，直到竞争发生才释放锁。以后每次同步，检查锁的偏向线程ID与当前线程ID是否一致，如果一致直接进入同步。无需每次加锁解锁都去CAS更换对象头。如果自始自终使用锁的线程只有一个，很明显偏向锁几乎没有额外开销，性能极高！
2.如果不等：表明发生了竞争，锁已经不是总是偏向于同一线程了，这个时候会尝试使用CAS来替换Mark Word里面的线程ID为新线程ID。
2.1竞争成功：表示之前的线程不存在了，Mark Word里面的线程ID为新线程ID，锁不会升级，仍为偏向锁
2.2竞争失败：这时候可能需要升级为轻量级锁，才能保证线程间公平竞争锁
注意，偏向锁只有遇到其他线程尝试竞争偏向锁时，持有偏向锁的线程才会释放锁，线程是不会主动释放偏向锁的。
技术实现：
一个synchronized方法被一个线程抢到锁时，那这个方法所在的对象就会在其所在的Mark Word中将偏向锁修改状态位，同时还会占有前54位来存储线程指针作为标识。若该线程再次访问同一个synchronized方法时，该线程只需去对象头的Mark Word中去判断一下是否有偏向锁指向本身的ID，无需再进入Monitor去竞争对象了。

4.3 细化案例Account对象举例说明：

偏向锁操作不会直接捅到操作系统，不涉及用户到内核转化，不要直接升级为最高级我们以一个count对象的对象头为例：

假如有一个线程执行到synchronized代码块的时候，JVM使用CAS操作把线程指针ID记录到Mark Word当中，并修改该偏向标示，标示当前线程就获得该锁。锁对象变成偏向锁（通过CAS修改对象头里的锁标示位），字面意思是“偏向第一个获得它的线程”的锁。执行完同步代码块后，线程并不会主动释放偏向锁。

这时候线程获得了锁，可以执行同步代码块。当该线程第二次到达同步代码块时会判断此时持有锁的线程是否还是自己（持有锁的线程ID也在对象头里面），JVM通过account对象的Mark Word判断：当前线程ID还在，说明还持有着这个对象的锁，就可以继续进入临界区工作。由于之前没有释放锁，这里也就不需要重新加锁。如果自始自终，使用锁的线程只有一个，很明显偏向锁没有额外开销，性能极高！结论：JVM不用和操作系统协商Mutex（争取内核），它只需要记录下线程ID就标示自己获得了当前锁，不用操作系统介入。

4.4 执行时间
可以通过下面的命令查看jvm对偏向锁的设置信息：

java -XX:+PrintFlagsInitial | grep BiasedLock

在这里插入图片描述
偏向锁在JDK1.6之后是默认开启的，但在Java15后被废除。默认是有四秒的延迟时间：

#开启偏向锁
-XX:+UseBiasedLocking -XX:BiasedLockingStartupDelay=0
#关闭偏向锁。----》关闭之后程序默认进入轻量级锁
-XX:-UseBiasedLocking

在这里插入图片描述

4.5 偏向锁撤销
在这里插入图片描述

偏向锁使用一种等到竞争出现才释放锁的机制，只有当其他线程竞争锁时，持有偏向锁的原来线程才会被撤销。撤销需要等待全局安全点（该时间点没有字节码正在执行），同时检查持有偏向锁的线程是否还在执行：
1⃣️：第一个线程正在执行synchronized方法（处于同步块），它还没有执行完，其他线程来抢夺，该偏向锁会被取消掉并出现锁升级。此时轻量级锁由原持有偏向锁的线程持有，继续执行其他代码块，而正在竞争的线程会进入自旋等待该轻量级锁。
2⃣️：第一个线程执行完成synchronized方法（退出同步块），则将对象头设置成无锁状态并撤销偏向锁，重新偏向

在这里插入图片描述

5. 轻量级锁

多线程竞争，但是任意时刻最多只有一个线程竞争，即不存在锁竞争太过激烈的情况，也就没有线程阻塞。轻量级锁是为了在线程近乎交替执行同步块时提高性能。
主要目的：在没有多线程竞争的前提下，通过CAS减少重量级锁使用操作系统互斥量产生的性能消耗，说白了先自旋，不行才升级阻塞。
升级时机：当关闭偏向锁功能或多线程竞争偏向锁会导致偏向锁升级为轻量级锁

假如线程A已经拿到了锁，这时候线程B又来抢该对象的锁，由于该对象的锁已经被线程A拿到，当前该锁已经是偏向锁了。而线程B在争抢时发现对象头Mark Word中的线程ID不是线程B 自己的线程ID（而是线程A），那么线程B就会进行CAS操作希望能获得锁。
此时线程B有两种情况：
如果获取锁成功，直接替换Mark Word中的线程ID为B自己的ID（A->B），重新偏向于其他线程（即将偏向锁交给其他线程，相当于当前线程被释放了锁），该锁会保持偏向锁状态，A线程Over，B线程上位！

如果获取锁失败，则偏向锁升级为轻量级锁（设置偏向锁标示为0，并设置锁标示位为00），此时轻量级锁由原持有偏向锁的线程持有，继续执行其同步代码，而正在竞争的线程B会进入自旋等待获得该轻量级锁

5.1 轻量级锁的加锁：
JVM会为每个线程在当前线程的栈帧中创建用于存储锁记录的空间，官方称为Displaced Mark Word,若一个线程获得锁时发现是轻量级锁，会把锁的Mark Word复制到自己的Displaced Mark Word里面。然后线程尝试用CAS将锁的Mark Word替换为指向锁记录的指针。如果成功，当前线程获得锁，如果失败则表示Mark Word已经被替换成了其他线程的锁记录，说明在与其他线程竞争锁，当前线程就尝试使用自旋来获取锁。

5.2轻量级锁的释放
在释放时，当前线程会使用CAS操作将Displaced Mark Word的内容复制回锁的Mark Word里面。如果没有发生竞争，那么这个复制的操作会成功。如果有其他线程因为自旋多次导致轻量级锁升级为重量级锁，那么CAS会失败，此时会释放锁并唤醒被阻塞的线程。

5.2自旋次数
Java6之前：默认情况下是自旋10次或者自旋线程超过CPU核数的一半，可以通过下面的jvm参数进行调节

-XX:PreBlockSpin=10

Java6之后，自适应自旋锁：线程如果自旋成功，那下次自旋的最大次数会增加，因为JVM认为既然上次成功了，那么这一次也很大概率会成功。反之，如果很少会自旋成功，那么下次会减少自旋次数甚至不自旋，避免CPU空转。

6.重量级锁

在这里插入图片描述
重量级锁原理：Java中synchronized重量级锁，是基于进入和退出Monitor对象实现的。在编译时会将同步块的开始位置插入monitor enter指令，在结束位置插入monitor exit指令。当线程执行到monitor enter指令时，会尝试获取对象所对应的Monitor所有权，如果获取到了，即获取到了锁，会在Monitor的owner中存放当前线程的ID，这样它将处于锁定状态，除非退出同步块，否则其他线程无法获取到该Monitor。

在这里插入图片描述

7.无锁到有锁状态时，hashCode去哪了？

锁升级成轻量级或重量级锁后，Mark Word中保存的分别是Lock Record指针和重量级锁指针，已经没有位置再保存HashCode，GC年龄。
在这里插入图片描述
可以用书中的一段话来解释上面的问题：

在无锁状态下：Mark Word可以存储对象的identity hash code值。当对象的hashCode()方法第一次被调用时，JVM会生成对应的identity hash code值并将该值存进Mark Word当中。
对于偏向锁:在线程获取偏向锁时，会用Thread ID和epoch值覆盖identity hash code所在的位置，如果一个对象的hashCode方法已经被调用过一次之后，这个对象不然被设置偏向锁。因为如果可以的话，那Mark Word中的identity hash code必然会被偏向线程Id给覆盖，这就会造成同一个对象前后两次调用hashCode()方法得到的结果不一致。
升级为轻量级锁时，JVM会在当前线程的栈帧中创建一个锁记录（Lock Record）空间，用于存储锁对象的Mark Word拷贝，该拷贝中可以包含identity hash code，所以轻量级锁可以和identity hash code共存，哈希码和GC年龄自然保存在此，释放锁后会将这些信息写回到对象头。
升级为重量级锁后，Mark Word保存的重量级锁指针，代表重量级锁的ObjectMonitor类里有字段记录非加锁状态下的Mark Word，锁释放后也会将这些信息写回对象头

在这里插入图片描述

8.锁的优缺点对比

在这里插入图片描述
锁升级过程总结：先自旋，不行再阻塞。实际上是把之前的悲观锁（重量级锁），变成一定条件下使用偏向锁以及使用轻量级（自旋锁CAS）的形式。
synchronized在修饰方法和代码块在字节码上实现方法有很大差异，但内部还是基于对象头的Mark Word来实现的。JDK1.6之前synchronized使用的是重量级锁，JDK1.6之后进行了优化，拥有了无锁-》偏向锁-〉轻量级锁-》重量级锁的升级过程，而不是什么情况下都用重量级锁。
在这里插入图片描述