Question 1

What are the differences between JVM, JRE, and JDK?

Accepted Answer

The JVM, JRE, and JDK are nested components of the Java platform, each building on the previous. Understanding their boundaries is essential for knowing what to install in different contexts.

The JVM (Java Virtual Machine) is the runtime engine that executes Java bytecode. It is an abstract specification implemented by vendors (Oracle HotSpot, OpenJ9, GraalVM). The JVM handles bytecode interpretation and JIT (Just-In-Time) compilation to native machine code, memory management and garbage collection, thread scheduling, and security sandboxing. Crucially, the JVM is platform-specific — there is a different JVM binary for Windows, Linux, and macOS — but it presents a uniform interface to Java bytecode, which is platform-neutral.

The JRE (Java Runtime Environment) packages the JVM together with the standard class libraries (java.lang, java.util, java.io, etc.) and supporting files needed to run compiled Java applications. If you only need to run a Java program — not develop one — the JRE is sufficient. Note: since Java 11, Oracle no longer distributes a standalone JRE; the JDK ships with a full runtime, and `jlink` can create minimal custom runtimes.

The JDK (Java Development Kit) is the full developer toolchain. It includes everything in the JRE plus: the Java compiler (`javac`), the archiver (`jar`), documentation generator (`javadoc`), debugger (`jdb`), and other development tools. You need the JDK to compile `.java` source files into `.class` bytecode and to build, package, and debug Java applications.

The relationship: JDK ⊃ JRE ⊃ JVM. In production deployments, you typically install only the JRE (or a JDK, now that they're merged) and ship pre-compiled JARs. On developer machines, you always need the JDK.

Question 2

Why is Java a platform-independent language?

Accepted Answer

Java's platform independence is summarized by the principle "Write Once, Run Anywhere" (WORA). The mechanism has two steps: compilation to an intermediate representation (bytecode), and execution of that bytecode by a platform-specific JVM.

When you compile a `.java` source file with `javac`, the output is `.class` files containing Java bytecode — a compact, binary instruction set designed not for any specific CPU architecture, but for the JVM. Bytecode is platform-neutral: the same `.class` file produced on Windows x86-64 will run on Linux ARM64 or macOS Silicon, as long as a compatible JVM is installed.

The JVM is the platform-specific layer that bridges bytecode and the host OS. Each operating system and CPU architecture has its own JVM binary that understands the host environment's system calls, memory model, and instruction set. The JVM interprets bytecode or compiles it to native machine code via JIT (Just-In-Time compilation), handles OS-level thread scheduling, file system access, and garbage collection.

This separation is the key insight: the platform complexity is isolated inside the JVM. Java developers write against the JVM's abstract specification — a stable, OS-agnostic contract. The JVM vendors (Oracle, Eclipse, Amazon) absorb the porting effort per platform, so application developers don't have to.

Platform independence has practical limits. Native code interop via JNI (Java Native Interface) ties you to a specific OS/architecture. GUI libraries like Swing use native look-and-feel and can render differently per OS. File paths, line endings, default character encodings, and locale-sensitive formatting can all vary. True portability requires awareness of these edge cases, not just the compilation model.

Question 3

How does the JVM work?

Accepted Answer

The JVM processes Java programs through four major subsystems: the class loader, the bytecode verifier, the execution engine, and the runtime memory areas.

The class loader subsystem loads `.class` files on demand, following a delegation hierarchy: Bootstrap ClassLoader (core JDK classes from rt.jar), Extension ClassLoader (lib/ext), and Application ClassLoader (classpath). This parent-first delegation prevents user code from shadowing core Java classes. Custom class loaders extend this hierarchy for frameworks, hot deployment, and OSGi-style isolation.

Before execution, the bytecode verifier statically checks `.class` files for structural validity and security properties — ensuring stack consistency, type safety, and absence of illegal memory accesses. This is a core security layer: untrusted bytecode cannot bypass the type system regardless of what compiler produced it.

The execution engine runs bytecode via two paths. The interpreter executes bytecode instructions directly, with no startup cost but slower throughput. The JIT (Just-In-Time) compiler monitors execution via profiling counters. When a method becomes "hot" (executed frequently), HotSpot compiles it to optimized native machine code, applying aggressive optimizations (inlining, escape analysis, loop unrolling) based on observed runtime behavior. This adaptive optimization is why JVM throughput often improves after a warm-up period.

The runtime memory model divides into: the heap (objects and arrays, managed by GC with generational regions — Eden, Survivor, Old Gen), the method area / Metaspace (class metadata, static fields), the JVM stack (one per thread — stack frames with local variables and operand stack), the PC register (per-thread instruction pointer), and native method stacks.

Garbage collection reclaims unreachable heap objects. Modern collectors (G1, ZGC, Shenandoah) use concurrent marking and region-based collection to minimize stop-the-world pauses, which is critical for latency-sensitive applications.

Question 4

What are the main features of Java?

Accepted Answer

Java is defined by a set of deliberate design choices that have kept it relevant for three decades. Understanding these features at depth — not just reciting the list — is what distinguishes strong candidates.

Platform independence: Java compiles to bytecode executed by the JVM, enabling the same binary to run on any OS with a compatible JVM. This is achieved by separating the compilation target (bytecode) from the execution platform (JVM implementation).

Object-oriented: Java is built around classes and objects. It supports encapsulation (access modifiers), inheritance (single-class, multiple-interface), and polymorphism (method overriding, interface-based dispatch). Everything except primitives is an object, enabling uniform treatment via generics, collections, and reflection.

Automatic memory management: The garbage collector reclaims heap memory for unreachable objects. Developers don't manage malloc/free. Modern GCs (G1, ZGC) provide low-pause collection suitable for latency-sensitive services. The trade-off is GC pauses and less deterministic memory release compared to C++.

Strong static typing: Types are declared and checked at compile time, catching an entire class of errors before runtime. Combined with generics (Java 5+), this provides type-safe collections and algorithms without sacrificing reuse.

Multithreading: Java has built-in thread support via the `Thread` class and `Runnable` interface, the `synchronized` keyword, `volatile`, and the `java.util.concurrent` package (locks, executors, atomic types, concurrent collections). The Java Memory Model formally defines visibility and ordering guarantees across threads.

Rich standard library and ecosystem: The JDK provides extensive APIs for I/O, networking, collections, concurrency, cryptography, and XML. The Maven/Gradle ecosystem provides hundreds of thousands of third-party libraries. This reduces time-to-production compared to languages requiring more from-scratch implementation.

Question 5

What is the significance of 'public static void main(String[] args)' in Java?

Accepted Answer

The `public static void main(String[] args)` signature is Java's program entry point — the method the JVM calls to start execution. Every keyword in the signature is load-bearing.

`public`: The JVM must be able to call this method from outside the class. Making it public gives the JVM (and any external caller) access regardless of the calling context. If it were private or package-private, the JVM runtime would throw a `NoSuchMethodException` or `IllegalAccessException` at launch.

`static`: The JVM must invoke `main` before any instance of the class exists — there is no object to call the method on. `static` means the method belongs to the class itself, not to instances. This allows invocation without first constructing an object, which is necessary because the JVM has no arguments to pass to a constructor at this point.

`void`: The `main` method returns no value to the JVM. Exit status is communicated via `System.exit(int)` if needed. The JVM doesn't inspect a return value from main — void is required by the specification.

`main`: This specific method name is a JVM convention. The JVM looks for a static method named exactly `main` with the `String[]` parameter signature. Other overloads of `main` with different parameter types are valid Java methods but will not be used as entry points.

`String[] args`: Command-line arguments passed by the OS to the JVM are made available as an array of strings. `args[0]` is the first argument after the program name. The array is empty (not null) if no arguments are provided. Since Java 21, a simpler unnamed `main()` method is supported in preview mode (JEP 445) for scripts and educational contexts, relaxing these requirements — but the traditional signature remains the standard for production code.

Question 6

What is the String Constant Pool in Java?

Accepted Answer

The String Constant Pool (also called String Intern Pool) is a special memory region inside the JVM's heap where string literals are stored and reused. When you write a string literal like `String s = "hello"`, the JVM checks the pool first. If "hello" already exists, it returns the same reference rather than allocating a new object. This is possible precisely because Strings are immutable — sharing references is safe since no one can modify the underlying character data.

Prior to Java 7, the pool lived in PermGen (Permanent Generation), which had a fixed size and could cause `OutOfMemoryError` under heavy string usage. From Java 7 onwards, the pool was moved to the main heap, allowing it to participate in normal garbage collection and be resized dynamically.

You can manually add a string to the pool using `String.intern()`. This is useful when you receive strings from external sources (e.g., parsing files) and want to deduplicate them for memory efficiency. For example, `String s = new String("hello").intern()` places the value in the pool and returns the canonical reference.

The key distinction is between `String s1 = "hello"` (uses the pool) and `String s2 = new String("hello")` (creates a new heap object, bypassing the pool). This is why `s1 == s2` returns false even though the content is identical — `==` compares references, and `s2` is a distinct heap object.

Understanding the pool matters for performance-sensitive applications: overuse of `new String()` inflates heap usage unnecessarily, while aggressive interning of dynamic strings can bloat the pool. The practical guidance is to use literals and compile-time constants wherever possible and reserve `intern()` for well-understood deduplication scenarios.

Question 7

Why are Strings immutable in Java?

Accepted Answer

String immutability in Java means that once a `String` object is created, its character sequence cannot be changed. Any operation that appears to modify a string — concatenation, `replace()`, `substring()` — actually creates and returns a new `String` object. The original remains unchanged.

There are four core reasons this design decision was made.

First, thread safety. Because strings cannot be mutated, they can be freely shared across threads without synchronization. No thread can corrupt another's view of the string.

Second, security. Strings are widely used for sensitive data — file paths, network hostnames, database URLs, class names for reflection. If strings were mutable, defensive code could pass a validated string to a security-sensitive API only to have it mutated by another thread before the API consumed it. Immutability closes that attack surface.

Third, hashCode caching. `String` caches its `hashCode` after the first computation. This is only safe because the content can never change. It makes strings highly efficient as `HashMap` keys — the hash is computed once and reused on every lookup.

Fourth, String Constant Pool participation. The JVM pools string literals and returns shared references for identical values. This optimization is only correct if strings cannot be mutated — otherwise modifying one reference would corrupt all others sharing the same pooled object.

The implementation enforces immutability by making the internal `char[]` (or `byte[]` in Java 9+ with compact strings) both `private` and `final`, and by never exposing a reference to it. Even though `final` on an array only freezes the reference, not the array contents, the array is never leaked.

A common interview follow-up: immutability does not mean the reference variable is constant. `String s = "a"; s = "b";` is valid — you are rebinding the variable, not mutating the object.

Question 8

What is the difference between StringBuffer and StringBuilder?

Accepted Answer

Both `StringBuffer` and `StringBuilder` are mutable character sequences used when you need to build or modify strings without creating multiple intermediate `String` objects. They share the same API — `append()`, `insert()`, `delete()`, `reverse()`, `toString()` — and both inherit from `AbstractStringBuilder`. The critical difference is thread safety.

`StringBuffer` was introduced in Java 1.0 and every public method is `synchronized`. This means only one thread can execute any mutating method at a time, making it safe for concurrent use. The synchronization overhead, however, makes it slower in single-threaded contexts.

`StringBuilder` was introduced in Java 5 specifically to address that overhead. Its methods are not synchronized. In a single-threaded environment — which covers the vast majority of string-building work — it is the correct choice and is measurably faster.

In practice, `StringBuilder` is almost always the right default. `StringBuffer` is appropriate only when you genuinely need a shared mutable string across threads, which is rare in modern code because most such patterns are better served by other concurrency primitives or by passing immutable strings across thread boundaries.

The Java compiler itself uses `StringBuilder` internally when it optimizes the `+` operator for string concatenation (up to Java 8; Java 9+ uses `invokedynamic` with `StringConcatFactory` for even more efficient compilation).

Capacity management is identical in both: they start with a default internal buffer of 16 characters and grow by doubling when capacity is exceeded. Pre-sizing with `new StringBuilder(expectedSize)` avoids reallocations in performance-sensitive code.

For interviews, the clean summary is: same API, `StringBuffer` is synchronized (thread-safe, slower), `StringBuilder` is not (not thread-safe, faster). Use `StringBuilder` by default.

Question 9

What is the importance of hashCode() and equals() methods in Java?

Accepted Answer

The `equals()` method defines logical equality between objects — whether two instances should be considered the same value. The `hashCode()` method returns an integer used by hash-based data structures to bucket objects efficiently. They are defined on `Object` and meant to be overridden together.

The contract between them, specified in the Java documentation, is: if two objects are equal according to `equals()`, they must return the same `hashCode()`. The reverse is not required — two objects with the same hash code need not be equal (hash collisions are allowed).

This contract is critical for `HashMap`, `HashSet`, and `Hashtable`. When you call `map.put(key, value)`, the map computes `key.hashCode()` to find the right bucket, then uses `equals()` to find the exact entry within that bucket. If you override `equals()` without overriding `hashCode()`, two logically equal objects may land in different buckets, making retrieval silently fail — the map will not find a key even though an equal one exists.

The reverse violation is less catastrophic but still a performance problem: if all objects return the same hash code (constant hash), every entry lands in the same bucket, turning O(1) lookups into O(n) linked list scans.

For correct implementations: `equals()` must be reflexive, symmetric, transitive, consistent, and return false for null. `hashCode()` should use the same fields that `equals()` uses. IDEs and `Objects.hash()` / `Objects.equals()` can generate compliant implementations. Java 16+ records auto-generate both based on their components.

A subtle production bug: using a mutable field in `hashCode()` is dangerous when that object is stored in a `HashSet`. Mutating the field after insertion changes the hash, putting the object in the wrong bucket — the set can no longer find or remove it.

Question 10

What is the difference between checked and unchecked exceptions in Java?

Accepted Answer

In Java, exceptions are divided into checked and unchecked. The distinction determines whether the compiler forces calling code to handle or declare the exception.

Checked exceptions are subclasses of Exception but not RuntimeException. The compiler enforces that any method which might throw a checked exception must either catch it or declare it with throws. Examples: IOException, SQLException, FileNotFoundException. These represent recoverable conditions — a file that does not exist, a dropped network connection.

Unchecked exceptions are subclasses of RuntimeException. The compiler does not require you to catch or declare them. Examples: NullPointerException, ArrayIndexOutOfBoundsException, IllegalArgumentException. These typically represent programming errors.

Errors (subclasses of Error, like OutOfMemoryError) are also unchecked but represent unrecoverable JVM-level problems.

The class hierarchy: Throwable is the root. It has two subclasses: Exception and Error. Under Exception, RuntimeException and its subclasses are unchecked. Everything else under Exception is checked.

The design rationale for checked exceptions is to force developers to consider failure modes. A method signature like void readFile(String path) throws IOException documents exactly what can go wrong.

However, checked exceptions are controversial. Critics argue they lead to boilerplate (empty catch blocks), poor abstraction (implementation details leaking into signatures), and scaling problems in large codebases. This is why Kotlin, Scala, and Spring predominantly use unchecked exceptions.

Best practices: use checked exceptions for recoverable conditions where the caller can take meaningful action. Use unchecked for programming errors and violated preconditions. Never swallow exceptions silently. When wrapping, preserve the original cause.

Question 11

What are wrapper classes in Java?

Accepted Answer

Java has eight primitive types — `byte`, `short`, `int`, `long`, `float`, `double`, `char`, and `boolean` — that are not objects and cannot be used where `Object` references are required. Wrapper classes provide an object counterpart for each: `Byte`, `Short`, `Integer`, `Long`, `Float`, `Double`, `Character`, and `Boolean`. The primary motivation is interoperability with the Java Collections Framework. `ArrayList` is illegal — generics require reference types. You write `ArrayList` instead. Wrapper classes bridge the gap. Java 5 introduced autoboxing and unboxing to reduce boilerplate. Autoboxing is the automatic conversion from primitive to wrapper (`int` → `Integer`); unboxing is the reverse. The compiler inserts the conversion calls transparently, so `Integer i = 5` compiles to `Integer.valueOf(5)`, and `int x = i` compiles to `i.intValue()`. Wrapper classes also carry utility methods. `Integer.parseInt("42")` converts strings to primitives. `Integer.MAX_VALUE`, `Integer.MIN_VALUE`, `Integer.toBinaryString()` are all available on the class. This makes them useful beyond mere boxing. A critical performance and correctness caveat: `Integer` (and other integer wrappers) caches instances for values from -128 to 127. `Integer.valueOf(100) == Integer.valueOf(100)` is `true` because both return the cached instance. `Integer.valueOf(200) == Integer.valueOf(200)` is `false` — new objects. This is a common source of subtle bugs when using `==` instead of `equals()` with wrapper types. Another pitfall is NullPointerException during unboxing. If an `Integer` field is null and you assign it to an `int`, the JVM calls `.intValue()` on null and throws NPE. This happens invisibly because the unboxing is compiler-generated.

Question 12

Why is Java not considered a pure object-oriented programming language?

Accepted Answer

A pure object-oriented language treats everything as an object and only allows object-based operations. Java falls short of this standard primarily because of primitive types and static members.

Java has eight primitive types — `int`, `long`, `double`, `float`, `byte`, `short`, `char`, and `boolean` — that are not objects. They do not inherit from `Object`, cannot be used as generic type parameters directly, have no methods, and are not stored on the heap in the same way objects are. In a truly pure OOP language like Smalltalk, even integers are objects. Java's primitives exist for performance — object allocation and dereferencing overhead would be prohibitive for low-level numeric operations.

The second violation is `static` members. Static fields and methods belong to the class itself rather than any instance. You can call `Math.sqrt(4.0)` without ever creating a `Math` object. This is procedural programming operating within a class container, not true object-oriented design. In pure OOP, behavior is always invoked on a receiver object.

A lesser-noted point: Java supports static methods, static blocks, and even a `main()` entry point that is static, none of which fit the pure OOP model where program execution is driven by message passing between objects.

Wrapper classes like `Integer` partially address the primitive gap — they provide object representations with utility methods. Java 5 autoboxing further reduced the friction. But the underlying primitives still exist and are still not objects.

Languages like Scala, which runs on the JVM, take the approach of unifying primitives and objects at the language level, compiling down to JVM primitives for performance while presenting a pure-OOP surface. Java deliberately chose not to hide primitives, trading purity for transparency and performance.

Question 13

What is the difference between an abstract class and an interface in Java?

Accepted Answer

Abstract classes and interfaces both enable abstraction, but they serve different design purposes.

An abstract class can contain instance fields, constructors, and a mix of abstract and concrete methods. A subclass extends it using extends and inherits its state and behavior. Java enforces single inheritance for classes — a class can extend only one abstract class. This makes abstract classes appropriate for modeling "is-a" relationships where subclasses share common state.

An interface defines a contract. Prior to Java 8, interfaces could only declare abstract methods and constants. Since Java 8, interfaces can include default methods and static methods. Java 9 added private methods. However, interfaces still cannot have instance fields or constructors — they cannot hold state. A class can implement multiple interfaces, enabling a form of multiple inheritance without the diamond problem.

Default methods narrowed the gap but did not eliminate it. They were designed to allow interface evolution — adding forEach() and stream() to Collection without breaking every implementation. But interfaces still cannot hold mutable state.

Use an abstract class when you need to share state among closely related classes, provide a partial implementation, enforce initialization via constructors, or use non-public members. Use an interface when you want to define a capability that can be mixed into unrelated classes — Comparable, Serializable, Iterable.

A practical pattern is to combine both: define interfaces for public API contracts and abstract classes as skeletal implementations. Java's List (interface) + AbstractList (abstract class) exemplifies this.

Question 14

What are marker interfaces in Java?

Accepted Answer

A marker interface is an interface that declares no methods or fields. Its sole purpose is to tag a class as possessing some property, which the JVM, runtime, or framework can then detect via `instanceof` checks. The interface conveys metadata rather than defining a behavioral contract.

The canonical examples in the Java standard library are:
- `java.io.Serializable` — signals that a class's instances can be serialized to a byte stream. The `ObjectOutputStream` checks `instanceof Serializable` before attempting serialization and throws `NotSerializableException` if the check fails.
- `java.lang.Cloneable` — signals that `Object.clone()` may be called on instances. Without implementing `Cloneable`, `clone()` throws `CloneNotSupportedException`.
- `java.util.RandomAccess` — signals that a `List` implementation supports O(1) indexed access, allowing algorithms like `Collections.binarySearch()` to use a faster iteration strategy.

The mechanism works through runtime type checking: `if (obj instanceof Serializable)`. The interface itself provides no methods — the behavior is implemented elsewhere (in `ObjectOutputStream`, in `Object.clone()`, etc.).

Modern Java offers annotations as an alternative that is generally considered more expressive. Instead of `implements Serializable`, you could annotate a class with something like `@Serializable`. Annotations can carry parameters, are accessible through the reflection API (`getAnnotation()`), and can target specific elements (fields, methods, parameters). Marker interfaces, by contrast, apply only to classes and interfaces and cannot carry data.

However, marker interfaces have one advantage: they participate in the type system. You can write a method signature `void serialize(Serializable obj)` and get compile-time enforcement. An annotation-based equivalent requires runtime reflection checking.

For new code, prefer annotations unless compile-time type checking is specifically needed.

Question 15

What are collections in Java?

Accepted Answer

The Java Collections Framework (JCF) is a unified architecture for representing and manipulating groups of objects. It consists of interfaces that define abstract data types, concrete implementations of those interfaces, and algorithms (utility methods in `Collections` and `Arrays`) that operate on them.

The core interfaces are:
- `Collection` — the root interface. Defines basic operations: `add()`, `remove()`, `contains()`, `size()`, `iterator()`.
- `List` — an ordered sequence allowing duplicates. Key implementations: `ArrayList` (dynamic array, O(1) random access), `LinkedList` (doubly-linked, O(1) head/tail insert).
- `Set` — a collection with no duplicates. `HashSet` (hash table, O(1) average ops), `TreeSet` (red-black tree, sorted, O(log n)), `LinkedHashSet` (insertion-ordered).
- `Queue` / `Deque` — FIFO and double-ended queue. `ArrayDeque`, `LinkedList`, `PriorityQueue`.
- `Map` — key-value pairs, not a `Collection` subtype. `HashMap` (O(1) average), `TreeMap` (sorted by key), `LinkedHashMap` (insertion-ordered).

The framework is built on the principle of separating interface from implementation. Writing code against `List` rather than `ArrayList` allows you to swap implementations without changing calling code.

Key utility classes: `Collections` provides static methods for sorting, shuffling, reversing, finding min/max, and wrapping collections in thread-safe or unmodifiable views. `Arrays` bridges arrays to the framework.

Thread safety is not provided by default in most JCF implementations. For concurrent use, prefer `java.util.concurrent` classes: `ConcurrentHashMap`, `CopyOnWriteArrayList`, `BlockingQueue` implementations. Alternatively, `Collections.synchronizedList()` wraps any list with synchronized access, though iterators still require external locking.

Question 16

What are the differences between ArrayList and Vector?

Accepted Answer

Both `ArrayList` and `Vector` are `List` implementations backed by a resizable array, and they share the same core operations. The primary difference is synchronization.

`Vector` was introduced in Java 1.0 and predates the Collections Framework. Every public method — `add()`, `get()`, `remove()`, `size()` — is `synchronized`. This makes `Vector` thread-safe for individual method calls but at the cost of lock acquisition on every operation, even in single-threaded code.

`ArrayList` was introduced in Java 1.2 as part of the Collections Framework. Its methods are not synchronized, making it significantly faster in single-threaded contexts. For concurrent access, you explicitly choose an appropriate strategy: `Collections.synchronizedList(new ArrayList<>())` for simple wrapping, or `CopyOnWriteArrayList` from `java.util.concurrent` for read-heavy workloads.

A secondary difference is growth strategy. When capacity is exceeded, `ArrayList` grows by 50% (current capacity × 1.5). `Vector` doubles its size by default, though this is configurable via a capacity increment parameter in its constructors.

`Vector` also has legacy methods like `elements()` (returns an `Enumeration`) that predate the `Iterator` interface. These are now redundant.

In practice, `Vector` is considered a legacy class. The Java documentation and Effective Java both recommend `ArrayList` for single-threaded use and `java.util.concurrent` classes for multithreaded use. `Vector` is rarely the right answer in modern code.

One nuance worth noting: even though `Vector` is synchronized, compound operations (check-then-act) still require external synchronization. `if (!v.isEmpty()) v.remove(0)` is not atomic even with `Vector`.

Question 17

What is the finalize() method in Java?

Accepted Answer

`finalize()` is a method defined on `java.lang.Object` that the garbage collector is permitted to call on an object before reclaiming its memory, giving the object a chance to release native resources or perform cleanup. It was part of Java from version 1.0.

The mechanism works as follows: when the GC determines an object is unreachable, it places the object on a finalization queue. A dedicated finalizer thread dequeues and calls `finalize()` on each object. After finalization, the GC can reclaim the object's memory on the next cycle.

In practice, `finalize()` has severe problems that led to its deprecation in Java 9 and its removal/forRemoval marking in Java 18:

1. Unpredictability. There is no guarantee about when — or even whether — `finalize()` will be called. The JVM specification allows it to never run, including on normal JVM exit.
2. Performance impact. Objects with non-trivial finalizers require at minimum two GC cycles to collect, prolonging their lifetime and increasing memory pressure.
3. Resurrection risk. A finalizer can store `this` in a static field, resurrecting the object. This complicates GC logic significantly.
4. Exception swallowing. Any exception thrown from `finalize()` is silently ignored, making debugging difficult.
5. Security. Malicious finalizers in subclasses can exploit the finalization delay to access resources that should have been closed.

The correct alternatives are:
- `try-with-resources` with `AutoCloseable` — deterministic, exception-safe cleanup via `close()`.
- `java.lang.ref.Cleaner` (Java 9+) — a phased, safer alternative to finalization for native resource cleanup when `AutoCloseable` is impractical.
- Explicit `close()` or `dispose()` patterns for long-lived resources.

For interviews: know what finalize does, why it is problematic, and what replaced it.

Question 18

What is the difference between the Comparable and Comparator interfaces?

Accepted Answer

`Comparable` and `Comparator` are both interfaces used for ordering objects, but they serve different design purposes. `Comparable` is implemented by a class to define its natural ordering. The single method `compareTo(T other)` returns a negative integer if `this` is less than `other`, zero if equal, and a positive integer if greater. A class implementing `Comparable` is saying: "I have a well-defined, canonical sort order." Examples: `String` (lexicographic), `Integer` (numeric), `Date` (chronological). Methods like `Collections.sort(list)` and `Arrays.sort(arr)` use natural ordering by default. `Comparator` is a separate strategy object that defines an ordering independent of the class being sorted. Its method `compare(T o1, T o2)` has the same return convention. You use a `Comparator` when you need a sort order other than the natural one, when the class you are sorting doesn't implement `Comparable`, or when you need multiple orderings for the same type. Java 8 enriched `Comparator` with default methods: `Comparator.comparing()` creates comparators from key extractors; `thenComparing()` chains comparators for multi-level sorting; `reversed()` inverts the order. This makes complex sort logic concise: `Comparator.comparing(Person::getLastName).thenComparing(Person::getFirstName)`. The design choice: implement `Comparable` when there is one obvious, universally applicable ordering for the type. Use `Comparator` for alternative orderings or when you cannot modify the class (e.g., sorting third-party objects). A practical note: `TreeMap` and `TreeSet` use either the natural ordering (Comparable) or a provided Comparator. If neither is available, they throw `ClassCastException` at runtime.

Question 19

What is an inner class in Java?

Accepted Answer

An inner class is a class defined within the body of another class or interface. Java has four distinct kinds, each with different scoping and access rules.

**Non-static inner class** (member inner class): defined at the class level without `static`. It has an implicit reference to the enclosing instance and can access all members of the outer class, including private ones. Because of the implicit reference, you need an outer instance to create one: `Outer.Inner i = outer.new Inner()`. The implicit outer reference also means these classes are a common source of memory leaks — they prevent GC of the outer instance.

**Static nested class**: declared with `static`. It does not hold a reference to the enclosing instance. It can only access static members of the outer class directly. It is instantiated as `new Outer.Nested()`. This is the preferred default when inner class access to instance state is not needed, precisely because there is no implicit reference and no leak risk.

**Local class**: defined inside a method body. It can access local variables of the enclosing method, but only if they are effectively final. Scope is limited to the method.

**Anonymous class**: a one-off, nameless class defined inline, typically as an argument or assignment. Common before Java 8 for event listeners and callbacks — largely superseded by lambda expressions for single-abstract-method interfaces.

The key design guidance: prefer static nested classes over non-static inner classes unless you genuinely need access to the enclosing instance's state. Non-static inner classes are the primary source of hard-to-diagnose memory leaks in Android and long-lived Java applications — the outer object cannot be GC'd as long as the inner object is alive.

All four types can access `private` members of the outer class through compiler-generated synthetic accessor methods.

Question 20

What is the difference between final, finally, and finalize() in Java?

Accepted Answer

These three keywords sound similar but serve completely different purposes.

`final` is a non-access modifier with three meanings depending on context:
- Applied to a variable: the reference cannot be reassigned after initialization. For primitives this makes the value constant. For object references, the reference is fixed but the object's internal state can still be mutated.
- Applied to a method: the method cannot be overridden in subclasses.
- Applied to a class: the class cannot be subclassed. `String`, `Integer`, and all other wrapper classes are final.

`finally` is a block that follows a `try` or `try-catch` block. Code in `finally` executes regardless of whether an exception was thrown or caught. It is used to guarantee cleanup — closing streams, releasing locks, etc. It does not execute in a few edge cases: `System.exit()`, a daemon thread being killed, or a JVM crash. Since Java 7, `try-with-resources` is the preferred alternative for resource cleanup, making explicit `finally` blocks for that purpose largely unnecessary.

`finalize()` is an instance method defined on `java.lang.Object`. The garbage collector may call it on an object before reclaiming the object's memory. It was intended for native resource cleanup but is unreliable, slow, and has been deprecated since Java 9. There is no guarantee it will run at all. Modern code should use `AutoCloseable` with try-with-resources or `java.lang.ref.Cleaner` instead.

The quick interview summary: `final` — immutability/constraint modifier. `finally` — always-runs cleanup block. `finalize()` — deprecated GC hook. They share etymology but no functional relationship.

Question 21

What is the difference between '==' and the equals() method in Java?

Accepted Answer

In Java, `==` and `equals()` test different things and the distinction is fundamental to writing correct code.

`==` is the identity operator. For primitive types (`int`, `double`, `boolean`, etc.), it compares values directly — `5 == 5` is `true`. For object references, it compares memory addresses: it is `true` only if both variables point to the exact same object in memory.

`equals()` is a method defined on `Object` that tests logical equality. The default implementation in `Object` uses `==` (same reference), but most classes override it to compare content. `String.equals()` compares character sequences. `Integer.equals()` compares numeric values. If you don't override `equals()`, you get reference comparison by default.

The classic example: `String a = new String("hello"); String b = new String("hello");` — `a == b` is `false` (different objects on the heap), but `a.equals(b)` is `true` (same content).

Key practical rules:
- Always use `equals()` to compare object content.
- Use `==` only to check if two references point to the exact same instance, or to compare primitives.
- Never use `==` to compare boxed wrapper types like `Integer` or `Long` unless you know the values fall in the cached range (-128 to 127 for Integer) — and even then, don't rely on caching behavior.
- Use `Objects.equals(a, b)` when either operand might be null, to avoid NullPointerException.

For `null`: `null == null` is `true`. Calling `.equals()` on a null reference throws `NullPointerException`. Calling `someObject.equals(null)` should return `false` by contract and does so in all standard library implementations.

Question 22

What is method overloading and method overriding in Java?

Accepted Answer

Method overloading and method overriding are both forms of polymorphism but operate at different phases and on different axes.

**Method overloading** (compile-time / static polymorphism): Multiple methods in the same class share the same name but differ in their parameter list — number of parameters, parameter types, or both. The compiler determines at compile time which overload to call based on the argument types and count. Return type alone is not sufficient to distinguish overloads. Example: `print(int x)`, `print(double x)`, `print(String s)` in the same class.

**Method overriding** (runtime / dynamic polymorphism): A subclass provides its own implementation of a method that is already defined in a superclass, keeping the same method signature (name + parameter list + return type, where the return type may be a covariant subtype since Java 5). The JVM determines at runtime which implementation to call based on the actual type of the object, not the declared type of the reference. This is the mechanism that enables polymorphic behavior.

Rules for overriding:
- The method signature must match.
- Access modifier cannot be more restrictive than the parent's.
- Cannot override `static`, `final`, or `private` methods.
- The `@Override` annotation should be used — it causes a compile error if the signature doesn't match, preventing silent overload-instead-of-override bugs.
- Overriding method can throw narrower (or no) checked exceptions, but not broader ones.

The key conceptual distinction: overloading is resolved by the compiler based on static type; overriding is resolved by the JVM at runtime based on the actual object type. This is why overloading is called static polymorphism and overriding is dynamic polymorphism.

Question 23

What is the difference between HashMap and Hashtable?

Accepted Answer

HashMap and Hashtable both implement the Map interface and store key-value pairs using a hash table, but they differ in synchronization, null handling, and historical context.

Hashtable is a legacy class from Java 1.0. Every public method is synchronized, meaning only one thread can access the table at a time. This makes Hashtable thread-safe but slow — every operation acquires a monitor lock on the entire object, even reads. Hashtable does not allow null keys or null values.

HashMap was introduced in Java 1.2 as part of the Collections Framework. It is not synchronized, making it faster in single-threaded scenarios. HashMap allows one null key and any number of null values.

The critical follow-up: what should you use for thread-safe map operations? ConcurrentHashMap, not Hashtable. ConcurrentHashMap uses fine-grained locking (node-level CAS operations in Java 8+), allowing multiple threads to read and write concurrently without blocking each other. It also provides atomic compound operations like putIfAbsent() and computeIfAbsent().

Another option is Collections.synchronizedMap(), which wraps a HashMap with synchronized methods — similar to Hashtable's coarse-grained locking but returns a standard Map interface.

HashMap's iterators are fail-fast (throw ConcurrentModificationException on structural modification during iteration). ConcurrentHashMap's iterators are weakly consistent — they reflect some changes and never throw ConcurrentModificationException.

There is essentially no reason to use Hashtable in modern Java code.

Question 24

What is the difference between ArrayList and LinkedList?

Accepted Answer

ArrayList and LinkedList are both implementations of the List interface in Java, but they are backed by fundamentally different data structures.

ArrayList is backed by a dynamically resizing array. Elements are stored sequentially in contiguous memory, giving O(1) random access. When the array reaches capacity, ArrayList allocates a new array approximately 1.5x the size and copies all elements, making add() amortized O(1) at the end. Insertion or removal at arbitrary positions is O(n) because elements must be shifted.

LinkedList is a doubly-linked list. Each element is wrapped in a Node object with pointers to the previous and next nodes. Insertion and removal at head or tail is O(1). Accessing an element by index is O(n) because you must traverse from the head or tail. LinkedList also implements the Deque interface.

The textbook analysis suggests LinkedList is better for frequent insertions in the middle. In practice, ArrayList benefits enormously from cache locality — contiguous memory enables CPU prefetching, and sequential access is extremely fast. LinkedList nodes are scattered across the heap, causing frequent cache misses. The Node object overhead (24+ bytes per node for object header and two pointers) also adds up. Benchmarks consistently show ArrayList outperforms LinkedList for most real-world workloads.

LinkedList is genuinely appropriate when used strictly as a queue or deque, or when removing elements during iteration with ListIterator.remove(). However, even for queue operations, ArrayDeque is often better due to contiguous memory.

In practice: default to ArrayList. Use LinkedList only when you specifically need Deque operations and have measured that it performs better.

Question 25

What is the Java Reflection API?

Accepted Answer

The Java Reflection API, in the `java.lang.reflect` package, enables a program to examine and modify its own structure and behavior at runtime. It allows code to inspect class metadata, invoke methods, access fields, and instantiate objects using symbolic names rather than compile-time references.

The entry point is `Class<?>`, obtained via `obj.getClass()`, `MyClass.class`, or `Class.forName("com.example.MyClass")`. From a `Class` object you can retrieve `Method`, `Field`, `Constructor`, and `Annotation` objects, then invoke methods or get/set fields even if they are private (after calling `setAccessible(true)`, subject to module and security constraints).

Common use cases: dependency injection frameworks (Spring reads annotations and injects beans), ORM tools (Hibernate maps fields to columns), serialization libraries (Jackson introspects field names), testing frameworks (JUnit discovers test methods by annotation), plugin systems (loading classes by name at runtime).

Reflection is powerful but carries real costs:
1. Performance: reflective invocation bypasses JVM optimizations (inlining, JIT hotspot compilation). Method.invoke() is measurably slower than direct calls, though `MethodHandle` (java.lang.invoke) and `invokedynamic` provide more performant alternatives.
2. Type safety: errors that would be caught at compile time (wrong argument types, missing methods) become runtime exceptions (`IllegalArgumentException`, `NoSuchMethodException`).
3. Encapsulation violation: `setAccessible(true)` overrides visibility modifiers, which was unrestricted before Java 9. Java 9+ module system (`--add-opens`) enforces access boundaries, limiting deep reflection on JDK internals and third-party modules.
4. Security: in security-managed environments, reflective access requires permissions that may not be granted.

For interviews at senior level, know that `MethodHandle` is the modern, performance-friendly alternative for dynamic dispatch, and that the module system materially changed what reflection can access.

Question 26

What are the different memory areas allocated by the JVM?

Accepted Answer

The JVM divides memory into several runtime data areas, each with a specific purpose and lifecycle.

**Heap**: The largest memory area. All object instances and arrays are allocated here. It is shared across all threads and is managed by the garbage collector. The heap is further divided into Young Generation (Eden + two Survivor spaces) and Old Generation (Tenured), with G1GC and ZGC using region-based layouts instead. `OutOfMemoryError` is thrown when the heap is exhausted.

**Stack (JVM Stack)**: Each thread has its own stack. It stores stack frames — one per method invocation. A frame holds: local variables, the operand stack, and a reference to the runtime constant pool of the method's class. When a method returns, its frame is popped. `StackOverflowError` is thrown when recursion exhausts the stack depth.

**Method Area** (Metaspace in Java 8+): Stores class-level data: the runtime constant pool, field and method data, method bytecode, and static variables. Prior to Java 8 this was PermGen (fixed size, a common OOM source). Java 8 replaced it with Metaspace, which uses native memory and grows dynamically (bounded by `MaxMetaspaceSize`). Each class loaded by a classloader stores its metadata here.

**PC Register** (Program Counter): One per thread. Holds the address of the current JVM instruction being executed. For native methods, the PC is undefined.

**Native Method Stack**: Supports native (non-Java) methods written in C/C++ via JNI. One per thread. Behaves like the JVM stack but for native frames.

**Runtime Constant Pool**: Technically part of the Method Area. Contains symbolic references from the class file's constant pool, resolved at runtime to actual memory references.

For GC tuning, Heap sizing (`-Xms`, `-Xmx`) and Metaspace sizing (`-XX:MaxMetaspaceSize`) are the primary levers.

Question 27

What is the difference between throw and throws in Java?

Accepted Answer

`throw` and `throws` are both part of Java's exception mechanism but operate at different points and serve different purposes.

`throw` is a statement used inside a method body to explicitly raise an exception. It takes an instance of `Throwable` (typically an `Exception` or `RuntimeException` subclass). Execution immediately leaves the current block and the stack unwinds looking for a matching `catch`. Example: `throw new IllegalArgumentException("value must be positive");`

`throws` is a clause in a method signature that declares which checked exceptions the method might propagate to its callers. It is a contract declaration, not an execution command. Any caller must either catch those exceptions or declare them in its own `throws` clause, propagating the obligation up the call stack. Example: `public void readFile(String path) throws IOException, ParseException {}`

The relationship: if a method uses `throw` to raise a checked exception, it must either handle that exception internally with `try-catch` or declare it with `throws`. Unchecked exceptions (`RuntimeException` subclasses) and errors can be thrown without a `throws` declaration.

Key distinctions:
- `throw` operates at runtime; `throws` is a compile-time declaration.
- `throw` takes a single object instance; `throws` lists one or more exception types (comma-separated).
- `throw` causes program flow to change; `throws` is informational — it doesn't cause anything to happen on its own.

A well-designed API uses checked exceptions (declared with `throws`) for recoverable conditions callers are expected to handle, and unchecked exceptions for programming errors. Overusing checked exceptions forces callers into boilerplate handling that often just wraps and rethrows, which is a design smell.

Question 28

What is a Singleton class and how do you create one in Java?

Accepted Answer

The Singleton pattern ensures that a class has exactly one instance throughout the application's lifetime and provides a global point of access to it. It is one of the Gang of Four creational patterns.

There are several implementation approaches, each with different thread-safety and laziness characteristics.

**Eager initialization**: The instance is created when the class loads. Simple and thread-safe because class loading is atomic. Drawback: the instance is created even if never used.
```java
public class Singleton {
    private static final Singleton INSTANCE = new Singleton();
    private Singleton() {}
    public static Singleton getInstance() { return INSTANCE; }
}
```

**Double-checked locking** (lazy, thread-safe): Delays creation until first use. The `volatile` keyword is essential — without it, the JVM may reorder instructions and a second thread can observe a partially initialized object.
```java
private static volatile Singleton instance;
public static Singleton getInstance() {
    if (instance == null) {
        synchronized (Singleton.class) {
            if (instance == null) instance = new Singleton();
        }
    }
    return instance;
}
```

**Initialization-on-demand holder** (Bill Pugh): Leverages class loader guarantees. The nested static class is not loaded until `getInstance()` is called. Thread-safe without synchronization overhead.
```java
private static class Holder { static final Singleton INSTANCE = new Singleton(); }
public static Singleton getInstance() { return Holder.INSTANCE; }
```

**Enum singleton** (Joshua Bloch's recommendation): Inherently serialization-safe and reflection-proof. Enum instances are guaranteed single by the JVM.
```java
public enum Singleton { INSTANCE; }
```

Enums are preferred when you need guaranteed single-instance semantics with zero risk of serialization or reflection bypass.

Question 29

What are the main features of the Java 8 Stream API?

Accepted Answer

The Stream API, introduced in Java 8 in `java.util.stream`, enables functional-style processing of sequences of elements through declarative, composable pipelines. A stream is not a data structure — it does not store data. It conveys elements from a source (collection, array, generator function, I/O channel) through a pipeline of operations. A stream pipeline has three parts: 1. **Source**: `collection.stream()`, `Arrays.stream(arr)`, `Stream.of(...)`, `Stream.generate(supplier)`, `Stream.iterate(seed, function)`. 2. **Intermediate operations**: lazy — they return a new stream and are not executed until a terminal operation is called. Examples: `filter(predicate)`, `map(function)`, `flatMap(function)`, `distinct()`, `sorted()`, `limit(n)`, `peek(consumer)`. 3. **Terminal operations**: trigger the pipeline to execute. Examples: `collect(collector)`, `forEach(consumer)`, `reduce(identity, accumulator)`, `count()`, `findFirst()`, `anyMatch(predicate)`, `toList()` (Java 16). Laziness is a key design feature. Intermediate operations are fused; the stream processes elements one at a time through the entire pipeline rather than creating intermediate collections. This enables short-circuit operations like `findFirst()` to stop processing as soon as a match is found. Parallel streams (`collection.parallelStream()`) distribute work across the ForkJoinPool's common pool. They are useful for CPU-bound operations on large datasets but counterproductive for small collections or I/O-bound tasks due to thread management overhead and potential race conditions with non-thread-safe collectors. `Collectors` provides rich terminal operations: `toList()`, `toSet()`, `groupingBy()`, `partitioningBy()`, `joining()`, `counting()`, and more. `Collectors.groupingBy()` is one of the most powerful — it produces a `Map>` grouping elements by a classifier function. Streams are consumed once — reusing a stream after a terminal operation throws `IllegalStateException`.

Question 30

What is the difference between fail-fast and fail-safe iterators?

Accepted Answer

The terms fail-fast and fail-safe describe how iterators behave when the underlying collection is modified during iteration.

**Fail-fast iterators** throw `ConcurrentModificationException` if the collection is structurally modified (elements added or removed) after the iterator is created, by any means other than the iterator's own `remove()` method. They detect modification by checking a `modCount` field on the collection against a count captured when the iterator was created. If they differ, the exception is thrown on the next `next()` or `hasNext()` call.

Fail-fast iterators are used by most standard `java.util` collections: `ArrayList`, `HashMap`, `HashSet`, `LinkedList`. They are not a thread-safety guarantee — the exception is a best-effort notification. The Java documentation explicitly states that fail-fast behavior should not be relied upon for program correctness; it is designed to detect programming bugs, not as a concurrency mechanism.

**Fail-safe iterators** work on a snapshot or copy of the collection as it existed when iteration began. Modifications to the original collection during iteration are not visible to the iterator and do not cause exceptions. The tradeoff is that the iterator may not reflect the current state of the collection.

Fail-safe iterators are used by `java.util.concurrent` classes: `ConcurrentHashMap` (iterator reflects current state via a weakly consistent traversal), `CopyOnWriteArrayList` (iterates over a snapshot of the array taken at iterator creation time — true copy semantics).

`CopyOnWriteArrayList` is appropriate for read-heavy workloads with infrequent writes — each write copies the entire array, which is expensive but produces a pristine read path with no locking. `ConcurrentHashMap`'s iterators are weakly consistent, meaning they may or may not reflect updates that occur after iteration begins.

For interviews: `ArrayList` → fail-fast; `CopyOnWriteArrayList` → fail-safe (copy). Be precise about weakly consistent iterators in `ConcurrentHashMap`.

Question 31

What is the difference between a process and a thread in Java?

Accepted Answer

A process and a thread are both units of execution, but they operate at different levels of the operating system and have fundamentally different resource isolation models.

A **process** is an instance of a running program. The OS allocates it its own private virtual memory address space, file handles, network connections, and system resources. Processes are isolated from each other — a crash in one process does not directly affect others. Communication between processes requires inter-process communication (IPC) mechanisms: pipes, sockets, shared memory, message queues. Creating a process is relatively expensive; the OS must allocate and initialize a new address space.

A **thread** is a unit of execution within a process. All threads in the same process share the process's memory space — the heap, static fields, and open resources. Each thread has its own program counter, stack, and register state, but nothing else is isolated. This shared memory makes communication between threads fast (just read/write shared variables), but requires careful synchronization to avoid data races and memory visibility issues.

In the JVM context: when you launch a Java application, the JVM itself runs as a single OS process. Inside that process, the JVM creates multiple threads: the main thread, GC threads, JIT compiler threads, finalizer thread, and any application threads you create.

Because threads share heap memory, concurrent access to shared objects without synchronization is a bug — data races produce undefined, non-deterministic behavior. The Java Memory Model (JMM) defines the rules for when one thread's writes are visible to another: `synchronized` blocks, `volatile` fields, and `java.util.concurrent` primitives all establish happens-before relationships.

Context switching between threads in the same process is cheaper than switching between processes because there is no address space change, but it is not free — the OS still saves and restores register state.

Question 32

What are the different ways to create a thread in Java?

Accepted Answer

Java provides several mechanisms to create and run threads, each with different tradeoffs.

**Extending Thread**: Subclass `java.lang.Thread` and override `run()`. Call `start()` (not `run()` directly — `run()` executes on the current thread; `start()` creates a new OS thread). Drawback: Java's single-inheritance constraint means the class cannot extend anything else.

**Implementing Runnable**: Implement `java.lang.Runnable` (functional interface with one method: `run()`). Pass an instance to `new Thread(runnable).start()`. This separates the task from the thread — you can pass the same Runnable to multiple threads or an executor. This is the preferred approach over extending Thread.

**Implementing Callable**: Like Runnable but `call()` returns a value and can throw a checked exception. Used with `ExecutorService.submit(callable)` which returns a `Future<V>`. Call `future.get()` to block until the result is available.

**ExecutorService**: The modern way. Rather than managing threads manually, submit tasks to a thread pool created by `Executors.newFixedThreadPool(n)`, `Executors.newCachedThreadPool()`, or `Executors.newScheduledThreadPool(n)`. The framework handles thread creation, reuse, and lifecycle. Always call `shutdown()` when done.

**CompletableFuture** (Java 8+): For async, non-blocking composition of tasks. `CompletableFuture.supplyAsync(supplier)` runs a task on the common ForkJoinPool. Supports chaining with `thenApply()`, `thenCompose()`, `exceptionally()`.

**Virtual Threads** (Java 21, Project Loom): `Thread.ofVirtual().start(runnable)` or `Executors.newVirtualThreadPerTaskExecutor()`. Lightweight threads scheduled by the JVM, not the OS. Enable millions of concurrent tasks without the memory cost of OS threads.

For most modern code, `ExecutorService` with `Callable`/`Runnable` is the standard. Avoid extending Thread or creating bare threads in production code.

Question 33

What is synchronization in Java?

Accepted Answer

Synchronization in Java is the mechanism by which the JVM controls access to shared resources by multiple threads, preventing data races and ensuring memory visibility.

Every Java object has an intrinsic lock (monitor). When a thread enters a `synchronized` method or block, it acquires the lock on the specified object. Other threads attempting to acquire the same lock block until the first thread releases it by exiting the synchronized scope. Synchronized methods lock on `this` (for instance methods) or on the class object (for static methods).

Synchronization provides two guarantees:
1. **Mutual exclusion**: only one thread executes the synchronized code at a time.
2. **Memory visibility**: changes made inside a synchronized block are visible to any thread that subsequently acquires the same lock (happens-before relationship in the Java Memory Model).

`volatile` is a lighter-weight alternative for visibility without mutual exclusion. A write to a volatile field is immediately visible to all threads. It does not, however, provide atomicity for compound operations — `count++` on a volatile int is still a race condition because it is a read-modify-write sequence of three operations.

The `java.util.concurrent` package provides higher-level alternatives:
- `ReentrantLock`: explicit locking with `lock()` and `unlock()`, supports try-lock with timeout, fair ordering.
- `ReadWriteLock`: separate locks for read and write — multiple readers can proceed concurrently; writes are exclusive.
- `AtomicInteger`, `AtomicReference`, etc.: lock-free atomic operations using CPU compare-and-swap (CAS) instructions.
- `CountDownLatch`, `CyclicBarrier`, `Semaphore`: coordination primitives for common concurrency patterns.

Pitfalls: holding locks for too long increases contention; synchronizing on publicly accessible objects allows external code to interfere; using `synchronized` on `String` literals or autoboxed `Integer` values shares locks unexpectedly across the codebase.

Question 34

What is deadlock in Java and how can it be avoided?

Accepted Answer

A deadlock is a situation where two or more threads are permanently blocked, each waiting to acquire a lock held by another thread in the cycle. No thread can proceed, and the application hangs indefinitely without throwing an exception.

The classic example: Thread A holds Lock 1 and waits for Lock 2. Thread B holds Lock 2 and waits for Lock 1. Neither can proceed.

Four conditions must all hold simultaneously for a deadlock (Coffman conditions):
1. **Mutual exclusion**: at least one resource is held in non-shareable mode.
2. **Hold and wait**: a thread holds one resource while waiting for another.
3. **No preemption**: the OS cannot forcibly take a lock from a thread.
4. **Circular wait**: a circular chain of threads each waiting on the next.

Prevention strategies target breaking one of these conditions:

**Lock ordering**: All threads acquire locks in the same global order. If every thread always acquires Lock 1 before Lock 2, circular wait is impossible. This is the most common and effective prevention technique.

**Try-lock with timeout**: Use `ReentrantLock.tryLock(timeout, unit)`. If a thread cannot acquire a lock within the timeout, it releases all held locks and retries or backs off. This breaks hold-and-wait.

**Lock-free data structures**: Use `AtomicReference`, `ConcurrentHashMap`, and other CAS-based structures that need no traditional locking.

**Deadlock detection**: In production, thread dumps via `jstack` or JMX expose deadlocked threads. The JVM can detect deadlock in thread dumps and reports the cycle. Tools: Java Flight Recorder, VisualVM.

**Avoid nested locking**: Minimize acquiring multiple locks simultaneously. If unavoidable, use a well-documented global ordering.

Deadlock is distinct from livelock (threads keep changing state but make no progress) and starvation (a thread is perpetually denied access but other threads make progress).

Question 35

What is the volatile keyword in Java?

Accepted Answer

The volatile keyword in Java is a field modifier that guarantees visibility and ordering guarantees for a variable across multiple threads. Without volatile, each thread may cache a variable's value in its CPU register or L1/L2 cache, meaning writes by one thread are not necessarily visible to other threads reading the same variable.

When a variable is declared volatile, the JVM ensures two things: first, every read of that variable goes directly to main memory rather than a thread-local cache; second, every write to that variable is flushed to main memory immediately. This eliminates the stale-read problem in multi-threaded programs.

volatile also provides a happens-before guarantee: all writes that happened before a volatile write are visible to any thread that reads that volatile variable afterward. This is a weaker guarantee than synchronization — it does not provide atomicity for compound operations. For example, volatile int counter does not make counter++ thread-safe because that operation involves a read, increment, and write — three distinct steps.

The canonical use case for volatile is a boolean status flag: a background thread sets running = false and the worker thread's loop condition checks while (running). Without volatile, the JIT compiler may hoist the read out of the loop entirely, and the worker never sees the update.

volatile is not a replacement for synchronized or Lock. It is appropriate when one thread writes and others only read, or when writes are independent (not derived from the current value). For counters, accumulators, or check-then-act patterns, prefer AtomicInteger or explicit synchronization.

Question 36

What is the transient keyword in Java?

Accepted Answer

The transient keyword in Java is a field modifier that instructs the serialization mechanism to skip a field when converting an object to a byte stream. When an object implementing Serializable is serialized, every non-transient field is written to the output. A transient field is omitted entirely, and upon deserialization it receives the default value for its type: null for objects, 0 for numbers, false for booleans.

The primary use cases for transient are security and practicality. Sensitive fields like passwords or cryptographic keys should not be persisted to disk or sent over a network in serialized form. Additionally, fields that cannot be serialized — such as a thread, a database connection, or a cached computed value — must be marked transient to prevent a NotSerializableException at runtime.

A classic example is a Logger field. Logger instances are typically singletons retrieved from a factory and are not meaningfully serializable. Marking it transient prevents errors and avoids bloating the serialized form.

After deserialization, transient fields are null (or zero/false). If your class needs to re-initialize them, override the readObject(ObjectInputStream) method to restore them post-deserialization. For example, a transient cached result can be lazily recomputed on first access.

transient has no effect outside Java's built-in serialization. Frameworks like JSON serializers (Jackson, Gson) do not honor it by default — they have their own annotations (@JsonIgnore, @Expose) for field exclusion.

In summary, transient is a targeted escape hatch within the serialization contract: use it to protect sensitive data, avoid serialization errors for inherently non-serializable state, and exclude derived or cached values that are cheaper to recompute than to persist.

Question 37

What is serialization and deserialization in Java?

Accepted Answer

Serialization is the process of converting a Java object's state into a byte stream so it can be persisted to disk, stored in a database, or transmitted over a network. Deserialization is the inverse: reconstructing an object from that byte stream. Together, they enable objects to outlive the JVM process that created them.

To make a class serializable, it must implement the java.io.Serializable marker interface, which has no methods. The JVM's built-in serialization mechanism then handles the conversion automatically using ObjectOutputStream for writing and ObjectInputStream for reading.

Each serializable class should declare a private static final long serialVersionUID field. This value is embedded in the serialized stream and checked during deserialization. If the class on the reading side has a different serialVersionUID than the one in the stream, an InvalidClassException is thrown. Omitting serialVersionUID means the JVM auto-generates it from class structure — any field addition or removal will change it and break existing serialized data.

Serialization has important caveats. It is shallow by default in the sense that all referenced objects must also be Serializable (or declared transient). It bypasses constructors — the object is reconstructed by directly setting field values from the stream, so any validation logic in constructors is not executed. This is a known security attack vector: malicious serialized data can create objects in invalid states.

For production systems, Java's built-in serialization is often avoided in favor of explicit formats like JSON (Jackson, Gson), Protocol Buffers, or Avro, which are language-agnostic, more efficient, and safer. Built-in serialization is appropriate for short-lived use cases like Java RMI or HttpSession persistence in application servers.

Customization hooks include readObject/writeObject for field-level control, readResolve/writeReplace for singleton preservation, and the Externalizable interface for complete control over the format.

Question 38

What are functional interfaces in Java?

Accepted Answer

A functional interface in Java is an interface that declares exactly one abstract method. This single-abstract-method (SAM) constraint makes the interface usable as the target type for a lambda expression or method reference, enabling functional-style programming introduced in Java 8. The @FunctionalInterface annotation is optional but strongly recommended. It instructs the compiler to enforce the SAM constraint and signals intent to readers. If you accidentally add a second abstract method, the compiler emits an error rather than silently breaking all lambda assignments. The java.util.function package ships with a rich set of built-in functional interfaces covering the most common patterns. Predicate takes a T and returns boolean (testing/filtering). Function maps T to R (transformation). Consumer takes a T and returns void (side effects). Supplier takes nothing and returns T (factories/lazy evaluation). BinaryOperator takes two T arguments and returns T (reduction). Primitive specializations like IntPredicate and LongSupplier avoid autoboxing overhead. Functional interfaces can have any number of default and static methods — only abstract methods count toward the SAM constraint. For example, Predicate has default methods and(), or(), and negate() that compose predicates. Before Java 8, single-method interfaces like Runnable and Comparator were already widely used in anonymous inner classes. Lambda expressions are essentially a syntactic shorthand for anonymous implementations of functional interfaces — the compiler infers the target type from context. A key design implication: when writing an API that accepts behavior as a parameter (callbacks, strategies, transformations), prefer accepting a standard functional interface from java.util.function rather than defining a custom one. This integrates naturally with the streams API and keeps the method signature immediately recognizable to Java developers.

Question 39

What are lambda expressions in Java?

Accepted Answer

Lambda expressions, introduced in Java 8, are anonymous function literals that implement a functional interface inline without the boilerplate of an anonymous inner class. The syntax is: (parameters) -> expression or (parameters) -> { statements; }. When the parameter type can be inferred from context, the type declaration is optional. A single-parameter lambda can omit parentheses.

Lambdas are not objects in the traditional sense — they are instances of a functional interface inferred from the target type. The compiler determines which functional interface a lambda implements based on context: the variable type it is assigned to, the method parameter it is passed as, or an explicit cast.

A critical distinction from anonymous inner classes is how they handle the this keyword and variable capture. Inside an anonymous inner class, this refers to the inner class instance. Inside a lambda, this refers to the enclosing class instance. Both can capture variables from the enclosing scope, but those variables must be effectively final — either declared final or never reassigned after initial assignment. This prevents race conditions when lambdas are used in concurrent contexts.

Method references are a shorthand syntax for lambdas that simply delegate to an existing method: ClassName::staticMethod, instance::instanceMethod, ClassName::instanceMethod (receives the instance as first parameter), and ClassName::new (constructor reference).

Lambdas are most prominent in the Streams API: list.stream().filter(x -> x > 0).map(x -> x * 2).collect(Collectors.toList()). They also appear in CompletableFuture chains, event handlers, and anywhere a callback was previously an anonymous inner class.

Performance note: lambda creation uses invokedynamic under the hood, deferring the actual implementation strategy to the JVM. In practice this is very efficient — frequently called lambdas are compiled to static methods and inlined by the JIT.

Question 40

What is the difference between Collection and Collections in Java?

Accepted Answer

Collection (singular, no 's') is the root interface in the Java Collections Framework hierarchy. It is located in java.util and declares the fundamental contract all collection types must fulfill: add, remove, contains, size, iterator, and similar methods. Interfaces like List, Set, and Queue extend Collection, and concrete classes like ArrayList, HashSet, and LinkedList ultimately implement it.

Collections (plural, with 's') is a final utility class in java.util containing only static helper methods that operate on objects implementing Collection or its sub-interfaces. It has no instances — you never instantiate Collections. Its methods include: sort(List), binarySearch(List, key), reverse(List), shuffle(List), min(Collection), max(Collection), frequency(Collection, obj), disjoint(Collection, Collection), and factory methods for synchronized and unmodifiable wrappers such as Collections.synchronizedList(list) and Collections.unmodifiableMap(map).

A useful analogy is Arrays vs. the array type itself. Collection is what the data structure IS; Collections is a toolbox of algorithms and adapters you apply to instances of Collection.

Note that Java 9+ introduced factory methods directly on the interfaces: List.of(), Set.of(), and Map.of(). These return immutable collections and are now preferred over Collections.unmodifiableList(Arrays.asList(...)) for creating small, fixed collections. This reduces some day-to-day reliance on the Collections utility class but does not replace it for algorithmic operations like sort or shuffle.

In interviews, confusion between these two is a common entry-level flag. Knowing that one is an interface and the other is a utility class — and being able to name methods from each — demonstrates solid Java fundamentals.

Question 41

What is the difference between Set and List in Java?

Accepted Answer

List and Set are both sub-interfaces of Collection but with fundamentally different contracts around ordering and uniqueness.

A List is an ordered sequence. It maintains insertion order (or a deliberately sorted order), allows duplicate elements, and provides index-based access via get(int index). The primary implementations are ArrayList (random access, backed by an array, O(1) get) and LinkedList (sequential access, O(n) get, but O(1) insert/remove at a known position).

A Set models a mathematical set: no duplicate elements are permitted. The equals() and hashCode() contract determines what counts as a duplicate. HashSet offers O(1) average add/contains/remove but no ordering guarantee. LinkedHashSet preserves insertion order with O(1) operations. TreeSet maintains elements in natural or comparator-defined sorted order with O(log n) operations, implementing the NavigableSet interface.

The practical decision is: do you need uniqueness or do you need indexed positional access? If you need to store and retrieve by position, or duplicates are meaningful, use a List. If the semantics of your data require uniqueness (email addresses, active user IDs, feature flags), use a Set — it enforces the constraint automatically rather than relying on manual checks.

Performance difference for membership testing is significant. contains() on an ArrayList is O(n) because it scans every element. contains() on a HashSet is O(1) average. For large collections where membership checks are frequent, HashSet dramatically outperforms ArrayList.

Note that iterating a HashSet in a specific order is unreliable across JVM runs (hash seed randomization). If deterministic iteration order matters, prefer LinkedHashSet or TreeSet.

Question 42

What is the difference between HashSet and TreeSet?

Accepted Answer

HashSet and TreeSet are both implementations of the Set interface in Java, but they differ fundamentally in their underlying data structures, performance characteristics, and ordering guarantees.

HashSet is backed by a HashMap internally. When you add an element, it computes the hash code, determines the bucket, and stores the element as a key in the underlying map. This gives HashSet O(1) average-case time complexity for add, remove, and contains operations. However, HashSet provides no ordering guarantees — iterating over a HashSet may return elements in any order. HashSet allows one null element and requires that elements properly implement hashCode() and equals().

TreeSet is backed by a TreeMap, which uses a red-black tree — a self-balancing binary search tree. This gives TreeSet O(log n) time complexity for add, remove, and contains operations. The key advantage is that TreeSet maintains elements in sorted order, either by natural ordering (Comparable) or by a custom Comparator. TreeSet does not allow null elements because it needs to compare every element.

Because TreeSet implements NavigableSet, it exposes powerful methods: first(), last(), headSet(), tailSet(), subSet(), ceiling(), floor(), higher(), and lower(). These allow efficient range queries that would require sorting the entire collection with a HashSet.

When choosing between them, use HashSet when you need fast lookups and do not care about ordering. Use TreeSet when you need sorted order or range queries. One subtle point: TreeSet's ordering must be consistent with equals. If a Comparator considers two distinct objects as equal (returns 0), TreeSet will reject the second one, even if equals() returns false.

Question 43

What is the diamond problem in Java?

Accepted Answer

The diamond problem is a classic multiple inheritance ambiguity that arises when a class inherits from two parents that both provide a concrete implementation of the same method, and both parents share a common superclass or interface defining that method. The shape forms a diamond in the inheritance graph: a common top, two middle nodes, and one bottom class inheriting from both.

Java avoids the classic diamond problem entirely for class inheritance because Java does not support multiple class inheritance — a class can extend only one superclass. This was a deliberate design decision, making the language simpler and less error-prone compared to C++.

However, Java 8 introduced default methods on interfaces, which brought a form of the diamond problem back. If two interfaces both declare a default method with the same signature, and a class implements both interfaces without overriding that method, the compiler refuses to compile and requires an explicit override in the implementing class.

The resolution rules are: first, a class implementation always wins over an interface default — if the class or any of its superclasses provides a concrete method, that implementation is used. Second, if resolution comes down to two interface defaults, the more specific interface wins (a sub-interface's default overrides a parent interface's default). Third, if neither rule resolves the conflict, the implementing class must override the method explicitly, and can delegate to a specific interface default using InterfaceName.super.methodName().

For example: class C implements A, B where both A and B have default void greet(). Class C must override greet() and may call A.super.greet() or B.super.greet() as needed.

Understanding this demonstrates mastery of Java 8+ interface evolution and why default methods were designed with these explicit conflict-resolution rules.

Question 44

What is dependency injection in Java?

Accepted Answer

Dependency injection (DI) is a design pattern implementing the Inversion of Control (IoC) principle. Instead of a class creating its own dependencies with new, those dependencies are provided (injected) from outside — by a framework, factory, or test harness. The class declares what it needs; something else decides what to provide.

There are three injection styles. Constructor injection passes dependencies through the constructor: the object is fully initialized on creation, all dependencies are visible, and the class can be declared immutable. This is the preferred style. Setter injection provides dependencies through setter methods after construction, useful for optional dependencies. Field injection injects directly into annotated fields — convenient but problematic for testing because the field is not accessible without a DI framework or reflection.

Spring Framework is the dominant DI container in the Java ecosystem. It manages bean lifecycle and wiring. With Spring, you annotate a class with @Component (or @Service, @Repository) and declare dependencies with @Autowired on constructors, setters, or fields. The Spring IoC container creates and wires beans at application startup. Java EE (now Jakarta EE) provides the CDI specification with @Inject for the same purpose.

The core benefit is testability. A class that creates its own dependencies is hard to unit test because you cannot substitute a mock. A class that accepts its dependencies via constructor can be instantiated in a test with mock objects, isolating behavior entirely. The second benefit is decoupling: your class depends on an interface, not a concrete implementation. The injected concrete type can be swapped without changing the class.

DI also centralizes configuration: which implementations to use, lifecycle scope (singleton, prototype, request-scoped), and initialization order are managed in one place rather than scattered across the codebase.

Question 45

What is the difference between shallow copy and deep copy in Java?

Accepted Answer

A shallow copy creates a new object and copies the top-level field values from the original. For primitive fields, this means the value itself is copied. For reference-type fields, only the reference (memory address) is copied — both the original and the copy point to the same nested objects. Modifying a mutable nested object through the copy will therefore affect the original and vice versa.

A deep copy creates a new object and recursively copies all referenced objects as well, producing a completely independent object graph. The copy shares no mutable state with the original. Modifying any nested object in the copy has no effect on the original.

Java's Object.clone() method performs a shallow copy by default when you override it and call super.clone(). To perform a deep copy via clone(), you must override clone() in each referenced class and explicitly clone each reference field.

Practical approaches for deep copying: override clone() with manual deep copy logic; use copy constructors where each class provides a constructor that takes an instance and copies all fields recursively; use serialization (serialize the object to a byte array and deserialize it back — produces a fully disconnected copy, but requires Serializable and is relatively slow); or use a library like Apache Commons Lang's SerializationUtils.clone() or ModelMapper.

Immutable objects change the calculus. String, Integer, and other immutable types are safe to share — a shallow copy of a field pointing to an immutable object is functionally equivalent to a deep copy because neither party can mutate the shared object.

The right choice depends on your use case. Shallow copies are fast and sufficient for read-only scenarios or objects with only primitive/immutable fields. Deep copies are required when you need fully independent state, such as when storing a snapshot of a mutable object or preventing unintended aliasing bugs.

Question 46

What are design patterns in Java?

Accepted Answer

Design patterns are proven, reusable solutions to commonly recurring software design problems. They are not code libraries or algorithms — they are templates describing how to structure classes and objects to solve a specific type of design challenge. The term was popularized by the Gang of Four (GoF) book (Gamma, Helm, Johnson, Vlissides, 1994), which cataloged 23 fundamental patterns.

The GoF patterns are organized into three categories. Creational patterns address object creation: Singleton (one instance), Factory Method (defer instantiation to subclasses), Abstract Factory (families of related objects), Builder (step-by-step construction of complex objects), and Prototype (clone-based creation). Structural patterns address class and object composition: Adapter (compatibility bridge between interfaces), Decorator (add behavior dynamically without subclassing), Facade (simplified interface to a complex subsystem), Proxy (controlled access to another object), and Composite (tree structures of objects). Behavioral patterns address communication and responsibility: Strategy (interchangeable algorithms), Observer (event notification), Command (encapsulate requests as objects), Iterator (sequential access), Template Method (define skeleton, defer steps to subclasses), and Chain of Responsibility.

Java's standard library embeds many of these patterns. java.util.Iterator is the Iterator pattern. java.io streams use Decorator heavily. java.lang.Runtime.getRuntime() is Singleton. The Collections.sort(list, comparator) API is Strategy. java.util.Observable (deprecated) was Observer.

Patterns have tradeoffs. Singleton introduces global state, making testing harder. Deep Decorator chains become hard to debug. Overusing patterns adds accidental complexity. The key is recognizing the problem a pattern solves and applying it deliberately, not pattern-matching for its own sake.

In interviews, naming patterns is table stakes. Demonstrating which problem each pattern solves and when not to use it distinguishes senior-level thinking.

Question 47

What is the Factory design pattern?

Accepted Answer

The Factory pattern encapsulates object creation behind a method or class, so callers request objects by type or configuration without depending on concrete class names or constructors. This decouples the consuming code from the instantiation details, making the system easier to extend and test.

There are two GoF-recognized factory patterns. Factory Method defines a method (typically abstract) in a superclass or interface for creating an object, and subclasses override it to return different concrete types. The creator class is extended to vary the product. Abstract Factory provides an interface for creating families of related objects — multiple factory methods grouped together — so entire product families can be swapped by substituting the factory implementation.

In practice, many Java codebases use Simple Factory — a static or instance method that takes a parameter and returns the appropriate subtype — which is not an official GoF pattern but is extremely common. NumberFormat.getInstance(locale) and Calendar.getInstance() in the JDK are examples of this style.

The key benefit is the Open/Closed Principle: you can add new product types by adding a new subclass or factory implementation without modifying existing calling code. The caller only depends on the product interface, not the concrete product.

For testing, factory methods make it straightforward to substitute a test factory that returns mocks or in-memory implementations instead of real ones — without changing the code under test.

Common implementation in Java: an interface or abstract class defines the product contract; a factory class or method takes a string, enum, or configuration object and instantiates the correct concrete implementation using a switch or map; the caller receives the product typed as the interface.

When combined with Dependency Injection, factories are often injected themselves, allowing even the factory strategy to be swapped at configuration time.

Question 48

What is the Builder design pattern?

Accepted Answer

The Builder pattern separates the construction of a complex object from its representation, allowing the same construction process to produce different configurations. It is most valuable when an object requires many parameters, some of which are optional, because the alternative — telescoping constructors or large constructor parameter lists — is unreadable and error-prone.

The canonical Java implementation uses a public static nested Builder class. The outer object's constructor is private and takes only the Builder. Client code chains setter-style methods on the Builder, then calls build() to get the final object. Because each setter returns the Builder itself, the methods chain fluently. The resulting outer object is typically immutable — all its fields are final and set only in the private constructor.

Compared to JavaBeans setters, Builder provides immutability (the object can't be partially constructed in a visible state) and thread-safety (no setters means no mutation after construction). Compared to a constructor with many parameters, Builder is self-documenting — .timeout(5000).retries(3) communicates intent that new Connection(5000, 3) does not.

Java standard library examples: StringBuilder is a mutable builder that produces an immutable String. ProcessBuilder constructs a Process. In modern Java, Locale.Builder, HttpRequest.Builder (java.net.http), and Stream.Builder follow this pattern.

Lombok's @Builder annotation generates the nested builder class at compile time, eliminating boilerplate. This is widely used in production codebases.

The Director variant (from GoF) adds a Director class that encapsulates common construction sequences, but this is rarely used in Java — most codebases let callers drive the builder directly.

Builder is appropriate when objects have more than 3-4 optional parameters or when construction involves validation that is cleanest to perform once in build() rather than across multiple setters.

Question 49

What is the difference between Heap and Stack memory in Java?

Accepted Answer

In Java, memory is divided into two primary regions: the stack and the heap.

Stack memory is allocated per thread. It stores method call frames, each containing local variables, parameters, and the return address. When a method is called, a new frame is pushed; when it returns, the frame is popped and memory is instantly reclaimed. This makes stack allocation extremely fast — just a pointer adjustment. Local primitive variables live entirely on the stack. Local reference variables also live on the stack, but they point to objects on the heap. Stack size is typically small (512KB to 1MB by default, configurable with -Xss). If a thread's stack runs out of space, Java throws a StackOverflowError.

Heap memory is shared across all threads. It is where all objects and their instance variables are stored via the new keyword. The heap is managed by the garbage collector, which periodically reclaims objects no longer reachable from any live reference. The heap is divided into generations: young generation (Eden + Survivor spaces) for short-lived objects, and old generation for long-lived objects. Heap size is configurable with -Xms (initial) and -Xmx (maximum). When exhausted, Java throws OutOfMemoryError.

The distinction has important implications for thread safety. Stack memory is inherently thread-safe because each thread has its own stack. Heap memory is shared, so objects on the heap need synchronization for concurrent access.

The JVM can perform escape analysis to determine if an object created inside a method never escapes that method's scope. If so, the JVM may allocate it on the stack instead of the heap (scalar replacement), avoiding GC overhead entirely.

Question 50

What is garbage collection in Java?

Accepted Answer

Garbage collection (GC) in Java is the automatic process of identifying objects on the heap that are no longer reachable from any GC root (active threads, static fields, local variables on stack) and reclaiming their memory. The developer is freed from manual memory management, eliminating use-after-free and double-free bugs common in C/C++.

The JVM heap is divided generationally based on the observation that most objects die young (the weak generational hypothesis). The Young Generation holds newly created objects and is collected frequently in Minor GC events, which are fast. Objects that survive enough Minor GCs are promoted to the Old Generation (Tenured), collected less frequently in Major GC or Full GC events. Some collectors also use a Metaspace (formerly PermGen) for class metadata.

GC algorithms in modern JVMs include Serial GC (single-threaded, for small heaps), Parallel GC (throughput-focused, multi-threaded), CMS (Concurrent Mark Sweep — low pause but deprecated in Java 9, removed in 14), G1GC (Garbage First — default since Java 9, balances throughput and latency), ZGC (scalable, near-zero pause times, production-ready since Java 15), and Shenandoah (Red Hat, low-latency concurrent GC).

The GC process generally involves: mark (traverse from GC roots, mark live objects), sweep (reclaim unmarked objects), and optionally compact (slide live objects together to eliminate fragmentation). Compacting collectors avoid fragmentation but require a Stop-the-World pause while references are updated.

GC tuning involves choosing the right collector for your workload, sizing the heap and generation spaces (-Xms, -Xmx, -XX:NewRatio), and monitoring GC logs for pause frequency and duration. For latency-sensitive applications, ZGC or Shenandoah are preferred because they do most work concurrently with the application.

Question 51

What are the different types of garbage collectors in Java?

Accepted Answer

Java provides several garbage collector implementations, each representing a different set of tradeoffs between throughput, latency, and resource usage.

Serial GC (-XX:+UseSerialGC) uses a single thread for all GC work and Stop-the-World pauses for both Minor and Major collection. It is appropriate for small heaps (< 100 MB) and client applications or containers with a single CPU.

Parallel GC (-XX:+UseParallelGC, default before Java 9) uses multiple threads for GC work, maximizing throughput. It still uses Stop-the-World pauses but parallelizes the collection work. Best for batch processing jobs where throughput matters more than latency.

CMS (Concurrent Mark Sweep, -XX:+UseConcMarkSweepGC) performed most marking and sweeping concurrently with application threads, reducing pause times. However it did not compact the heap, leading to fragmentation. It was deprecated in Java 9 and removed in Java 14.

G1GC (Garbage First, default since Java 9) divides the heap into equal-sized regions rather than contiguous Young/Old areas. It prioritizes regions with the most garbage (hence 'Garbage First'), performs concurrent marking, and compacts incrementally during mixed collections. It targets a configurable pause time goal (-XX:MaxGCPauseMillis). G1 is the best general-purpose choice for heaps between 6 GB and 32 GB with mixed throughput/latency requirements.

ZGC (-XX:+UseZGC, production-ready since Java 15) performs marking, relocation, and remapping concurrently using load barriers and multi-colored pointers, keeping Stop-the-World pauses under 1ms regardless of heap size. Optimal for latency-sensitive services with large heaps.

Shenandoah (-XX:+UseShenandoahGC, from Red Hat, available in OpenJDK) similarly achieves concurrent compaction using a Brooks forwarding pointer indirection, with pause times competitive with ZGC. Best for applications that cannot afford long GC pauses but are running on commodity JVMs without ZGC availability.

Question 52

What is the difference between wait() and sleep() in Java?

Accepted Answer

wait() and sleep() both pause thread execution, but they serve entirely different purposes and behave very differently with respect to locks.

sleep(long millis) is a static method on Thread. It suspends the current thread for the specified duration, or until interrupted. Critically, sleep() does not release any locks or monitors the thread holds. It is used for rate limiting, polling delays, or scheduling — it has nothing to do with inter-thread coordination.

wait() is an instance method on Object. It must be called from within a synchronized block on the object being waited on. When called, it atomically releases the monitor lock on that object and suspends the thread. The thread remains suspended until another thread calls notify() or notifyAll() on the same object, or until the optional timeout expires. After being notified, the thread re-acquires the lock before proceeding.

This atomic release-and-wait property is why wait() is used for condition-based coordination. The classic producer-consumer pattern: the consumer calls synchronized(queue) { while (queue.isEmpty()) queue.wait(); }, releasing the lock so the producer can enter the synchronized block and call queue.notifyAll().

Both methods throw InterruptedException, which must be handled. Both should be called in a while loop that re-checks the condition, not an if statement — to guard against spurious wakeups (OS-level interruptions where wait() returns without being notified).

In modern Java, wait/notify is largely replaced by higher-level concurrency utilities: Condition (from java.util.concurrent.locks.Lock) provides await()/signal()/signalAll() with the same semantics but more flexibility, and BlockingQueue handles the producer-consumer pattern without any manual synchronization. wait/notify is still important to understand for interviews and when maintaining legacy code.

Question 53

What is the difference between notify() and notifyAll() in Java?

Accepted Answer

Both notify() and notifyAll() are Object methods that wake threads suspended in wait() on the same object's monitor. The critical difference is how many threads they wake.

notify() wakes exactly one thread from the wait set. The JVM chooses which thread arbitrarily — there is no fairness guarantee. The notified thread does not immediately execute; it must re-acquire the monitor lock (competing with all other threads that want it), then re-check its condition before proceeding.

notifyAll() wakes all threads in the wait set. They all compete to re-acquire the monitor. One wins, re-checks its condition, proceeds if satisfied, releases the lock. The others proceed one at a time in an undefined order, each re-checking its condition.

notify() is safe only when two strict conditions hold: (1) all waiting threads are identical — they wait on the same condition and perform the same action upon waking, and (2) only one thread needs to be activated per notification. If different threads wait on different conditions (e.g., some threads wait for 'buffer not full' and others for 'buffer not empty'), notify() may wake the wrong type of thread, which re-evaluates its condition, finds it unsatisfied, and calls wait() again — while the thread that should have been notified never wakes up. This is the classic missed wakeup / deadlock scenario.

notifyAll() is the safe default. The cost is thundering herd: many threads wake, compete for the lock, find their condition unsatisfied, and go back to sleep. For performance-critical code with many waiting threads and high throughput, this can be measurable.

The modern solution is java.util.concurrent.locks.Condition, which supports multiple condition queues per lock. In a producer-consumer pattern, you maintain a notFull and notEmpty Condition separately — signal() on notFull wakes only producer threads, signal() on notEmpty wakes only consumer threads. This gives the precision of notify() without the correctness risk.

Question 54

What is an immutable class and how do you create one?

Accepted Answer

An immutable class is a class whose instances cannot be modified after construction. Once created, an immutable object's state is fixed for its lifetime. java.lang.String, Integer, and the other wrapper types are the canonical examples.

Immutable objects offer significant advantages: they are inherently thread-safe (no synchronization needed since state cannot change), safe to share and cache, easy to reason about, and make excellent keys in HashMap or elements in HashSet because their hashCode never changes.

To create an immutable class, follow these five rules:

1. Declare the class final (or use private constructors with static factory methods) to prevent subclassing that could override methods and introduce mutability.
2. Make all fields private and final so they are set once in the constructor and cannot be reassigned.
3. Do not provide any setter methods or other mutating methods.
4. Perform defensive copies of mutable objects passed into the constructor. If a constructor accepts a Date or a List, copy it immediately — otherwise a caller could mutate the external reference after construction, changing the object's state.
5. Perform defensive copies of mutable objects returned from getters. If a field is a mutable collection, return a copy or an unmodifiable view — otherwise callers can mutate the internal state through the reference.

Record classes introduced in Java 16 provide a concise immutable class syntax: the compiler auto-generates a canonical constructor, private final fields, accessors (not getters in JavaBeans style), equals(), hashCode(), and toString(). However, records don't automatically deep-copy mutable fields — you still need a compact constructor to perform defensive copies if fields contain mutable types.

A common mistake is thinking that declaring a field final makes the object it references immutable. final only prevents reassigning the reference; the referenced object itself can still be mutated if it is a mutable type.

Question 55

What is the difference between String, StringBuilder, and StringBuffer?

Accepted Answer

String, StringBuilder, and StringBuffer all represent character sequences in Java but differ critically in mutability and thread safety.

String is immutable. Every operation that appears to modify a String (concat, replace, substring) returns a new String object. The original is unchanged. Because Strings are immutable, they are inherently thread-safe, safely cacheable, and interned in the String pool for memory efficiency. The downside is that building a String with repeated concatenation inside a loop creates many intermediate objects, causing GC pressure. The JIT compiler optimizes simple loop-external concatenations using StringBuilder, but explicit StringBuilder is clearer and more efficient for loop-based construction.

StringBuilder is a mutable sequence of characters. Its internal char array can be modified in-place via append(), insert(), delete(), reverse(), and replace(). It is not thread-safe — concurrent access from multiple threads without external synchronization produces unpredictable results. StringBuilder should be the default choice for string construction within a single thread or method.

StringBuffer has the same API as StringBuilder but all its methods are synchronized, making it thread-safe. However, this synchronization has a cost — StringBuffer is measurably slower than StringBuilder in single-threaded contexts. StringBuffer was the original Java 1.0 API; StringBuilder was introduced in Java 5 as a faster single-threaded alternative. In modern Java, StringBuffer is rarely used — if you need thread-safe string construction, higher-level concurrent patterns are usually preferred over StringBuffer.

For string concatenation with the + operator: in Java 9+, the JVM uses invokedynamic and StringConcatFactory which generates efficient bytecode, making simple concatenation outside loops competitive. For building strings in loops, always prefer StringBuilder explicitly.

Question 56

What is the difference between static and instance variables in Java?

Accepted Answer

Static variables (also called class variables) are declared with the static keyword and belong to the class itself rather than any particular object. There is exactly one copy of a static variable in memory, shared by all instances of the class. They are initialized when the class is first loaded by the class loader and persist for the class's lifetime.

Instance variables are declared without static and belong to individual object instances. Each time you create a new object with new, a new copy of each instance variable is allocated. Changes to one object's instance variable have no effect on another object's copy.

A static variable declared as public static int count = 0 in a Counter class is incremented by every Counter object created. Every instance reads and writes the same counter. An instance variable private int id in the same class is unique per object — each counter has its own id.

Static variables are accessed via the class name: Counter.count. While Java allows accessing static members through an instance reference (myCounter.count), this is misleading and discouraged — IDEs and checkstyle tools flag it because it implies the variable is per-instance when it is not.

Memory layout: instance variables are stored in each object's heap allocation. Static variables are stored in the method area (metaspace), associated with the class's Class object.

Common use cases for static variables: constants (public static final String DEFAULT_NAME), singleton instances, shared counters or registries, and cached computed values. Instance variables model per-object state: a Person's name, age, and address.

Thread safety: static variables shared across instances require synchronization or use of AtomicInteger/AtomicReference if multiple threads can modify them. Instance variables are generally only accessed by the thread that owns the object, but this depends on whether the object is shared.

Question 57

What is the purpose of the super keyword in Java?

Accepted Answer

The super keyword in Java is a reference to the parent (superclass) of the current class. It has three primary uses: calling a parent class constructor, calling an overridden parent class method, and accessing a parent class field hidden by a subclass field of the same name.

Calling a parent constructor: super() or super(args) must be the first statement in a subclass constructor. If omitted, the compiler inserts an implicit super() call that invokes the parent's no-arg constructor. If the parent class does not have a no-arg constructor (because it defines only parameterized constructors), the subclass must explicitly call super(args) — otherwise the code will not compile.

Calling an overridden parent method: when a subclass overrides a method, the parent's version is still accessible as super.methodName(). This is useful when you want to extend, not replace, the parent's behavior. For example, a subclass's toString() might return super.toString() + ", additionalField=" + field, building on the parent's representation.

Accessing hidden fields: if a subclass declares a field with the same name as a parent field, the parent's field is shadowed. super.fieldName accesses the parent's field. This pattern is rare and generally a code smell — shadowing fields leads to confusing behavior.

super cannot be chained (super.super.method() is not valid in Java). This is deliberate: deep chains would couple subclasses to grandparent implementation details, which is considered harmful to encapsulation.

A key distinction: super() is for constructor chaining up the hierarchy; this() is for constructor chaining within the same class. They cannot both be the first statement, so you must choose one or the other in a given constructor.

Question 58

What is the purpose of the this keyword in Java?

Accepted Answer

The this keyword in Java is an implicit reference to the current object — the instance on which the current method or constructor is executing. It has four main uses.

Disambiguating fields from parameters: when a constructor or setter parameter has the same name as an instance field, this.fieldName refers to the field and fieldName alone refers to the parameter. Without this, the parameter shadows the field and the assignment is a no-op (fieldName = fieldName assigns the parameter to itself). This is the most common use: this.name = name; in a constructor.

Constructor chaining with this(): inside a constructor, this() calls another constructor in the same class. Like super(), it must be the first statement. This eliminates duplicated initialization logic across overloaded constructors. For example, a no-arg constructor can call this(defaultValue) to delegate to the single authoritative parameterized constructor.

Passing the current object as an argument: this can be passed to a method or constructor that expects an instance of the current type. Common in event listeners (button.addActionListener(this)) and builder patterns (return this in a builder method to enable chaining).

Returning the current object from a method: return this; is the mechanism behind method chaining / fluent APIs. StringBuilder.append() returns this, enabling sb.append("a").append("b").

Inside a lambda expression, this refers to the enclosing class instance, not the lambda itself — because lambdas are not their own object. This is a key distinction from anonymous inner classes, where this refers to the anonymous class instance.

this cannot be used in a static context — static methods have no current object, so the compiler rejects this in static methods.

Question 59

What are generics in Java?

Accepted Answer

Java generics, introduced in Java 5, allow classes, interfaces, and methods to be parameterized by type. Instead of writing a container that holds Object and requires manual casting, you declare List, and the compiler enforces that only String values are added and returns String values without explicit casts. This moves type errors from runtime ClassCastException to compile-time errors, significantly improving code safety and clarity. Generic classes are declared with a type parameter: class Box { private T value; }. Generic methods declare their type parameter before the return type: public T identity(T value). Type parameters are conventionally named T (type), E (element), K (key), V (value), R (return type). Bounded type parameters constrain the valid type arguments. > requires T to implement Comparable, enabling comparisons within the generic method. restricts T to Number subclasses. Wildcards add flexibility when consuming generic types without writing generic methods. List accepts a list of any type (useful when only reading, via the upper-bounded principle). List accepts List, List etc. — you can read from it safely but not write (since the concrete type is unknown). List accepts List, List, List

Question 60

What is type erasure in Java generics?

Accepted Answer

Type erasure is the mechanism by which the Java compiler removes all generic type parameters from the bytecode it produces. The resulting .class file contains no information about the specific type arguments used — only the erasure (the raw type or the bound) remains. This was a deliberate compatibility decision: generics were added to Java 5 without requiring changes to the JVM or breaking pre-existing bytecode. During compilation, the compiler replaces each unbounded type parameter T with Object, and each bounded type parameter > with Comparable. All casts necessary for type safety are inserted by the compiler at call sites. The programmer never writes these casts; the compiler guarantees they are correct based on the compile-time generic types. The practical consequences of type erasure: 1. No runtime type information: List and List are the same type at runtime — both are just List. You cannot write obj instanceof List or cast to List safely if the source is untyped. Unchecked casts produce an unchecked cast warning rather than a compile error, because the compiler knows it cannot verify the runtime type. 2. No generic arrays: new T[10] is illegal. The JVM creates the array with the erased type at runtime, which would be Object[], defeating type safety. 3. No instantiation of type parameters: new T() is illegal because T is not known at runtime. Workarounds involve passing a Class token or a Supplier factory. 4. No overloading by generic parameter: void process(List l) and void process(List l) have the same erasure (void process(List l)) and cannot coexist. 5. Bridge methods: when a subclass overrides a generic method with a specific type, the compiler generates a synthetic bridge method with the erased signature that delegates to the typed override, maintaining polymorphism correctly. Heap pollution is a related concept: a variable of parameterized type can refer to an object that is not of that type, producing a ClassCastException at an unexpected location far from the problematic cast.

Java Interview Questions — What Senior Engineers Need to Know

All 60 Questions

How to Prepare

Related Topics

Test Your Knowledge