監控的mem一直居高不下：
使用jstat命令檢視gc的情況，發現ygc已經停止，一直在fgc，懷疑記憶體已經洩漏，堆記憶體中有大量無法**的物件。
然後檢視gc日誌，發現年輕代和老年代使用率達到99%，且full gc後記憶體沒有被**。確定肯定是有物件無法被**。
* 需要解密的資料
* 這是加解密的功能，每次執行加解密都會new乙個bouncycastleprovider物件,放倒cipher.getinstance()方法中。
* verificationresults.put(var0, provider_verified);
* 導致記憶體被占用兒得不到了**
* @param data
* @return
* @throws exception
*/public static string decrypt(string data) throws exception
依賴樹已經提示了，往裡面跟原始碼，發現verificationresults物件一直在put bouncycastleprovider()物件，而沒有remove，導致bouncycastleprovider()物件越來越多，最後記憶體溢位。
final class jcesecurity else if (var1 != null) else if (verifyingproviders.get(var0) != null) else catch (exception var7) finally
return var3;}}
}
問題排查之JVM記憶體洩漏
問題排查之jvm記憶體洩漏 1.問題描述，部署在客戶伺服器上的資料閘道器專案，客戶開發反應，出現伺服器記憶體占用很高的問題，懷疑是否為我們部署的專案導致？開始排查 一 endif 登入到客戶伺服器，首先確認是否是我們應用占用的記憶體 endif 檢視記憶體占用排行 ps aux sort k4,4n...
一次線上記憶體洩漏的問題排查
上線了好久的專案今天突然出現cpu到達100 的情況，先將專案緊急重啟，恢復正常後登入伺服器排查gc日誌，發現存在記憶體洩漏的情況。top命令檢視程序情況，top hp pid檢視執行緒，再jstack匯出日誌。過程匆忙，忘了截圖 搜尋jsatck日誌看到許多執行緒阻塞在這一行 基本可以定位到問題，...
乙個很難發現的記憶體洩漏
當你的資源釋放以後，再去訪問時，就會出現各種錯誤，比如物件返回空，資源不存在等等，這些錯誤都是編譯的時候語法合理的，但是一旦執行到了這裡，肯定就會出錯了 這一塊如果沒被執行的話，還是發現不了錯誤的 而且很難找到這個錯誤的原因 不在於這個錯誤有多麼的難，而是 太多，關係太複雜，沒有很好地條理去分析，邏...