归档日志多个线程同时读取解析会把jvm程序拖垮，直接崩溃

Current thread (0x0000fff9d0009800): JavaThread "xxl-job-trigger-fast-6" daemon [_thread_in_native, id=4092896, stack(0x0000fff79e600000,0x0000fff79e800000)]

siginfo: si_signo: 11 (SIGSEGV), si_code: 1 (SEGV_MAPERR), si_addr: 0x000000000000002c

Registers:

R0=0x0000fff79e7fd630

R1=0x0000fff7700024b0

R2=0x0000fff770002570

R3=0x0000000000000000

R4=0x0000000000000000

R5=0x0000000000000000

R6=0x0000000000000000

R7=0x0000000000000000

R8=0x0000000000000065

R9=0x0000000000000001

R10=0x0000000000000001

R11=0x0000000000000001

R12=0x0000000000000000

R13=0x0000fff7700013f8

R14=0x0000fff770001420

R15=0x0000000000000004

R16=0x0000fff7579c7cd8

R17=0x0000fff756b7c2b0

R18=0x0000fff770002538

R19=0x0000fff770000f50

R20=0x0000000000000004

R21=0x0000fff79e7fd630

R22=0x0000fff7700011e0

R23=0x0000000000000001

R24=0x0000fff7700024b0

R25=0x0000000728e7b4d0

R26=0x0000fff79ed8d500

R27=0x0000000000000000

R28=0x0000fff9d0009800

R29=0x0000fff79e7fd5f0

R30=0x0000fff756b3b3c8

Top of Stack: (sp=0x0000fff79e7fd5f0)

0x0000fff79e7fd5f0: 0000fff79e7fdc50 0000fff756b3b488

0x0000fff79e7fd600: 0000fff75835b000 0000fff79e7fdca8

0x0000fff79e7fd610: 0000fff770000f50 0000000000000001

0x0000fff79e7fd620: 0000000000000000 0000fff79e7fdd38

0x0000fff79e7fd630: 0000fff7003e73e0 00000000ffffffff

0x0000fff79e7fd640: 0000000000000000 0000fff9d0009800

0x0000fff79e7fd650: 0000000000000000 0000000000000000

0x0000fff79e7fd660: 0000000000000000 0000000000000000

0x0000fff79e7fd670: 0000000000000000 0000000000000000

0x0000fff79e7fd680: 0000000000000000 0000000000000000

0x0000fff79e7fd690: 0000000000000001 0000000000000000

0x0000fff79e7fd6a0: 0000000000000000 0000000000000000

0x0000fff79e7fd6b0: 0000000000000000 0000000000000000

0x0000fff79e7fd6c0: 0000000000000000 0000000000000000

0x0000fff79e7fd6d0: 0000000000000000 0000000000000000

0x0000fff79e7fd6e0: 0000000000000000 0000000000000000

0x0000fff79e7fd6f0: 0000000000000000 0000000000000000

0x0000fff79e7fd700: 0000000000000000 0000000000000000

0x0000fff79e7fd710: 0000000000000000 0000000000000000

0x0000fff79e7fd720: 0000000000000000 0000000000000000

0x0000fff79e7fd730: 0000000000000000 0000000000000000

0x0000fff79e7fd740: 0000000000000000 0000000000000000

0x0000fff79e7fd750: 0000000000000000 0000000000000000

0x0000fff79e7fd760: 0000000000000000 0000000000000000

0x0000fff79e7fd770: 0000000000000000 0000000000000000

0x0000fff79e7fd780: 0000000000000000 0000000000000000

0x0000fff79e7fd790: ffffffffffffffff 0000000000000000
都是这种报错 deepseek告知原因
这不是 JVM 自身的缺陷，而是达梦数据库的本地库 libdmlogmnr_client.so 内部发生的内存访问错误，导致 JVM 进程被系统强制终止。崩溃发生在该库的 mem_heap_free_heap_top 函数中，访问了非法内存地址 0x2c（空指针偏移 44 字节），属于典型的 native 代码空指针解引用。

核心证据链
崩溃现场的关键信息是明确的：

信号与地址：SIGSEGV，si_addr: 0x000000000000002c。0x2c 是极小的地址，几乎可以断定是空指针（或接近空的野指针）加上结构体字段偏移后的结果。

问题帧：C [libdmlogmnr_client.so+0x31c2b4] mem_heap_free_heap_top+0x4。C 表示 native 代码，库名和函数名指向了达梦的日志挖掘（logmnr）客户端库。

Java 调用栈：崩溃线程正在执行 com.dameng.logmnr.LogmnrDll.endLogmnr，业务代码位于 com.gdky.task.service.impl.DaMeng.DMLogReadUtils.analysisSqlFromLog。这是一个通过 JNI 调用达梦本地库解析数据库日志（可能是归档日志或重做日志）的场景。

日志中有一句关键提示："The crash happened outside the Java Virtual Machine in native code." 这直接排除了 HotSpot JIT 编译或 GC 导致崩溃的可能。

为什么是达梦库的问题
mem_heap_free_heap_top 这个函数名表明，达梦的 native 库在调用 endLogmnr 时，正在执行某种内部堆内存的清理操作。崩溃原因大概率是：

重复释放：同一块内存被 endLogmnr 释放了两次。

释放未初始化/已损坏的指针：库内部状态管理出现错误，导致 mem_heap_free_heap_top 收到了一个无效的堆结构指针。

注意：虽然达梦数据库（服务器端）的 signal 11 可能涉及 core 文件分析，但此处的崩溃发生在 JVM 进程内的客户端库，与数据库服务器进程的稳定性无关。问题出在达梦提供的 JNI 封装库 libdmlogmnr_client.so 上，而非数据库内核。

排查建议
由于问题位于达梦的闭源 native 库，应用侧无法直接修复。建议按以下步骤推进：

检查达梦版本匹配性：确认 libdmlogmnr_client.so 的版本与数据库服务端版本是否一致。混用不同版本的客户端库和服务端是导致这类内存错误的常见原因。

向达梦技术支持反馈：提供完整的 hs_err_pid 日志文件和 core dump（如果已生成）。达梦官方需要根据库内部的符号信息来定位 endLogmnr 的具体缺陷。

审视调用逻辑：检查 DMLogReadUtils.analysisSqlFromLog 方法中 endLogmnr 的调用时机。是否可能存在重复调用、在未成功初始化时就调用结束操作、或多线程并发调用同一句柄的情况。你提供的日志中还有多个 xxl-job-trigger-fast 线程同时处于 _thread_in_native 状态，需确认是否存在并发访问达梦 logmnr 句柄的可能性。

临时规避：如果该功能非核心链路，可考虑在业务代码中捕获 native 调用可能引发的异常（尽管 JVM 崩溃无法被 Java 层捕获），或通过重试机制在进程崩溃后自动拉起。但这只是权宜之计。

总结：根本原因在达梦的 native 库内部，需要达梦官方修复。你的业务代码侧可以检查调用方式是否正确，但无法从根本上解决库自身的缺陷

请问是这样吗