HashMap在多线程并发情况下不安全的原因

最新推荐文章于 2024-11-15 21:08:14 发布
原创 最新推荐文章于 2024-11-15 21:08:14 发布 · 1.1k 阅读 · 1 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#java #hashmap #多线程

本文深入探讨了HashMap在多线程环境下数据丢失的原因，以及在JDK1.7和1.8中并发操作可能引发的数据丢失和死循环问题。

为什么HashMap不是线程安全的

源码阅读详见 https://blog.youkuaiyun.com/leonliu06/article/details/107274223
  • 线程T1和T2同时对一个HashMap进行put操作，如产生hash碰撞，正常情况下，会形成链表，并发情况下，有可能T2线程会覆盖T1线程put的元素。
  • 线程T1和T2同时对一个HashMap进行resize操作，因jdk1.7中，扩容时，移动元素生成新链表是按头插法进行的，可能出现循环链表，使得get一个不存在的元素，且该元素索引位置在循环链表位置时，造成对环形链表的死循环遍历，在jdk1.8中不会。
  • 所以，HashMap的线程不安全主要体现如下：
    • 在JDK1.7中，当并发执行put操作时，会造成数据丢失，并发扩容操作时会造成死循环的情况。
    • 在JDK1.8中，当并发执行put操作时，也会造成数据丢失，但不会形成环形链表，所以不会出现死循环情况。
HashMap在多线程下不安全问题(JDK1.7)
wanghao112956的博客
09-27 960
本文分析是基于JDK1.7的HashMap 多线程情况下HashMap所带来的问题 多线程put操作后，get操作导致死循环。 多线程put操作，导致元素丢失。 死循环场景重现 public class HashMapTest extends Thread { private static HashMap<Integer, Integer> map = new HashM...
HashMap为什么线程不安全？浅析高并发情况下的HashMap
V_Axis的博客
11-22 1万+
1.Hashmap在插入元素过多的时候需要进行Resize； 2.Hashmap扩容时Resize的ReHash步骤，并发的情况下可能会形成链表环；
【并发】为什么HashMap是线程不安全的？
12-21
目录 1.什么是线程安全性（what） 2.如何分辨一个类是否线程安全？（HOW） 3.为什么hashmap不安全 why 3.1 插入HashMap.put 3.1.1 HashMap 在扩容的时候 3.2 HashMap 在删除数据的时候 0.背景 经常会看到说HashMap是线程不安全的，ConcurrentHashMap是线程安全的等等说法，不禁有个疑问，什么是线程安全？什么样的类是线程安全的？ 1.什么是线程安全性（what） 线程安全定义，最核心是正确性， 正确性：多个线程访问某个类，不管怎么调度这些线程，其代码中不需要额外的同步或协同（synchronized），这个类依然有正确
hashMap线程不安全的原因及表现
热门推荐
WangSai.coo的专栏
04-15 1万+
hashMap出现线程不安全的原因： HashMap的实现里没有锁的机制，因此它是线程不安全的。其实只要有锁的机制，可以通过锁实现线程安全，我们在读写HashMap对象的时候加锁，以保障这个对象的线程安全，但不代表HashMap本身是线程安全的，因为是外力（你自己加的锁）使然。为啥不在HashMap内部加锁让它变成线程安全？这样会增加单线程访问的资源消耗，即使没有多线程访问，也要每次检查、加
HashMap 线程为啥不安全呢?
weixin_43870079的博客
11-26 511
1.jdk1.7中的HashMap 在jdk1.8中对HashMap做了很多优化，这里先分析在jdk1.7中的问题，相信大家都知道在jdk1.7多线程环境下HashMap容易出现死循环，这里我们先用代码来模拟出现死循环的情况： public class HashMapTest { public static void main(String[] args) { HashMapThread thre...
java的hashMap多线程并发情况下扩容产生的死锁问题解决.docx
07-02
在Java的HashMap中，多线程并发环境下的扩容操作可能会引发死锁问题。这主要发生在JDK 1.7版本，因为其扩容机制采用了头插法。以下详细解释这个问题及其解决方案。 首先，HashMap的扩容机制是在容量达到阈值时触发...
HashMap多线程并发情况(JDK1.8)
fumitzuki的博客
09-18 9583
HashMap多线程并发情况(JDK1.8) 很早就知道Hashmap是线程不安全的，并且也看过hashmap的源码，知道他的各个操作的过程，今天来实践下，在多线程的情况下，hashmap的哪些步骤会出问题。 撤销：Ctrl/Command + Z 重做：Ctrl/Command + Y 加粗：Ctrl/Command + Shift + B 斜体：Ctrl/Command + Shift + I...
多线程/高并发下的HashMap
qq_24047659的博客
02-26 3351
  有一定经验的开发者都知道，HashMap是非线程安全的。   在高并发环境下，HashMap可能出现致命问题。 一、Rehash是HashMap在扩容时候的一个步骤           HashMap的【容量】是有限的，当经过多次元素插入，使得HashMap达到一定饱和度时，Key映射index位置发生冲突的几率会逐渐提高。           这时候，HashMap需要扩展它的长度(...
Java基础：为什么hashmap是线程不安全的？
qq_53058639的博客
02-24 5048
HashMap 是线程不安全的主要原因是它的内部结构和操作不是线程安全的。下面是一些导致 HashMap 线程不安全的因素：非同步操作：HashMap 的操作不是线程同步的，也就是说，在多线程环境下同时对 HashMap 进行读写操作可能会导致数据不一致的问题。非原子操作：HashMap 的操作不是原子性的，例如 put() 方法涉及到了多个步骤，包括计算哈希值、查找或插入元素等。如果多个线程同时执行这些操作，就有可能导致数据不一致的情况。
HashMap为什么不是线程安全的？
weixin_41163113的博客
02-03 927
HashMap底层是一个Entry数组，当发生hash冲突的时候，hashmap是采用链表的方式来解决的，在对应的数组位置存放链表的头结点。对链表而言，新加入的节点会从头结点加入。 javadoc中关于hashmap的一段描述如下： 此实现不是同步的。如果多个线程同时访问一个哈希映射，而其中至少一个线程从结构上修改了该映射，则它必须 保持外部同步。（结构上的修改是指添加或删除一个或多个映射关系...
关于如何解决HashMap线程安全问题的介绍
08-22
HashMap为什么是线程不安全的?如何解决HashMap的线程不安全问题?
为什么hashmap不是线程安全的？
stone_tomcate的博客
08-27 317
1.Hashmap在插入元素过多的时候需要进行Resize，Resize的条件是 HashMap.Size >= Capacity * LoadFactor。 2.Hashmap的Resize包含扩容和ReHash两个步骤，ReHash在并发的情况下可能会形成链表环。 ...
HashMap为什么线程不安全
xiashenbao的博客
02-24 369
这里写自定义目录标题HashMap为什么线程不安全新的改变功能快捷键合理的创建标题，有助于目录的生成如何改变文本的样式插入链接与图片如何插入一段漂亮的代码片生成一个适合你的列表创建一个表格设定内容居中、居左、居右SmartyPants创建一个自定义列表如何创建一个注脚注释也是必不可少的KaTeX数学公式新的甘特图功能，丰富你的文章UML 图表FLowchart流程图导出与导入导出导入 HashMap为什么线程不安全 你好！ 这是你第一次使用 Markdown编辑器 所展示的欢迎页。如果你想学习如何使用Mar
HashMap为什么是线程不安全的？
thehateyou的博客
11-15 502
这意味着如果多个线程同时修改 HashMap 的内容，可能会导致数据不一致或并发冲突。
HashMap多线程不安全原因分析
CAT
03-16 1468
在之前准备面试题时，遇到过分析为什么HashMap线程不安全，答案是resize()可能会造成死循环，今天就分析一下resize()这个方法，我主要是靠分析源码解析，如有错误，欢迎指正！ resize()代码： final Node<K,V>[] resize() { Node<K,V>[] oldTab = table; int oldCap = (oldTab == null) ? 0 : oldTab.length;
HashMap原理及线程不安全详解
weixin_34228617的博客
12-29 520
为什么80%的码农都做不了架构师？>>> ...
分析hashmap线程不安全的有原因,以及解决方法
qq_46138725的博客
06-12 1897
为什么HashMap是线程不安全的 总说HashMap是线程不安全的，不安全的，不安全的，那么到底为什么它是线程不安全的呢？要回答这个问题就要先来简单了解一下HashMap源码中的使用的存储结构(这里引用的是Java 8的源码，与7是不一样的)和它的扩容机制。 HashMap的内部存储结构 下面是HashMap使用的存储结构: transient Node<K,V>[] table; static class Node<K,V> implements Map.Entry&lt
阿里面试官：HashMap 为什么是线程不安全的？(2)
2401_84301315的博客
04-30 912
多线程 put 操作后，get 操作导致死循环。多线程 put 非 NULL 元素后，get 操作得到 NULL 值。多线程 put 操作，导致元素丢失。
Java 什么是多线程情况下hashmap不安全
最新发布
06-08
<think>嗯，用户想深入了解Java多线程环境下HashMap线程不安全的原因和替代方案。这个问题在并发编程中很关键，尤其是HashMap在多线程环境中的行为。从系统指令来看，所有技术术语和代码都需要严格用LaTeX标记，并且必须引用站内资料。用户引用的几篇材料详细分析了线程不安全的原理，特别是引用[4]和[5]提到JDK7时代的循环链表问题，引用[3]则指向ConcurrentHashMap解决方案。具体思考点有：JDK7的transfer方法在多线程扩容时会产生循环链表，引用[5]的代码段清楚展示了在e.next操作时可能出现环链。这时候get操作就会CPU飙升。而在JDK8虽然优化为尾插法避免死循环，但仍有数据覆盖问题，如两个线程同时执行put时可能丢失数据。引用[1][2]都指出同步锁方案不可行，因为内置锁会让性能退化成Hashtable级别。替代方案方面需要分层推荐：基础场景用Collections.synchronizedMap，如引用[2]所示；高性能场景必须用ConcurrentHashMap，引用[3]提到它采用分段锁降低冲突。特别要强调Java8的ConcurrentHashMap改用CAS+synchronized，连putVal这样的操作都实现精细化同步。最后要生成延展问题：为什么ConcurrentHashMap放弃分段锁？如何理解Java内存模型对此的影响？并发容器选型标准也应该说明。</think> Java多线程环境下HashMap线程不安全的主要原因在于其非同步设计，以下是具体原因及解决方案： ### 一、线程不安全原因 1. **数据覆盖** 当多个线程同时执行`put()`操作时，若计算出的桶下标相同，会导致后写入的键值对覆盖前一个线程写入的数据。例： ```java // 线程A和B同时执行 map.put(key, valueA); // 线程A map.put(key, valueB); // 线程B // 最终可能只保留valueB ``` 2. **循环链表（JDK7）** 在扩容时执行`transfer()`方法，多线程操作可能导致链表形成闭环（引用[5]）： ```java void transfer(Entry[] newTable) { for (Entry<K,V> e : table) { // 多线程操作此循环 while(null != e) { Entry<K,V> next = e.next; // 线程A在此挂起 e.next = newTable[i]; // 线程B先完成扩容 newTable[i] = e; // 导致线程A恢复后形成闭环 }}} ``` *触发get操作时可能引起CPU 100%* 3. **大小计算错误** 多个线程同时修改`size`字段时，由于非原子操作导致最终值小于实际数量： ```java // 实际执行过程： int tmp = size; // 线程A读取size=5 tmp = tmp + 1; // 线程B同时读取size=5 size = tmp; // 最终size=6而非7 ``` 4. **可见性问题** 未使用`volatile`修饰内部数组，线程修改后其他线程可能不可见（引用[4]）。 ### 二、替代方案 1. **Collections.synchronizedMap** ```java Map<String, String> safeMap = Collections.synchronizedMap(new HashMap<>()); ``` *原理：通过mutex对象锁实现同步（引用[2]）* ```java public V put(K key, V value) { synchronized (mutex) { return m.put(key, value); } } ``` 2. **ConcurrentHashMap（推荐）** ```java Map<String, String> concurrentMap = new ConcurrentHashMap<>(); ``` - JDK7：分段锁（Segment），默认16个锁（引用[3]） - JDK8+：CAS+synchronized优化，锁粒度细化到桶头节点 ```java final V putVal(K key, V value) { if ((f = tabAt(tab, i)) == null) { if (casTabAt(tab, i, null, newNode)) break; // CAS插入 } else { synchronized (f) { // 锁住桶头节点 // 链表/红黑树操作 }}} ``` 3. **HashTable（不推荐）** ```java Map<String, String> table = new Hashtable<>(); ``` *问题：全表锁导致并发性能差* ### 三、选择建议 | 方案 | 锁粒度 | 适用场景 | |---------------------|------------|-----------------------| | `ConcurrentHashMap` | 桶级锁 | 高并发更新场景（推荐） | | `Collections.synchronizedMap` | 全表锁 | 低并发或读多写少场景 | | `HashTable` | 全表锁 | 废弃方案，不推荐使用 | > **关键结论**：HashMap的线程不安全本质源于设计目标（单线程性能优先），需根据并发场景选择替代方案： > - 读多写少：`Collections.synchronizedMap` > - 高并发写：`ConcurrentHashMap`（JDK8+性能最优） > - 完全避免：`Hashtable`等全局锁方案（引用[1][2][3]） ---
评论 1
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
表情包 代码片
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值