Quick Revision

• Automatic Garbage Collection: Java uses garbage collection to automatically manage memory by removing unreferenced objects.
• Heap Memory: Divided into Young Generation, Old Generation, and sometimes Metaspace (Java 8+); used for object storage.
• Stack Memory: Stores method call details, local variables, and references; is thread-specific.
• Method Area: Stores class metadata, including runtime constant pool and static variables; shared by all threads.
• Program Counter (PC): Tracks the next instruction to be executed in each thread.
• Native Method Stack: Manages native method execution via JNI (Java Native Interface).
• Memory Leaks in Java: Can occur when references to unused objects are unintentionally maintained.
• Garbage Collection Algorithms: JVM uses algorithms like Mark-and-Sweep, Copying, and Generational GC for memory cleanup.
• Finalization: The finalize() method is used but discouraged in favor of modern garbage collection practices.
• Escape Analysis: JVM optimization determines if an object can be allocated on the stack instead of the heap for faster access.
• Soft/Weak References: Special references (Soft, Weak, and Phantom) help in advanced memory management scenarios.
• OutOfMemoryError: Indicates insufficient heap, stack, or Metaspace memory, requiring tuning via JVM options.
• Java Memory Model (JMM): Defines rules for visibility and ordering of variables in a multi-threaded environment.
• Memory Monitoring Tools: Tools like VisualVM, JConsole, and profilers help analyze and manage JVM memory usage.
• Thread-Specific Allocation: Each thread gets its own stack but shares heap memory with other threads.
• Volatile Keyword: Ensures visibility of changes to variables across threads but does not guarantee atomicity.
• Metaspace (Java 8+): Replaces PermGen and dynamically resizes to store class metadata.
• JVM Tuning: Optimize memory with JVM options like -Xms, -Xmx, and -XX flags for garbage collection.

What Kinds of Memory Does the JVM Manage?

The Java Virtual Machine (JVM) manages several types of memory, categorized into distinct areas:

JVM Memory Components: Detailed Explanation
• Stack: - Holds references to heap objects and value types (primitives). - Each thread has its own stack memory, isolated from other threads. - Allocated per thread, with no cross-access between thread stacks.
• Heap: - Stores the actual objects in memory. - Shared across all threads in a single JVM instance. - Managed via garbage collection to reclaim unused memory.
• Program Counter (PC) Register: - Holds the address of the current instruction being executed. - If the current method is native, the PC remains undefined. - Used by JVM to track execution flow, pointing to the Method Area.
• Method Area and Runtime Constant Pool: - Shared across all threads, contains per-class elements like constants, fields, method data, and constructors. - Historically stored in PermGen space until Java 7, which was replaced by Metaspace in Java 8. - Metaspace uses native memory and dynamically scales up to the available system memory.
• Native Stack: - Stores frames for methods written in native languages like C or C++. - When a thread calls a native method, it switches from the Java stack to the native stack. - If the native method invokes a Java method, the thread returns to the Java stack. - Not all JVMs support native methods, but those that do maintain a native stack per thread.

These memory areas ensure the smooth execution of Java programs by handling object storage, method calls, and native operations.

Different Parts of the Heap in Java

The heap in Java is divided into multiple regions to optimize garbage collection and memory management. Here's a detailed explanation of the parts:

• Eden Space:
  • This is where new objects are initially allocated memory.
  • Most objects are short-lived and are quickly garbage collected in this area.
  • Garbage collection in Eden is performed by the minor GC.
  • When the Eden space is full, surviving objects are moved to the Survivor Spaces.
• First Survivor Space:
  • This is a small area where objects that survive a garbage collection in the Eden space are moved.
  • Its purpose is to hold objects temporarily before they are promoted to the Old Generation.
  • If an object survives multiple garbage collections, it will eventually be moved to the Old Generation.
• Second Survivor Space:
  • This is another small area similar to the First Survivor Space.
  • During garbage collection, objects are swapped between the two Survivor Spaces.
  • The swapping alternates between the First and Second Survivor Spaces to manage memory efficiently.
• Old Generation:
  • Also known as the "Tenured Generation," it holds objects that have a longer lifespan.
  • Objects are moved here after surviving multiple garbage collection cycles in the young generation.
  • Garbage collection in this space is done by the major GC, which is more expensive and less frequent than minor GC.
  • Since this space contains objects with a long lifespan, garbage collection here is less frequent but takes more time.

• Young Generation: Includes Eden Space, First Survivor Space, and Second Survivor Space.
• Old Generation: Contains long-lived objects.

Heap Size Limits: The theoretical maximum heap limit for a 32-bit JVM is 4GB, but practical limits are lower due to constraints like swap memory, kernel address space, memory fragmentation, and VM overhead.

What is PermGen Space?

PermGen (Permanent Generation) is a memory pool in the HotSpot JVM used to store metadata about the virtual machine itself and user-defined classes. It holds reflective data, such as class and method objects, and is unique to the HotSpot JVM.

• Contains metadata for user-defined classes (not part of the Java language).
• Stores static content, including:
  • Static methods
  • Primitive static variables
  • References to static objects
• Holds additional information such as bytecode, class names, and Just-In-Time (JIT) compiler data.
• Prior to Java 7, the String Pool was also stored in PermGen.
• With Java 8, PermGen was replaced by Metaspace, which is more flexible and addresses many of the issues with PermGen.

• PermGen is separate from the main heap but contiguous to it in memory layout.
• It is not considered part of the Java Heap space.

• PermGen is prone to OutOfMemoryError if its size limit is exceeded.
• The garbage collection of PermGen is tied to the old generation, leading to inefficiencies if either space fills up.
• Limited by the -XX:MaxPermSize flag. If the metadata exceeds this value, the application encounters an Out of Memory (OOM) error.

• -XX:PermSize: Sets the initial or minimum size of the PermGen space.
• -XX:MaxPermSize: Sets the maximum size of the PermGen space.

Starting with Java 8, PermGen was replaced by Metaspace, which uses native memory instead of heap memory. This change resolved many of the limitations of PermGen, such as fixed-size constraints.

What is Metaspace?

With the introduction of JDK 8, the concept of PermGen space has been replaced by Metaspace. The metadata information previously stored in PermGen is now relocated to native memory, under the Metaspace. This transition aligns with practices used by other JVM implementations like Oracle JRockit and IBM JVM.

• No longer requires contiguous memory within the Java heap. Instead, metadata resides in native memory.
• Mitigates the challenges associated with tuning PermGen, such as its dependency on factors like the number of classes, size of constant pools, and method sizes.
• Improves garbage collection efficiency by eliminating the need for specialized code for metadata in each garbage collector.
• Enables more flexible management of metadata, allowing for seamless handling during garbage collection and simplifying future memory deallocation processes.

Difference Between PermGen and Metaspace

The primary difference between PermGen and Metaspace lies in their memory management. While PermGen is contiguous within the Java heap, Metaspace is external to the Java heap and resides in native memory. This separation from the heap means that Metaspace's size is not fixed and instead, it dynamically adjusts its allocation based on the available resources of the host operating system.

• Memory Location: PermGen is part of the Java heap, whereas Metaspace is part of native memory outside the heap.
• Size Management: PermGen has a fixed maximum size, whereas Metaspace automatically expands its size up to the available memory on the host system.

What is Java HotSpot?

Java HotSpot is a high-performance implementation of the Java Virtual Machine (JVM) developed by Oracle Corporation. It enables Java applications to run efficiently across various hardware and operating systems.

• Just-In-Time (JIT) Compilation: HotSpot uses JIT compilation to dynamically convert frequently executed bytecode into native machine code, significantly improving performance.
• Garbage Collection: HotSpot includes advanced garbage collection mechanisms to manage memory efficiently and reduce pauses caused by memory management.
• Code Optimization: It identifies "hot spots" in the code, applying optimizations such as inlining and loop unrolling to enhance execution speed.
• Platform Independence: It supports running Java applications on multiple operating systems and architectures without modification.
• Thread Management: HotSpot provides robust multithreading support for concurrent applications, ensuring efficient CPU utilization.

C:\Users\user>java --version
java 17.0.12 2024-07-16 LTS
Java(TM) SE Runtime Environment Oracle GraalVM 17.0.12+8.1 (build 17.0.12+8-LTS-jvmci-23.0-b41)
Java HotSpot(TM) 64-Bit Server VM Oracle GraalVM 17.0.12+8.1 (build 17.0.12+8-LTS-jvmci-23.0-b41, mixed mode, sharing)
      

What is the Java Interpreter?

The Java Interpreter is a component of the Java runtime environment that directly executes Java bytecode instructions. Bytecode is the intermediate representation of Java programs, generated by the Java compiler, and is platform-independent.

• Direct Execution: It reads and executes Java bytecode line by line, translating it into actions on the host machine.
• Platform Independence: Bytecode executed by the interpreter can run on any platform with a compatible Java Virtual Machine (JVM).
• Simplicity: It eliminates the need to compile Java code to native machine code, allowing for rapid testing and debugging.
• Slower Performance: Compared to Just-In-Time (JIT) compilation, interpretation is slower because it translates bytecode line by line rather than optimizing frequently executed code.
• Legacy Use: Modern JVMs like Java HotSpot often combine interpretation with JIT compilation for better performance.

Working of the JIT Compiler

A Just-In-Time (JIT) compiler operates after a program has started execution, dynamically converting bytecode or virtual machine instructions into the host CPU's native machine code. This process occurs "just-in-time" to optimize program performance.

• Dynamic Compilation: JIT compiles code during runtime, taking advantage of runtime information to perform optimizations that a traditional static compiler cannot, such as inlining frequently used functions.
• Platform Neutrality: Java programs are initially compiled into platform-independent bytecode. The JIT compiler translates this bytecode into platform-specific machine code for faster execution.
• Performance Optimization: After a method is compiled, the JVM directly invokes the compiled code rather than interpreting bytecode, significantly improving performance for heavily used methods.
• Startup vs. Peak Performance: Compiling all methods at startup can cause delays. Instead, the JVM uses an invocation count threshold to determine which methods to compile, focusing on frequently called ("hot") methods for optimization.
• Sampling for Hot Spots: A sampler thread periodically monitors application threads to identify heavily executed methods. These "hot" methods are prioritized for JIT optimization.
• Fallback to Interpretation: Less frequently used methods are not compiled immediately or may remain interpreted to conserve resources like processor time and memory.
• Optional Disabling: JIT compilation can be disabled, in which case the JVM interprets the entire program, although at a cost to performance.

The JIT compiler improves Java program performance to approach that of native applications, but its dynamic nature requires a balance between compilation time, memory usage, and runtime performance. Optimization opportunities are greatest during the program's early stages, with diminishing returns as execution stabilizes.

What is the Code Cache in Java HotSpot?

In order to run JVM bytecode on different platforms, it needs to be converted to machine instructions. The JIT compiler is responsible for this compilation as the program is executed. When the JVM compiles bytecode to assembly instructions, it stores those instructions in a special non-heap data area called Code Cache.

Reference Types in Java

In Java, references are used to access objects stored in memory. The Java programming language provides four types of references to manage memory and the lifecycle of objects, especially in relation to garbage collection.

• Strong Reference:

  The most commonly used type of reference. Any object that has a strong reference will not be eligible for garbage collection unless the reference is explicitly set to null.

  String str = "Hello, World!";

• Weak Reference:

  Objects with weak references are eligible for garbage collection when no strong references exist. Weak references are used for objects like caches and mappings.

  WeakReference<String> weakRef = new WeakReference<>(new String("WeakReference"));

• Soft Reference:

  Soft references allow objects to stay in memory as long as sufficient memory is available. They are useful for implementing memory-sensitive caches.

  SoftReference<String> softRef = new SoftReference<>(new String("SoftReference"));

• Phantom Reference:

  Phantom references are used to schedule cleanup actions before an object is reclaimed by the garbage collector. They are created using the PhantomReference class.

  PhantomReference<String> phantomRef = new PhantomReference<>(new String("Phantom"), refQueue);

What is the Use of ReferenceQueue?

A ReferenceQueue in Java is a utility class used in conjunction with reference types like WeakReference, SoftReference, and PhantomReference. It provides a mechanism to track when a referent object is about to be or has been reclaimed by the garbage collector.

• Cleanup Actions: Enables applications to perform cleanup operations or resource management when an object is no longer reachable and ready for garbage collection.
• Monitoring Object Lifecycles: Helps track the lifecycle of objects and identify when they are no longer in use, which is especially useful in caches or resource pools.
• Post-GC Notifications: Provides a way to get notified when the garbage collector processes a reference, allowing specific actions to be triggered.

When creating a WeakReference, SoftReference, or PhantomReference, you can associate it with a ReferenceQueue. When the garbage collector determines that the referent object is eligible for collection, the reference object is enqueued in the associated ReferenceQueue.

The ReferenceQueue is a powerful tool for managing object lifecycles and implementing custom memory management strategies. It is particularly useful for advanced use cases like caching, resource cleanup, or integrating garbage collection events with application logic.

What is a Garbage Collector?

In Java, the Garbage Collector (GC) is a component of the Java Virtual Machine (JVM) responsible for automatic memory management. Its primary role is to reclaim memory occupied by objects that are no longer reachable or needed by the application, ensuring efficient use of system resources and preventing memory leaks.

• Automatic Memory Management: The GC eliminates the need for developers to manually allocate and deallocate memory, reducing the risk of programming errors.
• Detection of Unused Objects: The GC identifies objects that are no longer reachable from the application code and frees their associated memory.
• Heap Management: It manages the Java heap, the memory area where all objects are stored, by organizing memory into regions like Eden, Survivor, and Old generations.

The GC employs algorithms to identify and remove unreachable objects:

• Mark-and-Sweep: The GC marks objects that are still reachable from root references and sweeps away the rest.
• Generational Collection: The heap is divided into generations:
  • Young Generation: Newly created objects. Frequent GC occurs here.
  • Old Generation: Long-lived objects promoted from the Young Generation.
  • Permanent Generation (before Java 8): Metadata and class information.
• Compaction: After garbage collection, memory may be compacted to reduce fragmentation and improve allocation efficiency.

Java provides several types of garbage collectors, which can be selected using JVM options:

• Serial GC: Single-threaded collector, suitable for single-threaded applications.
• Parallel GC: Multi-threaded collector, designed for high throughput.
• CMS (Concurrent Mark-Sweep) GC: Minimizes pause times for applications requiring low latency.
• G1 GC: Balances throughput and low latency, divides the heap into regions.
• ZGC: Ultra-low latency collector for large heaps.

• Reduces the burden of manual memory management.
• Prevents common memory issues like leaks and dangling pointers.
• Improves developer productivity and application reliability.

How Garbage Collection Process in Java

Garbage collection in Java is a mechanism to automatically manage memory by reclaiming memory occupied by objects that are no longer reachable. The garbage collection process is integral to the JVM's memory management, involving multiple memory areas and distinct phases.

The JVM divides the heap memory into the following regions:

• Eden Memory: Where new objects are initially allocated.
• Survivor Spaces: Two spaces (A and B) used to hold objects that survive garbage collection.
• Old/Tenured Generation: Memory area for long-lived objects promoted from the young generation.

The young generation consists of the Eden memory and the two survivor spaces. Here's how the garbage collection process works:

• Object Creation: New objects are allocated in Eden memory. This space fills up quickly due to its limited size.
• First GC Run:
  • The garbage collector marks live objects in Eden memory.
  • Unreachable objects are collected as garbage.
  • Surviving objects are moved to one of the survivor spaces (e.g., survivor space A).
• Second GC Run:
  • Surviving objects from Eden memory and survivor space A are moved to the unused survivor space (e.g., survivor space B).
  • Unused memory in Eden and survivor space A is reclaimed.
• Object Promotion: After surviving a certain number of garbage collection cycles, objects are promoted to the old generation.

The two survivor spaces are designed to prevent memory fragmentation. After each garbage collection cycle:

• Live objects are copied from Eden and the in-use survivor space to the unused survivor space.
• This movement consolidates memory, avoiding fragmentation and eliminating the need for compaction in the young generation.

Once objects are promoted to the old generation, garbage collection occurs less frequently but involves more intensive processing:

• Full GC: When the old generation becomes full, garbage collection is triggered to reclaim memory.
• Memory Compaction: Unlike the young generation, compaction is necessary to reduce fragmentation in the old generation.

The garbage collection process efficiently manages memory by reclaiming unused objects, promoting long-lived objects, and optimizing memory layout. It ensures the smooth functioning of Java applications while reducing the need for manual memory management.

Can We Force the Garbage Collector to Run?

In Java, it is not possible to force the garbage collector to run. The methods System.gc() and Runtime.getRuntime().gc() can be used to suggest that garbage collection should be performed, but these are merely hints to the JVM. The decision to perform garbage collection is entirely up to the JVM and its internal algorithms.

• System.gc() and Runtime.getRuntime().gc(): These methods signal the JVM to prioritize garbage collection, but they do not guarantee that the garbage collector will be invoked immediately.
• JVM's Discretion: The JVM uses its own heuristics and optimizations to determine the best time to perform garbage collection, aiming to minimize performance overhead.
• Reason for No Direct Control: Java’s memory management is designed to abstract the complexity of manual memory handling. Giving developers direct control over garbage collection could lead to inefficiencies and performance degradation.

  public class GarbageCollectorExample {
      public static void main(String[] args) {
          // Suggesting garbage collection
          System.gc();
          Runtime.getRuntime().gc();
          
          // No guarantee that GC will run immediately
          System.out.println("Garbage collection suggested.");
      }
  }
    

While System.gc() and Runtime.getRuntime().gc() can be used to suggest garbage collection, they do not force it. The JVM's garbage collector operates autonomously to optimize application performance and memory management.

What is MinorGC and MajorGC?

In Java, garbage collection is categorized based on the memory region it operates on. These terms, although commonly used, do not have formal definitions in the JVM specification or garbage collection research papers.

• Definition: A garbage collection event that occurs in the young generation of the heap memory.
• Trigger: Happens when the Eden space in the young generation is full.
• Impact: Typically fast as it deals with a smaller portion of the heap, and most objects in the young generation are short-lived.
• Outcome: Surviving objects are moved to one of the survivor spaces or, after multiple collections, promoted to the old generation.

• Definition: A garbage collection event that occurs in the old generation of the heap memory.
• Trigger: Happens when the old generation becomes full.
• Impact: Slower compared to MinorGC as it processes a larger portion of the heap and involves memory compaction to avoid fragmentation.
• Outcome: Reclaims memory from the old generation. It may cause significant application pauses, depending on the GC algorithm used.

• Definition: A garbage collection event that runs on both the young and old generations.
• Trigger: Can be triggered explicitly or as a fallback when other GC efforts are insufficient.
• Impact: Usually results in the longest pause times since it encompasses the entire heap.

MajorGCs are often triggered by MinorGCs. For instance, when surviving objects from the young generation fill the old generation during promotion, a MajorGC may be required. This interdependence makes it challenging to separate the two processes entirely.

While MinorGC and MajorGC are widely used terms, they are not formally defined in the JVM specification. They provide a convenient way to describe garbage collection activity in different regions of the heap, helping developers understand and optimize memory management in Java applications.

What is a memory leak?

A memory leak in Java is a situation where some objects are no longer used by an application, but the Garbage Collector fails to recognize them as unused. This leads to the OutOfMemoryError if those unused objects contribute to the heap usage significantly enough that the next memory allocation request by the application cannot be fulfilled.

🔍 How to Avoid Memory Leaks in Java

Avoid Unwanted Object References

✔ Set objects to null when they are no longer needed.

✔ Use WeakReference or SoftReference for objects that can be garbage collected.

Use Weak References in Collections

✔ Replace HashMap with WeakHashMap to avoid strong references.

✔ Use ConcurrentLinkedQueue for caching objects efficiently.

Deregister Event Listeners & Callbacks

✔ Remove listeners manually when they are no longer needed.

✔ Use removeActionListener() for UI components.

Close JDBC, I/O, and Network Resources

✔ Always close database connections, file streams, and sockets.

✔ Use try-with-resources to manage resources automatically.

Avoid Memory Leaks in Inner Classes

✔ Use static inner classes to avoid unintended references to the outer class.

✔ If anonymous inner classes are used, ensure they don’t hold long-lived references.

Use Proper Caching Strategies

✔ Implement LRU (Least Recently Used) caches using LinkedHashMap or Guava Cache.

✔ Clear cache entries periodically to avoid excessive memory usage.

Enable JVM Monitoring & Heap Analysis

✔ Use VisualVM, JProfiler, or Eclipse MAT to detect memory leaks.

✔ Analyze heap dumps to identify objects consuming memory unnecessarily.

Tune Garbage Collection (GC)

✔ Use GC logging (-XX:+PrintGCDetails) to monitor memory usage.

✔ Choose the right GC algorithm (G1GC, ZGC) for optimized performance.

How to Generate and Analyze Heap Dump in GraalVM

-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=heapdump.hprof

jcmd  GC.heap_dump heapdump.hprof

jmap -dump:live,format=b,file=heapdump.hprof 

-XX:+HeapDumpAfterFullGC

visualvm

How you handled Memory leak in your project?

In one of our high-traffic microservices, we encountered an OutOfMemoryError (OOM) in production. The service was responsible for handling real-time user sessions, and over time, it started consuming more memory than expected.

jcmd <PID> GC.heap_dump heapdump.hprof

public class UserSessionManager {
private static final Map<String, UserSession> sessionCache = new HashMap<>();

public static void addSession(String sessionId, UserSession session) {
    sessionCache.put(sessionId, session);
}
}
    

private static final Map<String, UserSession> sessionCache = new WeakHashMap<>();
    

ScheduledExecutorService scheduler = Executors.newScheduledThreadPool(1);
scheduler.scheduleAtFixedRate(() -> {
sessionCache.entrySet().removeIf(entry -> entry.getValue().isExpired());
}, 10, 10, TimeUnit.MINUTES);
    

-Xms512m -Xmx2g

-XX:+UseG1GC -XX:InitiatingHeapOccupancyPercent=45