建设厅网站贵州人事考试信息网,公司一般有哪些部门,建立公司微信平台 网站平台,宁波网站建设培训学校如今#xff0c;有大胆的工程师在为Oracle工作。 昨天尝试确定Heisenbug时#xff0c;我得出了这个结论。 不足为奇#xff0c;当我尝试找到解决方案时#xff0c;该错误似乎消失了。 几个小时后#xff0c;将问题归结为JDK7更新之间的细微差别#xff0c;该错误的“ Hei… 如今有大胆的工程师在为Oracle工作。 昨天尝试确定Heisenbug时我得出了这个结论。 不足为奇当我尝试找到解决方案时该错误似乎消失了。 几个小时后将问题归结为JDK7更新之间的细微差别该错误的“ Heisen”部分被删除。 但是回到勇敢的主张。 为了理解我所描述的情况我将其提取到一个非常简单的测试代码段中供您尝试 class OOM {public static void main(String[] args) {java.util.Map m new java.util.HashMap(10_000_000);}
} 现在当我使用JDK7u40或更高版本在64位Mac OS X上启动课程时 my:tmp user$ /path-to/jdk1.7.0_40/bin/java -Xmx96m OOM
my:tmp user$ 您会看到命令提示符返回并且JVM成功完成了其工作。 现在使用JDKu25或更早版本启动相同的类 my:tmp user$ /path-to/jdk1.7.0_25/bin/java -Xmx96m OOM
Exception in thread main java.lang.OutOfMemoryError: Java heap spaceat java.util.HashMap.(HashMap.java:283)at java.util.HashMap.(HashMap.java:297)at OOM.main(OOM.java:3) 您会看到不同的结果。 使用100M条目初始化HashMap无法在我们的约100m堆中分配足够的资源并且JVM退出并抛出OutOfMemoryError 。 在这种情况下 HashMap的来源显然是第一大嫌疑人。 的确当您将JDK 7u25的源代码与下一个发行版名为u40为命名感到敬佩进行比较时您会看到很大的不同。 HashmapinitialCapacityloadFactor构造函数现在将忽略您构造初始大小等于initialCapacity的HashMap的意愿。 取而代之的是您看到仅当在地图上调用第一个put方法时基础数组才被延迟分配。 一个看似非常合理的变化– JVM在各个方面本质上都是懒惰的所以为什么不将大型数据结构的分配推迟到迫切需要这种分配时才进行。 因此从这个意义上讲这是一个很好的选择。 从某种意义上说某个特定的应用程序正在通过反射执行技巧并直接访问Map实现的内部结构也许不是。 但是同样不应该绕过API并开始变得聪明所以也许特定的开发人员现在更加相信每个新发现的概念都不适用于任何地方。 如果您是API开发人员您是否会自己进行更改 我不敢相信自己会有胆量因为要知道实施过程中各种怪异的方面大约有成千上万的应用程序在那儿。 但是我确实对JDK内的合理变更投了赞成票并且可以肯定地说这是好的。 参考 您是否敢更改HashMap实现 由我们的JCG合作伙伴 Nikita Salnikov Tarnovski在Plumbr Blog博客上获得。 翻译自: https://www.javacodegeeks.com/2013/11/would-you-dare-to-change-hashmap-implementation.html
