jvm 从GC日志分析堆内存

  在前面的文章中，我们只设置了整个堆的内存大小。但是我们知道，堆又分为了新生代，年老代。他们之间的内存怎么分配呢？新生代又分为Eden和Survivor，他们的比例大小能改变吗？其实这些都是可控的，以前没有讲到是因为就算讲了也只是讲讲而已，看不到实质性的东西。因此这章我们通过分析GC日志来一步步讲解如何细化设置堆内存。

  首先我们来了解几个相关的参数：

• -XX:+PrintGCDetails：用于告诉虚拟机回收垃圾的时候顺便打印日志
• -Xloggc:路径 ：将打印出来的日志信息保存至指定的路径
• -Xmn10M：设置新生代的内存大小

• -XX:SurvivorRatio=8:1调整Eden和Survivor的比例为8:1
    我们还是用前面的代码例子来讲:

    然后用参数-Xms20m -Xmx20m -Xmn10
  -XX:+PrintGCDetails -Xloggc:d:\gc1.log启动。表示给堆分配20M，给新生代分配10M，打印GC日志，并将其输出至D盘的gc1.log文件中。运行后得到以下日志，这是第一部分：

    现在我们来分析下每个部分代表的含义：

• 0.090：就是虚拟机从启动到现在经历的时间。

• GC：指的是停顿类型（留着下一章讲）
• PSYoungGen：发生GC的区域，这里指的是年轻代。根据收集器的种类而定。
• 7284K->1016K(9216K)：该区域GC前当前区域所使用的容量–>该区域GC后已使用的容量（该区域的总容量），也就是新生代的容量。
• 7284K->6139K(19456K)：整个堆GC前当前区域所使用的容量–>整个堆GC后已使用的容量（整个堆的总容量）。

• 0.0078481：这次GC所占用的时间。

    我们再来看看第二部分：
  

    看图画红线部分，表示当前的堆中新生代可用内存的大小（一个eden和一个Survivor视为可用内存），红色框下面则是年老区的大小，加上一共是20m,符合我们所设置的。

    红色框的部分则是新生代中eden区和两个Survivor区的大小，可以看出他们的比例是8：1，如果设置为-XX:SurvivorRatio=3的话，结果如下

    到这里以上几个参数的作用以及分析就讲完啦，小伙伴们可以打开自己的工具试一试，感受一下。以后碰到了内存泄漏或者内存不足的话就可以直接查看日志来进行分析调优了！

Stop The World

什么是停顿类型！经过前几章的学习，我们知道垃圾回收首先是要经过标记的。对象被标记后就会根据不同的区域采用不同的收集方法。看上去很完美的一件事情，其实并不然。

  大家有没有想过一件事情，当虚拟机完成两次标记后，便确认了可以回收的对象。但是，垃圾回收并不会阻塞我们程序的线程，他是与当前程序并发执行的。所以问题就出在这里，当GC线程标记好了一个对象的时候，此时我们程序的线程又将该对象重新加入了“关系网”中，当执行二次标记的时候，该对象也没有重写finalize()方法，因此回收的时候就会回收这个不该回收的对象。

  虚拟机的解决方法就是在一些特定指令位置设置一些“安全点”，当程序运行到这些“安全点”的时候就会暂停所有当前运行的线程（Stop The World 所以叫STW），暂停后再找到“GC Roots”进行关系的组建，进而执行标记和清除。

  这些特定的指令位置主要在：

• 循环的末尾
• 方法临返回前 / 调用方法的call指令后

• 可能抛异常的位置

    找到“GC Roots”也是要花很长的时间，然而这里又有新的解决方法，就是通过采用一个OopMap的数据结构来记录系统中存活的“GC Roots”，在类加载完成的时候，虚拟机就把对象内什么偏移量上是什么类型的数据计算出来保存在OopMap，通过解释OopMap就可以找到堆中的对象，这些对象就是GC Roots。而不需要一个一个的去判断某个内存位置的值是不是引用。这种方式也叫准确式GC。

    回到最开始的问题，那个停顿类型就是刚刚所说的STW，至于有GC和Full GC之分，还有Full GC (System)。个人认为主要是Full GC时STW的时间相对GC来说时间很长，因为Full GC针对整个堆以及永久代的，因此整个GC的范围大大增加；还有就是他的回收算法就是我们之前说过的“标记–清除–整理”，这里也会损耗一定的时间。所以我们在优化JVM的时候，减少Full GC的次数也是经常用到的办法。