admin 管理员组

文章数量: 887006

JVM知识点总结

1. jvm简介

VM是Java Virtual Machine（Java虚拟机）的缩写，JVM是一种用于计算设备的规范，它是一个虚构出来的计算机，是通过在实际的计算机上仿真模拟各种计算机功能来实现的。Java虚拟机包括一套字节码指令集、一组寄存器、一个栈、一个垃圾回收堆和一个存储方法域。 JVM屏蔽了与具体操作系统平台相关的信息，使Java程序只需生成在Java虚拟机上运行的目标代码（字节码）,就可以在多种平台上不加修改地运行。JVM在执行字节码时，实际上最终还是把字节码解释成具体平台上的机器指令执行。

1.1 jvm的架构模型

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-ifoohgMQ-1688482194782)(.jpg)]

（1）寄存器（程序计数器）

PC寄存器是用于存储每个线程下一步将执行的JVM指令，如该方法为native的，则PC寄存器中不存储任何信息。

（2）栈

J栈是线程私有的，每个线程创建的同时都会创建栈，JVM栈中存放的为当前线程中局部基本类型的变量（java中定义的八种基本类型：boolean、char、byte、short、int、long、float、double）、部分的返回结果以及Stack Frame，非基本类型的对象在JVM栈上仅存放一个指向堆上的地址。

（3）堆

它是用来存储对象实例以及数组值的区域，可以认为Java中所有通过new创建的对象的内存都在此分配，Heap中的对象的内存需要等待GC进行回收。

1） 堆是JVM中所有线程共享的，因此在其上进行对象内存的分配均需要进行加锁，这也导致了new对象的开销是比较大的

2） Sun Hotspot JVM为了提升对象内存分配的效率，对于所创建的线程都会分配一块独立的空间TLAB（Thread Local Allocation Buffer），其大小由JVM根据运行的情况计算而得，在TLAB上分配对象时不需要加锁，因此JVM在给线程的对象分配内存时会尽量的在TLAB上分配，在这种情况下JVM中分配对象内存的性能和C基本是一样高效的，但如果对象过大的话则仍然是直接使用堆空间分配

3） TLAB仅作用于新生代的Eden Space，因此在编写Java程序时，通常多个小的对象比大的对象分配起来更加高效。

4） 所有新创建的Object 都将会存储在新生代Yong Generation中。如果Young Generation的数据在一次或多次GC后存活下来，那么将被转移到OldGeneration。新的Object总是创建在Eden Space。

（4）方法区（Method Area）

（1）在Sun JDK中这块区域对应的为PermanetGeneration，又称为持久代。这里这个说法有问题，在1.6持久带在方法区，在1.7持久带划分在堆内存（逻辑划分），1.8持久带就不存来了，代替的是元数据空间Metaspace。

（2）方法区域存放了所加载的类的信息（名称、修饰符等）、类中的静态变量、类中定义为final类型的常量、类中的Field信息、类中的方法信息，当开发人员在程序中通过Class对象中的getName、isInterface等方法来获取信息时，这些数据都来源于方法区域，同时方法区域也是全局共享的，在一定的条件下它也会被GC，当方法区域需要使用的内存超过其允许的大小时，会抛出OutOfMemory的错误信息。

（5）运行时常量池（Runtime Constant Pool）

存放的为类中的固定的常量信息、方法和Field的引用信息等，其空间从方法区域中分配。

（6）本地方法堆栈（Native Method Stacks）

JVM采用本地方法堆栈来支持native方法的执行，此区域用于存储每个native方法调用的状态。

1.2 堆内存模型

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-fke4YI0s-1688482194783)(.png)]

  • Young 年轻区（代）

    Young区被划分为三部分，Eden区和两个大小严格相同的Survivor区，其中，Survivor区间中，某一时刻只有其中一个是被使用的，另外一个留做垃圾收集时复制对象用，在Eden区间变满的时候， GC就会将存活的对象移到空闲的Survivor区间中，根据JVM的策略，在经过几次垃圾收集后（默认15次，可以进行调整），任然存活于Survivor的对象将被移动到Tenured区间。

  • Tenured 年老区

    Tenured区主要保存生命周期长的对象，一般是一些老的对象，当一些对象在Young复制转移一定的次数以后，对象就会被转移到Tenured区，一般如果系统中用了application级别的缓存，缓存中的对象往往会被转移到这一区间。

  • Perm 永久区

    Perm代主要保存class,method,filed对象，这部份的空间一般不会溢出，除非一次性加载了很多的类，不过在涉及到热部署的应用服务器的时候，有时候会遇到java.lang.OutOfMemoryError : PermGen space 的错误，造成这个错误的很大原因就有可能是每次都重新部署，但是重新部署后，类的class没有被卸载掉，这样就造成了大量的class对象保存在了perm中，这种情况下，一般重新启动应用服务器可以解决问题。

  • Virtual区：（这给别人画在了老年带，由于它是虚拟的，并不存在的，所以这里我就没有画）

    • 最大内存和初始内存的差值，就是Virtual区。

注意：

在jdk1.8中变化最大的Perm区，用Metaspace（元数据空间）进行了替换。

需要特别说明的是：Metaspace所占用的内存空间不是在虚拟机内部，而是在本地内存空间中，这也是与1.7的永久代最大的区别所在。

2. 基础常用参数

三种类型的参数：标准参数、-X参数（非标准参数）、-XX参数（使用率较高）

2.1 标准参数

jvm的标准参数，一般都是很稳定的，在未来的JVM版本中不会改变，可以使用java -help检索出所有的标准参数。

[root@node01 ~]# java -help
用法: java [-options] class [args...](执行类)或  java [-options] -jar jarfile [args...](执行 jar 文件)
其中选项包括:-d32	  使用 32 位数据模型 (如果可用)-d64	  使用 64 位数据模型 (如果可用)-server	  选择 "server" VM默认 VM 是 server,因为您是在服务器类计算机上运行。-cp <目录和 zip/jar 文件的类搜索路径>-classpath <目录和 zip/jar 文件的类搜索路径>用 : 分隔的目录, JAR 档案和 ZIP 档案列表, 用于搜索类文件。-D<名称>=<值>设置系统属性-verbose:[class|gc|jni]启用详细输出-version      输出产品版本并退出-version:<值>警告: 此功能已过时, 将在未来发行版中删除。需要指定的版本才能运行-showversion  输出产品版本并继续#常用-jre-restrict-search | -no-jre-restrict-search警告: 此功能已过时, 将在未来发行版中删除。在版本搜索中包括/排除用户专用 JRE-? -help      输出此帮助消息-X            输出非标准选项的帮助-ea[:<packagename>...|:<classname>]-enableassertions[:<packagename>...|:<classname>]按指定的粒度启用断言-da[:<packagename>...|:<classname>]-disableassertions[:<packagename>...|:<classname>]禁用具有指定粒度的断言-esa | -enablesystemassertions启用系统断言-dsa | -disablesystemassertions禁用系统断言-agentlib:<libname>[=<选项>]加载本机代理库 <libname>, 例如 -agentlib:hprof另请参阅 -agentlib:jdwp=help 和 -agentlib:hprof=help-agentpath:<pathname>[=<选项>]按完整路径名加载本机代理库-javaagent:<jarpath>[=<选项>]加载 Java 编程语言代理, 请参阅 java.lang.instrument-splash:<imagepath>使用指定的图像显示启动屏幕

其中三个常用的命令：

  • -showversion

输出产品版本并继续

  • -server和-client
  • 它们的区别是Server VM的初始堆空间会大一些，默认使用的是并行垃圾回收器，启动慢运行快。
  • Client VM相对来讲会保守一些，初始堆空间会小一些，使用串行的垃圾回收器，它的目标是为了让JVM的启动速度更快，但运行速度会比Server模式慢些。
  • JVM在启动的时候会根据硬件和操作系统自动选择使用Server还是Client类型的JVM。
  • 32位操作系统
    • 如果是Windows系统，不论硬件配置如何，都默认使用Client类型的JVM。
    • 如果是其他操作系统上，机器配置有2GB以上的内存同时有2个以上CPU的话默认使用server模式，否则使用client模式。
  • 64位操作系统
    • 只有server类型，不支持client类型。

2.2 -X参数

jvm的-X参数是非标准参数，在不同版本的jvm中，参数可能会有所不同，可以通过java -X查看非标准参数。

[root@node01 test]# java -X-Xmixed           混合模式执行 (默认)-Xint             仅解释模式执行-Xbootclasspath:<用 : 分隔的目录和 zip/jar 文件>设置搜索路径以引导类和资源-Xbootclasspath/a:<用 : 分隔的目录和 zip/jar 文件>附加在引导类路径末尾-Xbootclasspath/p:<用 : 分隔的目录和 zip/jar 文件>置于引导类路径之前-Xdiag            显示附加诊断消息-Xnoclassgc       禁用类垃圾收集-Xincgc           启用增量垃圾收集-Xloggc:<file>    将 GC 状态记录在文件中 (带时间戳)-Xbatch           禁用后台编译-Xms<size>        设置初始 Java 堆大小-Xmx<size>        设置最大 Java 堆大小-Xss<size>        设置 Java 线程堆栈大小-Xprof            输出 cpu 配置文件数据-Xfuture          启用最严格的检查, 预期将来的默认值-Xrs              减少 Java/VM 对操作系统信号的使用 (请参阅文档)-Xcheck:jni       对 JNI 函数执行其他检查-Xshare:off       不尝试使用共享类数据-Xshare:auto      在可能的情况下使用共享类数据 (默认)-Xshare:on        要求使用共享类数据, 否则将失败。-XshowSettings    显示所有设置并继续-XshowSettings:all显示所有设置并继续-XshowSettings:vm 显示所有与 vm 相关的设置并继续-XshowSettings:properties显示所有属性设置并继续-XshowSettings:locale显示所有与区域设置相关的设置并继续-X 选项是非标准选项, 如有更改, 恕不另行通知。

常用参数：

  • -Xms和-Xmx

-Xms 设置初始 Java 堆大小
-Xmx 设置最大 Java 堆大小

  • -Xint、-Xcomp、-Xmixed
  • 在解释模式(interpreted mode)下，-Xint标记会强制JVM执行所有的字节码，当然这会降低运行速度，通常低10倍或更多。
  • -Xcomp参数与它（-Xint）正好相反，JVM在第一次使用时会把所有的字节码编译成本地代码，从而带来最大程度的优化。编译模式下，第一次执行会比解释模式下执行慢一些。
    • 然而，很多应用在使用-Xcomp也会有一些性能损失，当然这比使用-Xint损失的少，原因是-xcomp没有让JVM启用JIT编译器的全部功能。JIT编译器可以对是否需要编译做判断，如果所有代码都进行编译的话，对于一些只执行一次的代码就没有意义了。
  • -Xmixed是混合模式，将解释模式与编译模式进行混合使用，由jvm自己决定，这是jvm默认的模式，也是推荐使用的模式。

2.3 -XX参数

-XX参数也是非标准参数，主要用于jvm的调优和debug操作。

-XX参数的使用有2种方式，一种是boolean类型，一种是非boolean类型：

  • boolean类型
    • 格式：-XX:[±]/ 表示启用或禁用/属性
    • 如：-XX:+DisableExplicitGC 表示禁用手动调用gc操作，也就是说调用System.gc()无效
  • 非boolean类型
    • 格式：-XX:/=/ 表示/属性的值为/
    • 如：-XX:NewRatio=1 表示新生代和老年代的比值

2.4 查看运行参数的命令（jinfo）

有些时候我们需要查看jvm的运行参数，这个需求可能会存在2种情况：

第一，运行java命令时打印出运行参数：

运行java命令时打印参数，需要添加-XX:+PrintFlagsFinal参数即可。

java -XX:+PrintFlagsFinal -version

由上述的命令打印出的结果，参数有boolean类型和数字类型，值的操作符是=或:=，分别代表默认值和被修改的值。

第二，查看正在运行的java进程的参数

jps -l	#查看进程号
jinfo -flags <进程号>	#查看所有参数
jinfo -flag <参数名> <进程id> #查看某一参数的值
jinfo -flag MaxHeapSize 6219 #查看最大堆内存

2.5 查看堆内存使用情况（jstat）

jstat -命令选项 间隔时间/毫秒
  • 查看class加载统计
# 先查询进程号
[root@node01 ~]# jstat -class 6219 
Loaded  Bytes  Unloaded  Bytes     Time   3273  7122.3        0     0.0       3.98

参数说明：

  • Loaded：加载class的数量
  • Bytes：所占用空间大小
  • Unloaded：未加载数量
  • Bytes：未加载占用空间
  • Time：时间
  • 查看编译统计
[root@node01 ~]# jstat -compiler 6219
Compiled Failed Invalid   Time   FailedType FailedMethod2376      1       0     8.04          1 org/apache/tomcat/util/IntrospectionUtils setProperty

参数说明：

  • Compiled：编译数量。
  • Failed：失败数量
  • Invalid：不可用数量
  • Time：时间
  • FailedType：失败类型
  • FailedMethod：失败的方法
  • 垃圾回收统计
[root@node01 ~]# jstat -gc 6219S0C    S1C    S0U    S1U      EC       EU        OC         OU       MC     MU    CCSC   CCSU   YGC     YGCT    FGC    FGCT     GCT   
9216.0 8704.0  0.0   6127.3 62976.0   3560.4   33792.0    20434.9   23808.0 23196.1 2560.0 2361.6      7    1.078   1      0.244    1.323#也可以指定打印的间隔和次数，每1秒中打印一次，共打印5次
[root@node01 ~]# jstat -gc 6219 1000 5S0C    S1C    S0U    S1U      EC       EU        OC         OU       MC     MU    CCSC   CCSU   YGC     YGCT    FGC    FGCT     GCT   
9216.0 8704.0  0.0   6127.3 62976.0   3917.3   33792.0    20434.9   23808.0 23196.1 2560.0 2361.6      7    1.078   1      0.244    1.323
9216.0 8704.0  0.0   6127.3 62976.0   3917.3   33792.0    20434.9   23808.0 23196.1 2560.0 2361.6      7    1.078   1      0.244    1.323
9216.0 8704.0  0.0   6127.3 62976.0   3917.3   33792.0    20434.9   23808.0 23196.1 2560.0 2361.6      7    1.078   1      0.244    1.323
9216.0 8704.0  0.0   6127.3 62976.0   3917.3   33792.0    20434.9   23808.0 23196.1 2560.0 2361.6      7    1.078   1      0.244    1.323
9216.0 8704.0  0.0   6127.3 62976.0   3917.3   33792.0    20434.9   23808.0 23196.1 2560.0 2361.6      7    1.078   1      0.244    1.323

参数说明：

  • S0C：第一个Survivor区的大小（KB）
  • S1C：第二个Survivor区的大小（KB）
  • S0U：第一个Survivor区的使用大小（KB）
  • S1U：第二个Survivor区的使用大小（KB）
  • EC：Eden区的大小（KB）
  • EU：Eden区的使用大小（KB）
  • OC：Old区大小（KB）
  • OU：Old使用大小（KB）
  • MC：方法区大小（KB）
  • MU：方法区使用大小（KB）
  • CCSC：压缩类空间大小（KB）
  • CCSU：压缩类空间使用大小（KB）
  • YGC：年轻代垃圾回收次数
  • YGCT：年轻代垃圾回收消耗时间
  • FGC：老年代垃圾回收次数
  • FGCT：老年代垃圾回收消耗时间
  • GCT：垃圾回收消耗总时间

3. 内存分析工具

3.1 查看堆内存使用情况（jmap）

[root@node01 ~]# jmap -heap 6219
Attaching to process ID 6219, please wait...
Debugger attached successfully.
Server compiler detected.
JVM version is 25.141-b15using thread-local object allocation.
Parallel GC with 2 thread(s)Heap Configuration: #堆内存配置信息MinHeapFreeRatio         = 0MaxHeapFreeRatio         = 100MaxHeapSize              = 488636416 (466.0MB)NewSize                  = 10485760 (10.0MB)MaxNewSize               = 162529280 (155.0MB)OldSize                  = 20971520 (20.0MB)NewRatio                 = 2SurvivorRatio            = 8MetaspaceSize            = 21807104 (20.796875MB)CompressedClassSpaceSize = 1073741824 (1024.0MB)MaxMetaspaceSize         = 17592186044415 MBG1HeapRegionSize         = 0 (0.0MB)Heap Usage: # 堆内存的使用情况
PS Young Generation #年轻代
Eden Space:capacity = 123731968 (118.0MB)used     = 1384736 (1.320587158203125MB)free     = 122347232 (116.67941284179688MB)1.1191416594941737% used
From Space:capacity = 9437184 (9.0MB)used     = 0 (0.0MB)free     = 9437184 (9.0MB)0.0% used
To Space:capacity = 9437184 (9.0MB)used     = 0 (0.0MB)free     = 9437184 (9.0MB)0.0% used
PS Old Generation #年老代capacity = 28311552 (27.0MB)used     = 13698672 (13.064071655273438MB)free     = 14612880 (13.935928344726562MB)48.38545057508681% used13648 interned Strings occupying 1866368 bytes.

3.2 查看内存中对象数量及大小

#查看所有对象，包括活跃以及非活跃的
jmap -histo <pid> | more#查看活跃对象
jmap -histo:live <pid> | more[root@node01 ~]# jmap -histo:live 6219 | morenum     #instances         #bytes  class name
----------------------------------------------1:         37437        7914608  [C2:         34916         837984  java.lang.String3:           884         654848  [B4:         17188         550016  java.util.HashMap$Node5:          3674         424968  java.lang.Class6:          6322         395512  [Ljava.lang.Object;7:          3738         328944  java.lang.reflect.Method8:          1028         208048  [Ljava.util.HashMap$Node;9:          2247         144264  [I10:          4305         137760  java.util.concurrent.ConcurrentHashMap$Node。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。#对象说明
B  byte
C  char
D  double
F  float
I  int
J  long
Z  boolean
[  数组，如[I表示int[]
[L+类名 其他对象

3.3 将内存使用情况dump到文件

有些时候我们需要将jvm当前内存中的情况dump到文件中，然后对它进行分析，jmap也是支持dump到文件中的。

#用法：
jmap -dump:format=b,file=dumpFileName <pid>#示例
jmap -dump:format=b,file=/tmp/dump.dat 6219

可以看到已经在/tmp下生成了dump.dat的文件。

3.4 对dump文件进行分析查看

（1）通过jhat进行分析

我们将jvm的内存dump到文件中，这个文件是一个二进制的文件，不方便查看，这时我们可以借助于jhat工具进行查看。

#用法：
jhat -port <port> <file>#示例：
[root@node01 tmp]# jhat -port 9999 /tmp/dump.dat 
Reading from /tmp/dump.dat...
Dump file created Mon Sep 10 01:04:21 CST 2018
Snapshot read, resolving...
Resolving 204094 objects...
Chasing references, expect 40 dots........................................
Eliminating duplicate references........................................
Snapshot resolved.
Started HTTP server on port 9999
Server is ready.

打开浏览器进行访问：http://ip:9999/

在最后面有OQL查询功能。

（2）通过map进行分析

MAT(Memory Analyzer Tool)，一个基于Eclipse的内存分析工具，是一个快速、功能丰富的JAVA heap分析工具，它可以帮助我们查找内存泄漏和减少内存消耗。使用内存分析工具从众多的对象中进行分析，快速的计算出在内存中对象的占用大小，看看是谁阻止了垃圾收集器的回收工作，并可以通过报表直观的查看到可能造成这种结果的对象。

官网地址：/

  • 下载安装

下载地址：.php

将下载得到的MemoryAnalyzer-1.8.0.20180604-win32.win32.x86_64.zip进行解压：

  • 使用

查看对象以及它的依赖：

查看可能存在内存泄露的分析：

4. 线程状态分析（jstack）

有些时候我们需要查看下jvm中的线程执行情况，比如，发现服务器的CPU的负载突然增高了、出现了死锁、死循环等，我们该如何分析呢？

由于程序是正常运行的，没有任何的输出，从日志方面也看不出什么问题，所以就需要看下jvm的内部线程的执行情况，然后再进行分析查找出原因。

这个时候，就需要借助于jstack命令了，jstack的作用是将正在运行的jvm的线程情况进行快照，并且打印出来：

在Java中线程的状态一共被分成6种：

  • 初始态（NEW）
    • 创建一个Thread对象，但还未调用start()启动线程时，线程处于初始态。
  • 运行态（RUNNABLE），在Java中，运行态包括 就绪态 和 运行态。
    • 就绪态
      • 该状态下的线程已经获得执行所需的所有资源，只要CPU分配执行权就能运行。
      • 所有就绪态的线程存放在就绪队列中。
    • 运行态
      • 获得CPU执行权，正在执行的线程。
      • 由于一个CPU同一时刻只能执行一条线程，因此每个CPU每个时刻只有一条运行态的线程。
  • 阻塞态（BLOCKED）
    • 当一条正在执行的线程请求某一资源失败时，就会进入阻塞态。
    • 而在Java中，阻塞态专指请求锁失败时进入的状态。
    • 由一个阻塞队列存放所有阻塞态的线程。
    • 处于阻塞态的线程会不断请求资源，一旦请求成功，就会进入就绪队列，等待执行。
  • 等待态（WAITING）
    • 当前线程中调用wait、join、park函数时，当前线程就会进入等待态。
    • 也有一个等待队列存放所有等待态的线程。
    • 线程处于等待态表示它需要等待其他线程的指示才能继续运行。
    • 进入等待态的线程会释放CPU执行权，并释放资源（如：锁）
  • 超时等待态（TIMED_WAITING）
    • 当运行中的线程调用sleep(time)、wait、join、parkNanos、parkUntil时，就会进入该状态；
    • 它和等待态一样，并不是因为请求不到资源，而是主动进入，并且进入后需要其他线程唤醒；
    • 进入该状态后释放CPU执行权 和 占有的资源。
    • 与等待态的区别：到了超时时间后自动进入阻塞队列，开始竞争锁。
  • 终止态（TERMINATED）
    • 线程执行结束后的状态。
[root@node01 ~]# jstack 3256
Full thread dump Java HotSpot(TM) 64-Bit Server VM (25.141-b15 mixed mode):"Attach Listener" #11 daemon prio=9 os_prio=0 tid=0x00007f5bfc001000 nid=0xcff waiting on condition [0x0000000000000000]java.lang.Thread.State: RUNNABLE"DestroyJavaVM" #10 prio=5 os_prio=0 tid=0x00007f5c2c008800 nid=0xcb9 waiting on condition [0x0000000000000000]java.lang.Thread.State: RUNNABLE...JNI global references: 6Found one Java-level deadlock:
=============================
"Thread-1":waiting to lock monitor 0x00007f5c080062c8 (object 0x00000000f655dc40, a java.lang.Object),which is held by "Thread-0"
"Thread-0":waiting to lock monitor 0x00007f5c08004e28 (object 0x00000000f655dc50, a java.lang.Object),which is held by "Thread-1"Java stack information for the threads listed above:
===================================================
"Thread-1":at TestDeadLock$Thread2.run(TestDeadLock.java:47)- waiting to lock <0x00000000f655dc40> (a java.lang.Object)- locked <0x00000000f655dc50> (a java.lang.Object)at java.lang.Thread.run(Thread.java:748)
"Thread-0":at TestDeadLock$Thread1.run(TestDeadLock.java:27)- waiting to lock <0x00000000f655dc50> (a java.lang.Object)- locked <0x00000000f655dc40> (a java.lang.Object)at java.lang.Thread.run(Thread.java:748)Found 1 deadlock.

可以清晰的看到：

  • Thread2获取了 <0x00000000f655dc50> 的锁，等待获取 <0x00000000f655dc40> 这个锁
  • Thread1获取了 <0x00000000f655dc40> 的锁，等待获取 <0x00000000f655dc50> 这个锁
  • 由此可见，发生了死锁。

5. visualVM工具的使用

VisualVM，能够监控线程，内存情况，查看方法的CPU时间和内存中的对 象，已被GC的对象，反向查看分配的堆栈(如100个String对象分别由哪几个对象分配出来的)。VisualVM使用简单，几乎0配置，功能还是比较丰富的，几乎囊括了其它JDK自带命令的所有功能。

（1）启动

在jdk的安装目录的bin目录下，找到jvisualvm.exe，双击打开即可。

（2）查看本地进程

（2）查看远程进程

VisualJVM不仅是可以监控本地jvm进程，还可以监控远程的jvm进程，需要借助于JMX技术实现。JMX（Java Management Extensions，即Java管理扩展）是一个为应用程序、设备、系统等植入管理功能的框架。JMX可以跨越一系列异构操作系统平台、系统体系结构和网络传输协议，灵活的开发无缝集成的系统、网络和服务管理应用。

  • 监控远程Tomcat为例

想要监控远程的tomcat，就需要在远程的tomcat进行对JMX配置，方法如下：

#在tomcat的bin目录下，修改catalina.sh，添加如下的参数JAVA_OPTS="-Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=9999 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false"#这几个参数的意思是：
#-Dcom.sun.management.jmxremote ：允许使用JMX远程管理
#-Dcom.sun.management.jmxremote.port=9999 ：JMX远程连接端口
#-Dcom.sun.management.jmxremote.authenticate=false ：不进行身份认证，任何用户都可以连接
#-Dcom.sun.management.jmxremote.ssl=false ：不使用ssl

保存退出，重启tomcat。

使用VisualJVM连接远程tomcat

在一个主机下可能会有很多的jvm需要监控，所以接下来要在该主机上添加需要监控的jvm：

连接成功。使用方法和前面就一样了，就可以和监控本地jvm进程一样，监控远程的tomcat进程。

5. 垃圾回收机制

5.1 垃圾回收算法

自动化的管理内存资源，垃圾回收机制必须要有一套算法来进行计算，哪些是有效的对象，哪些是无效的对象，对于无效的对象就要进行回收处理。

常见的垃圾回收算法有：引用计数法、标记清除法、标记整理法、复制算法、分代算法等。

5.1.1 引用计数法

引用计数是历史最悠久的一种算法，最早George E. Collins在1960的时候首次提出，50多年后的今天，该算法依然被很多编程语言使用。

（1）原理

假设有一个对象A，任何一个对象对A的引用，那么对象A的引用计数器+1，当引用失败时，对象A的引用计数器就-1，如果对象A的计数器的值为0，就说明对象A没有引用了，可以被回收。

（2）优缺点

优点：

  • 实时性较高，无需等到内存不够的时候，才开始回收，运行时根据对象的计数器是否为0，就可以直接回收。
  • 在垃圾回收过程中，应用无需挂起。如果申请内存时，内存不足，则立刻报outofmember 错误。
  • 区域性，更新对象的计数器时，只是影响到该对象，不会扫描全部对象。

缺点：

  • 每次对象被引用时，都需要去更新计数器，有一点时间开销。
  • 浪费CPU资源，即使内存够用，仍然在运行时进行计数器的统计。
  • 无法解决循环引用问题。（最大的缺点）

什么是循环引用？

class A{public B b;
}class B{public A a;
}public class Main{public static void main(String[] args){A a = new A();B b = new B();a.b=b;b.a=a;a = null;b = null;}
}

虽然a和b都为null，但是由于a和b存在循环引用，这样a和b永远都不会被回收。

5.1.2 标记清除法

标记清除算法，是将垃圾回收分为2个阶段，分别是标记和清除。

  • 标记：从根节点开始标记引用的对象。
  • 清除：未被标记引用的对象就是垃圾对象，可以被清理。

（1）原理

这张图代表的是程序运行期间所有对象的状态，它们的标志位全部是0（也就是未标记，以下默认0就是未标记，1为已标记），假设这会儿有效内存空间耗尽了，JVM将会停止应用程序的运行并开启GC线程，然后开始进行标记工作，按照根搜索算法，标记完以后，对象的状态如下图。

可以看到，按照根搜索算法，所有从root对象可达的对象就被标记为了存活的对象，此时已经完成了第一阶段标记。接下来，就要执行第二阶段清除了，那么清除完以后，剩下的对象以及对象的状态如下图所示。

可以看到，没有被标记的对象将会回收清除掉，而被标记的对象将会留下，并且会将标记位重新归0。接下来就不用说了，唤醒停止的程序线程，让程序继续运行即可。

（2）优缺点

可以看到，标记清除算法解决了引用计数算法中的循环引用的问题，没有从root节点引用的对象都会被回收。

同样，标记清除算法也是有缺点的：

  • 效率较低，标记和清除两个动作都需要遍历所有的对象，并且在GC时，需要停止应用程序，对于交互性要求比较高的应用而言这个体验是非常差的。
  • 通过标记清除算法清理出来的内存，碎片化较为严重，因为被回收的对象可能存在于内存的各个角落，所以清理出来的内存是不连贯的。
5.1.3 标记整理算法

标记压缩算法是在标记清除算法的基础之上，做了优化改进的算法。和标记清除算法一样，也是从根节点开始，对对象的引用进行标记，在清理阶段，并不是简单的清理未标记的对象，而是将存活的对象压缩到内存的一端，然后清理边界以外的垃圾，从而解决了碎片化的问题。

（1）原理

（2）优缺点

优缺点同标记清除算法，解决了标记清除算法的碎片化的问题，同时，标记压缩算法多了一步，对象移动内存位置的步骤，其效率也有有一定的影响。

5.1.4 复制算法

复制算法的核心就是，将原有的内存空间一分为二，每次只用其中的一块，在垃圾回收时，将正在使用的对象复制到另一个内存空间中，然后将该内存空间清空，交换两个内存的角色，完成垃圾的回收。

如果内存中的垃圾对象较多，需要复制的对象就较少，这种情况下适合使用该方式并且效率比较高，反之，则不适合。

  • JVM中年轻代内存空间

  1. 在GC开始的时候，对象只会存在于Eden区和名为“From”的Survivor区，Survivor区“To”是空的。
  2. 紧接着进行GC，Eden区中所有存活的对象都会被复制到“To”，而在“From”区中，仍存活的对象会根据他们的年龄值来决定去向。年龄达到一定值(年龄阈值，可以通过-XX:MaxTenuringThreshold来设置)的对象会被移动到年老代中，没有达到阈值的对象会被复制到“To”区域。
  3. 经过这次GC后，Eden区和From区已经被清空。这个时候，“From”和“To”会交换他们的角色，也就是新的“To”就是上次GC前的“From”，新的“From”就是上次GC前的“To”。不管怎样，都会保证名为To的Survivor区域是空的。
  4. GC会一直重复这样的过程，直到“To”区被填满，“To”区被填满之后，会将所有对象移动到年老代中。

（2）优缺点

优点：

  • 在垃圾对象多的情况下，效率较高
  • 清理后，内存无碎片

缺点：

  • 在垃圾对象少的情况下，不适用，如：老年代内存
  • 分配的2块内存空间，在同一个时刻，只能使用一半，内存使用率较低
5.1.5 分代算法

前面介绍了多种回收算法，每一种算法都有自己的优点也有缺点，谁都不能替代谁，所以根据垃圾回收对象的特点进行选择，才是明智的选择。

分代算法其实就是这样的，根据回收对象的特点进行选择，在jvm中，年轻代适合使用复制算法，老年代适合使用标记清除或标记压缩算法。

5.2 垃圾收集器

前面我们讲了垃圾回收的算法，还需要有具体的实现，在jvm中，实现了多种垃圾收集器，包括：串行垃圾收集器、并行垃圾收集器、CMS（并发）垃圾收集器、G1垃圾收集器，接下来，我们一个个的了解学习。

5.2.1 串行垃圾收集器

串行垃圾收集器，是指使用单线程进行垃圾回收，垃圾回收时，只有一个线程在工作，并且java应用中的所有线程都要暂停，等待垃圾回收的完成。这种现象称之为STW（Stop-The-World）。

对于交互性较强的应用而言，这种垃圾收集器是不能够接受的。一般在Javaweb应用中是不会采用该收集器的。

在程序运行参数中添加2个参数，如下：

  • -XX:+UseSerialGC
    • 指定年轻代和老年代都使用串行垃圾收集器
  • -XX:+PrintGCDetails
    • 打印垃圾回收的详细信息
# 为了测试GC，将堆的初始和最大内存都设置为16M
-XX:+UseSerialGC -XX:+PrintGCDetails -Xms16m -Xmx16m

启动程序，可以看到下面信息：

[GC (Allocation Failure) [DefNew: 4416K->512K(4928K), 0.0046102 secs] 4416K->1973K(15872K), 0.0046533 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] [Full GC (Allocation Failure) [Tenured: 10944K->3107K(10944K), 0.0085637 secs] 15871K->3107K(15872K), [Metaspace: 3496K->3496K(1056768K)], 0.0085974 secs] [Times: user=0.02 sys=0.00, real=0.01 secs]

GC日志信息解读：

年轻代的内存GC前后的大小：

  • DefNew
    • 表示使用的是串行垃圾收集器。
  • 4416K->512K(4928K)
    • 表示，年轻代GC前，占有4416K内存，GC后，占有512K内存，总大小4928K
  • 0.0046102 secs
    • 表示，GC所用的时间，单位为秒。
  • 4416K->1973K(15872K)
    • 表示，GC前，堆内存占有4416K，GC后，占有1973K，总大小为15872K
  • Full GC
    • 表示，内存空间全部进行GC
5.2.1 并行垃圾收集器

并行垃圾收集器在串行垃圾收集器的基础之上做了改进，将单线程改为了多线程进行垃圾回收，这样可以缩短垃圾回收的时间。（这里是指，并行能力较强的机器）

当然了，并行垃圾收集器在收集的过程中也会暂停应用程序，这个和串行垃圾回收器是一样的，只是并行执行，速度更快些，暂停的时间更短一些。

ParNew垃圾收集器是工作在年轻代上的，只是将串行的垃圾收集器改为了并行。

通过-XX:+UseParNewGC参数设置年轻代使用ParNew回收器，老年代使用的依然是串行收集器。

#参数
-XX:+UseParNewGC -XX:+PrintGCDetails -Xms16m -Xmx16m#打印出的信息
[GC (Allocation Failure) [ParNew: 4416K->512K(4928K), 0.0032106 secs] 4416K->1988K(15872K), 0.0032697 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]

由以上信息可以看出，ParNew: 使用的是ParNew收集器。其他信息和串行收集器一致。

5.2.3 ParallelGC垃圾收集器

ParallelGC收集器工作机制和ParNewGC收集器一样，只是在此基础之上，新增了两个和系统吞吐量相关的参数，使得其使用起来更加的灵活和高效。

相关参数如下：

  • -XX:+UseParallelGC
    • 年轻代使用ParallelGC垃圾回收器，老年代使用串行回收器。
  • -XX:+UseParallelOldGC
    • 年轻代使用ParallelGC垃圾回收器，老年代使用ParallelOldGC垃圾回收器。
  • -XX:MaxGCPauseMillis
    • 设置最大的垃圾收集时的停顿时间，单位为毫秒
    • 需要注意的时，ParallelGC为了达到设置的停顿时间，可能会调整堆大小或其他的参数，如果堆的大小设置的较小，就会导致GC工作变得很频繁，反而可能会影响到性能。
    • 该参数使用需谨慎。
  • -XX:GCTimeRatio
    • 设置垃圾回收时间占程序运行时间的百分比，公式为1/(1+n)。
    • 它的值为0~100之间的数字，默认值为99，也就是垃圾回收时间不能超过1%
  • -XX:UseAdaptiveSizePolicy
    • 自适应GC模式，垃圾回收器将自动调整年轻代、老年代等参数，达到吞吐量、堆大小、停顿时间之间的平衡。
    • 一般用于，手动调整参数比较困难的场景，让收集器自动进行调整。

#参数
-XX:+UseParallelGC -XX:+UseParallelOldGC -XX:MaxGCPauseMillis=100 -XX:+PrintGCDetails -Xms16m -Xmx16m#打印的信息
[GC (Allocation Failure) [PSYoungGen: 4096K->480K(4608K)] 4096K->1840K(15872K), 0.0034307 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] [Full GC (Ergonomics) [PSYoungGen: 505K->0K(4608K)] [ParOldGen: 10332K->10751K(11264K)] 10837K->10751K(15872K), [Metaspace: 3491K->3491K(1056768K)], 0.0793622 secs] [Times: user=0.13 sys=0.00, real=0.08 secs]

有以上信息可以看出，年轻代和老年代都使用了ParallelGC垃圾回收器。

5.2.4 CMS垃圾收集器

CMS全称 Concurrent Mark Sweep，是一款并发的、使用标记-清除算法的垃圾回收器，该回收器是针对老年代垃圾回收的，通过参数-XX:+UseConcMarkSweepGC进行设置。

CMS垃圾回收器的执行过程如下：

  • 初始化标记(CMS-initial-mark) ,标记root，会导致stw；
  • 并发标记(CMS-concurrent-mark)，与用户线程同时运行；
  • 预清理（CMS-concurrent-preclean），与用户线程同时运行；
  • 重新标记(CMS-remark) ，会导致stw；
  • 并发清除(CMS-concurrent-sweep)，与用户线程同时运行；
  • 调整堆大小，设置CMS在清理之后进行内存压缩，目的是清理内存中的碎片；
  • 并发重置状态等待下次CMS的触发(CMS-concurrent-reset)，与用户线程同时运行；
#设置启动参数
-XX:+UseConcMarkSweepGC -XX:+PrintGCDetails -Xms16m -Xmx16m#运行日志
[GC (Allocation Failure) [ParNew: 4926K->512K(4928K), 0.0041843 secs] 9424K->6736K(15872K), 0.0042168 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] #第一步，初始标记
[GC (CMS Initial Mark) [1 CMS-initial-mark: 6224K(10944K)] 6824K(15872K), 0.0004209 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
#第二步，并发标记
[CMS-concurrent-mark-start]
[CMS-concurrent-mark: 0.002/0.002 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
#第三步，预处理
[CMS-concurrent-preclean-start]
[CMS-concurrent-preclean: 0.000/0.000 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
#第四步，重新标记
[GC (CMS Final Remark) [YG occupancy: 1657 K (4928 K)][Rescan (parallel) , 0.0005811 secs][weak refs processing, 0.0000136 secs][class unloading, 0.0003671 secs][scrub symbol table, 0.0006813 secs][scrub string table, 0.0001216 secs][1 CMS-remark: 6224K(10944K)] 7881K(15872K), 0.0018324 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
#第五步，并发清理
[CMS-concurrent-sweep-start]
[CMS-concurrent-sweep: 0.004/0.004 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
#第六步，重置
[CMS-concurrent-reset-start]
[CMS-concurrent-reset: 0.000/0.000 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]

由以上日志信息，可以看出CMS执行的过程。

5.2.5 G1垃圾收集器（重点）

G1垃圾收集器是在jdk1.7中正式使用的全新的垃圾收集器，oracle官方计划在jdk9中将G1变成默认的垃圾收集器，以替代CMS。

G1的设计原则就是简化JVM性能调优，开发人员只需要简单的三步即可完成调优：

  1. 第一步，开启G1垃圾收集器
  2. 第二步，设置堆的最大内存
  3. 第三步，设置最大的停顿时间

G1中提供了三种模式垃圾回收模式，Young GC、Mixed GC 和 Full GC，在不同的条件下被触发。

（1）原理

G1垃圾收集器相对比其他收集器而言，最大的区别在于它取消了年轻代、老年代的物理划分，取而代之的是将堆划分为若干个区域（Region），这些区域中包含了有逻辑上的年轻代、老年代区域。

这样做的好处就是，我们再也不用单独的空间对每个代进行设置了，不用担心每个代内存是否足够。

在G1划分的区域中，年轻代的垃圾收集依然采用暂停所有应用线程的方式，将存活对象拷贝到老年代或者Survivor空间，G1收集器通过将对象从一个区域复制到另外一个区域，完成了清理工作。

这就意味着，在正常的处理过程中，G1完成了堆的压缩（至少是部分堆的压缩），这样也就不会有cms内存碎片问题的存在了。

在G1中，有一种特殊的区域，叫Humongous区域。

  • 如果一个对象占用的空间超过了分区容量50%以上，G1收集器就认为这是一个巨型对象。
  • 这些巨型对象，默认直接会被分配在老年代，但是如果它是一个短期存在的巨型对象，就会对垃圾收集器造成负面影响。
  • 为了解决这个问题，G1划分了一个Humongous区，它用来专门存放巨型对象。如果一个H区装不下一个巨型对象，那么G1会寻找连续的H分区来存储。为了能找到连续的H区，有时候不得不启动Full GC。

（2）Young GC

Young GC主要是对Eden区进行GC，它在Eden空间耗尽时会被触发。

  • Eden空间的数据移动到Survivor空间中，如果Survivor空间不够，Eden空间的部分数据会直接晋升到年老代空间。
  • Survivor区的数据移动到新的Survivor区中，也有部分数据晋升到老年代空间中。
  • 最终Eden空间的数据为空，GC停止工作，应用线程继续执行。

Remembered Set（已记忆集合）

在GC年轻代的对象时，我们如何找到年轻代中对象的根对象呢？

根对象可能是在年轻代中，也可以在老年代中，那么老年代中的所有对象都是根么？

如果全量扫描老年代，那么这样扫描下来会耗费大量的时间。

于是，G1引进了RSet的概念。它的全称是Remembered Set，其作用是跟踪指向某个堆内的对象引用。

每个Region初始化时，会初始化一个RSet，该集合用来记录并跟踪其它Region指向该Region中对象的引用，每个Region默认按照512Kb划分成多个Card，所以RSet需要记录的东西应该是 xx Region的 xx Card。

（2）Mixed GC

当越来越多的对象晋升到老年代old region时，为了避免堆内存被耗尽，虚拟机会触发一个混合的垃圾收集器，即Mixed GC，该算法并不是一个Old GC，除了回收整个Young Region，还会回收一部分的Old Region，这里需要注意：是一部分老年代，而不是全部老年代，可以选择哪些old region进行收集，从而可以对垃圾回收的耗时时间进行控制。也要注意的是Mixed GC 并不是 Full GC。

MixedGC什么时候触发？ 由参数 -XX:InitiatingHeapOccupancyPercent=n 决定。默认：45%，该参数的意思是：当老年代大小占整个堆大小百分比达到该阀值时触发。

它的GC步骤分2步：

  1. 全局并发标记（global concurrent marking）
  2. 拷贝存活对象（evacuation）

1）全局并发标记

全局并发标记，执行过程分为五个步骤：

  • 初始标记（initial mark，STW）
    • 标记从根节点直接可达的对象，这个阶段会执行一次年轻代GC，会产生全局停顿。
  • 根区域扫描（root region scan）
    • G1 GC 在初始标记的存活区扫描对老年代的引用，并标记被引用的对象。
    • 该阶段与应用程序（非 STW）同时运行，并且只有完成该阶段后，才能开始下一次 STW 年轻代垃圾回收。
  • 并发标记（Concurrent Marking）
    • G1 GC 在整个堆中查找可访问的（存活的）对象。该阶段与应用程序同时运行，可以被 STW 年轻代垃圾回收中断。
  • 重新标记（Remark，STW）
    • 该阶段是 STW 回收，因为程序在运行，针对上一次的标记进行修正。
  • 清除垃圾（Cleanup，STW）
    • 清点和重置标记状态，该阶段会STW，这个阶段并不会实际上去做垃圾的收集，等待evacuation阶段来回收。

2）拷贝存活对象

Evacuation阶段是全暂停的。该阶段把一部分Region里的活对象拷贝到另一部分Region中，从而实现垃圾的回收清理。

5.2.6 G1收集器相关参数
  • -XX:+UseG1GC
    • 使用 G1 垃圾收集器
  • -XX:MaxGCPauseMillis
    • 设置期望达到的最大GC停顿时间指标（JVM会尽力实现，但不保证达到），默认值是 200 毫秒。
  • -XX:G1HeapRegionSize=n
    • 设置的 G1 区域的大小。值是 2 的幂，范围是 1 MB 到 32 MB 之间。目标是根据最小的 Java 堆大小划分出约 2048 个区域。
    • 默认是堆内存的1/2000。
  • -XX:ParallelGCThreads=n
    • 设置 STW 工作线程数的值。将 n 的值设置为逻辑处理器的数量。n 的值与逻辑处理器的数量相同，最多为 8。
  • -XX:ConcGCThreads=n
    • 设置并行标记的线程数。将 n 设置为并行垃圾回收线程数 (ParallelGCThreads) 的 1/4 左右。
  • -XX:InitiatingHeapOccupancyPercent=n
    • 设置触发标记周期的 Java 堆占用率阈值。默认占用率是整个 Java 堆的 45%。
-XX:+UseG1GC -XX:MaxGCPauseMillis=100 -XX:+PrintGCDetails -Xmx256m#日志
[GC pause (G1 Evacuation Pause) (young), 0.0044882 secs][Parallel Time: 3.7 ms, GC Workers: 3][GC Worker Start (ms): Min: 14763.7, Avg: 14763.8, Max: 14763.8, Diff: 0.1]#扫描根节点[Ext Root Scanning (ms): Min: 0.2, Avg: 0.3, Max: 0.3, Diff: 0.1, Sum: 0.8]#更新RS区域所消耗的时间[Update RS (ms): Min: 1.8, Avg: 1.9, Max: 1.9, Diff: 0.2, Sum: 5.6][Processed Buffers: Min: 1, Avg: 1.7, Max: 3, Diff: 2, Sum: 5][Scan RS (ms): Min: 0.0, Avg: 0.0, Max: 0.0, Diff: 0.0, Sum: 0.0][Code Root Scanning (ms): Min: 0.0, Avg: 0.0, Max: 0.0, Diff: 0.0, Sum: 0.0]#对象拷贝[Object Copy (ms): Min: 1.1, Avg: 1.2, Max: 1.3, Diff: 0.2, Sum: 3.6][Termination (ms): Min: 0.0, Avg: 0.1, Max: 0.2, Diff: 0.2, Sum: 0.2][Termination Attempts: Min: 1, Avg: 1.0, Max: 1, Diff: 0, Sum: 3][GC Worker Other (ms): Min: 0.0, Avg: 0.0, Max: 0.0, Diff: 0.0, Sum: 0.0][GC Worker Total (ms): Min: 3.4, Avg: 3.4, Max: 3.5, Diff: 0.1, Sum: 10.3][GC Worker End (ms): Min: 14767.2, Avg: 14767.2, Max: 14767.3, Diff: 0.1][Code Root Fixup: 0.0 ms][Code Root Purge: 0.0 ms][Clear CT: 0.0 ms] #清空CardTable[Other: 0.7 ms][Choose CSet: 0.0 ms] #选取CSet[Ref Proc: 0.5 ms] #弱引用、软引用的处理耗时[Ref Enq: 0.0 ms] #弱引用、软引用的入队耗时[Redirty Cards: 0.0 ms][Humongous Register: 0.0 ms] #大对象区域注册耗时[Humongous Reclaim: 0.0 ms] #大对象区域回收耗时[Free CSet: 0.0 ms][Eden: 7168.0K(7168.0K)->0.0B(13.0M) Survivors: 2048.0K->2048.0K Heap: 55.5M(192.0M)->48.5M(192.0M)] #年轻代的大小统计[Times: user=0.00 sys=0.00, real=0.00 secs]
5.2.7 G1垃圾收集器优化建议
  • 年轻代大小
    • 避免使用 -Xmn 选项或 -XX:NewRatio 等其他相关选项显式设置年轻代大小。
    • 固定年轻代的大小会覆盖暂停时间目标。
  • 暂停时间目标不要太过严苛
    • G1 GC 的吞吐量目标是 90% 的应用程序时间和 10%的垃圾回收时间。
    • 评估 G1 GC 的吞吐量时，暂停时间目标不要太严苛。目标太过严苛表示您愿意承受更多的垃圾回收开销，而这会直接影响到吞吐量。

6. GC日志分析可视化工具

6.1 GC日志输出参数

前面通过-XX:+PrintGCDetails可以对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:+UseG1GC -XX:MaxGCPauseMillis=100 -Xmx256m -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintGCDateStamps -XX:+PrintHeapAtGC -Xloggc:F://test//gc.log

运行后就可以在E盘下生成gc.log文件。

如下：

Java HotSpot(TM) 64-Bit Server VM (25.144-b01) for windows-amd64 JRE (1.8.0_144-b01), built on Jul 21 2017 21:57:33 by "java_re" with MS VC++ 10.0 (VS2010)
Memory: 4k page, physical 12582392k(1939600k free), swap 17300984k(5567740k free)
CommandLine flags: -XX:InitialHeapSize=201318272 -XX:MaxGCPauseMillis=100 -XX:MaxHeapSize=268435456 -XX:+PrintGC -XX:+PrintGCDateStamps -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintHeapAtGC -XX:+UseCompressedClassPointers -XX:+UseCompressedOops -XX:+UseG1GC -XX:-UseLargePagesIndividualAllocation 
{Heap before GC invocations=0 (full 0):garbage-first heap   total 196608K, used 9216K [0x00000000f0000000, 0x00000000f0100600, 0x0000000100000000)region size 1024K, 9 young (9216K), 0 survivors (0K)Metaspace       used 3491K, capacity 4500K, committed 4864K, reserved 1056768Kclass space    used 381K, capacity 388K, committed 512K, reserved 1048576K
2018-09-24T23:06:02.230+0800: 0.379: [GC pause (G1 Evacuation Pause) (young), 0.0031038 secs][Parallel Time: 2.8 ms, GC Workers: 3][GC Worker Start (ms): Min: 378.6, Avg: 378.8, Max: 379.0, Diff: 0.3][Ext Root Scanning (ms): Min: 0.0, Avg: 0.4, Max: 0.8, Diff: 0.8, Sum: 1.3][Update RS (ms): Min: 0.0, Avg: 0.0, Max: 0.0, Diff: 0.0, Sum: 0.0][Processed Buffers: Min: 0, Avg: 0.0, Max: 0, Diff: 0, Sum: 0][Scan RS (ms): Min: 0.0, Avg: 0.0, Max: 0.0, Diff: 0.0, Sum: 0.0][Code Root Scanning (ms): Min: 0.0, Avg: 0.0, Max: 0.1, Diff: 0.1, Sum: 0.1][Object Copy (ms): Min: 1.8, Avg: 1.9, Max: 1.9, Diff: 0.1, Sum: 5.6][Termination (ms): Min: 0.0, Avg: 0.0, Max: 0.0, Diff: 0.0, Sum: 0.0][Termination Attempts: Min: 1, Avg: 1.0, Max: 1, Diff: 0, Sum: 3][GC Worker Other (ms): Min: 0.0, Avg: 0.2, Max: 0.6, Diff: 0.6, Sum: 0.6][GC Worker Total (ms): Min: 2.4, Avg: 2.5, Max: 2.7, Diff: 0.3, Sum: 7.6][GC Worker End (ms): Min: 381.4, Avg: 381.4, Max: 381.4, Diff: 0.0][Code Root Fixup: 0.0 ms][Code Root Purge: 0.0 ms][Clear CT: 0.0 ms][Other: 0.2 ms][Choose CSet: 0.0 ms][Ref Proc: 0.1 ms][Ref Enq: 0.0 ms][Redirty Cards: 0.0 ms][Humongous Register: 0.0 ms][Humongous Reclaim: 0.0 ms][Free CSet: 0.0 ms][Eden: 9216.0K(9216.0K)->0.0B(7168.0K) Survivors: 0.0B->2048.0K Heap: 9216.0K(192.0M)->1888.0K(192.0M)]
Heap after GC invocations=1 (full 0):garbage-first heap   total 196608K, used 1888K [0x00000000f0000000, 0x00000000f0100600, 0x0000000100000000)region size 1024K, 2 young (2048K), 2 survivors (2048K)Metaspace       used 3491K, capacity 4500K, committed 4864K, reserved 1056768Kclass space    used 381K, capacity 388K, committed 512K, reserved 1048576K
}[Times: user=0.00 sys=0.00, real=0.00 secs] 
{Heap before GC invocations=1 (full 0):garbage-first heap   total 196608K, used 9056K [0x00000000f0000000, 0x00000000f0100600, 0x0000000100000000)region size 1024K, 9 young (9216K), 2 survivors (2048K)Metaspace       used 3492K, capacity 4500K, committed 4864K, reserved 1056768Kclass space    used 381K, capacity 388K, committed 512K, reserved 1048576K
2018-09-24T23:06:02.310+0800: 0.458: [GC pause (G1 Evacuation Pause) (young), 0.0070126 secs]
。。。。。。。。。。。。。。。。。。。

6.2 GC Easy 可视化工具

GC Easy是一款在线的可视化工具，易用、功能强大，网站：/

上传后，点击“Analyze”按钮，即可查看报告。

7. JVM优化

.html

为降低应用软件的垃圾回收时的停顿，首先考虑的是使用关注系统停顿的 CMS 回收器，其次，为了减少 Full GC 次数，应尽可能将对象预留在年轻代，因为年轻代 Minor GC 的成本远远小于年老代的 Full GC。

java –Xmx3550m –Xms3550m –Xmn2g –Xss128k –XX:ParallelGCThreads=20–XX:+UseConcMarkSweepGC –XX:+UseParNewGC –XX:+SurvivorRatio=8 –XX:TargetSurvivorRatio=90–XX:MaxTenuringThreshold=31

–XX:ParallelGCThreads=20：设置 20 个线程进行垃圾回收；

–XX:+UseParNewGC：年轻代使用并行回收器；

–XX:+UseConcMarkSweepGC：年老代使用 CMS 收集器降低停顿；

–XX:+SurvivorRatio：设置 Eden 区和 Survivor 区的比例为 8:1。稍大的 Survivor 空间可以提高在年轻代回收生命周期较短的对象的可能性，如果 Survivor 不够大，一些短命的对象可能直接进入年老代，这对系统来说是不利的。

–XX:TargetSurvivorRatio=90：设置 Survivor 区的可使用率。这里设置为 90%，则允许 90%的 Survivor 空间被使用。默认值是 50%。故该设置提高了 Survivor 区的使用率。当存放的对象超过这个百分比，则对象会向年老代压缩。因此，这个选项更有助于将对象留在年轻代。

–XX:MaxTenuringThreshold：设置年轻对象晋升到年老代的年龄。默认值是 15 次，即对象经过 15 次 Minor GC 依然存活，则进入年老代。这里设置为 31，目的是让对象尽可能地保存在年轻代区域。

本文标签： JVM知识点总结

版权声明：本文标题：JVM知识点总结 内容由网友自发贡献，该文观点仅代表作者本人， 转载请联系作者并注明出处：http://www.freenas.com.cn/jishu/1732352130h1533387.html， 本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，一经查实，本站将立刻删除。