如果希望某个类作为HashMap的键,则此类必须实现自己的hashCode和equals方法。

例如有一个Groundhog类

public class Groundhog{
 protected int number;
 public Groundhog(int n){number = n;}
 public String toString(){
  return "Groundhog #" + number;
 }
}

下面使用Groundhog作为Key,value为一个字符串

Map map = new HashMap();
map.put(new Groundhog(3), "Ground3");

下面查询此map:
Groundhog gh = new Groundhog(3);

if(map.containsKey(gh))
{
 System.out.println((String)map.get(gh));
}
else
{
 System.out.println("key not found:" + gh);
}

这段程序代码看起来很简单,但是它无效。因为Groundhog继承基类Object,所以
这里使用Object的hashCode方法生成散列码,而它默认是使用对象的地址计算散列码。
由于两个Groundhog(3)生成的散列码不一样,所以在Map里面就无法查找。

所以需要实现hashcode方法,使得相同的对象具有同样的hashcode,这里所说的相同的对象
是从业务上来说的,比如业务上认为number相同,则Groundhog的对象则相同。

仅仅实现合适的hashcode方法还是不够的,hashcode只用于实现查找hash地址。
还是实现equals方法,equals方法严格判断两个对象是否相等。

下面的类Groundhog2就能够作为Map的key。

public class Groundhog2 extends Groundhog{
 protected int number;
 public Groundhog2(int n){super(n);}
 public int hashCode(){return number;}
 public boolean equals(Object o){
  return (o instanceof Groundhog2)
    && (number == ((Groundhog2)o).number);
 }
}

不仅是HashMap,所有使用散列的数据结构(HashSet,HashMap,LinkedHashSet,and
LinkedHashMap)都无法正确的处理你的键。当然要很好的理解这个问题,必须了解这些数据结构的内部构造。

首先散列的目的是要使用一个对象来查找另一个对象。散列就类似于
家里挂的珠帘,一个个的珠子构成一串,每一串并行而挂。如果把
每一个珠子看成是Key-value对,串看成是bucket,每一串悬挂的地方定义hash地址
那么这就是一个HashMap了,只不过珠帘每一串的珠子个数是一样多的,而HashMap通常很难做到
每一个bucket里面的key-value的个数一样多。HashMap就是根据key的hashcode计算其hash code
,hashcode值一样的key-value对放在同一个bucket里面,同一个bucket里面也就可能好多个key-value值。
当进行查找的时候,HashMap先计算这个key的hashcode,通过hashcode马上定位到这个key-value在哪个bucket
里面,这样查询的速度就非常快,然后在bucket里面通过equals方法在一个个查找,如果有一个key-value满足,则就找到了key,value就可以取到了,否则就没有相应的key了。

从上面的对Hash原理的剖析可以知道,对于这样的key必须实现其hashCode和equals方法,缺一不可。

这里顺便提一下HashMap的性能因子,要理解这个问题必须解释一些术语。
容量(Capacity):散列表中bucket的数量,俗称桶的数量
初始化容量(initial capacity):创建散列表时桶的数量。HashMap和HashSet都允许在构造函数中指定初始化容量
尺寸(Size):当前散列表中记录的数量
负载因子(load factor):等于”尺寸/容量“。负载因子为0,表示空的散列表,0.5表示半满的散列表,以此类推。
轻负载的散列表具有冲突少,适宜插入与查询的特点。较高的负载因子虽然会降低空间的需求,但会提高查询的时间开销。
如果知道HashMap中会有很多记录,在创建时就使用较大的初始化容量,这样可以避免自动重散列的开销。