为什么HashCode对于对象是如此的重要

为什么HashCode对于对象是如此的重要（前面已经举了set的例子）：

　　HashMap和Hashtable，虽然它们有很大的区别，如继承关系不同，对value的约束条件(是否允许null)不同，以及线程安全性等有着特定的区别，但从实现原理上来说，它们是一致的。所以，我们只以Hashtable来说明： 　　在java中，存取数据的性能，一般来说当然是首推数组，但是在数据量稍大的容器选择中，Hashtable将有比数组性能更高的查询速度。具体原因看下面的内容： 　　Hashtable在存储数据时，一般先将该对象的HashCode和0x7FFFFFFF做与操作，因为一个对象的HashCode可以为负数，这样操作后可以保证它为一个正整数。然后以Hashtable的长度取模，得到该对象在Hashtable中的索引。

index = (o.hashCode() & 0x7FFFFFFF)%hs.length; 

　　这个对象就会直接放在Hashtable的index位置，对于写入，这和数组一样，把一个对象放在其中的第index位置，但如果是查询，经过同样的算法，Hashtable可以直接从第index取得这个对象，而数组却要做循环比较。所以对于数据量稍大时，Hashtable的查询比数组具有更高的性能。

　　事实上一个设计比较好的Hashtable，一般来说会比较平均地分布每个元素，因为Hashtable的长度总是比实际元素的个数按一定比例进行自增(负载因子一般为0.75左右)，这样大多数的索引位置只有一个对象，而很少的位置会有几个元素。但是，hash冲突很难完全避免，可以看hash。一般Hashtable中的每个位置存放的是一个链表，对于只有一个对象的位置，链表只有一个首节点(Entry)，Entry的next为null，同时保存hashCode，key，value属性，如果有相同索引的对象进来则会进入链表的下一个节点。如果同一个索引中有多个对象，根据HashCode和key可以在该链表中找到一个和查询的key相匹配的对象(equals方法)。 　　对于一个对象，如果具有很多属性，把所有属性都参与散列，显然是一种笨拙的设计。因为对象的HashCode()方法被自动调用的很多，如果太多的对象参与了散列，那么需要的时间将会增加很多。可以挑选具有区分度的属性计算hash值，或者设立缓存，只要当参与散列的对象改变时才重新计算，否则调用缓存的hashCode，这可以从很大程度上提高性能。 　　默认的实现是将对象内存地址转化为整数作为HashCode，这当然能保证每个对象具有不同的HasCode，但java语言并不能让程序员获取对象内存地址。 　　请记住：如果你想有效的使用HashMap，你就必须重写在其的hashCode()。

还有两条重写hashCode()的原则：

• 不必对每个不同的对象都产生一个唯一的hashCode，只要你的HashCode方法使get()能够得到put()放进去的内容就可以了。即“不为一原则”。
• 生成hashCode的算法尽量使hashCode的值分散一些， 不要很多hashCode都集中在一个范围内，这样有利于提高HashMap的性能。即“分散原则”。