踩坑记录：那些年被PDF内存占用支配的恐惧

血的教训：一次凌晨3点的紧急修复

去年双十一，我们的文档转换服务突然挂了。监控显示内存使用率飙到100%，服务器直接OOM重启。排查后发现，罪魁祸首竟然是一个看起来人畜无害的50MB PDF文件。

真相：这个PDF包含了2000多页高清图片，每页都是4K分辨率的产品图。当我们用常规方法加载时，内存占用瞬间飙升到8GB+！

PDF内存占用的几个坑

坑1：全量加载陷阱

很多开发者习惯这样写代码：

// 错误示范 - 直接全量加载
byte[] pdfBytes = Files.readAllBytes(pdfPath);
PDDocument document = PDDocument.load(pdfBytes);

问题在哪？PDF文件会被完整加载到内存中，如果文件很大，内存瞬间爆炸。更要命的是，PDFBox在解析时还会创建大量中间对象，实际内存占用可能是文件大小的5-10倍。

坑2：图片资源不释放

PDF中的图片是大头。每当你调用页面渲染方法时，图片数据就会被解压缩到内存中。如果不及时释放，内存会越用越多：

// 问题代码
for (int i = 0; i < document.getNumberOfPages(); i++) {
    PDPage page = document.getPage(i);
    BufferedImage image = renderer.renderImageWithDPI(i, 300);
    // 忘记释放资源了！
}

坑3：字体缓存积累

PDF中的字体信息会被缓存，处理多个文件时这些缓存会不断积累。我曾经遇到过处理1000个PDF后，字体缓存占用了2GB内存的情况。

实战优化方案

方案1：流式处理

不要一次性加载整个文件，使用流式处理：

// 正确做法 - 流式加载
try (InputStream inputStream = new FileInputStream(pdfFile);
     PDDocument document = PDDocument.load(inputStream)) {
    
    // 设置内存使用策略
    document.setResourceCache(new ResourceCache(50 * 1024 * 1024)); // 50MB缓存
    
    // 分页处理
    processPages(document);
}

方案2：按需渲染

不要一次渲染所有页面，用到时再渲染：

// 分批处理，及时释放
int batchSize = 10;
for (int start = 0; start < totalPages; start += batchSize) {
    int end = Math.min(start + batchSize, totalPages);
    
    processBatch(document, start, end);
    
    // 强制垃圾回收
    System.gc();
    Thread.sleep(100); // 给GC一点时间
}

方案3：内存监控

添加内存监控，及时发现问题：

private void checkMemoryUsage() {
    Runtime runtime = Runtime.getRuntime();
    long usedMemory = runtime.totalMemory() - runtime.freeMemory();
    long maxMemory = runtime.maxMemory();
    
    double usage = (double) usedMemory / maxMemory;
    
    if (usage > 0.8) {
        log.warn("Memory usage high: {}%", (int)(usage * 100));
        // 可以考虑暂停处理，等待GC
    }
}

生产环境配置建议

-Xmx4g -Xms2g 
-XX:+UseG1GC 
-XX:MaxGCPauseMillis=100 
-XX:+DisableExplicitGC

写在最后

PDF内存优化没有银弹，关键是要理解PDF的结构特点，合理设计处理流程。记住一个原则：用完就扔，分批处理，时刻监控。

现在我们的服务已经稳定运行一年多了，再也没有因为PDF处理导致的OOM问题。希望我踩过的坑，能让大家少走弯路。

有问题欢迎在评论区讨论，或者私信我。记得关注我的技术博客，后续还会分享更多实战经验。