调整大小时在多线程环境中的Hashmap
我正在学习一个教程，它基本上解释了在多线程环境中调整Hashmap大小时发生争用情况的原因：
在Java中，如果同时发现两个线程，则HashMap需要调整大小，并且它们都尝试调整大小。在Java中调整HashMap的大小的过程中，存储在链表中的存储桶中的元素在迁移到新存储桶的过程中顺序颠倒，因为Java
HashMap不会在尾部附加新元素，而是在头部附加新元素。避免横越尾巴。如果发生比赛条件，那么您将陷入无限循环
阅读此书后，我有两个问题：
- 为什么每个存储桶的链表顺序颠倒？
- 我可以看到可能存在竞争条件，但看不到无限循环是如何来的？是因为一个线程可能将元素的头部附加到尾部，而另一个则以相反的顺序进行呢？
请帮我澄清一下，万分感谢！
问题答案：
实际上，至少有一种与 重新哈希处理 有关的竞赛条件。查看以下代码片段（来自Sun JDK7）：
boolean oldAltHashing = this.useAltHashing;
this.useAltHashing |= sun.misc.VM.isBooted() && (this.newCapacity >= Holder.ALTERNATIVE_HASHING_THRESHOLD);
boolean rehash = oldAltHashing ^ this.useAltHashing;
transfer(newTable, rehash);
this.table = newTable;
在这里，线程T1最终以rehash = true线程T2最终rehash = false（假设T1已更改的值this.useAltHashing）是可能的。
现在，猜猜哪个线程将编写this.table-您也不知道可以。因此，是否获得一致的内部状态是一个运气问题。
无论如何，正如我在 设计 评论中提到的那样 ，不应在多线程环境中使用HashMap 。不起作用。因为这个原因或其他原因。以上只是为什么
不应该违反合同的 一个例子 。
-
我正在学习一个教程，它基本上解释了在多线程环境中调整Hashmap大小时出现争用条件的原因： 在Java中，如果两个线程同时发现现在HashMap需要调整大小，那么它们都尝试调整大小。Java HashMap在调整HashMap大小的过程中，链表中存储的bucket中的元素在迁移到新bucket时被颠倒，因为Java HashMap不在尾部追加新元素，而是在头部追加新元素，以避免尾部遍历。如果竞争
-
问题内容： 我正在用d3.js绘制散点图。借助以下问题： 获取屏幕，当前网页和浏览器窗口的大小 我正在使用此答案： 这样我就可以将图适合用户的窗口，如下所示： 现在，我希望在用户调整窗口大小时可以调整图的大小。 PS：我的代码中没有使用jQuery。 问题答案： 寻找“响应式SVG”，使SVG响应式非常简单，您不必再担心大小。 这是我的做法： 注意： SVG图像中的所有内容都会随窗口宽度缩放。这包
-
在tkinter中调整窗口大小时，有没有办法动态调整小部件的大小？ 这是代码： 当我调整窗口大小时，窗口小部件的宽度和高度保持不变。 我想要的是根据窗口的大小动态调整窗口小部件的大小。 有没有办法在tkinter中实现这一点？ 如果有人能帮我，那就太好了。
-
我的应用程序中有如下工作流：可以有X个用户请求（通常同时有5-10个），他们希望在系统中搜索某些东西（每个请求在单独的线程中处理）。 每个搜索都可以并行处理（我目前正在实现）。线程/CPU使用实际上不是这里的问题，因为这些任务不需要占用CPU。数据库是瓶颈。 目前，我只为搜索机制设置了一个单独的DB连接池-最大池大小设置为10。我知道这不多，但我不能把它设置得更高。现在我试图弄清楚如何为每个搜索（
-
我有下面的代码，它设置了一个特定大小的窗口。它还从外部URL加载图像。
-
我的 Web 应用程序中出现随机错误，我迷路了。我创建了一个库来解码代码。我尝试了很多，从未失败过测试。但突然间，它开始随机失败。由于它在单线程测试中运行良好，有时在 servlet 环境中失败时，我能想象的唯一解释是问题与多线程环境中使用的库有关。老实说，我知道多线程是一个非常复杂的问题。我担心我的库可能不是线程安全的。顺便说一下，它非常简单，它是一个具有几种静态方法的正面类。基本上，假设您正在