concurrentHashMap

最新推荐文章于 2022-09-29 14:17:16 发布

LuckyDeLee

最新推荐文章于 2022-09-29 14:17:16 发布

阅读量255

点赞数

分类专栏： Java基础文章标签： HashMap 并发

本文链接：https://blog.csdn.net/qq_29747683/article/details/78149400

版权

Java基础专栏收录该内容

19 篇文章 0 订阅

订阅专栏

并发环境使用HashMap

在并发场景中，使用HashMap,没有保持足够的同步，可能在执行HashMap.get时进入死循环，将CPU消耗到100%.
HashMap采用的是链表解决Hash冲突，容易形成闭合的链路，这样在循环时候，只要有线程对这个HashMap进行get操作就会产生死循环，应该用ConcurrentHashMap.
闭合回路的产生，在多线程并发、put操作时，如果size>initialCapacity*loadFactor（负载因子默认75%）,hash表会进行扩容，HashMap执行rehasing操作，两个线程可能会同时触发，造成闭合回路。
多线程下HashMap问题：
1.多线程put操作后，get操作导致死循环
2.多线程put非null元素后，get操作得到null值。
3.多线程put操作，导致元素丢失。

扩容(resize)就是重新计算容量，向HashMap对象里不停的添加元素，而HashMap对象内部的数组无法装载更多的元素时，对象就需要扩大数组的长度，以便能装入更多的元素。当然Java里的数组是无法自动扩容的，方法是使用一个新的数组代替已有的容量小的数组，就像我们用一个小桶装水，如果想装更多的水，就得换大水桶。
什么时候扩容：当向容器添加元素的时候，会判断当前容器的元素个数，如果大于等于阈值(知道这个阈字怎么念吗？—即当前数组的长度乘以加载因子的值的时候，自动扩容。

正常rehash

hash算法就是简单的用key mod 一下表的大小（也就是数组的长度）。

最上面的是old hash 表，其中的Hash表的size=2, 所以key = 3, 7, 5，在mod 2以后都冲突在table1这里了。

接下来的三个步骤是Hash表 resize成4，然后所有的重新rehash的过程
这里写图片描述
并发情况下

/**  
 * HashMap 添加节点  
 *  jdk 1.7
 * @param hash        当前key生成的hashcode  
 * @param key         要添加到 HashMap 的key  
 * @param value       要添加到 HashMap 的value  
 * @param bucketIndex 桶，也就是这个要添加 HashMap 里的这个数据对应到数组的位置下标  
 */    

 static int indexFor(int h, int length) {  
    return h & (length - 1);  //对length取模。
}  
void addEntry(int hash, K key, V value, int bucketIndex) {    
    //size：The number of key-value mappings contained in this map.    
    //threshold：The next size value at which to resize (capacity * load factor)    
    //数组扩容条件：1.已经存在的key-value mappings的个数大于等于阈值    
    //             2.底层数组的bucketIndex坐标处不等于null    
    if ((size >= threshold) && (null != table[bucketIndex])) {    
        resize(2 * table.length);//扩容之后，数组长度变了    
        hash = (null != key) ? hash(key) : 0;//为什么要再次计算一下hash值呢？    
        bucketIndex = indexFor(hash, table.length);//扩容之后，数组长度变了，在桶的下标跟数组长度有关，得重算。    
    }    
    createEntry(hash, key, value, bucketIndex);    
}    
    void resize(int newCapacity) {   //传入新的容量  
    Entry[] oldTable = table;    //引用扩容前的Entry数组  
    int oldCapacity = oldTable.length;  
    if (oldCapacity == MAXIMUM_CAPACITY) {  //扩容前的数组大小如果已经达到最大(2^30)了  
        threshold = Integer.MAX_VALUE; //修改阈值为int的最大值(2^31-1)，这样以后就不会扩容了  
        return;  
    }  

    Entry[] newTable = new Entry[newCapacity];  //初始化一个新的Entry数组  
    transfer(newTable);                         //*将数据转移到新的Entry数组里  
    table = newTable;                           //HashMap的table属性引用新的Entry数组  
    threshold = (int) (newCapacity * loadFactor);//修改阈值  
}  
/**  
 * 这地方就是链表出现的地方，有2种情况  
 * 1，原来的桶bucketIndex处是没值的，那么就不会有链表出来啦  
 * 2，原来这地方有值，那么根据Entry的构造函数，把新传进来的key-value mapping放在数组上，原来的就挂在这个新来的next属性上了  
 */    
void createEntry(int hash, K key, V value, int bucketIndex) {    
    HashMap.Entry<K, V> e = table[bucketIndex];    
    table[bucketIndex] = new HashMap.Entry<>(hash, key, value, e);    
    size++;    
}  
/**
  *将原有Entry数组的元素拷贝到新的Entry数组里。
  */
void transfer(Entry[] newTable) {  
    Entry[] src = table;                   //src引用了旧的Entry数组  
    int newCapacity = newTable.length;  
    for (int j = 0; j < src.length; j++) { //遍历旧的Entry数组  
        Entry<K, V> e = src[j];             //取得旧Entry数组的每个元素  
        if (e != null) {  
            src[j] = null;//释放旧Entry数组的对象引用（for循环后，旧的Entry数组不再引用任何对象）  
            do {  
                Entry<K, V> next = e.next;  
                int i = indexFor(e.hash, newCapacity); //！！重新计算每个元素在数组中的位置  
                e.next = newTable[i]; //标记[1]  
                newTable[i] = e;      //将元素放在数组上  
                e = next;             //访问下一个Entry链上的元素  
            } while (e != null);  
        }  
    }  
}

do { 
    Entry<K,V> next = e.next; // <--假设线程一执行到这里就被调度挂起了 
    int i = indexFor(e.hash, newCapacity); 
    e.next = newTable[i]; 
    newTable[i] = e; 
    e = next; 
} while (e != null);

这里写图片描述
线程一的e指向key（3），而next指向key（7），其在线程二rehash后，指向了线程二重组后的链表。
线程一被调度回来执行。

先是执行 newTalbe[i] = e;
然后是e = next，导致了e指向了key(7)，
而下一次循环的next = e.next导致了next指向了key(3)
这里写图片描述
e.next = newTable[i]导致key（3）.next指向了key（7）

环形链接出现。
e.next = newTable[i] 导致 key(3).next 指向了 key(7)
注意：此时的key(7).next 已经指向了key(3)，环形链表就这样出现了。
这里写图片描述

三种解决方案

（1）Hashtable替换HashMap
Hashtable是线程同步吃，但由迭代器返回的Iterator和由所有Hashtable的collection视图方法返回的Collection的listIterator方法都是快速失败的：在创建Iterator之后，如果从结构山对Hashtable进行修改，除非通过Iterator自身的移除或者添加方法，否则在任何时间以任何方式对其进行修改，iterator都将抛出ConcurrentModificationException.面对并发的修改，Iterator 很快就会完全失败，而不冒在将来某个不确定的时间发生任意不确定行为的风险。由 Hashtable 的键和值方法返回的 Enumeration 不是快速失败的。

ps：迭代器的快速失败行为无法得到保证，一般来说，不可能对是否出现不同步并发修改做出任何硬件保证。快速失败迭代器会尽最大努力抛出ConcurrentModificationException。因此，为提高这类迭代器的正确性而编写一个依赖于此异常的程序是错误的做法，迭代器的快速失败行为应该仅用于检测程序错误。

Collections.synchronizedMap将HashMap包装起来

返回由指定映射支持的同步（线程安全）映射。为了保证按顺序访问，必须通过返回的映射完成对底层映射的所有访问。在返回的映射或其任意collection视图上进行迭代时，强制用户手工在返回的映射上同步

    Map m = Collections.synchronizedMap(new HashMap());
    …
    Set s = m.keySet(); // Needn’t be in synchronized block
    …
    synchronized(m) { // Synchronizing on m, not s!
    Iterator i = s.iterator(); // Must be in synchronized block
    while (i.hasNext())
    foo(i.next());
}

不遵从此建议将导致无法确定的行为。如果指定映射是可序列化的，则返回的映射也将是可序列化的。

ConcurrentHashMap替代HashMap

支持检索的完全并发和更新的所期望可调整并发的哈希表。此类遵守与 Hashtable 相同的功能规范，并且包括对应于 Hashtable 的每个方法的方法版本。不过，尽管所有操作都是线程安全的，但检索操作不必锁定，并且不支持以某种防止所有访问的方式锁定整个表。此类可以通过程序完全与 Hashtable 进行互操作，这取决于其线程安全，而与其同步细节无关。
检索操作（包括 get）通常不会受阻塞，因此，可能与更新操作交迭（包括 put 和 remove）。检索会影响最近完成的更新操作的结果。对于一些聚合操作，比如 putAll 和 clear，并发检索可能只影响某些条目的插入和移除。类似地，在创建迭代器/枚举时或自此之后，Iterators 和 Enumerations 返回在某一时间点上影响哈希表状态的元素。它们不会抛出 ConcurrentModificationException。不过，迭代器被设计成每次仅由一个线程使用。

ConcurrentHashMap的底层机制

ConcurrentHashMap的读取并发，因为在读取的大多数时候都没有用到锁定，所以读取操作几乎是完全的并发操作，而写操作锁定的粒度又非常细。只有在求size等操作时才需要锁定整个表。而在迭代时，ConcurrentHashMap使用了不同于传统集合的快速失败迭代器的弱一致迭代器。在这种迭代方式中，当iterator被创建后集合再发生改变就不再是抛出ConcurrentModificationException，取而代之的是在改变时new新的数据从而不影响原有的数据，iterator完成后再将头指针替换为新的数据，这样iterator线程可以使用原来老的数据，而写线程也可以并发的完成改变，更重要的，这保证了多个线程并发执行的连续性和扩展性，是性能提升的关键。

效率底下的HashTable容器

Hashtable继承的是Dictionary（Hashtable是其唯一公开的子类），HashTable容器使用synchronized来保证线程安全，但在线程竞争激烈的情况下HashTable的效率非常低下。因为当一个线程访问HashTable的同步方法时，其他线程访问HashTable的同步方法时，可能会进入阻塞或轮询状态。如线程1使用put进行添加元素，线程2不但不能使用put方法添加元素，并且也不能使用get方法来获取元素，所以竞争越激烈效率越低。

Hashtable的实现方式：锁整个hash表。而ConcurrentHashMap的实现方式：锁桶（或段）

ConcurrentHashMap的分段技术

HashTable容器在竞争激烈的并发环境下表现出效率低下的原因，是因为所有访问HashTable的线程都必须竞争同一把锁，

那假如容器里有多把锁，每一把锁用于锁容器其中一部分数据，那么当多线程访问容器里不同数据段的数据时，线程间就不会存在锁竞争，从而可以有效的提高并发访问效率，这就是ConcurrentHashMap所使用的锁分段技术.

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

　　ConcurrentHashMap是由Segment数组结构和HashEntry数组结构组成。Segment是一种可重入锁ReentrantLock,在ConcurrentHashMap里扮演锁的角色，HashEntry则用于存储键值对数据。一个ConcurrentHashMap里包含一个Segment数组，Segment的结构和HashMap类似，是一种数组和链表结构，一个Segment里包含一个HashEntry数组，每个HashEntry是一个链表结构的元素，每个Segment守护者一个HashEntry数组里的元素，当对HashEntry数组的数据进行修改时，必须首先获得它对应的Segment锁。

ConcurrentHashMap实现原理

锁分离（Lock Stripping）

ConcurrentHashMap内部使用段（Segment）来表示这些不同的部分，每个段其实是一个小的hashtable，它们有自己的锁。只要多个修改操作发生在不同的段上，它们就可以并发进行。同样当一个线程占用锁访问其中一个段数据的时候，其他段的数据也能被其他线程访问。
ConcurrentHashMap有些方法需要跨段，比如size（）和containsValue(),它们可能需要锁定整个表而不只是某个段，这需要按顺序锁定所以段，操作完毕后，又按顺序释放所有段的锁。这里”按顺序”是很重要的，否则极有可能出现死锁，在ConcurrentHashMap内部，段数组是final的，并且其成员变量实际上也是final的，但是，仅仅是将数组声明为final的并不保证数组成员也是final的，，这需要实现上的保证。这可以确保不会出现死锁，因为获得锁的顺序是固定的。不变性是多线程编程占有很重要的地位。
final Segment[] segments.

不变（immutable）和易变（Volatile）

ConcurrentHashMap完全允许多个读操作并发进行，读操作并不需要加锁。如果使用传统的技术，如HashMap中的实现，如果允许可以在hash链的中间添加或删除元素，读操作不加锁将得到不一致的数据。ConcurrentHashMap实现技术是保证HashEntry几乎是不可变的。HashEntry代表每个hash链中的一个节点，其结构如下所示：

static final class HashEntry<K,V> {
   final E key;
   final int hash;
   volatile V value;
   final HashEntry<K,V> next;
}

可以看到除了value不是final的，其他值都是final的，为了防止链表结构被破坏，出现ConcurrentModification的情况。这意味着不能从hash链的中间或者尾部添加或删除节点。因为这需要修改next引用值，所有的节点的修改只能从头部开始。对于put操作，可以一律添加到Hash链的头部。。但是对于remove操作，可能需要从中间删除一个节点，这就需要将要删除节点的前面所有节点整个复制一遍，最后一个节点指向要删除结点的下一个结点，为了确保读操作能够看到最新的值，将value设置成volatile,这避免了加锁。

ConcurrentHashMap的初始化

结合源代码来具体分析一下ConcurrentHashMap的实现，先看下初始化方法：

public ConcurrentHashMap(int initialCapacity,  
                         float loadFactor, int concurrencyLevel) {  
    if (!(loadFactor > 0) || initialCapacity < 0 || concurrencyLevel <= 0)  
        throw new IllegalArgumentException();  

    if (concurrencyLevel > MAX_SEGMENTS)  
        concurrencyLevel = MAX_SEGMENTS;  

    // Find power-of-two sizes best matching arguments  
    int sshift = 0;  
    int ssize = 1;  
    while (ssize < concurrencyLevel) {  
        ++sshift;  
        ssize <<= 1;  
    }  
    segmentShift = 32 - sshift;  
    segmentMask = ssize - 1;  
    this.segments = Segment.newArray(ssize);  

    if (initialCapacity > MAXIMUM_CAPACITY)  
        initialCapacity = MAXIMUM_CAPACITY;  
    int c = initialCapacity / ssize;  
    if (c * ssize < initialCapacity)  
        ++c;  
    int cap = 1;  
    while (cap < c)  
        cap <<= 1;  

    for (int i = 0; i < this.segments.length; ++i)  
        this.segments[i] = new Segment<K,V>(cap, loadFactor);  
}

CurrentHashMap的初始化一共有三个参数，一个initialCapacity，表示初始的容量，一个loadFactor，表示负载参数，最后一个是concurrentLevel，代表ConcurrentHashMap内部的Segment的数量，ConcurrentLevel一经指定，不可改变，后续如果ConcurrentHashMap的元素数量增加导致ConrruentHashMap需要扩容，ConcurrentHashMap不会增加Segment的数量，而只会增加Segment中链表数组的容量大小，这样的好处是扩容过程不需要对整个ConcurrentHashMap做rehash，而只需要对Segment里面的元素做一次rehash就可以了。

整个ConcurrentHashMap的初始化方法还是非常简单的，先是根据concurrentLevel来new出Segment，这里Segment的数量是不大于concurrentLevel的最大的2的指数，就是说Segment的数量永远是2的指数个，这样的好处是方便采用移位操作来进行hash，加快hash的过程。接下来就是根据intialCapacity确定Segment的容量的大小，每一个Segment的容量大小也是2的指数，同样使为了加快hash的过程。

这边需要特别注意一下两个变量，分别是segmentShift和segmentMask，这两个变量在后面将会起到很大的作用，假设构造函数确定了Segment的数量是2的n次方，那么segmentShift就等于32减去n，而segmentMask就等于2的n次方减一。

ConcurrentHashMap的get操作

public V get(Object key) { 
    int hash = hash(key.hashCode()); 
    return segmentFor(hash).get(key, hash); 
}

segmentFor这个函数用于确定操作应该在哪一个segment中进行，几乎对ConcurrentHashMap的所有操作都需要用到这个函数

final Segment<K,V> segmentFor(int hash) { 
    return segments[(hash >>> segmentShift) & segmentMask]; 
}

这个函数用了位操作来确定Segment，根据传入的hash值向右无符号右移segmentShift位，然后和segmentMask进行与操作，结合我们之前说的segmentShift和segmentMask的值，就可以得出以下结论：假设Segment的数量是2的n次方，根据元素的hash值的高n位就可以确定元素到底在哪一个Segment中。

　　在确定了需要在哪一个segment中进行操作以后，接下来的事情就是调用对应的Segment的get方法：
　　

V get(Object key, int hash) { 
    if (count != 0) { // read-volatile 
        HashEntry<K,V> e = getFirst(hash); 
        while (e != null) { 
            if (e.hash == hash && key.equals(e.key)) { 
                V v = e.value; 
                if (v != null) 
                    return v; 
                return readValueUnderLock(e); // recheck 
            } 
            e = e.next; 
        } 
    } 
    return null; 
}

get操作不需要锁。第一步是访问count变量，这是一个volatile变量，由于所有的修改操作在进行结构修改时都会在最后一步写count变量，通过这种机制保证get操作能够得到几乎最新的结构更新。对于非结构更新，也就是结点值的改变，由于HashEntry的value变量是volatile的，也能保证读取到最新的值。接下来就是对hash链进行遍历找到要获取的结点，如果没有找到，直接访回null。对hash链进行遍历不需要加锁的原因在于链指针next是final的。但是头指针却不是final的，这是通过getFirst(hash)方法返回，也就是存在table数组中的值。这使得getFirst(hash)可能返回过时的头结点，例如，当执行get方法时，刚执行完getFirst(hash)之后，另一个线程执行了删除操作并更新头结点，这就导致get方法中返回的头结点不是最新的。这是可以允许，通过对count变量的协调机制，get能读取到几乎最新的数据，虽然可能不是最新的。要得到最新的数据，只有采用完全的同步。

V readValueUnderLock(HashEntry<K,V> e) { 
    lock(); 
    try { 
        return e.value; 
    } finally { 
        unlock(); 
    } 
}

最后，如果找到了所求的结点，判断它的值如果非空就直接返回，否则在有锁的状态下再读一次。这似乎有些费解，理论上结点的值不可能为空，这是因为put的时候就进行了判断，如果为空就要抛NullPointerException。空值的唯一源头就是HashEntry中的默认值，因为HashEntry中的value不是final的，非同步读取有可能读取到空值。仔细看下put操作的语句：tab[index] = new HashEntry(key, hash, first, value)，在这条语句中，HashEntry构造函数中对value的赋值以及对tab[index]的赋值可能被重新排序，这就可能导致结点的值为空。这种情况应当很罕见，一旦发生这种情况，ConcurrentHashMap采取的方式是在持有锁的情况下再读一遍，这能够保证读到最新的值，并且一定不会为空值。

　　对volatile字段的写入操作happens-before于每一个后续的同一个字段的读操作。
　　因为实际上put、remove等操作也会更新count的值，所以当竞争发生的时候，volatile的语义可以保证写操作在读操作之前，也就保证了写操作对后续的读操作都是可见的，这样后面get的后续操作就可以拿到完整的元素内容。　　

ConcurrentHashMap的put操作

V put(K key, int hash, V value, boolean onlyIfAbsent) { 
    lock();  //加锁
    try { 
        int c = count; 
        if (c++ > threshold) // ensure capacity 
            rehash();  //看是否需要rehash
        HashEntry<K,V>[] tab = table; 
        int index = hash & (tab.length - 1); 
        HashEntry<K,V> first = tab[index];  //确定链表头部的位置
        HashEntry<K,V> e = first; 
        while (e != null && (e.hash != hash || !key.equals(e.key))) 
            e = e.next; 

        V oldValue; 
        if (e != null) {  //如果存在，替换掉value
            oldValue = e.value; 
            if (!onlyIfAbsent) 
                e.value = value; 
        } 
        else { 
            oldValue = null; 
            ++modCount;   //修改modCount和count?
            tab[index] = new HashEntry<K,V>(key, hash, first, value);  //创建一个新的结点并添加到hash链的头部
            count = c; // write-volatile 
        } 
        return oldValue; 
    } finally { 
        unlock(); 
    } 
}

首先对Segment的put操作是加锁完成的，然后在第五行，如果Segment中元素的数量超过了阈值（由构造函数中的loadFactor算出）这需要进行对Segment扩容，并且要进行rehash。

第8和第9行的操作就是getFirst的过程，确定链表头部的位置。
第11行这里的这个while循环是在链表中寻找和要put的元素相同key的元素，如果找到，就直接更新更新key的value，如果没有找到，则进入21行这里，生成一个新的HashEntry并且把它加到整个Segment的头部，然后再更新count的值。

　　修改操作还有putAll和replace。putAll就是多次调用put方法。replace甚至不用做结构上的更改，实现要比put和delete要简单得多.

ConcurrentHashMap的remove操作

Remove操作的前面一部分和前面的get和put操作一样，都是定位Segment的过程，然后再调用Segment的remove方法

V remove(Object key, int hash, Object value) { 
    lock(); 
    try { 
        int c = count - 1; 
        HashEntry<K,V>[] tab = table; 
        int index = hash & (tab.length - 1); 
        HashEntry<K,V> first = tab[index]; 
        HashEntry<K,V> e = first; 
        while (e != null && (e.hash != hash || !key.equals(e.key))) 
            e = e.next;  //空白行之前的行主要是定位到要删除的节点e

        V oldValue = null; 
        if (e != null) {  
            V v = e.value; 
            if (value == null || value.equals(v)) {  
                oldValue = v; 
                // All entries following removed node can stay 
                // in list, but all preceding ones need to be 
                // cloned. 
                ++modCount; 
                HashEntry<K,V> newFirst = e.next; 
                for (HashEntry<K,V> p = first; p != e; p = p.next) 
                    newFirst = new HashEntry<K,V>(p.key, p.hash, 
                                                  newFirst, p.value); 
                tab[index] = newFirst; 
                count = c; // write-volatile 
            } 
        } 
        return oldValue; 
    } finally { 
        unlock(); 
    } 
}

整个操作是先定位到段，然后委托给段的remove操作。当多个删除操作并发进行时，只要它们所在的段不相同，它们就可以同时进行。下面是Segment的remove方法实现

　　首先remove操作也是确定需要删除的元素的位置，HashEntry中的next是final的，一经赋值以后就不可修改，在定位到待删除元素的位置以后，程序就将待删除元素前面的那一些元素全部复制一遍，然后再一个一个重新接到链表上去.

　　将e前面的结点复制一遍，尾结点指向e的下一个结点。e后面的结点不需要复制，它们可以重用.

ConcurrentHashMap的size操作

在前面的章节中，我们涉及到的操作都是在单个Segment中进行的，但是ConcurrentHashMap有一些操作是在多个Segment中进行，比如size操作，ConcurrentHashMap的size操作也采用了一种比较巧的方式，来尽量避免对所有的Segment都加锁。

前面我们提到了一个Segment中的有一个modCount变量，代表的是对Segment中元素的数量造成影响的操作的次数，这个值只增不减，size操作就是遍历了两次Segment，每次记录Segment的modCount值，然后将两次的modCount进行比较，如果相同，则表示期间没有发生过写入操作，就将原先遍历的结果返回，如果不相同，则把这个过程再重复做一次，如果再不相同，则就需要将所有的Segment都锁住，然后一个一个遍历了.

参考：
http://www.cnblogs.com/andy-zhou/p/5402984.html

http://www.cnblogs.com/kxdblog/p/4323892.html

LuckyDeLee

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
concurrentHashMap

并发环境使用HashMap在并发场景中，使用HashMap,没有保持足够的同步，可能在执行HashMap.get时进入死循环，将CPU消耗到100%. HashMap采用的是链表解决Hash冲突，容易形成闭合的链路，这样在循环时候，只要有线程对这个HashMap进行get操作就会产生死循环，应该用ConcurrentHashMap.
复制链接

扫一扫