Commençons par l'annotation @SpringBootApplication de la classe principale du programme.
D'abord, nous cliquons sur @SpringBootApplication:
nous voyons qu'elle est composée de quatre méta annotations @Target, @Retention, @Documented et @Inherited et @SpringBootConfiguration, @EnableAutoConfiguration, @ComponScanS ) Une annotation composée de trois annotations;
nous n'avons pas besoin d'en dire plus sur les méta-annotations. Ensuite, j'expliquerai les trois annotations @SpringBootConfiguration, @EnableAutoConfiguration et @ComponentScan.
Parlons de deux annotations simples @SpringBootConfiguration, des annotations @ComponentScan, et enfin l'annotation principale et la plus gênante @EnableAutoConfiguration.
一. @ SpringBootConfiguration
Nous cliquons sur @SpringBootConfiguration:
nous avons trouvé qu'il est composé de méta-annotations et de @Configuration, c'est-à-dire d'annotations @Configuration. Qu'est-ce que @Configuration? Cela signifie qu'il s'agit actuellement d'une classe de configuration.
En d'autres termes, notre classe de programme principale MainApplication est également une classe de configuration, mais c'est une classe de configuration principale.
二. @ ComponentScan
@ComponentScan, nous savons tous qu'il s'agit d'une annotation d'analyse de paquet, qui spécifie ce qu'il faut analyser.
三. @ EnableAutoConfiguration
Voilà, le plus important est enfin là.
Plus près de chez nous, nous cliquons sur l'annotation @EnableAutoConfiguration: nous avons
trouvé qu'elle est composée de 4 méta annotations et d'annotations @AutoConfigurationPackage, @Import ({AutoConfigurationImportSelector.class}).
Parlons d'abord de l'annotation @AutoConfigurationPackage, puis du rôle du composant importé par @Import ({AutoConfigurationImportSelector.class}).
1. @ AutoConfigurationPackage
Nous cliquons sur l'annotation @AutoConfigurationPackage: nous
trouvons qu'il s'agit en fait d'une annotation @Import. Qu'est-ce que le registraire importé? Cliquons et jetons un coup d'œil:
J'ai trouvé qu'il avait deux méthodes. En fait, Registrar doit enregistrer les composants par lots dans le conteneur. Parce qu'il est trop gênant d'importer un par un avec l'importation, alors écrivez un morceau de code pour enregistrer
par lots; nous mettons un point d'arrêt sur la première méthode, vous pouvez voir Quels composants enregistre-t-elle:
cette méthode a deux paramètres, comme suit:
AnnotationMetadata est les informations source de l'annotation et l'annotation fait référence à @AutoConfigurationPackage. Les informations source de l'annotation indiquent où l'annotation est marquée et la valeur de chaque attribut de celle-ci. , Cette annotation est l'annotation dans @SpringBootApplication, @SpringBootApplication est marquée sur la classe de programme principale MainApplication, elle est donc en fait marquée sur la classe de programme principale MainApplication.
On peut ouvrir les métadonnées pour voir ses informations lors du débogage: on
trouve que c'est bien sur la classe principale du programme, puis on continue à parler de cette méthode. Cette méthode a ici un nouveau PackageImports:
équivalent à obtenir nos informations de source d'annotation pour obtenir les nôtres Le nom du package, nous pouvons le laisser calculer le nom du package que nous obtenons:
vous pouvez voir que le chemin du package où la classe principale du programme MainApplication est calculée.
Parlons de cette méthode: après avoir obtenu le chemin de notre package, il obtient le nom du package de la classe principale du programme, puis encapsule le nom du package dans un tableau, puis l'enregistre pour nous dans le conteneur.
En d'autres termes, notre registraire équivaut à enregistrer tous les composants sous un certain emballage dans le conteneur par lots.
@AutoConfigurationPackage petit résumé:
- Utilisez Registrar pour importer une série de composants dans le conteneur
- Importez tous les composants du package où se trouve la classe de programme principale MainApplication
2. @ Importer ({AutoConfigurationImportSelector.class})
Utilisez le sélecteur pour importer certains composants dans le conteneur par lots.
Nous cliquons dans AutoConfigurationImportSelector:
le tableau renvoyé par notre méthode selectImports spécifie les composants à importer dans le conteneur, et la méthode getAutoConfigurationEntry est appelée dans la méthode selectImports. Étudions la méthode getAutoConfigurationEntry, entrez la méthode getAutoConfigurationEntry et mettons un point d'arrêt sur le corps de la méthode getAutoConfigurationEntry:
debug run, lorsque nous exécutons un par un pour obtenir la configuration, nous pouvons voir qu'il y a 130 configurations:
cliquez sur les configurations et vous trouverez 130 noms de classe complets. Expliquez que tous les 130 composants spécifiés par le nom complet de la classe doivent être importés dans notre conteneur:
alors comment savons-nous que ces 130 sont comme ça? Nous donnons un point d'arrêt à la méthode getCandidateConfigurations et re-debug:
entrez la méthode et constatez qu'elle utilise réellement ces chargeurs d'usine Spring pour charger certaines choses:
cliquez sur SpringFactoriesLoader.loadFactoryNames:
puis cliquez sur (List) loadSpringFactories (classLoaderToUse ):
Enfin, utilisez cette méthode pour charger tous les composants à notre place. D'où chargeons-nous tous les composants?
Nous mettons un point d'arrêt sur le corps de la méthode loadSpringFactories et re-debug:
vous pouvez voir qu'il charge un fichier de ressources ici, l'emplacement est: META-INF / spring.factories
En d'autres termes, tous les fichiers de l'emplacement META-INF / spring.factories dans notre système actuel sont analysés par défaut;
maintenant nous regardons le META-INF sous le paquet spring-boot-autoconfigure-2.4.1.jar:
Trouvé qu'il a un fichier spring.factories:
vérifiez le contenu du fichier, il y a un élément de configuration, org.springframework.boot.autoconfigure.EnableAutoConfiguration:
de la ligne 22 à la ligne 151, 130 lignes complètes de contenu:
ce sont nos 130 composants qui doivent être chargés , Ils sont tous ici, et ils sont tous codés en dur dans ce fichier de configuration, ce qui signifie que lorsque le fichier est codé en dur, spring-boot donnera toutes les classes de configuration chargées dans le conteneur dès son démarrage.
Mais est-ce que la réalité est la suivante: est-il vraiment nécessaire de charger les 130 composants dans le conteneur?
En fait non, notre SpringBoot a la fonction d'activer les éléments de configuration automatique à la demande.
Bien que toutes les configurations automatiques de nos 130 scènes soient chargées par défaut lors de leur démarrage. xxxxAutoConfiguration, mais sera éventuellement configuré à la demande, selon les règles d'assemblage conditionnel (@Conditional).
Par exemple, nous cliquons sur AopAutoConfiguration:
Dans cette classe, nous n'avons pas importé la classe Advice dans org.aspectj.weaver, donc sa classe interne AspectJAutoProxyingConfiguratio ne prendra pas effet:
