減少 Java 臨時物件建立，從設計階段提升效能

許多 Java 效能問題的種子，早在類設計階段就已埋下。Brian Goetz 指出：大量短命臨時物件會拖垮 GC、增加記憶體壓力，且往往源於介面設計不當。本文整理三大減少物件建立的實戰技巧，助你在寫下第一行程式碼前就避開效能陷阱。

為什麼臨時物件會傷效能？

• GC 壓力：短命物件填滿 Young Generation，觸發頻繁 Minor GC。
• 記憶體頻寬：分配、初始化、複製、回收都消耗頻寬。
• 快取污染：大量臨時物件擠走熱點資料，降低 CPU 快取命中率。

元兇：String 介面設計

經典反面教材 BadRegExpMatcher：

public class BadRegExpMatcher {
    public BadRegExpMatcher(String regExp);
    public String match(String inputText);  // 回傳新 String
}

每次呼叫 match() 至少產生兩個 String 物件（參數 + 回傳值），高頻呼叫時效能崩盤。

改良版 BetterRegExpMatcher 以基本型別與陣列取代 String：

class 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();  // 僅在需要時建立 String
}

呼叫端可重用 char[]，完全避免中間物件。

技巧 1：提供基本型別存取子

Swing 早期版本回傳 Rectangle、Point 等小物件，導致大量臨時分配。解法：新增 getX()、getY()、getWidth()、getHeight() 等 int 存取子。

// 呼叫端不再需要建立 Rectangle
int x = component.getX();
int y = component.getY();
int w = component.getWidth();
int h = component.getHeight();

此優化讓 Swing 許多操作快近兩倍。代價是 API 膨脹，但效能敏感場合值得。

技巧 2：利用可變物件「傳入重用」

為相容舊 API，提供 getBounds(Rectangle dest) 讓呼叫端重用同一 Rectangle 實例：

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

呼叫端在迴圈中只建立一次 Rectangle，反覆重用。注意：此技巧僅適用可變物件，String 等不可變類別無法使用。

技巧 3：不可變介面 + 可變內部實作

對外暴露不可變介面（Point），內部持有可變子類別（MutablePoint）：

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 = new MutablePoint(0, 0);
    public Point getLocation() { return myLocation; }  // 安全回傳不可變視圖
}

• 呼叫端拿到 Point，無法修改內部狀態（編譯期保護）。
• 內部持有 MutablePoint，可高效就地更新座標，零分配。
• java.math.BigInteger 即採此模式，內部用 MutableBigInteger 加速大整數運算。

不可變 vs 可變：效能權衡

結語

效能優化不應犧牲可讀性與維護性，但設計階段的介面選擇往往決定物件分配量級。記住三原則：

1. 熱點路徑優先用基本型別/陣列，避免物件包裝。
2. 必要時提供「傳入重用」多載方法。
3. 對外不可變、內部可變，兼顧封裝與效能。

在寫下 public String foo(String...) 之前，先問自己：這裡真的需要新物件嗎？

1. 上一篇文章： Java 繼承機制深度解析：super 呼叫、欄位遮蔽與建構子鏈
2. 下一篇文章： Java GC 核心原理與調優實戰：從可達性分析到引用類型應用

Java 相關知識

精通 Grails：開發自訂插件實戰——ShortenUrl 縮網址服務

Grails 鼓勵各層面的程式碼重用：微觀層面有局部模板、T

Java 6 線程優化實戰測試：深度驗證與多核心效能分析 (下)

承接上篇，本文將針對 Java 6 鎖優化 (偏向鎖、鎖粗化

Struts 從零開始 (五)：資料驗證完整指南 (手動驗證與 Validator 框架)

一、ActionForm 手動表單驗證 validate(

RAP 與 RCP 架構差異深度解析：從 Eclipse 插件到 Web 應用

Eclipse 生態系中的 RAP (Rich Ajax P