Почему возможно восстановление после StackOverflowError?

Я удивлен тем, как можно продолжить выполнение даже после того, как StackOverflowErrorв Java произошло.

Я знаю, что StackOverflowErrorэто подкласс класса Error. Класс Error декументируется как «подкласс Throwable, который указывает на серьезные проблемы, которые разумное приложение не должно пытаться уловить».

Это больше похоже на рекомендацию, чем на правило, утверждающее, что перехват ошибки, такой как StackOverflowError, на самом деле разрешен, и программист может этого не делать. И видите, я тестировал этот код, и он нормально завершается.

public class Test
{
    public static void main(String[] args)
    {
        try {
            foo();
        } catch (StackOverflowError e) {
            bar();
        }
        System.out.println("normal termination");
    }

    private static void foo() {
        System.out.println("foo");
        foo();
    }

    private static void bar() {
        System.out.println("bar");
    }
}

Как это может быть? Я думаю, что к моменту возникновения ошибки StackOverflowError стек должен быть настолько заполнен, чтобы не было места для вызова другой функции. Работает ли блок обработки ошибок в другом стеке или что здесь происходит?

Когда стек переполняется и StackOverflowErrorвыбрасывается, обычная обработка исключений раскручивает стек. Раскрутка стопки означает:

• прервать выполнение текущей активной функции
• удалите его кадр стека, продолжите вызывающую функцию
• прервать выполнение вызывающего
• удалите его кадр стека, продолжите вызывающую функцию
• и так далее...

... пока не будет обнаружено исключение. Это нормально (фактически, необходимо) и не зависит от того, какое исключение выбрано и почему. Поскольку вы перехватываете исключение за пределами первого вызова foo(), все тысячи fooкадров стека, заполнившие стек, были размотаны, и большая часть стека может быть использована снова.

Когда выбрасывается StackOverflowError, стек заполнен. Однако когда он перехватывается , все эти fooвызовы выталкиваются из стека. barможет работать нормально, потому что стек больше не переполняется foos. (Обратите внимание, что я не думаю, что JLS гарантирует, что вы сможете восстановиться после такого переполнения стека.)

Когда происходит StackOverFlow, JVM выскакивает на защелку, освобождая стек.

В вашем примере он избавляется от всех сложенных файлов foo.

Потому что стек на самом деле не переполняется. Лучшее имя может быть AttemptToOverflowStack. В основном это означает, что последняя попытка настроить фрейм стека дает ошибку, потому что в стеке недостаточно свободного места. На самом деле в стеке может быть много места, но недостаточно места. Таким образом, какая бы операция ни зависела от успешного выполнения вызова (обычно это вызов метода), она никогда не выполняется, и все, что остается программе, - это иметь дело с этим фактом. Это означает, что это действительно ничем не отличается от любого другого исключения. Фактически, вы можете поймать исключение в функции, выполняющей вызов.

Как уже было сказано, после перехвата a можно выполнять код и, в частности, вызывать функции, StackOverflowErrorпоскольку обычная процедура обработки исключений JVM раскручивает стек между точками throwи catchточками, освобождая пространство стека для использования. И ваш эксперимент подтверждает это.

Однако, это не совсем то же самое , как сказать , что это, в общем, можно восстановить из StackOverflowError.

StackOverflowErrorIS-A VirtualMachineError, который IS-AN Error. Как вы отметили, Java дает несколько расплывчатых советов для Error:

указывает на серьезные проблемы, которые разумное приложение не должно пытаться уловить

и вы, резонно заключить , что должно звучит как ловить Errorможет быть хорошо в некоторых обстоятельствах. Обратите внимание, что выполнение одного эксперимента не демонстрирует, что что-то в целом безопасно. Это могут сделать только правила языка Java и спецификации используемых вами классов. A VirtualMachineError- это особый класс исключения, поскольку спецификация языка Java и спецификация виртуальной машины Java предоставляют информацию о семантике этого исключения. В частности, последний говорит :

Реализация виртуальной машины Java создает объект, являющийся экземпляром подкласса класса, VirtualMethodErrorкогда внутренняя ошибка или ограничение ресурсов не позволяют реализовать семантику, описанную в этой главе. Эта спецификация не может предсказать, где могут возникнуть внутренние ошибки или ограничения ресурсов, и не требует точного определения того, когда о них можно сообщить. Таким образом, любой из VirtualMethodErrorподклассов, определенных ниже, может быть запущен в любое время во время работы виртуальной машины Java:

...

• StackOverflowError: Реализация виртуальной машины Java исчерпала пространство стека для потока, как правило, из-за того, что поток выполняет неограниченное количество рекурсивных вызовов в результате ошибки в выполняющейся программе.

Ключевой проблемой является то, что вы «не можете предсказать», где и когда StackOverflowErrorбудет брошен. Нет никаких гарантий, куда он не будет брошен. Например, вы не можете полагаться на то, что он будет брошен при входе в метод. Его можно бросить в точку внутри метода.

Эта непредсказуемость потенциально губительна. Поскольку он может быть брошен внутри метода, он может быть брошен частично через последовательность операций, которые класс считает одной «атомарной» операцией, оставляя объект в частично измененном, несовместимом состоянии. Когда объект находится в несовместимом состоянии, любая попытка использовать этот объект может привести к ошибочному поведению. Во всех практических случаях вы не можете знать, какой объект находится в несогласованном состоянии, поэтому вы должны предположить, что ни один объект не заслуживает доверия. Следовательно, любая операция восстановления или попытка продолжить после обнаружения исключения могут иметь ошибочное поведение. Поэтому единственное безопасное решение - не пойматьStackOverflowError, а скорее позволить программе завершить работу. (На практике вы можете попытаться вести журнал ошибок, чтобы помочь в устранении неполадок, но вы не можете полагаться на правильную работу этого журнала). То есть из файлаStackOverflowError .