Linux服务宕机，java服务导致的内存溢出

先看问题

可以看到，服务器宕机了

系统级别的日志默认存放在 /var/log 目录下，其中 /var/log/messages 是常用的系统日志文件，可能包含宕机前的错误或警告信息

 核心代码语句

grep -i "Out of memory\|killed process" /var/log/messages

可能原因
(1) Java 堆内存配置不合理
如果 Java 应用的 -Xmx（最大堆内存）设置过高，可能超出系统可用物理内存。
例如：系统总内存 4GB，但 Java 堆配置了 -Xmx3G，加上其他进程和系统开销，容易触发 OOM。
(2) 内存泄漏或资源未释放
Java 应用可能存在内存泄漏（如未释放对象、缓存无限增长等），导致堆内存或堆外内存（Direct Buffer、JNI 等）持续占用。
常见于长时间运行的服务，内存逐步累积直至耗尽。
(3) 系统内存资源不足
服务器物理内存总量较小，或未合理分配内存资源（如未预留足够内存给操作系统或其他服务）。
(4) JVM 未优化
未合理配置 JVM 参数（如 Metaspace、Code Cache、线程栈等），导致堆外内存占用过高。

根本问题是 Java 进程内存占用超出了系统可用资源，可能由配置不当、内存泄漏或系统资源不足导致。建议优先优化 JVM 参数、检查内存泄漏，并确保系统有足够内存冗余。如果问题持续，可考虑升级服务器配置。

如何处理

docker yml增加 Java 进程的最大内存限制

在Docker中使用Docker Compose时，如果你想要限制一个Java进程（例如，一个Spring Boot应用）的最大内存使用量，可以通过设置容器资源限制来实现。这可以通过在docker-compose.yml文件中为相应的服务设置mem_limit（或mem_reservation）来实现。示例
假设你有一个Spring Boot应用，并且你想限制其内存使用不超过512MB。你可以在docker-compose.yml文件中这样设置：version: '3'
services:springbootapp:image: your-spring-boot-imagemem_limit: 512m# 或者使用 mem_reservation 来确保至少有512MB的内存可用# mem_reservation: 512mports:- "8080:8080"
在这个配置中：mem_limit 设置了容器可以使用的最大内存量。一旦达到这个限制，容器中的应用可能会被OOM killer杀死（尽管这取决于具体的操作系统和内核策略）。mem_reservation 设置了容器启动时至少应该有的内存量。这对于保证容器启动时有足够的资源非常重要，尤其是在资源竞争激烈的环境中。注意点
OOM Killer：当容器中的进程尝试使用超过分配的内存量时，Linux内核的OOM Killer机制可能会介入并杀死一些进程以回收内存。这不一定总是你想要的行为，特别是在生产环境中。为了减少OOM Killer的干预，可以考虑增加mem_limit的值或者使用cgroup v2的内存管理功能（例如使用memory.oom_control）。JVM内存设置：除了Docker容器的内存限制外，你还需要在Java应用中正确设置JVM的内存参数（如-Xmx和-Xms），以确保应用不会尝试使用超过分配的内存量。例如，如果你的Docker容器限制为512MB，你应该在启动命令中设置：java -Xmx512m -Xms256m -jar your-application.jar这样，Java应用就不会尝试使用超过512MB的内存。使用cgroup v2：如果你使用的是cgroup v2，你可以更细粒度地控制内存管理策略。例如，你可以设置memory.oom_control为none来禁用OOM Killer针对特定容器的行为。这需要在Docker daemon的启动参数中启用cgroup v2，并在Docker Compose文件中适当设置。示例：启用cgroup v2并禁用OOM Killer
首先，确保你的Docker daemon配置为使用cgroup v2（这通常需要在Docker的启动参数中添加--exec-opt native.cgroupdriver=cgroupfs或者在Docker的配置文件中设置）。然后，你可以在Docker Compose文件中添加特定的cgroup配置：version: '3'
services:springbootapp:image: your-spring-boot-imagedeploy:resources:limits:memory: 512m# 其他配置...
在这个配置中，我们使用了Docker Compose的deploy部分来设置资源限制，这种方式更适合于Swarm模式或支持swarm模式的Docker环境。对于单机模式，直接使用mem_limit也是可行的。

或者如下

version: '3'
services:java:restart: alwaysimage: openjdk:14deploy:resources:limits:memory: 512mcontainer_name: haidi_openjdk14ports:- 8080:8080volumes:- /command/java/haidi/ruoyi-admin.jar:/data/ruoyi-admin.jar- /home/ruoyi/uploadPath:/home/ruoyi/uploadPathenvironment:TZ: Asia/Shanghaientrypoint: java -Xmx512m -Xms256m -jar /data/ruoyi-admin.jar

 如果出现该警告

docker-compose 启动警告Compose does not support ‘deploy‘ configuration - use `docker stack deploy` to de

docker-compose --compatibility  -f /command/java/haidi/haidi.yml up -d

达到最大内存的后果
当Java进程使用的内存达到最大限制后，JVM将开始进行垃圾回收(Garbage Collection,GC)以释放未使用的对象。如果此时仍然无法回收足够的内存，JVM会抛出0utOfMemoryError异常。Java中的 OutOfMemoryError是指在应用尝试分配内存但没有足够可用内存时发生的错误。
 

参考如下

您可以参考下这个
分配逻辑：
总容器内存：4 × 768MB = 3072MB（3GB），与剩余可用内存匹配。
mem_reservation：设置为 mem_limit 的 75%~80%（避免突发内存需求被OOM Killer杀死）。
JVM -Xmx：设置为容器 mem_limit 的 60%~70%（预留堆外内存空间）。
Docker Compose配置示例
services:
java-service1:
image: your-java-image
deploy:
resources:
limits:
memory: 768M
reservations:
memory: 600M
environment:
- JAVA_OPTS=-Xms512m -Xmx512m -XX:MaxRAMPercentage=70.0 # 推荐使用百分比模式
java-service2:
JVM参数优化建议
(1) 优先使用容器感知的JVM参数（JDK 8u131+ 或 JDK 10+）
# 自动根据容器内存分配堆大小（按总内存的70%）
-XX:InitialRAMPercentage=70.0
-XX:MaxRAMPercentage=70.0
-XX:MinRAMPercentage=70.0
优势：避免手动计算错误，动态适应容器内存限制。
(2) 手动设置堆内存（传统方式）
# 示例：堆内存设为512MB（需预留堆外内存）
-Xms512m -Xmx512m

linux查看服务器剩余内存

在Linux系统中，有多种方法可以查看服务器的剩余内存。下面是一些常用的命令：

1. free 命令

free 命令是最直接查看内存使用情况的方法之一。

free -h

这里 -h 选项代表“human-readable”，即以易于阅读的格式（如MB、GB）显示信息。输出结果中，Mem 部分显示了物理内存的使用情况，Swap 部分显示了交换空间的使用情况。