Master Java JVM Tuning: Key Commands, GC Options & Reference Types

1. Java Process Command Line Startup

Run a Java program using the standard syntax:

java [-options] main_class_name [args...]

2. Java Tuning Parameters

The JVM non‑standard -X options vary between versions; list them with java -X.

The -XX options are also non‑standard and used for JVM tuning and debugging. View all -XX flags with java -XX:+PrintFlagsFinal -version. They can be specified as boolean ( -XX:+Flag or -XX:-Flag) or as key‑value pairs ( -XX:NewRatio=2).

-Xmx30M               // maximum heap size
-Xms30M               // initial heap size
-Xss128K              // thread stack size
-Xmn20M               // young generation size (≈1/3‑1/4 of heap)
-XX:MaxDirectMemorySize // max direct (off‑heap) memory
-XX:SurvivorRatio=eden/from=eden/to // ratio of eden to survivor spaces
-XX:NewRatio=old/young // ratio of old to young generation
-XX:+PrintGC          // print GC information
-XX:+PrintGCDetails   // detailed GC info per memory region
-XX:+PrintHeapAtGC   // heap dump before/after GC
-XX:+PrintGCTimeStamps // timestamps for GC events
-XX:+PrintGCApplicationConcurrentTime // application run time
-XX:+PrintGCApplicationStoppedTime   // application stop time
-XX:+DoEscapeAnalysis // enable escape analysis
-server               // use server VM mode
-XX:-UseTLAB          // disable thread‑local allocation buffers
-XX:+EliminateAllocations // enable scalar replacement
-XX:PermSize30M      // permanent generation size (JDK 6/7)
-XX:MaxPermSize30M   // max permanent generation size (default 64 MB)
-XX:MaxMetaspaceSize // metaspace size (JDK 8+)
-XX:+PrintReferenceGC // print reference queues
-Xloggc:log/gc.log   // write GC logs to file
-verbose:[class|gc|jni] // verbose class loading, GC, JNI
-XX:+TraceClassLoading // trace class loading
-XX:+TraceClassUnLoading // trace class unloading
-XX:+PrintClassHistogram // class histogram
-XX:+PrintVMOptions   // print VM options
-XX:+PrintCommandLineFlags // print command‑line flags
-XX:InitialHeapSize=10m // initial heap size
-XX:+PrintFlagsFinal // print all flag values
-XX:+HeapDumpOnOutOfMemoryError // dump heap on OOM
-XX:HeapDumpPath=xxx // path for heap dump
-XX:+UseSerialGC     // use Serial GC
-XX:MaxTenuringThreshold=xxx // max age before promotion
-XX:PretenureSizeThreshold=xxx // size threshold for direct promotion

3. Explanation

The actual usable memory may differ from the value set with -Xmx due to internal alignment algorithms.

If the heap lacks free space, it expands up to the maximum heap size.

It is recommended to set the young generation to about one‑third or one‑fourth of the total heap.

Direct (NIO) memory is faster than heap memory but should be used for infrequent allocations with high access frequency.

The JVM supports both client and server modes; the default is server mode, viewable with java -version.

Young generation favors copying collection; old generation favors mark‑compact collection.

A card table (bit‑set) tracks references from old to young generation, speeding up young‑gen GC.

Larger heap sizes increase GC pause times.

Soft and weak references are suitable for optional caches that can be reclaimed when memory is low.

4. Garbage‑Collection Algorithms

Reference counting – cannot handle cyclic references.

Mark‑compact – moves live objects to a contiguous region.

Mark‑sweep – leaves fragmentation.

Copying – wastes half of the memory.

Generational – separates young and old generations.

Region‑based – divides the heap into independent regions for independent reclamation.

5. Copying Algorithm Process

During GC, live objects in the Eden space are copied to an unused Survivor space (e.g., "to"). Objects in the currently used Survivor space ("from") are also copied to "to"; large or old objects may be promoted directly to the old generation. After copying, Eden and the former Survivor space contain only garbage and can be cleared, while "to" holds the surviving objects.

6. Definition of Garbage Objects

An object is reachable from GC roots; reachable objects are in use and not collected.

An unreachable object may be resurrected in its finalize() method; such objects should not be reclaimed prematurely.

Only objects that are truly unreachable can be safely reclaimed.

7. Strength of References and Reachability

Java defines four reference types:

Strong Reference – normal references; objects are never reclaimed while reachable.

Soft Reference – reclaimed only when the heap is low; implemented by java.lang.ref.SoftReference.

Weak Reference – reclaimed on any GC cycle; implemented by java.lang.ref.WeakReference.

Phantom Reference – the weakest; used with a reference queue to track object finalization.

Soft, weak, and phantom references reside in the java.lang.ref package; the phantom reference is associated with FinalReference to support finalize() handling.

Strong references keep objects reachable; soft, weak, and phantom references allow objects to become softly reachable, weakly reachable, or phantom reachable, respectively, and can be reclaimed under appropriate conditions.

8. Stop‑The‑World (STW)

Garbage collectors need to pause all application threads (STW) to obtain a consistent heap state, ensuring no new garbage is created during the marking phase; this pause makes the application appear frozen while GC runs.