Quando comecei a trabalhar com Spring, um dos conceitos que mais me intrigou foi a ideia de bean scopes. Spring fornece vários escopos de bean que determinam o ciclo de vida dos beans criados no contêiner Spring. Dois dos escopos mais comumente usados ​​são Singleton e Prototype. Compreender esses escopos é crucial para projetar aplicativos Spring eficientes e eficazes, então deixe-me explicar o que aprendi sobre eles.

Compreendendo os escopos do Spring Bean

No Spring, um bean é um objeto que é instanciado, montado e gerenciado pelo contêiner Spring IoC (Inversão de Controle). O escopo do bean refere-se ao ciclo de vida do bean – como e quando as instâncias do bean são criadas e quanto tempo elas duram.

Spring oferece vários escopos de bean, mas os dois em que vou me concentrar são:

• Escopo Singleton
• Escopo do protótipo

Cada escopo tem seus casos de uso específicos, e escolher o correto pode impactar significativamente o comportamento e o desempenho do seu aplicativo.

O escopo singleton

O escopo Singleton é o escopo padrão no Spring e é o que uso com mais frequência. Quando um bean é definido com o escopo Singleton, significa que o contêiner Spring criará apenas uma instância desse bean, e essa única instância será compartilhada em todo o contexto do aplicativo.

Como funciona

Quando declaro um bean como Singleton, o Spring cria a instância do bean na primeira vez que ele é solicitado, seja durante a inicialização do contexto da aplicação ou quando ele é referenciado pela primeira vez. Depois disso, cada solicitação subsequente para este bean retornará a mesma instância.

Aqui está um exemplo simples:

@Configuration
public class AppConfig {
    @Bean
    public MyService myService() {
        return new MyService();
    }
}

Neste exemplo, myService() é um bean Singleton. Cada vez que solicito um bean MyService do contexto Spring, obterei a mesma instância.

Casos de uso para feijões singleton

Descobri que o escopo Singleton é ideal para beans sem estado – aqueles que não contêm nenhuma informação específica do cliente. Os exemplos incluem:

• Classes de serviço: normalmente, essas classes contêm lógica de negócios que pode ser compartilhada entre o aplicativo sem a necessidade de instâncias separadas.
• Classes DAO: Como geralmente interagem com o banco de dados e não mantêm o estado específico do cliente, uma única instância é suficiente.

Benefícios e considerações

O principal benefício dos beans Singleton é a eficiência da memória. Ao reutilizar uma única instância, o aplicativo consome menos memória e a sobrecarga de criação e destruição de objetos é minimizada. No entanto, é importante ter cuidado com os beans Singleton que mantêm o estado. Se um bean Singleton mantiver estado inadvertidamente (por exemplo, variáveis ​​de instância), esse estado poderá ser compartilhado entre vários clientes, levando a possíveis inconsistências de dados.

O escopo do protótipo

Em contraste com Singleton, o escopo Prototype cria uma nova instância de bean toda vez que o bean é solicitado do contêiner Spring. Quando aprendi sobre isso, ficou claro que os beans Prototype são úteis para cenários onde preciso de uma nova instância para cada uso.

Como funciona

Quando um bean é definido com o escopo Prototype, o Spring retornará uma nova instância toda vez que o bean for solicitado. Veja como posso definir um bean Prototype:

@Configuration
public class AppConfig {
    @Bean
    @Scope("prototype")
    public MyService myService() {
        return new MyService();
    }
}

Neste exemplo, toda vez que eu solicitar o bean MyService do contexto Spring, o Spring criará uma nova instância de MyService.

Casos de uso para protótipos de beans

Os beans de protótipo são particularmente úteis ao lidar com beans com estado - aqueles que mantêm algum tipo de estado específico do cliente ou requerem configuração exclusiva para cada uso. Alguns casos de uso típicos incluem:

• Objetos de Comando: Se estou implementando um padrão como Command, onde cada comando é executado separadamente e mantém seu próprio estado, um bean Prototype é a escolha certa.
• Beans com escopo de sessão ou solicitação: Em aplicações web, beans específicos para uma sessão ou solicitação de usuário podem ser definidos como protótipo para garantir que uma nova instância seja criada para cada usuário ou solicitação.

Benefícios e considerações

A principal vantagem de usar Prototype beans é a flexibilidade que ele oferece na criação de novas instâncias. Isto é particularmente útil ao lidar com objetos com estado. No entanto, há uma compensação em termos de desempenho e uso de recursos. Como uma nova instância é criada sempre, isso pode levar a um maior consumo de memória e à coleta de lixo mais frequente. Além disso, diferentemente dos beans Singleton, o Spring não gerencia o ciclo de vida dos beans Prototype além da criação, então tenho que lidar com a destruição e limpeza desses beans manualmente.

Singleton vs. Protótipo: Escolhendo o Escopo Certo

Uma das principais decisões que enfrento ao projetar um aplicativo Spring é escolher entre o escopo Singleton e Prototype. Aqui está um resumo dos fatores que considero:

• Statefulness: Se o bean não tiver estado, Singleton geralmente é a melhor escolha. Para beans com estado, Prototype é mais apropriado.
• Gerenciamento de recursos: Beans singleton são mais eficientes em termos de memória, pois apenas uma instância é mantida. Os beans protótipo, embora ofereçam mais flexibilidade, consomem mais recursos.
• Gerenciamento do ciclo de vida: Beans Singleton são gerenciados pelo contêiner Spring durante todo o seu ciclo de vida. Em contraste, devo gerenciar todo o ciclo de vida dos beans Prototype.

Exemplo prático

Deixe-me apresentar um cenário prático que pode ajudar a esclarecer quando usar cada escopo. Suponha que eu esteja criando um aplicativo de compras online.

• Serviço de carrinho de compras: Este serviço normalmente seria sem estado e seria um bom candidato para um bean Singleton. Não há necessidade de criar uma nova instância todas as vezes, e o mesmo serviço pode lidar com várias solicitações.
• Processamento de pedidos: Por outro lado, o objeto Pedido que representa o pedido de um cliente teria estado, contendo detalhes específicos desse pedido. Portanto, deve ser um bean Prototype para que cada pedido seja tratado por uma instância separada da classe Order.

Misturando escopos: uma palavra de cautela

Uma coisa que aprendi da maneira mais difícil é que misturar beans Singleton e Prototype pode levar a problemas inesperados. Por exemplo, injetar um bean com escopo de protótipo em um bean Singleton pode fazer com que o bean Singleton sempre use a mesma instância do bean Protótipo. Para evitar isso, normalmente injeto um Provider ou uso a anotação @Lookup para garantir que uma nova instância do bean Prototype seja criada sempre que necessário.

@Service
public class SingletonService {

    @Autowired
    private Provider myPrototypeServiceProvider;

    public void usePrototypeService() {
        MyPrototypeService prototypeService = myPrototypeServiceProvider.get();
        prototypeService.execute();
    }
}

Neste exemplo, myPrototypeServiceProvider.get() garante que uma nova instância de MyPrototypeService seja criada toda vez que for chamada no bean Singleton.

Adeus !

Compreender as nuances dos escopos de bean Singleton e Prototype no Spring foi fundamental em minha jornada como desenvolvedor. Ambos os escopos oferecem vantagens distintas dependendo do caso de uso, e escolher o correto pode impactar significativamente o desempenho e o design de um aplicativo.

Na minha experiência, Singleton é o escopo ideal para a maioria dos beans devido à sua eficiência e simplicidade, enquanto Prototype é reservado para aqueles casos especiais em que preciso sempre de uma nova instância. Ao considerar cuidadosamente o estado dos meus beans e como eles são usados ​​no aplicativo, posso tomar decisões informadas que levam a aplicativos Spring melhores e mais fáceis de manter.