今天發布一個線上服務，暫且稱之為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，避免頻繁反射。
喜歡 
頂
難過
囧
圍觀
無聊
王者榮耀賬號惡
MARVEL Strike 
2017年10月手游
比官居一品好玩
