JVM：调优

发表于 更新于 分类于
本文字数： 7.7k 阅读时长 ≈ 14 分钟

常用JVM参数

GC日志

Java的内存管理机制弱化了我们当程序出现内存溢出时定位问题和解决问题的能力。

当GC沦落为影响程序运行的性能瓶颈时，例如因为STW导致程序出现长时间暂停、GC频繁执行内存回收导致程序吞吐量下降等情况。我们必须通过分析这些GC日志来做出相应的调整和处理。即分析GC日志是故障排查和JVM性能调优的前提和基础。

理解GC日志

每一种收集器的日志形式都是由它们自身的实现所决定的，即每个收集器的日志格式都可以不一样。但JVM设计时将各个收集器的日志都维持一定的共性。

1
2
3
33.125: [GC [DefNew: 3324K->152K(3712K), 0.0025925 secs] 3324K->152K[11904K], 0.0031680sec]

100.667: [Full GC [Tenured: 0K->210K(10240K), 0.0149142 secs] 4603K->210K(19456K), [Perm : 2999K->2999K(21248K)],0.0150007 secs] [Times:user=0.01 sys=0.00, real=0.02 secs]
  • GC发生时间：33.125、100.667表示GC发生的时间，数字含义时从JVM启动以来经过的秒数
  • 停顿类型：GC日志开头的GC、FullGC说明了此次垃圾收集的停顿类型。而不是新生代或老年代，即使时新生代也可能因为担保失败而导致Full GC
  • GC区域：DefNew、Tenured、Perm表示GC发生的区域，与收集器密切相关
  • GC内存容量变化：方括号内部的3324K->152K(3712K)，GC前该内存区域已使用容量->GC后该内存区域已使用容量（该内存区域总容量）
  • GC堆容量变化：方括号外部的3324K->152K(11904K)表示GC前Java堆已使用容量->GC后Java堆已使用容量(Java堆总容量)
  • GC执行时间：0.0025925 secs表示该内存区域GC所占用时间。有些收集器给出更详细时间，Times: user=0.01 sys=0.00 real=0.02即分别代表用户态消耗的CPU时间、内核态消耗的CPU时间和操作从开始到结束所经过的墙钟时间（包括各种非运算的等待耗时，例如IO、线程阻塞等）。

CMS收集器

1564831023187

CMS的GC日志划分为初始标记、并发标记、再次标记、并发清除这4个主要阶段。

首先CMS会以一个初始标记阶段开始，这个阶段会导致STW，可以通过选项-XX:+PrintGCApplicationStoppedTime进行设置。耗时0.0001474s

之后并发标记，耗时0.005s

之后并发清除STW，耗时0.0003017s

最后进行并发清除。释放掉无用对象占用的可见。0.000/0.000代表并发清除耗时CPU的时间和墙上时间。如果排除并发预处理与并发重置，当执行完这4个主要阶段，CMS任务就完成了。

虚拟机性能监控与故障处理工具

给一个系统定位问题时，知识、经验是关键基础，数据是一句，工具是运用只是处理数据的手段。数据包括：运行日志、异常堆栈、GC日志、线程快照(threaddump、javacore文件)、堆存储快照(heapdump、hprof文件)等。

JDK的命令行工具

Sun JDK监控和故障处理工具

  • jps：JVM Proces Status Tool，显示指定系统内所有的HotSpot虚拟机进程
  • jstat：JVM Statistics Monitoring Tool，用于收集HotSpot虚拟机各方面的运行数据
  • jinfo：Configuration Info for Java
  • jmap：Memory Map for Java，显示虚拟机配置信息
  • jhat：JVM Heap Dump Browser，生成虚拟机的内存转储快照(heapdump文件)
  • jstack：Stack Trace for Java，显示虚拟机的线程快照。

JDK的很多小工具命名参考了UNIX命令的命名，例如jps，类似与ps

jps 虚拟机进程状况工具

jps可以列出正在运行的虚拟机进程，并显示虚拟机执行主类（main函数所在的类）名称以及这些进程的本地虚拟机唯一ID（Local Virtual Machine Identifier，LVMID）

LVMID与操作系统的进程ID是一致的，使用ps命令也可以查询到虚拟机进程的LVMID，但是如果同时启动了多个虚拟机进程，无法根据进程名称定位时，只能依赖jps显示主类的功能才能区分了。

jps通过RMI协议查询开启了RMI服务的远程虚拟机进程状态，hostid为RMI注册表中注册的主机名。jps的其他常用选项如下：

  • -q。只输出LVMID，省略主类的名称
  • -m。输出虚拟机进程启动时传递给主类main()函数的参数
  • -l。输出主类的全名，如果进程执行的时Jar包，输出Jar路径
  • -v。输出虚拟机进程启动时JVM参数

jstat 虚拟机统计信息监视工具

用于监视虚拟机各种运行状态信息的命令行工具，可以显示本地或远程虚拟机进程中的类装载、内存、垃圾收集、JIT编译等运行数据。

在只提供纯文本控制台环境的服务器上，是运行期定位虚拟机性能问题的首选工具

命令格式：jstat [option vmid [interval [s|ms] [count]] ]

  • option。是一个选项代表用户希望查询的虚拟机信息，主要分为三类：类装载、垃圾收集、运行期编译状况。
    • -class。监视类装载、卸载数量、总空间以及类装载所耗费的时间
    • -gc。监视Java堆状况，包括Eden区、两个Survivor区、老年代、永久代等的容量、已用空间、GC时间合计等信息
    • -gccapacity。监视内容与-gc基本相同，但输出主要关注Java堆各个区域使用到的最大、最小空间
    • -gcutil。监视内容与-gc基本相同，但输出主要关注已使用空间占总空间的百分比
    • -gccause。与-gcutil相同，但额外输出上一次GC产生的原因
    • -gcnew。监视新生代GC状况
    • -gcnewcapacity。监视内容与gcnew一致，输出主要关注使用到的最大、最小空间
    • -gcold。监视老年代GC状况
    • -gcoldcapacity。监视内容与gcold一致，输出主要关注使用到的最大、最小空间
    • -gcpermcapacity。输出永久代使用到的最大、最小空间
    • -compiler。输出JIT编译器编译过的方法、耗时等信息
    • -printcompilation。输出已经被JIT编译的方法
    • 等等
  • vmid：对于本地虚拟机进程，则vmid与LVMID是一致的，如果是远程虚拟机进程，则格式应为：[protocol:][//]lvmid[@hostname[:port]/servername]
  • interval和count。代表查询间隔和次数。如果省略这两个参数，则说明只查询一次。

示例：每250ms查询一次进程2764垃圾收集状况，一共查询20此，则命令为：jstat -gc 2764 250 20

jinfo java配置信息工具

jinfo的作用是实时查看和调整虚拟机各项参数。

命令格式：jinfo [option] pid

option选项

  • -sysprops。将虚拟机进程的System.getProperties内容打印出来。
  • -flag 。
    • -flag [name]查询未被显式指定的参数的系统默认值。或使用Java -XX:PrintFlagsFinal。而jps -v只可以查看虚拟机启动时显式指定的参数列表。
    • 可以在运行期修改参数，-flag [+|-] name或-flag name = value修改一部分运行期可写的虚拟机参数值

jmap Java内存映像工具

  • 用于生成堆存储快照，一般称为heapdump或dump文件。
  • 可以查询finalize执行队列、Java堆和永久代的详细信息，例如空间使用率，当前使用的收集器等。

对于dump文件，也可以采用-XX:+HeapDumpOnOutOfMemoryError参数，让虚拟机在OOM异常出血后自动生成dump文件。-XX:+HeapDumpOnCtrlBreak参数则可以使用Ctrl+Break键让虚拟机生成dump文件。

命令格式：jmap [option] vmid

option选项

  • -dump。格式为-dump:[live,]format=b, file=<filename>其中live子参数说明是否只dump出存活的对象
  • -finalizerinfo。显示在F-Queue中等待Finalizer线程执行finalize方法的对象
  • -heap。显示Java堆详细信息，如使用哪种回收器、参数配置、粉黛状况等
  • -histo。显示堆中对象统计信息，包括类、实例数量、合计容量
  • -permstat。以ClassLoader为统计口径显示永久代内存状态
  • -F。当虚拟机进程对-dump无响应时，强制生成dump快照

jhat 虚拟机堆转存储快照分析工具

jhat与jmap搭配使用，来分析jmap生成的堆转储快照。jhat内置了一个微型的HTTP/HTML服务器，生成dump文件的分析结果后，可以在浏览器中查看。

  • 一般不会在部署应用程序的服务器上直接分析dump文件，即使可以也会尽量将dump文件复制到其他机器上分析，英文分析工作耗时且耗费硬件资源，而在其他机器上就不需要受到命令行限制
  • jhat的分析功能相对简陋

jstack Java堆栈跟踪工具

用于生成虚拟机当前时刻的线程快照，一般为threaddump或者Javacore文件。线程快照就是当前虚拟机内每一条线程正在执行的方法堆栈的集合。

线程快照的主要目的时定位线程出现长时间停顿的原因，如线程间思索、死锁循环、请求外部资源导致的长时间等待等都是导致线程长时间停顿的常见原因。线程出现停顿时就可以通过jstack查看各个线程的调用堆栈，就可以知道没有响应的线程到底在后台做什么事情或者在等待什么资源。

命令格式jstack [option] vmid

  • -F。当正常输出的请求不被响应时，强制输出线程堆栈
  • -l。除堆栈外，显示关于锁的附加信息
  • -m。如果调用到本地方法的话，可以显示C/C++的堆栈

hsdis jit生成代码反汇编

在Java虚拟机规范中，详细描述了虚拟机指令集中每条指令的执行过程、执行前后对操作数栈、局部变量表的影响等细节，这些细节与早期的JVM高度吻合。

但是随着虚拟机的发展导致真正的细节实现方式已经渐渐与虚拟机规范描述的内容产生了越来越大的差距，其逐渐成为了概念模型，即实现只能保证规范描述等效。

基于以上原因，我们分析程序的执行语义问题(虚拟机做了什么)时，在字节码上分析完全可行，但分析程序的执行行为问题(虚拟机是怎样做的、性能如何)时，字节码层面分析就没有什么意义，需要通过其他方式解决。

HSDIS将HotSpot的-XX:+PrintAssembly指令调用它来把动态生成的本地代码还原成为汇编代码输出，并生成大量的注释。

JDK的可视化工具

Jconsole

Java监视与管理控制台。

VisualVM

调优案例分析与实战

JVM分析

内存泄漏

定义

内存泄漏就是存在一些被分配的对象，有两个特点

  • 在可达性分析时可达，即无法被GC回收
  • 这些对象是无用的，即程序以后不会再使用这些对象。但占有着内存。

原因

  • 长生命周期的对象持有短生命周期对象的引用就很可能发生内存泄漏，尽管短生命周期对象已经不再需要，但是因为长生命周期持有它的引用而导致不能被回收，这就是Java中内存泄漏的发生场景

工具

  • MemoryAnalyzer。Java堆转储文件分析工具，帮助发现内存漏洞和减少内存消耗。
  • EclipseMAT。开源Java内存分析软件，查找内存泄漏，能容易找到大块内存并验证谁在一直占用它。
  • JProbe。分析Java的内存泄漏。

示例

集合类泄漏

像HashMap、Vector等的使用最容易出现内存泄露，这些静态变量的生命周期和应用程序一致，他们所引用的所有的对象Object也不能被释放，因为他们也将一直被Vector等引用着。

如果是非静态，那么在方法执行结束时，由于vector=null释放，因此内部的对象也释放了。

1
2
3
4
5
6
Vector v = new Vector(10);
for (int i = 1; i < 100; i++) {
    Object o = new Object();
    v.add(o);
    o = null;   
}

我们仅仅释放引用本身，那么 Vector 仍然引用该对象，所以这个对象对 GC 来说是不可回收的。因此，如果对象加入到Vector 后，还必须从 Vector 中删除，最简单的方法就是将 Vector 对象设置为 null。

当集合里面的对象属性被修改后，再调用remove()方法时不起作用。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
public static void main(String[] args){
	Set<Person> set = new HashSet<Person>();
	Person p1 = new Person("唐僧","pwd1",25);
	Person p2 = new Person("孙悟空","pwd2",26);
	Person p3 = new Person("猪八戒","pwd3",27);
	set.add(p1);
	set.add(p2);
	set.add(p3);
	System.out.println("总共有:"+set.size()+" 个元素!"); //结果：总共有:3 个元素!
	p3.setAge(2); //修改p3的年龄,此时p3元素对应的hashcode值发生改变

	set.remove(p3); //此时remove不掉，造成内存泄漏

	set.add(p3); //重新添加，居然添加成功
	System.out.println("总共有:"+set.size()+" 个元素!"); //结果：总共有:4 个元素!
	for (Person person : set)
	{
		System.out.println(person);
	}
}

单例/静态变量造成的内存泄漏

不正确使用单例模式是引起内存泄漏的一个常见问题，单例对象在初始化后将在JVM的整个生命周期中存在（以静态变量的方式），如果单例对象持有外部的引用，那么这个对象将不能被JVM正常回收，导致内存泄漏

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
class A{
	public A(){
		B.getInstance().setA(this);
	}
....
}

//B类采用单例模式
class B{
	private A a;
	private static B instance=new B();
	public B(){}
	public static B getInstance(){
		return instance;
	}
	public void setA(A a){
		this.a=a;
	}
//getter...
}

匿名内部类/非静态内部类

内部类的引用是比较容易遗忘的一种，而且一旦没释放可能导致一系列的后继类对象没有释放。此外程序员还要小心外部模块不经意的引用，例如程序员A 负责A 模块，调用了B 模块的一个方法如：
public void registerMsg(Object b);

这种调用就要非常小心了，传入了一个对象，很可能模块B就保持了对该对象的引用，这时候就需要注意模块B 是否提供相应的操作去除引用。

资源未关闭造成的内存泄漏

如各种连接，包括数据库连接等。

比如数据库连接（dataSourse.getConnection()），网络连接(socket)和io连接，除非其显式的调用了其close（）方法将其连接关闭，否则是不会自动被GC 回收的，因为这些连接是独立于JVM的。

对于Resultset 和Statement 对象可以不进行显式回收，但Connection 一定要显式回收，因为Connection 在任何时候都无法自动回收，而Connection一旦回收，Resultset 和Statement 对象就会立即为NULL。但是如果使用连接池，情况就不一样了，除了要显式地关闭连接，还必须显式地关闭Resultset Statement 对象（关闭其中一个，另外一个也会关闭），否则就会造成大量的Statement 对象无法释放，从而引起内存泄漏。这种情况下一般都会在try里面去的连接，在finally里面释放连接，就能避免此类泄漏。

监听器

在java 编程中，我们都需要和监听器打交道，通常一个应用当中会用到很多监听器，我们会调用一个控件的诸如addXXXListener()等方法来增加监听器，但往往在释放对象的时候却没有记住去删除这些监听器，从而增加了内存泄漏的机会。

ThreadLocal内存泄漏

实际上 ThreadLocalMap 中使用的 key 为 ThreadLocal 的弱引用，弱引用的特点是，如果这个对象只存在弱引用，那么在下一次垃圾回收的时候必然会被清理掉。

所以如果 ThreadLocal 没有被外部强引用的情况下，在垃圾回收的时候会被清理掉的，这样一来 ThreadLocalMap中使用这个 ThreadLocal 的 key 也会被清理掉。但是，value 是强引用，不会被清理，这样一来就会出现 key 为 null 的 value。

ThreadLocalMap实现中已经考虑了这种情况，在调用 set()、get()、remove() 方法的时候，会清理掉 key 为 null 的记录。如果说会出现内存泄漏，那只有在出现了 key 为 null 的记录后，没有手动调用 remove() 方法，并且之后也不再调用 get()、set()、remove() 方法的情况下。

线程死锁

如何判断JVM线程死锁。

  • 在间隔两分钟后再次收集一次thread dump，如果输出相同，仍然是大量thread都在等待给同一个地址上锁，则是死锁

如果使用VisualVM dump线程信息出来，会有哪些信息

JConsole

JVM调优

OOM分析

参考

  1. Java内存溢出(OOM)异常完全指南