Утечка памяти захватывает в API Стандарта Java
о, Боже не получайте меня, запустился
, у меня когда-то был декан cs в уважаемом университете, говорят мне, что объектно-ориентированное программирование было просто 'популярным товаром', таким образом, они не предложили классов, мимоходом полагает как C++
относительно того, почему они не преподают эти вещи, ну, в общем, колледж там, чтобы преподавать Вам основные принципы дисциплины, не обязательно лучшие практики промышленности
6 ответов
Важным из них является то, что получение подстрок строк Java относится к исходной строке.
Пример: вы читаете запись из 3000 символов и получаете подстроку из 12 символов, возвращая ее в вызывающий (в той же JVM). Несмотря на то, что у вас нет прямой ссылки на исходную строку, эта 12-символьная строка все еще использует 3000 символов в памяти.
Для систем, которые получают и затем анализируют много сообщений, это может быть реальной проблемой.
] У вас есть несколько способов избежать этого:
String sub = new String(str.substring(6,12));
или
String sub = str.substring(6,12).intern();
Первый более четкий. У второго есть другие последствия, потому что вы используете пространство PermGen. При чрезмерном использовании вы можете закончиться, если не дадите достаточно виртуальной машины.
Помните, что это актуально только в том случае, если вы берете небольшие подстроки, а затем выбрасываете исходную строку и делаете это много.
Любые нестатические внутренние классы, которые вы сохраняете за внешними классами. Так что этот невинно выглядящий внутренний класс может удерживать огромный граф объектов. Поместите экземпляр в статическую коллекцию или коллекцию для всего приложения, и вы используете много памяти, которую не должны использовать.
Все, что вы регистрируете в качестве получателя События, например, в рамках графического интерфейса пользователя, не может быть собран сборщиком мусора, пока он зарегистрирован и источник события жив.
Это может вызвать утечку памяти, если разработчик не знает об этом. сильная ссылка от источника события на подписчика события.
Каждый экземпляр потока выделяет память для стека (по умолчанию 512 КБ, настраивается с помощью -Xss ). Это не утечка как таковая , но наивная попытка сильно многопоточности приложения приведет к значительному неочевидному потреблению памяти.
Использование сильных ссылок, когда было бы достаточно слабых ссылок. Обычными виновниками здесь являются приложения и API-интерфейсы, которые выполняют собственное управление состоянием и ресурсами.
Затем используется шаблон Observer, который может привести к утечкам памяти - когда Observer удаляет себя из Subject, память не может быть исправлено, если Субъект также не выпустит ссылку на Наблюдателя / Слушателя. На это уже указывалось ранее, но не многие люди понимают, что даже регистраторы являются наблюдателями.
Кроме того, существует вероятность классов, чьи объекты при создании экземпляров автоматически помещаются в статический член . Некоторые из этих классов даже не имеют метода release () или dispose (), поэтому ссылки по-прежнему удерживаются статическим членом.
Любой класс с методом dispose ()?
Например java.awt.Window # dispose :
public void dispose ( )
Освобождает все собственные ресурсы экрана, используемые этим Окном, его подкомпонентами и всеми его дочерними элементами. То есть ресурсы для этих Компонентов будут уничтожены, вся память, которую они потребляют, будет возвращена в ОС, и они будут помечены как неотображаемые.