jStat

java启动参数内可以指定gc的方式，实际情况中参数比较多，摘出部分参数看一下 A: -XX:+UseG1GC -XX:MaxGCPauseMillis=200 B: -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:CMSInitiatingOccupancyFraction=80 -XX:+UseCMSInitiatingOccupancyOnly 上述两个情况分别简称为A，B。 对于B使用的gc方法是CMS，对于A使用的G1。 注意1：内存结构 需要注意一下，对于CMS的内存结构是这样的 但是对于G1，内存划分不是整块整块的，而是把整个内存一整块堆切分成2000个小region，然后年轻代和年老代混排，对于G1，幸存者区域只有一个，所以在执行"jstat -gc"的时候，会看到S0总是空的。【参考资料2,3】 注意2 jstat -gc <pid>输出的信息单位是KB不是字节 注意3 gc触发的条件 gc条件比较多，说一下常见的条件 对于CMS，伊甸园区满了就会GC 对于G1，伊甸园区满了就会GC，另外还有一个参数控制，当整个堆内存达到一定比例就会GC，InitiatingHeapOccupancyPercent。 注意4 G1 gc的模式 G1中提供了三种模式垃圾回收模式，young gc、mixed gc 和 full gc

JAVA运行时内存区域 程序计数器 一块很小的内存空间 当前线程所执行的字节码的行号指示器 当前线程私有 不会出现OutOfMemoryError情况 java虚拟机栈 通常存放基本数据类型，对象引用（一个指向对象起始地址的引用指针或一个代表对象的句柄），reeturnAddress类型（指向一条字节码指令的地址） 线程私有，生命周期与线程相同 java方法执行的内存模型，每个方法执行的同时都会创建一个栈帧，存储局部变量表(基本类型、对象引用)、操作数栈、动态链接、方法出口等信息 StackOverflowError异常：当线程请求的栈深度大于虚拟机所允许的深度 OutOfMemoryError异常：如果栈的扩展时无法申请到足够的内存 本地方法栈 与虚拟机栈相似，主要为虚拟机使用到的Native方法服务，在HotSpot虚拟机中直接把本地方法栈与虚拟机栈二合一 和虚拟机栈一样可能抛出StackOverflowError和OutOfMemoryError异常。 Java堆(Java Heap) java堆是被所有线程共享的一块内存区域，在虚拟机启动时创建。此区域的唯一目的就是存储对象实例。java堆是垃圾收集器管理的主要区域。java堆还可以细分为：新生代与老年代。再细一点有Eden空间、Form Survivor空间、To Survivor空间等。 可以通过-Xmx和

处理过线上问题的同学基本上都会遇到系统突然运行缓慢，CPU 100%，以及Full GC次数过多的问题。当然，这些问题的最终导致的直观现象就是系统运行缓慢，并且有大量的报警。本文主要针对系统运行缓慢这一问题，提供该问题的排查思路，从而定位出问题的代码点，进而提供解决该问题的思路。 对于线上系统突然产生的运行缓慢问题，如果该问题导致线上系统不可用，那么首先需要做的就是，导出jstack和内存信息，然后重启系统，尽快保证系统的可用性。这种情况可能的原因主要有两种： 代码中某个位置读取数据量较大，导致系统内存耗尽，从而导致Full GC次数过多，系统缓慢； 代码中有比较耗CPU的操作，导致CPU过高，系统运行缓慢； 相对来说，这是出现频率最高的两种线上问题，而且它们会直接导致系统不可用。另外有几种情况也会导致某个功能运行缓慢，但是不至于导致系统不可用： 代码某个位置有阻塞性的操作，导致该功能调用整体比较耗时，但出现是比较随机的； 某个线程由于某种原因而进入WAITING状态，此时该功能整体不可用，但是无法复现； 由于锁使用不当，导致多个线程进入死锁状态，从而导致系统整体比较缓慢。 对于这三种情况，通过查看CPU和系统内存情况是无法查看出具体问题的，因为它们相对来说都是具有一定阻塞性操作，CPU和系统内存使用情况都不高，但是功能却很慢。下面我们就通过查看系统日志来一步一步甄别上述几种问题。

javap Java反编译工具，主要用于根据Java字节码文件反汇编为Java源代码文件 用法：javap 用法 描述 javap -help —help -? 输出此用法消息 javap -version 版本消息 javap -v -verbose 输出附加信息 javap -l 输出行号和本地变量表 javap -public 仅显示公共类和成员 javap -protected 显示受保护的/公共类和成员 javap -package 显示程序包/受保护的/公共类和成员 (默认) javap -p -private 显示所有类和成员 javap -c 对代码进行反汇编 javap -s 输出内部类型签名 javap -sysinfo 显示正在处理的类的系统信息 (路径, 大小, 日期, MD5 散列) javap -constants 显示最终常量 javap -classpath 指定查找用户类文件的位置 javap -cp 指定查找用户类文件的位置 javap -bootclasspath 覆盖引导类文件的位置 jps jps（Java Virtual Machine Process Status Tool）显示当前所有Java进程pid的命令 用法：jps [options] [hostid] 用法 描述 jps -q 仅输出VM标识符 jps -m 输出main

请大神移步： https://segmentfault.com/a/1190000010510968?utm_source=tuicool&utm_medium=referral 今天看JVM群里有人发了一个GC情况，让人帮忙看优化的，于是我也凑热闹发了出来想让群里的大神们指导优化一下，以下是优化过程记录. 一开始我贴了下面的两张图 jstat看GC记录 jstat -gcutil pid 1000 20 jcmd看VM参数(第一次使用这个命令) jcmd pid VM.flags 可以看到YGC了8W多次，FGC有1100+，相比较另一个发出来求教的，我这个更糟糕，他的是运行了3天左右 FGC370次 然后飞神让我看下运行时间 ps -p pid -o etime 我的也是跑了3天左右，感觉优化空间非常的大 又让我拉了JVM配置 jinfo -flags pid (没权限，没执行成功) ps aux | grep pid 发现我的JVM完全没做过优化，据我自己的印象，就改过PermSize,因为这个OOM过，所以调大了一点。 然后飞神给了我一份他之前用过的配置 JAVA_OPTS="-Xms2g -Xmx2g -Xmn512m -XX:MaxPermSize=256m -server -Xss256k -XX:PermSize=128M -XX:+PrintGCDetails

类加载统计： [weblogic@DW_APP02 ~]$ jstat -class 2748 Loaded Bytes Unloaded Bytes Time 25120 53656.8 391 604.2 30.61 Loaded:加载class的数量 Bytes：所占用空间大小 Unloaded：未加载数量 Bytes:未加载占用空间 Time：时间 编译统计： [weblogic@DW_APP02 ~]$ jstat -compiler 2748 Compiled Failed Invalid Time FailedType FailedMethod 2888 1 0 49.71 1 sun/misc/URLClassPath getLoader Compiled：编译数量。 Failed：失败数量 Invalid：不可用数量 Time：时间 FailedType：失败类型 FailedMethod：失败的方法 　 垃圾回收统计： [weblogic@DW_APP02 ~]$ jstat -gc 2748 S0C S1C S0U S1U EC EU OC OU PC PU YGC YGCT FGC FGCT GCT 1536.0 1536.0 0.0 0.0 1395200.0 597287.9 2796544.0 127364.1 159232.0 158879.9 84

1.介绍 Jstat用于监控基于HotSpot的JVM，对其堆的使用情况进行实时的命令行的统计，使用jstat我们可以对指定的JVM做如下监控： 类的加载及卸载情况 查看新生代、老生代及metaSpace的容量及使用情况 查看新生代、老生代及metaSpace的垃圾收集情况，包括垃圾回收的次数及垃圾回收所占用的时间 查看新生代中Eden区及Survior区中容量及分配情况等 jstat工具特别强大，它有众多的可选项，通过提供多种不同的监控维度，使我们可以从不同的维度来了解到当前JVM堆的使用情况。详细查看堆内各个部分的使用量，使用的时候必须加上待统计的Java进程号，可选的不同维度参数以及可选的统计频率参数。 2.语法 下面是jdk1.8支持的选项： 下面是jdk1.8以下版本支持的选项： 3示例 jstat -gc -h5 -t 26316 1s 20 1 2 -gc 选项 -h5 每隔5行显示一下表头 -t 显示从虚拟机启动在当前时间的时间间隔 单位：秒 26536 线程id 1s 1秒显示一次 20 总共显示20次 4表头讲解 实名jdk1.7与jdk1.8就差了一个metaspace区域，其它都一样。 表头 描述 jdk 版本 S0C 新生代中Survivor space中S0当前容量的大小（KB） S1C 新生代中Survivor space中S1当前容量的大小（KB）

分析内存泄露的一般步骤 把Java应用程序使用的heap dump下来 使用Java heap分析工具，找出内存占用超出预期（一般是因为数量太多）的嫌疑对象 必要时，需要分析嫌疑对象和其他对象的引用关系。 查看程序的源代码，找出嫌疑对象数量过多的原因。 dump heap analyze heap Memory Analyzer char[]的数量出其意料的多，占用90%以上的内存 发现有数万计的char[]，每个都占用数百K的内存 Java程序保存了数以万计的大String对象 顺藤摸瓜 在可疑的char[]中，任意挑了一个，使用Path To GC Root功能，找到该char[]的引用路径，发现String对象是被一个HashMap中引用的 虽然缓存中的String对象数量还没有达到阈值，但是String对象大小远远超出了我们的预期，最终导致内存被大量消耗，形成内存泄露的迹象（准确说应该是内存消耗过多） 不过并没有把String大对象放到HashMap中，而是把String大对象进行split（调用String.split方法），然后将split出来的String小对象放到HashMap中 查看代码 public int return this 可以看出，Stirng.split方法调用了Pattern.split方法。继续看Pattern.split方法的代码：

jstat命令可以查看堆内存各部分的使用量，以及加载类的数量。命令的格式如下： 　 Loaded: 加载class的数量 Bytes： 所占用空间大小 Unloaded： 未加载数量 Bytes: 未加载占用空间 Time： 时间 　 Compiled： 编译数量。 Failed： 失败数量 Invalid： 不可用数量 Time： 时间 FailedType： 失败类型 FailedMethod： 失败的方法 　 S0C： 第一个幸存区的大小 S1C： 第二个幸存区的大小 S0U： 第一个幸存区的使用大小 S1U： 第二个幸存区的使用大小 EC： 伊甸园区的大小 EU： 伊甸园区的使用大小 OC： 老年代大小 OU： 老年代使用大小 MC： 方法区大小 MU： 方法区使用大小 CCSC: 压缩类空间大小 CCSU: 压缩类空间使用大小 YGC： 年轻代垃圾回收次数 YGCT： 年轻代垃圾回收消耗时间 FGC： 老年代垃圾回收次数 FGCT： 老年代垃圾回收消耗时间 GCT： 垃圾回收消耗总时间 NGCMN： 新生代最小容量 NGCMX： 新生代最大容量 NGC： 当前新生代容量 S0C： 第一个幸存区大小 S1C： 第二个幸存区的大小 EC： 伊甸园区的大小 OGCMN： 老年代最小容量 OGCMX： 老年代最大容量 OGC： 当前老年代大小 OC: 当前老年代大小 MCMN:

大致方向：JVM调优的目的是保证在 一定吞吐量 的情况下尽可能的 减少GC次数 ，从而减少系统停顿时间，提高服务质量和效率。 其中减少GC次数的原则： 将新生代转换成老年代的数量降至最少（及时进行Minor GC回收新生代） 减少Full GC 次数 -XX:+PrintGCDetails：打印GC的详细信息（冒号之后的+表示打印，-表示不打印） -XX:+UseSerialGC : 使用串行回收器 -Xmx4000m ：指定堆最大值为4000M（ 等价于-XX：MaxHeapSize）。默认物理内存的1/4 -Xms4000m ：指定堆初始化值为4000M（ 等价于-XX：initialHeapSize）。默认物理内存的1/64 -Xmn2000m ：设置新生代大小为2000M。 -Xss512k：设置栈大小为512k -Xmx ：指定堆最大值。默认物理内存的1/4 -Xms ：指定堆初始化值。默认物理内存的1/64 推荐：通常会将 -Xmx 与 -Xms两个参数配置成相同的值 public class Main { /** *堆内存大小配置 * -Xmx4000m 设置最大堆内存为4000m * -Xms4000m 设置初始化堆内存为4000m * @param args */ public static void main(String[] args) { System