Java基础部分

1、面向对象的三个特征?五个基本原则?

封装，继承，多态。
所谓封装：
也就是把客观事物封装成抽象的类，并且类可以把自己的数据和方法只让可信的类或者对象操作，对不可信的进行信息隐藏。封装是面向对象的特征之一，是对象和类概念的主要特性。简单的说，一个类就是一个封装了数据以及操作这些数据的代码的逻辑实体。在一个对象内部，某些代码或某些数据可以是私有的，不能被外界访问。通过这种方式，对象对内部数据提供了不同级别的保护，以防止程序中无关的部分意外的改变或错误的使用了对象的私有部分。
所谓继承：
是指可以让某个类型的对象获得另一个类型的对象的属性的方法。它支持按级分类的概念。继承是指这样一种能力：它可以使用现有类的所有功能，并在无需重新编写原来的类的情况下对这些功能进行扩展。通过继承创建的新类称为“子类”或“派生类”，被继承的类称为“基类”、“父类”或“超类”。继承的过程，就是从一般到特殊的过程。要实现继承，可以通过“继承”（Inheritance）和“组合”（Composition）来实现。继承概念的实现方式有二类：实现继承与接口继承。实现继承是指直接使用基类的属性和方法而无需额外编码的能力；接口继承是指仅使用属性和方法的名称、但是子类必须提供实现的能力；
所谓多态：
就是指一个类实例的相同方法在不同情形有不同表现形式。多态机制使具有不同内部结构的对象可以共享相同的外部接口。这意味着，虽然针对不同对象的具体操作不同，但通过一个公共的类，它们（那些操作）可以通过相同的方式予以调用。

五大基本原则
1、单一职责原则SRP(Single Responsibility Principle)
是指一个类的功能要单一，不能包罗万象。如同一个人一样，分配的工作不能太多，否则一天到晚虽然忙忙碌碌的，但效率却高不起来。
2、开放封闭原则OCP(Open－Close Principle)
一个模块在扩展性方面应该是开放的而在更改性方面应该是封闭的。比如：一个网络模块，原来只服务端功能，而现在要加入客户端功能，那么应当在不用修改服务端功能代码的前提下，就能够增加客户端功能的实现代码，这要求在设计之初，就应当将服务端和客户端分开，公共部分抽象出来。
3、里氏替换原则(the Liskov Substitution Principle LSP)
子类应当可以替换父类并出现在父类能够出现的任何地方。比如：公司搞年度晚会，所有员工可以参加抽奖，那么不管是老员工还是新员工，也不管是总部员工还是外派员工，都应当可以参加抽奖，否则这公司就不和谐了。
4、依赖倒置原则(the Dependency Inversion Principle DIP)
具体依赖抽象，上层依赖下层。假设B是较A低的模块，但B需要使用到A的功能，这个时候，B不应当直接使用A中的具体类：而应当由B定义一抽象接口，并由A来实现这个抽象接口，B只使用这个抽象接口：这样就达到了依赖倒置的目的，B也解除了对A的依赖，反过来是A依赖于B定义的抽象接口。通过上层模块难以避免依赖下层模块，假如B也直接依赖A的实现，那么就可能造成循环依赖。一个常见的问题就是编译A模块时需要直接包含到B模块的cpp文件，而编译B时同样要直接包含到A的cpp文件。
5、接口分离原则(the Interface Segregation Principle ISP)
模块间要通过抽象接口隔离开，而不是通过具体的类强耦合起来

2、多态实现原理？

下面从虚拟机运行时的角度来简要介绍多态的实现原理，这里以Java虚拟机（Java Virtual Machine, JVM）规范的实现为例。
在JVM执行Java字节码时，类型信息被存放在方法区中，通常为了优化对象调用方法的速度，方法区的类型信息中增加一个指针，该指针指向一张记录该类方法入口的表（称为方法表），表中的每一项都是指向相应方法的指针。
方法表的构造如下：
由于Java的单继承机制，一个类只能继承一个父类，而所有的类又都继承自Object类。方法表中最先存放的是Object类的方法，接下来是该类的父类的方法，最后是该类本身的方法。这里关键的地方在于，如果子类改写了父类的方法，那么子类和父类的那些同名方法共享一个方法表项，都被认作是父类的方法。
注意这里只有非私有的实例方法才会出现，并且静态方法也不会出现在这里，原因很容易理解：静态方法跟对象无关，可以将方法地址直接引用，而不像实例方法需要间接引用。
更深入地讲，静态方法是由虚拟机指令invokestatic调用的，私有方法和构造函数则是由invokespecial指令调用，只有被invokevirtual和invokeinterface指令调用的方法才会在方法表中出现。
由于以上方法的排列特性（Object——父类——子类），使得方法表的偏移量总是固定的。例如，对于任何类来说，其方法表中equals方法的偏移量总是一个定值，所有继承某父类的子类的方法表中，其父类所定义的方法的偏移量也总是一个定值。
前面说过，方法表中的表项都是指向该类对应方法的指针，这里就开始了多态的实现：
假设Class A是Class B的子类，并且A改写了B的方法method()，那么在B的方法表中，method方法的指针指向的就是B的method方法入口。
而对于A来说，它的方法表中的method方法则会指向其自身的method方法而非其父类的（这在类加载器载入该类时已经保证，同时JVM会保证总是能从对象引用指向正确的类型信息）。
结合方法指针偏移量是固定的以及指针总是指向实际类的方法域，我们不难发现多态的机制就在这里：
在调用方法时，实际上必须首先完成实例方法的符号引用解析，结果是该符号引用被解析为方法表的偏移量。虚拟机通过对象引用得到方法区中类型信息的入口，查询类的方法表，当将子类对象声明为父类类型时，形式上调用的是父类方法，此时虚拟机会从实际类的方法表（虽然声明的是父类，但是实际上这里的类型信息中存放的是子类的信息）中查找该方法名对应的指针（这里用“查找”实际上是不合适的，前面提到过，方法的偏移量是固定的，所以只需根据偏移量就能获得指针），进而就能指向实际类的方法了。
我们的故事还没有结束，事实上上面的过程仅仅是利用继承实现多态的内部机制，多态的另外一种实现方式：实现接口相比而言就更加复杂，原因在于，Java的单继承保证了类的线性关系，而接口可以同时实现多个，这样光凭偏移量就很难准确获得方法的指针。所以在JVM中，多态的实例方法调用实际上有两种指令：
invokevirtual指令用于调用声明为类的方法；
invokeinterface指令用于调用声明为接口的方法。
当使用invokeinterface指令调用方法时，就不能采用固定偏移量的办法，只能老老实实挨个找了（当然实际实现并不一定如此，JVM规范并没有规定究竟如何实现这种查找，不同的JVM实现可以有不同的优化算法来提高搜索效率）。我们不难看出，在性能上，调用接口引用的方法通常总是比调用类的引用的方法要慢。这也告诉我们，在类和接口之间优先选择接口作为设计并不总是正确的，当然设计问题不在本文探讨的范围之内，但显然具体问题具体分析仍然不失为更好的选择。

3、抽象类和接口区别,以及各自的使用场景

一、抽象类
在面向对象的概念中，所有的对象都是通过类来描绘的，但是反过来，并不是所有的类都是用来描绘对象的，如果一个类中没有包含足够的信息来描绘一个具体的对象，这样的类就可以称之为抽象类。
1.抽象方法：使用abstract修饰且没有方法体的方法。
特点：
① 抽象方法没有方法体，交给子类实现
② 抽象方法修饰符不能是private final static
③ 抽象方法必须定义在抽象类或者接口中

2.抽象类：包含抽象方法的类，即使用abstract修饰的类。

特点：
① 抽象类不能被实例化，只能被继承
② 抽象类中可以不包含抽象方法（不包含抽象方法就没有太大意义，可以作为工具类防止被实例化）
③ 抽象类的子类可以不实现该类所有的抽象方法，但也必须作为抽象类（抽象派生类）
④ 抽象类的构造方法不能定义成私有（子类构造方法会调用父类构造方法）
⑤ 抽象类不能使用final修饰，final修饰的类不能被继承

二、接口
1.什么是接口：
① 硬件接口：是指同一计算机不同功能层之间的通信规则称为接口。
② 软件接口：是指对协定进行定义的引用类型。其他类型实现接口，以保证它们支持某些操作。
2.Java中的接口：在JAVA编程语言中是接口一个抽象类型，是抽象方法的集合，接口通常以interface来声明。一个类通过继承接口的方式，从而来继承接口的抽象方法。
特点：
① 接口中没有构造器，不能被实例化
② 接口只能继承接口，不能继承类，接口支持多继承
③ 接口中的定义的成员变量，默认是public static final修饰的静态常量
④ 接口中定义的方法，默认是public abstract修饰的抽象方法
⑤ 接口中定义的内部类，默认是public static修饰的静态内部类
标志接口：仅仅作为一个定义，就是一个标志
常量接口：用来封装多个常量信息
注意：在JDK8中，接口也可以定义静态方法和默认非静态方法，可以直接用接口名调用静态方法，实现类可以调用默认非静态方法。如果同时实现两个接口，接口中定义了一样的默认方法，则实现类必须重写默认方法，不然会报错。

三、抽象类和接口的异同点
1.语法层面

相同点：
① 抽象类和接口都不能被实例化
② 抽象类和接口都可以定义抽象方法，子类/实现类必须覆写这些抽象方法

不同点
① 抽象类有构造方法，接口没有构造方法
② 抽象类可以包含普通方法，接口中只能是public abstract修饰抽象方法（Java8之后可以）
③ 抽象类只能单继承，接口可以多继承
④ 抽象类可以定义各种类型的成员变量，接口中只能是public static final修饰的静态常量

2.设计层面
① 抽象类是对一种事物的抽象，即对类抽象，而接口是对行为的抽象。抽象类是对整个类整体进行抽象，包括属性、行为，但是接口却是对类局部（行为）进行抽象。举个简单的例子，飞机和鸟是不同类的事物，但是它们都有一个共性，就是都会飞。那么在设计的时候，可以将飞机设计为一个类Airplane，将鸟设计为一个类Bird，但是不能将飞行这个特性也设计为类，因此它只是一个行为特性，并不是对一类事物的抽象描述。此时可以将飞行设计为一个接口Fly，包含方法fly( )，然后Airplane和Bird分别根据自己的需要实现Fly这个接口。然后至于有不同种类的飞机，比如战斗机、民用飞机等直接继承Airplane即可，对于鸟也是类似的，不同种类的鸟直接继承Bird类即可。从这里可以看出，继承是一个 "是不是"的关系，而接口实现则是 "有没有"的关系。如果一个类继承了某个抽象类，则子类必定是抽象类的种类，而接口实现则是有没有、具备不具备的关系，比如鸟是否能飞（或者是否具备飞行这个特点），能飞行则可以实现这个接口，不能飞行就不实现这个接口。
② 设计层面不同，抽象类作为很多子类的父类，它是一种模板式设计。而接口是一种行为规范，它是一种辐射式设计。什么是模板式设计？最简单例子，大家都用过ppt里面的模板，如果用模板A设计了ppt B和ppt C，ppt B和ppt C公共的部分就是模板A了，如果它们的公共部分需要改动，则只需要改动模板A就可以了，不需要重新对ppt B和ppt C进行改动。而辐射式设计，比如某个电梯都装了某种报警器，一旦要更新报警器，就必须全部更新。也就是说对于抽象类，如果需要添加新的方法，可以直接在抽象类中添加具体的实现，子类可以不进行变更；而对于接口则不行，如果接口进行了变更，则所有实现这个接口的类都必须进行相应的改动。
四、抽象类和接口的使用场景
1.抽象类的使用场景
既想约束子类具有共同的行为（但不再乎其如何实现），又想拥有缺省的方法，又能拥有实例变量
如：模板方法设计模式，模板方法使得子类可以在不改变算法结构的情况下，重新定义算法中某些步骤的具体实现。
2.接口的应用场景
① 约束多个实现类具有统一的行为，但是不在乎每个实现类如何具体实现
② 作为能够实现特定功能的标识存在，也可以是什么接口方法都没有的纯粹标识。
③ 实现类需要具备很多不同的功能，但各个功能之间可能没有任何联系。
④ 使用接口的引用调用具体实现类中实现的方法（多态）

4、泛型以及泛型擦除

泛型，即“参数化类型”。
创建集合时就指定集合元素的类型，该集合只能保存其指定类型的元素，避免使用强制类型转换。
Java 编译器生成的字节码是不包涵泛型信息的，泛型类型信息将在编译处理是被擦除，这个过程即类型擦除。泛型擦除可以简单的理解为将泛型 java 代码转换为普通 java 代码，只不过编译器更直接点，将泛型 java 代码直接转换成普通 java 字节码。
类型擦除的主要过程如下：
1）.将所有的泛型参数用其最左边界（最顶级的父类型）类型替换。
2）.移除所有的类型参数。

5、List类型的list,可以加入无继承关系的B类型对象吗？如何加入？

暂未找到

6、Java异常体系

Throwable：有两个重要的子类：Exception（异常）和Error（错误），两者都包含了大量的异常处理类。
1、Error（错误）：
是程序中无法处理的错误，表示运行应用程序中出现了严重的错误。此类错误一般表示代码运行时JVM出现问题。通常有Virtual MachineError（虚拟机运行错误）、NoClassDefFoundError（类定义错误）等。比如说当jvm耗完可用内存时，将出现OutOfMemoryError。此类错误发生时，JVM将终止线程。
这些错误是不可查的，非代码性错误。因此，当此类错误发生时，应用不应该去处理此类错误。
2、Exception（异常）：程序本身可以捕获并且可以处理的异常。
Exception这种异常又分为两类：运行时异常和编译异常。
1、运行时异常(不受检异常)：RuntimeException类极其子类表示JVM在运行期间可能出现的错误。比如说试图使用空值对象的引用（NullPointerException）、数组下标越界（ArrayIndexOutBoundException）。此类异常属于不可查异常，一般是由程序逻辑错误引起的，在程序中可以选择捕获处理，也可以不处理。
2、编译异常(受检异常)：Exception中除RuntimeException极其子类之外的异常。如果程序中出现此类异常，比如说IOException，必须对该异常进行处理，否则编译不通过。在程序中，通常不会自定义该类异常，而是直接使用系统提供的异常类。

可查异常与不可查异常：java的所有异常可以分为可查异常（checked exception）和不可查异常（unchecked exception）。
1、可查异常：编译器要求必须处理的异常。正确的程序在运行过程中，经常容易出现的、符合预期的异常情况。一旦发生此类异常，就必须采用某种方式进行处理。除RuntimeException及其子类外，其他的Exception异常都属于可查异常。编译器会检查此类异常，也就是说当编译器检查到应用中的某处可能会此类异常时，将会提示你处理本异常——要么使用try-catch捕获，要么使用throws语句抛出，否则编译不通过。
2、不可查异常：编译器不会进行检查并且不要求必须处理的异常，也就说当程序中出现此类异常时，即使我们没有try-catch捕获它，也没有使用throws抛出该异常，编译也会正常通过。该类异常包括运行时异常（RuntimeException极其子类）和错误（Error）。

异常处理流程：
在java应用中，异常的处理机制分为抛出异常和捕获异常。
抛出异常：当一个方法出现错误而引发异常时，该方法会将该异常类型以及异常出现时的程序状态信息封装为异常对象，并交给本应用。运行时，该应用将寻找处理异常的代码并执行。任何代码都可以通过throw关键词抛出异常，比如java源代码抛出异常、自己编写的代码抛出异常等。
捕获异常：一旦方法抛出异常，系统自动根据该异常对象寻找合适异常处理器（Exception Handler）来处理该异常。所谓合适类型的异常处理器指的是异常对象类型和异常处理器类型一致。
对于不同的异常，java采用不同的异常处理方式：
1、运行异常将由系统自动抛出，应用本身可以选择处理或者忽略该异常。
2、对于方法中产生的Error，该异常一旦发生JVM将自行处理该异常，因此java允许应用不抛出此类异常。
3、对于所有的可查异常，必须进行捕获或者抛出该方法之外交给上层处理。也就是当一个方法存在异常时，要么使用try-catch捕获，要么使用该方法使用throws将该异常抛调用该方法的上层调用者。

7、反射原理以及使用场景

太复杂了，找到一篇比较好的博客：
https://blog.csdn.net/21aspnet/article/details/89402714

8、ThreadLocal原理，如何使用？

ThreadLocal的定义与理解
定义和特点：
ThreadLocal顾名思义可以理解为线程本地变量，ThreadLocal将变量的各个副本值保存在各个线程Thread，Thread对象实例采用ThreadLocalMap数据结构来存储副本值。每个线程往这个ThreadLocal中读写是线程隔离，一种将可变数据通过每个线程有自己的独立副本从而实现线程封闭的机制。
适用场景：

(1) 当很多线程需要多次使用同一个对象，并且需要该对象具有相同初始化值；

(2) 适用于资源共享但不需要维护状态的情况，也就是一个线程对资源的修改，不影响另一个线程的运行；

(3) 基于ThreadLocal实现线程安全是采用"空间换时间"，synchronized顺序执行是"时间换取空间"。

ThreadLocal类的核心方法包括4个：

(1) protected T initialValue()

(2) public T get()

先获取当前线程的thread对象，再获取thread对象的threadLocalMap对象，然后根据当前的threadLocal对象取得table数组对应下标的Entry对象；
如果Thread对象的ThreadLocalMap为空的话，就调用setInitialValue方法，该方法初始化map并且放入null ( initialValue的返回值为null )，可以通过覆盖该方法修改没有set时的初始值。

(3) public void set( T value)

先调用Thread类的静态方法获得当前线程的Thread对象，每个线程对应的Thread对象都有一个ThreadLocalMap对象的引用；
获得当前线程的ThreadLocalMap对象；
如果不为空就调用set方法，如果为空就调用createMap方法，传入参数为ThreadLocalMap为空的Thread对象和T类型的firstValue。

(4) public void remove()

先获取当前线程的Map对象；
调用Map的remove方法，删除entry。
ThreadLocal使用注意事项
1、ThreadLoca对象是一个弱引用
ThreadLocalMap中的节点Entry继承了WeakReference类，定义了一个类型为Object的value，用于存放塞到ThreadLocal里的值。如果这里使用普通的key-value形式来定义存储结构，实质上就会造成节点的生命周期与线程强绑定，只要线程没有销毁，那么节点在GC分析中一直处于可达状态，没办法被回收，而程序本身也无法判断是否可以清理节点。ThreadLocal对象是一个继承自WeakReference的弱引用，当把ThreadLocal的实例置为空以后，没有任何强引用指向ThreadLocal的实例，所以ThreadLocal的将会被GC回收。生命周期只存活到下次GC前，可降低内存泄漏的风险。
2、ThreadLocal与内存泄漏
ThreadLocal对象是具有弱引用特点，虽然在一定程度上降低了内存泄漏的风险，但是在有线程复用如线程池的场景中，一个线程的寿命很长，大对象长期不被回收影响系统运行效率与安全，那么就存在一条强引用链的关系一直存在：Thread --> ThreadLocalMap-->Entry-->Value，最终造成内存泄漏。
如何避免内存泄漏：
调用ThreadLocal的get()、set()方法时完成后再调用remove方法，将Entry节点和Map的引用关系移除，这样整个Entry对象在GC Roots分析后就变成不可达了，下次GC的时候就可以被回收。
3、哈希冲突怎么解决
ThreadLocalMap中解决哈希冲突的方式并非链表的方式，而是采用线性探测的方式，具体来说，就是简单的步长加1或减1，寻找下一个相邻的位置。

9、内存泄漏有哪些场景以及解决方法

1、类的静态变量持有大数据对象静态变量长期维持到大数据对象的引用，阻止垃圾回收。
2、非静态内部类存在静态实例非静态内部类会维持一个到外部类实例的引用，如果非静态内部类的实例是静态的，就会间接长期维持着外部类的引用，阻止被回收掉。
3、资源对象未关闭资源性对象比如（Cursor，File文件等）往往都用了一些缓冲，我们在不使用的时候，应该及时关闭它们，以便它们的缓冲及时回收内存。它们的缓冲不仅存在于java虚拟机内，还存在于java虚拟机外。如果我们仅仅是把它的引用设置为null,而不关闭它们，往往会造成内存泄露。
解决办法：比如SQLiteCursor（在析构函数finalize（）,如果我们没有关闭它，它自己会调close()关闭），如果我们没有关闭它，系统在回收它时也会关闭它，但是这样的效率太低了。因此对于资源性对象在不使用的时候，应该调用它的close()函数，将其关闭掉，然后才置为null. 在我们的程序退出时一定要确保我们的资源性对象已经关闭。程序中经常会进行查询数据库的操作，但是经常会有使用完毕Cursor后没有关闭的情况。如果我们的查询结果集比较小，对内存的消耗不容易被发现，只有在常时间大量操作的情况下才会复现内存问题，这样就会给以后的测试和问题排查带来困难和风险，记得try catch后，在finally方法中关闭连接
4、Handler内存泄漏 Handler作为内部类存在于Activity中，但是Handler生命周期与Activity生命周期往往并不是相同的，比如当Handler对象有Message在排队，则无法释放，进而导致本该释放的Acitivity也没有办法进行回收。
解决办法：声明handler为static类，这样内部类就不再持有外部类的引用了，就不会阻塞Activity的释放。如果内部类实在需要用到外部类的对象，可在其内部声明一个弱引用引用外部类。

10、static关键字和final关键字使用情况，一个类不能被继承，除了final关键字之外，还有什么方法（从构造函数考虑）？

static
（1）被static修饰的内部类，方法，属性有什么特点？
1、static修饰的属性和方法属于类级别
2、static修饰的属性:称静态属性/类属性
访问方式:

通过对象去访问: 对象.静态属性 (不推荐使用)
通过类去访问: 类名.静态属性
特点:所有对象共享同一份静态属性
3、static修饰方法:称静态方法/类方法
访问方式:与静态属性一致
特点:
静态方法中只能使用静态的属性和方法
（因为类加载之后，静态成员就会加载出来，而此时对象不一定存在，所以静态方法中不能有实例属性和实例方法）
静态方法不具备多态性, 执行哪个方法看引用类型
3、static修饰的内部类，只能通过类名.的方式去访问，起到保护作用
（2）静态初始代码块和实例代码块
1、静态代码块：
static{//code}
2、实例代码块：
{ .... }
3、静态成员的创建或执行时机:
类加载时被执行一次
静态代码块与静态成员执行的顺序, 看代码定义的先后位置
final
（3）被final修饰的类，方法，属性有什么特点？
1、final修饰类时:最终类；
特点:不能被继承
2、final修饰属性时:常量；
特点:常量必须初始化:
（1）定义常量时进行初始化
（2）在实例代码块中初始化
（3）在构造方法中初始化
注意:3者只能选其一，常量一旦初始化后值不能被改变
3、final修饰方法时最终方法；
特点:不能被重写
4、final修饰局部变量时:常量；
常量一旦初始化后值不能被改变
（4）static和final连用修饰属性
final关键字通常和static关键联用一起来修饰一个属性: 静态常量
静态常量:代替程序中需要使用到的一些固定选项值(代号),从而提升程序的可读性

一个类不能被继承，除了final关键字之外，还有什么方法
暂时没找到

11、序列化和反序列化。反序列化失败的场景。

见https://blog.csdn.net/u013815832/article/details/95212567

12、Vector、ArrayList和LinkedList的区别和底层实现？

1.基本区别：三个类都实现了List接口，都是有序集合，数据是允许重复的；ArrayList 和Vector都是基于数组实现存储的，集合中的元素的位置都是有顺序即连续的；LinkedList是基于双向链表实现存储的，集合中的元素的位置是不连续的
2.性能区别：Vector和ArrayList底层实现原理一致，但是Vector是线程安全的，因此性能比ArrayList差很多；LinkedList相比于集合Vector和ArrayList在插入,修改，删除等操作上速度较快，但是随机访问的性能较差
3.安全区别：Vector是使用了synchronized同步锁是线程安全的，ArrayList和LinkedList都是线程不安全的
4.原理区别：ArrayList与Vector都有初始的容量大小，当存储的元素的个数超过了容量时，就需要增加存储空间，Vector默认增长为原来两倍，而ArrayList的增长为原来的1.5倍；ArrayList与Vector都可以设置初始空间大小，Vector还可以设置增长的空间大小，而ArrayList没有提供设置增长空间的方法

然后详细分析每一个的原理：
1.Vector

从源码可以看出Vector的初始默认空间大小为10，底层使用protected Object[] elementData;存储数据，使用protected int elementCount;存储元素数量，Vector的方法都被synchronized关键字修饰，因此是线程安全的。
接下来我们从源码上看下Vector的添加元素时以及初始容量不足时的扩容机制：

当创建一个Vector容器，向其中添加一个元素是，首先会调用ensureCapacityHelper函数判断容器存储容量，如果容量不足则会调用grow函数扩容，上面我们说的扩展为原来的两倍，其实不是非常准确，因为当设置了扩容参数值，则就不是扩展为两倍了，而是原来的长度加上扩容参数值，默认情况下还是扩展为原来的两倍。

2.ArrayList

ArrayList的初始容量大小也是10，和Vector的原理是完全一样的，只是不是线程安全的，我们这里主要看下ArrayList的扩容原理：

ArrayList也是会先判断容器的容量大小，如果容量不足，则调用扩容方法grow函数，将容量扩展原来加原来一半也就是1.5倍
3.LinkedList

LinkedList是一个继承于AbstractSequentialList的双向链表，它也可以被当作堆栈、队列或双向队列进行操作。LinkedList实现 List 接口，能对它进行队列操作。LinkedList 实现 Deque 接口，即能将LinkedList当作双端队列使用。LinkedList 是非同步的（线程不安全的）。因为是双向链表，所以它的顺序访问会非常高效，而随机访问效率比较低。

下面我们先看下LinkedList的添加元素的原理

我们从源码可以看到其实add添加元素的操作就是在容器的最后新增一个数据节点，具体分析：先把当前最后一个节点存档到l数据节点中，然后新增一个数据节点，这里有一个判断，如果l为空那就是说改链表是空的，这样这个新增元素即是第一个也是最后一个节点；如果l不为空，将当前最后一个节点变成新增的前一个节点，然后last存放新增节点使其变成最后一个元素节点，这样一个新增的操作就完成了。

我们再来看看向制定位置添加数据节点的原理，看下面源码：

首先是位置是否存在，添加元素的位置必须是大于等于0小于等于链表的大小；然后判断如果要添加元素的位置等于链表的大小，则该元素插入最有一个即可，否则在指点的位置前插入节点，先将该位置前的阶段存起来到pred，然后判断如果pred为空说明该链表是空的，则将新增数据节点写入第一个节点中，如果pred不为空，将原来的前一个节点的下一个节点指向新添加的节点，将新添加节点的下一个节点指向原来位置的下一个节点即可

接下来我们看下删除第一个节点元素：

删除时是先把原来的第一个节点的下一个节点存到first中，然后将第一个节点的指向都设置为null（删除），然后将first指向next就可以了，然后判断如果next为空则last设置为空，这时候整个链表也就是空的；反之释放next内存；然后将链表大小减小一个，将此列表已被结构修改的次数减一
接下来我们看下删除最后一个节点元素：

删除最后一个元素是相对简单一些，删除最后一个节点，然后释放该节点指向前一个节点的指针空间和释放前一个节点指向下一个节点的指针空间，然后将链表大小减小一个，将此列表已被结构修改的次数减一

13、如何实现线程安全？

1：加锁利用Synchronized或者ReenTrantLock来对不安全对象进行加锁，来实现线程执行的串行化，从而保证多线程同时操作对象的安全性，一个是语法层面的互斥锁，一个是API层面的互斥锁.
2：非阻塞同步来实现线程安全。原理就是：通俗点讲，就是先进性操作，如果没有其他线程争用共享数据，那操作就成功了；如果共享数据有争用，产生冲突，那就再采取其他措施(最常见的措施就是不断地重试，直到成功为止)。这种方法需要硬件的支持，因为我们需要操作和冲突检测这两个步骤具备原子性。通常这种指令包括CAS SC,FAI TAS等。
3：线程本地化，一种无同步的方案，就是利用Threadlocal来为每一个线程创造一个共享变量的副本来（副本之间是无关的）避免几个线程同时操作一个对象时发生线程安全问题。

14、List遍历时如何删除元素？fail—fast是什么？fail—safe是什么

一、错误方式
先看看下面几段代码，1是foreach的方式去遍历list并删除元素，2是用迭代器的方式遍历list并删除元素，3是下标遍历

foreach
public void testDel(){
List list = Lists.newArrayList();
for(int i=1;i<=5;i++){
list.add(i);
}
for(Integer ele : list){
if(ele == 3)
list.remove(ele);
}
}
Iterator

public void testDel(){
List list = Lists.newArrayList();
for(int i=1;i<=5;i++){
list.add(i);
}
Iterator iterator = list.iterator();
while(iterator.hasNext()){
Integer integer = iterator.next();
if(integer==3)
list.remove(integer);
}
}
以上两段代码的执行结果都是 java.util.ConcurrentModificationException。
在使用ArrayList时，当尝试用foreach或者Iterator遍历集合时进行删除或者插入元素的操作时，会抛出这样的异常：java.util.ConcurrentModificationException
关于这个异常的原因，看了很多文章，基本上解释如下：ArrayList的父类AbstarctList中有一个域modCount，每次对集合进行修改（增添、删除元素）时modCount都会+1。
而foreach的实现原理就是迭代器Iterator，在这里，迭代ArrayList的Iterator中有一个变量expectedModCount，该变量会初始化和modCount相等，但当对集合进行插入，删除操作，modCount会改变，就会造成expectedModCount!=modCount，此时就会抛出java.util.ConcurrentModificationException异常，是在checkForComodification方法中，代码如下：
final void checkForComodification() {
if (modCount != expectedModCount)
throw new ConcurrentModificationException();
}
3 . 下标遍历
public void testDel() {
List list = Lists.newArrayList();
list.add(1);
list.add(2);
list.add(2);
list.add(2);
list.add(2);
for(int i=0;i<list.size();i++){
if(list.get(i)==2){
list.remove(i);
}
}
}
//结果： list = [1,2,2]
因为下标是固定死的自增，但list的大小在随着删除元素不停的减小，并且后面的元素往前移了1位,所以后面的元素遍历不到。在i=3时，由于删了2个元素，size=3，所以循环直接结束。因此这种方式也是不符合预期的。
二、解决方法
但业务中经常涉及遍历时删除或插入操作。所以如何安全的操作ArrayList呢，解决方法如下！

1.使用迭代器的remove方法
在使用迭代器遍历时，可使用迭代器的remove方法，因为Iterator的remove方法中有如下的操作：
expectedModCount = modCount；
所以避免了ConcurrentModificationException的异常。代码如下：

public void testDel() {
List list = Lists.newArrayList();
list.add(1);
list.add(2);
list.add(2);
list.add(2);
Iterator iterator = list.iterator();
while (iterator.hasNext()) {
Integer integer = iterator.next();
if (integer == 2)
iterator.remove();
}
}

执行后结果： list = [1]
其实在阿里巴巴Java开发手册中原话：不要在 foreach 循环里进行元素的 remove/add 操作。remove 元素请使用 Iterator方式，如果并发操作，需要对 Iterator 对象加锁。
2.倒序遍历删除
public void testDel() {
List list = Lists.newArrayList();
list.add(1);
list.add(2);
list.add(2);
list.add(2);
list.add(2);
for(int i=list.size()-1;i>=0;i--){
if(list.get(i)==2){
list.remove(i);
}
}
}
结果： list = [1]
可见，也达到了预期的效果。因为每次删除一个元素，list大小-1，但是倒序，循环条件为i>=0，所以list的size改变并没有对遍历造成影响，且元素的前移也不会对倒序遍历有影响。所以在对list或者hashmap遍历时候进行元素删增操作时，一定要验证下。

15、快速失败(fail-fast)和安全失败(fail-safe)的区别是什么？

一：快速失败（fail—fast）
在用迭代器遍历一个集合对象时，如果遍历过程中对集合对象的内容进行了修改（增加、删除、修改），则会抛出Concurrent Modification Exception。
原理：迭代器在遍历时直接访问集合中的内容，并且在遍历过程中使用一个 modCount 变量。集合在被遍历期间如果内容发生变化，就会改变modCount的值。每当迭代器使用hashNext()/next()遍历下一个元素之前，都会检测modCount变量是否为expectedmodCount值，是的话就返回遍历；否则抛出异常，终止遍历。
注意：这里异常的抛出条件是检测到 modCount！=expectedmodCount 这个条件。如果集合发生变化时修改modCount值刚好又设置为了expectedmodCount值，则异常不会抛出。因此，不能依赖于这个异常是否抛出而进行并发操作的编程，这个异常只建议用于检测并发修改的bug。
场景：java.util包下的集合类都是快速失败的，不能在多线程下发生并发修改（迭代过程中被修改）。
二：安全失败（fail—safe）
采用安全失败机制的集合容器，在遍历时不是直接在集合内容上访问的，而是先复制原有集合内容，在拷贝的集合上进行遍历。
原理：由于迭代时是对原集合的拷贝进行遍历，所以在遍历过程中对原集合所作的修改并不能被迭代器检测到，所以不会触发Concurrent Modification Exception。
缺点：基于拷贝内容的优点是避免了Concurrent Modification Exception，但同样地，迭代器并不能访问到修改后的内容，即：迭代器遍历的是开始遍历那一刻拿到的集合拷贝，在遍历期间原集合发生的修改迭代器是不知道的。
场景：java.util.concurrent包下的容器都是安全失败，可以在多线程下并发使用，并发修改。

16、详细介绍HashMap。角度：数据结构+扩容情况+put查找的详细过程+哈希函数+容量为什么始终都是2^N+JDK1.7与JDK1.8的区别。

深入浅出学Java——HashMap
哈希表（hash table）
也叫散列表，是一种非常重要的数据结构，应用场景及其丰富，许多缓存技术（比如memcached）的核心其实就是在内存中维护一张大的哈希表，本文会对java集合框架中HashMap的实现原理进行讲解，并对JDK7的HashMap源码进行分析。
一、什么是哈希表
在讨论哈希表之前，我们先大概了解下其他数据结构在新增，查找等基础操作执行性能
数组：采用一段连续的存储单元来存储数据。对于指定下标的查找，时间复杂度为O(1)；通过给定值进行查找，需要遍历数组，逐一比对给定关键字和数组元素，时间复杂度为O(n)，当然，对于有序数组，则可采用二分查找，插值查找，斐波那契查找等方式，可将查找复杂度提高为O(logn)；对于一般的插入删除操作，涉及到数组元素的移动，其平均复杂度也为O(n)
线性链表：对于链表的新增，删除等操作（在找到指定操作位置后），仅需处理结点间的引用即可，时间复杂度为O(1)，而查找操作需要遍历链表逐一进行比对，复杂度为O(n)
二叉树：对一棵相对平衡的有序二叉树，对其进行插入，查找，删除等操作，平均复杂度均为O(logn)。
哈希表：相比上述几种数据结构，在哈希表中进行添加，删除，查找等操作，性能十分之高，不考虑哈希冲突的情况下（后面会探讨下哈希冲突的情况），仅需一次定位即可完成，时间复杂度为O(1)，接下来我们就来看看哈希表是如何实现达到惊艳的常数阶O(1)的。
我们知道，数据结构的物理存储结构只有两种：顺序存储结构和链式存储结构（像栈，队列，树，图等是从逻辑结构去抽象的，映射到内存中，也这两种物理组织形式），而在上面我们提到过，在数组中根据下标查找某个元素，一次定位就可以达到，哈希表利用了这种特性，哈希表的主干就是数组。
比如我们要新增或查找某个元素，我们通过把当前元素的关键字通过某个函数映射到数组中的某个位置，通过数组下标一次定位就可完成操作。
这个函数可以简单描述为：存储位置 = f(关键字) ，这个函数f一般称为哈希函数，这个函数的设计好坏会直接影响到哈希表的优劣。举个例子，比如我们要在哈希表中执行插入操作：
插入过程如下图所示

查找操作同理，先通过哈希函数计算出实际存储地址，然后从数组中对应地址取出即可。
哈希冲突
然而万事无完美，如果两个不同的元素，通过哈希函数得出的实际存储地址相同怎么办？也就是说，当我们对某个元素进行哈希运算，得到一个存储地址，然后要进行插入的时候，发现已经被其他元素占用了，其实这就是所谓的哈希冲突，也叫哈希碰撞。前面我们提到过，哈希函数的设计至关重要，好的哈希函数会尽可能地保证计算简单和散列地址分布均匀,但是，我们需要清楚的是，数组是一块连续的固定长度的内存空间，再好的哈希函数也不能保证得到的存储地址绝对不发生冲突。那么哈希冲突如何解决呢？哈希冲突的解决方案有多种:开放定址法（发生冲突，继续寻找下一块未被占用的存储地址），再散列函数法，链地址法，而HashMap即是采用了链地址法，也就是数组+链表的方式。
二、HashMap的实现原理
HashMap的主干是一个Entry数组。Entry是HashMap的基本组成单元，每一个Entry包含一个key-value键值对。（其实所谓Map其实就是保存了两个对象之间的映射关系的一种集合）

//HashMap的主干数组，可以看到就是一个Entry数组，初始值为空数组{}，主干数组的长度一定是2的次幂。
//至于为什么这么做，后面会有详细分析。
transient Entry<K,V>[] table = (Entry<K,V>[]) EMPTY_TABLE;

Entry是HashMap中的一个静态内部类。代码如下
static class Entry<K,V> implements Map.Entry<K,V> {
final K key;
V value;
Entry<K,V> next;//存储指向下一个Entry的引用，单链表结构
int hash;//对key的hashcode值进行hash运算后得到的值，存储在Entry，避免重复计算

    /**
     * Creates new entry.
     */
    Entry(int h, K k, V v, Entry<K,V> n) {
        value = v;
        next = n;
        key = k;
        hash = h;
    }

所以，HashMap的总体结构如下：

简单来说，HashMap由数组+链表组成的，数组是HashMap的主体，链表则是主要为了解决哈希冲突而存在的，如果定位到的数组位置不含链表（当前entry的next指向null）,那么查找，添加等操作很快，仅需一次寻址即可；如果定位到的数组包含链表，对于添加操作，其时间复杂度为O(n)，首先遍历链表，存在即覆盖，否则新增；对于查找操作来讲，仍需遍历链表，然后通过key对象的equals方法逐一比对查找。所以，性能考虑，HashMap中的链表出现越少，性能才会越好。
其他几个重要字段

/**实际存储的key-value键值对的个数*/
transient int size;

/**阈值，当table == {}时，该值为初始容量（初始容量默认为16）；当table被填充了，也就是为table分配内存空间后，
threshold一般为 capacityloadFactory。HashMap在进行扩容时需要参考threshold，后面会详细谈到/
int threshold;

/**负载因子，代表了table的填充度有多少，默认是0.75
加载因子存在的原因，还是因为减缓哈希冲突，如果初始桶为16，等到满16个元素才扩容，某些桶里可能就有不止一个元素了。
所以加载因子默认为0.75，也就是说大小为16的HashMap，到了第13个元素，就会扩容成32。
*/
final float loadFactor;

/**HashMap被改变的次数，由于HashMap非线程安全，在对HashMap进行迭代时，
如果期间其他线程的参与导致HashMap的结构发生变化了（比如put，remove等操作），
需要抛出异常ConcurrentModificationException*/
transient int modCount;

HashMap有4个构造器，其他构造器如果用户没有传入initialCapacity 和loadFactor这两个参数，会使用默认值
initialCapacity默认为16，loadFactory默认为0.75
我们看下其中一个
public HashMap(int initialCapacity, float loadFactor) {
　　　　　//此处对传入的初始容量进行校验，最大不能超过MAXIMUM_CAPACITY = 1<<30(230)
if (initialCapacity < 0)
throw new IllegalArgumentException("Illegal initial capacity: " +
initialCapacity);
if (initialCapacity > MAXIMUM_CAPACITY)
initialCapacity = MAXIMUM_CAPACITY;
if (loadFactor <= 0 || Float.isNaN(loadFactor)){
throw new IllegalArgumentException("Illegal load factor: " +
loadFactor);
}
this.loadFactor = loadFactor;
threshold = initialCapacity;
init();//init方法在HashMap中没有实际实现，不过在其子类如 linkedHashMap中就会有对应实现
}
从上面这段代码我们可以看出，在常规构造器中，没有为数组table分配内存空间（有一个入参为指定Map的构造器例外），而是在执行put操作的时候才真正构建table数组
OK,接下来我们来看看put操作的实现
public V put(K key, V value) {
//如果table数组为空数组{}，进行数组填充（为table分配实际内存空间），入参为threshold，
//此时threshold为initialCapacity 默认是1<<4(24=16)
if (table == EMPTY_TABLE) {
inflateTable(threshold);
}
//如果key为null，存储位置为table[0]或table[0]的冲突链上
if (key == null)
return putForNullKey(value);
int hash = hash(key);//对key的hashcode进一步计算，确保散列均匀
int i = indexFor(hash, table.length);//获取在table中的实际位置
for (Entry<K,V> e = table[i]; e != null; e = e.next) {
//如果该对应数据已存在，执行覆盖操作。用新value替换旧value，并返回旧value
Object k;
if (e.hash == hash && ((k = e.key) == key || key.equals(k))) {
V oldValue = e.value;
e.value = value;
e.recordAccess(this);
return oldValue;
}
}
modCount++;//保证并发访问时，若HashMap内部结构发生变化，快速响应失败
addEntry(hash, key, value, i);//新增一个entry
return null;
}
inflateTable这个方法用于为主干数组table在内存中分配存储空间，通过roundUpToPowerOf2(toSize)可以确保capacity为大于或等于toSize的最接近toSize的二次幂，比如toSize=13,则capacity=16;to_size=16,capacity=16;to_size=17,capacity=32.

private void inflateTable(int toSize) {
int capacity = roundUpToPowerOf2(toSize);//capacity一定是2的次幂
/此处为threshold赋值，取capacityloadFactor和MAXIMUM_CAPACITY+1的最小值，
capaticy一定不会超过MAXIMUM_CAPACITY，除非loadFactor大于1 /
threshold = (int) Math.min(capacity * loadFactor, MAXIMUM_CAPACITY + 1);
table = new Entry[capacity];
initHashSeedAsNeeded(capacity);
}
roundUpToPowerOf2中的这段处理使得数组长度一定为2的次幂，Integer.highestOneBit是用来获取最左边的bit（其他bit位为0）所代表的数值.
private static int roundUpToPowerOf2(int number) {
// assert number >= 0 : "number must be non-negative";
return number >= MAXIMUM_CAPACITY
? MAXIMUM_CAPACITY
: (number > 1) ? Integer.highestOneBit((number - 1) << 1) : 1;
}
hash函数
/这是一个神奇的函数，用了很多的异或，移位等运算
对key的hashcode进一步进行计算以及二进制位的调整等来保证最终获取的存储位置尽量分布均匀*/
final int hash(Object k) {
int h = hashSeed;
if (0 != h && k instanceof String) {
return sun.misc.Hashing.stringHash32((String) k);
}

    h ^= k.hashCode();

    h ^= (h >>> 20) ^ (h >>> 12);
    return h ^ (h >>> 7) ^ (h >>> 4);
}

以上hash函数计算出的值，通过indexFor进一步处理来获取实际的存储位置
/**
* 返回数组下标
*/
static int indexFor(int h, int length) {
return h & (length-1);
}
h&（length-1）保证获取的index一定在数组范围内，举个例子，默认容量16，length-1=15，h=18,转换成二进制计算为index=2。位运算对计算机来说，性能更高一些（HashMap中有大量位运算）
所以最终存储位置的确定流程是这样的：

再来看看addEntry的实现：
void addEntry(int hash, K key, V value, int bucketIndex) {
if ((size >= threshold) && (null != table[bucketIndex])) {
resize(2 * table.length);//当size超过临界阈值threshold，并且即将发生哈希冲突时进行扩容
hash = (null != key) ? hash(key) : 0;
bucketIndex = indexFor(hash, table.length);
}
createEntry(hash, key, value, bucketIndex);
}
通过以上代码能够得知，当发生哈希冲突并且size大于阈值的时候，需要进行数组扩容，扩容时，需要新建一个长度为之前数组2倍的新的数组，然后将当前的Entry数组中的元素全部传输过去，扩容后的新数组长度为之前的2倍，所以扩容相对来说是个耗资源的操作。
三、为何HashMap的数组长度一定是2的次幂？
我们来继续看上面提到的resize方法
void resize(int newCapacity) {
Entry[] oldTable = table;
int oldCapacity = oldTable.length;
if (oldCapacity == MAXIMUM_CAPACITY) {
threshold = Integer.MAX_VALUE;
return;
}

    Entry[] newTable = new Entry[newCapacity];
    transfer(newTable, initHashSeedAsNeeded(newCapacity));
    table = newTable;
    threshold = (int)Math.min(newCapacity * loadFactor, MAXIMUM_CAPACITY + 1);
}

如果数组进行扩容，数组长度发生变化，而存储位置 index = h&(length-1),index也可能会发生变化，需要重新计算index，我们先来看看transfer这个方法：
void transfer(Entry[] newTable, boolean rehash) {
int newCapacity = newTable.length;
　　　　　//for循环中的代码，逐个遍历链表，重新计算索引位置，将老数组数据复制到新数组中去（数组不存储实际数据，所以仅仅是拷贝引用而已）
for (Entry<K,V> e : table) {
while(null != e) {
Entry<K,V> next = e.next;
if (rehash) {
e.hash = null == e.key ? 0 : hash(e.key);
}
int i = indexFor(e.hash, newCapacity);
//将当前entry的next链指向新的索引位置,newTable[i]有可能为空，有可能也是个entry链，如果是entry链，直接在链表头部插入。
e.next = newTable[i];
newTable[i] = e;
e = next;
}
}
}
这个方法将老数组中的数据逐个链表地遍历，扔到新的扩容后的数组中，我们的数组索引位置的计算是通过对key值的hashcode进行hash扰乱运算后，再通过和 length-1进行位运算得到最终数组索引位置。
HashMap的数组长度一定保持2的次幂，比如16的二进制表示为 10000，那么length-1就是15，二进制为01111，同理扩容后的数组长度为32，二进制表示为100000，length-1为31，二进制表示为011111。从下图可以我们也能看到这样会保证低位全为1，而扩容后只有一位差异，也就是多出了最左位的1，这样在通过 h&(length-1)的时候，只要h对应的最左边的那一个差异位为0，就能保证得到的新的数组索引和老数组索引一致(大大减少了之前已经散列良好的老数组的数据位置重新调换)，个人理解。

还有，数组长度保持2的次幂，length-1的低位都为1，会使得获得的数组索引index更加均匀

我们看到，上面的&运算，高位是不会对结果产生影响的（hash函数采用各种位运算可能也是为了使得低位更加散列），我们只关注低位bit，如果低位全部为1，那么对于h低位部分来说，任何一位的变化都会对结果产生影响，也就是说，要得到index=21这个存储位置，h的低位只有这一种组合。这也是数组长度设计为必须为2的次幂的原因。

如果不是2的次幂，也就是低位不是全为1此时，要使得index=21，h的低位部分不再具有唯一性了，哈希冲突的几率会变的更大，同时，index对应的这个bit位无论如何不会等于1了，而对应的那些数组位置也就被白白浪费了。
get方法：
public V get(Object key) {
　　　　 //如果key为null,则直接去table[0]处去检索即可。
if (key == null)
return getForNullKey();
Entry<K,V> entry = getEntry(key);
return null == entry ? null : entry.getValue();
}
get方法通过key值返回对应value，如果key为null，直接去table[0]处检索。我们再看一下getEntry这个方法
final Entry<K,V> getEntry(Object key) {

    if (size == 0) {
        return null;
    }
    //通过key的hashcode值计算hash值
    int hash = (key == null) ? 0 : hash(key);
    //indexFor (hash&length-1) 获取最终数组索引，然后遍历链表，通过equals方法比对找出对应记录
    for (Entry<K,V> e = table[indexFor(hash, table.length)];
         e != null;
         e = e.next) {
        Object k;
        if (e.hash == hash && 
            ((k = e.key) == key || (key != null && key.equals(k))))
            return e;
    }
    return null;

}

可以看出，get方法的实现相对简单，key(hashcode)–>hash–>indexFor–>最终索引位置，找到对应位置table[i]，再查看是否有链表，遍历链表，通过key的equals方法比对查找对应的记录。要注意的是，有人觉得上面在定位到数组位置之后然后遍历链表的时候，e.hash == hash这个判断没必要，仅通过equals判断就可以。其实不然，试想一下，如果传入的key对象重写了equals方法却没有重写hashCode，而恰巧此对象定位到这个数组位置，如果仅仅用equals判断可能是相等的，但其hashCode和当前对象不一致，这种情况，根据Object的hashCode的约定，不能返回当前对象，而应该返回null，后面的例子会做出进一步解释。
四、重写equals方法需同时重写hashCode方法
最后我们再聊聊老生常谈的一个问题，各种资料上都会提到，“重写equals时也要同时覆盖hashcode”，我们举个小例子来看看，如果重写了equals而不重写hashcode会发生什么样的问题

public class MyTest {
private static class Person{
int idCard;
String name;

    public Person(int idCard, String name) {
        this.idCard = idCard;
        this.name = name;
    }
    @Override
    public boolean equals(Object o) {
        if (this == o) {
            return true;
        }
        if (o == null || getClass() != o.getClass()){
            return false;
        }
        Person person = (Person) o;
        //两个对象是否等值，通过idCard来确定
        return this.idCard == person.idCard;
    }

}
public static void main(String []args){
    HashMap<Person,String> map = new HashMap<Person, String>();
    Person person = new Person(1234,"乔峰");
    //put到hashmap中去
    map.put(person,"天龙八部");
    //get取出，从逻辑上讲应该能输出“天龙八部”
    System.out.println("结果:"+map.get(new Person(1234,"萧峰")));
}

}
实际输出结果：null

如果我们已经对HashMap的原理有了一定了解，这个结果就不难理解了。尽管我们在进行get和put操作的时候，使用的key从逻辑上讲是等值的（通过equals比较是相等的），但由于没有重写hashCode方法，所以put操作时，key(hashcode1)–>hash–>indexFor–>最终索引位置，而通过key取出value的时候 key(hashcode1)–>hash–>indexFor–>最终索引位置，由于hashcode1不等于hashcode2，导致没有定位到一个数组位置而返回逻辑上错误的值null（也有可能碰巧定位到一个数组位置，但是也会判断其entry的hash值是否相等，上面get方法中有提到。）
所以，在重写equals的方法的时候，必须注意重写hashCode方法，同时还要保证通过equals判断相等的两个对象，调用hashCode方法要返回同样的整数值。而如果equals判断不相等的两个对象，其hashCode可以相同（只不过会发生哈希冲突，应尽量避免）。
五、JDK1.8中HashMap的性能优化
假如一个数组槽位上链上数据过多（即拉链过长的情况）导致性能下降该怎么办？
JDK1.8在JDK1.7的基础上针对增加了红黑树来进行优化。即当链表超过8时，链表就转换为红黑树，利用红黑树快速增删改查的特点提高HashMap的性能，其中会用到红黑树的插入、删除、查找等算法。
关于这方面的探讨我们以后的文章再做说明。
附：HashMap put方法逻辑图（JDK1.8）

17、HashMap如何实现线程安全？

HashMap不是线程安全的,往往在写程序时需要通过一些方法来回避.其实JDK原生的提供了2种方法让HashMap支持线程安全.
方法一:通过Collections.synchronizedMap()返回一个新的Map,这个新的map就是线程安全的. 这个要求大家习惯基于接口编程,因为返回的并不是HashMap,而是一个Map的实现.
方法二:重新改写了HashMap,具体的可以查看java.util.concurrent.ConcurrentHashMap. 这个方法比方法一有了很大的改进.
下面对这2中实现方法从各个角度进行分析和比较.
实现原理
锁机制的不同
如何得到/释放锁
优缺点
1)实现原理
方法一原理:
通过Collections.synchronizedMap()来封装所有不安全的HashMap的方法,就连toString, hashCode都进行了封装. 封装的关键点有2处,1)使用了经典的synchronized来进行互斥, 2)使用了代理模式new了一个新的类,这个类同样实现了Map接口.

private static class SynchronizedMap<K,V>
implements Map<K,V>, Serializable {
// use serialVersionUID from JDK 1.2.2 for interoperability
private static final long serialVersionUID = 1978198479659022715L;

private final Map<K,V> m; // Backing Map
final Object mutex;// Object on which to synchronize

SynchronizedMap(Map<K,V> m) {
if (m==null)
throw new NullPointerException();
this.m = m;
mutex = this;
}

SynchronizedMap(Map<K,V> m, Object mutex) {
this.m = m;
this.mutex = mutex;
}

public int size() {
synchronized(mutex) {return m.size();}
}

//***********************************
//节省空间,删除了大量类似代码
//***********************************
public String toString() {
synchronized(mutex) {return m.toString();}
}
private void writeObject(ObjectOutputStream s) throws IOException {
synchronized(mutex) {s.defaultWriteObject();}
}
}
方法二原理:
重新写了HashMap,比较大的改变有如下几点.
使用了新的锁机制(可以理解为乐观锁)稍后详细介绍
把HashMap进行了拆分,拆分成了多个独立的块,这样在高并发的情况下减少了锁冲突的可能

public V put(K key, V value) {
if (value == null)
throw new NullPointerException();
int hash = hash(key.hashCode());
return segmentFor(hash).put(key, hash, value, false);
}

2)锁机制的不同
方法一使用的是的synchronized方法,是一种悲观锁.在进入之前需要获得锁,确保独享当前对象,然后做相应的修改/读取.

方法二使用的是乐观锁,只有在需要修改对象时,比较和之前的值是否被人修改了,如果被其他线程修改了,那么就会返回失败.锁的实现,使用的是NonfairSync. 这个特性要确保修改的原子性,互斥性,无法在JDK这个级别得到解决,JDK在此次需要调用JNI方法,而JNI则调用CAS指令来确保原子性与互斥性.读者可以自行Google JAVA CAS来了解更多. JAVA的乐观锁是如何实现的.
当如果多个线程恰好操作到ConcurrentHashMap同一个segment上面,那么只会有一个线程得到运行,其他的线程会被LockSupport.park(),稍后执行完成后,会自动挑选一个线程来执行LockSupport.unpark().
V put(K key, int hash, V value, boolean onlyIfAbsent) {
lock();
try {
int c = count;
if (c++ > threshold) // ensure capacity
rehash();
HashEntry<K,V>[] tab = table;
int index = hash & (tab.length - 1);
HashEntry<K,V> first = tab[index];
HashEntry<K,V> e = first;
while (e != null && (e.hash != hash || !key.equals(e.key)))
e = e.next;

            V oldValue;
            if (e != null) {
                oldValue = e.value;
                if (!onlyIfAbsent)
                    e.value = value;
            }
            else {
                oldValue = null;
                ++modCount;
                tab[index] = new HashEntry<K,V>(key, hash, first, value);
                count = c; // write-volatile
            }
            return oldValue;
        } finally {
            unlock();
        }
    }

3)如何得到/释放锁
得到锁:
方法一:在Hashmap上面,synchronized锁住的是对象(不是Class),所以第一个申请的得到锁,其他线程将进入阻塞,等待唤醒.
方法二:检查AbstractQueuedSynchronizer.state,如果为0,则得到锁,或者申请者已经得到锁,则也能再辞得到锁,并且state也加1.
释放锁:
都是得到锁的逆操作,并且使用正确,二种方法都是自动选取一个队列中的线程得到锁可以获得CPU资源
4)优缺点
方法一:
优点:代码实现十分简单,一看就懂.
缺点:从锁的角度来看,方法一直接使用了锁住方法,基本上是锁住了尽可能大的代码块.性能会比较差.
方法二:
优点:需要互斥的代码段比较少,性能会比较好. ConcurrentHashMap把整个Map切分成了多个块,发生锁碰撞的几率大大降低,性能会比较好.
缺点:代码实现稍稍复杂些。

18、ConcurrentHashMap的底层实现?JDK1.7与JDK1.8的区别

ConcurrentHashMap与HashMap等的区别
1.HashMap
我们知道HashMap是线程不安全的，在多线程环境下，使用Hashmap进行put操作会引起死循环，导致CPU利用率接近100%，所以在并发情况下不能使用HashMap。
2.HashTable
HashTable和HashMap的实现原理几乎一样，差别无非是
• HashTable不允许key和value为null
• HashTable是线程安全的
但是HashTable线程安全的策略实现代价却太大了，简单粗暴，get/put所有相关操作都是synchronized的，这相当于给整个哈希表加了一把大锁。
多线程访问时候，只要有一个线程访问或操作该对象，那其他线程只能阻塞，相当于将所有的操作串行化，在竞争激烈的并发场景中性能就会非常差。
3.ConcurrentHashMap
主要就是为了应对hashmap在并发环境下不安全而诞生的，ConcurrentHashMap的设计与实现非常精巧，大量的利用了volatile，final，CAS等lock-free技术来减少锁竞争对于性能的影响。
我们都知道Map一般都是数组+链表结构（JDK1.8该为数组+红黑树）。
ConcurrentHashMap避免了对全局加锁改成了局部加锁操作，这样就极大地提高了并发环境下的操作速度，由于ConcurrentHashMap在JDK1.7和1.8中的实现非常不同，接下来我们谈谈JDK在1.7和1.8中的区别。
JDK1.7版本的CurrentHashMap的实现原理
在JDK1.7中ConcurrentHashMap采用了数组+Segment+分段锁的方式实现。

1.Segment(分段锁)
ConcurrentHashMap中的分段锁称为Segment，它即类似于HashMap的结构，即内部拥有一个Entry数组，数组中的每个元素又是一个链表,同时又是一个ReentrantLock（Segment继承了ReentrantLock）。
2.内部结构
ConcurrentHashMap使用分段锁技术，将数据分成一段一段的存储，然后给每一段数据配一把锁，当一个线程占用锁访问其中一个段数据的时候，其他段的数据也能被其他线程访问，能够实现真正的并发访问。如下图是ConcurrentHashMap的内部结构图：

从上面的结构我们可以了解到，ConcurrentHashMap定位一个元素的过程需要进行两次Hash操作。
第一次Hash定位到Segment，第二次Hash定位到元素所在的链表的头部。
3.该结构的优劣势
坏处
这一种结构的带来的副作用是Hash的过程要比普通的HashMap要长

好处
写操作的时候可以只对元素所在的Segment进行加锁即可，不会影响到其他的Segment，这样，在最理想的情况下，ConcurrentHashMap可以最高同时支持Segment数量大小的写操作（刚好这些写操作都非常平均地分布在所有的Segment上）。
所以，通过这一种结构，ConcurrentHashMap的并发能力可以大大的提高。
JDK1.8版本的CurrentHashMap的实现原理
JDK8中ConcurrentHashMap参考了JDK8 HashMap的实现，采用了数组+链表+红黑树的实现方式来设计，内部大量采用CAS操作，这里我简要介绍下CAS。
CAS是compare and swap的缩写，即我们所说的比较交换。cas是一种基于锁的操作，而且是乐观锁。在java中锁分为乐观锁和悲观锁。悲观锁是将资源锁住，等一个之前获得锁的线程释放锁之后，下一个线程才可以访问。而乐观锁采取了一种宽泛的态度，通过某种方式不加锁来处理资源，比如通过给记录加version来获取数据，性能较悲观锁有很大的提高。
CAS 操作包含三个操作数 —— 内存位置（V）、预期原值（A）和新值(B)。如果内存地址里面的值和A的值是一样的，那么就将内存里面的值更新成B。CAS是通过无限循环来获取数据的，若果在第一轮循环中，a线程获取地址里面的值被b线程修改了，那么a线程需要自旋，到下次循环才有可能机会执行。

JDK8中彻底放弃了Segment转而采用的是Node，其设计思想也不再是JDK1.7中的分段锁思想。
Node：保存key，value及key的hash值的数据结构。其中value和next都用volatile修饰，保证并发的可见性。
class Node<K,V> implements Map.Entry<K,V> {
final int hash;
final K key;
volatile V val;
volatile Node<K,V> next;
//... 省略部分代码
}

Java8 ConcurrentHashMap结构基本上和Java8的HashMap一样，不过保证线程安全性。
在JDK8中ConcurrentHashMap的结构，由于引入了红黑树，使得ConcurrentHashMap的实现非常复杂，我们都知道，红黑树是一种性能非常好的二叉查找树，其查找性能为O（logN），但是其实现过程也非常复杂，而且可读性也非常差，DougLea的思维能力确实不是一般人能比的，早期完全采用链表结构时Map的查找时间复杂度为O（N），JDK8中ConcurrentHashMap在链表的长度大于某个阈值的时候会将链表转换成红黑树进一步提高其查找性能。

总结
其实可以看出JDK1.8版本的ConcurrentHashMap的数据结构已经接近HashMap，相对而言，ConcurrentHashMap只是增加了同步的操作来控制并发，从JDK1.7版本的ReentrantLock+Segment+HashEntry，到JDK1.8版本中synchronized+CAS+HashEntry+红黑树。
1.数据结构：取消了Segment分段锁的数据结构，取而代之的是数组+链表+红黑树的结构。
2.保证线程安全机制：JDK1.7采用segment的分段锁机制实现线程安全，其中segment继承自ReentrantLock。JDK1.8采用CAS+Synchronized保证线程安全。
3.锁的粒度：原来是对需要进行数据操作的Segment加锁，现调整为对每个数组元素加锁（Node）。
4.链表转化为红黑树:定位结点的hash算法简化会带来弊端,Hash冲突加剧,因此在链表节点数量大于8时，会将链表转化为红黑树进行存储。
5.查询时间复杂度：从原来的遍历链表O(n)，变成遍历红黑树O(logN)。

面试总结--java基础部分(4)