<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-2.5.xsd">
<bean id="u" class="com.bjsxt.dao.impl.UserDAOImpl">
</bean>
<bean id="userService" class="com.bjsxt.service.UserService" init-method="init" destroy-method="destroy" scope="prototype">
<!--
<property name="userDAO" ref="u" />
-->
<constructor-arg>
<ref bean="u"/>
</constructor-arg>
</bean>
</beans>
For the above Spring's bean.xml configuration, the initialization method and the destruction method are added. Since the configuration of the prototype mode is added, a new object will be returned for each request, so the destroy-method method will not take effect and be called.
Because Spring cannot be responsible for the entire life cycle of a prototype bean, after the container initializes, configures, decorates, or assembles a prototype instance, it hands it over to the client, and then ignores the prototype instance. Regardless of the scope, the container will call the initialization lifecycle callback methods of all objects, and for prototypes, any configured destructor lifecycle callback methods will not be called. It is the client code's responsibility to clean up prototype-scoped objects and release any expensive resources held by prototype beans. (One possible way to have the Spring container release resources held by a singleton-scoped bean is by using a bean's post-processor that holds a reference to the bean to be cleaned up.)
The following quotes other blogs explaining the difference between prototype and singleton
Reference address: https://www.cnblogs.com/lizhonghua34/p/4953500.html
The difference between spring scope prototype and singleton
1. Singleton scope
When the scope of a bean is set to singleton, there will only be one shared bean instance in the Spring IOC container, and all requests to the bean, as long as the id matches the bean definition, will only return the bean the same instance of . In other words, when a bean definition is set to singleton scope, the Spring IOC container will only create a single instance of that bean definition. This singleton will be stored in the singleton cache, and all subsequent requests and references to the bean will return the cached object instance. Note here that the singleton scope and the singleton in the GOF design pattern The example is completely different. The singleton design pattern means that only one class exists in a ClassLoader, and the singleton here means that a container corresponds to a bean, that is to say, when a bean is identified as a singleton, only one class in the spring IOC container will be used. One such bean exists. 2. prototype
For beans deployed in the prototype scope, each request (injecting it into another bean, or calling the container's getBean() method programmatically) will generate a new bean instance, which is equivalent to a new operation. For prototype Scoped beans, it is very important that Spring cannot be responsible for the entire life cycle of a prototype bean. After the container initializes, configures, decorates or assembles a prototype instance, it hands it over to the client, and then it The prototype instance goes unnoticed. Regardless of the scope, the container will call the initialization lifecycle callback methods of all objects, and for prototypes, any configured destructor lifecycle callback methods will not be called. It is the client code's responsibility to clean up prototype-scoped objects and release any expensive resources held by prototype beans. (One possible way to have the Spring container release resources held by a singleton-scoped bean is by using a bean's post-processor that holds a reference to the bean to be cleaned up.)
The problem that scope="prototype" is not written, the operation of adding or deleting a table in the project is to use an action, this action add, update, delete, save these methods, adding and modifying share a page, when the page gets the id, it represents the process The modification operation, and vice versa is the add operation. Because I forgot to write scope="prototype" when configuring the spring bean, the last accessed record is displayed every time it is added, and scope="prototype" will create a new action object when an object of this type is requested. If scope=prototype is not configured, it will not create a new action when adding it, and it will still retain the recorded information of the last visit. The action of the webwork is not thread-safe, and it is required that in a multi-threaded environment, a thread must correspond to an independent instance, singleton cannot be used. Therefore, when we configure the Webwork Action Bean in Spring, we need to add the attribute scope=”prototype” or singleton=”false”.
The singleton mode refers to the complete sharing of an object, including code space and data space. To put it bluntly, if a class is singleton, if the class has a member variable, then the value of the member variable is shared by each thread (somewhat Similar to static), when thread A assigns a value to the variable, thread B can read the value. Therefore, for the foreground Action, the singleton mode must not be used. It must be a thread request corresponding to an independent instance. By extension, as long as it is a class with data member variables, in order to prevent multiple threads from mixing data, singleton cannot be used. For the Service and Dao we use, the reason why we use singleton is because they do not use data member variables. If someone's Service needs data member variables, please set singleton=false. Prototype scope is used for stateful beans, while singleton scope should be used for stateless beans.