386 Java Developer Interview Questions & Answers

Generics let me write a class, interface, or method that works with different reference types while the compiler checks the chosen type. For example, List<String> accepts strings and returns strings, so I do not need an unsafe cast. Generics make code reusable, make APIs clearer, and catch many type errors before the program runs. Java implements most generic typing through erasure, so parameterized types usually do not remain distinct runtime types.

Generics let one piece of Java code work safely with different kinds of objects. The caller chooses what kind of object the code should hold, return, or process. The compiler then checks that the code uses that kind consistently. This prevents many mistakes before the program starts. It also removes many manual conversions when values are read from collections. Generics are useful when the same behavior should work for customers, orders, messages, or other object types without copying the implementation for every type.

1. Should I explain generic classes, generic methods, or both?
2. Should I cover bounds and wildcards?
3. Should I explain type erasure and runtime limitations?

A generic declaration uses a type parameter as a placeholder for a reference type. For example, Box<T> declares T as the type stored by the box. Box<String> stores and returns a String. Box<Integer> uses the same class with Integer. The compiler checks each use, so the code remains reusable without losing type safety.

Generics are checked mainly during compilation. The compiler rejects adding an Integer to a List<String>. It also knows that reading from that list returns a String, so an explicit cast is unnecessary.

A bound restricts which types are accepted. The declaration <T extends Number> accepts Number and its subtypes. Wildcards make method parameters more flexible. List<? extends Number> is useful when a method reads values as Number. List<? super Integer> is useful when a method adds Integer values. List<?> represents a list whose exact element type is unknown.

Java generic types are invariant. List<Integer> is not a subtype of List<Number>, even though Integer is a subtype of Number. Allowing that assignment would make unsafe writes possible.

Java implements generics mainly with type erasure. The compiler verifies type arguments and then erases most of them from the generated runtime representation. It can insert casts and create bridge methods when needed to preserve type behavior. Because of erasure, code cannot use new T(), T.class, new T[10], or instanceof List<String>. Primitive types cannot be type arguments, so wrapper types such as Integer are required.

Generics themselves normally add little runtime or memory cost because objects do not usually store separate metadata for each type argument. Inserted casts and bridge methods have negligible cost in ordinary code. Using wrapper types for primitive values can cause boxing, object allocation, and additional memory use. In production, generics are common in collections, repositories, result wrappers, event handlers, and reusable service APIs.

A common mistake is assuming that List<Integer> can be assigned to List<Number>. Generic types are invariant, so that assignment is not allowed. Another mistake is using raw types such as List instead of List<String>. Raw types remove useful compiler checks and can lead to ClassCastException at runtime. Candidates also assume that List<? extends Number> safely accepts Number values. The exact element type is unknown, so adding any non null value is not type safe. Other mistakes include expecting all generic type arguments to be available at runtime, trying to use primitive type arguments, creating new T(), creating arrays of T, or testing instanceof with a parameterized type.

Start with the practical benefit. Say that generics provide reusable code with compile time type safety and fewer casts. Give a simple List<String> or Box<T> example. Then explain invariance, bounds, wildcards, and type erasure as the main rules and limitations. Connect each rule to how it prevents unsafe reads or writes.

A lambda expression is a concise way to provide the behavior required by a functional interface. I write parameters, an arrow, and a body instead of declaring a separate class. Java uses the target functional interface to infer the parameter and return types. Lambdas are useful for callbacks, collection operations, event handling, and task submission, but I keep them small and avoid depending on their object identity or allocation behavior.

A lambda expression lets a Java program pass a small action to another method without declaring a separate named class. It is useful when code needs one clear action, such as comparing names, processing every item, testing a value, or running a task. The shorter form removes repeated class setup and keeps simple behavior near the place where it is used. To use it correctly, we must know what information the action receives, what result it returns, and which interface describes that action.

1. Which functional interface should the lambda implement?
2. Does the lambda need to capture any value from the surrounding method?
3. Would a method reference or named method make the behavior clearer?

A lambda expression provides an implementation of the single abstract method of a functional interface. A functional interface has one abstract method after methods matching public methods of Object are excluded. It may also contain default, static, or private methods. Common examples are Runnable, Comparator, Predicate, Function, and Consumer.

The main syntax is (parameters) -> expression or (parameters) -> { statements; }. For example, name -> name.length() receives a name and returns its length. A lambda needs a target type. The target functional interface tells Java the expected parameter types, return type, and allowed checked exceptions. Java can often infer the parameter types from that context.

A lambda may capture a local variable from its surrounding method only when that variable is final or effectively final. Effectively final means the variable is assigned once and is not reassigned. The captured value is the value available when the lambda is created. A lambda may access fields and may change a captured mutable object's contents, but shared mutation can reduce clarity and create thread safety problems.

Lambdas are commonly used with collection methods, streams, callbacks, executors, and event handlers. A method reference such as System.out::println can be clearer when the lambda only calls an existing method.

Lambdas should remain small and focused. Complex conditions, many side effects, or extensive exception handling usually belong in a named method. Code must not rely on lambda object identity because Java does not guarantee whether a lambda instance is reused or newly created. Runtime allocation and optimization are implementation details, so performance and memory use should be measured when they matter.

Common mistakes include assuming any interface can be used as a lambda target, forgetting that the target must be a functional interface, and writing parameter or return types that do not match its abstract method. Candidates may also try to reassign a captured local variable, confuse changing an object's contents with reassigning the local reference, or assume a lambda is identical to an anonymous class in every detail. Other mistakes include depending on lambda object identity, hiding important side effects, ignoring checked exception rules, and using large lambdas that are difficult to read or test.

Begin by saying that a lambda supplies the single abstract method of a functional interface. Show the parameter, arrow, and body syntax. Then mention target type inference, effectively final local variable capture, one practical use, and the rule that complex behavior should usually move into a named method.

The Stream API is a JDK feature introduced in Java 8 for processing sequences of values through a pipeline. A stream reads elements from a source, applies lazy intermediate operations such as filter and map, and begins processing when a terminal operation such as collect, count, or reduce runs. A stream does not store data, and this kind of pipeline does not change the source collection unless the code performs explicit side effects. I use streams when they make data processing clear and avoid them when a loop expresses complex control flow more clearly.

The Stream API gives Java 8 a clear way to process values from a collection without writing every loop by hand. A developer describes the steps, such as keeping some items, changing them, sorting them, and collecting the result. Java passes the values through those steps when a final result is requested. The stream does not hold its own permanent data, and the original collection is not changed by this example. This approach is useful when the processing steps are simple and easy to read.

1. Must the result preserve the source encounter order?
2. Can the source contain null values?
3. Is the source held in memory or backed by a resource that must be closed?
4. Is parallel processing being considered, and has it been measured?

A stream is a sequence of elements for processing. It is not a collection and does not store elements. It reads them from a source such as a List, an array, or a file.

A stream pipeline contains a source, zero or more intermediate operations, and a terminal operation. Intermediate operations such as filter, map, distinct, and sorted return another stream. They are lazy, which means they normally do no element processing until a terminal operation starts the pipeline. Terminal operations include collect, count, reduce, and forEach.

In the example, filter keeps names with at least five characters. map creates uppercase strings. sorted places them in natural order. collect starts the pipeline and creates the result list. The output is [ALICE, CHARLIE, DAVID], and the source list remains unchanged.

A stream is single use. After a terminal operation, it must not be used again. Stream operations should also avoid modifying shared mutable data. Such side effects make pipelines difficult to understand and can become unsafe during parallel execution.

Streams work well for filtering, transformation, grouping, sorting, and aggregation. A loop is often clearer for complex state changes, checked exception handling, or control flow that needs break or continue. Parallel streams are not automatically faster because task splitting, coordination, ordering, and result combination add overhead.

Common mistakes include treating a stream as stored data, assuming intermediate operations run immediately, trying to reuse a stream after a terminal operation, and expecting the source collection to change automatically. Other mistakes include putting shared mutable side effects inside map, filter, or forEach, assuming parallelStream always improves performance, ignoring encounter order, and forgetting to close a resource backed stream. Developers should also not assume that Collectors.toList returns a specific list implementation or guarantees mutability.

Explain the pipeline in this order: source, lazy intermediate operations, terminal operation, and result. State that a stream does not store elements, is single use, and should normally avoid shared mutable side effects. Then mention one situation where a loop is clearer and explain why parallel execution must be measured instead of assumed to be faster.

Optional is used mainly as a method return type when a result may be present or absent. It makes the missing case visible in the API instead of returning an unexpected null. I normally handle it with methods such as map, orElse, orElseGet, orElseThrow, and ifPresent. I avoid calling get unless presence has already been proved, and I do not use Optional for every nullable value.

Optional is a Java container that tells the caller that a result may exist or may be missing. It helps a method communicate that absence clearly instead of quietly returning null. The caller must then decide what to do, such as use another value, run different work, or report an error. This can reduce bugs caused by forgotten null checks. Optional is most useful when no result is a normal outcome. It should not replace every value that might be missing, because that can make code harder to read.

1. Is a missing result expected, or should it be treated as an error?
2. Would an empty collection communicate the result better than Optional?
3. Does creating the fallback value require expensive work or cause side effects?

Optional<T> is a final JDK class that represents either an empty result or one non null value of type T. It is mainly intended for method return types when a method may legitimately have no result. For example, findUserEmail can return Optional<String> when an unknown user has no email result.

Use Optional.of when the supplied value must not be null. It throws NullPointerException when given null. Use Optional.ofNullable when the value may be null. It returns an empty Optional for null. Use Optional.empty to represent absence directly.

The caller can use map to transform a present value, ifPresent to perform an action, orElse to provide an already available fallback, orElseGet to create a fallback only when the Optional is empty, and orElseThrow when absence should become an exception. The fallback expression passed to orElse is evaluated before orElse runs, even when a value is present. The supplier passed to orElseGet runs only when the Optional is empty.

Calling get on an empty Optional throws NoSuchElementException. Safer operations usually make the empty case clearer. Optional should not normally wrap a collection merely to represent no elements, because an empty collection already communicates that state. It is also usually unnecessary for method parameters, object fields, or collection elements unless an API has a specific reason.

A present Optional commonly requires a wrapper object, although the JVM may remove some allocations through optimization. Code must not depend on Optional object identity, compare Optional instances with reference equality, or use them as synchronization locks because Optional is a value based class.

Common mistakes include returning null from a method declared to return Optional, calling Optional.of with a value that may be null, and calling get without proving that a value is present. Another mistake is using orElse for expensive fallback work and assuming that the work runs only when the Optional is empty. Developers may also use Optional for fields, parameters, collection elements, or empty collections without a clear API benefit. Code should not compare Optional objects with reference equality or rely on Optional.empty returning the same object instance.

Start by saying that Optional makes an expected missing return value explicit. Then explain present and empty states, show one safe handling method, mention that orElse evaluates its fallback eagerly while orElseGet evaluates its supplier only when needed, and finish by explaining that Optional should not replace every nullable value.

Serialization converts a Java object and the reachable serializable objects it refers to into bytes. Deserialization reads those bytes and rebuilds the object graph. Java provides ObjectOutputStream and ObjectInputStream for this when the classes implement Serializable. I would use native Java serialization only for trusted and controlled Java data. I would not use it for untrusted input, public APIs, or long term shared data because of security and compatibility risks.

Serialization means turning the saved information inside an object into bytes. The bytes can be written to a file, stored for a short time, or sent somewhere else. Deserialization performs the reverse action. It reads the bytes and rebuilds the saved objects and their connections. In Java, only supported objects can be saved this way. The process needs care because changing a class may make older saved information incompatible. Reading data from an unsafe source can also cause harmful code to run during restoration.

1. Can an outside user provide the serialized data?
2. Must old saved data work after future class changes?
3. Is native Java serialization required, or can we use another data format?

Native Java serialization uses the Serializable marker interface. It has no methods. It tells ObjectOutputStream that objects of the class may be written. The stream saves instance field values and follows references to reachable objects. Every reachable object must also be serializable unless its field is marked transient. Static fields belong to the class rather than one object, so they are not saved as part of the object state.

The stream tracks objects it has already visited. This preserves shared references and allows cyclic object graphs to be written without endlessly following the same references.

Deserialization uses ObjectInputStream. It reads class information and field values, allocates objects, restores their state, and reconnects references. Constructors of serializable classes are not normally called during this process. The no argument constructor of the first nonserializable superclass is called. Restoration hooks such as readObject and readResolve may also run.

A serializable class should declare an explicit serialVersionUID. During deserialization, Java compares the saved value with the value in the current class. A mismatch causes InvalidClassException. Keeping the same value does not make every class change compatible. Changes to field types, inheritance, or custom restoration logic can still fail or restore incomplete state.

Use try with resources to close streams. Writing can throw IOException. Reading can throw IOException or ClassNotFoundException. Work and memory use grow with the number of objects visited and the number of bytes processed. Serialization keeps tracking information for visited objects. Deserialization allocates the restored objects, arrays, strings, and supporting data, so a large or hostile stream can consume significant memory.

Never deserialize untrusted bytes with unrestricted ObjectInputStream. When native serialization cannot be avoided, use trusted sources, strict class controls, ObjectInputFilter limits, size limits, and tests for old data. For public APIs, queues, databases, and long term storage, explicit formats such as JSON, Avro, or Protocol Buffers are usually easier to validate, version, and share.

Common mistakes include implementing Serializable only on the root class while a reachable object is not serializable, assuming transient fields keep their original values, relying on an automatically generated serialVersionUID, and changing a class without testing older serialized data. Developers may also expect serializable class constructors to run during restoration, assume serialization encrypts data, forget to close streams, cast the restored object to the wrong type, or expect static fields to be restored. The most serious mistake is deserializing untrusted bytes without strict filtering and limits.

Begin with the conversion in both directions. Then explain Serializable, ObjectOutputStream, ObjectInputStream, and the reachable object graph. Mention transient and static fields, serialVersionUID, constructor behavior, compatibility limits, memory allocation, and the danger of untrusted deserialization. Finish by explaining when an explicit data format is a better production choice.

I use Java native serialization only for trusted data and only when compatibility with that format is required. I declare an explicit serialVersionUID, store only necessary state, validate every restored value in readObject, and reject invalid state with InvalidObjectException. I also apply a strict ObjectInputFilter before reading. For public or untrusted data, I prefer an explicit format such as JSON or Protocol Buffers.

This question asks how to save an object in a controlled form and rebuild it later without accepting bad data or breaking older saved data. The class may change after the data is written. A field may be added, removed, or given a new meaning. The saved input may also be damaged or harmful. A safe design must decide what information is stored, how older information is read, what values are allowed, and which sources are trusted.

1. Must data written by older application versions still be readable?
2. Can the input come from users, files, messages, or another service?
3. Which fields are secrets, temporary values, or values that can be calculated again?

Java native serialization writes an object graph through ObjectOutputStream and restores it through ObjectInputStream. A participating class implements Serializable. Custom private writeObject and readObject methods let the class control this process.

Declare an explicit serialVersionUID. Java compares it with the value in the stream. A different value causes InvalidClassException. The same value is necessary for intended compatibility, but it does not make every class change safe. Adding a field is often compatible because old streams provide its default value. Changing a field type, changing the class hierarchy, or changing the meaning of stored data can still break behavior. When several stream versions must be supported, readObject can use GetField and explicit defaults.

Store only required state. Mark tokens, passwords, open resources, caches, and derived values as transient. In readObject, treat restored values as untrusted. Check null rules, size limits, ranges, and relationships between fields. Throw InvalidObjectException before the object is returned if any invariant fails. Constructors of Serializable classes are not run normally during restoration. The constructor of the first superclass that is not Serializable is run, so constructor validation alone is not enough.

Set a strict ObjectInputFilter before readObject. Limit classes, graph depth, reference count, array length, and stream size. This is defense in depth, not permission to read hostile data. Native deserialization can invoke class specific restoration behavior and build large graphs. Work and temporary memory generally grow with the number and size of restored objects. Shared references and cycles are preserved through stream handles, but very deep or very large graphs can still exhaust resources.

Use this approach for controlled internal compatibility or legacy data. Prefer an explicit external format for public interfaces and untrusted input.

Common mistakes are relying on an automatically calculated serialVersionUID, assuming the same serialVersionUID makes every class change compatible, writing secrets or live resources, trusting constructor validation, failing to validate cross field rules in readObject, allowing broad classes through ObjectInputFilter, and treating the filter as enough protection for hostile input.

Begin with the safety decision. Say that Java native deserialization is only for controlled data. Then explain serialVersionUID, minimal stored state, validation in readObject, strict filtering, compatibility tests, and when an explicit external format is the better choice.

Multithreading in Java means using multiple threads inside one Java process so different tasks can make progress independently. A thread is one path of execution. Threads in the same JVM can share heap objects, so shared mutable data needs careful coordination. I normally submit Runnable or Callable tasks to an executor instead of manually creating many platform threads. This makes execution management easier, but I still need to handle race conditions, visibility problems, deadlocks, interruption, and safe access to shared state.

Multithreading lets one Java application make progress on more than one task at the same time. Each task can follow its own execution path while still belonging to the same running application. This is useful when a program must serve many requests, wait for outside work, or perform background jobs. The important point is that these tasks can use some of the same data. If two tasks change that data without proper control, the result can be wrong or unpredictable. Java provides standard tools to create, manage, and coordinate this work safely.

1. Would you like me to focus on platform threads or also mention virtual threads?
2. Should I explain synchronization and shared state problems in more detail?

A thread is one path of execution inside a Java process. A Java application can have many threads. Each thread has its own execution state, such as its call stack, while threads in the same JVM can share objects stored on the heap.

This shared heap is useful because threads can work with the same application state, but it also creates risk. If two threads read and change the same mutable object without proper coordination, their operations can interfere. This can cause a race condition, where the result depends on timing.

There can also be a visibility problem. One thread may change a value, but another thread is not automatically guaranteed to observe that change correctly unless the program establishes the required Java Memory Model relationship. Java provides tools such as synchronized, volatile, locks, atomic classes, and concurrent collections for different coordination needs.

Runnable represents work that does not return a result. Callable can return a result and can throw checked exceptions. In production code, it is usually better to submit tasks to an ExecutorService instead of repeatedly creating platform threads yourself. An executor separates task submission from thread management and can control thread creation, reuse, queues, and shutdown.

Modern Java also supports virtual threads. They are useful when an application has many tasks that spend much of their time waiting, such as network or database operations. They can make high concurrency blocking code practical, but they do not make CPU intensive work faster and they do not remove the need to limit access to scarce resources.

Another important risk is deadlock, where threads wait indefinitely for resources held by each other. Good designs reduce shared mutable state, choose the correct coordination tool, limit concurrency where resources require it, handle interruption correctly, and shut executors down cleanly.

A common mistake is thinking that every thread has completely separate application memory. Threads have their own execution state, but threads in the same JVM can share heap objects. Another mistake is assuming that concurrent code is automatically safe because each thread follows its own path. Shared mutable data can still cause race conditions and visibility problems. Developers also sometimes create a new platform thread for every task instead of using an executor or another suitable concurrency model. Other mistakes include ignoring interruption, forgetting to shut down executors, holding locks for too long, acquiring multiple locks in inconsistent orders, assuming volatile makes a compound operation atomic, and assuming virtual threads make CPU intensive work faster.

Start by defining a thread as one execution path and multithreading as multiple threads making progress inside one Java process. Then explain the most important practical fact: threads in the same JVM can share heap objects. Connect that fact to race conditions and visibility. Finish by saying that Runnable or Callable represent work and that executors are normally preferred for managing task execution.

The practical difference is that transient affects standard Java object serialization, while volatile affects visibility and ordering between threads. A transient instance field is normally excluded when an object is serialized, so it has its default value after deserialization unless custom logic restores it. A volatile field makes writes visible to subsequent reads of that field and creates memory ordering guarantees. It does not make compound operations such as count plus plus atomic.

These words solve two separate problems. One controls whether a value is included when Java saves an object using its built in object saving mechanism. The other controls how workers running at the same time see changes to a shared value. The first can leave a field out of the saved object data. The second helps one worker see a value written by another worker. Neither word provides the behavior of the other, and each has limits that matter in real applications.

1. Is the application using standard Java object serialization or another storage format?
2. Will several threads read or update the field?
3. Is the shared operation a simple read or write, or does it contain several steps?

A transient field is declared with the transient modifier. During default Java object serialization, a transient instance field is not included in the serialized state. When the object is deserialized, that field receives its Java default value, such as null, zero, or false, unless custom deserialization logic restores another value.

Transient is useful for temporary caches, calculated values, environment specific objects, or values that should not be part of the standard serialized form. Static fields are already excluded because they belong to the class rather than an individual object, so marking a static field transient has no useful serialization effect.

Transient is not encryption, secure deletion, or a universal persistence rule. JSON libraries, database mappers, and frameworks may apply their own rules and may still include the field unless configured otherwise.

A volatile field is used for shared state between threads. A write to a volatile field is visible to subsequent reads of that field. It also creates ordering guarantees under the Java Memory Model. Actions performed before the volatile write become visible to a thread after it performs the corresponding volatile read.

A read or write of the volatile field itself is atomic. However, a compound operation such as count plus plus is not atomic because it performs a read, calculation, and write. Multiple threads can still lose updates. Use synchronization, a lock, or an atomic class when several steps must act as one operation.

A volatile reference only protects access to the reference value. It does not automatically make the referenced object or array elements thread safe. A field can be both transient and volatile because the modifiers solve independent problems. Neither modifier creates an additional object allocation or changes the field type. Volatile access may cost more than ordinary access because it limits some optimizations and requires memory coordination.

A common mistake is saying that transient prevents every serializer, framework, or database tool from storing a field. Its defined effect applies to standard Java object serialization, while other tools use their own rules. Another mistake is treating transient as encryption or secure deletion. It provides neither. Candidates also assume that volatile makes count plus plus safe. Volatile provides visibility and ordering, but it does not make a compound operation atomic. Another error is assuming that a volatile object or array reference makes the referenced object or its elements thread safe. It only gives volatile behavior to the reference field itself.

Start by separating the two concerns. Say that transient affects standard Java object serialization and volatile affects visibility and ordering between threads. Then state one important limitation for each. Transient does not control every persistence tool, and volatile does not make compound operations atomic.

A synchronized method locks for the entire method, while a synchronized block locks only the selected statements. An instance synchronized method locks the current object. A static synchronized method locks the Class object. A synchronized block lets me choose both the protected section and the lock object. I use a method when the whole operation needs one lock, and a block when a smaller critical section is safe and can reduce contention.

Both forms prevent several workers from entering protected work at the same time when they use the same guard object. The main difference is how much work is protected and which object controls entry. Protecting a whole operation is simple and harder to misuse. Protecting only the sensitive part may let other work continue sooner, but the boundary must be chosen carefully. The decision matters when several requests or background tasks update the same information.

1. Is the shared state stored in each instance or shared by the whole class?
2. Must the complete operation happen as one indivisible action?
3. Can slow calculations or external calls safely remain outside the protected section?

A synchronized instance method acquires the monitor of the current object before entering the method body and releases it when the method exits, including when an exception is thrown. Its locking effect is the same as placing the complete body inside synchronized (this). Calls on the same instance contend for the same monitor. Calls on different instances use different monitors and may run at the same time.

A static synchronized method acquires the monitor of the Class object that declares the method. It protects class level state only when every related access uses that same Class monitor.

A synchronized block acquires the monitor of the object named in its expression. It can protect only the statements that must be atomic, and it can use a private final lock object instead of this. The expression must produce a nonnull reference. Replacing the lock reference or using different locks for the same state breaks the protection.

Both forms provide the same monitor based mutual exclusion and Java Memory Model visibility guarantees when threads release and later acquire the same monitor. A smaller block can reduce waiting, but only when code moved outside the block does not depend on the protected state or split one required atomic operation.

The language does not guarantee fairness, so a waiting thread is not guaranteed to acquire the monitor next. A private lock adds one lock object per containing instance, while a synchronized method needs no separate application lock object. On Java 21, synchronized code can pin a virtual thread to its carrier in important cases. Starting with JDK 24, JEP 491 removes nearly all pinning caused by synchronized methods and blocks, although native code and remaining pinning cases still require care.

A common mistake is saying that synchronized methods and synchronized blocks use different locking mechanisms. Both use Java monitors. Another mistake is claiming that every synchronized method locks the whole class. An instance method locks the current object, while a static method locks the declaring Class object. Other errors include protecting writes but not reads, using different lock objects for the same state, locking on a mutable reference, locking on a public object that outside code can also use, or shrinking a block so much that one required atomic operation becomes several separate operations. Holding a monitor during slow input, output, network, or database work can also create unnecessary contention.

Explain three points in order: which object is locked, how much code is protected, and when the smaller scope is still correct. State that both forms have the same monitor and visibility guarantees when they use the same monitor.

wait, notify, and notifyAll coordinate threads that use the same object monitor. A thread calls wait when a shared condition is not ready. wait releases that monitor and pauses the thread. Another thread changes the shared state while holding the same monitor and calls notify or notifyAll. notify selects one waiting thread, while notifyAll gives every waiting thread a chance to continue. I always test the condition in a while loop because waking does not guarantee that the condition is true.

These methods help several workers take turns when they depend on the same shared information. One worker may need to stop because the information is not ready. It can wait and allow another worker to update that information. After another worker makes the required change, it can signal that work may continue. One signal chooses one waiting worker. The other signal gives every waiting worker a chance to check whether it can continue. This is useful when progress depends on a shared condition.

1. Can different conditions use the same shared object?
2. Should one waiting thread continue, or should every waiting thread check again?
3. Should waiting have a time limit?

wait, notify, and notifyAll are final methods inherited from Object. They coordinate threads through the monitor associated with an object. A thread must own that object monitor before calling any of these methods, normally by entering a synchronized method or synchronized block that uses the same object. Otherwise, Java throws IllegalMonitorStateException.

A thread calls wait when a required condition is false. wait places the thread in the waiting set for that monitor and releases only that object monitor. This allows another thread to acquire the monitor and change the shared state. The waiting thread keeps any other locks that it already owns, which can create deadlock risks if the locking design is poor.

notify selects one unspecified thread from that monitor's waiting set. notifyAll signals every thread in that waiting set. A signaled thread does not run immediately. It must first reacquire the same monitor. Threads that were signaled by notifyAll compete for the monitor and continue one at a time.

The shared condition must be checked in a while loop. A thread may wake without a useful notification. Another thread may also change or consume the shared state before the awakened thread reacquires the monitor. A notification is not stored for a thread that starts waiting later.

wait can also use a timeout. It throws InterruptedException if the waiting thread is interrupted. Code should normally restore the interrupt status or propagate the exception according to the method contract.

The state check, state change, wait call, and signal must use the same monitor. Releasing and later reacquiring that monitor also provides the memory visibility needed for the waiting thread to see synchronized state changes. For most production code, BlockingQueue, CountDownLatch, Semaphore, or Lock with Condition is clearer and safer.

Common mistakes include calling wait, notify, or notifyAll without owning the target object's monitor, which causes IllegalMonitorStateException. Another mistake is synchronizing on one object but calling wait or notify on another. Using if instead of while is unsafe because a thread may wake when its condition is still false. Developers also confuse wait with Thread.sleep. wait releases the target object monitor, while Thread.sleep does not release any monitor. Another mistake is assuming notify selects the oldest or most suitable waiter. Java gives no such guarantee. Calling notify before a thread starts waiting does not save the notification. Ignoring InterruptedException can also prevent cancellation and clean shutdown. Holding unrelated locks while waiting may cause deadlock because wait releases only the monitor on which it is called.

Explain the protocol in order. The thread owns the monitor, checks a shared condition in a while loop, calls wait and releases that monitor, then another thread changes the shared state and signals while holding the same monitor. Mention that notify selects one unspecified waiter, notifyAll signals all waiters, and every awakened thread must reacquire the monitor and check the condition again. Also mention interruption and higher level concurrency utilities.