jvm并发之锁类别

I、java同步锁

重量级锁具有很大互斥性，线程的堵塞和唤醒都需要从用户态Ring3到内核态Ring0，频繁的切换会加重cpu的负担。传统的synchronized属于重量级锁，其实现原理基于对Mutex锁的调用，在每个对象的对象头都有一个指向Monitor的指针，线程在执行同步代码块的时候，会先执行MonitorEnter，获取Monitor的锁，退出时执行MonitorExit，同步方法则在方法描述的flag中添加一个ACC_SYNCHRONIZED,原理和Monitor差不多。重量级锁的实现机制：每个线程都维护着一个私有的Minitor Record组，每一个被锁住的对象都会和一个monitor record相关联，而对象头中的LockWord会指向关联的monitorRecord的起始位置。monitor record的结构为如下：

    

 Owner：若为null，则表示没有线程占用锁，若不为空，则表示拥有改对象锁的线程的标识。

EntryQ：关联一个互斥锁，阻塞所有试图获得锁的线程。

Rcthis：阻塞的线程个数。

Nest：实现重入锁的计数。

Candidate：0表示没有需要唤醒的线程，1表示需要唤醒一个线程来竞争锁。

下图为java对象头中的markWord：

 从图可以看出一共有5种状态：

          001表示无锁状态，bitfields存储的是对象的hashCode，age等。

       101表示偏向锁，threadID初始值为null，当有线程获得锁时，其值就是线程的标识。

       00标识轻量级锁，其bitfields指向线程栈中的lock Record空间。

       10表示重量级互斥锁，bitfields指向monitor，11表示GC垃圾回收标识。

II、轻量级锁

轻量级锁的实现利用操作系统的CAS（compare and swap），避免去进入monitor，汇编执行如 CMPXCHG。

获取轻量锁过程：

                   判断对象是否处于无锁状态，若是则在线程栈中年创建锁记录，保存Object Header的markWord和指向Object Header的指针，并尝试通过CAS将锁记录的指针修改到ObjectHeader的markWord，若成功修改为00（轻锁）状态。

                如果对象处于被锁状态，CAS失败，判断Object的MarkWord中的指针是否指向当前线程的锁记录，若是则表明这是一个递归加锁，则初始化锁记录为0，而不是ObjectHeader的markWord。若不是膨胀为重量级锁，修改ObjectMarkword指向线程的monitor Record，并修改状态为10。

解锁过程：

                CAS替换MarkWord，成功则解锁成功。失败则表示有另外一个线程竞争，释放锁唤醒阻塞线程，对于已经膨胀为重量级锁，则不降级，即不会降级为轻量级锁。

 轻量级锁流程：

 分析在openJdk7中的代码：

        hotspot目录下的Synchronizer.cpp类中，轻量级进入同步如下：

            

 

 

下面是锁膨胀的过程：

1. ObjectMonitor * ATTR ObjectSynchronizer::inflate (Thread * Self, oop object) {
2. // Inflate mutates the heap ...
3. // Relaxing assertion for bug 6320749.
4. assert (Universe::verify_in_progress() ||
5. !SafepointSynchronize::is_at_safepoint(), "invariant") ;
7. for (;;) {
8. //获取object的markWord
9. const markOop mark = object->mark() ;
10. assert (!mark->has_bias_pattern(), "invariant") ;
12. // The mark can be in one of the following states:
13. // * Inflated - just return
14. // * Stack-locked - coerce it to inflated
15. // * INFLATING - busy wait for conversion to complete
16. // * Neutral - aggressively inflate the object.
17. // * BIASED - Illegal. We should never see this
19. // CASE: inflated
20. if (mark->has_monitor()) {//若是已经膨胀为重量级锁，则返回
21. ObjectMonitor * inf = mark->monitor() ;
22. assert (inf->header()->is_neutral(), "invariant");
23. assert (inf->object() == object, "invariant") ;
24. assert (ObjectSynchronizer::verify_objmon_isinpool(inf), "monitor is invalid");
25. return inf ;
26. }
28. // CASE: inflation in progress - inflating over a stack-lock.
29. // Some other thread is converting from stack-locked to inflated.
30. // Only that thread can complete inflation -- other threads must wait.
31. // The INFLATING value is transient.
32. // Currently, we spin/yield/park and poll the markword, waiting for inflation to finish.
33. // We could always eliminate polling by parking the thread on some auxiliary list.
34. if (mark == markOopDesc::INFLATING()) {//正在膨胀，并等待膨胀完毕
35. TEVENT (Inflate: spin while INFLATING) ;
36. ReadStableMark(object) ;
37. continue ;
38. }
40. // CASE: stack-locked
41. // Could be stack-locked either by this thread or by some other thread.
42. //
43. // Note that we allocate the objectmonitor speculatively, _before_ attempting
44. // to install INFLATING into the mark word. We originally installed INFLATING,
45. // allocated the objectmonitor, and then finally STed the address of the
46. // objectmonitor into the mark. This was correct, but artificially lengthened
47. // the interval in which INFLATED appeared in the mark, thus increasing
48. // the odds of inflation contention.
49. //
50. // We now use per-thread private objectmonitor free lists.
51. // These list are reprovisioned from the global free list outside the
52. // critical INFLATING...ST interval. A thread can transfer
53. // multiple objectmonitors en-mass from the global free list to its local free list.
54. // This reduces coherency traffic and lock contention on the global free list.
55. // Using such local free lists, it doesn't matter if the omAlloc() call appears
56. // before or after the CAS(INFLATING) operation.
57. // See the comments in omAlloc().
58. //若没有线程膨胀锁，线程开始膨胀锁
59. if (mark->has_locker()) {//若有线程锁，证明存在竞争线程
60. ObjectMonitor * m = omAlloc (Self) ;//从线程local中omInFreeList获取到一个可用的monitor，若omInFreeList没有则从全局gFreeList中获取，再没有的话new ObjectMonitor。
61. // Optimistically prepare the objectmonitor - anticipate successful CAS
62. // We do this before the CAS in order to minimize the length of time
63. // in which INFLATING appears in the mark.
64. m->Recycle();
65. m->_Responsible = NULL ;
66. m->OwnerIsThread = 0 ;
67. m->_recursions = 0 ;
68. m->_SpinDuration = ObjectMonitor::Knob_SpinLimit ; // Consider: maintain by type/class
69. //CAS修改markWord(0值)，修改为正在膨胀状态
70. markOop cmp = (markOop) Atomic::cmpxchg_ptr (markOopDesc::INFLATING(), object->mark_addr(), mark) ;
71. if (cmp != mark) {//失败再次尝试
72. //将monitor放回线程的omInFreeList
73. omRelease (Self, m, true) ;
74. continue ; // Interference -- just retry
75. }
77. // We've successfully installed INFLATING (0) into the mark-word.
78. // This is the only case where 0 will appear in a mark-work.
79. // Only the singular thread that successfully swings the mark-word
80. // to 0 can perform (or more precisely, complete) inflation.
81. //
82. // Why do we CAS a 0 into the mark-word instead of just CASing the
83. // mark-word from the stack-locked value directly to the new inflated state?
84. // Consider what happens when a thread unlocks a stack-locked object.
85. // It attempts to use CAS to swing the displaced header value from the
86. // on-stack basiclock back into the object header. Recall also that the
87. // header value (hashcode, etc) can reside in (a) the object header, or
88. // (b) a displaced header associated with the stack-lock, or (c) a displaced
89. // header in an objectMonitor. The inflate() routine must copy the header
90. // value from the basiclock on the owner's stack to the objectMonitor, all
91. // the while preserving the hashCode stability invariants. If the owner
92. // decides to release the lock while the value is 0, the unlock will fail
93. // and control will eventually pass from slow_exit() to inflate. The owner
94. // will then spin, waiting for the 0 value to disappear. Put another way,
95. // the 0 causes the owner to stall if the owner happens to try to
96. // drop the lock (restoring the header from the basiclock to the object)
97. // while inflation is in-progress. This protocol avoids races that might
98. // would otherwise permit hashCode values to change or "flicker" for an object.
99. // Critically, while object->mark is 0 mark->displaced_mark_helper() is stable.
100. // 0 serves as a "BUSY" inflate-in-progress indicator.
103. // fetch the displaced mark from the owner's stack.
104. // The owner can't die or unwind past the lock while our INFLATING
105. // object is in the mark. Furthermore the owner can't complete
106. // an unlock on the object, either.
107. markOop dmw = mark->displaced_mark_helper() ;//获取displaced_mark（hashcode,age）
108. assert (dmw->is_neutral(), "invariant") ;
110. // Setup monitor fields to proper values -- prepare the monitor
111. m->set_header(dmw) ;//monitor存储displaced_mark_word
113. // Optimization: if the mark->locker stack address is associated
114. // with this thread we could simply set m->_owner = Self and
115. // m->OwnerIsThread = 1. Note that a thread can inflate an object
116. // that it has stack-locked -- as might happen in wait() -- directly
117. // with CAS. That is, we can avoid the xchg-NULL .... ST idiom.
118. m->set_owner(mark->locker());//设置monitor的拥有者
119. m->set_object(object);
120. // TODO-FIXME: assert BasicLock->dhw != 0.
122. // Must preserve store ordering. The monitor state must
123. // be stable at the time of publishing the monitor address.
124. guarantee (object->mark() == markOopDesc::INFLATING(), "invariant") ;
125. object->release_set_mark(markOopDesc::encode(m));//markWord设置为重量级锁ptr|10
127. // Hopefully the performance counters are allocated on distinct cache lines
128. // to avoid false sharing on MP systems ...
129. if (ObjectMonitor::_sync_Inflations != NULL) ObjectMonitor::_sync_Inflations->inc() ;
130. TEVENT(Inflate: overwrite stacklock) ;
131. if (TraceMonitorInflation) {
132. if (object->is_instance()) {
133. ResourceMark rm;
134. tty->print_cr("Inflating object " INTPTR_FORMAT " , mark " INTPTR_FORMAT " , type %s",
135. (intptr_t) object, (intptr_t) object->mark(),
136. Klass::cast(object->klass())->external_name());
137. }
138. }
139. return m ;
140. }
142. // CASE: neutral
143. // TODO-FIXME: for entry we currently inflate and then try to CAS _owner.
144. // If we know we're inflating for entry it's better to inflate by swinging a
145. // pre-locked objectMonitor pointer into the object header. A successful
146. // CAS inflates the object *and* confers ownership to the inflating thread.
147. // In the current implementation we use a 2-step mechanism where we CAS()
148. // to inflate and then CAS() again to try to swing _owner from NULL to Self.
149. // An inflateTry() method that we could call from fast_enter() and slow_enter()
150. // would be useful.
151. //线程2在开始膨胀锁时，线程1已经解锁的情况下，创建膨胀锁
152. assert (mark->is_neutral(), "invariant");
153. ObjectMonitor * m = omAlloc (Self) ;
154. // prepare m for installation - set monitor to initial state
155. m->Recycle();
156. m->set_header(mark);
157. m->set_owner(NULL);
158. m->set_object(object);
159. m->OwnerIsThread = 1 ;
160. m->_recursions = 0 ;
161. m->_Responsible = NULL ;
162. m->_SpinDuration = ObjectMonitor::Knob_SpinLimit ; // consider: keep metastats by type/class
163. //CAS monitor
164. if (Atomic::cmpxchg_ptr (markOopDesc::encode(m), object->mark_addr(), mark) != mark) {
165. m->set_object (NULL) ;
166. m->set_owner (NULL) ;
167. m->OwnerIsThread = 0 ;
168. m->Recycle() ;
169. omRelease (Self, m, true) ;
170. m = NULL ;
171. continue ;
172. // interference - the markword changed - just retry.
173. // The state-transitions are one-way, so there's no chance of
174. // live-lock -- "Inflated" is an absorbing state.
175. }
177. // Hopefully the performance counters are allocated on distinct
178. // cache lines to avoid false sharing on MP systems ...
179. if (ObjectMonitor::_sync_Inflations != NULL) ObjectMonitor::_sync_Inflations->inc() ;
180. TEVENT(Inflate: overwrite neutral) ;
181. if (TraceMonitorInflation) {
182. if (object->is_instance()) {
183. ResourceMark rm;
184. tty->print_cr("Inflating object " INTPTR_FORMAT " , mark " INTPTR_FORMAT " , type %s",
185. (intptr_t) object, (intptr_t) object->mark(),
186. Klass::cast(object->klass())->external_name());
187. }
188. }
189. return m ;
190. }
191. }

 锁膨胀过程：

        

 

 退出锁：

    

 

1. void ObjectSynchronizer::fast_exit(oop object, BasicLock* lock, TRAPS) {
2. assert(!object->mark()->has_bias_pattern(), "should not see bias pattern here");
3. // if displaced header is null, the previous enter is recursive enter, no-op
5. markOop dhw = lock->displaced_header();
6. markOop mark ;
7. if (dhw == NULL) { //递归加锁的在slowEnter里已经把lockRecord设置为null
8. // Recursive stack-lock.
9. // Diagnostics -- Could be: stack-locked, inflating, inflated.
10. mark = object->mark() ;//获取object的markWord
11. assert (!mark->is_neutral(), "invariant") ;
12. if (mark->has_locker() && mark != markOopDesc::INFLATING()) {//判断是否有lock并且当前锁是否正在膨胀
13. assert(THREAD->is_lock_owned((address)mark->locker()), "invariant") ;
14. }
15. if (mark->has_monitor()) {//判断markRecord是否有monitor重量级锁
16. ObjectMonitor * m = mark->monitor() ;
17. assert(((oop)(m->object()))->mark() == mark, "invariant") ;
18. assert(m->is_entered(THREAD), "invariant") ;//
19. }
20. return ;
21. }
23. mark = object->mark() ;
25. // If the object is stack-locked by the current thread, try to
26. // swing the displaced header from the box back to the mark.
27. //不存在线程竞争，线程CAS将lockRecord和object的markWord交换
28. if (mark == (markOop) lock) {
29. assert (dhw->is_neutral(), "invariant") ;
30. if ((markOop) Atomic::cmpxchg_ptr (dhw, object->mark_addr(), mark) == mark) {
31. TEVENT (fast_exit: release stacklock) ;
32. return;
33. }
34. }
36. ObjectSynchronizer::inflate(THREAD, object)->exit (THREAD) ;//释放锁
37. }

III、偏向锁

偏向锁：与轻量级锁比较，因为cas操作任然存在的一定的开销，故出现了偏向锁。只有第一个线程CAS成功才能把线程id假如到markWord中，这时候可以叫该对象偏向于该线程。当该线程再次去获得锁时不需要执行CAS操作更新markWork，虽然堆栈上的锁记录未被初始化，但其对于对象是偏向的，故不需要校验。当存在另外一个线程在该对象同步时，需要撤销偏向锁，到达安全点（safePoint）时（线程暂停）遍历获得偏向锁的线程堆栈，调整锁记录和Object的markWord关联（轻量级锁）。解锁过程如轻量级锁。

            

各种锁的状态转换图：

 

 

 

参考资料： http://www.cnblogs.com/paddix/p/5405678.html（java锁的介绍）

                   http:// http://blog.csdn.net/zbuger/article/details/51030772

                  http://blog.csdn.net/hffhjh111/article/details/53140909（window的Mutex介绍）

                    https://translate.google.com/translate?hl=zh-CN&sl=en&tl=zh-CN&u=https%3A%2F%2Fwiki.openjdk.java.net%2Fdisplay%2FHotSpot%2FSynchronization&anno=2

null

附件列表

 

转载于:https://www.cnblogs.com/zhenyimo/p/6738210.html