HashMap与ConcurrentHashMap的内存占用与get操作性能比较

最新推荐文章于 2025-10-30 15:56:26 发布
原创 最新推荐文章于 2025-10-30 15:56:26 发布 · 1.4w 阅读 · 6 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#hashmap #性能 #测试

一、测试背景

        项目中需要提供一个单机计算视频相似度的服务，计算的方式是对视频标题进行分词，提取关键词，然后通过word2vec的方式对关键词进行embedding，最后通过向量累加得到视频的词向量，然后通过某种相似度算法（比如欧式距离）得到视频相似度。这个服务要求5ms返回，可行性预研阶段需要估算响应时间能否达到要求，需要多少台机器支撑每天50亿的请求量。这里面有两个关键内容需要估算，一个是响应时间是多少，能否达到5ms的要求；另一个是每个服务需要多少存储空间（从而估算一台64G的机器能跑几个实例，这里假定一个实例能支撑的QPS是已知的）。这个服务中占用内存最大的是存储80万的词向量，时间消耗比较大的地方也是词向量的读取。

二、实现思路

         每次计算视频相似度需要大概查询150次词向量（50个视频乘以3个关键词），大量的时间都花在词向量查询，如果使用分布式缓存进行存储词向量，都不能够达到预期，所以初步设计是存在内存中，使用HashMap进行存储，Map的key是关键词，value是一个float数组。我们从生成好的80万词向量文件中随机抽取了10%的数据约81000行，样例文件大小225M，数据样例如下：


现在需要对程序使用内存进行预估，来决定申请机器的台数。这块使用了两种方法来预估内存：第一种通过使用java.lang.Runtime.freeMemory()方法来进行粗略的估计，在读取文件到Map前进行调用一次freeMemory方法，然后在数据填充进Map后再调用一次freeMemory，使用第一次的值减去第二次值，就可以得到HashMap近似的内存大小。注意使用这样方法进行预估时，一定要将运行jvm虚拟机-Xms 与-Xmx设置相等。具体代码和运行结果如下：

计算结果HashMap对象占用内存为83M，生成HasMap对象总共占用了约324M内存。

        第二种方法是将生成好的HashMap对象序列化到本地生成文件，查看文件大小近似估计HashMap所占的空间，生成文件大小为95M。

通过上述两种方法测试分析得到，加载10%的数据到HashMap对象时大约需要400M的内存空间，实际保存HashMap需要约100M的内存，依次类推加载所有数据HashMap不超过1.5G，加载HashMap使用内存到的总内存不会超过2G，加上相关性计算及多线程访问需要的内存大约每个实例预估使用4G内存。由于HashMap是线程不安全的，所以每次重新加载数据时需要先临时生成一个HashMap对象将新的数据加载进临时对象中，加载完毕之后将引用对象指向临时生成的HashMap，所以在重新加载对象时使用的内存是实际存储HashMap空间的2倍，也就是一个实例最终需要6G的内存，其中有2G的内存在平时属于空闲状态只有在数据重新加载时才会使用。这样实现很大程度会浪费很多内存空间，增加机器台数，增加了投入成本。实现代码如下：


       因为是HashMap是线程不安全，所以采用了以上实现。如果使用线程安全的ConcurrentHashMap在数据重新加载不需要以上操作节省一个Map存储的内存。使用同样代码对ConcurrentHashMap进行测试，得到ConcurrentHashMap存储所占用的内存约为84M，生成的序列化文件大小为95.3M与HashMap占用内存空间基本一致。现在唯一的问题是确定ConcurrentHashMap读取效率，是否能满足要求，网上查找资料时发现没有比较HashMap和ConcurrentHashMap在多线程下get操作的耗时对比，所以做了以下实验。

三、HashMap与ConcurrentHashMap多线程get操作对比

测试环境

CPU：Intel(R) Xeon(R)CPU E5-2620 0 @ 2.00GHz， 2个物理cpu，每个cpu包含6核心，每个核心4个线程

Jdk1.7版本：jdk1.7.0_80

Jdk1.6版本：jdk1.6.0_45

测试方法

       使用相同的词向量文件分别构造HashMap与ConcurrentHashMap，分别使用1个，12个，24个，48个线程，每个线程循环进行1000000次的get操作达到模拟高并发下的查询，记录测试时间；同样的程序使用jdk1.6与jdk1.7分别进行测试比较耗时。测试代码如下：

测试结果

测试结果如下表所示（每个线程请求1000000次）：

 

jdk1.7

jdk1.6

线程数

HashMap

ConcurrentHashMap

HashMap

ConcurrentHashMap

1

42ms

48ms

46ms

62ms

12

52ms

62ms

62ms

76ms

24

70ms

84ms

83ms

96ms

48

137ms

159ms

139ms

174ms


      使用jdk1.7测试结果来看ConcurrentHashMap比HashMap慢20%， HashMap的get操作需要42ns,ConcurrentHashMap的get操作需要48ns。从jdk两个版本对比来看，jdk1.7比jdk1.6大约快20%左右。从测试结果来看，使用ConcurrentHashMap代替HashMap完全没有问题。

结果分析

      ConcurrenHashMap使用了锁分段技术，将Hash表默认分为16个段（桶），每一个段上加一把锁，如果一个段被锁不会影响其他段的线程访问。ConcurrenHashMap 具体是由Segment数组和HashEntry数组构成的。每个Segment都可以理解为是一个HashTable,Segment包含一个HashEntry数组，HashEntry是一个链表结构，每一个Segment守护一个HashEntry数组，要对HashEntry数组操作时必须首先取得Segment的锁，才能更改HashEntry数组中的数据。读取数据是先需要找到数据所在的Segment，然后再在HashEntry数组中找到具体的HashEntry对象，然后从头开始访问链表，找到相同key的返回该对象的值，找不到查next对象的key值是否相同，一直查询到链表结束。从Jdk1.7 ConcurrentHashMap get方法源码可以看出CocurrentHashMap比HashMap进行get操作时，多进行了一次Hash来得到Segment，得到Segment后的操作与HashMap的get方法基本一致，通过一次hash找到HashEntry在数组中的位置，然后从头遍历该链表。CocurrentHashMap在取得Segment和HashEntry时使用了sun.misc.Unsafe类中提供的方法，Unsafe类提供的硬件级别的原子操作，调用操作系统底层提高性能。jdk1.7 CocurrentHashMap与jdk1.6的访问速度差异主要在于，jdk1.6如果在HashEntry中找多对用的key的值，如果值为null会加锁再读一次，而jdk1.7大量使用了Unsafe类提供的方法来提高性能。jdk1.7 CocurrentHashMap与jdk1.6的访问速度差异主要在于，jdk1.6如果在HashEntry中找多对用的key的值，如果值为null会加锁再读一次，而jdk1.7大量使用了Unsafe类提供的方法来提高性能。

参考资料：

http://ifeve.com/sun-misc-unsafe/

http://www.blogjava.net/stevenjohn/archive/2015/03/15/423475.html

http://www.infoq.com/cn/articles/ConcurrentHashMap

http://www.cnblogs.com/ITtangtang/p/3948786.html


ConcurrentHashMap中有十个提升性能的细节，你都知道吗？
DD_Dddd的博客
04-12 7588
历史文章推荐： HashMap面试，看这一篇就够了 七种方式教你在SpringBoot初始化时搞点事情 Java序列化的这三个坑千万要小心 Java中七个潜在的内存泄露风险，你知道几个？ JDK 16新特性一览 啥？用了并行流还更慢了 InnoDB自增原理都搞不清楚，还怎么CRUD？ 一些题外话 前一篇文章我们对HashMap的实现做了详细的解析和总结，这篇文章继续剖析一下ConcurrentHashMap的实现。由于ConcurrentHashMap的内容比较多，而且Java 7和Java 8两.
JVM成长之路,记录一次内存溢出导致频繁FGC的问题排查及解决
coderlaw's study
08-04 1万+
现象： 现象截图： 内存： 命令：jmap -heap30069 GC截图： FGC 次数 19529 次！！！何等的恐怖！！！！！ 命令： jstat -gcutil 30069 1000 现象描述： Node模块启动后收到请求却未能响应。 一直在频繁的FGC。新生代内
J.U.C 之 Java并发容器：ConcurrentHashMap 万字详解
最新发布
油墨香^-^的博客
10-30 821
ConcurrentHashMap是Java并发包中线程安全且高效的HashMap实现，在保证线程安全的同时提供更好的并发性能。JDK1.7采用分段锁机制，而1.8重构为Node数组+链表/红黑树结构，使用CAS+synchronized实现细粒度锁。核心方法如put通过CAS和同步块确保线程安全，get方法无锁读取。通过扩容机制和红黑树转换优化性能。相比Hashtable和同步Map，ConcurrentHashMap具有桶级别锁、高并发性能和弱一致性迭代器等优势。使用时需注意复合操作问题，建议使用原子方
【Java进阶营】虚拟机研究系列-Java各种类型对象占用内存情况分析（下）
zihong523的博客
04-23 476
前提回顾 建议大家从[【Java技术专题-JVM研究系列（39）Java各种类型对象占用内存情况分析（上）】]开始学习比较好，这样子会有一个承接和过度。根据前面的学习的内存占用计算规则，可以计算出一个对象在内存中的占用空间大小情况，下面举例分析下Java中的Enum, ArrayList及HashMap的内存占用情况，读者可以仿照分析计算过程来计算其他数据结构的内存占用情况。 注： 下面的分析计算基于HotSpot Jvm, JDK1.8, 64位机器，开启指针压缩。。 对象头 这里只关注其内存占用
JDK8的ConcurrentHashMap也会造成CPU 100%
03-20 317
转载：不止 JDK7 的 HashMap ，JDK8 的 ConcurrentHashMap 也会造成 CPU 100%？原因与解决~ 现象 大家可能都听过JDK7中的HashMap在多线程环境下可能造成CPU 100%的现象，这个由于在扩容的时候put时产生了死链，由此会在get时造成了CPU 100%。这个问题在JDK8中的HashMap获得了解决。其实JDK7中的HashMap...
ConcurrentHashMap与HashMap性能对比
自律使我自由
02-12 3671
ConcurrentHashMap与HashMap对比
HashMap/ConcurrentHashMap在单线程模式下的性能比较
明月专栏
08-20 7385
起源 阅读源码发现jdk8中ConcurrentHashMap是基于synchronized来加锁实现多线程安全的，但是实现方式上与早期的HashTable又有了很大的区别，虽然都是使用synchronized来加锁，但是锁的粒度不一样，大致可以作如下理解： HashTable JDK1.0版本开始提供，为了保证线程安全，内部使用了1把锁，读读、读写操作均会锁竞争 HashTable这种键值...
Java 中 HashMap 和 ConcurrentHashMap 核心原理解析
持续分享有趣的技术干货
08-19 882
在现代软件开发中，数据的存储和检索是核心操作之一。高效的数据结构可以大大提高程序的运行效率，减少内存占用，提升用户体验。Java 作为一种广泛应用的编程语言，提供了多种数据结构来满足不同的需求，其中 HashMap 和 ConcurrentHashMap 是常用的键值对存储结构。本文深入探讨了 Java 中 HashMap 和 ConcurrentHashMap 的核心原理。HashMap 采用数组 + 链表 / 红黑树的存储结构，通过哈希函数将键映射到数组的索引位置，当负载因子达到一定值时会进行扩容操作。
面试题总结——HashMap与ConcurrentHashMap
xiaoaxiao
10-16 1242
面试题总结——HashMap相关问题   1、HashXXX(HashSet,HashMap)和TreeXXX(TreeSet,TreeMap)的区别？   ①底层实现：HashXXX底层基于哈希表+红黑树；TreeXXX底层基于红黑树   ②元素要求：HashXXX是无序存储，允许存放null(Set是key，Map是key+value)；TreeXXX是有序存储（与比较器有关），不允许存放...
精选资源
HashMap与ConcurrentHashMap面试要点.pdf
05-19
Node数组的结构与HashMap中的数组类似，但ConcurrentHashMap对数组的每个节点Node进行了CAS操作来保证并发时节点的安全更新。 ConcurrentHashMap的节点Node在冲突比较小的情况下以链表形式存储，当冲突较大时，链表...
HashMap与ConcurrentHashMap的性能比较与优化
介绍HashMap和ConcurrentHashMap #### 1.1 HashMap的基本结构和特性 HashMap是Java集合框架中常用的数据结构之一，它基于哈希表实现。在HashMap中，数据以键值对的形式存储，其中每个键都唯一，并且可以使用键快速...
【Java基础】HashMap和ConcurrentHashMap详细笔记
锦年的博客
10-30 3272
一、HashMap 集合简介二、HashMap 集合底层的数据结构2.1 存储数据的过程2.3 面试题三、HashMap继承关系四、HashMap 集合类的成员4.1 成员变量4.1.1 serialVersionUID4.1.2 DEFAULT_INITIAL_CAPACITY4.1.3 DEFAULT_LOAD_FACTOR4.1.4 MAXIMUM_CAPACITY4.1.5 TREEIFY_THRESHOLD4.1.6 UNTREEIFY_THRESHOLD4.1.7 MIN_TREEIFY_CA.
ConcurrentHashMap内存溢出问题
weixin_30748995的博客
05-02 4463
写在前面 　　上周，同事写了一段ConcurrentHashMap的测试代码，说往map里放了32个元素就内存溢出了，我大致看了一下他的代码及运行的jvm参数，觉得很奇怪，于是就自己捣鼓了一下。首先上一段代码： public class MapTest { public static void main(String[] args) { System.out...
ConcurrentHashMap 和 HashMap 的区别及性能比较
weixin_54563083的博客
11-21 770
在 Java 中，和HashMap是两种常见的Map实现。尤其在多线程环境下，它们在设计和行为上存在一些关键的区别。在本文中，我们将深入探讨这两者之间的主要区别，并通过简单的代码示例演示它们的使用。
java的ConcurrentHashMap太吃内存了啊
03-15 539
[code="java"] public class BattleTest { static int num=1_000_000; @Test public void testHashMap() throws Exception{ List list=new ArrayList(num); for (int i = 0; i < num; i++) { Map p...
ConcurrentHashMap与HashMap的不同，以及二者的性能测试比较
keke_Xin的专栏
02-21 2155
好像今天没有什么源码读，那么就来看看java的这两种HashMap有啥不一样的地方吧，在这之前先普及一下HashMap的一些基本知识： 　　（1）放入HashMap的元素是key-value对。 　　（2）底层说白了就是以前数据结构课程讲过的散列结构。 　　（3）要将元素放入到hashmap中，那么key的类型必须要实现实现hashcode方法，默认这个方法是根据对象的地址来计算的，具体我...
记一个内存泄漏问题：Query Plan Cache BoundedConcurrentHashMap占用堆内存
yogima的博客
05-18 4383
原因是hibernate会缓存sql语句以减少重复编译，便于直接命中提高效率。这个缓存默认最大值为2G，且在使用in时，只要in后面的参数有任何一个不一样的，就会视为不同的语句而保存下来。 解决这个问题可以将缓存最大值改小。 我看大家都是这样写的： spring: jpa: properties: hibernate: query: plan_cache_max_size: 64 plan_parameter_metadata_
ConcurrentHashMap性能测试
software_test010的博客
06-14 492
今天我特意来测试一下java.util.concurrent.ConcurrentHashMap的查询性能，其他增改的功能暂时不做测试了。关于另外一个可能的原因java.util.concurrent.atomic.AtomicLong，我们下期再测。有兴趣的可以先看看我之前对于更强大的多线程计数器java.util.concurrent.atomic.LongAdder的性能测试：性能测试中的LongAdder。下面是之前遇到两种不同类型的对象池的性能测试文章：通用池化框架GenericObjectPoo
面试被问到 ConcurrentHashMap答不出 ，看这一篇就够了！
热门推荐
Java烂猪皮
02-04 3万+
本文汇总了常考的 ConcurrentHashMap 面试题，面试 ConcurrentHashMap，看这一篇就够了！为帮助大家高效复习，专门用”★ “表示面试中出现的频率，”★ “越多，代表越高频！ 实现原理 ConcurrentHashMap 的实现原理是什么？ ★★★★★ ConcurrentHashMap 在 JDK1.7 和 JDK1.8 的实现方式是不同的。 先来看下JDK1.7 JDK1.7 中的 ConcurrentHashMap 是由Segment数组结构和Has...
说一下Hashmap和concurrentHashMap，介绍1.8之后就行。concurrentHashMap是怎么控制并发的？
07-06
在 Java 8 及之后版本中，`HashMap` 和 `ConcurrentHashMap` 是两种常用的哈希表实现，但它们的并发控制机制和设计目标有显著差异。以下是它们的详细对比，重点分析 `ConcurrentHashMap` 如何控制并发。 --- ## **1. HashMap 的核心特性（Java 8+）** ### **1.1 数据结构** - **数组 + 链表 + 红黑树**： - 哈希表的主结构是一个**节点数组**（`Node<K,V>[] table`）。 - 每个数组槽位（Bucket）是一个**单向链表**，当链表长度超过阈值（`TREEIFY_THRESHOLD = 8`）时，会转换为**红黑树**（提升查询效率）。 - 红黑树节点为 `TreeNode`，继承自 `Node`。 ### **1.2 非线程安全** - `HashMap` 是**非线程安全**的，多线程并发操作可能导致： - **数据不一致**：如 `put` 和 `get` 同时操作时，可能读取到部分更新的数据。 - **死循环**：在扩容时（`resize()`），多线程可能形成链表环，导致 `get` 操作陷入死循环（Java 8 之前更常见）。 - **丢失更新**：两个线程同时 `put` 相同键，可能导致一个线程的写入被覆盖。 ### **1.3 Java 8 的优化** - **红黑树优化**：链表长度超过 8 时转为红黑树，查询时间从 O(n) 降到 O(log n)。 - **扩容优化**：使用**异步扩容**（转移数据时允许并发读写），减少锁竞争。 - **无锁读取**：`get()` 操作无需加锁，通过 `volatile` 变量保证可见性。 --- ## **2. ConcurrentHashMap 的核心特性（Java 8+）** ### **2.1 设计目标** - **线程安全**：支持高并发读写，避免全局锁。 - **高性能**：通过**分段锁（Java 7）**或**CAS + synchronized（Java 8）**减少锁粒度。 - **弱一致性**：迭代器反映的是创建时的状态，不保证实时性（避免强一致性带来的性能开销）。 ### **2.2 数据结构（Java 8+）** - **数组 + 链表 + 红黑树**： - 与 `HashMap` 类似，但每个槽位（Bucket）的锁粒度更细。 - 节点类型包括： - `Node`：普通链表节点。 - `TreeNode`：红黑树节点。 - `ForwardingNode`：扩容时使用的占位节点。 - `ReservedNode`：保留节点（用于未来扩展）。 ### **2.3 并发控制机制** #### **2.3.1 CAS + synchronized 锁** - **写操作（`put`、`remove`）**： 1. **定位槽位**：通过哈希计算确定数组索引。 2. **CAS 尝试插入**：如果槽位为空，尝试用 CAS 插入新节点。 3. **synchronized 锁槽位**：如果 CAS 失败（槽位非空），则对槽位的头节点加 `synchronized` 锁，再操作链表或树。 - **示例代码**： ```java final V putVal(K key, V value, boolean onlyIfAbsent) { if (key == null || value == null) throw new NullPointerException(); int hash = spread(key.hashCode()); // 扰动函数，减少哈希冲突 for (Node<K,V>[] tab = table;;) { Node<K,V> f; int n, i, fh; if (tab == null || (n = tab.length) == 0) tab = initTable(); // 初始化表 else if ((f = tabAt(tab, i = (n - 1) & hash)) == null) { if (casTabAt(tab, i, null, new Node<>(hash, key, value))) break; // CAS 插入新节点 } else if ((fh = f.hash) == MOVED) // 扩容中 tab = helpTransfer(tab, f); else { V oldVal = null; synchronized (f) { // 对槽位头节点加锁 if (tabAt(tab, i) == f) { // 链表或树的操作 if (fh >= 0) { // 链表 // 遍历链表，更新或插入 } else if (f instanceof TreeNode) { // 红黑树 // 树的操作 } } } if (oldVal != null) return oldVal; break; } } addCount(1L, binCount); // 更新元素计数 return null; } ``` #### **2.3.2 扩容优化** - **多线程协助扩容**： - 当某个线程发现表正在扩容（`ForwardingNode`），会通过 `helpTransfer()` 协助扩容。 - 扩容时，原表分成多个段（默认 16），每个线程负责一部分数据的转移。 - **扩容过程**： 1. 创建新数组（大小为原数组的 2 倍）。 2. 将原数组的槽位标记为 `ForwardingNode`（包含新数组的引用）。 3. 线程在 `put` 或 `get` 时，如果遇到 `ForwardingNode`，会帮助转移数据到新数组。 #### **2.3.3 读操作（`get`）** - **无锁读取**： - `get()` 操作无需加锁，直接通过哈希定位槽位。 - 如果槽位是 `ForwardingNode`，则从新数组中读取。 - 通过 `volatile` 变量保证节点的可见性。 #### **2.3.4 计数优化** - **LongAdder 机制**： - `size()` 操作通过维护多个 `CounterCell` 减少竞争。 - 更新时随机选择一个 `CounterCell` 进行 CAS 操作，统计时累加所有 `CounterCell` 的值。 --- ## **3. ConcurrentHashMap 的并发控制细节** ### **3.1 锁粒度** - **槽位锁（Bucket Lock）**： - Java 8 之前使用**分段锁（Segment）**，每个 Segment 是一个独立的哈希表，锁粒度为 Segment。 - Java 8 之后改为**槽位锁**，每个槽位的头节点加 `synchronized` 锁，锁粒度更细（通常 16-64 个槽位共享一个锁的时代已过去）。 ### **3.2 CAS 操作** - **无竞争优化**： - 如果槽位为空，直接通过 CAS 插入新节点，避免锁开销。 - 例如 `tabAt()` 和 `casTabAt()` 是基于 `Unsafe` 的原子操作。 ### **3.3 内存可见性** - **volatile 变量**： - 节点的 `val` 和 `next` 字段用 `volatile` 修饰，保证多线程下的可见性。 - 例如： ```java static class Node<K,V> implements Map.Entry<K,V> { final int hash; final K key; volatile V val; // volatile 保证可见性 volatile Node<K,V> next; // volatile 保证链表遍历的正确性 // ... } ``` ### **3.4 失败重试** - **自旋优化**： - 在 `put` 或 `remove` 时，如果 CAS 失败或锁竞争激烈，会通过自旋重试（`for (;;)` 循环）。 --- ## **4. ConcurrentHashMap 的性能对比** | **场景** | **HashMap** | **ConcurrentHashMap** | |------------------------|---------------------------|----------------------------------| | **单线程读** | O(1)（无锁） | O(1)（无锁） | | **单线程写** | O(1) | O(1)（CAS + 槽位锁） | | **多线程读** | 可能数据不一致 | 无锁，线程安全 | | **多线程写** | 可能死循环/丢失更新 | 槽位锁，高并发 | | **扩容** | 阻塞所有操作 | 多线程协助扩容，减少停顿时间 | | **内存占用** | 更低（无额外同步结构） | 更高（`volatile`、`CounterCell`）| --- ## **5. 实际应用场景** ### **5.1 ConcurrentHashMap 的适用场景** - **高并发读写**：如缓存、计数器、会话管理。 - **弱一致性要求**：如统计指标、日志聚合。 - **避免全局锁**：需要比 `Hashtable` 或 `Collections.synchronizedMap` 更高的并发性能。 ### **5.2 HashMap 的适用场景** - **单线程环境**：如局部变量、单线程应用。 - **读多写少**：且对线程安全无要求。 - **内存敏感**：需要最小化哈希表开销。 --- ## **6. 总结** | **关键点** | **HashMap** | **ConcurrentHashMap** | |----------------------|---------------------------------------|--------------------------------------| | **线程安全** | 非线程安全 | 线程安全 | | **并发控制** | 无 | CAS + 槽位锁 + 协助扩容 | | **数据结构** | 数组 + 链表 + 红黑树 | 数组 + 链表 + 红黑树 | | **读性能** | O(1)（无锁） | O(1)（无锁） | | **写性能** | O(1)（非线程安全） | O(1)（CAS + 槽位锁） | | **扩容** | 阻塞所有操作 | 多线程协助扩容 | | **内存开销** | 更低 | 更高（`volatile`、同步结构） | **最佳实践**： 1. **优先使用 `ConcurrentHashMap`**：除非明确知道是单线程环境，否则避免使用 `HashMap` 的多线程场景。 2. **避免频繁扩容**：预估数据量，初始化时指定合适容量（`new ConcurrentHashMap<>(1024)`）。 3. **合理选择并发级别**：Java 8 的 `ConcurrentHashMap` 已自动优化锁粒度，无需手动配置。 --- ### **
评论 4
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值