案例：容器化（K8s）环境的 JVM 内存陷阱本文是《JVM调优实战》专栏第 33 讲。引言把 JVM 应用从虚拟机搬到 Kubernetes，就像让一个习惯住大房子的人搬进精装修公寓。虚拟机时代，JVM 看到的是整台物理机的内存，想用多少用多少；而容器时代，Pod 被resources.limits.memory严格约束，超出即被杀。很多团队在上 K8s 时踩的第一个坑就是：明明设了 -Xmx，比容器限制还小，为什么 Pod 还是被 OOMKilled？本文还原了一个典型的容器化 JVM 内存排查案例。问题表象简单 — — Pod 不断重启，K8s 事件显示 OOMKilled — — 但根因却是 JVM 内存模型与容器限制之间的认知鸿沟。问题现象某微服务从虚拟机迁移到 Kubernetes 后，运维团队发现 Pod 频繁重启：kubectl get pods-nproductionNAME READY STATUS RESTARTS AGE order-servic