本文探讨jna加载dll后无法删除的问题，即使调用`dispose()`也无效。核心原因是`native.loadlibrary`与`nativelibrary.getinstance`因缓存键（如`classloader`）不同，可能获取到不同`nativelibrary`实例。教程将展示如何通过显式传递`classloader`来正确识别并释放最初加载的`nativelibrary`实例，从而成功删除dll文件。
JNA加载DLL后的文件删除挑战
在使用Java Native Access (JNA) 库加载动态链接库（DLL）后，开发者常会遇到一个棘手的问题：即使尝试通过NativeLibrary.dispose()方法释放了库资源，也无法删除对应的DLL文件，系统会抛出AccessDeniedException，表明文件仍被JVM持有。这通常发生在应用程序需要动态加载、使用并随后删除DLL文件的场景中，例如在插件系统或热更新机制中。
最初尝试的解决方案往往包括调用NativeLibrary.dispose()，甚至在调用后添加Thread.sleep()以等待操作系统释放文件句柄。然而，这些方法通常无法解决问题，因为它们可能没有正确地作用于JVM最初加载的那个NativeLibrary实例。
问题根源：NativeLibrary实例的缓存机制
JNA在内部管理NativeLibrary实例时使用了缓存机制。Native.loadLibrary()和NativeLibrary.getInstance()这两个方法都会利用这个缓存来避免重复加载同一个本地库。然而，导致文件无法删除的根本原因在于，Native.loadLibrary(dllPath, ExtDLLTool.class)与后续尝试释放的NativeLibrary.getInstance(dllPath)可能获取的并非同一个NativeLibrary实例。
Native.loadLibrary()方法在加载库时，会将其内部使用的ClassLoader（通常是调用该方法的类的ClassLoader）作为缓存键的一部分。这意味着，即使DLL路径相同，如果ClassLoader不同，JNA也会将其视为不同的库加载请求，从而创建并缓存一个新的NativeLibrary实例。
当开发者随后调用NativeLibrary.getInstance(dllPath)（不带ClassLoader参数）时，JNA可能无法命中Native.loadLibrary()时创建的那个带有特定ClassLoader信息的缓存条目。因此，getInstance返回的可能是另一个（或默认参数下的）NativeLibrary实例。对这个错误的实例调用dispose()，并不能真正释放最初被JVM加载并持有的DLL文件句柄，导致文件删除失败。
简而言之，问题在于Native#open可能被调用了两次（一次由Native.loadLibrary，一次由不带ClassLoader的NativeLibrary.getInstance），但Native#close（通过dispose()调用）只作用于其中一个实例，而未能释放原始加载的实例。
解决方案：显式指定ClassLoader
要正确释放由Native.loadLibrary()加载的DLL，关键在于确保在调用NativeLibrary.getInstance()时，能够获取到与最初加载时完全相同的NativeLibrary实例。这可以通过在NativeLibrary.getInstance()方法中显式传递加载该DLL接口的ClassLoader来实现。
通过ExtDLLTool.class.getClassLoader()获取用于加载ExtDLLTool接口的ClassLoader，并将其作为参数传递给NativeLibrary.getInstance()，可以保证JNA命中正确的缓存条目，从而获取到与Native.loadLibrary()创建的完全相同的NativeLibrary实例。对这个实例调用dispose()，就能确保本地库资源被正确释放。
示例代码
以下是修正后的代码示例，演示了如何正确释放JNA加载的DLL资源以允许其被删除：
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 {
// 第一次加载DLL，JNA会记录dllPath和ExtDLLTool.class.getClassLoader()作为缓存键
DLLUtil = (ExtDLLTool) Native.loadLibrary(dllPath, ExtDLLTool.class);
}
public static void main(String[] args) throws Exception {
if (DLLUtil != null) {
// 将DLLUtil引用置空，允许GC回收，但这不是释放DLL的关键
DLLUtil = null;
// 关键步骤：通过显式传递ClassLoader来获取正确的NativeLibrary实例
NativeLibrary lib = NativeLibrary.getInstance(dllPath, ExtDLLTool.class.getClassLoader());
lib.dispose(); // 释放本地库资源
// 给予操作系统时间来完全释放文件句柄
Thread.sleep(3000);
}
File dllFile = new File(dllPath);
if (dllFile.exists()) {
try {
Files.delete(Paths.get(dllPath)); // 尝试删除DLL文件
System.out.println("DLL file deleted successfully.");
} catch (Exception e) {
System.err.println("Unable to delete dll file: " + e.getMessage());
}
}
}
// 定义JNA接口，映射DLL中的函数
private interface ExtDLLTool extends Library {
String validateNomination(String dloadProps);
}
}
进一步优化与注意事项
-
统一库路径表示: 为了确保Native.loadLibrary()和NativeLibrary.getInstance()始终能命中同一个缓存条目，强烈建议在两者中使用绝对路径来指定DLL文件。相对路径或仅使用库名（不带前缀和后缀）可能会因JNA内部处理或操作系统搜索路径差异导致不一致。例如：
final private static String dllAbsolutePath = new File("./ExternalDownloader_64.dll").getAbsolutePath(); // ... DLLUtil = (ExtDLLTool) Native.loadLibrary(dllAbsolutePath, ExtDLLTool.class); // ... NativeLibrary lib = NativeLibrary.getInstance(dllAbsolutePath, ExtDLLTool.class.getClassLoader()); - Thread.sleep()的必要性: 尽管NativeLibrary.dispose()会立即尝试释放资源，但操作系统在某些情况下可能需要一个短暂的时间来完全释放文件句柄。因此，在调用dispose()后添加一个短暂的延迟（例如Thread.sleep(3000)）是一个稳健的做法，可以增加文件删除成功的概率。
- 资源管理与生命周期: 确保在不再需要DLL时及时调用dispose()。在复杂的应用程序中，可以考虑使用try-with-resources或在适当的生命周期钩子（如应用程序关闭、插件卸载）中执行释放操作。
- 异常处理: 文件删除操作应包含适当的异常处理，特别是针对IOException或AccessDeniedException，以便在删除失败时能够记录日志或采取恢复措施。
总结
JNA加载DLL后无法删除的问题，其核心在于对NativeLibrary实例的错误引用和释放。通过理解JNA的内部缓存机制，并在调用NativeLibrary.getInstance()时显式提供正确的ClassLoader，可以确保我们操作的是JVM最初加载的那个NativeLibrary实例。结合使用绝对路径和适当的延迟，可以有效解决DLL文件在JNA应用中无法删除的难题，从而实现更健壮的本地库管理。
