Scope of Bean

In short, bean s are objects initialized, assembled, and managed by the IoC container.
There are four scopes:

1.singleton

When the scope of a bean is Singleton, only one shared bean instance will exist in the Spring IoC container, and all requests to the bean will return only the same instance of the bean as long as the id matches the bean definition.

Singleton is a singleton type, which automatically creates an object of a bean at the same time the container is created. It exists regardless of whether you use it or not, and the object you get is the same object each time.

Note that the Singleton scope is the default scope in Spring.

To define a bean as a singleton in XML, you can configure it as follows:

Mode 1:
<!--P(attribute: properties)Namespace , Property still to be set set Method-->
<bean id="user" class="com.kuang.pojo.User" p:name="Crazy" p:age="18" scope="singleton"/>


Mode 2:
<!--P(attribute: properties)Namespace , Property still to be set set Method-->
<bean id="user_second" class="com.kuang.pojo.User" p:name="Crazy" p:age="18"/>

Test:

@Test
public void test03(){
    ApplicationContext context = new ClassPathXmlApplicationContext("User.xml");
    User user = (User) context.getBean("user");
    User user2 = (User) context.getBean("user");
    System.out.println(user==user2);
}

Result:true

2. prototype (noun, prototype)

When the scope of a bean is Prototype, it means that a bean definition corresponds to multiple object instances.

A Prototype scoped bean causes a new bean instance to be created each time it is requested (injected into another bean, or programmatically called the container's getBean() method).

Prototype is a prototype type type type that is not instantiated when we create containers, but creates an object when we get bean s, and each time we get objects, they are not the same object.

As a rule of thumb, a prototype scope should be used for stateful beans and a singleton scope for stateless beans.

Beans are defined as prototype s in XML and can be configured as follows:

Mode 1:
<bean id="user" class="com.kuang.pojo.User" p:name="Crazy" p:age="18" scope="prototype"/>
  
Mode 2:
<bean id="user" class="com.kuang.pojo.User" p:name="Crazy" p:age="18" singleton="false"/>

Test:

@Test
public void test03(){
    ApplicationContext context = new ClassPathXmlApplicationContext("User.xml");
    User user = (User) context.getBean("user");
    User user2 = (User) context.getBean("user");
    System.out.println(user==user2);
}

Result: false

3. request

When a bean's scope is Request, it means that in an HTTP request, a bean definition corresponds to an instance; That is, each HTTP request has its own bean instance, which is created from a bean definition. This scope is only valid in the web-based Spring ApplicationContext scenario. Consider the following bean definitions:

 <bean id="loginAction" class="cn.csdn.LoginAction" scope="request"/>

For each HTTP request, the Spring container creates a new LoginAction bean instance based on the definition of the loginAction bean, which is valid only within the current HTTP request, so you can safely change the internal state of the created instance as needed, while the other requests create instances based on the definition of the loginAction bean. You will not see these state changes specific to a request. When processing a request ends, the bean instance of the request scope will be destroyed.

4. session

When a bean has a scope of Session, it means that in an HTTP Session, a bean definition corresponds to an instance. This scope is only valid in the web-based Spring ApplicationContext scenario. Consider the following bean definitions:

 <bean id="userPreferences"   class="com.foo.UserPreferences"   scope="session"/>

For an HTTP Session, the Spring container creates a new instance of the userPreferences bean based on the userPreferences bean definition, and the userPreferences bean is valid only within the current HTTP Session. As with request scopes, you can safely change the internal state of the instances you create as you want, while other HTTP Sessions that create instances based on userPreferences will not see these state changes specific to an HTTP Session. When an HTTP Session is eventually discarded, the beans within that HTTP Session scope are also discarded.