【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是如何处理的，目前还没搞懂。但是这种轻微的变化，无需怀疑自己的代码，当然，我们可以通过长时间的跟踪作进一步的了解。