深入理解synchronized底层源码，小白这篇足够了

忘是亡心i 2023-02-20 10:50 13阅读 0赞

### 深入理解synchronized底层源码 ###

### 前言 ###

这篇文章从JVM源码分析synchronized的实现逻辑，这样才能更加对synchronized深度的认识。

> 进程：操作系统资源分配的基本单位。线程：cpu调度的基本单位（真实执行）

### 阅读导航 ###

*   *   *  深入理解synchronized底层源码
         *  前言
         *  一、synchronized的使用场景
         *  二、JVM中，对象在内存中的布局
         *  三、synchronized底层从字节码聊起
         *  四、monitor到底是什么？
         *  五、深入synchronized底层源码
         *  六、锁的优化
         *   *  1、偏向锁
             *  2、偏向锁的获取
             *  3、撤销偏向锁
             *  4、轻量级锁
             *  5、轻量级锁加锁过程
             *  6、重量级锁状态

### 一、synchronized的使用场景 ###

synchronized一般使用在下面这几种场景：

1.  修饰代码块，指定一个加锁的对象，给对象加锁
    
        public Demo1{ 
           Object lock=new Object();
           public void test1(){ 
               synchronized(lock){ 
               }
           }
        }
2.  修饰静态方法，对当前类的Class对象加锁
    
        public class Demo2 { 
           //形式一
            public void test1(){ 
                synchronized(Synchronized.class){ 
                }
            }
          //形式二
            public void test2(){ 
                public synchronized static void test1(){ 
                }
            }
        }
3.  修饰普通方法，对当前实例对象this加锁
    
        public class Demo3 { 
            public synchronized void test1(){ 
            }
        }

### 二、JVM中，对象在内存中的布局 ###

synchronized实现的锁是存储在Java对象头。所以要对synchronized深入理解，首先了解一下**对象在内存中的布局怎样的？**

在 JVM 中，对象在内存中分为这么三块区域：**对象头(Header)、实例数据(Instance Data)、对齐填充(Padding)。**

1、对象头(Header)两个部分组成：**markOop或称为Mark Word和类元信息**

**Mark Word**：默认存储对象的HashCode，分代年龄和锁标志位信息。它会根据对象的状态复用自己的存储空间，也就是说在运行期间Mark Word里存储的数据会随着锁标志位的变化而变化。源码如下：

class markOopDesc: public oopDesc { 
     private:
      // Conversion
      uintptr_t value() const {  return (uintptr_t) this; }
     public:
      // Constants
      enum {  age_bits                 = 4,  //分代年龄
             lock_bits                = 2, //锁标识
             biased_lock_bits         = 1, //是否为偏向锁
             max_hash_bits            = BitsPerWord - age_bits - lock_bits - biased_lock_bits,
             hash_bits                = max_hash_bits > 31 ? 31 : max_hash_bits, //对象的hashcode
             cms_bits                 = LP64_ONLY(1) NOT_LP64(0),
             epoch_bits               = 2 //偏向锁的时间戳
      };

**类元信息**：对象指向它的类元数据的指针，虚拟机通过这个指针来确定这个对象是哪个类的实例。

2、实例数据：这部分主要是存放类的数据信息，父类的信息

3、对其填充

### 三、synchronized底层从字节码聊起 ###

首先，来看使用synchronized修饰的方法及方法块的小Demo案例，然后进行分析。由于synchronized的实现是在JVM层面的，我们要深入理解，那就是从字节码聊起了。

public class Demo03 { 
        public static void main( String[] args ){ 
            System.out.println( "hello Java" );
        }
        //synchronized修饰普通方法
        public synchronized void test1() {  }
    
        //修饰代码块
        public void test2() { 
            synchronized (this) { }
        }
    }

接下打开终端运行`javac Demo03.java`意思是将`Demo03.java`变成`Demo03.class`，然后再`javap -v Demo03.class`这样可以查看字节码了如下。

![format_png][]

大家观察上面字节码会发现

**synchronized同步方法时**：

> 如果修饰同步方法是通过的flag ACC\_SYNCHRONIZED来完成的，也就是说一旦执行到这个方法，就会先判断是否有标志位，然后ACC\_SYNCHRONIZED会去隐式调用刚才的两个指令：monitorenter和monitorexit。

**synchronized修饰同步代码块时**：

首先如果被synchronized修饰在方法块的话，是通过 monitorenter 和 monitorexit 这两个字节码指令获取线程的执行权的。当方法执行完毕退出以后或者出现异常的情况下会自动释放锁。

> 以上不管修饰哪一种：不管哪一种本质是对一个对象监视器(monitor)进行获取

在Java虚拟机执行到monitorenter指令时，1⃣️首先它会尝试获取对象的锁，如果该对象没有锁，或者当前线程已经拥有了这个对象的锁时，它会把计数器+1；然后当执行到monitorexit 指令时就会将计数器-1；然后当计数器为0时，锁就释放了。2⃣️如果获取锁 失败，那么当前线程就要阻塞等待，直到对象锁被另一个线程释放为止。

### 四、monitor到底是什么？ ###

monitor它就是个监视器，底层源码是C++编写的。在hotspot虚拟机中，它是采用ObjectMonitor类来实现monitor的源码如下：

bool has_monitor() const { 
        return ((value() & monitor_value) != 0);
      }
      ObjectMonitor* monitor() const { 
        assert(has_monitor(), "check");
        // Use xor instead of &~ to provide one extra tag-bit check.
        return (ObjectMonitor*) (value() ^ monitor_value);
      }

monitor实现在虚拟机的ObjectMonitor.hpp文件中的如下：

class ObjectMonitor { 
    ...
      ObjectMonitor() { 
        _header       = NULL; //markOop对象头
        _count        = 0;    
        _waiters      = 0,   //等待线程数
        _recursions   = 0;   //线程重入次数
        _object       = NULL;  //存储Monitor对象
        _owner        = NULL;  //获得ObjectMonitor对象的线程
        _WaitSet      = NULL;  //wait状态的线程列表
        _WaitSetLock  = 0 ; 
        _Responsible  = NULL ;
        _succ         = NULL ;
        _cxq          = NULL ;	// 单向列表
        FreeNext      = NULL ;
        _EntryList    = NULL ; //处于等待锁BLOCKED状态的线程
        _SpinFreq     = 0 ;   
        _SpinClock    = 0 ;
        OwnerIsThread = 0 ; 
        _previous_owner_tid = 0; //监视器前一个拥有线程的ID
      }
    ...

### 五、深入synchronized底层源码 ###

从 monitorenter和 monitorexit这两个指令来开始阅读源码，JVM将字节码加载到内存以后，会对这两个指令进行解释执行， monitorenter, monitorexit的指令解析是通过 InterpreterRuntime.cpp中的两个方法实现。

IRT_ENTRY_NO_ASYNC(void, InterpreterRuntime::monitorenter(JavaThread* thread, BasicObjectLock* elem))
    #ifdef ASSERT
      thread->last_frame().interpreter_frame_verify_monitor(elem);
    #endif
      if (PrintBiasedLockingStatistics) { 
        Atomic::inc(BiasedLocking::slow_path_entry_count_addr());
      }
      Handle h_obj(thread, elem->obj());
      assert(Universe::heap()->is_in_reserved_or_null(h_obj()),
             "must be NULL or an object");
      if (UseBiasedLocking) { 
        // Retry fast entry if bias is revoked to avoid unnecessary inflation
        ObjectSynchronizer::fast_enter(h_obj, elem->lock(), true, CHECK);
      } else { //绕过偏向锁，直接进入轻量级锁
        ObjectSynchronizer::slow_enter(h_obj, elem->lock(), CHECK);
      }
      assert(Universe::heap()->is_in_reserved_or_null(elem->obj()),
             "must be NULL or an object");
    #ifdef ASSERT
      thread->last_frame().interpreter_frame_verify_monitor(elem);
    #endif
    IRT_END
    
    
    //%note monitor_1
    IRT_ENTRY_NO_ASYNC(void, InterpreterRuntime::monitorexit(JavaThread* thread, BasicObjectLock* elem))
    #ifdef ASSERT
      thread->last_frame().interpreter_frame_verify_monitor(elem);
    #endif
      Handle h_obj(thread, elem->obj());
      assert(Universe::heap()->is_in_reserved_or_null(h_obj()),
             "must be NULL or an object");
      if (elem == NULL || h_obj()->is_unlocked()) { 
        THROW(vmSymbols::java_lang_IllegalMonitorStateException());
      }
      ObjectSynchronizer::slow_exit(h_obj(), elem->lock(), thread);
      // Free entry. This must be done here, since a pending exception might be installed on
      // exit. If it is not cleared, the exception handling code will try to unlock the monitor again.
      elem->set_obj(NULL);
    #ifdef ASSERT
      thread->last_frame().interpreter_frame_verify_monitor(elem);
    #endif
    IRT_END

注：

//JavaThread 当前获取锁的线程
    //BasicObjectLock 基础对象锁

**UseBiasedLocking是在JVM启动的时候，是否启动偏向锁的标识**  
1、如果支持偏向锁,则执行 ObjectSynchronizer::fast\_enter的逻辑

ObjectSynchronizer::fast\_enter实现在 synchronizer.cpp文件中，代码如下

void ObjectSynchronizer::fast_enter(Handle obj, BasicLock* lock, bool attempt_rebias, TRAPS) { 
     if (UseBiasedLocking) { //判断是否开启锁
        if (!SafepointSynchronize::is_at_safepoint()) { //如果不处于全局安全点
          //通过`revoke_and_rebias`这个函数尝试获取偏向锁
          BiasedLocking::Condition cond = BiasedLocking::revoke_and_rebias(obj, attempt_rebias, THREAD);
          if (cond == BiasedLocking::BIAS_REVOKED_AND_REBIASED) { //如果是撤销与重偏向直接返回
            return;
          }
        } else { //如果在安全点，撤销偏向锁
          assert(!attempt_rebias, "can not rebias toward VM thread");
          BiasedLocking::revoke_at_safepoint(obj);
        }
        assert(!obj->mark()->has_bias_pattern(), "biases should be revoked by now");
     }
    
     slow_enter (obj, lock, THREAD) ;
    }

小结：

*  再次检查偏向锁是否开启
 *  当处于不安全点时，通过 revoke\_and\_rebias尝试获取偏向锁，如果成功则直接返回，如果失败则进入轻量级锁获取过程
 *  revoke\_and\_rebias这个偏向锁的获取逻辑在 biasedLocking.cpp中
 *  如果偏向锁未开启，则进入 slow\_enter获取轻量级锁的流程

2、如果不支持偏向锁,则执行 ObjectSynchronizer::slow\_enter逻辑，绕过偏向锁，直接进入轻量级锁，该方法同样位于 synchronizer.cpp文件中

void ObjectSynchronizer::slow_enter(Handle obj, BasicLock* lock, TRAPS) { 
      markOop mark = obj->mark();
      assert(!mark->has_bias_pattern(), "should not see bias pattern here");
    
      if (mark->is_neutral()) { //如果当前是无锁状态, markword的
        //直接把mark保存到BasicLock对象的_displaced_header字段
        lock->set_displaced_header(mark);
        //通过CAS将mark word更新为指向BasicLock对象的指针，更新成功表示获得了轻量级锁
        if (mark == (markOop) Atomic::cmpxchg_ptr(lock, obj()->mark_addr(), mark)) { 
          TEVENT (slow_enter: release stacklock) ;
          return ;
        }
        // Fall through to inflate() ...
      } 
      //如果markword处于加锁状态、且markword中的ptr指针指向当前线程的栈帧，表示为重入操作，不需要争抢锁
      else
      if (mark->has_locker() && THREAD->is_lock_owned((address)mark->locker())) { 
        assert(lock != mark->locker(), "must not re-lock the same lock");
        assert(lock != (BasicLock*)obj->mark(), "don't relock with same BasicLock");
        lock->set_displaced_header(NULL);
        return;
      }
    
    #if 0
      // The following optimization isn't particularly useful.
      if (mark->has_monitor() && mark->monitor()->is_entered(THREAD)) { 
        lock->set_displaced_header (NULL) ;
        return ;
      }
    #endif
    	//代码执行到这里，说明有多个线程竞争轻量级锁，轻量级锁通过`inflate`进行膨胀升级为重量级锁
      lock->set_displaced_header(markOopDesc::unused_mark());
      ObjectSynchronizer::inflate(THREAD, obj())->enter(THREAD);
    }

### 六、锁的优化 ###

大家都知道JDK1.6之前，synchronized是一个重量级锁，效率比较低。所以官方在JDK1.6开始，为了减少获得锁和释放锁带来的性能消耗，对synchronized进行了优化，引入了 偏向锁和 轻量级锁的概念。

`无锁状态--->偏向锁状态--->轻量级锁状态--->重量级锁状态`四种状态，锁的状态会随着锁竞争的情况逐步升级，**且锁升级是不可逆的**。

#### 1、偏向锁 ####

偏向锁是指如果一个线程获得了一个偏向锁，如果在接下来的一段时间中没有其他线程来竞争锁，那么持有偏向锁的线程再次进入同步，**不需要再次进行抢占锁和释放锁的操作**。

该过程是采用CAS客观锁操作的，意思就是一个线程获取偏向锁时，如果没有其他线程来竞争锁，那么持有偏向锁的线程再次进入，虚拟机就不进行任何同步操作了，对标志位加1即可；如果不同线程来竞争锁，CAS会失败，这样获取锁就失败了 。

> JDK 1.5偏向锁是关闭的，开启参数xx:-UseBiasedLocking=false，JDK1.6后默认开启。

#### 2、偏向锁的获取 ####

当一个线程访问同步块获取锁时，会在对象头(Mark Word)和栈帧中的锁记录里存储偏向锁的线程ID，表示哪个线程获得了偏向锁。

**获取过程**：

1）首先根据锁的标志判断是不是处于偏向锁的状态

2）如果是偏向锁状态，就通过CAS操作将自己的线程ID写入到MarkWord，如果CAS操作成功，说明当前线程获取到偏向锁，然后就继续执行同步代码块。如果CAS失败，那就是意味着获取锁失败。

3）如果当前不是偏向锁，那它会去检测MarkWord中存储的线程ID和当前访问的线程的线程ID是否相等，如果相等，就说明当前线程已经是获取偏向锁，然后直接执行同步代码；如果不相等，说明当前偏向锁被其他线程获取，需要**撤销偏向锁**。

#### 3、撤销偏向锁 ####

获取偏向锁的线程才会释放偏向锁，撤销偏向锁的过程需要等待一个**全局安全点（也就是等待获取偏向锁的线程都停止字节码执行）**。

撤销偏向锁的过程：

1）首先，判断获取偏向锁的线程否为存活状态

2）如果线程已存亡，那就直接把Mark Word设置为无锁状态

3）如果线程还存活，当达到全局安全点时，获取的偏向锁的线程会被挂起，然后接着偏向锁升级为轻量级锁，最后唤醒被阻塞在全局安全点的线程继续往下执行同步代码

#### 4、轻量级锁 ####

当多个线程竞争偏向锁时，会发生偏向锁的撤销，偏向锁撤销无非两种状态：

1）没有获取偏向锁的无锁状态

2）没有获取偏向锁的有锁状态

#### 5、轻量级锁加锁过程 ####

1）如果这个对象是无锁的，JVM就会在当前线程的栈帧创建用于存储锁记录的空间(LockRecord)，用来将对象头中的Mark Word复制到锁记录中的

2）然后JVM采用CAS将对象头中的Mark Word替换为指向锁记录的指针

3）替换成功，说明当前线程获得轻量级锁；替换失败，说明存在其他线程竞争锁。那么当前线程会尝试使用CAS来获取锁，当自旋超过指定次数(可以自定义)时仍然无法获得锁，此时锁会膨胀**升级为重量级锁**

> 自旋，防止线程被挂起，一旦可以获取资源，就直接尝试成功，如果超出阈值，还没有获取锁，那么升级为重量级锁。（自旋锁默认是10次，-XX：PreBlockSpin可以修改）

#### 6、重量级锁状态 ####

一旦锁升级为重量级锁，就不会再恢复到轻量级锁状态。当锁处于重量级锁状态，其他线程尝试获取锁时，都会被阻塞，也就是 BLOCKED状态。当持有锁的线程释放锁之后会唤醒这些现场，被唤醒之后的线程会进行新一轮的竞争。

参考资料

敖 丙：[死磕synchronized底层实现][synchronized]

架构师修炼宝典：\[(五)Synchronized原理分析\](

[format_png]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly9zdGF0aWMwMS5pbWdrci5jb20vdGVtcC8xN2I4ZTY4Y2U3N2E0Y2Q3OTNjNDAzZDc3ZDM0MmMzNy5wbmc?x-oss-process=image/format,png
[synchronized]: https://segmentfault.com/a/1190000022668048