一、散列函数的设计准则：
1、散列函数的设计不能太复杂。过于复杂的散列函数，势必会消耗很多计算时间，也就间接的影响到散列表的性能。
2、散列函数生成的值要尽可能随机并且均匀分布，这样才能避免或者最小化散列冲突，而且即便出现冲突，散列到每个槽里的数据也会比较平均，不会出现某个槽内数据特别多的情况。
二、装载因子过大的解决办法：
针对散列表，当装载因子过大时，可以进行动态扩容，重新申请一个更大的散列表，将数据搬移到这个新散列表中。假设每次扩容都申请一个原来散列表大小两倍的空间。如果原来散列表的装载因子是0.8，那经过扩容之后，新散列表的装载因子就下降为原来的一半，变成了0.4。但针对散列表的扩容，数据搬移操作要复杂很多。因为散列表的大小变了，数据的存储位置也变了，所以需要通过散列函数重新计算每个数据的存储位置。
三、如何避免低效的扩容：
为了解决一次性扩容耗时过多的情况，可以将扩容操作穿插在插入操作的过程中，分批完成。当装载因子触达阈值之后，只申请新空间，但并不将老的数据搬移到新散列表中。当有新数据要插入时，将新数据插入新散列表中，并且从老的散列表中拿出一个数据放入到新散列表。每次插入一个数据到散列表，都重复上面的过程。经过多次插入操作之后，老的散列表中的数据就一点一点全部搬移到新散列表中了。这样没有了集中的一次性数据搬移，插入操作就都变得很快了。
四、散列表HashMap的举例分析：
1.初始大小：
HashMap默认的初始大小是16，当然这个默认值是可以设置的，如果事先知道大概的数据量有多大，可以修改默认初始大小。
2.装载因子和动态扩容：
最大装载因子默认是0.75，当HashMap中元素个数超过0.75*capacity（capacity表示散列表的容量）的时候，就会启动扩容，每次扩容都会扩容为原来的两倍大小。
3.散列冲突解决方法：
HashMap底层采用链表法来解决冲突。但即使负载因子和散列函数设计得再合理，也免不了会出现拉链过长的情况，一旦出现拉链过长，则会严重影响HashMap的性能。于是，在JDK1.8版本中，为了对HashMap做进一步优化，引入了红黑树。而当链表长度太长（默认超过8）时，链表就转换为红黑树。可以利用红黑树快速增删改查的特点，提高HashMap的性能。当红黑树结点个数少于8个的时候，又会将红黑树转化为链表。因为在数据量较小的情况下，红黑树要维护平衡，比起链表来，性能上的优势并不明显。
4.散列函数：
static final int hash(Object key) {
int h = key.hashCode()；
return (h ^ (h >>> 16)) & (capitity -1); //capicity表示散列表的大小
}
其中， hashCode()返回的是Java对象的hash code。
五、工业级的散列表应该具有哪些特性？该如何设计？
1、应该具有的特性：
(1)：支持快速的查询、插入、删除操作
(2)：内存占用合理，不能浪费过多的内存空间；
(3)：性能稳定，极端情况下，散列表的性能也不会退化到无法接受的情况。
2、设计准则：
()：设计一个合适的散列函数；
()：定义装载因子阈值，并且设计动态扩容策略；
()：选择合适的散列冲突解决方法。
