Optimizing JVM GC for High‑Throughput E‑Commerce Order Systems

Background: In high‑traffic e‑commerce scenarios such as flash‑sale (秒杀), the system is split into multiple micro‑services (order, product, discount, inventory, payment, etc.). When the order flow reaches 100 k TPS, the per‑second object allocation size must be estimated to guide JVM GC tuning.

To choose a garbage collector, consider two metrics: throughput (ratio of time spent on the application vs. GC) and response time (average GC pause). Common configurations use ParNew for the young generation and CMS for the old generation, while JDK 8+ recommends G1. For latency‑sensitive e‑commerce, CMS is often preferred.

Then, how should JVM parameters be set?

Heap Size Settings

With an 8 GB server, typically half of the memory is allocated to the JVM. A basic configuration is:

-Xms8192M -Xmx8192M -Xmn2048M -Xss1M -XX:MetaspaceSize=256M -XX:MaxMetaspaceSize=256M -XX:SurvivorRatio=8

Because most objects in the order flow are short‑lived, this setting can cause frequent Full GC. Increasing the young generation size reduces the promotion rate:

-Xms8192M -Xmx8192M -Xmn4086M -Xss1M -XX:MetaspaceSize=256M -XX:MaxMetaspaceSize=256M -XX:SurvivorRatio=8

Adjusting the young generation keeps short‑lived objects in Survivor space and avoids unnecessary Full GC, which would otherwise pause the application.

Besides young‑generation size, what else can be optimized?

Common JVM Parameter Optimizations

Dynamic object age: default is 15. In the order scenario objects become garbage within seconds, so lowering -XX:MaxTenuringThreshold (e.g., to 5) moves them to the old generation earlier.

Large objects: objects larger than 2 MB that persist can be allocated directly in the old generation using -XX:PretenureSizeThreshold=2M .

CMS fragmentation: enable -XX:+UseCMSCompactAtFullCollection and set -XX:CMSFullGCsBeforeCompaction to trigger compaction after a number of Full GCs.

Metaspace size: set to 256 M to avoid Full GC caused by class metadata overflow.

JIT code cache: configure -XX:ReservedCodeCacheSize to ensure enough space for compiled code.

Escape analysis: when the JVM determines an object does not escape a method, it can allocate it on the stack, reducing heap pressure.