自恢复JVM

对任意一个的IT问题,我们想到的第一个解决方案就是,“你试着关掉并重新启动了吗?”。本文就是关于这样一种应用程序的例子,它说明采用上述解决方案可能会适得其反,弊大于利。

我们有一个应用程序,它能够正确地恢复自己,而不是需要关闭并重启。刚开始时它出现错误,但是一段时间后开始平稳运行。为了给出一个这种应用程序的例子,我们从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
[ 转载请保留原文出处、译者和译文链接。]



相关文章

发表评论

Comment form

(*) 表示必填项

还没有评论。

跳到底部
返回顶部