<\/p>\n
The JVM is the actual runtime that executes bytecode, it handles class loading, bytecode verification, JIT compilation, and garbage collection, and it’s the piece that makes Java portable, since every platform ships its own JVM but the compiled bytecode stays the same everywhere. The JRE is the JVM plus the core class libraries (java.lang, java.util, and so on) needed to run a compiled program, but it has no compiler in it.<\/p>\n
The JDK is the JRE plus the development tools, javac to compile source into bytecode, jar, javadoc, jshell, and a debugger. If you’re only running a compiled .jar you technically only need a JRE, but if you’re compiling code you need the full JDK, and most people just install the JDK now since standalone JRE-only installers have become rare.<\/p>\n
<\/div><\/div><\/div>\n
What's the difference between method overloading and method overriding?<\/span>OOP Basics<\/span>Easy<\/span><\/span><\/span><\/button><\/p>\n
Overloading is having multiple methods with the same name but different parameter lists in the same class, and which one gets called is decided at compile time based on the argument types you pass, that’s static binding. Overriding is a subclass providing its own implementation of a method with the exact same signature as its superclass, and which version actually runs is decided at runtime based on the object’s real type, that’s dynamic binding, and it’s the mechanism that makes polymorphism work.<\/p>\n
A detail that trips people up: changing only the return type doesn’t create an overload, the compiler needs different parameters to distinguish two methods with the same name, and when overriding, the return type has to be the same or a covariant subtype of the parent’s, otherwise it’s just a compile error, not a new overload.<\/p>\n
<\/div><\/div><\/div>\n
<\/span>Medium questions<\/h2>25<\/span><\/div><\/div><\/div>\n
Why do you need to override hashCode() whenever you override equals()?<\/span>Core Java<\/span>Medium<\/span><\/span><\/span><\/button><\/p>\n
Because HashMap, HashSet, and every hash-based collection use hashCode() to pick a bucket before it ever calls equals() to confirm a match. If two objects are equal by your equals() logic but return different hash codes, the map will happily store both in different buckets, and a lookup for the second one silently returns null even though a “duplicate” already exists somewhere else in the table.<\/p>\n
The contract from the Object class is specific: equal objects must produce equal hash codes, though the reverse isn’t required. Most interviewers ask a follow-up: what breaks if you only override equals()? The honest answer is that everything compiles fine, and the bug only shows up at runtime, inside a Set that quietly holds duplicates nobody notices until a report comes back wrong.<\/p>\n
<\/div><\/div><\/div>\n
Explain why Java strings are immutable, and what the string pool has to do with it.<\/span>Strings<\/span>Medium<\/span><\/span><\/span><\/button><\/p>\n
A String object can’t change after creation. Every “modification”, concatenation, substring, replace, actually returns a new object. That immutability is what makes the string pool possible: since a literal can never change out from under another reference, the JVM can safely reuse one copy in a shared pool (part of heap memory since Java 7) instead of allocating a fresh object for every identical literal.<\/p>\n
This is also why == and .equals() diverge for strings. new String(“java”) == “java” returns false, because new explicitly bypasses the pool and allocates a separate object, while “java” == “java” (both literals) returns true because they point at the same pooled instance. Interviewers use this to check whether you understand reference equality versus value equality, not just whether you memorized the trick.<\/p>\n
<\/div><\/div><\/div>\n
What's a ConcurrentModificationException, and how do fail-fast iterators differ from fail-safe ones?<\/span>Collections<\/span>Medium<\/span><\/span><\/span><\/button><\/p>\n
ArrayList and HashMap track a modCount field that increments on every structural change. Their iterators capture that count when created and check it on every next() call. If something else, another thread, or your own loop body, modifies the collection outside the iterator, next() throws ConcurrentModificationException. It’s a best-effort check, not a guarantee, so don’t rely on it for real thread safety.<\/p>\n
Fail-safe collections like CopyOnWriteArrayList or ConcurrentHashMap sidestep the exception entirely. CopyOnWriteArrayList’s iterator works off a snapshot array taken at creation time, so it never throws, but it also won’t see updates made after that snapshot. The fix for the common case, removing items while iterating a plain ArrayList, is simply to call the iterator’s own remove() method instead of the list’s.<\/p>\n
<\/div><\/div><\/div>\n
If a finally block has a return statement, what happens to a value or exception from the try block?<\/span>Exceptions<\/span>Medium<\/span><\/span><\/span><\/button><\/p>\n
The finally block always runs, even after a return or a thrown exception in the try block, and if finally itself contains a return statement, it wins outright. It silently discards whatever the try block was about to return and swallows any exception that was in flight.<\/p>\n
This gotcha shows up almost verbatim across interview loops because it tests whether you actually understand control flow instead of assuming finally is “just cleanup code.” The safe pattern is to never put a return, break, or continue inside finally. Try-with-resources, since Java 7, handles the common cleanup case more safely by auto-closing any AutoCloseable resource in reverse declaration order, without needing an explicit finally block at all.<\/p>\n
<\/div><\/div><\/div>\n
volatile versus synchronized: what does each one actually guarantee?<\/span>Concurrency<\/span>Medium<\/span><\/span><\/span><\/button><\/p>\n
volatile guarantees visibility only: a write to a volatile field is immediately visible to every thread that reads it afterward, because the JVM won’t let that value sit cached in a CPU register or get reordered across the write. It guarantees nothing about atomicity, count++ on a volatile int is still a read-modify-write with a race condition, volatile just makes the race visible sooner.<\/p>\n
synchronized guarantees both visibility and mutual exclusion. Only one thread can hold the monitor at a time, so compound operations become atomic, at the cost of contention and potential context-switch overhead. The short version interviewers want: reach for volatile on simple status flags and one-way signals, reach for synchronized or an AtomicInteger when the operation is actually a compound read-modify-write.<\/p>\n
<\/div><\/div><\/div>\n
How would you implement a thread-safe Singleton without paying a synchronization cost on every call?<\/span>Concurrency<\/span>Medium<\/span><\/span><\/span><\/button><\/p>\n
The naive approach, marking the whole getInstance() method synchronized, works but forces every caller through a lock forever, even though the lock is only needed once. The initialization-on-demand holder idiom avoids that entirely by relying on the JVM’s own guarantee that a class isn’t initialized until it’s first referenced, and that class initialization is already thread-safe.<\/p>\n
java<\/span>Copy<\/button><\/div>\n\npublic class ConfigLoader {\n\n private ConfigLoader() {}\n private static class Holder {\n\n static final ConfigLoader INSTANCE = new ConfigLoader();\n\n }\n public static ConfigLoader getInstance() {\n\n return Holder.INSTANCE;\n\n }\n\n}\n<\/code><\/pre><\/div><\/p>\nDouble-checked locking with a volatile field is the other accepted answer, and older codebases use it a lot, but the holder idiom is shorter and doesn’t depend on getting the volatile declaration exactly right.<\/p>\n
<\/div><\/div><\/div>\n
Why do most JVM garbage collectors split the heap into young and old generations?<\/span>GC<\/span>Medium<\/span><\/span><\/span><\/button><\/p>\n
The weak generational hypothesis: empirically, most objects die young, and the ones that survive tend to live a long time. Collectors optimize for that shape instead of scanning the whole heap every cycle.<\/p>\n
Minor GCs run frequently against just the small Young generation using a copying collector: live objects get copied from Eden into a Survivor space, and objects that survive enough cycles (tracked by an age counter, the tenuring threshold) get promoted into Old. Old-generation collections happen far less often, since most of what lives there is genuinely long-lived, but they’re more expensive when they do run, typically a mark-sweep-compact pass across a much bigger region. Oracle’s HotSpot GC Tuning Guide<\/a> walks through exactly how this plays out for both G1 and ZGC, worth reading once instead of memorizing secondhand summaries.<\/p>\n<\/div><\/div><\/div>\n
What's the actual difference between map() and flatMap() in the Streams API?<\/span>Java 8+<\/span>Medium<\/span><\/span><\/span><\/button><\/p>\n
map() applies a function to each element and returns one result per element, so if that function itself returns a Stream, you end up with a Stream of Streams, nested one level deeper than you wanted. flatMap() applies the function and then flattens the result into a single stream, which is what you need when each input maps to zero, one, or many outputs.<\/p>\n
java<\/span>Copy<\/button><\/div>\n\nList<String> sentences = List.of(\u201cjava is verbose\u201d, \u201cstreams help a bit\u201d);\nList<String> words = sentences.stream()\n\n .flatMap(s -> Arrays.stream(s.split(\u201d \u201c)))\n\n .collect(Collectors.toList());\n\n\/\/ [java, is, verbose, streams, help, a, bit]\n<\/code><\/pre><\/div>