标签频道
G1GC
该标签下的文章、提问与讨论帖。
背景 我负责一个 Java 17 高并发服务（K8s 4C8G，G1 GC，-Xmx8g -XX:MaxGCPauseMillis=50 -XX:G1ReservePercent=15），日常 QPS 约 3k，对象分配率约 55MB/s，
«结论先行：JDK 11+ 在容器里自动感知 "memory.limit"，但 "MaxRAMPercentage" 默认只有 25%——16G 容器只给你 4G 堆。如果你的服务实际堆需求在 8~12G，删掉 "-Xmx" 后 GC 频率
背景 8 年性能调优，最近在复盘一个「不是事故、但让人坐立不安」的退化模式。 核心服务：Java 17（OpenJDK 17.0.9）+ G1 GC，"-Xmx8g -XX:MaxGCPauseMillis=50 -XX:G1Reserve
【背景】 一个订单查询服务，4C8G 容器（K8s，limit 4C / 8G），JDK 17，堆 -Xms6g -Xmx6g，-XX:MaxGCPauseMillis=50，RegionSize 自动（4M）。日常 QPS 2-3k，对象
背景 生产环境：K8s 1.28.9 + containerd 1.7.13 + cgroup v2 + 内核 5.15.0-91。节点 16C64G，跑一个 Java 17 / Spring Boot 3 的订单服务（无状态，4C8G P
【背景】 我做了 10 年性能优化，最近带团队复盘一个 Java 17（G1，-Xmx6g）的订单中台服务，单机 8C16G，QPS 约 3k。服务内有一个每 4 小时跑一次的库存对账定时任务：拉取上游全量 SKU（约 40 万条）到内存做
«结论先行：JDK 在容器里会「看见」宿主机的核数并据此派生 GC 并行线程数，但 Linux cgroup 只限制 CPU 用量、不限制 线程数——两者组合起来，会造出一个反直觉的故障模式：你给容器配的 CPU limit 越小，JDK
背景 我在一个核心结算服务上踩了一个反复出现的坑：Spring Boot 3 + JDK 17.0.8 + G1，"-Xmx8g -XX:MaxGCPauseMillis=50 -XX:InitiatingHeapOccupancyPerc
«结论先行：G1 的停顿目标 "MaxGCPauseMillis" 只是「建议值」，不是硬上限；真正的停顿杀手往往是 IHOP 阈值设得太晚导致并发标记追不上、退化成 Serial Old 的 Full GC，以及 Humongous 对象
文
标题
摘要