In a high-concurrency scenario using Java 21, which approach is recommended for I/O-bound operations?
Answer: A
Virtual Threads (Project Loom) are ideal for I/O-bound operations as they have minimal overhead and can number in millions, improving scalability significantly.
Q.82Hard
What is the purpose of the strictfp modifier in the context of multithreading?
Answer: A
strictfp ensures consistent floating-point results across different platforms/JVMs, though it's not directly a multithreading construct.
Q.83Hard
In a producer-consumer problem, what is the ideal synchronization mechanism?
Answer: A
BlockingQueue (like LinkedBlockingQueue) is purpose-built for producer-consumer patterns, handling synchronization and blocking elegantly.
Q.84Hard
Consider a scenario with 3 threads updating a shared counter. Which synchronization mechanism is MOST efficient?
Answer: B
AtomicInteger uses lock-free CAS operations which are more efficient than synchronized blocks or locks for simple counter operations with multiple threads.
Q.85Hard
What is the behavior of ReentrantReadWriteLock when multiple threads perform read operations?
Answer: B
ReentrantReadWriteLock allows multiple threads to acquire the read lock simultaneously, but only one thread can hold the write lock. This improves concurrency for read-heavy workloads.
Advertisement
Q.86Hard
Which scenario can lead to livelock in multithreading?
Answer: A
Livelock occurs when threads are not blocked but continuously change state in response to each other (like two people trying to pass each other), preventing progress. This differs from deadlock where threads are blocked.
Q.87Hard
In a ForkJoinPool, what is the primary advantage over ExecutorService for recursive tasks?
Answer: B
ForkJoinPool uses a work-stealing algorithm where idle threads can 'steal' tasks from busy threads' queues, providing better load balancing for divide-and-conquer problems.
Q.88Hard
What is the output of the following code?
Thread t = new Thread(() -> { throw new RuntimeException("Error"); });
t.setUncaughtExceptionHandler((thread, ex) -> System.out.println("Caught"));
t.start();
Answer: A
The UncaughtExceptionHandler is invoked when an exception is thrown in a thread and not caught. It will print 'Caught' before the thread terminates.
Q.89Hard
Which statement about StampedLock is TRUE?
Answer: B
StampedLock provides optimistic reads that don't require acquiring a lock. If the data changes during an optimistic read, validation fails and a pessimistic lock can be acquired.
Q.90Hard
In the context of Java 21 Virtual Threads, what is a major limitation of traditional threading that Virtual Threads solve?
Answer: B
Virtual Threads are lightweight and can be created in large numbers (millions) with minimal memory footprint, unlike platform threads which are heavy OS-level constructs. This solves scalability issues in high-concurrency applications.
Q.91Hard
Consider a ThreadLocal variable initialized in a thread pool executor with 10 threads. If the same thread is reused from the pool for a different task, what is the state of its ThreadLocal variable?
Answer: B
ThreadLocal values persist across task executions in the same thread. ThreadPools reuse threads, so previous ThreadLocal values remain unless explicitly removed. This can cause data leakage. Developers must call remove() to clean up.
Q.92Hard
A high-frequency trading system uses AtomicInteger for concurrent counter updates. However, performance degrades as more threads access the same counter. What is the primary cause and best solution?
Answer: A
AtomicInteger suffers from false sharing when multiple threads frequently update adjacent memory locations on the same CPU cache line. LongAdder uses striped updates across multiple cells, reducing contention. This is a 2024-25 performance optimization best practice for high-concurrency scenarios.
Q.93Hard
Analyze the code:
try {
return 5;
} finally {
return 10;
}
What will be returned?
Answer: B
The finally block always executes, and if it contains a return statement, it overrides the return value from try or catch block. So 10 is returned.
Q.94Hard
What happens if an exception is thrown in the finally block?
Answer: C
If an exception occurs in the finally block, it will replace any exception thrown in the try or catch block, and the new exception will be propagated.
Q.95Hard
Analyze the nested try-catch:
try {
try {
int x = 05;
} catch(NullPointerException e) {
System.out.println("Inner");
}
} catch(ArithmeticException e) {
System.out.println("Outer");
}
Answer: B
ArithmeticException is thrown by 05. Inner catch only catches NullPointerException, so it propagates to outer catch which handles ArithmeticException. Output: Outer
Q.96Hard
What will be printed?
public class ExceptionTest {
public static void main(String[] args) {
try {
testMethod();
} catch (Exception e) {
System.out.println("Caught");
}
}
public static void testMethod() {
try {
throw new RuntimeException("Error");
} finally {
System.out.println("Finally");
}
}
}
Answer: A
Finally block executes first (prints 'Finally'), then the exception propagates to outer catch block which prints 'Caught'.
Q.97Hard
Which of the following is NOT a characteristic of Exception class in Java?
Answer: B
Exception class has both checked subclasses (like IOException) and unchecked subclasses (like RuntimeException). Not all exceptions extending Exception are checked.
Q.98Hard
Which of the following cannot throw a checked exception without being declared in throws clause?
Answer: D
Checked exceptions in constructors, instance initializers, and static initializers must be handled with try-catch or declared in throws (constructors only). This is enforced by Java compiler.
Q.99Hard
What is the execution order in try-catch-finally for nested exception handling?
Answer: B
Nested exception handling follows inner-to-outer order. Inner try-catch-finally completes fully, then control passes to outer blocks. Finally blocks execute in their respective scope order.
Q.100Hard
What is suppressed exception in Java (introduced in Java 7)?
Answer: B
In try-with-resources, if an exception occurs in try and another in resource close(), the second is added as suppressed exception to the first using addSuppressed(), preserving all exception information.
