1. 安全性：反射為何危險？
反射就像你程式的撬鎖工具：它能讓你闖進原本不該進入的地方。比如，藉由反射可以讀寫私有欄位、呼叫私有方法，甚至修改 final 欄位的值（沒錯，這些把戲辦得到，雖然不一定沒有後果）。
範例：繞過封裝
import java.lang.reflect.Field;
public class Secret {
private String secret = "這裡有祕密！";
public String getSecret() {
return secret;
}
}
public class ReflectionDemo {
public static void main(String[] args) throws Exception {
Secret s = new Secret();
Field field = Secret.class.getDeclaredField("secret");
field.setAccessible(true); // 打開 "門"
field.set(s, "已被破解！");
System.out.println(s.getSecret()); // 已被破解！
}
}
在一般情況下，私有欄位是受保護的，但帶有 setAccessible(true) 的反射會打破這道防護。這是一種超能力——同時也意味著巨大的責任。
SecurityManager 與限制
過去在 Java 中有一個 SecurityManager 機制，它能（例如在 applet 應用或伺服器上）限制反射的使用。但在 Java 17 中，SecurityManager 被標記為 deprecated for removal，而在 Java 21 已從平台中完全移除。
在現代 JVM 中，安全性以不同方式實作：透過模組化系統（Java 9+）與對內部類別的嚴格存取限制。
漏洞示例：修改 final 欄位
import java.lang.reflect.Field;
public class FinalDemo {
private final int number = 42;
public static void main(String[] args) throws Exception {
FinalDemo obj = new FinalDemo();
Field f = FinalDemo.class.getDeclaredField("number");
f.setAccessible(true);
f.set(obj, 99);
System.out.println(obj.number); // 42 (!)
System.out.println(f.get(obj)); // 99
}
}
欄位 number 的值其實不一定會如你「預期」那樣改變——編譯器與 JVM 可能會對 final 欄位做最佳化，結果可能會……出乎意料！這再次說明，反射不是魔杖，而更像是撬棍：有時有用，有時不行。
2. 反射的限制
效能損失
透過反射呼叫方法與存取欄位比一般呼叫慢。JVM 無法像對直接呼叫方法或欄位存取那樣好地最佳化。如果你在大型迴圈或熱路徑上透過反射呼叫方法——準備面對卡頓。
public class PerfDemo {
public void sayHello() {}
public static void main(String[] args) throws Exception {
PerfDemo obj = new PerfDemo();
long start = System.nanoTime();
for (int i = 0; i < 1_000_000; i++) {
obj.sayHello();
}
long direct = System.nanoTime() - start;
var method = PerfDemo.class.getMethod("sayHello");
start = System.nanoTime();
for (int i = 0; i < 1_000_000; i++) {
method.invoke(obj);
}
long reflect = System.nanoTime() - start;
System.out.printf("一般呼叫：%d 微秒\n", direct / 1000);
System.out.printf("透過反射：%d 微秒\n", reflect / 1000);
}
}
結果：反射通常會慢 10–100 倍！
型別安全性的喪失
反射處理的是 Object 型別，且需要手動轉型。錯誤（例如引數型別不正確）只會在執行期才暴露，而不是在編譯期。這提高了產生所謂「驚喜」與難以發現的 bug 的風險。
例外與 checked 錯誤
反射很愛拋例外：NoSuchFieldException、IllegalAccessException、InvocationTargetException 等。你必須捕捉它們，否則程式就會直接崩潰。
模組系統的限制
隨著 Java 的模組（module system）出現，對內部類別與私有成員的存取變得受限。如果你嘗試從另一個模組存取某類別的私有欄位，會得到 InaccessibleObjectException。
範例
// 在模組化應用程式中：
Field f = SomeClass.class.getDeclaredField("secret");
f.setAccessible(true); // java.lang.reflect.InaccessibleObjectException!
若要允許這種存取，必須明確開放套件（例如透過 JVM 參數：--add-opens），但這並非總是可行或安全。
3. 現代的反射替代方案
反射是一種只有在非用不可時才該用的工具。幸運的是，Java 語言與其生態系不斷演進，出現了許多新功能，讓多數情況下都能不靠反射完成工作。
Pattern Matching (Java 16+)
Pattern Matching 讓你能優雅地檢查並從物件中擷取值，而無需透過反射去「挖」它們的內部細節。
// instanceof 的 pattern matching 範例（Java 16+）
if (obj instanceof String s) {
System.out.println("這是字串，長度：" + s.length());
}
Sealed classes (Java 17+)
Sealed 類別允許明確限制繼承階層，讓程式碼分析更容易，並減少必須靠反射「猜測」結構的需求。
public sealed class Shape permits Circle, Rectangle {}
public final class Circle extends Shape {}
public final class Rectangle extends Shape {}
Record 類別 (Java 16+)
record 類別會自動產生建構子、getter、equals、hashCode 與 toString。藉此序列化與物件比較更簡單且更安全——多數情況下甚至不需要反射。
public record Point(int x, int y) {}
Annotation Processing (APT)
與其在執行期透過反射分析註解，不如在編譯期使用註解處理器（@SupportedAnnotationTypes 等）來產生所需程式碼。這更快也更安全。
使用介面、工廠與 DI
在許多過去會用反射以類名字建立物件的情境，更佳的做法是使用介面、工廠或 dependency injection 容器（例如 Spring）。這能建構彈性且可擴充的系統，而無需去「撬」類別。
4. 最佳實務：如何使用反射而不後悔
- 僅在非用不可時才使用反射。 例如：撰寫函式庫、框架、外掛、測試工具。
- 將使用範圍降到最低。 不要為了「以防萬一」就把所有欄位與方法都透過 setAccessible(true) 開放。
- 為反射的使用撰寫文件。 任何維運你程式碼的人都應知道你在哪裡、為何使用這個工具。
- 妥善處理所有 checked 例外。 別忽略它們——否則 bug 會在最不適合的時候爆發。
- 小心 final 欄位、私有與內部類別。 透過反射修改它們可能導致應用程式不穩定。
- 考量模組系統的限制。 如果你的應用程式運行在（Java 9+）模組化環境，請事先規劃各種對內部成員的存取情境。
- 不要把反射用在日常任務。 多半可用語言既有機制解決：介面、工廠、設計模式。
5. 實作：在模組化應用程式中存取私有欄位
讓我們嘗試在模組化應用程式中，透過反射存取另一個類別的私有欄位，看看會發生什麼。
程式碼範例
// module-info.java
module my.app {}
// SomeClass.java
package my.app;
public class SomeClass {
private String secret = "模組祕密";
}
// Main.java
package my.app;
import java.lang.reflect.Field;
public class Main {
public static void main(String[] args) throws Exception {
SomeClass obj = new SomeClass();
Field field = SomeClass.class.getDeclaredField("secret");
field.setAccessible(true); // java.lang.reflect.InaccessibleObjectException!
System.out.println(field.get(obj));
}
}
會發生什麼？
在 Java 17+（以及更高版本）你會得到例外：
Exception in thread "main" java.lang.reflect.InaccessibleObjectException:
Unable to make field private java.lang.String my.app.SomeClass.secret accessible:
module my.app does not "opens my.app" to unnamed module
如何修正?
明確為反射開放套件（例如透過 JVM 參數）：
--add-opens my.app/my.app=ALL-UNNAMED
或者（更好！）在能不用反射的地方就不要使用它。
6. 使用反射的常見錯誤與風險
錯誤 №1：不當使用 setAccessible(true)。
打開私有欄位的存取，就像為了從冰箱拿鑰匙而去撬自家門。只有在非常必要且理解後果時才這麼做。
錯誤 №2：忽視 checked 例外。
反射常拋出例外。不處理的話，應用程式可能突然崩潰。即便「在我這裡都能跑」——也不代表所有使用者都如此。
錯誤 №3：以為反射總會同樣運作。
模組系統、JVM 限制、不同版本的 Java 與啟動參數，都可能突然「弄壞」你的反射程式碼。
錯誤 №4：把反射用在常見日常任務。
若能用介面、工廠、DI 解決——就別用反射。它會增加複雜度並降低效能。
錯誤 №5：透過 final 欄位的修改來達成需求。
這可能導致與編譯器與 JVM 最佳化相關、出乎意料且難以捉摸的 bug。
GO TO FULL VERSION