Влияет ли назначение объектов на null в Java на сборку мусора?

Question

Присваивает ли назначение неиспользуемой ссылки на объект null в Java улучшение процесса сбора мусора каким-либо измеримым образом?

Мой опыт работы с Java (и C #) научил меня, что часто бывает нелогично пытаться перехитрить виртуальную машину или JIT-компилятор, но я видел, как коллеги используют этот метод, и мне любопытно, хорошо ли это Практика, чтобы забрать или одно из тех предрассудков программирования вуду?

Answer 1

В дальнейшем выполнении вашей программы значения некоторых элементов данных будут использоваться для вывода на компьютер видимого внешнего вида программы. Другие могут или не могут быть использованы, в зависимости от будущих (и невозможно предсказать) входов в программу. Другие члены данных могут быть гарантированно не использованы. Все ресурсы, включая память, выделенную для этих неиспользуемых данных, тратятся впустую. Работа сборщика мусора (GC) состоит в том, чтобы устранить эту потерянную память. Было бы губительно для GC устранить то, что было необходимо, поэтому используемый алгоритм мог бы быть консервативным, сохраняя больше строгого минимума. Он может использовать эвристические оптимизации для повышения скорости за счет сохранения некоторых элементов, которые на самом деле не нужны. Есть много потенциальных алгоритмов, которые может использовать GC. Поэтому возможно, что изменения, которые вы вносите в свою программу и которые не влияют на правильность вашей программы, могут, тем не менее, повлиять на работу GC, либо заставляя его работать быстрее для выполнения той же работы, либо быстрее идентифицировать неиспользованные элементы. Так что такого рода изменения, установка нечетной ссылки на объект на null, в теории не всегда вуду.

Это вуду? По сообщениям, есть части кода библиотеки Java, которые делают это. Авторы этого кода намного лучше, чем обычные программисты, и либо знают, либо сотрудничают с программистами, которые знают детали реализаций сборщика мусора. Таким образом, можно предположить, что иногда приносит пользу.

Answer 2

Даже если аннулирование ссылки было бы несколько более эффективным, стоило ли бы уродство того, чтобы приправлять ваш код этими уродливыми аннулированием? Они будут только загромождать и затенять код намерения, который их содержит.

Это редкая кодовая база, у которой нет лучшего кандидата на оптимизацию, чем попытка перехитрить сборщик мусора (реже все же есть разработчики, которым удается перехитрить его). Скорее всего, ваши усилия будут лучше потрачены в другом месте, отказавшись от этого грубого парсера Xml или найдя некоторую возможность для кеширования вычислений. Эта оптимизация будет легче определить количественно и не потребует от вас загрязнения вашей базы кода шумом.

Answer 3

" Зависит от "

Я не знаю о Java, но в .net (C #, VB.net ...) обычно не требуется присваивать нуль, когда вам больше не нужен объект.

Однако обратите внимание, что это "обычно не требуется".

Анализируя ваш код, компилятор .net хорошо оценивает время жизни переменной ... чтобы точно определить, когда объект больше не используется. Так что, если вы напишите obj = null, на самом деле это может выглядеть так, как будто obj все еще используется ... в этом случае непродуктивно назначать значение null.

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

Для этого не существует жесткого и быстрого правила. Придерживаясь вышесказанного, поместите null-assignments в ваш код и запустите профилировщик, чтобы посмотреть, поможет ли это в любом случае. Скорее всего, вы не видите выгоды.

Если вы пытаетесь оптимизировать код .net, то мой опыт показывает, что забота о методах Dispose и Finalize на самом деле более выгодна, чем забота о пустых значениях.

Некоторые ссылки по теме:

http://blogs.msdn.com/csharpfaq/archive/2004/03/26/97229.aspx

http://weblogs.asp.net/pwilson/archive/2004/02/20/77422.aspx