标签频道
JVM
该标签下的文章、提问与讨论帖。
«结论先行："-XX:MaxDirectMemorySize" 不设置时，JVM 默认把它等同于 "-Xmx"，但 Netty 4.1 的 PooledByteBufAllocator 走的是 "sun.nio.ch.DirectByteB
【背景】 - K8s 1.28.9 集群，cgroup v2，节点规格 32C256G - 核心 Java 17 服务（Spring Boot 3.2），12 个 Pod，每个 Pod memory request=4Gi / limit=
背景 我负责一个 Java 17 高并发服务（K8s 4C8G，G1 GC，-Xmx8g -XX:MaxGCPauseMillis=50 -XX:G1ReservePercent=15），日常 QPS 约 3k，对象分配率约 55MB/s，
背景 线上 Java 17 / Spring Boot 3 订单查询服务，K8s 1.28 部署（单 Pod 4C8G，节点 16C64G），G1 GC（-Xmx4g -XX:MaxGCPauseMillis=200），入口 QPS 稳定在
背景 做了 15 年性能调优，最近在排查一个 K8s 1.29 集群（cgroup v2、内核 5.15.0-91、containerd 1.7）上的 Java 服务 P99 毛刺。 - 服务：JDK 17 + G1GC，单 Pod 单容器
«结论先行：容器里 Java 服务「CPU 监控很绿、P99 偶发飙高、liveness 偶发被杀」，第一嫌疑不是 GC 本身，而是 JDK 的 CPU 预算假设（按宿主核数派生 GC/JIT 线程）和内核 CFS 的实际配额（cpu.ma
«结论先行：JDK 11+ 在容器里自动感知 "memory.limit"，但 "MaxRAMPercentage" 默认只有 25%——16G 容器只给你 4G 堆。如果你的服务实际堆需求在 8~12G，删掉 "-Xmx" 后 GC 频率
问
cgroup v2 memory.high 给存量 Java Pod 上「软限」怎么安全灰度：开启瞬间 reclaim 风暴 + JVM 堆已按 limit 定死，操作顺序、阈值与观测口径怎么定？
【背景】 K8s 1.28.9 + containerd 1.7.13 + 内核 5.15.0-91（cgroup v2），10 节点（16C64G）在线集群，主力负载是 Java 17 / Spring Boot 3.2 无状态订单服务，
背景 K8s 1.28.9 / containerd 1.7 / cgroup v2 / 内核 5.15，10 节点（16C64G）在线集群。一个 Java 17（Temurin 17.0.12）/ Spring Boot 3 无状态网关，
【背景】 先给结论：liveness 探针是 K8s 里最容易被低估的故障源，它不是部署模板里的勾选项，而是一条隐式的「自动重启回路」。 去年大促前一周，我们一个 8G 堆的 Java 服务（JDK 17，K8s 1.28，containe
背景 - K8s 1.28.9 / containerd 1.7.13 / 内核 5.15.0-91 / cgroup v2，10 节点（16C64G）在线集群。 - Java 17 / Spring Boot 3.2.5 无状态订单服务，
背景 在 ARM Cortex-A53（2C4G，8GB eMMC）的边缘网关上跑 K3s v1.31 + containerd 1.7.x，业务是一个 Java 17（Temurin）网关代理容器：request=limit=2500Mi
«结论先行：Spot 实例的「5 分钟回收预警」不是给你 JVM 排空用的，它只保证「收到信号后 5 分钟内你会被 SIGKILL」；而 JVM 从收到 SIGTERM 到进程真正退出，光 shutdown hook 里一个 "awaitT
【背景】 - K8s 1.28.9 集群，cgroup v2，节点规格 32C256G - 核心 Java 17 服务（Spring Boot 3.2），12 个 Pod，每个 Pod memory request=4Gi / limit=
结论先行 "CompletableFuture.supplyAsync(supplier)" 不传 executor 时默认走 "ForkJoinPool.commonPool"，而 commonPool 默认 worker 数 = "Ru
一、现象：同一个 1.2GB 文件，读一次 30ms，再读一次 2.5s，且反复横跳 先交代环境：K8s 1.28.9（cgroup v2，Ubuntu 22.04.4 内核 6.5），一个报表导出服务 Pod，规格 2C/2Gi，JVM
«结论先行：cgroup v2 的 "memory.high" 是一个「软限」（soft limit），它不杀进程，而是通过让内核在该水位下主动回收（reclaim）并施加「背压」（back-pressure，让进程在内存分配时主动 sle
【背景】 10 年性能优化经验，负责一个 Java 17 高并发订单服务（K8s 1.28，4C8G Pod，G1 GC，QPS 峰值 5000）。服务 P50 稳定 15ms，P99 SLO < 100ms。 【现象】 - 设了 -XX:
文
标题
摘要