反向索引：

正向索引（草稿，不完全，因為收到field info的影響，不同的field存儲內容不同，且fieldInfo的有些信息,TOKENIZED BINARY COMPRESSED也是保存在.fdt的每個document相關段的bits中,而不是.fnm中）:

Lucene在1.9版本的時候就已經加入了對GCJ的支持，利用GCJ編譯Lucene，并且使用新的GCJIndexInput.java讀寫文件系統，
直接調用操作系統級別的native方法，相信讀寫性能能夠極大得提高啊。

具體代碼可見Lucene的gcj目錄，編譯使用ant gcj

說明見Similarity.java的javadoc信息：


算法請參考javadoc的，它使用的是Vector Space Model (VSM) of Information Retrieval。

Lucene的索引文件，會包含很多個segments文件，每個segment中包含多個documents文件，一個segment中會有完整的正向索引和反向索引。
在搜索時，Lucene會遍歷這些segments，以segments為基本單位獨立搜索每個segments文件，而后再把搜索結果合并。

建立索引文件的過程，實際就是把documents文件一個個加入索引中，Lucene的做法是最開始為每個新加入的document獨立生成一個segment，放在內存中。而后，當內存中segments數量到達一個闕值時，合并這些segments，新生成一個segment加入文件系統的segments列表中。
而當文件系統的segments數量過多時，勢必影響搜索效率，因此需要不斷合并這些segments文件。

那么Lucene的合并策略是什么？如何保證合適的segments數量呢？

其實Lucene有兩套基本的策略：
第一種策略實現代碼位于IndexWriter#optimize()函數，其實就是把所有segments文件合并成一個文件。合并的算法是遞歸合并列表最后的mergeFactor個segments文件直到合并成一個文件。這兒mergeFactor是Lucene的一個參數。
btw: 從算法細節上看，其實我不是喜歡這段實現，因為列表的最后mergeFactor個文件內容實際被掃描了segmens_count/mergeFactor次。如果分段歸納合并的方式不知道是否更好，每個segment文件內容都將被掃描 ceil(Log_mergeFactor(segmens_count)) 或ceil(Log_mergeFactor(segmens_count)) +1次，是否更好?

第二種策略實現代碼位于IndexWriter#maybeMergeSegments()函數中，這個代碼就復雜了，它的基本策略就是要求確保合并后兩個公式的成立:
假定segments是個有序列表，B表示maxBufferedDocs，f(n)=ceil(log_M(ceil(n/B)))，M表示mergeFactor，這兒maxBufferedDocs和mergeFactor是兩個參數
1. 如果第i個segment的documents數量為x，第i+1個segment的documents數量為y，那么f(x)>f(y)一定成立
2. f(n)值相同的segments的數量不得超過M。
那么maybeMergeSegments()函數是如何確保這兩個公式成立的呢?
1.首先，從代碼：
這兒minMergeDocs=maxBufferedDocs, 因此可以看出，當內存中緩存的segments被合并寫回磁盤時生成的segment的document count等于或小于maxBufferedDocs（即minMergeDocs）。
補充：因為maybeMergeSegments()運行在同步代碼中，因此只要ramSegmentInfos.size==minMergerDocs(即maxBufferedDocs)就會寫回磁盤，因此應該不存在ramSegmentInfos.size>maxBufferedDocs才寫回的情況。而且，但如果是這種情況，因為合并后的segment文件的document count過大，后面的maybeMergeSegments()將不做合并處理直接退出，上述公式就可能不成立，那么算法將有錯。
----
2.
2.1 因此maybeMergeSegments()第一次執行時，所有segments的document count都小于等于maxBufferedDocs。此時，從i=0開始，合并i~i+mergeFactor-1個文件，如果合并后的doc count>maxBufferedDocs時，保留第i個segment，否則繼續合并改變后的i~i+mergeFactor-1，直到doc count>maxBufferedDocs或所有segments文件個數已經<mergeFactor了。經過這樣一輪的合并，除了最后<mergeFactor個的doc counts<=maxBufferedDocs文件外，其它文件的doc counts一定都>maxBufferedDocs并<maxBufferedDocs*mergeFactor了。
 2.2 這時，不理會最后<mergeFactor個doc count<maxBufferedDocs的文件，而后按2.1的同理規則，合并之前的文件，讓這些文件的最后<mergerFactor個segment符合 maxBufferedDocs<doc counts<=maxBufferedDocs*mergeFactor，之前的segment文件都符合maxBufferedDocs*mergeFactor<doc counts<=maxBufferedDocs*mergeFactor^2
2.3 重復2.2，最后得到的列表就會滿足上述兩等式的成立
---
3
之后，每次從內存緩存中flush出一個新的segment時，也就是往這個segments列表的最后增加一個doc_count<=maxBufferedDocs的文件，同樣執行上述步驟2進行合并，能夠始終保證上述兩公式的成立。
----
4
4.1
IndexWriter#addIndexesNoOptimize同樣借鑒使用了maybeMergeSegments()算法，區別此時，實際是已有一個符合兩公式的segments序列T，在T之后追加上隨意順序的segments序列S。這時，我們先找到S中doc count值最大的那個segment，計算出它屬于的區間f(x)，使得maxBufferedDocs*mergeFactor^x<doc counts<=maxBufferedDocs*mergeFactor^(x+1)，而后按2.2的算法合并出除了最后<mergerFactor個segments外， 之前所有segments都符合 a. doc count>maxBufferedDocs*mergeFactor^(x+1) b.符合上述2等式。
btw: 因為這兒調用IndexWriter#addIndexesNoOptimize傳入的參數是maxBufferedDocs*mergeFactor^(x+1)，因為S所有segment的doc count都一定小于maxBufferedDocs*mergeFactor^(x+1)，因此S的所有元素都會參與收縮合并。
4.2 將最后<mergerFactor個doc count<maxBufferedDocs*mergeFactor^(x+1)的segments合并，如果合并后的segment的doc count大于maxBufferedDocs*mergeFactor^(x+1)，就繼續2.2步驟，使得整個隊列符合上述兩公式
-----

上述兩種策略，最終確保了Lucene中的segments不會太多,確保效率。

BTW：實際上，如果documents太多時，Lucene還支持把docuements分成幾個組，每個組用獨立的進程或電腦進行索引，而后再多個目錄的索引合并起來，具體可參考IndexWriter#addIndexesNoOptimize和IndexWriter#addIndexes函數

FieldSelectorResult:枚舉，分別為
        LOAD Document#getFieldable和Document#getField不會返回null
        LAZY_LOAD :Lazy的Field意味著在搜索結果里這個Field的值缺省是不讀取的，只有當你真正對這個Field取值的時候才會去取。所以如果你要對它取值，你得保證IndexReader還沒有close。 Document#getField不能使用，只能使用Document#getFieldable
        NO_LOAD Document#getField和Document#getFieldable都返回null，Document#add不被調用。
        LOAD_AND_BREAK 類似LOAD，Document#getField和Document#getFieldable都可用，但返回后就結束，Document可能沒有完整的field的Set，參考LoadFirstFieldSelector 。
        LOAD_FOR_MERGE 類似LOAD，但不壓縮任何數據。只被SegmentMerger的一個FieldSelector匿名內嵌實現類使用。Document#getField和Document#getFieldable可返回null.
        SIZE 返回Field的size而不是value. Size表示存儲這個field需要的bytes數，string數值使用2*chars。size被存儲為a binary value，表現為as an int in a byte[]，with the higher order byte first in [0]。
        SIZE_AND_BREAK 類似SIZE，但立刻break from the field loading loop, i.e. stop loading further fields, after the size is loaded

======================================

Field中三大enum: Store Index和TermVector：

       ------------------------------------
        Store.COMPRESS  Store the original field value in the index in a compressed form. This is useful for long documents and for binary valued fields.壓縮存儲；
        Store.YES Store the original field value in the index. This is useful for short texts like a document's title which should be displayed with the results. The value is stored in its original form, i.e. no analyzer is used before it is stored. 索引文件本來只存儲索引數據, 此設計將原文內容直接也存儲在索引文件中，如文檔的標題。
        Store.NO  Do not store the field value in the index. 原文不存儲在索引文件中，搜索結果命中后，再根據其他附加屬性如文件的Path，數據庫的主鍵等，重新連接打開原文，適合原文內容較大的情況。
        決定了Field對象的 this.isStored 和        this.isCompressed
     ------------------------------------
        Index.NO Do not index the field value. This field can thus not be searched, but one can still access its contents provided it is Field.Store stored. 不進行索引，存放不能被搜索的內容如文檔的一些附加屬性如文檔類型, URL等。
        Index.TOKENIZED Index the field's value so it can be searched. An Analyzer will be used to tokenize and possibly further normalize the text before its terms will be stored in the index. This is useful for common text. 分詞索引
        Index.UN_TOKENIZED  Index the field's value without using an Analyzer, so it can be searched. As no analyzer is used the value will be stored as a single term. This is useful for unique Ids like product numbers. 不分詞進行索引，如作者名，日期等，Rod Johnson本身為一單詞，不再需要分詞。

        Index.NO_NORMS 不分詞，建索引。norms是什么???字段值???。但是Field的值不像通常那樣被保存，而是只取一個byte，這樣節約存儲空間???? Index the field's value without an Analyzer, and disable the storing of norms.  No norms means that index-time boosting and field length normalization will be disabled.  The benefit is less memory usage as norms take up one byte per indexed field for every document in the index.Note that once you index a given field <i>with</i> norms enabled, disabling norms will have no effect.  In other words, for NO_NORMS to have the above described effect on a field, all instances of that field must be indexed with NO_NORMS from the beginning.
        決定了Field對象的 this.isIndexed  this.isTokenized  this.omitNorms
     ------------------------------------
        Lucene 1.4.3新增的：
        TermVector.NO Do not store term vectors.  不保存term vectors
        TermVector.YES Store the term vectors of each document. A term vector is a list of the document's terms and their number of occurences in that document. 保存term vectors。
        TermVector.WITH_POSITIONS Store the term vector + token position information 保存term vectors。（保存值和token位置信息）
        TermVector.WITH_OFFSETS Store the term vector + Token offset information
        TermVector.WITH_POSITIONS_OFFSETS Store the term vector + Token position and offset information 保存term vectors。（保存值和Token的offset）
        決定了Field對象的this.storeTermVector this.storePositionWithTermVector this.storeOffsetWithTermVector

Closure: http://en.wikipedia.org/wiki/Closure_%28computer_science%29
我還比較喜歡Microsoft的一段說明，位于鏈接http://msdn.microsoft.com/msdnmag/issues/07/09/BasicInstincts/Default.aspx?loc=zh中，查找“Lambda 表達式和變量提升”

最早接觸Closure是在學javascript, 前年還寫了篇關于Closure對javascript內存泄露的文章http://m.tkk7.com/tim-wu/archive/2006/05/29/48729.html
一直以為這就是函數式語言的特性，頂多就是.net的委托和它有幾分相識，
沒想到現在Java7也要支持了，有興趣的朋友可以去讀讀：
http://www.javac.info/
沒細讀，不知道Lambda在Java這種強類型檢查的語言中表現的如何。

作為函數語言，Ruby中一直都有closure的用法，http://samdanielson.com/2007/3/19/proc-new-vs-lambda-in-ruby有個簡單例子。

 最近，ruby 1.9又提供了新的定義lambda

參見 http://www.infoq.com/cn/news/2008/01/new-lambda-syntax

VB 2008也支持了，這個鏈接有個例子，又是Lambda，又是范型，，又是委托回調，很有意思：
http://msdn.microsoft.com/msdnmag/issues/07/09/BasicInstincts/Default.aspx?loc=zh
VB中“需要注意的一點限制是，lambda 表達式完全就是一個單個表達式。在 Visual Basic 2008 中，您在 lambda 表達式中只能有一個單個表達式。在本專欄中，我將進一步向您展示 Visual Basic 2008 中引入的一個新的三元運算符，它將允許您構造條件表達式，但目前的功能不支持在 lambda 表達式中使用任意語句。”