c#程式記憶體配置

標籤：

c#程式記憶體配置

進程可使用記憶體數就是操作系統給進程分配的最大地址，一般的32位作業系統提供給使用者地址最大都是3g（作業系統自己保留1g），windows由於商業目的，對於個人使用者只提供了2g地址，要使用3g擴充需要對系統配置作修改。還有就是intel的32位晶片實際上是支援36位定址能力的(64g)，但是也是出於商業目的對於大部分個人晶片都禁止了這個功能，這個禁止可能是物理上的限制個人使用者幾乎無法修改。

而且在作業系統中物理可用記憶體和進程實際佔用記憶體是有區別的，因為有虛擬位址和交換區這種概念，進程實際使用的記憶體量遠遠大於物理可用記憶體，最簡單的一個例子就是聲明一個非常大的數組但不存放任何東西，進程啟動後佔用的實體記憶體可能很小但是申請的記憶體位址卻是非常大了（虛擬記憶體數），所以就可能產生這麼一種情況:空閑實體記憶體很多進程所佔實體記憶體很小但卻報了記憶體不夠，因為進程可用地址已經完全被分配完了(申請很多，卻沒有用。所以要JIT，lazy...)。

有些時候由於代碼的問題（確切地說是不瞭解framework的記憶體使用量機制）也會導致outofmemory，一般佔用大記憶體的情況就是list和hashtable2種結構，而這2種資料結構實際上都是使用數組作為容器存放元素的，由於數組是定長結構所以當達到上限時需要做動態擴容，動態擴容的演算法都是2倍當前數組長度，數組本身又是需要連續記憶體作為保證，如果記憶體片段過多就會導致沒有連續記憶體可用，.net的智能記憶體回收行程也沒辦法完全避免記憶體片段（可以通過禁止記憶體回收或者降低記憶體回收頻率來避免片段，但是需要手工回收來解決記憶體增長問題），所以在使用list或者hashtable的時候最好能事先指定需要的最大容量上限，避免到後面因為片段問題導致outofmemory。比如申請的初始記憶體塊不夠大，後期要分配更大記憶體，在本塊記憶體區後面沒有這麼大的連續空閑記憶體，就會outofmemory。

小計：C# List的記憶體配置

當List<T>對象的Item元素數量超過了Capacity的數量時，List<T>對象會重新申請一塊大小是原來Capacity的兩倍的記憶體空間，然後將當前所有Item元素以及待添加元素複製到新的記憶體空間中。

知道了記憶體配置的原則，接下來就得根據這些原則來採用最優的方法保證有限的記憶體空間能得到合理的運用。歸納起來主要有如下你點：
1.當執行個體化一個List<T>對象時，如果能預知其Item元素的大致個數，應該在執行個體化一個List<T>對象的時候設定其Capacity值為接近於Item元素個數的最小值。這樣的話可以避免在像List<T>中添加元素的時候，不斷的申請記憶體與元素的複製。

2.當由於不斷的調用Remove方法而導致Item元素的個數遠遠小於Capacity，就會造成記憶體的浪費。此時可以調用TrimExcess方法釋放多餘的記憶體。

c# 線程池 http://wenku.baidu.com/view/a6f14375f46527d3240ce01b.html

=====================================

Chat Question: Memory Limits for 32-bit and 64-bit processes

During our recent blog chat, there were a number of topics that were asked about and I am going to expand on some of them.  The first one is the memory limits for different processes.

This really depends on a few different things.  The architecture of the process (32-bit or 64-bit) and also the architecture of the Operating System the process is running on.  For 32-bit it also depends if you use the /3GB switch or not.

So I broke this up based on these things into the table below, this is the maximum amount of memory available for the process assuming you have that much RAM and Pagefile space.

	32-bit OS	64-bit OS
32-bit process	2 GB	4 GB
32-bit process with /3GB	3 GB	N/A
64-bit process	N/A	16 TB

These process numbers are contingent on how much RAM and disk space you have, so if you have 4 GB of RAM（記憶體） and 4 GB Pagefile（虛擬記憶體）, the total memory of all running processes can’t be greater then 8 GB.

Note: If you let Windows manage your Pagefile size, when you hit this limit, Windows will try to grow your Pagefile as long as there is disk space available.

For the amount a .NET application will use before we can expect to see out of memory, those numbers are:

	32-bit OS	64-bit OS
32-bit process	800-1200 MB	2800 MB
32-bit process with /3GB	1800 MB	N/A
64-bit process	N/A	2800 MB if using a 4 GB process or more if more RAM (around 70% of RAM + Pagefile)

Keep in mind that although a .NET process can grow this large, if the process is multiple GB in size, it can become very difficult for the Garage Collector to keep up with the memory as Generation 2 will become very large.  I’ll talk about the generations more in an upcoming post.

Hopefully that will clear up how much memory each one uses.

Keep checking the RECAP- ASP.NET Blog Chat to see other topics that Tess or I write about.

當前標籤: C# c#實現golang 的channel visionwang 2013-12-03 21:18 閱讀:398 評論:0   .NET中的GC總結 visionwang 2013-10-15 21:54 閱讀:165 評論:0   linq中不能準確按拼音排序 visionwang 2013-10-14 16:37 閱讀:42 評論:0   c#程式記憶體配置 visionwang 2013-04-24 23:08 閱讀:3126 評論:0   .net平台下串連池概述 visionwang 2012-11-16 23:34 閱讀:187 評論:0  

 

  

c#程式記憶體配置