最近、同僚が「会議に行く理由」と「YouTubeでビデオを見る理由」について既によく知っている質問をしました。これは友人であり、arbitrary意的な人物ではないため、より詳細に、詳細に、そしてニンニクについて答えたいと思いました。残念ながら、ライブモードでのライブモードでは、これを行うのは困難です。すべての詳細については言及しません。一方、これはハブポストに最適なトピックです。詳細なレビューを1回書いてから、真の社会恐怖症者として、Habrへのリンクですべての質問に答えることができます。

アイデアは簡単です。JPoint2017から最も人気のあるレポートを入手し、それが何であるか、なぜそれがクールで、なぜ私がそれを個人的に必要とするのかを簡単に言い直してください。これらの各レポートは個別の分析に値しますが、最初はトップ10の簡単な概要です。行こう！

興味深いことに、この会議で2つの基調講演がトップになりました。基調講演は、定義により、会議の精神とトーンを設定します;彼らは「インスピレーション」と「自分の視野を広げる」ために設計されています。狭い技術会議で基調講演を行うには、これを行う必要があります。ただし、それらはすべてここにあります。プログラム委員会はこれを簡単な方法で達成しました。最初の基調講演は伝統的に人気のある科学ポップであり、2番目はシピレフ（講演者-再犯者、最高のレポートの連続メーカー）です。

レポートを見たときの気持ちを比較するために、それぞれの隣に会議参加者の平均評価が表示されます。

10. 集団的（なし）責任の問題

スピーカー：Alexey Savvateev; 評価：4.38±0.04。

科学、特に数学とゲーム理論の普及者からの鮮明なレポート。このレポートは、私たち自身の研究と、オリバー・ハートとベンクト・ホルムストロームの研究（2016年ノーベル経済学賞、契約理論に与えられたもの）に基づいています。

まず、ゲームの理論と契約に関する基本的なことを忘れた（または知らなかった）人のために、いくつかの入門情報が提供されます。これにより、基調講演と「ハードコア」とが区別されます。著者は「大学で大学に合格しなかった人は誰でも立ち上がってホールを去った」とは言いませんでした。代わりに、彼は例でトピックを簡潔かつわかりやすく説明しているので、誰にでも明らかになります。たとえば、契約の理論は次のように使用できます：何らかの種類の通常のコーディングオフィスがある場合、すべての関係者（労働者、雇用主など）のモデルが構築され、将来、雇用主は直接注文を使用してこのシステムを管理できなくなります。そして、細かく選択された刺激を使用します。

アレクセイは、そのような契約の多くの例を挙げています。たとえば、誤って選択したルールを使用して、誤って車の交通をブロックする方法について説明しています。要するに、一般的なタスクはプロセスを正しく整理する方法です。

一連の例を使用して、ターンスタイル問題の例を使用してナッシュ均衡を説明します。ナッシュは、映画「マインドゲームズ」の主人公だった同志であり、1994年にノーベル経済学賞、2015年に数学のアーベル賞を受賞しました。ゲームの均衡の存在に関する非常に一般的な定理を証明しました。お金やその価値に対する信頼、大学での教育の質に対する相対的な信頼などの実際の例が示されています。

レポートの途中でAlexeyが聴衆と一緒にブレインストーミングを企画したことは非常にクールです。そして、聴衆の中に会話をサポートできる人々が本当にいました。通常、このような試みは哀れに見えますが、この場合、それらはレポートの一部であるように思われました。残念ながら、これをレコードで感じることはできませんが、これは私がライブで出席した数少ないレポートの1つです。たとえば、この形式では、ターンスタイルの問題の2番目の部分について説明しました。

そして最後に、これに基づいて、レポートの中心的なトピックに進みます。高レベルの腐敗を伴う脱税の問題を解決するためにスピーカーに求められた方法です。モデルが構築され、問題が形式化され、その問題はゲーム理論の枠組みの中で解決されます。その間に、非常に興味深い結果と観測がいくつか見つかります。

一般的に言えば、これは重要な記事であるはずでしたが、ゲーム理論の私の知識が彼の戦場で本物の科学者を批判するのに十分ではないことは明らかです。彼は正しいモデルを選択しましたか？計算は正しいですか？はい、地獄は知っています。まず第一に、著者の考え方に夢中になりました。これは、レポートのビデオ録画とライブコミュニケーションの両方で追跡できます。この考え方は手書きのようなものです。

いずれにせよ、すべてのプログラマーがプログラミング言語でモデリングの問題を解決しますが、Alexeiの場合、非常に高度な数学的抽象化によって引き出される非常に複雑な実際の問題について話しているため、非常に直感に反する結論を構築し、実際にテストすることができます。私にとって、このレポートの基調講演の価値はまさにこの中にあります。異なる目で単純なものの「マトリックス」を見始めたとき、突然の啓発と洞察の瞬間に。

9. パフォーマンス：私の名前は何ですか？

スピーカー：Alexei Shipilev（Red Hat）; 評価：4.38±0.03。

別の基調講演、今回はパフォーマンスについて。まず、Leshaは開発を成功させるための基準について説明します。もちろん、ビジネスの主な基準は略奪であり、プログラマーは大量の生地を稼いでいると言って、有能に聴衆にこだわります！

観客はお世辞から回復していませんが、砲撃は警備員とのコミュニケーションなど、もっと悲しい技術的なことから始まります。プロジェクトの成功に最も影響を与えるパフォーマンスは、最も重要なことではないと結論付けられます。パフォーマンスに従事している男からこれを聞くのは面白いです-通常、すべてのシギは彼の沼を賞賛します。

次に、正しいプログラムと高速プログラムが比較され、名前がcurveの曲線のスライドが表示されます。私見、このスライドは、すべての一般的な画像で自分自身を見つけることができる最も啓発的な瞬間の一つです。レポートのスライドを1つだけ表示したい場合は、ここにあります。

Leshaは、ダイアグラムのすべてのレベルを注意深く見ていきます。個人的には、これらの考慮事項は非常に明確な用途を持っています。たとえば、これは、パフォーマンス戦略を定義し、「正常なプロファイルを作成するか、まったくプロファイルを作成する必要がない」（グリーンゾーンにいる場合）などの有害な発言に対処するための十分に形式化された引数のリストです。鞭はまた、すべての紛争の主な議論として「時期尚早な最適化」で議論されています。そして、上司へのパフォーマンスを向上させるために作品を販売する方法。そして、新しい超高速データベースなど、ユーザーが何らかのゲームを販売するようになったときにどうするか。

いくつかのスライドを台無しにします。

そのようなスライドは想像を絶する量があり、それは特徴的です-それらはすべて厳密にケースにあります。これは、一般に、これによって生計を立てている男に期待されることでした。これはある種の極秘の知識であるとは言いませんが、私にとっての価値は最も明確でなめらかな言葉遣いと情報の整理にあります。

もちろん、例は困難です。コンパイル速度が2分から8分に低下したjavacのコードの一部、 Amdalの法則とUniversal Scalability Lawによる証明など。レシャは他の例をどこで手に入れますか？

一部のパフォーマンスの専門家は現在、スピーカーに対するandみを抱いているのではないかという疑念があります。あるレポートでは、彼はすべての主要な秘密と協議のトピックを通過したからです。

8. コトリンの未来：戦略と戦術

スピーカー：Andrey Breslav（JetBrains）; 評価：4.41±0.08。

コトリンについて何も聞いたことがないのは誰ですか？まあ、間違いなく私たちではありません。すべてのニュースはコトリンでいっぱいで、インターネットは活気づいています。そして、このプロジェクトの責任者であるAndrei Breslavが光の中で私たちにやって来ます。アンドレイは、言語とプラットフォームの将来について具体的に語っていますので、彼は間違っているかもしれませんが、このレポートはそれをそれほど価値のあるものにしています。

まず、Andreiが製品に代わって実際に話すことができるのは興味深いことです。彼は市場ですぐに話をすることができます：KotlinはScalaでビッグデータのために戦うかどうか、Pythonでデータサイエンスのために戦うかどうか。最初のスライドで、「私たちの信条：JVM、JS、およびネイティブプラットフォーム向けの産業用プラグマティック言語（相互運用、ツール、安全性）」-と言うことです。このスライドでは、JVM以外のプラットフォームのサポートが真の優先事項であるかどうかのトピックに関するチャットルームでのディスカッションを終了できます。

すぐに、Andreiは、どのプログラムもどのプラットフォームでも実行できるようにしようとしているのではないと説明します。「一度書いて、どこでも実行」はJava用であり、Kotlinitesはこれを行いません。これは貴重なモザイク作品でもあり、すでにKotlin指向のアーキテクチャを設計している人にとっては貴重です。私見、アーキテクトにとって、このレポートは、あなたが連絡した人とあなたが購読しようとしているものを海岸から理解し始めることができるという点で非常に貴重です。

同じ部屋で、次のような不快な質問をすることができます：Objective-Cサポートがいつ入るか、Kotlin Nativeのソケットのような便利なライブラリなど。質問は不便ですが、Andreiはどういうわけか出てきました:-)ネイティブに関して多くの質問がありました。レポートは組み込みでのKotlinの使用について真剣に議論しました。 ArduinoでのKotlinについての質問と、ゼロコストの抽象化と、サーバーとしてArduinoについて書く場合、実際にはうんざりするという議論がありました。

一般的に、レポートは非常に具体的でした。計画、野望、戦略について。

明らかに、すでに自分の未来をコトリンと結びつけている人にとって、それは非常に重要です。他の皆のために...さて、レポートの特に「売れている」部分はありませんでした-「私を食べて」、「私を飲んで」、「私を買って」、それは本当に私を買収しました。男は非常に太くなっているので、隅々までパンフレットを売ったり振ったりする必要すらありません。一方、最初に地獄のコトリンがあなたのために何であるかを理解したい場合-これは大したことではなく、いくつかの間接的な兆候によって決定する必要があります。

私にとって、このレポートの主な利点は、明示的に表現されていないが、追跡可能であるというアイデアにありました。未来のコトリンは、現在のコトリンではありません。今、何かがささいなことについて私を悩ますなら、それはおそらく将来修正されるでしょう。特に、人々はメタプログラミングのようなことを真剣に考えています。これは、私にとって、Golangの幅広いタスクのブロッカーになりました。コンパイラへのプラグインがIDEのプラグインに自動的になり、Golangコードジェネレーターを導入するときに再び苦痛になり、解決する必要があるというのは非常に価値のある考えです。要するに、Kotlinは素晴らしい未来を伴う戦略的決定とみなすことができます。

7. Javaバイトコード検証：いつ、どのように、そして無効にできますか？

スピーカー：Nikita Lipsky（Excelsior）; 評価：4.42±0.07。

プロットは、NikitaがJVMの構造について簡単な学生レポートを作成したようなものです。

学生だけでなく、成熟した経験豊富な開発者も、基本的な知識にギャップがあり、バイトコード検証がどのように機能するかを理解していないことがよくありました。

GCのようなものは仕様では必要ではなく、原則としてガベージコレクションをオフにすることができます（Epsilon GCを使用するなど）。対照的に、バイトコードはJVMSでハードコーディングされており、VMは同じバイトコードに同じ結果を返す必要があります（正しいかどうかに関係なく）。その結果、検証者は一度書かれた後、それを忘れます。（当面は、Value Typeが検証者の変更を必要とすることを私たちは皆知っています。）したがって、検証者を書いたことのある人は世界中に何十人もいます。Nikitaもその一人です。

このスライドのレポート全体は次のとおりです。

「なぜ会議に出席するのか」と「メモを見るのはなぜか」という質問に対して、インターネットでこれらの問題についてテキスト形式で首尾一貫した声明を出すことは困難です。

面白い写真-内部からクラスファイルを閲覧した人の数。ほぼホール全体。うーん、なぜ彼らはこれが必要なのですか？ :-)正直に言うと、JVMの基本を掘り下げてWebアプリをコーディングする前に、そのような詳細を学び始めることすら考えていませんでした（実際はそうではありません）。

最初に、Nikitaは、クラスファイルの構造、バイトコード、および命令の種類などについて詳しく説明します。

「億万長者になりたい」というゲームがありますが、 ~~ギルテネのように~~ 、およびさまざまな興味深い例。

次に、Nikitaとともに、JVMの5番目の章からJVMにクラスをロードする段階（ロード、リンク、初期化）を実行します。検証は、リンクフェーズの最初の段階です。その後、検証の詳細に進みます。静的制約と構造的制約のチェックです。静的チェックは2つのパスで行われます。出力はメソッドバイトコードの制御フローグラフです。構造制約は、たとえば、各命令のスタックの深さが実行パスに対して特定の値でなければならないなど、より複雑なことをチェックします。

検証者の魔法は静的ストリーム解析で機能します。これは研究所でプログラミング理論またはプログラム回路理論によって説明されることがあります。ニキータがこの部分を公開するのはどういうわけか複雑すぎることはすぐに明らかになりました-そして、彼はストリーム分析に関する講義を行っていることがわかります。どういうわけか、この場所での会議のプログラム委員会を通して、材料などの半格子について材料が漏れました。

ただし、このすべての要素は、スタックマップフレームや特定のバイトコードなど、ジャビスタに馴染みのあるものに簡単に当てはまります。これについては、たくさんの良いイラストがあります。さらに、検証タスクのリアルタイム、およびJava 5で実行された処理を計算することもできます。その後、多くの異なる純粋に実用的な事項について説明します。

個人的には、このレポートは、バイトコード検証（ java -jar -Xverify:none MyApp ）を無効にする推奨事項が純粋な狂気であり、検証者に対する批判を扱うべきである理由について（理論と実践の両方の観点から）確固たる正当化を与えました懐疑論の大部分。さらに、 ASMなどのライブラリを使用する場合に非常に役立ちます（レポートの途中でASMの使用に関する推奨事項を示します）。

6. 春の呪いテスト

スピーカー：キリル・トルカチョフ（アルファ研究所）およびエフゲニー・ボリソフ（ナヤ・テクノロジーズ）。評価：4.45±0.05。

これは純粋に実用的なレポートであり、マイクロサービスの一部をテストし、レポートで説明されているさまざまな原則を適用する方法を示します。

これは、RESTとキューを備えた標準アーキテクチャを使用したSpringで作成されたチャットのライブデモなど、Web開発者の心に近いものが豊富にあるという点で、JVMデバイスに関する以前のレポートとは大きく異なります。トピックの問題は、素早いアプローチを使用するとすぐにロックアップできるものとバラバラになるもののトピックで検討されます。

簡単なトローリングの行為として、スピーカーは任意のWebサービスではなく、Baruch Sadogursky（ @jbaruch ）とYegor Bugaenko（ @ yegor256 ）の頭脳をテストしています。タスクの条件に応じて、Baruchの回答はキャッシュされ、Yegorは時間の経過とともに気が変わる可能性があり、回答する前に考えます（キューを使用してデータを受信します）。

このレポートについて書くことはあまり意味がありません-あなたはただそれを見なければなりません。講演者たちは、Springでのテストの基本を、生き生きと興味深い形で示しています-いくつかの乾燥した事実だけでなく、ゼロから実用的なアプリケーションまでの開発。最初は多くのことが意図的に誤って行われ、その後、進化的な方法で理想にまで達していくのは興味深いことです。

次回SpringとSpring Bootでプロジェクトを行う必要があるときに、このレポートを必ず確認します。テストの分離を維持するために@SpringBootTest必要な理由（コンテキスト全体のテスト、プロパティの変更、特定の配列でのテストの作成-パッケージ/構成/自動スキャン）が@TestConfigurationになり@SpringBootConfiguration - @SpringBootTestシグナリングにのみ@SpringBootConfiguration必要です彼は止めなければなりません。一般に、Springを使用したテストは迅速に実行できることが明らかになりましたが、キャッシュは簡単に破損するため、 @TestConfigurationは@TestConfigurationのみを使用する必要があり@TestConfiguration 。

私は繰り返しますが、このレポートでは、開発プロセス自体とその進化の理解が、特定の結論の最終リストよりも重要です。もちろん、自分で同じ結論に達することができますが、膨大な時間を無駄に失います。

5. 春-深くない

スピーカー：Evgeny Borisov（Naya Technologies）; 評価：4.46±0.05。

Zhenya Borisovによる別のレポート。これは、トップの「Curse of Spring Test」にすでに存在するものを完全に補完します。

レポートの結論は、最初のスライドで突然与えられているので、それらを見ていきましょう。

春は完璧ではありませんが、それ以上のものはありません。そして、彼はまだ十分ですので、私たちは彼を愛しています。
Springでは、プラットフォームを構築できます。
それを修理することを恐れてはいけませんが、それ自体を修理することを忘れないでください。
更新に関する仕様をお読みください。

ユージーンは、有名なスライドからレポートを開始します。

これは、なぜ開発者とライブでチャットし、会議に行き、最新の記録を見る必要があるのかという問題です。私は自分自身の辛い面でジェンヤのこの観察を感じました：春についての声明の重要な部分は嘘であるか、絶望的に時代遅れです。

たとえば、自己注入のアイデア。トランザクション性を使用する場合、独自のメソッドを呼び出すBeanはthis使用するのではなく、自身へのプロキシを使用する必要があります。これを行うには、自分自身（または自分自身ではなく、自分のプロキシ）を注入する必要があります。この状況はどこから来たのか-Zhenyaは詳細に説明します。これはSpring 4.3までは機能しませんでしたが、 @Resourceアノテーションを使用できましたが、時には機能し、XMLでも常に機能していました。 Spring 4.3以降、 @Autowiredと@Injectは機能し始めましたが、標準のJava構成は機能しません（Javaのセマンティクスではこのような厄介なことは許可されません）。そして、これにはすべて、Springトラッカーでのバグの作成から4年半かかりました。

次の例は、破壊されたPropertySourcesPlaceholderConfigurerです。このこと（正確には、そのカスタム実装）がどれだけ私から血を飲んだのか。 Eugeneは、バージョン4.2ではjavakonfigでstaticとして指定する必要があり（そうでない場合はすべてエラーが発生する）、最近のバージョンでは@PropertySourceのみを指定できるか、Spring Bootの場合はまったく指定できないと@PropertySourceます。これらの間には数年もあります。

ちなみに、例はナパームによって利用されています。たとえば、ビン間の循環依存関係は、妻を自分に注入する夫の例によって示されています。

これらの例から、ロジックを@PostConstructでビジネスロジックの開始をブロックするのは悪いという考えに@PostConstructました。正直なところ、このようなアイデアは私の頭をよぎることさえありませんでした（まあ、それは私が牛のコーダーだからです）。結局のところ、これらすべての問題は慎重に選択された松葉杖によって解決されます。 @Mainは、そのような松葉杖を正しく書く方法を教えます-自作の@Mainアノテーションは、それを明確にします。

大まかに言って、eventListenerが作成されます（メソッドの上の新しいコンポーネントは@EventListenerアノテーションであり、パラメーターでは、どのイベントをキャッチするか）。 ContextRefreshedEventが必要ContextRefreshedEvent 。次に、BeanDefinitionsを調べ、 @Main見つけてプルする必要があります。しかし、同時に、これらすべてをSpring Bootで動作させるには、特定の操作を実行する必要があります。ここでは、興味のある人すべてについては説明しません。レポートをご覧ください。さらに、Springに没頭していない人にとっては、80文字を超える名前を持つメソッドのこの魔法は、ある種のゲームのように思えます。ただし、このレポートでは、Mavenに依存関係を追加するだけでこのゲームをすべて自動的に接続する方法を示しているため、毎回この地獄に行く必要はありません。

そして、より多くの興味深い、そして時には完全に禁止さBeanFactoryPostProcessorていることは、 BeanFactoryPostProcessorとSpringバージョンのBeanFactoryPostProcessorます。私は、Zhenyaについて十分に聞いて、これをすべて間違って適用した人々がいると確信しています。

一般に、このレポートにより、Spring、Spring Bootの仕組み、そして最も重要なこととして、javadocを読むだけでは理解できないイデオロギーのニュアンスをよりよく理解できます。ここでは、経験豊富なSpring Jediの介入とアドバイスが必要です。これはZhenyaです。このレポート（およびZhenyaのその他のレポート）は、標準機能が失われ始めているため、すぐに確認する必要があり、 BeanPostProcessorおよびBeanFactoryPostProcessorさらにBeanPostProcessorたいと考えています。

4. 1人のHTTP / 2クライアントエンジニアがオーバークロックした方法の物語

スピーカー：Sergey Kuksenko（Oracle）; 評価：4.47±0.06。

おそらく誰もが既に知っているように、HTTP / 2別名RFC 7540は、古いチューブHTTP / 1.1を置き換えるためにGoogleの紳士または他の誰かによって発明されたプロトコルです。

後続の物語の主な役割は、/ 1.1から/ 2のいくつかの違いによって果たされます。

バイナリ形式（フレームを使用）
単一のTCP接続で複数の要求を多重化する
- <Request> => <Stream> => <Frame> ... <Frame>
ヘッダー圧縮（HPACK別名RFC 7541 ）

基本的に、HTTP / 2は、以前の標準の特定の問題を解決する非常に低いバッキングです。

一方、OpenJDKには、JDK 110の一部としてリリースされたが、まだJava SEの一部になっていない「HTTPクライアント」であるJEP 110があります。彼は監視され、議論されるのに十分なほど釈放された。あなたが期待するようなものに見えます：URLを持つコンストラクター、同期および非同期APIなど。クライアントはユニバーサルであり、HTTP / 1.1とc / 2の両方で動作します。

スピーカーとは、このクライアントでパフォーマンスの仕事に携わった人のことで、後で彼について話します。目標は、合理的な時間内に適度に速いクライアントを獲得することです。

最初に、彼はそれをベンチマークしました。おそらく、クライアントにもあまり変更がないことを期待して。競合他社として、Jettyクライアントが比較に使用されました。

どういうわけかそれは悲しいことに判明しました。この場合、誰かがそれを覚えている場合、 TCP_NODELAY既知の問題がありました。人々は時々、特によく知られている横棒を単に忘れます。それにもかかわらず、セルゲイはこれらのすべてが何らかの秘密の知識ではなく、典型的な学校は非常に簡単にグーグルであり、初心者によって勉強されると主張しています。

これが実際のパフォーマンススペシャリストの頭の中でどのように機能するのだろうか。一部のアマチュアではなく、本当のアマチュアです。彼は最後の瞬間までプロトコルの仕様を読みませんでした。彼はプロファイルを作成し、パフォーマンステストを作成し、プロファイラーインターフェースを調べましたが、多くのリソースを消費するファット関数が存在することが判明した最後の瞬間にのみ仕様を読み上げましたが、その名前からはそれらが何をしているのか明確ではありません。つまり、反射は「常に仕様を最初に読む」ものであり、おそらく最も正しいものではありません。

一方、仕様を読んでいるので、それらを注意深く読んで、それに組み込まれたハックを使用してください。必要なハックを使用した後、クライアントはJettyを追い越し始めました-これが生命を与える仕様の強みです。

レポートでは、これらすべてが、HTTPクライアントを作成するサブジェクト領域からの実際のデータで示されています。たとえば、前の仕様例は、HTTP / 2でウィンドウを展開する手順によって示されました。おそらく、聴衆の一部にとって、この質問はそれ自体に関連があり、そこにあるすくいのあるすべての例は本当に有用です。私にとって、正直なところ、あまり良くありませんでした。Webバイコーディングの日々の実践では、通常、このようなライブラリを一度だけ、スーパープロフェッショナルによって書かれたものを使用します。

さらに、面白いライフハックのセットがあります。パフォーマンスアーティストがミッションコントロールに1日中座って、それに基づいてある種の黒魔術を行うという神話があります。 Sergeyの実践では、ほとんどの場合、ログをファイルに記録し、次のような即興の方法でそれらを確認します。

その直後、ネットワークライブラリで、クイックキューのグローバルロックの下に太字のコードをリファクタリングする方法が明確に示されています。ロックは悪であり、単純なリファクタリングで多くを絞り出すことができます。

並行して、神話は、GCからプールへの移行が自動的に良い結果をもたらすことを暴いています。実際には、プールから何も得られない状況に陥ることはありますが、プールなしで作業するすべての不利な点があります。

まだたくさんの興味深いことがありますが、ハブラポストをスクリーンショットの巨大なコレクションに変えることはできません（必要な場合でも）。

一般的に、このレポートは、ネットワークで作業しているパフォーマンスエンジニアのよく伝わる考え方の感覚を残します。また、おまけとして、HTTPクライアントを開発する典型的なレーキを順を追って説明します。

3. BPF Magicを使用したJVMアプリケーションの高速かつ安全な生産監視

スピーカー：Sasha Goldshtein（Sela Group）; 評価：4.49±0.07。

そこで、最初の3つに進みます。このレポートは特に理解しにくいものでした。実際、この記事を書くために、すべての記録を倍速でレビューしました。サーシャ自身は普通の人よりも速く話し、さらにレポート全体は英語です。この組み合わせは本当に脳を取り去るので、初めてそれを聞いているなら、標準速度をオンにする必要があります。

要するに、C ++またはPythonでアプリケーションを監視するために通常使用され、Sashaが犬を食べたソフトウェアは、JVMアプリケーションを監視するためにも非常に使用できるということです。もちろん、これはすべてLinux上で行われます。

レポートのグローバルな目的は次のとおりです。

この点で、BPFという言葉はすぐに明らかになりますが、多くの人は疑っていません。原則として、インターネット上で同様のトピックに関する他のレポートを見つけることができますが、Javaに関するものはありません。

このすばらしいレポート全体を台無しにすることはしませんが、小さな種の話から始めましょう。

レポートは、他の監視ツールの開発状況を考慮に入れた議論から始まります（すべてのツールは、新しい、安定した、および機能停止に分類されます）。たとえば、 ftrace 、 perf 、 SystemTapなどの安定したもの（本番モジュールを含むカーネルモジュールのコンパイルと動的なロードが必要です）。新しいものがあります： SysDig （非常にシンプルですが、機能はほとんどありません）、異なる言語のバインダーを使用したBPF 。 dtrace for Linux 、 ktap 、 LTTngなどのdtrace for Linuxなど、他にも多くのdtrace for Linuxがあります。

さらに、JVMについて学習できることを確認します。 JVMには、オンにして外部ソフトウェアを使用して接続できる特別なトレーディングポイントがあることがわかります。

さらに、Sashaはtplist tplist 。これはtplist -p `pidof java`としてtplist -p `pidof java`ことができますtplist -p `pidof java` これはすべてフラットリストに表示されるため、目で読む必要はありません。

興味深いことに、これらのすべてのポイントにはパラメーターがあるため、 monitor__waitedをモニターすると、4つのフィールド（符号付き、符号なし、符号なし、符号付き）の構造が見つかります。残念ながら、値の種類に加えて、パラメーターについては何も知りません。ただし、最も便利な形式ではありませんが、 .stpファイルで情報を開くことはできます。少なくとも、そこから引数名を引き出すことができます。

さらに、 BPFに進むために、Sashaはprodでデバッグする必要があるアプリケーションの例を提供します。異端がどのコードをコンソールに出力するかを理解するために、デバッガーへの接続が許可されていない場合。タスクはひどいです、通常の管理者は恐怖で彼女から逃げます。 -XX:PreserveFramePointer （3％のオーバーヘッドを与える）に接続する必要があり、その後BCCのtraceユーティリティBCCます。

 trace `SyS_write (arg1==1)` "%s", arg2' -U -p `pidof java`

トレースは必ずルートの下で実行されます。次に、トレース（この場合SyS_write書き込み用siskol）、条件（ (arg1==1) ）、出力用メッセージ（ "%s", arg2 ）、-U-ユーザースペース呼び出しスタック、、そしてもちろんPIDでフィルターします。どういうわけか次のようになります。

次に、以前に作成したスクリプト（ perf-map-agent create-java-perf-map ）を使用して、メソッドアドレスをJavaの実際のメソッド名に変換します。

その後、私たちのチームの疲れを掘り下げる必要があります。必要な行を表示する特定の場所を取得しました。

あなたはあなたの製品にそのような焦点を絞ることができます：そのようなチューニングに慣れていない平均的な人はそれを魔法と見なし、何でも信じることができます。次回は、彼の考えを読んで死者をよみがえらせることができることを管理者に伝えることができます。

このレポートには、 BCCユーティリティなど、高度なチューニングを使用することで実際に説明されている素晴らしいものが満載されています。

JavaアプリケーションはSystem.gc（）でガベージを頻繁に収集しますが、その理由を知りたいですか？はい、 -XX:PreserveFramePointerを除き、 -XX:PreserveFramePointer -XX:+ExtendedDTraceProbes有効にする-XX:PreserveFramePointerあります。これは非常に高価なオプションであり、一定に保つことはできません。管理者に頻繁にオンとオフを切り替えるよう依頼する場合、彼はあなたが本当のネクロマンサーではないことを推測できます（実際、あなたはもっと悪いです-あなたは今、彼の脳を作るヤビストです）。さて、その後、サーシャが語る地獄の儀式を実行してください： method__entry自分自身をmethod__entry必要があります。

さらに、サーシャは、なぜperf悪いのか（ネタバレ：ユーザー空間で分析するためにデータを大量にプッシュする）およびあらゆる種類のものについて説明します。

GNU / LinuxプラットフォームでのJavaアプリケーションのパフォーマンスに関与しているすべての人に、このレポートを聞いて結論を出すことを強くお勧めします。これは絶対必要です。

2. Hibernateを再び高速にする

スピーカー：ニコライアリメンコフ（EPAM）; 評価：4.51±0.04。

Hibernateが2位のレポートのトップで見なければならないことは、ショックではないにしても、驚きであることが判明しました。 Hibernateはそのようなもので、 2001年にリリースされました。ここ数年、彼についてできることはすべて語られていませんか？これを聞く人はまだいますか？

泊まった。しかし、これが本当に良い報告であり、ニコライ・アリメンコフがHibernateの多様性を理解しているまさにその人である場合にのみ。 5年の間に、彼は「Why I hate Hibernate」や「Barefoot on the Hibernate rake」などの神聖なタイトルでレポートを提供してきました。リストは長く、一部はYouTubeで見ることができます。

タイトルで表明された問題は本当に私に近いと言いたいです。人々はHibernateを誤って使用し、頭を使って考えることを拒否し、スマートな本を読まないで、「Hibernateは遅い」と叫びます。一方では、それはそのような不快な感覚、哀れみと軽snのbetween辱の交差を引き起こします。一方、システムに、ほとんどのユーザーがほぼ17年間使いこなすことができないようなAPIがある場合、そのようなAPIには明らかに問題があります。

最初のスライドのニコライは、これが彼の個人的な経験にすぎないというトピックに関する免責事項を作成します。しかし、この場合、私たちの経験はまったく同じです。

レポートは、Hibernateとは何か、それが解決する問題についての小さな必須の紹介から始まります-すべてのデータベースのユニバーサルOOPアダプターは、Hibernateが魔法のように動作しないことを示しますが、内部では同じJDBC、コンテナー内のJTAなどを使用します。さらに。抽象化レベルのチェーン全体を見て、その一部と移行がパフォーマンスに影響を与える可能性があることを理解し、それらを改善するためにそれらを測定できる必要があります。

測定には、Hibernate自体のログ（ hibernate.generate_statistics=true 、 DEBUGレベルのロガーorg.hibernate.statなど）を使用するか、 JMHでマイクロベンチマークを書き込むことをお勧めします。

データベースに送信されるクエリを確認するには、あらゆる種類のデータソースプロキシ（p6spy、datasource-proxiesなど）を使用し、生データを監視することをお勧めします。何らかの種類のカウントインターセプターを配置して、データベースに送信された物理リクエストの数を計算できます。そしてもちろん、Hibernate自体でクエリロギングを有効にすることができます。

さらに、Nikolayは、比較的小さなリクエストであっても、Hibernateログでどれだけ興味深い情報を読み取れるかを示しています。ログは悲鳴を上げ、すべてがあなたにとって間違っていることを叫び、あなたは緊急にそれをやり直す必要があります。（確かに、通常、雷が鳴るまで誰もそれを読み取りません。）ログを含めることは、ログの統計を読み取る方法、どこで、どの時間を費やしたかを示します。

このレポートでは、調整できる主要な事項について説明しています。 , JDBC, connection pool — , . , JDBC Session.doWork(), .

, , . , N+1. - , «, N+1 — , », … , . . — : , , , NamedEntityGraph ( Hibnerate, JPA, ).