Найти ссылки на объект во время выполнения

Question

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

if (container.Controls.Count > 0) 
{ 
    var controls = new Control[ container.Controls.Count ]; 
    container.Controls.CopyTo(controls, 0); 

    foreach (var control in controls) 
    { 
     container.Controls.Remove(control); 
     control.Dispose(); 
    } 

    controls = null; 
} 

GC.Collect(); 
GC.Collect(1); 
GC.Collect(2); 
GC.Collect(3); 

Как я могу узнать, какие ссылки у него есть? Почему он не собирается?

Answer 1

Попробуйте использовать профилировщик , (например, ants) он расскажет вам, что поддерживает объект. Попытка 2-го угадать, что этот тип проблемы очень тяжелый.

Red-gate дает 14-дневную пробную версию, которая должна быть более чем достаточно, чтобы решить эту проблему и решить, дает ли профилировщик памяти долгосрочную ценность.

Есть много других профайлеры памяти на рынке (например, .NET Memory Profiler), большинство из них имеют бесплатные пробные версии, однако я обнаружил, что Red-Gate инструментов просты в использовании, поэтому, как правило, пытаются их первыми.

Answer 2

Он не собран, потому что вы не удалили все ссылки на него. GC будет отмечать объекты только для коллекции, если у них нет корней в приложении.

Какие средства вы используете для проверки на GC, чтобы узнать, собрал ли он ваш объект?

Answer 3

Коллекция мусора в .NET не является схемой подсчета (например, COM), а реализована пометкой и разверткой. В принципе, GC работает в «случайные» времена, когда он чувствует необходимость сделать это, и поэтому сбор объектов не является детерминированным.

Вы можете, однако, вручную инициировать сборку (GC.Collect()), но вам, возможно, придется ждать завершения финализаторов (GC.WaitForPendingFinalizers()). Однако делать это в производственном приложении не рекомендуется, так как это может повлиять на эффективность управления памятью (GC работает слишком часто или ждет завершения финализаторов). Если объект все еще существует, на нем все еще есть какая-то живая ссылка.

Answer 4

Вам необходимо будет использовать Windbg и Sosex.

Команды !DumpHeap и !GCRoot могут помочь вам идентифицировать экземпляр и все остальные ссылки, которые поддерживают его.

Answer 5

Я использовал .NET Memory Profiler для выполнения некоторого серьезного профилирования памяти в одном из наших проектов. Это отличный инструмент для изучения управления памятью вашего приложения. Мне не платят за эту информацию :), но это просто помогло мне много.

Answer 6

Я решил аналогичную проблему с расширением SOS (который, видимо, больше не работает с Visual Studio 2013, но отлично работает со старыми версиями Visual Studio).

Я использовал следующий код, чтобы получить адрес объекта, для которого я хотел отслеживать ссылки:

public static string GetAddress(object o) 
{ 
    if (o == null) 
    { 
     return "00000000"; 
    } 
    else 
    { 
     unsafe 
     { 
      System.TypedReference tr = __makeref(o); 
      System.IntPtr ptr = **(System.IntPtr**) (&tr); 
      return ptr.ToString ("X"); 
     } 
    } 
} 

, а затем, в Visual Studio 2012 немедленным окна, во время работы в отладчик, введите:

.load C:\Windows\Microsoft.NET\Framework\v4.0.30319\sos.dll 

который будет загружать расширение SOS.dll.

Вы можете использовать GetAddress(x), чтобы получить шестнадцатеричный адрес объекта (например 8AB0CD40), а затем использовать:

!do 8AB0CD40 
!GCRoot -all 8AB0CD40 

сбросить объект и найти все ссылки на объект.

Просто имейте в виду, что если GC работает, это может изменить адрес объекта.