Question 1

In core Java concurrency, which three of the following are methods declared by java.lang.Object (select exactly three)?  notify()  notifyAll()  isInterrupted()  synchronized()  interrupt()  wait(long msecs)  sleep(long msecs)  yield()

Accepted Answer

Introduction / Context: Java’s concurrency model splits behavior between the foundational java.lang.Object class and the java.lang.Thread class. This question tests whether you can correctly identify which synchronization-related methods actually live on Object rather than Thread. Given Data / Assumptions: A list of eight APIs mixes Object methods, Thread methods, keywords, and unrelated calls. We must choose exactly three that are declared in java.lang.Object. Concept / Approach: In Java, intrinsic locking (monitors) is tied to every object instance. Consequently, the coordination primitives that manipulate an object’s monitor are instance methods on Object: wait() (and its overloads), notify(), and notifyAll(). Thread-scheduling helpers such as sleep() and yield() are static methods on Thread. Interruption APIs (interrupt(), isInterrupted()) also belong to Thread. The token synchronized is a language keyword, not a method. Step-by-Step Solution: Identify Object methods: notify() → yes (Object instance method).Identify Object methods: notifyAll() → yes (Object instance method).Identify Object methods: wait(long msecs) → yes (Object instance method; there are also wait() and wait(long,int)).Eliminate isInterrupted() → Thread instance method.Eliminate synchronized() → not a method; it is a keyword.Eliminate interrupt() → Thread instance method.Eliminate sleep(long) → Thread static method.Eliminate yield() → Thread static method. Verification / Alternative check: Consulting the Object API confirms the presence of wait/notify/notifyAll. Thread API holds sleep, yield, interrupt, and isInterrupted. Why Other Options Are Wrong: They point to Thread methods or a language keyword and are not declared on Object. Common Pitfalls: Assuming all concurrency helpers live on Thread; in fact, monitor control is on Object. Final Answer: 1, 2, 6

Question 2

Java threads — starting a thread that implements Runnable. Given: class X implements Runnable { public static void main(String args[]) { // Which line starts a new thread correctly? } public void run() {} }

Accepted Answer

Introduction / Context: There are two standard ways to create threads in Java: extend Thread, or implement Runnable and pass an instance to a Thread constructor. This question focuses on the Runnable approach and proper instantiation. Given Data / Assumptions: Class X implements Runnable and correctly defines run(). We need the exact code to start a new thread of execution. Concept / Approach: To start a thread using Runnable, you must: (1) create a Runnable object; (2) wrap it in a Thread by calling the appropriate constructor; (3) invoke start() on the Thread, not run(). Calling run() directly runs code on the current thread rather than creating a new one. Step-by-Step Solution: Create a Runnable: X run = new X();Create a Thread: Thread t = new Thread(run);Start the thread: t.start(); Verification / Alternative check: At runtime, t.start() transitions the new thread into the runnable state and schedules a call to run() on that thread. Directly calling run() would not create a separate thread. Why Other Options Are Wrong: new Thread(X) passes a Class literal, not a Runnable instance; t.start() is missing in some options; calling x.run() executes on the current thread and does not start a new one. Common Pitfalls: Forgetting to call start(); passing the class name rather than an instance; confusing run() with start(). Final Answer: X run = new X(); Thread t = new Thread(run); t.start();

Question 3

Threads — which three operations guarantee that the current thread will leave the running state? Choose exactly three: yield(), wait(), notify(), notifyAll(), sleep(1000), aLiveThread.join(), Thread.killThread()

Accepted Answer

Introduction / Context: Understanding which APIs cause the calling thread to stop running is essential for reasoning about scheduling and liveness. Some calls affect other threads, while others suspend the current one. Given Data / Assumptions: We must identify calls that force the current thread to leave the running state. Assume proper preconditions (e.g., monitor ownership when calling wait()). Concept / Approach: wait() suspends the current thread and releases the monitor; sleep(ms) suspends the current thread for at least the specified time; join() called on another live thread makes the current thread wait until that thread terminates. yield() only hints to the scheduler and does not guarantee leaving running. notify()/notifyAll() wake other waiting threads and do not block the caller. Thread.killThread() does not exist in Java. Step-by-Step Solution: wait() → current thread waits → guaranteed to stop running.sleep(1000) → current thread sleeps → guaranteed to stop running.aLiveThread.join() → current thread waits for target thread to die → guaranteed to stop running.yield() → advisory only, no guarantee.notify()/notifyAll() → affect others; caller continues.Thread.killThread() → non-existent. Verification / Alternative check: Javadoc confirms the blocking behavior for wait, sleep, and join. Why Other Options Are Wrong: They either do not block the current thread or are not real APIs. Common Pitfalls: Believing yield() guarantees descheduling; confusing the caller of notify() with the awakened thread. Final Answer: 2, 5 and 6

Question 4

Java Thread API — which two are valid constructors for java.lang.Thread?

Accepted Answer

Introduction / Context: The Thread class offers several constructors for supplying a target Runnable, a name, and an optional ThreadGroup. Recognizing valid signatures is a common certification topic. Given Data / Assumptions: We must identify exactly which listed constructor signatures exist in the JDK. Concept / Approach: Valid overloads include Thread(), Thread(Runnable), Thread(Runnable, String), Thread(ThreadGroup, Runnable), Thread(ThreadGroup, String), and Thread(ThreadGroup, Runnable, String), among others. There is no constructor that accepts an int priority, and the order of parameters matters for the ThreadGroup/Runnable variants. Step-by-Step Solution: Option 1: Thread(Runnable r, String name) → valid.Option 2: Thread() → valid.Option 3: Thread(int priority) → invalid (priority is set via setPriority()).Option 4: Thread(Runnable r, ThreadGroup g) → invalid ordering; valid form is Thread(ThreadGroup g, Runnable r).Option 5: Thread(Runnable r, int priority) → invalid; no such constructor. Verification / Alternative check: Javadoc for java.lang.Thread lists the available constructors and their parameter orders. Why Other Options Are Wrong: They either use unsupported parameter types or the wrong parameter order. Common Pitfalls: Confusing constructor signatures with setter methods like setPriority(); swapping Runnable and ThreadGroup positions. Final Answer: Thread(Runnable r, String name), Thread()

Question 5

Which of the following cannot directly cause a Java thread to stop executing (i.e., leave the running state) at the moment of the call?

Accepted Answer

Introduction / Context: Many APIs influence a thread’s execution state. Some block the current thread immediately; others merely request a change or affect different threads. Here we identify the call that does not directly deschedule the caller. Given Data / Assumptions: The question asks about direct, immediate effect on the current thread’s running state. Concept / Approach: setPriority() changes the scheduling priority but does not itself block or stop the caller. By contrast, wait() blocks the current thread, sleep() blocks the current thread, and I/O such as InputStream.read() often blocks until data is available. notify() affects waiting threads but does not block the caller; however, it also does not stop the caller. Step-by-Step Reasoning: setPriority() → adjusts scheduling metadata only → no immediate stop.wait() → caller releases monitor and blocks → immediate stop.sleep() → caller sleeps → immediate stop.read() → may block until data → likely stop.notify() → awakens others; caller continues executing. Verification / Alternative check: Javadoc behavior for the listed methods shows which ones are blocking versus non-blocking. Why Other Options Are Wrong: They represent blocking calls (wait/sleep/read) or do not answer the “cannot directly cause” aspect correctly. Common Pitfalls: Assuming priority changes force an immediate context switch; assuming notify() blocks the caller (it does not). Final Answer: Calling setPriority() on a Thread object

Question 6

Which two of the following methods are members of java.lang.Thread (not inherited from Object or declared elsewhere)?

Accepted Answer

Introduction / Context: Thread lifecycle methods are easy to confuse with Object’s monitor methods. This question tests your ability to distinguish Thread-specific APIs from Object’s synchronization primitives. Given Data / Assumptions: We must pick two methods that actually belong to java.lang.Thread. Concept / Approach: start() is a Thread method that registers the thread with the scheduler and ultimately invokes run() on a new call stack. run() is also a Thread method (and the single abstract method in Runnable). Conversely, wait() and notify() are Object methods, not Thread methods. There is no standard terminate() in Thread. Step-by-Step Solution: start() → yes, Thread method.run() → yes, Thread method (also declared in Runnable as public abstract).wait(), notify() → belong to Object.terminate() → nonexistent in the core API. Verification / Alternative check: Cross-check in Javadoc for java.lang.Thread and java.lang.Object. Why Other Options Are Wrong: They include Object methods or non-existent methods. Common Pitfalls: Thinking wait()/notify() are Thread utilities; they operate on an object’s monitor. Final Answer: start() and run()

Question 7

Thread lifecycle — which method actually registers a new thread with the scheduler and starts it?

Accepted Answer

Introduction / Context: Understanding the distinct roles of run() versus start() is essential for correct thread creation in Java. Given Data / Assumptions: You have a Thread instance or a Thread constructed with a Runnable target. You need to begin execution on a new call stack. Concept / Approach: start() transitions a Thread from the new state to the runnable state and asks the JVM to schedule it. The VM then invokes run() on the new thread. Calling run() directly executes synchronously on the current thread and does not involve the scheduler. Step-by-Step Solution: Create a Thread (or Runnable + Thread).Call start() → registers with scheduler.JVM calls run() on the new thread. Verification / Alternative check: Demonstrate using prints: calling run() executes on main thread; calling start() spawns a new thread. Why Other Options Are Wrong: run() does not start a thread; construct(), register(), and launch() are not Thread APIs. Common Pitfalls: Accidentally invoking run() and wondering why no parallelism occurs. Final Answer: start()

Question 8

Runnable contract — which method signature must a class provide to correctly implement java.lang.Runnable?

Accepted Answer

Introduction / Context: The Runnable interface defines the entry point executed by a Thread. Implementing classes must adhere to the exact method signature and visibility expected by the interface. Given Data / Assumptions: Interface declaration is public interface Runnable { public abstract void run(); } Implementers must not reduce visibility on implemented methods. Concept / Approach: Since interface methods are implicitly public abstract, an implementing method must be declared public. Omitting public (package-private) would reduce visibility and cause a compile-time error. Step-by-Step Solution: Required signature: public void run().Optional modifiers like @Override may be used but do not change the required visibility and signature. Verification / Alternative check: Try compiling a class with void run() (no public); the compiler reports that the method attempts to assign weaker access privileges than the interface method. Why Other Options Are Wrong: void run() (no public) has insufficient visibility; start() is a Thread method, not part of Runnable; overloads like run(int) do not satisfy the interface. Common Pitfalls: Forgetting to declare public or misspelling the signature. Final Answer: public void run()

Question 9

Which of the following will NOT directly cause the calling thread to stop executing at that moment?

Accepted Answer

Introduction / Context: Blocking versus non-blocking operations are central to thread behavior. Some APIs suspend the caller; others signal different threads and let the caller continue. Given Data / Assumptions: We focus on the immediate effect on the current (calling) thread. Assume correct monitor ownership for monitor methods. Concept / Approach: wait() and sleep() suspend the current thread. Blocking I/O (such as InputStream.read()) can also suspend the caller until data becomes available. In contrast, notify() (and notifyAll()) wake other waiting threads but do not block or stop the caller. Step-by-Step Reasoning: notify(): caller continues → does not directly stop.wait(): caller releases monitor and blocks → stops.sleep(): caller sleeps → stops.InputStream access: may block → stops until data arrives. Verification / Alternative check: Javadoc for Object and Thread confirms which calls are blocking or signaling. Why Other Options Are Wrong: They are either blocking calls by design or can block in common scenarios (I/O). Common Pitfalls: Assuming notify() transfers the lock or blocks the caller; it simply wakes others. Final Answer: notify()

Question 10

In Java, which type declares the monitor methods wait(), notify(), and notifyAll() that coordinate threads?

Accepted Answer

Introduction / Context: Java’s built-in monitor mechanism associates a lock with every object. The fundamental coordination methods are therefore defined where the lock lives: on java.lang.Object. Given Data / Assumptions: We are choosing the correct declaring type for wait(), notify(), and notifyAll(). Concept / Approach: Each Java object has a monitor. The methods that wait on or signal that monitor are instance methods of Object. Threads interact with these methods by synchronizing on the object whose monitor they are using. Thread provides lifecycle and scheduling methods (start, sleep, join, yield, interrupt) but does not declare wait/notify. Step-by-Step Solution: Check Object → declares wait(), wait(long), wait(long, int), notify(), and notifyAll().Check Thread → none of those methods are declared there.Check Runnable, Class, ThreadGroup → none declare these monitor methods. Verification / Alternative check: Review Javadoc for Object and Thread to confirm method ownership and usage patterns. Why Other Options Are Wrong: They are either interfaces or classes serving other purposes and do not contain the monitor APIs. Common Pitfalls: Assuming thread coordination methods belong to Thread; they are bound to the object whose monitor you use. Final Answer: Object

Question 11

In Java multithreading, which method contains the actual body of work executed by a Thread (i.e., the code that runs on the thread's stack when scheduled by the JVM scheduler)?

Accepted Answer

Introduction / Context: Understanding the lifecycle of a Java thread is essential for writing concurrent programs. A frequent confusion is between the method that starts a thread and the method that actually executes on the new thread. Given Data / Assumptions: A class extends Thread or implements Runnable. The thread lifecycle includes states such as New, Runnable, Running, Blocked/Waiting, and Terminated. The JVM scheduler invokes user code on a separate call stack when appropriate. Concept / Approach: The start() method asks the JVM to create a new thread of execution, whereas the run() method is the entry point for the work performed by that thread. The developer places the thread's body (business logic) inside run(). Step-by-Step Solution: 1) Override run() in a Thread subclass or provide a Runnable whose run() implements the task.2) Call start() on the Thread instance to transition from New to Runnable; the JVM will then invoke run() on the new thread.3) The code inside run() is what executes concurrently. Verification / Alternative check: Calling run() directly from the main thread executes synchronously (no new thread). Only start() spawns a new thread that then calls run(). Why Other Options Are Wrong: start() → starts the thread but doesn't contain the work. stop() → deprecated, dangerous; not the body. main() → process entry point, not a thread's body. Common Pitfalls: Beginners often call run() directly, mistakenly assuming it starts a new thread. Final Answer: run();

Question 12

Java concurrency: A thread A calls wait(2000) inside a synchronized method on object B. When does thread A become eligible (a candidate) to run again?

Accepted Answer

Introduction / Context: Timed waiting with wait(timeout) is a core synchronization mechanism in Java. Knowing precisely when a waiting thread can proceed is key to designing correct monitors. Given Data / Assumptions: Thread A executed wait(2000) while holding B’s monitor (inside synchronized code on B). Calling wait releases the monitor and suspends A. Other threads may call notify() or notifyAll() on B. Concept / Approach: With wait(timeout), a thread stops waiting when either it is notified or the timeout elapses. After that, it must re-acquire B’s monitor before resuming running. The question asks when it becomes a candidate for CPU time, which is upon notification or timeout expiration. Step-by-Step Solution: 1) A calls wait(2000) → releases monitor B and enters TIMED_WAITING.2) Either another thread calls notify/notifyAll on B, or 2 seconds pass.3) A transitions to BLOCKED (contending for B’s monitor) and, once it re-acquires B’s monitor, can run again. Verification / Alternative check: Even after notification/timeout, progress depends on re-acquiring B’s lock; however, eligibility begins at notify/timeout boundaries. Why Other Options Are Wrong: Option B over-emphasizes lock release as the trigger; the primary triggers are notify or timeout. Options C and D misstate sequencing and conditions. Common Pitfalls: Confusing “eligible to run” with “actively running.” Lock reacquisition is still required after notify/timeout. Final Answer: After thread A is notified, or after two seconds.

Question 13

In Java, which method is used to start a thread's execution on a new call stack?

Accepted Answer

Introduction / Context: Creating and starting threads correctly is foundational to Java concurrency. The main confusion is between start() and run(). Given Data / Assumptions: A thread has been created by extending Thread or by passing a Runnable to a Thread constructor. Concept / Approach: start() transitions a thread from New to Runnable so the JVM can schedule it. The JVM then calls run() on that new thread. Step-by-Step Solution: 1) Construct a Thread object (directly or with a Runnable).2) Call start() to ask the JVM to begin execution on a new call stack.3) The JVM invokes run() on that new thread. Verification / Alternative check: Directly invoking run() executes synchronously on the current thread; only start() creates a new thread of execution. Why Other Options Are Wrong: init() → applet lifecycle, not threads. run() → body of thread; does not start a new one when called directly. resume() → deprecated; not used to start threads. Common Pitfalls: Forgetting to call start() and expecting parallelism. Final Answer: start();

Question 14

Java threads: Which of the following will directly cause a thread to cease executing (stop running) at that moment?

Accepted Answer

Introduction / Context: Java threads change state based on specific primitives. Knowing which calls block the current thread is critical for correct synchronization. Given Data / Assumptions: The thread owns a monitor when calling wait(). We are comparing the immediate effect on the calling thread's execution. Concept / Approach: wait() immediately causes the current thread to release the monitor and enter the WAITING (or TIMED_WAITING with timeout) state. In effect, it stops the current thread from executing until notified/timeout. Step-by-Step Solution: 1) The calling thread is in synchronized code holding a monitor.2) wait() → releases the monitor and suspends the thread.3) Later, a notify/notifyAll or timeout can move the thread to contend for the monitor again. Verification / Alternative check: By contrast, notify() and notifyAll() affect other waiting threads, not the calling thread. Why Other Options Are Wrong: notify(), notifyAll() → do not block the caller; they wake others. Exiting synchronized code → simply releases the lock and continues running; it does not block or stop the thread. Common Pitfalls: Confusing wait() (blocking caller) with sleep() (also blocks caller but without monitor semantics) and with notify()/notifyAll() (do not block caller). Final Answer: wait()

Question 15

Which statement correctly creates a Java thread from a class that implements Runnable and starts it running?

Accepted Answer

Introduction / Context: There are two common ways to create threads in Java: extend Thread or implement Runnable. This question focuses on the Runnable approach. Given Data / Assumptions: MyRunnable implements Runnable and overrides run(). Concept / Approach: To execute a Runnable on a new thread, wrap the Runnable in a Thread and call start() on the Thread instance. Step-by-Step Solution: 1) Construct a Thread with the Runnable: new Thread(new MyRunnable()).2) Call start() to spawn the new thread; the JVM then calls run() on that thread. Verification / Alternative check: Calling run() directly executes on the current thread, not a new one. Why Other Options Are Wrong: Option A → invalid constructor call; Runnable is an interface, not a constructor parameter like that. Option B → calls run() directly on the new Thread object constructed with a type token (also invalid usage). Option D → Runnable has no start() method. Common Pitfalls: Confusing start() with run() and trying to call start() on a Runnable instead of a Thread. Final Answer: new Thread(new MyRunnable()).start();

Question 16

Java concurrency and synchronization scope: predict the output and determinism of this program.  class Happy extends Thread {  final StringBuffer sb1 = new StringBuffer();  final StringBuffer sb2 = new StringBuffer();   public static void main(Strin…

Accepted Answer

Introduction / Context: This question checks your understanding of Java threading, synchronization scopes, and why using synchronized(this) on different objects does not coordinate access across threads. It also touches on StringBuffer being thread-safe for individual operations but not making multi-object sequences atomic. Given Data / Assumptions: Two anonymous Thread instances mutate shared fields h.sb1 and h.sb2. Each thread uses synchronized(this) where this refers to the anonymous Thread object, not the shared Happy instance. Each thread appends to sb1 and sb2 and then prints them in different orders. Concept / Approach: Synchronization must use the same monitor to enforce mutual exclusion. Here, each synchronized block locks a different monitor (the respective Thread instance), so there is no inter-thread coordination. Although StringBuffer methods are synchronized, they only serialize access per buffer method call, not across the two-buffer sequence. Therefore, the order of appends and prints can interleave in many ways. Step-by-Step Solution: Thread-1: append A to sb1, B to sb2, then print sb1 and sb2.Thread-2: append D to sb1, C to sb2, then print sb2 and sb1.Because monitors differ, these four appends and four prints can interleave arbitrarily.Final contents will include A and D in sb1, B and C in sb2, but line order is not guaranteed. Verification / Alternative check: Replace synchronized(this) with synchronized(h) (or a dedicated common lock) to serialize both threads around the complete sequence; then you would see a predictable grouping of prints. Why Other Options Are Wrong: AB… fixed-line options assume a deterministic schedule which is not enforced. The code does compile; syntax and imports are fine. Common Pitfalls: Assuming synchronized anywhere implies global serialization; confusing StringBuffer’s internal synchronization with atomic multi-step logic; locking on the wrong monitor. Final Answer: Output is non-deterministic due to concurrent interleaving

Question 17

Java threads: calling run() directly vs starting a new thread.  class MyThread extends Thread {  public static void main(String[] args) {  MyThread t = new MyThread();  t.run();  }  public void run() {  for (int i = 1; i < 3; ++i) {  System.out.prin…

Accepted Answer

Introduction / Context: The distinction between Thread.start() and Thread.run() is fundamental in Java concurrency. start() creates a new thread of execution and then invokes run() on that new thread. Calling run() directly executes the method on the current thread (here, main), with no concurrency. Given Data / Assumptions: A class extends Thread and overrides run(). main creates MyThread and calls t.run() directly. The loop prints i from 1 to 2 inclusive. Concept / Approach: The loop bounds are i = 1; i < 3; ++i → values 1 and 2. Because run() is called like a normal method, it executes on the main thread and simply prints text; there is no second thread involved, but the output tokens are unaffected. Step-by-Step Solution: Instantiate MyThread.Invoke run() directly in main.Loop prints 1.. then 2..Program ends normally. Verification / Alternative check: If t.start() were used, the same text would print, but on another thread and with potential interleavings with other concurrent output. Why Other Options Are Wrong: Compilation errors do not exist in this snippet. 1..2..3.. would require i <= 3 or a different bound. “No output” contradicts the loop execution. Common Pitfalls: Confusing run() for start(); expecting new-thread behavior without calling start(). Final Answer: 1..2..

Question 18

Java synchronization on a shared Runnable instance: how will two threads print shared counters?  public class Test107 implements Runnable {  private int x; private int y;  public static void main(String[] args) {  Test107 that = new Test107();  (new…

Accepted Answer

Introduction / Context: This program examines how method-level synchronization affects the execution of two threads sharing the same Runnable instance. The key is understanding that synchronized instance methods lock on the receiver object (this), creating mutual exclusion across those threads. Given Data / Assumptions: Two Thread objects share the same Test107 instance as their target Runnable. run() is declared synchronized, so it locks on that shared Runnable. x and y are instance fields shared by both threads. Concept / Approach: Because both threads invoke a synchronized instance method on the same object, only one can enter run() at a time. The first thread to acquire the lock executes the whole for loop (10 iterations) and then releases the lock. The second thread then executes its entire loop. As a result, you see a block of ten ordered lines, followed by another block continuing the count. Step-by-Step Solution: Thread T1 acquires the lock on that, enters run().T1 increments x and y atomically with respect to T2 and prints 10 lines (x = 1..10).T1 exits run(), releases the lock.T2 acquires the lock, prints the next 10 lines (x = 11..20). Verification / Alternative check: Removing synchronized would allow interleaving and potentially inconsistent reads/writes on multiprocessor systems (though here only increments happen, divergence still could appear without atomicity). Why Other Options Are Wrong: Interleaving (option b) would occur only if run were not synchronized. Divergence (option d) suggests data races, which synchronization prevents. No compilation or deadlock issues exist. Common Pitfalls: Forgetting that synchronized on an instance locks that specific object; thinking each iteration releases the lock (it does not). Final Answer: One thread prints all 10 lines first, then the other (guaranteed)

Question 19

Thread vs Runnable target when subclass overrides run(): what prints?  class MyThread extends Thread {  MyThread() {}  MyThread(Runnable r) { super(r); }  public void run() { System.out.print("Inside Thread "); } } class MyRunnable implements Runnab…

Accepted Answer

Introduction / Context: A Thread can be constructed with a Runnable target. By default, Thread.run() delegates to the target’s run() if present. However, if you subclass Thread and override run(), your override takes precedence and does not automatically call the target’s run(). Given Data / Assumptions: MyThread extends Thread and overrides run() to print “Inside Thread ”. One MyThread is created with no target; another is created with a MyRunnable target that prints “ Inside Runnable”. Neither override calls super.run(). Concept / Approach: Because MyThread.run() overrides the inherited behavior, the Runnable target’s run() is never invoked in either case (unless explicitly called). Therefore, both started threads execute MyThread.run(), printing the same message twice. Step-by-Step Solution: First start: executes MyThread.run() → prints “Inside Thread ”.Second start with Runnable target: still executes MyThread.run() → prints “Inside Thread ” again.Combined output contains two “Inside Thread ” tokens (order may vary due to scheduling). Verification / Alternative check: To invoke the target’s run(), remove the override or call super.run() inside MyThread.run(); the second thread would then print the Runnable’s text. Why Other Options Are Wrong: “Inside Thread Inside Runnable” would require Thread.run() to be used (or super.run() called). No syntax or runtime errors exist. Common Pitfalls: Assuming Thread always delegates to its target; forgetting that subclass overrides replace the delegation unless they call super.run(). Final Answer: Prints "Inside Thread Inside Thread"

Question 20

Wrapping a Thread around a Thread (as a Runnable): what does this program print?  class MyThread extends Thread {  public static void main(String[] args) {  MyThread t = new MyThread();  Thread x = new Thread(t);  x.start();  }  public void run() { …

Accepted Answer

Introduction / Context: A Thread can take any Runnable, and Thread itself implements Runnable. If you pass a Thread (that overrides run()) as the target to another Thread, the outer Thread will invoke the target’s run() just like any Runnable. This is legal though unusual. Given Data / Assumptions: Class MyThread extends Thread and overrides run() to print i from 0 to 2. main constructs MyThread t, then constructs a new Thread x with t as its Runnable target, and starts x. Concept / Approach: Starting x results in x’s internal run() delegating to the target Runnable’s run(), which is t.run(). Therefore, the overridden run() in MyThread executes on thread x and prints 0..1..2.. Step-by-Step Solution: Create t (a Thread subclass) — not started directly.Create x = new Thread(t).Call x.start() → new thread calls t.run().Loop prints 0.. 1.. 2.. Verification / Alternative check: If main had called t.start() instead, you would still see 0..1..2.. (on a different thread) and possibly two sets if both were started. Why Other Options Are Wrong: Bounds do not produce 3..; loop ends at i < 3. No compilation problems are present. Common Pitfalls: Assuming a Thread cannot be used as a Runnable target; expecting an exception or double printing. Final Answer: 0..1..2..

Threads Questions