#反射的性能问题与优化

// 反射调用的每一次 invoke() 都要经过：
// 1. 参数类型检查
// 2. 访问权限检查（setAccessible）
// 3. 参数装箱（基本类型 → Object[]）
// 4. 参数拆箱（Object[] → 基本类型）
// 5. 结果装箱（Object → 基本类型）
// 6. 异常包装
// 7. JIT 无法内联

// 普通调用：
// 直接 CPU 指令执行

// 反射第一次调用时：
// JVM 不是直接用 native 方法，而是用 Java 层包装
// 创建一个 NativeMethodAccessorImpl
// 如果调用次数超过阈值（默认 15 次），切换到字节码生成的 Accessor

// 源码逻辑（MethodAccessorGenerator）：
// 调用次数 < 15：使用 NativeMethodAccessorImpl
// 调用次数 >= 15：生成字节码 Accessor（更快）

// 实际效果：
// 前 15 次调用：慢（native 层）
// 第 15 次之后：快（字节码生成的 Accessor）
// 但仍然比直接调用慢 5-10x

// JDK 17+: 不再有 Inflation 切换
// 直接使用字节码生成的 Accessor
// 但 setAccessible 仍然有额外开销

// ❌ 每次调用都反射查找
public void process(Object target) {
    Method method = target.getClass().getMethod("doWork"); // 每次查找！
    method.invoke(target);
}

// ✅ 缓存 Method 对象
private static final Map<Class<?>, Method> METHOD_CACHE = new ConcurrentHashMap<>();

public void process(Object target) {
    Class<?> cls = target.getClass();
    Method method = METHOD_CACHE.computeIfAbsent(cls,
        c -> {
            try {
                return c.getMethod("doWork");
            } catch (NoSuchMethodException e) {
                throw new ReflectionException(e);
            }
        });
    method.invoke(target);
}

// MethodHandle（JDK 7+）比反射快 10x
// MethodHandle 是"类型安全的引用"，类似于虚方法表的直接引用

public class MethodHandleInvoker {
    private final MethodHandle handle;

    public MethodHandleInvoker(Class<?> cls, String methodName, Class<?>... paramTypes)
            throws NoSuchMethodException, IllegalAccessException {
        this.handle = MethodHandles.lookup()
            .findVirtual(cls, methodName,
                MethodType.methodType(void.class, paramTypes));
    }

    public Object invoke(Object receiver, Object... args) throws Throwable {
        return handle.bindTo(receiver).invokeWithArguments(args);
    }
}

// ❌ 每次都 setAccessible
Method m = cls.getDeclaredMethod("doWork");
m.setAccessible(true); // 每次都遍历调用栈检查安全管理器

// ✅ 只 setAccessible 一次，配合缓存
private static final Map<Member, Boolean> ACCESS_CACHE = new ConcurrentHashMap<>();

public static void makeAccessible(Member member) {
    if (!ACCESS_CACHE.computeIfAbsent(member, m -> {
        if (!m.isAccessible()) {
            m.setAccessible(true);
            return true;
        }
        return false;
    })) {
        // 已经设置过了
    }
}

// JDK 8+: 使用 LambdaMetafactory 将反射调用"内联"为方法引用
// MyBatis 3.8+ 的实现

public interface MethodInvoker {
    Object invoke(Object target, Object... args) throws Throwable;
}

// 创建一个"看起来像普通接口调用"的包装
public static MethodInvoker createMethodInvoker(Method method) {
    if (method.getParameterCount() == 0) {
        return (target, args) -> method.invoke(target);
    }
    return method::invoke; // Lambda 表达式，JIT 可以优化
}

// Spring 的 BeanWrapper 使用 CachedIntrospectionResults
// 内部结构：
class CachedIntrospectionResults {
    // 缓存 PropertyDescriptor（包含 getter/setter/field）
    private final Map<String, PropertyDescriptor> propertyDescriptorCache;

    // Spring 缓存的是 PropertyDescriptor，而非原始 Method
    // PropertyDescriptor 已经包含了优化后的方法引用
}

// 使用时直接调用缓存好的 accessor，不需要每次反射
BeanWrapper bw = new BeanWrapperImpl(bean);
bw.setPropertyValue("name", "Alice"); // 内部使用缓存的 set 方法

// Jackson 的 ObjectMapper
// 为了性能，使用了大量的反射优化技巧：
// 1. 生成字节码（ASM）动态创建反序列化器
// 2. 缓存所有 accessor
// 3. 使用 @JsonIgnore 过滤不必要的字段

// 即使这样，JSON 反序列化仍然是 CPU 密集型操作
// 高 QPS 服务中，JSON 反序列化占 CPU 时间的 20-30%

// MyBatis 的 SQL 执行流程中的反射优化：
// 1. ResultSetHandler 使用 TypeHandlerRegistry
// 2. 每个 JDBC Type 映射到一个 TypeHandler
// 3. TypeHandler 内部使用反射设置字段
// 4. 所有 TypeHandler 在启动时一次性初始化并缓存

// MyBatis Plus（MyBatis 的增强库）进一步优化：
// 使用 JSqlParser 生成特定类型的 Setter
// 避免运行时反射

// sun.misc.Unsafe 的直接内存访问
import sun.misc.Unsafe;
Field f = Unsafe.class.getDeclaredField("theUnsafe");
f.setAccessible(true);
Unsafe unsafe = (Unsafe) f.get(null);

// 直接设置字段（无需 getter/setter，无需反射）
unsafe.putObject(obj, offset, value); // 比反射快 3-5x