Java Servlet Multithreading

I have not found a detailed explanation of this problem on the Internet, or it may be that the explanation of the high person does not conform to my understanding. Therefore, I collected data on the Internet and added my own ideas. I wrote something and sent it to the Forum. I hope you can give me some suggestions and check whether I understand it correctly.
Generally, the servlet has only one object in the JVM. When multiple requests are sent to a JSP page, the servlet-type dopost or doget method compiled by the JSP is actually called.

Now I will simulate a servlet call process:

 
New runnalbe {public run () {request requset = new request (); resposne response = new response (); // only one servlet object is generated automatically by the container, simulate a servlet call process. Servlet. dopost (request, response );}}
 

When there are multiple requests, it is equivalent to multiple threads to execute this section.Code. The Servlet implementation class helloservlet above:

Public class helloservlet extends httpservlet {private Int J = 0; Public void dopost (httpservletrequest request, httpservletresponse response) {int I = 0; I ++; j ++; // The I and j here are thread-safe ones, but they are not. We will start from the thread stack, and the concept of JVM heap to explain this problem // whether the request and response objects are thread-safe }}
 

JVM is a stack-based virtual machine. JVM allocates a stack for each newly created thread (the stack here is not the heap ). that is to say, for a Java Program , it runs through stack operations. The stack stores the thread status in frames. JVM only performs two types of operations on the stack: frame-based stack pressure and outbound stack operations.
we know that the method being executed by a thread is called the current method of this thread. We may not know that the frame used by the current method is called the current frame. When a thread activates a Java method, JVM will press a new frame into the thread's java stack. This frame naturally becomes the current frame. during the execution of this method, this frame will be used to save parameters, local variables, intermediate calculation processes, and other data. this frame is similar to the activity record concept in the compilation principle.
here we also need to add the concept of heap:
heap is composed of instances and arrays, and there is no global variable in Java, all variables exist in the form of class attributes or parameters. GC is automatically recycled, but array and class references are stored in the stack. All those who have learned assembly know that the data is stored in the stack, and the executed code logic can be shared. When multiple threads access the same method, the same code logic is shared, but the data corresponding to the method is stored in the respective stacks, for example, local variables and parameters and object references (local variables and parameters may also be object references ). In the case of multi-thread concurrency, data is not synchronized mainly because the data stored in the respective Stacks is shared, to put it bluntly, the reference (not copy) of the same data is stored in different stacks. for example, object a of Class X is accessed by multiple threads, and its reference is stored in the stacks of multiple threads, when multiple threads access a certain attribute B of object A, non-synchronization occurs if the lock is not applied. To avoid this, lock the thread and generate an X-Class Object for each thread, in this way, the objects in the heap corresponding to Class X references stored in the stack of each thread are different. Of course, there is no sharing problem.

Now let's go back to the example. We can analyze the request, respone, And I parameters well, which are thread-safe, while J parameters are thread-insecure;

Why? Request and respone are thread-safe because the request and respone objects of each thread are different and there is no sharing problem. I is thread-safe. I is a local variable, and the values stored in the stack of each thread are also independent.
J. Thread anxiety is because it is a helloservlet-like attribute. I cannot tell whether it is put there after finding a lot of information. From the actual effect, it is insecure, so it should be placed in the heap together with the class object. It is estimated that the heap is copied in one copy, because helloservlet has only one instance for multiple threads, so there is a sharing problem.

 

Simply put:Servlet isMultithreading for a single instanceBecause the object variable thread is not safe and the local variable thread is safe.