文章目录
Spring 应用启动时出现内存溢出（OOM）是常见问题，通常与 初始化资源过多、配置不当 或 代码缺陷 有关。排查需结合 JVM 内存模型、Spring 启动流程及工具分析，步骤如下：
一、定位 OOM 类型
首先通过错误日志确定 OOM 的具体类型，不同区域的溢出对应不同问题：
java.lang.OutOfMemoryError: Java heap space
- 堆内存不足：Spring 启动时创建大量对象（如 Bean、缓存数据、初始化集合）超出堆容量。
java.lang.OutOfMemoryError: Metaspace
- 元空间不足：加载的类过多（如大量动态生成类、依赖包过大），超出元空间限制。
java.lang.OutOfMemoryError: Direct buffer memory
- 直接内存不足：NIO 直接内存分配过多（如 Netty 缓冲区、文件 IO 缓存）。
java.lang.StackOverflowError
- 栈内存溢出：Spring 启动时方法调用栈过深（如递归依赖、循环依赖处理不当）。
二、基础排查：调整 JVM 参数与日志
- 临时调大内存参数
先尝试增加内存排查是否因配置不足导致，启动时添加 JVM 参数：
# 堆内存（初始=最大，避免动态扩容）
-Xms2g -Xmx2g
# 元空间（根据依赖规模调整）
-XX:MetaspaceSize=256m -XX:MaxMetaspaceSize=512m
# 直接内存（若怀疑直接内存问题）
-XX:MaxDirectMemorySize=1g
若调大后启动成功，说明原配置不足，需根据实际需求优化参数。
- 开启 OOM 日志与堆转储
添加参数记录关键信息，便于后续分析：
# OOM 时自动生成堆转储文件（路径自定义）
-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/tmp/spring-oom.hprof
# 打印 GC 详细日志（观察内存增长趋势）
-XX:+PrintGCDetails -XX:+PrintGCTimeStamps -Xloggc:/tmp/spring-gc.log
三、堆内存溢出（Heap Space）排查
Spring 启动时堆溢出多因 初始化大量 Bean 或 加载大数据（如缓存预热、配置解析）。
1. 分析堆转储文件
使用工具分析
spring-oom.hprof堆转储文件，定位大对象或异常对象：
- 工具：Eclipse MAT（Memory Analyzer Tool）、JProfiler、VisualVM。
- 关键步骤：
- 打开堆转储文件，查看 Dominator Tree（支配树），找出占用内存最多的对象。
- 检查是否有 异常大的集合（如
HashMap、List），可能是初始化时加载了过多数据。- 查看 Spring Bean 实例：是否有不必要的单例 Bean 被大量创建，或 Bean 本身持有大对象（如缓存全量数据）。
2. 典型场景与解决
场景 1：Bean 数量过多
若项目依赖过多（如引入大量 Starter），Spring 会扫描并创建大量 Bean（尤其是@ComponentScan范围过大）。
解决：缩小扫描范围（@ComponentScan(basePackages = "com.xxx.core")），排除不需要的自动配置（@SpringBootApplication(exclude = XXXAutoConfiguration.class)）。场景 2：初始化时加载全量数据
如@PostConstruct方法中加载全表数据到内存（如List<User> allUsers = userMapper.selectAll()）。
解决：按需加载（分页/懒加载），或延迟初始化（非启动时加载）。场景 3：循环依赖导致的对象膨胀
虽然 Spring 支持循环依赖，但复杂循环可能导致对象初始化时持有大量引用，间接占用内存。
解决：通过@Lazy延迟注入，或重构代码消除循环依赖。
四、元空间溢出（Metaspace）排查
元空间存储类信息（类结构、方法、注解等），溢出通常因 加载类过多 或 类未被卸载。
1. 分析类加载情况
- 查看类加载数量：启动时添加参数
-XX:+TraceClassLoading -XX:+TraceClassUnloading，日志中记录所有加载/卸载的类，排查是否有异常类（如动态生成的代理类、重复加载的类）。- 工具分析：用
jmap -clstats <pid>查看类加载统计，重点关注：- 类总数是否过大（如超过 10 万）。
- 是否有大量动态代理类（如 CGLIB 代理，每个代理生成一个新类）。
- 是否有重复类加载（同一类被不同类加载器加载）。
2. 典型场景与解决
场景 1：依赖包过多/过大
如引入大量第三方库（如全量 Spring Cloud 组件），每个 Jar 包含大量类。
解决：剔除无用依赖（用mvn dependency:analyze检测），使用瘦身插件（如 Spring Boot 的spring-boot-maven-plugin排除冗余依赖）。场景 2：动态代理类泛滥
Spring AOP 中，@Transactional、@Async等注解会通过 CGLIB/JDK 生成代理类，若代理目标过多（如每个 Service 都被代理），会产生大量类。
解决：缩小 AOP 切点范围（@Pointcut("execution(* com.xxx.service.*Service.*(..))")），避免对无必要的类代理。场景 3：类加载器泄漏
自定义类加载器未被回收（如热部署工具、插件化框架），导致加载的类长期占用元空间。
解决：确保类加载器使用后被正确释放，避免静态引用持有类加载器。
五、直接内存溢出（Direct Buffer）排查
直接内存由 JVM 外部管理（如 NIO 的
DirectByteBuffer），溢出常见于 网络/IO 密集型应用。
1. 定位直接内存使用者
- 日志分析：添加 JVM 参数
-XX:TraceDirectMemoryAllocation跟踪直接内存分配，日志会显示分配位置（如sun.nio.ch.DirectBuffer.<init>）。- 代码排查：检查是否有大量
ByteBuffer.allocateDirect()调用，且未及时释放（直接内存不受 GC 自动管理，需手动调用Cleaner.clean()或等待 GC 触发清理）。
2. 典型场景与解决
场景 1：Netty 等框架的缓冲区配置过大
如 Netty 服务器设置ChannelOption.SO_RCVBUF过大，或ByteBuf未释放。
解决：合理设置缓冲区大小，使用ReferenceCountUtil.release(buf)手动释放，或启用 Netty 的泄漏检测（-Dio.netty.leakDetectionLevel=PARANOID）。场景 2：文件 IO 频繁使用直接内存
如读取大文件时用FileChannel.map()（默认使用直接内存）加载全文件。
解决：分片读取，避免一次性映射大文件。
六、栈溢出（StackOverflowError）排查
栈溢出通常因 方法调用链过深，Spring 启动时常见于：
循环依赖处理不当
虽然 Spring 能解决循环依赖，但复杂嵌套（如 A→B→C→A）可能导致初始化时方法调用栈过深。
解决：用@Lazy延迟注入，或重构为接口依赖。自定义 BeanPostProcessor 逻辑递归
若BeanPostProcessor的postProcessBeforeInitialization中调用了被代理的方法，可能触发递归调用。
解决：避免在处理器中调用目标 Bean 的方法，或通过原生对象（AopContext.currentProxy()）调用。复杂的 SpEL 表达式解析
启动时解析嵌套过深的 SpEL 表达式（如@Value("#{...}")中多层函数调用）可能导致栈溢出。
解决：简化 SpEL 表达式，或改为代码中初始化。
七、总结：排查流程梳理
- 查看错误日志：确定 OOM 类型（堆/元空间/直接内存）。
- 调整参数验证：临时调大对应内存区域，判断是否因配置不足。
- 生成并分析堆转储：用 MAT 等工具定位大对象、异常类或资源泄漏。
- 结合 Spring 特性排查：聚焦 Bean 初始化、类扫描、AOP 代理等环节。
- 优化与验证：减少不必要的对象/类加载，调整初始化逻辑，重新测试。
通过以上步骤，可逐步定位 Spring 启动时 OOM 的根因，最终从配置优化、代码重构或依赖管理等方面解决问题。