使用 pdfbox 渲染 PDF答案

【问题标题】：PDF rendering using pdfbox使用 pdfbox 渲染 PDF
【发布时间】：2016-06-24 08:00:25
【问题描述】：

当我尝试将 pdf 转换为图像时，对于某些 pdf，我收到“内存不足”错误。所以我增加了堆大小，然后我再次得到了一些不同 pdf 文件的错误。暂时假设我没有其他对象的内存泄漏。那么这个内存出错的原因是什么？是否只是图像太大（我认为不是这种情况）以至于它消耗了堆，或者 pdfbox 将每个页面的缓冲图像存储在其内存中，这会导致堆大小的增长？任何见解都会很棒。

这是我要渲染的 pdf 的链接。 https://drive.google.com/file/d/0B_Ke2amBgdpeNFFDem5KVVVzanc/view?usp=sharing 这是代码段。

PDFRenderer pdfRenderer = new PDFRenderer(pdDoc);
BufferedImage image = pdfRenderer.renderImageWithDPI(page-1, 300,ImageType.GRAY);
//image=ImageHelper.convertImageToGrayscale(image);
ImageIOUtil.writeImage(image,"G:/Trial/tempImg.png", 300);

请注意，对于这个特定的 pdf 问题是通过增加堆大小来解决的，但我想知道的是 pdfbox 是否将缓冲的图像存储在其内存中并有助于堆大小。

这是另一个 pdf，即使在增加堆大小后也面临同样的问题。 https://drive.google.com/file/d/0B_Ke2amBgdpedDBtaG1QcW1oYlU/view?usp=sharing 在这个 pdf 中，我的代码在渲染第 44 页时需要很长时间。我不知道为什么会这样。

【问题讨论】：

可能会添加您要转换的内容的大小以及执行此操作的代码的 sn-p
我已经编辑了我的帖子并上传了代码和文件。
关于内存使用：如果我没记错的话 pdfbox 使用大量内存（尤其是彩色图像），是的，即使您不需要它们（一年前或所以他们计划在使用后进行 readOnDemand/remove，但我没有保持最新）。您可以尝试使用暂存文件来节省内存，但它会很慢
您的文件很大...也许您需要更多的 -Xmx 空间。我认为 p44 没有任何问题。这只是一堆非常大的扫描。是的，PDFBox 确实在内存中存储了很多。确保在转换时不要保留图像（例如，在数组中），以便空间可用。如果您使用的是 JDK8，请不要忘记特殊设置。 pdfbox.apache.org/2.0/getting-started.html
@Zeromus 我们正在缓存图像，但从 2.0 版本开始使用 SoftReference，因此不应将它们保存在内存中。我对p44没有问题。顺便说一句，提取的页面最大为 31MB（p8）。彩色扫描通常是个坏主意。由于人工制品，将文本文件扫描为JPEG（如链接的PDF）也是一个坏主意。可悲的是，许多编程不佳的多功能复印机都会这样做。

标签： java image pdf pdfbox

【解决方案1】：

嗯，这个问题似乎不是由于任何错误或内存泄漏，而是由于图像大小。建议的解决方案：- 1) 增加 Xmx 大小 2) 切换到 64 位 JVM。

编辑：- 感谢您的回答。我只是把它放在这里。 @Tilman Hausherr 进行了测试，结果是应该增加堆大小。注意使用的是 64 位 jvm。

【讨论】：

在 JDK7 64 位上，一个文件使用 -Xmx90m，另一个文件使用 -Xmx400m。
是的，增加 Xmx 大小是一种解决方法，但是当 pdf 文件太多时，堆就会变满。嘿@TilmanHausherr，你能帮我做一件事吗，放一个 image.flush () 行重复上面的代码太多次，然后看到堆转储。你可以用任何pdf来做到这一点。请更新我的结果。我的结果：- 太多的终结器类引用只会在没有循环的情况下增加。
这需要一些时间。我的电脑用了 6 年。而且我通常在晚上把它关掉，让房间凉快一点。
@TilmanHausherr，只要你有时间，就这样做，然后请告诉我结果。
为什么 finalize 方法与可能需要大量实例化的对象（如 bufferedImage）一起使用。它只是增加了引用队列中 finalize 方法的数量，我不明白目的。可以使用 close 或 dispose 等方法。