Javaパフォーマンス：現在と未来

20年の間、Javaアプリケーションにはパフォーマンスの問題があるという神話が積極的に生み出されてきました。 同時に、真に高負荷のシステムがJavaで作成されています。 最終的に誰が正しいのですか？ Javaのパフォーマンスがどのように変化するかを知るために、2つの利害関係者に注目しました。Java自体の作成者と、システムでJavaを使用するクライアントです。 Alexei Shipilev（Oracle）とOleg Anastasiev（Odnoklassniki）は、私たちの質問に答えることに親切に同意しました。

JDKクリエーターの目を通して見たJavaパフォーマンス

JUG.RU：あなた自身とあなたの仕事について教えてください？

Alexey Shipilev：私の名前はAlexey Shipilevです。 私は10年以上にわたってJavaのパフォーマンスに取り組んできました。 この間、さまざまなJVMで作業することができました。最初はIntelのApache Harmonyで作業し、次にSun Microsystemsに移り、そこでOpenJDKで作業しました。 現時点で、私の大部分の仕事は、製品のパフォーマンスの問題を見つけて解決する方法を特定するか、問題が単純な場合は自分の手で修正することです。 これには、仮想マシンのパフォーマンスをテストする標準ベンチマークの最適化、クライアントの問題の解決（アプリケーションの最適化）、数百万ドルのJavaエコシステムに必要なグローバルな改善が含まれます。

JUG.RU：今日、パフォーマンスはJava全体の問題であり、個々のアプリケーションとしてではなく、技術としての問題であると言うのは正しいと思いますか？

Alexei Shipilev：これについて話すのは困難です。パフォーマンスは、多くの場合、作成に使用した言語ではなく、最終アプリケーションのコードによって決定されるためです。 通常、プログラミング言語にはパフォーマンスがなく、この言語の実装にしかなれません。 さらに、多くの異なる実装が可能です。 ただし、Javaの世界では、ほとんどの場合、市場の95％以上を占めるSun / OracleからのJDKの実装について話しています。 心に留めておきます。

最初の1995年から2000年にかけて、Javaは他の若い製品と同様、実際にはあまり効率的に実装されていませんでした。 しかし、過去10年間で、Java実装で多くのことが行われてきたため、以前は典型的であったと考えられていた問題が、開発者をそれほど激しく苦痛にさらすことをやめました。

もちろん、高性能アプリケーションの開発に伴う多くの困難は生き残っています。そのため、私の意見では、この問題が最終的に解決されたとは言えません。 ツイストする必要があるものは他にもたくさんあります。

しかし、すべての人が高性能ソリューションを必要とするわけではないことを覚えておくことが重要です。多くの開発者にとって、パフォーマンスは成功基準のリストに含まれず、「妥当な時間で動作します」。 開発者が生産性の最後の一滴を本当に必要とする場合、かなり複雑な製品に存在する落とし穴を回避する必要があります（そしてHotSpot仮想マシン-および一般的にOpenJDKは非常に複雑な製品です）。

JUG.RU：言い換えれば、パフォーマンスはもはやグローバルなJavaの問題ではありませんか？

アレクセイ・シピレフ：そう思います。

正直なところ、どのプラットフォームでもパフォーマンスの問題は誇張されているように思えます。 先ほど言ったように、ほとんどのアプリケーションはそれほどパフォーマンスを必要としません。 しかし、プログラミングコミュニティには、繰り返すのに非常に便利な永続的な凡例とシンプルなレシピがあります（それらを繰り返すと、イニシエーターのグループに参加しているようです！）。 そして、これらの伝説の1つは、「Javaの速度が低下する」ことです。 個人的に、私はそれが長い間関連していないと確信しています。 彼女にとっては、10〜15年前に客観的な確認がありましたが、状況は変わりました。 もちろん、実行時にパフォーマンスの問題が発生するアプリケーションを作成できるようになりました。 しかし、これらの問題はほとんど知られており、それらの回避策があり、そのような方法に適さない人々は独自の「クランチ」を作成します。

JUG.RU：JDKの開発はどのくらい積極的に行われており、したがって、既知のパフォーマンスの問題を排除していますか（Oracle JDKについて話す場合）？

Alexei Shipilev：非常に活発であり、これには理由があります。Javaエコシステムは、1つの会社から見ても非常に大きいです。 同じOracleエンタープライズスタックはJavaで記述されています。 したがって、プラットフォームで行われた改善はスタック全体に広がり、Oracle開発者にとっても楽になります。 しかし、これがオラクルがOpenJDKを開発している理由です。 この話は、他のベンダーや他のオープンソースプロジェクトのさまざまな品質で繰り返されます。

JUG.RU：パフォーマンスを改善するという点で、Javaの最近の革新はどのような点で最も重要だと思いますか？

Alexei Shipilev：まず第一に、Garbage-First（G1）ガベージコレクターの話がゆっくりと論理的な終わりに近づいていることを気に入っています。 Garbage-Firstはかなり前に発表されましたが、Java 8と9でのみ十分に動作したため、工業規模で使用できます 。Java9ではデフォルトで有効になっています 。 この複数年にわたるプロジェクトは、最初から着想されたものをついに発射し、実行しています。

第二に、 VarHandlesの開発中の一部を置き換えるために、Unsafeを必要とする高性能アプリケーションの話に近づいています。 低レベルのハッキングの助けを借りて、パフォーマンスの最後の低下を絞る正当なケースがあります。 しかし、ご存じのとおり、UnsafeはプライベートAPIであり、実際には標準化されていません。 その使用は、燃えている建物のくすぶっている石炭の上に鋭いはさみで走っています。 また、VarHandlesは、最大のパフォーマンスまたは他の方法では利用できない何らかの種類の機能が必要な、まれであるが重要な場合にパブリックAPIを提供できる方法の1つです。

もう1つの興味深い革新は、 Compact Stringsです。 私は個人的にこのプロジェクトと他の「ストリング」最適化に参加しました。 共通クラスを大幅に改善するこのようなプラットフォームの変更により、Javaで記述されたすべてのアプリケーションのパフォーマンスが大幅に向上し、松葉杖の必要性がさらに減少します。

この場合、合成だけでなく、実際のアプリケーションでも非常に良い結果が得られました。 大規模アプリケーションでのメモリフットプリントとパフォーマンスの10％の向上は、Javaのような健全な成人向けプラットフォームにとって非常に優れた成果です。

JUG.RU：パフォーマンスについて話しているので、それを測定するための「標準的な」方法はありますか？ すべてがお金のためにビジネスになりますか？

Alexei Shipilev：生産性は必ずしもお金に変換されるわけではありません。 実際には、生産性の向上が問題の経済的側面にどのように影響するかを評価することは非常に困難です。 多くの場合、これらは間接的な効果です。プログラマがパフォーマンスの目標に適合するコードの作成に費やす時間です。 ユーザーが結果を待つために費やす時間など しかし、サーバーをクラウドと高密度のデータセンターに配置することで、パフォーマンスが問題の財務面に近づきました。アプリケーションの実行が高速になるほど、リソースの消費量が少なくなり、サーバーのレンタルとメンテナンスの費用が削減されます。 さらに、拡張性の高いアプリケーションにおけるこの依存性は、単純に線形である可能性があります。 私はアプリケーションを50％オーバークロックしました。必要な鉄の量は2倍、インフラストラクチャの費用は2倍少なくなります。

さらに、最適化の時間コストを正当化する必要がある場合、お金の問題が発生します。 商業開発に関与する組織は施し屋ではありません。 彼らはエンジニアに彼らのビジネス上の問題を解決するのを助けるためにお金を払うので、組織は開発の特定の領域に資金を供給する価値があるかどうかを理解しようとしています。 これらの結果をもたらすビジネス上の利益。 したがって、最適化は「ドライバーで掘り下げていただけではありません。ここでの選択に非常に興味があるからです」。 個々の開発者はそう思うかもしれませんが、これらの欲求をビジネス目標とうまく相関させることもありますが、ビジネス自体は最適化のために最適化に関心がありません。

JUG.RU：あなたの意見では、パフォーマンス管理の観点から最も期待されるJDKの革新は何ですか？

Alexey Shipilev：Value Typesは非常に期待される革新であり、現在Java 10のリリースで実装される予定です。これは、プラットフォームの他の部分との適合性の詳細な分析を必要とする非常に複雑なプロジェクトです。 Sacred Cow of Javaは後方互換性があります。 破壊する機能を作成することはできません（より正確には、少しの時間で破壊することはできますが、破壊する理由とユーザーが回避策を持っている理由については非常に正当な理由が必要です）。

値型は非常に単純な問題を解決します。 プログラミング言語としてのJavaの柱の1つは、（ほとんど）すべてがオブジェクトである、記述されていないプロパティです。 これは興味深いレーキです。Javaオブジェクトには個別のプロパティがあるという事実に由来します。 たとえば、ID：何らかのフィールドに番号42が書き込まれたオブジェクトと、「同じ」番号42を含む2番目のオブジェクトを作成した場合、これら2つのオブジェクトは言語の点で異なり、アイデンティティにより異なります。 実装の観点から見ると、これは、これらのほぼ同一のオブジェクトの2つの別々のコピーを保存する必要があることを意味します。たとえば、オブジェクトに関するメタ情報を保存する場所があります。 また、オブジェクトの大きなグラフがアプリケーションに表示されると、各オブジェクトのオーバーヘッドにより、有用なメモリのかなりの部分が消費されます。 これを回避できる言語にアイデンティティのないエンティティがあればいいでしょう。 そして、そのようなエンティティがあります：プリミティブ！ しかし、それらのリストは修正されています。 自然な拡張は、クラスとして記述され、プリミティブとして機能するエンティティの宣言を有効にすることです -これは値型です。

値型は、通常の参照型とは大きく異なります。 たとえば、Objectはすべての値型のスーパータイプですか？ 論理的には、ジェネリック、スペシャライゼーションなどとの相互作用の瞬間が現れます。 この種の特殊化を手動で行うライブラリ（同じGNU Trove）がありますが、誰もが言語自体に実装されることを望んでいます。 したがって、これは非常に期待される機能です。どのボーナスがもたらすかはわかっています。 これで、どの問題が発生するかがわかりました。 ただし、開発中に、実際のボーナスの数と問題の数も確認します。

JUG.RU：パフォーマンスの問題はグローバルよりもプライベートである可能性が高いと考えると、アプリケーションを最適化するための一般的なスキームについて話す方法はありますか？

Alexei Shipilev：特定の症状に基づいて、まず最初にどこを調べるかを規定する非常に具体的な方法論があります。 セルゲイ・ククセンコと私と他の人々 はこの主題について報告しました。

たとえば、非常に優れたガベージコレクターがあると言えますが、ご指摘のとおり、大量のゴミを捨てようとすると、最終的にガベージコレクションにかなりの時間がかかります。 どのランタイムを記述せず、プログラマーが1億個の要素の配列でバブルまたは線形検索を使用してソートを記述した場合、高速ではありません。 ここには魔法はありません-愚かな者は、7人の賢者が答えないようなパズルを作ることができます。

私の経験では、特定のアプリケーションのパフォーマンスで誰も作業したことがない、またはパフォーマンスが不十分だった場合、ほぼ確実に（99％）かなり多くのばかげたまたは明らかな非効率性があり、それらはすぐに検出され、すぐに修正され、時には生産性が向上します。

JUG.RU：ガベージコレクションに加えて、簡単に最適化できる典型的な問題は何ですか？

Alexei Shipilev：私のお気に入りはマルチスレッドの問題です。 正しいマルチスレッドアプリケーションを記述する最も簡単な方法は、同期をsynchronizationしみなく使用することです。 この方法が悪質であると言っているわけではありませんが、ロックが継続しているためにハードウェアリソースが完全に使用されていないという問題がしばしばあります。 これは非常に簡単に診断され、多くの場合簡単に修正されます（ただし、多くの場合、アーキテクチャの修正が必要です）。

アルゴリズムの問​​題は、原則として最高のアルゴリズムの複雑さを持つか、何らかの方法でアプリケーション内のデータに関する特定の知識を使用して、コードの悪い部分を良い部分に書き換えるときに非常に一般的です。最適化の最適化では夢にも思わなかった巨大な利益が得られます。

JDK / JVM固有の問題が発生しますが、まれです。 これには、メモリ内のデータ密度の問題（値型が再び波及する場所）、高度な最適化の問題（エスケープ分析と自動ベクトル化、こんにちは！）、およびコード生成の問題が含まれます。 そして、ここで滑りやすい質問-問題は、ランタイムが悪く、「正しく」動作しないこと、またはこの場合、パフォーマンスを向上させるためにソリューションを何らかの方法で変更したくないことです（たとえば、追加のライブラリを使用します）。 人や組織が異なれば、見方も異なります。

一般に、私の観点から見ると、Javaアプリケーションのパフォーマンスの最適化は、JVMが関与していないネイティブアプリケーションの最適化と根本的な違いはありません。 もちろん、JVMはこの階層の別のレベルですが、そこに存在する問題の多くは開発全般に固有のものであり、特にJavaでの開発ではありません。

JUG.RU：特定の問題が存在する場合、高性能アプリケーションにJavaを使用する意味がありますか？

アレクセイ・シピレフ：私が友達の一人の皮肉な質問に答えて、私が教師の一人であった男子生徒のとき、こんな速いCで書いてみてはどうですか 、と言いました。パスカル（当時人気）は、どこにでも散らかされ、どこにいてもチェックされ、足を撃たせないからです。そして、スピードが私にとって重要な場所では、彼を欺いて、それが速くなるようにします。」 そして、この話は、さまざまなアクターとさまざまな言語で繰り返されます。PascalとC、JavaとC ++、Cとアセンブラなどです。 実際、正常な成長が見込まれる大規模アプリケーションのパフォーマンスは、通常、このアプリケーションのかなり小さな部分のパフォーマンスによって決まります。 したがって、気が散るので、amokを実行せず、低レベルのコードを作成する言語で記述しない方が簡単かもしれません。 高水準言語で書く価値があり、必要に応じてそれを欺きます。ライブラリーとランタイムの曲率を繰り返すイディオムの少ないコードに行くか、重いものをレベルを下げることにより、特定の場所で高速化します。 Javaでの産業開発の実践とそのパフォーマンスの歴史は、主にこのアプローチを具体化しています。

Alexeyの今後のレポートは、 Joker 2016カンファレンスで基調講演形式で開催され、もちろん、プラットフォームのパフォーマンスとコードのパフォーマンスを改善する方法に専念します。

開発者の目から見たJavaパフォーマンス

JUG.RU：あなた自身とあなたの仕事について教えてください。

Oleg Anastasiev：私はOdnoklassnikiのプラットフォームチームで働いています。 プラットフォームチームは、Odnoklassnikiが迅速に機能するプログラムを開発します。 さまざまなデータウェアハウス、サーバー同士の通信フレームワークなどを開発およびサポートします。 さらに、生産の速度で何かが発生した場合、これを処理する方法に関するソリューションを探しているのはプラットフォームチームです。 Odnoklassnikiを高速で動作させるのが私たちの責任です。高速で動作しない場合、動作しないだけで、負荷がかかるとすぐに倒れるからです。

JUG.RU：負荷の高いアプリケーションにJavaを使用するのは理にかなっていると思いますか？ または、単に代替手段はありませんか？

Oleg Anastasiev： Javaは最速の言語ではないかもしれませんが、より速い言語があります。 しかし、大規模なロード済みプロジェクトを開発するための言語としてJavaを検討する場合、原則として、これに代わるものはまだありません。 CまたはC ++でより高速なコードを記述できますが、同時にこのコードはより高価になります-書き込み、デバッグ、およびその後のサポートは、Javaの同様のコードよりもはるかにコストがかかります。 さらに、インターネット上で突出しているCコードには、多くのセキュリティ問題が発生します。 ご存知のように、言語Cでは、あらゆる種類の安全でない構築が可能です。これにより、悪意のある人々があなたをクラックします。 Javaの安全でない構造は少ないため、セキュリティの観点からすると、Javaプログラムの労力は少なくなります。

その結果、Javaの価格/性能比は非常に優れています。

Javaには多くの問題があります。特に、メモリ管理と高トラフィックのサポートに個別に取り組む必要がありましたが、少量のコードで解決できます。このため、個別のone-nioライブラリを作成しました（ https：// githubへのリンク。 com / odnoklassniki / one-nio ）。 コードの残りの部分はすべて、Javaの優れた機能（高速開発、セキュリティ、JVMに組み込まれた適切な問題診断ツール、エラー保護など）を備えています。

JUG.RU：特定のパフォーマンスの問題を解決する必要があると述べました。 それらについて詳しく教えてください。

Oleg Anastasiev：私たちにとって、速度はJavaでのコード実行の速度だけではありません。 リソースの効率的な使用、つまり処理されたデータの量、スループット、メモリ消費の観点から考慮します。 そして、ここJavaでは、プリミティブのコレクション、構造体、オフフックの操作、ネイティブAPIの透過的な使用、アフィニティの管理、ファイルキャッシュなど、多くのことが欠けているため、ボトルネックを回避できるソリューションを開発する必要があります。

私たちにとって、この解釈におけるJavaのパフォーマンスは十分ではありません。さらに、この問題はJavaの次のリリースまで数年待つことができません。問題を今すぐ解決する必要があります。 これについて詳しく見ていきましょう。

たとえば、Javaの問題点の1つは、ブロッキングとノンブロッキング（特にネットワーク）の両方のI / Oパフォーマンスです。

これは、ビデオ配信の例で明らかに見られます。 発信ビデオトラフィックの合計は500ギガビットに達しました。 このようなストリームを配信するには、できるだけ多くのトラフィックが1つのサーバーに届くように、ビデオをできるだけ早く配信する必要があります。 ハードウェアはマシンから40 Gbpsを提供できますが、標準ソリューションを使用したJavaでの書き込みは、40 Gbpsをすべて使用するサーバーでは機能しません。Java自体の内部でパフォーマンスが大幅に低下します。 これは、オープンソースライブラリの一部として解決した問題の1つです。

40 Gbのトラフィックの例は、極端なものです。 負荷の少ないサーバーもありますが、独自の問題もあります。 たとえば、別のJavaの問題点は、多数のオブジェクトをメモリに保存することです。 Javaにはガベージコレクタがあります。 一方で、それはあなたが自動的にゴミを削除することができるので、それは良いです。 しかし一方で、多くの情報をメモリにキャッシュする必要がある場合は、助けるよりも干渉する可能性が高くなります。 さらに、100ギガバイトあたりのデータの配列がメモリに保存されている場合、プログラムを再起動したときに失われないようにしたい-ロードにかなりの時間がかかります。 このような配列を共有メモリに保存したいのですが、これにもJavaには組み込みの手段はありません。 そのような場所では、手動のメモリ管理が必要です。 JavaにUnsafeがあり、それを介して独自の決定を下したことは良いことです。

JUG.RU：JDKはあなたの問題に特有の問題を解決する方向に発展していますか？ 使用できる新しいオプションはありますか？

Oleg Anastasiev：世界でリリースされたJavaの最新バージョンは8です。言及された問題に対する解決策はありません。 Java 9でこれらの問題の一部を解決することのみが意図されており、一部の問題は10以降で解決されます。 ただし、成功または失敗します。 たとえば、Java 9はまだリリースされていないため、提案されたソリューションが現在よりもどれだけ優れているかを述べるのは時期尚早です。 もちろん、ベータ版は既に使用できますが、リリースに到達するまで何が変わるかは不明です。 したがって、Javaが登場します。見てみましょう。

JUG.RU：役立つと思われる技術革新はありますか？ たとえば、VarHandles？

Oleg Anastasiev： VarHandlesが私たちを助けるかどうかは、最終バージョンでどのように実装されるか、そしてどのくらい早く動作するかによって決まります。

VarHandlesは、APIの観点から見ても、Unsafeを通じて簡単かつ明確にできることを行うための、かなり複雑な方法です。 これは、あるタイプのメモリで配列を宣言し、別のタイプのメモリの配列として読み取る機会です。 アセンブリまたはCの原理に精通している人にとっては、状況に応じて、メモリアドレスにアクセスし、LongやByteなどのメモリ位置を読み取るように見えます。 大まかに言うと、VarHandlesを使用すると同じことができますが、より困難になります（これは技術的にはJDKレベルでより複雑なソリューションです）が、定期的に「脚を撃つ」プログラマーからの保護が強化されます。

さらに、VarHandlesは安全でないユースケースの1つのみを解決します。 ただし、完全に異なるシナリオ（たとえば、カスタムシリアル化や共有メモリの操作など）でもUnsafeを使用しますが、Java 10より前ではこれに代わるものは期待されていませんでした。

JUG.RU：あなたの会社は、アプリケーションのパフォーマンスに取り組む必要性について何を決定しますか？

オレグ・アナスタシエフ：スピードのためにスピードを出すことはありません。 最適化の経済効果を常に評価します。

私たちにとって、パフォーマンスはハードウェアに費やす必要がある金額で測定されます。最初にサーバーを購入し、次に毎年データセンターでそれらをサポートするために。 アプリケーションのパフォーマンスが高いほど、同じタスクに必要なハードウェアが少なくなります。 より少ないお金が彼をサポートします。

パフォーマンスの最適化はタスクに基づいています。 この特定のタスクのためにこの量の機器を購入する余裕はありますか？

たとえば、パフォーマンスを0.5％向上させるために、比較的有能なプログラマーの1年間の仕事を費やすことは、データセンター内のすべてのサーバーなど、特定の問題の影響を受けるまで経済的に効果的ではありません。 その後、費用対効果が高くなります。 そうでない場合、新しいサーバーを購入する方が簡単です。 鉄で問題を解決します。

私たちにとって、パフォーマンスはビジネス指標です。 彼女には明確なビジネスケースがあります。 パフォーマンスは、費用対効果が高い限り見られます。

Javaソリューションのパフォーマンスに関するすべての疑問にもかかわらず、これらの問題に対する継続的な作業が進行中であることを喜ばしく思います。Java自体は、すべての攻撃にもかかわらず、大規模で負荷の高い企業プロジェクトの業界標準になりました。

---

Joker 2016プログラムには 、技術的で筋金入りのより興味深いレポートがあります。 いくつかの例をご紹介します。

• Volker Simonis 、SAP： HotSpot Internals：Safepoints、NullPointers、およびStackOverflows 。
• ISI SB RASのTagir Valeev： Stream API：最高の犬のブリーダーの推奨事項 。
• Jean-Philippe BEMPEL、Ullink： Low Latency＆Mechanical Sympathy：issues and solutions 。
• ウラジミール・イワノフ、Oracle： ネイティブコード、オフヒープデータ、Java 。