1、散列表碰撞攻击
在极端情况下,攻击者通过精心构造的数据,使得所有的数据都散列到同一个槽里,如果使用链表冲突解决方法,散列表就会退化为链表,查询时间复杂度就从 O(1) 退化为 O(n)。
可能因为查询操作消耗大量 CPU 或者线程资源,导致系统无法响应其他请求,从而达到拒绝服务攻击(DoS)的目的。
2、如何设计散列函数?
散列函数设计的好坏,决定了散列表冲突的概率大小,也直接决定了散列表的性能。那什么才是好的散列函数呢?
- 散列函数的设计不能太复杂,过于复杂的散列函数,会消耗很多计算时间,影响到性能。
- 散列函数生成的值要尽可能随机并且均匀分布,最小化散列冲突,并且散列到每个槽里的数据也会比较平均。
3、装载因子过大了怎么办?动态扩容
装载因子 load fator,散列表中关键字个数和散列表长度之比,用于度量所有关键字填充哈希表后饱和的程度。
装载因子越大,说明散列表中的元素越多,空闲位置越少,散列冲突的概率就越大。不仅插入数据的过程要多次寻址或者拉很长的链,查找的过程也会因此变得很慢。
针对散列表,当装载因子过大时,我们可以进行动态扩容,重新申请一个更大的散列表,将数据搬移到这个新散列表中。
针对散列表的扩容,因为散列表的大小变了,数据的存储位置也变了,所以我们需要通过散列函数重新计算每个数据的存储位置。
装载因子阈值需要选择得当。如果太大,会导致冲突过多;如果太小,会导致内存浪费严重。
4、如何避免低效地扩容?
当有新数据要插入时,我们将新数据插入新散列表中,并且从老的散列表中拿出一个数据放入到新散列表。每次插入一个数据到散列表,我们都重复上面的过程。经过多次插入操作之后,老的散列表中的数据就一点一点全部搬移到新散列表中了。这样没有了集中的一次性数据搬移,插入操作就都变得很快了。
这期间的查询操作怎么来做呢?对于查询操作,为了兼容了新、老散列表中的数据,我们先从新散列表中查找,如果没有找到,再去老的散列表中查找。
通过这样均摊的方法,将一次性扩容的代价,均摊到多次插入操作中,就避免了一次性扩容耗时过多的情况。这种实现方式,任何情况下,插入一个数据的时间复杂度都是 O(1)。
5、如何选择冲突解决方法?
两种主要的散列冲突的解决办法:开放寻址法和链表法。
比如,Java 中 LinkedHashMap 就采用了链表法解决冲突,ThreadLocalMap 是通过线性探测的开放寻址法来解决冲突。
1. 开放寻址法
使用开放寻址法解决冲突的散列表,装载因子的上限不能太大,这种方法比链表法更浪费内存空间。
总结一下,当数据量比较小、装载因子小的时候,适合采用开放寻址法。这也是 Java 中的ThreadLocalMap使用开放寻址法解决散列冲突的原因。
2. 链表法
链表法对内存的利用率比开放寻址法要高:链表结点可以在需要的时候再创建,不需要事先申请好。
总结一下,基于链表的散列冲突处理方法比较适合存储大对象、大数据量的散列表,而且,比起开放寻址法,它更加灵活,支持更多的优化策略,比如用红黑树代替链表。