【HashMap并发修改异常】

关注

原创最新推荐文章于 2026-03-02 06:29:51 发布 2.8k 阅读 AI 写同款· GEO 优化 ›

遍历HashMap时增删导致报错问题背景在和朋友的一次交谈中，朋友遇到了这样一个问题：在遍历map时，做了一步remove操作，然后就发生了ConcurrentModificationException异常。由此我点进源码探究了一番。 JDK版本：1.8 探究点进HashMap源码发现，在每次循环结束前，会校验一下modCount的值，如果modCount变了，就会抛出ConcurrentModificationException异常。 @Override public void forEach(BiConsumer<? 阅读详情

我是廖志伟，一名Java开发工程师、幕后大佬社区创始人、Java领域优质创作者、优快云博客专家。拥有多年一线研发经验，研究过各种常见框架及中间件的底层源码，对于大型分布式、微服务、三高架构（高性能、高并发、高可用）有过实践架构经验。

博主：java_wxid
社区：幕后大佬

文章目录

本文的大概内容：

HashMap并发修改异常

HashMap实际使用过程中会出现一些线程安全问题，在JDK1.7中，当并发执行扩容操作时会造成环形链和数据丢失的情况，开多个线程不断进行put操作，rehash的时候，旧链表迁移新链表的时候，如果在新表的数组索引位置相同，则链表元素会倒置(就是因为头插)所以最后的结果打乱了插入的顺序，就可能发生环形链和数据丢失的问题，引起死循环，导致CPU利用率接近100%。在jdk1.8中对HashMap进行了优化，发生hash碰撞，不再采用头插法方式，而是直接插入链表尾部，因此不会出现环形链表的情况，但是在多线程环境下，会发生数据覆盖的情况，如果没有hash碰撞的时候，它会直接插入元素。如果线程A和线程B同时进行put操作，刚好这两条不同的数据hash值一样，并且该位置数据为null，线程A进入后还未进行数据插入时挂起，而线程B正常执行，从而正常插入数据，然后线程A获取CPU时间片，此时线程A不用再进行hash判断了，线程A会把线程B插入的数据给覆盖，导致数据发生覆盖的情况，发生线程不安全。可参考【HashMap扩容机制】

实际的故障现象：java.util.ConcurrentModificationException并发修改异常。导致原因：并发争取修改导致，一个线程正在写，一个线程过来争抢，导致线程写的过程被其他线程打断，导致数据不一致。

使用HashTable

HashTable是线程安全的，只不过实现代价却太大了，简单粗暴，get/put所有相关操作都是synchronized的，这相当于给整个哈希表加了一把大锁。多线程访问时候，只要有一个线程访问或操作该对象，那其他线程只能阻塞，相当于将所有的操作串行化，在竞争激烈的并发场景中性能就会非常差。

使用工具类

线程同步：Map<String,String> hashMap = Collections.synchronizedMap(new HashMap<>());

和Hashtable一样，实现上在操作HashMap时自动添加了synchronized来实现线程同步，都对整个map进行同步，在性能以及安全性方面不如ConcurrentHashMap。

使用写时复制(CopyOnWrite)

往一个容器里面加元素的时候，不直接往当前容器添加，而是先将当前容器的元素复制出来放到一个新的容器中，然后新的元素添加元素，添加完之后，再将原来容器的引用指向新的容器，这样就可以对它进行并发的读，不需要加锁，因为当前容器不添加任何元素。利用了读写分离的思想，读和写是不同的容器。

会有内存占用问题，在复制的时候只是复制容器里的引用，只是在写的时候会创建新对象添加到新容器里，而旧容器的对象还在使用，所以有两份对象内存。

会有数据一致性问题，CopyOnWrite容器只能保证数据的最终一致性，不能保证数据的实时一致性。

使用ConcurrentHashMap

为了应对hashmap在并发环境下不安全问题可以使用，ConcurrentHashMap大量的利用了volatile，CAS等技术来减少锁竞争对于性能的影响。在JDK1.7版本中ConcurrentHashMap避免了对全局加锁，改成了局部加锁（分段锁），分段锁技术，将数据分成一段一段的存储，然后给每一段数据配一把锁，当一个线程占用锁访问其中一个段数据的时候，其他段的数据也能被其他线程访问，能够实现真正的并发访问。不过这种结构的带来的副作用是Hash的过程要比普通的HashMap要长。

所以在JDK1.8版本中CurrentHashMap内部中的value使用volatile修饰，保证并发的可见性以及禁止指令重排，只不过volatile不保证原子性，使用为了确保原子性，采用CAS（比较交换）这种乐观锁来解决。

fast-fail机制

在系统设计中，快速失效系统一种可以立即报告任何可能表明故障的情况的系统。快速失效系统通常设计用于停止正常操作，而不是试图继续可能存在缺陷的过程。这种设计通常会在操作中的多个点检查系统的状态，因此可以及早检测到任何故障。快速失败模块的职责是检测错误，然后让系统的下一个最高级别处理错误。其实就是在做系统设计的时候先考虑异常情况，一旦发生异常，直接停止并上报。

以下的代码是一个对两个整数做除法的方法，在fast_fail_method方法中，我们对被除数做了个简单的检查，如果其值为0，那么就直接抛出一个异常，并明确提示异常原因。这其实就是fail-fast理念的实际应用。

public int fast_fail_method(int arg1,int arg2){
    if(arg2 == 0){
        throw new RuntimeException("can't be zero");
    }
    return arg1/arg2;
}

在Java集合类中很多地方都用到了该机制进行设计，一旦使用不当，触发fail-fast机制设计的代码，就会发生非预期情况。我们通常说的Java中的fail-fast机制，默认指的是Java集合的一种错误检测机制。当多个线程对部分集合进行结构上的改变的操作时，有可能会触发该机制时，之后就会抛出并发修改异常ConcurrentModificationException。当然如果不在多线程环境下，如果在foreach遍历的时候使用add/remove方法，也可能会抛出该异常。

之所以会抛出ConcurrentModificationException异常，是因为我们的代码中使用了增强for循环，而在增强for循环中，集合遍历是通过iterator进行的，但是元素的add/remove却是直接使用的集合类自己的方法。这就导致iterator在遍历的时候，会发现有一个元素在自己不知不觉的情况下就被删除/添加了，就会抛出一个异常，用来提示可能发生了并发修改！所以，在使用Java的集合类的时候，如果发生ConcurrentModificationException，优先考虑fail-fast有关的情况，实际上这可能并没有真的发生并发，只是Iterator使用了fail-fast的保护机制，只要他发现有某一次修改是未经过自己进行的，那么就会抛出异常。

总结

以上就是今天要讲的内容，还希望各位读者大大能够在评论区积极参与讨论，给文章提出一些宝贵的意见或者建议，合理的内容，我会采纳更新博文，重新分享给大家。

提示：以下都是资源分享，求个一键三连。

博客封面

首先我要说声抱歉，作为一个学习的平台，封面引人注目是营销策略，大家不用太过在意哈，专注博客内容本身即可。当然有同学惦记着我博客的封面，这里也分享出来给大家。
点击：博客封面
提取码：2021

面试资料

福利大放送，我就求个一键三连，拜托了，这对我真的很重要。
点击：面试资料
提取码：2021

200套PPT模板

福利大放送，我就求个一键三连，拜托了，这对我真的很重要。
点击：200套PPT模板
提取码：2021

提问的智慧

福利大放送，我就求个一键三连，拜托了，这对我真的很重要。
点击：提问的智慧
提取码：2021

一键三连

感谢大家的支持，用心写博文分享给大家，你的支持（点赞、收藏、关注）是对我创作的最大帮助。
微信公众号：南北踏尘
主页地址：java_wxid
社区地址：幕后大佬

给读者大大的话

我本身是一个很普通的程序员，放在人堆里，除了与生俱来的盛世美颜、所剩不多的发量，就剩下180的大高个了。就是我这样的一个人，默默坚持写博文也有好多年了，有句老话说的好，牛逼之前都是傻逼式的坚持。希望自己可以通过大量的作品，时间的积累，个人魅力、运气和时机，可以打造属于自己的技术影响力。同时也希望自己可以成为一个懂技术，懂业务，懂管理的综合型人才，作为项目架构路线的总设计师，掌控全局的团队大脑，技术团队中的绝对核心是我未来几年不断前进的目标。