Утечки Com4j с помощью DirectByteBuffer, Cleaner, Finalizer, экземпляры вариантов

Question

У меня есть проект Java, который работает с одной библиотекой DLL через COM. У меня Windows 7, и я использую 32-разрядную Java 1.6. Я использую 2012/04/26 выпуск com4j в качестве моста. Оно работает.

Проблема в том, что у меня серьезная утечка памяти, что делает работу моей программы практически невозможной.

Я подписался на некоторые события COM. Когда придет следующее событие, я наблюдаю увеличение памяти кучи, и GC никогда не помогает ее уменьшить. Если я использую COM4J.cleanUp() - использование памяти останавливает его рост, но события больше не поступают. Память кучи, используемая моей программой, очень быстро растет, в то время как на самом деле не выделяются мои собственные объекты.

разница

Снимки в VisualVM: http://postimg.org/image/cxg77ft8j/

Heap памяти поднять в VisualVM: http://postimg.org/image/m52g63b51/

Похоже, проблема с DirectByteBuffer, Чистильщик, Variant и экземпляры финализации. Я не создаю их самостоятельно. Это что-то внутри com4j.

Любые предложения?

Answer 1

Я изучаю утечку памяти самостоятельно в проекте com4j, над которым я работаю. Из того, что я понимаю, Com4j запускает ComThread для каждого JavaThread, который использует Com4j. Все вызовы Com4j выполняются как задачи для этого потока. Когда Thread существует, ресурсы освобождаются, и все COM-Wrappers отключены. COM4J.cleanUp() на самом деле убивает ComThread для текущей темы Java, что объясняет, почему события, которые вы слушаете, перестают появляться.

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

Посмотрите на https://github.com/guykv/com4j/compare/Issue16. Слияние этого изменения с моей вилкой com4j действительно помогло куче оставаться стабильным.

Cheears.