Redis源码解析——字典遍历
来源:互联网 发布:淘宝卖家信息采集软件 编辑:程序博客网 时间:2024/04/30 14:50
之前两篇博文讲解了字典库的基础,本文将讲解其遍历操作。之所以将遍历操作独立成一文来讲,是因为其中的内容和之前的基本操作还是有区别的。特别是高级遍历一节介绍的内容,充满了精妙设计的算法智慧。(转载请指明出于breaksoftware的csdn博客)
生成一个迭代器的方法很简单,该字典库提供了两种方式: 可以见得,它使用了ht[0]和ht[1]的相关信息进行Hash运算,从而得到该字典的指纹。我们可以发现,如果dictht的table、size和used任意一个有变化,则指纹将被改变。这也就意味着,扩容、锁容、rehash、新增元素和删除元素都会改变指纹(除了修改元素内容)。
假如第8次迭代后,数组瞬间扩容,这个时候遍历过程是
此时多了一次对下标为15的遍历,可以想象这次遍历应该会重复下标为15%8=7遍历(即第8次)的元素。所以dictScan具有潜在对一个元素遍历多次的问题。我们再看第7次迭代时发生瞬间扩容的情况
此时数组下标为11的遍历(即第8次遍历)会部分重复下标为3的遍历(即第7次遍历)元素。而之后的遍历就不会重复了。
如果第16次遍历时突然缩容,则遍历过程是
可见第16次遍历的是新数组下标为7的元素,和第15次遍历老数组下标为7的元素不同,本次遍历的结果包含前者(因为它还包含之前下标为15的元素)。所以也存在元素重复遍历的问题。
迭代器遍历
由于Redis字典库有rehash机制,而且是渐进式的,所以迭代器操作可能会通过其他特殊方式来实现,以保证能遍历到所有数据。但是阅读完源码发现,其实这个迭代器是个受限的迭代器,实现方法也很简单。我们先看下其基础结构:
成员变量d指向迭代器处理的字典。index是dictht中table数组的下标。table是dict结构中dictht数组的下标,即标识ht[0]还是ht[1]。safe字段用于标识该迭代器是否为一个安全的迭代器。如果是,则可以在迭代过程中使用dictDelete、dictFind等方法;如果不是,则只能使用dictNext遍历方法。entry和nextEntry分别指向当前的元素和下一个元素。fingerprint是字典的指纹,我们可以先看下指纹算法的实现:
生成一个迭代器的方法很简单,该字典库提供了两种方式:
然后我们看下遍历迭代器的操作。如果是初次迭代,则要查看是否是安全迭代器,如果是安全迭代器则让其对应的字典对象的iterators自增;如果不是则记录当前字典的指纹
因为要遍历的时候,字典可以已经处于rehash的中间状态,所以还要遍历ht[1]中的元素
往往使用迭代器获得元素后,会让字典删除这个元素,这个时候就无法通过迭代器获取下一个元素了,于是作者设计了nextEntry来记录当前对象的下一个对象指针
遍历完成后,要调用下面方法释放迭代器。需要注意的是,如果是安全迭代器,就需要让其指向的字典的iterators自减以还原;如果不是,则需要检测前后字典的指纹是否一致
最后我们探讨下什么是安全迭代器。源码中我们看到如果safe为1,则让字典iterators自增,这样dict字典库中的操作就不会触发rehash渐进,从而在一定程度上(消除rehash影响,但是无法阻止用户删除元素)保证了字典结构的稳定。如果不是安全迭代器,则只能使用dictNext方法遍历元素,而像获取元素值的dictFetchValue方法都不能调用。因为dictFetchValue底层会调用_dictRehashStep让字典结构发生改变。
但是作者在源码说明中说安全迭代器在迭代过程中可以使用dictAdd方法,但是我觉得这个说法是错误的。因为dictAdd方法插入的元素可能在当前遍历的对象之前,这样就在之后的遍历中无法遍历到;也可能在当前遍历的对象之后,这样就在之后的遍历中可以遍历到。这样一种动作,两种可能结果的方式肯定是有问题的。我查了下该库在Redis中的应用,遍历操作不是为了获取值就是为了删除值,而没有增加元素的操作,如
高级遍历
高级遍历允许ht[0]和ht[1]之间数据在迁移过程中进行遍历,通过相应的算法可以保证所有的元素都可以被遍历到。我们先看下功能的实现:
参数d是字典的指针;v是迭代器,这个迭代器初始值为0,每次调用dictScan都会返回一个新的迭代器。于是下次调用这个函数时要传入新的迭代器的值。fn是个函数指针,每遍历到一个元素时,都是用该函数对元素进行操作。
Redis中这个方法的调用样例是:
对于不在rehash状态的字典,则只要对ht[0]中迭代器指向的链表进行遍历就行了
如果在rehash状态,就要遍历ht[0]和ht[1]。遍历前要确定哪个dictht.table长度短(假定其长度为len=8),先对短的中该迭代器(假定为iter=4)对应的链进行遍历,然后遍历大的。然而不仅要遍历大的dictht中迭代器(iter=4)对应的链,还要遍历比iter大len的迭代器(4+8=12)对应的链表。
最后要重新计算下次使用的迭代器并返回
从上面的设计来看,调用dictScan时不能有多线程操作该字典,否则会出现遗漏遍历的情况。但是在每次调用dictScan之间可以对字典进行操作。
其实这个遍历中最核心的是迭代器v的计算方法,我们只要让v从0开始,执行“或操作”最短ht.table(~m0)大小、二进制翻转、加1、再二进制翻转就可以实现0到~m0的遍历。我们看个例子:
我一直想不出这套算法为什么能满足这样的特点,还是需要数学大神解释一下。同时也可见这种算法的作者Pieter Noordhuis数学有一定功底。
关键这样的算法不仅可以完成遍历,还可以在数组大小动态变化时保证元素被全部遍历到。我把代码提炼出来,模拟了长度为8的数组向长度为16的数组扩容,和长度为16的数组向长度为8的数组缩容的过程。为了让问题简单化,我们先不考虑两个数组的问题,只认为数组在一瞬间被扩容和缩容。
我们先看下扩容前的遍历过程
假如第8次迭代后,数组瞬间扩容,这个时候遍历过程是
此时多了一次对下标为15的遍历,可以想象这次遍历应该会重复下标为15%8=7遍历(即第8次)的元素。所以dictScan具有潜在对一个元素遍历多次的问题。我们再看第7次迭代时发生瞬间扩容的情况
此时数组下标为11的遍历(即第8次遍历)会部分重复下标为3的遍历(即第7次遍历)元素。而之后的遍历就不会重复了。
我们再看下数组的缩容。为缩容前的状态是
如果第16次遍历时突然缩容,则遍历过程是
可见第16次遍历的是新数组下标为7的元素,和第15次遍历老数组下标为7的元素不同,本次遍历的结果包含前者(因为它还包含之前下标为15的元素)。所以也存在元素重复遍历的问题。
我们看下第15次遍历时突然缩容的遍历过程
因为缩容到8,所以最后一次遍历下标7的情况,既包括之前老数组下标为7的元素,也包含老数组下标为15的元素。所以本次遍历不会产生重复遍历元素的问题。
我们再看下第14次遍历突然缩容的遍历过程
第14次本来是要遍历下标为11的元素。由于发生缩容,就遍历新的数组的下标为3的元素。所以第14的遍历包含第13次的遍历元素。
一个数组如此,像dict结构中有两个dictht的情况,则稍微复杂点。我们通过下图可以发现,不同时机ht[0]扩容或者缩容,都可以保证元素被全遍历
上面测试的代码是:
0 0
- Redis源码解析——字典遍历
- Redis源码解析——字典遍历
- Redis源码解析——字典结构
- Redis源码解析:04字典的遍历dictScan
- Redis源码解析——字典基本操作
- Redis源码解析:03字典
- Redis源码学习——字典
- Redis源码分析(三)——Redis数据结构-字典
- Redis源码解析—源码目录介绍
- Redis的字典(dict)rehash过程源码解析
- Redis的字典(dict)rehash过程源码解析
- Redis源码解析——前言
- Redis源码解析——内存管理
- Redis源码解析——Zipmap
- Redis源码解析(1)——源码目录介绍
- Redis源码解析(1)——源码目录介绍
- Redis源码解析(1)——源码目录介绍
- Redis源码解析(1)—源码目录介绍
- Android平台美颜相机/Camera实时滤镜/视频编解码/影像后期/人脸技术探索——2.2 来一份LOMO滤镜
- 初出茅庐
- 折纸问题
- 程序功能:建立一个带有头结点的单向链表,并将存储在数组中的字符依次转储到链表的各个结点中。
- String类的intern()方法详解
- Redis源码解析——字典遍历
- 为什么要做A.prototype.constructor=A这样的修正?
- [Leetcode] #104 Maximum Depth of Binary Tree
- mysql免安装版安装教程
- Unity3D脚本批量打渠道包
- spring mvc 拦截器
- leetcode 75. Sort Colors
- 二叉树遍历解析
- 开发个AndroidStudio可以使用的插件玩玩