【 某某提到: 】
: 一臺服務器裝有windows server 2008 r2，安裝16G內存并設置16G虛擬內存。最近在運行一個用C#編寫的大規模計算程序時發現，有很大一部分物理內存被莫名其妙地消耗了。資源監視器顯示該程序占用物理內存不到5G，但是總的物理內存消耗接近10G，可用物理內存僅剩6G。隨著運?
: 除了這個程序之外沒有其它程序大量占用內存。這個程序有大量磁盤IO操作，在運行中會不時地調用GC.Collect()以及時清理不用的內存。這個實驗中用到的一系列程序的結構基本相同，都會不時調用GC清理，但其它程序的內存使用都正常，只有這個程序會出現占用內存是實際使用的
: 請問為什么會出現這樣莫名其妙多占用內存的情況呢？謝謝大家
這個既不是應用本身的bug，也不是系統的memory leak。
當前資源監視器中關于系統物理內存，有這么幾個統計項，可用、緩存、總數、已安裝；其中"緩存"這項，代表著已用于文件系統、網絡等等子系統的數據緩沖存儲的內存容量，其中包含數量巨大的駐留在物理內存中的數據頁面。而這樣的物理內存消耗并沒有歸入任何一個進程列表顯示的進程所占用的物理內存。這就是為什么下面公式，
進程列表顯示的所有進程所占用的物理內存之和 + 可用物理內存 < 物理內存總數
，成立的原因所在。
導致這一現象的原因，從這個大規模計算程序的行為描述看，基本可以斷定是由于以下兩點，
1）應用本身的大規模數據駐留物理內存，導致parser.exe進程龐大的working set；
2）大量頻繁的IO操作，引起大量的物理內存為系統緩存所占用；
對于1),必須注意，GC.Collect()只是設置使能垃圾收集的標志位，并沒有立即啟動垃圾收集過程，這個過程的實際啟動時刻由CLR來動態決議；
所以如果要獲得即時的托管內存的釋放，并進一步釋放物理內存以減小當前進程的working set，可以使用AppDomain這個.net下可以用來資源劃分、獲取和釋放的，在概念上近似于輕量級進程的編程語義；在AppDomain中獲取的各種資源，包括托管內存、加載其中的各個assembly以及CCW等，在此AppDomain被釋放時都被相應的及時釋放（或者引用計數遞減）。
對于2），重新觀察先前的設計實現和模型，考慮是否能把一些分散的IO操作合并起來進行，比如,
for(long i=0; i < Count; ++i)
{
...
objIO.Operation(Data[i], 1);
...
}
修改為
for(long i=0; i < Count; ++i)
{
...
...
}
objIO.Operation(Data, Count);
這樣對于提高應用的IO效率以及提升系統緩存利用率應當會有幫助。
對于2），系統緩存隨著這個大規模計算應用的進行而逐步增大，并最后導致整個系統無法獲取的物理內存而無法繼續運行的現象，估計即使采用了在上文提出的，在應用程序代碼中盡可能合并IO操作，減少IO次數的方法，也不會改善系統緩存占用物理內存數量過大的問題。這個問題本質上是Windows操作系統本身從NT時代到現在，一直存在的問題，主要是圍繞著Windows kernel中的Cache mananger以及memory manager核心態組件的實現機制而產生的。
根據目前的Cc(對Cache manager的簡稱，在WindowsResourceKernel開源項目中，Cache manager相關模塊的函數都以Cc作為前綴，比如CcCopyRead，CcFlushCache等，Memory manager也同樣簡稱Mm)的實現機制，所有對文件系統的訪問，包括本地和網絡，都會首先由Cc對相關頁面作緩存映射，隨著頻繁的IO的操作，被Cc緩存的頁面也迅速遞增，而被緩存頁面占用多少物理內存，這是由Windows kernel中的Memory manager決定。目前在64位平臺上，系統緩存最高可達1TB，所以這個應用進程的運行中出現分配8G的緩存是完全可能的，但同時問題也隨之而來，那就是系統緩存占用了過多的物理內存，導致其他進程以及內核本身無法申請足夠的物理內存，最后致使系統“僵死”；
對于這個問題，微軟提供了“Microsoft Windows Dynamic Cache Service”工具來提供對系統緩存的工作集working set容量（也就是駐留物理內存的大小）的控制，這個工具主要是對SetSystemFileCacheSize的封裝，可以設置系統緩存容量的上下限。
但這只是一種臨時的解決方案，因為應用雖然可以通過上面這個Dynamic Cache Service來設置和限制系統緩存容量的大小，但是如何確定緩存容量大小的非常困難，如果過小，所有IO性能大受影響，整個Cc如同虛設；如果過大(等價于不受限)，那么系統緩存占用過多物理內存導致系統僵死的現象就會重現。
所以從根本上看，這個問題應由包括Cc和Mm在內的整個Windows kernel作出完整一致的調整，但從目前的實現看要完成整個方案改動很大，據稱這個改進可能會考慮包含在Win7中發布。
Microsoft Windows Dynamic Cache Service下載,
http://www.microsoft.com/downloads/en/details.aspx?FamilyID=e24ade0a-5efe-43c8-b9c3-5d0ecb2f39af&displaylang=en
Microsoft Windows Dynamic Cache Service相關的介紹，
http://blogs.msdn.com/b/ntdebugging/archive/2009/02/06/microsoft-windows-dynamic-cache-service.aspx
前些天在論壇上看到一個看似簡單，其實挺有意思的問題：
【20個連續的號碼中抽出6個來，要求6個號碼不能相連，有多少種抽法？】
這問題的本意應該是兩兩不相連的情況。
首先定義一個函數，F(m,p), m是確定抽出幾個號碼，p是總共有幾個號碼，那么
F(m,p)的值域就是代表在p個連續號碼中，抽出兩兩不相連的m個號碼，總共有幾種組合；
接著確定狀態轉移方程，經過觀察，p必須滿足條件p >= m*2-1，否則F就為0，同時
F(6,20) = F(5,18) + F(5,17) + F(5,16) + ... + F(5,9)；
因此可以得出如下狀態轉移方程，
當 p > m*2-1，F(m,p) = Sigma(F(m-1,q)) + 1；其中q 從(m-1)*2 到 p-2；
當 p == m*2-1，F(m,p) = 1；
當 p < m*2-1，F(m,p) = 0；
雖然分析到此，已可以著手具體實現，但是還是有些問題值得進一步分析，比如F(m,p)和F(m,p-1)之間存在何種關系，若使用遞歸，就當前這個問題效率估計會是問題；
因此對此方程進一步分析，
F(5,18) = Sigma(F(4,q)）+ F(4,7)；q從8到16
F(5,17) = Sigma(F(4,q)）+ F(4,7)；q從8到8；
...
可進一步推出，
當 p > m*2-1, F(m,p) = F(m,p-1) + F(m-1,p-2)；
這樣我們就得到了可以進行遞推實現的轉態轉移方程；
另外，對于m == 1的情形，顯然F(1,p) = p ；
#include<stdio.h>
#include<conio.h>
#define MAXLEN 10000
static int F[MAXLEN];
static int R[MAXLEN];
int Compute(
const int cM,
const int cP)
{
if (cM <= 0 || cP < (cM*2-1))
return 0;
if (cM == 1)
return cP;
if (cP == cM*2-1)
return 1;
for(int i = 0; i < MAXLEN; ++i) R[i] = i;
for(int m = 2; m <= cM; ++m)
{
int floof = 2*m;
int ceiling = cP-2*(cM-m);
F[2*m-1] = 1;
for(int p = floof; p <= ceiling; ++p)
F[p] = F[p-1] + R[p-2];
for(int j = floof; j <= ceiling; ++j)
R[j] = F[j];
}
return F[cP];
}
main()
{
Compute(6,20);
// Compute(6,19);
// Compute(5,18);
// Compute(5,17);
// Compute(4,16);
// Compute(6,13);
// Compute(6,12);
// Compute(5,11);
// Compute(5,10);
// Compute(4,9);
// Compute(4,8);
// Compute(3,7);
return 0;
}
接著再對目前的整個實現做下復雜度分析，主要處理部分基本上由兩個循環構成，對于R數組的初始化可作為常數項不計，那么
大O( F(m,p) ) = O( m*(ceiling-floor) )
= O( m*(p-2*m) )
近似于O( m*p )，
若m << p，顯然O(F(m,p)) = p；
若m 近似 p, 但事實上必須p >= 2*m - 1，否則F值就接近0或1，因此O(F(m,p)) 近似于const；
所以綜合來看上面的這個實現在時間上是個線性復雜度的實現；在空間上，使用了兩個長度至少為p的數組，個人認為可以對此進行進一步優化。
對于F(6,20) = 5005
整個實現在TC++ 3.0上驗證通過。
最近正好在思考系統API設計中考量的一些問題，
【某網友討論到】
: 那地址是不是同一個地址呢。我現在的理解是這樣的，假設有巨大的真實內存。windows首先將高2G的內存自己占了，用作各種內核對象。這2G內存共享給每個進程，但進程不能直接訪問，只能通過windows給定的函數訪問。
: 然后每個進程都給他2G內存，進程如果創建自己的對象就放到自己那2G內存里面，如果要建立內核對象就放到共享的那高2G里面去。
: 所以不同進程如果可以訪問高2G內存的話，任何進程訪問到同一個高地址實際上都是訪問到同一個對象。但如果訪問低2G地址的話，不同進程是對應不同的對象的。
在不同的進程中，詢問同一個內核對象的實際地址（無論是線性地址還是物理地址），是無意義的：
首先，內核對象只能由在內核態下的例程才能直接訪問，在我們日常的代碼中，所調用的Windows API，比如CreateFile, （注意調用剛開始時是處于用戶態下的），一般都會在ntdll.dll中找到對應的內核函數或例程，接著系統切換到內核態，開始調用實際對應的內核函數(KiCreateFile)，這個時候才會去訪問內核對象的實際地址，然后建立一個該內核對象對應當前進程的Handle，并把它返回給caller，同時切換回用戶態；因此，對于用戶態程序來說，只要且只能知道該內核對象在當前進程中的對應的Handle就可以對其進行操作了；
其次，這樣的設計是出于對OS核心數據結構（當然包括我們正在討論的內核對象）的保護；如果用戶態程序可以輕易的獲取內核數據結構的實際地址，那么對于整個OS的安全和穩定顯然構成很大的問題；一個用戶態的誤操作可以輕易的引起整個OS的崩潰，而有了這一層的保護，崩潰的只是當前進程而不是整個系統；
接著上面這點，也可以看出，內核對象的如此設計達到了接納OS本身的平滑演進的目的。從Windows 3.0到95/98，從NT到Win2k/XP，再到眼下的Vista/Win7，Windows操作系統本身發生了巨大的變化和進步，采納了無數的新技術新方法，但是它基本的系統應用編程接口，也就是我們所熟知的windows API，卻并沒有發生太大的改變，很多Win 3.0 這個16位OS時代的程序代碼只要當初設計規范編碼規范，稍許修改就可以在最新版的OS上運行如飛；是什么做到了這些？也就是所謂的極為重要的向后兼容性，我個人認為，把操作系統的重要/主要功能抽象成內核對象，并通過一套極為solid的API暴露出來，達成了這個目標。
這是一種更高層次上的面向對象，把實現的細節，把系統的復雜，簡單而優雅的封裝了起來。你只要調用CreateFile去建個文件或管道或郵槽，不用擔心當前OS是Windows 3.0還是Win7，獲得的Handle，你也不用去關心它以及它所指向的內核對象是Windows 3.0的實現還是Win7的實現。
Windows上所有的精彩幾乎都是基于這套通過內核對象概念抽象并暴露的API基礎之上，COM/OLE，這個二十年前震撼性的ABI和IPC范疇的技術規范，其中很多的設計思路也是植根于內核對象的設計理念，如COM對象的引用計數和內核對象引用計數，IUnknown和Windows Handle(前者是指向某個二進制兼容的組件對象，后者引用或間接指向某個內核對象，都是對于某個復雜概念的一致性抽象表述)，等等；
十年前的.net，本來是作為COM的升級版本推出，把COM/OLE的實現復雜性封裝在了虛擬機平臺CLR里面，而從這個虛擬機的開源實現SSCLI，我們可以看到大量的COM機制在.net的具體實現里面起了舉足輕重的作用。在這些VM中大量symbol有著COR的前綴或者后綴，COR指代什么？Common Object Runtime, 原來CLR/SSCLI的設計思路也是把OS通過虛擬機VM的形式，并通過common object向應用程序暴露功能。
小結一下，
OS內核對象API，三十年前系統級別的對象抽象；
COM/OLE，二十年前二進制組件級別的對象抽象；
.net/CLR, 十年前虛擬機平臺級別的對象抽象；
寫到這里倒是引起了我其他的一些思考，軟件工業界一直以來對面向對象OO是熱火朝天，特別是語言層面，從C++/Java/C#到Python/JScript，不一而足；
但是我們有沒有從根本性的設計理念上對面向對象，察納雅言了呢？
如果現在設計Windows這套API的任務放在大家面前，會采用內核對象/Handle方案還是直接指向OS內部數據結構的方式來暴露功能？
從三十年前的這套API的設計中，我們真的可以學到很多。