この号では
- マイクロプロファイル ： Java EEを蘇生させる別の試み
-BrexitはJava開発者を傷つけますか？
-Java Memory Modelの棚のレイアウト
-プロファイリング： AsyncGetCallTraceの弱点
...など
1.ニュース
1.1。 マイクロプロファイル
リンク1： http : //microprofile.io/リンク2： https : //developer.ibm.com/wasdev/blog/2016/06/27/microprofile-announce/
リンク3： http : //middlewareblog.redhat.com/2016/06/27/microprofile-collaborating-to-bring-microservices-to-enterprise-java/
リンク4： http : //www.tomitribe.com/blog/2016/06/microprofile/
Java EEは、マイクロサービスの誇大広告にdrれ続けています。 IBM 、 RedHat 、および他のいくつかの企業の人たちは、イニシアチブMicroProfile.ioを発表することで彼女に命を吹き込むことにしました。 目標は、Java EE標準を現在の傾向に合わせることです。 読み取り-マイクロサービスでJava EEをプルします。 そして、文字通りの意味で。 たとえば、dzharnikの最大サイズとアプリケーションの開始時間をほぼ標準化することが提案されています。 「あなたの...を拡大」のようなもの、ちょうど反対。
イニシアチブに対する反応はさまざまです。 誰かが冷笑する：
誰かが明らかにアイデアを失うことに時間を無駄にしないことを提案します：
私の意見では、このイニシアチブは確かに良いものです。 しかし、Java EEのこれまでの歴史はすべて「標準の標準」に関するものでした。 MicroPofile.ioは過去の間違いを考慮に入れて、「人々の標準」モデルに切り替えることができるでしょうか、と時間は告げます。
一方、Java EEのフリーズを取り巻く状況は引き続き熱くなっています。 そのため、次の焼cen黙示録の記事が出てきましたが、その本質は一言で言えば「Oracleの野郎、すべてが失われている」ということです。 ジェームズゴスリング自身がこの出版物について明示的にコメントしました 。
私はこれがでたらめだと言うことができるようにしたいが、それは悲劇的に反対です。 Oracleは、これまで出会った中で最高のIQバカによって運営されています。 彼らは、オラクル、それは顧客であり、彼らがこれまでに買収したすべての会社です。 一つの光線は、コアJavaグループがEEよりもはるかに優れていることです。
引き続き開発状況を監視しています。
1.2。 ブレグジット
リンク： http : //www.ibtimes.co.uk/brexit-will-london-lose-its-fintech-crown-1567222イギリスはEUを去ります。 ポンドはピークに達しており、英国の最大の銀行の相場をそれ自体で引き継いでいます。 国際金融会社のロンドン事務所での削減の開始についてのスローが継続的に表示されます。 これはロシアのJava開発者に何らかの形で影響しますか？
特定の影響があります。 秋にレイアウトを開始するJava開発市場調査のネタバレです。サンクトペテルブルクだけでも、約12のフィンテック企業が営業しており、約100のさまざまな規模のアウトソーシング業者がいます。 これらの企業の有形のシェアは、英国を含む西側諸国と関係があります。 不確実性が高い状況では、一部のプロジェクトは必然的に凍結され、削減され、キャンセルされます。 したがって、地元の人員のシャッフルは非常に可能ですが、それでも市場の一般的な状況に大きな影響はありません。
1.3。 GitHubの分析
リンク： https : //cloudplatform.googleblog.com/2016/06/GitHub-on-BigQuery-analyze-all-the-open-source-code.htmlGoogleのスタッフは、公開のGitHubリポジトリをBigQueryエンジンにアップロードし、誰でも利用できるようにしました。 アカウントに約300ドルを入れることは残っており、この巨大なデータセットに関するあらゆる種類の統計を簡単に収集できます。 たとえば、パッケージsun.miscのすべての使用を検索します:-)
BigQueryの1.5Tbのデータはすぐにドルをカボチャに変えるため、クエリは賢明にコンパイルすることをお勧めします。
2.読む
2.1。 Javaメモリモデル
リンク1： http : //shipilev.net/blog/2016/close-encounters-of-jmm-kind/リンク2： https : //groups.google.com/d/msg/mechanical-sympathy/T0pNhJSkZWQ/zHDubWKUBwAJ
Javaメモリモデルは、無数の記事やレポートでよく噛まれています。 JVMおよびハードウェア実装の詳細を確実に隠すいくつかのルール。 しかし、開発者はこのエレガントなモデルの境界を越えようと頑固に試みており、彼らはすでに何が起こっているのかという根性にすでに精通していると誤って信じています。 スイング。 かゆみ。 かゆみ。 ここから、多くの誤解されたJMM解釈の足を伸ばします。 TSOの 場合 、 x86の volatileは必要ありません。 他の空の同期ブロックは、 ギャッシュの前に発生します。 3番目のメモリキャッシュは「フラッシュ」されます。 これに対処することは困難です。なぜなら、長い間、そのようなアプローチやステートメントの誤りを示す明確な例がなかったからです。
アレクセイ・シピレフは巨大な仕事をし、JMMの誤解の膨大な数の明確な例をまとめました。 はい、「TSOの並べ替え」の場所はまさにその通りです。 記事の大きさはレフ・ニコラエヴィッチにうらやましいでしょうが、その読みは非常に重要です。 まず第一に、信仰の観点から、読んだ後、あなたは最終的にあなたがJMMといちゃつくべきではないと信じるでしょう。
2番目のリンクに関するGil Teneの解説は、上記のすべての下に太い線を引きます。
2.2。 プロファイリングとAsyncGetCallTrace
リンク： http : //psy-lob-saw.blogspot.ru/2016/06/the-pros-and-cons-of-agct.html最近、 AsyncGetCallTraceメソッドについて多くの議論がありました。これにより、 safepointで停止する必要なく、ストリームのダンプを取ることができます。 たとえば、 Honest Profilerはそれに基づいて構築されています。 彼の投稿で、日産はこのアプローチの弱点をいくつか示しています。 たとえば、本質主義者をプロファイルできない。
近い将来、 JMC + Honest Profilerバンドルは、プロファイリングの最初のラインの標準になり、相互に非常にうまく補完できると思います。
日産のプロファイリングレポートの最新ビデオのフォローアップ：
2.3。 JITについて少し
リンク： https : //www.infoq.com/articles/OpenJDK-HotSpot-What-the-JITJITの機能に関する良い記事。 階層コンパイル、最適化解除、組み込み関数などの問題が考慮されます。 軽く興味深いものが書かれています。
ところで、私が個人的に理解していないJVMのソリューションが1つあります。コードキャッシュがメタスペースと分離されているのはなぜですか？ クラスローダーがアクティブに動作しているときに、これら2つのパラメーターを並行して調整する必要があるときに、問題に何度も遭遇しました。 それ以外の場合、コンパイルはある時点で単純に切断されます。 メタスペースなしではできないでしょうか？ そして一般的に、 メタスペースとコードキャッシュは現在、GCインフラストラクチャに十分に統合されていないように感じます。 たとえば、メタキャッシュで不要なクラスローダーがハングアウトしている場合でも 、 コードキャッシュオーバーフローを簡単に取得できます。
2.4。 GCの視覚化
リンク： http : //mattwarren.org/2016/06/20/Visualising-the-dotNET-Garbage-Collector/Matt Warrenは、アプリケーション中のGCの動作を視覚化しました。 確かに、Javaではなく.NETで:-)しかし、まだ興味深いです。 Javaに似たものはありますか？ また、JavaでGCイベントに関する通知を受信することは可能ですか？