PDFBox 2不寻常的内存消耗

我们正在尝试使用PDFRenderer的方法renderImageWithDPI渲染来自不同PDF文件的图像。在特定的PDF上，对于某些页面，库渲染器具有不同的行为。PDFBox 2不寻常的内存消耗

渲染本身比其他类似页面花费的时间更长，并且内存消耗达到非常大的值：进程消耗的内存每1到2秒增加约50MB，直到达到像5GB内存在renderImageWithDPI中由应用程序进程占用。一旦线程完成renderImageWithDPI，内存消耗几乎立即下降1.5 - 2 GB。由于高内存消耗，有时会引发Java堆空间异常。

发生这种情况的页面在宽度，高度和磁盘大小相同的情况下并不明显不同。渲染使用250 DPI完成，使用 ImageType RGB。此外，应用程序正在运行“-Dsun.java2d.cmm = sun.java2d.cmm.kcms.KcmsServiceProvider”参数。

这是内存泄漏还是预期行为？另外，有人可以解释为什么有些页面会占用2GB的内存，需要花费1分钟才能渲染，而另外一些则会在几秒钟内渲染出来？

来源

2017-04-06 Cristian

你可以分享有问题的pdf吗？ – mkl

您能否给我您的电子邮件地址，以便我向您发送谷歌驱动器链接给它？ – Cristian

也许阴影，也许复杂的模式......请发送链接到snafu点de的tilman。 –

PDF分析显示，第34页有超过10000个XObject元素，几乎所有的CMYK图像。你可以用the PDFDebugger command line app自己看看，转到第34页，然后是资源，然后是XObject。在java中转换它们不是很快。内存使用率很可能是由于我们缓存这些图像。你可以观察到下一次显示页面时，它的速度要快得多。禁用缓存在FAQ中显示。

通过使用此选项，我还获得了一些速度提升（21秒而不是89秒）：-Dorg.apache.pdfbox.rendering.UsePureJavaCMYKConversion=true。但是，图像质量可能会稍有不同，请参阅PDFBOX-3569进行讨论。

来源

2017-04-07 17:33:25

我们将尝试FAQ中的所有选项，以及您提到的最后一个选项，并提出图像质量对我们来说非常重要。感谢您对此问题的理解。 – Cristian

阅读https://issues.apache.org/jira/browse/PDFBOX-3569后，我的理解是KcmsServiceProvider和UsePureJavaCMYKConversion不应该同时使用，因为它会减慢渲染速度。我们只会使用KcmsServiceProvider，因为我们无法在两者之间切换，具体取决于一个PDF还是另一个。 – Cristian

在我的情况下，使用它们使得它更快。 –

PDFBox 2不寻常的内存消耗

回答

相关问题