一、未處理的異常導致進程退出

1. 主線程拋出未捕獲異常Spring Boot 的啟動入口是 SpringApplication.run()，若啟動過程中（如容器初始化、Bean 加載階段）拋出未捕獲的 Exception 或 Error（如 OutOfMemoryError、NoClassDefFoundError），且未被框架捕獲，會直接導致主線程終止，進程退出。例：
   • 配置文件錯誤（如 @Value 注入的屬性不存在且無默認值）導致 IllegalArgumentException。
   • 自定義 CommandLineRunner 或 ApplicationRunner 的 run 方法拋出未處理異常。
2. 非守護線程拋出未捕獲異常Java 中，非守護線程（用戶線程）的未捕獲異常若未被 Thread.UncaughtExceptionHandler 處理，會導致該線程終止；若所有非守護線程都終止，進程會退出。例：
   • 業務線程池中的線程執行任務時拋出 RuntimeException 且未捕獲，若線程池核心線程全部異常終止，且無新任務觸發線程重建，可能導致進程 “空轉” 后退出（視線程池配置而定）。
   • 定時任務（如 @Scheduled）的執行邏輯拋出未處理異常，若框架未配置全局異常處理器，可能導致定時任務線程終止，極端情況下引發進程退出。

二、內存問題導致崩潰

1. OutOfMemoryError（OOM）當 JVM 無法分配足夠內存時，會拋出 OutOfMemoryError，若該異常未被捕獲（通常無法捕獲，因為內存已耗盡），進程會直接崩潰。常見 OOM 場景：
   • 堆內存溢出（Java heap space）：對象創建過多且未及時回收（如無限循環創建對象、內存泄漏），堆內存（-Xmx）設置不足。
   • 方法區 / 元空間溢出（Metaspace）：動態生成大量類（如 CGLIB 代理、反射頻繁生成類），元空間（-XX:MaxMetaspaceSize）設置不足。
   • 棧溢出（StackOverflowError）：遞歸調用過深，棧內存（-Xss）不足，雖不屬于 OOM，但會直接導致線程終止，若發生在主線程則進程退出。
2. 內存泄漏長期運行的應用中，內存泄漏會逐漸耗盡可用內存，最終觸發 OOM 導致宕機。例：
   • 靜態集合（如 static List）無限添加對象且不清理。
   • 未關閉的資源（如數據庫連接、文件流）導致對象無法被 GC 回收。
   • 第三方庫（如緩存框架）使用不當，導致內存占用持續增長。

三、資源耗盡導致不可用或崩潰

1. 文件描述符（File Descriptor）耗盡每個打開的文件、網絡連接（Socket）都會占用文件描述符。若應用頻繁創建連接卻不釋放（如未關閉的數據庫連接、HTTP 客戶端連接），或系統默認文件描述符上限（ulimit -n）過低，會導致 Too many open files 錯誤，最終引發 IO 操作失敗，甚至進程崩潰。
2. 線程耗盡若應用無限制創建線程（如每次請求創建新線程），或線程池核心線程 / 最大線程數設置過大，會導致系統線程數超過內核限制（/proc/sys/kernel/threads-max），引發 OutOfMemoryError: unable to create new native thread，最終進程崩潰。
3. 端口耗盡客戶端短連接場景下（如頻繁創建 outbound 連接），若本地端口（臨時端口，默認范圍 32768-60999）被耗盡，會導致新連接無法建立（Address already in use），若核心業務依賴外部服務，可能因無法通信而觸發應用自我終止（如健康檢查失敗）。

四、外部信號或系統干預

1. 用戶 / 腳本發送終止信號
   • kill -9 <pid>：強制終止信號（SIGKILL），進程無法捕獲，會立即退出。
   • kill <pid>：默認發送 SIGTERM 信號，若應用未注冊信號處理器，會被動退出（Spring Boot 默認不處理 SIGTERM，需自定義 ShutdownHook 優雅關閉，但強制終止仍會宕機）。
2. 系統 OOM Killer 干預當操作系統內存耗盡時，內核的 OOM Killer 會根據進程的內存占用、優先級等評分（oom_score）選擇 “犧牲品” 并殺死，釋放內存。Spring Boot 應用若占用內存過高（如頻繁 OOM 前的內存暴漲），可能被 OOM Killer 選中，進程會被強制終止（可通過 dmesg | grep -i 'killed process' 查看記錄）。
3. 容器 / 編排工具的健康檢查失敗在 Docker、K8s 等環境中，若應用健康檢查（如 Actuator 的 /health 端點）持續失敗，容器會被自動重啟或殺死（如 K8s 的 livenessProbe 失敗觸發重啟）。

五、配置錯誤或依賴沖突

1. 啟動時配置錯誤
   • 端口被占用（Address already in use）：若 server.port 已被其他進程占用，且未配置 server.port=0（隨機端口），應用啟動失敗后直接退出。
   • 依賴沖突：如不同版本的 Spring 組件、Jackson 等庫沖突，導致 NoSuchMethodError、ClassCastException 等，啟動時崩潰。
   • 外部服務不可用：若應用啟動依賴數據庫、Redis 等服務，且未配置重試或容錯（如 spring.datasource.continue-on-error=false），連接失敗會導致啟動終止。
2. 運行時配置不當
   • 線程池配置不合理：如核心線程數為 0、隊列容量為 0，且拒絕策略為 AbortPolicy（默認），高并發下觸發 RejectedExecutionException，若未處理可能導致關鍵任務失敗，間接引發應用退出。
   • 超時配置缺失：如數據庫連接超時未設置，網絡波動時線程長期阻塞，導致線程池耗盡，應用失去響應，最終被監控系統殺死。

六、JVM 或系統級故障

1. JVM 內部錯誤（Internal Error）罕見但可能發生，如 JVM 自身 Bug、硬件故障（內存損壞）導致的 Internal Error，會直接觸發進程崩潰（通常伴隨 hs_err_pid<pid>.log 日志）。
2. 系統級問題
   • 磁盤滿：應用寫入日志、臨時文件時，若磁盤空間耗盡（No space left on device），可能導致 IO 異常，若核心邏輯依賴文件操作，會引發應用崩潰。
   • 網絡中斷：分布式應用中，若與注冊中心（如 Eureka、Nacos）、配置中心的連接長期中斷，且未配置容錯機制，可能觸發自我保護機制失敗后退出。

如何排查宕機原因？

1. 查看日志：優先檢查應用日志（如 application.log）的最后輸出，是否有異常堆棧（如 OOM、未處理的 Exception）。
2. JVM 崩潰日志：若發生 JVM 內部錯誤或 OOM，會生成 hs_err_pid<pid>.log，記錄崩潰時的內存、線程狀態。
3. 系統日志：通過 dmesg、/var/log/messages 查看是否被 OOM Killer 殺死，或系統資源不足的記錄。
4. 監控指標：結合 Prometheus、Grafana 等工具，查看宕機前的內存、CPU、線程數、文件描述符等指標是否異常。

一、核心內存參數（必知）

1. 堆內存設置（最常用）

• -Xms：初始堆內存大小（JVM 啟動時分配的內存）
• -Xmx：最大堆內存大小（JVM 運行中允許使用的最大內存）

# 示例：初始堆 512M，最大堆 1024M
java -Xms512m -Xmx1024m -jar your-project.jar

2. 新生代 / 老年代設置（進階）

• -Xmn：新生代內存大小（建議為堆內存的 1/3 ~ 1/4）
• -XX:NewRatio：新生代與老年代的比例（默認 2，表示老年代：新生代 = 2:1）

# 示例：堆內存 1024M，新生代 256M（老年代則為 768M）
java -Xms1024m -Xmx1024m -Xmn256m -jar your-project.jar

# 示例：通過 NewRatio 設置老年代:新生代 = 3:1（堆內存 1024M 時，新生代 256M，老年代 768M）
java -Xms1024m -Xmx1024m -XX:NewRatio=3 -jar your-project.jar

3. 元空間（Metaspace）設置（Java 8+）

• -XX:MetaspaceSize：元空間初始大小（觸發 GC 的閾值）
• -XX:MaxMetaspaceSize：元空間最大大小

# 示例：元空間初始 128M，最大 256M
java -XX:MetaspaceSize=128m -XX:MaxMetaspaceSize=256m -jar your-project.jar

二、組合配置示例

# 完整示例：堆內存 2G（初始=最大），新生代 512M，元空間最大 512M，使用 prod 環境配置
java -Xms2g -Xmx2g -Xmn512m -XX:MetaspaceSize=256m -XX:MaxMetaspaceSize=512m -jar your-project.jar --spring.profiles.active=prod

三、驗證參數是否生效

1. 先查進程 ID（Linux 用 ps -ef | grep java，Windows 用 tasklist | findstr java）
2. 執行 jinfo <進程ID>，在輸出中搜索設置的參數（如 Xms、Xmx）。

# 查進程 ID
ps -ef | grep your-project.jar

# 假設進程 ID 是 12345，查看參數
jinfo 12345 | grep -E "Xms|Xmx|Metaspace"

四、注意事項

1. 參數順序：JVM 參數（如 -Xms）必須放在 -jar 前面，否則不生效；應用參數（如 --spring.profiles.active）放在 -jar 后面。
2. 內存上限：最大堆內存（Xmx）不應超過服務器物理內存的 70%（避免與其他進程搶占資源）。
3. 版本差異：Java 8 及以上用 Metaspace 參數，Java 7 及以下用 PermSize（永久代）參數（如 -XX:PermSize=128m -XX:MaxPermSize=256m）。

一、核心內存參數（按內存區域分類）

1. 堆內存參數（JVM 管理的主要內存區域，存放對象實例）

2. 非堆內存參數（存放類信息、方法元數據等，不參與垃圾回收）

3. 直接內存參數（堆外內存，用于 NIO 操作）

4. 內存調試與監控參數（輔助排查內存問題）

二、完整配置示例（結合機器內存）

# 堆內存：初始 2G，最大 4G（不超過物理內存的 50%）
# 新生代：1G（堆內存的 1/4 ~ 1/3）
# 元空間：最大 512M（根據類數量調整）
# 直接內存：最大 1G（若應用大量使用 NIO，可適當增加）
# 開啟 OOM 時自動 dump 堆日志
java -Xms2g -Xmx4g -Xmn1g \
     -XX:MetaspaceSize=256m -XX:MaxMetaspaceSize=512m \
     -XX:MaxDirectMemorySize=1g \
     -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/var/log/app/heapdump.hprof \
     -jar your-project.jar --spring.profiles.active=prod

三、注意事項（結合機器內存配置）

1. 堆內存上限：-Xmx 建議不超過服務器物理內存的 70%（例如 8GB 內存，-Xmx 不超過 5~6GB），避免與其他進程（如數據庫、緩存）搶占內存導致系統卡頓。
2. 初始與最大堆一致：-Xms 與 -Xmx 設為相同值，避免 JVM 運行中動態調整堆大小（會觸發額外 GC，影響性能）。
3. 元空間與直接內存：若應用依賴大量第三方庫（類數量多），需調大 MaxMetaspaceSize；若頻繁使用 NIO（如 Netty、文件上傳），需調大 MaxDirectMemorySize。
4. 監控與調整：通過 jstat（監控 GC 情況）、jmap（查看內存分布）或可視化工具（JConsole、VisualVM）觀察內存使用，逐步優化參數。

一、可能的結果及原因

1. 啟動直接失敗（最常見）

• JVM 層面：Error occurred during initialization of VM Could not reserve enough space for object heap（無法預留足夠的堆內存）。
• 操作系統層面：Linux 可能報 out of memory，Windows 可能提示 “內存不足”。

2. 啟動成功，但運行中崩潰或卡頓

• 頻繁卡頓 / 性能暴跌：當 JVM 實際使用的內存超過物理內存時，操作系統會將部分內存數據寫入磁盤（swap 分區），而磁盤 IO 速度遠低于內存，導致應用響應極慢。
• 運行中 OOM 崩潰：即使啟動時內存足夠，若運行中內存需求持續增長（如大量對象創建），超過系統實際能提供的內存（物理 + swap），會觸發 OutOfMemoryError 導致進程崩潰。
• 被操作系統殺死：Linux 有 OOM Killer 機制，當系統內存耗盡時，會優先殺死 “內存占用高且優先級低” 的進程（如 JVM 進程），直接導致服務中斷。

二、關鍵影響因素

1. 操作系統虛擬內存（swap）：若機器配置了 swap 分區（Linux）或頁面文件（Windows），系統會將部分磁盤空間作為 “虛擬內存” 臨時替代物理內存。若 JVM 配置的內存 ≤ 物理內存 + swap，可能啟動成功，但性能會受嚴重影響。
2. JVM 內存參數的 “實際使用” 特性：
   • -Xmx 是 “最大堆內存”，啟動時 JVM 不會立即占用全部，而是按需增長（但會預留地址空間）。
   • 若配置的 -Xmx 很大，但應用實際運行中內存需求較小（遠低于物理內存），可能暫時正常運行（但仍有風險）。
3. 操作系統內存分配策略：Linux 有 “內存過度分配（overcommit）” 機制，默認允許進程申請超過實際可用的內存（假設進程不會真的用完），但實際使用時若內存不足，會觸發 OOM Killer 殺進程。

三、總結

• 若配置的內存 > 物理內存 + swap 總和：啟動失敗，無法分配內存。
• 若配置的內存 ≤ 物理內存 + swap 總和：可能啟動成功，但運行中會因頻繁 swap 導致性能崩潰，或被系統殺死。