linux
分类： Java
2016-05-25 15:59:23
现实企业级Java开发中，有时候我们会碰到下面这些问题：
OutOfMemoryError，内存不足
内存泄露
线程死锁
锁争用（Lock Contention）
Java进程消耗CPU过高
......
这些问题在日常开发中可能被很多人忽视（比如有的人遇到上面的问题只是重启服务器或者调大内存，而不会深究问题根源），但能够理解并解决这些问题是 Java程序员进阶的必备要求。本文将对一些常用的JVM性能调优监控工具进行介绍，希望能起抛砖引玉之用。本文参考了网上很多资料，难以一一列举，在此 对这些资料的作者表示感谢！关于JVM性能调优相关的资料，请参考文末。
A、 jps(Java Virtual Machine Process Status Tool)
jps主要用来输出JVM中运行的进程状态信息。语法格式如下：
jps [options] [hostid]
如果不指定hostid就默认为当前主机或服务器。
命令行参数选项说明如下：
-q 不输出类名、Jar名和传入main方法的参数 -m 输出传入main方法的参数 -l 输出main类或Jar的全限名 -v 输出传入JVM的参数
比如下面：
root@ubuntu:/# jps -m -l 2458 org.artifactory.standalone.main.Main /usr/local/artifactory-2.2.5/etc/jetty.xml 29920 com.sun.tools.hat.Main -port 9998 /tmp/dump.dat 3149 org.apache.catalina.startup.Bootstrap start 30972 sun.tools.jps.Jps -m -l 8247 org.apache.catalina.startup.Bootstrap start 25687 com.sun.tools.hat.Main -port 9999 dump.dat 21711 mrf-center.jar
B、 jstack
jstack主要用来查看某个Java进程内的线程堆栈信息。语法格式如下：
jstack [option] pid jstack [option] executable core jstack [option] [server-id@]remote-hostname-or-ip
命令行参数选项说明如下：
-l long listings，会打印出额外的锁信息，在发生死锁时可以用jstack -l pid来观察锁持有情况 -m mixed mode，不仅会输出Java堆栈信息，还会输出C/C++堆栈信息（比如Native方法）
jstack可以定位到线程堆栈，根据堆栈信息我们可以定位到具体代码，所以它在JVM性能调优中使用得非常多。下面我们来一个实例找出某个Java进程 中最耗费CPU的Java线程并定位堆栈信息，用到的命令有ps、top、printf、jstack、grep。
第一步先找出Java进程ID，我部署在服务器上的Java应用名称为mrf-center：
root@ubuntu:/# ps -ef | grep mrf-center | grep -v grep root 21711 1 1 14:47 pts/3 00:02:10 java -jar mrf-center.jar
得到进程ID为21711，第二步找出该进程内最耗费CPU的线程，可以使用ps -Lfp pid或者ps -mp pid -o THREAD, tid, time或者top -Hp pid，我这里用第三个，输出如下：
TIME列就是各个Java线程耗费的CPU时间，CPU时间最长的是线程ID为21742的线程，用
printf "%x\n" 21742
得到21742的十六进制值为54ee，下面会用到。
OK，下一步终于轮到jstack上场了，它用来输出进程21711的堆栈信息，然后根据线程ID的十六进制值grep，如下：
root@ubuntu:/# jstack 21711 | grep 54ee "PollIntervalRetrySchedulerThread" prio=10 tid=0x00007f950043e000 nid=0x54ee in Object.wait() [0x00007f94c6eda000]
可以看到CPU消耗在PollIntervalRetrySchedulerThread这个类的Object.wait()，我找了下我的代码，定位到下面的代码：
// Idle wait
getLog().info("Thread [" + getName() + "] is idle waiting...");
schedulerThreadState = PollTaskSchedulerThreadState.IdleWaiting;
long now = System.currentTimeMillis();
long waitTime = now + getIdleWaitTime();
long timeUntilContinue = waitTime - now;
synchronized(sigLock) {
try {
if(!halted.get()) {
sigLock.wait(timeUntilContinue);
}
}
catch (InterruptedException ignore) {
}
}
它是轮询任务的空闲等待代码，上面的sigLock.wait(timeUntilContinue)就对应了前面的Object.wait()。
C、 jmap（Memory Map）和jhat（Java Heap Analysis Tool）
jmap用来查看堆内存使用状况，一般结合jhat使用。
jmap语法格式如下：
jmap [option] pid jmap [option] executable core jmap [option] [server-id@]remote-hostname-or-ip
如果运行在64位JVM上，可能需要指定-J-d64命令选项参数。
jmap -permstat pid
打印进程的类加载器和类加载器加载的持久代对象信息，输出：类加载器名称、对象是否存活（不可靠）、对象地址、父类加载器、已加载的类大小等信息，如下图：
使用jmap -heap pid查看进程堆内存使用情况，包括使用的GC算法、堆配置参数和各代中堆内存使用情况。比如下面的例子：
root@ubuntu:/# jmap -heap 21711 Attaching to process ID 21711, please wait... Debugger attached successfully. Server compiler detected. JVM version is 20.10-b01 using thread-local object allocation. Parallel GC with 4 thread(s) Heap Configuration: MinHeapFreeRatio = 40 MaxHeapFreeRatio = 70 MaxHeapSize = 2067791872 (1972.0MB) NewSize = 1310720 (1.25MB) MaxNewSize = 17592186044415 MB OldSize = 5439488 (5.1875MB) NewRatio = 2 SurvivorRatio = 8 PermSize = 21757952 (20.75MB) MaxPermSize = 85983232 (82.0MB) Heap Usage: PS Young Generation Eden Space: capacity = 6422528 (6.125MB) used = 5445552 (5.1932830810546875MB) free = 976976 (0.9317169189453125MB) 84.78829520089286% used From Space: capacity = 131072 (0.125MB) used = 98304 (0.09375MB) free = 32768 (0.03125MB) 75.0% used To Space: capacity = 131072 (0.125MB) used = 0 (0.0MB) free = 131072 (0.125MB) 0.0% used PS Old Generation capacity = 35258368 (33.625MB) used = 4119544 (3.9287033081054688MB) free = 31138824 (29.69629669189453MB) 11.683876009235595% used PS Perm Generation capacity = 52428800 (50.0MB) used = 26075168 (24.867218017578125MB) free = 26353632 (25.132781982421875MB) 49.73443603515625% used ....
使用jmap -histo[:live] pid查看堆内存中的对象数目、大小统计直方图，如果带上live则只统计活对象，如下：
root@ubuntu:/# jmap -histo:live 21711 | more num #instances #bytes class name ---------------------------------------------- 1: 38445 55977362: 38445 5237288 3: 3500 3749504 4: 60858 3242600 5: 3500 2715264 6: 2796 2131424 7: 5543 1317400 [I 8: 13714 1010768 [C 9: 4752 1003344 [B 10: 1225 639656 11: 14194 454208 java.lang.String 12: 3809 396136 java.lang.Class 13: 4979 311952 [S 14: 5598 287064 [[I 15: 3028 266464 java.lang.reflect.Method 16: 280 163520 17: 4355 139360 java.util.HashMap$Entry 18: 1869 138568 [Ljava.util.HashMap$Entry; 19: 2443 97720 java.util.LinkedHashMap$Entry 20: 2072 82880 java.lang.ref.SoftReference 21: 1807 71528 [Ljava.lang.Object; 22: 2206 70592 java.lang.ref.WeakReference 23: 934 52304 java.util.LinkedHashMap 24: 871 48776 java.beans.MethodDescriptor 25: 1442 46144 java.util.concurrent.ConcurrentHashMap$HashEntry 26: 804 38592 java.util.HashMap 27: 948 37920 java.util.concurrent.ConcurrentHashMap$Segment 28: 1621 35696 [Ljava.lang.Class; 29: 1313 34880 [Ljava.lang.String; 30: 1396 33504 java.util.LinkedList$Entry 31: 462 33264 java.lang.reflect.Field 32: 1024 32768 java.util.Hashtable$Entry 33: 948 31440 [Ljava.util.concurrent.ConcurrentHashMap$HashEntry;
class name是对象类型，说明如下：
B byte C char D double F float I int J long Z boolean [ 数组，如[I表示int[] [L+类名 其他对象
还有一个很常用的情况是：用jmap把进程内存使用情况dump到文件中，再用jhat分析查看。jmap进行dump命令格式如下：
jmap -dump:format=b,file=dumpFileName
我一样地对上面进程ID为21711进行Dump：
root@ubuntu:/# jmap -dump:format=b,file=/tmp/dump.dat 21711 Dumping heap to /tmp/dump.dat ... Heap dump file created
dump出来的文件可以用MAT、VisualVM等工具查看，这里用jhat查看：
root@ubuntu:/# jhat -port 9998 /tmp/dump.dat Reading from /tmp/dump.dat... Dump file created Tue Jan 28 17:46:14 CST 2014 Snapshot read, resolving... Resolving 132207 objects... Chasing references, expect 26 dots.......................... Eliminating duplicate references.......................... Snapshot resolved. Started HTTP server on port 9998 Server is ready.
然后就可以在浏览器中输入主机地址:9998查看了：
上面红线框出来的部分大家可以自己去摸索下，最后一项支持OQL（对象查询语言）。
D、jstat（JVM统计监测工具）
语法格式如下：
jstat [ generalOption | outputOptions vmid [interval[s|ms] [count]] ]
vmid是虚拟机ID，在Linux/Unix系统上一般就是进程ID。interval是采样时间间隔。count是采样数目。比如下面输出的是GC信息，采样时间间隔为250ms，采样数为4：
root@ubuntu:/# jstat -gc 21711 250 4 S0C S1C S0U S1U EC EU OC OU PC PU YGC YGCT FGC FGCT GCT 192.0 192.0 64.0 0.0 6144.0 1854.9 32000.0 4111.6 55296.0 25472.7 702 0.431 3 0.218 0.649 192.0 192.0 64.0 0.0 6144.0 1972.2 32000.0 4111.6 55296.0 25472.7 702 0.431 3 0.218 0.649 192.0 192.0 64.0 0.0 6144.0 1972.2 32000.0 4111.6 55296.0 25472.7 702 0.431 3 0.218 0.649 192.0 192.0 64.0 0.0 6144.0 2109.7 32000.0 4111.6 55296.0 25472.7 702 0.431 3 0.218 0.649
要明白上面各列的意义，先看JVM堆内存布局：
可以看出：
堆内存 = 年轻代 + 年老代 + 永久代 年轻代 = Eden区 + 两个Survivor区（From和To）
现在来解释各列含义：
S0C、S1C、S0U、S1U：Survivor 0/1区容量（Capacity）和使用量（Used） EC、EU：Eden区容量和使用量 OC、OU：年老代容量和使用量 PC、PU：永久代容量和使用量 YGC、YGT：年轻代GC次数和GC耗时 FGC、FGCT：Full GC次数和Full GC耗时 GCT：GC总耗时
其他JVM性能调优参考资料：
《Java虚拟机规范》
《Java Performance》
《Trouble Shooting Guide for JavaSE 6 with HotSpot VM》:
《Effective Java》
VisualVM:
jConsole:
Monitoring and Managing JavaSE 6 Applications:
来自： http://my.oschina.net/feichexia/blog/196575Jstat 是JDK自带的一个轻量级小工具，全称是“Java Virtual Machine statistics monitoring tool”。它是一个极强的监视VM内存工具，可以用来监视VM内存内的各种堆和非堆的大小，以及内存使用量。
Jstat位于java的bin目录下，主要是利用JVM内建的指令对Java应用程序的资源和性能进行实时的命令行的监控，同时也包括了对Heap size、垃圾回收状况的监控。
Jstat工具特别强大，有众多的可选项，详细查看堆内各个部分的使用量，以及加载类的数量。使用时，需加上查看进程的进程id，和所选参数。
1. 语法结构：Usage: jstat -help|-options
jstat -
参数解释：
options — 选项，我们一般使用 -gcutil 查看gc情况
vmid — VM的进程号，即当前运行的java进程号
interval — 间隔时间，单位为秒或者毫秒
count — 打印次数，如果缺省则打印无数次
2. 输出格式：
S0 S1 E O P YGC YGCT FGC FGCT GCT
参数解释：
S0 — Heap上的 Survivor space 0 区已使用空间的百分比
S1 — Heap上的 Survivor space 1 区已使用空间的百分比
E — Heap上的 Eden space
区已使用空间的百分比
O — Heap上的 Old space
区已使用空间的百分比
P — Perm space 区已使用空间的百分比
YGC — 从应用程序启动到采样时发生 Young GC 的次数
YGCT– 从应用程序启动到采样时 Young GC 所用的时间(单位秒)
FGC — 从应用程序启动到采样时发生 Full GC 的次数
FGCT– 从应用程序启动到采样时 Full GC 所用的时间(单位秒)
GCT — 从应用程序启动到采样时用于垃圾回收的总时间(单位秒)
3. 实例
（1）实例1：
[root@localhost bin]# jstat -gcutil 25444
S0 S1 E O P YGC YGCT FGC FGCT GCT
11.63 0.00 56.46 66.92 98.49 162 0.248 6 0.331 0.579
其中，25444是java的进程号
（2）实例2：
[root@localhost bin]# jstat -gcutil 25444 1000 5
S0
S1
E
O
P
YGC
YGCT
FGC
FGCT
GCT
58.34 0.00
71.44
23.88 72.08 85498 220.502
14
1.182
221.683
0.00 33.34
35.76
24.32 72.08 85499 220.503
14
1.182
221.685
25.00 0.00
40.51
24.33 72.08 85500 220.505
14 1.182
221.687
0.00 50.00
36.37
24.33 72.08 85501 220.507
14
1.182
221.688
0.00
0.00
0.00
24.35 72.08 85502 220.509
14 1.182
221.691
1）我们可以看到，5次young gc之后，垃圾内存被从Eden space区(E)放入了Old space区(O)，并引起了百分比的变化，导致Survivor space使用的百分比从58.344%(S0)降到0%(S1)。有效释放了内存空间.
2）一次full gc之后，Old space区(O)的内存被回收，占用的百分比会下降。
3）常驻内存区(P)的使用率，始终停留在72.08%左右，说明常驻内存没有突变，比较正常。
如果young gc和full gc能够正常发生，而且都能有效回收内存，常驻内存区变化不明显，则说明java内存释放情况正常，垃圾回收及时，java内存泄露的几率就会大大降低。但也不能说明一定没有内存泄露。
4）CT 是YGCT 和FGCT的时间总和。
附注：JVM内存管理
JVM的内存分栈内存、堆内存、本地方法栈和方法区四部分。java通过类加载器来加载class文件，加载到内存后，会把类、方法、 常变量放到堆内存中。因为java是自动进行垃圾回收的，所以放入堆内存中的东西，哪些该回收，哪些不该回收？这都需要jvm去额外的线程去进行判断。但 如果对于一个大型的J2EE系统来说，当创建的对象及方法变量比较多时，即堆内存中的对象比较多，如果一个一个对象去进行循环判断是否该回收时，这样的回 收机制未免太耗时了，系统的性能一定会下降，jvm为了提高jvm执行效率，采用了堆内存分区管理的机制。
JVM把堆内存分三大块：Young Generation Space 新生区（也称新生代）、Tenure generation space养老区（也称旧生代）、Permanent Space 永久存储区。分区是为了进行模块化管理，管理不同的对象及变量以提高JVM的执行效率。
对于Young Generation Space ，它主要用来存储新创建的对象，内存大小会比较小，垃圾回收会比较频繁。对此区又分三个区域：一个Eden Space和两个Survivor Space。有一个前辈对这三个区域描述的相当透彻：
对于Tenure generation space，它主要是用来存储那些长时间被引用的对象。因为它里面存放的是经过几次在Young Genderation Space 进行扫描判断过仍存活的对象，内存大小会比较大，垃圾回收频率会比较小。
对于Permanent Space 永久存储区，它是用来存储一些值信息不经常变更的东东，有类定义、字节码和常量等。2013-10-30 15:34:34| 分类： 性能LR/Jmeter/Co |举报 |字号
| S0 S1 E O P YGC YGCT FGC FGCT GCT LGCC GCC |
|
|||||
| 87.71 0.00 94.71 59.45 59.03 20832 1961.089 121 74.676 2035.765 Allocation Failure No GC | ||||||
| 87.71 0.00 94.71 59.45 59.03 20832 1961.089 121 74.676 2035.765 Allocation Failure No GC | ||||||
| 87.71 0.00 94.71 59.45 59.03 20832 1961.089 121 74.676 2035.765 Allocation Failure No GC | ||||||
| 87.71 0.00 94.71 59.45 59.03 20832 1961.089 121 74.676 2035.765 Allocation Failure No GC | ||||||
| 87.71 0.00 94.71 59.45 59.03 20832 1961.089 121 74.676 2035.765 Allocation Failure No GC | ||||||
正好对应JVM 的内存分代
图中参数含义如下：
S0 — Heap
上的 Survivor space 0 区已使用空间的百分比 S1 — Heap上的 Survivor space 1 区已使用空间的百
分比 E — Heap上的 Eden space 区已使用空间的百分比 O — Heap上的 Old space 区已使
用空间的百分比 P — Perm space 区已使用空间的百分比
YGC — 从应用程序启动到采样时发生 Young GC 的次数
YGCT– 从应用程序启动到采样时 Young GC 所用的时间(单位秒) FGC — 从应用程序启动到采样时发生 Full GC 的次数
FGCT– 从应用程序启动到采样时 Full GC 所用的时间(单位秒) GCT — 从应用程序启动到采样时用于垃圾回收的总时间(单位秒)
一、相关概念
基本回收算法
分代垃圾回收详述
如上图所示，为Java堆中的各代分布。
GC类型
GC有两种类型：Scavenge GC和Full GC。
二、垃圾回收器
目前的收集器主要有三种：串行收集器、并行收集器、并发收集器。
使用单线程处理所有垃圾回收工作，因为无需多线程交互，所以效率比较高。但是，也无法使用多处理器的优势，所以此收集器适合单处理器机器。当然，此收集器也可以用在小数据量（100M左右）情况下的多处理器机器上。可以使用-XX:+UseSerialGC打开。
并行收集器
对年轻代进行并行垃圾回收，因此可以减少垃圾回收时间。一般在多线程多处理器机器上使用。使用-XX:+UseParallelGC.打开。并行收集器在J2SE5.0第六6更新上引入，在Java SE6.0中进行了增强--可以堆年老代进行并行收集。如果年老代不使用并发收集的话，是使用单线程进行垃圾回收，因此会制约扩展能力。使用-XX:+UseParallelOldGC打开。
1. 使用-XX:ParallelGCThreads=设置并行垃圾回收的线程数。此值可以设置与机器处理器数量相等。
2. 此收集器可以进行如下配置：
§ 最大垃圾回收暂停:指定垃圾回收时的最长暂停时间，通过-XX:MaxGCPauseMillis=指定。为毫秒.如果指定了此值的话，堆大小和垃圾回收相关参数会进行调整以达到指定值。设定此值可能会减少应用的吞吐量。
§ 吞吐量:吞吐量为垃圾回收时间与非垃圾回收时间的比值，通过-XX:GCTimeRatio=来设定，公式为1/（1+N）。例如，-XX:GCTimeRatio=19时，表示5%的时间用于垃圾回收。默认情况为99，即1%的时间用于垃圾回收。
并发收集器可以保证大部分工作都并发进行（应用不停止），垃圾回收只暂停很少的时间，此收集器适合对响应时间要求比较高的中、大规模应用。使用-XX:+UseConcMarkSweepGC打开。
1. 并 发收集器主要减少年老代的暂停时间，他在应用不停止的情况下使用独立的垃圾回收线程，跟踪可达对象。在每个年老代垃圾回收周期中，在收集初期并发收集器会 对整个应用进行简短的暂停，在收集中还会再暂停一次。第二次暂停会比第一次稍长，在此过程中多个线程同时进行垃圾回收工作。
2. 并发收集器使用处理器换来短暂的停顿时间。在一个N个处理器的系统上，并发收集部分使用K/N个可用处理器进行回收，一般情况下1<=K<=N/4。
3. 在只有一个处理器的主机上使用并发收集器，设置为incremental mode模式也可获得较短的停顿时间。
4. 浮动垃圾：由于在应用运行的同时进行垃圾回收，所以有些垃圾可能在垃圾回收进行完成时产生，这样就造成了“Floating Garbage”，这些垃圾需要在下次垃圾回收周期时才能回收掉。所以，并发收集器一般需要20%的预留空间用于这些浮动垃圾。
5. Concurrent Mode Failure：并发收集器在应用运行时进行收集，所以需要保证堆在垃圾回收的这段时间有足够的空间供程序使用，否则，垃圾回收还未完成，堆空间先满了。这种情况下将会发生“并发模式失败”，此时整个应用将会暂停，进行垃圾回收。
6. 启动并发收集器：因为并发收集在应用运行时进行收集，所以必须保证收集完成之前有足够的内存空间供程序使用，否则会出现“Concurrent Mode Failure”。通过设置-XX:CMSInitiatingOccupancyFraction=指定还有多少剩余堆时开始执行并发收集
2. 小结
o 串行处理器：
--适用情况：数据量比较小（100M左右）；单处理器下并且对响应时间无要求的应用。
--缺点：只能用于小型应用
o 并行处理器：
--适用情况：“对吞吐量有高要求”，多CPU、对应用响应时间无要求的中、大型应用。举例：后台处理、科学计算。
--缺点：应用响应时间可能较长
o 并发处理器：
--适用情况：“对响应时间有高要求”，多CPU、对应用响应时间有较高要求的中、大型应用。举例：Web服务器/应用服务器、电信交换、集成开发环境。
三、常见配置举例
[Full GC 121376K->10414K(130112K), 0.0650971 secs]
[GC [DefNew: 8614K->8614K(9088K), 0.0000665 secs][Tenured: 112761K->10414K(121024K), 0.0433488 secs] 121376K->10414K(130112K), 0.0436268 secs]
四、调优总结
减少年轻代和年老代花费的时间，一般会提高应用的效率
五、参考文献
转载▼