Analyse du code source Spring - Spring Cache et problèmes de dépendance circulaire

Préface

De l'analyse de l'article précédent, nous pouvons voir qu'il y a plus de liens dans le processus de création et d'instanciation des beans au printemps et que l'empaquetage est plus profond. Si autant de liens sont nécessaires à chaque fois que getBean, alors non seulement il produira beaucoup d'objets mémoire et de logique de calcul , Et plus important encore, il est incapable de résoudre le problème de dépendance des objets dans certaines scènes, en particulier le problème de la dépendance circulaire. Par conséquent, spring lui-même prend ce problème en considération, et il y aura des conceptions de cache associées dans le processus de création de beans. Aujourd'hui, nous allons voir comment cela est résolu par la mise en cache.

Scène de cache

Scénario 1. Lorsque vous

obtenez un bean pour la première fois avec getBean (), il sera obtenu à partir du cache de premier ou de deuxième niveau selon le processus de la figure ci-dessus, et il sera retourné directement s'il est obtenu. Sinon, prenez-le directement dans le cache de troisième niveau. Lorsqu'il y a un objet mis en cache dans le cache de troisième niveau, récupérez le bean directement via le beanFactory.getObject () mis en cache, supprimez le cache de troisième niveau et écrivez le bean obtenu dans le cache de second niveau. Cache, puis renvoyez l'objet.


Scénario 2.


Pendant le processus doCreateBean () au premier createBean () , si les paramètres du bean peuvent être exposés à l'avance (activé par défaut), un cache de troisième niveau (objet beanFactory)


sera créé . Pourquoi le cache de second niveau est-il supprimé lors de la création du cache de troisième niveau? Cache? Étant donné que les objets du cache de deuxième niveau sont obtenus à partir du cache de troisième niveau, lorsque le cache de troisième niveau est mis à jour, les anciennes données de cache de deuxième niveau seront supprimées en même temps pour éviter le problème des données de cache incohérentes.

Dépendance circulaire

Dans l'objet A, la référence à l'objet B est conservée; de ​​la même manière, dans l'objet B, la référence à l'objet A est également prise en charge. Ce type de dépendance circulaire est divisé en deux situations: 1. Dans l'objet A, l'objet B est utilisé comme variable membre de l'objet A; 2. Dans l'objet A, l'objet B dépend du paramètre de construction de l'objet A. Une fois que les deux méthodes ont une influence mutuelle La scène de référence de l'anneau a besoin d'attention.

La capture d'écran ci-dessus appartient au premier cas, et Spring ne considère que ce cas. Dans ce cas, le ressort est considéré comme une référence normale.Dans d'autres cas, le ressort ne le supporte pas et lancera directement une exception dans ce cas.

Solution

Alors, comment Spring résout-il la première situation de dépendance circulaire ci-dessus? Ce problème est parfaitement résolu en construisant un mécanisme de cache à trois niveaux. Pour le processus de solution spécifique, veuillez consulter le diagramme suivant.

D'après le diagramme de solution ci-dessus et le code source du cache publié, l'explication détaillée est la suivante:

1. Lorsque CircularRefA est instancié, récupérez d'abord le bean instance à partir du cache;
2. Lorsqu'il n'y a aucun objet dans les trois niveaux de cache, appelez getSingleton () pour créer une instance;
3. Appelez la classe anonyme pour créer une instance createBean ();
4. Instanciez l'objet CircularRefA via le constructeur (les propriétés de dépendance et les membres de l'objet ne sont pas instanciés, c'est-à-dire que l'objet CircularRefB est nul pour le moment);
5. Créez un cache de troisième niveau pour mettre en cache l'objet objectFactory correspondant à CircularRefA;
6. Effectuez l'injection de dépendances sur CircularRefA, puis déclenchez l'opération getBean () de l'objet CircularRefB;
7. Le programme entre récursivement à l'étape 1 ... étape 6;
8. Quand il en va de même à l'étape 6, effectuez une injection de dépendance sur CircularRefA dans CircularRefB pour déclencher l'opération getBean ();
9. À ce stade, une référence à CircularRefA peut être obtenue à partir du cache de troisième niveau (bien que ce ne soit qu'un squelette), donc CircularRefA est injecté;
10. Immédiatement après que l'instanciation de CircularRefB est terminée, il est ensuite affecté à la variable membre CircularRefB dans CircularRefA via l'injection de dépendances;
11. En fin de compte, les deux objets, CircularRefA et CircularRefB, sont instanciés (ils contiennent les références de l'autre, et ils seront également affectés à ce moment);

OK, tu comprends ici? La conception du mécanisme de cache à trois niveaux de Spring est très intéressante. Ceux qui sont intéressés peuvent accéder au code source.
Enfin, nous devons faire une conclusion claire: seul le type Scope = Singleton de beandefintion peut effectuer la mise en cache et prendre en charge la dépendance circulaire du premier cas ci-dessus. Tant que d'autres types de dépendances circulaires se produisent, spring lève directement une exception. Quant à savoir pourquoi spring ne prend pas en charge le code source dans d'autres cas, vous pouvez y penser plus ou moins.

Remarques finales

Le problème de la mise en cache de printemps et des dépendances circulaires est d'abord partagé ici. Si vous avez des questions à ce sujet, vous pouvez laisser un message directement dans la zone de commentaire.Veuillez continuer à faire attention à plus de produits secs de code source de printemps!