still called, all the checks are still performed, and the method is still invoked using reflection. Obviously,
this incurs runtime overhead each time the method is invoked, even though the proxy often performs no
additional processing other than to invoke the unadvised method via reflection.
You can instruct the ProxyFactory to use a JDK proxy by specifying the list of interfaces to proxy
using setInterfaces() (in the AdvisedSupport class that the ProxyFactory class extends indirectly).
Using CGLIB Proxies
With the JDK proxy, all decisions about how to handle a particular Method Invocation are handled at
runtime each time the method is invoked. When you use CGLIB, CGLIB dynamically generates the
bytecode for a new class on the fly for each proxy, reusing already generated classes wherever possible.
When a CGLIB proxy is first created, CGLIB asks Spring how it wants to handle each method. This
means that many of the decisions that are performed in each call to invoke() on the JDK proxy are
performed just once for the CGLIB proxy. Because CGLIB generates actual bytecode, there is also a lot
more flexibility in the way you can handle methods. For instance, the CGLIB proxy generates the
appropriate bytecode to invoke any unadvised methods directly, reducing the overhead introduced by
the proxy. In addition to this, the CGLIB proxy determines whether it is possible for a method to return
this; if not, it allows the method call to be invoked directly, again reducing the runtime overhead.
The CGLIB proxy also handles fixed advice chains differently than the JDK proxy. A fixed-advice
chain is one that you guarantee will not change after the proxy has been generated. By default, you are
able to change the advisors and advice on a proxy even after it is created, although this is rarely a
requirement. The CGLIB proxy handles fixed advice chains in a particular way, reducing the runtime
overhead for executing an advice chain.
Comparing Proxy Performance
So far, all we have done is discuss in loose terms the differences in implementation between the different
proxy types. In this section, we are going to run a simple performance test to compare the performance
of the CGLIB proxy with the JDK proxy.
Let's create an ISimpleBean interface and its implementation class, SimpleBean, which we will use
as the target object for proxying. Listing 6-39 and Listing 6-40 show the ISimpleBean interface and
SimpleBean class, respectively.
Listing 6-39. The ISimpleBean Interface
package com.apress.prospring3.ch6.proxies;
public interface ISimpleBean {
public void advised();
public void unadvised();
}
Listing 6-40. The SimpleBean Class
package com.apress.prospring3.ch6.proxies;
public class SimpleBean implements ISimpleBean {
private long dummy = 0;
Search WWH :
