关于“动态代理”可能是一个被讲烂了的词，但无论是基于纯源码分析的，还是基于纯讲故事的，看过的太多，记住的太少。直到我尝试着手写一个RPC框架时，不经意发现对它的理解又更深了一点。
RPC框架要完成的，是实现像调用本地方法一样获得远程执行的结果。
IHelloService helloService = RpcClient.getRemoteInstanceProxy(IHelloService.class);
String msg = helloService.sayHi("world");
//- 返回：Hello, world!
实际上getRemoteInstanceProxy返回的是一个实现了IHelloService接口的“傀儡”实例：底层通过Socket通信把方法名、参数等发送给IHelloService真正的服务提供者（Server/Provider）。服务提供者得到结果后，再通过Socket把结果发送给服务消费者（Client/Consumer）。
“傀儡”实例基于动态代理实现，无非是对Socket通信进行了一层封装。
代理模式分为静态代理和动态代理。静态代理在编译时期产生.class，为IHelloService实现代理后，如果又有一个新接口，就必须再重新实现一次。对于框架来说显然是不可接受的，因此引出了动态代理，在运行时通过反射生成接口的“傀儡”实例。
最后的拓展阅读，推荐刘欣的两篇文章：
Java帝国之动态代理
从兄弟到父子：动态代理在民间是怎么玩的？
网友评论