手作りネットプロトコル工房コミュのVMの限界時の動作

僕は自動車やオートバイを飛ばすのが好きなんですが、自動車やオートバイは、スピードが上がってスピンしたり転倒したりする直前のギリギリの状態になると、通常とは違った挙動をします。 だから、峠とかに友達と飛ばしにいくに当たって、そういうギリギリの状態でどういう挙動が出るのかを普段から良く観察しておく事が大切ではないかと思います。

ところで最近、僕は自作のエディタを使って日記を書いていたのですが、突如 OutOfMemoryErrorが発生して、日記が全部消えました。 愕然として、誰だ、こんないい加減なコーディングするプログラマは！ と思ったんですが、自分でした。
（＾−＾；；；

そういうわけで、考えてみました。


今回の事件で感じたのですが、Javaは、C++なんかの言語と違って、メモリが限界近くなった時でも動作が割りと安定しているな、と思いました。 OutOfMemoryErrorが出たとしても、問題を解決すれば、ほとんど何も変らずに そのまま処理を続行出来たりするところは、すごく驚きました。ただ、ガーベージコレクタ式なのでメモリリークの原因を調査するのは、ちょっと簡単ではないのですが...。

この安定した動作が、裏目に出ることがあるみたいです。

ファイルを保存する時は、通常...

　1.ファイルを新規書き込みモードで開く
　2.書き込む
　3.閉じる

というような処理を行うと思うのです。

OutOfMemoryErrorが発生したら、誰でも、まず、作業状態を保存する事を考えると思うのですが、メモリが限界近い状態だと、たいがいの場合、この書き込むところでコケてしまいます。

そうすると、今までちゃんと健康な状態で保存されていたファイルまで壊れてしまうので、非常に困った事になります。

実は、僕は、コーディングするとき、こんな事もあろうかと、ファイルを開く前にリネームしてバックアップをとる機能を付けておきました。 さすが俺。

　1.既存のファイルがあったら、リネームしておく。
　2.ファイルを新規書き込みモードで開く
　3.書き込む
　4.閉じる

ところが、メモリが限界近くなると、処理が終わるまでに２０〜３０秒時間がかかる事があるみたいです。 セーブボタンを押したのにプログラムの反応がないとなれば、セーブボタンを連打したくなるのが人の常です。 僕も思わずやってしまいました。

そうすると、しばらくたって、3の書き込みでこけた後、もう一度この処理が走ってしまいます。 そうすると、コケた不健康なファイルでバックアップをとってしまうので、バックアップまで壊れちゃいます。 （＾−＾；；； 結局僕の工夫はなんの意味もありませんでした。

結局、OutOfMemoryErrorが出たら、すかさず、全ての処理を停止するしかないのかな、と思いました。 できれば、復帰できる範囲で復帰し、復帰中にエラーが出たら絶対にそれ以上は復帰を試みない、というフローを作る以外にないかなという気がしました。

メモリリークがたまった不健康な状態のままデータを操作するというのは非常に危険な事だと思います。 疲れが抜け切らないトラック運転手が東名高速をぶっ飛ばすのと同じ様なもので、すぐにデータを壊してしまいます。


今回は、SWINGアプリだったので、幸運なことに、目の前でアプリの挙動を観察できましたが、これが、サーバーアプリだと動作が全く見えないので、非常に苦労するような気がします。

J2EE全盛時代は、誰もがこの限界時の動作を観察しないでコーディングしていましたから、今思えば、かなり、無謀運転だったような気がします。

ちなみに、全てのスレッドには、

Thread#setUncaughtExceptionHandler( eh )

というメソッドがあって、OutOfMemoryError などの 捕捉されない Error例外を外部からハンドルする機能があるので、簡単にOutOfMemoryError の一元管理が出来ます。 Javaでは 元々このことが考えられていたのだと思います。

或いは、常にメモリの状態を観察して、危険な領域に近づいたら、エラーが発生する前に自動的に処理を停止して全ての状態を保存する、というのも非常によいアイデアだと思います。

ちなみにこの自作エディターで発生するエラーは、J2SE1.6でしか発生しないみたいで、しかも、常にJTextPane内部クラスで発生しているようなきがするので、ひょっとしたらSWINGのバグなのかもしれません。

いずれにせよ、何が起こっても絶対にデータを壊さないように、常に問題が起こることを想定しておきたいものです。