JVM Crash的定位和解决办法

最新推荐文章于 2023-07-31 09:54:49 发布
最新推荐文章于 2023-07-31 09:54:49 发布
阅读量1.6k 收藏 4
点赞数 1
分类专栏： JAVA 文章标签： java 开发语言
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/kang389110772/article/details/125177427
版权

Crash的原因

在日常的环境中，我们偶尔也会遇到JVM Crash，与普通的错误问题不同，想要明白JVM为什么Crash是有一定难度的，所以今天我根据知识和自己的经验进行总结一下，希望也可以帮助到你。

引起Crash的直接原因可以分为两类: 代码bug和内存溢出。代码bug不仅仅指应用的代码，在Oracle官网上一共分成下面几类:

有了这些原因，我怎么知道JVM是为什么Crash的呢? 不要着急，其实想要定位到直接原因非常简单，也就是下面我们要讲的定位手段。

定位手段

代码问题:

就像定位其他问题一样，JVM给我们提供了一个很直观的Crash日志，名字叫Fatal Error Log。

Fatal Error Log通过参数-XX:ErrorFile=参数指定要生成的位置，如果没有指定，那么就默认在进程的目录生成。

内存问题:

如果通过JVM监控发现是内存的问题，那么建议增加-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/xxxx/Logs 两个参数，当内存溢出的时候就会生成dump文件，让我们来分析内存泄露的情况。

光说不练假把式，下面我们结合实际案例来学习一下。

实际案例

代码案例 - JVM编译代码报错

Crash现场日志

Crash日志:

# A fatal error has been detected by the Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0x00007ff058953325, pid=46096, tid=140667078522624
#
# JRE version: Java(TM) SE Runtime Environment (8.0_20-b26) (build 1.8.0_20-b26)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (25.20-b23 mixed mode linux-amd64 compressed oops)
# Problematic frame:
# V [libjvm.so+0x858325] LoadKlassNode::make(PhaseGVN&, Node*, Node*, TypePtr const*, TypeKlassPtr const*)+0x45
#
# Core dump written. Default location: /home/export/Domains/xxxxxxxx/server1/bin/core or core.46096
#
# An error report file with more information is saved as:
# /home/export/Domains/xxxxxxxx/server1/bin/hs_err_pid46096.log
#
# Compiler replay data is saved as:
# /home/export/Domains/xxxxxxx/server1/bin/replay_pid46096.log
#
# If you would like to submit a bug report, please visit:
# http://bugreport.sun.com/bugreport/crash.jsp
#

顶层堆栈：


# Problematic frame:

# V [libjvm.so+0x858325] LoadKlassNode::make(PhaseGVN&, Node*, Node*, TypePtr const*, TypeKlassPtr const*)+0x45

在/home/export/Domains/xxxxxxxx/server1/bin/hs_err_pid46096.log中可以找到当时进程的具体报错详情:

Java Threads: ( => current thread )

  

--------------- P R O C E S S ---------------

  
  

C2:10611752 25130 ! 4 com.xxx.xxx.xxx.xxx::onMessage (570 bytes)

Current CompileTask:

  
  

C [libpthread.so.0+0x7e65] start_thread+0xc5

V [libjvm.so+0x8e75f8] java_start(Thread*)+0x108

V [libjvm.so+0xa29a3c] JavaThread::run()+0x11c

V [libjvm.so+0xa2990f] JavaThread::thread_main_inner()+0xdf

V [libjvm.so+0x49e420] CompileBroker::compiler_thread_loop()+0x620

V [libjvm.so+0x49ba4a] CompileBroker::invoke_compiler_on_method(CompileTask*)+0xc8a

V [libjvm.so+0x3e67e8] C2Compiler::compile_method(ciEnv*, ciMethod*, int)+0x198

V [libjvm.so+0x4931cc] Compile::Compile(ciEnv*, C2Compiler*, ciMethod*, int, bool, bool, bool)+0x126c

V [libjvm.so+0x3e7d09] ParseGenerator::generate(JVMState*, Parse*)+0x99

V [libjvm.so+0x90fd58] Parse::Parse(JVMState*, ciMethod*, float, Parse*)+0x7b8

V [libjvm.so+0x90b967] Parse::do_all_blocks()+0x127

V [libjvm.so+0x90b6f0] Parse::do_one_block()+0x180

V [libjvm.so+0x908b0a] Parse::do_exceptions()+0xba

V [libjvm.so+0x551cb6] Parse::catch_inline_exceptions(SafePointNode*)+0x946

V [libjvm.so+0x858325] LoadKlassNode::make(PhaseGVN&, Node*, Node*, TypePtr const*, TypeKlassPtr const*)+0x45

Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)

Stack: [0x00007fef9b2f4000,0x00007fef9b3f4000], sp=0x00007fef9b3f0d20, free space=1011k

Crash分析

首先是对信号的分析。下面这个是信号的字段解释说明，从信号类型(SIGSEGV)来看，我们是访问内存失败导致的Crash。可以通过下面两个链接了解更多的内容。

  1. SIGSEGV的解释
  2. 信号说明
#  SIGSEGV (0xb) at pc=0x00007ff058953325,pid=46096, tid=140667078522624
      |      |           |                    |         +--- thread id
      |      |           |                    +------------- process id
      |      |           +--------------------------- program counter
      |      |                                        (instruction pointer)
      |      +--------------------------------------- signal number
      +---------------------------------------------- signal name

接下来是对堆栈的分析。V代表了VM Frame。


# Problematic frame:

# V [libjvm.so+0x858325] LoadKlassNode::make(PhaseGVN&, Node*, Node*, TypePtr const*, TypeKlassPtr const*)+0x45
  |              +-- Same as pc, but represented as library name and offset.
  |                  For position-independent libraries (JVM and most shared
  |                  libraries), it is possible to inspect the instructions
  |                  that caused the crash without a debugger or core file
  |                  by using a disassembler to dump instructions near the
  |                  offset.
  +----------------- Frame type

Frame的Type类型如下。尝试去做一下翻译，但是总觉得还是原文比较好。

Frame TypeDescription
CNative C frame
jInterpreted Java frame
VVM frame
vVM-generated stub frame
JOther frame types, including compiled Java Frames

最后是Crash的线程信息:

可以看到基本都是和C2有关。

解决手段

通过对上述信息的搜索，怀疑是JVM在JIT编译的时候出现了问题。具体的BUG链接JDK-6675699，经过优化后的代码，在循环的时候会访问到非法的地址。

修复的方法也很简单:

  1. 禁用JIT编译
  2. 升级JDK到8u40以上

我们采用的是升级JDK，而随后的表现也被证明的确解决了该问题。

内存泄露 - 超级大的年轻代

现象
在JVM启动后运行一段时间，就会自动挂掉。

分析
从JVM监控上看，没有YGC和FullGC的出现，内存是一直在涨，导致最后申请不到内存而挂掉。通过没有GC，就可以知道是内存设置的问题，所以就去检查了xms和Xmx的设置。

原因
因为容器本身内存比较大，16G内存，所以在设置Xmx的时候误将14G写成140G，所以导致内存使用一直在上涨，直到最终失败。

解决手段
把内存设置为14G，解决问题。

虽然这个内存泄露看起来很简单，不太正经，下面这个就是正经的内存泄露了。

延伸阅读

140G的年轻代有多大呢? 按照默认的是1:2，然后计算下来大约是46G。命名是16G内存的机器，为什么能够启动成功呢?

在staickoverflow上找到一个回答:

至少在Sun 64位的Window版本上，ObjectStartArray::initialize将512字节使用1个字节来表示占用。使用35TB的堆将导致VM需要立即分配70GB，所以这个启动失败了。
但在32位 VM上，在计算最大堆内存的时候，并不会关心物理内存有多少，在Windows和Linux上它被限制在2GB左右，在Soloaris上被限制在4GB左右，如果超过这个数值，那么在启动的时候就会立即失败。
如果你开始考虑设置对的最大可用内存这件事情，你会发现去考虑物理内存并不会有多大的意义。 X GB的物理内存并不会代表有X GB的内存可以给VM去使用，物理内存是被其他进程共享的，因此VM需要找到一个方法来解决堆内存的需求要比实际可用的内存多这个情况。如果VM没有崩溃，但是在分配时无法申请到更多的物理内存，那么就会抛出OutOfMemoryErrors异常。

总结下来是在说:

  1. 因为物理内存的最大可用是不稳定的，所以VM允许申请更大的内存，如果内存分配失败，那么就抛出来OutOfMemoryErrors。

  2. 但这个更大又不是绝对无意义上的大，在本机(macos)的实验上，超过512倍并不会失败，但是乘以10就会失败，也证明了是有上限的。

原链接: [Why am I able to set -Xmx to a value greater than physical and virtual memory on the machine on both Windows and Solaris?](https://stackoverflow.com/questions/1949904/why-am-i-able-to-set-xmx-to-a-value-greater-than-physical-and-virtual-memory-on)

内存泄露 - 三方图片导致内存泄露

现象
解决了超级大的年轻代问题后，但是发现JVM在运行过一段比较长的时间又会Crash。

分析

通过JVM监控发现内存这次使用的很正常，在缓缓上涨然后YGC和FullGC都有，不正常的是在最后Crash的时候，发现JVM一直在FullGC，但是内存却下不去。

去配置的目录中，找到生成内存溢出生成的dump文件，可以判断是内存溢出了。遇见内存溢出不可怕，好的工具能够事半功倍，这里推荐用JProfiler，的确好用很多。

使用JProfiler打开生成的dump文件，首先按Class的大小排序，可以看到是byte[]数组占用最大。
在这里插入图片描述

接下来，可以通过byte[]数据的引用是谁来发现问题。通过incoming reference可以发现基本上都会有java.awt.image.BufferedImage

在这里插入图片描述
发现了可疑对象，但这个类是sun的类，按道理不会出问题，所以我们要怀疑它的持有者，通过merged-incoming-reference可以看到都是org.fit.cssbox.layout.ImageCache，这个类是我们为了图片转换引入的类。

在这里插入图片描述

通过看它的源码，印证了这个结论。这个三方包在图片转换中，会有一个全局的map，只进不出，所以在转换的数量越多，它占用的空间就越大。

解决手段

  1. 在src包下新建相同路径相同名称的类，这样因为tomcat的classloader顺序，就会使用这个class
  2. 因为没有在文档和代码发现明显的不缓存配置选项，需要fork之后自己修改一下。

延伸拓展

通常我们说内存泄露，就是指堆的异常，但并不是只有堆上出了问题才会导致内存溢出。下面还有几种类型:

  1. GC占用时间异常。 Exception in thread thread_name: java.lang.OutOfMemoryError: GC Overhead limit exceeded。
  2. array这种内存连续的申请过大。Exception in thread thread_name: java.lang.OutOfMemoryError: Requested array size exceeds VM limit
  3. 元数据空间。 Exception in thread thread_name: java.lang.OutOfMemoryError: Metaspace
  4. 系统申请内存错误。Exception in thread thread_name: java.lang.OutOfMemoryError: request size bytes for reason. Out of swap space?
  5. 这个是指在64位机器上，可以使用32位的方式来代表Class元数据，这个空间的大小是被CompressedClassSpaceSize来控制的。Exception in thread thread_name: java.lang.OutOfMemoryError: Compressed class space。
  6. 这个是指JNI方法申请内存失败。Exception in thread thread_name: java.lang.OutOfMemoryError: reason stack_trace_with_native_method

更多的请点击这里

一点心得

对于内存泄露来说，我们可以从网上看到很多文章，比较多的是在说可以直接找到三方或者自己应用的类，但真实的情况比这个要复杂很多。可能看不到三方的类，也可能计算出来的大小并不对，heap是否经过gc后的大小等等问题，都让假设验证这样的模式成为最佳的解决手段。

sutonline
关注
  • 1
    点赞
  • 踩
  • 4
    收藏
    觉得还不错? 一键收藏
  • 1
    评论
专栏目录
美团JVM问题定位和排错
04-21
美团JVM问题定位和排错
JVM crash 错误日志分析
04-02
NULL 博文链接：https://myspace1916.iteye.com/blog/1441465
jvm瓶颈定位 java jvm 学习
03-09
jvm瓶颈定位 java jvm 学习
JVM问题定位的典型案例分析
12-25
JVM问题定位的典型案例分析
jvm crash的崩溃日志详细分析及注意点
08-30
本篇文章主要介绍了jvm crash的崩溃日志详细分析及注意点。具有很好的参考价值，下面跟着小编一起来看下吧
jvm crash 的原因以及解决办法
大漠孤狼的博客
07-11 8301
java内存 JVM 虚拟机 hs_err_pid
Java JVM致命错误日志（hs_err_pid.log）分析
最新发布
IccBoY_超越
07-31 1632
当jvm出现致命错误时，会生成一个错误文件 hs_err_pid.log，其中包括了导致jvm crash的重要信息，可以通过分析该文件定位到导致crash的根源，从而改善以保证系统稳定。当出现crash时，该文件默认会生成到工作目录下，然而可以通过jvm参数指定生成路径（JDK6中引入）：1该文件包含如下几类关键信息：日志头文件导致crash的线程信息所有线程信息安全点和锁信息堆信息本地代码缓存编译事件gc相关记录jvm内存映射jvm启动参数服务器信息。
spring boot项目启动报错
xilin6664的博客
02-10 1763
错误信息: Server initialized with port: 8000 2020-02-10 17:42:57.718 INFO 6352 --- [ main] org.eclipse.jetty.server.Server : jetty-9.4.8.v20171121, build timestamp: 2017-11-22T05:27:...
jvm crash 的原因及解决办法
qq_46416934的博客
04-19 827
最近部署服务器时，总是会出现jvm fatal error 导致tomcat崩溃无法正常启动，以下是错误信息 Java代码 [这里是图片001] #AfatalerrorhasbeendetectedbytheJavaRuntimeEnvironment: #InternalError(c1_Optimizer.cpp:271),pid=1196,tid=4412 #guarantee(x_compare_res!=Constant::not_comparable)failed:incom
JVM崩溃的原因及解决方法
MayMatrix 的博客
11-15 9279
Java的应用有时候会因为各种原因Crash，这时候会产生一个类似java_errorpid.log的错误日志。可以拿到了 这个日志，怎样分析Crash的原因呢？下面我们来详细讨论如何分析java_errorpid.log的错误日志。 一. 如何得到这个日志文件 如果有一个严重的错误引起Java进程非正常退出，我们叫Crash，这时候会产生一个日志文件。缺省情况下，这个 文件会产生在工作目
jvm开发笔记4---jvm crash信息处理
Shawn
12-04 844
ajvm是一个笔者正在开发中的java虚拟机， 用c和少量汇编语言编写， 目的在于探究一个可运行的java虚拟机是如何实现的， 目前整个jvm的source code代码量在5000行左右， 预计控制在1w行以内，只要能运行简单的java代码即可。笔者希望ajvm能变成一个教学用的简单java虚拟机实现， 帮助java程序员在陷入庞大的hotspot vm源码之前， 能对jvm的结构有个清晰的认识
JVM crash错误日志(hs_err_pid.log)分析
Keix
07-22 1172
当jvm出现致命错误时，会生成一个错误文件hs_err_pid<pid>.log，其中包括了导致jvm crash的重要信息，可以通过分析该文件定位到导致crash的根源，从而改善以保证系统稳定。当出现crash时，该文件默认会生成到工作目录下，然而可以通过jvm参数指定生成路径（JDK6中引入）： -XX:ErrorFile=./hs_err_pid<pid>.log 该文件包含如下几类关键信息： 日志头文件 导致crash的线程信息 所有线程信息.
JVM崩溃
点点的博客
04-01 2837
最近两天测试环境有一个服务总是会挂（两到三天一次），JVM虚拟机总是会崩溃。所以有必要了解JVM崩溃的原因是什么。 当JVM发生致命错误导致崩溃时，会生成一个hs_err_pid_xxx.log这样的文件，该文件包含了导致 JVM crash 的重要信息，我们可以通过分析该文件定位到导致 JVM Crash 的原因，从而修复保证系统稳定。 默认情况下，该文件是生成在工作目录下的，当然也可以通过...
启动ElasticSearch报错--踩坑系列3
u014177484的博客
05-08 1331
内存不足 There is insufficient memory for the Java Runtime Environment to continue. #Native memory allocation (malloc) failed to allocate 1077616 bytes for Chunk::new An error report file with more inform...
jvm crash
qq_25931839的博客
07-26 225
https://blog.csdn.net/achilles12345/article/details/50887402 https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8014189
jvm crash 分析
yuhui666666的博客
03-29 244
今天tomcat的jvm崩了，一直jvm崩掉，每次也就看了一下内存区域，判断大概是内存问题，今天决定好好分析一下，整理了网上的一些资料。     1.crash文件      如果有一个严重的错误引起Java进程非正常退出，我们叫Crash，这时候会产生一个日志文件。生成在工作目录下，名字为 hs_err_pidxxxx.log,可以修改配置来改变 java -XX:ErrorFile=/var...
解决——》There is insufficient memory for the Java Runtime Environment to continue
小仙~
07-25 3390
Java 运行时环境没有足够的内存来继续执行程序。 以下是常见的几种原因（具体原因可能因应用程序、系统环境和配置而异）： 1. 分配给 JVM 的堆内存不足：无法容纳程序所需的数据和对象 2. 系统内存不足：可能是因为其他运行中的程序占用了过多的内存 3. 内存泄漏 4. 大对象或复杂操作 5. JVM 参数设置不合理：堆内存分配、垃圾回收机制
Android性能优化：你的一些使用细节可能会引起严重的内存泄漏！
weixin_44339238的博客
02-26 357
前言 在Android中，内存泄露的现象十分常见；而内存泄露导致的后果会使得应用Crash。常见引发内存泄露原因主要有： Static关键字修饰的成员变量 非静态内部类 / 匿名类 日常使用（Context、WebView等） 今天，我将详细介绍日常的使用会导致的内存泄露，主要包括：集合类、资源对象使用后未关闭、Context、WebView和Adapter。 知识储备 a. 内存...
JVM 系列一：Native memory allocation 导致JVM Crash
05-19
在Java应用程序中，JVM是一个非常重要的组成部分。JVM是负责执行Java字节码的虚拟机，它提供了一种独立于平台的执行环境，使得Java程序可以在不同的操作系统上运行。然而，有时候我们会遇到一些JVM Crash的问题，其中一个常见的原因就是Native memory allocation导致的。 Native memory allocation是指Java程序在执行过程中需要使用到本地内存，比如说调用本地库、使用JNI等。JVM在执行过程中会为Java程序分配一定的内存空间，这些内存空间是属于JVM的堆外内存，也称为直接内存。 当Java程序使用的直接内存超过了JVM指定的最大直接内存限制时，就会出现Native memory allocation导致的JVM Crash。这种情况下，JVM会尝试将直接内存清空，但如果清空过程中出现错误，JVM就会崩溃。 为了避免Native memory allocation导致的JVM Crash，我们可以通过以下几种方式进行优化： 1. 增加JVM的最大直接内存限制，可以通过参数“-XX:MaxDirectMemorySize”来设置。 2. 减少Java程序使用的直接内存，可以通过改进代码、减少使用本地库等方式来实现。 3. 监控直接内存的使用情况，及时发现异常情况并做出相应的处理。 总之，Native memory allocation是一个很重要的问题，需要我们在开发Java应用程序时引起足够的重视。

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 1
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值