Preguntas de la entrevista-8 Primavera

Que es IoC

IoC (Inversión de control) control de inversión / control de inversión. Es una idea, no una realización técnica. Se describe:
la creación y gestión de objetos en el dominio de desarrollo de Java .

Por ejemplo: la clase A existente depende de la clase B

Método de desarrollo tradicional: a menudo se usa manualmente la palabra clave new to new en la clase A. Aparece el objeto A B. El método de desarrollo usa el pensamiento de IoC: no
crea objetos a través de la palabra clave nueva , sino a través del contenedor de IoC (marco de Spring) para ayudar a crear una instancia el objeto. Qué objeto necesitamos, simplemente vaya directamente desde el contenedor de IoC.
De la comparación de los dos métodos de desarrollo anteriores: "perdimos un poder"
(el poder de crear y administrar objetos) y, por lo tanto, también obtenemos un beneficio (no es necesario considerar la creación y administración de objetos, etc.)

¿Por qué se llama inversión de control?

Control: se refiere al derecho a crear (instanciar, administrar) objetos

Reversión: el control se le da al entorno externo (marco Spring, contenedor IoC)

¿Qué problema resuelve IoC?

El grado de acoplamiento o dependencia entre objetos se reduce; los recursos se vuelven más fáciles de administrar; por ejemplo, puede implementar fácilmente un singleton si lo proporciona el contenedor Spring. Por ejemplo: una
operación existente para el Usuario se desarrolla utilizando la estructura de dos niveles de Servicio y Dao

Sin utilizar la idea de IoC, si la capa de servicio desea utilizar la implementación específica de la capa de Dao, debe
crear manualmente la nueva clase de implementación específica de IUserDao en UserServiceImpl a través de la nueva palabra clave UserDaoImpl (no directamente nueva
clase de interfaz).

Es perfecto, este método también se puede lograr, pero imaginamos el siguiente escenario:

De repente, recibió un nuevo requisito durante el proceso de desarrollo y desarrolló otra clase de implementación específica para la interfaz IUserDao. Debido a que la
capa del servidor se basa en la implementación específica de IUserDao, necesitamos modificar el nuevo
objeto en UserServiceImpl . Si solo hay una clase que hace referencia a la implementación específica de IUserDao, puede sentirse bien. La modificación no es muy laboriosa, pero si hay muchos lugares donde se hace referencia a
la implementación específica de IUserDao, una vez que se debe cambiar la implementación de IUserDao , entonces será un dolor de cabeza modificarlo.

Usando la idea de IoC, transferimos el control (creación, administración) del objeto al contenedor de IoC para su administración, y podemos "solicitarlo" directamente desde el contenedor de IoC cuando lo usamos.

IoC y DI no sean tan estúpidos para distinguir que
IoC (Inverse of Control) es una idea de diseño
o un patrón determinado. Esta idea de diseño es entregar el control de los objetos creados manualmente en el programa al framework Spring para que los administre. IoC también se usa en otros idiomas y no es
exclusivo de Spring. El contenedor de IoC es el portador utilizado por Spring para implementar IoC. El contenedor de IoC es en realidad un mapa (clave, valor) y
varios objetos se almacenan en el mapa . La implementación más común y razonable de IoC se llama Inyección de dependencia (DI).

Que es AOP

AOP: Programación orientada a aspectos, AOP es una continuación de OOP (programación orientada a objetos).

Veamos primero un ejemplo de programación orientada a objetos.

Por ejemplo: actualmente hay tres clases, Caballo, Cerdo, Perro, y las tres clases tienen dos métodos, comer y correr.

A través de la herencia en el pensamiento de programación orientada a objetos, podemos extraer una clase principal de Animal y luego poner los
métodos eat y run en la clase principal. Horse, Pig y Dog pueden obtener automáticamente los métodos eat () y run () heredando el Animal. clase. Esto reducirá una gran cantidad de código repetitivo.

Las ideas de programación de OOP pueden resolver la mayoría de los problemas de duplicación de código. Pero hay algunos problemas que no se pueden solucionar. Por ejemplo, si el
código duplicado aparece en la misma posición de varios métodos en la clase principal Animal , OOP no puede resolverlo.

/**
 * 动物父类
 */
public class Animal {
    
    

    /** 身高 */
    private String height;

    /** 体重 */
    private double weight;

    public void eat() {
    
    
        // 性能监控代码
        long start = System.currentTimeMillis();

        // 业务逻辑代码
        System.out.println("I can eat...");

        // 性能监控代码
        System.out.println("执行时长：" + (System.currentTimeMillis() - start)/1000f + "s");
    }

    public void run() {
    
    
        // 性能监控代码
        long start = System.currentTimeMillis();

        // 业务逻辑代码
        System.out.println("I can run...");

        // 性能监控代码
        System.out.println("执行时长：" + (System.currentTimeMillis() - start)/1000f + "s");
    }
}

Esta parte del código repetido generalmente se denomina colectivamente código lógico transversal.

Problemas con el código lógico transversal:

Problema de duplicación de código El código de lógica transversal y el código comercial se mezclan, el código está inflado y el AOP de mantenimiento constante se utiliza para resolver estos problemas

AOP adopta otro enfoque y propone un mecanismo de extracción horizontal para separar el código de lógica transversal y el código de lógica empresarial.

La división de código es relativamente fácil. La parte difícil es cómo aplicar silenciosamente el código de lógica horizontal a la lógica empresarial original sin cambiar la lógica empresarial original para lograr el mismo efecto que la original.

¿Qué problema resuelve AOP? A través del análisis anterior, se puede encontrar que AOP se
usa principalmente para resolver: sin cambiar la lógica comercial original, mejorar el código de lógica transversal, desacoplarlo fundamentalmente y evitar el código de lógica transversal. duplicación.

Por qué se llama AOP corte de programación orientado a aspectos: se refiere a la lógica transversal, el código de lógica comercial original no se mueve, solo puede operar el código lógico transversal, por lo que está orientado a la lógica transversal

Superficie: los códigos lógicos transversales a menudo afectan a muchos métodos, cada método es como un punto y varios puntos forman una superficie. Hay un concepto de rostro aquí

Tres formas de lograr aop:

Utilice la interfaz nativa de la API de Spring

Primero, es crear una interfaz de servicio, luego incluir la función del objeto de destino y luego crear una clase de implementación para implementar esta interfaz, y en segundo lugar, crear una clase para implementar varias interfaces mejoradas, como la
interfaz MethonBeforeAdvice mejorada previamente , la interfaz AfterReturningAdvice post-mejorada, etc., son todos métodos de mejora para el método de destino, y finalmente configuran aop: config en el archivo de configuración xml, el punto de entrada es la clase de implementación del servicio

Aspecto personalizado

En la clase de aspecto personalizado, podemos especificar algunos métodos de aspecto personalizados, antes, después, alrededor, etc. y
luego configurar el aop en applicationContext.xml. Necesita indicar qué clase de aspecto es, y luego escribir el nombre en el método en el método de mejora de notificaciones

Implementación del método de anotación

Primero, creamos una clase, escribimos métodos de mejora, antes, después, etc., y luego agregamos anotaciones a la
clase @Aspact para indicar que la clase actual es una clase de aspecto, y luego anotamos los métodos de mejora, como @before @ después, etc. Los parámetros dentro son La ruta de la clase que se va a mejorar y, finalmente, habilitan el soporte de anotaciones en el archivo de configuración.

Capa inferior: jdk se usa para interfaces, cglib no se usa

Hay dos formas principales de proxy dinámico en Spring AOP, proxy dinámico JDK y proxy dinámico CGLIB:

① El proxy dinámico JDK solo proporciona un proxy de interfaz y no es compatible con el proxy de clase. La interfaz principal de InvocationHandler y la clase Proxy, InvocationHandler
invoca el código en la clase de destino a través de la reflexión del método invoke (), tejiendo dinámicamente la lógica transversal y el negocio juntos; luego, Proxy usa
InvocationHandler para crear dinámicamente una instancia que se ajusta a una determinada interfaz , Genera un objeto proxy de la clase de destino.
② Si la clase de proxy no implementa la interfaz InvocationHandler, Spring AOP elegirá usar CGLIB para proxy dinámicamente la clase de destino. CGLIB (
Biblioteca de generación de código ) es una biblioteca de clases para la generación de código, que puede generar dinámicamente un objeto de subclase de una clase específica en tiempo de ejecución y cubrir métodos específicos y agregar código mejorado para lograr AOP. CGLIB es un proxy dinámico a través de la herencia, por lo que si una clase se marca como final, no puede usar CGLIB como proxy dinámico.
(3) La diferencia entre el proxy estático y el proxy dinámico es que el tiempo de generación de los objetos de proxy AOP es diferente. Hablando relativamente, el método de proxy estático de AspectJ tiene un mejor rendimiento, pero AspectJ requiere un compilador específico para el procesamiento, mientras que Spring
AOP no lo hace. requieren una compilación específica 器 处理。 Procesamiento.

3 asuntos de primavera

La secuencia de ejecución de la transacción es la siguiente: 1. Abra la transacción
2. Establezca el nivel de aislamiento de la transacción (si no está establecido, use el nivel de aislamiento predeterminado)
3. Ejecute SQL
4. Envíe la transacción

4. Problemas que surgirán de transacciones concurrentes
1. Lecturas sucias

La llamada lectura sucia significa que la transacción A lee datos que aún no han sido comprometidos por la transacción B. Por ejemplo, cuando el banco retira dinero, la transacción A inicia la transacción y luego cambia a la transacción B, y la transacción B inicia la transacción. -> retire 100 yuanes, luego vuelva a cambiar la Transacción A, la transacción A debe leer los datos originales en la base de datos, porque la transacción B tomó 100 yuanes y no se comprometió, el saldo de la cuenta en la base de datos debe seguir siendo el saldo original, que está sucio leyendo.

2. Lectura no repetible

La llamada lectura no repetible significa que ciertos datos se leen dos veces en una transacción y la lectura de datos es inconsistente. Tome el retiro bancario como ejemplo. La transacción A abre la transacción -> el saldo de la tarjeta bancaria es de 1000 yuanes, luego cambie a la transacción B, la transacción B abre la transacción -> la transacción B quita 100 yuanes -> envíe, el el saldo en la base de datos se convierte en 900 yuanes, vuelva a la transacción A en este momento, la transacción A verifica nuevamente para descubrir que el saldo de la cuenta es de 900 yuanes, por lo que para la transacción A, los datos del saldo de la cuenta leídos dos veces en la misma transacción son inconsistentes, que es lectura no repetible.

3. Lectura fantasma

La llamada lectura fantasma se refiere al descubrimiento de datos no operados durante una operación en una transacción. Por ejemplo, para la información del estudiante, la transacción A abre la transacción -> modifique el estado de inicio de sesión de todos los estudiantes en el día a falso, luego cambie a la transacción B, la transacción B abre la transacción -> la transacción B inserta una parte de los datos del estudiante, luego vuelve a la transacción A, y la transacción A se envía. Cuando encontré un dato que no había modificado, esta es una lectura fantasma, como si hubiera ocurrido una ilusión. La premisa para la aparición de lectura fantasma es que hay transacciones que han insertado y eliminado operaciones en transacciones concurrentes.

Las transacciones de primavera esencialmente usan transacciones de base de datos, y las transacciones de base de datos usan esencialmente bloqueos de base de datos, por lo que las transacciones de resorte esencialmente usan bloqueos de base de datos. Abrir transacciones de resorte significa usar bloqueos de base de datos;
las transacciones de resorte solo terminarán o retrocederán cuando detectan excepciones. Después de intentar / capturar en el programa, maneje las excepciones usted mismo sin tirarlas, entonces la transacción no se terminará ni se revertirá, perdiendo el rol original de la
transacción ; la transacción de primavera capturará todas las excepciones, pero solo las operaciones relacionadas con la base de datos de reversión, y solo la reversión solo será se revierte cuando se declara la configuración como rollbackForClassName = "Exception", la
transacción de primavera revertirá todas las operaciones de la base de datos en la misma transacción, esencialmente revertirá las operaciones de la base de datos en la misma conexión de base de datos;

Por qué Spring Transaction no puede garantizar la coherencia de los datos y la corrección de la lógica empresarial:

1. Si el método de transacción arroja una excepción, la operación de la base de datos se revertirá en este momento, pero otros métodos que se han ejecutado no se revertirán, por lo que no se puede garantizar la corrección de la lógica empresarial;
2. Incluso si el El método de transacción no genera una excepción, no se puede garantizar la consistencia de los datos (debido a que la operación de la base de datos en la interfaz de la transacción se envía a la base de datos después de que se completa la ejecución de toda la lógica de la interfaz, es probable que cause problemas de consistencia de datos antes y después de la la interfaz se envía finalmente a la base de datos), por lo que no se puede garantizar la corrección de la lógica empresarial;

Nivel de aislamiento El valor del nivel de aislamiento causa problemas
Lectura no comprometida 0 conduce a lecturas sucias Lectura confirmada
1 Evite lecturas sucias, permita lecturas no repetibles y lecturas fantasma
Lectura repetible 2 Evite lecturas sucias, lecturas no repetibles, permita lecturas fantasmas
Serializable 3 Serial Para leer, las transacciones solo se pueden ejecutar una a una, evitando lecturas sucias, lecturas no repetibles y lecturas fantasmas. La eficiencia de ejecución es lenta, así que tenga cuidado al usar

Nivel de aislamiento Valor de nivel de aislamiento	El problema
Lectura no comprometida 0	Porque las lecturas sucias
Lectura confirmada 1	Evite las lecturas sucias, permita lecturas no repetibles y lecturas fantasma
Lectura repetible 2	Evite lecturas sucias, lecturas no repetibles y permita lecturas fantasma
Serializable 3	Lecturas serializadas, las transacciones se ejecutan una a una, evitando lecturas sucias, lecturas no repetibles y lecturas fantasmas.

Nivel de aislamiento en primavera

ISOLATION_READ_UNCOMMITTED
Este es el nivel de aislamiento más bajo de la transacción, lo que permite que otra transacción vea los datos no confirmados de esta transacción. Este nivel de aislamiento producirá lecturas sucias, lecturas no repetibles y lecturas fantasmas.
ISOLATION_READ_COMMITTED
garantiza que los datos modificados por una transacción solo pueden ser leídos por otra transacción después de que se hayan confirmado. Otra transacción no puede leer los datos enviados por la transacción.
ISOLATION_REPEATABLE_READ // Lectura repetible
Este nivel de aislamiento de transacciones puede evitar lecturas sucias y lecturas no repetibles. Sin embargo, puede producirse una lectura fantasma.
ISOLATION_SERIALIZABLE
Este es el nivel de aislamiento de transacciones más caro pero más confiable. Las transacciones se procesan como ejecución secuencial.

5. @ Ensamblaje automático de anotaciones por cable

Utilice la anotación @Autowired para ensamblar automáticamente el bean especificado. Antes de usar la anotación @Autowired, debe configurarla en el archivo de configuración de Spring, <context: annotation-config
/>. Cuando
se inicia Spring IoC, el contenedor carga automáticamente un postprocesador AutowiredAnnotationBeanPostProcessor. Cuando el contenedor busca @Autowied, @Resource o @Inject, automáticamente encontrará el bean requerido en el contenedor IoC y lo ensamblará con las propiedades del objeto. . Cuando utilice @Autowired, primero consulte el tipo de bean correspondiente en el contenedor:
si el resultado de la consulta es exactamente uno, entonces el bean se ensamblará con los datos especificados por @Autowired;
si el resultado de la consulta es más de uno, entonces @Autowired buscará por nombre;
si el resultado de la búsqueda anterior está vacío, se lanzará una excepción. Al resolver, use required = false.

6. ¿Cuáles son las formas en que Sprin ensambla automáticamente los frijoles?

Hay 5 tipos de ensamblaje automático en la configuración xml de Spring Framework:
no: el método predeterminado es no realizar ensamblaje automático, y el bean se ensambla configurando manualmente el atributo ref.
byName: El ensamblaje automático se realiza por el nombre del bean, si la propiedad de un bean es la misma que el nombre de otro bean, se realizará el ensamblado automático.
byType: Montaje automático a través del tipo de datos del parámetro.
constructor: use el constructor para ensamblar, y los parámetros del constructor se ensamblan a través de byType.
autodetect: Detección automática, si hay un método de construcción, se ensambla automáticamente por construcción, de lo contrario, se ensambla automáticamente por tipo.

5. Los conceptos de varios sustantivos en Spring AOP:

(1) Punto de unión: se refiere al método ejecutado durante la ejecución del programa. En Spring AOP, un punto de conexión siempre representa la ejecución de un método.
(2) Aspecto: El módulo común extraído se puede utilizar para cortar varios objetos en forma transversal. El aspecto se puede considerar como una combinación de Pointcut y
Advice. Un aspecto puede estar compuesto por múltiples puntos y consejos. En Spring AOP, los aspectos se pueden implementar usando anotaciones @AspectJ en las clases.
(3) Pointcut: El pointcut se utiliza para definir qué puntos de unión se van a interceptar.
El punto de corte se divide en modo de ejecución y modo de anotación. El modo de ejecución puede usar expresiones de ruta para especificar qué métodos interceptar, como especificar interceptar agregar *, buscar *. El método de anotación puede especificar qué código modificado por anotación se intercepta.
(4) Aviso: se refiere a las
acciones que se realizarán en el punto de unión , es decir, lógica mejorada, como sumas de verificación de permisos, registros de registro, etc. Hay varios tipos de notificaciones, incluidas Alrededor, Antes, Después, Después de
regresar y Después de lanzar. (5) Destino: El objeto que contiene el punto de conexión, también conocido como el objeto del aviso (Aviso).
Dado que Spring AOP se implementa a través de un proxy dinámico, este objeto siempre es un objeto de proxy.
(6) Tejido: El proceso
de ejecutar la lógica mejorada (Consejo) en el método del objeto de destino (es decir, el punto de unión ) a través del proxy dinámico .
(7) Introducción: agregue métodos o campos adicionales a la clase notificada. Spring permite la introducción de nuevas interfaces (y las implementaciones correspondientes) a cualquier objeto que se esté utilizando como proxy. Por ejemplo, puede utilizar una importación para hacer que el bean implemente la
interfaz IsModified para simplificar el mecanismo de almacenamiento en caché.

6. ¿Qué tipos de consejos de primavera (Consejos) existen?

(1) Antes del aviso: la notificación ejecutada antes del punto de unión. (2) Después del
aviso: la notificación que se ejecuta cuando el punto de conexión sale (independientemente del retorno normal o la salida anormal). (3)
Aviso de entorno: una notificación que rodea un punto de conexión. Este es el tipo de notificación más potente.
Las notificaciones envolventes pueden completar comportamientos personalizados antes y después de que se llame al método. También puede elegir si continuar la ejecución del punto de conexión o devolver directamente su propio valor de retorno o lanzar una excepción para finalizar la ejecución.
(4) Aviso posterior a la devolución: la notificación se ejecuta después de que el punto de conexión se completa normalmente (si el punto de conexión arroja una excepción, no se ejecutará)
(5) Advertencia posterior al lanzamiento: el método arroja una notificación de excepción ejecutada al salir

①BeanFactroy usa la carga diferida para inyectar Beans, es decir, solo cuando se usa un Bean (llame a getBean ()), el Bean se carga y se crea una instancia. De esta manera, no podemos encontrar algunos problemas de configuración de Spring existentes. Si no se inyecta un determinado atributo de Bean, después de cargar BeanFacotry, no se lanzará una excepción hasta que se llame al método getBean por primera vez.
②ApplicationContext, que crea todos los Beans al mismo tiempo cuando se inicia el contenedor. De esta forma, cuando se inicia el contenedor, podemos encontrar errores de configuración en Spring, lo que es propicio para comprobar si se inyectan las propiedades dependientes.
Después de que se inicie ApplicationContext, todos los beans de instancia única se cargan previamente. Al cargar previamente los beans de instancia única
, puede asegurarse de que cuando los necesite, no tenga que esperar porque ya se han creado.

7. ¿Cuál es el ciclo de vida de Spring Bean?

Permítanme hablar primero sobre el ciclo de vida de Servlet: instanciación, inicialización inicial, recepción de servicio de solicitud, destrucción de destrucción;

El ciclo de vida del Bean en el contexto de Spring es similar, como sigue:

1. Instanciación
2. Asignación de atributos Rellenar
3. Inicialización
4. Destrucción

(1) Instantiate Bean:
para el contenedor BeanFactory, cuando un cliente solicita un bean no inicializado del contenedor, o necesita inyectar otra dependencia no inicializada al inicializar el bean, el contenedor llamará a createBean para instanciarlo. Para el contenedor ApplicationContext, cuando se inicia el contenedor, se crean instancias de todos los beans obteniendo la información en el objeto BeanDefinition.
(2) Configuración de propiedades del objeto (inyección de dependencia): El
objeto instanciado se encapsula en el objeto BeanWrapper. Luego, Spring
completa la inyección de dependencia basándose en la información en BeanDefinition y la interfaz de configuración de propiedades proporcionada por BeanWrapper.
(3) Procesando la interfaz Aware:
A continuación, Spring detectará si el objeto implementa la interfaz xxxAware e inyectará la instancia xxxAware relevante en el Bean:
① Si el Bean ha implementado la interfaz BeanNameAware, llamará al setBeanName (String
beanId) implementado por ella . método, aquí es el valor id del bean en el archivo de configuración de la primavera;
②If el Bean ha implementado la interfaz BeanFactoryAware, el método setBeanFactory () implementado por el que será llamado, y se pasó la propia fábrica de la primavera.
③Si el Bean ha implementado la interfaz ApplicationContextAware, llamará al método setApplicationContext (ApplicationContext) y pasará el contexto Spring;
(4) BeanPostProcessor:
Si desea realizar algún procesamiento personalizado en el Bean, puede hacer que el Bean implemente la interfaz BeanPostProcessor, que llamará al método postProcessBeforeInitialization (Object
obj, String s). (5) InitializingBean e init-method:
si el bean está configurado con el atributo init-method en el archivo de configuración de Spring, se llamará automáticamente a su método de inicialización configurado.
(6) Si el Bean implementa la interfaz BeanPostProcessor, se llamará al método postProcessAfterInitialization (Object
obj, String s); dado que este método se llama al final de la inicialización del Bean, se puede aplicar a la memoria o la tecnología de almacenamiento en caché; lo
anterior Pasos Una vez finalizado, el Bean se ha creado correctamente y, a continuación, se puede utilizar. (7) DisposableBean:
cuando el Bean ya no sea necesario, pasará por la fase de limpieza. Si el Bean implementa la interfaz DisposableBean, llamará a su método destroy () implementado;
(8) método destroy:
Finalmente, si el Configuración de Spring de Bean Cuando el atributo de método de destrucción está configurado en, el método de destrucción configurado se llamará automáticamente.

8. Alcance del frijol en primavera:

(1) singleton: alcance predeterminado, singleton bean, solo hay una instancia de bean en cada contenedor.
(2) Prototipo: cree una instancia para cada solicitud de bean.
(3) solicitud: crea una instancia para cada solicitud. Una vez completada la solicitud, el recolector de basura invalidará y reciclará el bean.
(4) Sesión: similar al alcance de la solicitud, la misma sesión comparte una instancia y diferentes sesiones usan diferentes instancias.
(5) sesión global: alcance global, todas las sesiones comparten una instancia. Si desea declarar una variable de almacenamiento compartida por todas las sesiones, entonces la variable global debe almacenarse en global-session.

9. Spring tiene varias formas de inyectar beans basados ​​en xml

(1) Establecer inyección de método; (2) Inyección de constructor: ①Establecer la posición del parámetro a través del índice; ②Configurar el tipo de parámetro a través del tipo;
(3) Inyección de fábrica estática;
(4) Fábrica de ejemplo;

10. La diferencia entre @Autowired y @Resource

(1) @Autowired se inyecta por ensamblado de tipo de forma predeterminada. De forma predeterminada, requiere que existan objetos dependientes (puede establecer su atributo requerido en falso).
(2) @Resource ensambla la inyección de acuerdo con el nombre por defecto. Solo cuando no se encuentra ningún bean que coincida con el nombre, la inyección se ensambla de acuerdo con el tipo.

13. ¿Qué patrones de diseño se utilizan en el marco de Spring?

(1) Modo de fábrica: BeanFactory es la encarnación del modo de fábrica simple, que se utiliza para crear instancias de objetos; (2) Modo singleton: Bean tiene por defecto el modo singleton.
(3) Modo proxy: la función AOP de Spring utiliza el proxy dinámico de JDK y la tecnología de generación de código de bytes CGLIB; (4) Método de plantilla: se utiliza para resolver el problema de la duplicación de código. Por ejemplo
, RestTemplate, JmsTemplate, JpaTemplate.
(5) Modo de observador: Defina una dependencia de uno a muchos en las claves de objeto. Cuando el estado de un objeto cambia, todos los objetos que dependen de él serán notificados y actualizados al frenar, como la implementación del oyente en Spring-ApplicationListener .

14. La diferencia entre BeanFactory y factoryBean

BeanFactory es una fábrica, es decir, un contenedor de IOC o una fábrica de objetos, y FactoryBean es un Bean. En Spring, todos los Beans son administrados por BeanFactory (es decir, el contenedor IOC). Pero para FactoryBean, este Bean no es un simple Bean, sino un Bean de fábrica que puede producir o modificar la generación de objetos. Su implementación es similar al patrón de fábrica y al patrón de decorador en el patrón de diseño.