变态重口极致另类在线-波多久久夜色精品国产-波多野结衣在线观看一区-波多野结衣在线观看一区二区-污污的网站免费阅读-污污视频网址

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

首頁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 (您的評論需要經過審核才能顯示)

本類常用軟件

主站蜘蛛池模板: 亚洲欧美日产综合在线看 | 亚洲一区在线免费观看 | 国产精品久久女同磨豆腐 | 欧美精品一区二区精品久久 | 甜性涩爱免费在线观看 | 日韩视频精品在线 | 97碰视频人人做人人爱欧美 | 欧美日韩精品一区二区三区视频 | 中国国产成人精品久久 | 日韩成人精品日本亚洲 | 免费又黄又猛又爽的大片 | 波多野结衣中文字幕久久 | 久久三级影视 | 中国一级特黄特色真人毛片 | www.99视频| 欧美成人免费高清二区三区 | 亚洲精品天堂在线 | 成人欧美在线视频 | 插菊综合网| 最近免费中文完整视频观看 | 中文字幕一区在线 | 欧美一区二区三区男人的天堂 | 国产日韩精品一区在线不卡 | 国产成人精品免费视频大全软件 | 天堂网在线视频 | 99热免费在线观看 | 一级做a爱过程免费视频韩国 | 97人人艹| 免费日韩精品 | 久久www免费人成看片色多多 | 亚洲香蕉视频 | 狠狠色噜噜狠狠狠狠色综合网 | 国产在线观看色 | 国产日韩亚洲不卡高清在线观看 | 中文字幕日韩欧美 | 国产不卡一区 | 91久久免费视频 | 欧美激情视频二区三区 | 国产精品丝袜在线观看 | 国产免费叼嘿网站免费 | 91精品福利一区二区三区野战 |