cableado primavera por tipo es más lento por la magnitud que el cableado por su nombre

Question

En mi proyecto, yo estoy tratando de migrar todos los usos de

Foo foo = (Foo) beanFactory.getBean("name"); 

en

Foo foo = beanFactory.getBean(Foo.class); 

Las ventajas son evidentes: la seguridad de tipos, código menos intrincado, constantes menos inútiles, etc. Normalmente, tales líneas se ubican en contextos heredados estáticos donde dicho cableado es la única opción.

Todo estuvo bien hasta que un día los usuarios comenzaron a quejarse por la lentitud que resultó de la parte interna de Spring. Así que dispararon hasta un generador de perfiles para encontrar un punto de acceso en

org.springframework.beans.factory.support.AbstractBeanFactory::doGetBean(String, Class<T>, Object[], boolean)

que tiene una llamada cara a

Class.isAssignableFrom(anotherClass).

he creado rápidamente una pequeña prueba de rendimiento para averiguar la diferencia de velocidad entre el nombre de la cadena y tipo búsquedas se un ferina 350 veces (estoy usando para este StaticApplicationContext FAIW prueba)!

Mientras investigaba esto, encontré SPR-6870 que tiene un gran número de votos pero por alguna razón no se menciona. Esto me llevó a an attempt to solve this problem que mejora significativamente la situación, pero aún es más lento ~ 25 veces que la búsqueda de String! Resulta que este intento solo resuelve la mitad del problema: almacena en caché el nombre del bean para guardar en la iteración de O (n) pero aún tiene que llamar al isAssignableFrom para validar el tipo.

El problema descrito no solo está relacionado con mi escenario, sino también con los beans que usan @Autowired y se puede sentir con dificultad en los casos en que se crean frijoles dentro de un bucle.

Una de las soluciones sería anular uno de los métodos de fábricas de frijoles y almacenar en caché los resultados de las verificaciones is-this-bean-of-the-same-type pero claramente esto debería hacerse en Spring y no en mi propio código.

¿Alguien más está sufriendo un problema similar y ha encontrado una solución para ello?

Answer 1

La mayoría de las aplicaciones de Spring combinan elementos al iniciarse, en lugar de extraer beans del contexto en el tiempo de ejecución. Aún así, a menos que cambie el contexto de su aplicación mucho durante la ejecución regular de su aplicación, nunca debería buscar un bean más de una vez.

Dado que, si sus usuarios se quejan de lentitud, parece que su problema real son demasiadas búsquedas de beans; su uso de un medio más lento de hacerlo acaba de surgir el problema real.

Me gustaría moverme a Java Config (configurar sus dependencias en Java, creo que es compatible con Spring 3.0) y configurar su aplicación para conectar todos los beans al inicio. Esto también tiene la ventaja de que su aplicación simplemente no se iniciará si no se pueden cumplir las dependencias.

Answer 2

Este problema ahora se resuelve en primavera con la resolución de SPR-6870. Vea los comentarios de resolución allí para más detalles. La corrección está disponible a partir de las versiones 3.2.0.RELEASE y 3.1.2.