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

What will be the output of the program? class Happy extends Thread  {      final StringBuffer sb1 = new StringBuffer();      final StringBuffer sb2 = new StringBuffer();       public static void main(String args[])      {          final Happy h = ne…

Accepted Answer

Can you guarantee the order in which threads are going to run? No you can't. So how do you know what the output will be? The output cannot be determined.

Question 17

What will be the output of the program? class MyThread extends Thread  {     public static void main(String [] args)      {         MyThread t = new MyThread(); /* Line 5 */         t.run();  /* Line 6 */     }      public void run()      {         …

Accepted Answer

Line 6 calls the run() method, so the run() method executes as a normal method should and it prints "1..2.." A is incorrect because line 5 is the proper way to create an object. B is incorrect because it is legal to call the run() method, even though this will not start a true thread of execution. The code after line 6 will not execute until the run() method is complete. D is incorrect because the for loop only does two iterations.

Question 18

What will be the output of the program? public class Test107 implements Runnable  {      private int x;      private int y;       public static void main(String args[])      {         Test107 that = new Test107();          (new Thread(that)).start()…

Accepted Answer

Both threads are operating on the same instance variables. Because the code is synchronized the first thread will complete before the second thread begins. Modify line 17 to print the thread names: System.out.println(Thread.currentThread().getName() + " x = " + x + ", y = " + y);

Question 19

What will be the output of the program? class MyThread extends Thread  {      MyThread() {}      MyThread(Runnable r) {super(r); }      public void run()      {          System.out.print("Inside Thread ");     }  }  class MyRunnable implements Runna…

Accepted Answer

If a Runnable object is passed to the Thread constructor, then the run method of the Thread class will invoke the run method of the Runnable object. In this case, however, the run method in the Thread class is overridden by the run method in MyThread class. Therefore the run() method in MyRunnable is never invoked. Both times, the run() method in MyThread is invoked instead.

Question 20

What will be the output of the program? class MyThread extends Thread  {     public static void main(String [] args)      {         MyThread t = new MyThread();         Thread x = new Thread(t);         x.start(); /* Line 7 */     }     public void …

Accepted Answer

The thread MyThread will start and loop three times (from 0 to 2). Option A is incorrect because the Thread class implements the Runnable interface; therefore, in line 7, Thread can take an object of type Thread as an argument in the constructor. Option B and C are incorrect because the variable i in the for loop starts with a value of 0 and ends with a value of 2.

Threads Questions