gpt4 book ai didi

java - Com4j 因 DirectByteBuffer、Cleaner、Finalizer、Variant 实例而泄漏

转载 作者:行者123 更新时间:2023-12-01 13:35:09 25 4
gpt4 key购买 nike

我有一个 Java 项目,它通过 COM 使用一个 dll 库。我有 Windows 7,并且使用 32 位 Java 1.6。我使用 2012/04/26 发布的 com4j 作为桥梁。它有效。

问题是我有严重的内存泄漏,这使得我的程序几乎无法运行。

我订阅了一些 COM 事件。当下一个事件到达时,我观察到堆内存使用量的增加,并且 GC 永远不会帮助减少它。如果我使用 COM4J.cleanUp() - 内存使用量停止增长,但事件不再到达。我的程序使用的堆内存增长得非常快,而实际上没有分配我自己的对象。

VisualVM 中的快照差异:http://postimg.org/image/cxg77ft8j/

VisualVM 中的堆内存增加:http://postimg.org/image/m52g63b51/

看起来问题出在 DirectByteBuffer、Cleaner、Variant 和 Finalizer 实例上。它们不是我自己创造的。这是 com4j 内部的东西。

有什么建议吗?

最佳答案

我正在自己从事的 com4j 项目中调查内存泄漏。据我了解,Com4j 为每个使用 Com4j 的 JavaThread 启动一个 ComThread。对 Com4j 的所有调用都作为该线程的任务执行。当线程存在时,资源被释放,所有 COM-Wrappers 被释放。COM4J.cleanUp() 实际上杀死了当前 Java 线程的 ComThread,这解释了为什么您监听的事件停止出现。

我在我的项目中看到了相同的行为:ComThread 运行的时间越长,使用且从未释放的堆就越多。当 Com4j 包装器被释放时,它们不会从堆中删除,因为它们保留在 ComThread 的 Activity 对象集中。

看看https://github.com/guykv/com4j/compare/Issue16 。将该更改合并到我的 com4j 分支实际上有助于堆保持稳定。

干杯。

关于java - Com4j 因 DirectByteBuffer、Cleaner、Finalizer、Variant 实例而泄漏,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/21340112/

25 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com