From ede538c6da8983ec3207ae2667cff3db0ad732df Mon Sep 17 00:00:00 2001 From: "github-actions[bot]" <41898282+github-actions[bot]@users.noreply.github.com> Date: Mon, 18 May 2026 12:16:53 +0000 Subject: [PATCH] chore: update docs/jvm-parameters-matrix-table.md [20260518-1212] --- docs/jvm-parameters-matrix-table.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/jvm-parameters-matrix-table.md b/docs/jvm-parameters-matrix-table.md index cd703c72..bccbaa5f 100644 --- a/docs/jvm-parameters-matrix-table.md +++ b/docs/jvm-parameters-matrix-table.md @@ -5,7 +5,7 @@ |-XX:+UseZGC | Yes (JDK 11+) | Z GC : Better Garbage Collector Algorithm than G1 or Shenandoah. JDK 11+ required.
The Z Garbage Collector, also known as ZGC, is a scalable low latency garbage collector designed to meet the following goals:
· Pause times do not exceed 10ms (*)
· Pause times do not increase with the heap or live-set size
· Handle heaps ranging from a 8MB to 16TB in size
At a glance, ZGC is:
· Concurrent
· Region-based
· Compacting
· NUMA-aware
· Using colored pointers
· Using load barriers
At its core, ZGC is a concurrent garbage collector, meaning all heavy lifting work is done while Java threads continue to execute. This greatly limits the impact garbage collection will have on your application's response time.
7 JVM Arguments of Highly Effective Applications
[https://wiki.openjdk.org/spaces/zgc/pages/34668579/Main](https://wiki.openjdk.org/spaces/zgc/pages/34668579/Main) | |-XshowSettings:vm | Yes | This is a priceless feature to display all the settings of the JVM, together with -XX:+PrintCommandLineFlags it can show a world of hidden stuff.
[http://www.javamonamour.org/2018/11/java-showsettings.html](http://www.javamonamour.org/2018/11/java-showsettings.html) | |-XX:+UseStringDeduplication | Yes | [https://www.baeldung.com/jvm-garbage-collectors](https://www.baeldung.com/jvm-garbage-collectors) | -|-XX:+HeapDumpOnOutOfMemoryError
-XX:HeapDumpPath | Yes | When running a JVM in a docker container it is probably wise to use the HeapDumpOnOutOfMemoryError option so if you ever run out of memmory the jvm will write a dump of the heap to disk.
[https://www.merikan.com/2019/04/jvm-in-a-container//](https://www.merikan.com/2019/04/jvm-in-a-container//)
[https://dzone.com/articles/7-jvm-arguments-of-highly-effective-applications-1](https://dzone.com/articles/7-jvm-arguments-of-highly-effective-applications-1) | +|-XX:+HeapDumpOnOutOfMemoryError
-XX:HeapDumpPath | Yes | When running a JVM in a docker container it is probably wise to use the HeapDumpOnOutOfMemoryError option so if you ever run out of memmory the jvm will write a dump of the heap to disk.
[https://www.merikan.com/2019/04/jvm-in-a-container///](https://www.merikan.com/2019/04/jvm-in-a-container///)
[https://dzone.com/articles/7-jvm-arguments-of-highly-effective-applications-1](https://dzone.com/articles/7-jvm-arguments-of-highly-effective-applications-1) | |-Xss | Test | Increase the thread’s stack size limit by passing the -Xss argument.
[https://dzone.com/articles/7-jvm-arguments-of-highly-effective-applications-1](https://dzone.com/articles/7-jvm-arguments-of-highly-effective-applications-1)
Each application will have tens, hundreds, thousands of threads. Each thread will have its own stack. Each one of them consumes memory.
If their consumption goes beyond a certain limit, then a StackOverflowError is thrown. More details about StackOverflowError and solutions to resolve it can be found in this article.
Linux 64-bit JVM Default thread stack size = 1024k
-Xss2m : This will set the thread's stack size to 2mb | |-Dsun.net.client.defaultConnectTimeout
-Dsun.net.client.defaultReadTimeout | Yes | [https://dzone.com/articles/7-jvm-arguments-of-highly-effective-applications-1](https://dzone.com/articles/7-jvm-arguments-of-highly-effective-applications-1) | |-Duser.timeZone | Yes | [https://dzone.com/articles/7-jvm-arguments-of-highly-effective-applications-1](https://dzone.com/articles/7-jvm-arguments-of-highly-effective-applications-1) |