3.4 讀寫并發

在一個時刻只能夠有一個線程修改索引庫。Lucene通過鎖文件控制并發訪問。在Lucene 2.1版本以后，控制寫入的鎖文件write.lock默認存儲在index路徑。

如果出現多余的鎖文件，則有可能會拋出Lock obtain timed out異常。如果確定沒有線程在修改索引，可以手工刪除write.lock文件。

例如，當全文索引放在只讀光盤中時，需要設置這個索引只讀。只讀索引的初始化設置如下：

        Directory indexDir =
            FSDirectory.getDirectory(indexPath, NoLockFactory.getNoLockFactory());

如果一臺機器用來索引的同時也用來執行搜索，就不會預熱reader，這樣的后果會是災難性的。當搜索的時候，用戶會突然經歷長時間的延時。因為一個大的合并能花費數小時，這樣就意味著突然搜索性能變差達數小時。

因為Java沒有暴露底層的API，例如文件咨詢信息(posix_fadvise)、內存咨詢信息和對齊控制(posix_madvise)，所以要使用一個小的JNI擴展來改進性能。操作系統級別的功能應該能修復這個問題。

要僅僅在合并索引的時候完全忽略所有的操作系統緩存，可以通過使用Linux特定的O_DIRECT標志實現。合并索引的性能會變差，因為操作系統不再做預讀也不寫緩存，每個I/O請求都會接觸到硬盤。但這可能是一個很好的折中。

有些類似的應用，例如視頻解碼，可能不需要緩存。因此創建了一個原型Directory實現，一個DirectNIOFSDirectory的變體。LUCENE-2056使用O_DIRECT打開所有的輸入和輸出文件，這是通過JNI實現的。因為所有的I/O都必須用某種規則對齊，所以實現代碼有點亂。

由于按順序讀，Linux傾向于趕出已經加載的頁面。

這個方法工作得很好。在執行索引優化時，搜索性能沒有改變。

但是，優化階段的時間從1336秒延長到了1680秒(慢了26%)。可以通過增加緩存來減少優化所需的時間，或者創建自己的預讀/寫緩存模式。