怎么清理句柄_JAR文件句柄：混乱后清理！

系统管理员 2023-02-25 03:59 193阅读 0赞

怎么清理句柄

在Ultra ESB中，我们使用特殊的[热交换类加载器][Link 1] ，该[加载][Link 1]器使我们可以按需重新加载Java类。 这使我们能够从字面上[热交换我们的部署单元][Link 2] \-加载，卸载，使用更新的类重新加载，以及正常地逐步退出-无需重启JVM。

![format_png][]

## Windows：支持禁地 ##

在[Ultra ESB Legacy中][Ultra ESB Legacy] ，加载程序在Windows上运行良好，但在较新的[X版本上][X] ，似乎出现了一些问题。 我们不支持将Windows作为目标平台，因此并没有太大的意义-直到最近，当我们决定在Windows上支持非生产发行版时。 （我们的[企业集成IDE UltraStudio][IDE UltraStudio]在Windows上[可以][IDE UltraStudio]很好地运行，因此Windows开发人员都可以使用。）

![format_png 1][]

## TDD FTW ##

修复类加载器很容易，所有测试都通过了； 但是我想用一些额外的测试来支持我的修正，所以我写了一些新的测试。 其中大多数涉及在系统temp目录下的子目录中创建一个新的JAR文件，并使用热交换类加载器加载放置在JAR中的不同工件。 为了获得更多有关最佳做法的功劳，我还确保添加一些清理逻辑，以通过[`FileUtils.deleteDirectory()`][FileUtils.deleteDirectory]删除temp子目录。

然后，事情变*糟了* 。

## 拆解不再了。 ##

在Linux和Windows中，所有测试均通过了测试。 但是最终的拆卸逻辑在Windows中失败了，就在我删除temp子目录的那一刻。

在Windows上，我没有`lsof`的奢华； 幸运的是， [Sysinternals][]已经有了我需要的东西： [`handle64`][handle64] 。

查找罪魁祸首非常容易：在删除目录树之前，在`tearDown()`一个断点，然后运行`handle64 {my-jar-name}.jar` 。

笨蛋

我的测试Java进程持有测试JAR文件的句柄。

## 寻找泄漏 ##

![format_png 2][]

不行 我没有

自然，我的第一个怀疑者是类加载器本身。 我花了将近半小时反复遍历类加载器代码库。 没运气。 一切似乎都坚如磐石。

## 又名我的死神文件句柄 ##

我最好的镜头是看是什么代码打开了JAR文件的处理程序。 因此，我为Java的`FileInputStream`和`FilterInputStream`编写[了一个快速处理的补丁程序][Link 3] ，该[补丁程序][Link 3]将转储获取时间的堆栈跟踪快照。 每当线程保持流打开时间过长时。

此“泄漏转储程序”部分受[我们的JDBC连接池的][JDBC]启发，该[连接池][JDBC]检测到未释放的连接（受宽限期限制），然后转储借用它的线程的堆栈跟踪-回到被借用的时间。 （荣誉给[Sachini][] ，我以前的同事，实习生[AdroitLogic][] 。）

## 泄漏，裸露！ ##

果然，堆栈跟踪揭示了罪魁祸首：

id: 174 created: 1570560438355  --filter-- 
       java.io.FilterInputStream.<init>(FilterInputStream.java: 13 ) 
       java.util.zip.InflaterInputStream.<init>(InflaterInputStream.java: 81 ) 
       java.util.zip.ZipFile$ZipFileInflaterInputStream.<init>(ZipFile.java: 408 ) 
       java.util.zip.ZipFile.getInputStream(ZipFile.java: 389 ) 
       java.util.jar.JarFile.getInputStream(JarFile.java: 447 ) 
       sun.net.www.protocol.jar.JarURLConnection.getInputStream(JarURLConnection.java: 162 ) 
       java.net.URL.openStream(URL.java: 1045 ) 
       org.adroitlogic.x.base.util.HotSwapClassLoader.loadSwappableClass(HotSwapClassLoader.java: 175 ) 
       org.adroitlogic.x.base.util.HotSwapClassLoader.loadClass(HotSwapClassLoader.java: 110 ) 
       org.adroitlogic.x.base.util.HotSwapClassLoaderTest.testServiceLoader(HotSwapClassLoaderTest.java: 128 ) 
       sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) 
       sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java: 62 ) 
       sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java: 43 ) 
       java.lang.reflect.Method.invoke(Method.java: 498 ) 
       org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java: 86 ) 
       org.testng.internal.Invoker.invokeMethod(Invoker.java: 643 ) 
       org.testng.internal.Invoker.invokeTestMethod(Invoker.java: 820 ) 
       org.testng.internal.Invoker.invokeTestMethods(Invoker.java: 1128 ) 
       org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java: 129 ) 
       org.testng.internal.TestMethodWorker.run(TestMethodWorker.java: 112 ) 
       org.testng.TestRunner.privateRun(TestRunner.java: 782 ) 
       org.testng.TestRunner.run(TestRunner.java: 632 ) 
       org.testng.SuiteRunner.runTest(SuiteRunner.java: 366 ) 
       org.testng.SuiteRunner.runSequentially(SuiteRunner.java: 361 ) 
       org.testng.SuiteRunner.privateRun(SuiteRunner.java: 319 ) 
       org.testng.SuiteRunner.run(SuiteRunner.java: 268 ) 
       org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java: 52 ) 
       org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java: 86 ) 
       org.testng.TestNG.runSuitesSequentially(TestNG.java: 1244 ) 
       org.testng.TestNG.runSuitesLocally(TestNG.java: 1169 ) 
       org.testng.TestNG.run(TestNG.java: 1064 ) 
       org.testng.IDEARemoteTestNG.run(IDEARemoteTestNG.java: 72 ) 
       org.testng.RemoteTestNGStarter.main(RemoteTestNGStarter.java: 123 )

## 知道了！ ##

java.io.FilterInputStream.<init>(FilterInputStream.java: 13 ) 
       ... 
       sun.net.www.protocol.jar.JarURLConnection.getInputStream(JarURLConnection.java: 162 ) 
       java.net.URL.openStream(URL.java: 1045 ) 
       org.adroitlogic.x.base.util.HotSwapClassLoader.loadSwappableClass(HotSwapClassLoader.java: 175 )

但是，这并不能说明全部情况。 如果`URL.openStream()`打开JAR，为什么我们从try-with-resources块返回时却没有关闭它？

try (InputStream is = jarURI.toURL().openStream()) { 
                 byte [] bytes = IOUtils.toByteArray(is); 
                 Class<?> clazz = defineClass(className, bytes, 0 , bytes.length); 
                 ... 
                 logger.trace( 15 , "Loaded class {} as a swappable class" , className); 
                 return clazz; 
             } catch (IOException e) { 
                 logger.warn( 16 , "Class {} located as a swappable class, but couldn't be loaded due to : {}, " + 
                         "trying to load the class as a usual class" , className, e.getMessage()); 
                 ... 
             }

## 疯狂： ##

感谢[Sun Microsystems使其成为OSS][Sun Microsystems_OSS] ，我可以浏览JDK源代码，直到这个**令人震惊的**评论–一直到`java.net.URLConnection` ：

private static boolean defaultUseCaches = true ; 
        /** 
          * If <code>true</code>, the protocol is allowed to use caching 
          * whenever it can. If <code>false</code>, the protocol must always 
          * try to get a fresh copy of the object. 
          * <p> 
          * This field is set by the <code>setUseCaches</code> method. Its 
          * value is returned by the <code>getUseCaches</code> method. 
          * <p> 
          * Its default value is the value given in the last invocation of the 
          * <code>setDefaultUseCaches</code> method. 
          * 
          * @see    java.net.URLConnection#setUseCaches(boolean) 
          * @see    java.net.URLConnection#getUseCaches() 
          * @see    java.net.URLConnection#setDefaultUseCaches(boolean) 
          */ 
         protected boolean useCaches = defaultUseCaches;

## 是的，Java ##

来自`sun.net.www.protocol.jar.JarURLConnection` ：

JarURLInputStream class extends FilterInputStream { 
             JarURLInputStream(InputStream var2) { 
                 super (var2); 
             } 
             public void close() throws IOException { 
                 try { 
                     super .close(); 
                 } finally { 
                     if (!JarURLConnection. this .getUseCaches()) { 
                         JarURLConnection. this .jarFile.close(); 
                     } 
                 } 
             } 
         }

![format_png 3][]

如果（ *因为* ， *因为* ） `useCaches`在默认情况下为`true` ，那么我们感到非常惊讶！

## 让Java缓存其JAR，但不要破坏我的测试！ ##

JAR缓存可能会提高性能。 但这是否意味着我应该在此之后停止清理-并且在每次测试后都留下杂散的文件？

（当然，我可以说`file.deleteOnExit()` ；但是由于我正在处理目录层次结构，因此不能保证顺序删除所有内容，并且会保留未删除的目录。）

因此，我想要一种清理JAR缓存的方法–或至少清除我的JAR条目； 完成之后，但在JVM关闭之前。

## 完全禁用JAR缓存-可能不是一个好主意！ ##

`URLConnection`确实提供了一种避免缓存连接条目的选项：

/** 
          * Sets the default value of the <code>useCaches</code> field to the 
          * specified value. 
          * 
          * @param  defaultusecaches  the new value. 
          * @see    #getDefaultUseCaches() 
          */ 
         public void setDefaultUseCaches( boolean defaultusecaches) { 
             defaultUseCaches = defaultusecaches; 
         }

如上所述，如果可以对每个文件/ URL禁用缓存，那将是完美的。 我们的类加载器在打开JAR时会立即缓存所有条目，因此不再需要再次打开/读取该文件。 但是，一旦打开JAR，就无法在其上禁用缓存；否则，将无法对其进行缓存。 因此，一旦我们的类加载器打开了JAR，就不会摆脱缓存的文件句柄-直到JVM本身关闭！

`URLConnection`还允许您默认禁用所有后续连接的缓存：

但是，如果您一次禁用它，则从那时起，整个JVM可能会受到影响-因为它可能适用于所有基于`URLConnection`的实现。 就像我之前说过的那样，这可能会妨碍性能-更不用说使测试脱离启用缓存的实际行为了。

## 在兔子洞下（再次！）：从 ##

侵入性最小的选项是在我知道完成后从缓存中删除我自己的JAR。

好消息是，缓存`sun.net.www.protocol.jar.JarFileFactory`已经具有执行该工作的`close(JarFile)`方法。

但是可悲的是，缓存类是程序包专用的。 意味着无法在我的测试代码中进行操作。

## 反思救援！ ##

![format_png 4][]

多亏了反射，我所需要的只是一个小的“桥梁”，它将代表我访问和调用`jarFactory.close(jarFile)` ：

JarBridge { class JarBridge { 
         static void closeJar(URL url) throws Exception { 
             // JarFileFactory jarFactory = JarFileFactory.getInstance(); 
             Class<?> jarFactoryClazz = Class.forName( "sun.net.www.protocol.jar.JarFileFactory" ); 
             Method getInstance = jarFactoryClazz.getMethod( "getInstance" ); 
             getInstance.setAccessible( true ); 
             Object jarFactory = getInstance.invoke(jarFactoryClazz); 
             // JarFile jarFile = jarFactory.get(url); 
             Method get = jarFactoryClazz.getMethod( "get" , URL. class ); 
             get.setAccessible( true ); 
             Object jarFile = get.invoke(jarFactory, url); 
             // jarFactory.close(jarFile); 
             Method close = jarFactoryClazz.getMethod( "close" , JarFile. class ); 
             close.setAccessible( true ); 
             //noinspection JavaReflectionInvocation 
             close.invoke(jarFactory, jarFile); 
             // jarFile.close(); 
             ((JarFile) jarFile).close(); 
         }  }

在测试中，我只需要说：

JarBridge.closeJar(jarPath.toUri().toURL());

就在删除临时目录之前。

![format_png 5][]

## 那么，要点是什么？ ##

如果您不直接处理JAR文件，那么对您来说无济于事。 但是如果是这样，您可能会遇到这种晦涩的“使用中的文件”错误。 （这对于其他基于`URLConnection`的流同样适用。）

如果您碰巧像我以前那样（不幸），请回想一下，一个臭名昭著的博客写了一些[骇人的“ leak dumper”补丁JAR][leak dumper_JAR] ，可以确切地告诉您JAR（或非JAR）泄漏的位置。

阿迪耶

> 翻译自: [https://www.javacodegeeks.com/2019/10/jar-file-handles-clean-up-after-your-mess.html][https_www.javacodegeeks.com_2019_10_jar-file-handles-clean-up-after-your-mess.html]

怎么清理句柄

[Link 1]: http://blog.ruwan.org/2012/12/dynamic-hot-swap-environment-inside.html
[Link 2]: https://developer.adroitlogic.com/ultraesb-legacy/docs/2.6.1/architecture-and-design/deployment-unit.html#DeploymentUnit-HotUpdate
[format_png]: /images/20230209/642f5a1f9a4f47df9228da97060ce320.png
[Ultra ESB Legacy]: https://developer.adroitlogic.com/ultraesb-legacy/docs/2.6.1/
[X]: https://developer.adroitlogic.com/project-x/docs/17.07/
[IDE UltraStudio]: https://www.adroitlogic.com/products/ultrastudio
[format_png 1]: /images/20230209/c1dcbd772de74c68b73ad18347f13b1b.png
[FileUtils.deleteDirectory]: https://commons.apache.org/proper/commons-io/javadocs/api-2.5/org/apache/commons/io/FileUtils.html#deleteDirectory%28java.io.File%29
[Sysinternals]: https://docs.microsoft.com/en-us/sysinternals/
[handle64]: https://docs.microsoft.com/en-us/sysinternals/downloads/handle
[format_png 2]: /images/20230209/81f0b4a9cdc34ef1b143de1a79db9ae3.png
[Link 3]: https://github.com/janakaud/file-leak-detector
[JDBC]: https://bitbucket.org/adroitlogic/ultracp
[Sachini]: https://www.mrt.ac.lk/web/datasearch/members/ms-sachini-herath
[AdroitLogic]: https://www.adroitlogic.com/products/
[Sun Microsystems_OSS]: https://www.quora.com/When-did-Java-become-open-source
[format_png 3]: /images/20230209/2cad6d009d0e4e829ed9a69c8955be8a.png
[format_png 4]: http://imgconvert.csdnimg.cn/aHR0cHM6Ly93d3cuamF2YWNvZGVnZWVrcy5jb20vd3AtY29udGVudC91cGxvYWRzLzIwMTkvMTAvdW5uYW1lZC0xLmpwZw?x-oss-process=image/format,png
[format_png 5]: http://imgconvert.csdnimg.cn/aHR0cHM6Ly93d3cuamF2YWNvZGVnZWVrcy5jb20vd3AtY29udGVudC91cGxvYWRzLzIwMTkvMTAvNzFUY2FWV3ZCc0wuX1NYNDY2Xy5qcGc?x-oss-process=image/format,png
[leak dumper_JAR]: https://github.com/janakaud/file-leak-detector/blob/master/README.adoc
[https_www.javacodegeeks.com_2019_10_jar-file-handles-clean-up-after-your-mess.html]: https://www.javacodegeeks.com/2019/10/jar-file-handles-clean-up-after-your-mess.html