寫，執行緒2往build_index2，。。。依次類推，最後乙個幹完的將build_index1-4目錄的索引合併到
build_index.
我開了4個執行緒嘗試發現也要花大概7-8分鐘，合併索引的過程非常快20秒左右。
開了10個執行緒，整個過程需要6分多鐘，合併索引也只花了21秒。
似乎效果並不明顯,這因該是因為資料量還不夠大引起的,資料量越大,並行的優勢會越明顯
可見合併索引的過程非常快，這又提供了另外的好處，我們通常將build_index作為搜尋目錄，就像上面說的那樣，建索引的過程 會影響搜尋（雖然按照書上說是不影響的），如果我們採用這種方案，建索引的絕大部分過程其實與build_index目錄無關，只有最後 合併的時候需要用到build_index，但那個過程又非常的快速，所以可以極大的緩解建索引給搜尋帶來的問題。
順便說：當然你也可以再開乙個通知執行緒專門等待索引執行緒，當索引執行緒完畢之後加入通知執行緒的佇列，通知執行緒發現自己的佇列有通知記錄就開始合併索引，這樣就不用所有的執行緒完畢之後才開始合併索引。（這種方案待嘗試）
如果條件允許，你可以擴充套件一下這個方案，將多執行緒索引公升級為多台機器同時建。
lucene並行建索引解決方案
背景 單執行緒為30萬條資料建索引花了10分鐘，為了提高效率採用多執行緒 起初我採用多個執行緒共享乙個indexwriter例項 也意味著往同乙個目錄寫索引 這是luceneinaction和lucenewiki的推薦做法，不知道到為什麼總是報filenotfoundexception，很讓人困惑。...
lucene並行建索引解決方案
背景 單執行緒為30萬條資料建索引花了10分鐘，為了提高效率採用多執行緒 起初我採用多個執行緒共享乙個indexwriter例項 也意味著往同乙個目錄寫索引 這是 lucene in action 和lucene wiki的推薦做法，不知道到為什麼總是報filenotfoundexception，很...
多版本（ 30）並行控制的解決方案
之前也寫了和轉了一些解決方案，發現並沒有乙個能完全符合自己需求的方式，於是在現有的方案中取各家精華，盡量規避各種坑，形成了現在的管理模式，可以看做 是 fork 機制的另一種實現方式。fork 是同乙個賬戶只能 對同乙個專案 fork 一次，無法滿足我的要求 單版本庫多分支簡直滅絕人性，分支數量多到...