码迷，mamicode.com
首页 > 编程语言 > 详细

4.锁定--Java的LockSupport.park()实现分析

时间：2015-10-05 14:15:10      阅读：1314      评论：0      收藏：0      [点我收藏+]

标签：

LockSupport类是Java6(JSR166-JUC)引入的一个类，提供了主要的线程同步原语。

LockSupport实际上是调用了Unsafe类里的函数。归结到Unsafe里，仅仅有两个函数：

[java] view plaincopy技术分享技术分享
  1. public native void unpark(Thread jthread);  
  2. public native void park(boolean isAbsolute, long time);  

isAbsolute參数是指明时间是绝对的，还是相对的。

只两个简单的接口。就为上层提供了强大的同步原语。

先来解析下两个函数是做什么的。

unpark函数为线程提供“许可(permit)”，线程调用park函数则等待“许可”。

这个有点像信号量，可是这个“许可”是不能叠加的，“许可”是一次性的。

比方线程B连续调用了三次unpark函数，当线程A调用park函数就使用掉这个“许可”，假设线程A再次调用park，则进入等待状态。

注意。unpark函数能够先于park调用。比方线程B调用unpark函数，给线程A发了一个“许可”，那么当线程A调用park时。它发现已经有“许可”了。那么它会立即再继续执行。

实际上，park函数即使没有“许可”。有时也会无理由地返回，这点等下再解析。

park和unpark的灵活之处

上面已经提到，unpark函数能够先于park调用。这个正是它们的灵活之处。

一个线程它有可能在别的线程unPark之前，或者之后，或者同一时候调用了park，那么由于park的特性。它能够不用操心自己的park的时序问题，否则，假设park必需要在unpark之前，那么给编程带来非常大的麻烦。。

考虑一下，两个线程同步，要怎样处理？

在Java5里是用wait/notify/notifyAll来同步的。wait/notify机制有个非常蛋疼的地方是，比方线程B要用notify通知线程A。那么线程B要确保线程A已经在wait调用上等待了，否则线程A可能永远都在等待。编程的时候就会非常蛋疼。

另外，是调用notify，还是notifyAll？

notify仅仅会唤醒一个线程，假设错误地有两个线程在同一个对象上wait等待。那么又悲剧了。为了安全起见，貌似仅仅能调用notifyAll了。

park/unpark模型真正解耦了线程之间的同步。线程之间不再须要一个Object或者其他变量来存储状态。不再须要关心对方的状态。


HotSpot里park/unpark的实现

每一个java线程都有一个Parker实例。Parker类是这样定义的：

[cpp] view plaincopy技术分享技术分享
  1. class Parker : public os::PlatformParker {  
  2. private:  
  3.   volatile int _counter ;  
  4.   ...  
  5. public:  
  6.   void park(bool isAbsolute, jlong time);  
  7.   void unpark();  
  8.   ...  
  9. }  
  10. class PlatformParker : public CHeapObj<mtInternal> {  
  11.   protected:  
  12.     pthread_mutex_t _mutex [1] ;  
  13.     pthread_cond_t  _cond  [1] ;  
  14.     ...  
  15. }  
能够看到Parker类实际上用Posix的mutex，condition来实现的。

在Parker类里的_counter字段，就是用来记录所谓的“许可”的。

当调用park时，先尝试直接是否能直接拿到“许可”，即_counter>0时。假设成功。则把_counter设置为0,并返回：

[cpp] view plaincopy技术分享技术分享
  1. void Parker::park(bool isAbsolute, jlong time) {  
  2.   // Ideally we‘d do something useful while spinning, such  
  3.   // as calling unpackTime().  
  4.   
  5.   
  6.   // Optional fast-path check:  
  7.   // Return immediately if a permit is available.  
  8.   // We depend on Atomic::xchg() having full barrier semantics  
  9.   // since we are doing a lock-free update to _counter.  
  10.   if (Atomic::xchg(0, &_counter) > 0) return;  

假设不成功，则构造一个ThreadBlockInVM。然后检查_counter是不是>0。假设是，则把_counter设置为0，unlock mutex并返回：

[cpp] view plaincopy技术分享技术分享
  1. ThreadBlockInVM tbivm(jt);  
  2. if (_counter > 0)  { // no wait needed  
  3.   _counter = 0;  
  4.   status = pthread_mutex_unlock(_mutex);  

否则，再推断等待的时间，然后再调用pthread_cond_wait函数等待，假设等待返回。则把_counter设置为0，unlock mutex并返回：

[cpp] view plaincopy技术分享技术分享
  1. if (time == 0) {  
  2.   status = pthread_cond_wait (_cond, _mutex) ;  
  3. }  
  4. _counter = 0 ;  
  5. status = pthread_mutex_unlock(_mutex) ;  
  6. assert_status(status == 0, status, "invariant") ;  
  7. OrderAccess::fence();  
当unpark时，则简单多了。直接设置_counter为1。再unlock mutext返回。假设_counter之前的值是0，则还要调用pthread_cond_signal唤醒在park中等待的线程：

[cpp] view plaincopy技术分享技术分享
  1. void Parker::unpark() {  
  2.   int s, status ;  
  3.   status = pthread_mutex_lock(_mutex);  
  4.   assert (status == 0, "invariant") ;  
  5.   s = _counter;  
  6.   _counter = 1;  
  7.   if (s < 1) {  
  8.      if (WorkAroundNPTLTimedWaitHang) {  
  9.         status = pthread_cond_signal (_cond) ;  
  10.         assert (status == 0, "invariant") ;  
  11.         status = pthread_mutex_unlock(_mutex);  
  12.         assert (status == 0, "invariant") ;  
  13.      } else {  
  14.         status = pthread_mutex_unlock(_mutex);  
  15.         assert (status == 0, "invariant") ;  
  16.         status = pthread_cond_signal (_cond) ;  
  17.         assert (status == 0, "invariant") ;  
  18.      }  
  19.   } else {  
  20.     pthread_mutex_unlock(_mutex);  
  21.     assert (status == 0, "invariant") ;  
  22.   }  
  23. }  
简而言之。是用mutex和condition保护了一个_counter的变量。当park时。这个变量置为了0，当unpark时，这个变量置为1。


值得注意的是在park函数里。调用pthread_cond_wait时，并没实用while来推断，所以posix condition里的"Spurious wakeup"一样会传递到上层Java的代码里。

关于"Spurious wakeup"，參考上一篇blog：http://blog.csdn.net/hengyunabc/article/details/27969613

[cpp] view plaincopy技术分享技术分享
  1. if (time == 0) {  
  2.   status = pthread_cond_wait (_cond, _mutex) ;  
  3. }  

这也就是为什么Java dos里提到，当以下三种情况下park函数会返回：

  • Some other thread invokes unpark with the current thread as the target; or
  • Some other thread interrupts the current thread; or
  • The call spuriously (that is, for no reason) returns.

相关的实现代码在：

http://hg.openjdk.java.net/build-infra/jdk7/hotspot/file/52c4a1ae6adc/src/share/vm/runtime/park.hpp
http://hg.openjdk.java.net/build-infra/jdk7/hotspot/file/52c4a1ae6adc/src/share/vm/runtime/park.cpp
http://hg.openjdk.java.net/build-infra/jdk7/hotspot/file/52c4a1ae6adc/src/os/linux/vm/os_linux.hpp
http://hg.openjdk.java.net/build-infra/jdk7/hotspot/file/52c4a1ae6adc/src/os/linux/vm/os_linux.cpp  

其他的一些东东：

Parker类在分配内存时，使用了一个技巧，重载了new函数来实现了cache line对齐。

[cpp] view plaincopy
  1. // We use placement-new to force ParkEvent instances to be  
  2. // aligned on 256-byte address boundaries.  This ensures that the least  
  3. // significant byte of a ParkEvent address is always 0.  
  4.    
  5. void * operator new (size_t sz) ;  
Parker里使用了一个无锁的队列在分配释放Parker实例：

[cpp] view plaincopy
  1. volatile int Parker::ListLock = 0 ;  
  2. Parker * volatile Parker::FreeList = NULL ;  
  3.   
  4. Parker * Parker::Allocate (JavaThread * t) {  
  5.   guarantee (t != NULL, "invariant") ;  
  6.   Parker * p ;  
  7.   
  8.   // Start by trying to recycle an existing but unassociated  
  9.   // Parker from the global free list.  
  10.   for (;;) {  
  11.     p = FreeList ;  
  12.     if (p  == NULL) break ;  
  13.     // 1: Detach  
  14.     // Tantamount to p = Swap (&FreeList, NULL)  
  15.     if (Atomic::cmpxchg_ptr (NULL, &FreeList, p) != p) {  
  16.        continue ;  
  17.     }  
  18.   
  19.     // We‘ve detached the list.  The list in-hand is now  
  20.     // local to this thread.   This thread can operate on the  
  21.     // list without risk of interference from other threads.  
  22.     // 2: Extract -- pop the 1st element from the list.  
  23.     Parker * List = p->FreeNext ;  
  24.     if (List == NULL) break ;  
  25.     for (;;) {  
  26.         // 3: Try to reattach the residual list  
  27.         guarantee (List != NULL, "invariant") ;  
  28.         Parker * Arv =  (Parker *) Atomic::cmpxchg_ptr (List, &FreeList, NULL) ;  
  29.         if (Arv == NULL) break ;  
  30.   
  31.         // New nodes arrived.  Try to detach the recent arrivals.  
  32.         if (Atomic::cmpxchg_ptr (NULL, &FreeList, Arv) != Arv) {  
  33.             continue ;  
  34.         }  
  35.         guarantee (Arv != NULL, "invariant") ;  
  36.         // 4: Merge Arv into List  
  37.         Parker * Tail = List ;  
  38.         while (Tail->FreeNext != NULL) Tail = Tail->FreeNext ;  
  39.         Tail->FreeNext = Arv ;  
  40.     }  
  41.     break ;  
  42.   }  
  43.   
  44.   if (p != NULL) {  
  45.     guarantee (p->AssociatedWith == NULL, "invariant") ;  
  46.   } else {  
  47.     // Do this the hard way -- materialize a new Parker..  
  48.     // In rare cases an allocating thread might detach  
  49.     // a long list -- installing null into FreeList --and  
  50.     // then stall.  Another thread calling Allocate() would see  
  51.     // FreeList == null and then invoke the ctor.  In this case we  
  52.     // end up with more Parkers in circulation than we need, but  
  53.     // the race is rare and the outcome is benign.  
  54.     // Ideally, the # of extant Parkers is equal to the  
  55.     // maximum # of threads that existed at any one time.  
  56.     // Because of the race mentioned above, segments of the  
  57.     // freelist can be transiently inaccessible.  At worst  
  58.     // we may end up with the # of Parkers in circulation  
  59.     // slightly above the ideal.  
  60.     p = new Parker() ;  
  61.   }  
  62.   p->AssociatedWith = t ;          // Associate p with t  
  63.   p->FreeNext       = NULL ;  
  64.   return p ;  
  65. }  
  66.   
  67.   
  68. void Parker::Release (Parker * p) {  
  69.   if (p == NULL) return ;  
  70.   guarantee (p->AssociatedWith != NULL, "invariant") ;  
  71.   guarantee (p->FreeNext == NULL      , "invariant") ;  
  72.   p->AssociatedWith = NULL ;  
  73.   for (;;) {  
  74.     // Push p onto FreeList  
  75.     Parker * List = FreeList ;  
  76.     p->FreeNext = List ;  
  77.     if (Atomic::cmpxchg_ptr (p, &FreeList, List) == List) break ;  
  78.   }  
  79. }  

总结与扯谈

JUC(Java Util Concurrency)仅用简单的park, unpark和CAS指令就实现了各种高级同步数据结构，并且效率非常高，令人惊叹。

在C++程序猿各种自制轮子的时候，Java程序猿则有非常丰富的并发数据结构，如lock，latch，queue，map等信手拈来。

要知道像C++直到C++11才有标准的线程库，同步原语，但离高级的并发数据结构还有非常远。boost库有提供一些线程，同步相关的类，但也是非常easy的。

Intel的tbb有一些高级的并发数据结构，可是国内boost都用得少，更别说tbb了。

最開始研究无锁算法的是C/C++程序猿，可是后来非常多Java程序猿。或者类库開始自制各种高级的并发数据结构，常常能够看到有分析Java并发包的文章。

反而C/C++程序猿总是在分析无锁的队列算法。

高级的并发数据结构。比方并发的HashMap。没有看到有相关的实现或者分析的文章。在C++11之后，这样的情况才有好转。

由于正确高效实现一个Concurrent Hash Map是非常困难的，要对内存CPU有深刻的认识。并且还要面对CPU不断升级带来的各种坑。

我觉得真正值得信赖的C++并发库，仅仅有Intel的tbb和微软的PPL。

https://software.intel.com/en-us/node/506042     Intel? Threading Building Blocks 

http://msdn.microsoft.com/en-us/library/dd492418.aspx   Parallel Patterns Library (PPL)

另外FaceBook也开源了一个C++的类库，里面也有并发数据结构。

https://github.com/facebook/folly

版权声明：本文博主原创文章，博客，未经同意不得转载。

4.锁定--Java的LockSupport.park()实现分析

标签：

原文地址：http://www.cnblogs.com/lcchuguo/p/4855664.html
踩
(0)
赞
(0)
   
举报
评论 一句话评论（0）
登录后才能评论！
分享档案
更多>
2021年07月29日 (22)
2021年07月28日 (40)
2021年07月27日 (32)
2021年07月26日 (79)
2021年07月23日 (29)
2021年07月22日 (30)
2021年07月21日 (42)
2021年07月20日 (16)
2021年07月19日 (90)
2021年07月16日 (35)
周排行
mamicode.com排行更多图片
更多
友情链接
兰亭集智   国之画   百度统计   站长统计   阿里云   chrome插件   新版天听网
关于我们 - 联系我们 - 留言反馈
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码！