Java Synchronized的偏向锁详细分析

目录
  • 理论知识
  • 源码论证
  • 总结

上篇文章已经对Synchronized关键字做了初步的介绍,从字节码层面介绍了Synchronized关键字,最终字节码层面就是monitorenter和monitorexit字节码指令。并且拿Synchronized关键字和Java的JUC包下的ReentrantLock做了比较。Synchronized关键字的初体验-超链接地址

那么本篇文章将开始深入解析Synchronized关键字的底层原理,也就是解析Hotspot虚拟机对monitorenter和monitorexit字节码指令的实现原理。

理论知识

相信各位读者在准备面试中,都会背到关于Synchronized关键字的面试题,什么对象头、锁标志位、偏向锁、轻量级锁、重量级锁,锁升级的过程等等面试题。而对于一些不仅仅只想漂浮于表面的读者来说,去看Synchronized底层源码,只能说是一头雾水。所以笔者有考虑这方面,所以理论知识(给临时抱佛脚背理论的读者)和底层源码(给喜欢研究底层源码的读者)都会在这个系列中。

偏向锁存在的意义:

先从字面意思来解释,偏向于某个线程,是不是可以理解为偏向的这个线程获取锁都很效率呢?那么为什么要存在偏向锁呢?读者需要明白,任何框架存在的意义不仅仅是为了某一部分场景,肯定需要适配大部分场景,而Synchronized关键字使用的场景可能并发高,可能并发低,可能几乎不存在并发,所以实现者需要帮用户去适配不同的场景,达到效率最高化。而对于几乎不存在并发的场景,是不是可以理解为几乎只有一个线程拿到Synchronized锁,所以就存在偏向锁去优化这种场景,不让所有场景都去走很复杂的逻辑。

偏向锁实现的流程:

  • 拿到锁竞争对象
  • 从当前线程栈中获取到一个没有使用的BasicObjectLock(用于记录锁状态)
  • 查看当前是否开启了偏向锁模式
  • 查看当前偏向锁是否偏向的是当前线程,如果偏向的是当前线程,直接退出(可以理解成命中缓存)
  • 查看当前是否已经锁升级了,并且尝试撤销偏向锁(想象一下并发过程中,可能其他线程已经完成了锁对象的锁升级)
  • 当前epoch是否发生了改变,如果发生了改变,当前线程可以尝试获取偏向锁,尝试成功直接退出
  • 当前是否是匿名偏向,或者已经偏向于某个线程,但是不是当前线程,此时可以尝试获取锁,获取成功直接退出
  • 如果不支持偏向锁或者第5步的撤销偏向锁失败了,此时尝试膨胀成轻量级锁,如果轻量级锁膨胀失败了就继续往上锁膨胀

流程图如下(仅只有偏向锁逻辑)

源码论证

首先,我们先需要知道Synchronized底层源码的入口在哪里,在字节码层面表示为monitorenter和monitorexit字节码指令,而我们知道JVM是负责执行字节码,最终转换成不同CPU平台的ISA指令集(也称之为跨平台)。而JVM执行字节码分为

  • CPP解释执行
  • 模板解释执行(汇编)
  • JIT编译执行

一级一级的优化,而最根本是CPP解释执行,后者都是基于CPP解释执行的不断优化,后者的难度极大,所以读者弄明白CPP解释执行就即可。

在Hotspot源码中,CPP解释执行的入口在bytecodeInterpreter.cpp文件(这里要注意,JDK1.8不同版本对synchronized关键字实现有区别,所以本文选的是jdk8u40版本,其他版本可能没有偏向锁等等逻辑)

首先,读者明白,使用Synchronized关键字时需要一个锁对象,而底层就是操作这个锁对象的对象头,所以我们先从markOop.hpp文件中找到对象头的描述信息,是不是跟外面8股文描述的一模一样呢

对象头熟悉以后,源码中就是操作对象头,不同的锁状态设置不同对象头,用对象头来表示不同的锁状态,替换对象头的原子性依靠CAS来保证。如果存在并发,那么CAS竞争失败的线程就会往下走,一步一步的锁升级,反而如果没有竞争那就默认使用偏向锁。

下面是Hotspot中C++解释器对于monitorenter字节码指令的解释执行源码(注释特别详细)。

CASE(_monitorenter): {
        // 拿到锁对象
        oop lockee = STACK_OBJECT(-1);
        // derefing's lockee ought to provoke implicit null check
        CHECK_NULL(lockee);
        // find a free monitor or one already allocated for this object
        // if we find a matching object then we need a new monitor
        // since this is recursive enter
        // 从当前线程栈中找到一个没有被使用的BasicObjectLock
        // 作用:用来记录锁状态
        BasicObjectLock* limit = istate->monitor_base();
        BasicObjectLock* most_recent = (BasicObjectLock*) istate->stack_base();
        BasicObjectLock* entry = NULL;
        while (most_recent != limit ) {
          if (most_recent->obj() == NULL) entry = most_recent;
          else if (most_recent->obj() == lockee) break;
          most_recent++;
        }
        if (entry != NULL) {
          // 抢坑,为什么这里不需要CAS,因为属于线程栈(线程变量),线程安全。
          entry->set_obj(lockee);
          int success = false;
          // 得到epoch的掩码。
          uintptr_t epoch_mask_in_place = (uintptr_t)markOopDesc::epoch_mask_in_place;
          // 得到当前锁对象的对象头。
          markOop mark = lockee->mark();
          intptr_t hash = (intptr_t) markOopDesc::no_hash;
          // implies UseBiasedLocking
          // 当前是偏向锁模式,可以用JVM参数UseBiasedLocking控制
          if (mark->has_bias_pattern()) {
            uintptr_t thread_ident;
            uintptr_t anticipated_bias_locking_value;
            thread_ident = (uintptr_t)istate->thread();
            // lockee->klass()->prototype_header() 是否拿到对象的类模板的头部信息。
            // lockee->klass()->prototype_header() | thread_ident) 是类模板头部信息组合上线程id
            // mark 是当前锁对象的头部信息。
            // markOopDesc::age_mask_in_place 是当前对象的年龄信息。
            // 所以与年龄无关
            // 所以拿锁对象的原型对象的对象头控制
            // lockee->klass()->prototype_header() | thread_ident) ^ (uintptr_t)mark 如果为0 代表当前对象头偏向锁偏向了当前线程
            anticipated_bias_locking_value =
              (((uintptr_t)lockee->klass()->prototype_header() | thread_ident) ^ (uintptr_t)mark) &
              ~((uintptr_t) markOopDesc::age_mask_in_place);
            // 等于0代表当前锁对象头部和类模板头部一样。
            // 所以这是一次偏向锁的命中。
            if  (anticipated_bias_locking_value == 0) {
              // already biased towards this thread, nothing to do
              if (PrintBiasedLockingStatistics) {
                (* BiasedLocking::biased_lock_entry_count_addr())++;
              }
              success = true;
            }
            // 当前对象头已经膨胀成轻量级或者重量级锁了。也即非偏向锁。
            else if ((anticipated_bias_locking_value & markOopDesc::biased_lock_mask_in_place) != 0) {
              // try revoke bias
              // 尝试撤销偏向锁
              markOop header = lockee->klass()->prototype_header();
              if (hash != markOopDesc::no_hash) {
                header = header->copy_set_hash(hash);
              }
              // CAS尝试取消偏向
              if (Atomic::cmpxchg_ptr(header, lockee->mark_addr(), mark) == mark) {
                if (PrintBiasedLockingStatistics)
                  (*BiasedLocking::revoked_lock_entry_count_addr())++;
              }
            }
            // 来到这里可能表示当前偏向于其他线程。
            // 而epoch发生了变动,表示批量撤销偏向锁了。
            // 当前线程可以尝试争抢一次偏向锁,没有成功就去锁升级
            else if ((anticipated_bias_locking_value & epoch_mask_in_place) !=0) {
              // try rebias
              // 尝试重偏向
              markOop new_header = (markOop) ( (intptr_t) lockee->klass()->prototype_header() | thread_ident);
              if (hash != markOopDesc::no_hash) {
                new_header = new_header->copy_set_hash(hash);
              }
              // CAS竞争,重偏向。
              if (Atomic::cmpxchg_ptr((void*)new_header, lockee->mark_addr(), mark) == mark) {
                if (PrintBiasedLockingStatistics)
                  (* BiasedLocking::rebiased_lock_entry_count_addr())++;
              }
              // CAS失败,锁升级
              else {
                  // 锁升级逻辑
                CALL_VM(InterpreterRuntime::monitorenter(THREAD, entry), handle_exception);
              }
              success = true;
            }
            // 来到这里表示,当前是匿名偏向锁(也即暂时还没有线程占用)
            // 或者是已经偏向了某个线程,所以这里CAS尝试一次
            else {
              // try to bias towards thread in case object is anonymously biased
              markOop header = (markOop) ((uintptr_t) mark & ((uintptr_t)markOopDesc::biased_lock_mask_in_place |
                                                              (uintptr_t)markOopDesc::age_mask_in_place |
                                                              epoch_mask_in_place));
              if (hash != markOopDesc::no_hash) {
                header = header->copy_set_hash(hash);
              }
              markOop new_header = (markOop) ((uintptr_t) header | thread_ident);
              // debugging hint
              DEBUG_ONLY(entry->lock()->set_displaced_header((markOop) (uintptr_t) 0xdeaddead);)
              // 如果是匿名偏向,这个CAS就有可能成功
              // 如果是已经偏向其他线程,这个CAS不能成功,直接往锁升级走
              if (Atomic::cmpxchg_ptr((void*)new_header, lockee->mark_addr(), header) == header) {
                if (PrintBiasedLockingStatistics)
                  (* BiasedLocking::anonymously_biased_lock_entry_count_addr())++;
              }
              // cas失败
              else {
                  // 锁升级逻辑
                CALL_VM(InterpreterRuntime::monitorenter(THREAD, entry), handle_exception);
              }
              success = true;
            }
          }
          // traditional lightweight locking
          // case1:如果当前已经锁升级了
          // case2:如果当前不支持偏向锁
          if (!success) {
            markOop displaced = lockee->mark()->set_unlocked();
            entry->lock()->set_displaced_header(displaced);
            bool call_vm = UseHeavyMonitors;
            // UseHeavyMonitors是JVM参数,是否直接开启重量级锁
            // 如果不直接开启,就CAS竞争轻量级锁,竞争成功就直接返回
            if (call_vm || Atomic::cmpxchg_ptr(entry, lockee->mark_addr(), displaced) != displaced) {
              // Is it simple recursive case?
              // CAS失败可能是锁重入,如果不是锁重入,那么就是竞争失败要往锁升级逻辑走了。
              if (!call_vm && THREAD->is_lock_owned((address) displaced->clear_lock_bits())) {
                  // 轻量级锁的锁重入
                entry->lock()->set_displaced_header(NULL);
              } else {
                  // 锁升级逻辑
                CALL_VM(InterpreterRuntime::monitorenter(THREAD, entry), handle_exception);
              }
            }
          }
          UPDATE_PC_AND_TOS_AND_CONTINUE(1, -1);
        } else {
          istate->set_msg(more_monitors);
          UPDATE_PC_AND_RETURN(0); // Re-execute
        }
      }

要明白偏向锁对应的对象头的几个部分的意义,然后带入到源码中就比较容易理解。

  • 线程对象:偏向于那个线程(当没有线程对象时,就代表是匿名偏向,此时线程都可以去竞争)
  • epoch:是否发生了批量锁撤销(为什么要锁撤销?因为偏向锁升级为轻量级锁就需要撤销)
  • 偏向锁标志位:0表示无锁,1表示偏向锁(偏向锁和无锁的锁标志位都是01)
  • 锁标志位:表示不同锁状态,偏向锁表示为01(要注意无锁也是表示为01,所以需要额外的偏向锁标志位来区分是无锁还是偏向锁)

总结

可能源码部分一直是一个难点,操作的内容太多了,并且还是C++实现的。但是从对象头的角度去分析理解还是很有帮助。

到此这篇关于Java Synchronized的偏向锁详细分析的文章就介绍到这了,更多相关Java Synchronized偏向锁内容请搜索我们以前的文章或继续浏览下面的相关文章希望大家以后多多支持我们!

(0)

相关推荐

  • Java synchronized偏向锁的核心原理详解

    目录 1.偏向锁的核心原理 2.偏向锁的撤销 3.偏向锁的膨胀 4.偏向锁的好处 总结 1. 偏向锁的核心原理 轻量级锁在没有竞争时(就自己这个线程),每次重入仍然需要执行 CAS 操作. Java 6 中引入了偏向锁来做进一步优化:只有第一次使用 CAS 将线程 ID 设置到对象的 Mark Word 头,之后发现 这个线程 ID 是自己的就表示没有竞争,不用重新 CAS.以后只要不发生竞争,这个对象就归该线程所有. public class Main { static final Objec

  • Java synchronized偏向锁的概念与使用

    目录 一.什么是偏向锁 二.偏向锁原理 三.偏向锁演示 四.偏向锁的处理流程 五.偏向锁的撤销 六.偏向锁的好处 一.什么是偏向锁 HotSpot作者经过研究实践发现,在大多数情况下,锁不仅不存在多线程竞争,而且总是由同一线程多次获得,为了让线程获得锁的代价更低,引进了偏向锁. 偏向锁的“偏”,它的意思是锁会偏向于第一个获得它的线程,会在对象头(Mark Word中)存储锁偏向的线程ID,以后该线程进入和退出同步块时只需要检查是否为偏向锁.锁标志位以及ThreadID即可. 如下图是偏向锁对象头

  • Java面试synchronized偏向锁后hashcode存址

    目录 前言 1.hashcode是啥时候存进对象头中? 2.存在hashcode后,出现synchronized会是什么锁? 3.如果锁状态是 已偏向,再计算hashcode会怎样? 4.总结 前言 今天的文章从下面这张图片开始,这张图片Java开发们应该很熟悉了 我们都知道无锁状态是对象头是有位置存储hashcode的,而变为偏向锁状态是没有位置存储hashcode的,今天我们来通过实现验证这个问题:当锁状态为偏向锁的时候,hashcode存到哪里去了? 先说结论: jdk8偏向锁是默认开启,

  • Java CopyOnWriteArrayList源码超详细分析

    目录 一.概述 二.类图 三.核心方法 1.add() 2.set() 3.remove() 4.get() 5.size() 四.总结 一.概述 CopyOnWriteArrayList是基于写时复制技术实现的,适用于读多写少场景下的线程安全的并发容器.读操作永远不会加锁,读读.读写都不会冲突,只有写写需要等待.写操作时,为了不影响其它线程的读取,它会进行一次自我复制,待数据写入完成后再替换array数组.array数组是被volatile修饰的,它被修改后可以被其他线程立刻发现. publi

  • Java getRealPath("/")与getContextPath()区别详细分析

    一.以下是在servlet中测试的. 二.运行结果如下(其中myfile文件夹是不存在的). 三.总结. 1.getRealPath("/")方法返回的是项目在服务器的绝对路径,而getRealPath("WEB-INF/myfile")返回的是包含一个给定虚拟路径的绝对路径,其中/myfile是虚拟的. 2.getContextPath()方法返回的是项目相对路径,并不会返回其绝对的路径,就是说并不知道项目在哪个位置. 到此这篇关于Java getRealPath

  • Java 栈与队列超详细分析讲解

    目录 一.栈(Stack) 1.什么是栈? 2.栈的常见方法 3.自己实现一个栈(底层用一个数组实现) 二.队列(Queue) 1.什么是队列? 2.队列的常见方法 3.队列的实现(单链表实现) 4.循环队列 一.栈(Stack) 1.什么是栈? 栈其实就是一种数据结构 - 先进后出(先入栈的数据后出来,最先入栈的数据会被压入栈底) 什么是java虚拟机栈? java虚拟机栈只是JVM当中的一块内存,该内存一般用来存放 例如:局部变量当调用函数时,我们会为函数开辟一块内存,叫做 栈帧,在 jav

  • java集合 ArrayDeque源码详细分析

    问题 (1)什么是双端队列? (2)ArrayDeque是怎么实现双端队列的? (3)ArrayDeque是线程安全的吗? (4)ArrayDeque是有界的吗? 简介 双端队列是一种特殊的队列,它的两端都可以进出元素,故而得名双端队列. ArrayDeque是一种以数组方式实现的双端队列,它是非线程安全的. 继承体系 通过继承体系可以看,ArrayDeque实现了Deque接口,Deque接口继承自Queue接口,它是对Queue的一种增强. public interface Deque<E>

  • 从汇编代码开始全面解析synchronized还原最真实的偏向锁

    目录 前言 一.TemplateTable::monitorenter() 二.lock_object(): 三.biased_locking_enter() 1).参数 2).概念 3).源码 前言 我们都知道java之所以跨平台能力强,是因为java在编译期没有被编译成机器码,而是被编译成字节码.早期的jvm会将编译好的字节码翻译成机器码解释执行,我们在jvm的源码中还可以看到早期的解释器——bytecodeInterpreter.cpp(虽然已经不再使用).对于字节码这种总数固定,解释逻辑

  • JAVA对象分析之偏向锁、轻量级锁、重量级锁升级过程

    在HotSpot虚拟机里,对象在堆内存中的存储布局可以划分为三个部分: 对象头(Header) 实例数据(Instance Data) 对齐填充(Padding). 对象头 HotSpot虚拟机(后面没有说明的话默认是这个虚拟机)对象头包括三部分: Mark Word 指向类的指针 数组长度(只有数组对象才有) 对象头之Mark Word Mark Word记录了对象和锁有关的信息,当这个对象被synchronized关键字当成同步锁时,围绕这个锁的一系列操作都和Mark Word有关. Mar

  • java synchronized 锁机制原理详解

    目录 前言: 1.synchronized 的作用: 2.synchronized 底层语义原理: 3. synchronized 的显式同步与隐式同步: 3.1.synchronized 代码块底层原理: 3.2.synchronized 方法底层原理: 4.JVM 对 synchronized 锁的优化: 4.1.锁升级:偏向锁->轻量级锁->自旋锁->重量级锁 4.1.1.synchronized 的 Mark word 标志位: 4.1.2.锁升级过程: 4.2.锁消除: 4.3

  • 基于Java 生产者消费者模式(详细分析)

    生产者消费者模式是多线程中最为常见的模式:生产者线程(一个或多个)生成面包放进篮子里(集合或数组),同时,消费者线程(一个或多个)从篮子里(集合或数组)取出面包消耗.虽然它们任务不同,但处理的资源是相同的,这体现的是一种线程间通信方式. 本文将先说明单生产者单消费者的情况,之后再说明多生产者多消费者模式的情况.还会分别使用wait()/nofity()/nofityAll()机制.lock()/unlock()机制实现这两种模式. 在开始介绍模式之前,先解释下wait().notify()和no

随机推荐