【高并發(fā)】你敢信？？HashMap竟然干掉了CPU！！

時間：2020-05-20 00:19:57

關鍵字： CPU HM BSP GE

手機看文章

掃描二維碼
隨時隨地手機看文章

[導讀]? ?? 問題分析 Race Condition（也叫做資源競爭），是多線程編程中比較頭疼的問題。特別是Java多線程模型當中，經(jīng)常會因為多個線程同時訪問相同的共享數(shù)據(jù)，而造成數(shù)據(jù)的不一致性。為了解決這個問題，通常來說需要加上同步標志“synchronized”，來保證數(shù)據(jù)的

【高并發(fā)】你敢信？？HashMap竟然干掉了CPU?。? ><span style=

問題分析

Race Condition（也叫做資源競爭），是多線程編程中比較頭疼的問題。特別是Java多線程模型當中，經(jīng)常會因為多個線程同時訪問相同的共享數(shù)據(jù)，而造成數(shù)據(jù)的不一致性。為了解決這個問題，通常來說需要加上同步標志“synchronized”，來保證數(shù)據(jù)的串行訪問。但是“synchronized”是個性能殺手，過多的使用會導致性能下降，特別是擴展性下降，使得你的系統(tǒng)不能使用多個CPU資源。

那是一個電商系統(tǒng)，運行在我們的T2000服務器（8核32線程）上。當500個并發(fā)用戶的時候居然把所有的CPU都壓得滿滿的（90%以上的忙碌，甚至達到了100%）。這是很少有的現(xiàn)象，在我測試的所有項目中很少有擴展性這么好的系統(tǒng)能把T2000的32個線程都占滿的。我狠狠的夸了他們的應用。話音沒落，卻發(fā)現(xiàn)測試結果很差，平均響應時間很長。不可能呀，所有的CPU都在干活，而且都在用戶態(tài)（如果在系統(tǒng)態(tài)干太多的活就有問題了），結果怎么還會差呢。CPU都在干嘛呢？

通過工具發(fā)現(xiàn)（Dtrace for Java），我們發(fā)現(xiàn)很多的CPU都在做一件事情，那就是不停的執(zhí)行一條Java語句（HashMap.get()）。象是進入了死循環(huán)。我們進行了進一步試驗，讓并發(fā)用戶數(shù)量為1，不停的運行10分鐘，結果沒有發(fā)現(xiàn)這種情況；接著我們讓50個并發(fā)用戶同時運行，但是只運行在一個CPU上（通過psrset），結果也沒有出現(xiàn)死循環(huán)狀態(tài)。只要并發(fā)用戶數(shù)量超過10個，運行的CPU超過兩個，不到2分鐘就出現(xiàn)死循環(huán)。一旦死循環(huán)出現(xiàn)，大量CPU資源被白白浪費，性能自然很差。

源碼分析

通過上面的試驗我們可以很肯定的判斷，是由于并發(fā)控制不好，導致數(shù)據(jù)的不一致，引起的死循環(huán)。值得一提的是，HashMap不是一個線程安全的數(shù)據(jù)結構，要用到多個線程中去，需要自己加上同步標志，為什么會死循環(huán)呢，看看下面HashMap中get函數(shù)的源代碼：

public V get(Object key) {
 if (key == null)
     return getForNullKey();
        int hash = hash(key.hashCode());
        for (Entry<K,V> e = table[indexFor(hash, table.length)];
             e != null;
             e = e.next) {
            Object k;
            if (e.hash == hash && ((k = e.key) == key || key.equals(k)))
                return e.value;
        }
        return null;
    }