說明：dubbo-rcp包遠程調用模塊，抽象各種協議，以及動態代理，只包含一對一的調用，不關心集群的管理。

1：ConfigUtils.loadProperties()方法的242行，List進行new了2次。

2：疑惑transient聲明變量？

答案：總之，java 的transient關鍵字為我們提供了便利，你只需要實現Serilizable接口，將不需要序列化的屬性前添加關鍵字transient，序列化對象的時候，這個屬性就不會序列化到指定的目的地中。

3：dubbo-rpc模塊閱讀JavassistProxyFactory和JdkProxyFactory過程中遇到的阻力？

（1）javassit是一個開源的分析、編輯和創建Java字節碼的類庫，需要復習？？？

（2）java反射技術，需要復習？？？

（3）設計模式-之訪問者模式？？？

（4）動態代理、靜態代理區別？

A：靜態代理

說明：

當在代碼階段規定這種代理關系，Proxy類通過編譯器編譯成class文件，當系統運行時，此class已經存在了。這種靜態的代理模式固然在訪問無法訪問的資源，增強現有的接口業務功能方面有很大的優點，但是大量使用這種靜態代理，會使我們系統內的類的規模增大，并且不易維護；并且由于Proxy和RealSubject的功能 本質上是相同的，Proxy只是起到了中介的作用，這種代理在系統中的存在，導致系統結構比較臃腫和松散。

B：動態代理

說明：

代理類處理的邏輯很簡單：在調用某個方法前及方法后做一些額外的業務。換一種思路就是：在觸發（invoke）真實角色的方法之前或者之后做一些額外的業務。那么，為了構造出具有通用性和簡單性的代理類，可以將所有的觸發真實角色動作交給一個觸發的管理器，讓這個管理器統一地管理觸發。這種管理器就是Invocation Handler。動態代理模式的結構跟上面的靜態代理模式稍微有所不同，多引入了一個InvocationHandler角色。

先解釋一下InvocationHandler的作用：在靜態代理中，代理Proxy中的方法，都指定了調用了特定的realSubject中的對應的方法：在上面的靜態代理模式下，Proxy所做的事情，無非是調用在不同的request時，調用觸發realSubject對應的方法；更抽象點看，Proxy所作的事情；在Java中 方法（Method）也是作為一個對象來看待了，動態代理工作的基本模式就是將自己的方法功能的實現交給 InvocationHandler角色，外界對Proxy角色中的每一個方法的調用，Proxy角色都會交給InvocationHandler來處理，而InvocationHandler則調用具體對象角色的方法。如下圖所示：

區別：

在面向對象的編程之中，如果我們想要約定Proxy 和RealSubject可以實現相同的功能，有兩種方式：

?a.一個比較直觀的方式，就是定義一個功能接口，然后讓Proxy 和RealSubject來實現這個接口。

?b.還有比較隱晦的方式，就是通過繼承。因為如果Proxy 繼承自RealSubject，這樣Proxy則擁有了RealSubject的功能，Proxy還可以通過重寫RealSubject中的方法，來實現多態。

其中JDK中提供的創建動態代理的機制，是以a 這種思路設計的，而cglib 則是以b思路設計的。

（5）jdk動態代理機制？思考？？？

（6）cglib動態代理機制？思考？？？

（7）hessian的實現原理？？？扒一下源碼？？？

（8）apache httpClient的原理？？？扒一下源碼？？？

（9）RMI:遠程方法調用(Remote Method Invocation)？？？復習？？？博客地址：http://blog.csdn.net/a19881029/article/details/9465663

（10）了解Apache Thrift的實現原理？？？