Difficulty: Easy
Correct Answer: 1, 2, 6
Explanation:
Introduction / Context:Java’s concurrency model splits behavior between the foundational java.lang.Object class and the java.lang.Thread class. This question tests whether you can correctly identify which synchronization-related methods actually live on Object rather than Thread.
Given Data / Assumptions:
Concept / Approach:In Java, intrinsic locking (monitors) is tied to every object instance. Consequently, the coordination primitives that manipulate an object’s monitor are instance methods on Object: wait() (and its overloads), notify(), and notifyAll(). Thread-scheduling helpers such as sleep() and yield() are static methods on Thread. Interruption APIs (interrupt(), isInterrupted()) also belong to Thread. The token synchronized is a language keyword, not a method.
Step-by-Step Solution:
Identify Object methods: notify() → yes (Object instance method).Identify Object methods: notifyAll() → yes (Object instance method).Identify Object methods: wait(long msecs) → yes (Object instance method; there are also wait() and wait(long,int)).Eliminate isInterrupted() → Thread instance method.Eliminate synchronized() → not a method; it is a keyword.Eliminate interrupt() → Thread instance method.Eliminate sleep(long) → Thread static method.Eliminate yield() → Thread static method.Verification / Alternative check:Consulting the Object API confirms the presence of wait/notify/notifyAll. Thread API holds sleep, yield, interrupt, and isInterrupted.
Why Other Options Are Wrong:They point to Thread methods or a language keyword and are not declared on Object.
Common Pitfalls:Assuming all concurrency helpers live on Thread; in fact, monitor control is on Object.
Final Answer:1, 2, 6
Discussion & Comments