Análisis de código fuente de Spring: caché de Spring y problemas de dependencia circular

Prefacio

Del análisis del artículo anterior, podemos ver que hay más enlaces en el proceso de creación y instanciación de beans en primavera y el empaquetado es más profundo. Si se necesitan tantos enlaces cada vez que getBean, entonces no solo producirá una gran cantidad de objetos de memoria y lógica de cálculo. Y, lo que es más importante, es incapaz de resolver el problema de la dependencia de los objetos en algunas escenas, especialmente el problema de la dependencia circular. Por lo tanto, Spring toma en consideración este problema y habrá algunos diseños de caché relacionados en el proceso de creación de beans. Hoy veremos cómo se resuelve mediante el almacenamiento en caché.

Escena de caché

Escenario 1. Al

obtener un bean por primera vez con getBean (), se obtendrá de la caché de primer o segundo nivel según el proceso de la figura anterior, y se devolverá directamente si se obtiene. Si no es así, tómelo directamente del caché de tercer nivel. Cuando hay un objeto almacenado en caché en el caché de tercer nivel, obtenga el bean directamente a través del beanFactory .getObject () en caché, elimine el caché de tercer nivel y escriba el bean obtenido en el caché de segundo nivel. Caché y luego devuelva el objeto.


Escenario 2.


Durante el proceso doCreateBean () durante el primer createBean () , si la configuración del bean se puede exponer por adelantado (habilitada de forma predeterminada), se creará una caché de tercer nivel (objeto beanFactory) .¿Por


qué se elimina la caché de segundo nivel cuando se crea la caché de tercer nivel? ¿Cache? Debido a que los objetos de la caché de segundo nivel se obtienen de la caché de tercer nivel, cuando se actualiza la caché de tercer nivel, los datos antiguos de la caché de segundo nivel se eliminarán al mismo tiempo para evitar el problema de los datos de caché inconsistentes.

Dependencia circular

En el objeto A, se mantiene la referencia al objeto B; de la misma manera, en el objeto B, también se admite la referencia al objeto A. Este tipo de dependencia circular se divide en dos situaciones: 1. En el objeto A, el objeto B se utiliza como una variable miembro del objeto A; 2. En el objeto A, el objeto B depende del parámetro de construcción del objeto A. Una vez que los dos métodos tienen influencia mutua La escena de referencia del anillo necesita atención.

La captura de pantalla anterior pertenece al primer caso, y Spring solo considera este caso. En este caso, el resorte se considera una referencia normal, en otros casos, el resorte no apoya y lanzará directamente una excepción en este caso.

solución

Entonces, ¿cómo resuelve la primavera la primera situación de dependencia circular anterior? Este problema se resuelve perfectamente mediante la construcción de un mecanismo de caché de tres niveles. Para el proceso de solución específico, consulte el siguiente diagrama de flujo.

De acuerdo con el diagrama de flujo de la solución anterior y el código fuente de la caché publicado, la explicación detallada es la siguiente:

1. Cuando se crea una instancia de CircularRefA, primero obtenga el bean de instancia del caché;
2. Cuando no haya objetos en los tres niveles de caché, llame a getSingleton () para crear una instancia;
3. Llame a la clase anónima para crear una instancia createBean ();
4. Cree una instancia del objeto CircularRefA a través del constructor (las propiedades de dependencia y los miembros del objeto no se instancian, es decir, el objeto CircularRefB es nulo en este momento);
5. Cree una caché de tercer nivel para almacenar en caché el objeto objectFactory correspondiente a CircularRefA;
6. Realice una inyección de dependencia en CircularRefA y luego active la operación getBean () del objeto CircularRefB;
7. El programa entra de forma recursiva en el paso 1 ... paso 6;
8. Cuando lo mismo vaya al paso 6, realice la inyección de dependencia en CircularRefA en CircularRefB para activar la operación getBean ();
9. En este momento, se puede obtener una referencia a CircularRefA de la caché de tercer nivel (aunque es solo un esqueleto), por lo que se inyecta CircularRefA;
10. Inmediatamente después de que se completa la instanciación de CircularRefB, se asigna a la variable miembro CircularRefB en CircularRefA a través de la inyección de dependencia;
11. Al final, se instancian los dos objetos, CircularRefA y CircularRefB (contienen las referencias del otro y también se asignarán en este momento);

OK, ¿entiendes aquí? El diseño del mecanismo de caché de tres niveles de Spring es muy interesante. Los interesados ​​pueden acudir al código fuente.
Finalmente, debemos hacer una conclusión clara: solo el tipo Scope = Singleton de beandefintion puede realizar el almacenamiento en caché y admitir la dependencia circular en el primer caso anterior Siempre que ocurran otros tipos de dependencias circulares, Spring arroja directamente una excepción. En cuanto a por qué Spring no admite el código fuente en otros casos, puede pensar en ello más o menos.

Observaciones finales

El problema sobre el almacenamiento en caché de primavera y las dependencias circulares se comparte aquí primero. Si tiene alguna pregunta sobre esto, puede dejar un mensaje directamente en el área de comentarios. ¡Continúe prestando atención a más productos secos con código fuente de primavera!