一 ,Hits對象是搜索結果的集合 主要有下面幾個方法 [list=1]
length() ,這個方法記錄有多少條結果返回(lazy loading)
doc(n) 返回第n個記錄
id(in) 返回第n個記錄的Document ID
score(n) 第n個記錄的相關度(積分)
由于搜索的結果一般比較大，從性能上考慮，Hits對象并不會真正把所有的結果全部取回，默認情況下是保留前100個記錄(對于一般的搜索引擎,100個記錄足夠了).
分頁的處理
100條記錄還是太多，我們多半會每頁顯示20條記錄，然后分為若干頁顯示，對于分頁，一般有兩個辦法
[list=1]
在session中保留indexreader對象和hit對象，翻頁的時候提取內容
不使用session，每次都簡單處理為重新查詢
lucene推薦先使用第二個辦法，即每次都重新查詢，這樣做的好處是簡單方便，不需要考慮session的問題，lucene的查詢效率也能保證每次查詢時間不長，除非真正有了性能問題，否則不用考慮第一個辦法。
Lucene面向全文檢索的優化在于首次索引檢索后，并不把所有的記錄（Document）具體內容讀取出來，而起只將所有結果中匹配度最高的頭100條
結果（TopDocs）的ID放到結果集緩存中并返回，這里可以比較一下數據庫檢索：如果是一個10,000條的數據庫檢索結果集，數據庫是一定要把所有
記錄內容都取得以后再開始返回給應用結果集的。所以即使檢索匹配總數很多，Lucene的結果集占用的內存空間也不會很多。對于一般的模糊檢索應用是用不
到這么多的結果的，頭100條已經可以滿足90%以上的檢索需求。
如果首批緩存結果數用完后還要讀取更后面的結果時Searcher會再次檢索并生成一個上次的搜索緩存數大1倍的緩存，并再重新向后抓取。所以如果構造一
個Searcher去查1－120條結果，Searcher其實是進行了2次搜索過程：頭100條取完后，緩存結果用完，Searcher重新檢索再構造
一個200條的結果緩存，依此類推，400條緩存，800條緩存。由于每次Searcher對象消失后，這些緩存也訪問那不到了，你有可能想將結果記錄緩
存下來，緩存數盡量保證在100以下以充分利用首次的結果緩存，不讓Lucene浪費多次檢索，而且可以分級進行結果緩存。
Lucene的另外一個特點是在收集結果的過程中將匹配度低的結果自動過濾掉了。這也是和數據庫應用需要將搜索的結果全部返回不同之處。
我的一些嘗試：
|
ExtJS教程-
Hibernate教程-
Struts2 教程-
Lucene教程