服務啟動以后過段時間自動失敗：A fatal error has been detected by the Java Runtime Environment
控制台中的錯誤信息
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算法
在項目啟動的時候的運行-編輯配置-環境-虛擬機選項中添加
-XX:+UseParallelOldGC
將老年代的垃圾收集器配置為並行收集
重啟項目試試
可惜還是不行
7.代碼問題
這個我應該也不是，畢竟是一個已經上線的項目，代碼方面應該是沒有什么問題的，不然也不會隨機時間報錯了
8.plcommpro.dll文件有問題？
從Problematic frame:C [pLcommpro.dll+0xc715]能大概看出來是關於plcommpro.dll的錯誤
然而這個文件就算有問題也不太敢動
晚點自己試試
以上就是嘗試過的所有的方法，可惜目前還是沒有完全解決我的問題，但是已經比最開始呆的時間久了太多太多，自行尋找尋找，看看有沒有完全解決的方式