跟我学（Effective Java 2）第55条:谨慎地进行优化

第55条:谨慎地进行优化

优化的弊大于利，特别是不成熟的优化。在优化过程中，产生的软件可能既不快速，也不正确，而且还不容易修正。

不要因为性能而牺牲合理的结构。要努力编写好的程序而不足快的栏序。如果好的程序不够快，它的结构将使它可以得到优化。好的程序体现了信息隐藏 (information hiding）的原则：只要有可能，它们就会把设计决策集中在单个模块中，因此，可以改变单个决策，而不会影响到系统的其他部分（见第13条：使类和成员的可访问性最小化）。

这并不意味着在完成程序之前就可以忽略性能问题。实现上的问题可以通过后期的优化而得到修正，但是，遍布全局并且限制性能的结构缺陷几乎是不可能被改正的．除非重新编写系统。在系统完成之后再改变设计的某个基本方面，会导致系统的结构很不好，从而难以维护和改进。因此，必须在设计过程中考虑到性能间题。

1 努力避免那些限制性能的设计决策。 当一个系统设计完成之后，其中最难以更改的组件是那些指定了模块之间交互关系以及模块与外界交互关系的组件。在这些设计组件之中，最主要的是API线路层（wire-Ievel）协议以及永久数据格式。这些设计组件不仅在事后难以甚至不可能改变，而且它们都有可能对系统本该达到的性能产生严重的限制。

2 要考虑API设计决策的性能后果。 使公有的类型成为可变的（mutable )。这可能会导致大量不必要的保护性拷贝（见第39条：必要时进行保护性拷贝 )。同样地，在适合使用复合模式的公有类中使用继承，会把这个类与它的超类永远地束缚在一起，从而人为地限制了子类的性能（见第16条：复合优先于继承)。最后一个例子，在API中使用实现类型而不是接口，会把你束缚在一个具休的实现上，即使将来出现更快的实现你也无法使用（见第52条：通过接口引用对象）。

API设计对于性能的影响是非常实际的。幸运的是，一般而言，好的API设计也会带来好的性能。为获得好的性能而对API进行包装，这是一种非常不好的想法。你对API进行包装的性能因素可能会在平台未来的发行版本中，或者在将来的底层软件中不复存在，但是披包装的API以及由它引起的问题将永远困扰着你。

一旦谨慎地设计了程序，井且产生了一个清晰、简明、结构良好的实现，那么就到了该考虑优化的时候了，假定此时你对于程序的性能还不满意。在每次试图做优化之前和之后，要对性能进行测量。

性能剖析工具有助于你决定应该把优化的重心放在哪里。这样的工具可以为你提供运行时的信息，比如每个方法大致上花费了多少时间、它被调用多少次。除了确定优化的重点之外，它还可以警告你是否需要改变算法。

总而言之，不要费力去编写快速的程序——应该努力编写好的程序，速度自然会随之而来。在设计系统的时候，特别是在设计API、线路层协议和永久数据格式的时候，一定要考虑性能的因素。当构建完系统之后，要测量它的性能。如果它足够快，你的任务就完成了。如果不够快，则可以在性能剖析器的帮助下，找到问题的根源，然后设法优化系统中相关的部分。第一个步骤是检查所选择的算法：再多的低层优化也无法弥补算法的选择不当。必要时重复这个过程，在每次改变之后都要测量性能，直到满意为止。