亚洲国产中文在线二区三区免,国产AV无码专区亚洲AVJULIA,亚洲熟妇AV一区二区三区宅男

Tomcat �pȝ��架构与设计模式，�W?2 部分: 设计模式分析(�?

zhb8015 — Mon, 28 May 2012 09:58:00 GMT

原文地址�Q?br />

http://www.ibm.com/developerworks/cn/java/j-lo-tomcat2/

门面设计模式�?Tomcat 中有多处使用�Q�在 Request �?Response 对象��装中、Standard Wrapper �? ServletConfig ��装中、ApplicationContext �?ServletContext ��装中等都用��C��q�种设计模式�?/p>

门面设计模式的原�?/a>

�q�么多场合都用到了这�U�设计模式，那这�U�设计模式究竟能有什么作用呢�Q�顾名思义�Q�就是将一个东西封装成一个门面好与�h家更�Ҏ��q�行交流�Q�就像一个国家的外交部一栗��?/p>

�q�种设计模式主要用在一个大的系�l�中有多个子�pȝ��l�成�Ӟ��q�多个子�pȝ��肯定要涉及到�怺�通信�Q�但是每个子�pȝ��又不能将自己的内部数据过多的�?露给其它�pȝ��Q�不然就没有必要划分子系�l�了。每个子�pȝ��都会设计一个门面，把别的系�l�感兴趣的数据封装�v来，通过�q�个门面来进行访问。这��是门面设计模式存在的意义�?/p>

门面设计模式�C�意囑֦�下：

�?1. 门面�C�意�?/strong>

Client 只能讉K��?Façade 中提供的数据是门面设计模式的关键�Q�至�?Client 如何讉K�� Façade �?Subsystem 如何提供 Façade 门面设计模式�q�没有规定死�?/p>
Tomcat 的门面设计模式示�?/a>

Tomcat 中门面设计模式��用的很多�Q�因�?Tomcat 中有很多不同�l��g�Q�每个组件要�怺�交互数据�Q�用门面模式隔离数据是个很好的方法�?/p>
下面�?Request 上��用的门面设计模式�Q?/p>
�?2. Request 的门面设计模式类�?/strong>

从图中可以看�?HttpRequestFacade �c�d��装了 HttpRequest 接口能够提供数据�Q�通过 HttpRequestFacade 讉K��到的数据都被代理�?HttpRequest 中，通常被封装的对象都被设�ؓ Private 或�? Protected 讉K��修饰�Q�以防止�?Façade 中被直接讉K��?/p>
回页�?/a>
观察者设计模�?/a>

�q�种设计模式也是常用的设计方法通常也叫发布 - 订阅模式�Q�也��是事�g监听机制�Q�通常在某个事件发生的前后会触发一些操作�?/p>
观察者模式的原理

观察者模式原理也很简单，��是你在做事的时候旁�Ҏ��L��一个�h在盯着你，当你做的事情是它感兴��的时候，它就会跟着做另外一些事情。但是盯着你的人必��要��C��那去登记�Q�不然你无法通知它。观察者模式通常包含下面�q�几个角�Ԍ��

Subject ��是抽象主题�Q�它负责��理所有观察者的引用�Q�同时定义主要的事�g操作�?/li>
ConcreteSubject 具体主题�Q�它实现了抽象主题的所有定义的接口�Q�当自己发生变化�Ӟ��会通知所有观察者�?/li>
Observer 观察者：监听主题发生变化相应的操作接口�?/li>

Tomcat 的观察者模式示�?/a>

Tomcat 中观察者模式也有多处��用，前面讲的控制�l��g生命周期�?Lifecycle ��是�q�种模式的体玎ͼ��q�有�?Servlet 实例的创建、Session 的管理、Container �{�都是同��L��原理。下面主要看一�?Lifecycle 的具体实现�?/p>
Lifecycle 的观察者模式结构图�Q?/p>
�?3. Lifecycle 的观察者模式结构图

上面的结构图中，LifecycleListener 代表的是抽象观察者，它定义一�?lifecycleEvent �Ҏ��Q�这个方法就是当主题变化时要执行的方法�?ServerLifecycleListener 代表的是具体的观察者，它实��C�� LifecycleListener 接口的方法，��是�q�个具体的观察者具体的实现方式。Lifecycle 接口代表的是抽象主题�Q�它定义了管理观察者的�Ҏ��和它要所做的其它�Ҏ��。�?StandardServer 代表的是具体主题�Q�它实现了抽象主题的所有方法。这�?Tomcat 对观察者做了扩展，增加了另外两个类�Q�LifecycleSupport、LifecycleEvent�Q�它们作��助类扩展了观察者的功能�?LifecycleEvent 使得可以定义事�g�c�d��Q�不同的事�g可区别处理，更加灉|��。LifecycleSupport �c�M��理了主题对多观察者的��理�Q�将�q�个��理抽出来统一实现�Q�以后如果修改只要修�?LifecycleSupport �c�d��可以了，不需要去修改所有具体主题，因�ؓ所有具体主题的对观察者的操作都被代理�l?LifecycleSupport �c�M��。这可以认�ؓ是观察者模式的改进版�?/p>
LifecycleSupport 调用观察者的�Ҏ��代码如下�Q?/p>
清单 1. LifecycleSupport 中的 fireLifecycleEvent �Ҏ��
public void fireLifecycleEvent(String type, Object data) { LifecycleEvent event = new LifecycleEvent(lifecycle, type, data); LifecycleListener interested[] = null; synchronized (listeners) { interested = (LifecycleListener[]) listeners.clone(); } for (int i = 0; i < interested.length; i++) interested[i].lifecycleEvent(event); }

主题是怎么通知观察者呢�Q�看下面代码�Q?/p>
清单 2. 容器中的 start �Ҏ��
public void start() throws LifecycleException { lifecycle.fireLifecycleEvent(BEFORE_START_EVENT, null); lifecycle.fireLifecycleEvent(START_EVENT, null); started = true; synchronized (services) { for (int i = 0; i < services.length; i++) { if (services[i] instanceof Lifecycle) ((Lifecycle) services[i]).start(); } } lifecycle.fireLifecycleEvent(AFTER_START_EVENT, null); }

回页�?/a>
命��o设计模式

前面�?Tomcat 中两个核心组�?Connector �? Container�Q�比作一对夫妅R��男的将接受�q�来的请求以命��o的方式交�l�女��M�h。对应到 Connector �? Container�Q�Connector 也是通过命��o模式调用 Container 的�?/p>
命��o模式的原�?/a>

命��o模式主要作用��是��装命��o�Q�把发出命��o的责��d��执行命��o的责��d��开。也是一�U�功能的分工。不同的模块可以对同一个命令做��Z��同解释�?/p>
下面是命令模式通常包含下面几个角色�Q?/p>
Client�Q�创��Z��个命令，�q�决定接受�?/li>
Command 命��o�Q�命令接口定义一个抽象方�?/li>
ConcreteCommand�Q�具体命令，负责调用接受者的相应操作
Invoker ��h��者：负责调用命��o对象执行��h��
Receiver 接受者：负责具体实施和执行一�ơ请�?/li>

Tomcat 中的命��o模式的示�?/a>

Tomcat 中命令模式在 Connector �?Container �l��g之间有体玎ͼ�Tomcat 作�ؓ一个应用服务器�Q�无疑会接受到很多请求，如何分配和执行这些请求是必须的功能�?/p>
下面看一�?Tomcat 是如何实现命令模式的�Q�下面是 Tomcat 命��o模式的结构图�Q?/p>
�?4. Tomcat 命��o模式的结构图

Connector 作�ؓ抽象��h��者，HttpConnector 作�ؓ具体��h��者。HttpProcessor 作�ؓ命��o。Container 作�ؓ命��o的抽象接受者，ContainerBase 作�ؓ具体的接受者。客��L��是应用服务�?Server �l��g了。Server 首先创徏命��o��h��?HttpConnector 对象�Q�然后创建命�?HttpProcessor 命��o对象。再把命令对象交�l�命令接受�?ContainerBase 容器来处理命令。命令的最�l�是�?Tomcat �?Container 执行的。命令可以以队列的方式进来，Container 也可以以不同的方式来处理��h��Q�如 HTTP1.0 协议�?HTTP1.1 的处理方式就会不同�?/p>
回页�?/a>
责�Q链模�?/a>

Tomcat 中一个最�Ҏ��发现的设计模式就是责任链模式�Q�这个设计模式也�?Tomcat �?Container 设计的基��Q�整个容器的��是通过一个链�q�接在一��P��q�个链一直将��h��正确的传递给最�l�处理请求的那个 Servlet�?/p>
责�Q链模式的原理

责�Q链模式，��是很多对象有每个对象对其下家的引用而连接�v来�Ş成一条链�Q�请求在�q�条链上传递，直到链上的某个对象处理此��h��Q�或者每个对象都可以处理��h��Q��ƈ传给下一�Ӟ��直到最�l�链上每个对象都处理完。这样可以不影响客户端而能够在链上增加��L��的处理节炏V�?/p>
通常责�Q链模式包含下面几个角�Ԍ��

Handler�Q�抽象处理者）�Q�定义一个处理请求的接口
ConcreteHandler�Q�具体处理者）�Q�处理请求的具体�c�，或者传�l�下�?/li>

Tomcat 中责任链模式�C�Z��

�?tomcat 中这�U�设计模式几乎被完整的��用，tomcat 的容器设�|�就是责任链模式�Q�从 Engine �?Host 再到 Context 一直到 Wrapper 都是通过一个链传递请求�?/p>
Tomcat 中责任链模式的类�l�构囑֦�下：

�?5. Tomcat 责�Q链模式的�l�构�?/strong>

上图基本描述了四个子容器使用责�Q链模式的�cȝ��构图�Q�对应的责�Q链模式的角色�Q�Container 扮演抽象处理者角�Ԍ��具体处理者由 StandardEngine �{�子容器扮演。与标准的责任链不同的是�Q�这里引入了 Pipeline �?Valve 接口。他们有什么作用呢�Q?/p>
实际�?Pipeline �?Valve 是扩展了�q�个铄��功能�Q��得在铑־�下传递过�E�中�Q�能够接受外界的�q�预。Pipeline ��是�q�接每个子容器的��子�Q�里面传递的 Request �?Response 对象好比��子里流的水�Q��?Valve ��是�q�个��子上开的一个个��口子，让你有机会能够接触到里面的水�Q�做一些额外的事情�?/p>
��Z��防止水被引出来而不能流��C��一个容器中�Q�每一�D늮�子最后��L��一个节点保证它一定能��到下一个子容器�Q�所以每个容器都有一�?StandardXXXValve。只要涉及到�q�种有链式是处理��程�q�是一个非常值得借鉴的模式�?/p>

参考资�?
学习
查看本系列的�W?1 部分�Q?#8220;Tomcat �pȝ��原理分析”�?br />
“面向初�� Web 开发�h员的 Tomcat” �Q�developerWorks�Q?005 �q?10 月）�Q�Apache Tomcat 应用服务器不再是高�� Web �pȝ��开发�h员的专用领域。在本教�E�中�Q�Sing Li ��向初�� Web 开发�h员展�C�如何利用他们当前的 Java 开发技能，使用 Tomcat �~�写服务器端 JSP、servlet �?Web 服务�?br />
技术书�?/a>�Q�浏览关于这些和其他技术主题的图书�?br />
developerWorks Java 技术专�?/a>�Q�数癄��关于 Java �~�程各个斚w��的文章�?br />
讨论
加入 developerWorks �C�֌��?br />
查看 developerWorks 博客的最��C��息�?br />

zhb8015 2012-05-28 17:58 发表评论

zhb8015 — Mon, 28 May 2012 09:53:00 GMT
原文地址�Q?div>http://www.ibm.com/developerworks/cn/java/j-lo-spring-principle/

Spring 的骨骼架�?/a>

Spring ��d��有十几个�l��g�Q�但是真正核心的�l��g只有几个�Q�下面是 Spring 框架的��M��架构图：

�?1 .Spring 框架的��M��架构�?/strong>

从上图中可以看出 Spring 框架中的核心�l��g只有三个�Q�Core、Context �?Beans。它们构��v了整�?Spring 的骨骼架构。没有它们就不可能有 AOP、Web �{�上层的�Ҏ��功能。下面也��主要从�q�三个组件入手分�?Spring�?/p>
Spring 的设计理�?/a>

前面介绍�?Spring 的三个核心组�Ӟ��如果再在它们三个中选出核心的话�Q�那��非 Beans �l��g莫属了，��Z��q�样��_��其实 Spring ��是面向 Bean 的编�E�（BOP,Bean Oriented Programming�Q�，Bean �?Spring 中才是真正的主角�?/p>
Bean �?Spring 中作用就�?Object �?OOP 的意义一��P��没有对象的概念就像没有面向对象编�E�，Spring 中没�?Bean 也就没有 Spring 存在的意义。就像一�ơ演��台都准备好了但是却没有演员一栗��ؓ什么要 Bean �q�种角色 Bean 或者�ؓ何在 Spring 如此重要�Q�这�?Spring 框架的设计目标决定，Spring ��Z��如此��行�Q�我们用 Spring 的原因是什么，��x��你会发现原来 Spring 解决了一个非常关键的问题他可以让你把对象之间的依赖关�p��{而用配置文�g来管理，也就是他的依赖注入机制。而这个注入关�p�d��一个叫 Ioc 容器中管理，�?Ioc 容器中有又是什么就是被 Bean 包裹的对象。Spring 正是通过把对象包装在 Bean 中而达到对�q�些对象��理以及一些列额外操作的目的�?/p>
它这�U�设计策略完全类��g�� Java 实现 OOP 的设计理念，当然�?Java 本��n的设计要�?Spring 复杂太多太多�Q�但是都是构��Z��个数据结构，然后�Ҏ��q�个数据�l�构设计他的生存环境�Q��ƈ让它在这个环境中按照一定的规律在不停的�q�动�Q�在它们的不停运动中�?计一�p�d��与环境或者与其他个体完成信息交换。这��h��来回�q�头��x��我们用到的其他框枉��是大慨类似的设计理念�?/p>
核心�l��g如何协同工作

前面�?Bean �?Spring 中关键因素，�?Context �?Core 又有何作用呢�Q�前面吧 Bean 比作一场演��Z��的演员的话，�?Context ��是�q�场演出的舞台背景，�?Core 应该��是演出的道具了。只有他们在一��h��能具备能演出一场好戏的最基本的条件。当然有最基本的条件还不能使这场演��颖而出�Q�还要他表演的节目��够的�_?彩，�q�些节目��是 Spring 能提供的特色功能了�?/p>
我们知道 Bean 包装的是 Object�Q��?Object 必然有数据，如何�l�这些数据提供生存环境就�?Context 要解决的问题�Q�对 Context 来说他就是要发现每个 Bean 之间的关�p�，为它们徏立这�U�关�p�dƈ且要�l�护好这�U�关�p�R��所�?Context ��是一�?Bean 关系的集合，�q�个关系集合又叫 Ioc 容器�Q�一旦徏立�v�q�个 Ioc 容器�?Spring ��可以�ؓ你工作了。那 Core �l��g又有什么用武之地呢�Q�其�?Core ��是发现、徏立和�l�护每个 Bean 之间的关�p�L��需要的一些列的工��P��从这个角度看来，Core �q�个�l��g�? Util 更能让你理解�?/p>
它们之间可以用下图来表示�Q?/p>
�?2. 三个�l��g关系

核心�l��g详解

�q�里��详�l�介�l�每个组件内部类的层�ơ关�p�，以及它们在运行时的时序顺序。我们在使用 Spring 是应该注意的地方�?/p>
Bean �l��g

前面已经说明�?Bean �l��g�?Spring 的重要性，下面看看 Bean �q�个�l��g式怎么设计的。Bean �l��g�?Spring �? org.springframework.beans 包下。这个包下的所有类主要解决了三件事�Q�Bean 的定义、Bean 的创��Z��及对 Bean 的解析。对 Spring 的��用者来说唯一需要关心的��是 Bean 的创建，其他两个�?Spring 在内部帮你完成了�Q�对你来说是透明的�?/p>
Spring Bean 的创建时典型的工厂模式，他的��接口�?BeanFactory�Q�下图是�q�个工厂的��承层�ơ关�p�：

�?4. Bean 工厂的��承关�p?/strong>

BeanFactory 有三个子�c�：ListableBeanFactory、HierarchicalBeanFactory �? AutowireCapableBeanFactory。但是从上图中我们可以发现最�l�的默认实现�c�L�� DefaultListableBeanFactory�Q�他实现了所有的接口。那��Z��要定义这么多层次的接口呢�Q�查阅这些接口的源码和说明发玎ͼ�每个接口都有他��用的场合�Q�它主要是�ؓ了区分在 Spring 内部在操作过�E�中对象的传递和转化�q�程中，对对象的数据讉K��所做的限制。例�? ListableBeanFactory 接口表示�q�些 Bean 是可列表的，�?HierarchicalBeanFactory 表示的是�q�些 Bean 是有�l�承关系的，也就是每�?Bean 有可能有�?Bean。AutowireCapableBeanFactory 接口定义 Bean 的自动装配规则。这四个接口共同定义�?Bean 的集合、Bean 之间的关�p�R��以�?Bean 行�ؓ�?/p>
Bean 的定义主要有 BeanDefinition 描述�Q�如下图说明了这些类的层�ơ关�p�：

�?5. Bean 定义的类层次关系�?/strong>

Bean 的定义就是完整的描述了在 Spring 的配�|�文件中你定义的节点中所有的信息�Q�包括各�U�子节点。当 Spring 成功解析你定义的一�? 节点后，�?Spring 的内部他��p��转化�?BeanDefinition 对象。以后所有的操作都是对这个对象完成的�?/p>
Bean 的解析过�E�非常复杂，功能被分的很�l�，因�ؓ�q�里需要被扩展的地方很多，必须保证有��够的灉|��性，以应对可能的变化。Bean 的解析主要就是对 Spring 配置文�g的解析。这个解析过�E�主要通过下图中的�c�d��成：

�?6. Bean 的解析类

当然�q�有具体�?tag 的解析这里�ƈ没有列出�?/p>
Context �l��g

Context �?Spring �?org.springframework.context 包下�Q�前面已�l�讲解了 Context �l��g�?Spring 中的作用�Q�他实际上就是给 Spring 提供一个运行时的环境，用以保存各个对象的状态。下面看一下这个环境是如何构徏的�?/p>
ApplicationContext �?Context 的顶�U�父�c�，他除了能标识一个应用环境的基本信息外，他还�l�承了五个接口，�q�五个接口主要是扩展�?Context 的功能。下面是 Context 的类�l�构图：

�?7. Context 相关的类�l�构�?/strong>

�Q�查�?�?7 的清晰版�?/a>。）

从上图中可以看出 ApplicationContext �l�承�?BeanFactory�Q�这也说明了 Spring 容器中运行的��M��对象�?Bean�Q�另�?ApplicationContext �l�承�?ResourceLoader 接口�Q��? ApplicationContext 可以讉K��C�Q何外部资源，�q�将�?Core 中详�l�说明�?/p>
ApplicationContext 的子�c�M��要包含两个方面：

ConfigurableApplicationContext 表示�?Context 是可修改的，也就是在构徏 Context 中用户可以动态添加或修改已有的配�|�信息，它下面又有多个子�c�，其中最�l�常使用的是可更新的 Context�Q�即 AbstractRefreshableApplicationContext �c�R�?/li>
WebApplicationContext ��֐�思义�Q�就是�ؓ web 准备�?Context 他可以直接访问到 ServletContext�Q�通常情况下，�q�个接口使用的少�?/li>

再往下分��是按照构徏 Context 的文件类型，接着��是讉K�� Context 的方式。这样一�U�一�U�构成了完整�?Context �{��层次�?/p>
��M��来说 ApplicationContext 必须要完成以下几件事�Q?/p>
标识一个应用环�?/li>
利用 BeanFactory 创徏 Bean 对象
保存对象关系�?/li>
能够捕获各种事�g

Context 作�ؓ Spring �?Ioc 容器�Q�基本上整合�?Spring 的大部分功能�Q�或者说是大部分功能的基��?/p>
Core �l��g

Core �l��g作�ؓ Spring 的核心组�Ӟ��他其中包含了很多的关键类�Q�其中一个重要组成部分就是定义了资源的访问方式。这�U�把所有资源都抽象成一个接口的方式很值得在以后的设计中拿来学习。下面就重要看一下这个部分在 Spring 的作用�?/p>
下图�?Resource 相关的类�l�构图：

�?8. Resource 相关的类�l�构�?/strong>

�Q�查�?�?8 的清晰版�?/a>。）

从上囑֏�以看�?Resource 接口��装了各�U�可能的资源�c�d��Q�也��是对��用者来说屏蔽了文�g�c�d��的不同。对资源的提供者来��_��如何把资源包装�v来交�l�其他�h用这也是一个问题，我们看到 Resource 接口�l�承�?InputStreamSource 接口�Q�这个接口中有个 getInputStream �Ҏ��Q�返回的�? InputStream �c�R��这��h��有的资源都被可以通过 InputStream �q�个�c�L��获取�Q�所以也屏蔽了资源的提供者。另外还有一个问题就是加载资源的问题�Q�也��是资源的加载者要�l�一�Q�从上图中可以看��个�Q务是�? ResourceLoader 接口完成�Q�他屏蔽了所有的资源加蝲者的差异�Q�只需要实现这个接口就可以加蝲所有的资源�Q�他的默认实现是 DefaultResourceLoader�?/p>
下面看一�?Context �?Resource 是如何徏立关�pȝ��Q�首先看一下他们的�c�d��p�d��Q?/p>
�?9. Context �?Resource 的类关系�?/strong>

从上囑֏�以看出，Context 是把资源的加载、解析和描述工作委托�l�了 ResourcePatternResolver �c�L��完成�Q�他相当于一个接头�h�Q�他把资源的加蝲、解析和资源的定义整合在一起便于其他组件��用。Core �l��g中还有很多类似的方式�?/p>
Ioc 容器如何工作

前面介绍�?Core �l��g、Bean �l��g�?Context �l��g的结构与�怺�关系�Q�下面这里从使用者角度看一下他们是如何�q�行的，以及我们如何�?Spring 完成各种功能�Q�Spring 到底能有那些功能�Q�这些功能是如何得来的，下面介绍�?/p>
如何创徏 BeanFactory 工厂

正如�?2 描述的那��P��Ioc 容器实际上就�?Context �l��g�l�合其他两个�l��g共同构徏了一�?Bean 关系�|�，如何构徏�q�个关系�|�？构徏的入口就�?AbstractApplicationContext �cȝ�� refresh �Ҏ��中。这个方法的代码如下�Q?/p>
清单 1. AbstractApplicationContext.refresh
public void refresh() throws BeansException, IllegalStateException { synchronized (this.startupShutdownMonitor) { // Prepare this context for refreshing. prepareRefresh(); // Tell the subclass to refresh the internal bean factory. ConfigurableListableBeanFactory beanFactory = obtainFreshBeanFactory(); // Prepare the bean factory for use in this context. prepareBeanFactory(beanFactory); try { // Allows post-processing of the bean factory in context subclasses. postProcessBeanFactory(beanFactory); // Invoke factory processors registered as beans in the context. invokeBeanFactoryPostProcessors(beanFactory); // Register bean processors that intercept bean creation. registerBeanPostProcessors(beanFactory); // Initialize message source for this context. initMessageSource(); // Initialize event multicaster for this context. initApplicationEventMulticaster(); // Initialize other special beans in specific context subclasses. onRefresh(); // Check for listener beans and register them. registerListeners(); // Instantiate all remaining (non-lazy-init) singletons. finishBeanFactoryInitialization(beanFactory); // Last step: publish corresponding event. finishRefresh(); } catch (BeansException ex) { // Destroy already created singletons to avoid dangling resources. destroyBeans(); // Reset 'active' flag. cancelRefresh(ex); // Propagate exception to caller. throw ex; } } }

�q�个�Ҏ��是构徏整个 Ioc 容器�q�程的完整的代码�Q�了解了里面的每一行代码基本上��׃��解大部分 Spring 的原理和功能了�?/p>
�q�段代码主要包含�q�样几个步骤�Q?/p>
构徏 BeanFactory�Q�以便于产生所需�?#8220;演员”
注册可能感兴��的事�g
创徏 Bean 实例对象
触发被监听的事�g

下面��q��合代码分析这几个�q�程�?/p>
�W�二三句��是在创建和配置 BeanFactory。这里是 refresh 也就是刷新配�|�，前面介绍�?Context 有可更新的子�c�，�q�里正是实现�q�个功能�Q�当 BeanFactory 已存在是��更斎ͼ�如果没有��新创徏。下面是更新 BeanFactory 的方法代码：

清单 2. AbstractRefreshableApplicationContext. refreshBeanFactory
protected final void refreshBeanFactory() throws BeansException { if (hasBeanFactory()) { destroyBeans(); closeBeanFactory(); } try { DefaultListableBeanFactory beanFactory = createBeanFactory(); beanFactory.setSerializationId(getId()); customizeBeanFactory(beanFactory); loadBeanDefinitions(beanFactory); synchronized (this.beanFactoryMonitor) { this.beanFactory = beanFactory; } } catch (IOException ex) { throw new ApplicationContextException( "I/O error parsing bean definition source for " + getDisplayName(), ex); } }

�q�个�Ҏ��实现�?AbstractApplicationContext 的抽象方�? refreshBeanFactory�Q�这�D�代码清楚的说明�?BeanFactory 的创��E�。注�?BeanFactory 对象的类型的变化�Q�前面介�l�了他有很多子类�Q�在什么情况下使用不同的子�c�这非常关键。BeanFactory 的原始对象是 DefaultListableBeanFactory�Q�这个非常关键，因�ؓ他设计到后面对这个对象的多种操作�Q�下面看一下这个类的��承层�ơ类图：

�?10. DefaultListableBeanFactory �cȝ��承关�p�d��

�Q�查�?�?10 的清晰版�?/a>。）

从这个图中发现除�?BeanFactory 相关的类外，�q�发��C��?Bean �?register 相关。这�? refreshBeanFactory �Ҏ��中有一�?loadBeanDefinitions(beanFactory) ��找到答案，�q�个�Ҏ��开始加载、解�?Bean 的定义，也就是把用户定义的数据结构�{化�ؓ Ioc 容器中的特定数据�l�构�?/p>
�q�个�q�程可以用下面时序图解释�Q?/p>
�?11. 创徏 BeanFactory 时序�?/strong>

�Q�查�?�?11 的清晰版�?/a>。）

Bean 的解析和登记��程时序囑֦�下：

�?12. 解析和登�?Bean 对象时序�?/strong>

�Q�查�?�?12 的清晰版�?/a>。）

创徏�?BeanFactory 后，接下��L��加一�?Spring 本��n需要的一些工��L��Q�这个操作在 AbstractApplicationContext �?prepareBeanFactory �Ҏ��完成�?/p>
AbstractApplicationContext 中接下来的三行代码对 Spring 的功能扩展性�v了至关重要的作用。前两行主要是让你现在可以对已经构徏�?BeanFactory 的配�|�做修改�Q�后面一行就是让你可以对以后再创�? Bean 的实例对象时��d��一些自定义的操作。所以他们都是扩展了 Spring 的功能，所以我们要学习使用 Spring 必须对这一部分搞清楚�?/p>
其中�?invokeBeanFactoryPostProcessors �Ҏ��中主要是获取实现 BeanFactoryPostProcessor 接口的子�c�R��ƈ执行它的 postProcessBeanFactory �Ҏ��Q�这个方法的声明如下�Q?/p>
清单 3. BeanFactoryPostProcessor.postProcessBeanFactory
void postProcessBeanFactory(ConfigurableListableBeanFactory beanFactory) throws BeansException;

它的参数�?beanFactory�Q�说明可以对 beanFactory 做修改，�q�里注意�q�个 beanFactory �? ConfigurableListableBeanFactory �c�d��的，�q�也印证了前面介�l�的不同 BeanFactory 所使用的场合不同，�q�里只能是可配置�?BeanFactory�Q�防止一些数据被用户随意修改�?/p>
registerBeanPostProcessors �Ҏ��也是可以获取用户定义的实��C�� BeanPostProcessor 接口的子�c�，�q�执行把它们注册�?BeanFactory 对象中的 beanPostProcessors 变量中。BeanPostProcessor 中声明了两个�Ҏ��Q�postProcessBeforeInitialization、postProcessAfterInitialization 分别用于�?Bean 对象初始化时执行。可以执行用戯��定义的操作�?/p>
后面的几行代码是初始化监听事件和对系�l�的其他监听者的注册�Q�监听者必��L�� ApplicationListener 的子�c�R�?/p>
如何创徏 Bean 实例�q�构�?Bean 的关�pȝ��

下面��是 Bean 的实例化代码�Q�是�?finishBeanFactoryInitialization �Ҏ��开始的�?/p>
清单 4. AbstractApplicationContext.finishBeanFactoryInitialization
protected void finishBeanFactoryInitialization( ConfigurableListableBeanFactory beanFactory) { // Stop using the temporary ClassLoader for type matching. beanFactory.setTempClassLoader(null); // Allow for caching all bean definition metadata, not expecting further changes. beanFactory.freezeConfiguration(); // Instantiate all remaining (non-lazy-init) singletons. beanFactory.preInstantiateSingletons(); }

从上面代码中可以发现 Bean 的实例化是在 BeanFactory 中发生的。preInstantiateSingletons �Ҏ��的代码如下：

清单 5. DefaultListableBeanFactory.preInstantiateSingletons
public void preInstantiateSingletons() throws BeansException { if (this.logger.isInfoEnabled()) { this.logger.info("Pre-instantiating singletons in " + this); } synchronized (this.beanDefinitionMap) { for (String beanName : this.beanDefinitionNames) { RootBeanDefinition bd = getMergedLocalBeanDefinition(beanName); if (!bd.isAbstract() && bd.isSingleton() && !bd.isLazyInit()) { if (isFactoryBean(beanName)) { final FactoryBean factory = (FactoryBean) getBean(FACTORY_BEAN_PREFIX+ beanName); boolean isEagerInit; if (System.getSecurityManager() != null && factory instanceof SmartFactoryBean) { isEagerInit = AccessController.doPrivileged( new PrivilegedAction() { public Boolean run() { return ((SmartFactoryBean) factory).isEagerInit(); } }, getAccessControlContext()); } else { isEagerInit = factory instanceof SmartFactoryBean && ((SmartFactoryBean) factory).isEagerInit(); } if (isEagerInit) { getBean(beanName); } } else { getBean(beanName); } } } } }

�q�里出现了一个非帔R��要的 Bean —— FactoryBean�Q�可以说 Spring 一大半的扩展的功能都与�q�个 Bean 有关�Q�这是个�Ҏ��?Bean 他是个工�?Bean�Q�可以��?Bean �?Bean�Q�这里的产生 Bean 是指 Bean 的实例，如果一个类�l�承 FactoryBean 用户可以自己定义产生实例对象的方法只要实��C��?getObject �Ҏ��。然而在 Spring 内部�q�个 Bean 的实例对象是 FactoryBean�Q�通过调用�q�个对象�?getObject �Ҏ��p��获取用户自定义��生的对象�Q�从而�ؓ Spring 提供了很好的扩展性。Spring 获取 FactoryBean 本��n的对象是在前面加�?& 来完成的�?/p>
如何创徏 Bean 的实例对象以及如何构�?Bean 实例对象之间的关联关�p�d�� Spring 中的一个核心关键，下面是这个过�E�的��程图�?/p>
�?13.Bean 实例创徏��程�?/strong>

�Q�查�?�?13 的清晰版�?/a>。）

如果是普通的 Bean ��q��接创��Z��的实例，是通过调用 getBean �Ҏ��。下面是创徏 Bean 实例的时序图�Q?/p>
�?14.Bean 实例创徏时序�?/strong>

�Q�查�?�?14 的清晰版�?/a>。）

�q�有一个非帔R��要的部分��是建立 Bean 对象实例之间的关�p�，�q�也�?Spring 框架的核心竞争力�Q�何时、如何徏立他们之间的关系��L��下面的时序图�Q?/p>
�?15.Bean 对象关系建立

�Q�查�?�?15 的清晰版�?/a>。）

Ioc 容器的扩展点

现在�q�有一个问题就是如何让�q�些 Bean 对象有一定的扩展性，��是可以加入用户的一些操作。那么有哪些扩展点呢�Q?Spring 又是如何调用到这些扩展点的？

�?Spring �?Ioc 容器来说�Q�主要有�q�么几个。BeanFactoryPostProcessor�Q? BeanPostProcessor。他们分别是在构�?BeanFactory 和构�?Bean 对象时调用。还有就�? InitializingBean �?DisposableBean 他们分别是在 Bean 实例创徏和销毁时被调用。用户可以实现这些接口中定义的方法，Spring ��׃��在适当的时候调用他们。还有一个是 FactoryBean 他是个特�D�的 Bean�Q�这�?Bean 可以被用��h��多的控制�?/p>
�q�些扩展炚w��常也是我们使用 Spring 来完成我们特定�Q务的地方�Q�如何精�?Spring ��q��你有没有掌握�?Spring 有哪些扩展点�Q��ƈ且如何��用他们，要知道如何��用他们就必须了解他们内在的机理。可以用下面一个比��L��解释�?/p>
我们�?Ioc 容器比作一个箱子，�q�个��子里有若干个球的模子，可以用这些模子来造很多种不同的球�Q�还有一个造这些球模的机器�Q�这个机器可以��生球模。那么他们的对应�?�p�d��?BeanFactory ��是那个造球模的机器�Q�球模就�?Bean�Q�而球模造出来的球就�?Bean 的实例。那前面所说的几个扩展点又在什么地方呢�Q?BeanFactoryPostProcessor 对应到当造球模被造出来时�Q�你��有��Z��可以对其做出讑ֽ�的修正，也就是他可以帮你修改球模。�?InitializingBean �? DisposableBean 是在球模造球的开始和�l�束阶段�Q�你可以完成一些预备和扫尾工作。BeanPostProcessor ��可以让你对球模造出来的球做出适当的修正。最后还有一�? FactoryBean�Q�它可是一个神奇的球模。这个球模不是预先就定型了，而是�׃��来给他确定它的�Ş�Ӟ��既然你可以确定这个球模型的�Ş�Ӟ��当然他造出�?的球肯定��是你想要的球了�Q�这样在�q�个��子里尼可以发现所有你惌��的球

Ioc 容器如何为我所�?/strong>

前面的介�l�了 Spring 容器的构��E�，�?Spring 能�ؓ我们做什么，Spring �?Ioc 容器又能做什么呢�Q�我们��? Spring 必须要首先构�?Ioc 容器�Q�没有它 Spring 无法工作�Q�ApplicatonContext.xml ��是 Ioc 容器的默认配�|�文�Ӟ��Spring 的所有特性功能都是基于这�?Ioc 容器工作的，比如后面要介�l�的 AOP�?/p>
Ioc 它实际上��是��Z��构徏了一个魔方，Spring ��Z��搭好了骨骼架构，�q�个��方到底能变��Z��么好的东西出来，�q�必��要有你的参与。那我们怎么参与�Q�这��是前面说的要了�?Spring 中那有些扩展点，我们通过实现那些扩展�Ҏ��改变 Spring 的通用行�ؓ。至于如何实现扩展点来得到我们想要的个性结果，Spring 中有很多例子�Q�其�?AOP 的实现就�?Spring 本��n实现了其扩展�Ҏ��辑ֈ�了它惌��的特性功能，可以拿来参考�?/p>
回页�?/a>
Spring �?AOP �Ҏ��详�?/a>

动态代理的实现原理

要了�?Spring �?AOP ��必��d��了解的动态代理的原理�Q�因�?AOP ��是��Z��动态代理实现的。动态代理还要从 JDK 本��n说�v�?/p>
�?Jdk �?java.lang.reflect 包下有个 Proxy �c�，它正是构造代理类的入口。这个类的结构入下：

�?16. Proxy �cȝ��?/strong>

从上囑֏�现最后面四个是公有方法。而最后一个方�?newProxyInstance ��是创徏代理对象的方法。这个方法的源码如下�Q?/p>
清单 6. Proxy. newProxyInstance
public static Object newProxyInstance(ClassLoader loader, Class[] interfaces, InvocationHandler h) throws IllegalArgumentException { if (h == null) { throw new NullPointerException(); } Class cl = getProxyClass(loader, interfaces); try { Constructor cons = cl.getConstructor(constructorParams); return (Object) cons.newInstance(new Object[] { h }); } catch (NoSuchMethodException e) { throw new InternalError(e.toString()); } catch (IllegalAccessException e) { throw new InternalError(e.toString()); } catch (InstantiationException e) { throw new InternalError(e.toString()); } catch (InvocationTargetException e) { throw new InternalError(e.toString()); } }

�q�个�Ҏ��需要三个参敎ͼ�ClassLoader�Q�用于加载代理类�?Loader �c�，通常�q�个 Loader 和被代理的类是同一�? Loader �c�R��Interfaces�Q�是要被代理的那些那些接口。InvocationHandler�Q�就是用于执行除了被代理接口中方法之外的用户自定义的操作�Q?他也是用户需要代理的最�l�目的。用戯��用目标方法都被代理到 InvocationHandler �c�M��定义的唯一�Ҏ�� invoke 中。这在后面再详解�?/p>
下面�q�是看看 Proxy 如何产生代理�cȝ��q�程�Q�他构造出来的代理�c�d��底是什么样子？下面揭晓啦�?/p>
�?17. 创徏代理对象时序�?/strong>

其实从上图中可以发现正在构造代理类的是�?ProxyGenerator �?generateProxyClass 的方法中。ProxyGenerator �c�d�� sun.misc 包下�Q�感兴趣的话可以看看他的源码�?/p>
假如有这样一个接口，如下�Q?/p>
清单 7. SimpleProxy �c?/strong>
public interface SimpleProxy { public void simpleMethod1(); public void simpleMethod2(); }

代理来生成的�cȝ��构如下：

清单 8. $Proxy2 �c?/strong>
public class $Proxy2 extends java.lang.reflect.Proxy implements SimpleProxy{ java.lang.reflect.Method m0; java.lang.reflect.Method m1; java.lang.reflect.Method m2; java.lang.reflect.Method m3; java.lang.reflect.Method m4; int hashCode(); boolean equals(java.lang.Object); java.lang.String toString(); void simpleMethod1(); void simpleMethod2(); }

�q�个�c�M��的方法里面将会是调用 InvocationHandler �?invoke �Ҏ��Q�而每个方法也��对应一个属性变量，�q�个属性变�?m 也将传给 invoke �Ҏ��中的 Method 参数。整个代理就是这样实现的�?/p>
Spring AOP 如何实现

从前面代理的原理我们知道�Q�代理的目的是调用目标方法时我们可以转而执�?InvocationHandler �cȝ�� invoke �Ҏ��Q�所以如何在 InvocationHandler 上做文章��是 Spring 实现 Aop 的关键所在�?/p>
Spring �?Aop 实现是遵�?Aop 联盟的约定。同�?Spring 又扩展了它，增加了如 Pointcut、Advisor �{�一些接口��得更加灵�z�R�?/p>
下面�?Jdk 动态代理的�c�d��Q?/p>
�?18. Jdk 动态代理的�c�d��

上图清楚的显�C�Z�� Spring 引用�?Aop Alliance 定义的接口。姑且不讨论 Spring 如何扩展 Aop Alliance�Q�先看看 Spring 如何实现代理�cȝ��Q�要实现代理�c�d�� Spring 的配�|�文件中通常是这样定一�?Bean 的，如下�Q?/p>
清单 9. 配置代理�c?Bean
org.springframework.aop.framework.PrototypeTargetTests$TestBean true testInterceptor testInterceptor2

配置上看到要讄��被代理的接口�Q�和接口的实现类也就是目标类�Q�以及拦截器也就在执行目标方法之前被调用�Q�这�?Spring 中定义的各种各样的拦截器�Q�可以选择使用�?/p>
下面看看 Spring 如何完成了代理以及是如何调用拦截器的�?/p>
前面提到 Spring Aop 也是实现其自�w�的扩展�Ҏ��完成�q�个�Ҏ��的�Q�从�q�个代理�c�d��以看出它正是�l�承�?FactoryBean �? ProxyFactoryBean�Q�FactoryBean 之所以特别就在它可以让你自定义对象的创徏�Ҏ��。当然代理对象要通过 Proxy �c�L��动态生成�?/p>
下面�?Spring 创徏的代理对象的时序图：

�?19.Spring 代理对象的��?/strong>

Spring 创徏了代理对象后�Q�当你调用目标对象上的方法时�Q�将都会被代理到 InvocationHandler �cȝ�� invoke �Ҏ��中执行，�q�在前面已经解释。在�q�里 JdkDynamicAopProxy �c�d��C�� InvocationHandler 接口�?/p>
下面再看�?Spring 是如何调用拦截器的，下面是这个过�E�的时序图：

�?20.Spring 调用拦截�?/strong>

以上所说的都是 Jdk 动态代理，Spring �q�支持一�U?CGLIB �c�M��理，感兴��自��q��吧�?/p>
回页�?/a>
Spring 中设计模式分�?/a>

Spring 中��用的设计模式也很多，比如工厂模式、单例模式、模版模式等�Q�在�?Webx 框架的系�l�架构与设计模式》、�?Tomcat 的系�l�架构与模式设计分析》已�l�有介绍�Q�这里就不赘�q�C��。这里主要介�l�代理模式和�{�略模式�?/p>
代理模式

代理模式原理

代理模式��是�l�某一个对象创��Z��个代理对象，而由�q�个代理对象控制对原对象的引用，而创��个代理对象就是可以在调用原对象是可以增加一些额外的操作。下面是代理模式的结构：

�?21. 代理模式的结�?/strong>

Subject�Q�抽象主题，它是代理对象的真实对象要实现的接口，当然�q�可以是多个接口�l�成�?/li>
ProxySubject�Q�代理类除了实现抽象主题定义的接口外�Q�还必须持有所代理对象的引�?/li>
RealSubject�Q�被代理的类�Q�是目标对象�?/li>

Spring 中如何实��C��理模�?/strong>

Spring Aop �?Jdk 动态代理就是利用代理模式技术实现的。在 Spring 中除了实现被代理对象的接口外�Q�还会有 org.springframework.aop.SpringProxy �? org.springframework.aop.framework.Advised 两个接口。Spring 中��用代理模式的�l�构囑֦�下：

�?22. Spring 中��用代理模式的�l�构�?/strong>

$Proxy ��是创徏的代理对象，�?Subject 是抽象主题，代理对象是通过 InvocationHandler 来持有对目标对象的引用的�?/p>
Spring 中一个真实的代理对象�l�构如下�Q?/p>
清单 10 代理对象 $Proxy4
public class $Proxy4 extends java.lang.reflect.Proxy implements org.springframework.aop.framework.PrototypeTargetTests$TestBean org.springframework.aop.SpringProxy org.springframework.aop.framework.Advised { java.lang.reflect.Method m16; java.lang.reflect.Method m9; java.lang.reflect.Method m25; java.lang.reflect.Method m5; java.lang.reflect.Method m2; java.lang.reflect.Method m23; java.lang.reflect.Method m18; java.lang.reflect.Method m26; java.lang.reflect.Method m6; java.lang.reflect.Method m28; java.lang.reflect.Method m14; java.lang.reflect.Method m12; java.lang.reflect.Method m27; java.lang.reflect.Method m11; java.lang.reflect.Method m22; java.lang.reflect.Method m3; java.lang.reflect.Method m8; java.lang.reflect.Method m4; java.lang.reflect.Method m19; java.lang.reflect.Method m7; java.lang.reflect.Method m15; java.lang.reflect.Method m20; java.lang.reflect.Method m10; java.lang.reflect.Method m1; java.lang.reflect.Method m17; java.lang.reflect.Method m21; java.lang.reflect.Method m0; java.lang.reflect.Method m13; java.lang.reflect.Method m24; int hashCode(); int indexOf(org.springframework.aop.Advisor); int indexOf(org.aopalliance.aop.Advice); boolean equals(java.lang.Object); java.lang.String toString(); void sayhello(); void doSomething(); void doSomething2(); java.lang.Class getProxiedInterfaces(); java.lang.Class getTargetClass(); boolean isProxyTargetClass(); org.springframework.aop.Advisor; getAdvisors(); void addAdvisor(int, org.springframework.aop.Advisor) throws org.springframework.aop.framework.AopConfigException; void addAdvisor(org.springframework.aop.Advisor) throws org.springframework.aop.framework.AopConfigException; void setTargetSource(org.springframework.aop.TargetSource); org.springframework.aop.TargetSource getTargetSource(); void setPreFiltered(boolean); boolean isPreFiltered(); boolean isInterfaceProxied(java.lang.Class); boolean removeAdvisor(org.springframework.aop.Advisor); void removeAdvisor(int)throws org.springframework.aop.framework.AopConfigException; boolean replaceAdvisor(org.springframework.aop.Advisor, org.springframework.aop.Advisor) throws org.springframework.aop.framework.AopConfigException; void addAdvice(org.aopalliance.aop.Advice) throws org.springframework.aop.framework.AopConfigException; void addAdvice(int, org.aopalliance.aop.Advice) throws org.springframework.aop.framework.AopConfigException; boolean removeAdvice(org.aopalliance.aop.Advice); java.lang.String toProxyConfigString(); boolean isFrozen(); void setExposeProxy(boolean); boolean isExposeProxy(); }

�{�略模式

�{�略模式原理

�{�略模式��֐�思义��是做某事的�{�略�Q�这在编�E�上通常是指完成某个操作可能有多�U�方法，�q�些�Ҏ��各有千秋�Q�可能有不同的适应的场合，然而这些操作方法都有可能用到。各一个操作方法都当作一个实现策略，使用者可能根据需要选择合适的�{�略�?/p>
下面是策略模式的�l�构�Q?/p>
�?23. �{�略模式的结�?/strong>

Context�Q��用不同策略的环境�Q�它可以�Ҏ��自��n的条仉��择不同的策略实现类来完成所要的操作。它持有一个策略实例的引用。创建具体策略对象的�Ҏ��也可以由他完成�?/li>
Strategy�Q�抽象策略，定义每个�{�略都要实现的策略方�?/li>
ConcreteStrategy�Q�具体策略实现类�Q�实现抽象策略中定义的策略方�?/li>

Spring 中策略模式的实现

Spring 中策略模式��用有多个地方�Q�如 Bean 定义对象的创��Z��及代理对象的创徏�{�。这里主要看一下代理对象创建的�{�略模式的实现�?/p>
前面已经了解 Spring 的代理方式有两个 Jdk 动态代理和 CGLIB 代理。这两个代理方式的��用正是��用了�{�略模式。它的结构图如下所�C�：

�?24. Spring 中策略模式结构图

在上面结构图中与标准的策略模式结构稍微有点不同，�q�里抽象�{�略�?AopProxy 接口�Q�Cglib2AopProxy �? JdkDynamicAopProxy 分别代表两种�{�略的实现方式，ProxyFactoryBean ��是代表 Context 角色�Q�它�Ҏ��条�g选择使用 Jdk 代理方式�q�是 CGLIB 方式�Q�而另外三个类主要是来负责创徏具体�{�略对象�Q�ProxyFactoryBean 是通过依赖的方法来兌��具体�{�略对象的，它是通过调用�{�略对象�?getProxy(ClassLoader classLoader) �Ҏ��来完成操作�?/p>
回页�?/a>
�ȝ��

本文通过�?Spring 的几个核心组件入手，试图扑և�构徏 Spring 框架的骨骼架构，�q�而分�?Spring 在设计的一些设计理念，是否从中扑և�一些好的设计思想�Q�对我们以后�E�序设计能提供一些思�\。接着再详�l�分析了 Spring 中是如何实现�q�些理念的，以及在设计模式上是如何��用的�?/p>
通过分析 Spring �l�我一个很大的启示��是其这套设计理念其实对我们有很强的借鉴意义�Q�它通过抽象复杂多变的对象，�q�一步做规范�Q�然后根据它定义的这套规范设计出一个容器，容器中构建它们的复杂关系�Q�其实现在有很多情况都可以用�q�种�c�M��的处理方法�?/p>
虽然我很��x��我对 Spring 的想法完全阐�q�清楚，但是所�?#8220;书不��言�Q�言不尽意�?#8221;�Q�有什么不�Ҏ��者不清楚的地方大家还是看看其源码吧�?/p>

参考资�?
学习
“Spring �p�d��: Spring 框架��?/a>”�Q�developerWorks�Q?005 �q?8 月）�Q�在�q�由三部分组成的介绍 Spring 框架的系列文章的�W�一期中�Q�将开始学习如何用 Spring 技术构��量��的、强壮的 J2EE 应用�E�序�?br />
“AOP@Work: �?AspectJ �?Spring �q�行依赖��Ҏ��?/a>”�Q�developerWorks�Q?006 �q?1 月）�Q�依赖项插入和面向方面编�E�是互补的技术，所以想把它们结合在一起��用是很自然的。本文探索两者之间的关系�Q��ƈ了解怎样才能把它们组合在一��P��来促�q�高�U�的依赖��Ҏ��入场景�?br />
“Spring 2 �?JPA ��?/a>”�Q�developerWorks�Q?006 �q?8 月）�Q�您��学习如何用 Spring 2 框架从头开始创建服务器应用�E�序�?br />
查看本文作者的其它文章�Q?#8220;Tomcat �pȝ��原理分析”�?#8220;Tomcat 设计模式分析”�?br />
技术书�?/a>�Q�浏览关于这些和其他技术主题的图书�?br />
developerWorks Java 技术专�?/a>�Q�数癄��关于 Java �~�程各个斚w��的文章�?br />
获得产品和技�?/strong>
Springframework �|�站�Q�下�?Spring 框架�?br />
讨论
加入 developerWorks �C�֌��?br />
查看 developerWorks 博客的最��C��息�?br />

zhb8015 2012-05-28 17:53 发表评论

Java 动态代理机制分析及扩展�Q�第 1 部分(�?

zhb8015 — Mon, 28 May 2012 09:05:00 GMT

https://www.ibm.com/developerworks/cn/java/j-lo-proxy1/

zhb8015 2012-05-28 17:05 发表评论