Java Interview Questions

javac compiles source to platform-independent bytecode in a .class file. The JVM loads that bytecode, verifies it, and executes it — interpreting at first, then JIT-compiling hot methods to native code.

JVM runs bytecode. JRE = JVM plus the standard library, enough to run an application. JDK = JRE plus the tools to build one (javac, jar, javadoc).

Java is pass-by-value everywhere. For an object, the value copied is the reference — so the method can mutate what the reference points at, but reassigning the parameter only rebinds the local copy.

void swap(int[] a, int[] b) { int[] t = a; a = b; b = t; }   // no effect on the caller
void fill(int[] a)            { a[0] = 42; }                  // caller sees this

That is why the standard idiom is to return a new value, or to mutate an object the caller already holds.

String is immutable, so s += x allocates a new string and copies the whole contents each time. In a loop over n items that is O(n²) copying.

StringBuilder sb = new StringBuilder();
for (String part : parts) sb.append(part);
String out = sb.toString();

StringBuilder keeps a growable char buffer and appends in amortised O(1). StringBuffer is the synchronised version — only worth the lock if the builder is genuinely shared across threads. Outside a loop, plain + is fine: the compiler rewrites it to a builder for you.

If two objects are equal, they must return the same hash code. The converse is not required — unequal objects may collide.

Keep the fields used in equals and hashCode identical, and keep them effectively immutable — mutating a key after insertion strands it in the wrong bucket.

HashMap: O(1) average lookup, no order guarantee — the default. LinkedHashMap: same cost plus a linked list keeping insertion order (or access order, which makes an LRU cache almost free). TreeMap: a red-black tree, O(log n), keys always sorted and range queries available.

Inheritance couples a subclass to its parent’s implementation: a change upstream can break every descendant, and you get the whole interface whether it fits or not. Composition holds a collaborator as a field and delegates, so you expose only what you mean to.

Inheritance earns its place when the relationship is genuinely is-a and the base is designed for extension — documented hooks, or an abstract class that exists precisely to be subclassed.

On a class, it cannot be subclassed. On a method, it cannot be overridden. On a field, it must be assigned exactly once and cannot be reassigned after.

A final field also carries a memory-model guarantee: once a constructor completes, other threads see the fully-initialised value without extra synchronisation.

It is global mutable state: it hides dependencies from a class’s signature, makes tests order-dependent, and is awkward to substitute. Prefer passing the instance in.

public enum Config {
  INSTANCE;
  private final Properties props = load();
  public String get(String k) { return props.getProperty(k); }
}

If you do need one, an enum is the safest form — the JVM guarantees a single instance, initialisation is thread-safe, and it is immune to the serialisation and reflection tricks that defeat a lazily-built holder.

A subclass must be usable anywhere its base is expected without changing correctness. Violations look like a subclass that strengthens what it demands or weakens what it promises.

class Rectangle { void setWidth(int w); void setHeight(int h); }
class Square extends Rectangle { /* setWidth also sets height */ }

// caller: r.setWidth(5); r.setHeight(4); assert r.area() == 20;
// holds for Rectangle, fails for Square

The fix is not a cleverer Square: it is recognising that an immutable Shape with an area() is the right model, and mutable-rectangle is not a supertype of square.

They let an interface gain a method without breaking every existing implementer — which is how Collection.stream() was added to interfaces implemented across the whole ecosystem.

They are for evolution, not for shipping behaviour. State still cannot live on an interface, so anything needing fields belongs in an abstract class.

volatile guarantees visibility and ordering: a write is published to other threads and cannot be reordered across the access. It does not give atomicity — count++ on a volatile is still read-modify-write and still races.

volatile boolean running = true;   // correct: a flag one thread sets, another reads
volatile int  count   = 0;
count++;                           // wrong: use AtomicInteger

synchronized gives both atomicity and visibility, at the cost of blocking. For a single counter, AtomicInteger is a compare-and-swap loop with neither lock nor race.

Streams are lazy and composable: intermediate operations build a pipeline that runs once on terminal invocation, so filter().map().findFirst() touches only the elements it needs. They also express intent — the reader sees "filter then map", not index bookkeeping.

Streams are single-use: consuming one twice throws IllegalStateException.

It is a return type that makes "there might be no value" part of the signature, so the caller cannot forget the empty case the way a bare null lets them.

Optional<User> findByEmail(String email);         // good: absence is expected
user.getName().orElse("anonymous");                // good

void setUser(Optional<User> u);                    // misuse: parameters
private Optional<String> name;                     // misuse: fields

Do not use it for parameters or fields — it is not serialisable, adds an allocation, and a null Optional is the worst of both worlds. And never call get() without isPresent(); that is just a null pointer with extra steps.

Heap holds objects and is what the garbage collector manages. Stack is per-thread, holding frames, locals and return addresses. Metaspace holds class metadata (native memory since Java 8, replacing PermGen).

OutOfMemoryError: Java heap space means live objects exceed the heap — usually a leak such as an ever-growing static collection, not a genuinely large working set. StackOverflowError is unbounded recursion. Metaspace exhaustion usually means classloader leaks, which is a classic in redeployed application servers.

A thread is an expensive OS resource; creating one per task means unbounded thread counts under load and a scheduler that thrashes. An ExecutorService owns a bounded pool and a queue, so concurrency stays capped and tasks queue instead of overwhelming the machine.

ExecutorService pool = Executors.newFixedThreadPool(8);
Future<Report> f = pool.submit(() -> build(id));
Report r = f.get();          // blocks until ready
pool.shutdown();

Size the pool to the work: roughly the core count for CPU-bound tasks, higher for I/O-bound ones that spend their time blocked. Virtual threads (Java 21) change the calculus for blocking I/O — they are cheap enough to create per task.