java wait源码_从源码角度分析java 的 sleep()和wait()究竟有什么区别？

àì夳堔傛蜴生んèń 2022-11-10 10:47 91阅读 0赞

如果不能从根本上理解sleep() 和wait() 之间的区别，再好的解释也会只是当时记得，而后就忘记。本文刨根问题，从源码角度去理解这两个函数的区别。

1. sleep() 的根本实现

jvm sleep()---->jni sleep()-------->  经过层层调用，最终会进入系统的sys\_pasue()调用，而sys\_pause() 则会调用 schedule(), schedule() 则会主动放弃cpu 时间片，进入等待队列

asmlinkage int sys\_pause(void)

current->state = TASK\_INTERRUPTIBLE;

schedule();

return -ERESTARTNOHAND;

2. wait() 的根本实现

先查看jdk\\src\\share\\native\\java\\lang\\Object.c

\#include

\#include "jni.h"

\#include "jni\_util.h"

\#include "jvm.h"

\#include "java\_lang\_Object.h"

static JNINativeMethod methods\[\] = \{

\{"hashCode", "()I", (void \*)&JVM\_IHashCode\},

\{"wait", "(J)V", (void \*)&JVM\_MonitorWait\},

\{"notify", "()V", (void \*)&JVM\_MonitorNotify\},

\{"notifyAll", "()V", (void \*)&JVM\_MonitorNotifyAll\},

\{"clone", "()Ljava/lang/Object;", (void \*)&JVM\_Clone\},

\};

可以看到wait 对应的是 native  方法是JVM\_MonitorWait， 继续查看JVM\_MonitorWait的实现

JVM\_ENTRY(void, JVM\_MonitorWait(JNIEnv\* env, jobject handle, jlong ms))

JVMWrapper("JVM\_MonitorWait");

Handle obj(THREAD, JNIHandles::resolve\_non\_null(handle)); //调用 JNIHandles::resolve\_non\_null 函数将 jobject 类型的 handle 转化为 oop

assert(obj->is\_instance() || obj->is\_array(), "JVM\_MonitorWait must apply to an object");

JavaThreadInObjectWaitState jtiows(thread, ms != 0);

if (JvmtiExport::should\_post\_monitor\_wait()) \{

JvmtiExport::post\_monitor\_wait((JavaThread \*)THREAD, (oop)obj(), ms);

ObjectSynchronizer::wait(obj, ms, CHECK); //重点分析这句

JVM\_END

接着分析ObjectSynchronizer::wait()方法

void ObjectSynchronizer::wait(Handle obj, jlong millis, TRAPS) \{

if (UseBiasedLocking) \{

BiasedLocking::revoke\_and\_rebias(obj, false, THREAD);

assert(!obj->mark()->has\_bias\_pattern(), "biases should be revoked by now");

if (millis < 0) \{

TEVENT (wait - throw IAX) ;

THROW\_MSG(vmSymbols::java\_lang\_IllegalArgumentException(), "timeout value is negative");

ObjectMonitor\* monitor = ObjectSynchronizer::inflate(THREAD, obj());

DTRACE\_MONITOR\_WAIT\_PROBE(monitor, obj(), THREAD, millis);

monitor->wait(millis, true, THREAD);

/\* This dummy call is in place to get around dtrace bug 6254741. Once

that's fixed we can uncomment the following line and remove the call \*/

// DTRACE\_MONITOR\_PROBE(waited, monitor, obj(), THREAD);

dtrace\_waited\_probe(monitor, obj, THREAD);

将调用ObjectMonitor 的wait 方法

void ObjectMonitor::wait(jlong millis, bool interruptible, TRAPS) \{

......

// create a node to be put into the queue

// Critically, after we reset() the event but prior to park(), we must check

// for a pending interrupt.

ObjectWaiter node(Self);

node.TState = ObjectWaiter::TS\_WAIT ;

Self->\_ParkEvent->reset() ;

OrderAccess::fence(); // ST into Event; membar ; LD interrupted-flag

// Enter the waiting queue, which is a circular doubly linked list in this case

// but it could be a priority queue or any data structure.

// \_WaitSetLock protects the wait queue. Normally the wait queue is accessed only

// by the the owner of the monitor \*except\* in the case where park()

// returns because of a timeout of interrupt. Contention is exceptionally rare

// so we use a simple spin-lock instead of a heavier-weight blocking lock.

Thread::SpinAcquire (&\_WaitSetLock, "WaitSet - add") ;

AddWaiter (&node) ;

Thread::SpinRelease (&\_WaitSetLock) ;

....

int ret = OS\_OK ;

int WasNotified = 0 ;

\{ // State transition wrappers

OSThread\* osthread = Self->osthread();

OSThreadWaitState osts(osthread, true);

ThreadBlockInVM tbivm(jt);

// Thread is in thread\_blocked state and oop access is unsafe.

jt->set\_suspend\_equivalent();

if (interruptible && (Thread::is\_interrupted(THREAD, false) || HAS\_PENDING\_EXCEPTION)) \{

// Intentionally empty

\} else

if (node.\_notified == 0) \{

if (millis <= 0) \{

Self->\_ParkEvent->park () ;

\} else \{

ret = Self->\_ParkEvent->park (millis) ;

// were we externally suspended while we were waiting?

if (ExitSuspendEquivalent (jt)) \{

// TODO-FIXME: add -- if succ == Self then succ = null.

jt->java\_suspend\_self();

\} // Exit thread safepoint: transition \_thread\_blocked -> \_thread\_in\_vm

....

这段函数相当的长，为了从宏观上理解流程，我们删去了很多中间部分，重点在  ObjectWaiter node(Self);   Self 是Thread 对象，将Thread 和 ObjectWaiter 关联起来，

ObjectMonitor::AddWaiter() 将 node加入到  ObjectWaiter 的\_WaitSet 中

Self->\_ParkEvent->park () ;

将会调用

void os::PlatformEvent::park() \{ // AKA "down()"

// Invariant: Only the thread associated with the Event/PlatformEvent

// may call park().

// TODO: assert that \_Assoc != NULL or \_Assoc == Self

int v ;

for (;;) \{

v = \_Event ;

if (Atomic::cmpxchg (v-1, &\_Event, v) == v) break ;

guarantee (v >= 0, "invariant") ;

if (v == 0) \{

// Do this the hard way by blocking ...

int status = pthread\_mutex\_lock(\_mutex);

assert\_status(status == 0, status, "mutex\_lock");

guarantee (\_nParked == 0, "invariant") ;

\++ \_nParked ;

while (\_Event < 0) \{

status = pthread\_cond\_wait(\_cond, \_mutex);

// for some reason, under 2.7 lwp\_cond\_wait() may return ETIME ...

// Treat this the same as if the wait was interrupted

if (status == ETIME) \{ status = EINTR; \}

assert\_status(status == 0 || status == EINTR, status, "cond\_wait");

\-- \_nParked ;

// In theory we could move the ST of 0 into \_Event past the unlock(),

// but then we'd need a MEMBAR after the ST.

\_Event = 0 ;

status = pthread\_mutex\_unlock(\_mutex);

assert\_status(status == 0, status, "mutex\_unlock");

guarantee (\_Event >= 0, "invariant") ;

\}从代码中可以看出线程将进入等待中

本质结论：

1.sleep() 只是主动调用schedule() ，放弃CPU时间片

2.wait() 线程并没有主动放弃CPU, 在linux 下 调用 pthread\_cond\_wait() 等待条件满足再次进入Runnning 状态

本文从宏观上分析了sleep() 和wait()的 区别，中间还有很多的细节，值得去学习，后续将继续深化。

java wait源码_从源码角度分析java 的 sleep()和wait()究竟有什么区别？

发表评论取消回复

还没有评论，来说两句吧...

相关阅读

相关 JAVA wait和sleep 的区别

相关 sleep()和wait()的区别是什么？

相关 sleep()和wait() 有什么区别？

相关 kubectl源码分析之wait

相关 java wait源码_从源码角度分析java 的 sleep()和wait()究竟有什么区别？

相关 java sleep和wait区别_java中的sleep()与wait()区别

相关 JAVA—sleep（）和wait（）的区别

相关 as_completed和wait源码分析

相关 sleep和wait到底什么区别

相关 Java的wait()、notify()：JVM源码分析