Следующий сценарий называется утечка памяти в Java? Разве это не мусор?

Question

Если какая-либо переменная объекта все еще указывает на некоторый объект, который бесполезно, тогда JVM не будет собирать мусор этот объект и объект останется в памяти, создав утечку памяти

В приведенном выше сценарии возможна утечка памяти. Почему это не сборщик мусора? Кто-нибудь может уточнить это?

Answer 1

Пока у кого-то есть ссылка на объект, его можно использовать, а JVM не может собирать мусор.

JVM определяет, используются ли кластеры объектов, путем поиска пути ссылок от корня до рассматриваемых объектов. Это означает, что кластер объектов, которые ссылаются друг на друга, но не ссылаются на остальную часть системы, будет собирать мусор.

Таким образом, простое наведение объекта на вас не помешает вам собрать мусор.

Answer 2

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

Было доказано, что невозможно с 100% точностью и во всех ситуациях определить, будет ли данный объект использоваться впоследствии. Вместо этого сборщики мусора используют «следующую лучшую вещь», которая заключается в том, что они выпускают объекты, которые достижимы : объект, к которому нельзя получить доступ из приложения, из-за отсутствия пути ссылок на этот объект, никогда больше не будет использоваться приложением, поскольку приложение не сможет даже заметить, что объект все еще существует. Это приближение, но это безопасно: GC не будет освобождать объект, который все еще используется, но он может не выпустить объект, который больше не будет использоваться, если этот объект кажется достижимым (т.е. приложение может все еще протянуть руку и схватить объект, если он того пожелает).

«Утечка памяти» - это ситуация, когда неиспользуемые объекты используют чрезмерное количество ОЗУ. Что такое «неординарный», зависит от приложения. Единственный неиспользованный объект редко является проблемой. Обычные важные утечки - это ситуации, когда неиспользуемые, но достижимые объекты накапливаются тысячами.

Answer 3

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

Answer 4

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

Больше информации здесь: http://www.javaworld.com/javaworld/javatips/jw-javatip79.html

Answer 5

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

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

Answer 6

Это не сборщик мусора, потому что JVM не может определить, будет ли когда-либо использоваться ссылка в этой переменной объекта в будущем. Для такого определения в общем случае потребуется, чтобы JVM решила проблему остановки.

Answer 7

Если у вас есть ссылка на объект, как JVM должна знать, что он «бесполезен»? Если вам это не нужно, отбросьте ссылку, и JVM скажет, что вы больше не собираетесь ее использовать. GC в Java довольно хорош, но он не может читать ваши мысли или определять ваши намерения кода.