绑定到列表导致内存泄漏

Question

When I bind an ItemsSource of a ListBox to a List the binding engine holds on to the list elements after the control is gone. This causes all the list elements to stay in memory. The problem goes away when using an ObservalbleCollection. Why does this happen?

The xaml inside the window tag

<Grid>
    <StackPanel>
        <ContentControl Name="ContentControl">
            <ListBox ItemsSource="{Binding List, Mode=TwoWay}" DisplayMemberPath="Name"/>
        </ContentControl>
        <Button Click="Button_Click">GC</Button>
    </StackPanel>
</Grid>

Code behind:

public MainWindow()
    {
        InitializeComponent();
        DataContext = new ViewModel();
    }

private void Button_Click(object sender, RoutedEventArgs e)
    {
        this.DataContext = null;
        ContentControl.Content = null;
        GC.Collect();
        GC.WaitForPendingFinalizers();
    }

ViewModel

class ViewModel : INotifyPropertyChanged
{
    //Implementation of INotifyPropertyChanged ...

    //Introducing ObservableCollection as type resolves the problem
    private IEnumerable<Person> _list = 
            new List<Person> { new Person { Name = "one" }, new Person { Name = "two" } };

    public IEnumerable<Person> List
    {
        get { return _list; }
        set
        {
            _list = value;
            RaisePropertyChanged("List");
        }
    }

class Person
{
    public string Name { get; set; }
}

Edit: To check the leaking of the person istances, I used ANTS and .Net memory profiler. Both show that after pushing the GC-button only the binding engine is holding reference to the person objects.

Answer 1

Ahhh got you. Now I understand what you mean.

You set the Content to null and so you kill the compelte ListBox but still the ItemsSource binds to List and so ListBox memory is not completely released.

That is unfortunately a well known issue and also well documented on MSDN.

If you are not binding to a DependencyProperty or a object that implements INotifyPropertyChanged or ObservableCollection then the binding can leak memory, and you will have to unbind when you are done.

This is because if the object is not a DependencyProperty or does not implement INotifyPropertyChanged or not implementing INotifyCollectionChanged (Normal list is not implementing this) then it uses the ValueChanged event via the PropertyDescriptors AddValueChanged method. This causes the CLR to create a strong reference from the PropertyDescriptor to the object and in most cases the CLR will keep a reference to the PropertyDescriptor in a global table.

Because the binding must continue to listen for changes. This behavior keeps the reference alive between the PropertyDescriptor and the object as the target remains in use. This can cause a memory leak in the object and any object to which the object refers.

The question is...is Person implementing INotifyPropertyChanged?

Answer 2

I had a look at your example with JustTrace memory profiler and apart from an obvious question why would you kill view model / nullify DataContext and leave view running (in 99.9% of cases you'd kill View and DataContext - hence ViewModel and Bindings go of of scope automatically) here's what I found.

It will work fine if you modify your example to:

• replace DataContext with new instance of view model, as expected, existing instances of Person go out of scope as MS.Internal.Data.DataBingingEngine flushes all bindings, even they were strong refs not managed by WeakPropertyChangedEventManager , or:
• ViewModel to replace List with new instance of IEnumerable ie new Person[0]/simply null and raise INCP.PropertyChanged("List") on the ViewModel

Above modifications prove you can safely use IEnumerable/IEnumerable in binding. BTW, Person class doesn't need to implement INPC neither - TypeDescriptor binding/Mode=OneTime don't make any difference in this case, I verified that too. BTW, bindings to IEnumerable/IEnumerable/IList are wrapped into EnumerableCollectionView internal class. Unfortunatelly, I didn;t have a chance to go through MS.Internal/System.ComponentModel code to find out why ObservableCollection works when setting DataContext = null, probably because Microsoft guys did a special handing when unsubscribing from CollectionChanged. Feel free to waste few precious lifetime hours on going through MS.Internal/ComponentModel :) Hope It helps

Answer 3

That's an old post, I see. But the explanations provided especially by the accepted answer is not very accurate and its implications are wrong.

Abstract

Beforehand, this is not a real memory leak. The special binding engine's lifetime management for collections that do not implement INotifyCollectionChanged and their associated CollectionView takes care of the allocated memory.
WPF supports binding to many different types like DataTable and XML or in general to types that implement IList , IEnumerable or IListSource . If this was a serious bug, then all those bindings would be dangerous.
Microsoft would propagate warnings in their docs against eg, binding to DataTable as they do in case of potential memory leaks in context with events or data binding.

It is indeed true that this special behavior can be avoided when binding to a collection of type INotifyCollectionChanged - or by avoiding using CollectionView at all!
This behavior is actually induced by the actual CollectionView management of the binding engine.
The following code triggers the same behavior as would do binding to a List\\<T> :

var list = new List<int> {1, 2, 3};
ICollectionView listView = CollectionViewSource.GetDefaultView(list);
list = null;
listView = null;
for (int i = 0; i < 4; i++)
{
  GC.Collect(2, GCCollectionMode.Forced, true);
  GC.WaitForPendingFinalizers();
}

Result: the entire collection reference tree and the CollectionView are still in memory (see explanation below).
This should be proof that the behavior is not introduced by data binding, but the binding engine's CollectionView management.

---

Memory Leaks in Context of Data binding

The memory leak issue regarding data binding is not related to the type of the property, but to the notification system that the binding source implements.
The source must a) participate in the dependency property system (by extending DependencyObject and by implementing properties as DependencyProperty ) b) or implement INotifyPropertyChanged

Otherwise the binding engine will create a static reference to the source. A static reference are root references. Due to their nature to be reachable during the lifetime of the application, such root references, like static fields and every object (memory) they reference, will never be elegible for garbage collection and thus create the memory leak.

Collections and CollectionView Management

Collections are a different story. The cause of the alledged leak is not the data binding itself. It's the binding engine that is also responsible for creating the CollectionView of the actual collections.
Whether the the CollectionView is created in context of a binding or when calling CollectionViewSource.GetDefaultView : it's the binding engine that creates and manages the views.

Those views are managed by the ViewManager , which is part of the binding engine. To improve performance, the view manager caches views: it stores them in a ViewTable using WeakReference to allow them to be garbage collected.

The CollectionView itself is target of a strong reference from the underlying source collection if this collection implements INotifyCollectionChanged .
This strong reference is created by the CollectionView the momement it observes the INotifyCollectionChanged.CollectionChanged event (by attaching a callback that the collection stores in order to invoke it when raising the event).

This way, the lifetime of the CollectionView is coupled to the lifetime of the collection: even if the application has no references to a CollectionView , because of this strong references the lifetime of the CollectionView is extended until the collection itself is elegible for garbage collection.
Since the CollectionView instances are stored as WeakReference , this lifetime coupling prevents the WeakReference from getting garbage collected prematurely.
This strong coupling prevents the CollectionView from being garbage collected before the collection.

Additionally, the manager must also guarantee that as long the CollectionView is referenced by the application, the underlying collection exists. This is achieved by keeping a strong reference from CollectionView to the source collection. This is the crititical reference that results in the perceived memory leak.

Now, when the collection does not implement INotifyCollectionChanged , then the required strong reference from collection to CollectionView does not exist and the WeakReference to the CollectionView could be garbage collected prematurely. To fix this, the view manager must keep the CollectionView alive "artificially" to prevent the WeakReference .

It does this by storing a strong reference to the CollectionView . At this moment the view manager has stored a strong reference to the CollectionView (due to the lack of INotifyCollectionChanged ) and this CollectionView has a strong reference to the underlying collection. This is the cause for the perceived memory leak.

But this is not a real leak as the view manager controls the lifetime of the strong reference to the CollectionView by registering the strong reference with an expiration date.

The view manager will now occasionally purge those references when their expiration date is expired and the underlying collection was garbage collected. This behavior is introduced to allow the strong reference while avoiding the leak.

Conclusion

Due to the special lifetime management (using expiration dates) for a CollectionView of a collection that does not implement INotifyCollectionChanged , the CollectionView is kept alive (in memory) much longer. And because the CollectionView in general has a strong reference to its source collection (in this case the one without INotifyCollectionChanged ), this collection and its items and all rechable references are also kept alive much longer.

If the collection had implemented INotifyCollectionChanged , then the view manager would not had stored the strong reference to the CollectionView and therefore the CollectionView would have been garbage collected the moment the source collection became unreachable.

The important point is, the lifetime of the strong reference to the CollectionView is managed by the ViewManager ie binding engine. Due to the expiration date and the occasional purge, this lifetime is significantly extended.
Therefore, the observation of the persisting allocated memory after all references to the collection have been destroyed is perceiving. It is not a real memory leak.