总结常见Java故障案例

作者:神秘网友 发布时间:2020-08-29 06:28:11

总结常见Java故障案例

【总结】常见Java故障案例

原文 http://dbaplus.cn/news-21-173-1.html


目录

  • HotSpot常识

  • Java故障排查方法论

  • Java故障案例分析

Part 1

HotSpot常识

  • HotSpot是目前最常见的开源JVM(GPL协议),用来运行Java应用和applet,本次讨论基本都是基于这一软件来进行的。

  • 所有的Java对象都是分配在Java堆上的,Java代码中看到的引用,在JVM的实现中就是一个指针,指向一段被表示成对象的内存区域。这个区域可能被移动,引用指针的值不同于一般的C/C++指针,是会从外部改变的。

  • 执行的Java字节码都是动态加载、链接、编译的。

  • JIT compiler,JVM里面有一个模块负责把Java字节码编译成优化过的native机器码,这样可以极大提高执行效率。

    但 是HotSpot的JIT编译器只会编译热点方法,一个Java方法load进来后会默认从解释器开始执行,只有部分或整体的解释执行次数超过一定次数才 会被编译优化,在某些条件下,比如debug,会把方法去优化退回到解释器执行。解释器可以看做是一个没有优化的翻译器,会把每一条bytecode指令 机械的翻译成汇编指令来执行。

1.6, 两个stack,interned string放到heap

总结常见Java故障案例

这张图里每一个小方块展开都可以写一系列文章,今天就不在这里展开了。

参考链接:

http://blog.jamesdbloom.com/images_2013_11_17_17_56/JVM_Internal_Architecture.png

http://blog.jamesdbloom.com/JVMInternals.html

Part 2

Java故障排查方法论

1 1参考书

总结常见Java故障案例

总结常见Java故障案例

2 几个我个人常用的三个原则

  • 从浅显和广泛开始。分析问题应该尽量从高层入手,收集各种各样的现场信息,版本信息,尽量不要一开始就debugger跑起。

  • 分而治之,隔离问题。将问题隔离到尽可能小的领域中,比如某个特定系统、特定版本、 甚至特定机器中。之后如果是java的问题,还可以继续分析是java应用、容器、或者jdk的问题,最后应该能确定到某个模块的某些代码、一次 commit、一行配置的问题。整个排查问题的过程就是一个从上到下,一步步缩小问题范围的过程。

  • 福尔摩斯法则。当排除了所有的不可能,那么剩下的那个,不管多么荒谬,就是罪魁祸首了。

3 重现故障和收集数据

不同于其他工业系统,软件工业的一个好处就是重新尝试的代价一般都特别小,重启一个进程总比重启一台发动机、一个核反应堆轻松很多。所以如果故障问题能稳定的通过重启复现,这对于修bug的同学将会是个天大的好消息。

但是现实中,特别是在生产环境中,更多的事后故障问题不是你想发现就能发现,经常是重启后就没了,跑了不确定的时间就又出现了,所以只能通过收 集故障时的系统状态数据来分析问题。状态数据大致可以分为两类:一是监控类数据,收集这类数据对于应用的性能影响很小,基本可以忽略不计,所以可以持续收 集,比如GC log,应用log等;第二类是某些瞬时数据,这些数据要么收集的代价很大,很影响系统性能,要么时效性很高,过了故障点一切可能就都不一样了,所以不能 持续收集,必须迅速的在故障出现点自动采集,比如Heap dump,core dump等。

下面这个图描述了常见的Java故障和需要收集的数据之间的概要关系

总结常见Java故障案例

JVM级别数据

对于JVM,下面这些选项最好常年打开选项,对于收集故障数据很有帮助

-XX:+PrintGCDetails

-XX:+PrintGCDateStamps

-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/log/gcdump

系统级别数据

Java进程运行的环境信息也是重要的诊断信息,如果能在故障点全部收集下来对于后续调试分析也是很有帮助的,这些信息主要包括: 系统基本软硬件信息、所有进程的情况、打开的文件描述符等等。

简单的做法可以在Java进程非正常返回的时候执行一个脚本,自动的去采集一遍这些信息。(HotSpot支持在致命错误或者oom时执行一个系 统命令,可以设置让其去直接执行这个脚本)。或者说是使用一个监控程序,监视Java进程的输出结果,如果发现异常、crash等情况,就收集一次环境信 息。

Part 3

Java故障案例分析

故障1 CPU load过高

问题一般是指CPU使用率很高,但是系统并没有很繁忙,一般有两种情形。

总结常见Java故障案例

总结常见Java故障案例

情况1,启动阶段

应用刚启动之后或者刚放了用户流量之后,也是可能突然cpu load飙到很高的,这一般不是java代码引起的,而是由于jvm的jit编译器引起的。(当然如果你使用的是一些非普遍的JDK,比如IBMJDK, 并且启用了AOT之类的功能,是不可能遇到这个情况的,因为代码已经提前编译好了)

  • -XX:+TieredCompilation

可以先一定程度上减轻这个问题,效果上相当于把消耗资源严重的一些优化处理延后进行了,先把java方法编译到一个低优化级别的native方 法。值得注意的是,这个参数会消耗比较多的内存资源,同一个方法被编译了多次,存在多份native内存拷贝,建议是把codecache调大一点儿 (-XX:+ReservedCodeCacheSize,InitialCodeCacheSize)。

Optional:

CodeCache不足可能会引起性能问题,这是一种非常少见的故障,code cache不足,jit需要编译新的方法的时候就会不停的尝试清理code cache,丢弃掉无用的方法,频繁的尝试会导致大量资源消耗在JIT线程上。

  • -XX:+PrintCompilation

为了确认这个问题可以尝试使用这个参数,输出JIT编译的情况,如果初始阶段发生大量方法的编译,就可以确定是由于JIT编译引起的。一般情况下,忍一忍熬过一开始的编译阶段就好了。如果用户请求超时严重,无法忍受,可以尝试使用分层编译、提前预热系统。

情况2,非启动阶段

一般是一些计算密集型任务、忙等操作、或者过于密集的线程调度。一般需要定位出被频繁执行的代码逻辑(热点方法),然后再进行优化,目前可以使用 各种profile工具来分析。比如Java Mission Control, ZProfiler(硬广:阿里自产的profiler工具)

总结常见Java故障案例

总结常见Java故障案例

故障2 应用性能下降/较差

这个问题又两个层面,一个是应用的性能下降了,这一般是来自监控系统或者用户突然的报警 。从分割问题的角度看,性能下降一般是和之前时间点比较得出的结论,那么就肯定有一个分水岭,在某一个时间点(通常是一个改动发生的时候)之后就会开始性 能下降。所以初始的解决方案比较简单,就是找到改动发生的时间点,挑出造成性能下降的改动,然后分析这个改动为什么会造成性能下降。

但是如果就是一个应用性能较差的问题,就比较棘手了,这个通常意味着没有可以比较的时间点,相当于凭空设定一个性能指标,将系统性能优化提升到这 个目标。通常这是一个需要多方合作,修改多个层次的代码、配置才能达到的目标。通常而言可以继续尝试profiling Java应用,分析性能瓶颈,优化瓶颈部分。

可能有影响的瓶颈包括:

这个一般需要设计、代码层面的改动,使用更高效的加锁机制,减轻竞争,等等。

GC

总结常见Java故障案例

频繁full gc的又有两种情况,一种是说full gc完了之后整个heap还是没有很多的可用空间,一般是可能是由于最大heap上限可能设置有点儿小了,或者应用有内存泄露,需要做个heap dump具体分析下内存里面各个部分的使用情况。

另外一个情况是full gc完了之后整个heap还是有不少的可用空间的,比如下图,这个一般是有一些“临时”对象晋升到了老年代,新生代没有滤掉足够的短生命周期对象,可能需 要调整JVM参数-XX:MaxTenuringThreshold(15, 4bits)提高promote到老年代的门槛。

总结常见Java故障案例

总结常见Java故障案例

分析GC日志,一个开源的免费解决方案是eclipse的GCMV

总结常见Java故障案例

GC参数优化

关于GC其实你能做的并不多,影响最大就是通过调整JVM启动时参数,来调节GC的各个行为,但是推荐读懂了官方文档中的说明再做调整:

http://www.oracle.com/technetwork/java/javase/tech/vmoptions-jsp-140102.html

1.    仔细设计一个适合你自己环境、应用的参数模板。

2.    收集应用信息,评估应用内存活动行为(参见“Java性能优化权威指南”),常驻内存对象大小,大对象比例,native内存使用,分配速度等。。。

3.    调整下列参数(不是一条命令哦)

-Xms8888m
-Xmx8888m
-Xmn8888m
-Xss8888k
-XX:PermSize=8888m
-XX:MaxPermSize=8888m
-XX:+UseStringCache
-XX:+UseConcMarkSweepGC

-XX:+UseG1GC
-XX:+UseParNewGC

-XX:ParallelGCThreads=8888

-XX:+CMSClassUnloadingEnabled

-XX:+DisableExplicitGC

-XX:+UseCMSInitiatingOccupancyOnly

-XX:CMSInitiatingOccupancyFraction=88

GC停顿时间太长

堆太大的时候,CMS GC可能会停顿比较久的时间,-XX:+CMSScavengeBeforeRemark能通过在remark阶段前做一次young gc减轻这个时间。

另外可以考虑换G1。

总结常见Java故障案例

故障3 内存耗尽OOM

基本的解决思路,多给点儿或者少用点儿呗。

  • Java对象真的耗尽了内存资源,Eclipse MAT
    HeapDump,分析内存泄露,大对象,对象关系图。

  • Native内存耗尽, DirectBuffer,malloc

    JVM运行过程中,虽然会对Java堆做垃圾收集,但是如果jni或者非DirectBuffer的Unsafe分配的内存没有回收,会逐渐累积直至java进程结束。DirectBuffer虽然Java对象很小,但是使用的内存可能会很多。

    参考:http://lovestblog.cn/blog/2015/05/12/direct-buffer/

  • PermGen耗尽,一般动态类加载导致,已经成为历史,尽早升级吧。

故障4 崩溃crash

现代JVM发展到今天已经很健壮了,一般很少会出现crash的情况,如果出现了,很有可能是Java代码执行了不安全的操作,比如使用Unsafe去直接操作内存、自己编写了JNI函数中crash了。

总结常见Java故障案例

目前的现实是很多第三方的库确实直接使用了Unsafe去实现各种“高效”的操作,随便搜索下Github就可以看到大量的开源Java、Scala库使用了JDK提供的unsafe类

总结常见Java故障案例

对于crash的情形,需要收集的信息包括各种dump,最关键的是系统core dump,方便将来使用GDB做事后分析,在linux上一般需要使用ulimit –c unlimited 命令修改core文件尺寸上限才行。

有了core dump,剩下的分析一般都是使用GDB继续了,crash的情形一般反而比较直观。如果不是unsafe、自己jni引起的crash问题,恭喜你,真的发现bug了,这个问题直接给Oracle或者java社区报bug吧。

总结常见Java故障案例

脚本太复杂,怎么知道最后跑起来的Java进程到底设置了哪些参数?

-XX:-PrintCommandLineFlags

总结常见Java故障案例相关教程

  1. 深入分析Java Web-Servlet工作原理
  2. Spark Executor 报错 java.lang.StackOverflowError
  3. JAVA300集学习总结 第五章笔记 2019.05.24
  4. 传智播客Java 方法
  5. 使用原生javaScript创建ul和li对象以及操作
  6. JAVA读取属性文件的几种主流方式
  7. day16 集合01(ArrayList,LinkedList -> java基础大神进阶学习
  8. Servlet 开发(1)