高性能WEB开发
JVM挂掉后产生hs_err_pid文件，有什么方法确定是什么原因导致的吗
墨衍会员 · AI 创作全网分发 墨衍智能分发 通过墨衍一键同步至各平台 可同步平台 CSDN微信公众号微博知乎掘金百家号博客园抖音小红书 你的文章也可以这样分发 墨衍会员 ¥399起/年，写一次发全网
我也要 关注 + 加入社区最近实验室测试应用，连续两次jvm挂掉只产生了hs_err_pid文件，通过hs_err_pid文件分析业务实在困难，有什么办法知道jvm为什么突然挂掉吗？
1、两次jvm挂掉一次是跑了3天后的凌晨，一次是在跑了一天后的下午且两次打印的问题堆栈都不一样，因此怀疑跟业务代码有关
2、两次挂掉时候产生的hs_err_pid文件中的内存使用情况都属于正常，所以定位问题的方向很模糊
下面是两次hs_err_pid文件中显示的jvm崩溃的堆栈
Stack: [0x00007f8892995000,0x00007f8892a96000], sp=0x00007f8892a940e0, free space=1020k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V [libjvm.so+0x62b071] HeapRegionDCTOC::walk_mem_region(MemRegion, HeapWord*, HeapWord*)+0x91
V [libjvm.so+0x9eae33] DirtyCardToOopClosure::do_MemRegion(MemRegion)+0x113
V [libjvm.so+0x5cb578] ScanRSClosure::doHeapRegion(HeapRegion*)+0x318
V [libjvm.so+0x59b610] G1CollectedHeap::collection_set_iterate_from(HeapRegion*, HeapRegionClosure*)+0x30
V [libjvm.so+0x5caade] G1RemSet::scanRS(G1ParPushHeapRSClosure*, CodeBlobClosure*, unsigned int)+0xce
V [libjvm.so+0x5cae24] G1RemSet::oops_into_collection_set_do(G1ParPushHeapRSClosure*, CodeBlobClosure*, unsigned int)+0xe4
V [libjvm.so+0x5ce221] G1RootProcessor::scan_remembered_sets(G1ParPushHeapRSClosure*, OopClosure*, unsigned int)+0xa1
V [libjvm.so+0x5ae1e2] G1ParTask::work(unsigned int)+0x3f2
V [libjvm.so+0xaed0ff] GangWorker::loop()+0xcf
V [libjvm.so+0x92a728] java_start(Thread*)+0x108
第二次的
Stack: [0x00007efe2b183000,0x00007efe2b284000], sp=0x00007efe2b282050, free space=1020k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V [libjvm.so+0x9f1690] SparsePRT::add_card(int, int)+0x40
V [libjvm.so+0x63127a] OtherRegionsTable::add_reference(void*, int)+0x12a
V [libjvm.so+0x64ea04] InstanceKlass::oop_oop_iterate_nv(oopDesc*, FilterOutOfRegionClosure*)+0xb4
V [libjvm.so+0x62a2a6] HeapRegion::oops_on_card_seq_iterate_careful(MemRegion, FilterOutOfRegionClosure*, bool, signed char*)+0x2e6
V [libjvm.so+0x5c9f5c] G1RemSet::refine_card(signed char*, unsigned int, bool)+0x20c
V [libjvm.so+0x5cb045] RefineRecordRefsIntoCSCardTableEntryClosure::do_card_ptr(signed char*, unsigned int)+0x25
V [libjvm.so+0x565f5e] DirtyCardQueueSet::apply_closure_to_completed_buffer(CardTableEntryClosure*, unsigned int, int, bool)+0xce
V [libjvm.so+0x59d502] G1CollectedHeap::iterate_dirty_card_closure(CardTableEntryClosure*, DirtyCardQueue*, bool, unsigned int)+0x62
V [libjvm.so+0x5cae07] G1RemSet::oops_into_collection_set_do(G1ParPushHeapRSClosure*, CodeBlobClosure*, unsigned int)+0xc7
V [libjvm.so+0x5ce221] G1RootProcessor::scan_remembered_sets(G1ParPushHeapRSClosure*, OopClosure*, unsigned int)+0xa1
V [libjvm.so+0x5ae1e2] G1ParTask::work(unsigned int)+0x3f2
V [libjvm.so+0xaed0ff] GangWorker::loop()+0xcf
V [libjvm.so+0x92a728] java_start(Thread*)+0x108
两次挂掉时jvm参数都加了HeapDumpOnOutOfMemoryError，所用版本1.8.0_151
疑问：
1、这种情况jvm为啥不产生heapdump文件
2、对于jvm只产生hs_err_pid文件的还有什么定位手段
1、两次jvm挂掉一次是跑了3天后的凌晨，一次是在跑了一天后的下午且两次打印的问题堆栈都不一样，因此怀疑跟业务代码有关
2、两次挂掉时候产生的hs_err_pid文件中的内存使用情况都属于正常，所以定位问题的方向很模糊
下面是两次hs_err_pid文件中显示的jvm崩溃的堆栈
Stack: [0x00007f8892995000,0x00007f8892a96000], sp=0x00007f8892a940e0, free space=1020k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V [libjvm.so+0x62b071] HeapRegionDCTOC::walk_mem_region(MemRegion, HeapWord*, HeapWord*)+0x91
V [libjvm.so+0x9eae33] DirtyCardToOopClosure::do_MemRegion(MemRegion)+0x113
V [libjvm.so+0x5cb578] ScanRSClosure::doHeapRegion(HeapRegion*)+0x318
V [libjvm.so+0x59b610] G1CollectedHeap::collection_set_iterate_from(HeapRegion*, HeapRegionClosure*)+0x30
V [libjvm.so+0x5caade] G1RemSet::scanRS(G1ParPushHeapRSClosure*, CodeBlobClosure*, unsigned int)+0xce
V [libjvm.so+0x5cae24] G1RemSet::oops_into_collection_set_do(G1ParPushHeapRSClosure*, CodeBlobClosure*, unsigned int)+0xe4
V [libjvm.so+0x5ce221] G1RootProcessor::scan_remembered_sets(G1ParPushHeapRSClosure*, OopClosure*, unsigned int)+0xa1
V [libjvm.so+0x5ae1e2] G1ParTask::work(unsigned int)+0x3f2
V [libjvm.so+0xaed0ff] GangWorker::loop()+0xcf
V [libjvm.so+0x92a728] java_start(Thread*)+0x108
第二次的
Stack: [0x00007efe2b183000,0x00007efe2b284000], sp=0x00007efe2b282050, free space=1020k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V [libjvm.so+0x9f1690] SparsePRT::add_card(int, int)+0x40
V [libjvm.so+0x63127a] OtherRegionsTable::add_reference(void*, int)+0x12a
V [libjvm.so+0x64ea04] InstanceKlass::oop_oop_iterate_nv(oopDesc*, FilterOutOfRegionClosure*)+0xb4
V [libjvm.so+0x62a2a6] HeapRegion::oops_on_card_seq_iterate_careful(MemRegion, FilterOutOfRegionClosure*, bool, signed char*)+0x2e6
V [libjvm.so+0x5c9f5c] G1RemSet::refine_card(signed char*, unsigned int, bool)+0x20c
V [libjvm.so+0x5cb045] RefineRecordRefsIntoCSCardTableEntryClosure::do_card_ptr(signed char*, unsigned int)+0x25
V [libjvm.so+0x565f5e] DirtyCardQueueSet::apply_closure_to_completed_buffer(CardTableEntryClosure*, unsigned int, int, bool)+0xce
V [libjvm.so+0x59d502] G1CollectedHeap::iterate_dirty_card_closure(CardTableEntryClosure*, DirtyCardQueue*, bool, unsigned int)+0x62
V [libjvm.so+0x5cae07] G1RemSet::oops_into_collection_set_do(G1ParPushHeapRSClosure*, CodeBlobClosure*, unsigned int)+0xc7
V [libjvm.so+0x5ce221] G1RootProcessor::scan_remembered_sets(G1ParPushHeapRSClosure*, OopClosure*, unsigned int)+0xa1
V [libjvm.so+0x5ae1e2] G1ParTask::work(unsigned int)+0x3f2
V [libjvm.so+0xaed0ff] GangWorker::loop()+0xcf
V [libjvm.so+0x92a728] java_start(Thread*)+0x108
两次挂掉时jvm参数都加了HeapDumpOnOutOfMemoryError，所用版本1.8.0_151
疑问：
1、这种情况jvm为啥不产生heapdump文件
2、对于jvm只产生hs_err_pid文件的还有什么定位手段
...全文
相关推荐
JVM Crash，生成hs_err_pid.log文件
标题"JVM Crash，生成hs_err_pid.log文件"指的是Java虚拟机在运行过程中遇到了致命问题，导致其终止运行，并自动生成了一个错误日志文件。
JVM crash 错误日志分析
当JVM出现崩溃时，系统会产生一个名为“hs_err_pid.log”的错误日志文件，这个文件包含了关于崩溃时的详细信息。通过对这个日志的深入分析，我们可以找出问题的原因并采取相应的解决措施。
hs-err-pid19784.log
hs_err_pid19784.log，这是我的jvm报错文件，有人可以帮忙看下问题在哪吗，我要疯了
hs_err_pid10988.log
java进程崩溃日志以下为几种可能的原因：Java应用程序的问题：发生OOM导致进程Crash；JVM出错：JVM或JDK自身的Bug导致进程Crash;被操作系统OOM-Killer;
jvm crash的崩溃日志详细分析及注意点
默认情况下，日志会被保存在Java程序运行的当前目录下，文件名为`hs_err_pid.log`。
