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