言必称希腊--浅谈对JVM GC垃圾回收的理解

在工作中遇到OutofMemoryError故障而去详细研究JVM垃圾回收的一些细节，从这段时间搜索到的一些文档来看，最后来看，还是Oracle上的资料，最显得有深度和专业。而其他获取的信息，都是支离破碎和语焉不详的，随便抄抄、转转。所以，就有点感叹，读书一定要读经典的书，看电影要看经典的电影，言必称希腊，在很多时候是很对的，而且是不应该鄙夷！特别是，当对方对这些经典的理解，不是很肤浅，不是那里做炫耀的资本，而是理解很准确，就应该认为人家走的路子很对。

JVM的GC垃圾回收将Heap分为新生代、长久保持代以及永久数据代，见图：



refer from:http://www.oracle.com/technetwork/java/gc1-4-2-135950.html#6.%20Conclusion|outline

按照对JVM垃圾回收粗浅的理解，
1.JVM GC认为JVM运行的程序，对象的生成和消失基本上新生代内完成，基本上不用在代与代之间移动或很少移动。

2.在新生代中经过几次小规模垃圾回收，释放不掉的Java对象则进入长久保持代；而那些class 信息和method objects信息则会在永久代中存在；各个代各有不同的职责。

当读到此处的时间，对于no perm heap的OutofMemory，在大的应用下，最大可以64M的Heap，应该是基本上很少见的

3.每个Heap代都有自己的垃圾回收器，回收的条件为代所属的Heap内存都已经满的条件。通过JProfile观察Java程序也可以看到在内存猛然满的时间，突然间内存就通过垃圾回收消失了，可以作为明证。在垃圾回收的这段时间内，整个程序被冰冻,freezing状态，会有少许的OverHead等待时间。

所以，虽然你可以扩大新生代Heap的值，使得程序很大部分的对象的生成的消失基本在新生代的中完成，但是，在极端的场景下，例如垃圾回收时大多数对象不能死亡，(是否会出现取决于权衡和对程序进行实验)，也会因内存拷贝和移动，造成更长的OverHead。

4.网上经常讲-xms和-Xmx，如果设置成一样的话，会有什么样的结果？在Oracle的标准文档中给予了这样的说明。完成的是，代的自由内存Free Space的量比，最终导致Heap代的整体内存增长和缩小而已，而增长的上界和减小的下界为JVM，设置成为一样就有可能禁止掉这样的Sizing过程。

原文： Setting -Xms and -Xmx to the same value increases predictability by removing the most important sizing decision from the virtual machine. On the other hand, the virtual machine can't compensate if you make a poor choice.

这些文档都特别地说明了垃圾回收不属于JVM规范限定的范围，所以，有可能遭遇变化，也是需要注意的。不过，在此可见，JVM规范在此地也是玩了一个抽象。只要求你能够做到垃圾回收，如果做到，则允许变化！这样的对待方式，然后就支持了不同的垃圾回收可能的设计。 但是，从计算机界一贯发展来看，很多发展或创造是殊途同归了，最后总是不免就几种而已了:) 也不会多的让你挑花了眼，选不过来，呵呵！

回想起以前为了了解JavaScript的一些机制，而去阅读Ecma的规范:) 言必称希腊，并不是错误，还很值得推尚。

引用或参考文档：
//JVM debug option
http://www.oracle.com/technetwork/java/javase/tech/vmoptions-jsp-140102.html#DebuggingOptions

http://www.oracle.com/technetwork/java/javase/tech/index-jsp-136373.html

jvm虚拟机内存的分布
http://www.oracle.com/technetwork/java/gc1-4-2-135950.html#6.%20Conclusion|outline

gc
http://www.oracle.com/technetwork/java/faq-140837.html