2

フレームワークで使用JMX MBeansしていspring 4ます。JMX mBean からの通知を処理し、イベントとして処理します。

別のアプローチをテストするために、通知処理部分をコメントアウトしました。これは、私の JMX Mbean が通知を発行し続けていることを意味し、私はそれらを無視しています。

PS: 経由で JMX 通知を処理しlogstashます。Logstashテストのために、構成をコメントアウトしました

通知はどうなりますか？どこに保管されますか？アプリケーションのメモリ/パイルアップに影響しますか?

4

2 に答える 2

2

JMX 通知は、オブザーバー パターンの実装です。このパターンでは、イベントは保存されないため、メモリの問題はありません。

NotificationBroadcasterJavaDoc:

MBean が通知を発行すると、addNotificationListener で追加され、その後 removeNotificationListener で削除されていない各リスナーが考慮されます。そのリスナーにフィルターが提供されていて、フィルターの isNotificationEnabled メソッドが false を返す場合、リスナーは無視されます。それ以外の場合は、リスナーの handleNotification メソッドが通知で呼び出されます...

こちらもご覧ください

失効したリスナーの問題

オブザーバー パターン リンクは、この問題を参照しています。明確にするために、この潜在的なメモリ リンクは、最初に心配していたもの (通知の保存) とは異なります。このメモリ リークは、logstash リスナーなどのリスナーが登録解除されていないことが原因で発生します。リスナーが登録解除されていない場合、ガベージ コレクトされない可能性があります。

これが心配な場合は、logstash 構成をコメント アウトすると、リスナーがそもそも登録されないことを確認する必要があります (おそらくそうなります)。とにかく、これは 1 つのリスナー オブジェクトにすぎないため、おそらく問題にはなりません。通知は継続的に作成されるため、通知に関する懸念はより深刻でした。

于 2016-03-17T05:35:05.857 に答える
1

メソッドのコード フローを Java でデバッグした後sendNotification: 以下の私の調査結果:

Flow of sendNotification Method: 
org.springframework.jmx.export.notification.ModelMBeanNotificationPublisher
javax.management.modelmbean.RequiredModelMBean (Sendnotification)
javax.management.NotificationBroadcasterSupport

のメソッドは、 (クラス ファイル内にNotificationBroadcasterSupport基づいて) 登録されているリスナーのみに通知を送信します。listenersListリスナーが登録されていない場合は、通知の送信をスキップします。

したがって、このことから、通知はどこにも保存されていないと想定/結論します。

@DavidSが示唆したように、登録後にremoveNotificationListenerに失敗し、通知を受け取りたくない場合、リスナーが通知を処理することになります。メモリ リークの考えられる原因。

于 2016-03-17T07:21:10.217 に答える