hashmap实现及哈希冲突

 

原文：

 

   hashmap 采用一种所谓的“hash 算法”来决定每个元素的存储位置。当程序执行 map.put(string,obect)方法 时，系统将调用string的 hashcode() 方法得到其 hashcode 值——每个 java 对象都有 hashcode() 方法，都可通过该方法获得它的 hashcode 值。得到这个对象的 hashcode 值之后，系统会根据该 hashcode 值来决定该元素的存储位置。源码如下:

java代码  

1.    public v put(k key, v value) {  
2.         if (key == null)  
3.             return putfornullkey(value);  
4.         int hash = hash(key.hashcode());  
5.         int i = indexfor(hash, table.length);  
6.         for (entry<k,v> e = table[i]; e != null; e = e.next) {  
7.             object k;  
8.             //判断当前确定的索引位置是否存在相同hashcode和相同key的元素，如果存在相同的hashcode和相同的key的元素，那么新值覆盖原来的旧值，并返回旧值。  
9.             //如果存在相同的hashcode，那么他们确定的索引位置就相同，这时判断他们的key是否相同，如果不相同，这时就是产生了hash冲突。  
10.             //hash冲突后，那么hashmap的单个bucket里存储的不是一个 entry，而是一个 entry 链。  
11.             //系统只能必须按顺序遍历每个 entry，直到找到想搜索的 entry 为止——如果恰好要搜索的 entry 位于该 entry 链的最末端（该 entry 是最早放入该 bucket 中），  
12.             //那系统必须循环到最后才能找到该元素。  
13.             if (e.hash == hash && ((k = e.key) == key || key.equals(k))) {  
14.                 v oldvalue = e.value;  
15.                 e.value = value;  
16.                 return oldvalue;  
17.             }  
18.         }  
19.         modcount++;  
20.         addentry(hash, key, value, i);  
21.         return null;  
22.     }  
23.    

       上面程序中用到了一个重要的内部接口：map.entry，每个 map.entry 其实就是一个 key-value 对。从上面程序中可以看出：当系统决定存储 hashmap 中的 key-value 对时，完全没有考虑 entry 中的 value，仅仅只是根据 key 来计算并决定每个 entry 的存储位置。这也说明了前面的结论：我们完全可以把 map 集合中的 value 当成 key 的附属，当系统决定了 key 的存储位置之后，value 随之保存在那里即可.hashmap程序经过我改造，我故意的构造出了hash冲突现象，因为hashmap的初始大小16,但是我在hashmap里面放了超过16个元素，并且我屏蔽了它的resize()方法。不让它去扩容。这时hashmap的底层数组entry[]   table结构如下: 

   

       hashmap里面的bucket出现了单链表的形式，散列表要解决的一个问题就是散列值的冲突问题，通常是两种方法：链表法和开放地址法。链表法就是将相同hash值的对象组织成一个链表放在hash值对应的槽位；开放地址法是通过一个探测算法，当某个槽位已经被占据的情况下继续查找下一个可以使用的槽位。java.util.hashmap采用的链表法的方式，链表是单向链表。形成单链表的核心代码如下：

 

java代码  

1. void addentry(int hash, k key, v value, int bucketindex) {  
2.     entry<k,v> e = table[bucketindex];  
3.     table[bucketindex] = new entry<k,v>(hash, key, value, e);  
4.     if (size++ >= threshold)  
5.         resize(2 * table.length);  
6. bsp;  

     上面方法的代码很简单，但其中包含了一个设计：系统总是将新添加的 entry 对象放入 table 数组的 bucketindex 索引处——如果 bucketindex 索引处已经有了一个 entry 对象，那新添加的 entry 对象指向原有的 entry 对象（产生一个 entry 链），如果 bucketindex 索引处没有 entry 对象，也就是上面程序代码的 e 变量是 null，也就是新放入的 entry 对象指向 null，也就是没有产生 entry 链。

       hashmap里面没有出现hash冲突时，没有形成单链表时，hashmap查找元素很快,get()方法能够直接定位到元素，但是出现单链表后，单个bucket 里存储的不是一个 entry，而是一个 entry 链，系统只能必须按顺序遍历每个 entry，直到找到想搜索的 entry 为止——如果恰好要搜索的 entry 位于该 entry 链的最末端（该 entry 是最早放入该 bucket 中），那系统必须循环到最后才能找到该元素。

       当创建 hashmap 时，有一个默认的负载因子（load factor），其默认值为 0.75，这是时间和空间成本上一种折衷：增大负载因子可以减少 hash 表（就是那个 entry 数组）所占用的内存空间，但会增加查询数据的时间开销，而查询是最频繁的的操作（hashmap 的 get() 与 put() 方法都要用到查询）；减小负载因子会提高数据查询的性能，但会增加 hash 表所占用的内存空间。

一、hashmap概述

　　hashmap基于哈希表的 map 接口的实现。此实现提供所有可选的映射操作，并允许使用 null 值和 null 键。（除了不同步和允许使用 null 之外，hashmap 类与 hashtable 大致相同。）此类不保证映射的顺序，特别是它不保证该顺序恒久不变。

　　值得注意的是hashmap不是线程安全的，如果想要线程安全的hashmap，可以通过collections类的静态方法synchronizedmap获得线程安全的hashmap。

 map map = collections.synchronizedmap(new hashmap());

 

二、hashmap的数据结构

　　hashmap的底层主要是基于数组和链表来实现的，它之所以有相当快的查询速度主要是因为它是通过计算散列码来决定存储的位置。hashmap中主要是通过key的hashcode来计算hash值的，只要hashcode相同，计算出来的hash值就一样。如果存储的对象对多了，就有可能不同的对象所算出来的hash值是相同的，这就出现了所谓的hash冲突。学过数据结构的同学都知道，解决hash冲突的方法有很多，hashmap底层是通过链表来解决hash冲突的。