云原生背景下如何配置JVM内存

最新推荐文章于 2025-12-28 18:05:40 发布

转载最新推荐文章于 2025-12-28 18:05:40 发布 · 160 阅读

CC 4.0 BY-SA版权

原文链接：https://mp.weixin.qq.com/s?__biz=MzUzMTA2NTU2Ng==&mid=2247573670&idx=3&sn=a66bd439112bf21020cc2caca4ff0572&chksm=fa4bdf17cd3c56013bb3f96f015b5dc08a9a3cf42a7bee92e0cfd5ab05d14d95291ae3e84e4d&scene=126&sessionid=0

文章标签：

#jvm #云原生 #java #linux #开发语言

文章讲述了在Kubernetes环境中，由于应用内存使用率高导致Pod重启的问题。通过分析发现，虽然JVM内存占用只有30%，但是容器（Pod）内存已满，触发了OOM。解释了容器的namespace和cgroups如何实现资源隔离与限制，并指出Java应用在容器中的内存配置问题，建议JVM配置应低于容器限制的2/3以防止内存溢出。最后，提出了云原生背景下的优化策略。

点击上方“芋道源码”，选择“设为星标”

管她前浪，还是后浪？

能浪的浪，才是好浪！

每天 10:33 更新文章，每天掉亿点点头发...

源码精品专栏

来源：crossoverJie

前段时间业务研发反馈说是他的应用内存使用率很高，导致频繁的重启，让我排查下是怎么回事；

在这之前我也没怎么在意过这个问题，正好这次排查分析的过程做一个记录。

首先我查看了监控面板里的 Pod 监控：

发现确实是快满了，而此时去查看应用的 JVM 占用情况却只有30%左右；说明并不是应用内存满了导致 JVM 的 OOM，而是 Pod 的内存满了，导致 Pod 的内存溢出，从而被 k8s 杀掉了。

而 k8s 为了维持应用的副本数量就得重启一个 Pod，所以看起来就是应用运行一段时间后就被重启。

而这个应用配置的是 JVM 8G，容器申请的内存是16G，所以 Pod 的内存占用看起来也就 50% 左右。

容器的原理

在解决这个问题之前还是先简单了解下容器的运行原理，因为在 k8s 中所有的应用都是运行在容器中的，而容器本质上也是运行在宿主机上的一个个经常而已。

但我们使用 Docker 的时候会感觉每个容器启动的应用之间互不干扰，从文件系统、网络、CPU、内存这些都能完全隔离开来，就像两个运行在不同的服务器中的应用。

其实这一点也不是啥黑科技，Linux 早就支持 2.6.x 的版本就已经支持 namespace 隔离了，使用 namespace 可以将两个进程完全隔离。

仅仅将资源隔离还不够，还需要限制对资源的使用，比如 CPU、内存、磁盘、带宽这些也得做限制；这点也可以使用 cgroups 进行配置。

它可以限制某个进程的资源，比如宿主机是 4 核 CPU，8G 内存，为了保护其他容器，必须给这个容器配置使用上限：1核 CPU，2G内存。

这张图就很清晰的表示了 namespace 和 cgroups 在容器技术中的作用，简单来说就是：

namespace 负责隔离
cgroups 负责限制

在 k8s 中也有对应的提现：

resources:
    requests:
      memory: 1024Mi
      cpu: 0.1
    limits:
      memory: 1024Mi
      cpu: 4

这个资源清单表示该应用至少需要为一个容器分配一个 0.1 核和 1024M 的资源，CPU 的最高上限为 4 个核心。

基于 Spring Boot + MyBatis Plus + Vue & Element 实现的后台管理系统 + 用户小程序，支持 RBAC 动态权限、多租户、数据权限、工作流、三方登录、支付、短信、商城等功能

项目地址：https://github.com/YunaiV/ruoyi-vue-pro
视频教程：https://doc.iocoder.cn/video/

不同的OOM

回到本次的问题，可以确认是容器发生了 OOM 从而导致被 k8s 重启，这也是我们配置 limits 的作用。

k8s 内存溢出导致容器退出会出现 exit code 137 的一个 event 日志。

因为该应用的 JVM 内存配置和容器的配置大小是一样的，都是8GB，但 Java 应用还有一些非 JVM 管理的内存，比如堆外内存之类的，这样很容易就导致容器内存大小超过了限制的 8G 了，也就导致了容器内存溢出。

基于 Spring Cloud Alibaba + Gateway + Nacos + RocketMQ + Vue & Element 实现的后台管理系统 + 用户小程序，支持 RBAC 动态权限、多租户、数据权限、工作流、三方登录、支付、短信、商城等功能

项目地址：https://github.com/YunaiV/yudao-cloud
视频教程：https://doc.iocoder.cn/video/

云原生背景的优化

因为这个应用本身使用的内存不多，所以建议将堆内存限制到 4GB，这样就避免了容器内存超限，从而解决了问题。

当然之后我们也会在应用配置栏里加上建议：推荐 JVM 的配置小于容器限制的 2/3，预留一些内存。

其实本质上还是开发模式没有转变过来，以传统的 Java 应用开发模式甚至都不会去了解容器的内存大小，因为以前大家的应用都是部署在一个内存较大的虚拟机上，所以感知不到容器内存的限制。

从而误以为将两者画了等号，这一点可能在 Java 应用中尤为明显，毕竟多了一个 JVM；甚至在老版本的 JDK 中如果没有设置堆内存大小，无法感知到容器的内存限制，从而自动生成的 Xmx 大于了容器的内存大小，以致于 OOM。

欢迎加入我的知识星球，一起探讨架构，交流源码。加入方式，长按下方二维码噢：

已在知识星球更新源码解析如下：

最近更新《芋道 SpringBoot 2.X 入门》系列，已经 101 余篇，覆盖了 MyBatis、Redis、MongoDB、ES、分库分表、读写分离、SpringMVC、Webflux、权限、WebSocket、Dubbo、RabbitMQ、RocketMQ、Kafka、性能测试等等内容。

提供近 3W 行代码的 SpringBoot 示例，以及超 4W 行代码的电商微服务项目。

获取方式：点“在看”，关注公众号并回复 666 领取，更多内容陆续奉上。

文章有帮助的话，在看，转发吧。
谢谢支持哟 (*^__^*）