我相信一个 ConcurrentHashMap is resized here .
我原以为当负载因子达到某个阈值时会调整 ConcurrentHashMap 的大小。
但是我看不出 addCount 方法的大小调整与加载因子有什么关系。
调整 ConcurrentHashMap 大小的标准是什么？负载因子是其中之一吗？
最佳答案
来自 ConcurrentHashMap 的 javadoc :
The table is resized when occupancy exceeds a percentage threshold (nominally, 0.75, but see below).
The table is dynamically expanded when there are too many collisions (i.e., keys that have distinct hash codes but fall into the same slot modulo the table size), with the expected average effect of maintaining roughly two bins per mapping (corresponding to a 0.75 load factor threshold for resizing). There may be much variance around this average as mappings are added and removed, but overall, this maintains a commonly accepted time/space tradeoff for hash tables. However, resizing this or any other kind of hash table may be a relatively slow operation. When possible, it is a good idea to provide a size estimate as an optional {@code initialCapacity} constructor argument. An additional optional {@code loadFactor} constructor argument provides a further means of customizing initial table capacity by specifying the table density to be used in calculating the amount of space to allocate for the given number of elements. Also, for compatibility with previous versions of this class, constructors may optionally specify an expected {@code concurrencyLevel} as an additional hint for internal sizing.
关于java - 是什么导致 ConcurrentHashMap 调整大小，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/55893118/