How to Improve the Performance of Java locks (1)

How to Improve the Performance of Java locks (1)

We try our best to find a solution to the problems encountered by our products, but I will share with you several common technologies in this article, these technologies include separating locks, parallel data structures, protecting data rather than code, and narrowing down the scope of the lock. These technologies enable us to detect deadlocks without any tools.

The lock is not the root cause of the problem, but the competition between locks is

When you encounter performance problems in multi-threaded code, you usually complain about the lock problem. After all, the lock will reduce the running speed of the program and its low scalability is well known. Therefore, if you begin to optimize the Code with this "Common Sense", the result may be annoying concurrency problems later.

Therefore, it is important to understand the differences between a competitive lock and a non-competitive lock. Lock contention is triggered when a thread tries to enter the synchronization block or method being executed by another thread. This thread will be forced to enter the waiting state until the first thread executes the synchronization block and has released the monitor. When only one thread tries to execute the synchronized code area at a time, the lock will remain non-competitive.

In fact, in non-competitive scenarios and most applications, JVM has optimized synchronization. Non-competitive locks do not incur any additional overhead during execution. Therefore, you should not complain about the lock due to performance issues, but should complain about the lock competition. With this understanding, let's look at what we can do to reduce the possibility of competition or reduce the duration of competition.

Protect data, not code

A quick way to solve the thread security problem is to lock the accessibility of the entire method. In the following example, we try to create an online poker game server using this method:

 
 

  
  
class GameServer { 
  
  
 
  
  
public Map<> tables = new HashMap>(); 
  
  
 
  
  
public synchronized void join(Player player, Table table) { 
  
  
 
  
  
if (player.getAccountBalance() > table.getLimit()) { 
  
  
 
  
  
List 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 author's intention is good-when a new player joins the card table, make sure that the number of players on the card table does not exceed the total number of players that the card table can accommodate.

However, this solution actually requires control of the player's entry to the card table at any time, even when the server's access volume is small, threads waiting for lock release are destined to frequently trigger system competition events. Locked blocks that include checks on account balances and card table restrictions may greatly increase the overhead of calling operations, which will undoubtedly increase the possibility and duration of competition.

The first step is to ensure that we protect the data, rather than moving from the method declaration to the synchronous declaration in the method body. For the simple example above, it may not change much. However, we need to consider the interface of the entire game service, rather than simply a join () method.

 
 

  
  
class GameServer { 
  
  
 
  
  
public Map> tables = new HashMap>(); 
  
  
 
  
  
public void join(Player player, Table table) { 
  
  
 
  
  
synchronized (tables) { 
  
  
 
  
  
if (player.getAccountBalance() > table.getLimit()) { 
  
  
 
  
  
List 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 */} 
  
  
 
  
  
} 
 
 

It may have been a small change, but it affects the behavior of the entire class. The previous synchronization method locks the entire GameServer instance at any time, and then competes with gamers who attempt to leave the table at the same time. Moving the lock from the method declaration to the method body will delay the loading of the lock, thus reducing the possibility of lock competition.