Spring Boot 项目调优，JVM 调优，预防触发Linux的OOM-Killer机制

最新推荐文章于 2025-10-25 17:58:18 发布

原创

最新推荐文章于 2025-10-25 17:58:18 发布 · 926 阅读

0 ·

CC 4.0 BY-SA版权

文章标签：

#JVM #调优

本文介绍了如何针对一个8GB内存的Linux服务器上运行的Spring Boot服务进行内存调优，以防止触发Linux的OOM-Killer机制。以一个RocketMQ消费者服务为例，调整JVM参数，观察内存占用情况，分析Java进程堆栈，探讨进一步优化的可能性。通过减少线程堆栈大小等手段尝试减小内存占用，同时提供了相关参考资料供深入研究。

前言

手上有一个测试服务器，内存是8G，最近开始搭起微服务的软件架构，单个Spring Boot 服务内存占用有点大，比如一个RocketMq的消费者服务(单独运行的服务)，启动占用了 500M 内存,导致我后面想运行其他服务,内存不够，触发了 Linux 的 OOM - Killer 机制

Linux杀死了我们的进程,但 nohup.out 没有记录任何东西，我们的linux发生的都在记录/var/log下，通过下面命令查看被杀死进程信息

dmesg | egrep -i -B100 'killed process
在这里插入图片描述

最近内存的确有点吃紧，上面只需要关注第二个 anno-rss 实际占用内存(被Kill前)，现在有两个方向一个是不做微服务，第二个是给Spring Boot 项目瘦身√

下面以我们的RocketMQ消费者为例，看看没有优化前直接启动占用多少实际内存

# 启动命令
nohup java -jar /usr/****/jar/consumer-rocketmq/target/consumer-rocketmq-2.0.1.RELEASE.jar &

# 获取进程号23371的pid和启动参数，rss实际占用内存(kB)，vsz允许最大内存，

最低0.47元/天解锁文章

确定要放弃本次机会？

福利倒计时

: :

立减 ¥

普通VIP年卡可用

立即使用

aka这里是你的程序员

关注关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
分享

复制链接

分享到 QQ

分享到新浪微博

扫一扫
举报

举报

专栏目录

Docker 容器 OOM：从资源监控到JVM调优的实战记录

Rqaqedamancy的博客

09-07

3万+

在微服务架构盛行的今天，Docker容器化部署已经成为标准实践。然而，在之前生产环境部署中，我遭遇了一个让人头疼的问题：Java应用在Docker容器中频繁出现OOM（Out of Memory）错误，导致服务不断重启，严重影响了用户体验。这个问题的复杂性远超我的预期。表面上看是简单的内存不足，但深入分析后发现，这涉及到Docker容器的资源限制机制、JVM内存管理策略、以及容器环境下的内存分配逻辑等多个层面。更让人困惑的是，同样的应用在物理机上运行良好，但一旦容器化部署就会出现内存问题。

ElasticSearch中的JVM性能调优

javalingyu的博客

05-05

3474

ElasticSearch6.3.2 中的JVM性能调优前一段时间被人问了个问题：在使用ES的过程中有没有做过什么JVM调优措施？在我搭建ES集群过程中，参照important-settings官方文档来的，并没有对JVM参数做过多的调整。但谈到JVM配置参数，少不了操作系统层面上的一些配置参数，比如 page cache 和文件描述符的个数：(/etc/security/limits.conf)。另外ES jvm.options配置文件也针对JVM参数做了一些优化，这里简要介绍一下ElasticS

参与评论您还未登录，请先登录后发表或查看评论

K8S为何杀死我的应用

jdk2010的博客

10-25

557

首发公众号:二进制社区,转载联系:binary0101@126.com导读"K8S为我们提供自动部署调度应用的能力，并通过健康检查接口自动重启失败的应用，确保服务的可用性，但这种自动运维在某些特殊情况下会造成我们的应用陷入持续的调度过程导致业务受损，本文就生产线上一个核心的平台应用被K8S频繁重启调度问题展开剖解，抽丝剥茧一步步从系统到应用的展开分析，最后定位到代码层面解决问题"现象在搭建devops基础设施后,业务已经全盘容器化部署,并基于k8s实现自动调度,但个别业务运行一段时间后会被k8s自动重

linux 系统日志 oom,Linux进程被杀掉（OOM killer），查看系统日志

weixin_33917474的博客

05-02

2895

基本概念：Linux 内核有个机制叫OOM killer(Out Of Memory killer)，该机制会监控那些占用内存过大，尤其是瞬间占用内存很快的进程，然后防止内存耗尽而自动把该进程杀掉。内核检测到系统内存不足、挑选并杀掉某个进程的过程可以参考内核源代码linux/mm/oom_kill.c，当系统内存不足的时候，out_of_memory()被触发，然后调用select_bad_pro...

Linux内存优化：OOM Killer与交换分区调优

最新发布

jsgdfgxjsgdjxc的博客

10-25

249

当系统内存耗尽时，内核触发OOM（Out-of-Memory）Killer终止进程以释放资源。Linux内存管理需平衡物理内存与交换空间，避免系统崩溃。：调优需结合业务场景测试。例如，数据库服务器建议。并保护核心进程，而开发环境可适度提高交换利用率。交换分区将内存数据暂存磁盘，扩展可用内存空间。

【Linux】进程OOM-kill 监控和规避

康师傅没有眼泪

07-05

3982

在Linux系统内存将要用完的情况下，OOM-killer进程会遍历当前机器上的所有进程，按照进程所占内存的大小和用户打分(oom_score_adj)对进程进行打分（占用内存越大，分数越高），然后挑选出分数最高的进程将其kill掉。在工作过程中，你可能会遇到过这种情况，程序在运行一段时间之后突然挂掉，在你保证程序在正常情况下不会挂掉的情况下，程序挂掉的原因可能是在你的程序运行过程中，有一段时间你的程序运行内存过大，而此时系统物理内存不足，导致系统触发OOM killer机制，将该进程kill。

linux springboot项目异常停止无日志

qq_43089596的博客

07-25

1172

帮朋友做了个小项目，代码不多，业务不多，部署在阿里云内存为1G的服务器上，采用springboot+h2，前端为vue3+nginx,运行参数最大最小内存都为500m,正常运行2个月后开始出现异常停止现像，无异常日志打印，同时发现内存实际为730M，已占用为90%明显内存不足。。只是从没有在这么低配置上部署项目，一时不知所措，

Linux OOM Killer机制以及防止被OOM Killer杀死的方法_linux 设置 redis 内存防止oom(2)

m0_62261166的博客

05-05

945

本书是获得了很多读者好评的Linux经典畅销书**《Linux从入门到精通》的第2版**。本书第﹖版以最新的Ubuntu 12.04为版本，循序渐进地向读者介绍了Linux 的基础应用、系统管理、网络应用、娱乐和办公、程序开发、服务器配置、系统安全等。另外,本书还为读者提供了大量的Linux学习资料和Ubuntu安装镜像文件，供读者免费下载。需要《Linux入门到精通》、《linux系统移植》、《Linux驱动开发入门实战》、《Linux开源网络全栈》电子书籍及教程的工程师朋友们劳烦您转发+评论。

JVM参数调优实录：深度排查Neo4j服务启动失败的5个内存配置陷阱

# JVM参数调优实录：深度排查Neo4j服务启动失败的5个内存配置陷阱在部署 Neo4j 图数据库时，你有没有遇到过这样的场景？一切配置看似完美，防火墙也放行了端口，但服务就是“卡”在启动阶段，日志里反复刷着 `...

JVM内存问题排查

偶尔写些东西，意思一下我也参与了内卷

01-25

1594

JVM 的堆空间分成2个区域：年轻代、老年代年轻代又进一步细分成3个区域：Eden、Survivor From、Survivor To。

Spring Boot 中使用多线程时，线程数量过多可能导致内存溢出（OOM）

2401_89221867的博客

07-24

742

在 Spring Boot 中使用多线程时，线程数量过多可能导致内存溢出（OOM）的核心原因是：。以下是针对性的解决方案，涵盖线程池配置、资源管理、内存优化等关键环节。

jvm系列(十):教你如何成为Java的OOM Killer

纯洁的微笑

10-17

658

此文出处云时代架构，作者：李艳鹏教你如何成为Java的OOM Killer前言虽然事隔半年，当时排查线上OOM事故的过程记忆犹新，每一个步骤都历历在目，感谢业务组、系...

一文搞懂 JVM 架构和运行时数据区 (内存区域)

独行侠梦的博客

03-27

581

点击上方蓝色字体，关注我们前言了解 JVM 是对 Java 开发人员的基本要求，JVM 的相关内容自然也成了现在 Java 程序员面试的重要考点。不过估计很多小伙伴和我一样，长时间醉心于...

Linux 服务器进程避免 OOM 的方法

m0_38048955的博客

12-29

865

某天一台机器突然 ssh 远程登录不了，但能 ping 通，说明不是网络的故障，原因是 sshd 进程被 OOM killer 杀掉了(多次遇到这样的假死状况)。

Linux 后台运行jar包程序

记录工作开发中遇到的技术难点，方便自己查看，也希望可以帮助到他人...

04-26

278

问题：在Xshell终端窗口中使用java -jar xxx.jar运行jar包程序，当Xshell关闭之后，jar包程序停止运行。解决办法： nohup java -jar XXX.jar & nohup 意思是不挂断运行命令，当账户退出或终端关闭时，程序仍然运行。 ...

当jvm发生oom时自动退出

老徐的博客

09-28

1443

jvm oom 内存溢出自动退出 springboot

total-vm anon-rss file-rss shmem-rss含义

已迁移至 https://seekstar.github.io/

07-28

1万+

进程被杀了。查一下日志： dmesg | egrep -i -B100 'killed process' [2352218.368085] Out of memory: Kill process 1462 (transaction-exp) score 834 or sacrifice child [2352218.368850] Killed process 1462 (transaction-exp) total-vm:18307836kB, anon-rss:13871180kB, file-rss

什么是STW以及CMS和G1优缺点？

热门推荐

Venus's Blog

09-08

2万+

什么是Stop The World 不管选择哪种GC算法，stop-the-world都是不可避免的。Stop-the-world意味着从应用中停下来并进入到GC执行过程中去。一旦Stop-the-world发生，除了GC所需的线程外，其他线程都将停止工作，中断了的线程直到GC任务结束才继续它们的任务。GC调优通常就是为了改善stop-the-world的时间 CMS收集器一种以获取最短回收停顿时间为目标的收集器，CMS收集器是基于“”标记–清除”(Mark-Sweep)算法实现的。整个过程分为四个步骤

javaOOM该分析dump文件而不是看异常log日志原因

try to do

12-04

657

字节（byte）字节来自英文Byte，音译为“拜特”，习惯上用大写的“B”表示。字节是计算机中数据处理的基本单位。计算机中以字节为单位存储和解释信息，规定一个字节由八个二进制位构成，即1个字节等于8个比特（1Byte=8bit） 1KB=1024B；1MB=1024KB=1024 x 1024B。其中1024=2^10。应用程序出现OOM异常，你是否仍然通过看日志的方式去排查问题（该方式定位解决问题是大概率的巧合而已）？正确的排查方案是进行dump文件分析，你知道为什么吗？ OOM异常–intsmaz

nohup java -jar 部署jar 包后项目莫名挂掉的解决方法

07-12

在使用 `nohup java -jar` 部署 JAR 包时，应用可能会因为多种原因出现崩溃或意外退出的情况。以下是几种常见的解决方法： 1. **日志文件过大问题** 默认情况下，`nohup` 会将输出写入 `nohup.out` 文件中，如果未进行管理，该文件可能无限增长并导致磁盘空间耗尽，从而引发程序异常退出。为了避免这一问题，可以将标准输出和错误输出重定向到 `/dev/null`，即不记录任何输出： ```bash nohup java -jar xxxx.jar > /dev/null 2>&1 & ``` 这样可以有效避免因日志文件过大而导致的系统资源耗尽问题[^1]。 2. **内存配置不当** 如果 JVM 的堆内存设置不合理（例如 `-Xms` 和 `-Xmx` 设置过小），可能导致应用在处理大量请求或数据时发生 `OutOfMemoryError`。因此，建议根据实际需求调整 JVM 内存参数，并确保有足够的物理内存可用： ```bash nohup java -jar -Xms512m -Xmx1024m /xxx/yyy/aaa.jar & ``` 此外，还可以通过添加 `-XX:+HeapDumpOnOutOfMemoryError` 参数来生成堆转储文件，以便后续分析内存泄漏的原因[^2]。 3. **临时目录配置** 某些 Java 应用（尤其是基于 Tomcat 的 Spring Boot 应用）会在运行时使用默认的系统临时目录（如 `/tmp`）。如果该目录权限受限或磁盘空间不足，可能导致应用异常退出。为避免此类问题，可以通过 `-Djava.io.tmpdir` 显式指定一个具有足够空间和适当权限的临时目录： ```bash nohup java -Djava.io.tmpdir=/xxx/.../tmp -jar -Xms512m -Xmx512m /xxx/.../xxx.jar --server.tomcat.basedir=/xxx/.../tmp & ``` 同时，`--server.tomcat.basedir` 参数用于指定 Tomcat 的工作目录，防止其使用默认路径导致的问题[^2]。 4. **自动重启机制** 为了提高服务的可用性，可以在脚本中实现自动重启逻辑。例如，编写一个 Shell 脚本来定期检查应用是否仍在运行，并在检测到进程终止后重新启动它： ```bash #!/bin/bash while true; do if ! ps -p <PID> > /dev/null; then echo "Application is not running, restarting..." nohup java -jar -Xms512m -Xmx1024m /path/to/app.jar > /dev/null 2>&1 & fi sleep 60 done ``` 其中 `<PID>` 是应用的进程 ID。此脚本每分钟检查一次应用状态，若发现进程不存在，则自动重启应用[^4]。 5. **健康检查与监控** 使用 `curl` 或其他 HTTP 客户端工具对应用的健康检查接口进行轮询，确保应用始终处于可访问状态。如果检测失败，可以触发重启操作： ```bash #!/bin/bash if ! curl -s -f http://localhost:8080/actuator/health > /dev/null; then echo "Application health check failed, restarting..." pkill -f "java -jar" nohup java -jar -Xms512m -Xmx1024m /path/to/app.jar > /dev/null 2>&1 & fi ``` 上述脚本通过调用 `/actuator/health` 接口判断应用是否正常，若失败则杀死当前 Java 进程并重新启动[^5]。 6. **查看日志与调试信息** 若应用频繁崩溃但无明显外部表现，应优先检查 `nohup.out` 中的日志内容，寻找异常堆栈信息。此外，还可以结合系统日志（如 `/var/log/messages` 或 `dmesg` 输出）查找是否有 OOM Killer 杀死进程的记录： ```bash dmesg | grep -i kill ``` ###