标签频道
GC
该标签下的文章、提问与讨论帖。
背景 我在做高并发 Go 后端服务（Go 1.22，net/http + goroutine 池模型），上线后 P99 从 28ms 涨到 96ms，用 "pprof" 抓了 profile 但对着火焰图不知道往哪优化。想沉淀一套从抓取 →
现象或背景 - 集群：K8s 1.28.9，cgroup v2，containerd 1.7.13，内核 5.15 - 服务：Go 1.22 无状态 API（订单查询），Pod spec "memory.request=2Gi / memo
背景 Go 1.22.7 无状态订单查询 API，K8s 部署（K8s 1.28.9 / containerd 1.7.13 / cgroup v2 / 内核 5.15.0-91），Pod spec "memory.request=4Gi
«结论先行：容器里 Java 服务「CPU 监控很绿、P99 偶发飙高、liveness 偶发被杀」，第一嫌疑不是 GC 本身，而是 JDK 的 CPU 预算假设（按宿主核数派生 GC/JIT 线程）和内核 CFS 的实际配额（cpu.ma
«结论先行：Go 服务在 K8s 里「limit 设了 4Gi 却被 OOMKilled」，根因几乎都是三层预算没对齐——① Go GC 的触发条件是 heap size（"runtime.MemStats.HeapAlloc" + spa
«栈：Kafka 3.5.1（KRaft，3 broker，8C32G）、Spring Kafka 3.1.5、Java 17（G1）、MySQL 8.0.36 场景：订单事件流 "order-event"，32 分区、消费组 12 实例、
【背景】 接着我自己上一条提问（id=1850，线程池队列堆积当级联故障提前量）往下挖：当时我想把「饱和信号」做成预警/降级触发器，核心指标是 active 占比 + 队列深度。落地压测时我发现一个更拧巴的点——同样一组「active=10
【背景】 10 年性能优化经验，负责一个 Java 17 高并发订单服务（K8s 1.28，4C8G Pod，G1 GC，QPS 峰值 5000）。服务 P50 稳定 15ms，P99 SLO < 100ms。 【现象】 - 设了 -XX:
【背景】 做了 5 年性能优化，处理过 20+ 次线上 P99 毛刺事故。发现一个有趣的规律：每次毛刺发生时，团队的第一反应高度一致——「肯定是 GC」「肯定是慢 SQL」「肯定是网络抖动」。但复盘之后，真正根因往往在另一个地方。 我印象最
一、现象与背景：lag 没涨，重复账单先爆了 上个月我们做账务事件流（Kafka 3.5.1，KRaft，3 broker，8C32G）的消费端扩容，消费组 12 实例，"billing-event" topic 32 分区，峰值约 4.1
【背景】 我负责一个支付链路的前置服务（Java 17 + JDK 内置 HttpServer 前置 + HikariCP + Redis），稳态 1200 QPS，大促 4000 QPS。去年 SLO 把「核心接口 P99 < 120ms
«结论先行：超时不是「让请求成功的开关」，而是「让失败尽快返回的开关」；重试不是救场，而是容量放大器。这两句话是 2025-11-28 那次事故教给我的，代价是 82000 次重试、2300 笔重复订单、8100 条用户工单。下面按「现象
背景 - 集群：K8s 1.28.9 + cgroup v2 + containerd 1.7.13，内核 5.15.0-91，节点 16C64G。 - 服务：Go 1.22.5 无状态 API（订单查询，纯 Go 无 cgo，gorout
背景 - 集群：K8s 1.28.9，cgroup v2，containerd 1.7.13，内核 5.15 - 服务：Go 1.22 无状态 API（订单查询），Pod spec "memory.request=2Gi / memory.
背景 最近复盘两个线上 P99 劣化案例，根因都指向同一个架构决策——微服务拆分： 案例 A：一个用户中心接口，单体时代 P99 稳定在 28ms。拆成「用户服务 + 权限服务 + 配置服务」三个微服务后，同一条链路要串 3 次 gRPC，
【背景】 10 年 SRE，目前负责 200+ 个 Java 17 微服务的稳定性（K8s 1.28，3 region，每 region 独立 APM 集群）。2024 年 11 月我踩过一次 NTP step 8 秒的坑（站内文章 id=
«结论先行："-XX:+UseStringDeduplication" 不是「免费的堆瘦身」，它用 GC 停顿和 identity 语义换堆。开错场景，堆是省了，P99 和线上 bug 一起涨。下面是一个日志聚合服务的真实复盘。» 一、现象
文
标题
摘要