Java Concurrency - Synchronization

In my last post we looked at running tasks across multiple threads, asynchronously using the ExecutorService. Accessing and manipulating an object from multiple threads simultaneously can pose a problem when the object in question holds state. If multiple threads attempt to modify shared state, behaviour can become unpredictable and result in data being left in an inconsistent state.

Unsynchronized Code

Take the simple BankAccount class below. It holds state in the form of a balance, which can be increased and decreased using the credit and debit methods respectively. When used in a single threaded context this object will behave as expected, crediting and debiting the amounts specified.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
public class BankAccount {
 
    private double balance;
 
    public void credit(double amount){
        balance = balance +amount;         
    }
 
    public void debit(double amount){    
        balance = balance - amount;     
    }
  
    public double getBalance(){
        return balance;
    }
}

However, when multiple threads call the credit and debit methods simultaneously, we can end up with unpredictable behaviour and an incorrect balance. To see this in action the test method below uses an ExecutorService to submit 100 account debits and 100 account credits, each for £100.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
@Test
public void testBankAccountWithoutSynchronization1(){
  
    BankAccount bankAccount = new BankAccount();
  
    ExecutorService executorService = Executors.newFixedThreadPool(10);
  
    IntStream.rangeClosed(1, 100).forEach(i->{   
        executorService.submit(()-> {   
            bankAccount.debit(100);    
        });
   
        executorService.submit(()-> {    
            bankAccount.credit(100);    
        });
    });
  
    executorService.shutdown();    
    System.out.println("Final Balance: " + bankAccount.getBalance());  
}

After all debits and credits have run we'd expect the account to have a balance of zero. However, what we end up with is a balance of -100 as shown below.

1
Final Balance: -100.0

So what's the problem?

The credit method takes the current balance, adds a specified amount to it and then assigns the new value back to balance. The problem is that adding a value to balance and then assigning that result back to balance is not an atomic operation. This means that it does not happen as one distinct unit of work. Instead a thread may add the specified amount to the current balance and before it has a chance to assign the new value back to balance, the balance variable is updated by another thread. At this point the balance value held by the first thread is stale and the resulting variable assignment is incorrect.

1
2
3
public void credit(double amount){ 
    balance = balance + amount;       
}

To resolve the issue we need to ensure that balance = balance + amount becomes an atomic operation, performed in isolation by one thread at a time.

Synchronized Methods

The simplest way to achieve this is by marking a method as synchronised.  A synchronized method uses an implicit lock to ensure that only 1 thread at a time can enter the method.  As a result, any shared state referenced inside the method is no longer vulnerable to being manipulated by multiple threads at the same time. In this instance the shared state we're protecting is of course the account balance.

1
2
3
public synchronized void credit(double amount){
    balance = balance + amount;         
}

Side Note: Using synchronized on an instance method will use the current objects intrinsic lock for controlling access to the method. Using synchronized on a static method however, uses the intrinsic lock associated with the class, not the object. This is an important distinction, as it is possible for one thread to hold an objects intrinsic lock, while another thread at the same time holds of the class.

Synchronized Blocks

While synchronizing an entire method can be useful, it is sometimes preferable to only synchronize a portion of a method instead. If you think about it, synchronizing a method creates a bottleneck by allowing only 1 thread into the method at a time. This bottle neck, known as contention, is a result of multiple threads competing to acquire a single lock. Contention can have an adverse affect on performance, so it can be preferable to synchronize only vulnerable code rather than an entire method. Thankfully the synchronized block shown below allows us to do exactly that.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
public void debit(double amount){ 
  
    // execute some non vulnerable code here...  
  
    //vulnerable code is executed inside synchronized block
    synchronized (this) {
        balance = balance - amount; 
    }
  
    // execute some more non vulnerable code here...
}

When defining a synchronized block you must specify an object on which to lock . The intrinsic lock of the specified object is used to control access to the synchronized block. A typical approach is to use the current object by specifying this (shown above). 

A final thread safe version of the original BankAccount class is shown below.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
public class SynchronizedBankAccount {
 
    private double balance;
 
    public synchronized void credit(double amount){
        balance = balance + amount;         
    }
 
    public void debit(double amount){  
        synchronized (this) {
            balance = balance - amount; 
        }  
    }
 
    public double getBalance(){
        return balance;
    }
}

Granular Control with the Lock Interface

While synchronized methods and blocks are sufficient in most instances, there are times when greater control is required. The Lock interface defines a set of locking operations that provide developers with more granular control when writing thread safe code. ReentrantLock is a common implementation of the Lock interface and one we're going to discuss in next few sections.

ReentrantLock - what is reentrance?

The term reentrant refers to a locks ability to be acquired multiple times by the same thread. Implicit locking implemented via a synchronized method or block is reentrant. This means that a thread in a syncronized method may call into another synchronized method without blocking itself. While a reentrant lock may be acquired many times by the same thread, it must also be released the same number of times before the lock can be acquired by another thread.

Creating a ReentrantLock

The code snippet below creates a ReentrantLock using its no argument constructor.

1
private Lock lock = new ReentrantLock();

A second constructor takes a boolean to indicate whether or not the lock should apply a fairness policy. If set to true, a fairness policy is implemented that ensures that the longest waiting thread will acquire the lock when it becomes available. This avoids high priority threads monopolising CPU time, while lower priority threads are left to wait for long periods. 

1
private Lock lock = new ReentrantLock(true);

Locking and Unlocking

The code snippet below is an updated version of the BankAccount credit method we looked at earlier. Instead of using the synchronized keyword I've used a ReentrantLock to control access to the vulnerable code. When a thread enters the method it will call lock in an attempt to acquire mutually exclusive access to the ReentrantLock. If the lock hasn't already been acquired by another thread, it will be acquired by the current thread, which will then be allowed to proceed.
If the lock has already been acquired by another thread when lock is called, the current thread will block until the lock becomes available again. 

1
2
3
4
5
6
7
8
9
public void credit(double amount){
    try{   
        lock.lock();
        balance = balance + amount;    
    }
    finally{
        lock.unlock(); 
    }  
}

After the balance has been updated the unlock method is called to signal that the current thread is finished and the lock is released. At this point the lock can be acquired by a waiting thread.
Note that unlock should always be called inside a finally block. This ensures that the lock is always released, even if an exception is thrown after the lock is acquired. Its imperative that the lock is released, as failing to do so will result in other threads being blocked indefinitely.

More Flexible Locking and Unlocking

The lock method we looked at above attempts to acquire a lock, waiting indefinitely if it is not available. This is the same behaviour as a synchronized method or block. There are however, times when we may want to limit the amount of time we're willing to wait for a lock, especially if we have a large number of threads competing for the same lock.  Rather than have many threads blocked waiting for access, we could take some other course of action when a lock isn't available.  Luckily ReentrantLock provides this flexibility via two flavours of the tryLock method.

Acquiring a lock with tryLock()

The tryLock method checks for the availability of the lock, returning true if the lock is available. When tryLock returns true the current thread acquires the lock and is free to execute whatever vulnerable code is being protected.  If the lock is held by another thread and not immediately available tryLock will return false, allowing the application to immediately take some other course of action.

Acquiring a lock with tryLock(long time, TimeUnit unit)

An overloaded version of tryLock takes a time and time unit that determines how long the current thread should wait for the lock to become available. If the lock is available when tryLock is called, the current thread will acquire the lock and the method will return true immediately. At this point the current thread is free to execute whatever vulnerable code is being protected.
If on the other hand the lock has already been acquired by another thread, the current thread will wait for the lock to be released. If the lock is released within the specified period of time, the current thread will acquire the lock and tryLock will return true. If the time period elapsed and the lock still hasn't been released, tryLock will return false. At this point the current thread has not acquired the lock and an alternative course of action can be taken.

The debit method below shows tryLock in action. On line 3 the current thread waits up to two seconds for the lock to become available. If the lock is available or becomes available within two seconds, the current thread is free to execute whatever vulnerable code is being protected. If the lock doesn't become available after two seconds the debit amount is added to a queue for processing later.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
public void debit(double amount) throws InterruptedException{  
  
    if(lock.tryLock(2000, TimeUnit.MILLISECONDS)){
        try{   
            balance-=amount;   
        }
        finally{
            lock.unlock(); 
        }
    }
    /* lock isn't available right now so do something else */
    else{
        /* add debit amount to queue for processing later */
    }    
}

ReentrantReadWriteLock

Another lock implementation worth looking at is the ReentrantReadWriteLock. As the names suggests the ReentrantReadWriteLock encapsulates both a read and write lock inside a single lock implementation.

Why would I need a Read & Write Lock

Consider a situation where you have a resource such as a HashMap that is being read from and written to by multiple threads. To synchronize access to a HashMap you could use any of the approaches we've already looked at. You could use a synchronized method, a synchronized block or even a ReentrantLock. While these approaches will work just fine, they do not always offer the most efficient solution.

When a thread attempts to read from or write to a HashMap using any of the above approaches, it will obtain mutually exclusive access to the lock, blocking all other threads from reading or writing at the same time. While this is the desired behaviour when writing to a HashMap, there is no reason why we should stop multiple threads reading from the HashMap concurrently. Reads do not manipulate the HashMap in any way so there is no reason to limit reads to only 1 thread at a time.

Ideally we'd like a means of synchronizing access to the HashMap when its being updated, but allow multiple threads to read from the HashMap when its not being updated. Thankfully this is exactly what the ReentrantReadWriteLock does.

Creating a ReentrantReadWriteLock

Like ReentrantLock the ReentrantReadWriteLock can be instantiated with an optional boolean to indicate whether or not a fairness policy should be established. If a fairness policy is chosen, threads will acquire the lock in the order they've requested it.

1
private ReadWriteLock readWriteLock = new ReentrantReadWriteLock(true);

Acquiring a Write Lock

The method below demonstrates how a write lock is acquired by first calling the writeLock method, followed by an appropriate locking method. The example below chains the lock method with writeLock but both tryLock and tryLock(time, TimeUnit) are both available. As mentioned previously, the lock should be released inside a finally block.

1
2
3
4
5
6
7
8
9
public void saveTransaction(String transaction) throws InterruptedException {
    try{
        readWriteLock.writeLock().lock();
        transactionHistory.put(UUID.randomUUID().toString(), transaction); 
    }
    finally{
        readWriteLock.writeLock().unlock(); 
    }  
}

When the write lock is acquired by a thread, that thread has mutually exclusive access to the ReentrantReadWriteLock. At this point no other thread can obtain a read or write lock, meaning that the HashMap can not be read from or written to by any other thread.

Acquiring a Read Lock

The method below demonstrates how a read lock is acquired by first calling readLock followed by an appropriate locking method.  Although the example below chains the lock method with readLock, both tryLock and tryLock(time, TimeUnit) are also available.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
public List<String> getTransactions(){  
  
    List<String> transactions = null;
    
    try{
        readWriteLock.readLock().lock();
        transactions =  transactionHistory.values().stream().collect(Collectors.toList());
    }
    finally{
        readWriteLock.readLock().unlock(); 
    } 
  
    return transactions;
}

Unlike the write lock, the read lock can be held by multiple threads. In our sample code this allows multiple threads to read from the Map concurrently.

Important Note

While the example above serves to demonstrate the fundamentals of ReentrantReadWriteLock, in reality we wouldn't use it to synchronize access to a HashMap. Instead we'd make use of the Collections class which has a method that takes a Map and returns a thread safe equivalent, as shown below.

1
Map<String, String> transactionHistory  = Collections.synchronizedMap(new HashMap<String, String>());

Wrapping Up

The sample code for this post is available on github, so feel free to pull it down and have a play around. If you have any comments, questions or suggestions please leave a note below.  

Comments

Post a Comment

Popular posts from this blog

Spring Web Services Tutorial

Image
Update
I've recently written a more up to date version of this post which describes how to build a contract first web service using Apache CXF. Check it out here.

Introduction
Modern enterprise applications are rarely stand alone and often rely on data and services provided by external systems. In order for different types of systems to communicate there must be a  communication protocol of some sort, a standard way of sending and receiving messages in a format that is recognised and supported by all major platforms. SOAP (Simple Object Application Protocol) is such a protocol, and allows applications to communicate by exchanging messages in a standard XML format.
SOAP Web Services provide a platform agnostic integration mechanism that allows disparate systems to exchange data regardless of the platform they are running on. For example, SOAP web services are commonly used to integrate .NET applications with applications running on the Java platform. Almost all modern platforms and …
Read more

REST Endpoint Testing With MockMvc

In this post I'm going to show you how to test a Spring MVC Rest endpoint without deploying your application to a server. In the past, full integration tests were the only meaningful way to test a Spring REST endpoint. This involved spinning up a test server like Tomcat or Jetty, deploying the application, calling the test endpoint, running some assertions and then terminating the server. While this is an effective way to test an endpoint, it isn't particularly fast. We're forced to wait while the entire application is stood up, just to test a single endpoint.
An alternative approach is to unit test by manually instantiating the Controller and mocking out any required dependencies.  While such a test will run much faster than a full integration test, its of limited value. The problem is that by manually instantiating the Controller we're bypassing Springs Dispatcher Servlet, and as a result missing out on core features like
request URL mapping request deserialization re…
Read more

Axis2 Web Service Client Tutorial

Image
Introduction
Axis2 is a Java framework that provides comprehensive support for exposing and consuming web services. This short post will look at its SOAP client support and how it can be used to get a simple web service client up and running.
For convenience I'm going to be calling a web service that I recently built as part of another blog post.  If you don't already have a web service to call you can grab the full source code for my sample service from github. Simply run a Maven build and deploy the WAR to your Servlet container.

What is a Web Service Client
This post doesn't attempt to explain the detailed inner workings of a web service client, but its still pretty useful to have an idea of what's going on under the hood. Most web service clients provide the following
A client side proxy for the remote service we want to call, that allows our application to invoke a SOAP service using a simple method call. The proxy insulates our application from the intricacies of s…
Read more

Health Checks, Metrics & More with Spring Boot Actuator

Image
I've been working with Spring Boot for a few years now and I'm a big fan. There are lots of things to like about Spring Boot, but one thing that really stands out for me is the emphasis on production readiness.
Production Readiness Production readiness is about looking beyond functional requirements and ensuring your application can be properly managed and monitored in production. Some key things to consider when thinking about production readiness are...
Health checksViewing application configuration - application properties, Environment variables etc. Viewing and altering log configurationViewing application metrics - JVM, classloader, threading and garbage collection. Audibility of key application events Spring provides all of this functionality out of the box via Spring Boot Actuator, a sub project of Spring Boot. A range of RESTful management and monitoring endpoints are provided so you don't have to implement these features each time you build an application. To enable…
Read more

An Introduction to Wiremock

This post provides a brief introduction to Wiremock, showing how it can be used to to quickly and easily mock remote API calls. We'll use Wiremock to write some integration tests for a simple Dropwizard app and show you how it can be put to use in a real world scenario.

Why would I need to mock external API calls? There are a number of scenarios where it makes sense to mock an external API rather than call a live service.
The external API may still be in development and not yet available for integration. In this instance as long as a data contract has been defined (e.g. Swagger spec, WSDL), the remote API can be stubbed based on the data contract. Stubbed endpoints allows a team to continue development even when external APIs isn't fully implemented.You may have little or no control over the external API uptime in development or test.  As a result you cannot guarantee it will be available to call when running integration tests. In this instance it makes sense to use mocked respo…
Read more

Spring Batch Tutorial

Image
Introduction Spring batch is a lightweight framework that provides a solid foundation on which to build robust and scalable batch applications. It provides developers with a set of tried and tested patterns that solve common batch problems and allows developers to focus more on the business requirement and less on complex batch infrastructure. Spring batch contains a variety of out of the box configurable components that can be used to satisfy many of the most common batch use cases. Extensive XML configuration and an extensible programming model mean that these components can be customised and used as building blocks to quickly deliver common batch functionality.
This tutorial will show you how to build a very simple batch application to read fixed length data from a flat file and write it to a database table. This is a common batch use case and should be sufficient to demonstrate some of the fundamental concepts of Spring batch and provide you with a foundation on which to build mor…
Read more

Externalising Spring Configuration

Enterprise applications typically contain a number of  properties and  runtime resources that must be configured before the application is deployed. Property and resource values can either be baked into the artefact at build time using something like Maven Profiles or derived at runtime using Spring Profiles. My preferred approach is to externalise all configuration so that the artefact taken from the build server is environment agnostic and can be deployed onto any environment . For example, we could take a WAR file from our build server and  deploy it to our development, UAT or production environments without changing any configuration in the WAR file itself.

Spring Property Configuration Spring applications use the PropertyPlaceholderConfigurer to load application properties. Property files are typically loaded from the class path but the example below uses a slightly different approach, loading the properties file from a directory outside of the application itself. This allows the…
Read more

Docker & Spring Boot

Docker allows you to package an application with its dependencies, into a light weight, portable container that can run on almost any environment.  You can think of a Docker container as a run time, a mini virtual machine that encapsulates your application and its dependencies.
In order to run a container you need a Docker image. An image is like a template that defines everything that will exist within the container. You can almost think of an container as a run time instance of the image it was created from. In this post we'll define and build 3 slightly different Docker images that run a simple Java app.

Installing Docker If you haven't already done so you'll need to install Docker. The official documentation is pretty good so following it step by step should see you up and running in about 15 minutes.
I've installed Docker on Windows and Ubuntu but to be honest I prefer running it on Ubuntu and have found it a bit more reliable than with Docker Toolbox on Windows.��…
Read more

Spring Boot & Amazon Web Services (EC2, RDS & S3)

Image
This post will take you through a step by step guide to building and deploying a simple Java application to the AWS cloud platform. The application will use a few well known AWS services which I'll describe along the way. There is quite a bit of material to cover in this post so the overview of the AWS services will be light. For those interested in finding out more I'll link to the appropriate section of the AWS documentation. Amazon have done a fine job documenting their platform so I'd encourage you to have a read if time permits.      

Prerequisites In order to get the sample application up and running you'll need access to AWS. If you don't already have access you can register for a free account which includes access to a bunch of great services and some pretty generous allowances. I'd encourage you to get an account set up now before going any further.

What will the sample application look like? The application we're going to build is very simple custo…
Read more