Unlocking JVM Secrets: Memory Leaks, GC, Class Loading and Performance Tuning

Table of Contents

1. Does Java have memory leaks? Brief description.

2. In a 64‑bit JVM, what is the length of an int?

3. Differences between Serial and Parallel GC?

4. In 32‑bit and 64‑bit JVMs, what is the length of an int?

5. Difference between WeakReference and SoftReference in Java?

6. What does the JVM option -XX:+UseCompressedOops do and why use it?

7. How to determine via Java code whether the JVM is 32‑bit or 64‑bit?

8. Maximum heap memory for 32‑bit and 64‑bit JVMs?

9. Differences among JRE, JDK, JVM and JIT?

10. Explain Java heap space and GC.

11. JVM memory areas.

12. Program Counter (thread‑private).

13. Virtual Machine Stack (thread‑private).

14. Native Method Stack (thread‑private).

15. Can you guarantee GC execution?

16. How to obtain memory usage of a Java program and heap usage percentage?

17. Difference between heap and stack in Java.

18. Describe the principle of JVM class file loading.

19. What is GC and why is it needed?

20. Heap (shared among threads) – runtime data area.

21. Method Area / Permanent Generation (shared among threads).

22. JVM runtime memory.

23. Young Generation.

24. Old Generation.

25. Permanent Generation.

26. Java 8 and Metaspace.

27. Reference counting.

28. Reachability analysis.

29. Mark‑Sweep algorithm.

30. Copying algorithm.

31. Mark‑Compact algorithm.

32. Generational collection algorithm.

33. Young generation and copying algorithm.

34. Old generation and mark‑compact algorithm.

35. Strong references in Java.

36. Soft references in Java.

37. Weak references in Java.

38. Phantom references in Java.

39. Generational collection algorithm.

40. Copying algorithm in young generation.

41. Mark‑compact algorithm in old generation.

42. Region‑based collection algorithm.

43. GC collectors.

44. Serial collector (single‑thread, copying).

45. ParNew collector (Serial + multithreaded).

46. Parallel Scavenge collector (multithreaded copying, high throughput).

57. Serial Old collector (single‑thread, mark‑compact).

58. Parallel Old collector (multithreaded mark‑compact).

59. CMS collector (multithreaded mark‑sweep, low pause).

60. G1 collector (mark‑compact, pause‑time control).

61. JVM class loading mechanism.

62. Class loaders.

63. Parent‑delegation model.

64. OSGi (dynamic module system).

65. Dynamic reconfiguration.

66. Modular programming and hot‑plug.

67. JVM memory model.

68. Stack.

69. Native method stack.

70. Program counter.

71. Heap.

72. Method area.

73. Generational reclamation.

74. Differences between heap and stack.

75. When does Full GC occur?

76. What is the Java Virtual Machine and why is Java called a "platform‑independent" language?

77. Object allocation rules.

78. Describe the JVM class‑file loading mechanism.

79. Java object creation process.

80. Brief description of Java object layout.

81. How to determine if an object can be reclaimed.

82. Does GC happen in the permanent generation?

83. Garbage‑collection algorithms.

84. Tuning commands.

85. Tuning tools.

86. When do Minor GC and Full GC happen?

87. Common JVM performance tuning techniques.

1. Does Java have memory leaks? Brief description.

Yes. When you implement data structures that allocate memory on the heap yourself, memory leaks can occur; see Effective Java for details.

2. In a 64‑bit JVM, what is the length of an int?

In Java, the length of an int is a fixed 32‑bit value, independent of the platform; both 32‑bit and 64‑bit JVMs use the same 4‑byte size.

3. Differences between Serial and Parallel GC?

Both Serial and Parallel cause stop‑the‑world pauses. The Serial collector is the default copying collector and uses a single thread for GC, whereas the Parallel collector employs multiple GC threads.

4. In 32‑bit and 64‑bit JVMs, what is the length of an int?

The length of an int is identical in both 32‑bit and 64‑bit JVMs: 32 bits (4 bytes).

5. Difference between WeakReference and SoftReference in Java?

Both improve GC and memory efficiency. A WeakReference is reclaimed as soon as the last strong reference disappears, while a SoftReference may survive until the JVM experiences memory pressure.

6. What does the JVM option -XX:+UseCompressedOops do and why use it?

When migrating an application from a 32‑bit JVM to a 64‑bit JVM, object pointers grow from 32 bits to 64 bits, roughly doubling heap size and potentially hurting CPU‑cache performance. The -XX:+UseCompressedOops option makes the JVM use 32‑bit object pointers (compressed OOPs) instead of full 64‑bit pointers, reducing memory consumption.

7. How to determine via Java code whether the JVM is 32‑bit or 64‑bit?

You can inspect system properties such as sun.arch.data.model or os.arch to obtain this information.

8. Maximum heap memory for 32‑bit and 64‑bit JVMs?

In theory, a 32‑bit JVM can address up to 2^32 bytes (4 GB), but practical limits are lower (e.g., ~1.5 GB on Windows, ~3 GB on Solaris). A 64‑bit JVM can theoretically address 2^64 bytes; in practice you can specify heap sizes up to 100 GB or even 1 TB on some JVMs (e.g., Azul).

9. Differences among JRE, JDK, JVM and JIT?

JRE (Java Runtime Environment) provides the runtime needed to execute Java programs. JDK (Java Development Kit) includes development tools such as the compiler and also contains a JRE. JVM (Java Virtual Machine) is the component that runs Java bytecode. JIT (Just‑In‑Time compilation) translates frequently executed bytecode into native code to improve performance.

10. Explain Java heap space and GC.

When a Java process starts, the JVM allocates a heap area for object allocation. Garbage Collection (GC) is an internal JVM process that reclaims memory occupied by unreachable objects for future allocations.

11. JVM memory areas

JVM memory is divided into thread‑private regions (Program Counter, Java Stack, Native Method Stack) and thread‑shared regions (Java Heap, Method Area) plus Direct Memory. Thread‑private regions live as long as the thread does; thread‑shared regions are created and destroyed with the JVM lifecycle. Direct memory is not part of the runtime data area but is used frequently via NIO buffers.

12. Program Counter (thread‑private)

A small memory area that holds the bytecode instruction address for the current thread. Each thread has its own Program Counter. For native methods, the PC is empty. This area never throws OutOfMemoryError.

13. Virtual Machine Stack (thread‑private)

Represents the memory model for Java method execution. Each method call creates a stack frame that stores local variables, operand stack, dynamic linking information, and return address. Stack frames are created on method entry and popped on method exit, regardless of normal or exceptional termination.

14. Native Method Stack (thread‑private)

The native method stack serves native (non‑Java) methods similarly to how the Java stack serves Java methods. In HotSpot, the native method stack is merged with the Java stack.

15. Can you guarantee GC execution?

No. You can invoke System.gc() or Runtime.gc(), but the JVM does not guarantee that a GC cycle will actually run.

16. How to obtain memory usage of a Java program and heap usage percentage?

Use methods in java.lang.Runtime: freeMemory() returns free bytes, totalMemory() returns total bytes, and maxMemory() returns the maximum heap size. From these you can calculate the heap usage percentage.

17. Difference between heap and stack in Java.

The heap is a shared memory area where objects and arrays are allocated. The stack is thread‑private, storing method frames and local primitives. Stacks are usually smaller and not shared across threads, while the heap is larger and shared.

18. Describe the principle of JVM class file loading.

Class loading is performed by ClassLoaders and their subclasses. When a class is needed, the JVM uses a ClassLoader to locate and load the .class file, creating a Class object in the method area. After loading, the class undergoes linking (verification, preparation, resolution) and finally initialization.

19. What is GC and why is it needed?

GC (Garbage Collection) automatically reclaims memory of objects that are no longer reachable, preventing memory leaks and program crashes. Developers can request GC via System.gc() or Runtime.getRuntime().gc(), but the JVM may ignore the request.

20. Heap (shared among threads) – runtime data area

The heap stores all objects and arrays and is the primary area for GC. Modern JVMs use generational collection, dividing the heap into Young Generation (Eden, From Survivor, To Survivor) and Old Generation.

21. Method Area / Permanent Generation (shared among threads)

The Permanent Generation stores class metadata, constants, static variables, and JIT‑compiled code. In HotSpot, GC can manage the method area similarly to the heap, primarily reclaiming class metadata and unloading classes.

Runtime Constant Pool is part of the method area; it holds literals and symbolic references from class files.

22. JVM runtime memory

The Java heap is further divided into Young Generation (Eden, From Survivor, To Survivor) and Old Generation for GC purposes.

23. Young Generation

Used to store newly created objects, typically occupying one‑third of the heap. Frequent object creation leads to frequent Minor GCs. It consists of Eden, Survivor From, and Survivor To spaces.

Eden : Birthplace of new objects; large objects may be allocated directly to the Old Generation. When Eden fills, a Minor GC is triggered.

Survivor From : Holds survivors from the previous GC.

Survivor To : Holds survivors after the current GC.

Minor GC process (copy → clear → swap)

Minor GC uses the copying algorithm.

Copy live objects from Eden and Survivor From to Survivor To, incrementing their age. If an object reaches the age threshold, it is promoted to the Old Generation.

Clear Eden and Survivor From.

Swap Survivor To and Survivor From roles.

24. Old Generation

Stores long‑lived objects. Major (Full) GC is less frequent and uses the Mark‑Sweep algorithm, which first marks live objects then sweeps away the dead ones, potentially causing fragmentation.

25. Permanent Generation

Stores class metadata, constants, and static data. GC does not reclaim this area during normal operation; when it fills, a Full GC may be triggered, and eventually an OutOfMemoryError (PermGen space) can occur.

26. Java 8 and Metaspace

Java 8 removes the Permanent Generation and introduces Metaspace, which resides in native memory. Its size is limited only by the amount of native memory available.

27. Reference counting

Objects are reclaimed when their reference count drops to zero. This simple method cannot handle cyclic references.

28. Reachability analysis

To overcome cyclic reference problems, the JVM performs reachability analysis starting from GC Roots. Objects not reachable from any root are considered unreachable and eligible for reclamation after two marking phases.

29. Mark‑Sweep algorithm (Mark‑Sweep)

Two‑phase GC: first mark all live objects, then sweep away the unmarked ones. This algorithm can cause severe fragmentation.

30. Copying algorithm (copying)

Divides memory into two equal halves. One half is used until full; live objects are copied to the other half, and the used half is cleared, eliminating fragmentation but halving usable memory.

31. Mark‑Compact algorithm (Mark‑Compact)

Combines marking with compaction: after marking live objects, they are moved toward one end of memory, eliminating fragmentation.

32. Generational collection algorithm

Divides the heap into Young and Old generations based on object lifespan, applying different collection algorithms to each.

33. Young generation and copying algorithm

Most JVMs use the copying algorithm for the Young Generation because most objects die quickly, making copying cheap.

34. Old generation and mark‑compact algorithm

Old Generation uses the Mark‑Compact algorithm because it contains fewer objects and aims to minimize pause times.

The Permanent Generation (now Metaspace) stores class metadata, constants, and static data. Its reclamation mainly involves discarding unused constants and classes.

Object allocation primarily occurs in Eden; some large objects go directly to the Old Generation.

When Eden and Survivor From lack space, a GC copies surviving objects to Survivor To and clears the other spaces.

If an object cannot fit into Survivor To, it is promoted to the Old Generation.

After GC, Eden and Survivor To become the active spaces for the next cycle.

Objects surviving a certain number of Minor GCs (default 15) are promoted to the Old Generation.

35. Strong references

Strong references keep objects reachable; such objects are never reclaimed by GC, even if they become logically unused, making strong references a common source of memory leaks.

36. Soft references

Implemented via SoftReference. Objects reachable only through soft references are reclaimed only when the JVM is low on memory, making them useful for memory‑sensitive caches.

37. Weak references

Implemented via WeakReference. Objects reachable only through weak references are reclaimed at the next GC cycle, regardless of memory pressure.

38. Phantom references

Implemented via PhantomReference. They must be used together with a reference queue and are primarily used to track object finalization.

39. Generational collection algorithm

Modern JVMs adopt generational collection, dividing the heap into Young, Old, and (formerly) Permanent generations, allowing each region to use the most suitable GC algorithm.

40. Copying algorithm in Young Generation

Because most objects die quickly, copying them during Minor GC is cheap and efficient.

41. Mark‑compact algorithm in Old Generation

Since objects in the Old Generation have high survival rates, the JVM uses mark‑compact to avoid copying and to reclaim contiguous free space.

42. Region‑based collection algorithm

The heap is divided into multiple contiguous regions; each region can be collected independently, allowing the GC to control pause times by reclaiming a subset of regions.

43. GC collectors

Java heap is split into Young and Old generations. Young generation collectors use copying or mark‑sweep; Old generation collectors use mark‑compact. JDK 1.6 provides several collectors:

44. Serial collector (single‑thread, copying)

Serial is a basic single‑thread collector using the copying algorithm. It pauses all application threads during GC and is efficient on single‑CPU systems.

45. ParNew collector (Serial + multithreaded)

ParNew is the multithreaded version of Serial, also using copying. It pauses all application threads during GC and is the default Young Generation collector in Server mode.

46. Parallel Scavenge collector (multithreaded copying, high throughput)

Parallel Scavenge is a multithreaded Young Generation collector focusing on maximizing throughput (CPU time spent on user code versus GC).

57. Serial Old collector (single‑thread, mark‑compact)

Serial Old is the Old Generation counterpart of Serial, using a single thread and the mark‑compact algorithm. It is the default Old Generation collector in Client mode and can be paired with CMS in Server mode.

Parallel Scavenge paired with ParNew works similarly, both being multithreaded copying collectors.

58. Parallel Old collector (multithreaded mark‑compact)

Parallel Old is the Old Generation version of Parallel Scavenge, using multithreaded mark‑compact to provide high throughput for both generations.

59. CMS collector (multithreaded mark‑sweep, low pause)

CMS (Concurrent Mark‑Sweep) is an Old Generation collector aiming for minimal pause times. It uses four phases:

Initial Mark : Quickly marks objects directly reachable from GC Roots (pauses application threads).

Concurrent Mark : Traverses the object graph concurrently with application threads.

Remark : Re‑marks objects changed during the concurrent phase (pauses threads).

Concurrent Sweep : Reclaims unreachable objects concurrently.

60. G1 collector

G1 (Garbage‑First) is a modern collector that uses mark‑compact without fragmentation and can predictably control pause times while maintaining high throughput. It divides the heap into fixed‑size regions, tracks their garbage levels, and collects the regions with most garbage within a given pause budget.

61. JVM class loading mechanism

Class loading consists of five phases: Loading, Verification, Preparation, Resolution, and Initialization.

Loading : Reads the .class file bytes and creates a Class object in the method area.

Verification : Ensures the bytecode complies with JVM specifications and does not violate security.

Preparation : Allocates memory for static variables and sets default values (e.g., zero for primitives).

Resolution : Replaces symbolic references in the constant pool with direct references.

Initialization : Executes static initializers and <clinit> method; parent classes are initialized before child classes.

62. Class loaders

JVM provides three primary class loaders:

Bootstrap ClassLoader : Loads core Java libraries from JAVA_HOME/lib or paths specified by -Xbootclasspath.

Extension ClassLoader : Loads classes from JAVA_HOME/lib/ext or directories specified by java.ext.dirs.

Application (System) ClassLoader : Loads classes from the application classpath; it is the default parent for user‑defined class loaders.

63. Parent‑delegation model

When a class loader receives a load request, it first delegates to its parent. Only if the parent cannot find the class does the child attempt to load it. This ensures that core classes (e.g., java.lang.Object) are loaded by the Bootstrap loader, guaranteeing a single definition.

64. OSGi (dynamic module system)

OSGi (Open Service Gateway Initiative) is a set of specifications for a dynamic module system for Java, enabling modular development and runtime component management.

65. Dynamic reconfiguration

OSGi allows services to be added, removed, or updated on the fly without restarting the host, reducing coupling and supporting hot‑plug capabilities.

66. Modular programming and hot‑plug

OSGi provides a foundation for modular Java applications with the ability to hot‑swap modules, which is attractive for enterprise software requiring minimal downtime.

67. JVM memory model

Thread‑private areas: Stack, Native Method Stack, Program Counter. Thread‑shared areas: Heap, Method Area.

68. Stack

Also called the method stack; a thread‑private area that stores local variables, operand stack, dynamic linking, and return addresses for each method call.

69. Native method stack

Similar to the Java stack but used for native (non‑Java) method execution.

70. Program counter

Holds the address of the next bytecode instruction for the current thread; empty for native methods.

71. Heap

The largest JVM memory area, shared among all threads, used for object allocation. When the heap is exhausted, an OutOfMemoryError is thrown.

72. Method area

Also known as the non‑heap area; stores loaded class metadata, constants, static variables, and JIT‑compiled code. In Java 7 it is the Permanent Generation; in Java 8 it is implemented as Metaspace.

73. Generational reclamation

Based on the observation that most objects die young, the heap is divided into generations to apply appropriate collection algorithms.

74. Differences between heap and stack

Function : Stack stores method frames and local primitives; heap stores objects.

Sharing : Stack is thread‑private; heap is shared across threads.

Failure : Stack overflow results in StackOverflowError; heap exhaustion results in OutOfMemoryError.

Size : Stack is much smaller than the heap.

75. When does Full GC occur?

Beyond explicit System.gc() calls, Full GC is triggered when:

Old Generation runs out of space.

Permanent Generation (or Metaspace) becomes full.

CMS encounters promotion failures or concurrent mode failures.

The average size of objects promoted from Minor GC exceeds the remaining Old Generation space.

Additionally, RMI may trigger a Full GC every hour unless disabled.

76. What is the Java Virtual Machine and why is Java called a "platform‑independent" language?

The JVM is a process that executes Java bytecode. Java source files are compiled to bytecode, which can run on any platform that provides a compatible JVM, making Java platform‑independent.

77. Object allocation rules

Objects are first allocated in Eden; if Eden lacks space, a Minor GC occurs.

Large objects are allocated directly in the Old Generation to avoid copying overhead.

Long‑living objects are promoted to the Old Generation after surviving a configurable number of Minor GCs (default age threshold is 15).

If the total size of objects of a certain age in Survivor exceeds half the Survivor space, objects of that age are promoted early.

During Minor GC, the JVM calculates the average size of objects moving to Old Generation; if this exceeds the remaining Old Generation space, a Full GC may be triggered.

78. Describe the JVM class‑file loading mechanism?

Class loading is performed by ClassLoaders. When a class is needed, the JVM uses the Bootstrap loader, then Extension, then System loader (parent‑delegation). The loader reads the .class file bytes, creates a Class object, and then proceeds through verification, preparation, resolution, and initialization.

79. Java object creation process

The JVM encounters a new‑object instruction, resolves the symbolic reference from the constant pool, and loads the class if necessary.

Memory is allocated for the object (using techniques such as pointer bumping, free‑list, or Thread‑Local Allocation Buffer).

The object’s fields (except the header) are zero‑initialized.

The object header is set (including class pointer, hash code, lock information, etc.).

80. Brief description of Java object layout

Java objects consist of three parts: object header, instance data, and alignment padding. The header contains a mark word (hash code, GC age, lock state, etc.) and a class pointer. Instance data holds the actual fields, and padding ensures 8‑byte alignment.

81. How to determine if an object can be reclaimed

Two main approaches:

Reference counting : Increment/decrement a counter for each reference; when it reaches zero, the object can be reclaimed (does not handle cycles).

Reachability analysis : Starting from GC Roots, traverse reference chains; objects not reachable are considered dead and eligible for collection.

82. Does GC happen in the permanent generation?

GC does not run directly in the Permanent Generation. When it becomes full, a Full GC is triggered, which may reclaim space in the Permanent Generation.

83. Garbage‑collection algorithms

Basic algorithms include Mark‑Sweep, Copying, and Mark‑Compact. Modern collectors combine these with generational collection.

84. Tuning commands

JDK monitoring and troubleshooting commands include: jps – JVM Process Status Tool. jstat – JVM statistics monitoring. jmap – Generates heap dumps. jhat – Analyzes heap dumps. jstack – Thread stack snapshots. jinfo – Displays and modifies JVM configuration.

85. Tuning tools

Common tools: jconsole – Java Monitoring and Management Console. jvisualvm – Visual monitoring, profiling, and heap analysis.

MAT (Memory Analyzer Tool) – Eclipse‑based heap analysis.

GChisto – GC log analysis.

86. When do Minor GC and Full GC happen?

Minor GC occurs when the Young Generation runs out of space; Full GC occurs when the overall JVM memory is insufficient.

87. Common JVM performance tuning techniques

Typical tuning includes setting heap size ( -Xmx), configuring Young Generation size ( -XX:NewSize, -XX:NewRatio, -XX:SurvivorRatio), and selecting appropriate collectors (e.g., -XX:+UseParNewGC for Young Generation, -XX:+UseConcMarkSweepGC for Old Generation).