java.lang.OutOfMemoryError

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

Студворк — интернет-сервис помощи студентам

java.lang.OutOfMemoryError

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

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

@boaa · 13.11.2006, 23:24

Нуууу, эт смотря как и что надо делать. У меня, бывало, и тысяча потоков работала. И ничего. Сутками струячили и без никаких "НО" (и это все еще и на лептопе).

@vlav · 14.11.2006, 01:15 **[ТС]**

Я тоже думаю что ничего. Это в основе многозадочной оси. У меня в данный момент в оси работает 62 процесса, из них каждый например может представлять ява машину с 500 потоками еще внутри. Это называется fork и threads. И проблем с памятью не должно быть по определению. Вот если на swap места не хватит - но это уже называется русским словом на п.!

Поэтому я и говорю, что это баг ява-машины

Точнее так - недоработочка.

@boaa · 14.11.2006, 04:39

У меня, кстати, тоже проблема подобной сложности нарисовалась.

Потоки ничего общего, кроме БД и сети не используют, но тем не менее иногда наступает момент в работе программы (как правило, после часа-другого работы), когда все уходит в ступор. Активности никакой, загрузки процессора - никакой, сама программа по SIGTERM завершаться не хочет, а убить ее может только SIGKILL.

И даже дотошное изучение преподробнейших логов пока что ничего не дало. Вот такие пироги...

@vlav · 14.11.2006, 09:07 **[ТС]**

Вообще убить или завесить систему программным путем легче, чем кажется. Даже хваленый линукс.

Все эти БД и разные драйверы сети и т.п. содержат сотни багов, каждый день разработчики вычищают их пачками.

Я бы в твоем случае начал с того, что обновил бы все, что там задействовано до последних версий. Может проблема сама и снимется.

А что это, если не секрет, за приложение - работает сутками с сетью и базой?

@boaa · 14.11.2006, 12:43

Не секрет. Система автоматизированного сбора информации новостного характера для категорированных (то-бишь закрытых) корпоративных сетей.

@boaa · 14.11.2006, 12:48

А версии JDBC, СУБД и JVM у меня и так последние, кстати. На ось тож не жалуюсь (хотя в моем случае мало что зависит, как мне кажется).

@vlav · 14.11.2006, 12:58 **[ТС]**

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

Только я не пускаю сразу все потоки. Я ставлю, например, 50 потоков - и новые запусаются по мере того, как завершаются другие. Считал наиболее разумным все-таки использовать возможно меньше потоков - главное добиться цели - полностью загрузить канал связи. У меня на 128 кбит - как раз где-то 50-60 потоков не дают ему простаивать. Меньше уже хуже.

Я просто по ходу работы складываю количество загруженных байт и делю его на время. Видно, как в течение минут 10, приближается к 14-16кбайт/сек - то есть мой канал.

@boaa · 14.11.2006, 13:42

vlav (14.11.2006)
Я ставлю, например, 50 потоков - и новые запусаются по мере того, как завершаются другие...

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

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

@Vadim_ig · 14.11.2006, 14:01

Ну не знаю. Сначала выделяете огромное количество ресурсов, а потом рассуждаете о недостатках ява-машины. Да - поддержка многозадачности может и лежит в основе операционной системы, но зачем же злоупотреблять. Питание - тоже базовая функция человека, но это не значит, что нужно переедать, потом пиная на экологию... Это так - философское отступление, программ-то ваших не видел, может там все и хорошо (хотя тогда этой темы не было бы)...

@vlav · 14.11.2006, 14:32 **[ТС]**

Слушай - я тут вспомнил. У меня есть одно приложение для домашнего ползования. Суть в том, что я скачиваю телепрограммку на неделю, потом парзю ее и загоняю в базу. Там разово порядка 4000 записей, но идет за короткое время еще много запросов, которые определелют время конца передачи. Все делается запросами.

так вот на этой фигне:

1. мускл тормозит и на 100% грузит процессор. Тормозит на столько, что вывод на консоль можно успевать читать.

2. и я вспомнил - тоже раз из 10 вылетает с java.lang.OutOfMemoryError

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

@boaa · 14.11.2006, 17:58

vlav (14.11.2006)
...но идет за короткое время еще много запросов, которые определелют время конца передачи. Все делается запросами...

Не понял мысли. И с трудом верится, что все так погано при использовании реализации на Java. Как говорил Джон Сильвер: "Что-то здесь не тааак..."

@mselez · 14.11.2006, 20:51

В си я выделяю вначале динамическую память, например для размещения очередного элемента структуры, и начинаю писать в эту память только если она выделилась. Если не выделилась - предпринимаю какие-то действия, если возможно. Скажем - организую свопинг с диском.
Ява я так понимаю должна бы это делать в автомате и такой ошибки не должно бы быть в принципе. Видимо какие-то данные она хранит по определению только в оперативке.

Не делает java свопинг. Наверное, это противоречит концепции "песочницы".

А я бы просто не запускал поток, если ему памяти мало.

Вы хотели бы больше творческого подхода от java? Программист закодировал запуск потока, а java почесала репу и решила - а ну его ? Java честно исполняет инструкции и сообщает о фатальном исходе в виде исключений. А как иначе? Это ответственность программиста.

Сейчас поэкспериментирую, но от системы ява вместе с моим приложением отъедает не больше 30% вроде.

отьедает 30% чего? Если памяти, то разве вы не сами устанавливаете, сколько памяти доступно приложению?
У меня лично к java претензий нет. Одно время не нравилось, что нельзя явно управлять уборкой мусора, но потом немного ознакомился с этой кухней и сейчас вполне устраивает.

@vlav · 14.11.2006, 21:43 **[ТС]**

boaa (14.11.2006)

vlav (14.11.2006)
...но идет за короткое время еще много запросов, которые определелют время конца передачи. Все делается запросами...

Не понял мысли. И с трудом верится, что все так погано при использовании реализации на Java. Как говорил Джон Сильвер: "Что-то здесь не тааак..."

время конца передачи - телепередачи

Просто много запросов подряд (не одновременно!) типа SELECT и за ним сразу UPDATE.

в конце там так

Java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
finally {
 
if (rs != null) { 
 
    try {rs.close();} catch (SQLException sqlEx) {rs = null;}
 
}
 
if (stmt != null) {
 
    try {stmt.close();} catch (SQLException sqlEx) {stmt = null;}
 
} 
 
}

то есть все закрывается.

Ошибки памяти точно мелькают - я помню.

К тому что тебе возможно именно на базу надо внимание обращать.

Кстати не обязательно с ней работать именно из ява. Можно написать серверный (HTTP) скрипт, например на PHP, который будет класть в базу данные переданные в параметрах GET или даже POST. А дергать скрипт из явы с этими параметрами. Таким образом исключишь из подозрений базу - или наоборот

@boaa · 15.11.2006, 15:25

Можешь сократить код до закрытия объекта класса java.sql.Statement, поскольку когда вызывается close() упомянутого объекта, он автоматом закрывает созданные ResultSet`ы.

@boombastik · 15.11.2006, 17:16

это верно, НО не для всех реализаций JDBC driver'ов, были преценденты, поэтому всегда настоятельно рекомендуют закрывать и то и другое в своем коде, а не полагаться на реализацию того или иного JDBC driver'а

С уважением,

Владимир

@boaa · 15.11.2006, 17:29

Опа... Это ж скоко кода надо пофиксить...

@Danissimo · 15.11.2006, 17:57

Я тут свои 2 копейки добавлю. vlav, не греши. jvm + java тут не причем (надеюсь, мы говорим о стабильной версии, а не бета какой-нть). 100%. Да, все остальные софтины, как то драйверы (выпущенные не саном), а также наши собственные могут грешить багами.

Я бы мог рассказать о том, какие приложения, скока работают, скока потоков и тд. и тп. мне пришлось сделать, в каких ситуациях у них были OutOdMemoryError и почему. Проще -- ищи не в java. В драйвере, в своем коде (ставлю, что баг в твоем коде, причем на уровне дизайна).

Для любителей передергивать: я не говорю, что в java нету багов. Я говорю про конкретный "баг" -- OutOfMemoryError.

@vlav · 15.11.2006, 18:36 **[ТС]**

У меня (плююсь

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

@boombastik · 15.11.2006, 19:02

boaa (15.11.2006)
Опа... Это ж скоко кода надо пофиксить...

ну фиксить нужно лишь тот код для которого неизвестно какой именно JDBC драйвер будет использоваться или нужна поддержка для широкого диапазона драйверов, например, если Вы разрабатываете программу типа "SQL Navigator" для любой доступной СУБД, я бы рекомендовал закрывать и result set, и statement, и connection

если драйвер известен, переход на альтернативный драйвер не планируется и достоверно известно как ведет себя данный драйвер, то переписывать программу вовсе необязательно

С уважением,

Владимир

P.S. Пара ссылок. Вот баг, про который тут уже упоминали: http://bugs.mysql.com/bug.php?id=5022

Вот рекомендациy с пояснениями зачем это надо:

http://www.precisejava.com/jav... tm#JDBC118

Вот дискуссия о том, про что я говорил: http://forum.java.sun.com/thre... ID=4042681

Цитата:

---

> If you close the connection, all dependen objects

> like statements and resultsets will also be closed.

The docs say this is true, but some driver vendors (e.g. Oracle) have failed to do so in the past. I always explicitly close statements and resultsets to be safe.

---

@Danissimo · 15.11.2006, 19:07

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

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

Новые блоги и статьи Все статьи Все блоги /
Вангую, что это не пройдёт модерацию, и на неделе я запущу свой сервер. Hrethgir 19.07.2026 Эта публикация сейчас в песочнице и ждёт приглашения. https:/ / habr. com/ ru/ sandbox/ 295048/ начало и оглавление - Как «пернатого» заставить осваивать новые горизонты опыта через масштабирование. . .	сукцессия 33. открытые вопросы от клауде anaschu 19.07.2026 "Что накопилось за эту часть А — тринадцать правок, из которых шесть пришли из ваших вопросов и каждая оказалась реальной ошибкой, а не калибровкой: односторонний симбиоз, отсутствующий листопад,. . .	32 сукцессия anaschu 19.07.2026 сукцессия 28‑мерное ядро стабилизировано Коллеги, фиксирую разбор инженерных правок и их изоморфную проекцию на экономику, меметику и половой отбор. Модель теперь не «подкручивает» сходимость —. . .	сукцессия 31: модель микоризы - это модель ещё нескольких явлений, социальных и экономических anaschu 18.07.2026 Теория «Всего»: апдейт v1. 1. 2 — 28‑мерное ядро стабилизировано Коллеги, фиксирую разбор инженерных правок и их изоморфную проекцию на экономику, меметику и половой отбор. Модель теперь не. . .
сукцессия 30. Массив проверяющих друг друга моделей anaschu 18.07.2026 Архитектура сети взаимопроверяющих моделей микоризной сукцессии (v2. 0) Развитие тензорного ОДУ-ядра и создание кросс-платформенного калибровочного полигона Уважаемые коллеги! В продолжение. . .	Грибы - это женщины, деревья - это мужчины. Анти инь янь для союза мужчины и женщины. anaschu 18.07.2026 ГЛАВНЫЙ НАУЧНО-ФИЛОСОФСКИЙ ВЫВОД: Сексуально-Репродуктивный Капитализм против Государства Моногамии Коллеги, мы вышли на финишную прямую 20-мерного ОДУ-моделирования вековой сукцессии (ветка. . .	Текстовый слайдер с нумерацией страниц и кроссбраузерность. russiannick 18.07.2026 Один мой друг написал текстовый слайдер с нумерацией страниц. Сегодня я расскажу как он умудрился подружить его с кроссбраузерностью. Очевидно сложно угодить с шириной каждому браузеру. Один крадет. . .	Грибы - это мемы, дерево - это человек. Применение микоризной модели к теории меметики Докинза. anaschu 18.07.2026 Меметический изоморфизм теории «всего»: Грибная сукцессия как модель эволюции идей Докинза Базовый код системы ОДУ микоризной сукцессии описывает не просто биологию, а универсальную. . .

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

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

@boaa 0 / 0 / 0 Регистрация: 08.06.2011 Сообщений: 63
	13.11.2006, 23:24
	Нуууу, эт смотря как и что надо делать. У меня, бывало, и тысяча потоков работала. И ничего. Сутками струячили и без никаких "НО" (и это все еще и на лептопе). 0

@vlav 0 / 0 / 1 Регистрация: 14.02.2009 Сообщений: 470
	14.11.2006, 01:15 [ТС]
	Я тоже думаю что ничего. Это в основе многозадочной оси. У меня в данный момент в оси работает 62 процесса, из них каждый например может представлять ява машину с 500 потоками еще внутри. Это называется fork и threads. И проблем с памятью не должно быть по определению. Вот если на swap места не хватит - но это уже называется русским словом на п.! Поэтому я и говорю, что это баг ява-машины Точнее так - недоработочка. 0

@boaa 0 / 0 / 0 Регистрация: 08.06.2011 Сообщений: 63
	14.11.2006, 04:39
	У меня, кстати, тоже проблема подобной сложности нарисовалась. Потоки ничего общего, кроме БД и сети не используют, но тем не менее иногда наступает момент в работе программы (как правило, после часа-другого работы), когда все уходит в ступор. Активности никакой, загрузки процессора - никакой, сама программа по SIGTERM завершаться не хочет, а убить ее может только SIGKILL. И даже дотошное изучение преподробнейших логов пока что ничего не дало. Вот такие пироги... 0

@vlav 0 / 0 / 1 Регистрация: 14.02.2009 Сообщений: 470
	14.11.2006, 09:07 [ТС]
	Вообще убить или завесить систему программным путем легче, чем кажется. Даже хваленый линукс. Все эти БД и разные драйверы сети и т.п. содержат сотни багов, каждый день разработчики вычищают их пачками. Я бы в твоем случае начал с того, что обновил бы все, что там задействовано до последних версий. Может проблема сама и снимется. А что это, если не секрет, за приложение - работает сутками с сетью и базой? 0

@boaa 0 / 0 / 0 Регистрация: 08.06.2011 Сообщений: 63
	14.11.2006, 12:43
	Не секрет. Система автоматизированного сбора информации новостного характера для категорированных (то-бишь закрытых) корпоративных сетей. 0

@boaa 0 / 0 / 0 Регистрация: 08.06.2011 Сообщений: 63
	14.11.2006, 12:48
	А версии JDBC, СУБД и JVM у меня и так последние, кстати. На ось тож не жалуюсь (хотя в моем случае мало что зависит, как мне кажется). 0

@vlav 0 / 0 / 1 Регистрация: 14.02.2009 Сообщений: 470
	14.11.2006, 12:58 [ТС]
	Интересная задача. У меня ведь в итоге получился почти готовый для нее движок Только я не пускаю сразу все потоки. Я ставлю, например, 50 потоков - и новые запусаются по мере того, как завершаются другие. Считал наиболее разумным все-таки использовать возможно меньше потоков - главное добиться цели - полностью загрузить канал связи. У меня на 128 кбит - как раз где-то 50-60 потоков не дают ему простаивать. Меньше уже хуже. Я просто по ходу работы складываю количество загруженных байт и делю его на время. Видно, как в течение минут 10, приближается к 14-16кбайт/сек - то есть мой канал. 0

@Vadim_ig 1 / 1 / 1 Регистрация: 05.01.2010 Сообщений: 235
	14.11.2006, 14:01
	Ну не знаю. Сначала выделяете огромное количество ресурсов, а потом рассуждаете о недостатках ява-машины. Да - поддержка многозадачности может и лежит в основе операционной системы, но зачем же злоупотреблять. Питание - тоже базовая функция человека, но это не значит, что нужно переедать, потом пиная на экологию... Это так - философское отступление, программ-то ваших не видел, может там все и хорошо (хотя тогда этой темы не было бы)... 0

@vlav 0 / 0 / 1 Регистрация: 14.02.2009 Сообщений: 470
	14.11.2006, 14:32 [ТС]
	Слушай - я тут вспомнил. У меня есть одно приложение для домашнего ползования. Суть в том, что я скачиваю телепрограммку на неделю, потом парзю ее и загоняю в базу. Там разово порядка 4000 записей, но идет за короткое время еще много запросов, которые определелют время конца передачи. Все делается запросами. так вот на этой фигне: 1. мускл тормозит и на 100% грузит процессор. Тормозит на столько, что вывод на консоль можно успевать читать. 2. и я вспомнил - тоже раз из 10 вылетает с java.lang.OutOfMemoryError причем - то-же мускл под апачей-пхп на локалхосте работает на порядок быстрее (визуально), чем через jdbc 0

@boaa 0 / 0 / 0 Регистрация: 08.06.2011 Сообщений: 63
	15.11.2006, 15:25
	Можешь сократить код до закрытия объекта класса java.sql.Statement, поскольку когда вызывается close() упомянутого объекта, он автоматом закрывает созданные ResultSet`ы. 0

@boombastik 7 / 7 / 12 Регистрация: 13.02.2007 Сообщений: 1,255
	15.11.2006, 17:16
	это верно, НО не для всех реализаций JDBC driver'ов, были преценденты, поэтому всегда настоятельно рекомендуют закрывать и то и другое в своем коде, а не полагаться на реализацию того или иного JDBC driver'а С уважением, Владимир 0

@boaa 0 / 0 / 0 Регистрация: 08.06.2011 Сообщений: 63
	15.11.2006, 17:29
	Опа... Это ж скоко кода надо пофиксить... 0

@Danissimo 4 / 4 / 4 Регистрация: 28.08.2008 Сообщений: 611
	15.11.2006, 17:57
	Я тут свои 2 копейки добавлю. vlav, не греши. jvm + java тут не причем (надеюсь, мы говорим о стабильной версии, а не бета какой-нть). 100%. Да, все остальные софтины, как то драйверы (выпущенные не саном), а также наши собственные могут грешить багами. Я бы мог рассказать о том, какие приложения, скока работают, скока потоков и тд. и тп. мне пришлось сделать, в каких ситуациях у них были OutOdMemoryError и почему. Проще -- ищи не в java. В драйвере, в своем коде (ставлю, что баг в твоем коде, причем на уровне дизайна). Для любителей передергивать: я не говорю, что в java нету багов. Я говорю про конкретный "баг" -- OutOfMemoryError. 0

@vlav 0 / 0 / 1 Регистрация: 14.02.2009 Сообщений: 470
	15.11.2006, 18:36 [ТС]
	У меня (плююсь ) - все прошло, когда я убрал ошибку, что в некоторых (редких) случаях в потоке возникало переполнение массива. 0

@Danissimo 4 / 4 / 4 Регистрация: 28.08.2008 Сообщений: 611
	15.11.2006, 19:07
	Стоп-стоп =)) С этого места по-подробнее, пожалуйста. Обращение за пределы массива возбуждает совсем другую ошибку: ArrayIndexOutOfBoundsException. Это RuntimeException. А у тебя мало того, что OutOfMemoryError вылетает, так он еще и Error -- из совсем другой иерархии. Может, конечно, возникавщий ArrayIndexOutOfBoundsException приводил к возникновению OutOfMemoryError из-за того, что где-то стек разрушался, и все начинало работать неправильно. Но выглядит пофикс довольно странно. Лично я рекомендую проверить все. Почему выход за пределы массива приводили к OutOfMemoryError. 0