如何实现一个工业级哈希表

1、散列表碰撞攻击

 

在极端情况下,攻击者通过精心构造的数据,使得所有的数据都散列到同一个槽里,如果使用链表冲突解决方法,散列表就会退化为链表,查询时间复杂度就从 O(1) 退化为 O(n)。

可能因为查询操作消耗大量 CPU 或者线程资源,导致系统无法响应其他请求,从而达到拒绝服务攻击(DoS)的目的。

 

2、如何设计散列函数?

散列函数设计的好坏,决定了散列表冲突的概率大小,也直接决定了散列表的性能。那什么才是好的散列函数呢?

 

  • 散列函数的设计不能太复杂,过于复杂的散列函数,会消耗很多计算时间,影响到性能。
  • 散列函数生成的值要尽可能随机并且均匀分布,最小化散列冲突,并且散列到每个槽里的数据也会比较平均。
 

3、装载因子过大了怎么办?动态扩容

 

装载因子 load fator,散列表中关键字个数和散列表长度之比,用于度量所有关键字填充哈希表后饱和的程度。

装载因子越大,说明散列表中的元素越多,空闲位置越少,散列冲突的概率就越大。不仅插入数据的过程要多次寻址或者拉很长的链,查找的过程也会因此变得很慢。

 

针对散列表,当装载因子过大时,我们可以进行动态扩容,重新申请一个更大的散列表,将数据搬移到这个新散列表中。

 

针对散列表的扩容,因为散列表的大小变了,数据的存储位置也变了,所以我们需要通过散列函数重新计算每个数据的存储位置。

 

装载因子阈值需要选择得当。如果太大,会导致冲突过多;如果太小,会导致内存浪费严重。

 

4、如何避免低效地扩容?

 

当有新数据要插入时,我们将新数据插入新散列表中,并且从老的散列表中拿出一个数据放入到新散列表。每次插入一个数据到散列表,我们都重复上面的过程。经过多次插入操作之后,老的散列表中的数据就一点一点全部搬移到新散列表中了。这样没有了集中的一次性数据搬移,插入操作就都变得很快了。

 

这期间的查询操作怎么来做呢?对于查询操作,为了兼容了新、老散列表中的数据,我们先从新散列表中查找,如果没有找到,再去老的散列表中查找。

通过这样均摊的方法,将一次性扩容的代价,均摊到多次插入操作中,就避免了一次性扩容耗时过多的情况。这种实现方式,任何情况下,插入一个数据的时间复杂度都是 O(1)。

5、如何选择冲突解决方法?

两种主要的散列冲突的解决办法:开放寻址法和链表法。

比如,Java 中 LinkedHashMap 就采用了链表法解决冲突,ThreadLocalMap 是通过线性探测的开放寻址法来解决冲突。

 

1. 开放寻址法

使用开放寻址法解决冲突的散列表,装载因子的上限不能太大,这种方法比链表法更浪费内存空间。

总结一下,当数据量比较小、装载因子小的时候,适合采用开放寻址法。这也是 Java 中的ThreadLocalMap使用开放寻址法解决散列冲突的原因。

2. 链表法

链表法对内存的利用率比开放寻址法要高:链表结点可以在需要的时候再创建,不需要事先申请好。

总结一下,基于链表的散列冲突处理方法比较适合存储大对象、大数据量的散列表,而且,比起开放寻址法,它更加灵活,支持更多的优化策略,比如用红黑树代替链表。

posted @ 2023-04-24 14:24  邴越  阅读(14)  评论(0编辑  收藏  举报