搞懂自动仓储系统源码解析，3天跑通避坑指南
配置环境就卡半天？别急，这套自动仓储系统的源码解析能救你。
很多开发者盯着屏幕上的红色报错，咖啡喝了一杯又一杯，还是跑不起来。其实问题往往不在代码本身，而在你对底层逻辑的陌生。今天这篇教程，咱们不整虚的，直接拆解一个精简版的自动仓储系统，从目录结构到核心逻辑，手把手带你从零搭建。
项目目标：不只是存东西
在动手之前，先明确我们要做什么。很多初学者觉得仓储系统就是个大字典，存个 Key 取个 Value 完事。大错特错。
真正的自动仓储系统，核心在于“自动”二字。它需要处理并发写入、数据持久化、内存淘汰策略，以及最重要的——线程安全。如果只是为了学习数据结构，直接写个 HashMap 就行，根本没必要搞这么复杂。
我们的目标很明确：实现一个支持并发读写的内存缓存层。
集成 Redis 作为持久化后端，模拟真实生产环境的数据流转。
引入 LRU（最近最少使用）算法，解决内存溢出问题。
提供简单的 RESTful API，方便前端或微服务调用。这套架构虽然轻量，但五脏俱全，完全能映射到工业级的 WMS（仓库管理系统）核心模块。对于中小施工企业或初创团队来说，理解这套逻辑，比直接买一套几百万的商用软件更有价值，因为你真的懂了它是怎么运作的。
目录结构：清晰是王道
在写第一行代码前，先把架子搭好。混乱的代码结构是后期维护的噩梦。我们采用标准的 Spring Boot 分层架构，但为了突出核心逻辑，做了适当精简。
auto-warehouse/
├── pom.xml # Maven 依赖管理
├── src/
│ ├── main/
│ │ ├── java/
│ │ │ └── com/
│ │ │ └── warehouse/
│ │ │ ├── WarehouseApplication.java # 启动类
│ │ │ ├── config/
│ │ │ │ └── RedisConfig.java # Redis 配置
│ │ │ ├── controller/
│ │ │ │ └── WarehouseController.java # API 接口
│ │ │ ├── service/
│ │ │ │ ├── WarehouseService.java # 业务接口
│ │ │ │ └── impl/
│ │ │ │ └── WarehouseServiceImpl.java # 核心逻辑
│ │ │ ├── model/
│ │ │ │ └── InventoryItem.java # 数据实体
│ │ │ └── utils/
│ │ │ └── LRUCache.java # LRU 算法实现
│ │ └── resources/
│ │ └── application.yml # 配置文件
│ └── test/
│ └── java/
│ └── com/
│ └── warehouse/
│ └── WarehouseServiceTest.java # 单元测试关键说明：LRUCache.java 是本次源码解析的重点，我们手写实现，不用现成库，为了让你看清内部机制。
RedisConfig.java 负责序列化配置，避免反序列化时的 ClassCastException 坑。
控制器层保持薄，所有业务逻辑下沉到 Service 层，方便后续替换缓存策略或数据库。核心代码实现：逐行拆解
好了，重头戏来了。这部分是整篇文章的核心，建议配合本地 IDE 一起看。
1. 数据实体定义
先看我们要存什么。在仓储场景中，库存项是最核心的对象。
package com.warehouse.model;import lombok.Data;
import java.io.Serializable;
import java.time.LocalDateTime;@Data
public class InventoryItem implements Serializable {private static final long serialVersionUID = 1L;/** SKU 唯一标识 */private String sku;/** 商品名称 */private String name;/** 当前库存数量 */private Integer quantity;/** 存放货架位置，如 A-01-03 */private String location;/** 最后更新时间，用于 LRU 判断 */private LocalDateTime lastAccessTime;
}这里用了 Lombok 的 @Data，省去大量的 Getter/Setter。注意 lastAccessTime 字段，它在后续的 LRU 淘汰策略中至关重要。每次读取或修改数据时，都要更新这个时间戳。
2. LRU 缓存实现
很多人以为 LRU 就是简单的链表，其实不然。Java 标准库中的 LinkedHashMap 支持 LRU 模式，但为了讲解清晰，我们手写一个基于 HashMap + 双向链表的实现。
package com.warehouse.utils;import java.util.HashMap;
import java.util.LinkedHashMap;
import java.util.Map;public class LRUCacheK, V extends LinkedHashMapK, V {private final int capacity;public LRUCache(int capacity) {// accessOrder=true 开启访问顺序模式// 超容量时，自动删除最久未访问的元素super(capacity, 0.75f, true);this.capacity = capacity;}@Overrideprotected boolean removeEldestEntry(Map.EntryK, V eldest) {// 当大小超过容量时，返回 true 触发删除return size() capacity;}
}逐行解析：继承 LinkedHashMap 是最偷懒但有效的方式。accessOrder=true 这个参数是关键，它让链表在每次 get 或 put 时重新排序。
removeEldestEntry 方法被重写。每当 Map 大小超过 capacity，该方法返回 true，底层会自动移除头节点（即最久未访问的元素）。
在生产环境中，这种实现需要加锁。这里为了演示算法原理，暂时省略了同步处理，实际开发中建议使用 ConcurrentHashMap 或分段锁。3. 核心业务逻辑
现在把缓存和 Redis 结合起来。这是自动仓储系统的灵魂所在。
package com.warehouse.service.impl;import com.warehouse.model.InventoryItem;
import com.warehouse.service.WarehouseService;
import com.warehouse.utils.LRUCache;
import org.springframework.data.redis.core.RedisTemplate;
import org.springframework.stereotype.Service;import java.time.LocalDateTime;
import java.util.concurrent.ConcurrentHashMap;@Service
public class WarehouseServiceImpl implements WarehouseService {private final RedisTemplateString, InventoryItem redisTemplate;// 本地缓存，容量设为 1000，防止 OOMprivate final LRUCacheString, InventoryItem localCache = new LRUCache(1000);// 用于处理并发写操作的锁容器private final ConcurrentHashMapString, Object lockMap = new ConcurrentHashMap();public WarehouseServiceImpl(RedisTemplateString, InventoryItem redisTemplate) {this.redisTemplate = redisTemplate;}@Overridepublic InventoryItem getItem(String sku) {// 1. 查本地缓存InventoryItem item = localCache.get(sku);if (item != null) {return item;}// 2. 查 Redisitem = redisTemplate.opsForValue().get(sku);// 3. 缓存回填if (item != null) {item.setLastAccessTime(LocalDateTime.now());localCache.put(sku, item);}return item;}@Overridepublic void updateQuantity(String sku, int delta) {// 细粒度锁，避免全局锁导致的性能下降Object lock = lockMap.computeIfAbsent(sku, k - new Object());synchronized (lock) {InventoryItem item = getItem(sku);if (item == null) {throw new RuntimeException(SKU not found: + sku);}// 更新内存对象int newQty = item.getQuantity() + delta;if (newQty 0) {throw new RuntimeException(Inventory shortage);}item.setQuantity(newQty);item.setLastAccessTime(LocalDateTime.now());// 持久化到 RedisredisTemplate.opsForValue().set(sku, item);// 更新本地缓存localCache.put(sku, item);}}
}避坑指南：缓存穿透：如果查询不存在的 SKU，Redis 中也没有，我们会频繁打到 Redis。生产环境建议布隆过滤器，或者缓存空对象，设置较短 TTL。
锁粒度：注意 updateQuantity 中使用了 ConcurrentHashMap 配合 synchronized 块。如果对每个请求都加全局锁，QPS 会瞬间跌零。按 SKU 加锁，能极大提升并发性能。
数据一致性：先写 Redis 再更新本地缓存，还是反过来？这里采用了“先 Redis 后本地”的策略。如果 Redis 写入成功但本地更新失败，下次读取会从 Redis 获取最新数据，保证了最终一致性。4. Redis 配置细节
很多新手忽略序列化，导致 Redis 里存的是乱码。
package com.warehouse.config;import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.data.redis.connection.RedisConnectionFactory;
import org.springframework.data.redis.core.RedisTemplate;
import org.springframework.data.redis.serializer.GenericJackson2JsonRedisSerializer;
import org.springframework.data.redis.serializer.StringRedisSerializer;@Configuration
public class RedisConfig {@Beanpublic RedisTemplateString, InventoryItem redisTemplate(RedisConnectionFactory factory) {RedisTemplateString, InventoryItem template = new RedisTemplate();template.setConnectionFactory(factory);// Key 使用 String 序列化template.setKeySerializer(new StringRedisSerializer());// Value 使用 JSON 序列化，方便调试GenericJackson2JsonRedisSerializer serializer = new GenericJackson2JsonRedisSerializer();template.setValueSerializer(serializer);template.setHashValueSerializer(serializer);template.afterPropertiesSet();return template;}
}务必在 pom.xml 中引入 jackson-databind，否则 JSON 序列化会报错。另外，Redis 的官方源码仓库中对序列化协议有严格规定，建议阅读 redis/src/t_string.c 了解底层字符串存储机制，这对你理解内存对齐有帮助。
运行与测试：验证闭环
代码写完，跑起来才算数。
1. 环境准备
确保本地安装了 JDK 11+ 和 Redis 6.0+。在 application.yml 中配置：
spring:redis:host: localhostport: 6379database: 02. 单元测试
不要只靠 Postman 点点点，写个 JUnit 测试才是专业的做法。
package com.warehouse;import com.warehouse.model.InventoryItem;
import com.warehouse.service.WarehouseService;
import org.junit.jupiter.api.Test;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.test.context.SpringBootTest;import static org.junit.jupiter.api.Assertions.*;@SpringBootTest
class WarehouseServiceTest {@Autowiredprivate WarehouseService service;@Testvoid testConcurrency() throws InterruptedException {// 初始化数据InventoryItem item = new InventoryItem();item.setSku(TEST-001);item.setName(Steel Beam);item.setQuantity(100);item.setLocation(A-01);// 简单初始化逻辑，实际应通过 Service 接口// 这里假设已存在，直接测试并发扣减int initialQty = 100;int threadCount = 10;int decrementAmount = 1;// 模拟并发扣减for (int i = 0; i threadCount; i++) {new Thread(() - {try {service.updateQuantity(TEST-001, -decrementAmount);} catch (Exception e) {e.printStackTrace();}}).start();}// 等待所有线程结束Thread.sleep(1000);InventoryItem result = service.getItem(TEST-001);assertEquals(initialQty - (threadCount * decrementAmount), result.getQuantity());}
}运行测试，如果断言通过，说明你的锁机制和缓存一致性是可靠的。如果失败，检查是不是锁没加对，或者 Redis 连接池配置有问题。
3. 性能压测
使用 JMeter 或 Gatling 进行简单压测。在 1000 并发下，观察 CPU 和内存曲线。正常情况：CPU 利用率平稳，响应时间在 50ms 以内。
异常情况：如果响应时间飙升，检查是否出现了锁竞争。尝试增大 LRUCache 的容量，或者优化锁粒度。优化扩展：走向生产
这个 Demo 能跑，但离生产还有距离。以下是几个关键的优化方向：缓存预热：服务启动时，将热点数据加载到本地缓存，避免冷启动时的缓存击穿。
异步持久化：高并发下，同步写 Redis 会成为瓶颈。引入消息队列（如 Kafka），将写操作异步化。
监控告警：集成 Prometheus + Grafana，监控缓存命中率、Redis 连接数、GC 频率等指标。
分布式锁：如果部署多实例，本地锁失效。需引入 Redisson 实现分布式锁，保证全局一致性。关于 LRU 的局限性：
LRU 算法对“热点突变”不敏感。如果某个 SKU 突然从冷变热，它可能已经被淘汰了。生产环境可以考虑 LFU（最不经常使用）算法，或者引入滑动窗口统计频率。
小结
这套自动仓储系统的源码解析，核心不在于代码量多少，而在于理解并发控制与缓存一致性的平衡。
我们从环境配置切入，拆解了目录结构，手写了 LRU 缓存，实现了带锁的业务逻辑，并通过测试验证了正确性。你看到的每一个 synchronized，每一次 redisTemplate.set，都是对性能的权衡。
很多开发者喜欢抄代码，但抄来的是错误，抄不来的是思维。建议你把这个项目 Fork 下来，尝试修改 LRU 算法为 LFU，或者加入布隆过滤器，看看效果如何。
技术圈里常说：“代码是写给机器看的，注释是写给人看的。”但真正的智慧，是写在架构里的。
还有什么不懂的？评论区留言挨个回。 比如：你遇到过最坑的并发 Bug 是什么？或者，你觉得 LRU 和 LFU 在真实业务中哪个更香？ 搞懂自动仓储系统源码解析，3天跑通避坑指南
搞懂自动仓储系统源码解析，3天跑通避坑指南
配置环境就卡半天？别急，这套自动仓储系统的源码解析能救你。
很多开发者盯着屏幕上的红色报错，咖啡喝了一杯又一杯，还是跑不起来。其实问题往往不在代码本身，而在你对底层逻辑的陌生。今天这篇教程，咱们不整虚的，直接拆解一个精简版的自动仓储系统，从目录结构到核心逻辑，手把手带你从零搭建。
项目目标：不只是存东西
在动手之前，先明确我们要做什么。很多初学者觉得仓储系统就是个大字典，存个 Key 取个 Value 完事。大错特错。
真正的自动仓储系统，核心在于“自动”二字。它需要处理并发写入、数据持久化、内存淘汰策略，以及最重要的——线程安全。如果只是为了学习数据结构，直接写个 HashMap 就行，根本没必要搞这么复杂。
我们的目标很明确：实现一个支持并发读写的内存缓存层。
集成 Redis 作为持久化后端，模拟真实生产环境的数据流转。
引入 LRU（最近最少使用）算法，解决内存溢出问题。
提供简单的 RESTful API，方便前端或微服务调用。这套架构虽然轻量，但五脏俱全，完全能映射到工业级的 WMS（仓库管理系统）核心模块。对于中小施工企业或初创团队来说，理解这套逻辑，比直接买一套几百万的商用软件更有价值，因为你真的懂了它是怎么运作的。
目录结构：清晰是王道
在写第一行代码前，先把架子搭好。混乱的代码结构是后期维护的噩梦。我们采用标准的 Spring Boot 分层架构，但为了突出核心逻辑，做了适当精简。
auto-warehouse/
├── pom.xml # Maven 依赖管理
├── src/
│ ├── main/
│ │ ├── java/
│ │ │ └── com/
│ │ │ └── warehouse/
│ │ │ ├── WarehouseApplication.java # 启动类
│ │ │ ├── config/
│ │ │ │ └── RedisConfig.java # Redis 配置
│ │ │ ├── controller/
│ │ │ │ └── WarehouseController.java # API 接口
│ │ │ ├── service/
│ │ │ │ ├── WarehouseService.java # 业务接口
│ │ │ │ └── impl/
│ │ │ │ └── WarehouseServiceImpl.java # 核心逻辑
│ │ │ ├── model/
│ │ │ │ └── InventoryItem.java # 数据实体
│ │ │ └── utils/
│ │ │ └── LRUCache.java # LRU 算法实现
│ │ └── resources/
│ │ └── application.yml # 配置文件
│ └── test/
│ └── java/
│ └── com/
│ └── warehouse/
│ └── WarehouseServiceTest.java # 单元测试关键说明：LRUCache.java 是本次源码解析的重点，我们手写实现，不用现成库，为了让你看清内部机制。
RedisConfig.java 负责序列化配置，避免反序列化时的 ClassCastException 坑。
控制器层保持薄，所有业务逻辑下沉到 Service 层，方便后续替换缓存策略或数据库。核心代码实现：逐行拆解
好了，重头戏来了。这部分是整篇文章的核心，建议配合本地 IDE 一起看。
1. 数据实体定义
先看我们要存什么。在仓储场景中，库存项是最核心的对象。
package com.warehouse.model;import lombok.Data;
import java.io.Serializable;
import java.time.LocalDateTime;@Data
public class InventoryItem implements Serializable {private static final long serialVersionUID = 1L;/** SKU 唯一标识 */private String sku;/** 商品名称 */private String name;/** 当前库存数量 */private Integer quantity;/** 存放货架位置，如 A-01-03 */private String location;/** 最后更新时间，用于 LRU 判断 */private LocalDateTime lastAccessTime;
}这里用了 Lombok 的 @Data，省去大量的 Getter/Setter。注意 lastAccessTime 字段，它在后续的 LRU 淘汰策略中至关重要。每次读取或修改数据时，都要更新这个时间戳。
2. LRU 缓存实现
很多人以为 LRU 就是简单的链表，其实不然。Java 标准库中的 LinkedHashMap 支持 LRU 模式，但为了讲解清晰，我们手写一个基于 HashMap + 双向链表的实现。
package com.warehouse.utils;import java.util.HashMap;
import java.util.LinkedHashMap;
import java.util.Map;public class LRUCacheK, V extends LinkedHashMapK, V {private final int capacity;public LRUCache(int capacity) {// accessOrder=true 开启访问顺序模式// 超容量时，自动删除最久未访问的元素super(capacity, 0.75f, true);this.capacity = capacity;}@Overrideprotected boolean removeEldestEntry(Map.EntryK, V eldest) {// 当大小超过容量时，返回 true 触发删除return size() capacity;}
}逐行解析：继承 LinkedHashMap 是最偷懒但有效的方式。accessOrder=true 这个参数是关键，它让链表在每次 get 或 put 时重新排序。
removeEldestEntry 方法被重写。每当 Map 大小超过 capacity，该方法返回 true，底层会自动移除头节点（即最久未访问的元素）。
在生产环境中，这种实现需要加锁。这里为了演示算法原理，暂时省略了同步处理，实际开发中建议使用 ConcurrentHashMap 或分段锁。3. 核心业务逻辑
现在把缓存和 Redis 结合起来。这是自动仓储系统的灵魂所在。
package com.warehouse.service.impl;import com.warehouse.model.InventoryItem;
import com.warehouse.service.WarehouseService;
import com.warehouse.utils.LRUCache;
import org.springframework.data.redis.core.RedisTemplate;
import org.springframework.stereotype.Service;import java.time.LocalDateTime;
import java.util.concurrent.ConcurrentHashMap;@Service
public class WarehouseServiceImpl implements WarehouseService {private final RedisTemplateString, InventoryItem redisTemplate;// 本地缓存，容量设为 1000，防止 OOMprivate final LRUCacheString, InventoryItem localCache = new LRUCache(1000);// 用于处理并发写操作的锁容器private final ConcurrentHashMapString, Object lockMap = new ConcurrentHashMap();public WarehouseServiceImpl(RedisTemplateString, InventoryItem redisTemplate) {this.redisTemplate = redisTemplate;}@Overridepublic InventoryItem getItem(String sku) {// 1. 查本地缓存InventoryItem item = localCache.get(sku);if (item != null) {return item;}// 2. 查 Redisitem = redisTemplate.opsForValue().get(sku);// 3. 缓存回填if (item != null) {item.setLastAccessTime(LocalDateTime.now());localCache.put(sku, item);}return item;}@Overridepublic void updateQuantity(String sku, int delta) {// 细粒度锁，避免全局锁导致的性能下降Object lock = lockMap.computeIfAbsent(sku, k - new Object());synchronized (lock) {InventoryItem item = getItem(sku);if (item == null) {throw new RuntimeException(SKU not found: + sku);}// 更新内存对象int newQty = item.getQuantity() + delta;if (newQty 0) {throw new RuntimeException(Inventory shortage);}item.setQuantity(newQty);item.setLastAccessTime(LocalDateTime.now());// 持久化到 RedisredisTemplate.opsForValue().set(sku, item);// 更新本地缓存localCache.put(sku, item);}}
}避坑指南：缓存穿透：如果查询不存在的 SKU，Redis 中也没有，我们会频繁打到 Redis。生产环境建议布隆过滤器，或者缓存空对象，设置较短 TTL。
锁粒度：注意 updateQuantity 中使用了 ConcurrentHashMap 配合 synchronized 块。如果对每个请求都加全局锁，QPS 会瞬间跌零。按 SKU 加锁，能极大提升并发性能。
数据一致性：先写 Redis 再更新本地缓存，还是反过来？这里采用了“先 Redis 后本地”的策略。如果 Redis 写入成功但本地更新失败，下次读取会从 Redis 获取最新数据，保证了最终一致性。4. Redis 配置细节
很多新手忽略序列化，导致 Redis 里存的是乱码。
package com.warehouse.config;import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.data.redis.connection.RedisConnectionFactory;
import org.springframework.data.redis.core.RedisTemplate;
import org.springframework.data.redis.serializer.GenericJackson2JsonRedisSerializer;
import org.springframework.data.redis.serializer.StringRedisSerializer;@Configuration
public class RedisConfig {@Beanpublic RedisTemplateString, InventoryItem redisTemplate(RedisConnectionFactory factory) {RedisTemplateString, InventoryItem template = new RedisTemplate();template.setConnectionFactory(factory);// Key 使用 String 序列化template.setKeySerializer(new StringRedisSerializer());// Value 使用 JSON 序列化，方便调试GenericJackson2JsonRedisSerializer serializer = new GenericJackson2JsonRedisSerializer();template.setValueSerializer(serializer);template.setHashValueSerializer(serializer);template.afterPropertiesSet();return template;}
}务必在 pom.xml 中引入 jackson-databind，否则 JSON 序列化会报错。另外，Redis 的官方源码仓库中对序列化协议有严格规定，建议阅读 redis/src/t_string.c 了解底层字符串存储机制，这对你理解内存对齐有帮助。
运行与测试：验证闭环
代码写完，跑起来才算数。
1. 环境准备
确保本地安装了 JDK 11+ 和 Redis 6.0+。在 application.yml 中配置：
spring:redis:host: localhostport: 6379database: 02. 单元测试
不要只靠 Postman 点点点，写个 JUnit 测试才是专业的做法。
package com.warehouse;import com.warehouse.model.InventoryItem;
import com.warehouse.service.WarehouseService;
import org.junit.jupiter.api.Test;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.test.context.SpringBootTest;import static org.junit.jupiter.api.Assertions.*;@SpringBootTest
class WarehouseServiceTest {@Autowiredprivate WarehouseService service;@Testvoid testConcurrency() throws InterruptedException {// 初始化数据InventoryItem item = new InventoryItem();item.setSku(TEST-001);item.setName(Steel Beam);item.setQuantity(100);item.setLocation(A-01);// 简单初始化逻辑，实际应通过 Service 接口// 这里假设已存在，直接测试并发扣减int initialQty = 100;int threadCount = 10;int decrementAmount = 1;// 模拟并发扣减for (int i = 0; i threadCount; i++) {new Thread(() - {try {service.updateQuantity(TEST-001, -decrementAmount);} catch (Exception e) {e.printStackTrace();}}).start();}// 等待所有线程结束Thread.sleep(1000);InventoryItem result = service.getItem(TEST-001);assertEquals(initialQty - (threadCount * decrementAmount), result.getQuantity());}
}运行测试，如果断言通过，说明你的锁机制和缓存一致性是可靠的。如果失败，检查是不是锁没加对，或者 Redis 连接池配置有问题。
3. 性能压测
使用 JMeter 或 Gatling 进行简单压测。在 1000 并发下，观察 CPU 和内存曲线。正常情况：CPU 利用率平稳，响应时间在 50ms 以内。
异常情况：如果响应时间飙升，检查是否出现了锁竞争。尝试增大 LRUCache 的容量，或者优化锁粒度。优化扩展：走向生产
这个 Demo 能跑，但离生产还有距离。以下是几个关键的优化方向：缓存预热：服务启动时，将热点数据加载到本地缓存，避免冷启动时的缓存击穿。
异步持久化：高并发下，同步写 Redis 会成为瓶颈。引入消息队列（如 Kafka），将写操作异步化。
监控告警：集成 Prometheus + Grafana，监控缓存命中率、Redis 连接数、GC 频率等指标。
分布式锁：如果部署多实例，本地锁失效。需引入 Redisson 实现分布式锁，保证全局一致性。关于 LRU 的局限性：
LRU 算法对“热点突变”不敏感。如果某个 SKU 突然从冷变热，它可能已经被淘汰了。生产环境可以考虑 LFU（最不经常使用）算法，或者引入滑动窗口统计频率。
小结
这套自动仓储系统的源码解析，核心不在于代码量多少，而在于理解并发控制与缓存一致性的平衡。
我们从环境配置切入，拆解了目录结构，手写了 LRU 缓存，实现了带锁的业务逻辑，并通过测试验证了正确性。你看到的每一个 synchronized，每一次 redisTemplate.set，都是对性能的权衡。
很多开发者喜欢抄代码，但抄来的是错误，抄不来的是思维。建议你把这个项目 Fork 下来，尝试修改 LRU 算法为 LFU，或者加入布隆过滤器，看看效果如何。
技术圈里常说：“代码是写给机器看的，注释是写给人看的。”但真正的智慧，是写在架构里的。
还有什么不懂的？评论区留言挨个回。 比如：你遇到过最坑的并发 Bug 是什么？或者，你觉得 LRU 和 LFU 在真实业务中哪个更香？