Threads - Pointing out the correct statements Questions and Answers

Answer: C

The JVM synchronises class initialisation, so however many threads race to use a class first, its static initialiser runs exactly once and its effects are visible to all of them. This is what makes the holder idiom a correct lazy singleton without any explicit locking.

Answer: D

shutdown() is the orderly form: no new tasks are accepted and the queue is drained normally. shutdownNow() also interrupts running tasks and returns the tasks still queued. Neither blocks; waiting for termination is awaitTermination's job.

Answer: A

get() waits for completion and then delivers the outcome, wrapping a task failure in ExecutionException so the caller sees it on their own thread. That is the mechanism by which a value or an error crosses from the worker back to the submitter, which a bare Runnable cannot do.

Answer: B

It is built for concurrency rather than wrapped for it: reads generally proceed without locking and writes contend only over part of the table, so throughput holds up under many threads. A Collections.synchronizedMap, by contrast, funnels every call through one lock.

Answer: C

The iterator holds the array as it was when iteration began, so concurrent modifications are invisible to it and cannot invalidate it. The cost is on the write side, which copies the whole array, making the class suitable for read-mostly data such as listener lists.

Answer: D

Unlike synchronized, whose monitor is released whichever way the block exits, an explicit lock is released only when you call unlock. Skipping the finally means one thrown exception leaves the lock held for ever. What you gain for that care is tryLock, timed waits and interruptible acquisition.

Answer: A

tryLock reports whether it succeeded and never waits, which lets a thread back off, do other work or release the locks it already holds rather than sit in a possible deadlock. A monitor has no equivalent: entering a synchronized block either succeeds or blocks.

Answer: B

A Condition belongs to a Lock and plays the same role wait and notify play for a monitor: the lock must be held, await releases it while waiting and reacquires it before returning. The advantage is that one lock can carry several conditions, so waiters for different states can be signalled separately.

Answer: C

Unless a task is submitted to a pool of your own, parallel streams draw on the common ForkJoinPool, which is shared process-wide. A long or blocking operation inside one therefore delays unrelated parallel work, which is why blocking calls do not belong in a parallel stream.

Answer: D

With several threads waiting on one monitor for different conditions, notify may wake one whose condition still does not hold; it returns to waiting and the thread that could have proceeded is never signalled. notifyAll wakes them all to re-test, at some cost in contention. It only ever affects waiters on that same object.