Java 編譯器對 String 常量表達式的極致優化：原理、實證與邊界

經典面試題：String a = "ab"; String b = "a" + "b"; 打印什麼？

三類典型回答：

1. true（新手）：以為內容相等即引用相等。
2. false（進階）：知 + 產生新對象，== 比較引用。
3. true（高手）：知常量池機制，"a"+"b" 編譯期優化為 "ab"，複用池中對象。

第 3 類最接近真相，但理由略有偏差——根本不存在運行期 "a"+"b" 拼接操作。

鐵證如山：Class 文件二進制對比

// 版本 A
private String a = "aa";
// 版本 B
private String a = "a" + "a";

編譯後用十六進制編輯器對比 .class 文件，**完全逐字節一致**。證明編譯器在編譯期直接將 "a"+"a" 常量折疊為 "aa"，運行期只見 ldc "aa" 指令。

常量表達式優化的邊界探測

深層機制：JLS 規範與 String 的特殊地位

Java 語言規範（JLS）將 String 視為「準基本類型」：

• 常量表達式定義：僅由字面量、final 常量變量、基本類型運算組成，編譯器必須編譯期求值。
• + 運算符重載：Java 唯一的運算符重載，專供 String 拼接，編譯器將其降級為 StringBuilder.append() 或直接常量折疊。
• 字符串常量池：類加載時將編譯期常量駐留，String.intern() 可手動入池。

實戰啟示

1. 大量字面量拼接**無性能損耗**，編譯器已優化。
2. 循環/變量拼接**必用 StringBuilder**，避免產生大量中間對象觸發 GC。
3. final 修飾引用類型僅保證引用不變，**不保證對象內容不變**，編譯器優化依賴「值不可變」的語義推導。

Java 對 String 的優化可謂「到了極點」——從語法糖、常量池到 JIT 內聯，將一個普通對象打造成接近基本類型的高性能數據類型。