Java 7 HashMap 多線程并發(fā)操作導(dǎo)致cpu 100%

問題現(xiàn)象

在線上發(fā)布一個java 7服務(wù)的時候，發(fā)現(xiàn)某臺機(jī)器發(fā)布完成后無法正常提供服務(wù)吟税，發(fā)布后出現(xiàn)大量線程被blocked往衷，觸發(fā)了告警：

JVM線程監(jiān)控狀況

從監(jiān)控中可以看到，JVM中存活的線程數(shù)量已經(jīng)達(dá)到2k+黑忱，這本身就是不正常的，其次勒魔，有近1.8k的線程被blocked了甫煞，這就說明服務(wù)根本就沒有正常啟動，存在啟動問題冠绢。

問題分析

線程數(shù)量超出正常水平抚吠，和線程blocked是因果關(guān)系，因?yàn)榫€程被blocked了弟胀，所以需要更多的線程來執(zhí)行工作楷力，所以新的線程被不斷的創(chuàng)建出來。
所以需要找出線程被阻塞到了什么地方孵户，通過簡單排查分析萧朝，發(fā)現(xiàn)大量的線程都被阻塞在相同的地方：

at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton
(DefaultSingletonBeanRegistry.java: 213)
at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean
(AbstractBeanFactory.java: 308)
at org.springframework.beans.factory.support.AbstractBeanFactory.getBean
(AbstractBeanFactory.java: 197)

來看一下阻塞的地方法代碼：org.springframework.beans.factory.support.DefaultSingletonBeanRegistry#getSingleton(java.lang.String, boolean)

    /**
     * Return the (raw) singleton object registered under the given name.
     * <p>Checks already instantiated singletons and also allows for an early
     * reference to a currently created singleton (resolving a circular reference).
     * @param beanName the name of the bean to look for
     * @param allowEarlyReference whether early references should be created or not
     * @return the registered singleton object, or {@code null} if none found
     */
    protected Object getSingleton(String beanName, boolean allowEarlyReference) {
        Object singletonObject = this.singletonObjects.get(beanName);
        if (singletonObject == null && isSingletonCurrentlyInCreation(beanName)) {
            synchronized (this.singletonObjects) {
                singletonObject = this.earlySingletonObjects.get(beanName);
                if (singletonObject == null && allowEarlyReference) {
                    ObjectFactory<?> singletonFactory = this.singletonFactories.get(beanName);
                    if (singletonFactory != null) {
                        singletonObject = singletonFactory.getObject();
                        this.earlySingletonObjects.put(beanName, singletonObject);
                        this.singletonFactories.remove(beanName);
                    }
                }
            }
        }
        return (singletonObject != NULL_OBJECT ? singletonObject : null);
    }

org.springframework.beans.factory.support.DefaultSingletonBeanRegistry#getSingleton(java.lang.String, boolean)這個方法確實(shí)存在同步代碼，需要執(zhí)行同步代碼的線程需要獲取到鎖才能執(zhí)行夏哭，否則就會被blocked检柬。

分析到這里，我們能確定的事情就是調(diào)用方法org.springframework.beans.factory.support.DefaultSingletonBeanRegistry#getSingleton(java.lang.String, boolean)確實(shí)會產(chǎn)生因競爭同步鎖而導(dǎo)致的線程blocked竖配，但是根據(jù)報警何址，幾乎所有的線程都被blocked了，那就可能存在死鎖問題进胯，導(dǎo)致這個鎖無法被釋放用爪，所以所有訪問該方法的線程都被blocked，為了搞明白具體的原因胁镐，先把線程堆棧轉(zhuǎn)儲下來偎血。

"xxx-13-thread-1" daemon prio=10 tid=0x00007fa3790a1000 nid=0x48b4c waiting for monitor entry [0x00007fa38e17b000]
   java.lang.Thread.State: BLOCKED (on object monitor)
    at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:213)
    - waiting to lock <0x0000000727af5b68> (a java.util.concurrent.ConcurrentHashMap)
    at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:308)
    at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:197)
    at org.springframework.aop.aspectj.annotation.BeanFactoryAspectInstanceFactory.getAspectInstance(BeanFactoryAspectInstanceFactory.java:83)
    at org.springframework.aop.aspectj.annotation.LazySingletonAspectInstanceFactoryDecorator.getAspectInstance(LazySingletonAspectInstanceFactoryDecorator.java:53)
    at org.springframework.aop.aspectj.AbstractAspectJAdvice.invokeAdviceMethodWithGivenArgs(AbstractAspectJAdvice.java:627)
    at org.springframework.aop.aspectj.AbstractAspectJAdvice.invokeAdviceMethod(AbstractAspectJAdvice.java:616)
    at org.springframework.aop.aspectj.AspectJAroundAdvice.invoke(AspectJAroundAdvice.java:70)
    at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:168)
    at org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:92)
    at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179)
    at org.springframework.aop.framework.CglibAopProxy$DynamicAdvisedInterceptor.intercept(CglibAopProxy.java:671)
    ...
    at org.springframework.cglib.proxy.MethodProxy.invoke(MethodProxy.java:204)
    at org.springframework.aop.framework.CglibAopProxy$CglibMethodInvocation.invokeJoinpoint(CglibAopProxy.java:736)
    at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:157)
    at org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:92)
    at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179)
    at org.springframework.aop.framework.CglibAopProxy$DynamicAdvisedInterceptor.intercept(CglibAopProxy.java:671)
    ...
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
    at java.lang.Thread.run(Thread.java:745)

被blocked的線程棧都和上面貼出的一樣，重點(diǎn)在于：

waiting to lock <0x0000000727af5b68> (a java.util.concurrent.ConcurrentHashMap)

0x0000000727af5b68是對象的地址盯漂，其實(shí)根據(jù)后面的提示（a java.util.concurrent.ConcurrentHashMap）也可以確定是我們上面分析過的那個同步對象烁巫，再來看一下剛才那個同步對象：

    /** Cache of singleton objects: bean name --> bean instance */
    private final Map<String, Object> singletonObjects = new ConcurrentHashMap<String, Object>(256);

現(xiàn)在，我需要知道是哪個線程占有了對象0x0000000727af5b68的鎖不釋放宠能，導(dǎo)致其他線程被blocked亚隙，為了搜索占有鎖的線程，可以在線程棧轉(zhuǎn)儲文件中搜索關(guān)鍵字："locked <0x0000000727af5b68>"违崇，根據(jù)對象鎖獲取邏輯阿弃，只可能有一個線程持有該對象鎖诊霹，搜索后，發(fā)現(xiàn)了如下的堆棧：

"main" prio=10 tid=0x00007fa4a0018000 nid=0x4889e runnable [0x00007fa4a8fea000]
   java.lang.Thread.State: RUNNABLE
    at java.util.HashMap.put(HashMap.java:494)
    at org.apache.thrift.meta_data.FieldMetaData.addStructMetaDataMap(FieldMetaData.java:49)
  ...
    at java.lang.Class.forName0(Native Method)
    at java.lang.Class.forName(Class.java:191)
    at com.sun.proxy.$Proxy346.<clinit>(Unknown Source)
    at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
    at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
    at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
    at java.lang.reflect.Constructor.newInstance(Constructor.java:526)
    at java.lang.reflect.Proxy.newInstance(Proxy.java:764)
    at java.lang.reflect.Proxy.newProxyInstance(Proxy.java:755)
    at org.springframework.aop.framework.JdkDynamicAopProxy.getProxy(JdkDynamicAopProxy.java:122)
    at org.springframework.aop.framework.JdkDynamicAopProxy.getProxy(JdkDynamicAopProxy.java:112)
    at org.springframework.aop.framework.ProxyFactory.getProxy(ProxyFactory.java:96)
  ...
    at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeCustomInitMethod(AbstractAutowireCapableBeanFactory.java:1759)
    at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1696)
    at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1626)
    at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:553)
    at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:481)
    at org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:312)
    at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:230)
    - locked <0x0000000727af5b68> (a java.util.concurrent.ConcurrentHashMap)
    at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:308)
    at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:197)
    at org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:756)
    at org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:867)
    at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:542)
    - locked <0x00000007292f2fb0> (a java.lang.Object)
    at org.springframework.boot.context.embedded.EmbeddedWebApplicationContext.refresh(EmbeddedWebApplicationContext.java:123)
    at org.springframework.boot.SpringApplication.refresh(SpringApplication.java:666)
    at org.springframework.boot.SpringApplication.refreshContext(SpringApplication.java:353)
    at org.springframework.boot.SpringApplication.run(SpringApplication.java:300)

是main線程渣淳，它持有了對象0x00007fa4a8fea000鎖脾还，并且根據(jù)他的狀態(tài)為RUNNABLE，說明它并沒有被阻塞入愧，也就是這其實(shí)不是死鎖問題鄙漏，估計(jì)是main線程進(jìn)入了死循環(huán)出不來，從而持有的鎖無法釋放棺蛛，導(dǎo)致其他需要對象0x00007fa4a8fea000鎖的線程都被blocked怔蚌。

看到棧頂在java.util.HashMap.put(HashMap.java:494)，心里一驚旁赊，感覺發(fā)現(xiàn)了thrift的一個bug了桦踊，這件事情還值得再說一說。

HashMap在至今的java版本中均不是線程安全的终畅，也就是說籍胯，如果你的場景中會存在并發(fā)訪問一個Map，你就不能用HashMap离福，否則會出現(xiàn)或多或少的問題杖狼，我們使用的是Java 7，在Java 7中妖爷，多線程并發(fā)訪問HashMap會存在線程死循環(huán)的問題本刽。

為了說明問題，截取HashMap的put方法代碼如下：

    public V put(K key, V value) {
        if (table == EMPTY_TABLE) {
            inflateTable(threshold);
        }
        if (key == null)
            return putForNullKey(value);
        int hash = hash(key);
        int i = indexFor(hash, table.length);
        for (Entry<K,V> e = table[i]; e != null; e = e.next) { // ----- 494行
            Object k;
            if (e.hash == hash && ((k = e.key) == key || key.equals(k))) {
                V oldValue = e.value;
                e.value = value;
                e.recordAccess(this);
                return oldValue;
            }
        }

        modCount++;
        addEntry(hash, key, value, i);
        return null;
    }

進(jìn)入死循環(huán)的條件就是當(dāng)前的e.next = e赠涮，也就是某個節(jié)點(diǎn)的next指針指向了自己，導(dǎo)致無限循環(huán)問題暗挑。為了驗(yàn)證這個問題笋除，將堆dump了下來，然后使用Eclipse Memory Analyzer Tool（下文中使用 MAT 來指代該工具）來載入dump下來的堆炸裆，然后點(diǎn)擊下面示意圖中的按鈕獲取到線程列表：


線程詳情

MAT可以將線程的名字垃它，當(dāng)前的堆棧及持有的對象分析出來，對于排查內(nèi)存問題非常的方便烹看，找到main線程：

main線程棧頂

結(jié)合HashMap的put死循環(huán)代碼国拇，當(dāng)時的e就是0x73ae67608這個java.util.HashMap.Entry，可以看到惯殊，這個java.util.HashMap.Entry的next還是自己酱吝，這樣就導(dǎo)致了執(zhí)行該代碼的main線程死循環(huán)了。

關(guān)于HashMap的死循環(huán)問題是如何產(chǎn)生的土思，可以參考為什么HashMap不線程安全

問題解決

這個HashMap的代碼是thrift的代碼务热，我們可以看看原始代碼：

//
// Source code recreated from a .class file by IntelliJ IDEA
// (powered by Fernflower decompiler)
//

package org.apache.thrift.meta_data;

import java.io.Serializable;
import java.util.HashMap;
import java.util.Map;
import org.apache.thrift.TBase;
import org.apache.thrift.TFieldIdEnum;

public class FieldMetaData implements Serializable {
    public final String fieldName;
    public final byte requirementType;
    public final FieldValueMetaData valueMetaData;
    private static Map<Class<? extends TBase>, Map<? extends TFieldIdEnum, FieldMetaData>> structMap = new HashMap();

    public FieldMetaData(String name, byte req, FieldValueMetaData vMetaData) {
        this.fieldName = name;
        this.requirementType = req;
        this.valueMetaData = vMetaData;
    }

    public static void addStructMetaDataMap(Class<? extends TBase> sClass, Map<? extends TFieldIdEnum, FieldMetaData> map) {
        structMap.put(sClass, map);
    }

    public static Map<? extends TFieldIdEnum, FieldMetaData> getStructMetaDataMap(Class<? extends TBase> sClass) {
        if(!structMap.containsKey(sClass)) {
            try {
                sClass.newInstance();
            } catch (InstantiationException var2) {
                throw new RuntimeException("InstantiationException for TBase class: " + sClass.getName() + ", message: " + var2.getMessage());
            } catch (IllegalAccessException var3) {
                throw new RuntimeException("IllegalAccessException for TBase class: " + sClass.getName() + ", message: " + var3.getMessage());
            }
        }

        return (Map)structMap.get(sClass);
    }
}

根據(jù)問題忆嗜，我們知道，解決問題的方式有兩種崎岂，一種是將structMap定義成并發(fā)安全的ConcurrentHashMap捆毫，另一種方法是將訪問structMap的代碼寫成同步的，也就是在操作structMap的方法上（或者代碼段上）加上synchronized關(guān)鍵字冲甘。
此時興奮的我想快去給thrift提個pr绩卤，但是發(fā)現(xiàn)如下的代碼：

github thrift修復(fù)代碼

可以看到thrift已經(jīng)修復(fù)了該問題，是使用加synchronized關(guān)鍵字的方案來解決的江醇。我們可以升級到0.9.3及之后的版本就可以避免再次發(fā)生這樣的問題濒憋。

這個pr是為了解決THRIFT-1618這個任務(wù)的，為了看看這個問題是否和我們的問題一致嫁审，可以搜索一下這個任務(wù)：

THRIFT-1618

可以看到這個任務(wù)的狀態(tài)是CLOSED跋炕，已經(jīng)被解決，問題描述也和我們的狀況一致律适。

結(jié)論

基于上文的分析辐烂，總結(jié)一下，該問題是因?yàn)槎嗑€程并發(fā)訪問HashMap觸發(fā)Java 7 HashMap擴(kuò)容時導(dǎo)致鏈表循環(huán)捂贿，從而線程進(jìn)入死循環(huán)纠修，而死循環(huán)線程持有的對象鎖無法得到釋放，其他請求獲取對象鎖的線程均被blocked?厂僧。將thrift版本升級到0.9.3以上就可以解決這個問題扣草。

最后編輯于 ：
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
  • 人面猴
    序言：七十年代末，一起剝皮案震驚了整個濱河市颜屠，隨后出現(xiàn)的幾起案子辰妙，更是在濱河造成了極大的恐慌，老刑警劉巖甫窟，帶你破解...
    沈念sama閱讀 217,185評論 6贊 503
  • 死咒
    序言：濱河連續(xù)發(fā)生了三起死亡事件密浑，死亡現(xiàn)場離奇詭異，居然都是意外死亡粗井，警方通過查閱死者的電腦和手機(jī)尔破，發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 92,652評論 3贊 393
  • 救了他兩次的神仙讓他今天三更去死
    文/潘曉璐 我一進(jìn)店門，熙熙樓的掌柜王于貴愁眉苦臉地迎上來浇衬，“玉大人懒构，你說我怎么就攤上這事≡爬蓿” “怎么了胆剧？”我有些...
    開封第一講書人閱讀 163,524評論 0贊 353
  • 道士緝兇錄：失蹤的賣姜人
    文/不壞的土叔 我叫張陵，是天一觀的道長醉冤。 經(jīng)常有香客問我赞赖，道長滚朵，這世上最難降的妖魔是什么？ 我笑而不...
    開封第一講書人閱讀 58,339評論 1贊 293
  • ?港島之戀（遺憾婚禮）
    正文 為了忘掉前任前域，我火速辦了婚禮辕近，結(jié)果婚禮上，老公的妹妹穿的比我還像新娘匿垄。我一直安慰自己移宅，他們只是感情好，可當(dāng)我...
    茶點(diǎn)故事閱讀 67,387評論 6贊 391
  • 惡毒庶女頂嫁案：這布局不是一般人想出來的
    文/花漫 我一把揭開白布椿疗。 她就那樣靜靜地躺著漏峰，像睡著了一般。 火紅的嫁衣襯著肌膚如雪届榄。 梳的紋絲不亂的頭發(fā)上浅乔，一...
    開封第一講書人閱讀 51,287評論 1贊 301
  • 城市分裂傳說
    那天，我揣著相機(jī)與錄音铝条，去河邊找鬼靖苇。 笑死，一個胖子當(dāng)著我的面吹牛班缰，可吹牛的內(nèi)容都是我干的贤壁。 我是一名探鬼主播，決...
    沈念sama閱讀 40,130評論 3贊 418
  • 雙鴛鴦連環(huán)套：你想象不到人心有多黑
    文/蒼蘭香墨 我猛地睜開眼埠忘，長吁一口氣：“原來是場噩夢啊……” “哼脾拆！你這毒婦竟也來了？” 一聲冷哼從身側(cè)響起莹妒，我...
    開封第一講書人閱讀 38,985評論 0贊 275
  • 萬榮殺人案實(shí)錄
    序言：老撾萬榮一對情侶失蹤名船，失蹤者是張志新（化名）和其女友劉穎，沒想到半個月后旨怠，有當(dāng)?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體渠驼，經(jīng)...
    沈念sama閱讀 45,420評論 1贊 313
  • ?護(hù)林員之死
    正文 獨(dú)居荒郊野嶺守林人離奇死亡，尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點(diǎn)故事閱讀 37,617評論 3贊 334
  • ?白月光啟示錄
    正文 我和宋清朗相戀三年运吓，在試婚紗的時候發(fā)現(xiàn)自己被綠了。 大學(xué)時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片疯趟。...
    茶點(diǎn)故事閱讀 39,779評論 1贊 348
  • 活死人
    序言：一個原本活蹦亂跳的男人離奇死亡拘哨，死狀恐怖，靈堂內(nèi)的尸體忽然破棺而出信峻，到底是詐尸還是另有隱情倦青，我是刑警寧澤，帶...
    沈念sama閱讀 35,477評論 5贊 345
  • ?日本核電站爆炸內(nèi)幕
    正文 年R本政府宣布盹舞，位于F島的核電站产镐，受9級特大地震影響隘庄，放射性物質(zhì)發(fā)生泄漏。R本人自食惡果不足惜癣亚，卻給世界環(huán)境...
    茶點(diǎn)故事閱讀 41,088評論 3贊 328
  • 男人毒藥：我在死后第九天來索命
    文/蒙蒙 一丑掺、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧述雾，春花似錦街州、人聲如沸。這莊子的主人今日做“春日...
    開封第一講書人閱讀 31,716評論 0贊 22
  • 一樁弒父案唆缴，背后竟有這般陰謀
    文/蒼蘭香墨 我抬頭看了看天上的太陽。三九已至黍翎，卻和暖如春面徽，著一層夾襖步出監(jiān)牢的瞬間，已是汗流浹背匣掸。 一陣腳步聲響...
    開封第一講書人閱讀 32,857評論 1贊 269
  • 情欲美人皮
    我被黑心中介騙來泰國打工趟紊， 沒想到剛下飛機(jī)就差點(diǎn)兒被人妖公主榨干…… 1. 我叫王不留，地道東北人旺聚。 一個月前我還...
    沈念sama閱讀 47,876評論 2贊 370
  • 代替公主和親
    正文 我出身青樓织阳，卻偏偏與公主長得像，于是被迫代替她去往敵國和親砰粹。 傳聞我的和親對象是個殘疾皇子唧躲，可洞房花燭夜當(dāng)晚...
    茶點(diǎn)故事閱讀 44,700評論 2贊 354