待解决问题

待解决问题:

单例模式

饿汉式

//饿汉式(基于classloader机制避免了多线程的同步问题)
public class Singleton{
    private static Singleton instance = new Singleton();
    private Singleton(){};
    
    public static Singleton getInstance(){
        return instance;
    }
}

懒汉式

//懒汉式(第一次调用才初始化，避免内存浪费)
public class Singleton{
    private static Singleton instance;
    private Singleton(){};
    
    public static synchronized Singleton getInstance(){
        if(instance==null){
            instance = new Singleton();
        }
        return instance;
    }
}

死锁的演示

//演示死锁  (解决上述死锁的方式很简单,使得两者获取锁的顺序相同即可.thread1和thread2都先获取lock1再获取lock2就可以解决死锁)
public class DeathLock {

    public static final String lock_1 = "lock1";
    public static final String lock_2 = "lock2";

    public static void main(String[] args) {
        Thread thread1 = new Thread(() -> {
            try {
                while (true) {
                    synchronized (DeathLock.lock_1) {
                        System.out.println(Thread.currentThread().getName() + "lock1上锁");
                        Thread.sleep(1000);
                        synchronized (DeathLock.lock_2) {
                            System.out.println(Thread.currentThread().getName() + "lock2上锁");
                        }
                    }
                }
            } catch (Exception e) {
                e.printStackTrace();
            }
        });

        Thread thread2 = new Thread(() -> {
            try {
                while (true) {
                    synchronized (DeathLock.lock_2) {
                        System.out.println(Thread.currentThread().getName() + "lock2上锁");
                        Thread.sleep(1000);
                        synchronized (DeathLock.lock_1) {
                            System.out.println(Thread.currentThread().getName() + "lock1上锁");
                        }
                    }
                }
            } catch (Exception e) {
                e.printStackTrace();
            }
        });

        thread1.start();
        thread2.start();
    }
}

Comparable和Comparator区别比较:

• Comparable是排序接口，若一个类实现了Comparable接口，就意味着“该类支持排序”。(在这个类中实现排序)(内部只有一个方法 compareTo())

• 而Comparator是比较器接口，我们若需要控制某个类的次序，可以建立一个“该类的比较器”来进行排序。(我重新创建一个新的类让其继承comparator接口,专门用来排序,实现类内重写compare方法)

• Comparable相当于“内部比较器”，而Comparator相当于“外部比较器”。

两种方法各有优劣， 用Comparable 简单， 只要实现Comparable 接口的对象直接就成为一个可以比较的对象，但是需要修改源代码。 用Comparator 的好处是不需要修改源代码， 而是另外实现一个比较器， 当某个自定义的对象需要作比较的时候，把比较器和对象一起传递过去就可以比大小了， 并且在Comparator 里面用户可以自己实现复杂的可以通用的逻辑，使其可以匹配一些比较简单的对象，那样就可以节省很多重复劳动了。

ConcurrentHashMap的key和value都不能为null:

源码

if (key == null || value == null) throw new NullPointerException();

二义性

假定ConcurrentHashMap也可以存放value为null的值。那不管是HashMap还是ConcurrentHashMap调用map.get(key)的时候，如果返回了null，那么这个null，都有两重含义:

​ 1.这个key从来没有在map中映射过。

​ 2.这个key的value在设置的时候，就是null。

为什么map允许value=null

对于HashMap的正确使用场景是在单线程下使用。

在单线程中，当我们得到的value是null的时候，我可以用hashMap.containsKey(key)方法来区分上面说的两重含义。

所以当map.get(key)返回的值是null，在HashMap中虽然存在二义性，但是结合containsKey方法可以避免二义性。

为什么ConcurrentHashMap不允许

ConcurrentHashMap的使用场景为多线程。

用反证法来推理，假设concurrentHashMap允许存放值为null的value。

这时有A、B两个线程。

线程A调用concurrentHashMap.get(key)方法,返回为null，我们还是不知道这个null是没有映射的null还是存的值就是null。

我们假设此时返回为null的真实情况就是因为这个key没有在map里面映射过。那么我们可以用concurrentHashMap.containsKey(key)来验证我们的假设是否成立，我们期望的结果是返回false。

但是在我们调用concurrentHashMap.get(key)方法之后，containsKey方法之前，有一个线程B执行了concurrentHashMap.put(key,null)的操作。那么我们调用containsKey方法返回的就是true了。这就与我们的假设的真实情况不符合了。也就是上面说的二义性。

对于key不能为null

源码就是这样。。

ConcurrentHashMap也会存在线程安全问题:

用一个多线程并发获取map中的值并加1，看看最后输出的数字如何

public class CHMDemo {
    public static void main(String[] args) throws InterruptedException {
        ConcurrentHashMap<String, Integer> map = new ConcurrentHashMap<String,Integer>();
        map.put("key", 1);
        ExecutorService executorService = Executors.newFixedThreadPool(100);
        for (int i = 0; i < 1000; i++) {
            executorService.execute(new Runnable() {
                @Override
                public void run() {
                    int key = map.get("key") + 1; //step 1
                    map.put("key", key);//step 2
                }
            });
        }
        Thread.sleep(3000); //模拟等待执行结束
        System.out.println("------" + map.get("key") + "------");
        executorService.shutdown();
    }
}

此时我们看看多次执行输出的结果

------790------
------825------
------875------　　

通过观察输出结果可以发现，这段使用ConcurrentHashMap的代码，产生了线程安全的问题。我们来分析一下为什么会发生这种情况。在step1跟step2中，都只是调用ConcurrentHashMap的方法，各自都是原子操作，是线程安全的。但是他们组合在一起的时候就会有问题了，A线程在进入方法后，通过map.get(“key”)拿到key的值，刚把这个值读取出来还没有加1的时候，线程B也进来了，那么这导致线程A和线程B拿到的key是一样的。

为什么重写equals()方法时，必须要求重写hashCode()方法

equals() 方法和 hashcode() 方法间的关系是这样的：

1、如果两个对象相同,那么它们的 hashCode 值一定要相同；

2、如果两个对象的 hashCode 相同，它们并不一定相同

如果重写了 equals() 而未重写 hashcode() 方法，可能就会出现两个没有关系的对象 equals 相同（因为equal都是根据对象的特征进行重写的），但 hashcode 不相同的情况。因为此时 Student 类的 hashcode 方法就是 Object 默认的 hashcode方 法，由于默认的 hashcode 方法是根据对象的内存地址经哈希算法得来的，所以 stu1 != stu2，故两者的 hashcode 值不一定相等。

根据 hashcode 的规则，两个对象相等其 hash 值一定要相等，矛盾就这样产生了。

MySQL联合索引时的最左前缀匹配原则:

MySQL会一直向右匹配直到遇到范围查询（>、<、between、like）就停止匹配，比如 a=“3” and="" b=“4” c>5 and d=6,如果建立(a,b,c,d)顺序的索引，d是无法使用索引的，abc是会走索引的,但是d无法走索引.如果建立(a,b,d,c)的索引则都可以使用到，a、b、d的顺序可以任意调整。

=和in可以乱序，比如 a=1 and b=2 and c=3 建立(a,b,c)索引可以任意顺序，MySQL的查询优化器会帮你优化成索引可以识别的形式。

MySqL中的B+树结构

索引在 MySQL 数据库中分三类：

• B+ 树索引
• Hash 索引
• 全文索引

我们今天要介绍的是工作开发中最常接触到的 InnoDB 存储引擎中的 B+ 树索引。要介绍 B+ 树索引，就不得不提二叉查找树，平衡二叉树和 B 树这三种数据结构。B+ 树就是从他们仨演化来的。

二叉查找树

首先，让我们先看一张图：

从图中可以看到，我们为 user 表（用户信息表）建立了一个二叉查找树的索引。

图中的圆为二叉查找树的节点，节点中存储了键（key）和数据（data）。键对应 user 表中的 id，数据对应 user 表中的行数据。

二叉查找树的特点就是任何节点的左子节点的键值都小于当前节点的键值，右子节点的键值都大于当前节点的键值。顶端的节点我们称为根节点，没有子节点的节点我们称之为叶节点。

如果我们需要查找 id=12 的用户信息，利用我们创建的二叉查找树索引，查找流程如下：

• 将根节点作为当前节点，把 12 与当前节点的键值 10 比较，12 大于 10，接下来我们把当前节点>的右子节点作为当前节点。
• 继续把 12 和当前节点的键值 13 比较，发现 12 小于 13，把当前节点的左子节点作为当前节点。
• 把 12 和当前节点的键值 12 对比，12 等于 12，满足条件，我们从当前节点中取出 data，即 id=12，name=xm。

利用二叉查找树我们只需要 3 次即可找到匹配的数据。如果在表中一条条的查找的话，我们需要 6 次才能找到。

平衡二叉树

上面我们讲解了利用二叉查找树可以快速的找到数据。但是，如果上面的二叉查找树是这样的构造：

这个时候可以看到我们的二叉查找树变成了一个链表。如果我们需要查找 id=17 的用户信息，我们需要查找 7 次，也就相当于全表扫描了。 导致这个现象的原因其实是二叉查找树变得不平衡了，也就是高度太高了，从而导致查找效率的不稳定。为了解决这个问题，我们需要保证二叉查找树一直保持平衡，就需要用到平衡二叉树了。 平衡二叉树又称 AVL 树，在满足二叉查找树特性的基础上，要求每个节点的左右子树的高度差不能超过 1。 下面是平衡二叉树和非平衡二叉树的对比：

由平衡二叉树的构造我们可以发现第一张图中的二叉树其实就是一棵平衡二叉树。

平衡二叉树保证了树的构造是平衡的，当我们插入或删除数据导致不满足平衡二叉树不平衡时，平衡二叉树会进行调整树上的节点来保持平衡。具体的调整方式这里就不介绍了。平衡二叉树相比于二叉查找树来说，查找效率更稳定，总体的查找速度也更快。

B 树

因为内存的易失性。一般情况下，我们都会选择将 user 表中的数据和索引存储在磁盘这种外围设备中。但是和内存相比，从磁盘中读取数据的速度会慢上百倍千倍甚至万倍，所以，我们应当尽量减少从磁盘中读取数据的次数。另外，从磁盘中读取数据时，都是按照磁盘块来读取的，并不是一条一条的读。如果我们能把尽量多的数据放进磁盘块中，那一次磁盘读取操作就会读取更多数据，那我们查找数据的时间也会大幅度降低。如果我们用树这种数据结构作为索引的数据结构，那我们每查找一次数据就需要从磁盘中读取一个节点，也就是我们说的一个磁盘块。我们都知道平衡二叉树可是每个节点只存储一个键值和数据的。那说明什么？说明每个磁盘块仅仅存储一个键值和数据！那如果我们要存储海量的数据呢？

可以想象到二叉树的节点将会非常多，高度也会极其高，我们查找数据时也会进行很多次磁盘 IO，我们查找数据的效率将会极低！

为了解决平衡二叉树的这个弊端，我们应该寻找一种单个节点可以存储多个键值和数据的平衡树。也就是我们接下来要说的 B 树。

B 树（Balance Tree）即为平衡树的意思，下图即是一棵 B 树：

图中的 p 节点为指向子节点的指针，二叉查找树和平衡二叉树其实也有，因为图的美观性，被省略了。

图中的每个节点称为页，页就是我们上面说的磁盘块，在 MySQL 中数据读取的基本单位都是页，所以我们这里叫做页更符合 MySQL 中索引的底层数据结构。

从上图可以看出，B 树相对于平衡二叉树，每个节点存储了更多的键值（key）和数据（data），并且每个节点拥有更多的子节点，子节点的个数一般称为阶，上述图中的 B 树为 3 阶 B 树，高度也会很低。

基于这个特性，B 树查找数据读取磁盘的次数将会很少，数据的查找效率也会比平衡二叉树高很多。

假如我们要查找 id=28 的用户信息，那么我们在上图 B 树中查找的流程如下：

• 先找到根节点也就是页 1，判断 28 在键值 17 和 35 之间，那么我们根据页 1 中的指针 p2 找到页 3。
• 将 28 和页 3 中的键值相比较，28 在 26 和 30 之间，我们根据页 3 中的指针 p2 找到页 8。
• 将 28 和页 8 中的键值相比较，发现有匹配的键值 28，键值 28 对应的用户信息为（28，bv）。

B+ 树

B+ 树是对 B 树的进一步优化。让我们先来看下 B+ 树的结构图：

根据上图我们来看下 B+ 树和 B 树有什么不同：

①B+ 树非叶子节点上是不存储数据的，仅存储键值，而 B 树节点中不仅存储键值，也会存储数据。

之所以这么做是因为在数据库中页的大小是固定的，InnoDB 中页的默认大小是 16KB。

如果不存储数据，那么就会存储更多的键值，相应的树的阶数（节点的子节点树）就会更大，树就会更矮更胖，如此一来我们查找数据进行磁盘的 IO 次数又会再次减少，数据查询的效率也会更快。

另外，B+ 树的阶数是等于键值的数量的，如果我们的 B+ 树一个节点可以存储 1000 个键值，那么 3 层 B+ 树可以存储 1000×1000×1000=10 亿个数据。

一般根节点是常驻内存的，所以一般我们查找 10 亿数据，只需要 2 次磁盘 IO。

②因为 B+ 树索引的所有数据均存储在叶子节点，而且数据是按照顺序排列的。

那么 B+ 树使得范围查找，排序查找，分组查找以及去重查找变得异常简单。而 B 树因为数据分散在各个节点，要实现这一点是很不容易的。

有心的读者可能还发现上图 B+ 树中各个页之间是通过双向链表连接的，叶子节点中的数据是通过单向链表连接的。

其实上面的 B 树我们也可以对各个节点加上链表。这些不是它们之前的区别，是因为在 MySQL 的 InnoDB 存储引擎中，索引就是这样存储的。

也就是说上图中的 B+ 树索引就是 InnoDB 中 B+ 树索引真正的实现方式，准确的说应该是聚集索引（聚集索引和非聚集索引下面会讲到）。

通过上图可以看到，在 InnoDB 中，我们通过数据页之间通过双向链表连接以及叶子节点中数据之间通过单向链表连接的方式可以找到表中所有的数据。

MyISAM 中的 B+ 树索引实现与 InnoDB 中的略有不同。在 MyISAM 中，B+ 树索引的叶子节点并不存储数据，而是存储数据的文件地址。

聚集索引 VS 非聚集索引

在上节介绍 B+ 树索引的时候，我们提到了图中的索引其实是聚集索引的实现方式。

那什么是聚集索引呢？在 MySQL 中，B+ 树索引按照存储方式的不同分为聚集索引和非聚集索引。

这里我们着重介绍 InnoDB 中的聚集索引和非聚集索引：

**①****聚集索引（聚簇索引）：**以 InnoDB 作为存储引擎的表，表中的数据都会有一个主键，即使你不创建主键，系统也会帮你创建一个隐式的主键。

这是因为 InnoDB 是把数据存放在 B+ 树中的，而 B+ 树的键值就是主键，在 B+ 树的叶子节点中，存储了表中所有的数据。

这种以主键作为 B+ 树索引的键值而构建的 B+ 树索引，我们称之为聚集索引。

**②****非聚集索引（非聚簇索引）：**以主键以外的列值作为键值构建的 B+ 树索引，我们称之为非聚集索引。

非聚集索引与聚集索引的区别在于非聚集索引的叶子节点不存储表中的数据，而是存储该列对应的主键，想要查找数据我们还需要根据主键再去聚集索引中进行查找，这个再根据聚集索引查找数据的过程，我们称为回表。

明白了聚集索引和非聚集索引的定义，我们应该明白这样一句话：数据即索引，索引即数据。

利用聚集索引和非聚集索引查找数据

前面我们讲解 B+ 树索引的时候并没有去说怎么在 B+ 树中进行数据的查找，主要就是因为还没有引出聚集索引和非聚集索引的概念。

下面我们通过讲解如何通过聚集索引以及非聚集索引查找数据表中数据的方式介绍一下 B+ 树索引查找数据方法。

利用聚集索引查找数据

还是这张 B+ 树索引图，现在我们应该知道这就是聚集索引，表中的数据存储在其中。

现在假设我们要查找 id>=18 并且 id<40 的用户数据。对应的 sql 语句为：

MySQL

select * from user where id>=18 and id <40

其中 id 为主键，具体的查找过程如下：

①一般根节点都是常驻内存的，也就是说页 1 已经在内存中了，此时不需要到磁盘中读取数据，直接从内存中读取即可。

从内存中读取到页 1，要查找这个 id>=18 and id <40 或者范围值，我们首先需要找到 id=18 的键值。

从页 1 中我们可以找到键值 18，此时我们需要根据指针 p2，定位到页 3。

②要从页 3 中查找数据，我们就需要拿着 p2 指针去磁盘中进行读取页 3。

从磁盘中读取页 3 后将页 3 放入内存中，然后进行查找，我们可以找到键值 18，然后再拿到页 3 中的指针 p1，定位到页 8。

③同样的页 8 页不在内存中，我们需要再去磁盘中将页 8 读取到内存中。

将页 8 读取到内存中后。因为页中的数据是链表进行连接的，而且键值是按照顺序存放的，此时可以根据二分查找法定位到键值 18。

此时因为已经到数据页了，此时我们已经找到一条满足条件的数据了，就是键值 18 对应的数据。

因为是范围查找，而且此时所有的数据又都存在叶子节点，并且是有序排列的，那么我们就可以对页 8 中的键值依次进行遍历查找并匹配满足条件的数据。

我们可以一直找到键值为 22 的数据，然后页 8 中就没有数据了，此时我们需要拿着页 8 中的 p 指针去读取页 9 中的数据。

④因为页 9 不在内存中，就又会加载页 9 到内存中，并通过和页 8 中一样的方式进行数据的查找，直到将页 12 加载到内存中，发现 41 大于 40，此时不满足条件。那么查找到此终止。

最终我们找到满足条件的所有数据，总共 12 条记录：

(18,kl), (19,kl), (22,hj), (24,io), (25,vg) , (29,jk), (31,jk) , (33,rt) , (34,ty) , (35,yu) , (37,rt) , (39,rt) 。

下面看下具体的查找流程图

利用非聚集索引查找数据

读者看到这张图的时候可能会蒙，这是啥东西啊？怎么都是数字。如果有这种感觉，请仔细看下图中红字的解释。

什么？还看不懂？那我再来解释下吧。首先，这个非聚集索引表示的是用户幸运数字的索引（为什么是幸运数字？一时兴起想起来的:-)），此时表结构是这样的。

在叶子节点中，不再存储所有的数据了，存储的是键值和主键。对于叶子节点中的 x-y，比如 1-1。左边的 1 表示的是索引的键值，右边的 1 表示的是主键值。

如果我们要找到幸运数字为 33 的用户信息，对应的 sql 语句为：

select * from user where luckNum=33

查找的流程跟聚集索引一样，这里就不详细介绍了。我们最终会找到主键值 47，找到主键后我们需要再到聚集索引中查找具体对应的数据信息，此时又回到了聚集索引的查找流程。

下面看下具体的查找流程图：

在 MyISAM 中，聚集索引和非聚集索引的叶子节点都会存储数据的文件地址。

有关输入输出的整理:

import java.util.Scanner;

Scanner scanner = new Scanner(System.in);
int n = scanner.nextInt();//读一个整数
String str = scanner.next();//读一个字符串
float fl=  scanner.nextFloat();//读一个浮点数
double db = scanner.nextFloat();//读一个浮点数
String s = scanner.nextLine();//读一整行


//判断是否有下一个输入
scanner.hasNext()
scanner.hasNextInt()
scanner.hasNextDouble()
scanner.hasNextLine() 
    
//输出
System.out.print(); 
System.out.println(); 
System.out.format();
System.out.printf()

//输入描述：输入数组的元素个数，换行输入数组元素
    Scanner scanner = new Scanner(System.in);

    while (scanner.hasNext()){
        int m = scanner.nextInt();
        int[] nums = new int[m];
        for (int i=0;i<m;i++){
            nums[i]  = scanner.nextInt();
        }
        System.out.println(Arrays.toString(nums));
    }

    scanner.close();

//输入描述：输入矩阵行数和列数，输入矩阵
    Scanner scanner = new Scanner(System.in);

    int m = scanner.nextInt();
    int n = scanner.nextInt();
    int nums[][] = new int[m][n];

    for (int i=0;i<m;i++){
        for (int j=0;j<n;j++){
            nums[i][j] = scanner.nextInt();
        }
    }

    scanner.close();

    for (int i=0;i<m;i++){
        System.out.print(Arrays.toString(nums[i])+" ");
    }

//A+B 多次输入多组数据 输入包括两个正整数a,b(1 <= a, b <= 10^9),输入数据包括多组。输出a+b
    Scanner in = new Scanner(System.in);
    int a,b;
    while(in.hasNext()){
        a = in.nextInt();
        b = in.nextInt();
        System.out.println(a+b);
    }

//A+B 一次输入指定组数据 
Scanner sc = new Scanner(System.in);
        int n = sc.nextInt();
        for(int i = 0; i < n; i++){
            int a = sc.nextInt();
            int b = sc.nextInt();
            System.out.println(a+b);
        }

//A+B 指定字符输入停止  输入包括两个正整数a,b,输入数据有多组, 如果输入为0则结束输入  输出a+b的结果
Scanner sc = new Scanner(System.in);
        while(sc.hasNext()){
            int a = sc.nextInt();
            int b = sc.nextInt();
            if(a==0&&b==0){
                break;
            }
            
            System.out.println(a+b);
        } 

//A+B+C 多组输入指定字符停止
Scanner sc = new Scanner(System.in);
        while(sc.hasNext()){
            int a = sc.nextInt();
            int sum = 0;
            if(a == 0) return;
            for(int i = 0; i < a; i++){
                sum += sc.nextInt();
            }
            System.out.println(sum);
        }

//A+B+C+..多组输入不定项求和 
//输入数据有多组, 每行表示一组输入数据。每行不定有n个整数，空格隔开
Scanner sc = new Scanner(System.in);
        while(sc.hasNextLine()){
            int sum = 0;
            String[] s = sc.nextLine().split(" ");
            for(int i = 0; i < s.length; i++){
                sum += Integer.valueOf(s[i]);   //parseInt
            }
            System.out.println(sum);
        }

//字符串排序 一次输入多个字符串
Scanner scanner = new Scanner(System.in);

        String[] str = scanner.nextLine().split(" ");
        Arrays.sort(str);
        System.out.println(Arrays.toString(str));

//字符串排序 多组输入
Scanner scanner = new Scanner(System.in);

        while (scanner.hasNextLine()) {
            String[] str = scanner.nextLine().split(" ");
            Arrays.sort(str);
            System.out.println(Arrays.toString(str));
        }

//将输入的字符串数组"[1,2,3]" 转换为数组nums = [1,2,3];
Scanner scanner = new Scanner(System.in);
		
		String s = scanner.nextLine();
        String substring = s.substring(1, s.length() - 1);
        String[] split = substring.split(",");

        int[] nums = new int[split.length];
         for (int i=0;i<nums.length;i++){
             nums[i] = Integer.valueOf(split[i]);
         }

        System.out.println(Arrays.toString(nums));

//将输入的字符串数组"[1,2,3;4,5,6]" 转换为二维数组nums;
Scanner scanner = new Scanner(System.in);

        String s = scanner.nextLine();
        String substring = s.substring(1, s.length() - 1);
        String[] split = substring.split(";");
        

        int[][] nums = new int[split.length][];
        for (int i=0;i<nums.length;i++){
            String[] split1 = split[i].split(",");
            
            nums[i] = new int[split1.length];
            for (int j=0;j<split1.length;j++){
                nums[i][j] = Integer.valueOf(split1[j]);
            }
        }

快排的时间复杂度证明

在最优情况下

Partition每次都划分得很均匀,此时的时间复杂度T(n) = 2*T(n/2)+n,前者是划分出来的两个均与区域的时间复杂度,然后后者的n是遍历整个数组进行区域划分时所用到的时间复杂度.一分为二，那么各自还需要T（n/2）的时间（注意是最好情况，所以平分两半）.于是不断地划分下去，就有了下面的不等式推断：

这说明，在最优的情况下，快速排序算法的时间复杂度为O(nlogn)

在最坏情况下

(数组已经是按从小到大有序排列,或者说你随机取得最后一个数顺序是这样的),比如[1,2,3,4,5,6,7,8,9],此时每次从最后一个元素开始进行划分的时候,只能确定右指针的位置,所以一次需要n次比较,n-1次比较…一共是n+(n-1)+(n-2)+…+2+1=(n+1)n/2 所以最坏情况的时间复杂度是O(n^2).

快速排序最差的情况就是有序的长度过长或者整个序列就是顺序或者逆序的,此时跟冒泡排序一样要两两比较交换，时间复杂度最差为O (N^2)

仔细思考一下,其实快排也是一个构建树的过程,这种最坏情况就相当于左右的节点全在树的一侧.而理想的情况当然是每次都能将区域均等划分,也就代表着二叉树能相对的平衡,这也是算是对时间复杂度O(nlogn)的一种变相理解吧

附上快排的代码

    //永远的快排
    public static void QuickSort(int[] nums){
        if (nums==null || nums.length<2) return;
        QuickSort(nums,0,nums.length-1);
    }

    private static void QuickSort(int[] nums, int left, int right) {
        if (left<right){
            //随机选一个数和最后一个数做交换
            int random = (int) Math.random() * (right - left + 1);
            swap(nums,left+random,right);

            int[] partition = partition(nums, left, right);
            QuickSort(nums,left,partition[0]);
            QuickSort(nums,partition[1],right);
        }
    }

    //要的就是两个区域的值
    private static int[] partition(int[] nums,int left, int right){
        //注意left表示当前数的位置  arr[right]表示的是我们设置的划分值
        //less是小于区的右边界 more是大于区的左边界
        int less = left-1;
        int more = right;
        while (left<more){
            if (nums[left]<nums[right]){
                swap(nums,++less,left++);
            }else if (nums[left]>nums[right]){
                swap(nums,left,--more);
            }else{
                left++;
            }
        }

        swap(nums,right,more);
        return new int[]{less,more+1};
    }


    private static void swap(int[] nums,int i,int j) {
        int temp = nums[i];
        nums[i] = nums[j];
        nums[j] = temp;
    }

冒泡以及优化/快排/堆排序

冒泡的基本思想:

(假设从小到大排序).每次都将j与j+1位置进行比较,如果nums[j]>nums[j+1]就交换两者的位置,这样的话在一轮的循环之后,就可以将最大的那个数冒泡到最上面去.所以每轮都可以在后面确定一个最大的数.这样的话下次的比较范围就将当前范围减一即可

//冒泡排序
public void bubbleSort(int[] nums){
    if(nums.length<=1) return;
    
    for(int i=0;i<nums.length;i++){//一共比较n轮 确定所有的最大数
        for(int j=0;j<nums.length-i-1;j++){//每轮都将最大的数往上冒泡
            if(nums[j]>nums[j+1]){
                swap(nums,j,j+1);
            }
        }
    }
}

public void swap(int[] arr,int i,int j){
    	arr[i] = arr[i] ^ arr[j];
		arr[j] = arr[i] ^ arr[j];
		arr[i] = arr[i] ^ arr[j];
}

面向对象与面向过程的区别

面向过程是直接将解决问题的步骤分析出来，然后用函数把步骤一步一步实现，然后再依次调用就可以了；

而面向对象是将构成问题的事物，分解成若干个对象，建立对象的目的不是为了完成一个步骤，而是为了描述某个事物在解决问题过程中的行为。

布隆过滤器

布隆过滤器原理

了解布隆过滤器原理之前，先回顾下 Hash 函数原理。

哈希函数

哈希函数的概念是：将任意大小的输入数据转换成特定大小的输出数据的函数，转换后的数据称为哈希值或哈希编码，也叫散列值。下面是一幅示意图：

所有散列函数都有如下基本特性：

• 如果两个散列值是不相同的（根据同一函数），那么这两个散列值的原始输入也是不相同的。这个特性是散列函数具有确定性的结果，具有这种性质的散列函数称为单向散列函数。
• 散列函数的输入和输出不是唯一对应关系的，如果两个散列值相同，两个输入值很可能是相同的，但也可能不同，这种情况称为“散列碰撞（collision）”。

但是用 hash表存储大数据量时，空间效率还是很低，当只有一个 hash 函数时，还很容易发生哈希碰撞。

布隆过滤器数据结构

BloomFilter 是由一个固定大小的二进制向量或者位图（bitmap）和一系列映射函数组成的。

在初始状态时，对于长度为 m 的位数组，它的所有位都被置为0，如下图所示：

当有变量被加入集合时，通过 K 个映射函数将这个变量映射成位图中的 K 个点，把它们置为 1（假定有两个变量都通过 3 个映射函数）。

查询某个变量的时候我们只要看看这些点是不是都是 1 就可以大概率知道集合中有没有它了

• 如果这些点有任何一个 0，则被查询变量一定不在；
• 如果都是 1，则被查询变量很可能存在

为什么说是可能存在，而不是一定存在呢？那是因为映射函数本身就是散列函数，散列函数是会有碰撞的。

误判率

布隆过滤器的误判是指多个输入经过哈希之后在相同的bit位置1了，这样就无法判断究竟是哪个输入产生的，因此误判的根源在于相同的 bit 位被多次映射且置 1。

这种情况也造成了布隆过滤器的删除问题，因为布隆过滤器的每一个 bit 并不是独占的，很有可能多个元素共享了某一位。如果我们直接删除这一位的话，会影响其他的元素。(比如上图中的第 3 位)

特性

• 一个元素如果判断结果为存在的时候元素不一定存在，但是判断结果为不存在的时候则一定不存在。
• 布隆过滤器可以添加元素，但是不能删除元素。因为删掉元素会导致误判率增加。

添加与查询元素步骤

添加元素

1. 将要添加的元素给 k 个哈希函数
2. 得到对应于位数组上的 k 个位置
3. 将这k个位置设为 1

查询元素

1. 将要查询的元素给k个哈希函数
2. 得到对应于位数组上的k个位置
3. 如果k个位置有一个为 0，则肯定不在集合中
4. 如果k个位置全部为 1，则可能在集合中

优点

相比于其它的数据结构，布隆过滤器在空间和时间方面都有巨大的优势。布隆过滤器存储空间和插入/查询时间都是常数 $O(K)$，另外，散列函数相互之间没有关系，方便由硬件并行实现。布隆过滤器不需要存储元素本身，在某些对保密要求非常严格的场合有优势。

布隆过滤器可以表示全集，其它任何数据结构都不能；

缺点

但是布隆过滤器的缺点和优点一样明显。误算率是其中之一。随着存入的元素数量增加，误算率随之增加。但是如果元素数量太少，则使用散列表足矣。

另外，一般情况下不能从布隆过滤器中删除元素。我们很容易想到把位数组变成整数数组，每插入一个元素相应的计数器加 1, 这样删除元素时将计数器减掉就可以了。然而要保证安全地删除元素并非如此简单。首先我们必须保证删除的元素的确在布隆过滤器里面。这一点单凭这个过滤器是无法保证的。另外计数器回绕也会造成问题。

在降低误算率方面，有不少工作，使得出现了很多布隆过滤器的变种。

布隆过滤器使用场景和实例

在程序的世界中，布隆过滤器是程序员的一把利器，利用它可以快速地解决项目中一些比较棘手的问题。

如网页 URL 去重、垃圾邮件识别、大集合中重复元素的判断和缓存穿透等问题。

布隆过滤器的典型应用有：

• 数据库防止穿库。 Google Bigtable，HBase 和 Cassandra 以及 Postgresql 使用BloomFilter来减少不存在的行或列的磁盘查找。避免代价高昂的磁盘查找会大大提高数据库查询操作的性能。
• 业务场景中判断用户是否阅读过某视频或文章，比如抖音或头条，当然会导致一定的误判，但不会让用户看到重复的内容。
• 缓存宕机、缓存击穿场景，一般判断用户是否在缓存中，如果在则直接返回结果，不在则查询db，如果来一波冷数据，会导致缓存大量击穿，造成雪崩效应，这时候可以用布隆过滤器当缓存的索引，只有在布隆过滤器中，才去查询缓存，如果没查询到，则穿透到db。如果不在布隆器中，则直接返回。
• WEB拦截器，如果相同请求则拦截，防止重复被攻击。用户第一次请求，将请求参数放入布隆过滤器中，当第二次请求时，先判断请求参数是否被布隆过滤器命中。可以提高缓存命中率。Squid 网页代理缓存服务器在 cache digests 中就使用了布隆过滤器。Google Chrome浏览器使用了布隆过滤器加速安全浏览服务
• Venti 文档存储系统也采用布隆过滤器来检测先前存储的数据。
• SPIN 模型检测器也使用布隆过滤器在大规模验证问题时跟踪可达状态空间。

http各个版本的区别

HTTP1.0

优点

1. 简单
   HTTP基本的报文格式就是 header + body。
2. 灵活和易于扩展
   HTTP协议里的各类请求方法`状态码、头字段等都是可以自定义扩展的。
   同时 HTTP 由于是工作在应用层（ OSI 第七层），则它下层可以随意变化。
3. 应用广泛和跨平台

缺点

1. 无状态

服务器不会去记忆 HTTP 的状态，所以不需要额外的资源来记录状态信息(无状态的问题解决方法有cookie/session/token)

​ 2.不安全

• 明文传输

• 不验证通信方的身份

• 无法证明报文的完整性

安全问题HTTPS得到了解决。

​ 3.无连接(短连接)

浏览器的每次请求都要与服务器建立一个TCP连接，服务器完成请求处理后立即断开TCP连接。

每个TCP只能发送一个请求。发送数据完毕，连接就关闭。如果还要请求其他资源，就需要再建立一个连接。

TCP三次握手是一个很耗费时间的过程，所以HTTP/1.0性能比较差。

请求报文

• 请求行由请求方法、URL 和 HTTP协议版本三个字段组成。中间由空格隔开。例如：GET /index.html HTTP/1.1。

HTTP协议的请求方法有GET、POST、HEAD、PUT、DELETE、OPTIONS、TRACE、CONNECT。

常见的：

1. GET

• 当客户端要从服务器读取文档时，点击网页上的链接或者通过在浏览器的地址栏输入网址来浏览网页，都是GET方式。
• GET方法要求服务器将URL定位的资源放在响应报文的数据部分，会送给客户端。
• 使用GET方法时，请求参数和对应的值附加在URL后面，以一个（？）代表URL的结尾与请求参数的开始，传递参数长度受限制。例如:/index.jsp?id=100&op=bind.

​ 2.POST

• POST方法将请求的参数封装在HTTP请求数据中，以名称/值的方式出现，可以传输大量数据，对传送的大小没有限制，也不会显示在URL中。

​ 3.HEAD

• HEAD就像GET，只不过服务端接受到HEAD请求后只返回响应头，而不会发送响应内容。当我们只需要查看某个页面的状态的时候，使用HEAD是非常高效的，因为在传输的过程中省去了页面内容。

GET和POST的区别?

1. GET方法是请求从服务器获取资源，可以是图片、文本、页面、视频等。 POST是向URI指定的资源提交数据，数据就放在请求报文的BODY里。
2. GET请求会把请求的数据附在URL后。POST提交是将数据放在报文的body里。 因此GET提交的数据会在地址栏中显示出来，而POST提交地址栏不会改变。
3. 是否安全且幂等

安全和幂等：

• 安全：请求方法不会破坏服务器上的资源
• 幂等：多次执行相同的操作，结果都是相同的。

GET是安全且幂等，因为它的操作是只读的，无论操作多少次，服务器上的数据都是安全的，且每次结果都相同。
POST 因为是新增或提交数据，因此它会修改服务器上的资源，所以是不安全的，且多次提交数据就会创建多个资源，也是不幂等的。

1. 安全性：

POST的安全性要比GET的安全性高。

注意：这里所说的安全性和上面GET提到的“安全”不是同个概念。上面“安全”的含义仅仅是不作数据修改，而这里安全的含义是真正的Security的含义，

比如：通过GET提交数据，用户名和密码将明文出现在URL上，因为(1)登录页面有可能被浏览器缓存， (2)其他人查看浏览器的历史纪录，那么别人就可以拿到你的账号和密码了。

1. POST传输的资源更大，数据类型更多。
2. get 获取资源的速度更快！！

HTTP 1.1改进

1. 缓存处理

在HTTP1.0中主要使用header里的If-Modified-Since,Expires来做为缓存判断的标准，HTTP1.1则引入了更多的缓存控制策略例如Entity tag，If-Unmodified-Since, If-Match, If-None-Match等更多可供选择的缓存头来控制缓存策略。

1. 带宽优化及网络连接的使用

HTTP1.0中，存在一些浪费带宽的现象，例如客户端只是需要某个对象的一部分，而服务器却将整个对象送过来了，并且不支持断点续传功能，HTTP1.1则在请求头引入了range头域，它允许只请求资源的某个部分，即返回码是206（Partial Content），这样就方便了开发者自由的选择以便于充分利用带宽和连接。

1. 错误通知的管理

在HTTP1.1中新增了24个错误状态响应码，如409（Conflict）表示请求的资源与资源的当前状态发生冲突；410（Gone）表示服务器上的某个资源被永久性的删除。

1. HOST头处理

在HTTP1.0中认为每台服务器都绑定一个唯一的IP地址，因此，请求消息中的URL并没有传递主机名（hostname）。但随着虚拟主机技术的发展，在一台物理服务器上可以存在多个虚拟主机（Multi-homed Web Servers），并且它们共享一个IP地址。HTTP1.1的请求消息和响应消息都应支持Host头域，且请求消息中如果没有Host头域会报告一个错误（400 Bad Request）。

1. 长连接

在早期的HTTP1.0中，每次http请求都要建立一个TCP连接，创建连接的过程需要消耗资源和时间，为了减少资源消耗，就需要重用连接。

后来的HTTP1.0 与 HTTP1.1 中，引用了重用连接的机制，在HTTP请求头中加入Connection:keep-alive，告诉对方这个响应完成后不要关闭，下一次继续使用。

HTTP1.0需要保持长连接要在头部信息中加入此参数，HTTP1.1 默认长连接，可以不加。如果不需要长连接，则在头部信息加上：Connection:close，接受到请求的客户端就会自动关闭连接。

长连接会一直保持吗？

不会！ 一般服务端都会设置keep-alive超时时间，超过指定的时间间隔，服务端主动关闭连接。

同时，服务端还会设置最大请求数，比如最大请求数为300，只要超过最大请求数，即使没到超时时间，都会主动关闭连接。

参数content-length，指明响应体数据的大小，浏览器收到如数的响应知道响应完成，就可以关闭连接。

1. 管道网络传输

采用长连接的方式，管道传输成为了可能。长连接有两种工作方式：非流水线方式和流水线方式。

• 非流水线方式：客户端在收到前一个响应之后才能发出下一个请求。在TCP连接建立后，客户端每访问一次对象都要消耗一个RTT。优点：比非持续连接的两倍RTT节省了建立TCP连接所需的一个RTT。 缺点：服务器发送完一个对象之后，其TCP连接处于空闲状态，浪费服务器资源。
• 流水线方式：客户在收到HTTP响应之前，就接着发送新的请求。服务器可以持续发送响应报文。优点：只需要一个RTT。使TCP连接中的空闲时间减少，提高文档下载效率。

但是服务器会按照顺序，回应请求。如果前面的请求特别慢，后面的请求就会排队等待。称为队头堵塞。

HTTP 2.0 改进

1. 头部压缩

如果发送多个请求，头部使一样的或是相似的，协议会消除重复的部分。

HPACK算法：在客户端和服务器同时维护一张头信息表，所有字段都会存入这个表，生成一个索引号，以后就不发送同样字段了，只发送索引号，这样就提高速度了。

1. 二进制格式

报文采用了二进制格式。

头信息和数据体都是二进制，统称为帧：头信息帧和数据帧。

这样虽然对用户不友好，但是对计算机非常友好，因为计算机只懂二进制，那么收到报文后，无需再将明文的报文转成二进制，而是直接解析二进制报文，这增加了数据传输的效率。

1. 数据流

数据包不是连续发送的，同一个连接里面的连续的数据包，可能属于不同的回应。必须对包进行标记，指出属于哪个回应。

每个请求或回应的所有数据包，称为一个数据流（Stream）。

每个数据流都标记着一个独一无二的编号，其中规定客户端发出的数据流编号为奇数， 服务器发出的数据流编号为偶数

客户端还可以指定数据流的优先级。优先级高的请求，服务器就先响应该请求。

1. 多路复用

HTTP/2 是可以在一个连接中并发多个请求或回应，而不用按照顺序一一对应。

移除了 HTTP/1.1 中的串行请求，不需要排队等待，也就不会再出现「队头阻塞」问题，降低了延迟，大幅度提高了连接的利用率。

举例来说，在一个 TCP 连接里，服务器收到了客户端 A 和 B 的两个请求，如果发现 A 处理过程非常耗时，于是就回应 A 请求已经处理好的部分，接着回应 B 请求，完成后，再回应 A 请求剩下的部分。
HTTP/2 为了解决HTTP/1.1中仍然存在的效率问题，HTTP/2 采用了多路复用。即在一个连接里，客户端和浏览器都可以同时发送多个请求或回应，而且不用按照顺序一一对应。能这样做有一个前提，就是HTTP/2进行了二进制分帧，即 HTTP/2 会将所有传输的信息分割为更小的消息和帧（frame）,并对它们采用二进制格式的编码。

也就是说，老板可以同时下达多个命令，员工也可以收到了A请求和B请求，于是先回应A请求，结果发现处理过程非常耗时，于是就发送A请求已经处理好的部分， 接着回应B请求，完成后，再发送A请求剩下的部分。A请求的两部分响应在组合到一起发给老板。

而这个负责拆分、组装请求和二进制帧的一层就叫做二进制分帧层。
除此之外，还有一些其他的优化，比如做Header压缩、服务端推送等。

HTTPS 改进

HTTPS 在 HTTP 与TCP之间加入了 SSL/TLS协议。

HTTPS如何解决 HTTP不安全的问题？

• 混合加密的方式实现了信息的机密性，解决了窃听的风险。
• 摘要算法保证数据的完整性，能够为数据生成独一无二的指纹，指纹用于校验数据的完整性，解决了篡改的风险。
• 将服务器公钥放入数字证书中，解决了冒充的风险。

HTTP 与 HTTPS 区别？

1. HTTP是超文本传输协议，信息是明文传输，存在安全风险的问题。HTTPS解决了HTTP不安全的缺陷，在TCP与HTTP之间加入了SSL/TLS协议，保证报文能够加密传输。
2. HTTP连接建立相对简单，TCP三次握手之后可进行HTTP传输。而HTTPS在三次握手之后，还要进行SSL/TLS握手过程，才可以进入加密传输。
3. HTTP的端口号是80，HTTPS端口号是443.
4. HTTPS需要向CA（证书权威机构）申请数字证书，保证服务器是可信的。

联合索引

为什么要使用联合索引

• 1、减少开销。建一个联合索引(col1,col2,col3)，实际相当于建了(col1),(col1,col2),(col1,col2,col3)三个索引。每多一个索引，都会增加写操作的开销和磁盘空间的开销。对于大量数据的表，使用联合索引会大大的减少开销！
• 2、覆盖索引。对联合索引(col1,col2,col3)，如果有如下的sql: select col1,col2,col3 from test where col1=1 and col2=2。那么MySQL可以直接通过遍历索引取得数据，而无需回表，这减少了很多的随机io操作。减少io操作，特别的随机io其实是dba主要的优化策略。所以，在真正的实际应用中，覆盖索引是主要的提升性能的优化手段之一。
• 3、效率高。索引列越多，通过索引筛选出的数据越少。有1000W条数据的表，有如下sql:select from table where col1=1 and col2=2 and col3=3,假设假设每个条件可以筛选出10%的数据，如果只有单值索引，那么通过该索引能筛选出1000W10%=100w条数据，然后再回表从100w条数据中找到符合col2=2 and col3= 3的数据，然后再排序，再分页；如果是联合索引，通过索引筛选出1000w10% 10% *10%=1w，效率提升可想而知！

最左匹配原则的原理

最左匹配原则都是针对联合索引来说的，所以我们可以从联合索引的原理来了解最左匹配原则。

我们都知道索引的底层是一颗 B+ 树，那么联合索引当然还是一颗 B+ 树，只不过联合索引的键值数量不是一个，而是多个。构建一颗 B+ 树只能根据一个值来构建，因此数据库依据联合索引最左的字段来构建 B+ 树。例子：假如创建一个（a,b,c)的联合索引，那么它的索引树是这样的：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-ZqsOfG2h-1650292945644)(C:\Users\hanxiao\AppData\Roaming\Typora\typora-user-images\image-20220323215706642.png)]

该图就是一个形如(a,b,c)联合索引的 b+ 树，其中的非叶子节点存储的是第一个关键字的索引 a，而叶子节点存储的是三个关键字的数据。这里可以看出 a 是有序的，而 b，c 都是无序的。但是当在 a 相同的时候，b 是有序的，b 相同的时候，c 又是有序的。通过对联合索引的结构的了解，那么就可以很好的了解为什么最左匹配原则中如果遇到范围查询就会停止了。以 select * from t where a=5 and b>0 and c =1; #这样a,b可以用到（a,b,c），c不可以 为例子，当查询到 b 的值以后（这是一个范围值），c 是无序的。所以就不能根据联合索引来确定到底该取哪一行。

该图就是一个形如(a,b,c)联合索引的 b+ 树，其中的非叶子节点存储的是第一个关键字的索引 a，而叶子节点存储的是三个关键字的数据。这里可以看出 a 是有序的，而 b，c 都是无序的。但是当在 a 相同的时候，b 是有序的，b 相同的时候，c 又是有序的。通过对联合索引的结构的了解，那么就可以很好的了解为什么最左匹配原则中如果遇到范围查询就会停止了。以 select * from t where a=5 and b>0 and c =1; #这样a,b可以用到（a,b,c），c不可以 为例子，当查询到 b 的值以后（这是一个范围值），c 是无序的。所以就不能根据联合索引来确定到底该取哪一行。

操作系统里的I/O

TopK问题

callable里面的方法

大kv放在redis怎么解决？

TCP报文的结构？

Zset如何做的排序？底层原理数据结构是什么?

Redis zset（有序集合）中的成员是有序排列的，它和 set 集合的相同之处在于，集合中的每一个成员都是字符串类型，并且不允许重复；而它们最大区别是，有序集合是有序的，set 是无序的，这是因为有序集合中每个成员都会关联一个 double（双精度浮点数）类型的 score (分数值)，Redis 正是通过 score 实现了对集合成员的排序。

Redis 使用以下命令创建一个有序集合：

127.0.0.1:6379> ZADD key score member [score member ...]  

key：指定一个键名；
score：分数值，用来描述 member，它是实现排序的关键；
member：要添加的成员（元素）。

当 key 不存在时，将会创建一个新的有序集合，并把分数/成员（score/member）添加到有序集合中；当 key 存在时，但 key 并非 zset 类型，此时就不能完成添加成员的操作，同时会返回一个错误提示。

注意：在有序集合中，成员是唯一存在的，但是分数（score）却可以重复。有序集合的最大的成员数为 2^32 - 1 (大约 40 多亿个)。

有序集合（zset）同样使用了两种不同的存储结构，分别是 zipList（压缩列表）和 skipList（跳跃列表），当 zset 满足以下条件时使用压缩列表：

• 成员的数量小于128 个；
• 每个 member （成员）的字符串长度都小于 64 个字节。

当有序结合不满足使用压缩列表的条件时，就会使用 skipList 结构来存储数据。跳跃列表（skipList）又称“跳表”是一种基于链表实现的随机化数据结构，其插入、删除、查找的时间复杂度均为 O(logN)。

MySQL有哪些索引的分类

普通索引、唯一索引、主键索引、组合索引、全文索引

Spring的AOP原理

AOP（Aspect Oriented Programming）是基于切面编程的，可无侵入的在原本功能的切面层添加自定义代码，一般用于日志收集、权限认证等场景。

AOP是基于切面编程的,编程思想就是把业务逻辑和横切的问题(非业务比如日志记录 权限认证 事务 安全)进行分离，从而达到解耦的目的，使代码的重用性和开发效率高（目的是重用代码，把公共的代码抽取出来）

可以通过预编译方式和运行期动态代理实现在不修改源代码的情况下给程序动态统一添加功能的一种技术。AOP设计模式孜孜不倦追求的是调用者和被调用者之间的解耦，AOP 可以说也是这种目标的一种实现。我们现在做的一些非业务，如：日志、事务、安全等都会写在业务代码中(也即是说，这些非业务类横切于业务类)，但这些代码往往是重复，复制——粘贴式的代码会给程序的维护带来不便，AOP 就实现了把这些业务需求与系统需求分开来做。这种解决的方式也称代理机制。

AOP代理主要分为静态代理和动态代理，静态代理的代表为AspectJ；而动态代理则以Spring AOP为代表。所谓的静态代理就是AOP框架会在编译阶段生成AOP代理类，因此也称为编译时增强.

使用AspectJ的编译时增强实现AOP

之前提到，AspectJ是静态代理的增强，所谓的静态代理就是AOP框架会在编译阶段生成AOP代理类，因此也称为编译时增强。

举个实例的例子来说。首先我们有一个普通的Hello类

public class Hello {    
	public void sayHello() {
        System.out.println("hello");
    }
    public static void main(String[] args) {
        Hello h = new Hello();
        h.sayHello();
    }
}

//使用AspectJ编写一个Aspect
 public aspect TxAspect {
     void around():call(void Hello.sayHello()){
         System.out.println("开始事务 ...");
         proceed();
         System.out.println("事务结束 ...");
     }
 }

这里模拟了一个事务的场景，类似于Spring的声明式事务。使用AspectJ的编译器编译

ajc -d . Hello.java TxAspect.aj

编译完成之后再运行这个Hello类，可以看到以下输出

开始事务 …

hello

事务结束 …

显然，AOP已经生效了，那么究竟AspectJ是如何在没有修改Hello类的情况下为Hello类增加新功能的呢？

查看一下编译后的Hello.class

public class Hello {
    public Hello() {
    }     
    public void sayHello() {
        System.out.println("hello");
    }
    public static void main(String[] args) {
        Hello h = new Hello();
        sayHello_aroundBody1$advice(h, TxAspect.aspectOf(), (AroundClosure)null);
    }
}

可以看到，这个类比原来的Hello.java多了一些代码，这就是AspectJ的静态代理，它会在编译阶段将Aspect织入Java字节码中， 运行的时候就是经过增强之后的AOP对象。

public void ajc$around$com_listenzhangbin_aop_TxAspect$1$f54fe983(AroundClosure ajc$aroundClosure) {
    System.out.println("开始事务 ...");                                                                                               ajc$around$com_listenzhangbin_aop_TxAspect$1$f54fe983proceed(ajc$aroundClosure);
    System.out.println("事务结束 ...");
}

从Aspect编译后的class文件可以更明显的看出执行的逻辑。proceed方法就是回调执行被代理类中的方法。

使用Spring AOP

与AspectJ的静态代理不同，Spring AOP使用的动态代理，所谓的动态代理就是说AOP框架不会去修改字节码，而是在内存中临时为方法生成一个AOP对象，这个AOP对象包含了目标对象的全部方法，并且在特定的切点做了增强处理，并回调原对象的方法。

Spring AOP中的动态代理主要有两种方式，JDK动态代理和CGLIB动态代理。JDK动态代理通过反射来接收被代理的类，并且要求被代理的类必须实现一个接口。JDK动态代理的核心是InvocationHandler接口和Proxy类。

如果目标类没有实现接口，那么Spring AOP会选择使用CGLIB来动态代理目标类。CGLIB（Code Generation Library），是一个代码生成的类库，可以在运行时动态的生成某个类的子类，注意，CGLIB是通过继承的方式做的动态代理，因此如果某个类被标记为final，那么它是无法使用CGLIB做动态代理的。

动态代理个静态代理的区别:

AspectJ在编译时就增强了目标对象，Spring AOP的动态代理则是在每次运行时动态的增强，生成AOP代理对象，区别在于生成AOP代理对象的时机不同，相对来说AspectJ的静态代理方式具有更好的性能，但 是AspectJ需要特定的编译器进行处理，而Spring AOP则无需特定的编译器处理。

AOP的基本概念

(1)Aspect(切面):通常是一个类，里面可以定义切入点和通知，是对横切关注点的抽象。

(2)JointPoint(连接点):程序执行过程中明确的点,之后需要增强的地方，一般是方法的调用，还可以是字段或则构造器。

(3)Advice(增强)😗*即需要添加的功能,**AOP在特定的切入点上执行的增强处理，包含before,after,afterReturning,afterThrowing,around

(4)Pointcut(切入点):就是带有增强的连接点，在程序中主要体现为书写切入点表达式

(5)AOP代理：AOP框架创建的对象，代理就是目标对象的加强。Spring中的AOP代理可以使JDK动态代理，也可以是CGLIB代理，前者基于接口，后者基于子类

(6)目标对象：代理的目标对象,需要增强的业务类

(7)Waving(织入)：将增强添加到目标类具体连接点上的过程

(8)Introduction(引入)：在不修改代码的前提下，引入可以在运行期为类动态地添加一些方法或字段

事务的传播级别？

事务的隔离级别？

类包含哪些方法？

BIO,NIO,AIO总结以及IO多路复用

同步与异步

• 同步： 同步就是发起一个调用后，被调用者未处理完请求之前，调用不返回。
• 异步： 异步就是发起一个调用后，立刻得到被调用者的回应表示已接收到请求，但是被调用者并没有返回结果，此时我们可以处理其他的请求，被调用者通常依靠事件，回调等机制来通知调用者其返回结果。

同步和异步的区别最大在于异步的话调用者不需要等待处理结果，被调用者会通过回调等机制来通知调用者其返回结果。

阻塞和非阻塞

• 阻塞： 阻塞就是发起一个请求，调用者一直等待请求结果返回，也就是当前线程会被挂起，无法从事其他任务，只有当条件就绪才能继续。
• 非阻塞： 非阻塞就是发起一个请求，调用者不用一直等着结果返回，可以先去干其他事情。

1. BIO (Blocking I/O)

同步阻塞I/O模式，数据的读取写入必须阻塞在一个线程内等待其完成。

2. NIO (New I/O)

2.1 NIO 简介

NIO是一种同步非阻塞的I/O模型，在Java 1.4 中引入了NIO框架，对应 java.nio 包，提供了 Channel , Selector，Buffer等抽象。

NIO中的N可以理解为Non-blocking，不单纯是New。它支持面向缓冲的，基于通道的I/O操作方法。 NIO提供了与传统BIO模型中的 Socket 和 ServerSocket 相对应的 SocketChannel 和 ServerSocketChannel 两种不同的套接字通道实现,两种通道都支持阻塞和非阻塞两种模式。阻塞模式使用就像传统中的支持一样，比较简单，但是性能和可靠性都不好；非阻塞模式正好与之相反。对于低负载、低并发的应用程序，可以使用同步阻塞I/O来提升开发速率和更好的维护性；对于高负载、高并发的（网络）应用，应使用 NIO 的非阻塞模式来开发。

2.2 NIO的特性/NIO与IO区别

如果是在面试中回答这个问题，我觉得首先肯定要从 NIO 流是非阻塞 IO 而 IO 流是阻塞 IO 说起。然后，可以从 NIO 的3个核心组件/特性为 NIO 带来的一些改进来分析。如果，你把这些都回答上了我觉得你对于 NIO 就有了更为深入一点的认识，面试官问到你这个问题，你也能很轻松的回答上来了。

1)Non-blocking IO（非阻塞IO）

IO流是阻塞的，NIO流是不阻塞的。

Java NIO使我们可以进行非阻塞IO操作。比如说，单线程中从通道读取数据到buffer，同时可以继续做别的事情，当数据读取到buffer中后，线程再继续处理数据。写数据也是一样的。另外，非阻塞写也是如此。一个线程请求写入一些数据到某通道，但不需要等待它完全写入，这个线程同时可以去做别的事情。

Java IO的各种流是阻塞的。这意味着，当一个线程调用 read() 或 write() 时，该线程被阻塞，直到有一些数据被读取，或数据完全写入。该线程在此期间不能再干任何事情了

2)Buffer(缓冲区)

IO 面向流(Stream oriented)，而 NIO 面向缓冲区(Buffer oriented)。

Buffer是一个对象，它包含一些要写入或者要读出的数据。在NIO类库中加入Buffer对象，体现了新库与原I/O的一个重要区别。在面向流的I/O中·可以将数据直接写入或者将数据直接读到 Stream 对象中。虽然 Stream 中也有 Buffer 开头的扩展类，但只是流的包装类，还是从流读到缓冲区，而 NIO 却是直接读到 Buffer 中进行操作。

在NIO库中，所有数据都是用缓冲区处理的。在读取数据时，它是直接读到缓冲区中的; 在写入数据时，写入到缓冲区中。任何时候访问NIO中的数据，都是通过缓冲区进行操作。

最常用的缓冲区是 ByteBuffer,一个 ByteBuffer 提供了一组功能用于操作 byte 数组。除了ByteBuffer,还有其他的一些缓冲区，事实上，每一种Java基本类型（除了Boolean类型）都对应有一种缓冲区。

3)Channel (通道)

NIO 通过Channel（通道） 进行读写。

通道是双向的，可读也可写，而流的读写是单向的。无论读写，通道只能和Buffer交互。因为 Buffer，通道可以异步地读写。

4)Selectors(选择器)

NIO有选择器，而IO没有。

选择器用于使用单个线程处理多个通道。因此，它需要较少的线程来处理这些通道。线程之间的切换对于操作系统来说是昂贵的。 因此，为了提高系统效率选择器是有用的。

2.3 NIO 读数据和写数据方式

通常来说NIO中的所有IO都是从 Channel（通道） 开始的。

• 从通道进行数据读取 ：创建一个缓冲区，然后请求通道读取数据。
• 从通道进行数据写入 ：创建一个缓冲区，填充数据，并要求通道写入数据。

数据读取和写入操作图示：

2.4 NIO核心组件简单介绍

NIO 包含下面几个核心的组件：

• Channel(通道)
• Buffer(缓冲区)
• Selector(选择器)

3. AIO (Asynchronous I/O)

AIO 也就是 NIO 2。在 Java 7 中引入了 NIO 的改进版 NIO 2,它是异步非阻塞的IO模型。异步 IO 是基于事件和回调机制实现的，也就是应用操作之后会直接返回，不会堵塞在那里，当后台处理完成，操作系统会通知相应的线程进行后续的操作。

AIO 是异步IO的缩写，虽然 NIO 在网络操作中，提供了非阻塞的方法，但是 NIO 的 IO 行为还是同步的。对于 NIO 来说，我们的业务线程是在 IO 操作准备好时，得到通知，接着就由这个线程自行进行 IO 操作，IO操作本身是同步的。

select,poll,epoll

redis实现分布式锁

注意:使用lua脚本的原因是因为Redis处理每个请求是单线程执行的，在执行一个Lua脚本时其它请求必须等待，直到这个Lua脚本处理完成

setIfAbsent 和 setnx的区别

• setIfAbsent 是java中的方法

• setnx 是 redis命令中的方法

分布式锁如何实现

作为分布式锁实现过程中的共享存储系统，Redis可以使用键值对来保存锁变量，在接收和处理不同客户端发送的加锁和释放锁的操作请求。那么，键值对的键和值具体是怎么定的呢？我们要赋予锁变量一个变量名，把这个变量名作为键值对的键，而锁变量的值，则是键值对的值，这样一来，Redis就能保存锁变量了，客户端也就可以通过Redis的命令操作来实现锁操作。

想要实现分布式锁，必须要求Redis有互斥的能力。可以使用SETNX命令，其含义是SET IF NOT EXIST，即如果key不存在，才会设置它的值，否则什么也不做。两个客户端进程可以执行这个命令，达到互斥，就可以实现一个分布式锁。

以下展示了Redis使用key/value对保存锁变量，以及两个客户端同时请求加锁的操作过程。

加锁操作完成后，加锁成功的客户端，就可以去操作共享资源，例如，修改MySQL的某一行数据。操作完成后，还要及时释放锁，给后来者让出操作共享资源的机会。如何释放锁呢？直接使用DEL命令删除这个key即可。这个逻辑非常简单，整体的流程写成伪代码就是下面这样。

// 加锁
SETNX lock_key 1
// 业务逻辑
DO THINGS
// 释放锁
DEL lock_key
123456

但是，以上实现存在一个很大的问题，当客户端1拿到锁后，如果发生下面的场景，就会造成死锁。

1. 程序处理业务逻辑异常，没及时释放锁
2. 进程挂了，没机会释放锁

以上情况会导致已经获得锁的客户端一直占用锁，其他客户端永远无法获取到锁。

如何避免死锁

为了解决以上死锁问题，最容易想到的方案是在申请锁时，在Redis中实现时，给锁设置一个过期时间，假设操作共享资源的时间不会超过10s，那么加锁时，给这个key设置10s过期即可。

但以上操作还是有问题，加锁、设置过期时间是2条命令，有可能只执行了第一条，第二条却执行失败，例如：

1. SETNX执行成功，执行EXPIRE时由于网络问题，执行失败
2. SETNX执行成功，Redis异常宕机，EXPIRE没有机会执行
3. SETNX执行成功，客户端异常崩溃，EXPIRE没有机会执行

总之这两条命令如果不能保证是原子操作，就有潜在的风险导致过期时间设置失败，依旧有可能发生死锁问题。幸好在Redis 2.6.12之后，Redis扩展了SET命令的参数，可以在SET的同时指定EXPIRE时间，这条操作是原子的，例如以下命令是设置锁的过期时间为10秒。

SET lock_key 1 EX 10 NX
1

至此，解决了死锁问题，但还是有其他问题。想像下面这个这样一种场景：

1. 客户端1加锁成功，开始操作共享资源
2. 客户端1操作共享资源耗时太久，超过了锁的过期时间，锁失效（锁被自动释放）
3. 客户端2加锁成功，开始操作共享资源
4. 客户端1操作共享资源完成，在finally块中手动释放锁，但此时它释放的是客户端2的锁。

这里存在两个严重的问题：

• 锁过期
• 释放了别人的锁

第1个问题是评估操作共享资源的时间不准确导致的，如果只是一味增大过期时间，只能缓解问题降低出现问题的概率，依旧无法彻底解决问题。原因在于客户端在拿到锁之后，在操作共享资源时，遇到的场景是很复杂的，既然是预估的时间，也只能是大致的计算，不可能覆盖所有导致耗时变长的场景。

第2个问题是释放了别人的锁，原因在于释放锁的操作是无脑操作，并没有检查这把锁的归属，这样解锁不严谨。如何解决呢？

锁被别人给释放了

解决办法是，客户端在加锁时，设置一个只有自己知道的唯一标识进去，例如可以是自己的线程ID，如果是redis实现，就是SET key unique_value EX 10 NX。之后在释放锁时，要先判断这把锁是否归自己持有，只有是自己的才能释放它。

//释放锁 比较unique_value是否相等，避免误释放
if redis.get("key") == unique_value then
    return redis.del("key")
123

这里释放锁使用的是GET + DEL两条命令，这时又会遇到原子性问题了。

1. 客户端1执行GET，判断锁是自己的
2. 客户端2执行了SET命令，强制获取到锁（虽然发生概念很低，但要严谨考虑锁的安全性）
3. 客户端1执行DEL，却释放了客户端2的锁

由此可见，以上GET + DEL两个命令还是必须原子的执行才行。怎样原子执行两条命令呢？答案是Lua脚本，可以把以上逻辑写成Lua脚本，让Redis执行。因为Redis处理每个请求是单线程执行的，在执行一个Lua脚本时其它请求必须等待，直到这个Lua脚本处理完成，这样一来GET+DEL之间就不会有其他命令执行了。

以下是使用Lua脚本（unlock.script）实现的释放锁操作的伪代码，其中，KEYS[1]表示lock_key，ARGV[1]是当前客户端的唯一标识，这两个值都是我们在执行 Lua脚本时作为参数传入的。

//Lua脚本语言，释放锁 比较unique_value是否相等，避免误释放
if redis.call("get",KEYS[1]) == ARGV[1] then
    return redis.call("del",KEYS[1])
else
    return 0
end
123456

最后我们执行以下命令，即可

redis-cli  --eval  unlock.script lock_key , unique_value 
1

这样一路优先下来，整个加锁、解锁流程就更严谨了，先小结一下，基于Redis实现的分布式锁，一个严谨的流程如下：

1. 加锁时要设置过期时间SET lock_key unique_value EX expire_time NX
2. 操作共享资源
3. 释放锁：Lua脚本，先GET判断锁是否归属自己，再DEL释放锁

有了这个严谨的锁模型，我们还需要重新思考之前的那个问题，锁的过期时间不好评估怎么办。

如何确定锁的过期时间

前面提到过，过期时间如果评估得不好，这个锁就会有提前过期的风险，一种妥协的解决方案是，尽量冗余过期时间，降低锁提前过期的概率，但这个方案并不能完美解决问题。是否可以设置这样的方案，加锁时，先设置一个预估的过期时间，然后开启一个守护线程，定时去检测这个锁的失效时间，如果锁快要过期了，操作共享资源还未完成，那么就自动对锁进行续期，重新设置过期时间。

这是一种比较好的方案，已经有一个库把这些工作都封装好了，它就是Redisson。Redisson是一个Java语言实现的Redis SDK客户端，在使用分布式锁时，它就采用了自动续期的方案来避免锁过期，这个守护线程我们一般叫它看门狗线程。这个SDK提供的API非常友好，它可以像操作本地锁一样操作分布式锁。客户端一旦加锁成功，就会启动一个watch dog看门狗线程，它是一个后台线程，会每隔一段时间（这段时间的长度与设置的锁的过期时间有关）检查一下，如果检查时客户端还持有锁key（也就是说还在操作共享资源），那么就会延长锁key的生存时间。

那如果客户端在加锁成功后就宕机了呢？宕机了那么看门狗任务就不存在了，也就无法为锁续期了，锁到期自动失效。

Redis的部署方式对锁的影响

上面讨论的情况，都是锁在单个Redis 实例中可能产生的问题，并没有涉及到Redis的部署架构细节。

Redis发展到现在，几种常见的部署架构有：

• 单机模式；
• 主从模式；
• 哨兵（sentinel）模式；
• 集群模式；

我们使用Redis时，一般会采用主从集群+哨兵的模式部署，哨兵的作用就是监测redis节点的运行状态。普通的主从模式，当master崩溃时，需要手动切换让slave成为master，使用主从+哨兵结合的好处在于，当master异常宕机时，哨兵可以实现故障自动切换，把slave提升为新的master，继续提供服务，以此保证可用性。那么当主从发生切换时，分布式锁依旧安全吗？

想像这样的场景：

1. 客户端1在master上执行SET命令，加锁成功
2. 此时，master异常宕机，SET命令还未同步到slave上（主从复制是异步的）
3. 哨兵将slave提升为新的master，但这个锁在新的master上丢失了，导致客户端2来加锁成功了，两个客户端共同操作共享资源

可见，当引入Redis副本后，分布式锁还是可能受到影响。即使Redis通过sentinel保证高可用，如果这个master节点由于某些原因发生了主从切换，那么就会出现锁丢失的情况。

集群模式+Redlock实现高可靠的分布式锁

为了避免Redis实例故障而导致的锁无法工作的问题，8edlock算法的基本思路，是让客户端和多个独立的Redis实例依次请求加锁，如果客户端能够和半数以上的实例成功地完成加锁操作，那么我们就认为，客户端成功地获得分布式锁了，否则加锁失败。这样一来，即使有单个Redis实例发生故障，因为锁变量在其它实例上也有保存，所以，客户端仍然可以正常地进行锁操作，锁变量并不会丢失。

来具体看下Redlock算法的执行步骤。Redlock算法的实现要求Redis采用集群部署模式，无哨兵节点，需要有N个独立的Redis实例（官方推荐至少5个实例）。接下来，我们可以分成3步来完成加锁操作。

第一步是，客户端获取当前时间。
第二步是，客户端按顺序依次向N个Redis实例执行加锁操作。

这里的加锁操作和在单实例上执行的加锁操作一样，使用SET命令，带上NX、EX/PX选项，以及带上客户端的唯一标识。当然，如果某个Redis实例发生故障了，为了保证在这种情况下，Redlock算法能够继续运行，我们需要给加锁操作设置一个超时时间。如果客户端在和一个Redis实例请求加锁时，一直到超时都没有成功，那么此时，客户端会和下一个Redis实例继续请求加锁。加锁操作的超时时间需要远远地小于锁的有效时间，一般也就是设置为几十毫秒。

第三步是，一旦客户端完成了和所有Redis实例的加锁操作，客户端就要计算整个加锁过程的总耗时。

客户端只有在满足两个条件时，才能认为是加锁成功，条件一是客户端从超过半数（大于等于 N/2+1）的Redis实例上成功获取到了锁；条件二是客户端获取锁的总耗时没有超过锁的有效时间。

为什么大多数实例加锁成功才能算成功呢？多个Redis实例一起来用，其实就组成了一个分布式系统。在分布式系统中总会出现异常节点，所以在谈论分布式系统时，需要考虑异常节点达到多少个，也依旧不影响整个系统的正确运行。这是一个分布式系统的容错问题，这个问题的结论是：如果只存在故障节点，只要大多数节点正常，那么整个系统依旧可以提供正确服务。

在满足了这两个条件后，我们需要重新计算这把锁的有效时间，计算的结果是锁的最初有效时间减去客户端为获取锁的总耗时。如果锁的有效时间已经来不及完成共享数据的操作了，我们可以释放锁，以免出现还没完成共享资源操作，锁就过期了的情况。

当然，如果客户端在和所有实例执行完加锁操作后，没能同时满足这两个条件，那么，客户端就要向所有Redis节点发起释放锁的操作。为什么释放锁，要操作所有的节点呢，不能只操作那些加锁成功的节点吗？因为在某一个Redis节点加锁时，可能因为网络原因导致加锁失败，例如一个客户端在一个Redis实例上加锁成功，但在读取响应结果时由于网络问题导致读取失败，那这把锁其实已经在Redis上加锁成功了。所以释放锁时，不管之前有没有加锁成功，需要释放所有节点上的锁以保证清理节点上的残留的锁。

在Redlock算法中，释放锁的操作和在单实例上释放锁的操作一样，只要执行释放锁的 Lua脚本就可以了。这样一来，只要N个Redis实例中的半数以上实例能正常工作，就能保证分布式锁的正常工作了。所以，在实际的业务应用中，如果你想要提升分布式锁的可靠性，就可以通过Redlock算法来实现。

常见分布式锁方案对比

分类	方案	实现原理	优点	缺点
基于数据库	基于mysql 表唯一索引	1.表增加唯一索引 2.加锁：执行insert语句，若报错，则表明加锁失败 3.解锁：执行delete语句	完全利用DB现有能力，实现简单	1.锁无超时自动失效机制，有死锁风险 2.不支持锁重入，不支持阻塞等待 3.操作数据库开销大，性能不高
	基于MongoDB findAndModify原子操作	1.加锁：执行findAndModify原子命令查找document，若不存在则新增 2.解锁：删除document	实现也很容易，较基于MySQL唯一索引的方案，性能要好很多	1.大部分公司数据库用MySQL，可能缺乏相应的MongoDB运维、开发人员 2.锁无超时自动失效机制
基于分布式协调系统	基于ZooKeeper	1.加锁：在/lock目录下创建临时有序节点，判断创建的节点序号是否最小。若是，则表示获取到锁；否，则则watch /lock目录下序号比自身小的前一个节点 2.解锁：删除节点	1.由zk保障系统高可用 2.Curator框架已原生支持系列分布式锁命令，使用简单	需单独维护一套zk集群，维保成本高
基于缓存	基于redis命令	1. 加锁：执行setnx，若成功再执行expire添加过期时间 2. 解锁：执行delete命令	实现简单，相比数据库和分布式系统的实现，该方案最轻，性能最好	1.setnx和expire分2步执行，非原子操作；若setnx执行成功，但expire执行失败，就可能出现死锁 2.delete命令存在误删除非当前线程持有的锁的可能 3.不支持阻塞等待、不可重入
	基于redis Lua脚本能力	1. 加锁：执行SET lock_name random_value EX seconds NX 命令 2. 解锁：执行Lua脚本，释放锁时验证random_value – ARGV[1]为random_value, KEYS[1]为lock_nameif redis.call(“get”, KEYS[1]) == ARGV[1] then return redis.call(“del”,KEYS[1])else return 0end	同上；实现逻辑上也更严谨，除了单点问题，生产环境采用用这种方案，问题也不大。	不支持锁重入，不支持阻塞等待

MVCC

什么是MVCC

全称Multi-Version Concurrency Control，即多版本并发控制，主要是为了提高数据库的并发性能。以下文章都是围绕InnoDB引擎来讲，因为myIsam不支持事务。

同一行数据平时发生读写请求时，会上锁阻塞住。但mvcc用更好的方式去处理读—写请求，做到在发生读—写请求冲突时不用加锁。

这个读是指的快照读，而不是当前读，当前读是一种加锁操作，是悲观锁。

什么是MySQL InnoDB下的当前读和快照读？

当前读

它读取的数据库记录，都是当前最新的版本，会对当前读取的数据进行加锁，防止其他事务修改数据。是悲观锁的一种操作。

如下操作都是当前读：

• select lock in share mode (共享锁)
• select for update (排他锁)
• update (排他锁)
• insert (排他锁)
• delete (排他锁)
• 串行化事务隔离级别

快照读

快照读的实现是基于多版本并发控制，即MVCC，既然是多版本，那么快照读读到的数据不一定是当前最新的数据，有可能是之前历史版本的数据。

如下操作是快照读：

• 不加锁的select操作（注：事务级别不是串行化）

快照读与mvcc的关系

MVCCC是“维持一个数据的多个版本，使读写操作没有冲突”的一个抽象概念。

这个概念需要具体功能去实现，这个具体实现就是快照读。（具体实现下面讲）

数据库并发场景

• 读-读：不存在任何问题，也不需要并发控制
• 读-写：有线程安全问题，可能会造成事务隔离性问题，可能遇到脏读，幻读，不可重复读
• 写-写：有线程安全问题，可能会存在更新丢失问题，比如第一类更新丢失，第二类更新丢失

MVCC解决并发哪些问题？

mvcc用来解决读—写冲突的无锁并发控制，就是为事务分配单向增长的时间戳。为每个数据修改保存一个版本，版本与事务时间戳相关联。

读操作只读取该事务开始前的数据库快照。

解决问题如下：

• 并发读-写时：可以做到读操作不阻塞写操作，同时写操作也不会阻塞读操作。
• 解决脏读、幻读、不可重复读等事务隔离问题，但不能解决上面的写-写 更新丢失问题。

因此有了下面提高并发性能的组合拳：

• MVCC + 悲观锁：MVCC解决读写冲突，悲观锁解决写写冲突
• MVCC + 乐观锁：MVCC解决读写冲突，乐观锁解决写写冲突

MVCC的实现原理

它的实现原理主要是版本链，undo日志 ，Read View来实现的

版本链

我们数据库中的每行数据，除了我们肉眼看见的数据，还有几个隐藏字段，得开天眼才能看到。分别是db_trx_id、db_roll_pointer、db_row_id。

• db_trx_id

  6byte，最近修改(修改/插入)事务ID：记录创建这条记录/最后一次修改该记录的事务ID。

• db_roll_pointer（版本链关键）

  7byte，回滚指针，指向这条记录的上一个版本（存储于rollback segment里）

• db_row_id

  6byte，隐含的自增ID（隐藏主键），如果数据表没有主键，InnoDB会自动以db_row_id产生一个聚簇索引。

• 实际还有一个删除flag隐藏字段, 记录被更新或删除并不代表真的删除，而是删除flag变了

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-O7W4EToU-1650292945646)(https://img.php.cn/upload/article/000/000/052/7d239fc720ed0f548d4d994272398847-2.png)]

如上图，db_row_id是数据库默认为该行记录生成的唯一隐式主键，db_trx_id是当前操作该记录的事务ID，而db_roll_pointer是一个回滚指针，用于配合undo日志，指向上一个旧版本。

每次对数据库记录进行改动，都会记录一条undo日志，每条undo日志也都有一个roll_pointer属性（INSERT操作对应的undo日志没有该属性，因为该记录并没有更早的版本），可以将这些undo日志都连起来，串成一个链表，所以现在的情况就像下图一样：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-iw8dWn3q-1650292945647)(https://img.php.cn/upload/article/000/000/052/7d239fc720ed0f548d4d994272398847-3.png)]

对该记录每次更新后，都会将旧值放到一条undo日志中，就算是该记录的一个旧版本，随着更新次数的增多，所有的版本都会被roll_pointer属性连接成一个链表，我们把这个链表称之为版本链，版本链的头节点就是当前记录最新的值。另外，每个版本中还包含生成该版本时对应的事务id，这个信息很重要，在根据ReadView判断版本可见性的时候会用到。

undo日志

Undo log 主要用于记录数据被修改之前的日志，在表信息修改之前先会把数据拷贝到undo log里。

当事务进行回滚时可以通过undo log 里的日志进行数据还原。

Undo log 的用途

• 保证事务进行rollback时的原子性和一致性，当事务进行回滚的时候可以用undo log的数据进行恢复。
• 用于MVCC快照读的数据，在MVCC多版本控制中，通过读取undo log的历史版本数据可以实现不同事务版本号都拥有自己独立的快照数据版本。

undo log主要分为两种：

• insert undo log

  代表事务在insert新记录时产生的undo log , 只在事务回滚时需要，并且在事务提交后可以被立即丢弃

• update undo log（主要）

  事务在进行update或delete时产生的undo log ; 不仅在事务回滚时需要，在快照读时也需要；

  所以不能随便删除，只有在快速读或事务回滚不涉及该日志时，对应的日志才会被purge线程统一清除

Read View(读视图)

事务进行快照读操作的时候生产的读视图(Read View)，在该事务执行的快照读的那一刻，会生成数据库系统当前的一个快照。

记录并维护系统当前活跃事务的ID(没有commit，当每个事务开启时，都会被分配一个ID, 这个ID是递增的，所以越新的事务，ID值越大)，是系统中当前不应该被本事务看到的其他事务id列表。

Read View主要是用来做可见性判断的, 即当我们某个事务执行快照读的时候，对该记录创建一个Read View读视图，把它比作条件用来判断当前事务能够看到哪个版本的数据，既可能是当前最新的数据，也有可能是该行记录的undo log里面的某个版本的数据。

Read View几个属性

• trx_ids: 当前系统活跃(未提交)事务版本号集合。
• low_limit_id: 创建当前read view 时“当前系统最大事务版本号+1”。
• up_limit_id: 创建当前read view 时“系统正处于活跃事务最小版本号”
• creator_trx_id: 创建当前read view的事务版本号；

Read View可见性判断条件

• db_trx_id < up_limit_id || db_trx_id == creator_trx_id（显示）

  如果数据事务ID小于read view中的最小活跃事务ID，则可以肯定该数据是在当前事务启之前就已经存在了的,所以可以显示。

  或者数据的事务ID等于creator_trx_id ，那么说明这个数据就是当前事务自己生成的，自己生成的数据自己当然能看见，所以这种情况下此数据也是可以显示的。

• db_trx_id >= low_limit_id（不显示）

  如果数据事务ID大于read view 中的当前系统的最大事务ID，则说明该数据是在当前read view 创建之后才产生的，所以数据不显示。如果小于则进入下一个判断

• db_trx_id是否在活跃事务（trx_ids）中

  • 不存在：则说明read view产生的时候事务已经commit了，这种情况数据则可以显示。
  • 已存在：则代表我Read View生成时刻，你这个事务还在活跃，还没有Commit，你修改的数据，我当前事务也是看不见的。

MVCC和事务隔离级别

上面所讲的Read View用于支持RC（Read Committed，读提交）和RR（Repeatable Read，可重复读）隔离级别的实现。

RR、RC生成时机

• RC隔离级别下，是每个快照读都会生成并获取最新的Read View；
• 而在RR隔离级别下，则是同一个事务中的第一个快照读才会创建Read View, 之后的快照读获取的都是同一个Read View，之后的查询就不会重复生成了，所以一个事务的查询结果每次都是一样的。

解决幻读问题

• 快照读：通过MVCC来进行控制的，不用加锁。按照MVCC中规定的“语法”进行增删改查等操作，以避免幻读。
• 当前读：通过next-key锁（行锁+gap锁）来解决问题的。

RC、RR级别下的InnoDB快照读区别

• 在RR级别下的某个事务的对某条记录的第一次快照读会创建一个快照及Read View， 将当前系统活跃的其他事务记录起来，此后在调用快照读的时候，还是使用的是同一个Read View，所以只要当前事务在其他事务提交更新之前使用过快照读，那么之后的快照读使用的都是同一个Read View，所以对之后的修改不可见；
• 即RR级别下，快照读生成Read View时，Read View会记录此时所有其他活动事务的快照，这些事务的修改对于当前事务都是不可见的。而早于Read View创建的事务所做的修改均是可见
• 而在RC级别下的，事务中，每次快照读都会新生成一个快照和Read View, 这就是我们在RC级别下的事务中可以看到别的事务提交的更新的原因

总结

从以上的描述中我们可以看出来，所谓的MVCC指的就是在使用READ COMMITTD、REPEATABLE READ这两种隔离级别的事务在执行普通的SEELCT操作时访问记录的版本链的过程，这样子可以使不同事务的读-写、写-读操作并发执行，从而提升系统性能。

Innodb的几种日志Redo log, bin log, Undo log

InnoDB中通过undo log实现了数据的多版本，而并发控制通过锁来实现。

undo log除了实现MVCC外，还用于事务的回滚。MySQL Innodb中存在多种日志，除了错误日志、查询日志外，还有很多和数据持久性、一致性有关的日志。

binlog，是mysql服务层产生的日志，常用来进行数据恢复、数据库复制，常见的mysql主从架构，就是采用slave同步master的binlog实现的, 另外通过解析binlog能够实现mysql到其他数据源（如ElasticSearch)的数据复制。

redo log记录了数据操作在物理层面的修改，mysql中使用了大量缓存，缓存存在于内存中，修改操作时会直接修改内存，而不是立刻修改磁盘，当内存和磁盘的数据不一致时，称内存中的数据为脏页(dirty page)。为了保证数据的安全性，事务进行中时会不断的产生redo log，在事务提交时进行一次flush操作，保存到磁盘中, redo log是按照顺序写入的，磁盘的顺序读写的速度远大于随机读写。当数据库或主机失效重启时，会根据redo log进行数据的恢复，如果redo log中有事务提交，则进行事务提交修改数据。这样实现了事务的原子性、一致性和持久性。

undo log: 除了记录redo log外，当进行数据修改时还会记录undo log，undo log用于数据的撤回操作，它记录了修改的反向操作，比如，插入对应删除，修改对应修改为原来的数据，通过undo log可以实现事务回滚，并且可以根据undo log回溯到某个特定的版本的数据，实现MVCC。

AQS

对比内存和硬盘的速度，

要分为两种请款对比：

• 顺序访问：这种情况下，内存访问速度仅仅是硬盘访问速度的6~7倍（358.2M / 53.2M = 6.7）
• 随机访问：这种情况下，内存访问速度就要比硬盘访问速度快上10万倍以上 （36.7M / 316 = 113,924）

java多线程的实现方式有4种

继承Thread类，重写run方法；

public class Main {
    public static void main(String[] args){
            MyThread th1 = new MyThread();
            th1.start();
        }
}

class MyThread extends Thread{
    @Override
    public void run() {
        System.out.println(Thread.currentThread().getName()+"方式一");
    }
}

实现Runnable接口，重写run方法；

public class Main {
    public static void main(String[] args) {
            Thread th = new Thread(new MyThread());
        	th.start();
        }
}

class MyThread implements Runnable{
    @Override
    public void run() {
        System.out.println(Thread.currentThread().getName()+"方式一");
    }
}

实现Callable接口通过FutureTask包装器来创建Thread线程；

public class Main {
    public static void main(String[] args) {
        MyCall th  =new MyCall();
        //通过FutureTask包装器来创建Thread线程
        FutureTask<Integer> futureTask = new FutureTask<Integer>(th);
        System.out.println("action ...");
        Thread thread = new Thread(futureTask);
        thread.start();
        System.out.println("end...");
        //如果有异常 也将在futureTask.get()中获取
        System.out.println(futureTask.get());
        }
}

class MyCall implements Callable<Integer>{

    @Override
    public Integer call() throws Exception {
        System.out.println(Thread.currentThread().getName()+"call");
        return 1/0;
    }
}

通过线程池创建线程；

public class Main {
    public static void main(String[] args) {
       //Executors是一个线程池工厂，提供了很多的工厂方法 通过Executors创建线程池
       ExecutorService executorService = Executors.newFixedThreadPool(3);
        for (int i = 0; i < 10; i++) {
            //通过submit方法来提交任务
            executorService.submit(() -> {
                System.out.println(Thread.currentThread().getName());
                try {
                    Thread.sleep(1000L);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
            });
        }
        //关闭线程池
        executorService.shutdown();
    }
}

public static void main(String[] args) {
        Thread th = new Thread(new MyThread());
    	th.start();
    }

}

class MyThread implements Runnable{
@Override
public void run() {
System.out.println(Thread.currentThread().getName()+“方式一”);
}
}

### 实现Callable接口通过FutureTask包装器来创建Thread线程；

```java
public class Main {
    public static void main(String[] args) {
        MyCall th  =new MyCall();
        //通过FutureTask包装器来创建Thread线程
        FutureTask<Integer> futureTask = new FutureTask<Integer>(th);
        System.out.println("action ...");
        Thread thread = new Thread(futureTask);
        thread.start();
        System.out.println("end...");
        //如果有异常 也将在futureTask.get()中获取
        System.out.println(futureTask.get());
        }
}

class MyCall implements Callable<Integer>{

    @Override
    public Integer call() throws Exception {
        System.out.println(Thread.currentThread().getName()+"call");
        return 1/0;
    }
}

通过线程池创建线程；

public class Main {
    public static void main(String[] args) {
       //Executors是一个线程池工厂，提供了很多的工厂方法 通过Executors创建线程池
       ExecutorService executorService = Executors.newFixedThreadPool(3);
        for (int i = 0; i < 10; i++) {
            //通过submit方法来提交任务
            executorService.submit(() -> {
                System.out.println(Thread.currentThread().getName());
                try {
                    Thread.sleep(1000L);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
            });
        }
        //关闭线程池
        executorService.shutdown();
    }
}