Thread Methods and Execution States in Java SE 25

These ten questions clarify static thread methods, thread startup, sleeping, synchronization, and the six states exposed by Thread.State.

1. Which common Thread methods are static, and which are instance methods?

   Answer: Sleep, yield, and currentThread are static. Start, join, interrupt, and isAlive are instance methods. Sleep and yield affect the currently executing thread, not the thread referenced by a variable used to write the call.

   Use Thread.sleep(100) rather than calling a static method through an instance expression. In contrast, worker.join() makes the caller wait for worker to terminate, and worker.interrupt() requests interruption of worker. Thread.interrupted is static and clears the current thread's interrupt status; isInterrupted queries an instance without clearing it.

2. Why must wait and notify be used while owning the same monitor?

   Answer: Ownership makes the state test, transition into waiting, and producer's update follow one coordination protocol. Otherwise a notification could fall between a waiter's unchecked observation and its attempt to wait. Java enforces ownership with IllegalMonitorStateException.

   These methods do not acquire the lock for you. Use a synchronized block on their target, or an instance synchronized method when the target is this. Always test the application condition in a loop. The monitor also supplies the memory-ordering relationship needed for one thread to observe another's protected writes.

3. When does a newly constructed Thread begin separate execution?

   Answer: Start schedules its task for execution. Constructing a Thread creates a NEW object but does not run the task. A builder's start operation combines creation and startup; its unstarted operation does not.

   Java SE 25 supports both platform and virtual threads. Both start at most once. There is no promise about exactly when the task begins relative to the caller's next instruction. Calling the Runnable's run method directly stays on the calling thread.




4. Does a sleeping thread retain its locks?

   Answer: Yes. It is a thread, not an arbitrary object, that sleeps. Thread.sleep does not release monitors the caller owns, nor does it unlock explicit locks. Other threads needing those locks may be unable to progress during the pause.

   Object.wait has different behavior: it temporarily releases only the monitor of its target object and reacquires it before returning. Do not substitute sleep for condition waiting. Static synchronized methods are also not a Java 17 invention; they are a longstanding language feature.

5. What are the six Thread.State values?

   Answer: NEW, RUNNABLE, BLOCKED, WAITING, TIMED_WAITING, and TERMINATED. RUNNABLE covers execution and eligibility to execute; Java has no separate RUNNING state. BLOCKED specifically concerns intrinsic monitor acquisition. Sleeping with a positive duration is one cause of TIMED_WAITING.

   import java.util.Arrays;
   public class StateNames {
       public static void main(String[] args) {
           System.out.println(Arrays.toString(Thread.State.values()));
       }
   }

   The output is [NEW, RUNNABLE, BLOCKED, WAITING, TIMED_WAITING, TERMINATED]. These are JVM states, not a direct operating-system state table. The older five-state teaching diagram is not the Thread.State API.

6. Can a terminated thread ever be restarted?

   Answer: No. Its Thread object remains a record of that execution and cannot return to NEW. Starting it again throws IllegalThreadStateException. A reference to the object may remain reachable long after the execution has ended.

   For more work, create a new thread or submit another task to an executor. Reusing a Runnable can be valid, but its mutable state needs a safe design if several executions share it. Task reuse and Thread lifecycle reuse are separate concepts.





7. Which state makes a thread eligible for execution?

   Answer: RUNNABLE. A runnable thread may be executing or waiting for execution resources. The scheduler determines when it receives processor time, and several threads can execute at once on different cores.

   Do not poll getState as a substitute for coordination: it is a transient monitoring snapshot. Even immediately after start, the observed state could already be waiting or terminated. Join, latches, and other synchronization mechanisms express actual completion or readiness requirements.

8. How can a method exclude other threads using the same object's lock?

   Answer: Declare an instance method synchronized, or place the critical region inside synchronized(this) or another shared monitor. Threads attempting to acquire that same monitor cannot own it concurrently. Intrinsic locking is reentrant, so the owner can call another method guarded by the same monitor.

   Unsynchronized methods are not automatically blocked, and synchronized methods on different instances use different monitors. Protect every access that participates in the shared invariant. The modifier is not a global prohibition on running the same method body.

9. What mechanisms can coordinate activity between threads?

   Answer: Object.wait, notify, and notifyAll provide low-level monitor coordination. Higher-level tools include BlockingQueue for handing off items, CountDownLatch for a one-time milestone, and Future for task completion and results. Choose the abstraction matching the dependency.

   Sleep and yield do not establish that dependency or publish shared writes by themselves. With monitor waiting, protect the condition with one lock, wait in a loop, and decide how interruption should end or propagate from the operation.





10. Does every Thread constructor require a Runnable?

    Answer: No. Thread has several constructors, including a no-argument constructor and overloads taking a Runnable and optional name or other configuration. A Thread with no target and no overridden run method has no application work to perform when started.

    Supplying a Runnable separates task logic from lifecycle control. In Java SE 25, thread builders are also available, especially for creating virtual threads. Constructing a Callable is not enough to pass it to a Thread(Runnable) constructor; submit result-producing Callable tasks to an appropriate executor.

References: Thread methods, Thread.State, and Concurrency utilities.