面试题总结-2024

面试技巧

• 面试前

  • 最好去查下公司相关产品业务、如果有app或者网站，提前去熟悉
  • 巩固面试岗位所需要的技术栈，有自己擅长的某一个领域 比如某个中间件或者框架

• 面试中

  • 要有礼貌，保持头脑清晰，思维清晰
  • 要有自信，不能自卑或者没信心
  • 专业技术一定要准备好，尽量往自己熟悉的方向考虑
  • 做过项目一定要熟悉，准备好项目的亮点和难点
  • 表现出有学习热情，掌握主流技术栈，关注前言技术

• 面试后

  • 一定要做复盘
  • 面试多了，问题都类似，一定去补上，下次也可能遇到
  • 可以问问面试官有没回答不好的点

1.2 非技术面试问题回答注意点

• 做下简单的自我介绍？

  • 基本信息、工作经历等，2-3分钟即可

• 为什么从上个公司离职？

  • 不能说不好的，比如公司混乱、勾心斗角、负面情绪
  • 推荐说公司搬迁比较远，然后刚好个人职业规划对某某领域比较喜欢

• 你对加班的是怎么看的？

  • 业务发展好、公司快速发展，项目紧急等加班非常乐意

  • 自己也会合理评估工作，提高个人工作效率

• 有没女朋友，家住在哪里?

  • 考查是否上班太远了，浪费时间，且容易换工作

• 你对自己未来职业规划是怎样的？

  • 往专业上靠拢，比如几年发展成技术负责人，带团队，多少年称为架构师, 比较喜欢看技术书籍提升能力

• 你认为自己有什么缺点？

  • 不能说没有缺点
  • 避免说影响工作、让人觉得不靠谱
  • 可以说些表面上看是缺点，从工作的角度看却是优点的缺点：对事情追求比较高，比如代码洁癖爱好者，对自己做的产品比较有要求，但也会适当控制

• 平时有什么爱好或者兴趣？

  • 不能说抽烟喝酒啥的
  • 建议是积极向上的活动

• 你期望的薪资是多少?

  • 薪酬最好写个范围，也看公司具体有哪些福利，比如餐补、交通、住房补助等，是否有13薪或者其他福利

• 你还有其他问题想问的吗？

  • 公司是否有员工培训、晋升机制等
  • 自己面试是否有不足，自己好改进
  • 什么时候会有面试结果，能不能加个联系方式

一、 java基础

怎么理解面向对象？简单说说封装继承多态

• 面向过程强调以过程为核心，关注问题解决的步骤和流程，将问题分解为一系列的步骤，通过函数实现这些步骤并依次调用。

  • 简单来说面向过程就是把解决问题的过程拆解成一个个方法，通过一个个方法的执行解决问题。

• 面向对象强调以对象为核心，通过对象来模拟现实世界中实体和它们之间的关系。面向对象的设计关注的问题本质和对象之间的交互。

  • 简单来说面向对象会把解决问题的过程抽象为对象，然后通过对象执行方法的方式解决问题。

• java面向对象的三大特性包含：封装、继承、多态：

  • 封装就是将类的某些信息隐藏在类的内部，不允许外部程序直接访问，而是提供Getter、Setter来实现对隐藏信息的操作和访问。封装可以提高Java代码的安全性。
  • 继承是指子类可以复用或扩展父类属性和方法。以此提高我们程序代码的复用性和扩展性，能够大大的提高开发效率。
  • 多态是指允许一个对象在不同的情况下表现出不同的行为。多态可以分为编译时多态（重载）和运行时多态（重写）。它使得程序具有良好的灵活性和扩展性。

JAVA中的八大数据类型

• JAVA支持数据类型分为两类：基本数据类型和引用数据类型
• 基本数据类型有八种。可以分为三类：
• 数值型：整数类型（byte、short、int、long）和浮点类型（float、double）
• 字符型：char
• 布尔型：boolean

值传递和引用传递?

• 在Java中所有的参数传递，不管基本类型还是引用类型，都是值传递。
• 基本类型数据进行操作时，传递的是基本数据类型的值的副本
• 引用类型数据进行操作时，传递的是对象的地址值

== 与 equals 有什么区别？

• 对于字符串变量来说，==比较两个变量本身的值，即两个变量在内存中的地址值，equals比较字符串内容是否相同
• 对于非字符串变量来说，如果没有对equals进行重写的话，==和equals方法的作用是相同的，都是用来比较对象在堆内存中的地址值，即用来比较两个引用变量是否指向同一个对象。

Integer a = 100;Integer b = 100; a==b 输出为？Integer a = 200;Integer b = 200; a==b 输出为？为什么？

xxxxxxxxxx
Integer a = 100;
Integer b = 100;
System.out.println(a == b);  // true

Integer c = 200;
Integer d = 200;
System.out.println(c == d);  // false 因为不在静态缓存池范围内，所以会重新new一个字符串对象实例。因此结果为false
// 为什么c == d 输出结果为false?

/**
  *   java 的Integer类内部实现了一个静态缓存池，用于存储特定范围内的整数值对应的Integer对象
  *   默认情况下，这个范围是-127至128。当通过Integer.valueOf(int)方法创建一个在这个范围内的整数对象时，
  *       并不会每次都生成新的对象实例，而是复用缓存池中的现有对象，会直接从内存中取
**/

String、StringBuffer和StringBuild区别是什么？

• String是java中基础且重要的类，被声明为final class，是不可变字符串。因为它的不可变性，所以拼接字符串时候会产生很多无用的中间对象，频繁进行拼接对性能会影响性能。
• StringBuffer是为了解决大量拼接字符串时产生很多中间对象问题而提供的一个类。它提供了append和add方法，可以将字符串添加到已有序列的末尾或指定位置，本质上是一个线程安全的可修改的字符序列。但由于保证线程安全的同时加了锁所以效率较低。
• StringBuilder是jdk1.5发布的，它线程不安全，去掉了保证线程安全的那部分减少了开销，所以效率比StringBuffer高

重载和重写有什么区别?

• 重载指的是同一个类，可以有多个同名的方法，它们具有不同的参数列表，编译器根据调用时的参数类型决定调用哪个方法。
• 重写是指子类可以重新定义父类的方法，方法名、参数列表和返回类型必须与父类中的方法一致，通过@override注解来表示对父类方法的重写。

什么是反射机制？什么是泛型？

• 反射的本质Java程序在运行期间通过class对象，反向获取类对象的各种信息的一个过程

• java获取类的3种方式：1、Class.forName("类名") 2、类名.class。3、对象.getClass()

• 反射具有以下特性：

  • 运行时类信息访问：反射机制运行程序在运行时获取类的完整结构信息，包括类名、包名、父类、实现类的接口、构造函数、方法和字段等
  • 动态对象创建：可以使用反射API动态创建对象实例，即使在编译时不知道具体的类名。通过Class类的newInstance()方法或者构造器对象的newInstance()方法实现
  • 动态方法调用：可以在运行时动态调用对象的方法，包括私有方法。通过Method类的invoke()方法实现，允许你传入对象实例和参数值来执行方法。
  • 访问和修改字段值：反射还允许程序在运行时访问和修改对象的字段值，即使是私有的。这是通过Field类的get和set方法完成的。

• 泛型是为了将类型参数化，在编译时保证数据类型的一致性。

Spring创建的对象和自己手动new出来的对象有什么区别？

• 手动new创建对象是在编译时加载Class文件，通过构造函数创建对象的过程
• Spring创建对象底层依赖于IOC容器，是通过反射创建对象实例，在运行时加载Class文件，通过构造函数创建对象的过程

接口和抽象类的区别是什么?

• 接口用于定义行为规范，可以有常量和抽象方法，不能有方法的实现（Java8以后可以有默认方法和静态方法）；抽象类用于描述类的共同属性和行为，可以有成员变量、构造方法和具体方法；
• 实现接口的关键字是implements，一个类可以实现多个接口，使用接口可以实现多重继承；继承抽象类的关键字为extends，一个类只能继承一个抽象类；
• 接口成员变量默认为public static final，必须赋初值，接口中所有的方法public abstract的；抽象类中成员变量默认为default，可以在子类中重新定义，抽象类中抽象方法被abstract修饰，不能有具体的代码实现，不能被private、static、synchronized和native等修饰

BIO、NIO、AIO

• BIO模型也称（blocking-io）同步阻塞IO模型。Acceptor监听到客户端的连接后会为每一个客户端创建一个新的线程进行处理，因此每个请求都需要有一个线程来处理，属于一种典型的一请求一应答模型，服务端的线程个数和客户端并发访问数呈1:1的正比关系，当并发量很大的时候会造成线程数过多导致系统宕机。

• NIO模型也称（no blocking-io）同步非阻塞IO模型，是jdk1.4引入的包。基于Reactor模型来实现的，NIO通过使用单线程轮询多个连接的的方式来实现高效的处理方式。通过Selector（I/O多路复用）轮询大量的Channel，每次都会获取一批有事件的Channel，然后对每个请求启动一个线程处理即可。这种方式是非阻塞的，Selector一个线程就可以不停轮询channel，所有客户端请求都不会阻塞。

• AIO（Asynchronous IO）也叫异步非阻塞IO模型。AIO是基于事件和回调机制实现的，也就是应用操作之后会直接返回，不会阻塞在那，当后台处理完成后操作系统会通知相应的线程进行后续操作。

• 设想你要烧水这样一个场景：

  • BIO：在烧水期间，你一直守在旁边，不敢任何事，等到水烧开了才去完成其他事
  • NIO：在烧水期间，你不必一直守在旁边，而是时不时来看水是否烧开，其他时间可以去完成其他事
  • AIO：在烧水期间，你无需来看水是否烧开了，可以去完成其他任务，水烧开的时候会发出提示音提示你水开了，这时候你再来处理。

JAVA8有哪些新特性？

• Lambda 表达式使代码变得更加简洁
• java8中引入了StreamAPI，提供了一种高效且易于使用的数据处理方式，特别适合集合对象的操作。如过滤、映射、排序等。StreamAPI不仅可以提高代码的可读性和简洁性，还能利用多核处理器的优势进行并行处理
• 并行API就是将源数据分为多个子流对象进行多线程操作，然后将处理的结果再汇总为一个流对象，底层是使用通过的fork/join池来实现，即将一个任务拆分成为多个小任务并行计算，再把多个小任务的结果合并汇总。对于CPU密集型的任务来说，并行流使用ForkJoinPool线程池，为每个CPU分配一个任务，这是非常有效率的。
• Java8中引入了CompletableFuture。对Future进行了扩展，可以通过设置回调的方式处理计算结果，同时也支持组合操作，支持进一步的编排，一定程度上解决了回调地狱的问题。

二、java集合

说说java中的集合？Java中线程安全的集合有哪些？

• 
• List是有序的Collection，常用的实现List的类有LinkedList、ArrayList、Vector、Stack
• Set是不允许重复的Collection，常用的实现有HashSet、LinkedHashSet（插入前有序）和TreeSet（插入后有序）
• Map是键值对集合，key无序唯一；value不要求有序，允许重复，常用的实现有TreeMap、HashMap、LinkedHashMap、ConcurrentHashMap;
• Java中线程安全的集合主要有Vector和Hashtable，其他都是线程不安全的

ArrayList线程安全吗？ArrayList变成线程安全的方法有哪些？CopyOnWriteArrayList是如何实现线程安全的？

• ArrayList线程不安全。可以使用CopyOnWriteArrayList代替ArrayList。CopyOnWriteArrayList底层是一个数组，使用volatile关键字修饰的数组，保证当前线程对数组对象重新赋值后，其他线程可以及时感知到。在写入操作时，加了一把互斥锁ReetrantLock来保证线程安全
• 也可以使用Collections.synchronizedList(arrayList);将ArrayList包装成线程安全的List

HashMap实现原理介绍一下？HashMap的put流程介绍一下？

• 在JDK1.7之前，HashMap的数据结构是数组+链表，在JDK1.8之后使用的是数组+链表+红黑树。

• HashMap的put流程：

  • 当我们在put一个元素，先会对这个Key的hashcode值重新进行一次hash的操作，然后将重新进行hash的值与数组长度-1进行&运算，计算出元素应该放在数组的哪个位置。如果数组中没有元素则直接插入，反之则判断key是否相同，key相同就覆盖，否则插入到链表的尾部。如果链表的长度超过8 && 数组长度大于等于64则转换为红黑树，若数组⻓度超过默认的⻓度*负载因⼦也就是12则进⾏两倍的扩容。
  • HashMap是线程不安全的，我们可以使用Hashtable，但Hashtable使用了synchronized加锁操作保证线程安全，效率较低。我们多线程环境下可以使用Collections.synchronizedMap同步加锁的方式保证线程安全，还可以使用ConurrentHashMap

ConcurrentHashMap怎么实现的？

• 在jdk1.5时ConcurrentHashMap使⽤Segment分段锁技术将数据分为一段一段的存储，并且每段数据都配一把锁。当一个线程占用一把锁时，其他Segment数据可以被其他线程访问到。
• 在JDK1.8则抛弃了Segment，改为使⽤CAS+synchronized来保证线程安全，synchronized只锁定当前链表或红黑二叉树的首节点，减⼩了锁的粒度。进一步提升了效率。

三、java多线程

用过Java多线程吗？在哪用的，怎么用的？

• 我们的项目在查询数据字典的时候，是分了四次查询，分别查询企业性质、公司优势、人员规模、福利待遇等，这四次查询本质上没有任何关联，也没有任何依赖关系，并且这四次查询是同步进行的，因此我们对这个接口进行优化，使用多线程将四次的同步查询操作异步化，以此提高效率。
• 我们基于ThreadPoolExecutor自定义线程池，使用Java8中提供给我们的新特性CompletableFuture来实现对多线程任何的异步编排以此来提高我们多个字典项查询的效率

线程创建的方式有哪些？

• 继承Thread类，重写run方法，通过调用start()方法启动线程
• 实现Runnable接口，重写run方法，将Runnable对象传递给Thread类的构造器，创建Thread对象后调用start()方法
• 实现Callable接口，有返回值并且可以抛异常。因为Thread类的构造器只接受Runnable参数，所以需要将任务包装成一个FutureTask，FutureTask实现了Runnable接口。
• 使用线程池（Executor框架），这是一种更高效的线程管理方式，避免了频繁创建和销毁线程的开销。可以通过Executors类的静态方法创建不同类型的线程池。

synchronized 工作原理？ syncronized锁升级的过程讲一下

• Synchronized是通过对象内部的⼀个监视器锁来实现的，这个监视器锁本质是依赖底层操作系统的互斥锁来实现的。
• 代码块的同步原理是利⽤monitorenter和monitorexit这两个字节码指令。分为位于同步代码块的开始位置和结束位置。当jvm执⾏到monitorenter指令时，当前线程试图获取monitor对象的所有权，如果未加锁或者已经被当前对象所持有，就把锁的计数器+1；当执⾏到monitorexit指令时，锁计数器-1；当锁的计数器为0时，该锁就被释放了，如果获取monitor失败，该线程就会进⼊阻塞状态，直到其他线程释放锁，由于操作系统实现线程的切换需要从⽤户态转换为内核态，这个过程的成本是⾮常⾼的。
• JDK1.6之后对Synchronized进⾏了优化，引⼊了偏向锁和轻量级锁，锁的状态变为四种：⽆锁、偏向锁、轻量级锁、重量级锁。级别由底到⾼，通常情况下，锁的状态只能升级，不能降级。
• 引⼊偏向锁的⽬的是为了减少在不存在多线程竞争的情况下的性能消耗
• 当我们的程序在访问同步代码块时，会先检查对象头中MarkWord的锁状态信息，如果是偏向锁，则检查当前线程ID是否等于MarkWord中的线程ID，如果不是同⼀个线程ID，则会申请锁升级为轻量级锁。当锁升级为轻量级锁时，当由多个线程同时竞争锁时，锁就会升级为重量级锁。

ReentrantLock 的工作原理？

• ReentrantLock是一个可重入锁，底层依赖CAS+AQS实现。

• CAS就是比较并交换的意思，它里面有三个参数，分别是内存值、预期值、要修改的值。只有当内存值和预期值相等的时候才进行修改。这个操作是依赖于CPU底层指令的原子性操作。

• AQS是一个构造锁和同步容器的框架。底层使用了一个先进先出的等待队列和一个volatile修饰的int类型的State变量

• 执行过程如下：

  • 当程序执行lock方法时，会先进行CAS操作，判断State状态值是否为0。
  • 若State为0代表当前锁未占用进行获取锁操作。若State不为0则判断是否被自己占用，若被自己占用则通过CAS更新State字段，表示重入的次数。若不是被自己占用，这时候会把当前线程放入AQS队列进行排队等待。

ReentrantLock和synchronized有什么区别？

• 来源不同。synchronized是Java语言内建的关键字，ReentrantLock是Java并发包下的一个类；
• 等待可中断。synchronized不可响应中断获取锁，一旦线程没有获取到锁则会进行阻塞状态进行等待，ReentrantLock能够响应中断获取锁；
• 锁释放不同。synchronized由JVM自动释放锁，ReentrantLock必须由手动unlock()进行解锁；
• 锁的申请不同。synchronized一旦获取不到锁会一直等待。而ReentrantLock提供tryLock()方法尝试获取锁，获取不到就返回false不会一直等待；
• 公平与非公平。synchronized是非公平的，不保证等待时间最长的线程先获得锁。而ReentrantLock可以在构造函数中指定是公平锁还是非公平锁；

介绍一下AQS的原理？

• AQS中文名叫抽象队列同步器，是Java中的一个抽象类。Java并发包中Semaphore、CountDownLatch、CyclicBarrier等的核心实现都是基于AQS实现。
• AQS底层使用一个volatile的int类型的成员变量来表示同步状态，通过内置的FIFO队列来完成资源获得的排队工作，通过CAS完成对state值的修改

ThreadLocal的原理?为什么会产生内存泄漏？

• 当我们使用ThreadLocal时，ThreadLocal会为访问这个变量的每个线程都创建一个变量的副本，实际在多线程操作时，操作的是自己线程中变量的副本，从而规避了线程安全问题
• ThreadLocal的实现底层依赖于Thread类中的一个ThreadLocalMap字段，这是一个存储ThreadLocal变量本身和对应值的映射，每个线程都有自己的ThreadLocalMap实例，当调用ThreadLocal的set方法时，ThreadLocal会将给定的值与当前线程关联起来，即在当前线程的ThreadLocalMap中存储一个键值对，键是ThreadLocal对象本身，值是传入的值
• 如果没有显示调用remove方法可能会导致内存泄露。因为ThreadLocalMap中的key是弱引用，value是强引用，当我们的线程不回收时，会持续持有ThreadLocal变量的引用，即使ThreadLocalMap中的key是弱引用可被回收，但value也会导致内存泄露。

介绍一下线程池的工作原理？有线程池参数设置的经验吗？

• 
• 线程池是为了减少频繁创建线程和销毁线程带来的性能损耗。核心参数有7个，分别是核心线程数、最大线程数、存活时间、存活时间单位、工作队列、线程工厂、拒绝策略
• 当我们提交一个任务时，如果当前运行的线程数小于核心线程数，新提交的任务会立即启动新的线程执行。如果当前运行线程大于或等于核心线程数就加入任务队列进行等待。如果任务队列满了并且当前运行的线程数小于最大线程数，会创建新的线程来处理任务，如果当前运行线程达到最大线程数量，就会按照拒绝策略进行处理
• 工作中一般看服务器CPU任务的类型，如果是CPU密集型任务，核心线程数设置为CPU核数+1；如果是IO密集型任务，核心线程数设置为CPU核数的2倍

四、java虚拟机

JDK、JRE、JVM的关系？

• JDK=JRE+开发工具集
• JRE=JVM+Java SE标准类库

JVM的内存模型介绍一下？

• 

• 

• 根据JVM8的规范，JVM运行时内存共分为java虚拟机栈、本地方法栈、方法区、堆、程序计数器五个部分

• java虚拟机栈是每个线程私有的，随着线程的创建而创建。栈里面存着一种叫栈帧的东西，每个方法都会创建一个栈帧，栈帧中存放了局部变量表、操作数栈、方法出入口等信息。

• 本地方法栈和Java虚拟机栈类似，区别是Java虚拟机栈执行Java方法，本地方法执行native方法。

• 方法区是线程共享的区域，JDK7之前也叫永久代，存储已经被虚拟机加载的类信息、常量、静态变量等数据。在JDK8之后叫元空间，元空间属于本地内存由操作系统直接管理。

• 堆内存是JVM所有线程共享的部分，所有的对象和数组都在堆上进行分配。堆是JVM内存占用最大，管理最复杂的一个区域。在JDK1.8后，字符串常量也存放在堆中。

  • 堆主要划分为新生代、老年代、元空间
  • 新生代又分为Eden区和两个大小相等的Survivor区。大多数新创建的对象首先存放在Eden区，当Eden区满时，会触发一次Minor GC（新生代垃圾回收），对象的存活年龄+1。在每次Minor GC后，存活下来的对象都会被移动到其中的一个Surivor空间，继续它们的生命周期。这两个区域轮流充当对象中的中转站，帮助区分短暂存活的对象和长期存活的对象
  • 当对象存活年龄等于15的时候，下一次Minor GC时将会进入老年代。老年代的对象生命周期比较长，在老年代主要发生Major GC，发生频率相对较低，而且执行时间通常比Minor GC长
  • 从Java8开始，永久代被元空间所取代。元空间并不在Java堆中，而是使用本地内存。这解决了永久代容易出来的内存溢出问题

• 程序计数器是当前线程所执行的字节码行号指示器，是线程私有的内存空间。

String s = new String（“abc”）执行过程中分别对应哪些内存区域？

• new指令是创建一个类的实例对象并完成加载初始化，new创建的字符串对象是在堆内存上。
• 此外，在String的构造方法中传递了一个字符串abc，由于这里的abc是被final修饰的属性，所以它是一个字符串常量。在首次构建这个字符串常量对象时，JVM拿字面量abc去字符串常量池试图获取其对应String对象的引用。于是在堆中创建了一个abc的String字符串常量，并将其保存到字符串常量池中。
• 所以，如果abc这个字符串常量不存在，则创建两个对象，分别是abc这个字符串常量，以及new String这个实例对象。如果abc这个字符串常量存在，则只会创建一个对象。

Java创建对象的过程？

• 

• 在Java中创建对象的过程包含：

  • 类加载检查。JVM遇到一条new指令时会去检查这个指令参数是否能在常量池中定位到一个类的符号引用 ，并且检查这个符号引用代表的类是否已被加载过、解析和初始化过。如果没有，那必须先执行相应的类加载过程
  • 分配内存。在类加载检查通过后，JVM将为新生对象分配内存。对象所需的内存大小在类加载完成后便可确定，为对象分配空间的任务等同于把一块确定大小的内存从Java堆中划分出来。
  • 初始化零值。内存分配完成后，虚拟机需要将分配到的内存空间都初始化为零值（不包括对象头），这一步操作保证了对象的实例字段在Java代码中可以不赋初始值就直接使用，程序能访问到这些字段的数据类型所对应的零值。
  • 进行必要设置，比如对象头。初始化零值后，JVM要对对象进行必要的设置，例如这个对象是哪个类的实例、如何才能找到类的元数据信息、对象的哈希码、对象的GC分代年龄等信息。这些信息存放在对象头中。另外，根据JVM当前运行状态的不同，如是否启用偏向锁等，对象头会有不同的设置方式。
  • 构造函数初始化。在上面工作都完成之后，从JVM层面来看一个新的对象已经产生了，但从Java程序层面来看，对象创建才刚开始---构造函数，即class文件中的方法还没有执行，所有的字段都还为零，对象需要的其他资源和状态信息还没有按照预定的意图构造好，所以一般来说，执行new指令之后会接着执行方法，把对象按照程序员的意图进行初始化，这样一个真正可用的对象才算完全被构造出来

讲一下类的加载过程？

• 

• 加载、链接（验证、准备、解析）、初始化

• 加载：

  1. 通过一个类的全限定名获取该类的二进制字节流；
  2. 将该二进制流中的静态存储结构转化为方法区运行时数据结构
  3. 在内存中生成该类的class对象，作为该类的数据访问入口

• 验证：验证的目的是确保class文件的字节流中的信息不会危害到虚拟机，主要完成四种验证

  1. 文件格式验证：验证字节流是否符合class文件的规范，如主次版本号是否在当前虚拟机范围内，常量池中的常量是否有不被支持的类型
  2. 元数据验证：对字节码描述的信息进行语义分析，如这个类是否有父类，是否继承了不被继承的类
  3. 字节码验证：对数据流和控制流进行分析，确定程序语义是否正确，主要针对方法体的验证。如方法中的类型转换是否正确，跳转指令是否正确等
  4. 符号引用验证：这个动作在解析过程中发生，主要确保解析动作是否能正确执行

• 准备：在方法区为类的静态变量分配内存并初始化，准备阶段不分配类中实例变量的内存，实例变量的内存会在对象实例化时随着对象一起分配在java堆中

• 解析：该阶段主要完成符号引用到直接引用的跳转动作，解析动作不一定在初始化完成之前，也可能在初始化完成之后

• 初始化：真正开始执行类中定义的java程序代码

什么是类加载器，类加载器有哪些？

• 通过类的全限定名获取该类的二进制流的代码块叫做类加载器

• 有四种加载器

  1. 启动类加载器（BootStrap ClassLoader）用来加载java核心类库，无法被java程序直接引用
  2. 扩展类加载器（extension ClassLoader）用来加载java的扩展库，java虚拟机的实现会提供一个扩展类目录，该类加载器会在此目录里面查找并加载java类
  3. 应用类加载器（App ClassLoader）根据java应用的类路径（classpath）来加载java类，一般来说java应用的类都是由它来进行加载的，可以通过ClassLoader.getSystemClassLoader()来获取它。
  4. 用户自定义加载器（Customer ClassLoader），通过继承java.lang.ClassLoader类的方式实现

什么是双亲委派模型？请简述一下加载过程。并说一下优点？

• 当一个类加载器收到类加载请求时，首先不会自己去尝试加载这个类，而是把这个请求委派给父类加载器去完成，每一层次的类加载器都是如此，因此所有的加载请求最终都应该传送到顶层的启动类加载器中
• 只有当父类加载器反馈自己无法完成这个加载请求时，子加载器才会尝试自己去加载
• 优点：保护java核心类。可以避免用户自己编写的类代替java的核心类，可以避免全限定命名的类重复加载

判断垃圾的方法有哪些？

• 判断对象是否为垃圾主要依据两种主流的垃圾回收算法来实现：引用计数法和可达性分析算法。
• 引用计数法为每个对象分配一个引用计数器，每当有一个地方引用它时，计数器加1；当引用失效时，计数器减1。当计数器为0时，表示对象不再被任何变量引用，可以被回收。缺点是不能解决循环引用问题，即两个对象相互引用，但不再被其他任何对象引用，这时引用计数器不会为0导致对象无法被回收。
• Java虚拟机主要采用可达性分析算法来判断对象是否为垃圾。可达性分析算法先人为的将一组对象设置为根节点，根据对象间的引用关系向下寻找其他的对象，如果一个对象到根节点没有任何引用链相连，即从GC Roots到这个对象不可达，那么这个对象就被认为是不可达的，可以被回收。
• GC Roots对象包括：虚拟机栈中引用的对象、方法区中类静态属性引用的对象、本地方法栈中Java本地接口引用的对象、活跃线程的引用等。

垃圾回收算法有哪些？标记清除算法的缺点是什么？

• 标记清除算法。标记清除算法先标记再清除，首先通过可达性分析，标记出所有需要回收的对象，然后统一清楚所有标记的对象。标记清除算法有两个缺陷。

  • 标记和清除的效率都不高，
  • 清除结束会造成大量的碎片空间

• 复制算法。复制算法将内存分为两块，每次申请内存时都使用其中的一块，当内存不够时，将这一块内存中所有存活的复制到另一块上，然后再把已使用的内存整个清理掉。复制算法解决了空间碎片问题，但是带来了新的问题。

  • 申请内存时都只能使用一半的内存空间。内存利用率严重不足。

• 标记压缩算法。标记压缩算法的标记过程与标记清除算法的标记过程一致，但标记之后不会直接清理。而是将所有存活对象移动到内存的一端。移动结束后直接清理掉剩余部分。

• 分代回收算法。分代收集是将内存划分成新生代和老年代。分配的依据是对象的生存周期，或者说经历过的GC次数。对象创建时，一般在新生代申请内存，当经历一次GC之后如果对象还存活，那么对象的年龄+1，当年龄超过一定值（默认是15）后，该对象会进入老年代。

垃圾回收器有哪些？G1垃圾回收器？CMS和G1的区别？

• 
• Serial收集器（复制算法)
• ParNew收集器 (复制算法)
• Parallel Scavenge收集器 (复制算法)
• Serial Old收集器 (标记-整理算法)
• Parallel Old收集器 (标记-整理算法)
• CMS(Concurrent Mark Sweep)收集器（标记-清除算法）
• G1(Garbage First)收集器 (标记-整理算法)：JAVA堆并行收集器，G1收集器是JDK1.7提供的一个新收集器，G1收集器基于标记整理算法实现，也就是说不会产生内存碎片。此外，G1收集器不同于之前的收集器的一个重要特点是G1收集器回收的范围是整个Java堆，包括新生代、老年代

MinorGC、MajorGC、FullGC的区别，什么场景触发FullGC?

• MinorGC（也称为Young GC）只针对年轻代进行回收，包括Eden区和两个Survivor区（S0和S1）。当Eden区空间不足时，JVM触发一次Minor GC，将Eden区和一个Survivor区中的存活对象移动到另一个Survivor区或老年代。通过Minor GC发生的非常频繁，因为年轻代中的对象生命周期较短，回收率高，暂停时间相对较短
• MajorGC（有时也称为Old GC）主要针对老年代进行回收，但不一定只回收老年代。当老年代空间不足时，或者系统检测到年轻代对象晋升到老年代的速度过快，可能会触发Major GC。相比Minor GC，Major GC发生的频率较低，但每次回收可能需要更长的时间，因为老年代中对象存活率较高
• FullGC是对整个堆内存（包含年轻代、老年代以及元空间）进行回收。我们可以直接调用System.gc()或者Runtime.getRuntime.gc()方法触发Full GC，如果Minor GC存活的对象无法全部放入老年代，或者老年代空间不足则会触发Full GC，对整个堆内存进行回收。Full GC需要Stop The World，遍历整个堆内存来查找回收不再使用的对象，是一次比较昂贵的操作。

五、Spring

说一下你对Spring的理解

• Spring框架核心特性包含IOC容器、AOP、事务管理、MVC框架
• SpringIOC通过控制反转实现了对象的创建和对象间的依赖关系管理。开发者只需要定义好Bean以及依赖关系，Spring容器负责创建和组装这些对象。
• 面向切面编程AOP允许开发者定义独立于业务逻辑的代码。通过AOP可以将这些关注点模块化，提高代码的可维护性和可重用性。
• Spring提供了一致的事务管理接口，支持声明式事务和编程式事务。开发者可以轻松进行事务管理，无需关心具体的事务API
• Spring MVC是一个基于Servlet API构建的Web框架，采用MVC架构，支持灵活的URL到页面控制器的映射，以及多种视图技术。

谈谈你对IOC和AOP的理解？他们的实现原理是什么？

• 
• 
• IOC即控制反转，是指将原本在程序中手动创建对象的过程交由Spring进行管理创建，不需要人工来管理对象之间复杂的依赖关系，相当于把控制权交给 了Spring，大大降低了耦合。
• AOP叫做面向切面编程，是一个编程规范，将那些与业务无关，却为业务模块所共同调用的逻辑封装起来，目的就是提高代码的模块性。Spring AOP基于动态代理的方式实现，如果代理的对象实现了某个接口的话就会使用JDK动态代理，反之则使用CGLIB代理

动态代理是什么？和静态代理有什么区别？

• 动态代理：通过提供一个代理类，让我们在调用目标方法的时候，不再直接对目标方法进行操作，而是通过代理类间接调用。让不属于目标方法核心逻辑的代码从目标方法中剥离出来，调用目标方法时先调用代理对象的方法，减少对目标方法的调用和打扰，AOP底层是动态代理，如果是接口采用JDK动态代理，如果是类采用CGLIB方式实现动态代理。

• 区别：

  • 静态代理由程序员或者特定的工具创建，在代码编译时就确定了被代理的类是一个静态代理，静态代理通常只代理一个类。
  • 动态代理是在代码运行期间，运用反射机制动态创建生成，动态代理代理的是一个接口下的多个实现类。

JDK动态代理和CGLIB代理有什么区别？

• 针对类实现了某个接口，AOP则会使用JDK动态代理。他是基于反射的机制实现，生成一个实现同样接口的一个代理类，然后通过重写方法的实现，实现对代码的增强。
• 但是一个类没有实现接口，AOP则会使用CGLIB代理，他的底层是基于ASM第三方框架，通过修改字节码生成一个子类，然后重写父类的方法，实现对代码的增强。

Spring如何解决循环依赖的问题?

• 首先，Spring解决循环依赖有两个前提条件：

  • 不全是构造器方式的循环依赖
  • 必须是单例

• 本质上解决循环依赖的问题就是三级缓存，通过三级缓存提前拿到未初始化完全的对象

• Spring中的缓存

  • 一级缓存：用来保存实例化、初始化都完成的对象
  • 二级缓存：用来保存实例化完成，但未初始化完成的对象
  • 三级缓存：用来保存一个对象工厂，提供一个匿名内部类，用于创建二级缓存中的对象

• 假设一个简单的循环依赖场景，A、B互相依赖。

  • 创建对象A，实例化的时候把A对象工厂放入三级缓存，A注入属性时，发现依赖B，转而去实例化B
  • 同样创建对象B，注入属性时发现依赖A，依次从一级缓存到三级缓存查询A，从三级缓存中通过对象工厂拿到A，把A放入二级缓存，同时删除三级缓存中的A，此时B已经实例化完成并且初始化完成，把B放入一级缓存。
  • 接着继续创建A，顺利从一级缓存中拿到实例化且初始化完成的B对象，A对象创建也完成，删除二级缓存中的A，同时把A放入一级缓存
  • 最后，一级缓存中保存着实例化、初始化都完成的A、B对象

• A类中有个B类的属性, B类中有个A类的属性,启动是否报错?

  • 不报错，Spring会解决循环依赖问题，解决过程如上

• A类的构造函数中new了个B类,B类的构造函数中new了个A类,启动是否报错?

  • 报错，如果两个都是用构造器来进行循环依赖的话，Spring无法将实例化和初始化的流程分离，所以无法解决循环依赖的问题

• 为什么要三级缓存？二级不行吗？

  • 不行，主要是为了生成代理对象
  • 因为三级缓冲中放的是生成具体对象的匿名内部类，他可以生成代理对象，也可以是普通的实例对象
  • 使用三级缓存的目的主要是为了保证不管什么时候使用的都是一个对象
  • 假设只有二级缓存的情况，往二级缓存中放的一个普通的Bean对象，Bean的后置处理器去生成代理对象之后，覆盖掉二级缓存中的普通的Bean对象，那么多线程的环境下可能获取到对象就不一致了。

SpringIOC容器的一级二级三级缓存的作用?

• 不支持循环依赖的情况下，只有一级缓存生效，二三级缓存用不到
• 二三级缓存就是为了解决循环依赖

Spring事务的实现原理?

• Spring本身不实现事务，Spring事务的本质还是底层数据库对事务的支持，没有数据库事务的支持，Spring事务就不会生效。
• Spring事务的本质是Spring AOP和数据库事务，Spring将数据库的事务操作提取为切面，通过AOP在方法执行前后增加数据库的事务操作；

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

• 工厂设计模式：Spring使用工厂模式通过BeanFactory、ApplicationContext创建Bean对象
• 代理设计模式：Spring AOP功能的实现
• 单例设计模式：Spring中Bean默认都是单例的
• 模版方法模式：Spring中jdbcTemplate、hibernateTemplate等以Template结尾的对数据库操作的类，都使用到了模版模式
• 包装器设计模式：我们的项目需要连接多个数据库，而且不同的客户在每次访问中根据需要会去访问不同的数据库。这种模式让我们可以根据客户的需求能够动态切换到不同的数据源。
• 观察者模式：Spring事件驱动模型就是观察者模式很经典的一个应用
• 适配器模式：Spring AOP的增强或者通知Advice使用到了适配器模式、Spring MVC中也是用到了适配器模式适配Controller

Spring事务在哪些情况下会失效?至少说出3种情况?

• Spring事务的本质是Spring AOP和数据库事务，Spring将数据库的事务操作提取为切面，通过AOP在方法执行前后增加数据库的事务操作。Spring在以下情况下事务会失效。

  • 事务方法未被代理。比如事务方法不是public，Spring AOP只能代理public方法，非public方法上的事务注解将不起作用。方法被final类型修饰，导致动态代理不能重新该方法，事务失效。
  • 异常类型不匹配。默认情况下，Spring只会在未检查异常和Error时回滚。如果抛出受检异常（继承自Exception但不是RuntimeException）事务不会回滚。
  • 事务传播行为配置不当
  • 未启用Spring事务管理功能：@EnableTransactionManagement 注解用来启用spring事务自动管理事务的功能，这个注解千万不要忘记写了
  • 数据源未配置事务管理器
  • 自身调用问题。通过非代理对象访问方法，事务会失效，例如一个方法A调用方法B，方法B加事务，方法A不加事务，方法B事务会失效，可以通过注入ApplicationContext对象，applicationContext.getBean(B.class).serviceB()解决;
  • 业务和spring事务代码不在一个线程中

SpringBean的生命周期?

• 

• SpringBean的生命周期简单概括为4个阶段：

  • 实例化。Spring容器根据Bean的定义，使用反射机制实例化Bean对象

  • 属性赋值。一旦Bean实例化完成，Spring容器会通过依赖注入（DI）的方式开始对Bean的属性进行赋值。

  • 初始化

    • 如果实现了xxxAware接口，通过不同类型的Aware接口拿到Spring容器的资源
    • 如果实现了BeanPostProcessor（Bean的后置处理器）接口，则会回调该接口的PostProcessBeforeInitialzation（后置处理器的前置初始化）
    • 如果实现了init-method方法，则会执行init-method配置的方法
    • 如果实现了BeanPostProcessor（Bean的后置处理器）接口，则会回调该接口的PostProcessAfterInitialization（后置处理器的后置初始化）方法

  • 使用

  • 销毁

    • 容器关闭后，如果Bean实现了DisposableBean接口，则会回调该接口的destroy方法，
    • 如果配置了destroy- method方法，则会执行destroy- method配置的方法

默认创建的Bean是单例,还有哪些类型?一共有几种?

• Spring创建的Bean默认是单例的
• 一共有5种。单例（singleton）、 多例（pototype）、request、session、global-session

Spring AOP 和 AspectJ AOP 有什么区别？

• Spring AOP是基于动态代理实现，属于运行时增强，AspectJ AOP则属于编译时增强

• AspectJ属于编译时增强，主要有三种方式

  • 编译时织入：指的是增强的代码和源代码我们都有，直接使用AspectJ编译器编译就行了，编译之后生成一个新的类，他也会作为一个正常的java类装载到JVM
  • 编译后织入：指的是代码已经被编译成class文件或者已经打包成jar包，这时候要增强的话，就是编译后织入。
  • 加载时织入：指的是在JVM加载类的时候进行织入

• 总结：Spring AOP只能在运行时织入，不需要单独编译，性能相比AspectJ编译织入的方式慢，而AspectJ只支持编译前后和类加载时织入，性能更好，功能更加强大。

FactoryBean和BeanFactory有什么区别？

• BeanFactory是Bean的工厂，ApplicationContext的父类，IOC容器的核心，负责生产和管理Bean对象
• FactoryBean是一个Bean，可以通过实现FactoryBean接口定制实例化Bean的逻辑，通过代理一个Bean对象，对方法前后做一些操作。

Spring事务传播行为有多少种？分别是什么作用？（即问@Transactional的propagation参数）

• required（默认属性） 如果存在一个事务，则支持当前事务。如果没有事务则开启一个新的事务。 被设置成这个级别时，会为每一个被调用的方法创建一个逻辑事务域。如果前面的方法已经创建了事务，那么后面的方法支持当前的事务，如果当前没有事务会重新建立事务。
• Mandatory 支持当前事务，如果当前没有事务，就抛出异常。
• Never 以非事务方式执行，如果当前存在事务，则抛出异常。
• Not_supports 以非事务方式执行操作，如果当前存在事务，就把当前事务挂起。
• requires_new 新建事务，如果当前存在事务，把当前事务挂起。
• Supports 支持当前事务，如果当前没有事务，就以非事务方式执行。
• Nested 支持当前事务，新增Savepoint点，与当前事务同步提交或回滚。 嵌套事务一个非常重要的概念就是内层事务依赖于外层事务。外层事务失败时，会回滚内层事务所做的动作。而内层事务操作失败并不会引起外层事务的回滚。

Spring的Bean默认是单例的不是线程安全的，怎么保证线程安全？

• Spring容器中大部分Bean都是无状态（不会保存数据）的，在某种程度上来说也是线程安全的

• Bean有状态的情况下，

  • 使用ThreadLocal保证线程安全。ThreadLocal会为每一个线程提供一个独立的变量副本，从而隔离了多个线程对数据的访问冲突，也就没有线程安全问题了。
  • 使用锁机制保证线程安全。例如 synchronized 或 ReentrantLock 加锁修改操作，保证线程安全。
  • 设置为原型作用域，每次请求时都生成一个新对象，也就没有线程安全的问题了。

SpringMVC工作流程是怎么样的?

• 
• 用户发送请求给前端控制器DispatcherServlet，前端控制器收到请求后调用HandlerMapping处理器映射器，处理器映射器找到具体的处理器，封装Handler对象返回给前端控制器DispatcherServlet
• 前端控制器DispatcherServlet调用后端控制器controller，controller执行完返回ModelAndView对象给前端控制器DispatcherServlet
• 前端控制器DispatcherServlet将ModelAndView对象传给视图解析器ViewReslover，视图解析器解析后返回具体View给前端控制器DispatcherServlet

MyBatis工作流程

1. 首先MyBatis应用程序会去加载MyBatis全局配置文件，如数据源和Mapper配置文件等信息。
2. 解析配置文件，MyBatis会根据XML配置文件生成Configuration对象和一个个MappedStatement对象，MappedStatement对象中包含参数映射配置、动态SQL语句、结果映射配置，对应着select、update、delete、insert标签
3. SessionFactoryBuilder会根据Configuration对象创建SqlSessionFactory对象，用来开启SqlSession
4. 当我们在调用Mapper接口中的方法时，SqlSession会调用对应的MappedStatement对象
5. Executor（负责动态SQL的生成和查询缓存的维护）会将MappedStatement对象进行解析、SQL参数转化、动态SQL拼接，生成JDBC Statement对象
6. 通过JDBC执行SQL
7. 借助MappedStatement中的映射关系，将返回结果进行转化并返回

Mybatis里的 # 和 $ 的区别？

• #{}是预编译处理，底层使用的是PreparedStatement，会将SQL中的#{}替换为？号，执行效率高，可以防止SQL注入，适合传递参数
• ${}只是创建普通的SQL语句，然后在执行SQL语句时Mybatis将参数直接拼入到SQL里，不能防止SQL注入，因为参数直接拼接到SQL语句中，未经验证可能会造成安全问题。

MyBatis一级缓存和二级缓存,作用域是多少?

• 一级缓存：SqlSession级别的缓存，缓存的数据只在SqlSession内有效。默认开启。
• 二级缓存：mapper级别的缓存，同一个namespace共用这一个缓存，所以对SqlSession是共享的，二级缓存需要我们手动开启。
• 查询的顺序：先查询二级缓存，没有命中再去查一级缓存，如果一级缓存也没有则查数据库。sqlSession关闭之前，一级缓存中的数据会写入二级缓存

Springboot的启动类的启动流程是怎样的?

• 
• 首先是准备环境，根据不同的环境创建不同的Environment
• 准备、加载上下文，为不同的环境选择不同的Spring Context，然后加载资源，配置Bean
• 初始化，这个阶段刷新Spring context，启动应用
• 最后结束流程

为什么使用SpringBoot，SpringBoot比Spring好在哪里？

• 简化开发，SpringBoot提供一套开箱即用的组件和自动化配置，简化了项目配置和开发，开发人员可以更专注于业务逻辑的实现，无需花费过多时间在繁琐的配置上
• 自动化配置，SpringBoot通过自动配置功能，通过约定大于配置的原则，根据约定的规则配置应用程序，减少了配置的复杂性

SpringBoot的自动装配原理是什么?

• SpringBoot实现自动装配是通过SpringBoot项目启动类上的@SpringBootApplication注解实现的。SpringBoot的自动装配实际上是用METE-INF/spring.factories文件中获取到对应的需要进行自动装配的类，并生成对应的Bean对象交给Spring容器进行管理。
• SpringBoot的核心注解是@SpringBootApplication，该注解是一个复合主键，@SpringBootApplication中有@SpringBootConfiguration和@EnableAutoConfiguration和@ComponentScan注解。
• 其中@SpringBootConfiguration注解里有一个@Configuration注解，表明这个SpringBoot是一个配置类，最终要被注入到Spring容器中
• @EnableAutoConfiguration注解是实现自动化配置的核心。也是一个复合注解，里面包含@AutoConfigurationPackage和@Import注解。
• @AutoConfigurationPackage中有一个@Import(AutoConfigurationPackages.Registrar.class)注解，其中 Registrar 类的作用是将启动类所在包下的所有子包的组件扫描注入到spring容器中。
• @Import注解中会加载AutoConfigurationImportSelector，这个类中的会查找meta-info/spring.factories文件中所有的自动配置类，并加载这些类，Spring.factories其中有一个key=EnableAutoConfiguration，他对应的值就是一个个以AutoConfiguration结尾来命名的 xxxAutoConfiguration 自动配置类。
• 前面的xxxAutoConfiguration 自动配置类并不是所有的都会生效，都是在某些限定条件下才会生效，这些限定条件是通过@ConditionOnxxx注解来实现的

了解SpringCloud吗？说一下他和SpringBoot的区别

SpringBoot是用于构建单体应用的框架，而SpringCloud则是用于构建分布式系统中的微服务架构的工具，SpringCloud提供了服务发现、远程调用、负载均衡、断路器、网关等功能

HTTP与RPC的区别?

• RPC（远程过程调用）可以基于TCP协议，也可以基于HTTP协议，而HTTP是基于HTTP协议之上
• RPC使用自定义的TCP协议，可以让请求报文体积更小，提高传输效率，而HTTP如果是基于HTTP协议请求中会有很多无用的内容
• RPC可以实现高效的二进制传输，而HTTP大多是通过JSON来实现，HTTP更耗性能
• RPC基本自带负载均衡策略，而HTTP需要配置Nginx来实现负载均衡
• RPC能做到自动通知，不影响上游，而HTTP需要事先通知
• RPC主要用于公司内部的服务调用，性能消耗低，传输效率高，服务治理更方便，而HTTP主要用于对外的接口调用，浏览器接口调用、APP接口调用、第三方接口调用等

Eureka工作原理?

• ①微服务启动后会向Eureka注册，Eureka集群自己会自动进行同步，
• ②当服务消费者要调用提供者时，会向Eureka获取服务提供者的地址，同时会将服务提供者地址缓存到本地，下次再调用时，则直接从本地缓存中获取，完成一次调用
• ③当Eureka检查到提供者不可用时，会在服务注册中心将服务置为Down状态，并把当前服务的不可用状态告知订阅者，订阅过的服务消费者会更新本地缓存
• ④服务的提供者会定期的（默认30s）向Eureka发送心跳，证明当前状态可用，Eureka如果在90s内未收到提供者的心跳，则认为服务宕机，注销该实例
• ⑤如果在15分钟内超过85%的节点都没有正常的心跳，Eureka会开启自动保护机制，不再注销服务，仍能接收新服务的注册和查询，但不会同步到其他节点上
• Eureka--AP（可用性、分区容错性）
• Zookeeper---CP(一致性、分区容错性)正因为保证一致性，在节点宕机时选举时间过长注册服务会瘫痪

负载均衡策略有哪些算法?

• 简单轮询。将请求按顺序分发给后端服务器上，不关心服务器当前的状态，比如后端服务器的性能、当前负载
• 加权轮询。根据服务器自身的性能给服务器设置不同的权重，将请求按顺序和权重分发给不同步的服务器，让性能更高的服务器处理更多的请求
• 一致性哈希。根据请求的客户端IP、或请求参数通过哈希算法得到一个数值，利用该数值取摸映射出对应的后端服务器，这样能保证同一个客户端或者相同参数的请求每次都能使用同一台服务器。
• 最小连接数。是指把请求分配给当前连接数最少的服务器，以确保负载更均匀

什么是服务熔断？什么是服务降级 ？

• 服务熔断是应对微服务雪崩效应的一种链路保护机制，类似保险丝。当调用链路的某个服务不可用或响应时间太长时就会进行服务熔断，快速响应失败。当检测到该节点微服务调用响应正常后，恢复调用链路。
• 雪崩效应是指微服务之间的数据交互通过远程调用来完成，服务A调用服务B，服务B调用服务C，如果服务C不可用，随着时间的增长，对服务C的调用也越来越多，然后服务C崩溃，对服务B的调用也在持续增多，然后服务B崩溃，随之A也崩溃，导致雪崩效应。
• 在SpringCloud框架里，熔断机制通过Hystrix实现，Hystrix会监控微服务间的调用状况，当失败调用达到一定阈值，缺省是5秒内20次调用失败，就会启动熔断机制。
• 服务降级是指在服务器压力剧增的时候，根据实际业务使用情况对一些服务和页面有策略的不处理或者用一种简单的方式处理，从而释放服务器资源以保证核心业务的正常高效运行。

线程隔离 熔断降级

• 线程隔离

  • Hystrix会为每个依赖服务调用一个小的线程池，线程池用尽，会立即拒绝，默认不采用排队

• 熔断降级

  • 当线程池已满或者请求超时会触发Hystrix熔断降级，优先保证核心服务

Dubbo工作原理?

• ①provider向注册中心去注册
• ②consumer从注册中心订阅服务，注册中心会通知consumer注册好的服务
• ③consumer调用provider
• ④consumer和provider都异步的通知监控中心

Dubbo注册中心挂了可以继续通信吗？

可以，因为刚开始初始化的时候，消费者会将提供者的地址等信息拉取到本地缓存，所以注册中心挂了可以继续通信。

Dubbo的执行流程

项目一启动，加载配置文件的时候，就会初始化，服务的提供方ServiceProvider就会向注册中心注册自己提供的服务，当消费者在启动时，就会向注册中心订阅自己所需要的服务，如果服务提供方有数据变更等，注册中心将基于长连接的形式推送变更数据给消费者。

Dubbo的安全性如何得到保障

• 在有注册中心的情况下,可以通过dubbbo admin中的路由规则，来指定固定ip的消费方来访问
• 在直连的情况下，通过在服务的提供方中设置密码(令牌)token，消费方需要在消费时也输入这 个密码，才能够正确使用。

Dubbo中如何保证分布式事务？

• 一般情况下，我们尽量将需要事务的方法放在一个service中，从而避开分步式事务。
• Dubbo底层是基于socket： Socket通信是一个全双工的方式，如果有多个线程同时进行远程方法调用，这时建立在client server之间的socket连接上会有很多双方发送的消息传递，前后顺序也可能是乱七八糟的，server处理完结果后，将结果消息发送给client，client收到很多消息，怎么知道哪个消息结果是原先哪个线程调用的？ 答：使用一个ID，让其唯一，然后传递给服务端，再服务端又回传回来，这样就知道结果是原先哪个线程的了。

SpringCloud有哪些组件?怎么用的?

• Eureka（服务治理）
• Ribbon（客户端负载均衡）
• Hystrix（熔断器）
• Zuul（网关）
• Feign（远程调用）

说说"3PC"模式的过程。

• 三个阶段过程

  • 阶段一：CanCommit

    • 事务协调者向参与者发送一个包含事务内容的CanCommit请求，询问是否能够执行事务，并等待回应
    • 事务参与者向事务协调者反馈事务询问的响应，如果事务参与者认为自己可以顺利执行事务，就返回YES，否则返回NO响应

  • 阶段二：PreCommit

    • 事务协调者根据参与者的响应，如果阶段一返回的都是YES则执行事务预提交，如果阶段一返回有NO则中断事务操作

    • 事务预提交：

      • 事务协调者会向所有参与者节点发出预提交（PreCommit）请求，并等待响应
      • 事务参与者收到PreCommit请求后，会执行事务操作，并将结果返回
      • 事务协调者会根据得到的ACK响应确定下一阶段是否提交事务或者终止操作

    • 中断事务：

      • 事务协调者会向所有的事务参与者发出放弃（Abort）请求
      • 然后事务参与者如果收到Abort请求或者超时了，就会中断事务

  • 阶段三：do Commit

    • 执行提交：

      • 事务协调者会发起提交事务请求，并等待ACK响应
      • 事务参与者收到提交（do Commit） 请求后会执行事务并反馈事务提交的结果，向事务协调者发送ACK消息。
      • 最后协调者收到ACK消息后完成事务

    • 中断事务：中断事务是因为出现了异常，比如协调者一方出现了问题，或者是协调者与参与者之间出现了故障。过程如下：

      • 首先事务协调者会向所有的事务参与者发送中断请求
      • 参与者接收到中断请求后会根据二阶段记录的undo信息来执行事务回滚操作，并释放资源
      • 在所有事务参与者完成事务回滚后会向事务协调者发送ACK消息
      • 最后事务协调者收到所有的ACK消息后，会中断事务

• 3PC协议的优点

  • 3PC对于协调者和参与者都设置了超时时间，而2PC只有协调者才拥有超时机制。避免了参与者在长时间无法与协调者通讯的情况下无法释放资源的问题
  • 3PC多设置了一个缓冲阶段保证了在最后提交阶段之前各参与节点的状态是一致的。

六、MySQL

事务ACID的特性是什么？如何实现？

• 原子性。原子性是指一个事务中所有操作，要么全部完成，要么全部不完成，不会结束在中间某个环节，就好比购买一件商品，购买成功商家付了钱，商品到手；购买失败商品在商家手中，消费者钱也没花出去。原子性是通过undo log（回滚日志）来保证的
• 一致性。是指事务操作前后，数据满足完整性约束，数据库保持一致性状态。一致性是通过持久性+原子性+隔离性来保证的
• 隔离性。隔离性可以防止多个事务并发执行时由于交叉执行而导致数据不一致，多个事务之间是相互隔离的，不会相互干扰。隔离性是通过MVCC（多版本并发控制）或锁机制来保证的
• 持久性。事务处理结束后，对数据的修改是永久性的。持久性是通过redo log（重做日志）来保证的

MySQL事务的隔离级别有哪些？他们各有什么问题？

• 读未提交，指一个事务还没提交，它做的变更就能被其他事务看到，可能会出现脏读、不可重复读、幻读现象。
• 读已提交，指一个事务提交后，它做的变更才能被其他事务看到。可能会出现不可重复读和幻读现象。
• 可重复读，指一个事务执行过程中看到的数据，一直跟这个事务启动时看到的数据是一致的，这是MySQL的默认事务隔离级别。可能会发生幻读现象。
• 串行化，会对记录加上读写锁，在多个事务对这个记录进行读写操作时，如果发生了读写冲突的时候，后访问的事务必须等前一个事务执行完成才能继续执行。

什么是脏读、不可重复读、幻读？如何解决幻读？

• 脏读：如果一个事务读到了另一个未提交的事务修改过的数据，就意味着发生了脏读。

• 不可重复读：最开始读到的数据和事务结束前的任意时刻读到的同一批数据出现不一致的情况，就意味着发生了不可重复读现象。

• 幻读：一个事务在前后两次查询同一个范围时，由于其他事务的插入或删除操作，导致后一次查询的记录数量发生了变化。就意味着发生了幻读现象。

  • 针对快照读（普通的select语句），MVCC会在执行查询时会生成一个读视图，后续所有的查询都是利用这个读视图进行查询，因此避免了幻读问题。
  • 针对当前读（for update语句），是通过记录锁+间隙锁的方式解决了幻读问题。但是InnoDB中的MVCC并不能完全避免幻读的问题。举个例子，如果事务 A 先执行 SELECT * FROM t_test WHERE id > 100; （快照读）得到了3个数据。执行后事务 B 往插入一个 id=200 的数据并提交，事务 A 再执行SELECT * FROM t_test WHERE id > 100 for update; （当前读）就会得到 4 个数据，此时也发生了幻读现象。
  • 要避免这种特殊情况下发生幻读就是尽量在开启事务之后马上执行for update当前读语句，对记录加行锁避免其他事务插入一条新数据。

说说mysql MVCC多版本并发控制机制原理。

• MVCC是基于undo log和ReadView(读视图)来实现事务隔离的，在执行update和delete操作时不会更改原始数据，而是会将每次操作详细记录在undoLog版本链表中，每一行记录都会有一个版本链表，记录了这条记录的所有变更。

• 读取数据的时候是用读视图来做可见性判断的，具体流程如下：

  • 事务在进行快照读操作的时候会生成读视图。在事务执行快照读的那一刻，会生成数据库系统当前的一个快照，记录并维护系统当前活跃事务的ID，这个ID是自增的。MySQL会把这个读视图作为条件来判断当前事务能够看到哪个版本的数据
  • 读视图遵循一个可见性算法，将要修改的数据的最新记录的事务ID取出来和当前其他活跃事务ID进行对比，如果不符合可见性就会一直通过回滚指针去遍历链表直到找到符合可见性的事务ID为止

MySQL里有哪些锁？

• 全局锁，一般用于全库逻辑备份
• 表级锁
• 行级锁
• 记录锁，有S锁和X锁之分，满足读写互斥、写写互斥
• 间隙锁，只存在于可重复读隔离级别，目的是解决可重复读隔离级别下的幻读现象

执行一条SQL请求的过程是什么？

• 首先，客户端与MySQL服务器建立连接，连接器会进行身份验证和权限确认等
• 查询缓存，如果所需查询的结果已经存在与缓存中则直接返回结果
• 当缓存未命中时，解析器和预处理器对查询语句进行解析，验证语法正确性，生成语法树。
• MySQL优化器会根据查询语句的结构、表的统计信息等因素生成多个可能执行计划，并通过成本估算器挑选出最优的执行计划
• MySQL执行器按照优化器选定的执行计划，调用存储引擎的API来执行查询，获取所需数据
• MySQL存储引擎负责实际的数据存储和检索，根据执行器的请求，读取或写入数据

Mysql存储引擎都有哪些？ 分别有什么区别？优缺点是什么？

• InnoDB：

  • MySQL5.5之后的默认引擎。被设计用来处理大量短期事务。具有ACID事务支持
  • 支持事务、行锁、外键，并发写的时候只锁一行数据，适合高并发的操作
  • 缓存索引和真实数据，对内存要求高，而且内存大小对性能有决定性影响
  • 除了查询和新增外，需要更新，删除操作，应该优先选择InnoDB存储引擎
  • 除了有其他特别的原因需要使用其他的存储引擎，否则优先考虑InnoDB引擎

• MyISAM：

  • MyISAM提供了大量的特性，包括全文检索、压缩、空间函数等，但MyISAM不支持事务和行锁，有一个毫无疑问的缺陷是崩溃后无法安全恢复
  • 不支持事务、也不支持外键，支持表锁，即使有操作一条数据也锁定整个表，不适合高并发的操作
  • 只缓存索引，不缓存真实数据，缓存真实数据需要调用操作系统的缓存区，引发过多的系统调用影响效率

• Memory引擎

  • 如果需要快速访问内存数据，并且这些数据不会被修改，重启以后丢失也没关系，那么可以使用Memory引擎
  • 不支持事务、也不支持外键，支持表锁
  • Memory引擎比MyISAM要快，数据存储在内存，但是一旦服务器出现故障，数据都会丢失

索引是什么？有什么好处？

• 索引本质上是一种提高查询效率的数据结构
• 索引是需要占用存储空间，类似于书籍的目录，有了目录，我们可以通过目录定位到需要查询的数据。
• 如果查询的时候没有用索引就会全表扫描，这时候查询的时间复杂度是O(n)
• 如果使用索引，那么查询的时候基于二分查询算法，通过索引快速定位到目标数据。
• MySQL的索引数据结构是B+数，搜索的时间复杂度为O(logdn),其中d表示节点允许的最大子节点个数为d个

MySQL中索引是怎么实现的？

• 
• MySQL中InnoDB引擎是用了B+树作为索引的数据结构。B+数是一种多叉树，叶子结点存放数据，非叶子结点只存放索引，而且每个节点的数据是按主键顺序存放的。在叶子结点中包含了所有的索引值信息，每个叶子结点有两个指针，分别指向下一个叶子结点和上一个叶子结点，形成了一个双向链表
• 数据库的索引和数据都是存储在硬盘的，我们把读取一个节点当作一次磁盘IO操作。B+树存储千万级的数据只需要3-4层高度就可以满足，这意味着从千万级的表查询目标数据最多需要3-4次磁盘IO
• 所以B+树相比B树和二叉树来说，最大优势在于查询效率很高，因为即使在数据量很大的情况下查询只需要3-4次IO操作

一页默认是16Kb,高度为3的B+数据最多能存储多少个数据?

• 我们假设主键ID为bigint类型，长度为8字节，InnoDB源码中设置的指针大小为6字节。那么一个非叶子结点可以存放16kb / (8b + 6b) = 16 * 1024B / 14B = 1170个指针
• 如果我们假设一行记录的数据大小为1kb，单个叶子结点可以存放的记录数即为 16kb / 1kb = 16 条
• 因此一个高度为3的B+树可以存储的数据为 1170 * 1170 * 16 = 21902400（两千多万）条数据

实际情况中每个节点可能不能填充满，因此在数据库中，B+Tree 的高度一般都在 2~4 层。MySQL 的 InnoDB 存储引擎在设计时是将根节点常驻内存的，也就是说查找某一键值的行记录时最多只需要 1~3 次磁盘 I/O 操作。

MySQL为什么用B+树结构？和其他结构比的优点？

• 那为什么索引不用hashmap而用B+树？

  • 排序、范围查找不能用哈希结构的索引，而树型结构的索引可以很好的支持排序、范围查找
  • 哈希类型的索引可能会退化为链表，时间复杂度为O(n)，而树型结构的有序特征依然能够保持O(log2N) 的高效率

• 为什么索引要用B+树而不用B树？

  • B树索引的数据和索引存放在每一个结点，造成每个结点中数据域较大，由于结点大小固定，一个结点中数据域大的话索引域的存放空间自然就会小，一个结点中索引存放空间小又要保存大量的数据，只能增大树的高度，导致IO次数变多进而影响效率。
  • B+树索引的数据全部存放在叶子结点，而非叶子结点只存放行记录的主键和索引，这个可以大大增加每一个结点存储key的数量，降低B+树的高度，减少IO次数。
  • B+树更适合基于范围的查询，B+树只需要遍历叶子结点就可以实现整棵树的遍历，而B树需要进行一次中序遍历来遍历。

什么是聚簇索引，什么是非聚簇索引？他们之间有什么区别？

• 聚簇索引简单来说就是物理地址等于逻辑地址的一种数据存储方式，整张表的主键索引构建一颗B+树，叶子节点存放的是整张表的行记录数据，数据也是索引的一部分。这样的存储方式导致数据访问的速度更快，因为数据和索引存储在同一个B+树中，聚簇索引查询数据时，可以直接从索引中获得数据行，不需要额外的步骤去查找数据所在位置。但是每张表只能拥有一个聚簇索引
• 非聚簇索引简单来说就是物理地址不等于逻辑地址的一种数据存储方式，叶子节点存储的不再是整张表的行记录数据，而是整张表的主键值，通过非聚簇索引先找到的是主键值，再通过主键值回溯到聚簇索引中查找实际的数据行，这个过程也叫回表。

什么是回表？

• 聚簇索引的 B+Tree 的叶子节点存放的是实际数据，所有完整的用户记录都存放在聚簇索引的 B+Tree 的叶子节点里；
• 二级索引的 B+Tree 的叶子节点存放的是主键值，而不是实际数据
• 在查询时使用了二级索引，如果查询的数据能在二级索引里查到，那么就不需要回表，这个过程就是覆盖索引
• 如果查询的数据不在二级索引里，就会先查二级索引，找到对应的叶子结点获取主键值，然后通过主键查询聚簇索引获取数据，这个过程就叫回表。

索引优化详细讲讲？

• 前缀索引优化。使用前缀索引是为了减小索引字段的大小，可以增加一个索引页中存储的索引值，有效提高索引的查询速度。在一些大字符串的字段作为索引时，使用前缀索引可以帮助我们减少索引项的小大。

• 利用覆盖索引来进行查询操作，来避免回表操作

  • 尽量不要使用select * 来做查询。原因：如果主键索引是学号，另外我们还根据手机号也建了索引，如果我们where条件是手机号，分两种情况：

    • 如果我们查询的字段是学号，直接在手机号索引就能获取到数据，不需要回表。
    • 如果我们查询的是其他字段，我们查询的时候流程是先会根据手机号查询学号，再根据学号去主键索引表查询其他字段数据，这个过程叫回表。

• 主键索引自增。使用自增主键可以让插入的新数据按照顺序添加到当前索引节点的位置，不需要重新移动已有的数据，提高效率。

• 业务上具有唯一特性的字段，即使是组合字段，也建成唯一索引。

• 超过三张表禁止join；join的字段数据类型保持绝对一致；多表关联的字段需要有索引

• 禁止使用左模糊或者全模糊，如果需要走搜索引擎来解决。

• 建组合索引的时候，区分度最高的放在最左边

• SQL性能优化的目标至少达到range级别，要求是ref级别，如果可以是const最好

  • const单表中最多只有一个匹配行（主键或唯一索引），在优化阶段即可读取到数据
  • ref指的是使用普通的索引
  • range对索引进行范围检测
  • index代表索引物理文件全扫描，速度非常慢

• 关联查询优化

  • 保证被驱动表的join字段被索引
  • left join 时，选择小表作为驱动表，大表作为被驱动表
  • inner join 时，mysql会自动将小结果集的表选为驱动表。
  • 能够直接多表关联的尽量直接关联，不用子查询

  注：驱动表是主表的意思，例如select* from t_emp t1 left join t_dep t2 on t1.id = t2.id , t1是驱动表，t2是被驱动表

Mysql 什么情况下会导致“索引失效“？

• 最左原则，联合索引，没有遵循最左匹配原则，造成索引失效
• 字符串不加单引号会导致索引失效，索引列的隐式转换
• 模糊匹配中前缀匹配索引会失效
• 范围查询：范围右边的列不能命中
• != <>：带not的都不能触发索引
• like：以%开头索引会失效
• 索引列上进行函数、计算操作，索引会失效
• 用or连接条件，一个条件使用了索引，另一个没有使用索引，会导致索引失效
• order by时不限制索引失效
• order by时顺序错误,索引失效
• order by时规则不一致, 索引失效

分别讲一下binlog、undolog、undolog?

• binlog文件是记录了数据库表机构变更和表数据修改的日志，但不会记录查询类的操作
• undolog是一种用于撤销回退的日志，用于保证事务的ACID特性中的原子性
• RedoLog是为了保证事务的持久性，能够保证MySQL在任何时间段崩溃重启后之前已提交的记录都不会丢失，同时将写操作的随机写变成了顺序写，提升了Mysql写入磁盘的性能。

一条SQL语句的执行顺序？

答：from->where->group By->聚合函数->having分组->计算表达式->select->order By

Explain关键字的作用？

• Explain可以查询SQL的执行计划，主要用于分析SQL语句的执行过程，比如有没有走索引，有没有外部排序，没有没索引覆盖等等。

• 只针对select查询，可以显示出大概的执行流程和索引命中的情况。explain出来的信息id、type（数据扫描类型）、possible_key（可能用到的索引）、key（实际用到的索引）、key_len（索引的长度）、rows（扫描的数据行数）、ext

• id: id相同，可以认为是同一组，执行顺序由上而下，id不同，id越大优先级越高。

• type:

  • all：从硬盘中遍历全表；
  • index：全索引扫描。从索引中读全表；
  • range：索引范围扫描。检索给定范围的行；
  • ref：非唯一索引扫描。表连接匹配条件，
  • eq_ref：唯一索引扫描。类似ref区别是使用的索引是唯一索引；
  • const：结果只有一条的主键或唯一索引扫描。通过索引一次就找到了；
  • system：表仅有一行记录。这是const类型的特例；
  • null：执行时甚至不用访问表或索引

• key_len：表示索引使用的字节数，根据这个值可以判断索引的使用情况

  计算逻辑:

  • 先看索引上字段的类型+长度比如 int=4 ; varchar(20) =20 ; char(20) =20
  • 如果是varchar或者char这种字符串字段，视字符集要乘不同的值，比如utf-8要乘 3，GBK要乘2
  • varchar这种动态字符串要加2个字节
  • 允许为空的字段要加1个字节

• filtered:这个字段表示存储引擎返回的数据在server层过滤后，剩下多少满足查询的记录数量的比例，注意是百分比，不是具体记录数

• Extra

  • Using filesort 当查询语句中包含group by操作，而无法利用索引完成排序操作的时候，这时不得不选择相应的排序算法进行，甚至可能会通过文件排序，效率是很低的，要避免这种问题的出现
  • Using temporary 使用临时表保存中间结果，MySQL在查询结果排序时使用临时表，常见于排序order by和分组查询group by。效率低要避免这种问题的出现
  • Using index 在索引中即可全部获得数据，不需再到表中取数据，也就是使用了覆盖索引，避免了回表操作，效率高。

MySQL如何开启慢查询？

• MySQL的慢查询日志是MySQL提供的一种日志记录，它用来记录在MySQL中响应时间超过阀值的语句，具体指运行时间超过long_query_time值的SQL，则会被记录到慢查询日志中。

• 如何开启慢查询语句?

  • 通过设置long_query_time来定义构成慢查询的阈值，默认是10s。
  • 启用慢查询日志，通过设置slow_query_log为1（或ON）并指定日志文件位置。
  • （可选）启用log_queries_not_using_indexes来记录所有没有使用索引的查询。
  • 分析慢查询日志文件中的内容
  • 优化---->explain--->sql优化的知识进行优化

MySQL主从复制了解吗？对于主从延迟有什么处理办法？

• 
• MySQL的主从复制依赖于binlog，复制的过程就是将binlog中的数据从主库传输到从库上。这个过程是异步的，也就是主库上执行事务操作不会等待复制binlog的线程同步完成
• MySQL主库收到客户端提交事务的请求之后，会先写入binlog再提交事务（半同步复制会等待至少一个从库确认已接收到该事务的binlog事件并写入本地的中继日志），返回客户端操作成功的响应
• 从库会创建一个专门的IO线程连接主库的log dump线程，来接收主库的binlog日志，把binlog信息写入relay log的中继日志里，再返回给主库复制成功的响应
• 从库会创建一个用于回放binlog的线程，用于去读取relay log中继日志，然后回放binlog更新存储引擎中的数据，最终实现主从的数据一致性。
• 主从延迟问题的处理可以强制走主库，对于大事务或资源密集型操作，直接在主库上执行，避免从库的额外延迟。
• 主主模式：相互主从
• 主从级联模式：一主一从，一从再多从
• 主主从级联模式：多主多从，一从多从

mysql的分库和分表？常见的数据分片算法有哪些？

• 分库是指按照业务将数据划分到多个独立的数据库中，每个数据库只负责存储部分数据，解决并发连接过多，单机mysql扛不住的问题

• 分表是将数据库中的表拆分成多个表，每个表只负责存储一部分数据，减轻单个表的压力，分表主要解决单表数据量太大，查询性能下降问题。常见的分库分表策略有垂直分库、垂直分表、水平分库、水平分表等。

• 常见的数据分片

  • 取模：通过对id进行取模，完成数据分片。
  • 枚举：适用于在特定业务场景下，将不同的数据存放于不同的数据库中，如按省份存放订单、按存放人员信息等。
  • hash
  • 一致性hash(哈希环)：一致性hash算法引入了hash环的概念，环的大小是0-2^32-1,首先通过crc16算法计算出数据节点在环中的位置，然后从数据映射的位置开始，以顺时针的方式找出最近的数据节点，接着将数据存入到该结点中，但数据并没有达到预期的数据均匀。可以通过设置虚拟数据映射结点来解决数据分布不均的问题。数据仍然以顺时针方式寻找数据节点，当找到最近的数据节点无论是实际还是虚拟，都会进行存储，如果是虚拟数据节点的话，最终会将数据保存到实际数据节点中。 从而尽量的使数据均匀分布。

七、Redis

Redis为什么这么快?

• 单线程的 Redis 吞吐量可以达到 10W/每秒
• Redis的大部分操作都在内存中完成，并且采用高效的数据结构，CPU不是Redis的瓶颈，Redis的瓶颈最有可能是机器内存的大小或者网络带宽。既然单线程容易实现，而且CPU不会成为瓶颈，那就顺理成章地采用单线程的方案了（毕竟采用多线程会有很多麻烦！）
• Redis采用单线程模型可以避免多线程之间的竞争，减小了线程上下文切换开销，不需要锁的消耗。
• Redis采用了IO多路复用机制处理大量的客户端Socket请求，IO多路复用机制是指一个线程处理多个IO流，也就是select/epoll机制，单线程的Redis可以处理多个IO流的效果。

redis是单线程还是多线程?为什么?

• 单线程
• 官方FAQ表示，因为Redis是基于内存的操作，CPU不是Redis的瓶颈，Redis的瓶颈最有可能是机器内存的大小或者网络带宽。既然单线程容易实现，而且CPU不会成为瓶颈，那就顺理成章地采用单线程的方案了（毕竟采用多线程会有很多麻烦！）

Redis数据类型有几种，说说每种对应的使用场景

• 常用的数据类型有五种。分别是String、Hash、List、Set、ZSet
• String类型常见的应用场景是缓存对象、常规计数、分布式锁、共享session信息等
• List类型我们可以用来存储多个有序的字符串，使用lpush或者rpush实现消息队列。也可以用来实现栈
• Hash类型常用于缓存对象、购物车等。
• Set也可以用来保存多个字符串元素，不允许重复并且是无序的
• Zset有序集合，常用于排序场景，比如排行榜、电话和姓名排序等。
• Zset有序集合，我们可以用来做一个排行榜的功能，用户发布了n篇文章，其他人看到文章后点赞，使用score来记录点赞数，有序集合会根据score来排名；也可以用来做延迟消息队列，下单的时候15分钟未支付则自动取消订单，我们可以将下单后的15分钟后时间作为score，订单作为value存入redis，消费者轮询的去消费，如果消费的时间大于等于这笔记录的score，则将这笔记录移除队列，取消订单。

Zset底层是怎么实现的？

• Zset底层是压缩列表或跳表实现的
• 如果有序集合的元素个数小于128个，并且每个元素的值小于64字节时，Redis会使用压缩列表作为Zset的底层数据结构
• 如果有序集合不满足上面条件，则会使用跳表作为Zset的底层数据结构
• 在Redis7.0中，压缩列表数据结构已经废弃，交由listpack数据结构来实现了。

Redis是单线程还是多线程？

• Redis的网络 I/O 和执行命令一直使用的是单线程模型，但在Redis6.0版本后，也采用了多个IO线程来处理网络请求，这是因为随着网络硬件性能提升，Redis的性能瓶颈有时会出现在网络IO的处理上
• 所以为了提升网络IO的并行度，Redis6.0对于网络IO采用多线程来处理，对于命令的执行仍然使用单线程。
• Redis官方表示，Redis6.0版本引入多线程IO特性对性能提升至少是一倍以上。
• Redis6.0默认只针对发送响应数据采用IO多线程，并不会以多线程的方式处理读请求，可以在Redis.conf配置文件中进行开启，配置线程的个数。
• 官方建议，4核CPU线程数设置为2或3，8核CPU建议线程数设置为6，线程数需要小于机器核数

Redis持久化策略有几种?分别的优缺点是什么？

• Redis的读写操作都在内存，当Redis断电后，内存中的数据就会丢失，为了保证内存中的数据不丢失，Redis实现了数据持久化的机制，这个机制会把数据存储到磁盘。Redis提供AOF日志和RDB快照两种数据持久化方式

• AOF日志是指每执行一条写操作命令，以命令追写的形式写入到一个日志里

  • 

  • Redis提供了三种写回硬盘的策略，在Redis.conf配置文件中可以配置，分别是

    • Always：每次写操作命令执行完后同步将AOF日志数据写回硬盘；
    • EverySec：每次写操作之后，先将命令写入AOF文件内核缓冲区，每隔一秒将缓冲区里的内容写回硬盘；
    • NO：不由Redis控制写回硬盘的时机，转交给操作系统控制写回硬盘时机。
    • 

• RDB快照是指将某一时刻的内存数据，以二进制的方式写入磁盘。

  • 

  • RDB(数据快照模式)默认开启的时RDB模式：定期存储，保存的是数据本身，存储文件是紧凑的

    • save 900 1 #在900秒(15分钟)之后，如果至少有1个key发生变化，则dump内存快照。
    • save 300 10 #在300秒(5分钟)之后，如果至少有10个key发生变化，则dump内存快照。
    • save 60 10000 #在60秒(1分钟)之后，如果至少有10000个key发生变化，则dump内存快照。

  • 因为AOF日志记录的是操作命令，不是实际的数据，所以用AOF方法做故障恢复时，需要全量把日志都执行一遍，一旦AOF日志非常多，势必会造成Redis恢复操作缓慢，为了解决这个问题，Redis增加了RDB快照。

  • Redis提供了两个命令来生成RDB文件，分别是save和bgsave，他们的区别就在于是否在主线程里执行。

    • save命令会在主线程生成RDB文件，由于和执行操作命令在同一个线程，所以如果写入RDB文件的时间太长会阻塞主线程
    • bgsave命令会创建一个子线程来生成RDB文件，这样可以避免主线程阻塞。

• AOF的优点

  • 提供了更好的数据安全性，因为它默认每接收到一个写命令就会追加到文件末尾。即使Redis宕机也只会丢失最后一次写入前的数据。
  • AOF支持多种同步策略，可以根据需要调整数据安全性和性能之间的平衡。
  • AOF文件在Redis启动时可以通过重写机制优化减少文件体积，加快恢复速度
  • AOF文件即使发生损坏也可以使用Redis-Check-AOF工具来进行修复

• AOF的缺点

  • AOF记录了每一个写操作，所以AOF文件通常比RDB文件更大，消耗更多的磁盘空间。
  • 频繁的磁盘IO操作（尤其是同步策略设置为always时）可能会对Redis写入性能造成一定的影响。
  • 当单个AOF文件体积过大时，没有开启AOF重写或者重写频率较低可能会导致恢复过程慢

• RDB的优点

  • 通过快照保存某一时刻的数据状态，文件体积小，备份和恢复速度快
  • RDB是在主线程之外通过fork子线程来进行的，不会阻塞处理器处理命令请求，对Redis服务的性能影响小
  • RDB文件通常比AOF文件小得多

• RDB的缺点

  • RDB方式在两次快照之间，如果Redis服务器发生故障，这段时间的数据将会丢失
  • 在RDB创建快照到恢复期间有写操作，恢复后的数据可能与故障前的数据不完全一致

Redis的内存淘汰策略？

• Redis的内存淘汰策略是在内存满了的时候，Redis会触发内存淘汰策略来淘汰一些不必要的内存资源

  • Redis的内存淘汰策略有八种，大体分为不进行数据淘汰和进行数据淘汰两类策略
  • 

Redis的过期删除策略?

• Redis的过期删除策略是将已过期的键值进行删除，Redis采用的删除策略是惰性删除+定期删除这两种策略搭配和使用，以求在合理使用CPU时间和避免内存浪费之间取得平衡。

• 惰性删除策略：

  • 
  • Redis在访问或修改Key之前，会调用expireIfNeeded函数对其进行检查
  • 如果key过期则删除该key；如果没有过期则不做任何处理，然后返回正常的键值对给客户端

• 定期删除策略：

  • 
  • 在Redis中，默认每秒进行10次过期检查，每次随机从过期字典中抽取20个key
  • 检查这20个key是否过期，并删除已过期的key
  • 如果本轮检查的已过期key的数量超过5个，也就是已过期key的数量占随机抽取key的数量比例大于25%，则重复进行随机抽查步骤
  • 如果已过期的key比例小于25%，则停止继续删除过期key，等待下一轮检查
  • Redis为了保证定期删除不会出现循环过度导致线程卡死现象，增加了定期删除循环时间上限，默认不超过25ms

Redis集群模式了解吗?什么时候进入fail状态?为什么Redis最大槽数是16384？

• 当Redis缓存数据量大到一台服务器无法缓存时，就需要使用Redis Cluster切片集群方案，Redis Cluster切片集群方案将数据分布在不同的服务器上以此降低单节点的依赖，提高Redis服务的读写性能。

• Redis Cluster方案中，一个切片集群有16384个哈希槽，每个键值对都会根据key按照一定的算法分配到一个哈希槽中，具体执行过程如下：

  • 根据键值对的key，按照CRC16算法计算一个16bit的值
  • 用这个16bit的值对16383取模，得到0-16383范围的值并放入对应的哈希槽
  • 在使用cluster create命令创建Redis集群时，Redis会自动把所有哈希槽平均分布到集群节点上。比如集群中有9的节点，则每个节点上槽的个数为16384/9个

• redis集群去中心化：集群中所有的主节点都可以进行读写数据，不分主次，即Redis集群是去中心化的

• 集群进入fail状态的条件：

  • ①超过半数的主节点挂掉，无论是否有从节点。
  • ②集群中任意主节点挂掉，且没有任何从节点

• Redis最大的集群槽数是16384的原因：

  • 原因每个key通过CRC16校验后对16384取模来决定放入哪个槽，集群的每个节点负责一部分hash槽，CRC16算法产生的hash值有16bit，可以产生的值在0--65535之间。
  • 而redis节点间通信需要发送心跳包，16384=16k，使用char进行bigmap压缩后是2k，就是说使用2k的空间创建了16k的槽数
  • 如果是65535=65k，压缩后是8k，也就是说需要需要8k的心跳包。Redis的作者认为这样做不太值得；并且一般情况下一个redis集群不会有超过1000个master节点，所以16k的槽位是个比较合适的选择。

哨兵机制的原理是什么？

• 

• 在Redis的主从架构中，由于主从模式是读写分离的，如果master挂了，那么将没有master来服务客户端的写操作，也没有master给slave进行数据同步了。

• 这时需要恢复的话，需要人工进行切换，比较麻烦。因此在Redis2.8版本以后提供哨兵机制实现主从节点故障转移。哨兵节点会监测主节点是否存活，如果发现主节点挂了就会选举一个从节点切换为主节点，并且把新的主节点信息通知给从节点和客户端。

• 故障转移过程：

  • 
  • 假如主服务器宕机，哨兵A先监测到这个结果，系统并不会马上进行故障转移，仅仅是哨兵A主观认为主服务器不可用，这个现象称为主观下线；
  • 当后面的哨兵也检测到主服务器不可用结果时，数量超过一半时哨兵之间会进行一次投票，进行故障转移操作。转移成功后，哨兵会通过发布订阅模式，让各个哨兵把自己监控的从服务器实现切换主机，这个过程称为客观下线
  • 当哨兵节点判定为客观下线时，会进行故障转移，从Sentinel集群中选举出Sentinel Leader，由Sentinel Leader从Redis从节点中选举一个节点升级为主节点

为什么Redis比Mysql快？

• Redis是基于内存存储的NoSQL数据库，而Mysql是基于磁盘存储的关系型数据库。由于内存存储速度快，Redis能够更快的进行读取和写入数据，而无需像Mysql那样频繁的进行磁盘IO操作
• Redis采用单线程模型避免了多线程之间的竞争，省去多线程来回切换的开销
• Redis基于键值对存储，数据操作简单高效。而Mysql基于复杂的关系型数据结构，数据操作更复杂
• 单台设备的Redis的QPS是MySQL的10倍，Redis单机的QPS可以轻松突破10w，而MySQL单机很难突破1w

Redis应用场景有哪些？Redis分布式锁的实现原理？Redis实现分布式锁存在哪些问题？如何解决？

• 应用场景：

  • 在项目中我们常用的是作为缓存系统，缓存一些热点数据提供访问速度，减轻数据库压力；
  • Redis的有序集合结构非常适用于实现排行榜和排名系统，可以方便的进行数据排序和排名；
  • Redis中的SetNX也可以用来实现分布式锁，确保多个进程和服务之间数据操作的原子性和一致性；

• Redis分布式锁实现原理：

  • 分布式锁是用于分布式环境下并发控制的一种机制，用于控制某个资源在同一时刻只能被一个应用所使用
  • Redis本身可以被多个客户端共享访问，可以用来保存分布式锁。Redis中有个SetNX命令可以实现key不存在时插入，所以可以用SetNX来实现分布式锁。

• Redis实现分布式锁存在的问题：

  • xxxxxxxxxx
    // 出现死锁的情况，可以在设置锁的时候设置一个过期时间
    // 释放锁出现误删的问题，可以生成一个uuid，进行判断再删除
    
    // Q2: 删除分布式锁问题
    //     极端情况：
    //          A线程判断成功后，还未执行删除锁操作，锁恰好过期了；
    //          B线程获得分布式锁后，此时A线程开始执行删锁操作，把B线程的锁误删了
    答Q2：判断和删除要原子操作，这里采用LUA脚本保证判断锁和删除锁是一个原子性操作。
    
    // Q3: 分布式锁的过期时间问题：如果业务执行时间比我们预估的过期时间比要更长，此时会发生什么？
    //     极端情况：
    //         假设业务代码执行需要35s，过期时间我们设置为30s;
    //         线程A分布式锁在30s的时候就自动过期了
    //         此时B线程进来，AB两个进程操作就会存在依旧有共享资源的问题
    答Q3：采用Redisson来实现分布式锁，实现自动续期机制。Redisson是可重入锁，所以无需重试，当前线程重入了多少次就需要释放多少次，默认非公平加锁，此处不需要设置过期时间，有默认过期时间并且会续期。Redisson内部提供了一个监控锁的看门狗，在redisson被关闭之前，不断延长锁的有效期，默认情况下，看门狗检查锁的时间是30s，可以通过config.setLockWatchdogTimeout(30000)来设置redisson看门狗检查锁的超时时间，如果设置了过期时间，则无看门狗机制
    

如何保证Redis和mysql数据缓存一致性问题？

• 

• 对于读数据，如果Cache中不命中，会从DB加载数据到Cache。对于写数据，先更新数据库，再删除缓存。

• 根据C(一致性)A(可用性)P(分区容错性)理论，缓存是通过牺牲强一致性C来提高性能。缓存系统适用的场景就是非强一致性的场景，保证了C(一致性)A(可用性)P(分区容错性)理论中A(可用性)P(分区容错性)

• 所以使用缓存提升性能必定会有数据更新的延迟，这需要我们根据自身的业务对缓存的过期时间进行合理评估。缓存过期时间太短请求可能会比较多的落到数据库上，这也意味着失去了缓存的优势；缓存过期时间设置太长的话系统会长时间读取脏数据。

• 我们可以通过一些方案进行优化，达到最终一致性效果。

  • 

  • 问题：更新数据库成功，没来得及删除缓存或者删除缓存失败，那么其他线程从缓存中读取到的就是旧值，缓存不一致发生，怎么解决？

    • 可以引入消息队列，将删除缓存的操作加入到消息队列，由消费者进行删除。如果删除缓存失败，可以从消息队列中重新读取数据再次删除，失败重试达到一定次数向业务层报告错误信息
    • 订阅MySQL binlog，再操作缓存。先更新数据库，使用阿里巴巴开源中间件Canal监听数据库binlog变更日志后删除缓存，来达到数据最终一致性的效果
    • 对一致性要求不是很高的业务场景可以设置缓存过期时间，以后的操作只修改数据库，不操作缓存，等待缓存超时后从数据库重新读取

• 总结：删除缓存的两种方案：

  • 先删除缓存，再更新数据库。解决方案是使用延时双删
  • 先更新数据库，再删除缓存。解决方案是消息队列或者其他Binlog同步，引入消息队列会带来更多的问题，不推荐使用
  • 针对缓存一致性要求不是很高的场景，那么只通过设置缓存超时时间就可以了

缓存穿透、击穿、雪崩是什么?怎么解决?

• 缓存穿透：缓存穿透是指一个不存在的数据，由于缓存无法命中从而去查询数据库，但数据库中也没有此记录，没办法构建缓存数据来服务后续请求。当我们没有把查询到的null值存入缓存，导致每次查询这个数据都要去数据库查，失去了缓存这层保护当流量大时，DB就有可能会挂掉。有人会利用不存在的key频繁访问我们的数据库，导致我们的数据库宕机
• 解决方案： 当我们在数据库中查到值为null时，可以将null进行缓存，设置过期时间，一般不超过五分钟过期
• 缓存击穿：缓存击穿是指设置了过期时间的key，在某些时间这些key又是热点数据，被超高并发地访问在大量请求访问这个key的同时正好过期失效，那么所有的请求都会打到数据库上，导致缓存被击穿
• 解决方案：锁。
• 缓存雪崩：缓存雪崩是我们设置缓存的时候采用了相同的过期时间。当过期时间到了的时候，缓存会在某一时刻同时失效，请求全部打到DB上，DB瞬间压力过重导致雪崩
• 解决方案： 当我们在设置过期时间的时候，在原有的过期时间上再增加一个随机值，这样大量缓存同时过期的概率就会很低，很难引发集体key失效的事件

布隆过滤器的原理了解吗？

• 布隆过滤器是由一个位数组和若干个哈希函数组成，位数组是一个由0和1组成的数组，初始值都为0
• 当一个元素加入到布隆过滤器时，会通过多个哈希函数生成多个哈希值，然后将这些哈希值对应的位数组位置设置为1
• 当一个元素需要查询是否存在于布隆过滤器中时，也会通过多个哈希函数生成多个哈希值，然后查询这些哈希值对应的位数组是否都为1
• 若任意一个位数组位置不为1，那么该元素肯定不存在布隆过滤器中。如果所有的位数组位置都为1，那么该元素可能存在于布隆过滤器中，因为多个元素可能会被哈希到同一个位数组位置上，存在误判的情况。

八、RabbitMQ

消息中间件使用场景？

• 流量削峰。在并发请求下，使用中间件，用户先访问中间件再去访问实际接口，使用中间件把这些请求进行排队处理，防止高并发带来的服务器宕机等问题
• 解耦。在我们系统与系统之间的调用过程中，如果调用链路过长，中途某一个环节出现问题都会导致整个接口异常，容易造成雪崩现象。当我们使用消息中间件后，系统之间的调用问题就会减少很多。比如下单过程中，需要调用物流系统、库存系统、积分系统。我们可以将发货、减库存、加积分等操作写入消息中间件，让其他服务进行监听来达到服务之间的一个解耦。
• 异步。我们可以使用消息中间件来将同步调用的过程改为异步执行，来提高程序执行效率。如果一个注册功能，我们需要写数据库，也需要发验证码。我们可以将这两个过程并行执行。等到他们都执行成功了再返回给客户端。

五种基本的消息模式?

• 简单模式：一个生产者、一个消费者，不需要设置交换机（使用默认的交换机）
• 工作模式：一个生产者、多个消费者（竞争关系），不需要设置交换机（使用默认的交换机）
• 发布订阅模式：需要设置类型为fanout的交换机，并且交换机和队列进行绑定，当发送消息到交换机后，交换机会将消息发送到绑定的队列
• 路由模式：需要设置类型为direct的交换机，交换机和队列进行绑定，并且指定routing key，当发送消息到交换机后，交换机会根据routing key将消息发送到对应的队列
• 主题模式：需要设置类型为topic的交换机，交换机和队列进行绑定，并且指定通配符方式的routing key，当发送消息到交换机后，交换机会根据routing key将消息发送到对应的队列

交换机的种类有几种?常用的几种?

• Fanout广播
• Direct定向
• Topic通配符

什么叫死信队列和死信交换机?

• 死信队列指的是消息在队列上无法被消费，消息成为死信消息，队列也就自然称为死信队列了
• 当消息成为死信后，如果该队列绑定了死信交换机，则消息会被死信交换机重新路由到队列

什么叫ttl?

• TTL可以指消息的存活时间，当消息到达存活时间后，还没有被消费，会被自动清除
• 也可以指队列的存活时间，当队列到达存活时间后，消息会重新发布到绑定的死信交换机

延迟队列的原理?

• 延迟队列由生产者->正常交换机->死信队列->死信交换机->正常队列->消费者组成
• 当消息到达死信队列，由于死信队列设置TTL，TTL到期时，消息会被交换机重新路由到队列由消费者消费
• 所谓的延迟时间就是TTL

消息成为死信的条件?

• 消息TTL到了，消息过期
• 队列长队满了
• 消费者拒绝消费，并且不把消息放回队列

如何保证消息不丢失?

• 生产者先发送消息到交换机，在发送给消息队列，这个链路中每个过程都有可能出错，导致消息没有正常发送

• RabbitMQ有两种方式来控制消息的可靠性。分别是ConfirmCallback机制和ReturnCallback机制。

  • 
  • confirm确认机制：消息一旦从生产者发送到MQ server，也就是交换机接收到，这个时候会触发一个回调ConfirmCallback，代表MQ服务接收到了消息，这个回调函数一定会执行
  • return回退模式：交换机把消息路由到队列时一旦出现问题，则会触发ReturnCallback回调，只有失败时才会触发这个函数。

• 生产者：开启消息的确认机制。确保消息到达RabbitMQ

  • xxxxxxxxxx
    publisher-confirm-type: correlated    # 发布消息成功到交换器后会触发回调方法
    publisher-returns: true               # 交换机发送消息到队列后会触发回调方法
    

• RabbitMQ：开启RabbitMQ持久化，交换机设置持久化、队列设置持久化、消息持久化，设置发送模式deliveryMode=2，代表持久化消息

• 消费者：ACK确认机制。关闭rabbitMQ的自动ACK，改为手动，这样可以避免消息还没处理完就ACK。

如何防止消息堆积/累计?

• 设置并发消费两个关键属性concurrentConsumers和prefetchCount
• concurrentConsumers设置的是对每个listener在初始化的时候设置的并发消费者的个数
• prefetchCount是每次一次性从broker里面取的待消费的消息的个数
• 启动的时候会根据设置的concurrentConsumers创建N个BlockingQueueConsumer（N个消费者）
• prefetchCount是BlockingQueueConsumer内部维护的一个阻塞队列LinkedBlockingQueue的大小，其作用就是如果某个消费者队列阻塞，就无法接收新的消息，该消息会发送到其它未阻塞的消费者

集群分为几种?有什么区别?

• 普通集群：默认的集群模式，某个节点挂了，该节点上的消息就不可用了，受影响的业务瘫痪，只能等待节点恢复重启可用（必须持久化消息情况下）

• 镜像集群：把需要的队列做成镜像队列，存在于多个节点，属于RabbitMQ的HA方案，三种HA策略模式：

  1）同步至所有的 2）同步最多N个机器 3）只同步至符合指定名称的nodes

  HA 镜像队列有一个很大的缺点就是： 系统的吞吐量会有所下降

什么叫幂等性?幂等性问题如何解决?

• 幂等性是指同一操作发起的一次或多次请求的结果是一致的，不会由于多次点击而产生副作用

RabbitMQ怎么防止重复消费？

• 网络延迟传输中，消费者出现异常或者消费者延迟消费，会造成进行MQ重试补偿，在重试过程中，可能会造成重复消费。

  • 你拿到这个消息做数据库的insert操作。那就容易了，给这个消息做一个唯一主键，那么就算出现重复消费的情况，就会导致主键冲突，避免数据库出现脏数据。
  • 再比如，你拿到这个消息做redis的set的操作，那就容易了，不用解决，因为你无论set几次结果都是一样的，set操作本来就算幂等操作。
  • 可以使用用一个消息状态表，用来记录消息处理状态，每次消费前都去消息状态表中查询一次，如果已经有相同的消息存在，那么不处理

九、ElasticSearch

什么是正排索引？什么是倒排索引？

• 顺序扫描法：要找内容包含某一个字符串的文件，就是一个文档一个文档的看，对于每一个文档，从头看到尾，如果此文档包含此字符串，则此文档为我们要找的文件，接着看下一个文件，直到扫描完所有的文件。
• 正向索引： 给每一个文档编一个序号，一个序号对应这个文档的所有关键词，当我们查找某个关键字时需要遍历所有的文档，查询效率非常慢
• 倒排索引： 而倒排索引会先对所有的文档进行分词，建立关键词到文档id的映射，根据关键词，可以快速获取包含这个关键词的所有文档
• 正向索引和倒排索引总结：正向索引：文档ID-->文档的所有关键字，倒排索引：关键字-->包含这个关键字的所有文档

十、zookeeper

• Zookeeper的工作机制？应用场景？ZK的特点是什么?

  • ZK从字母意思去理解就是动物管理员，是一个分布式环境协调组件。

  • ZK可以说是一种以观察者模式对节点中数据进行监听，如果节点数据发送变化，则发起事件变更通知。

  • 应用场景：

    • ZK可以作为注册中心
    • kafka和netty等都是依赖ZK实现了集群
    • 可以充当分布式配置中心，统一对配置进行管理
    • MQ消费者处理完毕也可以通过ZK回写通知给生产者告知结果

  • ZK的特点

    • ZK集群由一个leader和多个follower组成
    • ZK集群中只要有半数节点存活，那么整个集群可以正常对外提供服务
    • ZK每个节点数据全部都是强一致的，ZK满足CP类型的架构
    • ZK可以保证自身事务的顺序一致性，ZK会使用递增的事务ID也就是zxid来标识事务

• zookeeper中什么叫临时节点?永久节点?顺序节点？

  • ZK中临时节点是指当客户端与ZK服务断开连接后，用户创建的节点会自动删除，只要当前会话不存在了，该节点也就消失了
  • ZK中永久节点是指一旦节点创建，该节点永久存在，除非手动删除
  • 默认创建的永久节点，创建临时节点可以在后面加上 -e 参数
  • 顺序节点是指同一个节点可以创建多个，可以在后面加上 -s 参数创建

• zookeeper如何进行数据同步?

• zookeeper如何实现分布式锁?

  • ZK实现分布式锁的核心原理是同一个节点只能被创建一次，如果第二个用户无法创建，表示当前业务被其他用户锁住了，直到第一个用户删除节点释放锁才能让后续线程创建新的锁

  • 具体步骤：

    • 多个客户端同时获得锁，创建Lock节点，这个Lock节点是临时顺序节点，临时是为了避免死锁，顺序是为了用于判断最小的获得当前锁
    • 客户端获取当前Lock节点下的所有子节点，判断哪个节点的顺序值是最小的，如果是最小的说明是最先创建的节点，也就是第一个获得锁的，此时这个客户端表态获得了锁，使用完毕释放删除锁
    • 其他客户端在判断的时候，发现自己并非最小顺序，所以需要等待释放锁之后，再次去获得锁，这个时候创建监听器，用于监听最小顺序节点的删除事件
    • 当第一个客户端删除节点之后，其他客户端会收到删除锁节点的事件通知，此时再判断自己是否是当前的最小顺序，如果是则获得锁，如果不是则继续等待

十一、数据结构

冒泡排序算法

xxxxxxxxxx
    /**
     * 对整数数组进行冒泡排序的测试方法。
     * 冒泡排序是一种简单的排序算法，它重复地遍历要排序的数列，一次比较两个元素，
     * 如果它们的顺序错误就把它们交换过来。遍历数列的工作是重复地进行直到没有再需要交换，
     * 也就是说该数列已经排序完成。
     */
    @Test
    public void popSort() {
        // 待排序的整数数组
        int[] arrays = {1, 10, 7, 8, 9, 4};

        // 外层循环控制遍历的次数
        for (int i = 0; i < arrays.length - 1; i++) {
            // 内层循环进行相邻元素的比较和交换
            for (int j = i + 1; j < arrays.length; j++) {
                // 如果前一个元素大于后一个元素，则交换它们的位置
                if (arrays[i] > arrays[j]) {
                    int temp = arrays[i];
                    arrays[i] = arrays[j];
                    arrays[j] = temp;
                }
            }
        }
        // 打印排序后的数组
        log.info(Arrays.toString(arrays));
    }

快速排序算法

xxxxxxxxxx
    /**
     * 快速排序测试方法
     */
    @Test
    public void quickSort() {
        int[] arr = {3, 7, 8, 5, 2, 1, 9, 5, 4}; // 待排序数组
        quickSort(arr, 0, arr.length - 1); // 调用快速排序方法
        log.info(Arrays.toString(arr)); // 输出排序后的数组
    }

    /**
     * 快速排序方法
     *
     * @param arr   待排序数组
     * @param left  排序部分的左边界
     * @param right 排序部分的右边界
     */
    private void quickSort(int[] arr, int left, int right) {
        if (left < right) {
            int pivotIndex = partition(arr, left, right); // 获取分区后的基准元素索引
            quickSort(arr, left, pivotIndex - 1); // 对基准元素左边的子数组进行快速排序
            quickSort(arr, pivotIndex + 1, right); // 对基准元素右边的子数组进行快速排序
        }
    }

    /**
     * 分区方法，用于将数组分区，并返回基准元素的索引
     *
     * @param arr   待分区数组
     * @param left  分区的左边界
     * @param right 分区的右边界
     * @return 基准元素的索引
     */
    private int partition(int[] arr, int left, int right) {
        int pivot = arr[right]; // 选择最右边的元素作为基准元素
        int i = left - 1;
        for (int j = left; j < right; j++) {
            if (arr[j] <= pivot) { // 如果当前元素小于或等于基准元素，则交换
                i++;
                swap(arr, i, j);
            }
        }
        swap(arr, i + 1, right); // 将基准元素放到正确的位置
        return i + 1;
    }

    /**
     * 交换数组中两个元素的位置
     *
     * @param arr 待交换元素的数组
     * @param i   第一个元素的索引
     * @param j   第二个元素的索引
     */
    private void swap(int[] arr, int i, int j) {
        int temp = arr[i];
        arr[i] = arr[j];
        arr[j] = temp;
    }

十二、项目相关

xxxxxxxxxx
熟练掌握Java基础，理解OOP编程思想，对类的加载机制、集合、多线程、IO流、反射、泛型、JAVA8新特性有深入的理解，具备良好的编码习惯。
熟练掌握SpringMVC、Spring、MyBatis三大框架整合，理解SpringMVC的运行流程，理解Spring框架IOC和AOP两大核心思想，能够使用MyBatis逆向工程和通用Mapper快速高效开发。
熟练使用MySQL数据库及JDBC编程事务，了解数据库的四种隔离级别，可解决脏读、幻读、不可重复读等问题，可保证数据库事务的ACID特性，具备Explain查看SQL语句执行流程，并建立高效索引对SQL语句进行优化。
熟练使用非关系型数据库Redis作为缓存工具，熟悉常用的数据类型及其使用场景，理解持久化、主从复制、Cluster等机制，能够基于Redis实现分布式锁、并解决缓存穿透、缓存雪崩、缓存击穿等缓存常见问题。
熟练使用SpringBoot、SpringCloud搭建微服务架构，理解SpringBoot自动化配置原理及独立打包部署，掌握SpringCloud中Eureka、Ribbon、Hystry、Feign、Gateway等组件的使用。
熟练使用ElasticSearch作为模板引擎，理解倒排索引原理，能够使用IK分词器对关键字进行匹配搜索，能够使用Kibana远程测试并调优DSL语句。
熟练使用RabbitMQ作为消息中间件，实现系统间的异步消息管理，了解死信队列、延迟队列等机制，能够基于RabbitMQ实现分布式事务。
熟悉JAVA并发包下常用工具类的使用，了解常用的锁机制以及CAS原理。
熟悉JVM内存模型和GC回收机制，了解对JVM内存空间及GC算法相关参数进行调优。
熟悉Docker容器技术，能够基于Docker对常用组件进行安装部署。
能够使用Git进行项目版本管理，使用Maven进行项目依赖管理及构建。
熟练掌握Linux常用命令，Docker容器化技术，能够基于Linux安装常用组件。
了解HTML、CSS、JavaScript、Vue、Thymeleaf等前端开发技术。


（一）招聘云SaaS系统
项目描述：
        招聘云SaaS系统分为用户平台、企业管理平台、运营管理平台三大平台。整个项目基于微服务进行开发，项目分为用户服务、文件服务、简历服务、聊天服务、工作服务、企业服务、招聘服务、鉴权等多个微服务。整个项目采用前后端分离模式进行开发。
核心技术：SpringBoot、SpringCloud、Mybatis-Plus、MySQL、Redis、SpringSecurity、RabbitMQ、Elasticsearch、Canel、Zookeeper、OpenResty、ELK等
项目架构：
  1.网关接入层采用云负载均衡器CLB，Nginx网关层采用OpenResty多级缓存架构，微服务网关集群采用SpringCloud GateWay进行统一搭建；
  2.基于Nacos作为服务的注册中心和动态配置中心，对各个微服务进行统一的管理与配置；
  3.基于SpringBoot+SpringCloud开发，采用OpenFeign进行服务间的RESTFul通信；
  4.项目前后端分离，基于SpringSecurity+JWT进行授权认证，RBAC权限模型进行设计；
  5.数据库采用MySQL搭建，MyBatis-Plus作为微服务持久层框架进行数据操作；
  6.分布式缓存采用Redis，本地缓存基于Caffeine，采用MongoDB作为非关系型数据库进行信息快照的处理；
  7.消息队列采用RabbitMQ作为消息中间件，实现异步解耦、延迟队列等功能；
  8.基于Zookeeper进行分布式协调处理，实现了节点的动态监听和动态配置；
  9.项目基于ELK等工具对日志进行收集、分析和可视化；
主要职责：
1.负责注册登录业务的开发。完成APP手机端一键注册登录、用户扫码登录、加盐登录等功能的开发，集成第三方短信SDK，基于RabbitMQ实现短信的异步发送，生成二维码令牌供用户进行扫描，用户扫码后生成预登录令牌并定期检查扫码状态完成登录页面跳转。

2.参与鉴权服务的开发。基于RBAC用户角色接口访问权限控制管理端脚手架开发，并应用于多个业务系统。支持动态URL权限认证，基于Redis解决JWT无法手动设置过期时间的弊端，保证同一用户在用一时间仅支持同一设备登录，以及在线人数统计、强制下线等功能的开发。

3.负责简历服务的开发。新用户简历初始化。借助本地消息表记录消息+ThreadLocal本地线程储存消息ID，自定义事务管理器批量发送消息至RabbitMQ，并手动ACK确认机制保证消息的可靠性投递，解决分布式事务数据的一致性问题；缓存用户简历信息进Redis，提升App端接口查询的性能，并解决缓存穿透、击穿、雪崩等问题。

4.负责企业服务的开发。完成三级行业分类树功能的开发，结合RabbitMQ延迟队列批量更新行业分类缓存数据，优化了缓存同步策略；完成数据字典相关接口的开发，基于CompletableFuture多线程异步编排优化数据字典查询接口，提升了接口的访问性能，并结合Canel异步监听数据变更实现缓存数据的同步刷新。

5.参与工作服务的开发。SpringBoot自启动时将系统配置提前进行缓存预热，结合Caffeine本地缓存+OpenResty共享字典缓存+Redis分布式缓存+Lua脚本实现多级缓存架构，将缓存前置网关，提升简历刷新接口响应时间50%，并基于CuratorZK实现服务集群节点的动态监听，实现缓存数据的同步。

6.参与检索服务的开发。基于RabbitMQ将简历信息同步至Elasticsearch，基于IK分词器对关键词进行匹配搜索，整合Elasticsearch实现了简历的复杂搜索，提升了检索效率。对数据可视化业务进行分析，基于Aggs统计聚合实现不同维度图表的数据可视化功能。

注册登录业务的开发？如何设计的？

• 运营管理平台通过超级管理员Admin在后台添加用户，分配角色和权限点，登录时校验用户名和密码，生成带有平台前缀的JWT返回给前端

• APP用户我们是使用短信一键注册登录，若用户没有注册过，对用户手机验证码校验通过后创建一个新用户并初始化用户简历信息。同时生成带有平台前缀的JWT令牌返回给前端；若用户注册过，则直接返回用户信息和令牌给前端

• 企业SAAS管理平台通过APP端扫码登录，扫码登录设计流程如下：

  1. 首次进入或者刷新页面，后端生成唯一的qrToken写入Redis，同时标记当前qrToken未被扫码读取；
  2. app端扫码成功时，检验app端的token令牌是否OK。如果没问题，后端会标记qrToken已被app读取，并且生成preToken写入redis返回给前端。
  3. 前端页面会每隔3秒定时去查询qrToken是否被扫码的标记，用于页面判断
  4. 用户在app端点击确认登录后，前端携带pre_token与Redis中的preToken进行比对，如果比对成功则登录成功，将用户信息暂时存入Redis中
  5. 在用户登录成功后页面刷新时生成带有平台前缀的JWT返回给前端。

鉴权服务的开发？什么是RBAC？如何实现动态URL权限认证？怎么保证同一时间仅支持同一设备登录？在线人数统计？强制下线功能？

• RBAC也叫基于角色的访问控制，抽象的概括就是谁是否可以对什么内容进行怎样的访问操作

• 在RBAC模型中，有三个基础组成部分，分别是用户、角色和权限。在项目中，我们设计了用户表、角色表、权限表。表与表通过中间表进行关联。一个用户可以分配多个角色，一个角色下可以分配多个权限。实现根据用户的角色来判断用户是否有权限访问特定资源的操作。具体操作步骤如下：

  • 验证请求是否存在以及请求方法是否正确
  • 查询当前用户的按钮级别的权限列表，由于我们的项目是前后端分离的项目，所以只有按钮级别的权限需要控制
  • 若当前请求URL和方法在这个权限列表中则放行，否则不放行。

• 由于JWT无法手动失效，因此在项目中我们引入Redis存放JWT，在过滤器中会将当前请求的JWT与Redis中的JWT进行比对，若不一致则代表用户已注销或者用户在不同平台进行登录。以此来达到同一时刻仅支持同一设备进行登录的效果。

• 在线人数统计只需要根据JWT相关的键查询用户名列表，然后根据用户名列表查询在线用户返回给前端

• 强制下线功能主要根据前端传过来的用户列表，清除Redis中与这些用户列表相关的JWT信息即可

简历服务的开发？怎么解决分布式事务数据一致性问题？缓存穿透、击穿、雪崩问题如何解决的？

• APP用户一键注册以后，需要初始化用户信息和简历，但由于我们的服务是微服务项目，根据单一职责的业务划分，用户服务和简历服务分别处于两个微服务。因此出现了分布式事务问题。
• 我们定义一个消息记录表记录本地消息，并且将本地消息ID保存到ThreadLocal中
• 通过自定义事务管理器，在用户微服务进行用户信息初始化事务提交后，根据ThreadLocal中的消息ID查询本地消息记录进行批量发送消息到RabbitMQ
• 简历服务监听成功后对当前用户简历进行初始化操作
• 并且我们保证了消息的可靠性投递，在消费端开启手动ACK确认机制保证消息的可靠性
• 查询简历时，我们使用Redis对用户简历信息进行缓存，第一次查询走数据库进行查询，将数据库查询的结果缓存进Redis，以此提高App接口的查询性能，并解决了缓存穿透、击穿、雪崩问题。

企业服务的开发？三级行业分类树如何设计？采用了哪种缓存同步策略？数据字典缓存为什么要使用Canel监听？

• 在我们企业服务的开发中，我们的三级行业分类采用了RabbitMQ延迟同步缓存策略。
• 当我们后台运营端修改行业分类数据时，我们会在修改后的次日凌晨3点进行缓存刷新
• 之前我们的做法是在每次更新行业分类数据时对缓存进行延迟双删，但由于这个延迟时间不好评估，并且对代码侵入性太高
• 根据我们的业务，三级分类数据实时性要求并不是很高，因此我们后面采用了统一次日凌晨刷新缓存策略。
• 由于我们的数据字典查询接口涉及到多个字典项，比如企业性质、公司优势、人员规模等，每次查询都要同步进行查询字典列表然后再组装成VO返回给前端，这个过程其实是可以异步化的，我们基于CompletableFuture多线程异步编排机制，对多个字典项查询进行异步编排，提高数据查询效率。
• 我们给数据字典数据做了一个缓存预热机制，在我们项目启动的时候会触发数据字典预热。并且我们也给运营管理端提供数据字典缓存预热按钮，运营人员可以手动点击按钮刷新数据字典缓存。在每次数据字典发生数据变更时，我们使用第三方中间件Canel对数据字典表进行监听，同步完成数据字典缓存数据的刷新。

工作服务的开发？为什么要引入多级缓存架构？如何设计与实现的？

• xxxxxxxxxx
  参与工作服务的开发。SpringBoot自启动时将系统配置提前进行缓存预热，结合Caffeine本地缓存+OpenResty共享字典缓存+Redis分布式缓存+Lua脚本实现多级缓存架构，将缓存前置网关，提升简历刷新接口响应时间50%，并基于CuratorZK实现服务集群节点的动态监听，实现缓存数据的同步。
  

• 缓存是为了降低数据库崩溃的风险，但当我们流量激增的时候，达到千万级甚至亿级别流量时，缓存失效的情况下瞬间高并发流量会直接击穿数据库，因为我们的防护屏障只有Redis这一层，因此我们引入了多级缓存架构，更好的保护系统的抗风险能力。

• 多级缓存架构的本质就是在请求的各个节点处添加缓存，分摊tomcat的压力来提升整体的接口访问性能，因此我们引入了多级缓存架构

• 设计与实现

  • 在网关层面：

    • 由Nginx入口网关反向代理到OpenResty网关集群，在网关OpenResty中结合Lua实现对Redis的操作，如此就可以在网关层实现Redis缓存，将缓存前置，分摊了单个tomcat的并发性能瓶颈。并且我们也开启了网关中的本地缓存共享词典。以此形成多级网关缓存架构。
    • 我们由一级网关转发到二级OpenRestry网关集群，在OpenResty中会先查询Nginx本地缓存和Redis，若命中则直接在网关层面返回给客户端即可，若Nginx本地缓存和Redis都未命中则向微服务进行转发
    • 请求转发到微服务后，Redis中必定会有缓存值（因为在我们工作服务启动时，会将简历的最大刷新次数预热到Redis和ZK节点中，同时ZK会动态监听当前节点的数据，同步变更Caffeine本地缓存）
    • 查询到Redis中最大刷新次数再设置到Nginx本地缓存中

  • 在微服务层面：

    • 在业务代码层面我们只需要从Caffeine本地缓存中获取简历最大刷新次数，若没有则从Redis和ZK中获取即可
    • 在用户点击刷新简历后，我们更新数据库中用户刷新简历的最新时间，并且修改Redis中用户当天的刷新次数。同时会发送消息至RabbitMQ，将用户简历数据刷新至ES。
    • 当我们的运营端修改简历最大刷新次数时，会把数据携带版本号保存到ZK节点中，此时各个微服务节点监听到数据变动会更新各自的本地缓存。同时更新Redis中值。
    • 并且我们做了一个数据的一致性校验，发送延迟消息来校验数据的一致性，使得数据库、Redis、ZK这三者的数据最终达到一致。
    • 运营端查询最大简历刷新次数时，会从ZK中获取简历最大刷新次数，因为在我们项目启动的时候，简历最大刷新次数已经进行了预热

项目亮点是什么？你在项目中遇到的难点？怎么解决的？

• 我们项目的亮点就是引入了多级缓存架构，同时也引入了多级网关缓存分摊为服务集群的压力

• 遇到的难点

  • 因为在我们APP端，求职者可能有意无意的点击刷新简历按钮，刷新简历的这个接口并发是很大的，起初我们没有引入多级缓存架构的时候，我们只有一层Redis缓存，当用户集中式的点击刷新简历按钮，我们项目的QPS始终上不去。后面对这一块进行了分析优化，我们的流量起初是要先经过我们的微服务，单个微服务tomcat在优化不错的情况下并发撑死了也就200，因此我们定位到QPS上不去的瓶颈在于tomcat
  • 起初我们尝试对tomcat做了优化，但效果不是很明显，后来想着我们的流量大部分是落在缓存上，现在问题出在服务流量上不去，何不将缓存前置，因此我们想到了OpenResty结合Lua，将缓存前置网关。并且我们的防护只有单层Redis，当高并发流量瞬间进来，容易造成Redis的击穿，缓存这层我们保护的不够周全
  • 因此我查阅了很多资料，学习了LUA语言、了解到OpenResty是一个基于Nginx的高性能Web平台，可以结合Lua进行自定义网关逻辑，并积极与小组成员讨论，真正实践落地运用到我们的项目当中。

电商库存系统的防超卖和高并发扣减方案

• 方案一：传统通过数据库保证不超卖

  • 使用数据库的事务保证。通过SQL判断剩余库存数量是否够用，多个并发执行update语句只有一个能执行成功
  • 同时为了保证扣减不重复，会配合一个防重表来防止重复提交，做好幂等性
  • 缺点：面临系统流量大，数据库会有性能瓶颈问题。

• 方案二：分离防超卖和数据持久化

  • 扣减库存其实包含两个过程：第一步是超卖校验，第二步是扣减库存数据的持久化

  • 实现原理是分离开防超卖和数据持久化，防超卖过程由Redis来完成，

    • 我们可以使用Redis中Hash结构的hincrby命令来进行库存的扣减

      xxxxxxxxxx
      127.0.0.1:6379> hset iphone inStock 1 #设置苹果手机有一个可售库存
      (integer) 1
      127.0.0.1:6379> hget iphone inStock   #查看苹果手机可售库存为1
      "1"
      127.0.0.1:6379> hincrby iphone inStock -1 #卖出扣减一个，返回剩余0，下单成功
      (integer) 0
      127.0.0.1:6379> hget iphone inStock #验证剩余0
      "0"
      127.0.0.1:6379> hincrby iphone inStock -1 #应用并发超卖但Redis单线程返回剩余-1，下单失败
      (integer) -1
      127.0.0.1:6379> hincrby iphone inStock 1 #识别-1，回滚库存加一，剩余0
      (integer) 0
      127.0.0.1:6379> hget iphone inStock #库存恢复正常
      "0"
      

    • 保证扣减的幂等性，通过订单号和商品防重码是否存在来决定是否扣减成功，通过setNX命令来决定扣减是否成功。

      xxxxxxxxxx
      // 初始化库存
      127.0.0.1:6379> hset iphone inStock 1 #设置苹果手机有一个可售库存
      (integer) 1
      127.0.0.1:6379> hget iphone inStock   #查看苹果手机可售库存为1
      "1"
      // 应用线程一扣减库存，订单号a100，jedis开启pipeline
      127.0.0.1:6379> set a100_iphone "1" NX EX 10 #通过订单号和商品防重码
      OK
      127.0.0.1:6379> hincrby iphone inStock -1 #卖出扣减一个，返回剩余0，下单成功
      (integer) 0
      //结束pipeline，执行结果OK和0会一起返回
      

    • 并发扣减后检验。为了防止并发扣减，需要对Redis的hincrby命令返回值是否为负数来判断是否发生高并发超卖，如果扣减后的结果为负数，需要反向执行hincrby把数据进行加回

    • 单向保证。很多极端场景中，很难做到不超卖和少卖。我们选择不超卖单向保证，尽可能较少少卖概率。比如如果扣减Redis过程中，设置防重码成功，由于网络抖动扣减失败，重试的时候就会认为成功造成超卖。

      • 扣减库存，顺序为：1.扣减库存，2.写入防重码
      • 回滚库存，顺序为：1.写入防重码，2.扣减库存

  • 通过Redis防超卖后，由任务引擎扣减库存，任务引擎通过订单号进行分库分表，将热点商品的落库分散开，消除数据库的热点。