red5をapplet化してみる。その５、メモリーによけいなものがのこった原因の考察

さて、前回ではClassLoaderで読み込んだデータが残る条件をしらべてみたわけですが、
GUI上で起動したRed5のプログラムを殺してもなぜデータがのこってしまったのでしょう？

というわけでその考察です。
JavaVisualVMのメモリーデータをDumpしてみるとslf4jのloggerの部分やapache-mina、springframework、それにRed5のプログラムがのこったままになっているようです。
いっぱいのこってます・・・orz
実際にどうなるかは、そのうちRed5を起動するJavaApplication公開するので、そのときにやってみてください。

どうやらThread的には、ほぼ壊滅状態みたいです。
net.sf.ehcache.CacheManager
NioSocketAcceptor-1
このあたりが待機スレッドになっているのと、
Jconsoleで接続したところ、Jconsoleに追加された管理用のObjectがしつこくのこっているくらいだろうか？

実際にRed5を実行したときに増えるスレッド一覧は次のとおり
NioSocketAcceptor-1
Red5_scheduler_QuartzSchedulerThread
Red5_scheduler_Worker-1 - 4
pool-2-thread-1
net.sf.ehcache.CacheManager
RMI TCP Connection
GC Daemon
RMI Reaper
RMI TCP Accept-0
RMI TCP Accept-9999
pool-1-thread-1-4
http-0.0.0.0-5080-Acceptor
ContainerBackgroundProcessor

先ほどのシャットダウンをやってみたときのと比べてみるとほぼ死んでいるような・・・
ついでにJMXに登録しているデータをリストアップしてみる。
起動時についてくるのはorg.red5.serverとred5Engineの２つ、後者はtomcatの動作からくるみたい。ということはJetty系のRed5の場合はそっちのデータがつくことも考慮しないとだめみたいですね。

シャットダウンを実行するとred5Engineの一部だけ残るみたいです。

今後とるべき方針はJMXに登録しているオブジェクトを削除。それでだめなら、該当スレッドをなんとか停止するようにする。

この２本だてでせめればよさそうですね。
ちなみに余談ですけど、再度起動した場合でもきちんとred5は動作するようです。古いデータが消えずにメモリーを圧迫するようなので、きちんとやらないとだめですけどね＾＾；