Threads - Pointing out the correct statements Questions and Answers

Q: Which object a synchronized block may lock - which of the following is true?

Every object has a monitor, so synchronized (lock) works with any reference. A private final lock object is often preferred to locking this, because outside code cannot accidentally acquire it and interfere with the class's own locking.

41.

Which one of the following statements about a thread re-entering a monitor it already holds is true?

A.A thread may re-enter a monitor it already holds.
B.A thread that re-enters a monitor it already holds deadlocks against itself.
C.A thread that re-enters a monitor it already holds throws IllegalMonitorStateException.
D.A thread may re-enter a monitor only if the second region is a synchronized block, not a method.

Answer: A

Monitors count entries by owner, so a synchronized method calling another synchronized method on the same object simply increments the count and releases the lock when the outermost region exits. Without reentrancy any such call, including a superclass call, would deadlock immediately.

Discuss in Forum

42.

Consider two threads in synchronized methods of different instances. Which statement is correct?

A.Two threads may run synchronized instance methods at once only if the class has no static state.
B.Two threads may run synchronized instance methods of the same class at once on different instances.
C.Two threads may never run synchronized instance methods of the same class at the same time.
D.Two threads may run synchronized instance methods at once only if the methods differ.

Answer: B

A synchronized instance method locks its own receiver, so two objects mean two independent monitors and no contention between them. Synchronization protects an object's state, not the class's code, which is why shared static state needs a lock on something shared.

Discuss in Forum

43.

Which object a synchronized block may lock - which of the following is true?

A.A synchronized block may only lock an object that implements Runnable.
B.A synchronized block may lock any object, but only one such object exists per class.
C.A synchronized block may lock any object, letting a class use a private lock rather than itself.
D.A synchronized block may only lock this, or the Class object in a static context.

Answer: C

Every object has a monitor, so synchronized (lock) works with any reference. A private final lock object is often preferred to locking this, because outside code cannot accidentally acquire it and interfere with the class's own locking.

Discuss in Forum

44.

Which of these statements about visibility of writes made before start() is correct?

A.The new thread sees no state written before start(); it must read shared fields under a lock.
B.The new thread sees earlier writes only if the fields concerned are declared volatile.
C.The new thread sees earlier writes only if the creating thread later calls join().
D.Everything a thread did before calling start() is visible to the new thread when it begins.

Answer: D

Starting a thread establishes a happens-before edge: actions in the starting thread before start() are ordered before everything the new thread does. So a field set during construction and then handed over by start() is safely visible without extra synchronization. The edge is one-way.

Discuss in Forum

45.

Which one of the following statements about visibility of a worker's writes after join() is true?

A.After t.join() returns, everything t did is visible to the thread that joined.
B.After t.join() returns, t's writes are visible only if the fields are volatile.
C.After t.join() returns, t's writes are visible only through a synchronized block.
D.join() only waits for termination and provides no visibility guarantee at all.

Answer: A

Termination of a thread happens-before another thread detecting that termination through join, so results computed by the worker can be read from a plain field once join has returned. That pairing with start() is what makes the simple fork-and-join pattern correct without locks.

Discuss in Forum

46.

Consider StringBuffer compared with StringBuilder. Which statement is correct?

A.Neither class is synchronized; both require external locking.
B.StringBuffer's methods are synchronized while StringBuilder's are not.
C.StringBuilder's methods are synchronized while StringBuffer's are not.
D.Both classes are synchronized; they differ only in their growth strategy.

Answer: B

StringBuffer is the older, synchronized class and StringBuilder is the unsynchronized replacement, which is why StringBuilder is faster and the right default for a local variable. Only genuinely shared mutable text needs StringBuffer, and even then a lock around a larger operation is usually clearer.

Discuss in Forum

47.

Which legacy collections synchronize their methods - which of the following is true?

A.All four classes are synchronized, since they are all part of the collections framework.
B.None of the four is synchronized; only the Collections.synchronized wrappers are.
C.Vector and Hashtable synchronize their methods, while ArrayList and HashMap do not.
D.ArrayList and HashMap synchronize their methods, while Vector and Hashtable do not.

Answer: C

Vector and Hashtable are the legacy synchronized collections; ArrayList and HashMap deliberately are not, leaving the caller to decide. Note that per-method synchronization does not make a sequence of calls atomic, so even a Vector needs external locking for check-then-act logic.

Discuss in Forum

48.

Which of these statements about iterating a synchronized collection is correct?

A.Iterating a synchronized collection is safe without a lock.
B.Iterating a synchronized collection is safe because its iterator holds the lock throughout.
C.Iterating a synchronized collection is safe only for a collection of immutable elements.
D.Iterating a synchronized collection still needs an external lock.

Answer: D

Synchronizing each method makes individual operations atomic, not the loop built from them. Another thread can modify the collection between two calls, giving ConcurrentModificationException or a missed element, so the whole traversal must hold the lock.

Discuss in Forum

49.

Which one of the following statements about Callable compared with Runnable is true?

A.A Callable can return a value and throw a checked exception; a Runnable can do neither.
B.A Runnable can return a value and throw a checked exception; a Callable can do neither.
C.Both can return a value, but only Runnable may throw a checked exception.
D.Both are identical apart from the name of their single method.

Answer: A

Runnable.run() returns void and declares no checked exception, so a task that produces a result or fails has nowhere to put either. Callable.call() returns a value and is declared to throw Exception, which is why an ExecutorService hands back a Future that can deliver a result or rethrow the failure.

Discuss in Forum

50.

Consider what a ThreadLocal holds for each thread. Which statement is correct?

A.ThreadLocal restricts a variable so that only the main thread may write to it.
B.ThreadLocal gives each thread its own independently set value for the same variable.
C.ThreadLocal gives every thread a shared value that is synchronized on access.
D.ThreadLocal makes a field visible to other threads without declaring it volatile.

Answer: B

A ThreadLocal holds one value per thread, so each thread reads and writes its own copy and no coordination is needed. It solves confinement rather than sharing, and it does leak if a value is left behind on a pooled thread that is reused for other work.

Discuss in Forum

Threads - Pointing out the correct statements Questions and Answers

Topics

Other Subjects

About Us

Threads - Pointing out the correct statements Questions and Answers

Topics

Other Subjects

About Us

Stay informed about all important Dates & Notifications