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 的根因，最終從配置優化、代碼重構或依賴管理等方面解決問題。