謹慎地進行優化（55）

關於優化的深入真理：

• 優化弊大於利，產生的結果多是既不快速也不正確，並且很不容易修正

不要由於性能去犧牲合理的結構，努力寫好的程序而不是快的程序

• 可是這不意味着完成程序前能夠忽略性能問題
• 實現上的問題能夠經過後期優化獲得優化，可是遍及全局的結構性性能缺陷是不可能修復的，除非重作系統
• 設計之初必須全盤考慮，系統完成後進行基本結構調整會致使系統結構很很差，並且很不方便維護和改進

努力限制那些限制性能的設計決策

• 最難以更改的組件是那些指定了模塊之間交互關係和模塊與外界交互關係的組件
  • 最主要的要數API、線路層協議、永久數據格式
• 並且可能對本該達到的性能產生嚴重限制

要考慮API 設計決策的性能後果

• 公有類型變成可變的（非final類型），可能會致使大量沒必要要保護性拷貝
• 適合使用組合模式的公有類中使用繼承，使得這個類與超類永久性的束縛在一塊兒，人爲限制子類的性能
• 在API中使用實現類型而不是接口，這樣會把本身綁在具體實現類上，後續出現更快實現類沒法使用

API 設計對性能的影響是很是實際的

• 數百萬個小對象也會給系統帶來嚴重的性能問題
• 好的API 設計會帶來好的性能

爲得到好的性能而對API 進行包裝是很很差的想法

• 性能問題，可能在新的jdk 版本中不復存在，可是包裝的API 會一直困擾着你

性能剖析工具會幫助你決定優化的重心放在什麼地方

• 每一個方法大體花費了多少時間，被調用多少次，還能夠警告你是否須要替換算法

java 語言沒有很強的性能模型，因此性能優化後必須對比測試

• 並且 不一樣jvm 、不一樣發行版本、不一樣硬件平臺跑出來性能可能都有差別（對比測試的重要性）