MEF引起的内存泄露

也许你编程的时候很小心，注意不引起内存泄露，例如不要被全局Static的变量引用上，注意Singleton的static引用，注意Event Handler注销，注意IDisposable接口实现，而且正确实现了IDisposable。但或许你还是有内存泄露，为何？因为你的IDisposable接口根本没有被触发！为什么？参考MSDN这个页面的”Dispose method not invoked ”章节。还有其它的内存泄露原因，比如第三方组件或框架，框架本身的内存泄露问题，已经框架本身有LifetimeManagement对象生命周期管理机制。例如我今天要说的MEF引起的内存泄露。

实现IDisposable接口，却导致没有触发，这是何故？

看看MEF的对象生命周期管理机制说明，里面有这么一段话：

Container and parts references

We believe that .Net Garbage Collector is the best thing to rely on for proper clean up. However, we also need to provider a container that has a deterministic behavior. Thus, the container will not hold references to parts it creates unless one of the following is true:

1. The part is marked as Shared
2. The part implements IDisposable
3. One or more imports is configured to allow recomposition

For those cases, a part reference is kept. Combined with the fact that you can have non shared parts and keep requesting those from the container then memory demand can quickly become an issue. In order to mitigate this issue you should rely on one of the following strategies discussed in the next two topics.

原来在MEF中，对象构造策略为Shared，实现IDisposable接口的，和允许recomposition的，都会被全局container引用，也就是说不释放。具体可以去看MEF的源码。

内存泄露分析过程

内存分析工具很多，例如Windbg, Redgate ANTS MemoryProfiler, 以及.NET Memory Profiler。我是用的Redgate的，大家可以从下面的图中看到为何这个ViewModel被引用着。根据这个图，去看MEF的源码，就ok了。

MEF Parts Lifetime (zz from: http://mef.codeplex.com/wikipage?title=Parts%20Lifetime)

It’s very important that one understand a parts lifetime within a MEF container and its implications. Given that MEF focuses on open ended applications this becomes especially important as the application authors won’t have control over the set of parts once the app ships and third party extensions come to play. Lifetime can be explained as being the desired “shareability” of a part (transitively, its exports) which translates to the policy that controls when a new part is created as well as when the part will be shut down or disposed.

Shared, Non Shared and ownership

The “shareability” of a part is defined through the CreationPolicy set (class level) using the PartCreationPolicyAttribute. The following values are supported:

• Shared: the part author is telling MEF that at most one instance of the part may exist per container.
• NonShared: the part author is telling MEF that each request for exports of the part will be served by a new instance of it.
• Any or not supplied value: the part author allows the part to be used as either “Shared” or “NonShared”.

The Creation Policy can be defined on a part using the[System.ComponentModel.Composition.PartCreationPolicyAttribute]:

The container will always have the ownership of parts it creates. In other words, the ownership is never transferred to an actor that requested it by using the container instance (directly) or through an import (indirectly). 
Imports can also define or constraint the creation policy of parts used to supply the import values. All you have to do is specify the CreationPolicy enum value for RequiredCreationPolicy:

This is a useful for scenarios where the “shareability” of a part is relevant for the importer. By default, the RequiredCreationPolicy is set to Any, so Shared and NonShared parts can supply the values..

Disposing the container

A container instance is generally the lifetime holder of parts. Part instances created by the container have their lifetime conditioned to the container’s lifetime. The way to signal the end of the container lifetime is by disposing it. The implications of disposing a container are:

• Parts that implement IDisposable will have the Dispose method called
• Reference to parts held on the container will be cleaned up
• Shared parts will be disposed and cleaned up
• Lazy exports won’t work after the container is disposed
• Operations might throw System.ObjectDisposedException

Container and parts references

We believe that .Net Garbage Collector is the best thing to rely on for proper clean up. However, we also need to provider a container that has a deterministic behavior. Thus, the container will not hold references to parts it creates unless one of the following is true:

• The part is marked as Shared
• The part implements IDisposable
• One or more imports is configured to allow recomposition

For those cases, a part reference is kept. Combined with the fact that you can have non shared parts and keep requesting those from the container then memory demand can quickly become an issue. In order to mitigate this issue you should rely on one of the following strategies discussed in the next two topics.

Scoped operations and early reclaim of resources

Some common kinds of applications like web apps and windows services vary greatly from desktop applications. They are more likely to rely on batched and short lived operations. For example, a windows service might watch a directly and once a pre-determined number of file is present, start a batching operation that transforms those files into another format. Web operations may be scoped by per-web-request operations. 
For those scenarios you should either use child containers (explained in the next topic) or release early the object graph. The latter allows the container to dispose and clear out references to non shared parts in the object graph – until it reaches a shared part. 
In order to early release the object graph you need to call the method ReleaseExport exposed by the CompositionContainer:

The figure below depicts an object graph and show what parts would be released (references removed, disposed) and the ones that would be left untouched: 
 
As the root part is just non shared no reference was being kept by the container, so it is basically a no-operation. We proceed traversing the graph checking the exports served to the root part. Dep 1 is both non shared and disposable, so the part is disposed and its reference is removed from the container. The same happens with Dep 2, however, the export used by Dep is left untouched as it is shared – so other parts may be using it. 
Note that the implementation traverses the graph in a depth-first way.

Container hierarchies

Another way to approach the same problem is to use container hierarchies. You can create containers and connect them to a parent container, making them child containers. Note that unless you provide a different catalog to the child container, it wouldn’t be of much help as instantiation will continue to happen on the parent. 
Hence, what you should do is either filter the parent catalog based on a criterion that divides the set of parts that should be created on the parent container from those that should be created on the child, or you should specify a completely new catalog that expose a set of parts that should be created on the child container. As the child is expected to be short lived, parts created in it will be released and disposed earlier. 
A common approach is to have Shared parts created on the parent container and Non Shared on the child container. As Shared parts may depend on exports supplied by Non Shared, then the main catalog will have to contain the whole set of parts whereas the child container should have a filtered view of the main catalog with only the non shared parts. 
 
For more information on this topic please check Filtering Catalogs

Disposal ordering

Disposal ordering is not guaranteed in any way. That means that you should not try to use an import in your Dispose method. For example:

Using the imported logger instance on your dispose method implementation may be a problem as the implementation of the ILogger contract may also be disposable, and as such may have been disposed already. 

AddPart/RemovePart

Not every part is created by the container. You can also add and remove parts from it. This process triggers composition and may start creating parts to satisfy dependencies of the part added recursively. When the part added is removed MEF is smart enough to reclaim the resources and dispose the non shared parts used by the part added. 
Note: that MEF will never take ownership of an instance supplied by you, but it does have the ownership of part it creates to satisfy your instance’s imports.

深入思考和继续阅读

通常.NET程序的内存泄露原因：

• Static references
• Event with missing unsubscription
• Static event with missing unsubscription
• Dispose method not invoked
• Incomplete Dispose method

有关如何避免.NET程序的内存泄露，请仔细阅读MSDN这两篇文章，详细讲述了<如何检测.NET程序内存泄露>以及<如何写高性能的托管程序>

• How to detect and avoid memory and resources leaks in .NET applications
• Writing High-Performance Managed Applications : A Primer

有关.NET的自动内存管理机制、GC机制，垃圾回收原理等深层次内容，请仔细阅读下面的内容：

• 买书《CLR Via C#(3rd Edition)》，里面有《Memory Management》这一章专门讲述了.NET CLR的自动内存管理和垃圾回收机制
• CodeProject上的文章《Memory Management Misconceptions》有助你深入理解Root, Generation 0, 1…

http://www.cnblogs.com/Mainz/archive/2011/09/10/2173172.html