вызовет ли утечка памяти анонимный экземпляр класса, который имеет неявную ссылку на экземпляр, содержащий один объект? - PullRequest
Новая
       25

вызовет ли утечка памяти анонимный экземпляр класса, который имеет неявную ссылку на экземпляр, содержащий один объект?

2 голосов
/ 24 января 2012 
public class Singleton {

  public void processRequest(final List<a> aList) {

      List<b> bList = new AbstractList<b>() {
              b get(int i) {
                   return (b)aList.get(i); 
              }

              int size() {
                   return aList.size();
              }

             ......
      }

  }

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

любая помощь приветствуется!

Ответы [ 3 ]

3 голосов
/ 24 января 2012

Нет, здесь нет утечки памяти.Объекты, которые ссылаются на объекты без мусора, могут быть собраны;это только объекты , на которые ссылается объекты без мусора, которые не могут стать мусором.

0 голосов
/ 31 октября 2014

Этот ответ приходит через 2 года после факта, но он попал под мою аналогичную область вопросов, когда я спросил: Ссылка на конечный объект в конструкторе анонимного класса - утечка?

Я даю другой ответ, чем @Russel и @Sebestian, потому что они основаны на узком определении утечки памяти. Однако утечка часто означает в языках GC «сохранение ссылки, что не позволяет GC собирать ее». http://android -developers.blogspot.com / 2009/01 / avoiding-memory-leaks.html и мне кажется, что OP использовал этот термин. Я думаю, он спрашивает, я непреднамеренно поддерживаю этот объект? Я запрещаю GC требовать это?

Если это ваши настоящие вопросы, то ответ - да. aList является имплицитным полем bList. Сохранение ссылки на bList предотвратит сбор aList, если bList остается в живых.

0 голосов
/ 12 июня 2012

Как сказал Рассел, здесь нет утечки памяти.

Объект имеет право на сборку мусора, когда он недоступен ни одному потоку.

Если на объект не ссылается ни один другой объект, он никогда не будет доступен. Но если A и B ссылаются друг на друга, это не значит, что они достижимы, потому что они оба могут быть недоступны из любого потока. Это то, что мы называем Остров изоляции

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

достижимость

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

Справочный пакет Java API

...