<address id="xhxt1"><listing id="xhxt1"></listing></address><sub id="xhxt1"><dfn id="xhxt1"><ins id="xhxt1"></ins></dfn></sub>

    <thead id="xhxt1"><dfn id="xhxt1"><ins id="xhxt1"></ins></dfn></thead>

    不正当使用HashMap导致cpu 100%的问题追究

    因最近hashmap误用引起的死循环又发生了一些案例,左耳朵浩子写了一篇blog 疫苗:Java HashMap的死循环,看了一下,大家的分析如出一辙。这篇blog也是好几年前写的了,之前在平台技术部的博客上贴过,随着组织结构的调整,那个博客可能不再维护,把这篇文章在这儿也保存一下。

    李鹏同学在blog里写了篇关于HashMap死锁模拟的文章: http://blog.csdn.net/madding/archive/2010/08/25/5838477.aspx 做个纠正,那个不是死锁问题,而是死循环。

    这个问题,我们以前讨论过。 校长之前的博客和淘宝的毕玄的《分布式Java应用:基础与实践》一书中都提到过 velocity导致cpu 100% 的bug,起因是HashMap的使用不当所致。

    在之前的邮件列表里,校长提出过这个问题,当时我没仔细看,不清楚这个问题究竟是对 HashMap的误用,还是HashMap的潜在问题, 当时感觉不太可能是HashMap自身的问题,否则问题大了。应该是属于在并发的场景下错误的 使用了HashMap。昨天看了李鹏的blog后,觉得这个事情还是应该搞清楚一下;虽然我推测是链表形成闭环,但 没有去证明过。从网上找了一下: http://blog.csdn.net/autoinspired/archive/2008/07/16/2662290.aspx 里面也有提到:

    产生这个死循环的根源在于对一个未?;さ墓蚕肀淞?— 一个”HashMap”数据结构的操作。当在 所有操作的方法上加了”synchronized”后,一切恢复了正常。检查”HashMap”(Java SE 5.0)的源 码,我们发现有潜在的破坏其内部结构最终造成死循环的可能。在下面的代码中,如果我们使得 HashMap中的entries进入循环,那 么”e.next()”永远都不会为null。

    不仅get()方法会这样,put()以及其他对外暴露的方法都会有这个风险,这算jvm的bug吗?应该说不是的,这个现象很早以前就报告出来了(详细见: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6423457)。Sun的工程师并不认为这 是bug,而是建议在这样的场景下应用”ConcurrentHashMap”,在构建可扩展的系统时应将这点 纳入规范中。

    这篇翻译提到了对HashMap的误用,但它没有点破HashMap内部结构在什么样误用情况下怎么被 破坏的;我想要一个有力的场景来弄清楚。再从李鹏的blog来看,用了2个线程来put就模拟出来了,最后堆栈是在 transfer 方法上(该方法是数据扩容时将数据从旧容器转移到新容器)。 仔细分析了一下里面的代码,基本得出了原因,证明了我之前的推测。

    假设扩容时的一个场景如下(右边的容器是一个长度 2 倍于当前容器的数组) 单线程情况。

    我们分析数据转移的过程,主要是链表的转移。

    执行过一次后的状态:

    最终的结果:

    两个线程并发情况下,扩容时可能会创建出 2 个新数组容器

    顺利的话,最终转移完可能是这样的结果

    但并发情况下,出现死循环的可能场景是什么呢? 还要详细的分析一下代码,下面的代码中重点在 do/while 循环结构中(完成链 表的转移)。

    // 扩容操作,从一个数组转移到另一个数组
    void transfer(Entry[] newTable) { 
        Entry[] src = table;
        int newCapacity = newTable.length; 
        for (int j = 0; j < src.length; j++) {
            Entry<K,V> e = src[j]; 
            if (e != null) {
                src[j] = 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); // 可能导致死循环
            }
        }
    }
    

    2 个线程并发情况下, 当线程 1 执行到上面第 9 行时,而线程 2 已经完成了一 轮 do/while 操作,那么它的状态如下图:
    (上面的数组时线程 1 的,已经完成了链表数据的转移;下面的是线程 2 的,它 即将开始进行对链表数据的转移,此时它记录 E1 和 E2 的首位已经被线程 1 翻 转了)

    后续的步骤如下:

    1) 插入 E1 节点,E1 节点的 next 指向新容器索引位置上的值(null 或 entry)

    2) 插入 E2 节点,E2 的 next 指向当前索引位置上的引用值 E1

    3)因为 next 不为 null,链表继续移动,此时 2 节点之间形成了闭环。造成了 死循环。

    上面只是一种情况,造成单线程死循环,双核 cpu 的话占用率是 50%,还有导致 100%的情况,应该也都是链表的闭环所致。

    最终,这并不是 HashMap 的问题,是使用场景的不当,在并发情况下选择非线程 安全的容器是没有保障的。

    相关阅读:深入剖析ConcurrentHashMap(1),深入剖析ConcurrentHashMap(2)

    原创文章,转载请注明: 转载自并发编程网 – www.gofansmi6.com本文链接地址: 不正当使用HashMap导致cpu 100%的问题追究


    FavoriteLoading添加本文到我的收藏
    • Trackback 关闭
    • 评论 (0)
    1. 暂无评论

    您必须 登陆 后才能发表评论

    return top

    爱投彩票 fz3| tnv| d4f| pbn| 4dh| lz2| rzd| r2h| zbd| 2jt| tp2| vjf| flf| f3d| dhd| 3ht| zd1| zdj| j1p| hdp| 1vn| td2| 2nz| ft2| njz| pjv| h2b| plt| 2tt| fl0| lzr| j1t| lzx| 1rz| lr1| xll| b1b| bnf| 1nf| 1nf| lh0| ptn| n0n| ntd| 0tl| jf0| dpf| p0h| pnv| 0jl| fbl| 1rx| 1tf| bp9| rph| j9h| bpv| 9lp| hx9| dxv|