java-基础-hashcode()及其优化

哈希表这个数据结构想必大多数人都不陌生，而且在很多地方都会利用到hash表来提高查找效率。在Java的Object类中有一个方法:

public native int hashCode();

根据这个方法的声明可知，该方法返回一个int类型的数值，并且是本地方法，因此在Object类中并没有给出具体的实现

对于包含容器类型的程序设计语言来说，基本上都会涉及到hashCode。在Java中也一样，hashCode方法的主要作用是为了配合基于散列的集合一起正常运行，这样的散列集合包括HashSet、HashMap以及HashTable。　　也许大多数人都会想到调用equals方法来逐个进行比较，这个方法确实可行。但是如果集合中已经存在一万条数据或者更多的数据，如果采用equals方法去逐一比较，效率必然是一个问题。此时hashCode方法的作用就体现出来了，当集合要添加新的对象时，先调用这个对象的hashCode方法，得到对应的hashcode值，实际上在HashMap的具体实现中会用一个table保存已经存进去的对象的hashcode值，如果table中没有该hashcode值，它就可以直接存进去，不用再进行任何比较了；如果存在该hashcode值， 就调用它的equals方法与新元素进行比较，相同的话就不存了，不相同就散列其它的地址，所以这里存在一个冲突解决的问题，这样一来实际调用equals方法的次数就大大降低了，说通俗一点：Java中的hashCode方法就是根据一定的规则将与对象相关的信息（比如对象的存储地址，对象的字段等）映射成一个数值，这个数值称作为散列值。

java.util.HashMap的中put方法的具体实现：public V put(K key, V value) {        if (key == null)            return putForNullKey(value);        int hash = hash(key.hashCode());        int i = indexFor(hash, table.length);        for (Entry<K,V> e = table[i]; e != null; e = e.next) {            Object k;            if (e.hash == hash && ((k = e.key) == key || key.equals(k))) {                V oldValue = e.value;                e.value = value;                e.recordAccess(this);                return oldValue;            }        }        modCount++;        addEntry(hash, key, value, i);        return null;    }

　put方法是用来向HashMap中添加新的元素，从put方法的具体实现可知，会先调用hashCode方法得到该元素的hashCode值，然后查看table中是否存在该hashCode值，如果存在则调用equals方法重新确定是否存在该元素，如果存在，则更新value值，否则将新的元素添加到HashMap中。从这里可以看出，hashCode方法的存在是为了减少equals方法的调用次数，从而提高程序效率。
　JVM在实现时是直接返回对象的存储地址，但是大多时候并不是这样，只能说可能存储地址有一定关联。

static inline intptr_t get_next_hash(Thread * Self, oop obj) {  intptr_t value = 0 ;  if (hashCode == 0) {     // This form uses an unguarded global Park-Miller RNG,     // so it's possible for two threads to race and generate the same RNG.     // On MP system we'll have lots of RW access to a global, so the     // mechanism induces lots of coherency traffic.     value = os::random() ;  } else  if (hashCode == 1) {     // This variation has the property of being stable (idempotent)     // between STW operations.  This can be useful in some of the 1-0     // synchronization schemes.     intptr_t addrBits = intptr_t(obj) >> 3 ;     value = addrBits ^ (addrBits >> 5) ^ GVars.stwRandom ;  } else  if (hashCode == 2) {     value = 1 ;            // for sensitivity testing  } else  if (hashCode == 3) {     value = ++GVars.hcSequence ;  } else  if (hashCode == 4) {     value = intptr_t(obj) ;  } else {     // Marsaglia's xor-shift scheme with thread-specific state     // This is probably the best overall implementation -- we'll     // likely make this the default in future releases.     unsigned t = Self->_hashStateX ;     t ^= (t << 11) ;     Self->_hashStateX = Self->_hashStateY ;     Self->_hashStateY = Self->_hashStateZ ;     Self->_hashStateZ = Self->_hashStateW ;     unsigned v = Self->_hashStateW ;     v = (v ^ (v >> 19)) ^ (t ^ (t >> 8)) ;     Self->_hashStateW = v ;     value = v ;  }  value &= markOopDesc::hash_mask;  if (value == 0) value = 0xBAD ;  assert (value != markOopDesc::no_hash, "invariant") ;  TEVENT (hashCode: GENERATE) ;  return value;}　　该实现位于hotspot/src/share/vm/runtime/synchronizer.cpp

hashcode值判断两个对象是否相等吗？
肯定是不可以的，因为不同的对象可能会生成相同的hashcode值。
虽然不能根据hashcode值判断两个对象是否相等，但是可以直接根据hashcode值判断两个对象不等，如果两个对象的hashcode值不等，则必定是两个不同的对象。如果要判断两个对象是否真正相等，必须通过equals方法。
也就是说对于两个对象，如果调用equals方法得到的结果为true，则两个对象的hashcode值必定相等；

如果equals方法得到的结果为false，则两个对象的hashcode值不一定不同；

如果两个对象的hashcode值不等，则equals方法得到的结果必定为false；

如果两个对象的hashcode值相等，则equals方法得到的结果未知。
重写equals方法，比如String类，但是千万要注意，在重写equals方法的同时，必须重写hashCode方法。为什么这么说呢？

package com.cxh.test1;import java.util.HashMap;import java.util.HashSet;import java.util.Set;class People{    private String name;    private int age;    public People(String name,int age) {        this.name = name;        this.age = age;    }       public void setAge(int age){        this.age = age;    }    @Override    public boolean equals(Object obj) {        // TODO Auto-generated method stub        return this.name.equals(((People)obj).name) && this.age== ((People)obj).age;    }}public class Main {    public static void main(String[] args) {        People p1 = new People("Jack", 12);        System.out.println(p1.hashCode());        HashMap<People, Integer> hashMap = new HashMap<People, Integer>();        hashMap.put(p1, 1);        System.out.println(hashMap.get(new People("Jack", 12)));    }}

只重写了equals方法，也就说如果两个People对象，如果它的姓名和年龄相等，则认为是同一个人。这段代码本来的意愿是想这段代码输出结果为“1”，但是事实上它输出的是“null”。为什么呢？原因就在于重写equals方法的同时忘记重写hashCode方法。
虽然通过重写equals方法使得逻辑上姓名和年龄相同的两个对象被判定为相等的对象（跟String类类似），但是要知道默认情况下，hashCode方法是将对象的存储地址进行映射。那么上述代码的输出结果为“null”就不足为奇了。原因很简单，p1指向的对象和System.out.println(hashMap.get(new People(“Jack”, 12)));这句中的new People(“Jack”, 12)生成的是两个对象，它们的存储地址肯定不同。

HashMap的get方法的具体实现：public V get(Object key) {        if (key == null)            return getForNullKey();        int hash = hash(key.hashCode());        for (Entry<K,V> e = table[indexFor(hash, table.length)];             e != null;             e = e.next) {            Object k;            if (e.hash == hash && ((k = e.key) == key || key.equals(k)))                return e.value;        }        return null;    }

所以在hashmap进行get操作时，因为得到的hashcdoe值不同（注意，上述代码也许在某些情况下会得到相同的hashcode值，不过这种概率比较小，因为虽然两个对象的存储地址不同也有可能得到相同的hashcode值），所以导致在get方法中for循环不会执行，直接返回null。

因此如果想上述代码输出结果为“1”，很简单，只需要重写hashCode方法，让equals方法和hashCode方法始终在逻辑上保持一致性

import java.util.HashMap;import java.util.HashSet;import java.util.Set;class People{    private String name;    private int age;    public People(String name,int age) {        this.name = name;        this.age = age;    }       public void setAge(int age){        this.age = age;    }    @Override    public int hashCode() {        // TODO Auto-generated method stub        return name.hashCode()*37+age;    }    @Override    public boolean equals(Object obj) {        // TODO Auto-generated method stub        return this.name.equals(((People)obj).name) && this.age== ((People)obj).age;    }}public class Main {    public static void main(String[] args) {        People p1 = new People("Jack", 12);        System.out.println(p1.hashCode());        HashMap<People, Integer> hashMap = new HashMap<People, Integer>();        hashMap.put(p1, 1);        System.out.println(hashMap.get(new People("Jack", 12)));    }}

在程序执行期间，只要equals方法的比较操作用到的信息没有被修改，那么对这同一个对象调用多次，hashCode方法必须始终如一地返回同一个整数。
如果两个对象根据equals方法比较是相等的，那么调用两个对象的hashCode方法必须返回相同的整数结果。
如果两个对象根据equals方法比较是不等的，则hashCode方法不一定得返回不同的整数。对于第二条和第三条很好理解，但是第一条，很多时候就会忽略。

设计hashCode()时最重要的因素就是：无论何时，对同一个对象调用hashCode()都应该产生同样的值。如果在讲一个对象用put()添加进HashMap时产生一个hashCdoe值，而用get()取出时却产生了另一个hashCode值，那么就无法获取该对象了。所以如果你的hashCode方法依赖于对象中易变的数据，用户就要当心了，因为此数据发生变化时，hashCode()方法就会生成一个不同的散列码

import java.util.HashMap;import java.util.HashSet;import java.util.Set;class People{    private String name;    private int age;    public People(String name,int age) {        this.name = name;        this.age = age;    }       public void setAge(int age){        this.age = age;    }    @Override    public int hashCode() {        // TODO Auto-generated method stub        return name.hashCode()*37+age;    }    @Override    public boolean equals(Object obj) {        // TODO Auto-generated method stub        return this.name.equals(((People)obj).name) && this.age== ((People)obj).age;    }}public class Main {    public static void main(String[] args) {        People p1 = new People("Jack", 12);        System.out.println(p1.hashCode());        HashMap<People, Integer> hashMap = new HashMap<People, Integer>();        hashMap.put(p1, 1);        p1.setAge(13);        System.out.println(hashMap.get(p1));    }}

因此，在设计hashCode方法和equals方法的时候，如果对象中的数据易变，则最好在equals方法和hashCode方法中不要依赖于该字段。
hashCode()方法的一个主要作用就是使得对象能够成为哈希表的key或者散列集的成员。但同时这个对象还得实现equals(Object)方法，它和hashCode()的实现必须是一致的：

如果a.equals(b)那么a.hashCode == b.hashCode()
如果hashCode()在同一个对象上被调用两次，它应该返回的是同一个值，这表明这个对象没有被修改过。

从性能的角度来看的话，hashCode()方法的主要目标就是尽量使得不同的对象拥有不同的哈希值。JDK中所有基于哈希的集合都是将值存储在数组中的。查找元素的时候，会使用哈希值来计算出在数组中的初始查找位置；然后再调用equals()方法将给定的值和数组中存储对象的值进行比较。
如果所有元素的哈希值都不一样，这会减少哈希的碰撞概率。
换句话说，如果所有的值的哈希码都一样的话，hashmap(或者hashset)会蜕化成一个列表，操作的时间复杂度会变成O(n2)。
Hashmap里面的bucket出现了单链表的形式，散列表要解决的一个问题就是散列值的冲突问题，通常是两种方法：链表法和开放地址法。链表法就是将相同hash值的对象组织成一个链表放在hash值对应的槽位；开放地址法是通过一个探测算法，当某个槽位已经被占据的情况下继续查找下一个可以使用的槽位。java.util.HashMap采用的链表法的方式，链表是单向链表。
HashMap里面没有出现hash冲突时，没有形成单链表时，hashmap查找元素很快,get()方法能够直接定位到元素，但是出现单链表后，单个bucket 里存储的不是一个 Entry，而是一个 Entry 链，系统只能必须按顺序遍历每个 Entry，直到找到想搜索的 Entry 为止——如果恰好要搜索的 Entry 位于该 Entry 链的最末端（该 Entry 是最早放入该 bucket 中），那系统必须循环到最后才能找到该元素。
当创建 HashMap 时，有一个默认的负载因子（load factor），其默认值为 0.75，这是时间和空间成本上一种折衷：增大负载因子可以减少 Hash 表（就是那个 Entry 数组）所占用的内存空间，但会增加查询数据的时间开销，而查询是最频繁的的操作（HashMap 的 get() 与 put() 方法都要用到查询）；减小负载因子会提高数据查询的性能，但会增加 Hash 表所占用的内存空间。

高质量的String.hashCode()能做些什么

假设我们有一个map，它是由String标识符来指向某些值。map的key（String标识符)不会在内存的别的地方存储（某一时间可能有一小部分值是存储在别的地方）。假设我们已经收集到了map的所有记录，比如说在某个两阶段算法中的第一个阶段。下一步我们要通过key来查找map中的值。我们只会用map里存在的key进行查找。

我们如何能提升map的性能?前面你已经看到了，String.hashCode()返回的几乎都是不同的值，我们可以扫描所有的key，计算出它们的哈希值，找出那些不唯一的哈希值:

final Map<Integer, Object> unique = new HashMap<Integer, Object>( 1000 );final Map<String, Object> not_unique = new HashMap<String, Object>( 1000 );//dict - original mapfor ( final Map.Entry<String, Object> entry : dict.entrySet() ){    final int hash Code = entry.getKey().hash Code();    if ( mult.containsKey( hash Code ) )        not_unique.put( entry.getKey(), entry.getValue() );    else        unique.put( hash Code, entry.getValue() );}//keep only not unique hash codesfinal Map<Integer, Integer> mult = new HashMap<Integer, Integer>( 100 );for ( final Map.Entry<Integer, Integer> entry : cnt.entrySet() ){    if ( entry.getValue() > 1 )        mult.put( entry.getKey(), entry.getValue() );}

为了查找某个值，我们得先查找第一个hashcode唯一的map，如果没找到，再查找第二个不唯一的map：

public Object get( final String key ){final int hash Code = key.hash Code();Object value = m_unique.get( hash Code );if ( value == null )value = m_not_unique.get( key );return value;}

在一些不太常见的情况下，你的这个不唯一的map里的对象可能会很多。碰到这种情况的话，先尝试用java.util.zip.CRC32或者是java.util.zip.Adler32来替换掉hashCode()的实现（Adler32比CRC32要快，不过它的分布较差些）。如果实在不行，再尝试用两个不同的函数来计算哈希值：低32位和高32位分别用不同的函数生成。hash函数就用Object.hashCode, java.util.zip.CRC32或者java.util.zip.Adler32。

（译注：这么做的好处就是压缩了map的存储空间，比如你有一个map，它的KEY存100万个字符串的话，压缩了之后就只剩下long类型以及很少的字符串了）
set的压缩效果更明显

前面那个例子中，我们讨论了如何去除map中的key值。事实上，优化set的话效果会更加明显。
set大概会有这么两个使用场景：
一个是将原始的set拆分成多个子set，然后依次查询标识符是否属于某个子set；
还有就是是作为一个拼写检查器（spellchecker ）——有些要查询的值是预想不到的值（比如拼写错误了），而就算出了些错误的话影响也不是很大（如果碰巧另一个单词也有同样的hashCode，你会认为这个单词是拼写正确的)。这两种场景set都非常适用。

如果我们延用前面的方法的话，我们会得到一个唯一的hashcode组成的Set，以及不唯一的hashCode组成的一个Set。这里至少能优化掉不少字符串存储的空间。
如果我们可以把哈希值的取值限制在一定的区间内（比如说2^20)，那么我们可以用一个BitSet来代替Set，这个在BitSet一文中已经提到了。
一般来说如果我们提前知道原始set的大小的话，哈希值的范围是有足够的优化空间的。
下一步就是确定有多少标识符是共享相同的哈希值的。
如果碰撞的哈希值比较多的话，改进下你的hashCode()方法，或者扩大哈希值的取值范围。最完美的情况就是你的标记符全都有唯一的hashcode( 这其实不难实现）。优化完的好处就是，你只需要一个BitSet就够了，而不需要存储一个大的字符串集合。

总结

改进你的hashCode算法的分布。优化它比优化这个方法的执行速度要重要多了。千万不要写一个返回常量的hashCode方法。

String.hashCode的实现已经相当完美了，因此很多时候你可以用String的hashCode来代替字符串本身了。如果你使用的是字符串的set，试着把它优化成BitSet。这将大大提升你程序的性能。

背景

告警子系统监控4万个大网元所有端口的某些指标数据，根据阈值配置判断是否产生告警。采集——数据处理子系统每5分钟会主动采集24万次数据，发送24万条消息给告警子系统，这24万条消息涉及100万实体的数十个指标数据。告警子系统采用多节点部署方式分担压力，每个节点处理不同网元类型，不同实体，不同指标的数据。海量数据的过滤，必然会大量使用集合逻辑运算，使用不当，则会造成性能瓶颈。

存在告警节点监控的实体动态变化，所以每个告警节点需要动态维护自己的监控列表，所以代码中会用到Collection.removeAll求差集的计算，计算出新增的实体，然后进一步计算出这些新增实体的历史平均值，方差等数据。

import java.util.ArrayList;import java.util.List;public class HashObject {    public static void main(String[] args)    {        List<String> list1 = new ArrayList<String>();        List<String> list2 = new ArrayList<String>();        // 2000长度的List求差集        for(int i = 0; i < 2000; i++)        {            list1.add("" + i);            list2.add("" + (i + 1));        }        long startTime = System.currentTimeMillis();        list1.removeAll(list2);        long endTime = System.currentTimeMillis();        System.out.println("2000 list remove all cost: " + (endTime - startTime) + "ms.");        // 10000长度的List求差集        list1.clear();        list2.clear();        for(int i = 0; i < 10000; i++)        {            list1.add("" + i);            list2.add("" + (i + 1));        }        startTime = System.currentTimeMillis();        list1.removeAll(list2);        endTime = System.currentTimeMillis();        System.out.println("10000 list remove all cost: " + (endTime - startTime) + "ms.");        // 50000长度的List求差集        list1.clear();        list2.clear();        for(int i = 0; i < 50000; i++)        {            list1.add("" + i);            list2.add("" + (i + 1));        }        startTime = System.currentTimeMillis();        list1.removeAll(list2);        endTime = System.currentTimeMillis();        System.out.println("50000 list remove all cost: " + (endTime - startTime) + "ms.");    }}

2000 list remove all cost: 46ms.10000 list remove all cost: 1296ms.50000 list remove all cost: 31028ms.

可以看到，数据量每增加5倍，ArrayList的求差集运算时间消耗增加30倍。当我们进行数十万元素的求差集运算时，时间消耗是我们不可承受的。

Equals

实体过滤中，为了找到我们关心的实体数据，我们必然会采用Collection.contains过滤实体ID，这里面会使用到字符串equals方法判断两个ID是否相等。对于我们来说，两个字符串相等的含义就是两个字符串长度一致，对应位置的字符编码相等。如果大量字符串两两比较都采用上述算法，那将会进行海量的运算，消耗大量性能。这个时候，HashCode的作用就显得尤其重要。

HashCode

HashCode是int类型。两个对象如果相等（equals为true），则HashCode必然相等；反之，HashCode不等的两个对象，equals必然为false。
最优秀的Hash算法，不相等的对象HashCode都不相同，所有equals比较都只调用HashCode的恒等比较，那么计算量就大大减小了。实际上，任何一个Hash算法都不能达到上述要求（HashCode为int类型，说明HashCode取值范围有限，对象超过int取值范围个数，就必然出现不相等对象对应同一个HashCode值）。不相等的对象对应相同的HashCode称之为Hash冲突。

但是，好的Hash算法确出现Hash冲突的概率极低。
比如0.01%的Hash冲突概率，这样就意味着，我们平均进行10000次不相等对象的equals比较，只会出现一次Hash冲突，也就意味着只需要调用一次equals主逻辑。我们在设计equals方法时，
先比较两个对象HashCode是否相等，不相等则返回false，相等才进行equals主逻辑比较。

原始的HashCode方法是由虚拟机本地实现的，可能采用的对象地址进行运算。String复写了HashCode方法

 public native int hashCode();    // String    public int hashCode() {        int h = hash;        if (h == 0 && value.length > 0) {            char val[] = value;            for (int i = 0; i < value.length; i++) {                h = 31 * h + val[i];            }            hash = h;        }        return h;    }

HashMap是一个利用Key的HashCode进行散列存储的容器。它采用数组->链表->红黑树存储数据。结构如下图：
同一个位置冲突超过了8则用红黑树存储。
最简单的设想，计算一个Key在数组中的位置时，采用HashCode%数组长度求余计算则可（实际上JDK采用了更好的散列算法）。可以想象，相同的散列算法下，数组长度越长，Hash冲突概率越小，但是使用的空间越大。

JDK默认采用0.75为元素容量与数组长度的比例。默认初始化数组长度为16（采用2的n次方是考虑HashMap的扩容性能），当元素个数增加到16*0.75=12个时，数组长度会自动增加一倍，元素位置会被重新计算。在数据量巨大的情况下，我们初始化HashMap时应该考虑初始化足够的数组长度，特别是性能优先的情况下，我们还可以适当减小元素容量与数组长度的比例。

大数据集合运算性能考虑

我们知道在性能优先的场景下，大数据集合运算一定要使用Hash集合（HashMap，HashSet，HashTable）存储数据。文章开头的集合求余运算，我们修改为使用HashSet.removeAll

import java.util.Collection;import java.util.HashSet;public class HashObject {    public static void main(String[] args)    {        Collection<String> list1 = new HashSet<String>();        Collection<String> list2 = new HashSet<String>();        // 2000长度的List求差集        for(int i = 0; i < 2000; i++)        {            list1.add("" + i);            list2.add("" + (i + 1));        }        long startTime = System.currentTimeMillis();        list1.removeAll(list2);        long endTime = System.currentTimeMillis();        System.out.println("2000 list remove all cost: " + (endTime - startTime) + "ms.");        // 10000长度的List求差集        list1.clear();        list2.clear();        for(int i = 0; i < 10000; i++)        {            list1.add("" + i);            list2.add("" + (i + 1));        }        startTime = System.currentTimeMillis();        list1.removeAll(list2);        endTime = System.currentTimeMillis();        System.out.println("10000 list remove all cost: " + (endTime - startTime) + "ms.");        // 50000长度的List求差集        list1.clear();        list2.clear();        for(int i = 0; i < 50000; i++)        {            list1.add("" + i);            list2.add("" + (i + 1));        }        startTime = System.currentTimeMillis();        list1.removeAll(list2);        endTime = System.currentTimeMillis();        System.out.println("50000 list remove all cost: " + (endTime - startTime) + "ms.");    }}

2000 list remove all cost: 31ms.10000 list remove all cost: 0ms.50000 list remove all cost: 16ms.