打印日志

　　通过加入 -XX:+PrintGCDetails 参数则可以打印详细GC信息至控制台。参数-verbose:gc也是可以，但不够详细。通过加入-XX:+PrintGCDateStamps则可以记录GC发生的详细时间。通过加入 -Xloggc:/home/XX/gc/app_gc.log。可以把GC输出至文件，这对长时间服务器GC监控很有帮助。通过加入-XX:+DisableExplicitGC可以将System.gc()转为空操作。

日志分析

ParNew

　　通过加入-XX:+UseParNewGC参数指定新生代使用ParNew垃圾收集器。

2017-12-19T15:45:31.518-0800: 0.218: [GC (Allocation Failure) 2017-12-19T15:45:31.518-0800: 0.218: [ParNew: 31031K->4351K(39296K), 0.2660674 secs] 31031K->22453K(126720K), 0.2661635 secs] [Times: user=0.59 sys=0.05, real=0.27 secs]

　　2017-12-19T15:45:31.518-0800　GC发生的时间。　Allocation Failure表示gc的原因；ParNew表示是ParNew新手代收集器；31031K表示GC前的年轻代大小； 4351K表示GC后的年轻代大小；39296K年轻代的总大小。0.2660674本次回收的时间。

Parallel Scavenge

2017-12-18T20:54:09.544-0800: 2.988: [GC (Allocation Failure) [PSYoungGen: 33280K->400K(38400K)] 33280K->408K(125952K), 0.0008640 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]

　　2017-12-18T20:54:09.544-0800 GC发生的时间。Allocation Failure表示gc的原因；PSYoungGen 表示是Parallel Scavenge新时代收集器；33280K 表示GC前的年轻代大小； 400K表示GC后的年轻代大小；38400K年轻代的总大小。33280K表示GC前的堆大小；408K表示GC后的堆大小；125952K表示堆的总大小0.0008640本次回收的时间。Times: user=0.00 sys=0.00, real=0.00 secs，表示内核执行用户时间，系统调用时间，和总时间。

CMS

　　通过加入-XX:+UseConcMarkSweepGC参数指定老年代使用CMS垃圾收集器。

2017-12-19T16:08:32.961-0800: 11.052: [GC (CMS Initial Mark) [1 CMS-initial-mark: 26710K(87424K)] 28716K(126720K), 0.0017267 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]

2017-12-19T16:08:32.962-0800: 11.054: [CMS-concurrent-mark-start]

2017-12-19T16:08:33.041-0800: 11.133: [CMS-concurrent-mark: 0.079/0.079 secs] [Times: user=0.06 sys=0.01, real=0.08 secs]

2017-12-19T16:08:33.041-0800: 11.133: [CMS-concurrent-preclean-start]

2017-12-19T16:08:33.043-0800: 11.134: [CMS-concurrent-preclean: 0.002/0.002 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]

2017-12-19T16:08:33.043-0800: 11.134: [CMS-concurrent-abortable-preclean-start]

2017-12-19T16:08:33.555-0800: 11.647: [CMS-concurrent-abortable-preclean: 0.075/0.512 secs] [Times: user=0.15 sys=0.01, real=0.51 secs]

2017-12-19T16:08:33.555-0800: 11.647: [GC (CMS Final Remark) [YG occupancy: 1939 K (39296 K)]2017-12-19T16:08:33.555-0800: 11.647: [Rescan (parallel) , 0.0038080 secs]2017-12-19T16:08:33.559-0800: 11.651: [weak refs processing, 0.0000223 secs]2017-12-19T16:08:33.559-0800: 11.651: [class unloading, 0.0002446 secs]2017-12-19T16:08:33.560-0800: 11.651: [scrub symbol table, 0.0004310 secs]2017-12-19T16:08:33.560-0800: 11.651: [scrub string table, 0.0001471 secs][1 CMS-remark: 32503K(87424K)] 34443K(126720K), 0.0047693 secs] [Times: user=0.01 sys=0.00, real=0.01 secs]

2017-12-19T16:08:33.560-0800: 11.652: [CMS-concurrent-sweep-start]

2017-12-19T16:08:33.572-0800: 11.663: [CMS-concurrent-sweep: 0.011/0.011 secs] [Times: user=0.01 sys=0.00, real=0.01 secs]

2017-12-19T16:08:33.572-0800: 11.663: [CMS-concurrent-reset-start]

2017-12-19T16:08:33.576-0800: 11.668: [CMS-concurrent-reset: 0.004/0.004 secs] [Times: user=0.01 sys=0.00, real=0.00 secs]

1.第一阶段 初始标记

　　2017-12-19T16:08:32.961-0800: 11.052 CMS Initial Mark的开始时间。CMS Initial Mark：收集阶段，开始收集所有的GC Roots和直接引用到的对象；26710K当前老年代的使用容量；87424K老年代的总容量；28716K当前堆的使用容量；126720K当前堆的总容量；0.0017267 secs执行时间。

2.第二阶段 并发标记

　　这个阶段会遍历整个老年代并且标记所有存活的对象，并发标记的特点是和应用程序线程同时运行。

　　2017-12-19T16:08:32.962-0800: 11.054并发标记时间；CMS-concurrent-mark-start并发标记开始；CMS-concurrent-mark: 0.079/0.079 secs并发标记执行时间；

3.第三阶段 并发重新标记

　　前一个阶段在并行运行的时候，一些对象的引用已经发生了变化，在这个阶段，那些能够对那些对象到达的对象标记。

　　2017-12-19T16:08:33.041-0800: 11.133 并发重新标记时间； CMS-concurrent-preclean-start并发重新标记开始标志； CMS-concurrent-preclean: 0.002/0.002 secs并发重新标记执行时间。

4.第四阶段 并发重复标记

　　这个阶段是重复的做相同的事情直到发生aboart的条件。

　　2017-12-19T16:08:33.043-0800: 11.134: 并发重新标记时间；CMS-concurrent-abortable-preclean-start并发重新标记开始标志； CMS-concurrent-abortable-preclean: 0.075/0.512 secs并发重新标记执行时间。

5.第五阶段 最终标记

　　该阶段的任务是完成标记整个年老代的所有的存活对象。

　　2017-12-19T16:08:33.555-0800: 11.647: 并发重新标记时间；CMS Final Remark 最终标记； YG occupancy: 1939 K (39296 K) 年轻代当前占用容量情况；

　　2017-12-19T16:08:33.555-0800: 11.647: [Rescan (parallel) , 0.0038080 secs] 这个阶段，应用停止，完成最终标记

　　2017-12-19T16:08:33.559-0800: 11.651: [weak refs processing, 0.0000223 secs] 第一个子阶段；

　　2017-12-19T16:08:33.559-0800: 11.651: [class unloading, 0.0002446 secs] 第二个子阶段；

　　2017-12-19T16:08:33.560-0800: 11.651: [scrub symbol table, 0.0004310 secs]第三个子阶段

　　2017-12-19T16:08:33.560-0800: 11.651: [scrub string table, 0.0001471 secs]第四个子阶段

　　[1 CMS-remark: 32503K(87424K)] 34443K(126720K), 0.0047693 secs] [Times: user=0.01 sys=0.00, real=0.01 secs]

6.第六阶段 并发清理

　　这个阶段的目的就是移除那些不用的对象。

　　2017-12-19T16:08:33.560-0800: 11.652:清理的时间；[CMS-concurrent-sweep-start] 开始清理标志

　　 2017-12-19T16:08:33.572-0800: 11.663:清理的时间  [CMS-concurrent-sweep: 0.011/0.011 secs]  清理花费的时间[Times: user=0.01 sys=0.00, real=0.01 secs]

7.第七阶段 重置

　　重新设置CMS算法内部的数据结构，准备下一个CMS生命周期的使用。

　　2017-12-19T16:08:33.572-0800: 11.663: [CMS-concurrent-reset-start]

　　2017-12-19T16:08:33.576-0800: 11.668: [CMS-concurrent-reset: 0.004/0.004 secs] [Times: user=0.01 sys=0.00, real=0.00 secs]

　　

Full GC

2017-12-19T14:20:21.524-0800: 0.745: [Full GC (Ergonomics) [PSYoungGen: 5120K->0K(71680K)] [ParOldGen: 98922K->96623K(207872K)] 104042K->96623K(279552K), [Metaspace: 2635K->2635K(1056768K)], 0.8495748 secs] [Times: user=1.81 sys=0.04, real=0.85 secs]

　　2017-12-19T14:20:21.524-0800: 0.745: GC发生的时间。PSYoungGen 表示是Parallel Scavenge新时代收集器；5120K表示GC前的年轻代大小； 0K表示GC后的年轻代大小； 71680K年轻代的总大小。ParOldGen表示是Parallel Old收集器；98922K表示GC前的老年代大小；96623K表示GC前的老年代大小；207872K表示老年代总大小；104042K表示GC前的总大小；96623K表示GC后的总大小；279552K表示总大小；

java虚拟机小贴士之GC分析的更多相关文章

  1. java虚拟机(十二)--可视化工具分析GC日志

    在上篇博客中,我们学习了Parallel.CMS.G1三种垃圾收集器的日志格式,本次我们通过工具去分析日志,会更加的直观 日志格式博客地址:java虚拟机(十一)--GC日志分析 GCeasy: 这是 ...

  2. 深入理解JAVA虚拟机（内存模型+GC算法+JVM调优）

    目录 1.Java虚拟机内存模型 1.1 程序计数器 1.2 Java虚拟机栈 局部变量 1.3 本地方法栈 1.4 Java堆 1.5 方法区(永久区.元空间) 附图 2.JVM内存分配参数 2.1 ...

  3. 《深入理解Java虚拟机》调优案例分析与实战

    上节学习回顾 在上一节当中,主要学习了Sun JDK的一些命令行和可视化性能监控工具的具体使用,但性能分析的重点还是在解决问题的思路上面,没有好的思路,再好的工具也无补于事. 本节学习重点 在书本上本 ...

  4. Java虚拟机三：OutOfMemoryError异常分析

    根据Java虚拟机规范,虚拟机内存中除过程序计数器之外的运行时数据区域都会发生OutOfMemoryError(OOM),本文将通过实际例子验证分析各个数据区域OOM的情况.为了更贴近生产,本次所有例 ...

  5. 大战Java虚拟机【2】—— GC策略

    前言 前面我们已经知道了Java虚拟机所做的事情就是回收那些不用的垃圾,那些不用的对象.那么问题来了,我们如何知道一个对象我们不需要使用了呢?程序在使用的过程中会不断的创建对象,这些所创建的对象指不定 ...

  6. 【转载】Java虚拟机类加载机制与案例分析

    出处:https://blog.csdn.net/u013256816/article/details/50829596 https://blog.csdn.net/u013256816/articl ...

  7. 深入理解Java虚拟机(六)——JVM调优分析与实战

    大内存硬件上的程序部署策略 单个虚拟机管理大内存 出现问题 如果JVM中的堆内存太小,就会频繁地出发GC,而每次GC会将用户线程暂停,所以,频繁地GC会导致长时间的停顿.如果扩大计算的内存的大小,就能 ...

  8. java虚拟机学习总结之GC回收算法与GC收集器

    GC回收算法 1.标记清除算法分为标记阶段和清除阶段标记阶段:通过特定的判断方式找出无用的对象实例并将其标记清除阶段:将已标记的对象所占用的内存回收缺点:运行多次以后容易产生空间碎片,当需要一整段连续 ...

  9. （一）深入java虚拟机之内存溢出与分析

    一.内存溢出程序 public class Test { public static void main(String[] args) { List<User> userList=new ...

随机推荐

  1. 手机APP无法抓包(无法连接服务器)

    一. 把证书放到系统信任区 前提:手机已root 详细步骤 计算证书名 openssl x509 -subject_hash_old -in charles-ssl-proxying-certific ...

  2. SSM框架环境搭建

    SSM基础环境搭建 创建maven工程 next,finish,等待创建完成,创建完成后,src/main下只有webapp文件夹,我们需要手动创建java和resources,鼠标右击main,ne ...

  3. Docker 最常用的镜像命令和容器命令

    本文列出了 Docker 使用过程中最常用的镜像命令和容器命令,以及教大家如何操作容器数据卷,实现容器数据的备份.熟练练习这些命令以后,再来一些简单的应用部署练习,大家就可以学习 Docker 的镜像 ...

  4. Mysql 如何实现全文检索，关键词跑分

    一.前言 今天一个同事问我,如何使用 Mysql 实现类似于 ElasticSearch 的全文检索功能,并且对检索关键词跑分?我当时脑子里立马产生了疑问?为啥不直接用es呢?简单好用还贼快.但是听他 ...

  5. 贪心思想之区间贪心 关联洛谷P1803

    力扣上也有一道类似的题 几乎是一样 输出不同 → 力扣leetcode 435. 无重叠区间 区间贪心是比较经典的 就拿洛谷P1803来举例 题目大意 n个比赛 [开始时间,结束时间] 问一个人最多能 ...

  6. Istio可观测性

    Istio可观测性 Istio的可观测性包括metrics,日志,分布式链路跟踪以及可视化展示.下面主要介绍如何在istio中部署基于Prometheus的metrics监控,基于jaeger的链路跟 ...

  7. Webpack 入门指迷

    大概算是一份教程吧, 只不过效果肯定不如视频演示之类的好..Webpack 最近在英文社区上经常看到, 留了心, 但进一步了解是通过下边的视频:视频: How Instagram.com Works, ...

  8. 反射机制(Java)

    反射机制 今天闲来无事,对反射机制http://www.cnblogs.com/jqyp/archive/2012/03/29/2423112.html阅读一番,整理了下这方面的知识以及自己的一些心得 ...

  9. 10.redis cluster介绍与gossip协议

    一.redis cluster 介绍 自动将数据进行分片,每个 master 上放一部分数据 提供内置的高可用支持,部分 master 不可用时,还是可以继续工作的 redis cluster架构下的 ...

  10. Spark应用开发-关联分析

    在机器学习中,常用的主题有分类,回归,聚类和关联分析.而关联分析,在实际中的应用场景,有部分是用于商品零售的分析.在Spark中有相应的案例 在关联分析中,有一些概念要熟悉. 频繁项集,关联规则,支持 ...