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




相关文章
|
1月前
|
监控 Java 应用服务中间件
高级java面试---spring.factories文件的解析源码API机制
【11月更文挑战第20天】Spring Boot是一个用于快速构建基于Spring框架的应用程序的开源框架。它通过自动配置、起步依赖和内嵌服务器等特性,极大地简化了Spring应用的开发和部署过程。本文将深入探讨Spring Boot的背景历史、业务场景、功能点以及底层原理,并通过Java代码手写模拟Spring Boot的启动过程,特别是spring.factories文件的解析源码API机制。
71 2
|
15天前
|
Java 程序员
深入理解Java异常处理机制
Java的异常处理是编程中的一块基石,它不仅保障了代码的健壮性,还提升了程序的可读性和可维护性。本文将深入浅出地探讨Java异常处理的核心概念、分类、处理策略以及最佳实践,旨在帮助读者建立正确的异常处理观念,提升编程效率和质量。
|
16天前
|
Java 开发者 UED
深入探索Java中的异常处理机制##
本文将带你深入了解Java语言中的异常处理机制,包括异常的分类、异常的捕获与处理、自定义异常的创建以及最佳实践。通过具体实例和代码演示,帮助你更好地理解和运用Java中的异常处理,提高程序的健壮性和可维护性。 ##
41 2
|
16天前
|
Java 开发者
Java中的异常处理机制深度剖析####
本文深入探讨了Java语言中异常处理的重要性、核心机制及其在实际编程中的应用策略,旨在帮助开发者更有效地编写健壮的代码。通过实例分析,揭示了try-catch-finally结构的最佳实践,以及如何利用自定义异常提升程序的可读性和维护性。此外,还简要介绍了Java 7引入的多异常捕获特性,为读者提供了一个全面而实用的异常处理指南。 ####
39 2
|
20天前
|
监控 算法 Java
jvm-48-java 变更导致压测应用性能下降,如何分析定位原因?
【11月更文挑战第17天】当JVM相关变更导致压测应用性能下降时,可通过检查变更内容(如JVM参数、Java版本、代码变更)、收集性能监控数据(使用JVM监控工具、应用性能监控工具、系统资源监控)、分析垃圾回收情况(GC日志分析、内存泄漏检查)、分析线程和锁(线程状态分析、锁竞争分析)及分析代码执行路径(使用代码性能分析工具、代码审查)等步骤来定位和解决问题。
|
19天前
|
Java 程序员 UED
深入理解Java中的异常处理机制
本文旨在揭示Java异常处理的奥秘,从基础概念到高级应用,逐步引导读者掌握如何优雅地管理程序中的错误。我们将探讨异常类型、捕获流程,以及如何在代码中有效利用try-catch语句。通过实例分析,我们将展示异常处理在提升代码质量方面的关键作用。
31 3
|
19天前
|
Java 数据库连接 开发者
Java中的异常处理机制:深入解析与最佳实践####
本文旨在为Java开发者提供一份关于异常处理机制的全面指南,从基础概念到高级技巧,涵盖try-catch结构、自定义异常、异常链分析以及最佳实践策略。不同于传统的摘要概述,本文将以一个实际项目案例为线索,逐步揭示如何高效地管理运行时错误,提升代码的健壮性和可维护性。通过对比常见误区与优化方案,读者将获得编写更加健壮Java应用程序的实用知识。 --- ####
|
20天前
|
运维 Java 编译器
Java 异常处理:机制、策略与最佳实践
Java异常处理是确保程序稳定运行的关键。本文介绍Java异常处理的机制,包括异常类层次结构、try-catch-finally语句的使用,并探讨常见策略及最佳实践,帮助开发者有效管理错误和异常情况。
65 4
|
19天前
|
开发框架 安全 Java
Java 反射机制:动态编程的强大利器
Java反射机制允许程序在运行时检查类、接口、字段和方法的信息,并能操作对象。它提供了一种动态编程的方式,使得代码更加灵活,能够适应未知的或变化的需求,是开发框架和库的重要工具。
35 2
|
23天前
|
Java
深入探讨Java中的中断机制:INTERRUPTED和ISINTERRUPTED方法详解
在Java多线程编程中,中断机制是协调线程行为的重要手段。了解和正确使用中断机制对于编写高效、可靠的并发程序至关重要。本文将深入探讨Java中的`Thread.interrupted()`和`Thread.isInterrupted()`方法的区别及其应用场景。
24 4