Linux如何調試內存洩漏

2021-03-02 良許Linux

內存洩漏是指由於疏忽或錯誤造成程序未能釋放已經不再使用的內存。內存洩漏並非指內存在物理上的消失，而是應用程式分配某段內存後，由於設計錯誤，導致在釋放該段內存之前就失去了對該段內存的控制，從而造成了內存的浪費。

我們平時開發過程中不可避免的會遇到內存洩漏問題，你是如何排查的呢？估計你是使用下面這幾個工具吧？

valgrind

mtrace

dmalloc

ccmalloc

memwatch

debug_new

這裡程序喵向大家推薦新的一個排查內存洩漏的工具：AddressSanitizer(ASan)，該工具為gcc自帶，4.8以上版本都可以使用，支持Linux、OS、Android等多種平臺，不止可以檢測內存洩漏，它其實是一個內存錯誤檢測工具，可以檢測的問題有：

使用方法直接看我下面的代碼：

檢測內存洩漏

內存洩漏代碼：

#include <stdlib.h>
void func1() { malloc(7); }
void func2() { malloc(5); }
int main() {   func1();   func2();   return 0;}
編譯and輸出：
g++ -fsanitize=address -g test_leak.cc && ./a.out
===================================================================103==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 7 byte(s) in 1 object(s) allocated from:   #0 0x7f95b231eb40 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xdeb40)   #1 0x7f95b36007f7 in func1() /home/wangzhiqiang/test/test_leak.cc:3   #2 0x7f95b3600814 in main /home/wangzhiqiang/test/test_leak.cc:8   #3 0x7f95b1e61b96 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21b96)
Direct leak of 5 byte(s) in 1 object(s) allocated from:   #0 0x7f95b231eb40 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xdeb40)   #1 0x7f95b3600808 in func2() /home/wangzhiqiang/test/test_leak.cc:5   #2 0x7f95b3600819 in main /home/wangzhiqiang/test/test_leak.cc:9   #3 0x7f95b1e61b96 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21b96)
SUMMARY: AddressSanitizer: 12 byte(s) leaked in 2 allocation(s).
編譯方式很簡單，只需要添加-fsanitize=address -g就可以檢測出具體產生內存洩漏的位置以及洩漏空間的大小。
檢測堆棧內存越界訪問
示例：
#include <iostream>
int main() {   int *array = new int[100];   array[0] = 0;   int res = array[100];     delete[] array;   return res;}
編譯and輸出：
g++ -fsanitize=address -g test_leak.cc && ./a.out   ===================================================================110==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x6140000001d0 at pc 0x7f0e06400d2e bp 0x7ffff5963f10 sp 0x7ffff5963f00READ of size 4 at 0x6140000001d0 thread T0   #0 0x7f0e06400d2d in main /home/wangzhiqiang/test/test_leak.cc:6   #1 0x7f0e048d1b96 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21b96)   #2 0x7f0e06400bb9 in _start (/mnt/d/wzq/wzq/util/test/a.out+0xbb9)
0x6140000001d0 is located 0 bytes to the right of 400-byte region [0x614000000040,0x6140000001d0)allocated by thread T0 here:   #0 0x7f0e05120608 in operator new[](unsigned long) (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xe0608)   #1 0x7f0e06400cab in main /home/wangzhiqiang/test/test_leak.cc:4   #2 0x7f0e048d1b96 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21b96)
SUMMARY: AddressSanitizer: heap-buffer-overflow /home/wangzhiqiang/test/test_leak.cc:6 in mainShadow bytes around the buggy address: 0x0c287fff7fe0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c287fff7ff0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c287fff8000: fa fa fa fa fa fa fa fa 00 00 00 00 00 00 00 00 0x0c287fff8010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c287fff8020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00=>0x0c287fff8030: 00 00 00 00 00 00 00 00 00 00[fa]fa fa fa fa fa 0x0c287fff8040: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c287fff8050: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c287fff8060: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c287fff8070: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c287fff8080: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa faShadow byte legend (one shadow byte represents 8 application bytes): Addressable:           00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone:       fa Freed heap region:       fd Stack left redzone:      f1 Stack mid redzone:       f2 Stack right redzone:     f3 Stack after return:      f5 Stack use after scope:   f8 Global redzone:          f9 Global init order:       f6 Poisoned by user:        f7 Container overflow:      fc Array cookie:            ac Intra object redzone:    bb ASan internal:           fe Left alloca redzone:     ca Right alloca redzone:    cb==110==ABORTING
可以方便定位到堆棧內存越界訪問的錯誤。
全局內存越界訪問：
示例：
#include <iostream>
int global_array[100] = {0};
int main() {   int res = global_array[100];     return 0;}
編譯and輸出：
g++ -fsanitize=address -g test_leak.cc && ./a.out===================================================================116==ERROR: AddressSanitizer: global-buffer-overflow on address 0x7f42e6e02310 at pc 0x7f42e6c00c84 bp 0x7fffdda52780 sp 0x7fffdda52770READ of size 4 at 0x7f42e6e02310 thread T0   #0 0x7f42e6c00c83 in main /home/wangzhiqiang/test/test_leak.cc:6   #1 0x7f42e50d1b96 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21b96)   #2 0x7f42e6c00b69 in _start (/mnt/d/wzq/wzq/util/test/a.out+0xb69)
0x7f42e6e02310 is located 0 bytes to the right of global variable 'global_array' defined in 'test_leak.cc:3:5' (0x7f42e6e02180) of size 400SUMMARY: AddressSanitizer: global-buffer-overflow /home/wangzhiqiang/test/test_leak.cc:6 in mainShadow bytes around the buggy address: 0x0fe8dcdb8410: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0fe8dcdb8420: 00 00 00 00 00 00 00 00 01 f9 f9 f9 f9 f9 f9 f9 0x0fe8dcdb8430: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0fe8dcdb8440: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0fe8dcdb8450: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00=>0x0fe8dcdb8460: 00 00[f9]f9 f9 f9 f9 f9 00 00 00 00 00 00 00 00 0x0fe8dcdb8470: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0fe8dcdb8480: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0fe8dcdb8490: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0fe8dcdb84a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0fe8dcdb84b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00Shadow byte legend (one shadow byte represents 8 application bytes): Addressable:           00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone:       fa Freed heap region:       fd Stack left redzone:      f1 Stack mid redzone:       f2 Stack right redzone:     f3 Stack after return:      f5 Stack use after scope:   f8 Global redzone:          f9 Global init order:       f6 Poisoned by user:        f7 Container overflow:      fc Array cookie:            ac Intra object redzone:    bb ASan internal:           fe Left alloca redzone:     ca Right alloca redzone:    cb==116==ABORTING
局部內存被外層使用
示例：
#include <iostream>
volatile int *p = 0;
int main() {{   int x = 0;   p = &x;} *p = 5; return 0;}
編譯and輸出：
g++ -fsanitize=address -g test_leak.cc && ./a.out===================================================================243==ERROR: AddressSanitizer: stack-use-after-scope on address 0x7fffce12a4b0 at pc 0x7f3993e00e7e bp 0x7fffce12a480 sp 0x7fffce12a470WRITE of size 4 at 0x7fffce12a4b0 thread T0      
Address 0x7fffce12a4b0 is located in stack of thread T0 at offset 32 in frame  
This frame has 1 object(s):  [32, 36) 'x' <== Memory access at offset 32 is inside this variableHINT: this may be a false positive if your program uses some custom stack unwind mechanism or swapcontext    (longjmp and C++ exceptions *are* supported)SUMMARY: AddressSanitizer: stack-use-after-scope /home/wangzhiqiang/test/test_leak.cc:10 in mainShadow bytes around the buggy address:0x100079c1d440: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 000x100079c1d450: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 000x100079c1d460: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 000x100079c1d470: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 000x100079c1d480: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00=>0x100079c1d490: 00 00 f1 f1 f1 f1[f8]f2 f2 f2 00 00 00 00 00 000x100079c1d4a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 000x100079c1d4b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 000x100079c1d4c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 000x100079c1d4d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 000x100079c1d4e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00Shadow byte legend (one shadow byte represents 8 application bytes):Addressable:           00Partially addressable: 01 02 03 04 05 06 07Heap left redzone:       faFreed heap region:       fdStack left redzone:     f1Stack mid redzone:       f2Stack right redzone:     f3Stack after return:     f5Stack use after scope:   f8Global redzone:         f9Global init order:       f6Poisoned by user:       f7Container overflow:     fcArray cookie:           acIntra object redzone:   bbASan internal:           feLeft alloca redzone:     caRight alloca redzone:   cb==243==ABORTING
free後被使用
示例：
#include <iostream>
int main() {    int *array = new int[100];    delete[] array;    int a = array[0];      return 0;}
編譯and輸出：
g++ -fsanitize=address -g test_leak.cc && ./a.out===================================================================282==ERROR: AddressSanitizer: heap-use-after-free on address 0x614000000040 at pc 0x7f209fa00caa bp 0x7ffff2a15020 sp 0x7ffff2a15010READ of size 4 at 0x614000000040 thread T0            
0x614000000040 is located 0 bytes inside of 400-byte region [0x614000000040,0x6140000001d0)freed by thread T0 here:            
previously allocated by thread T0 here:            
SUMMARY: AddressSanitizer: heap-use-after-free /home/wangzhiqiang/test/test_leak.cc:6 in mainShadow bytes around the buggy address:  0x0c287fff7fb0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  0x0c287fff7fc0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  0x0c287fff7fd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  0x0c287fff7fe0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  0x0c287fff7ff0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00=>0x0c287fff8000: fa fa fa fa fa fa fa fa[fd]fd fd fd fd fd fd fd  0x0c287fff8010: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd  0x0c287fff8020: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd  0x0c287fff8030: fd fd fd fd fd fd fd fd fd fd fa fa fa fa fa fa  0x0c287fff8040: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa  0x0c287fff8050: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa faShadow byte legend (one shadow byte represents 8 application bytes):  Addressable:           00  Partially addressable: 01 02 03 04 05 06 07  Heap left redzone:       fa  Freed heap region:       fd  Stack left redzone:      f1  Stack mid redzone:       f2  Stack right redzone:     f3  Stack after return:      f5  Stack use after scope:   f8  Global redzone:          f9  Global init order:       f6  Poisoned by user:        f7  Container overflow:      fc  Array cookie:            ac  Intra object redzone:    bb  ASan internal:           fe  Left alloca redzone:     ca  Right alloca redzone:    cb==282==ABORTING
Initialization order bugs
示例，這裡有兩個文件：
#include <stdio.h>
extern int extern_global;int read_extern_global() { return extern_global; }
int x = read_extern_global() + 1;
int main() {    printf("%d\n", x);    return 0;}

int foo() { return 123; }int extern_global = foo();
第一種編譯方式輸出如下：
g++ test_memory1.cc test_memory2.cc && ./a.out1
第二種編譯方式輸出如下：
g++ test_memory2.cc test_memory1.cc && ./a.out124
這種問題我們平時編程過程中可以都不會太注意，然而通過ASan可以檢測出這種潛在的bug：
編譯and輸出：
g++ -fsanitize=address -g test_memory1.cc test_memory2.cc
ASAN_OPTIONS=check_initialization_order=true:strict_init_order=true ./a.out===================================================================419==ERROR: AddressSanitizer: initialization-order-fiasco on address 0x7f46c20021a0 at pc 0x7f46c1e00c28 bp 0x7fffe423d920 sp 0x7fffe423d910READ of size 4 at 0x7f46c20021a0 thread T0    #0 0x7f46c1e00c27 in read_extern_global() /home/wangzhiqiang/test/test_memory1.cc:3    #1 0x7f46c1e00cb3 in __static_initialization_and_destruction_0 /home/wangzhiqiang/test/test_memory1.cc:4    #2 0x7f46c1e00d0a in _GLOBAL__sub_I__Z18read_extern_globalv /home/wangzhiqiang/test/test_memory1.cc:8    #3 0x7f46c1e00e5c in __libc_csu_init (/mnt/d/wzq/wzq/util/test/a.out+0xe5c)    #4 0x7f46c0461b27 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21b27)    #5 0x7f46c1e00b09 in _start (/mnt/d/wzq/wzq/util/test/a.out+0xb09)
0x7f46c20021a0 is located 0 bytes inside of global variable 'extern_global' defined in 'test_memory2.cc:2:5' (0x7f46c20021a0) of size 4  registered at:    #0 0x7f46c08764a8  (/usr/lib/x86_64-linux-gnu/libasan.so.4+0x364a8)    #1 0x7f46c1e00e0b in _GLOBAL__sub_I_00099_1__Z3foov (/mnt/d/wzq/wzq/util/test/a.out+0xe0b)    #2 0x7f46c1e00e5c in __libc_csu_init (/mnt/d/wzq/wzq/util/test/a.out+0xe5c)
SUMMARY: AddressSanitizer: initialization-order-fiasco /home/wangzhiqiang/test/test_memory1.cc:3 in read_extern_global()Shadow bytes around the buggy address:  0x0fe9583f83e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  0x0fe9583f83f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  0x0fe9583f8400: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  0x0fe9583f8410: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  0x0fe9583f8420: 00 00 00 00 00 00 00 00 04 f9 f9 f9 f9 f9 f9 f9=>0x0fe9583f8430: 00 00 00 00[f6]f6 f6 f6 f6 f6 f6 f6 00 00 00 00  0x0fe9583f8440: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  0x0fe9583f8450: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  0x0fe9583f8460: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  0x0fe9583f8470: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  0x0fe9583f8480: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00Shadow byte legend (one shadow byte represents 8 application bytes):  Addressable:           00  Partially addressable: 01 02 03 04 05 06 07  Heap left redzone:       fa  Freed heap region:       fd  Stack left redzone:      f1  Stack mid redzone:       f2  Stack right redzone:     f3  Stack after return:      f5  Stack use after scope:   f8  Global redzone:          f9  Global init order:       f6  Poisoned by user:        f7  Container overflow:      fc  Array cookie:            ac  Intra object redzone:    bb  ASan internal:           fe  Left alloca redzone:     ca  Right alloca redzone:    cb==419==ABORTING
注意：這裡在運行程序前需要添加環境變量：
ASAN_OPTIONS=check_initialization_order=true:strict_init_order=true
小總結
ASan是個很好的檢測內存問題的工具，不需要配置環境，使用還方便，編譯時只需要-fsanitize=address -g就可以，運行程序時候可以選擇添加對應的ASAN_OPTIONS環境變量就可以檢測出很多內存問題。它的錯誤信息也很有用，明確指出當前是什麼類型的內存錯誤，如：
具體可以看google的官方文檔：https://github.com/google/sanitizers/wiki/AddressSanitizer

添加良許個人微信即送3套程式設計師必讀資料
→ 精選技術資料共享
→ 高手如雲交流社群
本公眾號全部博文已整理成一個目錄，請在公眾號裡回復「m」獲取！
推薦閱讀：
牛X，這次Windows太給力了！！！
為什麼只有 Pornhub 這麼紅？
熬夜總結了面試套路，2W字長文！
5T技術資源大放送！包括但不限於：C/C++，Linux，Python，Java，PHP，人工智慧，單片機，樹莓派，等等。在公眾號內回復「1024」，即可免費獲取！！

相關焦點

  • Linux平臺中調試C/C++內存洩漏方法 (騰訊和MTK面試的時候問到的)
    因 此，出於這些原因，需要特別關注 C 和 C++ 編程的內存問題，特別是內存洩漏。本文先從如何發現內存洩漏，然後使用不同的方法和工具定位內存洩漏，最後對這些工具進行了比較，另外還簡單介紹了資源洩 漏的處理(以句柄洩漏為例)。本文使用的測試平臺是：Linux (Redhat AS4)。但是這些方法和工具許多都不只是局限於 C/C++ 語言以及 linux 作業系統。
  • 用valgrind定位內存洩漏
    緣起年前，寫了使用mtrace定位內存洩漏，在留言中，有讀者提到了希望介紹valgrind，那好，今天就介紹使用valgrind定位內存洩漏。大約2-3年前，楊同學讓我幫做模擬面試，他求職的是C++崗位，我問了這樣一個問題：在你的項目中，你是如何定位內存洩漏的呢？
  • Linux 系統內核的調試
    本文將首先介紹 Linux 內核上的一些內核代碼監視和錯誤跟蹤技術，這些調試和跟蹤方法因所要求的使用環境和使用方法而各有不同，然後重點介紹三種 Linux 內核的原始碼級的調試方法。　　調試是軟體開發過程中一個必不可少的環節，在 Linux 內核開發的過程中也不可避免地會面對如何調試內核的問題。
  • 如何通過wrap malloc定位C/C++程序的內存洩漏
    什麼是內存洩漏？動態申請的內存丟失引用，造成沒有辦法回收它（我知道槓jing要說進程退出前系統會統一回收），這便是內存洩漏。理論上，只要我們足夠小心，在每次申請的時候，都牢記釋放，那這個世界就清淨了，但現實往往沒有那麼美好，比如拋異常了，釋放內存的語句執行不到，又或者某菜鳥程式設計師不小心埋了一個雷，所以，我們必須直面真實的世界，那就是我們會遭遇內存洩漏。怎麼查內存洩漏？
  • 用Visual Studio調試Linux程序
    當然如果你說VS2015及以上版本自帶的linux調試插件，那就算了。這些自帶的插件調試一個有簡單的main函數程序還湊合，稍微複雜點的程序，根本無法編譯調試。而本文介紹的主角是VS的另外一款插件Visual GDB，讓我們歡迎主角登場，下面是正文。
  • C/C++程序調試和內存檢測
    減少程序錯誤最有效的方法是：在敲代碼之前，多花點時間思考，如何構造程序，數據結構和算法，儘量把細節提前寫下來，可以嘗試著在紙上寫出核心代碼，這樣可以減少今後修改代碼的時間。1、常用的調試技巧(1)代碼檢查，重新閱讀程序，排除比較明顯的錯誤。
  • GDB與Valgrind ,調試C++代碼內存的工具
    筆者 入"坑"C++之後，在調試 C++代碼的過程之中，學習了不少調試代碼內存的工具。希望借這個機會來介紹一下筆者常用的工具，GDB，Valgrind等等，相信大家通過好好運用這些工具，能更好的馴服內存這匹"野馬"。
  • iOS內存洩漏的檢測及定位工具-Instruments
    ，後來經過和開發小哥哥溝通，分析得知可能是內存洩漏，於是利用Instruments工具進行檢測發現果然存在內存洩漏，並成功定位到內存洩漏的代碼所在，問題完美解決。上述內存洩漏問題的定位和完美解決離不開一個工具Instruments，測試遇到的內存問題中最常見就是內存洩漏，在此小編介紹一個內存洩漏檢測工具- Instruments之Leaks，使用它可以檢測程序是否存在內存洩露，並定位到內存洩露的代碼。
  • 理解閉包與內存洩漏
    三、內存洩漏內存洩漏常常與閉包緊緊聯繫在一起，很容易讓人誤以為閉包就會導致內存洩漏。其實閉包只是讓內存常駐，而濫用閉包才會導致內存洩漏。四、內存dump瀏覽器中抓取內存的dump相對來說簡單些，直接通過谷歌瀏覽器的調試工具找到memory對應的tab頁面，然後點擊Load即可開始抓取內存dump，如:
  • 《Linux鐵三角之內存管理》在線視頻課程
    主要目的：理解硬體訪問內存的原理,MMU和頁表；澄清Linux內核ZONE，buddy，slab管理；澄清用戶空間malloc與內核關係，Lazy分配機制；澄清進程的內存消耗的vss,rss,pss,uss概念；澄清內存耗盡的OOM行為；澄清文件背景頁面與匿名頁，page cache與swap；澄清內存的回收、dirty page的寫回，
  • 獨家|Linux進程內存用量分析之堆內存篇
    本文將介紹幾種內存洩漏檢測工具，並通過實際例子介紹一種分析堆內存佔用量的工具和方法，幫助定位內存膨脹問題。背景進程的內存管理是每一個開發者必須要考慮的問題，對於C++程序進程來說，出現問題很多情況下都與內存掛鈎。進程崩潰問題通常可以使用gdb等調試工具輕鬆排查並解決。
  • Android 內存洩漏探討
    我會從 java 內存洩漏的基礎知識開始，並通過具體例子來說明 Android 引起內存洩漏的各種原因，以及如何利用工具來分析應用內存洩漏，最後再做總結。篇幅有些長，大家可以分幾節來看！了解了 Java 的內存分配之後，我們再來看看 Java 是怎麼管理內存的。Java是如何管理內存Java的內存管理就是對象的分配和釋放問題。在 Java 中，程式設計師需要通過關鍵字 new 為每個對象申請內存空間 (基本類型除外)，所有的對象都在堆 (Heap)中分配空間。另外，對象的釋放是由 GC 決定和執行的。
  • C語言中的指針和內存洩漏
    這些的確是消耗了開發人員大多數調試時間的事項。指針和內存洩漏對某些開發人員來說似乎令人畏懼，但是一旦您了解了指針及其關聯內存操作的基礎，它們就是您在 C 語言中擁有的最強大工具。本文將與您分享開發人員在開始使用指針來編程前應該知道的秘密。
  • 【開源工具】推薦一款Linux下內存檢測工具:valgrind
    內存洩漏問題可以說是C/C++工程師無法避免的問題，系統編程中一個重要的方面就是有效地處理與內存相關的問題。
  • 檢查是否內存洩漏的方法
    目錄前言一個簡單的內存洩漏檢查內存洩露的方法方法內存洩漏時，內存的消耗沒有內存洩露時的內存消耗前言這兩天抽空把之前買的這門課給看了看，課程很好，有興趣的也可以看一看：具體的課程總結過幾天寫一寫，這篇推送就說一下從這課上學到的一個技巧吧：一個檢查內存洩露的方法。
  • 【221期】面試官:談談內存洩漏和內存溢出的聯繫與區別
    2、一次內訓洩漏似乎不會有大的影響，但內存洩漏後堆積的結果就是內存溢出。3、內存洩漏具有隱蔽性，積累性的特徵，比其他內存非法訪問錯誤更難檢測。這是因為內存洩漏產生的原因是內存塊未被釋放，屬於遺漏型缺陷而不是過錯型缺陷。
  • JavaScript內存管理機制以及四種常見的內存洩漏解析
    而這第三篇文章將討論另一個很重要的主題——內存管理。隨著程式語言變得越來越成熟越來越複雜，開發人員很容易忽視這一問題。同時，本文還將提供一些處理JavaScript內存洩漏的技巧，既能確保SessionStack不會出現內存洩漏，也不會增加web應用程式的內存佔用。
  • Android 輕鬆解決內存洩漏
    什麼是內存洩漏？內存洩漏的危害運行性能的問題: Android在運行的時候，如果內存洩漏將導致其他組件可用的內存變少，一方面會使得GC的頻率加劇，在發生GC的時候，所有進程都必須進行等待，GC的頻率越多，從而用戶越容易感知到卡頓。
  • vue中的eventBus會產生內存洩漏嗎
    引入本文介紹了eventBus的實現原理，並介紹它如何在vue中使用，並舉了一個具體的例子來說明，如果使用不當，它會造成內存洩漏。fr=aladdin內容在vue使用eventBus;使用不當的問題：多次執行回調；內存洩漏；解決方案
  • 嵌入式Linux內存管理的一些知識點總結
    這個內存管理的知識點還真的需要我們專門的去理解一下，今天大家一起來學習學習嵌入式Linux內存管理的知識。1.不涉及linux內核的彙編知識，僅C語言層面解析1.回答：彙編主要處理的是寄存器地址(包括內容)的計算，進行一部分的地址轉換工作(當然，它是重要的);C語言處理了極大部分的系統內存管理工作。