web-dev-qa-db-ja.com

Java try / catchのパフォーマンス、try句内の内容を最小限に抑えることをお勧めしますか？

あなたがこのようなコードを持っていると考えると：

doSomething() // this method may throw a checked a exception
//do some assignements calculations
doAnotherThing() //this method may also throw the same type of checked exception
//more calls to methods and calculations, all throwing the same kind of exceptions.

実際、例外を作成するとき、特にスタックを巻き戻すときに、パフォーマンスが低下することがわかりました。また、try/catchブロックに入るときのわずかなパフォーマンスの低下を指摘するいくつかの記事を読みましたが、どの記事も何も結論付けていないようです。

私の質問は、try catch内の行を最小限に抑えることをお勧めしますか？つまり、実際にキャッチしている例外をスローできる行のみをtry句内に含めることをお勧めします。 try句内のコードの実行速度が低下しますか、それともパフォーマンスが低下しますか？.

しかし、これを行うことを検討する際のベストプラクティス/より読みやすいソリューションが何であるかがより重要です。

try {
    doSomething() // this method may throw a checked a exception
//do some assignements calculations
doAnotherThing() //this method may also throw the same type of checked exception
//more calls to methods and calculations, all throwing the same kind of exceptions.
}
catch (MyCheckedException e) {
   //handle it
}

または：

try {
    doSomething() // this method may throw a checked a exception
}
catch (MyCheckedException e) {
   //Store my exception in a Map (this is all running in a loop and I want it to   continue running, but I also want to know which loops didn't complete and why)
   continue;     
} 
 //do some assignements calculations
try {
    doAnotherThing() // this method may throw a checked a exception
}
catch (MyCheckedException e) {
    //Store my exception in a Map (this is all running in a loop and I want it to   continue running, but I also want to know which loops didn't complete and why)
   continue;
}

これは、もちろん、このチェックされたすべての例外をまったく同じ方法で処理することを考慮しています。

javaperformancetry-catchreadability
33
Oscar Gomez

ここでの例では、実際のパフォーマンスへの影響は、doSomething（）とdoAnotherThing（）の両方が例外をスローした場合です。 try-blockへの入力は、例外がスローされるまで高速です。

それは本当にあなたの状況が何であるかにかかっています。 MyCheckedExceptionがいずれかの方法でスローされたときに同じことを行う必要がある場合は、両方を同じtryブロックに入れる方が読みやすく、パフォーマンスも高いと思いますが、2つの異なる状況を異なる方法で処理する必要がある場合は、もちろんです。それらを分離する方が理にかなっています。

編集：私はあなたのコメントの終わりを読みました、あなたは両方を同じ方法で扱うことを想定しています、その場合私はそれらを同じtry-blockに入れます。

15
rwat

トライキャッチ内の線を最小限に抑えることをお勧めしますか？

いいえ。tryブロックの長さ、または実際に任意のブロックの長さがパフォーマンスに影響を与える可能性があるとどのように考えることができるか想像できません。

Try句内のコードの実行速度が低下しますか、それともパフォーマンスが低下しますか？.

番号。

ご覧のとおり、例外はスローされたときにのみパフォーマンスコストが発生します。

'try'のパフォーマンスが心配な場合は、コードを最大？に保つことをお勧めします。

23
user207421

どちらが遅いかはわかりませんが、tryブロックが制御フローであることを忘れないでください。制御フローを、達成しようとしているものと一致させる必要があります。私にとっては、

try {
    // op 1.
    // op 2.
    / ...
    // op n.
}
catch ( MyCheckedException error )
{
    // handle any `MyException` in op 1, 2 ... n.
}

それぞれのcatchブロックを分離することは、主に、操作ごとに異なる処理を行うか、エラーに関係なくop nまで実行を続けるか、すべてを実行して失敗するかを決定します。最初のエラー。

クリーンで読みやすいコードを記述し、その後ボトルネックを検索します。既存の実験で基本的なガイドラインを結論付けることができない場合は、とにかくボトルネックが見つかる場所ではないと思います。

4
André Caron

Try-blockを使用しても、適切なJVMでは基本的にパフォーマンスへの影響はありません。実際にヒットするのは、例外が実際にスローされたときです。

この記事 を読んで、JVMがバイトコードで例外処理を実装する方法を理解できます。コードの領域をキャッチ/最終的にブロックするようにマップする「例外テーブル」を作成します。

  • Tryブロックのバイトコードは標準の{}ブロックのバイトコードと同じです
  • スローしない場合の唯一の追加コストは、「例外テーブル」をメモリにロードすることです。

もちろん、例外がスローされると、多くのスタック作業が行われるため、コストがかかります。とにかく、SEH（.NET例外）ほど悪くはありません。

3
gpeche

コードは、何かを実行できる例外のみを処理する必要があり、他の例外は再スローする必要があります。

Tryブロック内のコードの量によって速度が低下することはありませんが、catchブロックをヒットすると速度が低下します。しかし、あなたが本当の高性能コードを書こうとしない限り、私はそれについて心配しません。

2
Jeroen van Bergen

Try/catchブロックの数を最小限に抑えると、パフォーマンスがわずかに向上しますが、例外がスローされたためにスキップされる作業を除いて、作業を移動しても実際には違いはありません。

1
Chris

各例外ブロックにはオーバーヘッドがあります。したがって、ブロックにとどまる時間を最大化する必要があります。

ただし、セマンティクスの違いも考慮する必要があります。最初の例では、doSomething()が例外をスローした場合、doAnotherThing()は実行されません。 2番目の例（catchハンドラーが返さないと仮定）では、doAnotherThing()が実行されます。

0
Mike Caron

tryブロック内でパフォーマンスが遅くなるかどうかはわかりませんが、ex.getStackTrace()のパフォーマンスは非常に遅いことがわかっています。これは、すべてのコマンドスタックとあなたはそれに注意する必要があります。

0
danny.lesnik

例外がスローされるたびに、スタックトレースを作成してデータを入力する必要があるため、例外には多くのコストがかかります。

資金不足のために1％のケースで失敗する残高転送操作を想像してみてください。この比較的少ない障害率でも、パフォーマンスに深刻な影響を与える可能性があります。

ソースコードとベンチマーク結果を参照してください ここ 。

0
Richard Gomes