?

翻譯 by SuperMMX

　　閱讀整個(gè)的 "為性能而設(shè)計(jì)" 系列: 　　第一部分: 接口事宜 　　第二部分: 減少對(duì)象創(chuàng)建 　　第三部分: 遠(yuǎn)程接口 (March 23, 2001)

　　第二部分: 減少對(duì)象創(chuàng)建

　　概要 　　許多通常的 Java 性能問題都起源于在設(shè)計(jì)過程早期中的類設(shè)計(jì)的思想, 早在許多開發(fā)者開始考慮性能問題之前. 在這個(gè)系列中, Brian Goetz 討論了通常的 Java 性能上的冒險(xiǎn)以及怎么在設(shè)計(jì)時(shí)候避免它們. 在第二部分, 他討論了減少臨時(shí)對(duì)象創(chuàng)建的一些技術(shù)。

　　雖然許多程序員把性能管理一直推遲到開發(fā)過程的最后, 性能考慮應(yīng)該從第一天起就和設(shè)計(jì)周期結(jié)合在一起. 這個(gè)系列探索一些早期的設(shè)計(jì)思想能夠極大影響應(yīng)用程序性能的方法.在這篇文章里, 我繼續(xù)探索大量臨時(shí)對(duì)象創(chuàng)建的問題, 并且提供一些避免它們的一些技術(shù).

　　臨時(shí)對(duì)象就是一些生命周期比較短的對(duì)象, 一般用于保存其他數(shù)據(jù)而再?zèng)]有其他用途. 程序員一般用臨時(shí)變量向一個(gè)方法傳遞數(shù)據(jù)或者從一個(gè)方法返回?cái)?shù)據(jù). 第一部分探討了臨時(shí)對(duì)象是怎樣給一個(gè)程序的性能帶來負(fù)面的沖擊, 以及一些類接口的設(shè)計(jì)思想怎樣提供了臨時(shí)對(duì)象的創(chuàng)建. 避免了那些接口的創(chuàng)建, 你就能極大地減少那些影響你的程序性能的臨時(shí)對(duì)象創(chuàng)建的需求,

　　只是對(duì) String 說不嗎?

　　當(dāng)它要?jiǎng)?chuàng)建臨時(shí)變量時(shí), String 類是最大的罪人中的一個(gè). 為了演示, 在第一部分我寫了一個(gè)正規(guī)表達(dá)式匹配的例子, 通過和一個(gè)類似的但是經(jīng)過仔細(xì)設(shè)計(jì)的接口相比較, 演示了看起來無害的接口是怎樣引起大量對(duì)象的創(chuàng)建, 而慢上幾倍. 這里是原來的和好一些的類的接口:

BadRegExpMatcher

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); }

BetterRegExpMatcher

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(); }

　　大量使用 BadREgExpMatcher 的程序比使用 BtterRegExpMatcher 的要慢好多. 首先,調(diào)用者不得不創(chuàng)建一個(gè) String 傳入 match(), 接著 match() 又創(chuàng)建了一個(gè) String 來返回匹配的文本. 結(jié)果是每次調(diào)用都有兩個(gè)對(duì)象創(chuàng)建, 看起來不多, 但是如果要經(jīng)常調(diào)用match(), 這些對(duì)象創(chuàng)建帶給性能的代價(jià)就太打了. BadRegExpMatcher 的性能問題不是在它的實(shí)現(xiàn)中, 而是它的接口; 象它定義的接口, 沒有辦法避免一些臨時(shí)變量的創(chuàng)建.

　　BetterRegExpMatcher 的 match() 用原類型(整數(shù)和字符數(shù)組)代替了 String 對(duì)象; 不需要?jiǎng)?chuàng)建中間對(duì)象來在調(diào)用者和 match() 之間傳遞信息.

　　既然在設(shè)計(jì)時(shí)候避免性能問題要比寫完整個(gè)系統(tǒng)以后再修改要容易一些, 你應(yīng)該注意你的類中控制對(duì)象創(chuàng)建的方法. 在 RegExpMatcher 的例子中, 它的方法要求和返回 String 對(duì)象, 就應(yīng)該為潛在的性能冒險(xiǎn)提個(gè)警告信號(hào). 因?yàn)?String 類是不可變的, 除了最常用以外, 所有的 String 參數(shù)在每次調(diào)用處理函數(shù)時(shí)都需要?jiǎng)?chuàng)建一個(gè)新的 String.

　　不可變性對(duì)于性能來說是否很壞?

　　因?yàn)?String 經(jīng)常和大量的對(duì)象創(chuàng)建聯(lián)系在一起, 一般來說歸咎于它的不可變性. 許多程序員認(rèn)為不可變的對(duì)象與生俱來對(duì)性能沒有好處. 但是, 事實(shí)多少會(huì)更復(fù)雜一些. 實(shí)際上, 不可變性有時(shí)候提供了性能上的優(yōu)勢(shì), 可變性的對(duì)象有時(shí)候?qū)е滦阅軉栴}. 不管可變性對(duì)性能來說有幫助或者有害, 依賴于對(duì)象是怎么使用的.

　　程序經(jīng)常處理和修改文本字符串 -- 和不可變性非常不匹配. 每次你想處理一個(gè) String --想查找和解析出前綴或者子串, 變小寫或者大寫, 或者把兩個(gè)字符串合并 -- 你必須創(chuàng)建一個(gè)新的 String 對(duì)象. (在合并的情況下, 編譯器也會(huì)隱藏地創(chuàng)建一個(gè) StringBuffer() 對(duì)象)

　　另一個(gè)方面, 一個(gè)不可變的對(duì)象的一個(gè)引用可以自由共享, 而不用擔(dān)心被引用的對(duì)象要被修改, 這個(gè)比可變對(duì)象提供性能優(yōu)勢(shì), 就象下一節(jié)例子所說的.

　　可變的對(duì)象有它們自己的臨時(shí)對(duì)象問題.

　　在 RegExpMatcher 的例子中, 你看見了 當(dāng)一個(gè)方法返回一個(gè) String 類型時(shí), 它通常需要新建一個(gè) String 對(duì)象. BadRegExpMatcher 的一個(gè)問題就是 match() 返回一個(gè)對(duì)象而不是一個(gè)原類型 -- 但是只因?yàn)橐粋€(gè)方法返回一個(gè)對(duì)象, 不意味著必須有一個(gè)新對(duì)象創(chuàng)建. 考慮一下 java.awt 中的幾何類, 象 Point 和 Rectangle. 一個(gè) Rectangle只是四個(gè)整數(shù)(x, y, 寬度, 長度)的容器. AWT Component 類存儲(chǔ)組件的位置, 通過getBounds()作為一個(gè)Rectangle 返回

public class Component { ? ... ? public Rectangle getBounds(); }

　　在上面的例子中, getBounds() 只是一個(gè)存儲(chǔ)元 -- 它只使一些 Component 內(nèi)部的一些狀態(tài)信息可用. getBounds() 需要?jiǎng)?chuàng)建它返回的 Rectangle 嗎? 可能. 考慮一下下面getBounds() 可能的實(shí)現(xiàn).

public class Component { ? ... ? protected Rectangle myBounds; ? public Rectangle getBounds()? { return myBounds; } }

　　當(dāng)一個(gè)調(diào)用者調(diào)用上面例子中的 getBounds(), 沒有新對(duì)象創(chuàng)建 -- 因?yàn)榻M件已經(jīng)知道它在哪里 -- 所以 getBounds() 效率很高. 但是 Rectangle 的可變性又有了其他問題. 當(dāng)一個(gè)調(diào)用者運(yùn)行一下程序會(huì)發(fā)生什么呢?

? Rectangle r = component.getBounds(); ? ... ? r.height *= 2;

　　因?yàn)?Rectangle 是可變的, 它在 Component 不知道的情況下使 Component 移動(dòng). 對(duì)象AWT 這樣的 GUI 工具箱來說, 這是個(gè)災(zāi)難,? 因?yàn)楫?dāng)一個(gè)組件移動(dòng)以后, 屏幕需要重繪, 件監(jiān)聽器需要被通知, 等等. 所以上面的實(shí)現(xiàn) Component.getBounds() 的代碼看起來很危險(xiǎn). 一個(gè)安全一點(diǎn)的實(shí)現(xiàn)就象下面這樣:

? public Rectangle getBounds() { ??? return new Rectangle(myBounds.x, myBounds.y, ???????????????????????? myBounds.height, myBounds.width); ? }

　　但是現(xiàn)在, 每一個(gè) getBounds() 的調(diào)用都創(chuàng)建一個(gè)新對(duì)象, 就象 RegExpMatcher 一樣.實(shí)際上, 下面的代碼片段創(chuàng)建了 4 個(gè)臨時(shí)對(duì)象:

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

　　在 String 的情況中, 對(duì)象創(chuàng)建是必要的, 因?yàn)?String 是不可變的. 但在這個(gè)例子中,對(duì)象的創(chuàng)建也是必要的, 因?yàn)?Rectangle 是可變的. 我們使用 String 避免了這個(gè)問題,在我們的接口中沒有使用對(duì)象. 雖然在 RegExpMatcher 的情況下很好, 這個(gè)方法不總是可行的或者是希望的. 幸運(yùn)的是, 你可以在實(shí)際類的時(shí)候可以使用一些技巧, 來免除太多小對(duì)象的問題, 而不是完全避免小對(duì)象.

　　減少對(duì)象的技巧 1: 加上好的存取函數(shù)

　　在 Swing 工具箱的初始版本中, 對(duì)象小對(duì)象的臨時(shí)創(chuàng)建, 象 Point, Rectangle 和 Dimension極大地阻礙了性能. 把它們放在一個(gè) Point 或者 Rectangle 中來一次返回多個(gè)值, 看起來更有效, 實(shí)際上, 對(duì)象的創(chuàng)建比多個(gè)方法調(diào)用代價(jià)更高. 在 Swing 的最后發(fā)布之前, 通過給 Component 和其他一些類加一些新的存取方法, 問題就簡(jiǎn)單地解決了, 就象下面這樣:

? public int getX()????? { return myBounds.x; } ? public int getY()????? { return myBounds.y; } ? public int getHeight() { return myBounds.height; } ? public int getWidth()? { return myBounds.width; }

　　現(xiàn)在一個(gè)調(diào)用者可以這樣獲取邊界而不用創(chuàng)建對(duì)象:

? int x = component.getX(); ? int y = component.getY(); ? int h = component.getHeight(); ? int w = component.getWidth();

　　getBounds() 的舊形式仍然支持; 好的存取方法簡(jiǎn)單地提供了有效的方法來達(dá)到相同的目的. 結(jié)果是, Rectangle 的接口全部在 Component 中使用. 當(dāng)修改 Swing 包支持和使用這樣的存取函數(shù)后, 在許多 Swing 操作中比以前要快到兩倍. 這很好, 因?yàn)?GUI 代碼非常注意性能 -- 用戶等待發(fā)生一些事, 希望 UI 操作瞬間完成.

　　使用這個(gè)技術(shù)不好的地方就是你的對(duì)象提供了更多的方法, 有多于一個(gè)的方法來得到相同的信息, 就使文檔更大更復(fù)雜, 可能使用戶害怕. 但是就象 Swing 的例子顯示的, 在關(guān)注性能的情況下, 這樣的優(yōu)化技術(shù)是有效的.

　　技巧 2: 利用可變性

　　除了給 Component 加上原類型的存儲(chǔ)函數(shù) -- 象上面討論的 getX() 函數(shù) -- 以外, Java 2 在 AWT 和 Swing 中也使用了另一種技術(shù)來減少對(duì)象創(chuàng)建, 允許一個(gè)調(diào)用者把邊界作為一個(gè) Rectangle 得到, 但是不需要任何臨時(shí)對(duì)象的創(chuàng)建.

? public Rectangle getBounds(Rectangle returnVal) { ??? returnVal.x = myBounds.x; ??? returnVal.y = myBounds.y; ??? returnVal.height = myBounds.height; ??? returnVal.width = myBounds.width; ??? return returnVal; ? }

　　調(diào)用者仍然需要?jiǎng)?chuàng)建一個(gè) Rectangle 對(duì)象, 但它可以在后來的調(diào)用中重用. 如果一個(gè)調(diào)用者在一系列的 Component 中循環(huán), 可以只創(chuàng)建一個(gè) Rectangle 對(duì)象, 在每個(gè) Component 中重用. 注意這個(gè)技術(shù)只用于可變性對(duì)象; 你不能用這種方法消除 String 的創(chuàng)建.

　　技巧 3: 得到兩個(gè)中的最好的.

　　一個(gè)解決在簡(jiǎn)單類(象 Point 之類)的對(duì)象創(chuàng)建的問題, 更好的方法是使 Point 對(duì)象不可? 但是定義一個(gè)可變的子類, 就象下面這樣:

? 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 可以安全返回一個(gè) myLocation 的引用, 因?yàn)檎{(diào)用者試圖修改域或者調(diào)用設(shè)置函數(shù)會(huì)失敗. (當(dāng)然, 調(diào)用者仍然可以把 Point 轉(zhuǎn)換為 MutablePoint, 但這明顯不安全, 這樣的調(diào)用者可能得到他們想要的) C++ 程序員可能注意到了這個(gè)技巧很象 C++ 中返回一個(gè) Rectangle 的常量引用(cong Rectangle&) -- 一個(gè) Java 不支持的特點(diǎn).

　　這個(gè)技巧 -- 返回一個(gè)具有可變的和不可變的類, 只允許讀的對(duì)象, 而不創(chuàng)建新對(duì)象 --在 Java 1.3 類庫 java.math.BigInteger 類中使用. MutableBigInteger 類不可見 --它是一個(gè)只在 java.math 類庫中內(nèi)部使用的私有類型. 但是既然 BigInteger 的一些方法(象 gcd()) 在許多數(shù)學(xué)操作中都有, 在一個(gè)地方操作比創(chuàng)建上百個(gè)臨時(shí)變量性能提高非常大.

　　結(jié)論

　　所有的性能優(yōu)化的建議中, 值得記住的是有許多程序的性能可以完全接受的情況. 在這些情況下, 不值得犧牲可讀性, 可維護(hù)性, 抽象, 或者其他可取的程序?qū)傩詠慝@得性能. 但是, 既然許多性能問題的種子在設(shè)計(jì)時(shí)就種下了, 要注意到設(shè)計(jì)思想潛在地對(duì)性能的沖?當(dāng)你設(shè)計(jì)的類在關(guān)注性能的情況***使用, 你可以有效地使用這里提到的技巧來減少臨時(shí)對(duì)象的創(chuàng)建,

　　在第三部分中, 我將看看分布式的應(yīng)用程序中特有的性能問題, 怎樣在設(shè)計(jì)時(shí)候找出和消除它們。

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.