0

DirectByteBuffersを使用して、C++で記述されたサードパーティのライブラリをインターフェイスすることを計画しています。

私はhadoopドキュメントから次のように心配しました：

DirectByteBuffersは、ファントム参照と参照キューを使用してガベージコレクションされます。時々、JVMは参照キューをチェックし、DirectByteBuffersをクリーンアップします。ただし、これはDirectByteBufferへのすべての参照を破棄した直後には発生しないため、DirectByteBuffersを使用して自分でOutOfMemoryErrorを実行するのは簡単です。

まず、 OpenJDK 7はファントム参照を使用していないように見えるため、DirectByteBuffersのすべての実装が同じかどうかはわかり ませんが、パフォーマンスが低下するはずのfinalizeメソッドに依存しています。

次に、を使用してOutOfMemoryErrorを複製しようとしました

public static void main(String[] args) {
    for(;;){
        ByteBuffer buff = ByteBuffer.allocateDirect(1000*1000);
    }
}

そして、すべてが適切にガベージコレクションされるようです。これが私のマシンの場合は

java version "1.6.0_31"
Java(TM) SE Runtime Environment (build 1.6.0_31-b04-415-11M3635)
Java HotSpot(TM) 64-Bit Server VM (build 20.6-b01-415, mixed mode)

これが他のすべてのマシンとJavaバージョン>=1.6で機能することを信頼できますか？

ありがとう

4

2 に答える 2

2

これは、Java 6の初期バージョンのバグでした。ただし、JVMに含まれていた簡単な回避策は、System.gc（）をトリガーした後にのみOutOfMemoryErrorをスローすることでした。これで、明示的なGCを無効にすることで、この問題をシミュレートできます。

java.nio.Bits.reserveMemory（long）のソース

GCがダイレクトメモリまたはメモリマップトファイルをクリーンアップするのを待つのではなく、OpenJDKベースのJVM（ホットスポットなど）に適した内部APIを使用します。これにより、スプリアスフルGCが減少し、パフォーマンスが向上します。

((DirectBuffer) buffer).cleaner().clean();

ヒープバッファがある場合、cleaner（）はnullを返します。

于 2012-06-07T15:18:25.417 に答える
2

これはこのテーマに関する素晴らしい記事です。

あなたのテストに関しては、そのような単純なテストは実際には問題領域を行使しません。GCが大幅に遅れると、潜在的な問題が発生します。そのようなテストでは、GCは他に何もしていないので、追いつくのに問題はないでしょう。

于 2012-06-07T15:21:13.657 に答える