Java memory for singleton object

The Java Virtual Machine (JVM) manages the memory of the operation system in order to obtain the best performance by optimizing the usage of it.

In this article, I’ll put the focus on a particular part of the memory which involves the Singleton object in Java. This type of object, always more frequently used, make a good deal between the memory optimization and the performance result.

Connection pool, resource manager and configuration objects are only a few examples of how many kind of object are, in good practice, implemented as Singleton object.

Sometimes happens that I find out by the code that I look at the web, that’s not very clear how they works and it’s worth to spend this article to clear the fog…

First of all, a very brief explanation of Java memory arrangement.

Fundamentally, JVM splits the memory in two parts:

  • Java Heap: It’s where all Java object created by the applications that are running are stored. When it comes up to line contained “…new object()” this object goes to Heap.
  • Thread Stack: It’s where the thread and the method of the Java object are executed driving by the thread. In this area the local variables are hold and updated.

When a object is deallocated , then the Garbage collector remove the object from the heap in order to avoid memory leaks.

Putting the focus of what happens in memory with singleton object, let’s take the singleton objects “Reader” and “Writer”.



By the definition of singleton object, there’ll be only an instance of Reader object and Writer object in the context.

The first object contains the “read” method while the other the “write” method.

BufferedReader read(){
   String fileName;

void write(){
   String fileName;

Now, imaging the two class instances are running in a concurrency application, thus, multiple thread could access the same object (the only object instance) in the same time by different threads.






All these threads are hosted in the Thread Stack memory, and the different method are called in concurrently. Let’s look at thread number 1 and number 3.

They both access the read method of the same object.

With Singleton objects we can obtain this situation without instancing two objects of the same type.








The final picture of the java memory is the following:


Every threads run using the same objects shared with the others without any conflict.

Having said that, it seems we’ve to transform every object in singleton….is it right?

As you well know, the answer is no; unfortunately, Singleton object are a good solution for a lot of pattern but is not a panacea to prevent every performance issue.

First of all, Singleton object are stateless; objects like bean or object which stored user information cannot be singleton by definition.

Even objects as the above described can be, significantly, become impossible to apply the Singleton pattern if we put class properties like the below code:

public class Reader{

public string fileName;

  BufferedReader read(){
    BufferedReader br = new BufferedReader(new FileReader(fileName));

The highlight property “filename” gets the Reader object in big problem if it would be instance as Singleton.

Remember, this property is in the heap memory and not in the stack thread.

Concluding, in order to build a very robust and scalable system, we’ve to have clear ideas on how JVM manage the memory.

Adopting Singleton object is a good way to achieve scalable platform. We’ve to use it carefully to avoid side effect as sharing information between the threads.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.