Делает ли что-нибудь установка объектов Java на null?

Я просматривал старые книги и нашел копию "Практической Java" Питера Хаггера. В разделе производительности есть рекомендация устанавливать ссылки на объекты, nullкогда они больше не нужны.

Может ли в Java устанавливать ссылки на объекты для nullповышения производительности или эффективности сборки мусора? Если да, то в каких случаях это проблема? Контейнерные классы? Состав объекта? Анонимные внутренние классы?

Я довольно часто вижу это в коде. Это устаревший совет по программированию или он все еще полезен?

Это немного зависит от того, когда вы подумывали обнулить ссылку.

Если у вас есть цепочка объектов A-> B-> C, то, как только A станет недостижимым, все A, B и C будут иметь право на сборку мусора (при условии, что ничто другое не относится ни к B, ни к C). Например, нет необходимости и никогда не было необходимости явно устанавливать для ссылок A-> B или B-> C значение null.

Кроме того, в большинстве случаев проблема не возникает, потому что на самом деле вы имеете дело с объектами в коллекциях. Как правило, вы всегда должны думать об удалении объектов из списков, карт и т. Д., Вызывая соответствующий метод remove ().

Случай, когда раньше давались некоторые советы по установке ссылок на null, был специально в длинной области, когда объект, интенсивно использующий память, переставал использоваться на полпути через область . Например:

{
  BigObject obj = ...
  doSomethingWith(obj);
  obj = null;             <-- explicitly set to null
  doSomethingElse();
}

Обоснованием здесь было то, что, поскольку obj все еще находится в области видимости, без явного обнуления ссылки он не станет собираемым мусором до завершения метода doSomethingElse () . И это совет, который, вероятно, больше не актуален для современных JVM : оказывается, JIT-компилятор может определить, в какой момент данная ссылка на локальный объект больше не используется.

Нет, это не устаревший совет. Висячие ссылки по-прежнему представляют собой проблему, особенно если вы, скажем, реализуете контейнер расширяемого массива (ArrayList или что-то подобное) с использованием предварительно выделенного массива. Элементы, превышающие «логический» размер списка, должны быть обнулены, иначе они не будут освобождены.

См. Эффективное Java 2-е изд., Правило 6: Устранение устаревших ссылок на объекты.

Поля экземпляра, элементы массива

Если есть ссылка на объект, он не может быть собран сборщиком мусора. Особенно, если этот объект (и весь граф за ним) большой, есть только одна ссылка, которая останавливает сборку мусора, и эта ссылка больше не нужна, что является неудачной ситуацией.

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

Поэтому, если вы не уверены, что объект, содержащий ссылку, в любом случае (или даже в этом случае) будет обработан сборщиком мусора, вам следует обнулить все, что вам больше не нужно.

Переменные в области видимости:

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

{
  BigObject obj = ...
  doSomethingWith(obj);
  obj = null;          //   <-- explicitly set to null
  doSomethingElse();
}

становится

{
  {  
     BigObject obj = ...
     doSomethingWith(obj);
  }    //         <-- obj goes out of scope
  doSomethingElse();
}

Длинные плоские области видимости также плохо сказываются на читаемости кода. Внедрение частных методов для разбивки вещей только для этой цели тоже не является чем-то необычным.

В средах с ограниченным объемом памяти (например, в мобильных телефонах) это может быть полезно. Установив значение null, объекту objetc не нужно ждать, пока переменная выйдет за пределы области видимости для gc'd.

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

Во-первых, это не значит, что вы устанавливаете объект null. Объясняю это ниже:

List list1 = new ArrayList();
List list2 = list1;

В приведенном выше сегменте кода мы создаем имя переменной ссылки list1на ArrayListобъект, которая хранится в памяти. Так list1ссылается на этот объект, и это не что иное, как переменная. А во второй строке кода мы копируем ссылку list1на list2. Итак, теперь вернемся к вашему вопросу, если я сделаю:

list1 = null;

это означает, что list1больше не ссылается на какой-либо объект, который хранится в памяти, поэтому list2ему также не на что ссылаться. Итак, если вы проверите размер list2:

list2.size(); //it gives you 0

Итак, здесь появляется концепция сборщика мусора, в которой говорится «Вам не о чем беспокоиться об освобождении памяти, удерживаемой объектом, я сделаю это, когда обнаружу, что он больше не будет использоваться в программе, и JVM будет управлять мной».

Надеюсь, это проясняет концепцию.

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