内存泄漏

内存泄露是指分配出去的内存无法回收。

内存泄露是指由于疏忽或者错误导致程序在运行完之后没有正确的释放已经不再使用内存，由于设计的错误，失去了对该段内存的控制，从而造成内存的浪费。

一般我们常说的内存泄露是指堆内存泄露，使用完后要显式的释放内存。否则这块内存一直被占着，我们就说内存泄露了。

而内存溢出是指程序要求的内存超出了系统所能分配给的范围。

内存泄露可以通过修改程序逻辑或者设计来避免发生，但是内存溢出必须修改运行参数，分配给足够的内存给程序才可以。

Swap（交换分区）-->虚拟内存(不经常用的)
si: 每秒从交换区写到内存（物理内存）的大小
so: 每秒写入交换区的内存大小

交换分区，英文的说法是swap，意思是“交换”、“实物交易”功能就是在内存不够的情况下，操作系统先把内存中暂时不用的数据，存到硬盘的交换空间，腾出内存来让别的程序运行，和Windows的虚拟内存（pagefile.sys）的作用是一样的。

一: 内存泄漏

内存泄漏是编程中常常见到的一个问题，内存泄漏往往会一种奇怪的方式来表现出来,基本上每个程序都表现出不同的方式。但是一般最后的结果只有两个，一个是程序当掉，一个是系统内存不足。还有一种就是比较介于中间的结果程序不会当，但是系统的反映时间明显降低，需要定时的Reboot才会正常。

有一个很简单的办法来检查一个程序是否有内存泄漏。就是是用Windows的任务管理器(Task Manager)。运行程序，然后在任务管理器里面查看 “内存使用”和”虚拟内存大小”两项，当程序请求了它所需要的内存之后，如果虚拟内存还是持续的增长的话，就说明了这个程序有内存泄漏问题。当然如果内存泄漏的数目非常的小，用这种方法可能要过很长时间才能看的出来。

当然最简单的办法大概就是用CompuWare的BoundChecker 之类的工具来检测了，不过这些工具的价格对于个人来讲稍微有点奢侈了。

如果是已经发布的程序，检查是否有内存泄漏是又费时又费力。所以内存泄漏应该在Code的生成过程就要时刻进行检查。

二: 原因

内存泄漏产生的原因一般是三种情况：

1. 分配完内存之后忘了回收；

2. 程序Code有问题，造成没有办法回收；

3. 某些API函数操作不正确，造成内存泄漏。

1. 内存忘记回收，这个是不应该的事情。但是也是在代码种很常见的问题。分配内存之后，用完之后，就一定要回收。如果不回收，那就造成了内存的泄漏，造成内存泄漏的Code如果被经常调用的话，那内存泄漏的数目就会越来越多的。从而影响整个系统的运行。比如下面的代码：

for (int =0;I<100;I++)

{

Temp = new BYTE[100];

}

就会产生 100*100Byte的内存泄漏。

2. 在某些时候，因为代码上写的有问题，会导致某些内存想回收都收不回来，比如下面的代码：

Temp1 = new BYTE[100];

Temp2 = new BYTE[100];

Temp2 = Temp1;

这样，Temp2的内存地址就丢掉了，而且永远都找不回了，这个时候Temp2的内存空间想回收都没有办法。

3. API函数应用不当，在Windows提供API函数里面有一些特殊的API，比如FormatMessage。如果你给它参数中有FORMAT_MESSAGE_ALLOCATE_BUFFER，它会在函数内部New一块内存Buffer出来。但是这个 buffer需要你调用LocalFree来释放。如果你忘了，那就会产生内存泄漏。

java内存泄漏

　Java的内存管理就是对象的分配和释放问题。在Java中，程序员需要通过关键字new为每个对象申请内存空间（基本类型除外），所有的对象都在堆（Heap）中分配空间。另外，对象的释放是由GC决定和执行的。在Java中，内存的分配是由程序完成的，而内存的释放是有GC完成的，这种收支两条线的方法确实简化了程序员的工作。但同时，它也加重了JVM的工作。这也是Java程序运行速度较慢的原因之一。因为，GC为了能够正确释放对象，垃圾收集器(garbage collector，GC)必须监控每一个对象的运行状态，包括对象的申请、引用、被引用、赋值等，GC都需要进行监控

　最后一个重要的问题，就是如何检测Java的内存泄漏。目前，我们通常使用一些工具来检查Java程序的内存泄漏问题。市场上已有几种专业检查Java内存泄漏的工具，它们的基本工作原理大同小异，都是通过监测Java程序运行时，所有对象的申请、释放等动作，将内存管理的所有信息进行统计、分析、可视化。开发人员将根据这些信息判断程序是否有内存泄漏问题。这些工具包括 OptimizeitProfiler，JProbeProfiler，JinSight，Rational公司的Purify等。