排查過程
程式測試執行過程中，其中乙個程序被linux系統給殺掉了，檢視系統日誌，發現是進行占用記憶體過大而觸發linux oom給殺掉了。重啟反覆幾次後均被殺掉，發現是記憶體洩漏問題。另發現有的時候有記憶體洩漏，有的時候沒有記憶體洩漏。針對這種情形，首先想到的是進行重現，然後使用工具檢測排查，同時檢測記憶體，統計出記憶體洩漏的狀況，發現記憶體洩漏呈線性增長，大概5kb/s。有了這個資料後就可以大概想一下，**可能會出現每秒洩漏5kb/s。因為是隨著時間呈非常有規律的線性增長，最先想到的是程式中有個超時1s定時執行乙個連線操作。把這段**注釋掉後，沒有再發現記憶體洩漏，從而對洩露位置初步定位，同時也明白了為什麼有的時候有記憶體洩露，有個時候沒有。之後對這個連線操作進行進一步的問題定位，最後發現是連線中會首先進行握手，握手過程中需要呼叫密碼學庫中的esies進行加密，是在這裡出現了記憶體洩露。問題排查完成。
總結這次出現記憶體洩露是rust開發的乙個程式，rust是非常注重記憶體安全的，出現記憶體問題時，首先應該注意的**就是程式中的unsafe**段，因為unsafe部分的**編譯器只執行了部分的安全檢查，所以是最有可能出現問題的地方。
記一次goto記憶體洩漏
學習c語言時一直被告誡盡量不要使用goto語句，所以對其了解很少。在一次專案使用時由於之前的程式已經使用了goto，按照自己的理解去處理，結果導致記憶體未釋放。例子如下 include int main return 0 error printf aaaaa n printf 11111.n ret...
一次線上記憶體洩漏的問題排查
上線了好久的專案今天突然出現cpu到達100 的情況，先將專案緊急重啟，恢復正常後登入伺服器排查gc日誌，發現存在記憶體洩漏的情況。top命令檢視程序情況，top hp pid檢視執行緒，再jstack匯出日誌。過程匆忙，忘了截圖 搜尋jsatck日誌看到許多執行緒阻塞在這一行 基本可以定位到問題，...
記專案中的一次記憶體洩漏問題
最近在使用qt開發乙個大型專案，記憶體占用可能有點多，其中在vector.push back 的時候報了乙個segment fault錯誤，感到很奇怪。因為平時遇到段錯誤，大多數情況下都是陣列越界 使用訪問元素 而vector的push back 函式，在新增元素時，如果空間不足，會先向記憶體申請原...