¡Unos minutos le llevarán a comprender rápidamente el conocimiento teórico del marco Spring!

1. Dos entendimientos centrales de Spring

Los dos núcleos de Spring son IOC (Inversión de Control) y AOP (Programación Orientada a Aspectos).

IOC Inversion of Control: De hecho, el derecho de administrar los objetos se entrega a Spring. En el pasado, era necesario tomar la iniciativa para crear objetos y controlar el tiempo. Ahora este derecho se transfiere al contenedor Spring, y el El contenedor Spring lo maneja de acuerdo con el archivo de configuración.Crea instancias y administra dependencias entre instancias, el acoplamiento flexible entre objetos también es propicio para reutilizar funciones. Para decirlo sin rodeos, IOC permite la creación de objetos sin ir a NUEVO, que Spring puede producir automáticamente de acuerdo con los archivos de configuración que proporcionamos. Cuando necesitamos objetos, podemos obtenerlos directamente del contenedor.

La ubicación del código de bytes y la información de la clase se configuran en el archivo de configuración de Spring. Cuando se genera el contenedor, el archivo de configuración se cargará para identificar la información del código de bytes y los objetos de la clase se crearán a través de la reflexión.

Métodos de inyección de COI: método setter, constructor, método de anotación

Programación orientada a aspectos AOP: De hecho, encapsula esos comportamientos públicos y extracciones lógicas que no tienen nada que ver con el negocio pero que afectan a múltiples objetos en un módulo reutilizable.Este módulo es en realidad un aspecto. Por ejemplo: gestión de registros, etc. Spring AOP utiliza un proxy dinámico. El proxy dinámico significa que el marco AOP no modifica el código de bytes, pero genera temporalmente un objeto AOP para el método en la memoria cada vez que se ejecuta. Este objeto AOP contiene todos los métodos del objeto de destino y el procesamiento mejorado. se realiza en un punto de corte específico y se vuelve a llamar al método del objeto original.

2. Spring admite varios ámbitos de beans

(1) singleton: el valor predeterminado es un bean singleton y solo hay un bean en un contenedor

(2) Prototipo: se crea un bean cada vez que se instancia un objeto

(3) solicitud: una solicitud crea un bean, y el contenedor de recolección de basura lo reciclará después de que finalice la solicitud

(4) sesión: similar a la solicitud, una sesión comparte un bean y el bean se reciclará después de que se cierre la sesión o la sesión

(5) sesión global: alcance global, todas las sesiones comparten una instancia. Si desea declarar una variable de almacenamiento compartida por todas las sesiones, puede almacenar la variable global en sesión global.

3. La diferencia entre BeanFactory y ApplicationContext

beanFactory es la interfaz más alta de Spring. Implementa algunas funciones básicas del contenedor de Spring. Es muy complicado de llamar y generalmente se usa para Spring. Cuando se inicia el proyecto, el bean no se instanciará inmediatamente, sino que solo se instanciará cuando se llame.

applicationContext es una subinterfaz de beanFactory, que amplía algunas funciones. Tan pronto como se inicie el proyecto, cargará el bean y lo colocará en el contenedor Spring, y luego lo obtendrá cuando se use.

4. Patrones de diseño utilizados por Spring Framework

(1) Modo de fábrica: el interior beanFactory utiliza un modo de fábrica simple para la producción de frijoles.

(2) Modo singleton: el bean es un singleton por defecto y solo hay un bean en un contenedor.

(3) Modo proxy: AOP en Spring se realiza a través del proxy dinámico JDK y la tecnología de código de bytes CGLIB.

(4) Método del observador: defina una dependencia de uno a muchos de las claves de objeto. Si cambia una propiedad de un objeto, otros objetos dependientes pueden ser notificados y actualizados en consecuencia. El Listener en Spring es ApplicationListener.

(5) Método de plantilla: realice la reutilización de código, como JpaTemplate y RestTemplate.

5. Método de implementación y principio de la transacción Spring

La esencia de las transacciones de Spring es el soporte de la base de datos para transacciones.Si la base de datos no admite transacciones, Spring no puede implementar transacciones. La base de datos implementa el envío y la reversión de datos mediante binlog y relog.

Los métodos de implementación son:

(1) Transacciones programáticas: implementación de métodos de gestión de transacciones como begintransactionManager(), commit() y rollback().

(2) Transacción declarativa: realizada por anotación @Transactional.

6. Tipo de notificación de primavera y ejecución

(1) Tipo de notificación previa: Ejecutado antes de que se ejecute el punto de corte.

(2) Tipo de notificación posterior: se ejecuta después de que el punto de corte se ejecuta normalmente.

(3) Tipo de notificación de excepción: se ejecuta cuando se produce una excepción en el punto de corte.

(4) Tipo de aviso final: ejecución final en el pointcut.

(5) Tipo de notificación circundante: los programadores pueden definir la configuración de notificación por sí mismos a través de la codificación para resolver otros problemas de tiempo de notificación.

7. Si el objeto Spring tiene por defecto una sola instancia o varias instancias, y si el bean singleton tiene problemas de seguridad de subprocesos

Los objetos Spring son singletons por defecto, pero se pueden configurar en varias instancias.

La clase correspondiente al objeto bean singleton puede tener variables miembro mutables.Cuando hay subprocesos para cambiar el valor de las variables miembro, los subprocesos múltiples operarán el bean, lo que causará problemas de seguridad de subprocesos. La razón de esto es: si la operación de subprocesos múltiples cambia la variable miembro, otros subprocesos no pueden acceder al bean, lo que genera confusión de datos.

Puede evitar establecer variables miembro variables en el objeto bean, definir una variable ThreadLocal y colocar todas las variables miembro variables dentro de la variable.

8. La diferencia entre la inyección de dependencia @Resource y @Autowired

@Resource Es una anotación proporcionada por Spring. Se ensambla por nombre de manera predeterminada. Si no se puede encontrar un bean coincidente por nombre, se ensamblará por tipo. Si no se puede encontrar por nombre, se informará un error. Pero debe saber que si la ejecución se especifica a través del atributo de nombre, solo se ensamblará de acuerdo con el nombre, si no se encuentra, se informará un error y no se ensamblará de acuerdo con la clase de tipo.

@Autowried Lo proporciona de forma nativa Java. Se ensambla de acuerdo con el tipo de forma predeterminada. El objeto dependiente debe existir de forma predeterminada. Si está vacío, debe establecer requerido en falso. Si desea implementar el ensamblaje por nombre, debe usar el nombre especificado junto con @Qualifier.

9. Escenarios de uso de @Qualifier

Debe usarse junto con @Autowired y no puede usarse solo. La combinación de los dos realiza el ensamblaje por nombre, que en realidad logra la misma función que @Resource.

10. Anotaciones comunes de Spring

@Component: se puede usar en varias capas para la creación de instancias de objetos

@Controller: para la capa de control, para instanciación de objetos

@Serveice: para la capa empresarial, para la creación de instancias de objetos

@Repository: para la capa dao, para la creación de instancias de objetos

@Value: inyección de dependencia para propiedades simples

@Resource: Para realizar el ensamble de objetos, por defecto es ensamblar de acuerdo al nombre, si no lo encuentra, puede ensamblar de acuerdo al tipo

@Autowried: Para realizar el ensamblaje de objetos, lo predeterminado es ensamblar según el tipo, si no se encuentra, se lanzará una excepción

@Qualifier: se usa junto con @Autowried para lograr el ensamblaje por nombre

@Bean: marque el método, dígale al método que genere un objeto bean y luego entréguelo a Spring para su administración y colóquelo en el contenedor

@ComponentScan: escaneo de componentes

@Configuración: tener esta anotación se considera una clase de configuración. Una vez que se inicia el sistema, Spring creará los objetos que deben crearse en él, los colocará en el contenedor de beans y los obtendrá cuando sea necesario.

@Transactional: colocado en el método, con función de gestión de transacciones

@Importar: Introducir el contenido de otra clase de configuración en la clase de configuración

@PostConstruct, @PreDestory: se utiliza para establecer las operaciones que deben realizarse después de crear el objeto Spring y antes de destruirlo

@PropertySource: se usa para introducir otros archivos de configuración de propiedades

11. Comportamiento de propagación de transacciones de Spring

El comportamiento de propagación de las transacciones en realidad se refiere a cómo Spring maneja estas transacciones cuando existen múltiples transacciones al mismo tiempo.

(1) propagación_requerida: si hay una transacción actual, únase a la transacción, si no hay transacción, cree una nueva transacción.

(2) propagation_support: admite la transacción actual. Si hay una transacción actualmente, únase a la transacción, si no hay transacción, ejecute como no transacción.

(3) propagación_not_support: Ejecutado como una no transacción. Si actualmente existe una transacción, la transacción pendiente se ejecuta de forma no transaccional.

(4) propagation_never: Ejecutar sin transacción. Se lanza una excepción si existe una transacción.

(5) propagación_requries_new: crea una nueva transacción, independientemente de si hay una transacción actual o no.

(6) propagation_mandatory: admite la transacción actual, si hay una transacción, únase a la transacción y, si no existe, elimine la excepción.

(7) propagation_nested: si hay una transacción actual, ejecutarla en una transacción anidada. Si no hay transacción, ejecute de acuerdo con el atributo requerido.

12. Nivel de aislamiento en primavera

(1) aislamiento_predeterminado: este es el aislamiento de transacciones predeterminado de PlatfromTransactionManager, utilizando el nivel de aislamiento predeterminado de la base de datos.

(2) aislamiento_lectura_uncommitted: lectura no confirmada, lo que permite que otra transacción vea los datos no confirmados de esta transacción.

(3) aislamiento_lectura_comprometida: lectura confirmada, para garantizar que los datos modificados por una transacción puedan ser leídos por otra transacción solo después de que se haya confirmado, y pueda ver la actualización de los registros existentes por la transacción. Resuelva el problema de los datos sucios.

(4) aislamiento_repetible_lectura: lectura repetible, para garantizar que los datos modificados por una transacción puedan ser leídos por otra transacción solo después de la confirmación, pero no se puede ver la actualización de los registros existentes por la transacción. tabla de filas.

(5) aislamiento_serializable: una transacción no puede ver las actualizaciones realizadas en la base de datos por otras transacciones durante la ejecución. Cerradura estándar.

Supongo que te gusta

Origin blog.csdn.net/lf21qp/article/details/131401317
Recomendado
Clasificación