【正文】 息，包括名字（name）、含有的文檔的數(shù)目（docCount）和段所位于的目錄的位置（dir）。根據(jù)索引文件中的段的意義，有了這三點(diǎn)，就能唯一確定一個(gè)段了。SegmentInfos這個(gè)類則是用來(lái)表示一個(gè)段的鏈表（），實(shí)際上，也就是索引（index）的意思了。需要注意的是，這里并沒有在SegmentInfo中安插一個(gè)文檔（document）的鏈表。這樣做的原因牽涉到Lucene內(nèi)部對(duì)于文檔（相當(dāng)于一個(gè)被索引文件）的處理；Lucene內(nèi)部采用了賦予文檔編號(hào)，給域賦值的方式來(lái)處理文檔，即加入的文檔順次編號(hào)，以后用文檔號(hào)表示文檔，而路徑信息，文件名字等等在以后索引查找需要的屬性，都作為域存儲(chǔ)下來(lái)；因此SegmentInfo中并沒有另外存儲(chǔ)一個(gè)文檔（document）的鏈表，對(duì)于這些的寫出和讀入，則交給了永久化的代理類來(lái)做。圖UML圖（八）（segment）的讀入操作的代理類，而負(fù)責(zé)段（segment）的寫出操作也同樣沒有定義，這些操作都直接實(shí)現(xiàn)在了類IndexWriter類中（后面會(huì)詳細(xì)分析）。段的操作同樣采用了之前的數(shù)組或者說是緩沖的處理方式，相關(guān)的細(xì)節(jié)也不在這里詳細(xì)敘述了。然后，針對(duì)前面項(xiàng)（term）那部分定義的幾個(gè)接口，段（segment）這部分也需要做相應(yīng)的接口實(shí)現(xiàn)，因?yàn)樘峁┲苯颖闅v訪問段中的各個(gè)項(xiàng)的能力對(duì)于檢索來(lái)說，無(wú)疑是十分重要的。即這部分的設(shè)計(jì)，實(shí)際上都是在為了檢索在服務(wù)。圖UML圖（九）圖UML圖（十）（term）那里定義的接口是如何在這里通過繼承實(shí)現(xiàn)的。Lucene在處理這部分的時(shí)候，也是分成兩部分（Segment與Segments開頭的類）來(lái)實(shí)現(xiàn)，而且很合理的運(yùn)用了數(shù)組的技法，以及注意了繼承重用。但是細(xì)化到局部，終歸是比較簡(jiǎn)單的按照語(yǔ)義來(lái)獲得結(jié)果而已了，因此關(guān)于更多的也就不多做分析了，我們完全可以通過閱讀源代碼來(lái)解決。接下來(lái)所介紹的，就是在Lucene的設(shè)計(jì)過程中比較特殊的一個(gè)部分：段合并類（SegmentMerger）。這首先需要介紹Lucene中的建立索引時(shí)的段合并策略。Lucene為了兼顧建立索引時(shí)的效率和讀取索引查找的速度，引入了分小段建立索引的方式，即每一次批量建立索引時(shí)，先在內(nèi)存中的虛擬文件系統(tǒng)中為每一個(gè)文檔單獨(dú)建立一個(gè)段，然后在輸出的時(shí)候?qū)⑦@些段合并之后輸出成為索引文件，這時(shí)僅僅存在一個(gè)段。多次建立的索引后，如果想優(yōu)化索引文件，也可采取合并段的方法，將索引中的段合并成為一個(gè)段。我們來(lái)看一下在IndexWriter類中相應(yīng)的方法的實(shí)現(xiàn)，來(lái)了解一下這中建立索引的實(shí)現(xiàn)。對(duì)于上面的代碼，我們不做過多注釋了，結(jié)合源碼中的注解應(yīng)該很容易理解。在最后那個(gè)mergeSegments函數(shù)中，將用到幾個(gè)重要的類結(jié)構(gòu)，它們記錄了合并時(shí)候的一些重要信息，完成合并時(shí)候的工作。接下來(lái)，我們來(lái)看這幾個(gè)類的UML圖。圖UML圖（十一），我們看到Lucene設(shè)計(jì)一個(gè)類SegmentMergeInfo用來(lái)保存每一個(gè)被合并的段的信息，也保存能夠訪問其內(nèi)部的接口句柄，也就是說合并時(shí)的操作使用這個(gè)類作為對(duì)被合并的段的操作代理。，做為SegmentMergeInfo的容器類，而且附帶能夠自動(dòng)排序。SegmentMerger是主要進(jìn)行操作的類，里面各個(gè)方法環(huán)環(huán)相扣，分別完成合并各個(gè)數(shù)據(jù)項(xiàng)的問題。5．IndexReader類與IndexWirter類最后剩下的，就是整個(gè)索引邏輯部分的使用接口類了。外界通過這兩個(gè)類以及文檔（document）類的構(gòu)造函數(shù)調(diào)用之。下面我們來(lái)看一下這部分最后兩個(gè)類的UML圖。圖UML圖（十二）IndexWriter的設(shè)計(jì)與IndexReader的設(shè)計(jì)很不相同，前者是一個(gè)實(shí)現(xiàn)類，而后者是一個(gè)抽象類，帶有沒有實(shí)現(xiàn)的接口。IndexWriter的主要作用就是接收新加入的文檔（document），然后在內(nèi)部為之生成相應(yīng)的小段，最后再合并并向索引文件中輸出。由于Lucene在面向?qū)ο笊戏庋b的努力，通過各個(gè)構(gòu)造函數(shù)就已經(jīng)完成了對(duì)于各個(gè)概念的構(gòu)造過程，剩下部分的代碼主要是依據(jù)各個(gè)數(shù)組或者是鏈表中的信息，逐個(gè)逐個(gè)的將信息寫出到相應(yīng)的文件中去了。IndexReader部分則只是做了接口設(shè)計(jì)，沒有具體的實(shí)現(xiàn)，這個(gè)和本部分所完成的主要功能有關(guān)：索引構(gòu)建邏輯。設(shè)計(jì)這個(gè)抽象類的目的是，預(yù)先完成一些函數(shù)，為以后的檢索（search）部分的各種形式的IndexReader鋪平道路，也是利用了在同一個(gè)包內(nèi)可以方便訪問其它類的保護(hù)變量這個(gè)java語(yǔ)言的限制。到此，在索引構(gòu)建邏輯部分出現(xiàn)的類我們就分析完畢了，需要說明主要是做的一個(gè)宏觀上的組成結(jié)構(gòu)上的分析，并指出一些實(shí)現(xiàn)上的要點(diǎn)。具體的實(shí)現(xiàn)，由于Lucene的開放源碼而顯得并不是非常的重要，因?yàn)長(zhǎng)ucene在做到良好的面相對(duì)象設(shè)計(jì)之后，實(shí)際帶來(lái)的是局部復(fù)雜性的減小，因此某一些單獨(dú)的函數(shù)或者實(shí)現(xiàn)就比較容易編寫，也容易讓人閱讀。本文不再繼續(xù)敘述這方面的細(xì)節(jié)，作為一個(gè)總結(jié)，下一個(gè)部分我們通過索引構(gòu)建邏輯的數(shù)據(jù)流圖的方式，再來(lái)理清楚一下索引構(gòu)建邏輯這部分的調(diào)用時(shí)序。三、數(shù)據(jù)流邏輯從宏觀上明白一個(gè)系統(tǒng)的設(shè)計(jì)，理清楚其中的運(yùn)行規(guī)律，最好的方式應(yīng)該是通過數(shù)據(jù)流圖。在分析了各個(gè)位于索引構(gòu)建邏輯部分的類的設(shè)計(jì)之后，我們接下來(lái)就通過分析數(shù)據(jù)流圖的方式來(lái)總結(jié)一下。但是由于之前提到的原因：索引讀入部分在這一部分并沒有完全實(shí)現(xiàn)，所以我們?cè)跀?shù)據(jù)流圖中主要給出的是索引構(gòu)建的數(shù)據(jù)流圖。圖索引構(gòu)建部分的數(shù)據(jù)流邏輯合并輸出字節(jié)流輸入內(nèi)存文件系統(tǒng)writeNorms寫出標(biāo)準(zhǔn)化因子sortPostingTable排序位置信息writePostings寫出索引信息invertDocument分析文檔addDocument生成小段加入document對(duì)象以document對(duì)象方式傳入調(diào)用生成field對(duì)象，根據(jù)對(duì)象性質(zhì)不同，為值賦予String值，或者是Reader值生成document對(duì)象，調(diào)用add方法加入field對(duì)象通過java語(yǔ)言的io類以輸入流方式傳入，結(jié)合Lucene源代碼中的一些文件看，能夠加深理解。，因此這部分可以結(jié)合這個(gè)類的實(shí)現(xiàn)來(lái)看。至于內(nèi)存文件系統(tǒng)，比較復(fù)雜，但是這時(shí)的邏輯相對(duì)簡(jiǎn)單，因此也不難理解。上面的數(shù)據(jù)流圖十分清楚的勾畫除了整個(gè)索引構(gòu)建邏輯這部分的設(shè)計(jì)：通過層層嵌套的類結(jié)構(gòu)，在構(gòu)建時(shí)候即分步驟有計(jì)劃的生成了索引結(jié)構(gòu)，將之存儲(chǔ)到內(nèi)存中的文件系統(tǒng)中，然后通過對(duì)內(nèi)存中的文件系統(tǒng)優(yōu)化合并輸出到實(shí)際的文件系統(tǒng)中。四、關(guān)于cLucene項(xiàng)目前面的三個(gè)部分，已經(jīng)完成了分析索引構(gòu)建邏輯的任務(wù)，這里我們還是有針對(duì)性的談?wù)勎覀冞@次的畢業(yè)設(shè)計(jì)項(xiàng)目cLucene在這一部分的情況。在實(shí)現(xiàn)這部分的時(shí)候，為了將一些java語(yǔ)法中比較特殊的部分，比如內(nèi)隱類、同步函數(shù)、同步對(duì)象等等，我們不得不采用了一些比較晦澀和艱深的C++語(yǔ)法，在OpenTop這個(gè)類庫(kù)所提供的類似于java語(yǔ)言的設(shè)施上來(lái)實(shí)現(xiàn)。這個(gè)尤其體現(xiàn)在實(shí)現(xiàn)Segment相關(guān)類時(shí)，為了處理原來(lái)java源代碼中用內(nèi)隱類實(shí)現(xiàn)的Lock文件創(chuàng)建機(jī)制的時(shí)候，我們不得不定義了大量的cLucene::store::With的子類，并為之傳入調(diào)用類的指針，設(shè)置它為調(diào)用類的友元，才得以精確的模擬了原有的語(yǔ)義。陷于我們這次的重寫以移植為主，系統(tǒng)結(jié)構(gòu)基本上沒有大的變化，不得不產(chǎn)生這種重復(fù)而且大量的工作。如果需要改進(jìn)這中狀況，我們應(yīng)該考慮按照C++語(yǔ)言的特點(diǎn)來(lái)設(shè)計(jì)索引構(gòu)建部分的類庫(kù)繼承結(jié)構(gòu)，但是很可惜在本文成文之前，時(shí)間不允許我們這樣做。來(lái)自java語(yǔ)法的特殊性只是我們解決問題的一個(gè)方面，我們還需要處理引用的調(diào)用方式。由于java語(yǔ)言擁有了垃圾收集機(jī)制，因此得以將一切的參數(shù)形式看作為引用，而不考慮其分配與消亡的問題。C++語(yǔ)言并不具備這種機(jī)制，它需要程序員自行管理分配空間與銷毀對(duì)象的問題。在這里，我們使用的是來(lái)自O(shè)penTop中所引入的計(jì)數(shù)指針RefPtr模板，它能夠模擬指針的語(yǔ)義，并且計(jì)算指針被引用的次數(shù)，在引用次數(shù)為0時(shí)就自動(dòng)釋放資源：這是一種類似于java語(yǔ)言中引用的方式，不過它顯得更加高效率。我們?cè)赾Lucene的實(shí)現(xiàn)中大量的使用了計(jì)數(shù)指針模板。除此之外，我們沒有改變Lucene所定義的索引構(gòu)建邏輯的結(jié)構(gòu)和語(yǔ)義，我們實(shí)現(xiàn)的是一個(gè)完全和java版本Lucene兼容的版本。