lucene4.5源码分析系列：索引缓存以及刷新-优快云博客

缓存和刷新是比较重要的问题，它涉及到lucene如何管理内存和磁盘。前面提到索引的结果是缓存在内存中的，等到一定时候才会将其刷新到硬盘上去。缓存在这里的目的无非是缓解高速设备到低速设备的不匹配。下面这些问题都比较重要：调用增删改索引后此时索引时已经写入磁盘还是仍然驻留内存，即索引的刷新时间是什么？其次，缓存会占用多少内存？另外，刷新的效率如何？最后，lucene允许多个线程并发刷新索引，具体实现是怎么做的？

flush的一个总入口是DocumentWriter中的doFlush，随后严格按照索引链层层向下传递，直到FreqProxTermWriter的flush方法，FreqProxTermWriter中最后会调用如下语句，将所有对索引文件的操作交给codec去做。

[java]view plaincopy
      
state.segmentInfo.getCodec().postingsFormat().fieldsConsumer(state).write(fields);

那么到底哪些地方会调用flush呢？实际上，下面这5个地方都会最终调用到flush，可以发现，这5个地方已经涵盖了对索引的大部分操作，可见flush的重要。

从源码上看，addIndexes, forceMerge, close和commit4个操作都是进行full flush，入口为DocumentWriter.flushAllThreads，他们会对所有active的DocumentsWriterPerThread进行flush；而updateDocument则只会flush一个DocumentsWriterPerThread。

在lucene中，flush是由DocumentsWriterFlushControl来统一控制的，好处就是统一入口，便于维护和管理。这个控制器用了很多方式来保持其扩展灵活性以及健壮性。

刷新时机策略

DocumentsWriterFlushControl中有一个FlushPolicy。我们每次更新文档都需要将缓存内容写入磁盘吗？如果每次索引的内容只有几十字节，那么频繁写入其实是不划算的，会带来极大的开销，也就失去使用缓存的意义了。FlushPolicy就是定义了这个刷新时机的策略，默认策略在FlushByRamOrCountsPolicy中定义。如下图，我们可以看出来，FlushByRamOrCountsPolicy中实际上有3种方式来控制缓存的刷新。

其中flushOnRAM会在删除或者插入时被应用，也就是内存达到设定值时候才允许刷新；flushOnDocCount则只在插入时生效，即文档数达到设定值生效；flushOnDeleteTerms在删除时的缓存大于设定值时生效；而这3个设定值分别对应indexWriterConfig中的RAMBufferSizeMB，MaxBufferedDocs, MaxBufferedDeleteTerms。也就是说，我们可以通过控制这几个值来控制刷新的方式。因而一旦设定了RAMBufferSizeMB这种刷新方式，则缓存占用的最大内存就是RAMBufferSizeMB

[java]view plaincopy
      
    
public void onDelete(DocumentsWriterFlushControl control, ThreadState state) {  
  if (flushOnDeleteTerms()) {  
    // Flush this state by num del terms  
    final int maxBufferedDeleteTerms = indexWriterConfig  
        .getMaxBufferedDeleteTerms();  
    if (control.getNumGlobalTermDeletes() >= maxBufferedDeleteTerms) {  
      control.setApplyAllDeletes();  
    }  
  }  
  if ((flushOnRAM() &&  
      control.getDeleteBytesUsed() > (1024*1024*indexWriterConfig.getRAMBufferSizeMB()))) {  
    control.setApplyAllDeletes();  
   if (infoStream.isEnabled("FP")) {  
     infoStream.message("FP", "force apply deletes bytesUsed=" + control.getDeleteBytesUsed() + " vs ramBuffer=" + (1024*1024*indexWriterConfig.getRAMBufferSizeMB()));  
   }  
 }  
}  
  
public void onInsert(DocumentsWriterFlushControl control, ThreadState state) {  
  if (flushOnDocCount()  
      && state.dwpt.getNumDocsInRAM() >= indexWriterConfig  
          .getMaxBufferedDocs()) {  
    // Flush this state by num docs  
    control.setFlushPending(state);  
  } else if (flushOnRAM()) {// flush by RAM  
    final long limit = (long) (indexWriterConfig.getRAMBufferSizeMB() * 1024.d * 1024.d);  
    final long totalRam = control.activeBytes() + control.getDeleteBytesUsed();  
    if (totalRam >= limit) {  
      if (infoStream.isEnabled("FP")) {  
        infoStream.message("FP", "flush: activeBytes=" + control.activeBytes() + " deleteBytes=" + control.getDeleteBytesUsed() + " vs limit=" + limit);  
      }  
      markLargestWriterPending(control, state, totalRam);  
    }  
  }  
}  

健康管理
在多线程下，有可能出现索引线程的速度快于刷新线程的速度，积累下去很容易导致JVM内存耗尽。

DocumentsWriterFlushControl中的DocumentsWriterStallControl便是用来做健康管理的。所谓的健康管理，就是在索引线程速度过快时阻塞索引线程，从而保证内存的占用不会持续上涨。判断是否需要健康管理的程序如下

[java]view plaincopy
      
    
final boolean stall = ((activeBytes + flushBytes) > limit)  &&  
                          (activeBytes < limit) &&  
                          !closed;  

FlushAllThreads

具体到一次完全刷新具体做了什么事，可以参考下图，实际上主要就是3件事，首先做一些准备工作，因为刷新是非常复杂的过程，当中涉及多线程操作以及状态的变化，所以需要mark，接下来对每个pending状态的DocumentsWriterPerThread做flush，最后是等待所有flush结束。

markForFullFlush这个方法实际上有如下这些步骤。实际上这个方法有许多多线程处理的技巧，都是为了尽可能的少用锁。

1. 确定删除队列。这里会新建一个generation加1的删除队列来替换原来的删除队列，而后续操作则使用老的删除队列，这么做无非是想在fullFlush时可以同时做其他操作比如删除而不用整个锁住。

2. 改变每个待刷新的ThreadState的状态，从active变为flushing。这步其实还有一个最重要的操作，就是internalTryCheckOutForFlush，他的机制就是将所有checkout的ThreadState放到一个Map（flushingWriters）中，这样就类似上了锁，只要在Map中的都是已经加锁的，比每次加锁判断要高效。

3. 对blockedFlushes阻塞的每个DocumentWriterPerThread，将其状态设置为flushing并从blockedFlushes中删除。

4. 准备好flushQueue，主要就是将上面步骤中fullFlushBuffer搜集到的DocumentWriterPerThread全部填充到flushQueue中

5. 更新健康状态，这步就是去判断是否需要健康管理。

如图，实际的刷新工作是多个线程并发的做，他们都会调用doFlush，很有意思的一点是它会把每次刷新作为一个ticket放到ticketQueue中来管理，这样会有一个统一地方获知正在刷新的ticket，也便于上锁等操作。在flush结束时会进入doAfterFlush，这里会将前面的flushingWriters删除本次flush用的DocumentsWriterPerThread，然后更新健康管理的状态并且使用notifyAll来通知其他等待的线程（主要就是waitForFlush的等待线程）。至于doFlush中实际如何顺着索引链向下的调用，这里就不细细说明了，整体流程到这里已经比较清楚，需要细节可以自行查阅相关代码。