【为何个人JVM能实际使用的内存比-Xmx指定的少？】

做者：Nikita Salnikov-Tarnovski   译者：Amanda    校对：

“你好，你能过来看看帮我解决一个奇怪的问题么。”就是这个技术支持案例使我想起写下这篇帖子。眼前的这个问题就是关于不一样工具对于可用内存大小检测的差别。

其实就是一个工程师在调查一个应用程序的太高的内存使用状况时发现，尽管该程序已经被指定分配2G堆内存，可是JVM检测工具彷佛并不能肯定进程实际能用多少内存。例如jconsole显示可用堆内存为1,963M，然而jvisualvm 却显示能用2,048M。因此到底哪一个工具才是对的，为何检测结果会出现差别呢？

这确实是个挺奇怪的问题，特别是当最常出现的几种解释理由都被排除后，看来JVM并无耍一些明显的小花招：

• -Xmx和-Xms是相等的，所以检测结果并不会由于堆内存增长而在运行时有所变化。

• 经过关闭自适应调整策略(-XX:-UseAdaptiveSizePolicy)，JVM已经事先被禁止动态调整内存池的大小。
  

重现差别检测结果

要弄清楚这个问题的第一步就是要明白这些工具的实现原理。经过标准APIs,咱们能够用如下简单语句获得可以使用的内存信息。

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

复制代码

并且确实，现有检测工具底层也是用这个语句来进行检测。要解决这个问题，首先咱们须要一个可重复使用的测试用例。所以，我写了下面这段代码：

1. package eu.plumbr.test;
   

2. //imports skipped for brevity
   

3. 
   

4. public class HeapSizeDifferences {
   

5. 
   

6.   static Collection objects = new ArrayList();
   

7.   static long lastMaxMemory = 0;
   

8. 
   

9.   public static void main(String[] args) {
   

10.     try {
    

11.       List inputArguments = ManagementFactory.getRuntimeMXBean().getInputArguments();
    

12.       System.out.println("Running with: " + inputArguments);
    

13.       while (true) {
    

14.         printMaxMemory();
    

15.         consumeSpace();
    

16.       }
    

17.     } catch (OutOfMemoryError e) {
    

18.       freeSpace();
    

19.       printMaxMemory();
    

20.     }
    

21.   }
    

22. 
    

23.   static void printMaxMemory() {
    

24.     long currentMaxMemory = Runtime.getRuntime().maxMemory();
    

25.     if (currentMaxMemory != lastMaxMemory) {
    

26.       lastMaxMemory = currentMaxMemory;
    

27.       System.out.format("Runtime.getRuntime().maxMemory(): %,dK.%n", currentMaxMemory / 1024);
    

28.     }
    

29.   }
    

30. 
    

31.   static void consumeSpace() {
    

32.     objects.add(new int[1_000_000]);
    

33.   }
    

34. 
    

35.   static void freeSpace() {
    

36.     objects.clear();
    

37.   }
    

38. }

复制代码

这段代码经过将new int[1_000_000]置于一个循环中来不断分配内存给程序，而后监测JVM运行期的当前可用内存。当程序监测到可用内存大小发生变化时，经过打印出Runtime.getRuntime().maxMemory()返回值来获得当前可用内存尺寸，输出相似下面语句：

1. Running with: [-Xms2048M, -Xmx2048M]
   

2.   Runtime.getRuntime().maxMemory(): 2,010,112K.

复制代码

实际状况也确实如预估的那样，尽管我已经给JVM预先指定分配了2G对内存，在不知道为何在运行期有85M内存不见了。你大能够把 Runtime.getRuntime().maxMemory()的返回值2,010,112K 除以1024来转换成MB，那样你将获得1,963M，正好和2048M差85M。

找到根本缘由

在成功重现了这个问题以后，我尝试用使用不一样的GC算法，果真检测结果也不尽相同。

1. GC algorithm
   

2. 
   

3. Runtime.getRuntime().maxMemory()
   

4. 
   

5. -XX:+UseSerialGC
   

6. 
   

7. 2,027,264K
   

8. 
   

9. -XX:+UseParallelGC
   

10. 
    

11. 2,010,112K
    

12. 
    

13. -XX:+UseConcMarkSweepGC
    

14. 
    

15. 2,063,104K
    

16. 
    

17. -XX:+UseG1GC
    

18. 
    

19. 2,097,152K

复制代码

除了G1算法恰好完整使用了我预指定分配的2G以外，其他每种GC算法彷佛都不一样程度地丢失了一些内存。

如今咱们就该看看在JVM的源代码中有没有关于这个问题的解释了。我在CollectedHeap这个类的源代码中找到了以下的解释：

1.   Running with: [-Xms2048M, -Xmx2048M]
   

2.   // Support for java.lang.Runtime.maxMemory():  return the maximum amount of
   

3.   // memory that the vm could make available for storing 'normal' java objects.
   

4.   // This is based on the reserved address space, but should not include space
   

5.   // that the vm uses internally for bookkeeping or temporary storage
   

6.   // (e.g., in the case of the young gen, one of the survivor
   

7.   // spaces).
   

8.   virtual size_t max_capacity() const = 0;

复制代码

我不得不说这个答案藏得有点深，可是只要你有足够的好奇心，仍是不难发现的：有时候，有一块Survivor区是不被计算到可用内存中的。 

明白这一点以后问题就好解决了。打开并查看GC logging 信息以后咱们发现，在Serial，Parallel以及CMS算法回收过程当中丢失的那些内存，尺寸恰好等于JVM从2G堆内存中划分给Survivor区内存的尺寸。例如，在上面的ParallelGC算法运行时，GC logging信息以下：

1. Running with: [-Xms2g, -Xmx2g, -XX:+UseParallelGC, -XX:+PrintGCDetails]
   

2. Runtime.getRuntime().maxMemory(): 2,010,112K.
   

3. 
   

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

5. 
   

6. PSYoungGen      total 611840K, used 524800K [0x0000000795580000, 0x00000007c0000000, 0x00000007c0000000)
   

7.   eden space 524800K, 100% used [0x0000000795580000,0x00000007b5600000,0x00000007b5600000)
   

8.   from space 87040K, 0% used [0x00000007bab00000,0x00000007bab00000,0x00000007c0000000)
   

9.   to   space 87040K, 0% used [0x00000007b5600000,0x00000007b5600000,0x00000007bab00000)
   

10. ParOldGen       total 1398272K, used 1394966K [0x0000000740000000, 0x0000000795580000, 0x0000000795580000)

复制代码

由上面的信息能够看出，Eden区被分配了524,800K，两个Survivor区都被分配到了87,040K，老年代（Old space）则被分配了1,398,272K。把Eden区、老年代以及一个Survivor区的尺寸求和，恰好等于2,010,112K，说明丢失的那85M（87,040K）确实就是剩下的那个Survivor区。

总结

读完这篇帖子的你如今应该对如何探索Java API的实现原理有了一些新的想法。下次当你用某个可视化工具查看可用堆内存发现所得的结果略少于-Xmx指定分配的大小时，你就知道这二者之间的差值是一块Survivor区的大小。

我必须认可这个知识点在平常编程中并非特别经常使用，但这并非这篇帖子的重点。我写下这篇帖子是为了描述一种特质，一种我常常在优秀的程序员身上寻找的特质-好奇心。好的程序员们会常常试着去了解一些事物工做的机理以及缘由。有时问题的答案并不会那么显而易见，可是但愿你能坚持寻找下去，最终在寻找过程当中的所累积的知识总会让你获益匪浅。

原创文章，转载请注明： 转载自ifeve.com