28.9. Common JVM Pitfalls

• Memory Leaks: Even with GC, holding object references can leak memory.

Memory leaks occur when an application holds onto references of objects that are no longer needed, preventing the garbage collector (GC) from freeing that memory. Even though Java has a garbage collection mechanism to automatically reclaim memory, it cannot clear objects that are still referenced. For instance, if a long-lived object keeps a reference to a short-lived object, that short-lived object won't be collected and its memory won't be reclaimed, potentially leading to increased memory usage over time.

Imagine a library where books represent objects. If a librarian (the programmer) keeps checking out an old book (object) but never returns it because there's still a reference to it, that old book cannot be removed from the library (memory). Over time, more and more old, unneeded books accumulate, leading to a crowded library (memory leaks).

• OutOfMemoryError: o Heap space o GC overhead limit o Metaspace

The OutOfMemoryError is thrown when the JVM cannot allocate an object because it's out of memory and no more memory could be reclaimed by the garbage collector. This can happen for several reasons:

• Heap space: If the applications need more memory than is available in the heap area.
• GC overhead limit: If the GC is spending too much time to free up memory but only recovering a small amount, the JVM might throw this error to avoid wasting resources.
• Metaspace: Starting from Java 8, the metadata area for classes (metaspace) is allocated on native memory. If this native area is exhausted, it can also lead to an OutOfMemoryError.

Think of a busy restaurant (the heap) where each table (memory space) must fit a number of diners (objects). If more diners arrive than there are seats (memory), no more diners can enter. If diners start taking too long to pay the bill and their chairs aren't being freed up fast enough for new diners (GC overhead limit), the restaurant may eventually reach a point where it can't serve anyone anymore, leading to a chaotic situation—this directly correlates to an OutOfMemoryError in a Java application.

• StackOverflowError: Due to recursive calls.

A StackOverflowError occurs when the call stack memory limit is exceeded, usually due to uncontrolled recursion. Each method call adds a frame to the stack, and if a method keeps calling itself (recursion) without a proper base case to stop, it will continue adding frames until the stack runs out of space.

Imagine a set of nesting dolls, where each doll (method call) goes inside another. If you kept adding smaller dolls without ever stopping (like excessive recursive calls), eventually, you would run out of space to keep nesting them. This is similar to hitting a StackOverflowError when the stack (call area) is full.

• ClassLoader Leaks: Especially in container environments (Tomcat, etc.).

ClassLoader leaks occur when classes loaded by a ClassLoader are not able to be re-collected, often in long-running applications or those that use hot-deployment (like web applications in Tomcat). If old ClassLoader instances hold onto references of classes that were re-deployed or updated, it prevents those classes from being garbage-collected and can lead to increased memory usage over time.

Consider a theater (the application) that keeps putting on new plays (deploying new classes) without removing the old set (old ClassLoaders). As long as parts of the old set remain visible or accessible, they can't be taken down or thrown away. Over time, the theater might get cluttered with old props (classes), leading to memory issues—this illustrates the concept of ClassLoader leaks.

--