可以将文章内容翻译成中文,广告屏蔽插件可能会导致该功能失效(如失效,请关闭广告屏蔽插件后再试):
问题:
We're using Spring (3.0.5) AOP with @AspectJ
style annotations and <aop:aspectj-autoproxy/>
. We use it for transactions, auditing, profiling etc. It works fine except that the startup time of the application is continuously growing as more code is being added.
I have done some profiling and found that most of the time is spent during Spring container initialization, more specifically org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(String, ObjectFactory)
- takes about 35 sec.
org.springframework.aop.support.AopUtils.canApply(Pointcut, Class, boolean)
- takes about 15 sec.
My goal is for the application to start in 5-10 seconds and not ~45 sec as it does now, so any tips would be much appreciated.
回答1:
I had the same issue, it turns out Spring AOP auto-proxying spends a LOT of time at startup loading classes with bcel (without caching, so loading again and again same classes like java.lang.Object...) when trying to figure out which advices apply.
It can be somewhat improved by writing more fine-grained Point cuts (use within, @within for example) but I've found a solution that worked better if all your pointcuts are written with @annotation.
1) Desactivate auto-proxy with: spring.aop.auto=false
2) Write a custom subclass of AnnotationAwareAspectJAutoProxyCreator to filter beans to be decorated according to your own criteria, for example this one is based on package and annotations :
@Override
protected Object[] getAdvicesAndAdvisorsForBean(Class<?> beanClass, String beanName, TargetSource targetSource) {
if (beanClass != null && isInPackages(beansPackages, beanClass.getName()) && hasAspectAnnotation(beanClass)) {
return super.getAdvicesAndAdvisorsForBean(beanClass, beanName, targetSource);
} else {
return DO_NOT_PROXY;
}
}
In my case startup time down from 60s to 15s.
I hope it will help someone and polar bears
回答2:
From what you've posted it looks like your using Load Time Weaving which incurs a startup penalty because the system has to weave all the classes as they are being loaded. If your primary concern is startup time, then I would suggest you switch to Compile Time Weaving. You can find instructions on how to do this in the spring documentation (Chapter 6, Section 8) or in at the AspectJ site (http://www.eclipse.org/aspectj/docs.php)
Switching to Compile time weaving with the AspectJ compiler is relatively stragiht forward:
- Remove the
<aop:aspectj-autoproxy/>
notation
from your context file.
- Add a
aspectJ compile step to your build
file. On the AspectJ site you should
be able to find an ant plugin,
codehaus has a maven plugin. Here
are examples of how to us both.
For Maven:
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>aspectj-maven-plugin</artifactId>
<version>1.3</version>
<configuration>
<verbose>true</verbose>
<source>1.6</source>
<target>1.6</target>
<complianceLevel>1.6</complianceLevel>
<showWeaveInfo>true</showWeaveInfo>
<aspectLibraries>
<aspectLibrary>
<groupId>org.springframework</groupId>
<artifactId>spring-aspects</artifactId>
</aspectLibrary>
</aspectLibraries>
</configuration>
<executions>
<execution>
<goals>
<goal>compile</goal>
</goals>
</execution>
</executions>
</plugin>
For Ant
<taskdef
resource="org/aspectj/tools/ant/taskdefs/aspectjTaskdefs.properties">
<classpath>
<pathelement location="${lib.dir}/AspectJ_1.6.8/aspectjtools.jar"/>
</classpath>
</taskdef>
<iajc aspectPath="${file.reference.spring-aspects.jar}; ${build.classes.dir}/path/to/custom/aspects"
classpath="${lib.dir}/AspectJ_1.6.8/aspectjrt.jar; ${javac.classpath}"
inpath="${build.classes.dir}"
destDir="${build.classes.dir}"
showWeaveInfo="true" />
回答3:
Apparently this is a known issue if you have a lot of non-singleton beans. There seems to be a fix for Spring 3.1: https://jira.springsource.org/browse/SPR-7328
回答4:
I am not sure that it applies to your situtation, but Spring performance can be improved by empolying a CachingBeanFactory.
This usually applies when wiring beans, but depending on how your aspects are applied and wired, it might bring improvements.
回答5:
Do you have any circular dependency? That's what's killing my current app.
I know that's not really a solution but I would break up the context to run different services in different vms, SOA-style. That should allow all your apps to have a small startup time and that should also give you some flexibility to change the implementation of these services more easily, small amount of code to test, etc.
I didn't do that in one of my apps and now startup time is at about 3/4 mins which is crazy (we have a couple of thousand beans). That problem doesn't go away, it will only get worse, but if you try to do something about it too late, the app will be too big and too difficult to break up.
Another thing I would look into is hibernate, creating the session factory can be pretty slow.
回答6:
I had the same problem, before I change jdk1.7 back to jdk1.6.
By jdk1.7, my app hang on “Initializing Spring root WebApplicationContext” for more tha 30 seconds. After I change back, it startup in 10sec.