gpt4 book ai didi

java - 是否有必要从 Platform MBean Server 注销 MBean?

转载 作者:塔克拉玛干 更新时间:2023-11-03 04:29:18 27 4
gpt4 key购买 nike

我已经开始使用 MBean 来公开有关应用程序的一些信息。几乎全部的 HOWTO/教程/博客文章/在线示例都在教您如何实现 MBean 并将其注册到 MBean 服务器,但从未提及(或只是粗略地)从服务器注销 MBean。

我担心一个 MBean 需要引用一个相当重量级的对象才能提供有关该对象的状态信息。

Platform MBean Server 是否维护对 MBean 的弱引用或其他类似技巧,以确保在您的应用程序不再持有对它的任何引用时它最终得到 GC?通常不需要取消注册,从而解释为什么没有人在 JMX 教程中谈论它?

最佳答案

您不能“弱”地向服务器注册一个 MBean(目前),从而期望它在没有其他对它的引用存在时被 GC。

话虽如此,您绝对应该阅读 Eamonn McManus 就此主题发表的一些文章。

https://web.archive.org/web/20120207140653/http://weblogs.java.net/blog/emcmanus/archive/2005/07/cleaning_up_an_1.html

It's been suggested that the JMX API could have some explicit support for "Weak MBeans" like this. I'm not sure there's enough use for them to justify including them in the API, and I'm also not sure what a general-purpose API for Weak MBeans would look like. But the above shows how you can create your own Weak MBeans if need be.

https://web.archive.org/web/20090114131740/http://weblogs.java.net/blog/emcmanus/archive/2005/07/javaone_feedbac.html

"Weak" MBeans. An MBean frequently manages another Java object that is the "resource" to be monitored or controlled. But what if the only reference to that resource is from the MBean? Could we somehow arrange for the MBean to disappear if the resource is no longer referenced by anyone else?

Turning on and off expensive MBeans. Some MBeans may export information that is continuously sampled and that is expensive to gather. You don't necessarily want those MBeans to be running all the time. Ad hoc solutions are easy, for instance the setThreadContentionMonitoringEnabled method in java.lang.management.ThreadMXBean. But perhaps there could be a more general convention, such as a setDetailLevel(int) method.

关于java - 是否有必要从 Platform MBean Server 注销 MBean?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/386892/

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