ガベージコレクション

　"Tokyo Railways コンピュータ版"の開発ですが、一応、ＢＧＭを作り終わったので、本格的にプログラミングに戻ってます。
　Macbook Airで動かしてみたら、MIDIだけでなくMP3もぶつぶつに切れて聴けたもんじゃない。こりゃ困ったと思い、本腰を入れて調べてみました。
　これまでには対策としてJAVA標準のソフトMIDIシーケンシャーやMP3を再生するスレッドが、思考ルーチンなどの他の重たい処理をやってるスレッドに割り込まれないように、音楽再生以外のスレッドの優先度を下げていたのですが、どうやらそれでも何かの処理に割り込まれてしまって、音楽の再生が途中で中断してしまっているようです。
　その結果、MIDIはテンポが崩れ、MP3はぶつぶつときれている様子。それで、すぐにピンと来たのはガベージコレクション処理です。JAVAは使用が終わったメモリを定期的にガベージコレクション処理を動かして開放しているのですが、この時に開放するメモリーが多いと、他の処理が長時間待たされてしまいます。
　今のところ、このプログラムでは最大256MバイトをJAVAに割り当てているのですが、少し前まではメモリが厳しくなっていて、ガベージコレクション処理が間に合わず、メモリー不足のエラーが発生するケースがありました。それで、移動や建設などの後で明示的にガベージコレクションをやってたのですが、よくよく調べていくと、これがいけなかったみたいです。
　処理としてはガベージコレクションで十分の一秒単位の時間を消費したって、ほとんど問題にならないのですが、音楽にとって十分の一秒どころか百分の一秒だって中断したらテンポが狂ったりノイズが入ったりして、耳障りに聞こえてしまいます。
　で、対策としては明示的なガベージコレクションは極力やめるようにしてみました。さすがに前のマップを破棄して、新しいマップを読み込むときには、短時間に大量のメモリーを破棄して新たに確保するので、このタイミングにはガベージコレクションを残しましたが、それ以外の部分は全て取っ払いました。
　こんなことしてメモリが足りなくならないかとちょっと心配しましたが、最近のバージョンアップで地道にメモリーの使用量を減らしてきたおかげで、ちょっとテストしたかぎりでは明示的なガベージコレクションがなくても大丈夫な様子です。
　そして、肝心のMIDIとMP3の再生ですが、完璧というわけには行きませんが、ほとんど問題にならないレベルまで改善されました！

　これでこの問題はひとまず解決ということにしておきます。
　でもねえ、MIDIの再生にはもう一つ根本的な問題がある。UbuntuでOpenJDKを動かしてテストしててわかったのですが、OpenJDKのMIDI再生は音がショボすぎます。こればっかりはどうしようもないので、我慢してもらうかMP3版を使ってもらうしかないですねえ。