前百度面试官整理的——Java后端面试题（一）

List 和 Set 的区别

List , Set 都是继承自 Collection 接口 List 特色：元素有放入顺序，元素可重复 ，

Set 特色：元素无放入顺序，元素不可重复，重复元素会覆盖掉，（元素虽然无放入顺序，可是元素在set中的位 置是有该元素的 HashCode 决定的，其位置实际上是固定的，加入Set 的 Object 必须定义 equals ()方法 ，另外list 支持for循环，也就是经过下标来遍历，也能够用迭代器，可是set只能用迭代，由于他无序，没法用下标来取得想 要的值。） Set和List对比 Set：检索元素效率低下，删除和插入效率高，插入和删除不会引发元素位置改变。

List：和数组相似，List能够动态增加，查找元素效率高，插入删除元素效率低，由于会引发其余元素位置改变

HashSet 是如何保证不重复的

向 HashSet 中 add ()元素时，判断元素是否存在的依据，不只要比较hash值，同时还要结合 equles 方法比较。 HashSet 中的 add ()方法会使用 HashMap 的 add ()方法。如下是 HashSet 部分源码：

HashMap 的 key 是惟一的，由上面的代码能够看出 HashSet 添加进去的值就是做为 HashMap 的key。因此不会 重复（ HashMap 比较key是否相等是先比较 hashcode 在比较 equals ）。

HashMap 是线程安全的吗，为何不是线程安全的（最好画图说明多线程 环境下不安全）?

不是线程安全的；

若是有两个线程A和B，都进行插入数据，恰好这两条不一样的数据通过哈希计算后获得的哈希码是同样的，且该位 置尚未其余的数据。因此这两个线程都会进入我在上面标记为1的代码中。假设一种状况，线程A经过if判断，该 位置没有哈希冲突，进入了if语句，尚未进行数据插入，这时候 CPU 就把资源让给了线程B，线程A停在了if语句 里面，线程B判断该位置没有哈希冲突（线程A的数据还没插入），也进入了if语句，线程B执行完后，轮到线程A执 行，如今线程A直接在该位置插入而不用再判断。这时候，你会发现线程A把线程B插入的数据给覆盖了。发生了线 程不安全状况。原本在 HashMap 中，发生哈希冲突是能够用链表法或者红黑树来解决的，可是在多线程中，可能 就直接给覆盖了。

上面所说的是一个图来解释可能更加直观。以下面所示，两个线程在同一个位置添加数据，后面添加的数据就覆盖 住了前面添加的。

若是上述插入是插入到链表上，如两个线程都在遍历到最后一个节点，都要在最后添加一个数据，那么后面添加数 据的线程就会把前面添加的数据给覆盖住。则

在扩容的时候也可能会致使数据不一致，由于扩容是从一个数组拷贝到另一个数组。

HashMap 的扩容过程

当向容器添加元素的时候，会判断当前容器的元素个数，若是大于等于阈值(知道这个阈字怎么念吗？不念 fa 值， 念 yu 值四声)---即当前数组的长度乘以加载因子的值的时候，就要自动扩容啦。

扩容( resize )就是从新计算容量，向 HashMap 对象里不停的添加元素，而 HashMap 对象内部的数组没法装载更 多的元素时，对象就须要扩大数组的长度，以便能装入更多的元素。固然 Java 里的数组是没法自动扩容的，方法 是使用一个新的数组代替已有的容量小的数组，就像咱们用一个小桶装水，若是想装更多的水，就得换大水桶。

HashMap hashMap=new HashMap(cap);
cap =3， hashMap 的容量为4；

cap =4， hashMap 的容量为4；

cap =5， hashMap 的容量为8；

cap =9， hashMap 的容量为16；

若是 cap 是2的n次方，则容量为 cap ，不然为大于 cap 的第一个2的n次方的数。

HashMap 1.7 与 1.8 的 区别，说明 1.8 作了哪些优化，如何优化的？

HashMap结构图

在 JDK1.7 及以前的版本中， HashMap 又叫散列链表：基于一个数组以及多个链表的实现，hash值冲突的时候， 就将对应节点以链表的形式存储。

JDK1.8 中，当同一个hash值（ Table 上元素）的链表节点数不小于8时，将再也不以单链表的形式存储了，会被 调整成一颗红黑树。这就是 JDK7 与 JDK8 中 HashMap 实现的最大区别。

其下基于 JDK1.7.0_80 与 JDK1.8.0_66 作的分析

JDK1.7中

使用一个 Entry 数组来存储数据，用key的 hashcode 取模来决定key会被放到数组里的位置，若是 hashcode 相 同，或者 hashcode 取模后的结果相同（ hash collision ），那么这些 key 会被定位到 Entry 数组的同一个 格子里，这些 key 会造成一个链表。

在 hashcode 特别差的状况下，比方说全部key的 hashcode 都相同，这个链表可能会很长，那么 put/get 操做 均可能须要遍历这个链表，也就是说时间复杂度在最差状况下会退化到 O(n)

JDK1.8中

使用一个 Node 数组来存储数据，但这个 Node 多是链表结构，也多是红黑树结构

• 若是插入的 key 的 hashcode 相同，那么这些key也会被定位到 Node 数组的同一个格子里。
• 若是同一个格子里的key不超过8个，使用链表结构存储。
• 若是超过了8个，那么会调用 treeifyBin 函数，将链表转换为红黑树。

那么即便 hashcode 彻底相同，因为红黑树的特色，查找某个特定元素，也只须要O(log n)的开销

也就是说put/get的操做的时间复杂度最差只有 O(log n) 听起来挺不错，可是真正想要利用 JDK1.8 的好处，有一个限制： key的对象，必须正确的实现了 Compare 接口 若是没有实现 Compare 接口，或者实现得不正确（比方说全部 Compare 方法都返回0） 那 JDK1.8 的 HashMap 其实仍是慢于 JDK1.7 的

简单的测试数据以下：

向 HashMap 中 put/get 1w 条 hashcode 相同的对象 JDK1.7: put 0.26s ， get 0.55s JDK1.8 （未实现 Compare 接口）： put 0.92s ， get 2.1s 可是若是正确的实现了 Compare 接口，那么 JDK1.8 中的 HashMap 的性能有巨大提高，此次 put/get 100W条 hashcode 相同的对象 JDK1.8 （正确实现 Compare 接口，）： put/get 大概开销都在320 ms 左右

final finally finalize final

• 能够修饰类、变量、方法，修饰类表示该类不能被继承、修饰方法表示该方法不能被重写、修饰变量表 示该变量是一个常量不能被从新赋值。
• finally通常做用在try-catch代码块中，在处理异常的时候，一般咱们将必定要执行的代码方法finally代码块 中，表示不论是否出现异常，该代码块都会执行，通常用来存放一些关闭资源的代码。
• finalize是一个方法，属于Object类的一个方法，而Object类是全部类的父类，该方法通常由垃圾回收器来调 用，当咱们调用 System.gc() 方法的时候，由垃圾回收器调用finalize()，回收垃圾，一个对象是否可回收的 最后判断。

感谢你耐心看完了文章…

关注做者，我会不按期在思否分享Java，Spring，MyBatis，Redis，Netty源码分析，高并发、高性能、分布式、微服务架构的原理，JVM性能优化、分布式架构，BATJ面试 等资料…