問題タブ [filechannel]

私は、メモリにマップされたファイル ( FileChannel.map()を介して) から構築されたByteBuffersと、メモリ内の直接 ByteBuffers を使用するものに取り組んでいます。並行性とメモリ モデルの制約を理解しようとしています。

FileChannel、ByteBuffer、MappedByteBuffer などの関連するすべての Javadoc (およびソース) を読みました。特定の ByteBuffer (および関連するサブクラス) に多数のフィールドがあり、状態がメモリ モデルから保護されていないことは明らかです。視点。そのため、特定の ByteBuffer の状態を変更するときに、そのバッファーが複数のスレッドで使用されている場合は同期する必要があります。一般的なトリックには、ThreadLocal を使用して ByteBuffer をラップする、(同期中に) 複製して同じマップされたバイトを指す新しいインスタンスを取得するなどがあります。

このシナリオを考えると：

1. B_allマネージャーには、ファイル全体にマップされたバイト バッファーがあります (2 GB 未満とします)。
2. マネージャーは、B_all で duplicate()、position()、limit()、および slice() を呼び出して、ファイルのチャンクである新しいより小さい ByteBuffer を作成し、B_1これをスレッド T1 に渡します。
3. B_2マネージャーは、同じマップされたバイトを指すByteBuffer を作成するためにすべて同じことを行い、これをスレッド T2 に渡します

私の質問は、T1 が B_1 に書き込み、T2 が B_2 に同時に書き込み、互いの変更を確実に確認できるかどうかです。T3 は B_all を使用してこれらのバイトを読み取り、T1 と T2 の両方からの変更を確実に確認できますか?

force() を使用して OS にページをディスクに書き込むように指示しない限り、マップされたファイルへの書き込みが必ずしもプロセス間で見られるとは限らないことを認識しています。私はそれを気にしません。この質問では、この JVM が単一のマップされたファイルを書き込む唯一のプロセスであると仮定します。

注: 私は推測を求めているわけではありません (自分で推測することはできます)。メモリ マップド ダイレクト バッファで何が保証されているか (または保証されていないか) について、決定的なものへの参照を希望します。または、実際の経験や否定的なテスト ケースがあれば、それも十分な証拠となる可能性があります。

更新:複数のスレッドが同じファイルに並行して書き込むことでいくつかのテストを行ったところ、これまでのところ、それらの書き込みは他のスレッドからすぐに見えるようです。そこまで頼れるか不安ですけどね。

RandomAccessFilesを使用するJavaのFileChannelクラスを使用してファイルを作成しました。ファイル内のさまざまな場所にオブジェクトを書き込みました。オブジェクトのサイズは可変でしたが、すべて同じクラスでした。私は次のアイデアを使用してオブジェクトを作成しました：

今、私はそのようなファイルから読みたいです。読み取るバイト数を指定する必要はありません。オブジェクト入力ストリームを使用してオブジェクトを直接読み取れるようにしたい。これを達成する方法は？

ファイル内のさまざまな位置に書き込む必要があるため、ランダムアクセスファイルを使用する必要があります。また、オブジェクトが書き込まれた場所を別のデータ構造で記録しています。

ログ ライブラリによって生成されるガベージの量を制限しようとしているので、FileChannel.write が作成しているメモリの量を示すテストをコーディングしました。以下のコードは、私の Mac に ZERO メモリを割り当てますが、Linux ボックス (Ubuntu 10.04.1 LTS) に大量のゴミを作成し、GC をトリガーします。FileChannel は高速で軽量であると想定されています。これが Linux で改善された JRE バージョンはありますか?

私のJREの詳細は以下の通りです：

更新:

そして、それはうまくいきました。:-|

これで、以前のバージョンの FileChannelImpl にはメモリ割り当ての問題があることがわかりました。

そのため、マップされたFileChannelを使用して非常に大きなファイルを読み込もうとしています。

ファイルが2GBを超えています。コードのスニペットは次のとおりです。

これはエラーをスローします：

FileChannel.mapはlong、ファイルサイズとしてを取ります。では、このエラーは意味がありますか？なぜ彼らはそれよりも大きなファイルのサポートを提供しないのでしょうか？

NIOライブラリで遊んでいます。ポート8888で接続をリッスンしようとしています。接続が受け入れられたら、そのチャネルからにすべてをダンプしますsomefile。

でそれを行う方法は知っていますがByteBuffers、非常に効率的だと言われているで動作させたいと思いますFileChannel.transferFrom。

これは私が得たものです：

だから、私の質問は、「transferFromストリームの終わりに達するまで、いくつかのチャネル」をどのように表現するのですか？

^{編集：使用されるバッファのサイズは質問とは無関係であるため、1024をBUF_SIZEに変更しました。}

以下のように ByteBuffer を使用して読み続ける状況があります。

しかし、読み取りが境界に達したとき (読み取る残りのバイト数が BUFFER_SIZE 未満のとき) boundaryLimit - FileChannel's current position、.

境界制限が x で、現在の位置が y であることを意味します。次に、バイトを読み取る必要があり、それをy超えxないようにする必要があります。

どうすればこれを達成できますか?

新しい容量で別のインスタンスを作成したくありません。

RandomAccessFileとそのFileChannelがあります。私がやろうとしているのは、そのファイルからバイトの特定のセクションを読み取ることです。ただし、FileChannelの読み取りメソッドを調べている間、私がやろうとしていることに役立つオーバーロードは見つかりませんでした。コンテンツ全体を読み取るメソッド、または読み取ったバッファー内の特定の位置にコンテンツを読み取るメソッドのみが表示されました。メソッドが取り入れます。特定のバイトのチャンクを読み取るという目標を達成するのに役立つ、欠落しているメソッドはありますか、それともチャネル全体をバッファーに読み込んでから、何らかの方法でセクションを解析する必要がありますか？

今日、ユーティリティ クラスの 1 つで問題が発生しました。これはファイルのヘルパーであり、いくつかの静的ファイル コピー ルーチンが含まれています。以下は、テスト方法とともに抽出された関連する方法です。

問題は、setLastModified 呼び出しが失敗して、false が返されることがあるということです。

私の PC (Windows 7、最新の Java) では、「setLastModified failed」というメッセージが表示されることがあります (1000 回中約 25 回)。

FileChannel.close 呼び出しを削除することで問題を回避しましたが、それが正しい解決策であっても、なぜこれが起こっているのかを理解したいと思っています。

他の誰かが同じ問題を抱えていますか？

編集:を閉じるStreamsと.FileChannelFileChannelStream

開いている RandomAccessFile インスタンスからファイル名を取得するにはどうすればよいですか?

ファイル自体に関連する次のメソッドのみを見つけることができます。

• getFD(): FileDescriptor オブジェクトを返します
• getChannel(): FileChannel オブジェクトを返します

File クラスのインスタンスを取得するか、RandomAccessFile のコンストラクターに渡すファイル名文字列を直接取得したいと思います。

ありがとう！

5 ～ 6 個のスレッドを作成するアプリケーションを考えてみましょう。サイクル内の各スレッドは、5 MB のページ サイズに MappedByteBuffer を割り当てます。

遅かれ早かれ、アプリケーションが大きなファイルを処理すると、oom がスローされます

仕様によると、MappedBuffer は GC 自体であるとすぐにダイレクト メモリを破棄する必要があります。問題は、MappedBuffer の GC 処理が遅すぎて、後でダイレクト メモリが終了したことです。

この状況を回避するには？おそらくMappedBufferを暗黙的に破棄するか、MappedBufferのある種のプールを使用すると言います