Java Threads Interview Questions: Concurrency Practice Quiz

Calling start() on a Thread instance causes the JVM to create a new OS-level thread and invoke run() within that new thread. Calling run() directly simply executes the method body on the current thread, exactly like any ordinary method call — no new thread is created. Therefore the statement that calling start() on a Thread object creates a new OS-level thread and automatically invokes run() in that thread is correct and the others are wrong.

Thread.start() allocates and schedules a new thread of execution and, once that thread is running, the JVM invokes the thread's run() method on it. Calling run() directly is an ordinary method call, so it executes on the caller's thread and no new thread is created. The answer is therefore the start() method.

Thread.run() is a plain instance method. Invoking it directly runs its body on the caller's current thread, just like any other method call, so no new thread is created. Only Thread.start() requests the JVM to create and schedule a new thread, which then calls run() asynchronously. Therefore the statement is false.

Calling start() allocates a new native thread and schedules it; the JVM then invokes run() on that new thread. Calling run() directly simply executes the method body on the caller's thread, so no concurrency happens. The question asks for the method name, so an open short answer of start (or start()) is the correct response.

A Java Thread object is in the NEW state from the moment it is constructed until start() is invoked, at which point it transitions to RUNNABLE. The Thread.State enum has six values: NEW, RUNNABLE, BLOCKED, WAITING, TIMED_WAITING, and TERMINATED.

Thread.start() is the method that actually requests the JVM to allocate a new OS-level thread; the JVM then calls run() on that new thread. If you invoke run() yourself, it is just an ordinary method call on the current thread — no new thread is created, and the code runs inline just like any other method. This is a common beginner mistake that results in code appearing to be multi-threaded when it is actually single-threaded.

A Java Thread object maps to one underlying OS thread and can move from NEW to RUNNABLE only once. The JVM enforces this by having start() throw IllegalThreadStateException whenever the thread's internal state is not NEW, and that includes the case where the thread has already finished executing. Calling run() directly would not create a thread at all, and a second start() does not silently restart the thread or throw InterruptedException.

volatile provides visibility: every read sees the latest write, and a write establishes a happens-before relationship with subsequent reads. It does not make compound operations atomic. count++ involves a read, an add, and a write, which are three separate steps, so two threads can interleave and lose updates even on a volatile field. Atomicity for such operations requires synchronized blocks or an AtomicInteger.

Line 2 declares instance without the volatile keyword. The statement instance = new LazyCache() is not atomic: it allocates memory, runs the constructor, and assigns the reference. Without volatile, the JIT compiler and CPU may reorder these steps so that the reference is published before construction completes. A thread that bypasses the synchronized block via the first null check can then read a non-null instance pointing to a partially constructed object. Marking the field volatile establishes a happens-before relationship that prohibits this reordering, making the double-checked locking idiom safe. The other lines implement the standard pattern correctly once the field is volatile.

Without a happens-before relationship between the write to data and the read of data, the JMM allows the compiler or processor to reorder the two writes in writer(), so the reader can observe ready == true while still seeing the default 0 for data. The statement that the reader can return 17 is false: no thread ever writes 17, the JMM forbids out-of-thin-air values, and 32-bit int writes are atomic, so a read only returns a value some thread actually wrote (or the default). The statement that the reader is guaranteed to return 42 once it sees ready == true is false for the same reason as the reordering case: the absence of synchronization means no happens-before edge exists to guarantee visibility of data = 42. Declaring ready as volatile would create that edge.

The JMM defines specific happens-before edges: (1) a volatile write happens-before every subsequent volatile read of the same field; (2) a monitor unlock happens-before every subsequent lock on the same monitor; (3) a call to Thread.start() happens-before every action in the started thread. Two threads both reading the same volatile field—even if one read occurs temporally before the other—does not create a happens-before edge, because the volatile guarantee links a write to a subsequent read, never a read to another read. Without an intervening volatile write (or other synchronization action) between the two reads, there is no ordering guarantee.

The wait() calls on lines 13 and 23 release the monitor and park the thread until notified, but a waiting thread can return from wait() without any notification (spurious wakeup, which Object.wait's documentation explicitly allows). Also, notifyAll() wakes every waiter, and only one can hold the monitor at a time, so by the time a later waiter runs, the condition it was waiting for may already be false again. Because the guards on lines 12 and 22 are if statements, the thread proceeds immediately after wait() returns without re-checking the condition, so a producer can write into a full buffer or a consumer can read from an empty one. Changing both if statements to while loops makes each thread re-test its condition after every wakeup and wait again if it still does not hold, which is the standard guarded-wait pattern. The fix is therefore to change lines 12 and 22 and nothing else in this listing.

The guaranteed value is 1. Three happens-before edges chain together: program order in Thread A orders the write x = 1 before the volatile write ready = true; the volatile rule orders that volatile write before the volatile read at (3) because the read observed true; and program order in Thread B orders the read at (3) before the read of x at (4). Transitivity of happens-before then guarantees the write to x is visible at (4). The common misconception that x could still be 0 because x is not volatile confuses field-level visibility with the broader guarantee that a volatile write publishes all of the writing thread's prior writes.

A release write (setRelease) and an acquire read (getAcquire) form a release-acquire pair: if the acquire read observes the value written by the release write, a happens-before edge is established from the release write to the acquire read. In t1, the plain write A.set(d, 1) is ordered before C.setRelease(d, 1) by program order, and the release mode prevents the plain write from being reordered after the release write. In t2, the acquire read C.getAcquire(d) is ordered before the plain read A.get(d) by program order, and the acquire mode prevents the plain read from being reordered before the acquire read. Therefore, if C.getAcquire returns 1, transitivity gives: A.set(d,1) → C.setRelease(d,1) → C.getAcquire(d) → A.get(d), so A.get is guaranteed to return 1 — the output 1,0 is impossible. If C.getAcquire returns 0, no happens-before edge is created between the threads, and the plain read A.get may observe either the default 0 or t1's plain write of 1, making 0,0 and 0,1 both legal. 1,1 is obviously legal when the acquire read sees the release write.

The guarantee follows from tracing a full happens-before chain defined by the Java Memory Model (JLS 17.4.5). In Thread A, the final count++ (which writes 10) is sequenced before the volatile write done = true by program order. A volatile write happens-before every later volatile read of the same field that observes its value, so when Thread B's check() reads done as true, that edge exists. Within check(), the volatile read of done is sequenced before the read of count. Transitivity gives: write of count = 10 (Thread A) happens-before volatile write of done (Thread A) happens-before volatile read of done (Thread B) happens-before read of count (Thread B). Therefore the printed value is guaranteed to be 10. The synchronized block in increment() does not create this guarantee for Thread B, since a monitor release only synchronizes with a later acquire of the same monitor and check() never acquires it. The volatile field is the only bridge between the threads.

The Java Memory Model builds a happens-before partial order from three rules. Within Thread A, program order gives a happens-before edge from the write x = 10 to the unlock of lock. The monitor-lock rule (JLS §17.4.5) states that every unlock of a monitor happens-before every subsequent lock of that same monitor, connecting Thread A's unlock to Thread B's lock. Within Thread B, program order gives an edge from the lock acquisition to the read of x. By transitivity of happens-before, the write in Thread A happens-before the read in Thread B, so the read is guaranteed to observe the value 10 and not a stale or default value.

CAS only tests whether the current value equals the expected value, so a location that goes A to B to A looks unchanged to a thread that read it earlier. The danger is strongest when the value is a pointer to a node that was freed and reallocated at the same address between the two observations. A versioned/tagged pointer addresses the comparison itself: the tag changes on every write, so a CAS that compares pointer and tag together detects the intervening mutations. A hazard pointer does not change the CAS comparison; instead it publishes which nodes threads are still reading, and reclamation defers reuse of those nodes, so the reallocated-at-same-address scenario cannot occur while a reader holds the reference.

Tracing the happens-before edges through the code: (1) Program order in Thread A gives W1 → W2. (2) Program order in Thread B gives R1 → R2. (3) The volatile rule gives W1 → R1, because W1 is the write to the volatile field ready and R1 is a subsequent read of ready that observes the value true. By transitivity, W1 → R1 → R2, so W1 happens-before R2. However, W2 (the write to value) appears AFTER W1 in Thread A's program order — the edge W1 → W2 points away from W2, not toward R2. There is no path in the happens-before graph from W2 to R2. Because the write to the non-volatile field value at W2 does not happen-before the read of value at R2, the JMM provides no guarantee that R2 will observe the value 42 written by W2. The only values ever written to value are the default 0 and 42 (at W2), so R2 may return either 0 or 42, with no guarantee as to which. This contrasts with the safe pattern where value = 42 precedes ready = true: then W1 (value=42) → W2 (ready=true) → R1 → R2, giving W1 → R2 and guaranteeing R2 sees 42.