“ 你好，你能过来看看帮我解决一个奇怪的问题么。 ”就是这个技术支持案例使我想起写下这篇帖子。眼前的这个问题就是关于不同工具对于可用内存大小检测的差异。
其实就是一个工程师在调查一个应用程序的过高的内存使用情况时发现，尽管该程序已经被指定分配2G堆内存，但是JVM检测工具似乎并不能确定进程实际能用多少内存。例如jconsole显示可用堆内存为1,963M，然而jvisualvm却显示能用2,048M。所以到底哪个工具才是对的，为什么检测结果会出现差异呢？
这确实是个挺奇怪的问题，特别是当最常出现的几种解释理由都被排除后，看来JVM并没有耍一些明显的小花招：
- -Xmx和*-Xms*是相等的，因此检测结果并不会因为堆内存增加而在运行时有所变化。
- 通过关闭自适应调整策略( -XX:-UseAdaptiveSizePolicy )，JVM已经事先被禁止动态调整内存池的大小。
重现差异检测结果
要弄清楚这个问题的第一步就是要明白这些工具的实现原理。通过标准APIs,我们可以用以下简单语句得到可使用的内存信息。
System.out.println("Runtime.getRuntime().maxMemory()="+Runtime.getRuntime().maxMemory());
而且确实，现有检测工具底层也是用这个语句来进行检测。要解决这个问题，首先我们需要一个可重复使用的测试用例。因此，我写了下面这段代码：
package eu.plumbr.test;
//imports skipped for brevity
public class HeapSizeDifferences {
static Collection objects = new ArrayList();
static long lastMaxMemory = 0;
public static void main(String[] args) {
try {
List 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[1_000_000] 置于一个循环中来不断分配内存给程序，然后监测JVM运行期的当前可用内存。当程序监测到可用内存大小发生变化时，通过打印出 Runtime.getRuntime().maxMemory() 返回值来得到当前可用内存尺寸，输出类似下面语句：
Running with: [-Xms2048M, -Xmx2048M]
Runtime.getRuntime().maxMemory(): 2,010,112K.
实际情况也确实如预估的那样， 尽管我已经给JVM预先指定分配了2G对内存，在不知道为什么在运行期有85M内存不见了。 你大可以把 Runtime.getRuntime().maxMemory() 的返回值2,010,112K 除以1024来转换成MB，那样你将得到1,963M，正好和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这个类的源代码中找到了如下的解释：
Running with: [-Xms2048M, -Xmx2048M]
// Support for java.lang.Runtime.maxMemory(): return the maximum amount of
// memory that the vm could make available for storing 'normal' java objects.
// This is based on the reserved address space, but should not include space
// that the vm uses internally for bookkeeping or temporary storage
// (e.g., in the case of the young gen, one of the survivor
// spaces).
virtual size_t max_capacity() const = 0;
我不得不说这个答案藏得有点深，但是只要你有足够的好奇心，还是不难发现的：有时候，有一块Survivor区是不被计算到可用内存中的。
明白这一点之后问题就好解决了。打开并查看GC logging 信息之后我们发现，在Serial，Parallel以及CMS算法回收过程中丢失的那些内存，尺寸刚好等于JVM从2G堆内存中划分给Survivor区内存的尺寸。例如，在上面的ParallelGC算法运行时，GC logging信息如下：
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区被分配了524,800K，两个Survivor区都被分配到了87,040K，老年代（Old space）则被分配了1,398,272K。把Eden区、老年代以及一个Survivor区的尺寸求和，刚好等于2,010,112K，说明丢失的那85M（87,040K）确实就是剩下的那个Survivor区。
总结
读完这篇帖子的你现在应该对如何探索Java API的实现原理有了一些新的想法。下次当你用某个可视化工具查看可用堆内存发现所得的结果略少于-Xmx指定分配的大小时，你就知道这两者之间的差值是一块Survivor区的大小。
我必须承认这个知识点在日常编程中并不是特别常用，但这并不是这篇帖子的重点。我写下这篇帖子是为了描述一种特质，一种我经常在优秀的程序员身上寻找的特质- 好奇心 。好的程序员们会经常试着去了解一些事物工作的机理以及原因。有时问题的答案并不会那么显而易见，但是希望你能坚持寻找下去，最终在寻找过程中的所累积的知识总会让你获益匪浅。
