開源jar包bug致使的CPU消耗200%問題分析案例

mapdb是什麼

mapdb是一個快速、易用的嵌入式java數據庫，主要提供map和set形式的數據存儲，使用起來就像是在操做java自己的map,set，

mapdb能夠提供內存級別和磁盤級別的緩存，MapDB 提供了併發的 TreeMap 和 HashMap ，使用基於磁盤的存儲。快速、可伸縮性以及易用，它提供了基於磁盤或者堆外（off- heap容許Java直接操做內存空間, 相似於C的malloc和free）存儲的併發的Maps、Sets、Queues。MapDB的前身是JDBM，已經有15年的歷史。

它的jar包只有200KB，且無其它依賴，很是輕量。MapDB目前相對來講功能已經穩定，並有全職 的開發者支持開發。

mapdb引發app-6028-security應用CPU消耗異常問題定位案例

最近2天在測試的過程當中發現基礎應用服務app-6028-security應用存在一個奇怪的問題，該應用在運行一段時間後，發現這個服務的cpu常常在200%多，即便不作任務業務操做，

cpu的使用率一段時間後仍然飆升到200%，因此很奇怪，現象是運行一夜後，就會出現這個cpu高的問題，重啓應用後過一段的時間又會從新復現，

該應用主要是作一些敏感數據的加密和解密的服務(好比身份證、銀行卡、姓名、手機號等數據加密和解密)。

由此肯定這個cpu消耗最多的進程是app-6028-security應用

經過top -Hp 29868

發現其中的2個線程，消耗異常，始終消耗cpu 99%

登陸docker經過jstack查看：

jstack 57 | grep "nid=0x98" -A30

到此，基本肯定這段代碼確定存在問題

 

爲了驗證問題的準確性，接着登陸咱們的準生產環境，看看這個問題是否存在：

登陸準生產後，查看以下：

發現準生產也存在這個問題，其實問題就是這兩個線程致使的 

而後讓運維去線上查看這個服務的cpu消耗，佔據了也是200%，也讓運維拿到上面的docker環境裏的進程號：

printf "%x\n" tid

nid=0xaf

nid=0xb3

 

 

APP項目中調用到mapdb的代碼以下：

查看1.0.9版本代碼中的代碼邏輯以下：

 

經過和架構師討論，建議升級到該版本的下一個版本，從當前的1.0.9版本升級到2.0的版本，若是版本跨度，怕不兼容，因此爲了安全起見，暫時這樣解決，最新版本的是支持jdk1.8 而咱們項目是jdk1.7版本

老版本的源碼以下

 

新版本的源碼以下：

經過對比mapdb插件源碼，發現存在問題的源碼已經改動了，因此將mapdb從1.0.9版本升級到2.0-beta13版本後，觀察2天三夜，問題不在復現

 

目前問題已經解決

其實這個問題很容易，可是主要是他對性能的影響不大，在和運維獲取線上的這個服務的cpu佔用時候，運維都以爲影響不大，cpu消耗佔用都不大，可是做爲性能測試人員，必定要嚴格要求項目，任何問題不要放過

可是說明之前的測試，沒有重視和解決這個問題，畢竟這個問題已經在線上運行了2年以上了

 

 

 

 

參考文章：

https://mvnrepository.com/artifact/org.mapdb/mapdb

https://blog.csdn.net/qy20115549/article/details/53207093

https://blog.csdn.net/abc86319253/article/details/53020432

https://blog.csdn.net/u014401141/article/details/79132224

http://www.sohu.com/a/136901812_494947

https://blog.csdn.net/Appleyk/article/details/79880655

http://www.mapdb.org/

https://www.jianshu.com/p/b6f43302338e