垃圾回收算法与实现系列-锁在Java虚拟机中的实现和优化

古城微笑少年丶 2022-10-11 03:58 183阅读 0赞

导语
  上篇分享中提到了对象头Mark Word 的基本概念之后,接下来就可以深入到虚拟机内部了。在多线程程序中,线程之间的竞争是不可避免的,并且这是一种多线程程序的常态。那么如何高效的处理多线程的竞争,是JVM的一项关键优化点,如果将所有的线程处理都交给操作系统,那么整体的处理效率比较低。所以,JVM在进入操作系统处理之前,首先就需要做好前期的准备工作,这样尽可能的避免真实场景的竞争发生。下面就来看看JVM对于锁的优化等问题。

锁机制在JVM中的实现和优化

偏向锁

  偏向锁是JDK1.6 中提出的一种锁的优化方式。核心思想是,如果程序没有竞争,则取消之前已经取得锁的线程同步操作。也就是说,某个锁被线程获取之后,就会进入偏向模式,当线程再次请求这个锁的时候,不需要在进行相关的同步操作,从而节省了操作的时间,如果在此期间有其他的线程进行锁请求,则退出偏向模式。在JVM中使用-XX:+UseBiasedLocking 可以设置启用偏向锁。

  1. -XX:+UseBiasedLocking

  当锁处于偏向模式的时候,对象头会记录获取锁的线程

  1. [JavaThread* |epoch|age|1|01]

  这样,当该线程再次尝试获得锁时,通过Mark Word的线程信息就可以判断当掐你线程是否持有偏向锁。

  1. public class Biased{
  2. public static List<Integer> numberList = new Vector<Integer>();
  3. public static void main(String[] args) throws InterruptedException{
  4. long begin = System.currentTimeMillis();
  5. int count = 0;
  6. int startnum = 0;
  7. while(count<100000000){
  8. numberList.add(startnum);
  9. startnum+=2;
  10. count++;
  11. }
  12. long end = System.currentTimeMillis();
  13. System.out.println(end-begin);
  14. }
  15. }

  上述代码使用一个线程对Vector进行写入操作,由于对Vector的访问内部都用同步锁控制,每次add()操作都会请求numberList对象的锁,使用以下参数执行这段程序:

  1. -XX:+UseBiasedLocking -XX:BiasedLockingStartupDelay=0 -client -Xmx512m -Xms512m

  程序输出结果如下

  1. 394

  上述结果表示程序使用394毫秒完成所有的工作。参数中的-XX:BiasedLockingStartupDelay表示虚拟机在启动之后立即使用偏向锁。如果不设置该参数,虚拟机默认会在启动后的4秒才会启用偏向锁,考虑到程序运行时间较短,故做此设置,尽早启用偏向锁。

  如果禁用偏向锁,则只需要使用如下参数启动程序:

  1. -XX:-UseBiasedLocking -client -Xmx512m -Xms512m

  程序输出结果如下

  1. 539

  可以看到,偏向锁在竞争较少的情况下,对系统性能有很大的帮助。

  偏向锁在锁竞争激烈的场合没有太强的优化效果,因为大量的竞争会导致持有锁的线程不停地切换,锁也很难一直保持在偏向模式。此时使用锁偏向不仅得不到性能优化,反而是降低了系统性能。因此,在竞争激烈的场合,可以尝试使用-XX:UseBiasedLocking 参数禁用偏向锁。

轻量级锁

  如果偏向锁失败,JVM会让线程申请轻量级锁。轻量级锁在JVM内部使用了一个被称为BasicObjectLock的对象实现,这个对象内部由一个BasicLock对象和一个持有该锁的Java对象指针组成。BasicObjectLock 对象放置在Java栈的栈帧中。在BasicLock对象内部还维护着displaced_header字段,它用于备份对象头部的Mark Word。
  当一个线程持有一个对象的锁的时候,对象头部Mark Word 如下

  1. [ptr |00] locked

  末尾两位00,整个Mark Word 为指向BasicLock对象指针。由于BasicObjectLock对象在线程栈中,该指针必然指向持有该锁的线程栈空间。当需要判断某一线程是否持有该对象锁的时候,只需要判断对象头的指针是否在当前线程的栈地址范围内。同时,BasicLock 对象的displaced_header字段备份了原对象的Mark Word 内容,BasicObjectLock 对象的obj 字段则指向该对象。

  在JVM中,轻量级锁的代码实现可读性比较好。首先BasicLock 通过set_displaced_header() 方法备份了原对象的Mark Word。接着,通过CAS操作,尝试将BasicLock的地址复制到对象头的Mark Word。如果复制成功,那么加锁成功,否则加锁失败。如果加锁失败,那么轻量级锁就有可能膨胀为重量级锁。如图所示
在这里插入图片描述

锁膨胀

  当轻量级锁失败,虚拟机就会使用重量级锁。在使用重量级锁时,对象的Mark Word如下

  1. [ptr |10] monitor

  末尾的2个比特位被设置成10。整个Mark Word 表示指向monitor对象的指针。在轻量级锁处理失败之后,JVM会执行如下的操作

  1. lock->set_displaced_header(markOopDesc::unused_mark());
  2. ObjectSynchroizer::inflate(THREAD,obj())->enter(THREAD)

  第一步是废弃前面BasicLock备份的对象头信息。第二步则正式启用重量级锁。启用过程分为两步:首先通过inflate()方法进行锁膨胀,其目的是获得对象的ObjectMonitor;然后使用enter()方法尝试进入该锁。
  在调用enter()方法时,线程很可能会在操作系统层面被挂起,此时线程间切换和调度的成本就会比较高。

自旋锁

  在上面提到,锁膨胀之后,进入ObjectMonitor 的enter()方法,线程很可能会在操作系统层面被挂起,这样线程上下文切换的性能损失就比较大。在锁膨胀之后,JVM会做最后的争取,希望线程可以尽快进入临界区从而避免被操作系统挂起。解决这种问题比较有效的手段就是使用自旋锁。

  自旋锁可以使得线程在没有取得锁的之后不被挂起,去执行一个空循环,也就是所谓的自旋,在若干个空循环后,线程如果可以获得锁,则继续执行。若线程依然不能获得锁,才会被挂起。

  在使用自旋锁之后,线程被挂起的概率相对减小,线程执行的连贯性相对加强。因此,对于那些锁竞争不是很强烈的锁占用时间很短的并发线程,具有很积极的效果,但对锁竞争激烈、单线程占用时间长的并发程序,自旋锁在自旋等待之后,往往依然是没有办法获取到对应的锁,白白的浪费了CPU时间,最终还会导致线程不被挂起,从而消耗了很多的资源。

  JDK1.6中,JVM提供-XX:+UseSpinning参数来开启自旋锁,使用-XX:PreBlockSpin参数来设置自旋锁的等待次数。
  JDK1.7后的版本,自旋锁的参数被取消,JVM不再支持由用户配置自旋锁。自旋锁总是被执行,但是自旋的次数由虚拟机自己来决定。

锁消除

  锁消除是JVM在JIT编译的时候,通过对运行上下文的扫描,去除不可能存在共享资源竞争的锁,通过锁的消除,可以节省无意义的锁的请求时间。

  这里需要说明一点,既然没有产生锁,为什么还要加锁?在Java应用程序开发过程中,必然会涉及到一些JDK内置的API,例如StringBuffer、Vector等,一些常用的工具类可能被大量使用,虽然这些工具类本身可能有对应的非线程安全版本,但是再开发过程中,可能在没有多线程的场合下使用了这种工具类。

  在这种情况下工具类内部的同步方法就是不必要的,虚拟机可以在运行时,基于逃逸分析技术,捕获一些不可能存在竞争却有申请锁的代码段,并取消一些不必要的锁。从而提高系统性能

  逃逸分析和锁消除的参数分别是 -XX:+DoEscapeAnalysis和-XX:+EliminateLocks 开启。

发表评论

表情:
评论列表 (有 0 条评论,183人围观)

还没有评论,来说两句吧...

相关阅读

    相关 Java虚拟垃圾回收收集算法

    一、概述 Java虚拟机的内存区域中,程序计数器、虚拟机栈和本地方法栈三个区域是线程私有的,随线程生而生,随线程灭而灭;栈中的栈帧随着方法的进入和退出而进行入栈和出栈操作,