C#: В каких случаях необходимо аннулировать ссылки?
Существуют партии, описанные здесь: http://www.gnu.org/licenses/license-list.html#SoftwareLicenses
, решение которого использовать может быть политическим, но должно в конечном счете быть определено Вашими планами/требованиями относительно программного обеспечения. Если Вы хотите удостовериться, что это всегда свободно, тогда выбирают GPL или другую "Разрешенную для копирования" лицензию. Если Вы не возражаете против некоторого коммерческого использования, выбираете другой, это совместимо с этим.
3 ответа
Это нужно делать только тогда, когда переменная, содержащая ссылку, будет оставаться «активной», но вы не хотите, чтобы сама ссылка предотвращала сборку мусора. Другими словами, если объект A содержит ссылку на объект B, и B вам больше не нужен, но A останется в живых по другим причинам. Другой распространенный пример - статические переменные, которые «живы» до тех пор, пока существует AppDomain.
Для локальных переменных они почти никогда не нужны, потому что GC может обнаружить последнюю возможную точку в коде, где переменная будет доступна. Однако, если вы используете переменную, объявленную вне цикла во время первой итерации, но знаете, что она вам не понадобится для последующих итераций, вы можете установить для нее значение null, чтобы помочь объекту получить право на сборку мусора. ранее.
По моему опыту, очень редко оказываюсь в такой ситуации. Я почти никогда не устанавливаю переменные в null ради сборки мусора. Обычно все переменные-члены в объекте «полезны» до тех пор, пока сам объект не станет подходящим для GC. Если вы обнаружите, что у вас есть переменные-члены, которые не полезны на протяжении всего жизненного цикла объекта, вы можете захотеть узнать, указывает ли это на проблему с проектом.
Это важно, если у вас есть долгоживущие объекты (например, пример кеша в вашей цитате), содержащие ссылки на короткоживущие объекты (например, элементы кеша). Другими примерами долгоживущих объектов могут быть одноэлементные объекты, экземпляр основной формы в приложении Windows Forms, экземпляр приложения приложения ASP.NET и т. Д.
Я хотел бы добавить еще одну распространенную проблему: недолговечные объекты, подписывающиеся на события публикуются долгоживущими объектами. Поскольку издатель события содержит ссылку на всех подписчиков, подписчики (например, ASP.
Вы должны обнулить ссылки на объект, который вам больше не нужен, если вы знаете, что в противном случае они не будут собраны в мусор.
Если у вас есть Эффективная Java книга Посмотрите на Правило 5, там есть пример реализации стека с утечками памяти, потому что ссылки на объекты не обнуляются. Если у вас нет этой книги, вы можете найти ее в Google Книгах здесь .