发信人: SuperMMX (笑天子*不再喝可乐)
发信站: BBS 水木清华站
来自 http://SuperMMX.dhs.org/forum
原文请到此站查看.
[b]为性能而设计, 第二部分: 减少对象创建[/b]
From Java World.
[b]在设计 Java 类的时候避免性能上的冒险[/b]
[b][u]概要[/u][/b]
许多通常的 Java 性能问题都起源于在设计过程早期中的类设计的思想, 早在许多开发者
开始考虑性能问题之前. 在这个系列中, Brian Goetz 讨论了通常的 Java 性能上的冒险
以及怎么在设计时候避免它们. 在第二部分, 他讨论了减少临时对象创建的一些技术.
(1,700 字)
By Brian Goetz
翻译 by SuperMMX
阅读整个"为性能而设计"系列:
第一部分: 接口事宜
第二部分: 减少对象创建
第三部分: 远程接口 (March 23, 2001)
虽然许多程序员把性能管理一直推迟到开发过程的最后, 性能考虑应该从第一天起就和设
计周期结合在一起. 这个系列探索一些早期的设计思想能够极大影响应用程序性能的方法.
在这篇文章里, 我继续探索大量临时对象创建的问题, 并且提供一些避免它们的一些技术.
临时对象就是一些生命周期比较短的对象, 一般用于保存其他数据而再没有其他用途. 程
序员一般用临时变量向一个方法传递数据或者从一个方法返回数据. 第一部分探讨了临时
对象是怎样给一个程序的性能带来负面的冲击, 以及一些类接口的设计思想怎样提供了临
时对象的创建. 避免了那些接口的创建, 你就能极大地减少那些影响你的程序性能的临时
对象创建的需求,
[b][u]只是对 String 说不吗?[/u][/b]
当它要创建临时变量时, String 类是最大的罪人中的一个. 为了演示, 在第一部分我写了
一个正规表达式匹配的例子, 通过和一个类似的但是经过仔细设计的接口相比较, 演示了
看起来无害的接口是怎样引起大量对象的创建, 而慢上几倍. 这里是原来的和好一些的类
的接口:
BadRegExpMatcher
[code]
public class BadRegExpMatcher {
public BadRegExpMatcher(String regExp);
/** Attempts to match the specified regular expression against the input
text, returning the matched text if possible or null if not */
public String match(String inputText);
}
[/code]
BetterRegExpMatcher
[code]
class BetterRegExpMatcher {
public BetterRegExpMatcher(...);
/** Provide matchers for multiple formats of input -- String,
character array, and subset of character array. Return -1 if no
match was made; return offset of match start if a match was
made. */
public int match(String inputText);
public int match(char[] inputText);
public int match(char[] inputText, int offset, int length);
/** If a match was made, returns the length of the match; between
the offset and the length, the caller should be able to
reconstruct the match text from the offset and length */
public int getMatchLength();
/** Convenience routine to get the match string, in the event the
caller happens to wants a String */
public String getMatchText();
}
[/code]
大量使用 BadREgExpMatcher 的程序比使用 BtterRegExpMatcher 的要慢好多. 首先,
调用者不得不创建一个 String 传入 match(), 接着 match() 又创建了一个 String 来
返回匹配的文本. 结果是每次调用都有两个对象创建, 看起来不多, 但是如果要经常调用
match(), 这些对象创建带给性能的代价就太打了. BadRegExpMatcher 的性能问题不是在
它的实现中, 而是它的接口; 象它定义的接口, 没有办法避免一些临时变量的创建.
BetterRegExpMatcher 的 match() 用原类型(整数和字符数组)代替了 String 对象; 不需
要创建中间对象来在调用者和 match() 之间传递信息.
既然在设计时候避免性能问题要比写完整个系统以后再修改要容易一些, 你应该注意你的
类中控制对象创建的方法. 在 RegExpMatcher 的例子中, 它的方法要求和返回 String
对象, 就应该为潜在的性能冒险提个警告信号. 因为 String 类是不可变的, 除了最常用
以外, 所有的 String 参数在每次调用处理函数时都需要创建一个新的 String.
[b][u]不可变性对于性能来说是否很坏?[/u][/b]
因为 String 经常和大量的对象创建联系在一起, 一般来说归咎于它的不可变性. 许多
程序员认为不可变的对象与生俱来对性能没有好处. 但是, 事实多少会更复杂一些. 实
际上, 不可变性有时候提供了性能上的优势, 可变性的对象有时候导致性能问题. 不管可
变性对性能来说有帮助或者有害, 依赖于对象是怎么使用的.
程序经常处理和修改文本字符串 -- 和不可变性非常不匹配. 每次你想处理一个 String --
想查找和解析出前缀或者子串, 变小写或者大写, 或者把两个字符串合并 -- 你必须创建
一个新的 String 对象. (在合并的情况下, 编译器也会隐藏地创建一个 StringBuffer()
对象)
另一个方面, 一个不可变的对象的一个引用可以自由共享, 而不用担心被引用的对象要被
修改, 这个比可变对象提供性能优势, 就象下一节例子所说的.
[b][u]可变的对象有它们自己的临时对象问题. [/u][/b]
在 RegExpMatcher 的例子中, 你看见了 当一个方法返回一个 String 类型时, 它通常
需要新建一个 String 对象. BadRegExpMatcher 的一个问题就是 match() 返回一个对
象而不是一个原类型 -- 但是只因为一个方法返回一个对象, 不意味着必须有一个新对
象创建. 考虑一下 java.awt 中的几何类, 象 Point 和 Rectangle. 一个 Rectangle
只是四个整数(x, y, 宽度, 长度)的容器. AWT Component 类存储组件的位置, 通过
getBounds()作为一个Rectangle 返回
[code]
public class Component {
...
public Rectangle getBounds();
}
[/code]
在上面的例子中, getBounds() 只是一个存储元 -- 它只使一些 Component 内部的一
些状态信息可用. getBounds() 需要创建它返回的 Rectangle 吗? 可能. 考虑一下下面
getBounds() 可能的实现.
[code]
public class Component {
...
protected Rectangle myBounds;
public Rectangle getBounds() { return myBounds; }
}
[/code]
当一个调用者调用上面例子中的 getBounds(), 没有新对象创建 -- 因为组件已经知道它
在哪里 -- 所以 getBounds() 效率很高. 但是 Rectangle 的可变性又有了其他问题. 当
一个调用者运行一下程序会发生什么呢?
[code]
Rectangle r = component.getBounds();
...
r.height *= 2;
[/code]
因为 Rectangle 是可变的, 它在 Component 不知道的情况下使 Component 移动. 对象
AWT 这样的 GUI 工具箱来说, 这是个灾难, 因为当一个组件移动以后, 屏幕需要重绘,
件监听器需要被通知, 等等. 所以上面的实现 Component.getBounds() 的代码看起来很
危险. 一个安全一点的实现就象下面这样:
[code]
public Rectangle getBounds() {
return new Rectangle(myBounds.x, myBounds.y,
myBounds.height, myBounds.width);
}
[/code]
但是现在, 每一个 getBounds() 的调用都创建一个新对象, 就象 RegExpMatcher 一样.
实际上, 下面的代码片段创建了 4 个临时对象:
[code]
int x = component.getBounds().x;
int y = component.getBounds().y;
int h = component.getBounds().height;
int w = component.getBounds().width;
[/code]
在 String 的情况中, 对象创建是必要的, 因为 String 是不可变的. 但在这个例子中,
对象的创建也是必要的, 因为 Rectangle 是可变的. 我们使用 String 避免了这个问题,
在我们的接口中没有使用对象. 虽然在 RegExpMatcher 的情况下很好, 这个方法不总是
可行的或者是希望的. 幸运的是, 你可以在实际类的时候可以使用一些技巧, 来免除太多
小对象的问题, 而不是完全避免小对象.
[b][u]减少对象的技巧 1: 加上好的存取函数[/u][/b]
在 Swing 工具箱的初始版本中, 对象小对象的临时创建, 象 Point, Rectangle 和 Dimension
极大地阻碍了性能. 把它们放在一个 Point 或者 Rectangle 中来一次返回多个值, 看起
来更有效, 实际上, 对象的创建比多个方法调用代价更高. 在 Swing 的最后发布之前, 通
过给 Component 和其他一些类加一些新的存取方法, 问题就简单地解决了, 就象下面这样:
[code]
public int getX() { return myBounds.x; }
public int getY() { return myBounds.y; }
public int getHeight() { return myBounds.height; }
public int getWidth() { return myBounds.width; }
[/code]
现在一个调用者可以这样获取边界而不用创建对象:
[code]
int x = component.getX();
int y = component.getY();
int h = component.getHeight();
int w = component.getWidth();
[/code]
getBounds() 的旧形式仍然支持; 好的存取方法简单地提供了有效的方法来达到相同的目
的. 结果是, Rectangle 的接口全部在 Component 中使用. 当修改 Swing 包支持和使用
这样的存取函数后, 在许多 Swing 操作中比以前要快到两倍. 这很好, 因为 GUI 代码非
常注意性能 -- 用户等待发生一些事, 希望 UI 操作瞬间完成.
使用这个技术不好的地方就是你的对象提供了更多的方法, 有多于一个的方法来得到相同
的信息, 就使文档更大更复杂, 可能使用户害怕. 但是就象 Swing 的例子显示的, 在关注
性能的情况下, 这样的优化技术是有效的.
[b][u]技巧 2: 利用可变性[/u][/b]
除了给 Component 加上原类型的存储函数 -- 象上面讨论的 getX() 函数 -- 以外,
Java 2 在 AWT 和 Swing 中也使用了另一种技术来减少对象创建, 允许一个调用者把边界
作为一个 Rectangle 得到, 但是不需要任何临时对象的创建.
[code]
public Rectangle getBounds(Rectangle returnVal) {
returnVal.x = myBounds.x;
returnVal.y = myBounds.y;
returnVal.height = myBounds.height;
returnVal.width = myBounds.width;
return returnVal;
}
[/code]
调用者仍然需要创建一个 Rectangle 对象, 但它可以在后来的调用中重用. 如果一个调用
者在一系列的 Component 中循环, 可以只创建一个 Rectangle 对象, 在每个 Component
中重用. 注意这个技术只用于可变性对象; 你不能用这种方法消除 String 的创建.
[b][u]技巧 3: 得到两个中的最好的.[/u]][/b]
一个解决在简单类(象 Point 之类)的对象创建的问题, 更好的方法是使 Point 对象不可?
但是定义一个可变的子类, 就象下面这样:
[code]
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; }
}
[/code]
在上面的例子中, Shape 可以安全返回一个 myLocation 的引用, 因为调用者试图修改域
或者调用设置函数会失败. (当然, 调用者仍然可以把 Point 转换为 MutablePoint, 但
这明显不安全, 这样的调用者可能得到他们想要的) C++ 程序员可能注意到了这个技巧很
象 C++ 中返回一个 Rectangle 的常量引用(cong Rectangle&) -- 一个 Java 不支持的
特点.
这个技巧 -- 返回一个具有可变的和不可变的类, 只允许读的对象, 而不创建新对象 --
在 Java 1.3 类库 java.math.BigInteger 类中使用. MutableBigInteger 类不可见 --
它是一个只在 java.math 类库中内部使用的私有类型. 但是既然 BigInteger 的一些方
法(象 gcd()) 在许多数学操作中都有, 在一个地方操作比创建上百个临时变量性能提高
非常大.
[b][u]结论[/u][/b]
所有的性能优化的建议中, 值得记住的是有许多程序的性能可以完全接受的情况. 在这
些情况下, 不值得牺牲可读性, 可维护性, 抽象, 或者其他可取的程序属性来获得性能.
但是, 既然许多性能问题的种子在设计时就种下了, 要注意到设计思想潜在地对性能的冲?
当你设计的类在关注性能的情况性爱使用, 你可以有效地使用这里提到的技巧来减少临时
对象的创建,
In Part 3, I'll look at some of the performance issues specific to distributed
applications and show how to spot and eliminate them at design time.
在第三部分中, 我将看看分布式的应用程序中特有的性能问题, 怎样在设计时候找出和消
除它们
About the author
Brian Goetz is a professional software developer with over 15 years of
experience. He is a principal consultant at Quiotix, a software development
and consulting firm located in Los Altos, Calif.
本文地址：http://com.8s8s.com/it/it18123.htm