Переменные, которые ссылаются на объект, который хранится в переменной Session, собираются GC? - PullRequest
1 голос
/ 13 апреля 2011

Я не очень знаком с тем, как работает сборка мусора и что вызывает утечки памяти. Но я в тот момент, когда меня это беспокоит, и я хочу написать более эффективный код. Таким образом, у проекта, над которым я работаю, который является веб-приложением Asp.Net, есть экземпляр пользовательского DataCriteria, который создается при запуске сеанса в global.asax и затем сохраняется в переменной Session. Этот пользовательский DataCriteria - это то, что мы используем для связи с базой данных для методов CRUD.

Первый вопрос, скажем, у нас есть класс Person, и в этом классе Person есть поле DataCriteria, которое установлено в экземпляр переменной Session объекта DataCriteria. Поскольку экземпляр Person содержит ссылку на экземпляр DataCriteria, который не будет утилизирован до завершения сеанса, этот экземпляр Person будет в состоянии быть собранным. Или каждый экземпляр Личности не будет утилизирован до окончания этой Сессии.

Второй вопрос более общий, но тот же. По сути, мне интересно, сможет ли переменная, объявленная в методе, который ссылается на экземпляр переменной Session объекта DataCriteria, быть в состоянии собрать GC? Или он останется до конца сессии?

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

Ответы [ 2 ]

2 голосов
/ 13 апреля 2011

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

Где вещи могут стать немного странными, это когда ссылки не слишком очевидны. Например, экземпляр C становится ссылкой на экземпляр D, когда C подписывается на событие, представленное D. Это означает, что, если D является долгоживущим, C не станет доступным для сборки мусора до D, пока не откажется от подписки на событие. Ссылки, хранящиеся в событиях и других делегатах, на самом деле объясняют большую часть утечек памяти в приложениях .NET. (Собственно говоря, в действительности это не утечки памяти, поскольку нет фактического сбоя при очистке памяти, которая не используется фактическими экземплярами объекта.)

1 голос
/ 13 апреля 2011

Ссылки на объекты составляют ориентированный граф - объект A ссылается на объект B. До тех пор, пока A не будет собрана, B не может быть.

Session - это просто еще один объект, который ссылается на вещи - это объект A, ссылающийся на ваш объект B.Человек остается рядом, пока сессия не уходит.если Сессия не ссылается на вашу Личность, их жизни не связаны.

Теперь вы должны остерегаться того, на что еще ссылаются ваши DataCriteria.Если он содержит соединения с базой данных или другие объекты, они будут жить столько же, сколько и Session.

...