为什么JVM指定-Xmx参数后占用内存会变少?

“嘿,你能顺便过来看看这个奇怪的事情吗?” 就是让我提供支持的这个事情,驱使我写下这篇博客的。这个特殊的问题是,不同工具给出的可用内存的报告是不一样的。

简而言之,工程师正在调查特定应用程序的内存使用。根据以往的经验,他给这个应用指定了2G堆内存。但是不知道什么原因,JVM工具似乎不能确定这个程序到底有多少内存。例如 jconsole 探测可用堆总共为1963M,但 jvisualvm 报告称堆为2048M。到底哪一个是正确的呢?为什么另一个给出了不一样的信息呢?

这的确很不可思议,特别是以往的认知被突然改变。表面上JVM没有耍任何花招:

  • -Xmx 和 -Xms 是相等的,这就使得报告的数字不会随着堆实时增加。
  • JVM避免通过内存的自适应策略(-XX:-UseAdaptiveSizePolicy)动态改变内存池的大小。

重现不同

搞懂这个问题的第一步是深入这些工具的实现方式。一般通过标准API查看可用内存会像下面这样:

System.out.println("Runtime.getRuntime().maxMemory()="+Runtime.getRuntime().maxMemory());

的确,这好像是工具首先会被用到的方式。寻找答案的第一步是找出可复现的测试用例。为了这个目的,我写了下面这段代码:

package eu.plumbr.test;
//imports skipped for brevity

public class HeapSizeDifferences {

  static Collection<Object> objects = new ArrayList<Object>();
  static long lastMaxMemory = 0;

  public static void main(String[] args) {
    try {
      List<String> inputArguments = ManagementFactory.getRuntimeMXBean().getInputArguments();
      System.out.println("Running with: " + inputArguments);
      while (true) {
        printMaxMemory();
        consumeSpace();
      }
    } catch (OutOfMemoryError e) {
      freeSpace();
      printMaxMemory();
    }
  }

  static void printMaxMemory() {
    long currentMaxMemory = Runtime.getRuntime().maxMemory();
    if (currentMaxMemory != lastMaxMemory) {
      lastMaxMemory = currentMaxMemory;
      System.out.format("Runtime.getRuntime().maxMemory(): %,dK.%n", currentMaxMemory / 1024);
    }
  }

  static void consumeSpace() {
    objects.add(new int[1_000_000]);
  }

  static void freeSpace() {
    objects.clear();
  }
}

这段代码通过在一个 new int[1000000] 的循环中分配内存块,检测当前在实时JVM中的可用内存。无论何时,只要最后知道的内存大小改变时,都会通过打印出 ofRuntime.getRuntime().maxMemory()__ 报告出来,类似于如下这样:

Running with: [-Xms2048M, -Xmx2048M]
Runtime.getRuntime().maxMemory(): 2,010,112K.

结果确实如此——有时甚至指定JVM有2G可用堆,但是运行着莫名其妙地发现其中的85M找不到了。你可以通过运用 2,010,112K 除以 1024 转化Runtime.getRuntime().maxMemory() 的输出到MB来复查我的计算。实际结果等于1963M,比起实际的 2048M 少了 85M。

寻求根本原因

重现这个现象之后,我做了如下的笔记——采用不同的GC算法运行似乎也产生不同的结果:

GC algorithm Runtime.getRuntime().maxMemory()
-XX:+UseSerialGC 2,027,264K
-XX:+UseParallelGC 2,010,112K
-XX:+UseConcMarkSweepGC 2,063,104K
-XX:+UseG1GC 2,097,152K

除了G1消费了我实际给的2G之外,任何其它GC算法似乎始终会半随机地丢失一部分内存。

现在是时候剖析一下JVM的源代码了,在 CollectedHeap 的源代码中,我发现了下面这些:

//对java.lang.Runtime.maxMemory()的支持:
//返回虚拟机提供给“标准”java对象的最大内存。
//这个基于保留的地址空间,但是不应该包括虚拟机使用内部统计或临时存储的这部分空间。
//(例如:在青年代中,残留空间之一)
virtual size_t max_capacity() const = 0;

不得不承认答案隐藏得很深。但真相还是在好奇心的驱使下找到——事实上,某些情况下残留空间其中一些可能被排除在内存计算之外

从这里开始就一帆风顺了。打开GC日志发现,确实在设置2G内存时,Parallel和CMS算法都会在不同程度上,设置残留的空间是可变的。例如,以Parallel算法为例GC的日志演示如下所示:

Running with: [-Xms2g, -Xmx2g, -XX:+UseParallelGC, -XX:+PrintGCDetails]
Runtime.getRuntime().maxMemory(): 2,010,112K.

... rest of the GC log skipped for brevity ...

 PSYoungGen      total 611840K, used 524800K [0x0000000795580000, 0x00000007c0000000, 0x00000007c0000000)
  eden space 524800K, 100% used [0x0000000795580000,0x00000007b5600000,0x00000007b5600000)
  from space 87040K, 0% used [0x00000007bab00000,0x00000007bab00000,0x00000007c0000000)
  to   space 87040K, 0% used [0x00000007b5600000,0x00000007b5600000,0x00000007bab00000)
 ParOldGen       total 1398272K, used 1394966K [0x0000000740000000, 0x0000000795580000, 0x0000000795580000)

从上面你可以看到,Eden空间被设置为了524800K,残留空间都被设为了 87040K,Old空间大小为 1398272K。把Eden、Old和残留空间之一加在一起等于2010112K,确认丢失的 85 或 87040K 确实是保留的残留空间

总结

读完这篇文章后,相信你现在已经准备好以一种新的视角深入到Java API的实现细节。下次遇到可视化工具的总可用堆大小略低于Xmx规定的大小时,你就知道少的那部分等于你一个残留空间的大小。

不得不承认的一个事实是,在日常的编程中不是特别有用,但是这不是我写这篇文章的初衷。相反地,写这篇文章目的是为了强调我在优秀工程师身上看到的特质——好奇心。优秀的工程师总是想去知道,那些东西的工作方式并探究为什么它们会像那样工作。有时候答案藏匿地很深,但仍然建议你去试图寻求答案。最终,在这个过程中获取的知识,将会让你受益无穷。

原文链接: javacodegeeks 翻译: ImportNew.com - 张 健
译文链接: http://www.importnew.com/15934.html
[ 转载请保留原文出处、译者和译文链接。]

关于作者: 张 健

(新浪微博:@jasper你咋了

查看张 健的更多文章 >>



相关文章

发表评论

Comment form

(*) 表示必填项

4 条评论

  1. Finneen Chiong 说道:

    看懂了,很不错!

    Thumb up 0 Thumb down 0

  2. Finneen Chiong 说道:

    不过这不能算作保留的内存空间,from 和 to这两块空间都应回归为young space。所以说youngspace = (from+to)+eden,只不过from(幸存者1区) 和 to(幸存者2区)大小配额相等,年轻代内存回收时这两个区域总会发生旋转,其中一个区域存活的对象会拷贝到另一个区域。

    这样说来原文的作者理解是有误的,不过翻译的还不错。

    Thumb up 1 Thumb down 0

    • secret32 说道:

      原文the remaining Survivor space 翻译成 保留的残留空间,我觉得这反而是翻译造成的误解

      Thumb up 1 Thumb down 0

  3. 杨峰at杭州 说道:

    PSYoungGen total 611840K
    ParOldGen total 1398272K
    Runtime.getRuntime().maxMemory(): 2,010,112K.

    这有啥问题啊

    Thumb up 0 Thumb down 0

跳到底部
返回顶部