福州制作网站企业,收费网站怎么做,云开发数据库,长春哪家做网站便宜这确实是个挺奇怪的问题#xff0c;特别是当最常出现的几种解释理由都被排除后#xff0c;看来JVM并没有耍一些明显的小花招#xff1a;-Xmx和-Xms是相等的#xff0c;因此检测结果并不会因为堆内存增加而在运行时有所变化。通过关闭自适应调整策略(-XX:-UseAdaptiveSizePo…这确实是个挺奇怪的问题特别是当最常出现的几种解释理由都被排除后看来JVM并没有耍一些明显的小花招-Xmx和-Xms是相等的因此检测结果并不会因为堆内存增加而在运行时有所变化。通过关闭自适应调整策略(-XX:-UseAdaptiveSizePolicy)JVM已经事先被禁止动态调整内存池的大小。重现差异检测结果要弄清楚这个问题的第一步就是要明白这些工具的实现原理。通过标准APIs,我们可以用以下简单语句得到可使用的内存信息。System.out.println(Runtime.getRuntime().maxMemory()Runtime.getRuntime().maxMemory());而且确实现有检测工具底层也是用这个语句来进行检测。要解决这个问题首先我们需要一个可重复使用的测试用例。因此我写了下面这段代码package eu.plumbr.test;//imports skipped for brevitypublic 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算法果然检测结果也不尽相同。除了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 信息之后我们发现在SerialParallel以及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区的大小。私信回复 资料 领取一线大厂Java面试题总结阿里巴巴泰山手册各知识点学习思维导一份300页pdf文档的Java核心知识点总结这些资料的内容都是面试时面试官必问的知识点篇章包括了很多知识点其中包括了有基础知识、Java集合、JVM、多线程并发、spring原理、微服务、Netty 与RPC 、Kafka、日记、设计模式、Java算法、数据库、Zookeeper、分布式缓存、数据结构等等。我必须承认这个知识点在日常编程中并不是特别常用但这并不是这篇帖子的重点。我写下这篇帖子是为了描述一种特质一种我经常在优秀的程序员身上寻找的特质-好奇心。好的程序员们会经常试着去了解一些事物工作的机理以及原因。有时问题的答案并不会那么显而易见但是希望你能坚持寻找下去最终在寻找过程中的所累积的知识总会让你获益匪浅。
