zoukankan      html  css  js  c++  java
  • JAVA集合-HashMap的实现原理

    1.HashMap工作原理  

      当我们往hashmap中put元素的时候,先根据key的hash值得到这个元素在数组中的位置(即下标),然后就可以把这个元素放到对应的位置中了。如果这个元素所在的位子上已经存放有其他元素了(两个 Entry 的 key 的 hashCode() 返回值相同,即发生了哈希冲突),如果这两个 Entry 的 key 通过 equals 比较返回 true,新添加 Entry 的 value 将覆盖集合中原有 Entry的 value;如果这两个 Entry 的 key 通过 equals 比较返回 false,那么在同一个位子上的元素将以链表的形式存放,java1.7及以前版本采用头插法,java1.8开始采用尾插法。并且java1.8中,如果链表长度超过阈值(TREEIFY THRESHOLD==8),就把链表转成红黑树,链表长度低于6,就把红黑树转回链表。如果桶满了(容量16 * 加载因子0.75),就需要 resize(扩容2倍后重排)
      我们调用 get() 方法,HashMap 会使用键对象的 hashcode 找到 bucket 位置,找到 bucket 位置之后,会调用 keys.equals() 方法去找到链表中正确的节点,最终找到要找的值对象。从这里我们可以想象得到,如果每个位置上的链表只有一个元素,那么hashmap的get效率将是最高的,但是理想总是美好的,现实总是有困难需要我们去克服。
      zjp:当我们在hashmap中put元素的时候:
        1.首先对key的hashcode作hash运算,计算其在数组中的位置;
        2. 如果没发生碰撞,即两个key的hashcode不相等,就直接放在bucket里;
        3. 如果发生碰撞,即两个key的hashcode相等,并且如果这两个key通过equals比较返回false,那么就把元素以链表的形式存放在bucket后面;
        4.如果发生碰撞,但是,这两个key通过equals比较返回true,那么就就替换Old value;
        5.如果碰撞导致链表长度过长,就把链表转变成红黑树;
        6.如果bucket满了,就要resize;
      当我们在hashmap中get元素的时候:
        1.首先对key的hashcode作hash运算,计算其在数组table中的位置index;
        2.如果在bucket(即table[Index])上的第一个节点命中,则直接返回;
        3.如果发生冲突,则通过key.equals(k)去查找对应的Entry;
        4.如果这个bucket上的数据结构是 树,则在树中通过key.equals(k)查找,O(logn);
        5.如果这个bucket上的数据结构是 链表,则在链表上通过key.equals(k)查找,O(n);

    2.HashMap容量为2次幂的原因

      我们先来说一下hash算法,我们可以看到在hashmap中要找到某个元素,需要根据key的hash值来求得对应数组中的位置。如何计算这个位置就是hash算法。前面说过hashmap的数据结构是数组和链表的结合,所以我们当然希望这个hashmap里面的元素位置尽量的分布均匀些,尽量使得每个位置上的元素数量只有一个,那么当我们用hash算法求得这个位置的时候,马上就可以知道对应位置的元素就是我们要的,而不用再去遍历链表。 

    所以我们首先想到的就是把hashcode对数组长度取模运算,这样一来,元素的分布相对来说是比较均匀的。但是,“模”运算的消耗还是比较大的,能不能找一种更快速,消耗更小的方式那?java中时这样做的:

    1 static int indexFor(int h, int length) {  
    2        return h & (length-1);  
    3    } 

      首先算得key得hashcode值,然后跟数组的长度-1做一次“与”运算(&)。看上去很简单,其实比较有玄机。比如数组的长度是2的4次方,那么hashcode就会和2的4次方-1做“与”运算。很多人都有这个疑问,为什么hashmap的数组初始化大小都是2的次方大小时,hashmap的效率最高,我以2的4次方举例,来解释一下为什么数组大小为2的幂时hashmap访问的性能最高。 

             看下图,左边两组是数组长度为16(2的4次方),右边两组是数组长度为15。两组的hashcode均为8和9,但是很明显,当它们和1110“与”的时候,产生了相同的结果,也就是说它们会定位到数组中的同一个位置上去,这就产生了碰撞,8和9会被放到同一个链表上,那么查询的时候就需要遍历这个链表,得到8或者9,这样就降低了查询的效率。同时,我们也可以发现,当数组长度为15的时候,hashcode的值会与14(1110)进行“与”,那么最后一位永远是0,而0001,0011,0101,1001,1011,0111,1101这几个位置永远都不能存放元素了,空间浪费相当大,更糟的是这种情况中,数组可以使用的位置比数组长度小了很多,这意味着进一步增加了碰撞的几率,减慢了查询的效率!

      

       所以说,当数组长度为2的n次幂的时候,不同的key算得得index相同的几率较小,那么数据在数组上分布就比较均匀,也就是说碰撞的几率小,相对的,查询的时候就不用遍历某个位置上的链表,这样查询效率也就较高了。 
              说到这里,我们再回头看一下hashmap中默认的数组大小是多少,查看源代码可以得知是16,为什么是16,而不是15,也不是20呢,看到上面annegu的解释之后我们就清楚了吧,显然是因为16是2的整数次幂的原因,在小数据量的情况下16比15和20更能减少key之间的碰撞,而加快查询的效率。 

      zjp: HashMap中是如何得到元素在数组中的位置的呢?在hashmap源码中,首先通过key.hashcode()得到hash值,然后与(数组的长度-1)作与运算。只有当数组的长度为2的n次幂时,数组的长度-1然后进行与运算才能得到每一位都是1的值,保证数组的每一位都可以利用到,如果得到的值在某一位为0,这样可能导致不能完全的对数组使用,造成数据分配不均的问题。

    3.HashMap的resize

      当hashmap中的元素越来越多的时候,碰撞的几率也就越来越高(因为数组的长度是固定的),所以为了提高查询的效率,就要对hashmap的数组进行扩容,数组扩容这个操作也会出现在ArrayList中,所以这是一个通用的操作,很多人对它的性能表示过怀疑,不过想想我们的“均摊”原理,就释然了,而在hashmap数组扩容之后,最消耗性能的点就出现了:原数组中的数据必须重新计算其在新数组中的位置,并放进去,这就是resize。 

             那么hashmap什么时候进行扩容呢?当hashmap中的元素个数超过数组大小*loadFactor时,就会进行数组扩容,loadFactor的默认值为0.75,也就是说,默认情况下,数组大小为16,那么当hashmap中元素个数超过16*0.75=12的时候,就把数组的大小扩展为2*16=32,即扩大一倍,然后重新计算每个元素在数组中的位置,而这是一个非常消耗性能的操作,所以如果我们已经预知hashmap中元素的个数,那么预设元素的个数能够有效的提高hashmap的性能。比如说,我们有1000个元素new HashMap(1000), 但是理论上来讲new HashMap(1024)更合适,不过上面annegu已经说过,即使是1000,hashmap也自动会将其设置为1024。 但是new HashMap(1024)还不是更合适的,因为0.75*1024 < 1000, 也就是说为了让0.75 * size > 1000, 我们必须这样new HashMap(2048)才最合适,既考虑了&的问题,也避免了resize的问题。

    zjp: 当hashmap中的元素个数超过数组大小*loadFactor时,就会进行数组扩容,loadFactor的默认值为0.75,也就是说,默认情况下,数组大小为16,那么当hashmap中元素个数超过16*0.75=12的时候,就把数组的大小扩展为2*16=32,即扩大一倍,然后重新计算每个元素在数组中的位置.

    4.HashMap并发状态下扩容出现的死循环问题(java1.7)

    hashmap用数组+链表。数组是固定长度,链表太长就需要扩充数组长度进行rehash减少链表长度。如果两个线程同时触发扩容,在移动节点时会导致一个链表中的2个节点相互引用,从而生成循环链表。

    HashMap的方法不是线程安全的。HashMap在并发执行put操作时发生扩容,可能会导致节点丢失,产生环形链表等情况。 节点丢失,会导致数据不准 生成环形链表,会导致get()方法死循环。

    知识拓展

    在jdk1.7中,由于扩容时使用头插法,在并发时可能会形成环状链表,导致死循环,在jdk1.8中改为尾插法,可以避免这种问题,但是依然避免不了节点丢失的问题。


    5.HashMap和ConcurrentHashMap的区别

    1.在jdk1.7版本中,ConcurrentHashmap对整个桶数组进行了分割分段(Segment),然后在每一个分段上都用Lock锁进行保护,相对于Hashtable的全局Synchronized锁的粒度更精细了一些,并发性能更好,而HashMap没有锁机制,不是线程安全的。( 到了 JDK1.8 的时候ConcurrentHashmap摒弃了Segment的概念,而是直接用 Node 数组+链表+红黑树的数据结构来实现,并发控制使用 synchronized 和 CAS 来操作。)

    2.HashMap的键值对允许有null,但是ConCurrentHashMap都不允许。

    6.Hashtable和ConcurrentHashMap的区别

    主要区别是实现线程安全的方式: ① 在JDK1.7的时候,ConcurrentHashMap(分段锁) 对整个桶数组进行了分割分段(Segment),每一把锁只锁容器其中一部分数据,多线程访问容器里不同数据段的数据,就不会存在锁竞争,提高并发访问率。(默认分配16个Segment,比Hashtable效率提高16倍。) 到了 JDK1.8 的时候已经摒弃了Segment的概念,而是直接用 Node 数组+链表+红黑树的数据结构来实现,并发控制使用 synchronized 和 CAS 来操作。(JDK1.6以后 对 synchronized锁做了很多优化) 整个看起来就像是优化过且线程安全的 HashMap,虽然在JDK1.8中还能看到 Segment 的数据结构,但是已经简化了属性,只是为了兼容旧版本;② Hashtable(同一把锁) :整个表结构共用一把锁,使用 synchronized 来保证线程安全,效率非常低下。当一个线程访问同步方法时,其他线程也访问同步方法,可能会进入阻塞或轮询状态,如使用 put 添加元素,另一个线程不能使用 put 添加元素,也不能使用 get,竞争会越来越激烈效率越低。

    7.HashMap和Hashtable和ConcurrentHashMap的区别

    ConcurrentHashMap 结合了 HashMap 和 HashTable 二者的优势。HashMap 没有考虑同步,HashTable 考虑了同步的问题。但是 HashTable 在每次同步执行时都要锁住整个结构。 ConcurrentHashMap 锁的方式是稍微细粒度的。

     8.对比图

    HashTable:

    JDK1.7的ConcurrentHashMap:

     

    JDK1.8的ConcurrentHashMap(TreeBin: 红黑二叉树节点 Node: 链表节点):

     

    答:ConcurrentHashMap 结合了 HashMap 和 HashTable 二者的优势。HashMap 没有考虑同步,HashTable 考虑了同步的问题。但是 HashTable 在每次同步执行时都要锁住整个结构。 ConcurrentHashMap 锁的方式是稍微细粒度的。

    9 ConcurrentHashMap 底层具体实现知道吗?实现原理是什么?

    JDK1.7

    首先将数据分为一段一段的存储,然后给每一段数据配一把锁,当一个线程占用锁访问其中一个段数据时,其他段的数据也能被其他线程访问。

    在JDK1.7中,ConcurrentHashMap采用Segment + HashEntry的方式进行实现,结构如下:

    一个 ConcurrentHashMap 里包含一个 Segment 数组。Segment 的结构和HashMap类似,是一种数组和链表结构,一个 Segment 包含一个 HashEntry 数组,每个 HashEntry 是一个链表结构的元素,每个 Segment 守护着一个HashEntry数组里的元素,当对 HashEntry 数组的数据进行修改时,必须首先获得对应的 Segment的锁。

    img

    1. 该类包含两个静态内部类 HashEntry 和 Segment ;前者用来封装映射表的键值对,后者用来充当锁的角色;
    2. Segment 是一种可重入的锁 ReentrantLock,每个 Segment 守护一个HashEntry 数组里得元素,当对 HashEntry 数组的数据进行修改时,必须首先获得对应的 Segment 锁。

    JDK1.8

    在JDK1.8中,放弃了Segment臃肿的设计,取而代之的是采用Node + CAS + Synchronized来保证并发安全进行实现,synchronized只锁定当前链表或红黑二叉树的首节点,这样只要hash不冲突,就不会产生并发,效率又提升N倍。

    结构如下:

    img

     10.为什么重写了equals,一定要重写hashcode()?

      通俗的讲,就是equals()和hashcode()方法要保持相当程度的一致性,equals()方法相等,hashcode()必须相等;反之,equals方法不相等,hashcode可以相等,可以不相等。但是两者的一致有利于提高哈希表的性能。所以,源码注释来看,两方法的同时重写是很必要的。

      如果只重写equals(),不重写hashcode()方法,equals()相等的的两个等价对象因为hashCode不同,所以在hashmap中的table数组的下标不同,从而这两个对象就会同时存在于集合中,

      就举最简单的例子,假定HashMap中以String为key,即HashMap<String,Object>,如果String只重写了equals方法,没有重写hashCode方法,同时put两个键完全相同的键值对,类似<"aaa", Object1>、<"aaa", Object2>, 则不会进行覆盖操作,即object2替换object1,而是会进行两次添加操作。因为HashMap,hash值的计算完全依赖于key的hashCode值,如果没有重写hashCode方法,就会调用object的hashcode()方法,这个方法是根据对象的地址生成的hash值。会导致两个字符串对象映射到hash表中的不同位置。

     






  • 相关阅读:
    commonJS — 数组操作(for Array)
    seafile增加邮件服务功能
    2.事务和系统概念
    1.事务处理简介
    glusterfs分布式复制扩容卷以及平衡卷
    seafile数据的备份与恢复
    seafile+glusterfs 安装部署
    虚拟机或物理服务器热添加硬盘
    bash: cannot create temp file for here-document: Read-only file system
    FATAL ERROR: please install the following Perl modules before executing ./mysql_install_db: Data::Dumper
  • 原文地址:https://www.cnblogs.com/jingpeng77/p/12449308.html
Copyright © 2011-2022 走看看