Java 番石榴ImmutableMap是否会推迟地图大小调整？

当我测试番石榴ImmutableMap和HashMap时，我发现ImmutableMap在常规点（即16、32、64）上没有调整大小。这是什么意思

测试代码：

Map<Integer, Integer> mapFootPrint = new HashMap<Integer, Integer>();

for(int i = 1; i < 1000; i ++){
    mapFootPrint.put(i, i+ 128); //no cache integer
    ImmutableMap<Integer, Integer> immutableMap = ImmutableMap.copyOf(mapFootPrint);

    System.out.println(MemoryMeasurer.measureBytes(mapFootPrint));
    System.out.println(MemoryMeasurer.measureBytes(immutableMap));
}

MapMapFootprint=newHashMap（）；
对于（int i=1；i<1000；i++）{
mapFootPrint.put（i，i+128）；//无缓存整数
ImmutableMap ImmutableMap=ImmutableMap.copyOf（mapFootPrint）；
System.out.println（MemoryMeasurer.measureBytes（mapFootPrint））；
System.out.println（MemoryMeasurer.measureBytes（immutableMap））；
}

结果图：

---

Y轴是以字节为单位的内存占用，X轴是映射大小。蓝色是HashMap，橙色是ImmutableMap。您可以看到ImmutableMap比HashMap更晚调整大小。

这只是一个不同的加载因子-对于普通的

HashMap

为1.33，对于

ImmutableMap

为1.2。所有哈希映射都有可用空间，因为哈希从来都不是完美的，可变映射需要额外的空间来容纳潜在的新条目。看看Guava

com.google.common.collect.Hashing.closedTableSize（）

，Guava

com.google.common.collect.regulammutableMap.MAX\u LOAD\u FACTOR

，和

java.util.HashMap.DEFAULT\u LOAD\u FACTOR

，这似乎是一个负载因子问题。但是我使用的是64位Java7HotSpot，默认的加载因子是0.75f。你知道谷歌为什么选择不同的比例吗？有基准吗？在数字的存储和应用方式上是不同的——一个库使用乘法，另一个库使用除法：items*1.33=items/（0.75），items*1.25=items/（0.80）