Javaパフォーマンス
2章
ベンチマーク
マイクロベンチマーク
Javaのコードはコンパイルするたびに早くなるらしい
なので、このウォームアップを行ってから計測に入るのが良さそう
特定の処理自体の速度のベンチマークっぽい
マクロベンチマーク
ユーザ視点での速度のベンチマーク
外部リソースを使った場合など、アプリケーションに対するベンチマーク
最適化が行われるため
ウォームアップ
正しいテストを行うためにコードのウォームアップを行う
JITコンパイラで最適化される
ウォームアップなしだと遅いので、ウォームアップによって最適化されたあとに計測するのが通例
ウォームアップを行うメリット
コンパイラによる最適化
キャッシュの有効利用
同じファイルをキャッシュして、ループなどを高速化ｆ
3章
オペレーティング・システム付属のツール
CPUの使用率について
使用率とはどのくらい効率的にCPUが処理できたかの指標
CPU使用率50%でバッチ処理が1秒かかっているとすると、
使用率を100%にあげたら0.5秒で処理が完了する。
100%に使用率は上昇するが、そのほうが効率的なので望ましい
しかし、これは一定間隔でリクエストが来た場合や、他に処理するものがない場合などでしか意味はない。
CPUが単一と複数、スレッドが複数の場合でも目指すゴールは2つ
スレッド同士がブロックされないようにCPU使用率を上げること
多くのリクエストをさばけるようにCPU使用率を下げること
vmstatとか
ディスクの使用率
iostat
ファイル入出力がないアプリケーションもディスク監視はすべき
理由はメモリのスワッピングが発生する可能性があるため
Javaだとヒープのおかげで、顕著にメモリに影響がでるらしい。Javaアプリはメモリをいっぱいつかうから
スワップインやスワップアウト
一秒間の書き込み量
使用率
ネットワークの使用率
netstat
nicstat
JITコンパイラ
役割
プログラムからコンパイルによって中間コード（classファイル）になるが、それを機械語にコンパイルするもの
JITコンパイルされた機械語がCPU上に乗っかり処理が実行される。
JITコンパイルされるタイミングは特定のメソッドをコールしたとき。
複数回メソッドをコールするとJITコンパイラはキャッシュぽいことをして、同じコンパイルはしないようにする
コンパイル時に何度も実行されるようなコードはコンパイルを行っておくことで高速化できる
逆にそんなに使われないコードの場合はコンパイルしてもその時間が無駄なので、インタプリタっぽく呼ぶことになる
なにか？
JVM上に実装されているコンパイラ
クラスファイルを機械語にコンパイルして実行可能状態にするやつ
必要なものを必要なときだけコンパイルする
Javaのコンパイルから実行までの流れ
1. javaファイル
2. javacでコンパイルしてclassファイル作成
3. JVM上で実行
4. JVMのjavaインタプリタで実行
5. コンパイルした方がパフォーマンスが出そうならJITコンパイラによるコンパイルが実施される
あまり使われないコードをJITコンパイルしたとしても、その時間が持った無い
逆にequalsとかの場合は何度もインタプリタによる実行のほうがコストがかかる
なので、JITコンパイルして、機械語にしておいてやる
最適化だね
classファイルは中間コードであり、これを作ることでどのJVM上でも実行が可能
JVMのインストールはOS似合ったものにしておくとOK
JITコンパイラ種類
クライアントコンパイラ
サーバコンパイラ
階層的コンパイラ
早期にコンパイルを実施する
初期のほうが早くなる
様子を見て最適なコンパイルを行う
最初は遅いが、最適化がクライアントに比べ良い
早期にコンパイルして、より多く利用されるものについては、サーバコンパイラっぽく最適化を目指して再度コンパイルされる
Java7から試験的に導入されて、java8からはデフォルトとなってるらしい
オプションについて
コンパイルさせる閾値を設定することもできる
例えばメソッドが10回コールされたらコンパイルするように設定など