但总不能放弃，对比之前做的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的回收，那么实际的情况我们看下

优化前：

内存状况：