1. LeetCode刷题与复盘方法论

作为一名Java开发者，我坚持刷LeetCode已经三年有余。从最初的"两数之和"都磕磕绊绊，到现在能从容应对周赛四题，这套自创的"五步复盘法"是我突破算法瓶颈的关键。不同于简单的题海战术，系统化的复盘能让每道题的价值提升3-5倍。

1.1 刷题前的结构化准备

工欲善其事，必先利其器。我的刷题装备清单：

• IntelliJ IDEA + LeetCode插件（官方编辑器太简陋）
• 纸质笔记本+三色笔（红黑蓝对应不同笔记类型）
• 计时器（严格模拟面试环境）

数据结构选择矩阵是我自制的决策工具：

| 问题特征 | 首选结构 | 备选方案 | 时间复杂度 | |--------------------|-------------|-------------|------------| | 需要快速查找 | HashSet | TreeSet | O(1)/O(logn)| | 维护插入顺序 | LinkedHashMap| ArrayList | O(1) | | 频繁头尾操作 | Deque | LinkedList | O(1) | | 键值对范围查询 | TreeMap | HashMap+排序 | O(logn) |

1.2 五步深度复盘流程

1.2.1 初解记录阶段

用手机录屏第一次解题过程，记录所有卡壳点和犹豫时间。比如在解决"76. 最小覆盖子串"时，我的初始滑动窗口实现存在重复计算问题，录屏显示在窗口收缩逻辑上卡顿了7分钟。

1.2.2 多维解法分析

对每道题至少探索三种解法。以"215. 数组中的第K个最大元素"为例：

1. 直接排序法：Arrays.sort()后取倒数第K个（O(nlogn)）
2. 堆解法：维护大小为K的小顶堆（O(nlogk)）
3. 快速选择：改造快排的partition（平均O(n)）

// 快速选择实现示例 public int findKthLargest(int[] nums, int k) { int left = 0, right = nums.length - 1; while (true) { int pivot = partition(nums, left, right); if (pivot == k - 1) return nums[pivot]; if (pivot < k - 1) left = pivot + 1; else right = pivot - 1; } }

1.2.3 复杂度可视化

我用Excel制作了常见操作的时间成本对比图，比如ArrayList的add(0, e)是O(n)而LinkedList是O(1)，但在实际遍历时前者有更好的局部性。这种视觉化记忆比单纯背复杂度更有效。

1.2.4 错题本构建技巧

不是简单记录错误，而是建立错误模式索引：

• 边界类：左闭右开vs双闭区间
• 溢出类：二分查找中的mid计算
• 并发修改：遍历时修改集合
• 状态同步：DFS中的visited标记

每个模式配3-5道典型题，比如"边界类"对应：

1. 704. 二分查找（左右区间终止条件）
2. 34. 在排序数组中查找元素的第一个和最后一个位置
3. 35. 搜索插入位置

1.2.5 口语化讲解训练

使用"费曼技巧"，假设要向新手解释解法。我发现自己能流畅写出"146. LRU缓存"的代码，但解释get()操作如何维护访问顺序时却语塞，这暴露了对双向链表指针变化的理解漏洞。

2. Java语言特性深度利用

2.1 集合框架的实战优化

2.1.1 HashMap的负载因子陷阱

默认0.75负载因子在频繁查询场景并不最优。我处理"692. 前K个高频单词"时，通过预先计算词频数量设置初始容量，避免resize开销：

int maxSize = (int)(wordCount.size() / 0.75) + 1; Map<String, Integer> frequencyMap = new HashMap<>(maxSize);

2.1.2 TreeSet的comparator坑点

"220. 存在重复元素III"需要使用滑动窗口+TreeSet，但要注意：

// 错误写法：可能溢出 set.floor((long)nums[i] + t) // 正确处理 Long floor = set.floor(nums[i]); if (floor != null && nums[i] - floor <= t) return true;

2.2 并发工具的应用场景

在"1188. 设计有限阻塞队列"中，对比了不同实现方案：

1. synchronized+wait/notify：代码简单但吞吐量低
2. ReentrantLock+Condition：更灵活的条件等待
3. ArrayBlockingQueue：直接使用JDK实现

实测发现方案2比方案1吞吐量高40%，但面试时方案1更容易写对。

3. 算法模板的精髓与变形

3.1 二分查找的六种变体

我的模板库包含：

1. 基本二分（找确定值）
2. 左边界二分（可插入位置）
3. 右边界二分
4. 旋转数组二分
5. 无限流二分
6. 浮点数精度二分

以旋转数组搜索为例：

public int search(int[] nums, int target) { int left = 0, right = nums.length - 1; while (left <= right) { int mid = left + (right - left) / 2; if (nums[mid] == target) return mid; if (nums[left] <= nums[mid]) { // 左半段有序 if (nums[left] <= target && target < nums[mid]) right = mid - 1; else left = mid + 1; } else { // 右半段有序 if (nums[mid] < target && target <= nums[right]) left = mid + 1; else right = mid - 1; } } return -1; }

3.2 回溯法的剪枝艺术

在"51. N皇后"问题中，通过位运算剪枝将时间复杂度从O(N!)降到O(N!)：

void backtrack(int row, int cols, int diags1, int diags2) { if (row == n) { /* 记录解 */ return; } int availablePos = ((1 << n) - 1) & ~(cols | diags1 | diags2); while (availablePos != 0) { int pos = availablePos & -availablePos; // 获取最低位的1 availablePos &= availablePos - 1; // 清除该位 backtrack(row+1, cols|pos, (diags1|pos)<<1, (diags2|pos)>>1); } }

4. 周赛实战策略

4.1 时间分配金字塔

我的30-20-25-35分钟分配法：

1. 第一题：30分钟内必须AC（包括异常处理）
2. 第二题：20分钟核心逻辑+10分钟边界检查
3. 第三题：25分钟主算法+10分钟优化
4. 第四题：35分钟（前10分钟评估是否值得做）

4.2 调试技巧

在"周赛430"的第三题中，我遇到TLE时使用：

1. 打印操作次数日志，发现无效循环
2. 用JProfiler定位热点方法
3. 替换HashSet为boolean数组（提升20%速度）

5. 面试八股文转化技巧

5.1 从算法题引出知识点

当被问到HashMap原理时，我会结合：

1. "1. 两数之和"说明哈希查找优势
2. "706. 设计哈希映射"手写简单实现
3. "380. O(1)时间插入、删除和获取随机元素"讨论扩容影响

5.2 系统设计衔接

解"460. LFU缓存"后，顺势讨论：

1. Redis内存淘汰策略
2. MySQL的LRU链表优化
3. 分布式环境下的缓存一致性

这套方法让我在三个月内从AC率50%提升到85%，最重要的是建立了算法与工程实践的连接思维。现在看每道题不仅是解题，更是发现其背后的设计模式和系统思想。