如何查看 java gc 类型

Posted 2023-05-15

Java中的GC有哪几种类型？

参数

描述

UseSerialGC

虚拟机运行在Client模式的默认值，打开此开关参数后，
使用Serial+Serial Old收集器组合进行垃圾收集。

UseParNewGC

打开此开关参数后，使用ParNew+Serial Old收集器组合进行垃圾收集。

UseConcMarkSweepGC

打开此开关参数后，使用ParNew+CMS+Serial Old收集器组合进行垃圾收集。Serial Old作为CMS收集器出现Concurrent Mode Failure的备用垃圾收集器。

UseParallelGC

虚拟机运行在Server模式的默认值，打开此开关参数后，使用Parallel Scavenge+Serial Old收集器组合进行垃圾收集。

UseParallelOldGC

打开此开关参数后，使用Parallel Scavenge+Parallel Old收集器组合进行垃圾收集。

在Java程序启动完成后，通过jps观察进程来查询到当前运行的java进程，使用
jinfo –flag UseSerialGC 进程

的方式可以定位其使用的gc策略，因为这些参数都是boolean型的常量，如果使用该种gc策略会出现＋号，否则－号。

使用-XX:+上述GC策略可以开启对应的GC策略。

GC日志查看
可以通过在java命令种加入参数来指定对应的gc类型，打印gc日志信息并输出至文件等策略。

GC的日志是以替换的方式(>)写入的，而不是追加(>>)，如果下次写入到同一个文件中的话，以前的GC内容会被清空。

对应的参数列表
-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 日志文件的输出路径

这里使用如下的参数来进行日志的打印：
-XX:+PrintGCDateStamps -XX:+PrintGCDetails -Xloggc:./gclogs

对于新生代回收的一行日志，其基本内容如下：
2014-07-18T16:02:17.606+0800: 611.633: [GC 611.633: [DefNew: 843458K->2K(948864K), 0.0059180 secs] 2186589K->1343132K(3057292K), 0.0059490 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]

其含义大概如下：
2014-07-18T16:02:17.606+0800（当前时间戳）: 611.633（时间戳）: [GC（表示Young GC） 611.633: [DefNew（单线程Serial年轻代GC）: 843458K（年轻代垃圾回收前的大小）->2K（年轻代回收后的大小）(948864K（年轻代总大小）), 0.0059180 secs（本次回收的时间）] 2186589K（整个堆回收前的大小）->1343132K（整个堆回收后的大小）(3057292K（堆总大小）), 0.0059490 secs（回收时间）] [Times: user=0.00（用户耗时） sys=0.00（系统耗时）, real=0.00 secs（实际耗时）]

老年代回收的日志如下：
2014-07-18T16:19:16.794+0800: 1630.821: [GC 1630.821: [DefNew: 1005567K->111679K(1005568K), 0.9152360 secs]1631.736: [Tenured:
2573912K->1340650K(2574068K), 1.8511050 secs] 3122548K->1340650K(3579636K), [Perm : 17882K->17882K(21248K)], 2.7854350 secs] [Times: user=2.57 sys=0.22, real=2.79 secs]

gc日志中的最后貌似是系统运行完成前的快照：
Heap
def new generation total 1005568K, used 111158K [0x00000006fae00000, 0x000000073f110000, 0x0000000750350000)
eden space 893888K, 12% used [0x00000006fae00000, 0x0000000701710e90, 0x00000007316f0000)
from space 111680K, 3% used [0x0000000738400000, 0x000000073877c9b0, 0x000000073f110000)
to space 111680K, 0% used [0x00000007316f0000, 0x00000007316f0000, 0x0000000738400000)
tenured generation total 2234420K, used 1347671K [0x0000000750350000, 0x00000007d895d000, 0x00000007fae00000)
the space 2234420K, 60% used [0x0000000750350000, 0x00000007a2765cb8, 0x00000007a2765e00, 0x00000007d895d000)
compacting perm gen total 21248K, used 17994K [0x00000007fae00000, 0x00000007fc2c0000, 0x0000000800000000)
the space 21248K, 84% used [0x00000007fae00000, 0x00000007fbf92a50, 0x00000007fbf92c00, 0x00000007fc2c0000)
No shared spaces configured.

GC日志的离线分析
可以使用一些离线的工具来对GC日志进行分析，比如sun的gchisto( https://java.net/projects/gchisto)，gcviewer（ https://github.com/chewiebug/GCViewer ），这些都是开源的工具，用户可以直接通过版本控制工具下载其源码，进行离线分析。

下面就已gcviewer为例，简要分析一下gc日志的离线分析，gcviewer源代码工程是maven结构的，可以直接用maven进行package，这里编译的是1.34版本，本版本的快照已经上传至附件中。

需要说明的是，gcviewer支持多种参数生成的gc日志，直接通过java –jar的方式运行，加载生成的gc日志即可： 参考技术A java虽然是自动回收内存，但是应用程序，尤其服务器程序最好根据业务情况指明内存分配限制。否则可能导致应用程序宕掉。

举例说明含义：
-Xms128m
表示JVM Heap(堆内存)最小尺寸128MB，初始分配
-Xmx512m
表示JVM Heap(堆内存)最大允许的尺寸256MB，按需分配。

说明：如果-Xmx不指定或者指定偏小，应用可能会导致java.lang.OutOfMemory错误，此错误来自JVM不是Throwable的，无法用try...catch捕捉。

PermSize和MaxPermSize指明虚拟机为java永久生成对象（Permanate generation）如，class对象、方法对象这些可反射（reflective）对象分配内存限制，这些内存不包括在Heap（堆内存）区之中。

-XX:PermSize=64MB 最小尺寸，初始分配
-XX:MaxPermSize=256MB 最大允许分配尺寸，按需分配
过小会导致：java.lang.OutOfMemoryError: PermGen space

MaxPermSize缺省值和-server -client选项相关。
-server选项下默认MaxPermSize为64m
-client选项下默认MaxPermSize为32m 参考技术B gc是通知垃圾回收的，但不一定马上执行。 参考技术C gc是garbage collection——垃圾回收器的意思
就没有这种类型
只有基本数据类型和引用数据类型 参考技术D 输入代码：System.gc().getClass().getName();

Java 内存查看与分析

 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实时诊断，还有手动dump出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 -dump:<dump-options> <pid>

    （to connect to running process and dump java heap）

    dump-options:

    format=b     binary default

    file=<file>  dump heap to <file>

    Example:       jmap -dump: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的dump选项，这个选项是将jvm的堆中内存信息输出到一个文件中，在我本机执行

    jmap -dump:file=c:dump.txt 340

    注意340是我本机的java进程pid，dump出来的文件比较大有10几M，而且我只是开了tomcat，跑了一个很简单的应用，且没有任何访问，可以想象，大型繁忙的服务器上，dump出来的文件该有多大。需要知道的是，dump出来的文件信息是很原始的，绝不适合人直接观看，而jmap -histo显示的内容又太简单，例如只显示某些类型的对象占用多大内存，以及这些对象的数量，但是没有更详细的信息，例如这些对象分别是由谁创建的。那这么说，dump出来的文件有什么用呢？当然有用，因为有专门分析jvm的内存dump文件的工具。

 

    5：jhat

    上面说了，有很多工具都能分析jvm的内存dump文件，jhat就是sun jdk6及以上版本自带的工具，位于jdk的bin目录，执行 jhat -J -Xmx512m [file] ，file就是dump文件路径。jhat内置一个简单的web服务器，此命令执行后，jhat在命令行里显示分析结果的访问地址，可以用-port选项指定端口，具体用法可以执行jhat -heap查看帮助信息。访问指定地址后，就能看到页面上显示的信息，比jmap -histo命令显示的丰富得多，更为详细。

 

    6：eclipse内存分析器

    上面说了jhat，它能分析jvm的dump文件，但是全部是文字显示，eclipse memory analyzer，是一个eclipse提供用于分析jvm 堆dump的插件，它的分析速度比jhat快，分析结果是图形界面显示，比jhat的可读性更高。其实jvisualvm也可以分析dump文件，也是有图形界面显示的。

 

    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的堆dump文件，然后再用jhat，或者jvisualvm，或者eclipse内存分析器来分析内存状况。