java try-catch-finally 遞歸題

Question

public class Foo {

    public static void main(String[] args) {
        foo();
    }

    public static void foo() {
        try {
            System.out.println("try");
            foo();
        } catch (Throwable e) {
            System.out.println("catch");
            foo();
        } finally {
                System.out.println("finally");
                foo();
        }
    }
}

誰能解釋這個代碼的output？

1.output on eclipse（無盡）客戶端模式：

    try
    try
    ....


    ...
    ...
    tryfinallyfinally
    tryfinallyfinally
    try
    try
    try
    tryfinallyfinally
    tryfinallyfinally
    try
    tryfinallyfinally
    tryfinallyfinally
    try
    ....
    ....

2.output on linux（崩潰）服務器模式：

    try
    try
    ...

    ...
    try
    try
    try
    try
    try
    try
    MISSING EXCEPTION HANDLER for pc 0x00002aaaab1c53f0 and handler bci -1
       Exception:

     Compiled exception table :
    ExceptionHandlerTable (size = 3304 bytes)
    catch_pco = 700 (1 entries)
      bci -1 at scope depth 0 -> pco 11039
    catch_pco = 1736 (1 entries)
      bci -1 at scope depth 0 -> pco 11473
    catch_pco = 1756 (1 entries)
      bci -1 at scope depth 0 -> pco 11433
    catch_pco = 1776 (1 entries)

Answer 1

我想我從“Java Puzzlers”一書中記得這一點。 try 塊執行無限遞歸，這很快導致 StackOverflowError 被拋出。 try 和 catch 塊恢復遞歸，但剩余堆棧相對較小。 但是，隨着每個遞歸調用返回，剩余的堆棧再次變大......

最終結果是 forms 的調用圖，其深度取決於堆棧的大小； 使用主流 JVM 的默認堆棧大小，樹變得如此之大，以至於您必須等待數十億年才能完全遍歷它並終止程序。

編輯：這就是您在客戶端模式下看到的：調用圖的遍歷。 您在服務器模式下的 Linux 上看到的是 JVM 錯誤或硬件缺陷（有故障的 RAM 可能會產生這種影響）。