Lucene 4.0 的關鍵詞：
架構解耦，索引結構可定製化，索引結構透明化，向搜索框架方向發展。
Lucene 4.0 正式版亮點功能：
一、通過解碼器Codec 機制 Lucene 索引格式與Lucene架構解耦，變成了Plugin方式實現，包括：Terms , Postings lists ,Stored 字段,Term Vectors 等都可以以自定義的格式予以支持。
正如Mysql支持多種存儲引擎一樣，現在Lucene也可以了。
二、排序相關的算法與向量空間模型解耦(即Lucene中經典的經典的(TF/IDF)模型)。同時提供：最佳匹配 Okapi BM 25，隨機分歧 (Divergence from Randomness )，語言模型和基於信息量的模型。 不同的算法模型可以組合串聯起來使用，這等於完全解放了Lucene的生產力！。
三、新的DocValues類型可以爲每個文檔提供存儲額外的類型數據。類似：PayLoad, 可以在用這個特性自定義排序打分參數。
四、IndexWriter 寫入索引到硬盤支持完全併發，之前IndexWriter在應用層能多線程調用，但在寫入硬盤的時候還是逐個線程順序寫入的。這對於經常要重建索引的場景，減少了等待索引的時間。
具體圖形化的演示，請參考我之前的一片文章： http://blog.csdn.net/accesine960/article/details/6780068
五、每個Document的標準化因子 norms 不再侷限於一個字節。自定義排序的實現可以使用任何DocValues類型的排序因子。
六、索引結構更加透明化，增加了索引統計機制，利用這些統計信息，Lucene索引內容不再是一個黑匣子了。
包括： 提供針對term或者Field的token數量，針對某個filed的Posting數量，包含某個field的positing的文檔數量。當然有了這些索引統計的數據後，就可以自定義的改進評分機制了。
也就是說以下方法將會成爲你的新朋友：
TermsEnum.docFreq()，TermsEnum.totalTermFreq()，Fields.getUniqueTermCount()，Fields.getUniqueFieldCount()
七、索引term不再侷限於UTF-16的字符格式，Lucene 4.0中 term 可以是任何二進制數值(java中的byte數組)。默認情況下文本類term是UTF-8字節方式存儲。
八、在搜索時使用Filter效率有大幅提升
九、針對索引merge線程添加了IO限速機制，減少搜索線程與合併索引線程引起的IO爭用現象。
十、由於架構的解耦，增加了一系列可插拔和可替換的模塊，包括：
A: 添加編碼器codec：針對類 Hadoop DFS 的文件系統提供。
B: 內存編碼器codec：把所有的term和posting放到一個內存中的FST（有限狀態機），針對內存型應用提升了搜索速度。
C: 脈衝編碼器codec:主要利用了 Zipf 定律，根據term的頻率，把頻率達到制定閾值的term以inline的方式存儲。
瞭解c++ inline 函數的同學，應該知道inline對於提升函數調用速度的威力吧。
D: 明文編碼器codec: Lucene的索引結構爲了提升效率，從來都是一個黑匣子。現在這個黑匣子可以以明文的方式存儲了。
很顯然這個編碼器主要是調試、演示用的。估計很多需要寫論文的同學們很樂意使用這個功能。
E: Bloom編碼器codec: 國內很多人把Bloom翻譯爲布隆，我還是喜歡直接用英文的Bloom。
關於什麼是Bloom 參考我之前的一片文章：http://blog.csdn.net/accesine960/article/details/1491483
F：直接編碼器 codec : 由這個名字可以看到，這個編碼器是爲提升效率用的，主要針對高內存需求類的場景定製的。
G: 塊解碼器 codec: 使用了一個新的索引結構和壓縮模式schema。
十一、Term 偏移量可以選擇與Postings list存儲在一起。
十二、新增AutomatonQuery ，用來返回所有Term匹配有限狀態機文章列表
十三、FuzzyQuery 查詢速度提升了100-200倍。
十四、新增拼寫檢查器DirectSpellChecker，新的拼寫檢查器不需要單獨的索引，能夠直接使用主索引。
十五、 運行中的內存數據結構優化，包括：term 目錄，FiledCache 等。
以：500萬wekipedia數據爲例 3.x 索引時需要600M內存，4.x 索引時需要 200M內存。
十六、所有的搜索邏輯現在針對每個segment上工作。IndexReaer 也被完全重構，變成了：Atomic 和 Composite Reader。
這個變化比較大，我們知道Lucene在生成索引的時候會先生成小的Segment然後逐漸合併成大的Segment。Lucene的所有結構和組件都是以多個Segment爲導向進行設計架構的。爲搜索多個Segment需要MultiReader，而多Reader的會導致在搜索TermEnum 或者 Postings 的時候搜索效率的下降。因此新的Reader去掉了MultiReader，以Atomic和Composite Reader 代替。
十七、Lucene 4.0 提供了模塊化的API。 以模塊化的方式提供了非結構化信息管理分析器 和空間信息搜索模塊