精品久久看,欧美成人久久一级c片免费,日本加勒比在线精品视频,国产一区二区三区免费大片天美,国产成人精品999在线,97理论三级九七午夜在线观看

東坡下載:內容最豐富最安全的下載站!

首頁IT技術硬件技術 → Hession反序列化導致CPU占用飆高

Hession反序列化導致CPU占用飆高

相關文章發表評論 來源:本站整理時間:2016/12/3 9:41:17字體大小:A-A+

更多

作者:專題點擊:223次評論:0次標簽: CPU占用

今天發布一個線上服務,暫且稱之為O,發布完后,依賴O服務的2個服務C和W大量Time報警,并且這兩個服務的CPU占用都飆到了40%左右,平時只有10%的樣子。 

這時去看O服務的監控,Time并沒有升高,QPS反倒降了一半。同時C和W服務器日志中出現了大量的WARNING,信息如下:

java.lang.ClassNotFoundException: com.我是不可描述的信息.PropertyAo Dec 02, 2016 6:24:33 PM com.alibaba.com.caucho.hessian.io.SerializerFactory getDeserializerWARNING: Hessian/Burlap: 'com.我是不可描述的信息.PropertyAo' is an unknown class in WebappClassLoader  context:  delegate: false  repositories:    /WEB-INF/classes/----------> Parent Classloader: org.apache.catalina.loader.StandardClassLoader@21bf4c80123456789123456789

短時間內找不到原因,且C服務是核心服務,找QA童鞋把O服務回滾,C和W報警恢復,CPU占用回到正常。

定位

可能見過這個WARNING的朋友已經知道了我這次發布干了啥,其實就是在API返回的模型中增加了兩個自定義類型的屬性,如下:

private List<PropertyAo> properties1;private List<PropertyAo> properties2;1212

這兩個屬性W中會用到,之所以會有上面提到的WARNING,是由于我先發布了O服務,O服務中設置了這兩個屬性,而W服務還沒有發布,這樣Hession在反序列化的時候,檢測到了PropertyAo不存在,所以給出了WARNING。但這與CPU飆高有關系嗎? 
與同事討論了一番,他提到了Hession反序列化時會使用到反射,他之前遇到過CPU占用飆高的情況(是由于反射代碼被大量調用),這點提醒了我,順著com.alibaba.com.caucho.hessian.io.SerializerFactory getDeserializer這個方法看到了這樣的實現:

try {    Class cl = Class.forName(type, false, _loader);    deserializer = getDeserializer(cl); } catch (Exception e) {    log.warning("Hessian/Burlap: '" + type + "' is an unknown class in " + _loader + ":\n" + e);    log.log(Level.FINER, e.toString(), e); }12345671234567

可以看到Hession是通過名字去拿到Class,這里使用了反射,當反射失敗時就會打出上面的warning。這時聰明的你可能想到了,即使沒有失敗也是在使用反射啊,繼續向下看代碼:

if (deserializer != null) {    if (_cachedTypeDeserializerMap == null)        _cachedTypeDeserializerMap = new HashMap(8);    synchronized (_cachedTypeDeserializerMap) {        _cachedTypeDeserializerMap.put(type, deserializer);    } }1234567812345678

反射成功就會將其cache起來,也就是說,如果反射成功,只會調用一次反射,反射失敗,則每次都會執行反射。

驗證

先將C升級到最新api,然后發布,再發布O服務,C表現正常,W的CPU又開始飆高,執行jstack看一下事故現場,可以看到一些線程正在執行反射,棧信息如下:

"New I/O worker #17" daemon prio=10 tid=0x00007fb1ed33b000 nid=0x63fe runnable [0x00007fb22fcfa000]    java.lang.Thread.State: RUNNABLE         at java.lang.Class.forName0(Native Method)         at java.lang.Class.forName(Class.java:270)         at com.alibaba.com.caucho.hessian.io.SerializerFactory.getDeserializer(SerializerFactory.java:500)1234512345

解決

當服務端模型升級時,尤其是新增自定義類型時,盡量讓所有消費端升級,但當消費端過多時,這個方案成本太高,且不友好

改進SerializerFactory,把反射失敗的情況也緩存,避免重復反射

給Dubbo提了issue,不過估計不會解決

結論

Hession默認的反序列化實現滿足下面2點條件時,就會導致CPU占用飆高:

服務端新增了自定義類型

對該服務接口的調用QPS較高,我的應用中是100+

其本質原因還是由于反射,所以開發過程中慎用反射,反射得到的信息盡量Cache,避免頻繁反射。

擴展知識

相關評論

閱讀本文后您有什么感想? 已有 人給出評價!

  • 2791 喜歡喜歡
  • 2101 頂
  • 800 難過難過
  • 1219 囧
  • 4049 圍觀圍觀
  • 5602 無聊無聊
熱門評論
最新評論
昵稱:
表情: 高興 可 汗 我不要 害羞 好 下下下 送花 屎 親親
字數: 0/500 (您的評論需要經過審核才能顯示)

本類常用軟件

主站蜘蛛池模板: 日本四虎影院 | 黄色网址国产 | 99久久精品免费视频 | 青青草国产97免久久费观看 | 91视频最新地址 | 99re99| 久久电影网午夜鲁丝片免费 | 四虎影视库永久在线地址 | 成人欧美一区二区三区 | 天天射日日干 | 久久精品免看国产成 | 国产成人精品一区二区不卡 | 美女网站免费看 | 九九亚洲| 色综合精品 | 99这里精品 | 伊人免费视频网 | 婷婷激情四月 | 国产精品久久久久久免费 | 久久精品国产99久久99久久久 | 阿v天堂网 | 婷婷色在线视频 | 天天干天天干天天干天天干天天干 | 日韩 欧美 中文字幕 不卡 | 免费看电影网址 | www.奇米影视.com | 久久久久久国产精品免费免 | 四虎永久免费影院在线 | 亚洲综合天堂网 | 免费一级a毛片 | 五月天最新网址 | 深夜视频免费观看 | 伊人成年综合网 | 伊人久久婷婷 | 97视频在线观看免费视频 | 国产免费一级在线观看 | 亚洲精品国产免费 | 午夜激情福利视频 | 青草国产在线观看 | 97在线亚洲| 精品国产亚洲人成在线 |