极客时间已完结课程限时免费阅读

25 | 内存持续上升，我该如何排查问题？

25 | 内存持续上升，我该如何排查问题？-极客时间

25 | 内存持续上升，我该如何排查问题？

2019-07-18 刘超 来自北京
《Java性能调优实战》
课程介绍

讲述：李良

时长09:32大小6.54M

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

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

工欲善其事，必先利其器。平时排查内存性能瓶颈时，我们往往需要用到一些 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 命令

在第 23 讲中我们使用过 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 这块的代码出现了问题。

总结

在一些比较简单的业务场景下，排查系统性能问题相对来说简单，且容易找到具体原因。但在一些复杂的业务场景下，或是一些开源框架下的源码问题，相对来说就很难排查了，有时候通过工具只能猜测到可能是某些地方出现了问题，而实际排查则要结合源码做具体分析。
可以说没有捷径，排查线上的性能问题本身就不是一件很简单的事情，除了将今天介绍的这些工具融会贯通，还需要我们不断地去累积经验，真正做到性能调优。

思考题

除了以上我讲到的那些排查内存性能瓶颈的工具之外，你知道要在代码中对 JVM 的内存进行监控，常用的方法是什么？
期待在留言区看到你的分享。也欢迎你点击“请朋友读”，把今天的内容分享给身边的朋友，邀请他一起讨论。
分享给需要的人，Ta购买本课程，你将得18元
生成海报并分享

赞 18

提建议

© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
上一篇
24 | 如何优化JVM内存分配？
下一篇
26 | 答疑课堂：模块四热点问题解答
unpreview
 写留言

精选留言(35)

  • 每天晒白牙
    2019-07-18
    放两篇自己在工作中排查JVM问题的两篇文章【非广告，纯技术文】 https://mp.weixin.qq.com/s/ji_8NhN4NnEHrfAlA9X_ag https://mp.weixin.qq.com/s/IPi3xiordGh-zcSSRie6nA

    作者回复: 赞！

    共 10 条评论
    90
  • 我已经设置了昵称
    2019-07-18
    老师是否可以讲下如何避免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掉，就可以防止内存泄漏了。

    共 11 条评论
    73
  • WL
    2019-07-18
    请问一下老师内存泄露和内存溢出具体有啥区别，有点不太理解内存泄露的概念。

    作者回复: 内存泄漏是指不再使用的对象无法得到及时的回收，持续占用内存空间，从而造成内存空间的浪费。例如，我们之前在第3讲中聊到的在Java6中substring方法可能会导致内存泄漏情况发生。当调用substring方法时会调用new string构造函数，此时会复用原来字符串的char数组，而如果我们仅仅是用substring获取一小段字符，而原本string字符串非常大的情况下，substring的对象如果一直被引用，由于substring的里面的char数组仍然指向原字符串，此时string字符串也无法回收，从而导致内存泄露。 内存溢出则是发生了OutOfMemoryException，内存溢出的情况有很多，例如堆内存空间不足，栈空间不足，以及方法区空间不足都会发生内存溢出异常。 内存泄漏与内存溢出的关系：内存泄漏很容易导致内存溢出，但内存溢出不一定是内存泄漏导致的。

    共 2 条评论
    34
  • 怪盗キッド
    2019-09-22
    我开源了一个 Java 性能监控工具，就是用 JDK 自带的接口实现的。 GitHub 地址：https://github.com/LinShunKang/MyPerf4J

    作者回复: 👍

    共 2 条评论
    18
  • Rain
    2019-08-04
    老师，为什么线程要sleep一下，看了注释还是不理解，求告知

    作者回复: 正常情况下，如果一个线程set之后，该线程销毁了，然后key值由于弱引用刚好遇到一次GC，被回收了，此时value已经出现内存泄漏。而threadlocal为了解决这个问题，在后面的线程进行set时，会把之前key值为null的value清空掉，所以就不会出现大量内存泄漏了。 所以我们要模拟的就是，在后面进来的线程set之前，保证之前的线程还没有销毁，之前的key value就会保持，这样我们能模拟出大量value内存泄漏的情况出现。

    共 3 条评论
    12
  • CRann
    2019-07-31
    老师，刚看案例top命令后java的pid是1444，可是为什么后来查线程信息变成top -Hd 1593了？

    作者回复: 截图截错了，自己操作的时候记得输入正确的pid就好了。

    10
  • 昨夜的柠檬
    2019-10-27
    实际项目中很多都是这样的，老师正确的写法应该是怎样的？

    作者回复: 正确的写法是在set之后，记得在finally里面remove掉。 try{ localthread.set("test"); }finally{ localthread.remove("test"); }

    9
  • 殿小二
    2019-12-03
    老师 "而threadlocal为了解决这个问题，在后面的线程进行set时，会把之前key值为null的value清空掉，所以就不会出现大量内存泄漏了。" 后面的线程set的时候也只会在自己持有的ThreadLocalMap上进行操作吧,没有所谓的清空 key为null的value的值吧

    作者回复: 是的，后面线程的set只是在当前线程的ThreadLocalMap上进行操作，不能清空其他线程ThreadLocalMap上已经泄漏的value值。这里指的是同一个线程，ThreadLocal实例没有外部强引用的情况下被回收了，此时key值会被回收，下一次在相同线程下set，value值会被清掉。

    6
  • 偏偏喜欢你
    2019-11-21
    老是您好最近看到项目有报内存溢出，发现是byte[]的问题，但是在Histogram 下看到排在第一位的是char[]数组，排第二的是byte[] 我是去排查char[]呢还是byte[]

    作者回复: 这两个都是基础数据类型数组，例如char[]是String的基础数据类型，byte[]则是数据传输字节流的基础数据类型，排在第一二是比较常见的，我们需要再看看大小，如果异常大，那就是该基础数据类型之上的某个引用类型的问题。可以通过工具再展开树看看封装基础数据类型的引用类型是什么。

    5
  • Bruce
    2020-05-13
    问下老师，jmap和jstack命令能查历史的数据，譬如想查昨天的？

    作者回复: 只能查看运行时的数据，如果需要历史数据，可以在JVM启动参数中加入dump日志参数，启动长时间JVM日志监控： 启动OOM监控日志：-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/tmp/heapdump.hprof 启动GC日志：-XX:+PrintGCTimeStamps -XX:+PrintGCDetails -Xloggc:/tmp/heapTest.log

    4
  • Alex
    2020-01-29
    老师好，不好意思，想问一下，本门课程案例代码的git地址在哪里？我没有找到

    作者回复: 由于代码比较少，这篇没有提交到github上，麻烦自己建个项目，拷贝下文章中的代码上去就好了。

    3
  • 星星滴蓝天
    2019-08-05
    代码中对jvm监控常用方法是啥？我翻了翻留言，没有人问这个问题的

    作者回复: 可以通过ManagementFactory中的RuntimeMXBean实时获取JVM对应的值

    4
  • vvip
    2020-03-30
    老师，请问JVM上始终开启HeapDumpOnOutOfMemoryError这个参数，会影响性能吗？

    作者回复: 有性能损耗

    2
  • 丁奇老师的粉丝
    2019-11-09
    老师您好，看了您的课程收货颇丰！谢谢 现在有个问题想咨询下 前提：jdk7u24 xms8g xmx8g g1垃圾回收 现象： 堆内存使用量从2G一直到6.3G都没有young gc 和 full gc 当堆内存使用量到了7G的时候直接进行了full gc 并且周期性重复上面的full gc 查看GC日志 eden区回收前高达6.3G 请问老师。现在该如何调优呢
    展开

    作者回复: 如果没有设置年轻代与老年代的比例，默认分配给年轻代最大比例为60%，而且默认会先触发young gc，所以你说的这种情况比较少见，检查是否长时间存活的对象太多导致的。 这种情况优化设置参数已经没有很明显的作用了，建议先查找内存爆满的原因。

    2
  • null
    2021-04-29
    老师，请问一下，文章是二次修改过么？评论区有些关键字如：sleep，test0，test1。 我在文章只看到 test0 方法。另两个都没找到。 谢谢！
    1
  • 静静聆听
    2020-12-10
    treadLocal会随着线程被回收而消失的，不会一直存在，极端情况才会内存泄漏
    共 1 条评论
    2
  • Feng
    2019-08-31
    没看到有test1啊。。。

    作者回复: 之前的代码已经优化了，所以去掉了test1，重写写了test0方法，两个方法对于大家来说不是很好理解

    1
  • WolvesLeader
    2019-08-21
    java -jar -Xms1000m -Xmx4000m -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/tmp/heapdump.hprof -Xms1g -Xmx1g -XX:+PrintGCTimeStamps -XX:+PrintGCDetails -Xloggc:/tmp/heapTest.log heapTest-0.0.1-SNAPSHOT.jar 配置了2个-Xms和-Xmx，为啥要配置2个

    作者回复: 一个就够了，已修正

    1
  • 拒绝
    2019-07-18
    我用ab测试，设置请求数量一万，请求test0，内存就溢出，；还没请求到test1,？

    作者回复: 内存泄露导致有大量对象无法回收，占满了堆内存情况下，就会导致内存溢出。我在这里加了一个test1只是为了创建更多的对象，从而更容易发生内存溢出。

    1
  • 恰饭哒
    2019-07-18
    老师太棒了，是我一直想总结而不知道怎么总结的一篇文章
    1