为何内存不够用?微服务改造启动多个Spring Boot的陷阱与解决方案

简介: 本文记录并复盘了生产环境中Spring Boot应用内存占用过高的问题及解决过程。系统上线初期运行正常,但随着业务量上升,多个Spring Boot应用共占用了64G内存中的大部分,导致应用假死。通过jps和jmap工具排查发现,原因是运维人员未设置JVM参数,导致默认配置下每个应用占用近12G内存。最终通过调整JVM参数、优化堆内存大小等措施解决了问题。建议在生产环境中合理设置JVM参数,避免资源浪费和性能问题。

在生产环境中我们会遇到一些问题,此文主要记录并复盘一下当时项目中的实际问题及解决过程。

背景简述

最初系统上线后都比较正常风平浪静的。在系统运行了一段时间后,业务量上升后,生产上发现java应用内存占用过高,服务器总共64G,发现每个SpringBoot占用近12G的内存,我们项目采用微服务架构,有多个springboot应用。一下子内存就不够用了,springboot出现假死了。

由于当时生产没有截图,我用本机模拟类似的情况。


添加图片注释,不超过 140 字(可选)



添加图片注释,不超过 140 字(可选)


可以看到内存基本被使用完了,为什么Java程序会占用这么大内存呢?


解决步骤

step1:jps查看进程ID或通过top


添加图片注释,不超过 140 字(可选)


step2:jmap -heap 进程ID


添加图片注释,不超过 140 字(可选)


可以看到Java应用的最大堆内存是4G,当时我们生产是64G的物理内存,生产Java应用的最大堆内存是12G。


添加图片注释,不超过 140 字(可选)


  • 最大堆大小(-Xmx):通常为物理内存的1/4。
  • 初始堆大小(-Xms):通常为物理内存的1/64。


以下是Oracle官方对JVM默认参数的详细说明:


添加图片注释,不超过 140 字(可选)


以下是对应的译文:

默认堆大小 除非在命令行中指定了初始堆大小和最大堆大小,否则它们是根据计算机上的内存量计算的。 客户端 JVM 默认初始和最大堆大小 默认最大堆大小是物理内存的一半(物理内存大小不超过 192 兆字节 (MB)),否则为物理内存的四分之一(物理内存大小不超过 1 千兆字节 (GB))。 例如,如果您的计算机有 128 MB 物理内存,则最大堆大小为 64 MB,大于或等于 1 GB 物理内存会导致最大堆大小为 256 MB。 JVM 实际上不会使用最大堆大小,除非您的程序创建了足够的对象来需要它。在 JVM 初始化期间分配的量要小得多,称为初始堆大小。此量至少为 8 MB,否则为物理内存的 1/64,最大物理内存大小为 1 GB。 分配给年轻代的最大空间量是总堆大小的三分之一。 服务器 JVM 默认初始和最大堆大小 默认初始堆大小和最大堆大小在服务器 JVM 上的工作方式与在客户端 JVM 上的工作方式类似,只是默认值可以更高。在 32 位 JVM 上,如果有 4 GB 或更多物理内存,则默认最大堆大小可达 1 GB。在 64 位 JVM 上,如果有 128 GB 或更多物理内存,则默认最大堆大小可达 32 GB。 到这里基本上可以看出是运维人员发布Java应用时并没有设置JVM参数,而是使用默认JVM参数。导致每个Java应用占用过高。虽然是小问题,但生产上每个Java占用12G内存还是比较吓人的。


复盘

一般内存占用过大的排查思路:

在排查内存占用过大的问题时,一般可以采取以下思路:

  1. 检查JVM参数: 如果在生产环境中启动Spring Boot没有设置JVM参数,使用默认的JVM配置,可能会导致性能问题和资源浪费。优化JVM参数,根据应用程序的需求和服务器配置进行调整。
  2. 观察内存使用情况: 使用监控工具或者操作系统提供的工具,观察Java应用的内存使用情况,包括堆内存、非堆内存、垃圾回收等。
  3. 分析GC: 如果发现内存问题,可以分析GC日志以了解垃圾回收的情况,包括频率、时间等。
  4. 合理设置堆内存大小: 根据应用程序的需求和服务器的物理内存,合理设置堆内存的大小,避免过大或过小导致性能问题。
  5. 考虑使用内存分析工具: 使用工具如VisualVM、MAT等,对应用程序进行内存分析,找出可能存在的内存泄漏或者大对象。

添加图片注释,不超过 140 字(可选)


如果在生产环境中启动springboot没有设置jvm参数,使用默认的JVM配置,可能会有以下几个危害:

  • 默认的JVM配置可能不适合你的应用程序的性能需求和资源限制,导致内存溢出、垃圾回收频繁、性能下降等问题。
  • 默认的JVM配置可能会浪费服务器的内存资源,因为JVM会根据物理内存的大小来分配堆内存的大小,而不是根据应用程序的实际需求。

因此,建议在生产环境中启动springboot时,根据应用程序的特点和服务器的配置,合理地设置JVM参数,以提高应用程序的性能和稳定性,节省服务器的资源。

目录
相关文章
|
2月前
|
Web App开发 缓存 监控
内存溢出与内存泄漏:解析与解决方案
本文深入解析内存溢出与内存泄漏的区别及成因,结合Java代码示例展示典型问题场景,剖析静态集合滥用、资源未释放等常见原因,并提供使用分析工具、优化内存配置、分批处理数据等实用解决方案,助力提升程序稳定性与性能。
701 1
|
3月前
|
安全 Java 应用服务中间件
Spring Boot + Java 21:内存减少 60%,启动速度提高 30% — 零代码
通过调整三个JVM和Spring Boot配置开关,无需重写代码即可显著优化Java应用性能:内存减少60%,启动速度提升30%。适用于所有在JVM上运行API的生产团队,低成本实现高效能。
345 3
|
2月前
|
负载均衡 Java API
《深入理解Spring》Spring Cloud 构建分布式系统的微服务全家桶
Spring Cloud为微服务架构提供一站式解决方案,涵盖服务注册、配置管理、负载均衡、熔断限流等核心功能,助力开发者构建高可用、易扩展的分布式系统,并持续向云原生演进。
|
3月前
|
监控 Java 数据库
从零学 Dropwizard:手把手搭轻量 Java 微服务,告别 Spring 臃肿
Dropwizard 整合 Jetty、Jersey 等成熟组件,开箱即用,无需复杂配置。轻量高效,启动快,资源占用少,内置监控、健康检查与安全防护,搭配 Docker 部署便捷,是构建生产级 Java 微服务的极简利器。
340 3
|
9月前
|
安全 Java Apache
微服务——SpringBoot使用归纳——Spring Boot中集成 Shiro——Shiro 身份和权限认证
本文介绍了 Apache Shiro 的身份认证与权限认证机制。在身份认证部分,分析了 Shiro 的认证流程,包括应用程序调用 `Subject.login(token)` 方法、SecurityManager 接管认证以及通过 Realm 进行具体的安全验证。权限认证部分阐述了权限(permission)、角色(role)和用户(user)三者的关系,其中用户可拥有多个角色,角色则对应不同的权限组合,例如普通用户仅能查看或添加信息,而管理员可执行所有操作。
491 0
|
9月前
|
安全 Java 数据安全/隐私保护
微服务——SpringBoot使用归纳——Spring Boot中集成 Shiro——Shiro 三大核心组件
本课程介绍如何在Spring Boot中集成Shiro框架,主要讲解Shiro的认证与授权功能。Shiro是一个简单易用的Java安全框架,用于认证、授权、加密和会话管理等。其核心组件包括Subject(认证主体)、SecurityManager(安全管理员)和Realm(域)。Subject负责身份认证,包含Principals(身份)和Credentials(凭证);SecurityManager是架构核心,协调内部组件运作;Realm则是连接Shiro与应用数据的桥梁,用于访问用户账户及权限信息。通过学习,您将掌握Shiro的基本原理及其在项目中的应用。
356 0
|
6月前
|
缓存 监控 Cloud Native
Java Solon v3.2.0 高并发与低内存实战指南之解决方案优化
本文深入解析了Java Solon v3.2.0框架的实战应用,聚焦高并发与低内存消耗场景。通过响应式编程、云原生支持、内存优化等特性,结合API网关、数据库操作及分布式缓存实例,展示其在秒杀系统中的性能优势。文章还提供了Docker部署、监控方案及实际效果数据,助力开发者构建高效稳定的应用系统。代码示例详尽,适合希望提升系统性能的Java开发者参考。
340 4
Java Solon v3.2.0 高并发与低内存实战指南之解决方案优化
|
7月前
|
druid Java 关系型数据库
Spring Boot与Druid升级解决方案
好的,我需要帮助用户解决他们遇到的数据库连接问题,并升级项目的依赖。首先,用户提供的错误信息是关于Spring Boot应用在初始化数据源时抛出的异常,具体是Druid连接池验证连接失败。同时,用户希望升级项目的依赖版本。
704 10
|
8月前
|
监控 Java 关系型数据库
Spring Boot整合MySQL主从集群同步延迟解决方案
本文针对电商系统在Spring Boot+MyBatis架构下的典型问题(如大促时订单状态延迟、库存超卖误判及用户信息更新延迟)提出解决方案。核心内容包括动态数据源路由(强制读主库)、大事务拆分优化以及延迟感知补偿机制,配合MySQL参数调优和监控集成,有效将主从延迟控制在1秒内。实际测试表明,在10万QPS场景下,订单查询延迟显著降低,超卖误判率下降98%。
356 5