Q: Two threads calling a synchronized instance method on the same object: what sequence of numbers prints? public class ThreadDemo { private int count = 1; public synchronized void doSomething() { for (int i = 0; i < 10; i++) System.out.println(cou…

Introduction / Context: This problem reinforces how synchronized instance methods serialize access when multiple threads share the same object. Because both threads call the same synchronized method on the same ThreadDemo instance, only one thread at a time executes the loop.Given Data / Assumptions:count starts at 1 and is incremented inside a synchronized method.Two threads A operate on the same ThreadDemo instance.Each call prints ten numbers by incrementing count.Concept / Approach: Mutual exclusion ensures that the first thread prints 1..10 in order, then the second thread prints 11..20, also in order. Which thread prints first is not specified, but the overall sequence from 1 to 20 will be strictly increasing without overlap or gaps.Step-by-Step Solution:Thread T1 enters doSomething(), prints 1..10, exits.Thread T2 then enters doSomething(), prints 11..20.The monitor on demo enforces this serialization.Final output is the numbers 1 through 20, each once, in order.Verification / Alternative check: If doSomething() were not synchronized, lines could interleave and ordering would not be guaranteed.Why Other Options Are Wrong:0..19 contradicts initial value.“Unknown order with repeats” would require a data race.The code compiles and does not deadlock.Common Pitfalls: Assuming threads will interleave inside a synchronized loop; forgetting synchronization scope.Final Answer: Prints 1 to 20 sequentially

Q: Using wait/notify correctly: why does this code fail at runtime? public class Test { public static void main(String[] args) { final Foo f = new Foo(); Thread t = new Thread(new Runnable() { public void run() { f.doStuff(); } }); Thread g = new …

Introduction / Context: Object.wait() and Object.notify()/notifyAll() must be invoked by a thread that currently owns the object’s monitor; otherwise, the JVM throws IllegalMonitorStateException. This example intentionally calls wait/notify without synchronization to test your understanding of this precondition.Given Data / Assumptions:Two threads invoke Foo.doStuff() concurrently on the same Foo instance.doStuff() calls wait() and notify() with no synchronized block or synchronized method.x starts at 5, satisfying the x Concept / Approach: Because neither doStuff() nor its caller holds Foo’s monitor (i.e., synchronized(this)), calling wait() immediately raises IllegalMonitorStateException at runtime. Likewise, notify() would also be illegal if reached. Proper usage requires doStuff() to be synchronized or to wrap wait/notify inside synchronized(this) {}.Step-by-Step Solution:Threads start and enter doStuff().Branch x The JVM throws IllegalMonitorStateException.Program terminates abnormally; no consistent printing occurs.Verification / Alternative check: Fix by declaring public synchronized void doStuff() and by using a condition loop (while (x Why Other Options Are Wrong:Compilation is fine; the error is at runtime.Printing “x is 5 x is 6” would require reaching the else branch and proper synchronization.Hanging forever is not the observed behavior here; instead an immediate exception is thrown.Common Pitfalls: Forgetting to synchronize when using wait/notify; using if instead of while around wait, which can lead to spurious wakeup issues.Final Answer: An exception occurs at runtime

Q: Java Thread.start() invoked twice on the same thread — what happens? class MyThread extends Thread { public static void main(String [] args) { MyThread t = new MyThread(); t.start(); System.out.print("one. "); t.start(); System.out.print("…

Introduction / Context:This question targets lifecycle rules for java.lang.Thread. Calling start() transitions a new thread from NEW to RUNNABLE. A second call to start() on the same Thread object violates the lifecycle and results in a runtime exception.Given Data / Assumptions:t is constructed, then start() is called twice.run() prints "Thread ".There are prints on the main thread: "one. " and "two. ".Concept / Approach:Thread.start() may be invoked only once per Thread object. A second call throws IllegalThreadStateException, an unchecked RuntimeException. Therefore the program compiles, begins running, and then fails at the second start(). Output produced before the exception (such as "Thread " and/or "one. ") is nondeterministic, but the guaranteed outcome is a runtime exception.Step-by-Step Solution:Call t.start() → valid; run() may execute concurrently.Print "one. ".Call t.start() again → IllegalThreadStateException is thrown.Execution terminates abnormally; any subsequent prints may not execute.Verification / Alternative check:Replace the second start() with a fresh Thread object or call run() directly (which does not start a new thread) to avoid the exception.Why Other Options Are Wrong:Compilation succeeds; the error is at runtime.Deterministic combined output is impossible due to exception and scheduling.Common Pitfalls:Confusing run() with start(); run() can be called multiple times but runs on the current thread.Final Answer:An exception occurs at runtime.

Q: Two Runnable instances and two threads — what ordering will the printed numbers follow? class s1 implements Runnable { int x = 0, y = 0; int addX() { x++; return x; } int addY() { y++; return y; } public void run() { for (int i = 0; i < …

Introduction / Context:The code launches two separate Runnable instances, each with its own counters x and y. The question probes thread interleaving and the independence of state when each thread operates on a different object.Given Data / Assumptions:run1 and run2 are distinct objects; each thread mutates only its own x and y.There is no synchronization; however, there is no shared state between the threads either.Each thread prints ten lines: "1 1", "2 2", … for its own object.Concept / Approach:Because the two threads print concurrently, the console output is an interleaving of two monotonic sequences. Java does not guarantee relative scheduling order, so the lines may mix arbitrarily. What is guaranteed: within each individual thread, the outputs occur in ascending order for that thread.Step-by-Step Solution:Thread t1 prints: 1 1, 2 2, 3 3, …Thread t2 prints: 1 1, 2 2, 3 3, …Interleaving may be t1,t2,t1,t2 or t2,t2,t1,… etc.Thus the overall order is not strictly predictable across both threads.Verification / Alternative check:Adding Thread.sleep or using thread priorities still does not guarantee a fixed interleaving; only explicit coordination would.Why Other Options Are Wrong:No compile-time error: start() exists on Thread.A single global sequence (option D) would require shared counters.A strict alternating pattern (option B) is not guaranteed without coordination.Common Pitfalls:Assuming deterministic scheduling or thinking that lack of synchronization implies errors even when objects are distinct.Final Answer:Will print but not exactly in an order (e.g: 1 1 2 2 1 1 3 3...)

Q: One shared Runnable with internal synchronization — what will the two threads print? class s implements Runnable { int x, y; public void run() { for (int i = 0; i < 1000; i++) synchronized (this) { x = 12; y = 12; } System.out.…

Introduction / Context:This code launches two threads sharing a single Runnable instance. Inside run(), assignments to x and y are protected by synchronized(this). The question asks whether the final prints are deterministic and what values will appear.Given Data / Assumptions:Both threads execute the same run object (this is the same monitor for synchronized).Within the loop, x and y are always set to 12 together while holding the monitor.After the loop, each thread prints x and y without additional synchronization.Concept / Approach:Because all writes to x and y happen under the same monitor and always set the same constants (12 and 12), the values cannot diverge. Although the final println occurs outside synchronized, the JMM still guarantees that some assignment has occurred before printing since each thread itself performs the assignments, then prints. There is no deadlock: both synchronized blocks are short and use a single, consistent monitor (this).Step-by-Step Solution:Each thread runs the loop 1000 times, repeatedly setting x=12 and y=12 under lock.After its loop finishes, a thread prints x + " " + y + " ". For that thread, the last writes it performed were 12 and 12.Thus the first print is "12 12 ". The second thread does the same, so the combined output is "12 12 12 12" (ordering of the two pairs may vary, but the values are the same).Verification / Alternative check:Even without synchronization, constant assignments would still lead to 12 12, but synchronization ensures no torn writes or reordering issues for visibility across threads.Why Other Options Are Wrong:Deadlock requires circular waits on multiple locks; only one lock is used.Compilation is valid.“Cannot determine” is overly pessimistic; the printed values are deterministically 12 and 12 for each thread.Common Pitfalls:Assuming prints must be inside synchronized to see consistent values; here each thread prints its own last writes.Final Answer:It print 12 12 12 12

Q: Thread.currentThread().sleep(...) usage — does this code compile and what happens? class Test { public static void main(String [] args) { printAll(args); } public static void printAll(String[] lines) { for (int i = 0; i < lines.length; i…

Introduction / Context:The snippet uses Thread.currentThread().sleep(1000) to pause after printing each line. The key point is not whether sleep applies to the current thread (it does) but that sleep(long) throws InterruptedException, which must be handled or declared.Given Data / Assumptions:Thread.sleep(long) is a static method that throws InterruptedException.Calling it via Thread.currentThread() is legal but still static.Method printAll does not declare throws InterruptedException and does not catch it.Concept / Approach:Checked exceptions in Java must be caught or declared. Because sleep throws InterruptedException, the compiler requires a try/catch around the call or a throws clause in printAll (and in main if not handled there). Absent either, compilation fails regardless of whether a thread is explicitly created.Step-by-Step Solution:Encounter call to Thread.currentThread().sleep(1000).sleep(long) declares throws InterruptedException.No try/catch present; no throws on printAll.Compiler error: unreported exception InterruptedException; must be caught or declared to be thrown.Verification / Alternative check:Fix by writing: try { Thread.sleep(1000); } catch (InterruptedException ie) { Thread.currentThread().interrupt(); }Why Other Options Are Wrong:They presume successful compilation and execution.Whether or not the code runs in a separate thread is irrelevant to compile-time checked exception rules.Common Pitfalls:Forgetting that calling a static method through an expression does not change its checked-exception behavior.Final Answer:This code will not compile.

Q: Calling yield() inside run() — what will this single-thread program display? public class ThreadTest extends Thread { public void run() { System.out.println("In run"); yield(); System.out.println("Leaving run"); } public static void …

Introduction / Context:This question checks understanding of Thread.yield() and the typical behavior when a single custom thread is launched. yield() is a hint to the scheduler that the current thread is willing to let other runnable threads proceed.Given Data / Assumptions:Only one user-created thread runs besides the JVM’s background threads.run() prints two lines with a yield() call in between.No exceptions are thrown, and the code compiles cleanly.Concept / Approach:yield() does not terminate a thread; it merely gives the scheduler an opportunity to allow another runnable thread to run. In the absence of competing runnable threads with higher or equal priority, the yielding thread is typically scheduled again immediately. Thus both print statements execute in order.Step-by-Step Solution:start() → new thread begins executing run().Prints "In run".yield() → scheduler may switch, but usually the same thread continues quickly.Prints "Leaving run".Verification / Alternative check:Even with other runnable threads, yield() does not skip code; the same thread will continue later and print the second line.Why Other Options Are Wrong:There is no compile error.Only printing the first line would imply termination after yield(), which is incorrect.Common Pitfalls:Overestimating the power of yield(); it is only a scheduling hint and guarantees nothing beyond allowing other runnable threads a chance.Final Answer:The text "In run" followed by "Leaving run" will be displayed

Question 1

Two threads, one synchronized run(), infinite loop: what behavior is guaranteed?  public class Q126 implements Runnable {  private int x; private int y;  public static void main(String[] args) {  Q126 that = new Q126();  (new Thread(that)).start(); …

Accepted Answer

Introduction / Context: This test explores synchronization and liveness. Because run() is synchronized on the shared Runnable instance, only one thread can execute it at a time. The infinite loop means the first thread that enters never releases the lock, so the second thread is blocked indefinitely.Given Data / Assumptions:Two Thread objects share the same Q126 instance.run() is an instance-synchronized method.The loop is for(;;), i.e., never terminates.Concept / Approach: Mutual exclusion on the same monitor guarantees that increments of x and y occur together with no interference. Since the loop never ends, the first thread to acquire the monitor will print endlessly. The second thread will remain blocked on the monitor and never print.Step-by-Step Solution:Thread T1 acquires monitor on the Q126 object.In each iteration, T1 increments x and y and prints the pair → they remain equal.T2 attempts to enter run(), blocks on the monitor forever because T1 never exits.Output is an increasing sequence (x = 1 y = 1), (x = 2 y = 2), …Verification / Alternative check: If the loop had a break or sleep with a synchronized block of smaller scope, the lock could be released and T2 might run later, but as written T1 monopolizes it.Why Other Options Are Wrong:Compilation errors do not exist on the cited lines.Races (option c) are prevented by synchronization.No deadlock occurs—only starvation of T2.Common Pitfalls: Expecting both threads to alternate inside a synchronized infinite loop; misunderstanding that a synchronized method holds the lock for its entire duration.Final Answer: x and y are always equal and increase by one each line; one thread monopolizes execution

Question 2

wait/notify preconditions: calling wait() while holding the monitor but without a notifier.  public class WaitTest {  public static void main(String[] args) {  System.out.print("1 ");  synchronized (args) {  System.out.print("2 ");  try { args.wait(…

Accepted Answer

Introduction / Context: This exercise probes correct use of Object.wait(). The thread must own the monitor of the object on which wait() is called, and typically some other thread should notify/notifyAll() to resume the waiting thread.Given Data / Assumptions:The code synchronizes on args and then calls args.wait().No other thread exists that could call notify/notifyAll() on the same monitor.InterruptedException is caught properly.Concept / Approach: The call occurs while holding the monitor, satisfying the precondition; thus no IllegalMonitorStateException is thrown. However, because no other thread notifies, the waiting thread never wakes up. Therefore the code prints “1 2” and then blocks indefinitely; “3” is never printed.Step-by-Step Solution:Print “1 ”.Enter synchronized(args) and print “2 ”.Call args.wait(): releases the monitor and parks the thread.No notify occurs → the program hangs.Verification / Alternative check: Adding a second thread that locks on args and invokes notify() would allow the main thread to resume and print “3”.Why Other Options Are Wrong:IllegalMonitorStateException is not required to be handled and does not occur here.“1 2 3” and “1 3” contradict the waiting behavior.Common Pitfalls: Forgetting to pair wait() with a proper notify path; calling wait() without holding the monitor (which would cause IllegalMonitorStateException).Final Answer: 1 2

Question 3

Protecting shared state: which change ensures Foo.data remains consistent under concurrency?  public class SyncTest {  public static void main(String[] args) {  Thread t = new Thread() {  Foo f = new Foo();  public void run() { f.increase(20); }  };…

Accepted Answer

Introduction / Context: The code demonstrates a read-modify-write sequence on a shared field. Without synchronization, concurrent invocations may interleave in a way that loses updates (a classic race). Ensuring integrity requires atomicity and memory visibility guarantees.Given Data / Assumptions:Field data is mutable shared state.Method increase(int) performs a non-atomic read-modify-write.Multiple threads may call increase concurrently in realistic scenarios.Concept / Approach: Declaring increase as synchronized makes the entire critical section atomic with respect to a Foo instance and establishes happens-before relationships for visibility. While volatile ensures visibility, it does not make compound actions atomic. Synchronizing run() or wrapping synchronized around the call site helps only if all callers do it; encapsulating the lock in the method is safer.Step-by-Step Solution:Change signature to public synchronized void increase(int amt).This serializes all calls on the same Foo object.Now read x = data and write data = x + amt occur without interleaving.Visibility is guaranteed when threads enter/exit the monitor.Verification / Alternative check: Another correct approach is to use AtomicInteger and data.getAndAdd(amt) which is lock-free and atomic.Why Other Options Are Wrong:Synchronizing run() or at the call site is fragile and not enforced for all callers.No runtime exception occurs by default.volatile alone does not make the compound operation atomic.Common Pitfalls: Relying on volatile for compound operations; synchronizing only some call sites; ignoring visibility guarantees.Final Answer: Declare increase(int) as synchronized to guard data

Question 4

Two threads calling a synchronized instance method on the same object: what sequence of numbers prints?  public class ThreadDemo {  private int count = 1;  public synchronized void doSomething() {  for (int i = 0; i < 10; i++) System.out.println(cou…

Accepted Answer

Introduction / Context: This problem reinforces how synchronized instance methods serialize access when multiple threads share the same object. Because both threads call the same synchronized method on the same ThreadDemo instance, only one thread at a time executes the loop.Given Data / Assumptions:count starts at 1 and is incremented inside a synchronized method.Two threads A operate on the same ThreadDemo instance.Each call prints ten numbers by incrementing count.Concept / Approach: Mutual exclusion ensures that the first thread prints 1..10 in order, then the second thread prints 11..20, also in order. Which thread prints first is not specified, but the overall sequence from 1 to 20 will be strictly increasing without overlap or gaps.Step-by-Step Solution:Thread T1 enters doSomething(), prints 1..10, exits.Thread T2 then enters doSomething(), prints 11..20.The monitor on demo enforces this serialization.Final output is the numbers 1 through 20, each once, in order.Verification / Alternative check: If doSomething() were not synchronized, lines could interleave and ordering would not be guaranteed.Why Other Options Are Wrong:0..19 contradicts initial value.“Unknown order with repeats” would require a data race.The code compiles and does not deadlock.Common Pitfalls: Assuming threads will interleave inside a synchronized loop; forgetting synchronization scope.Final Answer: Prints 1 to 20 sequentially

Question 5

Using wait/notify correctly: why does this code fail at runtime?  public class Test {  public static void main(String[] args) {  final Foo f = new Foo();  Thread t = new Thread(new Runnable() { public void run() { f.doStuff(); } });  Thread g = new …

Accepted Answer

Introduction / Context: Object.wait() and Object.notify()/notifyAll() must be invoked by a thread that currently owns the object’s monitor; otherwise, the JVM throws IllegalMonitorStateException. This example intentionally calls wait/notify without synchronization to test your understanding of this precondition.Given Data / Assumptions:Two threads invoke Foo.doStuff() concurrently on the same Foo instance.doStuff() calls wait() and notify() with no synchronized block or synchronized method.x starts at 5, satisfying the x Concept / Approach: Because neither doStuff() nor its caller holds Foo’s monitor (i.e., synchronized(this)), calling wait() immediately raises IllegalMonitorStateException at runtime. Likewise, notify() would also be illegal if reached. Proper usage requires doStuff() to be synchronized or to wrap wait/notify inside synchronized(this) {}.Step-by-Step Solution:Threads start and enter doStuff().Branch x The JVM throws IllegalMonitorStateException.Program terminates abnormally; no consistent printing occurs.Verification / Alternative check: Fix by declaring public synchronized void doStuff() and by using a condition loop (while (x Why Other Options Are Wrong:Compilation is fine; the error is at runtime.Printing “x is 5 x is 6” would require reaching the else branch and proper synchronization.Hanging forever is not the observed behavior here; instead an immediate exception is thrown.Common Pitfalls: Forgetting to synchronize when using wait/notify; using if instead of while around wait, which can lead to spurious wakeup issues.Final Answer: An exception occurs at runtime

Question 6

Java threads without join — what is printed by main when two worker threads update shared buffers?  class Test116  {   static final StringBuffer sb1 = new StringBuffer();   static final StringBuffer sb2 = new StringBuffer();   public static void mai…

Accepted Answer

Introduction / Context:This problem explores thread scheduling and visibility when the main thread starts worker threads and immediately prints shared data without waiting. It tests understanding of start(), synchronized blocks, and the absence of join() or other happens-before relationships connecting worker completion to the println call.Given Data / Assumptions:Two anonymous threads each synchronize on sb1, then append to sb1 and sb2.Main thread starts both and immediately executes System.out.println(sb1 + " " + sb2).No join(), latch, or other coordination is performed.StringBuffer methods are synchronized but that does not force main to wait.Concept / Approach:Thread.start() returns promptly; it does not block until run() completes. Without a join or coordination primitive, main may print before any thread runs, after one runs, after both run, or interleaved with them. The println converts sb1 and sb2 to strings at that instant, showing whatever content has been appended so far. Because each worker locks sb1 before modifying both buffers, there is no data race between workers, but there is also no ordering with main.Step-by-Step Solution:Case 1: Scheduler runs main immediately → output: "" (empty) + space + "" (empty).Case 2: One worker completes first → output could be "A" or "C" for sb1 and "B" or "D" for sb2.Case 3: Both complete before println → output "AC BD" (or "CA DB") depending on order.Because all are possible, a single deterministic answer cannot be given.Verification / Alternative check:Insert t1.join(); t2.join(); before println to force deterministic output showing both letters in each buffer. Without joins, results vary per run and platform.Why Other Options Are Wrong:"main() will finish before starting threads." is incorrect; start() definitely runs before println, but workers may or may not run before the print."main() will finish in the middle/after one thread" assert specific schedules not guaranteed.Common Pitfalls:Assuming that synchronized modifications imply visibility to unrelated threads without an ordering action like join(), volatile, or synchronized around the read.Final Answer:Cannot be determined.

Question 7

Java Thread.start() invoked twice on the same thread — what happens?  class MyThread extends Thread  {  public static void main(String [] args)   {  MyThread t = new MyThread();  t.start();  System.out.print("one. ");  t.start();  System.out.print("…

Accepted Answer

Introduction / Context:This question targets lifecycle rules for java.lang.Thread. Calling start() transitions a new thread from NEW to RUNNABLE. A second call to start() on the same Thread object violates the lifecycle and results in a runtime exception.Given Data / Assumptions:t is constructed, then start() is called twice.run() prints "Thread ".There are prints on the main thread: "one. " and "two. ".Concept / Approach:Thread.start() may be invoked only once per Thread object. A second call throws IllegalThreadStateException, an unchecked RuntimeException. Therefore the program compiles, begins running, and then fails at the second start(). Output produced before the exception (such as "Thread " and/or "one. ") is nondeterministic, but the guaranteed outcome is a runtime exception.Step-by-Step Solution:Call t.start() → valid; run() may execute concurrently.Print "one. ".Call t.start() again → IllegalThreadStateException is thrown.Execution terminates abnormally; any subsequent prints may not execute.Verification / Alternative check:Replace the second start() with a fresh Thread object or call run() directly (which does not start a new thread) to avoid the exception.Why Other Options Are Wrong:Compilation succeeds; the error is at runtime.Deterministic combined output is impossible due to exception and scheduling.Common Pitfalls:Confusing run() with start(); run() can be called multiple times but runs on the current thread.Final Answer:An exception occurs at runtime.

Question 8

Two Runnable instances and two threads — what ordering will the printed numbers follow?  class s1 implements Runnable  {   int x = 0, y = 0;   int addX() { x++; return x; }   int addY() { y++; return y; }   public void run() {   for (int i = 0; i < …

Accepted Answer

Introduction / Context:The code launches two separate Runnable instances, each with its own counters x and y. The question probes thread interleaving and the independence of state when each thread operates on a different object.Given Data / Assumptions:run1 and run2 are distinct objects; each thread mutates only its own x and y.There is no synchronization; however, there is no shared state between the threads either.Each thread prints ten lines: "1 1", "2 2", … for its own object.Concept / Approach:Because the two threads print concurrently, the console output is an interleaving of two monotonic sequences. Java does not guarantee relative scheduling order, so the lines may mix arbitrarily. What is guaranteed: within each individual thread, the outputs occur in ascending order for that thread.Step-by-Step Solution:Thread t1 prints: 1 1, 2 2, 3 3, …Thread t2 prints: 1 1, 2 2, 3 3, …Interleaving may be t1,t2,t1,t2 or t2,t2,t1,… etc.Thus the overall order is not strictly predictable across both threads.Verification / Alternative check:Adding Thread.sleep or using thread priorities still does not guarantee a fixed interleaving; only explicit coordination would.Why Other Options Are Wrong:No compile-time error: start() exists on Thread.A single global sequence (option D) would require shared counters.A strict alternating pattern (option B) is not guaranteed without coordination.Common Pitfalls:Assuming deterministic scheduling or thinking that lack of synchronization implies errors even when objects are distinct.Final Answer:Will print but not exactly in an order (e.g: 1 1 2 2 1 1 3 3...)

Question 9

One shared Runnable with internal synchronization — what will the two threads print?  class s implements Runnable  {   int x, y;   public void run()   {   for (int i = 0; i < 1000; i++)   synchronized (this)   {   x = 12;   y = 12;   }   System.out.…

Accepted Answer

Introduction / Context:This code launches two threads sharing a single Runnable instance. Inside run(), assignments to x and y are protected by synchronized(this). The question asks whether the final prints are deterministic and what values will appear.Given Data / Assumptions:Both threads execute the same run object (this is the same monitor for synchronized).Within the loop, x and y are always set to 12 together while holding the monitor.After the loop, each thread prints x and y without additional synchronization.Concept / Approach:Because all writes to x and y happen under the same monitor and always set the same constants (12 and 12), the values cannot diverge. Although the final println occurs outside synchronized, the JMM still guarantees that some assignment has occurred before printing since each thread itself performs the assignments, then prints. There is no deadlock: both synchronized blocks are short and use a single, consistent monitor (this).Step-by-Step Solution:Each thread runs the loop 1000 times, repeatedly setting x=12 and y=12 under lock.After its loop finishes, a thread prints x + " " + y + " ". For that thread, the last writes it performed were 12 and 12.Thus the first print is "12 12 ". The second thread does the same, so the combined output is "12 12 12 12" (ordering of the two pairs may vary, but the values are the same).Verification / Alternative check:Even without synchronization, constant assignments would still lead to 12 12, but synchronization ensures no torn writes or reordering issues for visibility across threads.Why Other Options Are Wrong:Deadlock requires circular waits on multiple locks; only one lock is used.Compilation is valid.“Cannot determine” is overly pessimistic; the printed values are deterministically 12 and 12 for each thread.Common Pitfalls:Assuming prints must be inside synchronized to see consistent values; here each thread prints its own last writes.Final Answer:It print 12 12 12 12

Question 10

Thread.currentThread().sleep(...) usage — does this code compile and what happens?  class Test  {  public static void main(String [] args)   {  printAll(args);  }   public static void printAll(String[] lines)   {  for (int i = 0; i < lines.length; i…

Accepted Answer

Introduction / Context:The snippet uses Thread.currentThread().sleep(1000) to pause after printing each line. The key point is not whether sleep applies to the current thread (it does) but that sleep(long) throws InterruptedException, which must be handled or declared.Given Data / Assumptions:Thread.sleep(long) is a static method that throws InterruptedException.Calling it via Thread.currentThread() is legal but still static.Method printAll does not declare throws InterruptedException and does not catch it.Concept / Approach:Checked exceptions in Java must be caught or declared. Because sleep throws InterruptedException, the compiler requires a try/catch around the call or a throws clause in printAll (and in main if not handled there). Absent either, compilation fails regardless of whether a thread is explicitly created.Step-by-Step Solution:Encounter call to Thread.currentThread().sleep(1000).sleep(long) declares throws InterruptedException.No try/catch present; no throws on printAll.Compiler error: unreported exception InterruptedException; must be caught or declared to be thrown.Verification / Alternative check:Fix by writing: try { Thread.sleep(1000); } catch (InterruptedException ie) { Thread.currentThread().interrupt(); }Why Other Options Are Wrong:They presume successful compilation and execution.Whether or not the code runs in a separate thread is irrelevant to compile-time checked exception rules.Common Pitfalls:Forgetting that calling a static method through an expression does not change its checked-exception behavior.Final Answer:This code will not compile.

Question 11

Calling yield() inside run() — what will this single-thread program display?  public class ThreadTest extends Thread  {   public void run()   {   System.out.println("In run");   yield();   System.out.println("Leaving run");   }   public static void …

Accepted Answer

Introduction / Context:This question checks understanding of Thread.yield() and the typical behavior when a single custom thread is launched. yield() is a hint to the scheduler that the current thread is willing to let other runnable threads proceed.Given Data / Assumptions:Only one user-created thread runs besides the JVM’s background threads.run() prints two lines with a yield() call in between.No exceptions are thrown, and the code compiles cleanly.Concept / Approach:yield() does not terminate a thread; it merely gives the scheduler an opportunity to allow another runnable thread to run. In the absence of competing runnable threads with higher or equal priority, the yielding thread is typically scheduled again immediately. Thus both print statements execute in order.Step-by-Step Solution:start() → new thread begins executing run().Prints "In run".yield() → scheduler may switch, but usually the same thread continues quickly.Prints "Leaving run".Verification / Alternative check:Even with other runnable threads, yield() does not skip code; the same thread will continue later and print the second line.Why Other Options Are Wrong:There is no compile error.Only printing the first line would imply termination after yield(), which is incorrect.Common Pitfalls:Overestimating the power of yield(); it is only a scheduling hint and guarantees nothing beyond allowing other runnable threads a chance.Final Answer:The text "In run" followed by "Leaving run" will be displayed

Question 12

Two Thread subclasses running concurrently — can you predict the exact print order?  class s1 extends Thread {   public void run()   {   for (int i = 0; i < 3; i++)   {   System.out.println("A");   System.out.println("B");   }   }  }  class Test120 …

Accepted Answer

Introduction / Context:The program launches two independent Thread subclasses. Each thread prints two letters per loop iteration. The question asks if the final interleaving across both threads can be predicted.Given Data / Assumptions:t1 prints A then B, three times.t2 prints C then D, three times.No synchronization exists between t1 and t2.Concept / Approach:Interleaving among different threads is nondeterministic. Within a single thread, A always precedes B and C always precedes D in each loop; however, the relative ordering between the two threads has no guarantee. Therefore you cannot predict a fixed combined pattern like AB CD AB … or ABCD … across the whole output.Step-by-Step Solution:Possible output fragment: A B C D A B C D …Another run: C D A B C D …Or even mixed lines: A C B D A B C D … depending on scheduler timing.Verification / Alternative check:Introducing Thread.sleep calls can influence but not fully determine the interleaving; exact ordering still varies by platform and load.Why Other Options Are Wrong:No compile error.Specific patterns (options B and D) are not guaranteed.Common Pitfalls:Assuming JVM uses a round-robin scheduler that yields a neat AB-CD alternation.Final Answer:Will print but not be able to predict the Order

Question 13

Anonymous Thread subclass overriding run() vs superclass constructor side effects — what prints?  class MyThread extends Thread  {  MyThread()   {  System.out.print(" MyThread");  }  public void run()   {  System.out.print(" bar");  }  public void r…

Accepted Answer

Introduction / Context:This question combines constructor side effects with method overriding. The superclass MyThread prints in its constructor and defines two run methods: run() and an overloaded run(String). The anonymous subclass created in main overrides run().Given Data / Assumptions:Constructing the anonymous subclass first runs the MyThread() constructor, printing " MyThread".The anonymous subclass overrides run() and prints " foo" using println, which appends a newline.run(String) is just an overload, never called by Thread.start().Concept / Approach:Thread.start() always invokes the no-argument run() polymorphically. Overloads such as run(String) are not considered by the thread machinery. Therefore, after construction prints, the overridden run() in the anonymous class runs and prints " foo".Step-by-Step Solution:Create new MyThread() { public void run(){ System.out.println(" foo"); } } → constructor prints " MyThread".Call start() → JVM invokes overridden run() → prints " foo".No call to superclass run() or run(String) occurs.Verification / Alternative check:Replace println with print and observe spacing differences, but the token order remains MyThread then foo.Why Other Options Are Wrong:"foo" omits the constructor print."MyThread bar" would require using the superclass run(), which is overridden."foo bar" suggests both run methods executed; only one run() is called.Common Pitfalls:Confusing overloading with overriding; Thread looks only for run().Final Answer:MyThread foo

Question 14

Java wait/notify facts — select the two true statements from the list provided.

Accepted Answer

Introduction / Context:The item asks you to evaluate several assertions about Java’s wait/notify mechanism and thread scheduling. Understanding which methods are overloaded, what contexts are required, and what guarantees exist is essential for correct concurrent code.Given Data / Assumptions (statements):1) Deadlock will not occur if wait()/notify() is used2) A thread will resume execution as soon as its sleep duration expires.3) Synchronization can prevent two objects from being accessed by the same thread.4) The wait() method is overloaded to accept a duration.5) The notify() method is overloaded to accept a duration.6) Both wait() and notify() must be called from a synchronized context.Concept / Approach:Evaluate each statement against the Java Language Specification and java.lang.Object API.Step-by-Step Solution:1) False. Deadlock is still possible if locks are acquired in conflicting orders or notifications are missed due to logic errors.2) False. sleep sets the thread to TIMED_WAITING; after the time elapses it becomes RUNNABLE, but scheduling is not guaranteed immediately.3) False. Synchronization restricts concurrent access by multiple threads to shared state; it does not prevent a thread from accessing two objects.4) True. Object.wait has overloads: wait(long) and wait(long, int) besides wait().5) False. notify() and notifyAll() have no timed overloads.6) True. A thread must own the monitor to call wait/notify; otherwise IllegalMonitorStateException is thrown.Verification / Alternative check:Consult Object’s method signatures: wait(), wait(long), wait(long, int), notify(), notifyAll().Why Other Options Are Wrong:Any pair containing 1, 2, 3, or 5 includes at least one false statement.Common Pitfalls:Believing that sleep guarantees immediate resumption or that using wait/notify magically prevents deadlocks.Final Answer:4 and 6

Question 15

Creating a Thread with a Runnable target — which class definitions compile for "new Thread(target)"?  Given: Runnable target = new MyRunnable(); Thread myThread = new Thread(target);  Choose the valid implementation for MyRunnable.

Accepted Answer

Introduction / Context:To construct a Thread with a Runnable target, the argument must implement the java.lang.Runnable interface. The interface declares one method: public void run().Given Data / Assumptions:The Thread constructor used is Thread(Runnable target).We are deciding which candidate MyRunnable compiles and can be passed to that constructor.Concept / Approach:A class can implement an interface, not extend it. When implementing Runnable, the run method must be declared public to satisfy the interface’s public abstract signature. A package-private run() fails to implement the interface method due to reduced visibility.Step-by-Step Solution:Option A: "extends Runnable" is invalid; Runnable is an interface, not a class.Option B: Extending Object alone does not implement Runnable; cannot be used as the Thread target.Option C: Correct. Implements Runnable and provides public void run().Option D: Incorrect visibility; method must be public to implement Runnable.run().Verification / Alternative check:Compile Option C and pass new MyRunnable() into new Thread(target); code compiles and runs.Why Other Options Are Wrong:They either misuse inheritance for an interface or fail the visibility requirement.Common Pitfalls:Forgetting that interface methods are implicitly public and must be implemented with public visibility.Final Answer:public class MyRunnable implements Runnable{public void run(){}}

Question 16

In Java concurrency, which statement about wait()/notify() scheduling and resumption is actually true?

Accepted Answer

Introduction / Context:This question examines the precise semantics of the Java Object monitor methods wait(), notify(), and notifyAll(). Many beginners assume a deterministic “notify wakes one waiter and it runs immediately” model. In reality, the resumption of a waiting thread is neither immediate nor guaranteed; scheduling, monitor re-acquisition, and even spurious wakeups complicate the picture.Given Data / Assumptions:One or more threads may be waiting (via wait()) on the same monitor object.Another thread may invoke notify() or notifyAll() while holding that object’s monitor (inside a synchronized block/method).Threads may compete to re-acquire the monitor after being notified.Concept / Approach:Calling notify() moves one arbitrary waiting thread from the wait set to the entry set for that monitor. That thread is merely made eligible to acquire the monitor again; it cannot proceed until the notifier eventually exits the synchronized region and releases the monitor. Even after release, the awakened thread competes with other threads and may starve. Additionally, spurious wakeups are permitted, which is why wait() must be used in a loop that re-checks the condition predicate.Step-by-Step Solution:A thread calls wait(): it releases the monitor and enters the wait set.Another thread calls notify(): one waiter is transferred to the entry set but is still blocked until the monitor is free.When the notifier exits synchronized, the monitor becomes available; the awakened thread competes with other contenders and may be delayed.Because of scheduling/starvation or logic errors, it is possible (though undesirable) that a particular waiting thread never proceeds.Verification / Alternative check:Run a test with multiple notifies and heavy contention: it is easy to observe the notified thread not running “immediately”, and under pathological contention, for a long time. Correct code always waits in a loop checking the condition.Why Other Options Are Wrong:Option A claims immediate resumption; this is false—monitor re-acquisition and scheduling interpose.Option C guarantees definite, sole causality from notify(); not guaranteed—spurious wakeups and scheduling exist.Option D claims FIFO fairness among waiters; Java does not guarantee any ordering for notified waiters.Option E is incorrect because option B is correct.Common Pitfalls:Relying on notify() for ordering; forgetting to re-check the condition after wakeup; assuming immediate execution post-notify.Final Answer:If a thread is blocked in wait() and another thread calls notify() on the same object, it is still possible the waiting thread might never resume execution.

Question 17

Java monitors: which statement about notify/notifyAll/wait and synchronization requirements is true?

Accepted Answer

Introduction / Context:This item probes your understanding of where the monitor methods wait(), notify(), and notifyAll() can legally be invoked and which classes define them. Misconceptions here cause IllegalMonitorStateException and subtle concurrency bugs.Given Data / Assumptions:Java monitors are associated with every Object instance.wait(), notify(), and notifyAll() operate on an Object’s monitor, not on threads directly.Correct usage requires holding the relevant monitor.Concept / Approach:All three methods—wait, notify, notifyAll—are instance methods of java.lang.Object and must be called by a thread that currently owns that object’s monitor (i.e., from within a synchronized block/method on that same object). Otherwise, the runtime throws IllegalMonitorStateException.Step-by-Step Solution:Check Option A: notifyAll() must be called while holding the object’s monitor ⇒ true (same requirement as for notify() and wait()).Option B reverses the relationship: the calling thread must own the object’s lock, not the other way around ⇒ false.Option C: notify() is in Object, not Thread ⇒ false.Option D: notify() does not release any locks immediately; the notifying thread keeps them until leaving the synchronized block ⇒ false.Verification / Alternative check:Call notifyAll() outside synchronized; you will see IllegalMonitorStateException. Wrap it in synchronized(obj) { obj.notifyAll(); } and it works.Why Other Options Are Wrong:They either misstate ownership rules, attribute methods to the wrong class, or misdescribe lock-release timing.Common Pitfalls:Calling notify()/wait() on the wrong object; assuming notify() “hands off” the lock immediately; forgetting that these are Object methods.Final Answer:The notifyAll() method must be called from a synchronized context.

Question 18

Java synchronization basics: identify the single true statement about synchronized methods/blocks and thread behavior.

Accepted Answer

Introduction / Context:This question checks foundational knowledge of Java’s synchronized keyword applied to methods and blocks, and how it interacts with static members, instance members, and thread state changes such as sleep().Given Data / Assumptions:Synchronized is a modifier for methods and a block statement prefix; it is not a variable modifier.sleep() is a Thread API that pauses execution but does not affect monitor ownership.Static synchronized methods lock the Class object; instance synchronized methods lock the receiver instance.Concept / Approach:Confirm each option against the language rules. Only one statement should be fully accurate without extra caveats.Step-by-Step Solution:Option A: False. Static methods can be declared synchronized; they acquire the associated Class object’s monitor.Option B: True. Synchronization only guards the specific synchronized regions. Unprotected (non-synchronized) methods/blocks may run concurrently regardless of other synchronized parts.Option C: False. synchronized is not a field modifier; variables are not “marked synchronized.” Protection comes from synchronizing the code that accesses them.Option D: False. Thread.sleep(...) does not release any monitors held by the thread; locks are released only by exiting synchronized scopes (or by wait(), which releases the specific monitor while waiting).Verification / Alternative check:Create a class with both synchronized and unsynchronized methods; invoke them from multiple threads and observe that unsynchronized calls may interleave freely.Why Other Options Are Wrong:They misstate synchronized’s allowable targets (A/C) or the semantics of sleep() vs. monitor release (D).Common Pitfalls:Thinking synchronized is a property of data rather than code; assuming sleep() behaves like wait(); confusing static and instance locking.Final Answer:If a class has synchronized code, multiple threads can still access the nonsynchronized code.

Question 19

Thread creation in Java: which two techniques correctly start work on a new thread of execution?

Accepted Answer

Introduction / Context:This question targets the two canonical ways to define work that runs on a separate thread in Java: subclassing Thread and overriding run(), or implementing Runnable and supplying an instance to a Thread.Given Data / Assumptions:Statements listed: (1) Extend java.lang.Thread and override run(); (2) Extend java.lang.Runnable and override start(); (3) Implement java.lang.Thread and implement run(); (4) Implement java.lang.Runnable and implement the run() method; (5) Implement java.lang.Thread and implement start().Concept / Approach:Runnable is an interface whose single method, run(), contains the task body. Thread is a concrete class with start(), which arranges to execute run() on a new thread. You never “implement Thread”; you can extend it. start() should not be overridden just to run work; its job is to create the new thread and then invoke run().Step-by-Step Solution:(1) Extend Thread and override run(): valid. Start by calling new Subclass().start().(2) Extend Runnable and override start(): invalid; Runnable is an interface, cannot be “extended,” and it has no start().(3) Implement Thread and implement run(): invalid; Thread is a class, not an interface.(4) Implement Runnable and implement run(): valid; pass the Runnable to new Thread(r).start().(5) Implement Thread and implement start(): invalid for the same reason as (3).Verification / Alternative check:Write two minimal examples: class T extends Thread { public void run(){...} } and class R implements Runnable { public void run(){...} }. In both cases, call start() on a Thread object to launch the task.Why Other Options Are Wrong:They misuse the distinction between classes and interfaces or override the wrong method.Common Pitfalls:Calling run() directly instead of start(); trying to “implement Thread”.Final Answer:1 and 4

Threads Questions

Questions

Practice smarter