Java 八股文 持续修改更新...

文章目录

• 什么是面向对象,面向对象和面向过程之间的区别是什么？
• 封装，继承，多态，抽象（四个概念分别解释即可）
• OOA OOD OOP
• ORM 框架
• JDK JRE JVM
• == 和equals() 比较
• hashCode与equals
• final finally(try catch) finalize(gc回收)
• • final 最终的
• * 为什么局部内部类和匿名内部类只能访问局部final变量？编译之后会生成两个class文件，Test.class Test1.class
• String、StringBuffer、StringBuilder
• String 为什么设计成为不可变的？
• Serializable java.io.Serializable serialVersionUID
• • 什么是Java对象序列化
  • 如何保证序列化和反序列化后的对象一致？（如有异议望指正）
  • 小结：
• 重载和重写的区别
• 接口和抽象类的区别
• Java 集合 继承实现体系 idea Diagrams
• List接口和Set接口的区别
• ArrayList和LinkedList区别
• HashMap和HashTable有什么区别？其底层实现是什么？
• • 区别 ：
  • 2.哈希表底层实现：数组+链表实现
• ConcurrentHashMap原理，jdk7和jdk8版本的区别
• 什么是字节码？采用字节码的好处是什么？
• • java中的编译器和解释器：
  • 采用字节码的好处：
• Java中的异常体系
• • Java 异常关键字
  • Error 和 Exception 之间的区别是什么？
  • 受检异常和非受检异常之间的区别？
  • JVM 是怎么样处理异常的？
  • throw throws 之间的区别
  • finally final finalize(雷锋和雷峰塔之间的关系，毫无联系)
  • NoClassDefFoundError 和 ClassNotFoundException
  • try catch finally 中间什么环节可以省略？
  • 常见的运行时异常
• Java类加载器
• • GC如何判断对象可以被回收
• 线程、并发相关
• • 线程的生命周期？线程有几种状态？
  • sleep()、wait()、join()、yield()的区别

什么是面向对象,面向对象和面向过程之间的区别是什么？

对比面向过程，是两种不同的处理问题的角度
面向过程更注重事情的每一个步骤及顺序，面向对象更注重事情有哪些参与者（对象）、及各自需要做什么

面向过程是将某一个事情分为什么样子的流程进行处理

面向对象，完成意见事情，需要将现实世界中的物体抽象成为什么对象，各个对象之间是怎么相互配合完成这件事情的；

封装，继承，多态，抽象（四个概念分别解释即可）

封装：封装的意义，在于明确标识出允许外部使用的所有成员函数和数据项
内部细节对外部调用透明，外部调用无需修改或者关心内部实现

比如说：javabean的属性私有，提供getset对外访问，因为属性的赋值或者获取逻辑只能由javabean本身决定。而不能由外部胡乱修改

在Java 中每一个类就可以看做是一个封装，里面封装了成员变量，成员方法，具体的变量是什么，方法的内部是怎么编写的，外部不需要知道，外部只是需要知道怎么调用即可，达到了封装的目的

继承 父类对于子类进行继承，达到扩展复用的目的

多态对象所属类的不同，外部对同一个方法的调用，实际执行的逻辑不同。

怎么理解呢？
多态是需要继承的条件的，比如动物类，具体的动物类继承了动物类，父类中假设都存在一个叫的方法，但是具体的动物对象的叫声是不一样的，因为他们所属于的类别是不一样的，他们只是具体的动物类的实例；

多态实现需要的三个条件：继承，方法重写，父类引用指向子类对象

OOA OOD OOP

Obiect-Oriented Analysis
Design
Programing

ORM 框架

什么是ORM
即Object-Relationl Mapping对象关系模型，它的作用是在关系型数据库和对象之间作一个映射，这样，我们在具体的操作数据库的时候，就不需要再去和复杂的SQL语句打交道，只要像平时操作对象一样操作它就可以了。这就建立起来了类和数据库表之间的联系，通过对象的操作完成了数据库的操作；

JDK JRE JVM

JDK：
Java Develpment Kit java 开发工具
JRE：
Java Runtime Environment java运行时环境
JVM：
java Virtual Machine java 虚拟机

JDK（开发Java 程序，执行编译等操作） > JRE（包含一些基本类库，操作文件、怎么连接网络） > JVM(处理编译好的 .class 文件)

== 和equals() 比较

== 比较的是两个对象之间的地址

在自己编写的类中如果自己不重写 equals() 方法，底层任然是比较地址，具体来说比较的是的对象的地址；

在我们尝试用的 String 这个数据类型中，它的源代码是重写了 equals 方法的，比较的规则是比较字符串的内容；

一个是比较的运算符号，一个是比较的方法，一般来讲， == 只是会简单的比较数值，引用数据类型会比较地址，equals() 方法一般与 == 没有区别，但是在方法体中，可以添加自己的比较逻辑；

hashCode与equals

这两个值主要是在哈希表的元素存储过程中发挥作用；

为什么出现了哈希表这种数据结构？
因为传统的单一使用数组或者链表进行元素存储的时候，要么是数组满足了检索内容快速，要么满足了链表的插入元素快速，都存在一定的缺点，在数据量越来越大的时代，上面的两种数据结构显然不能满足需求，所以创造出来了哈希表，既满足了一定的查询能力，也达到了在插入删除中有一定的效率；

hashCode介绍：
hashCode() 的作用是获取哈希码，也称为散列码；它实际上是返回一个int整数。这个哈希码（哈希码通过一定的运算可以获取到在数组中的下标）的作用是确定该对象在哈希表中的索引位置。

哈希函数 = hashCode() + 取模运算

hashCode() 定义在JDK的Object.java中，Java中的任何类都包含有 hashCode() 函数。
散列表存储的是键值对(key-value)，它的特点是：能根据“键”快速的检索出对应的“值”。这其中就利用到了散列码！（可以快速找到所需要的对象）

为什么要有hashCode：
以“HashSet（无序不重复的数据结构）如何检查重复”为例子来说明为什么要有hashCode：对象加入HashSet时，HashSet会先计算对象的hashcode值来判断对象加入的位置，看该位置是否有值，如果没有、HashSet会假设对象没有重复出现。但是如果发现有值，这时会调用equals（）方法来检查两个对象是否真的相同。如果两者相同，HashSet就不会让其加入操作成功。如果不同的话，就会重新散列到其他位置。这样就大大减少了equals的次数，相应就大大提高了执行速度。

如果两个对象相等，则hashcode一定也是相同的两个对象相等,对两个对象分别调用equals方法都返回true 两个对象有相同的hashcode值，它们也不一定是相等的因此，equals方法被覆盖过，则hashCode方法也必须被覆盖
hashCode()的默认行为是对堆上的对象产生独特值。如果没有重写hashCode()，则该class的两个对象无论如何都不会相等（即使这两个对象指向相同的数据）

final finally(try catch) finalize(gc回收)

final 最终的

修饰类：类不可继承
修饰方法：方法不可被子类覆盖(不能重写)，但是可以重载(因为重载了之后就是一个新的方法，新方法的怎么修改和当前方法的 final 没有关系)
修饰变量：表示变量一旦被赋值就不可以更改它的值。
（1） 修饰成员变量
如果final修饰的是类变量，只能在静态初始化块中指定初始值或者声明该类变量时指定初始值。
如果final修饰的是实例变量，可以在非静态初始化块、声明该变量或者构造器中执行初始值。
（2） 修饰局部变量
系统不会为局部变量进行初始化，局部变量必须由程序员显示初始化。因此使用final修饰局部变量时，即可以在定义时指定默认值（后面的代码不能对变量再赋值），也可以不指定默认值，而在后面的代码中对final变量赋初值（仅一次）
（3）修饰基本类型数据和引用类型数据
如果是基本数据类型的变量，则其数值一旦在初始化之后便不能更改；如果是引用类型的变量，则在对其初始化之后便不能再让其指向另一个对象。但是引用的值是可变的（指向的地址不能变化的，但是地址中保存的值是可以改变的）。

* 为什么局部内部类和匿名内部类只能访问局部final变量？编译之后会生成两个class文件，Test.class Test1.class

首先需要知道的一点是: 内部类和外部类是处于同一个级别的，内部类不会因为定义在方法中就会随着方法的执行完毕就被销毁。

这里就会产生问题：当外部类的方法结束时，局部变量就会被销毁了，但是内部类对象可能还存在(只有没有人再引用它时，才会死亡)。这里就出现了一个矛盾：内部类对象访问了一个不存在的变量。为了解决这个问题，就将局部变量复制了一份作为内部类的成员变量，这样当局部变量死亡后，内部类仍可以访问它，实际访问的是局部变量的"copy"。这样就好像延长了局部变量的生命周期

将局部变量复制为内部类的成员变量时，必须保证这两个变量是一样的，也就是如果我们在内部类中修改了成员变量，方法中的局部变量也得跟着改变，怎么解决问题呢？

就将局部变量设置为final，对它初始化后，我就不让你再去修改这个变量，就保证了内部类的成员变量和方法的局部变量的一致性。这实际上也是一种妥协。使得局部变量与内部类内建立的拷贝保持一致，设置成为 final 的原因。

String、StringBuffer、StringBuilder

String类是final修饰的 维护的数组是 privite final 修饰的，不可变，每次操作都会产生新的String对象

StringBuffer和StringBuilder都是在原对象上操作

StringBuffer是线程安全的，StringBuilder线程不安全的

StringBuffer方法都是synchronized修饰的

性能：StringBuilder > StringBuffer > String

场景：经常需要改变字符串内容时使用后面两个
优先使用StringBuilder，多线程使用共享变量时使用StringBuffer

String 为什么设计成为不可变的？

1、线程以及网络传输安全问题
不可变对象天生就是线程安全的：因为不可变对象不能被改变，所以他们可以自由地在多个线程之间共享。不需要任何同步处理。在网络连接和数据库连接中字符串常常作为参数，例如，网络连接地址URL，文件路径path，反射机制所需要的String参数。其不可变性可以保证连接的安全性。如果字符串是可变的，黑客就有可能改变字符串指向对象的值，那么会引起很严重的安全问题。

2、减少内存开支，使用字符串常量池思想
便于实现字符串池：在Java中，由于会大量的使用String常量，如果每一次声明一个String都创建一个String对象，那将会造成极大的空间资源的浪费。Java提出了String pool的概念，在堆中开辟一块存储空间String pool，当初始化一个String变量时，如果该字符串已经存在了，就不会去创建一个新的字符串变量，而是会返回已经存在了的字符串的引用。（已经存在于常量池的字符串就不创建了，不可以变化）

3、作为 key 可以在 哈希表中存储元素，使得哈希冲突减少
加快字符串处理速度由于String是不可变的，保证了hashcode的唯一性，于是在创建对象时其hashcode就可以放心的缓存了，不需要重新计算。这也就是Map喜欢将String作为Key的原因，处理速度要快过其它的键对象。所以HashMap中的键往往都使用String。

Serializable java.io.Serializable serialVersionUID

什么是Java对象序列化

在 为什么要用序列化与反序列化 之前我们先了解一下对象序列化的两种用途：

把对象的字节序列永久地保存到硬盘上，通常存放在一个文件中；
在网络上传送对象的字节序列。
我们可以想想如果没有序列化之前，又是怎样一种情景呢？

举例：
Web 服务器中的 Session 会话对象，当有10万用户并发访问，就有可能出现10万个 Session 对象，显然这种情况内存可能是吃不消的。

于是 Web 容器就会把一些 Session 先序列化，让他们离开内存空间，序列化到硬盘中，当需要调用时，再把保存在硬盘中的对象还原到内存中。

序列化之后，可以进行反序列化得到，序列化之前的内容，能不能反序列化一个重要的点就是比较序列化版本号是不是一致的；保证数据的传输安全；

序列化版本号：验证类版本一致性的，JVM 会判断传进来的字节流中的版本号和本地实体类的版本号是不是一样的，不一样就会报出来异常；

自动生成的版本号在类发生变化之后，版本号是会发生变化的JVM会认为是两个类，但是自定义的版本号，即使修改了类中的属性，JVM还是认为是同一个类；

如何保证序列化和反序列化后的对象一致？（如有异议望指正）

对于这个问题我在查阅了一些资料之后，发现并不能保证序列化和反序列化之后的对象是一致的，因为我们在反序列化的过程中，是先创建一个对象，然后再通过对对象进行赋值来完成对象的反序列化，这样问题就来了，在创建了一个新的对象之后，如果对象引用和原本的对象并不是指向同一个目标。因此我们只能保证他们的数据和版本一致，并不能保证对象一致。

序列化以及反序列化保存的是当前对象的状态，至于什么引用指向它，不是很重要，因为反序列化之后，一定是使用一个新的对象指向反序列化的这个对象，所以这个对象肯定是不一致的；

可以按照上面的理解

小结：

序列化的是Java 对象，目的是将 Java对象序列化，进而持久化，等到需要的时候在进行反序列化，减少内存压力；或者是进行网络上面的数据传输，需要将传送的数据序列化，方便传输；

序列化版本号比较的是创建对象的类，判断是不是同一个类，默认产生的序列化版本号在类发生变化时，版本号会发生改变；如果类的序列化版本号自己写定了，那么类的改变，序列化版本号是不会发生改变的；

只有类的改变才会改变序列化版本号，自定义的序列化版本号即使类改变了，版本号还是不变的；对象的数据的修改是不会影响反序列化的结果的；

什么是序列化以及反序列化理解
序列化的方式
序列化写的不错的博客

重载和重写的区别

重载： 发生在同一个类中，方法名必须相同，参数类型、个数、顺序，方法返回值和访问修饰符可以不同，发生在编译时。

重写： 发生在父子类中，方法名、参数列表必须相同，返回值范围小于等于父类，抛出的异常范围小于等于父类，访问修饰符范围大于等于父类；如果父类方法访问修饰符为private则子类就不能重写该方法。（Override）

接口和抽象类的区别

1.语法层面上的区别（两者之间语法定义是不一样的）

抽象类具有类的特征，但是接口就是接口，一个行为的规范；

抽象类可以提供成员方法的实现细节，而接口中只能存在public abstract 方法；
抽象类中的成员变量可以是各种类型的，而接口中的成员变量只能是public static final类型的；
接口中不能含有静态代码块以及静态方法，而抽象类可以有静态代码块和静态方法；
一个类只能继承一个抽象类，而一个类却可以实现多个接口。2.设计层面上的区别

2.设计层面上的区别
抽象类是对于一类物体的再次抽象，可以理解为类的抽象
接口是定义了一系列的规范，方法，实现接口，必须实现里面定义的方法；就像实现抽象类必须实现抽象方法一样，接口更加的纯粹，只是关注某些行为规范的实现

Java 集合 继承实现体系 idea Diagrams

List接口和Set接口的区别

在Java 中这两着的具体实现都是接口，里面规定了一系列的对于数据的操作方法；
List：有序，按对象进入的顺序保存对象，可重复，允许多个Null元素对象(因为可以重复存在元素，当然包括了可以重复的存在 null 元素)，可以使用Iterator取出所有元素 for 加强 for（需要知道里面的数据类型），在逐一遍历，还可以使用get(int index)获取指定下标的元素

Set：无序，不可重复， 多允许有一个Null元素对象（因为不能重复元素，所以不能存在两个 null），取元素时只能用Iterator接口取得所有元素，在逐一遍历各个元素

ArrayList和LinkedList区别

ArrayList：基于动态数组，连续内存存储，适合下标访问（随机访问），扩容机制：初始化容量为10,对于这个初始化容量的理解是，当 ArrayList 为空的时候初始化容量为 0 ，但是当添加了第一个元素的时候，这个时候，将容量变为10，接下来的扩容操作中，扩容因子为 1.5；
因为数组长度固定，超出长度存数据时需要新建数组，然后将老数组的数据拷贝到新数组，如果不是尾部插入数据还会涉及到元素的移动（往后复制一份，插入新元素），使用尾插法并指定初始容量可以极大提升性能、甚至超过linkedList（需要创建大量的node对象）

LinkedList：基于双向链表，可以存储在分散的内存中，适合做数据插入及删除操作，不适合查询：需要逐一遍历
遍历LinkedList必须使用iterator不能使用for循环，因为每次for循环体内通过get(i)取得某一元素时都需要对list重新进行遍历，性能消耗极大。
另外不要试图使用indexOf等返回元素索引，并利用其进行遍历，使用indexlOf对list进行了遍历，当结果为空时会遍历整个列表。

HashMap和HashTable有什么区别？其底层实现是什么？

区别 ：

（1） HashMap方法没有synchronized修饰，线程非安全，HashTable线程安全；
（2） HashMap允许key和value为null，而HashTable不允许

2.哈希表底层实现：数组+链表实现

jdk8开始链表高度到8并且数组长度超过64，链表转变为红黑树，元素以内部类Node节点存在;

1、计算key的hash值，二次hash然后对数组长度取模，对应到数组下标，如果没有产生hash冲突，则直接创建Node存入数组，如果产生hash冲突，先进行equal比较，相同则取代该元素
2、否则则判断链表高度插入链表，链表高度达到8，并且数组长度到64则转变为红黑树，长度低于6则将红黑树转回链表 key 为 null，存在下标0的位置数组扩容

ConcurrentHashMap原理，jdk7和jdk8版本的区别

HahsMap 以及 CurrentHashMap 之间的区别以及联系
作者自己整理的博客

什么是字节码？采用字节码的好处是什么？

java中的编译器和解释器：

Java中引入了虚拟机的概念，即在机器和编译程序之间加入了一层抽象的虚拟的机器。这台虚拟的机器在任何平台上都提供给编译程序一个的共同的接口。

编译程序只需要面向虚拟机，生成虚拟机能够理解的代码，然后由解释器来将虚拟机代码转换为特定系统的机器码执行。在Java中，这种供虚拟机理解的代码叫做 字节码（即扩展名为 .class的文件），它不面向任何特定的处理器，只面向虚拟机。

每一种平台的解释器是不同的，但是实现的虚拟机是相同的。Java源程序经过编译器编译后变成字节码，字节码由虚拟机解释执行，虚拟机将每一条要执行的字节码送给解释器，解释器将其翻译成特定机器上的机器码，然后在特定的机器上运行。这也就是解释了Java的编译与解释并存的特点。

c++ 只有编译器，Python 只有解释器，Java 编译器和解释器都存在；C++ 键盘敲出来的代码是可以跨平台编译的，编译成为不同的文件在不同的环境下面运行，但是在一个环境下面编译的文件在另外的环境中是没有办法跨平台的；但是 Java 可以，源代码和 .class 文件都是可以跨平台的，因为 Java 有虚拟机；

Java 从键盘编写的 .java 文件到具体的执行中间经历的所有过程：

Java源代码---->编译器---->jvm可执行的Java字节码(即虚拟指令)---->jvm---->jvm中解释器---->机器可执行的二进制机器码---->程序运行

采用字节码的好处：

Java语言通过字节码的方式，在一定程度上解决了传统解释型语言执行效率低的问题，同时又保留了解释型语言可移植的特点。所以Java程序运行时比较高效，而且，由于字节码并不专对一种特定的机器，因此，Java程序无须重新编译便可在多种不同的计算机上运行。

Java中的异常体系

Java中的所有异常都来自顶级父类Throwable

Throwable下有两个子类Exception和Error：

Error是程序无法处理的错误，一旦出现这个错误，则程序将被迫停止运行

Exception不会导致程序停止，又分为两个部分RunTimeException运行时异常和CheckedException检查异常。

RunTimeException常常发生在程序运行过程中，会导致程序当前线程执行失败。CheckedException常常发生在程序编译过程中，会导致程序编译不通过。

RunTImeExceptin 和 Error 的区别
非检查型异常也就是RunTImeExceptin，通常是可以通过编码加以避免的逻辑错误，具体根据需要来判断是否需要捕获，并不会在编译期强制要求，比如空指针异常，是非受检异常；

Error则是指在正常情况下，不大可能出现的情况，绝大部分的Error都会导致程序（比如JVM）处于非正常的、不可恢复状态。既然是非正常情况，所以不便于也不需要捕获，常见的比如OutOfMemoryError，其为Error的子类，具体的异常类型查看上面的思维导图；

Java 异常关键字

finally：总是会执行的，主要用于回收在 try 语句块中打开的资源，在 finally 使用了 return 或者 throw 等终止方法之后，就不跳回执行，会直接停止；

阻止 finally 执行的代码实例：

   try {
   // do something
       System.exit(1);
   } finally {
       System.out.println("Hello，I am finally。");
   }

程序进入死循环，不会执行 finally

  try{
      while(true){
          System.out.println("always run");
      }
  }finally{
      System.out.println("ummm");
  }

正在执行的线程被杀死的时候，里面的 finally 也是不会执行的

// 线程被杀死
当执行 try-finally 的线程被杀死时，finally 中的代码也无法执行。

下面的这个情况是会执行 finally 的；

   try {
   // do something
       return;
   } finally {
       System.out.println("Hello，I am finally。");
   }

下面的情况下也是会执行的

   try{
       System.out.println("csd");
   }finally{
       System.out.println("ummm");
       return;
   }

catch 语句里面存在 return finally 也是会执行的

Error 和 Exception 之间的区别是什么？

Error 经常是虚拟机发生的错误，比如系统崩溃，内存不够等错误，这个错误是不会编译器检查的，一旦发生这个错误，程序直接终止退出

受检异常和非受检异常之间的区别？

受检异常在编译时一般就必须要进行处理，非受检异常表示的是程序运行时候产生的异常，Java 编译器不会检查这类异常，常见的有空指针异常和超出索引异常；受检异常常见的有IO异常以及 AWT 异常;

关于运行时异常以及受检异常，受检异常是强制调用者必须处理的，相反需要使用运行时异常，一般来讲推荐使用运行时异常；

JVM 是怎么样处理异常的？

在一个方法中发生了异常。这个方法会创建出来一个异常对象，转交给JVM；
这个异常对象包含有：异常的名称，异常描述，以及异常时候，程序的调用状态；
创建异常对象并且交给 JVM 这个过程叫做异常的抛出，随着方法之间的相互调用，最终才会进入异常的方法，这一系列的方法的调用叫做调用栈；

JVM 会先尝试是不是存在有处理异常的代码，将异常传递给可以处理的代码，实在没有代码可以处理，就终止程序的运行；

throw throws 之间的区别

throw 在程序中抛出一个异常
throws 在方法申明上面抛出一个或者多个异常；

finally final finalize(雷锋和雷峰塔之间的关系，毫无联系)

finalize 的执行是和垃圾收集关联在一起的，一旦实现了非空的 finalize 方法，就会导致相应对象回收呈现数量级上的变慢、

final 类无法被继承，方法无法被重写，变量无法重新赋值；

NoClassDefFoundError 和 ClassNotFoundException

NoClassDefFoundError 是一个 Error 类型的异常，是由 JVM 引起的，不应该尝试捕获这个异常。

引起该异常的原因是 JVM 或 ClassLoader 尝试加载某类时在内存中找不到该类的定义，该动作发生在运行期间，即编译时该类存在，但是在运行时却找不到了，可能是变异后被删除了等原因导致；

ClassNotFoundException 是一个受查异常，需要显式地使用 try-catch 对其进行捕获和处理，或在方法签名中用 throws 关键字进行声明。当使用 Class.forName, ClassLoader.loadClass 或 ClassLoader.findSystemClass 动态加载类到内存的时候，通过传入的类路径参数没有找到该类，就会抛出该异常；另一种抛出该异常的可能原因是某个类已经由一个类加载器加载至内存中，另一个加载器又尝试去加载它。

try catch finally 中间什么环节可以省略？

catch 是可以省略的
单独的使用 try 可以处理运行时异常，try + catch 可以处理运行时异常以及受检异常，但是在一段程序中，只是存在运行时异常的话，是可以不使用 catch 的；

常见的运行时异常

ClassCastException(类转换异常)
IndexOutOfBoundsException(数组越界)
NullPointerException(空指针)
ArrayStoreException(数据存储异常，操作数组时类型不一致)
还有IO操作的BufferOverflowException异常

Java类加载器

 JDK自带有三个类加载器：
 bootstrap ClassLoader
 ExtClassLoader
 AppClassLoader
 
BootStrapClassLoader是ExtClassLoader的父类加载器，默认负责加载%JAVA_HOME%lib下的jar包和 class文件；
  
ExtClassLoader是AppClassLoader的父类加载器，负责加载%JAVA_HOME%/lib/ext文件夹下的jar包和 class类

AppClassLoader是自定义类加载器的父类，负责加载classpath下的类文件。系统类加载器，线程上下文加载器继承ClassLoader实现自定义类加载器

双亲委托模型
双亲委派模型的好处：
主要是为了安全性，避免用户自己编写的类动态替换 Java的一些核心类，比如 String。
同时也避免了类的重复加载，因为 JVM中区分不同类，不仅仅是根据类名，相同的 class文件被不同的 ClassLoader加载就是不同的两个类

GC如何判断对象可以被回收

引用计数法：每个对象有一个引用计数属性，新增一个引用时计数加1，引用释放时计数减1，计数为0时可以回收，可达性分析法：从 GC Roots 开始向下搜索，搜索所走过的路径称为引用链。当一个对象到 GC
Roots 没有任何引用链相连时，则证明此对象是不可用的，那么虚拟机就判断是可回收对象。
引用计数法，可能会出现A 引用了 B，B 又引用了 A，这时候就算他们都不再使用了，但因为相互引用 计数器=1 永远无法被回收。
GC Roots的对象有：
虚拟机栈(栈帧中的本地变量表）中引用的对象方法区中类静态属性引用的对象
方法区中常量引用的对象
本地方法栈中JNI(即一般说的Native方法)引用的对象可达性算法中的不可达对象并不是立即死亡的，对象拥有一次自我拯救的机会。对象被系统宣告死亡至少要经历两次标记过程：第一次是经过可达性分析发现没有与GC Roots相连接的引用链，第二次是在由虚拟机自动建立的Finalizer队列中判断是否需要执行finalize()方法。
当对象变成(GC Roots)不可达时，GC会判断该对象是否覆盖了finalize方法，若未覆盖，则直接将其回收。否则，若对象未执行过finalize方法，将其放入F-Queue队列，由一低优先级线程执行该队列中对象的finalize方法。执行finalize方法完毕后，GC会再次判断该对象是否可达，若不可达，则进行回收，否则，对象“复活”
每个对象只能触发一次finalize()方法
由于finalize()方法运行代价高昂，不确定性大，无法保证各个对象的调用顺序，不推荐大家使用，建议遗忘它。

线程、并发相关

线程的生命周期？线程有几种状态？

1.线程通常有五种状态，创建，就绪，运行、阻塞和死亡状态。
1.新建状态（New）：新创建了一个线程对象。
2.就绪状态（Runnable）：线程对象创建后，其他线程调用了该对象的start方法。该状态的线程位于可运行线程池中，变得可运行，等待获取CPU的使用权。
3.运行状态（Running）：就绪状态的线程获取了CPU，执行程序代码。
4.阻塞状态（Blocked）：阻塞状态是线程因为某种原因放弃CPU使用权，暂时停止运行。直到线程进入就绪状态，才有机会转到运行状态。
5.死亡状态（Dead）：线程执行完了或者因异常退出了run方法，该线程结束生命周期。

2.阻塞的情况又分为三种：
(1)、等待阻塞：运行的线程执行wait方法，该线程会释放占用的所有资源，JVM会把该线程放入“等待池”中。进入这个状态后，是不能自动唤醒的，必须依靠其他线程调用notify或notifyAll方法才能被唤醒，wait是object类的方法
(2)、同步阻塞：运行的线程在获取对象的同步锁时，若该同步锁被别的线程占用，则JVM会把该线程放入“锁池”中。
(3)、其他阻塞：运行的线程执行sleep或join方法，或者发出了I/O请求时，JVM会把该线程置为阻塞状
态。当sleep状态超时、join等待线程终止或者超时、或者I/O处理完毕时，线程重新转入就绪状态。

sleep()、wait()、join()、yield()的区别

sleep是Thread类的方法
1.锁池
所有需要竞争同步锁的线程都会放在锁池当中，比如当前对象的锁已经被其中一个线程得到，则其他线程需要在这个锁池进行等待，当前面的线程释放同步锁后锁池中的线程去竞争同步锁，当某个线程得到后会进入就绪队列进行等待cpu资源分配。
2.等待池
当我们调用wait（）方法后，线程会放到等待池当中，等待池的线程是不会去竞争同步锁。只有调用了 notify（）或notifyAll()后等待池的线程才会开始去竞争锁，notify（）是随机从等待池选出一个线程放到锁池，而notifyAll()是将等待池的所有线程放到锁池当中

1、 sleep 是 Thread 类的静态本地方法，wait 则是 Object 类的本地方法。
2、 sleep方法不会释放lock，但是wait会释放，而且会加入到等待队列中。
sleep就是把cpu的执行资格和执行权释放出去，不再运行此线程，当定时时间结束再取回cpu资源，参与cpu 的调度，获取到cpu资源后就可以继续运行了。而如果sleep时该线程有锁，那么sleep不会释放这个锁，而是把锁带着进入了冻结状态，也就是说其他需要这个锁的线程根本不可能获取到这个锁。也就是说无法执行程序。如果在睡眠期间其他线程调用了这个线程的interrupt方法，那么这个线程也会抛出 interruptexception异常返回，这点和wait是一样的。

3、 sleep方法不依赖于同步器synchronized，但是wait需要依赖synchronized关键字。
4、 sleep不需要被唤醒（休眠之后推出阻塞），但是wait需要（不指定时间需要被别人中断）。
5、 sleep 一般用于当前线程休眠，或者轮循暂停操作，wait 则多用于多线程之间的通信。
6、 sleep 会让出 CPU 执行时间且强制上下文切换，而 wait 则不一定，wait 后可能还是有机会重新竞争到锁继续执行的。

yield（）执行后线程直接进入就绪状态，马上释放了cpu的执行权，但是依然保留了cpu的执行资格，所以有可能cpu下次进行线程调度还会让这个线程获取到执行权继续执行
join（）执行后线程进入阻塞状态，例如在线程B中调用线程A的join（），那线程B会进入到阻塞队列，直到线程A结束或中断线程

对线程安全的理解

不是线程安全、应该是内存安全，堆是共享内存，可以被所有线程访问
当多个线程访问一个对象时，如果不用进行额外的同步控制或其他的协调操作，调用这个对象的行为都可以获得正确的结果，我们就说这个对象是线程安全的
堆是进程和线程共有的空间，分全局堆和局部堆。全局堆就是所有没有分配的空间，局部堆就是用户分配的空间。堆在操作系统对进程初始化的时候分配，运行过程中也可以向系统要额外的堆，但是用完了要还给操作系统，要不然就是内存泄漏。
在Java中，堆是Java虚拟机所管理的内存中 大的一块，是所有线程共享的一块内存区域，在虚拟机启动时创建。堆所存在的内存区域的唯一目的就是存放对象实例，几乎所有的对象实例以及数组都在这里分配内存。
栈是每个线程独有的，保存其运行状态和局部自动变量的。栈在线程开始的时候初始化，每个线程的栈互相独立，因此，栈是线程安全的。操作系统在切换线程的时候会自动切换栈。栈空间不需要在高级语言里面显式的分配和释放。

目前主流操作系统都是多任务的，即多个进程同时运行。为了保证安全，每个进程只能访问分配给自己的内存空间，而不能访问别的进程的，这是由操作系统保障的。
在每个进程的内存空间中都会有一块特殊的公共区域，通常称为堆（内存）。进程内的所有线程都可以访问到该区域，这就是造成问题的潜在原因。

Thread、Runable的区别

Thread和Runnable的实质是继承关系，没有可比性。无论使用Runnable还是Thread，都会new
Thread，然后执行run方法。用法上，如果有复杂的线程操作需求，那就选择继承Thread，如果只是简单的执行一个任务，那就实现runnable。

原因是：MyThread创建了两个实例，自然会卖出两倍，属于用法错误

对守护线程的理解

守护线程：为所有非守护线程提供服务的线程；任何一个守护线程都是整个JVM中所有非守护线程的保姆；
守护线程类似于整个进程的一个默默无闻的小喽喽；它的生死无关重要，它却依赖整个进程而运行；哪天其他线程结束了，没有要执行的了，程序就结束了，理都没理守护线程，就把它中断了；
注意： 由于守护线程的终止是自身无法控制的，因此千万不要把IO、File等重要操作逻辑分配给它；因为它不靠谱；
守护线程的作用是什么？举例， GC垃圾回收线程：就是一个经典的守护线程，当我们的程序中不再有任何运行的Thread,程序就不会再产生垃圾，垃圾回收器也就无事可做，所以当垃圾回收线程是JVM上仅剩的线程时，垃圾回收线程会自动离开。它始终在低级别的状态中运行，用于实时监控和管理系统中的可回收资源。
应用场景：（1）来为其它线程提供服务支持的情况；（2） 或者在任何情况下，程序结束时，这个线程必须正常且立刻关闭，就可以作为守护线程来使用；反之，如果一个正在执行某个操作的线程必须要正确地关闭掉否则就会出现不好的后果的话，那么这个线程就不能是守护线程，而是用户线程。通常都是些关键的事务，比方说，数据库录入或者更新，这些操作都是不能中断的。
thread.setDaemon(true)必须在thread.start()之前设置，否则会跑出一个
IllegalThreadStateException异常。你不能把正在运行的常规线程设置为守护线程。
在Daemon线程中产生的新线程也是Daemon的。
守护线程不能用于去访问固有资源，比如读写操作或者计算逻辑。因为它会在任何时候甚至在一个操作的中间发生中断。
Java自带的多线程框架，比如ExecutorService，会将守护线程转换为用户线程，所以如果要使用后台线程就不能用Java的线程池。

ThreadLocal的原理和使用场景
每一个Thread对象均含有一个ThreadLocalMap类型的成员变量threadLocals，它存储本线程中所有ThreadLocal对象及其对应的值
ThreadLocalMap由一个个Entry对象构成
Entry继承自WeakReference<ThreadLocal<?>>，一个Entry由ThreadLocal对象和Object构成。由此可见，Entry的key是ThreadLocal对象，并且是一个弱引用。当没指向key的强引用后，该 key就会被垃圾收集器回收
当执行set方法时，ThreadLocal首先会获取当前线程对象，然后获取当前线程的ThreadLocalMap对象。再以当前ThreadLocal对象为key，将值存储进ThreadLocalMap对象中。
get方法执行过程类似。ThreadLocal首先会获取当前线程对象，然后获取当前线程的ThreadLocalMap 对象。再以当前ThreadLocal对象为key，获取对应的value。由于每一条线程均含有各自私有的ThreadLocalMap容器，这些容器相互独立互不影响，因此不会存在线程安全性问题，从而也无需使用同步机制来保证多条线程访问容器的互斥性。

使用场景：
1、 在进行对象跨层传递的时候，使用ThreadLocal可以避免多次传递，打破层次间的约束。
2、 线程间数据隔离
3、 进行事务操作，用于存储线程事务信息。
4、 数据库连接，Session会话管理。
Spring框架在事务开始时会给当前线程绑定一个Jdbc Connection,在整个事务过程都是使用该线程绑定的 connection来执行数据库操作，实现了事务的隔离性。Spring框架里面就是用的ThreadLocal来实现这种隔离

ThreadLocal内存泄露原因，如何避免

内存泄露为程序在申请内存后，无法释放已申请的内存空间，一次内存泄露危害可以忽略，但内存泄露堆积后果很严重，无论多少内存,迟早会被占光，
不再会被使用的对象或者变量占用的内存不能被回收，就是内存泄露。

强引用：使用 普遍的引用(new)，一个对象具有强引用，不会被垃圾回收器回收。当内存空间不足，
Java虚拟机宁愿抛出OutOfMemoryError错误，使程序异常终止，也不回收这种对象。如果想取消强引用和某个对象之间的关联，可以显式地将引用赋值为null，这样可以使JVM在合适的时间就会回收该对象。
弱引用：JVM进行垃圾回收时，无论内存是否充足，都会回收被弱引用关联的对象。在java中，用 java.lang.ref.WeakReference类来表示。可以在缓存中使用弱引用。

ThreadLocal的实现原理，每一个Thread维护一个ThreadLocalMap，key为使用弱引用的ThreadLocal 实例，value为线程变量的副本

hreadLocalMap使用ThreadLocal的弱引用作为key，如果一个ThreadLocal不存在外部强引用时， Key(ThreadLocal)势必会被GC回收，这样就会导致ThreadLocalMap中key为null， 而value还存在着强引用，只有thead线程退出以后,value的强引用链条才会断掉，但如果当前线程再迟迟不结束的话，这些key为null的Entry的value就会一直存在一条强引用链（红色链条） key 使用强引用
当hreadLocalMap的key为强引用回收ThreadLocal时，因为ThreadLocalMap还持有ThreadLocal的强引用，如果没有手动删除，ThreadLocal不会被回收，导致Entry内存泄漏。
key 使用弱引用
当ThreadLocalMap的key为弱引用回收ThreadLocal时，由于ThreadLocalMap持有ThreadLocal的弱引用，即使没有手动删除，ThreadLocal也会被回收。当key为null，在下一次ThreadLocalMap调用 set(),get()，remove()方法的时候会被清除value值。

因此，ThreadLocal内存泄漏的根源是：由于ThreadLocalMap的生命周期跟Thread一样长，如果没有手动删除对应key就会导致内存泄漏，而不是因为弱引用。
ThreadLocal正确的使用方法
每次使用完ThreadLocal都调用它的remove()方法清除数据
将ThreadLocal变量定义成private static，这样就一直存在ThreadLocal的强引用，也就能保证任何时候都能通过ThreadLocal的弱引用访问到Entry的value值，进而清除掉 。

并发、并行、串行的区别

串行在时间上不可能发生重叠，前一个任务没搞定，下一个任务就只能等着并行在时间上是重叠的，两个任务在同一时刻互不干扰的同时执行。
并发允许两个任务彼此干扰。统一时间点、只有一个任务运行，交替执行

并发的三大特性

原子性是指在一个操作中cpu不可以在中途暂停然后再调度，即不被中断操作，要不全部执行完成，要不都不执行。就好比转账，从账户A向账户B转1000元，那么必然包括2个操作：从账户A减去1000元，往账户B加上1000元。2个操作必须全部完成。

那程序中原子性指的是 小的操作单元，比如自增操作，它本身其实并不是原子性操作，分了3步的，包括读取变量的原始值、进行加1操作、写入工作内存。所以在多线程中，有可能一个线程还没自增完，可能才执行到第二部，另一个线程就已经读取了值，导致结果错误。那如果我们能保证自增操作是一个原子性的操作，那么就能保证其他线程读取到的一定是自增后的数据。
关键字：synchronized 可见性
当多个线程访问同一个变量时，一个线程修改了这个变量的值，其他线程能够立即看得到修改的值。
若两个线程在不同的cpu，那么线程1改变了i的值还没刷新到主存，线程2又使用了i，那么这个i值肯定还是之前的，线程1对变量的修改线程没看到这就是可见性问题。

如果线程2改变了stop的值，线程1一定会停止吗？不一定。当线程2更改了stop变量的值之后，但是还没来得及写入主存当中，线程2转去做其他事情了，那么线程1由于不知道线程2对stop变量的更改，因此还会一直循环下去。
关键字：volatile、synchronized、final
有序性
虚拟机在进行代码编译时，对于那些改变顺序之后不会对 终结果造成影响的代码，虚拟机不一定会按照我们写的代码的顺序来执行，有可能将他们重排序。实际上，对于有些代码进行重排序之后，虽然对变量的值没有造成影响，但有可能会出现线程安全问题。

write方法里的1和2做了重排序，线程1先对flag赋值为true，随后执行到线程2，ret直接计算出结果，再到线程1，这时候a才赋值为2,很明显迟了一步
关键字：volatile、synchronized
volatile本身就包含了禁止指令重排序的语义，而synchronized关键字是由“一个变量在同一时刻只允许一条线程对其进行lock操作”这条规则明确的。

synchronized关键字同时满足以上三种特性，但是volatile关键字不满足原子性。
在某些情况下，volatile的同步机制的性能确实要优于锁(使用synchronized关键字或 java.util.concurrent包里面的锁)，因为volatile的总开销要比锁低。
我们判断使用volatile还是加锁的唯一依据就是volatile的语义能否满足使用的场景(原子性)

volatile

1. 保证被volatile修饰的共享变量对所有线程总是可见的，也就是当一个线程修改了一个被volatile修饰共享变量的值，新值总是可以被其他线程立即得知。

如果线程2改变了stop的值，线程1一定会停止吗？不一定。当线程2更改了stop变量的值之后，但是还没来得及写入主存当中，线程2转去做其他事情了，那么线程1由于不知道线程2对stop变量的更改，因此还会一直循环下去。

2. 禁止指令重排序优化。

write方法里的1和2做了重排序，线程1先对flag赋值为true，随后执行到线程2，ret直接计算出结果，再到线程1，这时候a才赋值为2,很明显迟了一步。
但是用volatile修饰之后就变得不一样了

第一：使用volatile关键字会强制将修改的值立即写入主存；
第二：使用volatile关键字的话，当线程2进行修改时，会导致线程1的工作内存中缓存变量stop的缓存行无效（反映到硬件层的话，就是CPU的L1或者L2缓存中对应的缓存行无效）；
第三：由于线程1的工作内存中缓存变量stop的缓存行无效，所以线程1再次读取变量stop的值时会去主存读取。

inc++; 其实是两个步骤，先加加，然后再赋值。不是原子性操作，所以volatile不能保证线程安全。

为什么用线程池？解释下线程池参数？

1、 降低资源消耗；提高线程利用率，降低创建和销毁线程的消耗。
2、 提高响应速度；任务来了，直接有线程可用可执行，而不是先创建线程，再执行。
3、 提高线程的可管理性；线程是稀缺资源，使用线程池可以统一分配调优监控。
corePoolSize 代表核心线程数，也就是正常情况下创建工作的线程数，这些线程创建后并不会消除，而是一种常驻线程
maxinumPoolSize 代表的是 大线程数，它与核心线程数相对应，表示 大允许被创建的线程数，比如当前任务较多，将核心线程数都用完了，还无法满足需求时，此时就会创建新的线程，但是线程池内线程总数不会超过 大线程数
keepAliveTime、unit 表示超出核心线程数之外的线程的空闲存活时间，也就是核心线程不会
消除，但是超出核心线程数的部分线程如果空闲一定的时间则会被消除,我们可以通过
setKeepAliveTime 来设置空闲时间
workQueue 用来存放待执行的任务，假设我们现在核心线程都已被使用，还有任务进来则全部放入队列，直到整个队列被放满但任务还再持续进入则会开始创建新的线程
ThreadFactory 实际上是一个线程工厂，用来生产线程执行任务。我们可以选择使用默认的创建工厂，产生的线程都在同一个组内，拥有相同的优先级，且都不是守护线程。当然我们也可以选择自定义线程工厂，一般我们会根据业务来制定不同的线程工厂
Handler 任务拒绝策略，有两种情况，第一种是当我们调用shutdown 等方法关闭线程池后，这时候即使线程池内部还有没执行完的任务正在执行，但是由于线程池已经关闭，我们再继续想线程池提交任务就会遭到拒绝。另一种情况就是当达到 大线程数，线程池已经没有能力继续处理新提交的任务时，这是也就拒绝

简述线程池处理流程

线程池中阻塞队列的作用？为什么是先添加列队而不是先创建最大线程？

1、一般的队列只能保证作为一个有限长度的缓冲区，如果超出了缓冲长度，就无法保留当前的任务了，阻塞队列通过阻塞可以保留住当前想要继续入队的任务。
阻塞队列可以保证任务队列中没有任务时阻塞获取任务的线程，使得线程进入wait状态，释放cpu资源。
阻塞队列自带阻塞和唤醒的功能，不需要额外处理，无任务执行时,线程池利用阻塞队列的take方法挂起，从而维持核心线程的存活、不至于一直占用cpu资源 2、在创建新线程的时候，是要获取全局锁的，这个时候其它的就得阻塞，影响了整体效率。
就好比一个企业里面有10个（core）正式工的名额， 多招10个正式工，要是任务超过正式工人数
（task > core）的情况下，工厂领导（线程池）不是首先扩招工人，还是这10人，但是任务可以稍微积压一下，即先放到队列去（代价低）。10个正式工慢慢干，迟早会干完的，要是任务还在继续增加，超过正式工的加班忍耐极限了（队列满了），就的招外包帮忙了（注意是临时工）要是正式工加上外包还是不能完成任务，那新来的任务就会被领导拒绝了（线程池的拒绝策略）。

线程池中线程复用原理

线程池将线程和任务进行解耦，线程是线程，任务是任务，摆脱了之前通过 Thread 创建线程时的一个线程必须对应一个任务的限制。
在线程池中，同一个线程可以从阻塞队列中不断获取新任务来执行，其核心原理在于线程池对
Thread 进行了封装，并不是每次执行任务都会调用 Thread.start() 来创建新线程，而是让每个线程去执行一个“循环任务”，在这个“循环任务”中不停检查是否有任务需要被执行，如果有则直接执行，也就是调用任务中的 run 方法，将 run 方法当成一个普通的方法执行，通过这种方式只使用固定的线程就将所有任务的 run 方法串联起来。

Mysql

索引的基本原理

索引用来快速地寻找那些具有特定值的记录。如果没有索引，一般来说执行查询时遍历整张表。
索引的原理：就是把无序的数据变成有序的查询

1. 把创建了索引的列的内容进行排序
2. 对排序结果生成倒排表
3. 在倒排表内容上拼上数据地址链
4. 在查询的时候，先拿到倒排表内容，再取出数据地址链，从而拿到具体数据

mysql聚簇和非聚簇索引的区别

都是B+树的数据结构
聚簇索引：将数据存储与索引放到了一块、并且是按照一定的顺序组织的，找到索引也就找到了数据，数据的物理存放顺序与索引顺序是一致的，即：只要索引是相邻的，那么对应的数据一定也是相邻地存放在磁盘上的
非聚簇索引：叶子节点不存储数据、存储的是数据行地址，也就是说根据索引查找到数据行的位置再取磁盘查找数据，这个就有点类似一本树的目录，比如我们要找第三章第一节，那我们先在这个目录里面找，找到对应的页码后再去对应的页码看文章。
优势：
1、 查询通过聚簇索引可以直接获取数据，相比非聚簇索引需要第二次查询（非覆盖索引的情况下）效率要高
2、 聚簇索引对于范围查询的效率很高，因为其数据是按照大小排列的
3、 聚簇索引适合用在排序的场合，非聚簇索引不适合
劣势：
1、 维护索引很昂贵，特别是插入新行或者主键被更新导至要分页(page split)的时候。建议在大量插入新行后，选在负载较低的时间段，通过OPTIMIZE TABLE优化表，因为必须被移动的行数据可能造成碎片。使用独享表空间可以弱化碎片
2、 表因为使用UUId（随机ID）作为主键，使数据存储稀疏，这就会出现聚簇索引有可能有比全表扫面更慢，所以建议使用int的auto_increment作为主键
3、 如果主键比较大的话，那辅助索引将会变的更大，因为辅助索引的叶子存储的是主键值；过长的主键值，会导致非叶子节点占用占用更多的物理空间
InnoDB中一定有主键，主键一定是聚簇索引，不手动设置、则会使用unique索引，没有unique索引，则会使用数据库内部的一个行的隐藏id来当作主键索引。在聚簇索引之上创建的索引称之为辅助索引，辅助索引访问数据总是需要二次查找，非聚簇索引都是辅助索引，像复合索引、前缀索引、唯一索引，辅助索引叶子节点存储的不再是行的物理位置，而是主键值
MyISM使用的是非聚簇索引，没有聚簇索引，非聚簇索引的两棵B+树看上去没什么不同，节点的结构完全一致只是存储的内容不同而已，主键索引B+树的节点存储了主键，辅助键索引B+树存储了辅助键。表数据存储在独立的地方，这两颗B+树的叶子节点都使用一个地址指向真正的表数据，对于表数据来说，这两个键没有任何差别。由于索引树是独立的，通过辅助键检索无需访问主键的索引树。
如果涉及到大数据量的排序、全表扫描、count之类的操作的话，还是MyISAM占优势些，因为索引所占空间小，这些操作是需要在内存中完成的。

mysql索引的数据结构，各自优劣

索引的数据结构和具体存储引擎的实现有关，在MySQL中使用较多的索引有Hash索引，B+树索引等， InnoDB存储引擎的默认索引实现为：B+树索引。对于哈希索引来说，底层的数据结构就是哈希表，因此在绝大多数需求为单条记录查询的时候，可以选择哈希索引，查询性能 快；其余大部分场景，建议选择BTree索引。
B+树：
B+树是一个平衡的多叉树，从根节点到每个叶子节点的高度差值不超过1，而且同层级的节点间有指针相互链接。在B+树上的常规检索，从根节点到叶子节点的搜索效率基本相当，不会出现大幅波动，而且基于索引的顺序扫描时，也可以利用双向指针快速左右移动，效率非常高。因此，B+树索引被广泛应用于数据库、文件系统等场景。

哈希索引：
哈希索引就是采用一定的哈希算法，把键值换算成新的哈希值，检索时不需要类似B+树那样从根节点到叶子节点逐级查找，只需一次哈希算法即可立刻定位到相应的位置，速度非常快

如果是等值查询，那么哈希索引明显有绝对优势，因为只需要经过一次算法即可找到相应的键值；前提是键值都是唯一的。如果键值不是唯一的，就需要先找到该键所在位置，然后再根据链表往后扫描，直到找到相应的数据；
如果是范围查询检索，这时候哈希索引就毫无用武之地了，因为原先是有序的键值，经过哈希算法后，有可能变成不连续的了，就没办法再利用索引完成范围查询检索；
哈希索引也没办法利用索引完成排序，以及like ‘xxx%’ 这样的部分模糊查询（这种部分模糊查询，其实本质上也是范围查询）；
哈希索引也不支持多列联合索引的 左匹配规则；
B+树索引的关键字检索效率比较平均，不像B树那样波动幅度大，在有大量重复键值情况下，哈希索引的效率也是极低的，因为存在哈希碰撞问题。

索引设计的原则？

查询更快、占用空间更小

1. 适合索引的列是出现在where子句中的列，或者连接子句中指定的列
2. 基数较小的表，索引效果较差，没有必要在此列建立索引
3. 使用短索引，如果对长字符串列进行索引，应该指定一个前缀长度，这样能够节省大量索引空间，如果搜索词超过索引前缀长度，则使用索引排除不匹配的行，然后检查其余行是否可能匹配。
4. 不要过度索引。索引需要额外的磁盘空间，并降低写操作的性能。在修改表内容的时候，索引会进行更新甚至重构，索引列越多，这个时间就会越长。所以只保持需要的索引有利于查询即可。
5. 定义有外键的数据列一定要建立索引。
6. 更新频繁字段不适合创建索引
7. 若是不能有效区分数据的列不适合做索引列(如性别，男女未知， 多也就三种，区分度实在太低)
8. 尽量的扩展索引，不要新建索引。比如表中已经有a的索引，现在要加(a,b)的索引，那么只需要修改原来的索引即可。
9. 对于那些查询中很少涉及的列，重复值比较多的列不要建立索引。
10. 对于定义为text、image和bit的数据类型的列不要建立索引。

什么是最左前缀原则？什么是最左匹配原则

锁的类型有哪些

基于锁的属性分类：共享锁、排他锁。
基于锁的粒度分类：行级锁(INNODB)、表级锁(INNODB、MYISAM)、页级锁(BDB引擎 )、记录锁、间隙锁、临键锁。

如果当事务A加锁成功之后就设置一个状态告诉后面的人，已经有人对表里的行加了一个排他锁了，你们不能对整个表加共享锁或排它锁了，那么后面需要对整个表加锁的人只需要获取这个状态就知道自己是不是可以对表加锁，避免了对整个索引树的每个节点扫描是否加锁，而这个状态就是意向锁。

InnoDB存储引擎的锁的算法

相关知识点：

1. innodb对于行的查询使用next-key lock
2. Next-locking keying为了解决Phantom Problem幻读问题
3. 当查询的索引含有唯一属性时，将next-key lock降级为record key
4. Gap锁设计的目的是为了阻止多个事务将记录插入到同一范围内，而这会导致幻读问题的产生
5. 有两种方式显式关闭gap锁：（除了外键约束和唯一性检查外，其余情况仅使用record lock） A.
   将事务隔离级别设置为RC B. 将参数innodb_locks_unsafe_for_binlog设置为1

关心过业务系统里面的sql耗时吗？统计过慢查询吗？对慢查询都怎么优化过？

在业务系统中，除了使用主键进行的查询，其他的都会在测试库上测试其耗时，慢查询的统计主要由运维在做，会定期将业务中的慢查询反馈给我们。
慢查询的优化首先要搞明白慢的原因是什么？是查询条件没有命中索引？是load了不需要的数据列？还是数据量太大？
所以优化也是针对这三个方向来的，
首先分析语句，看看是否load了额外的数据，可能是查询了多余的行并且抛弃掉了，可能是加载了许多结果中并不需要的列，对语句进行分析以及重写。
分析语句的执行计划，然后获得其使用索引的情况，之后修改语句或者修改索引，使得语句可以尽可能的命中索引。
如果对语句的优化已经无法进行，可以考虑表中的数据量是否太大，如果是的话可以进行横向或者纵向的分表。

事务的基本特性和隔离级别

事务基本特性ACID分别是：
原子性指的是一个事务中的操作要么全部成功，要么全部失败。
一致性指的是数据库总是从一个一致性的状态转换到另外一个一致性的状态。比如A转账给B100块钱，假设A只有90块，支付之前我们数据库里的数据都是符合约束的,但是如果事务执行成功了,我们的数据库数据就破坏约束了,因此事务不能成功,这里我们说事务提供了一致性的保证隔离性指的是一个事务的修改在 终提交前，对其他事务是不可见的。
持久性指的是一旦事务提交，所做的修改就会永久保存到数据库中。

隔离性有4个隔离级别，分别是：
read uncommit 读未提交，可能会读到其他事务未提交的数据，也叫做脏读。
用户本来应该读取到id=1的用户age应该是10，结果读取到了其他事务还没有提交的事务，结果读取结果age=20，这就是脏读。
read commit 读已提交，两次读取结果不一致，叫做不可重复读。
不可重复读解决了脏读的问题，他只会读取已经提交的事务。
用户开启事务读取id=1用户，查询到age=10，再次读取发现结果=20，在同一个事务里同一个查询读取到不同的结果叫做不可重复读。
repeatable read 可重复复读，这是mysql的默认级别，就是每次读取结果都一样，但是有可能产生幻读。
serializable 串行，一般是不会使用的，他会给每一行读取的数据加锁，会导致大量超时和锁竞争的问题。

脏读(Drity Read)：某个事务已更新一份数据，另一个事务在此时读取了同一份数据，由于某些原因，前一个RollBack了操作，则后一个事务所读取的数据就会是不正确的。
不可重复读(Non-repeatable read):在一个事务的两次查询之中数据不一致，这可能是两次查询过程中间插入了一个事务更新的原有的数据。
幻读(Phantom Read):在一个事务的两次查询中数据笔数不一致，例如有一个事务查询了几列(Row)数据，而另一个事务却在此时插入了新的几列数据，先前的事务在接下来的查询中，就会发现有几列数据是它先前所没有的。

ACID靠什么保证的？

A原子性由undo log日志保证，它记录了需要回滚的日志信息，事务回滚时撤销已经执行成功的sql
C一致性由其他三大特性保证、程序代码要保证业务上的一致性
I隔离性由MVCC来保证
D持久性由内存+redo log来保证，mysql修改数据同时在内存和redo log记录这次操作，宕机的时候可以从redo log恢复
InnoDB redo log 写盘，InnoDB 事务进入 prepare 状态。
如果前面 prepare 成功，binlog 写盘，再继续将事务日志持久化到 binlog，如果持久化成功，那么
InnoDB 事务则进入 commit 状态(在 redo log 里面写一个 commit 记录)
redolog的刷盘会在系统空闲时进行

什么是MVCC

多版本并发控制：读取数据时通过一种类似快照的方式将数据保存下来，这样读锁就和写锁不冲突了，不同的事务session会看到自己特定版本的数据，版本链
MVCC只在 READ COMMITTED 和 REPEATABLE READ 两个隔离级别下工作。其他两个隔离级别够和
MVCC不兼容, 因为 READ UNCOMMITTED 总是读取 新的数据行, 而不是符合当前事务版本的数据行。而 SERIALIZABLE 则会对所有读取的行都加锁。

聚簇索引记录中有两个必要的隐藏列： trx_id：用来存储每次对某条聚簇索引记录进行修改的时候的事务id。
roll_pointer：每次对哪条聚簇索引记录有修改的时候，都会把老版本写入undo日志中。这个 roll_pointer就是存了一个指针，它指向这条聚簇索引记录的上一个版本的位置，通过它来获得上一个版本的记录信息。(注意插入操作的undo日志没有这个属性，因为它没有老版本) 已提交读和可重复读的区别就在于它们生成ReadView的策略不同。

开始事务时创建readview，readView维护当前活动的事务id，即未提交的事务id，排序生成一个数组访问数据，获取数据中的事务id（获取的是事务id大的记录），对比readview：如果在readview的左边（比readview都小），可以访问（在左边意味着该事务已经提交）
如果在readview的右边（比readview都大）或者就在readview中，不可以访问，获取roll_pointer，取上一版本重新对比（在右边意味着，该事务在readview生成之后出现，在readview中意味着该事务还未提交）

已提交读隔离级别下的事务在每次查询的开始都会生成一个独立的ReadView,而可重复读隔离级别则在第一次读的时候生成一个ReadView，之后的读都复用之前的ReadView。
这就是Mysql的MVCC,通过版本链，实现多版本，可并发读-写，写-读。通过ReadView生成策略的不同实现不同的隔离级别。

分表后非sharding_key的查询怎么处理，分表后的排序？

1. 可以做一个mapping表，比如这时候商家要查询订单列表怎么办呢？不带user_id查询的话你总不能扫全表吧？所以我们可以做一个映射关系表，保存商家和用户的关系，查询的时候先通过商家查询到用户列表，再通过user_id去查询。
2. 宽表，对数据实时性要求不是很高的场景，比如查询订单列表，可以把订单表同步到离线（实时）数仓，再基于数仓去做成一张宽表，再基于其他如es提供查询服务。
3. 数据量不是很大的话，比如后台的一些查询之类的，也可以通过多线程扫表，然后再聚合结果的方式来做。或者异步的形式也是可以的。

union
排序字段是唯一索引：
首先第一页的查询：将各表的结果集进行合并，然后再次排序第二页及以后的查询，需要传入上一页排序字段的 后一个值，及排序方式。
根据排序方式，及这个值进行查询。如排序字段date，上一页 后值为3，排序方式降序。查询的时候sql为select … from table where date < 3 order by date desc limit 0,10。这样再将几个表的结果合并排序即可。

mysql主从同步原理

mysql主从同步的过程：
Mysql的主从复制中主要有三个线程：master（binlog dump thread）、slave（I/O thread 、SQL thread），Master一条线程和Slave中的两条线程。
主节点 binlog，主从复制的基础是主库记录数据库的所有变更记录到 binlog。binlog 是数据库服务器启动的那一刻起，保存所有修改数据库结构或内容的一个文件。
主节点 log dump 线程，当 binlog 有变动时，log dump 线程读取其内容并发送给从节点。
从节点 I/O线程接收 binlog 内容，并将其写入到 relay log 文件中。
从节点的SQL 线程读取 relay log 文件内容对数据更新进行重放， 终保证主从数据库的一致性。
注：主从节点使用 binglog 文件 + position 偏移量来定位主从同步的位置，从节点会保存其已接收到的偏移量，如果从节点发生宕机重启，则会自动从 position 的位置发起同步。

由于mysql默认的复制方式是异步的，主库把日志发送给从库后不关心从库是否已经处理，这样会产生一个问题就是假设主库挂了，从库处理失败了，这时候从库升为主库后，日志就丢失了。由此产生两个概念。
全同步复制
主库写入binlog后强制同步日志到从库，所有的从库都执行完成后才返回给客户端，但是很显然这个方式的话性能会受到严重影响。
半同步复制
和全同步不同的是，半同步复制的逻辑是这样，从库写入日志成功后返回ACK确认给主库，主库收到至少一个从库的确认就认为写操作完成。

简述MyISAM和InnoDB的区别

MyISAM：
不支持事务，但是每次查询都是原子的；支持表级锁，即每次操作是对整个表加锁；存储表的总行数；一个MYISAM表有三个文件：索引文件、表结构文件、数据文件；
采用非聚集索引，索引文件的数据域存储指向数据文件的指针。辅索引与主索引基本一致，但是辅索引不用保证唯一性。
InnoDb：
支持ACID的事务，支持事务的四种隔离级别；支持行级锁及外键约束：因此可以支持写并发；不存储总行数；一个InnoDb引擎存储在一个文件空间（共享表空间，表大小不受操作系统控制，一个表可能分布在多个文件里），也有可能为多个（设置为独立表空，表大小受操作系统文件大小限制，一般为2G），受操作系统文件大小的限制；
主键索引采用聚集索引（索引的数据域存储数据文件本身），辅索引的数据域存储主键的值；因此从辅索引查找数据，需要先通过辅索引找到主键值，再访问辅索引； 好使用自增主键，防止插入数据时，为维持B+树结构，文件的大调整。

简述mysql中索引类型及对数据库的性能的影响

普通索引：允许被索引的数据列包含重复的值。
唯一索引：可以保证数据记录的唯一性。
主键：是一种特殊的唯一索引，在一张表中只能定义一个主键索引，主键用于唯一标识一条记录，使用关键字 PRIMARY KEY 来创建。
联合索引：索引可以覆盖多个数据列，如像INDEX(columnA, columnB)索引。
全文索引：通过建立倒排索引 ,可以极大的提升检索效率,解决判断字段是否包含的问题，是目前搜索引擎使用的一种关键技术。可以通过ALTER TABLE table_name ADD FULLTEXT (column);创建全文索引

索引可以极大的提高数据的查询速度。
通过使用索引，可以在查询的过程中，使用优化隐藏器，提高系统的性能。
但是会降低插入、删除、更新表的速度，因为在执行这些写操作时，还要操作索引文件
索引需要占物理空间，除了数据表占数据空间之外，每一个索引还要占一定的物理空间，如果要建立聚簇索引，那么需要的空间就会更大，如果非聚集索引很多，一旦聚集索引改变，那么所有非聚集索引都会跟着变。

mysql执行计划怎么看

执行计划就是sql的执行查询的顺序，以及如何使用索引查询，返回的结果集的行数
EXPLAIN SELECT * from A where X=? and Y=?

1。id ：是一个有顺序的编号，是查询的顺序号，有几个 select 就显示几行。id的顺序是按 select 出现的顺序增长的。id列的值越大执行优先级越高越先执行，id列的值相同则从上往下执行，id列的值为
NULL后执行。
2。selectType 表示查询中每个select子句的类型
SIMPLE： 表示此查询不包含 UNION 查询或子查询
PRIMARY： 表示此查询是 外层的查询（包含子查询）
SUBQUERY： 子查询中的第一个 SELECT
UNION： 表示此查询是 UNION 的第二或随后的查询
DEPENDENT UNION： UNION 中的第二个或后面的查询语句, 取决于外面的查询
UNION RESULT, UNION 的结果
DEPENDENT SUBQUERY: 子查询中的第一个 SELECT, 取决于外面的查询. 即子查询依赖于外层查询的结果.
DERIVED：衍生，表示导出表的SELECT（FROM子句的子查询）
3.table：表示该语句查询的表
4.type：优化sql的重要字段，也是我们判断sql性能和优化程度重要指标。他的取值类型范围：
const：通过索引一次命中，匹配一行数据 system: 表中只有一行记录，相当于系统表； eq_ref：唯一性索引扫描，对于每个索引键，表中只有一条记录与之匹配 ref: 非唯一性索引扫描,返回匹配某个值的所有
range: 只检索给定范围的行，使用一个索引来选择行，一般用于between、<、>； index: 只遍历索引树；
ALL: 表示全表扫描，这个类型的查询是性能 差的查询之一。 那么基本就是随着表的数量增多，执行效率越慢。
执行效率：
ALL < index < range< ref < eq_ref < const < system。最好是避免ALL和index

5.possible_keys：它表示Mysql在执行该sql语句的时候，可能用到的索引信息，仅仅是可能，实际不一定会用到。
6.key：此字段是 mysql 在当前查询时所真正使用到的索引。 他是possible_keys的子集
7.key_len：表示查询优化器使用了索引的字节数，这个字段可以评估组合索引是否完全被使用，这也是我们优化sql时，评估索引的重要指标
9.rows：mysql 查询优化器根据统计信息，估算该sql返回结果集需要扫描读取的行数，这个值相关重要，索引优化之后，扫描读取的行数越多，说明索引设置不对，或者字段传入的类型之类的问题，说明要优化空间越大
10.filtered：返回结果的行占需要读到的行(rows列的值)的百分比，就是百分比越高，说明需要查询到数据越准确， 百分比越小，说明查询到的数据量大，而结果集很少
11.extra
using filesort ：表示 mysql 对结果集进行外部排序，不能通过索引顺序达到排序效果。一般有 using filesort都建议优化去掉，因为这样的查询 cpu 资源消耗大，延时大。
using index：覆盖索引扫描，表示查询在索引树中就可查找所需数据，不用扫描表数据文件，往往说明性能不错。
using temporary：查询有使用临时表, 一般出现于排序， 分组和多表 join 的情况， 查询效率不高，建议优化。
using where ：sql使用了where过滤,效率较高。