Возможно ли какое-то нормальное восстановление программы после возникновения иксепшна OutOfMemoryError (который как известно наследует Error)?
Имеет ли смысл
try {
}
catch (OutOfMemoryError ex) {
// hope that everything will be OK? OR
// try to recover in some way?
Здравствуйте, leokom, Вы писали:
L>Возможно ли какое-то нормальное восстановление программы после возникновения иксепшна OutOfMemoryError (который как известно наследует Error)? L>Имеет ли смысл
Здравствуйте, sss1024, Вы писали:
S>Здравствуйте, leokom, Вы писали:
L>>Возможно ли какое-то нормальное восстановление программы после возникновения иксепшна OutOfMemoryError (который как известно наследует Error)? L>>Имеет ли смысл
S>да.
А какую разумную процедуру восстановления можно предложить? Виртуальная машина не находится ли после этого еррора уже в таком состоянии с которого ее "не поднять"?
Здравствуйте, leokom, Вы писали:
L>Возможно ли какое-то нормальное восстановление программы после возникновения иксепшна OutOfMemoryError (который как известно наследует Error)? L>Имеет ли смысл
L>...
В общем случае не имеет, потому что OOME может возникнуть в любом месте кода (например, при банальном toString()).
L>А какую разумную процедуру восстановления можно предложить? Виртуальная машина не находится ли после этого еррора уже в таком состоянии с которого ее "не поднять"?
а что поднимать-то. Просто память кончилась
Runtime.gc()
Thread.sleep(1000)
дальше удалить что-нибудь ненужное или по обстоятельствам.
Здравствуйте, sss1024, Вы писали:
S>а что поднимать-то. Просто память кончилась
S>Runtime.gc() S>Thread.sleep(1000)
S>дальше удалить что-нибудь ненужное или по обстоятельствам.
-1
Спецификация гарантирует, что перед тем, как бросить out of memory, jvm сделает все возможное для того, чтобы попытаться очистить память (запустит full collection, соберет soft references).
DZ>-1 DZ>Спецификация гарантирует, что перед тем, как бросить out of memory, jvm сделает все возможное для того, чтобы попытаться очистить память (запустит full collection, соберет soft references).
Здравствуйте, sss1024, Вы писали:
DZ>>-1 DZ>>Спецификация гарантирует, что перед тем, как бросить out of memory, jvm сделает все возможное для того, чтобы попытаться очистить память (запустит full collection, соберет soft references).
S>и что
то что повторный запуск сборщика мусора и ожидание 1 секунду настолько редко помогает при OOM, что рассчитывать не него не стоит.
Здравствуйте, leokom, Вы писали:
L>Возможно ли какое-то нормальное восстановление программы после возникновения иксепшна OutOfMemoryError (который как известно наследует Error)? L>Имеет ли смысл
Тут тебе человек написал что имеет, я сначала с этим утверждением был не согласен но полез в спецификацию и вот что нарыл :
11.5.2.2 Virtual Machine Errors
A Java Virtual Machine throws an object that is an instance of a subclass of the class VirtualMachineError when an internal error or resource limitation prevents it from implementing the semantics of the Java Language. This language specification and the Java Virtual Machine Specification define the following virtual machine errors:
InternalError: An internal error has occurred in a Java Virtual Machine, because of a fault in the software implementing the virtual machine, a fault in the underlying host system software, or a fault in the hardware. This error is delivered asynchronously when it is detected, and may occur at any point in a Java program.
OutOfMemoryError: A Java Virtual Machine has run out of either virtual or physical memory, and the automatic storage manager wasn't able to reclaim enough memory to satisfy an object creation request.
StackOverflowError: A Java Virtual Machine has run out of stack space for a thread, typically because the thread is doing an unbounded number of recursive invocations due to a fault in the executing program.
UnknownError: An exception or error has occurred but, for some reason, a Java Virtual Machine is unable to report the actual exception or error.
A sophisticated Java program may be designed to handle OutOfMemoryError and attempt to recover from it, perhaps by carefully dropping references to objects.
We are exploring enhancements to Java to simplify handling of out-of-memory conditions. One possibility would be to support automatic suspension of a thread which encounters an OutOfMemoryError and allow another thread to handle the error situation. Such a technique might also permit a Java program to recover from a StackOverflowError if this overflow does not result from a nonterminating recursion. Suggestions for other approaches are welcomed.
Здравствуйте, sss1024, Вы писали:
S>а что поднимать-то. Просто память кончилась S>Runtime.gc() S>Thread.sleep(1000) S>дальше удалить что-нибудь ненужное или по обстоятельствам.
Да уж, вирус с sql.ru расползается с невероятной скоростью. Меня там совсем не давно пытались убедить в том что это отличное решение. Уважаемый, где вы этой дряни набрались?
J>We are exploring enhancements to Java to simplify handling of out-of-memory conditions. One possibility would be to support automatic suspension of a thread which encounters an OutOfMemoryError and allow another thread to handle the error situation. Such a technique might also permit a Java program to recover from a StackOverflowError if this overflow does not result from a nonterminating recursion. Suggestions for other approaches are welcomed.
То есть, получается разработчики джавы еще сами толком не знают что в этом случае делать и ищут красивые выходы из ситуации. (про поток-обработчик).
Но так и не ясно что делать с существующими вирт. машинами джавы... Так как улучшения про которые они тут пишут еще только "в проекте"
Излишнее цитирование удалено. Обратите внимания на правила форума. В случае дальнейшего их нарушения ваши права на RSDN могут быть ограничены режимом read-only.
Здравствуйте, jitm, Вы писали:
J> Тут тебе человек написал что имеет, я сначала с этим утверждением был не согласен но полез в спецификацию и вот что нарыл : J>
J>We are exploring enhancements to Java to simplify handling of out-of-memory conditions. One possibility would be to support automatic suspension of a thread which encounters an OutOfMemoryError and allow another thread to handle the error situation. Such a technique might also permit a Java program to recover from a StackOverflowError if this overflow does not result from a nonterminating recursion. Suggestions for other approaches are welcomed.
С некоторых пор за объемами памяти можно наблюдать через JMX. Эта функциональность позволяет навесить специальный слушатель, и когда размер свободной памяти будет приближатся к критическому, то выполнять нужные действия в контексте своего приложения.
Здравствуйте, jitm, Вы писали:
J> Тут тебе человек написал что имеет, я сначала с этим утверждением был не согласен но полез в спецификацию и вот что нарыл :
J>...
J>OutOfMemoryError: A Java Virtual Machine has run out of either virtual or physical memory, and the automatic storage manager wasn't able to reclaim enough memory to satisfy an object creation request.
J>...
J>We are exploring enhancements to Java to simplify handling of out-of-memory conditions. One possibility would be to support automatic suspension of a thread which encounters an OutOfMemoryError and allow another thread to handle the error situation. Such a technique might also permit a Java program to recover from a StackOverflowError if this overflow does not result from a nonterminating recursion. Suggestions for other approaches are welcomed.
Ключевые моменты:
ОМЕ может случиться в любой точке программы, где создается новый объект. Невозможно заранее предсказать где;
Можно предположить существование программы, которая создает объекты в одном/нескольких строго определенных местах. При этом она использует алгоритм наподобие такого, который производит вычисления с точностью, не выше заданной (могущей быть большой), но позволяющий вернуть значение, посчитанное с меньшей точностью. Тогда можно реализовать это так, что поступают новые данные, начинаются вычисления, как только получаем OME, зануляем ссылки на данные с результатами промежуточных вычислений, просим о полной сборке и возвращаем то, что успели посчитать. Не думаю, что процент подобных программ от общего числа приложений равен хотя бы единице; В будущем планируется ввести более удобные механизмы по восстановлению от OME, которые позволят использовать это в более широком круге задач;
Здравствуйте, Blazkowicz, Вы писали:
B>Здравствуйте, sss1024, Вы писали:
S>>а что поднимать-то. Просто память кончилась S>>Runtime.gc() S>>Thread.sleep(1000) S>>дальше удалить что-нибудь ненужное или по обстоятельствам.
B>Да уж, вирус с sql.ru расползается с невероятной скоростью. Меня там совсем не давно пытались убедить в том что это отличное решение. Уважаемый, где вы этой дряни набрались?
Видимо это "решение" действительно не будет работать так как вирт. машина перед броском этого иксепшна сама попыталась "собрать мусор"... Вопрос в том имеет ли смысл ловить такой иксепшн и например пытаться ручками за-null-ить какие-то возможно ненужные объекты, а потом "попросить" вирт. машину снова "поубирать" (только попросить так как гарантий выполнения сборщика она не дает). Или после OutOfMemory работа вирт. машины вообще неопределенна, и лучше всего закрыть аппликейшн?
Здравствуйте, denis.zhdanov, Вы писали:
DZ>Спецификация гарантирует, что перед тем, как бросить out of memory, jvm сделает все возможное для того, чтобы попытаться очистить память (запустит full collection, соберет soft references).
Есть мнение, что при определенных настройках (Parallel GC?) и очень быстром заполнении памяти, можно вызвать OEM ещё до того как GC успеет освободить память, остановить все потоки, или увеличить хип. Сам не сталкивался, всё никак нет времени опробовать.
Здравствуйте, leokom, Вы писали:
L>Видимо это "решение" действительно не будет работать так как вирт. машина перед броском этого иксепшна сама попыталась "собрать мусор"... Вопрос в том имеет ли смысл ловить такой иксепшн и например пытаться ручками за-null-ить какие-то возможно ненужные объекты, а потом "попросить" вирт. машину снова "поубирать" (только попросить так как гарантий выполнения сборщика она не дает). Или после OutOfMemory работа вирт. машины вообще неопределенна, и лучше всего закрыть аппликейшн?
Здравствуйте, leokom, Вы писали:
L>Видимо это "решение" действительно не будет работать так как вирт. машина перед броском этого иксепшна сама попыталась "собрать мусор"... Вопрос в том имеет ли смысл ловить такой иксепшн и например пытаться ручками за-null-ить какие-то возможно ненужные объекты, а потом "попросить" вирт. машину снова "поубирать" (только попросить так как гарантий выполнения сборщика она не дает). Или после OutOfMemory работа вирт. машины вообще неопределенна, и лучше всего закрыть аппликейшн?
Т.к. ОМЕ может случиться где угодно, возможен вариант, что если ты даже поймаешь еррор в месте, откуда можно занулить ссылки на большие объекты, не факт что ОМЕ не вылетела перед этим в другом потоке(ах). Т.е. если ты поймаешь и освободишь память, у тебя могут быть unexpectedly terminated важные потоки.
Расскажи лучше о задаче, в качестве возможного решения которой ты рассматриваешь обработку ОМЕ. Я уверен, что можно будет предложить лучшую альтернативу.
Здравствуйте, denis.zhdanov, Вы писали:
DZ>Ключевые моменты:
DZ> DZ> ОМЕ может случиться в любой точке программы, где создается новый объект. Невозможно заранее предсказать где;
Ну это я понимаю прекрасно но автор топика как — то это думает побороть раз задал такой вопрос иначе наше обсуждение просто флейм ... DZ> Можно предположить существование программы, которая создает объекты в одном/нескольких строго определенных местах. При этом она использует алгоритм наподобие такого, который производит вычисления с точностью, не выше заданной (могущей быть большой), но позволяющий вернуть значение, посчитанное с меньшей точностью. Тогда можно реализовать это так, что поступают новые данные, начинаются вычисления, как только получаем OME, зануляем ссылки на данные с результатами промежуточных вычислений, просим о полной сборке и возвращаем то, что успели посчитать. Не думаю, что процент подобных программ от общего числа приложений равен хотя бы единице;
+1
Полностью согласен
DZ> В будущем планируется ввести более удобные механизмы по восстановлению от OME, которые позволят использовать это в более широком круге задач;
Ну в принцыпе в спеке написано тоже DZ>
Здравствуйте, leokom, Вы писали:
L>Здравствуйте, jitm, Вы писали:
J>>Здравствуйте, leokom, Вы писали:
L>То есть, получается разработчики джавы еще сами толком не знают что в этом случае делать и ищут красивые выходы из ситуации. (про поток-обработчик).
Получается что так. L>Но так и не ясно что делать с существующими вирт. машинами джавы... Так как улучшения про которые они тут пишут еще только "в проекте"
Да, но у меня встречный вопрос если ты хош ловить ООМЕ то ты знаешь де оно происходит ? Если знаешь то может просто не доводить до ООМЕ, как ты на это смотришь ? Если не знаешь то ты либо пишешь так как описал denis.zhdanov либо тебе стало скучно и ты решил поговорить
