JMagick的JNI-hazard问题

JNI-hazard问题
       JMagick使用JNI技术调用ImageMagick，存在JNI-hazard问题。不适合在长时间运行的Web应用程序使用ImageMagick +Jmagick，可能导致JVM崩溃。

       我就在项目中遇到过，Tomcat在跑了数天后会crash，异常内容为：magick.MagickException: Unable to retrieve handle  。

        从表象看，应该是没有释放ImageMagick的句柄导致的，查找API后发现程序中没有调用：magick.MagickImage.destroyImages()  Called by finalize to deallocate the image handle。 在程序加上本方法，情况有所改善，大概在十多天后出现了一次tomcat进程crash。并不能根本解决问题。
       建议使用IM4JAVA。

 

在JMagick的邮件列表中找到一份我认为有价值的邮件

The "JNI hazard" here is that if something you use (f.ex libtiff for reading  
TIFF files) has a memory bug then it can make your whole JVM crash. Thats of  
course frustrating and therefore its great to have im4java around, which  
starts IM as an external process, so JVM crashes are avoided.  
 * *  
Coolest thing would be if JMagick and im4java could have the same API so it  
was easy to switch depending on luckyness. Ive asked the author of im4java  
to attemt to be as compatible as possible, but as im4java is very much  
different internally its limited how much can be done in that direction.  
  
If you don't like the risk, stick to im4java. If your want optimal  
performance give JMagick a try.  
  
And, its not JMagick that is buggy, its what it depends on (hereunder IM)  
that is not always (memory) bug free on long running processes.  
I also have never seen a mismatch between JMagick binary and ImageMagick  
binaries leading to crashes. 

 

IM4JAVA官方文档也有相关说明：

1.1. What exactly do you mean with JNI-hazard? 
Running native code using JNI from within java always imposes additional risks. The JVM is no longer sandboxed, so there might be some security issues. In addition, there could be errors like memory leaks or memory corruption within the JNI-layer (JMagick) or within the native code (ImageMagick). 
This is especially dangerous for long running processes (typically web-application-servers). Memory corruption or a segmentation fault (maybe triggered by a intentionally manipulated image) might bring down the whole server. 
On the other side, in reality the situation is not as bad as it sounds above. JMagick is well tested, and for standard use-cases it prooves to be very stable. 
Some additional information is available on the JMagick-users mailing list where this topic has been discussed to some detail.