Java Interview Master Notes

Think of it like a restaurant. JVM is the chef — the actual engine that executes Java code. JRE is the full kitchen — chef plus all the utensils and ingredients (class libraries, runtime support) needed to actually serve food (run Java programs). JDK is the entire restaurant building — kitchen plus the architecture room where you design new recipes (javac compiler, debugger, javadoc, jar tool, etc.).

As a user who just wants to run a Java app? You install JRE. As a developer building Java apps? You install JDK. The JDK includes a JRE inside it, so you don't need both separately.

The JVM itself is a specification — not a single product. Oracle's HotSpot, OpenJ9, GraalVM are all JVM implementations. They all run the same bytecode (.class files) but differ in performance, GC strategies, startup time etc.

In C/C++, your code compiles directly to machine code — the binary is specific to Windows x86 or Linux ARM. You want to run on another OS? Recompile. Java took a different route.

When you write Java and compile with javac, you get .class files containing bytecode — an intermediate representation that's not native to any CPU. It's like a universal language that any JVM understands.

Each OS has its own JVM implementation that knows how to translate that bytecode to the native machine code of that specific platform. So the same HelloWorld.class runs on Windows, Linux, Mac — unchanged. The JVM absorbs the platform difference.

Every thread in Java gets its own Stack. When a method is called, a new frame is pushed with local variables, return address, operand stack. Method returns? Frame popped. Clean, automatic, no GC needed.

The Heap is where every object you create with new lives. It's shared across all threads (which is why you need synchronization). The GC watches the heap and collects objects with no remaining references.

The JVM Heap is itself divided: Young Generation (new objects — Eden + Survivor S0/S1), Old Generation / Tenured (long-lived objects), and before Java 8, PermGen (class metadata — now replaced by Metaspace in the native memory).

Java's GC is based on one key insight: most objects die young. You create a String to format a log line, use it, and it's garbage. These short-lived objects are the vast majority. So GC focuses most effort on the Young Generation where new objects land.

How it works step by step: New objects go to Eden (Young Gen). When Eden fills up, a Minor GC runs — it marks all reachable objects starting from GC roots (stack variables, static fields, JNI refs). Live objects are copied to Survivor space S0. On next Minor GC, S0 survivors go to S1, S1 goes to S0 (they alternate). After surviving a certain number of GC cycles (default 15, the "tenuring threshold"), objects are promoted to Old Gen.

When Old Gen fills up, a Major GC (or Full GC) runs — more expensive, longer pause. The goal of modern GC tuning is to keep Full GCs rare.

GC algorithms in Java: Serial GC (single-threaded, small apps), Parallel GC (multi-threaded, throughput focus — Java 8 default), G1GC (Garbage First — splits heap into regions, targets low pause time — Java 9+ default), ZGC (sub-millisecond pauses, Java 15+), Shenandoah (low pause, concurrent).

Think of == like asking "are these two people the same physical person?" — comparing ID cards (memory addresses). equals() is asking "do these two people have the same name?" — comparing content.

For primitives (int, char, boolean), == compares values directly (no objects involved). For objects, == compares references — same object? For Strings, == is almost always wrong because two different String objects with the same content are NOT the same reference.

The String Pool is the classic gotcha. String literals (not new String()) are interned — stored in the pool. Two literals with same content share the same reference, so == accidentally works. But new String("hello") == new String("hello") is false — two objects on heap.

HashMap uses an array of buckets. Each bucket is a linked list (or tree for 8+ entries). put(key, value): compute hash → find bucket → add node. get(key): compute hash → find bucket → traverse list. All fast — O(1) average.

But two threads calling put() simultaneously can corrupt the structure. In Java 7, resizing could cause infinite loops in multi-threaded use (now fixed but still unsafe). Never use HashMap in multi-threaded code without external synchronization.

Hashtable was the old solution — synchronized every method. Safe, but terrible performance — one lock for everything, one thread at a time. Essentially serialized access.

ConcurrentHashMap (Java 7): splits the map into 16 segments, each with its own lock. 16 threads can write simultaneously (to different segments). Much better than Hashtable.

ConcurrentHashMap (Java 8+): Even better — no segments anymore. Uses CAS (Compare-And-Swap) operations and synchronized only on individual bucket nodes. Lock granularity is now per-bucket. In practice, reads are lock-free (volatile reads). Writes lock only the specific bucket being modified.

When you run a Java program, you start a JVM process. That process has one thread at the start — the main thread. From there you spawn more threads using new Thread(runnable).start() or ExecutorService.

Java threads are kernel-level threads (1:1 with OS threads, via JNI) since the early days. This means true parallelism on multi-core CPUs. Java 19+ introduced Virtual Threads (Project Loom) — lightweight threads managed by the JVM, not the OS. You can have millions of virtual threads (vs thousands of OS threads). Virtual threads are the answer to "how do you handle 1 million concurrent connections in Java?"

Two ways to create threads: extend Thread class (bad — you waste your one inheritance slot), implement Runnable (better), or implement Callable (returns a value + can throw checked exceptions). Always prefer ExecutorService over raw threads in production.

Every Java object has an intrinsic lock (monitor). The synchronized keyword grabs that lock. Only one thread can hold a given object's lock at a time — others block.

You can synchronize a method (lock = the object) or a block (lock = any specified object). Synchronized methods are simpler; synchronized blocks are more flexible and allow finer granularity (lock only the specific object you're protecting, not the whole this).

Deadlock example in Java: Thread 1 locks Object A then tries to lock Object B. Thread 2 locks Object B then tries to lock Object A. Both block forever. Standard fix: always acquire locks in the same fixed order.

Beyond synchronized, Java's java.util.concurrent.locks package offers ReentrantLock — same mutual exclusion but with tryLock() (avoid deadlock by not waiting forever), lockInterruptibly() (respond to interrupts), and separate read/write locks (ReentrantReadWriteLock).

This is the question that separates people who just use Java from people who understand Java. Let's walk through it precisely.

Step 1 — Compilation: javac HelloWorld.java → produces HelloWorld.class with bytecode. Bytecode is not native code. It's compact, platform-neutral instructions for the JVM.

Step 2 — Class Loading: When JVM starts, the Class Loader subsystem kicks in. Three built-in loaders: Bootstrap ClassLoader (loads core Java classes from rt.jar — java.lang, java.util), Extension ClassLoader (loads from ext directories), Application ClassLoader (loads your .class files and classpath). Delegation model: child always asks parent first before loading itself.

Step 3 — Bytecode Verification: The Bytecode Verifier checks that the .class file is valid, hasn't been tampered with, and doesn't violate access rules. This is Java's security gate — ensures bytecode won't crash the JVM.

Step 4 — Execution: The Execution Engine runs the bytecode. Initially via Interpreter — reads and executes one bytecode instruction at a time (slow). The JVM tracks which methods are called frequently (hot methods). Those get compiled by the JIT (Just-In-Time) Compiler to native machine code — stored in code cache — and subsequent calls run at native speed. This is why Java warms up over time and gets faster.

Step 5 — Memory Management: GC runs in the background, cleaning the heap. Main thread starts with main(). Program exits when all non-daemon threads finish.

String in Java is immutable. When you do str = str + "world", Java doesn't modify the existing String. It creates a NEW String object and points str to it. The old object becomes garbage. This is why concatenating Strings in a loop with + is O(n²) — you're creating n objects and copying more each time.

Immutability makes Strings safe to share across threads (no sync needed), safe to use as HashMap keys (hash never changes), and allows String pooling (interning). These are features, not accidents.

StringBuilder is a mutable buffer. append() adds to the internal char array without creating new objects. Use it for building strings in loops or when concatenating many pieces. Not thread-safe.

StringBuffer is exactly like StringBuilder but every method is synchronized. Thread-safe, but the synchronization overhead makes it slower. In the real world, you rarely need StringBuffer — if you're building a string in a multi-threaded context, you usually build it locally (StringBuilder) and then share the immutable String result.