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分析当前各个线程的运行情况，如是否存在死锁、是否存在一个线程长时间持有锁不放等等。
除了上述的分析，大多数情况下会基于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 {
@Override
public 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回收器