JVM的自愈能力 JVM
程序员文章站
2022-04-16 19:34:27
...
在IT行业，碰到问题的第一个反应通常是——“你重启过没”——而这样做可能会适得其反，本文要讲述的就是这样的一个场景。
接下来要介绍的这个应用，它不仅不需要重启，而且毫不夸张地说，它能够自我治愈：刚开始运行的时候它可能会碰到些挫折，但会渐入佳境。为了能实际地展示出它的自愈能力，我们尽可能简单地重现了这一场景，这个灵感还得归功于五年前heinz Kabutz发表的一篇老文章:
上述代码会循环地分配两块内存。每次分配的内存都是堆中总内存的60%。由于在同一个方法内会不停地进行这个内存分配，因此你可能会认为这段代码会不断地抛出 java.lang.OutOfMemoryError: Java heap space异常，永远无法正常地执行完allocateMemory方法。
我们先来对源代码进行下静态分析，看看这种猜测是否恰当：
1. 乍看一下这段程序的话，这确实是无法成功执行的，因为要分配的内存已经超出了JVM的限制。
2. 但再仔细分析下的话我们会发现第一次分配是在一个块作用域内完成的，也就是说这个块中定义的变量仅对块内可见。这意味着这些内存在这个代码块执行完成后便可以回收掉了。这段代码一开始应该是可以成功执行的，只是当它再去尝试分配moreBytes的时候才会挂掉。
3. 如果再查看下编译后的class文件的话，你会看到如下的字节码：
从中能够看出，第一个数组是在位置3～5处完成分配的，并存储到了序号为1的本地变量中。随后在位置17处，正要分配另一个数组。不过由于第一个数组仍被本地变量所引用着，因此第二次分配总会抛出OOM的异常而失败。字节码解释器不会允许GC去回收第一个数组，因为它仍然存在着一个强引用。
从静态代码分析中可看出，由于底层的两个约束，上述的代码是无法成功执行的，而在第一种情况下则是能够运行的。这三点分析里面哪个才是正确的呢？我们来实际运行下看看结果吧。结果表明，这些结论都是正确的。首先，应用程序的确无法分配内存。但是，经过一段时间之后（在我的Mac OS X上使用Java 8大概是出现在第255次迭代中），内存分配开始能够成功执行了:
为了搞清楚究竟发生了什么，我们得思考一下，在程序运行期间发生了什么变化？显然，Just-In-Time编译开始介入了。如果你还记得的话，JIT编译是JVM的一个内建机制，它可以优化热点代码。JIT会监控运行的代码，如果发现了一个热点，它会将你的字节码转化成本地代码，同时会执行一些额外的优化，譬如方法内联以及无用代码擦除。
我们打开下面的命令行参数重启下程序，看看是否触发了JIT编译。
这会生成一个日志文件，在我这里是一个hotspot_pid38139.log文件，38139是Java进程的PID。在该文件中可以找到这么一行：
这说明，在运行了256次allocateMemory()方法2之后，C1编译器决定将这个方法进行3级编译。看下这里可以了解下分层编译的各个级别以及不同的阈值。在前面的256次迭代中这段程序都是在解释模式下运行的，这里的字节码解释器就是一个简单堆栈机器，它无法提前预知某个变量后续是否会被用到，在这里对应的是变量bytes。但是JIT会一次性查看整个方法，因此它能推断出后面不会再用到bytes变量，可以对它进行GC。所以才会触发垃圾回收，因此我们的程序才能奇迹般地自愈。我只是希望本文的读者都不要在生产环境碰到调试这类问题的情况。不过如果你想让某人抓狂的话，倒是可以试试在生产环境中加下类似的代码。
原创文章转载请注明出处：http://it.deepinmind.com
英文原文链接
接下来要介绍的这个应用，它不仅不需要重启，而且毫不夸张地说，它能够自我治愈：刚开始运行的时候它可能会碰到些挫折，但会渐入佳境。为了能实际地展示出它的自愈能力，我们尽可能简单地重现了这一场景，这个灵感还得归功于五年前heinz Kabutz发表的一篇老文章:
package eu.plumbr.test;
public class HealMe {
private static final int SIZE = (int) (Runtime.getRuntime().maxMemory() * 0.6);
public static void main(String[] args) throws Exception {
for (int i = 0; i < 1000; i++) {
allocateMemory(i);
}
}
private static void allocateMemory(int i) {
try {
{
byte[] bytes = new byte[SIZE];
System.out.println(bytes.length);
}
byte[] moreBytes = new byte[SIZE];
System.out.println(moreBytes.length);
System.out.println("I allocated memory successfully " + i);
} catch (OutOfMemoryError e) {
System.out.println("I failed to allocate memory " + i);
}
}
}
上述代码会循环地分配两块内存。每次分配的内存都是堆中总内存的60%。由于在同一个方法内会不停地进行这个内存分配，因此你可能会认为这段代码会不断地抛出 java.lang.OutOfMemoryError: Java heap space异常，永远无法正常地执行完allocateMemory方法。
我们先来对源代码进行下静态分析，看看这种猜测是否恰当：
1. 乍看一下这段程序的话，这确实是无法成功执行的，因为要分配的内存已经超出了JVM的限制。
2. 但再仔细分析下的话我们会发现第一次分配是在一个块作用域内完成的，也就是说这个块中定义的变量仅对块内可见。这意味着这些内存在这个代码块执行完成后便可以回收掉了。这段代码一开始应该是可以成功执行的，只是当它再去尝试分配moreBytes的时候才会挂掉。
3. 如果再查看下编译后的class文件的话，你会看到如下的字节码：
private static void allocateMemory(int);
Code:
0: getstatic #3 // Field SIZE:I
3: newarray byte
5: astore_1
6: getstatic #4 // Field java/lang/System.out:Ljava/io/PrintStream;
9: aload_1
10: arraylength
11: invokevirtual #5 // Method java/io/PrintStream.println:(I)V
14: getstatic #3 // Field SIZE:I
17: newarray byte
19: astore_1
20: getstatic #4 // Field java/lang/System.out:Ljava/io/PrintStream;
23: aload_1
24: arraylength
25: invokevirtual #5 // Method java/io/PrintStream.println:(I)V
[*]--- cut for brevity ----
从中能够看出，第一个数组是在位置3～5处完成分配的，并存储到了序号为1的本地变量中。随后在位置17处，正要分配另一个数组。不过由于第一个数组仍被本地变量所引用着，因此第二次分配总会抛出OOM的异常而失败。字节码解释器不会允许GC去回收第一个数组，因为它仍然存在着一个强引用。
从静态代码分析中可看出，由于底层的两个约束，上述的代码是无法成功执行的，而在第一种情况下则是能够运行的。这三点分析里面哪个才是正确的呢？我们来实际运行下看看结果吧。结果表明，这些结论都是正确的。首先，应用程序的确无法分配内存。但是，经过一段时间之后（在我的Mac OS X上使用Java 8大概是出现在第255次迭代中），内存分配开始能够成功执行了:
java -Xmx2g eu.plumbr.test.HealMe 1145359564 I failed to allocate memory 0 1145359564 I failed to allocate memory 1 … cut for brevity ... I failed to allocate memory 254 1145359564 I failed to allocate memory 255 1145359564 1145359564 I allocated memory successfully 256 1145359564 1145359564 I allocated memory successfully 257 1145359564 1145359564 Self-healing code is a reality! Skynet is near...
为了搞清楚究竟发生了什么，我们得思考一下，在程序运行期间发生了什么变化？显然，Just-In-Time编译开始介入了。如果你还记得的话，JIT编译是JVM的一个内建机制，它可以优化热点代码。JIT会监控运行的代码，如果发现了一个热点，它会将你的字节码转化成本地代码，同时会执行一些额外的优化，譬如方法内联以及无用代码擦除。
我们打开下面的命令行参数重启下程序，看看是否触发了JIT编译。
[*]XX:+UnlockDiagnosticVMOptions -XX:+PrintAssembly -XX:+LogCompilation
这会生成一个日志文件，在我这里是一个hotspot_pid38139.log文件，38139是Java进程的PID。在该文件中可以找到这么一行：
<task_queued compile_id='94' method='HealMe allocateMemory (I)V' bytes='83' count='256' iicount='256' level='3' stamp='112.305' comment='tiered' hot_count='256'/>
这说明，在运行了256次allocateMemory()方法2之后，C1编译器决定将这个方法进行3级编译。看下这里可以了解下分层编译的各个级别以及不同的阈值。在前面的256次迭代中这段程序都是在解释模式下运行的，这里的字节码解释器就是一个简单堆栈机器，它无法提前预知某个变量后续是否会被用到，在这里对应的是变量bytes。但是JIT会一次性查看整个方法，因此它能推断出后面不会再用到bytes变量，可以对它进行GC。所以才会触发垃圾回收，因此我们的程序才能奇迹般地自愈。我只是希望本文的读者都不要在生产环境碰到调试这类问题的情况。不过如果你想让某人抓狂的话，倒是可以试试在生产环境中加下类似的代码。
原创文章转载请注明出处：http://it.deepinmind.com
英文原文链接