dom apiのJavaマルチスレッド

Question

私はxml解析を行う関数を持っています。私は関数スレッドを安全にしたいが、できるだけ最適化された（ブロッキングが少ない）ようにしたい。

public Document doXML(InputStream s) 
{ 
//Some processing. 
    DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance(); 
    DocumentBuilder parser = factory.newDocumentBuilder(); 
    Document xmlDoc = parser.parse(is); 
    return xmlDoc; 

} 

しかし、私は、各呼び出しで新しいのDocumentBuilderFactoryまたはDocumentBuilderのを作成する必要はありません。次のように短いコードで
は何かです。
私はファクトリとパーサを再利用したいが、スレッドセーフであるとは確信できません。だから最適なアプローチは何ですか？
1） DocumentBuilderFactoryをクラスフィールドにキャッシュし、factory.newDocumentBuilder（）を同期させます。キャッシュのDocumentBuilderFactory とてDocumentBuilderと同期parser.parse（である））は、各スレッドがDocumentBuilderの
2の独自のインスタンスを有するように、スレッドごとに
私は（2）が最適だと思いますが、それは安全ですか？また、同期してブロックすることもできますか？私はできるだけ早くそれをしたいと思います。

ありがとうございます。

Answer 1

スレッドを再利用する場合（スレッドプール内など）、DocumentBuilderFactoryをスレッドローカルに宣言できます。スレッドごとに新しいセットを作成するオーバーヘッドがありますが、私が言ったように、あなたがreuisingしている場合、後続のオーバーヘッドは非常に低いです。

final ThreadLocal<DocumentBuilderFactory> documentBuilderFactor = new ThreadLocal<DocumentBuilderFactory>(){ 
    public DocumentBuilderFactory initialValue(){ 
     return DocumentBuilderFactory.newInstance(); 
    } 
} 

public Document doXML(InputStream s) 
{ 
//Some processing. 
    DocumentBuilderFactory factory = documentBuilderFactor.get(); 
    DocumentBuilder parser = factory.newDocumentBuilder(); 
    Document xmlDoc = parser.parse(is); 
    return xmlDoc; 

} 

ここでは、スレッドごとに1つのDocumentBuilderFactoryを作成します。

DocumentBuilderが解析時にスレッドセーフであるかどうかはわかりません（不変ですか？）。しかし、DocumentBuilderが構文解析時にスレッドセーフであれば、私が述べたのと同じメカニズムを使用できます。

この解像度は、全体のスループットをできるだけ速くします。

注：これはテストされていないか、コンパイルされているだけで私が何を参照しているのアイデアを与える。

Answer 2

同期ブロッキングを避けるには、アトミック操作を使用する必要があります。 javax.xml.parser.*の動作は、実装によって異なります（システムプロパティを使用して実装を指定するか、実装コードを呼び出すことができます）。スレッド数と各スレッドの負荷重みに応じて、パーサーオブジェクトの作成を制御することが妥当かもしれません。新しいパーサーの作成か、パーサーの待機のどちらかを選択する必要があります。このコードは、開始時にパーサーのプールを作成してから、スレッドがプールからパーザを取得します。パーザは、フリーパーサーが存在しない場合にブロックされます。スレッドがパーサーを取得すると、データを解析し、パーサーをリセットしてプールに戻します。プールの長さによって、時間/メモリ使用量をいつでも制御できます。

Answer 3

2）スレッドセーフですが、アプリは一度に1つのドキュメントしか解析できません。

あなたが持っているコードを使ってみませんか？ありますか

DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance(); 
DocumentBuilder parser = factory.newDocumentBuilder(); 

明らかに受け入れられないオーバーヘッドはありますか？

Answer 4

同様の状況でパフォーマンスの問題が発生しました。私はスレッドの問題（1秒あたり10秒）を避けるために、それぞれの使用時にファクトリオブジェクトを作成していました。その（確かに古い）プラットフォームのXML実装は、サービスプロバイダクラスの比較的遅いルックアップロジックを実行しました。

私が調整したのは、結果として得られた答えを決定し、コマンドラインのプロパティで設定することでした。そのため、ルックアップはスキップされました。

-Djavax.xml.parsers.DocumentBuilderFactory=com.example.FactoryClassName 
-Djavax.xml.transform.TransformerFactory=com.example.OtherFactoryClassName 

クラスが見つかった場合、ルックアップコードがキャッシュロジックを持っていたというのは残念でした。しかし、ミスのキャッシングはありません（何も見つからず、デフォルトを使用します）。ネガティブなケースを処理していたルックアップキャッシュを少し改善すれば、これは不要になりました。

これはまだ必要ですか？あなたの環境でのテストが必要です。 Solaris上でtrussを使用して、そのルックアップロジックに起因する非常に頻繁なファイル操作に気付きました。