LINUX.ORG.RU

[java] memory leaks


0

2

Здравствуйте!
Как искать в java утечки памяти?
Если я запускаю netbeans profiler, совершаю какие-то действия в приложении и при этом, каждый раз, совершая действие, surviving generations увеличивается - является ли это утечкой?

★★★★★

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

Скорее всего это не утечка! При достижении определенного порога используемой памяти, либо через некоторое время, запустится GC и удалит не используемые объекты.

Daeloce ()

я использую YourKit Java Profiler.

JFreeM ★★★☆ ()

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

Если я запускаю netbeans profiler, совершаю какие-то действия в приложении и при этом, каждый раз, совершая действие, surviving generations увеличивается - является ли это утечкой?


не обязательно.

JFreeM ★★★☆ ()

пульзуй валу, в ней гц на подсчете ссылок

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

>Скорее всего это не утечка! При достижении определенного порога используемой памяти, либо через некоторое время, запустится GC и удалит не используемые объекты.
Эх, в том и беда, что приложение работало, работало почти месяц, потом ВНЕЗАПНО начало сыпать NPE. Перезапускаю - снова NPE (уже сразу). К базе не коннектит, и вообще ведет себя неадекватно. Перезалил на сервер, перезапустил - все работает прекрасно. Хотя, админ говорит, что якобы память течет, вот проверяю, пытаюсь отыскать, правда ли это.

шг такие взмыленные x_x

это не я, это все scrot :)

kovrik ★★★★★ ()

Ставь на мониторинг и следи за графиком. Если пила горизонтальная, то всё нормально.

Перезапускаю

Вместе с контейнером? Если нет, то вполне возможно, что проблема в permgen. По прошествии некоторого количества перезапусков он выелся.

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

>Вместе с контейнером? Если нет, то вполне возможно, что проблема в permgen. По прошествии некоторого количества перезапусков он выелся.
Когда он сыпал NPE, то перезапускал вместе с контейнером. А он снова за свое. Потом перезалил - и вроде ПОКА что работает.

Ставь на мониторинг и следи за графиком. Если пила горизонтальная, то всё нормально.

Так, а вот насчет мониторинга. Если мониторить через VisualVM - как ее подрубить к удаленной машине? Открываю порт на сервере, в опциях томката разрешаю подключаться к этому порту по jmx, в visualvm добавляю remote connection, пишу <hostname>:<port>, он пытается добавить подключение, но не получается. Из-за чего это может быть?

kovrik ★★★★★ ()

Может ты delete где-то забыл сделать?

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

Фиг знает, может и забыл, найти б только где =) И вообще, для начала хотелось бы точно определиться есть утечка или нет.

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

Это аля капитан Петросян.[br] Я на джаве не пишу и до сих пор честно полагал, что в джаве нет утечек в принципе. Фраза «утечка памяти в джаве» «делит мой мозг на 0».

anonymous ()
Ответ на: комментарий от kovrik

Так, еще такой вопрос: вот слежу за графиками и памятью. Память растет медленно, дошла где-то до 40MB (used memory; Total Memory - 75MB), а потом резко упала до 20 (GC запустился?), но при этом surviving generations увеличилось на 1. Это что значит?

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

В джаве вполне могут быть утечки, пример:

public class LeakExample 
{
	static Vector myVector = new Vector();
	static HashSet pendingRequests = new HashSet();

	public void slowlyLeakingVector(int iter, int count) 
	{
		for (int i=0; i<iter; i++) 
		{
			for (int n=0; n<count; n++) 
			{
				myVector.add(Integer.toString(n+i));
			}
			for (int n=count-1; n>0; n--) 
			{
				// Oops, it should be n>=0
				myVector.removeElementAt(n);
			}
		}
	}
}

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

Всё. Мой мир перевернулся. Я так надеялся, что где-то в безбрежном океяне айти есть островок, в котором всё шоколадно, нет сегфолтов, всяких дурацких деструкторов, if (ret < 0) и т.п.

А тут такой БП.

Пойду напьюсь, чего ещё остаёться?

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

Я тоже надеялся, а теперь вот сижу, смотрю на графики, да ищу утечки =)

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

Ну NPE не очень связан с утечкой, там алгоритмическая ошибка как я понял

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

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

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

«The slowlyLeakingVector has a wrong condition in the second for loop, due to which one String object leaks in every iteration.»

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

Часто утечкой считают когда данные становятся недостижимы, тоесть они не доступны из рабочих структур. А это алгоритмическая ошибка, так как мусор в векторе видно и он поломает алгоритм скорее всего. Утечка же сама по себе обычно ничего неломает, кроме того что жрет память. В Java недостижимые данные подчищаются сборщиком мусора.

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

vertexua ★★★☆☆ ()

>Если добраться до объекта из программы можно, то это не «утечка»
именно это и называется «утечка» - сохранение ссылок на ненужные более обьекты.

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

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

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

И GC их удалять не будет - ссылки-то на них есть!

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

>В коллекции содержится куча ненужных объектов - утечка.
не, ну во первых сессия рано или поздно умрет и будет собрана GC
Во вторых, не принимайте буквально выражение «обьект будет собран GC только в том случае если на него нет ссылки». Во первых есть WeakReference, во вторых если например, есть коллекция, на которую никто не ссылается и в этой коллекции есть обьект, то при очередном сборе мусора коллекция уйдет вместе с обьектом. Почитайте про GC Root

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

ОК, надо будет почитать.
А что считать утечкой, если судить по графикам?
Threads: 17
Total memory: 716,701,696 B
Used memory: ~30,000,000 B (и периодически падает до 10,000,000)

А surviving generations не уменьшаются - либо держатся на одном уровне достаточно долгое время, либо увеличиваются (медленно, но все же).

Утечка?

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

ваши скриншоты показывают, что первый из них - снят за одну минуту, второй - за 10. По этим данным никто и ничего вам не скажет. Чтобы можно было сказать что-то определенное, надо хотя бы сутки промониторить под нагрузкой. Опять же, лики по моему опыту характеризуются неспадающим графиком Old Generation. Survivor я так понимаю, это Young Generation и он может скакать как угодно - о ликах это ничего не говорит. Вообще говоря, обьекты перемещаются из young space в old space, поэтому следить надо только за вторым.

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

Ещё можно поступать так:

1) Снять дамп хипа (см. jmap) 2) Погонять запросы на сервер. 3) Снять второй дамп хипа. 4) Сравнить дампы. Анализировать.

WFrag ★★★★ ()

В общем, оставлял мониторинг на 2 дня, ничего вроде не течет, памяти 20 метров кушает...видимо все ок :) всем спасибо!

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

Это тоже утечка?

List<Integer> integerList = new LinkedList<Integer>();
for (int i = 0; ;i++) {
    integerList.add(i);
}

GreenFenix ()

Берёшь любой профайер (я использовал упомянутый тут YourKit Java Profiler) и делаешь дамп памяти. В профайлере смотришь в этом дампе, какие объекты (понятно, что это будут какие-то списки, массивы) отжирают память и ищешь, что ты делаешь не так (например, подвешиваешь их к глобальным хранилищам), что не даёт работать сборщику мусора.

В общем, чисто рутинная процедура :)

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

>пульзуй валу, в ней гц на подсчете ссылок

Так для кольцевых же ссылок такой метод не работает.

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

>потом ВНЕЗАПНО начало сыпать NPE

А при чём тут утечки памяти? NPE — это обращение к NULL-указателю.

Утечки памяти — это OutOfMemory

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

>ну и где тут учечка? не путайте ошибки в коде и утечки памяти

Утечки памяти — всегда следствие ошибок в коде.

// Ваш К.О. :)

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