Descripción general
En el artículo anterior, se presenta que si te inyectas en un frijol, si tienes @async y @Transaction, si te inyectas @autowire, informará una dependencia circular. Si te inyectas beanFactoryaware, @Transaction no será válido. Por ejemplo:
@ServicePublic clase myService implementa beanFactoryaware {private myService self; // La anotación de transacciones es inválida @Transactional public void NotWork () {...} @Async public Future Async () {...} @Override public void setBeanFactory (beanFactory BeanFactory) arroja beansexception {self = beanFactory.getBean (myService.class); }}Lo acabo de mencionar brevemente en ese momento, y este artículo es presentar por qué falló.
General
Se requiere que las siguientes condiciones se cumplan en la situación anterior:
El resultado es: a excepción de @async, la anotación surta efecto, y ninguna otra entra en vigencia, como se muestra en la figura a continuación
El proxy normal debe ser la siguiente figura:
razón
Lo primero que viene a la mente es que el método de procesamiento de la anotación de @Async puede ser diferente de los demás. En la implementación de AsyncannotationBeanPoanProcessor (el código específico está en su clase matriz abstractorbeanPostProcessor), se encontró un problema,
En circunstancias normales, el frijol que entra ya es una clase proxy dinámica que se está proxyes, y cuando falla, la clase real que entra es de hecho, como se muestra en la figura a continuación:
Luego, después de analizar el código, si se trata de una clase real, cuando llega a la línea 69, devuelve verdadero y agregue el asesor de @Aysnc al principio dinámico. Si se trata de una clase real, cuando alcanza la línea 83, creará una clase de proxy y solo agregará el asesor de @Aysnc al proxy dinámico, por lo que ya @Transaction ya no será válido.
¿Por qué no entran los agentes?
De hecho, la única diferencia es si se ha obtenido a través de BeanFactoryaware. Entonces, ¿por qué usas BeanFactory para conseguirte, y luego no eres un proxy en el posteriorpostprosor posterior? Si está familiarizado con el mecanismo de carga Spring @Transaction, sabrá que la creación de proxy dinámica como @Transaction y @cryryable Annotations se crea en AnnotationAwareAspectJaUtoProxyCreator. A través de la depuración, descubrimos que después de pasar por AnnotationAwareaspectJautoProxyCreator, nuestro proxy dinámico no fue agregado.
Echemos un vistazo a la implementación en AnnotationAweAspectJaUtoProxyCreator, pero después de eso, no se generó ninguna clase de proxy. La razón es que hay "MyService" en el mapa expuesto de antemano.
¿Cuándo fue expuesto? En realidad es
@OverridePublic void setBeanFactory (BeanFactory BeanFactory) arroja BeanSexception {self = beanFactory.getBean (myService.Class);}Entonces, todo salió a la luz. En el caso de MyService, BeanFactoryaware se activó y se creó una clase de proxy a través de BeanFactory.getBean (myService.class); (Consejos: la clase proxy actual no contiene el adivisor de @async), porque Spring en realidad está creando el frijol myService y aún no se ha puesto en la factor de beanfactory. Luego activamos BeanFactory.getBean (myservice.class); En este proceso, creamos el proxy y regresamos, y lo unimos al mapa expuesto por adelantado. Esto lleva a una serie de problemas que siguieron. Se siente un poco enredado. Habla con la imagen:
Normalmente, el siguiente proceso debe ser:
Este es el caso con una situación anormal
resumen
En circunstancias normales, use @Autowire para inyectar (si se usa Autowire, la situación anterior arrojará directamente la dependencia circular). Por supuesto, si hay un problema, no puede dejarlo ir. ¡Debes saber la razón y la razón!
Lo anterior es todo el contenido de este artículo. Espero que sea útil para el aprendizaje de todos y espero que todos apoyen más a Wulin.com.