java面试

面向对象

什么是面向对象？

对比面向过程，是两种不同的处理问题的角度

面向过程更注重事情的每一个步骤及顺序，面向对象更注重事情有哪些参与者（对象）、及各自需要做什么

比如：洗衣机洗衣服

面向过程会将任务拆解成一系列的步骤（函数），1、打开洗衣机----->2、放衣服----->3、放洗衣粉----->4、清洗----->5、烘干

面向对象会拆出人和洗衣机两个对象：

人：打开洗衣机 放衣服 放洗衣粉

洗衣机：清洗 烘干

从以上例子能看出，面向过程比较直接高效，而面向对象更易于复用、扩展和维护

面向对象

封装： 封装的意义，在于明确标识出允许外部使用的所有成员函数和数据项

内部细节对外部调用透明，外部调用无需修改或者关心内部实现

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

private String name;
public void setName(String name){
    this.name = "tuling_"+name;
}
该name有自己的命名规则，明显不能由外部直接赋值

什么是JavaBean:

JavaBean是一个遵循特定写法的Java类，它通常具有如下特点：

• 这个Java类必须具有一个无参的构造函数
• 属性必须私有化。
• 私有化的属性必须通过public类型的方法暴露给其它程序，并且方法的命名也必须遵守一定的命名规范。

2.orm框架

操作数据库，我们不需要关心链接是如何建立的、sql是如何执行的，只需要引入mybatis，调方法即可。

orm:对象关系映射（Object Relational Mapping，简称ORM）是通过使用描述对象和数据库之间映射的元数据，将面向对象语言程序中的对象自动持久化到关系数据库中。本质上就是将数据从一种形式转换到另外一种形式。

继承：继承父类的方法，并做出自己的改变或扩展

子类共性的方法或者属性直接使用父类的，而不需要自己再定义，只需要扩展自己个性的。

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

继承，方法重写，父类引用指向子类对象(多态的三个条件)。

父类类型  变量名  =  new  子类对象 ;
变量名.方法名();

JDK、JRE、JVM、区别与联系

• JDK:
  Java Develpment Kit -java开发工具
  java开发工具是提供给开发人员用的。

• JRE:
  java Runtime Environment -java运行时环境
  java运行时环境，谁需要运行java程序，谁就可以可以安装，运行JRE的不一定是开发人员。

• JVM:
  java Virtual Machine -java虚拟机
  解释class文件，让操作系统可以执行。

三者关系：

JRE下的lib只是运行java程序的jar包，是为JVM运行时候用的。包括所有的标准类库，和扩展类。
JRE下的bin放的对应系统的虚拟机

==和equals

对于基本类型和引用类型 == 的作用效果是不同的，如下所示：

• 基本类型：比较的是值是否相同；
• 引用类型：比较的是引用是否相同；

String x = "string";
String y = "string";
String z = new String("string");
System.out.println(x==y); // true
System.out.println(x==z); // false
System.out.println(x.equals(y)); // true
System.out.println(x.equals(z)); // true

final

1.简述final作用

• 修饰类：表示类不可被继承
• 修饰方法： 表示方法不可被子类覆盖，但是可以重载
• 修饰变量： 表示变量一旦被赋值就不可以更改它的值。

（1） 修饰成员变量

• 如果final修饰的是类变量，只能在静态初始化块中指定初始值或者声明该类变量时指定初始值。
• 如果final修饰的是成员变量，可以在非静态初始化块、声明该变量或者构造器中执行初始值。

（2） 修饰局部变量
系统不会为局部变量进行初始化，局部变量必须由程序员显示初始化。因此使用final修饰局部变量时，即可以在定义时指定默认值（后面的代码不能对变量再赋值），也可以不指定默认值，而在后面的代码中对final变量赋初值（仅一次）

public class FinalVar {
    final static int a = 0;//在声明的时候就需要赋值，或者在静态代码块中赋值
    /**
    static{
    	a = 0;
    }
    */
    final int b = 0;//再声明的时候就需要赋值 或者代码块中赋值 或者构造器赋值
    /*{
        b = 0;
    }*/
    public static void main(String[] args) {
        final int localA;   //局部变量只声明没有初始化，不会报错,与final无关。
        localA = 0;//在使用之前一定要赋值
        //localA = 1;  但是不允许第二次赋值
    }
}

（3）修饰基本类型数据和引用数据类型数据

• 如果是基本数据类型的变量，则其数值一旦在初始化之后便不能更改；
• 如果是引用类型的变量，则在对其初始化之后便不能再让其指向另一个对象。但是引用的值是可变的。

public class FinalReferenceTest{
    public static void main(){
        final int[] iArr={1,2,3,4};
        iArr[2]=-3;//合法 
        iArr=null;//非法，对iArr不能重新赋值
        
        final Person p = new Person(25);
        p.setAge(24);//合法
        p=null;//非法 
    }   
}

2. 为什么局部内部类和匿名内部类只能访问局部final变量？

编译之后会生成两个class文件，Test.class Test1.class

public class Test {
    public static void main(String[] args)  {     
    }   
    //局部final变量a,b
    public void test(final int b) {//jdk8在这里做了优化, 不用写,语法糖，但实际上也是有的，也不能修改
        final int a = 10;
        //匿名内部类
        new Thread(){
            public void run() {
                System.out.println(a);
                System.out.println(b);
            };
        }.start();
    }
}

class OutClass {
        private int age = 12;
 
        public void outPrint(final int x) {
                class InClass {
                        public void InPrint() {
                                System.out.println(x);
                                System.out.println(age);
                        }
                }
                new InClass().InPrint();
        }
}

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

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

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

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

String、StringBuffer、StringBuilder区别及使用场景

• String是final修饰的，不可变，每次操作都会产生新的String对象

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

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

• StringBuffer每个方法都是synchronized修饰的

性能：StringBuilder > StringBuffer > String

场景：经常需要改变字符串内容时使用后面两个

优先使用StringBuilder，多线程使用共享变量时使用StringBuffer

重载和重写的区别

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

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

接口和抽象类的区别

• 抽象类可以存在普通成员函数，而接口中只能存在public abstract 方法。
• 抽象类可以存在普通成员函数，而接口中只能存在public abstract 方法。
• 抽象类只能继承一个，接口可以实现多个。

中高级程序员：回到下面：
接口的设计目的，是对类的行为进行约束（更准确的说是一种“有”约束，因为接口不能规定类不可以有什么行为），也就是提供一种机制，可以强制要求不同的类具有相同的行为。它只约束了行为的有无，但不对如何实现行为进行限制。

而抽象类的设计目的，是代码复用。当不同的类具有某些相同的行为(记为行为集合A)，且其中一部分行为的实现方式一致时（A的非真子集，记为B），可以让这些类都派生于一个抽象类（抽象类中一定是先有子类再有父类，将子类的共性抽取成一个父类）。在这个抽象类中实现了B，避免让所有的子类来实现B，这就达到了代码复用的目的。而A减B的部分，留给各个子类自己实现。正是因为A-B在这里没有实现，所以抽象类不允许实例化出来（否则当调用到A-B时，无法执行）。

抽象类是对类本质的抽象，表达的是 is a 的关系，比如：BMW is a Car。抽象类包含并实现子类的通用特性，将子类存在差异化的特性进行抽象，交由子类去实现。

而接口是对行为的抽象，表达的是 like a 的关系。比如：Bird like a Aircraft（像飞行器一样可以飞），但其本质上 is a Bird。接口的核心是定义行为，即实现类可以做什么，至于实现类主体是谁、是如何实现的，接口并不关心。

使用场景：当你关注一个事物的本质的时候，用抽象类；当你关注一个操作的时候，用接口。

抽象类的功能要远超过接口，但是，定义抽象类的代价高。因为高级语言来说（从实际设计上来说也是）每个类只能继承一个类。在这个类中，你必须继承或编写出其所有子类的所有共性。虽然接口在功能上会弱化许多，但是它只是针对一个动作的描述。而且你可以在一个类中同时实现多个接口。在设计阶段会降低难度。

List和Set的区别

• 有序，按对象进入的顺序保存对象，可重复，允许多个Null元素对象，可以使用Iterator取出所有元素，在逐一遍历，还可以使用get(int index)获取指定下标的元素
• Set：无序，不可重复，最多允许有一个Null元素对象，取元素时只能用Iterator接口取得所有元素，在逐一遍历各个元素

hashCode与equals

hashCode介绍：

hashCode() 的作用是获取哈希码，也称为散列码；它实际上是返回一个int整数。这个哈希码的作用是确定该对象在哈希表中的索引位置(在java中对象存在于堆中，对象在那个位置呢，实际上java中维护一张hash表，hash表的索引就是我们这里的hashcode，通过索引很快在hash表找到对象所在的位置)。hashCode() 定义在JDK的Object.java中，Java中的任何类都包含有hashCode() 函数。
散列表存储的是键值对(key-value)，它的特点是：能根据“键”快速的检索出对应的“值”。这其中就利用到了散列码！（可以快速找到所需要的对象）

为什么要有hashCode

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

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

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

ArrayList和LinkedList区别

ArrayList：基于动态数组，连续内存存储，适合下标访问（随机访问），扩容机制：因为数组长度固定，超出长度存数据时需要新建数组，然后将老数组的数据拷贝到新数组，如果不是尾部插入数据还会涉及到元素的移动（往后复制一份，插入新元素），使用尾插法并指定初始容量可以极大提升性能、甚至超过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不允许；

底层实现：数组+链表

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

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

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

参考
jdk7:
数据结构：ReentrantLock+Segment+HashEntry，一个Segment中包含一个HashEntry数组，每个HashEntry又是一个链表结构元素查询：二次hash，第一次Hash定位到Segment，第二次Hash定位到元素所在的链表的头部

ConcurrentHashMap 类中包含两个静态内部类 HashEntry 和 Segment。HashEntry 用来封装映射表的键 / 值对；Segment 用来充当锁的角色，每个 Segment 对象守护整个散列映射表的若干个桶。每个桶是由若干个 HashEntry对象链接起来的链表。一个 ConcurrentHashMap 实例中包含由若干个 Segment 对象组成的数组。

锁：Segment分段锁 Segment继承了ReentrantLock，锁定操作的Segment，其他的Segment不受影响，并发度为segment个数，可以通过构造函数指定，数组扩容不会影响其他的segment

get方法无需加锁，volatile保证了数据的安全性。

ReentrantLock基础知识

jdk8:

数据结构：synchronized+CAS+Node+红黑树，Node的val和next都用volatile修饰，保证可见性

查找，替换，赋值操作都是使用CAS

锁：锁链表的head节点，不影响其他元素的读写，锁粒度更细，效率更高，扩容时，阻塞所有的读写操作、并发扩容读操作无锁：

Node的val和next使用volatile修饰，读写线程对该变量互相可见。

数组用volatile修饰，保证扩容时被读线程感知。

volatile关键字

1.可见性：java提供了volatile关键字来保证可见性。
所谓可见性，当一个共享变量被volatile修饰时，它会保证修饰的值立即被更新到主存中，当有其他线程需要读取时，他会去内存中读取新值。（多个线程操作共享变量时候，当有一个线程改变了共享变量值时候，其他变量能立即知道）
2.防止指令重排序

CAS

• CAS是英文单词CompareAndSwap的缩写，中文意思是：比较并替换。CAS需要有3个操作数：内存地址V，旧的预期值A，即将要更新的目标值B。
• CAS指令执行时，当且仅当内存地址V的值与预期值A相等时，将内存地址V的值修改为B，否则就什么都不做。整个比较并替换的操作是一个原子操作。

CAS的缺点:
CAS虽然很高效的解决了原子操作问题，但是CAS仍然存在三大问题。

• 循环时间长开销大
• 只能保证一个变量的原子操作
• ABA问题

循环时间长开销很大：CAS 通常是配合无限循环一起使用的，我们可以看到 getAndAddInt 方法执行时，如果 CAS 失败，会一直进行尝试。如果 CAS 长时间一直不成功，可能会给 CPU 带来很大的开销。

只能保证一个变量的原子操作：
当对一个变量执行操作时，我们可以使用循环 CAS 的方式来保证原子操作，但是对多个变量操作时，CAS 目前无法直接保证操作的原子性。但是我们可以通过以下两种办法来解决：1）使用互斥锁来保证原子性；2）将多个变量封装成对象，通过 AtomicReference 来保证原子性。

什么是ABA问题？ABA问题怎么解决？

CAS 的使用流程通常如下：1）首先从地址 V 读取值 A；2）根据 A 计算目标值 B；3）通过 CAS 以原子的方式将地址 V 中的值从 A 修改为 B。

但是在第1步中读取的值是A，并且在第3步修改成功了，我们就能说它的值在第1步和第3步之间没有被其他线程改变过了吗？

如果在这段期间它的值曾经被改成了B，后来又被改回为A，那CAS操作就会误认为它从来没有被改变过。这个漏洞称为CAS操作的“ABA”问题。Java并发包为了解决这个问题，提供了一个带有标记的原子引用类“AtomicStampedReference”，它可以通过控制变量值的版本来保证CAS的正确性。因此，在使用CAS前要考虑清楚“ABA”问题是否会影响程序并发的正确性，如果需要解决ABA问题，改用传统的互斥同步可能会比原子类更高效。

红黑树

红黑树是一种近似平衡的二叉查找树，它能够确保任何一个节点的左右子树的高度不会超过二者中较低哪一个的一倍，具体来说，红黑树是满足如下条件的二叉查找树：

• 每个节点要么是红色，要么是黑色。
• 根节点必须是黑色。
• 红色节点不能连续（也即是，红色节点的孩子和父亲都不能是红色）。
• 对于每个节点，从该节点至nulll(树尾端)的任何路径，都会有相同个数的黑色节点。

Spring

Spring是什么？

Spring框架是一个开放源代码的J2EE(企业级分布式应用程序开发规范)应用程序框架,它是一个容器框架，用来装javabean（java对象），中间层框架（万能胶）可以起一个连接作用， Spring解决了开发者在J2EE开发中遇到的许多常见的问题，提供了功能强大IOC、AOP及Web MVC等功能。

Spring是一个轻量级的控制反转（IoC)和面向切面（AOP）的容器框架

• 从大小与开销两方面而言Spring都是轻量级的。
• 通过控制反转(IoC)的技术达到松耦合的目的
• 供了面向切面编程的丰富支持，允许通过分离应用的业务逻辑与系统级服务进行内聚性的开发
• 包含并管理应用对象(Bean)的配置和生命周期，这个意义上是一个容器。
• 将简单的组件配置、组合成为复杂的应用，这个意义上是一个框架。

谈谈你对AOP（面向切面编程）的理解

系统是由许多不同的组件所组成的，每一个组件各负责一块特定功能。除了实现自身核心功能之外，这些组件还经常承担着额外的职责。例如日志、事务管理和安全这样的核心服务经常融入到自身具有核心业务逻辑的组件中去。这些系统服务经常被称为横切关注点，因为它们会跨越系统的多个组件。

当我们需要为分散的对象引入公共行为的时候，OOP则显得无能为力。也就是说，OOP允许你定义从上到下的关系，但并不适合定义从左到右的关系。例如日志功能。

日志代码往往水平地散布在所有对象层次中，而与它所散布到的对象的核心功能毫无关系。

在OOP设计中，它导致了大量代码的重复，而不利于各个模块的重用。

AOP：将程序中的交叉业务逻辑（比如安全，日志，事务等），封装成一个切面，然后注入到目标对象（具体业务逻辑）中去。AOP可以对某个对象或某些对象的功能进行增强，比如对象中的方法进行增强，可以在执行某个方法之前额外的做一些事情，在某个方法执行之后额外的做一些事情。

谈谈你对IOC的理解l

容器概念（spring容器指的就是IOC容器）、控制反转、依赖注入

容器概念：

ioc容器：实际上就是个map(key,value),里面存的是各种对象（在xml里配置的bean节点、@repository、@service、@controller、@component），在项目启动的时候会读取配置文件里面的bean节点，根据全限定类名使用反射创建对象放到map里、扫描到打上上述注解的类还是通过反射创建对象放到map里。

这个时候map里就有各种对象了，接下来我们在代码里需要用到里面的对象时，再通过DI注入（autowired、resource等注解，xml里bean节点内的ref属性，项目启动的时候会读取xml节点ref属性根据id注入，也会扫描这些注解，根据类型或id注入；id就是对象名）。
举例：
本来A是依赖B的，现在有了IOC，我们把A,和B都注入到IOC容器中，当A需要用到B的时候，由IOC主动注入

控制反转：

没有引入IOC容器之前，对象A依赖于对象B，那么对象A在初始化或者运行到某一点的时候，自己必须主动去创建对象B或者使用已经创建的对象B。无论是创建还是使用对象B，控制权都在自己手上。

引入IOC容器之后，对象A与对象B之间失去了直接联系，当对象A运行到需要对象B的时候，IOC容器会主动创建一个对象B注入到对象A需要的地方。

通过前后的对比，不难看出来：对象A获得依赖对象B的过程,由主动行为变为了被动行为，控制权颠倒过来了，这就是“控制反转”这个名称的由来。

全部对象的控制权全部上缴给“第三方”IOC容器，所以，IOC容器成了整个系统的关键核心，它起到了一种类似“粘合剂”的作用，把系统中的所有对象粘合在一起发挥作用，如果没有这个“粘合剂”，对象与对象之间会彼此失去联系，这就是有人把IOC容器比喻成“粘合剂”的由来。

依赖注入（可以说为控制反转的实现）：
“获得依赖对象的过程被反转了”。控制被反转之后，获得依赖对象的过程由自身管理变为了由IOC容器主动注入。依赖注入是实现IOC的方法，就是由IOC容器在运行期间，动态地将某种依赖关系注入到对象之中。

如何实现IOC容器

1.配置文件配置包扫描路径

2.递归包扫描获取.class文件

3.反射、确定需要交给IOC管理类

4.对需要注入的类进行依赖注入

详细讲解以上四步：

• 配置文件中指定需要扫描的包路径
• 定义一些注解，分别表示访问控制层、业务服务层、数据持久层、依赖注入注解、获取配置文件注解
• 从配置文件中获取需要扫描的包路径，获取到当前路径下的文件信息及文件夹信息，我们将当前路径下所有以.class结尾的文件添加到一个Set集合中进行存储
• 遍历这个set集合，获取在类上有指定注解的类，并将其交给IOC容器，定义一个安全的Map用来存储这些对象
• 遍历这个IOC容器，获取到每一个类的实例，判断里面是有有依赖其他的类的实例，然后进行递归注入

BeanFactory和ApplicationContext有什么区别？

ApplicationContext是BeanFactory的子接口

ApplicationContext提供了更完整的功能：

①继承MessageSource,因此支持国际化

②统一的资源文件访问方式

③提供在监听器中注册bean的事件。

④同时加载多个配置文件

⑤载入多个（有继承关系）上下文，使得每一个上下文都专注于一个特定的层次，比如应用的web层。

• BeanFactroy采用的是延迟加载形式来注入Bean的，即只有在使用到某个Bean时(调用getBean())，才对该Bean进行加载实例化。这样，我们就不能发现一些存在的Spring的配置问题。如果Bean的某一个属性没有注入，BeanFacotry加载后，直至第一次使用调用getBean方法才会抛出异常。
• ApplicationContext，它是在容器启动时，一次性创建了所有的Bean。这样，在容器启动时，我们就可以发现Spring中存在的配置错误，这样有利于检查所依赖属性是否注入。 ApplicationContext启动后预载入所有的单实例Bean，通过预载入单实例bean ,确保当你需要的时候，你就不用等待，因为它们已经创建好了。
• 相对于基本的BeanFactory，ApplicationContext 唯一的不足是占用内存空间。当应用程序配置Bean较多时，程序启动较慢。
• BeanFactory通常以编程的方式被创建，ApplicationContext还能以声明的方式创建，如使用ContextLoader。
• BeanFactory和ApplicationContext都支持BeanPostProcessor、BeanFactoryPostProcessor的使用，但两者之间的区别是：BeanFactory需要手动注册，而ApplicationContext则是自动注册。

描述一下Spring Bean

1. 解析类得到BeanDefinition
2. 如果有多个构造方法，则要推断构造方法
3. 确定好构造方法后，进行实例化得到一个对象（到这一步，得到了bean对象）
4. 对对象中的加了@Autowired注解的属性进行属性填充
5. 回调Aware方法，比如BeanNameAware，BeanFactoryAware
6. 调用BeanPostProcessor的初始化前的方法
7. 调用初始化方法
8. 调用BeanPostProcessor的初始化后的方法，在这里会进行AOP
9. 如果当前创建的bean是单例的则会把bean放入单例池
10. 使用bean
11. Spring容器关闭时调用DisposableBean中destory()方法

解释下Spring支持的几种bean的作用域

• singleton:默认，每个容器中只有一个bean的实例，单例模式由BeanFactory自身来维护。该对象的生命周期是与Spring IOC容器一致的（但在第一次被注入时才会创建）。
• prototype: 为每一个bean请求提供一个实例，在每次注入时都会创建一个新的对象。
• request: bean被定义为每个HTTP请求中创建一个单例对象，也就是说在单个请求中都会复用这一个单例对象。
• session：与request范围类似，确保每个session中有一个bean的实例，在session过期后，bean会随之失效。
• application：bean被定义为在ServletContext的生命周期中复用一个单例对象。
• websocket：bean被定义为在websocket的生命周期中复用一个单例对象。
• global-session：全局作用域，global-session和Portlet应用相关。当你的应用部署在Portlet容器中工作时，它包含很多portlet。如果你想要声明让所有的portlet共用全局的存储变量的话，那么这全局变量需要存储在global-session中。全局作用域与Servlet中的session作用域效果相同。

Spring框架中的单例Bean是线程安全的么？

不是线程安全的。

Spring中的Bean默认是单例模式的，框架并没有对bean进行多线程的封装处理。（单例即为共享的）

如果Bean是有状态的 那就需要开发人员自己来进行线程安全的保证，最简单的办法就是改变bean的作用域 把 "singleton"改为’‘protopyte’ 这样每次请求Bean就相当于是 new Bean() 这样就可以保证线程的安全了。

• 有状态就是有数据存储功能
• 无状态就是不会保存数据 　　 controller、service和dao层本身并不是线程安全的，只是如果只是调用里面的方法，而且多线程调用一个实例的方法，会在内存中复制变量，这是自己的线程的工作内存，是安全的。

Dao会操作数据库Connection，Connection是带有状态的，比如说数据库事务，Spring的事务管理器使用Threadlocal为不同线程维护了一套独立的connection副本，保证线程之间不会互相影响（Spring 是如何保证事务获取同一个Connection的）

不要在bean中声明任何有状态的实例变量或类变量，如果必须如此，那么就使用ThreadLocal把变量变为线程私有的，如果bean的实例变量或类变量需要在多个线程之间共享，那么就只能使用synchronized、lock、CAS等这些实现线程同步的方法了。

Spring 框架中都用到了哪些设计模式？

简单工厂：由一个工厂类根据传入的参数，动态决定应该创建哪一个产品类。
Spring中的BeanFactory就是简单工厂模式的体现，根据传入一个唯一的标识来获得Bean对象，但是否是在传入参数后创建还是传入参数前创建这个要根据具体情况来定。

工厂方法：
实现了FactoryBean接口的bean是一类叫做factory的bean。其特点是，spring会在使用getBean()调用获得该bean时，会自动调用该bean的getObject()方法，所以返回的不是factory这个bean，而是这个bean.getOjbect()方法的返回值。

单例模式：保证一个类仅有一个实例，并提供一个访问它的全局访问点
spring对单例的实现： spring中的单例模式完成了后半句话，即提供了全局的访问点BeanFactory。但没有从构造器级别去控制单例，这是因为spring管理的是任意的java对象。

适配器模式：
Spring定义了一个适配接口，使得每一种Controller有一种对应的适配器实现类，让适配器代替controller执行相应的方法。这样在扩展Controller时，只需要增加一个适配器类就完成了SpringMVC的扩展了。

装饰器模式：动态地给一个对象添加一些额外的职责。就增加功能来说，Decorator模式相比生成子类更为灵活。
Spring中用到的包装器模式在类名上有两种表现：一种是类名中含有Wrapper，另一种是类名中含有Decorator。

动态代理：
切面在应用运行的时刻被织入。一般情况下，在织入切面时，AOP容器会为目标对象创建动态的创建一个代理对象。SpringAOP就是以这种方式织入切面的。

植入：把切面应用到目标对象并创建新的代理对象的过程。

观察者模式：
spring的事件驱动模型使用的是 观察者模式 ，Spring中Observer模式常用的地方是listener的实现。

策略模式：
Spring框架的资源访问Resource接口。该接口提供了更强的资源访问能力，Spring 框架本身大量使用了 Resource 接口来访问底层资源。

模板方法：父类定义了骨架（调用哪些方法及顺序），某些特定方法由子类实现。

最大的好处：代码复用，减少重复代码。除了子类要实现的特定方法，其他方法及方法调用顺序都在父类中预先写好了。

refresh方法

Spring事务的实现方式和原理以及隔离级别？

在使用Spring框架时，可以有两种使用事务的方式，一种是编程式的，一种是申明式的，@Transactional注解就是申明式的。

首先，事务这个概念是数据库层面的，Spring只是基于数据库中的事务进行了扩展，以及提供了一些能让程序员更加方便操作事务的方式。

比如我们可以通过在某个方法上增加@Transactional注解，就可以开启事务，这个方法中所有的sql都会在一个事务中执行，统一成功或失败。

在一个方法上加了@Transactional注解后，Spring会基于这个类生成一个代理对象，会将这个代理对象作为bean，当在使用这个代理对象的方法时，如果这个方法上存在@Transactional注解，那么代理逻辑会先把事务的自动提交设置为false，然后再去执行原本的业务逻辑方法，如果执行业务逻辑方法没有出现异常，那么代理逻辑中就会将事务进行提交，如果执行业务逻辑方法出现了异常，那么则会将事务进行回滚。

当然，针对哪些异常回滚事务是可以配置的，可以利用@Transactional注解中的rollbackFor属性进行配置，默认情况下会对RuntimeException和Error进行回滚。

spring事务隔离级别就是数据库的隔离级别：外加一个默认级别

• read uncommitted（未提交读）
• read committed（提交读、不可重复读）
• repeatable read（可重复读）
• serializable（可串行化）

数据库的配置隔离级别是Read Commited,而Spring配置的隔离级别是Repeatable Read，请问这时隔离级别是以哪一个为准？

答：以Spring配置的为准，如果spring设置的隔离级别数据库不支持，效果取决于数据库

spring事务传播机制

多个事务方法相互调用时，事务如何在这些方法间传播

答：方法A是一个事务的方法，方法A执行过程中调用了方法B，那么方法B有无事务以及方法B对事务的要求不同都会对方法A的事务具体执行造成影响，同时方法A的事务对方法B的事务执行也有影响，这种影响具体是什么就由两个方法所定义的事务传播类型所决定。

• REQUIRED(Spring默认的事务传播类型)：如果当前没有事务（A没有事务），则自己新建一个事务（B新建一个事务），如果当前存在事务，则加入这个事务（REQUIRED(还有下面所有参数)都是修饰的B）
  举例：（1）A调用B,如果A没有事务，则B创建一个事务进行操作。
  （2）如果A有事务，则B加入到事务中。比如：A有两个sql操作，B有两个sql操作，则四个sql变成了一个事务，执行事务的时候大家要么一起成功，要么一起失败。

• SUPPORTS：当前存在事务，则加入当前事务，如果当前没有事务，就以非事务方法执行
  A调用B，如果当前A存在事务,则加入事务，如果A没有事务，就以非事务运行（单独知识sql,不需要回滚等事务操作）。

• MANDATORY：当前存在事务，则加入当前事务，如果当前事务不存在，则抛出异常。

• REQUIRES_NEW：创建一个新事务，如果存在当前事务，则挂起该事务。
  A调用B，B创建一个事务，如果A存在事务，就把A事务挂起，执行事务B以后，再执行事务A（即事务分开操作）。

• NOT_SUPPORTED：以非事务方式执行,如果当前存在事务，则挂起当前事务

• NEVER：不使用事务，如果当前事务存在，则抛出异常

• NESTED：如果当前事务存在，则在嵌套事务中执行，否则REQUIRED的操作一样（开启一个事务）
  嵌套事务：A调用B，如果A没有事务，B自己开启一个事务。如果A有事务，则B事务嵌套在里面，A是父事务，B是一个子事务。如果父事务有异常，父，子事务都回滚。如果子事务有异常，父事务不一定回滚。解释：如果子事务被try-catch捕获异常，异常被处理，父事务就不收影响。

NESTED和REQUIRES_NEW的区别
REQUIRES_NEW是新建一个事务并且新开启的这个事务与原有事务无关，而NESTED则是当前存在事务时（我们把当前事务称之为父事务）会开启一个嵌套事务（称之为一个子事务）。 在NESTED情况下父事务回滚时，子事务也会回滚，而在REQUIRES_NEW情况下，原有事务回滚，不会影响新开启的事务。

NESTED和REQUIRED的区别
REQUIRED情况下，调用方存在事务时，则被调用方和调用方使用同一事务，那么被调用方出现异常时，由于共用一个事务，所以无论调用方是否catch其异常，事务都会回滚 而在NESTED情况下，被调用方发生异常时，调用方可以catch其异常，这样只有子事务回滚，父事务不受影响

spring事务什么时候会失效?

spring事务的原理是AOP，进行了切面增强，那么失效的根本原因是这个AOP不起作用了！常见情况有如下几种：
1.发生自调用，类里面使用this调用本类的方法（this通常省略），此时这个this对象不是代理类，而是UserService对象本身！解决方法很简单，让那个this变成UserService的代理类即可！
2.方法不是public的
@Transactional 只能用于 public 的方法上，否则事务不会失效，如果要用在非 public 方法上，可以开启 AspectJ 代理模式。
3.数据库不支持事务
4.没有被spring管理
5.异常被吃掉，事务不会回滚(或者抛出的异常没有被定义，默认为RuntimeException)

什么是bean的自动装配，有哪些方式？

开启自动装配，只需要在xml配置文件中定义“autowire”属性。

<bean id="cutomer" class="com.xxx.xxx.Customer" autowire="" />

autowire属性有五种装配的方式：

• no – 缺省情况下，自动配置是通过“ref”属性手动设定 。

手动装配：以value或ref的方式明确指定属性值都是手动装配。
需要通过‘ref’属性来连接bean。

• byName-根据bean的属性名称进行自动装配。

Cutomer的属性名称是person，Spring会将bean id为person的bean通过setter方法进行自动装配。
<bean id="cutomer" class="com.xxx.xxx.Cutomer" autowire="byName"/>
<bean id="person" class="com.xxx.xxx.Person"/>

• byType-根据bean的类型进行自动装配。

Cutomer的属性person的类型为Person，Sprirng会将Person类型通过setter方法进行自动装配。
<bean id="cutomer" class="com.xxx.xxx.Cutomer" autowire="byType"/>
<bean id="person" class="com.xxx.xxx.Person"/>

• constructor-类似byType，不过是应用于构造器的参数。如果一个bean与构造器参数的类型形同，则进行自动装配，否则导致异常。

Cutomer构造函数的参数person的类型为Person，Spirng会将Person类型通过构造方法进行自动装配。
<bean id="cutomer" class="com.xxx.xxx.Cutomer" autowire="construtor"/>
<bean id="person" class="com.xxx.xxx.Person"/>

• autodetect-如果有默认的构造器，则通过constructor方式进行自动装配，否则使用byType方式进行自动装配。

如果有默认的构造器，则通过constructor方式进行自动装配，否则使用byType方式进行自动装配。

@Autowired自动装配bean，可以在字段、setter方法、构造函数上使用。

SpringBoot、Spring MVC 和 Spring 有什么区别

spring是一个IOC容器，用来管理Bean，使用依赖注入实现控制反转，可以很方便的整合各种框架，提供AOP机制弥补OOP的代码重复问题、更方便将不同类不同方法中的共同处理抽取成切面、自动注入给方法执行，比如日志、异常等

springmvc是spring对web框架的一个解决方案，提供了一个总的前端控制器Servlet，用来接收请求，然后定义了一套路由策略（url到handle的映射）及适配执行handle，将handle结果使用视图解析技术生成视图展现给前端

springboot是spring提供的一个快速开发工具包，让程序员能更方便、更快速的开发spring+springmvc应用，简化了配置（约定了默认配置），整合了一系列的解决方案（starter机制）、redis、mongodb、es，可以开箱即用

SpringMVC 工作流程(springmvc核心问题)

（1）用户发送请求至前端控制器 DispatcherServlet。

（2）DispatcherServlet 收到请求调用 HandlerMapping 处理器映射器。

（3）处理器映射器找到具体的处理器(可以根据 xml 配置、注解进行查找)，生成处理器及处理器拦截器(如果有则生成)一并返回给 DispatcherServlet。

（4）DispatcherServlet 调用 HandlerAdapter 处理器适配器。

（5）HandlerAdapter 经过适配调用具体的处理器(Controller，也叫后端控制器)

（6）Controller 执行完成返回 ModelAndView。

（7）HandlerAdapter 将 controller 执行结果 ModelAndView 返回给 DispatcherServlet。

（8）DispatcherServlet 将 ModelAndView 传给 ViewReslover 视图解析器。

（9）ViewReslover 解析后返回具体 View。

（10）DispatcherServlet 根据 View 进行渲染视图（即将模型数据填充至视图中）。

（11）DispatcherServlet 响应用户。

详解带图

知乎

Spring MVC的主要组件（9大组件）？

Handler：也就是处理器。它直接应对着MVC中的C也就是Controller层，它的具体表现形式有很多，可以是类，也可以是方法。在Controller层中@RequestMapping标注的所有方法都可以看成是一个Handler，只要可以实际处理请求就可以是Handler

1、HandlerMapping-接口（主要）
initHandlerMappings(context)，处理器映射器，根据用户请求的资源uri来查找Handler的。在SpringMVC中会有很多请求，每个请求都需要一个Handler处理，具体接收到一个请求之后使用哪个Handler进行，这就是HandlerMapping需要做的事。

2、HandlerAdapter-接口（主要）
initHandlerAdapters(context)，适配器。因为SpringMVC中的Handler可以是任意的形式，只要能处理请求就ok，但是Servlet需要的处理方法的结构却是固定的，都是以request和response为参数的方法。如何让固定的Servlet处理方法调用灵活的Handler来进行处理呢？这就是HandlerAdapter要做的事情。
Handler是用来干活的工具；HandlerMapping用于根据需要干的活找到相应的工具；HandlerAdapter是使用工具干活的人。

3、HandlerExceptionResolver
initHandlerExceptionResolvers(context)， 其它组件都是用来干活的。在干活的过程中难免会出现问题，出问题后怎么办呢？这就需要有一个专门的角色对异常情况进行处理，在SpringMVC中就是HandlerExceptionResolver。具体来说，此组件的作用是根据异常设置ModelAndView，之后再交给render方法进行渲染。

4、ViewResolver
initViewResolvers(context)，ViewResolver用来将String类型的视图名和Locale解析为View类型的视图。View是用来渲染页面的，也就是将程序返回的参数填入模板里，生成html（也可能是其它类型）文件。这里就有两个关键问题：使用哪个模板？用什么技术（规则）填入参数？这其实是ViewResolver主要要做的工作，ViewResolver需要找到渲染所用的模板和所用的技术（也就是视图的类型）进行渲染，具体的渲染过程则交由不同的视图自己完成。

5、RequestToViewNameTranslator
initRequestToViewNameTranslator(context)，ViewResolver是根据ViewName查找View，但有的Handler处理完后并没有设置View也没有设置ViewName，这时就需要从request获取ViewName了，如何从request中获取ViewName就是RequestToViewNameTranslator要做的事情了。RequestToViewNameTranslator在Spring MVC容器里只可以配置一个，所以所有request到ViewName的转换规则都要在一个Translator里面全部实现。

6、LocaleResolver
initLocaleResolver(context)， 解析视图需要两个参数：一是视图名，另一个是Locale。视图名是处理器返回的，Locale是从哪里来的？这就是LocaleResolver要做的事情。LocaleResolver用于从request解析出Locale，Locale就是zh-cn之类，表示一个区域，有了这个就可以对不同区域的用户显示不同的结果。SpringMVC主要有两个地方用到了Locale：一是ViewResolver视图解析的时候；二是用到国际化资源或者主题的时候。

7、ThemeResolver
initThemeResolver(context)，用于解析主题。SpringMVC中一个主题对应一个properties文件，里面存放着跟当前主题相关的所有资源、如图片、css样式等。SpringMVC的主题也支持国际化，同一个主题不同区域也可以显示不同的风格。SpringMVC中跟主题相关的类有 ThemeResolver、ThemeSource和Theme。主题是通过一系列资源来具体体现的，要得到一个主题的资源，首先要得到资源的名称，这是ThemeResolver的工作。然后通过主题名称找到对应的主题（可以理解为一个配置）文件，这是ThemeSource的工作。最后从主题中获取资源就可以了。

8、MultipartResolver
initMultipartResolver(context)，用于处理上传请求。处理方法是将普通的request包装成MultipartHttpServletRequest，后者可以直接调用getFile方法获取File，如果上传多个文件，还可以调用getFileMap得到FileName->File结构的Map。此组件中一共有三个方法，作用分别是判断是不是上传请求，将request包装成MultipartHttpServletRequest、处理完后清理上传过程中产生的临时资源。

9、FlashMapManager
initFlashMapManager(context)，用来管理FlashMap的，FlashMap主要用在redirect中传递参数。

Spring Boot 自动配置原理？

@Import + @Configuration + Spring spi

自动配置类由各个starter提供，使用@Configuration + @Bean定义配置类，放到META-INF/spring.factories下

使用Spring spi扫描META-INF/spring.factories下的配置类

使用@Import导入自动配置类

如何理解 Spring Boot 中的 Starter

使用spring + springmvc使用，如果需要引入mybatis等框架，需要到xml中定义mybatis需要的bean

starter就是定义一个starter的jar包，写一个@Configuration配置类、将这些bean定义在里面，然后在starter包的META-INF/spring.factories中写入该配置类，springboot会按照约定来加载该配置类

开发人员只需要将相应的starter包依赖进应用，进行相应的属性配置（使用默认配置时，不需要配置），就可以直接进行代码开发，使用对应的功能了，比如mybatis-spring-boot–starter，spring-boot-starter-redis

Mybatis

-Mybatis本是apache的一个开源项目ibatis,2010年这个项目由apache迁移到了google code,并改名为Mybatis。

• Mybatis是一款持久层框架。
• Mybatis避免了几乎所有的JDBC代码和手动设置参数以及获取结果集的过程
• Mybatis 可以使用简单的XML或注解来配置和映射原生信息，将接口和Java实体类[Plain Old java Objects,普通的Java对象]映射成数据库中的记录。

为什么需要Mybatis

• Mybatis就是帮助程序猿将数据存入数据库中，和从数据库中读取。
• 传统的JDBC操作有很多重复代码块，比如：数据取出时的封装，数据库的建立链接等等。通过框架可以减少重复代码，提高开发效率。
• MyBatis是一个半自动化的ORM框架（Object Relatinship Mapping）—>对象关系映射。

mybatis的优缺点

优点：
1.基于 SQL 语句编程，相当灵活，不会对应用程序或者数据库的现有设计造成任何影响，SQL 写在 XML 里，解除 sql 与程序代码的耦合，便于统一管理；提供 XML 标签， 支持编写动态 SQL 语句， 并可重用。

2.与 JDBC 相比，减少了 50%以上的代码量，消除了 JDBC 大量冗余的代码，不需要手动开关连接；

3.很好的与各种数据库兼容（ 因为 MyBatis 使用 JDBC 来连接数据库，所以只要JDBC 支持的数据库 MyBatis 都支持）。

4.能够与 Spring 很好的集成；

5.提供映射标签， 支持对象与数据库的 ORM 字段关系映射； 提供对象关系映射标签， 支持对象关系组件维护。

缺点：
1.SQL 语句的编写工作量较大， 尤其当字段多、关联表多时， 对开发人员编写SQL 语句的功底有一定要求。

2.SQL 语句依赖于数据库， 导致数据库移植性差， 不能随意更换数据库。

#{}和${}的区别是什么？

#{}是预编译处理、是占位符， ${}是字符串替换、是拼接符。

Mybatis 在处理#{}时，会将 sql 中的#{}替换为?号，调用 PreparedStatement 来赋值；

Mybatis 在处理时 ， 就 是 把 {}时， 就是把时，就是把{}替换成变量的值，调用 Statement 来赋值；

#{} 的变量替换是在DBMS 中、变量替换后，#{} 对应的变量自动加上单引号

的 变 量 替 换 是 在 D B M S 外 、 变 量 替 换 后 ， {} 的变量替换是在 DBMS 外、变量替换后，的变量替换是在DBMS外、变量替换后，{} 对应的变量不会加上单引号

使用#{}可以有效的防止 SQL 注入， 提高系统安全性。

简述 Mybatis 的插件运行原理，如何编写一个插件。

答：Mybatis 只支持针对 ParameterHandler、ResultSetHandler、StatementHandler、Executor 这 4 种接口的插件， Mybatis 使用 JDK 的动态代理， 为需要拦截的接口生成代理对象以实现接口方法拦截功能， 每当执行这 4 种接口对象的方法时，就会进入拦截方法，具体就是 InvocationHandler 的 invoke() 方法， 拦截那些你指定需要拦截的方法。

编写插件： 实现 Mybatis 的 Interceptor 接口并复写 intercept()方法， 然后在给插件编写注解， 指定要拦截哪一个接口的哪些方法即可， 在配置文件中配置编写的插件。

@Intercepts({@Signature(type = StatementHandler.class, method = "query", args = {Statement.class, ResultHandler.class}),
        @Signature(type = StatementHandler.class, method = "update", args = {Statement.class}),
        @Signature(type = StatementHandler.class, method = "batch", args = { Statement.class })})
@Component

invocation.proceed()执行具体的业务逻辑

Mysql

数据库设计三范式

什么是设计范式？

设计数据库表的依据，按照这个三范式设计的表不会出现数据冗余（关键点）。

三范式都是那些？

• 第一范式：任何一张表都应该有主键，并且每一个字段原子性不可再分。
• 第二范式：建立在第一范式的基础上，所有非主键字段，完全依赖于主键，不能产生部分依赖。
  多对多（老师和学生）？ 三张表，关系表，两个外键。
  举例：学生一个表，老师一个表，老师和学生关系一个表（一个老师的主键，一个学生的主键）。
• 第三范式：建立在第二范式的基础上，所有非主键字段直接依赖主键，不能产生传递依赖。
  一对多（班级和学生）？两张表，多的表加外键
  举例：

cno(pk)	cname
1	班级1
2	班级2

学生表

sno(pk)	sname	cname
101	张1	1
102	张2	1
103	张2	2

数据库增、删、改、查，左连接，右连接，全连接

table_a

table_b

增加：

删除：

修改：

查找：

各种连接韦恩图：

内连接（INNER JOIN）：

代码：

SELECT  A.PK AS A_PK,A.Value AS A_Value,B.PK AS B_PK,B.Value AS B_Value
FROM table_a A
INNER JOIN table_b B
ON A.PK = B.PK;

查询结果：

左连接（LEFT JOIN）：

代码：

SELECT  A.PK AS A_PK,A.Value AS A_Value,B.PK AS B_PK,B.Value AS B_Value
FROM table_a A
LEFT JOIN  table_b B
ON A.PK = B.PK;

右连接：

代码：

SELECT  A.PK AS A_PK,A.Value AS A_Value,B.PK AS B_PK,B.Value AS B_Value
FROM table_a A
RIGHT JOIN   table_b B
ON A.PK = B.PK;

查询结果：

全连接：
mysql暂时不支持全连接。

索引的基本原理

索引用来快速地寻找那些具有特定值的记录。如果没有索引，一般来说执行查询时遍历整张表。
索引的原理：就是把无序的数据变成有序的查询。
1.把创建了索引的列的内容进行排序
2.对排序结果生成倒排序（正排序就是根据要查询的数据，到数据库中一个一个比对，倒排序就是先把数据库关键字建成一张表，在表中查找）倒排表参考
3.在倒排表内容上拼上数据地址链
4.在查询的时候，先拿到倒排表内容，再取出数据地址链，从而拿到具体数据。

持久化

持久化是将程序数据在持久态和瞬时态间转换的机制。

• 即把数据（如内存中的对象）保存到可永久保存的存储设备中（如磁盘）。持久化的主要应用是将内存中的对象存储在数据库中，或者存储在磁盘文件中，XML数据文件中等等。
• JDBC就是一种持久化机制。文件IO也是一种持久化机制。
• 在生活中：将鲜肉冷藏，吃的时候再解冻的方法也是。将水果做成罐头的方法也是。

持久层

• 完成持久化工作的代码块。-----》dao层[DAO(Data Access Object)数据访问对象]
• 大多数情况下，特别是企业级应用，数据持久化往往也就是意味着将内存中的数据保存到磁盘上加以固化，而持久化的实现过程则大多通过各种关系数据库来完成的。
• 持久层是一个相对对立的逻辑层面，专注于数据持久化逻辑实现。说白了就是操作数据库实现的。

JDBC

JDBC（Java DataBase Connectivity）是Java和数据库之间的一个桥梁，是一个规范而不是一个实现，能够执行SQL语句。它由一组用Java语言编写的类和接口组成。各种不同类型的数据库都有相应的实现，本文中的代码都是针对MySQL数据库实现的。
JDBC详解

事务四大特性

事务基本特性ACID分别是：

• 原子性（Atomicity）
  原子性是指事务包含的所有操作要么全部成功，要么全部失败回滚，因此事务的操作如果成功就必须要完全应用到数据库，如果操作失败则不能对数据库有任何影响。

• 一致性（Consistency）
  事务开始前和结束后，数据库的完整性约束没有被破坏。比如A向B转账，不可能A扣了钱，B却没收到。

• 隔离性（Isolation）
  隔离性是当多个用户并发访问数据库时，比如操作同一张表时，数据库为每一个用户开启的事务，不能被其他事务的操作所干扰，多个并发事务之间要相互隔离。
  举例：
  同一时间，只允许一个事务请求同一数据，不同的事务之间彼此没有任何干扰。比如A正在从一张银行卡中取钱，在A取钱的过程结束前，B不能向这张卡转账。

• 持久性（Durability）
  持久性是指一个事务一旦被提交了，那么对数据库中的数据的改变就是永久性的，即便是在数据库系统遇到故障的情况下也不会丢失提交事务的操作。

事务的并发？事务隔离级别，每个级别会引发什么问题，MySQL默认是哪个级别？

从理论上来说, 事务应该彼此完全隔离, 以避免并发事务所导致的问题，然而, 那样会对性能产生极大的影响, 因为事务必须按顺序运行， 在实际开发中, 为了提升性能, 事务会以较低的隔离级别运行， 事务的隔离级别可以通过隔离事务属性指定。

事务并发问题

（1）脏读：事务A读取了事务B更新的数据，然后B回滚操作，那么A读取到的数据是脏数据。
（2）不可重复读：事务 A 多次读取同一数据，事务 B 在事务A多次读取的过程中，对数据作了更新并提交，导致事务A多次读取同一数据时，结果因此本事务先后两次读到的数据结果会不一致。
（3）幻读：幻读解决了不重复读，保证了同一个事务里，查询的结果都是事务开始时的状态（一致性）。
举例：事务T1对一个表中所有的行的某个数据项做了从“1”修改为“2”的操作 这时事务T2又对这个表中插入了一行数据项，而这个数据项的数值还是为“1”并且提交给数据库。 而操作事务T1的用户如果再查看刚刚修改的数据，会发现还有跟没有修改一样，其实这行是从事务T2中添加的，就好像产生幻觉一样，这就是发生了幻读。
小结：不可重复读的和幻读很容易混淆，不可重复读侧重于修改，幻读侧重于新增或删除。解决不可重复读的问题只需锁住满足条件的行，解决幻读需要锁表。

事务隔离级别

• 读未提交：另一个事务修改了数据，但尚未提交，而本事务中的SELECT会读到这些未被提交的数据也叫做脏读。
  举例：用户本来应该读取到id=1的用户age应该是10，结果读取到了其他事务还没有提交的事务，结果读 取结果age=20，这就是脏读。
• 不可重复读（读已提交）：事务 A 多次读取同一数据，事务 B 在事务A多次读取的过程中，对数据作了更新并提交，导致事务A多次读取同一数据时，结果因此本事务先后两次读到的数据结果会不一致。
  举例：用户开启事务读取id=1用户，查询到age=10，再次读取发现结果=20，在同一个事务里同一个查 询读取到不同的结果叫做不可重复读。
• 可重复读：在同一个事务里，SELECT的结果是事务开始时时间点的状态，因此，同样的SELECT操作读到的结果会是一致的。但是，会有幻读现象。
• 串行化：最高的隔离级别，在这个隔离级别下，不会产生任何异常。一般是不会使用的，他会给每一行读取的数据加锁，会导致大量超时和锁竞争的问题。在并发的事务，就像事务是在一个个按照顺序执行一样。

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

都是B+树的数据结构

• 聚簇索引：将数据存储与索引放到了一块、并且是按照一定的顺序组织的，找到索引也就找到了数 据，数据的物理存放顺序与索引顺序是一致的，即：只要索引是相邻的，那么对应的数据一定也是 相邻地存放在磁盘上的 。（在B+树中，叶子节点才存储数据和索引）
• 非聚簇索引：叶子节点不存储数据、存储的是数据行地址，也就是说根据索引查找到数据行的位置 再取磁盘查找数据，这个就有点类似一本树的目录，比如我们要找第三章第一节，那我们先在这个 目录里面找，找到对应的页码后再去对应的页码看文章。（在B+数中，叶子节点不存储数据，存储的是数据的行地址）

优势：
1、查询通过聚簇索引可以直接获取数据，相比非聚簇索引需要第二次查询（第一次先找到索引的数据行，第二次找到具体的数据）（非覆盖索引的情况下）效率要高
举例：
id是索引，name不是索引，对于表A

 select A.id=3 from A;(覆盖索引)
 select A.id=4,A.name='张三'  from A;(非覆盖索引，应为name不是索引)

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+树索引。对于哈希索引来说，底层的数据结构就是哈希表，因 此在绝大多数需求为单条记录查询的时候，可以选择哈希索引，查询性能快；其余大部分场景，建议 选择B+Tree索引。

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引擎 )、记录锁、间 隙锁、临键锁。

基于锁的状态分类：意向共享锁、意向排它锁。

• 共享锁(Share Lock)
  共享锁又称读锁，简称S锁；当一个事务为数据加上读锁之后，其他事务只能对该数据加读锁，而不能对 数据加写锁，直到所有的读锁释放之后其他事务才能对其进行加持写锁。共享锁的特性主要是为了支持 并发的读取数据，读取数据的时候不支持修改，避免出现重复读的问题。
• 排他锁（eXclusive Lock）
  排他锁又称写锁，简称X锁；当一个事务为数据加上写锁时，其他请求将不能再为数据加任何锁，直到该 锁释放之后，其他事务才能对数据进行加锁。排他锁的目的是在数据修改时候，不允许其他人同时修 改，也不允许其他人读取。避免了出现脏数据和脏读的问题。
• 表锁
  表锁是指上锁的时候锁住的是整个表，当下一个事务访问该表的时候，必须等前一个事务释放了锁才能 进行对表进行访问；
  特点： 粒度大，加锁简单，容易冲突；
• 行锁
  行锁是指上锁的时候锁住的是表的某一行或多行记录，其他事务访问同一张表时，只有被锁住的记录不 能访问，其他的记录可正常访问；
  特点：粒度小，加锁比表锁麻烦，不容易冲突，相比表锁支持的并发要高；
• 记录锁(Record Lock)
  记录锁也属于行锁中的一种，只不过记录锁的范围只是表中的某一条记录，记录锁是说事务在加锁后锁 住的只是表的某一条记录。 精准条件命中，并且命中的条件字段是唯一索引 加了记录锁之后数据可以避免数据在查询的时候被修改的重复读问题，也避免了在修改的事务未提交前 被其他事务读取的脏读问题。
• 页锁
  页级锁是MySQL中锁定粒度介于行级锁和表级锁中间的一种锁。表级锁速度快，但冲突多，行级冲突 少，但速度慢。所以取了折衷的页级，一次锁定相邻的一组记录。 特点：开销和加锁时间界于表锁和行锁之间；会出现死锁；锁定粒度界于表锁和行锁之间，并发度一般
• 间隙锁(Gap Lock)
  属于行锁中的一种，间隙锁是在事务加锁后其锁住的是表记录的某一个区间，当表的相邻ID之间出现空 隙则会形成一个区间，遵循左开右闭原则。 范围查询并且查询未命中记录，查询条件必须命中索引、间隙锁只会出现在REPEATABLE_READ（重复 读)的事务级别中。 触发条件：防止幻读问题，事务并发的时候，如果没有间隙锁，就会发生如下图的问题，在同一个事务 里，A事务的两次查询出的结果会不一样。
  比如表里面的数据ID 为 1,4,5,7,10 ,那么会形成以下几个间隙区间，-n-1区间，1-4区间，7-10 区间，10-n区间 （-n代表负无穷大，n代表正无穷大）
• 临建锁(Next-Key Lock)
  也属于行锁的一种，并且它是INNODB的行锁默认算法，总结来说它就是记录锁和间隙锁的组合，临键锁 会把查询出来的记录锁住，同时也会把该范围查询内的所有间隙空间也会锁住，再之它会把相邻的下一 个区间也会锁住 触发条件：范围查询并命中，查询命中了索引。 结合记录锁和间隙锁的特性，临键锁避免了在范围查询时出现脏读、重复读、幻读问题。加了临键锁之 后，在范围区间内数据不允许被修改和插 入。

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

• 意向共享锁
  当一个事务试图对整个表进行加共享锁之前，首先需要获得这个表的意向共享锁。
• 意向排他锁
  当一个事务试图对整个表进行加排它锁之前，首先需要获得这个表的意向排它锁。

InnoDB存储引擎的锁的算法

• Record lock：单个行记录上的锁
• Gap lock：间隙锁，锁定一个范围，不包括记录本身
• Next-key lock：record+gap 锁定一个范围，包含记录本身

相关知识点：

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了额外的数据，可能是查询了多余的行并且抛弃掉了，可能是加载 了许多结果中并不需要的列，对语句进行分析以及重写。
• 分析语句的执行计划，然后获得其使用索引的情况，之后修改语句或者修改索引，使得语句可以尽 可能的命中索引。
• 如果对语句的优化已经无法进行，可以考虑表中的数据量是否太大，如果是的话可以进行横向或者 纵向的分表。