Lucene是一個(gè)高性能的java全文檢索工具包，它使用的是倒排文件索引結(jié)構(gòu)。該結(jié)構(gòu)及相應(yīng)的生成算法如下：

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

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

經(jīng)過上面處理后
文章1的所有關(guān)鍵詞為：[tom] [live] [guangzhou] [i] [live] [guangzhou]
文章2的所有關(guān)鍵詞為：[he] [live] [shanghai]

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

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

加上“出現(xiàn)頻率”和“出現(xiàn)位置”信息后，我們的索引結(jié)構(gòu)變?yōu)椋?
關(guān)鍵詞 文章號[出現(xiàn)頻率] 出現(xiàn)位置
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 這行為例我們說明一下該結(jié)構(gòu)：live在文章1中出現(xiàn)了2次，文章2中出現(xiàn)了一次，它的出現(xiàn)位置為“2,5,2”這表示什么呢？我們需要結(jié)合文章號和出現(xiàn)頻率來分析，文章1中出現(xiàn)了2次，那么“2,5”就表示live在文章1中出現(xiàn)的兩個(gè)位置，文章2中出現(xiàn)了一次，剩下的“2”就表示live是文章2中第 2個(gè)關(guān)鍵字。

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

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

Lucene中使用了field的概念，用于表達(dá)信息所在位置（如標(biāo)題中，文章中，url中），在建索引中，該field信息也記錄在詞典文件中，每個(gè)關(guān)鍵詞都有一個(gè)field信息(因?yàn)槊總€(gè)關(guān)鍵字一定屬于一個(gè)或多個(gè)field)。

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

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

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

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

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

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

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

　　一、導(dǎo)出和導(dǎo)入函數(shù)的匹配

　　DLL文件中包含一個(gè)導(dǎo)出函數(shù)表。這些導(dǎo)出函數(shù)由它們的符號名和稱為標(biāo)識號的整數(shù)與外界聯(lián)系起來。函數(shù)表中還包含了DLL中函數(shù)的地址。當(dāng)應(yīng)用程序加載DLL模塊時(shí)時(shí)，它并不知道調(diào)用函數(shù)的實(shí)際地址，但它知道函數(shù)的符號名和標(biāo)識號。動態(tài)鏈接過程在加載的DLL模塊時(shí)動態(tài)建立一個(gè)函數(shù)調(diào)用與函數(shù)地址的對應(yīng)表。如果重新編譯和重建DLL文件，并不需要修改應(yīng)用程序，除非你改變了導(dǎo)出函數(shù)的符號名和參數(shù)序列。

　　簡單的DLL文件只為應(yīng)用程序提供導(dǎo)出函數(shù)，比較復(fù)雜的DLL文件除了提供導(dǎo)出函數(shù)以外，還調(diào)用其它DLL文件中的函數(shù)。這樣，一個(gè)特殊的DLL可以既有導(dǎo)入函數(shù)，又有導(dǎo)入函數(shù)。這并不是一個(gè)問題，因?yàn)閯討B(tài)鏈接過程可以處理交叉相關(guān)的情況。

　　在DLL代碼中，必須像下面這樣明確聲明導(dǎo)出函數(shù)：

__declspec(dllexport) int MyFunction(int n);

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

__declspec(dllimport) int MyFuncition(int n);

　　僅有導(dǎo)入和導(dǎo)出聲明并不能使應(yīng)用程序內(nèi)部的函數(shù)調(diào)用鏈接到相應(yīng)的DLL文件上。應(yīng)用程序的項(xiàng)目必須為鏈接程序指定所需的輸入庫（LIB文件）。而且應(yīng)用程序事實(shí)上必須至少包含一個(gè)對DLL函數(shù)的調(diào)用。

　　二、與DLL模塊建立鏈接

　　應(yīng)用程序?qū)牒瘮?shù)與DLL文件中的導(dǎo)出函數(shù)進(jìn)行鏈接有兩種方式：隱式鏈接和顯式鏈接。所謂的隱式鏈接是指在應(yīng)用程序中不需指明DLL文件的實(shí)際存儲路徑，程序員不需關(guān)心DLL文件的實(shí)際裝載。而顯式鏈接與此相反。

　　采用隱式鏈接方式，程序員在建立一個(gè)DLL文件時(shí)，鏈接程序會自動生成一個(gè)與之對應(yīng)的LIB導(dǎo)入文件。該文件包含了每一個(gè)DLL導(dǎo)出函數(shù)的符號名和可選的標(biāo)識號，但是并不含有實(shí)際的代碼。LIB文件作為DLL的替代文件被編譯到應(yīng)用程序項(xiàng)目中。當(dāng)程序員通過靜態(tài)鏈接方式編譯生成應(yīng)用程序時(shí)，應(yīng)用程序中的調(diào)用函數(shù)與LIB文件中導(dǎo)出符號相匹配，這些符號或標(biāo)識號進(jìn)入到生成的EXE文件中。LIB文件中也包含了對應(yīng)的DLL文件名（但不是完全的路徑名），鏈接程序?qū)⑵浯鎯υ贓XE文件內(nèi)部。當(dāng)應(yīng)用程序運(yùn)行過程中需要加載DLL文件時(shí)，Windows根據(jù)這些信息發(fā)現(xiàn)并加載DLL，然后通過符號名或標(biāo)識號實(shí)現(xiàn)對DLL函數(shù)的動態(tài)鏈接。

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

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

　　下面是應(yīng)用程序?qū)υ搶?dǎo)出函數(shù)的顯式鏈接的例子：

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);//調(diào)用該DLL函數(shù)

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

　　三、使用符號名鏈接與標(biāo)識號鏈接

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

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

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

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

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

　　一、導(dǎo)出和導(dǎo)入函數(shù)的匹配

　　DLL文件中包含一個(gè)導(dǎo)出函數(shù)表。這些導(dǎo)出函數(shù)由它們的符號名和稱為標(biāo)識號的整數(shù)與外界聯(lián)系起來。函數(shù)表中還包含了DLL中函數(shù)的地址。當(dāng)應(yīng)用程序加載DLL模塊時(shí)時(shí)，它并不知道調(diào)用函數(shù)的實(shí)際地址，但它知道函數(shù)的符號名和標(biāo)識號。動態(tài)鏈接過程在加載的DLL模塊時(shí)動態(tài)建立一個(gè)函數(shù)調(diào)用與函數(shù)地址的對應(yīng)表。如果重新編譯和重建DLL文件，并不需要修改應(yīng)用程序，除非你改變了導(dǎo)出函數(shù)的符號名和參數(shù)序列。

　　簡單的DLL文件只為應(yīng)用程序提供導(dǎo)出函數(shù)，比較復(fù)雜的DLL文件除了提供導(dǎo)出函數(shù)以外，還調(diào)用其它DLL文件中的函數(shù)。這樣，一個(gè)特殊的DLL可以既有導(dǎo)入函數(shù)，又有導(dǎo)入函數(shù)。這并不是一個(gè)問題，因?yàn)閯討B(tài)鏈接過程可以處理交叉相關(guān)的情況。

　　在DLL代碼中，必須像下面這樣明確聲明導(dǎo)出函數(shù)：

__declspec(dllexport) int MyFunction(int n);

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

__declspec(dllimport) int MyFuncition(int n);

　　僅有導(dǎo)入和導(dǎo)出聲明并不能使應(yīng)用程序內(nèi)部的函數(shù)調(diào)用鏈接到相應(yīng)的DLL文件上。應(yīng)用程序的項(xiàng)目必須為鏈接程序指定所需的輸入庫（LIB文件）。而且應(yīng)用程序事實(shí)上必須至少包含一個(gè)對DLL函數(shù)的調(diào)用。

　　二、與DLL模塊建立鏈接

　　應(yīng)用程序?qū)牒瘮?shù)與DLL文件中的導(dǎo)出函數(shù)進(jìn)行鏈接有兩種方式：隱式鏈接和顯式鏈接。所謂的隱式鏈接是指在應(yīng)用程序中不需指明DLL文件的實(shí)際存儲路徑，程序員不需關(guān)心DLL文件的實(shí)際裝載。而顯式鏈接與此相反。

　　采用隱式鏈接方式，程序員在建立一個(gè)DLL文件時(shí)，鏈接程序會自動生成一個(gè)與之對應(yīng)的LIB導(dǎo)入文件。該文件包含了每一個(gè)DLL導(dǎo)出函數(shù)的符號名和可選的標(biāo)識號，但是并不含有實(shí)際的代碼。LIB文件作為DLL的替代文件被編譯到應(yīng)用程序項(xiàng)目中。當(dāng)程序員通過靜態(tài)鏈接方式編譯生成應(yīng)用程序時(shí)，應(yīng)用程序中的調(diào)用函數(shù)與LIB文件中導(dǎo)出符號相匹配，這些符號或標(biāo)識號進(jìn)入到生成的EXE文件中。LIB文件中也包含了對應(yīng)的DLL文件名（但不是完全的路徑名），鏈接程序?qū)⑵浯鎯υ贓XE文件內(nèi)部。當(dāng)應(yīng)用程序運(yùn)行過程中需要加載DLL文件時(shí)，Windows根據(jù)這些信息發(fā)現(xiàn)并加載DLL，然后通過符號名或標(biāo)識號實(shí)現(xiàn)對DLL函數(shù)的動態(tài)鏈接。

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

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

　　下面是應(yīng)用程序?qū)υ搶?dǎo)出函數(shù)的顯式鏈接的例子：

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);//調(diào)用該DLL函數(shù)

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

　　三、使用符號名鏈接與標(biāo)識號鏈接

　　在Win16環(huán)境中，符號名鏈接效率較低，所有那時(shí)標(biāo)識號鏈接是主要的鏈接方式。在Win32環(huán)境中，符號名鏈接的效率得到了改善。Microsoft現(xiàn)在推薦使用符號名鏈接。但在MFC庫中的DLL版本仍然采用的是標(biāo)識號鏈接。一個(gè)典型的MFC程序可能會鏈接到數(shù)百個(gè)MFC DLL函數(shù)上。采用標(biāo)識號鏈接的應(yīng)用程序的EXE文件體相對較小，因?yàn)樗槐匕瑢?dǎo)入函數(shù)的長字符串符號名。
四、編寫DllMain函數(shù)

　　DllMain函數(shù)是DLL模塊的默認(rèn)入口點(diǎn)。當(dāng)windows/" target=_blank>Windows加載DLL模塊時(shí)調(diào)用這一函數(shù)。系統(tǒng)首先調(diào)用全局對象的構(gòu)造函數(shù)，然后調(diào)用全局函數(shù)DLLMain。DLLMain函數(shù)不僅在將DLL鏈接加載到進(jìn)程時(shí)被調(diào)用，在DLL模塊與進(jìn)程分離時(shí)（以及其它時(shí)候）也被調(diào)用。下面是一個(gè)框架DLLMain函數(shù)的例子。

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

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

　　五、模塊句柄

　　進(jìn)程中的每個(gè)DLL模塊被全局唯一的32字節(jié)的HINSTANCE句柄標(biāo)識。進(jìn)程自己還有一個(gè)HINSTANCE句柄。所有這些模塊句柄都只有在特定的進(jìn)程內(nèi)部有效，它們代表了DLL或EXE模塊在進(jìn)程虛擬空間中的起始地址。在Win32中，HINSTANCE和HMODULE的值是相同的，這個(gè)兩種類型可以替換使用。進(jìn)程模塊句柄幾乎總是等于0x400000，而DLL模塊的加載地址的缺省句柄是0x10000000。如果程序同時(shí)使用了幾個(gè)DLL模塊，每一個(gè)都會有不同的HINSTANCE值。這是因?yàn)樵趧?chuàng)建DLL文件時(shí)指定了不同的基地址，或者是因?yàn)榧虞d程序?qū)LL代碼進(jìn)行了重定位。
模塊句柄對于加載資源特別重要。Win32 的FindResource函數(shù)中帶有一個(gè)HINSTANCE參數(shù)。EXE和DLL都有其自己的資源。如果應(yīng)用程序需要來自于DLL的資源，就將此參數(shù)指定為DLL的模塊句柄。如果需要EXE文件中包含的資源，就指定EXE的模塊句柄。

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

　　六、應(yīng)用程序怎樣找到DLL文件

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

　　1． 包含EXE文件的目錄，
　　2． 進(jìn)程的當(dāng)前工作目錄，
　　3． Windows系統(tǒng)目錄，
　　4． Windows目錄，
　　5． 列在Path環(huán)境變量中的一系列目錄。

　　這里有一個(gè)很容易發(fā)生錯(cuò)誤的陷阱。如果你使用VC＋＋進(jìn)行項(xiàng)目開發(fā)，并且為DLL模塊專門創(chuàng)建了一個(gè)項(xiàng)目，然后將生成的DLL文件拷貝到系統(tǒng)目錄下，從應(yīng)用程序中調(diào)用DLL模塊。到目前為止，一切正常。接下來對DLL模塊做了一些修改后重新生成了新的DLL文件，但你忘記將新的DLL文件拷貝到系統(tǒng)目錄下。下一次當(dāng)你運(yùn)行應(yīng)用程序時(shí)，它仍加載了老版本的DLL文件，這可要當(dāng)心！

　　七、調(diào)試DLL程序

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

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

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

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

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

　　實(shí)際上線程運(yùn)行而進(jìn)程不運(yùn)行。兩個(gè)進(jìn)程彼此獲得專用數(shù)據(jù)或內(nèi)存的唯一途徑就是通過協(xié)議來共享內(nèi)存塊。這是一種協(xié)作策略。下面讓我們分析一下任務(wù)管理器里的進(jìn)程選項(xiàng)卡。

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

　　第四列，CPU時(shí)間，是CPU被進(jìn)程中的線程累計(jì)占用的小時(shí)、分鐘及秒數(shù)。請注意，我對進(jìn)程中的線程使用占用一詞。這并不一定意味著那就是進(jìn)程已耗用的CPU時(shí)間總和，因?yàn)椋缥覀円粫簩⒖吹降模琋T計(jì)時(shí)的方式是，當(dāng)特定的時(shí)鐘間隔激發(fā)時(shí)，無論誰恰巧處于當(dāng)前的線程中，它都將計(jì)算到CPU周期之內(nèi)。通常情況下，在大多數(shù)NT系統(tǒng)中，時(shí)鐘以10毫秒的間隔運(yùn)行。每10毫秒NT的心臟就跳動一下。有一些驅(qū)動程序代碼片段運(yùn)行并顯示誰是當(dāng)前的線程。讓我們將CPU時(shí)間的最后10毫秒記在它的帳上。因此，如果一個(gè)線程開始運(yùn)行，并在持續(xù)運(yùn)行8毫秒后完成，接著，第二個(gè)線程開始運(yùn)行并持續(xù)了2毫秒，這時(shí)，時(shí)鐘激發(fā)，請猜一猜這整整10毫秒的時(shí)鐘周期到底記在了哪個(gè)線程的帳上？答案是第二個(gè)線程。因此，NT中存在一些固有的不準(zhǔn)確性，而NT恰是以這種方式進(jìn)行計(jì)時(shí)，實(shí)際情況也如是，大多數(shù)32位操作系統(tǒng)中都存在一個(gè)基于間隔的計(jì)時(shí)機(jī)制。請記住這一點(diǎn)，因?yàn)椋袝r(shí)當(dāng)你觀察線程所耗用的CPU總和時(shí)，會出現(xiàn)盡管該線程或許看上去已運(yùn)行過數(shù)十萬次，但其CPU時(shí)間占用量卻可能是零或非常短暫的現(xiàn)象，那么，上述解釋便是原因所在。上述也就是我們在任務(wù)管理器的進(jìn)程選項(xiàng)卡中所能看到的基本信息列。

     摘要: 簡述組件的定義  閱讀全文      摘要: 如題  閱讀全文      摘要: 如題  閱讀全文      摘要: swt調(diào)用系統(tǒng)程序  閱讀全文      摘要: 記錄使用java進(jìn)行網(wǎng)絡(luò)編程時(shí)遇到的問題  閱讀全文      摘要:   閱讀全文      摘要: 如題  閱讀全文      摘要: 如題  閱讀全文