Improving Lock Performance in Java--reference
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?”
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:
01.
class
GameServer {
02.
public
Map<<String, List<Player>> tables =
new
HashMap<String, List<Player>>();
03.
04.
05.
06.
07.
public
synchronized
void
join(Player player, Table table) {
08.
if
(player.getAccountBalance() > table.getLimit()) {
09.
List<Player> tablePlayers = tables.get(table.getId());
10.
if
(tablePlayers.size() <
9
) {
11.
tablePlayers.add(player);
12.
}
13.
}
14.
}
15.
public
synchronized
void
leave(Player player, Table table) {
/*body skipped for brevity*/
}
16.
public
synchronized
void
createTable() {
/*body skipped for brevity*/
}
17.
public
synchronized
void
destroyTable(Table table) {
/*body skipped for brevity*/
}
18.
}
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 GameServerinterface, not just the single join() method:
01.
class
GameServer {
02.
public
Map<String, List<Player>> tables =
new
HashMap<String, List<Player>>();
03.
04.
05.
06.
07.
public
void
join(Player player, Table table) {
08.
synchronized
(tables) {
09.
if
(player.getAccountBalance() > table.getLimit()) {
10.
List<Player> tablePlayers = tables.get(table.getId());
11.
if
(tablePlayers.size() <
9
) {
12.
tablePlayers.add(player);
13.
}
14.
}
15.
}
16.
}
17.
public
void
leave(Player player, Table table) {
/* body skipped for brevity */
}
18.
public
void
createTable() {
/* body skipped for brevity */
}
19.
public
void
destroyTable(Table table) {
/* body skipped for brevity */
}
20.
}
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 theGameServer instance (this) and introduced contention events to players trying to simultaneouslyleave() 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:
01.
public
class
GameServer {
02.
public
Map<String, List<Player>> tables =
new
HashMap<String, List<Player>>();
03.
04.
05.
06.
07.
public
void
join(Player player, Table table) {
08.
if
(player.getAccountBalance() > table.getLimit()) {
09.
synchronized
(tables) {
10.
List<Player> tablePlayers = tables.get(table.getId());
11.
if
(tablePlayers.size() <
9
) {
12.
tablePlayers.add(player);
13.
}
14.
}
15.
}
16.
}
17.
//other methods skipped for brevity
18.
}
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:
01.
public
class
GameServer {
02.
public
Map<String, List<Player>> tables =
new
HashMap<String, List<Player>>();
03.
04.
05.
06.
07.
public
void
join(Player player, Table table) {
08.
if
(player.getAccountBalance() > table.getLimit()) {
09.
List<Player> tablePlayers = tables.get(table.getId());
10.
synchronized
(tablePlayers) {
11.
if
(tablePlayers.size() <
9
) {
12.
tablePlayers.add(player);
13.
}
14.
}
15.
}
16.
}
17.
//other methods skipped for brevity
18.
}
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 ConcurrentHashMapto store all your poker tables would result in code similar to following:
01.
public
class
GameServer {
02.
public
Map<String, List<Player>> tables =
new
ConcurrentHashMap<String, List<Player>>();
03.
04.
05.
06.
07.
public
synchronized
void
join(Player player, Table table) {
/*Method body skipped for brevity*/
}
08.
public
synchronized
void
leave(Player player, Table table) {
/*Method body skipped for brevity*/
}
09.
10.
11.
12.
13.
public
synchronized
void
createTable() {
14.
Table table =
new
Table();
15.
tables.put(table.getId(), table);
16.
}
17.
18.
19.
20.
21.
public
synchronized
void
destroyTable(Table table) {
22.
tables.remove(table.getId());
23.
}
24.
}
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 withAtomicInteger 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 solutionor manually extracting the information from thread dumps.
reference from:
http://java.dzone.com/articles/improving-lock-performance
Improving Lock Performance in Java--reference的更多相关文章
- What Influences Method Call Performance in Java?--reference
reference from:https://www.voxxed.com/blog/2015/02/too-fast-too-megamorphic-what-influences-method-c ...
- Java Reference 源码分析
@(Java)[Reference] Java Reference 源码分析 Reference对象封装了其它对象的引用,可以和普通的对象一样操作,在一定的限制条件下,支持和垃圾收集器的交互.即可以使 ...
- java Reference
相关讲解,参考: Java Reference 源码分析 Java Reference详解 Reference: // 名称说明下:Reference指代引用对象本身,Referent指代被引用对象 ...
- Java Reference & ReferenceQueue一览
Overview The java.lang.ref package provides more flexible types of references than are otherwise ava ...
- Java Reference核心原理分析
本文转载自Java Reference核心原理分析 导语 带着问题,看源码针对性会更强一点.印象会更深刻.并且效果也会更好.所以我先卖个关子,提两个问题(没准下次跳槽时就被问到). 我们可以用Byte ...
- Java Reference简要概述
@(Java)[Reference] Java Reference简要概述 Reference对象封装了其它对象的引用,可以和普通的对象一样操作. Java提供了四种不同类型的引用,引用级别从高到低分 ...
- Monitor and diagnose performance in Java SE 6--转载
Java SE 6 provides an in-depth focus on performance, offering expanded tools for managing and monito ...
- CLH lock 原理及JAVA实现
--喜欢记得关注我哟[shoshana]-- 前记 JUC中的Lock中最核心的类AQS,其中AQS使用到了CLH队列的变种,故来研究一下CLH队列的原理及JAVA实现 一. CLH背景知识 SMP ...
- Implementing the skip list data structure in java --reference
reference:http://www.mathcs.emory.edu/~cheung/Courses/323/Syllabus/Map/skip-list-impl.html The link ...
随机推荐
- 坚果云创业团队访谈:我们 DIY 云存储(不要过度关注竞争对手,尤其当我们还是小公司的时候)
坚果云(http://jianguoyun.com/)是一款用于多平台文件同步.备份和交换的云存储工具,立志于提供“便捷,安全”的服务.坚果云自去年年初启动内测,至今年三月初刚刚正式发布.近日我们拜访 ...
- windows 上rails3.2 + ruby1.9环境搭建
题外话:本文是通过参考网友资料,亲自尝试过后写的,有不对之处,还请网友指正! 1.搭建环境 准备ruby1.9.3 下载地址: 下载地址:http://rubyforge.org/frs/?group ...
- SQL中取当前记录的ID----->SCOPE_IDENTITY()
SQL Server 2000中,有三个比较类似的功能:他们分别是:SCOPE_IDENTITY.IDENT_CURRENT 和 @@IDENTITY,它们都返回插入到 IDENTITY 列中的值.I ...
- CORREL
CORREL Show All Returns the correlation coefficient of the array1 and array2 cell ranges. Use the co ...
- [POJ2234]Matches Game
Time Limit: 1000MS Memory Limit: 65536K Total Submissions: 9297 Accepted: 5365 Description Here ...
- 【CSS3】Advanced5:At Rules:@import, @media, and @font-face
1.@import bolt another stylesheet onto your existing one. @import url(**.css); must be placed at the ...
- iOS真机调试——Certificates, Identifiers &Profiles 简介
Certificates, Identifiers &Profiles 简介 每次到这个页面,我都不知道这几个选项是干啥的,我相信有很多同学跟我一样,所以首先我们就来先介绍下Developer ...
- 【Hibernate】--一对一关联、联合主键
一.数据模型 1.学生信息模型(编号.名称.身份信息) public class Student implements java.io.Serializable{ private static fin ...
- 143. Sort Colors II
最后更新 一刷 class Solution { public void sortColors2(int[] colors, int k) { // write your code here if ( ...
- 【三支火把】---C语言面试问题总结
看了一份关于HR在面试一名C程序员可能提问的问题手册,学到了很多,很多都是一些琐碎的知识点,总是你写过很多大型的C程序,但是我敢说,里面也有你没掌握的东西. 1.全局变量和局部变量有何区别? 答:全局 ...