Java低遅延アプリケーションの包括的なチェックリストを作成したいと思います。ここにチェックリストを追加できますか?
これが私のリストです
1。オブジェクトを不変にする
2。同期メソッドを減らしてみてください
3。ロックの順序は十分に文書化され、慎重に処理される必要があります
4。プロファイラーを使用する
5。アムダールの法則を使用して、順次実行パスを見つけます
6。 Java 5つの同時実行ユーティリティとロックを使用する
7。プラットフォームに依存するため、スレッドの優先順位は避けてください
8。 JVMウォームアップを使用できます
9。不公平なロック戦略を好む
10。コンテキストの切り替えを避けます(多くのスレッドは逆効果につながります)
11。ボクシング、開封は避けてください
12。コンパイラの警告に注意してください
13。スレッドの数はコアの数以下である必要があります
低遅延アプリケーションは、ミリ秒ごとに調整されます。
不変性は良好ですが、必ずしもレイテンシーが改善されるとは限りません。低遅延を確保することは、プラットフォームに依存する可能性があります。
一般的なパフォーマンス以外に、GCの調整は非常に重要です。メモリ使用量を減らすと、GCに役立ちます。特に、移動する必要のある中年のオブジェクトの数を減らすことができる場合は、オブジェクトを長寿命または短寿命のいずれかに保ちます。また、permgenに触れないようにしてください。
ボックス化/ボックス化解除を避け、可能であればプリミティブ変数を使用します。
購入、読み取り、および理解有効なJava 。また オンラインで入手可能
メッセージ処理パスで可能な限りコンテキストの切り替えを回避する結果:NIOと単一のイベントループスレッド(リアクター)を使用する
最新のプロセッサ(およびそのキャッシュ)の拡張機能を中断しないように、大規模なロックやマルチスレッドは避けてください。次に、非常に低いレイテンシで、信じられないほどの制限(1秒あたり600万トランザクション)まで単一のスレッドを使用できます。
実世界の低レイテンシJavaアプリケーションとそのアーキテクチャに関する十分な詳細を確認したい場合は、LMAXを参照してください。
測定、測定、測定。ベンチマークを定期的に実行するには、実稼働ハードウェアにできるだけ近い実際のデータに近いものを使用してください。低レイテンシのアプリケーションはアプライアンスと見なされることが多いため、特定のメソッド/クラス/パッケージ/アプリケーション/ JVMなどだけでなく、展開されたボックス全体を考慮する必要があります。設定などの本番環境で現実的なベンチマークを構築しないと、製造。
基盤となるハードウェアにコアがあるよりも多くのスレッドをアプリケーションにスケジュールしないでください。 OSはスレッドの実行と、同じハードウェアを共有する可能性のある他のサービスを必要とするため、アプリケーションは使用可能なコアの最大数よりも少ない数を使用する必要がある場合があることに注意してください。
「オブジェクトを不変にする」よりも「適切な場合にのみ可変オブジェクトを使用する」の方が良いと思います。多くの非常に低遅延のアプリケーションには、GCを最小限に抑えるために再利用するオブジェクトのプールがあります。不変オブジェクトはそのように再利用することはできません。たとえば、Locationクラスがある場合:
class Location {
double lat;
double lon;
}
起動時にいくつかを作成し、それらを何度も使用して、割り当てや後続のGCが発生しないようにすることができます。
ただし、このアプローチは不変のロケーションオブジェクトを使用するよりもはるかに難しいため、必要な場合にのみ使用する必要があります。
大きな文字列を生成するときは、StringBuilder
の代わりにString
を使用してください。たとえば、クエリ。
もう1つの重要なアイデアは、最初に機能させてからパフォーマンスを測定し、ボトルネックを特定して最適化し、再度測定して改善を確認することです。
クヌースが言ったように、「時期尚早の最適化はすべての悪の根源です」。
ここですでにアドバイスされている開発者レベルのソリューションに加えて、ZingやTeracotta BigMemory、Apache Igniteなどのオフヒープメモリソリューションなどの高速化されたJITランタイムを検討して、Stop-the-worldGCの一時停止を減らすことも非常に有益です。 Hessianのようなバイナリプロトコルを使用するGUIがある場合、Webサービスなどの代わりにZERO-CICEが非常に効果的です。