どうやら原因はキャッシュらしい

今もう一度実行しなおしたら，MappedByteBufferのほうで60秒ぐらいかかった．
なるほど，これぐらいの差なら説明できる．別のマシンでjava.nio の
MappedByteBufferを使ったのとjava.ioのRandomAccessFile を使って
データをダンプするプログラムの実行速度を比較したら1分と3〜4分
ぐらいの差があったので，それと同じになっているのがわかる．

まあ，これだけで3〜4倍の性能差でるのでもすごいけど，恐ろしいのはキャッシュの効果．
たしかに，140MBならメモリに載るサイズだけど，実際にアクセスするパターンは
ランダムなわけで，キャッシュが効いたからと言って1分が2秒になるのは恐ろしい．
一応プロセスは一旦終了しているわけなんだし．
# OSから見たら関係ないんだろうけどさ

もしこれが何度も同じ部分をアクセスするプログラムだったら，MappedByteBuffer使う
価値はかなり上がるよな．．．

ただ，まったく問題ないわけじゃないと思う．たぶん普通の使い方ならこれで
問題ないけど，positionのメソッドがint型だということ．つまり，一回の
MappedByteBufferの割り当てだと2Gのデータしかアクセスできないと思われる．
再割り当てすれば済む話だが，たぶん再割り当てのオーバーヘッドって，
検証はしていないけど，安くないと思う．
はじめから64bitになっていれば問題なかったんだろうけど．