Um scope de bean controla quantas instâncias o container cria e quanto tempo elas vivem. Os callbacks de ciclo de vida permitem rodar código logo depois que um bean é construído e logo antes de ele ser destruído.
Um scope de bean controla quantas instâncias o container cria e quanto tempo elas vivem. Os callbacks de ciclo de vida permitem rodar código logo depois que um bean é construído e logo antes de ele ser destruído.
@Service // singleton by default — one shared OrderService for the whole app
public class OrderService { }
@Component
@Scope("prototype") // fresh instance on every getBean/inject
public class ReportBuilder { }
A armadilha clássica: injetar um prototype em um singleton. O singleton é conectado uma vez, então ele mantém uma única instância prototype para sempre — a promessa de "novo toda vez" quebra. Corrija com @Lookup, um ObjectProvider<ReportBuilder> ou um scoped-proxy.
@Component
public class ConnectionPool {
@PostConstruct // runs after dependencies are injected, before use
public void open() { /* open sockets, warm caches */ }
@PreDestroy // runs on graceful container shutdown (singletons only)
public void close() { /* release resources */ }
}
Importante: o Spring não chama @PreDestroy em beans prototype — ele os entrega e para de rastreá-los, então você é dono da limpeza deles.
Isso separa quem trata o Spring como mágica de quem entende o container. O bug do singleton-segurando-um-prototype é um cenário favorito de entrevista porque é sutil e causa bugs reais em produção. Saber que os singletons precisam ser stateless e thread-safe (são compartilhados por todas as threads de requisição) é a lição prática que os entrevistadores esperam ouvir.
Uma biblioteca de perguntas de entrevista de TI com respostas detalhadas — de Júnior a Sênior.
Doar