lucene原理及源码解析--核心类
马云说：大家还没搞清PC时代的时候，移动互联网来了，还没搞清移动互联网的时候，大数据时代来了。
然而，我看到的是：在PC时代搞PC的，移动互联网时代搞移动互联网的，大数据时代搞大数据的，都是同一伙儿人。
我就是一个做业务方向的，而回忆起真正做技术的时光，也就是大数据时代刚来临的时候做搜索了。
搜索用的是solr框架，solr就是包装了lucene实现了近实时索引。所以源头还是lucene。而且lucene是java写的全文检索库，源码是一定要研究一下的。
刚才提到全文检索，要说它的概念先来谈谈数据。数据分为结构化数据和全文数据。对于没有什么固定格式的全文数据的检索就是全文检索了。
对全文数据的搜索最原始的做法是顺序扫描。就是找一个开始从头到尾的匹配，匹配对了就记录一下，然后继续扫直到结束。Windows的搜索功能就是这么做的。
顺序扫描很慢，想要加快其搜索速度就要让数据高度有序，即结构化。这种从全文中提取重新组织的信息称为索引。而lucene做的只有两件事：建立索引和搜索索引。目前lucene的最新版是6.4.1，但本文的版本是我当初使用的使用的版本4.10.1. 记得那时每月都有新版，我跟追剧似的追了好久。
首先说建立索引：打开文件目录，这个目录可以是磁盘或者是内存。遍历里面的文件，将每个文件的一个字段存成一个Field对象（相当于关系型数据库的列），一条记录存成一个Document（相当于关系型数据库的行），写入IndexWriter里。
打开目录用的FSDirectory对象的open函数。这个函数是一个Directory的工厂(工厂模式)，其实打开类型的文件也是和环境进行了适配的，也可以理解为适配器模式。研究任何一种源码都离不开其设计模式的。
今天先介绍几个核心的类。因为放在冰箱里的水果被人偷吃了好多，宝宝不开心。下次记得一定要把袋子系好口，尽量往里面放。所以今天多打算多些几行代码，忘掉我那可爱的苹果，桂圆和小金桔。苹果总共就四个，是谁那么狠心忍心拿走一个啊[大哭][大哭]拿走我的橙子以为我数不出来吗，不知道我记性好啊，看一眼就知道几个了啊。下次能不能拿点我看不出来的啊？你吃了我的东西给我留个条啊？没准我知道你来不及吃早饭还给你送吃的过去呢，不带这么不客气的！世界上最遥远的距离，是你我同在一个办公室里，你偷吃了我的水果，我却不知道你是谁。
Lucene核心类
lucene-core里这几个package列出了lucene核心做的几件事情：解析，解码，存储格式，索引，搜索，存储和工具类。
这里面最好理解的是document包的内容：
这里面所有以Field结尾的类就是定义字段格式的。除了各种Field，包里就剩下Document用于存放Field和几个字段格式的工具类。值得注意的是里面有一个DocumentStoredFieldVisitor。我们一般类命名除了类的功能属性外，还有一种常见的结尾，就是设计模式名。这个类一看就知道是运用了访问者模式。源码很简单：
public class DocumentStoredFieldVisitor extends StoredFieldVisitor {
private final Document doc = new Document(); private final Set<String> fieldsToAdd;
public DocumentStoredFieldVisitor(Set<String> fieldsToAdd) { this.fieldsToAdd = fieldsToAdd; }
/** Load only fields named in the provided fields. */ public DocumentStoredFieldVisitor(String... fields) { fieldsToAdd = new HashSet<>(fields.length); for(String field : fields) { fieldsToAdd.add(field); } }
/** Load all stored fields. */ public DocumentStoredFieldVisitor() { this.fieldsToAdd = null; }
@Override public void binaryField(FieldInfo fieldInfo, byte[] value) throws IOException { doc.add(new StoredField(fieldInfo.name, value)); }
@Override public void stringField(FieldInfo fieldInfo, String value) throws IOException { final FieldType ft = new FieldType(TextField.TYPE_STORED); ft.setStoreTermVectors(fieldInfo.hasVectors()); ft.setIndexed(fieldInfo.isIndexed()); ft.setOmitNorms(fieldInfo.omitsNorms()); ft.setIndexOptions(fieldInfo.getIndexOptions()); doc.add(new Field(fieldInfo.name, value, ft)); }
@Override public void intField(FieldInfo fieldInfo, int value) { doc.add(new StoredField(fieldInfo.name, value)); }
@Override public void longField(FieldInfo fieldInfo, long value) { doc.add(new StoredField(fieldInfo.name, value)); }
@Override public void floatField(FieldInfo fieldInfo, float value) { doc.add(new StoredField(fieldInfo.name, value)); }
@Override public void doubleField(FieldInfo fieldInfo, double value) { doc.add(new StoredField(fieldInfo.name, value)); }
@Override public Status needsField(FieldInfo fieldInfo) throws IOException { return fieldsToAdd == null || fieldsToAdd.contains(fieldInfo.name) ? Status.YES : Status.NO; }
public Document getDocument() { return doc; } }
访问者模式把数据结构和作用于结构上的操作解耦合，使得操作集合可相对自由地演化。具体到这个类就是不管是什么类型的数据，我都把它添加到Document对象里。
store这个包主要是做IO的：
这里面值得注意是在做IO的时候用到了LockFactory，一个锁工厂。这是典型的工厂模式自不必说。它的主要作用是防止读写Directory的并发。下面是BaseDirectory的源码：
public abstract class BaseDirectory extends Directory {
volatile protected boolean isOpen = true;
protected LockFactory lockFactory;
/** Sole constructor. */ protected BaseDirectory() { super(); }
@Override public Lock makeLock(String name) { return lockFactory.makeLock(name); }
@Override public void clearLock(String name) throws IOException { if (lockFactory != null) { lockFactory.clearLock(name); } }
@Override public void setLockFactory(LockFactory lockFactory) throws IOException { assert lockFactory != null; this.lockFactory = lockFactory; lockFactory.setLockPrefix(this.getLockID()); }
@Override public LockFactory getLockFactory() { return this.lockFactory; }
@Override protected final void ensureOpen() throws AlreadyClosedException { if (!isOpen) throw new AlreadyClosedException("this Directory is closed"); }
}
BaseDirectory基本上就做了一件事：就是管理锁工厂。下面重点来说一下Directory相关的类：
还是Type Hierarchy更直观些：
从上面两个图可以看出Directory的直接子类就只有BaseDirectoy和FilterDirectory两个。 其中FilterDirectory的子类都是给Directory添加附加的功能：TrackingDirectoryWrapper是记录文件的写入或删除；NRTCachingDirectory是提供对RAMDirectory的缓存，达到近实时的效果(NRT：near real time)；RateLimitedDirecotyWrapper是通过IOContext来限制读写速率。这些都是装饰器模式的代表。
BaseDirectory的子类中，FileSwitchDirectory针对lucene的不同的索引文件使用不同的Directory；CompoundFileDirectory用于访问一个组合的数据流；RAMDirectory是常驻内存的Directory实现。FSDirectory是文件系统的Directory（FS：File System ），它的三种实现：SimpleFSDirectory,它的并发支持能力有限；NIOFSDirectory支持默认线程安全的多线程读取；MMapDirectory是通过内存映射读取的Directory。
下面是analysis包，这个是用来分词的，我在当初做项目的时候用的是IK分词器。因为歪果仁的分词器对中文的支持不太好，什么自带的标准分词器啥的都是一个个字就是一个分词了。中国人比较人性化的是基于词典的分词器。标准分词器在对姓名这种组合词组没有什么意义的时候有用。所以在做垂直搜索的时候，可以对不同的列采用不同的分词器。比如一篇文章存成一个Document，里面有不同的Field。标题和内容是TextField，可以用基于词典的分词器拆分。发表时间是一个LongField（我记得我当初用的时候没有专门的时间Field）不可拆分，可以排序。标题可以是StringField不可拆分，也可以用TextField标准分词器来拆分分词，看业务需求。
因为现在看的创建索引的过程，那么index那个包里先只看IndexWriter。代码比较多，我就不贴源码了。
一个IndexWriter对象只创建并维护一个索引。IndexWriter通过Directory以及Analyzer来构建，给它画个类图还是很有意义的：
话说咱也是会用UML建模工具的，只是觉得手绘比较快，显然歪果仁和我有同样的见解，他们还专门起个名字叫:freehand
Lucene打开一个IndexWriter就会把它Lock住，不释放，再次访问就会抛出Lock obtain timed out异常。Document写入索引文件的时候也是先写入小的segment分段索引然后再按一定机制合并的。我在运行的时候，会观察磁盘的变化。比如:能发现在IndexWriter在打开后磁盘会多出一个write.lock文件。IndexWriter关闭时文件被删除。你还可以看到分段文件到大索引文件的合并过程。还可以对比全文数据到索引文件大小的变化。