Difficulty: Easy
Correct Answer: 4 and 6
Explanation:
Introduction / Context:The item asks you to evaluate several assertions about Java’s wait/notify mechanism and thread scheduling. Understanding which methods are overloaded, what contexts are required, and what guarantees exist is essential for correct concurrent code.
Given Data / Assumptions (statements):
Concept / Approach:Evaluate each statement against the Java Language Specification and java.lang.Object API.
Step-by-Step Solution:
1) False. Deadlock is still possible if locks are acquired in conflicting orders or notifications are missed due to logic errors.2) False. sleep sets the thread to TIMED_WAITING; after the time elapses it becomes RUNNABLE, but scheduling is not guaranteed immediately.3) False. Synchronization restricts concurrent access by multiple threads to shared state; it does not prevent a thread from accessing two objects.4) True. Object.wait has overloads: wait(long) and wait(long, int) besides wait().5) False. notify() and notifyAll() have no timed overloads.6) True. A thread must own the monitor to call wait/notify; otherwise IllegalMonitorStateException is thrown.Verification / Alternative check:Consult Object’s method signatures: wait(), wait(long), wait(long, int), notify(), notifyAll().
Why Other Options Are Wrong:
Common Pitfalls:Believing that sleep guarantees immediate resumption or that using wait/notify magically prevents deadlocks.
Final Answer:4 and 6
Discussion & Comments