Spring 应用启动时出现内存溢出（OOM）是常见问题，通常与 初始化资源过多、配置不当 或 代码缺陷 有关。排查需结合 JVM 内存模型、Spring 启动流程及工具分析，步骤如下：

一、定位 OOM 类型

首先通过错误日志确定 OOM 的具体类型，不同区域的溢出对应不同问题：

1. java.lang.OutOfMemoryError: Java heap space

• 堆内存不足：Spring 启动时创建大量对象（如 Bean、缓存数据、初始化集合）超出堆容量。

2. java.lang.OutOfMemoryError: Metaspace

• 元空间不足：加载的类过多（如大量动态生成类、依赖包过大），超出元空间限制。

3. java.lang.OutOfMemoryError: Direct buffer memory

• 直接内存不足：NIO 直接内存分配过多（如 Netty 缓冲区、文件 IO 缓存）。

4. java.lang.StackOverflowError

• 栈内存溢出：Spring 启动时方法调用栈过深（如递归依赖、循环依赖处理不当）。

二、基础排查：调整 JVM 参数与日志

1. 临时调大内存参数
   先尝试增加内存排查是否因配置不足导致，启动时添加 JVM 参数：

# 堆内存（初始=最大，避免动态扩容）
-Xms2g -Xmx2g 
# 元空间（根据依赖规模调整）
-XX:MetaspaceSize=256m -XX:MaxMetaspaceSize=512m 
# 直接内存（若怀疑直接内存问题）
-XX:MaxDirectMemorySize=1g 

若调大后启动成功，说明原配置不足，需根据实际需求优化参数。

2. 开启 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。
• 关键步骤：

1. 打开堆转储文件，查看 Dominator Tree（支配树），找出占用内存最多的对象。
2. 检查是否有 异常大的集合（如 HashMap、List），可能是初始化时加载了过多数据。
3. 查看 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 启动时常见于：

1. 循环依赖处理不当
   虽然 Spring 能解决循环依赖，但复杂嵌套（如 A→B→C→A）可能导致初始化时方法调用栈过深。
   解决：用 @Lazy 延迟注入，或重构为接口依赖。

2. 自定义 BeanPostProcessor 逻辑递归
   若 BeanPostProcessor 的 postProcessBeforeInitialization 中调用了被代理的方法，可能触发递归调用。
   解决：避免在处理器中调用目标 Bean 的方法，或通过原生对象（AopContext.currentProxy()）调用。

3. 复杂的 SpEL 表达式解析
   启动时解析嵌套过深的 SpEL 表达式（如 @Value("#{...}") 中多层函数调用）可能导致栈溢出。
   解决：简化 SpEL 表达式，或改为代码中初始化。

七、总结：排查流程梳理

1. 查看错误日志：确定 OOM 类型（堆/元空间/直接内存）。
2. 调整参数验证：临时调大对应内存区域，判断是否因配置不足。
3. 生成并分析堆转储：用 MAT 等工具定位大对象、异常类或资源泄漏。
4. 结合 Spring 特性排查：聚焦 Bean 初始化、类扫描、AOP 代理等环节。
5. 优化与验证：减少不必要的对象/类加载，调整初始化逻辑，重新测试。

通过以上步骤，可逐步定位 Spring 启动时 OOM 的根因，最终从配置优化、代码重构或依赖管理等方面解决问题。