Java and the JVM

The collections framework is small enough to hold in your head and the choices matter more than the syntax. ArrayList is a growable array: constant-time access by index, linear removal from the middle. LinkedList is almost never the right answer despite what its name suggests, because pointer chasing loses to cache locality on modern hardware. HashMap is the workhorse. TreeMap keeps keys sorted, which is what you want when the question includes everything between two values.

The contract that catches people is between equals and hashCode. Two objects that are equal must return the same hash code, or a HashMap will look in the wrong bucket and fail to find something it is holding. Override one and you must override the other, which is why records exist: a record generates both from its components and removes the whole category.

Mutable keys break the same machinery from the other direction. Put an object in a HashSet, change a field that participates in its hash, and the object is now in the wrong bucket: still present, unreachable by lookup, and it will not be found by contains even though iteration will show it. Keys should be immutable, which in practice means records or classes with final fields.

HashMap's implementation is worth one sentence of knowledge: buckets hold a linked list and convert to a balanced tree once enough entries collide, which turns a degenerate O(n) bucket into O(log n) and defuses the collision attack that this change was introduced to address.

Two habits save real time. Prefer the interface as the declared type, so List rather than ArrayList, because it keeps the implementation a choice rather than a commitment. And be deliberate about mutability: List.of returns an immutable list, Collections.unmodifiableList wraps a mutable one in a view that still changes underneath you, and confusing the two produces a defensive copy that defends nothing.

Garbage collection removes a category of bug rather than a category of work. Nothing is freed by hand, so use-after-free and double-free do not exist, and in exchange the runtime decides when to reclaim memory, which means it sometimes decides during a request you cared about.

The observation the collectors are built on is that most objects die young. Allocation happens in a small young region, collection there is cheap because it copies the few survivors rather than visiting the many dead, and anything that survives repeatedly is promoted to an older region collected far less often. That generational split is why allocating short-lived objects in Java is much cheaper than intuition suggests.

The collector you get by default is G1, which divides the heap into regions and collects those with the most garbage first, aiming at a pause time goal you can set rather than a fixed schedule. For workloads that cannot tolerate pauses at all, ZGC and Shenandoah do most of their work concurrently with the application and hold pauses to a small number of milliseconds regardless of heap size, at the cost of some throughput.

What actually causes trouble is rarely the collector's algorithm. It is a memory leak wearing a different name: a cache with no eviction, a listener never unregistered, a thread-local on a pooled thread, a static map that only grows. The heap fills, the collector runs more and more often to reclaim less and less, and the service spends its time collecting rather than working before it finally fails.

So the useful skill is reading the evidence rather than tuning flags. Allocation rate, pause time distribution, and the size of the old generation after each full collection: if that last number is rising over hours, you have a leak and no collector setting will help. A heap dump names the objects and what is holding them, which is the answer rather than the symptom.

Java threads are operating system threads, so each carries a stack measured in hundreds of kilobytes or more and a context switch costs the kernel real time. That is why a thread per request stopped scaling, why thread pools exist, and why a generation of frameworks went asynchronous and reactive to avoid blocking a thread on IO.

An executor separates the work from the thread running it, which is the right abstraction and comes with a decision people leave at its default: the queue. An unbounded queue turns overload into an out-of-memory failure rather than a rejection, which is the backpressure argument in its most concrete form. A bounded queue with a sensible rejection policy converts the same overload into an error the caller can act on.

Virtual threads, standard since Java 21, change the arithmetic underneath all of this. They are scheduled by the JVM onto a small pool of platform threads and unmount when they block, so a blocking call no longer occupies an operating system thread and a million concurrent tasks becomes reasonable. The point is that ordinary blocking code becomes the scalable style again, which removes most of the reason to write reactive pipelines that were hard to read and harder to debug.

There is a caveat worth carrying. Before Java 24 a virtual thread blocking inside a synchronized block pinned its carrier, so a small number of pinned threads could stall everything; JEP 491 removed that specific pin. Native calls and a few other cases can still pin, and the JVM emits an event when it happens, so the modern advice is to measure rather than to avoid synchronized on principle.

The memory model is the part no thread abstraction removes. Without synchronisation there is no guarantee that one thread sees another's write, at all, ever: the compiler and the processor may reorder, and a field read in a loop may be hoisted out of it. volatile, synchronized and the concurrent utilities all establish the happens-before relationships that make visibility defined, and none of them is optional because a test happened to pass.

Java generics are checked at compile time and erased afterwards. A List of String and a List of Integer are the same class at run time, and the compiler inserts the casts that make it safe. That decision was made for compatibility, so that generic code could interoperate with the collections written before generics existed, and everything odd about them follows from it.

The visible consequences are a short list worth memorising. You cannot ask whether something is a List of String at run time, because the answer no longer exists. You cannot create an array of a generic type. You cannot overload two methods that differ only in their type parameter, because after erasure they have the same signature. And a cast to a generic type is unchecked, which is the compiler telling you it has stopped being able to help.

Wildcards are where the syntax earns its reputation and the rule behind them is simple: a producer you read from is declared with extends, a consumer you write to with super. A List of some subtype of Number can be read as Number and cannot be written to, because the compiler does not know which subtype it holds. Once that clicks, the signatures in the standard library stop looking arbitrary.

The pattern for recovering the erased type is to pass it explicitly, as a Class object or through the trick of subclassing a generic type so the parameter is recorded in the class file. Serialisation libraries do this constantly, which is why deserialising into a generic collection needs a type token rather than a class literal.

It is worth contrasting this with the alternative, because it explains a real performance gap. C# reifies generics, so a list of integers holds integers rather than boxed objects, while Java boxes every primitive stored in a collection: a list of a million ints is a million objects with headers, pointers and cache misses. Project Valhalla is the long-running effort to close that gap, and until it lands, primitive-heavy code uses arrays or a specialised library rather than the collections framework.