Which of the following will NOT directly cause the calling thread to stop executing at that moment?

Difficulty: Easy

Correct Answer: notify()

Explanation:

Introduction / Context:Blocking versus non-blocking operations are central to thread behavior. Some APIs suspend the caller; others signal different threads and let the caller continue.

Given Data / Assumptions:

  • We focus on the immediate effect on the current (calling) thread.
  • Assume correct monitor ownership for monitor methods.

Concept / Approach:wait() and sleep() suspend the current thread. Blocking I/O (such as InputStream.read()) can also suspend the caller until data becomes available. In contrast, notify() (and notifyAll()) wake other waiting threads but do not block or stop the caller.

Step-by-Step Reasoning:

notify(): caller continues → does not directly stop.wait(): caller releases monitor and blocks → stops.sleep(): caller sleeps → stops.InputStream access: may block → stops until data arrives.

Verification / Alternative check:Javadoc for Object and Thread confirms which calls are blocking or signaling.

Why Other Options Are Wrong:They are either blocking calls by design or can block in common scenarios (I/O).

Common Pitfalls:Assuming notify() transfers the lock or blocks the caller; it simply wakes others.

Final Answer:notify()

More Questions from Threads

Discussion & Comments

No comments yet. Be the first to comment!
Join Discussion