devbox
神奇cpp
这个屌丝很懒，什么也没留下！
关注作者
热门标签
热门文章
当前位置:   article > 正文

使用ReferenceQueue实现对ClassLoader垃圾回收过程的观察、以及由此引发的ClassLoader内存泄露的场景及排查过程_urlclassloader 什么时候被回收

作者：神奇cpp | 2024-07-25 17:53:56

赞

踩

urlclassloader 什么时候被回收

1 使用Reference/ReferenceQueue观察Class和ClassLoader的卸载

在java中，存在着强引用(=)，软引用(SoftReference)，弱引用(WeakReference)，虚引用(PhantomReference)这4种引用类型。如果一个对象强引用可达，就一定不会被GC回收；而如果一个对象只有软引用可达，则虚机会保证在out of memory之前会回收该对象；如果一个对象只是弱引用或者虚引用可达，则下一次GC时候就会将其回收。弱引用和虚引用的区别是，当一个对象只是弱引用可达时，它在下一次GC来临之前还有抢救的余地，也就是说弱引用仍可以获得该被引用的对象，然后将其赋值给某一个GC Root可达的变量，此时它就“得救”了；而当一个对象只是虚引用可达时候，它已经无法被抢救了，因为虚引用无法得到被引用对象。


Java还提供了ReferenceQueue用于在一个对象被gc回收掉的时候可以进行额外的处理。ReferenceQueue即是这样的一个队列，当一个对象被gc回收之后，其相应的包装类，即ref对象会被放入队列中。我们可以从queue中获取到相应的对象信息，同时进行额外的处理。比如反向操作，数据清理等。


由上面的介绍可以得知，我们可以使用WeakReference或者PhantomReference来观察ClassLoader和Class的卸载动作，而不会影响到他们的生命周期。先上一段代码：SimpleMonitorClassLoader.java

 

  1. public class SimpleMonitorClassLoader {
  2. 	public static void main(String args[]) throws Exception{
  3. 		final ReferenceQueue<Object> rq = new ReferenceQueue<Object>();
  4. 		final Map<Object, Object> map = new HashMap<>();
  5. 		Thread thread = new Thread(() -> {
  6. 		    try {
  7. 		        WeakReference<byte[]> k;
  8. 		        while((k = (WeakReference) rq.remove()) != null) {
  9. 		            System.out.println("GC回收了:" + map.get(k));
  10. 		        }
  11. 		    } catch(InterruptedException e) {
  12. 		        //结束循环
  13. 		    }
  14. 		});
  15. 		thread.setDaemon(true);
  16. 		thread.start();
  17. 		
  18. 		ClassLoader cl = newLoader();
  19. 		Class cls = cl.loadClass("classloader.test.Foo");
  20. 		Object obj = cls.newInstance();
  21. 		
  22. 		
  23. 		Object value = new Object();
  24. 		
  25. 		WeakReference<ClassLoader> weakReference = new WeakReference<ClassLoader>(cl, rq);
  26. 		map.put(weakReference, "ClassLoader URLClassLoader");
  27. 		WeakReference<Class> weakReference1 = new WeakReference<Class>(cls, rq);
  28. 		map.put(weakReference1, "Class classloader.test.Foo");
  29. 		WeakReference<Object> weakReference2 = new WeakReference<Object>(obj, rq);
  30. 		map.put(weakReference2, "Instance of Foo");
  31. 		
  32. 		obj=null;
  33. 		System.out.println("Set instance null and execute gc!");
  34. 		System.gc();
  35. 		Thread.sleep(3000);
  36. 		cls=null;
  37. 		System.out.println("Set class null and execute gc!");
  38. 		System.gc();
  39. 		Thread.sleep(3000);
  40. 		cl=null;
  41. 		System.out.println("Set classloader null and execute gc!");
  42. 		System.gc();
  43. 		Thread.sleep(3000);
  44. 	}
  45. 	
  46. 	static URLClassLoader newLoader() throws Exception{
  47. 		URL url = new File("/home/wangd/work/test/wangd/target/classes").toURI().toURL();
  48. 		URLClassLoader ucl = new URLClassLoader(new URL[] {url}, null);
  49. 	    return ucl;
  50. 	}
  51. }

执行结果如下：

 

Set instance null and execute gc!
GC回收了:Instance of Foo
Set class null and execute gc!
Set classloader null and execute gc!
GC回收了:Class classloader.test.Foo
GC回收了:ClassLoader URLClassLoader


从上面的结果可以看出，当heap中的实例对象实例失去了引用以后，会在GC时立刻被回收。而ClassLoader及其加载的Class是同时被回收的，因为ClassLoader及其加载的Class之间是相互引用的关系，要么同时GC Root可达，要么同时不可达也就是被回收。当外部没有任何引用到一个ClassLoader本身以及其加载的所有Class（也就是GC root不可达）时，GC会将其同时回收。

 

2 Guava FinalizableReference/FinalizableReferenceQueue对Reference/ReferenceQueue的封装

 

Guava是一种基于开源的Java库,对Java进行了封装,谷歌很多项目使用了它的核心库。这个库是为了方便编码,并减少人为的编码错误。Guava中提供了对Reference/ReferenceQueue的封装，使其使用起来变得非常简单。上面的例子使用Guava FinalizableReferen实现的代码如下：SimpleMonitorClassLoaderByGuava.class

 

  1. public class SimpleMonitorClassLoaderByGuava {
  2. 	public static void main(String args[]) throws Exception{
  3. 		final FinalizableReferenceQueue rq = new FinalizableReferenceQueue();
  4. 		ClassLoader cl = newLoader();
  5. 		Class cls = cl.loadClass("classloader.test.Foo");
  6. 		Object obj = cls.newInstance();
  7. 		
  8. 		Reference<ClassLoader> weakReference = new FinalizableWeakReference<ClassLoader>(cl, rq) {
  9. 	    	//在引用对象被GC回收以后执行一些订制的业务逻辑
  10. 			@Override
  11. 			public void finalizeReferent() {
  12. 				System.out.println("GC回收了:ClassLoader URLClassLoader");
  13. 			}
  14. 		};
  15. 	    
  16. 	    Reference<Class> weakReference1 = new FinalizableWeakReference<Class>(cls, rq) {
  17. 	    	//在引用对象被GC回收以后执行一些订制的业务逻辑
  18. 			@Override
  19. 			public void finalizeReferent() {
  20. 				System.out.println("GC回收了:Class classloader.test.Foo");
  21. 			}
  22. 		};
  23. 	    
  24. 	    Reference<Object> weakReference2 = new FinalizableWeakReference<Object>(obj, rq) {
  25. 	    	//在引用对象被GC回收以后执行一些订制的业务逻辑
  26. 			@Override
  27. 			public void finalizeReferent() {
  28. 				System.out.println("GC回收了:Instance of Foo");
  29. 			}
  30. 		};
  31. 	
  32. 		obj=null;
  33. 		System.out.println("Set instance null and execute gc!");
  34. 		System.gc();
  35. 		Thread.sleep(3000);
  36. 		cls=null;
  37. 		System.out.println("Set class null and execute gc!");
  38. 		System.gc();
  39. 		Thread.sleep(3000);
  40. 		cl=null;
  41. 		System.out.println("Set classloader null and execute gc!");
  42. 		System.gc();
  43. 		Thread.sleep(3000);
  44. 	}
  45. 	
  46. 	static URLClassLoader newLoader() throws Exception{
  47. 		URL url = new File("/home/wangd/work/test/wangd/target/classes").toURI().toURL();
  48. 		URLClassLoader ucl = new URLClassLoader(new URL[] {url}, null);
  49. 	    return ucl;
  50. 	}
  51. }

 

执行结果如下：

 

Set instance null and execute gc!
GC回收了:Instance of Foo
Set class null and execute gc!
Set classloader null and execute gc!
GC回收了:ClassLoader URLClassLoader
GC回收了:Class classloader.test.Foo

与上面的效果完全一致，Guava FinalizableReferenceQueue是对Java ReferenceQueue进行了一层封装，并在内部启动守护线程监控ReferenceQueue，当发现有FinalizableReference对象被enqueue以后，对该对象执行其finalizeReferent方法。无需我们自己编写代码启动线程，并管理随后可能出现的各种问题。

 

3 FinalizableReferenceQueue源码分析及其引出的Application ClassLoader无法卸载的问题

FinalizableReferenceQueue内部持有一个ReferenceQueue<Object> queue，并通过PhantomReference将自己也关联到queue上。然后在初始化的时候启动一个Finalizer Thread并将queue、对自己的PhantomReference以及FinalizableReference.class传递给Finalizer Thread。代码如下：FinalizableReferenceQueue.class

 

 

  1. public class FinalizableReferenceQueue implements Closeable {
  2. 	.............................
  3. 	
  4.   final ReferenceQueue<Object> queue;
  5.   final PhantomReference<Object> frqRef;
  6.   final boolean threadStarted;
  7.   
  8.   public FinalizableReferenceQueue() {
  9.     queue = new ReferenceQueue<Object>();
  10.     frqRef = new PhantomReference<Object>(this, queue);
  11.     boolean threadStarted = false;
  12.     try {
  13.       startFinalizer.invoke(null, FinalizableReference.class, queue, frqRef);
  14.       threadStarted = true;
  15.     } catch (IllegalAccessException impossible) {
  16.       throw new AssertionError(impossible); // startFinalizer() is public
  17.     } catch (Throwable t) {
  18.       logger.log(
  19.           Level.INFO,
  20.           "Failed to start reference finalizer thread."
  21.               + " Reference cleanup will only occur when new references are created.",
  22.           t);
  23.     }
  24.  
  25.     this.threadStarted = threadStarted;
  26.   }
  27.   ....................
  28. }

其中startFinalizer是一个通过反射获得的Method，代表了Finalizer类的startFinalizer静态方法，其作用是启动守护线程。该方法代码如下：

 

  1. public static void startFinalizer(Class<?> finalizableReferenceClass,
  2.       ReferenceQueue<Object> queue,
  3.       PhantomReference<Object> frqReference) {
  4.     ..............
  5.     Finalizer finalizer = new Finalizer(finalizableReferenceClass, queue, frqReference);
  6.     Thread thread = new Thread(finalizer);
  7.     thread.setName(Finalizer.class.getName());
  8.     thread.setDaemon(true);
  9.  
  10.     try {
  11.       if (inheritableThreadLocals != null) {
  12.         inheritableThreadLocals.set(thread, null);
  13.       }
  14.     } catch (Throwable t) {
  15.       logger.log(
  16.           Level.INFO,
  17.           "Failed to clear thread local values inherited by reference finalizer thread.",
  18.           t);
  19.     }
  20.  
  21.     thread.start();
  22.   }

Finalizer内部持有对FinalizableReferenceQueue传递来的queue和PhantomReference的引用，并创建一个WeakReference来监控FinalizableReference.class，其构造函数如下所示：

 

  1. private Finalizer(
  2.       Class<?> finalizableReferenceClass,
  3.       ReferenceQueue<Object> queue,
  4.       PhantomReference<Object> frqReference) {
  5.     this.queue = queue;
  6.  
  7.     this.finalizableReferenceClassReference =
  8.         new WeakReference<Class<?>>(finalizableReferenceClass);
  9.  
  10.     this.frqReference = frqReference;
  11.   }

Finalizer Thread是一个守护线程，启动后在正常循环下，从queue中获得被回收对象的引用包装，并执行其finalizeReferent方法。而当FinalizableReference.class被卸载，或者是queue中入列（enqueue）了FinalizableReferenceQueue本身时，循环就会被打破，Finalizer Thread就会退出。代码如下：Finalizer.class

 

  1. public void run() {
  2.     while (true) {
  3.       try {
  4.         if (!cleanUp(queue.remove())) {
  5.           break;
  6.         }
  7.       } catch (InterruptedException e) {
  8.         // ignore
  9.       }
  10.     }
  11.   }
  12.  
  13.   private boolean cleanUp(Reference<?> reference) {
  14.     Method finalizeReferentMethod = getFinalizeReferentMethod();
  15.     if (finalizeReferentMethod == null) {
  16.       return false;
  17.     }
  18.     do {
  19.       reference.clear();
  20.  
  21.       if (reference == frqReference) {
  22.         return false;
  23.       }
  24.  
  25.       try {
  26.         finalizeReferentMethod.invoke(reference);
  27.       } catch (Throwable t) {
  28.         logger.log(Level.SEVERE, "Error cleaning up after reference.", t);
  29.       }
  30.  
  31.     } while ((reference = queue.poll()) != null);
  32.     return true;
  33.   }

在FinalizableReferenceQueue源码的注释中提到，如果应用客户端(client)是通过动态加载或者osgi等加载的则其ClassLoader为Application ClassLoader(与默认的System ClassLoader相区别)，在这种情况下假如client有一个static变量指向FinalizableReferenceQueue实例的话，而FinalizableReferenceQueue在启动Finalizer Thread的时候直接使用默认的Application Classloader，这样会形成一个Finalizer Thread->Finalizer.class->Application Classloader->ClientClass.class->FinalizableReferenceQueue的引用关系，导致FinalizableReferenceQueue无法被GC回收，从而导致Finalizer Thread无法停止，最终导致Application Classloader无法被GC回收。

 

因此如果Guava库是被Application ClassLoader加载的话，Finalizer Thread中不应该持有对Application Classloader的引用，对此Guava的解决方案是，在FinalizableReferenceQueue中加载Finalizer类时依次尝试使用SystemClassLoader、新创建的URLClassLoader、以及Application ClassLoader来执行。除了最后一种情况，其他两者应该都可以打破Finalizer Thread对Application Classloader的引用。源代码如下：

 

  1. /** Reference to Finalizer.startFinalizer(). */
  2.   private static final Method startFinalizer;
  3.  
  4.   static {
  5.     Class<?> finalizer =
  6.         loadFinalizer(new SystemLoader(), new DecoupledLoader(), new DirectLoader());
  7.     startFinalizer = getStartFinalizer(finalizer);
  8.   }
  9. ...............................
  10.   private static Class<?> loadFinalizer(FinalizerLoader... loaders) {
  11.     for (FinalizerLoader loader : loaders) {
  12.       Class<?> finalizer = loader.loadFinalizer();
  13.       if (finalizer != null) {
  14.         return finalizer;
  15.       }
  16.     }
  17.  
  18.     throw new AssertionError();
  19.   }

其中SystemLoader、DecoupledLoader、DirectLoader都实现了接口FinalizerLoader，并实现其loadFinalizer方法，在其中各自使用ClassLoader.getSystemClassLoader()、new URLClassLoader(new URL[] {base}, null)以及直接使用Class.forName方式（也就是当前的Application ClassLoader）来实现对Finalizer.class的加载，具体代码可查看FinalizableReferenceQueue.class这里就不再一一贴出。
上面的解决方案看上去没有任何问题，然而实际执行结果如何呢？我们可以实验模拟一下这种情况，代码如下：GuavaQueueUseByDynamicApp.java

  1. public class GuavaQueueUseByDynamicApp {
  2. 	public static void main(String args[]) throws Exception{
  3. 		final ReferenceQueue<Object> rq = new ReferenceQueue<Object>();
  4. 		final Map<Object, Object> map = new HashMap<>();
  5. 		Thread thread = new Thread(() -> {
  6. 		    try {
  7. 		        WeakReference<byte[]> k;
  8. 		        while((k = (WeakReference) rq.remove()) != null) {
  9. 		            System.out.println("GC回收了:" + map.get(k));
  10. 		        }
  11. 		    } catch(InterruptedException e) {
  12. 		        //结束循环
  13. 		    }
  14. 		});
  15. 		thread.setDaemon(true);
  16. 		thread.start();
  17. 		
  18. 		ClassLoader cl = newLoader();
  19. 		System.out.println("Set application contextclassloader as: "+cl);
  20. 		Thread.currentThread().setContextClassLoader(cl);	//如果到时候不取消contextclassloader对cl的引用，则cl无法被卸载
  21. 		
  22. 		Class cls = cl.loadClass("jdktest.reference.ExecuteSomethingByFinalizableReferenceQueue");
  23. 		Object obj = cls.newInstance();
  24. 		Method method = cls.getMethod("doSomething");
  25.         method.invoke(obj);
  26. 		
  27. 		WeakReference<ClassLoader> weakReference = new WeakReference<ClassLoader>(cl, rq);
  28. 		map.put(weakReference, "Application ClassLoader");
  29. 		WeakReference<Class> weakReference1 = new WeakReference<Class>(cls, rq);
  30. 		map.put(weakReference1, "Class(ExecuteSomethingByFinalizableReferenceQueue)");
  31. 		WeakReference<Object> weakReference2 = new WeakReference<Object>(obj, rq);
  32. 		map.put(weakReference2, "Instance of ExecuteSomethingByFinalizableReferenceQueue");
  33. 		
  34. 		obj=null;
  35. 		method=null;
  36. 		cls=null;
  37. 		cl=null;
  38. 		System.out.println(Thread.currentThread()+":开始执行GC");
  39. 		System.gc();
  40. 		Thread.sleep(10000);
  41. 		
  42. 		Thread.currentThread().setContextClassLoader(null);
  43. 		
  44. 		System.out.println(Thread.currentThread()+":再次执行GC");
  45. 		System.gc();
  46. 		Thread.sleep(10000);
  47. 		System.out.println(Thread.currentThread()+":第三次执行GC");
  48. 		System.gc();
  49. 		Thread.sleep(600000);
  50. 	}
  51. 	
  52. 	static URLClassLoader newLoader() throws Exception{
  53. 		URL url1 = new File("/home/wangd/data/java/guava-23.0.jar").toURI().toURL();
  54. 		URL url2 = new File("/home/wangd/work/test/wangd/target/classes").toURI().toURL();
  55. 		URLClassLoader ucl = new URLClassLoader(new URL[] {url1, url2}, null);
  56. 	      return ucl;
  57. 	}
  58. }

 

为了更真实的模拟应用模块动态加载的情形，GuavaQueueUseByDynamicApp的运行环境中并不加载guava库

 

 

模拟的动态加载的应用模块代码如下：ExecuteSomethingByFinalizableReferenceQueue.class

  1. public class ExecuteSomethingByFinalizableReferenceQueue{
  2. 	public FinalizableReferenceQueue rq = new FinalizableReferenceQueue();
  3. 	public void doSomething() throws Exception{
  4. 		System.out.println("Just do something!");
  5. 	}
  6. }

注意public FinalizableReferenceQueue rq = new FinalizableReferenceQueue();这一句，当其修饰符变为static时会导致结果的不一样。
执行结果如下：

 

Set application contextclassloader as: java.net.URLClassLoader@7ea987ac
Just do something!
Thread[main,5,main]:开始执行GC
GC回收了:Instance of ExecuteSomethingByFinalizableReferenceQueue
Thread[main,5,main]:再次执行GC
GC回收了:Class(ExecuteSomethingByFinalizableReferenceQueue)
GC回收了:Application ClassLoader
Thread[main,5,main]:第三次执行GC

我们可见，第一次GC时，只回收了实例对象，因为此时main thread的contextClassLoader引用了Application ClassLoader，所以Application ClassLoader以及其加载的ExecuteSomethingByFinalizableReferenceQueue.class都无法被回收。当第二次GC的时候，由于执行了Thread.currentThread.setContextClassLoader(null)，因此Application ClassLoader和ExecuteSomethingByFinalizableReferenceQueue.class都变得GC Root不可达，GC就将他们都回收了。

 

 

 

假如将ExecuteSomethingByFinalizableReferenceQueue中的变量rq添加static修饰，也就是在FinalizableReferenceQueue源码注释中提到的情况时，执行结果如下：

Set application contextclassloader as: java.net.URLClassLoader@7ea987ac
Just do something!
Thread[main,5,main]:开始执行GC
GC回收了:Instance of ExecuteSomethingByFinalizableReferenceQueue
Thread[main,5,main]:再次执行GC
Thread[main,5,main]:第三次执行GC

 

这次居然在执行了Thread.currentThread.setContextClassLoader(null)以后也没有回收Application ClassLoader及其加载的ExecuteSomethingByFinalizableReferenceQueue.class。这是为什么呢，结合两者的不同，可以推测问题很有可能是守护线程Finalizer依然持有着Application ClassLoader和ExecuteSomethingByFinalizableReferenceQueue.class的引用，因此当ExecuteSomethingByFinalizableReferenceQueue中的变量FinalizableReferenceQueue rq是实例变量时，该变量指向的对象可被GC回收(Class类并不持有其实例化对象的引用)，而rq被回收会导致其启动的守护线程Finalizer Thread终止，当Finalizer Thread终止后，Application ClassLoader和ExecuteSomethingByFinalizableReferenceQueue.class就彻底不可达了，因此会在下一次GC的时候被回收。

 

而当FinalizableReferenceQueue rq是类变量的时候，该变量指向的对象不可被GC回收(Class类直接持有静态变量的引用)，形成了一个Finalizer Thread->Finalizer.class->etc.->Application Classloader->ExecuteSomethingByFinalizableReferenceQueue.class->FinalizableReferenceQueue的引用路径，阻止了FinalizableReferenceQueue对象被回收，因此也阻止了Finalizer Thread终止。

 

按照Guava源码中的说法，已经考虑到并处理了这个问题了啊，为什么还是会有这种结果呢？如果仍然存在内存泄露那么可达路径又是什么呢？另外，ClassLoader内存泄露还什么其他的方式？如何有效查找ClassLoader的内存泄露路径呢？

 

4 使用MAT分析dump文件，找出ClassLoader内存泄露的可达路径

 

MAT介绍不再多说，自行搜索，使用MAT查找ClassLoader内存泄露的相关资料参考自http://java.jiderhamn.se/2011/12/11/classloader-leaks-i-how-to-find-classloader-leaks-with-eclipse-memory-analyser-mat/

首先在程序运行时候dump出内存快照：

$ jps
$ jmap -dump:format=b,file=/home/data/testdump.bin <pid>


然后使用MAT打开该dump文件，选择open query browser->java basics->classloader explorer

 

然后在弹出的框中直接点确定，可得到ClassLoader的列表，

一一点开可看到FinalizableReferenceQueue是由Application ClassLoader(URLClassLoader@0x708e09408)加载的，而Finalizer是由新创建独立的ClassLoader(URLClassLoader@0x708e092f0)加载的。这个行为符合我们的预期：由于System ClassLoader中并没有Guava库，所以无法加载Finalizer，因此按顺序应该是新建一个URLClassLoader并加载之。接着我们要查看Application ClassLoader(URLClassLoader@0x708e09408)为什么没有被GC回收，在URLClassLoader(@0x708e09408)上右键->ClassLoader->Path to GC Roots->exclude all reference

 

 

从结果列表中可以查看到该ClassLoader的GC Roots可达路径:

 

我们发现居然还有三条可达路径，第一条是Finalizer Thread的contextClassLoader是Application ClassLoader；第二条和第三条略微复杂，都是跟访问控制上下文（AccessControlContext）相关：其中一条是Finalizer Thread从创建它的线程中继承过来的访问控制上下文（AccessControllContext）中持有父线程调用栈对应的保护域（ProtectionDomain）数组，其中一个保护域对应的ClassLoader就是Application ClassLoader；另外一条是Finalizer.class的类加载器持有的访问控制上下文（AccessControllContext）中持有的一个保护域的ClassLoader属性就是Application ClassLoader。

 

其中，AccessControlContext、ProtectionDomain都是Java内置安全体系中的概念，关于AccessControlContext、ProtectionDomain的介绍，以及在线程和类加载器创建时为何必须继承它们创建者的AccessControlContext的讨论，请参照《Java Security Architecture--Java安全体系技术文档翻译(四)》4.3，4.4两节。

 

由此可见仅仅使用Guava中的解决方案，并不能完全阻止Finalizer Thread持有对Application ClassLoader的强引用。

5 解决方案

知道了问题所在，我们接下来就考虑解决方案。其实从日常使用的角度讲，该极端问题一般不会遇到，另外如果在相关的reference统统被处理掉（finalized）以后显式的去掉对FinalizableReferenceQueue的强引用，或者执行其close方法就肯定会达到FinalizableReferenceQueue的回收和Finalizer Thread的停止。但是假如就在该极端情况下，又不取消强引用及执行其close方法，有办法让GC自动回收掉FinalizableReferenceQueue从而实现Finalizer Thread的停止和Application ClassLoader的卸载吗？

 

从上面MAT找出的结果来看，我们需要破坏掉那三条从Finalizer Thread到Application ClassLoader的可达路径。翻看上面列出的startFinalizer方法中创建Finalizer Thread时contextClassLoader和inheritedAccessControlContext统统是使用默认处理，因此导致了对Application ClassLoader的关联，因此修改startFinalizer方法如下：Finalizer.java

  1. public static void startFinalizer(
  2. 	      Class<?> finalizableReferenceClass,
  3. 	      ReferenceQueue<Object> queue,
  4. 	      PhantomReference<Object> frqReference) {
  5. 	    if (!finalizableReferenceClass.getName().equals(FINALIZABLE_REFERENCE)) {
  6. 	      throw new IllegalArgumentException("Expected " + FINALIZABLE_REFERENCE + ".");
  7. 	    }
  8.  
  9. 	    Finalizer finalizer = new Finalizer(finalizableReferenceClass, queue, frqReference);
  10. 	    Thread thread = new Thread(finalizer);
  11. 	    thread.setName(Finalizer.class.getName());
  12. 	    thread.setDaemon(true);
  13.  
  14. 	    try {
  15. 	      if (inheritableThreadLocals != null) {
  16. 	        inheritableThreadLocals.set(thread, null);
  17. 	      }
  18. 	      
  19. 	      //消除本线程从父线程继承而来的访问控制上下文
  20. 	      Field inheritedAccessControlContext = Thread.class.getDeclaredField("inheritedAccessControlContext");
  21. 	      inheritedAccessControlContext.setAccessible(true);
  22. 	      inheritedAccessControlContext.set(thread, null);
  23. 	      
  24. 	      
  25. 	    } catch (Throwable t) {
  26. 	      logger.log(
  27. 	          Level.INFO,
  28. 	          "Failed to clear thread local values inherited by reference finalizer thread.",
  29. 	          t);
  30. 	    }
  31. 	    //消除本线程的contextClassLoader与启动本线程的类的类加载器之间的关联
  32. 	    thread.setContextClassLoader(null);
  33.  
  34. 	    thread.start();
  35. 	  }

其中打了注释的部分为我们添加的代码，目的就是切断上一步找出来的第一条和第二条路径。我们使用反射机制是因为Thread并没有提供公开的API来取消继承父线程中访问控制上下文的行为。

 

另外，修改FinalizableReferenceQueue的内部静态类DecoupledLoader中的方法newLoader()，使得新创建的URLClassLoader与Application ClassLoader不再关联，代码如下：

  1. URLClassLoader newLoader(URL base) {
  2. 	    	URLClassLoader cl = new URLClassLoader(new URL[] {base}, null);
  3. 	    	
  4. 	    	try{
  5. 	    		//消除新创建的类加载器从本类的类加载器中继承的访问控制上下文
  6. 	    		Field acc = URLClassLoader.class.getDeclaredField("acc");
  7. 	    		acc.setAccessible(true);
  8. 	    		acc.set(cl, null);
  9. 	    	}catch(Exception e){
  10. 	    		e.printStackTrace();
  11. 	    	}
  12. 	      return cl;
  13. 	    }

 

其中注释部分为切断上面找出来的第三条路径，也就是新创建的类加载器与Application ClassLoader之间的关联。同样使用反射机制是因为URLClassLoader并没有提供公开的API来取消保存访问控制上下文（包括父加载器访问控制上下文）的行为。

 

 

修改完毕使用重新打包后的Guava库，执行结果如下：

Set application contextclassloader as: java.net.URLClassLoader@548c4f57
----------FinalizableReferenQueue ClassLoader:java.net.URLClassLoader@548c4f57
----------Finalizer ClassLoader:java.net.URLClassLoader@1b28cdfa
finalizer thread's classloader is:java.net.URLClassLoader@548c4f57
Just do something!
Thread[com.common.finalizablereference.Finalizer,5,main] start run a deamon thread!
Thread[main,5,main]:开始执行GC
GC回收了:Instance of ExecuteSomethingByFinalizableReferenceQueue
Thread[main,5,main]:再次执行GC
GC回收了:Class(ExecuteSomethingByFinalizableReferenceQueue)
Thread[com.common.finalizablereference.Finalizer,5,main] Class has been unloaded!!
Thread[com.common.finalizablereference.Finalizer,5,main] thread loop break;
Thread[com.common.finalizablereference.Finalizer,5,main] run out a deamon thread!
GC回收了:Application ClassLoader
Thread[main,5,main]:第三次执行GC

为了方便查看，在Finalizer Thread的run方法中添加了一些输出，这样可以方便的看到，当第一次执行GC的时候只回收了instance,因为main thread的contextClassLoader还关联着Application ClassLoader,因此大家都不会被回收，Finalizer Thread也不会停止。而第二次GC的时候，由于执行Thread.currentThread().setContextClassLoader(null)；因此Application ClassLoader，ExecuteSomethingByFinalizableReferenceQueue.class以及static属性指向的FinalizableReferenceQueue对象都被回收了，因此Finalizer Thread的循环也被打破，线程也成功关闭了。

6 总结

 

上面的解决方案肯定不是想说Guava的FinalizableReferenQueue应该像第5章解决方案中那么去用，其实更自然的使用方式就是在没必要存活的时候主动去除引用，不要让对象拥有不必要的存活范围。本文旨在通过这样的一个案例来说明ClassLoader泄露的可能原因、如何观察ClassLoader是否被卸载、如何查找ClassLoader内存泄露的路径以及如何解决这一类问题。另外，除了由Thread引发的ClassLoader内存泄露问题外，不同ClassLoader之间我们未预期到的相互引用导致的内存泄露也是相当隐蔽及棘手的问题（例如：通过AccessControllContext里的ProtectionDomain[]）。但是有了上面的一整套查找及解决的方法，相信在实际情况中遇到的这些问题也都可以一一解决。

 

 

本文的代码及测试结果均为作者在自己的环境中实验得出，结论也只是一家之言并没有严格考证，若有不当之处，还请大家多多指正。

声明：本文内容由网友自发贡献，不代表【wpsshop博客】立场，版权归原作者所有，本站不承担相应法律责任。如您发现有侵权的内容，请联系我们。转载请注明出处：https://www.wpsshop.cn/w/神奇cpp/article/detail/881424
推荐阅读
相关标签

Copyright © 2003-2013 www.wpsshop.cn 版权所有，并保留所有权利。

  

闽ICP备14008679号