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

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

2) 有了關(guān)鍵詞后，我們就可以建立倒排索引了。上面的對(duì)應(yīng)關(guān)系是：“文章號(hào)”對(duì)“文章中所有關(guān)鍵詞”。倒排索引把這個(gè)關(guān)系倒過(guò)來(lái)，變成：“關(guān)鍵詞”對(duì)“擁有該關(guān)鍵詞的所有文章號(hào)”。文章1，2經(jīng)過(guò)倒排后變成
關(guān)鍵詞 文章號(hào)
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）查詢(xún)快），lucene中記錄的就是這種位置。

加上“出現(xiàn)頻率”和“出現(xiàn)位置”信息后，我們的索引結(jié)構(gòu)變?yōu)椋?
關(guān)鍵詞 文章號(hào)[出現(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 這行為例我們說(shuō)明一下該結(jié)構(gòu)：live在文章1中出現(xiàn)了2次，文章2中出現(xiàn)了一次，它的出現(xiàn)位置為“2,5,2”這表示什么呢？我們需要結(jié)合文章號(hào)和出現(xiàn)頻率來(lái)分析，文章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沒(méi)有使用B樹(shù)結(jié)構(gòu)），因此lucene可以用二元搜索算法快速定位關(guān)鍵詞。

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

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

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

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

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

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

　　一般來(lái)說(shuō)，DLL是一種磁盤(pán)文件（通常帶有DLL擴(kuò)展名），它由全局?jǐn)?shù)據(jù)、服務(wù)函數(shù)和資源組成，在運(yùn)行時(shí)被系統(tǒng)加載到進(jìn)程的虛擬空間中，成為調(diào)用進(jìn)程的一部分。如果與其它DLL之間沒(méi)有沖突，該文件通常映射到進(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ù)制了自己的讀/寫(xiě)全局變量。如果想要與其它進(jìn)程共享內(nèi)存，必須使用內(nèi)存映射文件或者聲明一個(gè)共享數(shù)據(jù)段。DLL模塊需要的堆棧內(nèi)存都是從運(yùn)行進(jìn)程的堆棧中分配出來(lái)的。

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

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

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

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

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

__declspec(dllexport) int MyFunction(int n);

　　但也可以在模塊定義(DEF)文件中列出導(dǎo)出函數(shù)，不過(guò)這樣做常常引起更多的麻煩。在應(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)目必須為鏈接程序指定所需的輸入庫(kù)（LIB文件）。而且應(yīng)用程序事實(shí)上必須至少包含一個(gè)對(duì)DLL函數(shù)的調(diào)用。

　　二、與DLL模塊建立鏈接

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

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

　　顯式鏈接方式對(duì)于集成化的開(kāi)發(fā)語(yǔ)言（例如VB）比較適合。有了顯式鏈接，程序員就不必再使用導(dǎo)入文件，而是直接調(diào)用Win32 的LoadLibary函數(shù)，并指定DLL的路徑作為參數(shù)。LoadLibary返回HINSTANCE參數(shù)，應(yīng)用程序在調(diào)用GetProcAddress函數(shù)時(shí)使用這一參數(shù)。GetProcAddress函數(shù)將符號(hào)名或標(biāo)識(shí)號(hà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文件都會(huì)在應(yīng)用程序EXE文件加載時(shí)被加載在到內(nèi)存中；但如果采用顯式鏈接方式，程序員可以決定DLL文件何時(shí)加載或不加載。顯式鏈接在運(yùn)行時(shí)決定加載哪個(gè)DLL文件。例如，可以將一個(gè)帶有字符串資源的DLL模塊以英語(yǔ)加載，而另一個(gè)以西班牙語(yǔ)加載。應(yīng)用程序在用戶(hù)選擇了合適的語(yǔ)種后再加載與之對(duì)應(yīng)的DLL文件。

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

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

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

　　一般來(lái)說(shuō)，DLL是一種磁盤(pán)文件（通常帶有DLL擴(kuò)展名），它由全局?jǐn)?shù)據(jù)、服務(wù)函數(shù)和資源組成，在運(yùn)行時(shí)被系統(tǒng)加載到進(jìn)程的虛擬空間中，成為調(diào)用進(jìn)程的一部分。如果與其它DLL之間沒(méi)有沖突，該文件通常映射到進(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ù)制了自己的讀/寫(xiě)全局變量。如果想要與其它進(jìn)程共享內(nèi)存，必須使用內(nèi)存映射文件或者聲明一個(gè)共享數(shù)據(jù)段。DLL模塊需要的堆棧內(nèi)存都是從運(yùn)行進(jìn)程的堆棧中分配出來(lái)的。

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

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

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

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

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

__declspec(dllexport) int MyFunction(int n);

　　但也可以在模塊定義(DEF)文件中列出導(dǎo)出函數(shù)，不過(guò)這樣做常常引起更多的麻煩。在應(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)目必須為鏈接程序指定所需的輸入庫(kù)（LIB文件）。而且應(yīng)用程序事實(shí)上必須至少包含一個(gè)對(duì)DLL函數(shù)的調(diào)用。

　　二、與DLL模塊建立鏈接

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

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

　　顯式鏈接方式對(duì)于集成化的開(kāi)發(fā)語(yǔ)言（例如VB）比較適合。有了顯式鏈接，程序員就不必再使用導(dǎo)入文件，而是直接調(diào)用Win32 的LoadLibary函數(shù)，并指定DLL的路徑作為參數(shù)。LoadLibary返回HINSTANCE參數(shù)，應(yīng)用程序在調(diào)用GetProcAddress函數(shù)時(shí)使用這一參數(shù)。GetProcAddress函數(shù)將符號(hào)名或標(biāo)識(shí)號(hà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文件都會(huì)在應(yīng)用程序EXE文件加載時(shí)被加載在到內(nèi)存中；但如果采用顯式鏈接方式，程序員可以決定DLL文件何時(shí)加載或不加載。顯式鏈接在運(yùn)行時(shí)決定加載哪個(gè)DLL文件。例如，可以將一個(gè)帶有字符串資源的DLL模塊以英語(yǔ)加載，而另一個(gè)以西班牙語(yǔ)加載。應(yīng)用程序在用戶(hù)選擇了合適的語(yǔ)種后再加載與之對(duì)應(yīng)的DLL文件。

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

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

　　DllMain函數(shù)是DLL模塊的默認(rèn)入口點(diǎn)。當(dāng)windows/" target=_blank>Windows加載DLL模塊時(shí)調(diào)用這一函數(shù)。系統(tǒng)首先調(diào)用全局對(duì)象的構(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;//成功
}

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

　　五、模塊句柄

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

　　但是在使用這些句柄之前存在一個(gè)問(wèn)題，你怎樣得到它們呢？如果需要得到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將遵循下面的搜索順序來(lái)定位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)目開(kāi)發(fā)，并且為DLL模塊專(zhuān)門(mén)創(chuàng)建了一個(gè)項(xiàng)目，然后將生成的DLL文件拷貝到系統(tǒng)目錄下，從應(yīng)用程序中調(diào)用DLL模塊。到目前為止，一切正常。接下來(lái)對(duì)DLL模塊做了一些修改后重新生成了新的DLL文件，但你忘記將新的DLL文件拷貝到系統(tǒng)目錄下。下一次當(dāng)你運(yùn)行應(yīng)用程序時(shí)，它仍加載了老版本的DLL文件，這可要當(dāng)心！

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

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

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

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

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

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

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

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

     摘要: 簡(jiǎn)述組件的定義  閱讀全文      摘要: 如題  閱讀全文      摘要: 如題  閱讀全文      摘要: swt調(diào)用系統(tǒng)程序  閱讀全文