上線了好久的專案今天突然出現cpu到達100% 的情況，先將專案緊急重啟，恢復正常後登入伺服器排查gc日誌，發現存在記憶體洩漏的情況。
top命令檢視程序情況，top -hp pid檢視執行緒，再jstack匯出日誌。過程匆忙，忘了截圖
搜尋jsatck日誌看到許多執行緒阻塞在這一行**
基本可以定位到問題，是由於certutil中的建立的某些物件一直沒有被**導致的。而certutil並不是靜態的，而是每次請求建立乙個，因此當併發量提公升時，新建立的物件會佔滿記憶體。
檢視日誌系統，發現果然近兩天的請求數量劇增
在mat中匯入dump檔案分析，可以看到與jstack日誌中結論一致，jcssecurity類中的map維護了大量的org.bouncycastle.jce.provider.bouncycastleprovider物件，這些物件一直沒有被釋放，直到佔滿了記憶體空間
jcssecurity類原始碼顯示其內部維護乙個靜態的map--verificationresults，它在呼叫鏈中只存在put操作，不存在remove操作，因此每次呼叫後在map中維護的value無法被**。由此我們可以知道，該類的設計初衷，應當是讓我們單例或靜態呼叫，不應當持續建立新物件
第一次排查oom，其實過程遠沒有部落格描述的這般順利。此次事故之後，相信以後的記憶體問題排查會更加得心應手。
記一次線上問題排查
這次線上問題來的比較突然，影響也大，用部落格記錄下整個過程，也當作是對這次事故的一次總結歸納。day1 2018年06月21號上午10點，收到運營同事通知，http com api 訪問量劇增，日誌量達到80g 天，而且有上公升趨勢。運營同事讓我們排查，這種訪問是否正常。運營統計訪問量 收到通知後立...
記一次排查記憶體洩漏的過程
排查過程 程式測試執行過程中，其中乙個程序被linux系統給殺掉了，檢視系統日誌，發現是進行占用記憶體過大而觸發linux oom給殺掉了。重啟反覆幾次後均被殺掉，發現是記憶體洩漏問題。另發現有的時候有記憶體洩漏，有的時候沒有記憶體洩漏。針對這種情形，首先想到的是進行重現，然後使用工具檢測排查，同時...
記一次React線上問題排查
昨天運營報了乙個問題，之前一直正常執行的react專案突然頁面訪問不了了，通過排查發現頁面報錯了，錯誤如下 uncaught typeerror failed to set an indexed property on cssstyledeclaration index property sette...