umarshallerimpl finalize（）方法导致内存泄漏

发布于 2025-01-22 03:03:25 字数 506 浏览 1 评论 0原文

我正在我的多线程弹簧应用中使用WebServiceTemplate。有我的jaxb依赖性：

compile('javax.xml.bind:jaxb-api:2.3.0')
compile('org.glassfish.jaxb:jaxb-runtime:2.3.0')

我的应用程序提出了很多ESB请求，以及我如何注意到每个请求/响应（MostrectAndReceive）JAXB创建了一个实用的实例。 > finalize（）方法，这对我来说是问题，因为对象创建的速度比最终方线程可以处理该对象更快，因此它会导致内存泄漏。我想知道为什么glassfish实现仍然具有finalize（）在unmarshallerimpl中，它确实给我带来了问题。是否有其他版本的Glassfish Jaxb实施或类似的库？我将感谢任何有用的信息。

UPD：我还尝试了JAXB的3.0.2版：JAXB -Runtime-问题仍然存在

原文

I'm using webServiceTemplate in my multithread Spring app.
There are my jaxb dependencies:

compile('javax.xml.bind:jaxb-api:2.3.0')
compile('org.glassfish.jaxb:jaxb-runtime:2.3.0')

My application makes a lot esb requests and how I have noticed for each request/response (marshalSendAndReceive) jaxb creates an instance of UnmarshallerImpl which implements finalize() method and this is the problem for me, because objects creates faster than Finalizer thread can handle this objects, so it leads to memory leak. I'm wondering why do glassfish implementation still has finalize() in UnmarshallerImpl, it really creates problems for me. Is there any alternative versions of glassfish jaxb implementation or similar libraries? I will be grateful for any useful information.

UPD:
I have also tried version 3.0.2 of jaxb:jaxb-runtime - the problem is still present

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

不及他 2025-01-29 03:03:25

我认为，从长远来看，您最好的选择是使用XML流媒体实现来切换您的请求。

在短期内...

正如您指出的那样，JAXB参考实现仍然在最新版本中使用finalize（）。
我认为没有一种方法可以增加GC最终螺纹的数量。（这可能是一件好事。...）
提供者列表
此Q＆amp; a列出了一些替代JAXB实现： jaxb 是开源，您可以修改finalize（）实现您当前正在使用的unmarshallerimpl。

finalize（）方法的标准实现如下：

@Override
@SuppressWarnings("FinalizeDeclaration")
protected void finalize() throws Throwable {
    try {
        ClassFactory.cleanCache();
    } finally {
        super.finalize();
    }
}

思考...您 May 可以摆脱不清洁classFactory 缓存每次 <代码> umarshallerimpl实例是收集的。也许这可能只是设定一个“全局”标志，以告诉有效工作要做的异步缓存清洁器。

当然，从长远来看，使用修改的库有一个维护开销，因此建议尝试使上游项目接受更改。

Update

我应该之前研究CleanCache，但看来它所做的只是丢弃已在线程本地缓存的地图。这个应该便宜，不应该成为争论的来源。另外，这意味着不同步（即在另一个线程上！）不会有效。（这也意味着清洁器下面建议的方法也无法使用。）

另一种选择是不调用Cleancache，但这为我们提供了潜在的内存通过本地线程泄漏！！

无论哪种方式，我（现在！）感到困惑，因为这个finalize（）方法根本是瓶颈。您确定问题不是由其他问题引起的吗？

我想知道为什么glassfish实施仍然具有finalize（） in unmarshallerimpl，它确实为我造成了问题。

答案很明显。他们尚未到¹修复它。

^{1-修辞问题：1）您为实施玻璃鱼的实施支付了多少钱？ 2）有些东西称为“开源赏金” 。您是否尝试提供一个问题来解决此问题？}

I think your best bet in the long term is to switch to processing your requests using an XML streaming implementation.

In the short term ...

As you noted, the JAXB reference implementation still uses finalize() in the latest release.
I don't think there is a way to increase the number of GC finalizer threads. (That is probably a good thing ....)
This Q&A lists some alternative JAXB implementation: List of JAXB providers
Since it is open source, you could modify the finalize() implementation for the UnmarshallerImpl you are currently using.

The standard implementation of the finalize() method looks like this:

@Override
@SuppressWarnings("FinalizeDeclaration")
protected void finalize() throws Throwable {
    try {
        ClassFactory.cleanCache();
    } finally {
        super.finalize();
    }
}

Thinking about it ... you may be able to get away with not cleaning the ClassFactory cache every time an UnmarshallerImpl instance is garbage collected. Maybe this could just set a "global" flag to tell an asynchronous cache cleaner that there is work to do.

Of course, there is a maintenance overhead in using a modified library in the longer term, so it would be advisable to try to get your changes accepted by the upstream project.

UPDATE

I should have looked at cleanCache earlier, but it appears that all it does is to drop a map that has been cached in a thread-local. This should be cheap, and shouldn't be a source of contention. Also, it means that doing this asynchronously (i.e. on a different thread!) won't be effective. (It also means that the Cleaner approach suggested below won't work either.)

The other alternative is to not to call cleanCache at all, but that gives us a potential memory leak via the thread local!!

Either way, I am (now!) puzzled that this finalize() method is a bottleneck at all. Are you sure that the problem isn't caused by a different one?

I'm wondering why do glassfish implementation still has finalize() in UnmarshallerImpl, it really creates problems for me.

The answer is obvious. They haven't gotten around to¹ fixing it yet.

^{1 - Rhetorical questions: 1) How much money are you paying for support for your GlassFish implementation? 2) There are things called "open source bounties". Have you tried offering one to get this problem fixed?}

回复收藏 0 原文