(最近使用内存分析工具ANTS Memory Profiler，以及其他网友提供的意见发现最终导致内存泄漏的就是MEF，在此特地更新下，与大家分享！最下面红色字体)
最近参考使用了郭明峰的一套架构来做新的项目架构，这套架构看起来还是不错的，先向小郭同学的分享精神致敬！
（郭同学的项目文档：http://www.cnblogs.com/guomingfeng/archive/2013/05/19/mvc-overall-design.html）
项目开发上线后，傻眼了，貌似没有几个人访问的新项目，速度一直慢的跟牛一样，真心没法交差啊。上面发下话了，解决不了就可以走人了。压力可想而知。
接下来就是苦逼的找原因了。
症状：1、内存占用高，8g的内存很快就能吃完
2、网站相应速度慢，firebug检测每次都是在等待
根据这些症状，感觉是内存泄露了，于是memory profiler。。。什么性能分析工具都用上了，怎奈水平有限，不会使用这些高级玩意，一番折腾下来，就剩下无奈。
但总不能放弃，对比之前做的mvc项目，就是多了entityframework、MEF这两样，看样子也就这两块的原因了，EF的嫌疑最大，而且首次使用，并不了解。于是，接下来又是一段苦逼的研究；功夫不负有心人，根据目前研究的结果及上线的效果来看，基本上找到了问题的所在。总结下，与诸位分享，高手忽略。
问题原因：1、很多数据查询一次性读入到内存中，导致内存增加。
2、上下文对读入到内存中的数据对象会进行跟踪，导致内存不断攀升，疑似内存泄露
解决办法：1、深入学习EF，监控每一步生成的sql语句，防止无用数据的调取
2、网站大部分的数据在读取的时候是不需要进行上下文跟踪的，一定要禁止跟踪，否则内存就会爆了！代码如下：
/// <summary>
/// 获取当前实体的查询数据集(通过读上下文进行读取，只读专用，返回的实体数据不会被上下文跟踪)
/// </summary>
public virtual IQueryable<TEntity> ReadEntities
{
get { return WriteContext.Set<TEntity>().AsNoTracking(); }
} /// <summary>
/// 获取当前实体的查询数据集(通过写上下文进行读取，修改专用，返回的实体数据会被上下文进行跟踪)
/// </summary>
public virtual IQueryable<TEntity> WriteEntities
{
get { return WriteContext.Set<TEntity>(); }
}
说明：我在仓储模式中，对读取实体集合进行了修改，ReadEntities表示不需要进行跟踪的，加上AsNoTracking方法；WriteEntities表示是需要跟踪的，用于修改实体信息使用。这样以来，所有的症状全部消失了。
当然，也许有更好的优化方法，至少目前本人发现了这些问题所在，而且微软的白皮书中确实也讲的了EF的性能注意事项，怎奈仓促开发，对EF毫不了解，罪过罪过！大家引以为鉴！
另外，还遇到一个问题，不知道是否是DBcontext线程冲突问题，大家帮分析下，谢谢：
持续的内存泄漏问题终于有了结果了，花了近一周的时间，无数苦逼的熬夜，终于掌握了ANTS Memory Profiler的基本用法，结合之前网友的宝贵意见，经检测，终于发现导致内存泄漏的罪魁祸首：MEF。
小郭的架构中有这么一段代码：
public CompositionContainer Container
{
get
{
CompositionContainer container;
if (!HttpContext.Current.Items.Contains(MefContainerKey))
{
container = new CompositionContainer(_catalog, CompositionOptions.DisableSilentRejection);
HttpContext.Current.Items.Add(MefContainerKey, container);
HttpContext.Current.DisposeOnPipelineCompleted(container);
}
else
{
container = (CompositionContainer)HttpContext.Current.Items[MefContainerKey];
}
return container;
}
}
这段代码用于创建MEF容器，并向其中加入对象实例化的目录。
小郭童鞋说了，项目中的所有Import的对象都是MEF创建的，不需要刻意的去Dispose，只要MEF对象释放了，那么container中的所有实例化对象就会被释放。
话没错，但代码中确实没有看到有释放container对象的地方，我翻遍了评论，看到有个哥们ltcszk提醒说要加入HttpContext.Current.DisposeOnPipelineCompleted(container)这句话就ok，当时并未重视，固执的认为是过多的DBContext导致的，这两天经过ANTS Memory Profiler测试下，果真是这个问题导致的，加上这句话，效果立竿见影，在此感谢ltcszk的提醒。同时总结下，与诸位分享！
在页面打开后，理论上这次请求就完毕，所有线程中创建的对象就应该被GC释放掉，Profiler在每次快照的时候就会执行GC的回收，那么实际的情况我们看下
优化前：
内存状况：
第一步
第二步
第三步
优化后：
驻留在内存中的类型明显少了很多，只有35个，大部分是cache内容！
在此记录，与诸位分享，欢迎拍砖！