Может JVM восстанавливаться с OutOfMemoryError без перезапуска

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

• На самом деле может быть недостаточно памяти для выполнения запрошенных задач, даже после выполнения действий по восстановлению, таких как освобождение блока зарезервированной памяти. В этой ситуации ваше приложение может застрять в цикле, в котором оно неоднократно кажется, что восстанавливается, а затем снова исчерпывает память.

• OOME можно бросить в любую ветку. Если поток приложения или библиотека не предназначены для работы с ним, это может оставить некоторую долговечную структуру данных в неполном или несогласованном состоянии.

• Если потоки умирают в результате OOME, приложению может потребоваться перезапустить их как часть восстановления OOME. По крайней мере, это усложняет приложение.

• Предположим, что поток синхронизируется с другими потоками с помощью уведомления / ожидания или какого-либо механизма более высокого уровня. Если этот поток умирает из-за OOME, другие потоки могут остаться в ожидании уведомлений (и т. Д.), Которые никогда не приходят ... например. Разработка для этого может значительно усложнить приложение.

Таким образом, проектирование, реализация и тестирование приложения для восстановления из OOME могут быть трудными, особенно если приложение (или структура, в которой оно выполняется, или любая из библиотек, которые оно использует) является многопоточным. Лучше рассматривать OOME как фатальную ошибку.

См. Также мой ответ на связанный вопрос:

РЕДАКТИРОВАТЬ - в ответ на следующий вопрос:

Другими словами, если OOME создается на сервере приложений (jboss / websphere / ..) мне нужно перезапустить его?

Нет, вы не должны перезапустить. Но это, вероятно, мудро , особенно если у вас нет хорошего / автоматического способа проверки правильности работы службы.

JVM нормально восстановится. Но сервер приложений и само приложение могут или не могут восстановиться, в зависимости от того, насколько хорошо они спроектированы, чтобы справиться с этой ситуацией.(Мой опыт показывает, что некоторые серверы приложений не предназначены для того, чтобы справиться с этим, и что проектирование и реализация сложного приложения для восстановления из OOME сложны, а его правильное тестирование еще сложнее.)

EDIT 2

В ответ на этот комментарий:

«другие потоки могут остаться в ожидании уведомлений (и т. Д.), Которые никогда не приходят» Правда? Разве убитый поток не раскрутил бы свои стеки, высвобождая ресурсы по ходу, включая удерживаемые блокировки?

Да уж! Рассмотрим это:

Поток №1 выполняет это:

    synchronized(lock) {
         while (!someCondition) {
             lock.wait();
         }
    }
    // ...

Поток №2 выполняет следующее:

    synchronized(lock) {
         // do stuff
         lock.notify();
    }

Если поток №1 ожидает уведомления, а поток №2 получает сообщение OOME в // сделайте что-нибудь , то поток №2 не будет вызывать notify () , а поток №1 может навсегда застрять в ожидании уведомления, которого никогда не будет. Конечно, поток № 2 гарантированно освободит мьютекс для объекта lock ... но этого недостаточно!

В противном случае код, выполняемый потоком, не является безопасным в отношении исключений, что является более общей проблемой.

«Исключительная безопасность» - это не тот термин, о котором я слышал (хотя я знаю, что вы имеете в виду). Программы Java обычно не предназначены для обеспечения устойчивости к неожиданным исключениям. В самом деле, в сценарии, подобном описанному выше, сделать исключение приложения безопасным, вероятно, будет где-то между трудностями и невозможностью.

Вам понадобится какой-то механизм, посредством которого сбой потока №1 (из-за OOME) превращается в уведомление об ошибке межпотоковой связи для потока №2. Erlang делает это ... но не Java.Причина, по которой они могут делать это в Erlang, заключается в том, что процессы Erlang взаимодействуют с использованием строгих примитивов, подобных CSP; т.е. отсутствует совместное использование структур данных!

(Обратите внимание, что указанная выше проблема может возникнуть практически для любого неожиданного исключения ... а не только для исключений Error . Существуют определенные типы кода Java, в которых выполняется попытка восстановления после непредвиденное исключение , вероятно, закончится плохо.)