实战：内存持续上升解决

生产环境中可能会遇到内存溢出或是内存使用率过高的问题。碰到内存持续上升的情况，其实我们很难从业务日志中查看到具体的问题，那么面对多个进程以及大量业务线程，那么该如何精准地找到背后的原因呢？

 

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

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

 

Linux 命令行工具之 top 命令

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

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

 

Linux 命令行工具之 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：运行虚拟机窃取的时间。

 

Linux 命令行工具之 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 的内存分配以及使用情况。

 

JDK 工具之 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)。

 

JDK 工具之 jstack 命令

这个工具在是一种线程堆栈分析工具，最常用的功能就是使用 jstack pid 命令查看线程的堆栈信息，通常会结合 top -Hp pid 或 pidstat -p pid -t 一起查看具体线程的状态，也经常用来排查一些死锁的异常。

每个线程堆栈的信息中，都可以查看到线程 ID、线程的状态（wait、sleep、running 等状态）以及是否持有锁等。

 

JDK 工具之 jmap 命令

使用 jmap 可以查看堆内存初始化配置信息以及堆内存的使用情况。那么除了这个功能，我们其实还可以使用 jmap 输出堆内存中的对象信息，包括产生了哪些对象，对象数量多少等。

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

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

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

我们可以通过 jmap 命令把堆内存的使用情况 dump 到文件中：

我们可以将文件下载下来，使用 MAT 工具打开文件进行分析：

 

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

 

实战演练

 

我们平时遇到的内存溢出问题一般分为两种，一种是由于大峰值下没有限流，瞬间创建大量对象而导致的内存溢出；另一种则是由于内存泄漏而导致的内存溢出。

 

使用限流，我们一般就可以解决第一种内存溢出问题，但其实很多时候，内存溢出往往是内存泄漏导致的，这种问题就是程序的 BUG，我们需要及时找到问题代码。

 

下面我模拟了一个内存泄漏导致的内存溢出案例，我们来实践一下。

我们知道，ThreadLocal 的作用是提供线程的私有变量，这种变量可以在一个线程的整个生命周期中传递，可以减少一个线程在多个函数或类中创建公共变量来传递信息，避免了复杂度。但在使用时，如果 ThreadLocal 使用不恰当，就可能导致内存泄漏。

这个案例的场景就是 ThreadLocal，下面我们模拟对每个线程设置一个本地变量。运行以下代码，系统一会儿就发送了内存溢出异常：

final static ThreadLocal<Byte[]> localVariable = new ThreadLocal<Byte[]>();// 声明本地变量

@RequestMapping(value = "/test0")

public String test0(HttpServletRequest request) {

new Thread() {

          public void run() {

              localVariable.set(new Byte[4096*1024]);// 为线程添加变量

              try {

Thread.sleep(2000);// 延迟线程生命周期，使得在其他线程调用 set 时，避免回收已经失去引用的 key 的 value

  } catch (InterruptedException e) {

// TODO Auto-generated catch block

e.printStackTrace();

  }

          }

        }.start();

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 这块的代码出现了问题。

 

总结

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