dubbo源码学习3-dubbo反射调用服务源码分析

在上两节中，分别分享了
dubbo协议源码分析
服务提供方接入执行源码分析

最初以为dubbo的反射调用使用的只是JDK原生的反射调用方法，例如

    public static void main(String[] args) throws Exception {User user = new User();user.setAge(666);user.setName("张三");Class<? extends User> userClass = user.getClass();Method getName = userClass.getDeclaredMethod("getName");Object res = getName.invoke(user);System.out.println(res);}

后来想，这好像并不符合dubbo的高性能的定位，于是进行了深入研究
在dubbo启动过程中，通过代理工厂创建了 Invoker，该Invoker是执行反射调用的关键部分

在dubbo中通过SPI机制内置了三种代理工厂，如下图所示，默认的代理工厂是 JavassistProxyFactory，通过 javassist的动态字节码技术，创建代理对象

在 JavassistProxyFactory 创建Invoker的过程中，创建了AbstractProxyInvoker，抽象的代理对象执行器。同时通过 Wrapper 对目标对象的类型进行包装，其中proxy即是原始对象

在Wapper中，通过ClassGenerator 构建新类，新类的名称是原始类的类名 + DubboWrap
声明为 dubbo的包装类，以及使其继承了 Wrapper.class类，添加了默认的构造方法，添加了mns，dmns等属性

拦截了一些java的默认方法，获取属性，获取方法

        cc.addMethod("public String[] getPropertyNames(){ return pns; }");cc.addMethod("public boolean hasProperty(String n){ return pts.containsKey($1); }");cc.addMethod("public Class getPropertyType(String n){ return (Class)pts.get($1); }");cc.addMethod("public String[] getMethodNames(){ return mns; }");cc.addMethod("public String[] getDeclaredMethodNames(){ return dmns; }");

最关键的还是构造的生成类，重写了Wrapper 的 invokeMethod，根据传进的方法名，调用目标类的方法，例如 需要被代理的类型是 com.takemehand.dubbo.user.service.UserServiceImpl
$1 这是取得invokeMethod 方法的第一个参数，所以说，dubbo的反射调用实际上是通过动态字节码技术动态生成的类去调用实际类的实际方法，从而避免了JDK的反射调用

在反射调用时，实际调用的也是 Wrapper 的 invokeMethod 的方法，

通过观察调用堆栈，发现点击包装类 class com.takemehand.dubbo.user.service.UserServiceImplDubboWrap0是，并不能显示源码，因为该类是动态生成的，idea并不能查看其源码

在dubbo中另外一种JDK动态代理的实现，则是通过方法名和参数列表获取对应的Method，直接发起反射调用，相对比JDK的反射调用实际性能是非常低的

结论
dubbo服务提供方执行服务时，默认使用的 javassist的动态字节码技术，创建目标对象的包装类，由包装类去调用实际对象的对应方法，并不是使用JDK的反射调用技术
性能对比

维度	Javassist	JDK 反射
调用速度	生成的类与普通类性能相同，区别在于比普通类调用多一些if的方法名判断	比直接调用慢 10-20 倍
初始化开销	类生成时开销较大	首次反射调用开销较大
内存占用	需要维护生成的字节码	仅使用反射 API 无额外内存占用

性能说明：Javassist 生成的类在调用时没有反射开销，但类生成过程比反射调用更耗时，在需求高性能的应用场景中，初始化开销造成的项目启动时间变成，内存占用更多这两点都是可以接受的，反而是JDK反射调用性能差距，以及首次反射调用开销巨大的问题是高性能系统所不能接受的。