如何查找如何查找.NET程序内存不断上涨的原因程序内存不断上涨的原因
前段时间公司新写的自动升级服务端(Remoting)出现了内存不断飙升的情况，从最初的七八十兆一晚上竟然飙到了1G多，直
接导致客户端连接服务端失败，这不科学，后来优化了各种可能造成占用内存的方法（数据库连接，I/O操作，引用类型释
放），但效果不佳，这下可难为我们了，不知道问题的所在也就不知道该如何去修改。
我们知道.NET是带有垃圾回收机制的，出现这种情况一般是由某些数据长期存活在内存中又不能被当成垃圾数据回收的原因
造成的。
后来就在各搜索引擎上进行了各种搜索，有说使用windebug分析dump，但需要大量时间琢磨，有人说是不是硬件问题，还有
人说中毒了，最后找到了一款微软推出的CLRProfiler工具，貌似很强大，遂MSDN了一把，MSDN是这样说的：
Who allocates what on the managed heap
Which objects survive on the managed heap.
Who is holding on to objects.
What the garbage collector does over the lifetime of your application.
得到这些信息以后就决定使用一下，让服务端运行了一会儿，停止以后得到分析结果，最终在Allocation Graph视图下了解到
原来是下载文件DownloadFile方法下的byte[]数组引起的，短短不到一分钟的时间竟然占用了两百多兆的内存，好了，这下可
找到“原凶”了，有得折腾了
方案1：把要下载的数据一并加载到内存，用户在下载的时候通过position来获取byte[]不新建直接返回，是能解决问题，但这
就大大降低了服务端的可用性啊，只能当做小文件服务端，太不合理。
方案2：由于下载文件的时候返回的是一个可序列化的类，所以想是不是这里出现了问题，可以直接返回byte[]，以最基本的数
据头->数据长度->数据->数据尾来实现，但这样一来要改的东西太多了，服务端客户端，协议重构，眼看着就要落幕的项目却
要重头再来心有不甘那，再加上还有一堆任务在后面赶着，这不是坑自己吗，也放弃了。
然后又回到各种网络资料搜索上，经过一番查找后了解到，byte[]最终也是会被回收的，只要是托管的数据都是能被回收的，
只是周期可能会长一些，最后又回到了Remoting本身上，抱着试一试的心态把WellKnowObjectMode由SingleTon改为了
SingleCall，跑了一晚上最后稳定在了200M上下，总算松了口气。
使用SingleTon本来是想节省内存消耗的，可没想到得不偿失如此的大费周折，遂总结出SingleTon并不适合并发量大的服务端
程序，SingleTon是单线程模式，在调用每个方法的时候都会被加锁，猜测造成数据一直不能被释放的原因是由这些锁造成
的，由于连接的数量太多导致连接一直处于排队状态，造成了后面连接的客户端响应过慢，连接超时，在这里也给大家一个教
训还是用SingleCall实在。
上面说了这么多只是跟大家分享一下解决问题的经验，还有叙述了一下问题的所在，如果各位有不同的见解请一定要指出来，
毕竟.NET内存分配、垃圾回收本就比较复杂。
然事与愿违却柳暗花明
这篇文章的重点是讲如何使用CLRProfiler来查找.NET程序的内存分配情况的，下面就开始吧。
下载CLR Profiler：http://search.microsoft.com/en-us/DownloadResults.aspx?q=clr%20profiler
可根据自己.NET的版本下载相应的CLRProfiler，下面以.NET4.0版本为例。CLRProfiler可以分析应用程序，服务和ASP.NET
编写的程序，以下以应用程序为例为大家演示如何简单使用CLRProfiler。
下面是一个拆箱装箱的例子CLRProfilerTestDemo，通过这个例子来观察进程托管堆的分配和研究垃圾回收机制的行为表现，
代码如下
评论1