public static void showMemory() {
System.out.println("Memory used: "
+ (Runtime.getRuntime().totalMemory() - Runtime.getRuntime().freeMemory()) / (1024.D * 1024.D) + "mB.");
}
上述代码分别显示2Mb,1029Mb和2Mb. – >这一切似乎都很正常.
但是,在查看TaskManager时,Java的RAM使用率最初为2mb,然后转到1052Mb并保持不变,即使该代码段显示为2Mb.
由于我希望Java使用最少的资源,我该如何解决这个问题？
编辑：
我做了一些研究并找出了要使用的术语.实际上,本机内存与堆内存的值不相似,并且通常大于堆内存.有没有办法减少使用的本机内存,使其接近堆内存？
解决方法
使用垃圾优先(G1)GC(Java 9中的默认GC),与ParallelOldGC相比,这个垃圾收集器还缩小了堆大小(最终,它还会缩小garabage集合中使用的整体“本机内存”)( Java 7和Java 8中的默认GC,很少永远不会缩小堆大小！
通常：
你的基本假设是错误的.
您假设代码段显示堆大小.这是不正确的.它显示了堆利用率.这意味着“我的堆使用了多少空间？”. Runtime.getRuntime().totalMemory()显示堆大小Runtime.getRuntime().freeMemory()显示空闲堆大小,它们的差异显示堆利用率(使用的大小).
您的堆以初始大小开始,利用0字节,因为尚未创建任何对象,以及最大堆大小.最大堆大小描述允许垃圾收集器调整堆大小的大小(例如,如果没有足够的空间用于非常大的对象)
在创建空堆之后的下一步,自动加载一些对象(类对象等),它们通常应该很容易适合初始堆大小.
然后,您的代码开始运行并分配对象.只要您的伊甸园空间没有更多空间(堆被分成年轻一代(伊甸园,幸存者和幸存者 – 太空)和老一代,如果您对这些细节感兴趣,请查找其他资源),触发垃圾收集.
在垃圾收集期间,垃圾收集器可能决定调整堆的大小(如上所述,在讨论最大堆大小时).在您的情况下会发生这种情况,因为您的初始堆大小太小而不适合您的1GB对象.因此,堆大小会增加,介于初始堆大小和最大堆大小之间.
然后,在你的大对象死亡之后,下一个GC可以使堆再次变小,但它没有必要.为什么？它低于最大堆大小,这是GC所关心的.一些垃圾收集算法再次缩小堆,有些则没有.
特别是ParallelOldGC,Java 7和Java 8中的默认GC,很少会永远不会缩小堆.
如果您希望GC在垃圾收集期间通过缩小堆来尝试保持较小的堆大小,请通过设置-XX：UseG1GC Java标记来尝试首先使用garabage(G1)GC.
例：
这将以字节打印出所有值.
您将获得概述,两个GC如何工作以及使用其中任何一个时使用的空间.
System.out.println(String.format("Init:\t%,d",ManagementFactory.getMemoryMXBean().getHeapMemoryUsage().getInit()));
System.out.println(String.format("Max:\t%,d%n",ManagementFactory.getMemoryMXBean().getHeapMemoryUsage().getMax()));
Thread outputThread = new Thread(() -> {
try {
int i = 0;
for(;;) {
System.out.println(String.format("%dms\t->\tUsed:\t\t%,i,ManagementFactory.getMemoryMXBean().getHeapMemoryUsage().getUsed()));
System.out.println(String.format("%dms\t->\tCommited:\t%,ManagementFactory.getMemoryMXBean().getHeapMemoryUsage().getCommitted()));
Thread.sleep(100);
i += 100;
}
} catch (Exception e) { }
});
Thread allocThread = new Thread(() -> {
try {
int val = 0;
Thread.sleep(500); // Wait 1/2 second
createArray();
Thread.sleep(500); // Wait another 1/2 seconds
System.gc(); // Force a GC,array should be cleaned
return;
} catch (Exception e) { }
});
outputThread.start();
allocThread.start();
createArray()只是以下小方法：
private static void createArray() {
byte[] arr = new byte[1024 * 1024 * 1024];
}
–Result ParallelOldGC：
Init: 262,144,000 Max: 3,715,629,056 0ms -> Used: 6,606,272 0ms -> Commited: 251,658,240 100ms -> Used: 6,272 100ms -> Commited: 251,240 200ms -> Used: 6,272 200ms -> Commited: 251,240 300ms -> Used: 6,272 300ms -> Commited: 251,240 400ms -> Used: 6,272 400ms -> Commited: 251,240 500ms -> Used: 1,080,348,112 500ms -> Commited: 1,325,924,352 600ms -> Used: 1,112 600ms -> Commited: 1,352 700ms -> Used: 1,112 700ms -> Commited: 1,352 800ms -> Used: 1,112 800ms -> Commited: 1,352 900ms -> Used: 1,112 900ms -> Commited: 1,352 1000ms -> Used: 1,112 1000ms -> Commited: 1,352 1100ms -> Used: 1,112 1100ms -> Commited: 1,352 1200ms -> Used: 2,261,768 1200ms -> Commited: 1,352 1300ms -> Used: 2,768 1300ms -> Commited: 1,352
你可以看到,我的堆的初始大小约为260MB,允许的最大大小(GC可能决定调整大小的大小)大约为3.7 GB.
在创建阵列之前,使用了大约6MB的堆.然后创建大数组,我的堆大小(提交大小)增加到1,3GB,使用大约1GB(数组).然后我强制收集数组的垃圾收集.然而,我的堆大小保持在1,因为GC不关心再次收缩,只是利用率下降到2MB.
– 结果G1：
Init: 262,000 Max: 4,179,623,936 0ms -> Used: 2,097,152 0ms -> Commited: 262,000 100ms -> Used: 2,152 100ms -> Commited: 262,000 200ms -> Used: 2,152 200ms -> Commited: 262,000 300ms -> Used: 2,152 300ms -> Commited: 262,000 400ms -> Used: 2,152 400ms -> Commited: 262,000 500ms -> Used: 1,074,364,464 500ms -> Commited: 1,336,934,400 600ms -> Used: 1,464 600ms -> Commited: 1,400 700ms -> Used: 1,464 700ms -> Commited: 1,400 800ms -> Used: 1,464 800ms -> Commited: 1,400 900ms -> Used: 1,464 900ms -> Commited: 1,400 1000ms -> Used: 492,520 1000ms -> Commited: 8,388,608 1100ms -> Used: 492,520 1100ms -> Commited: 8,608 1200ms -> Used: 492,520 1200ms -> Commited: 8,608
现在我们开始！ G1 GC关心小堆！清理对象后,不仅利用率降至约0.5MB,而且堆大小也缩小到8MB(与ParallelOldGC中的1,3GB相比)
更多信息：
但是,请记住,堆大小仍将与任务管理器中显示的不同.从Wikipedia – Java virtual machine开始的following image说明堆只是完整JVM内存的一部分：
