在不使用aspectj的情况下，使用cglib或jdk代理在spring aop中有哪些高性能？

Question

we have implemented the spring AOP into our application without using aspectj. We made the auto proxy as true to make it use CGLIB proxy.

The reason we made it as proxy target class = 'true' to resolve the proxy error. as a side effect the application becomes slow and taking longer time to execute.

Is there a way out of this which will help us to keep performance intact and also to escape the proxy error.

<!-- Aspects -->
    <bean id="loggingAspect" class="web.aspect.LogAspectAroundMethod" />
    <!-- PointCut -->
    <bean id="myLogPointCut" class="org.springframework.aop.support.JdkRegexpMethodPointcut">
    <property name="pattern" value=".*" />
    <property name="excludedPatterns">
    <list>
    <value>.*.isDaemon.*</value>
    </list>
    </property>
    </bean>

    <!-- Advisor Around-->
    <bean id="myLogAroundAdvisor" class="org.springframework.aop.support.DefaultBeanFactoryPointcutAdvisor">
      <property name="adviceBeanName" value="loggingAspect" />
      <property name="pointcut" ref="myLogPointCut" />
    </bean>

    <bean id="aprProxy" class="org.springframework.aop.framework.autoproxy.BeanNameAutoProxyCreator">
    <property name="proxyTargetClass" value="true"/>
    <property name="beanNames">
    <value>*Delegate,*Builder*,*Impl*,*Controller,*Handler,*Helper</value>
    </property>
    <property name="interceptorNames">
    <list>
    <value>myLogAroundAdvisor</value>
    </list>
    </property>
    </bean>

Advisor code follows:-

Provided only the implementation part:-

    import org.aopalliance.intercept.MethodInterceptor;
    import org.aopalliance.intercept.MethodInvocation;

    public class LogAspectAroundMethod implements MethodInterceptor{

        public Object invoke(MethodInvocation methodInvocation) throws Throwable {

               Object result = methodInvocation.proceed();
               return result;
        }

}

Answer 1

CGLIB应该更快，JDK代理内部使用反射（请参见Spring的JdkDynamicAopProxy），CGLIB代理直接通过生成的代码调用目标方法

Answer 2

What is slow? Start-up performance or performance later when everything is already set up? Maybe there are performance issues with JdkRegexpMethodPointcut , I do not know. Maybe it is the high number of created proxies, you seem to match a lot of classes and methods. Furthermore, your advice themselves may be slow. You are not showing them here. What happens if your advice just calls proceed() and does nothing else? Do you even need around() advice or would before() or after() suffice? Many open questions. Try to debug differentially, ie change one thing at a time. First trivialise the advice as suggested in order to find out about their performance impact. Also consider to use normal AspectJ matching syntax instead of Regex matching, maybe that is slow. Then try matching fewer classes and measure the impact.

Last but not least, even if you do not want to hear it, consider AspectJ which does not need any proxies. Especially with compile-time weaving you can also minimise the impact on start-up time.

Answer 3

One problem I see is the amount of proxies created combined with the use of JdkRegexpMethodPointcut .

When determining if an advice needs to be executed there are 2 parts in play. First there is the static part of the pointcut. This is basically the point where the proxy is created and is, in this case, based on the name. You seem to have quite some beans which need the advice applied.

Second there is the dynamic part which is executed for each method call on the proxy. In your case that is a JDK based regular expression which is executed to determine if the method name matches. Now the JDK regexp impementation is known to be slower then other implementations.

I would expect the amount of proxies combined with the regexp is slowing your application down.

I would strongly urge you to try and convince your company and allow the use of AspectJ, why would there be a risk in using a framework that is used by millions of developers? There is more risk in using the AOP alliance thing (what you are using now) as that is used by far less people then AspectJ.