Zakres Beana (Scope)

Adnotacja @Scope

• Singleton
  Tak jak już wspominaliśmy, w ramach całego kontenera Springa istnieje tylko jedna instancja takiego obiektu. Co to oznacza w praktyce? To znaczy, że wstrzykując obiekt, w każdym miejscu wstrzyknięcia otrzymujemy dokładnie tą samą instancję obiektu. Zatem jeśli na przykład odczytamy adres obiektu w jednej klasie, to będzie on dokładnie taki sam w każdej innej klasie.

  @Component
  @Scope("singleton")
  public class ItemServiceImpl implements ItemService {
  
      ...
  }
  

  @RestController
  public class ItemController {
  
      final Logger LOG = ...
  
      @Autowired
      private ItemService itemService;    
      
      ...
      
      public void showServiceInfo() {
          LOG.info(itemService.toString());
      }    
  }
  

  @RestController
  public class ReportController {
  
      final Logger LOG = ...
  
      @Autowired
      private ItemService itemService;    
      
      ...
      
      public void showServiceInfo() {
          LOG.info(itemService.toString());
      }
  }
  

  Wywołując metodę toString na obiekcie ItemService, otrzymamy wskazanie na to samo miejsce w pamięci (zarówno w klasie ItemController jak i ReportController). W naszym przypadku na konsoli zostało wypisane:
  
  - ItemService@3a6609f2
  - ItemService@3a6609f2
  
  Tak samo będzie to wyglądało w każdej kolejnej klasie, do której wstrzykniemy ItemService. Oznacza to, że zmieniając obiekt w jednej klasie będziemy mogli tą zmianę odczytać w każdej innej klasie gdzie ten obiekt jest wstrzyknięty.
• Prototype
  Prototype oznacza, że w każdym kolejnym miejscu wstrzyknięcia będzie tworzona nowa instancja obiektu. Oczywiście w przypadku serwisów (klas oznaczonych adnotacją @Service) bezstanowych (stateless) nie ma to większego sensu, gdyż jedna instancja (jak w przypadku singletona) w zupełności wystarcza do obsługi operacji przetwarzania logiki biznesowej. Natomiast takie rozwiązanie staje się bardzo przydatne w przypadku klas przechowujących stan, gdy wymagane jest kolekcjonowanie danych niezależnie, w kolejnych miejscach wstrzyknięcia. Zobaczmy jak to będzie wyglądało na przykładzie klasy implementującej stworzony przez nas interfejs ItemCollector:

  @Component
  @Scope("prototype")
  public class DefaultItemCollector implements ItemCollector {
  
      ...
  }
  

  @RestController
  public class ItemController {
  
      final Logger LOG = ...
  
      @Autowired
      private ItemCollector itemCollector;    
      
      ...
      
      public void showCollectorInfo() {
          LOG.info(itemCollector.toString());
      }    
  }
  

  @RestController
  public class ReportController {
  
      final Logger LOG = ...
  
      @Autowired
      private ItemCollector itemCollector;    
      
      ...
      
      public void showCollectorInfo() {
          LOG.info(itemCollector.toString());
      }
  }
  

  Wywołując metodę toString na obiektach ItemCollector, otrzymamy wskazania na dwa różne miejsca w pamięci (inne w klasie ItemController, a inne w klasie ReportController). W naszym przypadku na konsoli zostało wypisane:
  
  - ItemCollector@20d8599c
  - ItemCollector@15849e84
  
  Widzimy więc, że ItemController i ReportController przechowują dwie różne instancje obiektu ItemCollector. Zmiana danych w jednym obiekcie ItemCollector nie będzie miała wpływu na dane przechowywane w drugiej instancji. Innymi słowy, zmieniając obiekt w jednej klasie nie będziemy mogli tej zmiany odczytać w innej klasie.
• Request
  Request oznacza, że nowa instancja obiektu będzie tworzona za każdym razem, gdy odbierzemy nowe żądanie (request) HTTP. W ten sposób możemy niezależnie przetwarzać dane tak, aby nie "mieszać" ich między kolejnymi żądaniami. Trzeba przy tym pamiętać, że takie rozwiązanie będzie generowało znaczną ilość obiektów, więc najlepiej będzie nie przechowywać w nich dużych kolekcji danych (konsumpcja pamięci wzrośnie wtedy ekstremalnie).

  @Component
  @Scope("request", proxyMode = ScopedProxyMode.TARGET_CLASS)
  public class ItemRequestComponent {
  
      ...
  }
  

  @RequestMapping("/api")
  @RestController
  public class ItemController {
  
      final Logger LOG = ...
  
      @Autowired
      private ItemRequestComponent itemRequestComponent;    
      
      ...
      
      @PostMapping(value = "/items/request")
      public String processRequest() {
          LOG.info(itemRequestComponent.toString());
      }    
      
  }
  

  Wywołując metodę toString na obiekcie ItemRequestComponent, otrzymamy wskazania na różne miejsca w pamięci dla każdego kolejnego żądania (requestu) wysłanego na ścieżkę "/api/items/request", na przykład:
  
  - ItemRequestComponent@aa51976d
  - ItemRequestComponent@41849f84
  - ItemRequestComponent@e5149e32
  ...
• Session
  Session oznacza, że nowa instancja obiektu będzie tworzona za każdym razem, gdy zostanie stworzona nowa sesja, a konkretnie nowy obiekt HttpSession. Umożliwia to na przykład stworzenie dedykowanej klasy, która będzie przechowywała podstawowe informacje o zalogowanym użytkowniku.

  @Component
  @Scope("session", proxyMode = ScopedProxyMode.TARGET_CLASS)
  public class CurrentUser {
  
      ...
  }
  

  @Service
  public class UserServiceImpl implements UserService {
  
      final Logger LOG = ...
  
      @Autowired
      private CurrentUser currentUser;    
      
      ...
      
      public void processUser() {
          
          LOG.info(currentUser.toString());
          
          ...
      }
  }
  

  @Service
  public class ItemServiceImpl implements ItemService {
  
      final Logger LOG = ...
  
      @Autowired
      private CurrentUser currentUser;    
      
      ...
      
      public void processUserItems() {
          
          LOG.info(currentUser.toString());
          
          ...
      }    
  }
  

  W tym przypadku, zarówno w klasie UserServiceImpl jak i ItemServiceImpl (a także w dowolnej innej klasie ze wstrzykniętym obiektem CurrentUser) otrzymamy tą samą instancję obiektu CurrentUser. Wykonanie metody toString zawsze wskaże na to samo miejsce pamięci (w ramach tej samej sesji). Jeśli mamy wielu użytkowników zalogowanych do aplikacji, wtedy dla każdego z nich będzie przypisana odrębna instancja obiektu CurrentUser.
• Application
  Application oznacza, że nowa instancja obiektu będzie tworzona raz i będzie istniała w ramach cyklu życia całego kontekstu serwletu (ServletContext). Zatem jeśli mamy więcej aplikacji działających w ramach tego samego ServletContext, to wszystkie te aplikacje będą współdzieliły jedną instancję obiektu.

  @Component
  @Scope("application", proxyMode = ScopedProxyMode.TARGET_CLASS)
  public class ApplicationSharedComponent {
  
      ...
  }
  

  Możemy powiedzieć, że zakres application rozszerza właściwości zakresu singleton, który jak pamiętamy umożliwia tworzenie jednego obiektu w ramach pojedynczego kontenera aplikacji. W przypadku kilku aplikacji uruchomionych w ramach jednego ServletContext, singleton - w przeciwieństwie do application - utworzy kilka instancji obiektu.
• Websocket
  Websocket to ostatni rodzaj zakresu, który jest udostępniony przez obecną wersję Springa (Spring 5). W tym przypadku będzie istniała jedna instancja obiektu per sesja WebSocket-u:

  @Component
  @Scope("websocket", proxyMode = ScopedProxyMode.TARGET_CLASS)
  public class WebsocketSessionComponent {
  
      ...
  }
  

Gdzie się podział zakres globalSession?

ScopedProxyMode - TARGET_CLASS

java.lang.IllegalStateException: 
No thread-bound request found: Are you referring to request attributes outside of an actual web request, 
or processing a request outside of the originally receiving thread?

Wisienka na torcie

W zasadzie wszystko co chcielibyśmy tu napisać zostało już gdzieś "przemycone" w treści tego rozdziału. Możemy ewentualnie jeszcze dodać, że najczęściej używanym scopem w trakcie naszej przygody ze Springiem był i jest scope domyślny czyli singleton. Natomiast prawdą jest też, że każdy z tych zakresów jest bardzo potrzebny, a i nieraz ich specyficzne właściwości stają się wręcz niezastąpione, gdy potrzebujemy wykonać zadanie, do którego jedna instancja nam nie wystarczy.

Praktyka

W zdecydowanej większości przypadków używamy zakresu singleton, jednak zdarzają się przypadki użycia zakresu request oraz session.

Autor: Jarek Klimas

Data: 03 stycznia 2024

Labele: Backend, Podstawowy, Java

Czy informacje, które otrzymałeś, były pomocne?
Jeśli tak, zapraszam Cię do podarowania mi kawy.

Topowe Materiały

Spring IO: Bean Scopes
Baeldung: Quick Guide to Spring Bean Scopes

Udemy: [NEW] Spring Boot 3, Spring 6 & Hibernate for Beginners  —  polskie napisy