Java 凭借着自身活跃的开源社区和完善的生态优势，在过去的二十几年一直是最受欢迎的编程语言之一。步入云原生时代，蓬勃发展的云原生技术释放云计算红利，推动业务进行云原生化改造，加速企业数字化转型。

然而 Java 的云原生转型之路面临着巨大的挑战，Java 的运行机制和云原生特性存在着诸多矛盾。企业借助云原生技术进行深层次成本优化，资源成本管理被上升到前所未有的高度。公有云上资源按量收费，用户对资源用量十分敏感。在内存使用方面，基于 Java 虚拟机的执行机制使得任何 Java 程序都会有固定的基础内存开销，相比 C++/Golang 等原生语言，Java 应用占用的内存巨大，被称为“内存吞噬者”，因此 Java 应用上云更加昂贵。并且应用集成到云上之后系统复杂度增加，普通用户对云上 Java 应用内存没有清晰的认识，不知道如何为应用合理配置内存，出现 OOM 问题时也很难排障，遇到了许多问题。

为什么堆内存未超过 Xmx 却发生了 OOM？怎么理解操作系统和JVM的内存关系？为什么程序占用的内存比 Xmx 大不少，内存都用在哪儿了？为什么线上容器内的程序内存需求更大？本文将 EDAS 用户在 Java 应用云原生化演进实践中遇到的这些问题进行了抽丝剥茧的分析，并给出云原生 Java 应用内存的配置建议。

1.背景知识

K8s 应用的资源配置

云原生架构以 K8s 为基石，应用在 K8s 上部署，以容器组的形态运行。K8s 的资源模型有两个定义，资源请求（request）和资源限制（limit），K8s 保障容器拥有 request数量的资源，但不允许使用超过limit数量的资源。以如下的内存配置为例，容器至少能获得 1024Mi 的内存资源，但不允许超过 4096Mi，一旦内存使用超限，该容器将发生OOM，而后被 K8s 控制器重启。 

spec:
  containers:
  - name: edas
    image: alibaba/edas
    resources:
      requests:
        memory: "1024Mi"
      limits:
        memory: "4096Mi"
    command: ["java", "-jar", "edas.jar"]