1. "只要分配了記憶體沒有釋放,就會導致記憶體洩漏" -- 這是我以前的理解, 是片面的.
分配了的記憶體,如果它的指標沒有丟失,就不算是洩漏. 一般說來,為static指標變數或全域性的指標變數(它們的生存期是全域性的)進行記憶體分配,如果沒有釋放它,雖然這也是"not-freed blocks",但是它是"reachable"的.現代的os會得到這些指標並去釋放它.
下面是兩個例子:
1) 使用全域性指標或靜態指標:
int main()
使用valgrind檢查:
valgrind --leak-check=yes --show-reachable=yes -q ./memtest
==13764== searching for pointers to 1 not-freed blocks.
==13764== checked 4488448 bytes.
==13764==
==13764== 4 bytes in 1 blocks are still reachable in loss record 1 of 1
==13764== at 0xb74d27ab: __builtin_new (vg_replace_malloc.c:172)
==13764== by 0xb74d2802: operator new(unsigned) (vg_replace_malloc.c:185)
==13764== by 0x8048491: main (in /home/prog/valgrind/memtest)
==13764== by 0xb71c4ba6: __libc_start_main (in /lib/libc-2.3.2.so)
==13764==
==13764== leak summary:
==13764== definitely lost: 0 bytes in 0 blocks.
==13764== possibly lost: 0 bytes in 0 blocks.
==13764== still reachable: 4 bytes in 1 blocks.
==13764== suppressed: 0 bytes in 0 blocks.
==13764==
報告說有乙個"not-freed block",但這個block是reachable的,所以它不算是真正的memory leak.
2) 如果使用的是區域性指標:
int main()
==13782== searching for pointers to 1 not-freed blocks.
==13782== checked 4484352 bytes.
==13782==
==13782== 4 bytes in 1 blocks are definitely lost in loss record 1 of 1
==13782== at 0xb74d27ab: __builtin_new (vg_replace_malloc.c:172)
==13782== by 0xb74d2802: operator new(unsigned) (vg_replace_malloc.c:185)
==13782== by 0x8048491: main (in /home/prog/valgrind/memtest)
==13782== by 0xb71c4ba6: __libc_start_main (in /lib/libc-2.3.2.so)
==13782==
==13782== leak summary:
==13782== definitely lost: 4 bytes in 1 blocks.
==13782== possibly lost: 0 bytes in 0 blocks.
==13782== still reachable: 0 bytes in 0 blocks.
==13782== suppressed: 0 bytes in 0 blocks.
==13782==
報告說是"definitely lost",這才是真正的memory leak!
切記：靜態變數只能由靜態函式訪問。
關於 ThreadLocal 記憶體洩露
在使用 threadlocal 的時候，一般我們的 都是這樣寫的 public class threadlocaldemo public static long getuserid public static void remove 然後處理業務的是乙個執行緒池，有乙個結果就是 threadloca...
關於記憶體洩露追蹤函式mtrace
關於 mtrace調查 記憶體洩露的過程，mtrace是glibc的乙個函式，他的機制實際上是把記憶體洩露資訊列印到環境變數到malloc trace設 置的 檔案裡，然後使用mtrace命令來檢視log資訊，因為mtrace呼叫會增加 系統開銷，所以一般放在debug巨集定義中 比如說下面的函式 ...
關於iframe記憶體洩露的問題
5.17日，最近幾天上網狂搜以及實踐了一下，發現普遍的說法是使用iframe確實會導致大量的記憶體得不到釋放 5.21日 最近嘗試了各種方法 1.直接寫死乙個iframe,通過js改變src的方法，結果 記憶體問題還是存在 2.通過jquery的load 方法，將返回的結果嵌入到乙個div中，結果 ...