linux进程和线程排查 · 记一次JVM CPU高负载的排查办法
前言
查看所有进程信息 top -H
轻量级进程（LWP）
实验观察
操作总结
htop
查看进程下的线程信息
两种命令
ps -Lf pid
pstree -p 22564
ps命令详解
ps –e | grep java
ps –o nlwp 27989
获取真正在running的线程
JVM CPU高负载的排查办法
前言
通过本文，你将学会：
1、linux上进程及进程中线程排查的基本方法，如查看进程中的线程数
此文中的线程一般指轻量级进程。
查看所有进程信息 top -H
加上-H这个选项启动top，top一行显示一个线程（指的是（轻量级）进程？ ）。否则，它一行显示一个进程。
先输入top -p 20378 只显示该进程的变化情况 ，但是在按H（shift + h）后，会显示threads的信息，但是总的CPU占用之和远小于没按H之前的占用之和。
轻量级进程（LWP）
轻量级进程（LWP）是一种实现多任务的方法。与普通进程相比，LWP与其他进程共享所有（或大部分）它的逻辑地址空间和系统资源；与 线程相比，LWP有它自己的进程标识符，优先级，状态，以及栈和局部存储区，并和其他进程有着父子关系。
后文中的LWP粗略认为是线程。LWP的一个重要作用是提供了一个用户级线程实现的中间系统。LWP可以通过系统调用获得内核提供的服务，因此，当一个用户级线程运行时，只需要将它连接到一个LWP上便可以具有内核支持线程的所有属性。
实验观察
某个时刻下的截图
个别时间下出现CPU占用1000%，出现次数几乎可以忽略。
操作总结
一般通过top -H定位想要具体分析的Java进程对应的PID，此处为22564。
htop
install htop 一个比top更强大的命令，支持点击 %CPU %MEM后进行排序
查看进程下的线程信息
两种命令
ps -Lf pid 查看对应进程下的线程信息
pstree -p 22564 通过进程PID查看进程下线程的PID
上面两个命令的缺点： 没有线程占用资源的信息
ps -Lf pid
通过ps -Lf pid 查看对应进程下的线程信息 ，查到pid 22564下有1个进程（自身）+48个线程，如下图所示：
上图是截图左半部分
上图是截图右半部分
pstree -p 22564
pstree -p 22564 通过进程PID查看进程下线程的PID
ps命令详解
ps –e | grep java
ps命令可以查看进程状态，如执行如下命令：
ps –e | grep java
结果如下图：
可以看到，只打印了一个进程的信息；27989是线程id，java是指执行的java命令。这是因为启动一个tomcat，内部所有的工作都在这一个进程里完成，包括主线程、垃圾回收线程、Acceptor线程、请求处理线程等等。
ps –o nlwp 27989
通过
ps –o nlwp 27989
命令，可以看到该进程内有多少个线程；其中，nlwp含义是number of light-weight process。
获取真正在running的线程
可以看到，该进程内部有73个线程；但是73并没有排除处于idle状态的线程。要想获得真正在running的线程数量，可以通过以下语句完成：
ps -eLo pid ,stat | grep 27989 | grep running | wc -l
其中ps -eLo pid ,stat可以找出所有线程，并打印其所在的进程号和线程当前的状态；两个grep命令分别筛选进程号和线程状态；wc统计个数。其中，ps -eLo pid ,stat | grep 27989输出的结果如下：
图中只截图了部分结果；
Sl表
示大多数线程都处于空闲状态。
JVM CPU高负载的排查办法
今天线上一个java进程cpu负载100%。按以下步骤查出原因。
1.执行top -c命令，找到cpu最高的进程的id
2.执行top -H -p pid，这个命令就能显示刚刚找到的进程的所有线程的资源消耗情况。找到CPU负载高的线程pid 8627, 把这个数字转换成16进制，21B3（10进制转16进制，用linux命令: printf %x 8627）。
3.执行jstack -l pid，拿到进程的线程dump文件。这个命令会打出这个进程的所有线程的运行堆栈。
4.用记事本打开这个文件，搜索“21B3”，就是搜一下16进制显示的线程id。搜到后，下面的堆栈就是这个线程打出来的。排查问题从这里深入。
今天最后排查出来的结果是“VM THREAD”把进程的资源耗尽。那只能说明是jvm在耗cpu。很容易想到是疯狂的GC，按关键字 “overhead” 搜一下系统日志， 发现 “java.lang.OutOfMemoryError: GC overhead limit exceeded”日志。问题明了了。jvm在疯狂的Full GC，而且有个大对象始终根节点路径可达，无法释放。dump了一下这个实例的内存，发现确实有大对象，占用了一个多G的堆内存。