189 8069 5689
这篇文章将为大家详细讲解有关打印GC日志排查问题怎么解决，文章内容质量较高，因此小编分享给大家做个参考，希望大家阅读完这篇文章后对相关知识有一定的了解。
创新互联建站是一家集网站建设,阳朔企业网站建设,阳朔品牌网站建设,网站定制,阳朔网站建设报价,网络营销,网络优化,阳朔网站推广为一体的创新建站企业，帮助传统企业提升企业形象加强企业竞争力。可充分满足这一群体相比中小企业更为丰富、高端、多元的互联网需求。同时我们时刻保持专业、时尚、前沿，时刻以成就客户成长自我，坚持不断学习、思考、沉淀、净化自己，让我们为更多的企业打造出实用型网站。
在工作当中，有时候我们会需要打印GC的相关信息来定位问题。该如何做呢？
先来看个示例，
public static void main(String[] args) {
List list0 = new ArrayList<>();
long start0 = System.currentTimeMillis();
for (int i = 0; i < 1000000; i++) {
list0.add(i);
}
System.out.println("cost: " + (System.currentTimeMillis() - start0));
List list1 = new ArrayList<>();
long start1 = System.currentTimeMillis();
for (int i = 0; i < 1000000; i++) {
list1.add(i);
}
System.out.println("cost: " + (System.currentTimeMillis() - start1));
}
直接运行，结果如下，
cost: 135
cost: 85
你应该觉得奇怪，同样的往一个list插入100万条数据，为啥第一个耗时比较久？
这种时候，有经验的工程师应该能马上怀疑是GC的问题，我们可以通过在运行时添加JVM参数来打印程序运行时的GC情况。
-XX:+PrintGCDetails
如果是使用IDEA来运行，可以在 run configurations 的 VM options添加上面的参数即可。
再次运行，输出如下，
[GC (Allocation Failure) [PSYoungGen: 1536K->512K(1536K)] 1884K->1234K(262144K), 0.0009030 secs] [Times: user=0.01 sys=0.00, real=0.00 secs]
[GC (Allocation Failure) [PSYoungGen: 1302K->1017K(2560K)] 2025K->1948K(263168K), 0.0012290 secs] [Times: user=0.01 sys=0.01, real=0.01 secs]
[GC (Allocation Failure) [PSYoungGen: 2553K->1504K(3072K)] 3484K->3051K(263680K), 0.0017210 secs] [Times: user=0.02 sys=0.00, real=0.00 secs]
[GC (Allocation Failure) [PSYoungGen: 3040K->2033K(4608K)] 4587K->4228K(265216K), 0.0023170 secs] [Times: user=0.02 sys=0.00, real=0.00 secs]
[GC (Allocation Failure) [PSYoungGen: 4593K->2560K(5120K)] 8195K->6681K(265728K), 0.0249700 secs] [Times: user=0.31 sys=0.00, real=0.03 secs]
[GC (Allocation Failure) [PSYoungGen: 5120K->3584K(6656K)] 11352K->11408K(267264K), 0.0241680 secs] [Times: user=0.30 sys=0.01, real=0.03 secs]
[GC (Allocation Failure) [PSYoungGen: 6656K->3296K(7680K)] 17645K->17909K(268288K), 0.0349010 secs] [Times: user=0.45 sys=0.00, real=0.03 secs]
[GC (Allocation Failure) [PSYoungGen: 6368K->3328K(10240K)] 25729K->25825K(270848K), 0.0314260 secs] [Times: user=0.40 sys=0.00, real=0.03 secs]
cost: 137
[GC (Allocation Failure) [PSYoungGen: 8166K->4469K(10240K)] 30663K->30103K(270848K), 0.0285370 secs] [Times: user=0.36 sys=0.01, real=0.03 secs]
[GC (Allocation Failure) [PSYoungGen: 9166K->3785K(13312K)] 34800K->33427K(273920K), 0.0226780 secs] [Times: user=0.28 sys=0.01, real=0.02 secs]
[GC (Allocation Failure) [PSYoungGen: 11465K->6142K(13824K)] 41107K->38511K(274432K), 0.0065540 secs] [Times: user=0.08 sys=0.00, real=0.00 secs]
[GC (Allocation Failure) [PSYoungGen: 13822K->7837K(19456K)] 46191K->44246K(280064K), 0.0099720 secs] [Times: user=0.11 sys=0.01, real=0.01 secs]
cost: 79
所以你大概明白了，第一次minor gc的次数比第二次多，所以运行时间比较长。
那么上面打印出来的日志，具体是什么意思呢？已经有人画出了很详细的图，我借来用下，
了解GC日志的打印方法，并且能看懂GC日志，对于查找定位问题非常有帮助的。
我自己就遇到过生产上一个CPU飙到好几百的情况，打印GC日志发现 JVM 一直在 fullGC，而且每次GC之后内存基本没有变化，从而定位到应用程序可能存在内存泄漏的问题。