问加载使用本机代码的多个Java类版本

EN

在检查Open 7实现时，似乎是的，加载使用本机代码的多个版本的将工作：

库加载

关键的信息是，System.load是如何表现的？该方法的实现将依赖于系统，但各种实现的语义应该是相同的。

1. System.load委托给包-私有方法Runtime.load0。
2. Runtime.load0委托给包-私有静态方法ClassLoader.loadLibrary。
3. ClassLoader.loadLibrary将委托给私有静态方法ClassLoader.loadLibrary0。
4. ClassLoader.loadLibrary0创建包的对象-私有内部类ClassLoader.NativeLibrary，并将其委托给它的load方法。
5. ClassLoader.NativeLibrary.load是一个本机方法，它将委托给函数JVM_LoadLibrary。
6. JVM_LoadLibrary委托给os::dll_load。
7. os::dll_load是系统依赖的。
8. os::dll_load将委托给dlopen系统调用，从而提供RTLD_LAZY选项。
9. 默认情况下，Linux变体的dlopen系统调用具有RTLD_LOCAL行为，因此共享库加载了RTLD_LOCAL语义。
10. RTLD_LOCAL语义是指加载库中的符号不能用于随后加载的库的(自动)符号解析。也就是说，符号不进入全局命名空间，不同的库可以在不产生冲突的情况下定义相同的符号。共享库甚至可以毫无问题地拥有相同的内容。。
11. 因此，如果不同的共享库(由不同的类加载器加载)定义相同的符号(对于本机方法具有相同的extern函数名称)并不重要: JRE和JVM共同避免名称冲突。

本机函数查找

这确保共享库的多个版本不会产生名称冲突。但是，OpenJDK如何确保本机方法调用使用正确的JNI代码？

1. 过程，JVM按照该过程调用本机方法。相当长，但它都包含在一个函数SharedRuntime::generate_native_wrapper中。但是，最终需要知道要调用的JNI函数的地址。
2. 该包装器函数使用methodHandle C++对象，酌情从methodHandle::critical_native_function()或methodHandle::native_function()获取JNI函数的地址。
3. JNI函数的地址通过从methodHandle调用methodHandle::set_native_function记录在NativeLookup::lookup中。
4. NativeLookup::lookup间接地委托给NativeLookup::lookup_style
5. NativeLookup::lookup_style委托给Java私有静态方法ClassLoader.findNative。
6. ClassLoader.findNative按照加载库的顺序遍历ClassLoader.loadLibrary0设置的ClassLoader.NativeLibrary对象的列表(ClassLoader.nativeLibraries)。对于每个库，它委托NativeLibrary.find尝试查找感兴趣的本机方法。虽然这个对象列表不是公开的，但是JNI规范要求JVM“为每个类加载器维护一个加载的本机库列表”，所以所有实现都必须有类似于这个列表的东西。
7. NativeLibrary.find是一种本地方法。它只是简单地委托给JVM_FindLibraryEntry。
8. JVM_FindLibraryEntry委托给系统相关方法os::dll_lookup。
9. os::dll_lookup的Linux实现委托给dlsym系统调用来查找共享库中函数的地址。
10. 因为每个类加载器都维护自己的加载库列表，因此可以保证为本机方法调用的JNI代码将是正确的版本，即使不同的类加载器加载共享库的不同版本。

如果您试图在不同的类加载器中加载相同的库，您将得到一个UnsatisfiedLinkError，它的消息是“本机库：.已经加载到另一个类加载器中了”。这可能与当类加载器被垃圾收集(方法)时调用库的卸载方法的VM有关。

但是，如果您--正如您所说--“使用不同的临时文件来存储共享库的副本”，那么这两个库实际上是不同的库，而不管文件的内容(可能是二进制相同的，这并不重要)。所以没什么问题。