[JUC第二天]浅谈synchronized关键字

电玩女神 2023-07-12 09:00 15阅读 0赞

### 文章目录 ###

*  概述
 *   *  Synchronized关键词
     *   *  同步方法锁的是什么
         *  同步方法 VS 同步代码块
     *  Synchronized与锁
 *  锁的是什么
 *   *  Java对象头
 *  锁的升级
 *   *  锁消除
     *  偏向锁
     *   *  关闭偏向锁
     *  轻量级锁
     *   *  自旋锁
         *  CAS
     *  重量级锁

# 概述 #

## Synchronized关键词 ##

`Synchronized`是在爪哇语言中用于实现线程同步的关键词

在调用`Synchronized`的方法之后，该代码部分只能有一个线程执行，通常情况下，有下面两种用法：

> 同步方法

public synchronized void test()
    {
        
        ....
    }

> 同步代码块

public void test()
    {
        
        synchronized(xxx){
        
            
        }
    }

两者都是通过`加锁`的方式，拿到某个东西作为锁，使得本段代码只能被一个线程执行，如果有其他线程在这期间想要执行，则需要等待。但是这两种写法的粒度是不同的

### 同步方法锁的是什么 ###

对于同步方法，这里我就直接给出结论了：

*  对于同步方法，锁是当前实例对象
 *  对于静态同步方法，锁是当前对象的Class对象
 *  对于同步方法块，锁是Synchonized括号里配置的对象

可以看这样一个程序：

package com.imlehr.juc.chapter2;
    
    import java.util.concurrent.TimeUnit;
    
    public class Test {
        
    
    
        public synchronized void M1() {
        
            System.out.println("M1");
            try {
        
                TimeUnit.SECONDS.sleep(3);
            } catch (InterruptedException e) {
        
                e.printStackTrace();
            }
        }
    
       public synchronized void M11() {
        
            System.out.println("M11");
            try {
        
                TimeUnit.SECONDS.sleep(3);
            } catch (InterruptedException e) {
        
                e.printStackTrace();
            }
        }
        
        public synchronized void M2() {
        
            System.out.println("M2");
            try {
        
                TimeUnit.SECONDS.sleep(3);
            } catch (InterruptedException e) {
        
                e.printStackTrace();
            }
        }
        
            public synchronized void M22() {
        
            System.out.println("M22");
            try {
        
                TimeUnit.SECONDS.sleep(3);
            } catch (InterruptedException e) {
        
                e.printStackTrace();
            }
        }
    
        public static void M3() {
        
            System.out.println("M3");
            try {
        
                TimeUnit.SECONDS.sleep(3);
            } catch (InterruptedException e) {
        
                e.printStackTrace();
            }
        }
    
        public static void M4() {
        
            System.out.println("M4");
            try {
        
                TimeUnit.SECONDS.sleep(3);
            } catch (InterruptedException e) {
        
                e.printStackTrace();
            }
        }
    
    
        public static void main(String[] args) {
        
    
            Test t1 = new Test();
            Test t2 = new Test();
            new Thread(() -> t1.M1()).start();
            new Thread(() -> t1.M2()).start();;
            new Thread(() -> t2.M11()).start();;
            new Thread(() -> t2.M22()).start();;
            new Thread(() -> Test.M3()).start();;
            new Thread(() -> Test.M4()).start();;
            
        }
    }

读者可以自行体验一下输出的结果：

输出的情况会大概是这样：

> 首先，会输出三个结果：
> 
> `M1orM2的其中一个` \+ `M11 or M22的其中一个`\+ `M3 or M4的其中一个`
> 
> 然后，过了三秒钟，则继续另外三个结果：
> 
> `M1orM2的其中一个` \+ `M11 or M22的其中一个` \+ `M3 or M4的其中一个`

为什么会这样呢？因为上面说道，同步方法的本质就是锁住本方法所在的类（对于static来说，由于他也在Class类的一个单例实例，所以这个实例也会被锁住）

所以当你调用某个对象的同步方法之后，整个类就会被当成synchronized的锁，这个方法中其他所有的synchronized方法都会被迫等待锁的释放（因为他们也要等待这个对象作为锁）

但是如果你有两个对象的话（比如上面代码中的t1,t2对象），那么你分别执行两个不同对象的synchornized同步方法，他们锁的就是不同的对象本身

对于static方法而言，首先明确一个概念：由于爪哇语言采用的是不同于C++的`OOP-Klass Model`方式来实现的面向对象的

> `OOP-Klass Model`的意思简单的说就是，把一个对象的信息分为两个部分来记录：
> 
>  *  第一部分：OOP，就代表的是你实例化后的对象，就是new之后在堆中开辟空间然后存放的那个东西
>  *  第二部分：klass，这其实就是爪哇中的`Class类`为每一个其他的类生成的记录元数据和静态方法虚函数表什么的类对象了，他是放在方法区里的，每个OOP对象如果需要获取关于自己的类信息或者静态方法，则会通过指针去找到自己对应类的这个Class类对象
> 
> 再讲直白一点，就是，static方法被放在了一个类型是Class类的代表了当前类的元数据的对象中

所以说，当我们调用static的同步方法的时候，这个类对象就会被锁住，也会导致其他static同步方法被锁住

（但是，锁住了类对象不会影响这个类的其他实例化对象的同步方法的使用的）

感觉好像讲得不是很清楚，引用一个例子吧：

> Java中的一个类就像一个手机工厂，一个对象就像生产出来的一台手机
> 
> 比如对于手机而言，现在有两个同步方法：打电话和发短信
> 
> 还有一个普通方法：摸一下手机
> 
> 对于手机厂而言，有这样一个同步方法：工厂关门
> 
> --------------------
> 
> 所以对于一个手机而言，如果他被某个人（线程）调用了打电话方法，那么另外一个需要调用发短信方法的人（线程）就必须等待，不过如果有第三个人（第三个线程）想要摸一下手机的话（就是这个对象没有加synchronized的一个普通方法），那他就可以不用等待而直接去做
> 
> --------------------
> 
> 对于两个手机而言，也是类似的，如果是两个人（线程）分别去用两台手机发短信，那么他们就都不用等待，除非有另外的人在占用着
> 
> --------------------
> 
> 而对于手机厂而言，同步方法也是类似的，但是这里想讲的是：类被锁住不会导致对象的同步方法被锁住
> 
> 这个一个例子：工厂关门了（类的同步方法），但是你的手机还是能打电话（对象的同步方法还是能用），因为他们本质上锁的并不是一个东西

### 同步方法 VS 同步代码块 ###

表面上来看：通过上面的例子，可以发现，其实同步方法只不过是锁定区域范围更大的同步代码块而已

而且使用同步方法还容易导致性能下降（正是因为这个粒度大的问题）

所以说，如果需要使用synchronized，为了避免这种不必要的阻塞，就尽量用同步代码块（或者用Lock类）来细粒度处理，在同步代码块之前可以把那些准备工作提前做好

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

但是在如何锁住这个对象的底层具体实现上，他们还是有些区别的：

对于同步方法，虚拟机是通过在方法常量池中给每个方法添加一个叫做`ACC_SYNCHRONIZED`的标记符来判定的，每次有线程访问的时候，就回去检查这个标志位的状态，如果别标记了，则需要先去试图抢锁，才会有后续的执行

而对于同步代码块，虚拟机则采用`monitorenter`、`monitorexit`两个指令来实现同步，大搞好像是让这个对象维持着一个加锁次数记录器之类的，（因为同步代码块有可能多重嵌套，比如DCL单例模式），只有当计数器是0的时候，才代表现在没有被锁住了，才能下一个线程进行继续操作

## Synchronized与锁 ##

首先借用美团一张图，展示一下锁的分类：

![7f749fc8][]

> 在多线程并发编程中Synchronized一直是元老级角色，很多人都会称呼它为重量级锁，但是随着Java SE1.6对Synchronized进行了各种优化之后，有些情况下它并不那么重了，Java SE1.6中为了减少获得锁和释放锁带来的性能消耗而引入的偏向锁和轻量级锁，以及锁的存储结构和升级过程。—Java并发编程艺术

在Java 6以前，一旦使用Synchronized，就必定会触发一次锁操作（也就是上面讲的那些），但是锁操作会导致线程的状态发生各种变化，由于要阻塞或唤醒线程都会涉及到操作系统，需要在户态与核心态之间切换，这种切换会消耗大量的系统资源，所以每次使用一次synchronized的代价是非常大的，这也就是为什么他之前被叫做重量级锁（这个级别指的是对性能的影响），如果对于那些需要同步的简单的代码块，获取锁挂起操作消耗的时间比用户代码执行的时间还要长，这种同步策略显然非常糟糕的，所以为了解决这个问题，在Java 6以后，引入了锁的升级的概念，分别设置了四个不同级别的锁的情况：`无锁状态`，`偏向锁状态`，`轻量级锁`，`重量级锁`，这也就是我下文要讲的

在优化之后，对于普通玩家，只要用synchronized就好了，具体底层会使用哪一种机制来实现线程同步就不需要关系了

# 锁的是什么 #

之前只说了，synchronized会拿一个对象作为锁，但是他底层的具体实现其实只是在这个对象的元数据的标志位上做一些记号

## Java对象头 ##

Java里一个对象在堆中，除了保存自己的内容，field，method这部分以外，还会有一个部分叫做对象头，里面记载了这个对象的一系列元数据，而synchronized用的锁就是放在头里的Mark Word这个地方的，对象头中主要包含了GC分代年龄、锁状态标记、哈希码、epoch等信息。对象的状态一共有五种，分别是无锁态、轻量级锁、重量级锁、GC标记和偏向锁

以64位虚拟机为例，Mark Word的长度正好是64bit，他的储存内容如下（搬运自并发编程艺术作者博客）：

<table> 
 <thead> 
  <tr> 
   <th><strong>锁状态</strong></th> 
   <th>25bit</th> 
   <th>31bit</th> 
   <th>1bit</th> 
   <th>4bit</th> 
   <th>1bit</th> 
   <th>2bit</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td></td> 
   <td></td> 
   <td>cms_free</td> 
   <td>分代年龄</td> 
   <td>偏向锁</td> 
   <td>锁标志位</td> 
   <td></td> 
  </tr> 
  <tr> 
   <td>无锁</td> 
   <td>unused</td> 
   <td>hashCode</td> 
   <td></td> 
   <td></td> 
   <td>0</td> 
   <td>01</td> 
  </tr> 
  <tr> 
   <td>偏向锁</td> 
   <td>ThreadID(54bit) Epoch(2bit)</td> 
   <td></td> 
   <td></td> 
   <td>1</td> 
   <td>01</td> 
   <td></td> 
  </tr> 
 </tbody> 
</table>

接下来对于锁的各种升级，各种操作，都是通过检查和修改Mark Word里的内容来实现的

# 锁的升级 #

锁的升级顺序如下：(锁的升级也被称为锁的膨胀)

> 无锁—>偏向锁—>轻量级锁—>重量级锁

btw：锁只能升级不能降级！

## 锁消除 ##

在锁升级之前，JDK还有一种特殊的优化方式，叫做锁消除

说白了就是，JVM觉得明明就一个线程在那里玩没有必要加锁的时候，他就会JIT编译优化（用了一种叫做逃逸技分析的技术）把你的synchronized代码去除了

这个优化的意义在于：（[引用Hollis的话][Hollis]）

> 这里，可能有读者会质疑了，代码是程序员自己写的，程序员难道没有能力判断要不要加锁吗？就像以上代码，完全没必要加锁，有经验的开发者一眼就能看的出来的。其实道理是这样，但是还是有可能有疏忽，比如我们经常在代码中使用`StringBuffer`作为局部变量，而`StringBuffer`中的`append`是线程安全的，有`synchronized`修饰的，这种情况开发者可能会忽略。这时候，JIT就可以帮忙优化，进行锁消除

## 偏向锁 ##

首先看这样一个例子：

package com.imlehr.juc.chapter2;
    
    public class Test {
        
    
        public synchronized void M1() {
        
            System.out.println("M1");
        }
    
        public static void main(String[] args)  throws Exception{
        
    
            Test t = new Test();
            
            new Thread(() ->{
        
               	for(int i = 0 ;i<100;i++)
                {
        
                	t1.M1();     
                }
            } ).start();
            
            Thread.sleep(10);
            
            new Thread(() ->{
        
               	for(int i = 0 ;i<3;i++)
                {
        
                	t1.M1();     
                }
            } ).start();
        }
    }

在上面这是中这种情况中，可以发现，主要是第一个线程在访问同步方法，第二个方法只会访问3次同步方法，那么如果在上面这种情况下，我们执行每一次的任务的时候都进行加锁（重型锁），那么其实大部分时候都没有什么意义而且开销还会很大

所以，为了让这种情况下的开销变得更小，爪哇虚拟机（HotSpot）采用了`偏向锁`这个东西来解决这种情况

偏向锁，其实就是一种可重入锁：

放一张图：

![jdlkfajfdlkdajblkjdakgaE][]

偏向锁的工作方式如下：

> 首先，在对象头里，有一个叫做ThreadId的字段
> 
> 第一次，A线程去获取锁的时候，发现他是空的，所以就会把自己的线程id放入到锁对象的头里去
> 
> 如果下次请求来的又是A线程，那么首先，对象头查看自己的线程id，如果和a的线程id一致，那么就认为，反正控制权一直是A拿着的，他没有放过，所以可以直接执行（这个阶段上本质就没有真实用到锁，这里其实只是用threadId来标记目前这个方法的执行权在谁手上）
> 
> 同理如果下下次请求还是A线程
> 
> 但是，如果某一次来的不是A线程了，而是B线程，那么和字段里的一对比，不一样！所以这时候就会触发`锁的升级`，使得当前的锁变成`轻量级锁`

偏向锁使用了一种等到竞争出现(有第二个线程来了)才释放锁的机制，所以当其他线程尝试竞争偏向锁时，持有偏向锁的线程才会释放锁，其实就是无锁竞争下可重入锁的简单实现，在只有一个线程不停访问某个同步代码块的时候就一直让他保持着锁，直到有竞争情况出现被触发，JVM会消除它身上的偏向锁，将锁恢复到标准的轻量级锁

### 关闭偏向锁 ###

偏向锁在 Java 6 和 Java 7 里是默认启用的

不过也可以通过调节虚拟机参数来手动关闭，使得锁的模式直接进入轻量级锁：

> \-XX:-UseBiasedLocking=false

因为在有的情况下，比如已经知道是个多线程很复杂的情况，几乎不会出现需要用到偏向锁的时候，一开始反复去设置偏向锁的对象头里的id之类的也可能导致效率变低

## 轻量级锁 ##

这里的轻量级锁其实是一种自旋锁，所以先来说下自旋锁：

### 自旋锁 ###

在重量级锁的情况下，当某个线程发现某个同步代码块的锁被人占用的时候，他就会被挂起，进入到阻塞状态（操作系统让线程切换状态，会导致产生一些开销）

但是，如果是这样一个场景：

> 某个同步代码块的任务很少，每个线程只需要执行0.000001秒钟，可是会一个接着一个地来很多线程（间隔是0.0000011秒，也就是每个来的线程都会等一下，且一般每次只有一个线程会在等着）
> 
> 那么，如果直接让线程进入阻塞状态，则每次会产生极大的开销，反而会使得整个程序的执行时间变得很久
> 
> 所以，这时候不如让后面的线程先不忙阻塞，先while循环一小会儿（因为这样开销比让线程挂起小的多的多）
> 
> 这就是所谓的自（己）旋（转），意思就是：稍微等一下
> 
> --------------------
> 
> 用生活中的例子来讲就是：比如去银卡取钱，如果人少而且等的不久，就直接在后面排队（自旋），不用折腾一趟到候客厅去坐着然后再走过来（切换线程状态）

轻量级锁的工作流程如下：

![7fad1fcbaf1e3f6b47aebbbc50063c3e][]

他的工作过程大概这样：

> 紧接着偏向锁的例子
> 
> 第二个线程来抢锁，导致锁膨胀成为轻量级锁
> 
> 第二个线程于是在自己的stack里开辟一个空间，叫做Lock Record，其中包含owner和Displaced Mark Word两个小区域，然后把当前的锁对象的Mark Word拷贝到Displaced Mark Word，代表现在的线程已经知道要去抢的锁是谁了
> 
> 然后，JVM将使用CAS操作尝试将对象的Mark Word更新为指向Lock Record的指针，并将Lock record里的owner指针指向这个锁对象的头部mark word，如果成功执行了，那么就抢锁成功
> 
> 这一步由于是要修改对象的Mark Word，所以如果遇到有两个人都来抢这个锁的时候（当前一共有三个线程：原持有者，和两个抢匪），CAS的更新操作就会失败，这时候说明，多线程的情况已经是超出轻量锁的设计情况了，所以会使得锁膨胀，直接变成重量级锁

为什么如果有第三个线程来抢锁的时候，就需要让锁膨胀呢？

因为：如果多个线程都来等着，而且还要等很久，多个线程疯狂自旋，则也和很浪费资源

其实这里还有另外一种触发膨胀的条件：一个线程自旋太久了，也会让锁膨胀

### CAS ###

上面反复说到CAS这个东西，所以就单独讲一下：

CAS是Compare-and-swap（比较与替换）的简写，是一种有名的`无锁算法`，但是爪哇中他具体的实现代码都是native方法，找操作系统去了…

CAS的基本思想：比较和替换

他在进行写入（替换）的时候，实现的方式是这样的：

> 比较当前的值，看看和我们之前保存的是否一样，如果一样，就在这个值的基础上更新
> 
> 如果不一样，则说明发生了修改，那么这时候需要读取最新的值，然后进行重试（上面那句话）
> 
> 这其实就是个乐观锁

比如你进入AtomicInteger的getAndIncrese方法，他本质是通过一个叫做Unsafe的类来完成的

他就用了Unsafe类中的getAndAddInt（Unsafe类里主要就是CAS实现的一些算法）

@HotSpotIntrinsicCandidate
        public final int getAndAddInt(Object o, long offset, int delta) {
        
            int v;
            do {
        
                v = this.getIntVolatile(o, offset);
            } while(!this.weakCompareAndSetInt(o, offset, v, v + delta));
            return v;
        }

本质就是做循环，如果值不一样，就再去找这个数据的最新值，直到确定了这个数就是最新的值之后，才去修改这个值，从而保证了不用锁还让共享数据同步

所以说卖票问题可以甚至不用加锁，只要你用Atomic系列来做就好了（以后重新写一篇博客来研究CAS）

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

CAS虽然很高效的解决了原子操作问题，但是CAS仍然存在三大问题。

1.  循环时间长开销很大。
2.  只能保证一个共享变量的原子操作。
3.  ABA问题（状态变化多次后又变回来了无法发觉）

以后来详细写

## 重量级锁 ##

就是我们常常说的引起系统调用来改变线程状态的那个锁了

终于写完了累死了

很多地方没有写全，以后补上…

然后这里暂时保留三个没讲的：

*  synchronized与原子性？
 *  synchronized与可见性？
 *  synchronized与有序性？  
    具体以后会补上

参考来源：

http://ifeve.com/java-synchronized/

https://47.99.194.156/archives/2637

https://blog.csdn.net/zqz\_zqz/article/details/70233767

https://tech.meituan.com/2018/11/15/java-lock.html

[7f749fc8]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly9waWMuaW1sZWhyLmNvbS91cGxvYWRzL3R5cG9yYS83Zjc0OWZjOC5wbmc?x-oss-process=image/format,png
[Hollis]: https://47.99.194.156/archives/2637
[jdlkfajfdlkdajblkjdakgaE]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly9waWMuaW1sZWhyLmNvbS91cGxvYWRzL3R5cG9yYS9qZGxrZmFqZmRsa2RhamJsa2pkYWtnYUUucG5n?x-oss-process=image/format,png
[7fad1fcbaf1e3f6b47aebbbc50063c3e]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly9waWMuaW1sZWhyLmNvbS91cGxvYWRzL3R5cG9yYS83ZmFkMWZjYmFmMWUzZjZiNDdhZWJiYmM1MDA2M2MzZS5wbmc?x-oss-process=image/format,png