那么如果设置了 -yjm 1024 ，JobManager的JVM的堆内存大小是多少呢？
本文参考Flink1.10官方多篇文章相关知识收集、翻译、整合和内化而写成的关于Flink内存模型详解的文章，其中Job Manager、Task Manager和Client 分别是什么，各自之间的运行关系怎样，任务运行过程中所使用任务槽和资源情况的内存模型构成详解，内存设置需要配置哪些参数，参数功能描述等。暂时不熟悉Flink相关概念的童鞋自觉查阅笔者以往分享关于Flink术语基本概念的文章链接：Flink优化器与源码解析系列--Flink相关基本概念。
Apache Flink 基于 JVM 的高效处理能力，依赖于其对各组件内存用量的细致掌控。 考虑到用户在 Flink 上运行的应用的多样性，尽管社区已经努力为所有配置项提供合理的默认值，仍无法满足所有情况下的需求。 为了给用户生产提供最大化的价值， Flink 允许用户在整体上以及细粒度上对集群的内存分配进行调整。
Apache Flink通过严格控制其各种组件的内存使用，在JVM之上提供高效的工作负载。
前文我们没有提到，如何限制元空间的大小，其实就是限制 commit 的内存大小。元空间的限制不只是受限于我们的参数配置，并且前面我们提到了，元空间的内存回收也比较特殊，元空间的内存基本都是每个类加载器的 ClassLoaderData 申请并管理的，在类加载器被 GC 回收后，ClassLoaderData 管理的这些元空间也会被回收掉。所以，GC 是可能触发一部分元空间被回收了。所以元空间在设计的时候，还有一个动态限制 _capacity_until_GC，即触发 GC 的元空间占用大小。当要分配的空间导致元空间整体占用超过这个限制的时候，尝试触发 GC。这个动态限制也会在每次 GC 的时候动态扩大或者缩小。动态扩大以及缩小
java 程序是运行在jvm 虚拟机里面的，离开jvm虚拟机，那么java程序无法直接在linux平台的运行。 所以java应用程序和os 平台之间是隔着jvm虚拟机的。 所谓的jvm虚拟机，本质上就是一个进程，此时它的内存模型和普通的进程有相同之处，但它又是java程序的管理者，所以它又有自己独特的内存模型. 从os层面来看jvm的进程，其内存模型包含如下几个部分： 内核内存 + jvm的code + jvm的data + jvm的 heap + jvm的stack + unused memory. 其中的heap, stack 就是我们常说的“堆栈” 空间. 我们更多需要从jvm作为java程序管理者的角度来看其内存模型： 此时jvm的内存空间可以分为两大类，分别是 “堆内存” 以及“非堆内存”，其中前者是可以分配给java程序使用的，而后者则是jvm进程自己使用的。 所以“堆内存”是我们要讨论的重点：
不同的 GC 堆大小动态伸缩有很大很大的差异（比如 ParallelGC 涉及 UseAdaptiveSizePolicy 启用的动态堆大小策略以及相关的 UsePSAdaptiveSurvivorSizePolicy、UseAdaptiveGenerationSizePolicyAtMinorCollection 等等等等的参数参与决定计算最新堆大小的方式以及时机），在这个系列以后的章节我们详细分析每个 GC 的时候再详细分析这些不同 GC 的动态伸缩策略。我们这里仅涉及大多数 GC 通用的堆大小伸缩涉及的参数：MinHeapFreeRatio 与 MaxHeapFreeRatio：
不同的 GC 情况下，初始化以及扩展的流程可能在某些细节不太一样，但是，大体的思路都是：
前面提到了虚拟内存需要映射物理内存才能使用，这个映射关系被保存在内存中的页表（Page Table）。现代 CPU 架构中一般有 TLB （Translation Lookaside Buffer，翻译后备缓冲，也称为页表寄存器缓冲）存在，在里面保存了经常使用的页表映射项。TLB 的大小有限，一般 TLB 如果只能容纳小于 100 个页表映射项。 我们能让程序的虚拟内存对应的页表映射项都处于 TLB 中，那么能大大提升程序性能，这就要尽量减少页表映射项的个数：页表项个数 = 程序所需内存大小 / 页大小。我们要么缩小程序所需内存，要么增大页大小。我们一般会考虑增加页大小，这就大页分配的由来，JVM 对于堆内存分配也支持大页分配，用于优化大堆内存的分配。那么 Linux 环境中有哪些大页分配的方式呢？
我们过一下元空间内存分配流程，我们会忽略一些 GC 相关的还有并发安全的细节，否则涉及的概念太多，一下说不过来，这些细节，会在以后的系列中详细提到。
概述：命令jmap是一个多功能的命令。它可以生成 java 程序的 dump 文件， 也可以查看堆内对象示例的统计信息、查看 ClassLoader 的信息以及 finalizer 队列。
我们前面介绍了元空间的组成元素，但是没有将他们完整的串联起来，我们这里举一个简单的例子，将之前的所有元素串联起来。
Java虚拟机（JVM）是Java应用的运行环境，从一般意义上来讲，JVM是通过规范来定义的一个虚拟的计算机，被设计用来解释执行从Java源码编译而来的字节码。更通俗地说，JVM是指对这个规范的具体实现。这种实现基于严格的指令集和全面的内存模型。另外，JVM也通常被形容为对软件运行时环境的实现。通常JVM实现主要指的是HotSpot。
非标准参数表示不保证所有JVM实现都支持这些参数，在将来的JVM版本中可能会发生改变。非标准参数统一以 -X 开头，如 -Xmx20M 设置最大java堆大小，示例：
JVM中, 所有对象都是在堆中分配内存空间的,栈只用于保存局部变量和临时变量,如果是对象,只保存引用,实际内存还是在堆中;一个java对象占用的内存空间,除了一个固定大小的空间用于描述这个对象属于哪个类,其它的就用于保存它的字段的值;默认的java虚拟机的大小比较小，在对大数据进行处理时java就会报错：java.lang.OutOfMemoryError。设置jvm内存的方法，对于单独的.class，可以用下面的方法对Test运行时的jvm内存进行设置。
Tomcat本身不能直接在计算机上运行，需要依赖于硬件基础之上的操作系统和一个Java虚拟机。Tomcat的内存溢出本质就是JVM内存溢出，所以在本文开始时，应该先对Java JVM有关内存方面的知识进行详细介绍。
Tomcat本身不能直接在计算机上运行，需要依赖于操作系统和一个Java虚拟机。JAVA程序启动时JVM会分配一个初始内存和最大内存给APP。当APP需要的内存超出内存的最大值时虚拟机就会提示内存溢出，并且导致应用服务崩溃。
打开 IDEA 安装目录，看到有一个 bin 目录，其中有两个 vmoptions 文件，需针对不同的JDK进行配置：
在上面提到的 TLAB 大小设计的时候，我们经常提到期望。这个期望是根据历史数据计算得出的，也就是每次输入采样值，根据历史采样值得出最新的期望值。不仅 TLAB 用到了这种期望计算，GC 和 JIT 等等 JVM 机制中都用到了。这里我们来看一种 TLAB 中经常用到的 EMA（Exponential Moving Average 指数平均数） 算法：
王子在之前的JVM文章中已经大体上把一些原理性问题说清楚了，今天主要是介绍一些实际进行JVM调优工作的工具和命令，不会深入讲解，因为网上资料很多，篇幅可能不长，但都是实用的内容，小伙伴们有不清楚的可以自行查找资料。
Linux 内存管理模型不是咱们这个系列的讨论重点，我们这里只会简单提一些对于咱们这个系列需要了解到的，如果读者想要深入理解，建议大家查看 bin 神（公众号：bin 的技术小屋）的系列文章：一步一图带你深入理解 Linux 虚拟内存管理
在基于物理的服务器（此处主要与容器平台进行区分，故此描述）上运行Java应用程序时，我们通常会使用Java虚拟机参数"-Xms、-Xmx"来指定Java堆内存的初始值和最大值。如果要将我们的应用程序移植到容器平台，如何在容器环境中配置Java堆内存大小呢？有没有最佳做法？在本文中，我们将讨论可用于指定Java堆内存大小的JVM参数以及最优选择。
Java是以VM为基础的，而云原生讲究的就是Native，天然的矛盾，虽然Quarkus是为GraalVM和HotSpot量身定制的K8s Native Java框架，生态原因切换成本太高，这种矛盾体现在很多方面，比如：当你在物理机或者虚拟机上配置 JVM 参数时，你可以选择使用-Xmx/-Xms 来指定 Java 堆大小，但这样指定的话，就固定了 JVM 堆占用大小，如果将 Java 应用程序移植到容器或者说 K8s Pod 中，K8S 本身有垂直扩容的能力，如果我把内存从 8G 增长到 16G，JVM 如何感知到呢？我们又该如何配置 Java 堆大小呢？本文我们讨论下如何在 Java 容器中参数配置的最佳实践。
在上一篇博文：【JAVA】JVM 内存区域的划分 中介绍了 JVM 内存区域的划分，总结了相关的一些概念，本博文将结合 JVM 参数、工具等方面，进一步分析 JVM 内存结构，包括外部资料相对较少的堆外部分。
在一些物理内存为8g的服务器上，主要运行一个Java服务，系统内存分配如下：Java服务的JVM堆大小设置为6g，一个监控进程占用大约 600m，Linux自身使用大约800m。从表面上，物理内存应该
总的来说就是依照这些原则来解决这些问题以达到 GC 低频 GC 停顿时间短，以及低内存占用和高吞吐。
在一些物理内存为8g的服务器上，主要运行一个Java服务，系统内存分配如下：Java服务的JVM堆大小设置为6g，一个监控进程占用大约 600m，Linux自身使用大约800m。
JVM本质就是一个进程，因此其内存空间（也称之为运行时数据区，注意与JMM的区别）也有进程的一般特点。深入浅出 Java 中 JVM 内存管理，这篇参考下。
随着企业越来越多地了解到部署容器化应用程序的优点，有必要纠正 JVM 在云中表现不好的误解，尤其是在内存管理方面。虽然许多JVM可能不能完美地配置成在弹性云环境中运行，但各种可用的系统属性允许对JVM进行调优，以帮助最大限度地利用其主机环境。如果一个容器化的应用程序是使用OpenShift部署的，那么该应用程序可以利用Kubernetes Vertical Pod Autoscaler (VPA)，这是一个alpha特性。VPA就是一个例子，JVM的默认内存管理设置可能会降低在云中运行应用程序的好处。这篇博文将介绍配置和测试一个与VPA一起使用的容器化Java应用程序的步骤，这将演示JVM在云中运行时的适应性。
在开发spring cloud过程中一个很严重的资源问题就是内存占用过高，而实际上本机开发测试并没有很大的请求量，所以这是对电脑资源的一种严重的浪费，甚至导致IDE卡死、崩溃。
在jvm中有很多的参数可以进行设置，这样可以让jvm在各种环境中都能够高效的运行。绝大部分的参数保持默认即可。
作为一名工程师，项目调优这事，是必须得熟练掌握的事情。在Spring Boot项目中，调优主要通过配置文件和配置JVM的参数的方式进行。
如果想分析自己的JAVA Application时，可以使用jmap程序来生成heapdump文例： jmap -heap pid jmap是JDK自带的一个工具，非常小巧方便，其支持参数如下： -heap：打印heap空间的概要，这里可以粗略的检验heap空间的使用情况。 官网对jmap的解释是: DESCRIPTION
主要保证 GC 的时候扫描高效。由于 TLAB 仅线程内知道哪些被分配了，在 GC 扫描发生时返回 Eden 区，如果不填充的话，外部并不知道哪一部分被使用哪一部分没有，需要做额外的检查，如果填充已经确认会被回收的对象，也就是 dummy object， GC 会直接标记之后跳过这块内存，增加扫描效率。反正这块内存已经属于 TLAB，其他线程在下次扫描结束前是无法使用的。这个 dummy object 就是 int 数组。为了一定能有填充 dummy object 的空间，一般 TLAB 大小都会预留一个 dummy object 的 header 的空间，也是一个 int[] 的 header，所以 TLAB 的大小不能超过int 数组的最大大小，否则无法用 dummy object 填满未使用的空间。
公司众多系统中有一个系统使用的是 CMS 垃圾回收器，JVM 初始堆内存不等于最大堆内存，但通过监控信息发现：在经过一次 FullGC 之后，服务器物理内存剩余空间并未提升，运维同事告诉我说，有内存泄露，因为 GC 了之后，内存并没有被释放。按照大部分人的理解，FullGC 之后 JVM 进程会释放的内存一部分还给物理内存，下面通过几个实验来对比验证一下 CMS 和 G1 的物理内存归还机制。
作为一名工程师，项目调优这事，是必须得熟练掌握的事情。在 SpringBoot 项目中，调优主要通过配置文件和配置 JVM 的参数的方式进行。
在一些物理内存为8g的服务器上，主要运行一个Java服务，系统内存分配如下：Java服务的JVM堆大小设置为6g，一个监控进程占用大约 600m，Linux自身使用大约800m。从表面上，物理内存应该是足够使用的;但实际运行的情况是，会发生大量使用SWAP(说明物理内存不够使用 了)，如下图所示。同时，由于SWAP和GC同时发生会致使JVM严重卡顿，所以我们要追问：内存究竟去哪儿了要分析这个问题，理解JVM和操作系统之间的内存关系非常重要。接下来主要就Linux与JVM之间的内存关系进行一些分析。 一、Li
关于这些设置的JVM参数是什么意思，请参考第二步中的oracle官方给出的调优文档。
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
引言 在一些物理内存为8g的服务器上，主要运行一个Java服务，系统内存分配如下：Java服务的JVM堆大小设置为6g，一个监控进程占用大约600m，Linux自身使用大约800m。从表面上，物理内存
在一些物理内存为8g的服务器上，主要运行一个Java服务，系统内存分配如下：Java服务的JVM堆大小设置为6g，一个监控进程占用大约 600m，Linux自身使用大约800m。从表面上，物理内存应该是足够使用的；但实际运行的情况是，会发生大量使用SWAP(说明物理内存不够使用 了)，如下图所示。由于SWAP和GC同时发生会致使JVM严重卡顿，所以我们要追问：内存究竟去哪儿了？
JVM 直接内存（Direct Memory）是 JVM 运行时使用的一种特殊内存区域，它是 JVM 堆外的一块内存空间。在 Java 中，我们使用java.nio 包和java.lang.System类中的arraycopy()方法等来操作直接内存。
先来看一下官网上对flink内存设置的介绍。Flink JVM 进程的进程总内存（Total Process Memory）包含了由 Flink 应用使用的内存（Flink 总内存）以及由运行 Flink 的 JVM 使用的内存。Flink 总内存（Total Flink Memory）包括 JVM 堆内存（Heap Memory）和堆外内存（Off-Heap Memory）。其中堆外内存包括直接内存（Direct Memory）和本地内存（Native Memory）。
如果你用的是IDEA等开发工具，来启动运行项目，那么要调试JDK就方便太多了。另外，IDEA 系列教程全部整理好了，微信搜索Java技术栈，在后台发送：IDEA，可以在线阅读。
Java 19 中 Loom 终于 Preview 了，虚拟线程（VirtualThread）是我期待已久的特性，但是这里我们说的线程内存，并不是这种 虚拟线程，还是老的线程。其实新的虚拟线程，在线程内存结构上并没有啥变化，只是存储位置的变化，实际的负载线程（CarrierThread）还是老的线程。
JVM的-X参数是非标准参数，在不同版本的jvm中，参数可能会有所不同，可以通过java -X查看非标准参数。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
实时音视频
对象存储
云直播
