GC日志详解

前言

在日常开发或生产环境中，我们会经常遇到OOM。对于OOM，大伙的第一反应就是内存不够了，赶紧加内存。殊不知，有时候就是这简单的加内存，就会在我们的生产环境中埋下一颗雷，说不定哪天就爆了。。当然也有可能人品爆发，短时间相安无事。当然谁也不想自己的项目中会有颗雷。对于OOM往往是我们的代码中出现了内存泄露，日积月累最终导致了OOM，（当然也有可能确实是jvm内存分配不合理导致的）。所以我们需要找到内存泄漏的根本原因。这样才能在源头上避免OOM的再次发生。但是代码又不会主动告诉你，他在哪里发生内存泄漏了，所以我们需要通过GC日志和工具来分析代码中出现内存泄漏的地方。这里来和大家一起学习下如果配置GC日志，以及对GC日志的一些简单介绍。

如何配置GC日志

对于Tomcat，我们可以在catalina.bat(linux下是catalina.sh)中设置VM的arguments来打印输出GC日志。在catalina.bat的开始位置配置

-Xms512m -Xmx1028m -XX:MaxNewSize=512m -XX:MaxPermSize=1028m -XX:+PrintGCTimeStamps  
-XX:+PrintGCDetails  -verbose:gc  -Xloggc:d:/gc.log

如下图

常见的参数如下

    -Xms --jvm堆的最小值
    -Xmx --jvm堆的最大值
    -XX:MaxNewSize  --新生代最大值
    -XX:MaxPermSize=1028m  --永久代最大值
    -XX:+PrintGCTimeStamps 输出GC的时间戳（以基准时间的形式）
    -XX:+PrintGCDateStamps 输出GC的时间戳（以日期的形式，如 2013-05-04T21:53:59.234+0800）
    -XX:+PrintGCDetails  --打印出GC的详细信息
    -verbose:gc --开启gc日志
    -Xloggc:d:/gc.log -- gc日志的存放位置
    -Xmn -- 新生代内存区域的大小
    -XX:SurvivorRatio=8 --新生代内存区域中Eden和Survivor的比例

当然在eclispe等其他开发工具中也是可以配置GC日志的。

如何分析GC日志

下图中是我截取的JVM刚启动的一部分GC日志

我们可以看到图中第一行红色，是项目的配置参数。这里不仅配置了打印GC日志，还有相关的VM内存参数。
第二行中的是在这个GC时间点发生GC之后相关GC情况。
1. 对于3.836 这是具体发生GC的时间点。这是时间戳是从jvm启动开始计算的，我们也可以用PrintGCDateStamps 来打印时间日期格式的时间。
2. PSYoungGen是指GC发生的区域，其实应该还有一个ParOldGen，（因为JVM刚启动没有触发老年代的GC，所以日志上没有展示ParOldGen）分别代表使用Parallel Scavenge垃圾收集器的新生代和使用Parallel old垃圾收集器的老生代。为什么是这两个垃圾收集器组合呢？因为我的jvm开启的模式是Server，而Server模式的默认垃圾收集器组合便是这个，在命令行输入java -version就可以看到自己的jvm默认开启模式。还有一种是client模式，默认组合是Serial收集器和Serial Old收集器组合。
3. 153598K->21501K(153600K),这三个数字分别对应GC之前占用年轻代的大小，GC之后年轻代占用，以及整个年轻代的大小。
4. 159516K->37430K(503296K),这三个数字分别对应GC之前占用堆内存的大小，GC之后堆内存占用，以及整个堆内存的大小。
5. 0.0209017是该时间点GC占用耗费时间。
上面的这些参数，能够帮我们查看分析GC的垃圾收集情况。但是如果GC日志很多很多，成千上万行。就算你一目十行，看完了，脑子也是一片空白。所以我们可以借助一些功能来帮助我们分析，这里推荐一个gceasy,可以上传gc文件，然后他会利用可视化的界面来展现GC情况。具体下图所示

上图我们可以看到年轻代，老年代，以及永久代的内存分配，和最大使用情况。

上图我们可以看到堆内存在GC之前和之后的变化，以及其他信息。

总结

上面是简单介绍了GC日志的配置和分析，我们也可以用jdk自带的一些命令来查看内存和GC情况，例如jconsole,jmap。。。小伙伴们可以自己去尝试尝试。