Instancias anotadas para GC - No detectable desde mi código administrado

Question

Así que estoy usando WPF 3.5 con el método MVVM + DataTemplate para cargar 2 vistas en la GUI. ¡He observado mientras que el perfil de la memoria que los elementos generados como parte del contenedor de artículos de los controles de artículos se anclan en la memoria y no se acumulan GC incluso después de que se descargue la vista!

Acabo de ejecutar pruebas y descubrí que es reproducible incluso para el código más simple ... Ustedes pueden comprobarlo por sí mismos.

XAML:

<Window x:Class="ContentControlVMTest.Window2" 
     xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" 
     xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" 
     xmlns:local="clr-namespace:ContentControlVMTest" 
     Title="Window2" Height="300" Width="300"> 
    <DockPanel LastChildFill="True"> 

     <CheckBox Click="CheckBox_Click" Content="Test1?" 
        DockPanel.Dock="Top" Margin="5"/> 

     <ContentControl x:Name="contentControl"> 
      <ContentControl.Resources> 

       <DataTemplate DataType="{x:Type local:Test3}"> 
        <TextBlock Text="{Binding C}" Margin="5"/> 
       </DataTemplate> 

       <DataTemplate DataType="{x:Type local:Test1}"> 
        <DockPanel LastChildFill="True" Margin="5"> 
         <TextBlock Text="{Binding A}" 
            DockPanel.Dock="Top" 
            Margin="5"/> 
         <ListBox ItemsSource="{Binding Bs}" 
           DisplayMemberPath="B" 
           Margin="5"/> 
        </DockPanel> 
       </DataTemplate> 
      </ContentControl.Resources> 
     </ContentControl> 
    </DockPanel> 
</Window> 

código subyacente:

public class Test3 
{ 
    public string C { get; set; } 
} 

public class Test2 
{ 
    public string B { get; set; } 
} 

public class Test1 
{ 
    public string A { get; set; } 

    private List<Test2> _Bs; 
    public List<Test2> Bs 
    { 
     get 
     { 
      return _Bs; 
     } 

     set 
     { 
      _Bs = value; 
     } 
    } 
} 

public partial class Window2 : Window 
{ 
    public Window2() 
    { 
     InitializeComponent(); 
     this.KeyDown += Window_KeyDown; 
    } 

    private void Window_KeyDown 
      (object sender, System.Windows.Input.KeyEventArgs e) 
    { 
     if (Keyboard.IsKeyDown(Key.LeftCtrl)) 
      if (Keyboard.IsKeyDown(Key.LeftShift)) 
       if (Keyboard.IsKeyDown(Key.LeftAlt)) 
        if (Keyboard.IsKeyDown(Key.G)) 
        { 
         GC.Collect(2, GCCollectionMode.Forced); 
         GC.WaitForPendingFinalizers(); 
         GC.Collect(2, GCCollectionMode.Forced); 
         GC.WaitForPendingFinalizers(); 
         GC.Collect(3, GCCollectionMode.Forced); 
         GC.WaitForPendingFinalizers(); 
         GC.Collect(3, GCCollectionMode.Forced); 
        } 
    } 

    private void CheckBox_Click(object sender, RoutedEventArgs e) 
    { 
     if (((CheckBox)sender).IsChecked.GetValueOrDefault(false)) 
     { 
      var x = new Test1() { A = "Test1 A" }; 
      x.Bs = new List<Test2>(); 
      for (int i = 1; i < 10000; i++) 
      { 
       x.Bs.Add(new Test2() { B = "Test1 B " + i }); 
      } 
      contentControl.Content = x; 
     } 
     else 
     { 
      contentControl.Content = new Test3() { C = "Test3 C" }; 
     } 
    } 
} 

llevo a cabo GC obligado por desplazamiento a la izquierda + Alt + Ctrl + G. Todos los artículos para la vista Test1 o Test3 y Ver modelo se muere después de que se descargan correctamente. Entonces eso es lo esperado.

Pero la colección generada en el modelo Test1 (que tiene objetos Test2), permanece anclada en la memoria. ¡Y indica que la matriz es la utilizada por el contenedor de elementos del listbox porque muestra la cantidad de elementos desvirtualizados del listbox! ¡Esta matriz anclada cambia su tamaño cuando minimizamos o restauramos la vista en el modo de vista Test1! Una vez fueron 16 ítems y la próxima vez fue 69 ítems cuando se perfilaron.

Esto significa WPF realiza la fijación de elementos generados en artículos controles! ¿Alguien puede explicar esto? ¿Esto tiene algún inconveniente significativo?

Thx mucho.

Answer 1

El problema se debe a que el mecanismo de encuadernación no ha liberado completamente los elementos de la lista que se han visto obligados a mostrarse en la pantalla. Es casi seguro que ese último bit sea el motivo por el que está viendo diferentes números de instancias "huérfanas" en diferentes ejecuciones. Cuanto más se desplaza por la lista, más problemas genera.

Esto parece estar relacionado con el mismo tipo de problema subyacente que se describe en a bug report that I submitted over a year ago, ya que la raíz fija y los árboles de instancia anclados son similares. (Para ver ese tipo de detalles en un formato conveniente, es posible que desee obtener una copia de un perfilador de memoria un poco más elegante como ANTS Memory Profiler.)

La mala noticia es que sus instancias huérfanas están siendo fijadas más allá de la desaparición de la la ventana misma, por lo que probablemente no pueda limpiarlos sin el mismo tipo de truco que tuve que usar en el escenario de WinForms para forzar la limpieza de las partes privadas de unión.

La única buena noticia en todo esto es que el problema no ocurre si puede evitar el enlace a propiedades anidadas. Por ejemplo, si agrega una anulación de ToString() a Test2 para devolver el valor de su propiedad B y elimina DisplayMemberPath de su elemento de cuadro de lista, el problema desaparecerá. ej .:

public class Test2 
{ 
    public string B { get; set; } 

    public override string ToString() 
    { 
     return this.B; 
    } 
} 

---

<ListBox ItemsSource="{Binding Bs}" 
    Margin="5"/> 

Answer 2

En el código de ejemplo anterior, ¿no veo dónde está descargando alguno de los elementos visuales?

Pero suponiendo que está descargando toda la vista, esto todavía es predecible. El factor que no está teniendo en cuenta es el despachador. El despachador es una cola de eventos priorizados y para cada delegado en esa cola mantiene una referencia a los objetos apuntados por esos delegados. Lo que significa que es muy posible que algo en su vista esté en la cola después de un evento descargado y, por lo tanto, tenga una referencia legítima en el GC. Puede GC. Recoger hasta que esté azul en la cara y nunca recogerá objetos con las referencias restantes.

Entonces lo que tienes que hacer es bombear el despachador y luego llamar a GC.Collect. Algo como esto:

void Control_Unloaded(object sender, RoutedEventArgs e) 
{ 
    // flush dispatcher 
    this.Dispatcher.BeginInvoke(new Action(DoMemoryAnalysis), DispatcherPriority.ContextIdle); 
} 

private static void DoMemoryAnalysis() 
{ 
    GC.Collect(); 
    GC.WaitForPendingFinalizers(); 

    // do memory analysis now. 
} 

Otra causa muy común de pérdidas de memoria en .NET tiene que ver con la fijación de los acontecimientos y no unattaching correctamente. No veo que hagas esto en tu muestra anterior, pero si adjuntas eventos, asegúrate de que los estás desatando en Descargado o Disposición o donde sea más apropiado.