Java Interview Questions

"The JVM is the engine. It loads compiled class files, checks the bytecode is safe, and runs it, first by interpreting and then by compiling the hot parts to native code with the JIT. The JRE is the JVM plus the standard libraries, like java.lang and java.util, so it's what you need to run a Java program. The JDK is what developers install: it has the runtime plus tools like javac to compile, jar to package, and a debugger. The flow is: I write a .java file, javac turns it into bytecode, and any JVM on any operating system can run that bytecode. That's where 'write once, run anywhere' comes from: the bytecode is portable, the JVM is the platform-specific part."

"Every thread gets its own stack. Each time a method is called, a frame is pushed that holds its local variables: primitives are stored right there, and for objects the frame only holds a reference. The objects themselves always go on the heap, which all threads share, and the garbage collector frees them once nothing reachable points to them. So if I write Person p = new Person() inside a method, p is on the stack and the Person object is on the heap. This matters in practice. Local variables are naturally thread-safe because no other thread can see my stack, but objects on the heap can be shared. And the two errors tell you which area ran out: StackOverflowError usually means runaway recursion, OutOfMemoryError means the heap is full."

"The collector doesn't count references. It starts from GC roots, things like local variables on thread stacks, static fields and a few JVM internals, and marks everything it can reach. Whatever isn't marked is garbage, even if those objects point at each other in a cycle. The heap is split into generations because most objects die very young, like a temporary string built for a log line. So new objects go into the young generation, which is collected often and quickly because it's mostly garbage. Objects that survive several young collections get promoted to the old generation, which is bigger and collected less often. Some phases pause the application threads, and that's what shows up as latency spikes. Modern collectors like G1 and ZGC are designed to keep those pauses short."

"First I protect users: restart the failing instances or add capacity, and if the crashes started right after a deploy, I roll it back. At the same time I read the exact message, because OutOfMemoryError has several kinds. Java heap space means the heap is full. Metaspace points at class loading. Unable to create native thread means too many threads, not too much data. I make sure we capture a heap dump, turning on dump-on-OOM if it isn't already on, and I keep the GC logs. Raising the maximum heap might buy time, but I treat it as a stopgap, not a fix. Once it's stable, I open the dump and look at what's filling the heap and what's holding on to it. Then I fix the cause, add an alert on heap use after GC, and write up what happened."

"Since Java 8, interfaces can have default and static methods, and later private methods too, so the old line 'interfaces have no code' isn't true any more. The real difference now is state and inheritance. An interface can't hold instance fields, only constants, and a class can implement as many interfaces as it likes. An abstract class can have fields, constructors and protected helpers, but a class can extend only one. So I use an interface to describe a capability, like Comparable or a PaymentGateway contract, especially when unrelated classes need it. I'd pick an abstract class when several subclasses share real state and setup logic, for example a base report class that holds a title and a date range and implements the common steps, leaving one method abstract for the part each report does differently."

"Overloading is having several methods with the same name but different parameters, like print(int) and print(String). The compiler picks which one to call based on the declared types of the arguments, so it's decided at compile time. Overriding is when a subclass provides its own version of a method it inherited, with the same signature. Which version runs is decided at runtime from the real object, not the variable type. So if I have Animal a = new Dog() and call a.speak(), Dog's speak runs. That's runtime polymorphism. An override has rules: it can't make the method less visible, it can't throw broader checked exceptions, and it can return a more specific type. Static methods can't be overridden, only hidden, and private or final methods can't be overridden at all."

"A String can't change after it's created. Methods like toUpperCase or concat give you a new String and leave the original alone. That design has real benefits. Because nobody can change a String, the JVM can safely share one copy of each literal, which is the string pool: if two places in my code use the literal "hello", they point to the same object. It also makes Strings thread-safe for free, lets the hash code be cached so they're fast as HashMap keys, and stops someone changing a file path or class name after it's been checked. The side effect people trip on is ==. Two literals compare equal with == because they're the same pooled object, but new String("hello") is a separate object, so == is false. That's why I always compare content with equals."

"The contract says that if two objects are equal by equals, they must return the same hashCode. The reverse isn't required: different objects can collide. If I override equals and forget hashCode, each object keeps the default identity-based hash code. Then HashMap and HashSet break in a quiet way. Say I add a Point(1, 2) to a HashSet, then ask contains(new Point(1, 2)). equals would say they match, but the set first uses hashCode to pick a bucket, looks in a different bucket, and returns false. I get duplicates in sets and lookups that miss. So I build both methods from the same fields, usually with Objects.equals and Objects.hash, or I use a record, which generates both correctly. I also avoid mutable fields in the hash, because changing one after insertion strands the object in the wrong bucket."

"I make the class final so nobody can subclass it and add mutable behaviour. All fields are private and final, and there are no setters. The part people miss is mutable fields. If my class holds a List or a Date and I just store the reference passed into the constructor, the caller can still change it from outside. So I copy it on the way in, for a list with List.copyOf, which also gives me an unmodifiable list, and I never return the internal mutable object from a getter. Any method that looks like a change, like withSalary, returns a new object instead. The payoff is that the object is safe to share between threads without locks, and once I add equals and hashCode it makes a safe map key. For simple data carriers I'd reach for a record now, but I still have to copy mutable components myself."

"Internally a HashMap is an array of buckets. On put, it calls the key's hashCode, mixes the high bits into the low bits so poor hash codes still spread out, and uses that to pick a bucket index. If the bucket is empty the entry goes straight in. If another key is already there, it walks the entries and uses equals: a match replaces the value, otherwise the new entry is added. That's a collision. When one bucket gets crowded, Java converts its list into a red-black tree, so a bad hash doesn't make lookups linear. On get, it computes the same bucket and uses equals to find the key. When the number of entries passes capacity times the load factor, 0.75 by default, it doubles the array and redistributes. So lookups are constant time on average, not guaranteed."

"Hashtable and Collections.synchronizedMap make every method synchronized on one lock, so only one thread can touch the map at a time, even for reads. ConcurrentHashMap was built for concurrency. In modern versions, reads usually take no lock at all, and a write locks only the single bin it's changing, or uses a compare-and-swap if the bin is empty. So many threads can read and write different keys at once. Its iterators are weakly consistent, meaning they won't throw ConcurrentModificationException. It also refuses null keys and values, so a null from get always means 'absent'. The catch is compound actions. If I write 'if the key is missing, put a value', that's two calls, and another thread can slip in between. I use the atomic methods instead: computeIfAbsent, putIfAbsent or merge for counters."

"ArrayList stores elements in an array, so get by index is constant time. Adding at the end is cheap on average; now and then it grows the array and copies, but that cost spreads out. Inserting or removing in the middle means shifting everything after that point. LinkedList is a chain of nodes, each pointing to the next and previous, so adding or removing at either end is constant time, but get(i) has to walk the chain. People say LinkedList is better for inserting in the middle, but you still have to walk to that position first, unless you're already there with an iterator. Each node also costs extra memory and is scattered in memory, which the CPU cache doesn't like. So I use ArrayList almost always, and when I need a queue or a stack I use ArrayDeque rather than LinkedList."

"A for-each loop uses an iterator under the hood. ArrayList keeps a modification count, and the iterator remembers the value it started with. If I call list.remove inside the loop, the count changes without the iterator knowing, so on the next step it notices and throws ConcurrentModificationException. It's a fail-fast check, and despite the name it happens in a single thread. The safe ways are to use the iterator's own remove method, which keeps the two in sync, or, much cleaner since Java 8, removeIf with a condition. If I'd rather not change the original list, I stream and filter into a new one. And if many threads really do share the collection, I'd use a concurrent collection instead of relying on this check, because fail-fast behaviour is only best effort."

"The quickest correct answer is LinkedHashMap. It keeps a linked list through its entries, and if I pass true for access order in the constructor, every get moves that entry to the end. So the head of the list is always the least recently used. Then I override removeEldestEntry to return true when the size goes over my limit, and the map drops the least recently used entry after each insert. That's a working LRU cache in a few lines. If the interviewer wants it by hand, I'd keep a HashMap from key to node plus a doubly linked list: get moves the node to the front, put adds at the front, and when full I drop the tail. Both give constant-time operations. Neither version is thread-safe, so for shared use I'd wrap it with a lock or use a proper caching library."

"Checked exceptions are the ones the compiler makes me deal with: anything that extends Exception but not RuntimeException, like IOException. I either catch it or declare it with throws. Unchecked exceptions extend RuntimeException, like NullPointerException or IllegalArgumentException, and the compiler doesn't force anything. Errors, like OutOfMemoryError, are also unchecked and usually mean the JVM itself is in trouble, so I don't catch them. For my own code, I throw a checked exception when the caller can realistically do something about it, like retry or ask for a different file. I throw an unchecked one when it's a bug or a broken precondition, like a null argument, where the right fix is to change the code, not catch it. Many teams lean unchecked because checked exceptions don't fit well with lambdas and streams."

"Finally runs whether the try block finishes normally, returns early or throws, which is why it's used for clean-up. It won't run if the JVM stops first, like System.exit, a crash, or the process being killed, or if the try block never finishes. One trap: if finally has its own return, or throws, it silently replaces whatever exception was on its way out, so I never return from finally. For closing things like streams, connections or locks that implement AutoCloseable, I use try-with-resources. It closes each resource automatically, in the reverse order they were opened, even when an exception is thrown. And if close itself throws while another exception is already in flight, the original stays the main exception and the close failure is attached as a suppressed one, so nothing is lost. The old hand-written finally version got that wrong constantly."

"Generics in Java are checked by the compiler and then erased, which kept old compiled code working when generics arrived. At runtime, a List<String> and a List<Integer> are the same class; the type argument is gone and the compiler inserts casts where values come out. That leads to real limits. I can't write new T() because the JVM doesn't know what T is. I can't ask at runtime whether an object is a List<String>. I can't create a generic array like new T[10] directly. And I can't have two overloads that take List<String> and List<Integer>, because after erasure they have the same signature. The usual workaround is to pass a Class<T> in, so the method can create instances or check types. For flexible APIs I use wildcards: extends when I only read from a collection, super when I only write into it."

"volatile is about visibility. Without it, one thread can keep reading a stale copy of a field and never see another thread's update, which is how a stop flag loop can spin forever. Marking the field volatile means every read sees the most recent write, and the JVM won't reorder other reads and writes around it in harmful ways. But it doesn't lock anything. synchronized gives mutual exclusion, so only one thread runs the block at a time for a given lock, and it also gives visibility: whatever one thread wrote before releasing the lock, the next thread sees after taking it. count++ is three steps: read, add one, write back. Two threads can both read five and both write six, even with volatile. So for a counter I use AtomicInteger, which does it atomically with compare-and-swap, or a lock."

"A deadlock is when threads wait on each other in a cycle and none can move. The textbook case is a money transfer. Thread one transfers from A to B, so it locks A then B. Thread two transfers from B to A, so it locks B then A. If each grabs its first lock at the same moment, both wait forever for the second. The most reliable fix is a consistent lock order: always lock the account with the smaller ID first, whatever the direction of the transfer. Other tools are keeping locked sections short, never calling unknown code while holding a lock, and using ReentrantLock.tryLock with a timeout so a thread can back off. To detect one in a running service, I take a thread dump with jstack or jcmd. It reports Java-level deadlocks directly and shows which thread holds which lock."

"Creating a thread per task is costly, and under load it can create thousands of threads and bring the service down. An ExecutorService keeps a pool of reusable threads and a queue of waiting tasks, so I control how much runs at once. For CPU-heavy work I size the pool close to the number of cores. For tasks that mostly wait on I/O I can go larger. I'm careful with the Executors shortcuts: newFixedThreadPool uses an unbounded queue, so if tasks arrive faster than they finish, the queue grows until memory runs out. In production I'd rather build a ThreadPoolExecutor with a bounded queue, named threads and a clear rejection policy. Two more habits: if I use submit, an exception is stored in the Future and is lost if nobody calls get, and I always shut the pool down on exit."

"With double-checked locking I check whether the instance is null, and only if it is do I lock and check again before creating it, so the lock is taken only on the first calls. The field must be volatile. Creating an object is really several steps: allocate memory, run the constructor, publish the reference. Without volatile, those steps can be reordered from another thread's point of view, so that thread might see a non-null reference to an object whose fields aren't set yet, skip the lock and use a half-built object. volatile forbids that. Honestly, I'd rather not write it at all. The holder idiom is lazy and thread-safe because the JVM initialises a class only once, when it's first used. And if I need protection against serialization and reflection creating copies, an enum with one value is the simplest singleton."

"I wouldn't approve it as is, even though the tests are green. HashMap isn't thread-safe. If two request threads write at once, updates can be lost, and a write during a resize can leave the map in a broken state that's very hard to debug later. The tests pass because they run on one thread, so they can't show the problem. I'd leave a clear comment explaining the risk, and suggest ConcurrentHashMap. I'd also look at how it's used: if the code does a get and then a put, I'd suggest computeIfAbsent or merge so the whole update is atomic. And I'd ask whether the state needs to be shared at all; maybe it belongs in a proper cache or per request. I'd offer to pair on it, because the goal is a correct service and a colleague who spots it next time."

"A functional interface is an interface with exactly one abstract method. Default and static methods don't count, so Comparator is one even though it has lots of default methods. Runnable and Callable are older examples, and java.util.function adds the everyday ones: Function takes a value and returns one, Predicate returns a boolean, Supplier takes nothing and returns something, and Consumer takes something and returns nothing. A lambda is just a compact way to implement that single method. On its own a lambda has no type; the interface it's assigned to decides what it means. A method reference like String::length is a shorter lambda when all I do is call an existing method. On my own interfaces I add @FunctionalInterface, so the compiler complains if someone adds a second abstract method. And a lambda can only use local variables that are effectively final."

"I'd stream the list and collect with groupingBy, using the word length as the key and Collectors.counting as the downstream collector. That gives a map from length to how many words have it. If I want the lengths sorted, I pass a TreeMap supplier. On laziness: operations like filter, map and sorted are intermediate. They just build a pipeline and return a new stream; nothing actually runs. The work happens only when a terminal operation like collect, count or forEach is called, and then each element flows through the whole pipeline. That's why a findFirst after a filter can stop early without touching the rest of the list. Two rules I keep: a stream can be consumed only once, and the lambdas inside shouldn't modify outside variables or collections. If I need a result, I let a collector build it."

"Optional is meant for return types where 'no result' is normal, like findUserByEmail. Returning Optional makes that visible in the signature, so the caller has to decide what happens when it's empty instead of getting a NullPointerException later. I use it with map and filter to chain steps, and finish with orElse, orElseGet or orElseThrow. There's a subtle difference there: orElse always evaluates its argument, even when a value is present, so if the default is expensive, like a database call, I use orElseGet with a lambda. What I avoid: calling get without checking, because it throws when empty, and using Optional for fields or parameters, where it adds overhead and noise. For collections I return an empty list, never an Optional of a list. And an Optional variable itself should never be null."

"A record is a class whose job is to carry data. I write record Point(int x, int y) and Java generates private final fields, a constructor that takes both values, accessor methods named x() and y(), and equals, hashCode and toString based on the fields. So a data class that used to take forty lines of boilerplate is one line, and equals and hashCode can't drift out of sync. Records became a standard feature in Java 16. They're implicitly final, can't extend another class, but can implement interfaces and have extra methods. If I need validation, I add a compact constructor. One thing to watch: they're only shallowly immutable. If a component is a List, the caller can still change that list unless I copy it in the constructor. I use them for DTOs, keys in maps and results returned from methods."

"I'd say it isn't a free speed-up, and suggest we measure instead of switching everything. Parallel streams split the work across the common ForkJoinPool, which the whole application shares. In a web service that already handles many requests at once, the CPU is often busy anyway, so splitting each request's work mostly adds overhead. For small collections, the cost of splitting and merging is bigger than the work itself. If a stream does blocking calls, like HTTP or database calls, it can tie up the shared pool and slow down unrelated code. And any lambda that touches shared state becomes a race. Where it does help is large, CPU-heavy work on data that splits easily, like an ArrayList. So I'd pick the one or two pipelines we think are slow, benchmark sequential against parallel, and switch only where the numbers show a clear win."

"At my last company a reporting service sometimes produced wrong dates, and now and then threw a NumberFormatException, but never in testing. It only showed up under load, which already pointed at threads. I went through the classes on that path and found a static SimpleDateFormat shared by every request. SimpleDateFormat keeps parsing state inside the object, so two threads parsing at once corrupt each other. To prove it, I wrote a small test that parsed dates from many threads at the same time, and it failed within seconds. The fix was to switch to DateTimeFormatter from java.time, which is immutable and safe to share. The test then passed every run. Afterwards I added a check to our code review list for mutable objects in static fields, and we found two more similar cases."

"At my last company, a nightly job that matched incoming records against an existing list was taking far too long. Instead of guessing, I ran it with a profiler, and almost all the time was inside a loop that called list.contains for every record. On a list with hundreds of thousands of items that's a linear scan each time, so the whole job was quadratic. I built a HashSet of the keys once before the loop, so each lookup became constant time on average. The same profile showed String.matches inside the loop, which compiles the regex again on every call, so I compiled one Pattern into a constant and reused it. The job went from most of an hour to a couple of minutes. I compared the output files from the old and new versions to make sure the results were identical."

"At my last company I led moving a group of services from Java 8 to Java 17, mainly because Java 8 support was ending for us and we wanted records and better garbage collectors. The first breakages were at compile time: we used JAXB for XML, and those modules were deprecated in Java 9 and removed from the JDK in Java 11, so we had to add them back as normal dependencies. Then a couple of old libraries broke at runtime because they reached into JDK internals with reflection, which newer versions block by default. We upgraded those libraries first, one pull request at a time, while still on Java 8. After that the switch itself was small. We rolled it out to one service at a time, compared GC pauses and latency with the old version, and kept the old build ready to roll back. None of them needed it."