Объекты установки Java аннулировать больше делают что-нибудь?
Если у класса Box нет конструктора с T, то вы можете создать класс, расширяющий Box. Например:
class NewBox extends Box {
...
}
Затем вы можете создать экземпляр G, например:
G g = new G<>(new NewBox());
Но в вашем случае Box имеет конструктор Box(T val){...}, тогда NewBox требуется соответствие конструктора super ] вроде:
class NewBox extends Box {
NewBox(NewBox val) {
super(val);
}
}
Чтобы создать его, вы должны получить нулевое значение, иначе это приведет к бесконечному вложению:
G g = new G<>(new NewBox(new NewBox(new NewBox(null))));
Обновление: , чтобы ответить Исходный вопрос: G означает, что T должен быть типом Box или любым потомком Box. Как вы правильно заметили, это приведет к бесконечной вложенности. Но вы все еще можете создать этот экземпляр без создания дополнительного класса (как указано выше с NewBox), используя Wildcard и null в качестве параметра для конструктора класса G, например: 1125]
G tg = new G<>(null);
4 ответа
Это немного зависит от того, когда вы думали об обнулении ссылки.
Если у вас есть цепочка объектов 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-компилятор может определить, в какой момент данная ссылка на локальный объект больше не используется.
тогда без явного обнуления ссылки она не станет собираемой мусором до завершения метода doSomethingElse () . И это совет, который , вероятно, больше не актуален для современных JVM : оказывается, JIT-компилятор может определить, в какой момент данная ссылка на локальный объект больше не используется. тогда без явного обнуления ссылки она не станет собираемой мусором до завершения метода doSomethingElse () . И это совет, который , вероятно, больше не актуален для современных JVM : оказывается, JIT-компилятор может определить, в какой момент данная ссылка на локальный объект больше не используется. Нет, это не устаревший совет. Висячие ссылки по-прежнему являются проблемой, особенно если вы, скажем, реализуете контейнер расширяемого массива ( ArrayList или тому подобное) с использованием предварительно выделенного массива. Элементы, превышающие «логический» размер списка, должны быть обнулены, иначе они не будут освобождены.
См. Эффективное Java 2-е изд., Правило 6: Устранение устаревших ссылок на объекты.
В средах с ограниченным объемом памяти (например, в мобильных телефонах) это может быть полезно. Установив значение null, объекту objetc не нужно ждать, пока переменная выйдет из области видимости и будет обработана.
Однако для повседневного программирования это не должно быть правилом, за исключением особых случаев, таких как тот Цитируется Крис Джестер-Янг.
Поля экземпляра, элементы массива
Если есть ссылка на объект, он не может быть собран сборщиком мусора. Особенно, если этот объект (и весь граф, стоящий за ним) большой, есть только одна ссылка, которая останавливает сборку мусора, и эта ссылка больше не нужна, это досадная ситуация.
Патологические случаи - это объект, который сохраняет случайный экземпляр для всего дерева 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();
}
Длинные плоские области видимости также плохо влияют на читаемость кода. Введение частных методов разбиения вещей только для этой цели тоже не является чем-то необычным.