Lucene是一個高性能的java全文檢索工具包，它使用的是倒排文件索引結構。該結構及相應的生成算法如下：

0）設有兩篇文章1和2
文章1的內容為：Tom lives in Guangzhou,I live in Guangzhou too.
文章2的內容為：He once lived in Shanghai.

1)由于lucene是基于關鍵詞索引和查詢的，首先我們要取得這兩篇文章的關鍵詞，通常我們需要如下處理措施
a.我們現在有的是文章內容，即一個字符串，我們先要找出字符串中的所有單詞，即分詞。英文單詞由于用空格分隔，比較好處理。中文單詞間是連在一起的需要特殊的分詞處理。
b.文章中的”in”, “once” “too”等詞沒有什么實際意義，中文中的“的”“是”等字通常也無具體含義，這些不代表概念的詞可以過濾掉
c.用戶通常希望查“He”時能把含“he”，“HE”的文章也找出來，所以所有單詞需要統一大小寫。
d.用戶通常希望查“live”時能把含“lives”，“lived”的文章也找出來，所以需要把“lives”，“lived”還原成“live”
e.文章中的標點符號通常不表示某種概念，也可以過濾掉
在lucene中以上措施由Analyzer類完成

經過上面處理后
文章1的所有關鍵詞為：[tom] [live] [guangzhou] [i] [live] [guangzhou]
文章2的所有關鍵詞為：[he] [live] [shanghai]

2) 有了關鍵詞后，我們就可以建立倒排索引了。上面的對應關系是：“文章號”對“文章中所有關鍵詞”。倒排索引把這個關系倒過來，變成：“關鍵詞”對“擁有該關鍵詞的所有文章號”。文章1，2經過倒排后變成
關鍵詞 文章號
guangzhou 1
he 2
i 1
live 1,2
shanghai 2
tom 1

通常僅知道關鍵詞在哪些文章中出現還不夠，我們還需要知道關鍵詞在文章中出現次數和出現的位置，通常有兩種位置：a)字符位置，即記錄該詞是文章中第幾個字符（優點是關鍵詞亮顯時定位快）；b)關鍵詞位置，即記錄該詞是文章中第幾個關鍵詞（優點是節約索引空間、詞組（phase）查詢快），lucene中記錄的就是這種位置。

加上“出現頻率”和“出現位置”信息后，我們的索引結構變為：
關鍵詞 文章號[出現頻率] 出現位置
guangzhou 1[2] 3，6
he 2[1] 1
i 1[1] 4
live 1[2],2[1] 2，5，2
shanghai 2[1] 3
tom 1[1] 1

以live 這行為例我們說明一下該結構：live在文章1中出現了2次，文章2中出現了一次，它的出現位置為“2,5,2”這表示什么呢？我們需要結合文章號和出現頻率來分析，文章1中出現了2次，那么“2,5”就表示live在文章1中出現的兩個位置，文章2中出現了一次，剩下的“2”就表示live是文章2中第 2個關鍵字。

以上就是lucene索引結構中最核心的部分。我們注意到關鍵字是按字符順序排列的（lucene沒有使用B樹結構），因此lucene可以用二元搜索算法快速定位關鍵詞。

實現時 lucene將上面三列分別作為詞典文件（Term Dictionary）、頻率文件(frequencies)、位置文件 (positions)保存。其中詞典文件不僅保存有每個關鍵詞，還保留了指向頻率文件和位置文件的指針，通過指針可以找到該關鍵字的頻率信息和位置信息。

Lucene中使用了field的概念，用于表達信息所在位置（如標題中，文章中，url中），在建索引中，該field信息也記錄在詞典文件中，每個關鍵詞都有一個field信息(因為每個關鍵字一定屬于一個或多個field)。

為了減小索引文件的大小，Lucene對索引還使用了壓縮技術。首先，對詞典文件中的關鍵詞進行了壓縮，關鍵詞壓縮為<前綴長度，后綴>，例如：當前詞為“阿拉伯語”，上一個詞為“阿拉伯”，那么“阿拉伯語”壓縮為<3，語>。其次大量用到的是對數字的壓縮，數字只保存與上一個值的差值（這樣可以減小數字的長度，進而減少保存該數字需要的字節數）。例如當前文章號是16389（不壓縮要用3個字節保存），上一文章號是16382，壓縮后保存7（只用一個字節）。

下面我們可以通過對該索引的查詢來解釋一下為什么要建立索引。
假設要查詢單詞 “live”，lucene先對詞典二元查找、找到該詞，通過指向頻率文件的指針讀出所有文章號，然后返回結果。詞典通常非常小，因而，整個過程的時間是毫秒級的。
而用普通的順序匹配算法，不建索引，而是對所有文章的內容進行字符串匹配，這個過程將會相當緩慢，當文章數目很大時，時間往往是無法忍受的。

推薦比較大應用程序都由很多模塊組成，這些模塊分別完成相對獨立的功能，它們彼此協作來完成整個軟件系統的工作。其中可能存在一些模塊的功能較為通用，在構造其它軟件系統時仍會被使用。在構造軟件系統時，如果將所有模塊的源代碼都靜態編譯到整個應用程序EXE文件中，會產生一些問題：一個缺點是增加了應用程序的大小，它會占用更多的磁盤空間，程序運行時也會消耗較大的內存空間，造成系統資源的浪費；另一個缺點是，在編寫大的EXE程序時，在每次修改重建時都必須調整編譯所有源代碼，增加了編譯過程的復雜性，也不利于階段性的單元測試。

　　windows/" target=_blank>Windows系統平臺上提供了一種完全不同的較有效的編程和運行環境，你可以將獨立的程序模塊創建為較小的DLL(Dynamic Linkable Library)文件，并可對它們單獨編譯和測試。在運行時，只有當EXE程序確實要調用這些DLL模塊的情況下，系統才會將它們裝載到內存空間中。這種方式不僅減少了EXE文件的大小和對內存空間的需求，而且使這些DLL模塊可以同時被多個應用程序使用。Microsoft Windows自己就將一些主要的系統功能以DLL模塊的形式實現。例如IE中的一些基本功能就是由DLL文件實現的，它可以被其它應用程序調用和集成。

　　一般來說，DLL是一種磁盤文件（通常帶有DLL擴展名），它由全局數據、服務函數和資源組成，在運行時被系統加載到進程的虛擬空間中，成為調用進程的一部分。如果與其它DLL之間沒有沖突，該文件通常映射到進程虛擬空間的同一地址上。DLL模塊中包含各種導出函數，用于向外界提供服務。Windows在加載DLL模塊時將進程函數調用與DLL文件的導出函數相匹配。

　　在Win32環境中，每個進程都復制了自己的讀/寫全局變量。如果想要與其它進程共享內存，必須使用內存映射文件或者聲明一個共享數據段。DLL模塊需要的堆棧內存都是從運行進程的堆棧中分配出來的。

　　DLL現在越來越容易編寫。Win32已經大大簡化了其編程模式，并有許多來自AppWizard和MFC類庫的支持。

　　一、導出和導入函數的匹配

　　DLL文件中包含一個導出函數表。這些導出函數由它們的符號名和稱為標識號的整數與外界聯系起來。函數表中還包含了DLL中函數的地址。當應用程序加載DLL模塊時時，它并不知道調用函數的實際地址，但它知道函數的符號名和標識號。動態鏈接過程在加載的DLL模塊時動態建立一個函數調用與函數地址的對應表。如果重新編譯和重建DLL文件，并不需要修改應用程序，除非你改變了導出函數的符號名和參數序列。

　　簡單的DLL文件只為應用程序提供導出函數，比較復雜的DLL文件除了提供導出函數以外，還調用其它DLL文件中的函數。這樣，一個特殊的DLL可以既有導入函數，又有導入函數。這并不是一個問題，因為動態鏈接過程可以處理交叉相關的情況。

　　在DLL代碼中，必須像下面這樣明確聲明導出函數：

__declspec(dllexport) int MyFunction(int n);

　　但也可以在模塊定義(DEF)文件中列出導出函數，不過這樣做常常引起更多的麻煩。在應用程序方面，要求像下面這樣明確聲明相應的輸入函數：

__declspec(dllimport) int MyFuncition(int n);

　　僅有導入和導出聲明并不能使應用程序內部的函數調用鏈接到相應的DLL文件上。應用程序的項目必須為鏈接程序指定所需的輸入庫（LIB文件）。而且應用程序事實上必須至少包含一個對DLL函數的調用。

　　二、與DLL模塊建立鏈接

　　應用程序導入函數與DLL文件中的導出函數進行鏈接有兩種方式：隱式鏈接和顯式鏈接。所謂的隱式鏈接是指在應用程序中不需指明DLL文件的實際存儲路徑，程序員不需關心DLL文件的實際裝載。而顯式鏈接與此相反。

　　采用隱式鏈接方式，程序員在建立一個DLL文件時，鏈接程序會自動生成一個與之對應的LIB導入文件。該文件包含了每一個DLL導出函數的符號名和可選的標識號，但是并不含有實際的代碼。LIB文件作為DLL的替代文件被編譯到應用程序項目中。當程序員通過靜態鏈接方式編譯生成應用程序時，應用程序中的調用函數與LIB文件中導出符號相匹配，這些符號或標識號進入到生成的EXE文件中。LIB文件中也包含了對應的DLL文件名（但不是完全的路徑名），鏈接程序將其存儲在EXE文件內部。當應用程序運行過程中需要加載DLL文件時，Windows根據這些信息發現并加載DLL，然后通過符號名或標識號實現對DLL函數的動態鏈接。

　　顯式鏈接方式對于集成化的開發語言（例如VB）比較適合。有了顯式鏈接，程序員就不必再使用導入文件，而是直接調用Win32 的LoadLibary函數，并指定DLL的路徑作為參數。LoadLibary返回HINSTANCE參數，應用程序在調用GetProcAddress函數時使用這一參數。GetProcAddress函數將符號名或標識號轉換為DLL內部的地址。假設有一個導出如下函數的DLL文件：

extern "C" __declspec(dllexport) double SquareRoot(double d);

　　下面是應用程序對該導出函數的顯式鏈接的例子：

typedef double(SQRTPROC)(double);
HINSTANCE hInstance;
SQRTPROC* pFunction;
VERIFY(hInstance=::LoadLibrary("c:\\winnt\\system32\\mydll.dll"));
VERIFY(pFunction=(SQRTPROC*)::GetProcAddress(hInstance,"SquareRoot"));
double d=(*pFunction)(81.0);//調用該DLL函數

　　在隱式鏈接方式中，所有被應用程序調用的DLL文件都會在應用程序EXE文件加載時被加載在到內存中；但如果采用顯式鏈接方式，程序員可以決定DLL文件何時加載或不加載。顯式鏈接在運行時決定加載哪個DLL文件。例如，可以將一個帶有字符串資源的DLL模塊以英語加載，而另一個以西班牙語加載。應用程序在用戶選擇了合適的語種后再加載與之對應的DLL文件。

　　三、使用符號名鏈接與標識號鏈接

　　在Win16環境中，符號名鏈接效率較低，所有那時標識號鏈接是主要的鏈接方式。在Win32環境中，符號名鏈接的效率得到了改善。Microsoft現在推薦使用符號名鏈接。但在MFC庫中的DLL版本仍然采用的是標識號鏈接。一個典型的MFC程序可能會鏈接到數百個MFC DLL函數上。采用標識號鏈接的應用程序的EXE文件體相對較小，因為它不必包含導入函數的長字符串符號名。
比較大應用程序都由很多模塊組成，這些模塊分別完成相對獨立的功能，它們彼此協作來完成整個軟件系統的工作。其中可能存在一些模塊的功能較為通用，在構造其它軟件系統時仍會被使用。在構造軟件系統時，如果將所有模塊的源代碼都靜態編譯到整個應用程序EXE文件中，會產生一些問題：一個缺點是增加了應用程序的大小，它會占用更多的磁盤空間，程序運行時也會消耗較大的內存空間，造成系統資源的浪費；另一個缺點是，在編寫大的EXE程序時，在每次修改重建時都必須調整編譯所有源代碼，增加了編譯過程的復雜性，也不利于階段性的單元測試。

　　windows/" target=_blank>Windows系統平臺上提供了一種完全不同的較有效的編程和運行環境，你可以將獨立的程序模塊創建為較小的DLL(Dynamic Linkable Library)文件，并可對它們單獨編譯和測試。在運行時，只有當EXE程序確實要調用這些DLL模塊的情況下，系統才會將它們裝載到內存空間中。這種方式不僅減少了EXE文件的大小和對內存空間的需求，而且使這些DLL模塊可以同時被多個應用程序使用。Microsoft Windows自己就將一些主要的系統功能以DLL模塊的形式實現。例如IE中的一些基本功能就是由DLL文件實現的，它可以被其它應用程序調用和集成。

　　一般來說，DLL是一種磁盤文件（通常帶有DLL擴展名），它由全局數據、服務函數和資源組成，在運行時被系統加載到進程的虛擬空間中，成為調用進程的一部分。如果與其它DLL之間沒有沖突，該文件通常映射到進程虛擬空間的同一地址上。DLL模塊中包含各種導出函數，用于向外界提供服務。Windows在加載DLL模塊時將進程函數調用與DLL文件的導出函數相匹配。

　　在Win32環境中，每個進程都復制了自己的讀/寫全局變量。如果想要與其它進程共享內存，必須使用內存映射文件或者聲明一個共享數據段。DLL模塊需要的堆棧內存都是從運行進程的堆棧中分配出來的。

　　DLL現在越來越容易編寫。Win32已經大大簡化了其編程模式，并有許多來自AppWizard和MFC類庫的支持。

　　一、導出和導入函數的匹配

　　DLL文件中包含一個導出函數表。這些導出函數由它們的符號名和稱為標識號的整數與外界聯系起來。函數表中還包含了DLL中函數的地址。當應用程序加載DLL模塊時時，它并不知道調用函數的實際地址，但它知道函數的符號名和標識號。動態鏈接過程在加載的DLL模塊時動態建立一個函數調用與函數地址的對應表。如果重新編譯和重建DLL文件，并不需要修改應用程序，除非你改變了導出函數的符號名和參數序列。

　　簡單的DLL文件只為應用程序提供導出函數，比較復雜的DLL文件除了提供導出函數以外，還調用其它DLL文件中的函數。這樣，一個特殊的DLL可以既有導入函數，又有導入函數。這并不是一個問題，因為動態鏈接過程可以處理交叉相關的情況。

　　在DLL代碼中，必須像下面這樣明確聲明導出函數：

__declspec(dllexport) int MyFunction(int n);

　　但也可以在模塊定義(DEF)文件中列出導出函數，不過這樣做常常引起更多的麻煩。在應用程序方面，要求像下面這樣明確聲明相應的輸入函數：

__declspec(dllimport) int MyFuncition(int n);

　　僅有導入和導出聲明并不能使應用程序內部的函數調用鏈接到相應的DLL文件上。應用程序的項目必須為鏈接程序指定所需的輸入庫（LIB文件）。而且應用程序事實上必須至少包含一個對DLL函數的調用。

　　二、與DLL模塊建立鏈接

　　應用程序導入函數與DLL文件中的導出函數進行鏈接有兩種方式：隱式鏈接和顯式鏈接。所謂的隱式鏈接是指在應用程序中不需指明DLL文件的實際存儲路徑，程序員不需關心DLL文件的實際裝載。而顯式鏈接與此相反。

　　采用隱式鏈接方式，程序員在建立一個DLL文件時，鏈接程序會自動生成一個與之對應的LIB導入文件。該文件包含了每一個DLL導出函數的符號名和可選的標識號，但是并不含有實際的代碼。LIB文件作為DLL的替代文件被編譯到應用程序項目中。當程序員通過靜態鏈接方式編譯生成應用程序時，應用程序中的調用函數與LIB文件中導出符號相匹配，這些符號或標識號進入到生成的EXE文件中。LIB文件中也包含了對應的DLL文件名（但不是完全的路徑名），鏈接程序將其存儲在EXE文件內部。當應用程序運行過程中需要加載DLL文件時，Windows根據這些信息發現并加載DLL，然后通過符號名或標識號實現對DLL函數的動態鏈接。

　　顯式鏈接方式對于集成化的開發語言（例如VB）比較適合。有了顯式鏈接，程序員就不必再使用導入文件，而是直接調用Win32 的LoadLibary函數，并指定DLL的路徑作為參數。LoadLibary返回HINSTANCE參數，應用程序在調用GetProcAddress函數時使用這一參數。GetProcAddress函數將符號名或標識號轉換為DLL內部的地址。假設有一個導出如下函數的DLL文件：

extern "C" __declspec(dllexport) double SquareRoot(double d);

　　下面是應用程序對該導出函數的顯式鏈接的例子：

typedef double(SQRTPROC)(double);
HINSTANCE hInstance;
SQRTPROC* pFunction;
VERIFY(hInstance=::LoadLibrary("c:\\winnt\\system32\\mydll.dll"));
VERIFY(pFunction=(SQRTPROC*)::GetProcAddress(hInstance,"SquareRoot"));
double d=(*pFunction)(81.0);//調用該DLL函數

　　在隱式鏈接方式中，所有被應用程序調用的DLL文件都會在應用程序EXE文件加載時被加載在到內存中；但如果采用顯式鏈接方式，程序員可以決定DLL文件何時加載或不加載。顯式鏈接在運行時決定加載哪個DLL文件。例如，可以將一個帶有字符串資源的DLL模塊以英語加載，而另一個以西班牙語加載。應用程序在用戶選擇了合適的語種后再加載與之對應的DLL文件。

　　三、使用符號名鏈接與標識號鏈接

　　在Win16環境中，符號名鏈接效率較低，所有那時標識號鏈接是主要的鏈接方式。在Win32環境中，符號名鏈接的效率得到了改善。Microsoft現在推薦使用符號名鏈接。但在MFC庫中的DLL版本仍然采用的是標識號鏈接。一個典型的MFC程序可能會鏈接到數百個MFC DLL函數上。采用標識號鏈接的應用程序的EXE文件體相對較小，因為它不必包含導入函數的長字符串符號名。
四、編寫DllMain函數

　　DllMain函數是DLL模塊的默認入口點。當windows/" target=_blank>Windows加載DLL模塊時調用這一函數。系統首先調用全局對象的構造函數，然后調用全局函數DLLMain。DLLMain函數不僅在將DLL鏈接加載到進程時被調用，在DLL模塊與進程分離時（以及其它時候）也被調用。下面是一個框架DLLMain函數的例子。

HINSTANCE g_hInstance;
extern "C" int APIENTRY DllMain(HINSTANCE hInstance,DWORD dwReason,LPVOID lpReserved)
{
if(dwReason==DLL_PROCESS_ATTACH)
{
TRACE0("EX22A.DLL Initializing!\n");
//在這里進行初始化
}
else if(dwReason=DLL_PROCESS_DETACH)
{
TRACE0("EX22A.DLL Terminating!\n");
//在這里進行清除工作
}
return 1;//成功
}

　　如果程序員沒有為DLL模塊編寫一個DLLMain函數，系統會從其它運行庫中引入一個不做任何操作的缺省DLLMain函數版本。在單個線程啟動和終止時，DLLMain函數也被調用。正如由dwReason參數所表明的那樣。

　　五、模塊句柄

　　進程中的每個DLL模塊被全局唯一的32字節的HINSTANCE句柄標識。進程自己還有一個HINSTANCE句柄。所有這些模塊句柄都只有在特定的進程內部有效，它們代表了DLL或EXE模塊在進程虛擬空間中的起始地址。在Win32中，HINSTANCE和HMODULE的值是相同的，這個兩種類型可以替換使用。進程模塊句柄幾乎總是等于0x400000，而DLL模塊的加載地址的缺省句柄是0x10000000。如果程序同時使用了幾個DLL模塊，每一個都會有不同的HINSTANCE值。這是因為在創建DLL文件時指定了不同的基地址，或者是因為加載程序對DLL代碼進行了重定位。
模塊句柄對于加載資源特別重要。Win32 的FindResource函數中帶有一個HINSTANCE參數。EXE和DLL都有其自己的資源。如果應用程序需要來自于DLL的資源，就將此參數指定為DLL的模塊句柄。如果需要EXE文件中包含的資源，就指定EXE的模塊句柄。

　　但是在使用這些句柄之前存在一個問題，你怎樣得到它們呢？如果需要得到EXE模塊句柄，調用帶有Null參數的Win32函數GetModuleHandle；如果需要DLL模塊句柄，就調用以DLL文件名為參數的Win32函數GetModuleHandle。

　　六、應用程序怎樣找到DLL文件

　　如果應用程序使用LoadLibrary顯式鏈接，那么在這個函數的參數中可以指定DLL文件的完整路徑。如果不指定路徑，或是進行隱式鏈接，Windows將遵循下面的搜索順序來定位DLL：

　　1． 包含EXE文件的目錄，
　　2． 進程的當前工作目錄，
　　3． Windows系統目錄，
　　4． Windows目錄，
　　5． 列在Path環境變量中的一系列目錄。

　　這里有一個很容易發生錯誤的陷阱。如果你使用VC＋＋進行項目開發，并且為DLL模塊專門創建了一個項目，然后將生成的DLL文件拷貝到系統目錄下，從應用程序中調用DLL模塊。到目前為止，一切正常。接下來對DLL模塊做了一些修改后重新生成了新的DLL文件，但你忘記將新的DLL文件拷貝到系統目錄下。下一次當你運行應用程序時，它仍加載了老版本的DLL文件，這可要當心！

　　七、調試DLL程序

　　Microsoft 的VC＋＋是開發和測試DLL的有效工具，只需從DLL項目中運行調試程序即可。當你第一次這樣操作時，調試程序會向你詢問EXE文件的路徑。此后每次在調試程序中運行DLL時，調試程序會自動加載該EXE文件。然后該EXE文件用上面的搜索序列發現DLL文件，這意味著你必須設置Path環境變量讓其包含DLL文件的磁盤路徑，或者也可以將DLL文件拷貝到搜索序列中的目錄路徑下。

     摘要: 隨著人們對應用程序的要求越來越高，單進程應用在許多場合已不能滿足人們的要求。編寫多進程/多線程程序成為現代程序設計的一個重要特點，在多進程程序設計中，進程間的通信是不可避免的。Microsoft Win32 API提供了多種進程間通信的方法，全面地闡述了這些方法的特點，并加以比較和分析，希望能給讀者選擇通信方法提供參考。  閱讀全文 轉自：http://www.cnblogs.com/sideandside/archive/2007/04/04/699637.html

        進程是系統分配資源的單位，每一個進程對應與一個活動的程序，當進程激活時，操作系統就將系統的資源包括內存、I/O和CPU等分配給它，使它執行。線程是CPU分配時間的單位，每一個線程對應于它在進程中的一個函數，也就是內存中的代碼段，多個線程執行時CPU會根據它們的優先級分配時間，使它們完成自己的功能。 一般來說，進程中至少一個線程，一個主線程和其他線程組成一個進程。多個線程的目的在于分享CPU的時間片，從而完成并行任務。
下面是自己整理的：
 線程和進程的比較：
線程是比進程更小的能獨立運行的基本單位，通常一個進程都有若干個線程，至少也需要一個線程。
        1.調度
線程師調度和分派的基本單位，進程是資源擁有的基本單位。
        2.并發性
進程之間可以并發執行，在一個進程中的多個線程之間也可以并發執行。
        3.擁有資源
進程是擁有資源的一個獨立單元，線程自己不擁有系統資源（也有一點比不可少的資源）但它可以訪問其隸屬進程的資源。
        ４．系統開銷
創建或撤消進程時，系統都要為之分配或回收資源，如內存空間、I/O設備等，OS所付出的開銷顯著大于在創建或撤消線程時的開銷；進程切換的開銷也遠大于線程切換的開銷。

        進程是指在系統中正在運行的一個應用程序；線程是系統分配處理器時間資源的基本單元，或者說進程之內獨立執行的一個單元。對于操作系統而言其調度單元是線程。一個進程至少包括一個線程，通常將該線程稱為主線程。一個進程從主線程的執行開始進而創建一個或多個附加線程，就是所謂基于多線程的多任務。
　　那進程與線程的區別到底是什么？進程是執行程序的實例。例如，當你運行記事本程序（Nodepad）時，你就創建了一個用來容納組成Notepad.exe的代碼及其所需調用動態鏈接庫的進程。每個進程均運行在其專用且受保護的地址空間內。因此，如果你同時運行記事本的兩個拷貝，該程序正在使用的數據在各自實例中是彼此獨立的。在記事本的一個拷貝中將無法看到該程序的第二個實例打開的數據。

　　以沙箱為例進行闡述。一個進程就好比一個沙箱。線程就如同沙箱中的孩子們。孩子們在沙箱子中跑來跑去，并且可能將沙子攘到別的孩子眼中，他們會互相踢打或撕咬。但是，這些沙箱略有不同之處就在于每個沙箱完全由墻壁
和頂棚封閉起來，無論箱中的孩子如何狠命地攘沙，他們也不會影響到其它沙箱中的其他孩子。因此，每個進程就象一個被保護起來的沙箱。未經許可，無人可以進出。

　　實際上線程運行而進程不運行。兩個進程彼此獲得專用數據或內存的唯一途徑就是通過協議來共享內存塊。這是一種協作策略。下面讓我們分析一下任務管理器里的進程選項卡。

　　這里的進程是指一系列進程，這些進程是由它們所運行的可執行程序實例來識別的，這就是進程選項卡中的第一列給出了映射名稱的原因。請注意，這里并沒有進程名稱列。進程并不擁有獨立于其所歸屬實例的映射名稱。換言之
，如果你運行5個記事本拷貝，你將會看到5個稱為Notepad.exe的進程。它們是如何彼此區別的呢？其中一種方式是通過它們的進程ID，因為每個進程都擁有其獨一無二的編碼。該進程ID由Windows NT或Windows 2000生成，并可以循環使用。因此，進程ID將不會越編越大，它們能夠得到循環利用。第三列是被進程中的線程所占用的CPU時間百分比。它不是CPU的編號，而是被進程占用的CPU時間百分比。此時我的系統基本上是空閑的。盡管系統看上去每一秒左右都只使用一小部分CPU時間，但該系統空閑進程仍舊耗用了大約99%的CPU時間。

　　第四列，CPU時間，是CPU被進程中的線程累計占用的小時、分鐘及秒數。請注意，我對進程中的線程使用占用一詞。這并不一定意味著那就是進程已耗用的CPU時間總和，因為，如我們一會兒將看到的，NT計時的方式是，當特定的時鐘間隔激發時，無論誰恰巧處于當前的線程中，它都將計算到CPU周期之內。通常情況下，在大多數NT系統中，時鐘以10毫秒的間隔運行。每10毫秒NT的心臟就跳動一下。有一些驅動程序代碼片段運行并顯示誰是當前的線程。讓我們將CPU時間的最后10毫秒記在它的帳上。因此，如果一個線程開始運行，并在持續運行8毫秒后完成，接著，第二個線程開始運行并持續了2毫秒，這時，時鐘激發，請猜一猜這整整10毫秒的時鐘周期到底記在了哪個線程的帳上？答案是第二個線程。因此，NT中存在一些固有的不準確性，而NT恰是以這種方式進行計時，實際情況也如是，大多數32位操作系統中都存在一個基于間隔的計時機制。請記住這一點，因為，有時當你觀察線程所耗用的CPU總和時，會出現盡管該線程或許看上去已運行過數十萬次，但其CPU時間占用量卻可能是零或非常短暫的現象，那么，上述解釋便是原因所在。上述也就是我們在任務管理器的進程選項卡中所能看到的基本信息列。

     摘要: 簡述組件的定義  閱讀全文