加载因子是表示Hsah表中元素的填满的程度.若:加载因子越大,填满的元素越多,好处是,空间利用率高了,但:冲突的机会加大了.反之,加载因子越小,填满的元素越少,好处是:冲突的机会减小了,但:空间浪费多了.
冲突的机会越大,则查找的成本越高.反之,查找的成本越小.因而,查找时间就越小.
因此,必须在 "冲突的机会"与"空间利用率"之间寻找一种平衡与折衷. 这种平衡与折衷本质上是数据结构中有名的"时-空"矛盾的平衡与折衷.
所有的Hash表都理论上都不可能避免冲突(无论Hash函数如何设计).当表中都快填满时(加载因子大),再填入新的元素时,冲突的机会将很大.
JAVA的HashMap当put(..)时若产生冲突(即:两个不同的对象,但其hadhCode相同,表明想占用表中同一个位置空间),则目前的实现中是:占用Hash表中同一个位置空间的冲突的元素,用一个链表来链起来.这样:当get(...)时,若有冲突,就要访问链表了(这样,一旦有冲突,put(..)与get(...)都要和链表打交道,成本当然就高了)
因此:要尽最大努力,减少冲突的机会