基于AI的JVM崩溃日志分析

背景

项目上出现了系统宕机，检查发现服务进程已经不存在，JVM直接退出。

如果JVM主动退出，在标准产品的bin目录下会生成一份hs_err_pidxxxx.log的文件，本次我们也获得了崩溃的日志文件：

我们尝试通过AI的形式来分析崩溃日志的根源。

操作步骤

第一步，我们通过Notepad++之类的文本编辑器打开hs_err_pidxxxx.log文件，由于AI一次可识别的内容不多，我们尝试分块来喂给AI，从AI侧获得答案。

先将红框中这一区块的内容发送给AI，从AI的回复结果看，关键问题可能是：这表明问题与sun.misc.Unsafe类的本地方法实现有关，可能是通过Unsafe.putAddress()等方法直接操作内存导致的。

第二步，我们尝试将下一区块的内容发送给AI，得到了进一步的分析答案：AI怀疑Java层通过 Unsafe.putAddress() 向地址 0x0 写入数据，触发空指针访问。

第三步：接着再发送内容，下一段日志就已经到问题调用堆栈了。我们将内容推送给AI之后，AI给出了肯定的答案：可以明确锁定到具体引发崩溃的业务代码位置。

此时就可以根据这段分析上报研发或客开来判断是谁的问题，并且根据具体代码位置做对应的整改。

精确位置：在 ErpRestMananger.checkAttr() 方法的第101行代码处调用了 Unsafe.putAddress() 方法
调用链：
ErpDataRest.erpDataAdd()
→ ErpRestMananger.Load()
→ ErpRestMananger.loadConfig()
→ ErpRestMananger.checkAttr() // 崩溃点

AI的处理结论也非常清晰，完全可以将结论推送给开发做参考解决：

我们甚至可以咨询AI，有什么行之有效的代码整改意见：

扩展知识

由于AI对超大文本解析能力有限，我们只能一段一段推送日志给AI循序渐进分析，日志也不是很结构化，新手在推送AI时可能会弄错。那么我们建议通过CrashAnalysis这类工具先对日志做提炼，再将提炼后的结果交给AI分析，工具的分析下载方法访问如下链接：系统崩溃日志hs_err_pid快速分析方法https://open.seeyoncloud.com/#/faq/faq/v1/share?url=Z2JySmU+Nzg5

我们可以逐个页签，将内容拷贝给AI，尤其是“线程信息”、“运行过程信息”部分推送给AI，也能得到准确的答案。

编撰人：het

快速跳转

• 基于AI的JVM崩溃日志分析
  • 背景
  • 操作步骤
  • 扩展知识