JVM锁优化和逃逸分析

﹏ヽ暗。殇╰゛Y 2023-10-11 17:32 39阅读 0赞

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

*  1.锁优化
 *   *  1.1 自旋锁和自适应自旋
     *   *  为什么要使用自旋锁
         *  线程自旋与线程阻塞
     *  1.2 锁消除
     *  1.3 锁粗化
     *  1.4 逃逸分析
     *   *  方法逃逸
         *  线程逃逸
         *  通过逃逸分析，编译器对代码的优化

## 1.锁优化 ##

jvm 在加锁的过程中，会采用自旋、自适应、锁消除、锁粗化等优化手段来提升代码执行效率。  
我们接下来看看这些优化手段都是干什么的。

### 1.1 自旋锁和自适应自旋 ###

现在大多的处理器都是多核处理器 ，如果在多核心处理器，有让两个或者以上的线程并行执行，我们可以让一个等待线程不放弃处理器的执行时间。设置一个等待超时时间，看线程是否能够很快的释放锁，在等待的这段时间可以执行一个空循环，让当前线程继续占用 CPU 的时间片。这就是所谓的「自旋锁」。

说这一堆，总结起来就一句话：自旋锁是指当一个线程尝试获取某个锁时，如果该锁已被其他线程占用，就一直循环检测锁是否被释放，而不是进入线程挂起或睡眠状态。

#### 为什么要使用自旋锁 ####

多个线程对同一个变量一直使用CAS（原子性）操作，那么会有大量修改操作，从而产生大量的缓存一致性流量，因为每一次CAS操作都会发出广播通知其他处理器，从而影响程序的性能。

#### 线程自旋与线程阻塞 ####

阻塞的缺点显而易见，线程一旦进入阻塞(Block)，再被唤醒的代价比较高，性能较差。自旋的优点是线程还是Runnable的，只是在执行空代码。当然一直自旋也会白白消耗计算资源，所以常见的做法是先自旋一段时间，还没拿到锁就进入阻塞。

JVM在处理synchrized实现时就是采用了这种折中的方案，并提供了调节自旋的参数。

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

首先来对比一下互斥锁和自旋锁。  
互斥锁：从等待到解锁过程，线程会从sleep状态变为running状态，过程中有线程上下文的切换，抢占CPU等开销。

自旋锁：从等待到解锁过程，线程一直处于running状态，没有上下文的切换。  
虽然自旋锁效率比互斥锁高，但它会存在下面两个问题  
自旋锁一直占用CPU，在未获得锁的情况下，一直运行，如果不能在很短的时间内获得锁，会导致CPU效率降低。

试图递归地获得自旋锁会引起死锁。递归程序决不能在持有自旋锁时调用它自己，也决不能在递归调用时试图获得相同的自旋锁。

由此可见，我们要慎重的使用自旋锁，自旋锁适合于锁使用者保持锁时间比较短并且锁竞争不激烈的情况。正是由于自旋锁使用者一般保持锁时间非常短，因此选择自旋而不是睡眠是非常必要的，自旋锁的效率远高于互斥锁。

JVM 中可以通过 +XX:UseSpinning来开启自旋锁，在 JDK1.6 过后默认为我们开启。由于自旋锁的使用会让锁的竞争者占用更多的处理器时间， JVM 规定了一个自旋次数的一个参数。我们可以通过 -XX:PreBlockSping来进行更改（默认10次）。

偏向锁、轻量级锁的状态转化及对象 Mark Word 的关系转换入下图所示：  
![在这里插入图片描述][de3bfdcaeefd45b29ca35260f0518f39.png_pic_center]  
总结：

> 由于自旋锁只是在当前线程不停地执行循环体，不进行线程状态的切换，因此响应速度更快。但当线程数不停增加时，性能下降明显，因为每个线程都需要占用CPU时间。如果线程竞争不激烈，并且保持锁的时间很短，则适合使用自旋锁。

### 1.2 锁消除 ###

锁消除即删除不必要的加锁操作。JVM在运行时，对一些“在代码上要求同步，但是被**检测到不可能存在共享数据竞争情况**”的锁进行消除。

根据代码逃逸技术，如果判断到一段代码中，堆上的数据不会逃逸出当前线程，那么就可以认为这段代码是线程安全的，无需加锁。锁消除的主要判断**依据于逃逸分析**。

下面是三个字符串 x, y, z 相加的例子，无论是从源代码上还是逻辑上都没有进行同步。

public String concatStr(String x, String y, String z) {
        
        return  x + y + z;
    }

String 是一个不可变的类，对字符的链接总是生成新的 String 对象来进行的，因此 Javac 编译器会对 String 链接进行自动优化，在 jdk5 之前字符串链接会转换为 StringBuffer；

在 jdk5 之后会转换为 StringBuilder 对象连续的 append()操作，我们看看 javac 过后，反编译的结果:

public String concatStr(String x, String y, String z) {
        
        StringBuilder sb = new StringBuilder();
        sb.append(x);
        sb.append(y);
        sb.append(z);
        return  sb.toString();
    }

这里大家可能会担心 StringBuilder不是线程安全的的操作会存在线程安全的问题吗？

这里的答案是不会，x + y + z操作的优化「经过逃逸分析」过后，他的动态作用域被限制在了 concatStr方法内，就是说当前实际执行的 StringBuilder 的操作在 concatStr 方法内部，「其他的外部线程无法访问」到，所以这里「虽然有锁，但是可以被安全的消除掉。所以当我们进行编译过后，这段代码就会忽略掉所有的同步措施直接执行。」  
![在这里插入图片描述][9f16a0e3182b477cbee789265fbe3248.png_pic_center]

上图则是javap反编译的结果。

### 1.3 锁粗化 ###

假设一系列的连续操作都会对同一个对象反复加锁及解锁，甚至加锁操作是出现在循环体中的，即使没有出现线程竞争，频繁地进行互斥同步操作也会导致不必要的性能损耗。

如果JVM检测到有一连串零碎的操作都是对同一对象的加锁，将会扩大加锁同步的范围（即锁粗化）到整个操作序列的外部。

原则上，我们在写代码的时候，总是推荐将同步块的作用范围限制得尽可能的小–只在共享数据的实际操作作用域中才进行同步，这样也是为了使得需要同步的操作尽可能的变少，即使存在锁的竞争，等待的锁的线程也能很快的获取到锁。

大多数情况下，上面的原则都是正确的，但是如果「一系列的连续操作都是对同一个对象反复加锁和解锁，甚至加锁操作时出现在循环体之中」的，那即使没有线程的竞争，频繁的进行相互操作也会导致不必需要的性能损耗。

StringBuffer buffer = new StringBuffer();
    /**  锁粗化 */ 
    public void append(){
         
     buffer.append("aaa").append(" bbb").append(" ccc"); 
    }

上面的代码每次调用 buffer.append 方法都需要加锁和解锁，如果 JVM检测到有一串连续的对同一个对象加锁和解锁的操作，就会将其合并成一次范围更大的加锁解锁操作，即在第一个 append 方法执行的时候进行加锁，最后一个 append 方法结束后进行解锁。

### 1.4 逃逸分析 ###

逃逸分析（Escape Analysis），是一种可能减少有效Java 程序中同步负载和内存堆分配压力的跨全局函数数据流分析算法。

通过逃逸分析，Java Hotspot 编译器能够分析出一个新的对象引用范围从而决定是否要将这个对象分配到堆上，「逃逸分析的基本行为就是分析对象的动态作用域。」

#### 方法逃逸 ####

当一个对象在方法里面被定义后，它可能被外部方法所引用，例如调用参数传递到其他方法中，这种称为方法逃逸。

#### 线程逃逸 ####

当一个对象可能被外部线程访问到，比如：赋值给其他线程中访问的实例变量，这种称为线程逃逸。

#### 通过逃逸分析，编译器对代码的优化 ####

如果能够证明一个对象不会逃逸到到方法外或线程外（其他线程方法或者线程无法通过任何方法访问该变量），或者逃逸程度比较低（只逃逸出方法而不逃逸出线程）则可以对这个对象采用不同程度的优化：

1、栈上分配（Stack Allocations）完全不会逃逸的局部变量和不会逃逸出线程的对象，采用栈上分配，对象就会跟随方法的结束自动销毁。以减少垃圾回收器的压力。

2、标量替换（Scalar Replacement）有个对象可能不需要作为一个连续的存储结果存储也能被访问到，那么对象的部分（或者全部）可以不存储在内存，而是存储在 CPU 寄存器中。

3、同步消除（Synchronization Elimination）如果一个对象发现只能在一个线程访问到，那么这个对象的操作可以考虑不同步。

[de3bfdcaeefd45b29ca35260f0518f39.png_pic_center]: https://img-blog.csdnimg.cn/de3bfdcaeefd45b29ca35260f0518f39.png#pic_center
[9f16a0e3182b477cbee789265fbe3248.png_pic_center]: https://img-blog.csdnimg.cn/9f16a0e3182b477cbee789265fbe3248.png#pic_center