自恢复JVM

jopen 10年前

bd255d41018a00afa720f143c5a00c1c.jpg

我们有一个应用程序，它能够正确地恢复自己，而不是需要关闭并重启。刚开始时它出现错误，但是一段时间后开始平稳运行。为了给出一个这种应用程序的例子，我们从Heinz Kabutz的Java简讯上五年前的一篇文章中获取灵感，尽可能简单地重新构造出了如下的实例：

package eu.plumbr.test;   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. 如果我们仔细的检查就会注意到，第一次内存申请是在一个代码块中，它意味着这个代码块中定义的变量只在块中是可见的。这就表明，变量bytes在代码块结束时应该会被GC回收掉。所以，我们的代码实际上从一开始就能够正确运行，因为当尝试申请moreBytes内存时，前面申请的内存bytes应该已经被销毁了。
  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，开始申请另一个数组。但是第一个数组仍然被局部变量引用，因此第二次内存申请应该会因为内存溢出而一直失败。字节码解释器不能简单的让GC清除第一个数组，因为它仍然被引用。

我们的静态代码分析显示，由于两种潜在的原因上面的代码不应该成功运行；而在一种情况下，它应该成功运行。这3种情形中的哪一种是正确的呢？让我们运行代码来看看。结果表明，两种分析结果都是正确的。首先，应用程序申请内存失败了；但是过了一段时间后（在我的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...

为了理解实际上发生了什么，我们需要仔细思考：在程序执行过程中，什么变化了？当然，显而易见的发生了即时编译。如果你回想一下，即时编译是用来优化代码热点的一个JVM内置机制。JIT监视正在运行的代码，当监测到一个热点时，JIT将字节码编译成本地代码，并应用诸如内联方法与死代码消除等不同优化。

让我们打开下面的命令行选项并重新运行程序，来检查是否是这种可能：

 -XX:+UnlockDiagnosticVMOptions -XX:+PrintAssembly -XX:+LogCompilation

它将产生一个log文件，在我们的例子中是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'/>

这行内容说明，在执行allocateMemory()方法256次之后，C1编译器决定将这个方法放到C1第3级别编译的队列中。你可以在这里了解更多编译级别和不同阀值的信息。所以，前256次循环中是运行在解释器模式，即一个简单的基于栈的字节码解释器。它不能预先知道哪些变量是否会在将来被用到，比如我们的例子中的bytes。但是JIT一次检查整个方法，并推断出变量bytes不再被使用，能够被GC回收。因此垃圾回收终于出现，我们的程序神奇地自我恢复了。现在，我只希望读者们没有人正在实际的产品中调试类似的问题。但是如果你希望让某个人悲剧一次，把类似的代码加入到产品中将会是一个“靠谱的”方法。

原文链接： javacodegeeks 翻译： ImportNew.com - shenggordon
译文链接： http://www.importnew.com/14137.html