【lucene】MMapDirectory 在FSDirectory基础上干了啥？
一句话：
**MMapDirectory 只是把 “读写文件” 从普通的 FileChannel I/O 换成了 mmap（内存映射），其余所有逻辑（文件创建、删除、锁、pending_segments 处理等）都和 FSDirectory 共用同一套代码**。
---
### 1. FSDirectory 已经做了什么
FSDirectory 提供了：
- 创建/打开/删除文件的统一实现（createOutput / openInput / deleteFile）
- 对 pendingDeletes、文件锁、临时文件的处理
- 可插拔的 `FSIndexOutput`/`FSIndexInput` 实现（用 `FileChannel.read/write` 做真正的 I/O）
---
### 2. MMapDirectory 只改了 I/O 实现
```java
public final class MMapDirectory extends FSDirectory {
...
@Override
public IndexInput openInput(String name, IOContext context) throws IOException {
ensureOpen();
Path path = directory.resolve(name);
// 用 mmap 而不是 FileChannel.read
return new MMapIndexInput(name, path, chunkSizePower, preload, useUnmapHack);
}
/* IndexOutput 仍然是 FSIndexOutput（FileChannel.write），
因为 mmap 写文件需要 RandomAccessFile + rw，且性能不一定更好，
Lucene 只在“读”路径用 mmap，“写”路径保留 FileChannel。 */
}
```
- **读文件** → `MMapIndexInput`：把文件映射到 `MappedByteBuffer`，后续读操作就是内存访问。
- **写文件** → 仍用 `FSIndexOutput`（FileChannel.write），因为：
- mmap 写需要 `RandomAccessFile` + `MapMode.READ_WRITE`，且每次扩展文件长度要重新映射，成本高；
- 写通常是顺序大块写入，FileChannel 反而更快。
---
### 3. 额外提供的调优参数
MMapDirectory 额外暴露：
- `setPreload(true)`：在 map 后立即 `madvise(MADV_WILLNEED)`，减少首次访问缺页。
- `setUseUnmapHack(true)`：用 Cleaner 或 Unsafe 手动 `unmap`，避免 64-bit JVM 下映射残留导致 “无法删除文件” 的问题（Windows 上尤其重要）。
---
### 总结对比
| 维度 | FSDirectory 默认实现 | MMapDirectory |
|-----------------|----------------------|------------------------------------|
| Directory 框架 | ✅ 同一套 | ✅ 继承 FSDirectory |
| 读文件 | FileChannel.read | mmap（MappedByteBuffer） |
| 写文件 | FileChannel.write | 同 FSDirectory（未用 mmap） |
| 额外调优 | 无 | preload、unmapHack、chunkSizePower |
| 适用场景 | 通用 | 读多写少，64-bit、大索引、随机查 |
因此：**MMapDirectory = FSDirectory + 读路径换成 mmap，其余完全复用**。
对，**在 open reader 的环节差异最大**：
1. 当你调用
`DirectoryReader.open(directory)` 或 `IndexReader.open(...)`
最终都会走到 `SegmentCoreReaders` → `openInput(name, IOContext.READONCE / RANDOM / MERGE)` 去为每个段文件（`.cfs`, `.fdx`, `.tim`, `.doc`, …）创建 `IndexInput`。
2. 如果目录是：
- **FSDirectory** → 返回 `FSIndexInput`，底层是 `FileChannel.read`
- **MMapDirectory** → 返回 `MMapIndexInput`，底层是 `MappedByteBuffer`（mmap）
3. **差异只在读阶段**
- 写文件时两者都走 `FSIndexOutput`（FileChannel.write），没有 mmap。
- 因此只有 **reader 打开后** 的随机访问、倒排表遍历、跳表查询等读操作，才会体验到 mmap 带来的：
- 地址空间直接映射，减少一次内核→用户空间拷贝
- 大文件分段映射，降低 GC 压力
- 预读/缓存效果由 OS 页缓存自动完成
4. **对上层 API 没区别**
上层代码（`IndexSearcher.search`, `TermsEnum`, `StoredFields`…）感知不到，只是底层 `IndexInput` 实现不同。
一句话：**writer 阶段无差异；reader 阶段因 mmap 而提速，尤其随机读多的查询**。