关于java:记一次CPU与内存飙高的线上事故

0次阅读

共计 2549 个字符，预计需要花费 7 分钟才能阅读完成。

我负责一个物联网平台的开发与运维工作，2020 年 12 月 18 日的一天，恰逢周五，原本认为能够划划水就能够过欢快的周末了，一大早让我看下昨天的设施上报的数据状况，关上浏览器输出网址，无奈失常登录，提醒服务器外部谬误！我心里一想不对呀，自己照看的零碎曾经稳固运行很长一段时间了，怎么会这样？都坐下，不要慌，咱们缓缓的来解决。

首先，通过我的 FinalShell 工具通过 ssh 登录服务器，一眼就看到了让我震惊的后果，我开始慌了。。。

有个 java 过程竟然内存和 CPU 占用都这么高，而后我简略看了一下过程号，定位到是物联网平台的后盾服务过程（因为该平台是采纳 docker 部署的，因而须要进入 docker 容器外部进行查看）

docker exec -it cfe1916c608a /bin/bash

通过 docker exec 进入容器外部，首先还是应用咱们比拟罕用 top 看下状况

果然，与咱们看到的景象统一，有个 java 过程 RES 占有高达 8.6g，%CPU 高达 277.0，这时忽然 有些兴奋呀，我又能够躺坑了，预先会被作为教训文章分享进去，也就是你当初看到的样子????。而后咱们一步步来剖析和解决。。。

接下来，咱们次要从 CPU 升高的方向先动手剖析。复制该过程的 id 号 8，通过执行 top -Hp 查看以后过程的各个线程执行状况

top -Hp 8

能够看到，后面几个线程的 CPU 占用都十分高，咱们随机筛选一个 PID 为 13 的线程进行剖析，须要留神的是，在 jstack 命令展现中，线程 id 都是转化成的十六进制模式，应用以下命令打印线程 id 的 16 进制后果

重点来了，执行 jstack 查看堆栈信息状况

jstack 8 |grep d

终于发现因为什么导致 CPU 升高了，能够看到 a，b，c，d 都是代表 GC 线程（PS：上图中的 10~13 这几个都是 GC 线程），咱们大略猜想应该就是因为 GC 进行频繁的垃圾回收，导致其余业务无奈失常的工作。好的，咱们还是通过 jstat 验证一下

jstat -gcutil 8 2000 10

果然，这个 FGC 与 FGCT 显示的 fullGC 的次数和工夫是不是让你头皮发麻 ????。而后，给大家一个 小技巧，咱们先通过 jmap -histo 命令先大抵查看下堆内存的对象数量和大小状况

jmap -histo:live 8 | more

从剖析中咱们能够看到【B 与【C 占有都十分高，这是什么玩意？其实这个 Byte 和 Char 数组，大胆猜想可能是有大量的 String 字符串。。。

class name 是对象类型，阐明如下：

B byte
C char
D double
F float
I int
J long
Z boolean
[数组，如[I 示意 int[]
[L+ 类名其余对象

咱们还是来好好剖析下，到底是什么起因导致的 GC 通过这么致力在开释堆内存还是开释不进去，帮帮 JVM 虚拟机诊断下病因，这个时候其实大家应该曾经晓得咱们应该看下堆内存外面到底是什么

首先，咱们通过 jmap -dump 导出当初 JVM 的堆内存日志状况

jmap -dump:format=b,file=dump.dat 8

而后，从服务器下载 dump.dat 文件到本机，通过 Eclipse Memory Analyzer 工具对其进行剖析查看

内存应用整体状况

间接点击下方 Reports→Leak Suspects 链接来生成报告，查看导致内存泄露的罪魁祸首

从图中能够看出一个可疑对象耗费了近 93.43% 的内存。接着往下看，点击 Details 查看详细情况

备注：

Shallow Heap 为对象本身占用的内存大小，不包含它援用的对象。

Retained Heap 为以后对象大小 + 以后对象可间接或间接援用到的对象的大小总和

点击 dominator_tree 查看 entries heap 对象援用关系 tree 进行剖析

最终通过点击 entries 援用 tree 层层查看对象的援用状况，查看相熟的货色，定位到如同与 device_log_mtu_2020-12 这个中央有关系

其实咱们曾经大略定位到问题呈现地位了，接下来其实就要联合业务零碎状况来追究业务状况与剖析零碎代码，最终定位到问题的起因：

以下截图是我与零碎的技术开发人员的交换，最终大略定位到问题的起因：因为代码的逻辑 bug 导致呈现 死循环

先通过 top 命令查看 CPU 与内存状况，查看是什么过程的 CPU 和内存飙高，如果是 CPU 比拟高，则能够通过 top -Hp <pid> 命令查看以后过程的各个线程运行状况，找出 CPU 过高的线程当前，将其线程 id 转换为十六进制的模式后，而后通过 jstack 日志查看改线程的工作状态和调用栈状况，这里有两种状况：

如果是失常的用户线程，则通过该线程的堆栈信息查看其具体在哪出代码运行比拟耗费 CPU;
如果该线程是 VM Thread，则通过jstat -gcutil <pid> <period> <times> 命令监控以后零碎的 GC 情况，而后通过 jmap dump:format=b,file=<filepath> <pid> 导出零碎以后的内存数据。导出之后将内存状况放到 eclipse 的 mat 工具中进行剖析即可得出内存中次要是什么对象比拟耗费内存，进而能够解决相干代码

如果企业外部自身没有相干监控与运维工具，那咱们能够应用 JDK 自身提供了一些监控剖析工具（jps、jstack、jmap、jhat、jstat、hprof 等），通过灵活运用这些工具简直可能定位 Java 我的项目 80% 的性能问题。最初在这里举荐一个 Alibaba 开源的 Java 诊断工具 Arthas 能够帮忙你解决：