hashmap会缩容吗

"怎么把hashmap 中的数据存到Mysql"

HashMap的性能与数据量有关，即HashMap的数据量越大，HashMap的查找、添加和删除的操作的性能就会变的越低。

原因在于，当HashMap的数据量较大时，HashMap中的数据被分布存储在不同的桶中以减少冲突，但是也导致了查询速度变慢，因为要检查多个桶来查找所需要的数据。

此外，HashMap会根据数据量不断进行扩容，这也会降低HashMap的性能。

hashmap在什么情况下会扩容

你的这个问题问的就有问题；

首先你得清楚你的map中放的值都是些什么内容，不同的内容可以采取不同的方法；

map中放的是键值对，你想把整个map内容保存的话；最好是取出来保存；

如果是对象，完全可以按照对象进行保存；

其他的话，可根据实际再采取不同的方式。

hashmap的最大容量是多少，在多少的时候会导致查询响应过慢

本人是给不出什么好的回答,应为你这个问题实在是太.....嘿嘿.....。

只好给你吧API描述贴出来咯..相信看了你会明白的.。

下面是API文档中的解释

基于哈希表的 Map 接口的实现。此实现提供所有可选的映射操作，并允许使用 null 值和 null 键。（除了不同步和允许使用 null 之外，HashMap 类与 Hashtable 大致相同。）此类不保证映射的顺序，特别是它不保证该顺序恒久不变。

此实现假定哈希函数将元素正确分布在各桶之间，可为基本操作（get 和 put）提供稳定的性能。迭代集合视图所需的时间与 HashMap 实例的“容量”（桶的数量）及其大小（键-值映射关系数）的和成比例。所以，如果迭代性能很重要，则不要将初始容量设置得太高（或将加载因子设置得太低）。

HashMap 的实例有两个参数影响其性能：初始容量 和加载因子。容量 是哈希表中桶的数量，初始容量只是哈希表在创建时的容量。加载因子 是哈希表在其容量自动增加之前可以达到多满的一种尺度。当哈希表中的条目数超出了加载因子与当前容量的乘积时，通过调用 rehash 方法将容量翻倍。

通常，默认加载因子 (.75) 在时间和空间成本上寻求一种折衷。加载因子过高虽然减少了空间开销，但同时也增加了查询成本（在大多数 HashMap 类的操作中，包括 get 和 put 操作，都反映了这一点）。在设置初始容量时应该考虑到映射中所需的条目数及其加载因子，以便最大限度地降低 rehash 操作次数。如果初始容量大于最大条目数除以加载因子，则不会发生 rehash 操作。

如果很多映射关系要存储在 HashMap 实例中，则相对于按需执行自动的 rehash 操作以增大表的容量来说，使用足够大的初始容量创建它将使得映射关系能更有效地存储。

注意，此实现不是同步的。如果多个线程同时访问此映射，而其中至少一个线程从结构上修改了该映射，则它必须 保持外部同步。（结构上的修改是指添加或删除一个或多个映射关系的操作；仅改变与实例已经包含的键关联的值不是结构上的修改。）这一般通过对自然封装该映射的对象进行同步操作来完成。如果不存在这样的对象，则应该使用 Collections.synchronizedMap 方法来“包装”该映射。最好在创建时完成这一操作，以防止对映射进行意外的不同步访问，如下所示：

Map m = Collections.synchronizedMap(new HashMap(...));。

由所有此类的“集合视图方法”所返回的迭代器都是快速失败 的：在迭代器创建之后，如果从结构上对映射进行修改，除非通过迭代器自身的 remove 或 add 方法，其他任何时间任何方式的修改，迭代器都将抛出 ConcurrentModificationException。因此，面对并发的修改，迭代器很快就会完全失败，而不冒在将来不确定的时间任意发生不确定行为的风险。

注意，迭代器的快速失败行为不能得到保证，一般来说，存在不同步的并发修改时，不可能作出任何坚决的保证。快速失败迭代器尽最大努力抛出 ConcurrentModificationException。因此，编写依赖于此异常程序的方式是错误的，正确做法是：迭代器的快速失败行为应该仅用于检测程序错误。

此类是 Java Collections Framework 的成员。

原则上，hashmap的插入和搜索，复杂度都是1，是非常快速的跟你的容量大小通常是没有直接关系的但是这是理想的情况。

这里说的理想，是在你所存储的对象的hashcode这个方法写的非常有效的情况下。根据hash的原理，存放一个对象是根据他的hashcode来计算的，如果没有哈希冲突，那么他的存储效率是最高，最完美的。

为什么哈希冲突会使得效率下降呢？

具体来分析，假设一个对象O1，他的hashcode算出来是1，另一个对象是O2，hashcode算起来也是1. 先放入O1对象，这时候速度很快，根据hashcode计算出来这个对象应该在哪个位置存放，然后直接放进去。但是到了放O2的时候，根据hashcode计算的地址存放，发现之前已经有O1了，那么显然是不能放的，因此就要采取些措施，比如，再计算一次，然后分配存放的地址（如果冲突，将继续，知道解决），一种最恶劣的情况下，很多很多的对象都存在hash冲突，那么重要就变得存储越来越慢。但是这个不是hashmap的责任，而是你的对象的hashcode方法没有定义好，使得冲突频繁。

另外，哈希表为了避免这种冲突，会有一点优化。简单的说，原本可以放100个数据的空间，当放到80个的时候，根据经验，接下去冲突的可能性会更加高，就好比一个靶子上80%都是箭的时候你再射一箭出去，射中箭的可能性很大。因此就自动增加空间来减小冲突可能性。

80/100 = 0.8 这个0.8就是负载因子。

java中的hashmap的负载因子是0.75说了写理论。说这个的原因是想解释一下你的疑问“10000条的时候在搜索的时候很快，那么在多少条的时候可能导致效率下降呢”。这个答案是肯定的，就是存储的量跟存储效率没有直接的关系。

这页是hash表这个数据结构的优势所在。

如果你觉得效率出现问题的时候，应该去关注一下你的存储对象的hashcode方法写的是否有问题。

如果想更完美的解决效率问题，还可以手动指定hashmap的负载因子（用HashMap（int factor）这个构造方法），负载因子越低，冲突可能越小。但是牺牲的空间会相应增加。

如果还是不能很好理解，可以先参看hash这个数据结构的特点，和JDK中HashMap的源代码，以及注释。

学好java，数据结构是很重要的，理解原理的使用，跟生搬硬套的使用，不可同年而语。

所以，去面试淘宝，腾讯，化为这种公司不会问你struts怎么用，只会问你struts怎么写。如同不会问你hashmap怎么用，而会问你hashmap的设计理念，和实现原理。

希望对你有所帮助

原文地址：http://www.qianchusai.com/hashmap%E4%BC%9A%E7%BC%A9%E5%AE%B9%E5%90%97.html