O'Reilly Japan - Javaパフォーマンス
こちらの本の１章まとめ
1章 イントロダクション - Qiita←今回記事
2章 パフォーマンステストのアプローチ - Qiita←次回記事
3章 Javaパフォーマンスのツールボックス - Qiita
4章 JIT コンパイラのしくみ - Qiita
5章 ガベージコレクションの基礎 - Qiita
本書では、JVMの設定と良い標準APIの使い方の２つについて説明がされる。
パフォーマンスの全体像
よりよいアルゴリズムを記述する
最終的にはパフォーマンスはコードの適切さにかかってくる。
特定の要素を探すコードだったら、いくらループするコードをなんとかしようとしても、HashMapを使うコードには勝てない。
コードの量を少なくする
いまだに書いたコード量で開発者を評価する管理者もいるが、
コード量が少ない場合のほうがパフォーマンス面で有利なことが多い。特にJavaだとこの傾向が強いらしい。
コンパイルしないといけないコードが増えれば、JITコンパイラのによってコードが速く実行できるようになるまでの時間が増加。
生成廃棄しないといけないオブジェクトの量が増えれば、GCの作業量も増える。
多くのオブジェクトを保持し続ければ、GCのサイクルが伸びる。
ロードするクラスが増えれば、起動する時間も増える。
実行されるコードのサイズが増えれば、キャッシュに収まらない可能性もある。
パフォーマンスは常に悪化する。機能追加がされていくため。
早まった安易な最適化
1日のうち97%くらいは、ささいな効率については忘れるべきです。早まった最適化は諸悪の根源です。
という有名な言葉がある。
クリーンで率直なコードを書いて読みやすくするようにすべきで、
分析をせずに最適化（パフォーマンス面で優位になる代わりに、構造が複雑になるような修正）するべきではない。
しかし、明らかにパフォーマンス面で問題になるようなコードを避けるというのは別の問題で、それはいいことである。
外部を見渡す(データベースは常にボトルネック)
外部リソースを使わないスタンドアロンの場合は、パフォーマンスでネックなのはそのアプリケーションだけ。
しかし、外部リソースを使う場合は、そこがネックになる。
本書では、Javaだけでなく、全体について分析がされていると仮定してJavaパフォーマンスについて説明を行う。
よくあるケースのために最適化する
頻度の高いユースケースに注力する。