使用itext 5合并pdf时，源文件常因资源未彻底释放而无法删除；根本原因是pdfreader默认持有文件句柄（尤其在java 9+中更敏感），需显式通过fileinputstream构造reader以确保底层文件流可控释放。
使用itext 5合并pdf时，源文件常因资源未彻底释放而无法删除；根本原因是pdfreader默认持有文件句柄（尤其在java 9+中更敏感），需显式通过fileinputstream构造reader以确保底层文件流可控释放。
在基于iText 5进行PDF合并的开发实践中，一个高频且易被忽视的问题是：合并完成后源PDF文件始终处于“被占用”状态，导致File.delete()或自定义删除工具返回失败（DELETE PDF NOK）。即使已调用reader.close()和copy.freeReader(reader)，问题依然存在——这并非代码逻辑遗漏，而是iText 5底层实现与JVM文件系统资源管理的交互缺陷，在Java 9及以上版本中表现尤为突出（因模块化与文件句柄生命周期策略变更）。
根本原因解析
iText 5的PdfReader(String filename)构造器内部会直接打开RandomAccessFile并长期持有句柄，其close()方法虽释放部分内存资源，但无法保证底层操作系统级文件锁立即释放。尤其当JVM启用较激进的资源延迟回收策略时，该句柄可能持续挂起数秒，足以阻塞后续的delete()操作。
正确解决方案：显式控制输入流生命周期
应避免直接传入文件路径，转而使用PdfReader(InputStream)构造器，并配合FileInputStream——这样可确保InputStream在reader.close()时同步关闭底层文件通道，实现句柄的确定性释放。
以下是修复后的完整示例代码（含异常处理优化与资源自动管理建议）：
public static void pdfConcat2(String pathFile1, String pathFile2, String destinationPDF) {
Document document = null;
FileOutputStream outputStream = null;
PdfCopy copy = null;
try (FileInputStream fis1 = new FileInputStream(pathFile1);
FileInputStream fis2 = new FileInputStream(pathFile2)) {
document = new Document();
outputStream = new FileOutputStream(destinationPDF);
copy = new PdfSmartCopy(document, outputStream);
document.open();
// 使用显式InputStream构造PdfReader
PdfReader reader1 = new PdfReader(fis1);
copy.addDocument(reader1);
copy.freeReader(reader1);
reader1.close(); // 此时fis1同步关闭
PdfReader reader2 = new PdfReader(fis2);
copy.addDocument(reader2);
copy.freeReader(reader2);
reader2.close(); // 此时fis2同步关闭
document.close();
outputStream.flush();
outputStream.close();
copy.flush();
copy.close();
} catch (IOException | DocumentException e) {
throw new RuntimeException("PDF合并失败", e);
}
}✅ 关键改进点：
- 使用try-with-resources自动管理FileInputStream，确保即使发生异常也能及时关闭流；
- PdfReader(InputStream)替代PdfReader(String)，切断隐式文件句柄绑定；
- copy.freeReader(reader) + reader.close()双重保障（前者释放iText内部缓存，后者触发流关闭）。
注意事项与最佳实践
- 禁止复用PdfReader实例：每个源文件必须创建独立的PdfReader，不可跨文档复用；
- 避免PdfCopy未关闭：copy.close()必须执行，否则输出流缓冲区未落盘，且可能残留引用；
- Java 9+用户必做：若无法升级至iText 7，请严格采用InputStream方式——这是目前最稳定、无副作用的绕过方案；
- 补充验证逻辑（可选）：删除前可加入短时重试机制（如等待100ms后重试2次），应对极少数JVM调度延迟场景。
通过上述重构，源PDF文件将在合并结束后立即可被安全删除，彻底解决DELETE PDF NOK问题，同时提升代码健壮性与跨JDK版本兼容性。
