/tags/jvm/ Recent content in JVM on Hugo -- gohugo.io en Wed, 01 Apr 2026 10:00:00 +0800 /posts/java-jvm-k8s-2026/ Wed, 01 Apr 2026 10:00:00 +0800 /posts/java-jvm-k8s-2026/ 引言 在 2026 年的云原生环境中，Java 应用部署到 Kubernetes（K8s）已经比较常见。不过，很多团队仍然沿用早期 JVM 配置方式，这类配置在容器里不一定合适，也容易带来资源浪费或 OOMKilled。 Akamas 在 2026 年 2 月发布的一份调查1提到，60% 的 JVM 工作负载未明确配置 GC，不少部署没有显式设置堆内存上限。我把它当作一个值得参考的行业观察，而不是绝对结论。 Java 25 于 2025 年 9 月发布，是继 Java 21 之后的最新长期支持版本（LTS）。而 Java 26（非 LTS）也已于 2026 年 3 月正式发布。本文结合 Java 25/26 的一些新特性，以及 2026 年实验验证数据，整理我当前比较认可的一组 Kubernetes 容器化 JVM 参数思路。 核心前提：容器感知已是本能 Java 版本与容器感知 Java 版本 -XX:+UseContainerSupport 默认行为 Java 8u191 之前 ❌ 不支持容器感知 Java 8u191+ ✅ 支持，需手动启用 Java 10+ ✅ 默认启用，无需配置 Java 17/21/23/25/26 ✅ 默认启用，高度优化 我的经验是： 使用 Java 10+ 时，通常不需要再手动配置 -XX:+UseContainerSupport。JVM 已经能够读取 Cgroups v2 提供的内存限制和 CPU 配额。 /posts/java25-k8s-jvm-config/ Wed, 11 Mar 2026 12:00:00 +0800 /posts/java25-k8s-jvm-config/ Akamas 发布的 The State of Java on Kubernetes 2026 提出了一个让人不安的论断：很多跑在 Kubernetes 上的 Java 应用，默认配置可能正在悄无声息地浪费资源、降低性能，甚至让服务在压力下更容易失稳。 联系到最近我碰到的生产环境上的 oom 和 CPU 限制问题。于是我用 Java 25 + Spring Boot 3.5.1 + kind 本地集群搭了一套实验环境，用真实数据来验证这些说法。 结论先说：按这次实验结果看，这些担心大多都有依据，而且修复成本并不高。 实验设计 用一个 Spring Boot 应用暴露两个压测端点： GET /stress/memory?mb=N：分配 N MB 短生命周期对象，触发 GC GET /stress/cpu?seconds=N：持续计算质数 N 秒，消耗 CPU k6 混合打压（60% 内存请求 + 40% CPU 请求，10 VUs，60 秒），通过 Spring Actuator 采集 JVM 指标。 基准容器规格：1c / 1Gi，4 个场景： 场景 JVM 参数 资源 验证目标 01-default 无 1c / 1Gi 默认配置基准 02-heap-fixed MaxRAMPercentage=75 1c / 1Gi 修复堆大小 03-cpu-throttle MaxRAMPercentage=75 250m / 1Gi CPU 节流影响 04-pod-small MaxRAMPercentage=75 0.