How does the singleton Bean serve the concurrent request?

Question

I have a question regarding how singleton beans serve concurrent requests in detail.

I have searched on StackOverflow regarding this question. This is a sample link from stackoverflow, but I found only high level details. I want full details on how a singleton bean serves concurrent requests and how the system processor will see those requests.

I have researched regarding concurrent request handling in the system processor online. They said the processor itself has a scheduler and that scheduler will decide which request gets processed.

Ok fine. If suppose I have more than one core processor, how does the scheduler handle concurrent requests?

Can anyone explain to me the step-by-step process on how a singleton bean will serve concurrent requests in the JVM and system?

Let me explain with a concrete example. I have a class like Sports:

class Sports {     public void playFootball() {     }      public void playVolleyBall() {     } } 

Two requests come in. The first request is executing the playFootball method on the created singleton instance of class Sports. At the same time, another request is executing the playVolleyBall method on the same created singleton instance of class Sports.

How is it possible with a singleton instance?

Answer 1

Saravan Kumar,

I understand the motivation behind your question. Before I started working on compilers, I also had a very similar wanting to know the internals of the Java Virtual Machine.

First of all, I'm impressed by your question. There needs to be a couple of points of distinctions and understanding in order to solve your question. Firstly: A Singleton pattern, or sometimes even called an anti-pattern, ensures that there is only one instance of this class available to the JVM(Java Virtual Machine). This means we are essentially introducing a global state into an application. I know you understand this, but it is just a point of clarification.

Now the internals.

When we create an instance of a class, we are creating an object that is residing in JVM's shared memory. Now, these threads are independently executing code that operates on these instances. Each thread has a working memory, in which it keeps data from the main memory that are shared between all threads. This is where the reference to the Singleton object you have created resides. Essentially what is happening is that the bytecode which was generated and is representative of the singleton object you created is being executed on each one of these threads.

Now the internals of how this happens is as follows:

Each JVM thread has a private JVM stack, created at the same time as the thread. Now, The JVM has a heap that is shared among all JVM threads. The heap is the runtime data area from which memory for all class instances and arrays is allocated. The heap is created on VM start-up. When your thread requests the singleton instance, it is going to point to a reference in the heap where the bytecode for this Singleton resides. It is going to execute the appropriate code. In your case, it is going to execute the first method for the first request and the second method for the second request. It's able to do this because there are no locks or restriction preventing the compiler from pointing the program counter to the area in the heap where this instance is allocated. The only restriction that the Singleton class puts on the Java Virtual Machine is that it can have only one instance in the heap of this class. That's simply it. Other than that, you can refer to it 100x times from your method, the compiler is going to point to the same bytecode and simply execute it. This is why we typically want the Singleton class to be stateless because if we any thread access it, we don't want internal variables to be mutated because of the lack of concurrency control.

Please let me know if you have any questions!

Answer 2

An ideal singleton bean should not keep any state. That means it will not have any variables that store anything specific to the request it is serving.

Thus, a singleton bean will simply have stateless code (e.g. controller methods) that can be executed concurrently for multiple requests without any concurrency issues.

For example if following was your singleton bean:

@Service public class Calculator {     public int sum(int a, int b) {         return a + b;    }   } 

In simple terms, when two "requests" invoke sum method of the bean at the same time, that would mean the sum method would be executed concurrently in two different threads. Hence they will have their own execution context which wont overlap with each other. This would safely allow them to run concurrently.

If the same bean was to have state as follows:

@Service public class Calculator {     int incrementalMultiplier = 0;     public int mulitply(int a, int b) {         incrementalMultiplier++;         return a * b * incrementalMultiplier;    }   } 

This could cause issues when serving two requests concurrently because the incrementalMultiplier is the object level state that will be shared by the two requests (threads) and hence could produce unexpected results.

In short a stateless singleton will be able to serve two requests concurrently because they will be in different threads.