12、锁-java对象头与锁优化与GC

爱欧米

已于 2022-12-12 00:22:19 修改

阅读量503

点赞数

分类专栏： # Java # JVM 文章标签： java 开发语言

于 2022-11-13 09:56:26 首次发布

本文链接：https://blog.csdn.net/god8816/article/details/127827172

版权

Java 同时被 2 个专栏收录

16 篇文章 1 订阅

订阅专栏

JVM

10 篇文章 2 订阅

订阅专栏

一、对象头结构

HotSpot虚拟机中，对象在内存中存储的布局可以分为三块区域：对象头（Header）、实例数据（Instance Data）和对齐填充（Padding）。

二、对象头结构理论

HotSpot虚拟机的对象头包括三部分信息。Mark Word、Klass Word（指向类的指针）、数组长度。比如在64位的系统，对象头前62位表示GC信息，后2位表示锁信息。

1、Mark Word

Mark Word记录了对象和锁有关的信息，当这个对象被synchronized关键字当成同步锁时，围绕这个锁的一系列操作都和Mark Word有关。Mark Word在32位JVM中的长度是32bit，在64位JVM中长度是64bit。Mark Word在不同的锁状态下存储的内容不同，在32位JVM中是这么存的：

锁状态	25bit		4bit	1bit	2bit
锁状态	23bit	2bit	4bit	是否偏向锁	锁标志位
无锁	对象的HashCode		分代年龄	0	01
偏向锁	线程ID	Epoch	分代年龄	1	01
轻量级锁	指向栈中锁记录的指针				00
重量级锁	指向重量级锁的指针				10
GC标记	空				11

其中无锁和偏向锁的锁标志位都是01，只是在前面的1bit区分了这是无锁状态还是偏向锁状态。

JDK1.6以后的版本在处理同步锁时存在锁升级的概念，JVM对于同步锁的处理是从偏向锁开始的，随着竞争越来越激烈，处理方式从偏向锁升级到轻量级锁，最终升级到重量级锁。

1、JVM如何使用锁和Mark Word

锁升级过程：无锁-偏向锁-轻量级锁-自旋锁-重量级锁

当没有被当成锁时，这就是一个普通的对象，Mark Word记录对象的HashCode，锁标志位是01，是否偏向锁那一位是0。
当对象被当做同步锁并有一个线程A抢到了锁时，锁标志位还是01，但是否偏向锁那一位改成1，前23bit记录抢到锁的线程id，表示进入偏向锁状态。
当线程A再次试图来获得锁时，JVM发现同步锁对象的标志位是01，是否偏向锁是1，也就是偏向状态，Mark Word中记录的线程id就是线程A自己的id，表示线程A已经获得了这个偏向锁，可以执行同步锁的代码。
当线程B试图获得这个锁时，JVM发现同步锁处于偏向状态，但是Mark Word中的线程id记录的不是B，那么线程B会先用CAS操作试图获得锁，这里的获得锁操作是有可能成功的，因为线程A一般不会自动释放偏向锁。如果抢锁成功，就把Mark Word里的线程id改为线程B的id，代表线程B获得了这个偏向锁，可以执行同步锁代码。如果抢锁失败，则继续执行步骤5。
偏向锁状态抢锁失败，代表当前锁有一定的竞争，偏向锁将升级为轻量级锁。JVM会在当前线程的线程栈中开辟一块单独的空间，里面保存指向对象锁Mark Word的指针，同时在对象锁Mark Word中保存指向这片空间的指针。上述两个保存操作都是CAS操作，如果保存成功，代表线程抢到了同步锁，就把Mark Word中的锁标志位改成00，可以执行同步锁代码。如果保存失败，表示抢锁失败，竞争太激烈，继续执行步骤6。
轻量级锁抢锁失败，JVM会使用自旋锁，自旋锁不是一个锁状态，只是代表不断的重试，尝试抢锁。从JDK1.7开始，自旋锁默认启用，自旋次数由JVM决定。如果抢锁成功则执行同步锁代码，如果失败则继续执行步骤7。
自旋锁重试之后如果抢锁依然失败，同步锁会升级至重量级锁，锁标志位改为10。在这个状态下，未抢到锁的线程都会被阻塞。

2、64位系统指针压缩

现在我们虚拟机基本是64位的，而64位的对象头有点浪费空间，JVM默认会开启指针压缩，所以基本上也是按32位的形式记录对象头的。手动设置jvm启动参数为：-XX:+UseCompressedOops

对象的全局静态变量（即类属性）
对象头信息：64位平台下，原生对象头大小为16字节，压缩后为12字节
对象的引/用类型：64位平台下，引|用类型本身大小为8字节，压缩后为4字节
对象数组类型：64位平台下，数组类型本身大小为24字节，压缩后16字节

2、Klass Word

该指针在32位JVM中的长度是32bit，在64位JVM中长度是64bit。Java对象的类数据保存在方法区。

3、数组长度

只有数组对象才有，在32位或者64位JVM中，长度都是32bit。

三、实例数据

存放类的属性数据信息，包括父类的属性信息；

四、对齐填充

由于虚拟机要求对象起始地址必须是8字节的整数倍。填充数据不是必须存在的，仅仅是为了字节对齐。原因是为了寻址最优，64位机器正好8个字节；

五、打印对象结构

Java利用ClassLayout查看对象头。需要引入jol-core包。

1、mark word对照表

2、引入jol-core包

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

3、代码生成对象头

public class JolTest {

    public static void main(String[] args) {
        Object dog = new Object();
        System.out.println("初始信息:"+ClassLayout.parseInstance(dog).toPrintable());
        System.out.println(dog.hashCode());
        System.out.println("hashcode信息:"+ClassLayout.parseInstance(dog).toPrintable());
        synchronized (dog) {
            System.out.println("加锁后信息:"+ClassLayout.parseInstance(dog).toPrintable());
        }
        System.out.println("释放锁后信息:"+ClassLayout.parseInstance(dog).toPrintable());
    }
}

六、什么是Monitor

1、Monitor介绍

Monitor可以理解为一种同步工具，也可理解为一种同步机制，常常被描述为一个Java对象，也叫管程。 管程（Monitor）是一种和信号量（Sophomore）等价的同步机制。它在Java并发编程中也非常重要，虽然程序员没有直接接触管程，但它确实是synchronized和wait()/notify()等线程同步和线程间协作工具的基石。当我们在使用这些工具时，其实是它在背后提供了支持。简单来说：管程使用锁（lock）确保了在任何情况下管程中只有一个活跃的线程，即确保线程互斥访问临界区管程使用条件变量（Condition Variable）提供的等待队列（Waiting Set）实现线程间协作，当线程暂时不能获得所需资源时，进入队列等待，当线程可以获得所需资源时，从等待队列中唤醒。

2、Monitor特征

互斥：一个Monitor在一个时刻只能被一个线程持有，即Monitor中的所有方法都是互斥的。
Signal机制：如果条件变量不满足，允许一个正在持有Monitor的线程暂时释放持有权，当条件变量满足时，当前线程可以唤醒正在等待该条件变量的线程，然后重新获取Monitor的持有权。
所有的Java对象是天生的Monitor。每一个Java对象都有成为Monitor的潜质，因为在Java的设计中，每一个Java对象自打娘胎里出来就带了一把看不见的锁，它叫做内部锁或者Monitor锁。
Monitor的本质是依赖于底层操作系统的Mutex Lock实现。操作系统实现线程之间的切换需要从用户态到内核态的转换，成本非常高。
Monitor 是线程私有的数据结构。每一个线程都有一个可用monitor record列表，同时还有一个全局的可用列表。每一个被锁住的对象都会和一个monitor关联（对象头的MarkWord中的LockWord指向monitor的起始地址），同时monitor中有一个Owner字段存放拥有该锁的线程的唯一标识，表示该锁被这个线程占用。其结构如下：

Owner字段：初始时为NULL表示当前没有任何线程拥有该monitor record，当线程成功拥有该锁后保存线程唯一标识，当锁被释放时又设置为NULL
EntryQ字段：关联一个系统互斥锁（semaphore），阻塞所有试图锁住monitor record失败的线程
RcThis字段：表示blocked或waiting在该monitor record上的所有线程的个数
Nest字段：用来实现重入锁的计数
HashCode字段：保存从对象头拷贝过来的HashCode值（可能还包含GC age）
Candidate字段：用来避免不必要的阻塞或等待线程唤醒，因为每一次只有一个线程能够成功拥有锁，如果每次前一个释放锁的线程唤醒所有正在阻塞或等待的线程，会引起不必要的上下文切换（从阻塞到就绪然后因为竞争锁失败又被阻塞）从而导致性能严重下降；Candidate只有两种可能的值0表示没有需要唤醒的线程1表示要唤醒一个继任线程来竞争锁

3、Monitor具体实现方式

Monitor是在jvm底层实现的，底层代码是c++
Monitor的enter方法：获取锁
Monitor的exit方法：释放锁
Monitor的wait方法：为java的Object的wait方法提供支持
Monitor的notify方法：为java的Object的notify方法提供支持
Monitor的notifyAll方法：为java的Object的notifyAll方法提供支持

4、Monitor实现机制

如下图：

Monitor可以类比为一个特殊的房间，这个房间中有一些被保护的数据，Monitor保证每次只能有一个线程能进入这个房间进行访问被保护的数据，进入房间即为持有Monitor，退出房间即为释放Monitor。

当一个线程需要访问受保护的数据（即需要获取对象的Monitor）时，它会首先在entry-set入口队列中排队（这里并不是真正的按照排队顺序），如果没有其他线程正在持有对象的Monitor，那么它会和entry-set队列和wait-set队列中的被唤醒的其他线程进行竞争（即通过CPU调度），选出一个线程来获取对象的Monitor，执行受保护的代码段，执行完毕后释放Monitor，如果已经有线程持有对象的Monitor，那么需要等待其释放Monitor后再进行竞争。

再说一下wait-set队列。当一个线程拥有Monitor后，经过某些条件的判断（比如用户取钱发现账户没钱），这个时候需要调用Object的wait方法，线程就释放了Monitor，进入wait-set队列，等待Object的notify方法（比如用户向账户里面存钱）。当该对象调用了notify方法或者notifyAll方法后，wait-set中的线程就会被唤醒，然后在wait-set队列中被唤醒的线程和entry-set队列中的线程一起通过CPU调度来竞争对象的Monitor，最终只有一个线程能获取对象的Monitor。

注意：

当一个线程在wait-set中被唤醒后，并不一定会立刻获取Monitor，它需要和其他线程去竞争，如果一个线程是从wait-set队列中唤醒后，获取到的Monitor，它会去读取它自己保存的PC计数器中的地址，从它调用wait方法的地方开始执行。

5、Monitor与java对象以及线程是如何关联

1、如果一个java对象被某个线程锁住，则该java对象的Mark Word字段中LockWord指向monitor的起始地址

2、Monitor的Owner字段会存放拥有相关联对象锁的线程id

七、Mutex Lock 与 Lock Cmpxchg

1、Mutex Lock

sysnchronized背后依赖的锁。Mutex(又叫 Lock),在多线程中,作为同步的基本类型,用来保证没有两个线程或进程同时在他们的关键区域.因为 Mutex 这种排它性,很多人认为 Mutex 开销很大,尽量避免使用它.就如这篇分析完共享数据问题后,进一步分析说明 Avoiding locks 来解决这个问题.但 Mutex 真的开销如此大,还是被大家误解了?Matthew Dillon 写道,”Most people have the misconception that locks are slow.”, Jeff Preshing 也写了这篇”Locks Aren’t Slow; Lock Contention Is”.

那么接下来做 3 个关于 Mutex 的 Benchmark,具体分析一下 Mutex 的开销如何,最后并利用原子操作和 semaphore 实现一个 lightweight Mutex. 一个 Mutex 仅仅从 Lock 到 Unlock 具体开销是多少,是不是占用很多时间,从 Always Use a Lightweight Mutex 从可以看到在 windows 中有两种 Mutex:Muetx 和 Critical Section, 重量级和轻量级的区别,两者的时间开销相差 25 倍多,所以一直使用轻量级的 Mutex。

这篇文章在高强度下 lock 的性能:每个线程做任何事情都占用 lock(高冲突),lock 占用极短的时间 (高频率).值得一读,但是在实际应用中,基本避免如此使用 locks.这里对 Mutex Contention 和 Mutex Frequency 都做最好和最坏场景的使用测试. Mutex 被灌以避免使用也因为其他原因.现在有很多大家熟知的 lock-free programming 技术.Lock-free 编程非常具有挑战性,但在实际场景中获得巨大的性能.既然有 lock-free 的技术吸引我们使用它们,那么 locks 就显得索然无味了.但也不能因此忽略 lock.因为在实际很多场景,它仍然是利器.

2、Lock Cmpxchg

Cas背后依赖的锁。如下代码，程序会根据当前处理器的类型来决定是否为cmpxchg指令添加lock前缀。如果程序是在多处理器上运行，就为cmpxchg指令加上lock前缀（Lock Cmpxchg）。反之，如果程序是在单处理器上运行，就省略lock前缀（单处理器自身会维护单处理器内的顺序一致
性，不需要lock前缀提供的内存屏障效果）。

inline jint Atomic::cmpxchg (jint exchange_value, volatile jint* dest, jint compare_value) {
 // alternative for InterlockedCompareExchange 
 int mp = os::is_MP(); 
  __asm { 
  mov edx, 
  dest mov ecx, 
  exchange_value mov eax, 
  compare_value LOCK_IF_MP(mp) 
  cmpxchg dword ptr [edx], ecx 
  } 
 }

八、锁升级过程

synchronized锁有无锁、偏向锁、轻量级锁和重量级锁4种状态，在对象头的Mark Word里有展示，锁状态不同，Mark Word的结构也不同。

1、无锁

很好理解，就是不存在竞争，线程没有获取synchronized锁的状态。

2、偏向锁

即偏向第一个拿到锁的线程，锁会在对象头的Mark Word通过CAS（Compare And Swap）记录获得锁的线程id，同时将Mark Word里的锁状态置为偏向锁，是否为偏向锁的位也置为1，当下一次还是这个线程获取锁时就不需要通过CAS。
如果其他的线程尝试通过CAS获取锁（即想将对象头的Mark Word中的线程ID改成自己的）会获取失败，此时锁由偏向锁升级为轻量级锁。

3、轻量级锁

JVM会给线程的栈帧中创建一个锁记录（Lock Record）的空间，将对象头的Mark Word拷贝到Lock Record中，并尝试通过CAS把原对象头的Mark Word中指向锁记录的指针指向当前线程中的锁记录，如果成功，表示线程拿到了锁。如果失败，则进行自旋（自旋锁），自旋超过一定次数时升级为重量级锁，这时该线程会被内核挂起。

4、自旋锁

轻量级锁升级为重量级锁之前，线程执行monitorenter指令进入Monitor对象的EntryList队列，此时会通过自旋尝试获得锁，如果自旋次数超过了一定阈值（默认10），才会升级为重量级锁，等待线程被唤起。
线程等待唤起的过程涉及到Linux系统用户态和内核态的切换，这个过程是很消耗资源的，自选锁的引入正是为了解决这个问题，先不让线程立马进入阻塞状态，而是先给个机会自旋等待一下。

5、重量级锁

在2中已经介绍，就是通常说的synchronized重量级锁。

6、锁升级过程

锁升级的顺序为：无锁 -> 偏向锁 -> 轻量级锁 -> 重量级锁，且锁升级的顺序是不可逆的。
线程第一次获取锁获时锁的状态为偏向锁，如果下次还是这个线程获取锁，则锁的状态不变，否则会升级为CAS轻量级锁；如果还有线程竞争获取锁，如果线程获取到了轻量级锁没啥事了，如果没获取到会自旋，自旋期间获取到了锁没啥事，超过了10次还没获取到锁，锁就升级为重量级的锁，此时如果其他线程没获取到重量级锁，就会被阻塞等待唤起，此时效率就低了。