Threads - Pointing out the correct statements Questions and Answers

Answer: C

They belong to Object, not Thread, which is why any object at all can serve as a monitor and a lock. All five overloads are declared final, so no subclass can change their behaviour. Locking is a property of every object in the language rather than something threads own.

Answer: D

For a thread blocked in wait, join or sleep, interrupt() clears the interrupt status and delivers InterruptedException. So by the time the catch block runs, isInterrupted() reports false. Code that wants to pass the interruption on has to restore it by calling Thread.currentThread().interrupt().

Answer: A

The static Thread.interrupted() tests and clears the status of the current thread, so two consecutive calls can return true then false. The instance method isInterrupted() reports another thread's status and explicitly leaves it unaffected. Confusing the two produces a flag that seems to vanish.

Answer: B

Interruption is a request, not a forced stop. On a thread that is simply running, interrupt() sets a flag and nothing else happens; the thread keeps going until it checks the flag or enters a blocking call that throws. That cooperative design is why the unsafe stop() was deprecated in its favour.

Answer: C

stop(), suspend(), resume() and destroy() are all deprecated. The javadoc recommends replacing them with code that sets a variable indicating the thread should stop, which the thread checks regularly before returning from run() in an orderly fashion. Ending a thread is always cooperative.

Answer: D

The javadoc explains that stopping a thread unlocks all of the monitors it had locked, so any object left in an inconsistent state by the half-finished work becomes visible to other threads, giving arbitrary behaviour. The damage is to shared data, not to the locks themselves.

Answer: A

A thread suspended while holding the lock on a critical resource keeps that lock, so nothing else can touch the resource until it is resumed. If the resuming thread needs the same lock first, the two deadlock. That is exactly the hazard the javadoc gives for deprecating it.

Answer: B

The javadoc calls yield a hint to the scheduler that the current thread is willing to give up its processor, and says the scheduler is free to ignore it. Nothing is promised about which thread runs next, or that any switch happens at all, so correctness must never depend on it.

Answer: C

Priority is a hint to the platform's scheduler and its effect varies between JVMs and operating systems; setPriority is also capped by the thread group's maximum. A program whose correctness depends on priority ordering works on one machine and fails on another.

Answer: D

The javadoc says the priority is set to the smaller of the requested value and the maximum permitted for the thread's thread group, so a request above that cap is quietly reduced rather than rejected. Values outside 1 to 10 are what cause IllegalArgumentException, and priority may be changed at any time.