正是因为这，所以想要转换成`Base64`最少要三个字节才可以，转换出来的`Base64`最少是4个字节，但是如果我要转换的字节不够3个怎么办？比如我想对字符`A`进行`Base64`加密。，`A`对应的第二个`Base64`的二进制位只有两个，把后边的四个补0就是了。

HashMap是Map接口的实现，元素以键值对的方式存储，并且允许使用null建和null值，因为key不允许重复，因此只能有一个键为null。

HashMap被认为是Hashtable的增强版，HashMap是一个非线程安全的容器，如果想构造线程安全的Map考虑使用ConcurrentHashMap。

HashMap是无序的，因为HashMap无法保证内部存储的键值对的有序性。

- 初始容量

HashMap的默认初始容量是由DEFAULT_INITIAL_CAPACITY属性管理的。

`static final int DEFAULT_INITIAL_CAPACITY = 1 << 4;

HashMap的默认初始容量是 1 << 4 = 16， << 是一个左移操作，它相当于是:


- 最大容量

HashMap的最大容量是

`static final int MAXIMUM_CAPACITY = 1 << 30;`

这里是不是有个疑问？int 占用四个字节，按说最大容量应该是左移 31 位，为什么 HashMap 最大容量是左移 30 位呢？因为在数值计算中，最高位也就是最左位的位 是代表着符号为，0 -> 正数，1 -> 负数，容量不可能是负数，所以 HashMap 最高位只能移位到 2 ^ 30 次幂。

- 默认负载因子

HashMap的默认负载因子是

`static final float DEFAULT_LOAD_FACTOR = 0.75f;`

float 类型所以用 .f 为单位，负载因子是和扩容机制有关，这里大致提一下，后面会细说。扩容机制的原则是当 HashMap 中存储的数量 > HashMap 容量 * 负载因子时，就会把 HashMap 的容量扩大为原来的二倍。

HashMap 的第一次扩容就在 DEFAULT_INITIAL_CAPACITY * DEFAULT_LOAD_FACTOR = 12 时进行。

- 树化阈值

HashMap 的树化阈值是

`static final int TREEIFY_THRESHOLD = 8;`

在进行添加元素时，当一个桶中存储元素的数量 > 8 时，会自动转换为红黑树（JDK1.8 特性）。

- 链表阈值

HashMap 的链表阈值是

`static final int UNTREEIFY_THRESHOLD = 6;` 在进行删除元素时，如果一个桶中存储元素数量 < 6 后，会自动转换为链表 - 扩容临界值 `static final int MIN_TREEIFY_CAPACITY = 64;`

这个值表示的是当桶数组容量小于该值时，优先进行扩容，而不是树化

哈希表中哈希函数的设计是相当重要的，这也是建哈希表过程中的关键问题之一。

建立一个哈希表之前需要解决两个主要问题：

- 构造一个合适的哈希函数,均匀性 H（key）的值均匀分布在哈希表中

- 冲突的处理

冲突：在哈希表中，不同的关键字值对应到同一个存储位置的现象。

当一个值中要存储到HashMap中的时候会根据Key的值来计算出他的hash，通过hash值来确认存放到数组中的位置，如果发生hash冲突就以链表的形式存储，当链表过长的话，HashMap会把这个链表转换成红黑树来存储通过hash的方法，通过put和get存储和获取对象。存储对象时，我们将K / V传给put方法时，它调用hashCode计算hash从而得到bucket位置，进一步存储，HashMap会根据当前bucket的占用情况自动调整容量 (超过Load Factor则resize为原来的2倍)。

获取对象时，我们将K传给get()方法，它调用hashCode()计算hash从而得到bucket位置，并进一步调用equals()方法确定键值对。

因为hashCode()是int类型，取值范围是40多亿，只要哈希函数映射的比较均匀松散，碰撞几率是很小的。 但就算原本的hashCode()取的很好，每个key的hashCode()不同，但是由于HashMap的哈希桶的长度远比hash取值范围小，默认是16，所以当对hash值以桶的长度取余，以找到存放该key的桶的下标时，由于取余是通过与操作完成的，会忽略hash值的高位。因此只有hashCode()的低位参加运算，

扰动函数就是为了解决hash碰撞的。它会综合hash值高位和低位的特征，并存放在低位，因此在与运算时，相当于高低位一起参与了运算，以减少hash碰撞的概率。（在JDK8之前，扰动函数会扰动四次，JDK8简化了这个操作）扩容操作时，会new一个新的Node数组作为哈希桶，然后将原哈希表中的所有数据(Node节点)移动到新的哈希桶中，相当于对原哈希表中所有的数据重新做了一个put操作。所以性能消耗很大，可想而知，在哈希表的容量越大时，性能消耗越明显。扩容时，如果发生过哈希碰撞，节点数小于8个。则要根据链表上每个节点的哈希值，依次放入新哈希桶对应下标位置。因为扩容是容量翻倍，所以原链表上的每个节点，现在可能存放在原来的下标，即low位， 或者扩容后的下标，即high位。 high位= low位+原哈希桶容量如果追加节点后，链表数量 >=8，且只有数组长度大于64才处理，则转化为红黑树由迭代器的实现可以看出，遍历HashMap时，

数组的特点：查询效率高，插入删除效率低。

链表的特点：查询效率低，插入删除效率高。

在HashMap底层使用数组加（链表或红黑树）的结构完美的解决了数组和链表的问题，使得查询和插入，删除的效率都很高。

数据结构的存储由数组+链表的方式，变化为数组+链表+红黑树的存储方式，当链表长度超过阈值（8）时,且只有数组长度大于64才处理，将链表转换为红黑树。

这里有一个需要注意的点就是在JDK1.8 HashMap扩容阶段重新映射元素时不需要像1.7版本那样重新去一个个计算元素的hash值，而是通过hash & oldCap的值来判断，若为0则索引位置不变，不为0则新索引=原索引+旧数组长度，为什么呢？具体原因如下：

因为我们使用的是2次幂的扩展(指长度扩为原来2倍)，所以，元素的位置要么是在原位置，要么是在原位置再移动2次幂的位置。因此，我们在扩充HashMap的时候，不需要像JDK1.7的实现那样重新计算hash，只需要看看原来的hash值新增的那个bit是1还是0就好了，是0的话索引没变，是1的话索引变成“原索引+oldCap

* 如果追加节点后，链表数量 >= 8，则转化为红黑树

1. JDK8为红黑树 + 链表 + 数组的形式，当桶内元素大于8时,且只有数组长度大于64才处理，便会树化。

把链表转换成红黑树，树化需要满足以下两个条件：

- 链表长度大于等于8

- table数组长度大于等于64

为什么table数组容量大于等于64才树化？

因为当table数组容量比较小时，键值对节点 hash 的碰撞率可能会比较高，进而导致链表长度较长。这个时候应该优先扩容，而不是立马树化。

6. HashMap和HashSet的区别：

HashSet继承于AbstractSet接口，实现了Set、Cloneable、java.io.Serializable接口。HashSet不允许集合中出现重复的值。HashSet底层其实

就是HashMap，所有对HashSet的操作其实就是对HashMap的操作。所以HashSet也不保证集合的顺序。

当线程要处理该变量时，多个处理器会将变量从主内存复制一份分别存储在自己的存储器中，等到进行完操作后，再赋值回主存。

`HashSet`和`HashMap`一直都是`JDK`中最常用的两个类，`HashSet`要求不能存储相同的对象，`HashMap`要求不能存储相同的键。 那么`Java`运行时

环境是如何判断`HashSet`中相同对象、`HashMap`中相同键的呢？当存储了相同的东西之后`Java`运行时环境又将如何来维护呢？

在研究这个问题之前，首先说明一下`JDK`对`equals(Object obj)`和`hashcode()`这两个方法的定义和规范:

在`Java`中任何一个对象都具备`equals(Object obj)`和`hashcode()`这两个方法，因为他们是在`Object`类中定义的:

- `equals(Object obj)`方法用来判断两个对象是否“相同”，如果“相同”则返回`true`，否则返回`false`。

- `hashcode()`方法返回一个`int`数，在`Object`类中的默认实现是“将该对象的内部地址转换成一个整数返回”。