Java面试题库整理

Collection接口的字接口

Map接口

Iterator

实现了RandomAccess接口的集合都可以做到随机访问，该接口是一个标记接口，未定义任何方法
以下这些集合都实现了List接口，而List接口提供了对元素的随机访问。

ArrayList：ArrayList是基于数组实现的动态数组。由于其内部数据结构是数组，因此可以通过索引快速访问元素。

Vector：Vector与ArrayList类似，也是基于数组的动态数组。不过Vector是线程安全的，支持同步，但因此可能性能稍差。  所有的public 方法加了synchronized 关键字

LinkedList：虽然LinkedList也可以通过索引访问元素，但它的访问效率较低，因为它是基于链表实现的，需要遍历链表来找到指定索引的元素。

Comparable是一个接口，位于 java.lang 包中。
内部只有一个方法compareTo，该方法返回一个整数值。可以实现对类对象的比较，升序。
自然排序是对象本身所具有的默认排序规则。
当使用 Arrays.sort() 或 Collections.sort() 这样的排序方法时，它们会使用对象的 compareTo 方法进行排序。

Comparator是一个接口，java.util包下的，在类外部定义排序规则。
传入各种自定义排序规则的 Comparator 实现类，对同样的类制定不同的排序策略。
Comparator 接口有一个 compare 方法，用于比较两个对象。
使用 Comparator 时，你需要在排序时显式指定要使用的比较器。

总的来说，Comparable 用于为对象定义默认的自然排序，而 Comparator 用于在不修改类定义的情况下进行自定义排序。你可以根据需要选择使用哪种接口来实现对象的比较。

Collection是一个接口，是各种集合类的父接口

Collections是一个工具类，包含有各种有关集合操作的静态方法，像synchronized方法提供了线程安全的集合，sort对集合进行排序

Enumeration速度是Iterator的2倍，同时占用更少的内存。

Iterator远远比Enumeration安全，因为其他线程不能够修改正在被iterator遍历的集合里面的对象。

Enumeration 位于 java.util 包中，定义在 java.util.Enumeration 接口中。
它只包含两个方法：hasMoreElements() 和 nextElement()。
Enumeration 是只读的，不支持对集合进行修改操作，只能用于遍历元素。

Iterator 位于 java.util 包中，定义在 java.util.Iterator 接口中。
它包含三个方法：hasNext()、next() 和 remove()（remove 方法用于从集合中删除当前元素，是可选操作）。
Iterator 是支持对集合进行修改操作的，可以通过 remove 方法删除元素。

所有集合接口和实现都大量使用它，泛型允许我们为集合提供一个可以容纳对象类型。泛型可以使得代码更加简洁，不需要显示转化和instanceOf操作，也给运行时带来好处，不会产生类型检查的指令

首先Map提供的是键值对映射（即Key和value的映射），而collection提供的是一组数据（并不是键值对映射）

map如果继承了collection接口的话还违反了面向对象的接口分离原则。

Map和List、set不同，Map放的是键值对，list、set放的是一个个的对象。说到底是因为数据结构不同，数据结构不同，操作就不一样，所以接口是分开的

接口分离原则：客户端不应该依赖它不需要的接口。

Collections里面提供了synchronizedMap

HashTable

ConcurrentHashMap

ConcurrentHashMap的子类

简介

原理

HashSet

线程是否安全：HashMap 是非线程安全的，HashTable 是线程安全的,因为 HashTable 内部的方法基本都经过synchronized 修饰。

因为线程安全的问题，HashMap 要比 HashTable 效率高一点。

HashMap 可以存储 null 的 key 和 value，但 null 作为键只能有一个，null 作为值可以有多个；HashTable 不允许有 null 键和 null 值，否则会抛出 NullPointerException。

创建时如果不指定容量初始值，Hashtable 默认的初始大小为 11，之后每次扩充，容量变为原来的 2n+1。HashMap 默认的初始化大小为 16。之后每次扩充，容量变为原来的 2 倍。

创建时如果给定了容量初始值，那么 Hashtable 会直接使用你给定的大小，而 HashMap 会将其扩充为 2 的幂次方大小

JDK1.8 以后的 HashMap 在解决哈希冲突时有了较大的变化，当链表长度大于阈值（默认为 8）（将链表转换成红黑树前会判断，如果当前数组的长度小于 64，那么会选择先进行数组扩容，而不是转换为红黑树）时，将链表转化为红黑树，以减少搜索时间。Hashtable 没有这样的机制。

1.7 ： 对线程对Map进行扩容。某个线程执行过程中，被挂起，其他线程已经完成数据迁移，等CPU资源释放后被挂起的线程重新执行之前的逻辑，数据已经被改变，造成死循环、数据丢失。头插法会导致死循环

1.8 :  对线程put操作。假设两个线程A、B都在进行put操作，并且hash函数计算出的插入下标是相同的，当线程A执行完第六行代码后由于时间片耗尽导致被挂起，而线程B得到时间片后在该下标处插入了元素，完成了正常的插入，然后线程A获得时间片，由于之前已经进行了hash碰撞的判断，所有此时不会再进行判断，而是直接进行插入，这就导致了线程B插入的数据被线程A覆盖了，从而线程不安全。

1.7 到 1.8 的改善：数据丢失、死循环已经在在JDK1.8中已经得到了很好的解决，如果去阅读1.8的源码会发现找不到HashMap#transfer()，因为JDK1.8直接在HashMap#resize()中完成了数据迁移。

体现

1.7

1.8

线程安全

空键或空值

性能和并发性

迭代器

LinkedList是实现了List接口和Deque接口的双端列表。其底层的链表结构使得它支持高效的插入和删除操作。同时实现了Deque接口，使得LinkedList具有队列的特性。队列不是线程安全的，如果需要变成线程安全的，可以调用静态类Collections中的synchronizedList方法

Collections中的synchronizedList方法 返回的是Collections中的子类，其实就是提供的方法都加上synchronized关键字

private static class Node<E> {
        E item;//节点值
        Node<E> next;//后继节点
        Node<E> prev;//前驱节点

        Node(Node<E> prev, E element, Node<E> next) {
            this.item = element;
            this.next = next;
            this.prev = prev;
        }
    }

注：虽然说删除、插入操作高效，只是删除这个动作比较高效，前置查找定位也需要O(n)的复杂度，只不过LinkedList不需要检验扩容操作

扩容机制

关键参数

思考

ArrayList

LinkedList

Vector ： List古老的实现类，底层使用Object[]存储，线程安全

ArrayList：底层使用Object[]存储，线程不安全

Collections.SynchronizedList

CopyOnWriteArrayList

CopyOnWriteArraySet

fail-fast

fail-safe

采用Collections包下的unmodifiable集合

Arrays.asList()方法返回的也是一个不能修改的集合

Collections.unmodifiableList(List)

Collections.unmodifiableSet(Set)

Collections.unmodifiableMap(Map)

FIFO算法

LRU算法

LFU算法

重写removeEldestEntry方法，当长度大于容量时，将最少访问的结点删除掉

accessOrder 是否按照访问顺序排序，默认是false，需要显示打开

afterNodeAccess

afterNodeInsertion

afterNodeRemoval

底层实现详解

Java虚拟机屏蔽了不同操作系统的差异，面向开发者提供了一致语言语法层次

不同的操作系统，Java虚拟机实现的方式可能不同

线程私有

线程共享

1） 共享内存区划分
 共享内存区 = 持久带 + 堆
 持久带 = 方法区 + 其他
 Java 堆 = 老年代 + 新生代
新生代 = Eden + S0 + S1

2） 一些参数的配置
默认，新生代 ( Young ) 与老年代 ( Old ) 的比例的值为 1:2 ，可以通过参数 – XX:NewRatio 配置。
默认，Edem : from : to = 8 : 1 : 1 ( 可以通过参数 –XX:SurvivorRatio 来设定) 
 Survivor 区中✁对象被复制次数为 15(对应虚拟机参数 -XX:+MaxTenuringThreshold)

3）为什么要分为 Eden 和 Survivor?为什么要设置两个 Survivor
区？
如果没有 Survivor，Eden 区每进行一次 Minor GC，存活的对象就会被送到老
年代。老年代很快被填满，触发 Major GC.老年代的内存空间远大于新生代，进
行一次 Full GC 的耗时间比 Minor GC 长得多,所以需要分为 Eden 和 Survivor。
Survivor 的存在意义，就减少被送到老年代对象，进而减少 Full GC发生，
Survivor 的预筛选保证，只有经历 16 次 Minor GC 还能在新生代中存活对象，
才会被送到老年代。
 设置两个 Survivor 区最大的好处就解决了碎片化，刚刚新对象在 Eden 中，
经历一次 Minor GC，Eden 中✁存活对象就会被移动到第一块 survivor space
S0，Eden 被清空；等 Eden 区再满了，就再触发一次 Minor GC，Eden 和 S0
中
存活对象又会被复制送入第二块 survivor space S1（这个过程非常重要，因为
这种复制算法保证了 S1 中来自S0 和 Eden 两部分存活对象占用连续✁内存空
间，避免了碎片化的发生）

不一定，在满足特定条件下，可以在栈上分配内存。

虚拟机栈一般是用来存储基本类数据类型、引用和返回地址的。

Java JIT编译器有两项优化，分别是 逃逸分析 和 标量替换。这样可以使得Java在栈上去分配对象

逃逸分析

引用回收时间与用途

强引用

软引用

弱引用

虚引用

堆设置

收集器设置

垃圾回收统计信息

并行收集器设置

并发收集器设置

HotSpot上面 1.7和其 以前 方法区和堆在物理内存上是连续的，方法区也被称之为永久代。

在1.7 的时候，方法区中的部分数据已经开始转移到堆/本地内存里面了，比如符号引用转移到本地内存；类的静态变量和字符串常量池转移到堆里；

1.8 之后取消了永久代的概念 转成元数据区，元数据区和本地内存一样大，但是其实同样可以去配置JVM这个参数

加载

链接

初始化

使用

卸载

类加载阶段中“通过一个类的全限定名来获取描述该类的二进制字节流”这个动作放到Java虚拟机外部实现，以便让应用程序自己决定如何去获取所需的类。实现这个动作的代码称为“类加载器”（Class Loader）

虽然只用于实现类加载的动作，但是Java中需中起到作用远超过类加载阶段。

对于任意一个类，必须由加载它的类加载器和它本身一起共同确立其在Java虚拟机中的唯一性。对于每个类加载器，都有独立的类名称空间。比较两个类是否相等，只有在这两个类是同一个类加载器的前提下才有意义

分类

启动类加载器

扩展类加载器

应用程序类加载器

工作过程

双亲委派机制很好地解决了各个类加载器协作时基础类型的一致性问题，但是如果有基础类型又要调用回用户的代码，这个时候就会破坏双亲委派机制

线程上下文类加载器，通过Thread类的setContext-ClassLoader()方法进行设置，如果创建线程时还未设置，会从父线程中继承一个。如果应用程序的全局范围内没有设置过的话，默认的就是应用程序类加载器。

有了线程上下文类加载器，程序可以做一些“舞弊”的事请，比如JNDI可以使用线程上下文类加载器去加载SPI服务代码。这是一种父类加载器去请求字类加载器完成类加载的行为。

涉及SPI的加载基本上都采用这种模式完成，JNDI、JDBC等。当SPI服务多于一个的时候，JDK6提供了ServiceLoader类，以MERA-INF/services中的配置信息，辅以责任链模式，才算是给SPI加载提供了相对合理的方案

模块化系统(JDK9后的类加载器委派关系)

介绍

Java语言对三个特性如何提供保证

深入理解JVM虚拟机描述

JVM可能会对我们写的语句进行指令重排，处理器为了提高程序运行的效率，对代码进行优化，不保证各个语句的执行顺序一致，但是可以在单线程中保证最终的执行结果一致

volatile等 可以做到禁止指令重排（具体的原理是内存屏障）

每个CPU都有自己的缓存，缓存的目的是为了提高性能，避免每次都要向内存存取，存在一定的弊端：不能实时和内存发生信息交换，分在不同CPU执行的不同线程对同一个变量的缓存值不同

volatile 关键字修饰的变量可以解决上述问题，通过内存屏障的方式，不同的硬件平台实现内存屏障的手段是不一致的，但是Java通过屏蔽这些差异，统一由JVM来生成内存屏障指令。

硬件层面的内存屏障

Java层面的内存屏障

Java内存模型具备一些先天的“有序性”（happens-before原则）

程序次序规则：一个线程内，按照代码顺序，书写在前面的操作先行发生于书写在后面的操作

锁定规则：一个unLock操作先行发生于后面对同一个锁额lock操作

volatile变量规则：对一个变量的写操作先行发生于后面对这个变量的读操作

传递规则：如果操作A先行发生于操作B，而操作B又先行发生于操作C，则可以得出操作A先行发生于操作C

线程启动规则：Thread对象的start()方法先行发生于此线程的每个一个动作

线程中断规则：对线程interrupt()方法的调用先行发生于被中断线程的代码检测到中断事件的发生

线程终结规则：线程中所有的操作都先行发生于线程的终止检测，我们可以通过Thread.join()方法结束、Thread.isAlive()的返回值手段检测到线程已经终止执行

对象终结规则：一个对象的初始化完成先行发生于他的finalize()方法的开始

minor GC

Full GC

Java 堆 = 老年代 + 新生代
新生代 = Eden + S0 + S1
当 Eden 区的空间满了， Java 虚拟机会触发一次 Minor GC，以收集新生代的
垃圾，存活下来的对象，则会转移到 Survivor 区。
大对象（需要大量连续内存空间的 Java 对象，如那种很长的字符串）直接进入老
年态；
如果对象在 Eden 出生，并经过第一次 Minor GC 后仍然存活，并且被 Survivor
容纳的话，年龄设为 1，每熬过一次 Minor GC，年龄+1，若年龄超过一定限制
（15），则被晋升到老年态。即长期存活的对象进入老年态。
老年代满了而无法容纳更多的对象，Minor GC 之后通常就会进行 Full GC，
FullGC 清理整个内存堆——包括年轻代和年老代。
Major GC 发生在老年代的GC，清理老年区，经常会伴随至少一次 Minor GC，
比 Minor GC 慢 10 倍以上。

引用计数算法

可达性分析

Serial收集器

Serial Old 收集器

ParNew收集器

Parallel Scavenge 收集器

Parallel Old 收集器

CMS收集器 🌟

G1收集器 🌟

标记清除

标记复制

标记整理

Hotspot VM

J9 VM

Zing VM

JRockit（Oracle）

内存泄露 memory leak，是指程序在申请内存后，无法释放已申请的内存空间；内存泄露堆积后果很严重，无论多少内存，迟早会被占光。

当集合里面的对象属性被修改后，再调用remove（）方法时不起作用

如果单例对象持有外部对象的引用，那么这个外部对象将不能被jvm正常回收，导致内存泄露

数据库连接，网络连接(socket)和io连接，除非其显式的调用了其close方法()将其连接关闭，否则是不会自动被GC回收的，可能会产生内存泄露。

递归调用深度过深： 当一个函数递归调用自身或其他函数太深，导致调用栈中的栈帧过多，栈内存会耗尽。这通常是因为没有递归终止条件，或者终止条件设置不当，导致递归无法结束。

局部变量占用过多内存： 如果在函数中定义了大量的局部变量，而这些变量在函数调用过程中没有被释放，会导致栈内存的快速耗尽。这通常发生在某个函数中创建了大型数组或数据结构。

大规模的方法调用链： 如果在程序中有大规模的方法调用链，每次方法调用都会创建一个新的栈帧，栈内存会不断增长。如果方法调用链太长，栈内存可能会耗尽。

递归死循环： 如果递归函数中存在死循环，栈内存会持续分配新的栈帧，直到栈内存用尽。这通常是由于递归终止条件设置不当或逻辑错误引起的。

线程过多： 对于多线程应用程序，每个线程都有自己的调用栈。如果创建了大量线程，每个线程都占用一部分栈内存，总体可能导致栈内存不足。

栈帧过大： 如果某个函数的栈帧过大，比如包含大型数据结构，也可能导致栈内存溢出。

栈内存溢出通常会导致程序崩溃，且错误信息通常包括 "java.lang.StackOverflowError"（对于Java）或类似的错误信息。为了避免栈内存溢出，需要谨慎设计递归和方法调用链，合理控制局部变量的大小，以及监控线程的数量，特别是在多线程应用中。

设计逻辑

垃圾回收

为什么需要DirectByteBuffer

内存分配问题

jps

jstat

jmap

jhat

jstack

jinfo

top命令查看 CPU的负载情况

或者使用JVM调优命令查看信息

基本概念

区别

进程之间的通信

线程之间的通信

原子性、可见性、有序性 是 并发的三大性质

原子性

有序性

可见性

内存屏障、volatile的内存屏障、final中内存屏障

使用多线程可以把占据时间长的程序中的任务放到后台处理

在多核机器上可以提升机器的利用率，使得程序的运行效率提高

多线程可以讲复杂任务分解成更小的，更想对独立的线程，简化编程任务以及易于维护和测试

编写多线程程序时，需要注意共享资源的线程安全

大量的线程也可能会影响性能，操作系统进行切换时会消耗一定的时间

1. 继承Thread类，并重写run方法，然后使用该类的实例进行start方法

2. 实现Runnable接口，并实现run方法；将其传入Thread构造器中，调用thread的start方法；（注：不会抛出异常）

3. 实现Callable接口，实现call方法，call方法是带返回值的，通过FutureTask构造方法，将callable实现类传进去，FeatureTask作为Thread的target创建Thread线程对象，通过get方法获取执行结果。（在get的时候，如果执行有问题会抛出异常）

4. 通过实现线程池，然后使用线程池可以提交任务，创建线程

Java中线程分成两类：守护线程、用户线程。

当JVM中不存在任何一个正在运行的非守护线程是，则JVM进程会退出

守护线程拥有自动结束自己生命周期的特性，非守护线程不具备这个特点

读写操作或者计算操作不应该放在守护线程中，可能用户线程已执行完成，守护线程退出，会导致守护线程中数据丢失

守护线程经常作用于执行一些后台任务，比如JDK的垃圾回收任务，因此有时候也被称为是后台线程

线程状态

线程状态流转

Java中的线程可以设置优先级，范围是1～10，默认为5； 你可以使用常量，如MIN_PRIORITY = 1 ,MAX_PRIORITY = 10 ，NORM_PRIORITY = 5 来设定优先级。

该值是给操作系统作为调度的参考，但线程最终的调用顺序是由操作系统的调度算法来决定的

t.setPriority()用来设定线程的优先级。

Java5.0 提供了java.util.concurrent包（简称JUC），包含了并发编程中常用的实用工具类

知识体系

基于 AQS 实现的各种工具类

不是线程安全的。i++不是原子操作，而是由三条指令合成

volatile不能解决线程安全问题，只能保证可见性，不能保证原子性

解决方法：
1、对 i++ 操作的方法加同步锁，同时只能有一个线程执行 i++ 操作
2、使用支持原子性操作的类，如 java.util.concurrent.atomic.AtomicInteger，它使用的是 CAS 算法，效率优于第 1 种；

t.join方法用来阻塞调用此方法的线程，直到线程t完成执行，再继续

原理：通过源码可以了解到，在join方法中调用了wait方法，表示主线程拥有自线程对象的锁，并且进入等待状态；当自线程执行结束时，JVM会自动调用lock.notify_all()方法，此时主线程被唤醒了，可以继续跑下去了

使用sleep方法，可以使得当前线程处于阻塞状态（休眠）；当线程重新被唤醒时，会从阻塞状态变成就绪状态

sleep和wait方法的区别

jdk 1.5 之后引入了 TimeUnit ,对sleep方法做了很好的封装，省去时间换算的步骤且更优雅

yield方法表示谦让的意思，它让掉当前CPU的时间片，使得正在运行中的线程重新变成就绪状态，并且重新竞争CPU的调度权，
也就是说如果cpu资源不紧张的话会忽略这种提示。

sleep和yield方法的区别

线程中断的3个方法

原理

两个池

wait

notify

notifyAll

同步是阻塞模式，异步是非阻塞模式。（讲一下两者的处理模式）

一般会采用异步去执行比较耗时，或者对最终结果没有影响的操作，从而提高效率

正常关闭

异常退出

进程假死

多线程编程中，为了防止多线程竞争共享资源而导致数据错乱，都会在操作共享资源之上加上互斥锁，只有获得锁的线程，才能操作共享资源，获取不到锁的线程只能等待，直到锁被释放

两个线程为了保护两个不同的共享资源使用了两个互斥锁，这两个互斥锁应用不当的时候，可能会导致两个线程都在等待对方释放锁，在没有外力的作用下，线程会相互等待，这个时候就会发生死锁

死锁四条件

程序死锁

Java排查死锁可以采用 jstack 工具，它是jdk自带的线程堆栈分析工具

最常见的方式是使用资源有序分配法

线程A和线程B获取资源的顺序要一致，当线程A先尝试获取A资源，然后尝试获取B资源的时候；线程B同样也是先尝试获取A资源，然后尝试获取B资源，AB线程总是以同样的顺序申请自己想要的资源即可

防止

避免

检测和恢复

两个以上的线程在执行的时候，因为互相谦让资源，结果都拿不到资源没法运行程序

账户A转账户B，账户B转账户 A。那么，线程一会占有账户A，线程二则会占有账户B。线程一拿不到账号B，转账没法执行，线程一结束；线程二也拿不到账号A，转账也没法执行，线程二结束。之后开始第二轮循环，再循环过程中又是重复，这样的话就是活锁

如何避免活锁？

无锁编程一般就是不使用锁而达到线程安全的目的，一般CAS算法就是常用的无锁算法

多线程场景下，某个线程一直阻塞在同步代码块外无法进入临界区消费，这种情况就是线程饥饿

导致原因

解决方式

CAS是比较并替换，是一种实现并发算法时，常用到的技术，Java并发包中原子类就是基于这种思想

CAS 需要有三个操作数： 内存值V，旧的预期值A，需要更新的目标值B；CAS执行时，当且仅当V==A时，将V修改成B否则什么都不做，整个比较替换的操作时原子操作

CAS会有ABA的问题

阻塞和非阻塞关注的是 程序在等待调用结果时的状态

阻塞调用表示，在调用结果返回回来前，当前的线程会被挂起，调用线程只有在得到结果之后才会执行下步操作

非阻塞调用表示不能立即得到结果前也不会阻塞当前线程。

并发是逻辑上的同时发生

并行是物理上的同时发生

并发和并行的区别

不使用stop原因

不使用suspend的原因

较高的Java版本已经将这两个方法标记上@Derecated标签了

定义一个变量，由目标线程去不断的检查变量的状态，当变量达到某个状态的时候，停止线程；这个变量需要加上volatile，保证变量的可见性

使用interrupt方法中断线程，原理其实是一致的，只不过线程封装成方法实现了。我们可以看到interrupt方法其实就是将中断状态变量设置成true，在调用isInterrupted方法的时候，可以看到就是去判断这个状态的，然后进行优雅退出线程。包括sleep等方法内部有去轮询这个状态是否为true，然后会抛出中断异常

什么是synchronized?

synchronized 用于对对代码块或者方法进行修饰：同步代码块 / 同步方法

要注意的问题：

面向对象的同步锁

面向类的同步锁

如果获取了某个实例的锁，还能继续获取类锁吗？

锁升级描述的是jdk6以后，Java对synchronized的优化，使得其在竞争并不是很大的场景下，有较高的性能；锁升级按照锁类型可以分成4个阶段

对象在JVM里的空间布局

偏向锁

轻量级锁

自旋锁

重量级锁

注

通常情况下，为了保证多线程间的有效并发，会要求每个线程持有锁的时间尽可能短，但是某些情况下，一个程序对同一个锁不间断、高频地请求、同步与释放，会消耗掉一定的系统资源，因为锁的请求、同步与释放本身会带来性能损耗，这样高频的锁请求就反而不利于系统性能的优化了，虽然单次同步操作的时间可能很短。

锁粗化：讲多次锁的请求合并到一个请求中，以降低段时间内大量锁请求、同步、释放带来的性能损耗

两个获取相同锁代码块之间有一定的代码，但是可以很快执行完成，系统会合并这两个代码块，放入到同一个锁代码块上

public void doSomethingMethod(){
    synchronized(lock){
        //do some thing
    }
    //这是还有一些代码，做其它不需要同步的工作，但能很快执行完毕
    synchronized(lock){
        //do other thing
    }
}

for(int i=0;i<size;i++){
    synchronized(lock){
    }
}

锁消除：虚拟机在即时编译的过程中，监测到不可能存在共享数据的竞争，此时就去掉锁；锁消除具体的判断依据来自逃逸技术：如果判断到一段代码中，在堆上的所有数据都不会逃逸出去，被其他线程访问到，那就可以把他们当作栈上的数据对待，认为他们是线程私有的，同步加锁就不用进行

public String concatString(String s1, String s2, String s3) {  
    StringBuffer sb = new StringBuffer();  
    sb.append(s1);  
    sb.append(s2);  
    sb.append(s3);  
    return sb.toString();  
}

StingBuffer是线程安全的，append方法加上了synchronized关键字，在这个场景下，每次调用concatString方法都会生成一个新的对象，那么这个对象进行append方法其实不需要有锁操作，会进行锁消除

重入锁实现了Lock接口，当前线程可以反复加锁，表示可重入。如果设计成不可重入的情况，那么一段逻辑中多次获取同一个锁会导致形成死锁

synchronized同样也是可重入的

ReentrantLock几个重要方法

ReentrantLock底层是通过 AQS 来实现的，重入次数统计是AQS中状态state，默认情况下锁的实现是非公平锁

相似点

不同点

一定要认真研读

笔记来自于

线程要不要锁住同步资源？

锁住同步资源失败，线程要不要阻塞？

多个线程竞争同步资源的流程细节有没有区别？

多个线程竞争锁时要不要排队？

一个线程中的多个流程能不能获取同一把锁？

多个线程能不能共享一把锁？

线程过多会带来额外的开销，其中包括创建销毁线程的开销、调度线程的开销等等，同时也降低了计算机的整体性能。线程池维护多个线程，等待监督管理者分配可并发执行的任务。这种做法，一方面避免了处理任务时创建销毁线程开销的代价，另一方面避免了线程数量膨胀导致的过分调度问题，保证了对内核的充分利用。

ThreadPoolExecutor

使用线程池可以带来的好处

Executors中提供了多种线程池快速创建方法，可以大致了解一下，自己在实践过程中还是采用ThreadPoolExecutor来进行构建，以便于自定义，同时理解线程池执行工作流程

固定长度的线程池，使用时，阻塞队列没有设置大小，大量请求来时队列耗费大量内存导致OOM。（LinkedBlockingQueue默认长度Integer.MAX_VALUE）

单线程的线程池，缺陷同上

缓存线程池：核心线程为0，最大线程非常大，动态创建特点；大量请求过来时会导致创建大量线程，可能导致OOM

execute只能提交Runnable类型任务，submit既能提交Runnable类型任务，也能提交Callable类型任务

exectue会直接抛出执行时的异常，submit会吃掉异常，在Future的get方法中将执行过程中的异常重新抛出

exectue所属的顶层接口是Executor，submit所属的顶层接口是ExecutorService。实现类ThreadPoolExecutor重写了execute方法,抽象类AbstractExecutorService重写了submit方法。

ThreadPoolExecutor中有几个方法可以时我们监控到线程池目前的运行情况

getQueue().size()

getActiveCount()

getCompletedTaskCount()

getTaskCount()

线程池参数的配置往往和具体的任务有关系，IO密集型和CPU密集型往往是不一致的参数

理论

经验值

其他做法

线程池关闭相关的方法主要如下

void shutdown

List<Runnable> shutDownNow

boolean awaitTermination

boolean isShutDown

boolean isTerminated

AQS的介绍

ReentrantReadWriteLock 详细介绍

从设计模式角度看AQS

AQS底层原理

分支/合并框(Fork/Join)是Java7提供的一个用于并行执行任务的框架，是一个把大任务分割成若干个小任务，最终汇总每个小任务结果后得到大任务结果的框架。它使用工作窃取（work-stealing）算法，主要用于实现“分而治之”。

ForkJoinPool

ForkJoinTask

概念

数据结构

GC之后Key是否为NULL？

set方法

ThreadLocalMap

使用场景

缺点

概念：一旦一个共享变量（类的成员变量、类的静态成员变量）被volatile修饰之后，那么就具备了两层语义

原理和实现机制：观察加入volatile关键字和没有加入volatile关键字时所生成的汇编代码发现，加入volatile关键字时，会多出一个lock前缀指令

eg1 : 单例模式 双重校验锁 - 顺序性特点

eg2: 开关控制利用可见性的特点

eg3: 状态标记利用顺序性特点

使用上的区别

对原子性的保证

对可见性的保证

对有序性的保证

其他

CyclicBarrier 的字面意思是可循环使用（Cyclic）的屏障（Barrier）。它要做 的事情是，让一组线程到达一个屏障（也可以叫同步点）时被阻塞，直到最后一 个线程到达屏障时，屏障才会开门，所有被屏障拦截的线程才会继续运行。

默认的构造方法是 public CyclicBarrier(int parties)，其参数表示屏障拦截的线程数量，每个线程调用 await 方法告诉 CyclicBarrier 我已经到达了屏障，然后当前线程被阻塞。

CyclicBarrier 还提供一个更高级的构造函数 public CyclicBarrier(int parties, Runnable barrierAction)，用于在线程到达屏障时，优先执行 barrierAction，方便处理更复杂的业务场景。

在线程池中使用 CyclicBarrier 时一定要注意线程的数量要多于 CyclicBarrier 实例中设置的阻塞线程的数量就会发生死锁。 调用 await() 方法的次数一定要等于屏障中设置的阻塞线程的数量，否则也会死锁。

使用AQS同步状态来表示计数。计数为0时，所有的Acquire操作（CountDownLatch的await方法）才可以通过。

二者都能让一个或多个线程阻塞等待，都可以用在多个线程间的协调，起到线程同步的作用。

CountDownLatch 的计数器只能使用一次，而 CyclicBarrier 的计数器可以反复 使用。

CountDownLatch.await 一般阻塞工作线程，所有的进行预备工作的线程执行 countDown，而 CyclicBarrier 通过工作线程调用 await 从而自行阻塞，直到所有工作线程达到指定屏障，所有的线程才会返回各自执行自己的工作。

在控制多个线程同时运行上，CountDownLatch 可以不限线程数量，而 CyclicBarrier 是固定线程数。

CyclicBarrier 还可以提供一个 barrierAction，合并多线程计算结果。

使用AQS同步状态来保存信号量的当前计数。tryRelease会增加计数，acquireShared会减少计数。

线程之间通信的一种方式，可以用来空值同时访问特定资源的线程数量，通过协调各个线程，以保证合理的使用资源

主要方法（令牌可以当作一个信号）

Exchanger是java 5引入的并发类，Exchanger顾名思义就是用来做交换的。这里主要是两个线程之间交换持有的对象。当Exchanger在一个线程中调用exchange方法之后，会等待另外的线程调用同样的exchange方法。两个线程都调用exchange方法之后，传入的参数就会交换。

两个主要方法

LockSupport是一个线程阻塞工具类，所有的方法都是静态方法，可以让线程在任意位置阻塞，或者唤醒。

concurrent包是基于AQS框架的，AQS借助于两个类：Unsafe（提供CAS操作）、LockSupport（提供park/unpark操作）

常用方法

引入Unsafe机制来实现非阻塞同步（乐观锁），基于CAS提供了一套原子工具类

分类

源码分析（AtomicInteger）

可能导致问题

ConcurrentHashMap：并发版HashMap 🌟

CopyOnWriteArrayList：并发版ArrayList 🌟

CopyOnWriteArraySet：并发Set

ConcurrentLinkedQueue：并发队列(基于链表)

ConcurrentLinkedDeque：并发队列(基于双向链表)

ConcurrentSkipListMap：基于跳表的并发Map

ConcurrentSkipListSet：基于跳表的并发Set

ArrayBlockingQueue：阻塞队列(基于数组) 🌟

LinkedBlockingQueue：阻塞队列(基于链表) 🌟

LinkedBlockingDeque：阻塞队列(基于双向链表)

PriorityBlockingQueue：线程安全的优先队列 🌟

SynchronousQueue：读写成对的队列

LinkedTransferQueue：基于链表的数据交换队列

DelayQueue：延时队列

可以理解为执行一次操作，和执行多次操作最终的效果是一致的

比如在和消息队列相关的业务中，我们最好将业务设计成幂等操作，这样如果发生了消息重复消费的场景，也可以保证不影响最终结果

作用

实现原理

两种动态代理实现

简介

IOC容器会帮对象找相应的依赖对象并注入

DI

装配实践

注入实践

- Bean的生命周期

设计模式

- Spring Cloud的实现原理/也可以用来回答微服务框架

- 其他相关问题

1.spring 中有两个id相同的bean 会报错吗？如果会报错在哪个阶段报出来？

2. 如何理解spring boot 中的starter

3.为什么使用spring框架

4.为什么越来越多的人选择spring boot

5.spring 如何解决循环依赖问题

Beanfactory 和 FactoryBean 的区别

7. spring 中事务的传播行为有哪些

8. spring 里面的事务和分布式事务的使用如何区分，以及这两个事务之间有什么关联

9.spring bean 生命周期的执行流程

10. spring 中有哪些方式可以把 bean注入到 ioc容器

11. spring boot 中自动装配机制的原理

12. spring boot 的约定优于配置，你的理解是什么？

14.spring ioc的工作流程

15.谈谈你对spring ioc和di 的理解

16. 谈谈你对 spring MVC 的理解

17.spring 中实现一步调用的方式有哪些

Mybatis是一个半ORM（对象关系映射）框架，它内部封装了JDBC，开发时只需要关注SQL语句本身，不需要花费精力去处理加载驱动、创建连接、创建statement等繁杂的过程。程序员直接编写原生态sql，可以严格控制sql执行性能，灵活度高。

MyBatis可以使用XML或注解来配置和映射原生信息，将POJO映射成数据库中的记录，避免了几乎所有的JDBC代码和手动设置参数以及获取结果集。

通过xml文件或注解的方式将要执行的各种statement配置起来，并通过java对象和statement中sql的动态参数进行映射生成最终执行的sql语句，最后由mybatis框架执行sql并将结果映射为java对象并返回。（从执行sql到返回result的过程）。

基础支持层

核心处理层

接口层

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

2、消除了JDBC大量冗余的代码，不需要手动开关连接；

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

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

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

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

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

1、MyBatis专注于SQL本身，是一个足够灵活的DAO层解决方案。

2、对性能的要求很高，或者需求变化较多的项目，如互联网项目，MyBatis将是不错的选择。

1、Mybatis和hibernate不同，它不完全是一个ORM框架，因为MyBatis需要程序员自己编写Sql语句。

2、Mybatis直接编写原生态sql，可以严格控制sql执行性能，灵活度高，非常适合对关系数据模型要求不高的软件开发，因为这类软件需求变化频繁，一但需求变化要求迅速输出成果。但是灵活的前提是mybatis无法做到数据库无关性，如果需要实现支持多种数据库的软件，则需要自定义多套sql映射文件，工作量大。

3、Hibernate对象/关系映射能力强，数据库无关性好，对于关系模型要求高的软件，如果用hibernate开发可以节省很多代码，提高效率。

#{}是预编译处理，${}是字符串替换。

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

Mybatis在处理{}替换成变量的值。

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

加载驱动程序

获得数据库连接

创建一个 Statement 对象

操作数据库，实现增删改查

获取结果集

关闭资源

Mybatis 使用 RowBounds 对象进行分页，它是针对 ResultSet 结果集执行的内存分页，而非物理分页，先把数据都查出来，然后再做分页。

可以在 sql 内直接书写带有物理分页的参数来完成物理分页功能，也可以使用分页插件来完成物理分页。

分页插件的基本原理是使用 Mybatis 提供的插件接口，实现自定义插件，在插件的拦截方法内拦截待执行的 sql，然后重写 sql（SQL 拼接 limit），根据 dialect 方言，添加对应的物理分页语句和物理分页参数，用到了技术 JDK 动态代理，用到了责任链设计模式。

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

Mybatis 动态 sql 可以在 Xml 映射文件内，以标签的形式编写动态 sql，执行原理是根据表达式的值完成逻辑判断 并动态调整 sql 的功能。
Mybatis 提供了 9 种动态 sql 标签：trim | where | set | foreach | if | choose | when | otherwise | bind。

除了常见的 select|insert|updae|delete 标签之外，还有：

<resultMap>、<parameterMap>、<sql>、<include>、<selectKey>，
加上动态 sql 的 9 个标签，其中<sql>为 sql 片段标签，
通过<include>标签引入 sql 片段，<selectKey>为不支持自增的主键生成策略标签。

Mybatis 仅支持 association 关联对象和 collection 关联集合对象的延迟加载，
association 指的就是一对一，collection 指的就是一对多查询。
在 Mybatis 配置文件中，可以配置是否启用延迟加载lazyLoadingEnabled=true|false。

延迟加载的基本原理是，使用 CGLIB 创建目标对象的代理对象，当调用目标方法时，进入拦截器方法。

比如调用a.getB().getName()，拦截器 invoke()方法发现 a.getB()是 null 值，那么就会单独发送事先保存好的查询关联 B 对象的 sql，把 B 查询上来，然后调用a.setB(b)，于是 a 的对象 b 属性就有值了，接着完成a.getB().getName()方法的调用。

当然了，不光是 Mybatis，几乎所有的包括 Hibernate，支持延迟加载的原理都是一样的。

简单说：使用了 JDK 动态代理和反射，把接口和 xml 绑定在一起而搞定的。

不能

1、对于支持生成自增主键的数据库：增加 useGenerateKeys 和 keyProperty ，<insert>标签属性。
2、不支持生成自增主键的数据库：使用<selectKey>。
注意 Mybatis 的版本，官方在这个 3.3.1 版本中加入了批量新增返回主键 id 的功能 。

不同的 Xml 映射文件，如果配置了 namespace，那么 id 可以重复；如果没有配置 namespace，那么 id 不能重复；毕竟 namespace 不是必须的，只是最佳实践而已。

原因就是 namespace+id 是作为 Map<String, MappedStatement>的 key 使用的，如果没有 namespace，就剩下 id，那么，id 重复会导致数据互相覆盖。有了 namespace，自然 id 就可以重复，namespace 不同，namespace+id 自然也就不同。

Mybatis 有三种基本的 Executor 执行器，「SimpleExecutor、ReuseExecutor、BatchExecutor。」
SimpleExecutor：每执行一次 update 或 select，就开启一个 Statement 对象，用完立刻关闭 Statement 对象。

ReuseExecutor：执行 update 或 select，以 sql 作为 key 查找 Statement 对象，存在就使用，不存在就创建，用完后，不关闭 Statement 对象，而是放置于 Map<String, Statement>内，供下一次使用。简言之，就是重复使用 Statement 对象。

BatchExecutor：执行 update（没有 select，JDBC 批处理不支持 select），将所有 sql 都添加到批处理中（addBatch()），等待统一执行（executeBatch()），它缓存了多个 Statement 对象，每个 Statement 对象都是 addBatch()完毕后，等待逐一执行 executeBatch()批处理。与 JDBC 批处理相同。

作用范围：Executor 的这些特点，都严格限制在 SqlSession 生命周期范围内。

（1）Hibernate 属于全自动 ORM 映射工具，使用 Hibernate 查询关联对象或者关联集合对象时，可以根据对象关系模型直接获取，所以它是全自动的。
而 Mybatis 在查询关联对象或关联集合对象时，需要手动编写 sql 来完成，所以，称之为半自动 ORM 映射工具。
（2）Mybatis 直接编写原生态 sql，可以严格控制 sql 执行性能，灵活度高，非常适合对关系数据模型要求不高的软件开发，因为这类软件需求变化频繁，一但需求变化要求迅速输出成果。但是灵活的前提是 mybatis 无法做到数据库无关性，如果需要实现支持多种数据库的软件，则需要自定义多套 sql 映射文件，工作量大。
（3）Hibernate 对象/关系映射能力强，数据库无关性好，对于关系模型要求高的软件，如果用 hibernate 开发可以节省很多代码，提高效率。
其实关于常见 ORM 框架还设有 Spring 的 JPA，后期的面试可能会更倾向于问 JPA 和 Mybatis 的区别了

configuration 配置

properties 属性:可以加载

properties 配置文件的信息

settings 设置：可以设置 mybatis 的全局属性

typeAliases 类型命名

typeHandlers 类型处理器

objectFactory 对象工厂

plugins 插件

environments 环境

environment 环境变量

transactionManager 事务管理器

dataSource 数据源

mappers 映射器

第 1 种：通过在查询的 sql 语句中定义字段名的别名，让字段名的别名和实体类的属性名一致。
<select id="selectById" resultMap="User">
        select id, name as userName, pwd as password from m_user
        <where>
            <if test="id != null">
                id = #{id}
            </if>
        </where>
    </select>

第 2 种：通过<resultMap>来映射字段名和实体类属性名的一一对应的关系。

第 3 种：使用注解时候，使用 Result，和第二种类似。

第 1 种：在 Java 代码中添加 sql 通配符。
String wildcardname = “%smi%”;
list<name> names = mapper.selectlike(wildcardname);

<select id=”selectlike”>
select * from foo where bar like #{value}
</select>

第 2 种：在 sql 语句中拼接通配符，会引起 sql 注入
String wildcardname = “smi”;
list<name> names = mapper.selectlike(wildcardname);

<select id=”selectlike”>
select * from foo where bar like "%"#{value}"%"
</select>

整体步骤：

创建数据库表-》创建数据库表对应的实体类-〉创建xxmapper接口类 -> 创建xxmapper.xml -》创建config.xml并配置-〉创建test类

1、创建 SqlSessionFactory

2、通过 SqlSessionFactory 创建 SqlSession

3、通过 sqlsession 执行数据库操作

4、调用 session.commit()提交事务

5、调用 session.close()关闭会话

总结来讲

详细讲

顺序传参法

@param注解传参法

map传参法

java bean 传参法

Mybatis当然可以映射枚举类，不单可以映射枚举类，Mybatis可以映射任何对象到表的一列上。映射方式为自定义一个TypeHandler，实现TypeHandler的setParameter()和getResult()接口方法。
TypeHandler有两个作用，一是完成从javaType至jdbcType的转换，二是完成jdbcType至javaType的转换，体现为setParameter()和getResult()两个方法，分别代表设置sql问号占位符参数和获取列查询结果。

Java和其他语言相比的差异性

Java的语法特性

JVM

JVM、JDK 和 JRE 有什么区别？

java 有哪些数据类型

自动类型转换，强制类型转换？

什么事自动拆箱/装箱？

this 关键字有什么作用？

回答套路

经典回答

考点分析

知识扩展

Java中异常处理体系

代码规范中如何设计Exception

Exception和Error区别

抛出异常

捕获异常

遇到异常不进行具体处理，而是继续抛给调用者 （throw，throws）
抛出异常有三种形式，一是 throw,一个 throws，还有一种系统自动抛异常。

throws 用在方法上，后面跟的是异常类，可以跟多个；而 throw 用在方法内，后面跟的是异常对象。

try catch 捕获异常
在 catch 语句块中补货发生的异常，并进行处理。


       try {
            //包含可能会出现异常的代码以及声明异常的方法
        }catch(Exception e) {
            //捕获异常并进行处理
        }finally {                                                       }
            //可选，必执行的代码
        }
try-catch 捕获异常的时候还可以选择加上 finally 语句块，finally 语句块不管程序是否正常执行，最终它都会必然执行。

只是看起来相似，但是作用完全不一样

final修饰 类、方法、变量，分别不同的意义

finally代码块

finalize方法的作用

== : 它的作⽤是判断两个对象的地址是不是相等。即，判断两个对象是不是同⼀个对象(基本数据类型 == 比较的是值，引⽤数据类型 == 比较的是内存地址)。

equals() : 它的作⽤也是判断两个对象是否相等。但是这个“相等”一般也分两种情况：

默认情况：类没有覆盖 equals() ⽅法。则通过 equals() 比较该类的两个对象时，等价于通过“ == ”比较这两个对象，还是相当于比较内存地址
自定义情况：类覆盖了 equals() ⽅法。我们平时覆盖的 equals()方法一般是比较两个对象的内容是否相同，自定义了一个相等的标准，也就是两个对象的值是否相等。

什么是 HashCode？

hashCode() 的作⽤是获取哈希码，也称为散列码；它实际上是返回⼀个 int 整数，定义在 Object 类中， 是一个本地⽅法，这个⽅法通常⽤来将对象的内存地址转换为整数之后返回。
public native int hashCode();
哈希码主要在哈希表这类集合映射的时候用到，哈希表存储的是键值对(key-value)，它的特点是：能根据“键”快速的映射到对应的“值”。这其中就利⽤到哈希码！

为什么重写 quals 时必须重写 hashCode ⽅法？

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

为什么两个对象有相同的 hashcode 值，它们也不⼀定是相等的？

因为可能会碰撞， hashCode() 所使⽤的散列算法也许刚好会让多个对象传回相同的散列值。越糟糕的散列算法越容易碰撞，但这也与数据值域分布的特性有关（所谓碰撞也就是指的是不同的对象得到相同的 hashCode ）。

Java 语言是值传递。Java 语言的方法调用只支持参数的值传递。当一个对象实例作为一个参数被传递到方法中时，参数的值就是对该对象的引用。对象的属性可以在被调用过程中被改变，但对对象引用的改变是不会影响到调用者的。

JVM 的内存分为堆和栈，其中栈中存储了基本数据类型和引用数据类型实例的地址，也就是对象地址。

而对象所占的空间是在堆中开辟的，所以传递的时候可以理解为把变量存储的对象地址给传递过去，因此引用类型也是值传递。

浅拷贝：仅拷贝被拷贝对象的成员变量的值，也就是基本数据类型变量的值，和引用数据类型变量的地址值，而对于引用类型变量指向的堆中的对象不会拷贝。
深拷贝：完全拷贝一个对象，拷贝被拷贝对象的成员变量的值，堆中的对象也会拷贝一份。

因此深拷贝是安全的，浅拷贝的话如果有引用类型，那么拷贝后对象，引用类型变量修改，会影响原对象。

浅拷贝如何实现呢？

Object 类提供的 clone()方法可以非常简单地实现对象的浅拷贝。

深拷贝如何实现呢？

重写克隆方法：重写克隆方法，引用类型变量单独克隆，这里可能会涉及多层递归。
序列化：可以先将原对象序列化，再反序列化成拷贝对象。

概念定位

弱引用的用途，在Java中的实践ThreadLocal

（1）new 创建新对象
（2）通过反射机制
（3）采用 clone 机制
（4）通过序列化机制
前两者都需要显式地调用构造方法。对于 clone 机制,需要注意浅拷贝和深拷贝的区别，对于序列化机制需要明确其实现原理，在 Java 中序列化可以通过实现 Externalizable 或者 Serializable 来实现。

String 是 Java 基本数据类型吗？

不是。Java 中的基本数据类型只有 8 个：byte、short、int、long、float、double、char、boolean；除了基本类型（primitive type），剩下的都是引用类型（reference type）。

String 是一个比较特殊的引用数据类型。

String 类可以继承吗？

不行。String 类使用 final 修饰，是所谓的不可变类，无法被继承。

概念定位

底层实现

字符串缓存

String的演进

两个语句都会去字符串常量池中检查是否已经存在 “abc”，如果有则直接使用，如果没有则会在常量池中创建 “abc” 对象。

但是不同的是，String str1 = new String("abc") 还会通过 new String() 在堆里创建一个 "abc" 字符串对象实例。所以后者可以理解为被前者包含。

String s = new String("abc")创建了几个对象？

很明显，一个或两个。如果字符串常量池已经有“abc”，则是一个；否则，两个。

当字符创常量池没有 “abc”，此时会创建如下两个对象：

一个是字符串字面量 "abc" 所对应的、字符串常量池中的实例
另一个是通过 new String() 创建并初始化的，内容与"abc"相同的实例，在堆中。

String 的确是不可变的，“+”的拼接操作，其实是会生成新的对象。

在jdk1.8 之前，a 和 b 初始化时位于字符串常量池，ab 拼接后的对象位于堆中。经过拼接新生成了 String 对象。如果拼接多次，那么会生成多个中间对象。

在Java8 时JDK 对“+”号拼接进行了优化，上面所写的拼接方式会被优化为基于 StringBuilder 的 append 方法进行处理。Java 会在编译期对“+”号进行处理。

下面是通过 javap -verbose 命令反编译字节码的结果，很显然可以看到 StringBuilder 的创建和 append 方法的调用。

也就是说其实上面的代码其实相当于：
String a = "hello ";
String b = "world!";
StringBuilder sb = new StringBuilder();
sb.append(a);
sb.append(b);
String ab = sb.toString();

如果当前字符串内容存在于字符串常量池（即 equals()方法为 true，也就是内容一样），直接返回字符串常量池中的字符串
否则，将此 String 对象添加到池中，并返回 String 对象的引用

答案是 a 和 b 相等，c 和 d 不相等。

对于基本数据类型==比较的值
对于引用数据类型==比较的是地址
Integer a= 127 这种赋值，是用到了 Integer 自动装箱的机制。自动装箱的时候会去缓存池里取 Integer 对象，没有取到才会创建新的对象。

如果整型字面量的值在-128 到 127 之间，那么自动装箱时不会 new 新的 Integer 对象，而是直接引用缓存池中的 Integer 对象，超过范围 a1==b1 的结果是 false

什么是 Integer 缓存？

因为根据实践发现大部分的数据操作都集中在值比较小的范围，因此 Integer 搞了个缓存池，默认范围是 -128 到 127，可以根据通过设置JVM-XX:AutoBoxCacheMax=来修改缓存的最大值，最小值改不了。

实现的原理是 int 在自动装箱的时候会调用 Integer.valueOf，进而用到了 IntegerCache。 【可以看下 Integer.valueOf 的源码 】

很简单，就是判断下值是否在缓存范围之内，如果是的话去 IntegerCache 中取，不是的话就创建一个新的 Integer 对象。

IntegerCache 是一个静态内部类， 在静态块中会初始化好缓存值。
private static class IntegerCache {
     ……
     static {
            //创建Integer对象存储
            for(int k = 0; k < cache.length; k++)
                cache[k] = new Integer(j++);
         ……
     }
 }

String 转成 Integer，主要有两个方法：

Integer.parseInt(String s)
Integer.valueOf(String s)
不管哪一种，最终还是会调用 Integer 类内中的parseInt(String s, int radix)方法。 
其实里面主要做了一些负向累加

对象比较：

public native int hashCode() ：native 方法，用于返回对象的哈希码，主要使用在哈希表中，比如 JDK 中的 HashMap。
public boolean equals(Object obj)：用于比较 2 个对象的内存地址是否相等，String 类对该方法进行了重写用户比较字符串的值是否相等。

对象拷贝：

protected native Object clone() throws CloneNotSupportedException：naitive 方法，用于创建并返回当前对象的一份拷贝。一般情况下，对于任何对象 x，表达式 x.clone() != x 为 true，x.clone().getClass() == x.getClass() 为 true。Object 本身没有实现 Cloneable 接口，所以不重写 clone 方法并且进行调用的话会发生 CloneNotSupportedException 异常。

对象转字符串：

public String toString()：返回类的名字@实例的哈希码的 16 进制的字符串。建议 Object 所有的子类都重写这个方法。

多线程调度：

public final native void notify()：native 方法，并且不能重写。唤醒一个在此对象监视器上等待的线程(监视器相当于就是锁的概念)。如果有多个线程在等待只会任意唤醒一个。
public final native void notifyAll()：native 方法，并且不能重写。跟 notify 一样，唯一的区别就是会唤醒在此对象监视器上等待的所有线程，而不是一个线程。
public final native void wait(long timeout) throws InterruptedException：native 方法，并且不能重写。暂停线程的执行。注意：sleep 方法没有释放锁，而 wait 方法释放了锁 。timeout 是等待时间。
public final void wait(long timeout, int nanos) throws InterruptedException：多了 nanos 参数，这个参数表示额外时间（以毫微秒为单位，范围是 0-999999）。 所以超时的时间还需要加上 nanos 毫秒。
public final void wait() throws InterruptedException：跟之前的 2 个 wait 方法一样，只不过该方法一直等待，没有超时时间这个概念

反射：

public final native Class<?> getClass()：native 方法，用于返回当前运行时对象的 Class 对象，使用了 final 关键字修饰，故不允许子类重写。

垃圾回收：

protected void finalize() throws Throwable ：通知垃圾收集器回收对象。

设计模式——代理模式

动态代理

静态代理

Vector

ArrayList

LinkedList

List具体总结看

HashTable

HashMap

TreeMap

ConcurrentHashMap

Map具体总结看

传统的IO

NIO

NIO2(AIO)

概念区分

抽象类（Abstract Class）：

抽象类是一个可以包含抽象方法的类，抽象方法是一种没有具体实现的方法，只包含方法的签名（名称、参数和返回类型）。
抽象类可以包含普通方法，这些方法有具体实现。
子类继承抽象类时，必须提供实现父类的抽象方法。否则，子类也必须声明为抽象类。
抽象类可以包含实例变量，构造函数，属性（属性也可以是抽象的）等。
一个类只能继承一个抽象类，因为Java等编程语言中不支持多继承。

接口（Interface）：

接口是一种约定，定义了一组方法的声明，但没有具体实现。所有接口方法都是公开、抽象的。
类可以实现多个接口，这种多继承是通过实现不同接口来实现的。
接口中的方法没有方法体，只有方法签名，它们在实现类中被具体实现。
接口可以被看作是一种契约，规定了实现类必须提供的一组方法。
接口通常用于定义类之间的契约和通用行为，以实现多态性和代码的重用。

从语法形式上看：成员变量是属于类的，⽽局部变量是在⽅法中定义的变量或是⽅法的参数；成员变量可以被 public , private , static 等修饰符所修饰，⽽局部变量不能被访问控制修饰符及 static 所修饰；但是，成员变量和局部变量都能被 final 所修饰。

从变量在内存中的存储⽅式来看：如果成员变量是使⽤ static 修饰的，那么这个成员变量是属于类的，如果没有使⽤ static 修饰，这个成员变量是属于实例的。对象存于堆内存，如果局部变量类型为基本数据类型，那么存储在栈内存，如果为引⽤数据类型，那存放的是指向堆内存对象的引⽤或者是指向常量池中的地址。

从变量在内存中的⽣存时间上看：成员变量是对象的⼀部分，它随着对象的创建⽽存在，⽽局部变量随着⽅法的调⽤⽽⾃动消失。

成员变量如果没有被赋初值：则会⾃动以类型的默认值⽽赋值（⼀种情况例外:被 final 修饰的成员变量也必须显式地赋值），⽽局部变量则不会⾃动赋值。

静态变量和实例变量的区别？

静态⽅法和实例⽅法有何不同?

1. 什么是IO？

2. 常用的IO类有哪些？

3. 怎么理解 BIO、NIO、AIO？

4. 什么是比特（Bit）、字节（Byte）、字符（Char）？

5. 字节流和字符流的区别？

6. 讲一下Java的序列化吧？

7. TCP/IP四层模型/OSI七层模型有哪些？

8. TCP 和 UDP 协议的区别？

9. TCP为什么要三次握手，两次不可以吗？

java 范型了解吗？什么是类型擦除？介绍下通配符？

说一下你对注解的理解？

什么是反射？应用？原理？

jdk 1.8  都有哪些新特性

Lambda 表达式了解多少？

Optional 了解吗？

Stream 流用过吗？

树

排序算法

HTTP

HTTPS

区别

HTTP 1.0：

连接管理: HTTP 1.0使用短连接，即每个HTTP请求都需要一个新的TCP连接。这导致了较高的连接开销，因为每个连接的建立和断开都需要时间。
请求-响应模型: 在HTTP 1.0中，每个请求都对应一个响应，请求和响应之间是一对一的关系。
头部信息: HTTP 1.0的头部信息较少，只支持基本的头部字段。

HTTP 1.1：

连接管理: HTTP 1.1引入了持久连接（Keep-Alive），允许多个HTTP请求和响应通过同一个TCP连接传输。这减少了连接建立和断开的开销，提高了性能。
请求-响应模型: HTTP 1.1支持流水线化（Pipelining），允许多个请求在一个连接上并行发送，而不需要等待前一个请求的响应。这提高了效率。
头部信息: HTTP 1.1引入了更多的头部字段，包括缓存控制、内容协商、范围请求等。

HTTP 2.0：

二进制协议: HTTP 2.0采用二进制协议而不是文本协议，这减少了数据传输的开销。
多路复用: HTTP 2.0支持多路复用，允许多个请求和响应共享一个连接，无需等待。这极大提高了性能。
头部压缩: HTTP 2.0使用头部压缩技术，减小了每个请求的头部大小，减少了带宽占用。
服务器推送: HTTP 2.0允许服务器在客户端请求之前主动推送资源，提高了页面加载速度。

也就是说，HTTP 2.0在性能和效率方面有显著改进，主要通过多路复用、头部压缩和服务器推送来实现。HTTP 1.1在HTTP 1.0的基础上引入了持久连接和请求-响应的流水线化，但仍然使用文本协议。根据性能需求和服务器支持情况，可以选择不同的HTTP版本。

http 长连接 和 tcp 长连接 的区别

在 HTTP 1.0 中默认是关闭的，如果浏览器要开启 Keep-Alive，它必须在请求的包头中添加：
Connection: Keep-Alive

从 HTTP 1.1 开始， 就默认是开启了 Keep-Alive，如果要关闭 Keep-Alive，需要在 HTTP 请求的包头里添加：
Connection:close

现在大多数浏览器都默认是使用 HTTP/1.1，所以 Keep-Alive 都是默认打开的。一旦客户端和服务端达成协议，那么长连接就建立好了。

一般都会提供 keepalive_timeout 参数，用来指定 HTTP 长连接的超时时间。

都包含请求头请求行，POST多了请求Body

GET多用来查询，请求参数直接放到URL上。POST用来提交，一般放在请求体里面

GET可以在URL上看到内容，POST用户无法直接看到

GET提交的数据长度是有限的，URL长度有限制，POST没有

POST

GET

PUT

HEAD

DELETE

CONNECT

OPTIONS

TRACE

状态码

forward 和 redirect 的区别？

当浏览器第一次发送请求给服务器时，服务器响应了；如果同个浏览器发第二次请求给服务器时，它还会响应，但是呢，服务器不知道你就是刚才的那个浏览器。简言之，服务器不会去记住你是谁，所以称为无状态协议。

加密

对称加密

非对称加密

数字签名

数字证书

问题

CSRF，跨站请求伪造（英文全称 Cross-site request forgery），是一种
挟制用户在当前已登录的 Web 应用程序上执行非本意操作的攻击方法。

Socket 其实就等于 IP 地址 + 端口 + 协议。
WebSocket 是一个持久化的协议，它伴随 H5 而出的协议，用来解决 http 不
支持持久化连的问题。
Socket 一个网编编程的标准接口，而 WebSocket 则是应用层通信协议。

DOS: (Denial of Service),翻译过来就是拒绝服务,一切能引起 DOS 行为的攻击都被称为 DOS 攻击。
最常见的DoS 攻击就有计算机网络宽带攻击、连通性攻击。
DDoS: (Distributed Denial of Service),翻译过来的分布式拒绝服务。
是指处于不同位置的多个攻击者同时向一个或几个目标发动攻击，或者一个攻击者
控制了位于不同位置的多台机器并利用这些机器对受害者同时实施攻击。
常见的DDos 有 SYN Flood、Ping of Death、ACK Flood、UDP Flood等。
DRDoS: (Distributed Reflection Denial of Service)，中文的分布式反射拒绝服务，该方式靠发送大量带有被害者 IP 地址的数据包给攻击主机，然后
攻击主机对 IP 地址源做出大量回应，从而形成拒绝服务攻击。

XSS 攻击也是比较常见，XSS，叫跨站脚本攻击（Cross-Site Scripting），因为会与层叠样式表(Cascading Style Sheets, CSS)的缩写混淆，因此有人将跨站脚本攻击缩写为 XSS。它指的是恶意攻击者往 Web 页面里插入恶意 html 代码，当用户浏览该页之时，嵌入其中 Web 里面的 html代码会被执行，从而达到恶意攻击用户的特殊目的。XSS 攻击一般分三种类型：
存储型 、反射型 、DOM 型 XSS

如何攻击？

如何解决？

首先，就不能相信用户的输入，对输入进行过滤，过滤标签等，只允许合法值。
HTML 转义
对于链接跳转，如 <a href="xxx"等，要校验内容，禁止以 script 开头的非法
链接。
限制输入长度等等

SQL 注入是一种代码注入技术，一般被应用于攻击 web 应用程序。它通过在
web 应用接口传入一些特殊参数字符，来欺应用服务器，执行恶意的SQL 命
令，以达到非法获取系统信息的目的。它目前是黑客对数据库进行攻击的最
常用手段之一。

SQL 注入是如何攻击的？

如何防止？

1、输入地址

2、浏览器查找域名的 IP 地址

DNS

3、浏览器向 web 服务器发送一个 HTTP 请求

4、服务器的永久重定向响应

5、浏览器跟踪重定向地址

6、服务器处理请求

7、服务器返回一个 HTTP 响应

8、浏览器显示 HTML

9、浏览器发送请求获取嵌入在 HTML 中的资源（如图片、音频、视频、CSS、JS等等）

TCP协议是一种可靠的，基于字节流的，面向连接的传输层双工协议。它有以下三个特征：
1、通信双方的数据传输是稳定的，即便是在网络不好的情况下，也能够保证数据传输到目标端。
2、TCP通信双方的数据包传输是通过字节流来实现传输的
3、数据传输之前，必须要建立一个连接，然后基于这个连接进行数据传输

1）客户端向服务端发送连接请求并携带同步序列号SYN。
2）服务端收到请求后，发送SYN和ACK， 这里的SYN表示服务端的同步序列号，ACK表示对
前面收到请求的一个确认，表示告诉客户端，请求已收到。
3）客户端收到服务端的请求后，再次发送ACK，这个ACK是针对服务端连接的一个确认，表示
告诉服务端，请求已收到。

为什么要有三次握手呢？

TCP是可靠性通信协议，所以TCP协议的通信双方都必须要维护一个序列号，去标记已经发送出去的
数据包，哪些是已经被对方签收的。而三次握手就是通信双方相互告知序列号的起始值，为了确保这
个序列号被收到，所以双方都需要有一个确认的操作。
TCP协议需要在一个不可靠的网络环境下实现可靠的数据传输，意味着通信双方必须要通过某种手段
来实现一个可靠的数据传输通道，而三次通信是建立这样一个通道的最小值。当然还可以四次、五次，
只是没必要浪费这个资源。
防止历史的重复连接初始化造成的混乱问题，比如说在网络比较差的情况下，客户端连续多次发送建
立连接的请求，假设只有两次握手，那么服务端只能选择接受或者拒绝这个连接请求，但是服务端不
知道这次请求是不是之前因为网络堵塞而过期的请求，也就是说服务端不知道当前客户端的连接是有
效还是无效

TCP 四次挥手过程
1. 第一次挥手(FIN=1，seq=u)，发送完毕后，客户端进入 FIN_WAIT_1 状态。
2. 第二次挥手(ACK=1，ack=u+1,seq =v)，发送完毕后，服务器端进入
CLOSE_WAIT 状态，客户端接收到这个确认包之后，进入 FIN_WAIT_2 状态。
3. 第三次挥手(FIN=1，ACK1,seq=w,ack=u+1)，发送完毕后，服务器端进入
LAST_ACK 状态，等待来自客户端的最后一个 ACK。
4. 第四次挥手(ACK=1，seq=u+1,ack=w+1)，客户端接收到来自服务器端的关
闭请求，发送一个确认包，并进入 TIME_WAIT 状态，等待了某个固定时间（两
个最大段生命周期，2MSL，2 Maximum Segment Lifetime）之后，没
有收到服务器端的 ACK ，认为服务器端已经正常关闭连接，于是自己也关闭连接，
进入 CLOSED 状态。服务器端接收到这个确认包之后，关闭连接，进入
CLOSED 状态

为什么需要等待 2MSL,才进入 CLOSED 关闭状态

2MSL，two Maximum Segment Lifetime，即两个最大段生命周期。

1.为了保证客户端发送的最后一个 ACK 报文段能够到达服务端。 这个 ACK 报
文段有可能丢失，因而使处在 LAST-ACK 状态的服务端就收不到对已发送的
FIN + ACK 文段的确认。服务端会超时重传这个 FIN+ACK 文段，而客
户端就能在 2MSL 时间内（超时 + 1MSL 传输）收到这个重传的 FIN+ACK
文段。接着客户端重传一次确认，重新启动 2MSL 计时器。最后，客户端和
服务器都正常进入到 CLOSED 状态。

2. 防止已失效的连接请求在文段出现在本连接中。客户端在发送完最后一个
ACK 的文段后，再经过时间 2MSL，就可以使本连接持续的时间内所产生的所
有的文段都从网络中消失。这样就可以使下一个连接中不会出现这种旧连接请求的文段。

首先，TCP 的连接是基于三次握手，而断开则是基于四次挥手。确保链接和断开的
可靠性。
其次，TCP 的可靠性，还体现在有状态;TCP 会记录哪些数据发送了，哪些数据被
回收了，哪些没有被接受，并且保证数据包按序到达，保证数据传输不出差错。
再次，TCP 的可靠性，还体现在可控制。它有数据包校验、ACK 应答、**超时重
传(发送方)**、失数据重传（接收方）、丢弃重复数据、流量控制（滑动窗口）
和拥塞控制等机制。

连接性：

TCP是面向连接的协议。在数据传输之前，TCP建立连接，确保双方都准备好通信。这包括三次握手和四次挥手等步骤，以确保数据的可靠传输。
UDP是面向无连接的协议。它不建立连接，数据包可以直接发送，不会进行握手和挥手等过程。这使得UDP传输速度更快，但不保证数据的可靠性。

可靠性：

TCP提供可靠的数据传输。它使用确认机制、重传机制和流量控制等功能，确保数据包按顺序到达，没有丢失，没有错误。
UDP提供不可靠的数据传输。它不提供确认、重传或错误检测，数据包可能会丢失或乱序，因此用于那些要求速度高、实时性强的应用。

数据大小：

TCP通常用于传输大量数据，因为它可以将数据分割成多个数据包，然后在接收端重新组装。这适用于文件传输和Web页面下载等。
UDP通常用于传输小型数据包，如音频和视频流，DNS查询等，这些应用对实时性要求更高。

头部开销：

TCP的头部开销较大，约占数据包大小的10%。这是因为它包含了许多控制信息，如序号、确认、窗口大小等。
UDP的头部开销较小，只包含源端口、目标端口、长度和校验和等信息。

流量控制：

TCP有流量控制机制，用于避免拥塞。它根据接收端的处理能力来控制数据的发送速度。
UDP不具备流量控制功能，数据包可以随意发送。这可能导致网络拥塞，需要应用层自行处理。

基于 TCP ✁应用层协议有：HTTP、FTP、SMTP、TELNET、SSH
 HTTP：HyperText Transfer Protocol（超文本传输协议），默认端口 80
 FTP: File Transfer Protocol (文件传输协议), 默认端口(20 用于传输数据，
21用于传输控制信息)  SMTP: Simple Mail Transfer Protocol (简单邮件传输协议) ,默认端口 25
 TELNET: Teletype over the Network (网络电传), 默认端口 23
 SSH： Secure Shell（安全外壳协议），默认端口 22

TCP 协议具有重传机制，也就是说，如果发送方认为发生了丢包现象，就重发这些数据包。很显然，我们需要一个方法来「猜测」是否发生了丢包。最简单的想法就是，接收方每收到一个包，就向发送方返回一个 ACK，表示自己已经收到了这段数据，反过来，如果发送方一段时间内没有收到 ACK，就知道很可能是数据包丢失了，紧接着就重发该数据包，直到收到 ACK 为止。

即使是超时了，这个数据包也可能并没有丢，它只是到的很晚而已。毕竟 TCP 协议是位于传输层的协议，不可能明确知道数据链路层和物理层发生了什么。但这并不妨碍我们的超时重传机制，因为接收方会自动忽略重复的包。

超时怎么确定：

在这里先引入两个概念：
RTT（Round Trip Time）：往返时延，也就是数据包从发出去到收到对应 ACK 的时间。RTT 是针对连接的，每一个连接都有各自独立的 RTT。
RTO（Retransmission Time Out）：重传超时，也就是前面说的超时时间。

基于计时器的重传

这种机制下，每个数据包都有相应的计时器，一旦超过 RTO 而没有收到 ACK，就重发该数据包。没收到 ACK 的数据包都会存在重传缓冲区里，等到 ACK 后，就从缓冲区里删除。

首先明确一点，对 TCP 来说，超时重传是相当重要的事件（RTO 往往大于两倍的 RTT，超时往往意味着拥塞），一旦发生这种情况，TCP 不仅会重传对应数据段，还会降低当前的数据发送速率，因为TCP 会认为当前网络发生了拥塞。

快速重传

快速重传机制「RFC5681」基于接收端的反馈信息来引发重传，而非重传计时器超时。

刚刚提到过，基于计时器的重传往往要等待很长时间，而快速重传使用了很巧妙的方法来解决这个问题：服务器如果收到乱序的包，也给客户端回复 ACK，只不过是重复的 ACK。就拿刚刚的例子来说，收到乱序的包 6,7,8,9 时，服务器全都发 ACK = 5。这样，客户端就知道 5 发生了空缺。一般来说，如果客户端连续三次收到重复的 ACK，就会重传对应包，而不需要等到计时器超时。

带选择确认的重传
改进的方法就是 SACK（Selective Acknowledgment），简单来讲就是在快速重传的基础上，返回最近收到的报文段的序列号范围，这样客户端就知道，哪些数据包已经到达服务器了。

来几个简单的示例：

case 1：第一个包丢失，剩下的 7 个包都被收到了。
当收到 7 个包的任何一个的时候，接收方会返回一个带 SACK 选项的 ACK，告知发送方自己收到了哪些乱序包。注：Left Edge，Right Edge 就是这些乱序包的左右边界。
case 2：第 2, 4, 6, 8 个数据包丢失。
收到第一个包时，没有乱序的情况，正常回复 ACK。
收到第 3, 5, 7 个包时，由于出现了乱序包，回复带 SACK 的 ACK。
因为这种情况下有很多碎片段，所以相应的 Block 段也有很多组，当然，因为选项字段大小限制， Block 也有上限。

不过 SACK 的规范「RFC2018」有点坑爹，接收方可能会在提供一个 SACK 告诉发送方这些信息后，又「食言」，也就是说，接收方可能把这些（乱序的）数据包删除掉，然后再通知发送方。

最后一句是说，当接收方缓冲区快被耗尽时，可以采取这种措施，当然并不建议这种行为。。。

由于这个操作，发送方在收到 SACK 以后，也不能直接清空重传缓冲区里的数据，一直到接收方发送普通的，ACK 号大于其最大序列号的值的时候才能清除。另外，重传计时器也收到影响，重传计时器应该忽略 SACK 的影响，毕竟接收方把数据删了跟丢包没啥区别。

DSACK 扩展
DSACK，即重复 SACK，这个机制是在 SACK 的基础上，额外携带信息，告知发送方有哪些数据包自己重复接收了。DSACK 的目的是帮助发送方判断，是否发生了包失序、ACK 丢失、包重复或伪重传。让 TCP 可以更好的做网络流控。

半连接队列
当客户端发送SYN到服务端，服务端收到以后回复ACK和SYN，状态由LISTEN变为SYN_RCVD，此时这个连接就被推入了SYN队列，也就是半连接队列。

全连接队列
当客户端返回ACK, 服务端接收后，三次握手完成。这个时候连接等待被具体的应用取走，在被取走之前，它会被推入另外一个 TCP 维护的队列，也就是全连接队列(Accept Queue)。

SYN Flood 攻击原理
SYN Flood 属于典型的 DoS/DDoS 攻击。其攻击的原理很简单，就是用客户端在短时间内伪造大量不存在的 IP地址，并向服务端疯狂发送SYN。对于服务端而言，会产生两个危险的后果:

处理大量的SYN包并返回对应ACK, 势必有大量连接处于SYN_RCVD状态，从而占满整个半连接队列，无法处理正常的请求。
由于是不存在的 IP，服务端长时间收不到客户端的ACK，会导致服务端不断重发数据，直到耗尽服务端的资源。

如何应对 SYN Flood 攻击？
增加 SYN 连接，也就是增加半连接队列的容量。
减少 SYN + ACK 重试次数，避免大量的超时重发。
利用 SYN Cookie技术，在服务端接收到SYN后不立即分配连接资源，而是根据这个SYN计算出一个Cookie，连同第二次握手回复给客户端，在客户端回复ACK的时候带上这个Cookie值，服务端验证Cookie 合法之后才分配连接资源。

半连接队列和 SYN Flood 攻击的关系
三次握手前，服务端的状态从CLOSED变为LISTEN, 同时在内部创建了两个队列：
半连接队列和全连接队列，即SYN队列和ACCEPT队列。
半连接队列是当客户端发送SYN到服务端，服务端收到以后回复ACK和SYN，状态由LISTEN变为SYN_RCVD，此时这个连接就被推入了SYN队列
SYN Flood在短时间内伪造大量不存在的 IP地址，并向服务端疯狂发送SYN。处理大量的SYN包并返回对应ACK, 势必有大量连接处于SYN_RCVD状态，从而占满整个半连接队列，无法处理正常的请求。

TCP是面向字节流的协议，就是没有界限的一串数据，本没有“包”的概念，“粘包”和“拆包”一说是为了有助于形象地理解这两种现象。

为什么UDP没有粘包？
粘包拆包问题在数据链路层、网络层以及传输层都有可能发生。日常的网络应用开发大都在传输层进行，由于UDP有消息保护边界，不会发生粘包拆包问题，因此粘包拆包问题只发生在TCP协议中。

粘包拆包发生场景
因为TCP是面向流，没有边界，而操作系统在发送TCP数据时，会通过缓冲区来进行优化，例如缓冲区为1024个字节大小。
如果一次请求发送的数据量比较小，没达到缓冲区大小，TCP则会将多个请求合并为同一个请求进行发送，这就形成了粘包问题。
如果一次请求发送的数据量比较大，超过了缓冲区大小，TCP就会将其拆分为多次发送，这就是拆包。

常见的解决方案
对于粘包和拆包问题，常见的解决方案有四种：

发送端将每个包都封装成固定的长度，比如100字节大小。如果不足100字节可通过补0或空等进行填充到指定长度；
发送端在每个包的末尾使用固定的分隔符，例如\r\n。如果发生拆包需等待多个包发送过来之后再找到其中的\r\n进行合并；例如，FTP协议；
将消息分为头部和消息体，头部中保存整个消息的长度，只有读取到足够长度的消息之后才算是读到了一个完整的消息；
通过自定义协议进行粘包和拆包的处理。

Netty对粘包和拆包问题的处理
Netty对解决粘包和拆包的方案做了抽象，提供了一些解码器（Decoder）来解决粘包和拆包的问题。如：

LineBasedFrameDecoder：以行为单位进行数据包的解码；
DelimiterBasedFrameDecoder：以特殊的符号作为分隔来进行数据包的解码；
FixedLengthFrameDecoder：以固定长度进行数据包的解码；
LenghtFieldBasedFrameDecode：适用于消息头包含消息长度的协议（最常用）；
基于Netty进行网络读写的程序，可以直接使用这些Decoder来完成数据包的解码。对于高并发、大流量的系统来说，每个数据包都不应该传输多余的数据（所以补齐的方式不可取），LenghtFieldBasedFrameDecode更适合这样的场景。

小结
TCP协议粘包拆包问题是因为TCP协议数据传输是基于字节流的，它不包含消息、数据包等概念，需要应用层协议自己设计消息的边界，即消息帧（Message Framing）。如果应用层协议没有使用基于长度或者基于终结符息边界等方式进行处理，则会导致多个消息的粘包和拆包。

Nagle算法
1、如果没有『未确认的包』，立马发送当前包。这是首要原则
2、否则累积缓冲区的数据，直到没有『未确认的包』|| 累积的数据达到『MSS』的大小，立马发送数据
ps：||表示或者
总之重点就是不要一有数据就发送，我们要尽量的积攒一些数据然后发送。

ACK延迟确认
1、收到数据包之后不急着给ack，而是等待
2、如果一直收不到其他的数据包，等待一个『最大等待时间』，然后发送ack包
3、如果在等待的过程中，收到了其他数据包，立马发送ack包。
4、如果在等待的过程中，自己也有数据要发送给对方，那么顺便发送
总之重点就是不要一收到数据就发送确认，我们要尽量减少单纯的确认包。

一般可以这么认为，IP 地址=网络号+主机号。
1. 网络号：它标志主机所连接的网络地址表示属于互联网的哪一个网络。
2. 主机号：它标志主机地址表示其属于该网络中的哪一台主机。
IP 地址分为 A，B，C，D，E 五大类：
 A 类地址(1~126)：以 0 开头，网络号占前 8 位，主机号占后面 24 位。
 B 类地址(128~191)：以 10 开头，网络号占前 16 位，主机号占后面 16 位。
 C 类地址(192~223)：以 110 开头，网络号占前 24 位，主机号占后面 8 位。
 D 类地址(224~239)：以 1110 开头，保留位多播地址。
 E 类地址(240~255)：以 11110 开头，保留位为将来使用

ARP 协议的全称是 Address Resolution Protocol(地址解析协议)，它是一个通过用于实现从 IP 地址到 MAC 地址的映射，即询问目标 IP 对应的 MAC 地址 的一种协议。ARP 协议在 IPv4 中极其重要。

注意：
ARP 只用于 IPv4 协议中，IPv6 协议使用的是 Neighbor Discovery Protocol，译为邻居发现协议，它被纳入 ICMPv6 中。
简而言之，ARP 就是一种解决地址问题的协议，它以 IP 地址为线索，定位下一个应该接收数据分包的主机 MAC 地址。如果目标主机不在同一个链路上，那么会查找下一跳路由器的 MAC 地址。

IP地址将物理地址对上层隐藏起来，使Internet表现出统一的地址格式，但是在实际通讯时，IP地址不能被物理网络所识别物理网络所使用的依然是物理地址。因此必须实现IP地址对物理地址的映射。

对于以太网而言，当IP数据包通过以太网发送时，以太网链路并不识别32位的IP地址，它们是以48位的MAC地址表示该以太网节点。因此，必须在IP地址与MAC地址之间简历映射关系（MAP），而建立这种映射的过程咱们称之为地址解析（Resoloution）。

如上图中，假设HostA和HostB在同一个网段，HostA要向HostB发送IP包，其地址解析过程如下：

1.HostA首先查看自己的ARP表项，确定其中是否包含HostB的IP地址对应ARP表项。如果找到了对应的表项，则HostA直接理由ARP表项中的MAC地址对IP数据包封装成帧，并将帧发送给HostB。

2.如果HostA在ARP表中找不到对应的表项，则暂时缓存该数据包，然后以广播方式发送一个ARP轻轻。ARP请求报文中的发送端IP地址和发送端MAC地址为HostA的IP地址和MAC地址，目标IP地址HostB的IP地址，目标MAC地址为全0的MAC地址。

3.由于ARP请求报文以广播方式发送，该网段上的所有主机都可以接收到该请求。HostB比较自己的IP地址和ARP请求报文中的目标IP地址，由于两者相同，HostB将ARP请求报文中的发送端（HostA）IP地址和MAC地址存入自己的ARP表中，并以单播方式HostA发送ARP响应，其中包含了自己的MAC地址。其他主机发送请求的IP地址并非自己，于是都不做应答。

4.HostA收到ARP响应报文后，将HostB的MAC地址加入到自己的ARP表中，同时将IP数据包用此MAC地址为目的地址封装成帧并发送给HostB。

IP地址：

IP地址是用于在互联网上唯一标识和寻址设备的地址。
它是网络层协议的一部分，允许数据在不同网络之间传输，因此它是全球范围内唯一的。
IP地址是逻辑地址，用于在网络中路由数据包。它们通常分为IPv4地址（32位）和IPv6地址（128位）。

MAC地址：

MAC地址是用于在局域网络（Local Area Network，LAN）中唯一标识和寻址网络设备的地址。
它是数据链路层（Data Link Layer）协议的一部分，用于在局域网络上直接传输数据包。
MAC地址通常是硬件地址，与设备的物理网络适配器（通常是网卡）相关。每个网络适配器都有唯一的MAC地址。

为什么需要同时使用IP地址和MAC地址：

IP地址用于在全球范围内唯一标识设备并进行路由，以确保数据能够从一个网络到另一个网络。
MAC地址用于在局域网络中唯一标识设备，以便在同一局域网络内直接传输数据帧。
在局域网络内，设备通常通过ARP（Address Resolution Protocol）将IP地址解析为MAC地址。ARP协议可以帮助设备找到其他设备的MAC地址，以便它们可以直接通信。所以，MAC地址是局域网络内的“物理地址”，而IP地址则是更高层次的逻辑地址，用于在全球互联网上唯一标识设备。

在传统的Js中，如果想发送客户端信息到服务器，需要建立一个HTML 表单然后GET或者POST数据到服务器端用户需要点击提交按钮来发送数据信息，然后等待服务器响应请求，页面重新加载使用AJAX技术，就可以使Javascript通过XMLHttpRequest对象直接与服务器进行交互

MVC开始是存在于Desktop程序中的，M是指数据模型，V是指用户界面，C则是控制器，使用MVC的目的是将M和V的实现代码分离。C存在的目的则是确保M和V的同步，一旦M改变，V应该同步更新。

视图是用户看到并与之交互的界面，视图没有真正的处理发生，不管这些数据是联机存储的还是一个雇员列表，作为视图来讲，它只是作为一种输出数据并允许用户操纵的方式。

模型表示企业数据和业务规则，模型返回的数据是中立的，就是说模型与数据格式无关，这样一个模型能为多个视图提供数据，由于应用于模型的代码只需写一次就可以被多个视图重用，所以减少了代码的重复性。

控制器接受用户的输入并调用模型和视图去完成用户的需求，控制器本身不输出任何东西和做任何处理。它只是接收请求并决定调用哪个模型构件去处理请求，然后再确定用哪个视图来显示返回的数据。

C设计模式考虑三种对象：模型对象、视图对象、和控制器对象。模型对象代表特别的知识和专业技能，它们负责保有应用程序的数据和定义操作数据的逻辑。视图对象知道如何显示应用程序的模型数据，而且可能允许用户对其进行编辑。控制器对象是应用程序的视图对象和模型对象之间的协调者。

过滤器和拦截器触发时机不一样:过滤器是在请求进入容器后，但请求进入 servlet 之前进行预处理的。请求结束返回也是，是在 servlet 处理完后，返回给前端之前。

拦截器是基于java的反射机制的，而过滤器是基于函数回调。

拦截器不依赖与servlet容器，过滤器依赖与servlet容器。

拦截器只能对action请求起作用，而过滤器则可以对几乎所有的请求起作用。

拦截器可以访问action上下文、值栈里的对象，而过滤器不能访问。

在action的生命周期中，拦截器可以多次被调用，而过滤器只能在容器初始化时被调用一次。

拦截器可以获取 IOC 容器中的各个 bean ，而过滤器就不行，这点很重要，在拦截器里注入一个 service，可以调用业务逻辑。

token类似一个令牌，无状态，用户信息都被加密到token中，服务器收到token后解密就可知道是哪个用户。需要开发者手动添加。

session存储于服务器，可以理解为一个状态列表，拥有一个唯一识别符号sessionId，通常存放于cookie中。服务器收到cookie后解析出sessionId，再去session列表中查找，才能找到相应session。依赖cookie

cookie类似一个令牌，装有sessionId，存储在客户端，浏览器通常会自动添加。cookies是明文存储，安全性很低，只使用cookie的话盗取了cookie基本就获取了用户所有权限。

Access-Control-Allow-Origin

Access-Control-Allow-Credentials

客户端本来可以直接通过HTTP协议访问某网站应用服务器，网站管理员可以在中间加上一个Nginx，客户端请求Nginx，Nginx请求应用服务器，然后将结果返回给客户端，此时Nginx就是反向代理服务器。

反向代理

正向代理

区别

命名规则：URI本质上是一个资源，一个独立的URI地址对应一个独一无二的资源。如果需要对资源进行操作，采用get或者post请求。

MySQL的基本架构

查询语句执行顺序

更新语句执行顺序，两阶段提交

日志模块

简介

隔离性与隔离级别

那ACID靠什么保证呢？

事务隔离的实现

事务的启动方式

事务的启动时机

视图 / MVCC

可重复读/读提交 的实现

数据库锁设计的初衷是处理并发问题。作为用户共享资源，当出现并发访问时，数据库需要合理控制资源的访问规则。锁是用来实现这些访问规则的重要数据结构

锁的分类/锁的粒度

锁模式

加锁机制

兼容性

遇到过死锁吗？如何解决？

简介

索引分类

常见的索引模型

InnoDB索引模型 —— 【B+树】

为什么用B+树，而不是用普通二叉树

为什么用B+树而不用B树？

hash索引和B+树索引区别是什么

聚簇索引与非聚簇索引的区别？

创建索引有哪些要注意的点

索引优化原则技巧

选择普通索引还是唯一索引

MySQL什么时候会选错索引

索引哪些情况下会失效？

哪些场景不是适用索引

给字符串创建索引

回表了解吗？

表空间回收

count() 实践

order by 实践

随机显示消息
https://time.geekbang.org/column/article/73795

导致SQL性能的原因

慢SQL如何定位

慢sql 的优化方式

怎么看执行计划（explain），如何理解其中各个字段的含义？

了解深度分页的问题吗？

基础

存储引擎

高性能/高可用

运维

Redis是一个基于Key-Value存储结构的Nosql开源内存数据库。
它提供了5种常用的数据类型，String、Map、Set、ZSet、List。
针对不同的结构，可以解决不同场景的问题。
因此它可以覆盖应用开发中大部分的业务场景，比如

1. 缓存：Redis最常用于作为缓存层，可以用来缓存数据库查询结果或其他计算密集型操作的中间结果。因为Redis将数据存储在内存中，读取速度非常快，可以显著减轻后端数据库的负担，提高应用性能。

2. 会话管理：Redis可以用来管理用户会话，存储用户登录状态、购物车数据和其他需要跨请求保持的信息。它比传统的基于文件或数据库的会话管理方式更高效。

3. 发布/订阅系统：Redis支持发布/订阅模式，允许应用程序发布信息给多个订阅者。这在构建实时消息传递系统和通知系统中非常有用。

4. 计数器：Redis可以用来创建计数器，例如网站的访问计数器、点赞计数器等。

5. 地理空间索引：Redis支持存储地理空间信息，可以用来构建位置相关的应用，如附近的人、地点搜索等。

6. 队列：Redis的列表数据结构可用于构建任务队列，支持异步任务处理。

7. 持久化：Redis提供了多种持久化选项，以确保数据在服务器重启后不会丢失。

8. 数据结构存储：Redis支持各种数据结构，如字符串、哈希、列表、集合、有序集合等。这使得它可以用于更复杂的应用，包括排行榜、消息队列等。

9. 分布式锁：Redis可以用于实现分布式锁，确保在分布式系统中的多个节点之间实现同步。

最后，作为企业级开发来说，它又提供了主从复制+哨兵、以及集群方式实现高可用在Redis集群里
面，通过hash槽的方式实现了数据分片，进一步提升了性能。

String（字符串）
 

Hash（哈希）

List（列表）

Set（集合）

有序集合（zset）

Redis 的三种特殊数据类型

Geo：Redis3.2 推出的，地理位置定位，用于存储地理位置信息，并对存储的信息进行操作。
HyperLogLog：用来做基数统计算法的数据结构，如统计网站的 UV。
Bitmaps ：用一个比特位来映射某个元素的状态，在 Redis 中，它的底层是基于字符串类型实现的 ，可以把 bitmaps 成作一个以比特位为单位的数组

基于内存存储实现

高效的数据结构

合理的数据编码

合理的线程模型

采用单线程，避免了不必要的上下文切换和竞争条件，也不存在多进程或者多线程导致的切换而消耗 CPU，不用去考虑各种锁的问题，不存在加锁释放锁操作，没有因为可能出现死锁而导致的性能消耗；

常见的IO多路复用机制的实现方式有： select 、poll、epoll

select 模型，它的基本原理是，采用轮询和遍历的方式。也就是说，在客户端操作服务器时，会创建三种文件描述符，简称FD。分别是writefds（写描述符）、readfds（读描述符）和 exceptfds（异常描述符）。

而select会阻塞监视这三种文件描述符，等有数据、可读、可写、出异常或超时都会返回；
返回后通过遍历fdset，也就是文件描述符的集合，来找到就绪的FD，然后，触发相应的IO操作。
优点：跨平台支持性好，几乎所有的平台上支持
它的缺点也很明显，由于select是采用轮询的方式进行全盘扫描，因此，随着FD数量增多而导致性能下降。

因此，每次调用select()方法，都需要把FD集合从用户态拷贝到内核态，并进行遍历。而操作系统对单个进程打开的FD数量是有限制的，一般默认是1024个。虽然，可以通过操作系统的宏定义FD_SETSIZE修改最大FD数量限制，但是，在IO吞吐量巨大的情况下，效率提升仍然有限。

poll 模型的原理与select模型基本一致，也是采用轮询加遍历，唯一的区别就是 poll 采用链表
的方式来存储FD。
所以，它的优点点是没有最大FD的数量限制。
它的缺点和select一样，也是采用轮询方式全盘扫描，同样也会随着FD数量增多而导致性能下
降。

epoll模型
由于select和poll都会因为吞吐量增加而导致性能下降，因此，才出现了epoll模型。
epoll模型是采用时间通知机制来触发相关的IO操作。它没有FD个数限制，而且从用户态拷贝
到内核态只需要一次。它主要通过系统底层的函数来注册、激活FD，从而触发相关的 IO 操作，这样
大大提高了性能。主要是通过调用以下三个系统函数：
1、epoll_create()函数，在系统启动时，会在Linux内核里面申请一个B+树结构的文件系统，
然后，返回epoll对象，也是一个FD。
2、epoll_ctl()函数，每新建一个连接的时候，会同步更新epoll对象中的FD，并且绑定一个
callback回调函数。
3、epoll_wait()函数，轮询所有的callback集合，并触发对应的 IO 操作

所以，epoll模型最大的优点是将轮询改成了回调，大大提高了CPU执行效率，也不会随FD数量
的增加而导致效率下降。当然，它也没有FD数量限制，也就是说，它能支持的FD上限是操作系统的最大文件句柄数。一般而言，1G 内存大概支持 10 万个句柄。分布式系统中常用的组件如Redis、
Nginx都是优先采用epoll模型。它的缺点是只能在Linux下工作。

什么是热 Key 呢？在 Redis 中，我们把访问频率高的 key，称为热点key。
如果某一热点 key 的请求到服务器主机时，由于请求量特别大，可能会导致主机资源 不足，甚至宕机，从而影响正常的服务。
热点key是怎么产生的呢？主要原因有两个：
1. 用户消费的数据远大于生产的数据：秒杀，热点新闻，等读多写少的场景
2. 请求分片集中，超过单 Redi 服务器的性能，比如固定名称 key，Hash 落入同一台服务器，瞬间访问量极大，超过机器瓶颈，产生热点 Key 问题。

如何识别到热key?

凭经验判断哪些是热 Key；
客户端统计上报；
服务代理层上报

如何解决热 key 问题？

Redis 集群扩容：增加分片副本，均衡读流量；
将热 key 分散到不同的服务器中；
使用二级缓存，即 JVM 本地缓存,减少 Redis 的读请求。

定时过期

惰性过期

定期过期

Redis 中同时使用了惰性过期和定期过期两种过期策略。

redis.conf中 有一行配置 # maxmemory-policy

noeviction ： 当内存不足时，新写入的数据会报错（不推荐）

allkeys-lru : 当内存不足以容纳新写入数据时，在建空间中移除最近最少使用的key（推荐）

allkeys-random：当内存不足以写入新数据时，在键空间中随机移除某个key（不推荐）

volatile-lru：当内存不足时，在设置了过期时间的键空间中移除最近最少使用的key。（不推荐）

volatile-random：当内存不足时，在设置了过期时间的键空间中随机移除一个值（不推荐）

volatile-ttl：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中有更早过期时间的key优先移除（不推荐）

缓存穿透

缓存雪崩

缓存击穿

缓存
不仅可以提升网站的访问速度，还可以
降低数据库 DB 的压力。并且，Redis 相比于 memcached，还提供了丰富的数据结构，并且提供 RDB 和 AOF 等持久化机制。

排行榜
Redis 提供的 zset数据类型能够实现这些复杂的排行榜。

计数器应用
各大网站、APP 应用经常需要计数器的功能，如短视频的播放数、电商网站的浏览数。这些播放数、浏览数一般要求实时的，每一次播放和浏览都要做加1的操作，如果并发量很大对于传统关系型数据的性能是一种挑战。Redis 天然支持计数功能而且计数的性能也非常好，可以说是计数器系统的重要选择。

共享Session
如果一个分布式 Web 服务将用户的 Session 信息保存在各自服务器，用户刷新一次可能就需要重新登录了，这样显然有问题。实际上，可以使用 Redis将用户的 Session 进行集中管理，每次用户更新或者查询登录信息都直接从Redis 中集中获取。

分布式锁
几乎每个互联网公司中都使用了分布式部署，分布式服务下，就会遇到对同一个资源的并发访问的技术难题，如秒杀、下单减库存等场景。
用 synchronize 或者reentrantlock 本地锁肯定是不行的。
如果是并发量不大话，使用数据库✁悲观锁、乐观锁来实现没啥问题。
但是在并发量高的场合中，利用数据库锁来控制资源的并发访问，会影响数据库的性能。
实际上，可以用 Redis 的setnx 来实现分布式锁。

社交网络
赞/踩、粉丝、共同好友/喜好、推送、下拉刷新等是社交网站的必备功能，由于社交网站访问量通常比较大，而且传统的关系型数据不太适保存 这种类型的数据，Redis 提供的数据结构可以相对比较容易地实现这些功能。

消息队列
消息队列是大型网站必用中间件，如 ActiveMQ、RabbitMQ、Kafka 等流行的消息队列中间件，主要用于业务解耦、流量削峰及异步处理实时性低的业务。
Redis 提供了发布/订阅及阻塞队列功能，能实现一个简单的消息队列系统。另外，这个不能和专业的消息中间件相比。

位操作
用于数据量上亿的场景下，例如几亿用户系统的签到，去重登录次数统计，某用户是否在线状态等等。腾讯 10 亿用户，要几个毫秒内查询到某个用户是否在线，能怎么做？这里要用到位操作——使用 setbit、getbit、bitcount 命令。原理是：redis 内构一个足够长的数组，每个数组元素只能是 0 和 1 两个值，然后这个数组的下标 index 用来表示用户id（必须是数字哈），那么很显然，这个几亿长的大数组就能通过下标和元素值（0 和 1）来构成一个记忆系统。

首先，Redis本身是一个基于Key-Value结构的内存数据库，为了避免Redis故障导致数据丢失的问题，所以提供了RDB和AOF两种持久化机制。

RDB

RDB持久化是把当前进程数据生成快照保存到硬盘的过程，触发RDB持久化过程分为手动触发和自动触发。

RDB⽂件是⼀个压缩的⼆进制⽂件，通过它可以还原某个时刻数据库的状态。由于RDB⽂件是保存在硬盘上的，所以即使Redis崩溃或者退出，只要RDB⽂件存在，就可以⽤它来恢复还原数据库的状态。

AOF

AOF（append only file）持久化：以独立日志的方式记录每次写命令， 重启时再重新执行AOF文件中的命令达到恢复数据的目的。AOF的主要作用是解决了数据持久化的实时性，目前已经是Redis持久化的主流方式。

AOF的工作流程操作：命令写入 （append）、文件同步（sync）、文件重写（rewrite）、重启加载 （load）

RDB和AOF如何选择？
（1）一般来说， 如果想达到足以媲美数据库的 数据安全性，应该 同时使用两种持久化功能。在这种情况下，当 Redis 重启的时候会优先载入 AOF 文件来恢复原始的数据，因为在通常情况下 AOF 文件保存的数据集要比 RDB 文件保存的数据集要完整。
（2）如果 可以接受数分钟以内的数据丢失，那么可以 只使用 RDB 持久化。
（3）有很多用户都只使用 AOF 持久化，但并不推荐这种方式，因为定时生成 RDB 快照（snapshot）非常便于进行数据备份， 并且 RDB 恢复数据集的速度也要比 AOF 恢复的速度要快，除此之外，使用 RDB 还可以避免 AOF 程序的 bug。
（4）如果只需要数据在服务器运行的时候存在，也可以不使用任何持久化方式。

为了实现高可用，通常的做法是，将数据库复制多个副本以部署在不同的服务器上，其中一台挂了也可以继续提供服务。 Redis 实现高可用有三种部署模式：主从模式，哨兵模式，集群模式。

主从模式

Redis 高可用回答包括两个层面，一个就是数据不能丢失，或者说尽量减少丢失;另外一个就是保证 Redis 服务不中断。
    1. 对于尽量减少数据丢失，可以通过 AOF 和 RDB 保证。
    2.对于保证服务不中断的话，Redis 就不能单点部署，这时候我们先看下 Redis 主从。

哨兵模式

Redis Cluster 集群

Cluster 集群节点的通讯协议：Gossip

故障转移

故障恢复：故障发现后，如果下线节点的主节点，则需要在它的从节点中选一个替换它，以保证集群的高可用。流程如下：

命令 setnx + expire 分开写

setnx + value 值的过期时间

set 的扩展命令（set ex px nx）（注意可能存在的问题）

set ex px nx + 校验唯一随机值,再删除

分布式锁可能存在锁过期释放，业务没执行完的问题。有些小伙伴认为，稍微把锁过期时间设置长一些就可以啦。其实我们设想一下，是否可以给获得锁的线程，开启一个定时守护线程，每隔一段时间检查锁是否还存在，存在则对锁的过期时间延长，防止锁过期提前释放。
当前开源框架Redisson 就解决了这个分布式锁问题。我们一起来看下
Redisson 底层原理是怎样的吧：

只要线程一加锁成功，就会启动一个 watch dog看门狗，它的一个后台线程，会每隔 10 秒检查一下，如果线程 1 还持有锁，那么就会不断地延长锁 key
的生存时间。因此，Redisson 就是使用 Redisson 解决了锁过期释放，业务没执行完问题。

Redis 一般都是集群部署的，假设数据在主从同步过程，主节点挂了，Redis 分布式锁可能会有哪些问题呢？一起来看些这个流程图：

如果线程一在 Redis 的master 节点上拿到了锁，但是加锁的 key 还没同步到 slave 节点。
恰好这时，master 节点发生故障，一个 slave 节点就会升级为master 节点。
线程二就可以获取同个 key 的锁啦，但线程一也已经拿到锁了，锁的安全性就没了。
为了解决这个问题，Redis 作者 antirez 提出一种高级的分布式锁算法：Redlock。

Redlock 核心思想是这样的：
搞多个Redis master 部署，以保证它们不会同时宕掉。并且这些 master 节点是完全相互独立的，相互之间不存在数据同步。同时，需要确保在这多个
master 实例上，是与在 Redis 单实例，使用相同方法来获取和释放锁。

按顺序向 5 个 master 节点请求加锁
根据设置的超时时间来判断，要不要跳过该 master 节点。
如果大于等于三个节点加锁成功，并且使用的时间小于锁的有效期，即可认定加锁成功啦。
如果获取锁失败，解锁！

跳跃表
跳跃表是有序集合 zset 的底层实现之一
跳跃表支持平均 O（logN）,最坏 O（N）复杂度的节点查找，还可以通过顺序性操作批量处理节点。
跳跃表实现由 zskiplist 和 zskiplistNode 两个结构组成，其中 zskiplist 用于 保存跳跃表信息（如表头节点、表尾节点、长度），而 zskiplistNode 则用于表示跳跃表节点。
跳跃表就是在链表的基础上，增加多级索引提升查找效率。

缓存延时双删

删除缓存重试机制

读取binlog异步缓存

Redis6.0 之前，Redis 在处理客户端的请求时，包括读 socket、解析、执行、写socket 等都由一个顺序串行的主线程处理，这就是所谓的“单线程”。

Redis6.0 之前为什么一直不使用多线程？使用 Redis 时，几乎不存在 CPU 成为瓶颈的情况， Redis 主要受限于内存和网络。例如在一个普通的Linux 系统上，Redis 通过使用 pipelining 每秒可以处理 100 万个请求，所以如果应用程序主要使用 O(N)或 O(log(N))的命令，它几乎不会占用过多 CPU。

redis 使用多线程并非是完全摒弃单线程，redis 还在使用单线程模型来处理客户端的请求，只是使用多线程来处理数据来读写和协议解析，执行命令还是使用单线程。这样做的目的是因为 redis 的性能瓶颈在于网络 IO 而非 CPU，使用多线程能提升 IO 读写的效率，从而整体提高 redis 的性能。

Redis 通过 MULTI、EXEC、WATCH 等一组命令集合，来实现事务机制。
事务支持一次执行多个命令，一个事务中所有命令都会被序列化。在事务执行过程，会按照顺序串行化执行队列中的命令，其他客户端提交的命令请求不会插入到事务执行命令序列中。
简言之，Redis 事务就是顺序性、一次性、排他性的执行一个队列中的一系列命令。
Redis 执行事务的流程如下：
 开始事务（MULTI）
 命令入队
 执行事务（EXEC）、撤销事务（DISCARD ）

EXEC 执行所有事务块内的命令

DISCARD 取消事务，放弃执行事务块内的所有命令

MULTI 标记一个事务块的开始

UNWATCH   WATCH 命令对所有 key 的监视。

WATCH  监视key ，如果在事务执行之前，该 key 被其他命令所改动，那么事
务将被打断。

java中的hashmap

Redis 提供两个指令生成 RDB，分别是 save 和 bgsave。
 如果是 save 指令，会阻塞，因为是主线程执行的。
 如果是 bgsave 指令，fork 一个子进程来写入 RDB 文件，快照持久化完全交给子进程来处理，父进程则可以继续处理客户端的请求。

RESP，英文全称是 Redis Serialization Protocol,它专门为 redis 设计的一套序列化协议. 这个协议其实在 redis 的1.2 版本时就已经出现了,但是到了redis2.0 才最终成为redis 通讯协议的标准。

RESP 主要有实现简单、解析速度快、可读性好等优点。

第一个，从Redis服务端层面。
Redis Server本身是一个线程安全的K-V数据库，也就是说在Redis Server上执行的指令，不需要任
何同步机制，不会存在线程安全问题。
虽然Redis 6.0里面，增加了多线程的模型，但是增加的多线程只是用来处理网络IO事件，对于指令
的执行过程，仍然是由主线程来处理，所以不会存在多个线程通知执行操作指令的情况。

为什么Redis没有采用多线程来执行指令，我认为有几个方面的原因。
Redis Server本身可能出现的性能瓶颈点无非就是网络IO、CPU、内存。但是CPU不是Redis的瓶颈
点，所以没必要使用多线程来执行指令。
如果采用多线程，意味着对于redis的所有指令操作，都必须要考虑到线程安全问题，也就是说需要
加锁来解决，这种方式带来的性能影响反而更大。

第二个，从Redis客户端层面。
虽然Redis Server中的指令执行是原子的，但是如果有多个Redis客户端同时执行多个指令的时候，
就无法保证原子性。
假设两个redis client同时获取Redis Server上的key1，同时进行修改和写入，因为多线程环境下的
原子性无法被保障，以及多进程情况下的共享资源访问的竞争问题，使得数据的安全性无法得到保障。

当然，对于客户端层面的线程安全性问题，解决方法有很多，比如尽可能的使用Redis里面的原子指
令，或者对多个客户端的资源访问加锁，或者通过Lua脚本来实现多个指令的操作等等。

首先，Redis在6.0支持的多线程，并不是说指令操作的多线程，而是针对网络IO的多线程支持。也就是Redis的命令操作，仍然是线程安全的。
其次， Redis本身的性能瓶颈，取决于三个纬度，网络、CPU、内存。而真正影响内存的关键问题是像内存和网络。

而Redis6.0的多线程，本质上解决网络IO的处理效率问题。
在Redis6.0之前。Redis Server端处理接受到客户端请求的时候，Socket连接建立到指令的读取、解析、执行、写回都是由一个线程来处理，这种方式，在客户端请求比较多的情况下，单个线程的网络处理效率太慢，导致客户端的请求处理效率较低。

于是在Redis6.0里面，针对网络IO的处理方式改成了多线程，通过多线程并行的方式提升了网络IO的处理效率。但是对于客户端指令的执行过程，还是使用单线程方式来执行。
最后，Redis6.0里面多线程默认是关闭的，需要在redis.conf文件里面修改io-threads-do-reads配置才能开启。

另外，之所以指令执行不使用多线程，我认为有两个方面的原因。
内存的IO操作，本身不存在性能瓶颈，Redis在数据结构上已经做了非常多的优化。
如果指令的执行使用多线程，那Redis为了解决线程安全问题，需要对数据操作增加锁的同步，不仅
仅增加了复杂度，还会影响性能，代价太大不合算。

单例模式

工厂方法模式

抽象工厂模式

建造者模式

原型模式

适配器模式

桥接模式

组合模式

装饰模式

外观模式

亨元模式

代理模式

访问者模式

模版模式

策略模式

状态模式

观察者模式

备忘录模式

中介者模式

迭代器模式

解释器模式

命令模式

责任链模式

开放封闭原则
Open Close Principle

里氏代换原则
Liskov Substitution Principle

依赖倒转原则
Dependence Inversion Principle

接口隔离原则
Interface Segregation Principle

迪米特法则（最少知道原则）
Demeter Principle

单一职责原则
Principle of single responsibility

CAP理论就是说在分布式存储系统中，最多叧能实现上面的两点。 而由于当前的网络硬件肯定会出现延迟丢包等问题，所以分区容忍性是我们必须需要实现的。

AP：是目前大多数网站架构的选择

CP：Redis、MongoDB、Zookeeper

Zookeeper是通过ZAB算法实现的

基本可用（Basically Available）

软状态（Soft state）

最终一致（Eventually consistent）

它的思想是通过让系统放松对某一时刻数据一致性的要求来换取系统整体伸缩性和性能上的改观