1.先找进程
ps -ef|grep tomcat
root 2303 1 33 18:57 pts/2
2.在找负载高的pid
top -Hp 2303
(按CPU排序，找到对应的PID即是CPU占用最多的线程，
在Java中可以使用jstack将该线程的堆栈打印出来，使用这个线程ID查找对应的线程堆栈（要先将线程ID转换成16进制）)
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
2474 root 15 0 1134m 904m 18m S 0.3 46.3 0:02.91 java
2303 root 18 0 1134m 904m 18m S 0.0 46.3 0:00.00 java
2304 root 22 0 1134m 904m 18m S 0.0 46.3 0:01.08 java
2306 root 16 0 1134m 904m 18m S 0.0 46.3 1:54.37 java
3.
printf "%x\n" 2474
得到2474的十六进制值
4.查到代码（jstack显示虚拟机的线程快照）
jstack 2303 | grep 9aa -A 10 (-A显示之后的10行)
5.使用jstat -gcutil命令查看进程的内存情况（jstat 用于收集HotSpot虚拟机各方面的运行数据）
jstat -gcutil 2303 2000 10
每个2s输出一次，输出10次
各个字段的介绍：
S0、S1 代表两个Survivor区；
E 代表 Eden 区；
O（Old）代表老年代；
P（Permanent）代表永久代；
YGC（Young GC）代表Minor GC；
YGCT代表Minor GC耗时；
FGC（Full GC）代表Full GC耗时；
GCT代表Minor & Full GC共计耗时
具体描述
S0年轻代中第一个survivor（幸存区）已使用的占当前容量百分比
S1年轻代中第二个survivor（幸存区）已使用的占当前容量百分比
E年轻代中Eden（伊甸园）已使用的占当前容量百分比
O old代已使用的占当前容量百分比
P perm代已使用的占当前容量百分比
YGC从应用程序启动到采样时年轻代中gc次数
YGCT从应用程序启动到采样时年轻代中gc所用时间(s)
FGC从应用程序启动到采样时old代(全gc)gc次数
FGCT从应用程序启动到采样时old代(全gc)gc所用时间(s)
GCT从应用程序启动到采样时gc用的总时间(s)
解释java堆分：
Java 堆分为新生代和老年代，新生代一般划分为三块区域，Eden + From Survivor + To Survivor，Eden 和 Survivor 的内存比为8:1，每次只使用一个Eden和一个 Survivor 区域，另一个Survivor 用于复制收集算法回收内存。
对象一般尽量分配到新生代中，而对于大对象（长字符串和大数组）直接分配在老年代中，同时“年龄”长的的对象会从新生代自动晋升到老年代中。
Java 方法区称为永久代，只有 HotSpot 虚拟机才存在永久代。
首先想eden区申请分配空间，如果空间够，就直接进行分配，否则进行一次Minor GC。minor GC 首先会对Eden区的对象进行标记，标记出来存活的对象。然后把存活的对象copy到From空间。如果From空间足够，则回收eden区可回收的对象。如果from内存空间不够，则把From空间存活的对象复制到To区，如果TO区的内存空间也不够的话，则把To区存活的对象复制到老年代。如果老年代空间也不够（或者达到触发老年年垃圾回收条件的话）则触发一次full GC。
6.分析堆栈：
使用jstack命令查看进程的堆栈情况
jstack 14063 >>jstack.out
查找先关信息：把jstack.out文件从服务器拿到本地后，用编辑器查找带有项目目录并且线程状态是RUNABLE的相关信息。
找到相应的代码，并对它进行分析。找出造成这样的原因
网友评论