Java JNI全局引用持有的JPanel导致OOM异常

我希望我的问题有更多的背景，但不幸的是，我发布这个问题是出于绝望。我无法用一个较小的应用程序复制这个，因为我希望我能在这里发布它。不幸的是，我所能做的就是试图解释我的症状，并希望有人在那里看到类似的东西

我有一个纯java的应用程序，它在一些客户机上摆脱了内存异常。我提供了400mb的java堆空间，但不幸的是，我们仍然看到这个问题。在应用程序崩溃之前从应用程序中获取堆转储，我可以看到有大量异常多的JPanel对象。查看堆转储，有趣的是对我的面板的唯一传入引用是JNI全局引用。让我困惑的是，为什么首先会有一个JNI全局引用到JPanel？我只有一帧。在什么情况下java需要创建对JPanel的全局JNI引用

虽然我有一个理论，它不是基于我读过的任何东西，但我感觉终结器线程被阻塞了。不幸的是，我没有一个线程转储来证明这一点。我的理论是，我的jpanel排队等待垃圾收集，但是，一旦它进入队列，队列本身就无法处理这个问题

有没有人愿意分享他们的理论或直觉？因为我不能在我的机器上复制这个，我在分析这个理论时有点手铐。然而，如果有人愿意给我另一条调查路线，我将不胜感激

编辑： 我有一个关于这个的小更新。我的应用程序也使用拖放，并且进一步分析堆转储，我注意到传递我的JPanel的java.awt.datatransfer.Transferable对象与未清理的JPanel一样多。有趣的是，对可转移对象的唯一引用还是JNI全局。这让我怀疑终结器是否在清理JPanel时被阻止，而是在清理拖放对象时被阻止

编辑：

---

因此，如果有人感兴趣，我相信我已经确定了问题所在。所以，我在最初的文章中遗漏了一点：应用程序使用windows IE COM库和一些第三方库嵌入了一个HTML页面。无论如何，事实证明，在拖放过程中，第三方库或IE COM库本身都会获取JNI全局引用。不幸的是，我没有解决这个问题的办法，但我要感谢所有在调查这个问题时给我提出建议的人。

假设代码不是你自己的，你可能需要一个错误的图形上下文。这是一个不会泄漏的示例。

感谢垃圾神的建议。我来看看这个。我正在调查一种我可以捏造这种情况的方法。