java.lang.OutOfMemoryError

@vlav · Регистрация: 14.02.2009

java.lang.OutOfMemoryError

- иногда выдается (очень редко) непонятно почему.

Можно что-то предпринять?

@boombastik · 15.11.2006, 19:24

возможно бесконечная рекурсия при обработке неперехваченных RuntimeException's?

@vlav · 15.11.2006, 19:34 **[ТС]**

Danissimo (15.11.2006)
Стоп-стоп =)) Почему выход за пределы массива приводили к OutOfMemoryError.

Для меня загадка, но эта единственная причинно-следственная связь, которую я заметил.

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

16.11.2006, 21:43

Danissimo (15.11.2006)
Стоп-стоп =)) С этого места по-подробнее, пожалуйста. Обращение за пределы массива возбуждает совсем другую ошибку: ArrayIndexOutOfBoundsException. Это RuntimeException. А у тебя мало того, что OutOfMemoryError вылетает, так он еще и Error -- из совсем другой иерархии.

Ну прям совсем из другой...

Danissimo (15.11.2006)

Может, конечно, возникавщий ArrayIndexOutOfBoundsException приводил к возникновению OutOfMemoryError из-за того, что где-то стек разрушался, и все начинало работать неправильно. Но выглядит пофикс довольно странно. Лично я рекомендую проверить все. Почему выход за пределы массива приводили к OutOfMemoryError.

Ага. Я тоже когда выкурю много, начинаю фантазировать.

Прослеживается явное непонимание автором поста сути OutOfMemoryError. У JVM есть верхний предел использования памяти, достигнув которого, получаем OutOfMemoryError. Это раз.

OutOfMemoryError не обязательно результат ошибки. А если у автора канал будет огромный и по его расчетам ему надо будет иметь 1000000 потоков? Здесь ошибка в логике работы, причем явная. Это два.

Не пойму, причем тут JVM и свопинг? Поставьте верхний придел памяти больше физической и создавайте кучу объектов. Память JVM не будет свопиться?

@vlav · 21.11.2006, 01:13 **[ТС]**

Не пойму, причем тут JVM и свопинг? Поставьте верхний придел памяти больше физической и создавайте кучу объектов. Память JVM не будет свопиться?

Вопрос конечно интересный, как-нибудь обязательно исследую будет ли свопиться память jvm (внутри которой работают приложения) - ставлю что не будет.

Сейчас экспериментирую в рамках своей задачи про обход сайта (мысль такая, что каждый встреченный на странице url загружается в новом потоке - так вот, если потоков в итоге 50-100 - все нормально. Если их 1000 - через один java.lang.OutOfMemoryError.

ОС показывает оперативной памяти - jvm - 18%. (в момент когда ошибки прут). Всего 512М оперативки.

@Danissimo · 21.11.2006, 04:17

vlav, дарагой, покажи, как jvm запускаешь. Наверняка же не поставил ключ -Xmx384m =)) И все-таки "у тебя с животом что-то не то..." (с) Еще раз предостерегаю: выход за пределы массива ведет к ArrayIndexOutOfBoundsException, which extends RuntimeException. OutOfMemoryError extends Error, что совсем из другой ветки. Чудес не бывает.

paradise, я все знаю про верний предел, иерархии и пр и пр. Рекомендую мой пост перечитать. Если интересно, конечно. А также пост, на который он был ответом.

Да, еще хотел заметить, что, указав взять больше, чем есть физической памяти, вы не позволите jvm создастся.

@Danissimo · 21.11.2006, 04:22

vlav, кстати, ты прав. Бесконечная рекурсия возможна. Или просто цикл, создающий объекты (и не убивающий их). Тока с рекурсией обычно вылетает StackOverflowError. Но и твой вариант возможен, если память "съедается" быстрее, чем стек.

@boombastik · 21.11.2006, 04:57

По поводу предоставления памяти для JVM из свопа, я склонен к мнению с <A class=SmlBoldLinks id=ctl03_ctlTopic_ctlPanelBar_ctlTopicsR epeater_ctl13_smAuthorName onmouseover="window.status = window.location;return true;" title="View Danissimo's Profile..." onmouseout="window.status=''return true;" href="void(''); Danissimo - это плохой подход. Помниться, ставил я эксперименты года 3 тому назад, вроде бы уже с J2SE 1.4.2, хотя и не уверен.
Что удивительно, под Windows XP/2000 Java (с правильным ключиком -xmx) позволила выходить за пределы физической памяти (ее было 512Мб) и свопить, но начинались такие тормоза, что было даже сложно убить процесс.
Под Sun Solaris же (по-моему памяти там было 2Гб) Java выкидывала злополучную OutOfMemoryError как только пыталась выйти за физические пределы ОЗУ. Возможно своп был неправильно настроен или не был настроен вообще, возможно еще что-то, скорее всего наши собственные ошибки, но проблему эту мы тогда решили экспансивным путем

С уважением,
Владимир

21.11.2006, 06:24

vlav (15.11.2006)
У меня (плююсь

) - все прошло, когда я убрал ошибку, что в некоторых (редких) случаях в потоке возникало переполнение массива.

Я тут решил влезть малость если не возражаете?

vlav объясни как у тебя возникает перполнение массива?

Конечно моё предложение увеличить память было не совсем хорошим в том смысле что если возникает memory leak то тут увеличивай не увеличивай - результат в конечном итоге будет тот же.

Создается впечатление что как раз это и есть причина OutOfMemoryError.

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

@boaa · 21.11.2006, 13:21

Здесь, действительно, фигня какая-то с алгоритмом. И, сдается мне, от этого и пляшут три страницы постов. Весьма стремно запускать каждый URL в новом потоке, поскольку так их родится немеряно. И в идеале "шайтана" система будет занята не выполнением полезной работы, а созданием потоков (КПД то-бишь).

@vlav · 21.11.2006, 14:27 **[ТС]**

boaa (21.11.2006)
Здесь, действительно, фигня какая-то с алгоритмом. И, сдается мне, от этого и пляшут три страницы постов. Весьма стремно запускать каждый URL в новом потоке, поскольку так их родится немеряно. И в идеале "шайтана" система будет занята не выполнением полезной работы, а созданием потоков (КПД то-бишь).

У меня проблем уже нету. Оптимальный алгоритм такой - максимально потоков 100, новые добавляются по мере заверешения работы запущенных. Если потоков скажем 300 - начинают мелькать эти ошибки выделения памяти jvm. Это на системе Линукс, ОЗУ 512К. При этом реально потребляется не более 20% этого ОЗУ. Вот и все - если это кому-нибудь интересно.

@Danissimo · 21.11.2006, 15:59

Мне интересно!

Покажи, как запускаешь. Хором уже просим =) И, соглашусь с mishgun'ом, покажи код вокруг переполнения до и после пофикса.

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

У меня проблем уже нету.

Будут! К бабке не ходи, будут. Ибо "кончилась память" и "кончился массив" -- ну, ваще, разные вещи =)))

@Danissimo · 21.11.2006, 16:11

boombastik (21.11.2006)
[...]Помниться, ставил я эксперименты года 3 тому назад, вроде бы уже с J2SE 1.4.2, хотя и не уверен.

Что удивительно, под Windows XP/2000 Java (с правильным ключиком -xmx)позволила выходить за пределы физической памяти (ее было 512Мб) и свопить, но начинались такие тормоза, что было даже сложно убить процесс.

Ничего себе! А я вот такой экперимент вчера провел. Код:

Java
1
2
3
class x {
public static void main(String [] args) {}
}

Запускаем (windows):

java -Xmx2g x

Говорит:

Error occurred during initialization of VM
Could not reserve enough space for object heap
Could not create the Java virtual machine.

$ java -version

java version "1.5.0_05"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_05-b05)
Java HotSpot(TM) Client VM (build 1.5.0_05-b05, mixed mode)

Памяти -- 2 Гб. У меня запустить не получилось.

@vlav · 21.11.2006, 16:20 **[ТС]**

Danissimo (21.11.2006)
Мне интересно!

Покажи, как запускаешь. Хором уже просим =) И, соглашусь с mishgun'ом, покажи код вокруг переполнения до и после пофикса.

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

А вот про собственно топик: java.lang.OutOfMemoryError - они выскакивают , как удалось выяснить, непредсказуемо, при попытке одновременного (из цикла for(int i=0; ///) старта большого количества Threads - больше где 200 - начинают мелькать. То есть поток прерывается аварийно, а точнее не запускается видимо вовсе, потом например еще 5-6 нормально стартуют. Потом опять.

Код вкратце приведу вечером.

@boombastik · 21.11.2006, 16:37

2 Danissimo: память выделял не всю сразу, был задан -xms приемлимых размеров, в процессе выполнения программа требовала больше памяти и приближалась к пределу -xmx, ну и -xmx поскромнее был, но надо будет дома сегодня попробовать, даже же интересно стало про swap и JRE

добавлено:

Хм.. есть идея, при попытке захвата JVM памяти близкой к максимальной физической, в безмерном количестве стали свопиться другие программы, отсюда тормоза, задачу я снимал, не дожидаясь OutOfMemoryError

С уважением,

Владимир

@boombastik · 21.11.2006, 16:42

vlav (21.11.2006)

А вот про собственно топик: java.lang.OutOfMemoryError - они выскакивают , как удалось выяснить, непредсказуемо, при попытке одновременного (из цикла for(int i=0; ///) старта большого количества Threads - больше где 200 - начинают мелькать. То есть поток прерывается аварийно, а точнее не запускается видимо вовсе, потом например еще 5-6 нормально стартуют. Потом опять.

Код вкратце приведу вечером.

Создай pool потоков и регулируй их количество, хорошо бы подсчитать статистику среднего и максимального объемов памяти, которые требуются для нормального выполнения одного потока, исходя из этих данных, можно достаточно точно вычислить безопасное число одновременно запущенных потоков при известных физических ограничениях для JVM.

Удачи,

Владимир

@vlav · 21.11.2006, 16:50 **[ТС]**

Несколько угнетает то что весь этот бардак при 80% свободной памяти физической. И еще я не могу регулировать параметры запуска jvm индивидуально везде.

То есть это должно работать по умолчанию для любой средней машины.

@Danissimo · 21.11.2006, 17:19

Ты не переживай. Все, что нужно, это просто обрабатывать ошибки. Как говорят, recover после сбоев. Как ты сам говоришь, можно сделать, например, так: запускаем поток, нет ошибок -- запускаем следующий. И так далее до некоего макс. кол-ва потоков (другими словами, запускаем не бесконечно). Если на какой-то итерации памяти стало мало -- больше не запускаем. Все. Запусщщеное кол-во потоков -- это и есть рабочее число для данной аппаратуры.

Ты не показываешь, как запускаешь jvm, почему? потому чтоне можешь контролировать у пользователей?

27.11.2006, 20:36

vlav (21.11.2006)
Несколько угнетает то что весь этот бардак при 80% свободной памяти физической. И еще я не могу регулировать параметры запуска jvm индивидуально везде.

То есть это должно работать по умолчанию для любой средней машины.

Меня дизайн, как тебе и сказали на первой странице этого флейма и потом еще сто раз повторили.

@vlav · 27.11.2006, 23:32 **[ТС]**

Danissimo (21.11.2006)
Ты не переживай. Все, что нужно, это просто обрабатывать ошибки. Как говорят, recover после сбоев. Как ты сам говоришь, можно сделать, например, так: запускаем поток, нет ошибок -- запускаем следующий. И так далее до некоего макс. кол-ва потоков (другими словами, запускаем не бесконечно). Если на какой-то итерации памяти стало мало -- больше не запускаем. Все. Запусщщеное кол-во потоков -- это и есть рабочее число для данной аппаратуры.

Ты не показываешь, как запускаешь jvm, почему? потому чтоне можешь контролировать у пользователей?

jvm - именно по этой причине - то есть я ее запускаю без параметров.

А как эту хрень - java.lang.OutOfMemoryError обработать? И вопросов бы не было!

@mselez · 28.11.2006, 00:32

Аналогичная проблема, когда java - апплет запускается в браузере клиента. Памятью тоже вроде нельзя управлять. Остается только умерять аппетиты клиентских приложений. А как с этим в web start?

Новые блоги и статьи Все статьи Все блоги /
[golang] Конкурентный fetcher с ограничением максимального количества одновременных HTTP запросов. alhaos 10.06.2026 Задача Реализовать конкурентный fetcher с ограничением максимального количества одновременных HTTP запросов. Сигнатура func Fetch(urls string, maxConcurrent int) Result Пример urls :=. . .	[golang] Состояние гонки (race condition) alhaos 10.06.2026 Состояние гонки (race condition) Состояние гонки (Race Condition) — это ошибка, возникающая при одновременном доступе нескольких горутин к одним и тем же данным без должной синхронизации. При этом. . .	Взрослые отношения, и почему они не получаются kumehtar 09.06.2026 Когда в детстве ребёнок не получает от родителей чего-то важного, он лишается не просто приятных переживаний, а основы для формирования определённых внутренних качеств и навыков. Если ребёнок не. . .	[golang] Worker Pool alhaos 09.06.2026 Worker Pool Worker Pool — паттерн конкурентной обработки задач в Go. Суть: фиксированное количество горутин-воркеров читают задачи из общего канала и пишут результаты в общий канал результатов. . . .
[golang] Pipeline alhaos 08.06.2026 Pipeline Pipeline — паттерн конкурентной обработки данных в Go. Суть: данные проходят через цепочку независимых стадий, каждая из которых работает в своей горутине и общается с соседями через. . .	Свет внутри себя kumehtar 07.06.2026 Пусть это будет здесь lIs4oanZS9Y	Программа для com-порта Uhbif79 05.06.2026 Всем привет, давно хотел изучить Qt, начинал, бросал, потом снова начинал. И сейчас вот смог написать свою первую программу. До этого имел опыт программирования микроконтроллеров, писал прошивки на. . .	Транскрипция 55-минутного видео через Whisper: WhisperDesktop облажался, спас Google Colab[ anaschu 01.06.2026 Понадобилось получить текст из свежезагруженного видео на YouTube. Казалось бы, задача на пять минут. Заняла полтора часа. Делюсь опытом — может кому пригодится последовательность решений. . . .

@vlav 0 / 0 / 1 Регистрация: 14.02.2009 Сообщений: 470

	java.lang.OutOfMemoryError 07.11.2006, 08:48. Показов 16948. Ответов 61 Метки нет (Все метки) java.lang.OutOfMemoryError - иногда выдается (очень редко) непонятно почему. Можно что-то предпринять? 0

@boombastik 7 / 7 / 12 Регистрация: 13.02.2007 Сообщений: 1,255
	15.11.2006, 19:24
	возможно бесконечная рекурсия при обработке неперехваченных RuntimeException's? 0

@Danissimo 4 / 4 / 4 Регистрация: 28.08.2008 Сообщений: 611
	21.11.2006, 04:17
	vlav, дарагой, покажи, как jvm запускаешь. Наверняка же не поставил ключ -Xmx384m =)) И все-таки "у тебя с животом что-то не то..." (с) Еще раз предостерегаю: выход за пределы массива ведет к ArrayIndexOutOfBoundsException, which extends RuntimeException. OutOfMemoryError extends Error, что совсем из другой ветки. Чудес не бывает. paradise, я все знаю про верний предел, иерархии и пр и пр. Рекомендую мой пост перечитать. Если интересно, конечно. А также пост, на который он был ответом. Да, еще хотел заметить, что, указав взять больше, чем есть физической памяти, вы не позволите jvm создастся. 0

@Danissimo 4 / 4 / 4 Регистрация: 28.08.2008 Сообщений: 611
	21.11.2006, 04:22
	vlav, кстати, ты прав. Бесконечная рекурсия возможна. Или просто цикл, создающий объекты (и не убивающий их). Тока с рекурсией обычно вылетает StackOverflowError. Но и твой вариант возможен, если память "съедается" быстрее, чем стек. 0

@boombastik 7 / 7 / 12 Регистрация: 13.02.2007 Сообщений: 1,255
	21.11.2006, 04:57
	По поводу предоставления памяти для JVM из свопа, я склонен к мнению с <A class=SmlBoldLinks id=ctl03_ctlTopic_ctlPanelBar_ctlTopicsR epeater_ctl13_smAuthorName onmouseover="window.status = window.location;return true;" title="View Danissimo's Profile..." onmouseout="window.status=''return true;" href="void(''); Danissimo - это плохой подход. Помниться, ставил я эксперименты года 3 тому назад, вроде бы уже с J2SE 1.4.2, хотя и не уверен. Что удивительно, под Windows XP/2000 Java (с правильным ключиком -xmx) позволила выходить за пределы физической памяти (ее было 512Мб) и свопить, но начинались такие тормоза, что было даже сложно убить процесс. Под Sun Solaris же (по-моему памяти там было 2Гб) Java выкидывала злополучную OutOfMemoryError как только пыталась выйти за физические пределы ОЗУ. Возможно своп был неправильно настроен или не был настроен вообще, возможно еще что-то, скорее всего наши собственные ошибки, но проблему эту мы тогда решили экспансивным путем С уважением, Владимир 0

@boaa 0 / 0 / 0 Регистрация: 08.06.2011 Сообщений: 63
	21.11.2006, 13:21
	Здесь, действительно, фигня какая-то с алгоритмом. И, сдается мне, от этого и пляшут три страницы постов. Весьма стремно запускать каждый URL в новом потоке, поскольку так их родится немеряно. И в идеале "шайтана" система будет занята не выполнением полезной работы, а созданием потоков (КПД то-бишь). 0

@boombastik 7 / 7 / 12 Регистрация: 13.02.2007 Сообщений: 1,255
	21.11.2006, 16:37
	2 Danissimo: память выделял не всю сразу, был задан -xms приемлимых размеров, в процессе выполнения программа требовала больше памяти и приближалась к пределу -xmx, ну и -xmx поскромнее был, но надо будет дома сегодня попробовать, даже же интересно стало про swap и JRE добавлено: Хм.. есть идея, при попытке захвата JVM памяти близкой к максимальной физической, в безмерном количестве стали свопиться другие программы, отсюда тормоза, задачу я снимал, не дожидаясь OutOfMemoryError С уважением, Владимир 0

@vlav 0 / 0 / 1 Регистрация: 14.02.2009 Сообщений: 470
	21.11.2006, 16:50 [ТС]
	Несколько угнетает то что весь этот бардак при 80% свободной памяти физической. И еще я не могу регулировать параметры запуска jvm индивидуально везде. То есть это должно работать по умолчанию для любой средней машины. 0

@Danissimo 4 / 4 / 4 Регистрация: 28.08.2008 Сообщений: 611
	21.11.2006, 17:19
	Ты не переживай. Все, что нужно, это просто обрабатывать ошибки. Как говорят, recover после сбоев. Как ты сам говоришь, можно сделать, например, так: запускаем поток, нет ошибок -- запускаем следующий. И так далее до некоего макс. кол-ва потоков (другими словами, запускаем не бесконечно). Если на какой-то итерации памяти стало мало -- больше не запускаем. Все. Запусщщеное кол-во потоков -- это и есть рабочее число для данной аппаратуры. Ты не показываешь, как запускаешь jvm, почему? потому чтоне можешь контролировать у пользователей? 0

@mselez 0 / 0 / 0 Регистрация: 22.07.2009 Сообщений: 457
	28.11.2006, 00:32
	Аналогичная проблема, когда java - апплет запускается в браузере клиента. Памятью тоже вроде нельзя управлять. Остается только умерять аппетиты клиентских приложений. А как с этим в web start? 0