Краткий ответ

System.exit() инициирует завершение JVM, а не обычное завершение текущего вызова с раскруткой стека. Поэтому JVM не обязана выполнять finally в потоке, вызвавшем System.exit().

finally гарантированно участвует в обычном завершении конструкции try — например, при возврате, исключении или переходе управления. Завершение всей JVM является отдельным сценарием и может прервать такую раскрутку.

Исторический контекст

Конструкция finally предназначена для структурированного освобождения ресурсов и выполнения обязательных действий при завершении блока try. Она решает проблему, когда управление покидает блок не только обычным способом, но и через return или исключение.

Однако finally является частью выполнения Java-кода, а не механизмом, управляющим остановкой процесса. Для завершения приложения JVM предоставляет отдельные операции завершения, которые не обязаны имитировать обычную передачу управления между методами.

Постановка проблемы

Если критически важная запись, освобождение ресурса или отправка сообщения помещены в finally, разработчик может ошибочно считать их гарантированными. При вызове System.exit() такой код может не выполниться, что приводит к незаписанным данным, незакрытым соединениям и неполному журналированию.

Это особенно опасно в серверных приложениях: принудительное завершение процесса может произойти раньше, чем поток успеет выполнить ожидаемую очистку. Поэтому finally нельзя рассматривать как абсолютную гарантию при остановке JVM.

Подробное решение

При обычном завершении try JVM выполняет семантически эквивалентную раскрутку стека: сначала обрабатывается return или исключение, затем выполняется finally. Исключение из finally может заменить исходный результат или исходное исключение.

При вызове System.exit() запускается процедура завершения JVM. Она не обязана раскручивать стек вызвавшего потока, поэтому finally, расположенный вокруг вызова, может быть пропущен:

public class Demo {
    public static void main(String[] args) {
        try {
            System.out.println("before");
            System.exit(0);
        } finally {
            System.out.println("cleanup");
        }
    }
}

В нормальном сценарии будет выведено before, а cleanup не гарантирован. Во время завершения JVM могут выполняться зарегистрированные shutdown hooks, но это не означает автоматического выполнения всех finally во всех потоках.

Для обычного завершения приложения лучше передавать управление наружу: корректно закрывать ресурсы через try-with-resources, останавливать рабочие потоки и ждать их завершения. System.exit() следует оставлять для специально предусмотренного завершения процесса, понимая, что он не является заменой протоколу graceful shutdown.

Ещё более жёсткий вариант — Runtime.halt(): он немедленно останавливает JVM и не запускает shutdown hooks. Ни System.exit(), ни Runtime.halt() нельзя использовать как гарантию выполнения произвольного finally.

Ситуация из практики

В консольном импортёре после обработки файла разработчик поместил запись итоговой статистики в finally, а при ошибке конфигурации вызывает System.exit(1). При такой ошибке статистика иногда не появляется, потому что поток завершается во время процедуры остановки JVM.

Рассматривались два варианта. Перенос записи в shutdown hook улучшает обработку сигнала завершения, но hook может не успеть завершиться, а при Runtime.halt() он не запускается. Оставление записи только в finally проще, но не покрывает System.exit() и аварийное завершение процесса.

Выбранное решение — сначала явно выполнить необходимую запись и закрытие ресурсов, затем завершить процесс с ненулевым кодом. Для серверного приложения вместо System.exit() применили управляемое завершение: прекратили приём новых задач, дождались активных операций и закрыли ресурсы. Это устранило потерю итоговых данных в штатных сценариях остановки.

Что кандидаты часто упускают

Выполнится ли finally при необработанном исключении?

Да, если JVM продолжает работу и исключение распространяется обычным образом по стеку вызовов. Перед передачей исключения вызывающий метод выполняются блоки finally на соответствующих участках стека. Исключение составляет не само отсутствие catch, а прекращение работы JVM или процесса, при котором Java-код может не получить возможности завершиться.

Запускает ли System.exit() shutdown hooks вместо finally?

Не вместо конкретного finally, а в рамках отдельного механизма завершения JVM. Зарегистрированные hooks обычно запускаются при инициированном завершении, но их выполнение не превращает раскрутку стеков всех потоков в обязательную процедуру. Поэтому hook подходит для общей логики остановки, но не является гарантией при любом виде завершения.

Чем Runtime.halt() отличается от System.exit() в контексте очистки?

System.exit() инициирует процедуру завершения JVM и допускает запуск shutdown hooks. Runtime.halt() принудительно прекращает работу JVM без выполнения shutdown hooks. В обоих случаях нельзя полагаться на выполнение finally; halt() даёт ещё меньше гарантий и обычно оправдан только при невозможности безопасно продолжать работу.