内存问题排查方案

Hi，我是阿昌，今天学习记录的是关于内存问题排查方案。

碰到内存持续上升的情况，其实很难从业务日志中查看到具体的问题，那么面对多个进程以及大量业务线程，该如何精准地找到背后的原因呢？

一、常用的监控和诊断内存工具

工欲善其事，必先利其器。平时排查内存性能瓶颈时，往往需要用到一些 Linux 命令行或者 JDK 工具来辅助监测系统或者虚拟机内存的使用情况，下面介绍几种好用且常用的工具。

1、top 命令

top 命令是我们在 Linux 下最常用的命令之一，它可以实时显示正在执行进程的 CPU 使用率、内存使用率以及系统负载等信息。

其中上半部分显示的是系统的统计信息，下半部分显示的是进程的使用率统计信息。

在这里插入图片描述

除了简单的 top 之外，还可以通过top -Hp pid查看具体线程使用系统资源情况：

在这里插入图片描述

2、vmstat 命令

vmstat 是一款指定采样周期和次数的功能性监测工具，可以看到，它不仅可以统计内存的使用情况，还可以观测到 CPU 的使用率、swap 的使用情况。

但 vmstat 一般很少用来查看内存的使用情况，而是经常被用来观察进程的上下文切换。

在这里插入图片描述

r：等待运行的进程数；
b：处于非中断睡眠状态的进程数；
swpd：虚拟内存使用情况；
free：空闲的内存；
buff：用来作为缓冲的内存数；
si：从磁盘交换到内存的交换页数量；
so：从内存交换到磁盘的交换页数量；
bi：发送到块设备的块数；
bo：从块设备接收到的块数；
in：每秒中断数；
cs：每秒上下文切换次数；
us：用户 CPU 使用时间；
sy：内核 CPU 系统使用时间；
id：空闲时间；
wa：等待 I/O 时间；
st：运行虚拟机窃取的时间。

3、pidstat 命令

pidstat 是 Sysstat 中的一个组件，也是一款功能强大的性能监测工具，可以通过命令：yum install sysstat 安装该监控组件。

之前的 top 和 vmstat 两个命令都是监测进程的内存、CPU 以及 I/O 使用情况，而 pidstat 命令则是深入到线程级别。

通过 pidstat -help 命令，可以查看到有以下几个常用的参数来监测线程的性能：

在这里插入图片描述
常用参数：

-u：默认的参数，显示各个进程的 cpu 使用情况；
-r：显示各个进程的内存使用情况；
-d：显示各个进程的 I/O 使用情况；
-w：显示每个进程的上下文切换情况；
-p：指定进程号；
-t：显示进程中线程的统计信息。

可以通过相关命令（例如 ps 或 jps）查询到相关进程 ID，再运行以下命令来监测该进程的内存使用情况：

在这里插入图片描述

其中 pidstat 的参数 -p 用于指定进程 ID，-r 表示监控内存的使用情况，1 表示每秒的意思，3 则表示采样次数。

其中显示的几个关键指标的含义是：

Minflt/s：任务每秒发生的次要错误，不需要从磁盘中加载页；
Majflt/s：任务每秒发生的主要错误，需要从磁盘中加载页；
VSZ：虚拟地址大小，虚拟内存使用 KB；
RSS：常驻集合大小，非交换区内存使用 KB。

如果我们需要继续查看该进程下的线程内存使用率，则在后面添加 -t 指令即可：

在这里插入图片描述
Java 是基于 JVM 上运行的，大部分内存都是在 JVM 的用户内存中创建的，所以除了通过以上 Linux 命令来监控整个服务器内存的使用情况之外，更需要知道 JVM 中的内存使用情况。

JDK 中就自带了很多命令工具可以监测到 JVM 的内存分配以及使用情况。

4、jstat 命令

jstat 可以监测 Java 应用程序的实时运行情况，包括堆内存信息以及垃圾回收信息。

可以运行 jstat -help 查看一些关键参数信息：

在这里插入图片描述
再通过 jstat -option 查看 jstat 有哪些操作：

在这里插入图片描述

-class：显示 ClassLoad 的相关信息；
-compiler：显示 JIT 编译的相关信息；
-gc：显示和 gc 相关的堆信息；
-gccapacity：显示各个代的容量以及使用情况；
-gcmetacapacity：显示 Metaspace 的大小；
-gcnew：显示新生代信息；
-gcnewcapacity：显示新生代大小和使用情况；
-gcold：显示老年代和永久代的信息；
-gcoldcapacity ：显示老年代的大小；
-gcutil：显示垃圾收集信息；
-gccause：显示垃圾回收的相关信息（通 -gcutil），同时显示最后一次或当前正在发生的垃圾回收的诱因；
-printcompilation：输出 JIT 编译的方法信息。

它的功能比较多，在这里例举一个常用功能，如何使用 jstat 查看堆内存的使用情况。

可以用 jstat -gc pid 查看：

在这里插入图片描述

S0C：年轻代中 To Survivor 的容量（单位 KB）；
S1C：年轻代中 From Survivor 的容量（单位 KB）；
S0U：年轻代中 To Survivor 目前已使用空间（单位 KB）；
S1U：年轻代中 From Survivor 目前已使用空间（单位 KB）；
EC：年轻代中 Eden 的容量（单位 KB）；
EU：年轻代中 Eden 目前已使用空间（单位 KB）；
OC：Old 代的容量（单位 KB）；
OU：Old 代目前已使用空间（单位 KB）；
MC：Metaspace 的容量（单位 KB）；
MU：Metaspace 目前已使用空间（单位 KB）；
YGC：从应用程序启动到采样时年轻代中 gc 次数；
YGCT：从应用程序启动到采样时年轻代中 gc 所用时间 (s)；
FGC：从应用程序启动到采样时 old 代（全 gc）gc 次数；
FGCT：从应用程序启动到采样时 old 代（全 gc）gc 所用时间 (s)；
GCT：从应用程序启动到采样时 gc 用的总时间 (s)。

5、jstack 命令

监测上下文切换异常的命令排查工具&BlockingQueue中，它是一种线程堆栈分析工具，最常用的功能就是使用 jstack pid 命令查看线程的堆栈信息，通常会结合 top -Hp pid 或 pidstat -p pid -t 一起查看具体线程的状态，也经常用来排查一些死锁的异常。

在这里插入图片描述
每个线程堆栈的信息中，都可以查看到线程 ID、线程的状态（wait、sleep、running 等状态）以及是否持有锁等。

6、jmap 命令

在JVM内存分配优化中使用过 jmap 查看堆内存初始化配置信息以及堆内存的使用情况。

那么除了这个功能，其实还可以使用 jmap 输出堆内存中的对象信息，包括产生了哪些对象，对象数量多少等。.

可以用 jmap 来查看堆内存初始化配置信息以及堆内存的使用情况：

在这里插入图片描述
可以使用 jmap -histo[:live] pid 查看堆内存中的对象数目、大小统计直方图，如果带上 live 则只统计活对象：

在这里插入图片描述
可以通过 jmap 命令把堆内存的使用情况 dump 到文件中：

在这里插入图片描述
可以将文件下载下来，使用 MAT 工具打开文件进行分析：

在这里插入图片描述

下面用一个实战案例来综合使用下刚刚介绍的几种工具，具体操作一下如何分析一个内存泄漏问题。

二、实战演练

平时遇到的内存溢出问题一般分为两种

一种是由于大峰值下没有限流，瞬间创建大量对象而导致的内存溢出；
另一种则是由于内存泄漏而导致的内存溢出。

使用限流，一般就可以解决第一种内存溢出问题，但其实很多时候，内存溢出往往是内存泄漏导致的，这种问题就是程序的 BUG，需要及时找到问题代码。下面模拟了一个内存泄漏导致的内存溢出案例，来实践一下。

ThreadLocal 的作用是提供线程的私有变量，这种变量可以在一个线程的整个生命周期中传递，可以减少一个线程在多个函数或类中创建公共变量来传递信息，避免了复杂度。但在使用时，如果 ThreadLocal 使用不恰当，就可能导致内存泄漏。这个案例的场景就是 ThreadLocal，下面模拟对每个线程设置一个本地变量。

运行以下代码，系统一会儿就发送了内存溢出异常：

    @RequestMapping(value = "/test0")
    public String test0(HttpServletRequest request) {
        ThreadLocal<Byte[]> localVariable = new ThreadLocal<Byte[]>();
        localVariable.set(new Byte[4096*1024]);// 为线程添加变量
        return "success";
    }

在启动应用程序之前，可以通过 HeapDumpOnOutOfMemoryError 和 HeapDumpPath 这两个参数开启堆内存异常日志，通过以下命令启动应用程序：

java -jar -Xms1000m -Xmx4000m -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/tmp/heapdump.hprof  -XX:+PrintGCTimeStamps -XX:+PrintGCDetails -Xloggc:/tmp/heapTest.log heapTest-0.0.1-SNAPSHOT.jar

首先，请求 test0 链接 10000 次，这个时候请求 test0 的接口报异常了。

在这里插入图片描述

通过日志，很好分辨这是一个内存溢出异常。

首先通过 Linux 系统命令查看进程在整个系统中内存的使用率是多少，最简单就是 top 命令了。

在这里插入图片描述

从 top 命令查看进程的内存使用情况，可以发现在机器只有 8G 内存且只分配了 4G 内存给 Java 进程的情况下，Java 进程内存使用率已经达到了 55%，再通过 top -Hp pid 查看具体线程占用系统资源情况。

在这里插入图片描述
再通过 jstack pid 查看具体线程的堆栈信息，可以发现该线程一直处于 TIMED_WAITING 状态，此时 CPU 使用率和负载并没有出现异常，可以排除死锁或 I/O 阻塞的异常问题了。

在这里插入图片描述
再通过 jmap查看堆内存的使用情况，可以发现，老年代的使用率几乎快占满了，而且内存一直得不到释放：

在这里插入图片描述

通过以上堆内存的情况，基本可以判断系统发生了内存泄漏。

下面就需要找到具体是什么对象一直无法回收，什么原因导致了内存泄漏。

需要查看具体的堆内存对象，看看是哪个对象占用了堆内存，可以通过 jmap 查看存活对象的数量：

在这里插入图片描述

Byte 对象占用内存明显异常，说明代码中 Byte 对象存在内存泄漏，在启动时，已经设置了 dump 文件，通过 MAT 打开 dump 的内存日志文件，可以发现 MAT 已经提示了 byte 内存异常：

在这里插入图片描述

再点击进入到 Histogram 页面，可以查看到对象数量排序，可以看到 Byte[]数组排在了第一位，选中对象后右击选择 with incomming reference 功能，可以查看到具体哪个对象引用了这个对象。

在这里插入图片描述

在这里我们就可以很明显地查看到是 ThreadLocal 这块的代码出现了问题。

在这里插入图片描述

三、总结

在一些比较简单的业务场景下，排查系统性能问题相对来说简单，且容易找到具体原因。

但在一些复杂的业务场景下，或是一些开源框架下的源码问题，相对来说就很难排查了，有时候通过工具只能猜测到可能是某些地方出现了问题，而实际排查则要结合源码做具体分析。

可以说没有捷径，排查线上的性能问题本身就不是一件很简单的事情，除了将今天介绍的这些工具融会贯通，还需要不断地去累积经验，真正做到性能调优。

是否可以讲下如何避免threadLocal内存泄漏呢

ThreadLocal是基于ThreadLocalMap实现的，这个Map的Entry继承了WeakReference，而Entry对象中的key使用了WeakReference封装，也就是说Entry中的key是一个弱引用类型，而弱引用类型只能存活在下次GC之前。

如果一个线程调用ThreadLocal的set设置变量，当前ThreadLocalMap则新增一条记录，此时ThreadLocal实例没有外部强引用，当发生一次垃圾回收，此时key值被回收，而value值依然存在内存中，由于当前线程一直存在，所以value值将一直被引用。.

这些被垃圾回收掉的key就存在一条引用链的关系一直存在：Thread --> ThreadLocalMap–>Entry–>Value，这条引用链会导致Entry不会回收，Value也不会回收，但Entry中的Key却已经被回收的情况，造成内存泄漏。

我们只需要在使用完该key值之后，通过remove方法remove掉，就可以防止内存泄漏了。

内存泄露和内存溢出具体有啥区别

内存泄漏是指不再使用的对象无法得到及时的回收，持续占用内存空间，从而造成内存空间的浪费。

例如，之前在在Java6中substring方法可能会导致内存泄漏情况发生。

当调用substring方法时会调用new string构造函数，此时会复用原来字符串的char数组，而如果仅仅是用substring获取一小段字符，而原本string字符串非常大的情况下，substring的对象如果一直被引用，由于substring的里面的char数组仍然指向原字符串，此时string字符串也无法回收，从而导致内存泄露。

内存溢出则是发生了OutOfMemoryException，内存溢出的情况有很多，例如堆内存空间不足，栈空间不足，以及方法区空间不足都会发生内存溢出异常。

内存泄漏与内存溢出的关系：

内存泄漏很容易导致内存溢出，但内存溢出不一定是内存泄漏导致的。