Scala / Akkaを使用したJVMでの高頻度取引
Javaの架空のHFTシステムを想像してみてください。これは、（非常に）低レイテンシーを必要とし、不変性（Scala？）による短命の小さなオブジェクトがたくさんあり、1秒あたり数千の接続があり、イベント駆動型アーキテクチャ（akkaとamqp？）。
そこにいる専門家にとって、JVM 7の最適なチューニングは（仮想的に）何でしょうか？どのような種類のコードがそれを幸せにするでしょうか？ ScalaとAkkaはこの種のシステムの準備ができていますか？
注：このようないくつかの同様の質問がありました one 、しかし私はまだカバーしているものを見つけていませんScala（JVMに独自の特異なフットプリントがあります）。
Javaで非常に優れたパフォーマンスを実現することは可能です。ただし、信頼できる回答を提供するには、質問をより具体的にする必要があります。レイテンシーの主な原因は、以下の非網羅的なリストから得られます。
作成するゴミの量と、それを収集して宣伝するためのGCの作業。私の経験では、不変の設計は低遅延にはうまく適合しません。 GCチューニングは大きな焦点である必要があります。
JVMをウォームアップして、クラスがロードされ、JITがその作業を実行できるようにします。
アルゴリズムをO(1)または少なくともO（log2 n）になるように設計し、これを主張するパフォーマンステストを行います。
デザインはロックフリーで、「 シングルライターの原則 "」に従う必要があります。
スタック全体を理解し、その使用に機械的な共感を示すことに多大な努力を払う必要があります。
キャッシュに適したアルゴリズムとデータ構造を設計します。最近のキャッシュミスは最大のコストです。これはプロセスの親和性と密接に関連しており、正しく設定しないと、キャッシュが大幅に汚染される可能性があります。これには、OSや、場合によってはJNIコードへの共感が含まれます。
実行する必要のあるスレッドが待機せずにコアを使用できるように、十分なコアがあることを確認してください。
私は最近、そのような演習の ケーススタディ についてブログを書きました。
メッセージパッシングにリングバッファを使用すると、Akkaで実行できるものを超える場合があります。金融アプリケーション用にJVMで使用される主なリングバッファの実装は、Disruptorと呼ばれるもので、効率（2サイズの累乗）、JVM（GCなし、ロックなし）、および最新のCPU（偽共有なし）に注意深く調整されています。キャッシュライン）。
これがScalaの観点からの紹介プレゼンテーションです http://scala-phase.org/talks/jamie-allen-sdisruptor/index.html#1 最後のスライドには、元のLMAXのものへのリンクがあります。