Small knowledge, big challenge! This article is participating in the creation activity of “Essential Tips for Programmers”

Introduction: To understand the origin of springMVC thread safety problems, we need to do an analysis of SpringMVC and Struts2.

SpringMVC is a method-based interception, whereas Struts2 is class-based interception. Struct2 instantiates an action for each request so there is no thread-safety issue. SpringMVC default singleton requests use a Controller, and if static variables are defined in this Controller they are shared by multiple threads. So springMVC controllers don’t define static variables as much as possible. You can use ThreadLocal or @Scope(“prototype”) to enable running in non-singleton mode, but there is an overhead associated with running in this way.

Thread safety: Data sharing (i.e., competition) issues.

If multiple threads share the same data, it is possible to manipulate the data simultaneously. At this point, data may be inconsistent with the expected results or deadlocks may persist, which is a thread safety issue. Speaking of multithreaded sharing, memory in the Java platform includes the following: Stack, Heap, and non-heap, where Stack is thread exclusive, and Heap and non-heap are shared between threads. Stack: Each thread has its own stack, which is mainly used to store the values of local variables, i.e. references to objects. Heap: All objects are placed in the heap, and the values of instance variables are stored in the heap space. Instance variables can be shared by multiple threads. Non-heap: Static variable values are stored in the non-heap space and are shared between threads. There are the following classes:

class Test{ private int a=0; private static int b=1; public void demo(){ int c=0; boolean flag = true; List<String> list=new ArrayList<>(); }}Copy the code

Analysis:

Where a is an instance variable that is shared by multiple threads (Test if single column), B is a static variable (class variable) that is shared by multiple threads, and C is a local variable that is held on a thread’s own stack and that holds references to objects on the heap. There’s also an ArrayList object that’s instantiated that’s on the heap and this one can be shared, but for the object in this example the demo generates an ArrayList instance every time it’s called, so the object referenced by the list variable is actually only accessible by one thread. So that’s using singletons and multiinstances. In singleton mode, thread-safety concerns arise when classes have static and instance variables, and some collection operations are best performed using the related methods in java.util.concurrent.

Conclusion:

SpringMVC shows that thread safety is closely related to its design pattern, so if a class variable is accidentally defined in a class, then the class variable is shared by all requests, which may cause multiple requests to modify the value of the variable, resulting in inconsistencies or exceptions that are not expected. So we’re trying to sidestep this when we write and use ThreadLocal or @scope (“prototype”) to handle sharing if needed.