JMagick и JVM падает

Question

Я использую JMagick и имею простой Java-класс, который перебирает все изображения в каталоге (и его подкаталогах), преобразуя изображения в изображения в градациях серого.

После того, как мое приложение некоторое время работает, JVM падает. Я полагаю, что сообщение об ошибке в журнале может указывать на наличие проблем с памятью:

фреймы Java: (J = скомпилированный код Java, j = интерпретированный, Vv = код VM) j magick.MagickImage.writeImage (Lmagick / ImageInfo;) Z + 0 j com.example.ImageGenerator.generateAlternativeImages (Ljava / IO / файла; Z), V + 91 j com.example.ImageGenerator.main ([Ljava / lang / String;) V + 58 v ~ StubRoutines :: call_stub

--------------- P R O C E S S ---------------

Потоки Java: (=> текущий поток) 0x0ab0c800 JavaThread "Low Детектор памяти "демон [_thread_blocked, id = 1532, стек (0x0aec0000,0x0af10000)] 0x0ab0ac00 JavaThread Демон "CompilerThread0" [_thread_blocked, id = 7304, stack (0x0ae70000,0x0aec0000)] 0x0aafe000 JavaThread "Команда JDWP Читатель "Демон [_thread_in_native, id = 6836, stack (0x0ae20000,0x0ae70000)] 0x0aafc800 JavaThread "Событие JDWP Вспомогательная нить "демон [_thread_blocked, id = 7248, стек (0x0add0000,0x0ae20000)] 0x0aafa400 JavaThread "JDWP Transport Слушатель: dt_socket "daemon [_thread_blocked, id = 6252, stack (0x0ad80000,0x0add0000)] 0x0aaee800 JavaThread "Attach Слушатель "демон [_thread_blocked, id = 2020, стек (0x0aca0000,0x0acf0000)] 0x0aaed400 JavaThread "Сигнал Диспетчер "демон [_thread_blocked, id = 7492, стек (0x0ac50000,0x0aca0000)] 0x0aada400 JavaThread "Финализатор" демон [_thread_blocked, id = 5400, стек (0x0ac00000,0x0ac50000)]
0x0aad8c00 JavaThread «обработчик ссылок» [_thread_blocked, id = 5772, стек (0x0abb0000,0x0ac00000)] => 0x002b8000 JavaThread "main" [_thread_in_native, id = 7020, стек (0x008c0000,0x00910000)]

Другие темы: 0x0aad5400 VMThread [стек: 0x0ab60000,0x0abb0000] [id = 7720] 0x0ab0f000 WatcherThread [стек: 0x0af10000,0x0af60000] [ID = 6432]

Состояние виртуальной машины: не в безопасной точке (нормальное выполнение)

VM Mutex / Monitor в настоящее время принадлежит потоку: нет

Общая куча нового поколения 960K, используется 793K [0x029c0000, 0x02ac0000, 0x02ea0000) Eden Space 896K, использовано 88% [0x029c0000, 0x02a865f0, 0x02aa0000) из пространства 64K, используется 0% [0x02aa0000, 0x02aa0000, 0x02ab0000) до 64K, используется 0% [0x02ab0000, 0x02ab0000, 0x02ac0000) всего заемного поколения 4096K, используется 0K [0x02ea0000, 0x032a0000, 0x069c0000) пространство 4096K, 0% используется [0x02ea0000, 0x02ea0000, 0x02ea0200, 0x032a0000) уплотнение пермь всего 12288K, использованных 2219K [0x069c0000, 0x075c0000, 0x0a9c0000) пробел 12288K, 18% использовано [0x069c0000, 0x06bead18, 0x06beae00, 0x075c0000) Нет настроенных общих пространств.

Я пытался добавить опции -Xmx, но думаю, что это не решение проблемы. Есть предложения?

Заранее спасибо.

Answer 1

Ваша JVM разбилась, -Xmx не поможет. Можете ли вы попробовать запустить с -Xint и посмотреть, сможете ли вы воспроизвести проблему? Это скажет JVM запустить без Hotspot, что означает отсутствие динамической оптимизации компиляции. С какой версией JVM вы работаете? Если вы не можете воспроизвести проблему с помощью -Xint и используете последнюю версию JVM, вы можете попытаться исключить из компиляции только magick.MagickImage.writeImage.

Чтобы исключить, создайте файл в рабочем каталоге приложений с именем:

.hotspot_compiler 

и добавьте строку:

exclude magick/MagickImage writeImage

Answer 2

Если вы подозреваете, что это проблема с памятью, запустите приложение с параметром -XX: + HeapDumpOnOutOfMemoryError.Это создаст дамп кучи в случае сбоя приложения из-за OOME.Затем вы можете проанализировать дамп кучи с помощью таких инструментов, как jhat или eclipse mat.

Вы также можете сгенерировать дамп кучи запущенного приложения с помощью jmap и посмотреть потребление памяти с помощью инструментов, предложенных выше, чтобы быть уверенным в своих подозрениях..

Answer 3

Я обнаружил, что вам нужно уничтожить каждую созданную вами копию изображения.В противном случае вы создаете утечку памяти.Это использует JNI, и я думаю, что есть mallocs, которые должны быть освобождены.