lucene 源码小析

lucene3.0

源代码流程：   index
IndexWriter:
1， setMessageID:  基本没用
2， DocumentWriter: 写多个document的writer。
3， directory.clearLock        NativeFSLockFactory    
（其中Directory的生成根据系统
if (Constants.WINDOWS) {
      return new SimpleFSDirectory(path, lockFactory);
    } else {
      return new NIOFSDirectory(path, lockFactory);
    }
）

4， Lock writeLock = directory.makeLock   (NativeFSLockFactory来完成clearlock和getlock）
5， writeLock.obtain(writeLockTimeout)     也就是说我觉得以上工作都只是init一个lock，但是并没有去obtain

6， if create is true:        以下读取的应该是原有的directory中的index
7， Segmentinfo seg = new Segmentinfos();
8， clear();         把以前的segment clear
9， checksum;   应该是核查文件的正确性
10， lastgeneration = generation = generationFromSegmentFileName(String filename);    generation是个int
11， int format = input.readInt();   格式都是负数，至于保存在哪个文件中，目前还未知，应该是Segments那个
if(format < 0){     // file contains explicit format info
        // check that it is a format we can understand
        if (format < CURRENT_FORMAT)
          throw new CorruptIndexException("Unknown format version: " + format);
        version = input.readLong(); // read version
        counter = input.readInt(); // read counter
      }
      else{     // file is in old format without explicit format info
        counter = format;
      }

if(format >= 0){    // in old format the version number may be at the end of the file
        if (input.getFilePointer() >= input.length())
          version = System.currentTimeMillis(); // old file format without version number
        else
          version = input.readLong(); // read version
      }

12，segmentInfos.clear();      应该是读取之前存在的directory之后执行的clear()操作
13，deleter = new IndexFileDeleter
14，pushMaxBufferedDocs();       这个似乎只是让LogDocMergePolicy设置一个minMergeSize
final MergePolicy mp = mergePolicy;
LogDocMergePolicy lmp = (LogDocMergePolicy) mp;
lmp.setMinMergeDocs(maxBufferedDocs);

addDocument:
1, DocumentsWriter:
# 得到一个线程，在lucene2.3之后，DocumentWriter多线程写document
final DocumentsWriterThreadState state = getThreadState(doc, delTerm);
state.consumer.processDocument();
processDocument方法里面 startDocument              好像没有什么用

重要：
init:  DocFieldProcessorPerThread extends DocConsumerPerThread
DocFieldProcessorPerField       单独的class
DocFieldConsumersPerThread extends DocFieldConsumerPerThread
DocInverterPerThread extends DocFieldConsumerPerThread
DocFieldConsumersPerField extends DocFieldConsumerPerField
DocInverterPerField extends DocFieldConsumerPerField
调用过程：
DocFieldProcessorPerThread 调用DocFieldConsumerPerThread 作为自己的consumer
然后调用DocFieldProcessorPerField 处理每一个Field的hash和QuictSort
然后调用每一个Field的Consumer，也就最终是DocInverterPerField 的processFields方法

2, finishDocument(state, perDoc);        完成后续工作，具体内容没完全看完。
其中第一步进行   balanceRam    系统中有3块内存，posting table, byte blocks, char blocks. 应该是调节3者的平衡，因为一个document如果分词太多，可能占据了posting 的绝大部分。
3, flush(boolean triggerMerge, boolean flushDocStores, boolean flushDeletes);     
ensureOpen(false)
doFlush() doFlushInternal    做了很多flush、delete、写混合index等工作，还有flush后处理工作以及checkpoint();
docwriter.clearFlushPending
maybeMerge()
updatePendingMerges              做一个merge前准备工作
mergeScheduler.merge(this);   this表示DocumentsWriter


optimize               没有仔细看，主要工作就是merge
如文档所说，optimize(boolean doWait)      ： you can specify whether the call should block until the optimize completes          应该指的是在optimize完成之前，整个indexwriter的call被block了。
代码：
if (doWait)
      synchronized(this)

close
从文档看因为lock的原因，如果在close过程中发生Exception，即使是在flush部分后发生Exception，也一样会保证原disk上的index不变
另外，从eg看writer.close()都只是放在try中，而没有放在finally中


IndexReader.deleteDocument(int doc)/deleteDocuments(Term term)
本质调用doDelete()
DirectoryReader.doDelete()      调用subReader，也就是segmentReader
SegmentReader.doDelete()     
     deletedDocs.getAndSet(docNum)    实际上在deleteDocs这个BitVector中添加要删除的docNum
和IndexWriter一样，close的时候会提交一个commit，commit的工作很多，包括减少本身(IndexReader)引用，用IndexFileDeleter删除需要删除的文件等等。pending的工作，正好和上面的doDelete符合，上面的doDelete删除的时候，如果失败，就会添加到pending中。

重要：
这里有一个结构很不错： 例子中IndexReader实际上是DirectoryReader，通过以下方法调用SegmentReader。这种自身不同类别调用，方法得到重用，结构清晰。
for (int i = 0; i < subReaders.length; i++)
        subReaders[i].commit();        subReader即segmentReader

另外，整个lucene中用了很多checkpoint机制，例如startCommit()即开始一个checkpoint。这样一旦出错，可以rollback.   例如在IndexReader.close的时候，DirectoryReader.commit --> startCommit --> segmentReader(startCommit) -->  segmentReader.commit --> if (!success) rollbackCommit --> segmentReader.rollbackCommit




Deleter:
几个重要的方法：
1, deleter.checkpoint
2, deleter.close
3, deleter.refresh