1、避免散列表碰撞攻击

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

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

2、如何设计散列函数？

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. 开放寻址法

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

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

2. 链表法

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

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