1700445212
1700445213
HashMap在底层也是以数组方式保存元素的，其中每一个键值对就是一个元素，也就是说HashMap把键值对封装成了一个Entry对象，然后再把Entry放到了数组中，我们简单看一下Entry类：
1700445214
1700445215
static class Entry＜K, V＞implements Map.Entry＜K, V＞{
1700445216
1700445217
//键
1700445218
1700445219
final K key；
1700445220
1700445221
//值
1700445222
1700445223
V value；
1700445224
1700445225
//相同哈希码的下一个元素
1700445226
1700445227
Entry＜K, V＞next；
1700445228
1700445229
final int hash；
1700445230
1700445231
/*key、value的getter/setter方法，以及重写的equals、hashCode、toString方法*/
1700445232
1700445233
}
1700445234
1700445235
}
1700445236
1700445237
HashMap底层的数组变量名叫table，它是Entry类型的数组，保存的是一个一个的键值对（在我们的例子中Entry是由两个String类型组成的）。再回过头来想想，对我们的例子来说，HashMap比ArrayList多了一次封装，把String类型的键值对转换成Entry对象后再放入数组，这就多了40万个对象，这应该是问题产生的第一个原因。
1700445238
1700445239
我们知道HashMap的长度也是可以动态增加的，它的扩容机制与ArrayList稍有不同，其代码如下：
1700445240
1700445241
if（size++＞=threshold）
1700445242
1700445243
resize（2*table.length）；
1700445244
1700445245
在插入键值对时，会做长度校验，如果大于或等于阀值（threshold变量），则数组长度增大一倍。不过，默认的阀值是多大的呢？默认是当前长度与加载因子的乘积。
1700445246
1700445247
threshold=（int）（newCapacity*loadFactor）；
1700445248
1700445249
默认的加载因子（loadFactor变量）是0.75，也就是说只要HashMap的size大于数组长度的0.75倍时，就开始扩容，经过计算得知（怎么计算的？查找2的N次幂大于40万的最小值即为数组的最大长度，再乘以0.75就是最后一次扩容点，计算的结果是N=19），在Map的size为393216时，符合了扩容条件，于是393216个元素准备开始大搬家，要扩容嘛，那首先要申请一个长度为1048576（当前长度的两倍嘛，2的19次方再乘以2，即2的20次方）的数组，但问题是此时剩余的内存只有7MB了，不足以支撑此运算，于是就报内存溢出了！这是第二个原因，也是最根本的原因。
1700445250
1700445251
这也就解释了为什么还剩余着7MB内存就报内存溢出了。我们再来思考一下ArrayList的扩容策略，它是在小于数组长度的时候才会扩容1.5倍，经过计算得知，ArrayList的size在超过80万后（一次加两个元素，40万的两倍），最近的一次扩容会是在size为1005308时，也就是说，如果程序设置了增加元素的上限为502655，同样会报内存溢出，因为它也要申请一个1507963长度的数组，如果没这么大的地方，就会报错了。
1700445252
1700445253
综合来说，HashMap比ArrayList多了一个层Entry的底层对象封装，多占用了内存，并且它的扩容策略是2倍长度的递增，同时还会依据阀值判断规则进行判断，因此相对于ArrayList来说，它就会先出现内存溢出。
1700445254
1700445255
可能会有读者在想，是不是可以在声明时指定HashMap的默认长度和加载因子来减少此问题的发生。是可以缓解此问题，可以不再频繁地进行数组扩容，但仍然避免不了内存溢出问题，因为键值对的封装对象Entry还是少不了的，内存依然增长较快。
1700445256
1700445257
注意 尽量让HashMap中的元素少量并简单。
1700445258
1700445259
1700445260
1700445261
[
上一页 ]
[ :1.700445212e+09 ]
[
下一页 ]