1.基础语法

1.1 八种基本数据类型的大小以及他们的封装类

基本数据类型	所占内存大小（单位：字节）	对应的包装类
byte	1	Byte
short	2	Short
int	4	Integer
long	8	Long
float	4	Float
double	8	Double
boolean	1（一般，具体看JVM是否设置高效储存）	Boolean
char	2	Character

1.2 引用数据类型

① 类Class引用 ② 接口Interface引用 ③ 数组引用

1.3 Switch能否用string做参数

在Java5以前，switch(expr)中，exper只能是byte，short，char，int类型(或其包装类)的常量表达式。

从Java5开始，java中引入了枚举类型，即enum类型。

从Java7开始，exper还可以是String类型。

但是long在所有版本中都是不可以的。

Java7并没有新的指令来处理switch string，而是通过调用switch中string.hashCode,将string转换为int从而进行判断。

hashcode返回的是int型
可以发现：进行switch的实际是hash值，然后用equals进行安全检查（因为hash值可能会发生碰撞），所以性能不如枚举。switch支持String其实是一个语法糖，在编译后的字节码文件中都会被还原成原生类型，并在相应位置插入了强制转换代码，底层的JVM在switch上并没有修改。

当传入switch的是null时，在运行时对一个null调用hashCode()方法，会抛出NullPointerException；如果case写的是null，那么在编译时无法求出hashcode，就会编译报错。

1.4 equals与==的区别

• 对于基本数据类型来说，== 比较的是值
• 对于引用数据类型来说，== 比较的是对象的内存地址

equals() 不能用于判断基本数据类型的变量，只能用来判断两个对象是否相等。equals()方法存在于Object类中，而Object类是所有类的直接或间接父类，因此所有的类都有equals()方法。

equals() 方法存在两种使用情况：

• 类没有重写 equals()方法 ：通过equals()比较该类的两个对象时，等价于通过“==”比较这两个对象，使用的默认是 Object类equals()方法。
• 类重写了 equals()方法 ：一般我们都重写 equals()方法来比较两个对象中的属性是否相等；若它们的属性相等，则返回 true(即，认为这两个对象相等)。

1.5 自动拆箱装箱

装箱其实就是调用了 包装类的valueOf()方法，拆箱其实就是调用了 xxxValue()方法

因此如下

• Integer i = 10 等价于 Integer i = Integer.valueOf(10)
• int n = i 等价于 int n = i.intValue();

1.6 Object有哪些方法

/**
 * getClass 方法，用于返回当前运行时对象的 Class 对象，使用了 final 关键字修饰，故不允许子类重写。
 */
public final native Class<?> getClass()
/**
 * hashCode 方法，用于返回对象的哈希码，主要使用在哈希表中，比如 JDK 中的HashMap。
 */
public native int hashCode()
/**
 * 用于比较 2 个对象的内存地址是否相等，String 类对该方法进行了重写以用于比较字符串的值是否相等。
 */
public boolean equals(Object obj)
/**
 * clone 方法，用于创建并返回当前对象的一份拷贝。
 */
protected native Object clone() throws CloneNotSupportedException
/**
 * 返回类的名字实例的哈希码的 16 进制的字符串。建议 Object 所有的子类都重写这个方法。
 */
public String toString()
/**
 * notify 方法，并且不能重写。唤醒一个在此对象监视器上等待的线程(监视器相当于就是锁的概念)。如果有多个线程在等待只会任意唤醒一个。
 */
public final native void notify()
/**
 * notifyAll 方法，并且不能重写。跟 notify 一样，唯一的区别就是会唤醒在此对象监视器上等待的所有线程，而不是一个线程。
 */
public final native void notifyAll()
/**
 * wait 方法，并且不能重写。暂停线程的执行。注意：sleep 方法没有释放锁，而 wait 方法释放了锁 ，timeout 是等待时间。
 */
public final native void wait(long timeout) throws InterruptedException
/**
 * 多了 nanos 参数，这个参数表示额外时间（以毫微秒为单位，范围是 0-999999）。 所以超时的时间还需要加上 nanos 毫秒。。
 */
public final void wait(long timeout, int nanos) throws InterruptedException
/**
 * 跟之前的2个wait方法一样，只不过该方法一直等待，没有超时时间这个概念
 */
public final void wait() throws InterruptedException
/**
 * 实例被垃圾回收器回收的时候触发的操作
 */
protected void finalize() throws Throwable { }

1.7 Hashcode方法详解

hashCode() 有什么用？

hashCode() 的作用是获取哈希码（int 整数），也称为散列码。这个哈希码的作用是确定该对象在哈希表中的索引位置。

hashCode()定义在 JDK 的 Object 类中，这就意味着 Java 中的任何类都包含有 hashCode() 函数。另外需要注意的是： Object 的 hashCode() 方法是本地方法，也就是用 C 语言或 C++ 实现的，该方法通常用来将对象的内存地址转换为整数之后返回。

public native int hashCode();Copy to clipboardErrorCopied

散列表存储的是键值对(key-value)，它的特点是：能根据“键”快速的检索出对应的“值”。这其中就利用到了散列码！（可以快速找到所需要的对象）

为什么要有 hashCode？

我们以“HashSet 如何检查重复”为例子来说明为什么要有 hashCode？

当你把对象加入 HashSet 时，HashSet 会先计算对象的 hashCode 值来判断对象加入的位置，同时也会与其他已经加入的对象的 hashCode 值作比较，如果没有相符的 hashCode，HashSet 会假设对象没有重复出现。但是如果发现有相同 hashCode 值的对象，这时会调用 equals() 方法来检查 hashCode 相等的对象是否真的相同。如果两者相同，HashSet 就不会让其加入操作成功。如果不同的话，就会重新散列到其他位置。这样我们就大大减少了 equals 的次数，相应就大大提高了执行速度。

其实， hashCode() 和 equals()都是用于比较两个对象是否相等。

那为什么 JDK 还要同时提供这两个方法呢？

这是因为在一些容器（比如 HashMap、HashSet）中，有了 hashCode() 之后，判断元素是否在对应容器中的效率会更高（参考添加元素进HashSet的过程）！

我们在前面也提到了添加元素进HashSet的过程，如果 HashSet 在对比的时候，同样的 hashCode 有多个对象，它会继续使用 equals() 来判断是否真的相同。也就是说 hashCode 帮助我们大大缩小了查找成本。

那为什么不只提供 hashCode() 方法呢？

这是因为两个对象的hashCode 值相等并不代表两个对象就相等。

那为什么两个对象有相同的 hashCode 值，它们也不一定是相等的？

因为 hashCode() 所使用的哈希算法也许刚好会让多个对象传回相同的哈希值。越糟糕的哈希算法越容易碰撞，但这也与数据值域分布的特性有关（所谓哈希碰撞也就是指的是不同的对象得到相同的 hashCode )。

总结下来就是 ：

• 如果两个对象的hashCode 值相等，那这两个对象不一定相等（哈希碰撞）。
• 如果两个对象的hashCode 值相等并且equals()方法也返回 true，我们才认为这两个对象相等。
• 如果两个对象的hashCode 值不相等，我们就可以直接认为这两个对象不相等。

相信大家看了我前面对 hashCode() 和 equals() 的介绍之后，下面这个问题已经难不倒你们了。

为什么重写 equals() 时必须重写 hashCode() 方法？

因为两个相等的对象的 hashCode 值必须是相等。也就是说如果 equals 方法判断两个对象是相等的，那这两个对象的 hashCode 值也要相等。

如果重写 equals() 时没有重写 hashCode() 方法的话就可能会导致 equals 方法判断是相等的两个对象，hashCode 值却不相等。

思考 ：重写 equals() 时没有重写 hashCode() 方法的话，使用 HashMap 可能会出现什么问题。

总结 ：

• equals 方法判断两个对象是相等的，那这两个对象的 hashCode 值也要相等。
• 两个对象有相同的 hashCode 值，他们也不一定是相等的（哈希碰撞）。

1.8 String、StringBuffer与StringBuilder的区别

可变性

String 是不可变的（后面会详细分析原因）。

StringBuilder 与 StringBuffer 都继承自 AbstractStringBuilder 类，在 AbstractStringBuilder 中也是使用字符数组保存字符串，不过没有使用 final 和 private 关键字修饰，最关键的是这个 AbstractStringBuilder 类还提供了很多修改字符串的方法比如 append 方法。

线程安全性

String 中的对象是不可变的，也就可以理解为常量，线程安全。AbstractStringBuilder 是 StringBuilder 与 StringBuffer 的公共父类，定义了一些字符串的基本操作，如 expandCapacity、append、insert、indexOf 等公共方法。StringBuffer 对方法加了同步锁或者对调用的方法加了同步锁，所以是线程安全的。StringBuilder 并没有对方法进行加同步锁，所以是非线程安全的。

性能

每次对 String 类型进行改变的时候，都会生成一个新的 String 对象，然后将指针指向新的 String 对象。StringBuffer 每次都会对 StringBuffer 对象本身进行操作，而不是生成新的对象并改变对象引用。相同情况下使用 StringBuilder 相比使用 StringBuffer 仅能获得 10%~15% 左右的性能提升，但却要冒多线程不安全的风险。

对于三者使用的总结：

1. 操作少量的数据: 适用 String
2. 单线程操作字符串缓冲区下操作大量数据: 适用 StringBuilder
3. 多线程操作字符串缓冲区下操作大量数据: 适用 StringBuffer

String 为什么是不可变的?

String 真正不可变有下面几点原因：

1. 保存字符串的数组被 final 修饰且为私有的，并且String 类没有提供/暴露修改这个字符串的方法。
2. String 类被 final 修饰导致其不能被继承，进而避免了子类破坏 String 不可变。

补充：在 Java 9 之后，String 、StringBuilder 与 StringBuffer 的实现改用 byte 数组存储字符串。

原因：新版的 String 其实支持两个编码方案： Latin-1 和 UTF-16。如果字符串中包含的汉字没有超过 Latin-1 可表示范围内的字符，那就会使用 Latin-1 作为编码方案。Latin-1 编码方案下，byte 占一个字节(8 位)，char 占用 2 个字节（16），byte 相较 char 节省一半的内存空间。

1.9 ArrayList、LinkedList、Vector的区别

• ArrayList、Vector 底层是由数组实现，LinkedList 底层是由双向链表实现，从底层的实现可以得出它们的性能问题
• ArrayList、Vector 插入速度相对较慢，查询速度相对较快，而LinkedList 插入速度较快,而查询速度较慢。
• 由于 Vevtor 使用了线程安全锁（很多方法用synchronized修饰），所以ArrayList 的运行效率高于 Vector

1.10 Map、Set、List、Queue、Stack辨析

• Map

键映射到值的对象。一个映射不能包含重复的键；每个键最多只能映射到一个值。
某些映射实现可明确保证其顺序，如 TreeMap 类；另一些映射实现则不保证顺序，如 HashMap 类。
Map中元素，可以将key序列、value序列单独抽取出来。
使用keySet()抽取key序列，将map中的所有keys生成一个Set。
使用values()抽取value序列，将map中的所有values生成一个Collection。
为什么一个生成Set，一个生成Collection？那是因为，key总是独一无二的，value允许重复。

• Set

一个不包含重复元素的 collection。
更确切地讲，set 不包含满足 e1.equals(e2) 的元素对 e1 和 e2，并且最多包含一个 null 元素。
不可随机访问包含的元素
只能用Iterator实现单向遍历
Set 没有同步方法

• List

可随机访问包含的元素
元素是有序的
可在任意位置增、删元素
不管访问多少次，元素位置不变
允许重复元素
用Iterator实现单向遍历，也可用ListIterator实现双向遍历

• Queue

先进先出
Queue使用时要尽量避免Collection的add()和remove()方法，而是要使用offer()来加入元素，使用poll()来获取并移出元素。它们的优点是通过返回值可以判断成功与否，add()和remove()方法在失败的时候会抛出异常。 如果要使用前端而不移出该元素，使用element()或者peek()方法。
值得注意的是LinkedList类实现了Queue接口，因此我们可以把LinkedList当成Queue来用。
Queue 实现通常不允许插入 null 元素，尽管某些实现（如 LinkedList）并不禁止插入 null。即使在允许 null 的实现中，也不应该将 null 插入到 Queue 中，因为 null 也用作 poll 方法的一个特殊返回值，表明队列不包含元素。

• Stack

后进先出
Stack继承自Vector（可增长的对象数组），也是同步的
它通过五个操作对类 Vector 进行了扩展 ，允许将向量视为堆栈。它提供了通常的 push 和 pop 操作，以及取堆栈顶点的 peek 方法、测试堆栈是否为空的 empty 方法、在堆栈中查找项并确定到堆栈顶距离的 search 方法。

用法
如果涉及到堆栈、队列等操作，应该考虑用List；
对于需要快速插入，删除元素，应该使用LinkedList；
如果需要快速随机访问元素，应该使用ArrayList。
如果程序在单线程环境中，或者访问仅仅在一个线程中进行，考虑非同步的类，其效率较高

1.11 HashMap源码分析

HashMap 主要用来存放键值对，它基于哈希表的 Map 接口实现，是常用的 Java 集合之一，是非线程安全的。HashMap是非线程安全的，只是用于单线程环境下，多线程环境下可以采用concurrent并发包下的concurrentHashMap。

HashMap 可以存储 null 的 key 和 value，但 null 作为键只能有一个，null 作为值可以有多个

JDK1.8 之前 HashMap 由 数组+链表 组成的，数组是 HashMap 的主体，链表则是主要为了解决哈希冲突而存在的（“拉链法”解决冲突）。 JDK1.8 以后的 HashMap 在解决哈希冲突时有了较大的变化，当链表长度大于阈值（默认为 8）（将链表转换成红黑树前会判断，如果当前数组的长度小于 64，那么会选择先进行数组扩容（resize方法），而不是转换为红黑树）时，将链表转化为红黑树，以减少搜索时间。

HashMap 默认的初始化大小为 16。之后每次扩充，容量变为原来的 2 倍。并且， HashMap 总是使用 2 的幂作为哈希表的大小。

  HashMap内存储数据的Entry数组默认是16，如果没有对Entry扩容机制的话，当存储的数据一多，Entry内部的链表会很长，这就失去了HashMap的存储意义了。所以HasnMap内部有自己的扩容机制。
  HashMap内部有：
  变量size，它记录HashMap的底层数组中已用槽的数量；
  变量threshold，它是HashMap的阈值，用于判断是否需要调整HashMap的容量（threshold = 容量*加载因子）    
  变量DEFAULT_LOAD_FACTOR = 0.75f，默认加载因子为0.75

  HashMap扩容的条件是：当size大于threshold时，对HashMap进行扩容  
  扩容是是新建了一个HashMap的底层数组，而后调用transfer方法，将就HashMap的全部元素添加到新的HashMap中（要重新计算元素在新的数组中的索引位置）。 很明显，扩容是一个相当耗时的操作，因为它需要重新计算这些元素在新的数组中的位置并进行复制处理。因此，我们在用HashMap的时，最好能提前预估下HashMap中元素的个数，这样有助于提高HashMap的性能。

  HashMap共有四个构造方法。构造方法中提到了两个很重要的参数：初始容量和加载因子。这两个参数是影响HashMap性能的重要参数，其中容量表示哈希表中槽的数量（即哈希数组的长度），初始容量是创建哈希表时的容量（从构造函数中可以看出，如果不指明，则默认为16），加载因子是哈希表在其容量自动增加之前可以达到多满的一种尺度，当哈希表中的条目数超出了加载因子与当前容量的乘积时，则要对该哈希表进行 resize 操作（即扩容）。

  下面说下加载因子，如果加载因子越大，对空间的利用更充分，但是查找效率会降低（链表长度会越来越长）；如果加载因子太小，那么表中的数据将过于稀疏（很多空间还没用，就开始扩容了），对空间造成严重浪费。如果我们在构造方法中不指定，则系统默认加载因子为0.75，这是一个比较理想的值，一般情况下我们是无需修改的。

   另外，无论我们指定的容量为多少，构造方法都会将实际容量设为不小于指定容量的2的次方的一个数，且最大值不能超过2的30次方。

• JDK1.8 HashMap添加元素

① 如果定位到的数组位置没有元素 就直接插入。

② 如果定位到的数组位置有元素就和要插入的 key 比较，如果 key 相同就直接覆盖，如果 key 不相同，就判断 p 是否是一个树节点，如果是就调用e = ((TreeNode<K,V>)p).putTreeVal(this, tab, hash, key, value)将元素添加进入。如果不是就遍历链表插入(插入的是链表尾部)。

• JDK1.7 HashMap添加元素

① 如果定位到的数组位置没有元素 就直接插入。

② 如果定位到的数组位置有元素，遍历以这个元素为头结点的链表，依次和插入的 key 比较，如果 key 相同就直接覆盖，不同就采用头插法插入元素。

1.12 HashMap和HashTable的区别

1、继承的父类不同
HashMap继承自AbstractMap类。但二者都实现了Map接口。
HashTable继承自Dictionary类，Dictionary类是一个已经被废弃的类（见其源码中的注释）。

2、HashMap线程不安全,HashTable线程安全

3、包含的contains方法不同
HashMap是没有contains方法的，而包括containsValue和containsKey方法；HashTable则保留了contains方法，效果同containsValue,还包括containsValue和containsKey方法。

4、是否允许null值
HashMap是允许key和value为null值的，用containsValue和containsKey方法判断是否包含对应键值对；HashTable键值对都不能为空，否则报空指针异常。

5、计算hash值方式不同

为了得到元素的位置，首先需要根据元素的 KEY计算出一个hash值，然后再用这个hash值来计算得到最终的位置。

①：HashMap有个hash方法重新计算了key的hash值,因为hash冲突变高，所以通过一种方法重算hash值的方法：

static final int hash(Object key) {
    int h;
    return (key == null) ? 0 : (h = key.hashCode()) ^ (h >>> 16);
}
// JDK 1.7 的hash方法里面做了四次 >>> 操作，所以性能比这个差

注意这里计算hash值，先调用hashCode方法计算出来一个hash值，再将hash与右移16位后相异或，从而得到新的hash值。
②：Hashtable通过计算key的hashCode()来得到hash值就为最终hash值。

它们计算索引位置方法不同：
HashMap在求hash值对应的位置索引时，index = (n - 1) & hash。将哈希表的大小固定为了2的幂，因为是取模得到索引值，故这样取模时，不需要做除法，只需要做位运算。位运算比除法的效率要高很多。

HashTable在求hash值位置索引时计算index的方法：

int index = (hash & 0x7FFFFFFF) % tab.length;

&0x7FFFFFFF的目的是为了将负的hash值转化为正值，因为hash值有可能为负数，而&0x7FFFFFFF后，只有符号位改变，而后面的位都不变。

6.扩容方式不同（容量不够）
当容量不足时要进行resize方法，而resize的两个步骤：
①扩容；
②rehash:这里HashMap和HashTable都会会重新计算hash值而这里的计算方式就不同了（看5）；
HashMap 哈希扩容必须要求为原容量的2倍，而且一定是2的幂次倍扩容结果，而且每次扩容时，原来数组中的元素依次重新计算存放位置，并重新插入；
而Hashtable扩容为原容量2倍加1，注：在HashTable中， 都是以链表方式存储。

1.13 HashMap和ConcurrentHashMap辨析

• HashMap是线程不安全的，当出现多线程操作时，会出现安全隐患；而ConcurrentHashMap是线程安全的。
• HashMap不支持并发操作，没有同步方法，ConcurrentHashMap支持并发操作，通过继承 ReentrantLock（JDK1.7重入锁）/CAS和synchronized(JDK1.8内置锁)来进行加锁（分段锁），每次需要加锁的操作锁住的是一个 segment，这样只要保证每个 segment 是线程安全的，也就实现了全局的线程安全。

ConcurrentHashMap采用锁分段技术，将整个Hash桶进行了分段segment，也就是将这个大的数组分成了几个小的片段segment，而且每个小的片段segment上面都有锁存在，那么在插入元素的时候就需要先找到应该插入到哪一个片段segment，然后再在这个片段上面进行插入，而且这里还需要获取segment锁。

ConcurrentHashMap让锁的粒度更精细一些，并发性能更好。

1.14 ConcurrentHashMap能完全替代HashTable吗

不能。

ConcurrentHashMap与HashTable都可以用于多线程的环境，但是当Hashtable的大小增加到一定的时候，性能会急剧下降，因为迭代时需要被锁定很长的时间。因为ConcurrentHashMap引入了分割(segmentation)，不论它变得多么大，仅仅需要锁定map的某个部分，而其它的线程不需要等到迭代完成才能访问map。简而言之，在迭代的过程中，ConcurrentHashMap仅仅锁定map的某个部分，而Hashtable则会锁定整个map。

那么既然ConcurrentHashMap那么优秀，为什么还要有Hashtable的存在呢？ConcurrentHashMap能完全替代HashTable吗？

HashTable虽然性能上不如ConcurrentHashMap，但并不能完全被取代，两者的迭代器的一致性不同的，HashTable的迭代器是强一致性的，而ConcurrentHashMap是弱一致的。 ConcurrentHashMap的get，clear，iterator 都是弱一致性的。 Doug Lea 也将这个判断留给用户自己决定是否使用ConcurrentHashMap。

那么什么是强一致性和弱一致性呢？

get方法是弱一致的，是什么含义？可能你期望往ConcurrentHashMap底层数据结构中加入一个元素后，立马能对get可见，但ConcurrentHashMap并不能如你所愿。换句话说，put操作将一个元素加入到底层数据结构后，get可能在某段时间内还看不到这个元素，若不考虑内存模型，单从代码逻辑上来看，却是应该可以看得到的。

正是因为get操作几乎所有时候都是一个无锁操作（get中有一个readValueUnderLock调用，不过这句执行到的几率极小），使得同一个Segment实例上的put和get可以同时进行，这就是get操作是弱一致的根本原因。

1.15 TreeMap、HashMap、LindedHashMap的区别

• Hashmap 是一个最常用的Map,它根据键的HashCode 值存储数据,根据键可以直接获取它的值，具有很快的访问速度，遍历时，取得数据的顺序是完全随机的。HashMap最多只允许一条记录的键为Null;允许多条记录的值为 Null;HashMap不支持线程的同步，即任一时刻可以有多个线程同时写HashMap;可能会导致数据的不一致。如果需要同步，可以用 Collections的synchronizedMap方法使HashMap具有同步的能力，或者使用ConcurrentHashMap。Hashtable与 HashMap类似,它继承自Dictionary类，不同的是:它不允许记录的键或者值为空;它支持线程的同步，即任一时刻只有一个线程能写Hashtable,因此也导致了 Hashtable在写入时会比较慢。

• LinkedHashMap保存了记录的插入顺序，在用Iterator遍历LinkedHashMap时，先得到的记录肯定是先插入的.也可以在构造时用带参数，按照应用次数排序。在遍历的时候会比HashMap慢，不过有种情况例外，当HashMap容量很大，实际数据较少时，遍历起来可能会比LinkedHashMap慢，因为LinkedHashMap的遍历速度只和实际数据有关，和容量无关，而HashMap的遍历速度和他的容量有关。

• TreeMap实现SortMap接口，能够把它保存的记录根据键排序,默认是按键值的升序排序，也可以指定排序的比较器，当用Iterator 遍历TreeMap时，得到的记录是排过序的。

一般情况下，我们用的最多的是HashMap,HashMap里面存入的键值对在取出的时候是随机的,它根据键的HashCode值存储数据,根据键可以直接获取它的值，具有很快的访问速度。在Map 中插入、删除和定位元素，HashMap 是最好的选择。TreeMap取出来的是排序后的键值对。但如果您要按自然顺序或自定义顺序遍历键，那么TreeMap会更好。LinkedHashMap 是HashMap的一个子类，如果需要输出的顺序和输入的相同,那么用LinkedHashMap可以实现,它还可以按读取顺序来排列，像连接池中可以应用。

1.16 Collection与Collections的区别

Collection
是集合类的上级接口，子接口有 Set、List、LinkedList、ArrayList、Vector、Stack、Set；

Collections
是集合类的一个帮助类， 它包含有各种有关集合操作的静态多态方法，用于实现对各种集合的搜索、排序、线程安全化等操作。此类不能实例化，就像一个工具类，服务于Java的Collection框架。

1.17 try-catch-finally 使用

• try块 ： 用于捕获异常。其后可接零个或多个 catch 块，如果没有 catch 块，则必须跟一个 finally 块。

• catch块 ： 用于处理 try 捕获到的异常。

• finally 块 ： 无论是否捕获或处理异常，finally 块里的语句都会被执行。当在 try 块或 catch 块中遇到 return 语句时，finally 语句块将在方法返回之前被执行。

注意：不要在 finally 语句块中使用 return! 当 try 语句和 finally 语句中都有 return 语句时，try 语句块中的 return 语句会被忽略。这是因为 try 语句中的 return 返回值会先被暂存在一个本地变量中，当执行到 finally 语句中的 return 之后，这个本地变量的值就变为了 finally 语句中的 return 返回值。

finally 中的代码不一定会执行

1. 虚拟机停止运行
2. 程序所在的线程死亡
3. 关闭 CPU

1.18 Excption与Error包结构

在 Java 中，所有的异常都有一个共同的祖先 java.lang 包中的 Throwable 类。Throwable 类有两个重要的子类:

• Exception :程序本身可以处理的异常，可以通过 catch 来进行捕获。Exception 又可以分为 Checked Exception (受检查异常，必须处理) 和 Unchecked Exception (不受检查异常，可以不处理)。

  • Checked Exception 即 受检查异常 ，Java 代码在编译过程中，如果受检查异常没有被 catch或者throws 关键字处理的话，就没办法通过编译。除了RuntimeException及其子类以外，其他的Exception类及其子类都属于受检查异常 。常见的受检查异常有： IO 相关的异常、ClassNotFoundException 、SQLException…。

  • Unchecked Exception 即 不受检查异常 ，Java 代码在编译过程中 ，我们即使不处理不受检查异常也可以正常通过编译。

    RuntimeException 及其子类都统称为非受检查异常，常见的有（建议记下来，日常开发中会经常用到）：

    • NullPointerException(空指针错误)
    • IllegalArgumentException(参数错误比如方法入参类型错误)
    • NumberFormatException（字符串转换为数字格式错误，IllegalArgumentException的子类）
    • ArrayIndexOutOfBoundsException（数组越界错误）
    • ClassCastException（类型转换错误）
    • ArithmeticException（算术错误）
    • SecurityException （安全错误比如权限不够）
    • UnsupportedOperationException(不支持的操作错误比如重复创建同一用户)

• Error ：Error 属于程序无法处理的错误 ，不建议通过catch捕获 。例如 Java 虚拟机运行错误（Virtual MachineError）、虚拟机内存不够错误(OutOfMemoryError)、类定义错误（NoClassDefFoundError）等 。这些异常发生时，Java 虚拟机（JVM）一般会选择线程终止。

1.19 Overload与Override

• 区别点	重载方法	重写方法
  发生范围	同一个类	子类
  参数列表	必须修改	一定不能修改
  返回类型	可修改	子类方法返回值类型应比父类方法返回值类型更小或相等
  异常	可修改	子类方法声明抛出的异常类应比父类方法声明抛出的异常类更小或相等；
  访问修饰符	可修改	一定不能做更严格的限制（可以降低限制）
  发生阶段	编译期	运行期

1.20 Interface与abstract类的区别

下面比较一下两者的语法区别：

• 抽象类可以有构造方法，接口中不能有构造方法。
• 抽象类中可以有普通成员变量，接口中没有普通成员变量
• 抽象类中可以包含非抽象的普通方法，接口中的所有方法必须都是抽象的，不能有非抽象的普通方法。
• 抽象类中的抽象方法的访问类型可以是public，protected和默认类型，但接口中的抽象方法只能是public类型的，并且默认即为public abstract类型。
• 抽象类中可以包含静态方法，接口中不能包含静态方法
• 抽象类和接口中都可以包含静态成员变量，抽象类中的静态成员变量的访问类型可以任意，但接口中定义的变量只能是public static final类型，并且默认即为public static final类型。
• 一个类可以实现多个接口，但只能继承一个抽象类。

1.21 静态内部类和普通内部类

java中普通的顶级类是不能使用static关键字修饰的。

只有内部类可以使用static修饰，或者不使用static关键字修饰。

即:

// 顶层类A不能用static修饰
public class A{
   // 普通内部类B, 可以不用static修饰
   public class B{    
   }
   // 普通内部类C, 也可以用static修饰
   public static class C{    
   }
}

普通的内部类(public class)和static内部类(public static class)区别？
1、静态内部类（static修饰的内部类）没有对外部类的引用，所以静态内部类只能访问外部类的静态属性或方法。并且在初始化的时候可以单独存在，例如：

StaticClass staticClass = new StaticClass();

或者：

Users.StaticClass staticClass2 = new Users.StaticClass()

二种方式初始化，建议使用第二种初始化方法，比较清晰。

2、普通内部类有对外部类的引用，所以普通内部类不能独立存在，初始化的时候必须通过外部类的实例。

并且普通内部类可以直接访问外部类的普通属性和函数（包括私有的属性和函数）同时也能访问外部类的静态属性和函数。

普通内部类的实例化如下：

Users.CommonClass commonClass = new Users().new CommonClass();

或者：

Users users = new Users();

Users.CommonClass commonClass2 = users.new CommonClass();

1.22 foreach与正常for循环效率对比

1.23 反射的作用于原理

/*
要操作一个类的字节码，需要首先获取到这个类的字节码，怎么获取java.lang.Class实例？
    三种方式
        第一种：Class c = Class.forName("完整类名带包名");
        第二种：Class c = 对象.getClass();
        第三种：Class c = 任何类型.class;
 */
class ReflectTest01 {
    public static void main(String[] args) throws ClassNotFoundException{
        /*
        第一种方式：Class.forName()
            1、静态方法
            2、方法的参数是一个字符串。
            3、字符串需要的是一个完整类名。
            4、完整类名必须带有包名。java.lang包也不能省略。
         */
        Class c1 = Class.forName("java.lang.String"); // c1代表String.class文件，或者说c1代表String类型。
        Class c2 = Class.forName("java.lang.Integer"); // c2代表Integer类型
        Class c3 = Class.forName("java.util.Date"); // c3代表Date类型


        // 第二种方式：java中任何一个对象都有一个方法：getClass()
        String a = "abc";
        Class c4 = a.getClass(); // c4代表String.class字节码文件；c4代表String类型。
        System.out.println(c4 == c1);//true（==判断的是对象的内存地址。）

        Date time = new Date();
        Class c5 = time.getClass();
        System.out.println(c5 == c3);//true(c5和c3两个变量中保存的内存地址都是一样的，都指向方法区中的字节码文件。)

        // 第三种方式：java语言中任何一种类型，包括基本数据类型，它都有.class属性。
        Class i = Integer.class; //i代表Integer类型
        Class d = Date.class; // d代表Date类型
        Class f = float.class; //f代表float类型

        System.out.println(i == c2);//true
    }
}

/*
获取到Class，能干什么？
    通过Class的newInstance()方法来实例化对象。
    注意：newInstance()方法内部实际上调用了无参数构造方法，必须保证无参构造存在才可以。
 */
class ReflectTest02{
    public static void main(String[] args) throws ClassNotFoundException, InstantiationException, IllegalAccessException {
        // 下面这段代码是以反射机制的方式创建对象。

        // 通过反射机制，获取Class，通过Class来实例化对象
        Class c = Class.forName("javase.reflectBean.User");
        // newInstance() 这个方法会调用User这个类的无参数构造方法，完成对象的创建。
        // 重点是：newInstance()调用的是无参构造，必须保证无参构造是存在的！
        Object obj = c.newInstance();
        System.out.println(obj);
    }
}

/*
验证反射机制的灵活性。
    java代码写一遍，再不改变java源代码的基础之上，可以做到不同对象的实例化。
    非常之灵活。（符合OCP开闭原则：对扩展开放，对修改关闭。）
 */
class ReflectTest03{
    public static void main(String[] args) throws Exception{
        // 以下代码是灵活的，代码不需要改动，可以修改配置文件，配置文件修改之后，可以创建出不同的实例对象。
        // 通过IO流读取reflectClassInfo.properties文件
        FileReader reader = new FileReader("Practice/reflectClassInfo1.properties");
        // 创建属性类对象Map
        Properties pro = new Properties();// key value都是String
        //加载
        pro.load(reader);
        reader.close();

        // 通过key获取value
        String className = pro.getProperty("className");

        // 通过反射机制实例化对象
        Class c = Class.forName(className);
        Object obj = c.newInstance();
        System.out.println(obj);
    }
}

/*
研究一下：Class.forName()发生了什么？
    记住，重点：
        如果你只是希望一个类的静态代码块执行，其它代码一律不执行，
        你可以使用：
            Class.forName("完整类名");
        这个方法的执行会导致类加载，类加载时，静态代码块执行。

提示：
    后面JDBC技术的时候我们还需要。
 */

/*
必须掌握：
    怎么通过反射机制访问一个java对象的属性？
        给属性赋值set
        获取属性的值get
 */
class ReflectTest07{
    public static void main(String[] args) throws Exception {
        //不使用反射机制给属性赋值
        Student student = new Student();
        /**给属性赋值三要素：给s对象的no属性赋值1111
         * 要素1：对象s
         * 要素2：no属性
         * 要素3：1111
         */
        student.no = 1111;
        /**读属性值两个要素：获取s对象的no属性的值。
         * 要素1：对象s
         * 要素2：no属性
         */
        System.out.println(student.no);

        //使用反射机制给属性赋值
        Class studentClass = Class.forName("javase.reflectBean.Student");
        Object obj = studentClass.newInstance();// obj就是Student对象。（底层调用无参数构造方法）

        // 获取no属性（根据属性的名称来获取Field）
        Field noField = studentClass.getDeclaredField("no");
        // 给obj对象(Student对象)的no属性赋值
        /*
            虽然使用了反射机制，但是三要素还是缺一不可：
                要素1：obj对象
                要素2：no属性
                要素3：22222值
            注意：反射机制让代码复杂了，但是为了一个“灵活”，这也是值得的。
         */
        noField.set(obj, 22222);

        // 读取属性的值
        // 两个要素：获取obj对象的no属性的值。
        System.out.println(noField.get(obj));


        // 可以访问私有的属性吗？
        Field nameField = studentClass.getDeclaredField("name");
        // 打破封装（反射机制的缺点：打破封装，可能会给不法分子留下机会！！！）
        // 这样设置完之后，在外部也是可以访问private的。
        nameField.setAccessible(true);
        // 给name属性赋值
        nameField.set(obj, "xiaowu");
        // 获取name属性的值
        System.out.println(nameField.get(obj));
    }
}



/*
重点：必须掌握，通过反射机制怎么调用一个对象的方法？
    五颗星*****

    反射机制，让代码很具有通用性，可变化的内容都是写到配置文件当中，
    将来修改配置文件之后，创建的对象不一样了，调用的方法也不同了，
    但是java代码不需要做任何改动。这就是反射机制的魅力。
 */
class ReflectTest10{
    public static void main(String[] args) throws Exception {
        // 不使用反射机制，怎么调用方法
        // 创建对象
        UserService userService = new UserService();
        // 调用方法
        /*
            要素分析：
                要素1：对象userService
                要素2：login方法名
                要素3：实参列表
                要素4：返回值
         */
        System.out.println(userService.login("admin", "123") ? "登入成功！" : "登入失败！");

        //使用反射机制调用方法
        Class userServiceClass = Class.forName("javase.reflectBean.UserService");
        // 创建对象
        Object obj = userServiceClass.newInstance();
        // 获取Method
        Method loginMethod = userServiceClass.getDeclaredMethod("login", String.class, String.class);
//        Method loginMethod = userServiceClass.getDeclaredMethod("login");//注：没有形参就不传
        // 调用方法
        // 调用方法有几个要素？ 也需要4要素。
        // 反射机制中最最最最最重要的一个方法，必须记住。
        /*
            四要素：
            loginMethod方法
            obj对象
            "admin","123" 实参
            retValue 返回值
         */
        Object resValues = loginMethod.invoke(obj, "admin", "123");//注：方法返回值是void 结果是null
        System.out.println(resValues);
    }
}

/*
重点：给你一个类，怎么获取这个类的父类，已经实现了哪些接口？
 */
class ReflectTest13{
    public static void main(String[] args) throws Exception{
        // String举例
        Class vipClass = Class.forName("java.lang.String");
        // 获取String的父类
        Class superclass = vipClass.getSuperclass();
        // 获取String类实现的所有接口（一个类可以实现多个接口。）
        Class[] interfaces = vipClass.getInterfaces();
        System.out.println(superclass.getName());
        for (Class i : interfaces) {
            System.out.println(i.getName());
        }
    }
}

谈谈反射机制的优缺点

优点 ： 可以让咱们的代码更加灵活、为各种框架提供开箱即用的功能提供了便利

缺点 ：让我们在运行时有了分析操作类的能力，这同样也增加了安全问题。比如可以无视泛型参数的安全检查（泛型参数的安全检查发生在编译时）。另外，反射的性能也要稍差点，不过，对于框架来说实际是影响不大的。

1.24 泛型常用特点及好处

泛型常用特点
泛型是Java SE 1.5之后的特性， 《Java 核心技术》中对泛型的定义是：“泛型” 意味着编写的代码可以被不同类型的对象所重用。
“泛型”，顾名思义，“泛指的类型”。我们提供了泛指的概念，但具体执行的时候却可以有具体的规则来约束，比如我们用的非常多的ArrayList就是个泛型类，ArrayList作为集合可以存放各种元素，如Integer, String，自定义的各种类型等，但在我们使用的时候通过具体的规则来约束，如我们可以约束集合中只存放Integer类型的元素，如

List<Integer> iniData = new ArrayList<>()

使用泛型的好处？
以集合来举例，使用泛型的好处是我们不必因为添加元素类型的不同而定义不同类型的集合，如整型集合类，浮点型集合类，字符串集合类，我们可以定义一个集合来存放整型、浮点型，字符串型数据，而并不是最重要的，因为我们只要把底层存储设置了Object即可，添加的数据全部都可向上转型为Object。 更重要的是我们可以通过规则按照自己的想法控制存储的数据类型。

1.25 JDK1.7~JDK11新特性

JDK1.7

主要特性有：

• 自动资源管理；
• 改进的通用实例创建类型推断；
• 数字字面量下划线支持；
• switch中使用string；
• 二进制字面量；
• 简化可变参数方法调用；
• 引入Java NIO.2开发包。

① 自动资源管理

Java中某些资源是需要手动关闭的，如InputStream，Writes，Sockets，Sql classes等。这个新的语言特性允许try语句本身申请更多的资源， 这些资源作用于try代码块，并自动关闭。

实例如下：

BufferedReader br = new BufferedReader(new FileReader(path)); 
try { 
  return br.readLine(); 
} finally { 
  br.close(); 
}

修改为如下：

 try (BufferedReader br = new BufferedReader(new FileReader(path)) { 
 	return br.readLine(); 
 } 

可以定义关闭多个资源：

try ( 
   InputStream in = new FileInputStream(src); 
   OutputStream out = new FileOutputStream(dest)) 
{ 
// code 
} 

为了支持这个行为，所有可关闭的类将被修改为实现一个Closable（可关闭的）接口。

② 增强的对通用实例创建（diamond）的类型推断
类型推断是一个特殊的烦恼，下面的代码：

Map<String, List<String>> anagrams = new HashMap<String, List<String>>();

通过类型推断后变成：

Map<String, List<String>> anagrams = new HashMap<>();

这个<>被叫做diamond（钻石）运算符，这个运算符从引用的声明中推断类型。

③ 数字字面量下划线支持

很长的数字可读性不好，在Java 7中可以使用下划线分隔长int以及long了，如：

int one_million = 1_000_000;

运算时先去除下划线，如：1_1 * 10 = 110，120 – 1_0 = 110

④ switch中使用string

以前你在switch中只能使用number或enum。现在可以使用string了：

String s = ... 
switch(s) { 
case "quux": 
      processQuux(s); 
case "foo": 
case "bar": 
      processFooOrBar(s); 
      break; 
case "baz": 
	  processBaz(s); 
default: 
      processDefault(s); 
      break; 
} 

⑤ 二进制字面量

由于继承C语言，Java代码在传统上迫使程序员只能使用十进制，八进制或十六进制来表示数(numbers)。

由于很少的域是以bit导向的，这种限制可能导致错误。现在，你可以使用二进制字面量这种表示方式，并且使用非常简短的代码，可将二进制字符转换为数据类型，如在byte或short。

byte aByte = (byte)0b001;    
short aShort = (short)0b010;   
int binary = 0b1001_1001;

⑥ 简化的可变参数调用

当程序员试图使用一个不可具体化的可变参数并调用一个varargs（可变）方法时，编辑器会生成一个“非安全操作”的警告。

JDK 7将警告从call转移到了方法声明(methord declaration)的过程中。这样API设计者就可以使用vararg，因为警告的数量大大减少了。

⑦ NIO

NIO即非阻塞IO，Java NIO（New IO）是从Java 1.4版本开始引入的一个新的IO API，可以替代标准的Java IO API。随着JDK 7 的发布，Java对NIO进行了极大的扩展，增强了对文件处理和文件系统特性的支持，以至于我们称他们为NIO.2。因为NIO 提供的一些功能，NIO已经成为文件处理中越来越重要的部分。

JDK1.8

Java 8 (又称为 jdk 1.8) 是 Java 语言开发的一个主要版本。 Java 8 是oracle公司于2014年3月发布，可以看成是自Java 5 以来最具革命性的版本。Java 8为Java语言、编译器、类库、开发工具与JVM带来了大量新特性。

主要特性有：

• 接口的默认方法

• Lambda 表达式

• 函数式接口

• 方法与构造函数引用

• Lambda 作用域

• 访问局部变量

• 访问对象字段与静态变量

• 访问接口的默认方法

• Date API

• Annotation 注解

JDK1.9

主要特性具体来讲：

• 模块化系统

• 钻石操作符的使用升级

• 语法改进：try语句

• String存储结构变更

• 便利的集合特性：of()

• 增强的Stream API

• 统一的JVM日志系统

• Java的动态编译器

JDK10

根据官网的公开资料，共有12个重要特性，如下：

• 本地变量类型推断
• 统一JDK仓库
• 垃圾回收器接口
• G1的并行Full GC
• 应用程序类数据共享
• ThreadLocal握手机制

JDK11

新特性有：

• HTTP Client 标准化
• ZGC(可伸缩低延迟垃圾收集器)
• Lambda 参数的局部变量语法
• 启动单文件源代码程序
• HTTP Client 标准化

1.26 JNI的使用

JNI是Java Native Interface的缩写，通过使用 Java本地接口书写程序，可以确保代码在不同的平台上方便移植。

主要运用是方法前面添加native关键字

public class CountNum {
    public native int addInt(int num1,int num2);//调用C++ int 相加
    public native double addDouble(double num1,double num2);//调用C++ double 相加
}

步骤：

• 书写Java程序
• 通过Javah命令生成h文件
• 根据h文件，创建cpp项目，把上面h文件导进去
• 编译生成dll文件

1.27 AOP与OOP

AOP为Aspect Oriented Programming的缩写，意为：面向切面编程，通过预编译方式和运行期动态代理实现程序功能的统一维护的一种技术。

AOP与OOP是面向不同领域的两种设计思想。

OOP（面向对象编程）针对业务处理过程的实体及其属性和行为进行抽象封装，以获得更加清晰高效的逻辑单元划分。

AOP则是针对业务处理过程中的切面进行提取，它所面对的是处理过程中的某个步骤或阶段，以获得逻辑过程中各部分之间低耦合性的隔离效果。

我们可以单单从上面的字面上来理解AOP和OOP的话，用下面的理解也不为过：

OOP实际上是对对象的属性和行为的封装，而AOP对于这点就无从谈起，但是AOP是处理某个步骤和阶段的，从中进行切面的提取，也就是说，如果几个或更多个逻辑过程中，有重复的操作行为，AOP就可以提取出来，运用动态代理，实现程序功能的统一维护，这么说来可能太含蓄，如果说到权限判断，日志记录等，可能就明白了。如果我们单纯使用OOP，那么权限判断怎么办？在每个操作前都加入权限判断？日志记录怎么办？在每个方法里的开始、结束、异常的地方手动添加日志？所有，如果使用AOP就可以借助代理完成这些重复的操作，就能够在逻辑过程中，降低各部分之间的耦合了。二者扬长补短，互相结合最好。

下面详细了解一些AOP的概念：

• 方面（Aspect）：一个关注点的模块化，这个关注点实现可能另外横切多个对象。事务管理是J2EE应用中一个很好的横切关注点例子。方面用Spring的Advisor或拦截器实现。
• 连接点（Joinpoint）：程序执行过程中明确的点，如方法的调用或特定的异常被抛出。
• 通知（Advice）：在特定的连接点，AOP框架执行的动作。各种类型的通知包括“around”、“before”和“throws”通知。通知类型将在下面讨论。许多AOP框架包括Spring都是以拦截器做通知模型，维护一个“围绕”连接点的拦截器链。
• 切入点（Pointcut）：指定一个通知将被引发的一系列连接点的集合。AOP框架必须允许开发者指定切入点，例如，使用正则表达式。
• 引入（Introduction）：添加方法或字段到被通知的类。Spring允许引入新的接口到任何被通知的对象。例如，你可以使用一个引入使任何对象实现IsModified接口，来简化缓存。
• 目标对象（Target Object）：包含连接点的对象，也被称作被通知或被代理对象。
• AOP代理（AOP Proxy）：AOP框架创建的对象，包含通知。在Spring中，AOP代理可以是JDK动态代理或CGLIB代理。
• 编织（Weaving）：组装方面来创建一个被通知对象。这可以在编译时完成（例如使用AspectJ编译器），也可以在运行时完成。Spring和其他纯Java AOP框架一样，在运行时完成织入。

Spring 中 AOP 代理由 Spring 的 IoC 容器负责生成、管理，其依赖关系也由 IoC 容器负责管理。

2.JVM

2.1 Java运行时数据区域

线程私有的：

• 程序计数器

• 虚拟机栈

• 本地方法栈

线程共享的：

• 堆

• 方法区（JDK1.8以后用元空间替代了方法区）

• 直接内存 (非运行时数据区的一部分)

---

①程序计数器

• 对PC寄存器的一种模拟
• 是一小块高速内存空间，可以看作是当前线程所执行的字节码的行号指示器
• 分支、循环、跳转、异常处理、线程恢复等功能都需要依赖这个计数器来完成
• 唯一一个没有定义OOM（OutOfMemoryError）的区域，它的生命周期随着线程的创建而创建，随着线程的结束而死亡。

②虚拟机栈

• Java方法执行的线程内存模型，除了一些 Native 方法调用是通过本地方法栈实现的(后面会提到)，其他所有的 Java 方法调用都是通过虚拟机栈来实现的
• 生命周期同线程
• 不存在垃圾回收问题
• 堆栈中的栈就是指的虚拟机栈的局部变量表部分
• Java 方法有两种返回方式，一种是 return 语句正常返回，一种是抛出异常。不管哪种返回方式，都会导致栈帧被弹出。也就是说， 栈帧随着方法调用而创建，随着方法结束而销毁。无论方法正常完成还是异常完成都算作方法结束。
• 基本单位为栈帧
  • 局部变量表（存放了编译期可知的各种数据类型、对象引用）
  • 操作数栈（主要用于存放方法执行过程中产生的中间计算结果和产生的临时变量）
  • 动态连接（主要用于一个方法调用其他方法，将符号引用转换为调用方法的直接引用）
  • 返回地址
• 异常
  • StackOverFlowError
    • 不允许动态扩展栈大小，而超过栈的最大大小时
  • OutOfMemoryError
    • 允许动态扩展，但是内存不够时

③本地方法栈

• 类似于虚拟机栈，服务于C语言写的本地函数（Native方法）
• Hotspot中，本地方法栈和虚拟机栈合二为一
• 异常（同虚拟机栈）
  • StackOverFlowError
  • OutOfMemoryError

④堆

• 存放对象实例

• 堆是垃圾收集器管理的主要区域，因此也被称作 GC 堆

• 几乎所有的Java对象在堆中分配

  • 例外
    • 基于逃逸分析的优化，如栈上分配、标量替换
  • 补充知识：基于逃逸分析的优化
    • 标量替换：对象不会被外部访问，并且可以进一步分解时，就不会创建该对象，而是用成员变量替换，这些成员变量会在栈帧或者寄存器上分配空间
    • 栈上分配：某些方法中的对象引用没有被返回或者未被外面使用（也就是未逃逸出去）可能被优化成栈上分配。另外这样的一个好处是不用垃圾回收了

• 堆可细分为

  • JDK1.8之前：新生代（Eden–>S0、S1）–>老年代–>永久代
  • JDK1.8之后：新生代（Eden–>S0、S1）–>老年代–>元空间
    • 注：元空间不是使用堆内存而是使用直接内存

  大部分情况，对象都会首先在 Eden 区域分配，在一次新生代垃圾回收后，如果对象还存活，则会进入 S0 或者 S1，并且对象的年龄还会加 1(Eden 区->Survivor 区后对象的初始年龄变为 1)，当它的年龄增加到一定程度（默认为 15 岁），就会被晋升到老年代中。对象晋升到老年代的年龄阈值，需要计算。可以通过参数 -XX:MaxTenuringThreshold 来设置。

  注：Hotspot 遍历所有对象时，按照年龄从小到大对其所占用的大小进行累积，当累积的某个年龄大小超过了 survivor 区的一半时，取这个年龄和 MaxTenuringThreshold 中更小的一个值，作为新的晋升年龄阈值

• 异常

  • java.lang.OutOfMemoryError: GC Overhead Limit Exceeded ： 当 JVM 花太多时间执行垃圾回收并且只能回收很少的堆空间时，就会发生此错误。
  • java.lang.OutOfMemoryError: Java heap space ：假如在创建新的对象时, 堆内存中的空间不足以存放新创建的对象, 就会引发此错误。(和配置的最大堆内存有关，且受制于物理内存大小。最大堆内存可通过-Xmx参数配置，若没有特别配置，将会使用默认值）

⑤方法区

• 注意：《Java 虚拟机规范》只是规定了有方法区这么个概念和它的作用，方法区到底要如何实现那就是虚拟机自己要考虑的事情了。也就是说，在不同的虚拟机实现上，方法区的实现是不同的

• 包含虚拟机加载的类的元数据与一些缓存数据：类信息、字段信息、方法信息、常量、静态变量、JIT代码缓存、运行时常量池（后面单独讲）

• 方法区和永久代、元空间的关系可以看成接口与类的关系，即永久代以及元空间是 HotSpot 虚拟机对虚拟机规范中方法区的两种实现方式

• 为什么要将永久代 (PermGen) 替换为元空间 (MetaSpace) 呢?

  • 整个永久代有一个 JVM 本身设置的固定大小上限，无法进行调整，而元空间使用的是直接内存，受本机可用内存的限制，虽然元空间仍旧可能溢出，但是比原来出现的几率会更小。注：当元空间溢出时会得到如下错误： java.lang.OutOfMemoryError: MetaSpace
  • 元空间里面存放的是类的元数据，这样加载多少类的元数据就不由 MaxPermSize 控制了, 而由系统的实际可用空间来控制，这样能加载的类就更多了。
  • 在 JDK8，合并 HotSpot 和 JRockit 的代码时, JRockit 从来没有一个叫永久代的东西, 合并之后就没有必要额外的设置这么一个永久代的地方了

• 运行时常量池

  • 运行时常量池的功能类似于传统编程语言的符号表，尽管它包含了比典型符号表更广泛的数据。 既然运行时常量池是方法区的一部分，自然受到方法区内存的限制，当常量池无法再申请到内存时会抛出 OutOfMemoryError 错误。

• 字符串常量池

  • 字符串常量池 是 JVM 为了提升性能和减少内存消耗针对字符串（String 类）专门开辟的一块区域，主要目的是为了避免字符串的重复创建。HotSpot 虚拟机中字符串常量池的实现是 src/hotspot/share/classfile/stringTable.cpp ,StringTable 本质上就是一个HashSet<String> 。**StringTable 中保存的是字符串对象的引用，字符串对象的引用指向堆中的字符串对象。**JDK1.7 之前，字符串常量池存放在永久代。JDK1.7 字符串常量池和静态变量从永久代移动了 Java 堆中。

    JDK 1.7 为什么要将字符串常量池移动到堆中？

    主要是因为永久代（方法区实现）的 GC 回收效率太低，只有在整堆收集 (Full GC)的时候才会被执行 GC。Java 程序中通常会有大量的被创建的字符串等待回收，将字符串常量池放到堆中，能够更高效及时地回收字符串内存。

⑥ 直接内存

• 一些Java类如NIO会用直接内存作为Buffer提高性能

• NIO：基于通道与缓冲区的IO方式，使用Naive函数直接分配堆外内存，然后通过Java堆里的DirectByteBuffer对象作为这块内存的引用直接进行操作。避免了Java堆和Naive堆之间的复制。

• 比较

  • 堆与栈

    • 堆为存储服务
    • 栈为运行服务

  • 元空间与永久代

    • 都是方法区的实现
      • 1.7：永久代，占用JVM内存
      • 1.8：元空间，直接使用物理内存
    • 1.7 vs 1.8
      • 1.7：有永久代，类变量和字符串常量池拿到堆中
      • 1.8：用元空间替换永久代，原因：永久代占用JVM内存，难以设置大小和调优
        • 位置调整
          • 字符串常量池、类变量（静态变量）调整到堆中
          • 类信息、常量保存在本地内存的元空间中

2.2 对象的创建

Step1：类加载检查

虚拟机遇到一条 new 指令时，首先将去检查这个指令的参数是否能在常量池中定位到这个类的符号引用，并且检查这个符号引用代表的类是否已被加载过、解析和初始化过。如果没有，那必须先执行相应的类加载过程。

Step2：分配内存

在类加载检查通过后，接下来虚拟机将为新生对象分配内存。对象所需的内存大小在类加载完成后便可确定，为对象分配空间的任务等同于把一块确定大小的内存从 Java 堆中划分出来。分配方式有 “指针碰撞” 和 “空闲列表” 两种，选择哪种分配方式由 Java 堆是否规整决定，而 Java 堆是否规整又由所采用的垃圾收集器是否带有压缩整理功能决定。

内存分配的两种方式 （需要掌握）：

• 指针碰撞：
  • 适用场合 ：堆内存规整（即没有内存碎片）的情况下。
  • 原理 ：用过的内存全部整合到一边，没有用过的内存放在另一边，中间有一个分界指针，只需要向着没用过的内存方向将该指针移动对象内存大小位置即可。
  • 使用该分配方式的 GC 收集器：Serial, ParNew
• 空闲列表 ：
  • 适用场合 ： 堆内存不规整的情况下。
  • 原理 ：虚拟机会维护一个列表，该列表中会记录哪些内存块是可用的，在分配的时候，找一块儿足够大的内存块儿来划分给对象实例，最后更新列表记录。
  • 使用该分配方式的 GC 收集器：CMS

选择以上两种方式中的哪一种，取决于 Java 堆内存是否规整。而 Java 堆内存是否规整，取决于 GC 收集器的算法是"标记-清除"，还是"标记-整理"（也称作"标记-压缩"），值得注意的是，复制算法内存也是规整的。

内存分配并发问题（需要掌握）

在创建对象的时候有一个很重要的问题，就是线程安全，因为在实际开发过程中，创建对象是很频繁的事情，作为虚拟机来说，必须要保证线程是安全的，通常来讲，虚拟机采用两种方式来保证线程安全：

• CAS+失败重试： CAS 是乐观锁的一种实现方式。所谓乐观锁就是，每次不加锁而是假设没有冲突而去完成某项操作，如果因为冲突失败就重试，直到成功为止。虚拟机采用 CAS 配上失败重试的方式保证更新操作的原子性。
• TLAB： 为每一个线程预先在 Eden 区分配一块儿内存，JVM 在给线程中的对象分配内存时，首先在 TLAB 分配，当对象大于 TLAB 中的剩余内存或 TLAB 的内存已用尽时，再采用上述的 CAS 进行内存分配

Step3：初始化零值

内存分配完成后，虚拟机需要将分配到的内存空间都初始化为零值（不包括对象头），这一步操作保证了对象的实例字段在 Java 代码中可以不赋初始值就直接使用，程序能访问到这些字段的数据类型所对应的零值。

Step4：设置对象头

初始化零值完成之后，虚拟机要对对象进行必要的设置，例如这个对象是哪个类的实例、如何才能找到类的元数据信息、对象的哈希码、对象的 GC 分代年龄等信息。 这些信息存放在对象头中。 另外，根据虚拟机当前运行状态的不同，如是否启用偏向锁等，对象头会有不同的设置方式。

Step5：执行init方法

在上面工作都完成之后，从虚拟机的视角来看，一个新的对象已经产生了，但从 Java 程序的视角来看，对象创建才刚开始，<init> 方法还没有执行，所有的字段都还为零。所以一般来说，执行 new 指令之后会接着执行 <init> 方法，把对象按照程序员的意愿进行初始化，这样一个真正可用的对象才算完全产生出来。

2.3 对象的内存布局

在 Hotspot 虚拟机中，对象在内存中的布局可以分为 3 块区域：对象头、实例数据和对齐填充。

Hotspot 虚拟机的对象头包括两部分信息，第一部分用于存储对象自身的运行时数据（哈希码、GC 分代年龄、锁状态标志等等），另一部分是类型指针，即对象指向它的类元数据的指针，虚拟机通过这个指针来确定这个对象是哪个类的实例。

实例数据部分是对象真正存储的有效信息，也是在程序中所定义的各种类型的字段内容。

对齐填充部分不是必然存在的，也没有什么特别的含义，仅仅起占位作用。 因为 Hotspot 虚拟机的自动内存管理系统要求对象起始地址必须是 8 字节的整数倍，换句话说就是对象的大小必须是 8 字节的整数倍。而对象头部分正好是 8 字节的倍数（1 倍或 2 倍），因此，当对象实例数据部分没有对齐时，就需要通过对齐填充来补全。

2.4 垃圾回收详解

2.4.1 如何判断对象是否死亡

①引用计数法

给对象中添加一个引用计数器：

• 每当有一个地方引用它，计数器就加 1；
• 当引用失效，计数器就减 1；
• 任何时候计数器为 0 的对象就是不可能再被使用的。

这个方法实现简单，效率高，但是目前主流的虚拟机中并没有选择这个算法来管理内存，其最主要的原因是它很难解决对象之间相互循环引用的问题，即A引用B，B引用A，那么他们引用计数器不为0，不会被回收

②可达性分析

这个算法的基本思想就是通过一系列的称为 “GC Roots” 的对象作为起点，从这些节点开始向下搜索，节点所走过的路径称为引用链，当一个对象到 GC Roots 没有任何引用链相连的话，则证明此对象是不可用的，需要被回收。

哪些对象可以作为 GC Roots 呢？

• 虚拟机栈(栈帧中的本地变量表)中引用的对象
• 本地方法栈(Native 方法)中引用的对象
• 方法区中类静态属性引用的对象
• 方法区中常量引用的对象
• 所有被同步锁持有的对象

对象可以被回收，就代表一定会被回收吗？

即使在可达性分析法中不可达的对象，也并非是“非死不可”的，这时候它们暂时处于“缓刑阶段”，要真正宣告一个对象死亡，还要经历标记过程（finalize方法已被废弃）

2.4.2 四种不同引用

1．强引用（StrongReference）

以前我们使用的大部分引用实际上都是强引用，这是使用最普遍的引用。如果一个对象具有强引用，垃圾回收器绝不会回收它。当内存空间不足，Java 虚拟机宁愿抛出 OutOfMemoryError 错误，使程序异常终止，也不会靠随意回收具有强引用的对象来解决内存不足问题。

2．软引用（SoftReference）

如果一个对象只具有软引用，如果内存空间足够，垃圾回收器就不会回收它，如果内存空间不足了，就会回收这些对象的内存。只要垃圾回收器没有回收它，该对象就可以被程序使用。软引用可用来实现内存敏感的高速缓存。

软引用可以和一个引用队列（ReferenceQueue）联合使用，如果软引用所引用的对象被垃圾回收，JAVA 虚拟机就会把这个软引用加入到与之关联的引用队列中。

3．弱引用（WeakReference）

弱引用与软引用的区别在于：只具有弱引用的对象拥有更短暂的生命周期。在垃圾回收器线程扫描它所管辖的内存区域的过程中，一旦发现了只具有弱引用的对象，不管当前内存空间足够与否，都会回收它的内存。不过，由于垃圾回收器是一个优先级很低的线程， 因此不一定会很快发现那些只具有弱引用的对象。

弱引用可以和一个引用队列（ReferenceQueue）联合使用，如果弱引用所引用的对象被垃圾回收，Java 虚拟机就会把这个弱引用加入到与之关联的引用队列中。

4．虚引用（PhantomReference）

"虚引用"顾名思义，就是形同虚设，与其他几种引用都不同，虚引用并不会决定对象的生命周期。如果一个对象仅持有虚引用，那么它就和没有任何引用一样，在任何时候都可能被垃圾回收。

虚引用主要用来跟踪对象被垃圾回收的活动。

虚引用与软引用和弱引用的一个区别在于： 虚引用必须和引用队列（ReferenceQueue）联合使用。当垃圾回收器准备回收一个对象时，如果发现它还有虚引用，就会在回收对象的内存之前，把这个虚引用加入到与之关联的引用队列中。程序可以通过判断引用队列中是否已经加入了虚引用，来了解被引用的对象是否将要被垃圾回收。程序如果发现某个虚引用已经被加入到引用队列，那么就可以在所引用的对象的内存被回收之前采取必要的行动。

特别注意，在程序设计中一般很少使用弱引用与虚引用，使用软引用的情况较多，这是因为软引用可以加速 JVM 对垃圾内存的回收速度，可以维护系统的运行安全，防止内存溢出（OutOfMemory）等问题的产生。

2.4.3 判断一个常量是否废弃

假如在字符串常量池中存在字符串 “abc”，如果当前没有任何 String 对象引用该字符串常量的话，就说明常量 “abc” 就是废弃常量，如果这时发生内存回收的话而且有必要的话，“abc” 就会被系统清理出常量池了。

注：

• JDK1.7 之前运行时常量池逻辑包含字符串常量池存放在方法区, 此时 hotspot 虚拟机对方法区的实现为永久代
• JDK1.7 字符串常量池被从方法区拿到了堆中, 这里没有提到运行时常量池,也就是说字符串常量池被单独拿到堆,运行时常量池剩下的东西还在方法区, 也就是 hotspot 中的永久代 。
• JDK1.8 hotspot 移除了永久代用元空间(MetaSpace)取而代之, 这时候字符串常量池还在堆, 运行时常量池还在方法区, 只不过方法区的实现从永久代变成了元空间(MetaSpace)

2.4.4 判断一个类是无用的

类需要同时满足下面 3 个条件才能算是 “无用的类” ：

• 该类所有的实例都已经被回收，也就是 Java 堆中不存在该类的任何实例。
• 加载该类的 ClassLoader 已经被回收。
• 该类对应的 java.lang.Class 对象没有在任何地方被引用，无法在任何地方通过反射访问该类的方法。

虚拟机可以对满足上述 3 个条件的无用类进行回收，这里说的仅仅是“可以”，而并不是和对象一样不使用了就会必然被回收。

2.4.5 垃圾收集算法

① 标记-清除

该算法分为“标记”和“清除”阶段：首先标记出所有不需要回收的对象，在标记完成后统一回收掉所有没有被标记的对象。它是最基础的收集算法，后续的算法都是对其不足进行改进得到。这种垃圾收集算法会带来两个明显的问题：

1. 效率问题
2. 空间问题（标记清除后会产生大量不连续的碎片）

② 标记-复制

此算法将内存分为大小相同的两块，每次使用其中的一块。当这一块的内存使用完后，就将还存活的对象复制到另一块去，然后再把使用的空间一次清理掉。这样就使每次的内存回收都是对内存区间的一半进行回收，效率更高。

③ 标记-整理

根据老年代的特点提出的一种标记算法，标记过程仍然与“标记-清除”算法一样，但后续步骤不是直接对可回收对象回收，而是让所有存活的对象向一端移动，然后直接清理掉端边界以外的内存。

注意：当前虚拟机的垃圾收集都采用分代收集算法，这种算法没有什么新的思想，只是根据对象存活周期的不同将内存分为几块。一般将 java 堆分为新生代和老年代，这样我们就可以根据各个年代的特点选择合适的垃圾收集算法。

比如在新生代中，每次收集都会有大量对象死去，所以可以选择”标记-复制“算法，只需要付出少量对象的复制成本就可以完成每次垃圾收集。而老年代的对象存活几率是比较高的，而且没有额外的空间对它进行分配担保，所以我们必须选择“标记-清除”或“标记-整理”算法进行垃圾收集。

2.4.6 HotSpot为什么要分新生代和老年代

考虑上面垃圾收集算法的效率问题

2.4.7 常见垃圾收集器

①Serial 收集器

Serial（串行）收集器是最基本、历史最悠久的垃圾收集器了。大家看名字就知道这个收集器是一个单线程收集器了。它的 “单线程” 的意义不仅仅意味着它只会使用一条垃圾收集线程去完成垃圾收集工作，更重要的是它在进行垃圾收集工作的时候必须暂停其他所有的工作线程（ “Stop The World” ），直到它收集结束。

新生代采用标记-复制算法，老年代采用标记-整理算法。

②ParNew 收集器

ParNew 收集器其实就是 Serial 收集器的多线程版本，除了使用多线程进行垃圾收集外，其余行为（控制参数、收集算法、回收策略等等）和 Serial 收集器完全一样。

新生代采用标记-复制算法，老年代采用标记-整理算法。

③Parallel Scavenge 收集器

JDK1.8 默认收集器

Parallel Scavenge 收集器关注点是吞吐量（高效率的利用 CPU）。CMS 等垃圾收集器的关注点更多的是用户线程的停顿时间（提高用户体验）。所谓吞吐量就是 CPU 中用于运行用户代码的时间与 CPU 总消耗时间的比值。 Parallel Scavenge 收集器提供了很多参数供用户找到最合适的停顿时间或最大吞吐量，如果对于收集器运作不太了解，手工优化存在困难的时候，使用 Parallel Scavenge 收集器配合自适应调节策略，把内存管理优化交给虚拟机去完成也是一个不错的选择。

新生代采用标记-复制算法，老年代采用标记-整理算法。

④Serial Old 收集器

Serial 收集器的老年代版本，它同样是一个单线程收集器。它主要有两大用途：一种用途是在 JDK1.5 以及以前的版本中与 Parallel Scavenge 收集器搭配使用，另一种用途是作为 CMS 收集器的后备方案。

⑤Parallel Old 收集器

Parallel Scavenge 收集器的老年代版本。使用多线程和“标记-整理”算法。在注重吞吐量以及 CPU 资源的场合，都可以优先考虑 Parallel Scavenge 收集器和 Parallel Old 收集器。

⑥CMS 收集器

CMS（Concurrent Mark Sweep）收集器是一种以获取最短回收停顿时间为目标的收集器。它非常符合在注重用户体验的应用上使用。

CMS（Concurrent Mark Sweep）收集器是 HotSpot 虚拟机第一款真正意义上的并发收集器，它第一次实现了让垃圾收集线程与用户线程（基本上）同时工作。

从名字中的Mark Sweep这两个词可以看出，CMS 收集器是一种 “标记-清除”算法实现的，它的运作过程相比于前面几种垃圾收集器来说更加复杂一些。整个过程分为四个步骤：

• 初始标记： 暂停所有的其他线程，并记录下直接与 root 相连的对象，速度很快 ；
• 并发标记： 同时开启 GC 和用户线程，用一个闭包结构去记录可达对象。但在这个阶段结束，这个闭包结构并不能保证包含当前所有的可达对象。因为用户线程可能会不断的更新引用域，所以 GC 线程无法保证可达性分析的实时性。所以这个算法里会跟踪记录这些发生引用更新的地方。
• 重新标记： 重新标记阶段就是为了修正并发标记期间因为用户程序继续运行而导致标记产生变动的那一部分对象的标记记录，这个阶段的停顿时间一般会比初始标记阶段的时间稍长，远远比并发标记阶段时间短
• 并发清除： 开启用户线程，同时 GC 线程开始对未标记的区域做清扫。

从它的名字就可以看出它是一款优秀的垃圾收集器，主要优点：并发收集、低停顿。但是它有下面三个明显的缺点：

• 对 CPU 资源敏感；
• 无法处理浮动垃圾，在并发进行清除时，工作线程还会不断产生垃圾，也就是浮动垃圾，当 CMS 垃圾回收速度无法跟上浮动垃圾产生速度时，会导致并发失败，采用 Serial old 的方式回收，大大降低效率。
• 它使用的回收算法-“标记-清除”算法会导致收集结束时会有大量空间碎片产生。内存碎片可能导致老年代明明有空间却提前触发FullGC。

⑦G1 收集器

G1 (Garbage-First) 是一款面向服务器的垃圾收集器。

被视为 JDK1.7 中 HotSpot 虚拟机的一个重要进化特征。它具备以下特点：

• 并行与并发：利用 CPU、多核环境下的硬件优势，缩短 Stop-The-World 停顿时间。
• 分代收集：虽然 G1 可以不需要其他收集器配合就能独立管理整个 GC 堆，但是还是保留了分代的概念。
• 空间整合：与 CMS 的“标记-清理”算法不同，G1 从整体来看是基于“标记-整理”算法实现的收集器；从局部上来看是基于“标记-复制”算法实现的。
• 可预测的停顿：建立可预测的停顿时间模型，能让使用者明确指定在一个长度为 M 毫秒的时间片段内。

G1 收集器的运作大致分为以下几个步骤：

• 初始标记
• 并发标记
• 最终标记
• 筛选回收

上述四个步骤除了并发标记都需要STW。

将内存划分为许多相同大小的单元，称为Region。

新生代和老年代编程逻辑划分，表示一系列region的集合。

对于大对象有专门的Region也就是H Region存放，用连续的多个H区存放大对象。

G1 收集器在后台维护了一个优先列表，每次根据允许的收集时间，优先选择回收价值最大的 Region(这也就是它的名字 Garbage-First 的由来) 。这种使用 Region 划分内存空间以及有优先级的区域回收方式，保证了 G1 收集器在有限时间内可以尽可能高的收集效率（把内存化整为零）。

⑧ZGC 收集器（JDK11）

新型垃圾回收期，相比于G1，区别在于Region是动态大小的且可以动态创建销毁。

选择

1. 旧JDK版本选择G1或者CMS，其中，内存小就用CMS，内存大就用G1。
2. 新JDK版本可以尝试ZGC，一些新特性可能依赖Linux内核。

⑨Shenandoah（JDK17）

在Shenandoah GC之前的所有垃圾回收器都必须主动或者被动地整理老年代或者新生代，因此会导致长时间的STW，对于大型的堆，比如超过100GB，所有现存的垃圾回收器几乎都表现得很差。为了解决这些问题，Red Hat开发了一个低停顿的并发垃圾回收器，没有分代机制，Shenandoah GC的STW时间不会随堆的增大而线性增长。

2.4.8 Minor GC和Full GC

Minor GC 和 Full GC 有什么不同呢？

• Minor GC：只收集新生代的GC

• Full GC: 收集整个堆，包括新生代，老年代，永久代(在 JDK 1.8及以后，永久代被移除，换为metaspace 元空间)等所有部分的模式。

Minor GC触发条件：当Eden区满时，触发Minor GC。

Full GC触发条件：

• 调用System.gc();
• 老年代空间不足。
• 空间分配担保失败。
• JDK 1.7 及以前的永久代内存不足
• CMS 由于浮动垃圾导致并发失败

2.5 类加载过程

1. 加载：通过类的全限定名加载类的字节码，然后将字节码中的类静态存储数据转换为运行时的内存数据结构，并且在堆中生成该类的class对象，作为对该类在方法区中数据的访问的接口。

2. 验证：验证class文件是否符合规范。

3. 准备：在堆中为类变量分配内存空间，并且初始化零值。如果类变量用static final 修饰，会用类字段属性表中的constant_value属性赋值。

4. 解析：将类中的部分符号引用转换为直接引用。（解析调用，对象：非虚方法）。

5. 初始化：开始执行类中编写的Java代码块中的类初始化部分。

6. 使用

7. 卸载

   注：其中2、3、4三步可以简称为连接

触发类加载的条件：

1. 创建类的实例时
2. 访问类的静态方法或静态变量的时候
3. 使用Class.forName反射类的时候
4. 某个子类初始化的时候

卸载：

Java自带的加载器加载的类,在虚拟机的生命周期中是不会被卸载的,只有用户自定义的加载器加载的类才可以被卸载。

2.6 类加载器

加载器作用是将 .class文件加载到内存，通过类名来获取二进制字节流。自顶向下分为四种加载器，启动类（顶层c++实现）->扩展类->应用类（当前应用 classpath 下的所有 jar 包和类）->自定义类。注：数组类型不通过类加载器创建，它由 Java 虚拟机直接创建。

双亲委派模型

概念：

在类加载的时候，系统会首先判断当前类是否被加载过。已经被加载的类会直接返回，否则才会尝试加载。加载的时候，首先会把该请求委派给父类加载器的 loadClass() 处理，因此所有的请求最终都应该传送到顶层的启动类加载器 BootstrapClassLoader 中。当父类加载器无法处理时，才由自己来处理。当父类加载器为 null 时，会使用启动类加载器 BootstrapClassLoader 作为父类加载器。

好处：

双亲委派模型保证了 Java 程序的稳定运行，可以避免类的重复加载（JVM 区分不同类的方式不仅仅根据类名，相同的类文件被不同的类加载器加载产生的是两个不同的类），也保证了 Java 的核心 API 不被篡改。如果没有使用双亲委派模型，而是每个类加载器加载自己的话就会出现一些问题，比如我们编写一个称为 java.lang.Object 类的话，那么程序运行的时候，系统就会出现多个不同的 Object 类。

自定义加载器

自定义加载器的话，需要继承 ClassLoader 。如果我们不想打破双亲委派模型，就重写 ClassLoader 类中的 findClass() 方法即可，无法被父类加载器加载的类最终会通过这个方法被加载。但是，如果想打破双亲委派模型则需要重写 loadClass() 方法

Q.E.D.