GCViewer

1、问题发现 Prometheus报警live服务的某个节点Old GC过多，需要排查。 2、问题分析 查看Prometheus，发现这个节点在11点18分到11点28分，仅仅10分钟内，进行了5次Full GC，根据经验（这样说可能有点扯淡），应该是某个特定接口导致的。 3、使用GCViewer分析GC日志 从图中可以看到，在发生Full GC的时间段内，老年代的使用不到200M，老年代的总大小为760多M。很显然，这个不是由于内存不够导致的。 ###4、查看GC原因 可以看到5次GC的原因都是 System.gc() ，说明代码中调用了方法 System.gc() （当然可能是业务同学自己写的代码，也可能是依赖包中的）。 ###5、在ELK中查看该服务在该时间段内的调用情况 ELK日志显示可能是导出Excel导致（历史原因：严格来讲，线上服务不应该提供这种导出功能，这部分功能正在慢慢向大数据团队迁移，但是还没迁移完） 6、查看代码 根据日志信息查看代码发现确实是导出Excel操作导致，依赖包中的 jxl.read.biff.WorkbookParser 类中，强制使用了方法 System.gc() 进行GC。 来源： oschina 链接： https://my.oschina.net/u/4344027/blog/3393626

开发过程中，经常需要对GC的垃圾收集器参数不断的进行动态调整，从而更充分的压榨机器性能，提升应用效率。本文将从常见的Parallel/G1垃圾收集器的GC日志着手，分析GC日志的具体含义，以及示范如何根据GC日志调整参数。 1. 准备工作 (1) VM Options 应用程序需要设置如下参数，以便将GC信息数值至gc.log文件中，供后续分析。 -XX:+DisableExplicitGC -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=./logs -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintGCDateStamps -Xloggc:./logs/gc.log (2) GC统计工具 为了更好的统计GC日志信息，我们将借助于GCViewer桌面软件(开源，地址为： https://github.com/chewiebug/GCViewer )，下载之后执行 maven clean package -Dmaven.test.skip=true 即可完成程序的编译，双击target文件夹下的gcviewer-1.36-SNAPSHOT.jar（具体名称由下载的GCViewer版本确定）即可执行程序。 原GCViewer于2008年后停止维护

在上篇博客中，我们学习了Parallel、CMS、G1三种垃圾收集器的日志格式，本次我们通过工具去分析日志，会更加的直观 日志格式博客地址： java虚拟机(十一)--GC日志分析 GCeasy： 这是一个在线分析日志的工具，主要功能是免费的，存在部分收费，地址： https://gceasy.io/ 把上篇博客生成的日志文件，上传分析，就会接到可视化界面 文件名：Parallel.gc.log，持续时间：6s，可以下载，分享 jvm堆： Allocated：各部分分配大小 Peak：峰值内存使用量 关键绩效指标： 吞吐量：93.769%，运行应用程序的时间/(GC时间的比值+运行应用程序的时间) 平均GC停顿时间 最大GC停顿时间 GC停顿持续时间范围：时间范围、GC数量、百分百 交互式图表： 左边菜单有很多： GC之前的堆、GC之后的堆、GC持续时间、GC停顿持续时间、回收的内存字节、Young区内存变化、Old区内存变化、Metaspace内存变化、分配对象大小、对象从Young到Old内存大小变化 后序的内容有：GC统计信息、Minor GC/Full GC信息、内存泄漏、GC的原因等等，所以这个工具的功能真的很强大 我们可以对比一下，Parallel、CMS、G1的GC效率 GCViewer 这个工具为web功能，下载过后通过maven进行打包，地址： https:/

java -jar gcviewer-1.36-SNAPSHOT.jar D:\BaiduNetdiskDownload\gp-jvm\gc.log 使用说明 来源： oschina 链接： https://my.oschina.net/u/3847203/blog/4254241

-XX:+PrintGC 输出GC日志 -XX:+PrintGCDetails 输出GC的详细日志 -XX:+PrintGCTimeStamps 输出GC的时间戳（以基准时间的形式） -XX:+PrintGCDateStamps 输出GC的时间戳（以日期的形式，如 2013-05-04T21:53:59.234+0800） -XX:+PrintHeapAtGC 在进行GC的前后打印出堆的信息 -Xloggc:../logs/gc.log 日志文件的输出路径 GC日志分析工具 https://github.com/chewiebug/GCViewer 来源： oschina 链接： https://my.oschina.net/u/4353161/blog/3220353

3 月，跳不动了？>>> 和Web应用程序一样，Tomcat作为一个Java程序也跑在JVM中，因此如果要对Tomcat进行调优，需要先了解JVM调优的原理。而对于JVM调优来说，主要是JVM垃圾收集的优化，一般来说是因为有问题才需要优化，所以对于JVM GC来说，如果观察到Tomcat进程的CPU使用率比较高，并且在GC日志中发现GC次数比较频繁、GC停顿时间长，这表明需要对GC进行优化了。 在对GC调优的过程中，不仅需要知道GC的原理，更重要的是要熟练使用各种监控和分析工具，具备GC调优的实战能力。CMS和G1是时下使用率比较高的两款垃圾收集器，从Java 9开始，采用G1作为默认垃圾收集器，而G1的目标也是逐步取代CMS。 1.CMS vs G1 CMS收集器将Java堆分为 年轻代 （Young）或 年老代 （Old）。这主要是因为有研究表明，超过90％的对象在第一次GC时就被回收掉，但是少数对象往往会存活较长的时间。 CMS还将年轻代内存空间分为 幸存者空间 （Survivor）和 伊甸园空间 （Eden）。新的对象始终在Eden空间上创建。一旦一个对象在一次垃圾收集后还幸存，就会被移动到幸存者空间。当一个对象在多次垃圾收集之后还存活时，它会移动到年老代。这样做的目的是在年轻代和年老代采用不同的收集算法，以达到较高的收集效率，比如在年轻代采用复制-整理算法

一、重新认识JVM 在之前的我们画过一张图，是从class文件到类装载器，再到运行时数据区的过程。今天把这张图进行升级，画一张完整的JVM大体的物理结构图。 二、 GC优化 内存被使用了之后，难免会有不够用或者达到设定值的时候，就需要对内存空间进行垃圾回收。 2.1 垃圾收集发生的时间 GC由JVM自动完成的，根据JVM系统环境而定的，所以时机是不确定的。当然，我们也可以进行手动垃圾回收，比如调用System.gc()方法通知JVM进行一次垃圾回收，但是具体什么时刻运行也无法控制。也就是System.gc()只是通知要回收，什么时候回收由JVM自行决定。但是不建议手动进行垃圾回收，因为消耗的资源比较大。 一般以下几种情况会进行垃圾回收 当Eden区或者S区不够用 老年代空间不够用 方法区看空间不够用 System.gc() 2.2 项目环境准备 此次案例我们使用SpringBoot来创建项目，然后配置对应的参数。 2.3 GC日志文件 要分析日志的信息，首先得拿到GC日志文件才行，所以得配置一下启动参数 -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintGCDateStamps -Xloggc:gc.log 然后启动项目 可以看到默认使用的是 ParallelGC 1、ParallelGC日志 吞吐量优先，日志分析 2020

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 纸上得来终觉浅 绝知此事要躬行 我所在的公司基本上是没有机会进行JVM参数调优的，但是如果有些东西自己不亲身经历一下，看再多的理论知识也只能算是纸上谈兵，真正碰到问题的时候还是不知道该怎么分析。所以就自己制造一些问题然后看其现象，利用所学的知识事前推测，看现象是不是和自己推测的一样。这样不仅对自己所学的知识又是一次巩固，而且也能锻炼自己解决问题的能力（虽然问题是自己制造的）。 其实在写这篇文章之前已经看过好好几遍关于JVM调优那一块的内容，无论是书还是博客，但是大都看完了感觉自己懂了，但是真正自己模拟操作的时候又觉得什么都不会，但是经过自己模拟一遍以后发现能够将之前的知识都关联起来，形成了一个面，感觉理解有深了一点。这里强调一下 希望大家看完以后，能够自己在机器上模拟一遍，采用不同的参数然后自己猜想结果并验证 工具准备 工欲善其事，必先利其器。在分析JVM之前我们需要先将工具准备一下，一个是可视化的垃圾回收工具，另一个是压测的工具。 GcViews安装 将 GcViews 代码从Git上下载下来 github地址 在项目的根目录中执行命令 mvn clean install 然后发现在根目录中生成了 target 文件夹，在里面可以找到 gcviewer-1.37-SNAPSHOT.jar 文件

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> Java学习笔记21-性能调优实战 我们这次从几个一般常见的问题分析，主要有接口请求过慢或超时，程序突然崩（挂）了，CPU、内存居高不下或忽高忽低，硬盘容量不足等，这些可能是各种情况造成，我们从内存、CPU、线程、网络等（一般都是业务代码有问题）角度分析。 内存相关问题 一、JVM启动参数配置 -Xms4g -Xmx4g： JVM堆内存的最小值、最大值设置为相等 启动时会有预热过程（堆内存小于最小值），逐渐达到最小值 启动时可直接向操作系统申请足够的内存（跳过预热）：-XX:+AlwaysPreTouch 二、GC分析与调优 GC分析，主要查看GC导致的stop-the-world，这将导致我们的程序延时增大。 jcmd 查找运行中jar程序的进程号 jmap 打印heap的概要信息，GC使用的算法，heap的配置及wise heap的使用情况 -Xloggc 收集GC日志（日志离线分析，主要用于检查故障看出是不是因为GC导致的程序卡顿） 通过GCViewer工具，辅助分析GC日志文件 jstat 动态监控GC统计信息，间隔1000毫秒统计一次，每10行数据后输出列标题 GC调优，切换回收器逐步调试， GC调优的过程就是对每个参数的含义了解后，再根据官方手册，一个个调试，找到符合应用的最佳配置点。是一个细致活