首先， 這三個工具的定位是不同的。
PDF-Renderer是早日Sun公佈的一個開源項目， 它主要目的是方便用戶展示PDF文檔。 通過解析PDF文檔， 使用戶能夠在自己的應用中查看， 預覽，繪製PNG和合併到3D的場景中。
PDFBox是Java實現的PDF文檔協作類庫，提供PDF文檔的創建、處理以及文檔內容提取功能。 它還包含比較多的命令方式方便用戶處理PDF。 它的強大功能是處理解析PDF文檔。而且業界使用是比較廣泛和穩定的。
JPedal是IDRsolutions公司的一個產品。 而這個產品在PDF解析和PDF展示中都有着比較專業的表現。JPedal只開源其中的一小部分功能。 其中PDF轉圖片的功能是在LGPL下面的。
從上面的定位來看， PDF-Renderer應該是比較吻合我們的要求的。下面分別從圖片質量， 效率方面來簡單的做個比較。
下面是三款工具從PDF中轉成的圖片：
[size=large] [b]PDF-renderer[/b][/size]
[img]http://dl.iteye.com/upload/attachment/551828/ee546739-d2ee-3737-b90b-bda5a26c06e8.png[/img]
[size=large][b] PDFbox[/b][/size]
[img]http://dl.iteye.com/upload/attachment/551830/ee4d67f3-15cf-39de-80f4-5112cd01fcd8.png[/img]
[size=large][b] Jpedal[/b][/size]
[img]http://dl.iteye.com/upload/attachment/551832/b25c7c01-8e56-3e19-93c9-816ce5305f30.png[/img]
從圖片質量上來看， 除了PDBbox有條線沒有成功畫出來後， 基本上差不多（當然， 在像素上PDFbox是最高的）。 但他們之間的轉化效率還是差別很大的。 在轉化效率上， 經過測試表現不如意的是PDFBox，其次是Jpedal. 最好的是PDF_renderer. 在我的測試中PDF-renderer的轉化效率大約是Jpedal的兩三倍。 而Jpedal的轉化效率大約是PDFbox的3倍多。
但是， 經過一定量文檔的測試， 發現很多PDF文檔是不能被PDF-renderer處理的。 一個主要原因是PDF-renderer的字體不全。 而PDFbox有自己的字體包， 在不能轉化時， 會轉化到默認字體處理。目前測試中， 還沒碰到PDFbox和Jpedal不能處理的文檔。 由於PDFbox有時候， 不能正確的撲捉的表格線， 所以我們這次的項目中選擇使用Jpedal. 除了Jpedal是家商業公司的產品外， 似乎沒有不用的理由。
在項目使用過程中， 由於我們使用多線程批量轉化。 出現過內存溢出的問題。 特別是使用PDFbox時候， 它需要的內存會更多。這裏順便簡單談下自己是怎樣追蹤解決內存溢出的問題。也許大家有更好的辦法， 熱烈歡迎大家給我意見。
首先， 可能大家自然的會想到利用jvisualvm，裝個插件就可以動態的觀察內存使用情況。 甚至隨時可以把線程堆棧，CPU和內存快照弄出來。但如果是在大的應用系統中， 內存本來就很吃緊，開個 jvisualvm基本上就死在那裏不動了。 這裏想到的就是利用gc log 和內存溢出後的堆棧信息來處理。
在JVM啓動中，加入下面的配置參數
-verbose:gc -XX:+PrintGCTimeStamps -XX:+PrintGCDetails -Xloggc:D:/java/gc/gc.log -XX:+HeapDumpOnOutOfMemoryError
打開gc的詳細log並寫入到一個單獨文件中。 其中HeapDumpOnOutOfMemoryError的配置， 會在內存溢出時候寫一個java_pidXXXX.hprof的文件到jvm啓動的第地方。 利用Eclipse Memory Analysis插件，打開這個文件後， 我們可以獲得到內存溢出時候的內存堆棧信息。 其中有個Leak Suspects 功能， 把認爲最有可能導致內存溢出的objece分析出來。如下圖：
[img]http://dl.iteye.com/upload/attachment/551857/2ba9e916-0d9c-373d-894b-f92a14716416.png[/img]
從圖中可以發現， 有兩個比較可疑的地方。 第二個正是我們轉圖片用的。 然後我們就可以去改進我們的代碼。
上面我們還提到過gc日誌文件。 通過分析gc日誌， 我們大概可以瞭解到JVM堆內存使用情況。 這裏介紹一個taobao人開發的查看gc日誌的工具。 很小很好用。[url]http://code.google.com/p/gclogviewer/[/url] 現在的版本只能畫圖， 下個版本除了畫圖的性能提高外，還會增加調優的建議。下面是我改動代碼前後的兩個gc圖。
[img]http://dl.iteye.com/upload/attachment/551862/bb2502e4-eaf7-35a3-8ec6-fcad87ad9967.png[/img]
從這個圖中， 可以看出內存一直在漲， 直至崩潰。
這是改動代碼後的一個圖：
[img]http://dl.iteye.com/upload/attachment/551868/1b291528-55e9-307e-adbc-221f688ef54c.png[/img]
這個圖， 內存趨於穩定了。 但轉化過程中， 一直處於Full GC. 應用暫停很嚴重。 幸好這是在後臺的一個數據訂正程序。性能優化還有很多可以做。