Java 使用 URLClassLoader 重新加载 jar 的问题
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/3216780/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Problem reloading a jar using URLClassLoader
提问by samitgaur
I need to add plugin functionality to an existing application for certain parts of the application. I want to be able to add a jar at runtime and the application should be able to load a class from the jar without restarting the app. So far so good. I found some samples online using URLClassLoader and it works fine.
我需要为应用程序的某些部分向现有应用程序添加插件功能。我希望能够在运行时添加一个 jar，并且应用程序应该能够在不重新启动应用程序的情况下从 jar 加载一个类。到现在为止还挺好。我使用 URLClassLoader 在网上找到了一些示例，它工作正常。
I also wanted the ability to reload the same class when an updated version of the jar is available. I again found some samples and the key to achieving this as I understand is that I need to use a new classloader instance for each new load.
我还希望能够在 jar 的更新版本可用时重新加载相同的类。我再次找到了一些示例，据我所知，实现这一目标的关键是我需要为每个新加载使用一个新的类加载器实例。
I wrote some sample code but hit a NullPointerException. First let me show you guys the code:
我写了一些示例代码，但遇到了 NullPointerException。先给大家看看代码：
package test.misc;
import java.io.File;
import java.net.URL;
import java.net.URLClassLoader;
import plugin.misc.IPlugin;
public class TestJarLoading {
public static void main(String[] args) {
IPlugin plugin = null;
while(true) {
try {
File file = new File("C:\plugins\test.jar");
String classToLoad = "jartest.TestPlugin";
URL jarUrl = new URL("jar", "","file:" + file.getAbsolutePath()+"!/");
URLClassLoader cl = new URLClassLoader(new URL[] {jarUrl}, TestJarLoading.class.getClassLoader());
Class loadedClass = cl.loadClass(classToLoad);
plugin = (IPlugin) loadedClass.newInstance();
plugin.doProc();
} catch (Exception e) {
e.printStackTrace();
} finally {
try {
Thread.sleep(30000);
} catch (InterruptedException e) {
e.printStackTrace();
}
}
}
}
}
IPlugin is a simple interface with just one method doProc:
IPlugin 是一个简单的接口，只有一个方法 doProc：
public interface IPlugin {
void doProc();
}
and jartest.TestPlugin is an implementation of this interface where doProc just prints out some statements.
而 jartest.TestPlugin 是这个接口的一个实现，其中 doProc 只是打印出一些语句。
Now, I package the jartest.TestPlugin class into a jar called test.jar and place it under C:\plugins and run this code. The first iteration runs smoothly and the class loads without issues.
现在，我将 jartest.TestPlugin 类打包到一个名为 test.jar 的 jar 中，并将其放在 C:\plugins 下并运行此代码。第一次迭代运行顺利，类加载没有问题。
When the program is executing the sleep statement, I replace C:\plugins\test.jar with a new jar containing an updated version of the same class and wait for the next iteration of while. Now here's what I don't understand. Sometimes the updated class gets reloaded without issues i.e. the next iteration runs fine. But sometimes, I see an exception thrown:
当程序执行 sleep 语句时，我将 C:\plugins\test.jar 替换为包含同一类的更新版本的新 jar，并等待下一次迭代 while。现在这是我不明白的地方。有时更新的类被重新加载而没有问题，即下一次迭代运行良好。但有时，我会看到抛出异常：
java.lang.NullPointerException
at java.io.FilterInputStream.close(FilterInputStream.java:155)
at sun.net.www.protocol.jar.JarURLConnection$JarURLInputStream.close(JarURLConnection.java:90)
at sun.misc.Resource.getBytes(Resource.java:137)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:256)
at java.net.URLClassLoader.accessURLClassLoader -> URLClassPath ucp -> ArrayList<Loader> loaders
JarLoader -> JarFile jar -> jar.close()
0(URLClassLoader.java:56)
at java.net.URLClassLoader.run(URLClassLoader.java:195)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
at java.lang.ClassLoader.loadClass(ClassLoader.java:252)
at test.misc.TestJarLoading.main(TestJarLoading.java:22)
I have searched on the net and scratched my head but can't really arrive at any conclusion as to why this exception is thrown and that too - only sometimes, not always.
我在网上搜索过，摸不着头脑，但无法真正得出关于为什么会抛出这个异常以及为什么会抛出任何结论 - 只是有时，并非总是如此。
I need your experience and expertise to understand this. What's wrong with this code? Please help!!
我需要你的经验和专业知识来理解这一点。这段代码有什么问题？请帮忙！！
Let me know if you need any more info. Thanks for looking!
如果您需要更多信息，请告诉我。感谢您的关注！
采纳答案by Ryan Fernandes
回答by samitgaur
For everyone's benefit, let me summarize the real problem and the solution that worked for me.
为了大家的利益，让我总结一下真正的问题和对我有用的解决方案。
As Ryan pointed out, there is a bugin JVM, which affects Windows Platform. URLClassLoaderdoes not close the open jar files after it opens them for loading classes, effectively locking the jar files. The jar files can't be deleted or replaced.
正如 Ryan 所指出的，JVM 中存在一个bug，它会影响 Windows 平台。URLClassLoader在打开它们以加载类后不会关闭打开的 jar 文件，从而有效地锁定了 jar 文件。无法删除或替换 jar 文件。
The solution is simple: close the open jar files after they've been read. However, to get a handle to the open jar files, we need to use reflection since the properties we need to traverse down are not public. So we traverse down this path
解决方案很简单：在读取后关闭打开的 jar 文件。但是，要获得打开的 jar 文件的句柄，我们需要使用反射，因为我们需要向下遍历的属性不是公开的。所以我们沿着这条路走下去
public class MyURLClassLoader extends URLClassLoader {
public PluginClassLoader(URL[] urls, ClassLoader parent) {
super(urls, parent);
}
/**
* Closes all open jar files
*/
public void close() {
try {
Class clazz = java.net.URLClassLoader.class;
Field ucp = clazz.getDeclaredField("ucp");
ucp.setAccessible(true);
Object sunMiscURLClassPath = ucp.get(this);
Field loaders = sunMiscURLClassPath.getClass().getDeclaredField("loaders");
loaders.setAccessible(true);
Object collection = loaders.get(sunMiscURLClassPath);
for (Object sunMiscURLClassPathJarLoader : ((Collection) collection).toArray()) {
try {
Field loader = sunMiscURLClassPathJarLoader.getClass().getDeclaredField("jar");
loader.setAccessible(true);
Object jarFile = loader.get(sunMiscURLClassPathJarLoader);
((JarFile) jarFile).close();
} catch (Throwable t) {
// if we got this far, this is probably not a JAR loader so skip it
}
}
} catch (Throwable t) {
// probably not a SUN VM
}
return;
}
}
The code to close the open jar files can be added to a close() method in a class extending URLClassLoader:
可以将关闭打开的 jar 文件的代码添加到扩展 URLClassLoader 的类中的 close() 方法中：
URL jarUrl = new URL("file:" + file.getAbsolutePath());
(This code was taken from the second link that Ryan posted. This code is also posted on the bug report page.)
（此代码取自 Ryan 发布的第二个链接。此代码也发布在错误报告页面上。）
However, there's a catch:For this code to work and be able to get a handle to the open jar files to close them, the loader used to load the classes from the file by URLClassLoader implementation has to be a JarLoader. Looking at the source codeof URLClassPath(method getLoader(URL url)), I noticed that it uses a JARLoader only if the file string used to create the URL does not end in "/". So, the URL must be defined like this:
但是，有一个问题：要使此代码工作并能够获取打开的 jar 文件的句柄以关闭它们，用于通过 URLClassLoader 实现从文件加载类的加载程序必须是JarLoader. 纵观源代码的URLClassPath（方法getLoader(URL url)），我注意到，它采用了JARLoader只有文件字符串用来创建URL中的“/”并没有结束。因此，必须像这样定义 URL：
void loadAndInstantiate() {
MyURLClassLoader cl = null;
try {
File file = new File("C:\jars\sample.jar");
String classToLoad = "com.abc.ClassToLoad";
URL jarUrl = new URL("file:" + file.getAbsolutePath());
cl = new MyURLClassLoader(new URL[] {jarUrl}, getClass().getClassLoader());
Class loadedClass = cl.loadClass(classToLoad);
Object o = loadedClass.getConstructor().newInstance();
} finally {
if(cl != null)
cl.close();
}
}
The overall class loading code should look something like this:
整个类加载代码应如下所示：
class MyReloaderMain {
...
//assuming ___BASE_DIRECTORY__/lib for jar and ___BASE_DIRECTORY__/conf for configuration
String dirBase = ___BASE_DIRECTORY__;
File file = new File(dirBase, "lib");
String[] jars = file.list();
URL[] jarUrls = new URL[jars.length + 1];
int i = 0;
for (String jar : jars) {
File fileJar = new File(file, jar);
jarUrls[i++] = fileJar.toURI().toURL();
System.out.println(fileJar);
}
jarUrls[i] = new File(dirBase, "conf").toURI().toURL();
URLClassLoader classLoader = new URLClassLoader(jarUrls, MyReloaderMain.class.getClassLoader());
// this is required to load file (such as spring/context.xml) into the jar
Thread.currentThread().setContextClassLoader(classLoader);
Class classToLoad = Class.forName("my.app.Main", true, classLoader);
instance = classToLoad.newInstance();
Method method = classToLoad.getDeclaredMethod("start", args.getClass());
Object result = method.invoke(instance, args);
...
}
Update:JRE 7 has introduced a close()method in the class URLClassLoaderwhich may have solved this issue. I haven't verified it.
更新：JRE 7close()在类中引入了一个方法URLClassLoader，可能已经解决了这个问题。我没有验证过。
回答by venergiac
This is an updatetested on java 7 with success. Now the URLClassLoaderworks fine for me
这是在java 7 上测试成功的更新。现在对我来说很好用URLClassLoader
MyReloader
我的重载器
classLoader.close();
Close and Restart the ClassReloader
关闭并重新启动 ClassReloader
then update your jar and call
然后更新你的罐子并打电话
##代码##then you can restart the app with the new version.
然后您可以使用新版本重新启动应用程序。
Do not include your jar into your base class loader
不要将您的 jar 包含在您的基类加载器中
Do not include your jar into your base class loader "MyReloaderMain.class.getClassLoader()" of the "MyReloaderMain", in other words develop 2 project with 2 jars one for "MyReloaderMain" and the other one for your real application without dependency between the two, or you will not able to understand who i loading what.
不要将您的 jar 包含在“ MyReloaderMain.class.getClassLoader()”的基类加载器“ ”中MyReloaderMain，换句话说，用 2 个 jar 开发 2 个项目，一个用于“ MyReloaderMain”，另一个用于您的实际应用程序，两者之间没有依赖关系，否则您将无法了解谁我加载什么。
回答by Nicolas Filotto
Starting from Java 7, you indeed have a close()method in URLClassLoaderbut it is not enough to release completely the jar files if you call directly or indirectly methods of type ClassLoader#getResource(String), ClassLoader#getResourceAsStream(String)or ClassLoader#getResources(String). Indeed by default, the JarFileinstances are automatically stored into the cache of JarFileFactoryin case we call directly or indirectly one of the previous methods and those instances are not released even if we call java.net.URLClassLoader#close().
从 Java 7 开始，您确实有一个close()方法 inURLClassLoader但如果您直接或间接调用类型ClassLoader#getResource(String), ClassLoader#getResourceAsStream(String)or 的方法，则完全释放 jar 文件是不够的 ClassLoader#getResources(String)。事实上，默认情况下，JarFile实例会自动存储到缓存中JarFileFactory，以防我们直接或间接调用前面的方法之一，并且即使我们调用 也不会释放这些实例java.net.URLClassLoader#close()。
So a hack is still needed in this particular case even with Java 1.8.0_74, here is my hack https://github.com/essobedo/application-manager/blob/master/src/main/java/com/github/essobedo/appma/core/util/Classpath.java#L83that I use here https://github.com/essobedo/application-manager/blob/master/src/main/java/com/github/essobedo/appma/core/DefaultApplicationManager.java#L388. Even with this hack, I still had to call the GC explicitly to fully release the jar files as you can see here https://github.com/essobedo/application-manager/blob/master/src/main/java/com/github/essobedo/appma/core/DefaultApplicationManager.java#L419
因此，即使使用 Java 1.8.0_74，在这种特殊情况下仍然需要 hack，这是我的 hack https://github.com/essobedo/application-manager/blob/master/src/main/java/com/github/essobedo我在这里使用的/appma/core/util/Classpath.java#L83 https://github.com/essobedo/application-manager/blob/master/src/main/java/com/github/essobedo/appma/core/ DefaultApplicationManager.java#L388。即使有了这个 hack，我仍然必须显式调用 GC 以完全释放 jar 文件，如您在此处所见https://github.com/essobedo/application-manager/blob/master/src/main/java/com/ github/essobedo/appma/core/DefaultApplicationManager.java#L419
回答by dalvarezmartinez1
The error is still present in jdk1.8.0_25 on Windows. Although @Nicolas' answer helps, I hit a ClassNotFoundfor sun.net.www.protocol.jar.JarFileFactorywhen running it on WildFly, and several vm crashes while debugging some box tests...
错误仍然存在于jdk1.8.0_25 上Windows。尽管@Nicolas 的回答有所帮助，但我在 WildFly 上运行它时遇到了一个ClassNotFoundfor sun.net.www.protocol.jar.JarFileFactory，并且在调试一些框测试时有几个虚拟机崩溃了......
Therefore I ended up extracting the part of the code which deals with loading and unloading, to an external jar. From the main code I just call this with java -jar....all looks fine for now.
因此，我最终将处理加载和卸载的代码部分提取到外部 jar 中。从主代码中，我只是调用它，java -jar....现在看起来一切都很好。
NOTE: Windows does release the locks on the loaded jar files when the jvm exits, that is why this works.
注意：当 jvm 退出时，Windows 确实会释放对加载的 jar 文件的锁定，这就是为什么这样做有效。
