thread safe assignment java

Java Tutorial

Control statements, java object class, java inheritance, java polymorphism, java abstraction, java encapsulation, java oops misc.

• Send your Feedback to [email protected]

Help Others, Please Share

Learn Latest Tutorials

Transact-SQL

Reinforcement Learning

R Programming

React Native

Python Design Patterns

Python Pillow

Python Turtle

Preparation

Verbal Ability

Interview Questions

Company Questions

Trending Technologies

Artificial Intelligence

Cloud Computing

Data Science

Machine Learning

B.Tech / MCA

Data Structures

Operating System

Computer Network

Compiler Design

Computer Organization

Discrete Mathematics

Ethical Hacking

Computer Graphics

Software Engineering

Web Technology

Cyber Security

C Programming

Control System

Data Mining

Data Warehouse

How to write Thread-Safe classes in Java

Thread-safe classes.

Thread-Safe classes remain functionally correct when accessed from multiple interleaving threads, without any additional synchronization or coordination required on the caller side.

Thread-Safety allows us to protect against race conditions. However, it is required only for classes having a Shared Mutable State . If the class is not shared, or the class is stateless or immutable , it is thread-safe by nature and no extra synchronization is required.

For mutable classes, we have several options:

Atomic Variables

These are part of Java concurrent utilities. These utility classes allow you to have atomic operations on single variables.

To understand this, let’s say we have an unsafe counter class:

This UnsafeCounter will provide an inconsistent count when accessed from multiple threads since counter++ is not a single atomic operation, it is a convenient syntax for three distinct operations: read counter value, add one to counter value, and write counter value back. Read-Modify-Write .

In a multi-threaded environment, race conditions will occur and threads will have stale values and lost updates. For example, two threads t1 and t2 can read the same counter value. t1 increments the counter and writes back before t2 . t2 now has a stale value and it increments it and writes back, effectively overwriting the previous value from t1 , which is now lost.

To write a thread-safe version of this class, we can use AtomicInteger :

AtomicInteger is a wrapper class over int that provides different methods for atomic operations. Like we have used counter.getAndIncrement() which is comparable to count++ in UnsafeCounter .

Atomic variable classes are part of java.util.concurrent.atomic package.

Synchronized Blocks

Synchronized blocks are used when a group of statements combined needs to be executed atomically. For example, let’s say we have the following UnsafeHttpRequestCounter :

To write a safe version of this class, we might consider changing int variables to AtomicInteger . Although this will make individual counters atomic, it won’t make them atomic as a combined execution group, as in incrementGetRequest() and incrementPostRequest() methods. We need to somehow lock these statements to achieve atomic execution of the whole group combined.

A synchronized block is a locking mechanism to enforce atomicity. It has two parts: an object reference to serve as a lock, and a block of code to be guarded.

You can use any Java object as a lock and the same lock should be shared between all threads that will execute synchronized block. These locks are called intrinsic locks or monitor locks . These locks act as mutual exclusion locks (mutex), which means that only one thread can hold the lock. If another thread needs the lock, it must wait for the holding thread to release it.

The lock (if available) is automatically acquired by an executing thread before entering the synchronized block and automatically released when the thread exists the synchronized block.

We can add synchronized blocks in our UnsafeHttpRequestCounter like:

Since we are protecting the whole method body using the current instance reference as a lock, we can directly add synchronized in the method signature.

Intrinsic locks are reentrant. If a thread tries to acquire a lock held by another thread, it will block, but, if a thread tries to acquire an already-holding lock, it will succeed. Reentrancy means that locks are acquired on a per-thread basis, instead of per invocation bases. For example:

Volatile Keyword

Volatile keyword solves memory visibility problem between threads.

Memory Visibility between threads

In a single thread, if you write some value to a variable and later read it, it would be the same value. But, if the reads and writes are happening in different threads, it is not guaranteed to be the same (without synchronization).

Consider the following example:

This is a classic producer-consumer setup. The producer sets a value in a shared variable and sets the ready flag to true so that the consumer can consume it, however, this program might not behave as expected. The problem is JVM and the underlying platform performs lots of optimizations. From the prospect of the consumer thread, the ready flag is false and the value is 0 . These values can be stored in processor cache or even reordered if JVM thinks it’s better for performance.

Consumer may:

This is called a memory visibility problem.

Using Volatile

volatile keyword ensures that updates to a variable are propagated predictably to other threads. Volatile variables are always written to and read from the memory and JVM won’t reorder them with other operations. This enables volatile reads to always return the most recent write by any other thread.

We have set the ready flag to volatile, now as soon as the producer updates the values of ready , the consumer can immediately see it in the next read.

Happens Before Guarantee

Write to volatile variable comes with Happens Before Guarantee . It means that all shared variables that are updated before an update to a volatile variable will be visible to any other thread after it reads the value of a volatile variable. Or, in other words, all writes that Happens-Before a volatile variable write are visible to other threads after the volatile variable read.

From the above producer-consumer example:

First, we set value = 49 , then we set read = true . Since the read variable is volatile, the value of value also gets synced with memory. When the consumer fetches the value of read , it will also fetch the latest values of other variables as well (that are written before the ready flag).

When to use volatile

Volatile provides a weaker form of synchronization with shared variables without any need for mutual exclusion, however, it can’t save you from race conditions. They can be used in scenarios such as:

Thread safety is an important aspect of Java multi-threaded programming. Stateless and Immutable classes are by nature threadsafe and do not require any special treatment. Classes with Shared Mutable States need proper synchronization and coordination in a multi-threaded environment. Java provides different tools to deal with synchronization like Atomic Variables, Synchronized Blocks and Volatile variables. These tools help us write correct thread-safe classes.

Trending Tags

• Enterprise Java
• Web-based Java
• Data & Java
• Project Management
• Visual Basic
• Ruby / Rails
• Java Mobile
• Architecture & Design
• Open Source
• Web Services

Developer.com content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More .

In our “What is Concurrency in Java?” tutorial, we learned that problems can occur within a multi-threaded environment if several threads try to access and change the same data at the same time. This is a serious problem, as it can lead to execution deadlocks and data corruption. A program that allows multiple threads to change the same data structure or objects simultaneously is referred to as being not thread-safe . Conversely, a program that is thread safe prevents other threads from working on the same object when a thread is already working with it. In this programming tutorial, we examine four relatively easy ways of achieving thread safety in our Java programs.

If you missed it, we recommend reading our previous part of this series on Java threading: What is Concurrency in Java?

Using Synchronization in Java

How to use atomic variables in java, using the volatile keyword in java, how to use the final keyword in java.

The first way to make a program thread safe is to use Synchronization . Simply put, Synchronization is the process of allowing only one thread at a time to complete a particular operation. It resolves the inconsistency problem by preventing multiple threads from accessing the same resource at the same time. Synchronization uses a synchronized keyword, which is a special modifier that creates a block of code known as a critical section .

Here is an example Java program that increments a value by five on two separate threads:

As expected, the incremented value jumps all over the place as each thread accesses the same variable concurrently:

Adding the synchronized keyword to the add5() method resolves this issue:

Now each thread completes its work in turn:

Read: Best Tools for Java Mobile Development

Another way to achieve thread safety in Java is to employ the volatile keyword. It is a field modifier that ensures that the object can be used by multiple threads at the same time without causing the problematic behaviors mentioned above.

The following example code declares and instantiates two integers using the volatile keyword:

As we can observe in the program output, both variables have been fully incremented by the first thread before the second thread outputs their values:

Another way to achieve thread safety in Java is to use atomic variables . As the name suggests, atomic variables allow developers to perform an atomic operation on a variable. Atomic variables minimize synchronization and help avoid memory consistency errors. The most commonly used atomic variables are AtomicInteger , AtomicLong , AtomicBoolean , and AtomicReference . Here is some example Java code that uses AtomicInteger to increment two separate counters before outputting their combined value:

Running the above program produces an output of “ 10000 “.

Read: Top Java Frameworks

Final Variables are always thread safe in Java because, once assigned, a reference to an object cannot point to another object. Here is a short program to demonstrate how to use the final keyword in Java:

Integrated development environments (IDEs) will not even let you run the above code and will show a compiler error about the attempt to reassign a value to the final aString variable:

Final Thoughts on Thread Safety in Java

This programming tutorial presented four ways of achieving thread safety in our Java programs, namely: using Synchronization , the volatile Keyword, via atomic variables, and the final keyword. There are other ways to achieve thread safety in Java, but those require slightly more effort on the part of the developer. These include the use of locks from the java.util.concurrent.locks package and using thread safe collection classes such as ConcurrentHashMap .

Now that you have a firm understanding of some of the ways to achieve thread safety in Java, we recommend checking out a few of our other tutorials on threading and multithreading in Java:

• What is Concurrency in Java?
• What is the Java Thread Class?

Get the Free Newsletter!

Subscribe to Developer Insider for top news, trends & analysis

Latest Posts

What is the role of a project manager in software development, how to use optional in java, overview of the jad methodology, microsoft project tips and tricks, how to become a project manager in 2023, related stories, understanding types of thread synchronization errors in java, understanding memory consistency in java threads.

In Java, a thread-safe is a class that guarantees the class’s internal state and that the methods’ values are correct while multiple threads are invoked concurrently.

This tutorial discusses different collection classes via code examples that are thread-safe in java.

Thread Safe Collections in Java

In Java, the most popular thread-safe collection classes are Vector , Stack , Hashtable , Properties , etc. Let’s learn each of them, starting with the Vector below.

Thread Safe Collection Class - Vector

The Vector is an array of objects that can grow as required. This class supports with the method like add() , remove() , get() , elementAt() , and size() .

Example Code:

Thread Safe Collection Class - Stack

The Stack class implements the stack data structure. It is based on the LIFO or Last In First Out . The most common operation of the Stack class is push() , pop() , empty() , and search() .

Thread Safe Collection Class - Hashtable

The Java Hashtable class implements the hash table that maps the keys to values . In addition, it implements the Map interface and inherits the directory.

Thread Safe Collection Class - Synchronize HashMap

There is a synchronized version of HashMap that you can use as a thread-safe collection in Java. This HashMap works most similar to the Synchronize HashMap .

Aminul Is an Expert Technical Writer and Full-Stack Developer. He has hands-on working experience on numerous Developer Platforms and SAAS startups. He is highly skilled in numerous Programming languages and Frameworks. He can write professional technical articles like Reviews, Programming, Documentation, SOP, User manual, Whitepaper, etc.

Related Article - Java Collection

• How to Convert Collection to List in Java
• How to Implement Key Value Pair in Java
• How to Iterate Over Each Element of Map in Java

Java, JavaScript & Web tutorials

Spring bean thread safety guide

Is Spring controller/service/singleton thread-safe?

It’s a commonly asked question by Spring newcomers and probably a must-have warm-up question on job interviews. As usual in programming, the answer is: it depends. The main factor which determines thread safety of a component is its scope.

Let’s get down to it and see what Spring’s scopes have to offer in multithreaded programming.

Which Spring scope is thread-safe?

In order to answer that question, you first need to understand when Spring creates a new thread.

In a standard servlet-based Spring web application, every new HTTP request generates a new thread. If the container creates a new bean instance just for that particular request, we can say this bean is thread-safe .

Let’s examine what scopes we have in Spring and focus on when the container creates them.

Is Spring singleton thread safe?

The short answer is: no, it isn’t.

And you probably already know why.

It’s because of the long life cycle of singleton beans. Those beans may be reused over and over again in many HTTP requests coming from different users.

If you don’t use @Lazy , the framework creates a singleton bean at the application startup and makes sure that the same instance is autowired and reused in all other dependent beans. As long the container lives, the singleton beans live as well.

But the framework doesn’t control how the singleton is used. If two different threads execute a method of the singleton at the same time, you’re not guaranteed that both calls will be synchronized and run in the sequence.

In other words, it’s your responsibility to ensure your code runs safely in the multithreaded environment. Spring won’t do that for you.

Request scope to the rescue

If you want to make sure your bean is thread-safe, you should go for the @RequestScope . As the name suggests, Spring binds such bean to a particular web request. Request beans aren’t shared between multiple threads, hence you don’t have to care about concurrency.

But hang on a minute.

If request scope beans are so great when it comes to concurrency, maybe we should use the scope for all application beans? Before you set the request scope to all your components,  ask yourself the following question.

Do you really need all your beans to be thread-safe?

Usually, you don’t.

Creating a new instance of a bean instead of reusing the existing one is always slower. Stick to singletons unless you have a real use case for request scope beans.

Problematic session scope

Spring associates session beans with a particular user. When a new user visits your application, a new session bean instance is created and reused for all requests from that user.

As you know, some user’s requests may be concurrent. Because of that fact, session beans aren’t thread-safe. Their life cycle is longer than request scope beans. Multiple requests may call the same session bean concurrently.

Tricky thread safety with prototype beans

I left the prototype scope as the last one to discuss because we can’t clearly say it’s always thread-safe or not. Prototype’s thread safety depends on the scope of the bean which contains the prototype.

Spring creates a prototype bean on demand whenever another bean requires its instance.

Imagine you have two beans in your application. One is the singleton and the second is the request scoped component. Both depend on a third bean which is the prototype.

Let’s consider the singleton bean first. Because the singleton isn’t thread-safe, calls to its prototype methods may also run concurrently. When several threads share the singleton, the single instance of the prototype that Spring injects to that singleton will also be shared.

It works the same for all other scopes which make a bean reusable in several web requests.

What about the request scope bean? Spring creates a new instance of such component for each web request. Each request is bound to a separate thread. Therefore, each instance of the request bean gets its own instance of the prototype bean. In that case, you can consider the prototype as thread-safe.

So are Spring web controllers thread-safe or not?

The answer again is: it depends.

It depends on the scope of such a controller.

If you define a controller as the default singleton bean, it won’t be thread-safe. Changing the default scope to the session won’t make the controller safe either. However, the request scope will make the controller bean safe to work for concurrent web requests.

What about controllers with the prototype scope? You already know its thread safety depends on the scope of the bean which contains the prototype as a dependency. But we never inject controllers to other beans, right? They’re entry points to our application. So how does Spring behave when you define a controller as the prototype bean?

As you probably suppose, when you define a controller as the prototype, the Spring framework will create a new instance for each web request it serves . Unless you inject them to unsafe scoped beans, you can consider prototype scoped controllers as thread-safe.

How to make any Spring bean thread-safe?

The best thing you can do to tackle access synchronization is to avoid it.

By making your bean classes stateless.

The bean is stateless if execution of its methods doesn’t modify its instance fields. Changing local variables inside a method is totally fine because each call to a method allocates the memory for these variables. Unlike instance fields which are shared between all non-static methods.

The perfect stateless bean has no fields but you won’t see such utility classes very often. Usually, your beans have some fields. But by applying a few simple rules, you can make any bean stateless and thread-safe.

How to make Spring bean stateless?

Start by making all bean fields final to indicate that during the life cycle of the bean fields shouldn’t be reassigned again.

But don’t confuse field modification with reassignment! Making all bean’s fields final doesn’t make it stateless. If values you assigned to final fields of a bean can be changed during the runtime, such bean is still not thread-safe.

The above example presents a stateless bean because you can’t change the value of the String field. The String class is immutable just like Integer, Boolean, and other primitive wrappers. You can also use primitive types safely in this case. But what about more complex objects like standard Lists, Maps, or your custom data classes?

For the common types like collections, you can go for immutable implementations which you can find in the standard Java library. You can easily create immutable collections with factory methods added in Java 9. If you still use an older version, don’t worry. You can also find conversion methods like unmodifiableList() in the Collections class .

If it comes to custom data types, you have to make sure they are immutable on your own. Creating an immutable class in Java goes beyond the scope of this article. If you need a more detailed guide, read how to design immutable classes in the official Java documentation .

Sounds easy enough. But some of your beans may maintain some state. What then?

Thread-safe variable in stateful Spring bean

Stateless bean sounds like the silver bullet. But what if you already have a stateful bean and you must synchronize access on one of its fields?

In that case, you have the classic Java problem with the concurrent modification access to a class field. The Spring framework won’t solve it for you. You need to select one of the possible solutions:

• The synchronized keyword and Locks – This option gives you the most control over access synchronization but also requires a deeper understanding of mechanisms used in the concurrent environment .
• Atomic variables – You can find a small set of thread-safe types in the Java standard library. Types from that package can be safely used as fields in shared stateful beans.
• Concurrent collections – In addition to atomic variables, Java provides us with a few useful collections which we can use without worrying about the concurrent access problem.

But beware: no matter which method you choose, access synchronization always has an impact on the performance . Try to avoid it if you have an alternative option.

Implementing thread-safe method in Spring component

Frankly, I’ve never had such case in any of my commercial projects but I was asked that question on an interview some time ago so you also may hear it.

As we already discussed, Spring itself doesn’t solve the problem of the concurrent access. If the scope of your bean isn’t thread-safe but its method contains some critical code that you always want to run safely, use the synchronized keyword on that method.

At this point, you should know the position of the Spring framework in the multithreaded environment. You learned how the scope of a component affects its safety and what are the options when you have to provide thread safety on your own.

If you like the post, subscribe to my blog so you won’t miss the next article. Also please leave a comment if you have some interesting stories about tackling concurrency problems in Spring applications. I would love to read them.

• Java Arrays
• Java Strings
• Java Collection
• Java 8 Tutorial
• Java Multithreading
• Java Exception Handling
• Java Programs
• Java Project
• Java Collections Interview
• Java Interview Questions
• Spring Boot

Java Threads

• Main thread in Java
• Virtual Threads in Java
• Thread Pools in Java
• Killing threads in Java
• Joining Threads in Java
• Daemon Thread in Java
• TreeMap in Java
• Multithreading in Java
• run() Method in Java Thread
• Multithreaded Servers in Java
• Thread Libraries
• Java Multithreading Tutorial
• Moving Ball Using Thread in Java
• Semaphore in Java
• Interrupting a Thread in Java
• Java.lang.Thread Class in Java
• Java Program to Create a Thread
• Joining Threads in C#
• Thread Class in C#

Typically, we can define threads as a subprocess with lightweight with the smallest unit of processes and also has separate paths of execution. The main advantage of multiple threads is efficiency (allowing multiple things at the same time. For example, in MS Word. one thread automatically formats the document while another thread is taking user input. Another advantage is quick response, if we use multiple threads in a process and if a thread gets stuck due to lack of resources or an exception, the other threads can continue to execution, allowing the process (which represents an application) to continue to be responsive.

Threads in a Shared Memory Environment in OS

As we can observe in, the above diagram a thread runs inside the process and there will be context-based switching between threads there can be multiple processes running in OS, and each process again can have multiple threads running simultaneously. The Multithreading concept is popularly applied in games, animation…etc.

The Concept Of Multitasking

To help users Operating System accommodates users the privilege of multitasking, where users can perform multiple actions simultaneously on the machine. This Multitasking can be enabled in two ways: 

• Process-Based Multitasking 
• Thread-Based Multitasking 

1. Process-Based Multitasking (Multiprocessing)

In this type of Multitasking, processes are heavyweight and each process was allocated by a separate memory area. And as the process is heavyweight the cost of communication between processes is high and it takes a long time for switching between processes as it involves actions such as loading, saving in registers, updating maps, lists, etc. 

2. Thread-Based Multitasking 

As we discussed above Threads are provided with lightweight nature and share the same address space, and the cost of communication between threads is also low. 

Why Threads are used? 

Now, we can understand why threads are being used as they had the advantage of being lightweight and can provide communication between multiple threads at a Low Cost contributing to effective multi-tasking within a shared memory environment. 

Life Cycle Of Thread

There are different states Thread transfers into during its lifetime, let us know about those states in the following lines: in its lifetime, a thread undergoes the following states, namely: 

• Active State
• Waiting/Blocked State
• Timed Waiting State
• Terminated State

We can see the working of  different states in a Thread in the above Diagram, let us know in detail each and every state: 

1. New State 

By default, a Thread will be in a new state,  in this state, code has not yet been run and the execution process is not yet initiated. 

2. Active State

A Thread that is a new state by default gets transferred to Active state when it invokes the start() method, his Active state contains two sub-states namely:

• Runnable State: In This State, The Thread is ready to run at any given time and it’s the job of the Thread Scheduler to provide the thread time for the runnable state preserved threads. A program that has obtained Multithreading shares slices of time intervals which are shared between threads hence, these threads run for some short span of time and wait in the runnable state to get their schedules slice of a time interval.
• Running State: When The Thread Receives CPU allocated by Thread Scheduler, it transfers from the “Runnable” state to the “Running” state. and after the expiry of its given time slice session, it again moves back to the “Runnable” state and waits for its next time slice.

3. Waiting/Blocked State 

If a Thread is inactive but on a temporary time, then either it is a waiting or blocked state, for example, if there are two threads, T1 and T2 where T1 needs to communicate to the camera and the other thread T2 already using a camera to scan then T1 waits until T2 Thread completes its work, at this state T1 is parked in waiting for the state, and in another scenario, the user called two Threads T2 and T3 with the same functionality and both had same time slice given by Thread Scheduler then both Threads T1, T2 is in a blocked state. When there are multiple threads parked in a Blocked/Waiting state Thread Scheduler clears Queue by rejecting unwanted Threads and allocating CPU on a priority basis. 

4. Timed Waiting State

Sometimes the longer duration of waiting for threads causes starvation, if we take an example like there are two threads T1, T2 waiting for CPU and T1 is undergoing a Critical Coding operation and if it does not exist the CPU until its operation gets executed then T2 will be exposed to longer waiting with undetermined certainty, In order to avoid this starvation situation, we had Timed Waiting for the state to avoid that kind of scenario as in Timed Waiting, each thread has a time period for which sleep() method is invoked and after the time expires the Threads starts executing its task. 

5. Terminated State

A thread will be in Terminated State, due to the below reasons: 

• Termination is achieved by a Thread when it finishes its task Normally.
• Sometimes Threads may be terminated due to unusual events like segmentation faults, exceptions…etc. and such kind of Termination can be called Abnormal Termination.
• A terminated Thread means it is dead and no longer available.

What is Main Thread? 

As we are familiar, we create Main Method in each and every Java Program, which acts as an entry point for the code to get executed by JVM, Similarly in this Multithreading Concept, Each Program has one Main Thread which was provided by default by JVM, hence whenever a program is being created in java, JVM provides the Main Thread for its Execution. 

How to Create Threads using Java Programming Language? 

We can create Threads in java using two ways, namely : 

• Extending Thread Class
• Implementing a Runnable interface

1. By Extending Thread Class 

We can run Threads in Java by using Thread Class, which provides constructors and methods for creating and performing operations on a Thread, which extends a Thread class that can implement Runnable Interface. We use the following constructors for creating the Thread: 

• Thread(Runnable r)
• Thread(String name)
• Thread(Runnable r, String name)

Sample code to create Threads by Extending Thread Class: 

 Sample code to create Thread by using Runnable Interface:  

  Sample Code to create Thread in Java using Thread(String name): 

  Sample Java Code which creates Thread Object by using Thread(Runnable r, String name): 

Java Program to explore different Thread States: 

Let us see the working of thread states by implementing them on Threads t1 and t2. 

Please Login to comment...

Similar reads.

• Java-Multithreading

Improve your Coding Skills with Practice

What kind of Experience do you want to share?