github/awesome-kubernetes
1
0
Fork 0
mirror of https://github.com/nubenetes/awesome-kubernetes.git synced 2026-05-22 17:13:42 +00:00
Code Issues Packages Projects Releases Wiki Activity

chore: update docs/jvm-parameters-matrix-table.md [20260517-1948]

Browse Source
This commit is contained in:
github-actions[bot]
2026-05-17 19:51:58 +00:00
committed by GitHub
parent 04864361a9
commit c0f32cfcfe
1 changed files with 4 additions and 4 deletions
Download Patch File Download Diff File Expand all files Collapse all files

8
docs/jvm-parameters-matrix-table.md
View File

@@ -1,11 +1,11 @@
| **JVM Parameters** | **Enable?** | **References / Details** |
|:-------------------|:---|:---|
|-XX:+UseG1GC | Enabled by default in Java 8u191+ | Most important defaults specific to G1 and their default values.<br/> [https://dzone.com/articles/choosing-the-right-gc](https://dzone.com/articles/choosing-the-right-gc)<br/> [https://wiki.openjdk.java.net/display/HotSpot/G1GC+Feedback](https://wiki.openjdk.java.net/display/HotSpot/G1GC+Feedback)<br/> Alternative: Shenandoah GC |
|-XX:+UseShenandoahGC | Alternative to G1GC. | Shenandoah Garbage Collector: experimental in Java 8, newer than G1GC, available in some OpenJDK 8 and newer releases.<br/> [https://wiki.openjdk.java.net/display/shenandoah/Main](https://wiki.openjdk.java.net/display/shenandoah/Main) <br/> [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:+UseZGC | Yes (JDK 11+) | Z GC : Better Garbage Collector Algorithm than G1 or Shenandoah. JDK 11+ required.<br/> The Z Garbage Collector, also known as ZGC, is a scalable low latency garbage collector designed to meet the following goals:<br/> · Pause times do not exceed 10ms (*)<br/> · Pause times do not increase with the heap or live-set size<br/> · Handle heaps ranging from a 8MB to 16TB in size<br/> At a glance, ZGC is:<br/> · Concurrent<br/> · Region-based<br/> · Compacting<br/> · NUMA-aware<br/> · Using colored pointers<br/> · Using load barriers<br/> 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.<br/> 7 JVM Arguments of Highly Effective Applications<br/> [https://wiki.openjdk.java.net/display/zgc/Main](https://wiki.openjdk.java.net/display/zgc/Main) |
|-XX:+UseG1GC | Enabled by default in Java 8u191+ | Most important defaults specific to G1 and their default values.<br/> [https://dzone.com/articles/choosing-the-right-gc](https://dzone.com/articles/choosing-the-right-gc)<br/> [https://wiki.openjdk.org/spaces/HotSpot/pages/24674441/G1GC+Feedback](https://wiki.openjdk.org/spaces/HotSpot/pages/24674441/G1GC+Feedback)<br/> Alternative: Shenandoah GC |
|-XX:+UseShenandoahGC | Alternative to G1GC. | Shenandoah Garbage Collector: experimental in Java 8, newer than G1GC, available in some OpenJDK 8 and newer releases.<br/> [https://wiki.openjdk.org/spaces/shenandoah/pages/25002018/Main](https://wiki.openjdk.org/spaces/shenandoah/pages/25002018/Main) <br/> [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:+UseZGC | Yes (JDK 11+) | Z GC : Better Garbage Collector Algorithm than G1 or Shenandoah. JDK 11+ required.<br/> The Z Garbage Collector, also known as ZGC, is a scalable low latency garbage collector designed to meet the following goals:<br/> · Pause times do not exceed 10ms (*)<br/> · Pause times do not increase with the heap or live-set size<br/> · Handle heaps ranging from a 8MB to 16TB in size<br/> At a glance, ZGC is:<br/> · Concurrent<br/> · Region-based<br/> · Compacting<br/> · NUMA-aware<br/> · Using colored pointers<br/> · Using load barriers<br/> 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.<br/> 7 JVM Arguments of Highly Effective Applications<br/> [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.<br/> [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<br/> -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.<br/> [https://merikan.com/2019/04/jvm-in-a-container/](https://merikan.com/2019/04/jvm-in-a-container/)<br/> [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<br/> -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.<br/> [https://www.merikan.com/2019/04/jvm-in-a-container//](https://www.merikan.com/2019/04/jvm-in-a-container//)<br/> [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.<br/> [https://dzone.com/articles/7-jvm-arguments-of-highly-effective-applications-1](https://dzone.com/articles/7-jvm-arguments-of-highly-effective-applications-1)<br/> Each application will have tens, hundreds, thousands of threads. Each thread will have its own stack. Each one of them consumes memory. <br/>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.<br/> Linux 64-bit JVM Default thread stack size = 1024k<br/> -Xss2m : This will set the thread's stack size to 2mb |
|-Dsun.net.client.defaultConnectTimeout<br/>-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) |