Производительность при запуске Spring @Configurable с ткачеством времени компиляции

Question

это мой первый вопрос о переполнении стека, поэтому, пожалуйста, будьте добры.

я запускаю приложение с

• пружина 2.5.х
• Настраиваемые аннотации
• Время компиляции (CTW)
• 1012 * Maven *
• затмение / AJDT

Я использую CTW, и все работает нормально. Но если я впервые создаю аннотированный класс, это занимает очень много времени. во второй раз это очень быстро.

Глядя на трассировку стека профилировщика для первого вызова, который я видел, 93% времени используется org.aspectj.weaver.internal.tools.PointcutExpressionImpl.matchesMethodExecution (Метод)

В трассировке стека второго вызова в этом методе используется только 1% времени. Еще хуже: первый вызов занимает примерно в 10 раз больше времени, чем второй.

Мне было интересно, так как я думал, что ткач больше не нужен в CTW.

Но, похоже, Spring начинает анализировать прототип bean-компонента только после того, как кто-то вызывает new в этом классе. Для анализа того, что нужно сделать, он использует aspectj weaver и готовится ускорить этот процесс для следующего вызова.

Есть ли у кого-нибудь опыт ускорения первого вызова инициализации аннотированного класса?

это фрагмент моего pom:

 <plugin>
 <groupId>org.codehaus.mojo</groupId>
 <artifactId>aspectj-maven-plugin</artifactId>
 <executions>
    <execution>
      <goals>
        <goal>test-compile</goal>
        <goal>compile</goal>
      </goals>
</execution>
 </executions>
 <dependencies>
   <dependency>
     <groupId>org.aspectj</groupId>
     <artifactId>aspectjtools</artifactId>
     <version>1.6.1</version>
   </dependency>
 </dependencies>
 <configuration>
 <verbose>true</verbose>
 <complianceLevel>1.5</complianceLevel>
 <source>1.5</source>
 <showWeaveInfo>true</showWeaveInfo>
 <outxml>true</outxml>
 <aspectLibraries>
   <aspectLibrary>
     <groupId>org.springframework</groupId>
     <artifactId>spring-aspects</artifactId>
   </aspectLibrary>
 </aspectLibraries>
 </configuration>
 </plugin>

Answer 1

С конфигурацией Spring в aop вы получаете некоторую степень абстракции и удобства, с другой стороны, Spring должен проделать большую работу во время загрузки классов, чтобы генерировать динамические прокси и переплетать классы. Это всегда будет иметь накладные расходы при запуске.

Однако время запуска сервера редко является критическим фактором, вы, как правило, измеряете время безотказной работы в днях, поэтому, на мой взгляд, минутный или более медленный запуск - это справедливая сделка, хотя это может раздражать в целях отладки.

Вы можете несколько снизить накладные расходы при первоначальной загрузке, если добавите некоторые процессы к запуску сервера для проверки приложения. Это помогает обеспечить заполнение сервера, поэтому ваш первый настоящий запрос не будет принят.

Если вам все-таки нужно быстрее запускаться или вы считаете, что накладные расходы неприемлемы, вы можете подумать о том, чтобы реализовать сочетания клавиш с ткачеством во время компиляции. При таком подходе все тяжелые работы выполняются во время компиляции, поэтому классы загружаются в сопоставимое время с неткаными версиями (в зависимости от того, что делает ткачество, конечно).

Answer 2

Я нашел ответ сам, когда проанализировал трассировку стека.

В дополнение к @Configurable with CTW я использую для управления транзакциями. Когда мой прототип bean-компонента, аннотированный @Configurable, загружается впервые, фабрика Spring Bean проверяет, совпадает ли какой-либо из наших советов aop :. Поэтому он использует библиотеку aspectj.

Так что мой оригинальный вопрос как-то вводил в заблуждение. Мы используем CTW для @Configurable, но в то же время используем LTW для управления транзакциями и безопасностью. Боб, сплетенный во время компиляции, должен быть снова сплетен во время загрузки.

Теперь я буду искать способ избежать LTW, так как время запуска имеет решающее значение в нашем процессе разработки.

Спасибо за ваши комментарии и ответы. Они помогли, подтолкнув меня в правильном направлении.