Silverlight Memory leakage (6) Memory leakage caused by Ioc frameworks such as MEF-ExportLifetimeContext

You can use new or IOC racks such as castle and MEF to create an object. IOC may be responsible for managing the lifecycle of the object created by IOC, developers who use the framework cannot figure out the cause of Memory leakage.

These memory leaks are not a bug in the IOC framework, but memory leaks caused by improper use or inattention by developers.

Taking MEF as an example to illustrate the two memory leaks I have encountered.

Read tips for Memory leakage series:

When we touch the same object graph, sometimes we can think of it as Memory leakage, and sometimes think it is not a memory leak, all of which is due to different contexts, in this series of articles, ANTS Memoery Profle has a specific context, and it makes no sense to read it separately. How can I determine whether the memory is leaked? Refer to the previous article.

An object exists in the form of an image. Ants Memory Profile allows us to focus on the analysis objects by processing these graphs as trees for convenience. However, we must understand the relationship between objects in the memory. That is to say, the ANTS tree chart is only a part of the object distribution in the memory. When analyzing memory leaks, we must have a global concept, we need to look at several related graphs together, even if one graph needs to be viewed as a whole, so that we can analyze the memory leakage problem.

Because it makes no sense to see a picture, if you paste multiple images, this article is too difficult to write. Even if multiple images are posted, it cannot be clearly expressed, the most important thing to Analyze memory leaks is experience. The following sections will reduce or even remove the ANTS diagram.

Memory leakage caused by improper use of ExportLifetimeContext

ExportLifetimeContext needs to call the Dispose method to release objects managed by MEF, otherwise the objects will not be released.

MSDN:

Disposing of a ExportLifetimeContext (Of T) object callthe referenced method to release its associated export.

Call Dispose when you are finished using the ExportLifetimeContext (Of T ). the Dispose method leaves the ExportLifetimeContext (Of T) in an unusable state. after calling Dispose, you must release all references to the ExportLifetimeContext (Of T) so the garbage collector can reclaim the memory that theExportLifetimeContext (Of T) was occupying.

We can see that ViewModel has multiple instances, and memory leakage may occur.

After analysis, find out the object diagram of Memory leakage:

We can see that the DisposableReflectionComposablePart of MEF keeps the reference of ViewModel, so ViewModel cannot be released.

MVVM uses custom navigation, code:

[Export]
Public class CompositionNavigationContentLoader: INavigationContentLoader
{
Public CompositionNavigationContentLoader ()
{
}
[ImportMany (typeof (IView)]
Public IEnumerable <ExportFactory <IView, IViewMetadata> ViewExports {get; set ;}
[Importcredential (typeof (IViewModel), RequiredCreationPolicy = CreationPolicy. Any)]
Public List <ExportFactory <IViewModel, IViewModelMetadata> ViewModelExports {get; set ;}
[Importparameters ("lazy", typeof (IViewModel), RequiredCreationPolicy = CreationPolicy. Any)]
Public List <Lazy <IViewModel, IViewModelMetadata> LazyViewModelExports {get; set ;}
Public IAsyncResult BeginLoad (Uri targetUri, Uri currentUri, AsyncCallback userCallback, object asyncState)
{
Var viewModelMapping = ViewModelExports. FirstOrDefault (o => o. Metadata. Key. Equals (relativeUri. Host, StringComparison. OrdinalIgnoreCase ));
// ViewModel
Var viewModelFactory = viewModelMapping. CreateExport ();
ViewModel = viewModelFactory. Value as IViewModel;
ViewModelFactory. Dispose (); // release an object
// View
Var viewFactory = viewMapping. CreateExport ();
View = viewFactory. Value as Control;
ViewFactory. Dispose (); // release an object
// Bind and navigate
View. DataContext = viewModel;
Var values = viewModelMapping. Metadata. GetArgumentValues (targetUri );
ViewModel. OnNavigated (values );
}

}

 

If viewModelFactory. Dispose () is not added ();

The objects created by the object MEF will not be recycled, and the VIew, ViewModel, and referenced resources will be kept until the program is closed.

Conclusion

A) do not blindly use third-party frameworks.

B) memory leaks all have contexts. Memory problems may occur only when code is hosted in a specific context.

C) Pay attention to the object lifecycle created by IOC. If the object created by IOC is managed by the container, you may need to call the methods provided by IOC to destroy the object.