Python 字典是如何解决哈希冲突的

本文主要翻译自 so 上面的问题 Why can a Python dict have multiple keys with the same hash? Praveen Gollakota 的答案

  • Python 字典是通过哈希表实现的

  • 哈希表必然存在哈希冲突。比如:就算两个键存在相同的哈希值,哈希表必须要有策略用来明确两个值插入和读取

  • Python 字典使用开放寻址法解决哈希冲突(下面展开讲)(源码:dictobject.c:296-297

  • Python 的哈希表仅仅是一块连续的内存(类似于数组,因此可以使用索引进行 O(1) 的查找)

  • 表里的每个插槽只能存储一个 entry,这是很重要的

  • 表里的每个 entry 实际上存储了三个值,这是由 C 结构实现的(详见 dictobject.h:51-56

  • 下面是 Python 哈希表的逻辑示例图,0,1,...,i,... 这些数是对插槽的索引(仅仅只是为了说明,实际上它们并没有与表格一起存放)

    # Logical model of Python Hash table
    -+-----------------+
    0| <hash|key|value>|
    -+-----------------+
    1|      ...        |
    -+-----------------+
    .|      ...        |
    -+-----------------+
    i|      ...        |
    -+-----------------+
    .|      ...        |
    -+-----------------+
    n|      ...        |
    -+-----------------+
    
  • 新字典初始化时拥有 8 个插槽(见 dictobject.h:49

  • 当往哈希表中添加 entry 时,我们以一些插槽开始,比如 i,它是基于对键的哈希。Cpython 使用 i = hash(key) & mask 初始化(这里 mask = PyDictMINSIZE - 1,但这不是重点),注意初始值 i 取决于对键的哈希

  • 如果该插槽是空的,entry 将会被添加到插槽中(entry 即 <hash|key|value>),如果插槽已经被占用时怎么办呢?这常常是由于其它的 entry 拥有相同的哈希值(即哈希冲突)

  • 如果插槽被占用,CPython(包括 PyPy)会对比已占用的和将被插入的 entry 的哈希值和键(使用 == 对比而不是 is)(见:dictobject.c:337,344-345),如果两个都相同,则认为这个 entry 已经存在,继而转向下一个被插入的 entry。如果存在哈希和键中某一个不匹配,则会开始查找

  • 查找意味它会一个一个的查看插槽是否为空,以找到一个空的插槽。技术上来说,我们可以通过不断加 1,如 i+1,i+2,...一旦找到可用的就停止(即线性查找)。但是,因为某些原因(源代码的注释非常漂亮的阐明了这些原因,见 dictobject.c:33-126),CPython 使用了随机查找。在随机查找中,下一个插槽的位置是一个伪随机数,而 entry 也会被添加到找到的第一个空的插槽中。具体的算法对于本次讨论来说并不太重要(具体可以查看 dictobject.c:33-126)。重要的是当第一个空插槽被找到时,查找则停止

  • 同样的事情也发生在索引的时候,它始于初始化的值 i(i 取决于键的哈希值),如果对应的插槽所在的 entry 哈希值和键都不匹配,则会开始查找,直到找到一个匹配的插槽。如果所有的插槽都找遍了也没有找到匹配的,则会报告错误

  • 另外,字典将会在占用了 2/3 的时候重新调整大小,这会避免降低查找的速度(见 dictobject.h:64-65

实际测试效果如下:

class HashTester(object):
    
    def __init__(self):
        self.value = 42

    def __hash__(self):
        return self.value

    def __eq__(self, other):
        return self.value == other.value
    

class HashTester2(object):

    def __hash__(self):
        return 42
>>> a = HashTester()
>>> b = HashTester()
>>> {a: 'this is a', b: 'this is b'}  # a 与 b 的 hash 和 key 都相等
{<__main__.HashTester object at 0x00000222B7A691C0>: 'this is b'}

>>> e = HashTester2()
>>> f = HashTester2()
>>> {e: 'this is e', f: 'this is f'}  # e 与 f 哈希冲突
{<__main__.HashTester2 object at 0x00000222B7A69CD0>: 'this is e', <__main__.HashTester2 object at 0x00000222B7A690A0>: 'this is f'}
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 202,332评论 5 475
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 84,930评论 2 379
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 149,204评论 0 335
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 54,348评论 1 272
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 63,356评论 5 363
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,447评论 1 281
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 37,862评论 3 394
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,516评论 0 256
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 40,710评论 1 295
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,518评论 2 318
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,582评论 1 329
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,295评论 4 318
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 38,848评论 3 306
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,881评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,121评论 1 259
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 42,737评论 2 349
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,280评论 2 341

推荐阅读更多精彩内容