今天这篇文章来粗略整理一下Java系统可能碰到的问题，并给出相应的解决方案建议。如果各位看官有更好的方案，欢迎尽情评论。

线上故障主要包括 CPU、磁盘、内存以及网络问题，而大多数故障可能会包含不止一个层面的问题，所以进行排查时候尽量四个方面依次排查一遍。

1.CPU异常

一般情况包括三种情况：

• 业务逻辑问题（死循环）
• 频繁GC
• 上下文切换过多

1.1 CPU过高的排查思路

一般步骤如下：

• 1）使用命令top -p <pid> ，显示你的java进程的内存情况，pid是你的java进程号，比如19663
• 2）执行top -p pid查看该进程的信息，按H查看线程信息。（top -H -p pid来找到 CPU 使用率比较高的一些线程）
• 3）找到CPU占用最高的线程编号，并将线程编号转为16进制。
• 4）执行jstack 16进制线程id是否能找到该线程的堆栈信息。
• 5）或者用可视化工具查看该线程的堆栈信息和异常的方法代码提示。

1.2 分析是不是频繁GC问题

可以使用jstat命令行工具或者使用MAT等工具进行分析。

用 jstat gc -pid 命令可以计算出如下一些关键数据，有了这些数据就可以采用之前介绍过的优化思路，先给自己的系统设置一些初始性的JVM参数，比如堆内存大小，年轻代大小，Eden和Survivor的比例，老年代的大小，大对象的阈值，大龄对象进入老年代的阈值等。

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

1.2.1 年轻代对象增长的速率

可以执行命令 jstat -gc pid 1000 10 (每隔1秒执行1次命令，共执行10次)，通过观察EU(eden区的使用)来估算每秒eden大概新增多少对象，如果系统负载不高，可以把频率1秒换成1分钟，甚至10分钟来观察整体情况。注意，一般系统可能有高峰期和日常期，所以需要在不同的时间分别估算不同情况下对象增长速率。

1.2.2 Young GC的触发频率和每次耗时

知道年轻代对象增长速率我们就能推根据eden区的大小推算出Young GC大概多久触发一次，Young GC的平均耗时可以通过 YGCT/YGC 公式算出，根据结果我们大概就能知道系统大概多久会因为Young GC的执行而卡顿多久。

1.2.3 每次Young GC后有多少对象存活和进入老年代

这个因为之前已经大概知道Young GC的频率，假设是每5分钟一次，那么可以执行命令 jstat -gc pid 300000 10 ，观察每次结果eden，survivor和老年代使用的变化情况，在每次gc后eden区使用一般会大幅减少，survivor和老年代都有可能增长，这些增长的对象就是每次Young GC后存活的对象，同时还可以看出每次Young GC后进去老年代大概多少对象，从而可以推算出老年代对象增长速率。

1.2.4 Full GC的触发频率和每次耗时

知道了老年代对象的增长速率就可以推算出Full GC的触发频率了，Full GC的每次耗时可以用公式 FGCT/FGC 计算得出。

1.2.5 优化思路

其实简单来说就是尽量让每次Young GC后的存活对象小于Survivor区域的50%，都留存在年轻代里。尽量别让对象进入老年代。尽量减少Full GC的频率，避免频繁Full GC对JVM性能的影响。

1.3 上下文切换排查

可以使用 vmstat 命令。

2.磁盘

2.1 磁盘空间

使用 df -hl 来查看文件系统状态。

2.2 磁盘性能

通过 iostatiostat -d -k -x 来进行分析。

看读写速度，一般就能帮助定位到具体哪块磁盘出现问题了。

还需要知道是哪个进程在进行读写，用 iotop 命令来进行定位文件读写的来源。

3.内存

主要包括 OOM、GC 问题和堆外内存。

3.1 OOM

3.1.1 Java 栈OOM

解决方案：

• 首先从代码层面来寻找问题，使用 jstack 或者 jmap。
• 如果一切都正常，JVM 方面可以通过指定 Xss 来减少单个 thread stack 的大小。
• 另外也可以在系统层面，可以通过修改 /etc/security/limits.confnofile 和 nproc 来增大 os 对线程的限制。

3.1.2 堆OOM

解决方案：

• 先应该在代码中找，怀疑存在内存泄漏，通过 jstack 和 jmap 去定位问题。
• 如果说一切都正常，才需要通过调整 Xmx 的值来扩大内存。

如何发现内存泄漏？

• 堆内内存泄漏总是和 GC 异常相伴。不过 GC 问题不只是和内存问题相关，还有可能引起 CPU 负载、网络问题等系列并发症，只是相对来说和内存联系紧密些。
• 如果观察一个系统，每次进行 FullGC 发现堆空间回收的比例比较小，尤其是老年代，同时对象越来越多，这个时候可 以判断是有可能发生内存泄漏.

如何排查？

• 1）使用jps查看虚拟机进程；
• 2）使用jstat -gcutil [pid] [interval]命令查看gc回收情况；
• 3）使用轻量级在线分析工具 jmap-histo:live [pid] 查看和定位信息；
• 4）若无法定位则使用 jmap -dump:live,format=b,file=heap.hprof [pid] 生成转储快照使用 MAT等工具进行离线分析，定位问题。

通过 mat（Eclipse Memory Analysis Tools）导入 dump 文件进行分析，内存泄漏问题一般我们直接选 Leak Suspects 即可，mat 给出了内存泄漏的建议。

另外也可以选择 Top Consumers 来查看最大对象报告。和线程相关的问题可以选择 thread overview 进行分析。

日常开发中，代码产生内存泄漏是比较常见的事，并且比较隐蔽，需要开发者更加关注细节。

比如说每次请求都 new 对象，导致大量重复创建对象；进行文件流操作但未正确关闭；手动不当触发 GC；ByteBuffer 缓存分配不合理等都会造成代码 OOM。

另一方面，我们可以在启动参数中指定 -XX:+HeapDumpOnOutOfMemoryError 来保存 OOM 时的 dump 文件。

3.1.3 元数据区OOM

解决方案：

• 首先从代码层面来寻找问题
• 如果说一切都正常，参数方面可以通过 XX:MaxPermSize 来进行调整

3.2 GC问题

GC 问题除了影响 CPU 也会影响内存，排查思路也是一致的。一般先使用 jstat 来查看分代变化情况，比如 youngGC 或者 FullGC 次数是不是太多呀；EU、OU 等指标增长是不是异常呀等。

参考上面的1.2 分析是不是频繁GC问题

3.2.1 着重看一下FullGC问题

什么情况下会发生Full GC?

（1）System.gc()方法的调用
此方法的调用是建议JVM进行Full GC,虽然只是建议而非一定，但很多情况下它会触发 Full GC,从而增加Full GC的频率，也即增加了间歇性停顿的次数。强烈影响系建议能不使用此方法就别使用，让虚拟机自己去管理它的内存，可通过通过-XX:+ DisableExplicitGC来禁止RMI（Java远程方法调用）调用System.gc。

（2）老年代空间不足
在Survivor区域的对象满足晋升到老年代的条件时，晋升进入老年代的对象大小大于老年代的可用内存，这个时候会触发Full GC。，当执行Full GC后空间仍然不足，则抛出错误：java.lang.OutOfMemoryError: Java heap space 。为避免以上两种状况引起的FullGC，调优时应尽量做到让对象在Minor GC阶段被回收、让对象在新生代多存活一段时间及不要创建过大的对象及数组。

（3）Metaspace区内存达到阈值
从JDK8开始，永久代(PermGen)的概念被废弃掉了，取而代之的是一个称为Metaspace的存储空间。Metaspace使用的是本地内存，而不是堆内存，也就是说在默认情况下Metaspace的大小只与本地内存大小有关。-XX:MetaspaceSize=21810376B（约为20.8MB）超过这个值就会引发Full GC，这个值不是固定的，是会随着JVM的运行进行动态调整的，与此相关的参数还有多个，详细情况请参考这篇文章jdk8 Metaspace 调优

（4）统计得到的Minor GC晋升到旧生代的平均大小大于老年代的剩余空间 Survivor区域对象晋升到老年代有两种情况：
一种是给每个对象定义一个对象计数器，如果对象在Eden区域出生，并且经过了第一次GC，那么就将他的年龄设置为1，在Survivor区域的对象每熬过一次GC，年龄计数器加一，等到到达默认值15时，就会被移动到老年代中，默认值可以通过-XX:MaxTenuringThreshold来设置。
另外一种情况是如果JVM发现Survivor区域中的相同年龄的对象占到所有对象的一半以上时，就会将大于这个年龄的对象移动到老年代，在这批对象在统计后发现可以晋升到老年代，但是发现老年代没有足够的空间来放置这些对象，这就会引起Full GC。

（5）堆中产生大对象超过阈值
这个参数可以通过-XX:PretenureSizeThreshold进行设定，大对象或者长期存活的对象进入老年代，典型的大对象就是很长的字符串或者数组，它们在被创建后会直接进入老年代，虽然可能新生代中的Eden区域可以放置这个对象，在要放置的时候JVM如果发现老年代的空间不足时，会触发GC。

（6）老年代连续空间不足
JVM如果判断老年代没有做足够的连续空间来放置大对象，那么就会引起Full GC，例如老年代可用空间大小为200K，但不是连续的，连续内存只要100K，而晋升到老年代的对象大小为120K，由于120＞100的连续空间，所以就会触发Full GC。

（7）CMS GC时出现promotion failed和concurrent mode failure
提升失败（promotion failed），在 Minor GC 过程中，Survivor Unused 可能不足以容纳 Eden 和另一个 Survivor 中的存活对象， 那么多余的将被移到老年代， 称为过早提升（Premature Promotion）。这会导致老年代中短期存活对象的增长， 可能会引发严重的性能问题。 再进一步， 如果老年代满了， Minor GC 后会进行 Full GC， 这将导致遍历整个堆， 称为提升失败（Promotion Failure）。
在 CMS 启动过程中，新生代提升速度过快，老年代收集速度赶不上新生代提升速度。在 CMS 启动过程中，老年代碎片化严重，无法容纳新生代提升上来的大对象，这是因为CMS采用标记清理，会产生连续空间不足的情况，这也是CMS的缺点。

3.3 堆外内存

首先堆外内存溢出表现就是物理常驻内存增长快，报错的话视使用方式都不确定。

如果由于使用 Netty 导致的，那错误日志里可能会出现 OutOfDirectMemoryError 错误，如果直接是 DirectByteBuffer，那会报 OutOfMemoryError: Direct buffer memory。

堆外内存溢出往往是和 NIO 的使用相关，一般我们先通过 pmap 来查看下进程占用的内存情况 pmap -x pid | sort -rn -k3 | head -30，这段意思是查看对应 pid 倒序前 30 大的内存段。

这边可以再一段时间后再跑一次命令看看内存增长情况，或者和正常机器比较可疑的内存段在哪里。

4.网络

4.1 超时

4.2 TCP 队列溢出

5.形成死锁的条件以及如何排查死锁

死锁产生的四个必要条件

• 1）互斥使用，即当资源被一个线程使用(占有)时，别的线程不能使用
• 2）不可抢占，资源请求者不能强制从资源占有者手中夺取资源，资源只能由资源占有者主动释放。
• 3）请求和保持，即当资源请求者在请求其他的资源的同时保持对原有资源的占有。
• 4）循环等待，即存在一个等待队列：P1占有P2的资源，P2占有P3的资源，P3占有P1的资源。这样就形成了一个等待环路。

如何排查死锁

• jstack加进程id查找死锁
• Arthas thread -b 可以查看线程死锁
• jvisualvm可视化工具自动检测死锁