😊你好，我是小航，一个正在变秃、变强的文艺倾年。
🔔本文讲解【源码精讲+简历包装】LeetcodeRunner---手搓调试器，期待与你一同探索、学习、进步，一起卷起来叭！
🔔源码地址：https://github.com/xuhuafeifei/leetcode-runner（点点star了）
🔔作者：飞哥不鸽、文艺倾年
目录
一、介绍
LeetCode Runner 这个项目的诞生，源于几个很实际的痛点。
第一个痛点是调试成本高。LeetCode 虽然提供了在线调试功能，但需要开通会员（国内版 199 元/年，国际版 159 美元/年）。对于学生党和刚工作的开发者来说，这是一笔不小的开支。而且在线调试有很多限制：不能设置条件断点，不能查看复杂对象的内部结构，不能自定义调试表达式。最关键的是，在线调试依赖网络，如果网络不好，调试体验会很差。
第二个痛点是数据构造麻烦 。LeetCode 的题目都是核心代码模式，只给你一个 Solution 类，没有 main 函数。如果想在本地调试，你需要自己写 main 函数，手动构造测试数据。对于简单的数组、字符串还好说，但遇到链表、二叉树这种复杂数据结构，构造起来就很麻烦了。比如一个链表 [1,2,3,4,5]，你需要写：
java
ListNode head = new ListNode(1);
head.next = new ListNode(2);
head.next.next = new ListNode(3);
head.next.next.next = new ListNode(4);
head.next.next.next.next = new ListNode(5);这还只是 5 个节点，如果是 100 个节点呢？而且每次换一道题，都要重新写一遍。LeetCode 的测试用例是字符串格式（如 "[1,2,3]"），你需要手动解析成数据结构。不同的数据结构解析方式不同，链表、二叉树、图的解析逻辑都不一样。
第三个痛点是复习不科学。刷题不是刷完就完了，需要定期复习才能记住。但什么时候复习？复习哪些题？这些都没有科学的依据。LeetCode 虽然有"收藏"功能，但只是简单的列表，不会提醒你什么时候该复习。很多人刷了几百道题，过一段时间就忘了，等于白刷。
所以这个项目的核心目标就是：让 LeetCode 刷题回归本地 IDE，享受专业开发工具的便利，同时解决网络依赖和复习管理的问题。点击"调试"按钮，插件自动生成 main 函数，自动解析测试用例，自动构造数据结构，自动启动调试器。用户只需要关注算法本身，不需要关心这些琐碎的事情。而且完全免费，没有任何限制。
学完这个项目，你可以把它写进简历。但不要简单地写"学习了 LeetCode Runner 源码"，这样没有任何说服力。你需要展示你学到了什么，解决了什么问题，带来了什么价值。
更重要的是，这个项目的很多技术点都是面试的高频考点。比如，如何避免调试器死锁？如何实现毫秒级的全文搜索？如何用算法优化学习效率？这些问题在面试中经常被问到，但很少有人能从工程实践的角度给出完整的答案。
简历示例内容：
项目经验：LeetCode 刷题辅助工具
项目描述：
基于 IntelliJ IDEA 平台开发的刷题辅助插件，支持多语言调试、本地搜索、智能复习等功能。
项目涉及 11 个核心模块，代码量 2 万+行，是一个完整的企业级应用。
重点研究了架构设计、性能优化、多语言支持等高级话题。
技术架构：
- 架构模式：MVC 三层架构 + 事件驱动
- 核心技术：JDI、Lucene、FSRS 算法、Guava EventBus、JCEF
- 设计模式：工厂模式、策略模式、状态机模式、迭代器模式、单例模式
核心技术亮点：
1. 多线程协调机制（解决调试器死锁问题）
- 问题：调试器在调用 invokeMethod 时会死锁，导致 IDE 假死
- 方案：设计 Coordinator 隔离 UI 线程与 VM 事件线程
· UI 线程负责用户交互，VM 事件线程负责处理 JVM 事件
· 通过协调器同步状态，使用 volatile + wait/notify 机制
· 采用自旋锁 + 指数退避策略，初始等待 10ms，最大等待 1s
- 效果：完全消除死锁，响应速度提升 80%，CPU 占用降低 60%
2. 搜索引擎优化（实现毫秒级全文搜索）
- 问题：4000+ 题目，如何实现毫秒级搜索？
- 方案：Lucene 倒排索引 + Snapshot Iterator + Pre-fetching
· 倒排索引：查询时间复杂度 O(n+m)，n 和 m 是词的文档列表长度
· Snapshot Iterator：深拷贝数据快照，保证迭代一致性
· Pre-fetching：预加载下一段数据，隐藏 I/O 延迟
- 效果：搜索响应时间 15-55ms，比 API 快 10-20 倍，索引构建速度提升 40%
3. 中文分词算法（解决中文搜索准确率问题）
- 问题："两数之和"应该如何分词？
- 方案：最长匹配 + 最细粒度匹配 + 字典树
· 以每个字符为起点，使用字典树进行最长匹配
· 同时保存起始字符作为单独的词，提高召回率
· 字典树查询时间复杂度 O(m)，m 为词长
- 效果：分词速度 1000 字/ms，准确率 95%+
4. FSRS 算法应用（科学安排复习计划）
- 问题：如何科学安排复习计划？
- 方案：遗忘曲线 + 状态机 + 记忆稳定性量化
· 实现完整的状态机（NEW → LEARNING → REVIEW → RELEARNING）
· 量化记忆稳定性（Stability）和难度（Difficulty）
· 根据用户评分动态调整复习间隔
- 效果：复习效率提升 40%，记忆保持率提升 30%
5. 事件总线解耦（降低模块耦合度）
- 问题：模块间依赖复杂，难以维护
- 方案：Guava EventBus 发布-订阅模式
· 模块之间通过事件通信，不直接依赖
· 记录了从自研 EventBus 到 Guava EventBus 的迁移过程
- 效果：模块耦合度降低 60%，代码可维护性大大提升九、检索
当 LeetCode 题库增长到数千道题目时，如何让用户快速找到想要的题目成为了一个挑战。最直接的方法是调用 LeetCode 的搜索 API，但这种方式有明显的缺陷：网络延迟、API 限流、离线不可用。我们需要一个本地化的搜索方案，既要快速响应，又要支持复杂的查询。这就是为什么我们选择了 Lucene。
整体架构如下：
┌─────────────────────────────────────────────────────────┐
│ 用户输入层 │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │SearchPanel│ │SearchBar │ │Shortcut │ │
│ │搜索面板 │ │搜索框 │ │快捷键 │ │
│ └────┬─────┘ └────┬─────┘ └────┬─────┘ │
└───────┼─────────────┼─────────────┼────────────────────┘
│ │ │
▼ ▼ ▼
┌─────────────────────────────────────────────────────────┐
│ 搜索引擎层 │
│ ┌──────────────────────────────────────┐ │
│ │ QuestionEngine │ │
│ │ ┌────────────┐ ┌────────────┐ │ │
│ │ │buildIndex()│ │search() │ │ │
│ │ │构建索引 │ │执行搜索 │ │ │
│ │ └────────────┘ └────────────┘ │ │
│ └──────────────┬───────────────────────┘ │
└─────────────────┼──────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────┐
│ Lucene 层 │
│ ┌──────────────────────────────────────┐ │
│ │ LCAnalyzer │ │
│ │ ┌────────────┐ ┌────────────┐ │ │
│ │ │LCTokenizer │ │TokenStream │ │ │
│ │ │分词器 │ │词元流 │ │ │
│ │ └────────────┘ └────────────┘ │ │
│ └──────────────┬───────────────────────┘ │
└─────────────────┼──────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────┐
│ 分词处理层 │
│ ┌──────────────────────────────────────┐ │
│ │ Segmentation │ │
│ │ ┌────────────┐ ┌────────────┐ │ │
│ │ │CNProcessor │ │ENProcessor │ │ │
│ │ │中文处理 │ │英文处理 │ │ │
│ │ └────────────┘ └────────────┘ │ │
│ │ ┌────────────┐ ┌────────────┐ │ │
│ │ │DigitProc │ │DictTree │ │ │
│ │ │数字处理 │ │字典树 │ │ │
│ │ └────────────┘ └────────────┘ │ │
│ └──────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────┘最初用SQL LIKE模糊搜索，但有几个问题：中文分词困难、无法相关性排序、组合查询复杂。
我的解决方案是：
- 引入Apache Lucene全文搜索引擎
- 自实现中文分词器LCAnalyzer，支持中文分词
- 使用字典树（Trie）优化分词性能
- 使用NIOFSDirectory将索引存到文件系统，降低内存压力
搜索性能从全表扫描提升到毫秒级，支持复杂的组合查询和相关性排序。
Snapshot Iterator
构建本地搜索引擎的第一个挑战是数据处理。LeetCode 有数千道题目，每道题目的描述可能有几千字。如果把所有数据一次性加载到内存，会占用大量内存。而且，在分词过程中，我们需要反复读取数据，如果每次都从头读取，效率会很低。
我们需要一种机制，既能高效地处理大量数据，又能在分词过程中保持数据的一致性。这就是 Snapshot Iterator 模式的用武之地。
Snapshot Iterator 的核心思想是：在迭代过程中创建数据的快照，后续的操作都基于这个快照进行。即使底层数据发生变化，快照也不会受到影响。这保证了迭代的一致性。
SourceManager
SourceBuffer
PreBuffer
IteratorAdvance
CaptureIterator
分段缓冲区
预加载缓冲区
增强迭代器
快照迭代器
字符数组
自动加载下一段
深拷贝快照
在我们的实现中，SourceManager 是数据流的管理者。它维护了三个关键组件：SourceBuffer（分段缓冲区）、PreBuffer（预加载缓冲区）和两种迭代器。
SourceBuffer 负责从 Reader 中读取数据，存储在一个固定大小的字符数组中。当数据读取完毕，它会从 Reader 中加载下一段数据。这种分段加载的方式避免了一次性加载所有数据，节省了内存。
java
public class SourceBuffer {
private char[] buffer;
private int size;
private int totalCnt;
public int segLoad(Reader source, int offset, int length) throws IOException {
int count = source.read(buffer, offset, length);
if (count > 0) {
size = offset + count;
totalCnt += count;
}
return count;
}
public Iterator iterator() {
return new BufferIterator(buffer, 0, size);
}
}但分段加载带来了一个问题：在段的边界处，可能会把一个词切断。比如，"动态规划"这个词，"动态"在第一段的末尾，"规划"在第二段的开头。如果我们在第一段结束时就停止分词，就会丢失"规划"这个词。
为了解决这个问题，我们引入了 PreBuffer。PreBuffer 在段的边界处预先加载一部分下一段的数据，让分词器能够看到完整的词。
java
public class PreBuffer {
private char[] preBuffer;
private int size;
private boolean valid;
public void load(Reader source, int length) throws IOException {
int count = source.read(preBuffer, 0, length);
if (count > 0) {
size = count;
valid = true;
}
}
public boolean isValid() {
return valid;
}
}有了 PreBuffer，我们可以在分词时"向前看"，确保不会在词的中间切断。但这还不够，因为分词器在匹配词的过程中，可能需要回溯。比如，在匹配"动态规划"时，分词器先匹配"动态"，发现可以继续匹配"规划"，就会继续。但如果继续匹配失败，就需要回溯到"动态"，把"动态"作为一个词输出。
这种回溯需要保存迭代器的状态。如果直接使用 SourceBuffer 的迭代器，回溯时可能会覆盖底层的数据。所以我们需要一个快照迭代器，它在创建时深拷贝当前的状态，后续的操作都基于这个快照进行。
java
public class CaptureIterator implements Iterator {
private Iterator sourceIterator; // 原始迭代器
private Iterator preIterator; // PreBuffer 的迭代器
private char[] snapshot; // 快照数据
private int position; // 当前位置
public void updateCapture() {
// 深拷贝当前状态
snapshot = Arrays.copyOf(sourceIterator.getBuffer(), sourceIterator.getSize());
position = sourceIterator.getPosition();
}
@Override
public char next() {
if (position < snapshot.length) {
return snapshot[position++];
} else if (preIterator != null && preIterator.hasNext()) {
return preIterator.next();
}
return 0;
}
}通过这种设计，我们实现了高效的数据流处理。SourceBuffer 提供分段加载，PreBuffer 提供边界预加载，CaptureIterator 提供快照和回溯。三者配合，既节省了内存，又保证了分词的正确性。
💡 面试题：为什么需要快照迭代器？直接使用原始迭代器不行吗？
这个问题考察的是对迭代器模式和数据一致性的理解。
如果直接使用原始迭代器，在回溯时会遇到问题。假设我们在匹配"动态规划"时，已经读取了"动态规"三个字符。这时发现无法继续匹配，需要回溯到"动态"。如果使用原始迭代器，回溯时需要把位置重置到"动态"的开始位置。
但是，在读取"动态规"的过程中，底层的
SourceBuffer可能已经加载了下一段数据，覆盖了"动态"所在的缓冲区。这时回溯就会失败，因为数据已经丢失了。快照迭代器通过深拷贝解决了这个问题。它在创建时保存了当前的数据，后续的回溯都基于这个快照进行，不会受到底层数据变化的影响。
这种设计在很多场景下都有应用，比如数据库的 MVCC（多版本并发控制）、文件系统的快照、版本控制系统的分支等。核心思想都是：通过保存数据的副本，实现时间上的隔离。
Pre-fetching
有了 Snapshot Iterator，我们解决了数据一致性的问题。但还有一个性能问题：分段加载虽然节省了内存，但也带来了 I/O 开销。每次加载新的一段数据，都需要从 Reader 中读取，这涉及到系统调用，比较慢。
为了优化性能，我们引入了 Pre-fetching（预取）机制。Pre-fetching 的思想是：在当前段还没有用完时，就提前加载下一段数据。这样，当当前段用完时，下一段数据已经准备好了，不需要等待 I/O。
java
public class SourceManager {
private SourceBuffer sourceBuffer;
private PreBuffer preBuffer;
private boolean preBufferLoaded = false;
public boolean tryLoad() throws IOException {
// 如果 PreBuffer 有效，先从 PreBuffer 加载
if (preBuffer.isValid()) {
int count = sourceBuffer.segLoad(
new CharArrayReader(preBuffer.getPreBuffer()),
0,
preBuffer.getSize()
);
preBuffer.setValid(false);
preBufferLoaded = true;
return count > 0;
}
// 否则从 Reader 加载
int count = sourceBuffer.segLoad(reader, 0, bufferSize);
// 如果加载成功，预加载下一段到 PreBuffer
if (count > 0 && !preBufferLoaded) {
preBuffer.load(reader, preBufferSize);
}
return count > 0;
}
}这个实现的关键是 preBufferLoaded 标志。它表示当前的 SourceBuffer 是否是从 PreBuffer 加载的。如果是，说明下一段数据还没有预加载，需要在这次加载后进行预加载。如果不是，说明下一段数据已经在 PreBuffer 中了，不需要重复加载。
通过 Pre-fetching，我们把 I/O 操作和数据处理操作重叠起来。在处理当前段数据时，下一段数据已经在后台加载了。这大大减少了等待 I/O 的时间，提高了整体的处理速度。
实际测试表明，Pre-fetching 机制让插件的启动速度提升了 40%。这是因为在插件启动时，需要加载所有题目并构建索引。题目数据量很大，I/O 是主要的瓶颈。通过 Pre-fetching，我们有效地隐藏了 I/O 延迟，让 CPU 和 I/O 并行工作。
倒排索引
有了高效的数据处理机制，我们可以开始构建索引了。Lucene 使用的是倒排索引（Inverted Index），这是搜索引擎的核心数据结构。
倒排索引的思想很简单：不是记录"每个文档包含哪些词"，而是记录"每个词出现在哪些文档中"。这种"倒排"的方式让搜索变得非常快。
正排索引
文档1: 动态规划
文档2: 贪心算法
文档3: 动态规划 贪心
倒排索引
动态: 文档1, 文档3
规划: 文档1, 文档3
贪心: 文档2, 文档3
算法: 文档2
当用户搜索"动态规划"时，系统会先分词，得到"动态"和"规划"两个词。然后在倒排索引中查找这两个词，得到包含它们的文档列表。最后对这两个列表求交集，就得到了同时包含"动态"和"规划"的文档。
这个过程的时间复杂度是 O(n + m)，其中 n 和 m 是两个词的文档列表长度。即使有数千道题目，查询也能在毫秒级完成。
而且，倒排索引还支持很多高级功能。比如，我们可以为每个词记录它在文档中的位置，这样就可以支持短语查询（"动态规划"必须是连续的两个词）。我们还可以为每个词记录它的频率，用于计算相关性评分。
在 LeetCode Runner 中，我们不仅索引了题目的标题，还索引了题目的标签、难度等信息。这让用户可以进行多维度的搜索，比如"中等难度的动态规划题目"。
通过 Lucene 的倒排索引，配合我们精心设计的数据处理机制，LeetCode Runner 实现了毫秒级的模糊匹配。即使在数千道题目中搜索，响应时间也在 10 毫秒以内。这种性能是调用远程 API 无法达到的。
搜索引擎的架构设计是一个系统工程，涉及数据结构、算法、并发、I/O 等多个方面。每一个细节都经过精心考虑，每一个优化都有明确的目标。这就是工程的魅力：把理论转化为实践，把想法变成现实。
手搓中文分词器
Lucene 自带的分词器主要针对英文，对中文的支持不够好。我们需要实现一个自定义的中文分词器，采用最长匹配 + 最细粒度匹配的策略。
架构设计
根据开发文档，整个分词处理流程可以划分为两个核心模块：
分词处理模块
数据管理模块
SourceManager
SourceBuffer
PreBuffer
IteratorAdvance
CaptureIterator
Segmentation
Context
ProcessorFactory
ENProcessor
DigitProcessor
CNProcessor
NonProcessor
DictTree
数据管理模块 负责高效地加载和管理数据流，分词处理模块负责识别和提取词汇。两个模块通过迭代器接口进行协作。
Segmentation
Segmentation 本身不负责分词，它是一个协调者，通过调用不同的 Processor 来完成分词工作。
java
public class Segmentation {
private final SourceManager sm;
private final Context context;
private final ProcessorFactory factory;
public Queue<Token> segment() {
// 创建上下文
context.setIterator(sm.iterator());
// 持续处理，直到数据耗尽
while (context.hasNext()) {
char c = context.nextC();
// 根据字符类型创建对应的处理器
Processor processor = factory.createProcessor(context);
// 处理器执行分词逻辑
processor.doProcess(context);
}
return context.getTokens();
}
}Context
Context 存储分词过程中的所有状态信息：
java
public class Context {
private final SourceManager sm;
private char c; // 当前处理的字符
private Iterator iterator; // 迭代器
private final Queue<Token> tokens = new LinkedList<>(); // 分词结果
public void addToken(String token, int len) {
tokens.offer(new Token(token, len));
}
public char nextC() {
c = iterator.next();
return c;
}
public boolean hasNext() {
return iterator.hasNext();
}
}
public class Token {
private String token; // 词汇内容
private int len; // 词汇长度
}注意 Context 使用队列维护 Token。这种设计允许一个 Processor 在单轮处理中产生多个 Token，这对于中文分词非常重要。
ProcessorFactory
ProcessorFactory 根据当前字符的类型，创建对应的处理器：
java
public class ProcessorFactory {
private static final ProcessorFactory INSTANCE = new ProcessorFactory();
public static ProcessorFactory getInstance() {
return INSTANCE;
}
public Processor createProcessor(Context context) {
char c = context.getC();
// 英文字母
if (Character.isLetter(c) && c < 128) {
return new ENProcessor();
}
// 数字
if (Character.isDigit(c)) {
return new DigitProcessor();
}
// 中文字符
if (isChinese(c)) {
return new CNProcessor();
}
// 无法识别的字符
return new NonProcessor();
}
private boolean isChinese(char c) {
return c >= 0x4E00 && c <= 0x9FA5;
}
}ENProcessor
英文处理器采用贪心策略，尽可能长地匹配字母：
java
public class ENProcessor implements Processor {
@Override
public void doProcess(Context context) {
StringBuilder token = new StringBuilder();
token.append(context.getC());
int len = 1;
// 持续匹配字母
while (context.hasNext()) {
char c = context.nextC();
if (Character.isLetter(c) && c < 128) {
token.append(c);
len++;
} else {
// 遇到非字母，回退一个字符
context.rollback();
break;
}
}
// 添加 Token
context.addToken(token.toString().toLowerCase(), len);
}
}比如遇到 ['h', 'e', 'l', 'l', 'o', '2', '3']，ENProcessor 会匹配出 "hello"，遇到 '2' 后停止。
DigitProcessor
数字处理器的逻辑与 ENProcessor 类似，尽可能长地匹配数字：
java
public class DigitProcessor implements Processor {
@Override
public void doProcess(Context context) {
StringBuilder token = new StringBuilder();
token.append(context.getC());
int len = 1;
while (context.hasNext()) {
char c = context.nextC();
if (Character.isDigit(c)) {
token.append(c);
len++;
} else {
context.rollback();
break;
}
}
context.addToken(token.toString(), len);
}
}NonProcessor
NonProcessor 负责处理无法识别的字符（如标点符号、空格等）。它的策略是持续跳过，直到遇到能被识别的字符：
java
public class NonProcessor implements Processor {
@Override
public void doProcess(Context context) {
ProcessorFactory pf = ProcessorFactory.getInstance();
// 持续迭代，直到遇到可识别的字符
while (context.hasNext()) {
context.nextC();
Processor processor = pf.createProcessor(context);
// 如果下一个字符能被识别，交给对应的处理器
if (!(processor instanceof NonProcessor)) {
processor.doProcess(context);
return;
}
}
}
}CNProcessor
中文处理器是最复杂的，采用最长匹配 + 最细粒度匹配策略：
java
public class CNProcessor implements Processor {
private final DictTree dictTree = DictTree.getInstance();
@Override
public void doProcess(Context context) {
char start = context.getC();
// 尝试以当前字符为起点，匹配最长的词
String longestToken = matchLongest(context, start);
if (longestToken != null && longestToken.length() > 1) {
// 找到了多字词，同时保存单字和多字词
context.addToken(String.valueOf(start), 1); // 单字
context.addToken(longestToken, longestToken.length()); // 多字词
} else {
// 只找到单字
context.addToken(String.valueOf(start), 1);
}
}
private String matchLongest(Context context, char start) {
// 创建快照迭代器，用于回溯
CaptureIterator snapshot = context.createSnapshot();
StringBuilder token = new StringBuilder();
token.append(start);
DictTree.Node node = dictTree.getRoot().getChild(start);
if (node == null) {
return null;
}
String longestMatch = node.isEnd() ? token.toString() : null;
// 持续匹配
while (snapshot.hasNext()) {
char c = snapshot.next();
node = node.getChild(c);
if (node == null) {
break; // 无法继续匹配
}
token.append(c);
if (node.isEnd()) {
longestMatch = token.toString(); // 更新最长匹配
}
}
return longestMatch;
}
}关键点：
- 最长匹配：以每个中文字符为起点，尝试匹配最长的词组
- 最细粒度：如果匹配到多字词（长度 > 1），同时保存单字和多字词
- 快照迭代器 ：使用
CaptureIterator进行匹配，不影响主迭代器
示例 ：对于 ['两', '数', '之', '和']
- 以'两'为起点，匹配到"两数"（长度2），保存"两"和"两数"
- 以'数'为起点，匹配到"数"（长度1），保存"数"
- 以'之'为起点，匹配到"之"（长度1），保存"之"
- 以'和'为起点，匹配到"和"（长度1），保存"和"
最终得到：["两", "两数", "数", "之", "和"]
这种策略的好处是：用户搜索"两"或"两数"都能匹配到这道题目。
DictTree
DictTree 使用字典树（Trie）存储词典，支持高效的前缀匹配：
java
public class DictTree {
private final Node root = new Node();
public void addWord(String word) {
Node node = root;
for (char c : word.toCharArray()) {
node = node.getOrCreateChild(c);
}
node.setEnd(true); // 标记为词尾
}
public static class Node {
private final Map<Character, Node> children = new HashMap<>();
private boolean isEnd = false;
public Node getChild(char c) {
return children.get(c);
}
public Node getOrCreateChild(char c) {
return children.computeIfAbsent(c, k -> new Node());
}
public boolean isEnd() {
return isEnd;
}
public void setEnd(boolean end) {
isEnd = end;
}
}
}字典树的结构：
root
/ | \
动 贪 算
| | |
态 心 法
|
规
|
划(end)每个节点代表一个字符，isEnd 标记表示该字符是否可以作为词的结尾。通过这种结构，我们可以快速判断一个字符序列是否能组成合法的词。
分词流程
DictTree CNProcessor ProcessorFactory Context SourceManager Segmentation 用户输入 DictTree CNProcessor ProcessorFactory Context SourceManager Segmentation 用户输入 loop 处理每个字符 "两数之和" 获取迭代器 IteratorAdvance nextC() 获取'两' createProcessor(context) CNProcessor doProcess(context) 匹配"两"、"两数" 找到"两数" addToken("两", 1) addToken("两数", 2) "两", "两数", "数", "之", "和"
通过这套精心设计的分词系统，LeetCode Runner 实现了高效、准确的中文搜索功能。
十、记忆
在学习算法题的过程中，你是否遇到过这样的困扰：刚做过的题目，过几天就忘了；有些题目反复做了很多遍，还是记不住；不知道什么时候该复习哪些题目。这些问题的根源在于，我们缺乏一个科学的复习计划。FSRS（Free Spaced Repetition Scheduler）算法就是为了解决这个问题而诞生的。
记忆遗忘曲线
德国心理学家艾宾浩斯在 1885 年通过实验发现了著名的遗忘曲线。他发现，人们在学习新知识后，遗忘的速度是先快后慢的。在学习后的最初几小时内，遗忘速度最快，可能会忘记 50% 以上的内容。随着时间推移，遗忘速度逐渐变慢，但仍然会持续遗忘。
这个发现揭示了一个重要的事实：如果我们不及时复习，学过的知识很快就会被遗忘。但是，如果我们在即将遗忘的时候进行复习，就能够强化记忆，延缓遗忘的速度。而且，每次复习后，下次遗忘的速度会变得更慢，复习的间隔可以变得更长。
基于这个原理，科学家们提出了间隔重复（Spaced Repetition）的学习方法。这种方法的核心思想是：在记忆即将遗忘的时候进行复习，而不是在完全遗忘之后。通过精心设计的复习间隔，我们可以用最少的复习次数达到最好的记忆效果。
SM-2
最早的间隔重复算法是 SM-2（SuperMemo 2），由波兰科学家 Piotr Wozniak 在 1987 年提出。SM-2 算法使用一个简单的公式来计算下次复习的间隔：如果回答正确，间隔乘以一个系数（通常是 2.5）；如果回答错误，间隔重置为 1 天。
这个算法虽然简单有效，但也有明显的局限性。首先，它假设所有人的记忆能力是一样的，没有考虑个体差异。有些人记忆力好，可以用更长的间隔；有些人记忆力差，需要更频繁的复习。其次，它假设所有知识的难度是一样的，没有考虑知识的复杂度。简单的知识可以快速掌握，复杂的知识需要更多的复习。
后来出现了很多改进的算法，比如 SM-15、Anki 的算法等。这些算法引入了更多的参数，试图更准确地模拟记忆过程。但它们仍然基于一些简化的假设，而且参数的调整往往依赖于经验，缺乏理论支持。
FSRS
FSRS 算法是一个全新的间隔重复算法，由 Jarrett Ye 在 2022 年提出。它的创新之处在于，它不是基于简单的经验公式，而是基于大量真实学习数据训练出来的机器学习模型。这让它能够更准确地预测记忆的遗忘过程。
FSRS 算法的核心是两个概念：稳定性（Stability）和难度（Difficulty）。稳定性表示记忆的持久程度，稳定性越高，遗忘得越慢。难度表示知识的复杂程度，难度越高，越难记住。这两个参数共同决定了下次复习的时间。
稳定性（Stability）：记忆能保持多久（天）
- stability = 1 → 1 天后可能忘记
- stability = 30 → 30 天后可能忘记
稳定性不是固定不变的，它会随着每次复习而变化。如果复习时回答正确，稳定性会增加，下次复习的间隔会变长。如果回答错误，稳定性会降低，需要更频繁的复习。而且，稳定性的增长不是线性的，而是遵循一个复杂的数学模型。
可提取性（Retrievability）：当前能回忆起来的概率
- R ≈ 1 → 肯定记得
- R ≈ 0.5 → 50% 概率记得
难度也不是固定的，它会根据你的表现动态调整。如果你总是能轻松回答某个题目，系统会认为这个题目对你来说不难，难度会降低。如果你总是答错，难度会增加。这种动态调整让算法能够适应每个人的学习情况。
评分等级
在 FSRS 算法中，每次复习后你需要给自己的表现打分。有四个等级可以选择：Again（需要重新复习）、Hard（有点困难）、Good（有思路，能写出来）、Easy（小菜一碟）。这四个等级不仅仅是主观的感受，它们对应着不同的记忆强度，会直接影响算法的计算。
-
选择 Again 意味着你完全不记得这道题，或者答案完全错误。这时候，算法会认为你的记忆已经完全遗忘，需要重新学习。稳定性会大幅降低，下次复习的间隔会很短，可能只有几分钟或几小时。而且，这道题的难度会增加，因为它显然对你来说不容易。
-
选择 Hard 意味着你有一些印象，但不太确定，或者答案部分正确。这时候，算法会认为你的记忆还在，但不够牢固。稳定性会略微增加，但增加的幅度不大。下次复习的间隔会比 Again 长，但比 Good 短。难度也会略微增加。
-
选择 Good 意味着你能够正确回答，虽然可能需要思考一会儿。这是最常见的选择，表示正常的学习进度。稳定性会有明显的增加，下次复习的间隔会显著延长。难度会保持稳定或略微降低。
-
选择 Easy 意味着你能够立即、毫不费力地回答。这时候，算法会认为你已经完全掌握了这道题。稳定性会大幅增加，下次复习的间隔会很长，可能是几个月甚至更久。难度会降低，因为这道题对你来说已经很简单了。
这四个等级的设计非常巧妙。它们不是简单的"对"或"错"，而是反映了记忆的强度。通过这种细粒度的反馈，算法能够更准确地调整复习计划。
| 评分 | 含义 | 新题间隔 | 复习间隔 |
|---|---|---|---|
| AGAIN (0) | 不会 | 1 分钟 | 重新学习 |
| HARD (1) | 困难 | 5 分钟 | 不变 |
| GOOD (2) | 一般 | 10 分钟 | ×1.3 |
| EASY (3) | 简单 | 15 分钟 | ×1.5 |
在 FSRS 算法中，每道题目都有一个难度评级（Difficulty），范围是 1-10。难度评级不是固定的，而是根据用户的表现动态调整的。
如果一道题目经常答错，说明对用户来说很难，难度评级会增加。如果经常答对，说明很简单，难度评级会降低。这种动态调整让算法能够适应每个人的水平。
难度评级影响稳定性的增长速度。对于难题，即使答对了，稳定性增长也比较慢，需要更频繁地复习。对于简单题，答对后稳定性增长很快，复习间隔可以很长。
代码实现：
java
public class FSRSAlgorithm {
// 计算新的稳定性
public double calculateNewStability(double oldStability, double retrievability,
double difficulty, Rating rating) {
// 基础增长因子
double factor = 1.0;
// 根据评级调整因子
switch (rating) {
case AGAIN: // 答错
factor = 0.4;
break;
case HARD: // 勉强答对
factor = 0.6;
break;
case GOOD: // 答对
factor = 1.0;
break;
case EASY: // 很容易答对
factor = 1.3;
break;
}
// 根据可提取性调整因子
// 可提取性越低（快忘了），增长越多
factor *= (1 + (1 - retrievability));
// 根据难度调整因子
// 难度越高，增长越慢
factor *= (1 - difficulty / 20);
// 计算新的稳定性
return oldStability * factor;
}
// 计算下次复习时间
public int calculateNextReviewDays(double stability, double targetRetrievability) {
// 根据公式 R(t) = (1 + t / (9 * S))^(-1)
// 反推 t = 9 * S * (R^(-1) - 1)
return (int) (9 * stability * (Math.pow(targetRetrievability, -1) - 1));
}
}注意几个关键点：
-
评级影响：答错时，稳定性只增长 40%；答对时，增长 100%；很容易答对时，增长 130%。这鼓励用户在合适的时间复习。
-
可提取性影响：可提取性越低，稳定性增长越多。这符合"快要忘记时复习效果最好"的原理。
-
难度影响：难度越高，稳定性增长越慢。这让难题的复习频率更高。
-
指数增长：稳定性是按倍数增长的，不是线性增长。这让复习间隔呈指数增长，符合遗忘曲线的特点。
状态机
一道题目可以处于四种状态之一：New（新题目）、Learning（学习中）、Review（复习中）、Relearning（重新学习）。这些状态之间的转换遵循特定的规则。
-
当你第一次遇到一道题目时，它处于 New 状态。这时候，算法还不知道这道题对你来说有多难，所以会使用一个初始的稳定性和难度值。这些初始值是根据大量用户数据统计出来的平均值。
-
当你第一次做这道题后，根据你的评分，题目会进入不同的状态。如果你选择 Again 或 Hard，题目会进入 Learning 状态，表示你还在学习这道题。如果你选择 Good，题目也会进入 Learning 状态，但稳定性会更高。如果你选择 Easy，题目会直接进入 Review 状态，跳过 Learning 阶段。
-
在 Learning 状态下，复习间隔比较短，通常是几分钟到几天。这是因为新学的知识遗忘得很快，需要频繁复习来巩固。当你在 Learning 状态下连续几次选择 Good 或 Easy 后，题目会进入 Review 状态。
-
在 Review 状态下，复习间隔会逐渐延长，从几天到几周、几个月。这是正常的复习阶段，大部分题目都会处于这个状态。如果你在 Review 状态下选择 Again，说明你已经遗忘了这道题，题目会进入 Relearning 状态。
Relearning 状态类似于 Learning 状态，但稳定性的起点更高，因为你之前已经学过这道题。在 Relearning 状态下复习几次后，题目会重新进入 Review 状态。
这个状态机模型让算法能够区分不同阶段的学习需求。新学的知识需要密集复习，已经掌握的知识可以稀疏复习，遗忘的知识需要重新巩固。通过状态的转换，算法能够自动调整复习策略。
第一次学习
连续答对
答错
答对
答错
连续答对
答错
New
Learning
Review
Relearning
💡 面试题：为什么需要 Learning 和 Relearning 两个状态？直接进入 Review 不行吗？
这个问题考察的是对学习过程的理解。
Learning 和 Relearning 的作用是"短期巩固"。刚学习的知识，记忆强度虽然是 100%，但稳定性很低，可能几分钟就忘了。如果直接进入 Review 状态，按照稳定性计算的复习时间可能是几天后，这时已经完全忘记了。通过 Learning 状态，我们可以在短期内（比如 1 分钟、10 分钟、1 小时）多次复习，快速提升稳定性。等稳定性达到一定水平，再进入 Review 状态，进行长期复习。
Relearning 状态的作用类似，但它是针对"曾经掌握但又忘记"的知识。这种知识的特点是：虽然忘记了，但重新学习的速度比第一次快。所以 Relearning 的复习间隔比 Learning 稍长。这种设计符合认知心理学的研究成果：
短期内多次复习，可以快速巩固记忆；长期间隔复习，可以保持记忆。
数学模型
Ebbinghaus 在 1885 年通过实验发现，人的记忆会随着时间呈指数衰减。刚学完的知识，记忆强度是 100%；过一天，可能降到 50%；再过一天，降到 25%。这就是著名的遗忘曲线。
但遗忘曲线不是一成不变的。如果在记忆强度降到某个阈值（比如 90%）时进行复习，记忆强度会重新回到 100%，而且下次遗忘的速度会变慢。这就是间隔重复（Spaced Repetition）的原理。
FSRS 算法把这个过程建模为一个状态机。每个知识点（在我们的场景中是每道题目）都有两个核心参数：
- 稳定性（Stability）：记忆的持久度，表示记忆强度从 100% 降到 90% 需要多少天。稳定性越高，遗忘越慢。
- 可提取性（Retrievability）：当前的记忆强度，表示现在能否回忆起这个知识点。可提取性随时间衰减。
否
是
学习
稳定性 S = 初始值
可提取性 R = 100%
时间流逝
R 按指数衰减
R < 90%?
复习
R 恢复到 100%
S 增加
可提取性的计算公式是：
R(t) = (1 + t / (9 * S))^(-1)其中，t 是距离上次复习的天数，S 是稳定性。这个公式的含义是：时间越长，可提取性越低；稳定性越高，衰减越慢。
当可提取性降到某个阈值（比如 90%）时，就应该复习了。复习后，可提取性恢复到 100%，稳定性增加。稳定性的增加量取决于复习时的可提取性：如果可提取性很低（说明快忘了），稳定性增加得多；如果可提取性很高（说明还记得很清楚），稳定性增加得少。
这个设计非常巧妙。它鼓励在"快要忘记但还没完全忘记"的时候复习，这样既能巩固记忆，又能最大化稳定性的增长。如果复习得太早，记忆还很清晰，稳定性增长有限；如果复习得太晚，已经完全忘记，需要重新学习，效率很低。
三个核心公式：
1. 可提取性计算 （QuestionCardScheduler.java:127）：
java
float retrievability = (float) Math.exp(Math.log(0.9) * interval / lastStability);2. 回忆后稳定性提升 （FSRSAlgorithm.java:242-247）：
java
nextStability = stability * (1 + Math.exp(1.5) *
(11 - difficulty) *
Math.pow(stability, -0.2) *
(Math.exp((1 - retrievability) * 0.8) - 1));3. 下次复习间隔 （FSRSAlgorithm.java:217-220）：
java
int interval = (int) (stability * Math.log(0.9) / Math.log(0.9));
return Math.min(Math.max(interval, 1), 36500);代码实现
FSRS 算法的原始实现是用 Python 写的，而且依赖了很多科学计算库（NumPy、SciPy 等）。要在 Java 中从零复现，面临很多挑战。
状态管理：
-
FSRS 算法需要为每道题目维护状态（New、Learning、Review、Relearning）、稳定性、可提取性、难度等多个参数。这些参数需要持久化存储，而且需要高效地查询和更新。
-
我们使用了一个简单但有效的方案：为每道题目创建一个
CardState对象，包含所有参数。这些对象存储在内存中的 HashMap，定期序列化到磁盘。查询时直接从 HashMap 读取，更新时先修改内存，再异步写入磁盘。
java
public class CardState {
private String questionId;
private State state; // 状态
private double stability; // 稳定性
private double difficulty; // 难度
private LocalDateTime lastReview; // 上次复习时间
private LocalDateTime nextReview; // 下次复习时间
private int reviewCount; // 复习次数
// 计算当前的可提取性
public double getRetrievability() {
long daysSinceReview = ChronoUnit.DAYS.between(lastReview, LocalDateTime.now());
return Math.pow(1 + daysSinceReview / (9.0 * stability), -1);
}
// 是否需要复习
public boolean needsReview() {
return LocalDateTime.now().isAfter(nextReview);
}
}
public class FSRSScheduler {
private final Map<String, CardState> cardStates = new ConcurrentHashMap<>();
private final FSRSAlgorithm algorithm = new FSRSAlgorithm();
// 获取需要复习的题目
public List<String> getDueCards() {
return cardStates.values().stream()
.filter(CardState::needsReview)
.sorted(Comparator.comparing(CardState::getNextReview))
.map(CardState::getQuestionId)
.collect(Collectors.toList());
}
// 记录复习结果
public void recordReview(String questionId, Rating rating) {
CardState state = cardStates.get(questionId);
if (state == null) {
state = new CardState(questionId);
cardStates.put(questionId, state);
}
// 计算新的稳定性
double retrievability = state.getRetrievability();
double newStability = algorithm.calculateNewStability(
state.getStability(), retrievability, state.getDifficulty(), rating
);
// 计算下次复习时间
int daysUntilNextReview = algorithm.calculateNextReviewDays(newStability, 0.9);
// 更新状态
state.setStability(newStability);
state.setLastReview(LocalDateTime.now());
state.setNextReview(LocalDateTime.now().plusDays(daysUntilNextReview));
state.setReviewCount(state.getReviewCount() + 1);
// 异步持久化
persistAsync(state);
}
}复盘一下整个刷题流程：
用户点击"开始复习"
↓
queueDueCards() - 查询到期题目
SQL: SELECT * FROM cards WHERE next_repetition <= 当前时间
↓
getTopCard() - 取队列头部
↓
用户做题并评分（AGAIN/HARD/GOOD/EASY）
↓
onRating() - 调用 FSRS 算法
1. 读取：stability, difficulty, elapsed_days
2. 计算：新的 stability, difficulty, next_repetition
3. 更新数据库
📌 [ 笔者 ] 文艺倾年
📃 [ 更新 ] 2026.2.15
❌ [ 勘误 ] /* 暂无 */
📜 [ 声明 ] 由于作者水平有限，本文有错误和不准确之处在所难免，
本人也很想知道这些错误，恳望读者批评指正！