对于后端程序员，特别是 Java 程序员来讲，排查线上问题是不可避免的。各种 CPU 飚高，内存溢出，频繁 GC 等等，这些都是令人头疼的问题。楼主同样也遇到过这些问题，那么，遇到这些问题该如何解决呢？

首先，出现问题，肯定要先定位问题所在，然后分析问题原因，再然后解决问题，最后进行总结，防止下次再次出现。

预备知识

top命令

top命令使我们最常用的Linux命令之一，它可以实时的显示当前正在执行的进程的CPU使用率，内存使用率等系统信息。top -Hp pid 可以查看线程的系统资源使用情况。

top命令各数据含义

jstack命令

jstack是JDK工具命令，它是一种线程堆栈分析工具，最常用的功能就是使用 jstack pid 命令查看线程的堆栈信息，也经常用来排除死锁情况。

jstat -gc 12538 5000

即会每5秒一次显示进程号为12538的java进成的GC情况，

mat内存工具

MAT(Memory Analyzer Tool)工具是eclipse的一个插件(MAT也可以单独使用)，它分析大内存的dump文件时，可以非常直观的看到各个对象在堆空间中所占用的内存大小、类实例数量、对象引用关系、利用OQL对象查询，以及可以很方便的找出对象GC Roots的相关信息。

常见问题

1.CPU 飚高

思路：首先找到 CPU 飚高的那个 Java 进程，因为你的服务器会有多个 JVM 进程。然后找到那个进程中的 “问题线程”，最后根据线程堆栈信息找到问题代码。最后对代码进行排查。

操作步骤：

  1. 通过 top 命令找到 CPU 消耗最高的进程，并记住进程 ID。
  2. 再次通过 top -Hp [进程 ID] 找到 CPU 消耗最高的线程 ID，并记住线程 ID.
  3. 通过 JDK 提供的 jstack 工具 dump 线程堆栈信息到指定文件中。具体命令：jstack -l [进程 ID] >>jstack.log。
  4. 由于刚刚的线程 ID 是十进制的，而堆栈信息中的线程 ID 是16进制的，因此我们需要将10进制的转换成16进制的，并用这个线程 ID 在堆栈中查找。使用 printf “%x\n” [十进制数字] ，可以将10进制转换成16进制。
  5. 通过刚刚转换的16进制数字从堆栈信息里找到对应的线程堆栈。就可以从该堆栈中看出端倪。

从楼主的经验来看，一般是某个业务死循环没有出口，这种情况可以根据业务进行修复。还有 C2 编译器执行编译时也会抢占 CPU，什么是 C2编译器呢？当 Java 某一段代码执行次数超过10000次（默认）后，就会将该段代码从解释执行改为编译执行，也就是编译成机器码以提高速度。而这个 C2编译器就是做这个的。如何解决呢？项目上线后，可以先通过压测工具进行预热，这样，等用户真正访问的时候，C2编译器就不会干扰应用程序了。如果是 GC 线程导致的，那么极有可能是 Full GC ，那么就要进行 GC 的优化。

2.内存溢出

Java 的内存由 GC 管理。有2种情况，一种是内存溢出了，一种是内存没有溢出，但 GC 不健康。

内存溢出

内存溢出的情况可以通过加上 -XX:+HeapDumpOnOutOfMemoryError 参数（在tomcat的bin目录下的catalina.sh文件JAVA_OPTIONS变量中增加），该参数作用是：在程序内存溢出时输出 dump 文件。

有了 dump 文件，就可以通过 dump 分析工具进行分析了，比如常用的MAT，Jprofile，jvisualvm 等工具都可以分析，这些工具都能够看出到底是哪里溢出，哪里创建了大量的对象等等信息。

GC 的健康问题

经验：YGC 5秒一次左右，每次不超过50毫秒，FGC 最好没有，CMS GC 一天一次左右。

而 GC 的优化有2个维度，一是频率，二是时长。

YGC优化

我们看YGC，首先看频率，如果 YGC 超过5秒一次，甚至更长，说明系统内存过大，应该缩小容量，如果频率很高，说明 Eden 区过小，可以将 Eden 区增大，但整个新生代的容量应该在堆的 30% - 40%之间，eden，from 和 to 的比例应该在 8：1：1左右，这个比例可根据对象晋升的大小进行调整。

如果 YGC 时间过长呢？YGC 有2个过程，一个是扫描，一个是复制，通常扫描速度很快，复制速度相比而言要慢一些，如果每次都有大量对象要复制，就会将 STW 时间延长，还有一个情况就是 StringTable ，这个数据结构中存储着 String.intern 方法返回的常连池的引用，YGC 每次都会扫描这个数据结构（HashTable），如果这个数据结构很大，且没有经过 FGC，那么也会拉长 STW 时长，还有一种情况就是操作系统的虚拟内存，当 GC 时正巧操作系统正在交换内存，也会拉长 STW 时长。

FGC优化

再来看看FGC，实际上，FGC 我们只能优化频率，无法优化时长，因为这个时长无法控制。如何优化频率呢？

首先，FGC 的原因有几个

  1. 是 Old 区内存不够
  2. 是元数据区内存不够
  3. 是 System.gc()
  4. 是 jmap 或者 jcmd
  5. 是CMS Promotion failed 或者 concurrent mode failure
  6. JVM 基于悲观策略认为这次 YGC 后 Old 区无法容纳晋升的对象，因此取消 YGC，提前 FGC。

通常优化的点是 Old 区内存不够导致 FGC。如果 FGC 后还有大量对象，说明 Old 区过小，应该扩大 Old 区，如果 FGC 后效果很好，说明 Old 区存在了大量短命的对象，优化的点应该是让这些对象在新生代就被 YGC 掉，通常的做法是增大新生代，如果有大而短命的对象，通过参数设置对象的大小，不要让这些对象进入 Old 区，还需要检查晋升年龄是否过小。如果 YGC 后，有大量对象因为无法进入 Survivor 区从而提前晋升，这时应该增大 Survivor 区，但不宜太大。

3.死锁

死锁会导致耗尽线程资源，占用内存，表现就是内存占用升高，CPU不一定会飙升(看场景决定)，如果是直接new线程，会导致JVM内存被耗尽，报无法创建线程的错误，这也是体现了使用线程池的好处。

  1. 通过ps -ef|grep java命令找出 Java 进程 pid
  2. 执行jstack pid 即可出现java线程堆栈信息，找到死锁信息
常见问题

线上机器的一个进程用kill命令杀不死该怎么办？

  1. ps aux，看看STAT那一栏，如果是Z，那么就是zombie状态的僵尸进程
  2. ps -ef | grep 僵尸进程id，可以找到父进程id
  3. kill父进程

服务器存储空间快满了（95%），还有一个小时存储就满了，在不影响服务正常运行的情况下，该如何解决？

  1. df -h，先看看磁盘使用的情况
  2. find / -size +100M |xargs ls -lh，找找大于100m的文件 或 du -h >fs_du.log，看看各个目录占用的磁盘空间大小，看看是不是哪个目录有大量的小文件

设置系统启动参数

java -Xms1024m -Xmx1024m -jar app.jar