java8 中concurrenthashmap数据结构和HashMap一样，且线程安全为啥还要HashMap

Posted 2023-03-21

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了java8 中concurrenthashmap数据结构和HashMap一样，且线程安全为啥还要HashMap相关的知识，希望对你有一定的参考价值。

java阻塞队列应用于生产者消费者模式、消息传递、并行任务执行和相关并发设计的大多数常见使用上下文。

BlockingQueue在Queue接口基础上提供了额外的两种类型的操作，分别是获取元素时等待队列变为非空和添加元素时等待空间变为可用。

BlockingQueue新增操作的四种形式：

请点击输入图片描述

插入操作是指向队列中添加一个元素，至于元素存放的位置与具体队列的实现有关。移除操作将会移除队列的头部元素，并将这个移除的元素作为返回值反馈给调用者。检查操作是指返回队列的头元素给调用者，队列不对这个头元素进行删除处理。

抛出异常形式的操作，在队列已满的情况下，调用add方法将会抛出IllegalStateException异常。如果调用remove方法时，队列已经为空，则抛出一个NoSuchElementException异常。（实际上，remove方法还可以附带一个参数，用来删除队列中的指定元素，如果这个元素不存在，也会抛出NoSuchElementException异常）。如果调用element检查头元素，队列为空时，将会抛出NoSuchElementException异常。

特殊值操作与抛出异常不同，在出错的时候，返回一个空指针，而不会抛出异常。

阻塞形式的操作，调用put方法时，如果队列已满，则调用线程阻塞等待其它线程从队列中取出元素。调用take方法时，如果阻塞队列已经为空，则调用线程阻塞等待其它线程向队列添加新元素。

超时形式操作，在阻塞的基础上添加一个超时限制，如果等待时间超过指定值，抛出InterruptedException。

阻塞队列实现了Queue接口，而Queue接口实现了Collection接口，因此BlockingQueue也提供了remove(e)操作，即从队列中移除任意指定元素，但是这个操作往往不会按预期那样高效的执行，所以应当尽量少的使用这种操作。

阻塞队列与并发队列（例如ConcurrentLinkQueue）都是线程安全的，但使用的场合不同。

Graphic3-1给出了阻塞队列的接口方法，Graphic3-2给出了阻塞队列的实现类结构。

Graphic 3-1 BlockingQueue接口

Graphic3-2阻塞队列的实现类

请点击输入图片描述

3.1.1 ArrayBlockingQueue类

一个以数组为基础的有界阻塞队列，此队列按照先进先出原则对元素进行排序。队列头部元素是队列中存在时间最长的元素，队列尾部是存在时间最短的元素，新元素将会被插入到队列尾部。队列从头部开始获取元素。

ArrayBlockingQueue是“有界缓存区”模型的一种实现，一旦创建了这样的缓存区，就不能再改变缓冲区的大小。ArrayBlockingQueue的一个特点是，必须在创建的时候指定队列的大小。当缓冲区已满，则需要阻塞新增的插入操作，同理，当缓冲区已空需要阻塞新增的提取操作。

ArrayBlockingQueue是使用的是循环队列方法实现的，对ArrayBlockingQueue的相关操作的时间复杂度，可以参考循环队列进行分析。

3.1.2 LinkedBlockingQueue

一种通过链表实现的阻塞队列，支持先进先出。队列的头部是队列中保持时间最长的元素，队列的尾部是保持时间最短的元素。新元素插入队列的尾部。可选的容量设置可以有效防止队列过于扩张造成系统资源的过多消耗，如果不指定队列容量，队列默认使用Integer.MAX_VALUE。LinkedBlockingQueue的特定是，支持无限（理论上）容量。

3.1.3 PriorityBlockingQueue

PriorityBlockingQueue是一种基于优先级进行排队的无界队列。队列中的元素按照其自然顺序进行排列，或者根据提供的Comparator进行排序，这与构造队列时，提供的参数有关。

使用提取方法时，队列将返回头部，具有最高优先级（或最低优先级，这与排序规则有关）的元素。如果多个元素具有相同的优先级，则同等优先级间的元素获取次序无特殊说明。

优先级队列使用的是一种可扩展的数组结构，一般可以认为这个队列是无界的。当需要新添加一个元素时，如果此时数组已经被填满，优先队列将会自动扩充当前数组（一般认为是，先分配一个原数组一定倍数空间的数组，之后将原数组中的元素拷贝到新分配的数组中，释放原数组的空间）。

如果使用优先级队列的iterator变量队列时，不保证遍历次序按照优先级大小进行。因为优先级队列使用的是堆结构。如果需要按照次序遍历需要使用Arrays.sort(pq.toArray())。关于堆结构的相关算法，请查考数据结构相关的书籍。

在PriorityBlockingQueue的实现过程中聚合了PriorityQueue的一个实例，并且优先队列的操作完全依赖与PriorityQueue的实现。在PriorityQueue中使用了一个一维数组来存储相关的元素信息。一维数组使用最小堆算法进行元素添加。

Graphic3-3PriorityBlockingQueue的类关系

请点击输入图片描述

3.1.4 DelayQueue

一个无界阻塞队列，只有在延时期满时才能从中提取元素。如果没有元素到达延时期，则没有头元素。

3.2 并发集合

在多线程程序中使用的集合类，与普通程序中使用的集合类是不同的。因为有可能多个线程同时访问或修改同一集合，如果使用普通集合，很可能造成相应操作出现差错，甚至崩溃。Java提供了用于线程访问安全的集合。（前面讨论的BlockingQueue也是这里集合中的一种）。下面针对这些集合，以及集合中使用的相应算法进行探讨。在设计算法时，仅对相应算法进行简要说明，如果读者需要深入了解这些算法的原理，请参考其他的高级数据结构相关的书籍。

3.2.1 ConcurrentMap接口

ConcurrentMap接口在Map接口的基础上提供了一种线程安全的方法访问机制。ConcurrentMap接口额外提供了多线程使用的四个方法，这四个方法实际是对Map已有方法的一个组合，并对这种组合提供一种原子操作。Graphic3-4给出了ConcurrentMap相关的操作。Graphic3-5给出了ConcurrentMap的实现类关系图。

从Graphic3-5中可以看出ConcurrentNavigableMap继承自ConcurrentMap，ConcurrentNavigableMap是一种SortedMap，就是说，映射中的元素会根据键值进行排序的。在java.util类库中，有两个类实现了SortedMap接口，分别是TreeMap和ConcurrentSkipListMap。TreeMap使用的是红黑树结构。而ConcurrentSkipListMap使用作为底层实现的SkipList（翻译为跳表）数据结构。此外ConcurrentHashMap实现了ConcurrentMap接口，使用的是HashMap方法。

Graphic3-4 ConcurrentMap

Graphic3-5 实现ConcurrentMap接口。

请点击输入图片描述

3.2.1.1 TreeMap

尽管TreeMap不是线程安全的，但是基于其数据结构的复杂性和方便对比说明，还是在这里简单提一下。TreeMap实现了SortedMap接口。TreeMap使用的是红黑树（这是高等数据结构中的一种），在红黑树算法中，当添加或删除节点时，需要进行旋转调整树的高度。使用红黑树算法具有较好的操作特性，插入、删除、查找都能在O(log(n))时间内完成。红黑树理论和实现是很复杂的，但可以带来较高的效率，因此在许多场合也得到了广泛使用。红黑树的一个缺陷在于，可变操作很可能影响到整棵树的结构，针对修改的局部效果不好。相关算法请参考http://blog.sina.com.cn/s/blog_616e189f0100qgcm.html。

TreeMap不是线程安全的，如果同时有多个线程访问同一个Map，并且其中至少有一个线程从结构上修改了该映射，则必须使用外部同步。可以使用Collections.synchronizedSortedMap方法来包装该映射。（注意使用包装器包装的SortMap是线程安全的，但不是并发的，效率上很可能远远不及ConcurrentSkipListMap，因此使用包装器的方法并不十分推荐，有人认为那是一种过时的做法。包装器使用了锁机制控制对Map的并发访问，但是这种加锁的粒度可能过大，很可能影响并发度）。

3.2.1.2 ConcurrentSkipListMap

另外一种实现了SortedMap接口的映射表是ConcurrentSkipListMap。ConcurrentSkipListMap提供了一种线程安全的并发访问的排序映射表。SkipList（跳表）结构，在理论上能够在O(log(n))时间内完成查找、插入、删除操作。SkipList是一种红黑树的替代方案，由于SkipList与红黑树相比无论从理论和实现都简单许多，所以得到了很好的推广。SkipList是基于一种统计学原理实现的，有可能出现最坏情况，即查找和更新操作都是O(n)时间复杂度，但从统计学角度分析这种概率极小。Graphic3-6给出了SkipList的数据表示示例。有关skipList更多的说明可以参考：http://blog.csdn.net/caoeryingzi/archive/2010/11/18/6018070.aspx 和http://en.wikipedia.org/wiki/Skip_list 这里不在累述。希望读者自行学习。

使用SkipList类型的数据结构更容易控制多线程对集合访问的处理，因为链表的局部处理性比较好，当多个线程对SkipList进行更新操作（指插入和删除）时，SkipList具有较好的局部性，每个单独的操作，对整体数据结构影响较小。而如果使用红黑树，很可能一个更新操作，将会波及整个树的结构，其局部性较差。因此使用SkipList更适合实现多个线程的并发处理。在非多线程的情况下，应当尽量使用TreeMap，因为似乎红黑树结构要比SkipList结构执行效率略优（无论是时间复杂度还是空间复杂度，作者没有做够测试，只是直觉）。此外对于并发性相对较低的并行程序可以使用Collections.synchronizedSortedMap将TreeMap进行包装，也可以提供较好的效率。对于高并发程序，应当使用ConcurrentSkipListMap，能够提供更高的并发度。

所以在多线程程序中，如果需要对Map的键值进行排序时，请尽量使用ConcurrentSkipListMap，可能得到更好的并发度。

注意，调用ConcurrentSkipListMap的size时，由于多个线程可以同时对映射表进行操作，所以映射表需要遍历整个链表才能返回元素个数，这个操作是个O(log(n))的操作。

Graphic3-6 SkipList示例

请点击输入图片描述

3.2.1.3 HashMap类

对Map类的另外一个实现是HashMap。HashMap使用Hash表数据结构。HashMap假定哈希函数能够将元素适当的分布在各桶之间，提供一种接近O(1)的查询和更新操作。但是如果需要对集合进行迭代，则与HashMap的容量和桶的大小有关，因此HashMap的迭代效率不会很高（尤其是你为HashMap设置了较大的容量时）。

与HashMap性能有影响的两个参数是，初始容量和加载因子。容量是哈希表中桶的数量，初始容量是哈希表在创建时的容量。加载因子是哈希表在容器容量被自动扩充之前，HashMap能够达到多满的一种程度。当hash表中的条目数超出了加载因子与当前容量的乘积时，Hash表需要进行rehash操作，此时Hash表将会扩充为以前两倍的桶数，这个扩充过程需要进行完全的拷贝工作，效率并不高，因此应当尽量避免。合理的设置Hash表的初始容量和加载因子会提高Hash表的性能。HashMap自身不是线程安全的，可以通过Collections的synchronizedMap方法对HashMap进行包装。

3.2.1.4 ConcurrentHashMap类

ConcurrentHashMap类实现了ConcurrentMap接口，并提供了与HashMap相同的规范和功能。实际上Hash表具有很好的局部可操作性，因为对Hash表的更新操作仅会影响到具体的某个桶（假设更新操作没有引发rehash），对全局并没有显著影响。因此ConcurrentHashMap可以提供很好的并发处理能力。可以通过concurrencyLevel的设置，来控制并发工作线程的数目（默认为16），合理的设置这个值，有时很重要，如果这个值设置的过高，那么很有可能浪费空间和时间，使用的值过低，又会导致线程的争用，对数量估计的过高或过低往往会带来明显的性能影响。最好在创建ConcurrentHashMap时提供一个合理的初始容量，毕竟rehash操作具有较高的代价。

3.2.2 ConcurrentSkipListSet类

实际上Set和Map从结构来说是很像的，从底层的算法原理分析，Set和Map应当属于同源的结构。所以Java也提供了TreeSet和ConcurrentSkipListSet两种SortedSet，分别适合于非多线程（或低并发多线程）和多线程程序使用。具体的算法请参考前述的Map相关介绍，这里不在累述。

3.2.3 CopyOnWriteArrayList类

CopyOnWriteArrayList是ArrayList的一个线程安全的变体，其中对于所有的可变操作都是通过对底层数组进行一次新的复制来实现的。

由于可变操作需要对底层的数据进行一次完全拷贝，因此开销一般较大，但是当遍历操作远远多于可变操作时，此方法将会更有效，这是一种被称为“快照”的模式，数组在迭代器生存期内不会发生更改，因此不会产生冲突。创建迭代器后，迭代器不会反映列表的添加、移除或者更改。不支持在迭代器上进行remove、set和add操作。CopyOnWriteArraySet与CopyOnWriteArrayList相似，只不过是Set类的一个变体。

3.2.3 Collections提供的线程安全的封装

Collections中提供了synchronizedCollection、synchronizedList、synchronizedMap、synchronizedSet、synchronizedSortedMap、synchronizedSortedMap等方法可以完成多种集合的线程安全的包装，如果在并发度不高的情况下，可以考虑使用这些包装方法，不过由于Concurrent相关的类的出现，已经不这么提倡使用这些封装了，这些方法有些人称他们为过时的线程安全机制。

3.2.4 简单总结

提供线程安全的集合简单概括分为三类，首先，对于并发性要求很高的需求可以选择以Concurrent开头的相应的集合类，这些类主要包括：ConcurrentHashMap、ConcurrentLinkedQueue、ConcurrentSkipListMap、ConcurrentSkipSet。其次对于可变操作次数远远小于遍历的情况，可以使用CopyOnWriteArrayList和CopyOnWriteArraySet类。最后，对于并发规模比较小的并行需求可以选择Collections类中的相应方法对已有集合进行封装。

此外，本章还对一些集合类的底层实现进行简单探讨，对底层实现的了解有利于对何时使用何种方式作出正确判断。希望大家能够将涉及到原理（主要有循环队列、堆、HashMap、红黑树、SkipList）进行仔细研究，这样才能更深入了解Java为什么这样设计类库，在什么情况使用，应当如何使用。

参考技术A

结构虽类似（数组+链表/红黑二叉树），但 ConcurrentHashMap采用CAS和synchronized来保证并发安全，它的链表或红黑二叉树的首节点会被锁，因此ConcurrentHashMap看起来就像优化过且线程安全的 HashMap。

但假如你线程本来就是安全的，何必要用性能换安全即用ConcurrentHashMap替代HashMap呢。

所以HashMap的存在是合理的。

参考技术B 首先一般开发有不少情况map会是在方法内创建并使用的局部变量，那么一般应该考虑的是方法是否需要保证线程安全是吧。
如果方法是线程安全的就完全没必要使用ConcurrentHashMap了。
另外如果在线程安全的方法中使用Map HashMap的性能要比ConcurrentHashMap高。
Map 如果作为类属性的话需要保持线程安全的话当然要考虑ConcurrentHashMap。参考技术C ConcurrentHashMap在读写数据时都需要加锁，这会带来性能开销。如果使用场景中不需要考虑线程安全问题，那么自然使用HashMap要比使用ConcurrentHashMap更为高效。参考技术D HashMap 效率比concurrenthashmap高就像楼上小裤衩说的map在方法内部定义使用，就用HashMap就可以了。

1.7&1.8-ConcurrentHashMap对比

导语：前文写了关于1.7ConcurrentHashMap原理的简单分析，本次针对1.8版本的升级，对数据结构和使用方式进行简单对比，梳理了一些质量不错的网络博客，对比数据结构、寻址方式、扩容方式，1.8进行了较大的改变，明显提升了效率。

Java 7基于分段锁的ConcurrentHashMap

注：本章的代码均基于JDK 1.7.0_67

数据结构

Java 7中的ConcurrentHashMap的底层数据结构仍然是数组和链表。与HashMap不同的是，ConcurrentHashMap最外层不是一个大的数组，而是一个Segment的数组。每个Segment包含一个与HashMap数据结构差不多的链表数组。整体数据结构如下图所示。 JAVA 7 ConcurrentHashMap

寻址方式

在读写某个Key时，先取该Key的哈希值。并将哈希值的高N位对Segment个数取模从而得到该Key应该属于哪个Segment，接着如同操作HashMap一样操作这个Segment。为了保证不同的值均匀分布到不同的Segment，需要通过如下方法计算哈希值。

  
    
    
  
   
     
     
   private int hash(Object k) {
   
     
     
     int h = hashSeed;
   
     
     
     if ((0 != h) && (k instanceof String)) {
   
     
     
       return sun.misc.Hashing.stringHash32((String) k);
   
     
     
     }
   
     
     
     h ^= k.hashCode();
   
     
     
     h += (h <<  15) ^ 0xffffcd7d;
   
     
     
     h ^= (h >>> 10);
   
     
     
     h += (h <<   3);
   
     
     
     h ^= (h >>>  6);
   
     
     
     h += (h <<   2) + (h << 14);
   
     
     
     return h ^ (h >>> 16);
   
     
     
   }

同样为了提高取模运算效率，通过如下计算，ssize即为大于concurrencyLevel的最小的2的N次方，同时segmentMask为2^N-1。这一点跟上文中计算数组长度的方法一致。对于某一个Key的哈希值，只需要向右移segmentShift位以取高sshift位，再与segmentMask取与操作即可得到它在Segment数组上的索引。

  
    
    
  
   
     
     
   int sshift = 0;
   
     
     
   int ssize = 1;
   
     
     
   while (ssize < concurrencyLevel) {
   
     
     
     ++sshift;
   
     
     
     ssize <<= 1;
   
     
     
   }
   
     
     
   this.segmentShift = 32 - sshift;
   
     
     
   this.segmentMask = ssize - 1;
   
     
     
   Segment<K,V>[] ss = (Segment<K,V>[])new Segment[ssize];

同步方式

Segment继承自ReentrantLock，所以我们可以很方便的对每一个Segment上锁。

对于读操作，获取Key所在的Segment时，需要保证可见性(请参考如何保证多线程条件下的可见性)。具体实现上可以使用volatile关键字，也可使用锁。但使用锁开销太大，而使用volatile时每次写操作都会让所有CPU内缓存无效，也有一定开销。ConcurrentHashMap使用如下方法保证可见性，取得最新的Segment。

  
    
    
  
   
     
     
   Segment<K,V> s = (Segment<K,V>)UNSAFE.getObjectVolatile(segments, u)

获取Segment中的HashEntry时也使用了类似方法

  
    
    
  
   
     
     
   HashEntry<K,V> e = (HashEntry<K,V>) UNSAFE.getObjectVolatile
   
     
     
     (tab, ((long)(((tab.length - 1) & h)) << TSHIFT) + TBASE)

对于写操作，并不要求同时获取所有Segment的锁，因为那样相当于锁住了整个Map。它会先获取该Key-Value对所在的Segment的锁，获取成功后就可以像操作一个普通的HashMap一样操作该Segment，并保证该Segment的安全性。同时由于其它Segment的锁并未被获取，因此理论上可支持concurrencyLevel（等于Segment的个数）个线程安全的并发读写。

获取锁时，并不直接使用lock来获取，因为该方法获取锁失败时会挂起（参考可重入锁）。事实上，它使用了自旋锁，如果tryLock获取锁失败，说明锁被其它线程占用，此时通过循环再次以tryLock的方式申请锁。如果在循环过程中该Key所对应的链表头被修改，则重置retry次数。如果retry次数超过一定值，则使用lock方法申请锁。

这里使用自旋锁是因为自旋锁的效率比较高，但是它消耗CPU资源比较多，因此在自旋次数超过阈值时切换为互斥锁。

size操作

put、remove和get操作只需要关心一个Segment，而size操作需要遍历所有的Segment才能算出整个Map的大小。一个简单的方案是，先锁住所有Sgment，计算完后再解锁。但这样做，在做size操作时，不仅无法对Map进行写操作，同时也无法进行读操作，不利于对Map的并行操作。

为更好支持并发操作，ConcurrentHashMap会在不上锁的前提逐个Segment计算3次size，如果某相邻两次计算获取的所有Segment的更新次数（每个Segment都与HashMap一样通过modCount跟踪自己的修改次数，Segment每修改一次其modCount加一）相等，说明这两次计算过程中无更新操作，则这两次计算出的总size相等，可直接作为最终结果返回。如果这三次计算过程中Map有更新，则对所有Segment加锁重新计算Size。该计算方法代码如下

  
    
    
  
   
     
     
   public int size() {
   
     
     
     final Segment<K,V>[] segments = this.segments;
   
     
     
     int size;
   
     
     
     boolean overflow; // true if size overflows 32 bits
   
     
     
     long sum;         // sum of modCounts
   
     
     
     long last = 0L;   // previous sum
   
     
     
     int retries = -1; // first iteration isn't retry
   
     
     
     try {
   
     
     
       for (;;) {
   
     
     
         if (retries++ == RETRIES_BEFORE_LOCK) {
   
     
     
           for (int j = 0; j < segments.length; ++j)
   
     
     
             ensureSegment(j).lock(); // force creation
   
     
     
         }
   
     
     
         sum = 0L;
   
     
     
         size = 0;
   
     
     
         overflow = false;
   
     
     
         for (int j = 0; j < segments.length; ++j) {
   
     
     
           Segment<K,V> seg = segmentAt(segments, j);
   
     
     
           if (seg != null) {
   
     
     
             sum += seg.modCount;
   
     
     
             int c = seg.count;
   
     
     
             if (c < 0 || (size += c) < 0)
   
     
     
               overflow = true;
   
     
     
           }
   
     
     
         }
   
     
     
         if (sum == last)
   
     
     
           break;
   
     
     
         last = sum;
   
     
     
       }
   
     
     
     } finally {
   
     
     
       if (retries > RETRIES_BEFORE_LOCK) {
   
     
     
         for (int j = 0; j < segments.length; ++j)
   
     
     
           segmentAt(segments, j).unlock();
   
     
     
       }
   
     
     
     }
   
     
     
     return overflow ? Integer.MAX_VALUE : size;
   
     
     
   }

不同之处

ConcurrentHashMap与HashMap相比，有以下不同点

ConcurrentHashMap线程安全，而HashMap非线程安全 HashMap允许Key和Value为null，而ConcurrentHashMap不允许 HashMap不允许通过Iterator遍历的同时通过HashMap修改，而ConcurrentHashMap允许该行为，并且该更新对后续的遍历可见

Java 8基于CAS的ConcurrentHashMap

注：本章的代码均基于JDK 1.8.0_111

数据结构

Java 7为实现并行访问，引入了Segment这一结构，实现了分段锁，理论上最大并发度与Segment个数相等。Java 8为进一步提高并发性，摒弃了分段锁的方案，而是直接使用一个大的数组。同时为了提高哈希碰撞下的寻址性能，Java 8在链表长度超过一定阈值（8）时将链表（寻址时间复杂度为O(N)）转换为红黑树（寻址时间复杂度为O(long(N))）。其数据结构如下图所示

JAVA 8 ConcurrentHashMap

寻址方式

Java 8的ConcurrentHashMap同样是通过Key的哈希值与数组长度取模确定该Key在数组中的索引。同样为了避免不太好的Key的hashCode设计，它通过如下方法计算得到Key的最终哈希值。不同的是，Java 8的ConcurrentHashMap作者认为引入红黑树后，即使哈希冲突比较严重，寻址效率也足够高，所以作者并未在哈希值的计算上做过多设计，只是将Key的hashCode值与其高16位作异或并保证最高位为0（从而保证最终结果为正整数）。

  
    
    
  
   
     
     
   static final int spread(int h) {
   
     
     
     return (h ^ (h >>> 16)) & HASH_BITS;
   
     
     
   }

同步方式

对于put操作，如果Key对应的数组元素为null，则通过CAS操作将其设置为当前值。如果Key对应的数组元素（也即链表表头或者树的根元素）不为null，则对该元素使用synchronized关键字申请锁，然后进行操作。如果该put操作使得当前链表长度超过一定阈值，则将该链表转换为树，从而提高寻址效率。

对于读操作，由于数组被volatile关键字修饰，因此不用担心数组的可见性问题。同时每个元素是一个Node实例（Java 7中每个元素是一个HashEntry），它的Key值和hash值都由final修饰，不可变更，无须关心它们被修改后的可见性问题。而其Value及对下一个元素的引用由volatile修饰，可见性也有保障。

  
    
    
  
   
     
     
   static class Node<K,V> implements Map.Entry<K,V> {
   
     
     
     final int hash;
   
     
     
     final K key;
   
     
     
     volatile V val;
   
     
     
     volatile Node<K,V> next;
   
     
     
   }

对于Key对应的数组元素的可见性，由Unsafe的getObjectVolatile方法保证。

  
    
    
  
   
     
     
   static final <K,V> Node<K,V> tabAt(Node<K,V>[] tab, int i) {
   
     
     
     return (Node<K,V>)U.getObjectVolatile(tab, ((long)i << ASHIFT) + ABASE);
   
     
     
   }

size操作

put方法和remove方法都会通过addCount方法维护Map的size。size方法通过sumCount获取由addCount方法维护的Map的size。

java8 中concurrenthashmap数据结构和HashMap一样，且线程安全 为啥还要HashMap

1.7&1.8-ConcurrentHashMap对比

Java 7基于分段锁的ConcurrentHashMap

数据结构

寻址方式

同步方式

size操作

不同之处

Java 8基于CAS的ConcurrentHashMap

数据结构

寻址方式

同步方式

size操作

java8 中concurrenthashmap数据结构和HashMap一样，且线程安全为啥还要HashMap