标签：http ar io os 使用 sp for java on
在IT行业，碰到问题的第一个反应通常是——“你重启过没”——而这样做可能会适得其反，本文要讲述的就是这样的一个场景。
接下来要介绍的这个应用，它不仅不需要重启，而且毫不夸张地说，它能够自我治愈：刚开始运行的时候它可能会碰到些挫折，但会渐入佳境。为了能实际地展示出它的自愈能力，我们尽可能简单地重现了这一场景，这个灵感还得归功于五年前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方法。
我们先来对源代码进行下静态分析，看看这种猜测是否恰当：
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
java/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
java/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 ar io os 使用 sp for java on
原文地址：http://www.cnblogs.com/guscode/p/4168744.html
