Java interview questions, with clear answers

The JVM (Java Virtual Machine) runs Java bytecode: it loads classes, verifies them, and executes them by interpreting and JIT-compiling them to native code. The JRE (Java Runtime Environment) is the JVM plus the standard class libraries — everything needed to run a Java program. The JDK (Java Development Kit) is the runtime plus the development tools, such as the javac compiler, jar and the debugger — what you need to write programs.

Since Java 11 there's no separate JRE download; the JDK includes the runtime.

Because the compiler doesn't produce machine code for one kind of processor. It produces bytecode (.class files) for the JVM. Every operating system has its own JVM that runs the same bytecode, so a compiled program runs on Windows, Linux or macOS unchanged — "write once, run anywhere". Note that the JVM itself is platform dependent; it's the bytecode that isn't.

Once created, a String object can't change; methods like concat() or toUpperCase() return a new String. The reasons:

• The string pool — string literals are shared, which is only safe if nobody can modify them.
• Security — strings hold file paths, URLs and class names, which mustn't change after they've been checked.
• Thread safety — immutable objects can be shared between threads without locks.
• Hash caching — the hash code is computed once, which makes Strings fast HashMap keys.

String is immutable, so building a string piece by piece in a loop creates many temporary objects. StringBuilder is mutable and fast — use it whenever you build a string step by step. StringBuffer is also mutable, but its methods are synchronised (thread-safe), which makes it slower; it's rarely needed today, because a string is seldom built by several threads at once.

For objects, == compares references — whether two variables point to the same object. (For primitives, it compares values.) equals() compares content, as defined by the class.

So new String("hi") == new String("hi") is false, while .equals() returns true. If you override equals(), you must also override hashCode() so that equal objects have equal hash codes; otherwise HashMap and HashSet behave incorrectly.

A HashMap keeps an array of buckets. To store an entry, it computes the key's hashCode(), mixes the bits, and uses the result to choose a bucket. Entries whose keys land in the same bucket are kept in a linked list. Since Java 8, a bucket that grows beyond 8 entries — once the table has at least 64 buckets — is converted into a red-black tree, so the worst case is O(log n) rather than O(n).

On get(), it finds the bucket the same way, then compares keys with equals(). When the number of entries exceeds capacity × load factor (16 × 0.75 by default), the array doubles in size and the entries are redistributed. A HashMap allows one null key and isn't thread-safe; use ConcurrentHashMap when several threads share it.

ArrayList is backed by a resizable array: get(i) is O(1) and iteration is fast, but inserting or removing in the middle shifts the elements that follow, which is O(n). LinkedList is a doubly linked list: adding or removing at either end is O(1), but get(i) has to walk the list (O(n)), and every node uses extra memory.

In practice ArrayList is the default choice, and ArrayDeque usually beats LinkedList when you need a queue or a stack.

All three implement Map. HashMap has no guaranteed order and O(1) average operations. LinkedHashMap remembers insertion order — or access order, which makes it handy for an LRU cache — at a small extra cost. TreeMap keeps its keys sorted, by natural order or a Comparator, with O(log n) operations and range methods such as headMap() and ceilingKey().

Checked exceptions are checked at compile time: a method must either catch them or declare them with throws. Examples are IOException and SQLException, which represent recoverable problems outside the program's control.

Unchecked exceptions extend RuntimeException — for example NullPointerException, ArrayIndexOutOfBoundsException and IllegalArgumentException — and usually point to bugs; the compiler doesn't force you to handle them. Errors such as OutOfMemoryError are also unchecked, and normally shouldn't be caught.

• final is a keyword. A final variable can't be reassigned, a final method can't be overridden, and a final class can't be extended.
• finally is a block after try and catch that always runs, typically to release resources — though try-with-resources is the modern way to do that.
• finalize() was a method the garbage collector might call before reclaiming an object. It was unreliable and has been deprecated since Java 9, so don't use it.

static makes a member belong to the class rather than to any object. A static variable is shared by all instances. A static method can be called without an object, as in Math.abs(), and can't use this or instance fields directly. A static block runs once, when the class is loaded. And a static nested class doesn't need an instance of the outer class. main is static so the JVM can call it without creating an object first.

The JVM automatically frees objects that can no longer be reached from any live reference — local variables, static fields or running threads.

The heap is generational. New objects go into the young generation; most of them die young, so it's collected often and cheaply (a minor GC). Objects that survive several collections move to the old generation, which is collected less often. Modern JVMs use collectors such as G1, the default since Java 9, or ZGC for very short pauses. System.gc() is only a request, and memory leaks can still happen if you hold references by mistake — for example, objects kept forever in a static collection.

You can create a thread by extending Thread and overriding run(), or by implementing Runnable and passing it to a Thread. Implementing Runnable is preferred: your class can still extend another class, the task stays separate from the thread that runs it, and the same task can be submitted to an ExecutorService. In real code you'd use executors (thread pools) rather than creating threads by hand.

synchronized runs a method or block while holding a lock — the object's monitor — so only one thread at a time can execute it on that object. It prevents race conditions on shared data, and it also guarantees that changes made inside are visible to the next thread that takes the lock.

Overusing it hurts performance and can cause deadlocks, so keep synchronised sections small. Alternatives include ReentrantLock, atomic classes such as AtomicInteger, and the concurrent collections.

• Lambda expressions — short inline functions, such as list.forEach(x -> System.out.println(x))
• Functional interfaces — interfaces with one abstract method, like Predicate, Function and Supplier
• The Stream API — filter, map and reduce collections declaratively:

List<String> adults = users.stream()
    .filter(u -> u.getAge() >= 18)
    .map(User::getName)
    .collect(Collectors.toList());

• Optional — an explicit "may or may not have a value" instead of returning null
• Default and static methods in interfaces, and the java.time date and time API

Mentioning newer features you've actually used — records, var, switch expressions or virtual threads (Java 21) — is a plus.

No. Static methods belong to the class, so a subclass method with the same signature hides the parent's method rather than overriding it; which one runs depends on the reference type, not the object. Private methods aren't visible to subclasses at all, so a method with the same name in the child is a new, unrelated method.