【Java】Synchronize与锁升级

最新推荐文章于 2024-07-28 14:23:21 发布

wildyuhao

最新推荐文章于 2024-07-28 14:23:21 发布

阅读量304

点赞数

分类专栏： Java 文章标签： java 多线程 jvm 面试

本文链接：https://blog.csdn.net/wildyuhao/article/details/108616866

版权

Java 专栏收录该内容

29 篇文章 0 订阅

订阅专栏

Synchronize与锁升级

1 Synchronize简介
2 锁优化

Synchronize实现方法，锁升级是Java面试中经常考到的内容，为了方便学习与理解Synchronize与锁升级，本文详细总结了一些相关的知识点。

1 Synchronize简介

synchronize是java中的关键字，可以用来修饰实例方法、静态方法、还有代码块；主要有三种作用：可以确保原子性、可见性、有序性，原子性就是能够保证同一时刻有且只有一个线程在操作共享数据，其他线程必须等该线程处理完数据后才能进行；Synchronize和lock通过锁保证任一时刻只有一个线程执行该代码，从而保证了原子性。可见性就是当一个线程在修改共享数据时，其他线程能够看到，保证可见性，volatile关键字也有这个功能；当共享变量被volatile修饰，它修改的值会立即更新到主存，当有其他线程需要读取该值时会从主存读取，lock和Synchronize能保证同一时刻只有一个线程获取锁执行同步代码，并且在释放锁之前将对变量的修改刷新到主存中，从而保证可见性。有序性就是被synchronize锁住后的线程相当于单线程，在单线程环境jvm的重排序是不会改变程序运行结果的，可以防止重排序对多线程的影响。synchronize和lock保证每个时刻只有一个线程执行同步代码，相当于线程顺序执行同步代码，从而保证了有序性。但是，synchronized保证的有序性是多个线程之间的有序性，即被加锁的内容要按照顺序被多个线程执行。但是其内部的同步代码还是会发生重排序，只不过由于编译器和处理器都遵循as-if-serial语义，所以我们可以认为这些重排序在单线程内部可忽略。

1.1 happens- before原则(先行发生原则)

另外，Java内存模型具备些先天的 ”有序性”, 即不需要通过任何手段就能够得到保证的有序性，这个通常也称为happens before原则。如果两个操作的执行次序无法从happens before原则推导出来，那么它们就不能保证它们的有序性，虑拟机可以随意地对它们进行重排序。

下面就来具体介绍下happens- before原则(先行发生原则)

程序次序规则：1个线程内，按照代码顺序.书写在前面的操作先行发生于书写在后面的操作
锁定规则:1个unlock操作先行发生于后面对同一个锁的Iock操作
volatile变量规则:对-个变量的写操作先行发生于后面对这个变量的读操作

1.2 synchronized使用场景

synchronized是Java中解决并发问题的一种最常用的方法，也是最简单的一种方法。synchronized的作用主要有三个：（1）确保线程互斥的访问同步代码（2）保证共享变量的修改能够及时可见（3）有效解决重排序问题。从语法上讲，它总共有三种使用场合：

修饰实例方法，作用于当前实例加锁，进入同步代码前要获得当前实例的锁

修饰静态方法，作用于当前类对象加锁，进入同步代码前要获得当前类对象的锁

修饰代码块，指定加锁对象，对给定对象加锁，进入同步代码库前要获得给定对象的锁。

1.3 Synchronize底层实现原理

synchronized的底层原理是跟monitor有关，也就是视图器锁，每个对象都有一个关联的monitor，当Synchronize获得monitor对象的所有权后会进行两个指令：加锁指令monitorenter跟减锁指令monitorexit。

monitor里面有个计数器，初始值是从0开始的。如果一个线程想要获取monitor的所有权，就看看它的计数器是不是0，如果是0的话，那么就说明没人获取锁，那么它就可以获取锁了，然后将计数器+1，也就是执行monitorenter加锁指令；monitorexit减锁指令是跟在程序执行结束和异常里的，如果不是0的话，就会陷入一个堵塞等待的过程，直到为0等待结束。

2 锁优化

在 Java 早期版本中，synchronized 属于重量级锁，效率低下，因为监视器锁（monitor）是依赖于底层的操作系统的 Mutex Lock 来实现的，Java 的线程是映射到操作系统的原生线程之上的。如果要挂起或者唤醒一个线程，都需要操作系统帮忙完成，而操作系统实现线程之间的切换时需要从用户态转换到内核态，这个状态之间的转换需要相对比较长的时间，时间成本相对较高，

因此，在 Java 6 之后 Java 官方对从 JVM 层面对synchronized 进行了较大优化：JDK1.6对锁的实现引入了大量的优化，如自旋锁、适应性自旋锁、锁消除、锁粗化、偏向锁、轻量级锁等技术来减少锁操作的开销，现在synchronized的效率已经挺高了。

锁主要存在四种状态，依次是：无锁状态、偏向锁状态、轻量级锁状态、重量级锁状态，他们会随着竞争的激烈而逐渐升级。（注意：锁可以升级不可降级，这种策略是为了提高获得锁和释放锁的效率）接下来，我们就详细就四种状态以及锁升级展开叙述。

2.1 偏向锁

在了解偏向锁之前我们先来了解一下对象头

2.1.1 对象头

synchronized用的锁是存在Java对象头里的。如果对象是数组类型，则虚拟机用3个字宽（Word）存储对象头，如果对象是非数组类型，则用2字宽存储对象头。在32位虚拟机中，1字宽等于4字节，即32bit，如表2-2所示：
在这里插入图片描述
Java对象头里的Mark Word里默认存储对象的HashCode、分代年龄和锁标记位。32位JVM的Mark Word的默认存储结构如表2-3所示：

在运行期间，Mark Word里存储的数据会随着锁标志位的变化而变化。Mark Word可能变化为存储以下4种数据，如表2-4所示：
在这里插入图片描述

在64位虚拟机下，Mark Word是64bit大小的，其存储结构如表2-5所示：
在这里插入图片描述

2.1.2 偏向锁

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

偏向锁的操作根本没有去找操作系统，每个对象都有对象头，下图示为account对象的“对象头”
在这里插入图片描述
JVM使用CAS操作把线程ID记录到了这个Mark Word当中，修改了标识位，当前线程就拥有这把锁了

可以看出：JVM不用和操作系统协商设置Mutex，它只记录下线程ID，就表示当前线程拥有这把锁了，不用操作系统介入。

这时线程获得了锁，可以执行synchronized修饰的代码块。

当线程再次执行到这个synchronized的时候，JVM通过锁对象account的Mark Word判断：“当前线程ID还在，还持有着这个对象的锁，就可以继续进入临界区执行。

这就是偏向锁，在没有别的线程竞争的时候，一直偏向当前线程，当前线程可以一直执行。

关于偏向锁的撤销，需要等待全局安全点，即在某个时间点上没有字节码正在执行时，它会先暂停拥有偏向锁的线程，然后判断锁对象是否处于被锁定状态。如果线程不处于活动状态，则将对象头设置成无锁状态，并撤销偏向锁，恢复到无锁（标志位为01）或轻量级锁（标志位为00）的状态。

偏向锁在 JDK 6 及之后版本的 JVM 里是默认启用的。可以通过 JVM 参数关闭偏向锁：-XX:-UseBiasedLocking=false，关闭之后程序默认会进入轻量级锁状态。

2.2 自旋锁（轻量级锁）

轻量级锁是由偏向所升级来的，偏向锁运行在一个线程进入同步块的情况下，当第二个线程加入锁争用的时候，偏向锁就会升级为轻量级锁

2.2.1 轻量级锁的加锁过程：

轻量级锁是指当锁是偏向锁的时候，却被另外的线程所访问，此时偏向锁就会升级为轻量级锁，其他线程会通过自旋（关于自旋的介绍见文末）的形式尝试获取锁，线程不会阻塞，从而提高性能。

轻量级锁的获取主要由两种情况：① 当关闭偏向锁功能时；② 由于多个线程竞争偏向锁导致偏向锁升级为轻量级锁。

在代码进入同步块的时候，如果同步对象锁状态为无锁状态（锁标志位为“01”状态，是否为偏向锁为“0”），虚拟机首先将在当前线程的栈帧中建立一个名为锁记录（Lock Record）的空间，用于存储锁对象目前的Mark Word的拷贝，官方称之为 Displaced Mark Word。

拷贝对象头中的Mark Word复制到锁记录中；

拷贝成功后，虚拟机将使用CAS操作尝试将对象的Mark Word更新为指向Lock Record的指针，并将Lock record里的owner指针指向object mark word。如果更新成功，则执行步骤4，否则执行步骤5。

如果这个更新动作成功了，那么这个线程就拥有了该对象的锁，并且对象Mark Word的锁标志位设置为“00”，即表示此对象处于轻量级锁定状态。

如果这个更新操作失败了，虚拟机首先会检查对象的Mark Word是否指向当前线程的栈帧，如果是就说明当前线程已经拥有了这个对象的锁，那就可以直接进入同步块继续执行。否则说明多个线程竞争锁，轻量级锁就要膨胀为重量级锁，锁标志的状态值变为“10”，Mark Word中存储的就是指向重量级锁（互斥量）的指针，后面等待锁的线程也要进入阻塞状态。而当前线程便尝试使用自旋来获取锁，自旋就是为了不让线程阻塞，而采用循环去获取锁的过程。
在这里插入图片描述

2.2.2 自旋

引入自旋这一规则的原因其实很简单：因为阻塞或唤醒一个 Java 线程需要操作系统切换 CPU 状态来完成，我们知道这种状态转换需要耗费处理器时间。所以让处理器继续执行一段简单代码消耗的时间可能反而比切换状态更短。并且在许多场景中，同步资源的锁定时间很短，为了这一小段时间去切换线程，这部分操作的开销其实是得不偿失的。

所以，在物理机器有多个处理器的情况下，当两个或以上的线程同时并行执行时，我们就可以让后面那个请求锁的线程不放弃 CPU 的执行时间，看看持有锁的线程是否很快就会释放锁。而为了让当前线程“稍等一下”，我们需让当前没拿到锁的线程进行自旋。如果在自旋完成后前面锁定同步资源的线程已经释放了锁，那么当前线程就可以不必阻塞而是直接获取同步资源，从而避免切换线程的开销。

自旋锁本身是有缺点的，它不能代替阻塞。自旋等待虽然避免了线程切换的开销，但它要占用处理器时间。如果锁被占用的时间很短，自旋等待的效果就会非常好。反之，如果锁被占用的时间很长，那么自旋的线程只会白浪费处理器资源。

所以，自旋等待的时间必须要有一定的限度，如果自旋超过了限定次数（默认是10次，可以使用 -XX:PreBlockSpin 来更改）没有成功获得锁，就应当挂起线程。

2.2.3 自适应自旋锁

自适应自旋锁在JDK6版本被引入，它意味着自旋的时间（次数）不再固定，而是由前一次在同一个锁上的自旋时间及锁的拥有者的状态来决定。如果在同一个锁对象上，自旋等待刚刚成功获得过锁，并且持有锁的线程正在运行中，那么虚拟机就会认为这次自旋也是很有可能再次成功，进而它将允许自旋等待持续相对更长的时间。如果对于某个锁，自旋很少成功获得过，那在以后尝试获取这个锁时将可能省略掉自旋过程，直接阻塞线程，避免浪费处理器资源。