JVM tuning

1. Thread dump

[plcm@rm900dev120 source]$ jstack   15000  >jstack.log

输出如下所示：

"GC Daemon" #21 daemon prio=2 os_prio=0 tid=0x00002b62d4aff000 nid=0x3ab2 in Object.wait() [0x00002b6257a3c000]
   java.lang.Thread.State: TIMED_WAITING (on object monitor)
	at java.lang.Object.wait(Native Method)
	- waiting on <0x0000000736932c98> (a sun.misc.GC$LatencyLock)
	at sun.misc.GC$Daemon.run(GC.java:117)
	- locked <0x0000000736932c98> (a sun.misc.GC$LatencyLock)

"RMI Reaper" #20 prio=5 os_prio=0 tid=0x00002b62d4b06800 nid=0x3ab1 in Object.wait() [0x00002b625793b000]
   java.lang.Thread.State: WAITING (on object monitor)
	at java.lang.Object.wait(Native Method)
	- waiting on <0x0000000736827da0> (a java.lang.ref.ReferenceQueue$Lock)
	at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:143)
	- locked <0x0000000736827da0> (a java.lang.ref.ReferenceQueue$Lock)
	at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:164)
	at sun.rmi.transport.ObjectTable$Reaper.run(ObjectTable.java:351)
	at java.lang.Thread.run(Thread.java:745)

"RMI TCP Accept-1098" #19 daemon prio=5 os_prio=0 tid=0x00002b62d4b00000 nid=0x3ab0 runnable [0x00002b625783a000]
   java.lang.Thread.State: RUNNABLE
	at java.net.PlainSocketImpl.socketAccept(Native Method)
	at java.net.AbstractPlainSocketImpl.accept(AbstractPlainSocketImpl.java:404)
	at java.net.ServerSocket.implAccept(ServerSocket.java:545)
	at java.net.ServerSocket.accept(ServerSocket.java:513)
	at sun.rmi.transport.tcp.TCPTransport$AcceptLoop.executeAcceptLoop(TCPTransport.java:400)
	at sun.rmi.transport.tcp.TCPTransport$AcceptLoop.run(TCPTransport.java:372)
	at java.lang.Thread.run(Thread.java:745)

CPU资源高分析：

1. 利用top 查看占用cpu最多的进程id，此例为15000， jstack  15000  >jstack.log  dump
2. 利用shift+h,查找cpu消耗最多的线程，查看线程id，本例中为15632
2. 转为十六进制，本例为：0x3d10
3. thread dump 查询0x3A98

"pool-34-thread-2" #375 prio=5 os_prio=0 tid=0x00002b62a80d2800nid=0x3d10waiting on condition [0x00002b62d3731000]

   java.lang.Thread.State: TIMED_WAITING (parking)
        at sun.misc.Unsafe.park(Native Method)
        - parking to wait for  <0x000000074e192308> (a java.util.concurrent.SynchronousQueue$TransferStack)
        at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
        at java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(SynchronousQueue.java:460)
        at java.util.concurrent.SynchronousQueue$TransferStack.transfer(SynchronousQueue.java:362)
        at java.util.concurrent.SynchronousQueue.poll(SynchronousQueue.java:941)
        at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1066)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
        at java.lang.Thread.run(Thread.java:745)

2.  Heap  dump

jmap 

[plcm@rm900dev120 source]$ jmap  -histo    15000  >memory.log

 num     #instances         #bytes  class name
----------------------------------------------
   1:       2143790      198084744  [C     ------------char
   2:        292525      143541080  [B---------------byte
   3:       1880560       45133440  java.lang.String--------string
   4:       1166136       37316352  java.util.HashMap$Node
   5:        189507       30126952  [I-------------------------------------------------int
   6:        313529       20281016  [Ljava.lang.Object;
   7:        121246       17975240  [Ljava.util.HashMap$Node;
   8:        172402       15171376  java.lang.reflect.Method
   9:        423004       13536128  com.sun.xml.bind.v2.model.impl.RuntimeEnumConstantImpl
  10:        248002        9920080  java.util.LinkedHashMap$Entry
  11:        145898        8170288  java.util.LinkedHashMap
  12:        111994        8063568  com.sun.org.apache.xerces.internal.dom.DeferredElementNSImpl
  13:        192391        7695640  java.util.TreeMap$Entry
  14:        144750        6948000  com.sun.org.apache.xerces.internal.dom.DeferredAttrNSImpl
  15:        137345        6592560  java.util.HashMap
  16:        226016        5424384  org.aspectj.apache.bcel.classfile.ConstantUtf8
  17:        132554        5302160  com.sun.org.apache.xerces.internal.dom.DeferredTextImpl
  18:        205687        4936488  java.util.ArrayList
  19:        143273        4584736  java.util.concurrent.ConcurrentHashMap$Node
  20:         47109        4522464  java.util.jar.JarFile$JarFileEntry
  21:         46872        4499712  sun.util.calendar.Gregorian$Date
  22:         46574        3725920  java.util.zip.ZipEntry
  23:         30538        3415024  java.lang.Class
  24:         82186        2908976  [Ljava.lang.String;

其中关于I、B、C等的说明如下 Table 4.2.

BaseType Character	Type	Interpretation
B	byte	signed byte
C	char	Unicode character
D	double	double-precision floating-point value
F	float	single-precision floating-point value
I	int	integer
J	long	long integer
L<classname>;	reference	an instance of class de><classname>de>
S	short	signed short
Z	boolean	de>truede> or de>falsede>
[	reference	one array dimension

[plcm@rm900dev120 source]$ jmap -dump:format=b,file=test.bin  15000
Dumping heap to /home/plcm/se200/trunk/source/source/test.bin ...
Heap dump file created

[plcm@rm900dev120 source]$ jhat -J-mx768m -port 7000  test.bin 
OpenJDK 64-Bit Server VM warning: Insufficient space for shared memory file:
   27832
Try using the -Djava.io.tmpdir= option to select an alternate temp location.

产生的二进制文件 很大， 通过jhat解析，分析后者用MAT

可以输出所有内存中对象的工具，甚至可以将VM 中的heap，以二进制输出成文本。使用方法 jmap -histo pid。如果连用SHELL jmap -histo pid>a.log可以将其保存到文本中去，在一段时间后，使用文本对比工具，可以对比出GC回收了哪些对象。jmap -dump:format=b,file= outfile  3024可以将3024进程的内存heap输出出来到 outfile 文件里 ，再配合 MAT（内存分析工具(Memory Analysis Tool），使用参见： http://blog.csdn.net/fenglibing/archive/2011/04/02/6298326.asp x）或与jhat (Java Heap Analysis Tool)一起使用，能够以图像的形式直观的展示当前内存是否有问题。

Reading from test.bin...
Dump file created Thu Mar 31 16:14:24 CST 2016