JVM -Xmx内存设置超过物理内存问题思考

最新推荐文章于 2024-10-10 14:31:07 发布
最新推荐文章于 2024-10-10 14:31:07 发布
阅读量8.2k 收藏 18
点赞数 3
分类专栏： Java
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/mutian6655/article/details/117816542
版权
本文探讨了JVM的-Xmx参数是否可以超过物理内存，以及当内存接近物理内存耗尽时JVM的行为。通过实验验证，在Linux和Windows环境下，JVM可以设置较大的-Xmx值，但受限于操作系统和JVM自身限制。当物理内存耗尽，系统可能使用SWAP空间，导致性能下降。JVM的垃圾回收并不直接由物理内存大小触发，而是根据堆内存使用情况。测试中观察到，内存溢出和GC效率降低与物理内存接近饱和有关。
摘要由CSDN通过智能技术生成

文章目录

问题提出

JVM是否可以设置-Xmx超过物理内存？如果设置，当内存使用接近物理内存后会发生什么现象？会发生GC吗？

理论思考

1. 是否可以设置-Xmx超过物理内存？

  • 可以。
  • JVM并不在启动时申请如此大的内存。适当的超出物理内存是允许的。

2. 是否可以将-Xmx设置的无限大？

  • 不可以。
  • JVM的一些垃圾回收算法，会使用到卡表(card tables)、 bitmap等，如果JVM检验到Heap区内存大到无法创建这些引用，或着直接超出操作系统可以预定的最大内存，会报错。
  • 这个具体的值跟操作系统、JVM版本、物理机内存等都有关系

3. 当物理机内存耗尽时，会发生什么现象？

  • 以Linux为例，如果 开启了Swap
    • 内存耗尽时会使用Swap，系统会出现抖动 (thrashing) 现象，系统性能会急剧下降
  • 如果未开启Swap，内存耗尽，或着 Swap 区也耗尽 时会发生什么？
    • 会发生无法分配内存

4. JVM在堆内存不足和物理内存耗尽时会发生什么？

  1. 持续分配对象，首先在Eden区上无法分配对象时，会先触发 YoungGC
    1. 在触发YoungGC前，如果老年代剩余空间小于年轻代现有所有对象，且小于历次进入老年代的平均大小时，会先触发老年代空间分配担保，进行FullGC
  2. 如果对象长期存活，或着GC后触发动态年龄判断，对象会进入老年代，如果老年代装满时，触发 FullGC
  3. 触发 FullGC 后会有以下几种情况
    1. 如果是刚启动时，由于JVM启动时会先使用一个较小的内存（默认1/64内存大小），当GC后内存不足且没有到达 -Xmx 最大值时，会发生 堆扩容。
      1. 如果扩容时无法申请内存，将发生 JVM物理内存无法申请 错误
    2. 如果因启用 Swap 区后，系统性能下降，GC的时间持续太长后，可能会触发 OOM 超出GC开销限制 错误
      1. JVM如果花了98%的时间进行垃圾回收，而只得到2%可用的内存，频繁的进行内存回收(最起码已经进行了5次连续的垃圾回收)时，会报这个错误
    3. 如果在 FullGC 之后，未回收太多的空间，仍然无法放下对象时，会触发 OOM 堆内存溢出 错误

5. JVM会因为临近物理内存大小而发生GC吗

  1. 不会。
  2. JVM是否发生YoungGC和FullGC始终与JVM堆内存的使用情况有关，与物理内存没有直接的关系
  3. 如果不考虑Swap，通常未到达物理内存大小时，JVM就因为无法扩容而崩溃了

问题验证

测试代码

不断往static list中添加一个10M的对象，让内存溢出

import java.util.LinkedList;
import java.util.List;
import java.util.concurrent.TimeUnit;
public class TestGC {
    private static final List<TestGC> list = new LinkedList<>();
    public byte[] bytes = new byte[10*1024*1024];
    public static void main(String[] args) throws InterruptedException {
        // TimeUnit.SECONDS.sleep(15);
        long count = 0;
        for(;;){
            System.out.println(count++);
            list.add(new TestGC());
            // TimeUnit.MILLISECONDS.sleep(1000);
        }
    }
}

测试Xmx最大值

Windows

  • 测试环境

    • 操作系统 Window 10
    • JDK 1.8.0_241
    • 物理内存 16GB

  • java -Xmx100g TestGC

    • 正常启动

  • java -Xmx1400g TestGC

Error occurred during initialization of VM
Unable to allocate 2867200KB card tables for parallel garbage collection for the requested 1468006400KB heap.
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.
  • java -Xmx1600g TestGC
Error occurred during initialization of VM
Unable to allocate 52428800KB bitmaps for parallel garbage collection for the requested 1677721600KB heap.
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.

不在Windows下测试OOM情况，只测试是否可以启动

Linux

  • 测试环境

    • 操作系统：CentOS 7.9
    • JDK： openjdk 1.8.9_292
    • 物理内存：2GB
    • SWAP： 2GB

  • java -Xmx40t TestGC

    • 正常启动

  • java -Xmx87t TestGC

    • 报错
Error occurred during initialization of VM
Could not reserve enough space for 93415538688KB object heap

测试内存溢出

开启SWAP情况下
  • -Xmx 大于物理内存，但小于(物理内存+Swap)
    • java -Xmx3g TestGC
    • 在打印到 142 (内存接近1.5GB)时，速度开始明显下降
    • 最后打印到 295 (内存接近3GB)时，报错 OOM 堆内存溢出
...
293
294
295
Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
    at TestGC.<init>(TestGC.java:7)
    at TestGC.main(TestGC.java:14)
  • -Xmx 大于物理内存，且大于(物理内存+SWAP)
    • java -Xmx8g TestGC
    • 在打印到 142 时，速度开始明显下降
    • 最后打印到 199 时，报错 JVM 无法分配内存
...
196
197
198
199
OpenJDK 64-Bit Server VM warning: INFO: os::commit_memory(0x00000006e2e95000, 1338490880, 0) failed; error='无法分配内存' (errno=12)
#
# There is insufficient memory for the Java Runtime Environment to continue.
# Native memory allocation (mmap) failed to map 1338490880 bytes for committing reserved memory.
# An error report file with more information is saved as:
# /root/test-java/hs_err_pid3770.log
关闭SWAP情况下
  • 无论 java -Xmx3g TestGC 还是 java -Xmx8g TestGC 结果均如下
    • 最后打印到 89 时，报错 JVM 无法分配内存
...
83
84
85
86
87
88
89
OpenJDK 64-Bit Server VM warning: INFO: os::commit_memory(0x00000006f5c83000, 601100288, 0) failed; error='无法分配内存' (errno=12)
#
# There is insufficient memory for the Java Runtime Environment to continue.
# Native memory allocation (mmap) failed to map 601100288 bytes for committing reserved memory.
# An error report file with more information is saved as:
# /root/test-java/hs_err_pid3917.log

测试GC现象

  • 将代码中的注释放开
关闭Swap
  • 使用 jstat -gc PID 1000 10000 跟踪如下
 S0C    S1C    S0U    S1U      EC       EU        OC         OU       MC     MU    CCSC   CCSU   YGC     YGCT    FGC    FGCT     GCT   
1024.0 1024.0  0.0    0.0    8192.0   507.9    20480.0      0.0     4480.0 875.7  384.0   76.6       0    0.000   0      0.000    0.000
1024.0 1024.0  0.0    0.0    8192.0   507.9    20480.0    10240.0   4480.0 875.7  384.0   76.6       0    0.000   0      0.000    0.000
1024.0 1024.0  0.0    0.0    8256.0    0.0     30724.0    20743.0   4864.0 3003.3 512.0  287.0       1    0.001   1      0.001    0.002
1728.0 1728.0  0.0    0.0   13888.0  10240.0   34572.0    20743.0   4864.0 3003.6 512.0  287.0       2    0.001   2      0.003    0.004
1728.0 1728.0  0.0    0.0   13888.0  10240.0   34572.0    30983.0   4864.0 3004.0 512.0  287.0       3    0.003   2      0.003    0.006
3392.0 3392.0  0.0    0.0   27584.0  10240.0   68708.0    41223.1   4864.0 3004.0 512.0  287.0       4    0.005   3      0.004    0.009
3392.0 3392.0  0.0    0.0   27584.0  21022.0   68708.0    41223.1   4864.0 3004.0 512.0  287.0       4    0.005   3      0.004    0.009
...
33280.0 33280.0  0.0   30721.4 266496.0 230392.1  666044.0   624904.5  4864.0 3007.0 512.0  287.0      11    0.233   6      0.025    0.258
33280.0 33280.0  0.0   30721.4 266496.0 240632.1  666044.0   624904.5  4864.0 3007.0 512.0  287.0      11    0.233   6      0.025    0.258
33280.0 33280.0  0.0   30721.4 266496.0 250872.2  666044.0   624904.5  4864.0 3007.0 512.0  287.0      11    0.233   6      0.025    0.258
33280.0 33280.0  0.0   30721.4 266496.0 261112.2  666044.0   624904.5  4864.0 3007.0 512.0  287.0      11    0.233   6      0.025    0.258

并没有看到 在接近物理内存时的 GC，发生时机与预期一致

打开Swap
  • 现象与关闭时的类似
  • 在临近报错时，可以看到最后两次明显的GC时间变长，说明GC效率下降，系统变慢
 S0C    S1C    S0U    S1U      EC       EU        OC         OU       MC     MU    CCSC   CCSU   YGC     YGCT    FGC    FGCT     GCT  
73408.0 73408.0 71680.7 71683.3 587328.0 584592.5 1478424.0  1474827.5  4864.0 3027.2 512.0  287.0      14    1.836   7      0.029    1.865
73408.0 73408.0 71681.4 71683.3 587328.0 584592.5 1652572.0  1638667.7  4864.0 3027.2 512.0  287.0      14    1.836   7      0.029    1.865
73408.0 73408.0 71682.0 71683.3 587328.0 584592.5 1836964.0  1833228.0  4864.0 3027.2 512.0  287.0      14    1.836   7      0.029    1.865
73408.0 73408.0 71682.3  0.0   587328.0   0.0    1970136.0  1966351.2  4864.0 3027.2 512.0  287.0      14   22.270   8      0.029   22.299
73408.0 73408.0  0.0     0.0   587328.0 71682.3  1970136.0  1966351.3  4864.0 3027.2 512.0  287.0      14   22.270   8      0.589   22.859

其他说明

  • 以下现象未复现
    • 由于该现象的条件比较苛刻，不容易复现
    • 复现要求：JVM如果花了98%的时间进行垃圾回收，而只得到2%可用的内存，频繁的进行内存回收(最起码已经进行了5次连续的垃圾回收) 超出GC开销限制
java.lang.OutOfMemoryError: GC overhead limit exceeded
进程物理内存远大于Xmx的问题分析，导致堆未满，但OOME
jybzjf的专栏
02-17 1420
进程物理内存远大于Xmx的问题分析 转自：http://lovestblog.cn/blog/2015/08/21/rssxmx/ 问题描述 最近经常被问到一个问题，”为什么我们系统进程占用的物理内存(Res/Rss)会远远大于设置的Xmx值”，比如Xmx设置1.7G，但是top看到的Res的值却达到了3.0G，随着进程的运行，Res的值还在递增，直到达到某个值，被OS当做bad pro...
JVM-内存管理
「 虚幻私塾」
02-25 1317
Python微信订餐小程序课程视频 https://edu.csdn.net/course/detail/36074 Python实战量化交易理财系统 https://edu.csdn.net/course/detail/35475 JVM内存管理 在之前，我们了解了JVM的大致运作原理以及相关特性，这一章，我们首先会从内存管理说起。 在传统的C/C++开发中，我们经常通过使用申请内存的方式来创建对象或是存放某些数据，但是这样也带来了一些额外的问题，我们要在何时释放这些内存，怎么才能使得内存的使用最高效，因
Linux与JVM的内存关系分析
张伟的专栏
05-05 857
引言 在一些物理内存为8g的服务器上，主要运行一个Java服务，系统内存分配如下：Java服务的JVM堆大小设置为6g，一个监控进程占用大约 600m，Linux自身使用大约800m。从表面上，物理内存应该是足够使用的；但实际运行的情况是，会发生大量使用SWAP(说明物理内存不够使用 了)，如下图所示。同时，由于SWAP和GC同时发生会致使JVM严重卡顿，所以我们要追问：内存究竟去哪儿了？
进程物理内存远大于Xmx的问题分析
weixin_34232617的博客
11-15 793
问题描述 最近经常被问到一个问题，”为什么我们系统进程占用的物理内存(Res/Rss)会远远大于设置的Xmx值”，比如Xmx设置1.7G，但是top看到的Res的值却达到了3.0G，随着进程的运行，Res的值还在递增，直到达到某个值，被OS当做bad process直接被kill掉了。 1 2 3 4 5 6 7 top - 16:57:47 up...
谈JVM xmx, xms等内存相关参数合理性设置
最新发布
京东科技开发者
10-10 869
作者：京东零售 刘乐说到JVM垃圾回收算法的两个优化标的：吞吐量和停顿时长，并提到这两个优化目标是有冲突的。那么有没有可能提高吞吐量而不影响停顿时长，甚至缩短停顿时长呢？答案是有可能的，提高内存占用（Memory Footprint）就有可能同时优化这两个标的，这篇文章就来聊聊内存相关内容。内存占用一般指应用运行需要的所有内存，包括堆内内存（On-heap Memory)和堆外内存（Off-heap Memory）
JVM
m0_46269902的博客
07-31 260
触发Full gc条件 从年轻代空间（包括Eden和 Survivor 区域）回收内存被称为 Minor GC，对老年代GC称为Major GC,而Full GC是对整个堆来说的，出现Full GC的时候经常伴随至少一次的Minor GC,但非绝对的。Major GC的速度一般会比Minor GC慢10倍以上。 1、System.gc()方法的调用 此方法的调用是建议JVM进行Full GC,虽然只是建议而非一定,但很多情况下它会触发 Full GC,从而增加Full GC的频率,也即增加了间歇性停顿的次数
为什么虚拟机占用的实际内存超出了 -xmx 设置的最大值
louhaiyun的专栏
07-18 3066
JBoss服务器，启动参数中设置了最大堆内存为3072M，运行一段时间后在系统任务管理器看到相应的java.exe进程占用了5G内存
JVM内存限制(最大值)
zhangmengjlu的专栏
08-05 995
目前在跑一个数据量加大的程序，在32位win7下的eclipse中，-Xmx开到了1500m后，再增加就无法启动了，找了下说法如下： JVM内存限制(最大值) 首先JVM内存限制于实际的最大物理内存，假设物理内存无限大的话，JVM内存的最大值跟操作系统有很大的关系。简单的说就32位处理器虽然可控内存空间有4GB,但是具体的操作系统会给一个限制，这个限制一般是2GB-3GB（一般来说Wi
JVM-java虚拟机
m0_60875109的博客
07-14 420
jvm内存结构，内存模型，垃圾回收算法，垃圾回收器
一个导致JVM物理内存消耗大的Bug
HeapDump性能社区的博客
05-22 1905
本文来自: PerfMa技术社区 PerfMa(笨马网络)官网 概述 最近我们公司在帮一个客户查一个JVM的问题(JDK1.8.0_191-b12)，发现一个系统老是被OS Kill掉，是内存泄露导致的。在查的过程中，阴差阳错地发现了JVM另外的一个Bug。这个Bug可能会导致大量物理内存被使用，我们已经反馈给了社区，并得到快速反馈，预计在OpenJDK8最新版中发布(JDK11中也存在这个问题)。 PS：用户的那个问题最终也解决了，定位下来算是C2的一个设计缺陷导致大量内存被使用，安全性上没有得到保.
一个大量消耗JVM物理内存的Bug
weixin_48509270的博客
06-12 449
概述 最近我们公司在帮一个客户查一个JVM的问题(JDK1.8.0_191-b12)，发现一个系统老是被OS Kill掉，是内存泄露导致的。在查的过程中，阴差阳错地发现了JVM另外的一个Bug。这个Bug可能会导致大量物理内存被使用，我们已经反馈给了社区，并得到快速反馈，预计在OpenJDK8最新版中发布(JDK11中也存在这个问题)。 PS：用户的那个问题最终也解决了，定位下来算是C2的一个设计缺陷导致大量内存被使用，安全性上没有得到保障。 找出消耗大内存的线程 接下来主要分享下这个BUG的发现过程，先
Java占Linux超过xms,Linux下Java项目占用内存问题的分析
weixin_39613951的博客
05-13 599
这两天发现一个问题，即自动化测试平台所在的服务器内存突然就爆了。从现象上看，服务器上执行命令行pandning，日志回吐卡顿，机器卡死......个人感觉这个问题比较蹊跷也很隐蔽，从原则上，讲为了不要眉毛胡子一把抓导致下错定义，故而花了些时间仔细研究了一下。“内存一直占满”首先，可以通过free 或者 free -b -s2查看一个Linux内存使用情况，如下图： 内存使用样例图当发现内存使用率这...
JVM中的内存关系
qq_22474115的博客
12-31 1265
Java会从系统内存（CPU Regisers、CPU Cache Memory、RAM Main Memory）中申请大块的堆内存、和栈区（虚拟机、本地方法栈、程序计数器），申请的这部分称为工作内存，是经过虚拟化了的，称为虚拟机内存。剩下的内存统一称为堆外内存。 堆外内存又称本地内存，本地内存中有部分可以借助工具（JNI 或者 JNA）直接访问，这部分内存称为直接内存，本地内存中的还有一部分内存划给了元空间（方法区），但是这部分内存不受XX:MaxDire...
java bookkeeping_为什么java应用运行时，实际占用内存大于Xmx设置的值
weixin_32314595的博客
02-16 573
Some of you have been there. You have added-Xmxoption to your startup scripts and sat back relaxed knowing that there is no way your Java process is going to eat up more memory than your fine-tuned ...
JVM实际内存占用超过Xmx的原因,设置Xmx的技巧
DRAGON的博客
02-27 1974
jvm 参数设置
jvm学习笔记--基本结构
yangdingcai的专栏
09-04 576
主要来学习jvm的基本结构 知识点1：什么是java虚拟机（你以为你知道，如果你看我下面的例子，你会发现你其实不知道） 第一步：先来写一个类： [code="java"] package test; public class JVMTestForJava { public static void main(String[] args) thro...
Spring Boot引起的“堆外内存泄漏”排查及经验总结
weixin_30274627的博客
06-28 498
背景为了更好地实现对项目的管理，我们将组内一个项目迁移到MDP框架（基于Spring Boot），随后我们就发现系统会频繁报出Swap区域使用量过高的异常。笔者被叫去帮忙查看原因，发现配置了4G堆内内存，但是实际使用的物理内存竟然高达7G，确实不正常。JVM参数配置是“-XX:MetaspaceSize=256M -XX:MaxMetaspaceSize=256M -XX:+AlwaysPreTo...
超出物理内存:机制
binbigdata的博客
04-07 660
到目前为止，我们假定地址空间是不实际的小的，并且适合于物理内存。事实上，我们一直假设每个运行过程的每个地址空间都适合内存。现在，我们将放松这些大的假设，并假设我们希望支持许多并发运行的大型地址空间。为此，我们需要在内存层次结构中增加一个级别。到目前为止，我们假定所有页面都驻留在物理内存中。但是，为了支持大的地址空间，操作系统需要一个地方来存储当前不太需要的地址空间的部分。一般来说，这样一个位置的特...
jvm调优技巧 - 内存抖动 、Xms和Xmx参数为什么要设置相同的值
叶新东老师的博客
07-24 6866
前言 在网上看到大部分的帖子都有介绍性能调优的案例，其中有一项就是告诉你 Xms 和 Xmx 参数一定要设置成相同的，这样就可以达到优化的目的，就像这样 -Xms1024m -Xmx1024m 但是却没说为什么要这么设置，那么这篇文章就是来告诉你这样设置的目的。底层做了哪些事情。 jvm性能调优的最基本条件     首先我们要知道，垃圾回收器（GC）在回收内存空间时候，所有的工作线程都会暂停，待回收工作完成后，工作线程才会继续运行。如果GC太频繁，工作线程的效率和响
jvm -Xms -Xmx -XX:PermSize -XX:MaxPermSize 设置比例
05-13
JVM 中的 -Xms 和 -Xmx 分别用于设置 JVM 的初始堆大小和最大堆大小。而 -XX:PermSize 和 -XX:MaxPermSize 则用于设置永久代（Permanent Generation）的初始大小和最大大小。 这些参数的设置比例应该根据具体的应用场景和服务器硬件配置来进行调整。一般来说，初始堆大小和最大堆大小应该设置为相同的值，以避免 JVM 运行时动态扩容带来的性能损失。而永久代的大小则可以根据应用程序中类和方法的数量来进行调整。 例如，如果应用程序中类和方法数量较多，可以适当增大永久代的大小，以避免出现 PermGen Space 的异常。一般来说，永久代的大小应该占用堆大小的 20% 左右。因此，可以根据实际情况设置如下参数： -Xms4g -Xmx4g -XX:PermSize=512m -XX:MaxPermSize=512m 这个设置表示 JVM 的初始堆大小和最大堆大小都为 4GB，而永久代的初始大小和最大大小都为 512MB。这个比例适用于一般的服务器硬件配置和中等规模的 Java 应用程序。但是需要注意，这个比例并不适用于所有的应用场景，需要根据具体情况进行调整。
评论 1
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值