Java性能設計

很多程序員在一開始並不注重性能的設計，只有當系統交付運行時，才 發現問題並且開始解決這一問題，但往往這隻能挽救一點點。性能的管理應該一開始 就被整合到設計和開發當中去。

最普遍的問題就是臨時對象大量經常的創建，這爲性能埋下隱患。

性能的問題來自很多原因，最容易解決的可能是：你選擇了不好的算法來進行計算，如 用冒泡法來排序巨量數據，或者你每次使用數據時都要反覆計算一次，這應該使用Cache。

你能很容易的使用工具(如Borland的Optimizeit)或壓力測試發現這些問題， 一旦發現，就能夠立即被糾正，但是很多Java的性能問題隱藏得更深，難於修改源碼就能糾正， 如程序組件的接口設計。

現在我們倡導面向對象的組件可複用設計，無疑這樣設計的優點是巨大的， 但是也要注意到對性能的影響。

一個java性能設計原則是，避免不必要的對象創建，對象的創建是非常耗時的， 所以你要避免不必要的臨時或過多的對象創建

String是程序中最主要創建的對象，因爲String是不變的，如果String長度被修改 將導致String對象再次創建，所以對性能有所注意的一般人就是儘量迴避使用String, 但是這幾乎是不可能的。



接口參數設計(ps:爲應付多種參數類型的轉換，重載是不不錯的選擇)

ot：
MailBot郵件系統的有一個Header數據，它是character buffer，需要對這個character buffer 進行分析比較，那麼你要做一個類Matcher，在這個類中你將Header數據讀入然後配比， 一個不好的做法是：

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

}

這個BadRegExpMatche要求入口參數是String ，那麼如果MailBot要調用他，必須自己做一個 character buffer到String的轉換：

BadRegExpMatcher dateMatcher = new BadRegExpMatcher(...);

while (...) { ...

//產生新的String
String headerLine = new String(myBuffer, thisHeaderStart, thisHeaderEnd-thisHeaderStart);

String result = dateMatcher.match(headerLine);

if (result == null) { ... }

}

很明顯，這裏這個由於接口不一致導致了多餘的對象String headerline的創建，這是不能允許的， 應該將Matcher的接口設計成能夠接納character buffer，當然爲通用性，也應該提供String的 接口參數：

class BetterRegExpMatcher {
　 public BetterRegExpMatcher(...);

　 /** 提供多個接口參數的match方法
　 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);

　 /** Get the next match against the input text, if any */
　 public int getNextMatch();

　 public int getMatchLength();

　 public String getMatchText();
}

很明顯BetterRegExpMatcher的運行速度將比前面BadRegExpMatcher運行速度快。

因爲在你已經寫好代碼的情況下，你比較難於更改一個類的接口參數，那就應該在寫程序之前多 多考慮你這些接口參數的類型設定，最好有一個通盤的接口類型規定。



減少對象的創建

臨時對象是那些有很短的生命週期，通常服務一些非十分有用的目標，程序員通常使用臨時對象作爲 數據混合包傳送或者返回，爲避免上述示例哪些轉換接口對象的構造，你應該巧妙的避免創造這些臨時 對象，以防止給你的程序留下性能的陰影。

上述示例說明性能問題在於String對象，但是String在對象創建中又是如此的普遍，String是不變的，一旦賦值，就不會變化，不少程序員 認爲不變的東西總是會導致壞的性能，其實它並不是這麼簡單，實際上，性能好壞在於你如何使用這個東西。

對於經常需要變化的String,很明顯使用Stringbuffer/SringBuilder來代替。

舉例：
看下面兩種實現：

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

和

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

當使用Component分別對應有如下兩種：

Rectangle r = component.getBounds();

...

r.height *= 2;

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

第一種使用方式缺點，r.height的使用已經脫離component，容易引起溝通上的誤解，因爲 Rectangle變化必須涉及component內容重新刷新，萬一其它程序員不知道這個規則，修改 r.height(乘2)，將不會去刷新component，(ps:傳回可變對象，是很怕的事情)

第二中方式是個提高，迫使componenet和其部件跟隨在一起。但是帶來問題是：創建了 四個臨時對象。

改進辦法是，在第一種的基礎上，在Commponent中增加

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

兩全其美了不是？

這就是減少創建對象技巧之一： 增加finer-grained輔助功能

第二種技巧是：Exploit mutability

上例還有一種實現方式：

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

}

多巧妙，把Rectangle作爲參數傳進來修改一下再送出去。

技巧3是 融合變和不變於一身。

總結上面一些例子，發現一個規律：臨時對象產生是在這種情況下產生的： 不變的要轉換成可變的。那麼針對這個根本原因我們設計出各取所需的方案。

以下例說明：

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



遠程接口

在分佈式應用中，性能也是相當重要的，這裏介紹如何通過檢查class的接口 能簡單預知分佈式應用中的性能問題。

在分佈式應用中，一個在這個系統中運行的對象能夠調用另外一個系統的對象的方法，這是通過很多 內部機制來實現將遠程對象貌似本地對象的，爲了發現遠程對象，你首先必須發現它，這是通過一種 名稱目錄服務機制，比如RMO的註冊，JNDO和CORBA的名稱服務。

當你通過目錄服務得到一個遠程的對象，你不是得到一個實際的指向，而是一個和遠程行爲一樣的stub對象的 指向， 當你調用stub對象的一個方法時，這個得marshal這個方法參數：也就是轉換成byte-stream，這類似 於序列化，這個stub對象通過網絡將marshal後的參數發送給skeleton對象，後者負責unmarshal這些參數然後 調用真正實際的你要調用的遠程方法，然後，這個方法返回一個值給skeleton，再逐個沿着剛纔路線返回, 一個簡單方法要做這麼多工作啊。

很顯然，遠程方法調用要比本地方法調用來得耗時昂貴。

上面返回情況是是指返回原始型primitive，如果返回的是對象，怎麼辦？如果這個對象支持遠程調用，它又會通過查詢創造一個stub和skeleton對象，這又是耗時的；如果這個對象不支持遠程調用，那麼所有的對象的字段和任何涉及引用的對象都要被marshal，這也是 相當耗時的。

由此可見，一個不好的遠程接口設計將完全扼殺程序的性能，爲了避免網絡開銷，設計一次 遠程調用返回多值總比多次調用，每次只返回一個值要好得多。

還有提防在不需要返回遠程對象時，返回一個遠程對象。不要傳遞很複雜不必要的對象給遠程。

假設遠程服務器有一個目錄列表對象，每個目錄項目中包含姓名 電話號碼 和郵件地址等值， 下列程序：

public interface Directory extends Remote {
　 DirectoryEntry[] getEntries();
　 void addEntry(DirectoryEntry entry);
　 void removeEntry(DirectoryEntry entry);

}

public interface DirectoryEntry extends Remote {
　 String getName();
　 String getPhoneNumber();
　 String getEmailAddress();

}

這樣設計導致結果是，當我需要一個姓名值時，首先要獲得Directory 對象，再獲得DirectoryEntry， 獲得DirectoryEntry才能獲得getName，這麼來來回回，需要多少次網絡開銷啊。

public interface Directory extends Remote {
　 String[] getNames();
　 DirectoryEntry[] getEntries();

　 //加入這個方法
　 DirectoryEntry getEntryByName(String name);
　 void addEntry(DirectoryEntry entry);
　 void removeEntry(DirectoryEntry entry);

}

這樣直接在Directory加上DirectoryEntry和getNames(),一次網絡開銷就全部解決。

當然這樣的解決方案是完全建立在對分佈式應用原理了解的基礎上。