日記というよりは過去を振り返るときのための単なる備忘録この広告は、90日以上更新していないブログに表示しています。前回では、ヒープ上に確保したByteBufferと、ダイレクトバッファとして作成したByteBufferでのデータの読み取りパフォーマンスを比較した結果、圧倒的にダイレクトバッファが速いことが分かった。上記ベンチマークは、あえてByteBuffer単体でのパフォーマンスの比較を行ったものであり、実際のファイル入出力処理を含んだ比較ではない。純粋なByteBufferの性能比較である。実際にファイルの読み取りを含んだ場合でも、はたしてダイレクトバッファを使ったほうが速いのであろうか?今回は、実際の利用方法を意識して、このあたりを調べてみることとする。ヒープバッファとダイレクトバッファの違いByteBufferには大きく分けて2種類がある。ヒープ上の作成されるヒープバッファネイティブ領域に作成されるダイレクトバッファヒープバッファは以下のように作成される。byte[]を実行しているだけである。)これは、当然、Javaのヒープ領域からバッファが割り当てられる。バッファとして確保した分、利用可能なヒープサイズは減ることになる。その特性はJavaの一般的なオブジェクトと何ら変わることは無い。これに対して、ダイレクトバッファは以下のように作成される。ByteBuffer.allocDirect(siz);(そのほか、RandomAccessFileから直接MappedByteBufferを取得する方法もある。)こちらはJavaのヒープではなく、ネイティブメモリ上から割り当てられる。ダイレクトバッファはヒープ上にバッファは作らないので、ヒープはほとんど減らない。そのかわり、ネイティブメモリ、つまりOS側からJavaVMが借りているコミットメモリが増える。ネイティブメモリはガベージコレクタが管理しているメモリの範囲外であるため、ガベージコレクトなどのメカニズムが効かない領域である。タスクマネージャで見られるように、アプリ終了前に一旦停止する。MiBごとのバッファを確保しながらヒープの残量を表示し、最後に入力待ちになって停止するアプリである。heap127831384/128974848118026720/128974848107540896/12897484897055072/12897484886569248/12897484876083424/12897484865597600/12897484855111776/12897484844625952/12897484834140128/12897484823654304/128974848バッファを確保するたびにヒープがどんどん減ってゆく順当な動きである。direct127831360/128974848128512256/128974848128512120/128974848128511984/128974848128511848/128974848128511712/128974848128511576/128974848128511440/128974848128511304/128974848128511168/128974848128511032/128974848ヒープはぜんぜん減っていない。