Developing thread-safe Spring Web applications

Objective

If a developer is developing or maintaining a web-based application based on a servlet, the servlet specification suggests it is best to look at it. Because it contains content that is helpful for Web application developers to understand how the servlet container works.

Among them, the specification gives the servlet container how to handle customer requests. The servlet container will create the corresponding web.xml based on the individual Servet defined in the configuration file. As a result, multiple customer requests may access these single cases at the same time, that is, multiple threads access them at the same time. It is important to ensure thread safety in Web applications. Developers should be wary of this problem and must ensure that their code runs in a thread-safe way.

Brush up on thread safety

Most Java developers should have heard the Synchronized keyword. Java itself provides native support for threads without using any third-party libraries, and the Synchronized keyword is often the most important factor in implementing thread safety in Java applications. Synchronization in Java provides mutually exclusive support. Thread safety is achieved by synchronizing a piece of code or the entire method to ensure that at most one thread executes it at the same time. Introducing synchronization has side effects, that is, blocking. For example, a large company or a receptionist at a lawyer's office needs to deal with phone calls, emails, clients interviewed, and so on. This makes her work very busy and causes some things not to be dealt with in time.

You need to be wary of blocking in Web applications. A code block that is protected by synchronization reduces the throughput of the client request at the same time, and many customers are blocked unless a client finishes processing. and mutual exclusion not only leads to blocking, but also to deadlocks. In general, deadlocks are not recoverable. The following conditions trigger the occurrence of a deadlock: thread A locks the resource that thread B waits on, and thread B locks the resource that thread a waits on, that is, thread B waits for thread A to release the lock, and thread A does. Therefore, for multi-threaded applications, deadlock prevention and processing is often a headache.

In addition, the Synchronized keyword allows a large number of synchronization objects to be used everywhere, thereby introducing the possibility of deadlock. For example, the methods provided in Java.util.Hashtable and java.util.Vector are mutually exclusive protections, so try not to use them unless you really need them. Developers only need to use JAVA.UTIL.HASHMAP and java.util.ArrayList. Of course, the synchronization method in Java.util.Collections also uses the Synchronized keyword.

Although reentrant can be easier to manage, it introduces other issues. Reentrant code avoids the sharing of data between threads. Consider the following code (let's say the method in Java is thread-safe):

public Double pi() {
　 int a = 22;
　 int b = 7;
　 return new Double(a / b);
}

It is always thread-safe, regardless of the number of threads entering the method at the same time. Each thread maintains a stack that belongs to each thread and is not shared with other threads. Where each thread creates a method variable in the current method, including a static method, that belongs only to the current thread, which is stored in the current thread's stack. Therefore, when threads A and B enter the above methods at the same time, they create a and B. Because the above methods do not have data sharing, the above method is thread safe. Please note that 22/7 values are similar to PI values, but they are not equal.

Next, let's look at how to optimize the code.

private Double pi = null;
public Double pi() {
　 if (pi == null) {
　　 pi = new Double(22 / 7);
　 }
　 return pi;
}