JDK ClassLoader.getResourceAsStream坏了吗？(未关闭的资源)
我将尝试证明ClassLoader.getResourceAsStream() 正在打开两个，关闭任何一个，并且只向客户端返回一个。**我的逻辑正确吗？JDK的源代码是从jdk1.8.0_25中选择的。
我已经进入了使用Spring ClassPathResource in interval (original question)的未关闭资源问题，即使用ClassLoader.getResourceAsStream将InputStream获取到属性文件。
经过调查，我发现classLoader.getResourceAsStream通过URL url = getResource(name);获得了一个URL，然后它打开了这个流，但是已经打开了这个流。ClassLoader的JDK源
public InputStream getResourceAsStream(String name) {
URL url = getResource(name); /* SILENTLY OPENS AND DON'T CLOSES STREAM */
try {
return url != null ? url.openStream() : null; /* SECOND OPEN !!! */
} catch (IOException e) {
return null;
}
}如果我们将close() InputStream提供的方式，我们将只关闭由url.openStream()打开的流。资料来源：
public final InputStream openStream() throws java.io.IOException {
return openConnection().getInputStream();
}我假设，JDK的问题是，JDK在URL url = getResource(name) 中以静默方式打开一个流，以获取进一步用于创建**(返回到客户端)流**的URL对象。查看此方法的来源：
public URL getResource(String name) {
URL url;
if (parent != null) {
url = parent.getResource(name);
} else {
url = getBootstrapResource(name); <---- we end up calling that method
}
if (url == null) {
url = findResource(name);
}
return url;
}现在，在Resource**!**：getBootstrapResource(name)中，当我们将Resource转换为URL 时，忘记了在中打开的流。
private static URL getBootstrapResource(String name) {
URLClassPath ucp = getBootstrapClassPath();
Resource res = ucp.getResource(name); <---- OPENING STREAM [see further]
return res != null ? res.getURL() : null; <--- LOSING close() CAPABILITY
}为什么ucp.getResource(name);要开放资源？让我们看看这个方法：this.getResource(var1, true);，它将委托给：
public Resource getResource(String var1, boolean var2) {
if(DEBUG) {
System.err.println("URLClassPath.getResource(\"" + var1 + "\")");
}
URLClassPath.Loader var3;
for(int var4 = 0; (var3 = this.getLoader(var4)) != null; ++var4) {
Resource var5 = var3.getResource(var1, var2); <-------- OPENING STREAM
if(var5 != null) {
return var5;
}
}
return null;
}为什么Resource var5 = var3.getResource(var1, var2);要打开流？进一步看：
Resource getResource(final String var1, boolean var2) {
final URL var3;
try {
var3 = new URL(this.base, ParseUtil.encodePath(var1, false));
} catch (MalformedURLException var7) {
throw new IllegalArgumentException("name");
}
final URLConnection var4;
try {
if(var2) {
URLClassPath.check(var3);
}
var4 = var3.openConnection(); <------------ OPENING STREAM
InputStream var5 = var4.getInputStream();
if(var4 instanceof JarURLConnection) {
JarURLConnection var6 = (JarURLConnection)var4;
this.jarfile = URLClassPath.JarLoader.checkJar(var6.getJarFile());
}
} catch (Exception var8) {
return null;
}
return new Resource() {
public String getName() {
return var1;
}
public URL getURL() {
return var3;
}
public URL getCodeSourceURL() {
return Loader.this.base;
}
public InputStream getInputStream() throws IOException {
return var4.getInputStream();
}
public int getContentLength() throws IOException {
return var4.getContentLength();
}
};
}我们可以看到没有关闭的openConnection()和getInputStream()，并且在返回Resource的所有调用中后退--我们最终只使用包装在Resource中的getURL()方法而没有关闭-- InputStream只是使用URL对象来打开jet另一个InputStream并将其返回给客户机(客户机可以关闭这个InputStream，但是我们以第一个未关闭的流结束)。
那么，是ClassLaoder.getResourceAsStream因资源泄漏而中断的吗？
实用方面:我在try-with-resources块中使用try-with-resources，并且在生产中仍然存在未关闭的资源问题，文件名每30秒加载一次。此外，垃圾回收中的所有资源都是关闭的，这与finalize()方法中的文件流finalize()一致。
回答 1
Stack Overflow用户
发布于 2015-02-13 10:25:19
我做了一个简单的测试程序来验证实际的行为：
System.out.println(System.getProperty("java.version"));
URL testURL = new URL("test", null, 0, "/", new URLStreamHandler() {
protected URLConnection openConnection(URL u) throws IOException {
System.out.println("creating connection to "+u);
return new URLConnection(u) {
InputStream is;
public void connect(){}
@Override
public InputStream getInputStream() throws IOException {
System.out.println("getInputStream() for "+u);
if(is==null) is=new InputStream() {
boolean open=true;
@Override
public void close() throws IOException {
if(!open) return;
System.out.println("One InputStream for "+u+" closed");
open=false;
}
public int read() { return -1; }
};
else System.out.println("COULD be shared");
return is;
}
};
}
});
System.out.println("\n trying new ClassLoader");
try(URLClassLoader newlClassLoader=new URLClassLoader(new URL[]{ testURL });
InputStream is=newlClassLoader.getResourceAsStream("foo")) {}
System.out.println("\n trying System ClassLoader");
try {
Method m=URLClassLoader.class.getDeclaredMethod("addURL", URL.class);
m.setAccessible(true);
m.invoke(ClassLoader.getSystemClassLoader(), testURL);
} catch(Exception ex) { ex.printStackTrace(); }
try(InputStream is=ClassLoader.getSystemResourceAsStream("foo")) {}
System.out.println("\n trying bootstrap ClassLoader");
try {
Method m=ClassLoader.class.getDeclaredMethod("getBootstrapClassPath");
m.setAccessible(true);
Object bootstrap = m.invoke(null);
m=bootstrap.getClass().getDeclaredMethod("addURL", URL.class);
m.setAccessible(true);
m.invoke(bootstrap, testURL);
} catch(Exception ex) { ex.printStackTrace(); }
try(InputStream is=ClassLoader.getSystemClassLoader().getResourceAsStream("foo")) {}在我的机器上使用(用1.8.0_05，1.8.0_20和1.8.0_40测试)打印
trying new ClassLoader
creating connection to test:/foo
getInputStream() for test:/foo
One InputStream for test:/foo closed
creating connection to test:/foo
getInputStream() for test:/foo
One InputStream for test:/foo closed
trying System ClassLoader
creating connection to test:/foo
getInputStream() for test:/foo
One InputStream for test:/foo closed
creating connection to test:/foo
getInputStream() for test:/foo
One InputStream for test:/foo closed
trying bootstrap ClassLoader
creating connection to test:/foo
getInputStream() for test:/foo
creating connection to test:/foo
getInputStream() for test:/foo
One InputStream for test:/foo closed因此，从这个测试中，我可以得出结论，资源确实被打开了两次，但对于通过用户类路径和其他ClassLoader访问的所有资源也正确地关闭了，因此在这些情况下没有资源泄漏。
有关引导资源行为的代码分析是正确的，存在资源泄漏，但对于应用程序所需的资源通常不会发生这种情况，因为这些资源应该可以通过用户类路径访问。ClassLoader首先尝试它们的父类，但是您的资源不应该在引导类路径中找到，因此该尝试应该返回null，而不是打开任何资源。
因此，确保应用程序特定的资源不能通过JRE的引导类路径访问至关重要，例如，不要操作引导类路径，也不要将资源放入JRE的扩展目录中。这也适用于上面的测试代码，如果您更改了测试的顺序，即首先修补引导类路径，所有测试都会显示一个泄漏，因为所有查找都首先尝试它们的父程序，最后是引导加载程序。
https://stackoverflow.com/questions/28496044
复制相似问题
腾讯云开发者
