Java程序崩溃原因分析：错误日志分析及解决（Cannot allocate memory）

悠悠 2024-04-01 13:32 27阅读 0赞

Java HotSpot(TM) 64-Bit Server VM warning: INFO: os::commit_memory(0x0000000513200000, 3075473408, 0) failed; error='Cannot allocate memory' (errno=12)
    #
    # There is insufficient memory for the Java Runtime Environment to continue.
    # Native memory allocation (mmap) failed to map 3075473408 bytes for committing reserved memory.
    # An error report file with more information is saved as:
    # /data/Projects/pick-task-assign-job/hs_err_pid5421.log

上面报错：Cannot allocate memory，不能分配内存；“内存不足，Java运行时环境无法继续。本地内存分配3075473408字节（3G）失败。错误信息存储在/data/Projects/pick-task-assign-job/hs\_err\_pid5421.log文件中”。

JVM出现的致命错误，会在默认工作目录下面生成了hs\_err\_pid.log 日志文件。其中包含了导致JVM crash 的重要信息（可以在虚拟参数中添加 -XX:ErrorFie=./hss\_err\_pid.log指定生成路径。）

## 问题原因总结及解决 ##

经过上面分析，复盘崩溃时的场景：1.项目启动时，未配置JVM内存分派，使用默认配置；默认配置是，初始堆大小是1G（默认物理内存的1/64），最大堆内存是16G（默认是物理内存的1/4）；堆内分年轻代和老年代，比例默认是1:2，所以当程序不断扩容后，年轻代最多占用5.33G，老年代最多占用10.66G。2.由于程序刚启动时使用的内存较小，随着程序的运行时间变成，开始执行minor gc和full gc做垃圾回收，由于存在cplex内存泄漏，每次都会有一部分内存因为泄漏回收不了，而且泄漏的内存越来越多，当已分配的堆内存不够用时，就扩容，直到16G堆内存全部分配完，程序出现奔溃。 3.但是根据日志，奔溃时，程序的内存内没有达到16G，所以JVM继续分配内存，此时正好有其他程序那一段时间内存使用很多(超过40%)，导致没有可用的物理内存分配了，最终程序奔溃。

### 1 外部原因及解决 ###

目前该机器上运行的程序比较多。可能有些程序使用内存过大，或者瞬时的内存使用过大，导致当前这个java程序在分派内存时，内存不够用，导致程序奔溃。

解决办法：

程序的所有人在启动程序时，最好对程序使用的资源做限制，并且经常查看项目运行的情况，做到在程序崩溃前预知风险，提前解决问题。  
最好能有相关报警。  
合理的将程序部署在四台机器上，不要把自己的所有服务都部署在同一台机器上。

### 2. 内部原因 ###

通过内存分析，发现有内存泄漏的可能；同时项目启动时最好预估内存使用情况并指定内存大小，尽量减少系统的自动扩缩容。

### 解决办法： ###

review代码，查看cplex部分是否有内存泄漏的情况。经过代码review发现，cplex使用完后没有调用end方法。修改代码后重新发布，再dump下内存，发现已经没有cplex相关的对象了。  
项目启动时指定堆内存的初始值和最大值，并保持相等，这样就不用自动扩容了： -Xms3072m -Xmx3072m；关闭堆内存的自动调整\*\*-XX:-UseAdaptiveSizePolicy ；调整老年代和新生代比例，同时增加survivor区的比例，-XX:NewRatio=1 -XX:SurvivorRatio=6；将MetaspaceSize和MaxMetaspaceSize设置成一样的值，并设置得比初始值要大，64G的机器设置为1G，-XX:MetaspaceSize=1024m -XX:MaxMetaspaceSize=1024m \*\*。  
修改代码中关于线程池相关的配置，根据目前仓的数量，决定有多少线程。