【底层原理之旅—从底层分析LockSupport原理机制】|Java 刷题打卡

简介: 【底层原理之旅—从底层分析LockSupport原理机制】|Java 刷题打卡

题目


从底层分析LockSupport原理机制




知识点


LockSupport的介绍


LockSupport类是Java6(JSR166-JUC)引入的一个类,提供了基本的线程同步原语。LockSupport实际上是调用了Unsafe类里的函数,归结到Unsafe里,只有两个函数,而仅仅两个简单的接口,就为上层提供了强大的同步原语,先来解析下两个函数是做什么的。



public native void unpark(Thread jthread);  
public native void park(boolean isAbsolute, long time);  
复制代码



  • park:阻塞当前线程(Block current thread),字面理解park,就算占住,停车的时候不就把这个车位给占住了么?起这个名字还是很形象的



  • isAbsolute参数是指明时间是否属于绝对。
  • time参数是指时间值




线程调用park函数则等待"许可"。

  • unpark: 使给定的线程停止阻塞(Unblock the given thread blocked)
  • thread参数是指对相应的线程进行解除阻塞。




线程调用unpark函数为线程提供"许可(permit)"。

  • 这个有点像信号量,但是这个"许可"是不能叠加的,"许可"是一次性的。
  • 比如,线程B连续调用了三次unpark函数,当线程A调用park函数就使用掉这个"许可",如果线程A再次调用park,则进入等待状态




注意,unpark函数可以先于park调用。比如线程B调用unpark函数,给线程A发了一个"许可",那么当线程A调用park时,它发现已经有"许可"了,那么它会马上再继续运行。(此部分比wait/notify(notifyAll))要好很多。




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类是这样定义的

class Parker : public os::PlatformParker {  
private:  
 volatile int _counter ;  
 ...  
public:  
 void park(bool isAbsolute, jlong time);  
 void unpark();  
 ...  
}  
class PlatformParker : public CHeapObj<mtInternal> {  
 protected:  
   pthread_mutex_t _mutex [1] ;  
   pthread_cond_t  _cond  [1] ;  
   ...  
}  
复制代码




  • 可以看到Parker类实际上用Posix的mutex,condition来实现的
  • 在Parker类里的_counter字段,就是用来记录所谓的“许可”的
  • 当调用park时,先尝试直接能否直接拿到"许可",即_counter>0时,如果成功,则把_counter设置为0,并返回:(和信号量的思路很像!)





void Parker::park(bool isAbsolute, jlong time) {  
  // Ideally we'd do something useful while spinning, such  
  // as calling unpackTime().  
  // Optional fast-path check:  
  // Return immediately if a permit is available.  
  // We depend on Atomic::xchg() having full barrier semantics  
  // since we are doing a lock-free update to _counter.  
  if (Atomic::xchg(0, &_counter) > 0) return;  
复制代码



如果不成功,则构造一个ThreadBlockInVM,然后检查_counter是不是>0,如果是,则把_counter设置为0,unlock mutex并返回:

ThreadBlockInVM tbivm(jt);  
if (_counter > 0)  { // no wait needed  
  _counter = 0;  
  status = pthread_mutex_unlock(_mutex);  
复制代码




否则,再判断等待的时间,然后再调用pthread_cond_wait函数等待,如果等待返回,则把_counter设置为0,unlock mutex并返回:

if (time == 0) {  
 status = pthread_cond_wait (_cond, _mutex) ;  
}  
_counter = 0 ;  
status = pthread_mutex_unlock(_mutex) ;  
assert_status(status == 0, status, "invariant") ;  
OrderAccess::fence();  
复制代码




当unpark时,则简单多了,直接设置_counter为1,再unlock mutext返回。如果_counter之前的值是0,则还要调用pthread_cond_signal唤醒在park中等待的线程

void Parker::unpark() {  
  int s, status ;  
  status = pthread_mutex_lock(_mutex);  
  assert (status == 0, "invariant") ;  
  s = _counter;  
  _counter = 1;  
  if (s < 1) {  
     if (WorkAroundNPTLTimedWaitHang) {  
        status = pthread_cond_signal (_cond) ;  
        assert (status == 0, "invariant") ;  
        status = pthread_mutex_unlock(_mutex);  
        assert (status == 0, "invariant") ;  
     } else {  
        status = pthread_mutex_unlock(_mutex);  
        assert (status == 0, "invariant") ;  
        status = pthread_cond_signal (_cond) ;  
        assert (status == 0, "invariant") ;  
     }  
  } else {  
    pthread_mutex_unlock(_mutex);  
    assert (status == 0, "invariant") ;  
  }  
}
复制代码




  • 用mutex和condition保护了一个_counter的变量,当park时,这个变量置为了0,当unpark时,这个变量置为1
  • 值得注意的是在park函数里,调用pthread_cond_wait时,并没有用while来判断,所以posix condition里的"Spurious wakeup"一样会传递到上层Java的代码里




if (time == 0) {  
  status = pthread_cond_wait (_cond, _mutex) ;  
}  
复制代码



这也就是为什么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.
复制代码



相关的实现代码在:


hg.openjdk.java.net/build-infra…hg.openjdk.java.net/build-infra…hg.openjdk.java.net/build-infra…hg.openjdk.java.net/build-infra…

其它的一些东东: Parker类在分配内存时,使用了一个技巧,重载了new函数来实现了cache line对齐。

// We use placement-new to force ParkEvent instances to be  
// aligned on 256-byte address boundaries.  This ensures that the least  
// significant byte of a ParkEvent address is always 0.  
void * operator new (size_t sz) ;  
Parker里使用了一个无锁的队列在分配释放Parker实例:
复制代码



volatile int Parker::ListLock = 0 ;  
Parker * volatile Parker::FreeList = NULL ;  
Parker * Parker::Allocate (JavaThread * t) {  
  guarantee (t != NULL, "invariant") ;  
  Parker * p ;  
  // Start by trying to recycle an existing but unassociated  
  // Parker from the global free list.  
  for (;;) {  
    p = FreeList ;  
    if (p  == NULL) break ;  
    // 1: Detach  
    // Tantamount to p = Swap (&FreeList, NULL)  
    if (Atomic::cmpxchg_ptr (NULL, &FreeList, p) != p) {  
       continue ;  
    }  
    // We've detached the list.  The list in-hand is now  
    // local to this thread.   This thread can operate on the  
    // list without risk of interference from other threads.  
    // 2: Extract -- pop the 1st element from the list.  
    Parker * List = p->FreeNext ;  
    if (List == NULL) break ;  
    for (;;) {  
        // 3: Try to reattach the residual list  
        guarantee (List != NULL, "invariant") ;  
        Parker * Arv =  (Parker *) Atomic::cmpxchg_ptr (List, &FreeList, NULL) ;  
        if (Arv == NULL) break ;  
        // New nodes arrived.  Try to detach the recent arrivals.  
        if (Atomic::cmpxchg_ptr (NULL, &FreeList, Arv) != Arv) {  
            continue ;  
        }  
        guarantee (Arv != NULL, "invariant") ;  
        // 4: Merge Arv into List  
        Parker * Tail = List ;  
        while (Tail->FreeNext != NULL) Tail = Tail->FreeNext ;  
        Tail->FreeNext = Arv ;  
    }  
    break ;  
  }  
  if (p != NULL) {  
    guarantee (p->AssociatedWith == NULL, "invariant") ;  
  } else {  
    // Do this the hard way -- materialize a new Parker..  
    // In rare cases an allocating thread might detach  
    // a long list -- installing null into FreeList --and  
    // then stall.  Another thread calling Allocate() would see  
    // FreeList == null and then invoke the ctor.  In this case we  
    // end up with more Parkers in circulation than we need, but  
    // the race is rare and the outcome is benign.  
    // Ideally, the # of extant Parkers is equal to the  
    // maximum # of threads that existed at any one time.  
    // Because of the race mentioned above, segments of the  
    // freelist can be transiently inaccessible.  At worst  
    // we may end up with the # of Parkers in circulation  
    // slightly above the ideal.  
    p = new Parker() ;  
  }  
  p->AssociatedWith = t ;          // Associate p with t  
  p->FreeNext       = NULL ;  
  return p ;  
}  
void Parker::Release (Parker * p) {  
  if (p == NULL) return ;  
  guarantee (p->AssociatedWith != NULL, "invariant") ;  
  guarantee (p->FreeNext == NULL      , "invariant") ;  
  p->AssociatedWith = NULL ;  
  for (;;) {  
    // Push p onto FreeList  
    Parker * List = FreeList ;  
    p->FreeNext = List ;  
    if (Atomic::cmpxchg_ptr (p, &FreeList, List) == List) break ;  
  }  
}




相关文章
|
13天前
|
Java 调度
Java并发编程:深入理解线程池的原理与实践
【4月更文挑战第6天】本文将深入探讨Java并发编程中的重要概念——线程池。我们将从线程池的基本原理入手,逐步解析其工作过程,以及如何在实际开发中合理使用线程池以提高程序性能。同时,我们还将关注线程池的一些高级特性,如自定义线程工厂、拒绝策略等,以帮助读者更好地掌握线程池的使用技巧。
|
8天前
|
Java 调度
Java中常见锁的分类及概念分析
Java中常见锁的分类及概念分析
14 0
|
8天前
|
Java
Java中ReentrantLock中tryLock()方法加锁分析
Java中ReentrantLock中tryLock()方法加锁分析
10 0
|
20天前
|
缓存 Java C#
【JVM故障问题排查心得】「Java技术体系方向」Java虚拟机内存优化之虚拟机参数调优原理介绍(一)
【JVM故障问题排查心得】「Java技术体系方向」Java虚拟机内存优化之虚拟机参数调优原理介绍
60 0
|
8天前
|
运维 NoSQL 算法
Java开发-深入理解Redis Cluster的工作原理
综上所述,Redis Cluster通过数据分片、节点发现、主从复制、数据迁移、故障检测和客户端路由等机制,实现了一个分布式的、高可用的Redis解决方案。它允许数据分布在多个节点上,提供了自动故障转移和读写分离的功能,适用于需要大规模、高性能、高可用性的应用场景。
15 0
|
8天前
|
Java
Java中关于ConditionObject的分析
Java中关于ConditionObject的分析
17 3
|
12天前
|
设计模式 缓存 安全
分析设计模式对Java应用性能的影响,并提供优化策略
【4月更文挑战第7天】本文分析了7种常见设计模式对Java应用性能的影响及优化策略:单例模式可采用双重检查锁定、枚举实现或对象池优化;工厂方法和抽象工厂模式可通过对象池和缓存减少对象创建开销;建造者模式应减少构建步骤,简化复杂对象;原型模式优化克隆方法或使用序列化提高复制效率;适配器模式尽量减少使用,或合并多个适配器;观察者模式限制观察者数量并使用异步通知。设计模式需根据应用场景谨慎选用,兼顾代码质量和性能。
|
16天前
|
Java 开发者
软件工程设计原理接口隔离原则 ,具体实现及JAVA代码举例
【4月更文挑战第7天】接口隔离原则(Interface Segregation Principle, ISP)是面向对象设计原则之一,旨在减少不必要的依赖关系,通过拆分庞大且臃肿的接口为更小、更具体的接口来实现。这个原则强调“客户端不应该被迫依赖于它不使用的接口”,意味着一个类不应该被迫实现它不使用的方法。
16 1
|
16天前
|
Java
软件工程设计原理依赖倒置原则 ,具体实现及JAVA代码举例
【4月更文挑战第5天】在软件工程中,依赖倒置原则(Dependency Inversion Principle, DIP)是一项重要的设计原则,它是SOLID原则中的一个组成部分。这个原则主张高层模块不应该依赖于低层模块,而是应该依赖于抽象;抽象不应该依赖于细节,细节应该依赖于抽象。这种设计方法有助于降低代码间的耦合度,增强系统的灵活性和可维护性
20 0
|
16天前
|
Java 关系型数据库
软件工程设计原理开放封闭原则 ,具体实现及JAVA代码举例
【4月更文挑战第4天】开放封闭原则(Open/Closed Principle, OCP)是面向对象设计的核心原则之一,它指出软件实体(类、模块、函数等)应该对扩展开放,对修改封闭。这意味着在不修改已有代码的前提下,可以通过扩展来增加新的功能,从而提高软件系统的灵活性和可维护性
17 1