Java服务突然失败：A fatal error has been detected by the Java Runtime Environment的总结

阅读原文时间：2023年07月09日阅读：1

控制台中的错误信息

A fatal error has been detected by the Java Runtime Environment:

EXCEPTION_ ACCESS. _VIOLATION (0xc0000005) at pc=0x0000003aec715， pid=12424， tid=0x0000000002260

JRE version: Java(TM) SE Runtime Environment (8.0_ 241-b07) (build 1.8.0_ 241-b07)
Java VM: Java HotSpot(TM) 64-Bit Server VM (25.241-b07 mixed mode windows- amd64 compressed oops)
Problematic frame:
C [pLcommpro . dll+0xc715]

Failed to write core dump. Minidumps are not enabLed by default on client versions of Windows

An error report file with more information is saved as:
C: \Users \11193574\Desktop\smartarea\hs_ err_pid12424.log

If you would like to submit a bug report, pLease visit:
http://bugreport. java . com/ bugreport/crash. jisp
. The crash happened outside the Java Virtual Machine in native code .

See probLematic frame for where to report the bug.

下面的方法全部都是自己一个一个试的，可能解决不了我的问题，但是说不定能解决你们的

1.尝试添加 -XX:+CreateMinidumpOnCrash

个人感觉其中最重要的就是

Failed to write core dump. Minidumps are not enabLed by default on client versions of Windows

无法写入核心转储。默认情况下，在客户端版本的Windows上不启用小型转储

解决：

要让HotSpot VM在client版Windows上写出minidump，我们可以先在配置文件idea64.exe.vmoptions（位置：你安装的idea文件夹/bin中）设置 -XX:+CreateMinidumpOnCrash，这样HotSpot VM在crash时就会调用Windows的MiniDumpWriteDump()函数写出minidump

更改以后重启idea，等待一段时间看看效果

崩了，但是也没看见啥minidump，但是项目倒是不崩了？

十分钟过去了，没有什么失败问题出现，或许解决了？

然而并没有，他还是自己挂了，wuwuwu

2.降低jdk版本

那么看来就是重点位置搞错了，或许是这部分？

JRE version: Java(TM) SE Runtime Environment (8.0_ 241-b07) (build 1.8.0_ 241-b07)
 Java VM: Java HotSpot(TM) 64-Bit Server VM (25.241-b07 mixed mode windows- amd64 compressed oops)

看了一下网上的教程，得试试降低jdk版本了，目前的jdk版本是1.8.0-241，看看有没有小版本可以用

如果遇到这个问题需要重新下载旧版本的jdk的时候，别从网上奇奇怪怪的地方下载，直接官网就能下，详细：从官网下载历史版本的java - DbWong_0918 - 博客园 (cnblogs.com)

下载1.8.0-191版本的java，进行安装，配置完环境更改idea项目中使用的jdk，然后重启项目

等待，看看过十五分钟还会不会自己挂掉

半个小时了，还没有挂，估计是成功了

还是挂了，我真的@#￥%@……@#￥@#￥#@%……@#

问了一下带我的师傅，说之前调了一下jvm就好了不少，试试

3.在idea中更改jvm内容

参考了这个

在虚拟机选项中添加

-XX:CompileCommand=exclude,org/hibernate/cfg/annotations/SimpleValueBinder，setType

然后再试试

还是会崩，不过久了一些，一个小时左右了可以

4.jvm内存调优

进行jvm调优

将堆大小给设置为

-Xms512m -Xmx1024m

可以参考jvm内存

重新运行以后，明显存活时间变长了，放了一晚上都没事儿，但是修改完东西重启项目的时候，不到半分钟，自己又崩了

难顶啊xdm

5.Tomcat和环境的版本

要保证 Tomcat 和使用的DLL版本是一致的

首先在命令行cd到安装的tomcat文件夹/bin下

然后直接输入-version

在下面的信息中就能看到对应的版本

但是咋说呢，我的本来就是一致的，所以对我来说也没啥用

6.回收手法问题导致内存溢出

看了看日志，怀疑是GC方面的问题

对日志的解读参考了JVM崩溃的原因及解决！

官方的参考Oracle的参考

看一下自己的是哪种

直接在命令行输入

java  -XX:+PrintCommandLineFlags  -version

然后我们就得到了响应的信息

-XX:InitialHeapSize = 268427072
-Xx:MaxHeapSize=4294833152
-XX:+PrintCommandLineFlags
-XX:+UseCompressedClassPointers
-XX:+UseCompressedOops
-XX:-UseLargePagesIndividualAllocation
-XX:+UseParallelGC
java version "1.8.0_ 241"
Java(TM) SE Runtime Environment (build 1.8.0 241-b07)
Java HotSpot(TM) 64-Bit Server VM (build 25.241-b07, mixed mode)

-XX:+UseParallelGC就说明了，新生代使用ParallerGC，老年代使用Serial Old（串行收集器）

好像默认就是使用这种类型的GC算法

在项目启动的时候的运行-编辑配置-环境-虚拟机选项中添加