本文深入探讨了jna加载的dll文件在尝试删除时遇到`accessdeniedexception`的常见问题。核心原因在于jna内部库缓存机制中，`native.loadlibrary`与`nativelibrary.getinstance`在未正确匹配`classloader`时，可能导致获取到不同的`nativelibrary`实例，进而造成dll句柄未完全释放。文章提供了详细的解决方案，强调通过指定正确的`classloader`来确保获取并释放同一库实例，从而实现dll的成功删除。
理解JNA的库加载与释放机制
在使用Java Native Access (JNA) 框架与本地库（如Windows下的DLL、Linux下的SO）交互时，我们通常会通过Native.loadLibrary()方法加载本地库，并将其映射到一个Java接口。JNA内部维护了一个库实例的缓存，以优化性能并避免重复加载。当一个库被加载后，操作系统会为其分配一个句柄，直到该库被显式卸载或JVM进程终止。
为了释放本地库占用的资源，JNA提供了NativeLibrary.dispose()方法。理论上，调用此方法后，操作系统应该释放对DLL文件的句柄，从而允许该文件被删除。然而，实际操作中，开发者常遇到即使调用了dispose()，DLL文件依然无法删除，并抛出java.nio.file.AccessDeniedException的异常。
问题分析：DLL无法删除的深层原因
问题的根源在于对JNA内部库缓存机制的误解。当我们在代码中执行以下两步操作时：
- DLLUtil = (ExtDLLTool) Native.loadLibrary(dllPath, ExtDLLTool.class);
- NativeLibrary lib = NativeLibrary.getInstance(dllPath);
我们可能会错误地认为这两行代码会引用或返回同一个NativeLibrary实例。然而，事实并非总是如此。
Native.loadLibrary(String name, Class<?> interfaceClass)方法在内部调用NativeLibrary.load()时，会使用interfaceClass.getClassLoader()作为加载选项的一部分。这个ClassLoader会被作为缓存键的一部分。这意味着，即使dllPath相同，如果后续通过NativeLibrary.getInstance(dllPath)（没有明确指定ClassLoader）尝试获取NativeLibrary实例，JNA的缓存机制可能会：
- 返回一个不同的NativeLibrary实例，因为它没有匹配到完整的缓存键（缺少ClassLoader信息）。
- 或者，在某些情况下，如果NativeLibrary.getInstance(dllPath)内部逻辑未能完全匹配Native.loadLibrary时使用的所有选项，它可能会创建一个新的NativeLibrary实例。
无论哪种情况，结果都是：我们可能加载了库（即操作系统打开了DLL文件），但尝试dispose()的却是错误的NativeLibrary实例，或者一个并非最初加载的实例。这就导致了“多重打开，单次关闭”的局面，操作系统对DLL文件的句柄并未完全释放，从而阻止了文件删除。
以下是原始问题中导致此问题的示例代码：
import java.io.File;
import com.sun.jna.Library;
import com.sun.jna.Native;
import com.sun.jna.NativeLibrary;
class Filter {
private static ExtDLLTool DLLUtil;
final private static String dllPath = "./ExternalDownloader_64.dll";
static {
// 第一次加载，隐式使用了ExtDLLTool.class的ClassLoader
DLLUtil = (ExtDLLTool) Native.loadLibrary(dllPath, ExtDLLTool.class);
}
public static void main(String[] args) throws Exception {
if (DLLUtil != null) {
DLLUtil = null;
// 尝试获取NativeLibrary实例，但没有指定ClassLoader
NativeLibrary lib = NativeLibrary.getInstance(dllPath); // 这里是问题所在
lib.dispose(); // 释放的可能是错误的或无效的实例
Thread.sleep(3000); // 延迟是为了给OS时间释放资源，但如果句柄未释放，延迟无用
}
File dllFile = new File(dllPath);
if (dllFile.exists()) {
// 尝试删除文件，会抛出AccessDeniedException
Files.delete(Paths.get(dllPath));
if (dllFile.exists()) {
System.out.println("Unable to delete dll file, since it hold by jvm");
}
}
}
private interface ExtDLLTool extends Library {
String validateNomination(String dloadProps);
}
}解决方案：正确释放JNA加载的库
解决此问题的关键在于确保在调用NativeLibrary.getInstance()时，提供与Native.loadLibrary()加载时完全相同的参数，尤其是ClassLoader。这样才能从JNA的内部缓存中获取到最初加载的那个NativeLibrary实例，并对其进行正确的dispose()操作。
将NativeLibrary.getInstance(dllPath)修改为NativeLibrary.getInstance(dllPath, ExtDLLTool.class.getClassLoader())即可解决问题。
以下是修正后的示例代码：
import java.io.File;
import java.nio.file.Files;
import java.nio.file.Paths;
import com.sun.jna.Library;
import com.sun.jna.Native;
import com.sun.jna.NativeLibrary;
class Filter {
private static ExtDLLTool DLLUtil;
final private static String dllPath = "./ExternalDownloader_64.dll";
static {
// 第一次加载，隐式使用了ExtDLLTool.class的ClassLoader
DLLUtil = (ExtDLLTool) Native.loadLibrary(dllPath, ExtDLLTool.class);
}
public static void main(String[] args) throws Exception{
if (DLLUtil != null) {
DLLUtil = null;
// 关键修正：在获取NativeLibrary实例时，传入正确的ClassLoader
NativeLibrary lib = NativeLibrary.getInstance(dllPath, ExtDLLTool.class.getClassLoader());
lib.dispose(); // 现在可以正确释放最初加载的库实例
Thread.sleep(3000); // 给予操作系统足够时间释放句柄
}
File dllFile = new File(dllPath);
if(dllFile.exists()){
Files.delete(Paths.get(dllPath)); // 现在可以成功删除文件
if(dllFile.exists()){
System.out.println("Unable to delete dll file, since it hold by jvm");
} else {
System.out.println("DLL file deleted successfully.");
}
}
}
private interface ExtDLLTool extends Library {
String validateNomination(String dloadProps);
}
}通过这个修改，我们确保了dispose()方法作用于正确管理的NativeLibrary实例，从而允许操作系统释放DLL文件的句柄，使其可以被成功删除。
最佳实践与注意事项
- 统一加载和释放方式： 始终确保用于加载（Native.loadLibrary或NativeLibrary.load）和释放（NativeLibrary.getInstance）的库路径和选项（尤其是ClassLoader）保持一致。
-
使用绝对路径： 为了避免由于相对路径解析、环境变量或工作目录变化导致的潜在问题，强烈建议在加载和获取NativeLibrary实例时，使用DLL文件的绝对路径。
- 例如：String absoluteDllPath = new File(dllPath).getAbsolutePath();
- 然后使用Native.loadLibrary(absoluteDllPath, ExtDLLTool.class)和NativeLibrary.getInstance(absoluteDllPath, ExtDLLTool.class.getClassLoader())。
- 理解JNA缓存键： JNA的缓存键不仅包含库名称，还可能包括其他选项，如ClassLoader、调用约定等。在使用NativeLibrary.getInstance()时，需考虑这些因素。
- 适当的延迟： 即使正确调用了dispose()，操作系统也可能需要一小段时间来完全释放文件句柄。在dispose()之后添加一个短暂的Thread.sleep()（例如几百毫秒到几秒）可以作为一种健壮性措施，尤其是在多线程或高并发场景下。但这只是辅助措施，不能解决根本的句柄未释放问题。
- 异常处理： 在尝试删除文件时，始终捕获并处理IOException，特别是AccessDeniedException，以便更好地诊断问题。
总结
JNA加载的DLL文件无法删除的问题，通常并非是JNA的缺陷，而是对JNA内部库缓存机制和NativeLibrary实例管理的误解所致。通过在获取NativeLibrary实例准备释放时，提供与加载时相同的ClassLoader，我们可以确保操作的是同一个库实例，从而成功地释放本地资源并删除DLL文件。遵循统一的加载和释放策略，并考虑使用绝对路径，将有助于构建更稳定、可靠的JNA应用。
