在本篇开始之前，需要了解JVM理论知识，不懂的可以跳转深入浅出JVM，看完你就懂
概念
企业级Java开发中，会碰到如下问题
1.OutOfMemoryError，内存不足
2.内存溢出
3.线程锁死
4.锁征用
5.Java进程消耗CPU过高
通过JVM一些常用的监控性能调优工具，可以很好的监控与发现问题所在。
JVM内存模型
区分为堆区(heap)、栈区(stack)和方法区(method)。由于本文主要讲解JVM调优，因此我们可以简单的理解为，JVM中的堆区中存放的是实际的对象，是需要被GC的。其他的都无需GC。
下图文JVM的内存模型
从图中我们可以看到，
1、JVM实质上分为三大块，年轻代(YoungGen)，年老代(Old Memory)，及持久代(Perm，在Java8中被取消，我们不做深入介绍)。
2、垃圾回收GC，分为2种，一是Minor GC，可以可以称为YGC，即年轻代GC，当Eden区，还有一种称为Major GC，又称为FullGC。
3、GC原理：
我们可以看到年轻代包括Eden区(对象刚被new出来的时候，放到该区)，S0和S1，是幸存者1区和幸存者2区，从名字可以看出，是当发生YGC，没有被任何其他对象所引用的对象将会从内存中被清除，还被其他对象引用的则放到幸存者区。当发生多次YGC，在S0、S1区多次没有被清楚的对象，则会被移到老年代区域。当老年代区域被占满的时候，则会发送FullGC。
无论是YGC或是FullGC，都会导致stop-the-world，即整个程序停止一些事务的处理，只有GC进程允许以进行垃圾回收，因此如果垃圾回收时间较长，部分web或socket程序，当终端连接的时候会报connetTimeOut或readTimeOut异常，
4、从JVM调优的角度来看，我们应该尽量避免发生YGC或FullGC，或者使得YGC和FullGC的时间足够的短。
监控&诊断工具
命令行工具
官方帮助文档：https://docs.oracle.com/en/java/javase/11/tools/jstack.html
jps：查看正在运行的Java进程
jstat：查看JVM统计信息
# 查看GC次数，时间等信息，每隔一秒打印一次
jstat -gcutil pid 1000
jinfo：实时查看和修改JVM配置参数
jmap：导出内存映像文件&内存使用情况
# 堆使用情况
jmap -heap pid
# dump堆内存信息到文件
jmap -dump:live,format=b,file=/home/myheapdump.hprof PID
# 查看堆内存占用空间最大的前20个对象类型,可初步查看是哪个对象占用了内存
jmap -histo PID | head -20
jhat：JDK自带堆分析工具
jstack：查看某个Java进程内线程dump
jstack 29452 > 29452.txt
jcmd：多功能命令行，可以用来实现前面除了jstat之外所有命令的功能
jstatd：远程主机信息收集
GUI工具
JConsole
jvisualvm
JProfiler
Arthas
MAT
JVM运行时参数
JVM参数选项
官网地址：https://docs.oracle.com/javase/8/docs/technotes/tools/windows/java.html
类型一：标准参数选项
> 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>
使用指定的图像显示启动屏幕
有关详细信息, 请参阅 http://www.oracle.com/technetwork/java/javase/documentation/index.html。
Server模式和Client模式
Hotspot JVM有两种模式，分别是server和client，分别通过-server和-client模式设置
-
32位系统上，默认使用Client类型的JVM。要想使用Server模式，机器配置至少有2个以上的CPU和2G以上的物理内存。client模式适用于对内存要求较小的桌面应用程序，默认使用Serial串行垃圾收集器
-
64位系统上，只支持server模式的JVM，适用于需要大内存的应用程序，默认使用并行垃圾收集器
官网地址：https://docs.oracle.com/javase/8/docs/technotes/guides/vm/server-class.html
如何知道系统默认使用的是那种模式呢？
通过java -version命令：可以看到Server VM字样，代表当前系统使用是Server模式
> java -version
java version "1.8.0_201"
Java(TM) SE Runtime Environment (build 1.8.0_201-b09)
Java HotSpot(TM) 64-Bit Server VM (build 25.201-b09, mixed mode)
类型二：-X参数选项
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 选项是非标准选项, 如有更改, 恕不另行通知。
如何知道JVM默认使用的是混合模式呢？
同样地，通过java -version命令：可以看到 mixed mode 字样，代表当前系统使用的是混合模式
类型三：-XX参数选项
Boolean类型格式
-XX:+<option> 启用option属性
-XX:-<option> 禁用option属性
非Boolean类型格式
-XX:<option>=<number> 设置option数值，可以带单位如k/K/m/M/g/G
-XX:<option>=<string> 设置option字符值
添加JVM参数选项
eclipse和idea中配置不必多说，在Run Configurations中VM Options中配置即可，大同小异
运行jar包
java -Xms100m -Xmx100m -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+PrintGCTimeStamps -jar demo.jar
Tomcat运行war包
# linux下catalina.sh添加
JAVA_OPTS="-Xms512M -Xmx1024M"
# windows下catalina.bat添加
set "JAVA_OPTS=-Xms512M -Xmx1024M"
程序运行中
# 设置Boolean类型参数
jinfo -flag [+|-]<name> <pid>
# 设置非Boolean类型参数
jinfo -flag <name>=<value> <pid>
常用的JVM参数选项
打印设置的XX选项及值
-XX:+PrintCommandLineFlags 程序运行时JVM默认设置或用户手动设置的XX选项
-XX:+PrintFlagsInitial 打印所有XX选项的默认值
-XX:+PrintFlagsFinal 打印所有XX选项的实际值
-XX:+PrintVMOptions 打印JVM的参数
堆、栈、方法区等内存大小设置
# 栈
-Xss128k <==> -XX:ThreadStackSize=128k 设置线程栈的大小为128K
# 堆
-Xms2048m <==> -XX:InitialHeapSize=2048m 设置JVM初始堆内存为2048M
-Xmx2048m <==> -XX:MaxHeapSize=2048m 设置JVM最大堆内存为2048M
-Xmn2g <==> -XX:NewSize=2g -XX:MaxNewSize=2g 设置年轻代大小为2G
-XX:SurvivorRatio=8 设置Eden区与Survivor区的比值，默认为8
-XX:NewRatio=2 设置老年代与年轻代的比例，默认为2
-XX:+UseAdaptiveSizePolicy 设置大小比例自适应，默认开启
-XX:PretenureSizeThreadshold=1024 设置让大于此阈值的对象直接分配在老年代，只对Serial、ParNew收集器有效
-XX:MaxTenuringThreshold=15 设置新生代晋升老年代的年龄限制，默认为15
-XX:TargetSurvivorRatio 设置MinorGC结束后Survivor区占用空间的期望比例
# 方法区
-XX:MetaspaceSize / -XX:PermSize=256m 设置元空间/永久代初始值为256M
-XX:MaxMetaspaceSize / -XX:MaxPermSize=256m 设置元空间/永久代最大值为256M
-XX:+UseCompressedOops 使用压缩对象
-XX:+UseCompressedClassPointers 使用压缩类指针
-XX:CompressedClassSpaceSize 设置Klass Metaspace的大小，默认1G
# 直接内存
-XX:MaxDirectMemorySize 指定DirectMemory容量，默认等于Java堆最大值
OutOfMemory相关的选项
-XX:+HeapDumpOnOutOfMemoryError 内存出现OOM时生成Heap转储文件，两者互斥
-XX:+HeapDumpBeforeFullGC 出现FullGC时生成Heap转储文件，两者互斥
-XX:HeapDumpPath=<path> 指定heap转储文件的存储路径，默认当前目录
-XX:OnOutOfMemoryError=<path> 指定可行性程序或脚本的路径，当发生OOM时执行脚本
垃圾收集器相关选项
首先需了解垃圾收集器之间的搭配使用关系
-
红色虚线表示在jdk8时被Deprecate，jdk9时被删除
-
绿色虚线表示在jdk14时被Deprecate
-
绿色虚框表示在jdk9时被Deprecate，jdk14时被删除
# Serial回收器
-XX:+UseSerialGC 年轻代使用Serial GC， 老年代使用Serial Old GC
# ParNew回收器
-XX:+UseParNewGC 年轻代使用ParNew GC
-XX:ParallelGCThreads 设置年轻代并行收集器的线程数。
一般地，最好与CPU数量相等，以避免过多的线程数影响垃圾收集性能。
# Parallel回收器
-XX:+UseParallelGC 年轻代使用 Parallel Scavenge GC，互相激活
-XX:+UseParallelOldGC 老年代使用 Parallel Old GC，互相激活
-XX:ParallelGCThreads
-XX:MaxGCPauseMillis 设置垃圾收集器最大停顿时间（即STW的时间），单位是毫秒。
为了尽可能地把停顿时间控制在MaxGCPauseMills以内，收集器在工作时会调整Java堆大小或者其他一些参数。
对于用户来讲，停顿时间越短体验越好；但是服务器端注重高并发，整体的吞吐量。
所以服务器端适合Parallel，进行控制。该参数使用需谨慎。
-XX:GCTimeRatio 垃圾收集时间占总时间的比例（1 / (N＋1)），用于衡量吞吐量的大小
取值范围（0,100），默认值99，也就是垃圾回收时间不超过1％。
与前一个-XX：MaxGCPauseMillis参数有一定矛盾性。暂停时间越长，Radio参数就容易超过设定的比例。
-XX:+UseAdaptiveSizePolicy 设置Parallel Scavenge收集器具有自适应调节策略。
在这种模式下，年轻代的大小、Eden和Survivor的比例、晋升老年代的对象年龄等参数会被自动调整，以达到在堆大小、吞吐量和停顿时间之间的平衡点。
在手动调优比较困难的场合，可以直接使用这种自适应的方式，仅指定虚拟机的最大堆、目标的吞吐量（GCTimeRatio）和停顿时间（MaxGCPauseMills），让虚拟机自己完成调优工作。
# CMS回收器
-XX:+UseConcMarkSweepGC 年轻代使用CMS GC。
开启该参数后会自动将-XX：＋UseParNewGC打开。即：ParNew（Young区）+ CMS（Old区）+ Serial Old的组合
-XX:CMSInitiatingOccupanyFraction 设置堆内存使用率的阈值，一旦达到该阈值，便开始进行回收。JDK5及以前版本的默认值为68，DK6及以上版本默认值为92％。
如果内存增长缓慢，则可以设置一个稍大的值，大的阈值可以有效降低CMS的触发频率，减少老年代回收的次数可以较为明显地改善应用程序性能。
反之，如果应用程序内存使用率增长很快，则应该降低这个阈值，以避免频繁触发老年代串行收集器。
因此通过该选项便可以有效降低Fu1l GC的执行次数。
-XX:+UseCMSInitiatingOccupancyOnly 是否动态可调，使CMS一直按CMSInitiatingOccupancyFraction设定的值启动
-XX:+UseCMSCompactAtFullCollection 用于指定在执行完Full GC后对内存空间进行压缩整理
以此避免内存碎片的产生。不过由于内存压缩整理过程无法并发执行，所带来的问题就是停顿时间变得更长了。
-XX:CMSFullGCsBeforeCompaction 设置在执行多少次Full GC后对内存空间进行压缩整理。
-XX:ParallelCMSThreads 设置CMS的线程数量。
CMS 默认启动的线程数是(ParallelGCThreads＋3)/4，ParallelGCThreads 是年轻代并行收集器的线程数。
当CPU 资源比较紧张时，受到CMS收集器线程的影响，应用程序的性能在垃圾回收阶段可能会非常糟糕。
-XX:ConcGCThreads 设置并发垃圾收集的线程数，默认该值是基于ParallelGCThreads计算出来的
-XX:+CMSScavengeBeforeRemark 强制hotspot在cms remark阶段之前做一次minor gc，用于提高remark阶段的速度
-XX:+CMSClassUnloadingEnable 如果有的话，启用回收Perm 区（JDK8之前）
-XX:+CMSParallelInitialEnabled 用于开启CMS initial-mark阶段采用多线程的方式进行标记
用于提高标记速度，在Java8开始已经默认开启
-XX:+CMSParallelRemarkEnabled 用户开启CMS remark阶段采用多线程的方式进行重新标记，默认开启
-XX:+ExplicitGCInvokesConcurrent
-XX:+ExplicitGCInvokesConcurrentAndUnloadsClasses
这两个参数用户指定hotspot虚拟在执行System.gc()时使用CMS周期
-XX:+CMSPrecleaningEnabled 指定CMS是否需要进行Pre cleaning阶段
# G1回收器
-XX:+UseG1GC 手动指定使用G1收集器执行内存回收任务。
-XX:G1HeapRegionSize 设置每个Region的大小。
值是2的幂，范围是1MB到32MB之间，目标是根据最小的Java堆大小划分出约2048个区域。默认是堆内存的1/2000。
-XX:MaxGCPauseMillis 设置期望达到的最大GC停顿时间指标（JVM会尽力实现，但不保证达到）。默认值是200ms
-XX:ParallelGCThread 设置STW时GC线程数的值。最多设置为8
-XX:ConcGCThreads 设置并发标记的线程数。将n设置为并行垃圾回收线程数（ParallelGCThreads）的1/4左右。
-XX:InitiatingHeapOccupancyPercent 设置触发并发GC周期的Java堆占用率阈值。超过此值，就触发GC。默认值是45。
-XX:G1NewSizePercent 新生代占用整个堆内存的最小百分比（默认5％）
-XX:G1MaxNewSizePercent 新生代占用整个堆内存的最大百分比（默认60％）
-XX:G1ReservePercent=10 保留内存区域，防止 to space（Survivor中的to区）溢出
怎么选择垃圾回收器？
-
优先让JVM自适应，调整堆的大小
-
串行收集器：内存小于100M；单核、单机程序，并且没有停顿时间的要求
-
并行收集器：多CPU、高吞吐量、允许停顿时间超过1秒
-
并发收集器：多CPU、追求低停顿时间、快速响应（比如延迟不能超过1秒，如互联网应用）
-
官方推荐G1，性能高。现在互联网的项目，基本都是使用G1
特别说明：
-
没有最好的收集器，更没有万能的收集器
-
调优永远是针对特定场景、特定需求，不存在一劳永逸的收集器
GC日志相关选项
-XX:+PrintGC <==> -verbose:gc 打印简要日志信息
-XX:+PrintGCDetails 打印详细日志信息
-XX:+PrintGCTimeStamps 打印程序启动到GC发生的时间，搭配-XX:+PrintGCDetails使用
-XX:+PrintGCDateStamps 打印GC发生时的时间戳，搭配-XX:+PrintGCDetails使用
-XX:+PrintHeapAtGC 打印GC前后的堆信息
-Xloggc:<file> 输出GC导指定路径下的文件中
-XX:+TraceClassLoading 监控类的加载
-XX:+PrintGCApplicationStoppedTime 打印GC时线程的停顿时间
-XX:+PrintGCApplicationConcurrentTime 打印垃圾收集之前应用未中断的执行时间
-XX:+PrintReferenceGC 打印回收了多少种不同引用类型的引用
-XX:+PrintTenuringDistribution 打印JVM在每次MinorGC后当前使用的Survivor中对象的年龄分布
-XX:+UseGCLogFileRotation 启用GC日志文件的自动转储
-XX:NumberOfGCLogFiles=1 设置GC日志文件的循环数目
-XX:GCLogFileSize=1M 设置GC日志文件的大小
其他参数
-XX:+DisableExplicitGC 禁用hotspot执行System.gc()，默认禁用
-XX:ReservedCodeCacheSize=<n>[g|m|k]、-XX:InitialCodeCacheSize=<n>[g|m|k] 指定代码缓存的大小
-XX:+UseCodeCacheFlushing 放弃一些被编译的代码，避免代码缓存被占满时JVM切换到interpreted-only的情况
-XX:+DoEscapeAnalysis 开启逃逸分析
-XX:+UseBiasedLocking 开启偏向锁
-XX:+UseLargePages 开启使用大页面
-XX:+PrintTLAB 打印TLAB的使用情况
-XX:TLABSize 设置TLAB大小
通过Java代码获取JVM参数
Java提供了java.lang.management包用于监视和管理Java虚拟机和Java运行时中的其他组件，它允许本地或远程监控和管理运行的Java虚拟机。其中ManagementFactory类较为常用，另外Runtime类可获取内存、CPU核数等相关的数据。通过使用这些api，可以监控应用服务器的堆内存使用情况，设置一些阈值进行报警等处理。(MBean的方式)
public class MemoryMonitor {
public static void main(String[] args) {
MemoryMXBean memorymbean = ManagementFactory.getMemoryMXBean();
MemoryUsage usage = memorymbean.getHeapMemoryUsage();
System.out.println("INIT HEAP: " + usage.getInit() / 1024 / 1024 + "m");
System.out.println("MAX HEAP: " + usage.getMax() / 1024 / 1024 + "m");
System.out.println("USE HEAP: " + usage.getUsed() / 1024 / 1024 + "m");
System.out.println("\nFull Information:");
System.out.println("Heap Memory Usage: " + memorymbean.getHeapMemoryUsage());
System.out.println("Non-Heap Memory Usage: " + memorymbean.getNonHeapMemoryUsage());
System.out.println("=======================通过java来获取相关系统状态============================ ");
System.out.println("当前堆内存大小totalMemory " + (int) Runtime.getRuntime().totalMemory() / 1024 / 1024 + "m");// 当前堆内存大小
System.out.println("空闲堆内存大小freeMemory " + (int) Runtime.getRuntime().freeMemory() / 1024 / 1024 + "m");// 空闲堆内存大小
System.out.println("最大可用总堆内存maxMemory " + Runtime.getRuntime().maxMemory() / 1024 / 1024 + "m");// 最大可用总堆内存大小
}
}
GC日志
日志分类
MinorGC（或young GC或YGC）日志：
[GC (Allocation Failure) [PSYoungGen: 31744K->2192K (36864K) ] 31744K->2200K (121856K), 0.0139308 secs] [Times: user=0.05 sys=0.01, real=0.01 secs]
FullGC
[Full GC (Metadata GC Threshold) [PSYoungGen: 5104K->0K (132096K) ] [Par01dGen: 416K->5453K (50176K) ]5520K->5453K (182272K), [Metaspace: 20637K->20637K (1067008K) ], 0.0245883 secs] [Times: user=0.06 sys=0.00, real=0.02 secs]
GC日志结构剖析
透过日志看垃圾收集器
-
Serial收集器：新生代显示 “[DefNew”，即 Default New Generation
-
ParNew收集器：新生代显示 “[ParNew”，即 Parallel New Generation
-
Parallel Scavenge收集器：新生代显示"[PSYoungGen"，JDK1.7使用的即PSYoungGen
-
Parallel Old收集器：老年代显示"[ParoldGen"
-
G1收集器：显示”garbage-first heap“
透过日志看GC原因
-
Allocation Failure：表明本次引起GC的原因是因为新生代中没有足够的区域存放需要分配的数据
-
Metadata GCThreshold：Metaspace区不够用了
-
FErgonomics：JVM自适应调整导致的GC
-
System：调用了System.gc()方法
透过日志看GC前后情况
通过图示，我们可以发现GC日志格式的规律一般都是：GC前内存占用-＞GC后内存占用（该区域内存总大小）
[PSYoungGen: 5986K->696K (8704K) ] 5986K->704K (9216K)
-
中括号内：GC回收前年轻代堆大小，回收后大小，（年轻代堆总大小）
-
括号外：GC回收前年轻代和老年代大小，回收后大小，（年轻代和老年代总大小）
注意：Minor GC堆内存总容量 = 9/10 年轻代 + 老年代。原因是Survivor区只计算from部分，而JVM默认年轻代中Eden区和Survivor区的比例关系，Eden:S0:S1=8:1:1。
透过日志看GC时间
GC日志中有三个时间：user，sys和real
-
user：进程执行用户态代码（核心之外）所使用的时间。这是执行此进程所使用的实际CPU 时间，其他进程和此进程阻塞的时间并不包括在内。在垃圾收集的情况下，表示GC线程执行所使用的 CPU 总时间。
-
sys：进程在内核态消耗的 CPU 时间，即在内核执行系统调用或等待系统事件所使用的CPU 时间
-
real：程序从开始到结束所用的时钟时间。这个时间包括其他进程使用的时间片和进程阻塞的时间（比如等待 I/O 完成）。对于并行gc，这个数字应该接近（用户时间＋系统时间）除以垃圾收集器使用的线程数。
由于多核的原因，一般的GC事件中，real time是小于sys time＋user time的，因为一般是多个线程并发的去做GC，所以real time是要小于sys＋user time的。如果real＞sys＋user的话，则你的应用可能存在下列问题：IO负载非常重或CPU不够用。
GC日志分析工具
GCEasy
GCEasy是一款在线的GC日志分析器，可以通过GC日志分析进行内存泄露检测、GC暂停原因分析、JVM配置建议优化等功能，大多数功能是免费的。
官网地址：https://gceasy.io/
GCViewer
GCViewer是一款离线的GC日志分析器，用于可视化Java VM选项 -verbose:gc 和 .NET生成的数据 -Xloggc:。还可以计算与垃圾回收相关的性能指标（吞吐量、累积的暂停、最长的暂停等）。当通过更改世代大小或设置初始堆大小来调整特定应用程序的垃圾回收时，此功能非常有用。
源码下载：https://github.com/chewiebug/GCViewer
运行版本下载：https://github.com/chewiebug/GCViewer/wiki/Changelog
GChisto
-
官网上没有下载的地方，需要自己从SVN上拉下来编译
-
不过这个工具似乎没怎么维护了，存在不少bug
HPjmeter
-
工具很强大，但是只能打开由以下参数生成的GC log，-verbose:gc -Xloggc:gc.log。添加其他参数生成的gc.log无法打开
-
HPjmeter集成了以前的HPjtune功能，可以分析在HP机器上产生的垃圾回收日志文件
RMI结合visualvm使用
1)、可配置远程RMI服务，两种方式（当我们要看远程服务器上JAVA程序的GC情况的时候，需要执行此步骤）
- 配置JMX的远程RMI服务(推荐)
java
-Dcom.sun.management.imxremote.authenticate=false
-Dcom.sun.management.jmxremote.ssl=false
-Dcom.sun.management.jmxremote.port=9004
-Djava.rmi.server.hostname=177.1.1.122
-jar demo.jar &
- 配置jstatd的远程RMI服务
将如下的代码存为文件 jstatd.all.policy，放到JAVA_HOME/bin中，其内容如下：不知道JAVA_HOME目录的，可以执行 which java查看。
grant codebase "file:${java.home}/../lib/tools.jar" {
permission java.security.AllPermission;
};
执行命令jstatd -J-Djava.security.policy=jstatd.all.policy -J-Djava.rmi.server.hostname=10.27.20.38 &
(10.27.20.38为你服务器的ip地址,&表示用守护线程的方式运行)
启动jar添加参数
java
-Dcom.sun.management.jmxremote
-Dcom.sun.management.jmxremote.port=1100
-Dcom.sun.management.jmxremote.authenticate=false
-Dcom.sun.management.jmxremote.ssl=false
-jar demo.jar &
2)、打开jvisualvm控制台。
工具–插件–中找到Visual GC插件进行安装.
3)、对要执行java程序进行调优，以 jvm-demo.jar为例。
java -Xms4G -Xmx4G
#1.输出gc日志
-verbose:gc
-Xloggc:/home/administrator/james/gc.log
-XX:+PrintGCTimeStamps
-XX:-PrintGCDetails
# 更详细的日志
-XX:+PrintHeapAtGC
# 2.日志文件控制
-XX:-UseGCLogFileRotation
-XX:GCLogFileSize=8K
# 3.dump文件输出
-XX:+HeapDumpOnOutOfMemoryError
-XX:HeapDumpPath=/home/administrator/james/error.hprof
# 打印GC时线程的停顿时间
-XX:+PrintGCApplicationStoppedTime
# 查看当前使用的垃圾回收器
-XX:+PrintCommandLineFlags
# 查看当前使用的垃圾回收器
-XX:+PrintFlagsFinal
# 使用压缩指针
-XX:+UseCompressedClassPointers
# 使用压缩对象
-XX:+UseCompressedOops
-Dcom.sun.management.imxremote.authenticate=false
-Dcom.sun.management.jmxremote.ssl=false
-Dcom.sun.management.jmxremote.port=9004
-Djava.rmi.server.hostname=177.1.1.122
-jar jvm-demo.jar
&
通过这样的配置，使用JVM控制台即可查看JVM(CPU/内存)及垃圾回收的情况。
4)、控制台配置
打开jvisualvm，远程—添加远程主机—输入远程IP----添加JMX连接
5)、下面开始正式的JVM调优。
执行：jstat -gc 15016 1000，看到每1秒钟java进程号为15016的GC回收情况。
[root@admin04 c1000k]# jstat -gc 15016 1000
S0C S1C S0U S1U EC EU OC OU PC PU YGC YGCT FGC FGCT GCT
699008.0 699008.0 29980.4 0.0 699136.0 116881.6 2097152.0 660769.4 21248.0 20071.0 354 54.272 0 0.000 54.272
699008.0 699008.0 29980.4 0.0 699136.0 118344.8 2097152.0 660769.4 21248.0 20071.0 354 54.272 0 0.000 54.272
699008.0 699008.0 29980.4 0.0 699136.0 119895.5 2097152.0 660769.4 21248.0 20071.0 354 54.272 0 0.000 54.272
699008.0 699008.0 29980.4 0.0 699136.0 121383.1 2097152.0 660769.4 21248.0 20071.0 354 54.272 0 0.000 54.272
解释如下：
S0C 是指：Survivor0区的分配空间
S0U 是指：Survivor1区的已经使用的空间
EC是指:Eden区所使用的空间
EU是指：Eden区当前使用的空间
OC是指：老年代分配的空间
OU是指：老年代当前使用的空间
PC是指：持久待分配的空间
PU是指：持久待当前使用的空间
YGC是指：年轻代发生的次数，这里是354次
YGCT是指：年轻代发送的总时长，这里是54.272秒，因此每次年轻代发生GC，即平均每次stop-the-world的时长为54.272/354=0.153秒。
FGC是指：年老代回收的次数，或者成为FullGC的次数。
FGCT是指：年老代发生回收的总时长。
GCT是指：包括年轻代YGC及年老代FGC的总时间长。
通常结合图形或数据，我们可以看到当EU即将等于EC的时候，此时发生YGC，因此YGC次数+1，YGCT时间增加。
经过实际的调优测试我们发现，当发生YGC的时候，如果S0U或S1U区如果有任意一个区域为0的时候，此时YGC的速度很快，相反如果S0U或者S1U中都有数据，或相对满的时候，此时YGC的时间边长，这就是因为S0/S1及Eden区的比例问题导致的。
5.3经过一定时间的调优，我们基本上可以使得YGC的次数非常少，时间非常快，很长时间，数天都不会发生FGC，此时JVM的调优算是一个好的结果。
5.4 在MAC电脑上可以通过jconsole调出图形化分析工具。
扫一扫
232
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
