今天項目發(fā)布，在預(yù)發(fā)布機器上居然出現(xiàn)應(yīng)用啟動不到10分鐘 CPU使用率從不到1%飆升到95以上，load從不到1升到15以上，然后當(dāng)然應(yīng)用就不可用了，第一次還奇怪為什么10分鐘后就變成這樣，然后找不到原因，異常還一堆其他的異常，而且還有其他的需求一起發(fā)布，所以還懷疑其他需求的問題，然后就單獨發(fā)布自己的需求代碼，重新發(fā)布后大概10分鐘后又出現(xiàn)這個問題，想了想，一堆的超時，應(yīng)用訪問也是超時，開始懷疑線程的問題，通過jstack dump java進程的線程棧信息，通過分析日志發(fā)現(xiàn)了 34個線程有16個線程的狀態(tài)處于同樣一處代碼上的runnable狀態(tài)，

?

"qtp1041301507-215" prio=10 tid=0x000000005aa2a800 nid=0x741d runnable [0x0000000044598000]java.lang.Thread.State: RUNNABLEat java.lang.Long.valueOf(Long.java:557)at com.alibaba.china.biz.viewcache.tree.NestTree.getNode(NestTree.java:188)at com.alibaba.china.biz.viewcache.ViewCacheTool.retrieveDisplayCategory(ViewCacheTool.java:802)at com.alibaba.apps.saleoffer.module.control.spuIndustry.SpuIndustryOfferResultMro.getIndustryMroAttributes(SpuIndustryOffer ResultMro.java:113)

才訪問了幾次這個代碼對應(yīng)的url，就出現(xiàn)該請求對應(yīng)的處理線程一直在runnable狀態(tài)，而且應(yīng)用的url顯示超時了。

?

好吧，再查下代碼

while (true) {DisplayCategory offerCategory = viewCacheTool.retrieveDisplayCategory(curCategoryId);if (offerCategory != null && offerCategory.getAttributes() != null && offerCategory.getAttributes().size() > 0) {for (int i = 0; i < offerCategory.getAttributes().size(); i++) {...} curCategoryId = offerCategory.getSuperCategoryId1();} ......}

這段代碼再執(zhí)行過程中由于?viewCacheTool.retrieveDisplayCategory的生產(chǎn)環(huán)境和測試環(huán)境的數(shù)據(jù)源不同導(dǎo)致在測試環(huán)境沒有出現(xiàn)問題，而線上處理過程由于curCategoryId = offerCategory.getSuperCategoryId1();在遞歸過程中

由于沒有進入if程序塊，導(dǎo)致死循環(huán)。

?

第一次遇到cpu和load飆升這么高，很有可能還真是死循環(huán)引起的，跟線程一直在執(zhí)行有關(guān)。

轉(zhuǎn)載于:https://www.cnblogs.com/secbook/archive/2012/07/02/2655159.html

總結(jié)

以上是生活随笔為你收集整理的java应用线上一次故障诊断分析的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。