這是高性能的春天aop使用cglib或jdk代理沒有aspectj？

我們在不使用aspectj的情況下將Spring AOP實現到我們的應用程序中。我們將自動代理設置爲true，以使其使用CGLIB代理。這是高性能的春天aop使用cglib或jdk代理沒有aspectj？

我們將其作爲代理目標類='true'來解決代理錯誤的原因。作爲副作用，應用程序變得緩慢並需要較長時間執行。

有沒有辦法解決這個問題，這將有助於我們保持性能不變，同時避免代理錯誤。

<!-- 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>

顧問代碼如下： -

只提供了實現部分： -

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; 
     } 

}

來源

2014-05-09 boopathiraja

自動代理與Cglib或JDK Dynamic Proxies無關。無論你是困惑的事情，或者你的意思是說'代理目標級'是'真實的'。 –

yes proxy-target-class爲true。剛剛修改了這個問題。 – boopathiraja

CGLIB應該是更快，JDK代理使用反射內部（見Spring的JdkDynamicAopProxy），CGLIB代理通過生成的代碼直接調用目標方法

來源

2014-05-09 04:52:35

是的CGLIB應該會更快，但事實並非如此！請建議如果有其他事情應該幫助我解決這個問題？ – boopathiraja

什麼是慢？以後什麼時候啓動性能或性能已經建立？也許有JdkRegexpMethodPointcut的性能問題，我不知道。也許這是創建代理的數量很高，你似乎匹配了很多類和方法。此外，你的建議本身可能會很慢。你沒有在這裏展示他們。如果你的建議只是調用proceed()而不做別的事情會發生什麼？你甚至需要around()建議，或者before()或after()就夠了嗎？許多開放的問題。嘗試差異化調試，即一次更改一件事。首先根據建議簡化建議，以瞭解其性能影響。另外考慮使用正常的AspectJ匹配語法，而不是正則表達式匹配，也許這很慢。然後嘗試匹配較少的類並測量影響。

最後但並非最不重要的是，即使您不想聽到它，也可以考慮AspectJ，它不需要任何代理。特別是在編譯時編織時，您還可以最大限度地減少對啓動時間的影響。

來源

2014-05-09 07:04:50 kriegaex

問題在於性能稍後與啓動無關。還添加了顧問實施部分。我們已經使用around（）的建議。不使用aspectj的原因是安全問題。請爲解決方案提出建議。 – boopathiraja

我**已經提出了一種調試方法。你甚至嘗試過嗎？首先我們需要事實，解決方案可以從他們得出結論。順便說一句，安全問題聽起來像是一個相當普遍的殺手論點。爲什麼AspectJ比Spring AOP更危險或者不安全？ – kriegaex

是的事實如下： - 看點：我們有一個事件日誌組件用於日誌記錄。對於這方面，我們試圖應用建議。我們做了一次性能測試，結果確定AOP比AOP慢和沒有AOP。因此尋找幫助。建議我是否有其他更好的實施方法。正如你所說的AspectJ是一個殺手論證，我們確實有使用該Jar的安全問題。這是我們沒有這樣做的原因。 – boopathiraja

我看到的一個問題是與JdkRegexpMethodPointcut的使用相結合創建的代理的數量。

當確定是否需要執行建議時，有兩個部分在使用。首先是切入點的靜態部分。這基本上是創建代理的地方，在這種情況下，是基於名稱。你似乎有一些需要應用建議的豆子。

其次是在代理上爲每個方法調用執行的動態部分是。在你的情況下，這是一個基於JDK的正則表達式，它被執行以確定方法名稱是否匹配。現在已知JDK正則表達式阻塞比其他實現慢。

我期望與正則表達式結合使用的代理數量會減慢應用程序的運行速度。

我強烈建議您嘗試說服您的公司並允許使用AspectJ，爲什麼使用由數百萬開發人員使用的框架會有風險？使用AOP聯盟的東西（您現在正在使用的東西）的風險更大，因爲AspectJ使用的人數少得多。

來源

2014-05-12 07:43:11

這是高性能的春天aop使用cglib或jdk代理沒有aspectj？

回答

相關問題