JVM Tuning

Tools 

uptime : monitor system load.
top : monitor system IO , cpu, processes , memory.
vmstat | 4 : calculate cpu, io, memory , thread switch frequency.
pidstat  : detailed thread inspector, need install.
      -t  // show threads       -p // specify the thread name      -u // monitor CPU , fetch each second

perfmon : In windows system, monitor each thread
process explorer : very powerfull tool than above
jps: list all jave related processes, -m -q -l -v
jmap: generate java stack snapshot statistics information eg:
           jmap -histo 2972 > C:/export.txt
           jmap -dump:format=b file=C:\heap.hprod 2972 // export head infor

jstack: Print thread infor, eg : jstack 120 >> C:\log.txt  -l  // print lock  -m // print pointer infor  -F // force

JConsole : A Graphic monitor tool , if you want to use this , please name your thread in application so that can differentiate them in JConsole
Visual VM : // open source Graphic monitor tool , more beautiful than JConsole and has some plugins to use as well

Tuning technique

JVM memory : heap + Perm Size + thread stack + direct memory
Heap overflow : increase Xms size or increase memory release frequency
Perm Size overflow : too many classes loaded in jvm, eg : cglib produce tons of classes and the metainfor of classes are stored in perm gen , so perm size overflow. so increase the permSize or set it to allow to  recycle class metainfor.

Java stack overflow:  heap size + stack size = thread  size < total size . so decrease the heap size.
direct memory overflow: ByteBuffer.allocateDirect(1024*1024).  so decrease heap size to trigger GC

MAT(Memory Analyzer) : a software to analyse the memory dump, so you can either analyse GC on some online dump analyzers or use this to analyse .

JMeter : a software to do loading test. for instance, if  MAT find a ConcurrentHashMap occupies a big memory , probably because of storing lots of sessions leading Tomcat OOM. Tomcat default session expiration is 20 minutes. so Using jmeter can detect this problem early before it goes into production.
Solution : increase heap size , turn down session exipiration time.

Shallow heap : Object structure size , eg : String has 24 bytes . this doesn't change forever.
Deep heap: Object real memory occupation size . this is changing .

Calculte application concurrency pressure: JQL can retrive the session list, eg :
                              select s.creationTime from session order by time; 
(the last session - the 1st session) = session lasting miliseconds 
(the last session - 1st session)/1000 = session lasting seconds
number of visit / (the last session - 1st session)/1000 = concurrency 

eg : 9941 / (（14646646464-143473747374）/ 1000) = 320 requests per second

please leave msg , if anything not clear