JUC并发编程第十一章——Synchronized与锁升级机制

原创

已于 2024-10-29 21:54:56 修改

· 置顶 · 1.3k 阅读

22 ·

版权

文章标签：

#java #开发语言

于 2024-06-12 17:48:33 首次发布

1 入门知识介绍

synchronized锁，是不是默认实现了锁升级。代码中只需要直接使用synchronized，至于怎么从偏向锁升级为轻量锁再升级为重量级锁，这些底层jvm已经实现了。不需要程序员担心。

是的，Java 8中的synchronized关键字确实默认实现了锁升级的机制。当使用synchronized关键字时，JVM会自动管理锁的状态，根据竞争情况从偏向锁开始，逐步升级到轻量级锁，最终升级到重量级锁。这一过程是由JVM内部实现的，不需要程序员手动干预。

锁升级的过程如下：

偏向锁（Biased Locking）：在没有竞争的情况下，JVM使用偏向锁来减少锁操作的开销。当一个线程第一次获取到锁时，该锁会偏向这个线程，后续这个线程再次访问这个同步块时，不需要任何同步操作，因为锁已经被该线程偏向了。

轻量级锁（Lightweight Locking）：如果有另一个线程尝试获取这个锁，JVM会将偏向锁撤销，并升级为轻量级锁。轻量级锁通过在栈帧中存储锁记录（Lock Record）的方式来实现，线程通过CAS（比较并交换）操作尝试将锁的Mark Word更新为指向自己的锁记录的指针，以此来获取锁。

重量级锁（Heavyweight Locking）：如果锁竞争加剧，轻量级锁的自旋操作不能及时成功获取锁，JVM会将轻量级锁膨胀为重量级锁。此时，线程会被阻塞，直到拥有锁的线程释放锁后，操作系统才会唤醒等待的线程。

这种锁升级的机制是JVM为了提高同步性能而设计的，它能够在没有竞争或竞争不激烈的情况下，减少同步操作的开销，而在竞争激烈时又能确保同步的正确性。

因此，作为Java程序员，你只需要在代码中使用synchronized关键字来同步代码块或方法，而无需关心锁的具体状态和升级过程。JVM会自动处理这些细节，以优化程序的性能。

1.1 面试题

谈谈你对Synchronized的理解
请你聊聊Synchronized的锁升级

1.2 本章路线总纲

1.2.1 锁使用的强制要求

【强制】高并发时，同步调用应该去考量锁的性能损耗，能用无锁数据结构，就不要用锁；能锁区块，就不要锁整个方法体；能用对象锁，就不要用类锁。

说明：尽可能使加锁的代码块工作量尽可能的小，避免在锁代码块中调用RPC方法。

synchronized锁优化的背景

用锁能够实现数据的安全性，但是会带来性能下降。

无锁能够基于现成并行提升程序性能，但是会带来安全性下降

那么如何求平衡？
锁的升级过程

无锁-偏向锁-轻量级锁-重量级锁(锁的范围一点一点变大，还是上面那句话，尽可能锁的范围小)

1.2.2 synchronized锁：由对象头重的Mark Word根据锁标志位的不同而被复用及锁升级策略

在这里插入图片描述

2 Synchronized的性能变化

java5以前，只有Synchronized，这个是操作系统级别的重量级操作

重量级锁，假如锁的竞争比较激烈的话，性能下降

Java5之前，用户态和内核态之间的切换

(我们写一个new Thread().start()的话是调用了底层的native方法的）

java的线程是映射到操作系统原生线程之上的，如果要阻塞或唤醒一个线程就需要操作系统介入，需要在用户态与核心态之间切换，这种切换会消耗大量的系统资源，因为用户态与内核态都有各自专用的内存空间，专用的寄存器等，用户态切换至内核态需要传递给许多变量、参数给内核，内核也需要保护好用户态在切换时的一些寄存器值、变量等，以便内核态调用结束后切换回用户态继续工作。
在Java早期版本中，synchronized属于重量级锁，效率低下，因为监视器锁（monitor）是依赖于底层的操作系统的Mutex Lock(系统互斥量)来实现的，挂起线程和恢复线程都需要转入内核态去完成，阻塞或唤醒一个Java线程需要操作系统切换CPU状态来完成，这种状态切换需要耗费处理器时间，如果同步代码块中内容过于简单，这种切换的时间可能比用户代码执行的时间还长”，时间成本相对较高，这也是为什么早期的synchronized效率低的原因Java 6之后，为了减少获得锁和释放锁所带来的性能消耗，引入了轻量级锁和偏向锁

（一句话就是尽量减少用户态和内核态的切换）

为什么每一个对象都可以成为一个锁-复习之前的知识

markOop.hpp

我们大概可以知道，每个对象都有一个ObjectMonitor，而每个ObjectMonitor都可以成为锁。

小结：我们说在java中每个对象都可以成为一把锁，因为在JVM中每个对象都一个monitor(监视器锁。对应到C底层叫做Object Monitor，并用c定义了很多信息。再往下到操作系统中是基于Mutex Lock互斥锁实现，涉及到了用户态和内核态的切换，所以非常耗费资源。

结合之前的synchronized和对象头说明

主要就是MarkWord中是什么代码表示了它是什么锁状态

从图中可以看出，如果当前锁对象是重量级锁，它底层还会有ObjectMonitor，保存了很多锁的相关信息。

3 Synchronized锁种类及升级步骤

3.1 多线程访问情况

只有一个线程来访问，有且唯一Only One
有两个线程（2个线程交替访问）
竞争激烈，更多线程来访问

不同线程访问情况，有着不同锁解决问题。

3.2 升级流程

Synchronized用的锁是存在Java对象头里的MarkWord中，锁升级功能主要依赖MarkWord中锁标志位和释放偏向锁标志位

重点关注【偏向锁位】和【锁标志位】

锁指向总结，请牢记

偏向锁：MarkWord存储的是偏向的线程ID；
轻量锁：MarkWord存储的是指向线程栈中Lock Record的指针；
重量锁：MarkWord存储的是指向堆中的monitor对象的指针；

3.3 无锁

复习C源码的MarkWord标记

我们知道，一个对象只是创建出来，它是无锁状态的。无锁状态的MarkWord标记占8字节，也就是64位。其中：25位是没有使用的 (unused)，31位存放了hashcode (hash)，1位未使用，4位是分代年龄 (age 4位二进制最大就是1111，十进制就是15，因此分代年龄最大15)，1位偏向锁位 (biased lock)，2位锁标识位 (normal lock)。25 + 31 + 1 + 4 + 1 + 2 = 64位(8字节)

Code1

import org.openjdk.jol.info.ClassLayout;

public class SynchronizedUpDemo {

    public static void main(String[] args) {
        Object o = new Object();
        System.out.println(ClassLayout.parseInstance(o).toPrintable());
    }

}

输出结果：
java.lang.Object object internals:
 OFFSET  SIZE   TYPE DESCRIPTION                               VALUE
      0     4        (object header)                           01 00 00 00 (00000001 00000000 00000000 00000000) (1)
      4     4        (object header)                           00 00 00 00 (00000000 00000000 00000000 00000000) (0)
      8     4        (object header)                           e5 01 00 f8 (11100101 00000001 00000000 11111000) (-134217243)
     12     4        (loss due to the next object alignment)
Instance size: 16 bytes
Space losses: 0 bytes internal + 4 bytes external = 4 bytes total

提出疑问

以上Code1就是new一个对象，对应64位对象标记图的无锁态！

hashCode对应的是哪31位，为什么都是0？
前8个字节（64位）的对象标记应该正着看还是倒着看？

Code2

import org.openjdk.jol.info.ClassLayout;

public class SynchronizedUpDemo {

    public static void main(String[] args) {
        Object o = new Object();

        System.out.println("10进制：" + o.hashCode());
        System.out.println("16进制：" +

最低0.47元/天解锁文章