Threads - Pointing out the correct statements Questions and Answers

Answer: A

run() is an ordinary method. Invoking it yourself just runs its body on the current thread, so the work happens sequentially and no concurrency is gained. Only start() asks the JVM for a new thread, after which two threads run concurrently: the caller returns from start() while the new one executes run().

Answer: B

The javadoc is explicit that it is never legal to start a thread more than once, and that a thread may not be restarted once it has completed execution. The second call throws IllegalThreadStateException. Re-running work needs a fresh Thread object, or an executor that manages reuse for you.

Answer: C

start() returns as soon as the new thread has been created and scheduled; the result is two threads running concurrently, the caller and the new one. Nothing about it waits for run() to finish. Waiting for completion is what join() is for.

Answer: D

Thread.sleep is static, so it always affects the thread that calls it; writing t.sleep(100) still puts the current thread to sleep, not t. The javadoc states the thread does not lose ownership of any monitors, so a lock held across a sleep stays held and other threads waiting on it make no progress.

Answer: A

Because sleep does not give up ownership of any monitor, a sleeping thread that holds a lock keeps it. Any thread that needs the same lock stays blocked until the sleeper wakes and leaves the synchronized region. This is the difference from wait(), which does release the monitor it is called on.

Answer: B

All of wait, notify and notifyAll should only be called by a thread that owns the object's monitor, and calling one without that ownership throws IllegalMonitorStateException. In practice that means the call sits inside a synchronized block or method on the same object. The requirement applies equally to notify.

Answer: C

The javadoc is precise here: wait places the thread in the wait set for this object and unlocks only this object. Any other object the thread is synchronized on stays locked while it waits, which is one of the standard routes into deadlock when a thread waits while holding a second lock.

Answer: D

The javadoc says one of the waiting threads is chosen to be awakened and that the choice is arbitrary, at the discretion of the implementation. Neither waiting time nor priority is promised. Code that needs every waiter to re-check its condition must call notifyAll.

Answer: A

notify does not hand over the lock. The woken thread is removed from the wait set and re-enabled for scheduling, then competes in the usual way for the monitor, so it cannot proceed until the notifier has left the synchronized region. Only once it regains the monitor does wait() return.

Answer: B

The javadoc states a thread can wake without being notified, interrupted or timing out, and that applications must guard against it by testing the condition and continuing to wait if it does not hold. The documented idiom is while (condition does not hold) obj.wait(); - a while, not an if.