背景介绍

我负责一个物联网平台的开发与运维工作，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日志查看改线程的工作状态和调用栈状况，这里有两种状况：

  1. 如果是失常的用户线程，则通过该线程的堆栈信息查看其具体在哪出代码运行比拟耗费CPU;
  2. 如果该线程是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能够帮忙你解决：

  1. 这个类从哪个 jar 包加载的？为什么会报各种类相干的 Exception？
  2. 我改的代码为什么没有执行到？难道是我没 commit？分支搞错了？
  3. 遇到问题无奈在线上 debug，难道只能通过加日志再从新公布吗？
  4. 线上遇到某个用户的数据处理有问题，但线上同样无奈 debug，线下无奈重现！
  5. 是否有一个全局视角来查看零碎的运行状况？
  6. 有什么方法能够监控到JVM的实时运行状态？
  7. 怎么疾速定位利用的热点，生成火焰图？

参考资料

零碎运行迟缓，CPU 100%，以及Full GC次数过多问题的排查思路

JVM性能调优监控工具jps、jstack、jmap、jhat、jstat、hprof_神往的专栏-CSDN博客

本文由博客一文多发平台 OpenWrite 公布！