A. c語言內存泄漏如何定位
用gstack長期觀察函數調用棧，分析調用情況與內存增長的關系，找到與內存泄露相關的函數，重點分析。
C語言是一門面向過程的、抽象化的通用程序設計語言，廣泛應用於底層開發。C語言能以簡易的方式編譯、處理低級存儲器。C語言是僅產生少量的機器語言以及不需要任何運行環境支持便能運行的高效率程序設計語言。
盡管C語言提供了許多低級處理的功能，但仍然保持著跨平台的特性，以一個標准規格寫出的C語言程序可在包括類似嵌入式處理器以及超級計算機等作業平台的許多計算機平台上進行編譯。
C語言是一門面向過程的計算機編程語言，與C++、C#、Java等面向對象編程語言有所不同。C語言的設計目標是提供一種能以簡易的方式編譯、處理低級存儲器、僅產生少量的機器碼以及不需要任何運行環境支持便能運行的編程語言。
C語言描述問題比匯編語言迅速、工作量小、可讀性好、易於調試、修改和移植，而代碼質量與匯編語言相當。C語言一般只比匯編語言代碼生成的目標程序效率低10%-20%。因此，C語言可以編寫系統軟體。
B. C語言內存泄露的問題
malloc是向系統申請內存的，因為你用的系統在你的程序退出後自動釋放的內存，所以沒有造成泄露問題。
這種情況下，你的程序不退出，而是不斷地申請內存，部分釋放內存或完全不釋放內存，才會造成泄露。
C. C語言指針問題--填空題 請問：為什麼會發生內存泄露
你在getmemory函數里 用malloc 對str指針分配了空間，test函數結束是，你沒有釋放分配的空間，當然內存泄露了。
在printf完後，加一句 free(str);
D. C語言指針 內存泄漏
for (i=0;i<10;i++)
{
char *p=(char *)malloc(nSize *sizeof(char));
i++;
}
調用了10次malloc，就分配了10份空間，每次循環，你之前分配空間的地址都會被新一次分配的地址覆蓋，繼而丟失了。
最後你只是釋放了一次，也就是9次都丟失了，造成內存泄露
E. c語言內存使用問題
補充一下：樓主說的「泄露」是錯別字，本為「泄漏」，這下你再看應該好理解了吧。
================================================
1: 因為使用 static 聲明的變數在全局中只有一個實例，也就是說如果你這樣用的話：
char * a = itoa(10);
char * b = itoa(9);
之後，實際上 a 和 b 指向的是同一個 static 數組，它們當前值都是 "9"。
2: 內存泄漏說白了就是你使用了 new 在堆中創建了內容，而使用之後沒有使用 delete 將之前申請的內存釋放，這樣申請的內存就算沒有指向它的指針(也就是再也沒有調用的時候)，內存也依然被佔用，這就是內存泄漏
他的方法就是叫你每次調用這個 itoa 的時候 new char[20] 這個樣子。這樣的話你不知道什麼時候應該把內存釋放掉，很容易造成內存泄漏。
舉個例子：
char *itoa (int n)
{
char* retbuf = new char[20];
sprintf(retbuf, "%d", n);
return retbuf;
}
然後你調用
char * a = itoa(10);
如果要使這段內存脫鉤之前不先釋放:
delete [] a;
然後使他脫鉤
a = itoa(9);
那麼第一次調用的時候 new 出來的內存就泄漏掉了。。
F. 在Linux中運行的C程序出現內存泄漏現象，怎麼解決
內存泄漏指由於疏忽或錯誤造成程序未能釋放已經不再使用的內存的情況。內存泄漏並非指內存在物理上的消失，而是應用程序分配某段內存後，由於設計錯誤，失去了對該段內存的控制，因而造成了內存的浪費。
可以使用相應的軟體測試工具對軟體進行檢測。
1. ccmalloc－Linux和Solaris下對C和C++程序的簡單的使用內存泄漏和malloc調試庫。
2. Dmalloc－Debug Malloc Library.
3. Electric
Fence－Linux分發版中由Bruce Perens編寫的malloc()調試庫。
4. Leaky－Linux下檢測內存泄漏的程序。
5. LeakTracer－Linux、Solaris和HP-UX下跟蹤和分析C++程序中的內存泄漏。
6. MEMWATCH－由Johan
Lindh編寫，是一個開放源代碼C語言內存錯誤檢測工具，主要是通過gcc的precessor來進行。
7. Valgrind－Debugging and profiling Linux programs, aiming at
programs written in C and C++.
8. KCachegrind－A visualization tool for the profiling data
generated by Cachegrind and Calltree.
9. Leak
Monitor－一個Firefox擴展，能找出跟Firefox相關的泄漏類型。
10. IE Leak Detector
(Drip/IE Sieve)－Drip和IE Sieve leak
detectors幫助網頁開發員提升動態網頁性能通過報告可避免的因為IE局限的內存泄漏。
11. Windows Leaks
Detector－探測任何Win32應用程序中的任何資源泄漏(內存，句柄等)，基於Win API調用鉤子。
12. SAP Memory
Analyzer－是一款開源的JAVA內存分析軟體，可用於輔助查找JAVA程序的內存泄漏，能容易找到大塊內存並驗證誰在一直佔用它，它是基於Eclipse
RCP(Rich Client Platform)，可以下載RCP的獨立版本或者Eclipse的插件。
13. DTrace－即動態跟蹤Dynamic
Tracing，是一款開源軟體，能在Unix類似平台運行，用戶能夠動態檢測操作系統內核和用戶進程，以更精確地掌握系統的資源使用狀況，提高系統性能，減少支持成本，並進行有效的調節。
14. IBM Rational PurifyPlus－幫助開發人員查明C/C++、託管.NET、Java和VB6代碼中的性能和可靠性錯誤。PurifyPlus
將內存錯誤和泄漏檢測、應用程序性能描述、代碼覆蓋分析等功能組合在一個單一、完整的工具包中。
15. Parasoft Insure++－針對C/C++應用的運行時錯誤自動檢測工具，它能夠自動監測C/C++程序，發現其中存在著的內存破壞、內存泄漏、指針錯誤和I/O等錯誤。並通過使用一系列獨特的技術（SCI技術和變異測試等），徹底的檢查和測試我們的代碼，精確定位錯誤的准確位置並給出詳細的診斷信息。能作為Microsoft
Visual C++的一個插件運行。
16. Compuware DevPartner for Visual C++ BoundsChecker
Suite－為C++開發者設計的運行錯誤檢測和調試工具軟體。作為Microsoft Visual Studio和C++ 6.0的一個插件運行。
17. Electric Software GlowCode－包括內存泄漏檢查，code
profiler，函數調用跟蹤等功能。給C++和.Net開發者提供完整的錯誤診斷，和運行時性能分析工具包。
18. Compuware DevPartner Java
Edition－包含Java內存檢測,代碼覆蓋率測試,代碼性能測試,線程死鎖,分布式應用等幾大功能模塊。
19. Quest JProbe－分析Java的內存泄漏。
20. ej-technologies JProfiler－一個全功能的Java剖析工具，專用於分析J2SE和J2EE應用程序。它把CPU、執行緒和內存的剖析組合在一個強大的應用中。JProfiler可提供許多IDE整合和應用伺服器整合用途。JProfiler直覺式的GUI讓你可以找到效能瓶頸、抓出內存泄漏、並解決執行緒的問題。4.3.2注冊碼：A-G666#76114F-1olm9mv1i5uuly#0126
21. BEA JRockit－用來診斷Java內存泄漏並指出根本原因，專門針對Intel平台並得到優化，能在Intel硬體上獲得最高的性能。
22. SciTech Software AB .NET Memory
Profiler－找到內存泄漏並優化內存使用針對C#，VB.Net，或其它.Net程序。
23. YourKit .NET & Java Profiler－業界領先的Java和.NET程序性能分析工具。
24. AutomatedQA AQTime－AutomatedQA的獲獎產品performance profiling和memory
debugging工具集的下一代替換產品，支持Microsoft, Borland, Intel, Compaq 和
GNU編譯器。可以為.NET和Windows程序生成全面細致的報告，從而幫助您輕松隔離並排除代碼中含有的性能問題和內存/資源泄露問題。支持.Net
1.0,1.1,2.0,3.0和Windows 32/64位應用程序。
25. JavaScript Memory Leak Detector－微軟全球產品開發歐洲團隊(Global Proct
Development- Europe team, GPDE)
發布的一款調試工具，用來探測JavaScript代碼中的內存泄漏，運行為IE系列的一個插件。
G. 怎樣發現內存泄露
一、內存泄漏的檢查方法：
1.ccmalloc－Linux和Solaris下對C和C++程序的簡單的使用內存泄漏和malloc調試庫。
2.Dmalloc－Debug Malloc Library.
3.Electric Fence－Linux分發版中由Bruce Perens編寫的malloc()調試庫。
4.Leaky－Linux下檢測內存泄漏的程序。
5.LeakTracer－Linux、Solaris和HP-UX下跟蹤和分析C++程序中的內存泄漏。
6.MEMWATCH－由Johan Lindh編寫，是一個開放源代碼C語言內存錯誤檢測工具，主要是通過gcc的precessor來進行。
7.Valgrind－Debugging and profiling Linux programs, aiming at programs written in C and C++.
8.KCachegrind－A visualization tool for the profiling data generated by Cachegrind and Calltree.
9.IBM Rational PurifyPlus－幫助開發人員查明C/C++、託管.NET、Java和VB6代碼中的性能和可靠性錯誤。PurifyPlus 將內存錯誤和泄漏檢測、應用程序性能描述、代碼覆蓋分析等功能組合在一個單一、完整的工具包中。
二、內存泄漏的簡單介紹：
內存泄漏也稱作「存儲滲漏」，用動態存儲分配函數動態開辟的空間，在使用完畢後未釋放，結果導致一直占據該內存單元。直到程序結束。（其實說白了就是該內存空間使用完畢之後未回收）即所謂內存泄漏。
內存泄漏形象的比喻是「操作系統可提供給所有進程的存儲空間正在被某個進程榨乾」，最終結果是程序運行時間越長，佔用存儲空間越來越多，最終用盡全部存儲空間，整個系統崩潰。所以「內存泄漏」是從操作系統的角度來看的。這里的存儲空間並不是指物理內存，而是指虛擬內存大小，這個虛擬內存大小取決於磁碟交換區設定的大小。由程序申請的一塊內存，如果沒有任何一個指針指向它，那麼這塊內存就泄漏了。
H. 哪些情況會內存泄漏
1、資源釋放問題
。 Android 程序代碼的問題，長期保持某些資源，如 Context、Cursor、IO 流的引用，資源得不到釋放造成內存泄露。
2、對象內存過大問題
保存了多個耗用內存過大的對象（如 Bitmap、XML 文件），造成內存超出限制。
3、static 關鍵字的使用問題
static 是 Java 中的一個關鍵字，當用它來修飾成員變數時，那麼該變數就屬於該類，而不是該類的實例。所 以用 static 修飾的變數，它的生命周期是很長的，如果用它來引用一些資源耗費過多的實例（Context 的情況最 多），這時就要謹慎對待了。
public class ClassName { private static Context mContext; //省略 }
1
1
以上的代碼是很危險的，如果將 Activity 賦值到 mContext 的話。那麼即使該 Activity 已經 onDestroy，但是由 於仍有對象保存它的引用，因此該 Activity 依然不會被釋放。
我們舉 Android 文檔中的一個例子。
private static Drawable sBackground;
@Override protected void onCreate(Bundle state) {
super.onCreate(state);
TextView label = new TextView(this); //getApplicationContext label.setText("Leaks are bad");
if (sBackground == null) {
sBackground = getDrawable(R.drawable.large_bitmap);
}
label.setBackgroundDrawable(sBackground); setContentView(label);
}
1
2
3
4
5
6
7
8
9
1
2
3
4
5
6
7
8
9
sBackground 是一個靜態的變數，但是我們發現，我們並沒有顯式的保存 Context 的引用，但是，當 Drawable 與 View 連接之後，Drawable 就將 View 設置為一個回調，由於 View 中是包含 Context 的引用的，所以，實際 上我們依然保存了 Context 的引用。這個引用鏈如下： Drawable->TextView->Context 所以，最終該 Context 也沒有得到釋放，發生了內存泄露。
針對 static 的解決方案
① 應該盡量避免 static 成員變數引用資源耗費過多的實例，比如 Context。
② Context 盡量使用 ApplicationContext，因為 Application 的 Context 的生命周期比較長，引用它不會 出現內存泄露的問題。 ③ 使用 WeakReference 代替強引用。比如可以使用 WeakReference mContextRef;
4、線程導致內存溢出
線程產生內存泄露的主要原因在於線程生命周期的不可控。我們來考慮下面一段代碼。
。
public class MyActivity extends Activity {
@Override
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.main);
new MyThread().start();
}
private class MyThread extends Thread{
@Override
public void run() {
super.run(); //do somthing while(true)
}
}
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
1
2
3
4
5
6
7
8
9
10
11
12
13
14
這段代碼很平常也很簡單，是我們經常使用的形式。我們思考一個問題：假設 MyThread 的 run 函數是一個很費 時的操作，當我們開啟該線程後，將設備的橫屏變為了豎屏，一 般情況下當屏幕轉換時會重新創建 Activity，按照我 們的想法，老的 Activity 應該會被銷毀才對，然而事實上並非如此。 由於我們的線程是 Activity 的內部類，所以 MyThread 中保存了 Activity 的一個引用，當 MyThread 的 run 函 數沒有結束時，MyThread 是不會被銷毀的，因此它所引用的老的 Activity 也不會被銷毀，因此就出現了內存泄露的 問題。有些人喜歡用 Android 提供的 AsyncTask，但事實上 AsyncTask 的問題更加嚴重，Thread 只有在 run 函數不結 束時才出現這種內存泄露問題，然而 AsyncTask 內部的實現機制是運用了 ThreadPoolExcutor,該類產生的 Thread 對 象的生命周期是不確定的，是應用程序無法控制的，因此如果 AsyncTask 作為 Activity 的內部類，就更容易出現內存 泄露的問題。
針對這種線程導致的內存泄露問題的解決方案：
第一、將線程的內部類，改為靜態內部類（因為非靜態內部類擁有外部類對象的強引用，而靜態類則不擁有）。
第二、在線程內部採用弱引用保存 Context 引用。
I. C語言調用外部EXE程序，用的這個ShellExecute，出現內存泄漏怎麼解決
外部程序內存泄露怎麼改？只能怪該程序的開發者太粗心。你可以選擇不使用它，而不是嘗試動態修改它，因為這會比再開發要難得多。
當然你可以對它進行一些限制，比如說完成特定功能後強制terminateprocess