Java StackOverflowError 產生場景與排查實戰

Java StackOverflowError 產生場景與排查實戰

StackOverflowError 表示線程棧幀深度超過 JVM 限制。本文實驗三種常見觸發方式：遞歸調用無終止條件、大量線程併發、棧大小設定過小，並解析為何「大量區域變數」無法撐爆棧（Java 物件在堆、基本型區域變數在棧但編譯器優化、棧可動態擴展）。

場景一：無限遞歸（最經典、最易復現）

public class StackOverflowDemo {
    private static void recursive() {
        recursive(); // 無終止條件
    }
    public static void main(String[] args) {
        recursive(); // 幾千次調用後拋出 StackOverflowError
    }
}

排查：堆疊追蹤顯示大量重複行號，定位遞歸方法，補充終止條件或改寫為迴圈。

場景二：-Xss 設定過小 + 深度遞歸

// VM 參數：-Xss128k（預設通常 1024k）
public class SmallStackDemo {
    static void deep(int n) {
        if (n == 0) return;
        deep(n - 1);
    }
    public static void main(String[] args) {
        deep(5000); // 小棧下更快溢位
    }
}

建議：生產環境避免設極小 -Xss，預設 1MB 足夠絕多數業務；若業務確有深度遞歸，優先改迴圈。

場景三：大量線程併發（理論可觸發，實測受限於 OS/記憶體）

public class ThreadStackDemo {
    public static void main(String[] args) {
        while (true) {
            new Thread(() -> {
                while (true) { /* 空跑佔用棧 */ }
            }).start();
        }
    }
}

實測現象：記憶體增長至系統上限（如 7.9GB）後停滯，未拋出 OutOfMemoryError: unable to create native thread，原因可能為 OS 線程數限制（ulimit -u）或 JVM 內部保護機制。

為什麼「大量區域基本型變數」撐不爆棧？

1. Java 基本型區域變數確實在棧幀的區域變數表中，但 long a0=0; long a1=0; ... 這樣寫會被 JIT 優化為常數或直接捨棄（未使用）。
2. 即使不優化，棧幀大小固定（由方法簽名決定），區域變數表大小編譯期確定，單個方法無法無限增加區域變數。
3. Java 物件（含陣列）永遠在堆，棧只存引用。
4. HotSpot 棧支援動態擴展（部分平台），不像 C++ 固定棧大小。

排查工具與參數

最佳實踐

1. 遞歸必須有明確終止條件，且深度可控（< 1000）。
2. 深度不可控場景（如樹形結構遍歷）改用顯式棧（Deque）實現迴圈。
3. 生產環境保留預設 -Xss，僅在單元測試驗證深度遞歸時調小複現問題。
4. 異步任務提交線程池（ThreadPoolExecutor），避免無限創建線程耗盡系統資源。