Java SE 25 Interview Questions: Priorities and Synchronization

Thread priorities are scheduling hints. Correct shared-state access depends on synchronization and memory visibility, not on which thread you expect to run first.

1. What priority does a newly created thread have?

   Answer: A platform thread ordinarily inherits its creator's priority, subject to the maximum permitted by its thread group. Thread builders can also configure platform-thread priority explicitly. Do not assume every newly created platform thread necessarily has priority 5.

   Virtual threads differ: their priority is always Thread.NORM_PRIORITY, which is 5. Their priority is not a control for ordering tasks. These Java values should also not be confused with an operating system's internal scheduling classifications or dynamic decisions.

2. How can a thread's priority be set?

   Answer: Use thread.setPriority(value), with a value from Thread.MIN_PRIORITY through Thread.MAX_PRIORITY, inclusive. Out-of-range values throw IllegalArgumentException. A platform thread's effective Java priority is limited by its thread group's maximum.

   A valid setPriority call on a virtual thread is ignored; its priority stays 5. Platform-thread builders also offer a priority setting before startup. None of these operations guarantees that a higher-priority thread runs before, or finishes before, another thread. Use an explicit dependency when execution order is required.

3. What are Thread.MIN_PRIORITY, NORM_PRIORITY, and MAX_PRIORITY?

   Answer: They are public static final integer fields, not methods. Their values are 1, 5, and 10 respectively. Use the constants rather than unexplained numeric literals when a platform priority setting is justified.

   public class PriorityValues {
       public static void main(String[] args) {
           System.out.println(Thread.MIN_PRIORITY + " "
                   + Thread.NORM_PRIORITY + " " + Thread.MAX_PRIORITY);
           Thread virtual = Thread.ofVirtual().unstarted(() -> {});
           virtual.setPriority(Thread.MAX_PRIORITY);
           System.out.println(virtual.getPriority());
       }
   }

   The output is 1 5 10, then 5. No thread needs to be started to inspect these values. The example illustrates the virtual-thread rule rather than predicting any scheduler behavior.

4. Does Thread.yield move the caller to the back of a queue?

   Answer: Java makes no such guarantee. Yield suggests that the current thread is willing to give up its current processor use, but the scheduler may ignore the hint or schedule the same thread again. There is no portable promise about a queue position, equal-priority handoff, or fairness.

   Yield does not release monitors or establish inter-thread visibility by itself. It is unsuitable for waiting for a flag written without proper synchronization. Replace such busy waiting with a suitable blocking or signaling mechanism rather than adding yield calls to hide a race.

5. Can an application assume the scheduler changes priorities to ensure fairness?

   Answer: No. The Java API does not promise an aging or priority-adjustment algorithm that will make every scheduling assumption safe. A platform's internal scheduling decisions are distinct from the Java priority returned by getPriority.

   Explicit priority settings and thread-group limits affect platform-thread priority; virtual threads retain priority 5. Neither the claim that “the JVM will fix unfairness by changing priorities” nor a blanket prediction about every operating system is a useful correctness rule. Avoid starvation through application design and documented coordination behavior.

6. How can shared mutable data be protected from race conditions?

   Answer: Identify the shared state and the operations that must appear indivisible. Protect all relevant accesses with a consistent lock, use an appropriate atomic or concurrent abstraction, or avoid sharing through immutability or thread confinement. Declaring a field private does not itself make access thread-safe.

   For a simple counter, AtomicInteger.incrementAndGet performs an atomic update; a volatile int followed by count++ does not. For a multi-field invariant, separate atomic variables may still be insufficient because the fields must change together. ConcurrentHashMap provides atomic per-key operations, but an arbitrary sequence of map calls is not automatically one transaction.

   Visibility matters as well as exclusion. Readers need a documented happens-before relationship with writers. A lock used by writers alone does not automatically protect unsynchronized readers of the same mutable state.

7. What does synchronized guarantee?

   Answer: It acquires an object's intrinsic monitor before entering a protected region and releases it on exit. Only one thread at a time can own a particular monitor, although the owning thread can acquire it repeatedly. Unlocking a monitor happens-before a subsequent lock of that same monitor, providing memory visibility.

   The guarantee is tied to the monitor identity, not to the word synchronized wherever it appears. Code locking different objects can run concurrently. Unsynchronized code is not automatically blocked from touching the object, so every access participating in a protected invariant must follow a compatible policy.

8. Which lock does a synchronized instance method acquire?

   Answer: It acquires the intrinsic monitor of its receiver, this. Two synchronized instance methods invoked on the same object therefore coordinate through the same monitor. The corresponding methods on two different instances acquire different monitors.

   This does not automatically protect static fields shared by all instances. A static synchronized method instead locks the Class object for the declaring class. Choose the lock according to which state is shared and ensure all accesses use the same policy; method modifiers alone do not establish the whole design.

9. How many intrinsic monitor locks does an object have?

   Answer: Every object has one associated intrinsic monitor in Java's synchronization model. Different synchronized methods on that object do not each receive a separate monitor. Intrinsic locking is reentrant: the owner can enter another region guarded by the same monitor without blocking itself.

   A class can also hold references to separate lock objects, or use explicit Lock implementations, to coordinate different state. Those are different locks with different identities. If a design uses multiple locks, establish a consistent acquisition order and consider whether splitting protection could break an invariant or introduce deadlock.

10. When is an intrinsic monitor released?

    Answer: Leaving a synchronized block or method releases the acquisition, whether the exit is normal or caused by an exception. With reentrant locking, an outer acquisition remains held until that outer region exits. Object.wait temporarily releases all acquisitions of its target monitor and restores them before returning.

    Sleep and yield do not release held monitors. Explicit locks follow a different programming pattern: after a successful Lock.lock call, normally put unlock in a finally block. Unlike synchronized, an explicit lock is not automatically released just because execution leaves a method.

References: Thread priorities and yield, Threads, locks, and memory ordering, and Explicit locks.