前陣子做一個ORM框架，用反射實現實體類和數據庫字段的映射，結果壓測時發現反射調用比直接調用慢了20倍，直接拖累了整個框架的性能。後來花了三天時間優化，把反射耗時降到了接近直接調用的水平——原來反射性能差不是不能解決，只是需要找對方法。

Java反射雖然靈活（能在運行時操作類和方法），但因為要繞過編譯期檢查、動態解析類信息，默認情況下性能確實不盡如人意。不過通過合理的緩存策略和API選型，完全能把性能損失控制在可接受範圍。本文結合實際項目經驗，分享一套從慢到快的反射優化方案。

一、先看差距：反射到底有多慢？

先做個簡單測試：調用一個普通方法100萬次，對比直接調用和反射調用的耗時：

public class ReflectionPerfTest {
    // 普通方法
    public int add(int a, int b) {
        return a + b;
    }

    public static void main(String[] args) throws Exception {
        ReflectionPerfTest obj = new ReflectionPerfTest();
        int iterations = 1_000_000;

        // 直接調用
        long directStart = System.currentTimeMillis();
        for (int i = 0; i < iterations; i++) {
            obj.add(1, 2);
        }
        long directTime = System.currentTimeMillis() - directStart;

        // 反射調用（未優化）
        Method addMethod = ReflectionPerfTest.class.getMethod("add", int.class, int.class);
        long reflectStart = System.currentTimeMillis();
        for (int i = 0; i < iterations; i++) {
            addMethod.invoke(obj, 1, 2);
        }
        long reflectTime = System.currentTimeMillis() - reflectStart;

        System.out.println("直接調用耗時：" + directTime + "ms");
        System.out.println("反射調用耗時：" + reflectTime + "ms");
        System.out.println("性能差距：" + (reflectTime / directTime) + "倍");
    }
}

測試結果（JDK 11）：

直接調用耗時：3ms
反射調用耗時：68ms
性能差距：22倍

可見未優化的反射確實慢很多，主要原因有兩個：

  1. Method.invoke()需要進行參數類型檢查、自動裝箱拆箱；
  2. 每次調用都要經過安全管理器校驗（如果開啓）。

二、初級優化：緩存反射對象

反射中最耗時的操作不是invoke()，而是獲取Class、Method、Field這些元對象的過程（比如getMethod()）。這些對象一旦獲取，本質上是不變的，完全可以緩存起來複用。

用HashMap手動緩存

public class ReflectCache {
    // 緩存Method對象：key為"類名#方法名#參數類型"
    private static final Map<String, Method> methodCache = new ConcurrentHashMap<>();

    // 獲取方法（帶緩存）
    public static Method getCachedMethod(Class<?> clazz, String methodName, Class<?>... paramTypes) throws NoSuchMethodException {
        String key = clazz.getName() + "#" + methodName + Arrays.toString(paramTypes);
        // 先查緩存，沒有再創建
        if (!methodCache.containsKey(key)) {
            Method method = clazz.getMethod(methodName, paramTypes);
            methodCache.put(key, method);
        }
        return methodCache.get(key);
    }
}

優化後測試反射調用：

// 使用緩存的反射調用
Method cachedMethod = ReflectCache.getCachedMethod(ReflectionPerfTest.class, "add", int.class, int.class);
long cachedReflectStart = System.currentTimeMillis();
for (int i = 0; i < iterations; i++) {
    cachedMethod.invoke(obj, 1, 2);
}
long cachedReflectTime = System.currentTimeMillis() - cachedReflectStart;

結果：

緩存後反射調用耗時：52ms
性能差距：17倍（比未緩存提升約23%）

雖然還是慢，但緩存已經起作用了。對於頻繁反射的場景（如ORM、JSON解析），這是必須做的基礎優化。

三、中級優化：突破Method.invoke()的限制

Method.invoke()的性能瓶頸在於每次調用都要做參數校驗和類型轉換。JDK提供了兩種方式繞過這些檢查：

1. 關閉訪問檢查（setAccessible(true)）

默認情況下，反射會檢查方法的訪問權限（比如private方法），調用setAccessible(true)可以關閉這個檢查，提升性能：

Method method = clazz.getMethod("add", int.class, int.class);
method.setAccessible(true); // 關閉訪問檢查

加上這行代碼後再測試：

關閉訪問檢查後耗時：35ms
性能差距：11倍（比緩存後再提升33%）

注意：這只是關閉反射的訪問檢查，不會改變方法本身的權限（比如private方法依然不能被外部直接調用），不用擔心安全問題。

2. 使用MethodHandle（JDK 7+）

MethodHandle是JDK 7引入的低級別反射API，性能接近直接調用，適合對性能要求高的場景：

import java.lang.invoke.MethodHandle;
import java.lang.invoke.MethodHandles;
import java.lang.invoke.MethodType;

public class MethodHandleTest {
    public static void main(String[] args) throws Throwable {
        ReflectionPerfTest obj = new ReflectionPerfTest();
        int iterations = 1_000_000;

        // 獲取MethodHandle
        MethodHandles.Lookup lookup = MethodHandles.lookup();
        MethodType methodType = MethodType.methodType(int.class, int.class, int.class);
        MethodHandle addHandle = lookup.findVirtual(ReflectionPerfTest.class, "add", methodType);

        // 調用MethodHandle
        long handleStart = System.currentTimeMillis();
        for (int i = 0; i < iterations; i++) {
            // 第一個參數是調用對象，後面是方法參數
            addHandle.invokeExact(obj, 1, 2);
        }
        long handleTime = System.currentTimeMillis() - handleStart;
        System.out.println("MethodHandle調用耗時：" + handleTime + "ms");
    }
}

測試結果：

MethodHandle調用耗時：8ms
性能差距：2.6倍（比setAccessible再提升77%）

MethodHandle性能好的原因是：它在編譯期就確定了方法簽名，invokeExact()要求參數類型完全匹配，避免了Method.invoke()的動態類型檢查。但缺點是使用更復雜，參數類型不匹配會直接拋異常。

四、高級優化：生成字節碼替代反射

如果還想進一步提升，可以在運行時動態生成字節碼（比如用ASM或CGLIB），本質是創建一個代理類，把反射調用變成直接調用。

用CGLIB生成代理類

CGLIB通過繼承目標類生成代理，調用方法時直接執行字節碼，完全避開反射：

import net.sf.cglib.proxy.Enhancer;
import net.sf.cglib.proxy.MethodInterceptor;

public class CglibProxy {
    // 生成代理對象
    public static <T> T createProxy(T target) {
        Enhancer enhancer = new Enhancer();
        enhancer.setSuperclass(target.getClass());
        enhancer.setCallback((MethodInterceptor) (obj, method, args, proxy) -> {
            // 這裏可以添加額外邏輯，直接調用時返回proxy.invokeSuper
            return proxy.invokeSuper(obj, args);
        });
        return (T) enhancer.create();
    }
}

測試代理調用性能：

// CGLIB代理調用
ReflectionPerfTest proxyObj = CglibProxy.createProxy(obj);
long proxyStart = System.currentTimeMillis();
for (int i = 0; i < iterations; i++) {
    proxyObj.add(1, 2); // 看似直接調用，實際是代理類的字節碼
}
long proxyTime = System.currentTimeMillis() - proxyStart;

結果：

CGLIB代理調用耗時：5ms
性能差距：1.6倍（接近直接調用）

這種方式性能最好，但實現複雜，適合框架級開發。日常業務中，如果不是極端場景，MethodHandle已經足夠。

五、優化建議：不同場景選對方案

  1. 簡單場景：用setAccessible(true) + 緩存，性價比最高；
  2. 高性能場景：用MethodHandle，平衡性能和複雜度；
  3. 極致性能場景：用CGLIB/ASM生成字節碼，適合ORM、序列化等底層框架；
  4. 避免頻繁反射：能在啓動時初始化的反射操作（如類掃描），就不要放到運行時循環裏。

總結

反射性能優化的核心思路是：減少動態檢查 + 複用反射對象 + 用更低級API替代。實際項目中，除非是高頻調用（每秒上萬次），否則不必過度優化——畢竟反射的靈活性價值往往大於性能損失。

我的經驗是：先寫清晰的反射代碼，再通過壓測找到性能熱點，最後針對性優化。就像開頭那個ORM框架，最終只對高頻調用的字段訪問做了MethodHandle改造，既解決了性能問題，又沒增加太多複雜度。記住：優化是為業務服務的，不是為了炫技。