使用 SevenZipJBinding 解析 RAR 文件后无法删除临时文件，根本原因是 RandomAccessFile 流未显式关闭，导致 Windows 系统锁住文件。本文提供完整解决方案：显式管理 RandomAccessFile 生命周期、确保资源释放，并给出健壮的 try-with-resources 改写示例。
使用 sevenzipjbinding 解析 rar 文件后无法删除临时文件，根本原因是 randomaccessfile 流未显式关闭，导致 windows 系统锁住文件。本文提供完整解决方案：显式管理 randomaccessfile 生命周期、确保资源释放，并给出健壮的 try-with-resources 改写示例。
在基于 SevenZipJBinding（如 16.02-2.01）开发归档处理功能时，一个常见且棘手的问题是：调用 SevenZip.openInArchive(...) 后，即使已调用 IInArchive.close()，仍无法删除原始 RAR 文件，抛出 java.nio.file.FileSystemException: The process cannot access the file because it is being used by another process。该问题在 Windows 平台尤为突出，其根源并非 SevenZip 本身未释放资源，而是 RandomAccessFileInStream 包装的底层 RandomAccessFile 对象未被关闭 —— SevenZipJBinding 不会自动关闭传入的流，需由调用方完全负责生命周期管理。
✅ 正确做法：显式关闭 RandomAccessFile
原代码中仅创建了 RandomAccessFile 并传递给 RandomAccessFileInStream，但从未调用其 close() 方法。即使 archive.close() 成功执行，RandomAccessFile 仍处于打开状态，操作系统（尤其是 Windows）会持续持有文件句柄，阻止删除操作。
以下是修复后的核心逻辑（推荐使用 try-with-resources 保证资源安全释放）：
@PostMapping("/upload")
public void extractRar(@RequestBody UploadDto dto) {
byte[] decodedBytes = Base64.getDecoder().decode(dto.data());
String filePath = dto.name();
try {
// 1. 写入临时文件
Path tempPath = Paths.get(filePath);
Files.write(tempPath, decodedBytes);
log.info("Temporary file saved: {}", filePath);
// 2. 使用 try-with-resources 管理 RandomAccessFile
try (RandomAccessFile raf = new RandomAccessFile(filePath, "r");
RandomAccessFileInStream stream = new RandomAccessFileInStream(raf);
IInArchive archive = SevenZip.openInArchive(null, stream)) {
log.info("Archive items count: {}", archive.getNumberOfItems());
// ✅ 此处可继续调用 archive.extract() 等方法解压内容
} catch (SevenZipException | FileNotFoundException e) {
throw new RuntimeException("Failed to open archive", e);
}
// 3. 归档关闭后，文件句柄已释放，可安全删除
Files.delete(tempPath);
log.info("Temporary file deleted successfully: {}", filePath);
} catch (IOException e) {
throw new RuntimeException("Error during RAR processing", e);
}
}? 关键说明与最佳实践
-
try-with-resources是关键：RandomAccessFile、RandomAccessFileInStream和IInArchive均实现了AutoCloseable，按声明顺序逆序自动调用close()，确保RandomAccessFile.close()在最后执行，彻底释放系统句柄。 -
不要混用手动 close 与 try-with-resources：若已使用 try-with-resources，无需再显式调用
archive.close()或raf.close()，否则可能触发IllegalStateException或重复关闭异常。 -
临时文件命名建议：生产环境应避免直接使用客户端传入的
dto.name()作为磁盘路径（存在路径遍历与覆盖风险）。推荐生成唯一临时文件名，例如：Path tempPath = Files.createTempFile("upload_", ".rar"); -
内存优先方案（进阶）：SevenZipJBinding 当前不支持纯内存解压（即不落盘的
byte[]或InputStream入参），若需彻底规避文件 I/O，可考虑：- 使用
ByteArrayInputStream+junrar（但需接受 RAR5 兼容性折衷）； - 或借助
7z.dll原生调用（通过 JNA/JNI），但复杂度显著上升； -
最实用替代：将临时文件写入系统临时目录（
System.getProperty("java.io.tmpdir")），并配合Files.deleteIfExists()+ShutdownHook双保险清理。
- 使用
✅ 总结
SevenZipJBinding 的文件删除失败问题，本质是 Java 资源管理疏漏，而非库缺陷。只要严格遵循“谁创建，谁关闭”原则，用 try-with-resources 封装 RandomAccessFile → RandomAccessFileInStream → IInArchive 链路，即可 100% 规避句柄泄漏。务必注意：archive.close() 不能替代 RandomAccessFile.close() —— 后者才是解锁文件的最终钥匙。
