Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

For modern Java ZGC, start with the JVM’s adaptive defaults and tune -Xmx first. Set a maximum heap large enough for the live data plus allocation headroom while concurrent collection runs, then evaluate latency, throughput, and memory use under representative load. ZGC has been generational by default since JDK 24, so many older tuning guides describe flags or modes that no longer apply.

What changed in modern ZGC?

In JDK 24 and later, generational ZGC is the default, and the non-generational mode was removed. You do not need to add -XX:+ZGenerational on these releases. Check the documentation for the exact JDK running in production before copying flags from older guides. Oracle’s JDK 24 migration notes describe this change.

ZGC adapts its behavior by resizing generations, scaling GC threads, and adjusting tenuring thresholds. It is designed to need little manual tuning. Oracle describes it as a low-latency collector that performs expensive work concurrently; this is a design goal, not a guarantee of a particular application’s latency or throughput. The JDK 25 guide gives a supported heap range from a few hundred megabytes to 16 TB, but that range is not a performance benchmark or a recommended heap size for every application.

How should you size the ZGC heap?

Begin with -Xmx, the maximum heap size and the primary ZGC tuning control. The heap must hold the objects that remain live and leave room for allocations while collection proceeds. The necessary allocation headroom depends on the application’s allocation rate, live-set size, and collection behavior; there is no universal margin or ideal heap value.

Free tools Windows power users keep installed

One-click scans. No signup required.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

A larger maximum heap can give ZGC more room to operate and may reduce collection pressure, but it also permits greater memory use. Compare the application’s latency distribution, throughput, and process footprint under representative load as you adjust it. Oracle’s JDK 25 garbage-collection guide calls setting the maximum heap the most important ZGC tuning option.

When is SoftMaxHeapSize useful?

-XX:SoftMaxHeapSize gives ZGC a preferred upper limit for its heap-sizing heuristics. It is not a hard cap: when needed, ZGC can exceed the soft limit up to -Xmx to avoid stalling the application.

For example, Oracle documents -Xmx5g -XX:SoftMaxHeapSize=4g. This sets a 5 GB maximum and a 4 GB soft target; it does not guarantee that the heap will stay at or below 4 GB. Use a soft target when you want to encourage a smaller footprint while retaining a larger ceiling for periods of demand.

How do memory-return settings affect latency and footprint?

By default, ZGC uncommits unused heap memory. Returning memory can reduce process footprint, but committing or uncommitting memory while the application runs can affect latency. Choose settings according to whether lower footprint or the most predictable latency matters more for your service.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.
  • -XX:-ZUncommit disables uncommit.
  • -XX:ZUncommitDelay=<seconds> changes how long ZGC waits before uncommitting unused memory. Oracle documents a default delay of 300 seconds; that is a default, not a universally optimal setting.

For workloads where extremely low latency takes priority, Oracle suggests setting -Xms equal to -Xmx and using -XX:+AlwaysPreTouch. This reserves and prepares memory up front, trading a larger upfront memory commitment for less memory-management work during application operation. Confirm the memory cost is acceptable for the host or container before adopting it.

Should you configure large pages?

Large pages can improve throughput, latency, and startup time, according to Oracle, but they add setup complexity and typically require root privileges. Treat them as a platform-specific experiment rather than a universal ZGC setting.

On Linux, distinguish explicit huge pages from transparent huge pages. Oracle cautions that transparent huge pages are usually not recommended for latency-sensitive applications because they can cause unwanted latency spikes. Verify kernel and page settings before comparing collectors: different collectors may use huge pages differently, so a comparison with mismatched settings can be misleading.

How do you evaluate a ZGC tuning change?

Change one meaningful setting at a time and test under representative application load. Use application-specific metrics alongside GC diagnostic output; a collector’s pause behavior alone does not show whether the service is meeting its goals.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.
  • Compare latency distributions, not just an average, against the service’s response-time requirements.
  • Track throughput and application behavior as well as process memory footprint.
  • Observe the workload’s live data and allocation behavior, since both affect the heap room ZGC needs.
  • Keep deployment conditions consistent when comparing settings or collectors, including heap sizing, available processor resources, and page configuration.

Oracle’s broader guidance notes that promptness—the time between an object becoming dead and its memory becoming available—can also matter in some distributed systems. The appropriate balance depends on workload behavior and user requirements; no single generation size or tuning profile fits every application.

Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Support on Ko-Fi

Should you use ZGC or another collector?

Choose based on the service’s requirements, then compare collectors under the same deployment conditions and representative workload. Oracle positions ZGC for applications where response time is a high priority and notes a throughput cost. G1 is mostly concurrent and aims to meet pause goals while achieving throughput. Parallel GC is intended for high application performance when longer pauses are acceptable. These are design trade-offs, not guarantees that one collector will outperform another on a particular service.

Heap size, live data, and available processor resources all influence collector performance. Oracle’s JDK 25 collector overview describes the available collectors and their intended trade-offs; its JDK 24 implementation guide provides further context on garbage-collection behavior.

Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.