ConcurrentHashMap构造函数参数？ [英] ConcurrentHashMap constructor parameters?

问题描述

我想知道构造 ConcurrentHashMap 的参数：

• initialCapacity 默认为16（理解）。


• loadFactor 默认为0.75 。


• concurrencyLevel 默认为16。

• initialCapacity is 16 by default (understood).
• loadFactor is 0.75 by default.
• concurrencyLevel is 16 by default.

我的问题是：

• 应使用什么标准来调整 loadFactor up or down？


• 我们如何确定并发更新线程的数量？


• 应该使用什么标准来调整 concurrencyLevel 上涨还是下跌？

• What criteria should be used to adjust loadFactor up or down?
• How do we establish the number of concurrently updating threads?
• What criteria should be used to adjust concurrencyLevel up or down?

此外：

• 良好哈希码实现的标志是什么？ （如果SO问题解决了这个问题，请链接到它。）

• What are the hallmarks of a good hashcode implementation? (If an SO question addresses this, just link to it.)

谢谢！

推荐答案

简短回答：将初始容量设置为大致预期在地图中放置的映射数量，并将其他参数保留为默认值。

The short answer: set "initial capacity" to roughly how many mappings you expect to put in the map, and leave the other parameters at their default.

长答案：

• 负载系数是
  之间的比率地图中桶的数量和
  预期元素的数量;

• load factor is the ratio between the number of "buckets" in the map and the number of expected elements;

0.75通常是合理的折衷 - 我记得，它意味着使用
好​​的哈希函数，平均而言我们
期望大约1.6次重定向以在地图中找到
元素（或者在该图周围）;

0.75 is usually a reasonable compromise-- as I recall, it means that with a good hash function, on average we expect about 1.6 redirects to find an element in the map (or around that figure);

• 更改负载
  因子更改
  更多重定向以查找元素之间的折衷，但
  减少浪费空间 - 放置0.75是
  通常是一个很好的值;

• changing the load factor changes the compromise between more redirects to find an element but less wasted space-- put 0.75 is really usually a good value;

原则上，将ConcurrencyLevel设置为
并发thr的数量eads你
期望修改地图，
虽然过高估计这不是
似乎对其他
造成不良影响而不是浪费内存（我写了一点
在 ConcurrentHashMap性能
a之前，以防你感兴趣的是
）

in principle, set ConcurrencyLevel to the number of concurrent threads you expect to have modifying the map, although overestimating this doesn't appear to have a bad effect other than wasting memory (I wrote a little on ConcurrentHashMap performance a while ago in case you're interested)

非正式地，你的哈希函数本质上应该是尽可能多的随机性。或者更严格地说，给定元素的哈希码应该给每个位大约50％的机会设置。用一个例子说明这一点实际上更容易：再次，你可能对我写的关于 String哈希函数如何工作和相关的哈希函数指南。对这些事情的反馈是显而易见的欢迎。

Informally, your hash function should essentially aim to have as much "randomness" in the bits as possible. Or more strictly, the hash code for a given element should give each bit a roughly 50% chance of being set. It's actually easier to illustrate this with an example: again, you may be interested in some stuff I wrote about how the String hash function works and associated hash function guidelines. Feedback is obvioulsy welcome on any of this stuff.

我在某些方面也提到的一件事是你在练习中不必过于偏执：如果你的哈希函数在某些位中产生合理的随机性，然后通常就可以了。在最糟糕的情况下，将代表性的数据段粘贴到字符串中并获取字符串的哈希码实际上并不是那么糟糕。

One thing I also mention at some point is that you don't have to be too paranoid in practice: if your hash function produces a "reasonable" amount of randomness in some of the bits, then it will often be OK. In the worst case, sticking representative pieces of data into a string and taking the hash code of the string actually doesn't work so badly.

这篇关于ConcurrentHashMap构造函数参数？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！