I've been investigating how to avoid memory leaks caused by strong references to the INotifyCollectionChanged
event from a view model. I was playing around with using a ListCollectionView
to see if that would deal with it for me. I think that the following is leaking memory, am I doing something wrong?
var stuff = new ObservableCollection<string>();
while (true)
{
var result = new ListCollectionView(stuff);
// Just to keep make sure that the memory I'm seeing
// isn't waiting to be GC'd
GC.Collect();
}
With each iteration
result
is being reassigned so that there won't be a reference to theListCollectionView
from the previous iteration. But callingGC.Collect
only schedules those items to have their memory reclaimed when the CLR decides to do the actual garbage collection. If you would like to see the memory getting reclaimed sooner, try addingGC.WaitForPendingFinalizers();
immediately after your call toGC.Collect();
.The documentation for
ListCollectionView
is not great but if you noticed there is a methodDetachFromSourceCollection
. The remarks for this call mention unsubscribing and allowing garbage collection.The CollectionView holds a reference to the source collection’s CollectionChanged event - hence GC can not collect the view until the source collection is disposed off and collected.
This is also clear from the documentation of CollectionView
This blog describes your issue and suggest two possible solutions:
http://www.eidias.com/blog/2014/2/24/wpf-collectionview-can-leak-memory ...
I initially posted this as a comment, but I think it makes a better answer, so ...
a) if you're sure you've found a problem with the .NET framework, you're probably doing something wrong. It's not impossible, it's just not likely. b) that GC.Collect() isn't going to do what you're thinking it will.
I think you need to review how GC.Collect() works.
MSDN GC.Collect Method
Remarks
Use this method to try to reclaim all memory that is inaccessible.
All objects, regardless of how long they have been in memory, are considered for collection; however, objects that are referenced in managed code are not collected. Use this method to force the system to try to reclaim the maximum amount of available memory.
For starters, you don't show us where you're disposing of that memory that the
ListCollectionView(stuff)
. You're just allocating new and allocating new, but you never dispose of the old. So yeah, it's going to leak like crazy. Until the GC runs and tries to collect.If you do the same thing you demonstrate here with a list of strings it will most likely do the same thing. But for what you've shown, I expect it to leak.
The best way to do this is to use Scopes / Anonymous functions. Lambada is grate for that
Using this method your throwing result out of scope as its method has been removed and this would use as little memory as possible.
Taken from: https://msdn.microsoft.com/en-gb/library/bb882516.aspx?f=255&MSPPError=-2147217396
when you call GC.Collect, you variable result is still in scope so it won't be collected since there is one pointer to the data. anyway even if it wasn't the case. what garbage collection does is non deterministic as far as application code is concerned. like drachenstern said it will only try! and it will succeed eventually but you can't be sure when!