Home » Java » Core Java » Improving lock performance in Java

About Vladimir Sor

Vladimir Sor
Vladimir Šor is a technical founder of Plumbr. “How to detect performance bottlenecks with minimal overhead? How to identify and trace down root causes with no direct access to source code?“ - these are the questions Vladimir has managed to solve and keeps solving for further Plumbr releases.

Improving lock performance in Java

Plumbr is the only solution that automatically detects the root causes of Java performance issues by interpreting application performance data.

After we introduced locked thread detection to Plumbr couple of months ago, we have started to receive queries similar to “hey, great, now I understand what is causing my performance issues, but what I am supposed to do now?”Print

We are working hard to build the solution instructions into our own product, but in this post I am going to share several common techniques you can apply independent of the tool used for detecting the lock. The methods include lock splitting, concurrent data structures, protecting the data instead of the code and lock scope reduction.

Locking is not evil, lock contention is

Whenever you face a performance  problem with the threaded code there is a chance that you will start blaming locks. After all, common “knowledge” is that locks are slow and limit scalability. So if you are equipped with this “knowledge” and start to optimize the code and getting rid of locks there is a chance that you end up introducing nasty concurrency bugs that will surface later on.

So it is important to understand the difference between contended and uncontended locks. Lock contention occurs when a thread is trying to enter the synchronized block/method currently executed by another thread. This second thread is now forced to wait until the first thread has completed executing the synchronized block and releases the monitor. When only one thread at a time is trying to execute the synchronized code, the lock stays uncontended.

As a matter of fact, synchronization in JVM is optimized for the uncontended case and for the vast majority of the applications, uncontended locks pose next to no overhead during execution. So, it is not locks you should blame for performance, but contended locks. Equipped with this knowledge, lets see what we can do to reduce either the likelihood of contention or the length of the contention.

Protect the data not the code

A quick way to achieve thread-safety is to lock access to the whole method. For example, take look at the following example, illustrating a naive attempt to build an online poker server:

class GameServer {
  public Map<<String, List<Player>> tables = new HashMap<String, List<Player>>();

  public synchronized void join(Player player, Table table) {
    if (player.getAccountBalance() > table.getLimit()) {
      List<Player> tablePlayers = tables.get(table.getId());
      if (tablePlayers.size() < 9) {
        tablePlayers.add(player);
      }
    }
  }
  public synchronized void leave(Player player, Table table) {/*body skipped for brevity*/}
  public synchronized void createTable() {/*body skipped for brevity*/}
  public synchronized void destroyTable(Table table) {/*body skipped for brevity*/}
}

The intentions of the author have been good – when new players join() the table, there must be a guarantee that the number of players seated at the table would not exceed the table capacity of nine.

But whenever such a solution would actually be responsible for seating players to tables – even on a poker site with moderate traffic, the system would be doomed to constantly trigger contention events by threads waiting for the lock to be released. Locked block contains account balance and table limit checks which potentially can involve expensive operations both increasing the likelihood and length of the contention.

First step towards solution would be making sure we are protecting the data, not the code by moving the synchronization from the method declaration to the method body. In the minimalistic example above, it might not change much at the first place. But lets consider the whole GameServer interface, not just the single join() method:

class GameServer {
  public Map<String, List<Player>> tables = new HashMap<String, List<Player>>();

  public void join(Player player, Table table) {
    synchronized (tables) {
      if (player.getAccountBalance() > table.getLimit()) {
        List<Player> tablePlayers = tables.get(table.getId());
        if (tablePlayers.size() < 9) {
          tablePlayers.add(player);
        }
      }
    }
  }
  public void leave(Player player, Table table) {/* body skipped for brevity */}
  public void createTable() {/* body skipped for brevity */}
  public void destroyTable(Table table) {/* body skipped for brevity */}
}

What originally seemed to be a minor change, now affects the behaviour of the whole class. Whenever players were joining tables, the previously synchronized methods locked on the GameServer instance (this) and introduced contention events to players trying to simultaneously leave() tables. Moving the lock from the method signature to the method body postpones the locking and reduces the contention likelihood.

Reduce the lock scope

Now, after making sure it is the data we actually protect, not the code, we should make sure our solution is locking only what is necessary – for example when the code above is rewritten as follows:

public class GameServer {
  public Map<String, List<Player>> tables = new HashMap<String, List<Player>>();

  public void join(Player player, Table table) {
    if (player.getAccountBalance() > table.getLimit()) {
      synchronized (tables) {
        List<Player> tablePlayers = tables.get(table.getId());
        if (tablePlayers.size() < 9) {
          tablePlayers.add(player);
        }
      }
    }
  }
  //other methods skipped for brevity
}

then the potentially time-consuming operation of checking player account balance (which potentially can involve IO operations) is now outside the lock scope. Notice that the lock was introduced only to protect against exceeding the table capacity and the  account balance check is not anyhow part of this protective measure.

Split your locks

When we look at the last code example, you can clearly notice that the whole data structure is protected by the same lock. Considering that we might hold thousands of poker tables in this structure, it still poses a high risk for contention events  as we have to protect each table separately from overflowing in capacity.

For this there is an easy way to introduce individual locks per table, such as in the following example:

public class GameServer {
  public Map<String, List<Player>> tables = new HashMap<String, List<Player>>();

  public void join(Player player, Table table) {
    if (player.getAccountBalance() > table.getLimit()) {
      List<Player> tablePlayers = tables.get(table.getId());
      synchronized (tablePlayers) {
        if (tablePlayers.size() < 9) {
          tablePlayers.add(player);
        }
      }
    }
  }
  //other methods skipped for brevity
}

Now, if we synchronize the access only to the same table instead of all the tables, we have significantly reduced the likelihood of locks becoming contended. Having for example 100 tables in our data structure, the likelihood of the contention is now 100x smaller than before.

Use concurrent data structures

Another improvement is to drop the traditional single-threaded data structures and use data structures designed explicitly for concurrent usage. For example, when picking ConcurrentHashMap to store all your poker tables would result in code similar to following:

public class GameServer {
  public Map<String, List<Player>> tables = new ConcurrentHashMap<String, List<Player>>();

  public synchronized void join(Player player, Table table) {/*Method body skipped for brevity*/}
  public synchronized void leave(Player player, Table table) {/*Method body skipped for brevity*/}

  public synchronized void createTable() {
    Table table = new Table();
    tables.put(table.getId(), table);
  }

  public synchronized void destroyTable(Table table) {
    tables.remove(table.getId());
  }
}

The synchronization in join() and leave() methods is still behaving as in our previous example, as we need to protect the integrity of individual tables. So no help from ConcurrentHashMap in this regards. But as we are also creating new tables and destroying tables in createTable() and destroyTable() methods, all these operations to the ConcurrentHashMap are fully concurrent, permitting to increase or reduce the number of tables in parallel.

Other tips and tricks

  • Reduce the visibility of the lock. In the example above, the locks are declared public and are thus visible to the world, so there is there is a chance that someone else will ruin your work by also locking on your carefully picked monitors.
  • Check out java.util.concurrent.locks to see whether any of the locking strategies implemented there will improve the solution.
  • Use atomic operations. The simple counter increase we are actually conducting in example above does not actually require a lock. Replacing the Integer in count tracking with AtomicInteger would most suit this example just fine.

Hope the article helped you to solve the lock contention issues, independent of whether you are using Plumbr automatic lock detection solution or manually extracting the information from thread dumps.

Plumbr is the only solution that automatically detects the root causes of Java performance issues by interpreting application performance data.

Reference: Improving lock performance in Java from our JCG partner Vladimir Sor at the Plumbr Blog blog.
(0 rating, 0 votes)
You need to be a registered member to rate this.
4 Comments Views Tweet it!
Do you want to know how to develop your skillset to become a Java Rockstar?
Subscribe to our newsletter to start Rocking right now!
To get you started we give you our best selling eBooks for FREE!
1. JPA Mini Book
2. JVM Troubleshooting Guide
3. JUnit Tutorial for Unit Testing
4. Java Annotations Tutorial
5. Java Interview Questions
6. Spring Interview Questions
7. Android UI Design
and many more ....
I agree to the Terms and Privacy Policy

4
Leave a Reply

avatar
3 Comment threads
1 Thread replies
0 Followers
 
Most reacted comment
Hottest comment thread
4 Comment authors
Ibragimov RuslabVishnu VardhanspluskGooseberry Recent comment authors

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

  Subscribe  
newest oldest most voted
Notify of
Gooseberry
Guest
Gooseberry

I cannot agree with “uncontended locks pose next to no overhead during execution”. If you try single threaded (unconteded thread) with no locking vs Atomic (CAS) vs Syncronized one can get No locks: 108 msec CAS : 1982 msec Syncronized : 7766 msec CAS is 20x slower than no locking Syncronized iis more than 70x slower than no locking private static final long INTERATIONS = 400_000_000l; public static long t1 = 0; public static AtomicLong t2 = new AtomicLong(0); public static long t3 = 0; public synchronized long add() { t3++; return t3; } public static void main(String[] args) {… Read more »

splusk
Guest
splusk

Maybe I missed something, but isn’t the value of “tables” a list of players and not a table?
(In the createTable method)

Vishnu Vardhan
Guest
Vishnu Vardhan

In example use data structures designed explicitly for concurrent usage,

With the approch of concurrent data structures , why do we need to synchronized again the methods createTable , removetable.The ConcurrentHashMap should take care of the and that is how it is desined.

Again why do it needs to be synchronized join and leave methods if we move down synchronization to data level i.e with in method level.

Ibragimov Ruslab
Guest

I think it’s just a typo, and synchronized methods should not be there.