【底层原理之旅—从底层分析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 ;  
  }  
}




目录
打赏
0
0
0
0
379
分享
相关文章
理解的Java中SPI机制
本文深入解析了JDK提供的Java SPI(Service Provider Interface)机制,这是一种基于接口编程、策略模式与配置文件组合实现的动态加载机制,核心在于解耦。文章通过具体示例介绍了SPI的使用方法,包括定义接口、创建配置文件及加载实现类的过程,并分析了其原理与优缺点。SPI适用于框架扩展或替换场景,如JDBC驱动加载、SLF4J日志实现等,但存在加载效率低和线程安全问题。
理解的Java中SPI机制
【原理】【Java并发】【synchronized】适合中学者体质的synchronized原理
本文深入解析了Java中`synchronized`关键字的底层原理,从代码块与方法修饰的区别到锁升级机制,内容详尽。通过`monitorenter`和`monitorexit`指令,阐述了`synchronized`实现原子性、有序性和可见性的原理。同时,详细分析了锁升级流程:无锁 → 偏向锁 → 轻量级锁 → 重量级锁,结合对象头`MarkWord`的变化,揭示JVM优化锁性能的策略。此外,还探讨了Monitor的内部结构及线程竞争锁的过程,并介绍了锁消除与锁粗化等优化手段。最后,结合实际案例,帮助读者全面理解`synchronized`在并发编程中的作用与细节。
50 8
【原理】【Java并发】【synchronized】适合中学者体质的synchronized原理
|
24天前
|
【原理】【Java并发】【volatile】适合初学者体质的volatile原理
欢迎来到我的技术博客!我是一名热爱编程的开发者,梦想是写出高端的CRUD应用。2025年,我正在沉淀自己,博客更新速度也在加快。在这里,我会分享关于Java并发编程的深入理解,尤其是volatile关键字的底层原理。 本文将带你深入了解Java内存模型(JMM),解释volatile如何通过内存屏障和缓存一致性协议确保可见性和有序性,同时探讨其局限性及优化方案。欢迎订阅专栏《在2B工作中寻求并发是否搞错了什么》,一起探索并发编程的奥秘! 关注我,点赞、收藏、评论,跟上更新节奏,让我们共同进步!
92 8
【原理】【Java并发】【volatile】适合初学者体质的volatile原理
JVM实战—1.Java代码的运行原理
本文介绍了Java代码的运行机制、JVM类加载机制、JVM内存区域及其作用、垃圾回收机制,并汇总了一些常见问题。
JVM实战—1.Java代码的运行原理
|
23天前
|
Java静态代码块深度剖析:机制、特性与最佳实践
在Java中,静态代码块(或称静态初始化块)是指类中定义的一个或多个`static { ... }`结构。其主要功能在于初始化类级别的数据,例如静态变量的初始化或执行仅需运行一次的初始化逻辑。
37 4
列表结构与树结构转换分析与工具类封装(java版)
本文介绍了将线性列表转换为树形结构的实现方法及工具类封装。核心思路是先获取所有根节点,将其余节点作为子节点,通过递归构建每个根节点的子节点。关键在于节点需包含 `id`、`parentId` 和 `children` 三个属性。文中提供了两种封装方式:一是基于基类 `BaseTree` 的通用工具类,二是使用函数式接口实现更灵活的方式。推荐使用后者,因其避免了继承限制,更具扩展性。代码示例中使用了 Jackson 库进行 JSON 格式化输出,便于结果展示。最后总结指出,理解原理是进一步优化和封装的基础。
【JAVA】封装多线程原理
Java 中的多线程封装旨在简化使用、提高安全性和增强可维护性。通过抽象和隐藏底层细节,提供简洁接口。常见封装方式包括基于 Runnable 和 Callable 接口的任务封装,以及线程池的封装。Runnable 适用于无返回值任务,Callable 支持有返回值任务。线程池(如 ExecutorService)则用于管理和复用线程,减少性能开销。示例代码展示了如何实现这些封装,使多线程编程更加高效和安全。
【JAVA】生成accessToken原理
在Java中,生成accessToken用于身份验证和授权,确保合法用户访问受保护资源。流程包括:1. 身份验证(如用户名密码、OAuth 2.0);2. 生成唯一且安全的令牌;3. 设置令牌有效期并存储;4. 客户端传递令牌,服务器验证其有效性。常见场景为OAuth 2.0协议,涉及客户端注册、用户授权、获取授权码和换取accessToken。示例代码展示了使用Apache HttpClient库模拟OAuth 2.0获取accessToken的过程。
|
1月前
|
【Java并发】【线程池】带你从0-1入门线程池
欢迎来到我的技术博客!我是一名热爱编程的开发者,梦想是编写高端CRUD应用。2025年我正在沉淀中,博客更新速度加快,期待与你一起成长。 线程池是一种复用线程资源的机制,通过预先创建一定数量的线程并管理其生命周期,避免频繁创建/销毁线程带来的性能开销。它解决了线程创建成本高、资源耗尽风险、响应速度慢和任务执行缺乏管理等问题。
172 60
【Java并发】【线程池】带你从0-1入门线程池
Java网络编程,多线程,IO流综合小项目一一ChatBoxes
**项目介绍**:本项目实现了一个基于TCP协议的C/S架构控制台聊天室,支持局域网内多客户端同时聊天。用户需注册并登录,用户名唯一,密码格式为字母开头加纯数字。登录后可实时聊天,服务端负责验证用户信息并转发消息。 **项目亮点**: - **C/S架构**:客户端与服务端通过TCP连接通信。 - **多线程**:采用多线程处理多个客户端的并发请求,确保实时交互。 - **IO流**:使用BufferedReader和BufferedWriter进行数据传输,确保高效稳定的通信。 - **线程安全**:通过同步代码块和锁机制保证共享数据的安全性。
72 23