本地常州网站建设,上海市建设工程 安全协会网站,wordpress需求规划书,浙江昆仑建设集团网站最近#xff0c;我偶然发现了一个错误#xff0c;该错误是由于多个线程对java.util.HashMap的使用不当引起的。 该错误是抽象泄漏的一个很好的例子。 只有了解数据结构的实现级别详细信息#xff0c;才能帮助我解决当前的问题。 因此#xff0c;我希望分享我所面临的问题将… 最近我偶然发现了一个错误该错误是由于多个线程对java.util.HashMap的使用不当引起的。 该错误是抽象泄漏的一个很好的例子。 只有了解数据结构的实现级别详细信息才能帮助我解决当前的问题。 因此我希望分享我所面临的问题将鼓励我们的一些读者熟悉基本数据结构的实现方式。 一天中通常仅需几分钟即可完成的某些分析过程已经运行了数小时因此我所面对的症状每天都变得丑陋。 作为我们Craft.io的真正信奉者我们通过自己的监控软件及时得到通知并开始调查原因。 我也有几个来自处理线程的线程转储。 他们指出该代码只是在堆转储中发现的哈希图中处理条目看似处于未终止的循环中。 因此似乎正在分析的数据以某种方式损坏了其中包含循环引用。 令我惊讶的是确实如此。 分析的堆内容中的HashMap条目相互引用。 在设计堆分析算法时我们从未想到这是可能的。 显然我们错了。 由于已知HashMap实现不是线程安全的所以我现在怀疑它与HashMap使用的并发问题有关。 实际上在java.util.HashMap的设计中隐藏着一个问题。 如您所知 HashMap由存储区数组组成每个存储区均引用一个链接的条目列表。 条目依次引用列表中的下一个条目直到最后一个条目引用null 我们的分析器遇到的问题是两个条目相互引用形成一个封闭的循环。 在Google的帮助下我发现了最终如何创建这样的循环引用是多线程环境中的一个问题。 再次提醒您 HashMap在运行时会根据映射中的条目数动态调整大小。 默认情况下 HashMaps使用75的负载率。 这意味着只要地图中的条目数超过可用容量的75地图大小就会增加以避免在地图元素条目上发生太多冲突。 所以我在这里。 显然有多个线程试图同时调整地图的大小从而在某些存储桶中创建了一个循环。 罪魁祸首最终隐藏在Java HashMap源代码的以下几行中 void transfer(Entry[] newTable, boolean rehash) {... skipped for brevity ...Entry next e.next;if (rehash) {e.hash null e.key ? 0 : hash(e.key);}... skipped for brevity ...
} 现在我们的分析端点解决方案非常简单。 我们只需要保留有关已处理条目的分类帐而无需对所有条目进行两次处理就可以了。 我确实相信这是失败抽象的一个很好的例子。 Java中的HashMaps构建良好即使您不了解实现细节也可以很好地为您服务。 直到他们不这样做。 在这种情况下对数据结构实现细节的深入了解将为您带来不同。 翻译自: https://www.javacodegeeks.com/2016/08/resizing-hashmap-dangers-ahead.html
