Java内存管理、内存泄露

转载原文：http://cowboy-bebop.iteye.com/blog/1019306

问题的提出

Java的一个重要优点就是通过垃圾收集器(Garbage Collection，GC)自动管理内存的回收，程序员不需要通过调用函数来释放内存。因此，很多程序员认为Java不存在内存泄漏问题，或者认为即使有内存泄漏也不是程序的责任，而是GC或JVM的问题。其实，这种想法是不正确的，因为Java也存在内存泄露，但它的表现与C++不同。

随着越来越多的服务器程序采用Java技术，例如JSP，Servlet， EJB等，服务器程序往往长期运行。另外，在很多嵌入式系统中，内存的总量非常有限。内存泄露问题也就变得十分关键，即使每次运行少量泄漏，长期运行之后，系统也是面临崩溃的危险。

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中的内存泄露

下面，我们就可以描述什么是内存泄漏。在Java中，内存泄漏就是存在一些被分配的对象，这些对象有下面两个特点，首先，这些对象是可达的，即在有向图中，存在通路可以与其相连；其次，这些对象是无用的，即程序以后不会再使用这些对象。如果对象满足这两个条件，这些对象就可以判定为Java中的内存泄漏，这些对象不会被GC所回收，然而它却占用内存。

在C++中，内存泄漏的范围更大一些。有些对象被分配了内存空间，然后却不可达，由于C++中没有GC，这些内存将永远收不回来。在Java中，这些不可达的对象都由GC负责回收，因此程序员不需要考虑这部分的内存泄露。

通过分析，我们得知，对于C++，程序员需要自己管理边和顶点，而对于Java程序员只需要管理边就可以了(不需要管理顶点的释放)。通过这种方式，Java提高了编程的效率。

因此，通过以上分析，我们知道在Java中也有内存泄漏，但范围比C++要小一些。因为Java从语言上保证，任何对象都是可达的，所有的不可达对象都由GC管理。

对于程序员来说，GC基本是透明的，不可见的。虽然，我们只有几个函数可以访问GC，例如运行GC的函数System.gc()，但是根据Java语言规范定义， 该函数不保证JVM的垃圾收集器一定会执行。因为，不同的JVM实现者可能使用不同的算法管理GC。通常，GC的线程的优先级别较低。JVM调用GC的策略也有很多种，有的是内存使用到达一定程度时，GC才开始工作，也有定时执行的，有的是平缓执行GC，有的是中断式执行GC。但通常来说，我们不需要关心这些。除非在一些特定的场合，GC的执行影响应用程序的性能，例如对于基于Web的实时系统，如网络游戏等，用户不希望GC突然中断应用程序执行而进行垃圾回收，那么我们需要调整GC的参数，让GC能够通过平缓的方式释放内存，例如将垃圾回收分解为一系列的小步骤执行，Sun提供的HotSpot JVM就支持这一特性。

下面给出了一个简单的内存泄露的例子。在这个例子中，我们循环申请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引用这些对象。 

如何检测内存泄漏

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

下面，我们将简单介绍Optimizeit的基本功能和工作原理。

Optimizeit Profiler版本4.11支持Application，Applet，Servlet和Romote Application四类应用，并且可以支持大多数类型的JVM，包括SUN JDK系列，IBM的JDK系列，和Jbuilder的JVM等。并且，该软件是由Java编写，因此它支持多种操作系统。Optimizeit系列还包括Thread Debugger和Code Coverage两个工具，分别用于监测运行时的线程状态和代码覆盖面。

当设置好所有的参数了，我们就可以在OptimizeIt环境下运行被测程序，在程序运行过程中，Optimizeit可以监视内存的使用曲线(如下图)，包括JVM申请的堆(heap)的大小，和实际使用的内存大小。另外，在运行过程中，我们可以随时暂停程序的运行，甚至强行调用GC，让GC进行内存回收。通过内存使用曲线，我们可以整体了解程序使用内存的情况。这种监测对于长期运行的应用程序非常有必要，也很容易发现内存泄露。

在运行过程中，我们还可以从不同视角观查内存的使用情况，Optimizeit提供了四种方式：

• 堆视角。 这是一个全面的视角，我们可以了解堆中的所有的对象信息(数量和种类)，并进行统计、排序，过滤。了解相关对象的变化情况。
• 方法视角。通过方法视角，我们可以得知每一种类的对象，都分配在哪些方法中，以及它们的数量。
• 对象视角。给定一个对象，通过对象视角，我们可以显示它的所有出引用和入引用对象，我们可以了解这个对象的所有引用关系。
• 引用图。 给定一个根，通过引用图，我们可以显示从该顶点出发的所有出引用。

在运行过程中，我们可以随时观察内存的使用情况，通过这种方式，我们可以很快找到那些长期不被释放，并且不再使用的对象。我们通过检查这些对象的生存周期，确认其是否为内存泄露。在实践当中，寻找内存泄露是一件非常麻烦的事情，它需要程序员对整个程序的代码比较清楚，并且需要丰富的调试经验，但是这个过程对于很多关键的Java程序都是十分重要的。

综上所述，Java也存在内存泄露问题，其原因主要是一些对象虽然不再被使用，但它们仍然被引用。为了解决这些问题，我们可以通过软件工具来检查内存泄露，检查的主要原理就是暴露出所有堆中的对象，让程序员寻找那些无用但仍被引用的对象。 

Java系统中内存泄漏测试方法的研究

　　问题的提出

　　笔者曾经参与开发的网管系统，系统规模庞大，涉及上百万行代码。系统主要采用Java语言开发，大体上分为客户端、服务器和数据库三个层次。在版本进入测试和试用的过程中，现场人员和测试部人员纷纷反映:系统的稳定性比较差，经常会出现服务器端运行一昼夜就死机的现象，客户端跑死的现象也比较频繁地发生。对于网管系统来讲，经常性的服务器死机是个比较严重的问题，因为频繁的死机不仅可能导致前后台数据不一致，发生错误，更会引起用户的不满，降低客户的信任度。因此，服务器端的稳定性问题必须尽快解决。

　　解决思路

　　通过察看服务器端日志，发现死机前服务器端频繁抛出OutOfMemoryException内存溢出错误，因此初步把死机的原因定位为内存泄漏引起内存不足，进而引起内存溢出错误。如何查找引起内存泄漏的原因呢?有两种思路:第一种，安排有经验的编程人员对代码进行走查和分析，找出内存泄漏发生的位置;第二种，使用专门的内存泄漏测试工具Optimizeit进行测试。这两种方法都是解决系统稳定性问题的有效手段，使用内存测试工具对于已经暴露出来的内存泄漏问题的定位和解决非常有效;但是软件测试的理论也告诉我们，系统中永远存在一些没有暴露出来的问题，而且，系统的稳定性问题也不仅仅只是内存泄漏的问题，代码走查是提高系统的整体代码质量乃至解决潜在问题的有效手段。基于这样的考虑，我们的内存稳定性工作决定采用代码走查结合测试工具的使用，双管齐下，争取比较彻底地解决系统的稳定性问题。

　　在代码走查的工作中，安排了对系统业务和开发语言工具比较熟悉的开发人员对应用的代码进行了交叉走查，找出代码中存在的数据库连接声明和结果集未关闭、代码冗余和低效等故障若干，取得了良好的效果，文中主要讲述结合工具的使用对已经出现的内存泄漏问题的定位方法。

　　内存泄漏的基本原理

　　在C++语言程序中，使用new操作符创建的对象，在使用完毕后应该通过delete操作符显示地释放，否则，这些对象将占用堆空间，永远没有办法得到回收，从而引起内存空间的泄漏。如下的简单代码就可以引起内存的泄漏:

void function(){
　Int[] vec = new int[5];
}

　　在function()方法执行完毕后，vec数组已经是不可达对象，在C++语言中，这样的对象永远也得不到释放，称这种现象为内存泄漏。

　　而Java是通过垃圾收集器(Garbage Collection，GC)自动管理内存的回收，程序员不需要通过调用函数来释放内存，但它只能回收无用并且不再被其它对象引用的那些对象所占用的空间。在下面的代码中，循环申请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认为它还有用)，这一点是导致内存泄漏最重要的原因。

　　Java的内存回收机制可以形象地理解为在堆空间中引入了重力场，已经加载的类的静态变量和处于活动线程的堆栈空间的变量是这个空间的牵引对象。这里牵引对象是指按照Java语言规范，即便没有其它对象保持对它的引用也不能够被回收的对象，即Java内存空间中的本原对象。当然类可能被去加载，活动线程的堆栈也是不断变化的，牵引对象的集合也是不断变化的。对于堆空间中的任何一个对象，如果存在一条或者多条从某个或者某几个牵引对象到该对象的引用链，则就是可达对象，可以形象地理解为从牵引对象伸出的引用链将其拉住，避免掉到回收池中;而其它的不可达对象由于不存在牵引对象的拉力，在重力的作用下将掉入回收池。在图1中，A、B、C、D、E、F六个对象都被牵引对象所直接或者间接地“牵引”，使得它们避免在重力的作用下掉入回收池。如果TR1-A链和TR2-D链断开，则A、B、C三个对象由于失去牵引，在重力的作用下掉入回收池(被回收)，D对象也是同样的原因掉入回收池，而F对象仍然存在一个牵引链(TR3-E-F)，所以不会被回收，如图2、3所示。

　　
　　图1 初始状态

　　
　　图2 TR1-A链和TR2-D链断开，A、B、C、D掉入回收池

　　
　　图3 A、B、C、D四个对象被回收

　　通过前面的介绍可以看到，由于采用了垃圾回收机制，任何不可达对象都可以由垃圾收集线程回收。因此通常说的Java内存泄漏其实是指无意识的、非故意的对象引用，或者无意识的对象保持。无意识的对象引用是指代码的开发人员本来已经对对象使用完毕，却因为编码的错误而意外地保存了对该对象的引用(这个引用的存在并不是编码人员的主观意愿)，从而使得该对象一直无法被垃圾回收器回收掉，这种本来以为可以释放掉的却最终未能被释放的空间可以认为是被“泄漏了”。

　　这里通过一个例子来演示Java的内存泄漏。假设有一个日志类Logger，其提供一个静态的log(String msg)方法，任何其它类都可以调用Logger.Log(message)来将message的内容记录到系统的日志文件中。Logger类有一个类型为HashMap的静态变量temp，每次在执行log(message)方法的时候，都首先将message的值丢入temp中(以当前线程+当前时间为键)，在方法退出之前再从temp中将以当前线程和当前时间为键的条目删除。注意，这里当前时间是不断变化的，所以log方法在退出之前执行删除条目的操作并不能删除方法执行之初丢入的条目。这样，任何一个作为参数传给log方法的字符串最终由于被Logger的静态变量temp引用，而无法得到回收，这种违背实现者主观意图的无意识的对象保持就是我们所说的Java内存泄漏。

 

　　鉴别泄漏对象的方法

　　一般说来，一个正常的系统在其运行稳定后其内存的占用量是基本稳定的，不应该是无限制的增长的，同样，对任何一个类的对象的使用个数也有一个相对稳定的上限，不应该是持续增长的。根据这样的基本假设，我们可以持续地观察系统运行时使用的内存的大小和各实例的个数，如果内存的大小持续地增长，则说明系统存在内存泄漏，如果某个类的实例的个数持续地增长，则说明这个类的实例可能存在泄漏情况。

　　Optimizeit是Borland公司的产品，主要用于协助对软件系统进行代码优化和故障诊断，其功能众多，使用方便，其中的OptimizeIt Profiler主要用于内存泄漏的分析。Profiler的堆视图(如图4)就是用来观察系统运行使用的内存大小和各个类的实例分配的个数的，其界面如图四所示，各列自左至右分别为类名称、当前实例个数、自上个标记点开始增长的实例个数、占用的内存空间的大小、自上次标记点开始增长的内存的大小、被释放的实例的个数信息、自上次标记点开始增长的内存的大小被释放的实例的个数信息，表的最后一行是汇总数据，分别表示目前JVM中的对象实例总数、实例增长总数、内存使用总数、内存使用增长总数等。

　　在实践中，可以分别在系统运行四个小时、八个小时、十二个小时和二十四个小时时间点记录当时的内存状态(即抓取当时的内存快照，是工具提供的功能，这个快照也是供下一步分析使用)，找出实例个数增长的前十位的类，记录下这十个类的名称和当前实例的个数。在记录完数据后，点击Profiler中右上角的Mark按钮，将该点的状态作为下一次记录数据时的比较点。

　　
　　图4 Profiler 堆视图

　　系统运行二十四小时以后可以得到四个内存快照。对这四个内存快照进行综合分析，如果每一次快照的内存使用都比上一次有增长，可以认定系统存在内存泄漏，找出在四个快照中实例个数都保持增长的类，这些类可以初步被认定为存在泄漏。

　　分析与定位

　　通过上面的数据收集和初步分析，可以得出初步结论:系统是否存在内存泄漏和哪些对象存在泄漏(被泄漏)，如果结论是存在泄漏，就可以进入分析和定位阶段了。

　　前面已经谈到Java中的内存泄漏就是无意识的对象保持，简单地讲就是因为编码的错误导致了一条本来不应该存在的引用链的存在(从而导致了被引用的对象无法释放)，因此内存泄漏分析的任务就是找出这条多余的引用链，并找到其形成的原因。前面还讲到过牵引对象，包括已经加载的类的静态变量和处于活动线程的堆栈空间的变量。由于活动线程的堆栈空间是迅速变化的，处于堆栈空间内的牵引对象集合是迅速变化的，而作为类的静态变量的牵引对象的集合在系统运行期间是相对稳定的。

　　对每个被泄漏的实例对象，必然存在一条从某个牵引对象出发到达该对象的引用链。处于堆栈空间的牵引对象在被从栈中弹出后就失去其牵引的能力，变为非牵引对象，因此，在长时间的运行后，被泄露的对象基本上都是被作为类的静态变量的牵引对象牵引。

　　Profiler的内存视图除了堆视图以外，还包括实例分配视图(图5)和实例引用图(图6)。

　　Profiler的实例引用图为找出从牵引对象到泄漏对象的引用链提供了非常直接的方法，其界面的第二个栏目中显示的就是从泄漏对象出发的逆向引用链。需要注意的是，当一个类的实例存在泄漏时，并非其所有的实例都是被泄漏的，往往只有一部分是被泄漏对象，其它则是正常使用的对象，要判断哪些是正常的引用链，哪些是不正常的引用链(引起泄漏的引用链)。通过抽取多个实例进行引用图的分析统计以后，可以找出一条或者多条从牵引对象出发的引用链，下面的任务就是找出这条引用链形成的原因。

　　实例分配图提供的功能是对每个类的实例的分配位置进行统计，查看实例分配的统计结果对于分析引用链的形成具有一定的作用，因为找到分配链与引用链的交点往往就可以找到了引用链形成的原因，下面将具体介绍。

　　
　　图5 实例分配图

　　
　　图6 实例引用图

　　设想一个实例对象a在方法f中被分配，最终被实例对象b所引用，下面来分析从b到a的引用链可能的形成原因。方法f在创建对象a后，对它的使用分为四种情况:1、将a作为返回值返回;2、将a作为参数调用其它方法;3、在方法内部将a的引用传递给其它对象;4、其它情况。其中情况4不会造成由b到a的引用链的生成，不用考虑。下面考虑其它三种情况:对于1、2两种情况，其造成的结果都是在另一个方法内部获得了对象a的引用，它的分析与方法f的分析完全一样(递归分析);考虑第3种情况:1、假设方法f直接将对象a的引用加入到对象b，则对象b到a的引用链就找到了，分析结束;2、假设方法f将对象a的引用加入到对象c，则接下来就需要跟踪对象c的使用，对象c的分析比对象a的分析步骤更多一些，但大体原理都是一样的，就是跟踪对象从创建后被使用的历程，最终找到其被牵引对象引用的原因。

　　现在将泄漏对象的引用链以及引用链形成的原因找到了，内存泄漏测试与分析的工作就到此结束，接下来的工作就是修改相应的设计或者实现中的错误了。

　　总结

　　使用上述的测试和分析方法，在实践中先后进行了三次测试，找出了好几处内存泄漏错误。系统的稳定性得到很大程度的提高，最初运行1~2天就抛出内存溢出异常，修改完成后，系统从未出现过内存溢出异常。此方法适用于任何使用Java语言开发的、对稳定性有比较高要求的软件系统。

 

 

 

第二篇：

转载原文：http://www.cnblogs.com/qq78292959/archive/2011/07/25/2116123.html

Java内存管理机制

在C++语言中，如果需要动态分配一块内存，程序员需要负责这块内存的整个生命周期。从申请分配、到使用、再到最后的释放。这样的过程非常灵活，但是却十分繁琐，程序员很容易由于疏忽而忘记释放内存，从而导致内存的泄露。Java语言对内存管理做了自己的优化，这就是垃圾回收机制。Java的几乎所有内存对象都是在堆内存上分配（基本数据类型除外），然后由GC（garbage collection）负责自动回收不再使用的内存。

    上面是Java内存管理机制的基本情况。但是如果仅仅理解到这里，我们在实际的项目开发中仍然会遇到内存泄漏的问题。也许有人表示怀疑，既然Java的垃圾回收机制能够自动的回收内存，怎么还会出现内存泄漏的情况呢？这个问题，我们需要知道GC在什么时候回收内存对象，什么样的内存对象会被GC认为是“不再使用”的。

    Java中对内存对象的访问，使用的是引用的方式。在Java代码中我们维护一个内存对象的引用变量，通过这个引用变量的值，我们可以访问到对应的内存地址中的内存对象空间。在Java程序中，这个引用变量本身既可以存放堆内存中，又可以放在代码栈的内存中（与基本数据类型相同）。GC线程会从代码栈中的引用变量开始跟踪，从而判定哪些内存是正在使用的。如果GC线程通过这种方式，无法跟踪到某一块堆内存，那么GC就认为这块内存将不再使用了（因为代码中已经无法访问这块内存了）。

 

 

    通过这种有向图的内存管理方式，当一个内存对象失去了所有的引用之后，GC就可以将其回收。反过来说，如果这个对象还存在引用，那么它将不会被GC回收，哪怕是Java虚拟机抛出OutOfMemoryError。

Java内存泄露

    一般来说内存泄漏有两种情况。一种情况如在C/C++语言中的，在堆中的分配的内存，在没有将其释放掉的时候，就将所有能访问这块内存的方式都删掉（如指针重新赋值）；另一种情况则是在内存对象明明已经不需要的时候，还仍然保留着这块内存和它的访问方式（引用）。第一种情况，在Java中已经由于垃圾回收机制的引入，得到了很好的解决。所以，Java中的内存泄漏，主要指的是第二种情况。

    可能光说概念太抽象了，大家可以看一下这样的例子：

1 Vector v=new Vector(10);
2 for (int i=1;i<100; i++){
3 Object o=new Object();
4 v.add(o);
5 o=null;
6 }

   
    在这个例子中，代码栈中存在Vector对象的引用v和Object对象的引用o。在For循环中，我们不断的生成新的对象，然后将其添加到Vector对象中，之后将o引用置空。问题是当o引用被置空后，如果发生GC，我们创建的Object对象是否能够被GC回收呢？答案是否定的。因为，GC在跟踪代码栈中的引用时，会发现v引用，而继续往下跟踪，就会发现v引用指向的内存空间中又存在指向Object对象的引用。也就是说尽管o引用已经被置空，但是Object对象仍然存在其他的引用，是可以被访问到的，所以GC无法将其释放掉。如果在此循环之后，Object对象对程序已经没有任何作用，那么我们就认为此Java程序发生了内存泄漏。

    尽管对于C/C++中的内存泄露情况来说，Java内存泄露导致的破坏性小，除了少数情况会出现程序崩溃的情况外，大多数情况下程序仍然能正常运行。但是，在移动设备对于内存和CPU都有较严格的限制的情况下，Java的内存溢出会导致程序效率低下、占用大量不需要的内存等问题。这将导致整个机器性能变差，严重的也会引起抛出OutOfMemoryError，导致程序崩溃。

一般情况下内存泄漏的避免

    在不涉及复杂数据结构的一般情况下，Java的内存泄露表现为一个内存对象的生命周期超出了程序需要它的时间长度。我们有时也将其称为“对象游离”。

例如：

 1 public class FileSearch{
 2 
 3     private byte[] content;
 4     private File mFile;
 5     
 6     public FileSearch(File file){
 7         mFile = file;
 8     }
 9 
10     public boolean hasString(String str){
11         int size = getFileSize(mFile);
12         content = new byte[size];
13         loadFile(mFile, content);
14         
15         String s = new String(content);
16         return s.contains(str);
17     }
18 }

    在这段代码中，FileSearch类中有一个函数hasString，用来判断文档中是否含有指定的字符串。流程是先将mFile加载到内存中，然后进行判断。但是，这里的问题是，将content声明为了实例变量，而不是本地变量。于是，在此函数返回之后，内存中仍然存在整个文件的数据。而很明显，这些数据我们后续是不再需要的，这就造成了内存的无故浪费。

    要避免这种情况下的内存泄露，要求我们以C/C++的内存管理思维来管理自己分配的内存。第一，是在声明对象引用之前，明确内存对象的有效作用域。在一个函数内有效的内存对象，应该声明为local变量，与类实例生命周期相同的要声明为实例变量……以此类推。第二，在内存对象不再需要时，记得手动将其引用置空。

复杂数据结构中的内存泄露问题

    在实际的项目中，我们经常用到一些较为复杂的数据结构用于缓存程序运行过程中需要的数据信息。有时，由于数据结构过于复杂，或者我们存在一些特殊的需求（例如，在内存允许的情况下，尽可能多的缓存信息来提高程序的运行速度等情况），我们很难对数据结构中数据的生命周期作出明确的界定。这个时候，我们可以使用Java中一种特殊的机制来达到防止内存泄露的目的。

    之前我们介绍过，Java的GC机制是建立在跟踪内存的引用机制上的。而在此之前，我们所使用的引用都只是定义一个“Object o;”这样形式的。事实上，这只是Java引用机制中的一种默认情况，除此之外，还有其他的一些引用方式。通过使用这些特殊的引用机制，配合GC机制，就可以达到一些我们需要的效果。

Java中的几种引用方式

    Java中有几种不同的引用方式，它们分别是：强引用、软引用、弱引用和虚引用。下面，我们首先详细地了解下这几种引用方式的意义。

    
      强引用

在此之前我们介绍的内容中所使用的引用都是强引用，这是使用最普遍的引用。如果一个对象具有强引用，那就类似于必不可少的生活用品，垃圾回收器绝不会回收它。当内存空 间不足，Java虚拟机宁愿抛出OutOfMemoryError错误，使程序异常终止，也不会靠随意回收具有强引用的对象来解决内存不足问题。

软引用（SoftReference）

SoftReference 类的一个典型用途就是用于内存敏感的高速缓存。SoftReference 的原理是：在保持对对象的引用时保证在 JVM 报告内存不足情况之前将清除所有的软引用。关键之处在于，垃圾收集器在运行时可能会（也可能不会）释放软可及对象。对象是否被释放取决于垃圾收集器的算法 以及垃圾收集器运行时可用的内存数量。

弱引用（WeakReference）

WeakReference 类的一个典型用途就是规范化映射（canonicalized mapping）。另外，对于那些生存期相对较长而且重新创建的开销也不高的对象来说，弱引用也比较有用。关键之处在于，垃圾收集器运行时如果碰到了弱可及对象，将释放 WeakReference 引用的对象。然而，请注意，垃圾收集器可能要运行多次才能找到并释放弱可及对象。

虚引用（PhantomReference）

PhantomReference 类只能用于跟踪对被引用对象即将进行的收集。同样，它还能用于执行 pre-mortem 清除操作。PhantomReference 必须与 ReferenceQueue 类一起使用。需要 ReferenceQueue 是因为它能够充当通知机制。当垃圾收集器确定了某个对象是虚可及对象时，PhantomReference 对象就被放在它的 ReferenceQueue 上。将 PhantomReference 对象放在 ReferenceQueue 上也就是一个通知，表明 PhantomReference 对象引用的对象已经结束，可供收集了。这使您能够刚好在对象占用的内存被回收之前采取行动。Reference与ReferenceQueue的配合使用。

GC、Reference与ReferenceQueue的交互

A、 GC无法删除存在强引用的对象的内存。

B、 GC发现一个只有软引用的对象内存，那么：

① SoftReference对象的referent 域被设置为null，从而使该对象不再引用heap对象。

② SoftReference引用过的heap对象被声明为finalizable。

③ 当 heap 对象的 finalize() 方法被运行而且该对象占用的内存被释放，SoftReference 对象就被添加到它的 ReferenceQueue（如果后者存在的话）。

C、 GC发现一个只有弱引用的对象内存，那么：

① WeakReference对象的referent域被设置为null,从而使该对象不再引用heap对象。

② WeakReference引用过的heap对象被声明为finalizable。

③ 当heap对象的finalize()方法被运行而且该对象占用的内存被释放时，WeakReference对象就被添加到它的ReferenceQueue（如果后者存在的话）。

D、 GC发现一个只有虚引用的对象内存，那么：

① PhantomReference引用过的heap对象被声明为finalizable。

② PhantomReference在堆对象被释放之前就被添加到它的ReferenceQueue。

值得注意的地方有以下几点：

1、GC在一般情况下不会发现软引用的内存对象，只有在内存明显不足的时候才会发现并释放软引用对象的内存。

2、GC对弱引用的发现和释放也不是立即的，有时需要重复几次GC，才会发现并释放弱引用的内存对象。
3、软引用和弱引用在添加到ReferenceQueue的时候，其指向真实内存的引用已经被置为空了，相关的内存也已经被释放掉了。而虚引用在添加到ReferenceQueue的时候，内存还没有释放，仍然可以对其进行访问。

    代码示例

通过以上的介绍，相信您对Java的引用机制以及几种引用方式的异同已经有了一定了解。光是概念，可能过于抽象，下面我们通过一个例子来演示如何在代码中使用Reference机制。

 

1     String str = new String("hello"); //①
2     ReferenceQueue<String> rq = new ReferenceQueue<String>(); //②
3     WeakReference<String> wf = new WeakReference<String>(str, rq); //③
4     str=null; //④取消"hello"对象的强引用
5     String str1=wf.get(); //⑤假如"hello"对象没有被回收，str1引用"hello"对象
6     //假如"hello"对象没有被回收，rq.poll()返回null
7     Reference<? extends String> ref=rq.poll(); //⑥

 

在以上代码中，注意⑤⑥两处地方。假如“hello”对象没有被回收wf.get()将返回“hello”字符串对象，rq.poll()返回null；而加入“hello”对象已经被回收了，那么wf.get()返回null，rq.poll()返回Reference对象，但是此Reference对象中已经没有str对象的引用了(PhantomReference则与WeakReference、SoftReference不同)。

    引用机制与复杂数据结构的联合应用

    了解了GC机制、引用机制，并配合上ReferenceQueue，我们就可以实现一些防止内存溢出的复杂数据类型。

例如，SoftReference具有构建Cache系统的特质，因此我们可以结合哈希表实现一个简单的缓存系统。这样既能保证能够尽可能多的缓存信息，又可以保证Java虚拟机不会因为内存泄露而抛出OutOfMemoryError。这种缓存机制特别适合于内存对象生命周期长，且生成内存对象的耗时比较长的情况，例如缓存列表封面图片等。对于一些生命周期较长，但是生成内存对象开销不大的情况，使用WeakReference能够达到更好的内存管理的效果。

附SoftHashmap的源码一份，相信看过之后，大家会对Reference机制的应用有更深入的理解。

 

  1package com.***.widget;
  2
  3//: SoftHashMap.java 
  4import java.util.*; 
  5import java.lang.ref.*; 
  6
  7import android.util.Log;
  8
  9public class SoftHashMap extends AbstractMap { 
 10  /** The internal HashMap that will hold the SoftReference. */ 
 11  private final Map hash = new HashMap(); 
 12  /** The number of "hard" references to hold internally. */ 
 13  private final int HARD_SIZE; 
 14  /** The FIFO list of hard references, order of last access. */ 
 15  private final LinkedList hardCache = new LinkedList(); 
 16  /** Reference queue for cleared SoftReference objects. */ 
 17  private ReferenceQueue queue = new ReferenceQueue(); 
 18
 19  //Strong Reference number
 20  public SoftHashMap() { this(100); } 
 21  public SoftHashMap(int hardSize) { HARD_SIZE = hardSize; } 
 22  
 23
 24  public Object get(Object key) { 
 25    Object result = null; 
 26    // We get the SoftReference represented by that key 
 27    SoftReference soft_ref = (SoftReference)hash.get(key); 
 28    if (soft_ref != null) { 
 29      // From the SoftReference we get the value, which can be 
 30      // null if it was not in the map, or it was removed in 
 31      // the processQueue() method defined below 
 32      result = soft_ref.get(); 
 33      if (result == null) { 
 34        // If the value has been garbage collected, remove the 
 35        // entry from the HashMap. 
 36        hash.remove(key); 
 37      } else { 
 38        // We now add this object to the beginning of the hard 
 39        // reference queue.  One reference can occur more than 
 40        // once, because lookups of the FIFO queue are slow, so 
 41        // we don't want to search through it each time to remove 
 42        // duplicates. 
 43          //keep recent use object in memory
 44        hardCache.addFirst(result); 
 45        if (hardCache.size() > HARD_SIZE) { 
 46          // Remove the last entry if list longer than HARD_SIZE 
 47          hardCache.removeLast(); 
 48        } 
 49      } 
 50    } 
 51    return result; 
 52  } 
 53
 54  /** We define our own subclass of SoftReference which contains 
 55   not only the value but also the key to make it easier to find 
 56   the entry in the HashMap after it's been garbage collected. */ 
 57  private static class SoftValue extends SoftReference { 
 58    private final Object key; // always make data member final 
 59    /** Did you know that an outer class can access private data 
 60     members and methods of an inner class?  I didn't know that! 
 61     I thought it was only the inner class who could access the 
 62     outer class's private information.  An outer class can also 
 63     access private members of an inner class inside its inner 
 64     class. */ 
 65    private SoftValue(Object k, Object key, ReferenceQueue q) { 
 66      super(k, q); 
 67      this.key = key; 
 68    } 
 69  } 
 70
 71  /** Here we go through the ReferenceQueue and remove garbage 
 72   collected SoftValue objects from the HashMap by looking them 
 73   up using the SoftValue.key data member. */ 
 74  public void processQueue() { 
 75    SoftValue sv; 
 76    while ((sv = (SoftValue)queue.poll()) != null) { 
 77        if(sv.get()== null){
 78            Log.e("processQueue", "null");
 79        }else{
 80            Log.e("processQueue", "Not null");
 81        }
 82      hash.remove(sv.key); // we can access private data!
 83      Log.e("SoftHashMap", "release " + sv.key);
 84    } 
 85  } 
 86  /** Here we put the key, value pair into the HashMap using 
 87   a SoftValue object. */ 
 88  public Object put(Object key, Object value) { 
 89    processQueue(); // throw out garbage collected values first 
 90    Log.e("SoftHashMap", "put into " + key);
 91    return hash.put(key, new SoftValue(value, key, queue)); 
 92  } 
 93  public Object remove(Object key) { 
 94    processQueue(); // throw out garbage collected values first 
 95    return hash.remove(key); 
 96  } 
 97  public void clear() { 
 98    hardCache.clear(); 
 99    processQueue(); // throw out garbage collected values 
100    hash.clear(); 
101  } 
102  public int size() { 
103    processQueue(); // throw out garbage collected values first 
104    return hash.size(); 
105  } 
106  public Set entrySet() { 
107    // no, no, you may NOT do that!!! GRRR 
108    throw new UnsupportedOperationException(); 
109  } 
110} 
111
112
113