Java обработка ошибки OutOfMemoryError

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

Как ты себе представляешь обработку OutOfMemoryError? Память кончилась, все! Тупо проблема решается запуском java c ключиком -XmxNNNm, NNN - макс лимит памяти для JVM. А в работающем приложении OutOfMemoryError - ошибка проектирования. Юзай профайлер.

>Юзай профайлер.

А можно отсюда поподробнее ?
На Це это решается очень просто там при каждом выделении памяти проверяешь дали ли тебе ее, и действуюеш соответственно.

По поводу ошибки проектирования. Это сложный вопрос просто повысили нагрузку на прогу.

>Тупо проблема решается запуском java c ключиком -XmxNNNm
Так и решаем кушает оно уже много.

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

> приложение пытается сделат новый тред и не может проверить что ему больше памяти не дадут

Что-то мешает завести переменную MAX_THREADS и установить разумный лимит?

Еще смотри сюда:

http://java.sun.com/j2se/1.4.2/docs/api/java/lang/Runtime.html#freeMemory()

http://java.sun.com/j2se/1.4.2/docs/api/java/lang/Runtime.html#maxMemory()

http://java.sun.com/j2se/1.4.2/docs/api/java/lang/Runtime.html#totalMemory()

>Юзай профайлер.

> можно отсюда поподробнее ?

google://java memory profiler

Раньше были в моде JProbe, JProfiler. Я давно не пользовался, не стану советовать.

Ок спасибо. Пойду почитаю.

>Что-то мешает завести переменную MAX_THREADS и установить разумный лимит?

Видимо это не вяжется с моим мировозрением, я привык что если нет памяти то спамим во все дыры (email syslog e.t.c.) что млять памяти нет, но прога продалжает нормально работать (кто то из клиентов кидпется). А вдруг админ в третий дум решил на серваке поиграть (утрирую - например кто то высвободил память), бац и память через час появилась и продолжилась нормальная работа на увеличенном количестве клиентов.
Клиенты весшь не постоянная сегодня из 10 а завтра 50 потом 100 и опять10.

>На Це это решается очень просто

С - другое дело, там если malloc-и не дергать, все более-менее контролируемо.

>Но блин это что масдай ?

масдай этот явой зовется:-). Если у тебя закончилась память, ты с _большой_ вероятностью ничего полезного в яве сделать не сможешь. GC еше не поудалял то, что переполнило память, и она опять закончится посреди обработчика ошибки, с сильно менее предсказуемыми последствиями. Немедленно упасть - лучшее, что программа может сделать в таких условиях.

> бац и память через час появилась

Это детский сад! Лимиты на все ограниченные ресурсы должны быть жестко зафиксированы. Всегда. Везде. В Java, C, etc.. Посмотри на конфиг любого нормального серверного приложения.

> Клиенты весшь не постоянная сегодня из 10 а завтра 50 потом 100 и опять10.

И? Ограниченные ресурсы - в пул. Клиентов - в очередь. Не изобретай велосипед.

> Если делать проверку исключительной ситуации перед каждым “new” то как это скажется на читаемости кода и на производительности?

Насколько я знаю, на производительности блок try {...} catch (...) {...} почти не сказывается.

А на читаемости скорей всего скажется отрицательно, придется писать кучу повторяющегося кода. Но есть такая штука, как AOP (Aspect Oriented Programming), как раз для решения таких проблем.

Вот несколько ссылочек:

http://www.jboss.org/products/aop

http://aspectwerkz.codehaus.org/

http://www.jboss.org/products/aop

Лично я предпочел JBoss AOP, т.к. он хорошо документирован, есть все необходимые мне фичи. Его минус - изначально нет способа использовать его на каких-либо AS кроме JBoss, нужно будет немного кода написать.

Последнюю ссылку криво вставил :) Хотел эту: http://eclipse.org/aspectj/