Java Programming - MCQ Practice Questions

Java 21 introduced Virtual Threads as a lightweight threading model under Project Loom, allowing millions of concurrent tasks. This is more efficient than platform threads for high-concurrency scenarios.

Java supports reentrant locks on synchronized blocks. The same thread can acquire the same lock multiple times. The lock is released only when the outermost synchronized block exits.

Callable interface returns a result via Future, and ExecutorService.invokeAll() waits for all submitted tasks to complete. This is the standard pattern for parallel task execution with result collection.

notify() randomly selects one waiting thread to wake up, while notifyAll() wakes all waiting threads. notifyAll() is generally safer to avoid missed notifications when multiple threads are waiting on the same condition.

CyclicBarrier is a synchronizer that allows a fixed number of threads to wait for each other at a barrier point. Once all threads reach the barrier, they proceed together. It's reusable (cyclic) unlike CountDownLatch.

When wait() is called, the thread releases the lock it holds on the object and enters the waiting pool. Another thread can then acquire the lock. The thread re-acquires the lock when notified.

ConcurrentHashMap uses segment-based locking (in older versions) or fine-grained locking to provide thread-safety without synchronizing the entire map. Other options require external synchronization or Collections.synchronizedMap().

This is a classic deadlock scenario involving circular wait. Race condition involves competing for resources. Starvation is when a thread never gets the resource. Livelock is when threads keep changing states without progress.

newSingleThreadExecutor() creates an executor with exactly one thread. Tasks are queued and executed sequentially in the order submitted. Task 1 will always execute before Task 2.

Thread.stop() is deprecated and unsafe. Modern approaches use either a volatile flag or Thread.interrupt() with proper handling. Both are valid and recommended depending on the scenario.

ReentrantLock provides more control with tryLock() for non-blocking attempts, Condition objects for complex wait/notify patterns, and fairness policy. It's more flexible than synchronized.

Virtual Threads are lightweight (millions can run) with minimal memory overhead compared to platform threads (thousands). They automatically handle I/O blocking without thread creation, making them ideal for high-concurrency scenarios.

Java guarantees that the lock is released when exiting a synchronized block, whether normally or via an exception. This is why synchronized is considered safer than manual lock management.

Safe publication requires using visibility mechanisms: synchronized (mutual exclusion), volatile (visibility), or thread-safe collections (both). Direct assignment without synchronization causes visibility issues in the memory model.

ForkJoinPool is designed for divide-and-conquer tasks where large problems are split (fork) into smaller subtasks and results are combined (join). It's optimized for recursive parallel algorithms.

Calling interrupt() on a blocked thread sets the interrupt flag. If the blocking operation supports interruption (like sleep(), join(), wait()), it throws InterruptedException. Non-interruptible I/O blocks require other mechanisms.

The synchronized keyword creates a critical section that only one thread can access at a time, preventing race conditions. volatile ensures visibility but not atomicity.

Virtual threads (Project Loom) are extremely lightweight and allow creating millions of threads efficiently, unlike platform threads which are limited by OS resources.

volatile ensures that all threads see the most recent value of a variable (visibility) but does not provide atomicity for compound operations.

volatile only ensures visibility, not atomicity. counter++ is actually three operations (read, increment, write), so even with volatile, race conditions can occur.