我們知道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[]數組引起的短短不到一分鐘的時間竟然占用了兩百多兆的內存好了這下可找到原凶了有得折騰了
方案:把要下載的數據一並加載到內存用戶在下載的時候通過position來獲取byte[]不新建直接返回是能解決問題但這就大大降低了服務端的可用性啊只能當做小文件服務端太不合理
方案:由於下載文件的時候返回的是一個可序列化的類所以想是不是這裡出現了問題可以直接返回byte[]以最基本的數據頭>數據長度>數據>數據尾來實現但這樣一來要改的東西太多了服務端客戶端協議重構眼看著就要落幕的項目卻要重頭再來心有不甘那再加上還有一堆任務在後面趕著這不是坑自己嗎也放棄了
然後又回到各種網絡資料搜索上經過一番查找後了解到byte[]最終也是會被回收的只要是托管的數據都是能被回收的只是周期可能會長一些最後又回到了Remoting本身上抱著試一試的心態把WellKnowObjectMode由SingleTon改為了SingleCall跑了一晚上最後穩定在了M上下總算松了口氣
使用SingleTon本來是想節省內存消耗的可沒想到得不償失如此的大費周折遂總結出SingleTon並不適合並發量大的服務端程序SingleTon是單線程模式在調用每個方法的時候都會被加鎖猜測造成數據一直不能被釋放的原因是由這些鎖造成的由於連接的數量太多導致連接一直處於排隊狀態造成了後面連接的客戶端響應過慢連接超時在這裡也給大家一個教訓還是用SingleCall實在
上面說了這麼多只是跟大家分享一下解決問題的經驗還有敘述了一下問題的所在如果各位有不同的見解請一定要指出來畢竟NET內存分配垃圾回收本就比較復雜
然事與願違卻柳暗花明
這篇文章的重點是講如何使用CLRProfiler來查找NET程序的內存分配情況的下面就開始吧
下載CLR Profiler:http://searchmicrosoftcom/enus/DownloadResultsaspx?q=clr%profiler
可根據自己NET的版本下載相應的CLRProfiler下面以NET版本為例CLRProfiler可以分析應用程序服務和ASPNET編寫的程序以下以應用程序為例為大家演示如何簡單使用CLRProfiler
下面是一個拆箱裝箱的例子CLRProfilerTestDemo通過這個例子來觀察進程托管堆的分配和研究垃圾回收機制的行為表現代碼如下
using System;
using SystemCollectionsGeneric;
namespace CLRProfilerTestDemo
{
class Program
{
static void Main（string[] args）
{
for （int i = ; i < * ; i++）
{
Boxing box = new Boxing（）
}
EnvironmentExit（EnvironmentExitCode）
}
}
class Boxing
{
private List<object> box = new List<object>（）
private List<int> unbox = new List<int>（）
public Boxing（）
{
for （int i = ; i < ; i++）
{
boxAdd（i）
unboxAdd（（int）box[i]）
}
}
}
}
[] []
From:http://tw.wingwit.com/Article/program/net/201311/16135.html
