Java反射支撑EventBus事件分发，通过扫描@Subscribe方法、建立EventClass到Method的映射、动态invoke执行回调；需处理setAccessible、异常展开及泛型擦除问题。
Java 反射是实现通用事件总线消息分发的核心技术之一，它让 EventBus 能在运行时动态识别、匹配并调用任意订阅方法，无需编译期绑定。
反射如何支撑事件分发流程
事件总线（如 Guava EventBus 或自研轻量实现）依赖反射完成三件事：扫描订阅方法、建立类型映射、触发回调执行。整个过程不硬编码类名或方法名，靠 Class 对象和 Method 对象驱动。
- 注册阶段：通过 Class.getDeclaredMethods() 扫描所有带
@Subscribe注解的方法，再用 method.getParameterTypes()[0] 提取其唯一参数类型——即该方法关心的事件类型 - 映射阶段：将
EventClass → List<Method>存入 ConcurrentHashMap，支持 O(1) 查找；同一事件类型可被多个类的多个方法监听 - 分发阶段：收到事件对象后，获取其
event.getClass()，查出所有匹配的 Method，再用 method.invoke(subscriberInstance, event) 完成调用
关键反射操作与安全注意事项
直接用反射调用方法看似简单，但实际需处理访问权限、异常、泛型擦除等细节：
JavaStoryDevelop
下载
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
- 调用前必须 method.setAccessible(true)，否则 private/protected 方法无法触发（尤其当订阅者是内部类或工具类时）
- 捕获
InvocationTargetException并展开其 cause，避免业务异常被反射层吞掉；建议统一包装为EventDispatchException向上抛或记录 - 注意泛型擦除：若事件定义为
OrderEvent<String>，反射拿到的仍是OrderEvent.class，无法区分泛型参数；需配合运行时类型检查或改用泛型事件总线设计（如Event<T>+ TypeReference）
为什么不用纯接口或策略模式替代反射
反射带来灵活性，但也引入运行时开销与调试难度。但它不可替代的原因在于：
立即学习“Java免费学习笔记（深入）”；
- 订阅者完全自由：任意 POJO 类只要有一个参数为事件类型的 public 方法，就能成为订阅者，无需实现特定接口或继承基类
- 零侵入注册：Spring 中可通过
@PostConstruct自动扫描并注册所有@Subscribe方法，开发者只写逻辑，不写胶水代码 - 天然支持多态分发：若发布
PaymentCompletedEvent，而某方法参数是其父类OrderEvent，反射结合isAssignableFrom可自动向上匹配，实现“一类事件、多种粒度响应”
性能优化的实际做法
高频调用场景下，反射确实比直接方法调用慢。但可通过以下方式收窄差距：
- 缓存 Method 对象：避免每次 post 都重复
getDeclaredMethods和遍历；注册时解析一次，存入 subscriber 的元数据中 - 预编译 MethodHandle（Java 7+）：比反射快 3–5 倍，适合长期稳定订阅关系的场景；用
MethodHandles.lookup().unreflect(method)获取 - 跳过安全检查：JVM 启动加
-Dsun.reflect.noInflation=true，强制使用 native 实现而非字节码生成，减少首次调用延迟
