高级JAVA工程师解决生产环境JVM宕机Java进程挡掉操作系统内存异常实例讲解

高级JAVA工程师解决生产环境JVM宕机Java进程挡掉内存溢出实例讲解

一、事故描述

生产环境Java进程莫名挡掉，JVM宕机。监控平台报警。生产停了，老板急了，客户爆了，怎么迅速解决事故？每次出现生产事故，都是一堆旁观者，真正解决问题的人其实很少。老板在旁边顶着，客户等着回复电话，甲方等着要说法！高级工程师其实没有那么容易！

二、核心JVM日志解读

JVM宕机就是java进程直接自己消失了，在jar包同级目录，会有JVM日志，这个日志，命名如下：

在这里插入图片描述

三、分析核心日志内容

日志内容如下：

#
# There is insufficient memory for the Java Runtime Environment to continue.
# Native memory allocation (mmap) failed to map 29360128 bytes for committing reserved memory.
# Possible reasons:
#   The system is out of physical RAM or swap space
#   The process is running with CompressedOops enabled, and the Java Heap may be blocking the growth of the native heap
# Possible solutions:
#   Reduce memory load on the system
#   Increase physical memory or swap space
#   Check if swap backing store is full
#   Decrease Java heap size (-Xmx/-Xms)
#   Decrease number of Java threads
#   Decrease Java thread stack sizes (-Xss)
#   Set larger code cache with -XX:ReservedCodeCacheSize=
#   JVM is running with Zero Based Compressed Oops mode in which the Java heap is
#     placed in the first 32GB address space. The Java Heap base address is the
#     maximum limit for the native heap growth. Please use -XX:HeapBaseMinAddress
#     to set the Java Heap base and to place the Java Heap above 32GB virtual address.
# This output file may be truncated or incomplete.
#
#  Out of Memory Error (os_linux.cpp:2749), pid=983631, tid=0x00007fd6ba2e2700
#
# JRE version: Java(TM) SE Runtime Environment (8.0_211-b12) (build 1.8.0_211-b12)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (25.211-b12 mixed mode linux-amd64 compressed oops)
# Core dump written. Default location: /home/jk/core or core.983631
#

---------------  T H R E A D  ---------------

Current thread (0x00007fd6e4271800):  VMThread [stack: 0x00007fd6ba1e3000,0x00007fd6ba2e3000] [id=983646]

Stack: [0x00007fd6ba1e3000,0x00007fd6ba2e3000],  sp=0x00007fd6ba2e13f0,  free space=1016k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0xad3455]  VMError::report_and_die()+0x2e5
V  [libjvm.so+0x4e0537]  report_vm_out_of_memory(char const*, int, unsigned long, VMErrorType, char const*)+0x67
V  [libjvm.so+0x910320]  os::pd_commit_memory(char*, unsigned long, unsigned long, bool)+0x100
V  [libjvm.so+0x90794f]  os::commit_memory(char*, unsigned long, unsigned long, bool)+0x1f
V  [libjvm.so+0x98c736]  PSVirtualSpace::expand_by(unsigned long)+0x56
V  [libjvm.so+0x98d9c8]  PSYoungGen::resize(unsigned long, unsigned long)+0xd8
V  [libjvm.so+0x98a166]  PSScavenge::invoke_no_policy()+0x1376
V  [libjvm.so+0x98a4fc]  PSScavenge::invoke()+0x4c
V  [libjvm.so+0x93a248]  ParallelScavengeHeap::failed_mem_allocate(unsigned long)+0x68
V  [libjvm.so+0xad4fa3]  VM_ParallelGCFailedAllocation::doit()+0x93
V  [libjvm.so+0xada1c6]  VM_Operation::evaluate()+0x46
V  [libjvm.so+0xad84fd]  VMThread::evaluate_operation(VM_Operation*) [clone .constprop.44]+0xcd
V  [libjvm.so+0xad8ae3]  VMThread::loop()+0x3a3
V  [libjvm.so+0xad8eb8]  VMThread::run()+0x78
V  [libjvm.so+0x90d952]  java_start(Thread*)+0x102

VM_Operation (0x00007fd69cda24a0): ParallelGCFailedAllocation, mode: safepoint, requested by thread 0x00007fd5fd7cf000

核心内容：

#   The system is out of physical RAM or swap space
#   The process is running with CompressedOops enabled, and the Java Heap may be blocking the growth of the native heap

The system is out of physical RAM or swap space
The process is running with CompressedOops enabled, and the Java Heap may be blocking the growth of the native heap
系统的物理 RAM 或交换空间不足
该进程在启用 CompressedOops 的情况下运行，并且 Java 堆可能会阻碍本机堆的增长

分析一下：
肯定跟操作系统内存有关系，内存相关的引起的宕机！

四、解决方法与思路

这段错误信息表明，Java 运行时环境（JRE）遇到了内存不足的问题。以下是一些可能的解决方法：

减少系统的内存负载：关闭一些不需要的进程或程序，以释放内存。
增加物理内存或交换空间：如果可能的话，可以添加更多的物理内存或增加交换空间的大小。
检查交换备份存储是否已满：确保交换空间有足够的可用空间。
减小 Java 堆大小：通过降低 -Xmx 或 -Xms 参数的值来减小 Java 堆的大小。
减少 Java 线程数量：如果有过多的线程，可以考虑减少线程数量。
减小 Java 线程堆栈大小：降低 -Xss 参数的值可以减小线程堆栈的大小。
设置更大的代码缓存：使用 -XX:ReservedCodeCacheSize= 参数来增加代码缓存的大小。
如果 JVM 在零基础压缩Oops 模式下运行，并且 Java 堆位于前 32GB 地址空间中，可以使用 -XX:HeapBaseMinAddress 来设置 Java 堆的基础地址，并将 Java 堆放置在 32GB 虚拟地址之上，以允许本机堆增长。

请注意，具体的解决方法可能因系统配置和应用程序的具体情况而有所不同。你可能需要根据实际情况进行一些试验和调整。此外，确保你的应用程序没有内存泄漏问题也是很重要的。如果问题仍然存在，可能需要进一步调查和分析！

第一个解决思路就是增加物理内存的容量，如果增量至2倍4倍，整个大招基本都能解决！
第二个解决思路，扩展虚拟内存的容量到2倍！让物理内存占用降低，分离出更多的闲余内存！
第三个重复整个服务器，让内存重新释放！
第四个减小 Java 堆大小：通过降低 -Xmx 或 -Xms 参数的值来减小 Java 堆的大小。将之前的配置减小！

特别情况

The system is out of physical RAM or swap space
The process is running with CompressedOops enabled, and the Java Heap may be blocking the growth of the native heap JAVA进程宕机，但是当前服务器还有剩余很多的内存，为啥还会内存不足呢？

当服务器还有剩余很多的内存，但仍然出现内存不足的错误时，可能有以下几个原因：

进程内部资源没有释放：通过top命令分析进程编号，若进程占用内存高但使用CPU少，说明不是进程内存死循环造成的内存开销很大，而是由进程内部资源没有释放掉。
Java线程出现死锁或所有线程被阻塞。
数据库连接池中的连接耗尽。
内存泄漏导致了OutOfMemory。
服务器可用内存足够，但是分配给JVM的内存被耗尽。
服务程序运行过程中替换了JAR包，但是没有进行重启服务。
磁盘空间满。
线程池满。

如果你遇到了内存不足的错误，可以根据实际情况检查上述可能的原因，并采取相应的解决措施。

解决思路

增大 Java 堆大小：通过降低 -Xmx 或 -Xms 参数的值来增大 Java 堆的大小。
让操作系统分配更多的内存给到JAVA进程！

如下分析启动shell脚本！

#!/bin/sh
export JAVA_HOME=/home/java/jdk1.8.0_211
export CLASSPATH=.:$JAVA_HOME/lib/dt.jar:$JAVA_HOME/lib/tools.jar

echo '' /home/jk/nasen.pid 

java -jar -Duser.timezone=GMT+08 -Xmx8000m -Xms6000m  /home/jk/nasen.jar >/dev/null &
#注意：必须有&让其后台执行，否则没有pid生成
echo $! > /home/jk/nasen.pid # 将jar包启动对应的pid写入文件中，为停止时提供pid

五、透过现象看本质，究竟是什么本质原因导致服务器内存不足呢？

上述是通常常用解决方法，但是我还是想深究一下，究竟是什么进程导致服务器内存不足呢？
服务器物理内存32G，虚拟内存32G，JAVA堆内存配置最大6G，redis最大配置也就10G，为啥操作系统物理占用那么高？甚至快占满了，完全说不通！
linux服务执行top命令查看当前服务器负载

在这里插入图片描述

ps aux | sort -k4rn | head -n 10   #查看当前操作系统所有进程，内存占用从大到小排列

排查一下可疑的进程，发现有个操作系统的监控控件进程占用超大内存，杀掉之后，内存就释放了，
总结本质原因因为操作系统自带一个监控插件占用内存过大，并且与JAVA进程跟redis进程互相争夺内存资源导致事故！

笔者简介
国内某一线知名软件公司企业认证在职员工：任JAVA高级研发工程师,大数据领域专家,数据库领域专家兼任高级DBA!10年软件开发经验！现任国内某大型软件公司大数据研发工程师、MySQL数据库DBA，软件架构师。直接参与设计国家级亿级别大数据项目!并维护真实企业级生产数据库300余个!紧急处理数据库生产事故上百起，挽回数据丢失所造成的灾难损失不计其数!并为某国家级大数据系统的技术方案（国家知识产权局颁布）专利权的第一专利发明人！

在这里插入图片描述