CPU过载、内存溢出分析

CPU过载、内存溢出问题一般出现在线上项目中，因为开发环境用户量和数据量都很小，即使你的代码有问题也不会爆发出来。线上出现这样的问题是比较严重的，需要认真对待，妥善解决。

问题原因

造成这样问题有两个大类型的原因：
一，性能问题，高并发高访问情况下线程太多，内存不够用；这个时候体现了多线程的一个危害，cpu过载而且可能内存溢出
二，代码问题，如代码中有死循环、一次查询数据量太大、存在太多对象引用内存无法回收（如集合里有大对象没有回收），数据库死锁等。
使用top, free, uptime等命令查看CPU、内存使用情况。 cpu、内存使用率阶段性较高时，是由于某段时间并发量比较高，导致服务器性能出现瓶颈，那么说明你可能需要升级服务器或者横向添加服务器做集群负载了。当CPU、内存使用长时间居高不下，那么很可能是代码出现了问题。需要进一步排查了。

jstack排查cpu使用问题

步骤：
1.top命令找出最高占用的进程（command为java）该命令具体详细介绍看linux load命令

2.查看高负载进程下的高负载线程：top -Hp 【PID】（或 ps -mp PID -o THREAD,tid,time）

3.找出最高占用的线程并记录thread_id，把线程号进行换算成16进制编号：printf ‘0x%x’ thread_id
这里假设存在高占用线程，得到占用cpu最高的线程是：19209
把线程号 19209 进行换算成16进制编号：0x4b09

4.（可选）执行查看高负载的线程名称：jstack 16143【进程】 | grep 3fb6【线程】

jstack命令生成的thread dump信息包含了JVM中所有存活的线程，为了分析指定线程，必须找出对应线程的调用栈，应该如何找？

在top命令中，已经获取到了占用cpu资源较高的线程pid，将该pid转成16进制的值，在thread dump中每个线程都有一个nid，找到对应的nid即可；隔段时间再执行一次stack命令获取thread dump，区分两份dump是否有差别，在nid=0x4b89的线程调用栈中，得到这个信息，就可以检查对应的代码是否有问题。

通过thread dump分析线程状态

除了上述的分析，大多数情况下会基于thead dump分析当前各个线程的运行情况，如是否存在死锁、是否存在一个线程长时间持有锁不放等等。

在dump中，线程一般存在如下几种状态：详细可以看这篇文章线程的几种状态

1、RUNNABLE，线程处于执行中

2、BLOCKED，线程被阻塞

3、WAITING，线程正在等待

实例1：多线程竞争synchronized锁

很明显：线程1获取到锁，处于RUNNABLE状态，线程2处于BLOCK状态

1、locked <0x000000076bf62208>说明线程1对地址为0x000000076bf62208对象进行了加锁；

2、waiting to lock <0x000000076bf62208>说明线程2在等待地址为0x000000076bf62208对象上的锁；

3、waiting for monitor entry [0x000000001e21f000]说明线程1是通过synchronized关键字进入了监视器的临界区，并处于"Entry Set"队列，等待monitor

## 实例2：通过wait挂起线程

static class Task implements Runnable {@Overridepublic void run() {synchronized (lock) {try {lock.wait();//TimeUnit.SECONDS.sleep(100000);} catch (InterruptedException e) {e.printStackTrace();}}}

dump结果

线程1和2都处于WAITING状态

1、线程1和2都是先locked <0x000000076bf62500>，再waiting on <0x000000076bf62500>，之所以先锁再等同一个对象，是因为wait方法需要先通过synchronized获得该地址对象的monitor；

2、waiting on <0x000000076bf62500>说明线程执行了wait方法之后，释放了monitor，进入到"Wait Set"队列，等待其它线程执行地址为0x000000076bf62500对象的notify方法，并唤醒自己

jastat命令

除了线程以外的堆栈信息，我们还可以通过jstat命令查看内存情况

堆内存 = 年轻代 + 永久代 + 元数据区
年轻代 = Eden区 + 两个Survivor区（From和To）

jstat -gc pid 垃圾回收统计

- S0C：第一个幸存区的大小
- S1C：第二个幸存区的大小
- S0U：第一个幸存区的使用大小
- S1U：第二个幸存区的使用大小
- EC：伊甸园区的大小
- EU：伊甸园区的使用大小
- OC：老年代大小
- OU：老年代使用大小
- MC：方法区大小
- MU：方法区使用大小
- CCSC:压缩类空间大小
- CCSU:压缩类空间使用大小
- YGC：年轻代垃圾回收次数
- YGCT：年轻代垃圾回收消耗时间
- FGC：老年代垃圾回收次数
- FGCT：老年代垃圾回收消耗时间
- GCT：垃圾回收消耗总时间

jstat -gcutil pid 总结垃圾回收统计


S0：幸存1区当前使用比例
S1：幸存2区当前使用比例
E：伊甸园区使用比例
O：老年代使用比例
M：元数据区使用比例
CCS：压缩使用比例
YGC：年轻代垃圾回收次数
FGC：老年代垃圾回收次数
FGCT：老年代垃圾回收消耗时间
GCT：垃圾回收消耗总时间

3、jstat -gcnew pid 新生代垃圾回收统计

- S0C：第一个幸存区大小
- S1C：第二个幸存区的大小
- S0U：第一个幸存区的使用大小
- S1U：第二个幸存区的使用大小
- TT:对象在新生代存活的次数
- MTT:对象在新生代存活的最大次数
- DSS:期望的幸存区大小
- EC：伊甸园区的大小
- EU：伊甸园区的使用大小
- YGC：年轻代垃圾回收次数
- YGCT：年轻代垃圾回收消耗时间

暂列以上几个，更多可以参考这篇文章jstat命令详解，
最后，内存的溢出往往和gc回收器知识点相关，参考这篇文章gc回收器