逃逸分析之标量替换

╰+哭是因爲堅強的太久メ 2021-07-24 22:19 398阅读 0赞

# 一 点睛 #

标量（scalar）是指一个无法再分解成更小的数据的数据。Java 中的原始数据类型就是标量。

相对的，那些还可以分解的数据叫做聚合量（Aggregate），Java 中的对象就是聚合量，因为他可以分解成其他聚合量和标量。

在 JIT 阶段，如果经过逃逸分析，发现一个对象不会被外界访问的话，那么经过 JIT 优化，就会把这个对象拆解成若干个其中包含的若干个成员变量来代替。这个过程就是标量替换。

# 二 实战——标量替换 #

## 1 原始代码 ##

public static void main(String args[]) {
        alloc();
    }
    class Point {
        private int x;
        private int y;
    }
    private static void alloc() {
        Point point = new Point(1,2);
        System.out.println("point.x" + point.x + ";point.y" + point.y);
    }

## 2 标量替换后的代码 ##

private static void alloc() {
        int x = 1;
        int y = 2;
        System.out.println("point.x = " + x + "; point.y=" + y);
    }

可以看到，Point 这个聚合量经过逃逸分析后，发现他并没有逃逸，就被替换成两个标量了。

那么标量替换有什么好处呢？就是可以大大减少堆内存的占用。因为一旦不需要创建对象了，那么就不再需要分配堆内存了。

标量替换为栈上分配提供了很好的基础。

# 三 标量替换参数设置 #

> \-XX:+EliminateAllocations：开启标量替换（默认打开），允许将对象打散分配在栈上。

# 四 实战——代码优化之标量替换 #

## 1 代码 ##

/**
    * 标量替换测试
    *  -Xmx100m -Xms100m -XX:+DoEscapeAnalysis -XX:+PrintGC -XX:-EliminateAllocations
    */
    public class ScalarReplace {
        public static class User {
            public int id;
            public String name;
        }
    
        public static void alloc() {
            User u = new User(); // 未发生逃逸
            u.id = 5;
            u.name = "cakin";
        }
    
        public static void main(String[] args) {
            long start = System.currentTimeMillis();
            for (int i = 0; i < 10000000; i++) {
                alloc();
            }
            long end = System.currentTimeMillis();
            System.out.println("花费的时间为： " + (end - start) + " ms");
        }
    }
    
    /*
    // 一个聚合量分解成两个标量和一个聚合量
    class Customer{
        String name;
        int id;
        Account acct;
    }
    // 一个聚合量分解成一个标量
    class Account{
        double balance;
    }
    */

上述代码在主函数中进行了1亿次 alloc 调用进行对象创建，由于 User 对象实例需要占据约 16 字节的空间，因此累计分配空间达到将近 1.5 GB。如果堆空间小于这个值，就必然会发生 GC。

## 2 不进行标量替换 ##

> \-Xmx100m -Xms100m -XX:+DoEscapeAnalysis -XX:+PrintGC -XX:-EliminateAllocations

控制台打印如下

> \[GC (Allocation Failure)  25600K->1091K(98304K), 0.0010280 secs\]
> 
> \[GC (Allocation Failure)  26691K->976K(98304K), 0.0008025 secs\]
> 
> \[GC (Allocation Failure)  26576K->896K(98304K), 0.0009549 secs\]
> 
> \[GC (Allocation Failure)  26496K->896K(98304K), 0.0006841 secs\]
> 
> \[GC (Allocation Failure)  26496K->896K(98304K), 0.0007844 secs\]
> 
> \[GC (Allocation Failure)  26496K->896K(100864K), 0.0007835 secs\]
> 
> \[GC (Allocation Failure)  31616K->816K(100864K), 0.0007315 secs\]
> 
> \[GC (Allocation Failure)  31536K->816K(100864K), 0.0003173 secs\]
> 
> 花费的时间为： 71 ms

## 3 进行标量替换 ##

> \-server -Xmx100m -Xms100m -XX:+DoEscapeAnalysis -XX:+PrintGC -XX:+EliminateAllocations

控制台打印如下

> 花费的时间为： 6 ms

## 4 参数说明 ##

*  \-server：启动Server模式，因为在server模式下，才可以启用逃逸分析。
 *  \-XX:+DoEscapeAnalysis：启用逃逸分析
 *  \-Xmx10m：指定了堆空间最大为10MB
 *  \-XX:+PrintGC：将打印Gc日志
 *  \-XX:+EliminateAllocations：开启了标量替换（默认打开），允许将对象打散分配在栈上，比如对象拥有 id 和 name 两个字段，那么这两个字段将会被视为两个独立的局部变量进行分配。

# 五 逃逸分析的不足 #

关于逃逸分析的论文在 1999 年就已经发表了，但直到 JDK1.6 才有实现，而且这项技术到如今也并不是十分成熟。

其根本原因就是无法保证逃逸分析的性能消耗一定能高于他的消耗。虽然经过逃逸分析可以做标量替换、栈上分配、和锁消除。但是逃逸分析自身也是需要进行一系列复杂的分析的，这其实也是一个相对耗时的过程。

一个极端的例子，就是经过逃逸分析之后，发现没有一个对象是不逃逸的。那这个逃逸分析的过程就白白浪费掉了。

虽然这项技术并不十分成熟，但是它也是即时编译器优化技术中一个十分重要的手段。

注意到有一些观点，认为通过逃逸分析，JVM 会在栈上分配那些不会逃逸的对象，这在理论上是可行的，但是取决于 JVM 设计者的选择。据我所知，oracle Hotspot JVM中并未这么做，这一点在逃逸分析相关的文档里已经说明，所以可以明确所有的对象实例都是创建在堆上。

目前很多书籍还是基于 JDK7 以前的版本，JDK 已经发生了很大变化，intern 字符串的缓存和静态变量曾经都被分配在永久代上，而永久代已经被元数据区取代。但是，intern 字符串缓存和静态变量并不是被转移到元数据区，而是直接在堆上分配，所以这一点同样符合前面一点的结论：对象实例都是分配在堆上。

# 六 小结 #

*  年轻代是对象的诞生、成长、消亡的区域，一个对象在这里产生、应用，最后被垃圾回收器收集、结束生命。
 *  老年代放置长生命周期的对象，通常都是从 survivor 区域筛选拷贝过来的 Java 对象。当然，也有特殊情况，我们知道普通的对象会被分配在TLAB上；如果对象较大，JVM 会试图直接分配在 Eden 其他位置上；如果对象太大，完全无法在新生代找到足够长的连续空闲空间，JVM就会直接分配到老年代。当GC只发生在年轻代中，回收年轻代对象的行为被称为 MinorGC。
 *  当 GC 发生在老年代时则被称为 MajorGC 或者 FullGC。一般的，MinorGC 的发生频率要比 MajorGC 高很多，即老年代中垃圾回收发生的频率将大大低于年轻代。