Java synchronized 关键字(1)-使用全解

淡淡的烟草味﹌ 2023-10-19 08:01 33阅读 0赞

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

*  1. synchronized 的作用
 *  2. synchronized 的作用范围
 *   *   *  2.1 synchronized 锁静态方法
         *  2.2 synchronized 锁对象方法
         *  2.3 synchronized 锁代码块
         *  结论:
 *  3. synchronized 的实现原理
 *   *   *  3.1 synchronized 同步代码块实现原理
         *  3.2 synchronized 同步方法实现原理
 *  4.Java 中各种锁的概念
 *   *   *  4.1 可重入锁
         *  4.2 公平锁与非公平锁
 *  5. JVM 对synchronized的优化
 *   *   *  5. 1 锁消除
         *  5. 2 锁粗化
         *  5. 2 偏向锁: 基于大多数情况锁总是由同一线程多次获得的经验
         *  5. 3 轻量级锁:基于绝大部分锁在整个同步周期内都不存在竞争的经验
         *  5. 4 自旋锁与自适应自旋锁:基于共享数据的锁定只会持续很短时间的前提经验
         *   *   *  5. 4.1 自旋锁
                 *  5. 4.2 自适应自旋锁

## 1. synchronized 的作用 ##

`synchronized` 是Java中实现互斥同步的手段,它可以保证方法或者代码块在运行时,同一时刻只有一个线程可以进入到临界区,同时它还可以保证共享变量的内存可见性. Java 中每一个对象都可以作为锁，这是`synchronized`实现同步的基础

*  **synchronized 能够实现原子性和可见性**  
    在Java内存模型中, synchronized规定线程在加锁时, 先清空工作内存→在主内存中拷贝最新变量的副本到工作内存→执行完代码→将更改后的共享变量的值刷新到主内存中→释放互斥锁. 这样 ThreadB 在申请 **同一个锁** 时,就会读取到之前得到锁的线程修改后的数据.
 *  **synchronized 无法禁止指令重排，但能保证有序性**  
    这是因为 `as-if-serial`语义的存在：不管怎么重排序，单线程程序的执行结果不能被改变。`synchronized` 通过排他锁的方式保证了同一时间内被其修饰的代码是单线程执行的，这就满足了`as-if-serial`语义关键的`单线程`前提，因为有`as-if-serial`语义保证，单线程程序有序性就天然存在了。另外，如果没有指令重排，也就不会有有序性问题

## 2. synchronized 的作用范围 ##

#### 2.1 synchronized 锁静态方法 ####

synchronized修饰静态方法,实际上是对该方法所属的类加锁, 俗称“类锁”. 在这种情况下, 一个对象在两个线程中分别调用一个静态同步方法和一个非静态同步方法,实际不会产生互斥. 因为静态同步方法持有的是类锁,非静态同步方法持有的是对象锁, 两把锁锁住的对象不一样.

public synchronized static void method(){
         
        // 实际锁住的是方法所属类, 是类锁
    }

#### 2.2 synchronized 锁对象方法 ####

synchronized修饰非静态方法,实际上是对该方法所在的类的对象加锁, 俗称“对象锁”. 在这种情况下, 一个对象在多个线程中调用 synchronized 方法, 实际上是对这个对象锁的争用,只有拿到锁才有权限执行代码.

public synchronized void method(){
          
        // 实际锁住的是方法所属类的对象, 相当于this
    }

#### 2.3 synchronized 锁代码块 ####

synchronized 修饰一个代码块，被修饰的代码块称为同步语句块, 其作用的范围是大括号\{\}括起来的代码，作用的对象是调用这个代码块的对象.

public void method(){
          
       synchronized(this){
         // synchronized锁住对象不同为不同的锁
        // 锁住静态对象变量(static Object lock = new Object();)为类锁
        // 锁住普通对象变量(Object lock = new Object();)为对象锁
       }
    }

#### 结论: ####

多个并发线程是否互斥需要根据synchronized锁住的对象来确定,如果多线程访问的代码持有的锁是**同一个对象**, 则在同一时刻只能有一个线程得到执行,其他线程必须等待当前线程执行完这个代码块以后才能竞争锁执行该代码块.

## 3. synchronized 的实现原理 ##

> 源码实现可以参考 [Java synchronized 关键字(2)-JVM 的锁实现分析][Java synchronized _2_-JVM]

#### 3.1 synchronized 同步代码块实现原理 ####

1.  同步语句块的实现使用的是monitorenter 和 monitorexit 指令，其中monitorenter指令指向同步代码块的开始位置，monitorexit指令则指明同步代码块的结束位置.
2.  当执行monitorenter指令时，当前线程将试图获取 objectref(即对象锁) 所对应的 **monitor** 的持有权 (monitor对象存在于每个Java对象的对象头中，synchronized 锁就是通过这种方式获取锁的，这也是Java中任意对象都可以作为锁对象的原因) ,当 objectref 的 monitor 的进入计数器为 0，那线程可以成功取得 monitor，并将计数器值 +1，取锁成功.
3.  如果当前线程已经拥有 objectref 的 monitor 的持有权，那它可以重入这个 monitor ,重入时计数器的值也会 +1，执行一次 monitorexit 指令则计数器 -1.
4.  假如其他线程已经拥有 objectref 的 monitor 的所有权，那当前线程将被阻塞，直到正在执行的线程执行完毕, 即monitorexit指令被执行，执行线程将释放 monitor(锁)并设置计数器值为0 ，其他线程将有机会持有 monitor .
5.  编译器会确保无论通过何种方式完成,调用过的每条 monitorenter 指令都会执行其对应 monitorexit 指令，无论这段代码是正常结束还是异常结束. 为了保证在方法异常完成时 monitorenter 和 monitorexit 指令依然可以正确配对执行，编译器会自动产生一个异常处理器，这个异常处理器声明可处理所有的异常，它的目的就是用于执行 monitorexit 指令.

#### 3.2 synchronized 同步方法实现原理 ####

1.  synchronized 修饰的方法并没有 monitorenter 指令和 monitorexit 指令，取而代之的是 ACC\_SYNCHRONIZED 标识(HotSpot 中已经废弃). 这个标识指明了该方法是一个同步方法.
2.  当方法调用时，调用指令将检查方法的 ACC\_SYNCHRONIZED 访问标志是否被设置，如果设置了,执行线程将先持有monitor(虚拟机规范中用的是管程一词), 然后再执行方法, 最后在方法完成(无论是正常完成还是非正常完成)时释放monitor.
3.  在方法执行期间执行线程持有了monitor, 其他任何线程都无法再获得同一个monitor.如果一个同步方法执行期间抛出了异常, 并且在方法内部无法处理此异常，那这个同步方法所持有的monitor将在异常抛到同步方法之外时自动释放.

## 4.Java 中各种锁的概念 ##

#### 4.1 可重入锁 ####

可重入锁的概念可通过如下代码来解释, 在以下代码中同步方法 getValue() 调用了另一个同步方法 getObjectValue(). 如果锁是不可重入的,那么当线程取得对象锁调用 getValue() 方法时, 再去调用同步方法 getObjectValue(), 又需要再次获取对象锁. 而这时对象锁已经被线程自己持有了,它没有执行完方法体又不会释放锁,这样就产生了死锁.

public synchronized void getValue(){
        
       getObjectValue()
    }
    public synchronized void getObjectValue(){
        
     // TODO
    }

简单来说, 可重入锁就是可重复可递归调用的锁,在外层使用锁之后,在内层仍然可以使用,并且不发生死锁(前提是内外层同步锁住的是同一个对象).

#### 4.2 公平锁与非公平锁 ####

公平锁与非公平锁在AQS(AbstractQueuedSynchronizer, 基于CAS实现)锁框架中有实现,可通过相关参数设置锁是否为公平锁.

*  **公平锁**  
    尽量以请求锁的顺序来获取锁.比如同时有多个线程在争用一个锁, 当这个锁被释放时,等待时间最久的线程(最先请求的线程)会获得该锁，这种就是公平锁.
 *  **非公平锁**  
    无法保证锁的获取是按照请求锁的顺序进行, 这样就可能导致某个或者一些线程永远获取不到锁.在Java中,synchronized就是非公平锁,它无法保证等待的线程获取锁的顺序.

## 5. JVM 对synchronized的优化 ##

为了提高锁的性能,Jdk 1.6 开始, 虚拟机开发团队实现了许多锁优化的技术.  
锁的状态总共有四种, 无锁状态、偏向锁、轻量级锁和重量级锁. 随着锁的竞争,锁可以从偏向锁升级到轻量级锁, 再升级到重量级锁, 但是锁的升级是单向的, 也就是说只能从低到高升级,不会出现锁的降级

#### 5. 1 锁消除 ####

JVM即时编译器( JIT )在运行时, 对一些代码上要求同步但被检测到不可能存在共享数据竞争的锁进行消除, 这是基于逃逸分析的技术。

*  **逃逸分析**  
    主要用于分析确定对象是否有可能逃逸出当前线程，被其他线程访问到。如果对象不存在逃逸，则可以将其在虚拟机栈中分配，以便减小垃圾回收的压力。

#### 5. 2 锁粗化 ####

如果一系列连续操作都对同一个对象加锁和解锁, 那么即便没有线程争用,频繁地进行互斥操作也会导致不必要的性能损耗.JVM 探测到这种情况就会把加锁同步的范围粗化到整个操作序列的外部.

#### 5. 2 偏向锁: 基于大多数情况锁总是由同一线程多次获得的经验 ####

1.  在大多数情况下，锁不仅不存在多线程竞争，而且总是由同一线程多次获得，因此为了减少同一线程获取锁的代价(会涉及到一些CAS操作，有耗时)而引入偏向锁.
2.  锁会偏向第一个获得它的线程. 当锁对象第一次被线程获取的时候,虚拟机会使用CAS操作把获取到这个锁的线程的ID记录到对象的Mark Word中, CAS操作成功则持有偏向锁的线程以后每次进入该锁相关的同步块时, 虚拟机都可以不再进行任何同步操作.
3.  如果有线程尝试去获取这个锁,则偏向锁模式结束,根据对象目前的锁定状态撤销偏向锁并恢复为无锁状态或者轻量级锁定状态.

*  \-XX:UseBiasedLocking 可用来设置偏向锁优化是否开启

以 下 为 对 象 的 M a r k W o r d 可 能 的 存 储 结 构 : 以下为对象的 Mark Word 可能的存储结构: 以下为对象的MarkWord可能的存储结构:

<table> 
 <tbody> 
  <tr> 
   <td>锁状态</td> 
   <td colspan="2">25bit</td> 
   <td>4bit</td> 
   <td>1bit</td> 
   <td>2bit</td> 
  </tr> 
  <tr> 
   <td>23bit</td> 
   <td>2bit</td> 
   <td>是否是偏向锁</td> 
   <td>锁标志位</td> 
  </tr> 
  <tr> 
   <td>无锁</td> 
   <td colspan="2">对象的HashCode</td> 
   <td>对象分代年龄</td> 
   <td>0</td> 
   <td>01</td> 
  </tr> 
  <tr> 
   <td>偏向锁</td> 
   <td>线程ID</td> 
   <td>Epoch: 偏向锁时间戳</td> 
   <td>对象分代年龄</td> 
   <td>1</td> 
   <td>01</td> 
  </tr> 
  <tr> 
   <td>轻量级锁</td> 
   <td colspan="4">指向栈帧中锁记录的指针</td> 
   <td>00</td> 
  </tr> 
  <tr> 
   <td>重量级锁</td> 
   <td colspan="4">指向互斥量（重量级锁）的指针</td> 
   <td>10</td> 
  </tr> 
  <tr> 
   <td>GC标志</td> 
   <td colspan="4">空</td> 
   <td>11</td> 
  </tr> 
 </tbody> 
</table>

#### 5. 3 轻量级锁:基于绝大部分锁在整个同步周期内都不存在竞争的经验 ####

1.  如果锁对象头已经存在偏向锁标志, 则需要检查持有偏向锁的线程是否依然在执行. 如果偏向锁记录的线程不再执行, 竞争锁的线程使用 CAS 替换锁对象头的线程ID 为自己即可，此时仍然为偏向锁；如果持有偏向锁的线程仍在执行且还没有释放锁, 表明存在锁竞争, 此时偏向锁模式结束, 偏向锁将被撤销, 锁升级为轻量级锁
2.  当线程进入同步代码块时，JVM 会在该线程的栈帧中创建一个锁记录(Lock Record)空间, 用于存储锁对象的 Mark Word 的拷贝。当锁升级为轻量级锁时，JVM 使用 CAS 操作更新锁对象的 Mark Word 为指向原本持有偏向锁的线程 锁记录 的指针, 更新成功, 原持有偏向锁的线程继续持有锁, 并更新锁状态为轻量级锁定.
3.  `请求锁的线程`发现偏向锁只是撤销了, 并没有重新偏向自己, 则有以下两个分支逻辑：
    
    1.  如果 Mark Word 为无锁状态(锁升级为轻量级锁后也有可能很快被释放了)，则竞争线程也会尝试使用 CAS 操作更新锁对象的 Mark Word 为指向自身 锁记录 的指针. 如果更新成功，获取锁返回；如果更新失败,说明其他线程已经抢占了锁, 锁膨胀为重量级锁(锁标识改变)
    2.  如果 Mark Word 不为无锁状态，则检查锁的持有者是否是自己, 是的话说明当前线程已经获得锁, 直接进入同步代码块执行. 如果否, 说明其他线程已经抢占了锁, 锁膨胀为重量级锁(锁标识改变)
    3.  重量级锁依赖锁对象 MarkWord 构建，所以之前持有轻量级锁的线程依然持有重量级锁. 进入重量级锁的竞争中, 请求锁的线程可进入自旋等待; 如果完成自旋发现锁还是被占用, 则挂起进入阻塞状态, 等待锁释放时被唤醒
4.  解锁时使用CAS操作把锁对象当前 Mark Word 与线程中的复制的 Mark Word 替换, CAS 操作成功则同步完成. 失败(锁膨胀为重量级锁的话锁标识变了)则释放锁,并唤醒其他线程(重量级锁其他等待线程都为阻塞状态).

有竞争时, 除了互斥量的开销, 轻量级锁还额外发生了CAS操作, 故比重量级锁更慢.

#### 5. 4 自旋锁与自适应自旋锁:基于共享数据的锁定只会持续很短时间的前提经验 ####

###### 5. 4.1 自旋锁 ######

等待锁的线程并不挂起,而是先执行一个空循环(自旋),看看持有锁的线程是否很快就会释放锁.

*  优点:  
    避免了线程切换的开销,在锁被占有的时间很短时效果很好
 *  缺点:  
    如果锁被占用的时间很长,自旋会白白消耗处理器资源,带来性能上的浪费
 *  \-XX:PreBlockSpin 可修改自旋次数, 默认为10

###### 5. 4.2 自适应自旋锁 ######

如果在同一个锁对象上, 自旋等待刚刚成功获得过锁,并且持有锁的线程正在运行,则认为此次自旋也很可能成功,进而允许它自旋等待相对更长的时间.反之,如果对某个锁自旋很少成功获得过锁,则以后获取这个锁时很可能省略掉自旋过程.

[Java synchronized _2_-JVM]: https://blog.csdn.net/weixin_45505313/article/details/112171348