JVM调优的liunx命令

在平时的运维工作中,我们经常会碰到下面这些问题:

1、OutOfMemoryError,内存不足 
2、内存泄露 
3、线程死锁 
4、锁争用(Lock Contention) 
5、Java 进程消耗 CPU 过高
导致服务器 CPU 或者内存飙高影响线上业务,对于解决以上问题,我们常用的 JVM 性能调优监控工具有:jps、jstat、jstack、jmap、jhat、hprof、jinfo
如果想要查看 Java 进程中线程堆栈的信息,可以选择 jstack,如果要查看堆内存,可以使用 jmap 导出并使用 jhat 来进行分析,包括查看类的加载信息,GC 算法那,对象的使用情况等,还可以使用 jstat 来对 JVM 进行统计监测,包括查看各个区内存和 GC 的情况,还可以使用 hprof 能够展现 CPU 使用率,统计堆内存使用情况。
1、jps 命令:
作用:
主要用来输出 JVM 中运行的进程状态信息。语法格式如下:
语法格式:
jps [options] [hostid]
如果不指定 hostid 就默认为当前主机或服务器。
命令参数:
-q 不输出类名、Jar 名和传入 main 方法的参数
-m 输出传入 main 方法的参数
-l 输出 main 类或 Jar 的全限名
-v 输出传入 JVM 的参数
 
[root@web02 ~]# jps -lm
Picked up _JAVA_OPTIONS: -Dawt.useSystemAAFontSettings=lcd
9346 org.apache.catalina.startup.Bootstrap start
19301 GpsTracker4.jar12520 org.apache.catalina.startup.Bootstrap start
25402 GPSTracker1.jar18463 GPSTracker5.jar7940 org.apache.catalina.startup.Bootstrap start
12452 org.apache.catalina.startup.Bootstrap start
8865 org.apache.catalina.startup.Bootstrap start
5489 org.apache.catalina.startup.Bootstrap start
1568 org.apache.catalina.startup.Bootstrap start
32543 GPSTracker2.jar25441 org.apache.catalina.startup.Bootstrap start
574 org.apache.catalina.startup.Bootstrap start
14498 org.apache.catalina.startup.Bootstrap start
25453 ./DEyesPushServer.jar2723 org.apache.catalina.startup.Bootstrap start
10584 bdwiseGpsTrack.jar2031 org.apache.catalina.startup.Bootstrap start
 
加入参数 -V 后,会把 jvm 的启动参数全部输出:
[root@web02 ~]# jps -lmv
Picked up _JAVA_OPTIONS: -Dawt.useSystemAAFontSettings=lcd
9346 org.apache.catalina.startup.Bootstrap start -Djava.util.logging.config.file=/home/tomcat/tomcat6/9704_event/conf/logging.properties -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -Xms256m -Xmx3072m -XX:PermSize=256M -XX:MaxPermSize=768M -Djava.endorsed.dirs=/home/tomcat/tomcat6/9704_event/endorsed -Dcatalina.base=/home/tomcat/tomcat6/9704_event -Dcatalina.home=/home/tomcat/tomcat6/9704_event -Djava.io.tmpdir=/home/tomcat/tomcat6/9704_event/temp -Dawt.useSystemAAFontSettings=lcd
19301 GpsTracker4.jar -Dawt.useSystemAAFontSettings=lcd
12520 org.apache.catalina.startup.Bootstrap start -Djava.util.logging.config.file=/home/tomcat/tomcat_gps_prod/9301_gpstrack/conf/logging.properties -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -Xms256m -Xmx3072m -XX:PermSize=256M -XX:MaxPermSize=768M -Djava.endorsed.dirs=/home/tomcat/tomcat_gps_prod/9301_gpstrack/endorsed -Dcatalina.base=/home/tomcat/tomcat_gps_prod/9301_gpstrack -Dcatalina.home=/home/tomcat/tomcat_gps_prod/9301_gpstrack -Djava.io.tmpdir=/home/tomcat/tomcat_gps_prod/9301_gpstrack/temp -Dawt.useSystemAAFontSettings=lcd
25402 GPSTracker1.jar -Dawt.useSystemAAFontSettings=lcd
18463 GPSTracker5.jar -Dawt.useSystemAAFontSettings=lcd
 
2.jstat 命令
作用:
用于监视虚拟机运行时状态信息的命令,它可以显示出虚拟机进程中的类装载、内存、垃圾收集、JIT 编译等运行数据
语法格式:
jstat [option] LVMID [interval] [count]
 
参数含义:
[option] : 操作参数
LVMID : Java 虚拟机 ID,在 Linux/Unix 系统上一般就是进程 ID
[interval] : 是采样时间间隔
[count] : count 是采样数目
 

 

option 参数总览: 
 
option 参数详解
-class:监视类装载、卸载数量、总空间以及耗费的时间
[root@web02 ~]# jstat -class 9346
Picked up _JAVA_OPTIONS: -Dawt.useSystemAAFontSettings=lcd
Loaded Bytes Unloaded Bytes Time
31909 64439.1 998 2028.2 22.75
[root@web02 ~]# jstat -class 12520
Picked up _JAVA_OPTIONS: -Dawt.useSystemAAFontSettings=lcd
Loaded Bytes Unloaded Bytes Time
7696 15390.2 0 0.0 8.84
[root@web02 ~]# jstat -class 7940
Picked up _JAVA_OPTIONS: -Dawt.useSystemAAFontSettings=lcd
Loaded Bytes Unloaded Bytes Time
27776 54941.7 136 292.5 27.44
 
Loaded : 加载 class 的数量
Bytes : class 字节大小
Unloaded : 未加载 class 的数量
Bytes : 未加载 class 的字节大小
Time : 加载时间
 
-compiler:输出 JIT 编译过的方法数量耗时等
[root@web02 ~]# jstat -compiler 9346
Picked up _JAVA_OPTIONS: -Dawt.useSystemAAFontSettings=lcd
Compiled Failed Invalid Time FailedType FailedMethod
6262 5 0 137.64 1 org/springframework/context/annotation/CommonAnnotationBeanPostProcessor buildResourceMetadata
[root@web02 ~]# jstat -compiler 12520
Picked up _JAVA_OPTIONS: -Dawt.useSystemAAFontSettings=lcd
Compiled Failed Invalid Time FailedType FailedMethod
1013 3 0 18.29 1 org/apache/catalina/loader/WebappClassLoader findResourceInternal
[root@web02 ~]# jstat -compiler 7940
Picked up _JAVA_OPTIONS: -Dawt.useSystemAAFontSettings=lcd
Compiled Failed Invalid Time FailedType FailedMethod
4163 2 0 84.02 1 org/apache/catalina/loader/WebappClassLoader findResourceInternal
[root@web02 ~]# ps -ef | grep 7940
root 5665 4118 0 17:29 pts/11 00:00:00 grep 7940
 

 

Compiled : 编译数量 
Failed : 编译失败数量 
Invalid : 无效数量 
Time : 编译耗时 
FailedType : 失败类型 
FailedMethod : 失败方法的全限定名 
-gc:垃圾回收堆的行为统计,常用命令
[root@web02 ~]# jstat -gc 9346Picked up _JAVA_OPTIONS: -Dawt.useSystemAAFontSettings=lcd
S0C S1C S0U S1U EC EU OC OU PC PU YGC YGCT FGC FGCT GCT
20992.0 32256.0 4952.4 0.0 227840.0 147675.8 222720.0 167726.6 262144.0 188115.3 46 1.324 5 2.933 4.256
 
比如下面输出的是 GC 信息,采样时间间隔为 250ms,采样数为 4:
[root@web02 ~]# jstat -gc 9346 250 4Picked up _JAVA_OPTIONS: -Dawt.useSystemAAFontSettings=lcd
S0C S1C S0U S1U EC EU OC OU PC PU YGC YGCT FGC FGCT GCT
20992.0 32256.0 4952.4 0.0 227840.0 147678.0 222720.0 167726.6 262144.0 188118.3 46 1.324 5 2.933 4.25620992.0 32256.0 4952.4 0.0 227840.0 147678.0 222720.0 167726.6 262144.0 188118.3 46 1.324 5 2.933 4.25620992.0 32256.0 4952.4 0.0 227840.0 147678.0 222720.0 167726.6 262144.0 188118.3 46 1.324 5 2.933 4.25620992.0 32256.0 4952.4 0.0 227840.0 147678.0 222720.0 167726.6 262144.0 188118.3 46 1.324 5 2.933 4.256
 

 

要明白上面各列的意义,先看 JVM 堆内存布局: 
 
可以看出:

 

堆内存 = 年轻代 + 年老代 + 永久代 
年轻代 = Eden 区 + 两个 Survivor 区(From 和 To)
现在来解释各列含义:
C 即 Capacity 总容量,U 即 Used 已使用的容量

 

S0C : survivor0 区的总容量 
S1C : survivor1 区的总容量 
S0U : survivor0 区已使用的容量 
S1C : survivor1 区已使用的容量 
EC : Eden 区的总容量 
EU : Eden 区已使用的容量 
OC : Old 区的总容量 
OU : Old 区已使用的容量 
PC 当前 perm 的容量 (KB) 
PU perm 的使用 (KB) 
YGC : 新生代垃圾回收次数 
YGCT : 新生代垃圾回收时间 
FGC : 老年代垃圾回收次数 
FGCT : 老年代垃圾回收时间 
GCT : GC 垃圾回收总消耗时间
-gcutil:同 -gc,不过输出的是已使用空间占总空间的百分比
[root@web02 etc]# jstat -gcutil 29544
S0 S1 E O P YGC YGCT FGC FGCT GCT
62.67 0.00 65.20 16.10 99.85 34 1.235 0 0.000 1.235
 
-gccause:垃圾收集统计概述(同 -gcutil),附加最近两次垃圾回收事件的原因
[root@web02 etc]# jstat -gccause 29544
S0 S1 E O P YGC YGCT FGC FGCT GCT LGCC GCC
62.67 0.00 65.20 16.10 99.85 34 1.235 0 0.000 1.235 Allocation Failure No GC
 

 

LGCC:最近垃圾回收的原因 
GCC:当前垃圾回收的原因 
-gcnew:统计新生代的行为
[root@web02 etc]# jstat -gcnew 29544
S0C S1C S0U S1U TT MTT DSS EC EU YGC YGCT
34944.0 34944.0 21900.2 0.0 16 31 17472.0 279616.0 182323.5 34 1.235
 

 

TT:Tenuring threshold(提升阈值) 
MTT:最大的 tenuring threshold 
DSS:survivor 区域大小 (KB) 
-gcnewcapacity:新生代与其相应的内存空间的统计
Picked up _JAVA_OPTIONS: -Dawt.useSystemAAFontSettings=lcd
NGCMN NGCMX NGC S0CMX S0C S1CMX S1C ECMX EC YGC FGC
349504.0 349504.0 349504.0 34944.0 34944.0 34944.0 34944.0 279616.0 279616.0 34 0
 

 

NGC: 当前年轻代的容量 (KB) 
S0CMX: 最大的 S0 空间 (KB) 
S0C: 当前 S0 空间 (KB) 
ECMX: 最大 eden 空间 (KB) 
EC: 当前 eden 空间 (KB)
-gcold:统计旧生代的行为
[root@web02 etc]# jstat -gclod 29544
PC PU OC OU YGC FGC FGCT GCT
164480.0 164236.6 699072.0 112581.0 34 0 0.000 1.235
 
-gcoldcapacity:统计旧生代的大小和空间
[root@web02 etc]# jstat -gcoldcapacity 29544
OGCMN OGCMX OGC OC YGC FGC FGCT GCT
699072.0 699072.0 699072.0 699072.0 34 0 0.000 1.235
 
-gcpermcapacity:永生代行为统计
[root@web02 etc]# jstat -gcpermcapacity 29544
PGCMN PGCMX PGC PC YGC FGC FGCT GCT
131072.0 262144.0 164480.0 164480.0 34 0 0.000 1.235
 
-printcompilation:hotspot 编译方法统计
[root@web02 etc]# jstat -printcompilation 29544
Compiled Size Type Method
2957 1032 1 org/apache/jasper/compiler/SmapUtil$SDEInstaller copyConstantPool
 

 

Compiled:被执行的编译任务的数量 
Size:方法字节码的字节数 
Type:编译类型 
Method:编译方法的类名和方法名。类名使用”/” 代替 “.” 作为空间分隔符. 方法名是给出类的方法名. 格式是一致于 HotSpot – XX:+PrintComplation 选项

 

jmap 命令: 
作用:
jmap(JVM Memory Map) 命令用来查看堆内存使用状况,一般结合 jhat 使用,用于生成 heap dump 文件,如果不使用这个命令,还可以使用 -XX:+HeapDumpOnOutOfMemoryError 参数来让虚拟机出现 OOM 的时候·自动生成 dump 文件。jmap 不仅能生成 dump 文件,还可以查询 finalize 执行队列、Java 堆和永久代的详细信息,如当前使用率、当前使用的是哪种收集器等。
命令格式:
jmap [option] LVMID
 
option 参数:

 

dump : 导出内存转储快照 
finalizerinfo : 显示在 F-Queue 队列等待 Finalizer 线程执行 finalizer 方法的对象 
heap : 显示 Java 堆详细信息 
histo : 显示堆中对象的统计信息 
permstat : to print permanent generation statistics 
F : 当 -dump 没有响应时,强制生成 dump 快照
-permstat:打印进程的类加载器和类加载器加载的持久代对象信息,输出:类加载器名称、对象是否存活(不可靠)、对象地址、父类加载器、已加载的类大小等信息
$ jmap -permstat 28920
Attaching to process ID 28920, please wait...
Debugger attached successfully.
Server compiler detected.
JVM version is 24.71-b01
finding class loader instances ..done.
computing per loader stat ..done.
please wait.. computing liveness.liveness analysis may be inaccurate ...
 
class_loader classes bytes parent_loader alive? type
<bootstrap> 3111 18154296 null live <internal>
0x0000000600905cf8 1 1888 0x0000000600087f08 dead sun/reflect/DelegatingClassLoader@0x00000007800500a0
0x00000006008fcb48 1 1888 0x0000000600087f08 dead sun/reflect/DelegatingClassLoader@0x00000007800500a0
0x00000006016db798 0 0 0x00000006008d3fc0 dead java/util/ResourceBundle$RBClassLoader@0x0000000780626ec0
0x00000006008d6810 1 3056 null dead sun/reflect/DelegatingClassLoader@0x00000007800500a0
 
-heap:查看进程堆内存使用情况,包括使用的 GC 算法、堆配置参数和各代中堆内存使用情况, 可以用此来判断内存目前的使用情况以及垃圾回收情况
[root@web02 etc]# jmap -heap 29544
Attaching to process ID 29544, please wait...
Debugger attached successfully.
Server compiler detected.
JVM version is 24.71-b01
 
using parallel threads in the new generation.
using thread-local object allocation.
Concurrent Mark-Sweep GC
 
Heap Configuration:
MinHeapFreeRatio = 40
MaxHeapFreeRatio = 70
MaxHeapSize = 1073741824 (1024.0MB)
NewSize = 357892096 (341.3125MB)
MaxNewSize = 357892096 (341.3125MB)
OldSize = 715784192 (682.625MB)
NewRatio = 2
SurvivorRatio = 8
PermSize = 134217728 (128.0MB)
MaxPermSize = 268435456 (256.0MB)
G1HeapRegionSize = 0 (0.0MB)
 
Heap Usage:
New Generation (Eden + 1 Survivor Space):
capacity = 322109440 (307.1875MB)
used = 231861032 (221.11991119384766MB)
free = 90248408 (86.06758880615234MB)
71.98206671620676% used
Eden Space:
capacity = 286326784 (273.0625MB)
used = 209435192 (199.73296356201172MB)
free = 76891592 (73.32953643798828MB)
73.14551194763533% used
From Space:
capacity = 35782656 (34.125MB)
used = 22425840 (21.386947631835938MB)
free = 13356816 (12.738052368164062MB)
62.672374012706044% used
To Space:
capacity = 35782656 (34.125MB)
used = 0 (0.0MB)
free = 35782656 (34.125MB)
0.0% used
concurrent mark-sweep generation:
capacity = 715849728 (682.6875MB)
used = 115282968 (109.9424057006836MB)
free = 600566760 (572.7450942993164MB)
16.104353119206607% used
Perm Generation:
capacity = 168427520 (160.625MB)
used = 168178312 (160.38733673095703MB)
free = 249208 (0.23766326904296875MB)
99.85203843172422% used
 
52703 interned Strings occupying 5899960 bytes.
 
 
可以很清楚的看到 Java 堆中各个区域目前的情况。
-histo:打印堆的对象统计,包括对象数、内存大小等等 (因为在 dump:live 前会进行 full gc,如果带上 live 则只统计活对象,因此不加 live 的堆大小要大于加 live 堆的大小 )
root@web02 etc]# jmap -histo:live 29544 | more
Picked up _JAVA_OPTIONS: -Dawt.useSystemAAFontSettings=lcd
 
num #instances #bytes class name
----------------------------------------------
1: 294647 42231088 <constMethodKlass>
2: 294647 37726512 <methodKlass>
3: 30310 32955000 <constantPoolKlass>
4: 92965 27338592 [B
5: 254526 26667336 [C
6: 30310 21857304 <instanceKlassKlass>
7: 24015 17222656 <constantPoolCacheKlass>
8: 89222 6150624 [Ljava.lang.Object;
9: 250330 6007920 java.lang.String
10: 50382 4030560 java.lang.reflect.Method
11: 44966 3683408 [Ljava.util.HashMap$Entry;
12: 82747 3309880 java.util.LinkedHashMap$Entry
13: 5129 3286856 <methodDataKlass>
14: 99275 3176800 java.util.concurrent.ConcurrentHashMap$HashEntry
15: 98922 3165504 java.util.HashMap$Entry
16: 31965 3020128 java.lang.Class
17: 47367 2341800 [[I
18: 40473 2188416 [S
19: 25680 1438080 java.util.LinkedHashMap
20: 23419 1234360 [Ljava.lang.String;
21: 7983 1145488 [I
22: 44966 1079184 java.util.HashMap$FrontCache
23: 8249 1064896 [Ljava.util.concurrent.ConcurrentHashMap$HashEntry;
24: 21452 1029696 org.apache.catalina.loader.ResourceEntry
25: 23879 955160 java.lang.ref.SoftReference
26: 29514 944448 java.lang.ref.WeakReference
27: 38989 935736 java.util.ArrayList
 
xml class name 是对象类型,说明如下:
B byte
C char
D double
F float
I int
J long
Z boolean
[数组,如 [I 表示 int[]
[L+ 类名 其他对象
 
-dump: 导出内存转储快照
常用格式:

 

-dump::live,format=b,file= pid 
dump:堆到文件 
format:指定输出格式 
live:指明是活着的对象 
file:指定文件名
dump.hprof 这个后缀是为了后续可以直接用 MAT(Memory Anlysis Tool) 打开。
-finalizerinfo:打印等待回收对象的信息
[root@web02 home]# jmap -finalizerinfo 29544
Picked up _JAVA_OPTIONS: -Dawt.useSystemAAFontSettings=lcd
Attaching to process ID 29544, please wait...
Debugger attached successfully.
Server compiler detected.
JVM version is 24.71-b01
Number of objects pending for finalization: 0
 
可以看到当前 F-QUEUE 队列中并没有等待 Finalizer 线程执行 finalizer 方法的对象。
-F:强制模式。如果指定的 pid 没有响应,请使用 jmap -dump 或 jmap -histo 选项。此模式下,不支持 live 子选项。
jhat 命令:
作用:
jhat(JVM Heap Analysis Tool) 命令是与 jmap 搭配使用,用来分析 jmap 生成的 dump,jhat 内置了一个微型的 HTTP/HTML 服务器,生成 dump 的分析结果后,可以在浏览器中查看。在此要注意,一般不会直接在服务器上进行分析,因为 jhat 是一个耗时并且耗费硬件资源的过程,一般把服务器生成的 dump 文件复制到本地或其他机器上进行分析。
命令格式:
jhat [dumpfile]
 
命令参数:
-stack false|true
 
关闭对象分配调用栈跟踪 (tracking object allocation call stack)。 如果分配位置信息在堆转储中不可用. 则必须将此标志设置为 false. 默认值为 true.
-refs false|true
关闭对象引用跟踪 (tracking of references to objects)。 默认值为 true. 默认情况下, 返回的指针是指向其他特定对象的对象, 如反向链接或输入引用 (referrers or incoming references), 会统计 / 计算堆中的所有对象。
-port port-number

 

设置 jhat HTTP server 的端口号. 默认值 7000. 
-exclude exclude-file
指定对象查询时需要排除的数据成员列表文件 (a file that lists data members that should be excluded from the reachable objects query)。 例如, 如果文件列列出了 java.lang.String.value , 那么当从某个特定对象 Object o 计算可达的对象列表时, 引用路径涉及 java.lang.String.value 的都会被排除。
-baseline exclude-file
指定一个基准堆转储 (baseline heap dump)。 在两个 heap dumps 中有相同 object ID 的对象会被标记为不是新的 (marked as not being new). 其他对象被标记为新的 (new). 在比较两个不同的堆转储时很有用.
-debug int
设置 debug 级别. 0 表示不输出调试信息。 值越大则表示输出更详细的 debug 信息.
-version

 

启动后只显示版本信息就退出 
-J< flag >
因为 jhat 命令实际上会启动一个 JVM 来执行, 通过 -J 可以在启动 JVM 时传入一些启动参数. 例如, -J-Xmx512m 则指定运行 jhat 的 Java 虚拟机使用的最大堆内存为 512 MB. 如果需要使用多个 JVM 启动参数, 则传入多个 -Jxxxxxx.
示例:
$ jhat -J-Xmx512m dump.hprof
eading from dump.hprof...
Dump file created Fri Mar 11 17:13:42 CST 2016
Snapshot read, resolving...
Resolving 271678 objects...
Chasing references, expect 54 dots......................................................
Eliminating duplicate references......................................................
Snapshot resolved.
Started HTTP server on port 7000
Server is ready.
 
中间的 -J-Xmx512m 是在 dump 快照很大的情况下分配 512M 内存去启动 HTTP 服务器,运行完之后就可在浏览器打开Http://localhost:7000进行快照分析 堆快照分析主要在最后面的 Heap Histogram 里,里面根据 class 列出了 dump 的时候所有存活对象。

 

分析同样一个 dump 快照,MAT 需要的额外内存比 jhat 要小的多的多,所以建议使用 MAT 来进行分析,当然也看个人偏好。 
分析
打开浏览器Http://localhost:7000,该页面提供了几个查询功能可供使用:
All classes including platform
Show all members of the rootset
Show instance counts for all classes (including platform)
Show instance counts for all classes (excluding platform)
Show heap histogram
Show finalizer summary
Execute Object Query Language (OQL) query
 
一般查看堆异常情况主要看这个两个部分: Show instance counts for all classes (excluding platform),平台外的所有对象信息。如下图:
Show heap histogram 以树状图形式展示堆情况。如下图:
具体排查时需要结合代码,观察是否大量应该被回收的对象在一直被引用或者是否有占用内存特别大的对象无法被回收。
一般情况,会 down 到客户端用工具来分析
jstack 命令
jstack 用于生成 java 虚拟机当前时刻的线程快照。线程快照是当前 java 虚拟机内每一条线程正在执行的方法堆栈的集合,生成线程快照的主要目的是定位线程出现长时间停顿的原因,如线程间死锁、死循环、请求外部资源导致的长时间等待等。
线程出现停顿的时候通过 jstack 来查看各个线程的调用堆栈,就可以知道没有响应的线程到底在后台做什么事情,或者等待什么资源。 如果 java 程序崩溃生成 core 文件,jstack 工具可以用来获得 core 文件的 java stack 和 native stack 的信息,从而可以轻松地知道 java 程序是如何崩溃和在程序何处发生问题。
另外,jstack 工具还可以附属到正在运行的 java 程序中,看到当时运行的 java 程序的 java stack 和 native stack 的信息, 如果现在运行的 java 程序呈现 hung 的状态,jstack 是非常有用的。
命令格式
jstack [option] LVMID
option 参数
-F : 当正常输出请求不被响应时,强制输出线程堆栈
-l : 除堆栈外,显示关于锁的附加信息
-m : 如果调用到本地方法的话,可以显示 C/C++ 的堆栈
示例
root@web02 home]# jstack -l 29544 | more
Picked up _JAVA_OPTIONS: -Dawt.useSystemAAFontSettings=lcd
2017-12-15 10:49:21
Full thread dump Java HotSpot(TM) 64-Bit Server VM (24.71-b01 mixed mode):
 
"Attach Listener" daemon prio=10 tid=0x00007f2bf4002000 nid=0x2f4f waiting on condition [0x0000000000000000]
java.lang.Thread.State: RUNNABLE
 
Locked ownable synchronizers:
- None
 
"Abandoned connection cleanup thread" daemon prio=10 tid=0x00007f2bac1fa000 nid=0x5e45 in Object.wait()[0x00007f2c1c672000]
java.lang.Thread.State: TIMED_WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:135)
- locked <0x00000000cab2d240> (a java.lang.ref.ReferenceQueue$Lock)
at com.mysql.jdbc.AbandonedConnectionCleanupThread.run(AbandonedConnectionCleanupThread.java:43)
 
Locked ownable synchronizers:
- None
分析
线程状态

 

NEW, 未启动的。不会出现在 Dump 中。 
RUNNABLE, 在虚拟机内执行的。 
BLOCKED, 受阻塞并等待监视器锁。 
WATING, 无限期等待另一个线程执行特定操作。 
TIMED_WATING, 有时限的等待另一个线程的特定操作。 
TERMINATED, 已退出的。
Monitor
在多线程的 JAVA 程序中,实现线程之间的同步,就要说说 Monitor。 Monitor 是 Java 中用以实现线程之间的互斥与协作的主要手段,它可以看成是对象或者 Class 的锁。每一个对象都有,也仅有一个 monitor。下 面这个图,描述了线程和 Monitor 之间关系,以 及线程的状态转换图:
进入区 (Entrt Set): 表示线程通过 synchronized 要求获取对象的锁。如果对象未被锁住, 则迚入拥有者; 否则则在进入区等待。一旦对象锁被其他线程释放, 立即参与竞争。
拥有者 (The Owner): 表示某一线程成功竞争到对象锁。
等待区 (Wait Set): 表示线程通过对象的 wait 方法, 释放对象的锁, 并在等待区等待被唤醒。
从图中可以看出,一个 Monitor 在某个时刻,只能被一个线程拥有,该线程就是 “Active Thread”,而其它线程都是 “Waiting Thread”,分别在两个队列 “ Entry Set”和 “Wait Set”里面等候。在 “Entry Set”中等待的线程状态是 “Waiting for monitor entry”,而在 “Wait Set”中等待的线程状态是 “in Object.wait()”。 先看 “Entry Set”里面的线程。我们称被 synchronized 保护起来的代码段为临界区。当一个线程申请进入临界区时,它就进入了 “Entry Set”队列。对应的 code 就像:
synchronized(obj) {
.........
}
 
调用修饰
表示线程在方法调用时, 额外的重要的操作。线程 Dump 分析的重要信息。修饰上方的方法调用。
locked < 地址 > 目标:使用 synchronized 申请对象锁成功, 监视器的拥有者。
waiting to lock < 地址 > 目标:使用 synchronized 申请对象锁未成功, 在迚入区等待。
waiting on < 地址 > 目标:使用 synchronized 申请对象锁成功后, 释放锁幵在等待区等待。
parking to wait for < 地址 > 目标
locked
at oracle.jdbc.driver.PhysicalConnection.prepareStatement
- locked <0x00002aab63bf7f58> (a oracle.jdbc.driver.T4CConnection)
at oracle.jdbc.driver.PhysicalConnection.prepareStatement
- locked <0x00002aab63bf7f58> (a oracle.jdbc.driver.T4CConnection)
at com.jiuqi.dna.core.internal.db.datasource.PooledConnection.prepareStatement
 
通过 synchronized 关键字, 成功获取到了对象的锁, 成为监视器的拥有者, 在临界区内操作。对象锁是可以线程重入的。
waiting to lock
at com.jiuqi.dna.core.impl.CacheHolder.isVisibleIn(CacheHolder.java:165)
- waiting to lock <0x0000000097ba9aa8> (a CacheHolder)
at com.jiuqi.dna.core.impl.CacheGroup$Index.findHolder
at com.jiuqi.dna.core.impl.ContextImpl.find
at com.jiuqi.dna.bap.basedata.common.util.BaseDataCenter.findInfo
 
通过 synchronized 关键字, 没有获取到了对象的锁, 线程在监视器的进入区等待。在调用栈顶出现, 线程状态为 Blocked。
waiting on
at java.lang.Object.wait(Native Method)
- waiting on <0x00000000da2defb0> (a WorkingThread)
at com.jiuqi.dna.core.impl.WorkingManager.getWorkToDo
- locked <0x00000000da2defb0> (a WorkingThread)
at com.jiuqi.dna.core.impl.WorkingThread.run
 
通过 synchronized 关键字, 成功获取到了对象的锁后, 调用了 wait 方法, 进入对象的等待区等待。在调用栈顶出现, 线程状态为 WAITING 或 TIMED_WATING。
parking to wait for
park 是基本的线程阻塞原语, 不通过监视器在对象上阻塞。随 concurrent 包会出现的新的机制, 不 synchronized 体系不同。

 

线程动作 
线程状态产生的原因
runnable: 状态一般为 RUNNABLE。
in Object.wait(): 等待区等待, 状态为 WAITING 或 TIMED_WAITING。
waiting for monitor entry: 进入区等待, 状态为 BLOCKED。
waiting on condition: 等待区等待、被 park。
sleeping: 休眠的线程, 调用了 Thread.sleep()。
 
进入区等待
"d&a-3588" daemon waiting for monitor entry [0x000000006e5d5000]
java.lang.Thread.State: BLOCKED (on object monitor)
at com.jiuqi.dna.bap.authority.service.UserService$LoginHandler.handle()
- waiting to lock <0x0000000602f38e90> (a java.lang.Object)
at com.jiuqi.dna.bap.authority.service.UserService$LoginHandler.handle()
 
线程状态 BLOCKED, 线程动作 wait on monitor entry, 调用修饰 waiting to lock 总是一起出现。表示在代码级别已经存在冲突的调用。必然有问题的代码, 需要尽可能减少其发生。
同步块阻塞
一个线程锁住某对象, 大量其他线程在该对象上等待。
"blocker" runnable
java.lang.Thread.State: RUNNABLE
at com.jiuqi.hcl.javadump.Blocker$1.run(Blocker.java:23)
- locked <0x00000000eb8eff68> (a java.lang.Object)
"blockee-11" waiting for monitor entry
java.lang.Thread.State: BLOCKED (on object monitor)
at com.jiuqi.hcl.javadump.Blocker$2.run(Blocker.java:41)
- waiting to lock <0x00000000eb8eff68> (a java.lang.Object)
"blockee-86" waiting for monitor entry
java.lang.Thread.State: BLOCKED (on object monitor)
at com.jiuqi.hcl.javadump.Blocker$2.run(Blocker.java:41)
- waiting to lock <0x00000000eb8eff68> (a java.lang.Object)
 
持续运行的 IO
IO 操作是可以以 RUNNABLE 状态达成阻塞。例如: 数据库死锁、网络读写。 格外注意对 IO 线程的真实状态的分析。 一般来说, 被捕捉到 RUNNABLE 的 IO 调用, 都是有问题的。
以下堆栈显示: 线程状态为 RUNNABLE。 调用栈在 SocketInputStream 或 SocketImpl 上,socketRead0 等方法。 调用栈包含了 jdbc 相关的包。很可能发生了数据库死锁
"d&a-614" daemon prio=6 tid=0x0000000022f1f000 nid=0x37c8 runnable
[0x0000000027cbd000]
java.lang.Thread.State: RUNNABLE
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.read(Unknown Source)
at oracle.net.ns.Packet.receive(Packet.java:240)
at oracle.net.ns.DataPacket.receive(DataPacket.java:92)
at oracle.net.ns.NetInputStream.getNextPacket(NetInputStream.java:172)
at oracle.net.ns.NetInputStream.read(NetInputStream.java:117)
at oracle.jdbc.driver.T4CMAREngine.unmarshalUB1(T4CMAREngine.java:1034)
at oracle.jdbc.driver.T4C8Oall.receive(T4C8Oall.java:588)
 
分线程调度的休眠
正常的线程池等待
"d&a-131" in Object.wait()
java.lang.Thread.State: TIMED_WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
at com.jiuqi.dna.core.impl.WorkingManager.getWorkToDo(WorkingManager.java:322)
- locked <0x0000000313f656f8> (a com.jiuqi.dna.core.impl.WorkingThread)
at com.jiuqi.dna.core.impl.WorkingThread.run(WorkingThread.java:40)
 
可疑的线程等待
"d&a-121" in Object.wait()
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
at java.lang.Object.wait(Object.java:485)
at com.jiuqi.dna.core.impl.AcquirableAccessor.exclusive()
- locked <0x00000003011678d8> (a com.jiuqi.dna.core.impl.CacheGroup)
at com.jiuqi.dna.core.impl.Transaction.lock()
 
总结:
wait on monitor entry: 被阻塞的, 肯定有问题 
runnable : 注意 IO 线程 
in Object.wait(): 注意非线程池等待
jinfo 命令
作用:
jinfo(JVM Configuration info) 这个命令作用是实时查看和调整虚拟机运行参数。 之前的 jps -v 口令只能查看到显示指定的参数,如果想要查看未被显示指定的参数的值就要使用 jinfo 口令
命令格式:
jinfo [option] [args] LVMID
 
option 参数:
-flag : 输出指定 args 参数的值
-flags : 不需要 args 参数,输出所有 JVM 参数的值
-sysprops : 输出系统属性,等同于 System.getProperties()
 
示例:
[root@web02 home]# jinfo -flag MaxPermSize 29544
-XX:MaxPermSize=268435456
 
以上命令就是查看 PID 为 29544 的 MaxPermSize 大小
 
1、jps
Jps 是参照 Unix 系统的取名规则命名的,而他的功能和 ps 的功能类似,可以列举正在运行的饿虚拟机进程并显示虚拟机执行的主类以及这些进程的唯一 ID(LVMID,对应本机来说和 PID 相同),他的用法如下:
Jps [option] [hostid]
jps -q 只输出 LVMID
jps -m 输出 JVM 启动时传给主类的方法
jps -l 输出主类的全名,如果是 Jar 则输出 jar 的路径
jps -v 输出 JVM 的启动参数
2、jstat
jstat 主要用于监控虚拟机的各种运行状态信息,如类的装载、内存、垃圾回收、JIT 编译器等,在没有 GUI 的服务器上,这款工具是首选的一款监控工具。其用法如下:
jstat [option vmid [interval [s|ms] [vount] ] ]
jstat 监控内容 线程好 刷新时间间隔 次数
jstat –gc 20445 1 20 : 监视 Java 堆,包含 eden、2 个 survivor 区、old 区和永久带区域的容量、已用空间、GC 时间合计等信息
jstat –gcutil 20445 1 20: 监视内容与 -gc 相同,但输出主要关注已使用空间占总空间的百分比
jstat –class 20445 1 20: 监视类的装载、卸载数量以及类的装载总空间和耗费时间等
.......-gccapcity......: 监视内容与 -gc 相同,但输出主要关注 Java 区域用到的最大和最小空间
.......-gccause........: 与 -gcutil 输出信息相同,额外输出导致上次 GC 产生的原因
.......-gcnew..........: 监控新生代的 GC 情况
.......-gcnewcapacity..: 与 -gcnew 监控信息相同,输出主要关注使用到的最大和最小空间
.......-gcold..........: 监控老生代的 GC 情况
.......-gcoldcapacity..: 与 -gcold 监控信息相同,输出主要关注使用到的最大和最小空间
.......-gcpermcapacity.: 输出永久带用到的最大和最小空间
.......-compiler.......: 输出 JIT 编译器编译过的方法、耗时信息
.......-printcompilation: 输出已经被 JIT 编译的方法
3、jinfo
jinfo 的作用是实时查看虚拟机的各项参数信息 jps –v 可以查看虚拟机在启动时被显式指定的参数信息,但是如果你想知道默认的一些参数信息呢?除了去查询对应的资料以外,jinfo 就显得很重要了。jinfo 的用法如下:
Jinfo [option] pid
4、jmap
map 用于生成堆快照(heapdump)。当然我们有很多方法可以取到对应的 dump 信息,如我们通过 JVM 启动时加入启动参数 –XX:HeapDumpOnOutOfMemoryError 参数,可以让 JVM 在出现内存溢出错误的时候自动生成 dump 文件,亦可以通过 -XX:HeapDumpOnCtrlBreak 参数,在运行时使用 ctrl+break 按键生成 dump 文件,当然我们也可以使用 kill -3 pid 的方式去恐吓 JVM 生成 dump 文件。Jmap 的作用不仅仅是为了获取 dump 文件,还可以用于查询 finalize 执行队列、Java 堆和永久带的详细信息,如空间使用率、垃圾回收器等。其运行格式如下:
Jmap [option] vmip
监控堆栈信息主要用来定位问题的原因,生成堆栈快照
.......-dump......: 生成对应的 dump 信息,用法为 -dump:[live,]format=b,file={fileName}
.......-finalizerinfo......: 显示在 F-Queue 中等待的 Finalizer 方法的对象(只在 linux 下生效)
.......-heap......:显示堆的详细信息、垃圾回收器信息、参数配置、分代详情等
.......-histo......:显示堆栈中的对象的统计信息,包含类、实例数量和合计容量
.......-permstat......:以 ClassLoder 为统计口径显示永久带的内存状态
.......-F......:虚拟机对 -dump 无响应时可使用这个选项强制生成 dump 快照
例子:jmap -dump:format=b,file=yhj.dump 20445
5、jstack
Jstack 用于 JVM 当前时刻的线程快照,又称 threaddump 文件,它是 JVM 当前每一条线程正在执行的堆栈信息的集合。生成线程快照的主要目的是为了定位线程出现长时间停顿的原因,如线程死锁、死循环、请求外部时长过长导致线程停顿的原因。通过 jstack 我们就可以知道哪些进程在后台做些什么?在等待什么资源等!其运行格式如下:
Jstack [option] vmid
-F 当正常输出的请求不响应时强制输出线程堆栈
-l 除堆栈信息外,显示关于锁的附加信息
-m 显示 native 方法的堆栈信息
6、jconsole
在 JDK 的 bin 目录下, 监控内存,thread, 堆栈等
7、jprofile
类似于 jconsole, 比 jconsole 监控信息更全面,内存,线程,包,cup 类,堆栈,等等