JAR文件句柄：烦恼后清理！

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

Windows：支持禁地

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

TDD FTW

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

然后，事情发疯了 。

拆解不再了。

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

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

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

笨蛋

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

寻找泄漏

不行我没有

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

又名我的死神文件句柄

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

此“泄漏转储程序”部分受我们的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 ，我可以浏览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(); } } } }

如果（因为，因为） 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还允许您默认禁用所有后续连接的缓存：

 /** * 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; }

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

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

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

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

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

反思救援！

多亏了反射，我所需要的只是一个小的“桥梁”，它将代表我访问和调用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());

就在删除临时目录之前。

那么，要点是什么？

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

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

阿迪耶

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