LINUX.ORG.RU

Java и течь памяти


0

0

Прошу помощи, у меня есть небольшая прога, в ней 3 вложенных цикла, они выполняются несколько десятков тысячь раз (в перспективе до нескольких сотен тысяч раз), за это время прога отжирает около 400метров и падает с СистемОутОфМемори, хотя должна переодически освобождать ресурсы. Как отловить место где текет память? На какие моменты обратить внимание? (в циклах делается запросы к СУБД и вывод в файл).

★★

Ответ на: комментарий от DDR

Вы не закрываете ResultSet-ы и Statement-ы. Перепишите DBSelect так, что бы он возвращал конечные данные, а не ResultSet-ы. Ловите SQLException в DBSelect при помощи try-catch-finally. Закрывайте Statement-ы в finally. При этом ResultSet-ы будут закрываться автоматически.

bbk123 ★★★★★
()
Ответ на: комментарий от DDR

Просто я думал раз метод отработал и выходит то гарбишь корректор собирает эти резалтсеты.

DDR ★★
() автор топика
Ответ на: комментарий от DDR

> Просто я думал раз метод отработал и выходит то гарбишь корректор собирает эти резалтсеты.

На них всё ещё есть ссылки из других мест. Поэтому GC не может их удалить.

bbk123 ★★★★★
()
Ответ на: комментарий от wfrr

Спасибо большое, буду пробовать.

DDR ★★
() автор топика
Ответ на: комментарий от bbk123

Какбе в документации нетривиально написано что GC может никогдаих и не собрать. И что есть метод close кой надо вызывать.

wfrr ★★☆
()
Ответ на: комментарий от wfrr

Благодарю за цитаты доков! Буду знать!:)

DDR ★★
() автор топика
Ответ на: комментарий от DDR

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

real_maverick ★★★
()
Ответ на: комментарий от wfrr

> Какбе в документации нетривиально написано что GC может никогдаих и не собрать. И что есть метод close кой надо вызывать.

Опять потролить пришёл? Про close() я уже говорил. Дальше я объяснил почему без close() GC их не соберёт. В каком месте у тебя случился дислективный разрыв?

bbk123 ★★★★★
()
Ответ на: комментарий от wfrr

Какбе в документации нетривиально написано что GC может никогдаих и не собрать. И что есть метод close кой надо вызывать.

А вот отсюда по подробнее. Вот кусок из официальной документации

4.1.4 Closing Statements

Statement objects will be closed automatically by the Java garbage collector. Nevertheless, it is recommended as good programming practice that they be closed explicitly when they are no longer needed. This frees DBMS resources immediately and helps avoid potential memory problems. 

Тут вроде ясно сказано, что GC должен собрать незакрытый Statement, если конечно ты сам его не удерживаешь. Не надо путать хороший тон программирования (...as good programming practice...) и обязаловку.

pathfinder ★★★★
()
Ответ на: комментарий от pathfinder

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

pathfinder ★★★★
()
Ответ на: комментарий от DDR

>Я htop'ом смотрю как в течение 30 секунд оно у меня сжирает память 400метров:)

И сколько остается свободной для Явы памяти в момент OutOfMemory? Ноль?

pathfinder ★★★★
()
Ответ на: комментарий от pathfinder

Вы смотрите текст старой спецификации. Вот как это прописано в JDBC 4.0:

13.1.4 Closing Statement Objects

An application calls the method Statement.close to indicate that it has finished
processing a statement. All Statement objects will be closed when the connection
that created them is closed. However, it is good coding practice for applications to
close statements as soon as they have finished processing them. This allows any
external resources that the statement is using to be released immediately.

bbk123 ★★★★★
()
Ответ на: комментарий от DDR

Открытые файловые дискрипторы можно посмотреть программой lsof. Пердварительно прочтите man lsof.

bbk123 ★★★★★
()
Ответ на: комментарий от bbk123

>Вы смотрите текст старой спецификации. Вот как это прописано в JDBC 4.0:

Прочитал данный текст. Там вроде ничего не написано по части поведения GC по отношению к незакрытому Statement. То, что явное закрытие это «good coding practice», это и ежу понятно.

Вопрос то в другом.

Почему GC не закрыл Statement? И в каких случаях это может произойти? Может в данном случае GC просто не запускался, так как исчерпалась не память, а что-то другое?

Тут либо какой-нибудь Connection неявно от программиста удерживает ссылку на Statement, либо исчерпались другие ресурсы.

pathfinder ★★★★
()
Ответ на: комментарий от pathfinder

Тут вроде ясно сказано, что GC должен собрать незакрытый Statement

Там (в доках) есть еще слова про то что GC может никогда не собрать определенный объект, именно про то и речь.

wfrr ★★☆
()
Ответ на: комментарий от pathfinder

>Прочитал данный текст. Там вроде ничего не написано по части поведения GC по отношению к незакрытому Statement. То, что явное закрытие это «good coding practice», это и ежу понятно.

Как же, написано:

An application calls the method Statement.close to indicate that it has finished processing a statement. All Statement objects will be closed when the connection that created them is closed.


Таким образом, незакрытые Statement'ы закрываются после закрытия Connection, но лучше закрывать их вручную. Но Connection в том коде вообще не закрывается, то есть и Statement, по идее, остаются открытыми до конца работы VM.

proud_anon ★★★★★
()
Ответ на: комментарий от proud_anon

>Как же, написано:

An application calls the method Statement.close to indicate that it has finished processing a statement. All Statement objects will be closed when the connection that created them is closed.

Ну там вообще-то сказано, что при закрытии Connection закрываются Statement, не более того. Там не сказано, что GC гарантировано не может собрать незакрытые Statement до закрытия Connection. Может Connection использует слабые ссылки на Statement?

pathfinder ★★★★
()
Ответ на: комментарий от pathfinder

Всем огромное спасибо, особенно bbk123. Переписал с ресалтсетов на очередь и чищу ресалсеты и статементы и память больше не текет:) И работает оч быстро.

DDR ★★
() автор топика
Ответ на: комментарий от pathfinder

> Тут либо какой-нибудь Connection неявно от программиста удерживает ссылку на Statement...

Именно об этом я и говорил.

bbk123 ★★★★★
()
Ответ на: комментарий от wfrr

Обратитесь наконец к врачу. Ваши дислективные припадки уже надоели.

bbk123 ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.