Un scope de bean controla cuántas instancias crea el contenedor y cuánto viven. Los callbacks del ciclo de vida te permiten ejecutar código justo después de que un bean se construya y justo antes de que se destruya.
Un scope de bean controla cuántas instancias crea el contenedor y cuánto viven. Los callbacks del ciclo de vida te permiten ejecutar código justo después de que un bean se construya y justo antes de que se destruya.
@Service // singleton por defecto — un único OrderService compartido para toda la app
public class OrderService { }
@Component
@Scope("prototype") // instancia nueva en cada getBean/inject
public class ReportBuilder { }
La trampa clásica: inyectar un prototype en un singleton. El singleton se conecta una sola vez, así que conserva para siempre una única instancia prototype: la promesa de "nuevo cada vez" se rompe. Arréglalo con @Lookup, un ObjectProvider<ReportBuilder> o un scoped-proxy.
@Component
public class ConnectionPool {
@PostConstruct // se ejecuta tras inyectar las dependencias, antes de usarse
public void open() { /* abrir sockets, precalentar caches */ }
@PreDestroy // se ejecuta en el apagado ordenado del contenedor (solo singletons)
public void close() { /* liberar recursos */ }
}
Importante: Spring no llama a @PreDestroy en los beans prototype: los entrega y deja de rastrearlos, así que tú eres responsable de su limpieza.
Esto separa a quien trata Spring como magia de quien entiende el contenedor. El bug del singleton que sostiene un prototype es un escenario de entrevista favorito porque es sutil y provoca bugs reales en producción. Saber que los singletons deben ser stateless y thread-safe (se comparten entre todos los threads de petición) es la conclusión práctica que los entrevistadores esperan oír.
Una biblioteca de preguntas de entrevista de IT con respuestas detalladas — de Junior a Senior.
Donar