Returns a capacity that is sufficient to keep the map from being resized as long as it grows no larger than expectedSize and the load factor is ≥ its default (0.75).
(int expectedSize)
| 260 | * larger than expectedSize and the load factor is ≥ its default (0.75). |
| 261 | */ |
| 262 | static int capacity(int expectedSize) { |
| 263 | if (expectedSize < 3) { |
| 264 | checkNonnegative(expectedSize, "expectedSize"); |
| 265 | return expectedSize + 1; |
| 266 | } |
| 267 | if (expectedSize < Ints.MAX_POWER_OF_TWO) { |
| 268 | // This seems to be consistent across JDKs. The capacity argument to HashMap and LinkedHashMap |
| 269 | // ends up being used to compute a "threshold" size, beyond which the internal table |
| 270 | // will be resized. That threshold is ceilingPowerOfTwo(capacity*loadFactor), where |
| 271 | // loadFactor is 0.75 by default. So with the calculation here we ensure that the |
| 272 | // threshold is equal to ceilingPowerOfTwo(expectedSize). There is a separate code |
| 273 | // path when the first operation on the new map is putAll(otherMap). There, prior to |
| 274 | // https://github.com/openjdk/jdk/commit/3e393047e12147a81e2899784b943923fc34da8e, a bug |
| 275 | // meant that sometimes a too-large threshold is calculated. However, this new threshold is |
| 276 | // independent of the initial capacity, except that it won't be lower than the threshold |
| 277 | // computed from that capacity. Because the internal table is only allocated on the first |
| 278 | // write, we won't see copying because of the new threshold. So it is always OK to use the |
| 279 | // calculation here. |
| 280 | return (int) ceil(expectedSize / 0.75); |
| 281 | } |
| 282 | return Integer.MAX_VALUE; // any large value |
| 283 | } |
| 284 | |
| 285 | /** |
| 286 | * Creates a <i>mutable</i>, empty, insertion-ordered {@code LinkedHashMap} instance. |