首先,该文章来自于极客时间网站,王争的专栏——《数据结构与算法之美》,我这里只是做简单的解释、记录并添加自己的见解,只是作为个人笔记,若侵权,马上删除。最后建议直接去该网站上购买该课程看原作者的讲解,一来是支持作者,二来是作者写的确实不错。
在我们学习过的内容中,有很多地方将散列表和链表一起使用。例如:
- 在链表那一节,介绍到如何使用链表实现LRU 缓存淘汰算法,但是链表实现的 LRU 缓存淘汰算法的时间复杂度是 O(n),通过散列表可以将这个时间复杂度降低到 O(1)。
- 在跳表那一节,说过Redis 有序集合不仅使用了跳表,还用到了散列表。
- Java中LinkedHashMap容器也使用到了散列表和链表两种数据结构。
今天我们主要看看散列表和链表是如何组合一起使用的,以及为什么散列表和链表会放在一起使用。
LRU 缓存淘汰算法
首先回顾下我们是如何通过链表实现LRU缓存淘汰算法的。
我们需要维护一个按照访问时间从大到小有序排列的链表结构。因为缓存大小有限,当缓存空间不够,需要淘汰一个数据的时候,我们就直接将链表头部的结点删除。
当要缓存某个数据的时候,先在链表中查找这个数据。如果没有找到,则直接将数据放到链表的尾部;如果找到了,我们就把它移动到链表的尾部。因为查找数据需要遍历链表,所以单纯用链表实现的 LRU 缓存淘汰算法的时间复杂很高,是 O(n)。
实际上,一个缓存(cache)系统主要包含下面这几个操作:
- 往缓存中添加一个数据;
- 从缓存中删除一个数据;
- 在缓存中查找一个数据。
这几个操作都有一个共同点——都需要查询操作。如果单纯地采用链表的话,时间复杂度只能是 O(n)。如果我们将散列表和链表两种数据结构组合使用,可以将这三个操作的时间复杂度都降低到 O(1)。具体的结构就是下面这个样子:
在这个数据结构中,基本架构为双向链表,链表中的每个结点处理存储数据(data)、前驱指针(prev)、后继指针(next)之外,还新增了一个特殊的字段 hnext。
因为我们的散列表是通过链表法解决散列冲突的,所以每个结点会在两条链中。一个链是刚刚我们提到的双向链表,另一个链是散列表中的拉链。前驱和后继指针是为了将结点串在双向链表中,hnext 指针是为了将结点串在散列表的拉链中。
了解了这个数据结构后,我们看下上面提到的三个操作是如何做到时间复杂度为O(1)的。
首先,我们来看如何查找一个数据。查找数据时我们通过散列表进行查询,这是因为散列表查询一个数据时间复杂度接近O(1),所以通过散列表,我们可以很快在缓存中找到一个数据。当找到数据之后,还需要将它移动到双向链表的尾部。在散列表中的位置不变。
其次,我们来看如何删除一个数据。我们需要找到数据所在的结点,然后将结点删除。借助散列表,我们可以在 O(1) 时间复杂度里找到要删除的结点。因为我们的链表是双向链表,双向链表可以通过前驱指针 O(1) 时间复杂度获取前驱结点,所以在双向链表中,删除结点只需要 O(1) 的时间复杂度。
最后,我们来看如何添加一个数据。添加数据到缓存稍微有点麻烦,我们需要先看这个数据是否已经在缓存中。如果已经在其中,需要将其移动到双向链表的尾部;如果不在其中,还要看缓存有没有满。如果满了,则将双向链表头部的结点删除,然后再将数据放到链表的尾部;如果没有满,就直接将数据放到链表的尾部。
通过上述步骤,我们可以发现散列表在这里主要起到加快查找效率的作用。也就是整个过程涉及到查找操作都可以通过散列表来完成。其他的操作,比如删除头结点、链表尾部插入数据等,都可以在 O(1) 的时间复杂度内完成。所以,这三个操作的时间复杂度都是 O(1)。至此,我们就通过散列表和双向链表的组合使用,实现了一个高效的、支持 LRU 缓存淘汰算法的缓存系统原型。
Redis 有序集合
在有序集合中,每个成员对象有两个重要的属性,key(键值)和 score(分值)。我们不仅会通过 score 来查找数据,还会通过 key 来查找数据。
举个例子,比如用户积分排行榜有这样一个功能:我们可以通过用户的 ID 来查找积分信息,也可以通过积分区间来查找用户 ID 或者姓名信息。这里包含 ID、姓名和积分的用户信息,就是成员对象,用户 ID 就是 key,积分就是 score。
对Redis 有序集合的操作进行细化,如下:
- 添加一个成员对象;
- 按照键值来删除一个成员对象;
- 按照键值来查找一个成员对象;
- 按照分值区间查找数据,比如查找积分在[100, 356]之间的成员对象;
- 按照分值从小到大排序成员变量;
如果我们仅仅按照 score 将成员对象组织成跳表的结构,那按照 key 来删除、查询成员对象就会很慢,解决方法与 LRU 缓存淘汰算法的解决方法类似。我们可以再按照 key 构建一个散列表,这样按照 key 来删除、查找一个成员对象的时间复杂度就变成了 O(1)。同时,借助跳表结构,其他操作也非常高效。
实际上,Redis 有序集合的操作还有另外一类,也就是查找成员对象的排名(Rank)或者根据排名区间查找成员对象。这个功能单纯用刚刚讲的这种组合结构就无法高效实现了。这块内容后面再说。
Java LinkedHashMap
Java中 HashMap 底层是通过散列表这种数据结构实现的。而 LinkedHashMap 前面比 HashMap 多了一个“Linked”。那么这个”Linked“是什么意思呢?
我们看看下面代码,它会以什么顺序打印3,1,5,2这几个key呢?
1 | HashMap<Integer, Integer> m = new LinkedHashMap<>(); |
上面的代码是按照数据插入的顺序依次打印的,也就是打印的顺序为3,1,5,2。但是,值得怀疑的一点是,散列表中的数据是经过散列函数打乱之后无规律存储的,这里是如何实现按照数据的插入顺序来遍历打印呢?
实际上,LinkedHashMap 也是通过散列表和链表组合在一起实现的这个功能。实际上,它不仅仅支持按照插入顺序遍历数据,还支持按照访问顺序来遍历数据,代码如下
1 | // 10是初始大小,0.75是装载因子,true是表示按照访问时间排序 |
这段代码打印的结果是 1,2,3,5。每次调用put()函数,往LinkedHashMap 中添加数据时,都会将数据添加到链表的尾部,所以在前四个操作完成后,链表中的数据(还有哈希表中的数据形式)时下面这样的:
下面一句m.put(3, 26);
再次将键值为 3 的数据放入到 LinkedHashMap 的时候,会先查找这个键值是否已经有了,然后,再将已经存在的 (3,11) 删除,并且将新的 (3,26) 放到链表的尾部。所以,这个时候链表中的数据就是下面这样:
当运行到m.get(5);
这一行时,我们将访问到的数据移动到链表的尾部。链表中的数据时下面这样的:
所以,最后打印出来的数据是 1,2,3,5。发现按照访问时间排序的 LinkedHashMap 本身就是一个支持 LRU 缓存淘汰策略的缓存系统。实际上,它们两个的实现原理也是一模一样的。
总结:LinkedHashMap 是通过双向链表和散列表这两种数据结构组合实现的。LinkedHashMap 中的“Linked”实际上是指的是双向链表,并非指用链表法解决散列冲突。
解答开篇&内容小结
为什么散列表和链表经常一块使用?
散列表这种数据结构虽然支持非常高效的数据插入、删除、查找操作,但是散列表中的数据都是通过散列函数打乱之后无规律存储的。也就说,它无法支持按照某种顺序快速地遍历数据。如果希望按照顺序遍历散列表中的数据,那我们需要将散列表中的数据拷贝到数组中,然后排序,再遍历。
因为散列表是动态数据结构,不停地有数据的插入、删除,所以每当我们希望按顺序遍历散列表中的数据的时候,都需要先排序,那效率势必会很低。为了解决这个问题,我们将散列表和链表(或者跳表)结合在一起使用。
课后思考
今天讲的几个散列表和链表结合使用的例子里,我们用的都是双向链表。如果把双向链表改成单链表,还能否正常工作呢?为什么呢?
答:这个替换主要影响的是删除操作。在删除一个元素时,虽然能 O(1) 的找到目标结点,但是要删除该结点需要拿到前一个结点的指针,遍历到前一个结点复杂度会变为 O(N),所以用双链表实现比较合适。
假设猎聘网有 10 万名猎头,每个猎头都可以通过做任务(比如发布职位)来积累积分,然后通过积分来下载简历。假设你是猎聘网的一名工程师,如何在内存中存储这 10 万个猎头 ID 和积分信息,让它能够支持这样几个操作:
- 根据猎头的 ID 快速查找、删除、更新这个猎头的积分信息;
- 查找积分在某个区间的猎头 ID 列表;
- 查找按照积分从小到大排名在第 x 位到第 y 位之间的猎头 ID 列表。
答:以积分排序构建一个跳表,再以猎头 ID 构建一个散列表。第一个操作ID 在散列表中所以可以 O(1) 查找到这个猎头;第二个操作积分以跳表存储,跳表支持区间查询;第三个操作目前学习的知识暂时无法实现。