减少.NET应用程序内存占用的一则实践_.Net教程

推荐：进程性能计数器已禁用的解决办法
未处理的异常：进程性能计数器已禁用 调试出错: 未处理的异常： System.InvalidOperationException: 进程性能计数器已禁用，因此无法执行所请求的操作 问题解决: 方法一： 这时只要修复一下windows的性能计数器即可。 具体方法：在运行中输入：lodctr /r 然后回车，运

　　最近一周比较忙，主要的工作内容是在做一个叫“键盘精灵”的东西，简单来讲就是将很多数据放到内存中，对这些数据进行快速检索，然后找出根据输入条件最匹配的10条记录并予以展示。具体和下面两款炒股软件的相关功能类似：

　　数据以文本形式存在文件中，且数据量较大，有近20万条，每一条记录有几个字段，以分隔符分割。当时使用的是6万条记录的测试数据，文本文件将近 10M，这个模块加载到内存并建立缓存之后，大概会占用将近70-80M的内存。自我接手以后，主要的任务就是降低内存消耗和提高匹配效率。

　　一、避免创建不必要的对象

　　拿到代码后，第一步就是看设计文档，然后断点一步一步的看代码，大概明白了逻辑之后，发现思路有一些问题。之前的代码处理流程思路大概是下面这样的：

　　1.将文件读取到内存，实例化

　　2.根据条件对文件进行检索，并存储到结果集1中

　　3.对结果集1中的结果进行匹配度计算，并存储到结果集中2

　　4.按对结果集2进行匹配度排序，取最匹配的10条记录，然后返回

　　这个过程中规中矩。但是其中有很多问题，最大的问题是，临时变量存储了太多的中间处理结果，而这些对象在一次查询完成后又马上丢弃，大量的临时对象带来了很大的GC压力。举例来说，当用户在输入框中输入1的时候，假设使用Contains来匹配，那么从6万条记录中找出包含1的记录可能有4万多条，然后需要把这4万多条记录存储在临时变量中进行处理，进一步计算这4万条记录的匹配度，然后存储到一个类似KeyValuePair的集合中，key为匹配度，然后对这个集合按Key进行排序，然后取前10条最优记录。可以看到，中间创建了大量的临时变量，使得内存剧增，大量临时对象创建之后马上会被回收，GC压力山大。

　　而在设计文档中，只要求返回最最匹配的10条记录，之前的解决方案中似乎并没有注意到这一点。所以接手后，第一步就是对上面的处理过程进行精简。精简后如下：

　　将文件读取到内存，实例化

　　根据条件对文件进行检索，如果存在，则：

　　计算匹配度。

　　以匹配度为Key，存储到只有11个容量的SortList中。

　　如果SortList集合添加记录后大于10个，则移除最后面一个元素，始终保持着前10个最小(匹配度最优)的记录。

　　遍历完成之后，返回这个集合对象

　　经过这一修改，减少了大量临时数据对内存的占用，整个过程中，我只是使用一个容量为11的SortList结构存储中间的过程，每一次插入一个元素，SortList帮我们排好序，然后移除最不匹配的那一个，也就是最后一个元素(从小到大排序，越匹配，值越小)。这里面的消耗主要是 SortList的插入，内部排序和移除记录。 说到这里在选择SortList还是SortDictionary的问题上纠结了一下，于是又找了些资料，SortDictionary在内部使用红黑树实现，SortList采用有序数组实现， 在内部排序都为O(logn)的前提下，SortDictionary的O(logn)插入及删除元素的时间复杂度优于SortList，但是 SortDictionary会比SortList占用更多内存。基本来说这是一个查询速度和内存分配之间的平衡，由于这里只需要存储11个对象，所以两者相差不大。其实即使没有这种结构，自己也可以实现的，无非就是一个集合，每次添加一个，排好序，然后将最大的那个移除。.NET使用起来方便是因为有很多这些强大的内置数据结构。

　　经过上面这个小小的修改，内存占用一下子降低了1倍，从原来的70-80M，降低到了30-40M，其实这就是降低内存开销的一个最基本的原则，那就是避免创建不必要的对象。

　　二、优化数据类型及算法

　　越到后面内存的降低越来越困难。仔细看了代码之后，除了上面之外，代码中也有一些其他问题，比如，一开始就将大量的对象实例化到内存中，然后一直保存。每一条记录中的信息比较多，但真正有用的用于搜索匹配的只有下面四个字段，但是整体的实例化会将其他没有用的字段也一并序列化进去了。导致很多内存被无用的字段占用。

　　“股票代码 股票中文名 中文拼音 市场类型 ……

　　600000 浦发银行 PFYH 上证A股 ……”

　　所以第一步就是在内存中只存放需要检索的上面四个关键字段，每一条记录刚开始是使用string[]数据，而不是使用类或者其它结构来保存，也尝试使用结构提来保存，但是由于四个字段，数据量大，中间还要作为参数传递，所以比使用类还大，这里只是简单的使用了数组。

　　除了上面这些之外，为了提高搜索效率，对数据按照0-9，a-z开头对数据做了切分分块缓存，这样当用户输入0时，直接从以0为key的块中读取数据，这样速度是加快了，但是大量的缓存也增加了对内存的消耗。缓存的数据基本上和加载到内存中原始的数据一样大了。并且在搜索的过程中，也是采用的完全搜索，对于17万条数据的四个字段，每一次查询要进行170000*4次遍历比较，才能找出最匹配的10条数据来。

　　为此，引入了不完全搜索，就是事先对各类型证券，如 股票，基金，债券分类，对每一类按证券代码进行排序。当用户设置了搜索的优先级时，依次在每一类中查找，如果找到满足条件的10条记录，则立即返回，因为数据已经事先按照证券类型和代码排好序了，所以后面找到的肯定没有之前找到的匹配度高，这一改进直接提高了搜索查询的效率。对有序的数据进行查找效率一般会比无序的数据查找效率高。我们常见的一些查找算法，比如说，二分查找法，前提也是待查找的集合有序排列。

　　三、采用非托管代码或者模块编写数据处理逻辑

　　上面的两部操作虽然减少了将近50-60%的内存占用，但是仍然达不到领导的要求，于是又尝试并比较了各种 使用不同的数据结构将数据载入到内存中的内存占用大小，包括直接将文件按类型读成字符串、数组、结构及类，内存占用最小的直接将文件读成字符串，10M的数据文件读进内存也会占用20-30M的空间，还不谈对其进行处理过程中产生的一些临时变量对内存的占用。使用dotTrace及CLR Profile等工具检查之后，发现内存的占用也是这些原始数据。然后以” How to reduce the memory usage of .NET applications” 到网上搜了一下减少.NET内存占用的一些方法，在StackOverflow上看到了这一回答：

分享：ASP.NET获取MS SQL Server安装实例
View Code protected void Page_Load(object sender, EventArgs e) { DataTable dataTable = SqlDataSourceEnumerator.Instance.GetDataSources(); foreach (DataRow dr in dataTable.Rows) { if (string.IsNullOrEmpty(dr[InstanceName].ToString())) this.DropDownLi