前言
哈喽哈喽,不知道还有多少人记得我之前欠了一篇重量级文章来着,就是一直难产的项目难点文章。最近准备重启这个选题了,会先写几篇线上问题处理的文章理一理思路。OOM问题也是老生常谈,最常见的就是堆内存溢出和栈内存溢出,但是本期主要聊聊堆的,因为相对来说手段会更加丰富一些,并且会有一定的方法论总结。栈的话确实没啥好说的,看看堆栈异常日志其实就能猜个七七八八,周五同事遇到这个问题,但是因为他电脑问题,换我电脑运行就没有,最后也没定位出来,素材丢失。除了堆内存溢出,还会补充CPU爆满的解决方法做内容填充,会给大家推荐一些实用的工具,帮助我们更好的定位和解决问题。
正文
如何解决堆内存溢出问题
OOM有很多种情况啊,这里就先讲解最常见也是最容易观测的java.lang.OutOfMemoryError: Java heap space,也就是堆内存溢出。
发现
启动Java程序的时候,最好参数加上-XX:+HeapDumpOnOutOfMemoryError,该参数不影响程序运行,运行时没有任何开销,只有OOM时会自动生成Java Heap Dump(特定时刻 JVM 内存中所有对象的快照)。该文件默认会在运行应用程序同级目录下生成一个格式为hprof的文件,当然也可以使用参数-XX:HeapDumpPath=/data指定生成到data文件夹下。
这里说一下我对于Java程序运行添加参数的一些理解,这是我项目的一个常规启动命令
java -javaagent:/usr/local/app/skywalking_agent_zy/skywalking-agent.jar -Dskywalking.agent.service_name=${appName} -Dskywalking.collector.backend_service=${skywalkingIp}:${skywalkingPort} -Dskywalking.plugin.toolkit.log.grpc.reporter.server_host=${skywalkingIp} $jvmoption -Dserver.port=8080 -Denv=${env} -jar /usr/local/app/app.jar
${}占位符这里是在DevOps上面配的,当然大家也没必要关注,嘻嘻。这里这个env是公司框架让配的环境参数,前面Javaagent一堆参数都是skywalking要用的。
除开这些客制化的东西,对于普通的应用,一般配置堆大小相同比较好,因为通常来说一个服务器或者容器只会有一个Java应用,释放内存给谁用呢,是吧,没那必要。JVM初始分配的堆内存由-Xms指定,默认是物理内存的1/64,JVM最大分配的堆内存由-Xmx指定,默认是物理内存的1/4。默认空余堆内存小于40%时,JVM就会增大堆直到-Xmx的最大限制,空余堆内存大于70%时,JVM会减少堆直到-Xms的最小限制。因此一般设置-Xms、-Xmx相等以避免在每次GC后调整堆的大小。
定位
拿到hprof文件后,可以选用jvisualvm(Jdk8之后不自带,需要到Github上下载)、JProfiler和IDEA的Profiler(旗舰版才有)打开文件,三者的操作逻辑都是类似的,目前我用的最舒服的是JProfiler,以下就拿JProfiler截图举例。
导入hprof文件到JProfiler之后经过解析,默认会跳到该界面,这里直接选上面的最大对象,继续解析。
这里右键选定比较大的对象后会弹出这样一个框,选择引用-传入引用。为啥是传入引用呢,因为我们要找问题的源头啊,哪里来的才是比较重要的。
找到对应堆栈信息,点击显示更多,即可发现带恶人。
以上就是一次完整的查询过程,如果点开发现都是差不多的内容,为了少点几次,保护鼠标,我建议可以换成旭日图更加便捷地查看
可以观察到相对类型地这个对象比较多啊,这里点击一下这块进入内部查询
如何解决CPU占用高问题
CPU占用高的问题就没有挂了之后自动dump文件的好事了。这时候需要善用jstack、监控和Arthas等工具。
发现
正常来说,咱们会有监控软件去监控服务器的一些性能指标,我这用的是Prometheus+Grafana,非常大众哈。
如图可以观察到一个服务器CPU占用的折线图,配合告警可以及时通知相关人员定位问题。
定位-传统武学
通过上面地监控及时发现问题,接下来就该上手具体的操作了。
- top -o %CPU,Linux上按CPU从大到小排序,找到占用最多的PID(这里假设是Java应用)
- jstack pid > thread.txt,通过jstack命令打印当前Java应用的堆栈信息
- top -Hp pid,通过该命令观察此pid进程中所有线程的CPU占用
- 找到线程pid,通过命令printf ‘%x\n’ pid得到转换为16进制的nid
- 在jstack获得的文件thread.txt中,找到nid对应的线程堆栈信息,找到对应代码块即可
通常除了CPU占用过高的线程,还需要重点关注线程状态为BLOCKED、WAITING和TIMED_WAITING的部分
定位-新派宝典
我一开始接触的也是传统武学,啪啪啪一堆命令敲得也是非常麻烦嗷,那有没有开箱即用的好东西呢。没错,那肯定是有的,就是大名鼎鼎的Arthas啦。
- 下载Arthas.jar,curl -O https://arthas.aliyun.com/arthas-boot.jar
- 运行java -jar arthas-boot.jar并选择需要监听的Java应用,图形化很赞
- 输入命令dashboard打开看板,随时监控,默认5000ms一刷
- 针对上面CPU问题,直接选择Thread系列命令
效果如下,牛中牛中牛,解放双手。相比jstack输出的文件,甚至多了cpuUsage这个参数,更加直观。
Arthas还有很多别的牛逼功能,不仅仅是Jdk工具的一个打包,更是对前者进行了易用性上的极大优化,同时也提供了很多新功能,要知道这玩意才一百多KB啊。
Arthas使用小结
Arthas官网
- 定位CPU100%问题。使用Thread命令查看所有线程情况,再使用Thread指定某个ID进行该占用最大的线程详情,得到异常代码类路径。通过Arthas自带的反编译命令jad,查看前面获得的异常代码的源码,从而定位问题。
- 定位死锁问题。使用Thread命令查看所有线程情况,如果发现有多个线程长期处于阻塞状态,就可以使用Thread -b命令,来查看当前阻塞的线程。接着Thread 线程ID和jad,定位源码即可
- **线上运行耗时性能问题排查。**使用trace命令,加上全限定类名和方法(trace com.wzy.arthas.TestController queryAny)。完成命令输入后就会开启对该方法的阻塞监听,每调用一次就会生成一次监控报告。
- **线上方法耗时统计。**使用monitor命令,指定方法名和窗口时间5秒(monitor -c 5 com.wzy.arthas.TestController queryAny)。就能看到控制台每5s打印,方法的平均耗时,成功和失败次数等信息。