如今，有大膽的工程師在為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，為命名感到敬佩！）進行比較時，您會看到很大的不同。 Hashmap（initialCapacity，loadFactor）構造函數現在將忽略您構造初始大小等于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

總結

以上是生活随笔為你收集整理的您是否敢更改HashMap实现？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。