Les opérations et la maintenance m'ont demandé d'optimiser la vitesse de démarrage de SpringBoot, et c'est ce que j'ai fait !

Spring Boot est sans aucun doute le framework numéro un pour le développement back-end Java. Basé sur Spring Boot, il dispose d'une chaîne d'outils complète et de divers starters. Pour le développement commercial quotidien, on peut dire que les roues sont terminées.

Cependant, avec la popularité des microservices et l'ère du cloud natif, les applications Spring Boot ont exposé certains problèmes, les plus importants sont :

• Démarrage lent
• L'application prend trop de temps mémoire
• Les applications cloud natives ont des exigences relativement élevées en matière de vitesse de démarrage. Lorsqu’une expansion horizontale est nécessaire, ces nouvelles instances doivent être démarrées dans un délai suffisamment court pour traiter les nouvelles demandes le plus rapidement possible.
• Les applications cloud natives nécessitent le moins de ressources possible pour être utilisées pendant l'exécution. Réduire autant que possible les ressources occupées par une seule instance signifie que davantage de demandes d'accès peuvent être prises en charge au même coût.
• Les applications cloud natives nécessitent une taille d'emballage plus petite. Les applications cloud natives sont conditionnées sous forme d’images de conteneurs. Plus la taille de l'image de l'application est grande, plus l'espace de stockage requis est grand et plus il faut de temps pour pousser et extraire l'image.

En fait, nous savons tous que la majeure partie du temps de démarrage est due au fait que Spring doit charger divers beans, ce qui entraîne une diminution de la vitesse de démarrage

1. Initialisation retardée des beans

Généralement , il existe de nombreuses tâches fastidieuses dans SpringBoot , telles que l'établissement de la connexion à la base de données, la création initiale du pool de threads, etc., nous pouvons retarder l'initialisation de ces opérations pour optimiser la vitesse de démarrage. La propriété
spring.main.lazy-initialization a été introduite après Spring Boot version 2.2. Si elle est configurée sur true, tous les beans seront initialisés paresseusement.

spring:main:lazy-initialization: true

Après avoir activé l'initialisation différée localement, le démarrage peut être 1 à 2 secondes plus rapide.

Environnement	Configuration	(moyenne de dix fois) vitesse de démarrage
springboot2+jdk1.8		≈10.3s
	Initialisation paresseuse de Bean	≈8,63s

二、创建扫描索引

Spring5 之后提供了spring-context-indexer功能，可以通过在编译时创建一个静态候选列表来提高大型应用程序的启动性能。

先看官方的解释：

在项目中使用了@Indexed之后，编译打包的时候会在项目中自动生成META-INT/spring.components文件。

当Spring应用上下文执行ComponentScan扫描时，META-INT/spring.components将会被CandidateComponentsIndexLoader 读取并加载，转换为CandidateComponentsIndex对象，这样的话@ComponentScan不在扫描指定的package，而是读取CandidateComponentsIndex对象，从而达到提升性能的目的.

我们只需要将依赖引入，然后在启动类上使用@Indexed注解即可。这样在程序编译打包之后会生成
META-INT/spring.components文件，当执行@ComponentScan扫描类时，会读取索引文件，提高扫描速度。

<dependency>	<groupid>org.springframework</groupid>	<artifactid>spring-context-indexer</artifactid>	<optional>true</optional></dependency>

@Indexed@SpringBootApplicationpublic class Application {public static void main(String[] args) {SpringApplication.run(Application.class, args);}}

环境	配置	(十次平均值)启动速度
springboot2+jdk1.8		≈10.3s
	+延迟初始化Bean	≈8.63s
	+创建扫描索引	≈7.7s

Autres conseils :

1. Réduisez la portée de @ComponentScan @SpringBootApplication lors de l'analyse des classes

2 Désactivez la surveillance JMX de Spring Boot et définissez spring.jmx.enabled=false

3. noverify, ne vérifiez pas la classe

4. Retardez le chargement des beans qui n'ont pas besoin d'être chargés au démarrage 5. Utilisez le chargement paresseux global de Spring Boot

5. Essayez de ne pas utiliser d'annotations pour les aspects AOPQ, ce qui entraînerait toutes les méthodes. à analyser au démarrage 7. Désactivez certaines fonctions de surveillance des points de terminaison

6. Excluez les dépendances jar inutiles du projet

7. Lorsque swagger analyse l'interface, spécifiez d'analyser uniquement les classes sous un certain chemin 10. L'analyse de Feign l'interface client réduit la portée de l'analyse des packages

À ce stade, la vitesse de démarrage doit être considérée comme la plus optimisée, mais l'utilisation importante de la mémoire reste un problème

3. Mise à niveau de jdk17

Bien sûr, jdk a également fait un. beaucoup d'efforts dans ce domaine :

L'utilisation importante de la mémoire est principalement due à l'utilisation de la mémoire. Le système d'exploitation ne sera pas restitué à l'avenir, cela s'améliore progressivement :

• G1 JDK12 et versions ultérieures sont pris en charge
• ZGC JDK13 et versions ultérieures sont pris en charge

est basé sur les fonctionnalités du langage Java Et certaines méthodes d'implémentation de Spring Boot déterminent que même si la mémoire inutilisée de G1/ZGC est activée et renvoyée à Avec le temps, le système d'exploitation utilise la mémoire de Spring Boot comme étant beaucoup plus importante que celle des langages compilés tels que Golang.

Donc, si Java veut résoudre les problèmes de l'ère du cloud natif, les solutions actuelles sont essentiellement basées sur GraalVM, qu'il s'agisse de Quarkus ou de Micronaut.

Alors, Spring Boot propose-t-il une solution similaire ? ：spring-graalvm-native

4. La mise à niveau de SpringBoot3

spring-graalvm-native est une fonctionnalité très importante de springBoo6/SpringBoot3 Elle prend en charge l'utilisation de GraalVM pour compiler les applications SpringBoot dans des fichiers image exécutables locaux. vitesse de démarrage, performances maximales et réduction de l'utilisation de la mémoire.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!