许多通常的 java 性能问题都起源于在设计过程早期中的类设计的思想, 早在许多开发者开始考虑性能问题之前. 在这个系列中, brian goetz 讨论了通常的 java 性能上的冒险以及怎么在设计时候避免它们. 在第二部分, 他讨论了减少临时对象创建的一些技术。
                                                                                    
　　虽然许多程序员把性能管理一直推迟到开发过程的最后, 性能考虑应该从第一天起就和设计周期结合在一起. 这个系列探索一些早期的设计思想能够极大影响应用程序性能的方法.在这篇文章里, 我继续探索大量临时对象创建的问题, 并且提供一些避免它们的一些技术.

　　临时对象就是一些生命周期比较短的对象, 一般用于保存其他数据而再没有其他用途. 程序员一般用临时变量向一个方法传递数据或者从一个方法返回数据. 第一部分探讨了临时对象是怎样给一个程序的性能带来负面的冲击, 以及一些类接口的设计思想怎样提供了临时对象的创建. 避免了那些接口的创建, 你就能极大地减少那些影响你的程序性能的临时对象创建的需求。         

　　只是对 string 说不吗?

　　当它要创建临时变量时, string 类是最大的罪人中的一个. 为了演示, 在第一部分我写了一个正规表达式匹配的例子, 通过和一个类似的但是经过仔细设计的接口相比较, 演示了看起来无害的接口是怎样引起大量对象的创建, 而慢上几倍. 这里是原来的和好一些的类的接口:

坏的正则表达式匹配实例：
public class badregexpmatcher {
  public badregexpmatcher(string regexp);
  public string match(string inputtext);
}                                                                                                                   

好的正则表达式匹配实例：

class betterregexpmatcher {
  public betterregexpmatcher(...);//省略了一些

  public int match(string inputtext);
  public int match(char[] inputtext);
  public int match(char[] inputtext, int offset, int length);
 
  public int getmatchlength();
  public string getmatchtext();
}
   　大量使用 badregexpmatcher 的程序比使用 btterregexpmatcher 的要慢好多. 首先,调用者不得不创建一个 string 传入 match(), 接着 match() 又创建了一个 string 来返回匹配的文本. 结果是每次调用都有两个对象创建, 看起来不多, 但是如果要经常调用match(), 这些对象创建带给性能的代价就太大了. badregexpmatcher 的性能问题不是在它的实现中, 而是它的接口; 象它定义的接口, 没有办法避免一些临时变量的创建。

　　betterregexpmatcher 的 match() 用原类型(整数和字符数组)代替了 string 对象; 不需要创建中间对象来在调用者和 match() 之间传递信息.

　　既然在设计时候避免性能问题要比写完整个系统以后再修改要容易一些, 你应该注意你的类中控制对象创建的方法. 在 regexpmatcher 的例子中, 它的方法要求和返回 string 对象, 就应该为潜在的性能冒险提个警告信号. 因为 string 类是不可变的, 除了最常用以外, 所有的 string 参数在每次调用处理函数时都需要创建一个新的 string.

　　不可变性对于性能来说是否很坏?

　　因为 string 经常和大量的对象创建联系在一起, 一般来说归咎于它的不可变性. 许多程序员认为不可变的对象与生俱来对性能没有好处. 但是, 事实多少会更复杂一些. 实际上, 不可变性有时候提供了性能上的优势, 可变性的对象有时候导致性能问题. 不管可变性对性能来说有帮助或者有害, 依赖于对象是怎么使用的.

　　程序经常处理和修改文本字符串 -- 这和不可变性非常不匹配。每次你想处理一个 string --想查找和解析出前缀或者子串, 变小写或者大写, 或者把两个字符串合并 -- 你必须创建一个新的 string 对象. (在合并的情况下, 编译器也会隐藏地创建一个 stringbuffer() 对象)

　　另一个方面, 一个不可变的对象的一个引用可以自由共享, 而不用担心被引用的对象要被修改, 这个比可变对象提供性能优势, 就象下一节例子所说的。

　　可变的对象有它们自己的临时对象问题.

　　在 regexpmatcher 的例子中, 你看见了 当一个方法返回一个 string 类型时, 它通常需要新建一个 string 对象. badregexpmatcher 的一个问题就是 match() 返回一个对象而不是一个原类型 -- 但是只因为一个方法返回一个对象, 不意味着必须有一个新对象创建. 考虑一下 java.awt 中的几何类, 象 point 和 rectangle. 一个 rectangle只是四个整数(x, y, 宽度, 长度)的容器， awt component 类存储组件的位置, 通过getbounds()作为一个rectangle 返回

public class component {
  ...
  public rectangle getbounds();
}

　　在上面的例子中, getbounds() 只是一个存储元 -- 它只使一些 component 内部的一些状态信息可用. getbounds() 需要创建它返回的 rectangle 吗? 可能. 考虑一下下面getbounds() 可能的实现.

public class component {
  ...
  protected rectangle mybounds;
  public rectangle getbounds()  { return mybounds; }
}

　　当一个调用者调用上面例子中的 getbounds(), 没有新对象创建 -- 因为组件已经知道它在哪里 -- 所以 getbounds() 效率很高. 但是 rectangle 的可变性又有了其他问题. 当一个调用者运行一下程序会发生什么呢?

  rectangle r = component.getbounds();
  ...
  r.height *= 2;

　　因为 rectangle 是可变的, 它在 component 不知道的情况下使 component 移动. 对象awt 这样的 gui 工具箱来说, 这是个灾难,  因为当一个组件移动以后, 屏幕需要重绘, 组件监听器需要被通知, 等等. 所以上面的实现 component.getbounds() 的代码看起来很危险. 一个安全一点的实现就象下面这样:

  public rectangle getbounds() {
    return new rectangle(mybounds.x, mybounds.y,
                         mybounds.height, mybounds.width);
  }

　　但是现在, 每一个 getbounds() 的调用都创建一个新对象, 就象 regexpmatcher 一样.实际上, 下面的代码片段创建了 4 个临时对象:

  int x = component.getbounds().x;
  int y = component.getbounds().y;
  int h = component.getbounds().height;
  int w = component.getbounds().width;

　　在 string 的情况中, 对象创建是必要的, 因为 string 是不可变的. 但在这个例子中,对象的创建也是必要的, 因为 rectangle 是可变的. 我们使用 string 避免了这个问题,在我们的接口中没有使用对象. 虽然在 regexpmatcher 的情况下很好, 这个方法不总是可行的或者是希望的. 幸运的是, 你可以在实际类的时候可以使用一些技巧, 来免除太多小对象的问题, 而不是完全避免小对象.

　　减少对象的技巧 1: 加上好的存取函数

　　在 swing 工具箱的初始版本中, 小对象的临时创建, 象 point, rectangle 和 dimension极大地阻碍了性能. 把它们放在一个 point 或者 rectangle 中来一次返回多个值, 看起来更有效, 实际上, 对象的创建比多个方法调用代价更高. 在 swing 的最后发布之前, 通过给 component 和其他一些类加一些新的存取方法, 问题就简单地解决了, 就象下面这样:

  public int getx()      { return mybounds.x; }
  public int gety()      { return mybounds.y; }
  public int getheight() { return mybounds.height; }
  public int getwidth()  { return mybounds.width; }

　　现在一个调用者可以这样获取边界而不用创建对象:

  int x = component.getx();
  int y = component.gety();
  int h = component.getheight();
  int w = component.getwidth();

　　getbounds() 的旧形式仍然支持; 好的存取方法简单地提供了有效的方法来达到相同的目的. 结果是, rectangle 的接口全部在 component 中使用. 当修改 swing 包支持和使用这样的存取函数后, 在许多 swing 操作中比以前要快到两倍. 这很好, 因为 gui 代码非常注意性能 -- 用户等待发生一些事, 希望 ui 操作瞬间完成.

　　使用这个技术不好的地方就是你的对象提供了更多的方法, 有多于一个的方法来得到相同的信息, 就使文档更大更复杂, 可能使用户害怕. 但是就象 swing 的例子显示的, 在关注性能的情况下, 这样的优化技术是有效的.

　　技巧 2: 利用可变性

　　除了给 component 加上原类型的存储函数 -- 象上面讨论的 getx() 函数 -- 以外, java 2 在 awt 和 swing 中也使用了另一种技术来减少对象创建, 允许一个调用者把边界作为一个 rectangle 得到, 但是不需要任何临时对象的创建.

  public rectangle getbounds(rectangle returnval) {
    returnval.x = mybounds.x;
    returnval.y = mybounds.y;
    returnval.height = mybounds.height;
    returnval.width = mybounds.width;
    return returnval;
  }

　　调用者仍然需要创建一个 rectangle 对象, 但它可以在后来的调用中重用. 如果一个调用者在一系列的 component 中循环, 可以只创建一个 rectangle 对象, 在每个 component 中重用. 注意这个技术只用于可变性对象; 你不能用这种方法消除 string 的创建.

　　技巧 3: 得到两个中的最好的.

　　一个解决在简单类(象 point 之类)的对象创建的问题, 更好的方法是使 point 对象不可变，但是定义一个可变的子类, 就象下面这样:

  public class point {
    protected int x, y;
    public point(int x, int y) { this.x = x; this.y = y; }
    public final int getx() { return x; }
    public final int gety() { return y; }
  }

  public class mutablepoint extends point {
    public final void setx(int x) { this.x = x; }
    public final void sety(int y) { this.y = y; }
  }

  public class shape {
    private mutablepoint mylocation;
    public shape(int x, int y) { mylocation = new mutablepoint(x, y); }
    public point getlocation()       { return (point) mylocation; }
  }

　　在上面的例子中, shape 可以安全返回一个 mylocation 的引用, 因为调用者试图修改域或者调用设置函数会失败. (当然, 调用者仍然可以把 point 转换为 mutablepoint, 但这明显不安全, 这样的调用者可能得到他们想要的) 。

　　这个技巧 -- 返回一个具有可变的和不可变的类, 只允许读对象, 而不创建新对象 --在 java 1.3 类库 java.math.biginteger 类中使用. mutablebiginteger 类不可见 --它是一个只在 java.math 类库中内部使用的私有类型. 但是既然 biginteger 的一些方法(象 gcd()) 在许多数学操作中都有, 在一个地方操作比创建上百个临时变量性能提高非常大.

　　结论

　　所有的性能优化的建议中, 值得记住的是有许多程序的性能可以完全接受的情况. 在这些情况下, 不值得牺牲可读性, 可维护性, 抽象, 或者其他可取的程序属性来获得性能. 但是, 既然许多性能问题的种子在设计时就种下了, 要注意到设计思想潜在地对性能的冲击，当你设计的类在关注性能的情况使用, 你可以有效地使用这里提到的技巧来减少临时对象的创建