hashcode 知识点

java中常用的哈希码的算法。

Object类的hashCode.返回对象的内存地址经过处理后的结构，由于每个对象的内存地址都不一样，所以哈希码也不一样。
String类的hashCode.根据String类包含的字符串的内容，根据一种特殊算法返回哈希码，只要字符串所在的堆空间相同，返回的哈希码也相同。
Integer类，返回的哈希码就是Integer对象里所包含的那个整数的数值，例如Integer i1=new Integer(100),i1.hashCode的值就是100 。由此可见，2个一样大小的Integer对象，返回的哈希码也一样。

hashCode 理解：
1、hashCode的存在主要是用于查找的快捷性，如Hashtable，HashMap等，hashCode是用来在散列存储结构中确定对象的存储地址的；
2、如果两个对象相同，就是适用于equals(java.lang.Object) 方法，那么这两个对象的hashCode一定要相同；
3、如果对象的equals方法被重写，那么对象的hashCode也尽量重写，并且产生hashCode使用的对象，一定要和equals方法中使用的一致，否则就会违反上面提到的第2点；
4、两个对象的hashCode相同，并不一定表示两个对象就相同，也就是不一定适用于equals(java.lang.Object) 方法，只能够说明这两个对象在散列存储结构中，如Hashtable，他们“存放在同一个篮子里”。
HashCode作用
Java中的集合（Collection）有两类，一类是List，再有一类是Set。前者集合内的元素是有序的，元素可以重复；后者元素无序，但元素不可重复。 equals方法可用于保证元素不重复，但是，如果每增加一个元素就检查一次，如果集合中现在已经有1000个元素，那么第1001个元素加入集合时，就要调用1000次equals方法。这显然会大大降低效率。
于是，Java采用了哈希表的原理。
哈希算法也称为散列算法，是将数据依特定算法直接指定到一个地址上。
这样一来，当集合要添加新的元素时，先调用这个元素的HashCode方法，就一下子能定位到它应该放置的物理位置上。
（1）如果这个位置上没有元素，它就可以直接存储在这个位置上，不用再进行任何比较了；
（2）如果这个位置上已经有元素了，就调用它的equals方法与新元素进行比较，相同的话就不存了；
（3）不相同的话，也就是发生了Hash key相同导致冲突的情况，那么就在这个Hash key的地方产生一个链表，将所有产生相同HashCode的对象放到这个单链表上去，串在一起（很少出现）。这样一来实际调用equals方法的次数就大大降低了，几乎只需要一两次。
HashCode实践
HashCode是用于查找使用的，而equals是用于比较两个对象的是否相等的。
（1）例如内存中有这样的位置：
0 1 2 3 4 5 6 7
而我有个类，这个类有个字段叫ID，我要把这个类存放在以上8个位置之一，如果不用HashCode而任意存放，那么当查找时就需要到这八个位置里挨个去找，或者用二分法一类的算法。
但如果用HashCode那就会使效率提高很多。定义我们的HashCode为ID％8，比如我们的ID为9，9除8的余数为1，那么我们就把该类存在1这个位置，如果ID是13，求得的余数是5，那么我们就把该类放在5这个位置。依此类推。
（2）但是如果两个类有相同的HashCode，例如9除以8和17除以8的余数都是1，也就是说，我们先通过 HashCode来判断两个类是否存放某个桶里，但这个桶里可能有很多类，那么我们就需要再通过 equals 在这个桶里找到我们要的类。

一个对象的哈希码允许算法和数据结构将对象放入隔间，就象打印机类型案件中的字母类型。打印机将所有的“A”类型放到一个房间，它寻找这个“A”的时候就只需要在这个房间进行寻找。这种简单的系统让他在未排序的抽屉中寻找类型的时候更快。这也是基于哈希的集合的想法，例如 HashMap 和 HashSet。
hashCode 契约
这个契约在 hashCode 方法的 JavaDoc 中进行了阐述。它可以大致的归纳为下面几点：
在一个运行的进程中，相等的对象必须要有相同的哈希码
请注意这并不意味着以下常见的误解：
不相等的对象一定有着不同的哈希码——错！
有同一个哈希值的对象一定相等——错！
hashcode 规则

无论你何时实现 equals 方法，你必须同时实现 hashCode 方法
如果你不这样做，你将会带来损坏的对象。为什么？一个对象的 hashCode 方法需要与 equals 方法考虑同样的域。通过重写 equals 方法，你将申明一些对象与其他对象相等，但是原始的 hashCode 方法将所有的对象看做是不同的。所以你将会有不同哈希码的相同对象。例如，在 HashMap 中调用 contains 方法将会返回 false，即使这个对象已经被添加。
哈希码冲突
任何时候，两个不同对象有相同的哈希码，我们称之为冲突。冲突不要紧，它只是意味着有多个对象在同一个空间里，所以 HashMap 会再检查一遍来找正确的对象。大量的冲突将会降低系统的性能，但是它们不会导致错误的结果。
但是如果你误认为哈希码是一个对象唯一的句柄，例如使用它作为Map的key，你有时会得到错误的对象。因为虽然冲突很罕见，但他们是不可避免的。例如，字符“Aa”和“BB”产生相同的哈希码：2112。因此：
永远不要把哈希码误用作一个key
哈希码可变
最后，在哈希码的契约中，有一个很重要的细节是相当让人吃惊的：hashCode 并不保证在不同的应用执行中得到相同的结果。让我们看一看 Java 文档:
在一次 Java 应用的执行中，对于同一个对象，hashCode 方法必须始终返回相同的整数，但这整数不反映对象是否被修改（equals 比较）的信息。同一个应用的不同执行，该整数不必保持一致。
事实上，这是不常见的，一些类库中的类甚至指定它们用于计算哈希码的精确公式（例如字符串）。对于这些类，哈希码总是会相同。虽然大部分的哈希码的实现提供稳定的值，但你不能依赖于这一点。正如这篇文章指出的，有些类库在不同进程中会返回不同的哈希值，这有的时候会让人困惑。谷歌的 Protocol Buffers 就是一个例子。
因此，你不应该在分布式应用程序中使用哈希码。一个远程对象可能与本地对象有不同的哈希码，即使这两个对象是相等的。
在分布式应用中不要使用哈希码
此外，你应该意识到从一个版本到另一个版本哈希码的功能实现可能会更改。因此您的代码不应该依赖于任何特定的哈希码值。例如，你不应该使用哈希码来持久化状态。下次你运行程序的时候，“相同”对象的哈希码可能不同。
最好的建议可能是：完全不使用哈希码，除非你自己创造了基于哈希的算法。
一种替代方法：SHA1
你可能知道加密的哈希码 SHA1 有时被用来标识对象（例如，git这样做）。这也是不安全吗？不。SHA1 使用 160 位密钥，这使得冲突几乎是不可能的。即使有很多对象，在这个空间发生冲突的几率远远低于一颗流星撞到你正在执行程序的电脑的几率。
从图片往下部分内容出处：http://www.importnew.com/16517.html