近期在定位问题时发现使用OleDb打开很大的Excel文件后，即使什么都不操作Colse掉，内存释放了部分，但是并未回到打开前的水平。在Excel 150M，解压缩后900M的场景下，打开后直接Close，内存比打开前多了近90M。如果再次打开关闭，内存不会再增加。但是如果是依此打开多个不同的大型Excel文件，程序很容易内存溢出崩掉。
在会用Red Gate进行内存分析时，发现确实是Excel非托管代码，在不断累积内存，想了很久，目前想到的有3种解决方案。
首先，先上问题复现的代码，很简单，就是使用OleDb打开一个150M左右的Excel
C# code
|
1 2 3 4 5 6 7 8 9 10 11 |
|
复现步骤：
1，准备一个150M的Excel
2，打开任务管理器，打开程序。
3，记录当前程序内存。
4，回车，等到文件读取完毕，并Close释放内存稳定后，再记录当前程序内存。
5，发现多处了70-90M
解决方案
1，经过验证，CSV类型，使用OleDb打开后没有出现类似的内存泄露。所以，可以先把xls、xlsx转为csv，再对csv使用oleDb打开进行操作，最后删掉该csv即可。
如果使用该方法需要注意，csv读取不能根据Sheet读取，只能读整个文件。
xls、xlsx的转化需要使用Microsoft.Office.Interop.Excel.Apllication ，所以需要把当前所需的数据库操作封装一层。
2，直接使用Microsoft.Office.Interop.Excel.Apllication进行Excel操作，并在操作后直接杀掉Excel进程。
但是该方法因为Microsoft.Office.Interop.Excel.Apllication进行Excel读取，每个Range每个Range的读取，都是进程间进行数据交换，性能太渣。唯一可行的是，一大块一大块的读数据，但是没有找到对应的方法。
3，另起一个进程，使用OleDb对Excel进行操作，操作后杀掉该进程。
这个方案可行度也不高，在C#下，要另起进程，带来的稳定性、性能开销都比较大，特别是如果是频繁读取Excel的场景下。
需要解决的问题
1，还有没有更好的办法，在不使用Microsoft.Office.Interop.Excel.Apllication的情况下，解决这一问题。因为使用Microsoft.Office.Interop.Excel.Apllication，就意味着要开个Excel进程，意味着性能开销。
2，OleDb在打开Excel文件时，会进行解压缩，150M 的文件，Open完毕后，程序进程能增加900多M。而使用Microsoft.Office.Interop.Excel.Apllication进行打开，发现只增加了150M。能否在使用OleDb的情况下，减小这部分的内存增加，要知道在程序本身就很耗内存的情况下，打开个Excel就陡增了900M，是很容易崩掉的。
以下是微软提供的解决办法
http://support.microsoft.com/kb/319998
OleDb 内存泄露问题