【Developer Log】Java VM的不明机制

在之前的【Developer Log】Java的内存使用、垃圾回收和内存泄漏中，我们通过长时间的大压测试探究了VM的GC机制，重点观察了Old Gen。然而在长时间的测试中，我们发现在jdk8的MetaSpace，或者在jdk7的Perm Gen中观察到随着时间有增长，虽然增长量很少很少，但是的确在增长。

这是个很头疼的问题，所以觉得另外写个小程序确认一下。程序很简单：

public class Main { 
     private static void permTest(String[] args){ 
         Utils.showInfo("Try to explore Perm Gen or MetaSpace");  //就是在Console上打出一行字。
         while(true){  
             try{ 
                 //Thread.sleep(100);     //TEST1采用了100ms的步进方式 
                 Thread.sleep(100000);   //TEST2采用了100s的步进方式 
             }catch(Exception e){ 
                 e.printStackTrace(); 
             } 
         } 
     } 

     public static void main(String[] args) {  
         permTest(args); 
     } 
 }

Anyway，这是个很简单的程序，就是不断地做一个sleep()的循环。在运行的过程中，没有新的对象的创建，只是不断地调用Thread的静态方法sleep()。

在java7的运行环境下，通过jvisualvm，我们也观察到了PermGen缓慢上涨的现象。

在这个图中，我们看到了类的轻微上涨，而Perm Gen则不明显。我们通过probe将数据导出来，在xls中做了下面这张图。

这样看就比较显著了。It's amazing. Why? 我们在来看看下面的数据，这是TEST1和TEST2种对GC的监控图的截取：

我们对比Test1和Test2，我们并没有创新新的对象，而是使用Thread的静态方法sleep()，按理没有什么新的空间需求，特别是Test2，时间间隔很长，但是一样有Eden Space的消耗。

实际上，我们监控的并不是我们的程序，而是VM如何运行我们的呈现，需要将VM的处理考虑进去。VM的处理影响了Eden Space和Perm Gen空间的分配。之于VM是如何处理的，目前还没搞懂。但是这种轻微的变化，无需怀疑自己的代码，当然，我们可以通过长时间的跟踪作进一步的了解。