听阿里巴巴JVM工程师为你分析常见Java故障案例

时间 2019-11-13

标签阿里巴巴 jvm 工程师为你分析常见 java 故障案例栏目阿里巴巴繁體版

原文原文链接

听阿里巴巴JVM工程师为你分析常见Java故障案例

本文根据12月23日阿里巴巴技术保障部JVM组软件工程师陆传胜老师在【DBA+社群，微信公众号：dbaplus】的主题分享整理！小编特别整理出其中精华内容，供你们学习交流。同时，也很是感谢陆传胜老师对DBA+社群给予的大力支持。 html

目录 java

HotSpot常识 linux
Java故障排查方法论 c++
Java故障案例分析安全

Part 1 性能优化

HotSpot常识微信

HotSpot是目前最多见的开源JVM（GPL协议），用来运行Java应用和applet，本次讨论基本都是基于这一软件来进行的。 oracle
全部的Java对象都是分配在Java堆上的，Java代码中看到的引用，在JVM的实现中就是一个指针，指向一段被表示成对象的内存区域。这个区域可能被移动，引用指针的值不一样于通常的C/C++指针，是会从外部改变的。 app
执行的Java字节码都是动态加载、连接、编译的。 eclipse
JIT compiler，JVM里面有一个模块负责把Java字节码编译成优化过的native机器码，这样能够极大提升执行效率。

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

1.6, 两个stack，interned string放到heap

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

参考连接:

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

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

Part 2

Java故障排查方法论

11参考书

2几个我我的经常使用的三个原则

从浅显和普遍开始。
分析问题应该尽可能从高层入手，收集各类各样的现场信息，版本信息，尽可能不要一开始就debugger跑起。
分而治之，隔离问题。
将问题隔离到尽量小的领域中，好比某个特定系统、特定版本、甚至特定机器中。以后若是是java的问题，还能够继续分析是java应用、容器、或者 jdk的问题，最后应该能肯定到某个模块的某些代码、一次commit、一行配置的问题。整个排查问题的过程就是一个从上到下，一步步缩小问题范围的过程。
福尔摩斯法则。
当排除了全部的不可能，那么剩下的那个，无论多么荒谬，就是罪魁祸首了。

3重现故障和收集数据

不一样于其余工业系统，软件工业的一个好处就是从新尝试的代价通常都特别小，重启一个进程总比重启一台发动机、一个核反应堆轻松不少。因此若是故障问题能稳定的经过重启复现，这对于修bug的同窗将会是个天大的好消息。

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

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

JVM级别数据

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

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

系统级别数据

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

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

Part 3

Java故障案例分析

故障1CPU load太高

问题通常是指CPU使用率很高，可是系统并无很繁忙，通常有两种情形。

状况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工具)

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

这个问题又两个层面，一个是应用的性能降低了，这通常是来自监控系统或者用户忽然的报警。从分割问题的角度看，性能降低通常是和以前时间点比较得出的结论，那么就确定有一个分水岭，在某一个时间点（一般是一个改动发生的时候）以后就会开始性能降低。因此初始的解决方案比较简单，就是找到改动发生的时间点，挑出形成性能降低的改动，而后分析这个改动为何会形成性能降低。

但是若是就是一个应用性能较差的问题，就比较棘手了，这个一般意味着没有能够比较的时间点，至关于凭空设定一个性能指标，将系统性能优化提高到这个目标。通常这是一个须要多方合做，修改多个层次的代码、配置才能达到的目标。一般而言能够继续尝试profiling Java应用，分析性能瓶颈，优化瓶颈部分。

可能有影响的瓶颈包括：

锁

这个通常须要设计、代码层面的改动，使用更高效的加锁机制，减轻竞争，等等。

GC

频繁full gc的又有两种状况，一种是说full gc完了以后整个heap仍是没有不少的可用空间，通常是多是因为最大heap上限可能设置有点儿小了，或者应用有内存泄露，须要作个heap dump具体分析下内存里面各个部分的使用状况。

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

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

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。

故障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了。

目前的现实是不少第三方的库确实直接使用了Unsafe去实现各类“高效”的操做，随便搜索下Github就能够看到大量的开源Java、Scala库使用了JDK提供的unsafe类

对于crash的情形，须要收集的信息包括各类dump，最关键的是系统core dump，方便未来使用GDB作过后分析，在linux上通常须要使用ulimit –c unlimited 命令修改core文件尺寸上限才行。

有了core dump，剩下的分析通常都是使用GDB继续了，crash的情形通常反而比较直观。若是不是unsafe、本身jni引发的crash问题，恭喜你，真的发现bug了，这个问题直接给Oracle或者java社区报bug吧。

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

-XX:-PrintCommandLineFlags

Q & A

Q1：关于内存泄露，是否是能够用一些开源产品来加探针，这方面有没有好的建议?

A1：内存泄露其实有两个方面，若是是native的malloc泄露，能够经过 valgrind，jemalloc等工具发现，这个和传统c++应用内存同样的；对于某些由于强引用链没法释放的java对象，通常都是 heapdump以后使用eclipse的mat工具分析“可能泄露的”，由于程序并无结束，并且还持有强引用，很可贵出结论说某些对象是否是内存泄露。

Q2：关于内存泄露, 怎么定位到具体代码？

A2：定位到代码目前比较可行的，就是用MAT分析出那些类型的对象发生了泄露,而后去扫描代码看看这些对象在哪里分配的，固然若是大量的string，byte.就很差办了，通常是以用户应用自定义的类为线索去查找。这样能够大大下降工做量。

讲师介绍：陆传胜

现就任于阿里巴巴技术保障部JVM组，主要工做是阿里巴巴定制化JDK的开发，以及相关的Java技术支持。
曾就任于IBM Java技术中心，负责IBMJDK开发、参与OpenJDK社区，是OpenJDK jdk8项目committer。
联系方式chuanshenglu@gmail.com