Java Developer interview questions

A thread is an execution path inside a process and shares that process's heap and resources with other threads.

• Each process has an isolated address space, while threads in one JVM can access the same objects.
• Every thread has its own stack, program counter, and call frames despite sharing the heap.
• Shared memory makes communication cheap but requires synchronization when mutable state is accessed concurrently.

start() asks the JVM to create a new execution path, while run() is an ordinary method call on the current thread.

• start() eventually invokes run() on the new thread after the scheduler makes it runnable.
• Calling run() directly provides no concurrency and blocks the caller until the method returns.
• A Thread instance can be started only once, and a second start() throws IllegalThreadStateException.

Thread.State describes where a thread is in its lifecycle rather than whether it is currently using a CPU core.

• A new thread moves from NEW to RUNNABLE after start(), and reaches TERMINATED when run() completes or fails.
• Entering a contended synchronized block produces BLOCKED, while Object.wait() or an unbounded join() produces WAITING.
• sleep(), a timed wait(), and a timed join() produce TIMED_WAITING until time expires or another wake-up condition occurs.

A race condition occurs when a result depends on an uncontrolled interleaving of concurrent operations.

• count++ is a read-modify-write sequence, not one indivisible operation.
• Two threads can read the same old value, calculate the same increment, and overwrite one result.
• Protect the operation with a common lock or use an atomic counter designed for concurrent updates.

synchronized provides mutual exclusion and memory visibility for code guarded by the same monitor.

• Only one thread at a time can execute a critical section protected by a particular monitor.
• Releasing the monitor flushes prior writes, and a later acquisition of that monitor makes those writes visible.
• Java monitors are reentrant, so a thread holding a monitor can enter another block guarded by it without deadlocking itself.

The monitor depends on the object named implicitly or explicitly by the synchronization form.

• An instance synchronized method locks this, so calls on different instances do not exclude each other.
• A static synchronized method locks the Class object, which is shared by all instances loaded by that class loader.
• A synchronized block locks its expression, allowing a private dedicated lock and a smaller critical section.

wait and notification coordinate through an object's monitor, while sleep only pauses the current thread.

• wait() must be called while holding that monitor and releases it until the thread is awakened and reacquires it.
• notify() wakes one arbitrary waiter and notifyAll() wakes all waiters, which must then compete for the monitor.
• sleep() neither requires nor releases a monitor, so sleeping inside synchronized can block other threads unnecessarily.
• A wait condition belongs in a while loop because wake-ups can be spurious or the condition can change before reacquisition.

volatile gives visibility and ordering guarantees for reads and writes of one variable, but it does not make compound actions atomic.

• A write to a volatile variable happens-before every subsequent read of that same variable.
• The JVM and CPU cannot reorder relevant memory operations across the volatile access in ways that break this guarantee.
• It is suitable for state flags or safely publishing an immutable value when updates do not depend on the old value.

volatile makes each read and write visible, but the increment still consists of multiple operations that can interleave.

• Each thread can observe the latest counter and still lose an update between its read and write.
• AtomicInteger.incrementAndGet() performs the update atomically, usually with compare-and-set.
• synchronized or Lock is preferable when the invariant spans several variables or several operations.

Happens-before is the rule that makes one action's effects guaranteed to be visible to another action.

• Program order establishes it between earlier and later actions within one thread.
• A monitor unlock happens-before a later lock of that monitor, and a volatile write happens-before a later read of that variable.
• Thread.start() publishes prior actions to the started thread, while a successful join() publishes the finished thread's actions to the joiner.
• Without a happens-before path, observing another thread's writes is not guaranteed even if tests usually appear to work.

Safe publication makes a fully constructed object's state reliably visible to every thread that obtains its reference.

• Publication through a volatile field, a synchronized handoff, a static initializer, or a concurrent collection creates the required ordering.
• Properly constructed final fields receive special visibility guarantees, but this does not make mutable referenced objects immutable.
• Leaking this from a constructor can expose default or partially initialized state before construction finishes.

The compiler, JVM, and processor may reorder operations for performance as long as single-thread behavior remains valid.

• Another thread can observe writes in an unexpected order when the threads have a data race.
• synchronized, volatile, thread lifecycle rules, and concurrent utilities introduce ordering constraints recognized by the memory model.
• Timing assumptions or adding sleep() do not establish visibility and cannot replace a happens-before relationship.

Deadlock requires exclusive resources, hold-and-wait, no forced preemption, and a cycle of dependencies.

• Code that acquires multiple locks in inconsistent order can create the circular wait.
• A global lock order or a single lock around one invariant removes that cycle.
• tryLock with a timeout can let code abandon and retry acquisition, but the failure path must release every acquired lock.

Starvation denies one thread progress, while livelock keeps threads active but prevents useful progress.

• Starvation can arise when a thread repeatedly loses access to a non-fair lock or executor capacity.
• In livelock, threads respond to each other by repeatedly yielding or retrying in a synchronized pattern.
• Deadlocked threads are blocked in a dependency cycle, whereas starving or livelocked threads may still change state.

Lock is useful when code needs acquisition behavior that the synchronized statement does not expose.

• tryLock supports immediate or timed failure, and lockInterruptibly allows cancellation while waiting.
• A Lock can provide multiple Condition queues, whereas an object's monitor has one wait set.
• synchronized is usually simpler for lexical critical sections because monitor release is automatic even when an exception occurs.
• A Lock must always be released in a finally block after successful acquisition.

ReentrantLock is an explicit reentrant mutex with interruptible, timed, and observable acquisition operations.

• Reentrancy tracks a hold count, so the owner must unlock as many times as it successfully locked.
• A fair lock generally grants access to the longest-waiting thread under contention.
• Fairness can reduce starvation but often lowers throughput, and untimed tryLock may still bypass the fairness queue.

ReadWriteLock can improve concurrency when reads are frequent, writes are rare, and protected work is substantial.

• Multiple readers may hold the read lock together, but the write lock requires exclusive access.
• Lock management and contention overhead can make a plain mutex faster for short sections or frequent writes.
• ReentrantReadWriteLock does not support a straightforward read-to-write upgrade, which can deadlock if attempted while retaining the read lock.

Atomic classes update a value by comparing its current state with an expected state and conditionally replacing it.

• A failed compare-and-set indicates interference, so lock-free algorithms usually reread the value and retry.
• The operation is atomic and has volatile-style visibility semantics without taking a Java monitor.
• ABA occurs when a value changes from A to B and back to A, so a comparison sees A but misses the intervening change.
• AtomicStampedReference or AtomicMarkableReference can attach version information when that history matters.

AtomicLong maintains one immediately readable atomic value, while LongAdder spreads contended updates across internal cells.

• AtomicLong is appropriate when updates need compare-and-set semantics or every read must be a single linearizable value.
• LongAdder usually scales better for heavily updated metrics because threads contend on different cells.
• LongAdder.sum() combines cells and is not an atomic snapshot relative to concurrent updates, so it is unsuitable for coordination logic.

ExecutorService separates task submission from thread creation, reuse, scheduling, and shutdown policy.

• Reusing a bounded set of workers avoids the memory and context-switch cost of one thread per task.
• The executor can queue work, reject overload, return Future results, and expose lifecycle operations.
• The application still has to choose queue capacity, pool size, thread factory, and rejection behavior for its workload.