Solutions to thread safety issues in singleton mode in Java

This article mainly introduces relevant information on thread safety issues in Java singleton mode. I hope that through this article, everyone can understand and master the use of thread safety in singleton mode. Friends in need can refer to it

Java singleton mode thread safety issues

The default access scope of the bean provided by the SpringIOC container is singleton mode. That is, there is only one instance in the entire application life cycle. Therefore, under multi-thread concurrency, there will be thread safety risks. Our servlets under the MVC framework are thread-safe. Since the servlet is on the client side, there is relatively little concurrency, but for the web service side, it needs to be taken into consideration.

ThreadLocal class: Provides an independent copy of the variable (instance) for each thread, and accesses isolation from each different instance.
In the synchronization lock mechanism, the latecomer thread waits for the preceding thread to complete before it can access the member variable. ThreadLocal implements instance replication and isolates object access data conflicts. At the same time, it can also solve a small amount of the consumption and burden of life cycle management of a large number of instances in the prototype access mode. They are two realizations of "exchanging time for space" and "exchanging space for time". The former only provides a unique variable for different threads to queue for access, while the latter provides a copy for each thread, so it can be accessed at the same time without affecting each other. At the same time, the copy is stored in the memory and will not be accessed again next time. Regenerate the instance to reduce server resource consumption.

We know that in general, only stateless beans can be shared in a multi-threaded environment. In Spring, most beans can be declared as singleton scope. It is because Spring uses ThreadLocal to process non-thread-safe states in some beans (such as RequestContextHolder, TransactionSynchronizationManager, LocaleContextHolder, etc.), making them thread-safe, because stateful beans can be shared among multiple threads.

Thread safety issues: caused by global variables and static variables. If there are only read operations and no write operations on global variables and static variables in each thread, generally speaking, this global variable is thread safe; If multiple threads perform write operations at the same time, thread synchronization generally needs to be considered, otherwise thread safety may be affected.

1) Constants are always thread-safe (constant value)
2) Creating a new instance before each method call is thread-safe. (Different instances are isolated from each other)
3) Local variables are thread-safe (isolated)

Because every time a method is executed, local variables will be created in an independent space, and it is not a shared resource. Local variables include method parameter variables and method-internal variables.

Stateful: Has data storage and change functions. Stateful Bean, an object with instance variables, can save data and is not thread-safe.

Stateless: It is a one-time operation and cannot change the data. Stateless object (Stateless Bean), an object without instance variables, cannot save data, is an immutable class, and is thread-safe. In spring, the singleton mode is a shared instance to improve performance. Stateful beans are not safe in a multi-threaded environment, so the Prototype prototype mode is suitable. Prototype: Each request for a bean creates a new bean instance.

The above is the detailed content of Solutions to thread safety issues in singleton mode in Java. For more information, please follow other related articles on the PHP Chinese website!