Java Language
Javaパフォーマンスチューニング
サーチ…
一般的方法
インターネットには、Javaプログラムのパフォーマンス向上のヒントが満載されています。多分1番のヒントは意識です。つまり、
- パフォーマンス上の問題とボトルネックを特定します。
- 分析ツールとテストツールを使用する。
- 良い習慣と悪い習慣を知る。
新しいシステムやモジュールについて話す場合、最初のポイントは設計段階で行う必要があります。レガシーコードについて語ると、解析ツールとテストツールが登場します。 JVMのパフォーマンスを分析するための最も基本的なツールは、JVisualVMです。これはJDKに含まれています。
三点目は、経験と豊富な研究について、など、このページなどに表示されますもちろん生のヒント、の主にあるこの 。
ストリングの量を減らす
Javaでは、必要とされない多くのStringインスタンスを作成するのは簡単すぎます。それ以外の理由で、プログラムでGCが忙しくなっているストリングがたくさんある可能性があります。
Stringインスタンスを作成する方法はいくつかあります。
myString += "foo";
ループや再帰では、悪いことに、
for (int i = 0; i < N; i++) {
myString += "foo" + i;
}
問題は、各+が新しいStringを作成することです（通常、新しいコンパイラはいくつかのケースを最適化するので）。 StringBuilderまたはStringBufferを使用して最適化を行うことができます。
StringBuffer sb = new StringBuffer(myString);
for (int i = 0; i < N; i++) {
sb.append("foo").append(i);
}
myString = sb.toString();
長いString（たとえばSQL）を頻繁に構築する場合は、String構築APIを使用します。
考慮すべき他の事項：
-
replace、substringなどの使用を減らす - 特に頻繁にアクセスするコードでは、
String.toArray()避けてください。 - フィルタリングすることを目的としたログ出力（例えば、ログレベルのため）は生成しないでください（ログレベルは事前にチェックする必要があります）。
- 必要に応じて、 このようなライブラリを使用してください。
- 変数が非共有の方法（スレッド間）で使用される場合、StringBuilderが優れています。
Javaのパフォーマンスチューニングに対する証拠ベースのアプローチ
ドナルド・クヌスはこれを次のように引用しています。
「プログラマはについて考える時間の膨大な量を無駄にし、または気にせ、そのプログラムの重要度の低い部分の速度、およびデバッグ、メンテナンス時の効率でこれらの試みは、実際に強い負の影響を与えることが考えられている。 我々は小さな効率を忘れなければならない、について言います97％の時間 ：時期尚早の最適化はすべての悪の根源ですが、重要な3％で機会を逃すべきではありません。
sageに関するアドバイスを念頭に置いて、ここではプログラムを最適化するために推奨される手順です：
まず、シンプルさと正確さに焦点を当てて、プログラムやライブラリを設計し、コーディングします。まず、パフォーマンスに多大な努力を払わないでください。
それを動作状態にし、コードベースの主要部分の単体テストを開発することが理想的です。
アプリケーションレベルのパフォーマンスベンチマークを開発する。ベンチマークは、アプリケーションのパフォーマンス上の重要な側面をカバーし、アプリケーションを本番環境でどのように使用するかの典型的な一連の作業を実行する必要があります。
パフォーマンスを測定します。
測定されたパフォーマンスと、アプリケーションがどれくらい速くなる必要があるかに関する基準とを比較してください。 （「できるだけ早く」などの非現実的な、達成不可能な、または決定不能な基準を避ける）
条件を満たす場合は、停止してください。あなたは仕事が終わった。 （それ以上の努力はおそらく時間の無駄です。）
アプリケーションがパフォーマンスベンチマークを実行している間にプロファイリングします。
プロファイリングの結果を調べ、最大の（最適化されていない） "パフォーマンスのホットスポット"を選択します。すなわち、アプリケーションが最も時間を費やしていると思われるコードのセクション。
ホットスポットコードセクションを分析して、なぜボトルネックであるのかを理解し、高速化する方法を考えてください。
提案コード変更、テスト、デバッグとして実装します。
ベンチマークを再実行して、コードの変更によってパフォーマンスが向上したかどうかを確認します。
- はいの場合は、手順4に戻ります。
- いいえの場合は、変更を放棄して手順9に戻ります。進捗がない場合は、別のホットスポットを選択して注目してください。
最終的には、アプリケーションの速度が十分速いか、重要なホットスポットのすべてを検討した時点になります。この時点で、このアプローチを止める必要があります。コードの一部が全体の時間の1％を消費している場合、50％の改善でさえ、アプリケーションを全体的に0.5％速くするだけです。
明らかに、ホットスポットの最適化が努力の無駄である点があります。その点に到達すれば、より根本的なアプローチを取る必要があります。例えば：
- コアアルゴリズムのアルゴリズムの複雑さを見てください。
- アプリケーションがガベージコレクションに多くの時間を費やしている場合は、オブジェクトの作成速度を低下させる方法を探します。
- アプリケーションの重要な部分がCPU集約型でシングルスレッドの場合は、並列処理の機会を探します。
- アプリケーションがすでにマルチスレッドの場合は、並行性のボトルネックを探します。
しかし、可能な限り、あなたの最適化作業を指示するために本能的ではなく、ツールと測定に頼ってください。