【JUC】10. synchronized与锁升级

逃离我推掉我的手 2024-04-01 10:02 84阅读 0赞

#### 文章目录 ####

*  1. 锁升级过程
 *   *  1.1 无锁
     *  1.2 偏向锁
     *   *  1.2.1 偏向锁的撤销
     *  1.3 轻量级锁
     *  1.4 重量级锁
 *  2. 锁关系之hashcode关系
 *  3. 总结
 *  4. 锁清除
 *  5. 锁粗化

## 1. 锁升级过程 ##

为什么会出现锁升级呢？

**是因为synchronized虽然能实现数据的安全性，但是带来的却是性能下降**

**无锁虽然能基于并行提升程序性能，但是带来的是安全性下降**

这中间需要求个平衡

![在这里插入图片描述][7579244e22ba4ca69a07bcc07e27d12b.png_pic_center]

**通过锁的升级，可以使得效率和安全性实现平衡**

**换句话说，比如手机掉了颗螺丝，我们可以自己拧上，完全没必要返厂维修。**

**所以对于并发情况并不需要一开始就加重量级锁**

在Java5以前，只有synchronized，也就是无论大并发还是小并发，都得使用synchronized重量级锁

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

但是在Java6开始，synchronized被优化

多线程访问情况分为以下三种

*  只有一个线程来访问，有且唯一
 *  有多个线程(2个线程A、B来交替访问)
 *  竞争激烈，更多线程来访问

**那么锁升级流程是怎么样的呢？**

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

![在这里插入图片描述][c0baaab93f3f45ec976294acf7242392.png_pic_center]

不同的锁MarkWord存储的内容是不一样的

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

--------------------

### 1.1 无锁 ###

在无锁状态中，MarkWord中存储的是

*  未使用(25位)
 *  哈希值(31位)(如果有使用的话)
 *  未使用(1位)
 *  分带年龄(4位)

引入依赖

<dependency>
        <groupId>org.projectlombok</groupId>
        <artifactId>lombok</artifactId>
        <version>1.18.24</version>
    </dependency>

通过这个工具类可以查看JVM的大小和分布

public class SynchronizedDemo {
        
        public static void main(String[] args) {
        
            Object o = new Object();
            System.out.println(ClassLayout.parseInstance(o).toPrintable());
    
            System.out.println("=============================================");
    
            System.out.println("10进制：" + o.hashCode());
            System.out.println("16进制:" + Integer.toHexString(o.hashCode()));
            System.out.println("2进制:" + Integer.toBinaryString(o.hashCode()));
            //1101010101010001100111010110110
            //01101010101010001100111010110110
            System.out.println(ClassLayout.parseInstance(o).toPrintable());
        }
    }

![在这里插入图片描述][b0f000bbc2074ef39e6d09aaf3a69ab1.png_pic_center]

对于每一行，从右往左读，每一行的一个小块从左往右读，就可以拼出哈希值一样的了

![在这里插入图片描述][a2c775544c7a4fc3adcc4fd480264602.png_pic_center]

--------------------

### 1.2 偏向锁 ###

偏向锁是什么？

> 当线程A第一次竞争到锁时，通过操作修改MarkWord钟偏向线程ID、偏向模式。
> 
> 如果不存在其他线程竞争的画，那么持有偏向锁的线程将永远不再需要同步
> 
> **也就是说，当一段同步代码一直被同一个线程多次访问，由于只有一个线程那么线程在后续访问时便会自动获得锁**

通过卖票案例感受偏向锁

public class SaleTicketDemo {
        
        public static void main(String[] args) {
        
            Ticket ticket = new Ticket();
    
            new Thread(() -> {
        
                for (int i = 0; i < 55; i++) {
        
                    ticket.sale();
                }
            }, "A").start();
    
            new Thread(() -> {
        
                for (int i = 0; i < 55; i++) {
        
                    ticket.sale();
                }
            }, "B").start();
    
            new Thread(() -> {
        
                for (int i = 0; i < 55; i++) {
        
                    ticket.sale();
                }
            }, "C").start();
        }
    }
    
    class Ticket {
        
        int number = 50;
    
        Object lockObject = new Object();
    
        public void sale(){
        
            synchronized (lockObject){
        
                if (number > 0){
        
                    System.out.println(Thread.currentThread().getName() + "卖出第：" + (number--) + "\t还剩下：" + number);
                }else {
        
                    System.out.println(Thread.currentThread().getName() + "买不到，因为卖完了");
                }
            }
        }
    }

![在这里插入图片描述][19c062a0028547ecbb1e5083cb5cd49f.png_pic_center]

一开始A线程抢夺到线程资源，那么A线程在后续访问时便会自动获得锁，所以A线程更容易争抢到资源

**也就是说，多线程的情况下，锁不仅不存在多线程竞争，还存在锁由一个线程获得的情况，偏向锁就是在这种情况下出现的，它的出现就是为了解决只有在一个线程执行同时提高性能**

**偏向锁会偏向于第一个访问锁的线程，如果在接下来的运行过程，该锁没有被其他的线程访问，则持有偏向锁的线程将永远不需要触发同步。也即偏向锁在资源没有竞争情况下消除了同步语句，懒的连CAS操作都不做了，直接提高程序性能**

在实际应用运行过程中发现，“锁总是同一个线程持有，很少发生竞争”，**也就是说锁总是被第一个占用他的线程拥有，这个线程就是锁的偏向线程**  
那么只需要在锁第一次被拥有的时候，记录下偏向线程ID。这样偏向线程就一直持有着锁(后续这个线程进入和退出这段加了同步锁的代码块时，不需要再次加锁和释放锁。而是直接会去检查锁的MarkWord里面是不是放的自己的线程ID)。  
如果相等，表示偏向锁是偏向于当前线程的，就不需要再尝试获得锁了，直到竞争发生才释放锁。以后每次同步，检查锁的偏向线程 D与当前线程ID是否一致，如果一致直接进入同步。无需每次加锁解锁都去CAS更新对象头。**如果自始至终使用销的线程只有一个**，很明显偏向锁几乎没有额外开销，性能极高。  
如果不等，表示发生了竞争，锁已经不是总是偏向干同一个线程了，这个时候会尝试使用CAS来替换MarkWord里面的线程ID为新线程的ID，  
\*\*竞争成功，\*\*表示之前的线程不存在了，MarkWord里面的线程ID为新线程的ID，锁不会升级，仍然为偏向锁。  
\*\*竞争失败，\*\*这时候可能需要升级变为轻量级锁，才能保证线程间公平竞争锁。  
**注意，偏向锁只有遇到其他线程尝试竞争偏向锁时，持有偏向锁的线程才会释放锁，线程是不会主动释放偏向锁的。**  
**技术实现:**  
一个svnchronized方法被一个线程抢到了锁时，那这个方法所在的对象就会在其所在的MarkWord中将偏向锁修改状态位，同时还会占用前54位来存储线程指针作为标识。**若该线程再访问同一个synchronized方法时，该线程只需去对象头的MarkWord中去判断一下是否由偏向锁指向本身的id，武训在进入Monitor去竞争对象了**

![在这里插入图片描述][e32ab15832e14c1d8c22f45276c748d8.png_pic_center]

> 偏向锁的操作不用直接捅到操作系统，不涉及用户到内核转换，不必要直接升级为最高级
> 
> ![在这里插入图片描述][37089a23c97d4ac7981ae91ca60711be.png_pic_center]

> 假如有一个线程执行到synchronized代码块的时候，**JVM使用CAS操作把线程指针ID记录到Mark Word当中**，并修改标偏向标示，标示当前线程就获得该锁。锁对象变成偏向锁(通过CAS修改对象头里的锁标志位)，字面意思是“偏向于第一个获得它的线程”的锁。执行完同步代码块后，线程并不会主动释放偏向锁。
> 
> ![在这里插入图片描述][a7b506344b87485198a6ec432224d580.png_pic_center]

> 这时线程获得了锁，可以执行同步代码块。当该线程第二次到达同步代码块时会判断此时持有锁的线程是否还是自己(持有锁的线程ID也在对象头里)，JVM通过account对象的MarkWord判断:当前线程ID还在，说明还持有着这个不象的锁，就可以继续进入临界区工作。由于之前没有释放锁，这里也就不需要重新加锁\*\*。 如果自始至终使用锁的线程只有一个，很明显偏向锁几乎没有额外开销，性能极高\*\*。结论:JVM不用和操作系统协商设置Mutex(争取内核)，它只需要记录下线程ID就标示自己获得了当前锁，不用操作系统接入。上述就是偏向锁:在没有其他线程竞争的时候，一直偏向偏心当前线程，当前线程可以一直执行。

偏向锁在JDK1.6之后是默认开启的，但是启动时间有延迟

需要添加参数–XX:BiasedLockingStartupDelay=0，让其程序启动时立即启动

*  当有另外线程来竞争锁的时候，就不能使用偏向锁了，要升级为轻量级锁
 *  竞争线程尝试CAS更新对象头失败，会等待到全局安全点撤销偏向锁

#### 1.2.1 偏向锁的撤销 ####

偏向锁使用一种等到竞争出现才释放锁的机制，只有当其他线程竞争锁时，持有偏向锁的原来线程才会被撤销。撤销需要等待全局安全点(该时间点上没有字节码正在执行)，同时检查持有偏向锁的线程是否还在执行:

*  第一个线程正在执行synchronized方法(处于同步块)，它还没有执行完，其它线程来抢夺，该偏向锁会被取消掉并出现锁升级。此时轻量级锁由原持有偏向锁的线程持有，继续执行其同步代码，而正在竞争的线程会进入自旋等待获得该轻量级锁。
 *  第一个线程执行完成synchronized方法(退出同步块)，则将对象头设置成无锁状态并撤销偏向锁，重新偏向。

![在这里插入图片描述][e4c30ef5aa9141edb728647046fcbabc.png_pic_center]

> 在2020年，jdk15废除偏向锁

--------------------

### 1.3 轻量级锁 ###

什么是轻量级锁？

多线程竞争，但是任意时刻最多只有一个线程竞争，即不存在锁竞争太过激烈的情况，也就没有线程阻塞

轻量级锁的获取  
轻量级锁是为了在线程近乎交替执行同步块时提高性能。  
主要目的：在没有多线程竞争的前提下，通过CAS减少重量级锁使用操作系统互斥量产生的性能消耗，说白了先自旋， 不行才升级阻塞。  
升级时机：当关闭偏向锁功能或多线程竞争偏向锁会导致偏向锁升级为轻量级锁

假如线程A已经拿到销，这时线程B又来抢该对象的锁，由于该对象的锁已经被线程A拿到，当前该锁已是偏向锁了。  
而线程B在争抢时发现对象头Mark Word中的线程ID不是线程B自己的线程ID(而是线程A)，那线程B就会进行CAS操作希望能获得锁。  
此时线程B操作中有两种情况:  
如果锁获取成功，百接替换MarkWord中的线程ID为B自己的ID(A→B)，重新偏向千其他线程(即将偏向销交给其他线程，相当干当前线程"被"释放了锁)，该锁会保持偏向锁状态，A线程Over，B线程上位:

![在这里插入图片描述][5456a82d07c6460ea2fbf3c11eb64d85.png_pic_center]

如果锁获取失败，则偏向锁升级为轻量级锁(设置偏向锁标识为0并设置锁标志位为00)，此时轻量级锁由原持有偏向锁的线程持有，继续执行其同步代码，而正在竞争的线程B会进入自旋等待获得该轻量级锁。

![在这里插入图片描述][968745159aa84d2884ae4a2dfacdf6bc.png_pic_center]

轻量级锁的加锁  
JVM会为每个线程在当前线程的栈帧中创建用于存储锁记录的空间，官方成为Displaced Mark Word。若一个线程获得锁时发现是轻最级锁，会把锁的MarkWord复制到自己的DisplacedrMark Word里面。然后线程尝试用CAS将锁的MarkWord替换为指向销记录的指针。如果成功，当前线程获得锁，如果失败，表示Mark Word已经被替换成了其他线程的锁记录，说明在与其它线程竞争锁，当前线程就尝试使用自旋来获取锁。

自旋CAS:不断尝试去获取锁，能不升级就不往上捅，尽量不要阻塞

轻量级锁的释放  
在释放锁时，当前线程会使用CAS操作将Displaced Mark Word的内容复制回锁的MarkWord里面。如果没有发生竞争，那么这个复制的操作会成功。如果有其他线程因为自旋多次导致轻量级锁升级成了重量级锁，那么CAS操作会失败，此时会释放锁并唤醒被阻塞的线程。

--------------------

### 1.4 重量级锁 ###

Java中synchronized的重量级锁，是基于进入和退出Monitor对象实现的。在编译时会将同步块的开始位置插入monitor enter指令，在结束位置插入monitor exit指令。  
当线程执行到monitor enter指令时，会尝试获取对象所对应的Monitor所有权，如果获取到了，即获取到了锁，会在Monitor的owner中存放当前线程的id，这样它将处于锁定状态，除非退出同步块，否则其他线程无法获取到这个Monitor。

--------------------

## 2. 锁关系之hashcode关系 ##

锁升级为轻量级或重量级锁后，MarkWord中保存的分别是线程栈帧里的锁记录指针和重量级指针，已经没有位置再保存哈希码、GC年龄，那么这些信息会移动到哪里呢？

*  在无锁状态下，Mark Word中可以存储对象的identity hashcode值。当对象的hashCode()方法第一次被调用时，JVM会生成对应的 identity hash code值并将该值存储到Mark Word中。
 *  对于偏向锁，在线程获取偏向锁时，会用ThreadID和epoch值覆盖identityhash code所在的位置。如果一个对象的hashCode()方法已经被调用过一次之后，这个对象不能被设置偏向锁。因为如果可以的化，那Mark Word中的identityhashcode必然会被偏向线程 ld给覆盖，这就会造成同一个对象前后两次调用hashCode()方法得到的结果不一致。
 *  升级为轻量级锁时，JVM会在当前线程的栈帧中创建一个锁记录(Lock Record)空间，用于存储锁对象的Mark Word拷贝，该拷贝中可以包含identity hash code，所以轻量级锁可以和identitv hash code共存，哈希码和GC年龄自然保存在此，释放锁后会将这些信息写回到对象头。

/**
     * @Author: lrk
     * @Date: 2022/10/23 下午 9:52
     * @Description:
     */
    public class SynchronizedUpDemo {
        
        public static void main(String[] args) {
        
            try {
        
                TimeUnit.SECONDS.sleep(5);
            } catch (InterruptedException e) {
        
                throw new RuntimeException(e);
            }
            Object o = new Object();
            synchronized (o){
        
                System.out.println(ClassLayout.parseInstance(o).toPrintable());
                //没有重写，一致性哈希，重写无效
                o.hashCode();
                System.out.println("偏向锁过程中遇到一致性哈希计算请求，立马撤销偏向模式，膨胀为重量级锁");
                System.out.println(ClassLayout.parseInstance(o).toPrintable());
            }
        }
    }

![在这里插入图片描述][e7e02a0721214548891bf165ab85f747.png_pic_center]

--------------------

## 3. 总结 ##

![在这里插入图片描述][74c288c86d29455fbc63d7ca980d68c5.png_pic_center]

*  synchronized锁升级过程总结:一句话，就是先自旋，不行再阻塞。  
    实际上是把之前的悲观锁(重量级锁)变成在一定条件下使用偏向锁以及使用轻量级(自旋锁CAS)的形式
 *  synchronized在修饰方法和代码块在字节码上实现方式有很大差异，但是内部实现还是基于对象头的MarkWord来实现的。
 *  JDK1.6之前synchronized使用的是重量级锁，JDK1.6之后进行了优化，拥有了无锁->偏向锁->轻量级锁->重量级锁的升级过程，而不是无论什么情况都使用重量级锁。

--------------------

## 4. 锁清除 ##

public class LockClearUp{
        
        static Object objectLock = new Object();
    
        public void m1(){
        
            Object o = new Object();
            synchronized (o){
        
                System.out.println("---hello" + "\t" + o.hashCode() + "\t" + objectLock.hashCode());
            }
        }
    
        public static void main(String[] args) {
        
            LockClearUp lockClearUp = new LockClearUp();
            for (int i = 0; i < 10; i++) {
        
                new Thread(() -> {
        
                    lockClearUp.m1();
                }, String.valueOf(i)).start();
            }
        }
    }

![在这里插入图片描述][1db758d1c01049ca94dff006613599fa.png_pic_center]

在这种情况下，每次执行这个方法就会new一个Object，因此每个线程访问的时候都是不同的object对象锁，因此这种锁是无效的，必须是objectLock这样的锁才是有效的

这样的无效锁，编译器会跳过

--------------------

## 5. 锁粗化 ##

public class LockBigDemo {
        
        static Object objectLock = new Object();
    
        public static void main(String[] args) {
        
            new Thread(() -> {
        
                synchronized (objectLock){
        
                    System.out.println("1111111");
                }
                synchronized (objectLock){
        
                    System.out.println("2222222");
                }
                synchronized (objectLock){
        
                    System.out.println("3333333");
                }
                synchronized (objectLock) {
        
                    System.out.println("4444444");
                }
            }, "t1").start();
        }
    }

![在这里插入图片描述][96d25556e91f48c29b91a965006f8d81.png_pic_center]

上面方法中首尾相接，前后相邻的都是一个锁对象，那么JIT编译器就会把这几个synchronized块合并成一大块

加粗加大范围，一个申请锁使用即可，避免次次的申请和释放锁，提升了性能

--------------------

> 来源：[尚硅谷2022版JUC并发编程（对标阿里P6-P7）][2022_JUC_P6-P7]

[7579244e22ba4ca69a07bcc07e27d12b.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/5b2886a1f8b14a47bb151e1aa353baf1.png
[28f718f8b5904633b3c8e8f86bf8c177.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/ecc285bcfc6343da80cfe9e09f2169d2.png
[c0baaab93f3f45ec976294acf7242392.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/4028ce082a404da8acbae8580d4e9525.png
[b0f000bbc2074ef39e6d09aaf3a69ab1.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/3a8326014c314f15b453ce74cdd9d263.png
[a2c775544c7a4fc3adcc4fd480264602.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/60b2ebde186a45efac304ed0ee1ba4a8.png
[19c062a0028547ecbb1e5083cb5cd49f.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/ff0419355cfd4756a5eda5d2cb98f240.png
[e32ab15832e14c1d8c22f45276c748d8.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/b829226eb8854c24b667885ac1d69947.png
[37089a23c97d4ac7981ae91ca60711be.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/9578db91bfd04610851b5e5c866e011c.png
[a7b506344b87485198a6ec432224d580.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/12b3248ba0204b77a3118056a01ac7e5.png
[e4c30ef5aa9141edb728647046fcbabc.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/e1e5c76a78164e35854d231c548a359b.png
[5456a82d07c6460ea2fbf3c11eb64d85.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/627924923d3c4aefb727b7ed09a08192.png
[968745159aa84d2884ae4a2dfacdf6bc.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/e27e60ca842a4a07883cb23834d279a6.png
[e7e02a0721214548891bf165ab85f747.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/6715130a17aa45fbb75d9a632750d7f3.png
[74c288c86d29455fbc63d7ca980d68c5.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/cfbd89bead864881a0fd527540b4b20b.png
[1db758d1c01049ca94dff006613599fa.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/0f1b9acff83e4af1bbb98941d0d3b5d2.png
[96d25556e91f48c29b91a965006f8d81.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/2ea42fcacfe74433b3981eb3a51b6498.png
[2022_JUC_P6-P7]: https://www.bilibili.com/video/BV1ar4y1x727?p=121&vd_source=cc24ad51180ec9731f4262085c2e8be9