一个改进 LRU 算法的缓冲池 update 2013.7.15
首先,这里的缓冲池指的是 Cache,而不是 Buffer,就是指将代价较大的对象先存储起来,以备以后需要的时候可以直接拿来用,能够节约一些时间或空间。
当缓冲池中的对象过多时,就需要删掉一些“不会再用”的对象来节约内存。但是没人能够知道某个对象什么时候会再用,因此这就涉及到缓存替换算法了,好的缓存替换算法可以有更大的概率删掉“不会再用”的对象,能够保留“很可能再用”的对象。
现在发明的缓存替换算法有很多,除了只有理论意义的 OPT(Optimal,最优替换,也就是上帝模式)和听天由命的随机替换,常用的有 LRU(Least recently used,最近最少使用),LFU(Least Frequently Used,最不经常使用)和 FIFO(First in first out,先进先出)以及很多改进算法。其中 LRU 算法经常被使用,我也打算使用 LRU 算法来实现一个缓冲池。
一、改进的 LRU 算法
LRU 算法认为最近被访问的对象,以后也很可能被访问。因此,在实现时,一般使用一个哈希表类存储被缓存的对象,和一个双向链表类存储对象被使用的情况:如果一个对象被访问了,就将它提升到链表的头部,如图1所示,这样就能保证最近被访问的对象总是更接近头部。当添加新对象时,直接添加到链表的头部;当需要淘汰旧对象时,就从链表的尾部(最久没有被访问)开始淘汰。
图1 K 被访问了,提升到链表的头部。
LRU 算法的实现还是比较容易的,但是由于每个操作都会有链表的修改,因此在并发访问时都每个操作需要加锁(双向链表没有无锁版的,只有单向链表有),不太利于并发访问。
同时,LRU 只将对象“最近是否被访问”作为度量指标,并不准确,偶发性和周期性的操作会导致 LRU 的命中率急剧下降,因此也提出了很多 LRU 的改进算法,例如 LRU-K,2Q,以及命中率更高的 LIRS 算法(它的论文是这么说的)。
后来,无意间看到了《OCP知识点讲解 之 LRU链与脏LRU链》这篇文章,里面介绍了一种 Oracle 改进的 LRU 算法,感觉效果会不错,实现起来也比较简单,因此使用该算法来实现缓冲池。
这个改进的算法将 LRU 链从中间分成了两半,前一半是热端,后一半是冷端,如图2所示。热端记录的是访问次数大于等于两次的对象,它们被认为可能会被经常访问到,冷端记录的是访问次数为一次的对象。区分热端和冷端,就可以保留访问次数较大的对象,同时更快的淘汰掉只访问了一次的对象,使命中情况更好,2Q 等改进算法使用的也是类似的思想。如果热端和冷端并不平均分配,就可以更快或更慢的淘汰掉只访问了一次的对象。
图2 改进的 LRU 链表,图片来自文章《OCP知识点讲解 之 LRU链与脏LRU链》
改进算法中还为每个对象的添加了访问次数,这样可以将冷端被经常访问的对象添加到热端,热端的对象也会被“降级”到冷端。下面则是具体的实现分析,为了方便起见,无论是热端还是冷端,都将左边作为头,右边作为尾。
1. 添加新对象
- 缓存空间还未满:与标准的 LRU 一样,总是插入到热端的头。因为此时缓存空间还足够,没必要区分对象是否被多次访问,之后在淘汰旧对象时自然可以区分出来。
- 缓存空间已满:这时先淘汰旧的对象,再将新对象添加到冷端的头。因为新添加对象的访问次数总是 1,所以应当放到冷端。
2. 访问对象
这里直接递增对象的访问计数即可,因此这个算法的并发访问效率可以提高一些。
3. 淘汰旧对象
淘汰旧对象是从冷端的末尾开始的,但并不是顺序进行淘汰,而是如果冷端末尾的对象的访问次数大于等于2,就认为可能会被经常访问,则将它移动到热端的头,并将访问次数清零,同时热端的末尾被淘汰到冷端的头。然后继续尝试淘汰,直到对象的访问次数小于2。清零访问次数保证了一定可以找到被淘汰的对象。
在淘汰旧对象时,如果访问次数大于等于2,并不需要真的每次都移除末尾节点再将它移动到热端的头。因为双向链表可以以环形存储(System.Collections.Generic.LinkedList<T> 就是这么干的),也就是说 Head.Prev = Tail && Tail.Next = Head,所以这个移动过程就相当于将 head 变为 Head.Prev(也就是前移一位),如图3所示:淘汰从 H 开始,但是 H 的访问次数大于 2,就将 Head 从 A 移动到 H,H 自然就被添加到热端的头了,下一次尝试也就从 G 继续进行。
图3 尝试淘汰访问次数大于等于 2 的 H。
淘汰旧对象这里感觉很像 Clock 算法,不过 Clock 总是存储到刚被淘汰的位置,改进的 LRU 算法则是存储到冷端的头。
二、缓冲池接口定义
缓冲池接口的定义如下,是像 Dictioary 一样利用键来检索对象。在添加对象时,总是会覆盖旧对象;在检索时,由于必须要对对象的有效性进行判断(说不定什么时候就被替换掉了),因此提供的是 TryGet 方法而不是抛异常。为了方便使用缓冲池,加入了 GetOrAdd,这样就不用每次都自己判断对象是否存在了。
using System; namespace Cyjb.Utility { /// <summary> /// 表示缓冲池的接口。 /// </summary> /// <typeparam name="TKey">缓冲对象的键的类型。</typeparam> /// <typeparam name="TValue">缓冲对象的类型。</typeparam> public interface ICache<TKey, TValue> { /// <summary> /// 将指定的键和对象添加到缓存中,无论键是否存在。 /// </summary> /// <param name="key">要添加的对象的键。</param> /// <param name="value">要添加的对象。</param> /// <exception cref="System.ArgumentNullException"><paramref name="key"/> 为 <c>null</c>。</exception> void Add(TKey key, TValue value); /// <summary> /// 清空缓存中的所有对象。 /// </summary> void Clear(); /// <summary> /// 确定缓存中是否包含指定的键。 /// </summary> /// <param name="key">要在缓存中查找的键。</param> /// <returns>如果缓存中包含具有指定键的元素,则为 <c>true</c>;否则为 <c>false</c>。</returns> /// <exception cref="System.ArgumentNullException"><paramref name="key"/> 为 <c>null</c>。</exception> bool Contains(TKey key); /// <summary> /// 从缓存中获取与指定的键关联的对象,如果不存在则将对象添加到缓存中。 /// </summary> /// <param name="key">要获取的对象的键。</param> /// <param name="valueFactory">用于为键生成对象的函数。</param> /// <returns>如果在缓存中找到该键,则为对应的对象;否则为 <paramref name="valueFactory"/> 返回的新对象。</returns> /// <exception cref="System.ArgumentNullException"><paramref name="key"/> 为 <c>null</c>。</exception> TValue GetOrAdd(TKey key, Func<TKey, TValue> valueFactory); /// <summary> /// 从缓存中移除并返回具有指定键的对象。 /// </summary> /// <param name="key">要移除并返回的对象的键。</param> /// <exception cref="System.ArgumentNullException"><paramref name="key"/> 为 <c>null</c>。</exception> void Remove(TKey key); /// <summary> /// 尝试从缓存中获取与指定的键关联的对象。 /// </summary> /// <param name="key">要获取的对象的键。</param> /// <param name="value">此方法返回时,<paramref name="value"/> 包含缓存中具有指定键的对象; /// 如果操作失败,则包含默认值。</param> /// <returns>如果在缓存中找到该键,则为 <c>true</c>;否则为 <c>false</c>。</returns> /// <exception cref="System.ArgumentNullException"><paramref name="key"/> 为 <c>null</c>。</exception> bool TryGet(TKey key, out TValue value); } }
三、缓冲池的实现
缓冲池中,使用 ReaderWriterLockSlim 读写锁来实现并发访问,自己实现了一个双向环形链表来将对象链起来。如果对象实现了 System.IDisposable 接口,会在移除或替换对象时自动调用 Dispose 方法,这里需要注意的是 Dispose 最好在锁之外调用,防止 Dispose 方法导致锁不能尽快被释放掉。
添加对象的核心代码是:
LruNode<TKey, TValue> node; IDisposable disposable = null; cacheLock.EnterWriteLock(); try { if (cacheDict.TryGetValue(key, out node)) { // 更新节点。 node.Value = value; // 写锁互斥,这里不用 Interlocked。 node.VisitCount++; return; } else { if (count < maxSize) { // 将节点添加到热端起始。 node = new LruNode<TKey, TValue>(key, value); AddHotFirst(node); // 写锁互斥,这里不用 Interlocked。 count++; if (count == hotSize + 1) { codeHead = head.Prev; } cacheDict.Add(key, node); return; } else { // 从冷端末尾尝试淘汰旧节点,将访问次数大于 1 的移动到热端的头。 // 由于双向链表是环形存储的,就相当于将 head 前移。 while (head.Prev.VisitCount >= 2) { // 清零访问计数。 head.Prev.VisitCount = 0; head = head.Prev; codeHead = codeHead.Prev; } // 将 node 移除,并添加到冷端的头。 node = head.Prev; disposable = node.Value as IDisposable; this.cacheDict.Remove(node.Key); this.Remove(node); // 这里直接重用旧节点。 node.Key = key; node.Value = value; node.VisitCount = 1; this.AddCodeFirst(node); cacheDict.Add(key, node); } } } finally { cacheLock.ExitWriteLock(); } if (disposable != null) { disposable.Dispose(); }
可以看到,如果要添加的对象的键已存在,是直接替换旧对象的。双向链表的节点也都是重用的,所以没必要使用对象池(应该不会经常删除缓存项把……)。
在下面的 GetOrAdd 方法中,实际上就是分别调用了 TryGet 方法和 AddInternal 方法,这么做可能会导致不必要的对象创建,但是为了保证 valueFactory 不会长时间的占用写锁,因此只好这么做了。
public TValue GetOrAdd(TKey key, Func<TKey, TValue> valueFactory) { ExceptionHelper.CheckArgumentNull(key, "key"); ExceptionHelper.CheckArgumentNull(valueFactory, "valueFactory"); TValue value; if (this.TryGet(key, out value)) { return value; } value = valueFactory(key); this.AddInternal(key, value); return value; }
2013.7.15 更新:这里可以利用 System.Lazy<T> 类来防止多次调用 valueFactory,即将对象用 Lazy<TValue> 包装起来,在获取对象时只会获取到 Lazy<TValue> 对象,实际对象的初始化则被 Lazy<TValue> 推迟了,同时也不会导致长时间占用写锁(只要得到了 Lazy<TValue> 对象就可以释放锁了),防止 valueFactory 多次被调用则由 Lazy<TValue> 完成。
缓冲池的实现基本就这样了,具体的代码可以见 Cyjb.Utility。
四、命中率的测试
最后,稍微写了一段代码来测试算法的命中率,测试的四个算法分别是 OPT,改进的 LRU,普通的 LRU 和 FIFO。下面先附上测试代码:
int maxCacheSize = 200; // 初始化数据。 int[] data = new int[100000]; Random random = new Random(); for (int i = 0; i < data.Length; i++) { if (random.Next(10) < 1) { data[i] = random.Next(10000); } else { data[i] = random.Next(10000); } } // OPT。 int miss = 0; Dictionary<int, int> nextVisit = new Dictionary<int, int>(); HashSet<int> optCache = new HashSet<int>(); for (int i = 0; i < data.Length; i++) { if (!optCache.Contains(data[i])) { miss++; if (optCache.Count >= maxCacheSize) { int minI = 0, maxVisit = 0; foreach (int j in optCache) { if (!nextVisit.ContainsKey(j)) { nextVisit.Add(j, 0); } if (nextVisit[j] <= i) { nextVisit[j] = int.MaxValue; for (int k = i + 1; k < data.Length; k++) { if (data[k] == j) { nextVisit[j] = k; break; } } } if (nextVisit[j] > maxVisit) { maxVisit = nextVisit[j]; minI = j; if (maxVisit == int.MaxValue) { break; } } } optCache.Remove(minI); } optCache.Add(data[i]); } } Console.WriteLine("OPT:{0}%", 100 - miss * 100.0 / data.Length); // LRU。 miss = 0; ICache<int, int> cache = new LruCache<int, int>(maxCacheSize); for (int i = 0; i < data.Length; i++) { int value; if (!cache.TryGet(data[i], out value)) { cache.Add(data[i], data[i]); miss++; } } Console.WriteLine("LRU:{0}%", 100 - miss * 100.0 / data.Length); // 普通 LRU。 miss = 0; cache = new LruNormalCache<int, int>(maxCacheSize); for (int i = 0; i < data.Length; i++) { int value; if (!cache.TryGet(data[i], out value)) { cache.Add(data[i], data[i]); miss++; } } Console.WriteLine("LRU_Normal:{0}%", 100 - miss * 100.0 / data.Length); // FIFO。 miss = 0; Queue<int> queue = new Queue<int>(); HashSet<int> set = new HashSet<int>(); for (int i = 0; i < data.Length; i++) { if (!set.Contains(data[i])) { set.Add(data[i]); miss++; queue.Enqueue(data[i]); if (queue.Count > maxCacheSize) { set.Remove(queue.Dequeue()); } } } Console.WriteLine("FIFO:{0}%", 100 - miss * 100.0 / data.Length);
下面是一些测试结果,缓冲池大小都是 200,数据个数是 10W,第一列表示数据的范围,50% 0~1000,50% 0~150 表示有 50% 的数据范围是 0~1000,50% 的数据范围是 0~150(这里给出的测试实际上不太严谨,数据范围应该是取 0~150 和 151~1000 的,现在的测试方法实际上有 57.5% 的数据范围是 0~150,42.5% 的数据范围是 151~1000)。表格中的数值表示命中率。
数据范围 | OPT | 改进LRU | 普通LRU | FIFO |
50% 0~1000,50% 0~150 | 70.745% | 50.966% | 41.532% | 37.325% |
10% 0~1000,90% 0~150 |
93.851%
|
91.79% | 89.941% | 78.46% |
10% 0~10000,90% 0~500 | 66.59% | 34.056% | 32.056% | 31.342% |
10% 0~10000,90% 0~5000 | 24.617% | 3.705% | 3.60599999999999% | 3.605% |
100% 0~10000 | 18.739% | 2.04000000000001% | 2.05500000000001% | 2.063% |
这些只是随意的测试,仅供参考,不过看起来改进的 LRU 还是比较给力的,可以比较好的保留经常被访问的数据。而当所有数据都是随机访问的时候,命中率反而会下降,甚至还不如 FIFO。
对于并发访问的测试,我不太了解怎么弄,所以就没有做,不过个人感觉 ReaderWriterLockSlim 应该就没有问题了。
作者:CYJB
出处:http://www.cnblogs.com/cyjb/
GitHub:https://github.com/CYJB/
本文版权归作者和博客园共有,欢迎转载,但未经作者同意必须保留此段声明,且在文章页面明显位置给出原文连接,否则保留追究法律责任的权利。