前言
我们前面简单实现了 redis 的几个特性，java从零手写实现redis(一)如何实现固定大小的缓存？ 中实现了先进先出的驱除策略。
但是实际工作实践中，一般推荐使用 LRU/LFU 的驱除策略。
LRU 基础知识
拓展学习
LRU 是什么
LRU 是由 Least Recently Used 的首字母组成，表示最近最少使用的含义，一般使用在对象淘汰算法上。
也是比较常见的一种淘汰算法。
其核心思想是如果数据最近被访问过，那么将来被访问的几率也更高。
连续性
在计算机科学中，有一个指导准则：连续性准则。
时间连续性：对于信息的访问，最近被访问过，被再次访问的可能性会很高。缓存就是基于这个理念进行数据淘汰的。
空间连续性：对于磁盘信息的访问，将很有可能访问连续的空间信息。所以会有 page 预取来提升性能。
实现步骤
新数据插入到链表头部；
每当缓存命中(即缓存数据被访问)，则将数据移到链表头部；
当链表满的时候，将链表尾部的数据丢弃。
其实比较简单，比起 FIFO 的队列，我们引入一个链表实现即可。
一点思考
我们针对上面的 3 句话，逐句考虑一下，看看有没有值得优化点或者一些坑。
如何判断是新数据？
(1) 新数据插入到链表头部；
我们使用的是链表。
判断新数据最简单的方法就是遍历是否存在，对于链表，这是一个 O(n) 的时间复杂度。
其实性能还是比较差的。
当然也可以考虑空间换时间，比如引入一个 set 之类的，不过这样对空间的压力会加倍。
什么是缓存命中
(2)每当缓存命中(即缓存数据被访问)，则将数据移到链表头部；
put(key,value) 的情况，就是新元素。如果已有这个元素，可以先删除，再加入，参考上面的处理。
get(key) 的情况，对于元素访问，删除已有的元素，将新元素放在头部。
remove(key) 移除一个元素，直接删除已有元素。
keySet() valueSet() entrySet() 这些属于无差别访问，我们不对队列做调整。
移除
(3)当链表满的时候，将链表尾部的数据丢弃。
链表满只有一种场景，那就是添加元素的时候，也就是执行 put(key, value) 的时候。
直接删除对应的 key 即可。
java 代码实现
接口定义
和 FIFO 的接口保持一致，调用地方也不变。
为了后续 LRU/LFU 实现，新增 remove/update 两个方法。
public interface ICacheEvict {
/**
* 驱除策略
*
* @param context 上下文
* @since 0.0.2
* @return 是否执行驱除
*/
boolean evict(final ICacheEvictContext context);
/**
* 更新 key 信息
* @param key key
* @since 0.0.11
*/
void update(final K key);
/**
* 删除 key 信息
* @param key key
* @since 0.0.11
*/
void remove(final K key);
}
LRU 实现
直接基于 LinkedList 实现：
/**
* 丢弃策略-LRU 最近最少使用
* @author binbin.hou
* @since 0.0.11
*/
public class CacheEvictLRU implements ICacheEvict {
private static final Log log = LogFactory.getLog(CacheEvictLRU.class);
/**
* list 信息
* @since 0.0.11
*/
private final List list = new LinkedList<>();
@Override
public boolean evict(ICacheEvictContext context) {
boolean result = false;
final ICache cache = context.cache();
// 超过限制，移除队尾的元素
if(cache.size() >= context.size()) {
K evictKey = list.get(list.size()-1);
// 移除对应的元素
cache.remove(evictKey);
result = true;
}
return result;
}
/**
* 放入元素
* (1)删除已经存在的
* (2)新元素放到元素头部
*
* @param key 元素
* @since 0.0.11
*/
@Override
public void update(final K key) {
this.list.remove(key);
this.list.add(0, key);
}
/**
* 移除元素
* @param key 元素
* @since 0.0.11
*/
@Override
public void remove(final K key) {
this.list.remove(key);
}
}
实现比较简单，相对 FIFO 多了三个方法：
update()：我们做一点简化，认为只要是访问，就是删除，然后插入到队首。
remove()：删除就是直接删除。
这三个方法是用来更新最近使用情况的。
那什么时候调用呢？
注解属性
为了保证核心流程，我们基于注解实现。
添加属性：
/**
* 是否执行驱除更新
*
* 主要用于 LRU/LFU 等驱除策略
* @return 是否
* @since 0.0.11
*/
boolean evict() default false;
注解使用
有哪些方法需要使用？
@Override
@CacheInterceptor(refresh = true, evict = true)
public boolean containsKey(Object key) {
return map.containsKey(key);
}
@Override
@CacheInterceptor(evict = true)
@SuppressWarnings("unchecked")
public V get(Object key) {
//1. 刷新所有过期信息
K genericKey = (K) key;
this.expire.refreshExpire(Collections.singletonList(genericKey));
return map.get(key);
}
@Override
@CacheInterceptor(aof = true, evict = true)
public V put(K key, V value) {
//...
}
@Override
@CacheInterceptor(aof = true, evict = true)
public V remove(Object key) {
return map.remove(key);
}
注解驱除拦截器实现
执行顺序：放在方法之后更新，不然每次当前操作的 key 都会被放在最前面。
/**
* 驱除策略拦截器
*
* @author binbin.hou
* @since 0.0.11
*/
public class CacheInterceptorEvict implements ICacheInterceptor {
private static final Log log = LogFactory.getLog(CacheInterceptorEvict.class);
@Override
public void before(ICacheInterceptorContext context) {
}
@Override
@SuppressWarnings("all")
public void after(ICacheInterceptorContext context) {
ICacheEvict evict = context.cache().evict();
Method method = context.method();
final K key = (K) context.params()[0];
if("remove".equals(method.getName())) {
evict.remove(key);
} else {
evict.update(key);
}
}
}
我们只对 remove 方法做下特判，其他方法都使用 update 更新信息。
参数直接取第一个参数。
测试
ICache cache = CacheBs.newInstance()
.size(3)
.evict(CacheEvicts.lru())
.build();
cache.put("A", "hello");
cache.put("B", "world");
cache.put("C", "FIFO");
// 访问一次A
cache.get("A");
cache.put("D", "LRU");
Assert.assertEquals(3, cache.size());
System.out.println(cache.keySet());
日志信息
[D, A, C]
通过 removeListener 日志也可以看到 B 被移除了：
[DEBUG] [2020-10-02 21:33:44.578] [main] [c.g.h.c.c.s.l.r.CacheRemoveListener.listen] - Remove key: B, value: world, type: evict
小结
redis LRU 淘汰策略，实际上并不是真正的 LRU。
LRU 有一个比较大的问题，就是每次 O(n) 去查找，这个在 keys 数量特别多的时候，还是很慢的。
如果 redis 这么设计肯定慢的要死了。
个人的理解是可以用空间换取时间，比如添加一个 Map<String, Integer> 存储在 list 中的 keys 和下标，O(1) 的速度去查找，但是空间复杂度翻倍了。
不过这个牺牲还是值得的。这种后续统一做下优化，将各种优化点统一考虑，这样可以统筹全局，也便于后期统一调整。
下一节我们将一起来实现以下改进版的 LRU。
Redis 做的事情，就是将看起来的简单的事情，做到一种极致，这一点值得每一个开源软件学习。
文中主要讲述了思路，实现部分因为篇幅限制，没有全部贴出来。
觉得本文对你有帮助的话，欢迎点赞评论收藏关注一波~
你的鼓励，是我最大的动力~
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
