记得当初看教程的时候大家都说lock性能比好不少，最近需要自己设计一个缓存终于要自己尝试一番了。
1.关于两者的实现的比较
A).一般认为synchronized关键字的实现是源自于像信号量之类的线程同步机制，涉及到线程运行状态的切换，在高并发状态下，CPU消耗过多的时间在线程的调度上，从而造成了性能的极大浪费。然而真的如此么？
B).lock实现原理则是依赖于硬件，现代处理器都支持CAS指令，所谓CAS指令简单的来说Compare And Set，CPU循环执行指令直到得到所期望的结果，换句话来说就是当变量真实值不等于当前线程调用时的值的时候(说明其他线程已经将这个值改变)，就不会赋予变量新的值。这样就保证了变量在多线程环境下的安全性。
然而，现实情况是当JDK版本高于1.6的时候，synchronized已经被做了CAS的优化：具体是这样的，当执行到synchronized代码块时，先对对象头的锁标志位用lock cmpxchg的方式设置成“锁住“状态，释放锁时，在用lock cmpxchg的方式修改对象头的锁标志位为”释放“状态，写操作都立刻写回主内存。JVM会进一步对synchronized时CAS失败的那些线程进行阻塞操作(调用操作系统的信号量)(此段来摘自别处)。也就是先CAS操作，不行的话继而阻塞线程。
除此之外，系统环境，CPU架构，虚拟机环境都会影响两者的性能关系。
2.用数据说话
1).X86_64 cpu i7 4910mq @4.0ghz ,Windows10 64bit,JDK1.8 hotspot 64bit虚拟机环境
测试代码
测试对某Map对象高并发下的读写线程安全测试
测试对比有synchronized，ReadWriteLock，ConcurrentHashMap，
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
|
public
class
MapTest {
private
Map<integer,string> map =
new
ConcurrentHashMap<>();
private
long
starttime;
private
AtomicInteger count =
new
AtomicInteger(t_count);
private
final
static
int
t_count =
5000
;
private
final
static
int
rw_count =
10000
;
Runnable readrun =
new
Runnable() {
@Override
public
void
run() {
int
i = rw_count;
while
(i >
0
){
map.get(i);
i--;
}
System.out.println(
"read-mapsize="
+map.size());
if
(count.decrementAndGet() ==
0
)
System.out.println(
"time="
+ (System.currentTimeMillis() - starttime +
"ms"
));
}
};
Runnable writerun =
new
Runnable() {
@Override
public
void
run() {
int
i = rw_count;
while
(i >
0
){
map.put(i,i+
""
);
i--;
}
System.out.println(
"write-mapsize="
+map.size());
if
(count.decrementAndGet() ==
0
)
System.out.println(
"time="
+ (System.currentTimeMillis() - starttime +
"ms"
));
}
};
public
void
run(){
starttime = System.currentTimeMillis();
for
(
int
i =
0
;i < t_count/
2
;i ++){
new
Thread(writerun).start();
new
Thread(readrun).start();
}
}
}
</integer,string>
|
HashMap 用synchronized重写
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
|
public
class
SyncHashMap
extends
HashMap{
@Override
public
Object get(Object key) {
// TODO Auto-generated method stub
synchronized
(
this
) {
return
super
.get(key);
}
}
@Override
public
synchronized
Object put(Object key, Object value) {
// TODO Auto-generated method stub
synchronized
(
this
) {
return
super
.put(key, value);
}
}
}
|
用读写锁实现的Map代理类，有些粗糙，没加try finally
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
|
public
class
SyncMapProxy<k,v>
implements
Map<k,v>{
private
Map<k,v> origin;
private
ReadWriteLock lock;
public
SyncMapProxy(Map<k, v=
""
> origin) {
this
.origin = origin;
lock =
new
ReentrantReadWriteLock();
}
public
static
<k,v> SyncMapProxy<k,v> SyncMap(Map<k,v> map){
return
new
SyncMapProxy<k,v>(map);
}
@Override
public
void
clear() {
lock.writeLock().lock();
origin.clear();
lock.writeLock().unlock();
}
@Override
public
boolean
containsKey(Object key) {
lock.readLock().lock();
boolean
res = origin.containsKey(key);
lock.readLock().unlock();
return
res;
}
@Override
public
boolean
containsValue(Object value) {
lock.readLock().lock();
boolean
res = origin.containsKey(value);
lock.readLock().unlock();
return
res;
}
@Override
public
Set<entry<k, v=
""
>> entrySet() {
lock.readLock().lock();
Set<entry<k, v=
""
>> res = origin.entrySet();
lock.readLock().unlock();
return
res;
}
@Override
public
V get(Object key) {
lock.readLock().lock();
V res = origin.get(key);
lock.readLock().unlock();
return
res;
}
@Override
public
boolean
isEmpty() {
return
origin.isEmpty();
}
@Override
public
Set<k> keySet() {
lock.readLock().lock();
Set<k> res = origin.keySet();
lock.readLock().unlock();
return
res;
}
@Override
public
V put(K key, V value) {
lock.writeLock().lock();
V v = origin.put(key, value);
lock.writeLock().unlock();
return
v;
}
@Override
public
void
putAll(Map<!--?
extends
K, ?
extends
V--> map) {
lock.writeLock().lock();
origin.putAll(map);
lock.writeLock().unlock();
}
@Override
public
V remove(Object key) {
lock.writeLock().lock();
V v = origin.remove(key);
lock.writeLock().unlock();
return
v;
}
@Override
public
int
size() {
return
origin.size();
}
@Override
public
Collection<v> values() {
lock.readLock().lock();
Collection<v> res = origin.values();
lock.readLock().unlock();
return
res;
}
}
</v></v></k></k></entry<k,></entry<k,></k,v></k,v></k,v></k,v></k,></k,v></k,v></k,v>
|
并发量100000,每个线程对Map执行读写100次,总耗时
ConcurrentHashMap:6112ms
synchronized:6121ms
ReadWriteLock:6182ms
Collections.synchronizedMap:6175ms
并发量10000,每个线程对Map执行读写1000次,总耗时
ConcurrentHashMap:1126ms
synchronized:1145ms
ReadWriteLock:2086ms
Collections.synchronizedMap:1170ms
并发量5000,每个线程对Map执行读写10000次,总耗时
ConcurrentHashMap:1206ms
synchronized:4896ms
ReadWriteLock:8505ms
Collections.synchronizedMap:4883ms
并发量1000,每个线程对Map执行读写100000次,总耗时
ConcurrentHashMap:1748ms
synchronized:9341ms
ReadWriteLock:18720ms
Collections.synchronizedMap:8945ms
并发量100,每个线程对Map执行读写1000000次,总耗时
ConcurrentHashMap:1922ms
synchronized:8417ms
ReadWriteLock:16110ms
Collections.synchronizedMap:9604ms
事实证明在以上的配置环境JDK1.8 X86 Windows10下，高并发下这几种方式性能都相差无几，较高和较低并发下，synchronized都比ReadWriteLock来的快，基本是两倍的关系。ConcurrentHashMap作为同步的Map还是时间性能还是最高的。总之在hotspot下都是一个数量级的。
2).下面看另外一种环境
Android6.0 X86_64模拟器镜像，ART Runtime
并发量20,每个线程对Map执行读写1000000次,总耗时
ConcurrentHashMap:10841ms
synchronized:239452ms
ReadWriteLock:16450ms
Collections.synchronized:213429ms
并发量200,每个线程对Map执行读写10000次,总耗时
ConcurrentHashMap:973ms
synchronized:57047ms
ReadWriteLock:1274ms
Collections.synchronized:52746ms
**难以置信的性能差距，synchronized和Lock在Android的Art环境下确实有着一个数量级的差距，可达数十倍之多，但是在Hotspot环境下却恰恰相反，lock在多数情况下反而不如synchronized。
这里估计是Android Art虚拟机尚未对synchronized进行CAS优化，主要还是因为Android现在作为客户端操作系统，对高并发的资源竞争并无必要做优化，以上结果尚不能下定论，看来要去扒一扒Art的源码才能知道具体的原因了。**
总结
如果开发的是服务器程序，并且使用的是最新的hotspot虚拟机，synchronized和lock其实已经相差无几，其底层实现已经差不多了。但是如果你是Android开发者，使用synchronized还是需要考虑其性能差距的。