同事调整了IndexWriterConfig的maxThreadStates參数，发现性能有非常大提升，原来之前一直没去注意这个东西。
addDocument时默认会调用ThreadAffinityDocumentsWriterThreadPool来获取线程锁,而这个线程池默认是8个线程，假设同一时候addDocument的线程多于8个，则线程处在等待锁的状态(通常是等最小竞争的>锁)，所以本质上要在indexwriterconfig中添加最大索引线程数。
Lucene中还存在一个FlushStallControl,用于平衡addDocument和flush之间的速度差,假设flushBytes + activeBytes > 2 * ramBytes，且flushBytes > 0,则addDocument线程被暂停，直到flush完毕。这有一个启示。最好监控下等待时间,假设等待时间太长，是不是考虑硬盘换一下?
另外使用LogByteMergePolicy的确比LogDocMergePolicy好，原因是这样内存平稳一点，表现略好。RamBufferSize是个非常微妙的參数,理论上越大,索引归并的趟数越少，有利于降低归并时间,对建索引本身速度的影响。考虑addDocument和flush的平衡这一瓶颈，假设硬盘使用ssd(即等待时间变得超短,并且非常少等待)。段应该大一点好?
这好像非常难说清。从小索引測试结果来看，200M左右性能最好。