Является ли это хорошей практикой для смягчения OutOfMemoryError?

Рассмотрите процесс java, в котором основной поток читает объекты Json из источника и назначает задачу с прочитанными объектами Json в FixedThreadPoolExecutor с 5 рабочими потоками.Является ли это хорошей практикой для смягчения OutOfMemoryError?

Здесь проблема в том, что источник, с которого читаются Jsons, намного быстрее, чем завершение задач рабочим потоком. Итак, когда Jsons накапливаются в памяти, ожидающей рабочих потоков, OutOfMemoryException бросается. Здесь количество рабочих потоков не может быть увеличено.

Так будет ли эффективное решение этой проблемы OutOfMemory?

В основном потоке проверить процент доступной памяти и сна в течение некоторого времени, если использование памяти более чем 80%

main(){ 
    for(;;){ 
     //read the data and assign to executor 
     long total = Runtime.getRuntime().maxMemory(),free = Runtime.getRuntime().freeMemory() 
     float usedPersent = (total-free)*100/total 
     if(usedPercent > 80) 
     Thread.sleep(2000); 
    } 
}

Будет ли хорошая практика?

источник

2013-12-05 vivek_jonam

Вы должны решить свою проблему OOME с надлежащим дизайном вместо хаков. Ваши объекты JSON должны быть перенесены в ограниченную очередь блокировки, которая автоматически позаботится о применении «противодавления» к производителю.

Вариант с более чистым вариантом должен состоять в том, чтобы перепроектировать так, чтобы каждой из ваших заданных задач была предоставлена часть загруженного JSON для обработки, поэтому он ничего не тянет сам по себе. Таким образом, вам даже не нужно реализовывать очередь: вы полагаетесь на внутреннюю очередь для своей службы-исполнителя, которую вам нужно настроить только соответствующим образом. Например, используйте явный конструктор ThreadPoolExecutor, передав ему CallerRunsPolicy в качестве политики отклонения.

Также обратите внимание, что загрузка слишком большого количества JSON будет замедлять вашу систему в целом, потому что избыточные объекты будут продвигаться до Старого поколения, увеличивая частоту крупных коллекций мусора.

источник

2013-12-05 09:34:28

Нет - это плохая идея.

Вы должны создать пул потоков с максимальным размером пула и ограниченным размером очереди и дескрипторами дескриптора.

Существует сообщение here, которое выглядит многообещающим. Он заявляет, что является BoundedExecutor.

источник

2013-12-05 09:34:33 OldCurmudgeon

Не может ли клиент быть заблокирован вместо отказа? –

@MarkoTopolnik - я надеюсь, что так до сих пор расследую. – OldCurmudgeon

Похоже, что «CallerRunsPolicy» - хороший подход. «Это обеспечивает простой механизм управления с обратной связью, который замедлит скорость подачи новых задач». –

Лучшим решением, вероятно, будет очередь, которая блокируется, когда она заполнена. Таким образом, вы сохраняете отставание управляемым без funkiness, который является синхронизацией потоков через Thread.sleep.

источник

2013-12-05 09:35:13 cHao

Нет, это плохая идея. Насколько я знаю, поведение JVM просто не указано после возникновения OutOfMEmoryException (извините, у меня сейчас нет ссылок). Вы даже не можете увидеть это исключение в некоторых случаях. Поэтому важно контролировать использование кучи JVM, например. в серверных средах.

источник

2013-12-05 09:35:39 spa

Да, после OOME и SOE поведение, как правило, непредсказуемо. На практике, однако, мы редко закрываем наши системы с первого взгляда на эти ошибки, потому что они полностью извлекаются из по меньшей мере в 90% случаев. –

Я не уверен в этой идее. Откуда вы берете основную нить из своей работы? Не заставляет ли спать спать и ждать в течение этих 2 секунд?

Я думаю, что у вас есть 2 способа атаковать эту проблему:

Как вы думаете, у вас есть какой-либо способ повышения эффективности вашей обработки данных?Возможно, если вы сможете сделать рабочие потоки более эффективными, они могут сбросить нагрузку на вашу систему быстрее, чем сейчас.
Или, если вы уверены, что не можете получить лучшую производительность, возможно, ваша проблема с подлинными ресурсами и должен попросить вашего оператора или того, кто управляет производственной системой для другой установки JVM, с разным размером кучи. Посмотрите на

http://www.jafaloo.com/java-xmx-memory-settings/

Если предоставить им звуковую оценку объема памяти вам нужно, они должны быть разумными (да, я лечил с жесткими операторами в моей жизни: P)

источник

2013-12-05 09:41:47

Является ли это хорошей практикой для смягчения OutOfMemoryError?

ответ

Смежные вопросы