g1垃圾回收器需协同配置核心参数以适配业务节奏：固定堆大小（-xms8g -xmx8g）、元空间（-xx:metaspacesize=256m -xx:maxmetaspacesize=512m）、停顿目标（-xx:maxgcpausemillis=150~200ms）、region大小（-xx:g1heapregionsize=4m）与ihop阈值（-xx:initiatingheapoccupancypercent=40），并合理设置线程数（-xx:parallelgcthreads=4、-xx:concgcthreads=2）及预留空间（-xx:g1reservepercent=15）。
直接上配置要点，不绕弯子。G1不是加个-XX:+UseG1GC就完事，关键在几个核心参数的协同和对业务节奏的适配。
基础启动与堆大小固定
必须设死初始堆和最大堆，避免运行时扩容抖动：
-
-Xms8g -Xmx8g（推荐值，根据机器内存50%~70%分配） - 搭配
-XX:+UseG1GC启用G1，JDK9+可省略，但显式写更清晰 - 元空间别漏掉：
-XX:MetaspaceSize=256m -XX:MaxMetaspaceSize=512m
停顿时间目标要务实
-XX:MaxGCPauseMillis不是承诺值，是G1努力逼近的目标。设太高没意义，太低会频繁GC拖垮吞吐量：
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
- 常规服务建议150~200ms；实时性要求高的可压到100ms，但需配合足够内存和CPU
- 若实际GC耗时持续超目标，先检查是否堆太小或年轻代占比不足，而不是盲目调低该值
- G1会据此动态调整每次回收的Region数量，目标不是“每次都不超”，而是“长期平均可控”
Region大小与老年代触发阈值
Region太大，大对象容易被拆散；太小，RSet开销飙升。IHOP设错，混合GC来得太晚，直接Full GC：
-
-XX:G1HeapRegionSize=4m（堆≤8G用4M；≥16G可试8M或16M，必须是2的幂） -
-XX:InitiatingHeapOccupancyPercent=40（默认45，偏高易延迟触发Mixed GC；观察老年代增长速率后微调） - 配合
-XX:+PrintGCDetails -Xlog:gc*:file=gc.log，用jstat -gcutil <pid></pid>盯住老年代使用率变化趋势
线程数与预留空间防晋升失败
STW阶段靠并行线程抢时间，并发标记靠额外线程减负担，预留空间给对象晋升兜底：
-
-XX:ParallelGCThreads=4（通常等于CPU物理核数） -
-XX:ConcGCThreads=2（建议设为ParallelGCThreads的1/4~1/2，避免抢应用线程资源） -
-XX:G1ReservePercent=15（预留15%堆空间，防止Mixed GC时老年代没空位导致晋升失败继而Full GC）
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
