[Java] Memory （ZT）

Part 1: The Truth About Garbage Collection



Part 2:
http://hi.baidu.com/free952711/blog/item/e150bbeda9cb90222df53483.html


Memory  Leak:

第一：
很多人在谈论内存泄露问题，当然对于c/c++来说，这个应该是老掉牙的问题，但是很多Java人员也越来越多得讨论这个问题，我这里写个小结，希望对大 家有一定的参考价值。
　　内存泄漏的慨念
　　1.c/c++是程序员自己治理内存，Java内存是由GC自动回收的。
　　我虽然不是很熟悉C++，不过这个应该没有犯常识性错误吧。
　　2.什么是内存泄露?
　　内存泄露是指系统中存在无法回收的内存，有时候会造成内存不足或系统崩溃。
　　在C/C++中分配了内存不释放的情况就是内存泄露。
　　3.Java存在内存泄露
　　我们必须先承认这个，才可以接着讨论。虽然Java存在内存泄露，但是基本上不用很关心它，非凡是那些对代码本身就不讲究的就更不要去关心这个了。
　　Java中的内存泄露当然是指：存在无用但是垃圾回收器无法回收的对象。而且即使有内存泄露问题存在，也不一定会表现出来。
　　4.Java中参数都是传值的。
　　对于基本类型，大家基本上没有异议，但是对于引用类型我们也不能有异议。
Java是如何管理内存
为了判断Java中是否有内存泄露，我们首先必须了解Java是如何管理内存的。Java的内存管理就是对象的分配和释放 问题。在Java中，程序 员需要通过关键字new为每个对象申请内存空间 (基本类型除外)，所有的对象都在堆 (Heap)中分配空间。另外，对象的释放是由GC决定和执行的。在Java中，内存的分配是由程序完成的，而内存的释放是有GC完成的，这种收支两条线 的方法确实简化了程序员的工作。但同时，它也加重了JVM的工作。这也是Java程序运行速度较慢的原因之一。因为，GC为了能够正确释放对象，GC必须 监控每一个对象的运行状态，包括对象的申请、引用、被引用、赋值等，GC都需要进行监控。
监视对象状态是为了更加准确地、及时地释放对象，而释放 对象的根本原则就是该对象不再被引用。
为了更好理解GC的工作原理，我们可以将对象考虑为有向图的顶点，将引用关系考虑为图的有向边，有向边从引 用者指向被引对象。另外，每个线程对象可 以作为一个图的起始顶点，例如大多程序从main进程开始执行，那么该图就是以main进程顶点开始的一棵根树。在这个有向图中，根顶点可达的对象都是有 效对象，GC将不回收这些对象。如果某个对象 (连通子图)与这个根顶点不可达(注意，该图为有向图)，那么我们认为这个(这些)对象不再被引用，可以被GC回收。
以下，我们举一个例子说明如 何用有向图表示内存管理。对于程序的每一个时刻，我们都有一个有向图表示JVM的内存分配情况。以下右图，就是左边程序运行到第6行的示意图。

Java 使用有向图的方式进行内存管理，可以消除引用循环的问题，例如有三个对象，相互引用，只要它们和根进程不可达的，那么GC也是可以回收它们 的。这种方式的优点是管理内存的精度很高，但是效率较低。另外一种常用的内存管理技术是使用计数器，例如COM模型采用计数器方式管理构件，它与有向图相 比，精度行低(很难处理循环引用的问题)，但执行效率很高。

　　Java内存泄露情况
　　JVM回收算法是很复杂的，我也不知道他们怎么实现的，但是我只知道他们要实现的就是：对于没有被引用的对象是可以回收的。所以你要造成内存泄露就要 做到：
　　持有对无用对象的引用!
　　不要以为这个很轻易做到，既然无用，你怎么还会持有它的引用? 既然你还持有它，它怎么会是无用的呢?
　　我实在想不到比那个堆栈更经典的例子了,以致于我还要引用别人的例子，下面的例子不是我想到的，是书上看到的，当然假如没有在书上看到，可能过一段时 间我自己也想的到，可是那时我说是我自己想到的也没有人相信的。
　　public class Stack {
　　private Object[] elements=new Object[10];
　　private int size = 0;
　　public void push(Object e){
　　ensureCapacity();
　　elements[size++] = e;
　　}
　　public Object pop(){
　　if( size == 0)
　　throw new EmptyStackException();
　　return elements[--size];
　　}
　　private void ensureCapacity(){
　　if(elements.length == size){
　　Object[] oldElements = elements;
　　elements = new Object[2 * elements.length+1];
　　System.arraycopy(oldElements,0, elements, 0, size);
　　}
　　}
　　}
　　上面的原理应该很简单，假如堆栈加了10个元素，然后全部弹出来，虽然堆栈是空的，没有我们要的东西，但是这是个对象是无法回收的，这个才符合了内存 泄露的两个条件：无用，无法回收。
　　但是就是存在这样的东西也不一定会导致什么样的后果，假如这个堆栈用的比较少，也就浪费了几个K内存而已，反正我们的内存都上G了，哪里会有什么影 响，再说这个东西很快就会被回收的，有什么关系。下面看两个例子。
　　例子1
　　public class Bad{
　　public static Stack s=Stack();
　　static{
　　s.push(new Object());
　　s.pop(); //这里有一个对象发生内存泄露
　　s.push(new Object()); //上面的对象可以被回收了，等于是自愈了
　　}
　　}
　 　因为是static，就一直存在到程序退出，但是我们也可以看到它有自愈功能，就是说假如你的Stack最多有100个对象，那么最多也就只有100个 对象无法被回收其实这个应该很轻易理解，Stack内部持有100个引用，最坏的情况就是他们都是无用的，因为我们一旦放新的进取，以前的引用自然消失！
　　例子2
　　public class NotTooBad{
　　public void doSomething(){
　　Stack s=new Stack();
　　s.push(new Object());
　　//other code
　　s.pop();//这里同样导致对象无法回收,内存泄露.
　　}//退出方法,s自动无效,s可以被回收,Stack内部的引用自然没了,所以
　　//这里也可以自愈,而且可以说这个方法不存在内存泄露问题,不过是晚一点
　　//交给GC而已,因为它是封闭的,对外不开放,可以说上面的代码99.9999%的
　　//情况是不会造成任何影响的,当然你写这样的代码不会有什么坏的影响,但是
　　//绝对可以说是垃圾代码!没有矛盾吧,我在里面加一个空的for循环也不会有
　　//什么太大的影响吧,你会这么做吗?
　　}
　 　上面两个例子都不过是小打小闹,但是C/C++中的内存泄露就不是Bad了,而是Worst了。他们假如一处没有回收就永远无法回收,频繁的调用这个方 法内存不就用光了!因为Java还有自愈功能(我自己起的名字,还没申请专利),所以Java的内存泄露问题几乎可以忽略了,但是知道的人就不要犯了。
　　不知者无罪!Java存在内存泄露,但是也不要夸大其辞。假如你对Java都不是很熟,你根本就不用关心这个,我说过你无意中写出内存泄露的例子就像 你中一千万一样概率小,开玩笑了,其实应该是小的多的多!
　　而且即使你有幸写出这样的代码，中奖了!基本上都是一包洗衣粉，不会让你发财，对系统没有什么大的影响。
　　杞人忧天的情况
　　1.无话可说型
　　Object obj=new Object();
　　obj=null;
　　//这个完全多此一举,因为退出了作用范围，对象的引用自动消失
　　//不要在你的程序中出现这样的语句，没有错，但是就是不雅观
　　2.思考不对型
　　void func(Object o){
　　o=new Object();
　　return
　　}
　　当我们知道Java参数是传值，就知道上面的方法什么也没错，就是申请了一个对象然后再丢给GC。因为是传值，这里的o是一个调用时候的拷贝,会不会 无法回收？不就是拷贝吗，退出方法什么都没了，这个对象怎么会留的住。
　　3.尽量避免型
　　class A{
　　B b=new B(this);
　　}
　　class B{
　　A a;
　　B(A a){this.a=a;}
　　}
　　这个存在互相引用，可能导致孤岛现象，但是这个不会造成内存泄露不过我自己觉得这个会降低GC的效率，就从我的智力来看，我觉得这种情况比一般情况难 以判定怎么回收!当然GC比我聪明，不过应该也要动一点脑子吧。

在把组件提交到集成阶段之前，每个开发人员必须对他们的组件进行性能单元测试。传统的单元测试仅仅重视功能而忽略性能。
在单元测试期间，性能单元测试意味着需要用以下的工具分析组件：
Memory profiler
Code profiler
Coverage profiler
Memory profiler 在用例开始前和在用例结束后运行垃圾回收并且记录堆的快照。从这些数据中，我们能看到用例的内存影响及该用例在内存中留下的具体对象列表。开发人员需要检 查那些对象以确认在用例执行完成后那些对象就应该保留在内存中。当用例完成后，如果对象被疏忽而留在堆中，那么这就是Java内存泄漏，并且我们这些称为 游离对象，有时也可称为遗留对象引用。
下一个需要寻找的内存问题称为对象循环。在用例执行期间，所记录的细粒度的堆的采样信息，结合创建和删除的 数量，说明了对象被创建和删除的次数。如果对象 被迅速地创建并删除，那么它将给JVM带来非常大的压力。每个被创建及删除的对象仅能由垃圾搜集回收，并且对象循环显著地增加垃圾回收的频率。这种情况通 常发生在一个循环或嵌套循环内部的对象创建的情况。
让我们看看以下的代码:
for( int i=0; i for( int j=0; j int threshold = system.getThreshold();
if( object[i].getThing() - object2[j].getOtherThing() > threshold ) {
// Do something
}
}
}

在这个例子中，外部循环遍历object中的所有项目，并且每个项目都遍历object2的所有项目。如果object包含1000个项目并且 object2也包含了1000个项目，那么被定义在循环内部的代码将被执行1000 *1000次，或1百万次。在这种代码下，阈限变量将每次在内部循环运行时(当该对象的引用超出作用域范围时对象将被销毁) 被分配和销毁。如果你在Memory profiler里看到这个代码，你将看到一百万个阈限实例被创建并被销毁。
代码应该用如下的方式重写来消 除这种情况:
int threshold = system.getThreshold();

int threshold = system.getThreshold();

for( int j=0; j
if( object[i].getThing() - object2[j].getOtherThing() > threshold ) {

// Do something

}

}

}

现在，对与一百万次循环，阈限变量只分配一次。阈限变量的影响从至关重要变为微不足道。
在基于Web应用中，我们经常看到的关于对象循环的场景 是在在请求的上下文中创建对象。在单次使用情况下，这并不是问题，不过一但当用户的负载显著增加 时，这个问题就很快变得很明显。你必须做出的决定是，这个对象是否需要基于每个请求创建，或者如果一旦它被创建，那么可被缓冲以被随后的请求重用。如果对 这个问题的回答是后者，那么你可以消除该对象的循环使用问题。图1显示当对象循环发生时堆的视图。

eclipse 有启动参数里设置jvm大小，因为eclipse运行时自己也需要jvm,所以eclipse.ini里设置的jvm大小不是具体某个程序运行时所用 jvm的大小，这和具体程序运行的jvm大小无关。
那么怎么才能设置某个程序的jvm大小呢（当然控制台运行的话不会存在这个问题，如：java -Xms256m -Xmx1024m classname，这样就可以把当前程序的jvm大小给设定）？
因为eclipse里默认的一个程序的jvm配置为：-Xms8m -Xmx128m，所以我们的处理耗内存比较大时需要手动调整一下，以便不会内存溢出。具体的设置方法为：
选中被运行的类，点击菜单 ‘Run->Run Configurations...’，选择(x)=Argument标签页下的vm arguments框里输入 -Xmx512m, 保存运行就ok了.


我经常处理大的浮点矩阵，所以我用的是-Xmx1024m



第二：
1 引言
     Java的一个重要优点就是通过垃圾收集器GC （Garbage Collection）自动管理内存的回收，程序员不需要通过调用函数来释放内存。因此，很多程序员 认为Java 不存在内存泄漏问题，或者认为即使有内存泄漏也不是程序的责任，而是GC 或JVM的问题。其实，这种想法是不正确的，因为Java 也存在内存泄漏，但它的表现与C++不同。如果正在开发的Java 代码要全天24 小时在服务器上运行，则内存漏洞在此处的影响就比在配置实用程序中的影 响要大得多，即使最小的漏洞也会导致JVM耗尽全部可用内存。另外，在很多嵌入式系统中，内存的总量非常有限。在相反的情况下，即便程序 的生存期较短，如果存在分配大量临时对象（或者若干吞噬大量内存的对象）的任何Java 代码，而且当不再需要这些对象时也没有取消对它们的引用，则仍然可能达到内存极限。


2 Java 内存回收机制
     Java 的内存管理就是对象的分配和释放问题。分配内存的方式多种多样，取决于该种语言的语法结构。但不论是哪一种语言的内存分配方式，最后都要返回所分配的内存 块的起始地址，即返回一个指针到内存块的首地址。在Java 中所有对象都是在堆（Heap）中分配的，对象的创建通常都是采用new或者是反射的方式，但对象释放却有直接的手段，所以对象的回收都是由Java虚拟 机通过垃圾收集器去完成的。这种收支两条线的方法确实简化了程序员的工作，但同时也加重了JVM的工作，这也是Java 程序运行速度较慢的原因之一。因为，GC 为了能够正确释放对象，GC 必须监控每一个对象的运行状态，包括对象的申请、引用、被引用、赋值等，GC 都需要进行监控。**对象状态是为了更加准确地、及时地释放对象，而释放对象的根本原则就是该对象不再被引用。Java 使用有向图的方式进行内存管理，可以消除引用循环的问题，例如有三个对象，相互引用，只要它们和根进程不可达，那么GC 也是可以回收它们的。在Java 语言中，判断一块内存空间是否符合垃圾收集器收集标准的标准只有两个：一个是给对象赋予了空值null，以下再没有调用过，另一个是给对象赋予了新值，即 重新分配了内存空间。

3 Java 中的内存泄漏

3.1 Java 中内存泄漏与C++的区别
    在Java 中，内存泄漏就是存在一些被分配的对象，这些对象有下面两个特点，首先，这些对象是可达的，即在有向图中，存在通路可以与其相连；其次，这些对象是无用 的，即程序以后不会再使用这些对象。如果对象满足这两个条件，这些对象就可以判定为Java 中的内存泄漏，这些对象不会被GC 所回收，然而它却占用内存。在C++中，内存泄漏的范围更大一些。有些对象被分配了内存空间，然后却不可达，由于C++中没有GC，这些内存将永远收不回 来。在Java 中，这些不可达的对象都由GC 负责回收，因此程序员不需要考虑这部分的内存泄漏。通过分析，可以得知，对于C++，程序员需要自己管理边和顶点，而对于Java 程序员只需要管理边就可以了（不需要管理顶点
的释放）。通过这种方式，Java 提高了编程的效率。

3.2 内存泄漏示例
3.2.1 示例1
   在这个例子中，循环申请Object 对象，并将所申请的对象放入一个Vector 中，如果仅仅释放引用本身，那么Vector 仍然引用该对象，所以这个对象对GC 来说是不可回收的。因此，如果对象加入到Vector 后，还必须从Vector 中删除，最简单的方法就是将Vector对象设置为null。
Vector v = new Vector(10);
for (int i = 1; i<100; i++)
{Object o = new Object();
v.add(o);
o = null;
}//

此时，所有的Object 对象都没有被释放，因为变量v 引用这些对象。实际上无用，而还被引用的对象，GC 就无能为力了（事实上GC 认为它还有用），这一点是导致内存泄漏最重要的原因。

(1)如果要释放对象，就必须使其的引用记数为0，只有那些不再被引用的对象才能被释放，这个原理很简单，但是很重要，是导致内存泄漏的基本原因，也是解决内存泄漏方法的宗旨；
(2)程序员无须管理对象空间具体的分配和释放过程，但必须要关注被释放对象的引用记数是否为0；
(3)一个对象可能被其他对象引用的过程的几种：
a.直接赋值，如上例中的A.a = E；
b.通过参数传递，例如public void addObject(Object E)；
c.其它一些情况如系统调用等。


3.3 容易引起内存泄漏的几大原因
3.3.1 静态集合类
      像HashMap、Vector 等静态集合类的使用最容易引起内存泄漏，因为这些静态变量的生命周期与应用程序一致，如示例1，如果该Vector 是静态的，那么它将一直存在，而其中所有的Object对象也不能被释放，因为它们也将一直被该Vector 引用着。
3.3.2 **器
     在java 编程中，我们都需要和**器打交道，通常一个应用当中会用到很多**器，我们会调用一个控件的诸如addXXXListener()等方法来增加**器， 但往往在释放对象的时候却没有记住去删除这些**器，从而增加了内存泄漏的机会。
3.3.3 物理连接
         一些物理连接，比如数据库连接和网络连接，除非其显式的关闭了连接，否则是不会自动被 GC 回收的。Java 数据库连接一般用DataSource.getConnection()来创建，当不再使用时必须用Close()方法来释放，因为这些连接是独立于 JVM的。对于Resultset 和Statement 对象可以不进行显式回收，但Connection 一定要显式回收，因为Connection 在任何时候都无法自动回收，而Connection一旦回收，Resultset 和Statement 对象就会立即为NULL。但是如果使用连接池，情况就不一样了，除了要显式地关闭连接，还必须显式地关闭Resultset Statement 对象（关闭其中一个，另外一个也会关闭），否则就会造成大量的Statement 对象无法释放，从而引起内存泄漏。


3.3.4 内部类和外部模块等的引用
        内部类的引用是比较容易遗忘的一种，而且一旦没释放可能导致一系列的后继类对象没有释放。对于程序员而言，自己的程序很清楚，如果发现内存泄漏，自 己对这些对象的引用可以很快定位并解决，但是现在的应用软件并非一个人实现，模块化的思想在现代软件中非常明 显，所以程序员要小心外部模块不经意的引用，例如程序员A 负责A 模块，调用了B 模块的一个方法如：public void registerMsg(Object b);这种调用就要非常小心了，传入了一个对象，很可能模块B就保持了对该对象的引用，这时候就需要注意模块B 是否提供相应的操作去除引用。


4 预防和检测内存漏洞
    在了解了引起内存泄漏的一些原因后，应该尽可能地避免和发现内存泄漏。
(1)好的编码习惯。最基本的建议就是尽早释放无用对象的引用，大多数程序员在使用临时变量的时候，都是让引用变量在退出活动域后，自动设置为null。 在使用这种方式时候，必须特别注意一些复杂的对象图，例如数组、列、树、图等，这些对象之间有相互引用关系较为复杂。对于这类对象，GC 回收它们一般效率较低。如果程序允许，尽早将不用的引用对象赋为null。另外建议几点：
在确认一个对象无用后，将其所有引用显式的置为null；
当类从Jpanel 或Jdialog 或其它容器类继承的时候，删除该对象之前不妨调用它的removeall()方法；在设一个引用变量为null 值之前，应注意该引用变量指向的对象是否被**，若有，要首先除去**器，然后才可以赋空值；当对象是一个Thread 的时候，删除该对象之前不妨调用它的interrupt()方法；内存检测过程中不仅要关注自己编写的类对象，同时也要关注一些基本类型的对象，例 如：int[]、String、char[]等等；如果有数据库连接，使用try...finally 结构，在finally 中关闭Statement 对象和连接。
(2)好的测试工具。在开发中不能完全避免内存泄漏，关键要在发现有内 存泄漏的时候能用好的测试工具迅速定位问题的所在。市场上已有几种专业检查Java 内存泄漏的工具，它们的基本工作原理大同小异，都是通过监测Java 程序运行时，所有对象的申请、释放等动作，将内存管理的所有信息进行统计、分析、可视化。开发人员将根据这些信息判断程序是否有内存泄漏问题。这些工具包 括Optimizeit Profiler、JProbe Profiler、JinSight、Rational 公司的Purify 等。