在JAVA中用弱引用堵住内存泄漏

在JAVA中用弱引用堵住内存泄漏本文章由91913网址导航整理，供更多的IT学习者学习。弱引用能让表达对象生命周期关系变得更加容易，虽然用Java™语言编写的程序在理论上是不会出现“内存泄漏”的，但是有时对象在不再作为程序的逻辑状态的一部分之后仍然不被垃圾收集。本月，负责保障应用程序健康的工程师BrianGoetz探讨了无意识的对象保留的常见原因，并展示了如何用弱引用堵住泄漏。要让垃圾收集(GC)回收程序不再使用的对象，对象的逻辑生命周期(应用程序使用它的时间)和对该对象拥有的引用的实际生命周期必须是相同的。在大多数时候，好的软件工程技术保证这是自动实现的，不用我们对对象生命周期问题花费过多心思。但是偶尔我们会创建一个引用，它在内存中包含对象的时间比我们预期的要长得多，这种情况称为无意识的对象保留Unintentionalobjectreten)ion弱引用和弱集合是对堆进行管理的强大工具,使得应用程序可以使用更复杂的可及性方案，而不只是由普通(强)引用所提供的'要么全部要么没有”可及性。下个月，我们将分析与弱引用有关的软引甩将分析在使用弱引用和软引用时，垃圾收集器的行为。全局Map造成的内存泄漏无意识对象保留最常见的原因是使用Map将元数据与临时对象(transientobject)相关联。假定一个对象具有中等生命周期，比分配它的那个方法调用的生命周期长，但是比应用程序的生命周期短，如客户机的套接字连接。需要将一些元数据与这个套接字关联，如生成连接的用户的标识。在创建Socket时是不知道这些信息的，并且不能将数据添加到Socket对象上，因为不能控制Socket类或者它的子类。这时，典型的方法就是在一个全局Map中存储这些信息，如清单1中的SocketManager类所示：清单1.使用一个全局Map将元数据关联到一个对象publicclassSocketManager{privateMap<Socket,user>m=newHashMap<Socket,user>();publicvoidsetuser(sockets,Useru){m.put(s,u);}publicUsergetuser(sockets){returnm.get(s);}publicvoidremoveuser(Sockets){m.remove(s);}}SocketManagersocketManager;・・・socketManager.setuser(socket,user);这种方法的问题是元数据的生命周期需要与套接字的生命周期挂钩，但是除非准确地知道什么时候程序不再需要这个套接字，并记住从Map中删除相应的映射，否则，Socket和User对象将会永远留在Map中，远远超过响应了请求和关闭套接字的时间。这会阻止Socket和User对象被垃圾收集，即使应用程序不会再使用它们。这些对象留下来不受控制，很容易造成程序在长时间运行后内存爆满。除了最简单的情况，在几乎所有情况下找出什么时候Socket不再被程序使用是一件很烦人和容易出错的任务，需要人工对内存进行管理。找出内存泄漏程序有内存泄漏的第一个迹象通常是它抛出一个OutOfMemoryError，或者因为频繁的垃圾收集而表现出糟糕的性能。幸运的是，垃圾收集可以提供能够用来诊断内存泄漏的大量信息。如果以verbose:gc或者Xloggc选项调用JVM,那么每次GC运行时在控制台上或者日志文件中会打印出一个诊断信息，包括它所花费的时间、当前堆使用情况以及恢复了多少内存。记录GC使用情况并不具有干扰性，因此如果需要分析内存问题或者调优垃圾收集器，在生产环境中默认启用GC日志是值得的。有工具可以利用GC日志输出并以图形方式将它显示出来，JTune就是这样的一种工具（请参阅参考资料）。观察GC之后堆大小的图，可以看到程序内存使用的趋势。对于大多数程序来说，可以将内存使用分为两部分：baseline使用和currentload使用。对于服务器应用程序，baseline使用就是应用程序在没有任何负荷、但是已经准备好接受请求时的内存使用，currentload使用是在处理请求过程中使用的、但是在请求处理完成后会释放的内存。只要负荷大体上是恒定的，应用程序通常会很快达到一个稳定的内存使用水平。如果在应用程序已经完成了其初始化并且负荷没有增加的情况下，内存使用持续增加，那么程序就可能在处理前面的请求时保留了生成的对象。清单2展示了一个有内存泄漏的程序。MapLeaker在线程池中处理任务，并在一个Map中记录每一项任务的状态。不幸的是，在任务完成后它不会删除那一项，因此状态项和任务对象（以及它们的内部状态）会不断地积累。清单2.具有基于Map的内存泄漏的程序publicclassMapLeaker{publicExecutorserviceexec=Executors.newFixedThreadPool(5);publicMapvTask,Taskstatus>taskstatus=Collections.synchronizedMap(newHashMapvTask,TaskStatus>());privateRandomrandom=newRandom();privateenumTaskstatus{not_started,started,finished};privateclassTaskimplementsRunnable{privateint[]numbers=newint[random.nextlnt(200)];publicvoidrun(){int[]temp=newint[random.nextlnt(10000)];taskstatus.put(this,Taskstatus.STARTED);doSomeWork();taskstatus.put(this,Taskstatus.FiNiSHED);}}publicTasknewTask(){Taskt=newTask();

taskstatus・put(t,Taskstatus・Not_started);exec.execute(t);returnt;}}图1显示MapLeakerGC之后应用程序堆大小随着时间的变化图。上升趋势是存在内存泄漏的警示信号。（在真实的应用程序中，坡度不会这么大，但是在收集了足够长时间的GC数据后，上升趋势通常会表现得很明显。）图1.持续上升的内存使用趋势宀苗帛亘UU」£■<占霑二吐缶HHeapUsageAfterGC2D ioClocktime(seconds)50宀苗帛亘UU」£■<占霑二吐缶HHeapUsageAfterGC2D ioClocktime(seconds)50*ScavengeOldfull■OtherfullGC确信有了内存泄漏后，下一步就是找出哪种对象造成了这个问题。所有内存分析器都可以生成按照对象类进行分解的堆快照。有一些很好的商业堆分析工具，但是找出内存泄漏不一定要花钱买这些工具——内置的hprof工具也可完成这项工作。要使用hprof并让它跟踪内存使用，需要以-Xrunhprof:heap=sites选项调用JVM。清单3显示分解了应用程序内存使用的hprof输出的相关部分°（hprof工具在应用程序退出时，或者用kill-3或在Windows中按Ctrl+Break时生成使用分解。）注意两次快照相比，Map.Entry、Task和int[]对象有了显著增加。请参阅清单3。清单4展示了hprof输出的另一部分，给出了Map.Entry对象的分配点的调用堆栈信息。这个输出告诉我们哪些调用链生成了Map.Entry对象，并带有一些程序分析，找出内存泄漏来源一般来说是相当容易的。清单4.HPROF输出，显示Map.Entry对象的分配点TRACE300446：java.util.HashMap$Entry.<init>(vunknownSource〉：unknownline)java.util.HashMap.addEntry(vunknownSource>:unknownline)java.util.HashMap.put(<unknownSource>:unknownline)java.util.Collections$SynchronizedMap.put(<unknownSource>:unknownline)com.quiotix.dummy.MapLeaker.newTask(MapLeaker.java:48)com.quiotix.dummy.MapLeaker.main(MapLeaker.java:64)弱引用来救援了SocketManager的问题是Socket-User映射的生命周期应当与Socket的生命周期相匹配，但是语言没有提供任何容易的方法实施这项规则。这使得程序不得不使用人工内存管理的老技术。幸运的是，从JDK1.2开始，垃圾收集器提供了一种声明这种对象生命周期依赖性的方法，这样垃圾收集器就可以帮助我们防止这种内存泄漏一一利用弱引用。弱引用是对一个对象（称为referent）的引用的持有者。使用弱引用后，可以维持对referent的引用，而不会阻止它被垃圾收集。当垃圾收集器跟踪堆的时候，如果对一个对象的引用只有弱引用，那么这个referent就会成为垃圾收集的候选对象，就像没有任何剩余的引用一样，而且所有剩余的弱引用都被清除。（只有弱引用的对象称为弱可及（we^k/yreachable）。）WeakReference的referent是在构造时设置的，在没有被清除之前，可以用get（）获取它的值。如果弱引用被清除了（不管是referent已经被垃圾收集了，还是有人调用了

WeakReference.clear()),get()会返回null。相应地，在使用其结果之前，应当总是检查get()是否返回一个非null值，因为referent最终总是会被垃圾收集的。用一个普通的(强)引用拷贝一个对象引用时，限制referent的生命周期至少与被拷贝的引用的生命周期一样长。如果不小心，那么它可能就与程序的生命周期一样一如果将一个对象放入一个全局集合中的话。另一方面，在创建对一个对象的弱引用时，完全没有扩展referent的生命周期，只是在对象仍然存活的时候，保持另一种到达它的方法。弱引用对于构造弱集合最有用，如那些在应用程序的其余部分使用对象期间存储关于这些对象的元数据的集合一这就是SocketManager类所要做的工作。因为这是弱引用最常见的用法，WeakHashMap也被添加到JDK1.2的类库中，它对键(而不是对值)使用弱引用。如果在一个普通HashMap中用一个对象作为键，那么这个对象在映射从Map中删除之前不能被回收，WeakHashMap使您可以用一个对象作为Map键，同时不会阻止这个对象被垃圾收集。清单5给出了WeakHashMap的get()方法的一种可能实现，它展示了弱引用的使用：清单5.WeakReference・get()的一种可能实现publicclassweakHashMap<K,v>implementsMap<K,v>{privatestaticclassEntry<K,v>extendsweakReference<K>implementsMap.Entry<K,V>{privateVvalue;privatefinalinthash;privateEntry<K,v>next;・・・}publicVget(Objectkey){inthash=getHash(key);Entry<K,v>e=getChain(hash);while(e!=null){KeKey=e.get();))if(e.hash==hash&&(key==eKey||key.equals(eKey)returne.value;))e=e.next;}returnnull;}调用WeakReference.get()时，它返回一个对referent的强引用(如果它仍然存活的话)，因此不需要担心映射在while循环体中消失，因为强引用会防止它被垃圾收集。WeakHashMap的实现展示了弱引用的一种常见用法 一些内部对象扩展WeakReference。其原因在下面一节讨论引用队列时会得到解释。在向WeakHashMap中添加映射时，请记住映射可能会在以后“脱离”，因为键被垃圾收集了。在这种情况下，get()返回null，这使得测试get()的返回值是否为null变得比平时更重要了。用WeakHashMap堵住泄漏在SocketManager中防止泄漏很容易，只要用WeakHashMap代替HashMap就行了，如清单6所示。(如果SocketManager需要线程安全，那么可以用Collections.synchronizedMap()包装WeakHashMap)。当映射的生命周期必须与键的生命周期联系在一起时，可以使用这种方法。不过，应当小心不滥用这种技术，大多数时候还是应当使用普通的HashMap作为Map的实现。清单6.用WeakHashMap修复SocketManagerreturnm.get(s);引用队列WeakHashMap用弱引用承载映射键，这使得应用程序不再使用键对象时它们可以被垃圾收集，get()实现可以根据WeakReference.get()是否返回null来区分死的映射和活的映射。但是这只是防止Map的内存消耗在应用程序的生命周期中不断增加所需要做的工作的一半，还需要做一些工作以便在键对象被收集后从Map中删除死项。否则，Map会充满对应于死键的项。虽然这对于应用程序是不可见的，但是它仍然会造成应用程序耗尽内存，因为即使键被收集了，Map.Entry和值对象也不会被收集。可以通过周期性地扫描Map,对每一个弱引用调用get()，并在get()返回null时删除那个映射而消除死映射。但是如果Map有许多活的项，那么这种方法的效率很低。如果有一种方法可以在弱引用的referent被垃圾收集时发出通知就好了，这就是引用队列的作用。引用队列是垃圾收集器向应用程序返回关于对象生命周期的信息的主要方法。弱引用有两个构造函数：一个只取referent作为参数，另一个还取引用队列作为参数。如果用关联的引用队列创建弱引用，在referent成为GC候选对象时，这个引用对象(不是referent)就在引用清除后加入到引用队列中。之后，应用程序从引用队列提取引用并了解到它的referent已被收集，因此可以进行相应的清理活动，如去掉已不在弱集合中的对象的项。(引