关于优化的深刻真理:
- 优化弊大于利,产生的结果可能是既不快速也不正确,而且很不容易修正
不要因为性能去牺牲合理的结构,努力写好的程序而不是快的程序
- 但是这不意味着完成程序前可以忽略性能问题
- 实现上的问题可以通过后期优化得到优化,但是遍布全局的结构性性能缺陷是不可能修复的,除非重做系统
- 设计之初必须全盘考虑,系统完成后进行基本结构调整会导致系统结构很不好,而且很不方便维护和改进
努力限制那些限制性能的设计决策
- 最难以更改的组件是那些指定了模块之间交互关系和模块与外界交互关系的组件
- 最主要的要数API、线路层协议、永久数据格式
- 而且可能对本该达到的性能产生严重限制
要考虑API 设计决策的性能后果
- 公有类型变成可变的(非final类型),可能会导致大量不必要保护性拷贝
- 适合使用组合模式的公有类中使用继承,使得这个类与超类永久性的束缚在一起,人为限制子类的性能
- 在API中使用实现类型而不是接口,这样会把自己绑在具体实现类上,后续出现更快实现类无法使用
API 设计对性能的影响是非常实际的
- 数百万个小对象也会给系统带来严重的性能问题
- 好的API 设计会带来好的性能
为获得好的性能而对API 进行包装是很不好的想法
- 性能问题,可能在新的jdk 版本中不复存在,但是包装的API 会一直困扰着你
性能剖析工具会帮助你决定优化的重心放在什么地方
- 每个方法大致花费了多少时间,被调用多少次,还可以警告你是否需要替换算法
java 语言没有很强的性能模型,所以性能优化后必须对比测试
- 而且 不同jvm 、不同发行版本、不同硬件平台跑出来性能可能都有差异(对比测试的重要性)