深入剖析 ConcurrentHashMap(未完待续)
hongjiang 2009-6-7
ConcurrentHashMap 是 Java5 中新增加的一个线程安全的 Map 集合,完全可以用来替代
HashTable。对于 ConcurrentHashMap 是如何提高其效率的,可能大多人只是知道它使用了
多个锁代替 HashTable 中的单个锁,也就是锁分离技术(Lock Stripping)。实际上,
ConcurrentHashMap 对提高并发方面的优化,还有一些其它的技巧在里面(比如你是否知道
在 get 操作的时候,它是否也使用了锁来保护?)。
我会试图用通俗一点的方法讲解一下 ConcurrentHashMap 的实现方式,不过因为水平
有限,在整理这篇文档的过程中,发现了更多自己未曾深入思考过的地方,使得我不得不从
新调整了自己的讲解方式。
我假设受众者大多是对 Java 存储模型(JMM)认识并不很深的(我本人也是)。如果我们
不断的对 ConcurrentHashMap 中一些实现追问下去,最终还是要归到 JMM 层面甚至更底层
的。这篇文章的关注点主要在同步方面,并不去分析 HashMap 中的一些数据结构方面的实
现。
ConcurrentHashMap 实现了 ConcurrentMap 接口,先看看 ConcurrentMap 接口的文档说明:
提供其他原子 putIfAbsent、remove、replace 方法的 Map。
内存一致性效果:当存在其他并发 collection 时,将对象放入 ConcurrentMap 之前的线
程中的操作 happen-before 随后通过另一线程从 ConcurrentMap 中访问或移除该元素的
操作。
我 们 不 关 心 ConcurrentMap 中 新 增 的 接 口 , 重 点 理 解 一 下 内 存 一 致 性 效 果 中 的
“happens-before”是怎么回事。因为要想从根本上讲明白,这个是无法避开的。这又不得不从
Java 存储模型来谈起了。
1. 理解 JAVA 存储模型(JMM)的 Happens-Before 规则。
在解释该规则之前,我们先看一段多线程访问数据的代码例子:
public class Test1 {
private int a=1, b=2;
public void foo(){ // 线程1
a=3;
b=4;
}
public int getA(){ // 线程2
return a;
}
public int getB(){ // 线程2
return b;
}
}
上面的代码,当线程 1 执行 foo 方法的时候,线程 2 访问 getA 和 getB 会得到什么样的结果?
答案:
A:a=1, b=2 // 都未改变
B:a=3, b=4 // 都改变了
C:a=3, b=2 // a 改变了,b 未改变
D:a=1, b=4 // b 改变了,a 未改变
上面的 A,B,C 都好理解,但是 D 可能会出乎一些人的预料。
一些不了解 JMM 的同学可能会问怎么可能 b=4 语句会先于 a=3 执行?
这是一个多线程之间内存可见性(Visibility)顺序不一致的问题。有两种可能会造成上面的
D 选项。
1) Java 编译器的重排序(Reording)操作有可能导致执行顺序和代码顺序不一致。
关于 Reording:
Java 语言规范规定了 JVM 要维护内部线程类似顺序化语义 (within-thread as-is-serial
semantics):只要程序的最终结果等同于它在严格的顺序化环境中执行的结果,那么上述所
有的行为都是允许的。
上面的话是《Java 并发编程实践》一书中引自 Java 语言规范的,感觉翻译的不太好。简单
的说:假设代码有两条语句,代码顺序是语句 1 先于语句 2 执行;那么只要语句 2 不依赖于
语句 1 的结果,打乱它们的顺序对最终的结果没有影响的话,那么真正交给 CPU 去执行时,
他们的顺序可以是没有限制的。可以允许语句 2 先于语句 1 被 CPU 执行,和代码中的顺序
不一致。
重排序(Reordering)是 JVM 针对现代 CPU 的一种优化,Reordering 后的指令会在性能上
有很大提升。(不知道这种优化对于多核 CPU 是否更加明显,也或许和单核多核没有关系。)
因为我们例子中的两条赋值语句,并没有依赖关系,无论谁先谁后结果都是一样的,所以就
可能有 Reordering 的情况,这种情况下,对于其他线程来说就可能造成了可见性顺序不一致
的问题。
2) 从线程工作内存写回主存时顺序无法保证。
下图描述了 JVM 中主存和线程工作内存之间的交互:
JLS 中对线程和主存互操作定义了 6 个行为,分别为 load,save,read,write,assign 和 use,
这些操作行为具有原子性,且相互依赖,有明确的调用先后顺序。这个细节也比较繁琐,我
们暂不深入追究。先简单认为线程在修改一个变量时,先拷贝入线程工作内存中,在线程工
作内存修改后再写回主存(Main Memery)中。
假设例子中 Reording 后顺序仍与代码中的顺序一致,那么接下来呢?
有意思的事情就发生在线程把 Working Copy Memery 中的变量写回 Main Memery 的时刻。
线程 1 把变量写回 Main Memery 的过程对线程 2 的可见性顺序也是无法保证的。
上面的列子,a=3; b=4; 这两个语句在 Working Copy Memery 中执行后,写回主存的过程对
于线程 2 来说同样可能出现先 b=4;后 a=3;这样的相反顺序。
Main Memery (Heap)
变量 1,变量 2,变量 3,变量。。。
Thread Working
Copy Memery
Load/ Save
Thread Working
Copy Memery
Read/ Write
Thread's Execution Engine
正因为上面的那些问题,JMM 中一个重要问题就是:如何让多线程之间,对象的状态对于
各线程的“可视性”是顺序一致的。
它的解决方式就是 Happens-before 规则:
JMM 为所有程序内部动作定义了一个偏序关系,叫做 happens-before。要想保证执行动作 B
的线程看到动作 A 的结果(无论 A 和 B 是否发生在同一个线程中),A 和 B 之间就必须满
足 happens-before 关系。
我们现在来看一下“Happens-before”规则都有哪些(摘自《Java 并发编程实践》):
① 程序次序法则:线程中的每个动作 A 都 happens-before 于该线程中的每一个动作 B,其
中,在程序中,所有的动作 B 都能出现在 A 之后。
② 监视器锁法则:对一个监视器锁的解锁 happens-before 于每一个后续对同一监视器锁的
加锁。
③ volatile 变量法则:对 volatile 域的写入操作 happens-before 于每一个后续对同一个域的读
写操作。
④ 线程启动法则:在一个线程里,对 Thread.start 的调用会 happens-before 于每个启动线程
的动作。
⑤ 线程终结法则:线程中的任何动作都 happens-before 于其他线程检测到这个线程已经终
结、或者从 Thread.join 调用中成功返回,或 Thread.isAlive 返回 false。
⑥ 中断法则:一个线程调用另一个线程的 interrupt happens-before 于被中断的线程发现中
断。
⑦ 终结法则:一个对象的构造函数的结束 happens-before 于这个对象 finalizer 的开始。
⑧ 传递性:如果 A happens-before 于 B,且 B happens-before 于 C,则 A happens-before 于 C
(更多关于 happens-before 描述见附注 2)
我们重点关注的是②,③,这两条也是我们通常编程中常用的。
后续分析 ConcurrenHashMap 时也会看到使用到锁(ReentrantLock),Volatile,final 等手段来
保证 happens-before 规则的。
使用锁方式实现“Happens-before”是最简单,容易理解的。
早期 Java 中的锁只有最基本的 synchronized,它是一种互斥的实现方式。在 Java5 之后,增
加了一些其它锁,比如 ReentrantLock,它基本作用和 synchronized 相似,但提供了更多的操
作方式,比如在获取锁时不必像 synchronized 那样只是傻等,可以设置定时,轮询,或者中
断,这些方法使得它在获取多个锁的情况可以避免死锁操作。
而我们需要了解的是 ReentrantLock 的性能相对 synchronized 来说有很大的提高。(不过据说
加锁 Lock(testObj)
a=3, b=4
解锁 Unlock(testObj)
加锁 Lock(testObj)
读取 a,b 的值
解锁 Unlock(testObj)
线程 1
线程 2
Java6 后对 synchronized 进行了优化,两者已经接近了。)
在 ConcurrentHashMap 中,每个 hash 区间使用的锁正是 ReentrantLock。
Volatile 可以看做一种轻量级的锁,但又和锁有些不同。
a) 它对于多线程,不是一种互斥(mutex)关系。
b) 用 volatile 修饰的变量,不能保证该变量状态的改变对于其他线程来说是一种“原子化操
作”。
在 Java5 之前,JMM 对 Volatile 的定义是:保证读写 volatile 都直接发生在 main memory 中,
线程的 working memory 不进行缓存。
它只承诺了读和写过程的可见性,并没有对 Reording 做限制,所以旧的 Volatile 并不太可靠。
在 Java5 之后,JMM 对 volatile 的语义进行了增强。就是我们看到的③ volatile 变量法则
那对于“原子化操作”怎么理解呢?看下面例子:
private static volatile int nextSerialNum = 0;
public static int generateSerialNumber(){
return nextSerialNum++;
}
上面代码中对 nextSerialNum 使用了 volatile 来修饰,根据前面“Happens-Before”法则的第三
条 Volatile 变量法则,看似不同线程都会得到一个新的 serialNumber
问 题 出 在 了 nextSerialNum++ 这 条 语 句 上 , 它 不 是 一 个 原 子 化 的 , 实 际 上 是
read-modify-write 三项操作,这就有可能使得在线程 1 在 write 之前,线程 2 也访问到了
nextSerialNum,造成了线程 1 和线程 2 得到一样的 serialNumber。
所以,在使用 Volatile 时,需要注意 a) 需不需要互斥;b)对象状态的改变是不是原子化的。
最后也说一下 final 关键字。
不变模式(immutable)是多线程安全里最简单的一种保障方式。因为你拿他没有办法,想
改变它也没有机会。
不变模式主要通过 final 关键字来限定的。
在 JMM 中 final 关键字还有特殊的语义。Final 域使得确保初始化安全性(initialization safety)
成为可能,初始化安全性让不可变形对象不需要同步就能自由地被访问和共享。
2)经过前面的了解,下面我们用 Happens-Before 规则理解一个经典问题:双重检测锁(DCL)
为什么在 java 中不适用?
public class LazySingleton {
private int someField;
private static LazySingleton instance;
private LazySingleton(){
this.someField = new Random().nextInt(200) + 1; // (1)
}
public static LazySingleton getInstance() {
if (instance == null) { // (2)
synchronized (LazySingleton.class) { // (3)
if (instance == null) { // (4)
instance = new LazySingleton(); // (5)
}
}
}
return instance; // (6)
}
public int getSomeField() {
return this.someField; // (7)
}
}
这里例子的详细解释可以看这里:http://www.javaeye.com/topic/260515?page=1
他解释的太详细了,是基于数学证明来分析的,看似更严谨一些,他的证明是因为那几条语句之
间不存在 Happens-before 约束,所以它们不能保证可见性顺序。理解起来有些抽象,对于经
验不多的程序员来说缺乏更有效的说服力。
我想简单的用对象创建期间的实际场景来分析一下:(注意,这种场景是我个人的理解,所看的
资料也是非官方的,不完全保证正确。如果发现不对请指出。见附注 1)
假设线程 1 执行完(5)时,线程 2 正好执行到了(2);
看看 new LazySingleton(); 这个语句的执行过程: 它不是一个原子操作,实际是由多个
步骤,我们从我们关注的角度简化一下,简单的认为它主要有 2 步操作好了:
a) 在内存中分配空间,并将引用指向该内存空间。
b) 执行对象的初始化的逻辑(<clinit>和<init>操作),完成对象的构建。
此时因为线程 1 和线程 2 没有用同步,他们之间不存在“Happens-Before”规则的约束,所以
在线程 1 创建 LazySingleton 对象的 a),b)这两个步骤对于线程 2 来说会有可能出现 a)可
见,b)不可见
造成了线程 2 获取到了一个未创建完整的 lazySingleton 对象引用,为后边埋下隐患。
之所以这里举到 DCL 这个例子,是因为我们后边分析 ConcurrentHashMap 时,也会遇到相
似的情况。
对于对象的创建,出于乐观考虑,两个线程之间没有用“Happens-Before 规则来约束”另一个
线程可能会得到一个未创建完整的对象,这种情况必须要检测,后续分析 ConcurrentHashMap
时再讨论。
附注 1:
我所定义的场景,是基于对以下资料了解的,比较低层,没有细看。
原文:http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html
其中分析一个对象创建过程的部分摘抄如下:
singletons[i].reference = new Singleton();
to the following (note that the Symantec JIT using a handle-based object
allocation system).
0206106A mov eax,0F97E78h
0206106F call 01F6B210 ; allocate space for
; Singleton, return
result in eax
02061074 mov dword ptr [ebp],eax ; EBP is
&singletons[i].reference
; store the
unconstructed object here.
02061077 mov ecx,dword ptr [eax] ; dereference the
handle to
; get the raw pointer
02061079 mov dword ptr [ecx],100h ; Next 4 lines are
0206107F mov dword ptr [ecx+4],200h ; Singleton's inlined
constructor
02061086 mov dword ptr [ecx+8],400h
0206108D mov dword ptr [ecx+0Ch],0F84030h
As you can see, the assignment to singletons[i].reference is performed before
the constructor for Singleton is called. This is completely legal under the
existing Java memory model, and also legal in C and C++ (since neither of
them have a memory model).
另外,从 JVM 创建一个对象的过程来看,分为:“装载”,“连接”,“初始化”三个步骤。
在连接步骤中包含“验证”,“准备”,“解析”这几个环节。
为一个对象分配内存的过程是在连接步骤的准备环节,它是先于“初始化”步骤的,而构造函
数的执行是在“初始化”步骤中的。
附注 2,
Java6 API 文档中对于内存一致性(Memory Consistency Properties)的描述:
内存一致性属性
Java Language Specification 第 17 章定义了内存操作(如共享变量的读写)的
happen-before 关系。只有写入操作 happen-before 读取操作时,才保证一个线程写入的
结果对另一个线程的读取是可视的。synchronized 和 volatile 构造 happen-before 关系,
Thread.start() 和 Thread.join() 方法形成 happen-before 关系。尤其是:
线程中的每个操作 happen-before 稍后按程序顺序传入的该线程中的每个操作。
一个解除锁监视器的(synchronized 阻塞或方法退出)happen-before 相同监视器
的每个后续锁(synchronized 阻塞或方法进入)。并且因为 happen-before 关系
是可传递的,所以解除锁定之前的线程的所有操作 happen-before 锁定该监视器的
任何线程后续的所有操作。
写入 volatile 字段 happen-before 每个后续读取相同字段。volatile 字段的读取和
写入与进入和退出监视器具有相似的内存一致性效果,但不 需要互斥锁。
在线程上调用 start happen-before 已启动的线程中的任何线程。
线程中的所有操作 happen-before 从该线程上的 join 成功返回的任何其他线程。
java.util.concurrent 中所有类的方法及其子包扩展了这些对更高级别同步的保证。尤其是:
线程中将一个对象放入任何并发 collection 之前的操作 happen-before 从另一线
程中的 collection 访问或移除该元素的后续操作。
线程中向 Executor 提交 Runnable 之前的操作 happen-before 其执行开始。同
样适用于向 ExecutorService 提交 Callables。
异步计算(由 Future 表示)所采取的操作 happen-before 通过另一线程中
Future.get() 获取结果后续的操作。
“释放”同步储存方法(如 Lock.unlock、Semaphore.release 和
CountDownLatch.countDown)之前的操作 happen-before 另一线程中相同同步储
存对象成功“获取”方法(如 Lock.lock、Semaphore.acquire、Condition.await 和
CountDownLatch.await)的后续操作。
对于通过 Exchanger 成功交换对象的每个线程对,每个线程中 exchange() 之前
的操作 happen-before 另一线程中对应 exchange() 后续的操作。
调用 CyclicBarrier.await 之前的操作 happen-before 屏障操作所执行的操作,屏
障操作所执行的操作 happen-before 从另一线程中对应 await 成功返回的后续操
作。
后续补充:
附注一种所引用的文章(Double-Checked Locking is Broken)是一篇比较著名的文章,但也
比较早;他所使用的 JIT 还是 Symantec(赛门铁克)JIT,这是一个很古老的 JIT,早已经退
出了 Java 舞台,不过我了解了一下历史,在 SUN 的 HotSpot JIT 出现之前,Symantec JIT 曾
是市场上编译最快的 JIT,我原以为 Symantec 只会做杀毒软件。
Symantec 的 JIT 反汇编后证明的逻辑,并不一定证明其他其他 JIT 也是这样的,我不清楚用
什么工具能将 java 执行过程用汇编语言表达出来。没有去证明其他的编译器。
所以我所描述的 new 一个对象的场景不一定是完全正确的(不同的编译器未必都和 Symantec
的实现方式一致),但是始终存在 reording 优化,即使编译器没有做,也有可能在 cpu 级去
做,所以 new 一个对象的过程对多线程访问始终存在不确定性。
Top Related