ByteArrayInputStreamを使用して「正しい」マーク/リセット動作を行う危険性/保証

Question

質問は一般的なものかもしれませんが、ここでの主な意味を理解しようとしています。

BCELライブラリを使用してバイトコードエンジニアリングを実行しようとしており、ワークフローの一部では、同じバイトコードファイルを複数回（最初から）読み込む必要があります。流れは次の通りです

// 1. Get Input Stream 

// 2. Do some work 

// 3. Finish 

// 4. Do some other work. 

手順4では、マークをリセットするか、ストリームを最初から取得する必要があります。私は以下の選択肢を知っています。

1）BufferedInputStreamを使用してストリームをラップ - 「マークを無効なリセット」取得のチャンスにIOException

2）するByteArrayInputStreamを使用して、それをラップ - それは常にいくつかのオンライン調査は、それが誤っだことを示唆しているにもかかわらず動作しますか？

3）ストリームからもう一度読む必要がある場合は、getInputStream()に電話するだけです。

私はどちらのオプションが良いのか理解しようとしています。最後のmarkが呼び出された場所がないので、BufferedInputStreamを使用したくないので、より高いマーク位置にresetを呼び出すとIOExceptionが発生します。 ByteArrayInputStreamを使用する方が好きですが、それは最低限のコード変更が必要ですが、誰かがオプション＃2かオプション＃3のどちらが良いかどうかを提案できますか？

JDKのByteArrayInputStreamとBufferedInputStreamでは、mark（）とreset（）の実装が異なることがわかりました。

よろしく

Answer 1

mark/resetの問題は、事前にこれらの呼び出しの間で読まれているデータの最大量を知るために、あなたはまた、コードは、あなたが意志に委任しているかどうかを知っている必要がありますしているということだけではありませんその機能を内部的に使用して、マークを廃止します。 mark/resetを使用しているコードでは、発信者の前のマークを覚えて復元することは不可能です。

合計ファイルサイズを最大でreadlimitと指定することで最大の問題を解決することは可能ですが、使用しないことを明示的に文書化していない任意のライブラリ関数にInputStreamを渡すときには、内部ではmark/reset機能です。

また、readlimitのファイルサイズの合計がreadlimitになると、同じサイズのバッファを維持するため、ファイル全体を保持する配列をラップするよりも効率的ではありません。

---

最高の解決策は、クラスファイル全体を一度アレイに読み込み、アレイを直接使用することです。 （ASMのClassReaderは、例えば、InputStreamの代わりにバイト配列を使用することをサポートしています）。あなたがそれを主張ライブラリ関数にInputStreamを供給する必要がある場合

、BCELのように、その後、必要なときにByteArrayInputStreamにバイト配列をラップしますが、は、クラスを再解析し、あなたが持っている新しいByteArrayInputStreamたびに作成ファイル。新しいByteArrayInputStreamを構築するのは、古い入力ストリームの状態には依存しないため、軽量ラッパーで信頼性が高いため、何もコストがかかりません。同時に複数のByteArrayInputStreamインスタンスで同じ配列を読み取ることもできます。

getInputStream()をもう一度呼び出すと、コンテンツ全体のバッファリングがオプションではない非常に大きなファイルに対処する必要がある場合は、オプションになりますが、これはクラスファイルには当てはまりません。