一、HashMap 和 HashTable 的区别？底层实现是什么？【老题目】
1.区别：
（1）HashMap方法没有synchronized修饰，线程非安全， HashTable线程安全
（2）HashMap允许key 和value 为null，而HashTable不允许
2.HashMap底层实现：数组+链表实现
jdk8开始链表高度达到8、数组长度超过64时，链表转变为红黑树，元素以内部类node节点（链表）存在。
数组干什么用？HashMap存储元素的过程及步骤：
- 计算key的hash值，根据这个hash值进行二次hash，然后对数组（HashMap里面会维护一个数组）长度取模，对应到数组下标。
- 如果没有产生hash冲突（如果计算出来的该数组的下标位置没有元素），则直接创建node存入数组，此时没有链表。
- 如果产生hash冲突（如果计算出来的该数组的下标位置有元素，此时会出现链表），先进行equals比较，如果equals比较相同（key值相同的话，则会覆盖掉原来的value值）则取代该元素。hashcode一样但是equals比较两个对象不相等的话，则判断链表高度插入链表（会维护一个链表），链表越来越长，当链表高度达到8时（链表越长遍历的效率就会越低），并且数组长度达到64则会把链表转变为红黑树（平行二叉树，查询的效率有保障），当数组的长度低于6时则将红黑树转回链表。
- key为null, 存在下标0的位置
数组扩容：跟ArrayList里面的数组扩容是一样的，Java中静态数组new出来的时候就已经固定了长度，HashMap可以一直往里面放入值（小于Int的最大值），数组的长度如果固定是10 ，但是现在需要加入元素，则会出现数组越界。如果使用HashMap的话，基于HashMap底层的扩容因子，就会new一个新的数组，把数组的长度直接变大，把旧的数组里面的元素复制到新的数组里面。
二、ConcurrentHashMap原理，JDK7 和 JDK8版本的区别
ConcurrentHashMap是线程安全的hashMap
JDK7: （分段锁）
数据结构：ReentrantLock+Segment+HashEntry，一个Segment中包含一个HashEntry数组，每个HashEntry又是一个链表结构（类似hashMap,底层是数组+链表，只是ConcurrentHashMap多了一个Segment，Segment的个数可以由函数指定)
元素查询：二次hash，第一次hash定位到Segment（属于哪一段），第二次hash定位到元素所在的链表的头部（Segment里面由一个数组，找到数组的下标，数组的下标就是链表的头部）
锁：Segment分段锁（计算Key,根据key找到这个Segment是属于哪一段,找到某一段，跟HashTable相比锁的粒度要小一些），Segment继承了ReentrantLock，锁定操作的Segment，其他的Segment不受影响，并发度就是指Segment个数（可以同时接受多少个线程来操作），可以通过构造函数指定，数组扩容不会影响其他的Segment（一般数组扩容是比较消耗性能的，所以ConcurrentHashMap性能比较高）。
读（get方法）的时候不加锁，写的时候需要加锁，不怕读的时候读到脏数据吗？那是因为由volatile来保证的。
ConcurrentHashMap维护了一个node内部类跟LinkedList类似，node里面有一个val变量存储元素，这个val变量是采用了volatile来修饰的，保证可见性。所以get方法不需要加锁。
JDK8: （jdk8之前synchronized性能不及ReentrantLock，但是在jdk8之后对synchronized做了很大的优化）
数据结构：synchronized+CAS+Node+红黑树，Node的val和next都用volatile修饰，保证可见性
查找、替换、赋值操作都使用CAS，CAS是乐观锁，CAS在很多场景下并发不是很激烈的时候效率比synchronized会更高。
锁：锁链表的head节点，不影响其他元素的读写，锁粒度更细，效率更高，扩容时，阻塞所有的读写操作、并发扩容
读操作无锁：
Node的val和next都用volatile修饰，读写线程对该变量互相可见，保证不会读到脏数据。
数组用volatile修饰，保证扩容时被读线程感知
三、如何实现一个IOC容器
1、配置文件配置包扫描路径
2、递归包扫描获取.class文件
3、反射、确定需要交给IOC管理的类
4、对需要注入的类进行依赖注入
配置文件中指定需要扫描的包路径
定义一些注解，分别表示访问控制层、业务服务层、数据持久层、依赖注入注解、获取配置文件注解
从配置文件中获取需要扫描的包路径，获取到当前路径下的文件信息及文件夹信息，我们将当前路径下所有的.class结尾的文件添加到一个set集合中进行存储
遍历这个set集合，获取在类上有指定注解的类，并将其交给IOC容器，定义一个安全的Map用来存储这些对象
遍历这个IOC容器，获取到每一个类的实例，判断里面是有依赖它的类的实例，然后进行递归注入。
四、什么是字节码，采用字节码的好处是什么？
Java中的编译器与解释器：
Java中引入了虚拟机的概念，既在机器和编译程序之间加入了一层抽象的虚拟的机器。这台虚拟的机器（jvm）在任何平台上都提供给编译程序一个共同的接口。
编译程序只需要面向虚拟机，生成虚拟机能够理解的代码，然后由解释器（有windows版本的、linux版本的）来将虚拟机代码转换为特定系统的机器码执行。在Java中，这种供虚拟机理解的代码叫做字节码（即扩展名为.class的文件），它不面向任务特定的处理器，只面向虚拟机。
每一种平台的解释器（windows与Linux）是不同的，但是实现的虚拟机是相同的。Java源程序经过编译器编译后编程字节码，字节码由虚拟机解释执行，虚拟机将每一条要执行的字节码送给解释器，解释器将其翻译成待定机器上的机器码，然后在特定的机器上运行。这也就是解释了Java的编译与解释并存的特点。
Java源代码-->编译器-->jvm可以执行的Java字节码（即虚拟机指令）-->jvm-->jvm中解释器-->机器可执行的二进制机器码--->程序运行。
采用字节码的好处：（Java跨平台，提高效率）
Java语言通过字节码的方式，在一定程度上解决了传统解释性语言执行效率低的问题，同时又保留了解释型语言可移植的特点。所以Java程序运行时比较高效，而且，由于字节码并不专对一种特定的机器，因此，Java程序无须重新编译便可在多种不同的计算机上运行。
五、Java类加载器
JDK自带有三个类加载器：bootstrap ClassLoader、ExtClassLoader、AppClassLoader.
Bootstrap ClassLoader是ExtClassLoader的父类加载器，默认负责加载%JAVA_HOME%lib下的jar包和class文件。
ExtClassLoader是AppClassLoader的父类加载器，负责加载%JAVA_HOME%lib/ext文件夹下的jar包和class类。
AppClassLoader是自定义类加载器的父类，负责加载classpath下的类文件及引入的jar包。系统类加载器，线程上下文加载器。
继承ClassLoader可以实现自定义类加载器
六、双亲委派模型
main方法是由AppClassLoader来加载的。
双亲委派模型的好处：
- 主要是为了安全性，避免用户自己编写的类动态替换Java的一些核心类，比如String。
- 同时也避免了类的重复加载，因为JVM中区分不同类，不仅仅是根据类名，相同的class文件被不同的ClassLoader加载就是不同的两个类。
七、Java中的异常体系
Java中的所有异常都来自顶级父类Throwable。
Throwable下有两个子类Exception和Error。
Error是程序无法处理的错误，一旦出现这个错误，则程序将被迫停止运行。例如内存溢出。
Exception不会导致程序停止，又分为两个部分RunTimeException运行时异常和CheckedException检查异常（语法问题），例如空指针，数组下标越界。某个方法或某个调用出问题。
RunTimeException（运行时异常）常常发生在程序运行过程中，会导致程序当前（调用）线程执行失败，可以处理的异常。
CheckedException常常发生在程序编译过程中，会导致程序编译不通过。
八、GC如何判断对象可以被回收【可达性分析】
- 引用计数法：每个对象有一个引用计数属性，新增一个引用计数加1，引用释放时计数减1，计数为0时意味着这个对象可以被回收。
- 可达性分析法：从 GC Roots 开始向下搜索，搜索所走过的路径称为引用链。当一个对象到GC Roots没有任何引用链接相连时，则证明此对象是不可用的，那么虚拟机就判断是可回收对象。
引用计数法的缺点，可能会出现A引用了B，B又引用了A，这时候就算他们都不再使用了，但因为相互引用计数器=1 永远无法被回收。
引用计数法的优点：效率高，只需判断计数器就可以判断这个对象是否可以被回收。
因为引用计数法有缺陷所以有了可达性分析。
GC Roots 的对象有：
- 虚拟机栈（栈帧中的本地变量表）中引用的对象。（add（）方法中 new了一个user对象，那么这个user对象就是GC Roots）
- 方法去中类静态属性引用的对象
- 方法区中常量引用的对象
- 本地方法栈中JNI（即一般说的Native方法）引用的对象
可达性算法中的不可达对象先不是立即死亡，对象拥有一次自我拯救的机会。对象被系统宣告死亡至少要经历两次标记过程：第一次是经可达性分析发现没有GC Roots相连接的引用链，此时会做一个标记，此时是不会立即被回收的，第二次是在由虚拟机自动建立的finalizer队列中判断是否需要执行finalizer()方法。
当对象变成（）不可达时，DC会判断该对象是否覆盖了finalize()方法，若第二次没有被覆盖，则直接将其回收。否则若第二次对象未执行过finalize()方法，将其放入F-Queue队列，由低优先级线程执行该队列中对象的finalize()方法。执行finalize()方法完毕之后，GC会再次判断该对象是否可达，若不可达，则进行回收，否则，对象”复活“
每个对象只能触发一次finalize()方法
由于finalize()方法运行代价高昂，不确定性大，无法保证各个对象的调用顺序，不推荐大家使用，建议遗忘它。