谨慎地进行优化（55）

关于优化的深入真理：

• 优化弊大于利，产生的结果多是既不快速也不正确，并且很不容易修正

不要由于性能去牺牲合理的结构，努力写好的程序而不是快的程序

• 可是这不意味着完成程序前能够忽略性能问题
• 实现上的问题能够经过后期优化获得优化，可是遍及全局的结构性性能缺陷是不可能修复的，除非重作系统
• 设计之初必须全盘考虑，系统完成后进行基本结构调整会致使系统结构很很差，并且很不方便维护和改进

努力限制那些限制性能的设计决策

• 最难以更改的组件是那些指定了模块之间交互关系和模块与外界交互关系的组件
  • 最主要的要数API、线路层协议、永久数据格式
• 并且可能对本该达到的性能产生严重限制

要考虑API 设计决策的性能后果

• 公有类型变成可变的（非final类型），可能会致使大量没必要要保护性拷贝
• 适合使用组合模式的公有类中使用继承，使得这个类与超类永久性的束缚在一块儿，人为限制子类的性能
• 在API中使用实现类型而不是接口，这样会把本身绑在具体实现类上，后续出现更快实现类没法使用

API 设计对性能的影响是很是实际的

• 数百万个小对象也会给系统带来严重的性能问题
• 好的API 设计会带来好的性能

为得到好的性能而对API 进行包装是很很差的想法

• 性能问题，可能在新的jdk 版本中不复存在，可是包装的API 会一直困扰着你

性能剖析工具会帮助你决定优化的重心放在什么地方

• 每一个方法大体花费了多少时间，被调用多少次，还能够警告你是否须要替换算法

java 语言没有很强的性能模型，因此性能优化后必须对比测试

• 并且 不一样jvm 、不一样发行版本、不一样硬件平台跑出来性能可能都有差别（对比测试的重要性）