転置インデックスにアクセスするためのコードを書いています。インデックスの読み取りを実行する2つの交換可能なクラスがあります。ディスクからインデックスを読み取り、その一部をバッファリングします。もう1つは、バイト[] []（インデックスサイズは約7Gb）としてインデックスを完全にメモリにロードし、この多次元配列から読み取ります。データ全体をメモリに保存している間は、パフォーマンスが向上することが期待されます。しかし、私の測定では、ディスク上のインデックスを操作するのは、メモリにあるのと同じくらい高速であると述べています。（メモリにインデックスをロードするために費やされた時間は、パフォーマンスにはカウントされません）
なぜこうなった？何か案は？
詳細情報：HPROFを有効にするコードを実行しました。「ディスク上」または「メモリ内」で動作します。最もよく使用されるコードは、読み取りに直接関連するコードではありません。また、私の（限られた）理解のために、gcプロファイラーはgc関連の問題を表示しません。
更新＃1：I/O時間を監視するためにコードをインストルメント化しました。メモリでのシークのほとんどは0〜2000nsかかるのに対し、ディスクでのシークのほとんどは1000〜3000nsかかるようです。2番目のメトリックは私には少し低すぎるようです。Linuxによるディスクキャッシングが原因ですか？ベンチマークの目的でディスクキャッシュを除外する方法はありますか？
更新＃2：インデックスへのすべてのリクエストの応答時間をグラフ化しました。メモリとディスクの線はほぼ正確に一致しています。O_DIRECTフラグを使用してファイルを開く他のテストをいくつか実行しました（JNAのおかげです！）。その場合、コードのディスクバージョンは（明らかに）メモリよりも低速です。したがって、「問題」は、Linuxの積極的なディスクキャッシングが原因であると結論付けています。これは非常に驚くべきことです。