『クラウドネイティブJavaの最適化 第2版』

付録A. マイクロベンチマーク

この付録 では、低レベルのJava性能数値を直接測定する具体的な方法について考察する。 JVMの動的な性質は、性能数値が多くの開発者が期待するよりも扱いにくいことが多いことを意味する。 その結果、インターネット上には不正確な、あるいは誤解を招くような性能数値が数多く出回っている。

本付録の主な目的は、このような落とし穴の可能性を認識し、自分も他の人も信頼できる性能数値だけを出すようにすることである。 特に、Javaコードの小片の測定（マイクロベンチマーク）は、微妙で正しく行うのが難しいことで有名であり、このテーマと性能エンジニアによる適切な使い方は、本付録全体の主要なテーマである。

第2章で紹介したファインマンの言葉は、マイクロベンチマークに適用する際に特に意味を持つ。

この付録の第2部では、マイクロベンチマークツールのゴールドスタンダードであるJMHの使用方法について説明する：すべての警告と注意事項の後でも、あなたのアプリケーションとユースケースがマイクロベンチマークを使用する価値があると本当に感じるなら、利用可能なツールの中で最も信頼性が高く高度なものから始めることによって、多くのよく知られた落とし穴と「熊の罠」を避ける必要がある。

低レベルJavaパフォーマンス測定入門

Javaパフォーマンス概要」では、パフォーマンス分析（ ）について、さまざまな側面の技術を統合した結果、基本的に実験科学である学問分野が生まれたと説明した。

つまり、良いベンチマーク（またはマイクロベンチマーク）を書きたいのであれば、それを科学実験のように考えることは非常に役に立つ。

このアプローチでは、ベンチマークを「不透明な箱」、つまりインプットとアウトプットがあり、そこから推測や推論ができるデータを収集したいと考える。 しかし、慎重を期す必要がある。単にデータを収集するだけでは十分ではない。 データに惑わされないようにする必要がある 。

ベンチマークの数字はそれだけでは重要ではない。その数字からどのようなモデルを導き出すかが重要なのだ。

アレクセイ・シピルёフ

つまり、可能な限りシステムの1つの側面だけを変更し、ベンチマークにおけるその他の外部要因は確実にコントロールすることである。 理想的な世界では、システムのその他の変更可能な側面は、テスト間で完全に不変であるべきだが、実際にはそれほど幸運なことはめったにない。

注

科学的に純粋で公正なテストという目標が実際には達成できないとしても、ベンチマークが少なくとも再現可能であることは不可欠である。

Javaプラットフォーム用のベンチマークを書く際の中心的な問題の1つは、Java ランタイムの高度さである。 本書のかなりの部分は、JVMによって開発者のコードに適用される自動最適化について明らかにすることに費やされている。 ベンチマークをこれらの最適化の文脈における科学的テストとして考えると、選択肢は限られてくる。

つまり、これらの最適化の正確な影響を完全に理解し、説明することは不可能に近いのだ。 アプリケーションコードの "実際の "パフォーマンスに関する正確なモデルを作成することは難しく、その適用範囲は限定される傾向にある。

別の言い方をすれば、実行中のJavaコードを、Javaランタイムが提供するJITコンパイラ、メモリ管理、その他のサブシステムから真に切り離すことはできない。 また、テストを実行するときのオペレーティングシステム、ハードウェア、またはランタイムの条件（負荷など）の影響を無視することもできない。 ...