❶ java内存查看与分析
业界有很多强大的java profile的工具，比如Jporfiler，yourkit，这些收费的东西我就不想说了，想说的是，其实java自己就提供了很多内存监控的小工具，下面列举的工具只是一小部分，仔细研究下扒陵jdk的工具，还是蛮有意思的呢：）
1：gc日志输出
在jvm启动参数中加入 -XX:+PrintGC -XX:+PrintGCDetails -XX:+PrintGCTimestamps -XX:+PrintGCApplicationStopedTime，jvm将会按照这些参数顺序输出gc概要信息，详细信息，gc时间信息，gc造成的应用暂停时间。如果在刚才的参数后面加入参数 -Xloggc:文件路径，gc信息将会输出到指定的文件中。其他参数还有
-verbose:gc和-XX:+PrintTenuringDistribution等。
2：jconsole
jconsole是jdk自带的一个内存分析工具，它提供了图形界面。可以查看到被监控的jvm的内存信息，线程信息，类加载信息，MBean信息。
jconsole位于jdk目录下的bin目录，在windows下是jconsole.exe，在unix和linux下是jconsole.sh，jconsole可以监控本地应用，也可以监控远程应用。 要监控本地应用，执行jconsole pid，pid就是运行的java进程id，如果不带上pid参数，则执行jconsole命令后，会看到一个对话框弹出，上面列出了本地的java进程，可以选择一个进行监控。如果要远程监控，则要在远程服务器的jvm参数里加入一些东西，因为jconsole的远程监控基于jmx的，关于jconsole详细用法，请见专门介绍jconsle的文章，我也会在博客里专门详细介绍jconsole。
3:jviusalvm
在JDK6 update 7之后，jdk推出了另外一个工具：jvisualvm,java可视化虚拟机，它不但提供了jconsole类似的功能，还提供了jvm内存和cpu实时诊断，还有手动mp出jvm内存情况，手动执行gc。
和jconsole一样，运行jviusalvm，在jdk的bin目录下执行jviusalvm，windows下是jviusalvm.exe,linux和unix下是jviusalvm.sh。渗此租
4：jmap
jmap是jdk自带的jvm内存分析的工具，丛兆位于jdk的bin目录。jdk1.6中jmap命令用法：
Usage:
jmap -histo pid
（to connect to running process and print histogram of java object heap
jmap -mp:mp-options pid
（to connect to running process and mp java heap）
mp-options:
format=b binary default
file=file mp heap to file
Example: jmap -mp:format=b,file=heap.bin pid
jmap -histo pid在屏幕上显示出指定pid的jvm内存状况。以我本机为例，执行该命令，屏幕显示：
num #instances #bytes class name
----------------------------------------------
1: 24206 2791864 constMethodKlass
2: 22371 2145216 [C
3: 24206 1940648 methodKlass
4: 1951 1364496 constantPoolKlass
5: 26543 1282560 symbolKlass
6: 6377 1081744 [B
7: 1793 909688 constantPoolCacheKlass
8: 1471 614624 instanceKlassKlass
9: 14581 548336 [Ljava.lang.Object;
10: 3863 513640 [I
11: 20677 496248 java.lang.String
12: 3621 312776 [Ljava.util.HashMap$Entry;
13: 3335 266800 java.lang.reflect.Method
14: 8256 264192 java.io.ObjectStreamClass$WeakClassKey
15: 7066 226112 java.util.TreeMap$Entry
16: 2355 173304 [S
17: 1687 161952 java.lang.Class
18: 2769 150112 [[I
19: 3563 142520 java.util.HashMap
20: 5562 133488 java.util.HashMap$Entry
Total 239019 17140408
为了方便查看，我删掉了一些行。从上面的信息很容易看出，#instance指的是对象数量，#bytes指的是这些对象占用的内存大小，class name指的是对象类型。
再看jmap的mp选项，这个选项是将jvm的堆中内存信息输出到一个文件中，在我本机执行
jmap -mp:file=c:mp.txt 340
注意340是我本机的java进程pid，mp出来的文件比较大有10几M，而且我只是开了tomcat，跑了一个很简单的应用，且没有任何访问，可以想象，大型繁忙的服务器上，mp出来的文件该有多大。需要知道的是，mp出来的文件信息是很原始的，绝不适合人直接观看，而jmap -histo显示的内容又太简单，例如只显示某些类型的对象占用多大内存，以及这些对象的数量，但是没有更详细的信息，例如这些对象分别是由谁创建的。那这么说，mp出来的文件有什么用呢？当然有用，因为有专门分析jvm的内存mp文件的工具。
5：jhat
上面说了，有很多工具都能分析jvm的内存mp文件，jhat就是sun jdk6及以上版本自带的工具，位于jdk的bin目录，执行 jhat -J -Xmx512m [file] ，file就是mp文件路径。jhat内置一个简单的web服务器，此命令执行后，jhat在命令行里显示分析结果的访问地址，可以用-port选项指定端口，具体用法可以执行jhat -heap查看帮助信息。访问指定地址后，就能看到页面上显示的信息，比jmap -histo命令显示的丰富得多，更为详细。
6：eclipse内存分析器
上面说了jhat，它能分析jvm的mp文件，但是全部是文字显示，eclipse memory analyzer，是一个eclipse提供用于分析jvm 堆mp的插件，它的分析速度比jhat快，分析结果是图形界面显示，比jhat的可读性更高。其实jvisualvm也可以分析mp文件，也是有图形界面显示的。
7：jstat
如果说jmap倾向于分析jvm内存中对象信息的话，那么jsta就是倾向于分析jvm内存的gc情况。都是jvm内存分析工具，但显然，它们是从不同维度来分析的。jsat常用的参数有很多，如 -gc,-gcutil,-gccause，这些选项具体作用可查看jsat帮助信息，我经常用-gcutil，这个参数的作用不断的显示当前指定的jvm内存的垃圾收集的信息。
我在本机执行 jstat -gcutil 340 10000，这个命令是每个10秒钟输出一次jvm的gc信息，10000指的是间隔时间为10000毫秒。屏幕上显示如下信息（我只取了第一行，因为是按的一定频率显示，所以实际执行的时候，会有很多行）：
S0 S1 E O P YGC YGCT FGC FGCT GCT
54.62 0.00 42.87 43.52 86.24 1792 5.093 33 7.670 12.763
额怎么说呢，要看懂这些信息代表什么意思，还必须对jvm的gc机制有一定的了解才行啊。其实如果对sun的 hot spot jvm的gc比较了解的人，应该很容易看懂这些信息，但是不清楚gc机制的人，有点莫名其妙，所以在这里我还是先讲讲sun的jvm的gc机制吧。说到gc，其实不仅仅只是java的概念，其实在java之前，就有很多语言有gc的概念了，gc嘛就是垃圾收集的意思，更多的是一种算法性的东西，而跟具体语言没太大关系，所以关于gc的历史，gc的主流算法我就不讲了，那扯得太远了，扯得太远了就是扯淡。sun现在的jvm，内存的管理模型是分代模型，所以gc当然是分代收集了。分代是什么意思呢？就是将对象按照生命周期分成三个层次，分别是：新生代，旧生代，持久代。对象刚开始分配的时候，大部分都在新生代，当新生代gc提交被触发后了，执行一次新生代范围内的gc，这叫minor gc，如果执行了几次minor gc后，还有对象存活，将这些对象转入旧生代，因为这些对象已经经过了组织的重重考验了哇。旧生代的gc频率会更低一些，如果旧生代执行了gc，那就是full gc，因为不是局部gc，而是全内存范围的gc，这会造成应用停顿，因为全内存收集，必须封锁内存，不许有新的对象分配到内存，持久代就是一些jvm期间，基本不会消失的对象，例如class的定义，jvm方法区信息，例如静态块。需要主要的是，新生代里又分了三个空间：eden，susvivor0，susvivor1，按字面上来理解，就是伊甸园区，幸存1区，幸存2区。新对象分配在eden区中，eden区满时，采用标记-复制算法，即检查出eden区存活 的对象，并将这些对象复制到是s0或s1中，然后清空eden区。jvm的gc说开来，不只是这么简单，例如还有串行收集，并行收集，并发收集，还有着名的火车算法，不过那说得太远了，现在对这个有大致了解就好。说到这里，再来看一下上面输出的信息：
S0 S1 E O P YGC YGCT FGC FGCT GCT
54.62 0.00 42.87 43.52 86.24 1792 5.093 33 7.670 12.763
S0:新生代的susvivor0区，空间使用率为5462%
S1:新生代的susvivor1区，空间使用率为0.00%（因为还没有执行第二次minor收集）
E:eden区，空间使用率42.87%
O:旧生代，空间使用率43.52%
P:持久带，空间使用率86.24%
YGC:minor gc执行次数1792次
YGCT:minor gc耗费的时间5.093毫秒
FGC:full gc执行次数33
FGCT:full gc耗费的时间7.670毫秒
GCT:gc耗费的总时间12.763毫秒
怎样选择工具
上面列举的一些工具，各有利弊，其实如果在开发环境，使用什么样的工具是无所谓的，只要能得到结果就好。但是在生产环境里，却不能乱选择，因为这些工具本身就会耗费大量的系统资源，如果在一个生产服务器压力很大的时候，贸然执行这些工具，可能会造成很意外的情况。最好不要在服务器本机监控，远程监控会比较好一些，但是如果要远程监控，服务器端的启动脚本要加入一些jvm参数，例如用jconsloe远程监控tomcat或jboss等，都需要设置jvm的jmx参数，如果仅仅只是分析服务器的内存分配和gc信息，强烈推荐，先用jmap导出服务器端的jvm的堆mp文件，然后再用jhat，或者jvisualvm，或者eclipse内存分析器来分析内存状况。
❷ jvm 性能调优工具之 jstat 命令详解
Jstat名称：Java Virtual Machine statistics monitoring tool
功能描述：
Jstat是JDK自带的一个轻量级小工具。它位于java的bin目录下，主要利用JVM内建的指令对Java应用程序的资源和性能进行实时的命令行的监控，包括了对Heap size和垃圾回收状况的监控。
命令用法：jstat [-命令选项] [vmid] [间隔时间/毫秒] [查询次数]
注意：使用的jdk版本是jdk8。
C:\Users\Administrator>jstat -helpUsage: jstat -help|-options jstat -<option> [-t] [-h<lines>] <vmid> [<interval> [<count>]] Definitions: <option> An option reported by the -options option <vmid> Virtual Machine Identifier. A vmid takes the following form: <lvmid>[@<hostname>[:<port>]] Where <lvmid> is the local vm identifier for the target Java virtual machine, typically a process id; <hostname> is the name of the host running the target Java virtual machine; and <port> is the port number for the rmiregistry on the target host. See the jvmstat documentation for a more complete description of the Virtual Machine Identifier. <lines> Number of samples between header lines. <interval> Sampling interval. The following forms are allowed: <n>["ms"|"s"] Where <n> is an integer and the suffix specifies the units as milliseconds("ms") or seconds("s"). The default units are "ms". <count> Number of samples to take before terminating. -J<flag> Pass <flag> directly to the runtime system.
option：参数选项
-t：可以在打印的列加上Timestamp列，用于显示系统运行的时间
-h：可以在周期性数据输出的时型蠢候，指定输出多少行以后输出一次表头
vmid：Virtual Machine ID（ 进程的 pid）
interval：执行每次的间隔时间，单位为毫秒
count：用于指定输出多少次记录，缺省则会一直打印
option 可以从下面参数中选择
jstat -options
-class 用卜悄陪于查看类加载情况的统计
-compiler 用于查看HotSpot中即时编译器编译情运档况的统计
-gc 用于查看JVM中堆的垃圾收集情况的统计
-gccapacity 用于查看新生代、老生代及持久代的存储容量情况
-gcmetacapacity 显示metaspace的大小
-gcnew 用于查看新生代垃圾收集的情况
-gcnewcapacity 用于查看新生代存储容量的情况
-gcold 用于查看老生代及持久代垃圾收集的情况
-gcoldcapacity 用于查看老生代的容量
-gcutil 显示垃圾收集信息
-gccause 显示垃圾回收的相关信息（通-gcutil）,同时显示最后一次仅当前正在发生的垃圾收集的原因
-printcompilation 输出JIT编译的方法信息
示例：
1.-class 类加载统计
[root@hadoop ~]# jps #先通过jps获取到java进程号（这里是一个zookeeper进程）3346 QuorumPeerMain7063 Jps[root@hadoop ~]# jstat -class 3346 #统计JVM中加载的类的数量与sizeLoaded Bytes Unloaded Bytes Time 1527 2842.7 0 0.0 1.02
Loaded:加载类的数量
Bytes：加载类的size，单位为Byte
Unloaded：卸载类的数目
Bytes：卸载类的size，单位为Byte
Time：加载与卸载类花费的时间
2.-compiler 编译统计
[root@hadoop ~]# jstat -compiler 3346 #用于查看HotSpot中即时编译器编译情况的统计Compiled Failed Invalid Time FailedType FailedMethod 404 0 0 0.19 0
Compiled：编译任务执行数量
Failed：编译任务执行失败数量
Invalid：编译任务执行失效数量
Time：编译任务消耗时间
FailedType：最后一个编译失败任务的类型
FailedMethod：最后一个编译失败任务所在的类及方法
3.-gc 垃圾回收统计
[root@hadoop ~]# jstat -gc 3346 #用于查看JVM中堆的垃圾收集情况的统计 S0C S1C S0U S1U EC EU OC OU MC MU CCSC CCSU YGC YGCT FGC FGCT GCT 128.0 128.0 0.0 128.0 1024.0 919.8 15104.0 2042.4 8448.0 8130.4 1024.0 996.0 7 0.019 0 0.000 0.019
S0C：年轻代中第一个survivor（幸存区）的容量 （字节）
S1C：年轻代中第二个survivor（幸存区）的容量 (字节)
S0U：年轻代中第一个survivor（幸存区）目前已使用空间 (字节)
S1U：年轻代中第二个survivor（幸存区）目前已使用空间 (字节)
EC：年轻代中Eden（伊甸园）的容量 (字节)
EU：年轻代中Eden（伊甸园）目前已使用空间 (字节)
OC：Old代的容量 (字节)
OU：Old代目前已使用空间 (字节)
MC：metaspace(元空间)的容量 (字节)
MU：metaspace(元空间)目前已使用空间 (字节)
CCSC：当前压缩类空间的容量 (字节)
CCSU：当前压缩类空间目前已使用空间 (字节)
YGC：从应用程序启动到采样时年轻代中gc次数
YGCT：从应用程序启动到采样时年轻代中gc所用时间(s)
FGC：从应用程序启动到采样时old代(全gc)gc次数
FGCT：从应用程序启动到采样时old代(全gc)gc所用时间(s)
GCT：从应用程序启动到采样时gc用的总时间(s)
4.-gccapacity 堆内存统计
[root@hadoop ~]# jstat -gccapacity 3346 #用于查看新生代、老生代及持久代的存储容量情况 NGCMN NGCMX NGC S0C S1C EC OGCMN OGCMX OGC OC MCMN MCMX MC CCSMN CCSMX CCSC YGC FGC 1280.0 83264.0 1280.0 128.0 128.0 1024.0 15104.0 166592.0 15104.0 15104.0 0.0 1056768.0 8448.0 0.0 1048576.0 1024.0 7 0[root@hadoop ~]# jstat -gccapacity -h5 3346 1000 #-h5：每5行显示一次表头 1000：每1秒钟显示一次，单位为毫秒 NGCMN NGCMX NGC S0C S1C EC OGCMN OGCMX OGC OC MCMN MCMX MC CCSMN CCSMX CCSC YGC FGC 1280.0 83264.0 1280.0 128.0 128.0 1024.0 15104.0 166592.0 15104.0 15104.0 0.0 1056768.0 8448.0 0.0 1048576.0 1024.0 7 0 1280.0 83264.0 1280.0 128.0 128.0 1024.0 15104.0 166592.0 15104.0 15104.0 0.0 1056768.0 8448.0 0.0 1048576.0 1024.0 7 0 1280.0 83264.0 1280.0 128.0 128.0 1024.0 15104.0 166592.0 15104.0 15104.0 0.0 1056768.0 8448.0 0.0 1048576.0 1024.0 7 0 1280.0 83264.0 1280.0 128.0 128.0 1024.0 15104.0 166592.0 15104.0 15104.0 0.0 1056768.0 8448.0 0.0 1048576.0 1024.0 7 0 1280.0 83264.0 1280.0 128.0 128.0 1024.0 15104.0 166592.0 15104.0 15104.0 0.0 1056768.0 8448.0 0.0 1048576.0 1024.0 7 0 NGCMN NGCMX NGC S0C S1C EC OGCMN OGCMX OGC OC MCMN MCMX MC CCSMN CCSMX CCSC YGC FGC 1280.0 83264.0 1280.0 128.0 128.0 1024.0 15104.0 166592.0 15104.0 15104.0 0.0 1056768.0 8448.0 0.0 1048576.0 1024.0 7 0 1280.0 83264.0 1280.0 128.0 128.0 1024.0 15104.0 166592.0 15104.0 15104.0 0.0 1056768.0 8448.0 0.0 1048576.0 1024.0 7 0 1280.0 83264.0 1280.0 128.0 128.0 1024.0 15104.0 166592.0 15104.0 15104.0 0.0 1056768.0 8448.0 0.0 1048576.0 1024.0 7 0 1280.0 83264.0 1280.0 128.0 128.0 1024.0 15104.0 166592.0 15104.0 15104.0 0.0 1056768.0 8448.0 0.0 1048576.0 1024.0 7 0
NGCMN：年轻代(young)中初始化(最小)的大小(字节)
NGCMX：年轻代(young)的最大容量 (字节)
NGC：年轻代(young)中当前的容量 (字节)
S0C：年轻代中第一个survivor（幸存区）的容量 (字节)
S1C：年轻代中第二个survivor（幸存区）的容量 (字节)
EC：年轻代中Eden（伊甸园）的容量 (字节)
OGCMN：old代中初始化(最小)的大小 (字节)
OGCMX：old代的最大容量(字节)
OGC：old代当前新生成的容量 (字节)
OC：Old代的容量 (字节)
MCMN：metaspace(元空间)中初始化(最小)的大小 (字节)
MCMX：metaspace(元空间)的最大容量 (字节)
MC：metaspace(元空间)当前新生成的容量 (字节)
CCSMN：最小压缩类空间大小
CCSMX：最大压缩类空间大小
CCSC：当前压缩类空间大小
YGC：从应用程序启动到采样时年轻代中gc次数
FGC：从应用程序启动到采样时old代(全gc)gc次数
5.-gcmetacapacity 元数据空间统计
[root@hadoop ~]# jstat -gcmetacapacity 3346 #显示元数据空间的大小MCMN MCMX MC CCSMN CCSMX CCSC YGC FGC FGCT GCT0.0 1056768.0 8448.0 0.0 1048576.0 1024.0 8 0 0.000 0.020
MCMN：最小元数据容量
MCMX：最大元数据容量
MC：当前元数据空间大小
CCSMN：最小压缩类空间大小
CCSMX：最大压缩类空间大小
CCSC：当前压缩类空间大小
YGC：从应用程序启动到采样时年轻代中gc次数
FGC：从应用程序启动到采样时old代(全gc)gc次数
FGCT：从应用程序启动到采样时old代(全gc)gc所用时间(s)
GCT：从应用程序启动到采样时gc用的总时间(s)
6.-gcnew 新生代垃圾回收统计
[root@hadoop ~]# jstat -gcnew 3346 #用于查看新生代垃圾收集的情况S0C S1C S0U S1U TT MTT DSS EC EU YGC YGCT128.0 128.0 67.8 0.0 1 15 64.0 1024.0 362.2 8 0.020
S0C：年轻代中第一个survivor（幸存区）的容量 (字节)
S1C：年轻代中第二个survivor（幸存区）的容量 (字节)
S0U：年轻代中第一个survivor（幸存区）目前已使用空间 (字节)
S1U：年轻代中第二个survivor（幸存区）目前已使用空间 (字节)
TT：持有次数限制
MTT：最大持有次数限制
DSS：期望的幸存区大小
EC：年轻代中Eden（伊甸园）的容量 (字节)
EU：年轻代中Eden（伊甸园）目前已使用空间 (字节)
YGC：从应用程序启动到采样时年轻代中gc次数
YGCT：从应用程序启动到采样时年轻代中gc所用时间(s)
7.-gcnewcapacity 新生代内存统计
[root@hadoop ~]# jstat -gcnewcapacity 3346 #用于查看新生代存储容量的情况NGCMN NGCMX NGC S0CMX S0C S1CMX S1C ECMX EC YGC FGC1280.0 83264.0 1280.0 8320.0 128.0 8320.0 128.0 66624.0 1024.0 8 0
NGCMN：年轻代(young)中初始化(最小)的大小(字节)
NGCMX：年轻代(young)的最大容量 (字节)
NGC：年轻代(young)中当前的容量 (字节)
S0CMX：年轻代中第一个survivor（幸存区）的最大容量 (字节)
S0C：年轻代中第一个survivor（幸存区）的容量 (字节)
S1CMX：年轻代中第二个survivor（幸存区）的最大容量 (字节)
S1C：年轻代中第二个survivor（幸存区）的容量 (字节)
ECMX：年轻代中Eden（伊甸园）的最大容量 (字节)
EC：年轻代中Eden（伊甸园）的容量 (字节)
YGC：从应用程序启动到采样时年轻代中gc次数
FGC：从应用程序启动到采样时old代(全gc)gc次数
8.-gcold 老年代垃圾回收统计
[root@hadoop ~]# jstat -gcold 3346 #用于查看老年代及持久代垃圾收集的情况MC MU CCSC CCSU OC OU YGC FGC FGCT GCT8448.0 8227.5 1024.0 1003.7 15104.0 2102.2 8 0 0.000 0.020
MC：metaspace(元空间)的容量 (字节)
MU：metaspace(元空间)目前已使用空间 (字节)
CCSC：压缩类空间大小
CCSU：压缩类空间使用大小
OC：Old代的容量 (字节)
OU：Old代目前已使用空间 (字节)
YGC：从应用程序启动到采样时年轻代中gc次数
FGC：从应用程序启动到采样时old代(全gc)gc次数
FGCT：从应用程序启动到采样时old代(全gc)gc所用时间(s)
GCT：从应用程序启动到采样时gc用的总时间(s)
9.-gcoldcapacity 老年代内存统计
[root@hadoop ~]# jstat -gcoldcapacity 3346 #用于查看老年代的容量OGCMN OGCMX OGC OC YGC FGC FGCT GCT15104.0 166592.0 15104.0 15104.0 8 0 0.000 0.020
OGCMN：old代中初始化(最小)的大小 (字节)OGCMX：old代的最大容量(字节)OGC：old代当前新生成的容量 (字节)OC：Old代的容量 (字节)YGC：从应用程序启动到采样时年轻代中gc次数FGC：从应用程序启动到采样时old代(全gc)gc次数FGCT：从应用程序启动到采样时old代(全gc)gc所用时间(s)GCT：从应用程序启动到采样时gc用的总时间(s) 在此我向大家推荐一个架构学习交流圈。交流学习指导伪鑫：1253431195（里面有大量的面试题及答案）里面会分享一些资深架构师录制的视频录像：有Spring，MyBatis，Netty源码分析，高并发、高性能、分布式、微服务架构的原理，JVM性能优化、分布式架构等这些成为架构师必备的知识体系。还能领取免费的学习资源，目前受益良多
10.-gcutil 垃圾回收统计
[root@hadoop ~]# jstat -gcutil 3346 #显示垃圾收集信息S0 S1 E O M CCS YGC YGCT FGC FGCT GCT52.97 0.00 42.10 13.92 97.39 98.02 8 0.020 0 0.000 0.020
S0：年轻代中第一个survivor（幸存区）已使用的占当前容量百分比
S1：年轻代中第二个survivor（幸存区）已使用的占当前容量百分比
E：年轻代中Eden（伊甸园）已使用的占当前容量百分比
O：old代已使用的占当前容量百分比
M：元数据区已使用的占当前容量百分比
CCS：压缩类空间已使用的占当前容量百分比
YGC ：从应用程序启动到采样时年轻代中gc次数
YGCT ：从应用程序启动到采样时年轻代中gc所用时间(s)
FGC ：从应用程序启动到采样时old代(全gc)gc次数
FGCT ：从应用程序启动到采样时old代(全gc)gc所用时间(s)
GCT：从应用程序启动到采样时gc用的总时间(s)
11.-gccause
[root@hadoop ~]# jstat -gccause 3346 #显示垃圾回收的相关信息（通-gcutil）,同时显示最后一次或当前正在发生的垃圾回收的诱因S0 S1 E O M CCS YGC YGCT FGC FGCT GCT LGCC GCC52.97 0.00 46.09 13.92 97.39 98.02 8 0.020 0 0.000 0.020 Allocation Failure No GC
LGCC：最后一次GC原因
GCC：当前GC原因（No GC 为当前没有执行GC）
12.-printcompilation JVM编译方法统计
[root@hadoop ~]# jstat -printcompilation 3346 #输出JIT编译的方法信息Compiled Size Type Method421 60 1 sun/nio/ch/Util$2 clear
Compiled：编译任务的数目
Size：方法生成的字节码的大小
Type：编译类型
Method：类名和方法名用来标识编译的方法。类名使用/做为一个命名空间分隔符。方法名是给定类中的方法。上述格式是由-XX:+PrintComplation选项进行设置的
远程监控
与jps一样，jstat也支持远程监控，同样也需要开启安全授权，方法参照jps。
C:\Users\Administrator>jps 192.168.146.1283346 QuorumPeerMain3475 JstatdC:\Users\Administrator>jstat -gcutil [email protected] S0 S1 E O M CCS YGC YGCT FGC FGCT GCT 52.97 0.00 65.15 13.92 97.39 98.02 8 0.020 0 0.000 0.020
❸ GC分析工具
-q：仅输出VM标识符，不包括classname,jar name,arguments in main method
-m：输出main method的参数
-l：输出完全的包名，应用主类名，jar的穗乎完全路空族巧径名
-v：输出jvm参数
-V：输出通过flag文件传递到JVM中的斗键参数(.hotspotrc文件或-XX:Flags=所指定的文件
l class (类加载器)
l compiler (JIT)
l gc (GC堆状态)
l gccapacity (各区大小)
l gccause (最近一次GC统计和原因)
l gcnew (新区统计)
l gcnewcapacity (新区大小)
l gcold (老区统计)
l gcoldcapacity (老区大小)
l gcpermcapacity (永久区大小)
l gcutil (GC统计汇总)
l printcompilation (HotSpot编译统计)
jmap -mp:format=b,file=outfile.bin 1234可以将1234进程的内存heap输出出来到outfile.bin文件里，再配合MAT（内存分析工具）。
jmap -histo:live>live.log
针对活着的进程做本地的或远程的线程mp； 美团的CAT有类似功能，可以展示每分钟堆栈信息
jstack pid > stack.log
分析可能存在内内存泄漏和对象占用内存情况
https://www.cnblogs.com/hanlinhu/p/10174185.html
gc日志分析；GC问题分析、gc优化前后详细指标
https://gceasy.io/diamondgc-report.jsp?oTxnId_value=643c1813-7d09-4a1d-864f-267fa63af00d
http://www.ruanyifeng.com/blog/2017/09/flame-graph.html
❹ 减少长时间的GC停顿
如果您的应用程序的对象创建率很高，因此，垃圾回收率也将非常高。高垃圾收集率也会增弊橘加GC暂停时间。因此，优化应用程序以创建较少数量的对象是减少长GC暂停的有效策略。这可能是比较耗时，但值得100％进行。为了优化应用程序中的对象创建速度，您可以考虑使用Java Profiler（如 JProfiler， YourKit，JVisualVM ...）。这些分析器将报告
小提示:如何计算对象创建率?
当年轻代太小时，对象将被过早地提升为老代。从老年代收集垃圾要比从年轻代收集垃圾花费更多的时间。因此，增加年轻代的大小可以减少长时间的GC暂停。可以通过设置两个JVM参数中的任何一个来增加年轻代
GC算法的选择对GC暂停时间有很大影响。除非您是GC专家或者打算成为一个专家或者团队中的某人是GC专家，否则您可以调整GC设置以获得最佳的GC暂停时间。假设您不具备GC专业知识，那么我建议您使用G1 GC算法，因为它具有 自动调整功能。在G1 GC中，您可以使用系统属性“ -XX：MaxGCPauseMillis”设置GC暂停时间目标。例：
根据上面的示例，最大GC暂停时间设置为200毫秒。这是一个软目标，JVM将尽力实现这一目标。如果您已经在使用G1 GC算法，并且仍然继续经历高暂停时间，请参考本文。
有时由于内存不足（RAM），操作系统可能正在从内存中交换应用程序.Swapping非常昂贵，因为它需要磁盘访问，这比物理内存访问要慢得多.交换过程时，GC将花费很长时间才能完成。
下面是从StackOverflow获得的脚本（感谢作者）-执行该脚本 将显示所有正在交换的进程。请确保您的进程没有被交换
如果发现进程正在交换，请执行以下操作之一：
a。向服务器分配更多RAM
b。减少服务器上运行的进程数，以便它可以释放内存（RAM）。
C。减小应用程序的堆大小（我不建议这样做，因为它可能导致其他副作用）.
对于GC日志中报告的每个GC事件，将打印user，sys和real time。例：
（如果在GC事件中您始终注意到“real time”并不比“user”时间显着少，则可能表明GC线程不足。考虑增加GC线程数。假设“user”时间为25秒，并且您已将GC线程数配置为5，那么“real time”应接近5秒（因为25秒/ 5个线程= 5秒）。
警告：添加过多的GC线程将消耗大量CPU，并会占用应用程序的资源。因此，您需要在增加GC线程数之前进行彻底的测试
如果文件系统的I / O活动繁重（即发生大量读取和写入操作），也会导致长时间的GC暂停。这种繁重的文件系统I / O活动可能不是由您的应用程序引起的。可能是由于同一服务器上正在运行的另一个进程引起的，仍然可能导致您的应用程序长时间处于GC暂停状态( https://engineering.linkedin.com/blog/2016/02/eliminating-large-jvm-gc-pauses-caused-by-background-io-traffic )
当I / O繁忙时，您会发现“real time”时间要比“user”时间长键罩得多。例：
当发生这种模式时，可以使用以下解决方案：
a。如果您的应用程序引起了很高的I / O活动，请对其进行优化。
b。消除导致服务器上大量I / O活动的进程
C。将您的应用程序移到I / O活动较少的其他服务器上
Tit-bit: 如何监控io?
您可以在Unix中使用sar(系统活动报告)监视I/O活动。例子:
上面的命令报告每1秒对设备所做的读/秒和写/秒。有关“sar”命令的更多细节，请参阅本教程。
1.您自己的应用程序开发人员可能正在显式调用System.gc（）方法。
2.可能是第三方库，框架，有时甚至是您使用的应用程序服务器也可能正在调用System.gc（）方法。
3.可以通过使用JMX从外部工具（如VisualVM）触发
4.如果您的应用程序正在使用RMI，则RMI会定期调用System.gc（）。可以使用以下系统属性来配置稿卜闹此间隔：
-Dsun.rmi.dgc.server.gcInterval = n
-Dsun.rmi.dgc.client.gcInterval = n
评估是否绝对需要显式调用System.gc（）。如果不需要，请删除它。另一方面，可以通过传递JVM参数 '-XX：+ DisableExplicitGC' 来强制禁用System.gc（）调用
Tit-bit：如何知道是否显式调用了System.gc（）调用？
大堆大小（-Xmx）也可能导致长时间的GC暂停。如果堆大小很大，那么堆中将堆积更多的垃圾。当触发Full GC来清除堆中所有累积的垃圾时，将需要很长时间才能完成。逻辑很简单：如果您的小罐子里装满了垃圾，将可以轻松快捷地进行处理。另一方面，如果您有卡车装满的垃圾，将需要更多的时间来处理它们。
假设您的JVM堆大小为18GB，然后考虑拥有三个6 GB JVM实例，而不是一个18GB JVM。较小的堆大小具有降低长时间GC暂停的巨大潜力。
注意：上述所有策略均应在经过全面测试和分析后才能投入生产。所有策略可能不适用于您的应用程序。这些策略使用不当会导致负面结果
即使有多个GC线程，有时工作负载也会在GC工作线程之间平均分配。有很多原因导致GC工作负载可能无法平均分配到GC线程中。例如：
a。当前无法并行扫描大型线性数据结构。
b。某些事件仅触发单个线程收集器（例如，CMS收集中出现“并发模式故障”时）
如果碰巧使用CMS（并发标记和清除算法），则可以考虑传递 -XX：+ CMSScavengeBeforeRemark参数。这样可以在GC工作线程之间创建更加平衡的工作负载
翻译自
https://gceasy.io/gc-recommendations/long-pause-solution.jsp
❺ GC调优配置参数
一、JVM调优主要是调整下面两个指标
1. 停顿时间 ：垃圾收集器做垃圾回收中断应用执行的时间。 -XX:MaxGCPauseMillis
2. 吞吐量 ：垃圾收集的时间和总时间的占比：1/(1+n)，吞吐量计算公式为1-1/(1+n）， 吞吐量越大，证明性能越好。 -XX：GCTimeRatio=n
二、GC调优步骤
1. 打印GC日志
-XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintGCDateStamps -Xloggc:./gc.log
Tomcat则直接加在JAVA_OPTS变量里
* 分析日志得到关键性指标
* 分析GC原因，调优JVM参数（工具：gceasy,GCViewer）
2. GC常用参数
堆栈设置
-Xss:每个线程的栈大小
-Xms:初始堆大小，默认物理内存的1/64
-Xmx:最大堆大小，默认物理内存的1/4
-Xmn:新生代大小
-XX:NewSize:设置新生代初始大小
-XX:NewRatio:默认2，表示新生代占老年代的1/2，占整个堆内存的1/3
-XX:SurivivorRatio:默认8，表示一个survivor区占用1/8的Eden内存，即1/10的新生代内存
-XX:MetaspaceSize:设置元空间大小
-XX:MaxMetaspaceSize:设置元空间最大允许大小，默认不受限制，JVM Metaspace会进行动态扩展
垃圾回收统计信息
-XX:+PrintGC
-XX:+PrintGCDetails
-XX:+PrintGCTimeStamps
-Xloggc:filename
收集器设置：
-XX:+UseSerialGC:设置串行收集器
-XX:+UseParallelGC:设置并行收集器
-XX:+UseParallelOldGC:老年代使用并行收集器
-XX:+UseParNewGC:在新生代使用并行收集器
-XX:+UseConcMarkSweepGC:设置CMS并行收集器
-XX:UseG1GC:设置G1收集器
并行收集器设置：
-XX:ParallelGCThreads:设置用于垃圾回收的线程数
-XX:MaxGCPauseMillis:设置并行收集最大暂停时间
-XX:GCTimeRatio:设置垃圾回收时间占程序运行时间的百分比
-XX:YongGenerationSizeIncrement:年轻代GC后扩容的比例，默认是20%
CMS收集器设置
-XX:+UseConcMarkSweepGC:设置CMS并发收集器
-XX:+CMSIncrementalMode:设置为增量模式。适用于单CPU情况
-XX:ParallelGCThreads:设置并发收集器的线程数
-XX:CMSFullGCsBeforeCompanction:设定进行多少次CMS垃圾回收后，进行一次内存压缩
-XX:+CMSClassUnloadingEnabled:允许对类元数据进行回收
-XX:UseCMSInitiatingOccupancyOnly:表示只在到达阈值的时候，才进行CMS回收
-XX:+CMSIncrementalMode:设置为增量模式，适用于单CPU情况
-XX:ParallelCMSThreads:设定CMS的线程数量
-XX::设置CMS收集器袭启友在老年代拍槐空间被使用多少后触发
-XX:+:设置CMS收集器在完成垃圾收集后是否要进行一次内存碎片的整理
G1收集器设置旁茄
-XX:+UseG1GC:使用G1收集器
-XX:ParallelGCThreads:设置并发收集器的线程数
-XX:G1HeapRegionSize:制定分区大小（1MB~32MB，必须是2的幂），默认将整个堆划分为2048个分区
-XX:GCTimeRatio:吞吐量大小，0-100的整数（默认9），值为n则系统将花费不超过1/(1+n)的时间用于垃圾回收
-XX：MaxGCPauseMillis:目标暂停时间（默认200ms）
-XX:G1NewSizePercent:新生代内存初始空间（默认堆的5%）
-XX:G1MaxNewSizePercent:新生代内存最大空间
-XX:TargetSurvivorRatio:Survivor填充容量（默认50%）
-XX:MaxTenuringThreshold:最大任期阈值（默认15%）
-XX:InitiatingHeapOccupancyPercen:老年代占空间超过整堆比IHOP阈值（默认45%），超过则进行混合收集
-XX:G1HeapWastePercent:堆废物百分比（默认5%）
❻ GC Log分析
Dalvik虚拟机型衡乱，每一次GC打印内容格式：
含义解析
GC Reason：GC触发原因
GC_CONCURRENT：当已分配内存达到某一值时，触发并发GC；
GC_FOR_MALLOC：当尝试在堆上分配内存不足时触发的GC；系统必须停止应用程序并回收内存；
GC_HPROF_DUMP_HEAP： 当需要创建HPROF文件来分析堆内存时触发的GC；
GC_EXPLICIT：当明确的调用GC时，例如调用System.gc()或者通过DDMS工具显式地告诉系统进行GC操作等；
GC_EXTERNAL_ALLOC： 仅在API级别为10或者更低时（新版本分配内存都在Dalvik堆上）
Amount freed GC：回收的内存大小
Heap stats：堆上的空闲内存百分比 （已用内存）/（堆上总内存）
External memory stats： API级别为10或者更低：（已分配的内存量）/ （即将发生垃圾的极限）
Pause time：这次卜档GC操作导致应用程序暂停的时间。关于这个暂停的时间，在2.3之前GC操作是不能并发进行的，也就是系统正在进行GC，那么应用程序就只能阻塞住等待GC结束。而自2.3之后，GC操作改成了并发的方式进行，就是说GC的过程中不会影响到应用程序的正常运行，但是在GC操作的拦烂开始和结束的时候会短暂阻塞一段时间。
Art虚拟机，每一次GC打印内容格式：
I/art:<GC_Reason><Amount_freed>,<LOS_Space_Status>,<Heap_stats>,<Pause_time>,<Total_time>
基本情况和Dalvik没有什么差别，GC的Reason更多了，还多了一个LOS_Space_Status.
LOS_Space_Status：Large Object Space，大对象占用的空间，这部分内存并不是分配在堆上的，但仍属于应用程序内存空间，主要用来管理 Bitmap 等占内存大的对象，避免因分配大内存导致堆频繁 GC。