diff --git a/.gitattributes b/.gitattributes index 05d154096837744c9f19dc70b562028796a902a0..2f2cad2e13a6388015e857cc8ba57983ce7249ce 100644 --- a/.gitattributes +++ b/.gitattributes @@ -1,4 +1,3 @@ -# Auto detect text files and perform LF normalization * text=auto *.js linguist-language=java *.css linguist-language=java diff --git a/.gitignore b/.gitignore new file mode 100644 index 0000000000000000000000000000000000000000..49a4209453a89f35c3930303747cb0e0cb48b8ad --- /dev/null +++ b/.gitignore @@ -0,0 +1,13 @@ +/node_modules +/package-lock.json +.DS_Store +# VS Code Config file +.vscode/ +# Vuepress Cache +.cache/ +# Vuepress Temp +.temp/ +# Vuepress Output +dist/ +# Build files +packages/*/lib/ diff --git a/.nojekyll b/.nojekyll new file mode 100755 index 0000000000000000000000000000000000000000..e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 diff --git "a/Java\347\233\270\345\205\263/ArrayList-Grow.md" "b/Java\347\233\270\345\205\263/ArrayList-Grow.md" deleted file mode 100644 index d763cb83492b4319280298756de303800b732bf3..0000000000000000000000000000000000000000 --- "a/Java\347\233\270\345\205\263/ArrayList-Grow.md" +++ /dev/null @@ -1,347 +0,0 @@ - -## 一 先从 ArrayList 的构造函数说起 - -**ArrayList有三种方式来初始化，构造方法源码如下：** - -```java - /** - * 默认初始容量大小 - */ - private static final int DEFAULT_CAPACITY = 10; - - - private static final Object[] DEFAULTCAPACITY_EMPTY_ELEMENTDATA = {}; - - /** - *默认构造函数，使用初始容量10构造一个空列表(无参数构造) - */ - public ArrayList() { - this.elementData = DEFAULTCAPACITY_EMPTY_ELEMENTDATA; - } - - /** - * 带初始容量参数的构造函数。（用户自己指定容量） - */ - public ArrayList(int initialCapacity) { - if (initialCapacity > 0) {//初始容量大于0 - //创建initialCapacity大小的数组 - this.elementData = new Object[initialCapacity]; - } else if (initialCapacity == 0) {//初始容量等于0 - //创建空数组 - this.elementData = EMPTY_ELEMENTDATA; - } else {//初始容量小于0，抛出异常 - throw new IllegalArgumentException("Illegal Capacity: "+ - initialCapacity); - } - } - - - /** - *构造包含指定collection元素的列表，这些元素利用该集合的迭代器按顺序返回 - *如果指定的集合为null，throws NullPointerException。 - */ - public ArrayList(Collection c) { - elementData = c.toArray(); - if ((size = elementData.length) != 0) { - // c.toArray might (incorrectly) not return Object[] (see 6260652) - if (elementData.getClass() != Object[].class) - elementData = Arrays.copyOf(elementData, size, Object[].class); - } else { - // replace with empty array. - this.elementData = EMPTY_ELEMENTDATA; - } - } - -``` - -细心的同学一定会发现 ：**以无参数构造方法创建 ArrayList 时，实际上初始化赋值的是一个空数组。当真正对数组进行添加元素操作时，才真正分配容量。即向数组中添加第一个元素时，数组容量扩为10。** 下面在我们分析 ArrayList 扩容时会讲到这一点内容！ - -## 二 一步一步分析 ArrayList 扩容机制 - -这里以无参构造函数创建的 ArrayList 为例分析 - -### 1. 先来看 `add` 方法 - -```java - /** - * 将指定的元素追加到此列表的末尾。 - */ - public boolean add(E e) { - //添加元素之前，先调用ensureCapacityInternal方法 - ensureCapacityInternal(size + 1); // Increments modCount!! - //这里看到ArrayList添加元素的实质就相当于为数组赋值 - elementData[size++] = e; - return true; - } -``` -### 2. 再来看看 `ensureCapacityInternal()` 方法 - -可以看到 `add` 方法 首先调用了`ensureCapacityInternal(size + 1)` - -```java - //得到最小扩容量 - private void ensureCapacityInternal(int minCapacity) { - if (elementData == DEFAULTCAPACITY_EMPTY_ELEMENTDATA) { - // 获取默认的容量和传入参数的较大值 - minCapacity = Math.max(DEFAULT_CAPACITY, minCapacity); - } - - ensureExplicitCapacity(minCapacity); - } -``` -**当 要 add 进第1个元素时，minCapacity为1，在Math.max()方法比较后，minCapacity 为10。** - -### 3. `ensureExplicitCapacity()` 方法 - -如果调用 `ensureCapacityInternal()` 方法就一定会进过（执行）这个方法，下面我们来研究一下这个方法的源码！ - -```java - //判断是否需要扩容 - private void ensureExplicitCapacity(int minCapacity) { - modCount++; - - // overflow-conscious code - if (minCapacity - elementData.length > 0) - //调用grow方法进行扩容，调用此方法代表已经开始扩容了 - grow(minCapacity); - } - -``` - -我们来仔细分析一下： - -- 当我们要 add 进第1个元素到 ArrayList 时，elementData.length 为0 （因为还是一个空的 list），因为执行了 `ensureCapacityInternal()` 方法 ，所以 minCapacity 此时为10。此时，`minCapacity - elementData.length > 0 `成立，所以会进入 `grow(minCapacity)` 方法。 -- 当add第2个元素时，minCapacity 为2，此时e lementData.length(容量)在添加第一个元素后扩容成 10 了。此时，`minCapacity - elementData.length > 0 ` 不成立，所以不会进入 （执行）`grow(minCapacity)` 方法。 -- 添加第3、4···到第10个元素时，依然不会执行grow方法，数组容量都为10。 - -直到添加第11个元素，minCapacity(为11)比elementData.length（为10）要大。进入grow方法进行扩容。 - -### 4. `grow()` 方法 - -```java - /** - * 要分配的最大数组大小 - */ - private static final int MAX_ARRAY_SIZE = Integer.MAX_VALUE - 8; - - /** - * ArrayList扩容的核心方法。 - */ - private void grow(int minCapacity) { - // oldCapacity为旧容量，newCapacity为新容量 - int oldCapacity = elementData.length; - //将oldCapacity 右移一位，其效果相当于oldCapacity /2， - //我们知道位运算的速度远远快于整除运算，整句运算式的结果就是将新容量更新为旧容量的1.5倍， - int newCapacity = oldCapacity + (oldCapacity >> 1); - //然后检查新容量是否大于最小需要容量，若还是小于最小需要容量，那么就把最小需要容量当作数组的新容量， - if (newCapacity - minCapacity < 0) - newCapacity = minCapacity; - // 如果新容量大于 MAX_ARRAY_SIZE,进入(执行) `hugeCapacity()` 方法来比较 minCapacity 和 MAX_ARRAY_SIZE， - //如果minCapacity大于最大容量，则新容量则为`Integer.MAX_VALUE`，否则，新容量大小则为 MAX_ARRAY_SIZE 即为 `Integer.MAX_VALUE - 8`。 - if (newCapacity - MAX_ARRAY_SIZE > 0) - newCapacity = hugeCapacity(minCapacity); - // minCapacity is usually close to size, so this is a win: - elementData = Arrays.copyOf(elementData, newCapacity); - } -``` - -**int newCapacity = oldCapacity + (oldCapacity >> 1),所以 ArrayList 每次扩容之后容量都会变为原来的 1.5 倍！** 记清楚了！不是网上很多人说的 1.5 倍+1！ - -> ">>"（移位运算符）：>>1 右移一位相当于除2，右移n位相当于除以 2 的 n 次方。这里 oldCapacity 明显右移了1位所以相当于oldCapacity /2。对于大数据的2进制运算,位移运算符比那些普通运算符的运算要快很多,因为程序仅仅移动一下而已,不去计算,这样提高了效率,节省了资源 　 - -**我们再来通过例子探究一下`grow()` 方法 ：** - -- 当add第1个元素时，oldCapacity 为0，经比较后第一个if判断成立，newCapacity = minCapacity(为10)。但是第二个if判断不会成立，即newCapacity 不比 MAX_ARRAY_SIZE大，则不会进入 `hugeCapacity` 方法。数组容量为10，add方法中 return true,size增为1。 -- 当add第11个元素进入grow方法时，newCapacity为15，比minCapacity（为11）大，第一个if判断不成立。新容量没有大于数组最大size，不会进入hugeCapacity方法。数组容量扩为15，add方法中return true,size增为11。 -- 以此类推······ - -**这里补充一点比较重要，但是容易被忽视掉的知识点：** - -- java 中的 `length `属性是针对数组说的,比如说你声明了一个数组,想知道这个数组的长度则用到了 length 这个属性. -- java 中的 `length()` 方法是针对字符串说的,如果想看这个字符串的长度则用到 `length()` 这个方法. -- java 中的 `size()` 方法是针对泛型集合说的,如果想看这个泛型有多少个元素,就调用此方法来查看! - -### 5. `hugeCapacity()` 方法。 - -从上面 `grow()` 方法源码我们知道： 如果新容量大于 MAX_ARRAY_SIZE,进入(执行) `hugeCapacity()` 方法来比较 minCapacity 和 MAX_ARRAY_SIZE，如果minCapacity大于最大容量，则新容量则为`Integer.MAX_VALUE`，否则，新容量大小则为 MAX_ARRAY_SIZE 即为 `Integer.MAX_VALUE - 8`。 - - -```java - private static int hugeCapacity(int minCapacity) { - if (minCapacity < 0) // overflow - throw new OutOfMemoryError(); - //对minCapacity和MAX_ARRAY_SIZE进行比较 - //若minCapacity大，将Integer.MAX_VALUE作为新数组的大小 - //若MAX_ARRAY_SIZE大，将MAX_ARRAY_SIZE作为新数组的大小 - //MAX_ARRAY_SIZE = Integer.MAX_VALUE - 8; - return (minCapacity > MAX_ARRAY_SIZE) ? - Integer.MAX_VALUE : - MAX_ARRAY_SIZE; - } -``` - - - -## 三 `System.arraycopy()` 和 `Arrays.copyOf()`方法 - - -阅读源码的话，我们就会发现 ArrayList 中大量调用了这两个方法。比如：我们上面讲的扩容操作以及`add(int index, E element)`、`toArray()` 等方法中都用到了该方法！ - - -### 3.1 `System.arraycopy()` 方法 - -```java - /** - * 在此列表中的指定位置插入指定的元素。 - *先调用 rangeCheckForAdd 对index进行界限检查；然后调用 ensureCapacityInternal 方法保证capacity足够大； - *再将从index开始之后的所有成员后移一个位置；将element插入index位置；最后size加1。 - */ - public void add(int index, E element) { - rangeCheckForAdd(index); - - ensureCapacityInternal(size + 1); // Increments modCount!! - //arraycopy()方法实现数组自己复制自己 - //elementData:源数组;index:源数组中的起始位置;elementData：目标数组；index + 1：目标数组中的起始位置； size - index：要复制的数组元素的数量； - System.arraycopy(elementData, index, elementData, index + 1, size - index); - elementData[index] = element; - size++; - } -``` - -我们写一个简单的方法测试以下： - -```java -public class ArraycopyTest { - - public static void main(String[] args) { - // TODO Auto-generated method stub - int[] a = new int[10]; - a[0] = 0; - a[1] = 1; - a[2] = 2; - a[3] = 3; - System.arraycopy(a, 2, a, 3, 3); - a[2]=99; - for (int i = 0; i < a.length; i++) { - System.out.println(a[i]); - } - } - -} -``` - -结果： - -``` -0 1 99 2 3 0 0 0 0 0 -``` - -### 3.2 `Arrays.copyOf()`方法 - -```java - /** - 以正确的顺序返回一个包含此列表中所有元素的数组（从第一个到最后一个元素）; 返回的数组的运行时类型是指定数组的运行时类型。 - */ - public Object[] toArray() { - //elementData：要复制的数组；size：要复制的长度 - return Arrays.copyOf(elementData, size); - } -``` - -个人觉得使用 `Arrays.copyOf()`方法主要是为了给原有数组扩容，测试代码如下： - -```java -public class ArrayscopyOfTest { - - public static void main(String[] args) { - int[] a = new int[3]; - a[0] = 0; - a[1] = 1; - a[2] = 2; - int[] b = Arrays.copyOf(a, 10); - System.out.println("b.length"+b.length); - } -} -``` - -结果： - -``` -10 -``` - - -### 3.3 两者联系和区别 - -**联系：** - -看两者源代码可以发现 copyOf() 内部实际调用了 `System.arraycopy()` 方法 - -**区别：** - -`arraycopy()` 需要目标数组，将原数组拷贝到你自己定义的数组里或者原数组，而且可以选择拷贝的起点和长度以及放入新数组中的位置 `copyOf()` 是系统自动在内部新建一个数组，并返回该数组。 - - - -## 四 `ensureCapacity`方法 - -ArrayList 源码中有一个 `ensureCapacity` 方法不知道大家注意到没有，这个方法 ArrayList 内部没有被调用过，所以很显然是提供给用户调用的，那么这个方法有什么作用呢？ - -```java - /** - 如有必要，增加此 ArrayList 实例的容量，以确保它至少可以容纳由minimum capacity参数指定的元素数。 - * - * @param minCapacity 所需的最小容量 - */ - public void ensureCapacity(int minCapacity) { - int minExpand = (elementData != DEFAULTCAPACITY_EMPTY_ELEMENTDATA) - // any size if not default element table - ? 0 - // larger than default for default empty table. It's already - // supposed to be at default size. - : DEFAULT_CAPACITY; - - if (minCapacity > minExpand) { - ensureExplicitCapacity(minCapacity); - } - } - -``` - -**最好在 add 大量元素之前用 `ensureCapacity` 方法，以减少增量重新分配的次数** - -我们通过下面的代码实际测试以下这个方法的效果： - -```java -public class EnsureCapacityTest { - public static void main(String[] args) { - ArrayList list = new ArrayList(); - final int N = 10000000; - long startTime = System.currentTimeMillis(); - for (int i = 0; i < N; i++) { - list.add(i); - } - long endTime = System.currentTimeMillis(); - System.out.println("使用ensureCapacity方法前："+(endTime - startTime)); - - list = new ArrayList(); - long startTime1 = System.currentTimeMillis(); - list.ensureCapacity(N); - for (int i = 0; i < N; i++) { - list.add(i); - } - long endTime1 = System.currentTimeMillis(); - System.out.println("使用ensureCapacity方法后："+(endTime1 - startTime1)); - } -} -``` - -运行结果： - -``` -使用ensureCapacity方法前：4637 -使用ensureCapacity方法后：241 - -``` - -通过运行结果，我们可以很明显的看出向 ArrayList 添加大量元素之前最好先使用`ensureCapacity` 方法，以减少增量重新分配的次数 diff --git "a/Java\347\233\270\345\205\263/BIO,NIO,AIO summary.md" "b/Java\347\233\270\345\205\263/BIO,NIO,AIO summary.md" deleted file mode 100644 index c5ec6dddd0440fd1775aef418fcad97a9b60df0b..0000000000000000000000000000000000000000 --- "a/Java\347\233\270\345\205\263/BIO,NIO,AIO summary.md" +++ /dev/null @@ -1,347 +0,0 @@ -熟练掌握 BIO,NIO,AIO 的基本概念以及一些常见问题是你准备面试的过程中不可或缺的一部分，另外这些知识点也是你学习 Netty 的基础。 - - - -- [BIO,NIO,AIO 总结](#bionioaio-总结) - - [1. BIO \(Blocking I/O\)](#1-bio-blocking-io) - - [1.1 传统 BIO](#11-传统-bio) - - [1.2 伪异步 IO](#12-伪异步-io) - - [1.3 代码示例](#13-代码示例) - - [1.4 总结](#14-总结) - - [2. NIO \(New I/O\)](#2-nio-new-io) - - [2.1 NIO 简介](#21-nio-简介) - - [2.2 NIO的特性/NIO与IO区别](#22-nio的特性nio与io区别) - - [1)Non-blocking IO（非阻塞IO）](#1non-blocking-io（非阻塞io）) - - [2)Buffer\(缓冲区\)](#2buffer缓冲区) - - [3)Channel \(通道\)](#3channel-通道) - - [4)Selectors\(选择器\)](#4selectors选择器) - - [2.3 NIO 读数据和写数据方式](#23-nio-读数据和写数据方式) - - [2.4 NIO核心组件简单介绍](#24-nio核心组件简单介绍) - - [2.5 代码示例](#25-代码示例) - - [3. AIO \(Asynchronous I/O\)](#3-aio-asynchronous-io) - - [参考](#参考) - - - - -# BIO,NIO,AIO 总结 - - Java 中的 BIO、NIO和 AIO 理解为是 Java 语言对操作系统的各种 IO 模型的封装。程序员在使用这些 API 的时候，不需要关心操作系统层面的知识，也不需要根据不同操作系统编写不同的代码。只需要使用Java的API就可以了。 - -在讲 BIO,NIO,AIO 之前先来回顾一下这样几个概念：同步与异步，阻塞与非阻塞。 - -**同步与异步** - -- **同步：** 同步就是发起一个调用后，被调用者未处理完请求之前，调用不返回。 -- **异步：** 异步就是发起一个调用后，立刻得到被调用者的回应表示已接收到请求，但是被调用者并没有返回结果，此时我们可以处理其他的请求，被调用者通常依靠事件，回调等机制来通知调用者其返回结果。 - -同步和异步的区别最大在于异步的话调用者不需要等待处理结果，被调用者会通过回调等机制来通知调用者其返回结果。 - -**阻塞和非阻塞** - -- **阻塞：** 阻塞就是发起一个请求，调用者一直等待请求结果返回，也就是当前线程会被挂起，无法从事其他任务，只有当条件就绪才能继续。 -- **非阻塞：** 非阻塞就是发起一个请求，调用者不用一直等着结果返回，可以先去干其他事情。 - -举个生活中简单的例子，你妈妈让你烧水，小时候你比较笨啊，在哪里傻等着水开（**同步阻塞**）。等你稍微再长大一点，你知道每次烧水的空隙可以去干点其他事，然后只需要时不时来看看水开了没有（**同步非阻塞**）。后来，你们家用上了水开了会发出声音的壶，这样你就只需要听到响声后就知道水开了，在这期间你可以随便干自己的事情，你需要去倒水了（**异步非阻塞**）。 - - -## 1. BIO (Blocking I/O) - -同步阻塞I/O模式，数据的读取写入必须阻塞在一个线程内等待其完成。 - -### 1.1 传统 BIO - -BIO通信（一请求一应答）模型图如下(图源网络，原出处不明)： - -![传统BIO通信模型图](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/2.png) - -采用 **BIO 通信模型** 的服务端，通常由一个独立的 Acceptor 线程负责监听客户端的连接。我们一般通过在`while(true)` 循环中服务端会调用 `accept()` 方法等待接收客户端的连接的方式监听请求，请求一旦接收到一个连接请求，就可以建立通信套接字在这个通信套接字上进行读写操作，此时不能再接收其他客户端连接请求，只能等待同当前连接的客户端的操作执行完成， 不过可以通过多线程来支持多个客户端的连接，如上图所示。 - -如果要让 **BIO 通信模型** 能够同时处理多个客户端请求，就必须使用多线程（主要原因是`socket.accept()`、`socket.read()`、`socket.write()` 涉及的三个主要函数都是同步阻塞的），也就是说它在接收到客户端连接请求之后为每个客户端创建一个新的线程进行链路处理，处理完成之后，通过输出流返回应答给客户端，线程销毁。这就是典型的 **一请求一应答通信模型** 。我们可以设想一下如果这个连接不做任何事情的话就会造成不必要的线程开销，不过可以通过 **线程池机制** 改善，线程池还可以让线程的创建和回收成本相对较低。使用`FixedThreadPool` 可以有效的控制了线程的最大数量，保证了系统有限的资源的控制，实现了N(客户端请求数量):M(处理客户端请求的线程数量)的伪异步I/O模型（N 可以远远大于 M），下面一节"伪异步 BIO"中会详细介绍到。 - -**我们再设想一下当客户端并发访问量增加后这种模型会出现什么问题？** - -在 Java 虚拟机中，线程是宝贵的资源，线程的创建和销毁成本很高，除此之外，线程的切换成本也是很高的。尤其在 Linux 这样的操作系统中，线程本质上就是一个进程，创建和销毁线程都是重量级的系统函数。如果并发访问量增加会导致线程数急剧膨胀可能会导致线程堆栈溢出、创建新线程失败等问题，最终导致进程宕机或者僵死，不能对外提供服务。 - -### 1.2 伪异步 IO - -为了解决同步阻塞I/O面临的一个链路需要一个线程处理的问题，后来有人对它的线程模型进行了优化一一一后端通过一个线程池来处理多个客户端的请求接入，形成客户端个数M：线程池最大线程数N的比例关系，其中M可以远远大于N.通过线程池可以灵活地调配线程资源，设置线程的最大值，防止由于海量并发接入导致线程耗尽。 - -伪异步IO模型图(图源网络，原出处不明)： - -![伪异步IO模型图](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/3.png) - -采用线程池和任务队列可以实现一种叫做伪异步的 I/O 通信框架，它的模型图如上图所示。当有新的客户端接入时，将客户端的 Socket 封装成一个Task（该任务实现java.lang.Runnable接口）投递到后端的线程池中进行处理，JDK 的线程池维护一个消息队列和 N 个活跃线程，对消息队列中的任务进行处理。由于线程池可以设置消息队列的大小和最大线程数，因此，它的资源占用是可控的，无论多少个客户端并发访问，都不会导致资源的耗尽和宕机。 - -伪异步I/O通信框架采用了线程池实现，因此避免了为每个请求都创建一个独立线程造成的线程资源耗尽问题。不过因为它的底层任然是同步阻塞的BIO模型，因此无法从根本上解决问题。 - -### 1.3 代码示例 - -下面代码中演示了BIO通信（一请求一应答）模型。我们会在客户端创建多个线程依次连接服务端并向其发送"当前时间+:hello world"，服务端会为每个客户端线程创建一个线程来处理。代码示例出自闪电侠的博客，原地址如下： - -[https://www.jianshu.com/p/a4e03835921a](https://www.jianshu.com/p/a4e03835921a) - -**客户端** - -```java -/** - * - * @author 闪电侠 - * @date 2018年10月14日 - * @Description:客户端 - */ -public class IOClient { - - public static void main(String[] args) { - // TODO 创建多个线程，模拟多个客户端连接服务端 - new Thread(() -> { - try { - Socket socket = new Socket("127.0.0.1", 3333); - while (true) { - try { - socket.getOutputStream().write((new Date() + ": hello world").getBytes()); - Thread.sleep(2000); - } catch (Exception e) { - } - } - } catch (IOException e) { - } - }).start(); - - } - -} - -``` - -**服务端** - -```java -/** - * @author 闪电侠 - * @date 2018年10月14日 - * @Description: 服务端 - */ -public class IOServer { - - public static void main(String[] args) throws IOException { - // TODO 服务端处理客户端连接请求 - ServerSocket serverSocket = new ServerSocket(3333); - - // 接收到客户端连接请求之后为每个客户端创建一个新的线程进行链路处理 - new Thread(() -> { - while (true) { - try { - // 阻塞方法获取新的连接 - Socket socket = serverSocket.accept(); - - // 每一个新的连接都创建一个线程，负责读取数据 - new Thread(() -> { - try { - int len; - byte[] data = new byte[1024]; - InputStream inputStream = socket.getInputStream(); - // 按字节流方式读取数据 - while ((len = inputStream.read(data)) != -1) { - System.out.println(new String(data, 0, len)); - } - } catch (IOException e) { - } - }).start(); - - } catch (IOException e) { - } - - } - }).start(); - - } - -} -``` - -### 1.4 总结 - -在活动连接数不是特别高（小于单机1000）的情况下，这种模型是比较不错的，可以让每一个连接专注于自己的 I/O 并且编程模型简单，也不用过多考虑系统的过载、限流等问题。线程池本身就是一个天然的漏斗，可以缓冲一些系统处理不了的连接或请求。但是，当面对十万甚至百万级连接的时候，传统的 BIO 模型是无能为力的。因此，我们需要一种更高效的 I/O 处理模型来应对更高的并发量。 - - - -## 2. NIO (New I/O) - -### 2.1 NIO 简介 - - NIO是一种同步非阻塞的I/O模型，在Java 1.4 中引入了NIO框架，对应 java.nio 包，提供了 Channel , Selector，Buffer等抽象。 - -NIO中的N可以理解为Non-blocking，不单纯是New。它支持面向缓冲的，基于通道的I/O操作方法。 NIO提供了与传统BIO模型中的 `Socket` 和 `ServerSocket` 相对应的 `SocketChannel` 和 `ServerSocketChannel` 两种不同的套接字通道实现,两种通道都支持阻塞和非阻塞两种模式。阻塞模式使用就像传统中的支持一样，比较简单，但是性能和可靠性都不好；非阻塞模式正好与之相反。对于低负载、低并发的应用程序，可以使用同步阻塞I/O来提升开发速率和更好的维护性；对于高负载、高并发的（网络）应用，应使用 NIO 的非阻塞模式来开发。 - -### 2.2 NIO的特性/NIO与IO区别 - -如果是在面试中回答这个问题，我觉得首先肯定要从 NIO 流是非阻塞 IO 而 IO 流是阻塞 IO 说起。然后，可以从 NIO 的3个核心组件/特性为 NIO 带来的一些改进来分析。如果，你把这些都回答上了我觉得你对于 NIO 就有了更为深入一点的认识，面试官问到你这个问题，你也能很轻松的回答上来了。 - -#### 1)Non-blocking IO（非阻塞IO） - -**IO流是阻塞的，NIO流是不阻塞的。** - -Java NIO使我们可以进行非阻塞IO操作。比如说，单线程中从通道读取数据到buffer，同时可以继续做别的事情，当数据读取到buffer中后，线程再继续处理数据。写数据也是一样的。另外，非阻塞写也是如此。一个线程请求写入一些数据到某通道，但不需要等待它完全写入，这个线程同时可以去做别的事情。 - -Java IO的各种流是阻塞的。这意味着，当一个线程调用 `read()` 或 `write()` 时，该线程被阻塞，直到有一些数据被读取，或数据完全写入。该线程在此期间不能再干任何事情了 - -#### 2)Buffer(缓冲区) - -**IO 面向流(Stream oriented)，而 NIO 面向缓冲区(Buffer oriented)。** - -Buffer是一个对象，它包含一些要写入或者要读出的数据。在NIO类库中加入Buffer对象，体现了新库与原I/O的一个重要区别。在面向流的I/O中·可以将数据直接写入或者将数据直接读到 Stream 对象中。虽然 Stream 中也有 Buffer 开头的扩展类，但只是流的包装类，还是从流读到缓冲区，而 NIO 却是直接读到 Buffer 中进行操作。 - -在NIO厍中，所有数据都是用缓冲区处理的。在读取数据时，它是直接读到缓冲区中的; 在写入数据时，写入到缓冲区中。任何时候访问NIO中的数据，都是通过缓冲区进行操作。 - -最常用的缓冲区是 ByteBuffer,一个 ByteBuffer 提供了一组功能用于操作 byte 数组。除了ByteBuffer,还有其他的一些缓冲区，事实上，每一种Java基本类型（除了Boolean类型）都对应有一种缓冲区。 - -#### 3)Channel (通道) - -NIO 通过Channel（通道） 进行读写。 - -通道是双向的，可读也可写，而流的读写是单向的。无论读写，通道只能和Buffer交互。因为 Buffer，通道可以异步地读写。 - -#### 4)Selectors(选择器) - -NIO有选择器，而IO没有。 - -选择器用于使用单个线程处理多个通道。因此，它需要较少的线程来处理这些通道。线程之间的切换对于操作系统来说是昂贵的。 因此，为了提高系统效率选择器是有用的。 - -![一个单线程中Slector维护3个Channel的示意图](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/2019-2/Slector.png) - -### 2.3 NIO 读数据和写数据方式 -通常来说NIO中的所有IO都是从 Channel（通道） 开始的。 - -- 从通道进行数据读取 ：创建一个缓冲区，然后请求通道读取数据。 -- 从通道进行数据写入 ：创建一个缓冲区，填充数据，并要求通道写入数据。 - -数据读取和写入操作图示： - -![NIO读写数据的方式](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/2019-2/NIO读写数据的方式.png) - - -### 2.4 NIO核心组件简单介绍 - -NIO 包含下面几个核心的组件： - -- Channel(通道) -- Buffer(缓冲区) -- Selector(选择器) - -整个NIO体系包含的类远远不止这三个，只能说这三个是NIO体系的“核心API”。我们上面已经对这三个概念进行了基本的阐述，这里就不多做解释了。 - -### 2.5 代码示例 - -代码示例出自闪电侠的博客，原地址如下： - -[https://www.jianshu.com/p/a4e03835921a](https://www.jianshu.com/p/a4e03835921a) - -客户端 IOClient.java 的代码不变，我们对服务端使用 NIO 进行改造。以下代码较多而且逻辑比较复杂，大家看看就好。 - -```java -/** - * - * @author 闪电侠 - * @date 2019年2月21日 - * @Description: NIO 改造后的服务端 - */ -public class NIOServer { - public static void main(String[] args) throws IOException { - // 1. serverSelector负责轮询是否有新的连接，服务端监测到新的连接之后，不再创建一个新的线程， - // 而是直接将新连接绑定到clientSelector上，这样就不用 IO 模型中 1w 个 while 循环在死等 - Selector serverSelector = Selector.open(); - // 2. clientSelector负责轮询连接是否有数据可读 - Selector clientSelector = Selector.open(); - - new Thread(() -> { - try { - // 对应IO编程中服务端启动 - ServerSocketChannel listenerChannel = ServerSocketChannel.open(); - listenerChannel.socket().bind(new InetSocketAddress(3333)); - listenerChannel.configureBlocking(false); - listenerChannel.register(serverSelector, SelectionKey.OP_ACCEPT); - - while (true) { - // 监测是否有新的连接，这里的1指的是阻塞的时间为 1ms - if (serverSelector.select(1) > 0) { - Set set = serverSelector.selectedKeys(); - Iterator keyIterator = set.iterator(); - - while (keyIterator.hasNext()) { - SelectionKey key = keyIterator.next(); - - if (key.isAcceptable()) { - try { - // (1) - // 每来一个新连接，不需要创建一个线程，而是直接注册到clientSelector - SocketChannel clientChannel = ((ServerSocketChannel) key.channel()).accept(); - clientChannel.configureBlocking(false); - clientChannel.register(clientSelector, SelectionKey.OP_READ); - } finally { - keyIterator.remove(); - } - } - - } - } - } - } catch (IOException ignored) { - } - }).start(); - new Thread(() -> { - try { - while (true) { - // (2) 批量轮询是否有哪些连接有数据可读，这里的1指的是阻塞的时间为 1ms - if (clientSelector.select(1) > 0) { - Set set = clientSelector.selectedKeys(); - Iterator keyIterator = set.iterator(); - - while (keyIterator.hasNext()) { - SelectionKey key = keyIterator.next(); - - if (key.isReadable()) { - try { - SocketChannel clientChannel = (SocketChannel) key.channel(); - ByteBuffer byteBuffer = ByteBuffer.allocate(1024); - // (3) 面向 Buffer - clientChannel.read(byteBuffer); - byteBuffer.flip(); - System.out.println( - Charset.defaultCharset().newDecoder().decode(byteBuffer).toString()); - } finally { - keyIterator.remove(); - key.interestOps(SelectionKey.OP_READ); - } - } - - } - } - } - } catch (IOException ignored) { - } - }).start(); - - } -} -``` - -为什么大家都不愿意用 JDK 原生 NIO 进行开发呢？从上面的代码中大家都可以看出来，是真的难用！除了编程复杂、编程模型难之外，它还有以下让人诟病的问题： - -- JDK 的 NIO 底层由 epoll 实现，该实现饱受诟病的空轮询 bug 会导致 cpu 飙升 100% -- 项目庞大之后，自行实现的 NIO 很容易出现各类 bug，维护成本较高，上面这一坨代码我都不能保证没有 bug - -Netty 的出现很大程度上改善了 JDK 原生 NIO 所存在的一些让人难以忍受的问题。 - -### 3. AIO (Asynchronous I/O) - -AIO 也就是 NIO 2。在 Java 7 中引入了 NIO 的改进版 NIO 2,它是异步非阻塞的IO模型。异步 IO 是基于事件和回调机制实现的，也就是应用操作之后会直接返回，不会堵塞在那里，当后台处理完成，操作系统会通知相应的线程进行后续的操作。 - -AIO 是异步IO的缩写，虽然 NIO 在网络操作中，提供了非阻塞的方法，但是 NIO 的 IO 行为还是同步的。对于 NIO 来说，我们的业务线程是在 IO 操作准备好时，得到通知，接着就由这个线程自行进行 IO 操作，IO操作本身是同步的。（除了 AIO 其他的 IO 类型都是同步的，这一点可以从底层IO线程模型解释，推荐一篇文章：[《漫话：如何给女朋友解释什么是Linux的五种IO模型？》](https://mp.weixin.qq.com/s?__biz=Mzg3MjA4MTExMw==&mid=2247484746&idx=1&sn=c0a7f9129d780786cabfcac0a8aa6bb7&source=41#wechat_redirect) ） - -查阅网上相关资料，我发现就目前来说 AIO 的应用还不是很广泛，Netty 之前也尝试使用过 AIO，不过又放弃了。 - -## 参考 - -- 《Netty 权威指南》第二版 -- https://zhuanlan.zhihu.com/p/23488863 (美团技术团队) diff --git "a/Java\347\233\270\345\205\263/Java IO\344\270\216NIO.md" "b/Java\347\233\270\345\205\263/Java IO\344\270\216NIO.md" deleted file mode 100644 index 905df527c40e26cd22ed74857de5e8faccdf283b..0000000000000000000000000000000000000000 --- "a/Java\347\233\270\345\205\263/Java IO\344\270\216NIO.md" +++ /dev/null @@ -1,200 +0,0 @@ - - -- [IO流学习总结](#io流学习总结) - - [一　Java IO，硬骨头也能变软](#一-java-io，硬骨头也能变软) - - [二　java IO体系的学习总结](#二-java-io体系的学习总结) - - [三　Java IO面试题](#三-java-io面试题) -- [NIO与AIO学习总结](#nio与aio学习总结) - - [一 Java NIO 概览](#一-java-nio-概览) - - [二 Java NIO 之 Buffer\(缓冲区\)](#二-java-nio-之-buffer缓冲区) - - [三 Java NIO 之 Channel（通道）](#三-java-nio-之-channel（通道）) - - [四 Java NIO之Selector（选择器）](#四-java-nio之selector（选择器）) - - [五 Java NIO之拥抱Path和Files](#五-java-nio之拥抱path和files) - - [六 NIO学习总结以及NIO新特性介绍](#六-nio学习总结以及nio新特性介绍) - - [七 Java NIO AsynchronousFileChannel异步文件通](#七-java-nio-asynchronousfilechannel异步文件通) - - [八 高并发Java（8）：NIO和AIO](#八-高并发java（8）：nio和aio) -- [推荐阅读](#推荐阅读) - - [在 Java 7 中体会 NIO.2 异步执行的快乐](#在-java-7-中体会-nio2-异步执行的快乐) - - [Java AIO总结与示例](#java-aio总结与示例) - - - - - -## IO流学习总结 - -### [一　Java IO，硬骨头也能变软](https://mp.weixin.qq.com/s?__biz=MzU4NDQ4MzU5OA==&mid=2247483981&idx=1&sn=6e5c682d76972c8d2cf271a85dcf09e2&chksm=fd98542ccaefdd3a70428e9549bc33e8165836855edaa748928d16c1ebde9648579d3acaac10#rd) - -**（1） 按操作方式分类结构图：** - -![按操作方式分类结构图：](https://user-gold-cdn.xitu.io/2018/5/16/16367d4fd1ce1b46?w=720&h=1080&f=jpeg&s=69522) - - -**（2）按操作对象分类结构图** - -![按操作对象分类结构图](https://user-gold-cdn.xitu.io/2018/5/16/16367d673b0e268d?w=720&h=535&f=jpeg&s=46081) - -### [二　java IO体系的学习总结](https://blog.csdn.net/nightcurtis/article/details/51324105) -1. **IO流的分类：** - - 按照流的流向分，可以分为输入流和输出流； - - 按照操作单元划分，可以划分为字节流和字符流； - - 按照流的角色划分为节点流和处理流。 -2. **流的原理浅析:** - - java Io流共涉及40多个类，这些类看上去很杂乱，但实际上很有规则，而且彼此之间存在非常紧密的联系， Java Io流的40多个类都是从如下4个抽象类基类中派生出来的。 - - - **InputStream/Reader**: 所有的输入流的基类，前者是字节输入流，后者是字符输入流。 - - **OutputStream/Writer**: 所有输出流的基类，前者是字节输出流，后者是字符输出流。 -3. **常用的io流的用法** - -### [三　Java IO面试题](https://mp.weixin.qq.com/s?__biz=MzU4NDQ4MzU5OA==&mid=2247483985&idx=1&sn=38531c2cee7b87f125df7aef41637014&chksm=fd985430caefdd26b0506aa84fc26251877eccba24fac73169a4d6bd1eb5e3fbdf3c3b940261#rd) - -## NIO与AIO学习总结 - - -### [一 Java NIO 概览](https://mp.weixin.qq.com/s?__biz=MzU4NDQ4MzU5OA==&mid=2247483956&idx=1&sn=57692bc5b7c2c6dfb812489baadc29c9&chksm=fd985455caefdd4331d828d8e89b22f19b304aa87d6da73c5d8c66fcef16e4c0b448b1a6f791#rd) - -1. **NIO简介**: - - Java NIO 是 java 1.4, 之后新出的一套IO接口NIO中的N可以理解为Non-blocking，不单纯是New。 - -2. **NIO的特性/NIO与IO区别:** - - 1)IO是面向流的，NIO是面向缓冲区的； - - 2)IO流是阻塞的，NIO流是不阻塞的; - - 3)NIO有选择器，而IO没有。 -3. **读数据和写数据方式:** - - 从通道进行数据读取 ：创建一个缓冲区，然后请求通道读取数据。 - - - 从通道进行数据写入 ：创建一个缓冲区，填充数据，并要求通道写入数据。 - -4. **NIO核心组件简单介绍** - - **Channels** - - **Buffers** - - **Selectors** - - -### [二 Java NIO 之 Buffer(缓冲区)](https://mp.weixin.qq.com/s?__biz=MzU4NDQ4MzU5OA==&mid=2247483961&idx=1&sn=f67bef4c279e78043ff649b6b03fdcbc&chksm=fd985458caefdd4e3317ccbdb2d0a5a70a5024d3255eebf38183919ed9c25ade536017c0a6ba#rd) - -1. **Buffer(缓冲区)介绍:** - - Java NIO Buffers用于和NIO Channel交互。 我们从Channel中读取数据到buffers里，从Buffer把数据写入到Channels； - - Buffer本质上就是一块内存区； - - 一个Buffer有三个属性是必须掌握的，分别是：capacity容量、position位置、limit限制。 -2. **Buffer的常见方法** - - Buffer clear() - - Buffer flip() - - Buffer rewind() - - Buffer position(int newPosition) -3. **Buffer的使用方式/方法介绍:** - - 分配缓冲区（Allocating a Buffer）: - ```java - ByteBuffer buf = ByteBuffer.allocate(28);//以ByteBuffer为例子 - ``` - - 写入数据到缓冲区（Writing Data to a Buffer） - - **写数据到Buffer有两种方法：** - - 1.从Channel中写数据到Buffer - ```java - int bytesRead = inChannel.read(buf); //read into buffer. - ``` - 2.通过put写数据： - ```java - buf.put(127); - ``` - -4. **Buffer常用方法测试** - - 说实话，NIO编程真的难，通过后面这个测试例子，你可能才能勉强理解前面说的Buffer方法的作用。 - - -### [三 Java NIO 之 Channel（通道）](https://mp.weixin.qq.com/s?__biz=MzU4NDQ4MzU5OA==&mid=2247483966&idx=1&sn=d5cf18c69f5f9ec2aff149270422731f&chksm=fd98545fcaefdd49296e2c78000ce5da277435b90ba3c03b92b7cf54c6ccc71d61d13efbce63#rd) - - -1. **Channel（通道）介绍** - - 通常来说NIO中的所有IO都是从 Channel（通道） 开始的。 - - NIO Channel通道和流的区别： -2. **FileChannel的使用** -3. **SocketChannel和ServerSocketChannel的使用** -4. **️DatagramChannel的使用** -5. **Scatter / Gather** - - Scatter: 从一个Channel读取的信息分散到N个缓冲区中(Buufer). - - Gather: 将N个Buffer里面内容按照顺序发送到一个Channel. -6. **通道之间的数据传输** - - 在Java NIO中如果一个channel是FileChannel类型的，那么他可以直接把数据传输到另一个channel。 - - transferFrom() :transferFrom方法把数据从通道源传输到FileChannel - - transferTo() :transferTo方法把FileChannel数据传输到另一个channel - - -### [四 Java NIO之Selector（选择器）](https://mp.weixin.qq.com/s?__biz=MzU4NDQ4MzU5OA==&mid=2247483970&idx=1&sn=d5e2b133313b1d0f32872d54fbdf0aa7&chksm=fd985423caefdd354b587e57ce6cf5f5a7bec48b9ab7554f39a8d13af47660cae793956e0f46#rd) - - -1. **Selector（选择器）介绍** - - Selector 一般称 为选择器 ，当然你也可以翻译为 多路复用器 。它是Java NIO核心组件中的一个，用于检查一个或多个NIO Channel（通道）的状态是否处于可读、可写。如此可以实现单线程管理多个channels,也就是可以管理多个网络链接。 - - 使用Selector的好处在于： 使用更少的线程来就可以来处理通道了， 相比使用多个线程，避免了线程上下文切换带来的开销。 -2. **Selector（选择器）的使用方法介绍** - - Selector的创建 - ```java - Selector selector = Selector.open(); - ``` - - 注册Channel到Selector(Channel必须是非阻塞的) - ```java - channel.configureBlocking(false); - SelectionKey key = channel.register(selector, Selectionkey.OP_READ); - ``` - - SelectionKey介绍 - - 一个SelectionKey键表示了一个特定的通道对象和一个特定的选择器对象之间的注册关系。 - - 从Selector中选择channel(Selecting Channels via a Selector) - - 选择器维护注册过的通道的集合，并且这种注册关系都被封装在SelectionKey当中. - - 停止选择的方法 - - wakeup()方法 和close()方法。 -3. **模板代码** - - 有了模板代码我们在编写程序时，大多数时间都是在模板代码中添加相应的业务代码。 -4. **客户端与服务端简单交互实例** - - - -### [五 Java NIO之拥抱Path和Files](https://mp.weixin.qq.com/s?__biz=MzU4NDQ4MzU5OA==&mid=2247483976&idx=1&sn=2296c05fc1b840a64679e2ad7794c96d&chksm=fd985429caefdd3f48e2ee6fdd7b0f6fc419df90b3de46832b484d6d1ca4e74e7837689c8146&token=537240785&lang=zh_CN#rd) - -**一 文件I/O基石：Path：** -- 创建一个Path -- File和Path之间的转换，File和URI之间的转换 -- 获取Path的相关信息 -- 移除Path中的冗余项 - -**二 拥抱Files类：** -- Files.exists() 检测文件路径是否存在 -- Files.createFile() 创建文件 -- Files.createDirectories()和Files.createDirectory()创建文件夹 -- Files.delete()方法 可以删除一个文件或目录 -- Files.copy()方法可以吧一个文件从一个地址复制到另一个位置 -- 获取文件属性 -- 遍历一个文件夹 -- Files.walkFileTree()遍历整个目录 - -### [六 NIO学习总结以及NIO新特性介绍](https://blog.csdn.net/a953713428/article/details/64907250) - -- **内存映射：** - -这个功能主要是为了提高大文件的读写速度而设计的。内存映射文件(memory-mappedfile)能让你创建和修改那些大到无法读入内存的文件。有了内存映射文件，你就可以认为文件已经全部读进了内存，然后把它当成一个非常大的数组来访问了。将文件的一段区域映射到内存中，比传统的文件处理速度要快很多。内存映射文件它虽然最终也是要从磁盘读取数据，但是它并不需要将数据读取到OS内核缓冲区，而是直接将进程的用户私有地址空间中的一部分区域与文件对象建立起映射关系，就好像直接从内存中读、写文件一样，速度当然快了。 - -### [七 Java NIO AsynchronousFileChannel异步文件通](http://wiki.jikexueyuan.com/project/java-nio-zh/java-nio-asynchronousfilechannel.html) - -Java7中新增了AsynchronousFileChannel作为nio的一部分。AsynchronousFileChannel使得数据可以进行异步读写。 - -### [八 高并发Java（8）：NIO和AIO](http://www.importnew.com/21341.html) - - - -## 推荐阅读 - -### [在 Java 7 中体会 NIO.2 异步执行的快乐](https://www.ibm.com/developerworks/cn/java/j-lo-nio2/index.html) - -### [Java AIO总结与示例](https://blog.csdn.net/x_i_y_u_e/article/details/52223406) -AIO是异步IO的缩写，虽然NIO在网络操作中，提供了非阻塞的方法，但是NIO的IO行为还是同步的。对于NIO来说，我们的业务线程是在IO操作准备好时，得到通知，接着就由这个线程自行进行IO操作，IO操作本身是同步的。 - - -**欢迎关注我的微信公众号:"Java面试通关手册"（一个有温度的微信公众号，期待与你共同进步~~~坚持原创，分享美文，分享各种Java学习资源）：** diff --git "a/Java\347\233\270\345\205\263/Java\345\237\272\347\241\200\347\237\245\350\257\206.md" "b/Java\347\233\270\345\205\263/Java\345\237\272\347\241\200\347\237\245\350\257\206.md" deleted file mode 100644 index 8b438eb18f8b37a13a85ddaa384cdb2938612c84..0000000000000000000000000000000000000000 --- "a/Java\347\233\270\345\205\263/Java\345\237\272\347\241\200\347\237\245\350\257\206.md" +++ /dev/null @@ -1,475 +0,0 @@ - - - - -- [1. 面向对象和面向过程的区别](#1-面向对象和面向过程的区别) - - [面向过程](#面向过程) - - [面向对象](#面向对象) -- [2. Java 语言有哪些特点](#2-java-语言有哪些特点) -- [3. 关于 JVM JDK 和 JRE 最详细通俗的解答](#3-关于-jvm-jdk-和-jre-最详细通俗的解答) - - [JVM](#jvm) - - [JDK 和 JRE](#jdk-和-jre) -- [4. Oracle JDK 和 OpenJDK 的对比](#4-oracle-jdk-和-openjdk-的对比) -- [5. Java和C++的区别](#5-java和c的区别) -- [6. 什么是 Java 程序的主类 应用程序和小程序的主类有何不同](#6-什么是-java-程序的主类-应用程序和小程序的主类有何不同) -- [7. Java 应用程序与小程序之间有那些差别](#7-java-应用程序与小程序之间有那些差别) -- [8. 字符型常量和字符串常量的区别](#8-字符型常量和字符串常量的区别) -- [9. 构造器 Constructor 是否可被 override](#9-构造器-constructor-是否可被-override) -- [10. 重载和重写的区别](#10-重载和重写的区别) -- [11. Java 面向对象编程三大特性: 封装 继承 多态](#11-java-面向对象编程三大特性-封装-继承-多态) - - [封装](#封装) - - [继承](#继承) - - [多态](#多态) -- [12. String StringBuffer 和 StringBuilder 的区别是什么 String 为什么是不可变的](#12-string-stringbuffer-和-stringbuilder-的区别是什么-string-为什么是不可变的) -- [13. 自动装箱与拆箱](#13-自动装箱与拆箱) -- [14. 在一个静态方法内调用一个非静态成员为什么是非法的](#14-在一个静态方法内调用一个非静态成员为什么是非法的) -- [15. 在 Java 中定义一个不做事且没有参数的构造方法的作用](#15-在-java-中定义一个不做事且没有参数的构造方法的作用) -- [16. import java和javax有什么区别](#16-import-java和javax有什么区别) -- [17. 接口和抽象类的区别是什么](#17-接口和抽象类的区别是什么) -- [18. 成员变量与局部变量的区别有那些](#18-成员变量与局部变量的区别有那些) -- [19. 创建一个对象用什么运算符?对象实体与对象引用有何不同?](#19-创建一个对象用什么运算符对象实体与对象引用有何不同) -- [20. 什么是方法的返回值?返回值在类的方法里的作用是什么?](#20-什么是方法的返回值返回值在类的方法里的作用是什么) -- [21. 一个类的构造方法的作用是什么 若一个类没有声明构造方法,该程序能正确执行吗 ?为什么?](#21-一个类的构造方法的作用是什么-若一个类没有声明构造方法该程序能正确执行吗-为什么) -- [22. 构造方法有哪些特性](#22-构造方法有哪些特性) -- [23. 静态方法和实例方法有何不同](#23-静态方法和实例方法有何不同) -- [24. 对象的相等与指向他们的引用相等，两者有什么不同？](#24-对象的相等与指向他们的引用相等两者有什么不同) -- [25. 在调用子类构造方法之前会先调用父类没有参数的构造方法，其目的是?](#25-在调用子类构造方法之前会先调用父类没有参数的构造方法其目的是) -- [26. == 与 equals\(重要\)](#26--与-equals重要) -- [27. hashCode 与 equals \(重要\)](#27-hashcode-与-equals-重要) - - [hashCode（）介绍](#hashcode（）介绍) - - [为什么要有 hashCode](#为什么要有-hashcode) - - [hashCode（）与equals（）的相关规定](#hashcode（）与equals（）的相关规定) -- [28. 为什么Java中只有值传递](#28-为什么java中只有值传递) -- [29. 简述线程，程序、进程的基本概念。以及他们之间关系是什么](#29-简述线程程序进程的基本概念以及他们之间关系是什么) -- [30. 线程有哪些基本状态?](#30-线程有哪些基本状态) -- [31 关于 final 关键字的一些总结](#31-关于-final-关键字的一些总结) -- [32 Java 中的异常处理](#32-java-中的异常处理) - - [Java异常类层次结构图](#java异常类层次结构图) - - [Throwable类常用方法](#throwable类常用方法) - - [异常处理总结](#异常处理总结) -- [33 Java序列化中如果有些字段不想进行序列化 怎么办](#33-java序列化中如果有些字段不想进行序列化-怎么办) -- [34 获取用键盘输入常用的的两种方法](#34-获取用键盘输入常用的的两种方法) -- [参考](#参考) - - - - - -## 1. 面向对象和面向过程的区别 - -### 面向过程 - -**优点：** 性能比面向对象高，因为类调用时需要实例化，开销比较大，比较消耗资源;比如单片机、嵌入式开发、Linux/Unix等一般采用面向过程开发，性能是最重要的因素。 - -**缺点：** 没有面向对象易维护、易复用、易扩展 - -### 面向对象 - -**优点：** 易维护、易复用、易扩展，由于面向对象有封装、继承、多态性的特性，可以设计出低耦合的系统，使系统更加灵活、更加易于维护 - -**缺点：** 性能比面向过程低 - -## 2. Java 语言有哪些特点 - -1. 简单易学； -2. 面向对象（封装，继承，多态）； -3. 平台无关性（ Java 虚拟机实现平台无关性）； -4. 可靠性； -5. 安全性； -6. 支持多线程（ C++ 语言没有内置的多线程机制，因此必须调用操作系统的多线程功能来进行多线程程序设计，而 Java 语言却提供了多线程支持）； -7. 支持网络编程并且很方便（ Java 语言诞生本身就是为简化网络编程设计的，因此 Java 语言不仅支持网络编程而且很方便）； -8. 编译与解释并存； - -## 3. 关于 JVM JDK 和 JRE 最详细通俗的解答 - -### JVM - -Java虚拟机（JVM）是运行 Java 字节码的虚拟机。JVM有针对不同系统的特定实现（Windows，Linux，macOS），目的是使用相同的字节码，它们都会给出相同的结果。 - -**什么是字节码?采用字节码的好处是什么?** - -> 在 Java 中，JVM可以理解的代码就叫做`字节码`（即扩展名为 `.class` 的文件），它不面向任何特定的处理器，只面向虚拟机。Java 语言通过字节码的方式，在一定程度上解决了传统解释型语言执行效率低的问题，同时又保留了解释型语言可移植的特点。所以 Java 程序运行时比较高效，而且，由于字节码并不专对一种特定的机器，因此，Java程序无须重新编译便可在多种不同的计算机上运行。 - -**Java 程序从源代码到运行一般有下面3步：** - -![Java程序运行过程](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/Java%20%E7%A8%8B%E5%BA%8F%E8%BF%90%E8%A1%8C%E8%BF%87%E7%A8%8B.png) - -我们需要格外注意的是 .class->机器码 这一步。在这一步 jvm 类加载器首先加载字节码文件，然后通过解释器逐行解释执行，这种方式的执行速度会相对比较慢。而且，有些方法和代码块是经常需要被调用的，也就是所谓的热点代码，所以后面引进了 JIT 编译器，JIT 属于运行时编译。当 JIT 编译器完成第一次编译后，其会将字节码对应的机器码保存下来，下次可以直接使用。而我们知道，机器码的运行效率肯定是高于 Java 解释器的。这也解释了我们为什么经常会说 Java 是编译与解释共存的语言。 - -> HotSpot采用了惰性评估(Lazy Evaluation)的做法，根据二八定律，消耗大部分系统资源的只有那一小部分的代码（热点代码），而这也就是JIT所需要编译的部分。JVM会根据代码每次被执行的情况收集信息并相应地做出一些优化，因此执行的次数越多，它的速度就越快。JDK 9引入了一种新的编译模式AOT(Ahead of Time Compilation)，它是直接将字节码编译成机器码，这样就避免了JIT预热等各方面的开销。JDK支持分层编译和AOT协作使用。但是 ，AOT 编译器的编译质量是肯定比不上 JIT 编译器的。 - -总结：Java虚拟机（JVM）是运行 Java 字节码的虚拟机。JVM有针对不同系统的特定实现（Windows，Linux，macOS），目的是使用相同的字节码，它们都会给出相同的结果。字节码和不同系统的 JVM 实现是 Java 语言“一次编译，随处可以运行”的关键所在。 - -### JDK 和 JRE - -JDK是Java Development Kit，它是功能齐全的Java SDK。它拥有JRE所拥有的一切，还有编译器（javac）和工具（如javadoc和jdb）。它能够创建和编译程序。 - -JRE 是 Java运行时环境。它是运行已编译 Java 程序所需的所有内容的集合，包括 Java虚拟机（JVM），Java类库，java命令和其他的一些基础构件。但是，它不能用于创建新程序。 - -如果你只是为了运行一下 Java 程序的话，那么你只需要安装 JRE 就可以了。如果你需要进行一些 Java 编程方面的工作，那么你就需要安装JDK了。但是，这不是绝对的。有时，即使您不打算在计算机上进行任何Java开发，仍然需要安装JDK。例如，如果要使用JSP部署Web应用程序，那么从技术上讲，您只是在应用程序服务器中运行Java程序。那你为什么需要JDK呢？因为应用程序服务器会将 JSP 转换为 Java servlet，并且需要使用 JDK 来编译 servlet。 - -## 4. Oracle JDK 和 OpenJDK 的对比 - -可能在看这个问题之前很多人和我一样并没有接触和使用过 OpenJDK 。那么Oracle和OpenJDK之间是否存在重大差异？下面通过我通过我收集到一些资料对你解答这个被很多人忽视的问题。 - -对于Java 7，没什么关键的地方。OpenJDK项目主要基于Sun捐赠的HotSpot源代码。此外，OpenJDK被选为Java 7的参考实现，由Oracle工程师维护。关于JVM，JDK，JRE和OpenJDK之间的区别，Oracle博客帖子在2012年有一个更详细的答案： - -> 问：OpenJDK存储库中的源代码与用于构建Oracle JDK的代码之间有什么区别？ -> -> 答：非常接近 - 我们的Oracle JDK版本构建过程基于OpenJDK 7构建，只添加了几个部分，例如部署代码，其中包括Oracle的Java插件和Java WebStart的实现，以及一些封闭的源代码派对组件，如图形光栅化器，一些开源的第三方组件，如Rhino，以及一些零碎的东西，如附加文档或第三方字体。展望未来，我们的目的是开源Oracle JDK的所有部分，除了我们考虑商业功能的部分。 - -总结： - -1. Oracle JDK版本将每三年发布一次，而OpenJDK版本每三个月发布一次； -2. OpenJDK 是一个参考模型并且是完全开源的，而Oracle JDK是OpenJDK的一个实现，并不是完全开源的； -3. Oracle JDK 比 OpenJDK 更稳定。OpenJDK和Oracle JDK的代码几乎相同，但Oracle JDK有更多的类和一些错误修复。因此，如果您想开发企业/商业软件，我建议您选择Oracle JDK，因为它经过了彻底的测试和稳定。某些情况下，有些人提到在使用OpenJDK 可能会遇到了许多应用程序崩溃的问题，但是，只需切换到Oracle JDK就可以解决问题； -4. 在响应性和JVM性能方面，Oracle JDK与OpenJDK相比提供了更好的性能； -5. Oracle JDK不会为即将发布的版本提供长期支持，用户每次都必须通过更新到最新版本获得支持来获取最新版本； -6. Oracle JDK根据二进制代码许可协议获得许可，而OpenJDK根据GPL v2许可获得许可。 - -## 5. Java和C++的区别 - -我知道很多人没学过 C++，但是面试官就是没事喜欢拿咱们 Java 和 C++ 比呀！没办法！！！就算没学过C++，也要记下来！ - -- 都是面向对象的语言，都支持封装、继承和多态 -- Java 不提供指针来直接访问内存，程序内存更加安全 -- Java 的类是单继承的，C++ 支持多重继承；虽然 Java 的类不可以多继承，但是接口可以多继承。 -- Java 有自动内存管理机制，不需要程序员手动释放无用内存 - - -## 6. 什么是 Java 程序的主类 应用程序和小程序的主类有何不同 - -一个程序中可以有多个类，但只能有一个类是主类。在 Java 应用程序中，这个主类是指包含 main（）方法的类。而在 Java 小程序中，这个主类是一个继承自系统类 JApplet 或 Applet 的子类。应用程序的主类不一定要求是 public 类，但小程序的主类要求必须是 public 类。主类是 Java 程序执行的入口点。 - -## 7. Java 应用程序与小程序之间有那些差别 - -简单说应用程序是从主线程启动(也就是 main() 方法)。applet 小程序没有main方法，主要是嵌在浏览器页面上运行(调用init()线程或者run()来启动)，嵌入浏览器这点跟 flash 的小游戏类似。 - -## 8. 字符型常量和字符串常量的区别 - -1. 形式上: 字符常量是单引号引起的一个字符 字符串常量是双引号引起的若干个字符 -2. 含义上: 字符常量相当于一个整形值( ASCII 值),可以参加表达式运算 字符串常量代表一个地址值(该字符串在内存中存放位置) -3. 占内存大小 字符常量只占2个字节 字符串常量占若干个字节(至少一个字符结束标志) (**注意： char在Java中占两个字节**) - -> java编程思想第四版：2.2.2节 -![](http://my-blog-to-use.oss-cn-beijing.aliyuncs.com/18-9-15/86735519.jpg) - -## 9. 构造器 Constructor 是否可被 override - -在讲继承的时候我们就知道父类的私有属性和构造方法并不能被继承，所以 Constructor 也就不能被 override（重写）,但是可以 overload（重载）,所以你可以看到一个类中有多个构造函数的情况。 - -## 10. 重载和重写的区别 - -**重载：** 发生在同一个类中，方法名必须相同，参数类型不同、个数不同、顺序不同，方法返回值和访问修饰符可以不同，发生在编译时。 　　 - -**重写：** 发生在父子类中，方法名、参数列表必须相同，返回值范围小于等于父类，抛出的异常范围小于等于父类，访问修饰符范围大于等于父类；如果父类方法访问修饰符为 private 则子类就不能重写该方法。 - -## 11. Java 面向对象编程三大特性: 封装 继承 多态 - -### 封装 - -封装把一个对象的属性私有化，同时提供一些可以被外界访问的属性的方法，如果属性不想被外界访问，我们大可不必提供方法给外界访问。但是如果一个类没有提供给外界访问的方法，那么这个类也没有什么意义了。 - - -### 继承 -继承是使用已存在的类的定义作为基础建立新类的技术，新类的定义可以增加新的数据或新的功能，也可以用父类的功能，但不能选择性地继承父类。通过使用继承我们能够非常方便地复用以前的代码。 - -**关于继承如下 3 点请记住：** - -1. 子类拥有父类非 private 的属性和方法。 -2. 子类可以拥有自己属性和方法，即子类可以对父类进行扩展。 -3. 子类可以用自己的方式实现父类的方法。（以后介绍）。 - -### 多态 - -所谓多态就是指程序中定义的引用变量所指向的具体类型和通过该引用变量发出的方法调用在编程时并不确定，而是在程序运行期间才确定，即一个引用变量到底会指向哪个类的实例对象，该引用变量发出的方法调用到底是哪个类中实现的方法，必须在由程序运行期间才能决定。 - -在Java中有两种形式可以实现多态：继承（多个子类对同一方法的重写）和接口（实现接口并覆盖接口中同一方法）。 - -## 12. String StringBuffer 和 StringBuilder 的区别是什么 String 为什么是不可变的 - -**可变性** -　 - -简单的来说：String 类中使用 final 关键字字符数组保存字符串，`private　final　char　value[]`，所以 String 对象是不可变的。而StringBuilder 与 StringBuffer 都继承自 AbstractStringBuilder 类，在 AbstractStringBuilder 中也是使用字符数组保存字符串`char[]value` 但是没有用 final 关键字修饰，所以这两种对象都是可变的。 - -StringBuilder 与 StringBuffer 的构造方法都是调用父类构造方法也就是 AbstractStringBuilder 实现的，大家可以自行查阅源码。 - -AbstractStringBuilder.java - -```java -abstract class AbstractStringBuilder implements Appendable, CharSequence { - char[] value; - int count; - AbstractStringBuilder() { - } - AbstractStringBuilder(int capacity) { - value = new char[capacity]; - } -``` - - -**线程安全性** - -String 中的对象是不可变的，也就可以理解为常量，线程安全。AbstractStringBuilder 是 StringBuilder 与 StringBuffer 的公共父类，定义了一些字符串的基本操作，如 expandCapacity、append、insert、indexOf 等公共方法。StringBuffer 对方法加了同步锁或者对调用的方法加了同步锁，所以是线程安全的。StringBuilder 并没有对方法进行加同步锁，所以是非线程安全的。 -　　 - -**性能** - -每次对 String 类型进行改变的时候，都会生成一个新的 String 对象，然后将指针指向新的 String 对象。StringBuffer 每次都会对 StringBuffer 对象本身进行操作，而不是生成新的对象并改变对象引用。相同情况下使用 StringBuilder 相比使用 StringBuffer 仅能获得 10%~15% 左右的性能提升，但却要冒多线程不安全的风险。 - -**对于三者使用的总结：** -1. 操作少量的数据 = String -2. 单线程操作字符串缓冲区下操作大量数据 = StringBuilder -3. 多线程操作字符串缓冲区下操作大量数据 = StringBuffer - -## 13. 自动装箱与拆箱 -**装箱**：将基本类型用它们对应的引用类型包装起来； - -**拆箱**：将包装类型转换为基本数据类型； - -## 14. 在一个静态方法内调用一个非静态成员为什么是非法的 - -由于静态方法可以不通过对象进行调用，因此在静态方法里，不能调用其他非静态变量，也不可以访问非静态变量成员。 - -## 15. 在 Java 中定义一个不做事且没有参数的构造方法的作用 -　Java 程序在执行子类的构造方法之前，如果没有用 super() 来调用父类特定的构造方法，则会调用父类中“没有参数的构造方法”。因此，如果父类中只定义了有参数的构造方法，而在子类的构造方法中又没有用 super() 来调用父类中特定的构造方法，则编译时将发生错误，因为 Java 程序在父类中找不到没有参数的构造方法可供执行。解决办法是在父类里加上一个不做事且没有参数的构造方法。 -　 -## 16. import java和javax有什么区别 - -刚开始的时候 JavaAPI 所必需的包是 java 开头的包，javax 当时只是扩展 API 包来说使用。然而随着时间的推移，javax 逐渐的扩展成为 Java API 的组成部分。但是，将扩展从 javax 包移动到 java 包将是太麻烦了，最终会破坏一堆现有的代码。因此，最终决定 javax 包将成为标准API的一部分。 - -所以，实际上java和javax没有区别。这都是一个名字。 - -## 17. 接口和抽象类的区别是什么 - -1. 接口的方法默认是 public，所有方法在接口中不能有实现(Java 8 开始接口方法可以有默认实现），抽象类可以有非抽象的方法 -2. 接口中的实例变量默认是 final 类型的，而抽象类中则不一定 -3. 一个类可以实现多个接口，但最多只能实现一个抽象类 -4. 一个类实现接口的话要实现接口的所有方法，而抽象类不一定 -5. 接口不能用 new 实例化，但可以声明，但是必须引用一个实现该接口的对象 从设计层面来说，抽象是对类的抽象，是一种模板设计，接口是行为的抽象，是一种行为的规范。 - -备注:在JDK8中，接口也可以定义静态方法，可以直接用接口名调用。实现类和实现是不可以调用的。如果同时实现两个接口，接口中定义了一样的默认方法，必须重写，不然会报错。(详见issue:[https://github.com/Snailclimb/JavaGuide/issues/146](https://github.com/Snailclimb/JavaGuide/issues/146)) - -## 18. 成员变量与局部变量的区别有那些 - -1. 从语法形式上，看成员变量是属于类的，而局部变量是在方法中定义的变量或是方法的参数；成员变量可以被 public,private,static 等修饰符所修饰，而局部变量不能被访问控制修饰符及 static 所修饰；但是，成员变量和局部变量都能被 final 所修饰； -2. 从变量在内存中的存储方式来看:如果成员变量是使用`static`修饰的，那么这个成员变量是属于类的，如果没有使用使用`static`修饰，这个成员变量是属于实例的。而对象存在于堆内存，局部变量存在于栈内存 -3. 从变量在内存中的生存时间上看:成员变量是对象的一部分，它随着对象的创建而存在，而局部变量随着方法的调用而自动消失。 -4. 成员变量如果没有被赋初值:则会自动以类型的默认值而赋值（一种情况例外被 final 修饰的成员变量也必须显示地赋值）；而局部变量则不会自动赋值。 - -## 19. 创建一个对象用什么运算符?对象实体与对象引用有何不同? - -new运算符，new创建对象实例（对象实例在堆内存中），对象引用指向对象实例（对象引用存放在栈内存中）。一个对象引用可以指向0个或1个对象（一根绳子可以不系气球，也可以系一个气球）;一个对象可以有n个引用指向它（可以用n条绳子系住一个气球）。 - -## 20. 什么是方法的返回值?返回值在类的方法里的作用是什么? - -方法的返回值是指我们获取到的某个方法体中的代码执行后产生的结果！（前提是该方法可能产生结果）。返回值的作用:接收出结果，使得它可以用于其他的操作！ - -## 21. 一个类的构造方法的作用是什么 若一个类没有声明构造方法,该程序能正确执行吗 ?为什么? - -主要作用是完成对类对象的初始化工作。可以执行。因为一个类即使没有声明构造方法也会有默认的不带参数的构造方法。 - -## 22. 构造方法有哪些特性 - -1. 名字与类名相同； -2. 没有返回值，但不能用void声明构造函数； -3. 生成类的对象时自动执行，无需调用。 - -## 23. 静态方法和实例方法有何不同 - -1. 在外部调用静态方法时，可以使用"类名.方法名"的方式，也可以使用"对象名.方法名"的方式。而实例方法只有后面这种方式。也就是说，调用静态方法可以无需创建对象。 - -2. 静态方法在访问本类的成员时，只允许访问静态成员（即静态成员变量和静态方法），而不允许访问实例成员变量和实例方法；实例方法则无此限制. - -## 24. 对象的相等与指向他们的引用相等,两者有什么不同? - -对象的相等，比的是内存中存放的内容是否相等。而引用相等，比较的是他们指向的内存地址是否相等。 - -## 25. 在调用子类构造方法之前会先调用父类没有参数的构造方法,其目的是? - -帮助子类做初始化工作。 - -## 26. == 与 equals(重要) - -**==** : 它的作用是判断两个对象的地址是不是相等。即，判断两个对象是不是同一个对象。(基本数据类型==比较的是值，引用数据类型==比较的是内存地址) - -**equals()** : 它的作用也是判断两个对象是否相等。但它一般有两种使用情况： -- 情况1：类没有覆盖 equals() 方法。则通过 equals() 比较该类的两个对象时，等价于通过“==”比较这两个对象。 -- 情况2：类覆盖了 equals() 方法。一般，我们都覆盖 equals() 方法来两个对象的内容相等；若它们的内容相等，则返回 true (即，认为这两个对象相等)。 - - -**举个例子：** - -```java -public class test1 { - public static void main(String[] args) { - String a = new String("ab"); // a 为一个引用 - String b = new String("ab"); // b为另一个引用,对象的内容一样 - String aa = "ab"; // 放在常量池中 - String bb = "ab"; // 从常量池中查找 - if (aa == bb) // true - System.out.println("aa==bb"); - if (a == b) // false，非同一对象 - System.out.println("a==b"); - if (a.equals(b)) // true - System.out.println("aEQb"); - if (42 == 42.0) { // true - System.out.println("true"); - } - } -} -``` - -**说明：** -- String 中的 equals 方法是被重写过的，因为 object 的 equals 方法是比较的对象的内存地址，而 String 的 equals 方法比较的是对象的值。 -- 当创建 String 类型的对象时，虚拟机会在常量池中查找有没有已经存在的值和要创建的值相同的对象，如果有就把它赋给当前引用。如果没有就在常量池中重新创建一个 String 对象。 - - - -## 27. hashCode 与 equals (重要) - -面试官可能会问你：“你重写过 hashcode 和 equals 么，为什么重写equals时必须重写hashCode方法？” - -### hashCode（）介绍 -hashCode() 的作用是获取哈希码，也称为散列码；它实际上是返回一个int整数。这个哈希码的作用是确定该对象在哈希表中的索引位置。hashCode() 定义在JDK的Object.java中，这就意味着Java中的任何类都包含有hashCode() 函数。 - -散列表存储的是键值对(key-value)，它的特点是：能根据“键”快速的检索出对应的“值”。这其中就利用到了散列码！（可以快速找到所需要的对象） - -### 为什么要有 hashCode - - -**我们以“HashSet 如何检查重复”为例子来说明为什么要有 hashCode：** - -当你把对象加入 HashSet 时，HashSet 会先计算对象的 hashcode 值来判断对象加入的位置，同时也会与其他已经加入的对象的 hashcode 值作比较，如果没有相符的hashcode，HashSet会假设对象没有重复出现。但是如果发现有相同 hashcode 值的对象，这时会调用 equals（）方法来检查 hashcode 相等的对象是否真的相同。如果两者相同，HashSet 就不会让其加入操作成功。如果不同的话，就会重新散列到其他位置。（摘自我的Java启蒙书《Head first java》第二版）。这样我们就大大减少了 equals 的次数，相应就大大提高了执行速度。 - - - -### hashCode（）与equals（）的相关规定 - -1. 如果两个对象相等，则hashcode一定也是相同的 -2. 两个对象相等,对两个对象分别调用equals方法都返回true -3. 两个对象有相同的hashcode值，它们也不一定是相等的 -4. **因此，equals 方法被覆盖过，则 hashCode 方法也必须被覆盖** -5. hashCode() 的默认行为是对堆上的对象产生独特值。如果没有重写 hashCode()，则该 class 的两个对象无论如何都不会相等（即使这两个对象指向相同的数据） - - -## 28. 为什么Java中只有值传递 - - [为什么Java中只有值传递？](https://github.com/Snailclimb/Java-Guide/blob/master/%E9%9D%A2%E8%AF%95%E5%BF%85%E5%A4%87/%E6%9C%80%E6%9C%80%E6%9C%80%E5%B8%B8%E8%A7%81%E7%9A%84Java%E9%9D%A2%E8%AF%95%E9%A2%98%E6%80%BB%E7%BB%93/%E7%AC%AC%E4%B8%80%E5%91%A8%EF%BC%882018-8-7%EF%BC%89.md) - - -## 29. 简述线程,程序,进程的基本概念.以及他们之间关系是什么? - -**线程**与进程相似，但线程是一个比进程更小的执行单位。一个进程在其执行的过程中可以产生多个线程。与进程不同的是同类的多个线程共享同一块内存空间和一组系统资源，所以系统在产生一个线程，或是在各个线程之间作切换工作时，负担要比进程小得多，也正因为如此，线程也被称为轻量级进程。 - -**程序**是含有指令和数据的文件，被存储在磁盘或其他的数据存储设备中，也就是说程序是静态的代码。 - -**进程**是程序的一次执行过程，是系统运行程序的基本单位，因此进程是动态的。系统运行一个程序即是一个进程从创建，运行到消亡的过程。简单来说，一个进程就是一个执行中的程序，它在计算机中一个指令接着一个指令地执行着，同时，每个进程还占有某些系统资源如CPU时间，内存空间，文件，文件，输入输出设备的使用权等等。换句话说，当程序在执行时，将会被操作系统载入内存中。 -线程是进程划分成的更小的运行单位。线程和进程最大的不同在于基本上各进程是独立的，而各线程则不一定，因为同一进程中的线程极有可能会相互影响。从另一角度来说，进程属于操作系统的范畴，主要是同一段时间内，可以同时执行一个以上的程序，而线程则是在同一程序内几乎同时执行一个以上的程序段。 - -## 30. 线程有哪些基本状态? - -Java 线程在运行的生命周期中的指定时刻只可能处于下面6种不同状态的其中一个状态（图源《Java 并发编程艺术》4.1.4节）。 - -![Java线程的状态](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/19-1-29/Java%E7%BA%BF%E7%A8%8B%E7%9A%84%E7%8A%B6%E6%80%81.png) - -线程在生命周期中并不是固定处于某一个状态而是随着代码的执行在不同状态之间切换。Java 线程状态变迁如下图所示（图源《Java 并发编程艺术》4.1.4节）： - -![Java线程状态变迁](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/19-1-29/Java%20%E7%BA%BF%E7%A8%8B%E7%8A%B6%E6%80%81%E5%8F%98%E8%BF%81.png) - - - -由上图可以看出： - -线程创建之后它将处于 **NEW（新建）** 状态，调用 `start()` 方法后开始运行，线程这时候处于 **READY（可运行）** 状态。可运行状态的线程获得了 cpu 时间片（timeslice）后就处于 **RUNNING（运行）** 状态。 - -> 操作系统隐藏 Java虚拟机（JVM）中的 RUNNABLE 和 RUNNING 状态，它只能看到 RUNNABLE 状态（图源：[HowToDoInJava](https://howtodoinjava.com/)：[Java Thread Life Cycle and Thread States](https://howtodoinjava.com/java/multi-threading/java-thread-life-cycle-and-thread-states/)），所以 Java 系统一般将这两个状态统称为 **RUNNABLE（运行中）** 状态 。 - -![RUNNABLE-VS-RUNNING](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/2019-3/RUNNABLE-VS-RUNNING.png) - -当线程执行 `wait()`方法之后，线程进入 **WAITING（等待）**状态。进入等待状态的线程需要依靠其他线程的通知才能够返回到运行状态，而 **TIME_WAITING(超时等待)** 状态相当于在等待状态的基础上增加了超时限制，比如通过 `sleep（long millis）`方法或 `wait（long millis）`方法可以将 Java 线程置于 TIMED WAITING 状态。当超时时间到达后 Java 线程将会返回到 RUNNABLE 状态。当线程调用同步方法时，在没有获取到锁的情况下，线程将会进入到 **BLOCKED（阻塞）** 状态。线程在执行 Runnable 的` run() `方法之后将会进入到 **TERMINATED（终止）** 状态。 - -## 31 关于 final 关键字的一些总结 - -final关键字主要用在三个地方：变量、方法、类。 - -1. 对于一个final变量，如果是基本数据类型的变量，则其数值一旦在初始化之后便不能更改；如果是引用类型的变量，则在对其初始化之后便不能再让其指向另一个对象。 -2. 当用final修饰一个类时，表明这个类不能被继承。final类中的所有成员方法都会被隐式地指定为final方法。 -3. 使用final方法的原因有两个。第一个原因是把方法锁定，以防任何继承类修改它的含义；第二个原因是效率。在早期的Java实现版本中，会将final方法转为内嵌调用。但是如果方法过于庞大，可能看不到内嵌调用带来的任何性能提升（现在的Java版本已经不需要使用final方法进行这些优化了）。类中所有的private方法都隐式地指定为final。 - -## 32 Java 中的异常处理 - -### Java异常类层次结构图 - -![Java异常类层次结构图](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/2019-2/Exception.png) - 在 Java 中，所有的异常都有一个共同的祖先java.lang包中的 **Throwable类**。Throwable： 有两个重要的子类：**Exception（异常）** 和 **Error（错误）** ，二者都是 Java 异常处理的重要子类，各自都包含大量子类。 - -**Error（错误）:是程序无法处理的错误**，表示运行应用程序中较严重问题。大多数错误与代码编写者执行的操作无关，而表示代码运行时 JVM（Java 虚拟机）出现的问题。例如，Java虚拟机运行错误（Virtual MachineError），当 JVM 不再有继续执行操作所需的内存资源时，将出现 OutOfMemoryError。这些异常发生时，Java虚拟机（JVM）一般会选择线程终止。 - -这些错误表示故障发生于虚拟机自身、或者发生在虚拟机试图执行应用时，如Java虚拟机运行错误（Virtual MachineError）、类定义错误（NoClassDefFoundError）等。这些错误是不可查的，因为它们在应用程序的控制和处理能力之 外，而且绝大多数是程序运行时不允许出现的状况。对于设计合理的应用程序来说，即使确实发生了错误，本质上也不应该试图去处理它所引起的异常状况。在 Java中，错误通过Error的子类描述。 - -**Exception（异常）:是程序本身可以处理的异常**。Exception 类有一个重要的子类 **RuntimeException**。RuntimeException 异常由Java虚拟机抛出。**NullPointerException**（要访问的变量没有引用任何对象时，抛出该异常）、**ArithmeticException**（算术运算异常，一个整数除以0时，抛出该异常）和 **ArrayIndexOutOfBoundsException** （下标越界异常）。 - -**注意：异常和错误的区别：异常能被程序本身可以处理，错误是无法处理。** - -### Throwable类常用方法 - -- **public string getMessage()**:返回异常发生时的详细信息 -- **public string toString()**:返回异常发生时的简要描述 -- **public string getLocalizedMessage()**:返回异常对象的本地化信息。使用Throwable的子类覆盖这个方法，可以声称本地化信息。如果子类没有覆盖该方法，则该方法返回的信息与getMessage（）返回的结果相同 -- **public void printStackTrace()**:在控制台上打印Throwable对象封装的异常信息 - -### 异常处理总结 - -- **try 块：**用于捕获异常。其后可接零个或多个catch块，如果没有catch块，则必须跟一个finally块。 -- **catch 块：**用于处理try捕获到的异常。 -- **finally 块：**无论是否捕获或处理异常，finally块里的语句都会被执行。当在try块或catch块中遇到return语句时，finally语句块将在方法返回之前被执行。 - -**在以下4种特殊情况下，finally块不会被执行：** - -1. 在finally语句块第一行发生了异常。 因为在其他行，finally块还是会得到执行 -2. 在前面的代码中用了System.exit(int)已退出程序。 exit是带参函数 ；若该语句在异常语句之后，finally会执行 -3. 程序所在的线程死亡。 -4. 关闭CPU。 - -下面这部分内容来自issue:。 - -**关于返回值：** - -如果try语句里有return，返回的是try语句块中变量值。 -详细执行过程如下： - -1. 如果有返回值，就把返回值保存到局部变量中； -2. 执行jsr指令跳到finally语句里执行； -3. 执行完finally语句后，返回之前保存在局部变量表里的值。 -4. 如果try，finally语句里均有return，忽略try的return，而使用finally的return. - -## 33 Java序列化中如果有些字段不想进行序列化 怎么办 - -对于不想进行序列化的变量，使用transient关键字修饰。 - -transient关键字的作用是：阻止实例中那些用此关键字修饰的的变量序列化；当对象被反序列化时，被transient修饰的变量值不会被持久化和恢复。transient只能修饰变量，不能修饰类和方法。 - -## 34 获取用键盘输入常用的的两种方法 - -方法1：通过 Scanner - -```java -Scanner input = new Scanner(System.in); -String s = input.nextLine(); -input.close(); -``` - -方法2：通过 BufferedReader - -```java -BufferedReader input = new BufferedReader(new InputStreamReader(System.in)); -String s = input.readLine(); -``` - -## 参考 - -- https://stackoverflow.com/questions/1906445/what-is-the-difference-between-jdk-and-jre -- https://www.educba.com/oracle-vs-openjdk/ -- https://stackoverflow.com/questions/22358071/differences-between-oracle-jdk-and-openjdk?answertab=active#tab-top diff --git "a/Java\347\233\270\345\205\263/Java\350\231\232\346\213\237\346\234\272\357\274\210jvm\357\274\211.md" "b/Java\347\233\270\345\205\263/Java\350\231\232\346\213\237\346\234\272\357\274\210jvm\357\274\211.md" deleted file mode 100644 index 238e7c8b5df9e4014b5fb62fcea53ad9f4371a0c..0000000000000000000000000000000000000000 --- "a/Java\347\233\270\345\205\263/Java\350\231\232\346\213\237\346\234\272\357\274\210jvm\357\274\211.md" +++ /dev/null @@ -1,67 +0,0 @@ -Java面试通关手册（Java学习指南）github地址（欢迎star和pull）：[https://github.com/Snailclimb/Java_Guide](https://github.com/Snailclimb/Java_Guide) - - - -下面是按jvm虚拟机知识点分章节总结的一些jvm学习与面试相关的一些东西。一般作为Java程序员在面试的时候一般会问的大多就是**Java内存区域、虚拟机垃圾算法、虚拟垃圾收集器、JVM内存管理**这些问题了。这些内容参考周的《深入理解Java虚拟机》中第二章和第三章就足够了对应下面的[深入理解虚拟机之Java内存区域：](https://link.zhihu.com/?target=https%3A//mp.weixin.qq.com/s%3F__biz%3DMzU4NDQ4MzU5OA%3D%3D%26mid%3D2247483910%26idx%3D1%26sn%3D246f39051a85fc312577499691fba89f%26chksm%3Dfd985467caefdd71f9a7c275952be34484b14f9e092723c19bd4ef557c324169ed084f868bdb%23rd)和[深入理解虚拟机之垃圾回收](https://link.zhihu.com/?target=https%3A//mp.weixin.qq.com/s%3F__biz%3DMzU4NDQ4MzU5OA%3D%3D%26mid%3D2247483914%26idx%3D1%26sn%3D9aa157d4a1570962c39783cdeec7e539%26chksm%3Dfd98546bcaefdd7d9f61cd356e5584e56b64e234c3a403ed93cb6d4dde07a505e3000fd0c427%23rd)这两篇文章。 - - -> ### 常见面试题 - -[深入理解虚拟机之Java内存区域：](https://link.zhihu.com/?target=https%3A//mp.weixin.qq.com/s%3F__biz%3DMzU4NDQ4MzU5OA%3D%3D%26mid%3D2247483910%26idx%3D1%26sn%3D246f39051a85fc312577499691fba89f%26chksm%3Dfd985467caefdd71f9a7c275952be34484b14f9e092723c19bd4ef557c324169ed084f868bdb%23rd) - -1. 介绍下Java内存区域（运行时数据区）。 - -2. 对象的访问定位的两种方式。 - - -[深入理解虚拟机之垃圾回收](https://link.zhihu.com/?target=https%3A//mp.weixin.qq.com/s%3F__biz%3DMzU4NDQ4MzU5OA%3D%3D%26mid%3D2247483914%26idx%3D1%26sn%3D9aa157d4a1570962c39783cdeec7e539%26chksm%3Dfd98546bcaefdd7d9f61cd356e5584e56b64e234c3a403ed93cb6d4dde07a505e3000fd0c427%23rd) - -1. 如何判断对象是否死亡（两种方法）。 - -2. 简单的介绍一下强引用、软引用、弱引用、虚引用（虚引用与软引用和弱引用的区别、使用软引用能带来的好处）。 - -3. 垃圾收集有哪些算法，各自的特点？ - -4. HotSpot为什么要分为新生代和老年代？ - -5. 常见的垃圾回收器有那些？ - -6. 介绍一下CMS,G1收集器。 - -7. Minor Gc和Full GC 有什么不同呢？ - - - -[虚拟机性能监控和故障处理工具](https://link.zhihu.com/?target=https%3A//mp.weixin.qq.com/s%3F__biz%3DMzU4NDQ4MzU5OA%3D%3D%26mid%3D2247483922%26idx%3D1%26sn%3D0695ff4c2700ccebb8fbc39011866bd8%26chksm%3Dfd985473caefdd6583eb42dbbc7f01918dc6827c808292bb74a5b6333e3d526c097c9351e694%23rd) - -1. JVM调优的常见命令行工具有哪些？ - -[深入理解虚拟机之类文件结构](https://link.zhihu.com/?target=https%3A//mp.weixin.qq.com/s%3F__biz%3DMzU4NDQ4MzU5OA%3D%3D%26mid%3D2247483926%26idx%3D1%26sn%3D224413da998f7e024f7b8d87397934d9%26chksm%3Dfd985477caefdd61a2fe1a3f0be29e057082252e579332f5b6d9072a150b838cefe2c47b6e5a%23rd) - -1. 简单介绍一下Class类文件结构（常量池主要存放的是那两大常量？Class文件的继承关系是如何确定的？字段表、方法表、属性表主要包含那些信息？） - -[深入理解虚拟机之虚拟机类加载机制](http://mp.weixin.qq.com/s?__biz=MzU4NDQ4MzU5OA==&mid=2247483934&idx=1&sn=f247f9bee4e240f5e7fac25659da3bff&chksm=fd98547fcaefdd6996e1a7046e03f29df9308bdf82ceeffd111112766ffd3187892700f64b40#rd) - -1. 简单说说类加载过程，里面执行了哪些操作？ - -2. 对类加载器有了解吗？ - -3. 什么是双亲委派模型？ - -4. 双亲委派模型的工作过程以及使用它的好处。 - - - - - -> ### 推荐阅读 - -[深入理解虚拟机之虚拟机字节码执行引擎](https://juejin.im/post/5aebcb076fb9a07a9a10b5f3) - -[《深入理解 Java 内存模型》读书笔记](http://www.54tianzhisheng.cn/2018/02/28/Java-Memory-Model/) （非常不错的文章） - -[全面理解Java内存模型(JMM)及volatile关键字 ](https://blog.csdn.net/javazejian/article/details/72772461) - -**欢迎关注我的微信公众号:"Java面试通关手册"（一个有温度的微信公众号，期待与你共同进步~~~坚持原创，分享美文，分享各种Java学习资源）：** - -![微信公众号](https://user-gold-cdn.xitu.io/2018/3/19/1623c870135a3609?w=215&h=215&f=jpeg&s=29172) diff --git "a/Java\347\233\270\345\205\263/Java\351\233\206\345\220\210\346\241\206\346\236\266\345\270\270\350\247\201\351\235\242\350\257\225\351\242\230\346\200\273\347\273\223.md" "b/Java\347\233\270\345\205\263/Java\351\233\206\345\220\210\346\241\206\346\236\266\345\270\270\350\247\201\351\235\242\350\257\225\351\242\230\346\200\273\347\273\223.md" deleted file mode 100644 index cb0bd1fe0e3dba790dbdec610c25d2654f79ffd3..0000000000000000000000000000000000000000 --- "a/Java\347\233\270\345\205\263/Java\351\233\206\345\220\210\346\241\206\346\236\266\345\270\270\350\247\201\351\235\242\350\257\225\351\242\230\346\200\273\347\273\223.md" +++ /dev/null @@ -1,353 +0,0 @@ - - -1. [List，Set,Map三者的区别及总结](#list，setmap三者的区别及总结) -1. [Arraylist 与 LinkedList 区别](#arraylist-与-linkedlist-区别) -1. [ArrayList 与 Vector 区别（为什么要用Arraylist取代Vector呢？）](#arraylist-与-vector-区别) -1. [HashMap 和 Hashtable 的区别](#hashmap-和-hashtable-的区别) -1. [HashSet 和 HashMap 区别](#hashset-和-hashmap-区别) -1. [HashMap 和 ConcurrentHashMap 的区别](#hashmap-和-concurrenthashmap-的区别) -1. [HashSet如何检查重复](#hashset如何检查重复) -1. [comparable 和 comparator的区别](#comparable-和-comparator的区别) - 1. [Comparator定制排序](#comparator定制排序) - 1. [重写compareTo方法实现按年龄来排序](#重写compareto方法实现按年龄来排序) -1. [如何对Object的list排序？](#如何对object的list排序) -1. [如何实现数组与List的相互转换？](#如何实现数组与list的相互转换) -1. [如何求ArrayList集合的交集 并集 差集 去重复并集](#如何求arraylist集合的交集-并集-差集-去重复并集) -1. [HashMap 的工作原理及代码实现](#hashmap-的工作原理及代码实现) -1. [ConcurrentHashMap 的工作原理及代码实现](#concurrenthashmap-的工作原理及代码实现) -1. [集合框架底层数据结构总结](#集合框架底层数据结构总结) - 1. [- Collection](#--collection) - 1. [1. List](#1-list) - 1. [2. Set](#2-set) - 1. [- Map](#--map) -1. [集合的选用](#集合的选用) -1. [集合的常用方法](#集合的常用方法) - - - - -## List，Set,Map三者的区别及总结 -- **List：对付顺序的好帮手** - - List接口存储一组不唯一（可以有多个元素引用相同的对象），有序的对象 -- **Set:注重独一无二的性质** - - 不允许重复的集合。不会有多个元素引用相同的对象。 - -- **Map:用Key来搜索的专家** - - 使用键值对存储。Map会维护与Key有关联的值。两个Key可以引用相同的对象，但Key不能重复，典型的Key是String类型，但也可以是任何对象。 - - -## Arraylist 与 LinkedList 区别 -Arraylist底层使用的是数组（存读数据效率高，插入删除特定位置效率低），LinkedList 底层使用的是双向链表数据结构（插入，删除效率特别高）（JDK1.6之前为循环链表，JDK1.7取消了循环。注意双向链表和双向循环链表的区别：）； 详细可阅读JDK1.7-LinkedList循环链表优化。学过数据结构这门课后我们就知道采用链表存储，插入，删除元素时间复杂度不受元素位置的影响，都是近似O（1）而数组为近似O（n），因此当数据特别多，而且经常需要插入删除元素时建议选用LinkedList.一般程序只用Arraylist就够用了，因为一般数据量都不会蛮大，Arraylist是使用最多的集合类。 - -## ArrayList 与 Vector 区别 -Vector类的所有方法都是同步的。可以由两个线程安全地访问一个Vector对象、但是一个线程访问Vector -，代码要在同步操作上耗费大量的时间。Arraylist不是同步的，所以在不需要同步时建议使用Arraylist。 - -## HashMap 和 Hashtable 的区别 -1. HashMap是非线程安全的，HashTable是线程安全的；HashTable内部的方法基本都经过synchronized修饰。 - -2. 因为线程安全的问题，HashMap要比HashTable效率高一点，HashTable基本被淘汰。 -3. HashMap允许有null值的存在，而在HashTable中put进的键值只要有一个null，直接抛出NullPointerException。 - -Hashtable和HashMap有几个主要的不同：线程安全以及速度。仅在你需要完全的线程安全的时候使用Hashtable，而如果你使用Java5或以上的话，请使用ConcurrentHashMap吧 - -## HashSet 和 HashMap 区别 -![HashSet 和 HashMap 区别](https://user-gold-cdn.xitu.io/2018/3/2/161e717d734f3b23?w=896&h=363&f=jpeg&s=205536) - -## HashMap 和 ConcurrentHashMap 的区别 -[HashMap与ConcurrentHashMap的区别](https://blog.csdn.net/xuefeng0707/article/details/40834595) - -1. ConcurrentHashMap对整个桶数组进行了分割分段(Segment)，然后在每一个分段上都用lock锁进行保护，相对于HashTable的synchronized锁的粒度更精细了一些，并发性能更好，而HashMap没有锁机制，不是线程安全的。（JDK1.8之后ConcurrentHashMap启用了一种全新的方式实现,利用CAS算法。） -2. HashMap的键值对允许有null，但是ConCurrentHashMap都不允许。 - -## HashSet如何检查重复 -当你把对象加入HashSet时，HashSet会先计算对象的hashcode值来判断对象加入的位置，同时也会与其他加入的对象的hashcode值作比较，如果没有相符的hashcode，HashSet会假设对象没有重复出现。但是如果发现有相同hashcode值的对象，这时会调用equals（）方法来检查hashcode相等的对象是否真的相同。如果两者相同，HashSet就不会让加入操作成功。（摘自我的Java启蒙书《Head fist java》第二版） - -**hashCode（）与equals（）的相关规定：** -1. 如果两个对象相等，则hashcode一定也是相同的 -2. 两个对象相等,对两个equals方法返回true -3. 两个对象有相同的hashcode值，它们也不一定是相等的 -4. 综上，equals方法被覆盖过，则hashCode方法也必须被覆盖 -5. hashCode()的默认行为是对堆上的对象产生独特值。如果没有重写hashCode()，则该class的两个对象无论如何都不会相等（即使这两个对象指向相同的数据）。 - -**==与equals的区别** - -1. ==是判断两个变量或实例是不是指向同一个内存空间 equals是判断两个变量或实例所指向的内存空间的值是不是相同 -2. ==是指对内存地址进行比较 equals()是对字符串的内容进行比较 -3. ==指引用是否相同 equals()指的是值是否相同 - -## comparable 和 comparator的区别 -- comparable接口实际上是出自java.lang包 它有一个 compareTo(Object obj)方法用来排序 -- comparator接口实际上是出自 java.util 包它有一个compare(Object obj1, Object obj2)方法用来排序 - -一般我们需要对一个集合使用自定义排序时，我们就要重写compareTo方法或compare方法，当我们需要对某一个集合实现两种排序方式，比如一个song对象中的歌名和歌手名分别采用一种排序方法的话，我们可以重写compareTo方法和使用自制的Comparator方法或者以两个Comparator来实现歌名排序和歌星名排序，第二种代表我们只能使用两个参数版的Collections.sort(). - -### Comparator定制排序 -```java -import java.util.ArrayList; -import java.util.Collections; -import java.util.Comparator; - -/** - * TODO Collections类方法测试之排序 - * @author 寇爽 - * @date 2017年11月20日 - * @version 1.8 - */ -public class CollectionsSort { - - public static void main(String[] args) { - - ArrayList arrayList = new ArrayList(); - arrayList.add(-1); - arrayList.add(3); - arrayList.add(3); - arrayList.add(-5); - arrayList.add(7); - arrayList.add(4); - arrayList.add(-9); - arrayList.add(-7); - System.out.println("原始数组:"); - System.out.println(arrayList); - // void reverse(List list)：反转 - Collections.reverse(arrayList); - System.out.println("Collections.reverse(arrayList):"); - System.out.println(arrayList); -/* - * void rotate(List list, int distance),旋转。 - * 当distance为正数时，将list后distance个元素整体移到前面。当distance为负数时，将 - * list的前distance个元素整体移到后面。 - - Collections.rotate(arrayList, 4); - System.out.println("Collections.rotate(arrayList, 4):"); - System.out.println(arrayList);*/ - - // void sort(List list),按自然排序的升序排序 - Collections.sort(arrayList); - System.out.println("Collections.sort(arrayList):"); - System.out.println(arrayList); - - // void shuffle(List list),随机排序 - Collections.shuffle(arrayList); - System.out.println("Collections.shuffle(arrayList):"); - System.out.println(arrayList); - - // 定制排序的用法 - Collections.sort(arrayList, new Comparator() { - - @Override - public int compare(Integer o1, Integer o2) { - return o2.compareTo(o1); - } - }); - System.out.println("定制排序后："); - System.out.println(arrayList); - } - -} - -``` -### 重写compareTo方法实现按年龄来排序 -```java -package map; - -import java.util.Set; -import java.util.TreeMap; - -public class TreeMap2 { - - public static void main(String[] args) { - // TODO Auto-generated method stub - TreeMap pdata = new TreeMap(); - pdata.put(new Person("张三", 30), "zhangsan"); - pdata.put(new Person("李四", 20), "lisi"); - pdata.put(new Person("王五", 10), "wangwu"); - pdata.put(new Person("小红", 5), "xiaohong"); - // 得到key的值的同时得到key所对应的值 - Set keys = pdata.keySet(); - for (Person key : keys) { - System.out.println(key.getAge() + "-" + key.getName()); - - } - } -} - -// person对象没有实现Comparable接口，所以必须实现，这样才不会出错，才可以使treemap中的数据按顺序排列 -// 前面一个例子的String类已经默认实现了Comparable接口，详细可以查看String类的API文档，另外其他 -// 像Integer类等都已经实现了Comparable接口，所以不需要另外实现了 - -class Person implements Comparable { - private String name; - private int age; - - public Person(String name, int age) { - super(); - this.name = name; - this.age = age; - } - - public String getName() { - return name; - } - - public void setName(String name) { - this.name = name; - } - - public int getAge() { - return age; - } - - public void setAge(int age) { - this.age = age; - } - - /** - * TODO重写compareTo方法实现按年龄来排序 - */ - @Override - public int compareTo(Person o) { - // TODO Auto-generated method stub - if (this.age > o.getAge()) { - return 1; - } else if (this.age < o.getAge()) { - return -1; - } - return age; - } -} -``` - -## 如何对Object的list排序 -- 对objects数组进行排序，我们可以用Arrays.sort()方法 -- 对objects的集合进行排序，需要使用Collections.sort()方法 - - -## 如何实现数组与List的相互转换 -List转数组：toArray(arraylist.size()方法；数组转List:Arrays的asList(a)方法 -```java -List arrayList = new ArrayList(); - arrayList.add("s"); - arrayList.add("e"); - arrayList.add("n"); - /** - * ArrayList转数组 - */ - int size=arrayList.size(); - String[] a = arrayList.toArray(new String[size]); - //输出第二个元素 - System.out.println(a[1]);//结果：e - //输出整个数组 - System.out.println(Arrays.toString(a));//结果：[s, e, n] - /** - * 数组转list - */ - List list=Arrays.asList(a); - /** - * list转Arraylist - */ - List arrayList2 = new ArrayList(); - arrayList2.addAll(list); - System.out.println(list); -``` -## 如何求ArrayList集合的交集 并集 差集 去重复并集 -需要用到List接口中定义的几个方法： - -- addAll(Collection c) :按指定集合的Iterator返回的顺序将指定集合中的所有元素追加到此列表的末尾 -实例代码： -- retainAll(Collection c): 仅保留此列表中包含在指定集合中的元素。 -- removeAll(Collection c) :从此列表中删除指定集合中包含的所有元素。 -```java -package list; - -import java.util.ArrayList; -import java.util.List; - -/** - *TODO 两个集合之间求交集 并集 差集 去重复并集 - * @author 寇爽 - * @date 2017年11月21日 - * @version 1.8 - */ -public class MethodDemo { - - public static void main(String[] args) { - // TODO Auto-generated method stub - List list1 = new ArrayList(); - list1.add(1); - list1.add(2); - list1.add(3); - list1.add(4); - - List list2 = new ArrayList(); - list2.add(2); - list2.add(3); - list2.add(4); - list2.add(5); - // 并集 - // list1.addAll(list2); - // 交集 - //list1.retainAll(list2); - // 差集 - // list1.removeAll(list2); - // 无重复并集 - list2.removeAll(list1); - list1.addAll(list2); - for (Integer i : list1) { - System.out.println(i); - } - } - -} - -``` - -## HashMap 的工作原理及代码实现 - -[集合框架源码学习之HashMap(JDK1.8)](https://juejin.im/post/5ab0568b5188255580020e56) - -## ConcurrentHashMap 的工作原理及代码实现 - -[ConcurrentHashMap实现原理及源码分析](http://www.cnblogs.com/chengxiao/p/6842045.html) - - -## 集合框架底层数据结构总结 -### - Collection - -#### 1. List - - Arraylist：数组（查询快,增删慢 线程不安全,效率高 ） - - Vector：数组（查询快,增删慢 线程安全,效率低 ） - - LinkedList：链表（查询慢,增删快 线程不安全,效率高 ） - -#### 2. Set - - HashSet（无序，唯一）:哈希表或者叫散列集(hash table) - - LinkedHashSet：链表和哈希表组成 。 由链表保证元素的排序 ， 由哈希表证元素的唯一性 - - TreeSet（有序，唯一）：红黑树(自平衡的排序二叉树。) - -### - Map - - HashMap：基于哈希表的Map接口实现（哈希表对键进行散列，Map结构即映射表存放键值对） - - LinkedHashMap:HashMap 的基础上加上了链表数据结构 - - HashTable:哈希表 - - TreeMap:红黑树（自平衡的排序二叉树） - - -## 集合的选用 -主要根据集合的特点来选用，比如我们需要根据键值获取到元素值时就选用Map接口下的集合，需要排序时选择TreeMap,不需要排序时就选择HashMap,需要保证线程安全就选用ConcurrentHashMap.当我们只需要存放元素值时，就选择实现Collection接口的集合，需要保证元素唯一时选择实现Set接口的集合比如TreeSet或HashSet，不需要就选择实现List接口的比如ArrayList或LinkedList，然后再根据实现这些接口的集合的特点来选用。 - -2018/3/11更新 -## 集合的常用方法 -今天下午无意看见一道某大厂的面试题，面试题的内容就是问你某一个集合常见的方法有哪些。虽然平时也经常见到这些集合，但是猛一下让我想某一个集合的常用的方法难免会有遗漏或者与其他集合搞混，所以建议大家还是照着API文档把常见的那几个集合的常用方法看一看。 - -会持续更新。。。 - -**参考书籍：** - -《Head first java 》第二版 推荐阅读真心不错 （适合基础较差的） - - 《Java核心技术卷1》推荐阅读真心不错 （适合基础较好的） - - 《算法》第四版 （适合想对数据结构的Java实现感兴趣的） - diff --git "a/Java\347\233\270\345\205\263/LinkedList.md" "b/Java\347\233\270\345\205\263/LinkedList.md" deleted file mode 100644 index 31f5f4838e9858890c8e3babee49882c84fa900b..0000000000000000000000000000000000000000 --- "a/Java\347\233\270\345\205\263/LinkedList.md" +++ /dev/null @@ -1,515 +0,0 @@ - - - -- [简介](#简介) -- [内部结构分析](#内部结构分析) -- [LinkedList源码分析](#linkedlist源码分析) - - [构造方法](#构造方法) - - [添加（add）方法](#add方法) - - [根据位置取数据的方法](#根据位置取数据的方法) - - [根据对象得到索引的方法](#根据对象得到索引的方法) - - [检查链表是否包含某对象的方法：](#检查链表是否包含某对象的方法：) - - [删除（remove/pop）方法](#删除方法) -- [LinkedList类常用方法测试：](#linkedlist类常用方法测试) - - - -## 简介 -LinkedList是一个实现了List接口和Deque接口的双端链表。 -LinkedList底层的链表结构使它支持高效的插入和删除操作，另外它实现了Deque接口，使得LinkedList类也具有队列的特性; -LinkedList不是线程安全的，如果想使LinkedList变成线程安全的，可以调用静态类Collections类中的synchronizedList方法： -```java -List list=Collections.synchronizedList(new LinkedList(...)); -``` -## 内部结构分析 -**如下图所示：** -![LinkedList内部结构](https://user-gold-cdn.xitu.io/2018/3/19/1623e363fe0450b0?w=600&h=481&f=jpeg&s=18502) -看完了图之后，我们再看LinkedList类中的一个**内部私有类Node**就很好理解了： -```java -private static class Node { - E item;//节点值 - Node next;//后继节点 - Node prev;//前驱节点 - - Node(Node prev, E element, Node next) { - this.item = element; - this.next = next; - this.prev = prev; - } - } -``` -这个类就代表双端链表的节点Node。这个类有三个属性，分别是前驱节点，本节点的值，后继结点。 - -## LinkedList源码分析 -### 构造方法 -**空构造方法：** -```java - public LinkedList() { - } -``` -**用已有的集合创建链表的构造方法：** -```java - public LinkedList(Collection c) { - this(); - addAll(c); - } -``` -### add方法 -**add(E e)** 方法：将元素添加到链表尾部 -```java -public boolean add(E e) { - linkLast(e);//这里就只调用了这一个方法 - return true; - } -``` - -```java - /** - * 链接使e作为最后一个元素。 - */ - void linkLast(E e) { - final Node l = last; - final Node newNode = new Node<>(l, e, null); - last = newNode;//新建节点 - if (l == null) - first = newNode; - else - l.next = newNode;//指向后继元素也就是指向下一个元素 - size++; - modCount++; - } -``` -**add(int index,E e)**：在指定位置添加元素 -```java -public void add(int index, E element) { - checkPositionIndex(index); //检查索引是否处于[0-size]之间 - - if (index == size)//添加在链表尾部 - linkLast(element); - else//添加在链表中间 - linkBefore(element, node(index)); - } -``` -linkBefore方法需要给定两个参数，一个插入节点的值，一个指定的node，所以我们又调用了Node(index)去找到index对应的node - -**addAll(Collection c )：将集合插入到链表尾部** - -```java -public boolean addAll(Collection c) { - return addAll(size, c); - } -``` -**addAll(int index, Collection c)：** 将集合从指定位置开始插入 -```java -public boolean addAll(int index, Collection c) { - //1:检查index范围是否在size之内 - checkPositionIndex(index); - - //2:toArray()方法把集合的数据存到对象数组中 - Object[] a = c.toArray(); - int numNew = a.length; - if (numNew == 0) - return false; - - //3：得到插入位置的前驱节点和后继节点 - Node pred, succ; - //如果插入位置为尾部，前驱节点为last，后继节点为null - if (index == size) { - succ = null; - pred = last; - } - //否则，调用node()方法得到后继节点，再得到前驱节点 - else { - succ = node(index); - pred = succ.prev; - } - - // 4：遍历数据将数据插入 - for (Object o : a) { - @SuppressWarnings("unchecked") E e = (E) o; - //创建新节点 - Node newNode = new Node<>(pred, e, null); - //如果插入位置在链表头部 - if (pred == null) - first = newNode; - else - pred.next = newNode; - pred = newNode; - } - - //如果插入位置在尾部，重置last节点 - if (succ == null) { - last = pred; - } - //否则，将插入的链表与先前链表连接起来 - else { - pred.next = succ; - succ.prev = pred; - } - - size += numNew; - modCount++; - return true; - } -``` -上面可以看出addAll方法通常包括下面四个步骤： -1. 检查index范围是否在size之内 -2. toArray()方法把集合的数据存到对象数组中 -3. 得到插入位置的前驱和后继节点 -4. 遍历数据，将数据插入到指定位置 - -**addFirst(E e)：** 将元素添加到链表头部 -```java - public void addFirst(E e) { - linkFirst(e); - } -``` -```java -private void linkFirst(E e) { - final Node f = first; - final Node newNode = new Node<>(null, e, f);//新建节点，以头节点为后继节点 - first = newNode; - //如果链表为空，last节点也指向该节点 - if (f == null) - last = newNode; - //否则，将头节点的前驱指针指向新节点，也就是指向前一个元素 - else - f.prev = newNode; - size++; - modCount++; - } -``` -**addLast(E e)：** 将元素添加到链表尾部，与 **add(E e)** 方法一样 -```java -public void addLast(E e) { - linkLast(e); - } -``` -### 根据位置取数据的方法 -**get(int index)：**：根据指定索引返回数据 -```java -public E get(int index) { - //检查index范围是否在size之内 - checkElementIndex(index); - //调用Node(index)去找到index对应的node然后返回它的值 - return node(index).item; - } -``` -**获取头节点（index=0）数据方法:** -```java -public E getFirst() { - final Node f = first; - if (f == null) - throw new NoSuchElementException(); - return f.item; - } -public E element() { - return getFirst(); - } -public E peek() { - final Node f = first; - return (f == null) ? null : f.item; - } - -public E peekFirst() { - final Node f = first; - return (f == null) ? null : f.item; - } -``` -**区别：** -getFirst(),element(),peek(),peekFirst() -这四个获取头结点方法的区别在于对链表为空时的处理，是抛出异常还是返回null，其中**getFirst()** 和**element()** 方法将会在链表为空时，抛出异常 - -element()方法的内部就是使用getFirst()实现的。它们会在链表为空时，抛出NoSuchElementException -**获取尾节点（index=-1）数据方法:** -```java - public E getLast() { - final Node l = last; - if (l == null) - throw new NoSuchElementException(); - return l.item; - } - public E peekLast() { - final Node l = last; - return (l == null) ? null : l.item; - } -``` -**两者区别：** -**getLast()** 方法在链表为空时，会抛出**NoSuchElementException**，而**peekLast()** 则不会，只是会返回 **null**。 -### 根据对象得到索引的方法 -**int indexOf(Object o)：** 从头遍历找 -```java -public int indexOf(Object o) { - int index = 0; - if (o == null) { - //从头遍历 - for (Node x = first; x != null; x = x.next) { - if (x.item == null) - return index; - index++; - } - } else { - //从头遍历 - for (Node x = first; x != null; x = x.next) { - if (o.equals(x.item)) - return index; - index++; - } - } - return -1; - } -``` -**int lastIndexOf(Object o)：** 从尾遍历找 -```java -public int lastIndexOf(Object o) { - int index = size; - if (o == null) { - //从尾遍历 - for (Node x = last; x != null; x = x.prev) { - index--; - if (x.item == null) - return index; - } - } else { - //从尾遍历 - for (Node x = last; x != null; x = x.prev) { - index--; - if (o.equals(x.item)) - return index; - } - } - return -1; - } -``` -### 检查链表是否包含某对象的方法： -**contains(Object o)：** 检查对象o是否存在于链表中 -```java - public boolean contains(Object o) { - return indexOf(o) != -1; - } -``` -### 删除方法 -**remove()** ,**removeFirst(),pop():** 删除头节点 -``` -public E pop() { - return removeFirst(); - } -public E remove() { - return removeFirst(); - } -public E removeFirst() { - final Node f = first; - if (f == null) - throw new NoSuchElementException(); - return unlinkFirst(f); - } -``` -**removeLast(),pollLast():** 删除尾节点 -```java -public E removeLast() { - final Node l = last; - if (l == null) - throw new NoSuchElementException(); - return unlinkLast(l); - } -public E pollLast() { - final Node l = last; - return (l == null) ? null : unlinkLast(l); - } -``` -**区别：** removeLast()在链表为空时将抛出NoSuchElementException，而pollLast()方法返回null。 - -**remove(Object o):** 删除指定元素 -```java -public boolean remove(Object o) { - //如果删除对象为null - if (o == null) { - //从头开始遍历 - for (Node x = first; x != null; x = x.next) { - //找到元素 - if (x.item == null) { - //从链表中移除找到的元素 - unlink(x); - return true; - } - } - } else { - //从头开始遍历 - for (Node x = first; x != null; x = x.next) { - //找到元素 - if (o.equals(x.item)) { - //从链表中移除找到的元素 - unlink(x); - return true; - } - } - } - return false; - } -``` -当删除指定对象时，只需调用remove(Object o)即可，不过该方法一次只会删除一个匹配的对象，如果删除了匹配对象，返回true，否则false。 - -unlink(Node x) 方法： -```java -E unlink(Node x) { - // assert x != null; - final E element = x.item; - final Node next = x.next;//得到后继节点 - final Node prev = x.prev;//得到前驱节点 - - //删除前驱指针 - if (prev == null) { - first = next;如果删除的节点是头节点,令头节点指向该节点的后继节点 - } else { - prev.next = next;//将前驱节点的后继节点指向后继节点 - x.prev = null; - } - - //删除后继指针 - if (next == null) { - last = prev;//如果删除的节点是尾节点,令尾节点指向该节点的前驱节点 - } else { - next.prev = prev; - x.next = null; - } - - x.item = null; - size--; - modCount++; - return element; - } -``` -**remove(int index)**：删除指定位置的元素 -```java -public E remove(int index) { - //检查index范围 - checkElementIndex(index); - //将节点删除 - return unlink(node(index)); - } -``` -## LinkedList类常用方法测试 - -```java -package list; - -import java.util.Iterator; -import java.util.LinkedList; - -public class LinkedListDemo { - public static void main(String[] srgs) { - //创建存放int类型的linkedList - LinkedList linkedList = new LinkedList<>(); - /************************** linkedList的基本操作 ************************/ - linkedList.addFirst(0); // 添加元素到列表开头 - linkedList.add(1); // 在列表结尾添加元素 - linkedList.add(2, 2); // 在指定位置添加元素 - linkedList.addLast(3); // 添加元素到列表结尾 - - System.out.println("LinkedList（直接输出的）: " + linkedList); - - System.out.println("getFirst()获得第一个元素: " + linkedList.getFirst()); // 返回此列表的第一个元素 - System.out.println("getLast()获得第最后一个元素: " + linkedList.getLast()); // 返回此列表的最后一个元素 - System.out.println("removeFirst()删除第一个元素并返回: " + linkedList.removeFirst()); // 移除并返回此列表的第一个元素 - System.out.println("removeLast()删除最后一个元素并返回: " + linkedList.removeLast()); // 移除并返回此列表的最后一个元素 - System.out.println("After remove:" + linkedList); - System.out.println("contains()方法判断列表是否包含1这个元素:" + linkedList.contains(1)); // 判断此列表包含指定元素，如果是，则返回true - System.out.println("该linkedList的大小 : " + linkedList.size()); // 返回此列表的元素个数 - - /************************** 位置访问操作 ************************/ - System.out.println("-----------------------------------------"); - linkedList.set(1, 3); // 将此列表中指定位置的元素替换为指定的元素 - System.out.println("After set(1, 3):" + linkedList); - System.out.println("get(1)获得指定位置（这里为1）的元素: " + linkedList.get(1)); // 返回此列表中指定位置处的元素 - - /************************** Search操作 ************************/ - System.out.println("-----------------------------------------"); - linkedList.add(3); - System.out.println("indexOf(3): " + linkedList.indexOf(3)); // 返回此列表中首次出现的指定元素的索引 - System.out.println("lastIndexOf(3): " + linkedList.lastIndexOf(3));// 返回此列表中最后出现的指定元素的索引 - - /************************** Queue操作 ************************/ - System.out.println("-----------------------------------------"); - System.out.println("peek(): " + linkedList.peek()); // 获取但不移除此列表的头 - System.out.println("element(): " + linkedList.element()); // 获取但不移除此列表的头 - linkedList.poll(); // 获取并移除此列表的头 - System.out.println("After poll():" + linkedList); - linkedList.remove(); - System.out.println("After remove():" + linkedList); // 获取并移除此列表的头 - linkedList.offer(4); - System.out.println("After offer(4):" + linkedList); // 将指定元素添加到此列表的末尾 - - /************************** Deque操作 ************************/ - System.out.println("-----------------------------------------"); - linkedList.offerFirst(2); // 在此列表的开头插入指定的元素 - System.out.println("After offerFirst(2):" + linkedList); - linkedList.offerLast(5); // 在此列表末尾插入指定的元素 - System.out.println("After offerLast(5):" + linkedList); - System.out.println("peekFirst(): " + linkedList.peekFirst()); // 获取但不移除此列表的第一个元素 - System.out.println("peekLast(): " + linkedList.peekLast()); // 获取但不移除此列表的第一个元素 - linkedList.pollFirst(); // 获取并移除此列表的第一个元素 - System.out.println("After pollFirst():" + linkedList); - linkedList.pollLast(); // 获取并移除此列表的最后一个元素 - System.out.println("After pollLast():" + linkedList); - linkedList.push(2); // 将元素推入此列表所表示的堆栈（插入到列表的头） - System.out.println("After push(2):" + linkedList); - linkedList.pop(); // 从此列表所表示的堆栈处弹出一个元素（获取并移除列表第一个元素） - System.out.println("After pop():" + linkedList); - linkedList.add(3); - linkedList.removeFirstOccurrence(3); // 从此列表中移除第一次出现的指定元素（从头部到尾部遍历列表） - System.out.println("After removeFirstOccurrence(3):" + linkedList); - linkedList.removeLastOccurrence(3); // 从此列表中移除最后一次出现的指定元素（从头部到尾部遍历列表） - System.out.println("After removeFirstOccurrence(3):" + linkedList); - - /************************** 遍历操作 ************************/ - System.out.println("-----------------------------------------"); - linkedList.clear(); - for (int i = 0; i < 100000; i++) { - linkedList.add(i); - } - // 迭代器遍历 - long start = System.currentTimeMillis(); - Iterator iterator = linkedList.iterator(); - while (iterator.hasNext()) { - iterator.next(); - } - long end = System.currentTimeMillis(); - System.out.println("Iterator：" + (end - start) + " ms"); - - // 顺序遍历(随机遍历) - start = System.currentTimeMillis(); - for (int i = 0; i < linkedList.size(); i++) { - linkedList.get(i); - } - end = System.currentTimeMillis(); - System.out.println("for：" + (end - start) + " ms"); - - // 另一种for循环遍历 - start = System.currentTimeMillis(); - for (Integer i : linkedList) - ; - end = System.currentTimeMillis(); - System.out.println("for2：" + (end - start) + " ms"); - - // 通过pollFirst()或pollLast()来遍历LinkedList - LinkedList temp1 = new LinkedList<>(); - temp1.addAll(linkedList); - start = System.currentTimeMillis(); - while (temp1.size() != 0) { - temp1.pollFirst(); - } - end = System.currentTimeMillis(); - System.out.println("pollFirst()或pollLast()：" + (end - start) + " ms"); - - // 通过removeFirst()或removeLast()来遍历LinkedList - LinkedList temp2 = new LinkedList<>(); - temp2.addAll(linkedList); - start = System.currentTimeMillis(); - while (temp2.size() != 0) { - temp2.removeFirst(); - } - end = System.currentTimeMillis(); - System.out.println("removeFirst()或removeLast()：" + (end - start) + " ms"); - } -} -``` diff --git "a/Java\347\233\270\345\205\263/Multithread/AQS.md" "b/Java\347\233\270\345\205\263/Multithread/AQS.md" deleted file mode 100644 index f405db1f17df6ff3d9595bc727248d79c10ac1ae..0000000000000000000000000000000000000000 --- "a/Java\347\233\270\345\205\263/Multithread/AQS.md" +++ /dev/null @@ -1,476 +0,0 @@ - -**目录：** - - -- [1 AQS 简单介绍](#1-aqs-简单介绍) -- [2 AQS 原理](#2-aqs-原理) - - [2.1 AQS 原理概览](#21-aqs-原理概览) - - [2.2 AQS 对资源的共享方式](#22-aqs-对资源的共享方式) - - [2.3 AQS底层使用了模板方法模式](#23-aqs底层使用了模板方法模式) -- [3 Semaphore\(信号量\)-允许多个线程同时访问](#3-semaphore信号量-允许多个线程同时访问) -- [4 CountDownLatch （倒计时器）](#4-countdownlatch-倒计时器) - - [4.1 CountDownLatch 的三种典型用法](#41-countdownlatch-的三种典型用法) - - [4.2 CountDownLatch 的使用示例](#42-countdownlatch-的使用示例) - - [4.3 CountDownLatch 的不足](#43-countdownlatch-的不足) - - [4.4 CountDownLatch相常见面试题：](#44-countdownlatch相常见面试题) -- [5 CyclicBarrier\(循环栅栏\)](#5-cyclicbarrier循环栅栏) - - [5.1 CyclicBarrier 的应用场景](#51-cyclicbarrier-的应用场景) - - [5.2 CyclicBarrier 的使用示例](#52-cyclicbarrier-的使用示例) - - [5.3 CyclicBarrier和CountDownLatch的区别](#53-cyclicbarrier和countdownlatch的区别) -- [6 ReentrantLock 和 ReentrantReadWriteLock](#6-reentrantlock-和-reentrantreadwritelock) - - - -> 常见问题：AQS原理？;CountDownLatch和CyclicBarrier了解吗,两者的区别是什么？用过Semaphore吗？ - -**本节思维导图：** - -![并发编程面试必备：AQS 原理以及 AQS 同步组件总结](http://my-blog-to-use.oss-cn-beijing.aliyuncs.com/18-10-31/61115865.jpg) - - -### 1 AQS 简单介绍 -AQS的全称为（AbstractQueuedSynchronizer），这个类在java.util.concurrent.locks包下面。 - -![enter image description here](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/Java%20%E7%A8%8B%E5%BA%8F%E5%91%98%E5%BF%85%E5%A4%87%EF%BC%9A%E5%B9%B6%E5%8F%91%E7%9F%A5%E8%AF%86%E7%B3%BB%E7%BB%9F%E6%80%BB%E7%BB%93/AQS.png) - -AQS是一个用来构建锁和同步器的框架，使用AQS能简单且高效地构造出应用广泛的大量的同步器，比如我们提到的ReentrantLock，Semaphore，其他的诸如ReentrantReadWriteLock，SynchronousQueue，FutureTask等等皆是基于AQS的。当然，我们自己也能利用AQS非常轻松容易地构造出符合我们自己需求的同步器。 - -### 2 AQS 原理 - -> 在面试中被问到并发知识的时候，大多都会被问到“请你说一下自己对于AQS原理的理解”。下面给大家一个示例供大家参加，面试不是背题，大家一定要加入自己的思想，即使加入不了自己的思想也要保证自己能够通俗的讲出来而不是背出来。 - -下面大部分内容其实在AQS类注释上已经给出了，不过是英语看着比较吃力一点，感兴趣的话可以看看源码。 - -#### 2.1 AQS 原理概览 - -**AQS核心思想是，如果被请求的共享资源空闲，则将当前请求资源的线程设置为有效的工作线程，并且将共享资源设置为锁定状态。如果被请求的共享资源被占用，那么就需要一套线程阻塞等待以及被唤醒时锁分配的机制，这个机制AQS是用CLH队列锁实现的，即将暂时获取不到锁的线程加入到队列中。** - -> CLH(Craig,Landin,and Hagersten)队列是一个虚拟的双向队列（虚拟的双向队列即不存在队列实例，仅存在结点之间的关联关系）。AQS是将每条请求共享资源的线程封装成一个CLH锁队列的一个结点（Node）来实现锁的分配。 - -看个AQS(AbstractQueuedSynchronizer)原理图： - - -![enter image description here](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/Java%20%E7%A8%8B%E5%BA%8F%E5%91%98%E5%BF%85%E5%A4%87%EF%BC%9A%E5%B9%B6%E5%8F%91%E7%9F%A5%E8%AF%86%E7%B3%BB%E7%BB%9F%E6%80%BB%E7%BB%93/CLH.png) - -AQS使用一个int成员变量来表示同步状态，通过内置的FIFO队列来完成获取资源线程的排队工作。AQS使用CAS对该同步状态进行原子操作实现对其值的修改。 - -```java -private volatile int state;//共享变量，使用volatile修饰保证线程可见性 -``` - -状态信息通过protected类型的getState，setState，compareAndSetState进行操作 - -```java - -//返回同步状态的当前值 -protected final int getState() { - return state; -} - // 设置同步状态的值 -protected final void setState(int newState) { - state = newState; -} -//原子地（CAS操作）将同步状态值设置为给定值update如果当前同步状态的值等于expect（期望值） -protected final boolean compareAndSetState(int expect, int update) { - return unsafe.compareAndSwapInt(this, stateOffset, expect, update); -} -``` - -#### 2.2 AQS 对资源的共享方式 - -**AQS定义两种资源共享方式** - -- **Exclusive**（独占）：只有一个线程能执行，如ReentrantLock。又可分为公平锁和非公平锁： - - 公平锁：按照线程在队列中的排队顺序，先到者先拿到锁 - - 非公平锁：当线程要获取锁时，无视队列顺序直接去抢锁，谁抢到就是谁的 -- **Share**（共享）：多个线程可同时执行，如Semaphore/CountDownLatch。Semaphore、CountDownLatCh、 CyclicBarrier、ReadWriteLock 我们都会在后面讲到。 - -ReentrantReadWriteLock 可以看成是组合式，因为ReentrantReadWriteLock也就是读写锁允许多个线程同时对某一资源进行读。 - -不同的自定义同步器争用共享资源的方式也不同。自定义同步器在实现时只需要实现共享资源 state 的获取与释放方式即可，至于具体线程等待队列的维护（如获取资源失败入队/唤醒出队等），AQS已经在上层已经帮我们实现好了。 - -#### 2.3 AQS底层使用了模板方法模式 - -同步器的设计是基于模板方法模式的，如果需要自定义同步器一般的方式是这样（模板方法模式很经典的一个应用）： - -1. 使用者继承AbstractQueuedSynchronizer并重写指定的方法。（这些重写方法很简单，无非是对于共享资源state的获取和释放） -2. 将AQS组合在自定义同步组件的实现中，并调用其模板方法，而这些模板方法会调用使用者重写的方法。 - -这和我们以往通过实现接口的方式有很大区别，这是模板方法模式很经典的一个运用，下面简单的给大家介绍一下模板方法模式，模板方法模式是一个很容易理解的设计模式之一。 - -> 模板方法模式是基于”继承“的，主要是为了在不改变模板结构的前提下在子类中重新定义模板中的内容以实现复用代码。举个很简单的例子假如我们要去一个地方的步骤是：购票`buyTicket()`->安检`securityCheck()`->乘坐某某工具回家`ride()`->到达目的地`arrive()`。我们可能乘坐不同的交通工具回家比如飞机或者火车，所以除了`ride()`方法，其他方法的实现几乎相同。我们可以定义一个包含了这些方法的抽象类，然后用户根据自己的需要继承该抽象类然后修改 `ride()`方法。 - -**AQS使用了模板方法模式，自定义同步器时需要重写下面几个AQS提供的模板方法：** - -```java -isHeldExclusively()//该线程是否正在独占资源。只有用到condition才需要去实现它。 -tryAcquire(int)//独占方式。尝试获取资源，成功则返回true，失败则返回false。 -tryRelease(int)//独占方式。尝试释放资源，成功则返回true，失败则返回false。 -tryAcquireShared(int)//共享方式。尝试获取资源。负数表示失败；0表示成功，但没有剩余可用资源；正数表示成功，且有剩余资源。 -tryReleaseShared(int)//共享方式。尝试释放资源，成功则返回true，失败则返回false。 - -``` - -默认情况下，每个方法都抛出 `UnsupportedOperationException`。 这些方法的实现必须是内部线程安全的，并且通常应该简短而不是阻塞。AQS类中的其他方法都是final ，所以无法被其他类使用，只有这几个方法可以被其他类使用。 - -以ReentrantLock为例，state初始化为0，表示未锁定状态。A线程lock()时，会调用tryAcquire()独占该锁并将state+1。此后，其他线程再tryAcquire()时就会失败，直到A线程unlock()到state=0（即释放锁）为止，其它线程才有机会获取该锁。当然，释放锁之前，A线程自己是可以重复获取此锁的（state会累加），这就是可重入的概念。但要注意，获取多少次就要释放多么次，这样才能保证state是能回到零态的。 - -再以CountDownLatch以例，任务分为N个子线程去执行，state也初始化为N（注意N要与线程个数一致）。这N个子线程是并行执行的，每个子线程执行完后countDown()一次，state会CAS(Compare and Swap)减1。等到所有子线程都执行完后(即state=0)，会unpark()主调用线程，然后主调用线程就会从await()函数返回，继续后余动作。 - -一般来说，自定义同步器要么是独占方法，要么是共享方式，他们也只需实现`tryAcquire-tryRelease`、`tryAcquireShared-tryReleaseShared`中的一种即可。但AQS也支持自定义同步器同时实现独占和共享两种方式，如`ReentrantReadWriteLock`。 - -推荐两篇 AQS 原理和相关源码分析的文章： - -- http://www.cnblogs.com/waterystone/p/4920797.html -- https://www.cnblogs.com/chengxiao/archive/2017/07/24/7141160.html - - - -### 3 Semaphore(信号量)-允许多个线程同时访问 - -**synchronized 和 ReentrantLock 都是一次只允许一个线程访问某个资源，Semaphore(信号量)可以指定多个线程同时访问某个资源。**示例代码如下： - -```java -/** - * - * @author Snailclimb - * @date 2018年9月30日 - * @Description: 需要一次性拿一个许可的情况 - */ -public class SemaphoreExample1 { - // 请求的数量 - private static final int threadCount = 550; - - public static void main(String[] args) throws InterruptedException { - // 创建一个具有固定线程数量的线程池对象（如果这里线程池的线程数量给太少的话你会发现执行的很慢） - ExecutorService threadPool = Executors.newFixedThreadPool(300); - // 一次只能允许执行的线程数量。 - final Semaphore semaphore = new Semaphore(20); - - for (int i = 0; i < threadCount; i++) { - final int threadnum = i; - threadPool.execute(() -> {// Lambda 表达式的运用 - try { - semaphore.acquire();// 获取一个许可，所以可运行线程数量为20/1=20 - test(threadnum); - semaphore.release();// 释放一个许可 - } catch (InterruptedException e) { - // TODO Auto-generated catch block - e.printStackTrace(); - } - - }); - } - threadPool.shutdown(); - System.out.println("finish"); - } - - public static void test(int threadnum) throws InterruptedException { - Thread.sleep(1000);// 模拟请求的耗时操作 - System.out.println("threadnum:" + threadnum); - Thread.sleep(1000);// 模拟请求的耗时操作 - } -} -``` - -执行 `acquire` 方法阻塞，直到有一个许可证可以获得然后拿走一个许可证；每个 `release` 方法增加一个许可证，这可能会释放一个阻塞的acquire方法。然而，其实并没有实际的许可证这个对象，Semaphore只是维持了一个可获得许可证的数量。 Semaphore经常用于限制获取某种资源的线程数量。 - -当然一次也可以一次拿取和释放多个许可，不过一般没有必要这样做： - -```java - semaphore.acquire(5);// 获取5个许可，所以可运行线程数量为20/5=4 - test(threadnum); - semaphore.release(5);// 获取5个许可，所以可运行线程数量为20/5=4 -``` - -除了 `acquire`方法之外，另一个比较常用的与之对应的方法是`tryAcquire`方法，该方法如果获取不到许可就立即返回false。 - - -Semaphore 有两种模式，公平模式和非公平模式。 - -- **公平模式：** 调用acquire的顺序就是获取许可证的顺序，遵循FIFO； -- **非公平模式：** 抢占式的。 - -**Semaphore 对应的两个构造方法如下：** - -```java - public Semaphore(int permits) { - sync = new NonfairSync(permits); - } - - public Semaphore(int permits, boolean fair) { - sync = fair ? new FairSync(permits) : new NonfairSync(permits); - } -``` -**这两个构造方法，都必须提供许可的数量，第二个构造方法可以指定是公平模式还是非公平模式，默认非公平模式。** - -由于篇幅问题，如果对 Semaphore 源码感兴趣的朋友可以看下面这篇文章： - -- https://blog.csdn.net/qq_19431333/article/details/70212663 - -### 4 CountDownLatch （倒计时器） - -CountDownLatch是一个同步工具类，它允许一个或多个线程一直等待，直到其他线程的操作执行完后再执行。在Java并发中，countdownlatch的概念是一个常见的面试题，所以一定要确保你很好的理解了它。 - -#### 4.1 CountDownLatch 的三种典型用法 - -①某一线程在开始运行前等待n个线程执行完毕。将 CountDownLatch 的计数器初始化为n ：`new CountDownLatch(n) `，每当一个任务线程执行完毕，就将计数器减1 `countdownlatch.countDown()`，当计数器的值变为0时，在`CountDownLatch上 await()` 的线程就会被唤醒。一个典型应用场景就是启动一个服务时，主线程需要等待多个组件加载完毕，之后再继续执行。 - -②实现多个线程开始执行任务的最大并行性。注意是并行性，不是并发，强调的是多个线程在某一时刻同时开始执行。类似于赛跑，将多个线程放到起点，等待发令枪响，然后同时开跑。做法是初始化一个共享的 `CountDownLatch` 对象，将其计数器初始化为 1 ：`new CountDownLatch(1) `，多个线程在开始执行任务前首先 `coundownlatch.await()`，当主线程调用 countDown() 时，计数器变为0，多个线程同时被唤醒。 - -③死锁检测：一个非常方便的使用场景是，你可以使用n个线程访问共享资源，在每次测试阶段的线程数目是不同的，并尝试产生死锁。 - -#### 4.2 CountDownLatch 的使用示例 - -```java -/** - * - * @author SnailClimb - * @date 2018年10月1日 - * @Description: CountDownLatch 使用方法示例 - */ -public class CountDownLatchExample1 { - // 请求的数量 - private static final int threadCount = 550; - - public static void main(String[] args) throws InterruptedException { - // 创建一个具有固定线程数量的线程池对象（如果这里线程池的线程数量给太少的话你会发现执行的很慢） - ExecutorService threadPool = Executors.newFixedThreadPool(300); - final CountDownLatch countDownLatch = new CountDownLatch(threadCount); - for (int i = 0; i < threadCount; i++) { - final int threadnum = i; - threadPool.execute(() -> {// Lambda 表达式的运用 - try { - test(threadnum); - } catch (InterruptedException e) { - // TODO Auto-generated catch block - e.printStackTrace(); - } finally { - countDownLatch.countDown();// 表示一个请求已经被完成 - } - - }); - } - countDownLatch.await(); - threadPool.shutdown(); - System.out.println("finish"); - } - - public static void test(int threadnum) throws InterruptedException { - Thread.sleep(1000);// 模拟请求的耗时操作 - System.out.println("threadnum:" + threadnum); - Thread.sleep(1000);// 模拟请求的耗时操作 - } -} - -``` -上面的代码中，我们定义了请求的数量为550，当这550个请求被处理完成之后，才会执行`System.out.println("finish");`。 - -与CountDownLatch的第一次交互是主线程等待其他线程。主线程必须在启动其他线程后立即调用CountDownLatch.await()方法。这样主线程的操作就会在这个方法上阻塞，直到其他线程完成各自的任务。 - -其他N个线程必须引用闭锁对象，因为他们需要通知CountDownLatch对象，他们已经完成了各自的任务。这种通知机制是通过 CountDownLatch.countDown()方法来完成的；每调用一次这个方法，在构造函数中初始化的count值就减1。所以当N个线程都调 用了这个方法，count的值等于0，然后主线程就能通过await()方法，恢复执行自己的任务。 - -#### 4.3 CountDownLatch 的不足 - -CountDownLatch是一次性的，计数器的值只能在构造方法中初始化一次，之后没有任何机制再次对其设置值，当CountDownLatch使用完毕后，它不能再次被使用。 - -#### 4.4 CountDownLatch相常见面试题： - -解释一下CountDownLatch概念？ - -CountDownLatch 和CyclicBarrier的不同之处？ - -给出一些CountDownLatch使用的例子？ - -CountDownLatch 类中主要的方法？ - -### 5 CyclicBarrier(循环栅栏) - -CyclicBarrier 和 CountDownLatch 非常类似，它也可以实现线程间的技术等待，但是它的功能比 CountDownLatch 更加复杂和强大。主要应用场景和 CountDownLatch 类似。 - -CyclicBarrier 的字面意思是可循环使用（Cyclic）的屏障（Barrier）。它要做的事情是，让一组线程到达一个屏障（也可以叫同步点）时被阻塞，直到最后一个线程到达屏障时，屏障才会开门，所有被屏障拦截的线程才会继续干活。CyclicBarrier默认的构造方法是 `CyclicBarrier(int parties)`，其参数表示屏障拦截的线程数量，每个线程调用`await`方法告诉 CyclicBarrier 我已经到达了屏障，然后当前线程被阻塞。 - -#### 5.1 CyclicBarrier 的应用场景 - -CyclicBarrier 可以用于多线程计算数据，最后合并计算结果的应用场景。比如我们用一个Excel保存了用户所有银行流水，每个Sheet保存一个帐户近一年的每笔银行流水，现在需要统计用户的日均银行流水，先用多线程处理每个sheet里的银行流水，都执行完之后，得到每个sheet的日均银行流水，最后，再用barrierAction用这些线程的计算结果，计算出整个Excel的日均银行流水。 - -#### 5.2 CyclicBarrier 的使用示例 - -示例1： - -```java -/** - * - * @author Snailclimb - * @date 2018年10月1日 - * @Description: 测试 CyclicBarrier 类中带参数的 await() 方法 - */ -public class CyclicBarrierExample2 { - // 请求的数量 - private static final int threadCount = 550; - // 需要同步的线程数量 - private static final CyclicBarrier cyclicBarrier = new CyclicBarrier(5); - - public static void main(String[] args) throws InterruptedException { - // 创建线程池 - ExecutorService threadPool = Executors.newFixedThreadPool(10); - - for (int i = 0; i < threadCount; i++) { - final int threadNum = i; - Thread.sleep(1000); - threadPool.execute(() -> { - try { - test(threadNum); - } catch (InterruptedException e) { - // TODO Auto-generated catch block - e.printStackTrace(); - } catch (BrokenBarrierException e) { - // TODO Auto-generated catch block - e.printStackTrace(); - } - }); - } - threadPool.shutdown(); - } - - public static void test(int threadnum) throws InterruptedException, BrokenBarrierException { - System.out.println("threadnum:" + threadnum + "is ready"); - try { - /**等待60秒，保证子线程完全执行结束*/ - cyclicBarrier.await(60, TimeUnit.SECONDS); - } catch (Exception e) { - System.out.println("-----CyclicBarrierException------"); - } - System.out.println("threadnum:" + threadnum + "is finish"); - } - -} -``` - -运行结果，如下： - -``` -threadnum:0is ready -threadnum:1is ready -threadnum:2is ready -threadnum:3is ready -threadnum:4is ready -threadnum:4is finish -threadnum:0is finish -threadnum:1is finish -threadnum:2is finish -threadnum:3is finish -threadnum:5is ready -threadnum:6is ready -threadnum:7is ready -threadnum:8is ready -threadnum:9is ready -threadnum:9is finish -threadnum:5is finish -threadnum:8is finish -threadnum:7is finish -threadnum:6is finish -...... -``` -可以看到当线程数量也就是请求数量达到我们定义的 5 个的时候， `await`方法之后的方法才被执行。 - -另外，CyclicBarrier还提供一个更高级的构造函数`CyclicBarrier(int parties, Runnable barrierAction)`，用于在线程到达屏障时，优先执行`barrierAction`，方便处理更复杂的业务场景。示例代码如下： - -```java -/** - * - * @author SnailClimb - * @date 2018年10月1日 - * @Description: 新建 CyclicBarrier 的时候指定一个 Runnable - */ -public class CyclicBarrierExample3 { - // 请求的数量 - private static final int threadCount = 550; - // 需要同步的线程数量 - private static final CyclicBarrier cyclicBarrier = new CyclicBarrier(5, () -> { - System.out.println("------当线程数达到之后，优先执行------"); - }); - - public static void main(String[] args) throws InterruptedException { - // 创建线程池 - ExecutorService threadPool = Executors.newFixedThreadPool(10); - - for (int i = 0; i < threadCount; i++) { - final int threadNum = i; - Thread.sleep(1000); - threadPool.execute(() -> { - try { - test(threadNum); - } catch (InterruptedException e) { - // TODO Auto-generated catch block - e.printStackTrace(); - } catch (BrokenBarrierException e) { - // TODO Auto-generated catch block - e.printStackTrace(); - } - }); - } - threadPool.shutdown(); - } - - public static void test(int threadnum) throws InterruptedException, BrokenBarrierException { - System.out.println("threadnum:" + threadnum + "is ready"); - cyclicBarrier.await(); - System.out.println("threadnum:" + threadnum + "is finish"); - } - -} -``` - -运行结果，如下： - -``` -threadnum:0is ready -threadnum:1is ready -threadnum:2is ready -threadnum:3is ready -threadnum:4is ready -------当线程数达到之后，优先执行------ -threadnum:4is finish -threadnum:0is finish -threadnum:2is finish -threadnum:1is finish -threadnum:3is finish -threadnum:5is ready -threadnum:6is ready -threadnum:7is ready -threadnum:8is ready -threadnum:9is ready -------当线程数达到之后，优先执行------ -threadnum:9is finish -threadnum:5is finish -threadnum:6is finish -threadnum:8is finish -threadnum:7is finish -...... -``` -#### 5.3 CyclicBarrier和CountDownLatch的区别 - -CountDownLatch是计数器，只能使用一次，而CyclicBarrier的计数器提供reset功能，可以多次使用。但是我不那么认为它们之间的区别仅仅就是这么简单的一点。我们来从jdk作者设计的目的来看，javadoc是这么描述它们的： - -> CountDownLatch: A synchronization aid that allows one or more threads to wait until a set of operations being performed in other threads completes.(CountDownLatch: 一个或者多个线程，等待其他多个线程完成某件事情之后才能执行；) -> CyclicBarrier : A synchronization aid that allows a set of threads to all wait for each other to reach a common barrier point.(CyclicBarrier : 多个线程互相等待，直到到达同一个同步点，再继续一起执行。) - -对于CountDownLatch来说，重点是“一个线程（多个线程）等待”，而其他的N个线程在完成“某件事情”之后，可以终止，也可以等待。而对于CyclicBarrier，重点是多个线程，在任意一个线程没有完成，所有的线程都必须等待。 - -CountDownLatch是计数器，线程完成一个记录一个，只不过计数不是递增而是递减，而CyclicBarrier更像是一个阀门，需要所有线程都到达，阀门才能打开，然后继续执行。 - -![CyclicBarrier和CountDownLatch的区别](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/Java%20%E7%A8%8B%E5%BA%8F%E5%91%98%E5%BF%85%E5%A4%87%EF%BC%9A%E5%B9%B6%E5%8F%91%E7%9F%A5%E8%AF%86%E7%B3%BB%E7%BB%9F%E6%80%BB%E7%BB%93/AQS333.png) - -CyclicBarrier和CountDownLatch的区别这部分内容参考了如下两篇文章： - -- https://blog.csdn.net/u010185262/article/details/54692886 -- https://blog.csdn.net/tolcf/article/details/50925145?utm_source=blogxgwz0 - -### 6 ReentrantLock 和 ReentrantReadWriteLock - -ReentrantLock 和 synchronized 的区别在上面已经讲过了这里就不多做讲解。另外，需要注意的是：读写锁 ReentrantReadWriteLock 可以保证多个线程可以同时读，所以在读操作远大于写操作的时候，读写锁就非常有用了。 - -由于篇幅问题，关于 ReentrantLock 和 ReentrantReadWriteLock 详细内容可以查看我的这篇原创文章。 - -- [ReentrantLock 和 ReentrantReadWriteLock](https://mp.weixin.qq.com/s?__biz=MzU4NDQ4MzU5OA==&mid=2247483745&idx=2&sn=6778ee954a19816310df54ef9a3c2f8a&chksm=fd985700caefde16b9970f5e093b0c140d3121fb3a8458b11871e5e9723c5fd1b5a961fd2228&token=1829606453&lang=zh_CN#rd) diff --git "a/Java\347\233\270\345\205\263/Multithread/BATJ\351\203\275\347\210\261\351\227\256\347\232\204\345\244\232\347\272\277\347\250\213\351\235\242\350\257\225\351\242\230.md" "b/Java\347\233\270\345\205\263/Multithread/BATJ\351\203\275\347\210\261\351\227\256\347\232\204\345\244\232\347\272\277\347\250\213\351\235\242\350\257\225\351\242\230.md" deleted file mode 100644 index 10d6177b040b9415a8d5e86017c24f553e7543f8..0000000000000000000000000000000000000000 --- "a/Java\347\233\270\345\205\263/Multithread/BATJ\351\203\275\347\210\261\351\227\256\347\232\204\345\244\232\347\272\277\347\250\213\351\235\242\350\257\225\351\242\230.md" +++ /dev/null @@ -1,429 +0,0 @@ - - - -# 一 面试中关于 synchronized 关键字的 5 连击 - -### 1.1 说一说自己对于 synchronized 关键字的了解 - -synchronized关键字解决的是多个线程之间访问资源的同步性，synchronized关键字可以保证被它修饰的方法或者代码块在任意时刻只能有一个线程执行。 - -另外，在 Java 早期版本中，synchronized属于重量级锁，效率低下，因为监视器锁（monitor）是依赖于底层的操作系统的 Mutex Lock 来实现的，Java 的线程是映射到操作系统的原生线程之上的。如果要挂起或者唤醒一个线程，都需要操作系统帮忙完成，而操作系统实现线程之间的切换时需要从用户态转换到内核态，这个状态之间的转换需要相对比较长的时间，时间成本相对较高，这也是为什么早期的 synchronized 效率低的原因。庆幸的是在 Java 6 之后 Java 官方对从 JVM 层面对synchronized 较大优化，所以现在的 synchronized 锁效率也优化得很不错了。JDK1.6对锁的实现引入了大量的优化，如自旋锁、适应性自旋锁、锁消除、锁粗化、偏向锁、轻量级锁等技术来减少锁操作的开销。 - - -### 1.2 说说自己是怎么使用 synchronized 关键字，在项目中用到了吗 - -**synchronized关键字最主要的三种使用方式：** - -- **修饰实例方法，作用于当前对象实例加锁，进入同步代码前要获得当前对象实例的锁** -- **修饰静态方法，作用于当前类对象加锁，进入同步代码前要获得当前类对象的锁** 。也就是给当前类加锁，会作用于类的所有对象实例，因为静态成员不属于任何一个实例对象，是类成员（ static 表明这是该类的一个静态资源，不管new了多少个对象，只有一份，所以对该类的所有对象都加了锁）。所以如果一个线程A调用一个实例对象的非静态 synchronized 方法，而线程B需要调用这个实例对象所属类的静态 synchronized 方法，是允许的，不会发生互斥现象，**因为访问静态 synchronized 方法占用的锁是当前类的锁，而访问非静态 synchronized 方法占用的锁是当前实例对象锁**。 -- **修饰代码块，指定加锁对象，对给定对象加锁，进入同步代码库前要获得给定对象的锁。** 和 synchronized 方法一样，synchronized(this)代码块也是锁定当前对象的。synchronized 关键字加到 static 静态方法和 synchronized(class)代码块上都是是给 Class 类上锁。这里再提一下：synchronized关键字加到非 static 静态方法上是给对象实例上锁。另外需要注意的是：尽量不要使用 synchronized(String a) 因为JVM中，字符串常量池具有缓冲功能！ - -下面我已一个常见的面试题为例讲解一下 synchronized 关键字的具体使用。 - -面试中面试官经常会说：“单例模式了解吗？来给我手写一下！给我解释一下双重检验锁方式实现单例模式的原理呗！” - - - -**双重校验锁实现对象单例（线程安全）** - -```java -public class Singleton { - - private volatile static Singleton uniqueInstance; - - private Singleton() { - } - - public static Singleton getUniqueInstance() { - //先判断对象是否已经实例过，没有实例化过才进入加锁代码 - if (uniqueInstance == null) { - //类对象加锁 - synchronized (Singleton.class) { - if (uniqueInstance == null) { - uniqueInstance = new Singleton(); - } - } - } - return uniqueInstance; - } -} -``` -另外，需要注意 uniqueInstance 采用 volatile 关键字修饰也是很有必要。 - -uniqueInstance 采用 volatile 关键字修饰也是很有必要的， uniqueInstance = new Singleton(); 这段代码其实是分为三步执行： - -1. 为 uniqueInstance 分配内存空间 -2. 初始化 uniqueInstance -3. 将 uniqueInstance 指向分配的内存地址 - -但是由于 JVM 具有指令重排的特性，执行顺序有可能变成 1->3->2。指令重排在单线程环境下不会出先问题，但是在多线程环境下会导致一个线程获得还没有初始化的实例。例如，线程 T1 执行了 1 和 3，此时 T2 调用 getUniqueInstance() 后发现 uniqueInstance 不为空，因此返回 uniqueInstance，但此时 uniqueInstance 还未被初始化。 - -使用 volatile 可以禁止 JVM 的指令重排，保证在多线程环境下也能正常运行。 - -### 1.3 讲一下 synchronized 关键字的底层原理 - -**synchronized 关键字底层原理属于 JVM 层面。** - -**① synchronized 同步语句块的情况** - -```java -public class SynchronizedDemo { - public void method() { - synchronized (this) { - System.out.println("synchronized 代码块"); - } - } -} - -``` - -通过 JDK 自带的 javap 命令查看 SynchronizedDemo 类的相关字节码信息：首先切换到类的对应目录执行 `javac SynchronizedDemo.java` 命令生成编译后的 .class 文件，然后执行`javap -c -s -v -l SynchronizedDemo.class`。 - -![synchronized 关键字原理](https://user-gold-cdn.xitu.io/2018/10/26/166add616a292bcf?w=917&h=633&f=png&s=21863) - -从上面我们可以看出： - -**synchronized 同步语句块的实现使用的是 monitorenter 和 monitorexit 指令，其中 monitorenter 指令指向同步代码块的开始位置，monitorexit 指令则指明同步代码块的结束位置。** 当执行 monitorenter 指令时，线程试图获取锁也就是获取 monitor(monitor对象存在于每个Java对象的对象头中，synchronized 锁便是通过这种方式获取锁的，也是为什么Java中任意对象可以作为锁的原因) 的持有权.当计数器为0则可以成功获取，获取后将锁计数器设为1也就是加1。相应的在执行 monitorexit 指令后，将锁计数器设为0，表明锁被释放。如果获取对象锁失败，那当前线程就要阻塞等待，直到锁被另外一个线程释放为止。 - -**② synchronized 修饰方法的的情况** - -```java -public class SynchronizedDemo2 { - public synchronized void method() { - System.out.println("synchronized 方法"); - } -} - -``` - -![synchronized 关键字原理](https://user-gold-cdn.xitu.io/2018/10/26/166add6169fc206d?w=875&h=421&f=png&s=16114) - -synchronized 修饰的方法并没有 monitorenter 指令和 monitorexit 指令，取得代之的确实是 ACC_SYNCHRONIZED 标识，该标识指明了该方法是一个同步方法，JVM 通过该 ACC_SYNCHRONIZED 访问标志来辨别一个方法是否声明为同步方法，从而执行相应的同步调用。 - - -### 1.4 说说 JDK1.6 之后的synchronized 关键字底层做了哪些优化，可以详细介绍一下这些优化吗 - -JDK1.6 对锁的实现引入了大量的优化，如偏向锁、轻量级锁、自旋锁、适应性自旋锁、锁消除、锁粗化等技术来减少锁操作的开销。 - -锁主要存在四种状态，依次是：无锁状态、偏向锁状态、轻量级锁状态、重量级锁状态，他们会随着竞争的激烈而逐渐升级。注意锁可以升级不可降级，这种策略是为了提高获得锁和释放锁的效率。 - -关于这几种优化的详细信息可以查看：[synchronized 关键字使用、底层原理、JDK1.6 之后的底层优化以及 和ReenTrantLock 的对比](https://mp.weixin.qq.com/s?__biz=MzU4NDQ4MzU5OA==&mid=2247484539&idx=1&sn=3500cdcd5188bdc253fb19a1bfa805e6&chksm=fd98521acaefdb0c5167247a1fa903a1a53bb4e050b558da574f894f9feda5378ec9d0fa1ac7&token=1604028915&lang=zh_CN#rd) - -### 1.5 谈谈 synchronized和ReenTrantLock 的区别 - - -**① 两者都是可重入锁** - -两者都是可重入锁。“可重入锁”概念是：自己可以再次获取自己的内部锁。比如一个线程获得了某个对象的锁，此时这个对象锁还没有释放，当其再次想要获取这个对象的锁的时候还是可以获取的，如果不可锁重入的话，就会造成死锁。同一个线程每次获取锁，锁的计数器都自增1，所以要等到锁的计数器下降为0时才能释放锁。 - -**② synchronized 依赖于 JVM 而 ReenTrantLock 依赖于 API** - -synchronized 是依赖于 JVM 实现的，前面我们也讲到了 虚拟机团队在 JDK1.6 为 synchronized 关键字进行了很多优化，但是这些优化都是在虚拟机层面实现的，并没有直接暴露给我们。ReenTrantLock 是 JDK 层面实现的（也就是 API 层面，需要 lock() 和 unlock 方法配合 try/finally 语句块来完成），所以我们可以通过查看它的源代码，来看它是如何实现的。 - -**③ ReenTrantLock 比 synchronized 增加了一些高级功能** - -相比synchronized，ReenTrantLock增加了一些高级功能。主要来说主要有三点：**①等待可中断；②可实现公平锁；③可实现选择性通知（锁可以绑定多个条件）** - -- **ReenTrantLock提供了一种能够中断等待锁的线程的机制**，通过lock.lockInterruptibly()来实现这个机制。也就是说正在等待的线程可以选择放弃等待，改为处理其他事情。 -- **ReenTrantLock可以指定是公平锁还是非公平锁。而synchronized只能是非公平锁。所谓的公平锁就是先等待的线程先获得锁。** ReenTrantLock默认情况是非公平的，可以通过 ReenTrantLock类的`ReentrantLock(boolean fair)`构造方法来制定是否是公平的。 -- synchronized关键字与wait()和notify/notifyAll()方法相结合可以实现等待/通知机制，ReentrantLock类当然也可以实现，但是需要借助于Condition接口与newCondition() 方法。Condition是JDK1.5之后才有的，它具有很好的灵活性，比如可以实现多路通知功能也就是在一个Lock对象中可以创建多个Condition实例（即对象监视器），**线程对象可以注册在指定的Condition中，从而可以有选择性的进行线程通知，在调度线程上更加灵活。 在使用notify/notifyAll()方法进行通知时，被通知的线程是由 JVM 选择的，用ReentrantLock类结合Condition实例可以实现“选择性通知”** ，这个功能非常重要，而且是Condition接口默认提供的。而synchronized关键字就相当于整个Lock对象中只有一个Condition实例，所有的线程都注册在它一个身上。如果执行notifyAll()方法的话就会通知所有处于等待状态的线程这样会造成很大的效率问题，而Condition实例的signalAll()方法 只会唤醒注册在该Condition实例中的所有等待线程。 - -如果你想使用上述功能，那么选择ReenTrantLock是一个不错的选择。 - -**④ 性能已不是选择标准** - -# 二 面试中关于线程池的 4 连击 - -### 2.1 讲一下Java内存模型 - - -在 JDK1.2 之前，Java的内存模型实现总是从**主存**（即共享内存）读取变量，是不需要进行特别的注意的。而在当前的 Java 内存模型下，线程可以把变量保存**本地内存**（比如机器的寄存器）中，而不是直接在主存中进行读写。这就可能造成一个线程在主存中修改了一个变量的值，而另外一个线程还继续使用它在寄存器中的变量值的拷贝，造成**数据的不一致**。 - -![数据的不一致](https://user-gold-cdn.xitu.io/2018/10/30/166c46ede4423ba2?w=273&h=166&f=jpeg&s=7268) - -要解决这个问题，就需要把变量声明为 **volatile**，这就指示 JVM，这个变量是不稳定的，每次使用它都到主存中进行读取。 - -说白了， **volatile** 关键字的主要作用就是保证变量的可见性然后还有一个作用是防止指令重排序。 - -![volatile关键字的可见性](https://user-gold-cdn.xitu.io/2018/10/30/166c46ede4b9f501?w=474&h=238&f=jpeg&s=9942) - - -### 2.2 说说 synchronized 关键字和 volatile 关键字的区别 - - synchronized关键字和volatile关键字比较 - -- **volatile关键字**是线程同步的**轻量级实现**，所以**volatile性能肯定比synchronized关键字要好**。但是**volatile关键字只能用于变量而synchronized关键字可以修饰方法以及代码块**。synchronized关键字在JavaSE1.6之后进行了主要包括为了减少获得锁和释放锁带来的性能消耗而引入的偏向锁和轻量级锁以及其它各种优化之后执行效率有了显著提升，**实际开发中使用 synchronized 关键字的场景还是更多一些**。 -- **多线程访问volatile关键字不会发生阻塞，而synchronized关键字可能会发生阻塞** -- **volatile关键字能保证数据的可见性，但不能保证数据的原子性。synchronized关键字两者都能保证。** -- **volatile关键字主要用于解决变量在多个线程之间的可见性，而 synchronized关键字解决的是多个线程之间访问资源的同步性。** - - -# 三 面试中关于 线程池的 2 连击 - - -### 3.1 为什么要用线程池？ - -线程池提供了一种限制和管理资源（包括执行一个任务）。 每个线程池还维护一些基本统计信息，例如已完成任务的数量。 - -这里借用《Java并发编程的艺术》提到的来说一下使用线程池的好处： - -- **降低资源消耗。** 通过重复利用已创建的线程降低线程创建和销毁造成的消耗。 -- **提高响应速度。** 当任务到达时，任务可以不需要的等到线程创建就能立即执行。 -- **提高线程的可管理性。** 线程是稀缺资源，如果无限制的创建，不仅会消耗系统资源，还会降低系统的稳定性，使用线程池可以进行统一的分配，调优和监控。 - - -### 3.2 实现Runnable接口和Callable接口的区别 - -如果想让线程池执行任务的话需要实现的Runnable接口或Callable接口。 Runnable接口或Callable接口实现类都可以被ThreadPoolExecutor或ScheduledThreadPoolExecutor执行。两者的区别在于 Runnable 接口不会返回结果但是 Callable 接口可以返回结果。 - - **备注：** 工具类`Executors`可以实现`Runnable`对象和`Callable`对象之间的相互转换。（`Executors.callable（Runnable task）`或`Executors.callable（Runnable task，Object resule）`）。 - -### 3.3 执行execute()方法和submit()方法的区别是什么呢？ - - 1)**`execute()` 方法用于提交不需要返回值的任务，所以无法判断任务是否被线程池执行成功与否；** - - 2)**submit()方法用于提交需要返回值的任务。线程池会返回一个future类型的对象，通过这个future对象可以判断任务是否执行成功**，并且可以通过future的get()方法来获取返回值，get()方法会阻塞当前线程直到任务完成，而使用 `get（long timeout，TimeUnit unit）`方法则会阻塞当前线程一段时间后立即返回，这时候有可能任务没有执行完。 - - -### 3.4 如何创建线程池 - -《阿里巴巴Java开发手册》中强制线程池不允许使用 Executors 去创建，而是通过 ThreadPoolExecutor 的方式，这样的处理方式让写的同学更加明确线程池的运行规则，规避资源耗尽的风险 - -> Executors 返回线程池对象的弊端如下： -> -> - **FixedThreadPool 和 SingleThreadExecutor** ： 允许请求的队列长度为 Integer.MAX_VALUE,可能堆积大量的请求，从而导致OOM。 -> - **CachedThreadPool 和 ScheduledThreadPool** ： 允许创建的线程数量为 Integer.MAX_VALUE ，可能会创建大量线程，从而导致OOM。 - -**方式一：通过构造方法实现** -![通过构造方法实现](https://user-gold-cdn.xitu.io/2018/10/30/166c4a5baac923e9?w=925&h=158&f=jpeg&s=29190) -**方式二：通过Executor 框架的工具类Executors来实现** -我们可以创建三种类型的ThreadPoolExecutor： - -- **FixedThreadPool** ： 该方法返回一个固定线程数量的线程池。该线程池中的线程数量始终不变。当有一个新的任务提交时，线程池中若有空闲线程，则立即执行。若没有，则新的任务会被暂存在一个任务队列中，待有线程空闲时，便处理在任务队列中的任务。 -- **SingleThreadExecutor：** 方法返回一个只有一个线程的线程池。若多余一个任务被提交到该线程池，任务会被保存在一个任务队列中，待线程空闲，按先入先出的顺序执行队列中的任务。 -- **CachedThreadPool：** 该方法返回一个可根据实际情况调整线程数量的线程池。线程池的线程数量不确定，但若有空闲线程可以复用，则会优先使用可复用的线程。若所有线程均在工作，又有新的任务提交，则会创建新的线程处理任务。所有线程在当前任务执行完毕后，将返回线程池进行复用。 - -对应Executors工具类中的方法如图所示： -![通过Executor 框架的工具类Executors来实现](https://user-gold-cdn.xitu.io/2018/10/30/166c4a5baa9ca5e9?w=645&h=222&f=jpeg&s=31710) - - -# 四 面试中关于 Atomic 原子类的 4 连击 - -### 4.1 介绍一下Atomic 原子类 - -Atomic 翻译成中文是原子的意思。在化学上，我们知道原子是构成一般物质的最小单位，在化学反应中是不可分割的。在我们这里 Atomic 是指一个操作是不可中断的。即使是在多个线程一起执行的时候，一个操作一旦开始，就不会被其他线程干扰。 - -所以，所谓原子类说简单点就是具有原子/原子操作特征的类。 - - -并发包 `java.util.concurrent` 的原子类都存放在`java.util.concurrent.atomic`下,如下图所示。 - -![ JUC 原子类概览](https://user-gold-cdn.xitu.io/2018/10/30/166c4ac08d4c5547?w=317&h=367&f=png&s=13267) - -### 4.2 JUC 包中的原子类是哪4类? - -**基本类型** - -使用原子的方式更新基本类型 - -- AtomicInteger：整形原子类 -- AtomicLong：长整型原子类 -- AtomicBoolean ：布尔型原子类 - -**数组类型** - -使用原子的方式更新数组里的某个元素 - - -- AtomicIntegerArray：整形数组原子类 -- AtomicLongArray：长整形数组原子类 -- AtomicReferenceArray ：引用类型数组原子类 - -**引用类型** - -- AtomicReference：引用类型原子类 -- AtomicStampedRerence：原子更新引用类型里的字段原子类 -- AtomicMarkableReference ：原子更新带有标记位的引用类型 - -**对象的属性修改类型** - -- AtomicIntegerFieldUpdater:原子更新整形字段的更新器 -- AtomicLongFieldUpdater：原子更新长整形字段的更新器 -- AtomicStampedReference ：原子更新带有版本号的引用类型。该类将整数值与引用关联起来，可用于解决原子的更新数据和数据的版本号，可以解决使用 CAS 进行原子更新时可能出现的 ABA 问题。 - - -### 4.3 讲讲 AtomicInteger 的使用 - - **AtomicInteger 类常用方法** - -```java -public final int get() //获取当前的值 -public final int getAndSet(int newValue)//获取当前的值，并设置新的值 -public final int getAndIncrement()//获取当前的值，并自增 -public final int getAndDecrement() //获取当前的值，并自减 -public final int getAndAdd(int delta) //获取当前的值，并加上预期的值 -boolean compareAndSet(int expect, int update) //如果输入的数值等于预期值，则以原子方式将该值设置为输入值（update） -public final void lazySet(int newValue)//最终设置为newValue,使用 lazySet 设置之后可能导致其他线程在之后的一小段时间内还是可以读到旧的值。 -``` - - **AtomicInteger 类的使用示例** - -使用 AtomicInteger 之后，不用对 increment() 方法加锁也可以保证线程安全。 -```java -class AtomicIntegerTest { - private AtomicInteger count = new AtomicInteger(); - //使用AtomicInteger之后，不需要对该方法加锁，也可以实现线程安全。 - public void increment() { - count.incrementAndGet(); - } - - public int getCount() { - return count.get(); - } -} - -``` - -### 4.4 能不能给我简单介绍一下 AtomicInteger 类的原理 - -AtomicInteger 线程安全原理简单分析 - -AtomicInteger 类的部分源码： - -```java - // setup to use Unsafe.compareAndSwapInt for updates（更新操作时提供“比较并替换”的作用） - private static final Unsafe unsafe = Unsafe.getUnsafe(); - private static final long valueOffset; - - static { - try { - valueOffset = unsafe.objectFieldOffset - (AtomicInteger.class.getDeclaredField("value")); - } catch (Exception ex) { throw new Error(ex); } - } - - private volatile int value; -``` - -AtomicInteger 类主要利用 CAS (compare and swap) + volatile 和 native 方法来保证原子操作，从而避免 synchronized 的高开销，执行效率大为提升。 - -CAS的原理是拿期望的值和原本的一个值作比较，如果相同则更新成新的值。UnSafe 类的 objectFieldOffset() 方法是一个本地方法，这个方法是用来拿到“原来的值”的内存地址，返回值是 valueOffset。另外 value 是一个volatile变量，在内存中可见，因此 JVM 可以保证任何时刻任何线程总能拿到该变量的最新值。 - -关于 Atomic 原子类这部分更多内容可以查看我的这篇文章：并发编程面试必备：[JUC 中的 Atomic 原子类总结](https://mp.weixin.qq.com/s/joa-yOiTrYF67bElj8xqvg) - -# 五 AQS - -### 5.1 AQS 介绍 - -AQS的全称为（AbstractQueuedSynchronizer），这个类在java.util.concurrent.locks包下面。 - -![enter image description here](https://user-gold-cdn.xitu.io/2018/10/30/166c4bb575d4a690?w=317&h=338&f=png&s=14122) - -AQS是一个用来构建锁和同步器的框架，使用AQS能简单且高效地构造出应用广泛的大量的同步器，比如我们提到的ReentrantLock，Semaphore，其他的诸如ReentrantReadWriteLock，SynchronousQueue，FutureTask等等皆是基于AQS的。当然，我们自己也能利用AQS非常轻松容易地构造出符合我们自己需求的同步器。 - -### 5.2 AQS 原理分析 - -AQS 原理这部分参考了部分博客，在5.2节末尾放了链接。 - -> 在面试中被问到并发知识的时候，大多都会被问到“请你说一下自己对于AQS原理的理解”。下面给大家一个示例供大家参加，面试不是背题，大家一定要假如自己的思想，即使加入不了自己的思想也要保证自己能够通俗的讲出来而不是背出来。 - -下面大部分内容其实在AQS类注释上已经给出了，不过是英语看着比较吃力一点，感兴趣的话可以看看源码。 - -#### 5.2.1 AQS 原理概览 - - - -**AQS核心思想是，如果被请求的共享资源空闲，则将当前请求资源的线程设置为有效的工作线程，并且将共享资源设置为锁定状态。如果被请求的共享资源被占用，那么就需要一套线程阻塞等待以及被唤醒时锁分配的机制，这个机制AQS是用CLH队列锁实现的，即将暂时获取不到锁的线程加入到队列中。** - -> CLH(Craig,Landin,and Hagersten)队列是一个虚拟的双向队列（虚拟的双向队列即不存在队列实例，仅存在结点之间的关联关系）。AQS是将每条请求共享资源的线程封装成一个CLH锁队列的一个结点（Node）来实现锁的分配。 - -看个AQS(AbstractQueuedSynchronizer)原理图： - - -![enter image description here](https://user-gold-cdn.xitu.io/2018/10/30/166c4bbe4a9c5ae7?w=852&h=401&f=png&s=21797) - -AQS使用一个int成员变量来表示同步状态，通过内置的FIFO队列来完成获取资源线程的排队工作。AQS使用CAS对该同步状态进行原子操作实现对其值的修改。 - -```java -private volatile int state;//共享变量，使用volatile修饰保证线程可见性 -``` - -状态信息通过procted类型的getState，setState，compareAndSetState进行操作 - -```java - -//返回同步状态的当前值 -protected final int getState() { - return state; -} - // 设置同步状态的值 -protected final void setState(int newState) { - state = newState; -} -//原子地（CAS操作）将同步状态值设置为给定值update如果当前同步状态的值等于expect（期望值） -protected final boolean compareAndSetState(int expect, int update) { - return unsafe.compareAndSwapInt(this, stateOffset, expect, update); -} -``` - -#### 5.2.2 AQS 对资源的共享方式 - -**AQS定义两种资源共享方式** - -- **Exclusive**（独占）：只有一个线程能执行，如ReentrantLock。又可分为公平锁和非公平锁： - - 公平锁：按照线程在队列中的排队顺序，先到者先拿到锁 - - 非公平锁：当线程要获取锁时，无视队列顺序直接去抢锁，谁抢到就是谁的 -- **Share**（共享）：多个线程可同时执行，如Semaphore/CountDownLatch。Semaphore、CountDownLatCh、 CyclicBarrier、ReadWriteLock 我们都会在后面讲到。 - -ReentrantReadWriteLock 可以看成是组合式，因为ReentrantReadWriteLock也就是读写锁允许多个线程同时对某一资源进行读。 - -不同的自定义同步器争用共享资源的方式也不同。自定义同步器在实现时只需要实现共享资源 state 的获取与释放方式即可，至于具体线程等待队列的维护（如获取资源失败入队/唤醒出队等），AQS已经在顶层实现好了。 - -#### 5.2.3 AQS底层使用了模板方法模式 - -同步器的设计是基于模板方法模式的，如果需要自定义同步器一般的方式是这样（模板方法模式很经典的一个应用）： - -1. 使用者继承AbstractQueuedSynchronizer并重写指定的方法。（这些重写方法很简单，无非是对于共享资源state的获取和释放） -2. 将AQS组合在自定义同步组件的实现中，并调用其模板方法，而这些模板方法会调用使用者重写的方法。 - -这和我们以往通过实现接口的方式有很大区别，这是模板方法模式很经典的一个运用。 - -**AQS使用了模板方法模式，自定义同步器时需要重写下面几个AQS提供的模板方法：** - -```java -isHeldExclusively()//该线程是否正在独占资源。只有用到condition才需要去实现它。 -tryAcquire(int)//独占方式。尝试获取资源，成功则返回true，失败则返回false。 -tryRelease(int)//独占方式。尝试释放资源，成功则返回true，失败则返回false。 -tryAcquireShared(int)//共享方式。尝试获取资源。负数表示失败；0表示成功，但没有剩余可用资源；正数表示成功，且有剩余资源。 -tryReleaseShared(int)//共享方式。尝试释放资源，成功则返回true，失败则返回false。 - -``` - -默认情况下，每个方法都抛出 `UnsupportedOperationException`。 这些方法的实现必须是内部线程安全的，并且通常应该简短而不是阻塞。AQS类中的其他方法都是final ，所以无法被其他类使用，只有这几个方法可以被其他类使用。 - -以ReentrantLock为例，state初始化为0，表示未锁定状态。A线程lock()时，会调用tryAcquire()独占该锁并将state+1。此后，其他线程再tryAcquire()时就会失败，直到A线程unlock()到state=0（即释放锁）为止，其它线程才有机会获取该锁。当然，释放锁之前，A线程自己是可以重复获取此锁的（state会累加），这就是可重入的概念。但要注意，获取多少次就要释放多么次，这样才能保证state是能回到零态的。 - -再以CountDownLatch以例，任务分为N个子线程去执行，state也初始化为N（注意N要与线程个数一致）。这N个子线程是并行执行的，每个子线程执行完后countDown()一次，state会CAS(Compare and Swap)减1。等到所有子线程都执行完后(即state=0)，会unpark()主调用线程，然后主调用线程就会从await()函数返回，继续后余动作。 - -一般来说，自定义同步器要么是独占方法，要么是共享方式，他们也只需实现`tryAcquire-tryRelease`、`tryAcquireShared-tryReleaseShared`中的一种即可。但AQS也支持自定义同步器同时实现独占和共享两种方式，如`ReentrantReadWriteLock`。 - -推荐两篇 AQS 原理和相关源码分析的文章： - -- http://www.cnblogs.com/waterystone/p/4920797.html -- https://www.cnblogs.com/chengxiao/archive/2017/07/24/7141160.html - -### 5.3 AQS 组件总结 - -- **Semaphore(信号量)-允许多个线程同时访问：** synchronized 和 ReentrantLock 都是一次只允许一个线程访问某个资源，Semaphore(信号量)可以指定多个线程同时访问某个资源。 -- **CountDownLatch （倒计时器）：** CountDownLatch是一个同步工具类，用来协调多个线程之间的同步。这个工具通常用来控制线程等待，它可以让某一个线程等待直到倒计时结束，再开始执行。 -- **CyclicBarrier(循环栅栏)：** CyclicBarrier 和 CountDownLatch 非常类似，它也可以实现线程间的技术等待，但是它的功能比 CountDownLatch 更加复杂和强大。主要应用场景和 CountDownLatch 类似。CyclicBarrier 的字面意思是可循环使用（Cyclic）的屏障（Barrier）。它要做的事情是，让一组线程到达一个屏障（也可以叫同步点）时被阻塞，直到最后一个线程到达屏障时，屏障才会开门，所有被屏障拦截的线程才会继续干活。CyclicBarrier默认的构造方法是 CyclicBarrier(int parties)，其参数表示屏障拦截的线程数量，每个线程调用await方法告诉 CyclicBarrier 我已经到达了屏障，然后当前线程被阻塞。 - -关于AQS这部分的更多内容可以查看我的这篇文章:[并发编程面试必备：AQS 原理以及 AQS 同步组件总结](https://mp.weixin.qq.com/s/joa-yOiTrYF67bElj8xqvg) - -# Reference - -- 《深入理解 Java 虚拟机》 -- 《实战 Java 高并发程序设计》 -- 《Java并发编程的艺术》 -- http://www.cnblogs.com/waterystone/p/4920797.html -- https://www.cnblogs.com/chengxiao/archive/2017/07/24/7141160.html diff --git "a/Java\347\233\270\345\205\263/synchronized.md" "b/Java\347\233\270\345\205\263/synchronized.md" deleted file mode 100644 index b0b0700ad8edcd429b3e8c631566670beeb85331..0000000000000000000000000000000000000000 --- "a/Java\347\233\270\345\205\263/synchronized.md" +++ /dev/null @@ -1,171 +0,0 @@ -以下内容摘自我的 Gitchat ：[Java 程序员必备：并发知识系统总结](https://gitbook.cn/gitchat/activity/5bc2b6af56f0425673d299bb)，欢迎订阅！ - -Github 地址：[https://github.com/Snailclimb/JavaGuide/edit/master/Java相关/synchronized.md](https://github.com/Snailclimb/JavaGuide/edit/master/Java相关/synchronized.md) - -![Synchronized 关键字使用、底层原理、JDK1.6 之后的底层优化以及 和ReenTrantLock 的对比](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/Java%20%E7%A8%8B%E5%BA%8F%E5%91%98%E5%BF%85%E5%A4%87%EF%BC%9A%E5%B9%B6%E5%8F%91%E7%9F%A5%E8%AF%86%E7%B3%BB%E7%BB%9F%E6%80%BB%E7%BB%93/%E4%BA%8C%20%20Synchronized%20%E5%85%B3%E9%94%AE%E5%AD%97%E4%BD%BF%E7%94%A8%E3%80%81%E5%BA%95%E5%B1%82%E5%8E%9F%E7%90%86%E3%80%81JDK1.6%20%E4%B9%8B%E5%90%8E%E7%9A%84%E5%BA%95%E5%B1%82%E4%BC%98%E5%8C%96%E4%BB%A5%E5%8F%8A%20%E5%92%8CReenTrantLock%20%E7%9A%84%E5%AF%B9%E6%AF%94.png) - -### synchronized关键字最主要的三种使用方式的总结 - -- **修饰实例方法，作用于当前对象实例加锁，进入同步代码前要获得当前对象实例的锁** -- **修饰静态方法，作用于当前类对象加锁，进入同步代码前要获得当前类对象的锁** 。也就是给当前类加锁，会作用于类的所有对象实例，因为静态成员不属于任何一个实例对象，是类成员（ static 表明这是该类的一个静态资源，不管new了多少个对象，只有一份，所以对该类的所有对象都加了锁）。所以如果一个线程A调用一个实例对象的非静态 synchronized 方法，而线程B需要调用这个实例对象所属类的静态 synchronized 方法，是允许的，不会发生互斥现象，**因为访问静态 synchronized 方法占用的锁是当前类的锁，而访问非静态 synchronized 方法占用的锁是当前实例对象锁**。 -- **修饰代码块，指定加锁对象，对给定对象加锁，进入同步代码库前要获得给定对象的锁。** 和 synchronized 方法一样，synchronized(this)代码块也是锁定当前对象的。synchronized 关键字加到 static 静态方法和 synchronized(class)代码块上都是是给 Class 类上锁。这里再提一下：synchronized关键字加到非 static 静态方法上是给对象实例上锁。另外需要注意的是：尽量不要使用 synchronized(String a) 因为JVM中，字符串常量池具有缓冲功能！ - -下面我已一个常见的面试题为例讲解一下 synchronized 关键字的具体使用。 - -面试中面试官经常会说：“单例模式了解吗？来给我手写一下！给我解释一下双重检验锁方式实现单利模式的原理呗！” - - - -**双重校验锁实现对象单例（线程安全）** - -```java -public class Singleton { - - private volatile static Singleton uniqueInstance; - - private Singleton() { - } - - public static Singleton getUniqueInstance() { - //先判断对象是否已经实例过，没有实例化过才进入加锁代码 - if (uniqueInstance == null) { - //类对象加锁 - synchronized (Singleton.class) { - if (uniqueInstance == null) { - uniqueInstance = new Singleton(); - } - } - } - return uniqueInstance; - } -} -``` -另外，需要注意 uniqueInstance 采用 volatile 关键字修饰也是很有必要。 - -uniqueInstance 采用 volatile 关键字修饰也是很有必要的， uniqueInstance = new Singleton(); 这段代码其实是分为三步执行： - -1. 为 uniqueInstance 分配内存空间 -2. 初始化 uniqueInstance -3. 将 uniqueInstance 指向分配的内存地址 - -但是由于 JVM 具有指令重排的特性，执行顺序有可能变成 1->3->2。指令重排在单线程环境下不会出先问题，但是在多线程环境下会导致一个线程获得还没有初始化的实例。例如，线程 T1 执行了 1 和 3，此时 T2 调用 getUniqueInstance() 后发现 uniqueInstance 不为空，因此返回 uniqueInstance，但此时 uniqueInstance 还未被初始化。 - -使用 volatile 可以禁止 JVM 的指令重排，保证在多线程环境下也能正常运行。 - - -###synchronized 关键字底层原理总结 - - - -**synchronized 关键字底层原理属于 JVM 层面。** - -**① synchronized 同步语句块的情况** - -```java -public class SynchronizedDemo { - public void method() { - synchronized (this) { - System.out.println("synchronized 代码块"); - } - } -} - -``` - -通过 JDK 自带的 javap 命令查看 SynchronizedDemo 类的相关字节码信息：首先切换到类的对应目录执行 `javac SynchronizedDemo.java` 命令生成编译后的 .class 文件，然后执行`javap -c -s -v -l SynchronizedDemo.class`。 - -![synchronized 关键字原理](https://images.gitbook.cn/abc37c80-d21d-11e8-aab3-09d30029e0d5) - -从上面我们可以看出： - -**synchronized 同步语句块的实现使用的是 monitorenter 和 monitorexit 指令，其中 monitorenter 指令指向同步代码块的开始位置，monitorexit 指令则指明同步代码块的结束位置。** 当执行 monitorenter 指令时，线程试图获取锁也就是获取 monitor(monitor对象存在于每个Java对象的对象头中，synchronized 锁便是通过这种方式获取锁的，也是为什么Java中任意对象可以作为锁的原因) 的持有权.当计数器为0则可以成功获取，获取后将锁计数器设为1也就是加1。相应的在执行 monitorexit 指令后，将锁计数器设为0，表明锁被释放。如果获取对象锁失败，那当前线程就要阻塞等待，直到锁被另外一个线程释放为止。 - -**② synchronized 修饰方法的的情况** - -```java -public class SynchronizedDemo2 { - public synchronized void method() { - System.out.println("synchronized 方法"); - } -} - -``` - -![synchronized 关键字原理](https://images.gitbook.cn/7d407bf0-d21e-11e8-b2d6-1188c7e0dd7e) - -synchronized 修饰的方法并没有 monitorenter 指令和 monitorexit 指令，取得代之的确实是 ACC_SYNCHRONIZED 标识，该标识指明了该方法是一个同步方法，JVM 通过该 ACC_SYNCHRONIZED 访问标志来辨别一个方法是否声明为同步方法，从而执行相应的同步调用。 - - -在 Java 早期版本中，synchronized 属于重量级锁，效率低下，因为监视器锁（monitor）是依赖于底层的操作系统的 Mutex Lock 来实现的，Java 的线程是映射到操作系统的原生线程之上的。如果要挂起或者唤醒一个线程，都需要操作系统帮忙完成，而操作系统实现线程之间的切换时需要从用户态转换到内核态，这个状态之间的转换需要相对比较长的时间，时间成本相对较高，这也是为什么早期的 synchronized 效率低的原因。庆幸的是在 Java 6 之后 Java 官方对从 JVM 层面对synchronized 较大优化，所以现在的 synchronized 锁效率也优化得很不错了。JDK1.6对锁的实现引入了大量的优化，如自旋锁、适应性自旋锁、锁消除、锁粗化、偏向锁、轻量级锁等技术来减少锁操作的开销。 - - -### JDK1.6 之后的底层优化 - -JDK1.6 对锁的实现引入了大量的优化，如偏向锁、轻量级锁、自旋锁、适应性自旋锁、锁消除、锁粗化等技术来减少锁操作的开销。 - -锁主要存在四中状态，依次是：无锁状态、偏向锁状态、轻量级锁状态、重量级锁状态，他们会随着竞争的激烈而逐渐升级。注意锁可以升级不可降级，这种策略是为了提高获得锁和释放锁的效率。 - -**①偏向锁** - -**引入偏向锁的目的和引入轻量级锁的目的很像，他们都是为了没有多线程竞争的前提下，减少传统的重量级锁使用操作系统互斥量产生的性能消耗。但是不同是：轻量级锁在无竞争的情况下使用 CAS 操作去代替使用互斥量。而偏向锁在无竞争的情况下会把整个同步都消除掉**。 - -偏向锁的“偏”就是偏心的偏，它的意思是会偏向于第一个获得它的线程，如果在接下来的执行中，该锁没有被其他线程获取，那么持有偏向锁的线程就不需要进行同步！关于偏向锁的原理可以查看《深入理解Java虚拟机：JVM高级特性与最佳实践》第二版的13章第三节锁优化。 - -但是对于锁竞争比较激烈的场合，偏向锁就失效了，因为这样场合极有可能每次申请锁的线程都是不相同的，因此这种场合下不应该使用偏向锁，否则会得不偿失，需要注意的是，偏向锁失败后，并不会立即膨胀为重量级锁，而是先升级为轻量级锁。 - -**② 轻量级锁** - -倘若偏向锁失败，虚拟机并不会立即升级为重量级锁，它还会尝试使用一种称为轻量级锁的优化手段(1.6之后加入的)。**轻量级锁不是为了代替重量级锁，它的本意是在没有多线程竞争的前提下，减少传统的重量级锁使用操作系统互斥量产生的性能消耗，因为使用轻量级锁时，不需要申请互斥量。另外，轻量级锁的加锁和解锁都用到了CAS操作。** 关于轻量级锁的加锁和解锁的原理可以查看《深入理解Java虚拟机：JVM高级特性与最佳实践》第二版的13章第三节锁优化。 - -**轻量级锁能够提升程序同步性能的依据是“对于绝大部分锁，在整个同步周期内都是不存在竞争的”，这是一个经验数据。如果没有竞争，轻量级锁使用 CAS 操作避免了使用互斥操作的开销。但如果存在锁竞争，除了互斥量开销外，还会额外发生CAS操作，因此在有锁竞争的情况下，轻量级锁比传统的重量级锁更慢！如果锁竞争激烈，那么轻量级将很快膨胀为重量级锁！** - -**③ 自旋锁和自适应自旋** - -轻量级锁失败后，虚拟机为了避免线程真实地在操作系统层面挂起，还会进行一项称为自旋锁的优化手段。 - -互斥同步对性能最大的影响就是阻塞的实现，因为挂起线程/恢复线程的操作都需要转入内核态中完成（用户态转换到内核态会耗费时间）。 - -**一般线程持有锁的时间都不是太长，所以仅仅为了这一点时间去挂起线程/恢复线程是得不偿失的。** 所以，虚拟机的开发团队就这样去考虑：“我们能不能让后面来的请求获取锁的线程等待一会而不被挂起呢？看看持有锁的线程是否很快就会释放锁”。**为了让一个线程等待，我们只需要让线程执行一个忙循环（自旋），这项技术就叫做自旋**。 - -百度百科对自旋锁的解释： - -> 何谓自旋锁？它是为实现保护共享资源而提出一种锁机制。其实，自旋锁与互斥锁比较类似，它们都是为了解决对某项资源的互斥使用。无论是互斥锁，还是自旋锁，在任何时刻，最多只能有一个保持者，也就说，在任何时刻最多只能有一个执行单元获得锁。但是两者在调度机制上略有不同。对于互斥锁，如果资源已经被占用，资源申请者只能进入睡眠状态。但是自旋锁不会引起调用者睡眠，如果自旋锁已经被别的执行单元保持，调用者就一直循环在那里看是否该自旋锁的保持者已经释放了锁，"自旋"一词就是因此而得名。 - -自旋锁在 JDK1.6 之前其实就已经引入了，不过是默认关闭的，需要通过`--XX:+UseSpinning`参数来开启。JDK1.6及1.6之后，就改为默认开启的了。需要注意的是：自旋等待不能完全替代阻塞，因为它还是要占用处理器时间。如果锁被占用的时间短，那么效果当然就很好了！反之，相反！自旋等待的时间必须要有限度。如果自旋超过了限定次数任然没有获得锁，就应该挂起线程。**自旋次数的默认值是10次，用户可以修改`--XX:PreBlockSpin`来更改**。 - -另外,**在 JDK1.6 中引入了自适应的自旋锁。自适应的自旋锁带来的改进就是：自旋的时间不在固定了，而是和前一次同一个锁上的自旋时间以及锁的拥有者的状态来决定，虚拟机变得越来越“聪明”了**。 - -**④ 锁消除** - -锁消除理解起来很简单，它指的就是虚拟机即使编译器在运行时，如果检测到那些共享数据不可能存在竞争，那么就执行锁消除。锁消除可以节省毫无意义的请求锁的时间。 - -**⑤ 锁粗化** - -原则上，我们再编写代码的时候，总是推荐将同步快的作用范围限制得尽量小——只在共享数据的实际作用域才进行同步，这样是为了使得需要同步的操作数量尽可能变小，如果存在锁竞争，那等待线程也能尽快拿到锁。 - -大部分情况下，上面的原则都是没有问题的，但是如果一系列的连续操作都对同一个对象反复加锁和解锁，那么会带来很多不必要的性能消耗。 - -### Synchronized 和 ReenTrantLock 的对比 - - -**① 两者都是可重入锁** - -两者都是可重入锁。“可重入锁”概念是：自己可以再次获取自己的内部锁。比如一个线程获得了某个对象的锁，此时这个对象锁还没有释放，当其再次想要获取这个对象的锁的时候还是可以获取的，如果不可锁重入的话，就会造成死锁。同一个线程每次获取锁，锁的计数器都自增1，所以要等到锁的计数器下降为0时才能释放锁。 - -**② synchronized 依赖于 JVM 而 ReenTrantLock 依赖于 API** - -synchronized 是依赖于 JVM 实现的，前面我们也讲到了 虚拟机团队在 JDK1.6 为 synchronized 关键字进行了很多优化，但是这些优化都是在虚拟机层面实现的，并没有直接暴露给我们。ReenTrantLock 是 JDK 层面实现的（也就是 API 层面，需要 lock() 和 unlock 方法配合 try/finally 语句块来完成），所以我们可以通过查看它的源代码，来看它是如何实现的。 - -**③ ReenTrantLock 比 synchronized 增加了一些高级功能** - -相比synchronized，ReenTrantLock增加了一些高级功能。主要来说主要有三点：**①等待可中断；②可实现公平锁；③可实现选择性通知（锁可以绑定多个条件）** - -- **ReenTrantLock提供了一种能够中断等待锁的线程的机制**，通过lock.lockInterruptibly()来实现这个机制。也就是说正在等待的线程可以选择放弃等待，改为处理其他事情。 -- **ReenTrantLock可以指定是公平锁还是非公平锁。而synchronized只能是非公平锁。所谓的公平锁就是先等待的线程先获得锁。** ReenTrantLock默认情况是非公平的，可以通过 ReenTrantLock类的`ReentrantLock(boolean fair)`构造方法来制定是否是公平的。 -- synchronized关键字与wait()和notify/notifyAll()方法相结合可以实现等待/通知机制，ReentrantLock类当然也可以实现，但是需要借助于Condition接口与newCondition() 方法。Condition是JDK1.5之后才有的，它具有很好的灵活性，比如可以实现多路通知功能也就是在一个Lock对象中可以创建多个Condition实例（即对象监视器），**线程对象可以注册在指定的Condition中，从而可以有选择性的进行线程通知，在调度线程上更加灵活。 在使用notify/notifyAll()方法进行通知时，被通知的线程是由 JVM 选择的，用ReentrantLock类结合Condition实例可以实现“选择性通知”** ，这个功能非常重要，而且是Condition接口默认提供的。而synchronized关键字就相当于整个Lock对象中只有一个Condition实例，所有的线程都注册在它一个身上。如果执行notifyAll()方法的话就会通知所有处于等待状态的线程这样会造成很大的效率问题，而Condition实例的signalAll()方法 只会唤醒注册在该Condition实例中的所有等待线程。 - -如果你想使用上述功能，那么选择ReenTrantLock是一个不错的选择。 - -**④ 性能已不是选择标准** - -在JDK1.6之前，synchronized 的性能是比 ReenTrantLock 差很多。具体表示为：synchronized 关键字吞吐量随线程数的增加，下降得非常严重。而ReenTrantLock 基本保持一个比较稳定的水平。我觉得这也侧面反映了， synchronized 关键字还有非常大的优化余地。后续的技术发展也证明了这一点，我们上面也讲了在 JDK1.6 之后 JVM 团队对 synchronized 关键字做了很多优化。**JDK1.6 之后，synchronized 和 ReenTrantLock 的性能基本是持平了。所以网上那些说因为性能才选择 ReenTrantLock 的文章都是错的！JDK1.6之后，性能已经不是选择synchronized和ReenTrantLock的影响因素了！而且虚拟机在未来的性能改进中会更偏向于原生的synchronized，所以还是提倡在synchronized能满足你的需求的情况下，优先考虑使用synchronized关键字来进行同步！优化后的synchronized和ReenTrantLock一样，在很多地方都是用到了CAS操作**。 diff --git "a/Java\347\233\270\345\205\263/\345\217\257\350\203\275\346\230\257\346\212\212Java\345\206\205\345\255\230\345\214\272\345\237\237\350\256\262\347\232\204\346\234\200\346\270\205\346\245\232\347\232\204\344\270\200\347\257\207\346\226\207\347\253\240.md" "b/Java\347\233\270\345\205\263/\345\217\257\350\203\275\346\230\257\346\212\212Java\345\206\205\345\255\230\345\214\272\345\237\237\350\256\262\347\232\204\346\234\200\346\270\205\346\245\232\347\232\204\344\270\200\347\257\207\346\226\207\347\253\240.md" deleted file mode 100644 index 61d5e7221740c5b0b22b70331cf88714c2df359e..0000000000000000000000000000000000000000 --- "a/Java\347\233\270\345\205\263/\345\217\257\350\203\275\346\230\257\346\212\212Java\345\206\205\345\255\230\345\214\272\345\237\237\350\256\262\347\232\204\346\234\200\346\270\205\346\245\232\347\232\204\344\270\200\347\257\207\346\226\207\347\253\240.md" +++ /dev/null @@ -1,342 +0,0 @@ - - -## 写在前面（常见面试题） - -### 基本问题： - -- **介绍下 Java 内存区域（运行时数据区）** -- **Java 对象的创建过程（五步，建议能默写出来并且要知道每一步虚拟机做了什么）** -- **对象的访问定位的两种方式（句柄和直接指针两种方式）** - -### 拓展问题: - -- **String类和常量池** -- **8种基本类型的包装类和常量池** - - -## 1 概述 - -对于 Java 程序员来说，在虚拟机自动内存管理机制下，不再需要像C/C++程序开发程序员这样为内一个 new 操作去写对应的 delete/free 操作，不容易出现内存泄漏和内存溢出问题。正是因为 Java 程序员把内存控制权利交给 Java 虚拟机，一旦出现内存泄漏和溢出方面的问题，如果不了解虚拟机是怎样使用内存的，那么排查错误将会是一个非常艰巨的任务。 - - -## 2 运行时数据区域 -Java 虚拟机在执行 Java 程序的过程中会把它管理的内存划分成若干个不同的数据区域。 -![](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/2019-3/JVM运行时数据区域.png) - -这些组成部分一些是线程私有的，其他的则是线程共享的。 - -**线程私有的：** - -- 程序计数器 -- 虚拟机栈 -- 本地方法栈 - -**线程共享的：** - -- 堆 -- 方法区 -- 直接内存 - - -### 2.1 程序计数器 -程序计数器是一块较小的内存空间，可以看作是当前线程所执行的字节码的行号指示器。**字节码解释器工作时通过改变这个计数器的值来选取下一条需要执行的字节码指令，分支、循环、跳转、异常处理、线程恢复等功能都需要依赖这个计数器来完。** - -另外，**为了线程切换后能恢复到正确的执行位置，每条线程都需要有一个独立的程序计数器，各线程之间计数器互不影响，独立存储，我们称这类内存区域为“线程私有”的内存。** - -**从上面的介绍中我们知道程序计数器主要有两个作用：** - -1. 字节码解释器通过改变程序计数器来依次读取指令，从而实现代码的流程控制，如：顺序执行、选择、循环、异常处理。 -2. 在多线程的情况下，程序计数器用于记录当前线程执行的位置，从而当线程被切换回来的时候能够知道该线程上次运行到哪儿了。 - -**注意：程序计数器是唯一一个不会出现OutOfMemoryError的内存区域，它的生命周期随着线程的创建而创建，随着线程的结束而死亡。** - -### 2.2 Java 虚拟机栈 - -**与程序计数器一样，Java虚拟机栈也是线程私有的，它的生命周期和线程相同，描述的是 Java 方法执行的内存模型。** - -**Java 内存可以粗糙的区分为堆内存（Heap）和栈内存(Stack),其中栈就是现在说的虚拟机栈，或者说是虚拟机栈中局部变量表部分。** （实际上，Java虚拟机栈是由一个个栈帧组成，而每个栈帧中都拥有：局部变量表、操作数栈、动态链接、方法出口信息。） - -**局部变量表主要存放了编译器可知的各种数据类型**（boolean、byte、char、short、int、float、long、double）、**对象引用**（reference类型，它不同于对象本身，可能是一个指向对象起始地址的引用指针，也可能是指向一个代表对象的句柄或其他与此对象相关的位置）。 - -**Java 虚拟机栈会出现两种异常：StackOverFlowError 和 OutOfMemoryError。** - -- **StackOverFlowError：** 若Java虚拟机栈的内存大小不允许动态扩展，那么当线程请求栈的深度超过当前Java虚拟机栈的最大深度的时候，就抛出StackOverFlowError异常。 -- **OutOfMemoryError：** 若 Java 虚拟机栈的内存大小允许动态扩展，且当线程请求栈时内存用完了，无法再动态扩展了，此时抛出OutOfMemoryError异常。 - -Java 虚拟机栈也是线程私有的，每个线程都有各自的Java虚拟机栈，而且随着线程的创建而创建，随着线程的死亡而死亡。 - -### 2.3 本地方法栈 - -和虚拟机栈所发挥的作用非常相似，区别是： **虚拟机栈为虚拟机执行 Java 方法 （也就是字节码）服务，而本地方法栈则为虚拟机使用到的 Native 方法服务。** 在 HotSpot 虚拟机中和 Java 虚拟机栈合二为一。 - -本地方法被执行的时候，在本地方法栈也会创建一个栈帧，用于存放该本地方法的局部变量表、操作数栈、动态链接、出口信息。 - -方法执行完毕后相应的栈帧也会出栈并释放内存空间，也会出现 StackOverFlowError 和 OutOfMemoryError 两种异常。 - -### 2.4 堆 -Java 虚拟机所管理的内存中最大的一块，Java 堆是所有线程共享的一块内存区域，在虚拟机启动时创建。**此内存区域的唯一目的就是存放对象实例，几乎所有的对象实例以及数组都在这里分配内存。** - -Java 堆是垃圾收集器管理的主要区域，因此也被称作**GC堆（Garbage Collected Heap）**.从垃圾回收的角度，由于现在收集器基本都采用分代垃圾收集算法，所以Java堆还可以细分为：新生代和老年代：再细致一点有：Eden空间、From Survivor、To Survivor空间等。**进一步划分的目的是更好地回收内存，或者更快地分配内存。** - -![](https://user-gold-cdn.xitu.io/2018/8/25/16570344a29c3433?w=599&h=250&f=png&s=8946) - -**在 JDK 1.8中移除整个永久代，取而代之的是一个叫元空间（Metaspace）的区域（永久代使用的是JVM的堆内存空间，而元空间使用的是物理内存，直接受到本机的物理内存限制）。** - -推荐阅读： - -- 《Java8内存模型—永久代(PermGen)和元空间(Metaspace)》：[http://www.cnblogs.com/paddix/p/5309550.html](http://www.cnblogs.com/paddix/p/5309550.html) - -### 2.5 方法区 - -**方法区与 Java 堆一样，是各个线程共享的内存区域，它用于存储已被虚拟机加载的类信息、常量、静态变量、即时编译器编译后的代码等数据。虽然Java虚拟机规范把方法区描述为堆的一个逻辑部分，但是它却有一个别名叫做 Non-Heap（非堆），目的应该是与 Java 堆区分开来。** - -HotSpot 虚拟机中方法区也常被称为 **“永久代”**，本质上两者并不等价。仅仅是因为 HotSpot 虚拟机设计团队用永久代来实现方法区而已，这样 HotSpot 虚拟机的垃圾收集器就可以像管理 Java 堆一样管理这部分内存了。但是这并不是一个好主意，因为这样更容易遇到内存溢出问题。 - - - -**相对而言，垃圾收集行为在这个区域是比较少出现的，但并非数据进入方法区后就“永久存在”了。** - -### 2.6 运行时常量池 - -运行时常量池是方法区的一部分。Class 文件中除了有类的版本、字段、方法、接口等描述信息外，还有常量池信息（用于存放编译期生成的各种字面量和符号引用） - -既然运行时常量池时方法区的一部分，自然受到方法区内存的限制，当常量池无法再申请到内存时会抛出 OutOfMemoryError 异常。 - -**JDK1.7及之后版本的 JVM 已经将运行时常量池从方法区中移了出来，在 Java 堆（Heap）中开辟了一块区域存放运行时常量池。** - -![](http://my-blog-to-use.oss-cn-beijing.aliyuncs.com/18-9-14/26038433.jpg) -——图片来源：https://blog.csdn.net/wangbiao007/article/details/78545189 - - - -推荐阅读： - -- 《Java 中几种常量池的区分》： [https://blog.csdn.net/qq_26222859/article/details/73135660](https://blog.csdn.net/qq_26222859/article/details/73135660) - - -### 2.7 直接内存 - -直接内存并不是虚拟机运行时数据区的一部分，也不是虚拟机规范中定义的内存区域，但是这部分内存也被频繁地使用。而且也可能导致 OutOfMemoryError 异常出现。 - -JDK1.4中新加入的 **NIO(New Input/Output) 类**，引入了一种基于**通道（Channel）** 与**缓存区（Buffer）** 的 I/O 方式，它可以直接使用Native函数库直接分配堆外内存，然后通过一个存储在 Java 堆中的 DirectByteBuffer 对象作为这块内存的引用进行操作。这样就能在一些场景中显著提高性能，因为**避免了在 Java 堆和 Native 堆之间来回复制数据**。 - -本机直接内存的分配不会收到 Java 堆的限制，但是，既然是内存就会受到本机总内存大小以及处理器寻址空间的限制。 - - -## 3 HotSpot 虚拟机对象探秘 -通过上面的介绍我们大概知道了虚拟机的内存情况，下面我们来详细的了解一下 HotSpot 虚拟机在 Java 堆中对象分配、布局和访问的全过程。 - -### 3.1 对象的创建 -下图便是 Java 对象的创建过程，我建议最好是能默写出来，并且要掌握每一步在做什么。 -![Java对象的创建过程](https://user-gold-cdn.xitu.io/2018/8/22/16561e59a4135869?w=950&h=279&f=png&s=28529) - -**①类加载检查：** 虚拟机遇到一条 new 指令时，首先将去检查这个指令的参数是否能在常量池中定位到这个类的符号引用，并且检查这个符号引用代表的类是否已被加载过、解析和初始化过。如果没有，那必须先执行相应的类加载过程。 - -**②分配内存：** 在**类加载检查**通过后，接下来虚拟机将为新生对象**分配内存**。对象所需的内存大小在类加载完成后便可确定，为对象分配空间的任务等同于把一块确定大小的内存从 Java 堆中划分出来。**分配方式**有 **“指针碰撞”** 和 **“空闲列表”** 两种，**选择那种分配方式由 Java 堆是否规整决定，而Java堆是否规整又由所采用的垃圾收集器是否带有压缩整理功能决定**。 - - -**内存分配的两种方式：（补充内容，需要掌握）** - -选择以上两种方式中的哪一种，取决于 Java 堆内存是否规整。而 Java 堆内存是否规整，取决于 GC 收集器的算法是"标记-清除"，还是"标记-整理"（也称作"标记-压缩"），值得注意的是，复制算法内存也是规整的 - -![](https://user-gold-cdn.xitu.io/2018/8/22/16561e59a40a2c3d?w=1426&h=333&f=png&s=26346) - -**内存分配并发问题（补充内容，需要掌握）** - -在创建对象的时候有一个很重要的问题，就是线程安全，因为在实际开发过程中，创建对象是很频繁的事情，作为虚拟机来说，必须要保证线程是安全的，通常来讲，虚拟机采用两种方式来保证线程安全： - -- **CAS+失败重试：** CAS 是乐观锁的一种实现方式。所谓乐观锁就是，每次不加锁而是假设没有冲突而去完成某项操作，如果因为冲突失败就重试，直到成功为止。**虚拟机采用 CAS 配上失败重试的方式保证更新操作的原子性。** -- **TLAB：** 为每一个线程预先在Eden区分配一块儿内存，JVM在给线程中的对象分配内存时，首先在TLAB分配，当对象大于TLAB中的剩余内存或TLAB的内存已用尽时，再采用上述的CAS进行内存分配 - - - -**③初始化零值：** 内存分配完成后，虚拟机需要将分配到的内存空间都初始化为零值（不包括对象头），这一步操作保证了对象的实例字段在 Java 代码中可以不赋初始值就直接使用，程序能访问到这些字段的数据类型所对应的零值。 - -**④设置对象头：** 初始化零值完成之后，**虚拟机要对对象进行必要的设置**，例如这个对象是那个类的实例、如何才能找到类的元数据信息、对象的哈希吗、对象的 GC 分代年龄等信息。 **这些信息存放在对象头中。** 另外，根据虚拟机当前运行状态的不同，如是否启用偏向锁等，对象头会有不同的设置方式。 - - -**⑤执行 init 方法：** 在上面工作都完成之后，从虚拟机的视角来看，一个新的对象已经产生了，但从 Java 程序的视角来看，对象创建才刚开始，`` 方法还没有执行，所有的字段都还为零。所以一般来说，执行 new 指令之后会接着执行 `` 方法，把对象按照程序员的意愿进行初始化，这样一个真正可用的对象才算完全产生出来。 - - -### 3.2 对象的内存布局 - -在 Hotspot 虚拟机中，对象在内存中的布局可以分为3块区域：**对象头**、**实例数据**和**对齐填充**。 - -**Hotspot虚拟机的对象头包括两部分信息**，**第一部分用于存储对象自身的自身运行时数据**（哈希码、GC分代年龄、锁状态标志等等），**另一部分是类型指针**，即对象指向它的类元数据的指针，虚拟机通过这个指针来确定这个对象是那个类的实例。 - -**实例数据部分是对象真正存储的有效信息**，也是在程序中所定义的各种类型的字段内容。 - -**对齐填充部分不是必然存在的，也没有什么特别的含义，仅仅起占位作用。** 因为Hotspot虚拟机的自动内存管理系统要求对象起始地址必须是8字节的整数倍，换句话说就是对象的大小必须是8字节的整数倍。而对象头部分正好是8字节的倍数（1倍或2倍），因此，当对象实例数据部分没有对齐时，就需要通过对齐填充来补全。 - -### 3.3 对象的访问定位 -建立对象就是为了使用对象，我们的Java程序通过栈上的 reference 数据来操作堆上的具体对象。对象的访问方式有虚拟机实现而定，目前主流的访问方式有**①使用句柄**和**②直接指针**两种： - -1. **句柄：** 如果使用句柄的话，那么Java堆中将会划分出一块内存来作为句柄池，reference 中存储的就是对象的句柄地址，而句柄中包含了对象实例数据与类型数据各自的具体地址信息； -![使用句柄](https://user-gold-cdn.xitu.io/2018/4/27/16306b9573968946?w=786&h=362&f=png&s=109201) - -2. **直接指针：** 如果使用直接指针访问，那么 Java 堆对象的布局中就必须考虑如何放置访问类型数据的相关信息，而reference 中存储的直接就是对象的地址。 - -![使用直接指针](https://user-gold-cdn.xitu.io/2018/4/27/16306ba3a41b6b65?w=766&h=353&f=png&s=99172) - -**这两种对象访问方式各有优势。使用句柄来访问的最大好处是 reference 中存储的是稳定的句柄地址，在对象被移动时只会改变句柄中的实例数据指针，而 reference 本身不需要修改。使用直接指针访问方式最大的好处就是速度快，它节省了一次指针定位的时间开销。** - - - - -## 四 重点补充内容 - -### String 类和常量池 - -**1 String 对象的两种创建方式：** - -```java - String str1 = "abcd"; - String str2 = new String("abcd"); - System.out.println(str1==str2);//false -``` - -这两种不同的创建方法是有差别的，第一种方式是在常量池中拿对象，第二种方式是直接在堆内存空间创建一个新的对象。 -![](https://user-gold-cdn.xitu.io/2018/8/22/16561e59a59c0873?w=698&h=355&f=png&s=10449) -记住：只要使用new方法，便需要创建新的对象。 - - - -**2 String 类型的常量池比较特殊。它的主要使用方法有两种：** - -- 直接使用双引号声明出来的 String 对象会直接存储在常量池中。 -- 如果不是用双引号声明的 String 对象，可以使用 String 提供的 intern 方法。String.intern() 是一个 Native 方法，它的作用是：如果运行时常量池中已经包含一个等于此 String 对象内容的字符串，则返回常量池中该字符串的引用；如果没有，则在常量池中创建与此 String 内容相同的字符串，并返回常量池中创建的字符串的引用。 - -```java - String s1 = new String("计算机"); - String s2 = s1.intern(); - String s3 = "计算机"; - System.out.println(s2);//计算机 - System.out.println(s1 == s2);//false，因为一个是堆内存中的String对象一个是常量池中的String对象， - System.out.println(s3 == s2);//true，因为两个都是常量池中的String对象 -``` -**3 String 字符串拼接** -```java - String str1 = "str"; - String str2 = "ing"; - - String str3 = "str" + "ing";//常量池中的对象 - String str4 = str1 + str2; //在堆上创建的新的对象 - String str5 = "string";//常量池中的对象 - System.out.println(str3 == str4);//false - System.out.println(str3 == str5);//true - System.out.println(str4 == str5);//false -``` -![](https://user-gold-cdn.xitu.io/2018/8/22/16561e59a4d13f92?w=593&h=603&f=png&s=22265) - -尽量避免多个字符串拼接，因为这样会重新创建对象。如果需要改变字符串的话，可以使用 StringBuilder 或者 StringBuffer。 -### String s1 = new String("abc");这句话创建了几个对象？ - -**创建了两个对象。** - -**验证：** - -```java - String s1 = new String("abc");// 堆内存的地址值 - String s2 = "abc"; - System.out.println(s1 == s2);// 输出false,因为一个是堆内存，一个是常量池的内存，故两者是不同的。 - System.out.println(s1.equals(s2));// 输出true -``` - -**结果：** - -``` -false -true -``` - -**解释：** - -先有字符串"abc"放入常量池，然后 new 了一份字符串"abc"放入Java堆(字符串常量"abc"在编译期就已经确定放入常量池，而 Java 堆上的"abc"是在运行期初始化阶段才确定)，然后 Java 栈的 str1 指向Java堆上的"abc"。 - -### 8种基本类型的包装类和常量池 - -- **Java 基本类型的包装类的大部分都实现了常量池技术，即Byte,Short,Integer,Long,Character,Boolean；这5种包装类默认创建了数值[-128，127]的相应类型的缓存数据，但是超出此范围仍然会去创建新的对象。** -- **两种浮点数类型的包装类 Float,Double 并没有实现常量池技术。** - -```java - Integer i1 = 33; - Integer i2 = 33; - System.out.println(i1 == i2);// 输出true - Integer i11 = 333; - Integer i22 = 333; - System.out.println(i11 == i22);// 输出false - Double i3 = 1.2; - Double i4 = 1.2; - System.out.println(i3 == i4);// 输出false -``` - -**Integer 缓存源代码：** - -```java -/** -*此方法将始终缓存-128到127（包括端点）范围内的值，并可以缓存此范围之外的其他值。 -*/ - public static Integer valueOf(int i) { - if (i >= IntegerCache.low && i <= IntegerCache.high) - return IntegerCache.cache[i + (-IntegerCache.low)]; - return new Integer(i); - } - -``` - -**应用场景：** -1. Integer i1=40；Java 在编译的时候会直接将代码封装成Integer i1=Integer.valueOf(40);，从而使用常量池中的对象。 -2. Integer i1 = new Integer(40);这种情况下会创建新的对象。 - -```java - Integer i1 = 40; - Integer i2 = new Integer(40); - System.out.println(i1==i2);//输出false -``` -**Integer比较更丰富的一个例子:** - -```java - Integer i1 = 40; - Integer i2 = 40; - Integer i3 = 0; - Integer i4 = new Integer(40); - Integer i5 = new Integer(40); - Integer i6 = new Integer(0); - - System.out.println("i1=i2 " + (i1 == i2)); - System.out.println("i1=i2+i3 " + (i1 == i2 + i3)); - System.out.println("i1=i4 " + (i1 == i4)); - System.out.println("i4=i5 " + (i4 == i5)); - System.out.println("i4=i5+i6 " + (i4 == i5 + i6)); - System.out.println("40=i5+i6 " + (40 == i5 + i6)); -``` - -结果： - -``` -i1=i2 true -i1=i2+i3 true -i1=i4 false -i4=i5 false -i4=i5+i6 true -40=i5+i6 true -``` - -解释： - -语句i4 == i5 + i6，因为+这个操作符不适用于Integer对象，首先i5和i6进行自动拆箱操作，进行数值相加，即i4 == 40。然后Integer对象无法与数值进行直接比较，所以i4自动拆箱转为int值40，最终这条语句转为40 == 40进行数值比较。 - - -**参考：** - -- 《深入理解Java虚拟机：JVM高级特性与最佳实践（第二版》 -- 《实战java虚拟机》 -- https://www.cnblogs.com/CZDblog/p/5589379.html -- https://www.cnblogs.com/java-zhao/p/5180492.html -- https://blog.csdn.net/qq_26222859/article/details/73135660 -- https://blog.csdn.net/cugwuhan2014/article/details/78038254 - - - - - diff --git "a/Java\347\233\270\345\205\263/\345\244\232\347\272\277\347\250\213\347\263\273\345\210\227.md" "b/Java\347\233\270\345\205\263/\345\244\232\347\272\277\347\250\213\347\263\273\345\210\227.md" deleted file mode 100644 index 6ed7bdafb211a19fba73f256597d350ac60099b0..0000000000000000000000000000000000000000 --- "a/Java\347\233\270\345\205\263/\345\244\232\347\272\277\347\250\213\347\263\273\345\210\227.md" +++ /dev/null @@ -1,69 +0,0 @@ -> ## 多线程系列文章 -下列文章，我都更新在了我的博客专栏：[Java并发编程指南](https://blog.csdn.net/column/details/20860.html)。 - -1. [Java多线程学习（一）Java多线程入门](http://blog.csdn.net/qq_34337272/article/details/79640870) -2. [Java多线程学习（二）synchronized关键字（1）](http://blog.csdn.net/qq_34337272/article/details/79655194) -3. [Java多线程学习（二）synchronized关键字（2）](http://blog.csdn.net/qq_34337272/article/details/79670775) -4. [Java多线程学习（三）volatile关键字](http://blog.csdn.net/qq_34337272/article/details/79680771) -5. [Java多线程学习（四）等待/通知（wait/notify）机制](http://blog.csdn.net/qq_34337272/article/details/79690279) - -6. [Java多线程学习（五）线程间通信知识点补充](http://blog.csdn.net/qq_34337272/article/details/79694226) -7. [Java多线程学习（六）Lock锁的使用](http://blog.csdn.net/qq_34337272/article/details/79714196) -8. [Java多线程学习（七）并发编程中一些问题](https://blog.csdn.net/qq_34337272/article/details/79844051) -9. [Java多线程学习（八）线程池与Executor 框架](https://blog.csdn.net/qq_34337272/article/details/79959271) - - -> ## 多线程系列文章重要知识点与思维导图 - -### Java多线程学习（一）Java多线程入门 - -![](https://user-gold-cdn.xitu.io/2018/8/4/16504e0cb6bac32e?w=758&h=772&f=jpeg&s=247210) - -### Java多线程学习（二）synchronized关键字（1） -![](https://user-gold-cdn.xitu.io/2018/8/4/16504e245ceb3ea9?w=1028&h=490&f=jpeg&s=203811) - -注意：**可重入锁的概念**。 - - 另外要注意：**synchronized取得的锁都是对象锁，而不是把一段代码或方法当做锁。** 如果多个线程访问的是同一个对象，哪个线程先执行带synchronized关键字的方法，则哪个线程就持有该方法，那么其他线程只能呈等待状态。如果多个线程访问的是多个对象则不一定，因为多个对象会产生多个锁。 - -### Java多线程学习（二）synchronized关键字（2） - -![思维导图](https://user-gold-cdn.xitu.io/2018/8/4/16504e3d98213324?w=1448&h=439&f=jpeg&s=245012) - - **注意：** - - - 其他线程执行对象中**synchronized同步方法**（上一节我们介绍过，需要回顾的可以看上一节的文章）和**synchronized(this)代码块**时呈现同步效果; - - **如果两个线程使用了同一个“对象监视器”（synchronized(object)）,运行结果同步，否则不同步**. - - **synchronized关键字加到static静态方法**和**synchronized(class)代码块**上都是是给**Class类**上锁，而**synchronized关键字加到非static静态方法**上是给**对象**上锁。 - - 数据类型String的常量池属性:**在Jvm中具有String常量池缓存的功能** - -### Java多线程学习（三）volatile关键字 - -![volatile关键字](https://user-gold-cdn.xitu.io/2018/8/4/16504e4ab69d8d58) - **注意：** - - **synchronized关键字**和**volatile关键字**比较 - -### Java多线程学习（四）等待/通知（wait/notify）机制 - -![本节思维导图](https://user-gold-cdn.xitu.io/2018/3/25/1625d2a9188ec021?w=1254&h=452&f=jpeg&s=229471) - -### Java多线程学习（五）线程间通信知识点补充 - -![本节思维导图](https://user-gold-cdn.xitu.io/2018/8/4/16504e618d6886c5?w=1146&h=427&f=jpeg&s=220573) - **注意：** ThreadLocal类主要解决的就是让每个线程绑定自己的值，可以将ThreadLocal类形象的比喻成存放数据的盒子，盒子中可以存储每个线程的私有数据。 - -### Java多线程学习（六）Lock锁的使用 - - ![本节思维导图](https://user-gold-cdn.xitu.io/2018/3/27/1626755a8e9a8774?w=1197&h=571&f=jpeg&s=258439) - -### Java多线程学习（七）并发编程中一些问题 - -![思维导图](https://user-gold-cdn.xitu.io/2018/4/7/162a01b71ebc4842?w=1067&h=517&f=png&s=36857) - -### Java多线程学习（八）线程池与Executor 框架 - -![](http://my-blog-to-use.oss-cn-beijing.aliyuncs.com/18-12-14/86510659.jpg) - diff --git "a/Java\347\233\270\345\205\263/\346\220\236\345\256\232JVM\345\236\203\345\234\276\345\233\236\346\224\266\345\260\261\346\230\257\350\277\231\344\271\210\347\256\200\345\215\225.md" "b/Java\347\233\270\345\205\263/\346\220\236\345\256\232JVM\345\236\203\345\234\276\345\233\236\346\224\266\345\260\261\346\230\257\350\277\231\344\271\210\347\256\200\345\215\225.md" deleted file mode 100644 index 819d37faca2c878148d011d4dcb3055eef03ccc0..0000000000000000000000000000000000000000 --- "a/Java\347\233\270\345\205\263/\346\220\236\345\256\232JVM\345\236\203\345\234\276\345\233\236\346\224\266\345\260\261\346\230\257\350\277\231\344\271\210\347\256\200\345\215\225.md" +++ /dev/null @@ -1,374 +0,0 @@ - -上文回顾：[《可能是把Java内存区域讲的最清楚的一篇文章》](https://mp.weixin.qq.com/s?__biz=MzU4NDQ4MzU5OA==&mid=2247484303&idx=1&sn=af0fd436cef755463f59ee4dd0720cbd&chksm=fd9855eecaefdcf8d94ac581cfda4e16c8a730bda60c3b50bc55c124b92f23b6217f7f8e58d5&token=506869459&lang=zh_CN#rd) -## 写在前面 - -### 本节常见面试题： - -问题答案在文中都有提到 - -- 如何判断对象是否死亡（两种方法）。 -- 简单的介绍一下强引用、软引用、弱引用、虚引用（虚引用与软引用和弱引用的区别、使用软引用能带来的好处）。 -- 如何判断一个常量是废弃常量 -- 如何判断一个类是无用的类 -- 垃圾收集有哪些算法，各自的特点？ -- HotSpot为什么要分为新生代和老年代？ -- 常见的垃圾回收器有那些？ -- 介绍一下CMS,G1收集器。 -- Minor Gc和Full GC 有什么不同呢？ - -### 本文导火索 - -![](http://my-blog-to-use.oss-cn-beijing.aliyuncs.com/18-8-26/29176325.jpg) - -当需要排查各种 内存溢出问题、当垃圾收集成为系统达到更高并发的瓶颈时，我们就需要对这些“自动化”的技术实施必要的监控和调节。 - - - -## 1 揭开JVM内存分配与回收的神秘面纱 - -Java 的自动内存管理主要是针对对象内存的回收和对象内存的分配。同时，Java 自动内存管理最核心的功能是 **堆** 内存中对象的分配与回收。 - -**JDK1.8之前的堆内存示意图：** - -![](https://user-gold-cdn.xitu.io/2018/8/25/16570344a29c3433?w=599&h=250&f=png&s=8946) - -从上图可以看出堆内存分为新生代、老年代和永久代。新生代又被进一步分为：Eden 区＋Survivor1 区＋Survivor2 区。值得注意的是，在 JDK 1.8中移除整个永久代，取而代之的是一个叫元空间（Metaspace）的区域（永久代使用的是JVM的堆内存空间，而元空间使用的是物理内存，直接受到本机的物理内存限制）。 - -![](http://my-blog-to-use.oss-cn-beijing.aliyuncs.com/18-8-27/89294547.jpg) - -### 1.1 对象优先在eden区分配 - -目前主流的垃圾收集器都会采用分代回收算法，因此需要将堆内存分为新生代和老年代，这样我们就可以根据各个年代的特点选择合适的垃圾收集算法。 - -大多数情况下，对象在新生代中 eden 区分配。当 eden 区没有足够空间进行分配时，虚拟机将发起一次Minor GC.下面我们来进行实际测试以下。 - -在测试之前我们先来看看 **Minor GC和Full GC 有什么不同呢？** - -- **新生代GC（Minor GC）**:指发生新生代的的垃圾收集动作，Minor GC非常频繁，回收速度一般也比较快。 -- **老年代GC（Major GC/Full GC）**:指发生在老年代的GC，出现了Major GC经常会伴随至少一次的Minor GC（并非绝对），Major GC的速度一般会比Minor GC的慢10倍以上。 - -**测试：** - -```java -public class GCTest { - - public static void main(String[] args) { - byte[] allocation1, allocation2; - allocation1 = new byte[30900*1024]; - //allocation2 = new byte[900*1024]; - } -} -``` -通过以下方式运行： -![](http://my-blog-to-use.oss-cn-beijing.aliyuncs.com/18-8-26/25178350.jpg) - -添加的参数：`-XX:+PrintGCDetails` -![](http://my-blog-to-use.oss-cn-beijing.aliyuncs.com/18-8-26/10317146.jpg) - -运行结果(红色字体描述有误，应该是对应于JDK1.7的永久代)： - -![](http://my-blog-to-use.oss-cn-beijing.aliyuncs.com/18-8-26/28954286.jpg) - -从上图我们可以看出eden区内存几乎已经被分配完全（即使程序什么也不做，新生代也会使用2000多k内存）。假如我们再为allocation2分配内存会出现什么情况呢？ - -```java -allocation2 = new byte[900*1024]; -``` -![](http://my-blog-to-use.oss-cn-beijing.aliyuncs.com/18-8-26/28128785.jpg) - -**简单解释一下为什么会出现这种情况：** 因为给allocation2分配内存的时候eden区内存几乎已经被分配完了，我们刚刚讲了当Eden区没有足够空间进行分配时，虚拟机将发起一次Minor GC.GC期间虚拟机又发现allocation1无法存入Survivor空间，所以只好通过 **分配担保机制** 把新生代的对象提前转移到老年代中去，老年代上的空间足够存放allocation1，所以不会出现Full GC。执行Minor GC后，后面分配的对象如果能够存在eden区的话，还是会在eden区分配内存。可以执行如下代码验证： - -```java -public class GCTest { - - public static void main(String[] args) { - byte[] allocation1, allocation2,allocation3,allocation4,allocation5; - allocation1 = new byte[32000*1024]; - allocation2 = new byte[1000*1024]; - allocation3 = new byte[1000*1024]; - allocation4 = new byte[1000*1024]; - allocation5 = new byte[1000*1024]; - } -} - -``` - - -### 1.2 大对象直接进入老年代 -大对象就是需要大量连续内存空间的对象（比如：字符串、数组）。 - -**为什么要这样呢？** - -为了避免为大对象分配内存时由于分配担保机制带来的复制而降低效率。 - -### 1.3 长期存活的对象将进入老年代 -既然虚拟机采用了分代收集的思想来管理内存，那么内存回收时就必须能识别哪些对象应放在新生代，哪些对象应放在老年代中。为了做到这一点，虚拟机给每个对象一个对象年龄（Age）计数器。 - -如果对象在 Eden 出生并经过第一次 Minor GC 后仍然能够存活，并且能被 Survivor 容纳的话，将被移动到 Survivor 空间中，并将对象年龄设为1.对象在 Survivor 中每熬过一次 MinorGC,年龄就增加1岁，当它的年龄增加到一定程度（默认为15岁），就会被晋升到老年代中。对象晋升到老年代的年龄阈值，可以通过参数 `-XX:MaxTenuringThreshold` 来设置。 - -### 1.4 动态对象年龄判定 - -为了更好的适应不同程序的内存情况，虚拟机不是永远要求对象年龄必须达到了某个值才能进入老年代，如果 Survivor 空间中相同年龄所有对象大小的总和大于 Survivor 空间的一半，年龄大于或等于该年龄的对象就可以直接进入老年代，无需达到要求的年龄。 - - -## 2 对象已经死亡？ - -堆中几乎放着所有的对象实例，对堆垃圾回收前的第一步就是要判断那些对象已经死亡（即不能再被任何途径使用的对象）。 - -![](http://my-blog-to-use.oss-cn-beijing.aliyuncs.com/18-8-27/11034259.jpg) - -### 2.1 引用计数法 - -给对象中添加一个引用计数器，每当有一个地方引用它，计数器就加1；当引用失效，计数器就减1；任何时候计数器为0的对象就是不可能再被使用的。 - -**这个方法实现简单，效率高，但是目前主流的虚拟机中并没有选择这个算法来管理内存，其最主要的原因是它很难解决对象之间相互循环引用的问题。** 所谓对象之间的相互引用问题，如下面代码所示：除了对象objA 和 objB 相互引用着对方之外，这两个对象之间再无任何引用。但是他们因为互相引用对方，导致它们的引用计数器都不为0，于是引用计数算法无法通知 GC 回收器回收他们。 - -```java -public class ReferenceCountingGc { - Object instance = null; - public static void main(String[] args) { - ReferenceCountingGc objA = new ReferenceCountingGc(); - ReferenceCountingGc objB = new ReferenceCountingGc(); - objA.instance = objB; - objB.instance = objA; - objA = null; - objB = null; - - } -} -``` - - - -### 2.2 可达性分析算法 - -这个算法的基本思想就是通过一系列的称为 **“GC Roots”** 的对象作为起点，从这些节点开始向下搜索，节点所走过的路径称为引用链，当一个对象到 GC Roots 没有任何引用链相连的话，则证明此对象是不可用的。 - -![可达性分析算法](http://my-blog-to-use.oss-cn-beijing.aliyuncs.com/18-8-27/72762049.jpg) - - -### 2.3 再谈引用 - -无论是通过引用计数法判断对象引用数量，还是通过可达性分析法判断对象的引用链是否可达，判定对象的存活都与“引用”有关。 - -JDK1.2之前，Java中引用的定义很传统：如果reference类型的数据存储的数值代表的是另一块内存的起始地址，就称这块内存代表一个引用。 - -JDK1.2以后，Java对引用的概念进行了扩充，将引用分为强引用、软引用、弱引用、虚引用四种（引用强度逐渐减弱） - - - -**1．强引用** - -以前我们使用的大部分引用实际上都是强引用，这是使用最普遍的引用。如果一个对象具有强引用，那就类似于**必不可少的生活用品**，垃圾回收器绝不会回收它。当内存空 间不足，Java虚拟机宁愿抛出OutOfMemoryError错误，使程序异常终止，也不会靠随意回收具有强引用的对象来解决内存不足问题。 - -**2．软引用（SoftReference）** - -如果一个对象只具有软引用，那就类似于**可有可无的生活用品**。如果内存空间足够，垃圾回收器就不会回收它，如果内存空间不足了，就会回收这些对象的内存。只要垃圾回收器没有回收它，该对象就可以被程序使用。软引用可用来实现内存敏感的高速缓存。 - -软引用可以和一个引用队列（ReferenceQueue）联合使用，如果软引用所引用的对象被垃圾回收，JAVA虚拟机就会把这个软引用加入到与之关联的引用队列中。 - -**3．弱引用（WeakReference）** - -如果一个对象只具有弱引用，那就类似于**可有可无的生活用品**。弱引用与软引用的区别在于：只具有弱引用的对象拥有更短暂的生命周期。在垃圾回收器线程扫描它 所管辖的内存区域的过程中，一旦发现了只具有弱引用的对象，不管当前内存空间足够与否，都会回收它的内存。不过，由于垃圾回收器是一个优先级很低的线程， 因此不一定会很快发现那些只具有弱引用的对象。 - -弱引用可以和一个引用队列（ReferenceQueue）联合使用，如果弱引用所引用的对象被垃圾回收，Java虚拟机就会把这个弱引用加入到与之关联的引用队列中。 - -**4．虚引用（PhantomReference）** - -"虚引用"顾名思义，就是形同虚设，与其他几种引用都不同，虚引用并不会决定对象的生命周期。如果一个对象仅持有虚引用，那么它就和没有任何引用一样，在任何时候都可能被垃圾回收。 - -**虚引用主要用来跟踪对象被垃圾回收的活动**。 - -**虚引用与软引用和弱引用的一个区别在于：** 虚引用必须和引用队列（ReferenceQueue）联合使用。当垃 圾回收器准备回收一个对象时，如果发现它还有虚引用，就会在回收对象的内存之前，把这个虚引用加入到与之关联的引用队列中。程序可以通过判断引用队列中是 否已经加入了虚引用，来了解被引用的对象是否将要被垃圾回收。程序如果发现某个虚引用已经被加入到引用队列，那么就可以在所引用的对象的内存被回收之前采取必要的行动。 - -特别注意，在程序设计中一般很少使用弱引用与虚引用，使用软引用的情况较多，这是因为**软引用可以加速JVM对垃圾内存的回收速度，可以维护系统的运行安全，防止内存溢出（OutOfMemory）等问题的产生**。 - -### 2.4 不可达的对象并非“非死不可” - -即使在可达性分析法中不可达的对象，也并非是“非死不可”的，这时候它们暂时处于“缓刑阶段”，要真正宣告一个对象死亡，至少要经历两次标记过程；可达性分析法中不可达的对象被第一次标记并且进行一次筛选，筛选的条件是此对象是否有必要执行 finalize 方法。当对象没有覆盖 finalize 方法，或 finalize 方法已经被虚拟机调用过时，虚拟机将这两种情况视为没有必要执行。 - -被判定为需要执行的对象将会被放在一个队列中进行第二次标记，除非这个对象与引用链上的任何一个对象建立关联，否则就会被真的回收。 - -### 2.5 如何判断一个常量是废弃常量 - -运行时常量池主要回收的是废弃的常量。那么，我们如何判断一个常量是废弃常量呢？ - -假如在常量池中存在字符串 "abc"，如果当前没有任何String对象引用该字符串常量的话，就说明常量 "abc" 就是废弃常量，如果这时发生内存回收的话而且有必要的话，"abc" 就会被系统清理出常量池。 - -注意：我们在 [可能是把Java内存区域讲的最清楚的一篇文章](https://mp.weixin.qq.com/s?__biz=MzU4NDQ4MzU5OA==&mid=2247484303&idx=1&sn=af0fd436cef755463f59ee4dd0720cbd&chksm=fd9855eecaefdcf8d94ac581cfda4e16c8a730bda60c3b50bc55c124b92f23b6217f7f8e58d5&token=506869459&lang=zh_CN#rd) 也讲了JDK1.7及之后版本的 JVM 已经将运行时常量池从方法区中移了出来，在 Java 堆（Heap）中开辟了一块区域存放运行时常量池。 - -### 2.6 如何判断一个类是无用的类 - -方法区主要回收的是无用的类，那么如何判断一个类是无用的类的呢？ - -判定一个常量是否是“废弃常量”比较简单，而要判定一个类是否是“无用的类”的条件则相对苛刻许多。类需要同时满足下面3个条件才能算是 **“无用的类”** ： - -- 该类所有的实例都已经被回收，也就是 Java 堆中不存在该类的任何实例。 -- 加载该类的 ClassLoader 已经被回收。 -- 该类对应的 java.lang.Class 对象没有在任何地方被引用，无法在任何地方通过反射访问该类的方法。 - -虚拟机可以对满足上述3个条件的无用类进行回收，这里说的仅仅是“可以”，而并不是和对象一样不使用了就会必然被回收。 - - -## 3 垃圾收集算法 - -![垃圾收集算法](http://my-blog-to-use.oss-cn-beijing.aliyuncs.com/18-8-27/1142723.jpg) - -### 3.1 标记-清除算法 - -算法分为“标记”和“清除”阶段：首先标记出所有需要回收的对象，在标记完成后统一回收所有被标记的对象。它是最基础的收集算法，效率也很高，但是会带来两个明显的问题： - -1. **效率问题** -2. **空间问题（标记清除后会产生大量不连续的碎片）** - -![标记-清除算法](http://my-blog-to-use.oss-cn-beijing.aliyuncs.com/18-8-27/63707281.jpg) - -### 3.2 复制算法 - -为了解决效率问题，“复制”收集算法出现了。它可以将内存分为大小相同的两块，每次使用其中的一块。当这一块的内存使用完后，就将还存活的对象复制到另一块去，然后再把使用的空间一次清理掉。这样就使每次的内存回收都是对内存区间的一半进行回收。 - -![复制算法](http://my-blog-to-use.oss-cn-beijing.aliyuncs.com/18-8-27/90984624.jpg) - -### 3.3 标记-整理算法 -根据老年代的特点特出的一种标记算法，标记过程仍然与“标记-清除”算法一样，但后续步骤不是直接对可回收对象回收，而是让所有存活的对象向一端移动，然后直接清理掉端边界以外的内存。 - -![标记-整理算法](http://my-blog-to-use.oss-cn-beijing.aliyuncs.com/18-8-27/94057049.jpg) - -### 3.4 分代收集算法 - -当前虚拟机的垃圾收集都采用分代收集算法，这种算法没有什么新的思想，只是根据对象存活周期的不同将内存分为几块。一般将java堆分为新生代和老年代，这样我们就可以根据各个年代的特点选择合适的垃圾收集算法。 - -**比如在新生代中，每次收集都会有大量对象死去，所以可以选择复制算法，只需要付出少量对象的复制成本就可以完成每次垃圾收集。而老年代的对象存活几率是比较高的，而且没有额外的空间对它进行分配担保，所以我们必须选择“标记-清除”或“标记-整理”算法进行垃圾收集。** - -**延伸面试问题：** HotSpot为什么要分为新生代和老年代？ - -根据上面的对分代收集算法的介绍回答。 - -## 4 垃圾收集器 - -![](http://my-blog-to-use.oss-cn-beijing.aliyuncs.com/18-8-27/41460955.jpg) - -**如果说收集算法是内存回收的方法论，那么垃圾收集器就是内存回收的具体实现。** - -虽然我们对各个收集器进行比较，但并非要挑选出一个最好的收集器。因为知道现在为止还没有最好的垃圾收集器出现，更加没有万能的垃圾收集器，**我们能做的就是根据具体应用场景选择适合自己的垃圾收集器**。试想一下：如果有一种四海之内、任何场景下都适用的完美收集器存在，那么我们的HotSpot虚拟机就不会实现那么多不同的垃圾收集器了。 - - -### 4.1 Serial收集器 -Serial（串行）收集器收集器是最基本、历史最悠久的垃圾收集器了。大家看名字就知道这个收集器是一个单线程收集器了。它的 **“单线程”** 的意义不仅仅意味着它只会使用一条垃圾收集线程去完成垃圾收集工作，更重要的是它在进行垃圾收集工作的时候必须暂停其他所有的工作线程（ **"Stop The World"** ），直到它收集结束。 - - **新生代采用复制算法，老年代采用标记-整理算法。** -![ Serial收集器](http://my-blog-to-use.oss-cn-beijing.aliyuncs.com/18-8-27/46873026.jpg) - -虚拟机的设计者们当然知道Stop The World带来的不良用户体验，所以在后续的垃圾收集器设计中停顿时间在不断缩短（仍然还有停顿，寻找最优秀的垃圾收集器的过程仍然在继续）。 - -但是Serial收集器有没有优于其他垃圾收集器的地方呢？当然有，它**简单而高效（与其他收集器的单线程相比）**。Serial收集器由于没有线程交互的开销，自然可以获得很高的单线程收集效率。Serial收集器对于运行在Client模式下的虚拟机来说是个不错的选择。 - - - -### 4.2 ParNew收集器 -**ParNew收集器其实就是Serial收集器的多线程版本，除了使用多线程进行垃圾收集外，其余行为（控制参数、收集算法、回收策略等等）和Serial收集器完全一样。** - - **新生代采用复制算法，老年代采用标记-整理算法。** -![ParNew收集器](http://my-blog-to-use.oss-cn-beijing.aliyuncs.com/18-8-27/22018368.jpg) - -它是许多运行在Server模式下的虚拟机的首要选择，除了Serial收集器外，只有它能与CMS收集器（真正意义上的并发收集器，后面会介绍到）配合工作。 - -**并行和并发概念补充：** - -- **并行（Parallel）** ：指多条垃圾收集线程并行工作，但此时用户线程仍然处于等待状态。 - -- **并发（Concurrent）**：指用户线程与垃圾收集线程同时执行（但不一定是并行，可能会交替执行），用户程序在继续运行，而垃圾收集器运行在另一个CPU上。 - - -### 4.3 Parallel Scavenge收集器 - -Parallel Scavenge 收集器类似于ParNew 收集器。 **那么它有什么特别之处呢？** - -``` --XX:+UseParallelGC - - 使用Parallel收集器+ 老年代串行 - --XX:+UseParallelOldGC - - 使用Parallel收集器+ 老年代并行 - -``` - -**Parallel Scavenge收集器关注点是吞吐量（高效率的利用CPU）。CMS等垃圾收集器的关注点更多的是用户线程的停顿时间（提高用户体验）。所谓吞吐量就是CPU中用于运行用户代码的时间与CPU总消耗时间的比值。** Parallel Scavenge收集器提供了很多参数供用户找到最合适的停顿时间或最大吞吐量，如果对于收集器运作不太了解的话，手工优化存在的话可以选择把内存管理优化交给虚拟机去完成也是一个不错的选择。 - - **新生代采用复制算法，老年代采用标记-整理算法。** -![ParNew收集器](http://my-blog-to-use.oss-cn-beijing.aliyuncs.com/18-8-27/22018368.jpg) - - -### 4.4.Serial Old收集器 -**Serial收集器的老年代版本**，它同样是一个单线程收集器。它主要有两大用途：一种用途是在JDK1.5以及以前的版本中与Parallel Scavenge收集器搭配使用，另一种用途是作为CMS收集器的后备方案。 - -### 4.5 Parallel Old收集器 - **Parallel Scavenge收集器的老年代版本**。使用多线程和“标记-整理”算法。在注重吞吐量以及CPU资源的场合，都可以优先考虑 Parallel Scavenge收集器和Parallel Old收集器。 - -### 4.6 CMS收集器 - -**CMS（Concurrent Mark Sweep）收集器是一种以获取最短回收停顿时间为目标的收集器。它而非常符合在注重用户体验的应用上使用。** - -**CMS（Concurrent Mark Sweep）收集器是HotSpot虚拟机第一款真正意义上的并发收集器，它第一次实现了让垃圾收集线程与用户线程（基本上）同时工作。** - -从名字中的**Mark Sweep**这两个词可以看出，CMS收集器是一种 **“标记-清除”算法**实现的，它的运作过程相比于前面几种垃圾收集器来说更加复杂一些。整个过程分为四个步骤： - -- **初始标记：** 暂停所有的其他线程，并记录下直接与root相连的对象，速度很快 ； -- **并发标记：** 同时开启GC和用户线程，用一个闭包结构去记录可达对象。但在这个阶段结束，这个闭包结构并不能保证包含当前所有的可达对象。因为用户线程可能会不断的更新引用域，所以GC线程无法保证可达性分析的实时性。所以这个算法里会跟踪记录这些发生引用更新的地方。 -- **重新标记：** 重新标记阶段就是为了修正并发标记期间因为用户程序继续运行而导致标记产生变动的那一部分对象的标记记录，这个阶段的停顿时间一般会比初始标记阶段的时间稍长，远远比并发标记阶段时间短 -- **并发清除：** 开启用户线程，同时GC线程开始对为标记的区域做清扫。 - -![CMS垃圾收集器](http://my-blog-to-use.oss-cn-beijing.aliyuncs.com/18-8-27/82825079.jpg) - -从它的名字就可以看出它是一款优秀的垃圾收集器，主要优点：**并发收集、低停顿**。但是它有下面三个明显的缺点： - -- **对CPU资源敏感；** -- **无法处理浮动垃圾；** -- **它使用的回收算法-“标记-清除”算法会导致收集结束时会有大量空间碎片产生。** - -### 4.7 G1收集器 - - -**G1 (Garbage-First)是一款面向服务器的垃圾收集器,主要针对配备多颗处理器及大容量内存的机器. 以极高概率满足GC停顿时间要求的同时,还具备高吞吐量性能特征.** - -被视为JDK1.7中HotSpot虚拟机的一个重要进化特征。它具备一下特点： - -- **并行与并发**：G1能充分利用CPU、多核环境下的硬件优势，使用多个CPU（CPU或者CPU核心）来缩短Stop-The-World停顿时间。部分其他收集器原本需要停顿Java线程执行的GC动作，G1收集器仍然可以通过并发的方式让java程序继续执行。 -- **分代收集**：虽然G1可以不需要其他收集器配合就能独立管理整个GC堆，但是还是保留了分代的概念。 -- **空间整合**：与CMS的“标记--清理”算法不同，G1从整体来看是基于“标记整理”算法实现的收集器；从局部上来看是基于“复制”算法实现的。 -- **可预测的停顿**：这是G1相对于CMS的另一个大优势，降低停顿时间是G1 和 CMS 共同的关注点，但G1 除了追求低停顿外，还能建立可预测的停顿时间模型，能让使用者明确指定在一个长度为M毫秒的时间片段内。 - - -G1收集器的运作大致分为以下几个步骤： - -- **初始标记** -- **并发标记** -- **最终标记** -- **筛选回收** - - -**G1收集器在后台维护了一个优先列表，每次根据允许的收集时间，优先选择回收价值最大的Region(这也就是它的名字Garbage-First的由来)**。这种使用Region划分内存空间以及有优先级的区域回收方式，保证了GF收集器在有限时间内可以尽可能高的收集效率（把内存化整为零）。 - - - - - -参考： - -- 《深入理解Java虚拟机：JVM高级特性与最佳实践（第二版》 -- https://my.oschina.net/hosee/blog/644618 - - - - - - - - - - - - - diff --git "a/Java\347\233\270\345\205\263/\350\256\276\350\256\241\346\250\241\345\274\217.md" "b/Java\347\233\270\345\205\263/\350\256\276\350\256\241\346\250\241\345\274\217.md" deleted file mode 100644 index e3e9586052910cebcd161aa4922ab6a643946d09..0000000000000000000000000000000000000000 --- "a/Java\347\233\270\345\205\263/\350\256\276\350\256\241\346\250\241\345\274\217.md" +++ /dev/null @@ -1,84 +0,0 @@ -# Java 设计模式 - -下面是自己学习设计模式的时候做的总结，有些是自己的原创文章，有些是网上写的比较好的文章，保存下来细细消化吧！ - -**系列文章推荐：** - -## 创建型模式 - -### 创建型模式概述 - -- 创建型模式(Creational Pattern)对类的实例化过程进行了抽象，能够将软件模块中对象的创建和对象的使用分离。为了使软件的结构更加清晰，外界对于这些对象只需要知道它们共同的接口，而不清楚其具体的实现细节，使整个系统的设计更加符合单一职责原则。 -- 创建型模式在创建什么(What)，由谁创建(Who)，何时创建(When)等方面都为软件设计者提供了尽可能大的灵活性。创建型模式隐藏了类的实例的创建细节，通过隐藏对象如何被创建和组合在一起达到使整个系统独立的目的。 - -![创建型模式](https://user-gold-cdn.xitu.io/2018/6/16/1640641afcb7559b?w=491&h=241&f=png&s=51443) - -### 常见创建型模式详解 - -- **单例模式：** [深入理解单例模式——只有一个实例](https://blog.csdn.net/qq_34337272/article/details/80455972) -- **工厂模式：** [深入理解工厂模式——由对象工厂生成对象](https://blog.csdn.net/qq_34337272/article/details/80472071) -- **建造者模式：** [深入理解建造者模式 ——组装复杂的实例](http://blog.csdn.net/qq_34337272/article/details/80540059) -- **原型模式：** [深入理解原型模式 ——通过复制生成实例](https://blog.csdn.net/qq_34337272/article/details/80706444) - -## 结构型模式 - -### 结构型模式概述 - -- **结构型模式(Structural Pattern)：** 描述如何将类或者对象结合在一起形成更大的结构，就像搭积木，可以通过简单积木的组合形成复杂的、功能更为强大的结构 -![结构型模式(Structural Pattern)](https://user-gold-cdn.xitu.io/2018/6/16/164064d6b3c205e3?w=719&h=233&f=png&s=270293) -- **结构型模式可以分为类结构型模式和对象结构型模式：** - - 类结构型模式关心类的组合，由多个类可以组合成一个更大的系统，在类结构型模式中一般只存在继承关系和实现关系。 - - 对象结构型模式关心类与对象的组合，通过关联关系使得在一个类中定义另一个类的实例对象，然后通过该对象调用其方法。根据“合成复用原则”，在系统中尽量使用关联关系来替代继承关系，因此大部分结构型模式都是对象结构型模式。 - -![结构型模式](https://user-gold-cdn.xitu.io/2018/6/16/1640655459d766d2?w=378&h=266&f=png&s=59652) - -### 常见结构型模式详解 - -- **适配器模式：** - - [深入理解适配器模式——加个“适配器”以便于复用](https://segmentfault.com/a/1190000011856448) - - [适配器模式原理及实例介绍-IBM](https://www.ibm.com/developerworks/cn/java/j-lo-adapter-pattern/index.html) -- **桥接模式：** [设计模式笔记16：桥接模式(Bridge Pattern)](https://blog.csdn.net/yangzl2008/article/details/7670996) -- **组合模式：** [大话设计模式—组合模式](https://blog.csdn.net/lmb55/article/details/51039781) -- **装饰模式：** [java模式—装饰者模式](https://www.cnblogs.com/chenxing818/p/4705919.html)、[Java设计模式-装饰者模式](https://blog.csdn.net/cauchyweierstrass/article/details/48240147) -- **外观模式：** [java设计模式之外观模式（门面模式）](https://www.cnblogs.com/lthIU/p/5860607.html) -- **享元模式：** [享元模式](http://www.jasongj.com/design_pattern/flyweight/) -- **代理模式：** - - [代理模式原理及实例讲解 （IBM出品，很不错）](https://www.ibm.com/developerworks/cn/java/j-lo-proxy-pattern/index.html) - - [轻松学，Java 中的代理模式及动态代理](https://blog.csdn.net/briblue/article/details/73928350) - - [Java代理模式及其应用](https://blog.csdn.net/justloveyou_/article/details/74203025) - - -## 行为型模式 - -### 行为型模式概述 - -- 行为型模式(Behavioral Pattern)是对在不同的对象之间划分责任和算法的抽象化。 -- 行为型模式不仅仅关注类和对象的结构，而且重点关注它们之间的相互作用。 -- 通过行为型模式，可以更加清晰地划分类与对象的职责，并研究系统在运行时实例对象之间的交互。在系统运行时，对象并不是孤立的，它们可以通过相互通信与协作完成某些复杂功能，一个对象在运行时也将影响到其他对象的运行。 - -**行为型模式分为类行为型模式和对象行为型模式两种：** - -- **类行为型模式：** 类的行为型模式使用继承关系在几个类之间分配行为，类行为型模式主要通过多态等方式来分配父类与子类的职责。 -- **对象行为型模式：** 对象的行为型模式则使用对象的聚合关联关系来分配行为，对象行为型模式主要是通过对象关联等方式来分配两个或多个类的职责。根据“合成复用原则”，系统中要尽量使用关联关系来取代继承关系，因此大部分行为型设计模式都属于对象行为型设计模式。 - -![行为型模式](https://user-gold-cdn.xitu.io/2018/6/28/164467dd92c6172c?w=453&h=269&f=png&s=63270) - -- **职责链模式：** -- [Java设计模式之责任链模式、职责链模式](https://blog.csdn.net/jason0539/article/details/45091639) -- [责任链模式实现的三种方式](https://www.cnblogs.com/lizo/p/7503862.html) -- **命令模式：** 在软件设计中，我们经常需要向某些对象发送请求，但是并不知道请求的接收者是谁，也不知道被请求的操作是哪个，我们只需在程序运行时指定具体的请求接收者即可，此时，可以使用命令模式来进行设计，使得请求发送者与请求接收者消除彼此之间的耦合，让对象之间的调用关系更加灵活。命令模式可以对发送者和接收者完全解耦，发送者与接收者之间没有直接引用关系，发送请求的对象只需要知道如何发送请求，而不必知道如何完成请求。这就是命令模式的模式动机。 -- **解释器模式：** -- **迭代器模式：** -- **中介者模式：** -- **备忘录模式：** -- **观察者模式：** -- **状态模式：** -- **策略模式：** - -策略模式作为设计原则中开闭原则最典型的体现，也是经常使用的。下面这篇博客介绍了策略模式一般的组成部分和概念，并用了一个小demo去说明了策略模式的应用。 - -[java设计模式之策略模式](https://blog.csdn.net/zlj1217/article/details/81230077) - -- **模板方法模式：** -- **访问者模式：** - diff --git "a/Java\347\233\270\345\205\263/\350\277\231\345\207\240\351\201\223Java\351\233\206\345\220\210\346\241\206\346\236\266\351\235\242\350\257\225\351\242\230\345\207\240\344\271\216\345\277\205\351\227\256.md" "b/Java\347\233\270\345\205\263/\350\277\231\345\207\240\351\201\223Java\351\233\206\345\220\210\346\241\206\346\236\266\351\235\242\350\257\225\351\242\230\345\207\240\344\271\216\345\277\205\351\227\256.md" deleted file mode 100644 index 18d276c4e22a416c86515aec7d522f206f95c9ee..0000000000000000000000000000000000000000 --- "a/Java\347\233\270\345\205\263/\350\277\231\345\207\240\351\201\223Java\351\233\206\345\220\210\346\241\206\346\236\266\351\235\242\350\257\225\351\242\230\345\207\240\344\271\216\345\277\205\351\227\256.md" +++ /dev/null @@ -1,288 +0,0 @@ - - - - -- [Arraylist 与 LinkedList 异同](#arraylist-与-linkedlist-异同) - - [补充：数据结构基础之双向链表](#补充：数据结构基础之双向链表) -- [ArrayList 与 Vector 区别](#arraylist-与-vector-区别) -- [HashMap的底层实现](#hashmap的底层实现) - - [JDK1.8之前](#jdk18之前) - - [JDK1.8之后](#jdk18之后) -- [HashMap 和 Hashtable 的区别](#hashmap-和-hashtable-的区别) -- [HashMap 的长度为什么是2的幂次方](#hashmap-的长度为什么是2的幂次方) -- [HashMap 多线程操作导致死循环问题](#hashmap-多线程操作导致死循环问题) -- [HashSet 和 HashMap 区别](#hashset-和-hashmap-区别) -- [ConcurrentHashMap 和 Hashtable 的区别](#concurrenthashmap-和-hashtable-的区别) -- [ConcurrentHashMap线程安全的具体实现方式/底层具体实现](#concurrenthashmap线程安全的具体实现方式底层具体实现) - - [JDK1.7（上面有示意图）](#jdk17（上面有示意图）) - - [JDK1.8 （上面有示意图）](#jdk18-（上面有示意图）) -- [集合框架底层数据结构总结](#集合框架底层数据结构总结) - - [Collection](#collection) - - [1. List](#1-list) - - [2. Set](#2-set) - - [Map](#map) - - [推荐阅读：](#推荐阅读：) - - - -## Arraylist 与 LinkedList 异同 - -- **1. 是否保证线程安全：** ArrayList 和 LinkedList 都是不同步的，也就是不保证线程安全； -- **2. 底层数据结构：** Arraylist 底层使用的是Object数组；LinkedList 底层使用的是双向链表数据结构（JDK1.6之前为循环链表，JDK1.7取消了循环。注意双向链表和双向循环链表的区别：）； 详细可阅读[JDK1.7-LinkedList循环链表优化](https://www.cnblogs.com/xingele0917/p/3696593.html) -- **3. 插入和删除是否受元素位置的影响：** ① **ArrayList 采用数组存储，所以插入和删除元素的时间复杂度受元素位置的影响。** 比如：执行`add(E e) `方法的时候， ArrayList 会默认在将指定的元素追加到此列表的末尾，这种情况时间复杂度就是O(1)。但是如果要在指定位置 i 插入和删除元素的话（`add(int index, E element) `）时间复杂度就为 O(n-i)。因为在进行上述操作的时候集合中第 i 和第 i 个元素之后的(n-i)个元素都要执行向后位/向前移一位的操作。 ② **LinkedList 采用链表存储，所以插入，删除元素时间复杂度不受元素位置的影响，都是近似 O（1）而数组为近似 O（n）。** -- **4. 是否支持快速随机访问：** LinkedList 不支持高效的随机元素访问，而 ArrayList 支持。快速随机访问就是通过元素的序号快速获取元素对象(对应于`get(int index) `方法)。 -- **5. 内存空间占用：** ArrayList的空 间浪费主要体现在在list列表的结尾会预留一定的容量空间，而LinkedList的空间花费则体现在它的每一个元素都需要消耗比ArrayList更多的空间（因为要存放直接后继和直接前驱以及数据）。 -- **6.补充内容:RandomAccess接口** - -```java -public interface RandomAccess { -} -``` - -查看源码我们发现实际上 RandomAccess 接口中什么都没有定义。所以，在我看来 RandomAccess 接口不过是一个标识罢了。标识什么？ 标识实现这个接口的类具有随机访问功能。 - -在binarySearch（）方法中，它要判断传入的list 是否RamdomAccess的实例，如果是，调用indexedBinarySearch（）方法，如果不是，那么调用iteratorBinarySearch（）方法 - -```java - public static - int binarySearch(List> list, T key) { - if (list instanceof RandomAccess || list.size()>>:无符号右移，忽略符号位，空位都以0补齐 - return (key == null) ? 0 : (h = key.hashCode()) ^ (h >>> 16); - } - ``` -对比一下 JDK1.7的 HashMap 的 hash 方法源码. - -```java -static int hash(int h) { - // This function ensures that hashCodes that differ only by - // constant multiples at each bit position have a bounded - // number of collisions (approximately 8 at default load factor). - - h ^= (h >>> 20) ^ (h >>> 12); - return h ^ (h >>> 7) ^ (h >>> 4); -} -``` - -相比于 JDK1.8 的 hash 方法 ，JDK 1.7 的 hash 方法的性能会稍差一点点，因为毕竟扰动了 4 次。 - -所谓 **“拉链法”** 就是：将链表和数组相结合。也就是说创建一个链表数组，数组中每一格就是一个链表。若遇到哈希冲突，则将冲突的值加到链表中即可。 - - - -![jdk1.8之前的内部结构](https://user-gold-cdn.xitu.io/2018/3/20/16240dbcc303d872?w=348&h=427&f=png&s=10991) - - -### JDK1.8之后 -相比于之前的版本， JDK1.8之后在解决哈希冲突时有了较大的变化，当链表长度大于阈值（默认为8）时，将链表转化为红黑树，以减少搜索时间。 - -![JDK1.8之后的HashMap底层数据结构](http://my-blog-to-use.oss-cn-beijing.aliyuncs.com/18-8-22/67233764.jpg) - ->TreeMap、TreeSet以及JDK1.8之后的HashMap底层都用到了红黑树。红黑树就是为了解决二叉查找树的缺陷，因为二叉查找树在某些情况下会退化成一个线性结构。 - -**推荐阅读：** - -- 《Java 8系列之重新认识HashMap》 ：[https://zhuanlan.zhihu.com/p/21673805](https://zhuanlan.zhihu.com/p/21673805) - -## HashMap 和 Hashtable 的区别 - -1. **线程是否安全：** HashMap 是非线程安全的，HashTable 是线程安全的；HashTable 内部的方法基本都经过 `synchronized` 修饰。（如果你要保证线程安全的话就使用 ConcurrentHashMap 吧！）； -2. **效率：** 因为线程安全的问题，HashMap 要比 HashTable 效率高一点。另外，HashTable 基本被淘汰，不要在代码中使用它； -3. **对Null key 和Null value的支持：** HashMap 中，null 可以作为键，这样的键只有一个，可以有一个或多个键所对应的值为 null。。但是在 HashTable 中 put 进的键值只要有一个 null，直接抛出 NullPointerException。 -4. **初始容量大小和每次扩充容量大小的不同 ：** ①创建时如果不指定容量初始值，Hashtable 默认的初始大小为11，之后每次扩充，容量变为原来的2n+1。HashMap 默认的初始化大小为16。之后每次扩充，容量变为原来的2倍。②创建时如果给定了容量初始值，那么 Hashtable 会直接使用你给定的大小，而 HashMap 会将其扩充为2的幂次方大小（HashMap 中的`tableSizeFor()`方法保证，下面给出了源代码）。也就是说 HashMap 总是使用2的幂作为哈希表的大小,后面会介绍到为什么是2的幂次方。 -5. **底层数据结构：** JDK1.8 以后的 HashMap 在解决哈希冲突时有了较大的变化，当链表长度大于阈值（默认为8）时，将链表转化为红黑树，以减少搜索时间。Hashtable 没有这样的机制。 - -**HasMap 中带有初始容量的构造函数：** - -```java - public HashMap(int initialCapacity, float loadFactor) { - if (initialCapacity < 0) - throw new IllegalArgumentException("Illegal initial capacity: " + - initialCapacity); - if (initialCapacity > MAXIMUM_CAPACITY) - initialCapacity = MAXIMUM_CAPACITY; - if (loadFactor <= 0 || Float.isNaN(loadFactor)) - throw new IllegalArgumentException("Illegal load factor: " + - loadFactor); - this.loadFactor = loadFactor; - this.threshold = tableSizeFor(initialCapacity); - } - public HashMap(int initialCapacity) { - this(initialCapacity, DEFAULT_LOAD_FACTOR); - } -``` - -下面这个方法保证了 HashMap 总是使用2的幂作为哈希表的大小。 - -```java - /** - * Returns a power of two size for the given target capacity. - */ - static final int tableSizeFor(int cap) { - int n = cap - 1; - n |= n >>> 1; - n |= n >>> 2; - n |= n >>> 4; - n |= n >>> 8; - n |= n >>> 16; - return (n < 0) ? 1 : (n >= MAXIMUM_CAPACITY) ? MAXIMUM_CAPACITY : n + 1; - } -``` - -## HashMap 的长度为什么是2的幂次方 - -为了能让 HashMap 存取高效，尽量较少碰撞，也就是要尽量把数据分配均匀。我们上面也讲到了过了，Hash 值的范围值-2147483648到2147483647，前后加起来大概40亿的映射空间，只要哈希函数映射得比较均匀松散，一般应用是很难出现碰撞的。但问题是一个40亿长度的数组，内存是放不下的。所以这个散列值是不能直接拿来用的。用之前还要先做对数组的长度取模运算，得到的余数才能用来要存放的位置也就是对应的数组下标。这个数组下标的计算方法是“ `(n - 1) & hash` ”。（n代表数组长度）。这也就解释了 HashMap 的长度为什么是2的幂次方。 - -**这个算法应该如何设计呢？** - -我们首先可能会想到采用%取余的操作来实现。但是，重点来了：**“取余(%)操作中如果除数是2的幂次则等价于与其除数减一的与(&)操作（也就是说 hash%length==hash&(length-1)的前提是 length 是2的 n 次方；）。”** 并且 **采用二进制位操作 &，相对于%能够提高运算效率，这就解释了 HashMap 的长度为什么是2的幂次方。** - -## HashMap 多线程操作导致死循环问题 - -在多线程下，进行 put 操作会导致 HashMap 死循环，原因在于 HashMap 的扩容 resize()方法。由于扩容是新建一个数组，复制原数据到数组。由于数组下标挂有链表，所以需要复制链表，但是多线程操作有可能导致环形链表。复制链表过程如下: -以下模拟2个线程同时扩容。假设，当前 HashMap 的空间为2（临界值为1），hashcode 分别为 0 和 1，在散列地址 0 处有元素 A 和 B，这时候要添加元素 C，C 经过 hash 运算，得到散列地址为 1，这时候由于超过了临界值，空间不够，需要调用 resize 方法进行扩容，那么在多线程条件下，会出现条件竞争，模拟过程如下： - - 线程一：读取到当前的 HashMap 情况，在准备扩容时，线程二介入 - -![](https://note.youdao.com/yws/public/resource/e4cec65883d9fdc24effba57dcfa5241/xmlnote/41aed567e3419e1314bfbf689e3255a2/192) - -线程二：读取 HashMap，进行扩容 - -![](https://note.youdao.com/yws/public/resource/e4cec65883d9fdc24effba57dcfa5241/xmlnote/f44624419c0a49686fb12aa37527ee65/191) - -线程一：继续执行 - -![](https://note.youdao.com/yws/public/resource/e4cec65883d9fdc24effba57dcfa5241/xmlnote/79424b2bf4a89902a9e85c64600268e4/193) - -这个过程为，先将 A 复制到新的 hash 表中，然后接着复制 B 到链头（A 的前边：B.next=A），本来 B.next=null，到此也就结束了（跟线程二一样的过程），但是，由于线程二扩容的原因，将 B.next=A，所以，这里继续复制A，让 A.next=B，由此，环形链表出现：B.next=A; A.next=B - -**注意：jdk1.8已经解决了死循环的问题。**详细信息请阅读[jdk1.8 hashmap多线程put不会造成死循环](https://blog.csdn.net/qq_27007251/article/details/71403647) - - -## HashSet 和 HashMap 区别 - -如果你看过 HashSet 源码的话就应该知道：HashSet 底层就是基于 HashMap 实现的。（HashSet 的源码非常非常少，因为除了 clone() 方法、writeObject()方法、readObject()方法是 HashSet 自己不得不实现之外，其他方法都是直接调用 HashMap 中的方法。） - -![HashSet 和 HashMap 区别](https://user-gold-cdn.xitu.io/2018/3/2/161e717d734f3b23?w=896&h=363&f=jpeg&s=205536) - -## ConcurrentHashMap 和 Hashtable 的区别 - -ConcurrentHashMap 和 Hashtable 的区别主要体现在实现线程安全的方式上不同。 - -- **底层数据结构：** JDK1.7的 ConcurrentHashMap 底层采用 **分段的数组+链表** 实现，JDK1.8 采用的数据结构跟HashMap1.8的结构一样，数组+链表/红黑二叉树。Hashtable 和 JDK1.8 之前的 HashMap 的底层数据结构类似都是采用 **数组+链表** 的形式，数组是 HashMap 的主体，链表则是主要为了解决哈希冲突而存在的； -- **实现线程安全的方式（重要）：** ① **在JDK1.7的时候，ConcurrentHashMap（分段锁）** 对整个桶数组进行了分割分段(Segment)，每一把锁只锁容器其中一部分数据，多线程访问容器里不同数据段的数据，就不会存在锁竞争，提高并发访问率。 **到了 JDK1.8 的时候已经摒弃了Segment的概念，而是直接用 Node 数组+链表+红黑树的数据结构来实现，并发控制使用 synchronized 和 CAS 来操作。（JDK1.6以后 对 synchronized锁做了很多优化）** 整个看起来就像是优化过且线程安全的 HashMap，虽然在JDK1.8中还能看到 Segment 的数据结构，但是已经简化了属性，只是为了兼容旧版本；② **Hashtable(同一把锁)** :使用 synchronized 来保证线程安全，效率非常低下。当一个线程访问同步方法时，其他线程也访问同步方法，可能会进入阻塞或轮询状态，如使用 put 添加元素，另一个线程不能使用 put 添加元素，也不能使用 get，竞争会越来越激烈效率越低。 - -**两者的对比图：** - -图片来源：http://www.cnblogs.com/chengxiao/p/6842045.html - -HashTable: -![](http://my-blog-to-use.oss-cn-beijing.aliyuncs.com/18-8-22/50656681.jpg) - -JDK1.7的ConcurrentHashMap： -![](http://my-blog-to-use.oss-cn-beijing.aliyuncs.com/18-8-22/33120488.jpg) -JDK1.8的ConcurrentHashMap（TreeBin: 红黑二叉树节点 -Node: 链表节点）： -![](http://my-blog-to-use.oss-cn-beijing.aliyuncs.com/18-8-22/97739220.jpg) - -## ConcurrentHashMap线程安全的具体实现方式/底层具体实现 - -### JDK1.7（上面有示意图） - -首先将数据分为一段一段的存储，然后给每一段数据配一把锁，当一个线程占用锁访问其中一个段数据时，其他段的数据也能被其他线程访问。 - -**ConcurrentHashMap 是由 Segment 数组结构和 HashEntry 数组结构组成**。 - -Segment 实现了 ReentrantLock,所以 Segment 是一种可重入锁，扮演锁的角色。HashEntry 用于存储键值对数据。 - -```java -static class Segment extends ReentrantLock implements Serializable { -} -``` - -一个 ConcurrentHashMap 里包含一个 Segment 数组。Segment 的结构和HashMap类似，是一种数组和链表结构，一个 Segment 包含一个 HashEntry 数组，每个 HashEntry 是一个链表结构的元素，每个 Segment 守护着一个HashEntry数组里的元素，当对 HashEntry 数组的数据进行修改时，必须首先获得对应的 Segment的锁。 - -### JDK1.8 （上面有示意图） - -ConcurrentHashMap取消了Segment分段锁，采用CAS和synchronized来保证并发安全。数据结构跟HashMap1.8的结构类似，数组+链表/红黑二叉树。 - -synchronized只锁定当前链表或红黑二叉树的首节点，这样只要hash不冲突，就不会产生并发，效率又提升N倍。 - - - -## 集合框架底层数据结构总结 -### Collection - -#### 1. List - - **Arraylist：** Object数组 - - **Vector：** Object数组 - - **LinkedList：** 双向链表(JDK1.6之前为循环链表，JDK1.7取消了循环) - 详细可阅读[JDK1.7-LinkedList循环链表优化](https://www.cnblogs.com/xingele0917/p/3696593.html) - -#### 2. Set - - **HashSet（无序，唯一）:** 基于 HashMap 实现的，底层采用 HashMap 来保存元素 - - **LinkedHashSet：** LinkedHashSet 继承与 HashSet，并且其内部是通过 LinkedHashMap 来实现的。有点类似于我们之前说的LinkedHashMap 其内部是基于 Hashmap 实现一样，不过还是有一点点区别的。 - - **TreeSet（有序，唯一）：** 红黑树(自平衡的排序二叉树。) - -### Map - - **HashMap：** JDK1.8之前HashMap由数组+链表组成的，数组是HashMap的主体，链表则是主要为了解决哈希冲突而存在的（“拉链法”解决冲突）.JDK1.8以后在解决哈希冲突时有了较大的变化，当链表长度大于阈值（默认为8）时，将链表转化为红黑树，以减少搜索时间 - - **LinkedHashMap:** LinkedHashMap 继承自 HashMap，所以它的底层仍然是基于拉链式散列结构即由数组和链表或红黑树组成。另外，LinkedHashMap 在上面结构的基础上，增加了一条双向链表，使得上面的结构可以保持键值对的插入顺序。同时通过对链表进行相应的操作，实现了访问顺序相关逻辑。详细可以查看：[《LinkedHashMap 源码详细分析（JDK1.8）》](https://www.imooc.com/article/22931) - - **HashTable:** 数组+链表组成的，数组是 HashMap 的主体，链表则是主要为了解决哈希冲突而存在的 - - **TreeMap:** 红黑树（自平衡的排序二叉树） - - - - -### 推荐阅读： - -- [jdk1.8中ConcurrentHashMap的实现原理](https://blog.csdn.net/fjse51/article/details/55260493) -- [HashMap? ConcurrentHashMap? 相信看完这篇没人能难住你！](https://crossoverjie.top/2018/07/23/java-senior/ConcurrentHashMap/) -- [HASHMAP、HASHTABLE、CONCURRENTHASHMAP的原理与区别](http://www.yuanrengu.com/index.php/2017-01-17.html) -- [ConcurrentHashMap实现原理及源码分析](https://www.cnblogs.com/chengxiao/p/6842045.html) -- [java-并发-ConcurrentHashMap高并发机制-jdk1.8](https://blog.csdn.net/jianghuxiaojin/article/details/52006118#commentBox) diff --git a/README.en.md b/README.en.md new file mode 100644 index 0000000000000000000000000000000000000000..91db0a4f3ac2c77a05496255fe345bfa6bd80129 --- /dev/null +++ b/README.en.md @@ -0,0 +1,418 @@ +## 👏 MAJOR UPDATE!!! Serious! + +Read in other languages: [Mandarin](https://github.com/Snailclimb/JavaGuide/blob/main/README.md) +- JavaGuide Read online version（New Version，Recommended👍：https://javaguide.cn/ +- JavaGuide Online reading version (old version, some links are no longer accessible): https://snailclimb.gitee.io/javaguide/#/ +- [JavaGuide Interview Blitz Edition] PDF Version Download (https://mp.weixin.qq.com/s?__biz=Mzg2OTA0Njk0OA==&mid=100029614&idx=1&sn=62993c5cf10265cb7018db7f1ec67250&chksm=4ea1fb6579d67273499b7243641d4ef372decd08047bfbb6dfb5843ef81c7ccba209086cf345#rd) + + + + +> 1. **Introduction**: For an introduction to the JavaGuide, see: [Some notes on the JavaGuide](https://www.yuque.com/snailclimb/dr6cvl/mr44yt) 。 +> 2. **Contribution Guide** : You are welcome to participate in [the maintenance of JavaGuide](https://github.com/Snailclimb/JavaGuide/issues/1235), it's a very rewarding thing to do. +> 3. **PDF Version** : [JavaGuide Interview Blitz Edition PDF Version](https://mp.weixin.qq.com/s?__biz=Mzg2OTA0Njk0OA==&mid=100029614&idx=1&sn=62993c5cf10265cb7018db7f1ec67250&chksm=4ea1fb6579d67273499b7243641d4ef372decd08047bfbb6dfb5843ef81c7ccba209086cf345#rd) 。 +> 4. **Illustrated Computer Fundamentals** : [Illustrated Computer Fundamentals PDF Download](https://mp.weixin.qq.com/s?__biz=Mzg2OTA0Njk0OA==&mid=100021725&idx=1&sn=2db9664ca25363139a81691043e9fd8f&chksm=4ea19a1679d61300d8990f7e43bfc7f476577a81b712cf0f9c6f6552a8b219bc081efddb5c54#rd) 。 +> 5. **Planet of Knowledge** : Resume guide/Java learning/Interview guide/Interview booklet. You are welcome to join [My Knowledge Planet](https://www.yuque.com/docs/share/8a30ffb5-83f3-40f9-baf9-38de68b906dc) 。 +> 6. **Interview Special Edition** : For those who are preparing for the interview, you can consider the interview special edition: [Java Interview Advanced Guide].(https://www.yuque.com/docs/share/f37fc804-bfe6-4b0d-b373-9c462188fec7) (Very high quality, built specifically for interviews, free for planet users) +> 7. **Reprint Instructions**: All the following articles are my (Guide) original if not stated at the beginning of the text, reproduced at the beginning of the text to indicate the source, if found malicious plagiarism / transport, will use legal weapons to defend their rights. Let's maintain a good technical creation environment together! ⛽️ + +

+ + + +

+

+ 阅读 + stars + forks + issues +

+

Recommended

+ + + + + + +
+ + +
+ + +## Java + +### Basis + +**Knowledge points/interview questions**: (Must see:+1: ): + +- [Java Basics Knowledge Points/Interview Questions Summary(1)](docs/java/basis/java-basic-questions-01.md) +- [Java Basics Knowledge Points/Interview Questions Summary(2)](docs/java/basis/java-basic-questions-01.md) +- [Java Basics Knowledge Points/Interview Questions Summary(3)](docs/java/basis/java-basic-questions-01.md) + +**Important Knowledge Points Explained:** + +- [Why only value passing in Java?](docs/java/basis/why-thereis-only-value-passing-in-java.md) +- [What is the reflection mechanism? What are the application scenarios of reflection mechanism?](docs/java/basis/反射机制详解.md) +- (docs/java/basis/proxy-model-detail.md) [proxy-model-detail: static proxy + JDK/CGLIB dynamic proxy practice](docs/java/basis/代理模式详解.md) +- [What are the common IO models and what is the difference between BIO, NIO, AIO in Java?](docs/java/basis/io模型详解.md) +- [BigDecimal solve floating point problem](docs/java/basis/bigdecimal.md) + +### Collection + +1. **[Java collection FAQ summary](docs/java/collection/java集合框架基础知识&面试题总结.md)** (must see :+1:) +2. [Summary of considerations for using Java containers](docs/java/collection/java集合使用注意事项.md) +3. **source code analysis** : [ArrayList source code + expansion mechanism analysis](docs/java/collection/arraylist-source-code.md), +[HashMap(JDK1.8) source code + underlying data structure analysis](docs/java/collection/ hashmap-source-code.md), +[ConcurrentHashMap source code + underlying data structure analysis](docs/java/collection/concurrent-hash-map-source-code.md) + +### Concurrency + +**Knowledge/Interview Questions:** (Must see :+1:) + +1. **[Java concurrency basic common interview questions summary](docs/java/concurrent/java并发基础常见面试题总结.md)** +2. **[Java concurrency advanced common interview questions summary](docs/java/concurrent/java并发进阶常见面试题总结.md)** + +**Important Knowledge Points Explained:** + +1. **Thread pool**: [Java thread pool learning summary](./docs/java/concurrent/java-thread-pool-summary.md), [Java thread pooling best practices](./docs/java/concurrent/java-thread-pool-best-practices.md) +2. [ThreadLocal keyword resolution](docs/java/concurrent/threadlocal.md) +3. [Java concurrency container summary](docs/java/concurrent/java-concurrent-collections.md) +4. [Atomic atomic class summary](docs/java/concurrent/atomic-classes.md) +5. [AQS principle and AQS synchronization component summary](docs/java/concurrent/aqs.md) +6. [Getting Started with CompletableFuture](docs/java/concurrent/completablefuture-intro.md) + +### JVM (must see :+1:) + +This part of JVM mainly refers to [JVM Virtual Machine Specification-Java8 ](https://docs.oracle.com/javase/specs/jvms/se8/html/index.html) and Mr. Zhou's [In-depth Understanding of Java Virtual Machine (3rd Edition)](https://book.douban.com/subject/34907497/) (Highly recommended to read more than once!) . + +1. **[Java Memory Regions](https://javaguide.cn/java/jvm/jvm-garbage-collection/)** +2. **[JVM Garbage Collection](https://javaguide.cn/java/jvm/jvm-garbage-collection/)** +3. [JDK monitoring and troubleshooting tools](https://javaguide.cn/java/jvm/jdk-monitoring-and-troubleshooting-tools/) +4. [Class file structure](https://javaguide.cn/java/jvm/class-file-structure/) +5. **[Class loading process](https://javaguide.cn/java/jvm/class-loading-process/)** +6. [Class loader](https://javaguide.cn/java/jvm/classloader/) +7. **[[To be completed] Summary of the most important JVM parameters (half of the translation is perfected)](https://javaguide.cn/java/jvm/jvm-parameters-intro/)** +8. **[[Extra Meal] The Big White Word takes you through the JVM](https://javaguide.cn/java/jvm/jvm-intro/)** + +### New features + +1. **Java 8**: [Java 8 new features summary](docs/java/new-features/Java8新特性总结.md), [Java8 common new features summary](docs/java/new-features/java8-common-new-features.md) +2. **Java9~Java15** : [An article to take you through the important new features of JDK9~15!](./docs/java/new-features/java新特性总结.md) + +### Tips + +1. [JAD decompile](docs/java/tips/JAD反编译tricks.md) +2. [Handy for locating common Java performance problems](./docs/java/tips/locate-performance-problems/手把手教你定位常见Java性能问题.md) + + +## Computer Basics + +👉 **[Illustrated Computer Fundamentals PDF Download](https://mp.weixin.qq.com/s?__biz=Mzg2OTA0Njk0OA==&mid=100021725&idx=1&sn=2db9664ca25363139a81691043e9fd8f&chksm=4ea19a1679d61300d8990f7e43bfc7f476577a81b712cf0f9c6f6552a8b219bc081efddb5c54#rd)** . + +### Operating system + +1. [OS FAQ summary!](docs/cs-basics/operating-system/操作系统常见面试题&知识点总结.md) +2. [Backend programmer essential Linux basics summary](docs/cs-basics/operating-system/linux-intro.md) +3. [Introduction to Shell Programming](docs/cs-basics/operating-system/shell-intro.md) + +### Networking + +1. [Computer Network Common Interview Questions](docs/cs-basics/network/计算机网络常见面试题.md) +2. [Xie Xiren teacher's "computer network" content summary](docs/cs-basics/network/谢希仁老师的《计算机网络》内容总结.md) + +### Data Structures + +**Diagrammatic Data Structures :** + +1. [Linear data structure :array, chain table, stack, queue](docs/cs-basics/data-structure/线性数据结构.md) +2. [diagram](docs/cs-basics/data-structure/图.md) +3. [heap](docs/cs-basics/data-structure/堆.md) +4. [tree](docs/cs-basics/data-structure/树.md) : focus on [red-black-tree](docs/cs-basics/data-structure/红黑树.md), B-, B+, B* tree, LSM tree + +Other common data structures : 1. + +1. [Bloom filter](docs/cs-basics/data-structure/bloom-filter.md) + + +### Algorithm + +This part of the algorithm is very important, if you do not know how to learn the algorithm, you can look at what I wrote. + +- [Recommended Algorithm Learning Books + Resources](https://www.zhihu.com/question/323359308/answer/1545320858) 。 +- [如何刷Leetcode?](https://www.zhihu.com/question/31092580/answer/1534887374) + +**Summary of common algorithm problems** : + +- [Several Common String Algorithm Questions Summarized ](docs/cs-basics/algorithms/几道常见的字符串算法题.md) +- [Summary of several common algorithm problems of the chain table ](docs/cs-basics/algorithms/几道常见的链表算法题.md) +- [Link offer some programming questions](docs/cs-basics/algorithms/剑指offer部分编程题.md) + +In addition，[GeeksforGeeks]( https://www.geeksforgeeks.org/fundamentals-of-algorithms/) This site summarizes the common algorithms, which are more comprehensive and systematic. + +## Database + +### MySQL + +**Summary:** + +1. [Database Basics Summary](docs/database/数据库基础知识.md) +2. **[MySQL Knowledge Summary](docs/database/mysql/mysql知识点&面试题总结.md)** (Must see:+1:) +4. [One Thousand Lines MySQL Study Notes](docs/database/mysql/a-thousand-lines-of-mysql-study-notes.md) +5. [MySQL High Performance Optimization Specification Recommendations](docs/database/mysql/mysql-high-performance-optimization-specification-recommendations.md) + +**Important knowledge points:** + +1.
+

+ + + +

+

+ 阅读 + stars + forks + issues +

+

+ + + +

+
+ +2. [Transaction isolation level (graphic detail)](docs/database/mysql/transaction-isolation-level.md) +3. [MySQL's Three Major Logs (binlog, redo log and undo log) Explained](docs/database/mysql/mysql-logs.md) +4. [InnoDB storage engine implementation of MVCC](docs/database/mysql/innodb-implementation-of-mvcc.md) +5. [How does a SQL statement get executed in MySQL?](docs/database/mysql/how-sql-executed-in-mysql.md) +6. [Character set details: Why is it not recommended to use utf8 in MySQL?](docs/database/字符集.md) +7. [A little thought on how to store time in the database](docs/database/mysql/some-thoughts-on-database-storage-time.md) + +### Redis + +1. [Redis FAQ Summary](docs/database/redis/redis-questions-01.md) +2. [3 common cache read and write strategies](docs/database/redis/3-commonly-used-cache-read-and-write-strategies.md) + +## Search Engine + +It is used to improve search efficiency and functions similarly to browser search engines. The more common search engines are Elasticsearch (recommended) and Solr. + +## System design + +### System design essential foundation + +#### RESTful API + +When we do back-end development, our main job is to provide APIs for front-end or other back-end services such as APIs for querying user data. a RESTful API is an API built on REST, and it is an API designed to be better used. + +Related reading: [RestFul API Brief Tutorial](docs/system-design/basis/RESTfulAPI.md) + +#### Name + +During programming, you must pay attention to naming. Because a good naming is a comment, others will know what your variable, method or class does as soon as they see your naming! + +Read more about: [Java Naming](docs/system-design/naming.md) 。 + +### Common frameworks + +If you have not touched Java Web development, you can first look at my summary of [J2EE Basics](docs/system-design/J2EE基础知识.md). Although much of the content in this article is now obsolete, it will give you a deeper understanding of Java backend technology development. + +#### Spring/SpringBoot (must see :+1:) + +**Knowledge/Interview Questions:** + +1. **[Spring FAQ Summary](docs/system-design/framework/spring/Spring常见问题总结.md)** +2. **[SpringBoot Getting Started Guide](https://github.com/Snailclimb/springboot-guide)** + +**Important Knowledge Points Explained:** 1. + +1. **[Spring/Spring Boot common annotations summary! Arrangement!](./docs/system-design/framework/spring/Spring&SpringBoot常用注解总结.md)** +2. **[Spring Transaction Summary](docs/system-design/framework/spring/Spring事务总结.md)** +3. [What design patterns are used in Spring?](docs/system-design/framework/spring/Spring设计模式总结.md) +4. **[SpringBoot auto-assembly principle?"](docs/system-design/framework/spring/SpringBoot自动装配原理.md)** + +#### MyBatis + +[MyBatis Common Interview Questions Summary](docs/system-design/framework/mybatis/mybatis-interview.md) + +#### Spring Cloud + +[Getting Started with Spring Cloud in Plain English](docs/system-design/framework/springcloud/springcloud-intro.md) + +### Security + +#### Certification Authorization + +**[Fundamentals of Certification Authorization](docs/system-design/security/basis-of-authority-certification.md)** In this article I will introduce the common concepts of authentication and authorization: **Authentication**, **Authorization** and **Cookie**, **Session**, Token, **OAuth 2**, **SSO**. If you are not clear about these concepts, we suggest you read this article properly. + +- **JWT** : JWT (JSON Web Token) is a form of authentication, where a JWT is essentially a signed piece of data in JSON format. Since it is signed, the recipient can verify its authenticity. Related reading. + - [JWT Pros and Cons Analysis and Solutions to Common Problems](docs/system-design/security/jwt优缺点分析以及常见问题解决方案.md) + - [Demo for beginners to get started with Spring Security With JWT](https://github.com/Snailclimb/spring-security-jwt-guide) + +- **SSO(Single Sign On)**: **SSO(Single Sign On)** that is, single sign on means that a user has the right to access other systems related to him/her by logging into one of the multiple subsystems. For example, after we logged into Jingdong Finance, we also successfully logged into Jingdong Supermarket, Jingdong Home Appliances and other subsystems of Jingdong. Related reading: [**SSO Single Sign-On is enough to read this article! **](docs/system-design/security/sso-intro.md) + +#### Data Desensitization + +Data desensitization means that we deform sensitive information data according to specific rules, for example, we replace certain digits of cell phone numbers and ID numbers with *. + +### Timed tasks + +Recently, some friends asked about timing task related issues. So, I simply wrote an article to summarize some concepts of timed tasks and some common timed task technology options: ["Java Timed Tasks Revealed"].(./docs/system-design/定时任务.md) + +## Distributed + +### CAP theory and BASE theory + +CAP is also the combination of the initials Consistency, Availability, and Partition Tolerance. + +**BASE** is an acronym for **Basically Available**, **Soft-state**, and **Eventually Consistent**. The BASE theory is the result of a trade-off between consistency and availability in the CAP, and is derived from a summary of distributed practices for large-scale Internet systems, evolving from the CAP theorem, which significantly reduces our system requirements. + +Related reading: [CAP Theory and BASE Theory Explained](docs/distributed-system/theorem&algorithm&protocol/cap&base-theorem.md) + +### Paxos algorithm and Raft algorithm + +The **Paxos algorithm** was born in 1990 as a classical algorithm for solving the consistency of distributed systems. However, since the Paxos algorithm was very difficult to understand and implement, there were continuous attempts to simplify it. Only in 2013 was a distributed consistency algorithm born that is easier to understand and implement than the Paxos algorithm - the **Raft algorithm**. + +### RPC + +RPC makes calling remote service calls as easy as calling local methods. + +Dubbo is a home-grown RPC framework , open source by Ali . Related reading. + +- [Dubbo FAQ Summary](docs/distributed-system/rpc/dubbo.md) +- [Why don't we use RPC instead of HTTP directly for calls between services?](docs/distributed-system/rpc/why-use-rpc.md) + +### API gateway + +Gateways are mainly used for request forwarding, security authentication, protocol conversion, and disaster recovery. + +Related reading. + +- [Why gateways? What common gateway systems do you know of?](docs/distributed-system/api-gateway.md) +- [Design and Implementation of Shepherd, a 10 Billion Dollar API Gateway Service](https://tech.meituan.com/2021/05/20/shepherd-api-gateway.html) + +### Distributed IDs + +In complex distributed systems, a large amount of data and messages often need to be uniquely identified. For example, after the data volume is too large, it is often necessary to split the data into libraries and tables, and after the splitting of the libraries and tables, a unique ID is needed to identify a piece of data or a message, and the self-incrementing ID of the database obviously cannot meet the demand. Related reading: [Why distributed id? What are the distributed id generation solutions?](docs/distributed-system/distributed-id.md) + +### Distributed transactions + +** A distributed transaction is one in which the participants of the transaction, the server supporting the transaction, the resource server, and the transaction manager are located on different nodes of different distributed systems. ** + +Simply put, a large operation consists of different small operations that are distributed across different servers and belong to different applications, and the distributed transaction needs to guarantee that all of these small operations either succeed or fail. Essentially, distributed transactions are about ensuring data consistency across different databases. + +### Distributed Orchestration + +**ZooKeeper**. + +> The first two articles may have content overlapping parts, we recommend reading them both. + +1. [[Getting Started] Summary of ZooKeeper-related concepts](docs/distributed-system/分布式协调/zookeeper/zookeeper-intro.md) +2. [[Advanced] Summary of ZooKeeper Related Concepts](docs/distributed-system/分布式协调/zookeeper/zookeeper-plus.md) +3. [[Hands-on] ZooKeeper hands-on](docs/distributed-system/分布式协调/zookeeper/zookeeper-in-action.md) + +## High performance + +### Message Queues + +Message queues are used in distributed systems primarily for decoupling and peak shaving. Related reading: [Message Queues FAQ Summary](docs/high-performance/message-queue/message-queue.md)。 + +1. **RabbitMQ** : [Getting Started with RabbitMQ](docs/high-performance/message-queue/rabbitmq-intro.md) +2. **RocketMQ** : [Getting Started with RocketMQ](docs/high-performance/message-queue/rocketmq-intro)、[A few simple questions and answers for RocketMQ](docs/high-performance/message-queue/rocketmq-questions.md) +3. **Kafka** : [Kafka FAQ Summary](docs/high-performance/message-queue/kafka知识点&面试题总结.md) + +### Read-write separation & split database and split table + +Read-write separation is mainly to separate the database read and write operations on different database nodes. The master server is responsible for writes and the slave server is responsible for reads. Alternatively, one master and one slave or one master and multiple slaves can be used. + +Read-write separation can substantially improve read performance and marginally improve write performance. Therefore, read-write separation is more suitable for scenarios where there are more concurrent read requests from a single machine. + +Library and table separation is to solve the problem of continuous database performance degradation due to the excessive amount of library and table data. + +Common library and table splitting tools are: `sharding-jdbc` (Dangdang), `TSharding` (Mushroom Street), `MyCAT` (based on Cobar), `Cobar` (Alibaba).... We recommend using `sharding-jdbc`. Because, `sharding-jdbc` is a lightweight `Java` framework, served as a `jar` package, no extra O&M work for us, and good compatibility. + +Related reading: [read-write separation & sharding summary of common problems](docs/high-performance/读写分离&分库分表.md) + +### Load Balancing + +Load balancing systems are often used to distribute tasks such as user request processing to multiple servers to improve the performance and reliability of a website, application or database. + +Common load balancing systems include 3 types. + +1. **DNS load balancing**: generally used to achieve geographic level balancing. +2. **Hardware Load Balancing**: Load balancing is achieved through a separate hardware device such as F5 (hardware is usually expensive). +3. **Software load balancing**: Load balancing is achieved by load balancing software such as Nginx. + +## High Availability + +Highly available describes a system that is available most of the time and can provide services to us. High availability means that the system is available even in the event of a hardware failure or system upgrade. + +Related reading: **"[How to design a highly available system? What are the areas to consider?](docs/high-availability/高可用系统设计.md)》** 。 + +### Flow limiting + +Flow limiting considers how to respond to system failures from the perspective of user access pressure. + +The purpose of flow limiting is to limit the frequency of requests received by the server-side interface to prevent the service from hanging. For example, if an interface is limited to 100 requests per second, requests that exceed the limit are either dropped or placed in a queue for processing. Limiting the flow can effectively deal with the excessive number of burst requests. Related reading: [What is flow limiting? What are the flow limiting algorithms?](docs/high-availability/limit-request.md) + +### Downgrading + +Downgrading is the consideration of how to respond to system failures from the perspective of system functional priorities. + +Service degradation refers to the strategic downgrading of some services and pages based on the current business situation and traffic when the server is under pressure, in order to free up server resources to ensure the normal operation of core tasks. + +### Meltdown + +Meltdown and degradation are two concepts that are easily confused and do not have the same meaning. + +Downgrades are intended to deal with failures of the system itself, while meltdowns are intended to deal with failures of external systems or third-party systems on which the current system depends. + +### Queuing + +An alternative type of flow limitation, analogous to real-world queuing. If you've played League of Legends, you'll know that every time there's an event, you have to go through a queue to get into the game. + +### Clustering + +Deploy multiple copies of the same service to avoid single points of failure. + +### Timeout and retry mechanism + +** Once a user's request goes beyond a certain time without a response, the request is ended and an exception is thrown. ** Failure to set a timeout may result in slow response times, or even a buildup of requests that prevents the system from processing them. + +In addition, the number of retries is generally set to 3. More retries will not be beneficial, but will add pressure to the server (some scenarios may not be suitable to use the failure retry mechanism). + +### Disaster recovery design and offsite multi-live + +**Disaster recovery** = disaster recovery + backup. + +- **Backup** : Backup several copies of all important data generated by the system. +- **Disaster Tolerant** : Create two identical systems in offsite locations. When the system in one place suddenly hangs, the whole application system can be switched to the other one so that the system can provide services normally. + +**Offsite Multi-Live** describes the deployment of services offsite and the simultaneous provisioning of services to the outside world. The main difference from traditional disaster recovery design is "multi-live", i.e., all sites are providing services to the public at the same time. Off-site multiplication is designed to deal with unexpected situations such as fires, earthquakes, and other natural or perceived disasters. + +Related reading. + +- [Read this article to understand off-site multi-live](https://mp.weixin.qq.com/s/T6mMDdtTfBuIiEowCpqu6Q) +- [Four steps to build offsite multi-live](https://mp.weixin.qq.com/s/hMD-IS__4JE5_nQhYPYSTg) +- ["Learning Architecture from Scratch" - 28 | Guarantees for Highly Available Business: Offsite Multi-Live Architecture](http://gk.link/a/10pKZ) + +## About the Author + +- [Personal Introduction Q & A](https://javaguide.cn/about-the-author/) +- [I used to be an Internet addict too](https://javaguide.cn/about-the-author/internet-addiction-teenager/) +- [Feelings after one month of onboarding](https://javaguide.cn/about-the-author/feelings-after-one-month-of-induction-training/) +- [Feelings from graduation to six months of employment](https://javaguide.cn/about-the-author/feelings-of-half-a-year-from-graduation-to-entry/) +- [A training institution stole my article into a video also on the B station popular](https://javaguide.cn/about-the-author/my-article-was-stolen-and-made-into-video-and-it-became-popular/) + +## Public + +If you want to follow my updated articles and the dry goods I share in real time, you can follow my public number. + +**《Java Interview Blitz》:** A PDF version of "Java Interview Blitz" derived from this document specifically for interviews [Public](#公众号) Reply back to **"Interview Blitz "** and get it for free! + +![My Public](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/2019-6/167598cd2e17b8ec.png) + +![](https://img-blog.csdnimg.cn/7af97d4dccdb4123a541f336a107ca86.png) + +![](https://p1-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/3a2d826918a44bcbaa8d9272db3ad7d2~tplv-k3u1fbpfcp-watermark.image) diff --git a/README.md b/README.md old mode 100644 new mode 100755 index 8aef7455edfd511a06eb5bc2816ea8b79af29273..cae7595fb1d9673524c86c04fd65faa6bf049993 --- a/README.md +++ b/README.md @@ -1,268 +1,446 @@ -# Java 学习/面试指南 - -
- -
-
- -## 阅读之前必看 - -1. **加群：** 微信交流群添加 [我的微信](#联系我) 后回复关键字“加群”即可入群。 -2. **Java工程师必备学习资源:** 一些Java工程师常用学习资源[公众号](#公众号)后台回复关键字 **“1”** 即可免费无套路获取。 -3. **《Java面试突击》:** 由本文档衍生的专为面试而生的《Java面试突击》V2.0 PDF 版本[公众号](#公众号)后台回复 **"Java面试突击"** 即可免费领取！ -4. **关于贡献者:** 对本仓库提过有价值的 issue 或 pr 的小伙伴将出现在 [Contributor](#Contributor) 这里。 -5. **欢迎投稿：** 由于我个人能力有限，很多知识点我可能没有涉及到，所以你可以对其他知识点进行补充。**对于不错的原创文章我根据你的选择给予现金(50-300)、付费专栏或者任选书籍进行奖励！所以，快提 pr 或者邮件的方式（邮件地址在主页）给我投稿吧！** 当然，我觉得奖励是次要的，最重要的是你可以从自己整理知识点的过程中学习到很多知识。 -4. **【限时福利】** 极客时间[《Java 并发编程面试必备》](#Java并发编程专栏)专栏限时特惠，购买之后的小伙伴加 [我的微信](#联系我) 报上自己的极客时间大名可以找我会把24元返现退给大家，减轻各位学习成本。 - -## 目录 - -* [:coffee: Java](#coffee-java) - * [Java/J2EE 基础](#javaj2ee-基础) - * [Java 集合框架](#java-集合框架) - * [Java 多线程](#java-多线程) - * [Java BIO,NIO,AIO](#java-bionioaio) - * [Java 虚拟机 jvm](#java-虚拟机-jvm) - * [设计模式](#设计模式) -* [:open_file_folder: 数据结构与算法](#open_file_folder-数据结构与算法) - * [数据结构](#数据结构) - * [算法](#算法) -* [:computer: 计算机网络与数据通信](#computer-计算机网络与数据通信) - * [网络相关](#网络相关) - * [数据通信\(RESTful,RPC,消息队列\)总结](#数据通信restfulrpc消息队列总结) -* [:iphone: 操作系统](#iphone-操作系统) - * [Linux相关](#linux相关) -* [:pencil2: 主流框架/软件](#pencil2-主流框架软件) - * [Spring](#spring) - * [ZooKeeper](#zookeeper) -* [:floppy_disk: 数据存储](#floppy_disk-数据存储) - * [MySQL](#mysql) - * [Redis](#redis) -* [:punch: 架构](#punch-架构) -* [:musical_note: 面试必备](#musical_note-面试必备) - * [备战面试](#备战面试) - * [最最最常见的Java面试题总结](#最最最常见的java面试题总结) - * [Java学习/面试开源仓库推荐](#java学习面试开源仓库推荐) -* [:art: 闲谈](#art-闲谈) -* [:envelope: 说明](#envelope-说明) - -## 待办 - -* [ ] Java 8 新特性总结 -* [ ] Java 多线程类别知识重构 -* [x] BIO,NIO,AIO 总结 -* [ ] Netty 总结 -* [ ] 数据结构总结重构 - -## :coffee: Java - -### Java/J2EE 基础 - -* [Java 基础知识回顾](https://github.com/Snailclimb/Java-Guide/blob/master/Java相关/Java基础知识.md) -* [J2EE 基础知识回顾](https://github.com/Snailclimb/Java-Guide/blob/master/Java相关/J2EE基础知识.md) -* [Java常见关键字总结：static、final、this、super](https://github.com/Snailclimb/Java-Guide/blob/master/Java相关/final、static、this、super.md) - - -### Java 集合框架 - -* [这几道Java集合框架面试题几乎必问](https://github.com/Snailclimb/Java-Guide/blob/master/Java相关/这几道Java集合框架面试题几乎必问.md) -* [Java 集合框架常见面试题总结](https://github.com/Snailclimb/Java-Guide/blob/master/Java相关/Java集合框架常见面试题总结.md) -* [ArrayList 源码学习](https://github.com/Snailclimb/Java-Guide/blob/master/Java相关/ArrayList.md) -* [【面试必备】透过源码角度一步一步带你分析 ArrayList 扩容机制](https://github.com/Snailclimb/JavaGuide/blob/master/Java相关/ArrayList-Grow.md) -* [LinkedList 源码学习](https://github.com/Snailclimb/Java-Guide/blob/master/Java相关/LinkedList.md) -* [HashMap(JDK1.8)源码学习](https://github.com/Snailclimb/Java-Guide/blob/master/Java相关/HashMap.md) - -### Java 多线程 - -* [并发编程面试必备：synchronized 关键字使用、底层原理、JDK1.6 之后的底层优化以及 和ReenTrantLock 的对比](https://github.com/Snailclimb/Java_Guide/blob/master/Java相关/synchronized.md) -* [并发编程面试必备：乐观锁与悲观锁](https://github.com/Snailclimb/Java-Guide/blob/master/面试必备/面试必备之乐观锁与悲观锁.md) -* [并发编程面试必备：JUC 中的 Atomic 原子类总结](https://github.com/Snailclimb/Java_Guide/blob/master/Java相关/Multithread/Atomic.md) -* [并发编程面试必备：AQS 原理以及 AQS 同步组件总结](https://github.com/Snailclimb/Java_Guide/blob/master/Java相关/Multithread/AQS.md) -* [BATJ都爱问的多线程面试题](https://github.com/Snailclimb/Java_Guide/blob/master/Java相关/Multithread/BATJ都爱问的多线程面试题.md) -* [并发容器总结](https://github.com/Snailclimb/Java_Guide/blob/master/Java相关/Multithread/并发容器总结.md) - -### Java 虚拟机 jvm - -* [可能是把Java内存区域讲的最清楚的一篇文章](https://github.com/Snailclimb/Java_Guide/blob/master/Java相关/可能是把Java内存区域讲的最清楚的一篇文章.md) -* [搞定JVM垃圾回收就是这么简单](https://github.com/Snailclimb/Java_Guide/blob/master/Java相关/搞定JVM垃圾回收就是这么简单.md) -* [《深入理解Java虚拟机》第2版学习笔记](https://github.com/Snailclimb/Java_Guide/blob/master/Java相关/Java虚拟机（jvm）.md) - -### Java BIO,NIO,AIO - -* [BIO,NIO,AIO 总结 ](https://github.com/Snailclimb/JavaGuide/blob/master/Java%E7%9B%B8%E5%85%B3/BIO%2CNIO%2CAIO%20summary.md) -* [Java IO 与 NIO系列文章](https://github.com/Snailclimb/Java_Guide/blob/master/Java相关/Java%20IO与NIO.md) - -### 设计模式 - -* [设计模式系列文章](https://github.com/Snailclimb/Java_Guide/blob/master/Java相关/设计模式.md) - -## :open_file_folder: 数据结构与算法 - -### 数据结构 - -* [数据结构知识学习与面试](https://github.com/Snailclimb/Java_Guide/blob/master/数据结构与算法/数据结构.md) - -### 算法 - -* [算法学习与面试](https://github.com/Snailclimb/Java_Guide/blob/master/数据结构与算法/算法.md) -* [常见安全算法（MD5、SHA1、Base64等等）总结](https://github.com/Snailclimb/Java_Guide/blob/master/数据结构与算法/常见安全算法（MD5、SHA1、Base64等等）总结.md) -* [算法总结——几道常见的子符串算法题 ](https://github.com/Snailclimb/Java_Guide/blob/master/数据结构与算法/搞定BAT面试——几道常见的子符串算法题.md) -* [算法总结——几道常见的链表算法题 ](https://github.com/Snailclimb/Java_Guide/blob/master/数据结构与算法/Leetcode-LinkList1.md) - -## :computer: 计算机网络与数据通信 - -### 网络相关 - -* [计算机网络常见面试题](https://github.com/Snailclimb/Java_Guide/blob/master/计算机网络与数据通信/计算机网络.md) -* [计算机网络基础知识总结](https://github.com/Snailclimb/Java_Guide/blob/master/计算机网络与数据通信/干货：计算机网络知识总结.md) -* [HTTPS中的TLS](https://github.com/Snailclimb/Java_Guide/blob/master/计算机网络与数据通信/HTTPS中的TLS.md) - -### 数据通信(RESTful,RPC,消息队列)总结 - -* [数据通信(RESTful、RPC、消息队列)相关知识点总结](https://github.com/Snailclimb/Java-Guide/blob/master/计算机网络与数据通信/数据通信(RESTful、RPC、消息队列).md) -* [Dubbo 总结：关于 Dubbo 的重要知识点](https://github.com/Snailclimb/Java-Guide/blob/master/计算机网络与数据通信/dubbo.md) -* [消息队列总结：新手也能看懂，消息队列其实很简单](https://github.com/Snailclimb/Java-Guide/blob/master/计算机网络与数据通信/message-queue.md) -* [一文搞懂 RabbitMQ 的重要概念以及安装](https://github.com/Snailclimb/Java-Guide/blob/master/计算机网络与数据通信/rabbitmq.md) - -## :iphone: 操作系统 - -### Linux相关 - -* [后端程序员必备的 Linux 基础知识](https://github.com/Snailclimb/Java-Guide/blob/master/操作系统/后端程序员必备的Linux基础知识.md) -* [Shell 编程入门](https://github.com/Snailclimb/Java-Guide/blob/master/操作系统/Shell.md) -## :pencil2: 主流框架/软件 - -### Spring - -* [Spring 学习与面试](https://github.com/Snailclimb/Java_Guide/blob/master/主流框架/Spring学习与面试.md) -* [Spring中bean的作用域与生命周期](https://github.com/Snailclimb/Java_Guide/blob/master/主流框架/SpringBean.md) -* [SpringMVC 工作原理详解](https://github.com/Snailclimb/JavaGuide/blob/master/主流框架/SpringMVC%20%E5%B7%A5%E4%BD%9C%E5%8E%9F%E7%90%86%E8%AF%A6%E8%A7%A3.md) - -### ZooKeeper - -* [可能是把 ZooKeeper 概念讲的最清楚的一篇文章](https://github.com/Snailclimb/Java_Guide/blob/master/主流框架/ZooKeeper.md) -* [ZooKeeper 数据模型和常见命令了解一下，速度收藏！](https://github.com/Snailclimb/Java_Guide/blob/master/主流框架/ZooKeeper数据模型和常见命令.md) - -## :floppy_disk: 数据存储 - -### MySQL - -* [MySQL 学习与面试](https://github.com/Snailclimb/Java_Guide/blob/master/数据存储/MySQL.md) -* [【思维导图-索引篇】搞定数据库索引就是这么简单](https://github.com/Snailclimb/Java_Guide/blob/master/数据存储/MySQL%20Index.md) - -### Redis - -* [Redis 总结](https://github.com/Snailclimb/Java_Guide/blob/master/数据存储/Redis/Redis.md) -* [Redlock分布式锁](https://github.com/Snailclimb/Java_Guide/blob/master/数据存储/Redis/Redlock分布式锁.md) -* [如何做可靠的分布式锁，Redlock真的可行么](https://github.com/Snailclimb/Java_Guide/blob/master/数据存储/Redis/如何做可靠的分布式锁，Redlock真的可行么.md) - -## :punch: 架构 - -* [一文读懂分布式应该学什么](https://github.com/Snailclimb/Java_Guide/blob/master/架构/分布式.md) -* [8 张图读懂大型网站技术架构](https://github.com/Snailclimb/JavaGuide/blob/master/架构/8%20张图读懂大型网站技术架构.md) -* [【面试精选】关于大型网站系统架构你不得不懂的10个问题](https://github.com/Snailclimb/JavaGuide/blob/master/架构/【面试精选】关于大型网站系统架构你不得不懂的10个问题.md) - -## :musical_note: 面试必备 - -### 备战面试 - -* [【备战面试1】程序员的简历就该这样写](https://github.com/Snailclimb/Java-Guide/blob/master/面试必备/程序员的简历之道.md) -* [【备战面试2】初出茅庐的程序员该如何准备面试？](https://github.com/Snailclimb/Java-Guide/blob/master/面试必备/interviewPrepare.md) -* [【备战面试3】7个大部分程序员在面试前很关心的问题](https://github.com/Snailclimb/JavaGuide/blob/master/面试必备/JavaProgrammerNeedKnow.md) -* [【备战面试4】Java程序员必备书单](https://github.com/Snailclimb/Java-Guide/blob/master/面试必备/books.md) -* [【备战面试5】美团面试常见问题总结（附详解答案）](https://github.com/Snailclimb/Java-Guide/blob/master/面试必备/美团面试常见问题总结.md) - - -### 最最最常见的Java面试题总结 - -这里会分享一些出现频率极其极其高的面试题，初定周更一篇，什么时候更完什么时候停止。 - -* [第一周（2018-8-7）](https://github.com/Snailclimb/Java-Guide/blob/master/面试必备/最最最常见的Java面试题总结/第一周（2018-8-7）.md) (为什么 Java 中只有值传递、==与equals、 hashCode与equals) -* [第二周（2018-8-13）](https://github.com/Snailclimb/Java-Guide/blob/master/面试必备/最最最常见的Java面试题总结/第二周(2018-8-13).md)(String和StringBuffer、StringBuilder的区别是什么？String为什么是不可变的？、什么是反射机制？反射机制的应用场景有哪些？......) -* [第三周（2018-08-22）](https://github.com/Snailclimb/Java-Guide/blob/master/Java相关/这几道Java集合框架面试题几乎必问.md) （Arraylist 与 LinkedList 异同、ArrayList 与 Vector 区别、HashMap的底层实现、HashMap 和 Hashtable 的区别、HashMap 的长度为什么是2的幂次方、HashSet 和 HashMap 区别、ConcurrentHashMap 和 Hashtable 的区别、ConcurrentHashMap线程安全的具体实现方式/底层具体实现、集合框架底层数据结构总结） -* [第四周(2018-8-30).md](https://github.com/Snailclimb/Java-Guide/blob/master/面试必备/最最最常见的Java面试题总结/第四周(2018-8-30).md) （主要内容是几道面试常问的多线程基础题。） - -### Java学习/面试开源仓库推荐 - -* [盘点一下Github上开源的Java面试/学习相关的仓库，看完弄懂薪资至少增加10k](https://github.com/Snailclimb/Java-Guide/blob/master/面试必备/JavaInterviewGithub.md) - -## :art: 闲谈 - -* [选择技术方向都要考虑哪些因素](https://github.com/Snailclimb/Java-Guide/blob/master/闲谈/选择技术方向都要考虑哪些因素.md) -* [结束了我短暂的秋招，说点自己的感受](https://github.com/Snailclimb/JavaGuide/blob/master/闲谈/2018%20%E7%A7%8B%E6%8B%9B.md) -* [【2018总结】即使平凡，也要热爱自己的生活](https://github.com/Snailclimb/JavaGuide/blob/master/闲谈/2018%20summary.md) -* [Java项目 Github Trending 月榜](https://github.com/Snailclimb/JavaGuide/blob/master/闲谈/JavaGithubTrending/JavaGithubTrending.md) - -*** - -## :envelope: 说明 - -### 介绍 - -* **对于 Java 初学者来说：** 本文档倾向于给你提供一个比较详细的学习路径，让你对于Java整体的知识体系有一个初步认识。另外，本文的一些文章 -也是你学习和复习 Java 知识不错的实践； -* **对于非 Java 初学者来说：** 本文档更适合回顾知识，准备面试，搞清面试应该把重心放在那些问题上。要搞清楚这个道理：提前知道那些面试常见，不是为了背下来应付面试，而是为了让你可以更有针对的学习重点。 - -本文档 Markdown 格式参考：[Github Markdown格式](https://guides.github.com/features/mastering-markdown/)，表情素材来自：[EMOJI CHEAT SHEET](https://www.webpagefx.com/tools/emoji-cheat-sheet/)。 - -### 关于转载 - -如果你需要转载本仓库的一些文章到自己的博客的话，记得注明原文地址就可以了。 - -### 如何对该开源文档进行贡献 - -1. 笔记内容大多是手敲，所以难免会有笔误，你可以帮我找错别字。 -2. 很多知识点我可能没有涉及到，所以你可以对其他知识点进行补充。(**对于不错的原创文章我根据你的选择给予现金奖励、付费专栏或者书籍进行奖励！快提 pr 给我投稿吧！**) -3. 现有的知识点难免存在不完善或者错误，所以你可以对已有知识点的修改/补充。 - -### 为什么要做这个开源文档？ - -初始想法源于自己的个人那一段比较迷茫的学习经历。主要目的是为了通过这个开源平台来帮助一些在学习 Java 或者面试过程中遇到问题的小伙伴。 - -### 联系我 - -如果大家需要与我交流，可以扫描下方二维码添加我的微信获取关注[我的公众号](#公众号)： - -![我的微信](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/2019-2/JavaGuide.jpg) - -### Java并发编程专栏 - -微信扫描下方二维码，购买之后我会将自己得到的24元返现都还给你，减轻各位的学习成本！ - -![ Java并发编程专栏](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/2019-2/Java并发编程实战.jpg) - -### Contributor - -下面是笔主收集的一些对本仓库提过有价值的pr或者issue的朋友，人数较多，如果你也对本仓库提过不错的pr或者issue的话，你可以加我的微信与我联系。下面的排名不分先后！ - - - - - - - - - - - - - - - - - -" - - - - - - - - - - -### 公众号 - -如果大家想要实时关注我更新的文章以及分享的干货的话，可以关注我的公众号。 - -![我的公众号](https://user-gold-cdn.xitu.io/2018/11/28/167598cd2e17b8ec?w=258&h=258&f=jpeg&s=27334) +> [JavaGuide 官方知识星球](https://www.yuque.com/docs/share/8a30ffb5-83f3-40f9-baf9-38de68b906dc)来啦！！！如果你需要专属面试小册/一对一交流/简历修改/专属求职指南/学习打卡，不妨花 3 分钟左右看看星球的详细介绍： [JavaGuide 知识星球详细介绍](https://www.yuque.com/docs/share/8a30ffb5-83f3-40f9-baf9-38de68b906dc) （一定要确定自己真的需要再加入，一定要看完详细介绍之后再加我）。 + +
+

+ + + +

+

+ + + +

+

+ 阅读 + stars + forks + issues +

+
+ +> 1. **面试专版** ：准备面试的小伙伴可以考虑面试专版：[《Java 面试进阶指北 》](https://www.yuque.com/docs/share/f37fc804-bfe6-4b0d-b373-9c462188fec7) (质量很高，专为面试打造，配合 JavaGuide 食用)。 +> 1. **知识星球** ：专属面试小册/一对一交流/简历修改/专属求职指南，欢迎加入 [JavaGuide 知识星球](https://www.yuque.com/docs/share/8a30ffb5-83f3-40f9-baf9-38de68b906dc)（点击链接即可查看星球的详细介绍，一定一定一定确定自己真的需要再加入，一定一定要看完详细介绍之后再加我）。 +> 2. **转载须知** ：以下所有文章如非文首说明为转载皆为我（Guide 哥）的原创，转载在文首注明出处，如发现恶意抄袭/搬运，会动用法律武器维护自己的权益。让我们一起维护一个良好的技术创作环境！ + +推荐你通过在线阅读网站进行阅读，体验更好，速度更快！ + +* [JavaGuide 在线阅读网站（新版，推荐👍）](https://javaguide.cn/) +* [JavaGuide 在线阅读版（老版）](https://snailclimb.gitee.io/javaguide/#/) + +你可能需要： + +* [项目介绍](./docs/javaguide/intro) +* [贡献指南](./docs/javaguide/contribution-guideline) +* [常见问题](./docs/javaguide/faq) +* [项目代办](./docs/javaguide/todo) + +## Java + +### 基础 + +**知识点/面试题** : (必看:+1: )： + +* [Java 基础常见知识点&面试题总结(上)](docs/java/basis/java-basic-questions-01.md) +* [Java 基础常见知识点&面试题总结(中)](docs/java/basis/java-basic-questions-02.md) +* [Java 基础常见知识点&面试题总结(下)](docs/java/basis/java-basic-questions-03.md) + +**重要知识点详解** ： + +* [为什么 Java 中只有值传递？](docs/java/basis/why-there-only-value-passing-in-java.md) +* [什么是反射机制？反射机制的应用场景有哪些？](docs/java/basis/reflection.md) +* [代理模式详解：静态代理+JDK/CGLIB 动态代理实战](docs/java/basis/proxy.md) +* [常见的 IO 模型有哪些？Java 中的 BIO、NIO、AIO 有啥区别?](docs/java/basis/io.md) +* [BigDecimal解决浮点数运算精度丢失问题](docs/java/basis/bigdecimal.md) +* **[泛型连环炮](docs/java/basis/generics.md)** + +### 集合 + +**知识点/面试题** ： + +1. [Java 集合常见知识点&面试题总结(上)](docs/java/collection/java-collection-questions-01.md) (必看 :+1:) +2. [Java 集合常见知识点&面试题总结(下)](docs/java/collection/java-collection-questions-02.md) (必看 :+1:) +2. [Java 容器使用注意事项总结](docs/java/collection/java集合使用注意事项.md) + +**源码分析** ： + +* [ArrayList 源码+扩容机制分析](docs/java/collection/arraylist-source-code.md) +* [HashMap(JDK1.8)源码+底层数据结构分析](docs/java/collection/hashmap-source-code.md) +* [ConcurrentHashMap 源码+底层数据结构分析](docs/java/collection/concurrent-hash-map-source-code.md) + +### 并发 + +**知识点/面试题** : (必看 :+1:) + +1. [Java 并发常见知识点&面试题总结（基础篇）](docs/java/concurrent/java-concurrent-questions-01.md) +2. [Java 并发常见知识点&面试题总结（进阶篇）](docs/java/concurrent/java-concurrent-questions-02.md) + +**重要知识点详解** ： + +1. **线程池** ：[Java 线程池详解](./docs/java/concurrent/java-thread-pool-summary.md)、[Java 线程池最佳实践](./docs/java/concurrent/java-thread-pool-best-practices.md) +2. [ThreadLocal 关键字解析](docs/java/concurrent/threadlocal.md) +3. [Java 并发容器总结](docs/java/concurrent/java-concurrent-collections.md) +4. [Atomic 原子类总结](docs/java/concurrent/atomic-classes.md) +5. [AQS 原理以及 AQS 同步组件总结](docs/java/concurrent/aqs原理以及aqs同步组件总结.md) +6. [CompletableFuture入门](docs/java/concurrent/completablefuture-intro.md) + +### JVM (必看 :+1:) + +JVM 这部分内容主要参考 [JVM 虚拟机规范-Java8 ](https://docs.oracle.com/javase/specs/jvms/se8/html/index.html) 和周志明老师的[《深入理解Java虚拟机（第3版）》](https://book.douban.com/subject/34907497/) （强烈建议阅读多遍！）。 + +1. **[Java 内存区域](https://javaguide.cn/java/jvm/jvm-garbage-collection/)** +2. **[JVM 垃圾回收](https://javaguide.cn/java/jvm/jvm-garbage-collection/)** +3. [JDK 监控和故障处理工具](https://javaguide.cn/java/jvm/jdk-monitoring-and-troubleshooting-tools/) +4. [类文件结构](https://javaguide.cn/java/jvm/class-file-structure/) +5. **[类加载过程](https://javaguide.cn/java/jvm/class-loading-process/)** +6. [类加载器](https://javaguide.cn/java/jvm/classloader/) +7. **[【待完成】最重要的 JVM 参数总结（翻译完善了一半）](https://javaguide.cn/java/jvm/jvm-parameters-intro/)** +8. **[【加餐】大白话带你认识 JVM](https://javaguide.cn/java/jvm/jvm-intro/)** + +### 新特性 + +1. **Java 8** ：[Java 8 新特性总结（翻译）](docs/java/new-features/java8-tutorial-translate.md)、[Java8常用新特性总结](./docs/java/new-features/java8-common-new-features.md) +2. [Java 9 新特性概览](./docs/java/new-features/java9.md) +3. [Java 10 新特性概览](./docs/java/new-features/java10.md) +4. [Java 11 新特性概览](./docs/java/new-features/java11.md) +5. [Java 12~13 新特性概览](./docs/java/new-features/java12-13.md) +6. [Java 14~15 新特性概览](./docs/java/new-features/java14-15.md) + +## 计算机基础 + +👉 **[图解计算机基础 PDF 下载](https://mp.weixin.qq.com/s?__biz=Mzg2OTA0Njk0OA==&mid=100021725&idx=1&sn=2db9664ca25363139a81691043e9fd8f&chksm=4ea19a1679d61300d8990f7e43bfc7f476577a81b712cf0f9c6f6552a8b219bc081efddb5c54#rd)** 。 + +### 操作系统 + +1. [操作系统常见问题总结！](docs/cs-basics/operating-system/operating-system-basic-questions-01.md) +2. [后端程序员必备的 Linux 基础知识总结](docs/cs-basics/operating-system/linux-intro.md) +3. [Shell 编程入门](docs/cs-basics/operating-system/shell-intro.md) + +### 网络 + +1. [OSI 和 TCP/IP 网络分层模型详解（基础）](./docs/cs-basics/network/osi&tcp-ip-model.md) +1. [HTTP vs HTTPS（应用层）](./docs/cs-basics/network/http&https.md) +1. [HTTP 1.0 vs HTTP 1.1（应用层）](./docs/cs-basics/network/http1.0&http1.1.md) +1. [计算机网络常见知识点&面试题（补充）](./docs/cs-basics/network/other-network-questions.md) +2. [谢希仁老师的《计算机网络》内容总结](docs/cs-basics/network/谢希仁老师的《计算机网络》内容总结.md) + +### 数据结构 + +**图解数据结构：** + +1. [线性数据结构 :数组、链表、栈、队列](docs/cs-basics/data-structure/linear-data-structure.md) +2. [图](docs/cs-basics/data-structure/graph.md) +3. [堆](docs/cs-basics/data-structure/heap.md) +4. [树](docs/cs-basics/data-structure/tree.md) ：重点关注[红黑树](docs/cs-basics/data-structure/red-black-tree.md)、B-，B+，B*树、LSM树 + +其他常用数据结构 ： + +1. [布隆过滤器](docs/cs-basics/data-structure/bloom-filter.md) + +### 算法 + +算法这部分内容非常重要，如果你不知道如何学习算法的话，可以看下我写的： + +* [算法学习书籍+资源推荐](https://www.zhihu.com/question/323359308/answer/1545320858) 。 +* [如何刷Leetcode?](https://www.zhihu.com/question/31092580/answer/1534887374) + +**常见算法问题总结** ： + +* [几道常见的字符串算法题总结 ](docs/cs-basics/algorithms/string-algorithm-problems.md) +* [几道常见的链表算法题总结 ](docs/cs-basics/algorithms/linkedlist-algorithm-problems.md) +* [剑指 offer 部分编程题](docs/cs-basics/algorithms/the-sword-refers-to-offer.md) + +另外，[GeeksforGeeks]( https://www.geeksforgeeks.org/fundamentals-of-algorithms/) 这个网站总结了常见的算法 ，比较全面系统。 + +## 数据库 + +### MySQL + +**总结：** + +1. [数据库基础知识总结](docs/database/basis.md) +2. **[MySQL知识点总结](docs/database/mysql/mysql-questions-01.md)** (必看 :+1:) +4. [一千行 MySQL 学习笔记](docs/database/mysql/a-thousand-lines-of-mysql-study-notes.md) +5. [MySQL 高性能优化规范建议](docs/database/mysql/mysql-high-performance-optimization-specification-recommendations.md) + +**重要知识点：** + +1. [MySQL数据库索引总结](docs/database/mysql/mysql-index.md) +2. [事务隔离级别(图文详解)](docs/database/mysql/transaction-isolation-level.md) +3. [MySQL三大日志(binlog、redo log和undo log)详解](docs/database/mysql/mysql-logs.md) +4. [InnoDB存储引擎对MVCC的实现](docs/database/mysql/innodb-implementation-of-mvcc.md) +5. [一条 SQL 语句在 MySQL 中如何被执行的?](docs/database/mysql/how-sql-executed-in-mysql.md) +6. [字符集详解：为什么不建议在MySQL中使用 utf8 ？](docs/database/character-set.md) +7. [关于数据库中如何存储时间的一点思考](docs/database/mysql/some-thoughts-on-database-storage-time.md) + +### Redis + +1. [Redis 常见问题总结](docs/database/redis/redis-questions-01.md) +2. [3种常用的缓存读写策略](docs/database/redis/3-commonly-used-cache-read-and-write-strategies.md) + +## 搜索引擎 + +用于提高搜索效率，功能和浏览器搜索引擎类似。比较常见的搜索引擎是 Elasticsearch（推荐） 和 Solr。 + +## 开发工具 + +### Docker + +* [Docker 基本概念解读](./docs/tools/docker/docker-intro.md) +* [Docker从入门到上手干事](./docs/tools/docker/docker-in-action.md) + +### Git + +* [Git 入门](./docs/tools/git/git-intro.md) +* [Github 小技巧](./docs/tools/git/github-tips.md) + +## 系统设计 + +### 系统设计必备基础 + +#### RESTful API + +我们在进行后端开发的时候，主要的工作就是为前端或者其他后端服务提供 API 比如查询用户数据的 API 。RESTful API 是一种基于 REST 构建的 API，它是一种被设计的更好使用的 API。 + +相关阅读：[RestFul API 简明教程](docs/system-design/basis/RESTfulAPI.md) + +#### 命名 + +编程过程中，一定要重视命名。因为好的命名即是注释，别人一看到你的命名就知道你的变量、方法或者类是做什么的！ + +相关阅读： [Java 命名之道](docs/system-design/basis/naming.md) 。 + +### 常用框架 + +如果你没有接触过 Java Web 开发的话，可以先看一下我总结的 [《J2EE 基础知识》](docs/system-design/J2EE基础知识.md) 。虽然，这篇文章中的很多内容已经淘汰，但是可以让你对 Java 后台技术发展有更深的认识。 + +#### Spring/SpringBoot (必看 :+1:) + +**知识点/面试题** : + +1. **[Spring 常见知识点&面试题总结](docs/system-design/framework/spring/spring-knowledge-and-questions-summary.md)** +2. **[SpringBoot 入门指南](https://github.com/Snailclimb/springboot-guide)** + +**重要知识点详解** ： + +1. **[Spring/Spring Boot 常用注解总结！安排！](./docs/system-design/framework/spring/spring-common-annotations.md)** +2. **[Spring 事务总结](docs/system-design/framework/spring/spring-transaction.md)** +3. [Spring 中都用到了那些设计模式?](docs/system-design/framework/spring/spring-design-patterns-summary.md) +4. **[SpringBoot 自动装配原理](docs/system-design/framework/spring/spring-boot-auto-assembly-principles.md)** + +#### MyBatis + +[MyBatis 常见面试题总结](docs/system-design/framework/mybatis/mybatis-interview.md) + +#### Spring Cloud + +[大白话入门 Spring Cloud](docs/system-design/framework/springcloud/springcloud-intro.md) + +### 安全 + +#### 认证授权 + +**[《认证授权基础》](docs/system-design/security/basis-of-authority-certification.md)** 这篇文章中我会介绍认证授权常见概念： **Authentication**, **Authorization** 以及 **Cookie**、**Session**、Token、**OAuth 2**、**SSO** 。如果你不清楚这些概念的话，建议好好阅读一下这篇文章。 + +* **JWT** ：JWT（JSON Web Token）是一种身份认证的方式，JWT 本质上就一段签名的 JSON 格式的数据。由于它是带有签名的，因此接收者便可以验证它的真实性。相关阅读： + + [JWT 优缺点分析以及常见问题解决方案](docs/system-design/security/advantages&disadvantages-of-jwt.md) + + [适合初学者入门 Spring Security With JWT 的 Demo](https://github.com/Snailclimb/spring-security-jwt-guide) + +* **SSO(单点登录)** ：**SSO(Single Sign On)** 即单点登录说的是用户登陆多个子系统的其中一个就有权访问与其相关的其他系统。举个例子我们在登陆了京东金融之后，我们同时也成功登陆京东的京东超市、京东家电等子系统。相关阅读：[**SSO 单点登录看这篇就够了！**](docs/system-design/security/sso-intro.md) + +#### 数据脱敏 + +数据脱敏说的就是我们根据特定的规则对敏感信息数据进行变形，比如我们把手机号、身份证号某些位数使用 * 来代替。 + +#### 敏感词过滤 + +系统需要对用户输入的文本进行敏感词过滤如色情、政治、暴力相关的词汇。 + +相关阅读：[《敏感词过滤》](./docs/system-design/security/sentive-words-filter.md) + +### 定时任务 + +最近有朋友问到定时任务相关的问题。于是，我简单写了一篇文章总结一下定时任务的一些概念以及一些常见的定时任务技术选型：[《Java定时任务大揭秘》](./docs/system-design/schedule-task.md) + +## 分布式 + +### CAP 理论和 BASE 理论 + +CAP 也就是 Consistency（一致性）、Availability（可用性）、Partition Tolerance（分区容错性） 这三个单词首字母组合。 + +**BASE** 是 **Basically Available（基本可用）** 、**Soft-state（软状态）** 和 **Eventually Consistent（最终一致性）** 三个短语的缩写。BASE 理论是对 CAP 中一致性和可用性权衡的结果，其来源于对大规模互联网系统分布式实践的总结，是基于 CAP 定理逐步演化而来的，它大大降低了我们对系统的要求。 + +相关阅读：[CAP 理论和 BASE 理论解读](docs/distributed-system/theorem&algorithm&protocol/cap&base-theorem.md) + +### Paxos 算法和 Raft 算法 + +**Paxos 算法** 诞生于 1990 年，这是一种解决分布式系统一致性的经典算法 。但是，由于 Paxos 算法非常难以理解和实现，不断有人尝试简化这一算法。到了2013 年才诞生了一个比 Paxos 算法更易理解和实现的分布式一致性算法—**Raft 算法**。 + +相关阅读： + +* [Paxos 算法解读](docs/distributed-system/theorem&algorithm&protocol/paxos-algorithm.md) +* [Raft 算法解读](docs/distributed-system/theorem&algorithm&protocol/raft-algorithm.md) + +### RPC + +RPC 让调用远程服务调用像调用本地方法那样简单。 + +Dubbo 是一款国产的 RPC 框架，由阿里开源。相关阅读： + +* [Dubbo 常见问题总结](docs/distributed-system/rpc/dubbo.md) +* [服务之间的调用为啥不直接用 HTTP 而用 RPC？](docs/distributed-system/rpc/why-use-rpc.md) + +### API 网关 + +网关主要用于请求转发、安全认证、协议转换、容灾。 + +相关阅读： + +* [为什么要网关？你知道有哪些常见的网关系统？](docs/distributed-system/api-gateway.md) +* [百亿规模API网关服务Shepherd的设计与实现](https://tech.meituan.com/2021/05/20/shepherd-api-gateway.html) + +### 分布式 id + +在复杂分布式系统中，往往需要对大量的数据和消息进行唯一标识。比如数据量太大之后，往往需要对数据进行分库分表，分库分表后需要有一个唯一 ID 来标识一条数据或消息，数据库的自增 ID 显然不能满足需求。相关阅读：[为什么要分布式 id ？分布式 id 生成方案有哪些？](docs/distributed-system/distributed-id.md) + +### 分布式事务 + +**分布式事务就是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。** + +简单的说，就是一次大的操作由不同的小操作组成，这些小的操作分布在不同的服务器上，且属于不同的应用，分布式事务需要保证这些小操作要么全部成功，要么全部失败。本质上来说，分布式事务就是为了保证不同数据库的数据一致性。 + +### 分布式协调 + +**ZooKeeper** ： + +> 前两篇文章可能有内容重合部分，推荐都看一遍。 + +1. [【入门】ZooKeeper 相关概念总结](docs/distributed-system/distributed-process-coordination/zookeeper/zookeeper-intro.md) +2. [【进阶】ZooKeeper 相关概念总结](docs/distributed-system/distributed-process-coordination/zookeeper/zookeeper-plus.md) +3. [【实战】ZooKeeper 实战](docs/distributed-system/distributed-process-coordination/zookeeper/zookeeper-in-action.md) + +## 高性能 + +### 消息队列 + +消息队列在分布式系统中主要是为了解耦和削峰。相关阅读： [消息队列常见问题总结](docs/high-performance/message-queue/message-queue.md)。 + +1. **RabbitMQ** : [RabbitMQ 入门](docs/high-performance/message-queue/rabbitmq-intro.md) +2. **RocketMQ** : [RocketMQ 入门](docs/high-performance/message-queue/rocketmq-intro)、[RocketMQ 的几个简单问题与答案](docs/high-performance/message-queue/rocketmq-questions.md) +3. **Kafka** ：[Kafka 常见问题总结](docs/high-performance/message-queue/kafka-questions-01.md) + +### 读写分离&分库分表 + +读写分离主要是为了将数据库的读和写操作分不到不同的数据库节点上。主服务器负责写，从服务器负责读。另外，一主一从或者一主多从都可以。 + +读写分离可以大幅提高读性能，小幅提高写的性能。因此，读写分离更适合单机并发读请求比较多的场景。 + +分库分表是为了解决由于库、表数据量过大，而导致数据库性能持续下降的问题。 + +常见的分库分表工具有： `sharding-jdbc` （当当）、 `TSharding` （蘑菇街）、 `MyCAT` （基于 Cobar）、 `Cobar` （阿里巴巴）...。 推荐使用 `sharding-jdbc` 。 因为， `sharding-jdbc` 是一款轻量级 `Java` 框架，以 `jar` 包形式提供服务，不要我们做额外的运维工作，并且兼容性也很好。 + +相关阅读： [读写分离&分库分表常见问题总结](docs/high-performance/read-and-write-separation-and-library-subtable.md) + +### 负载均衡 + +负载均衡系统通常用于将任务比如用户请求处理分配到多个服务器处理以提高网站、应用或者数据库的性能和可靠性。 + +常见的负载均衡系统包括 3 种： + +1. **DNS 负载均衡** ：一般用来实现地理级别的均衡。 +2. **硬件负载均衡** ： 通过单独的硬件设备比如 F5 来实现负载均衡功能（硬件的价格一般很贵）。 +3. **软件负载均衡** ：通过负载均衡软件比如 Nginx 来实现负载均衡功能。 + +## 高可用 + +高可用描述的是一个系统在大部分时间都是可用的，可以为我们提供服务的。高可用代表系统即使在发生硬件故障或者系统升级的时候，服务仍然是可用的 。 + +相关阅读： **《[如何设计一个高可用系统？要考虑哪些地方？](docs/high-availability/high-availability-system-design.md)》** 。 + +### 限流 + +限流是从用户访问压力的角度来考虑如何应对系统故障。 + +限流为了对服务端的接口接受请求的频率进行限制，防止服务挂掉。比如某一接口的请求限制为 100 个每秒, 对超过限制的请求放弃处理或者放到队列中等待处理。限流可以有效应对突发请求过多。相关阅读：[何为限流？限流算法有哪些？](docs/high-availability/limit-request.md) + +### 降级 + +降级是从系统功能优先级的角度考虑如何应对系统故障。 + +服务降级指的是当服务器压力剧增的情况下，根据当前业务情况及流量对一些服务和页面有策略的降级，以此释放服务器资源以保证核心任务的正常运行。 + +### 熔断 + +熔断和降级是两个比较容易混淆的概念，两者的含义并不相同。 + +降级的目的在于应对系统自身的故障，而熔断的目的在于应对当前系统依赖的外部系统或者第三方系统的故障。 + +### 排队 + +另类的一种限流，类比于现实世界的排队。玩过英雄联盟的小伙伴应该有体会，每次一有活动，就要经历一波排队才能进入游戏。 + +### 集群 + +相同的服务部署多份，避免单点故障。 + +### 超时和重试机制 + +**一旦用户的请求超过某个时间得不到响应就结束此次请求并抛出异常。** 如果不进行超时设置可能会导致请求响应速度慢，甚至导致请求堆积进而让系统无法再处理请求。 + +重试的次数一般设为 3 次，再多的重试次数没有好处，反而会加重服务器压力（部分场景使用失败重试机制会不太适合）。在一次重试失败之后通常会加上一个时间间隔 delay 再进行下一次重试，时间间隔 delay 通常建议是随机的。 + +并且，为了更好地保护下游，我们还可以结合断路器。 + +### 灾备设计和异地多活 + +**灾备** = 容灾+备份。 + +* **备份** ： 将系统所产生的的所有重要数据多备份几份。 +* **容灾** ： 在异地建立两个完全相同的系统。当某个地方的系统突然挂掉，整个应用系统可以切换到另一个，这样系统就可以正常提供服务了。 + +**异地多活** 描述的是将服务部署在异地并且服务同时对外提供服务。和传统的灾备设计的最主要区别在于“多活”，即所有站点都是同时在对外提供服务的。异地多活是为了应对突发状况比如火灾、地震等自然或者人为灾害。 + +相关阅读： + +* [搞懂异地多活，看这篇就够了](https://mp.weixin.qq.com/s/T6mMDdtTfBuIiEowCpqu6Q) +* [四步构建异地多活](https://mp.weixin.qq.com/s/hMD-IS__4JE5_nQhYPYSTg) +* [《从零开始学架构》— 28 | 业务高可用的保障：异地多活架构](http://gk.link/a/10pKZ) + +## 开发工具 + +### 数据库 + +* [CHINER: 干掉 PowerDesigner，这个国产数据库建模工具很强！](./docs/tools/database/CHINER.md) +* [DBeaver: 开源数据库管理工具。](./docs/tools/database/DBeaver.md) +* [screw: 一键生成数据库文档，堪称数据库界的Swagger](./docs/tools/database/screw.md) +* [DataGrip: IDEA官方的这个数据库管理神器真香！](./docs/tools/database/datagrip.md) + +### Git + +* [Git 入门](./docs/tools/git/git-intro.md) +* [Github 小技巧](./docs/tools/git/git-intro.md) + +### Docker + +* [Docker 基本概念解读](./docs/tools/docker/docker-intro.md) +* [Docker从入门到上手干事](./docs/tools/docker/docker-in-action.md) + +## 关于作者 + +* [个人介绍 Q&A](https://javaguide.cn/about-the-author/) +* [我曾经也是网瘾少年](https://javaguide.cn/about-the-author/internet-addiction-teenager/) +* [入职培训一个月后的感受](https://javaguide.cn/about-the-author/feelings-after-one-month-of-induction-training/) +* [从毕业到入职半年的感受](https://javaguide.cn/about-the-author/feelings-of-half-a-year-from-graduation-to-entry/) +* [某培训机构盗我文章做成视频还上了B站热门](https://javaguide.cn/about-the-author/my-article-was-stolen-and-made-into-video-and-it-became-popular/) + +## 公众号 + +如果大家想要实时关注我更新的文章以及分享的干货的话，可以关注我的公众号。 + +**《Java面试突击》:** 由本文档衍生的专为面试而生的《Java面试突击》PDF 版本[公众号](#公众号)后台回复 **"面试突击"** 即可免费领取！ + +![我的公众号](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/2019-6/167598cd2e17b8ec.png) + +![](https://img-blog.csdnimg.cn/7af97d4dccdb4123a541f336a107ca86.png) + +![](https://p1-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/3a2d826918a44bcbaa8d9272db3ad7d2~tplv-k3u1fbpfcp-watermark.image) diff --git a/docs/.vuepress/config.ts b/docs/.vuepress/config.ts new file mode 100644 index 0000000000000000000000000000000000000000..2e87d4a2f19559b522e8479920951b66514316a1 --- /dev/null +++ b/docs/.vuepress/config.ts @@ -0,0 +1,38 @@ +const { defineHopeConfig } = require("vuepress-theme-hope"); +import themeConfig from "./themeConfig"; + +module.exports = defineHopeConfig({ + port: "8080", + title: "JavaGuide", + description: "Java学习&&面试指南", + //指定 vuepress build 的输出目录 + dest: "./dist", + // 是否开启默认预加载 js + shouldPrefetch: (file, type) => false, + head: [ + // 添加百度统计 + [ + "script", {}, + `var _hmt = _hmt || []; + (function() { + var hm = document.createElement("script"); + hm.src = "https://hm.baidu.com/hm.js?5dd2e8c97962d57b7b8fea1737c01743"; + var s = document.getElementsByTagName("script")[0]; + s.parentNode.insertBefore(hm, s); + })();` + ], + [ + "link", + { + rel: "stylesheet", + href: "//at.alicdn.com/t/font_2922463_lu595twe5t.css", + }, + ], + ], + locales: { + "/": { + lang: "zh-CN" + } + }, + themeConfig, +}); diff --git a/docs/.vuepress/navbar.ts b/docs/.vuepress/navbar.ts new file mode 100644 index 0000000000000000000000000000000000000000..d593f9b5aa6d4e1f6972509354c9bd0e7d0d67b3 --- /dev/null +++ b/docs/.vuepress/navbar.ts @@ -0,0 +1,16 @@ +import { defineNavbarConfig } from "vuepress-theme-hope"; + +export const navbarConfig = defineNavbarConfig([ + { text: "Java面试指南", icon: "java", link: "/home" }, + { + text: "Java面试指北", + icon: "recommend", + link: "https://www.yuque.com/docs/share/f37fc804-bfe6-4b0d-b373-9c462188fec7", + }, + { + text: "官方知识星球", + icon: "recommend", + link: "https://www.yuque.com/docs/share/8a30ffb5-83f3-40f9-baf9-38de68b906dc", + }, + { text: "关于作者", icon: "zuozhe", link: "/about-the-author/" }, +]); diff --git a/docs/.vuepress/public/assets/icon/apple-icon-152.png b/docs/.vuepress/public/assets/icon/apple-icon-152.png new file mode 100644 index 0000000000000000000000000000000000000000..f53c6c55b049ea917c283acd84bd5a5f62a289c3 Binary files /dev/null and b/docs/.vuepress/public/assets/icon/apple-icon-152.png differ diff --git a/docs/.vuepress/public/assets/icon/chrome-192.png b/docs/.vuepress/public/assets/icon/chrome-192.png new file mode 100644 index 0000000000000000000000000000000000000000..5709628031cd66a7dc5d1a758601d8ffc862cab9 Binary files /dev/null and b/docs/.vuepress/public/assets/icon/chrome-192.png differ diff --git a/docs/.vuepress/public/assets/icon/chrome-512.png b/docs/.vuepress/public/assets/icon/chrome-512.png new file mode 100644 index 0000000000000000000000000000000000000000..2db62c2910783cadb4f99c15be74bb0134f763dc Binary files /dev/null and b/docs/.vuepress/public/assets/icon/chrome-512.png differ diff --git a/docs/.vuepress/public/assets/icon/chrome-mask-192.png b/docs/.vuepress/public/assets/icon/chrome-mask-192.png new file mode 100644 index 0000000000000000000000000000000000000000..77c39a2a828560cdfa70eec967cf4e5892ed767d Binary files /dev/null and b/docs/.vuepress/public/assets/icon/chrome-mask-192.png differ diff --git a/docs/.vuepress/public/assets/icon/chrome-mask-512.png b/docs/.vuepress/public/assets/icon/chrome-mask-512.png new file mode 100644 index 0000000000000000000000000000000000000000..b8349f4ea1d00b8bdc5a2dc905376803ffaa317c Binary files /dev/null and b/docs/.vuepress/public/assets/icon/chrome-mask-512.png differ diff --git a/docs/.vuepress/public/assets/icon/guide-maskable.png b/docs/.vuepress/public/assets/icon/guide-maskable.png new file mode 100644 index 0000000000000000000000000000000000000000..230798a3c891267ce4d89b234b158784e17b7813 Binary files /dev/null and b/docs/.vuepress/public/assets/icon/guide-maskable.png differ diff --git a/docs/.vuepress/public/assets/icon/guide-monochrome.png b/docs/.vuepress/public/assets/icon/guide-monochrome.png new file mode 100644 index 0000000000000000000000000000000000000000..e12403e2ec73bab4044d8f7ced3df530cccd18ea Binary files /dev/null and b/docs/.vuepress/public/assets/icon/guide-monochrome.png differ diff --git a/docs/.vuepress/public/assets/icon/ms-icon-144.png b/docs/.vuepress/public/assets/icon/ms-icon-144.png new file mode 100644 index 0000000000000000000000000000000000000000..681cde6fccaaa520b994c680289341a09a800811 Binary files /dev/null and b/docs/.vuepress/public/assets/icon/ms-icon-144.png differ diff --git a/docs/.vuepress/public/favicon.ico b/docs/.vuepress/public/favicon.ico new file mode 100644 index 0000000000000000000000000000000000000000..3a14635ac460d2194138e858ede73c919240e031 Binary files /dev/null and b/docs/.vuepress/public/favicon.ico differ diff --git a/docs/.vuepress/public/logo.png b/docs/.vuepress/public/logo.png new file mode 100644 index 0000000000000000000000000000000000000000..6e7fb462bd8b89e23a8a7e61f2bf3b326fa53716 Binary files /dev/null and b/docs/.vuepress/public/logo.png differ diff --git a/docs/.vuepress/public/logo.svg b/docs/.vuepress/public/logo.svg new file mode 100644 index 0000000000000000000000000000000000000000..da6b683d5f18f4cc43418dbb42e74e856239e7e3 --- /dev/null +++ b/docs/.vuepress/public/logo.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/docs/.vuepress/public/me.png b/docs/.vuepress/public/me.png new file mode 100644 index 0000000000000000000000000000000000000000..be8f2106c6cabd0937341ffcffe6c92f04927524 Binary files /dev/null and b/docs/.vuepress/public/me.png differ diff --git a/docs/.vuepress/sidebar.ts b/docs/.vuepress/sidebar.ts new file mode 100644 index 0000000000000000000000000000000000000000..d645cc2d5efdabe699037f23eac63c4ebd0ce940 --- /dev/null +++ b/docs/.vuepress/sidebar.ts @@ -0,0 +1,426 @@ +import { defineSidebarConfig } from "vuepress-theme-hope"; + +export const sidebarConfig = defineSidebarConfig({ + // 应该把更精确的路径放置在前边 + "/javaguide/": ["intro", "contribution-guideline", "faq", "todo"], + "/about-the-author/": [ + { + text: "个人经历", + icon: "zuozhe", + collapsable: false, + children: [ + "internet-addiction-teenager", + "javaguide-100k-star", + "feelings-after-one-month-of-induction-training", + "feelings-of-half-a-year-from-graduation-to-entry", + ], + }, + { + text: "杂谈", + icon: "chat", + collapsable: false, + children: [ + "my-article-was-stolen-and-made-into-video-and-it-became-popular", + "dog-that-copies-other-people-essay", + ], + }, + ], + "/high-quality-technical-articles/": [ + { + text: "练级攻略", + icon: "et-performance", + prefix: "advanced-programmer/", + collapsable: false, + children: ["seven-tips-for-becoming-an-advanced-programmer"], + }, + { + text: "个人经历", + icon: "zuozhe", + prefix: "personal-experience/", + collapsable: false, + children: [ + "two-years-of-back-end-develop--experience-in-didi&toutiao", + "8-years-programmer-work-summary", + ], + }, + { + text: "面试", + icon: "mianshixinxi-02", + prefix: "interview/", + collapsable: false, + children: [ + "the-experience-and-thinking-of-an-interview-experienced-by-an-older-programmer", + "technical-preliminary-preparation", + "screen-candidates-for-packaging", + ], + }, + { + text: "工作", + icon: "work0", + prefix: "work/", + collapsable: false, + children: ["get-into-work-mode-quickly-when-you-join-a-company"], + }, + ], + // 必须放在最后面 + "/": [ + { + text: "Java", + icon: "java", + prefix: "java/", + collapsable: true, + children: [ + { + text: "基础", + prefix: "basis/", + icon: "basic", + collapsable: true, + children: [ + "java-basic-questions-01", + "java-basic-questions-02", + "java-basic-questions-03", + { + text: "重要知识点", + icon: "important", + collapsable: true, + children: [ + "why-there-only-value-passing-in-java", + "reflection", + "proxy", + "io", + "bigdecimal", + "generics", + ], + }, + ], + }, + { + text: "容器", + prefix: "collection/", + icon: "container", + collapsable: true, + children: [ + "java-collection-questions-01", + "java-collection-questions-02", + "java-collection-precautions-for-use", + { + text: "源码分析", + collapsable: true, + children: [ + "arraylist-source-code", + "hashmap-source-code", + "concurrent-hash-map-source-code", + ], + }, + ], + }, + { + text: "并发编程", + prefix: "concurrent/", + icon: "et-performance", + collapsable: true, + children: [ + "java-concurrent-questions-01", + "java-concurrent-questions-02", + { + text: "重要知识点", + icon: "important", + collapsable: true, + children: [ + "java-thread-pool-summary", + "java-thread-pool-best-practices", + "java-concurrent-collections", + "aqs", + "reentrantlock", + "atomic-classes", + "threadlocal", + "completablefuture-intro", + ], + }, + ], + }, + { + text: "JVM", + prefix: "jvm/", + icon: "virtual_machine", + collapsable: true, + children: [ + "memory-area", + "jvm-garbage-collection", + "class-file-structure", + "class-loading-process", + "classloader", + "jvm-parameters-intro", + "jvm-intro", + "jdk-monitoring-and-troubleshooting-tools", + ], + }, + { + text: "新特性", + prefix: "new-features/", + icon: "features", + collapsable: true, + children: [ + "java8-common-new-features", + "java8-tutorial-translate", + "java9", + "java10", + "java11", + "java12-13", + "java14-15", + ], + }, + ], + }, + { + text: "计算机基础", + icon: "computer", + prefix: "cs-basics/", + collapsable: true, + children: [ + { + text: "网络", + prefix: "network/", + icon: "network", + collapsable: true, + children: [ + "osi&tcp-ip-model", + "http&https", + "http1.0&http1.1", + "other-network-questions", + ], + }, + { + text: "操作系统", + prefix: "operating-system/", + icon: "caozuoxitong", + collapsable: true, + children: [ + "operating-system-basic-questions-01", + "linux-intro", + "shell-intro", + ], + }, + { + text: "数据结构", + prefix: "data-structure/", + icon: "people-network-full", + collapsable: true, + children: [ + "linear-data-structure", + "graph", + "heap", + "tree", + "red-black-tree", + "bloom-filter", + ], + }, + { + text: "算法", + prefix: "algorithms/", + icon: "suanfaku", + collapsable: true, + children: [ + "string-algorithm-problems", + "linkedlist-algorithm-problems", + "the-sword-refers-to-offer", + ], + }, + ], + }, + { + text: "数据库", + icon: "database", + prefix: "database/", + collapsable: true, + children: [ + "basis", + "character-set", + { + text: "MySQL", + prefix: "mysql/", + icon: "mysql", + collapsable: true, + children: [ + "mysql-questions-01", + "a-thousand-lines-of-mysql-study-notes", + "mysql-high-performance-optimization-specification-recommendations", + { + text: "重要知识点", + icon: "important", + collapsable: true, + children: [ + "mysql-index", + "mysql-logs", + "transaction-isolation-level", + "innodb-implementation-of-mvcc", + "how-sql-executed-in-mysql", + "some-thoughts-on-database-storage-time", + ], + }, + ], + }, + { + text: "Redis", + prefix: "redis/", + icon: "redis", + collapsable: true, + children: [ + "redis-questions-01", + "3-commonly-used-cache-read-and-write-strategies", + ], + }, + ], + }, + { + text: "开发工具", + icon: "Tools", + prefix: "tools/", + collapsable: true, + children: [ + { + text: "Git", + icon: "git", + prefix: "git/", + collapsable: true, + children: ["git-intro", "github-tips"], + }, + { + text: "Docker", + icon: "docker1", + prefix: "docker/", + collapsable: true, + children: ["docker-intro", "docker-in-action"], + }, + ], + }, + { + text: "系统设计", + icon: "xitongsheji", + prefix: "system-design/", + collapsable: true, + children: [ + "system-design-questions", + { + text: "基础", + prefix: "basis/", + icon: "basic", + collapsable: true, + children: ["RESTfulAPI", "naming"], + }, + { + text: "常用框架", + prefix: "framework/", + icon: "framework", + collapsable: true, + children: [ + { + text: "Spring", + prefix: "spring/", + collapsable: true, + children: [ + "spring-knowledge-and-questions-summary", + "spring-common-annotations", + "spring-transaction", + "spring-design-patterns-summary", + "spring-boot-auto-assembly-principles", + ], + }, + "mybatis/mybatis-interview", + "netty", + { + text: "SpringCloud", + prefix: "springcloud/", + children: ["springcloud-intro"], + }, + ], + }, + { + text: "安全", + prefix: "security/", + icon: "security-fill", + collapsable: true, + children: [ + "basis-of-authority-certification", + "advantages&disadvantages-of-jwt", + "sso-intro", + "sentive-words-filter", + "data-desensitization", + ], + }, + "schedule-task", + ], + }, + { + text: "分布式", + icon: "distributed-network", + prefix: "distributed-system/", + collapsable: true, + children: [ + { + text: "理论&算法&协议", + prefix: "theorem&algorithm&protocol/", + collapsable: true, + children: ["cap&base-theorem", "paxos-algorithm", "raft-algorithm"], + }, + "api-gateway", + "distributed-id", + { + text: "RPC", + prefix: "rpc/", + collapsable: true, + children: ["dubbo", "why-use-rpc"], + }, + "distributed-transaction", + { + text: "分布式协调", + prefix: "distributed-process-coordination/", + collapsable: true, + children: [ + "zookeeper/zookeeper-intro", + "zookeeper/zookeeper-plus", + "zookeeper/zookeeper-in-action", + ], + }, + ], + }, + { + text: "高性能", + icon: "et-performance", + prefix: "high-performance/", + collapsable: true, + children: [ + "read-and-write-separation-and-library-subtable", + "load-balancing", + { + text: "消息队列", + prefix: "message-queue/", + icon: "MQ", + collapsable: true, + children: [ + "message-queue", + "kafka-questions-01", + "rocketmq-intro", + "rocketmq-questions", + "rabbitmq-intro", + ], + }, + ], + }, + { + text: "高可用", + icon: "CalendarAvailability-1", + prefix: "high-availability/", + collapsable: true, + children: [ + "high-availability-system-design", + "limit-request", + "fallback&circuit-breaker", + "timeout-and-retry", + "cluster", + "disaster-recovery&remote-live", + "performance-test", + ], + }, + ], +}); diff --git a/docs/.vuepress/styles/index.scss b/docs/.vuepress/styles/index.scss new file mode 100644 index 0000000000000000000000000000000000000000..e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 diff --git a/docs/.vuepress/styles/palette.scss b/docs/.vuepress/styles/palette.scss new file mode 100644 index 0000000000000000000000000000000000000000..1e6004d079c6ec01d49d803c3bb3b189aa221654 --- /dev/null +++ b/docs/.vuepress/styles/palette.scss @@ -0,0 +1,4 @@ +// colors +$themeColor: #2980B9; +$sidebarWidth: 20rem; +$sidebarMobileWidth: 16rem; diff --git a/docs/.vuepress/themeConfig.ts b/docs/.vuepress/themeConfig.ts new file mode 100644 index 0000000000000000000000000000000000000000..56bfb00540c3b64562ba40cfc82796f2563b1b43 --- /dev/null +++ b/docs/.vuepress/themeConfig.ts @@ -0,0 +1,102 @@ +import { defineThemeConfig } from "vuepress-theme-hope"; +import { navbarConfig } from "./navbar"; +import { sidebarConfig } from "./sidebar"; + +export default defineThemeConfig({ + logo: "/logo.png", + hostname: "https://javaguide.cn/", + author: "Guide哥", + repo: "https://github.com/Snailclimb/JavaGuide", + docsDir: "docs", + iconPrefix: "iconfont icon-", + pure: true, + navbar: navbarConfig, + sidebar: sidebarConfig, + blog: { + intro: "/about-the-author/", + sidebarDisplay: "mobile", + medias: { + Zhihu: "https://www.zhihu.com/people/javaguide", + Github: "https://github.com/Snailclimb", + Gitee: "https://gitee.com/SnailClimb", + }, + }, + footer: + '鄂ICP备2020015769号-1', + displayFooter: true, + plugins: { + blog: { + autoExcerpt: true, + }, + mdEnhance: { + enableAll: false, + presentation: { + plugins: ["highlight", "math", "search", "notes", "zoom"], + }, + }, + // docsearch: { + // appId: "", + // apiKey: "", + // indexName: "", + // }, + pwa: { + favicon: "/favicon.ico", + cachePic: true, + apple: { + icon: "/assets/icon/apple-icon-152.png", + statusBarColor: "black", + }, + msTile: { + image: "/assets/icon/ms-icon-144.png", + color: "#ffffff", + }, + manifest: { + icons: [ + { + src: "/assets/icon/chrome-mask-512.png", + sizes: "512x512", + purpose: "maskable", + type: "image/png", + }, + { + src: "/assets/icon/chrome-mask-192.png", + sizes: "192x192", + purpose: "maskable", + type: "image/png", + }, + { + src: "/assets/icon/chrome-512.png", + sizes: "512x512", + type: "image/png", + }, + { + src: "/assets/icon/chrome-192.png", + sizes: "192x192", + type: "image/png", + }, + ], + shortcuts: [ + { + name: "Guide", + short_name: "Guide", + url: "/guide/", + icons: [ + { + src: "/assets/icon/guide-maskable.png", + sizes: "192x192", + purpose: "maskable", + type: "image/png", + }, + { + src: "/assets/icon/guide-monochrome.png", + sizes: "192x192", + purpose: "monochrome", + type: "image/png", + }, + ], + }, + ], + }, + }, + }, +}); diff --git a/docs/about-the-author/dog-that-copies-other-people-essay.md b/docs/about-the-author/dog-that-copies-other-people-essay.md new file mode 100644 index 0000000000000000000000000000000000000000..6758a20817be5e365b0e84fe2cbe5d8e0e116fe5 --- /dev/null +++ b/docs/about-the-author/dog-that-copies-other-people-essay.md @@ -0,0 +1,57 @@ +--- +title: 抄袭狗，你冬天睡觉脚必冷！！！ +category: 走近作者 +tag: + - 杂谈 +--- + +抄袭狗真的太烦了。。。 + +听朋友说我的文章在知乎又被盗了，原封不动地被别人用来引流。 + +![](https://img-blog.csdnimg.cn/2e1416ba2d88460fbacc8ac265fef70a.png) + +而且！！！这还不是最气的。 + +这人还在文末注明的原出处还不是我的。。。 + +![](https://img-blog.csdnimg.cn/6087471b7b9449dcb3c8b593953ad895.png) + +也就是说 CSDN 有另外一位抄袭狗盗了我的这篇文章并声明了原创，知乎抄袭狗又原封不动地搬运了这位 CSDN 抄袭狗的文章。 + +真可谓离谱他妈给离谱开门，离谱到家了。 + +![](https://img-blog.csdnimg.cn/351cee184cac4af6a6e9f3ae18a4dd90.png) + +我打开知乎抄袭狗注明的原出处链接，好家伙，一模一样的内容，还表明了原创。 + +![](https://img-blog.csdnimg.cn/f0740bfac9ea4490815d827c6a69e498.png) + +看了一下 CSDN 这位抄袭狗的文章，好家伙，把我高赞回答搬运了一个遍。。。真是很勤奋了。。。 + +CSDN 我就不想多说了，就一大型文章垃圾场，都是各种不规范转载，各种收费下载的垃圾资源。这号称国内流量最大的技术网站贼恶心，吃香太难看，能不用就不要用吧！ + +像我自己平时用 Google 搜索的时候，都是直接屏蔽掉 CSDN 这个站点的。只需要下载一个叫做 Personal Blocklist 的 Chrome 插件，然后将 blog.csdn.net 添加进黑名单就可以了。 + +![](https://img-blog.csdnimg.cn/40ce678411834a708088d8d0af4dca1f.png) + +我的文章基本被盗完了，关键是我自己发没有什么流量，反而是盗我文章的那些人比我这个原作者流量还大。 + +这是什么世道，是人性的扭曲还是道德的沦丧？ + +不过，也没啥，CSDN 这垃圾网站不去发文也无妨。 + +看看 CSDN 热榜上的文章都是一些什么垃圾，不是各种广告就是一些毫无质量的拼凑文。 + +![](https://img-blog.csdnimg.cn/ed9b415bbe7e49a5afde4825aa807a90.png) + +当然了，也有极少部分的高质量文章，比如涛哥、二哥、冰河、微观技术等博主的文章。 + +还有很多视频平台（比如抖音、哔哩哔哩）上面有很多博主直接把别人的原创拿来做个视频，用来引流或者吸粉。 + +今天提到的这篇被盗的文章曾经就被一个培训机构拿去做成了视频用来引流。 + +![](https://img-blog.csdnimg.cn/58326aebd4514f8db9b8531f79642d6f.png) + +作为个体，咱也没啥办法，只能遇到一个举报一个。。。 + diff --git a/docs/about-the-author/feelings-after-one-month-of-induction-training.md b/docs/about-the-author/feelings-after-one-month-of-induction-training.md new file mode 100644 index 0000000000000000000000000000000000000000..bd21a09b05a60d4bdae6a4100e310ecba44fdaab --- /dev/null +++ b/docs/about-the-author/feelings-after-one-month-of-induction-training.md @@ -0,0 +1,24 @@ +--- +title: 入职培训一个月后的感受 +category: 走近作者 +tag: + - 个人经历 +--- + +不知不觉已经入职一个多月了，在入职之前我没有在某个公司实习过或者工作过，所以很多东西刚入职工作的我来说还是比较新颖的。学校到职场的转变，带来了角色的转变，其中的差别因人而异。对我而言，在学校的时候课堂上老师课堂上教的东西，自己会根据自己的兴趣选择性接受，甚至很多课程你不想去上的话，还可以逃掉。到了公司就不一样了，公司要求你会的技能你不得不学，除非你不想干了。在学校的时候大部分人编程的目的都是为了通过考试或者找到一份好工作，真正靠自己兴趣支撑起来的很少，到了工作岗位之后我们编程更多的是因为工作的要求，相比于学校的来说会一般会更有挑战而且压力更大。在学校的时候，我们最重要的就是对自己负责，我们不断学习知识去武装自己，但是到了公司之后我们不光要对自己负责，更要对公司负责，毕竟公司出钱请你过来，不是让你一直 on beach 的。 + +刚来公司的时候，因为公司要求，我换上了 Mac 电脑。由于之前一直用的是 Windows 系统，所以非常不习惯。刚开始用 Mac 系统的时候笨手笨脚，自己会很明显的感觉自己的编程效率降低了至少 3 成。当时内心还是挺不爽的，心里也总是抱怨为什么不直接用 Windows 系统或者 Linux 系统。不过也挺奇怪，大概一个星期之后，自己就开始慢慢适应使用 Mac 进行编程，甚至非常喜欢。我这里不想对比 Mac 和 Windows 编程体验哪一个更好，我觉得还是因人而异，相同价位的 Mac 的配置相比于 Windows确实要被甩几条街。不过 Mac 的编程和使用体验确实不错，当然你也可以选择使用 Linux 进行日常开发，相信一定很不错。 另外，Mac 不能玩一些主流网络游戏，对于一些克制不住自己想玩游戏的朋友是一个不错的选择。 + +不得不说 ThoughtWorks 的培训机制还是很不错的。应届生入职之后一般都会安排培训，与往年不同的是，今年的培训多了中国本地班（TWU-C）。作为本地班的第一期学员，说句心里话还是很不错。8周的培训，除了工作需要用到的基本技术比如ES6、SpringBoot等等之外，还会增加一些新员工基本技能的培训比如如何高效开会、如何给别人正确的提 Feedback、如何对代码进行重构、如何进行 TDD 等等。培训期间不定期的有活动，比如Weekend Trip、 City Tour、Cake time等等。最后三周还会有一个实际的模拟项目，这个项目基本和我们正式工作的实际项目差不多，我个人感觉很不错。目前这个项目已经正式完成了一个迭代，我觉得在做项目的过程中，收获最大的不是项目中使用的技术，而是如何进行团队合作、如何正确使用 Git 团队协同开发、一个完成的迭代是什么样子的、做项目的过程中可能遇到那些问题、一个项目运作的完整流程等等。 + +ThoughtWorks 非常提倡分享、提倡帮助他人成长，这一点在公司的这段时间深有感触。培训期间，我们每个人会有一个 Trainer 负责，Trainer 就是日常带我们上课和做项目的同事，一个 Trainer 大概会负责5-6个人。Trainer不定期都会给我们最近表现的 Feedback( 反馈) ，我个人觉得这个并不是这是走走形式，Trainer 们都很负责，很多时候都是在下班之后找我们聊天。同事们也都很热心，如果你遇到问题，向别人询问，其他人如果知道的话一般都会毫无保留的告诉你，如果遇到大部分都不懂的问题，甚至会组织一次技术 Session 分享。上周五我在我们小组内进行了一次关于 Feign 远程调用的技术分享，因为 team 里面大家对这部分知识都不太熟悉，但是后面的项目进展大概率会用到这部分知识。我刚好研究了这部分内容，所以就分享给了组内的其他同事，以便于项目更好的进行。 + + 另外，ThoughtWorks 也是一家非常提倡 Feedback( 反馈) 文化的公司，反馈是告诉人们我们对他们的表现的看法以及他们应该如何更好地做到这一点。刚开始我并没有太在意，慢慢地自己确实感觉到正确的进行反馈对他人会有很大的帮助。因为人在做很多事情的时候，会很难发现别人很容易看到的一些小问题。就比如一个很有趣的现象一样，假如我们在做项目的时候没有测试这个角色，如果你完成了自己的模块，并且自己对这个模块测试了很多遍，你发现已经没啥问题了。但是，到了实际使用的时候会很大概率出现你之前从来没有注意的问题。解释这个问题的说法是：每个人的视野或多或少都是有盲点的，这与我们的关注点息息相关。对于自己做的东西，很多地方自己测试很多遍都不会发现，但是如果让其他人帮你进行测试的话，就很大可能会发现很多显而易见的问题。 + +![](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/2019-7/feedback.png) + +工作之后，平时更新公众号、专栏还有维护 Github 的时间变少了。实际上，很多时候下班回来后，都有自己的时间来干自己的事情，但是自己也总是找工作太累或者时间比较零散的接口来推掉了。到了今天，翻看 Github 突然发现 14 天前别人在 Github 上给我提的 pr 我还没有处理。这一点确实是自己没有做好的地方，没有合理安排好自己的时间。实际上自己有很多想写的东西，后面会慢慢将他们提上日程。工作之后，更加发现下班后的几个小时如何度过确实很重要 ，如果你觉得自己没有完成好自己白天该做的工作的话，下班后你可以继续忙白天没有忙完的工作，如果白天的工作对于你游刃有余的话，下班回来之后，你大可去干自己感兴趣的事情，学习自己感兴趣的技术。做任何事情都要基于自身的基础，切不可好高骛远。 + +工作之后身边也会有很多厉害的人，多从他人身上学习我觉得是每个职场人都应该做的。这一届和我们一起培训的同事中，有一些技术很厉害的，也有一些技术虽然不是那么厉害，但是组织能力以及团队协作能力特别厉害的。有一个特别厉害的同事，在我们还在学 SpringBoot 各种语法的时候，他自己利用业余时间写了一个简化版的 SpringBoot ，涵盖了 Spring 的一些常用注解比如 `@RestController`、`@Autowried`、`@Pathvairable`、`@RestquestParam`等等（已经联系这位同事，想让他开源一下，后面会第一时间同步到公众号，期待一下吧！）。我觉得这位同事对于编程是真的有兴趣，他好像从初中就开始接触编程了，对于各种底层知识也非常感兴趣，自己写过实现过很多比较底层的东西。他的梦想是在 Github 上造一个 20k Star 以上的轮子。我相信以这位同事的能力一定会达成目标的，在这里祝福这位同事，希望他可以尽快实现这个目标。 + +这是我入职一个多月之后的个人感受，很多地方都是一带而过，后面我会抽时间分享自己在公司或者业余学到的比较有用的知识给各位，希望看过的人都能有所收获。 \ No newline at end of file diff --git a/docs/about-the-author/feelings-of-half-a-year-from-graduation-to-entry.md b/docs/about-the-author/feelings-of-half-a-year-from-graduation-to-entry.md new file mode 100644 index 0000000000000000000000000000000000000000..5557cb7fb87ddbd33a447a16124a4316de49dc7f --- /dev/null +++ b/docs/about-the-author/feelings-of-half-a-year-from-graduation-to-entry.md @@ -0,0 +1,56 @@ +--- +title: 从毕业到入职半年的感受 +category: 走近作者 +tag: + - 个人经历 +--- + +如果大家看过我之前的介绍的话，就会知道我是 19 年毕业的几百万应届毕业生中的一员。这篇文章主要讲了一下我入职大半年的感受，文中有很多自己的主观感受，如果你们有任何不认同的地方都可以直接在评论区说出来， 会很尊重其他人的想法。 + +简单说一下自己的情况吧！我目前是在一家外企，每天的工作和大部分人一样就是做开发。毕业到现在，差不多也算是工作半年多了，也已经过了公司 6 个月的试用期。目前在公司做过两个偏向于业务方向的项目，其中一个正在做。你很难想象我在公司做的两个业务项目的后端都没有涉及到分布式/微服务，没有接触到 Redis、Kafka 等等比较“高大上”的技术在项目中的实际运用。 + +第一个项目做的是公司的内部项目——员工成长系统。抛去员工成长系统这个名字，实际上这个系统做的就是绩效考核比如你在某个项目组的表现。这个项目的技术是 Spring Boot+ JPA+Spring Security + K8S+Docker+React。第二个目前正在做的是一个集成游戏（cocos）、Web 管理端(Spring Boot+Vue)和小程序（Taro）项目。 + +是的，我在工作中的大部分时间都和 CRUD 有关，每天也会写前端页面。之前我认识的一个朋友 ，他听说我做的项目中大部分内容都是写业务代码之后就非常纳闷，他觉得单纯写业务代码得不到提升？what?你一个应届生，连业务代码都写不好你给我说这个！所以，**我就很纳闷不知道为什么现在很多连业务代码都写不好的人为什么人听到 CRUD 就会反感？至少我觉得在我工作这段时间我的代码质量得到了提升、定位问题的能力有了很大的改进、对于业务有了更深的认识，自己也可以独立完成一些前端的开发了。** + +其实，我个人觉得能把业务代码写好也没那么容易，抱怨自己天天做 CRUD 工作之前，看看自己 CRUD 的代码写好没。再换句话说，单纯写 CRUD 的过程中你搞懂了哪些你常用的注解或者类吗？这就像一个只会 `@Service`、`@Autowired`、`@RestController`等等最简单的注解的人说我已经掌握了 Spring Boot 一样。 + +不知道什么时候开始大家都会觉得有实际使用 Redis、MQ 的经验就很牛逼了， 这可能和当前的面试环境有关系。你需要和别人有差异，你想进大厂的话，好像就必须要这些技术比较在行，好吧，没有好像，自信点来说对于大部分求职者这些技术都是默认你必备的了。 + +**实话实说，我在大学的时候就陷入过这个“伪命题”中**。在大学的时候，我大二因为加入了一个学校的偏技术方向的校媒才接触到 Java ，当时我们学习 Java 的目的就是开发一个校园通。 大二的时候，编程相当于才入门水平的我才接触 Java，花了一段时间才掌握 Java 基础。然后，就开始学习安卓开发。 + +到了大三上学期，我才真正确定要走 Java 后台的方向，找 Java 后台的开发工作。学习了 3 个月左右的 WEB 开发基础之后，我就开始学习分布式方面内容比如 Redis、Dubbo 这些。我当时是通过看书+视频+博客的方式学习的，自学过程中通过看视频自己做过两个完整的项目，一个普通的业务系统，一个是分布式的系统。**我当时以为自己做完之后就很牛逼了，我觉得普通的 CRUD 工作已经不符合我当前的水平了。哈哈！现在看来，当时的我过于哈皮！** + +这不！到了大三暑假跟着老师一起做项目的时候就出问题了。大三的时候，我们跟着老师做的是一个绩效考核系统，业务复杂程度中等。这个项目的技术用的是：SSM+Shiro+JSP。当时，做这个项目的时候我遇到各种问题，各种我以为我会写的代码都不会写了，甚至我写一个简单的 CRUD 都要花费好几天的时间。所以，那时候我都是边复习边学习边写代码。虽然很累，但是，那时候学到了很多，也让我在技术面前变得更加踏实。我觉得这“**这个项目已经没有维护的可能性**”这句话是我对我过的这个项目最大的否定了。 + +技术千变万化，掌握最核心的才是王道。我们前几年可能还在用 Spring 基于传统的 XML 开发，现在几乎大家都会用 Spring Boot 这个开发利器来提升开发速度，再比如几年前我们使用消息队列可能还在用 ActiveMQ，到今天几乎都没有人用它了，现在比较常用的就是 Rocket MQ、Kafka 。技术更新换代这么快的今天，你是无法把每一个框架/工具都学习一遍的， 。 + +**很多初学者上来就想通过做项目学习，特别是在公司，我觉得这个是不太可取的。** 如果的 Java 基础或者 Spring Boot 基础不好的话，建议自己先提前学习一下之后再开始看视频或者通过其他方式做项目。 **还有一点就是，我不知道为什么大家都会说边跟着项目边学习做的话效果最好，我觉得这个要加一个前提是你对这门技术有基本的了解或者说你对编程有了一定的了解。** + +**划重点！！！在自己基础没打牢的情况下，单纯跟着视频做一点用没有。你会发现你看完视频之后，让你自己写代码的时候又不会写了。** + +不知道其他公司的程序员是怎么样的？我感觉技术积累很大程度在乎平时，单纯依靠工作绝大部分情况只会加快自己做需求的熟练度，当然，写多了之后或多或少也会提升你对代码质量的认识（前提是你有这个意识）。 + +工作之余，我会利用业余时间来学习自己想学的东西。工作中的例子就是我刚进公司的第一个项目用到了 Spring Security+JWT ,因为当时自己对于这个技术不太了解，然后就在工作之外大概花了一周的时间学习写了一个 Demo 分享了出来,Github 地址：https://github.com/Snailclimb/spring-security-jwt-guide 。以次为契机，我还分享了 + +- [《一问带你区分清楚 Authentication,Authorization 以及 Cookie、Session、Token》](https://mp.weixin.qq.com/s?__biz=Mzg2OTA0Njk0OA==&mid=2247485626&idx=1&sn=3247aa9000693dd692de8a04ccffeec1&chksm=cea24771f9d5ce675ea0203633a95b68bfe412dc6a9d05f22d221161147b76161d1b470d54b3&token=684071313&lang=zh_CN&scene=21#wechat_redirect) +- [JWT 身份认证优缺点分析以及常见问题解决方案](https://mp.weixin.qq.com/s?__biz=Mzg2OTA0Njk0OA==&mid=2247485655&idx=1&sn=583eeeb081ea21a8ec6347c72aa223d6&chksm=cea2471cf9d5ce0aa135f2fb9aa32d98ebb3338292beaccc1aae43d1178b16c0125eb4139ca4&token=1737409938&lang=zh_CN#rd) + +另外一个最近的例子是因为肺炎疫情在家的这段时间，自学了 Kafka，并且正在准备写一系列的入门文章，目前已经完成了： + +1. 大白话 Kafka 入门； +2. Kafka 安装和基本功能体验； +3. Spring Boot 整合 Kafka 发送和接受消息； +4. Spring Boot 整合 Kafka 发送和接受消息的一些事务、错误消息处理等等。 + +还没完成的： + +1. Kafka 高级特性比如工作流程、Kafka 为什么快等等的分析； + +2. 源码阅读分析； + +3. ...... + +**所以，我觉得技术的积累和沉淀很大程度在乎工作之外的时间(大佬和一些本身就特别厉害的除外)。** + +**未来还有很长的路要走，即使再有精力也学不完你想学的所有技术，适当取舍、适当妥协，适当娱乐。** \ No newline at end of file diff --git a/docs/about-the-author/internet-addiction-teenager.md b/docs/about-the-author/internet-addiction-teenager.md new file mode 100644 index 0000000000000000000000000000000000000000..8c938dfb72df0773c3449cd2cfe65e10179ec342 --- /dev/null +++ b/docs/about-the-author/internet-addiction-teenager.md @@ -0,0 +1,109 @@ +--- +title: 我曾经也是网瘾少年 +category: 走近作者 +tag: + - 个人经历 +--- + +聊到高考，无数人都似乎有很多话说。今天就假借高考的名义，**简单**来聊聊我的求学经历吧！因为我自己的求学经历真的还不算平淡，甚至有点魔幻，所以还是有很多话想要说的。这篇文章大概会从我的初中一直介绍到大学，每一部分我都不会花太多篇幅。实际上，每一段经历我都可以增加很多“有趣”的经历，考虑到篇幅问题，以后有机会再慢慢说吧！ + +整个初中我都属于有点网瘾少年的状态，不过初三的时候稍微克制一些。到了高二下学期的时候，自己才对游戏没有真的没有那么沉迷了。 + +另外，关于大学的详细经历我已经在写了。想要知道我是如何从一个普通的不能再普通的少年慢慢成长起来的朋友不要错过~ + +![](https://cdn.jsdelivr.net/gh/javaguide-tech/blog-images/2020-08/0e370ac2-5f96-4e17-9ff4-8cc78ef72f19-20200802173544441.png) + +**以下所有内容皆是事实，没有任何夸大的地方，稍微有一点点魔幻。** + +## 01 刚开始接触电脑 + +最开始接触电脑是在我五年级的时候，那时候家里没电脑，都是在黑网吧玩的。我现在已经记不清当时是被哥哥还是姐姐带进网吧的了。 + +起初的时候，自己就是玩玩流行蝴蝶剑、单机摩托之类的单机游戏。但是，也没有到沉迷的地步，只是觉得这东西确实挺好玩的。 + +![](https://cdn.jsdelivr.net/gh/javaguide-tech/blog-images/2020-08/2a6021b9-e7a0-41c4-b69e-a652f7bc3e12-20200802173601289.png) + +开始有网瘾是在小学毕业的时候，在我玩了一款叫做 **QQ 飞车**的游戏之后（好像是六年级就开始玩了）。我艹，当时真的被这游戏吸引了。**每天上课都幻想自己坐在车里面飘逸，没错，当时就觉得秋名山车神就是我啦！** + +我记得，那时候上网还不要身份证，10 元办一张网卡就行了，网费也是一元一小时。但凡，我口袋里有余钱，我都会和我的小伙伴奔跑到网吧一起玩 QQ 飞车。Guide 的青回啊！说到这，我情不自禁地打开自己的 Windows 电脑，下载了 Wegame ，然后下载了 QQ 飞车。 + +到了初二的时候，就没玩 QQ 飞车了。我的等级也永久定格在了 **120** 级，这个等级在当时那个升级难的一匹的年代，算的上非常高的等级了。 + +![](https://guide-blog-images.oss-cn-shenzhen.aliyuncs.com/javaguide/b488618c-3c25-4bc9-afd4-7324e27553bd-20200802175534614.png) + +## 02 初二网瘾爆发 + +网瘾爆发是在上了初中之后。初二的时候，最为猖狂，自己当时真的是太痴迷 **穿越火线** 了，每天上课都在想像自己拿起枪横扫地方阵营的场景。除了周末在网吧度过之外，我经常每天早上还会起早去玩别人包夜留下的机子，毕竟那时候上学也没什么钱嘛！ + +![](https://guide-blog-images.oss-cn-shenzhen.aliyuncs.com/javaguide/9e94bb35-650d-4cad-8e69-40043fb4ec3d-20200802173632800.png) + +那时候成绩挺差的。这样说吧！我当时在很普通的一个县级市的高中，全年级有 500 来人，我基本都是在 280 名左右。 + +而且，整个初二我都没有学物理。因为开学不久的一次物理课，物理老师误会我在上课吃东西还狡辩，闪了我一巴掌。从此，我上物理课就睡觉，平常的物理考试就交白卷。那时候心里一直记仇，想着以后自己长大了再把这个物理老师暴打一顿。 + +初中时候的觉悟是在初三上学期的时候，当时就突然意识到自己马上就要升高中了。为了让自己能在家附近上学，因为当时我家就在我们当地的二中附近（_附近网吧多是主要原因，哈哈_）。年级前 80 的话基本才有可能考得上二中。**经过努力，初三上学期的第一次月考我直接从 280 多名进不到了年级 50 多名。当时，还因为进步太大，被当做进步之星在讲台上给整个年级做演讲。** 那也是我第一次在这么多人面前讲话，挺紧张的，但是挺爽的。 + +**其实在初三的时候，我的网瘾还是很大。不过，我去玩游戏的前提都是自己把所有任务做完，并且上课听讲也很认真。** 我参加高中提前考试前的一个晚上，我半夜12点乘着妈妈睡着，跑去了网吧玩CF到凌晨 3点多回来。那一次我被抓了现行，到家之后发现妈妈就坐在客厅等我，训斥一顿后，我就保证以后不再晚上偷偷跑出去了（*其实整个初二我通宵了无数次，每个周五晚上都回去通宵*）。 + +_这里要说明一点：我的智商我自己有自知之明的，属于比较普通的水平吧！ 前进很大的主要原因是自己基础还行，特别是英语和物理。英语是因为自己喜欢，加上小学就学了很多初中的英语课程。 物理的话就很奇怪，虽然初二也不怎么听物理课，也不会物理，但是到了初三之后自己就突然开窍了。真的！我现在都感觉很奇怪。然后，到了高中之后，我的英语和物理依然是我最好的两门课。大学的兼职，我出去做家教都是教的高中物理。_ + +后面，自己阴差阳错参加我们那个县级市的提前招生考试，然后就到了我们当地的二中，也没有参加中考。 + +## 03 高中生活 + +上了高中的之后，我上课就偷偷看小说，神印王座、斗罗大陆很多小说都是当时看的。中午和晚上回家之后，就在家里玩几把 DNF，当时家里也买了电脑。没记错的话，到我卸载 DNF 的时候已经练了 4 个满级的号。大量时间投入在游戏和小说上，我成功把自己从学校最好的小班玩到奥赛班，然后再到平行班。有点魔幻吧！ + +高中觉悟是在高二下学期的时候，当时是真的觉悟了，就突然觉得游戏不香了，觉得 DNF 也不好玩了。我妈妈当时还很诧异，还奇怪地问我：“怎么不玩游戏了？”（*我妈属于不怎么管我玩游戏的，她觉得这东西还是要靠自觉*）。 + +*当时，自己就感觉这游戏没啥意思了。内心的真实写照是：“我练了再多的满级的DNF账号有啥用啊？以后有钱了，直接氪金不久能很牛逼嘛！” 就突然觉悟了！* + +然后，我就开始牟足劲学习。当时，理科平行班大概有 7 个，每次考试都是平行班之间会单独拍一个名次。 后面的话，自己基本每次都能在平行班得第一，并且很多时候都是领先第二名个 30 来分。因为成绩还算亮眼，高三上学期快结束的时候，我就向年级主任申请去了奥赛班。 + +## 04 高考前的失眠 + +> **失败之后，不要抱怨外界因素，自始至终实际都是自己的问题，自己不够强大！** 然后，高考前的失眠也是我自己问题，要怪只能怪自己，别的没有任何接口。 + +我的高考经历其实还蛮坎坷的，毫不夸张的说，高考那今天可能是我到现在为止，经历的最难熬的时候，特别是在晚上。 + +我在高考那几天晚上都经历了失眠，想睡都睡不着那种痛苦想必很多人或许都体验过。 + +其实我在之前是从来没有过失眠的经历的。高考前夕，因为害怕自己睡不着，所以，我提前让妈妈去买了几瓶老师推荐的安神补脑液。我到现在还记得这个安神补脑液是敖东牌的。 + +高考那几天的失眠，我觉得可能和我喝了老师推荐的安神补脑液有关系，又或者是我自己太过于紧张了。因为那几天睡觉总会感觉有很多蚂蚁在身上爬一样，然后还起了一些小痘痘。 + +然后，这里要格外说明一点，避免引起误导： **睡不着本身就是自身的问题，上述言论并没有责怪这个补脑液的意思。** 另外， 这款安神补脑液我去各个平台都查了一下，发现大家对他的评价都挺好，和我们老师当时推荐的理由差不多。如果大家需要改善睡眠的话，可以咨询相关医生之后尝试一下。 + +## 05 还算充实的大学生活 + +高考成绩出来之后，比一本线高了 20 多分。自己挺不满意的，因为比平时考差了太多。加上自己泪点很低，就哭了一上午之后。后面，自我安慰说以后到了大学好好努力也是一样的。然后，我的第一志愿学校就报了长江大学，第一志愿专业就报了计算机专业。 + +后面，就开始了自己还算充实的大学生活。 + +大一的时候，满腔热血，对于高考结果的不满意，化作了我每天早起的动力。雷打不动，每天早上 6点左右就出去背英语单词。这也奠定了我后面的四六级都是一次过，并且六级的成绩还算不错。大一那年的暑假，我还去了孝感当了主管，几乎从无到有办了 5 个家教点。不过，其中两个家教点的话，是去年都已经办过的，没有其他几个那么费心。 + +![被我的学生 diss](https://guide-blog-images.oss-cn-shenzhen.aliyuncs.com/javaguide/5a47eb4614934a25b8ea1a83cafac43d-20200802173912511.png) + +大二的时候，加了学校一个偏技术方向的传媒组织（做网站、APP 之类的工作），后面成功当了副站长。在大二的时候，我才开始因为组织需要而接触 Java，不过当时主要学的是安卓开发。 + +![](https://guide-blog-images.oss-cn-shenzhen.aliyuncs.com/javaguide/b16201d0-37d4-462a-a5e6-bf95ca503d39-20200802174034108.png) + +大三的时候，正式确定自己要用 Java 语言找工作，并且要走 Java 后台（当时感觉安卓后台在求职时长太不吃香了）。我每天都在寝室学习 Java 后台开发，自己看视频，看书，做项目。我的开源项目 JavaGuide 和公众号都是这一年创建的。这一年，我大部分时间都是在寝室学习。带上耳机之后，即使室友在玩游戏或者追剧，都不会对我有什么影响。 + +我记得当时自己独立做项目的时候，遇到了很多问题。**就很多时候，你看书很容易就明白的东西，等到你实践的时候，总是会遇到一些小问题。我一般都是通过 Google 搜索解决的，用好搜索引擎真的能解决自己 99% 的问题。** + +![](https://cdn.jsdelivr.net/gh/javaguide-tech/blog-images/2020-08/d30eef29-3a73-483d-9a4a-d63f41271fb4-20200802174048832.png) + +大四的时候，开始找工作。我是参加的秋招，开始的较晚，基本很多公司都没有 HC 了。这点需要 diss 一下学校了，你其他地方都很好，但是，大四的时候就不要再上课点名了吧！然后，**希望国内的学校尽量能多给学生点机会吧！很多人连春招和秋招都不清楚，毕业了连实习都没实习过。** + +## 06 一些心里话 + +关于大学要努力学习专业知识、多去读书馆这类的鸡汤，Guide 就不多说了。就谈几条自己写这篇文章的时候，想到了一些心理话吧！ + +1. **不要抱怨学校** ：高考之后，不论你是 985、211 还是普通一本，再或者是 二本、三本，都不重要了，好好享受高考之后的生活。如果你觉得自己考的不满意的话，就去复读，没必要天天抱怨，复读的一年在你的人生长河里根本算不了什么的！ +2. **克制** ：大学的时候，克制住自己，诱惑太多了。你不去上课，在寝室睡到中午，都没人管你。你的努力不要只是感动自己！追求形式的努力不过是你打得幌子而已。到了社会之后，这个说法依然适用！ 说一个真实的发生在我身边的事情吧！高中的时候有一个特别特别特别努力的同班同学，家里的条件也很差，大学之前没有接触过手机和游戏。后来到了大学之后，因为接触了手机还有手机游戏，每天沉迷，不去上课。最后，直接就导致大学没读完就离开了。我听完我的好朋友给我说了之后，非常非常非常诧异！真的太可惜了！ +3. **不要总抱怨自己迷茫，多和优秀的学长学姐沟通交流。** +4. **不知道做什么的时候，就把手头的事情做好比如你的专业课学习。** + +*不论以前的自己是什么样，自己未来变成什么样自己是可以决定的，未来的路也终究还是要自己走。大环境下，大部分人都挺难的，当 996 成为了常态，Life Balance 是不可能的了。我们只能试着寻求一种平衡，试着去热爱自己现在所做的事情。* + +**往后余生，爱家人，亦爱自己；好好生活，不忧不恼。** diff --git a/docs/about-the-author/javaguide-100k-star.md b/docs/about-the-author/javaguide-100k-star.md new file mode 100644 index 0000000000000000000000000000000000000000..4dd4dd140843a76b71f6d10b17fc82133e0e38ab --- /dev/null +++ b/docs/about-the-author/javaguide-100k-star.md @@ -0,0 +1,42 @@ +--- +title: 1049天,100K Star！简单复盘 +category: 走近作者 +tag: + - 个人经历 +--- + +2021-03-21，晚上12点，肝完了我正在做的一个项目的前端的某块功能，我随手打开了[我的 Github 主页](https://github.com/Snailclimb)。 + +好家伙！几天没注意，[JavaGuide](https://github.com/Snailclimb/JavaGuide) 这个项目直接上了 100K star。 + +![JavaGuide 100k 里程碑](https://guide-blog-images.oss-cn-shenzhen.aliyuncs.com/github/javaguide/1&e=1643644799&token=kIxbL07-8jAj8w1n4s9zv64FuZZNEATmlU_Vm6zD:zANqh9HQEvvLPm6smyrjvjAt-Ik=.png) + +其实，这个真没啥好嘚瑟的。因为，教程类的含金量其实是比较低的，Star 数量比较多主要也是因为受众面比较广，大家觉得不错，点个 star 就相当于收藏了。很多特别优秀的框架，star 数量可能只有几 K。所以，单纯看 star 数量没啥意思，就当看个笑话吧！ + +![](https://guide-blog-images.oss-cn-shenzhen.aliyuncs.com/github/javaguide/20210323132635635.png) + +维护这个项目的过程中，也被某些人 diss 过：“md项目，没啥含金量，给国人丢脸！”。 + +对于说这类话的人，我觉得对我没啥影响，就持续完善，把 JavaGuide 做的更好吧！其实，国外的很多项目也是纯 MD 啊！就比如外国的朋友发起的 awesome 系列、求职面试系列。无需多说，行动自证！凎！ + +开源非常重要的一点就是协作。如果你开源了一个项目之后，就不再维护，别人给你提交 issue/pr，你都不处理，那开源也没啥意义了！ + +我的公号的小伙伴都是通过这个项目关注我的，趁着午休，简单复盘一下，也算是对关注这个项目的小伙伴负责。 + +我在大三开始准备秋招面试的时候，创建了 JavaGuide 这个项目，**2018-05-07** 这一天我提交了**第 1 个 commit**。 + +到今天（2021-03-23）为止，这个仓库已经累计有 **2933** 次 commit，累计有 **207** 位朋友参与到了项目中来。 + +![](https://img-blog.csdnimg.cn/20210323131344793.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM0MzM3Mjcy,size_16,color_FFFFFF,t_70) + +累计有 **511** 个 **issue** 和 **575** 个 **pr**。所有的 pr 都已经被处理，仅有15 个左右的 issue 我还未抽出时间处理。 + +![](https://img-blog.csdnimg.cn/20210323131632291.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM0MzM3Mjcy,size_16,color_FFFFFF,t_70) + +其实，相比于 star 数量，你看看仓库的 issue 和 pr 更能说明你的项目是否有价值。 + +那些到处骗 star 甚至是 刷 star 的行为，我就不多说了，有点丢人。人家觉得你的项目还不错，能提供价值，自然就给你点 star 了。 + +**未来几年，我还是会持续完善 JavaGuide。** + +**希望自己以后能开源一些有价值的轮子吧！继续加油！** \ No newline at end of file diff --git a/docs/about-the-author/my-article-was-stolen-and-made-into-video-and-it-became-popular.md b/docs/about-the-author/my-article-was-stolen-and-made-into-video-and-it-became-popular.md new file mode 100644 index 0000000000000000000000000000000000000000..58d3ffbcc1917c1f37dfbf5d1c84f9cffa2cd1d6 --- /dev/null +++ b/docs/about-the-author/my-article-was-stolen-and-made-into-video-and-it-became-popular.md @@ -0,0 +1,72 @@ +--- +title: 某培训机构盗我文章做成视频还上了B站热门 +category: 走近作者 +tag: + - 杂谈 +--- + +时间回到 2021-02-25，我在刷哔哩哔哩的时候发现，哔哩哔哩某UP主（某培训机构），擅自将我在知乎的一个回答做成了视频。 + +原滋原味啊！我艹。甚至，连我开头的自我调侃还加上了！真的牛皮！ + +你盗我原创，视频你用心做好点也行啊！至少也可以让这么优质的内容得到传播嘛！ + +结果，好家伙，视频做的像坨屎一样，配音也贼违和! + +麻烦这个培训机构看到这篇文章之后可以考虑换一个人做类似恶心的事情哈！这人完全没脑子啊！ + +![](https://oscimg.oschina.net/oscnet/up-db6b9cf323930786fa2bec8b1e1bfaad732.png) + +![](https://oscimg.oschina.net/oscnet/up-6395603ab441b74511c6eda28efee8937d7.png) + +![](https://oscimg.oschina.net/oscnet/up-921f60a5c7cee2c5c2eb30f4f7048f648e1.png) + +![](https://oscimg.oschina.net/oscnet/up-acc82a797bd01e27f5b7d5d327b32a21d4e.png) + +我随便找了一个视频看，发现也还是盗用别人的原创。 + +![](https://oscimg.oschina.net/oscnet/up-48d0c5ab086265ae19b7396bc59de2c2daf.png) + +![](https://oscimg.oschina.net/oscnet/up-366abf0656007ff96551064104e60740a41.png) + +其他的视频就不用多看了，是否还是剽窃别人的原创，原封不动地做成视频，大家心里应该有数。 + +他们这样做的目的就是一个：**引流到自己的QQ群，然后忽悠你买课程。** + +我并不认为是这完全都是培训机构的问题。培训机构的员工为了流量而做这种恶心的事情，也导致了现在这种事情被越来越频繁地发生。 + +所以，你会发现，哔哩哔哩和知乎上有越来越多培训机构的小号，到处剽窃原创，盗发。 + +我身边很多原创号主的文章都经常被某些培训机构盗发。 + +有时候真的会比较生气，毕竟你自己辛辛苦苦的原创，别人复制粘贴一下就白嫖了！ + +但是，我相信，这种靠剽窃别人原创来吸引流量的行为，终究只是跳梁小丑的行为罢了！ + +只有那些用心输出内容的创作者，才能走的更远，更安稳！ + +后来，我在我的公众号上发了一篇名为[《好家伙！某培训机构盗我文章做成视频还上了热门》](https://mp.weixin.qq.com/s?__biz=Mzg2OTA0Njk0OA==&mid=2247500005&idx=1&sn=7351e22619654492d3cf567bff9d87f0&chksm=cea18f2ef9d606384e0265b9318e004646c03b8a69f2801698d2f9e0e6bdfec0a1185ac3ab17&token=2146952532&lang=zh_CN&scene=21#wechat_redirect) 的文章，吐槽自己的原创被某机构白嫖。 + +谁能想到，培训机构的人竟然找人来让我删文章了！讲真，这俩人是真的奇葩啊！ + +![](https://guide-blog-images.oss-cn-shenzhen.aliyuncs.com/javaguide/8f8ccafcf5b764a2289a9c276c30728d.png) + +![](https://guide-blog-images.oss-cn-shenzhen.aliyuncs.com/javaguide/a0a4a45d7ec7b1a2622b2a38629e9b09.png) + +还让我格局大点？我去你丫的！明明就是我的原创，你自己不删，反而找人联系我删除！有脑子不？ + +其实，我这人是比较好说话的，现实生活中脾气也是出了名的好（前提是没有触犯到我的原则的情况）。 + +搞笑的是！他们在让我删文的同时，他们 B 站盗发的视频还都在，还在继续为他们引流。 + +![](https://guide-blog-images.oss-cn-shenzhen.aliyuncs.com/javaguide/86f659a93ce5b639526c8d2bd20b2fbe.png) + +![](https://img-blog.csdnimg.cn/img_convert/be6e0fd23146de3f6224b4d853c59ce7.png) + +如果他们把账号注销了，我或许还能考虑放一手。但是，文章是肯定不会删的。 + +现在，看后续情况吧！我随时可以动用法律来维护自己的权益，只是看我想不想，毕竟也挺麻烦对吧！ + +大家不用担心，这都是小事，我女朋友就是学法律的，国内的某法学双一流学校。 + +咱不怕事！凎！！！ \ No newline at end of file diff --git a/docs/about-the-author/readme.md b/docs/about-the-author/readme.md new file mode 100644 index 0000000000000000000000000000000000000000..ff98eecd6f6dd5727edc5326d6cb12ab62da2c7a --- /dev/null +++ b/docs/about-the-author/readme.md @@ -0,0 +1,63 @@ +--- +title: 个人介绍 Q&A +category: 走近作者 +--- + +大家好，我是 Gudie哥！这篇文章我会通过 Q&A 的形式简单介绍一下我自己。 + +## 我是什么时候毕业的？ + +很多老读者应该比较清楚，我是 19 年本科毕业的，刚毕业就去了某家外企“养老”。 + +我的学校背景是比较差的，高考失利，勉强过了一本线 20 来分，去了荆州的一所很普通的双非一本。不过，还好我没有因为学校而放弃自己，反倒是比身边的同学都要更努力，整个大学还算过的比较充实。 + +下面这张是当时拍的毕业照（后排最中间的就是我）： + +![](https://guide-blog-images.oss-cn-shenzhen.aliyuncs.com/javaguide/%E4%B8%AA%E4%BA%BA%E4%BB%8B%E7%BB%8D.png) + +## 我坚持写了多久博客？ + +时间真快啊！我自己是从大二开始写博客的。那时候就是随意地在博客平台上发发自己的学习笔记和自己写的程序。就比如 [谢希仁老师的《计算机网络》内容总结](https://javaguide.cn/cs-basics/network/%E8%B0%A2%E5%B8%8C%E4%BB%81%E8%80%81%E5%B8%88%E7%9A%84%E3%80%8A%E8%AE%A1%E7%AE%97%E6%9C%BA%E7%BD%91%E7%BB%9C%E3%80%8B%E5%86%85%E5%AE%B9%E6%80%BB%E7%BB%93/) 这篇文章就是我在大二学习计算机网络这门课的时候对照着教材总结的。 + +身边也有很多小伙伴经常问我：“我现在写博客还晚么？” + +我觉得哈！如果你想做什么事情，尽量少问迟不迟，多问自己值不值得，只要你觉得有意义，就尽快开始做吧！人生很奇妙，我们每一步的重大决定，都会对自己未来的人生轨迹产生影响。是好还是坏，也只有我们自己知道了！ + +对我自己来说，坚持写博客这一项决定对我人生轨迹产生的影响是非常正面的！所以，我也推荐大家养成坚持写博客的习惯。 + +## 我在大学期间赚了多少钱？ + +在校期间，我还通过办培训班、接私活、技术培训、编程竞赛等方式变现 20w+，成功实现“经济独立”。我用自己赚的钱去了重庆、三亚、恩施、青岛等地旅游，还给家里补贴了很多，减轻了父母的负担。 + +下面这张是我大一下学期办补习班的时候拍的（离开前的最后一顿饭）： + +![补习班的最后一顿晚餐](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/f36bfd719b9b4463b2f1d3edc51faa97~tplv-k3u1fbpfcp-zoom-1.image) + +下面这张是我大三去三亚的时候拍的： + +![](https://guide-blog-images.oss-cn-shenzhen.aliyuncs.com/javaguide/psc.jpeg) + +其实，我在大学就这么努力地开始赚钱，也主要是因为家庭条件太一般，父母赚钱都太辛苦了！也正是因为我自己迫切地想要减轻父母的负担，所以才会去尝试这么多赚钱的方法。 + +我发现做咱们程序员这行的，很多人的家庭条件都挺一般的，选择这个行业的很大原因不是因为自己喜欢，而是为了多赚点钱。 + +如果你也想通过接私活变现的话，可以在我的公众号后台回复“**接私活**”来了解一些我的个人经验分享。 + +![](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/2020-8/1d38ea3b-da2a-41df-9ac4-087356e9b5b4-20200802185910087.png) + +## 为什么自称 Guide哥？ + +可能是因为我的项目名字叫做 JavaGudie , 所以导致有很多人称呼我为 **Guide哥**。 + +后面，为了读者更方便称呼，我就将自己的笔名改成了 **Guide哥**。 + +我早期写文章用的笔名是 SnailClimb 。很多人不知道这个名字是啥意思，给大家拆解一下就清楚了。SnailClimb=Snail（蜗牛）+Climb(攀登)。我从小就非常喜欢听周杰伦的歌曲，特别是他的《蜗牛》🐌 这首歌曲，另外，当年我高考发挥的算是比较失常，上了大学之后还算是比较“奋青”，所以，我就给自己起的笔名叫做 SnailClimb ，寓意自己要不断向上攀登，嘿嘿😁 + +![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/37599546f3b34b92a32db579a225aa45~tplv-k3u1fbpfcp-watermark.image) + +## 后记 + +凡心所向，素履所往，生如逆旅，一苇以航。 + +生活本就是有苦有甜。共勉！ + diff --git "a/\346\225\260\346\215\256\347\273\223\346\236\204\344\270\216\347\256\227\346\263\225/Leetcode-LinkList1.md" b/docs/cs-basics/algorithms/linkedlist-algorithm-problems.md similarity index 88% rename from "\346\225\260\346\215\256\347\273\223\346\236\204\344\270\216\347\256\227\346\263\225/Leetcode-LinkList1.md" rename to docs/cs-basics/algorithms/linkedlist-algorithm-problems.md index 79b74441debfec34a332b09807e85fc88310a324..1b64653cd9f317b98319ca344b02f4b32aa124b4 100644 --- "a/\346\225\260\346\215\256\347\273\223\346\236\204\344\270\216\347\256\227\346\263\225/Leetcode-LinkList1.md" +++ b/docs/cs-basics/algorithms/linkedlist-algorithm-problems.md @@ -1,29 +1,6 @@ - - -- [1. 两数相加](#1-两数相加) - - [题目描述](#题目描述) - - [问题分析](#问题分析) - - [Solution](#solution) -- [2. 翻转链表](#2-翻转链表) - - [题目描述](#题目描述-1) - - [问题分析](#问题分析-1) - - [Solution](#solution-1) -- [3. 链表中倒数第k个节点](#3-链表中倒数第k个节点) - - [题目描述](#题目描述-2) - - [问题分析](#问题分析-2) - - [Solution](#solution-2) -- [4. 删除链表的倒数第N个节点](#4-删除链表的倒数第n个节点) - - [问题分析](#问题分析-3) - - [Solution](#solution-3) -- [5. 合并两个排序的链表](#5-合并两个排序的链表) - - [题目描述](#题目描述-3) - - [问题分析](#问题分析-4) - - [Solution](#solution-4) - - - - -# 1. 两数相加 +# 几道常见的链表算法题 + +## 1. 两数相加 ### 题目描述 @@ -50,7 +27,7 @@ Leetcode官方详细解答地址： 我们使用变量来跟踪进位，并从包含最低有效位的表头开始模拟逐 位相加的过程。 -![图1，对两数相加方法的可视化: 342 + 465 = 807342+465=807， 每个结点都包含一个数字，并且数字按位逆序存储。](http://my-blog-to-use.oss-cn-beijing.aliyuncs.com/18-9-20/34910956.jpg) +![图1，对两数相加方法的可视化: 342 + 465 = 807342+465=807， 每个结点都包含一个数字，并且数字按位逆序存储。](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/18-9-20/34910956.jpg) ### Solution @@ -92,13 +69,13 @@ public ListNode addTwoNumbers(ListNode l1, ListNode l2) { } ``` -# 2. 翻转链表 +## 2. 翻转链表 ### 题目描述 > 剑指 offer:输入一个链表，反转链表后，输出链表的所有元素。 -![翻转链表](http://my-blog-to-use.oss-cn-beijing.aliyuncs.com/18-9-20/81431871.jpg) +![翻转链表](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/18-9-20/81431871.jpg) ### 问题分析 @@ -180,7 +157,7 @@ public class Solution { 1 ``` -# 3. 链表中倒数第k个节点 +## 3. 链表中倒数第k个节点 ### 题目描述 @@ -225,7 +202,7 @@ public class Solution { while (node1 != null) { node1 = node1.next; count++; - if (k < 1 && node1 != null) { + if (k < 1) { node2 = node2.next; } k--; @@ -240,7 +217,7 @@ public class Solution { ``` -# 4. 删除链表的倒数第N个节点 +## 4. 删除链表的倒数第N个节点 > Leetcode:给定一个链表，删除链表的倒数第 n 个节点，并且返回链表的头结点。 @@ -269,7 +246,7 @@ public class Solution { 我们注意到这个问题可以容易地简化成另一个问题：删除从列表开头数起的第 (L - n + 1)个结点，其中 L是列表的长度。只要我们找到列表的长度 L，这个问题就很容易解决。 -![图 1. 删除列表中的第 L - n + 1 个元素](http://my-blog-to-use.oss-cn-beijing.aliyuncs.com/18-9-20/94354387.jpg) +![图 1. 删除列表中的第 L - n + 1 个元素](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/18-9-20/94354387.jpg) ### Solution @@ -324,7 +301,7 @@ public class Solution { **进阶——一次遍历法：** -> **链表中倒数第N个节点也就是正数第(L-N+1)个节点。 +> 链表中倒数第N个节点也就是正数第(L-N+1)个节点。 其实这种方法就和我们上面第四题找“链表中倒数第k个节点”所用的思想是一样的。**基本思路就是：** 定义两个节点 node1、node2;node1 节点先跑，node1节点 跑到第 n+1 个节点的时候,node2 节点开始跑.当node1 节点跑到最后一个节点时，node2 节点所在的位置就是第 （L-n ） 个节点（L代表总链表长度，也就是倒数第 n+1 个节点） @@ -367,7 +344,7 @@ public class Solution { -# 5. 合并两个排序的链表 +## 5. 合并两个排序的链表 ### 题目描述 diff --git "a/\346\225\260\346\215\256\347\273\223\346\236\204\344\270\216\347\256\227\346\263\225/\346\220\236\345\256\232BAT\351\235\242\350\257\225\342\200\224\342\200\224\345\207\240\351\201\223\345\270\270\350\247\201\347\232\204\345\255\220\347\254\246\344\270\262\347\256\227\346\263\225\351\242\230.md" b/docs/cs-basics/algorithms/string-algorithm-problems.md similarity index 89% rename from "\346\225\260\346\215\256\347\273\223\346\236\204\344\270\216\347\256\227\346\263\225/\346\220\236\345\256\232BAT\351\235\242\350\257\225\342\200\224\342\200\224\345\207\240\351\201\223\345\270\270\350\247\201\347\232\204\345\255\220\347\254\246\344\270\262\347\256\227\346\263\225\351\242\230.md" rename to docs/cs-basics/algorithms/string-algorithm-problems.md index 938f4a48f1a526dc59a0315555ac259353abe292..ccd420c4dadd6eb7cd02f13a09df7b7a4229a304 100644 --- "a/\346\225\260\346\215\256\347\273\223\346\236\204\344\270\216\347\256\227\346\263\225/\346\220\236\345\256\232BAT\351\235\242\350\257\225\342\200\224\342\200\224\345\207\240\351\201\223\345\270\270\350\247\201\347\232\204\345\255\220\347\254\246\344\270\262\347\256\227\346\263\225\351\242\230.md" +++ b/docs/cs-basics/algorithms/string-algorithm-problems.md @@ -1,27 +1,10 @@ - +# 几道常见的字符串算法题 -- [说明](#说明) -- [1. KMP 算法](#1-kmp-算法) -- [2. 替换空格](#2-替换空格) -- [3. 最长公共前缀](#3-最长公共前缀) -- [4. 回文串](#4-回文串) - - [4.1. 最长回文串](#41-最长回文串) - - [4.2. 验证回文串](#42-验证回文串) - - [4.3. 最长回文子串](#43-最长回文子串) - - [4.4. 最长回文子序列](#44-最长回文子序列) -- [5. 括号匹配深度](#5-括号匹配深度) -- [6. 把字符串转换成整数](#6-把字符串转换成整数) +> 授权转载！ +> +> - 本文作者：wwwxmu +> - 原文地址:https://www.weiweiblog.cn/13string/ - - - -## 说明 - -- 本文作者：wwwxmu -- 原文地址:https://www.weiweiblog.cn/13string/ -- 作者的博客站点：https://www.weiweiblog.cn/ （推荐哦！） - -考虑到篇幅问题，我会分两次更新这个内容。本篇文章只是原文的一部分，我在原文的基础上增加了部分内容以及修改了部分代码和注释。另外，我增加了爱奇艺 2018 秋招 Java：`求给定合法括号序列的深度` 这道题。所有代码均编译成功，并带有注释，欢迎各位享用！ ## 1. KMP 算法 @@ -78,13 +61,19 @@ public class Solution { * 第二种方法：利用API替换掉所用空格，一行代码解决问题 */ public static String replaceSpace2(StringBuffer str) { - + return str.toString().replaceAll("\\s", "%20"); } } ``` +对于替换固定字符（比如空格）的情况，第二种方法其实可以使用 `replace` 方法替换，性能更好! + +```java +str.toString().replace(" ","%20"); +``` + ## 3. 最长公共前缀 > Leetcode: 编写一个函数来查找字符串数组中的最长公共前缀。如果不存在公共前缀，返回空字符串 ""。 @@ -112,7 +101,7 @@ public class Main { public static String replaceSpace(String[] strs) { // 如果检查值不合法及就返回空串 - if (!chechStrs(strs)) { + if (!checkStrs(strs)) { return ""; } // 数组长度 @@ -137,7 +126,6 @@ public class Main { private static boolean chechStrs(String[] strs) { boolean flag = false; - // 注意：=是赋值，==是判断 if (strs != null) { // 遍历strs检查元素值 for (int i = 0; i < strs.length; i++) { @@ -145,6 +133,7 @@ public class Main { flag = true; } else { flag = false; + break; } } } @@ -190,7 +179,7 @@ public class Main { 我们上面已经知道了什么是回文串？现在我们考虑一下可以构成回文串的两种情况： - 字符出现次数为双数的组合 -- 字符出现次数为双数的组合+一个只出现一次的字符 +- **字符出现次数为偶数的组合+单个字符中出现次数最多且为奇数次的字符** （参见 **[issue665](https://github.com/Snailclimb/JavaGuide/issues/665)** ） 统计字符出现的次数即可，双数才能构成回文。因为允许中间一个数单独出现，比如“abcba”，所以如果最后有字母落单，总长度可以加 1。首先将字符串转变为字符数组。然后遍历该数组，判断对应字符是否在hashset中，如果不在就加进去，如果在就让count++，然后移除该字符！这样就能找到出现次数为双数的字符个数。 @@ -282,10 +271,7 @@ class Solution { 输出: "bb" ``` -以某个元素为中心，分别计算偶数长度的回文最大长度和奇数长度的回文最大长度。给大家大致花了个草图，不要嫌弃！ - - -![](https://user-gold-cdn.xitu.io/2018/9/9/165bc32f6f1833ff?w=723&h=371&f=png&s=9305) +以某个元素为中心，分别计算偶数长度的回文最大长度和奇数长度的回文最大长度。 ```java //https://leetcode-cn.com/problems/longest-palindromic-substring/description/ @@ -399,11 +385,6 @@ class Solution { 2 ``` -思路草图： - - -![](https://user-gold-cdn.xitu.io/2018/9/9/165bc6fca94ef278?w=792&h=324&f=png&s=15868) - 代码如下： ```java @@ -463,7 +444,7 @@ public class Main { return 0; } } - return flag == 1 ? res : -res; + return flag != 2 ? res : -res; } diff --git a/docs/cs-basics/algorithms/the-sword-refers-to-offer.md b/docs/cs-basics/algorithms/the-sword-refers-to-offer.md new file mode 100644 index 0000000000000000000000000000000000000000..790422342fc01d52b6f188f5e208effc5308fead --- /dev/null +++ b/docs/cs-basics/algorithms/the-sword-refers-to-offer.md @@ -0,0 +1,681 @@ +# 剑指offer部分编程题 + +## 斐波那契数列 + +**题目描述：** + +大家都知道斐波那契数列，现在要求输入一个整数n，请你输出斐波那契数列的第n项。 +n<=39 + +**问题分析：** + +可以肯定的是这一题通过递归的方式是肯定能做出来，但是这样会有一个很大的问题，那就是递归大量的重复计算会导致内存溢出。另外可以使用迭代法，用fn1和fn2保存计算过程中的结果，并复用起来。下面我会把两个方法示例代码都给出来并给出两个方法的运行时间对比。 + +**示例代码：** + +采用迭代法： + +```java +int Fibonacci(int number) { + if (number <= 0) { + return 0; + } + if (number == 1 || number == 2) { + return 1; + } + int first = 1, second = 1, third = 0; + for (int i = 3; i <= number; i++) { + third = first + second; + first = second; + second = third; + } + return third; +} +``` + +采用递归： + +```java +public int Fibonacci(int n) { + if (n <= 0) { + return 0; + } + if (n == 1||n==2) { + return 1; + } + + return Fibonacci(n - 2) + Fibonacci(n - 1); +} +``` + +## 跳台阶问题 + +**题目描述：** + +一只青蛙一次可以跳上1级台阶，也可以跳上2级。求该青蛙跳上一个n级的台阶总共有多少种跳法。 + +**问题分析：** + +正常分析法： + +> a.如果两种跳法，1阶或者2阶，那么假定第一次跳的是一阶，那么剩下的是n-1个台阶，跳法是f(n-1); +> b.假定第一次跳的是2阶，那么剩下的是n-2个台阶，跳法是f(n-2) +> c.由a，b假设可以得出总跳法为: f(n) = f(n-1) + f(n-2) +> d.然后通过实际的情况可以得出：只有一阶的时候 f(1) = 1 ,只有两阶的时候可以有 f(2) = 2 + +找规律分析法： + +> f(1) = 1, f(2) = 2, f(3) = 3, f(4) = 5， 可以总结出f(n) = f(n-1) + f(n-2)的规律。但是为什么会出现这样的规律呢？假设现在6个台阶，我们可以从第5跳一步到6，这样的话有多少种方案跳到5就有多少种方案跳到6，另外我们也可以从4跳两步跳到6，跳到4有多少种方案的话，就有多少种方案跳到6，其他的不能从3跳到6什么的啦，所以最后就是f(6) = f(5) + f(4)；这样子也很好理解变态跳台阶的问题了。 + +**所以这道题其实就是斐波那契数列的问题。** + +代码只需要在上一题的代码稍做修改即可。和上一题唯一不同的就是这一题的初始元素变为 1 2 3 5 8.....而上一题为1 1 2 3 5 .......。另外这一题也可以用递归做，但是递归效率太低，所以我这里只给出了迭代方式的代码。 + +**示例代码：** + +```java +int jumpFloor(int number) { + if (number <= 0) { + return 0; + } + if (number == 1) { + return 1; + } + if (number == 2) { + return 2; + } + int first = 1, second = 2, third = 0; + for (int i = 3; i <= number; i++) { + third = first + second; + first = second; + second = third; + } + return third; +} +``` + +## 变态跳台阶问题 + +**题目描述：** + +一只青蛙一次可以跳上1级台阶，也可以跳上2级……它也可以跳上n级。求该青蛙跳上一个n级的台阶总共有多少种跳法。 + +**问题分析：** + +假设n>=2，第一步有n种跳法：跳1级、跳2级、到跳n级 +跳1级，剩下n-1级，则剩下跳法是f(n-1) +跳2级，剩下n-2级，则剩下跳法是f(n-2) +...... +跳n-1级，剩下1级，则剩下跳法是f(1) +跳n级，剩下0级，则剩下跳法是f(0) +所以在n>=2的情况下： +f(n)=f(n-1)+f(n-2)+...+f(1) +因为f(n-1)=f(n-2)+f(n-3)+...+f(1) +所以f(n)=2*f(n-1) 又f(1)=1,所以可得**f(n)=2^(number-1)** + +**示例代码：** + +```java +int JumpFloorII(int number) { + return 1 << --number;//2^(number-1)用位移操作进行，更快 +} +``` + +**补充：** + +java中有三种移位运算符： + +1. “<<” : **左移运算符**，等同于乘2的n次方 +2. “>>”: **右移运算符**，等同于除2的n次方 +3. “>>>” : **无符号右移运算符**，不管移动前最高位是0还是1，右移后左侧产生的空位部分都以0来填充。与>>类似。 + +```java +int a = 16; +int b = a << 2;//左移2，等同于16 * 2的2次方，也就是16 * 4 +int c = a >> 2;//右移2，等同于16 / 2的2次方，也就是16 / 4 +``` + + +## 二维数组查找 + +**题目描述：** + +在一个二维数组中，每一行都按照从左到右递增的顺序排序，每一列都按照从上到下递增的顺序排序。请完成一个函数，输入这样的一个二维数组和一个整数，判断数组中是否含有该整数。 + +**问题解析：** + +这一道题还是比较简单的，我们需要考虑的是如何做，效率最快。这里有一种很好理解的思路： + +> 矩阵是有序的，从左下角来看，向上数字递减，向右数字递增， +> 因此从左下角开始查找，当要查找数字比左下角数字大时。右移 +> 要查找数字比左下角数字小时，上移。这样找的速度最快。 + +**示例代码：** + +```java +public boolean Find(int target, int [][] array) { + //基本思路从左下角开始找，这样速度最快 + int row = array.length-1;//行 + int column = 0;//列 + //当行数大于0，当前列数小于总列数时循环条件成立 + while((row >= 0)&& (column< array[0].length)){ + if(array[row][column] > target){ + row--; + }else if(array[row][column] < target){ + column++; + }else{ + return true; + } + } + return false; +} +``` + +## 替换空格 + +**题目描述：** + +请实现一个函数，将一个字符串中的空格替换成“%20”。例如，当字符串为We Are Happy.则经过替换之后的字符串为We%20Are%20Happy。 + +**问题分析：** + +这道题不难，我们可以通过循环判断字符串的字符是否为空格，是的话就利用append()方法添加追加“%20”，否则还是追加原字符。 + +或者最简单的方法就是利用：replaceAll(String regex,String replacement)方法了，一行代码就可以解决。 + +**示例代码：** + +常规做法： + +```java +public String replaceSpace(StringBuffer str) { + StringBuffer out = new StringBuffer(); + for (int i = 0; i < str.toString().length(); i++) { + char b = str.charAt(i); + if(String.valueOf(b).equals(" ")){ + out.append("%20"); + }else{ + out.append(b); + } + } + return out.toString(); +} +``` + +一行代码解决： + +```java +public String replaceSpace(StringBuffer str) { + //return str.toString().replaceAll(" ", "%20"); + //public String replaceAll(String regex,String replacement) + //用给定的替换替换与给定的regular expression匹配的此字符串的每个子字符串。 + //\ 转义字符. 如果你要使用 "\" 本身, 则应该使用 "\\". String类型中的空格用“\s”表示，所以我这里猜测"\\s"就是代表空格的意思 + return str.toString().replaceAll("\\s", "%20"); +} +``` + +## 数值的整数次方 + +**题目描述：** + +给定一个double类型的浮点数base和int类型的整数exponent。求base的exponent次方。 + +**问题解析：** + +这道题算是比较麻烦和难一点的一个了。我这里采用的是**二分幂**思想，当然也可以采用**快速幂**。 +更具剑指offer书中细节，该题的解题思路如下： +1.当底数为0且指数<0时，会出现对0求倒数的情况，需进行错误处理，设置一个全局变量； +2.判断底数是否等于0，由于base为double型，所以不能直接用==判断 +3.优化求幂函数（二分幂）。 +当n为偶数，a^n =（a^n/2）*（a^n/2）； +当n为奇数，a^n = a^[(n-1)/2] * a^[(n-1)/2] * a。时间复杂度O(logn) + +**时间复杂度**：O(logn) + +**示例代码：** + +```java +public class Solution { + boolean invalidInput=false; + public double Power(double base, int exponent) { + //如果底数等于0并且指数小于0 + //由于base为double型，不能直接用==判断 + if(equal(base,0.0)&&exponent<0){ + invalidInput=true; + return 0.0; + } + int absexponent=exponent; + //如果指数小于0，将指数转正 + if(exponent<0) + absexponent=-exponent; + //getPower方法求出base的exponent次方。 + double res=getPower(base,absexponent); + //如果指数小于0，所得结果为上面求的结果的倒数 + if(exponent<0) + res=1.0/res; + return res; + } + //比较两个double型变量是否相等的方法 + boolean equal(double num1,double num2){ + if(num1-num2>-0.000001&&num1-num2<0.000001) + return true; + else + return false; + } + //求出b的e次方的方法 + double getPower(double b,int e){ + //如果指数为0，返回1 + if(e==0) + return 1.0; + //如果指数为1，返回b + if(e==1) + return b; + //e>>1相等于e/2，这里就是求a^n =（a^n/2）*（a^n/2） + double result=getPower(b,e>>1); + result*=result; + //如果指数n为奇数，则要再乘一次底数base + if((e&1)==1) + result*=b; + return result; + } +} +``` + +当然这一题也可以采用笨方法：累乘。不过这种方法的时间复杂度为O（n），这样没有前一种方法效率高。 + +```java +// 使用累乘 +public double powerAnother(double base, int exponent) { + double result = 1.0; + for (int i = 0; i < Math.abs(exponent); i++) { + result *= base; + } + if (exponent >= 0) + return result; + else + return 1 / result; +} +``` + +## 调整数组顺序使奇数位于偶数前面 + +**题目描述：** + +输入一个整数数组，实现一个函数来调整该数组中数字的顺序，使得所有的奇数位于数组的前半部分，所有的偶数位于位于数组的后半部分，并保证奇数和奇数，偶数和偶数之间的相对位置不变。 + +**问题解析：** + +这道题有挺多种解法的，给大家介绍一种我觉得挺好理解的方法： +我们首先统计奇数的个数假设为n,然后新建一个等长数组，然后通过循环判断原数组中的元素为偶数还是奇数。如果是则从数组下标0的元素开始，把该奇数添加到新数组；如果是偶数则从数组下标为n的元素开始把该偶数添加到新数组中。 + +**示例代码：** + +时间复杂度为O（n），空间复杂度为O（n）的算法 + +```java +public class Solution { + public void reOrderArray(int [] array) { + //如果数组长度等于0或者等于1，什么都不做直接返回 + if(array.length==0||array.length==1) + return; + //oddCount：保存奇数个数 + //oddBegin：奇数从数组头部开始添加 + int oddCount=0,oddBegin=0; + //新建一个数组 + int[] newArray=new int[array.length]; + //计算出（数组中的奇数个数）开始添加元素 + for(int i=0;i stack1 = new Stack(); + Stack stack2 = new Stack(); + + //当执行push操作时，将元素添加到stack1 + public void push(int node) { + stack1.push(node); + } + + public int pop() { + //如果两个队列都为空则抛出异常,说明用户没有push进任何元素 + if(stack1.empty()&&stack2.empty()){ + throw new RuntimeException("Queue is empty!"); + } + //如果stack2不为空直接对stack2执行pop操作， + if(stack2.empty()){ + while(!stack1.empty()){ + //将stack1的元素按后进先出push进stack2里面 + stack2.push(stack1.pop()); + } + } + return stack2.pop(); + } +} +``` + +## 栈的压入,弹出序列 + +**题目描述：** + +输入两个整数序列，第一个序列表示栈的压入顺序，请判断第二个序列是否为该栈的弹出顺序。假设压入栈的所有数字均不相等。例如序列1,2,3,4,5是某栈的压入顺序，序列4，5,3,2,1是该压栈序列对应的一个弹出序列，但4,3,5,1,2就不可能是该压栈序列的弹出序列。（注意：这两个序列的长度是相等的） + +**题目分析：** + +这道题想了半天没有思路，参考了Alias的答案，他的思路写的也很详细应该很容易看懂。 +作者：Alias +https://www.nowcoder.com/questionTerminal/d77d11405cc7470d82554cb392585106 +来源：牛客网 + +【思路】借用一个辅助的栈，遍历压栈顺序，先讲第一个放入栈中，这里是1，然后判断栈顶元素是不是出栈顺序的第一个元素，这里是4，很显然1≠4，所以我们继续压栈，直到相等以后开始出栈，出栈一个元素，则将出栈顺序向后移动一位，直到不相等，这样循环等压栈顺序遍历完成，如果辅助栈还不为空，说明弹出序列不是该栈的弹出顺序。 + +举例： + +入栈1,2,3,4,5 + +出栈4,5,3,2,1 + +首先1入辅助栈，此时栈顶1≠4，继续入栈2 + +此时栈顶2≠4，继续入栈3 + +此时栈顶3≠4，继续入栈4 + +此时栈顶4＝4，出栈4，弹出序列向后一位，此时为5，,辅助栈里面是1,2,3 + +此时栈顶3≠5，继续入栈5 + +此时栈顶5=5，出栈5,弹出序列向后一位，此时为3，,辅助栈里面是1,2,3 + +…. +依次执行，最后辅助栈为空。如果不为空说明弹出序列不是该栈的弹出顺序。 + +**考察内容：** + +栈 + +**示例代码：** + +```java +import java.util.ArrayList; +import java.util.Stack; +//这道题没想出来，参考了Alias同学的答案：https://www.nowcoder.com/questionTerminal/d77d11405cc7470d82554cb392585106 +public class Solution { + public boolean IsPopOrder(int [] pushA,int [] popA) { + if(pushA.length == 0 || popA.length == 0) + return false; + Stack s = new Stack(); + //用于标识弹出序列的位置 + int popIndex = 0; + for(int i = 0; i< pushA.length;i++){ + s.push(pushA[i]); + //如果栈不为空，且栈顶元素等于弹出序列 + while(!s.empty() &&s.peek() == popA[popIndex]){ + //出栈 + s.pop(); + //弹出序列向后一位 + popIndex++; + } + } + return s.empty(); + } +} +``` \ No newline at end of file diff --git a/docs/cs-basics/data-structure/bloom-filter.md b/docs/cs-basics/data-structure/bloom-filter.md new file mode 100644 index 0000000000000000000000000000000000000000..d013be7471f6f0549d6d288452fdb2d9a64bb7e4 --- /dev/null +++ b/docs/cs-basics/data-structure/bloom-filter.md @@ -0,0 +1,306 @@ +--- +category: 计算机基础 +tag: + - 数据结构 +--- + +# 布隆过滤器 + +海量数据处理以及缓存穿透这两个场景让我认识了 布隆过滤器 ，我查阅了一些资料来了解它，但是很多现成资料并不满足我的需求，所以就决定自己总结一篇关于布隆过滤器的文章。希望通过这篇文章让更多人了解布隆过滤器，并且会实际去使用它！ + +下面我们将分为几个方面来介绍布隆过滤器： + +1. 什么是布隆过滤器？ +2. 布隆过滤器的原理介绍。 +3. 布隆过滤器使用场景。 +4. 通过 Java 编程手动实现布隆过滤器。 +5. 利用 Google 开源的 Guava 中自带的布隆过滤器。 +6. Redis 中的布隆过滤器。 + +## 什么是布隆过滤器？ + +首先，我们需要了解布隆过滤器的概念。 + +布隆过滤器（Bloom Filter）是一个叫做 Bloom 的老哥于 1970 年提出的。我们可以把它看作由二进制向量（或者说位数组）和一系列随机映射函数（哈希函数）两部分组成的数据结构。相比于我们平时常用的的 List、Map 、Set 等数据结构，它占用空间更少并且效率更高，但是缺点是其返回的结果是概率性的，而不是非常准确的。理论情况下添加到集合中的元素越多，误报的可能性就越大。并且，存放在布隆过滤器的数据不容易删除。 + +![布隆过滤器示意图](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/2019-11/布隆过滤器-bit数组.png) + +位数组中的每个元素都只占用 1 bit ，并且每个元素只能是 0 或者 1。这样申请一个 100w 个元素的位数组只占用 1000000Bit / 8 = 125000 Byte = 125000/1024 kb ≈ 122kb 的空间。 + +总结：**一个名叫 Bloom 的人提出了一种来检索元素是否在给定大集合中的数据结构，这种数据结构是高效且性能很好的，但缺点是具有一定的错误识别率和删除难度。并且，理论情况下，添加到集合中的元素越多，误报的可能性就越大。** + +## 布隆过滤器的原理介绍 + +**当一个元素加入布隆过滤器中的时候，会进行如下操作：** + +1. 使用布隆过滤器中的哈希函数对元素值进行计算，得到哈希值（有几个哈希函数得到几个哈希值）。 +2. 根据得到的哈希值，在位数组中把对应下标的值置为 1。 + +**当我们需要判断一个元素是否存在于布隆过滤器的时候，会进行如下操作：** + +1. 对给定元素再次进行相同的哈希计算； +2. 得到值之后判断位数组中的每个元素是否都为 1，如果值都为 1，那么说明这个值在布隆过滤器中，如果存在一个值不为 1，说明该元素不在布隆过滤器中。 + +举个简单的例子： + +![布隆过滤器hash计算](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/2019-11/布隆过滤器-hash运算.png) + +如图所示，当字符串存储要加入到布隆过滤器中时，该字符串首先由多个哈希函数生成不同的哈希值，然后将对应的位数组的下标设置为 1（当位数组初始化时，所有位置均为 0）。当第二次存储相同字符串时，因为先前的对应位置已设置为 1，所以很容易知道此值已经存在（去重非常方便）。 + +如果我们需要判断某个字符串是否在布隆过滤器中时，只需要对给定字符串再次进行相同的哈希计算，得到值之后判断位数组中的每个元素是否都为 1，如果值都为 1，那么说明这个值在布隆过滤器中，如果存在一个值不为 1，说明该元素不在布隆过滤器中。 + +**不同的字符串可能哈希出来的位置相同，这种情况我们可以适当增加位数组大小或者调整我们的哈希函数。** + +综上，我们可以得出：**布隆过滤器说某个元素存在，小概率会误判。布隆过滤器说某个元素不在，那么这个元素一定不在。** + +## 布隆过滤器使用场景 + +1. 判断给定数据是否存在：比如判断一个数字是否存在于包含大量数字的数字集中（数字集很大，5 亿以上！）、 防止缓存穿透（判断请求的数据是否有效避免直接绕过缓存请求数据库）等等、邮箱的垃圾邮件过滤、黑名单功能等等。 +2. 去重：比如爬给定网址的时候对已经爬取过的 URL 去重。 + + +## 编码实战 + +### 通过 Java 编程手动实现布隆过滤器 + +我们上面已经说了布隆过滤器的原理，知道了布隆过滤器的原理之后就可以自己手动实现一个了。 + +如果你想要手动实现一个的话，你需要： + +1. 一个合适大小的位数组保存数据 +2. 几个不同的哈希函数 +3. 添加元素到位数组（布隆过滤器）的方法实现 +4. 判断给定元素是否存在于位数组（布隆过滤器）的方法实现。 + +下面给出一个我觉得写的还算不错的代码（参考网上已有代码改进得到，对于所有类型对象皆适用）： + +```java +import java.util.BitSet; + +public class MyBloomFilter { + + /** + * 位数组的大小 + */ + private static final int DEFAULT_SIZE = 2 << 24; + /** + * 通过这个数组可以创建 6 个不同的哈希函数 + */ + private static final int[] SEEDS = new int[]{3, 13, 46, 71, 91, 134}; + + /** + * 位数组。数组中的元素只能是 0 或者 1 + */ + private BitSet bits = new BitSet(DEFAULT_SIZE); + + /** + * 存放包含 hash 函数的类的数组 + */ + private SimpleHash[] func = new SimpleHash[SEEDS.length]; + + /** + * 初始化多个包含 hash 函数的类的数组，每个类中的 hash 函数都不一样 + */ + public MyBloomFilter() { + // 初始化多个不同的 Hash 函数 + for (int i = 0; i < SEEDS.length; i++) { + func[i] = new SimpleHash(DEFAULT_SIZE, SEEDS[i]); + } + } + + /** + * 添加元素到位数组 + */ + public void add(Object value) { + for (SimpleHash f : func) { + bits.set(f.hash(value), true); + } + } + + /** + * 判断指定元素是否存在于位数组 + */ + public boolean contains(Object value) { + boolean ret = true; + for (SimpleHash f : func) { + ret = ret && bits.get(f.hash(value)); + } + return ret; + } + + /** + * 静态内部类。用于 hash 操作！ + */ + public static class SimpleHash { + + private int cap; + private int seed; + + public SimpleHash(int cap, int seed) { + this.cap = cap; + this.seed = seed; + } + + /** + * 计算 hash 值 + */ + public int hash(Object value) { + int h; + return (value == null) ? 0 : Math.abs(seed * (cap - 1) & ((h = value.hashCode()) ^ (h >>> 16))); + } + + } +} +``` + +测试： + +```java +String value1 = "https://javaguide.cn/"; +String value2 = "https://github.com/Snailclimb"; +MyBloomFilter filter = new MyBloomFilter(); +System.out.println(filter.contains(value1)); +System.out.println(filter.contains(value2)); +filter.add(value1); +filter.add(value2); +System.out.println(filter.contains(value1)); +System.out.println(filter.contains(value2)); +``` + +Output: + +``` +false +false +true +true +``` + +测试： + +```java +Integer value1 = 13423; +Integer value2 = 22131; +MyBloomFilter filter = new MyBloomFilter(); +System.out.println(filter.contains(value1)); +System.out.println(filter.contains(value2)); +filter.add(value1); +filter.add(value2); +System.out.println(filter.contains(value1)); +System.out.println(filter.contains(value2)); +``` + +Output: + +```java +false +false +true +true +``` + +### 利用 Google 开源的 Guava 中自带的布隆过滤器 + +自己实现的目的主要是为了让自己搞懂布隆过滤器的原理，Guava 中布隆过滤器的实现算是比较权威的，所以实际项目中我们不需要手动实现一个布隆过滤器。 + +首先我们需要在项目中引入 Guava 的依赖： + +```java + + com.google.guava + guava + 28.0-jre + +``` + +实际使用如下： + +我们创建了一个最多存放 最多 1500 个整数的布隆过滤器，并且我们可以容忍误判的概率为百分之（0.01） + +```java +// 创建布隆过滤器对象 +BloomFilter filter = BloomFilter.create( + Funnels.integerFunnel(), + 1500, + 0.01); +// 判断指定元素是否存在 +System.out.println(filter.mightContain(1)); +System.out.println(filter.mightContain(2)); +// 将元素添加进布隆过滤器 +filter.put(1); +filter.put(2); +System.out.println(filter.mightContain(1)); +System.out.println(filter.mightContain(2)); +``` + +在我们的示例中，当 `mightContain()` 方法返回 _true_ 时，我们可以 99％确定该元素在过滤器中，当过滤器返回 _false_ 时，我们可以 100％确定该元素不存在于过滤器中。 + +**Guava 提供的布隆过滤器的实现还是很不错的（想要详细了解的可以看一下它的源码实现），但是它有一个重大的缺陷就是只能单机使用（另外，容量扩展也不容易），而现在互联网一般都是分布式的场景。为了解决这个问题，我们就需要用到 Redis 中的布隆过滤器了。** + +## Redis 中的布隆过滤器 + +### 介绍 + +Redis v4.0 之后有了 Module（模块/插件） 功能，Redis Modules 让 Redis 可以使用外部模块扩展其功能 。布隆过滤器就是其中的 Module。详情可以查看 Redis 官方对 Redis Modules 的介绍 ：https://redis.io/modules + +另外，官网推荐了一个 RedisBloom 作为 Redis 布隆过滤器的 Module，地址：https://github.com/RedisBloom/RedisBloom +其他还有： + +* redis-lua-scaling-bloom-filter（lua 脚本实现）：https://github.com/erikdubbelboer/redis-lua-scaling-bloom-filter +* pyreBloom（Python 中的快速 Redis 布隆过滤器） ：https://github.com/seomoz/pyreBloom +* ...... + +RedisBloom 提供了多种语言的客户端支持，包括：Python、Java、JavaScript 和 PHP。 + +### 使用 Docker 安装 + +如果我们需要体验 Redis 中的布隆过滤器非常简单，通过 Docker 就可以了！我们直接在 Google 搜索 **docker redis bloomfilter** 然后在排除广告的第一条搜素结果就找到了我们想要的答案（这是我平常解决问题的一种方式，分享一下），具体地址：https://hub.docker.com/r/redislabs/rebloom/ （介绍的很详细 ）。 + +**具体操作如下：** + +``` +➜ ~ docker run -p 6379:6379 --name redis-redisbloom redislabs/rebloom:latest +➜ ~ docker exec -it redis-redisbloom bash +root@21396d02c252:/data# redis-cli +127.0.0.1:6379> +``` + +### 常用命令一览 + +> 注意： key : 布隆过滤器的名称，item : 添加的元素。 + +1. **`BF.ADD`**：将元素添加到布隆过滤器中，如果该过滤器尚不存在，则创建该过滤器。格式：`BF.ADD {key} {item}`。 +2. **`BF.MADD`** : 将一个或多个元素添加到“布隆过滤器”中，并创建一个尚不存在的过滤器。该命令的操作方式`BF.ADD`与之相同，只不过它允许多个输入并返回多个值。格式：`BF.MADD {key} {item} [item ...]` 。 +3. **`BF.EXISTS`** : 确定元素是否在布隆过滤器中存在。格式：`BF.EXISTS {key} {item}`。 +4. **`BF.MEXISTS`** ： 确定一个或者多个元素是否在布隆过滤器中存在格式：`BF.MEXISTS {key} {item} [item ...]`。 + +另外， `BF. RESERVE` 命令需要单独介绍一下： + +这个命令的格式如下： + +`BF. RESERVE {key} {error_rate} {capacity} [EXPANSION expansion]` 。 + +下面简单介绍一下每个参数的具体含义： + +1. key：布隆过滤器的名称 +2. error_rate : 期望的误报率。该值必须介于 0 到 1 之间。例如，对于期望的误报率 0.1％（1000 中为 1），error_rate 应该设置为 0.001。该数字越接近零，则每个项目的内存消耗越大，并且每个操作的 CPU 使用率越高。 +3. capacity: 过滤器的容量。当实际存储的元素个数超过这个值之后，性能将开始下降。实际的降级将取决于超出限制的程度。随着过滤器元素数量呈指数增长，性能将线性下降。 + +可选参数： + +* expansion：如果创建了一个新的子过滤器，则其大小将是当前过滤器的大小乘以`expansion`。默认扩展值为 2。这意味着每个后续子过滤器将是前一个子过滤器的两倍。 + +### 实际使用 + +```shell +127.0.0.1:6379> BF.ADD myFilter java +(integer) 1 +127.0.0.1:6379> BF.ADD myFilter javaguide +(integer) 1 +127.0.0.1:6379> BF.EXISTS myFilter java +(integer) 1 +127.0.0.1:6379> BF.EXISTS myFilter javaguide +(integer) 1 +127.0.0.1:6379> BF.EXISTS myFilter github +(integer) 0 +``` diff --git a/docs/cs-basics/data-structure/graph.md b/docs/cs-basics/data-structure/graph.md new file mode 100644 index 0000000000000000000000000000000000000000..0e1b4381afb7876d0fa41811108a97ae2f90d0c4 --- /dev/null +++ b/docs/cs-basics/data-structure/graph.md @@ -0,0 +1,161 @@ +--- +category: 计算机基础 +tag: + - 数据结构 +--- + +# 图 + +> 开头还是求点赞，求转发！原创优质公众号，希望大家能让更多人看到我们的文章。 +> +> 图片都是我们手绘的，可以说非常用心了！ + +图是一种较为复杂的非线性结构。 **为啥说其较为复杂呢？** + +根据前面的内容，我们知道： + +- 线性数据结构的元素满足唯一的线性关系，每个元素(除第一个和最后一个外)只有一个直接前趋和一个直接后继。 +- 树形数据结构的元素之间有着明显的层次关系。 + +但是，图形结构的元素之间的关系是任意的。 + +**何为图呢？** 简单来说，图就是由顶点的有穷非空集合和顶点之间的边组成的集合。通常表示为：**G(V,E)**，其中，G表示一个图，V表示顶点的集合，E表示边的集合。 + +下图所展示的就是图这种数据结构，并且还是一张有向图。 + +![](https://img-blog.csdnimg.cn/7f232c9660c54ee1ac182b7c0bf267a3.png) + +图在我们日常生活中的例子很多！比如我们在社交软件上好友关系就可以用图来表示。 + +## 图的基本概念 + +### 顶点 +图中的数据元素，我们称之为顶点，图至少有一个顶点（非空有穷集合） + +对应到好友关系图，每一个用户就代表一个顶点。 + +### 边 +顶点之间的关系用边表示。 + +对应到好友关系图，两个用户是好友的话，那两者之间就存在一条边。 + +### 度 +度表示一个顶点包含多少条边，在有向图中，还分为出度和入度，出度表示从该顶点出去的边的条数，入度表示进入该顶点的边的条数。 + +对应到好友关系图，度就代表了某个人的好友数量。 + +### 无向图和有向图 +边表示的是顶点之间的关系，有的关系是双向的，比如同学关系，A是B的同学，那么B也肯定是A的同学，那么在表示A和B的关系时，就不用关注方向，用不带箭头的边表示，这样的图就是无向图。 + +有的关系是有方向的，比如父子关系，师生关系，微博的关注关系，A是B的爸爸，但B肯定不是A的爸爸，A关注B，B不一定关注A。在这种情况下，我们就用带箭头的边表示二者的关系，这样的图就是有向图。 + +### 无权图和带权图 + +对于一个关系，如果我们只关心关系的有无，而不关心关系有多强，那么就可以用无权图表示二者的关系。 + +对于一个关系，如果我们既关心关系的有无，也关心关系的强度，比如描述地图上两个城市的关系，需要用到距离，那么就用带权图来表示，带权图中的每一条边一个数值表示权值，代表关系的强度。 + +下图就是一个带权有向图。 + +![带权有向图](./pictures/图/带权有向图.png) + +## 图的存储 +### 邻接矩阵存储 +邻接矩阵将图用二维矩阵存储，是一种较为直观的表示方式。 + +如果第i个顶点和第j个顶点之间有关系，且关系权值为n，则 `A[i][j]=n` 。 + +在无向图中，我们只关心关系的有无，所以当顶点i和顶点j有关系时，`A[i][j]`=1，当顶点i和顶点j没有关系时，`A[i][j]`=0。如下图所示： + +![无向图的邻接矩阵存储](./pictures/图/无向图的邻接矩阵存储.png) + +值得注意的是：**无向图的邻接矩阵是一个对称矩阵，因为在无向图中，顶点i和顶点j有关系，则顶点j和顶点i必有关系。** + +![有向图的邻接矩阵存储](./pictures/图/有向图的邻接矩阵存储.png) + +邻接矩阵存储的方式优点是简单直接（直接使用一个二维数组即可），并且，在获取两个定点之间的关系的时候也非常高效（直接获取指定位置的数组元素的值即可）。但是，这种存储方式的缺点也比较明显，那就是比较浪费空间， + +### 邻接表存储 + +针对上面邻接矩阵比较浪费内存空间的问题，诞生了图的另外一种存储方法—**邻接表** 。 + +邻接链表使用一个链表来存储某个顶点的所有后继相邻顶点。对于图中每个顶点Vi，把所有邻接于Vi的顶点Vj链成一个单链表，这个单链表称为顶点Vi的 **邻接表**。如下图所示： + + + +![无向图的邻接表存储](./pictures/图/无向图的邻接表存储.png) + + + +![有向图的邻接表存储](./pictures/图/有向图的邻接表存储.png) + +大家可以数一数邻接表中所存储的元素的个数以及图中边的条数，你会发现： + +- 在无向图中，邻接表元素个数等于边的条数的两倍，如左图所示的无向图中，边的条数为7，邻接表存储的元素个数为14。 +- 在有向图中，邻接表元素个数等于边的条数，如右图所示的有向图中，边的条数为8，邻接表存储的元素个数为8。 + +## 图的搜索 +### 广度优先搜索 +广度优先搜索就像水面上的波纹一样一层一层向外扩展，如下图所示： + +![广度优先搜索图示](./pictures/图/广度优先搜索图示.png) + +**广度优先搜索的具体实现方式用到了之前所学过的线性数据结构——队列** 。具体过程如下图所示： + +**第1步：** + +![广度优先搜索1](./pictures/图/广度优先搜索1.png) + +**第2步：** + +![广度优先搜索2](./pictures/图/广度优先搜索2.png) + +**第3步：** + +![广度优先搜索3](./pictures/图/广度优先搜索3.png) + +**第4步：** + +![广度优先搜索4](./pictures/图/广度优先搜索4.png) + +**第5步：** + +![广度优先搜索5](./pictures/图/广度优先搜索5.png) + +**第6步：** + +![广度优先搜索6](./pictures/图/广度优先搜索6.png) + +### 深度优先搜索 + +深度优先搜索就是“一条路走到黑”，从源顶点开始，一直走到没有后继节点，才回溯到上一顶点，然后继续“一条路走到黑”，如下图所示： + +![深度优先搜索图示](./pictures/图/深度优先搜索图示.png) + + +**和广度优先搜索类似，深度优先搜索的具体实现用到了另一种线性数据结构——栈** 。具体过程如下图所示： + +**第1步：** + +![深度优先搜索1](./pictures/图/深度优先搜索1.png) + +**第2步：** + +![深度优先搜索1](./pictures/图/深度优先搜索2.png) + +**第3步：** + +![深度优先搜索1](./pictures/图/深度优先搜索3.png) + +**第4步：** + +![深度优先搜索1](./pictures/图/深度优先搜索4.png) + +**第5步：** + +![深度优先搜索1](./pictures/图/深度优先搜索5.png) + +**第6步：** + +![深度优先搜索1](./pictures/图/深度优先搜索6.png) + diff --git a/docs/cs-basics/data-structure/heap.md b/docs/cs-basics/data-structure/heap.md new file mode 100644 index 0000000000000000000000000000000000000000..cd615deecdaa96f01e22ab5c4f50d55314bc4073 --- /dev/null +++ b/docs/cs-basics/data-structure/heap.md @@ -0,0 +1,198 @@ +--- +category: 计算机基础 +tag: + - 数据结构 +--- + +# 堆 + +## 什么是堆 + +堆是一种满足以下条件的树： + +堆中的每一个节点值都大于等于（或小于等于）子树中所有节点的值。或者说，任意一个节点的值都大于等于（或小于等于）所有子节点的值。 + +> 大家可以把堆(最大堆)理解为一个公司,这个公司很公平,谁能力强谁就当老大,不存在弱的人当老大,老大手底下的人一定不会比他强。这样有助于理解后续堆的操作。 + +**!!!特别提示：** + +- 很多博客说堆是完全二叉树，其实并非如此，**堆不一定是完全二叉树**，只是为了方便存储和索引，我们通常用完全二叉树的形式来表示堆，事实上，广为人知的斐波那契堆和二项堆就不是完全二叉树,它们甚至都不是二叉树。 +- （**二叉**）堆是一个数组，它可以被看成是一个 **近似的完全二叉树**。——《算法导论》第三版 + +大家可以尝试判断下面给出的图是否是堆？ + +![](./pictures/堆/堆1.png) + +第1个和第2个是堆。第1个是最大堆，每个节点都比子树中所有节点大。第2个是最小堆，每个节点都比子树中所有节点小。 + +第3个不是，第三个中，根结点1比2和15小，而15却比3大，19比5大，不满足堆的性质。 + +## 堆的用途 +当我们只关心所有数据中的最大值或者最小值，存在多次获取最大值或者最小值，多次插入或删除数据时，就可以使用堆。 + +有小伙伴可能会想到用有序数组，初始化一个有序数组时间复杂度是 `O(nlog(n))`，查找最大值或者最小值时间复杂度都是 `O(1)`，但是，涉及到更新（插入或删除）数据时，时间复杂度为 `O(n)`，即使是使用复杂度为 `O(log(n))` 的二分法找到要插入或者删除的数据，在移动数据时也需要 `O(n)` 的时间复杂度。 + +**相对于有序数组而言，堆的主要优势在于更新数据效率较高。** 堆的初始化时间复杂度为 `O(nlog(n))`，堆可以做到`O(1)`时间复杂度取出最大值或者最小值，`O(log(n))`时间复杂度插入或者删除数据，具体操作在后续章节详细介绍。 + +## 堆的分类 + +堆分为 **最大堆** 和 **最小堆**。二者的区别在于节点的排序方式。 +- **最大堆** ：堆中的每一个节点的值都大于等于子树中所有节点的值 +- **最小堆** ：堆中的每一个节点的值都小于等于子树中所有节点的值 + +如下图所示，图1是最大堆，图2是最小堆 + +![](./pictures/堆/堆2.png) + + +## 堆的存储 +之前介绍树的时候说过，由于完全二叉树的优秀性质，利用数组存储二叉树即节省空间，又方便索引（若根结点的序号为1，那么对于树中任意节点i，其左子节点序号为 `2*i`，右子节点序号为 `2*i+1`）。 + +为了方便存储和索引，（二叉）堆可以用完全二叉树的形式进行存储。存储的方式如下图所示： + +![堆的存储](./pictures/堆/堆的存储.png) + +## 堆的操作 +堆的更新操作主要包括两种 : **插入元素** 和 **删除堆顶元素**。操作过程需要着重掌握和理解。 +> 在进入正题之前，再重申一遍，堆是一个公平的公司，有能力的人自然会走到与他能力所匹配的位置 +### 插入元素 +> 插入元素，作为一个新入职的员工，初来乍到，这个员工需要从基层做起 + +**1.将要插入的元素放到最后** + +![堆-插入元素-1](./pictures/堆/堆-插入元素1.png) + +> 有能力的人会逐渐升职加薪，是金子总会发光的！！！ + +**2.从底向上，如果父结点比该元素大，则该节点和父结点交换，直到无法交换** + +![堆-插入元素2](./pictures/堆/堆-插入元素2.png) + +![堆-插入元素3](./pictures/堆/堆-插入元素3.png) + +### 删除堆顶元素 + +根据堆的性质可知，最大堆的堆顶元素为所有元素中最大的，最小堆的堆顶元素是所有元素中最小的。当我们需要多次查找最大元素或者最小元素的时候，可以利用堆来实现。 + +删除堆顶元素后，为了保持堆的性质，需要对堆的结构进行调整，我们将这个过程称之为"**堆化**"，堆化的方法分为两种： + +- 一种是自底向上的堆化，上述的插入元素所使用的就是自底向上的堆化，元素从最底部向上移动。 +- 另一种是自顶向下堆化，元素由最顶部向下移动。在讲解删除堆顶元素的方法时，我将阐述这两种操作的过程，大家可以体会一下二者的不同。 + +#### 自底向上堆化 + +> 在堆这个公司中，会出现老大离职的现象，老大离职之后，他的位置就空出来了 + +首先删除堆顶元素，使得数组中下标为1的位置空出。 + + + +![删除堆顶元素1](./pictures/堆/删除堆顶元素1.png) + + +> 那么他的位置由谁来接替呢，当然是他的直接下属了，谁能力强就让谁上呗 + +比较根结点的左子节点和右子节点，也就是下标为2,3的数组元素，将较大的元素填充到根结点(下标为1)的位置。 + +![删除堆顶元素2](./pictures/堆/删除堆顶元素2.png) + + +> 这个时候又空出一个位置了，老规矩，谁有能力谁上 + +一直循环比较空出位置的左右子节点，并将较大者移至空位，直到堆的最底部 + +![删除堆顶元素3](./pictures/堆/删除堆顶元素3.png) + +这个时候已经完成了自底向上的堆化，没有元素可以填补空缺了，但是，我们可以看到数组中出现了“气泡”，这会导致存储空间的浪费。接下来我们试试自顶向下堆化。 + +#### 自顶向下堆化 +自顶向下的堆化用一个词形容就是“石沉大海”，那么第一件事情，就是把石头抬起来，从海面扔下去。这个石头就是堆的最后一个元素，我们将最后一个元素移动到堆顶。 + +![删除堆顶元素4](./pictures/堆/删除堆顶元素4.png) + +然后开始将这个石头沉入海底，不停与左右子节点的值进行比较，和较大的子节点交换位置，直到无法交换位置。 + +![删除堆顶元素5](./pictures/堆/删除堆顶元素5.png) + +![删除堆顶元素6](./pictures/堆/删除堆顶元素6.png) + + + +### 堆的操作总结 + +- **插入元素** ：先将元素放至数组末尾，再自底向上堆化，将末尾元素上浮 +- **删除堆顶元素** ：删除堆顶元素，将末尾元素放至堆顶，再自顶向下堆化，将堆顶元素下沉。也可以自底向上堆化，只是会产生“气泡”，浪费存储空间。最好采用自顶向下堆化的方式。 + + +## 堆排序 + +堆排序的过程分为两步： + +- 第一步是建堆，将一个无序的数组建立为一个堆 +- 第二步是排序，将堆顶元素取出，然后对剩下的元素进行堆化，反复迭代，直到所有元素被取出为止。 + +### 建堆 + +如果你已经足够了解堆化的过程，那么建堆的过程掌握起来就比较容易了。建堆的过程就是一个对所有非叶节点的自顶向下堆化过程。 + +首先要了解哪些是非叶节点，最后一个节点的父结点及它之前的元素，都是非叶节点。也就是说，如果节点个数为n，那么我们需要对n/2到1的节点进行自顶向下（沉底）堆化。 + +具体过程如下图： + +![建堆1](./pictures/堆/建堆1.png) + +将初始的无序数组抽象为一棵树，图中的节点个数为6，所以4,5,6节点为叶节点，1,2,3节点为非叶节点，所以要对1-3号节点进行自顶向下（沉底）堆化，注意，顺序是从后往前堆化，从3号节点开始，一直到1号节点。 +3号节点堆化结果： + +![建堆1](./pictures/堆/建堆2.png) + +2号节点堆化结果： + +![建堆1](./pictures/堆/建堆3.png) + +1号节点堆化结果： + +![建堆1](./pictures/堆/建堆4.png) + +至此，数组所对应的树已经成为了一个最大堆，建堆完成！ + +### 排序 + +由于堆顶元素是所有元素中最大的，所以我们重复取出堆顶元素，将这个最大的堆顶元素放至数组末尾，并对剩下的元素进行堆化即可。 + +现在思考两个问题： + +- 删除堆顶元素后需要执行自顶向下（沉底）堆化还是自底向上（上浮）堆化？ +- 取出的堆顶元素存在哪，新建一个数组存？ + +先回答第一个问题，我们需要执行自顶向下（沉底）堆化，这个堆化一开始要将末尾元素移动至堆顶，这个时候末尾的位置就空出来了，由于堆中元素已经减小，这个位置不会再被使用，所以我们可以将取出的元素放在末尾。 + +机智的小伙伴已经发现了，这其实是做了一次交换操作，将堆顶和末尾元素调换位置，从而将取出堆顶元素和堆化的第一步(将末尾元素放至根结点位置)进行合并。 + +详细过程如下图所示： + +取出第一个元素并堆化： + +![堆排序1](./pictures/堆/堆排序1.png) + +取出第二个元素并堆化： + +![堆排序2](./pictures/堆/堆排序2.png) + +取出第三个元素并堆化： + +![堆排序3](./pictures/堆/堆排序3.png) + +取出第四个元素并堆化： + +![堆排序4](./pictures/堆/堆排序4.png) + +取出第五个元素并堆化： + +![堆排序5](./pictures/堆/堆排序5.png) + +取出第六个元素并堆化： + +![堆排序6](./pictures/堆/堆排序6.png) + +堆排序完成！ diff --git a/docs/cs-basics/data-structure/linear-data-structure.md b/docs/cs-basics/data-structure/linear-data-structure.md new file mode 100644 index 0000000000000000000000000000000000000000..17a61ddc386b48e614fa1aa92d1b276aa177d37c --- /dev/null +++ b/docs/cs-basics/data-structure/linear-data-structure.md @@ -0,0 +1,316 @@ +--- +category: 计算机基础 +tag: + - 数据结构 +--- + +# 线性数据结构 :数组、链表、栈、队列 + +> 开头还是求点赞，求转发！原创优质公众号，希望大家能让更多人看到我们的文章。 +> +> 图片都是我们手绘的，可以说非常用心了！ + +## 1. 数组 + +**数组（Array）** 是一种很常见的数据结构。它由相同类型的元素（element）组成，并且是使用一块连续的内存来存储。 + +我们直接可以利用元素的索引（index）可以计算出该元素对应的存储地址。 + +数组的特点是：**提供随机访问** 并且容量有限。 + +```java +假如数组的长度为 n。 +访问：O（1）//访问特定位置的元素 +插入：O（n ）//最坏的情况发生在插入发生在数组的首部并需要移动所有元素时 +删除：O（n）//最坏的情况发生在删除数组的开头发生并需要移动第一元素后面所有的元素时 +``` + +![数组](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/2019-6/数组.png) + +## 2. 链表 + +### 2.1. 链表简介 + +**链表（LinkedList）** 虽然是一种线性表，但是并不会按线性的顺序存储数据，使用的不是连续的内存空间来存储数据。 + +链表的插入和删除操作的复杂度为 O(1) ，只需要知道目标位置元素的上一个元素即可。但是，在查找一个节点或者访问特定位置的节点的时候复杂度为 O(n) 。 + +使用链表结构可以克服数组需要预先知道数据大小的缺点，链表结构可以充分利用计算机内存空间,实现灵活的内存动态管理。但链表不会节省空间，相比于数组会占用更多的空间，因为链表中每个节点存放的还有指向其他节点的指针。除此之外，链表不具有数组随机读取的优点。 + +### 2.2. 链表分类 + +**常见链表分类：** + +1. 单链表 +2. 双向链表 +3. 循环链表 +4. 双向循环链表 + +```java +假如链表中有n个元素。 +访问：O（n）//访问特定位置的元素 +插入删除：O（1）//必须要要知道插入元素的位置 +``` + +#### 2.2.1. 单链表 + +**单链表** 单向链表只有一个方向，结点只有一个后继指针 next 指向后面的节点。因此，链表这种数据结构通常在物理内存上是不连续的。我们习惯性地把第一个结点叫作头结点，链表通常有一个不保存任何值的 head 节点(头结点)，通过头结点我们可以遍历整个链表。尾结点通常指向 null。 + +![单链表](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/2019-6/单链表2.png) + +#### 2.2.2. 循环链表 + +**循环链表** 其实是一种特殊的单链表，和单链表不同的是循环链表的尾结点不是指向 null，而是指向链表的头结点。 + +![循环链表](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/2019-6/循环链表2.png) + +#### 2.2.3. 双向链表 + +**双向链表** 包含两个指针，一个 prev 指向前一个节点，一个 next 指向后一个节点。 + +![双向链表](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/2019-6/双向链表.png) + +#### 2.2.4. 双向循环链表 + +**双向循环链表** 最后一个节点的 next 指向 head，而 head 的 prev 指向最后一个节点，构成一个环。 + +![双向循环链表](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/2019-6/双向循环链表.png) + +### 2.3. 应用场景 + +- 如果需要支持随机访问的话，链表没办法做到。 +- 如果需要存储的数据元素的个数不确定，并且需要经常添加和删除数据的话，使用链表比较合适。 +- 如果需要存储的数据元素的个数确定，并且不需要经常添加和删除数据的话，使用数组比较合适。 + +### 2.4. 数组 vs 链表 + +- 数组支持随机访问，而链表不支持。 +- 数组使用的是连续内存空间对 CPU 的缓存机制友好，链表则相反。 +- 数组的大小固定，而链表则天然支持动态扩容。如果声明的数组过小，需要另外申请一个更大的内存空间存放数组元素，然后将原数组拷贝进去，这个操作是比较耗时的！ + +## 3. 栈 + +### 3.1. 栈简介 + +**栈** (stack)只允许在有序的线性数据集合的一端（称为栈顶 top）进行加入数据（push）和移除数据（pop）。因而按照 **后进先出（LIFO, Last In First Out）** 的原理运作。**在栈中，push 和 pop 的操作都发生在栈顶。** + +栈常用一维数组或链表来实现，用数组实现的栈叫作 **顺序栈** ，用链表实现的栈叫作 **链式栈** 。 + +```java +假设堆栈中有n个元素。 +访问：O（n）//最坏情况 +插入删除：O（1）//顶端插入和删除元素 +``` + +![栈](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/2019-6/栈.png) + +### 3.2. 栈的常见应用常见应用场景 + +当我们我们要处理的数据只涉及在一端插入和删除数据，并且满足 **后进先出（LIFO, Last In First Out）** 的特性时，我们就可以使用栈这个数据结构。 + +#### 3.2.1. 实现浏览器的回退和前进功能 + +我们只需要使用两个栈(Stack1 和 Stack2)和就能实现这个功能。比如你按顺序查看了 1,2,3,4 这四个页面，我们依次把 1,2,3,4 这四个页面压入 Stack1 中。当你想回头看 2 这个页面的时候，你点击回退按钮，我们依次把 4,3 这两个页面从 Stack1 弹出，然后压入 Stack2 中。假如你又想回到页面 3，你点击前进按钮，我们将 3 页面从 Stack2 弹出，然后压入到 Stack1 中。示例图如下: + +![栈实现浏览器倒退和前进](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/2019-6/栈实现浏览器倒退和前进.png) + +#### 3.2.2. 检查符号是否成对出现 + +> 给定一个只包括 `'('`，`')'`，`'{'`，`'}'`，`'['`，`']'` 的字符串，判断该字符串是否有效。 +> +> 有效字符串需满足： +> +> 1. 左括号必须用相同类型的右括号闭合。 +> 2. 左括号必须以正确的顺序闭合。 +> +> 比如 "()"、"()[]{}"、"{[]}" 都是有效字符串，而 "(]" 、"([)]" 则不是。 + +这个问题实际是 Leetcode 的一道题目，我们可以利用栈 `Stack` 来解决这个问题。 + +1. 首先我们将括号间的对应规则存放在 `Map` 中，这一点应该毋容置疑； +2. 创建一个栈。遍历字符串，如果字符是左括号就直接加入`stack`中，否则将`stack` 的栈顶元素与这个括号做比较，如果不相等就直接返回 false。遍历结束，如果`stack`为空，返回 `true`。 + +```java +public boolean isValid(String s){ + // 括号之间的对应规则 + HashMap mappings = new HashMap(); + mappings.put(')', '('); + mappings.put('}', '{'); + mappings.put(']', '['); + Stack stack = new Stack(); + char[] chars = s.toCharArray(); + for (int i = 0; i < chars.length; i++) { + if (mappings.containsKey(chars[i])) { + char topElement = stack.empty() ? '#' : stack.pop(); + if (topElement != mappings.get(chars[i])) { + return false; + } + } else { + stack.push(chars[i]); + } + } + return stack.isEmpty(); +} +``` + +#### 3.2.3. 反转字符串 + +将字符串中的每个字符先入栈再出栈就可以了。 + +#### 3.2.4. 维护函数调用 + +最后一个被调用的函数必须先完成执行，符合栈的 **后进先出（LIFO, Last In First Out）** 特性。 + +### 3.3. 栈的实现 + +栈既可以通过数组实现，也可以通过链表来实现。不管基于数组还是链表，入栈、出栈的时间复杂度都为 O(1)。 + +下面我们使用数组来实现一个栈，并且这个栈具有`push()`、`pop()`（返回栈顶元素并出栈）、`peek()` （返回栈顶元素不出栈）、`isEmpty()`、`size()`这些基本的方法。 + +> 提示：每次入栈之前先判断栈的容量是否够用，如果不够用就用`Arrays.copyOf()`进行扩容； + +```java +public class MyStack { + private int[] storage;//存放栈中元素的数组 + private int capacity;//栈的容量 + private int count;//栈中元素数量 + private static final int GROW_FACTOR = 2; + + //不带初始容量的构造方法。默认容量为8 + public MyStack() { + this.capacity = 8; + this.storage=new int[8]; + this.count = 0; + } + + //带初始容量的构造方法 + public MyStack(int initialCapacity) { + if (initialCapacity < 1) + throw new IllegalArgumentException("Capacity too small."); + + this.capacity = initialCapacity; + this.storage = new int[initialCapacity]; + this.count = 0; + } + + //入栈 + public void push(int value) { + if (count == capacity) { + ensureCapacity(); + } + storage[count++] = value; + } + + //确保容量大小 + private void ensureCapacity() { + int newCapacity = capacity * GROW_FACTOR; + storage = Arrays.copyOf(storage, newCapacity); + capacity = newCapacity; + } + + //返回栈顶元素并出栈 + private int pop() { + if (count == 0) + throw new IllegalArgumentException("Stack is empty."); + count--; + return storage[count]; + } + + //返回栈顶元素不出栈 + private int peek() { + if (count == 0){ + throw new IllegalArgumentException("Stack is empty."); + }else { + return storage[count-1]; + } + } + + //判断栈是否为空 + private boolean isEmpty() { + return count == 0; + } + + //返回栈中元素的个数 + private int size() { + return count; + } + +} +``` + +验证 + +```java +MyStack myStack = new MyStack(3); +myStack.push(1); +myStack.push(2); +myStack.push(3); +myStack.push(4); +myStack.push(5); +myStack.push(6); +myStack.push(7); +myStack.push(8); +System.out.println(myStack.peek());//8 +System.out.println(myStack.size());//8 +for (int i = 0; i < 8; i++) { + System.out.println(myStack.pop()); +} +System.out.println(myStack.isEmpty());//true +myStack.pop();//报错：java.lang.IllegalArgumentException: Stack is empty. +``` + +## 4. 队列 + +### 4.1. 队列简介 + +**队列** 是 **先进先出( FIFO，First In, First Out)** 的线性表。在具体应用中通常用链表或者数组来实现，用数组实现的队列叫作 **顺序队列** ，用链表实现的队列叫作 **链式队列** 。**队列只允许在后端（rear）进行插入操作也就是 入队 enqueue，在前端（front）进行删除操作也就是出队 dequeue** + +队列的操作方式和堆栈类似，唯一的区别在于队列只允许新数据在后端进行添加。 + +```java +假设队列中有n个元素。 +访问：O（n）//最坏情况 +插入删除：O（1）//后端插入前端删除元素 +``` + +![队列](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/2019-6/队列.png) + +### 4.2. 队列分类 + +#### 4.2.1. 单队列 + +单队列就是常见的队列, 每次添加元素时，都是添加到队尾。单队列又分为 **顺序队列（数组实现）** 和 **链式队列（链表实现）**。 + +**顺序队列存在“假溢出”的问题也就是明明有位置却不能添加的情况。** + +假设下图是一个顺序队列，我们将前两个元素 1,2 出队，并入队两个元素 7,8。当进行入队、出队操作的时候，front 和 rear 都会持续往后移动，当 rear 移动到最后的时候,我们无法再往队列中添加数据，即使数组中还有空余空间，这种现象就是 **”假溢出“** 。除了假溢出问题之外，如下图所示，当添加元素 8 的时候，rear 指针移动到数组之外（越界）。 + +> 为了避免当只有一个元素的时候，队头和队尾重合使处理变得麻烦，所以引入两个指针，front 指针指向对头元素，rear 指针指向队列最后一个元素的下一个位置，这样当 front 等于 rear 时，此队列不是还剩一个元素，而是空队列。——From 《大话数据结构》 + +![顺序队列假溢出](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/2019-6/顺序队列假溢出1.png) + +#### 4.2.2. 循环队列 + +循环队列可以解决顺序队列的假溢出和越界问题。解决办法就是：从头开始，这样也就会形成头尾相接的循环，这也就是循环队列名字的由来。 + +还是用上面的图，我们将 rear 指针指向数组下标为 0 的位置就不会有越界问题了。当我们再向队列中添加元素的时候， rear 向后移动。 + +![循环队列](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/2019-6/循环队列.png) + +顺序队列中，我们说 `front==rear` 的时候队列为空，循环队列中则不一样，也可能为满，如上图所示。解决办法有两种： + +1. 可以设置一个标志变量 `flag`,当 `front==rear` 并且 `flag=0` 的时候队列为空，当`front==rear` 并且 `flag=1` 的时候队列为满。 +2. 队列为空的时候就是 `front==rear` ，队列满的时候，我们保证数组还有一个空闲的位置，rear 就指向这个空闲位置，如下图所示，那么现在判断队列是否为满的条件就是： `(rear+1) % QueueSize= front` 。 + +![循环队列-队满](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/2019-6/循环队列-堆满.png) + +### 4.3. 常见应用场景 + +当我们需要按照一定顺序来处理数据的时候可以考虑使用队列这个数据结构。 + +- **阻塞队列：** 阻塞队列可以看成在队列基础上加了阻塞操作的队列。当队列为空的时候，出队操作阻塞，当队列满的时候，入队操作阻塞。使用阻塞队列我们可以很容易实现“生产者 - 消费者“模型。 +- **线程池中的请求/任务队列：** 线程池中没有空闲线程时，新的任务请求线程资源时，线程池该如何处理呢？答案是将这些请求放在队列中，当有空闲线程的时候，会循环中反复从队列中获取任务来执行。队列分为无界队列(基于链表)和有界队列(基于数组)。无界队列的特点就是可以一直入列，除非系统资源耗尽，比如 ：`FixedThreadPool` 使用无界队列 `LinkedBlockingQueue`。但是有界队列就不一样了，当队列满的话后面再有任务/请求就会拒绝，在 Java 中的体现就是会抛出`java.util.concurrent.RejectedExecutionException` 异常。 +- Linux 内核进程队列（按优先级排队） +- 现实生活中的派对，播放器上的播放列表; +- 消息队列 +- 等等...... diff --git "a/docs/cs-basics/data-structure/pictures/\345\233\276/\345\270\246\346\235\203\346\234\211\345\220\221\345\233\276.drawio" "b/docs/cs-basics/data-structure/pictures/\345\233\276/\345\270\246\346\235\203\346\234\211\345\220\221\345\233\276.drawio" new file mode 100644 index 0000000000000000000000000000000000000000..1a980955eb4b94897d763709aa8bf32d6fef1bcf --- /dev/null +++ "b/docs/cs-basics/data-structure/pictures/\345\233\276/\345\270\246\346\235\203\346\234\211\345\220\221\345\233\276.drawio" @@ -0,0 +1 @@ +5Zrfd5sgFMf/mjx2R0BNfGzSbHvodnpOH9bujShRNiKOkMbsrx9GjD9I0q6tpU2e4v0CCvfDvYBxgCaL/IvAWfKNR4QNoBPlA3Q1gBAAx1c/hbIplSAYlkIsaKQr1cIt/Uu06Gh1RSOybFWUnDNJs7YY8jQloWxpWAi+blebc9Z+aoZjYgi3IWam+oNGMinVERzW+ldC46R6MvCDsmSBq8p6JMsER3zdkNB0gCaCc1leLfIJYYXzKr+U7T4fKN11TJBUPqXBDV9cO9coQ8nPKcb4uyvd2QXUfZObasAkUuPXJhcy4TFPMZvW6ljwVRqR4q6Osuo615xnSgRK/EWk3GiYeCW5khK5YLqU5FTeNa7vi1t98rR1les7b41NZaRSbO6aRqNVYdbNtlbVbs5TqTsCC7scbzHIg27U0pKvREiO+M7V0xGLmMgj9QDa0VZhQviCqA6qhoIwLOlDuyNYz9d4V69Gqi401f8gjGwSrqneN0r2E34HpAKboHQnHzBb6ScNoM9Ud8ezFj//z6pIGVt/XSy3DrtUFaCX5XWhuoqLX6e6h+rSrBLNGcGYyqcF+XVCJbnN8Nada5XS21zxMiuT7JzmxfwYzyljE8642N4IzefED0OlL6Xgv0mjJBoGM6fG+kCEJPlxsCYI3QC6OqXqNcUdanvdyNBaShrJudJeHZ13NMZSnr5uUD0nbYJ3kzb9Jwbj0GYw+n0EIzzFYPRQOxg913IwDvtAh04RHQra6HxoGd3oTfPoB99+Bh8hjwZ9BKN7isHY3dRYD8bqBN5waS9bmOOnggMbGHthB9BHOEwAYMDrdUv6Ps55T2ZjNSeC4y9dbC5zXTbPXfZsMPVfyFQ3veFUdXGXlt2R307LoJNvy37pVp2ZsevGCyYL6mMFBae4gna3s9ZfCwDPYGe+jVPjlW1vtp2k00HTo1rCjMapMkPlH6L0ceE9GmJ2qQsWNIrYIXzt/LI/Kb8MR+dg6I5MHO4eHLAvHNDcjJovbk4WR3d/6e2JjjfFUU2PBo7gfHB0o8PzbeMABg73fHC4XRzWowOe9drRPQxbx2Fuw8wT1snicDs7Kw/YxmH+WXZG0eE5j78qeiUcyqy/UCjPNPV3Hmj6Dw== \ No newline at end of file diff --git "a/docs/cs-basics/data-structure/pictures/\345\233\276/\345\270\246\346\235\203\346\234\211\345\220\221\345\233\276.png" "b/docs/cs-basics/data-structure/pictures/\345\233\276/\345\270\246\346\235\203\346\234\211\345\220\221\345\233\276.png" new file mode 100644 index 0000000000000000000000000000000000000000..bf9465f92c8ebd103dbdbafece3e1b81d56a37cd Binary files /dev/null and "b/docs/cs-basics/data-structure/pictures/\345\233\276/\345\270\246\346\235\203\346\234\211\345\220\221\345\233\276.png" differ diff --git "a/docs/cs-basics/data-structure/pictures/\345\233\276/\345\271\277\345\272\246\344\274\230\345\205\210\346\220\234\347\264\2421.drawio" "b/docs/cs-basics/data-structure/pictures/\345\233\276/\345\271\277\345\272\246\344\274\230\345\205\210\346\220\234\347\264\2421.drawio" new file mode 100644 index 0000000000000000000000000000000000000000..72381b7ae284083c0df4e776769c7d51da8a6bad --- /dev/null +++ "b/docs/cs-basics/data-structure/pictures/\345\233\276/\345\271\277\345\272\246\344\274\230\345\205\210\346\220\234\347\264\2421.drawio" @@ -0,0 +1 @@ +7V1dj6M2G/01XHbE98dlksm0qtqqerdqdy+Z4CS0TEgJmUn661+bmCTGJpCJjb3I0mgXGzDgcx4ffHgghjN7O/xYxNv1r3kCMsM2k4PhPBu2bVmmD/9DNcdTTWSap4pVkSZ4o0vFl/Q/gCvrzfZpAnbEhmWeZ2W6JSsX+WYDFiVRFxdF/kFutswz8qjbeAWoii+LOKNr/0qTcn2qDe3gUv8TSFfr+siWH53WvMX1xvhKdus4yT+uqpy54cyKPC9PS2+HGchQ59X9ctrvpWXt+cQKsCn77LD/cvC9dPaz98+f//322x/r2fTr7gfcynuc7fEFG7afwfamr+iUyyPuB//fPTrP6TLflD/sKpQmcAPb2x4uK+HSCv1v1m3Ak3mtK3EnnFu04dlBEGFh+rFOS/BlGy/Qmg/II1i3Lt8yWLLgYrzbnpBdpgeQoJNIs2yWZ3lRNeQsl8BfLGD9rizyf8DVmiSIXiHf6oO/g6IEh9bus86gQDaD/A2UxRFugnewfYwjJnLg4vLHFS1w1fqKEXVdjIm4Ord8wQouYLjugM5mQNfs4k0yQTEAS5t8A8huhdddHL/CglkXvl0Xng9E6ViXDmn5tW4BLlf7PHm4dNkJFep9TucFEirSGn0Pzz3fFwtw46LxaFLGxQqUN7Zz2FheYeUxsKrrCpDFZfpOni4LQHyE3/MUXsiZKp4TPUWRF9hh4MFCaJHEsc0n03TtwLLdwPWtiGz+1AW4xetwbh7E8p88n2rmzE7nyXWoU6gPcuo/6iAVD8/d9XlqOiJGFXuMo4rnkaNKaEkeVVwR0DljhM61GtBFkqHzREDnjhG6ppZLh84XAZ01RuiaUSf9Nix48DaM481RPT/qujnyZd4cuWH4ZIfn+xbbchoC2Fj9ybuj0HoKrPP9T0DeHYUuc+1Ad0ehOozxejKmJSaHYYzTuEcKokYs9yWFa3c0JBj46EHg67lXPcHqM/c6z/LOU76rvW7M8ziSzO1JMk8qyRq6cvap7iVZs6HQGZZk9eEfZ9mZWd+u1nSw7IpYfdwEjizr6wy4UsWvMQJF7mdZ5nU0JJplLOPw0bGsJ8fkjWTOd8Gx5uSmOQD1lku/Y0gUzTFbFY6pN4pJ1crxMIxhVM4jIwqN6MWYe0YIFwJj/mJMZ0Y0ocgHZ7ElyThy6osZeT1PxlVxlq42sLiABAGwformxOkiziZ4xVuaJFnbpLzI95sETcEr9iEvAD83s3n5IyGJi2UG9Cy7ftB1TTDbbOfSQ7Nsq92XTNL3i7lxqtpt400v38Rk+SZX1stND+xcdzocVU2cmJLU4UAV32mEsEczxWUMReKY0m6DimdKi9GtmcJiiimbKe2uq3im2JopN5hCPjENpY8pLJN3KKa02PiaKSymSB9TWObuUExpybvRTGEwJZA+pvRwg3freIsWy/g1a8xtWZ22g9OleiqAum0BWRSnG9T71T6LPMvi7S6tGjttsU6z5Jf4mO/L+jB1iZpXVGV8bpZBPf5LYhAumY///EUIXpd8YAzdBow9H/817TF+WVg97NYaRniZZRpn/wOLMt6s+iBKI5YU+faP2h1AFVs0OQbF/B324K6eEtLhWOZbvDIDy3rf17ws8zdcKHBvnRutusqbwj94jTNktHnwamawbF3K8A9tXpSzfAORj9MKRxDvyg+w66ZRH0bcCJ+bDsiwPKANUZcrEar01vhChBz22jKrnK81HEnBhgfugsC6yndtA4s19ooDi+Usvmi4OuA6kLBIQ4+VXqiVs0M5A9dTTDlZlp5WTuHKaXfnRg/LA9qws7gS4bseirsfJQ479rI8M43VTaxUkc0emYpaNpuoWWZzxtkzV1gcjj3yB7VuCgjvQDHdpA0kPeMkg0Qd3XRYNpGecXbBpYh0OrS5o6WzUzoj1ZTTYdk+WjmFK6fT/frAsDygDSRHD8VEkCiknIJtojFipYpsslKxtGze+4hTumwK9ny0bN4KH4VkkzaQ9FBMBolCsinYJRojVqrIps4M4vF8U7ZsuizLR8umeNlULDPIpc0jUw/FRJCoI5uuYItojFgpIpuuTgviMNsMZacFuTotSIpsuoqlBbm0eaRNWjJIFJJNlkWkH292waWKcurMIA4TTvnKqROD5CinYolBLu0f6YRaMkjUUU5PsEs0RqwUkU1PZwVxyArq++1dcTAKtny0bN4KH3Vk06P9I51PSwaJQrLJcon0hLMLLlWUUycG8bBqpSunTgySo5yKJQZ5OjGoK0gUUk6dGHQ3VqrIpk4M4uHTypZNX7Dlo2XzVvioI5s+7R9pn5YMEnVk0xfsEo0RK0Vk09eJQRx82kj2401fJwZJkU1fscQgXycGdQWJQrKpE4M+A5cqyqkTgzj4tPKVUycGyVFOxRKDfNo/0hNOMkjUUc5AsEs0RqwUkc1AJwZx8Gmly2Yg2PLRsnkrfNSRzYD2j/QLnGSQKCSb+nNBd2OlimwqnxUkQxb9gJxNsr7bzvqtT4E46bSf27r4QIR+7ndd6zd/+EN9hwGk7Gj6ABzduTvDwqGNnKEj70hCKg35O1J/xhiI3ebMoHCEgs0ZHYhtgRj5cgMxvMPbGWEght1pOcPCoT0aSYFo1R9qkQb9HWk9Y4zEbuNlWDh0eo6sSIxsyZF4h3EzxkjszrkZFg6f6n3y55QhSdf5Kt/E2S951Ueo6/8GZXnEVlm8L3MSmKYjCXukOH7F7VWFb6gAQwEXnw/XK5+PRC+DZAVa+xhXlXVst11m2+foCpDFZfpOHoDVyXjX31GIX/ltUeMtO6vho+3yfbEAeK8LVFRDQfN1vWZDpyukGqowP1/PAzQI1KUBw9Dmwom2L/s+yInQ4sUJr/EuSvPnxUVzIhwZJ7hDHTWhNqMn73NgU1+6oJsSDXek4b4Nt2Xyw5v6qcDhAY/oB9PKAM5xmG/7pU3O0h/4nKSfakg0Dei0PmVoIEr62360nLP0f54TDekPgoE5Qc/JlOEERxq0fTOM96yA19BANSSaBvS7MsrQQNTQ0Pb5Vd6zAl5DQzj00EB/50oZTnCkQdtrqpyHhoiXYUA1JJoGnro0EDU0tH3xg/PQ8HlONIaGaGDDIFLYS1RjBtk0DCJ+hgGjKdFwK+wZcoz6tkRY3krA6yaRakg0DcZmE/a5OxAzcaCUgNdNYjT0TaL2Eu9VAo+fEtBNCYbbMhkpbvPQmM4NOIWce0YYGNOJMX8xpjMjmlDcKMGhJMEms+TxM1rGY9s4S1cbWFwA9DgfVqBnsukiziZ4xVuaJNWDY9bTYpKTTYLhS3okH//87lH99N1y6IT8+k1bIiFfVD6+ZTJy0hBULwikeWBMQiOcaqiQ2S8dKpsBFQym0Iie0cIkqKCC/06MqW/MfQNeQ2hh8MIZ2mYKa3wE8MSvVvlGZBrRDO01dY2JjRYgzKGLVsEYhWvnkTGxqgZhy7Yxjaq9XBTN6OjwuB7aBup+9FKfD30rOFqiOPWXFW8RxWG+ZSOOKd/3V6tEgOLToAz6gppl8v0g/Hef0iboPUXMfZoZ8oCnM9z0K8CNsBgCLlgs8ry8vtWFPbj+NU8A2uL/ \ No newline at end of file diff --git "a/docs/cs-basics/data-structure/pictures/\345\233\276/\345\271\277\345\272\246\344\274\230\345\205\210\346\220\234\347\264\2421.png" "b/docs/cs-basics/data-structure/pictures/\345\233\276/\345\271\277\345\272\246\344\274\230\345\205\210\346\220\234\347\264\2421.png" new file mode 100644 index 0000000000000000000000000000000000000000..c9041cd7669302e54c8205a4870e7a26cec4f8da Binary files /dev/null and "b/docs/cs-basics/data-structure/pictures/\345\233\276/\345\271\277\345\272\246\344\274\230\345\205\210\346\220\234\347\264\2421.png" differ diff --git "a/docs/cs-basics/data-structure/pictures/\345\233\276/\345\271\277\345\272\246\344\274\230\345\205\210\346\220\234\347\264\2422.drawio" "b/docs/cs-basics/data-structure/pictures/\345\233\276/\345\271\277\345\272\246\344\274\230\345\205\210\346\220\234\347\264\2422.drawio" new file mode 100644 index 0000000000000000000000000000000000000000..f4ad6803c4f7c9cfa1d5a4d1d3449e13dfd66986 --- /dev/null +++ "b/docs/cs-basics/data-structure/pictures/\345\233\276/\345\271\277\345\272\246\344\274\230\345\205\210\346\220\234\347\264\2422.drawio" @@ -0,0 +1 @@ +7V1dj6u2Fv01PHbElw08JmmmVdUjVT2VbvtUMYEk3MuElJCZpL/+mg8TwCaQxMY+Oa6OOmDAgNfae9vLG0ezFu+nn1J/v/2SBGGsmXpw0qwfNdM0DB2iP3nJuSzxdL0s2KRRUJ10Kfga/RtWhfi0YxSEh9aJWZLEWbRvF66S3S5cZa0yP02Tz/Zp6yRu33Xvb0Ki4OvKj8nS/0RBti1LXdO5lP8cRpstvrMBvfLIu49Prt7ksPWD5LNRZC01a5EmSVZuvZ8WYZw3Hm6X8rrXnqP1g6XhLhtzATj/8vHl01wdX0+f7t+zv/eGt/2hquXDj4/VC2smjFF987f8kbNz1Q7wn2P+nPN1sst+OBQozdAJJtifLgfR1ib/q+M60MO84cKqEeoaTfR0CES0M//cRln4de+v8iOfiEeobJu9x2jPQJv+YV8iu45OYZA/RBTHiyRO0qIia70O4WqFyg9ZmvwvbBwJHO8N8Q3f/CNMs/DU23xGDQpic5i8h1l6RqfgC6wKx4rIAFT7nw1aVEXbBiNwmV8RcVPXfMEKbVRw3QCdSYGu28S7YJbbANrbJbuw3azovdPzn2hHxzt/NXd+PLX2znjvFGV/4hrQdnHNC6j2LhflO/ia8rnCgLC0TtujZ0+O6Sq88tKVN8n8dBNmV86z6Fg2sAIUrHBZGsZ+Fn20H5cGYHWH35IIvUhNFVv3XjwPOKbrABNYru60mWPpL7pum45h2o4NDa9df9kGVZVNe+7cxXLhC4BENTU9rRfbujxD5yXKBiRuUhCxbq/7uWnxcCvmM7oV22y7FWgKdis2D+isZ4SuxqCCztEFQwd4QGc/I3TdYC4cOsgDOuMZoetanfB+mPNgP4xh7wgPkIZ6R1Bk78gC7ovp1v0WZIudANg5fF/vyAbGi2PU/R/HbffBYOdwpw/GuXvkykMZMJIyPUY5DWXMbidJ7xjzWFaY3kBFnIH3HgQej77wEGvM6Kse59WDvsZVV0Z6DElmjyQZEEkyo9udM+4kWbciaE9LMvzcj7OsZtZfjSMDLGsQa4yewJBlY7UBW6gr63ggB9zrysyBinizjCYdPurLRnJMnCezvgWOWdaAAxotMXWHSV2XyJtjpiwck8+LCY2Vz8MwilK59DTP1bxXbQk0F2042vJVmy80b0aQDw1jszbj2mPfipHNgXJV5MfRZod2V4ggISqf54PiaOXHs+rAexQEcd+oPE2OuyAfgxfsy8WAaubMZCWQgDYuLu7TNPiFZ7qa/DL1fio9NMo2+nXJIPq4iBtl0WHv70bpJjpNN2lIL1c1sLqsvB1R3HowKZnDgClA71gwJJliUzwRP6b0y6D8mdIjdCum0JhiiGZKv+rKnymmYsoVphjt7oVwn0ITeadiSo+Mr5hCY4pwn0LTdqdiSk/ijWIKhSlAtE9xIdHY7ZdO0mybbJKdH/+aJPuq9f8bZtm56uz7xyxpY9MdCfTk+DBUTIaVEJ0Oy4MjUAA7ht/FaewIFBoDFfGeC3LkpUFRT/VcBkNOWD0TkA9yArqsOGGCdkXWxJxwn4wTzKF2ulAb3gu4D2y36wDIqnjD7Sm4r8PtsoPbEw43ngGSEW6GTt7smQNhHPiBwyjwExXxpoEhLw14BX6TT2ewG/jv50Qn8INu1hhvTpjycoIhDWx3EtcAWbkGoiLeNLDkpQEv12DzCRfEmICVa4BTuwZbXk4wpAGcRi5wWMkFREW8aQDkpQEv1wCmkQvu50THNTgTywWexEqiHOPHrlzgsJMLKFXxhltixZCh1TvmNJGAVSeRqIg3DZ5NJBzTO+AzcCAiAatOojN1J1EpibdGAsguEpBVcc/0p6T6L11tvtTQEDJPX3S0+UylL5qeTU72Tpu+iGefu0i95hgtHW3mau5cIWW6lO/fJ0bKpCCFTOlVQ/3si03VScKeNoPFIYTgTHPNHE30/7lXoekuSJPUG8eANtc1F4170XUIedfOizxUtMxL5nNt5hQ3MbQ5JOp2tSW6+UKbzfKbzJY5ofJHc/LtJr+qmsurvOIqO3+o/ImANgOUrGf2HIzDdSYdAxHn2gzECaTND4odg6Rgd5THjoIGOUOUh0ocPS9BfHkpna+O6UfRTgbRandEfeIb7tdXC/13Qxefeejufvntenf20ixjoCLun06RwYBE/DsxN1poBgbF3Ph5/BFf5R62/j7fzPy3oukaqNBa8YAYhBsub7cVakc/2uXxt7hmlcSxvz9ERWXlGdsoDn71z8kxw7fBewQK7Z40sQ5D4IfumroOA1y54duaDY5Od/p05DoM3S+F2K2HNeKzVwwjes0s8uPfw1Xm7zZjECURC9Jk/wcesOYF+9xfhOnyA7XgARsQaZ1Z4YHzg6V9FptvSZYl79VOWrVWXWnRVGCO/qF3XORDLYDeZoH2jcs++pefnmaLZIeQ96MCx9A/ZJ/hYZhGYxhxxXxIngjjAelcyamTR4hQLDToX4iQoFZbx8UXiFvkWsMdC9w5gdU3AT+QBMsPLEpnG1Wo4LoO16kNizD0aOu8qcg5EDmh0UkyER45ad9WqsjJPXKaw6tUTssD8stJMkftu3XFw0s6TOt7aR8vKqyuYiVL2ByxZJwKm13UiMTtkWs28oNxxDJuKmxysG5HsrBJ6kdqwNk2EnnCpkVTidSAcwguSSKnRZlFVZFzKHISX7iJjpwWTfVRkZN75LR6eCKMB6R+RH758L264tJIJIqcnFWiZ8RKlrBJWxJLhc0bZzjFh03Oko8Km9fMR6KwSepHyhUPrS0izPdyVomeEStZwqZKDGIwvSk8bNo0yUeFTf5hU7LEIHtM1uX36or7lmkT5XttzhLRM2IlSdi0VVYQi9Gm6KwgW2UFCQmbtmRZQTYpHimRdmjVGmG+lyYRqenNIbhkiZwqMYjFgFN45FSJQWIip2SJQTapH6l82qE1AEX5XsBZJXpGrCQJm0BlBTHIChr7G+j8YOQs+aiwec185AmbgNSPVD5t20gkCps0lUgNOIfgkiVyqsQgBlKt+MipEoPERE7JEoOASgwaMhKJIqdKDLoZK1nCpkoMYqDTCg+bkLPko8LmNfORJ2xCUj9SOu3QDzI0fS+YEizOKtEzYnVq49SAzpoUOpUYxEKnFT29CVVikJCwCSVLDIIqMWjISK6ChT8vmAYslRh0D1ynNlTNTg9liVp+6KnEIBY6rfDIqRKDxEROyRKDIKkfqQHn0G/8iIqcDmeV6BmxkiRsOqSwo8LmYNgkdFrRYdPhLPmosHnNfOQJmw6pH6kPOId+LlHUHJmjlgu6GStJpjcd6bOCRIRFYLdHk7Rl2wEFJo44qbSf63HxAQsdzuyhYY2//GEP9Q0CkLTe9AE4hnN3poVDCTlTW965Dakw5G9I/XlGQxwWZyaFw+UszihD7DNED4o1RPcGbecJDdEdTsuZFg6l0QgyRAMv1CIM+hvSep7REoeFl2nhUOk5oizRMwVb4g3CzTNa4nDOzaRwGPq3nfD4uGZm4t/Gwb+07QiWNg2d7afE37wz5PWjwPpwsuLEwNN8I4xxG6Ajq1o3hv8ckzJSWOt18bP3jSK4yf/q+GL0NOX1Zfm352+5MUCypdEM/Qa5/Cm9sYWnS69440kndA2ds6yt3PNVW5Bnat/QaYr6/e7ZUO55iAHDOZETu2easn4/A2zFgDsZwD0LAe2mSQ5Wfewn1KDbL0kQ5mf8Hw== \ No newline at end of file diff --git "a/docs/cs-basics/data-structure/pictures/\345\233\276/\345\271\277\345\272\246\344\274\230\345\205\210\346\220\234\347\264\2422.png" "b/docs/cs-basics/data-structure/pictures/\345\233\276/\345\271\277\345\272\246\344\274\230\345\205\210\346\220\234\347\264\2422.png" new file mode 100644 index 0000000000000000000000000000000000000000..4f8dc6e06fc34d6227bde4d13a7871270bf7b99d Binary files /dev/null and "b/docs/cs-basics/data-structure/pictures/\345\233\276/\345\271\277\345\272\246\344\274\230\345\205\210\346\220\234\347\264\2422.png" differ diff --git "a/docs/cs-basics/data-structure/pictures/\345\233\276/\345\271\277\345\272\246\344\274\230\345\205\210\346\220\234\347\264\2423.drawio" "b/docs/cs-basics/data-structure/pictures/\345\233\276/\345\271\277\345\272\246\344\274\230\345\205\210\346\220\234\347\264\2423.drawio" new file mode 100644 index 0000000000000000000000000000000000000000..bbe5df1038248c25440aa87e35d94ecdaf0ee093 --- /dev/null +++ "b/docs/cs-basics/data-structure/pictures/\345\233\276/\345\271\277\345\272\246\344\274\230\345\205\210\346\220\234\347\264\2423.drawio" @@ -0,0 +1 @@ +7V1ts6I4Gv01fJxbvL98VFtnpna6qmt6a7f7I1dQ2eWKg3ivzq/fBBIlJAhqArluprrmmiABcs6TQ04eULNmb8df83C3+ZpFcaqZenTUrC+aaRqG7oI/sOZU1QS6XlWs8yRCX7pUfE/+jlEl/tohieI98cUiy9Ii2ZGVy2y7jZcFURfmefZBfm2VpeRRd+E6piq+L8OUrv13EhWbqtY3vUv9b3Gy3uAjG25QbXkL8ZfRlew3YZR91KqsuWbN8iwrqk9vx1mcws7D/VLtt2jZej6xPN4WfXawv36L8t+m/8rNX6PdP34/7X/+vvoFtfIepgd0wZrppqC96Ss85eKE+sH96wDPc7rKtsUv+xKlCfiC6eyOl43g0xr+1XEb4GRecSXqhHOLJjg7ACIoTD82SRF/34VLuOUD8AjUbYq3FJQM8DHc7ypkV8kxjuBJJGk6y9IsLxuyVqvYXS5B/b7Is//GtS2RF7wCvuGDv8d5ER9bu884gwLYHGdvcZGfwFfQDqaDcEREdgNU/qjRAlVtaozAdSEi4vrc8gUr8AHBdQN0JgO6ZhdvowmMAVDaZtuY7FZw3fnpByjouPCzXvhyJEonXDomxQ/cAvhc7vPioNJlJ1jA+1TnFUdUpDX6Hpx7dsiX8ZWLRqNJEebruLjyPYuNZQ0rh4EVrsvjNCySd/J0WQCiI3zLEnAhZ6o4ZvASBI5n+p5jOpZvkMTx9Bddt03PMG3Pdo2AbL7qAtRiPZybB9HdF8elmjmz03qxLeoU8EGq/qMOUvLw3F33U9MSMaqYzziqODY5qnjuyKOKLQI66xmhs3USOt8eGTpHBHT2M0LX1PLRoXNFQGc8I3TNqBv9Nsx78DaM480Rnh913Ry5Y94c2Z7/AgIO37eYhtUQwMbmO++OPOPFM873Px55d+QFzK0D3R358jDG6cmYlpgchjFW8x7JbsRyX1LYRkdDgoEPHgQez73wBKvP3Os8yztP+Wp7XZnncSSZ3ZNkzqgka97NOXeSrNmQ11QewSTDHH+cZWdm/axt6WBZjVh93ASOLOvrDNijil9jBPKDe1lmdzQkmmUs4/DRsawnx8YbyaxPwTGnYwDqLZfNWVJzSBTNMVMWjsk3io2qlc/DMIZROQ+0wNeChTZ3NB988LT5QpvOtGBCkQ/MYguSceTUFzGyPk9GVWGarLeguAQEiUH9FM6Jk2WYTtCGtySK0rZJeZ4dthGcgpfsg14AWjczefkjHomLoeNFrBrB8EJXnWCm3s6lh2bZRrsvGSXvF3Ojqtrvwm0v30Rn+SY16+WqB3auqw5HVRMnJiV1OFDFNUmqnNd3a0yxGUOROKa026DimdJidCumMJhyHuxHY0q76yqeKaZiyhWmkCum/uhjCsvkHYopLTa+YgqDKd7oYwrL3B2KKS15N4opLKaMPqb0cIP3m3AHPxbha9qY27I6bQ+mS3gqALttCVgUJlvY++U+yyxNw90+KRurvrFJ0uiP8JQdCnwYXKLmFWUZnRtNBM203KUfv640amEwCmN/teQDo281kml6Lv81nX5+WVg97FYMI7jMIgnTP+NlEW7XfRClEYvybPdP7A7Aih2cHMf5/B304B5PCelwLLId2pjGK7zva1YU2Rsq5Ki3zo2WXeVMwT9wjTNotDngamagbFzK4B/8el7Msi1gRJiUOMbhvviI99006sOIK+Fz1QEZlge0IWpzJUKZ3hpeiJCBXlulpfO1ASNpvOWBuyCwavmubWCxxl5xYLGcxYWCqwOuIwnLaOix0guVcnYop2c5kikny9JTyilcOc3u3OhheUAbdgZXInzqobh7KXHYsZflmSmsrmIli2z2yFRUstlEzdAbM06vZ66wOBx75A8q3RQQ3p5kukkbSGrGSQaJPLppsWwiNePsgksS6bRoc0dJZ6d0BrIpp8WyfZRyCldOq/vxgWF5QBtIlhqKiSCRSDkF20TPiJUssslKxVKyeeMS5/iyKdjzUbJ5LXwkkk3aQFJDMRkkEsmmYJfoGbGSRTZVZhCH9c3RZdNmWT5KNsXLpmSZQTZtHulqKCaCRB7ZtAVbRM+IlSSyaau0IB6zzbHTgmyVFjSKbNqSpQXZtHmkTFoySCSSTZZFpJY3u+CSRTk/e2ZQmz62KyoH5aQmnKMrp0oMGkc5JUsMsmn/SCXUkkEij3I6gl2iZ8RKEtl0VFYQh6ygvu/eFQejYMtHyea18JFHNh3aP1L5tGSQSCSbLJdITTi74JJFOVViEAerdnzlVIlB4yinZIlBjkoM6goSiZRTJQbdjJUssqkSgzj4tKPLpivY8lGyeS185JFNl/aPlE9LBok8sukKdomeEStJZNNViUE8fNqxlzddlRg0imy6kiUGuSoxqCtIJJJNlRh0D1yyKOdnTwySw6cdXTlVYtA4yilZYpBL+0dqwkkGiTzK6Ql2iZ4RK0lk01OJQTx82rFl0xNs+SjZvBY+8simR/tH6gFOMkgkkk31uqCbsZJFNmXPChpFFl2XnE2y3tvO+q1PgTiptJ/ruvhAhN73u674yR/+UN9gAEk7mj4AR3fuzrBwKCNn6Mg7kZCOhvwNqT/PGIjd5sygcPiCzRkViG2BGLjjBqJ/g7fzhIHod6flDAuH8mhGCkQDv6hlNOhvSOt5xkjsNl6GhUOl54wViYE5ciTeYNw8YyR259wMC4dL9T75c8qApJtsnW3D9I+s7CPY9f+Ji+KErLLwUGQkME1HEvRIfvqB2isLP2EBhAIqfjnWN345Eb0cR+u4tY9RVYFju+0y215Hl8dpWCTv5AFYnYx2/QZDvOa3+aTf5rkNH22fHfJljPa6QEU15DXfrNZsqLpCqqES8/P1PEADT14aMAxtLpxoe7Pvg5zwdV6csBvvDPIG5oT/ZJzgDnXQhNoJXpz7wKZ+/4ZuSjTcgYL7OtyGzg9v+qcCBwc8oBempQGc4zDf9kubvKXf4CX9zYZE04BO65OGBqKkv+1Hy3lL/92caEq/OTAn6DmZNJzgSIO2d4ZxHhp8XkMD1ZBoGtDPykhDA1FDQ9vrVzkPDfdzojE0+EMPDfR7rqThBEcatD2mynto4GUYUA2JpoEjLw1EDQ1tb/zgPTTwMgz8gQ2DQGIvUY4ZZNMw8PkZBoymRMMtsWfIMerbEmE5K0HA6yaRakg0DZ7NJuxzdyBm4tBUgvs50VCCYOibROUl3qgEgc5NCRhNCYbb0BkpbnNfm841MIWcO5rvadOJNl9o05kWTChuFPGxIMEms+fRGi1j2TZMk/UWFJcxXM4HFXBNNlmG6QRteEuiqFw4Zq0Wk5xsEgxd0iP5+Ca+A8Or7zpOBqyt9+InbYmEfFH5+AbmXROqBQRp7mkTX/OnCiozcEdHymQgBWJpoYEb7UtQBRpQ4GABP0zcchNAcKL5JkQT/H8aIDT9GR2TRm2bo011zXcNuB9A3rdhVQCq5rBmOtUmXnkQQ5u6VNu+NgcHn2mTCTzIZA4JBU/Ng5/r/EItV3sF5V42PCl4Ro42cWoX5MBmGXeZj3OwyvGQjIEW/i2OKwx08F3jQBRkPc2IGUOvGzwtMH73KO4YwyJzQwadhI+N848WIGwjPwJu6IJT2z59VqOgR1VRMNBUGY8JrKce3RT3AdiyPD8A6v51yKqUT2u1ssB/9Sp3Df8aeGdwNtX+VT1Xdn3mh5VR6F1lwKCPJxs6/TCk+oGQTrgkebgcCPz/ubrafnPiylBXwxwWFMGPNSp5vRoNVwfXgalg0H6TGl0bgSKRGBoMz+mB2yFT3Q7dyQBZ9NVgWFsPEMJShHiMEAw/Y2BC0JlmcFEGX/pluWh+qZ0uD/l76fsYlAt0x/oS9cKexaJkW//FZO6LRLbdvAuz7lwQtKmFiGZLdy8RgWKewXC8fB2EzOZrFsXwG/8D \ No newline at end of file diff --git "a/docs/cs-basics/data-structure/pictures/\345\233\276/\345\271\277\345\272\246\344\274\230\345\205\210\346\220\234\347\264\2423.png" "b/docs/cs-basics/data-structure/pictures/\345\233\276/\345\271\277\345\272\246\344\274\230\345\205\210\346\220\234\347\264\2423.png" new file mode 100644 index 0000000000000000000000000000000000000000..942cbaffd4677cc69adf71c72a203fc082bb2736 Binary files /dev/null and "b/docs/cs-basics/data-structure/pictures/\345\233\276/\345\271\277\345\272\246\344\274\230\345\205\210\346\220\234\347\264\2423.png" differ diff --git "a/docs/cs-basics/data-structure/pictures/\345\233\276/\345\271\277\345\272\246\344\274\230\345\205\210\346\220\234\347\264\2424.drawio" "b/docs/cs-basics/data-structure/pictures/\345\233\276/\345\271\277\345\272\246\344\274\230\345\205\210\346\220\234\347\264\2424.drawio" new file mode 100644 index 0000000000000000000000000000000000000000..620445a760678ae030887913c5a710bc5e7450ca --- /dev/null +++ "b/docs/cs-basics/data-structure/pictures/\345\233\276/\345\271\277\345\272\246\344\274\230\345\205\210\346\220\234\347\264\2424.drawio" @@ -0,0 +1 @@ +7V1dk6o2GP41XHaHhO9Lte7pxelM29OZ9lx1WEGlZcUi7rr99U34EkgU1ITkcNI505UAAfM870ceXqJmLF5Pn1J/v/05CcJYg3pw0owfNQgB0G30B7d8FC2erhcNmzQKyoPODV+i/8KysTrsGAXhoXVgliRxFu3bjatktwtXWavNT9PkvX3YOonbV937m5Bo+LLyY7L1jyjItkWrC51z+09htNlWVwa2V+x59auDy29y2PpB8t5oMpaasUiTJCs+vZ4WYYwHrxqX4rznC3vrG0vDXTbkhN3Xf2I9PX41Pv26/LyAf/0U/538UPby5sfH8gtr0I5Rf/MXfMvZRzkO9r9HfJ/zdbLLfjjkKM3QAdDan8470acN/qtXfaCbeakay0Goe4To7hCIaGP+vo2y8MveX+E974hHqG2bvcZoC6CP/mFfILuOTmGAbyKK40USJ2nekbFeh/ZqhdoPWZr8Ezb2BI73gvhWXfwtTLPwdHH4QA0KYnOYvIZZ+oEOqU4wSxxLIgOn3H5v0KJs2jYYUbX5JRE3dc9nrNCHEq4boIMU6LpDvAtm2AbQ1i7Zhe1hRd87/fgTbejVxtfmxo+n1tZHtXWKsj+rHtDn/Jwnq9w6n4Q3qnOK+woDwtI6Y4/uPTmmq/DKly69SeanmzC7cpxBx7KBlUXBqmpLw9jPorf27dIALK/wSxKhL1JTxQTek+dZDnQdC1qGqztt5lj6k66b0AHQdEwbeEb7AsUglH02DbpzGcOznyy70U+Hn8aTaZxvAnSuUgwhcZWcivWI3c9Og4djgVN0LKbRdizQFOxYTB7QGVOEDmUzLegMKBg6iwd05hSh64Zz4dDZPKADU4Sua3XCMzHnwUyMYX5UTZH68iNbZH5k2O4TdOvEBVapSR0A6btvzY9QSvTkgDoDctx2Gob6p+4eKUFy5SGNNZA0F8xyHNLAbpoEO+Y8OG3WezriDLz3IPDVDKyaZg2ZgdVzvXri1zjrymyPIcnMgSSzRJIMdBM6406SdTuC9rgkq+Szx1lWM+trY08PyxrEGqIpMGTZUH3AFBr/Oh7IcO5kWdcnEh3xZhlNPnzUlw3kmDhPZnwTHDN7HNDgcNmdKHVdIm+OQVk4Jp8XExorp8Mwila59DTP1bxnbWlpLvrgaMtnbb7QvBlBPjSRzdqMa89+S0Y2p8plkx9Hmx3aXCGChKh9jqfF0cqPZ+WO1ygI4kvz8jQ57gI8C8/Zh+WA8ukZZCWR2G1crCpsNfhVPe1q8qubTzObZ4PLymQQvZ3ljaLpsPd3g5QTnaacNMSXqypY3VZcjmhu3ZiUzGHAFAt0LNglmWJSPBE/plwWQvkz5YLUrZhCY4ohmimXdVf+TIGKKVeYAtrphXCfQpN5x2LKBSFfMYXGFOE+habtjsWUC8U3iikUpgDRPsW1icFuf+kkzbbJJtn58eck2Zej/3eYZR9lsu8fs6SNTXcmcKHOh6Fi0q+E6HRYHpyBWk7H8M07Z6A27OmI97MgR14a5P2U9wUYcsK48AjyQU7YHitOGFa7I2tkTrgT4wRzqJ0u1Ib3ZN0Httt1AGRXvOH2FNzX4XbZwe0Jh7t6PCgj3AydPLzwDIRx4K+ftj4a+ImOeNMAyEsDXoEf8kkGu4H/fk50A78+MiegvJxgSAPTHcU1QFaugeiINw0MeWnAyzWYfMIFMSdg5RqMsV2DKS8nGNLAHkcuMFjJBURHvGlgyUsDXq7BGkcuuJ8TXdcwslzgSawkyjF/7MoFBju5gNIVb7glVgwZWr0Dx4kErJJEoiPeNJiaSDgkO+AzcSAiAask0Rw7SVRK4q2RwGUXCciuuFf6U0r9l642X2poConLFx1tPlPli9CyyYe945Yv6pRyeYzUM8Zo6WgzV3PnCiloUt6AHxkpSEEKmdKzhvLss03VRcKeNrPzXQjBmeZCjCb6/9wr0XQXpEmajX2WNtc11zbxeQh518RNKAC5S9wyn2szJ78I0OY20berLdHFF9pshi8yW2JC4Vtz8Ocmv8qei7O8/CwT3xS+I0ubWZSqZ/YcjMN1Jh0DUbTvZ6AFRqUgWZWu14wB9SdSEZosRG6vO6/re0aCiFaP3kEDpzdVxnNOvJbn1vnqmL7lAweIYbwjUyPevH9+NtB/N0zLmKdbdTV4hRy4M7M2YU9HvFOtAa/uHrb+Hn/M/Jcc3QY0NLM5oFuuLAUjvkKG40c7HKTzc1ZJHPv7Q5R3VhyxjeLgs/+RHLPqMtUWYXbtdJtYriHwQ3dNXa7BXrnhy5qN4TrdZ6wDl2voKnHsFs4a8G5sBSP6mlnkx7+Fq8zfbYYgSiIWpMn+92pWixv2mKBhunxDI3ioPCbpjrPc5PHOwiHnH1+SLEtey420HK2603yorDn6h77jAs/HLPRtFmgbnLfRP3x4mi2SHULej3IcQ/+QvYeHfhoNYcQV8yF5IowHZDpORtNHiJCvSOifiZCgUVvH+WuKWxRLwx0L3DmBdekpfU+lLD+wKBk56lDBdR2uUxsWYejRloNTkbMnctqwrSSKj5wDEl4VOTlYd/9yluPygHy9kixk+25dcf+6D+P6Xtobjgqrq1jJEjYHrCynwmYXNaK6e+DSjvxgHLDWmwqbHKzbkSxskvqRmnC2jUSesGnQVCI14eyDS5LIaVAetarI2Rc5idfgREdOg6b6qMjJPXIaF3gijAekfkS+HvG9uuLCSCSKnJxVoiliJUvYpK2bpcLmjU84xYdNzpKPCpvXzEeisEnqR8oV9y1AIsz3claJpoiVLGFTFQYxeLwpPGyaNMlHhU3+YVOywiCTFI/I5Vq+V1d8aS03Ub7X5CwRTRErScKmqaqCWMw2RVcFmaoqSEjYNCWrCjJJ8UiJtH1L2wjzvTSJSD3e7INLlsipCoNYTDiFR05VGCQmckpWGGSS+pGqp+1bKFCU77U4q0RTxEqSsGmRwo4Km71hk1jjRLROa3GWfFTYvGY+8oRNi9SPVD1t20gkCps0lUhNOPvgkiVyqsIgBlKt+MipCoPERE7JCoMsVRjUZyQSRU5VGHQzVrKETVUYxECnFR42bc6Sjwqb18xHnrBpk/qR0mn7frVBlO+1OatEU8RKkrBpq8IgFjqt6MebtioMEhI2bckKg2xVGNRnJBKFTVUYdA9cskROVRjEQqcVHjlVYZCYyClZYZBN6kdqwtn3Q0CifK/DWSWaIlaShE2HFHZU2OwNm4ROKzpsOpwlHxU2r5mPPGHTof12inLF139TUZjvVcsF3YyVLGFT+qogEWHRstqzSdqy7RYFJo44qbKf63HxAQvtr+yhYV29+cMe6hsEIGm96QNw9NfujAuHEnLGtryPNqTCkL+h9GeKhtgvzowKh8tZnFGGeMkQPVusIbo3aDsTNES3vyxnXDiURiPIEEG1UIsw6G8o65miJfYLL+PCocpzRFmiBwVb4g3CzRQtsb/mZlQ4gC69kPawvnldMyN+gN0jNTMAx9Q2ga5EMzE/E6z3S2pjU4EmqtlxNQhoz6qWku1/j0kRPIz1Ov/p9UaTvcF/zepkdDfF+UX7t+eCuVFAslfwgE7qeN9gxBwbLkkeUwGd1OImV4D8SD7UB6ArGkBwg3o3yfzIHJAfjVpiAQBnWU2lR1dtQZ5iGwBIRU/Fxo6dSJTKAPVbanfAxT2VQZtpgqcJ9b5PaEC3PydBiI/4Hw== \ No newline at end of file diff --git "a/docs/cs-basics/data-structure/pictures/\345\233\276/\345\271\277\345\272\246\344\274\230\345\205\210\346\220\234\347\264\2424.png" "b/docs/cs-basics/data-structure/pictures/\345\233\276/\345\271\277\345\272\246\344\274\230\345\205\210\346\220\234\347\264\2424.png" new file mode 100644 index 0000000000000000000000000000000000000000..c2c804ac51baa121ed95e0ee587fbad263ae0c07 Binary files /dev/null and "b/docs/cs-basics/data-structure/pictures/\345\233\276/\345\271\277\345\272\246\344\274\230\345\205\210\346\220\234\347\264\2424.png" differ diff --git "a/docs/cs-basics/data-structure/pictures/\345\233\276/\345\271\277\345\272\246\344\274\230\345\205\210\346\220\234\347\264\2425.drawio" "b/docs/cs-basics/data-structure/pictures/\345\233\276/\345\271\277\345\272\246\344\274\230\345\205\210\346\220\234\347\264\2425.drawio" new file mode 100644 index 0000000000000000000000000000000000000000..8dc681fa499b670e25f88cb9840461a2506609b7 --- /dev/null +++ "b/docs/cs-basics/data-structure/pictures/\345\233\276/\345\271\277\345\272\246\344\274\230\345\205\210\346\220\234\347\264\2425.drawio" @@ -0,0 +1 @@ +7V1fs6q2Hv00PHYPfwM8qlvPfWhnOj1t7zl9Ywsqt2yxiHtrP/1NEJCQIKgJyXHSOdNtggTIWr+sZPEDNWv2fvySBbvNL2kYJZqph0fNetVM0zB0AP+gmtO5xtf1c8U6i8PyS5eKr/G/UVlZfe0Qh9Ee+2Kepkke7/DKZbrdRsscqwuyLP3Ev7ZKE/you2AdERVfl0FC1v43DvPNudYz3Uv9f6J4vamObAD/vOU9qL5cXsl+E4TpZ6PKmmvWLEvT/Pzp/TiLEtR5Vb+c91t0bK1PLIu2+ZAd/v37y5+rP798OtHy1fvDBpn9x18/la18BMmhvGDNBAlsb/qGTjk/lf0A/jmg85yu0m3+075AaQK/YDq742Uj/LRGf/WqDXgyb1Vl2Ql1iyY8OwgiLEw/N3Eefd0FS7TlE/II1m3y9wSWDPgx2O/OyK7iYxSik4iTZJYmaVY0ZK1WEVguYf0+z9K/o8aW0PXfIN+qg39EWR4dO7vPqEGBbI7S9yjPTvAr5Q62VeJYEhn4ZfmzQYuyatNgRFUXlERc1y1fsIIfSrhugM6kQNfu4m04QTEAS9t0G+HdCq87O32DBb0qfG8WXo9Y6VSVjnH+rWoBfi72eXHK0mUnVKj2OZ9XFBKR1up7eO7pIVtGVy66HE3yIFtH+ZXvWXQsG1g5FKyquixKgjz+wE+XBmB5hF/TGF5ITRVX919833FNz3VMx/IMnDiu/qLrtukapu3awPDx5s9dULbYDOfWQYAHXhxANFOz03qxLeIUqoOc+484SMHDurvup6bFY1Qxn3FUcU18VHGB4FHF5gGd9YzQOR4OnWcLhs7hAZ39jNC1tVw4dIAHdMYzQteOOuHTMPfBaRjDyVG1PuqbHAGRkyPgeC8w4Kp5i4lPjlxA3Xrr5Mh1jBfXqKc/Lj45cn3q1pEmR548hHEGEqYjJMchjNOeItmtUB5KCsfvaYgz8P6DwFdLr2p9NWTpVS/y6hVfY68ryzyGJLMHkswRSTK7PZlz7iRZuyG3LTycSVb5Zo+zrGbW98aWHpY1iDXETGDIsqHGgC10KGuNQJ5/71Bm9jTEm2U03/DRsWwgx8SNZNaPwDFg9QxAgw2m9iKpPSTy5pgpC8fkG8WEauXzMIziU859zfc0f6HNHc2DH1xtvtCmM82fEOSDi9gcZxy+8i0Z2Vwml1VBEq+3sLiEBIlg/RQtieNlkEzKDe9xGCZda/IsPWxDtAIv2IesgPK2mcnKHnFwXAy9kpsGwar7XE2CmXo3lx5aZBvdtmQYf1y8jXPVfhdsB9kmOs02aTgvVy2wuu58OKIaOzEpqcOAKp6OU6W+vdtgik0ZivgxpdsF5c+UDp9bMYXClHqwF8aUbtOVP1NMxZQrTME9QU/4mELzeMdiSoeLr5hCYYorfEyhmbtjMaUj7UYxhcYU4WPKADd4vwl26GMevCWttS2t0/ZwuVQtBVC3LSGLgniLer/YZ5kmSbDbx0Vj529s4iT8OTilh7w6TFUi1hVFuTw3QyPu/oVB5K2od//A0oveVmxgNHQDx3Ho7b+21c8uC2uA31rhCK8zj4Pkt2iZB9v1EEhJyMIs3f1e2QOoYodWx1E2/4BduK/WhGQ85umu3JhEq2rftzTP0/eykJW9VTdadJUzhf/gNc6Q0+bAq5nBsnEpw3/o61k+S7cQ+iAugIyCff4Z7ft5NIQSV+LnqgUyLg9IR9RmSoQivTW4ECGFvbZKCutrA4fSaMsCd05gNfJdu8CiDb78wKJZiwsFVw9cRxwWYejR0guVdPZIp185I9IoJ83TU8rJXTnN/tzocXlAOnYGUyL80ENx/73EccdemmmmsLqKlSyyOSBTUckmseI0WytOd2CuMD8cByQQKt3kEN6uZLpJOkhqxYkHiTy6adFsIrXi7INLEum0BqS7KekkpNOQTTotmu+jpJO7dFr9DxCMywPSQbLUWIwFiUTSydknekasZNFNWjKW0s1bb3KK103Oro/SzWvxI5FukhaSGovxIJFINzn7RM+IlSy6qZKDGNzhFC6bNs30UbLJXzYlyw2ySftIV0MxFiTyyKbN2SN6RqwkkU1bJQYxWW6KzgyyVWaQEN20JcsMskn7SNm0eJBIpJs0j0jd4eyDSxbpVMlBLFacwpVT5QaJUU7JcoNs0kBSObV4kMijnA5nm+gZsZJENh2VGMQiMWjo+3f54cjZ9FG6eS1+5NFNh3SQVE4tHiQS6SbNJlIrzj64ZJFOlRvEwqwVL50qN0iMdEqWG+So3KC+IJFIOlVu0M1YyaKbKjeIgVMrXDYBZ9NHyea18JFHNgHpICmnFg8SeWQTcLaJnhErSWQTqNwgJk6t6DucQOUGCdFNIFluEFC5QX1BIpFuqtyge+CSRTpVbhATp1a4dKrkIDHSKVlyECAdJLXkxINEHul0VXLQzVhJopuuSg5i4dSKlk2Xs+mjZPNa+Mgjmy7pIKmnOPEgkUg21UuDbsZKFtmUPjFIhCx6Nr6apL2+nfabnxxxUok/13XxgQi97/ddq6d/2EN9gwMk7Wj6ABz92TvjwqGMnLEj74RDKgz5G5J/njEQ+82ZUeHwOJszKhC7AtEHYgPRu8HbecJA9PoTc8aFQ3k0ggLRqF7WIgz6GxJ7njES+42XceFQ+TmiItE3BUfiDcbNM0Zif9LNuHAAovfxn1WGJN2k63QbJD+nRR+hrv9flOen0ioLDnmKA9N2JGGPZKdvZXtF4TsqwFAoi6/H5sbXE9bLUbiOOvu4rMqr2O66zK530mVREuTxB34AWieXu/6KQrzhtwHcb3NBy0fbp4dsGZV7XaAiGvLbb1drN3S+QqKhAvP6eh6ggSsvDSiGNhNOdL3e90FO+B4rTpit9wa5I3PCezJOMIfa0NtYO/6Lcx/a5O/gkG3xBtxXgPcAbjAEnPjNwNEB98lb09IAznCg7/rJTdbib7AS/3ZDvGlAJvZJQwNe4t/16+Wsxf9uTrTF3xyZE+SqTBpOMKRB15vDGA8NHquhgWiINw3Ix2WkoQGvoaHrJayMh4b7OdEaGryxhwbyZVfScIIhDboeVWU9NLCyDIiGeNPAkZcGvIaGrrd+sB4aWFkG3siWgS+xmyjJCrJtGXgMLQNKW7wBl9g3ZBj3XcmwjLXAZzVNJBriTYNnswqHzA/4LB3aWnA/J1pa4I89TVRu4q1a4OvstIDSFmfADZ2S6Db3tOlcg8vIuaN5rjadaPOFNp1p/oRgRx4dcxxuPFe+vFNLuXkbJPF6C4vLCN3UhxXozmy8DJJJueE9DsPi9jHtnjHOyjbFykt6JCvfru7onmrcybT86nlbLC2fV1a+oVMy0xBUCwTS3NUmnuZNFVSmD4QjZVKQgrG00OBk+xJUvgY12F+gDxNQbIIITjTPRGjC/0/9Ek1vRsak2djmaFNd80CxH0Tes1GVD6vmqGY61SZucRBDmwKibU+bw4PPtMkEHWQyR4RCp+aiz01+lS2f9/KLvWx0UuiMHG3iNC7IQc1S5pmPc/Cc6SEZAx3T72dg9YsCI1GQ9kxjxRij/lTjOSO946cFy+sf2R1jXLQG5NahyU41/7lMw+aX2unykH0UPWcQ/XjHvI146G2xsOB/NyzSmE++gNkWZfPuyRcA/W1xn3xJ/0Dkw8+p3jZwwjmO4HcCGLp6+FHISwHKYCCpIo4JtGcjQVL1AdyyrAdH8M8hPecAW6tVMUw2qsAa/a13hmdz3v9cz5RdP/LT62XoXWXAqM+rw5kBwQD1KsJeuCR524Ch/9jvU39cXYHbnuJQ1HVcTAyK3aTUdQx17X87+shMIN0sNba24mQMuGAxS9FE5bKygT24+SUNI/SN/wM= \ No newline at end of file diff --git "a/docs/cs-basics/data-structure/pictures/\345\233\276/\345\271\277\345\272\246\344\274\230\345\205\210\346\220\234\347\264\2425.png" "b/docs/cs-basics/data-structure/pictures/\345\233\276/\345\271\277\345\272\246\344\274\230\345\205\210\346\220\234\347\264\2425.png" new file mode 100644 index 0000000000000000000000000000000000000000..9654cbe246a2148dfbb627a5429548a299b18c03 Binary files /dev/null and "b/docs/cs-basics/data-structure/pictures/\345\233\276/\345\271\277\345\272\246\344\274\230\345\205\210\346\220\234\347\264\2425.png" differ diff --git "a/docs/cs-basics/data-structure/pictures/\345\233\276/\345\271\277\345\272\246\344\274\230\345\205\210\346\220\234\347\264\2426.drawio" "b/docs/cs-basics/data-structure/pictures/\345\233\276/\345\271\277\345\272\246\344\274\230\345\205\210\346\220\234\347\264\2426.drawio" new file mode 100644 index 0000000000000000000000000000000000000000..d1072768e6736af6282ffb42d71f346d112f66d3 --- /dev/null +++ "b/docs/cs-basics/data-structure/pictures/\345\233\276/\345\271\277\345\272\246\344\274\230\345\205\210\346\220\234\347\264\2426.drawio" @@ -0,0 +1 @@ +7V1bk6O4Gf01PE4XN3F5tD12UpXdqs1MqjLzSBtss6GNF+NuO78+EhYYIWFwWwIN0dbUNggQoHM+HenwgTVr8Xb+WxYcdr+nYZRoph6eNeurZpqGoTvwDyq5XEt8Xb8WbLM4xDvdCr7H/41wYbnbKQ6jI7FjnqZJHh/IwnW630frnCgLsiz9IHfbpAl51kOwjaiC7+sgoUv/HYf57lrqme6t/O9RvN2VZzYc/7rlLSh3xndy3AVh+lErspaatcjSNL8uvZ0XUYIar2yX63Grlq3VhWXRPu9zgH6ax8Fb+u1yOv4z3oI//5F++/IF1/IeJCd8w5rpJLC++Su65PyC28H564Suc75J9/mXY4HSDO5ggsP5thEubdFfvawDXsxrWYgboarRhFcHQYQr849dnEffD8EabfmAPIJlu/wtgWsGXAyOhyuym/gchegi4iRZpEmaFRVZm03krNew/Jhn6X+i2pbQ9V8h38qTv0dZHp1bm8+oQIFsjtK3KM8ucBd8gOVgHDGRXRuvf9RogYt2NUaUZQEm4raq+YYVXMBwPQCdyYCu2cT7cIZiAK7t031ENiu87+zyA67o5crP+srXM7F2KdfOcf6jrAEuF8e8ALx2OwitlMdcrysKqUhrtD289vSUraM7N417kzzItlF+Zz+LjWUNK8DAqizLoiTI43fyclkA4jP8kcbwRiqqOJb/4vvANT0XmMDyDJI4pv6i67bpGqbt2o7hk9VfmwDXWA/n5kkM5wU4VDUVO60X26IuoTzJtf2okxQ8rJrr89S0RPQq5hR7FQeQvYpnjNyr2CKgs6YIHTAa0PkjQwdEQGdPEbqmlo8OnSMCOmOK0DWjbvRhmPvkMIzj4KicH3UNjpwxB0fA815Mrxq3mOTgyDOYWx8eHHnGi2tUwx+XHBx5NnPrQIMjTx7CgJ6EaQnJYQhjN4ZIrt8I5b6kAGZHRYKB958Evpx6lfOrPlOvapJXzfhqR92Z5nEkmd2TZGBUkjVkpbKpHiVZsyLPGpZk5emfZ1nFrJ+1LR0sqxGrj5nAkWV9jQF7VO1r9EC+/VmWgY6KRLOM5Rs+25f15Nh4PZn1S3CsObdpdkC95dLp6BJFc8yUhWPy9WKjauV0GMbwKZe+5nuav9KWQPPggqstV9p8ofkzinxwEpuTjCNnvpiR9WkyLgqSeLuHq2tIkAiWz9GUOF4HyQxveIvDMGmbk2fpaR+iGXjBPmQF4MdmJi97xCNxMXSXnmSXz7nqBDP1di49Nck22m3JMH6/eRvXouMh2PeyTXSWbVJzXu5aYFXZ9XRUMXFhUlKHA1VcqxHCgGaKzeiKxDGl3QUVz5QWn1sxhcUUfWymtJuu4pliKqbcYUrDExy9T2F5vEMxpcXFV0xhMWX0PoVl7g7FlJa0G8UUBlPc0fuUHm7wcRcc0GIevCaNuS2r0Y5wulROBVCzrSGLgniPWr84Zp0mSXA4xkVl1z12cRL+FlzSU16eplyj5hXFOr42Q6Oe/oVB5G2YT/+ctRe9bvjA6NsNGHs+/WvaY/ySsHrYrSWM8DbzOEi+Res82G/7IEojFmbp4V+lO4AKDmhyHGXLd9iCx3JKSIdjnh7wxiTalMe+pnmevuGVDLdWVWnRVGAO/8F7XCCjDcC7WcB147YO/6Hds3yR7iHyQVzgGAXH/CM6dtOoDyPuhM9dB2RYHtCGqM2VCEV2a3AjQgpbbZMUztcO9qTRngfugsCqpbu2gcXqe8WBxXIWVwquDrjOJCyjocfKLlTK2aGcng0kU06WpaeUU7hymt2p0cPygDbsDK5E+KW74u5HicP2vSzPTGF1FytZZLNHoqKSzSZqhtGccfZMFRaHY4/8QaWbAsLblUw3aQNJzTjJIJFHNy2WTaRmnF1wSSKdFm3uKOnslk5dNum0WL6Pkk7h0ml1vz8wLA9oB8lSfTERJBJJp2CfaIpYyaKbrFwspZuPPuMcXTYFmz5KNu+Fj0SySTtIqismg0Qi2RRsE00RK1lkU6UG8XjAObZs2izPR8mmeNmULDXIpt0jXXXFRJDII5u2YItoilhJIpu2ygviMNv0xs4LslVe0CiyaUuWF2TT5pEyackgkUg2WRaRer7ZBZcsyqlSgzhMOMdXTpUZNI5ySpYZZNP+kcqoJYNEHuUEgl2iKWIliWwClRbEIy2o78d3xeEo2PNRunkvfuTRTUAbSCqjlgwSiXSTZROpGWcXXLJIp8oM4uHVjq6cKjNoHOWULDMIqMygriCRSDlVZtDDWMkimyoziIdRO7ZsOoI9HyWb98JHHtl0aANJGbVkkMgjm45gl2iKWEkim47KDOJh1PpjP+B0VGrQKLrpSJYa5KjUoK4gkUg3VWrQZ+CSRTpVahAHo3Z85VSpQeMop2SpQQ5tIKkZJxkk8iinK9gmmiJWksimq1KDOBi1o8umK9jzUbJ5L3zkkU2XNpDUK5xkkEgkm+qDQQ9jJYtsSp8WNIYsui45m2R9up31c58CcVJ5P/d18YkI/dxPu5bv/vCH+gEDSNre9Ak4upN3hoVDGTlDR96FhHQ05B/I/ZliIHabM4PC4Qk2Z1QgtgWi74wbiN4D3s4EA9HrzssZFg7l0YwUiEb5qZbRoH8gr2eKkdhtvAwLh0rPGSsSfXPkSHzAuJliJHbn3AwLh0O1PvmLypCku3Sb7oPkt7RoI9T0f0Z5fsFWWXDKUxKYpiMJWyS7/MD1FSs/0QoMBbz69Vzf+PVCtHIUbqPWNsZFeRnbbbfZ9kG6LEqCPH4nT8BqZHzoHyjEa36b33jNzmj4aMf0lK0jfNQNKqoir/m+XrOi6x1SFRWYV/fzBA1ceWnAMLS5cKLt275PcsI3eHECNF5Gaf7CuGhOeBPjBHeoDb2Jte6/gM+hTX/sgq5LNOC+ArwDcIMj4M3fCxwecJ9+NC0N4Bw7+raf2+Qs/q7DSfypikTTgE7sk4YGosS/7ZfLOYv/5znREH/XHZgT9KxMGk5wpEHbd8N4zwt4dQ1URaJpQL8tIw0NRHUNbZ9g5T0v4NU1eEN3DfSnrqThBEcatL2pyrlr8HlZBlRFomkA5KWBqK6h7aMfnLuGz3Oi0TX4A1sGvsRuoiQzyKZl4HO0DBh1iQZcYt+QY9y3JcPy1gJew0SqItE0mJpV2Gd8IGbqQGkBr2GiP/QwUbmJD2sB4KgFdF2CATd0RqLb0tPmSw1OI5dA81xtPtOWK22+0PwZxY48Ouck3GSuPH5Sy3h4GyTxdg9X1xF6qA8L0JPZeB0kM7zhLQ7D4vEx65kxycomxfAtPZOVb5UZgOUzeMOi0/LL922JtHxRWfmQeWyoVgikpavNPM2bK6hQiI4OlcmACgbTSoOj7VtU+RoUYX+FFmZOsQlCONM8E8EJ/z/3MZzegg5Kq7YNaHNd8xwLHQeh92xU5MOiJSqZz7WZW5zE0OYOVbenLeHJF9pshk4yWyJGoUtz0XKdYLjm61F+cZSNLgpdEdBmoHZDAFULa7hdIr0JHusVzQBP5N96GbRzcc3oXuEpvqKj+JP5mjIiGZXt8hOQ96jsWsagXGa9HVlCZVRLFTEWZrVEG5GTxc3rVgtgDItbj3w9NIAqx1S3od3yVjpfn7L3ouUMqh0/MRakXqRbrSz43wMTP+4DOmA01cP99IAOgO66hA/opH/J8ul3Xx/tQx06Fgd97xVeQX9M/i9TZwW9D42DgabKeExgvW/pJGUbwC3rqnN0/jql17xia7MpuslakbNFf63yYHg11+Ov5VzZ9Su/EY9DTyYGPPCK5yT7Z+A0RXL8/lnwy5eqf74bDBJFp8Gww1RfSoTJEGjB1SxFSncbGsMW3P2ehhHa438= \ No newline at end of file diff --git "a/docs/cs-basics/data-structure/pictures/\345\233\276/\345\271\277\345\272\246\344\274\230\345\205\210\346\220\234\347\264\2426.png" "b/docs/cs-basics/data-structure/pictures/\345\233\276/\345\271\277\345\272\246\344\274\230\345\205\210\346\220\234\347\264\2426.png" new file mode 100644 index 0000000000000000000000000000000000000000..584bcfb8db7ee3352c34e993a2e8c4278e143865 Binary files /dev/null and "b/docs/cs-basics/data-structure/pictures/\345\233\276/\345\271\277\345\272\246\344\274\230\345\205\210\346\220\234\347\264\2426.png" differ diff --git "a/docs/cs-basics/data-structure/pictures/\345\233\276/\345\271\277\345\272\246\344\274\230\345\205\210\346\220\234\347\264\242\345\233\276\347\244\272.drawio" "b/docs/cs-basics/data-structure/pictures/\345\233\276/\345\271\277\345\272\246\344\274\230\345\205\210\346\220\234\347\264\242\345\233\276\347\244\272.drawio" new file mode 100644 index 0000000000000000000000000000000000000000..4e40d1522e7916f4a804f0ec47e0c551a9dc5304 --- /dev/null +++ "b/docs/cs-basics/data-structure/pictures/\345\233\276/\345\271\277\345\272\246\344\274\230\345\205\210\346\220\234\347\264\242\345\233\276\347\244\272.drawio" @@ -0,0 +1 @@ +3Vrfc9o4EP5r/FiP9dPyI1C4PrQznWbuLu2bwAp4zljUVgL0rz8JS8YWJqEJhDQ8gLRarWR9n1baNQEaLTd/lXy1+CJTkQcwSjcB+hhACEBE9Y+RbGtJEkW1YF5mqVXaC26yX8IKndp9loqqo6ikzFW26gpnsijETHVkvCzluqt2J/PuqCs+FweCmxnPD6X/Zqla1FIG4738k8jmCzcyoEndsuRO2T5JteCpXLdEaBygUSmlqkvLzUjkZvHcutT9Jkdam4mVolCndPjnVrHB3+vP6MvP9bf1YvTrB5p8sFYeeH5vHziANNf2hlMzZbW160B/3pt5Du9koT5UO5QGWgGS1WbfqEtz8xs5G3oyUye0i9BYhHp2GkRdGa4XmRI3Kz4zLWvNIy1bqGWua0AXebWqkb3LNiI1k8jyfCRzWe4Mobs7QWczLa9UKf8TrZY0Tqaab27wB1EqsTm6fKABRbNZyKVQ5Var2A6QkLqLJTLBFtd1ixZWtGgxwsm4JeK8sbzHShcsXL8BHeyBzl/iIh2YPaBrhSxEd1n1c5fbW12JXOV7u/Jx06ltXW2TqVtnQZd3fUJia/tOpuL61PMS6cFO89Zez13elzPxyENbb6J4ORfqET3Uj2ULK9KDlZOVIucqe+hOtw9AO8JXmekHaahCEA6ThMSQxURXGOgSB0ZhFGEYA4hjTEHSNV8vgbXY3s7+IACEhLbMII+eKMToYA5ulHoBD0bZEbFZr+dzE13CrcD36FYI7roVCq7sVvAloEPvETocedAlV4aOXAI6/B6h8w/zq0NHLwEdeI/Q+bvu6vew+IX3sDPejlyA9NTtiF7zdoQZCiFrLi4QdC8uFLBu8zOvRzENY9Dcf+KkOwgGfa2vdDtib4cx5ETGHNmTr8MY5N2RSOLt5VNJgcEThi4MfPJC4F3w5SKsU4KvJsxrYr5Wr0cCvTOSDJ9IMnJVknnnShw9k2S+IYpel2QugHg5yxpmfW+1PMGyFrFOSSeckWWnpgbwVQ8/zwPF+Lksw08YOsIyDTvfttRWRqF6ZMJ+fEo7WUZdqC2el8J9acmXOsoTCXw9N4n+CAL7kZPv3U4+i8kT/vbSbhK+FY69PRd51YP4/TCsLwvqMcyEwtmM55/5VORfZZWpTBa6aSqVkkuNvlMY5NncNCjpReXVgq+MseVmbt7AhVNeZbOQl3Ugzks1KOa70aIQxCyOccIQ00FXjA0CQ0PxRsE4u5RXCxPd74x7Eb4gAO/ieJN+6ET+5tNE/u5FGezLBUwmSH/OkwsAiIaMdUDGFDSiFl8RoCEkh5yFaC8/e2YA9OVSr0kACDBkKGKQERjrb+oTAMcoYSABNGY00lxBfxghnKuwZEDsMDdESA8N0MWyQ+B4UrZa8SI4JbkX9SX3gjENdPiajIJxHAxxMIDBOAkGIBgOgjEx32wSjCfBcBQkg8iW2Ag0JdyUYFNq5+nr6R1JGmqIlEfDDq72uGzTxYq45fFMQyrKHoIvszTNj6UjS3lfpDs2Rj41z0AfSLsnBut5GdObXIS/Tx9d3b/7r4+c/T8o0Ph/ \ No newline at end of file diff --git "a/docs/cs-basics/data-structure/pictures/\345\233\276/\345\271\277\345\272\246\344\274\230\345\205\210\346\220\234\347\264\242\345\233\276\347\244\272.png" "b/docs/cs-basics/data-structure/pictures/\345\233\276/\345\271\277\345\272\246\344\274\230\345\205\210\346\220\234\347\264\242\345\233\276\347\244\272.png" new file mode 100644 index 0000000000000000000000000000000000000000..f5a3f8bc5911761de78ea43644c8c13b672900a0 Binary files /dev/null and "b/docs/cs-basics/data-structure/pictures/\345\233\276/\345\271\277\345\272\246\344\274\230\345\205\210\346\220\234\347\264\242\345\233\276\347\244\272.png" differ diff --git "a/docs/cs-basics/data-structure/pictures/\345\233\276/\346\227\240\345\220\221\345\233\276\347\232\204\351\202\273\346\216\245\347\237\251\351\230\265\345\255\230\345\202\250.drawio" "b/docs/cs-basics/data-structure/pictures/\345\233\276/\346\227\240\345\220\221\345\233\276\347\232\204\351\202\273\346\216\245\347\237\251\351\230\265\345\255\230\345\202\250.drawio" new file mode 100644 index 0000000000000000000000000000000000000000..055cf29683baa54a25dcff8972d41489a48c4fb6 --- /dev/null +++ "b/docs/cs-basics/data-structure/pictures/\345\233\276/\346\227\240\345\220\221\345\233\276\347\232\204\351\202\273\346\216\245\347\237\251\351\230\265\345\255\230\345\202\250.drawio" @@ -0,0 +1 @@ +7V1bj5s4FP41fmwE5mYeQyYzu9qtVLUr9fJGwElQScgSMpP0169tMAHsTGgmXHZkdaRi4+v5vnN8fIxngDHbHJ9Sf7f+mIQ4BlALj8B4ABDqumaT/2jOKc9xNS3PWKVRWBQ6Z3yJfuEikxc7RCHe1wpmSRJn0a6eGSTbLQ6yWp6fpslLvdgyieu97vwVFjK+BH4s5n6Nwmyd5yLonPP/wNFqzXvWbTd/s/F54WIm+7UfJi+VLGMOjFmaJFn+tDnOcEyFx+WS13u88LYcWIq3WZsKn/+co3D/6S8UfPR/Tb8+hU/LHx+sYh7PfnwoZgzmFvDmYDoHcxN4j2Cqg7kNXA24MzCHALEHaMekU2+ZkL6p8OMkZbXtfw90Ph6AxnLpuoZRzbJX9P+nKFsfFrRNNAcuAnMXIAe4pBdEO6XdWQAh4ELeC5lT3lHeAB/FA3+/SKl4s1OBGe+Q1vmwZ4yakgK6uTuKo6GduR5w5/RhagL0cJdJfnp4vDp6Ml8iAc9h830Erl2MhQifisIBU6MiE4c+uA7DYga8KSv8yB4cWgBxmpVygBk+0h7X2SYmGTp53Gdp8hPPiplsky2m84viuJHlx9FqS5IB4RYm+d4zTrOIaMW0eLGJwpB2472sowx/2fkB7fOF2ACSlyaHbYgp7TSSiv0Fjj0/+Lli+c3OiWgKrdfNIj0rJW147B+TIqMpGQY+XlQAvVQrYo9wssFZeiJFigqmU1QpTJHNRfZyVuxSW9cVpeZ5fmFLVmXTZ3UjD4XG/Yb26ToU1Y+Tug2noSXjtFah3qLkXZMdZHzEiF7CsEIaf7/LLesyOlJUa4RhOoDtIBDYRd6EjrvQtPugB22thp6jieghCXioO/AMCXhNIW/DKV2FzoSvCJbMPD19K9SEJb5XEw/HWurEU8co+8ZbIM+szsQqUudKNMHr5OPCobDWNaRPxp4c0gC/Ou1iycj8dIWzV0uackQriFkSxHheimM/i57rQ5bBWPTwKYmYoS4IYxnuxHUtByLHIgkkKP9E00zo6MQumLbu1pvPxVC0WF1Um53o9sSyhWZKjhoT0xCGwDvJJSh0wthYiustBDW7sC7wPVoXy2pYF2dw62J1AZ7xHsEz9Tp4yBocPLsL8Mz3CF5zXR8BeJI90dvB098jeE3NG4FTht7olN3VVYKtXSVnSFfJRGgCUenFQO7Zloth4/WNvhLSJ45eekNO3VdCmvRtb76SOybe2K15A4fkjdH0mqyGXrelhgmvNNQ1/Lz/2/dyxa6Mb73a7MrK/V+5GazUemUHeFeqWa2pZg9KtaaPZ99ItWZDjts31fR7Ua2k1/fKmytUq7CrTbDhrlRrHziwBl0NG8aoPLL4bapZVxrqnGqwA6vWkmhD2jTzf0K0ZkizaYpaL5/NPVTTOHZNNOtypCmMns+7nTxrv/O3rTZSmvTE5rwXezXcXebl3QnZtYE1lGIcJyfg7Rs0G8EaM2xX3KCZvR55WJfjWt1T5cImXFGFWh84OqpcjqJ1TxWoqHKZKvboqHI5Ztc9VS4E1RVVqCuijY4qsghhX1S5EMJXVKFUMUdHFVlQUFFleKrYDaqgwanCd1xqARo7VSTniz1TRRYAVG7tCKmiD04VWQBPbZbHRxXZ90I9U0X2NaIKwY2QKsbgVJFFaxvi7+dYAIzy9GnQg873cyhgSyK99PaCA6Yau72gsVsf5Z0HB7hTgEx2IQQCzyuuiEwt9uoRTF36ykXAs9hljQd2e8SihadopPajcr0B3uubK9uu4epKlh5o9GpQYIsv4fdrf0cfM38RN8yJTIx7wk4uOSq4gAjSj7YUD1YnSOLY3+0j1lheYh3F4d/+KTlkvBueEmBg6WJsOhA+ngt9jJbSj+fsAOHF8k4LQ+NsxoESIDUpkN0h2WJp4EiSmWaRH3/GQeZvV21AFUEL02T3D7fINGNHzRFO589EiHuuRKKOZsmueBnjJa+7SLIs2RSJtJBX2SiTleWRHyK9GT2RtshsZiStn9PkhxZPs1myJeD7EYMS+/vsBe+vM6kNKV5ToVcXHSkXzO6oIJpv8YrZW7jALmz6Zy4kRHDLmLkca2Jh8fYe0HeG1/W7LTKnrkO4xMMyXcF1Da5jHZbh0BPPr5SytUVPco+zZ/TEIyWFXlv0dInb0zN84jGPMp2t4bOHho/vdZTPOhKf9XRxUe3ZhTXEkxal2A29GZELa4inHWoZvQrXWFxYQwwCKWVri97gLqwhBn4Uem3RG96FNcRgjYKvNXzDu7CyL52VCzu4Cyv7DVE9u7AqMHRVb8bkwoqRIGWHr8I1GhdWDAQpZWuL3uAuLG9Z6d4N6A3vwppisEYpX2v4Bndh+VduyoUdlwsrU+yefVhTjAwpzW4ozoh8WFOFgm6Aayw+rKkiQbejN7wPKwaClKlsi94IfFgxWqOUrzV8w/uwLX55pPJhB/BhJczo24dV3whdVZwR+bD8Mo6C63fgGosPa6lQ0O3oDe7DWmIkSOleW/SG92EtFa15A3zd+bAkef5jYfklzfOfXDPm/wE= \ No newline at end of file diff --git "a/docs/cs-basics/data-structure/pictures/\345\233\276/\346\227\240\345\220\221\345\233\276\347\232\204\351\202\273\346\216\245\347\237\251\351\230\265\345\255\230\345\202\250.png" "b/docs/cs-basics/data-structure/pictures/\345\233\276/\346\227\240\345\220\221\345\233\276\347\232\204\351\202\273\346\216\245\347\237\251\351\230\265\345\255\230\345\202\250.png" new file mode 100644 index 0000000000000000000000000000000000000000..bcc5f5e00fd9ddfe7663d0192a6cce71dfd4e15d Binary files /dev/null and "b/docs/cs-basics/data-structure/pictures/\345\233\276/\346\227\240\345\220\221\345\233\276\347\232\204\351\202\273\346\216\245\347\237\251\351\230\265\345\255\230\345\202\250.png" differ diff --git "a/docs/cs-basics/data-structure/pictures/\345\233\276/\346\227\240\345\220\221\345\233\276\347\232\204\351\202\273\346\216\245\350\241\250\345\255\230\345\202\250.drawio" "b/docs/cs-basics/data-structure/pictures/\345\233\276/\346\227\240\345\220\221\345\233\276\347\232\204\351\202\273\346\216\245\350\241\250\345\255\230\345\202\250.drawio" new file mode 100644 index 0000000000000000000000000000000000000000..053d6656491066fcb1a42f8a920e0e7c685bf4e9 --- /dev/null +++ "b/docs/cs-basics/data-structure/pictures/\345\233\276/\346\227\240\345\220\221\345\233\276\347\232\204\351\202\273\346\216\245\350\241\250\345\255\230\345\202\250.drawio" @@ -0,0 +1 @@ +7V1tj5u4Gv01/thReIePeWF6d7UrVbcrtd1vBJyEWyakhMwk99evzVswhkBmbPBGVisNNmDA5zw++PBAgLZ8OX9OvMPuzziAEVBnwRloK6CqijIz0R9cc8lrnNksr9gmYVBsdK34Gv4fFpXlZqcwgEdiwzSOozQ8kJV+vN9DPyXqvCSJ38jNNnFEHvXgbSFV8dX3Irr2Wxiku7zWVq1r/X9guN2VR1ZMJ1/z4pUbF1dy3HlB/Far0lygLZM4TvOll/MSRrjzyn7J93vuWFudWAL36ZAdYPIr+hb//VP77fTr+/lb8OX31flT0cqrF52KCwaqGaH2Fmt8yuml6Afz1wmf52IT79NPxwylOdpANQ7n60q0tMV/Z2Ub6GTWZWXRCVWLKjo7BCIqLN52YQq/Hjwfr3lDPEJ1u/QlQiUFLXrHQ47sJjzDAJ9EGEXLOIqTrCFts4Gm76P6Y5rEP2FtTWA5a8S38uCvMEnhubP7lAoUxGYYv8A0uaBNih10vcCxILJpFeW3Gi2Kql2NEWWdVxBxW7V8xQotFHDdAZ3aAl2zi/fBHMcAKu3jPSS7FV13cvmOCrOy8KNeWJ2J0qUsncP0e9kCWs72eTKK0nUnXCj3yc8LBlSkNfoenXt8Snx446KL0ST1ki1Mb2yntWNZw8powaqsS2DkpeErebptABZH+BKH6EIqqliK8+Q4hqXalqEamq2QxDFmT7OZjrZSdUs3FYdsPu+CosV6ODcOYjrmk2FSzVTs1J50jTqF8iB5/1EHyXhYddf7qanxGFXURxxVLI0cVSx94lFF5wGd9ojQGQ4Jna1ODJ3BAzr9EaFravnk0Jk8oFMeEbpm1E1+G2Z98DaM4c1ROT/quzkyp7w5Mk37SbWr+xaVvDmy9Na1994cWabyZCnV7Y9F3hxZVuvakW6ObHEIYwwkTEdIjkMYo3mLpDZCefAd86ynIc7AOx8Evpx6lfOrIVOvapJXzfhqe92Y5jEkmT6QZMaUJNObN3PaO0nWbMgyxyVZ6Zt9nGUVs37U1vSwrEasIWYCQ5YNNQb0SbWvMQLZ1jtZ1hwTqYZ4s6zNN/zoWDaQY9ONZNq/gmN6zwA0WC6bk6TmkMibY6ooHBNvFJtUKx+HYS0+pWsCxwLzGXANgKTcUbKFBVi4wLWAMwe2DlwH2CpYLPDGtgvmBnBtMFfA3MYbz1fAyRbQNnOboiya+qYkT8n5csHj+uS6qPKicLtHRR/RCqL6BZ5Ih74XzYsVL2EQRF0z+SQ+7QM8b884iw2E4mGbymhmbjZmWU5JtxorVa2Fls3bcGZTc6XbzAzC16sjklcdD95+kNkyazNban7NTeOsqssPR1UTJyYkdRhQxVYagW/TVNFHZUq3d8qfKR3uuGRKG1O0qZnSbdXyZ4oqmXKDKQ0ncfIxpc0ZHospHd6/ZEobUyYfU9os4bGY0pGsI5nSwhRz8jFlgId83HkHvJh666gxI27rtCOaZJVTAdxtPmKRF+5x72f7+HEUeYdjmDWWb7ELo+AP7xKf0vIwZYmaV2Tl4twUQD0zDDxob1qfGZq+DdcbNjAqs8ZTpqEPDXVeOJYEGYIjus409KL/Qj/19tshkNKQBUl8+Ks0FXDFAc+pYeK+oi48lnNCOh7T+FCsjOCm3Hcdp2n8UhSSoreqRrOuMhboP7rGJfbnDHQ1S1RWrmX0H2+epMt4j6D3wgxI6B3TN3js59EQStyIn5vGybg8oH1UnSkRsqRY70qEGPXaJsoMsx0aSuGeBe6cwKplyXaB1Tb48gOrzZB8lnD1wHUmYZkMvbakRCmdPdLpqIZgytnm6Unl5K6can9G9bg8oB07hSkR/tVDcf8TyHHH3jbTTGJ1EytRZHNAfqOUTWrGqTZmnFWu2WTj5YC0Q6mbHMLbEkw3aQdJzjjJIBFHN7U2m0jOOPvgEkQ6tQFJclI6KelURJNOrc33kdLJXTq1/tcOxuUB7SBpciwmgkQg6eTsEz0iVqLoZlsyltTNex9yTq+bnF0fqZu34kcg3aQtJDkWk0EikG5y9okeEStRdFMmBzF4wjm5bOptpo+UTf6yKVhukE7bRzM5FBNBIo5s6pw9okfEShDZ1GViEJPp5tSZQbrMDJpEN3XBMoN02j6SNi0ZJALpZptHJJ9w9sElinTK5CAWM87JlVPmBk2jnILlBum0gSRzaskgEUc5Dc420SNiJYhsGjIxiEVi0NCv9vLDkbPpI3XzVvyIo5sG7SDJnFoySATSzTabSM44++ASRTplbhALs3Z66ZS5QdNIp2C5QYbMDeoLEoGkU+YG3Y2VKLopc4MYOLWTy6bJ2fSRsnkrfMSRTZN2kKRTSwaJOLJpcraJHhErQWTTlLlBTJzaqZ9wmjI3aBLdNAXLDTJlblBfkAikmzI36D1wiSKdMjeIiVM7uXTK5KBppFOw5CBTJgf1BYk40mlx9okeEStBdNOSyUEsnNqpZdPibPpI2bwVPuLIpkU7SPItTjJIBJJN+dGgu7ESRTaFTwyaQhZtg5xNtn2+ve2XQjniJBN/buviByL0fb8KW779wx7qOxwgYUfTD8DRn70zLhzSyBk78i4kpJMhf0fyzyMGYr85MyocNmdzRgZiVyA65rSBaN/h7TxgINr9iTnjwiE9mokCUSk/1jIZ9Hck9jxiJPYbL+PCIfNzpopER504Eu8wbh4xEvuTbsaFw6R6n/xZZUTSXbyN9170R5z1Ee76/8E0vRRWmXdKYxKYpiOJeiS5fC/aywo/cAGFQlFcnesrVxeil2GwhZ19XFSlZWx3XWbXN+kSGHlp+EoeoK2Ti12/4BCv+W0W6bdZTR/tGJ8SHxZ7XaGiGnKaX1drNpRfIdVQhnl1PR+ggSUuDVoMbSac6Pq87wc54TisOKE1vhtkjMwJ+8E4wRxqZdbEWnOejPehTf8ODt0Wb8AdCXgP4ApDwKnfDBwdcId+NC0M4AwH+q6f3GQs/qbDSPyphnjTgE7sE4YGvMRf5XND2BT/93OiKf6zkTlBz8qE4QRDGnR9OYz1vIDV0EA1xJsG9OsywtCA19DQ9RFW1vMCVkODPfbQQH/sShhOMKRB16uqjIcGm5VlQDXEmwaGuDTgNTR0ffWD8dDwfk40h4aRLQNHYDdRkBlk0zKwGVoGLW3xBlxg35Bh3Hclw7LWAla3iVRDvGnwaFbhkPsDPlMHSgtY3SY6Y98mSjfxbi2wGWoB3RZnwJWSYPVHu64BFi6Yu8DVweIZzBXgmgBR2lkCVwV2tqCaUfmGENrbr1LjzV+nOH8Yrm02joN/j/taZW7x389hujutcZu2C9Ao5DrAtgDqVtfGB8WHM4BtA2xn5EdBl5YfKG+gPItVuX6dEJwtD4j3+XTMqDdHGyj64UyfDT6YswCOixfmOrBXTC7yy+q59+zR9aIeWFjZ9T4DdCOWnwvqfNwVFphrtT6x8ALSbozFEizm2cbP2YKFN7BpYziF55QMRvJNhuI5esujdS8Kt3tU9CFOuUAV+Ll56HvRvFjxEgZB9nC/7Yk+OWZE3hpGC8//uc3qmwe/Dg+KXpRrb1ossn+AyZsWpjYjwq0q1x7kV69+Ea9a3P+mBSomMWbENVpR3+z+jAOIt/gH \ No newline at end of file diff --git "a/docs/cs-basics/data-structure/pictures/\345\233\276/\346\227\240\345\220\221\345\233\276\347\232\204\351\202\273\346\216\245\350\241\250\345\255\230\345\202\250.png" "b/docs/cs-basics/data-structure/pictures/\345\233\276/\346\227\240\345\220\221\345\233\276\347\232\204\351\202\273\346\216\245\350\241\250\345\255\230\345\202\250.png" new file mode 100644 index 0000000000000000000000000000000000000000..b16c73d6a7728bf822eb8de046a4b01bae92ef8a Binary files /dev/null and "b/docs/cs-basics/data-structure/pictures/\345\233\276/\346\227\240\345\220\221\345\233\276\347\232\204\351\202\273\346\216\245\350\241\250\345\255\230\345\202\250.png" differ diff --git "a/docs/cs-basics/data-structure/pictures/\345\233\276/\346\234\211\345\220\221\345\233\276\347\232\204\351\202\273\346\216\245\347\237\251\351\230\265\345\255\230\345\202\250.drawio" "b/docs/cs-basics/data-structure/pictures/\345\233\276/\346\234\211\345\220\221\345\233\276\347\232\204\351\202\273\346\216\245\347\237\251\351\230\265\345\255\230\345\202\250.drawio" new file mode 100644 index 0000000000000000000000000000000000000000..d090804e9127436d10c65aaf9759b0506dcc0ae9 --- /dev/null +++ "b/docs/cs-basics/data-structure/pictures/\345\233\276/\346\234\211\345\220\221\345\233\276\347\232\204\351\202\273\346\216\245\347\237\251\351\230\265\345\255\230\345\202\250.drawio" @@ -0,0 +1 @@ +7V1dj5s4FP01fuwqfMNjkiHdSl2palfa9tFJnIQtg7PEmUn2169tTPgwJEwaYjJrdaTBFxuMz7n24eLbAdb0+fAxhdvNH3iJYmCOlgdgPQHTNIyRS38xyzGzBKNRZlin0VJUKgzfon+RMObV9tES7SoVCcYxibZV4wInCVqQig2mKX6tVlvhuHrXLVwjyfBtAWPZ+le0JJvM6pteYf8dRetNfmfDDbIzzzCvLJ5kt4FL/FoyWSGwpinGJDt6PkxRzAYvH5es3azl7KljKUpIlwbHWeiv/dDdup+i/WQWf4g/ff0grrIjx/yB0ZI+vyjilGzwGicwDgvrJMX7ZInYVUe0VNT5jPGWGg1q/BsRchRgwj3B1LQhz7E4iw4R+V46/sEu9ZsjSk8HcWVeOOaFhKTH7+VCqRUrFs14KW+3wgkRHTF5OYrjKY5xyp/WWq2Qu1hQ+46k+CcqnTHG7B89k40QG5bWgc9HEe/TBToz2pYgMEzXiJxDxTzxgzoWws+IPhJtmKIYkuil2hEoGL4+1StIQA8ED97ACVMlJwoe/CidaebEQ2Lrq4RWdPIFxntxJ2C6Me3uZF5B3P1nz6YlPsIfdnyIx7SC6WwPxUl6tGa/R/k1aJfmuVHmUBzTOZtx5XUTEfRtC/lwvtJlo8oEuNtmE/kqOjBGdYd16QXz0eh08xeUEnQ4D6wMhGhgOWLaFuuWny9Ir6VVQJg2pQUgt90cOvusVyY4ua0bXjM1Gw88NTsd3ddV6b5OH+5rvkf3de2a+/qK3dftAzrrPULnjKrQBa5i6Ly7zrz/O1HsP8LM6/fhvvZ7dN+6cFLuvoE0or2opPOvKi0a6ZH81DAf4Q0nl+n30smP+rraGU2l065xPj6lcu2to3n1WvwQLHB+kQWi6Rcc0S4WUi9wq2uFU1sEsn6JVjUunbrxC/Qy+1jWjfe4rNdVufJ4iNEey1pGL8WwZ6bdFiadEB01IVoixdmQ18mW3U4yVzpW4wOFhlSBr+Ip5roy+MIE42id0OKCQomofcKAjhYwHosTz9FyGbcxrTp53oApXs2p/ZHMFLuBKWZvTLEVMqVlMtBMYcywhsaU9gBb/0xpicNppjBmeENjSns8r3+mtIT9NFOYhDSGxhRPIVNaIkyaKfxlY2hMaQ8yaqYoVbQ1phgj5VQJ9PLzEFRpin7flSn5hbWkHTpTTNVMMRQyRb8md2dK016G+zKlPWyqQ2+DYoqtmikNQdrQBcEU+AEIHRCMQGDwgwmYhCD0QDAGvg3CAPgmmExYZT8EY4efmoFxwE4FPpg4rNX4iR3TA1p57A8U1/qHohvg7EiCtGFKMK27In1+f+Igd5IX3+au+Ri/2KcvvO8GUPwVr+vexZt8xBunKTyWKmzZx7ld6cq1b3xebSdernNmHev71vn6rn+2Pj3IenzTD4dmU6C4Rv/dBm7ZIYFzTvYSbZsmjR2FL+cXpxelG4wSNvvwNgscx3C7i/jFshqbKF5+hke8J/lt8pK814CVRd8a+LqEyF818tVd+Gi+utHyVP8yZDXMWqPGWau3aaspjtsCJH1QEsH4K1oQmKy7YCpjtkzx9s/cT5mBuw9KwxfEvEjeEiAWJMInRHYyRqu87RwTgp9FIRXDdbooHypnQn/o4E3ZZOfQp5nSslGU6Q+rnpIpTij2MOJIIrgjr2h3mUhdOHHGgWSmXGKC3RsR5DCtvJPoV5jA09NgwQRMh20V84SwDRUTKLkF8H2h1bIJ6IKs7A8sOVIqbxTSYDVOwh1fCfrDTg5dakfriF3HF//esMvXa43d27EzOsb3+gNPju/pSbMreB3D+P2B1xRy0zpVmU49ti6m95Wtlhxg0zNy1WmGI1steSOiBusSWAORrZYc8dGrZ0fslMtWOcijseuInXrZKgdmNHhdwVMuW5u2tGnZqlq2Nn0tvK9s1UGgS04zHNmaX1iD9QawBiJbbR30uRo71bLVlmM+GruO2CmXrbYOzFwPnmrZajdljGrZqlq2Njn1fXWrLUeBtFdXvWZAulUO+2iwLoE1FN2qt+NcjZ1y3SoHfTR2HbFTr1t1ZOZ68FTr1vy/T9K6dVi6tYEX99WtjhwG0l5d9Zrh6FZHjvtosC6BNRDd6uiwz9XYqdatjhz10fHWjtgp162OjsxcD55y3dqQhRU6LCN4HILQBpMZGBs8cXjEcodDE/j8QKR3s1EC7E9A5VlrRRK5tVoFAdskWc8r/xiRzX4u8otZEnEAfI8nI/vspmOelez7IDBLSeTZjUQWuejF0ylDPa2QrSXL3bAbs9yzFOgg5FnNNvCfbvKQX55mF3tPn5eOwMTjzzsDgVtKx6ZD4YGxVRoTjx0Enkjinox55Rk/8FgFX3a6YWRhx3CO4glc/Fxze/3mhd8ZtiiXkiAn/B+4Te62W02C9IKGlwOzwfuuSN2mxeLvi2W5r8VfabPC/wA= \ No newline at end of file diff --git "a/docs/cs-basics/data-structure/pictures/\345\233\276/\346\234\211\345\220\221\345\233\276\347\232\204\351\202\273\346\216\245\347\237\251\351\230\265\345\255\230\345\202\250.png" "b/docs/cs-basics/data-structure/pictures/\345\233\276/\346\234\211\345\220\221\345\233\276\347\232\204\351\202\273\346\216\245\347\237\251\351\230\265\345\255\230\345\202\250.png" new file mode 100644 index 0000000000000000000000000000000000000000..17316f064ff3ec38295010799510b3b42a9acfeb Binary files /dev/null and "b/docs/cs-basics/data-structure/pictures/\345\233\276/\346\234\211\345\220\221\345\233\276\347\232\204\351\202\273\346\216\245\347\237\251\351\230\265\345\255\230\345\202\250.png" differ diff --git "a/docs/cs-basics/data-structure/pictures/\345\233\276/\346\234\211\345\220\221\345\233\276\347\232\204\351\202\273\346\216\245\350\241\250\345\255\230\345\202\250.drawio" "b/docs/cs-basics/data-structure/pictures/\345\233\276/\346\234\211\345\220\221\345\233\276\347\232\204\351\202\273\346\216\245\350\241\250\345\255\230\345\202\250.drawio" new file mode 100644 index 0000000000000000000000000000000000000000..a2ee5e47f227a9ee299f22c7d18431ef0f74eadd --- /dev/null +++ "b/docs/cs-basics/data-structure/pictures/\345\233\276/\346\234\211\345\220\221\345\233\276\347\232\204\351\202\273\346\216\245\350\241\250\345\255\230\345\202\250.drawio" @@ -0,0 +1 @@ +7V1tk6o2FP41zLQf2pH35COu2s70dXo709tPHVRUWhSLuKv99c0JCRAC6rog2b3M7NxLDiEkeZ5zTnISiWY+bU/fJf5+81O8DCLNGC1PmjnRDEPXRw75DyTnTIJHo0ywTsIly1QIPoX/BUzIsx3DZXAQMqZxHKXhXhQu4t0uWKSCzE+S+EXMtooj8a17fx1Igk8LP5Klf4TLdJNJkeEW8u+DcL3hb9YdnN3Z+jwza8lh4y/jl5LInGrmUxLHaXa1PT0FEXQe75fsuVnD3bxiSbBLb3ngrz9++Pyz8f3frn2I/w3RNP70y/obVsohPfMGB0vSfpaMk3QTr+OdH00L6TiJj7tlAKWOSKrI82Mc74lQJ8K/gzQ9MzD9YxoT0SbdRuxucArTz6XrP6Gob22WmpxYyTRx5oldmpw/lxOlpyBZPEZT/LlVvEtZRQxIZ+2FRjZ2I++T+Jgsggt9ZzI6+sk6SC/1sZGjTdQkiLcBqSB5MAkiPw2fxYr4jK/rPF8BKblgqL4CYaNPhAtU/yzdqUdYAaRQn0CxSj770ZG9STOciFR3PBfwc/49gsmg/fXNgXaYRzIY9v5U3CRXa/h/xMsgVZpzocyIKCL2FJB/2YRp8Gnv0+58ISZdxNU/7DMjuwpPwI/xKoyipziKE1qQuVoFzmJB5Ic0if8JSneWLp6PClifgyQNTpeBlYFgD5iYmVTmU1zuLF5KFpqJNiXjzGWtQ2dd1LFdvGtXqe4xm7oyZtO+URmdPpXR7kIZjY+ojA6qKCPqWRmdLqAzPyJ0tiVCh5yeoXMfakff+fATvQc7irpQRusjKmN1UNO7MmKpRzsZwVyeFDSMX/rTOt14D3MJPiB+1IhUjWnezdj0ahL1yzGXPr1cFZt7vV4fmNpvxJQ9+msckioWo1vTEa2yXTG3Wb3YUxVm5NV4A1mMLhyo/hEdaHU023tUQG+O6CzD56LbM9Fh7+9uQnRUh2iJFBfHSLkse50kFipW4QOBJhWBF/FklqsMPhP5UbjekeSCQBkQ+RiADhd+5LEb23C5jJqYJprCFpjiVoZa2JCZYtUwxeiMKVaPTGmY2g5MqWEKcvtmSnNgqnumNMSvBqZQpugiU3q3Kc1xsO6Z0jDAGJhSwxS3d5vi9siUhgWqgSl1TOndpjSH8xppsci6GCiRrOf+V6Ru5I+8f1R79bXGogIjyqeVvw2jc/b4Nt7FB9rlQpaCcg2Ms6vbU2zSZJDSvRd5ineBTTuBSCZwDRWzoZk26blrefU8L0f5rmKMopisp/M75J8pGQHYY3jeg3+mFiShTA/ePiVW34ZBi42fIAlPoDxJsSKFUV2l5Wfo8PKzvoMMkCLzNoxNU74BHQvX34Xp5jjnb0VQHYwgiSHpQpLWCfHKZlWEBiCQYaNcJ9o3vGL8FWIbJuX884S2IGOc3IKCGyTl0ay6BQRpag2vGoYrPOVJDzoYTTrvzF8nszt6g/Yt7fmxm/ctFIQdoT2UMBkQkM8za3BxeRK7OZOgoWMvL2qWJ13+GCqYXcEiM8RQb2qKQazTZNkcg5RaX9qTuUkWxJlZBhEzzCAUTTPcZMYZbpbMM9yhBhrk3ESDcEQlkT8PorG/+GdN79VVigfFaAOsXPYkoE3mUWM6l2LYMfXNzP8tBiK/lduGwiHY4BLynI5Z6vJzgzxzEYVJKRkg7iuKm6V7xGfk8nWpAlXTRZO5/SoLRavK8knmt97BE9IRyiGsEboRK0bMB1yMNUJfwjjsacjSiHVBhjammQnzPVsjRCZU9BBk9iYaphckj4cUHRvUx8DftgxvYDGmgeWxgmE+dLAgLyApv7ewiGzfs8y0OCbPtO56julDd8y0EgL3ksQ/lzLsIbR9KJVciZC7lf0ffOI7uzG/a17Jb1zMTy6yGrcadufvFAa6FTIfNv4eLlN/TqlbImGdBTgQ+DhbKFkIefxwB6aEPkMGD5G/P4S0sCzHJoyWP/rn+Jjy1/BUNcK+9AO0qo2wOwsUzFft2BhkVuYjNRF2u87EWF3ZGN6GW3Ai7UxDP/otWKT+bn0LZDIkyyTe/87VEARUO4Jk+hyAkjCzIDuPlFovuBkFK/7sPE7TeMsSCeuuvFDaVfaY/MHUCCyTPYE5kg3BFZ4mf5A9IYORHYHeDymQgX9IX4JDeivqF1RA5sIVrC3UFdRGt1DTnw/4BdQx6bRVRDfsb4hnD3ZtIPsGOBpUszc46ha3Bs3rUvPOIqS9IV+3WPUFKaKpmCLWrQgNivgARcROz4pYt8LzBSliw3SnNzjqllEGRXyAIuqW1bMmNq+LZCHc+5fLZqVQWVZWw6rXR9Z0VzFNx4Om96Tp2OhX081XBIY+oiZitTTRfEX8p584XSVETNOsbrrWUxxPH42uB/Lqtsp2FsczOw7uvHuLeplHd+uzeT2q9FgeyFEl+bfVytvXrsAyroJVtxuoO7DqAkGzAa4rcJ1EWHpD7xVxo8F1ctTwyFbMc3YcBBo85yX1UchzytEn+XeGX6wpbvjBZ2+2ty5eNGB1EStV3OYrYj+D28xnnHp1xnnj1w06w9HqOJAz+M1L+qOO37TkCNIw4xSVRB2/adWFiYYZ5zW4FHGd1iu2DA2uszlY27vr7HgD0OA6L+mPQq5TjiCZgy0WlEQh1/kRNgs9GCtV/OYrNhYNfrMxUtu72+w46DO4zUvqo5DblCNIgykWlUQdt2l3HCb6iFgp4jbtYW9QG9NN1PcKp10X9Bn8Zud+01Zsb5Ath4+G6aaoJAr5zWFv0D1wqeI6h71BLcw4+/ecw96gfjynYnuDbDmANMxiRCVRyHMOe4NejZUqbnPYG9SC28R9u02n45jP4DYvqY86btORA0jDhFNUEnXcplMXJRomnNfgUsRzOrJivflLgI8/zObqB/qa9ja/8ZAaZIshW/6JvLyI7AuD0iE1UkG4utWoWlDHp9048tZLZWhQo4jtcKIhFPRGTmC3LU7olXX0qhHomhO2upxokQZNi2ltm4bqaUd3m4ZqQV3TwFGXBl2ZhqZ9SW2bhrs5UTUN+MGckM+Lfd+caB1qfVTF2sXf2vehLf+GRy6ra8DlD3orA3iLet8U5mrZF6C2holSQV3TQP6yuDI06MoXNK0YtuwL7udExRegBw8T+SFKKnKiRRo0zeNbNg24LdMgFdQ1DWo2fU1tOD/Cm2pTSxvP4KgIOGZiBCdNTA0N0Qvxa32LPNJdfJAvP8Cl+o0+dgpOdhoFnD2BNeTSoysQvNSjZ1ggpMGny+o/5cdqMckPx0oEIjd8MTA7zUb6YmB2YAae0sMwLA1NWmkkPZ3mSu1Je0kPjF3a3pmGndLhHaQrXM0zS33iwgV22ZEfY49mntELFzIgWaHVOLyj9sSY4uWFzdAtli4tnLBTYto58kMXdc1BchQvP97jjUd+aOxcl5KyFie6mNP/AQ== \ No newline at end of file diff --git "a/docs/cs-basics/data-structure/pictures/\345\233\276/\346\234\211\345\220\221\345\233\276\347\232\204\351\202\273\346\216\245\350\241\250\345\255\230\345\202\250.png" "b/docs/cs-basics/data-structure/pictures/\345\233\276/\346\234\211\345\220\221\345\233\276\347\232\204\351\202\273\346\216\245\350\241\250\345\255\230\345\202\250.png" new file mode 100644 index 0000000000000000000000000000000000000000..8cec6213f0226be9598c1fef97ef6af022314787 Binary files /dev/null and "b/docs/cs-basics/data-structure/pictures/\345\233\276/\346\234\211\345\220\221\345\233\276\347\232\204\351\202\273\346\216\245\350\241\250\345\255\230\345\202\250.png" differ diff --git "a/docs/cs-basics/data-structure/pictures/\345\233\276/\346\267\261\345\272\246\344\274\230\345\205\210\346\220\234\347\264\2421.drawio" "b/docs/cs-basics/data-structure/pictures/\345\233\276/\346\267\261\345\272\246\344\274\230\345\205\210\346\220\234\347\264\2421.drawio" new file mode 100644 index 0000000000000000000000000000000000000000..bceea69589d052d806e4e8974b265755c99f81fc --- /dev/null +++ "b/docs/cs-basics/data-structure/pictures/\345\233\276/\346\267\261\345\272\246\344\274\230\345\205\210\346\220\234\347\264\2421.drawio" @@ -0,0 +1 @@ +7V1dk5s2FP01PGYHJPH1aHuddDLtTKdpp80ja7BNyxoHs7ve/voKDNhIwmBbQqpXmUwCAgToHN2je3WRDTh73n/Jgu36lzSMEgOY4d6AjwYAlmU6+L+i5P1Q4pvmoWCVxWF10rHgW/xvVBXWp73EYbRrnZinaZLH23bhIt1sokXeKguyLH1rn7ZMk/Zdt8Eqogq+LYKELv0zDvP1odQD7rH8pyheres7W45/OPIc1CdXb7JbB2H6dlIE5wacZWmaH7ae97MoKRqvbpfDdZ87jjYPlkWbfMgFf3zavoXL39Cj4z99/eP15cfy649PVS2vQfJSvbABnATXN30qHjl/r9rB+fFSPOd0mW7yT7sSpQk+Adjb/fEg3loV/5t1HfhhnurCqhGaGgF+Ogwi3pm+reM8+rYNFsWRN8wjXLbOnxO8Z+HNYLc9ILuM91FYPEScJLM0SbOyIrhcRs5igct3eZb+E50cCV3/CfOtvvlrlOXRvrP5rAYUzOYofY7y7B2fUl9gVzhWRG5wfTuhRVW0PmFEXRZURFw1NR+xwhsVXBdABxjQkU28CSdFH8B7m3QTtZsVv3f2/hfeMeud76c7j/vW3nu9t4/zv+oa8HZ5zYNd7R0vKnbqaw7PFYVUTyPaHj97+pItojMvXVmTPMhWUX7mPMjG8gQrm4FVXZZFSZDHr+3HZQFY3eHXNMYv0lAFAf/B920XeK4NbOiZbps5pvlgmgi4FkAuciwftm9waISqztMOTd7GdB5s56Qegp/wAcHjQ1jEXQ5NSN2lpGLTYtezE4owLECwYek2IF0mh4NhQYgwLL5kw4JEQAfvETpotqGDrmTobBHQoXuEjpRz6dA5IqCz7hE6stdJH4m5N47EOI6Pahepb3zkyBwfQdd7AF4zcAH10KQRQPbhi8dHrvXgWs0IyPXawzAI2IdHGiB56pDGHkiajm45DmkAOUxyie48lBbQ6qlIMPD+jcDXHljtZg3xwBpfr3H8Tq464+1xJBkaSDJbKsnIAR2pGUNJRlVkjUuy+na3s6xh1veTIz0sOyHWkJgCR5YNjQ8gqfpHWCAErmUZ6qlINMtY4cNbbdlAjsmzZPB/wTHSvyEN0GC5JCsiTaJojgFVOKaeFZOqlffDMEascu4YE9PwPGP+2ZjODH9CcQ77r3mbaG1nuCLiqR9cFQVJvNrg3QXmRYTLp4U3HC+CZFIdeI7DMOlyx7P0ZRMWzndJuiIKUE2aAV4THW4bDruG54RW9STXKa1I7eHmXlvdAckwfj1GNQ5Fu22wGRQwMVkBk5OYy9ngV1N2uB1V3HowJZnDgSk2IIYfkGYKYhggcUzpjn+KZ0pHhFszhcGUxsRLY0p3uFU8U4BmyhmmWG2mSLcprOjuWEzpiN9rpjCYAqTbFFZIdyymdOTcaKawmCLbpngO1djtl06zfJ2u0k2Q/Jym26r1/47y/L0a7AcvedrGhvQEOtJ7OAZK+gMgJhuWGx1P2yPg9K90PB3YU5HoKSBXXRqU9VTPZXHkBOyYebyRE67JixPIbo8/zJE54d0ZJ7hD7ZFQe/6DfR3YHmkA6KpEw+1ruM/D7fOD25cOd22VVISbo5EHHVMfvIUf8RJ+siLRNLDUpYEo4QdiBoOU8F/NCUL4m2mSsTgB1OUERxogbxTTAHmZBqoi0TSA6tJAlGlAYuSCNA3Xc4L0CcY2DUhdTnCkgTNOuADyChdQFYmmga0uDUSZBnuccMH1nCBMAxo5XOArHElUw38kwwWQX7iAUZVouBWOGHLs9S4YRQkQr0EiVZFoGtxbkHDI6ECM40AqwfWcIJVg7EGijiReqAQIclMCRlXCE/wZGf5zz5jODexCzm3Dc43pRKcvAseiJ3vHTV+saUci9bnAaO4aE8/wphopgBgfvo+MFGAgZRdpwP5jsTFxS6TwvxNj6hRJwp5p4EHFATtvVpwzxSVOge/EKQ85Bn4tf1ZcNUXGBBQbGGUPFYdwD8VH574xscoKcc3AmPrlVajoy8Xd8X3tk4RkXI4rf/w4PMHE6OUJZCW6CyQKa3kLAo+zHyVQH06b5Z/mSL3W0CVfetINONaXmW187Ot1FTq9VQnXVVa2uYa2qtblBy1dlXBoWenhHxZa4qubG6Clqhq/1w74qHq3DrbFZh48JQSuLFnb4UeulaxAeIGFLYg3hT6W1yzSJAm2u7is7HDGOk7Cn4P39CWvb1PvUbLY9oio5TLCIPKWzCXNnIUXPS35CKtLToMPXEiDdJH5LWk24KvlGkb8mnkcJL9FizzYrIYgSiMWZun29zrwUBRsC4JG2fwVt+CuHtHQA6a89J+Lg0m0rK99SvM8fa52sqq1mkrLprKn+C9+x1nhMtv4bWZ43zru47/F6Vk+SzcY+SAucYyCXf4W7fppNIQRZ7rPWUs0Lg9oj4meAruFCOVakcGRCClutWVSWv01HutGGx64CwKrK5GiJ5lZHFgMpwlXqOE6D9e+DYs09AZ4Mlo5SdQcSCQLSVfOAV6LVk4Bvbt/odFxeUC7OHSu4Yc1xf0rcoxre1kfoWqszmKlimwOWPNPyyaJGpWAP3DRTXEwDliFT8umgN7tKiabdPxIO5ztTqKObEJWlEg7nH1wKaKckI7taOXsVU7qS0XZyglZUR+tnMKVE/ZPGo3LAzp+RH/B8lFN8aGTKKScgqNE94iVKrI5YO5ay2bvDKd02RQc8tGyea77KCSbdPxIm+K+NWKk2V7BUaJ7xEoV2dSJQTymN2XLJmKFfLRsipdNxRKDEB08olfU+aimuGu5PVm2FwkOEd0jVorIJtJZQRy8TSg7KwjprCApsokUywpCdPBIB2n7Vh+SZntZISI9vdkHlyrKqRODODic8pVTJwbJUU7FEoMQHT/S+bR9aznKsr224CjRPWKliGzaOiuIQ1bQ0B+xFwej4JCPls1z3Ucd2bTp+JHOp213EoVkkxUl0g5nH1yqKKdODOIRqpWunDoxSI5yKpYYZOvEoL5OopBy6sSgi7FSRTZ1YhCPOK1s2XR0YpAc2VQsMcih40c6Ttv3wxqybK8jOEp0j1gpIpuOTgziEKdFsqc3HZ0YJEU2HcUSgxydGNTXSRSSTZ0YdA1cqiinTgziEKeVr5w6MUiOciqWGOTQ8SPtcPb9VpMs2+sKjhLdI1aKyKarE4M4xGmly6YrOOSjZfNc91FHNl06fqQ/4Oz72UtptlcvF3QxVqrIpvJZQTJk0Xba3iRr2XbmD4mJw0mn/ZzXxRt6aH9mDwvr+ssf/lBfEABS1preAEd/7s64cOhAztg9770NqTTkL0j9uceO2B+cGRUOT3BwRnfEro7oO3I7ondBbOcOO6LXn5YzLhw6RiOpI1r1Qi3SoL8grecee2J/4GVcOHR6jqye6APJPfGCwM099sT+nJtR4bDMCwI0Cs4/3R4zO/PjzrKCm5bpanM4xs8Cm4p9b2WZdNBGTx8R3WIMuPBulqb5ybEvuAXXv6RhVJzxHw== \ No newline at end of file diff --git "a/docs/cs-basics/data-structure/pictures/\345\233\276/\346\267\261\345\272\246\344\274\230\345\205\210\346\220\234\347\264\2421.png" "b/docs/cs-basics/data-structure/pictures/\345\233\276/\346\267\261\345\272\246\344\274\230\345\205\210\346\220\234\347\264\2421.png" new file mode 100644 index 0000000000000000000000000000000000000000..cd01ef52d9b6bcc38e4aae25b7129df3ae2f0c49 Binary files /dev/null and "b/docs/cs-basics/data-structure/pictures/\345\233\276/\346\267\261\345\272\246\344\274\230\345\205\210\346\220\234\347\264\2421.png" differ diff --git "a/docs/cs-basics/data-structure/pictures/\345\233\276/\346\267\261\345\272\246\344\274\230\345\205\210\346\220\234\347\264\2422.drawio" "b/docs/cs-basics/data-structure/pictures/\345\233\276/\346\267\261\345\272\246\344\274\230\345\205\210\346\220\234\347\264\2422.drawio" new file mode 100644 index 0000000000000000000000000000000000000000..a25027440d05bca518d52f3ef7548151c35d0169 --- /dev/null +++ "b/docs/cs-basics/data-structure/pictures/\345\233\276/\346\267\261\345\272\246\344\274\230\345\205\210\346\220\234\347\264\2422.drawio" @@ -0,0 +1 @@ +7V1bk6q4Gv01PO4u7oRHtXXOw0zV1OypM3s/0hKVObQ4SHfr/PoTLlEgQVATkrazq6u2BAiQtb6sZPEZNWv2evglDXab35IQxpqphwfNetZM0zB0F/2XlxzLEl/Xy4J1GoXVQeeC79G/sCrEh71FIdw3DsySJM6iXbNwmWy3cJk1yoI0TT6ah62SuHnVXbCGRMH3ZRCTpX9FYbYpS4Hpncv/A6P1Bl/ZcP1yz2uAD66eZL8JwuSjVmTNNWuWJklWfno9zGCcNx5ul/K8Rcfe042lcJsNOWGdfvzy34/vURD8cBffnM36j+jwrarlPYjfqgfWTDdG9U1f8lvOjlU7uP+85fc5XSXb7Nu+QGmCDjCd3eG8E31a5//ruA50My+4sGqEU40mujsEItqYfmyiDH7fBct8zwfiESrbZK8x2jLQx2C/K5FdRQcY5jcRxfEsiZO0qMharaC7XKLyfZYm/4O1PaHnvyC+4Yu/wzSDh87mM06gIDbD5BVm6REdUp1geRWOFZE9zNCPGi2qok2NEbgsqIi4PtV8xgp9qOC6AjqTAl27ibfhJI8BtLVNtrDZrOi50+MPtKHjjZ/1jedDY+uItw5R9gPXgD4X5zw51db5pHwDn1PeFwyJSGu1Pbr35C1dwgsPXfUmWZCuYXbhOIuOZQ0rh4IVLkthHGTRe/N2aQBWV/g9idCDnKji2v6T7zueCTzHdCxgNIjj+vqTrtuIQKbt2a7hN6svm6CqsR7O7YuY7pPjEtWc2Gk92RZxC/giZfsRFyl4eGqu26lp8ehVzEfsVVy31asAwb2KzQM66xGhc8wmdMAVDJ3DAzr7EaFra7lw6Fwe0BmPCF076oQPw7w7h2EMB0d4ftQ3OHJFDo4cHzyZ4DRuMZuDIw9Q9149OPKNJ884DX+85uAIGNS9Iw2OgDyEcQYSpiMkxyGM3R4iua1QHkoKx+qpiDPw/p3A46kXnl8NmXqdJnmnGV/trAvTPIYksweSzBFKsvZgzruRZERF+rgkw3J4P8tOzPpZ29PDshqxhpgJDFk21BiwhWpfqwfyjVtZ5vZUxJtlNN/w3r5sIMfE9WTWp+BYe27T7oAGy2W7onaXyJtjpiwck68XE6qVj8Mwik85d7WJrgGgzRfadKb5E4JzaO6aNYnWnPBWRKzPjquiII7WW7S5RLyAqHyaz4SjZRBPqh2vURjGXVPxNHnbhvnEuyBd7gBUb8tMVq6I34TD0G1ybo1fb9V5ZerdFLprbm10u5Fh9H62NMqi/S7YDnJLdJpbUjNcLjpfp7LyckRx48akpA4Dqnh2a/xhkkyxKT0QP6Z0m5/8mdJhbyumUJhy6uOFMaXba+XPFFMx5QJTmlYgEN6n0KzdsZjSYd4rplCY4gnvU2ie7lhM6ci2UUyhMUV4nzLABN5vgl3+MQte4taUltZoezRLwlOBvNmWiEVBtM1bvzhnmcRxsNtHRWXlEZsoDn8Njslbhi+Dt4h5RbFd3ZuhES/9wgCCFfWln7sE8GXFBkbfacE48KWfzQtGzI8hMKLHzKIg/gMus2C7HoIoiViYJrs/sSmQF+zyOTFM5++oBfd4SkiGY5bsqp0xXOFzX5IsS16rjbRqrVOlRVM5U/SHnnGW+2sOepoZ2jbO2+gvPzzNZskWIR9EBY4w2GcfcN9PoyGMuBA+F42PcXlA+qA2UyIUSa3BmQgJarVVXBheG9STwi0L3DmBVcty7QKL1vfyA4tmKC4UXD1wHZqwCEOPllSolLNHOYHjSKacNEtPKSd35TT7M6LH5QFp2BlMifCpu+L+N4jj9r00z0xhdRErWWRzQH6iks02aobRnnEOzBDmh+OAtEGlmxzC25NMN0kDSc04m0Eij27idC8147wKLkmk0xqQ5Kakk5BOXTbptGi+j5JO7tJp9X9tYFwekA6SpfriRpBIJJ2cfaJHxEoW3aTlYindvPYdp3DZ5Gz6KNm8FD4SySbpIKmuuBkkEskmZ5voEbGSRTZVahCLF5yiZRNXrGRzZNmULDXIJt0jXXXFjSCRRzZtzhbRI2IliWzaKi+IwWwTiM4LslVekBDZtCXLC7JJ80iZtM0gkUg2aRaRer/ZB5csyqlSgxhMOMUrp8oMEqOckmUG2aR/pDJqm0Eij3LipVjUhHM4VpLIpkMaO0o2e2WTSAsauuYuPxw5ez5KNy/Fjzy66ZAGksqobQaJRLpJs4nUjLMPLlmkU2UGsfBqhSunygwSo5ySZQY5KjOoL0gkUk6VGXQ1VrLIpsoMYmHUipZNfH0lmyPLpmSZQS5pICmjthkk8simy9klekSsJJFNV2UGsTBqfdEvOF2VGiREN13JUoNclRrUFyQS6aZKDboFLlmkU6UGMTBqxSunSg0So5ySpQa5pIGkZpzNIJFHOfFi9mrGORwrSWTTU6lBDIxa4bLpcfZ8lGxeCh95ZNMjDSRddcWNIJFINtWCQVdjJYtsSp8WJEIWPdBaEIgii7Rf+eSIk8r7uayLd0Tobb/oir/7wx7qKwwgaXvTO+DoT94ZFw5l5IwdeccmpMKQvyL35xEDsd+cGRUOPP9QgTh2IPqu2EAEV3g7DxiIoD8vZ1w4lEcjKBANvFSLMOivyOt5xEjsN17GhUOl54iKRN8UHIlXGDePGIn9OTfjwuESrd/8RWVE0k2yTrZB/GtStFHe9H/DLDtWVlnwliVNYNqOJGqR9Pijqq/Y+JlvoFCoNp8P9Z3Px0Yrw3ANO9u4KspwbHc9ZteCdCmMgyx6b16A1sjVqb/nIX7224De8tvwWB9XsU/e0iWszjpDRVbUXsm7XVH5hERFBean57mDBp68NKAY2kw40bW2752c8E1WnHBby9T6I3MCPBgnmENt6G2sPf/JuQ1t8jdwyLp4A+4rwHsANxgCTvxe4OiA4w5FRsAZdvRdP7fJWvwtVuLfrog3DcjEPmlowEv8u365nLX438yJtvi339Dy5gQ5K5OGEwxp0LVuGOOuAbDqGoiKeNOA/LaMNDTg1TV0LcHKuGu4nROtrgGM3TWQS11JwwmGNOj6pirrroGVZUBUxJsGjrw04NU1dC36wbprYGUZgJEtA19iN1GSGWTbMgAMLQNKXbwBl9g3ZBj3XcmwjLXAZzVMJCriTYNHswqHjA/4TB3aWnA7J1pa4I89TFRu4rVa4JvstIBSF2fADZ2S6DYH2nSuoWnk3NGAp00n2nyhTWeaPyHYkcFD1oS7mStfvamlvLwN4mi9RZtLmL/URwX5m9loGcSTasdrFIbF62PaO+MmK9sUqx7pnqx8C4/C8Dv4U0vV3vri79s20vJ5ZeUbWHjaUC1ykOaeNgEamCqoTB8IR8qkIIViaaGhwfY5qFxtomsAaHNfmxjatNyF/qwczamd7y3RBDMyJuv7HG2KKkKTX3QeQh7YeRFqFTAvappqE692EU8Dpjb18fkgvxF/pk0m+UUm85xQ6GA0SkSf6/yqai7P8ouz7PymyrueOLUHQuWoqmcOHCwzPSRjoI3pdYmBeDm4kSg4IHkObsNJmhZpNlUrdwKjmZZe/Dvt+at6NOOKUTvZgD0pNLjsTtFu44MC9GbRdkB/XdxFe0Aq3hcG12UILlkXd3AHJNt9HXA9nRm4ZF0CIveKr1ZKuHIEA6m8AIKo7yUbOumIfelMZk5fT6/Yf7EvGRl42vct3Ri3AdqzPHWj7j9vSZnmba1WFvpXL3LX+f86PhndTXl+Wc6UXZ95gYIq0mRiwIDvXX4ZtXUB0TmDW9UW6P118VZbvJKCApcKrssQXLIu7uAO+KImM3Dz/q925GJRCMBnAN1gBjpZl4CIpjhrn2j83Eeku4bWl/ARtbSWYbBduvnBh9Z38uNSzFzsgUbmBGlfkdnMn3yIzAfJ/pXaxx09G6RX9XC/qTkqkpKs1GYYA3yq2uBqGQf7fbSkja/qoyhixPV5xlFGe8DrtNp+8CiKMMDaNXEfQ5FrfpHfKfoib+ror/UZvapDm2mSG0Rn+NBjbn5LQpgf8X8= \ No newline at end of file diff --git "a/docs/cs-basics/data-structure/pictures/\345\233\276/\346\267\261\345\272\246\344\274\230\345\205\210\346\220\234\347\264\2422.png" "b/docs/cs-basics/data-structure/pictures/\345\233\276/\346\267\261\345\272\246\344\274\230\345\205\210\346\220\234\347\264\2422.png" new file mode 100644 index 0000000000000000000000000000000000000000..e32780220e19e95cb11a16e40e64a813400c58b8 Binary files /dev/null and "b/docs/cs-basics/data-structure/pictures/\345\233\276/\346\267\261\345\272\246\344\274\230\345\205\210\346\220\234\347\264\2422.png" differ diff --git "a/docs/cs-basics/data-structure/pictures/\345\233\276/\346\267\261\345\272\246\344\274\230\345\205\210\346\220\234\347\264\2423.drawio" "b/docs/cs-basics/data-structure/pictures/\345\233\276/\346\267\261\345\272\246\344\274\230\345\205\210\346\220\234\347\264\2423.drawio" new file mode 100644 index 0000000000000000000000000000000000000000..0c727214ab0c1a0597d91a62c6d7b81b198a40fc --- /dev/null +++ "b/docs/cs-basics/data-structure/pictures/\345\233\276/\346\267\261\345\272\246\344\274\230\345\205\210\346\220\234\347\264\2423.drawio" @@ -0,0 +1 @@ +7V3bcqO4Fv0aHieFuPNoO86Zh56qqe5TNd1PpwgQmxli3Jgk9nz9ERdhQOJiW0KKW12paiNAgNbaWtJiW1b01evxP6m33/6RBGGsaGpwVPRHRdMAUC34X15yKktcVS0LNmkUVAedC75F/4ZVITrsLQrCQ+vALEniLNq3C/1ktwv9rFXmpWny0T7sJYnbV917mxAr+OZ7MV76VxRk27LU0exz+e9htNmiKwPLLfe8eujg6kkOWy9IPhpF+lrRV2mSZOWn1+MqjPPGQ+1SnvfUs7e+sTTcZVNO+Af8/P37++vXr//798tz8v3gffwd/VbV8u7Fb9UDK5oVw/qWz/ktZ6eqHayfb/l9Ll+SXfbboUBpAQ/QzP3xvBN+2uT/q6gOeDPPqLBqhLpGDd4dBBFuLD+2URZ+23t+vucD8giWbbPXGG4B+NE77EtkX6JjGOQ3EcXxKomTtKhIf3kJLd+H5YcsTf4JG3sC232GfEMXfw/TLDz2Nh+oQYFsDpPXMEtP8JDqBB0RtyKyjbY/GrSoirYNRqAyryLipq75jBX8UMF1AXQaAbpuE++CRR4DcGuX7MJ2s8LnTk/f4YaKNn40Nx6Pra0T2jpG2XdUA/xcnPNgVlvnk/INdE55X2GARVqn7eG9J2+pHw48dNWbZF66CbOB43Qylg2sTAJWqCwNYy+L3tu3SwKwusKfSQQfpKaKabsPrmvammObmqk7oEUcy1EfVNXQbKAZtmEBt1192QRVjc1w7l7EtB5MC6umZqf+YOjYLaCLlO2HXaTgYd1c11NTZ9GraPfYq5hup1exOfcqBgvo9HuEzjDb0DkmZ+hMFtAZ9whdV8u5Q2exgA7cI3TdqOM+DLNvHIZRHByh+dHY4MjiOjjSnAfNqcctWntwZNvEvZcOjuCJDzaohz92e3DkqMS9Mw2OHHEIY04kTE9IzkMYvTtEMjuhPJUUhjVSEWPg3RuBR1MvNL+aMvWqJ3n1jK9x1sA0jyLJjIkkM7mSrDuYs64kWbci252XZMg3u51lNbN+NPaMsKxBrClmAkWWTTUGDJ4s6/ZAtRl6McvckYpYs4zkG97al03kGL+eTP8MHDO7PmW3A5psMHUnSd0ukTXHNFE4Jl4vxlUr74dhBJ9ybSkLVXEcZf2kLFeKu8A4B+euWZto7QlvRcTm7Lgq8uJos4ObPuRFCMuX+Uw48r14Ue14jYIg7puKp8nbLsgn3gXpcgegelum0XJFtDYcQNXxuTV6vdXklab2U+imuTXodyOD6P1saZRFh723m+SWqCS3pGG4DDpfdVl5Oay4dWNCUocCVSy7M/4AOFMMQg/Ejin95id7pvTY25IpBKbUfTw3pvR7reyZokmmDDClbQU63PsUkrU7F1N6zHvJFAJTbO59CsnTnYspPdk2kikkpnDvUyaYwIett88/Zt5z3JnSkhrtAGdJaCqQN5sPWeRFu7z1i3P8JI69/SEqKiuP2EZx8MU7JW8ZugzawuYVxXZ1b0DBXvoFXui8EF/6Wb4TPr/QgdHppNBMfelnsIIR8WMKjPAxs8iLv4Z+5u02UxDFEQvSZP9fZArkBft8Thym63fYggc0JcTDMUv21c44fEHnPidZlrxWG2nVWnWlRVOZS/gHn3GV+2smfJoV3AbnbfiXH55mq2QHkfeiAsfQO2Qf4WGcRlMYMRA+g8bHvDzAfVCDKhGKpFbvTIQEttpLXBheW9iThjsauDMCq5Hl2gcWqe9lBxbJUHyScI3AdWzDwg09UlKhVM4R5bQdUzDlJFl6UjmZK6c2nhE9Lw9www5QJcKn7orH3yDO2/eSPDOJ1SBWosjmhPxEKZtd1IDanXFOzBBmh+OEtEGpmwzC2xZMN3EDSc4420Eijm7qJJtIzjjH4BJEOvUJSW5SOruouaIpp06yfaRyMldOffxbA/PyADeQdNkVt4JEIOVkbBPdI1aiyCYpFUvK5qWvOLnLJmPPR8rmUPgIJJu4gSS74naQCCSbjF2ie8RKFNmUmUE03m/ylk2DZPlI2WQvm4JlBhm4eaTKrrgVJOLIpsHYIrpHrASRTUOmBVGYbTq804IMmRbERTYNwdKCDNw8kiZtO0gEkk2SRSRfb47BJYpyyswgChNO/sopE4P4KKdgiUEG7h/JhNp2kIijnCZjl+gesRJENk2ZFUQhK2jqirvsYGRs+UjZHAofcWTTxP0jmU/bDhKBZJPkEskJ5xhcoiinTAyiYdVyV06ZGMRHOQVLDDJlYtBYkAiknDIx6GKsRJFNmRhEw6flLZsWY8tHyuZQ+IgjmxbuH0mfth0k4simxdglukesBJFNSyYGUfBpXd6vNy2ZGMRFNi3BEoMsmRg0FiQCyaZMDLoGLlGUUyYGUfBp+SunTAzio5yCJQZZuH8kJ5ztIBFHOW3GLtE9YiWIbNq4sSNlc1Q2uz4td9m0GVs+UjaHwkcc2bRx/0h+gbMdJALJplwu6GKsRJFN4bOCuMgiaM8mSeu2k37ikyFOMu1nWBdviNDrfs4VffOHPtQXGEDC9qY3wDGeuzMvHNLImTvyTm1IuSF/QerPPQbiuDkzKxwOY3NGBmJfILoW30B0LvB27jAQnfG0nHnhkB4Np0AEaKEWbtBfkNZzj5E4brzMC4dMz+EVia7GORIvMG7uMRLHc27mhcPCWr/9c8qQpNtkk+y8+EtStFHe9H+HWXaqrDLvLUvawHQdSdgi6el7VV+x8SPfgKFQbT4emzsfT61WDoNN2NvGVVGGYrvvMfuWo0vD2Mui9/YFSI1cnfpnHuINv03v+G12x0c7JG+pH1ZnnaHCK+qu492tqHxCrKIC8/p5bqCBLS4NCIY2FU70rex7IycckxYn3M4itc7MnHDujBPUoXa7UFvug3kd2Njv3+BVsYbblXAPww1UenjjPxU4O+Au/mJaGMApdvN9v7RJW/o1WtLfrYg1DfC0PmFowEr6+360nLb0X82JrvTrM3MCn5MJwwmKNOhbM4xy1+DQ6hqwiljTAP+ujDA0YNU19C2/SrlruJ4Tna7BmbtrwNe5EoYTFGnQ9zVV2l0DLcMAq4g1DUxxacCqa+hb8YN210DLMHBmNgxcgb1EMWaQXcPAoWcYEKpiDbfAniHFqO9LhKWsBC6tQSJWEWsa3JtNOGV0wGbi0FWC6znRUQJ37kGi9BIvVAIXUFMCQlWM4QYozbz5UnftKMu1AqeQa1NxbGW5UNZPynKluAuMG1l4zNpgt7Pkq3e0hNe2XhxtdnDTD/PX+bAgfycb+V68qHa8RkFQvDgmvS1uc7JLsOqRbsnH11EAo7fvKjJdG+970TdtWwn5rPLxgUrIScuhespBWtvKwlGcpYRKc23uSGkEpGAsPSlwoH0OKktZqIrjKGtXWQBlWe6Cf3qO5tLI95ZoOis8Jo3GPlNZwoosIz8PIu8YeRHkq7MualoqC7txEVtxNGXpovOd/EbclbJY5BdZrHNCwYPhGBF+bvKrqrk8yy3OMvKbKu96YTYeCJbDqh4ZcLDM8RCNgUg1hxiI1oGbiYIT0ubCXbBI0yLBpmrlXmAUTVeLf/Wev6pHAxeM2fEGHEmeQWU3SrYFup05cK7V7NrQH6iLuWhPSML7hcE1KYKL18Uc3AlpdtTAzTvDxpFPTzr89ylAB9RAx+viENEXfNlSzLUkBol0k7oO4cNrsQCg4hbaL532zJQfQzEz2APNzAnS9zatGDUP3OPXLWD9fEvKdHHUPTeKrE3+P0Anw7spzy/LqRJPgIUO2JBjfFGuWVc9ACr+1c67W89yViQFWc4CAIKDNjBe82PvcIh80pCtOTDDBnGfZmhmGt0xdLftJw/M1LGaWA/LAG65nT0ZPJ3iF7E3yF7ovP4GIFhsv+wUGAfo+ncSJhivi3nYSfNqCFyTIrh4XczBndO8+qz+hoFJ3/Wg43VxiGjhF/3i528M4cNtLgvwjDDpb8w78QGC/f4fAKRlwqS/wYccgv3eIAC4+XV3v6s8K5LM/Q24mSZ5RJ6VHrb19o8kCPMj/g8= \ No newline at end of file diff --git "a/docs/cs-basics/data-structure/pictures/\345\233\276/\346\267\261\345\272\246\344\274\230\345\205\210\346\220\234\347\264\2423.png" "b/docs/cs-basics/data-structure/pictures/\345\233\276/\346\267\261\345\272\246\344\274\230\345\205\210\346\220\234\347\264\2423.png" new file mode 100644 index 0000000000000000000000000000000000000000..7d49ac2ed82e44e5dd81c0633c71c3957595deb3 Binary files /dev/null and "b/docs/cs-basics/data-structure/pictures/\345\233\276/\346\267\261\345\272\246\344\274\230\345\205\210\346\220\234\347\264\2423.png" differ diff --git "a/docs/cs-basics/data-structure/pictures/\345\233\276/\346\267\261\345\272\246\344\274\230\345\205\210\346\220\234\347\264\2424.drawio" "b/docs/cs-basics/data-structure/pictures/\345\233\276/\346\267\261\345\272\246\344\274\230\345\205\210\346\220\234\347\264\2424.drawio" new file mode 100644 index 0000000000000000000000000000000000000000..b115c61ee2da92a3c96b08f441ef158ec6f354be --- /dev/null +++ "b/docs/cs-basics/data-structure/pictures/\345\233\276/\346\267\261\345\272\246\344\274\230\345\205\210\346\220\234\347\264\2424.drawio" @@ -0,0 +1 @@ +7V1dj6M4Fv01PE4J82HgMUmnZqTtkVbbq92epxGVkIQZKqQJqUrtr18TMAHbCSSxsYt2q6QOBgzhnHvP9fXFMezZ6/HXLNxtfk+XUWJY5vJo2F8MywLAhOi/ouWjbAlMs2xYZ/GyOujc8C3+X1Q14sMO8TLatw7M0zTJ4127cZFut9Eib7WFWZa+tw9bpUn7qrtwHVEN3xZhQrf+N17mm7LVt7xz+29RvN7gKwMYlHteQ3xw9U32m3CZvjea7Llhz7I0zctPr8dZlBQPDz+X8rznC3vrG8uibd7nBOswh3/H+ezH13/kf/7H2y7A4vsvVS9vYXKovrBhwQT1N30pbjn/qJ4D/HEo7nO6Srf5L/sTShN0gOXujued6NO6+N/EfaCbecGN1UOoe7TQ3SEQ0cb0fRPn0bdduCj2vCMeobZN/pqgLYA+hvtdiewqPkbL4ibiJJmlSZqdOrJXqwguFqh9n2fp31Fjz9ILXhDf8MXfoiyPjhcfH6hBQWyO0tcozz7QIfgEWOFYEdnB2+8NWlRNmwYjcFtYEXFd93zGCn2o4LoBOosBHfmIt8tJYQNoa5tuo/ZjRd87+/iONky88Udz48uxtfWBt45x/h33gD6fznlyq63zScUGPqe8r2hJWRrx7NG9p4dsEV350pU3ycNsHeVXjrPZWDawchlY4bYsSsI8fmvfLgvA6gr/TGP0RWqqOHbwFASuZ/mea7m2b3pt5jjmk2k6lgcsx3MgCOz2BcqHUPXZNGjyMgA+ubDRD8FP+8mxzzdBfIvyCVIXOTGxfmD3k9MW4VesMfoVx237FdeW7FccEdDZY4TOBm3oIJAMnSsCOmeM0JFqLh06KAI6MEboSKuTHoh5DwZiHMMjPELqCo+gzPDI9v0ny6/jFgvYhAASu++Mjnzw5IE6/vH8dhDmwvbuYNDwyFeHMm5PylwwymEoY5FBEiCMuS8rbKujI8HABw8Cj4dfeIzVZ/hVD/TqUV/jrCtDPY4kc3qSzJVKMjKcs+4kGdmR6w5LMnz5x1lWM+uPxp4OljWI1SehwJFlfZMDjlT1IzwQhPeyzO3oSDTLWLnDR31ZT47J82T2p+AY7HBAveWSHCaRLlE0xyxVOKaeF5OqleNhGCNTOYfGxDR835g/G9OZEUwozqHRa94mWnvIWxGxOT6umsIkXm/R5gLxIkLt02IsHC/CZFLteI2Xy+TSYDxLD9tlMfQ+ka7IAVQzZhavvIjfhsML6ME1nuFq0opEjdvgGlxORy7jt3NOo2za78Jtr3SJyUqXNDIuV1NfdVt5Oaq5dWNKMocDU+o8NTZcj2aKw3BA4phyOfspnikX8tuaKSymWLKZcjnZKp4plmbKFaaAdlQh3aewcrtDMeVC9l4zhcUU6T6FldIdiikXCm40UxhMcWT7FB9SD7v9pdMs36TrdBsmX9N0Vz39v6I8/6iC/fCQp21syJHAhdoejomS7gSIyYblwYGnGxCGb9858IROR0eip4A8dWlw6qe6L8CRE/aFeccHOeEBXpxw3XZHzsCc8EfGCe5Q+yTUVvDk3ge2TzoAuivRcAca7utwB/zgDqTDjVNpKsLN0clbF6Y+OAu/Q9bz3Cv8VEeiaQDUpYEo4bfEBIOk8N/PCUL4nWBgTljqcoIjDRx/ENfg8nINVEeiaWCrSwNRrsERIxfUmICXa3CHdg2OupzgSAM4TLoA8koXUB2JpoGrLg1EuQZ3mHTB/ZwgXAMcOF0QKJxJVGP8SKYLIL90AaMr0XArnDHkaPWeNYwS8AoSqY5E02BsScI+0YGYgQOlBLyCRDh0kKgzibcqgcdPCeiuhBf4Myr8574xnRtoCDl3Dd8zphNdvmj5Lj3ZO2z5osmoki+Qei4wmnvGxDf8qUbK8hivvQ+MlMVACpnSs4Hi7LNN1bXBgTEBxrTchf7sAs2pU+wt0fRntEnajX2uMUUdwdN5CHnfKZqQbvjzU09TY+I1LuIZvmVMA3y+X9xIMDMmk+Iik3lBKHQwChHR5ya/qp7Ls4LTWU5xU+VdT9zGF0LtqKsvAjiYRKtcOQaiiLCbgRAMSkHWshkEGldfd6BevDZP/+o9eAmjW94hpR/gQKuoeISH8Px7FbvO2V3uSrhis+rYNbQ4OOMGLaMr4dCyCs9FQVs4wsaRz882+vcpIAe8ICe7kmDNN75hu0jC/T5esFBvYkvx4POgaxJWaN45kHZgR0fCkaXj9XNAVwdSM3qi7ieJkpgjqmGjpIdfCh2TlFJR7P15jXoRlMtdCbc+HQBfMT3ADVpGV8KhHTIA/qxRkkXK3/2Qk11JsOYei93sN+Gu+JiHLwmBN0vu9uiWscIVyC8QzmG8LfJbp3MWaZKEu3186qw8YhMny6/hR3rI8WXwFiWX7Uw1tbzZMoz8FXN5M7jwo5cVH8H1yPLEnsubkXPP/NaZ7RHrYhjR18zjMPlXtMjD7boPojRiyyzd/RtPCBUNu4KgUTZ/Q09wjyMdOozKT/Maxc4ykDp9fEnzPH2tNrLqadWdnh6VO0V/6DvOiqkMF32bGdoG5230VxyeIYeyRciH8QnHKNzn79G+m0Z9GHHFfK56omF5QEfGdGnSI0Q4LeAdnomQoqe2Sk5qsEExcLTlgbsgsC4VuHa8ZCYOLFaM/Kzh6oDr2IZFGno9wmCtnCRq0CGKuKUrZ4+QVyunAOvuXv19WB7QCWL6HZCf1hV3r5Q2rO9lLQ6isbqKlSqy2WMlZi2bJGrUi5E9l0IXB2OP1ZG1bAqwbk8x2aTzR3rA2TYSdWTTZmWJ9ICzCy5FlNOmcztaOTuVk1pBQrZy2qysj1ZO4cppd08aDcsDOn9EFyz8rK64NBKFlFNwlmiMWKkimz0q/7Rsds1wypdNwSkfLZvXzEch2aTzR9oVd63dJ833Cs4SjRErVWRTFwZxmN6ULpsOK+WjZVO8bCpWGOTQySN6pcOf1RVfWgZZlu91BKeIxoiVIrLp6KogHqNN2VVBjq4KkiKbjmJVQQ6dPNJJ2q5VIaX5XlaKSE9vdsGlinLqwiAeA07pyqkLg+Qop2KFQQ6dP9L1tF1rbMvyva7gLNEYsVJENl1dFcShKgjKztO6glM+WjavmY86sunS+SNdT9s2EoVkk5Ul0gPOLrhUUU5dGMQhVStfOXVhkBzlVKwwyNWFQV1GopBy6sKgm7FSRTZ1YRCHPK102YSCUz5aNq+ZjzqyCen8kc7Tdv3gmSzfCwVnicaIlSKyCXVhEI88rezpTagLg6TIJlSsMAjqwqAuI1FINnVh0D1wqaKcujCIR55WunLqwiA5yqlYYRCk80d6wNn1G5qyfK8nOEs0RqwUkU2PTuxo2eyUTSpPK1s2PcEpHy2b18xHHdn06PyRfoGz6+fIpflevVzQzVipIpvKVwXJkEWX+Dk/1rLtrJ/cEYiTLvu5rosPWGh3ZQ8La/zmD3+ob0gAKetNH4Cju3ZnWDh0Imdoy/toQyoN+RtKf8ZoiN3JmUHh8AUnZ7QhXjLEAMo1RP+G3M4IDdHvLssZFg6do5FkiAAv1CIN+hvKesZoid2Jl2Hh0OU5siwxsCRb4g2JmzFaYnfNzaBwAPOGBI2a80/ptd+nfiid5hDpNM/z8e8+y5pfAKanPWX/eaUH6XHNZNSZcwImK9UDE/x40J5F/QTgj0NaKgz+0fdGE1wX/wN8Mrqb8vyy/fP5aRnk6K7jGXSiBJh0NugTKq5CSCoyAwaA8lNg8pTbwhNftXIH0pUbQK3ckpUbKPYyPACsOTOt3HLIodjL9wDQYd3oXl4ZFEnhyo02s7SwyHrfr+hZb35Pl1FxxP8B \ No newline at end of file diff --git "a/docs/cs-basics/data-structure/pictures/\345\233\276/\346\267\261\345\272\246\344\274\230\345\205\210\346\220\234\347\264\2424.png" "b/docs/cs-basics/data-structure/pictures/\345\233\276/\346\267\261\345\272\246\344\274\230\345\205\210\346\220\234\347\264\2424.png" new file mode 100644 index 0000000000000000000000000000000000000000..f4c9d8e8b321cea51a41baf544f6062c6ef2a202 Binary files /dev/null and "b/docs/cs-basics/data-structure/pictures/\345\233\276/\346\267\261\345\272\246\344\274\230\345\205\210\346\220\234\347\264\2424.png" differ diff --git "a/docs/cs-basics/data-structure/pictures/\345\233\276/\346\267\261\345\272\246\344\274\230\345\205\210\346\220\234\347\264\2425.drawio" "b/docs/cs-basics/data-structure/pictures/\345\233\276/\346\267\261\345\272\246\344\274\230\345\205\210\346\220\234\347\264\2425.drawio" new file mode 100644 index 0000000000000000000000000000000000000000..a5a6d89bd82a139554e4b8389d9559cee4fe29d6 --- /dev/null +++ "b/docs/cs-basics/data-structure/pictures/\345\233\276/\346\267\261\345\272\246\344\274\230\345\205\210\346\220\234\347\264\2425.drawio" @@ -0,0 +1 @@ +7V3dkqq4Gn0aLqeLvwS4VLc9czEzNTV7V83MJS2onEOLg9htn6c/QQhCEg0qIWk7u7pqS4CArJVvJSsf0XBmr4ef83C7/i2L4tSwzehgON8M27YsE6L/ypKPqiQwzapglSdRfdCp4Hvyv7guxIftkyjedQ4ssiwtkm23cJFtNvGi6JSFeZ69dw9bZmn3qttwFVMF3xdhSpf+lUTFuir1be9U/kucrNb4yhYMqj2vIT64/ia7dRhl760iZ244szzLiurT62EWp+XDw8+lOu/5zN7mxvJ4U/Q54S+4ef2x/yUL1r9PneUP+OePbfpTXctbmO7rL2zYMEX1TV/KWy4+6ucA/92X9zldZpvip90RpQk6wAbbw2kn+rQq/zdxHehmXnBh/RCaGm10dwhEtDF9XydF/H0bLso974hHqGxdvKZoy0Ifw922QnaZHOKovIkkTWdZmuXHipzlMoaLBSrfFXn237i1J/KCF8Q3fPG3OC/iw9nHZzWgIDbH2Wtc5B/okPoEr4ax5rGLefzeYkVdtG4RApeFNQ9XTcUnqNCHGq0rkLMZyJFPeBNNyiaAtjbZJu4+VfS184+/0YaJN/5pb3w7dLY+8NYhKf7GNaDPx3OeQL11OqncwOdU9xVHVEMjHj2692yfL+ILX7oOJkWYr+LiwnEOG8oWVoCBFS7L4zQskrfu7bIArK/wR5agL9IwxXGDpyAAnu17wAaOb3WI4/jmk2m6tmfZrudCK3C69VfPoK6y3ZzJq9jwCUC6noafzpPrUDeBr1I9QeoqRyY2D+x2cjoiwor9iGHFgURc8STHFVcEdM4jQtcoew0dAJKhAyKgcx8ROk8x5KAI5KxHRI5sdNL7Yd6d/bABe0d4fMTrHUGZvSM78J9sv+m32BbRb/HYu6/uHgXWk2c1/R/P97ot3mTvHql/5KtDGtCTNGea5TikscheEiCac19a2A6nIsHAB3cCj8dfeJDVZ/zVjPSaYV/rrAtjvQFJ5vYkGZBKMrI/B28kGVmRG4xLMuyd3c+yhln/tPZwWNYiVh9HYUCW9XUHXKn6R0QgaN7KMsipSDTLWN7hvbGsJ8fkRTLnU3CMNCvJANRbLsmBEhkSRXPMVoVj6kUxqVr5OAxjWJVzaExMw/eN+bMxnRnBhOIcGr8WXaJ1B701Edsj5LooTJPVBm0uEC9iVD4tR8PJIkwn9Y7XJIrSc8PxPNtvonLwfSRd6QLUM2b2QMProIuGh8WqxSo8wdVmlW2eJ9Bdo2vrvB0ZJW8nU6Mq2m3DTS+/xGT5JS3L5aL11ZRVl6OKOzemJHEGIIrrEr0Pi2aKy4g/4phy3v0Uz5Qz/rZmCoMpTYSXxpTzbqt4ptiaKReY0p0qBdJjCsvcHYspZ+x7zRQGU1zpMYXl6I7FlDP5NpopLKbIjik+pB5290tnebHOVtkmTH/Nsm399P8TF8VH3dcP90XWxYYcCJzJ7RnQJ+H7HyYbljvHncAk4PRuHHcCwKlI9AyQpy4NjvXU92UNyAnnzMTjnZyA9lCcgKBbETlpLJoT/oNxYnCoPRJqGDyB28D2yABAVyUa7kDDfRlufzi4felwY2tNRbgHDPL2mZmPoYWf7KDdLPxkRaJpYKlLA1HCb4vpDFLCfzMnSOF3RuaErS4nBqSB648SGsBQoYGqSDQNHHVpICo0uGLkggwNt3OCCA1g7NDgqsuJAWkAx7ELwFB2AVWRaBoAdWkgKjSAceyC2zlBhoaR7YJAYSdRjfEjaReA4ewCRlWi4VbYMRyw1Xv2KEoAh+okUhWJpsGjmYR9egdiBg6kEtzOCUIJ4NidRO0kXqkE0BpMCRhVCc/vZyT4z31jOjfQEHIODN8zphOdvegF9FzvuNmLWHRIoJ5LiOaeMfENf6qBgoyX3kcGymYAhRrSs4F62acW1SQGB8bEMqbVLvTnlGBO3XJvBaY/oxuk3doHjCmqCNrleQh43y2L0FPx58eapsbEa13EM3zbmAb4fL+8kWBmTCblRSbzkk/oYNRBRJ/b9Kprrs4Kjme55U1Vdz0BrS+EylFV3wRQMI2XhXIEbJbpucRAaI1KQdaiGQQaF991oN67No//mj14/aJrXiClH+BIa6j4RCi3/Fv1GpjcqoTrNSuLXUOL+1PDQUtXJRxaVtq5KGjLQNg68vnZQf8+BeTWUJBTVUlozde9xL1Iw90uWbBQb2NL8eDzoGsRrdC9cRjteJyKhL/RSo+rTh26piM1c5pPNPBfpL/EHFqN21+6+/3jRxJVCp/b/Q3b51YlvB0yRmMa2kY8h4OWrko4tGOOcj5rf8kihfB2yKmqxm/NPbpLu3W4LT8W4UtK4M2Sux26ZaxwJfILhHOYbEqj63jOIkvTcLtLjpVVR6yTNPo1/Mj2Bb4M3qLksutYU+ucRWHsL5nrnMGFH78shxFcSKYp9lznjOwyDbfebI9FZTCM6GsWSZj+GS+KcLPqgyiNWJRn2x94Yqgs2JYEjfP5G3qCO9zTobtRxXF+o9xZdaSOH1+yoshe6428flpNpcdHBaboD33HWTmlAdC3maFt67SN/srDcxRQNgj5MDniGIe74j3e8WnUhxEXms/FSDQuD+huF52idA8Rjut4hyciZOipLdOjGqxRHzjeDIG7ILDOJbpyXjYTBxarI/Ws4eLAdejCIg29Hn0lrZwkagAQydzSlbOH+6uVU0Dr5q8CPy4PaKuYfhfky4Zi/oJp48Ze1iIhGquLWKkimz2WZNaySaJGvSDZc010cTD2WCRZy6aA1u0pJpu0f6QHnN1Goo5sOiyXSA84eXApopxOjyk1rZwkatRKErKV02G5Plo5hSunw580GpcHtH9Ev2H8VUNx1UgUUk7BLtEjYqWKbPbIAdSyyZ3hlC6bgi0fLZuXmo9Cskn7RzoU89bwkxZ7BbtEj4iVKrKpE4OGmN6ULZsuy/LRsileNhVLDHJp84he8fCrhuJzyyHLir2uYIvoEbFSRDZdnRU0wGgTyM4KcnVWkBTZdBXLCnJp80ibtLzVIaXFXpZFpKc3eXCpopw6MWiAAad85dSJQXKUU7HEIJf2j3Q+LW+tbVmxFwh2iR4RK0VkE9DGjpZNrmxSC8bK9mmBYMtHy+al5qOObALaP9L5tN1GopBsslwiPeDkwaWKcurEoCGsWunKqROD5CinYolBQCcG8RqJQsqpE4OuxkoV2dSJQUP4tLJlEwq2fLRsXmo+6sgmpP0j7dPyfvhMVuyFgl2iR8RKEdmEOjFoAJ8Wyp7ehDoxSIpsQsUSg6BODOI1EoVkUycG3QKXKsqpE4MG8GnlK6dODJKjnIolBkHaP9IDTt5vacqKvZ5gl+gRsVJENj2dGDSATytdNj3Blo+WzUvNRx3Z9Gj/SL/AyftZcmmxVy8XdDVWqsim8llBMmTRJX7Yj7VsO+sndwTipNN+LuviHS2Un9nDwhq/+TM81FcYQMpG0zvg4OfujAuHNnLGbnkfXUilIX9F6s8jNkS+OTMqHL5gc0Y3xHMNMYByG6J/hbfzgA3R56fljAuH9mgkNUQLL9QiDfor0noesSXyjZdx4dDpObJaYmBLbolXGDeP2BL5OTejwmGZVxg0as4/ZZd+n/ouO80h7DTP8vHvPsvyPS3T05Gy/7zSnfS41GTUmcawTJbVA1P8eNCeRfME4L/7rFIY/KPvrSK4Kv+38Mnobqrzq/LPF6dlkIOfxzMuOawr+lpfLcBbOHGmCfABI8CPOoFsWUAHeMkB3uJ30kbmBKuTpgO8HHLwp91GDvBf4I36UZEUnuKANvOsbJHNvp/Rs17/lkVxecT/AQ== \ No newline at end of file diff --git "a/docs/cs-basics/data-structure/pictures/\345\233\276/\346\267\261\345\272\246\344\274\230\345\205\210\346\220\234\347\264\2425.png" "b/docs/cs-basics/data-structure/pictures/\345\233\276/\346\267\261\345\272\246\344\274\230\345\205\210\346\220\234\347\264\2425.png" new file mode 100644 index 0000000000000000000000000000000000000000..b7061f365a915c69709a46b1b094644d3621e2a9 Binary files /dev/null and "b/docs/cs-basics/data-structure/pictures/\345\233\276/\346\267\261\345\272\246\344\274\230\345\205\210\346\220\234\347\264\2425.png" differ diff --git "a/docs/cs-basics/data-structure/pictures/\345\233\276/\346\267\261\345\272\246\344\274\230\345\205\210\346\220\234\347\264\2426.drawio" "b/docs/cs-basics/data-structure/pictures/\345\233\276/\346\267\261\345\272\246\344\274\230\345\205\210\346\220\234\347\264\2426.drawio" new file mode 100644 index 0000000000000000000000000000000000000000..dcf6c68ef1813da5e32f4f82551722d56356dfdb --- /dev/null +++ "b/docs/cs-basics/data-structure/pictures/\345\233\276/\346\267\261\345\272\246\344\274\230\345\205\210\346\220\234\347\264\2426.drawio" @@ -0,0 +1 @@ +7V1dc6M4Fv01PE4K8c2j7Tg7VdtTM7W9W929bwQUmxlivJgk9vz6FV82QsJgW0JqR12paiRAgM6590pHF6yZi9f9P7Jgu/4tjWCiGXq018xHzTAA0B30X1FzqGp8Xa8qVlkc1QedKr7Gf8O6sjnsLY7gDjswT9Mkj7d4ZZhuNjDMsbogy9IP/LCXNMGvug1WkKj4GgYJWfstjvJ1VesZ7qn+Vxiv1s2VgeNXe16D5uD6SXbrIEo/WlXmUjMXWZrm1dbrfgGTovOafqnOe+rZe7yxDG7yMSf4f3/7Ev7+6/yff/7+n+XajNz4v3/9UrfyHiRv9QNrhpOg9ubPxS3nh7ofnP+9Ffc5f0k3+S+7EqUZOsCwt/vTTrS1Kv7XmzbQzTw3lXUnHFs00N0hEFFh/rGOc/h1G4TFng/EI1S3zl8TVAJoM9htK2Rf4j2MipuIk2SRJmlWNmS+vEAnDFH9Ls/Sv2BrT+T6z4hvzcXfYZbDfW/3gSMoiM0wfYV5dkCH1Cc0MNY8Nu26/NFiRV21bhGiqQtqHq6ODZ+gQhs1WhcgZ1CQ6/bwJpoVJoBKm3QD8V5Fj50dvqOC3hR+tAuPe6x0aEr7OP/etIC2y3Me7Lp0OqkoNOdU9wUjwtA6XY/uPX3LQnjmoWtnkgfZCuZnjjPpULawsilYNXUZTII8fsdvlwZgfYU/0hg9yIkpvv/g+7ZreK5t2KYHcOKY+oOuW4YLDMu1HOCbePtVH9RNts25exXXebAdsp0jP80HyyRuorlK1YPEVUomHjvsenKaPNyKcY9uxQS4X7EMwX7F4gGdeY/QAReHztYFQ2fzgM66R+gMyZBzeCAH7hG5rtEJH4e5N47DGI6OmvnR0OjIETo6srwHwzuOWwyAj1ssg7770uGRaYEHFxzHP67n4pex6bsnGh958pDGHkmaHrOchjSgO0rSO+Y8lhbAG2iIM/D+jcA3869mkjVm/nWc6R2nfa2zzsz1GJLMGkkyWyTJusM5cCXHOu1Y1rQUa277do4defWjtWeAYy1ajdETGHJsrDZgCXVkHf9j29c6MjDQEG+W0ZTDWz3ZSI6J82Pmz8Cx7uyGcECjJabuNKnrEXlzzJCFY/J5MaGR8n4YRhEql4420zXP05ZP2nyh+TOCc2j2muNEw6e8NRHb8+O6Kkji1QYVQ8QLiOrnxVw4DoNkVu94jaMo6ZuMZ+nbJiqm3iXpCg2gXi8zGE2uLRwNpwlWLVY1y1ttVhl6P4FumluDfjEyit9PkkZVtdsGm1FqiU5TS1qCy1nh61hXXY6oxm5MSuIwIIrpd+zWIZliUfwPP6b0a5/8mdKjbium0JgCRDOlX2vlzxRDMeUMU/CFUku4T6FJu1MxpUe8V0yhMUW4T6HpuVMxpSfbRjGFwhRTuE8ZIQDv1sG22MyD56QzoaV12g7NkZqJQNFtIWJREG+K3i/PCdMkCba7uGysOmIdJ9GX4JC+5c1lmhIxqyjL9b0BjVj0iwLovVAX/ZzQg88vbGB09A6MIxf9utNSdslXIzTWBkb0mHkcJP+CYR5sVmMQJRGLsnT770YSKCq2xYwYZst31IO7ZkJImmOebuudCXxpzn1O8zx9rQtZ3VvHRsuusufoDz3jolDXbPQ0C1QGpzL6Kw7P8kW6QcgHcYkjDHb5B9wN02gMI86Yz1nZY1oekCqoxZQIZVJrcCJCinrtJSnlrjXypHDDAndOYLWyXPvAovlefmDR5MQnBdcAXB1tSBh6tJxCFTkHIqet25JFTpqkpyIn98hpDKdET8sDUrADTInwU7vi4fXDaX0vTTNTWJ3FSpawOSI/UYXNLmpeZ8JpjUwQ5gfjiIxBFTY5WLcrWdgk9SM14cSNRJ6wadJUIjXhHIJLkshpjshwU5Gzi5orW+Q0aaqPipzcI6c5/MLAtDwg9SNTuWLMSCSKnJxVonvESpawScvEUmHzwhVO8WGTs+SjwuY585EobJL6kXLFuJFIFDY5q0T3iJUsYVMlBjFY3hQeNi2a5KPCJv+wKVlikEWKR7pyxZiRyBM2Lc4S0T1iJUnYtFRWEIvZpuisIEtlBQkJm5ZkWUEWKR4pkRY3EonCJk0iUsubQ3DJEjlVYhCLCafwyKkSg8RETskSgyxSP1L5tLiRyBM5bc4q0T1iJUnYtFVWEIOsoLEf3OUHI2fJR4XNc+YjT9i0Sf1I5dPiRiJR2KSpRGrCOQSXLJFTJQYxkGrFR06VGCQmckqWGGSrxKAhI5EocqrEoIuxkiVsqsQgBjqt8LDpcJZ8VNg8Zz7yhE2H1I+UTosbiTxh0+GsEt0jVpKETUclBrHQaUUvbzoqMUhI2HQkSwxyVGLQkJFIFDZVYtA1cMkSOVViEAudVnjkVIlBYiKnZIlBDqkfqQknbiTyRE6Xs0p0j1hJEjZdlRjEQqcVHTZdzpKPCpvnzEeesOmS+pF6gRM3EonCpvpc0MVYyRI2pc8KEhEWLROfTdI+2077fU+OOKm0n/Nx8QYLve63XJs3f9hDfYEAJK03vQGO4dydaeFQQs7UlnfAIRWG/AWpP/doiMPizKRweJzFGWWIfYboO2IN0btA27lDQ/SG03KmhUNpNIIMETQfahEG/QVpPfdoicPCy7RwqPQcUZboG4It8QLh5h4tcTjnZlo4HKL38V9TRiRdp6t0EyRf0rKPiq7/E+b5oZbKgrc8xYHpKpKoR7LD97q9svCjKCBTqIuP+/bOxwPWyzBawd4+rqvyxrb7HrPvc3QZTII8fscvQOvk+tQ/ChNv6W02rrdZ3R+A3qVvWQjrs05QEQ3Z3S+rdRuqnpBoqMT8+Dw30MCVlwYUQZsJJ/q+7HsjJ2yXFSdA55tB5sSc8O6ME8yhdrpQA//Bvg5s4vdvyKZ4w+0ruM/D7bKDm/ihwMnh9sllaWngZujk+35mk3HgN11GgZ9oiDcNyKQ+aWjAK/D3/WI548B/PSc6gd/0JuYEOSOThhMMadD3xTDWcwJWroFoiDcNyDdlpKEBL9fQ9/FV1nMCVq7Bmto1kF+5koYTDGnQ95IqY9dgs5ILiIZ408CWlwa8XEPf9z4Yu4brOdFxDfbEcoEvsZIox/yxKxfY7OQCSlO84ZZYMWRo9X1psKwjAatBItEQbxrcm0g4ZnTAZ+JARAJWg0R76kGiUhIvjQQOu0hANsUZbtB8I6u9pLv0tPlSQ1PIpa15rjafacsnbb7Q/BnBjRzucxxsPEe+XqGlLNoGSbzaoGIIi8V8VFGsyMZhkMzqHa9xFJXLxrS1YpyTXYLVj3RTNr6OIeNS3plo3rLFkvF55eKDhipdoJ4KiJauNvM0b66AcgzhQBkUoJAhPWlolH2yKEeb6ZrnaUtfmwFtXu1Cf2YB5twq9lZgegvSIEFrn63NUUMOKM5DwHtWUeWjqmXZ0lybua2LuJpnaHO/Od8rbsRfaLNZcZHZsuATOhgNENF2m151y9VZfnmWVdxUddczu/VAqB419di6RXxX8fSoff/kWIpjylstHhG1/Kj55KdDbmdwlR0iGX8B8AcJ7DbNTsTgEQl3cBPNsqxMzal7uRcYzTD18t9xz7f60cAF432yAwfSbpq6G8O9aXYcjONdG+6PPxzU3xT3cD8iee/TQuvqzKClNMUd2hHJecygLRxh68inJxP9+ykgB6wg7zYlwppHvKDZgjxMgt0uDmmot7ElePDToGs4HQfrXzkLN42BhrgjS76PeRoPHsdhC/O4ZRy3yKSATzJyos7RnGlHTiPe2/w04ZUY2V4vlBjmYFPcLXLEi5mfFlpXZwYtpSne0IIRL3l++pETMLoj3Ksh7zYlwJrBBW93yvnlrrM0ui2u9sMj6osxAPTD8ynfMeNKj3Mmc9b9TMwJUqYix77Sv44mAkljKiRRMUvTvO28Ueeuf0sjWBzxfw== \ No newline at end of file diff --git "a/docs/cs-basics/data-structure/pictures/\345\233\276/\346\267\261\345\272\246\344\274\230\345\205\210\346\220\234\347\264\2426.png" "b/docs/cs-basics/data-structure/pictures/\345\233\276/\346\267\261\345\272\246\344\274\230\345\205\210\346\220\234\347\264\2426.png" new file mode 100644 index 0000000000000000000000000000000000000000..a9349c14f10ecaace2f607ac8f3a91bfb469a7dc Binary files /dev/null and "b/docs/cs-basics/data-structure/pictures/\345\233\276/\346\267\261\345\272\246\344\274\230\345\205\210\346\220\234\347\264\2426.png" differ diff --git "a/docs/cs-basics/data-structure/pictures/\345\233\276/\346\267\261\345\272\246\344\274\230\345\205\210\346\220\234\347\264\242\345\233\276\347\244\272.drawio" "b/docs/cs-basics/data-structure/pictures/\345\233\276/\346\267\261\345\272\246\344\274\230\345\205\210\346\220\234\347\264\242\345\233\276\347\244\272.drawio" new file mode 100644 index 0000000000000000000000000000000000000000..ae77016546086d9780c0aaa63139630b11262ab4 --- /dev/null +++ "b/docs/cs-basics/data-structure/pictures/\345\233\276/\346\267\261\345\272\246\344\274\230\345\205\210\346\220\234\347\264\242\345\233\276\347\244\272.drawio" @@ -0,0 +1 @@ +3VpLk6M2EP41HMclifcRv5JDtmoqU6nNHhkjYzYYsUKewfn1kYzEy2Dj8TOew1hqdUsgfV833aDpk3X+G/XT1TcS4FhDIMg1faohBCGw+I+QbAuJC0AhCGkUSKVK8Bb9i6VQqW2iAGcNRUZIzKK0KVyQJMEL1pD5lJLPptqSxM1VUz/Ee4K3hR/vS79HAVsVUgfZlfx3HIUrtTK03GJk7StleSfZyg/IZ02kzzR9QglhRWudT3AsNk/tS2E37xktL4zihA0xCN0cvE1oDl+nKZn+lX3/Mwxf5CwZ26obxgG/f9kllK1ISBI/nlXS8WJDP7CYFPIOJZsk2PUA71UGfxCSSpWfmLGtPFl/wwgXrdg6lqM4j9jf0ly0f4j2yJS9aV4bmm5VJ2F0K4xewAhAJSgsLegoQWW86zWsXzGN1phhKoUZo+QfPCExobt90Odznf/xkWKHxLb0brzaRbKhC3xgt5EEsE9DzA7ouSU8OK8w4ddJt9yO4thn0UfzOnwJ8LDUk6Yepf62ppCSKGFZbeZXIeAKiqu2BKpkKnRaeDqir+tuXZ83iitQvdqtVKIdRk/Aq9zBDz/eyG3QkBXzvRy/N2Bs/doIXo2XJGEv2Q57HldAZppXg7wVil+g5uCX9K6E+8SIY+50BAE+VxHDb6m/O+tP7veaiPaztPBEyygXzBgvoziuIWu5xNZi0YW5wHbfASgX/8CU4fww6vZRIg1Kv6OO05D9z5obk6JVzYMpWReuamd7+tHpHUfX3uIk8ITP5r2EJLjlKBTpQYPwx8gu3Qs8wb1ckPEqjB2lvNl9mLXDMjsOS8lO8wx7VDZcd+S6po0c20Sm7gC7CR3E3SwwkA2RYRsWdPXmAsUuyDkPeAzDtkamVZunBVB9ZOjVRcDWKsUW7q1yKc9iPE4kLOH5o47Ow5FQGg2lxU3CnTkQ+xB0g38wqs/yS+Y1Qgp6xpBiwmZIKR/S7xVSrIfhbD28wC8xFj4CY+3zotVtCGtfg7D6MxJWbz2i8+z7voR1HoawzSD7P6asO5Cy9pmU/VJOiawmAA1wOKc04EH96+SU7jX8ifGM/qSdU97dnyi4XPbs4DOeXTsW3L0eAGHH2Z1SELigEx1amOvLVG6UphvOCDll/oxUhlw+jncPn5qmmwYc2bBMxO1mmo5ao47dXOXKaTrsqgDeCTVDQy+6J2j0VkiFbovQQ2GhO0cmuvbJn11APOdNQ+stQ/kc2PPod0GUDc3Jel4a3AZlqP0yAHwRZe2J+Ey3RZlxKZRdIME4VsW7IMoGF6p78ogbObOWD9KNrzozeGSiHpidmgC1ExqVEF01oYFdJc1zPeVABN/PTw6tNt8VwEY7g2q7t8HvUtARh3ttP2k9CsYe0EfeNRQ/D8T6C71Z6ieD8nvQld9rM1sbe5qHZGM812aO5kHNc4TEM4RwZmn8Aded7HSMnbKjjfkoVza18UxzyhLPO61m3rdyxcxiQlP8d7j5XBtPNNcDsuVMjLKlly1UturliOLGeyoSDOesSbJmRUGSsF5+kCI/jsKEdxecE+KTmLEoNUQLP/bkwDoKgriv1tEsygZ+tirrtdr5hYsSv6omqPo1OnVWLhDop05P5YJ3qw+yChxXn7Xps/8A \ No newline at end of file diff --git "a/docs/cs-basics/data-structure/pictures/\345\233\276/\346\267\261\345\272\246\344\274\230\345\205\210\346\220\234\347\264\242\345\233\276\347\244\272.png" "b/docs/cs-basics/data-structure/pictures/\345\233\276/\346\267\261\345\272\246\344\274\230\345\205\210\346\220\234\347\264\242\345\233\276\347\244\272.png" new file mode 100644 index 0000000000000000000000000000000000000000..7d1bbd7bc927fe77248c6353cfe373af241aa431 Binary files /dev/null and "b/docs/cs-basics/data-structure/pictures/\345\233\276/\346\267\261\345\272\246\344\274\230\345\205\210\346\220\234\347\264\242\345\233\276\347\244\272.png" differ diff --git "a/docs/cs-basics/data-structure/pictures/\345\240\206/\345\210\240\351\231\244\345\240\206\351\241\266\345\205\203\347\264\2401.png" "b/docs/cs-basics/data-structure/pictures/\345\240\206/\345\210\240\351\231\244\345\240\206\351\241\266\345\205\203\347\264\2401.png" new file mode 100644 index 0000000000000000000000000000000000000000..f150d59686893e80e75c1460de1ad949dc9698fc Binary files /dev/null and "b/docs/cs-basics/data-structure/pictures/\345\240\206/\345\210\240\351\231\244\345\240\206\351\241\266\345\205\203\347\264\2401.png" differ diff --git "a/docs/cs-basics/data-structure/pictures/\345\240\206/\345\210\240\351\231\244\345\240\206\351\241\266\345\205\203\347\264\2402.png" "b/docs/cs-basics/data-structure/pictures/\345\240\206/\345\210\240\351\231\244\345\240\206\351\241\266\345\205\203\347\264\2402.png" new file mode 100644 index 0000000000000000000000000000000000000000..46a46a0a927b7f3a2664ab639129a1f1f5057f75 Binary files /dev/null and "b/docs/cs-basics/data-structure/pictures/\345\240\206/\345\210\240\351\231\244\345\240\206\351\241\266\345\205\203\347\264\2402.png" differ diff --git "a/docs/cs-basics/data-structure/pictures/\345\240\206/\345\210\240\351\231\244\345\240\206\351\241\266\345\205\203\347\264\2403.png" "b/docs/cs-basics/data-structure/pictures/\345\240\206/\345\210\240\351\231\244\345\240\206\351\241\266\345\205\203\347\264\2403.png" new file mode 100644 index 0000000000000000000000000000000000000000..2a6d06d3b1b308d960cb7b9828e162402b58ca03 Binary files /dev/null and "b/docs/cs-basics/data-structure/pictures/\345\240\206/\345\210\240\351\231\244\345\240\206\351\241\266\345\205\203\347\264\2403.png" differ diff --git "a/docs/cs-basics/data-structure/pictures/\345\240\206/\345\210\240\351\231\244\345\240\206\351\241\266\345\205\203\347\264\2404.png" "b/docs/cs-basics/data-structure/pictures/\345\240\206/\345\210\240\351\231\244\345\240\206\351\241\266\345\205\203\347\264\2404.png" new file mode 100644 index 0000000000000000000000000000000000000000..fa36b2b1b307a582d5af7d203e35df9fb4117cf2 Binary files /dev/null and "b/docs/cs-basics/data-structure/pictures/\345\240\206/\345\210\240\351\231\244\345\240\206\351\241\266\345\205\203\347\264\2404.png" differ diff --git "a/docs/cs-basics/data-structure/pictures/\345\240\206/\345\210\240\351\231\244\345\240\206\351\241\266\345\205\203\347\264\2405.png" "b/docs/cs-basics/data-structure/pictures/\345\240\206/\345\210\240\351\231\244\345\240\206\351\241\266\345\205\203\347\264\2405.png" new file mode 100644 index 0000000000000000000000000000000000000000..586f6c1ed02482fe56f9a8186e718734246a6a95 Binary files /dev/null and "b/docs/cs-basics/data-structure/pictures/\345\240\206/\345\210\240\351\231\244\345\240\206\351\241\266\345\205\203\347\264\2405.png" differ diff --git "a/docs/cs-basics/data-structure/pictures/\345\240\206/\345\210\240\351\231\244\345\240\206\351\241\266\345\205\203\347\264\2406.png" "b/docs/cs-basics/data-structure/pictures/\345\240\206/\345\210\240\351\231\244\345\240\206\351\241\266\345\205\203\347\264\2406.png" new file mode 100644 index 0000000000000000000000000000000000000000..e13ec00d80f7b96ceea9d96f252bdd33c6c26cf0 Binary files /dev/null and "b/docs/cs-basics/data-structure/pictures/\345\240\206/\345\210\240\351\231\244\345\240\206\351\241\266\345\205\203\347\264\2406.png" differ diff --git "a/docs/cs-basics/data-structure/pictures/\345\240\206/\345\240\206-\346\217\222\345\205\245\345\205\203\347\264\2401.png" "b/docs/cs-basics/data-structure/pictures/\345\240\206/\345\240\206-\346\217\222\345\205\245\345\205\203\347\264\2401.png" new file mode 100644 index 0000000000000000000000000000000000000000..e8268a9754a3b505edf0d45336004d66e90a49c0 Binary files /dev/null and "b/docs/cs-basics/data-structure/pictures/\345\240\206/\345\240\206-\346\217\222\345\205\245\345\205\203\347\264\2401.png" differ diff --git "a/docs/cs-basics/data-structure/pictures/\345\240\206/\345\240\206-\346\217\222\345\205\245\345\205\203\347\264\2402.png" "b/docs/cs-basics/data-structure/pictures/\345\240\206/\345\240\206-\346\217\222\345\205\245\345\205\203\347\264\2402.png" new file mode 100644 index 0000000000000000000000000000000000000000..d670321d03ea1293c42491473d13eea650b92122 Binary files /dev/null and "b/docs/cs-basics/data-structure/pictures/\345\240\206/\345\240\206-\346\217\222\345\205\245\345\205\203\347\264\2402.png" differ diff --git "a/docs/cs-basics/data-structure/pictures/\345\240\206/\345\240\206-\346\217\222\345\205\245\345\205\203\347\264\2403.png" "b/docs/cs-basics/data-structure/pictures/\345\240\206/\345\240\206-\346\217\222\345\205\245\345\205\203\347\264\2403.png" new file mode 100644 index 0000000000000000000000000000000000000000..37ef1fc15628b8592c3fbe4e5ab46b7017db6c30 Binary files /dev/null and "b/docs/cs-basics/data-structure/pictures/\345\240\206/\345\240\206-\346\217\222\345\205\245\345\205\203\347\264\2403.png" differ diff --git "a/docs/cs-basics/data-structure/pictures/\345\240\206/\345\240\2061.png" "b/docs/cs-basics/data-structure/pictures/\345\240\206/\345\240\2061.png" new file mode 100644 index 0000000000000000000000000000000000000000..488741f77ab70cd02b49d9e056ce1ef2695f2396 Binary files /dev/null and "b/docs/cs-basics/data-structure/pictures/\345\240\206/\345\240\2061.png" differ diff --git "a/docs/cs-basics/data-structure/pictures/\345\240\206/\345\240\2062.png" "b/docs/cs-basics/data-structure/pictures/\345\240\206/\345\240\2062.png" new file mode 100644 index 0000000000000000000000000000000000000000..4b7e63f73ae242594b7aa33cf16a1eef5ddaa7ee Binary files /dev/null and "b/docs/cs-basics/data-structure/pictures/\345\240\206/\345\240\2062.png" differ diff --git "a/docs/cs-basics/data-structure/pictures/\345\240\206/\345\240\206\346\216\222\345\272\2171.png" "b/docs/cs-basics/data-structure/pictures/\345\240\206/\345\240\206\346\216\222\345\272\2171.png" new file mode 100644 index 0000000000000000000000000000000000000000..74fc70615378c74cbc04d21782f44030d20a0951 Binary files /dev/null and "b/docs/cs-basics/data-structure/pictures/\345\240\206/\345\240\206\346\216\222\345\272\2171.png" differ diff --git "a/docs/cs-basics/data-structure/pictures/\345\240\206/\345\240\206\346\216\222\345\272\2172.png" "b/docs/cs-basics/data-structure/pictures/\345\240\206/\345\240\206\346\216\222\345\272\2172.png" new file mode 100644 index 0000000000000000000000000000000000000000..dcb57d6a57e6ff9333f9e3eeccb42c1c04910511 Binary files /dev/null and "b/docs/cs-basics/data-structure/pictures/\345\240\206/\345\240\206\346\216\222\345\272\2172.png" differ diff --git "a/docs/cs-basics/data-structure/pictures/\345\240\206/\345\240\206\346\216\222\345\272\2173.png" "b/docs/cs-basics/data-structure/pictures/\345\240\206/\345\240\206\346\216\222\345\272\2173.png" new file mode 100644 index 0000000000000000000000000000000000000000..bd028d955ee2652aedbd113537a443bd9ce1c145 Binary files /dev/null and "b/docs/cs-basics/data-structure/pictures/\345\240\206/\345\240\206\346\216\222\345\272\2173.png" differ diff --git "a/docs/cs-basics/data-structure/pictures/\345\240\206/\345\240\206\346\216\222\345\272\2174.png" "b/docs/cs-basics/data-structure/pictures/\345\240\206/\345\240\206\346\216\222\345\272\2174.png" new file mode 100644 index 0000000000000000000000000000000000000000..4705d9db82eeb5b6ef3fbf7f825ab22950bd915b Binary files /dev/null and "b/docs/cs-basics/data-structure/pictures/\345\240\206/\345\240\206\346\216\222\345\272\2174.png" differ diff --git "a/docs/cs-basics/data-structure/pictures/\345\240\206/\345\240\206\346\216\222\345\272\2175.png" "b/docs/cs-basics/data-structure/pictures/\345\240\206/\345\240\206\346\216\222\345\272\2175.png" new file mode 100644 index 0000000000000000000000000000000000000000..87f8816fdfffb615e5d86936e56fc7414a32b68e Binary files /dev/null and "b/docs/cs-basics/data-structure/pictures/\345\240\206/\345\240\206\346\216\222\345\272\2175.png" differ diff --git "a/docs/cs-basics/data-structure/pictures/\345\240\206/\345\240\206\346\216\222\345\272\2176.png" "b/docs/cs-basics/data-structure/pictures/\345\240\206/\345\240\206\346\216\222\345\272\2176.png" new file mode 100644 index 0000000000000000000000000000000000000000..8f20179d7e232e620b279082015daa0032c696b4 Binary files /dev/null and "b/docs/cs-basics/data-structure/pictures/\345\240\206/\345\240\206\346\216\222\345\272\2176.png" differ diff --git "a/docs/cs-basics/data-structure/pictures/\345\240\206/\345\240\206\347\232\204\345\255\230\345\202\250.png" "b/docs/cs-basics/data-structure/pictures/\345\240\206/\345\240\206\347\232\204\345\255\230\345\202\250.png" new file mode 100644 index 0000000000000000000000000000000000000000..d7a4d6a85a502e0949aea9557071ecc172c14c60 Binary files /dev/null and "b/docs/cs-basics/data-structure/pictures/\345\240\206/\345\240\206\347\232\204\345\255\230\345\202\250.png" differ diff --git "a/docs/cs-basics/data-structure/pictures/\345\240\206/\345\273\272\345\240\2061.png" "b/docs/cs-basics/data-structure/pictures/\345\240\206/\345\273\272\345\240\2061.png" new file mode 100644 index 0000000000000000000000000000000000000000..f97602b81aedf97deab4a8dce769f9ab2f331ef7 Binary files /dev/null and "b/docs/cs-basics/data-structure/pictures/\345\240\206/\345\273\272\345\240\2061.png" differ diff --git "a/docs/cs-basics/data-structure/pictures/\345\240\206/\345\273\272\345\240\2062.png" "b/docs/cs-basics/data-structure/pictures/\345\240\206/\345\273\272\345\240\2062.png" new file mode 100644 index 0000000000000000000000000000000000000000..e9038d64de029262b9dbce03dfafb74cd990fbc7 Binary files /dev/null and "b/docs/cs-basics/data-structure/pictures/\345\240\206/\345\273\272\345\240\2062.png" differ diff --git "a/docs/cs-basics/data-structure/pictures/\345\240\206/\345\273\272\345\240\2063.png" "b/docs/cs-basics/data-structure/pictures/\345\240\206/\345\273\272\345\240\2063.png" new file mode 100644 index 0000000000000000000000000000000000000000..8d8b3ff271d32f3b8ce70e65186eab257aaad5f7 Binary files /dev/null and "b/docs/cs-basics/data-structure/pictures/\345\240\206/\345\273\272\345\240\2063.png" differ diff --git "a/docs/cs-basics/data-structure/pictures/\345\240\206/\345\273\272\345\240\2064.png" "b/docs/cs-basics/data-structure/pictures/\345\240\206/\345\273\272\345\240\2064.png" new file mode 100644 index 0000000000000000000000000000000000000000..b0265b8d1b1bf1a3fa23364df36b2404bc884b9e Binary files /dev/null and "b/docs/cs-basics/data-structure/pictures/\345\240\206/\345\273\272\345\240\2064.png" differ diff --git "a/docs/cs-basics/data-structure/pictures/\346\240\221/\344\270\255\345\272\217\351\201\215\345\216\206.drawio" "b/docs/cs-basics/data-structure/pictures/\346\240\221/\344\270\255\345\272\217\351\201\215\345\216\206.drawio" new file mode 100644 index 0000000000000000000000000000000000000000..f8fe81d2c06ef9658666cea3abc0481d47ebae6d --- /dev/null +++ "b/docs/cs-basics/data-structure/pictures/\346\240\221/\344\270\255\345\272\217\351\201\215\345\216\206.drawio" @@ -0,0 +1 @@ +7Vtbk6I4FP41eZwukgBJHr1g727tVk1VV+30PNKSVmbQuIit7q/fBAISBLVbFHfa8sHkJORyzpcv5xwR4MFs8xj7i+lfIuARQFawAXgIEILQcuWXkmwzCWMkE0ziMNCddoKn8F+uhZaWrsKAL42OiRBREi5M4VjM53ycGDI/jsXa7PYqInPWhT/he4KnsR/tS7+FQTLNpBSRnfw3Hk6m+czQZVnLzM87650sp34g1iUR9gAexEIkWWm2GfBIKS/XS/bcqKG1WFjM58kpD6yenT8ev/39O3VCf/C2ZpuF7X/Ro7z50UpvGCA3kuP1X9SSk63Wg/vPSq2z/yrmyZdlaqWe7ICcxWbXKEsT9d3Lx5CLecmFWgnFiEiuThpRVvrraZjwp4U/Vi1riSMpmyazSNagLPrLRWbZ13DDA7WIMIoGIhJxOhB+feXueCzlyyQWP3mpJSDsxbKKyd94nPBNo/pgYRSJZi5mPIm3sot+gGBtRw1kzHR9XYKFFk1LiMhlvgbipBh5ZytZ0OZ6h+lQjemqKp4HPXUGZG0u5txUq9x3vH0uV76XK0O1b6uobXUtm4MHe6emoke5DrGKx/zABrA+zn484ckxjO7bpaR3p0bvuSzmkZ+Eb+Zy64yhZ/gqQrmRndktYpidWBV7ZtvUT5WPX3Ug5jwgaiMCkU1sN1+JHtYm1GzF5iyZkvZmSYFT6OTjWMKNNLBc+POPM0GJTDLBoJ4aClk23a/BGJSajGF3zRj2tazc/0RWdq0bs7JzLSsPP5GVHWRa2SEdW9m9lpUfP5GVmXtjVibn+nibMHkulb/nPp0s7xw8Vcn9u8IrLCpX9grt/4NX6FaAQuAHvUKKqIk4hq7q+NFzAVYbRFhH4JLD0irBEh6EZQcAc7oEGKneN+yjYYdDD4UdrNOwg52JvhZR4Z6ICtwlKiiCDy7GDrapdEgQNI3pUPjAIGO27AZtNw9c301J2D2AGIdada1XAkxOs5d3e7xP5Pa49MbcHliXljzX7zl8wdT7Pccusi78HqvelldyfMw8FWQmcCB8INAhiBIHOZhWhj/5zrJqh8nvLFq7hGsxEGpkIEU0LTKQfYSBsukaGEiSQWIeCZNB9JEp040W+VE4mcvqWCKYS3lfUUs49qOebpiFQRA1cVssVvNAMdmwLW5ilfSKtc9Ndg3e0cW4qTlX2jIA0B0AilOcyuXUOQCa06gtA8C9AyD1R28NAM0Z1pYBAO8ASC/8CgBo1wBw971R6QI+6arWoqkHESdTMRFzP/pTiIU2yA+eJFv9zoO/SkRDbsV6cDpKxuVvXHwwGXeys3meOeqypBcJCkefKCik1q0Fha3lKt+V2n5/Cr3N80dOPICdpqWgZQZsxIwKXYjrWt8bFbKDmUwJzy7zUnWZzIu4BM7dJZAthNyYS5APfHkAkDsAFBlUg4LOAdD8JmXLAMB3AKhLxb41ADQnBs/zQod9rzcalF/DOOhm/jIWJpXf2N3OLYz3/c1LhH35j+NZ1HdtlzPH8VGXM+vYVdCHarJwngP6Huh5wLOBjNV6EHguYBZgA+AhQNOCycnjInbanToZXzGG8f5BfAyT6epFjUk9wCjwGKAEMDkLVZOq6RxAKWCoiY31KoYFp8en0AK0a+8FORnrA+apQs8GdNjKJr8OR0dXL/crNSA9EbXfEWCuXotUvlIFAT1c0glRBUZSWwxAv5d2HqUFojrkx/rmOCzyX3jU98c/J6m8OrlUjT7D0Nb1UijeTz8theLQZEIb7zNhQXtnUqGs7v6SkoVHuz/2YO8/ \ No newline at end of file diff --git "a/docs/cs-basics/data-structure/pictures/\346\240\221/\344\270\255\345\272\217\351\201\215\345\216\206.png" "b/docs/cs-basics/data-structure/pictures/\346\240\221/\344\270\255\345\272\217\351\201\215\345\216\206.png" new file mode 100644 index 0000000000000000000000000000000000000000..5935c2e39fe6ed1a7900f8071d7c3773e886eca4 Binary files /dev/null and "b/docs/cs-basics/data-structure/pictures/\346\240\221/\344\270\255\345\272\217\351\201\215\345\216\206.png" differ diff --git "a/docs/cs-basics/data-structure/pictures/\346\240\221/\344\270\255\345\272\217\351\201\215\345\216\2062.drawio" "b/docs/cs-basics/data-structure/pictures/\346\240\221/\344\270\255\345\272\217\351\201\215\345\216\2062.drawio" new file mode 100644 index 0000000000000000000000000000000000000000..31e3097a914f4b43ea6c1037a6533db832c3fde5 --- /dev/null +++ "b/docs/cs-basics/data-structure/pictures/\346\240\221/\344\270\255\345\272\217\351\201\215\345\216\2062.drawio" @@ -0,0 +1 @@ +5ZhNc5swEIZ/jY/uYLDBHGPsuIdmpmMfmhxlkEGtYKkQBvLrK1niq46bJm0Zpj6hfSWtpH12NSMmlheXW4bS6AECTCemEZQTaz0xzdnMsMVHKpVSXNdRQshIoAe1wp48Yy0aWs1JgLPeQA5AOUn7og9Jgn3e0xBjUPSHHYH2V01RiC+EvY/opfqFBDxS6tJ0Wv0jJmFUrzyzXdUTo3qwPkkWoQCKjmRtJpbHALhqxaWHqQxeHRc17/5Kb7MxhhP+OxN22UPg7CLH2z06MV1Pt0bxPNVeTojm+sAT06bC3+ogt8wrHQf7ey73uTpCwqfZmdKdGGAu0rLtFK1Qfu9qH2Izh1rUQWg8mmJ3AqIwVkVEON6nyJc9hcgjoUU8psKaiSbKUkX2SEocyE0QSj2gwM6OrOMR274v9Iwz+IY7PYHjHgyjWfyEGcfl1fDNGigimzHEmLNKDNET7DojdSLPa7vopIWWok5G1BrSiRg2nltWoqFxvQGdeRVdlqLk/fQ6CaAE72WcjaaW+z8oO+7IKFtDUV7dEOW5NTLK86Eor2+IsjUfGeXFUJS3N0R56bjjomwPRXlzQ5QX5shq2bmMaCAeDtpMIJGhZZAngQzaWoYBGI8ghATRTwCpDu9XzHmlnz0o59APvogOqx7l/A+L2nzq9q1L7VxZlbbey0ie4deExJEhZz5+/U3BEQsxf23cJXGGKeLk1N/HX+e3HKpK72+oSh1jZFXqDlOlJeGdIhXWU12Vot2WqDT+fYX+QUXpqZ+BCI/ty/enu7e5i2sX6kbQs7p/IN7qSF0ZF47O6JvzvJQNwmx/pKjh7e8oa/MD \ No newline at end of file diff --git "a/docs/cs-basics/data-structure/pictures/\346\240\221/\344\270\255\345\272\217\351\201\215\345\216\2062.png" "b/docs/cs-basics/data-structure/pictures/\346\240\221/\344\270\255\345\272\217\351\201\215\345\216\2062.png" new file mode 100644 index 0000000000000000000000000000000000000000..aa74c7d6c7218aa0a886f3e47ebda6f7485a62fd Binary files /dev/null and "b/docs/cs-basics/data-structure/pictures/\346\240\221/\344\270\255\345\272\217\351\201\215\345\216\2062.png" differ diff --git "a/docs/cs-basics/data-structure/pictures/\346\240\221/\345\205\210\345\272\217\351\201\215\345\216\206.drawio" "b/docs/cs-basics/data-structure/pictures/\346\240\221/\345\205\210\345\272\217\351\201\215\345\216\206.drawio" new file mode 100644 index 0000000000000000000000000000000000000000..b92e5c29cc9a4f78293af95b04fa5a75122075f2 --- /dev/null +++ "b/docs/cs-basics/data-structure/pictures/\346\240\221/\345\205\210\345\272\217\351\201\215\345\216\206.drawio" @@ -0,0 +1 @@ +7Vtbk6I4FP41eZwuIDfyKIq9D7tVU9u1tTOPKGllGo2L2Or8+k0kIEFQ2xvOtOWDyUnI5ZwvJ985IoDdyeo5CWbjv0TIY+BY4QrAHnAc27aI/FKSdSZhjGaCURKFutNW8BL95FpoaekiCvnc6JgKEafRzBQOxXTKh6khC5JELM1uryI2Z50FI74jeBkG8a703yhMx5nUdehW/gePRuN8ZpuwrGUS5J31TubjIBTLkgj6AHYTIdKsNFl1eayUl+sle67f0FosLOHT9JgHEuvvH2+rZPbTI6O56/T+WTrPX/Qo70G80BsGDonleN5ALTldaz2Q/xZqnd6rmKZf5hsrdWQHB89W20ZZGqnvTj6GXMwgF2olFCM6cnXSiLLiLcdRyl9mwVC1LCWOpGycTmJZs2UxmM8yy75GKx6qRURx3BWxSDYDwddXToZDKZ+niXjjpZaQsoFlFZO/8yTlq0b12YVRJJq5mPA0Wcsu+gGCtB01kCHW9WUJFlo0LiEilwUaiKNi5K2tZEGb6wOmc2pMV1XxNOyoMyBrUzHlplrlvpP1t3Lle7nSU/u2itpa17I5eLhzaip6lOsQi2TI92wA6uMcJCOeHsLorl1Kesc1es9lCY+DNHo3l1tnDD3DVxHJjWzNblPD7IRU7JltUz9VPn6VgaiFnxwXOdR2EEUkX4keFkHXbIXmLJmSdmbZAKfQyelYgo1uYD4Lpqd7gpIzyQTdetdQyLLpfg+PQZnpMVDbHgPdysreJ7Iytu/MyvhWVu59IisjaFoZw5atTG5l5edPZGWX3pmV6bkcbxWl30rl7zmnk+UtwVOVnN8VrLCo3JgVol+BFeIKUAg9lRVC10Qcdm5K/NxzAVYbRFgH4JLD0irB0t4LyxYAhtsEGKneN/hEgBHi7gs7cKthBzsTfRdEBTkSFbBNVFBoPxEIMUQulhe4bRoTI/uJ2YwhV7YgYtETXRIiexCDkVXXeiPA5Fz7+rTH/0S0B7M7oz12XVryXN6z/4Kp5z2HLrI2eI9Vb8sbER/XuDBsZl4n1H6iNqaSSGOJIrcy/NF3ll07TD4Jql3CrTyQ0+iBlKO5oAeyD3igbLoGDySdQWoeCdOD6CNTdjdaFMTRaCqrQ4lgLuWeci3RMIg7umEShWHc5NsSsZiGypP1LpV2typpd7Lrm1AN3p2r+abmXOmFAeA8AKCMS0wAoNYB0JxGvTAA8AMAGz56bwBozrBeGADwAQDl8qv0FLUNALLLRiUFfNFVrUVTDyJJx2IkpkH8pxAzbZAfPE3X+p2HYJGKhtyK9YRbSsblb1ycmIw7mmyeZ466LOlVgsL+JwoKqX1vQeHFcpUfSm1/PIV+yfNHjzyAraalmBmvUTMoxBTWtX40KHT3JjIlOttMS9UlMq/CCMiDEcgW4t4ZI8gHvj4A6AMAyhmgewNA84uUFwYAegAAlH4PuxsANOcFzyOhHa/nd/vltzD2sszfxsKk+hN76xaGu3TzGlFf/tt4FvTdmnHmOD7IOLOObcV8Tk0SzsfA80HHBz4CMlTr2MAngFmAdYHvAHdTMH3ysAidtqdOhleMQbh7EJ+jdLwYqDFdHzAX+Ay4FDA5i6smVdNh4LqAOU3eWK+iV/j05Bi3YKPae0FOxjzAfFXoIOD2LrLJr73+wdXL/UoNSCai9tsHjOi1SOUrVVDQgSWdUFVgdGOLLvA6m879TYGqDjmVuzsfFgcDHnvB8G20kVcnl6rRZ9hGul6KxL3N50KReOVdkCIfVvKEhds70xXK6vYfKVl4tP1fD/T/Bw== \ No newline at end of file diff --git "a/docs/cs-basics/data-structure/pictures/\346\240\221/\345\205\210\345\272\217\351\201\215\345\216\206.png" "b/docs/cs-basics/data-structure/pictures/\346\240\221/\345\205\210\345\272\217\351\201\215\345\216\206.png" new file mode 100644 index 0000000000000000000000000000000000000000..22dbf344658923a63ccb5dafe70bc7cd61f17840 Binary files /dev/null and "b/docs/cs-basics/data-structure/pictures/\346\240\221/\345\205\210\345\272\217\351\201\215\345\216\206.png" differ diff --git "a/docs/cs-basics/data-structure/pictures/\346\240\221/\345\220\216\345\272\217\351\201\215\345\216\206.drawio" "b/docs/cs-basics/data-structure/pictures/\346\240\221/\345\220\216\345\272\217\351\201\215\345\216\206.drawio" new file mode 100644 index 0000000000000000000000000000000000000000..c324e80144770d60ad69d68891ac0df8ce59bc39 --- /dev/null +++ "b/docs/cs-basics/data-structure/pictures/\346\240\221/\345\220\216\345\272\217\351\201\215\345\216\206.drawio" @@ -0,0 +1 @@ +7VvLluI2EP0aLacPlqzXEoPpLJKcySHJPHZurAZnDCLGdEN/fSQsGwtsoHmZTHNYIJVkPaqurqoKA1BnvHhMgunoNxmKGMBWuACoCyB0nBZRX1qyzCSc00wwTKLQdFoL+tGbMMKWkc6jUMysjqmUcRpNbeFATiZikFqyIEnkq93tWcb2rNNgKLYE/UEQb0u/RGE6yqQM0rX8FxENR/nMDuFZyzjIO5udzEZBKF9LIuQD1EmkTLPSeNERsVZerpfsuV5Na7GwREzSQx6I2vhvtYG/fv/jz7cvuP+9P38bfTKjvATx3GwYQBKr8bwnveR0afRA/p3rdXrPcpJ+mq2s1FYdIJ4u1o2qNNTf7XwMtZinXGiUUIwI1eqUEVXFex1FqehPg4FueVU4UrJROo5VzVHFYDbNLPscLUSoFxHFcUfGMlkNhJ6fBRkMlHyWJvKHKLWElD+1WsXkLyJJxaJWfU5hFIVmIcciTZaqi3mA5HY0QIbU1F9LsDCiUQkRuSwwQBwWI69tpQrGXO8wHaww3aaKJ2FbnwFVm8iJsNWq9p0sv5Yr38qVrt53q6gtTS2bQ4Rbp2ZDj2odcp4MxI4NIHOcg2Qo0n0Y3bZLSe+4Qu+5LBFxkEYv9nKrjGFm+CwjtZHC7DjnK2N2vGnPbJvmqfLx2xiIMPwAmQupA13qknwlZliEmd2K7FkyJW3NsgJOoZPjsYRqaWA2DSbHM0GJTDJBp5oaClk23c/BGJTajIGaZgz3Wlb2PpCVXX5jVsbXsnL3I1nZsa3s4oatTK5l5ccPZGWGb8zK9FQfbxGlX0vlb7lPp8prB09Xcv+u8AqLypW9Qvd/4RVuAAXzI71C6jAbcRRe1fFjpwKsMoho7YFLDstWCZbOTlg2ADDcJMDI5n1Djw07XLYr7KCNhh38RPSdERXkQFSgJlFBHeeBIISRy7C6wB3bmC5xHrjDuctUi0ta9EhKgmQHYtS4TSImPxaX93v8D+T3YHpjfo9TlZc81fHZfcNUOz77brImHJ9WtS2v5PkQ68ZwuH2fcOeBOphCRjHEiG0MfygF4eph8kmql3AtBoK1DKSJ5owMRPcwUDZdDQMpMkjtI2EziDkyZboxoiCOhhNVHSgECyX3NLVEgyBum4ZxFIZxHbclcj4JNZN1z8VNzOamgnRKeHcr8A4vxk31ydIzAwDdAaCN69oAQI0DoD6PemYAkDsAVg7prQGgPsV6ZgA4dwCAUkp9HYM0DACy7Y0qF7BvqkaLth5kko7kUE6C+Fcpp8Yg/4g0XZqXHoJ5KmuSK60H3FA2Ln/l4shs3MHO5mnmqEqTXiQo7H2goJDwWwsKz5asfFdu+/059HOeP3rgAWw0L8XseI3aQaHLkdXKjkxMsZ2pTAXPRhNTVbnMi/gE7t0n0OxEbswnyAe+PADwHQCaDeCtAaD+XcozAwDeAaDvLnRrAKjPDJ7mhnZ9r/fYKb9Vu9PP/GksTDZ/ZW/cwmjb4bxE3Jf/PJ6Ffdf2OXMc7/U5s45NRX2wIg3nY+D5oO0D3wUqWGs7wCdAxTG8A3wI2Kpgc/KgCJ7Wp04FWJwjtH0QH6N0NH/SYzIfcAZ8DpQzy9UsTE+qp8OAMcBhHRubVXQLTk8OoQXHrbwX1GTcA9zXhbYLWPcsm/zc7e1dvdqv0oBHV/vtAU7MWpTytSooaKOSTqgucLqyRQd47VXn3qpAdYc8Yrw5DouDJxF7weDHcCXfnFypxpxhxzX1UizurT6XicUR3GbCgvZOpEJVXf8pJQuP1n/tQf5/ \ No newline at end of file diff --git "a/docs/cs-basics/data-structure/pictures/\346\240\221/\345\220\216\345\272\217\351\201\215\345\216\206.png" "b/docs/cs-basics/data-structure/pictures/\346\240\221/\345\220\216\345\272\217\351\201\215\345\216\206.png" new file mode 100644 index 0000000000000000000000000000000000000000..e80c2e072518e016f6d7e1fa1abe30d92829cc3d Binary files /dev/null and "b/docs/cs-basics/data-structure/pictures/\346\240\221/\345\220\216\345\272\217\351\201\215\345\216\206.png" differ diff --git "a/docs/cs-basics/data-structure/pictures/\346\240\221/\345\256\214\345\205\250\344\272\214\345\217\211\346\240\221.drawio" "b/docs/cs-basics/data-structure/pictures/\346\240\221/\345\256\214\345\205\250\344\272\214\345\217\211\346\240\221.drawio" new file mode 100644 index 0000000000000000000000000000000000000000..107a75dd04374fbb4733ac93b026632b206cfeab --- /dev/null +++ "b/docs/cs-basics/data-structure/pictures/\346\240\221/\345\256\214\345\205\250\344\272\214\345\217\211\346\240\221.drawio" @@ -0,0 +1 @@ +5VpLc+I4EP41OoaynpaOPJzsZatSNYedOW0ZWwHvGMwYM8D8+m3bsrGMCQwhhAyVQ9QtoUf3p+5PDYgOZ5un1F9M/05CHSPihBtER4gQjB0B/3LNttRIRUrFJI1CM2in+BL90kbpGO0qCvXSGpglSZxFC1sZJPO5DjJL56dpsraHvSSxverCn+g9xZfAj/e1/0RhNjWnIO5O/5eOJtNqZSxU2TPzq8HmJMupHybrhop6iA7TJMnK1mwz1HFuvMou5eceD/TWG0v1PDvlA5GOgn9/JWv68PTfdumwH6Px8sHM8tOPV+bAiIgY5huMoTHJG/Dfny2gMR8vF6VcDHhJYF04VrY1thI/VknV8bAsPNmHAYQvNrvOalanmgY2XM5Ur1apGzsg1kIEDgb+B2GwnkaZ/rLwg7xnDRAE3TSbxSBhaPrLRQmKl2ijw3xvURwPkzhJi4noy4sWQQD6ZZYm33WjJ3TV2HHqxZtmrmym00xvGipj9iedzHSWbmGI6aXCQMDcAVLJ6waijGraAFOl8w2GJ/XMOzdDw3j6N7xOOrzeNvE87OfXB6R5Mte2WcEU6fZrU/jWFEb5uZ1a2hrpgrZfJqs00K+ckJpQ4acTnR3Hvw6tKLDvyYaneIenKl2qYz+Lftqxo8t9ZoXnJCouUQUUZgOF8xYCynObTzXvensi1ZrIaU1UGmZvogJN9bHPBxg9KaxcIIyQOwojTArLqZR/cBhhB728XPjz8526hxXc7c5aVy73Z3iZUOe2vMyvdZfpHd1lzG0vM/rBXhbX8jK/Iy8zzG7Ly+5bid8myr422t8qogftHevLhYr01VSxFm6NKrI/gyqKM6kid6SNUUauShXlWyHZ+RZxjgCsArLTADJ+Fci3CEl+W5Bs57SzXy9S9ohkxMWEuUwQTFuMqLv7SoBVlwLszUZEcSL86E3Bj1PVE5RyyiQH8oGxDUasegorxST0MOG450GTMfsNxtl1H9ZVWfT931zsjt5cFN8YG8ddddm3ErXX81t3WDqWR28xK1bOvJG4RB0rXWFlJzMX91zMXSJdDiFMtqY/OWXSzmmqRVjnFq4Vs8jBmHXht6W4o7clF7cWs7qKvm9n8pcnRjX372GXNx+yPaeWD8RIEJ51GoHBdGp058ez6l58Mp7FlOwpIYjCDgOqJbkNQ+H0uMvyb0g5kVxwcV5A49QmWuzaROtwcfvCQcu9o6DV/lrqo2vb+HBx+8J0Wt4Rna5/8tCuTX2Ym7uq2+e92Xv805SZjhNl1plYTkhd/CMTEJbwlFc113WlXWTnGBK50ygPnZmBsBA9Lg5WoTilPUZ3u7gyp36PSv7VkLkHuONQ5Z8BmZRdBZntcsVe7f+dwSc6wOdxNPBQ30MeQ4NH1MfIEwjSvRoijyBZNGy6FNSI2SVPQJVSlO7n06com67G+ZzSQ0oiTyHpIgWryHzRfDmOpESKHGJTZhejOjOnp2R3zDqzOyymBkh5eaPPkBxd5JDPo8eju4fzggWANObnfURKmL2A8XNTuKhPGzZx84ZyC18M0aBfDH4sGm4+oMq4jagBOT6zQ4V9wU0oaUYDo/LjaDIHMYDrnj+PBjljiAI/7puOWRSG8SEWkyareZhzliLYxP5YxwM/+D4p9O3FwTTmp6KQw0q5EYAGxd+FSoPuccpa851mSCG/T2ZA3P0ctLysux/VUu9/ \ No newline at end of file diff --git "a/docs/cs-basics/data-structure/pictures/\346\240\221/\345\256\214\345\205\250\344\272\214\345\217\211\346\240\221.png" "b/docs/cs-basics/data-structure/pictures/\346\240\221/\345\256\214\345\205\250\344\272\214\345\217\211\346\240\221.png" new file mode 100644 index 0000000000000000000000000000000000000000..784f057f164d3f77eba0cb31bf137fc9bf06304c Binary files /dev/null and "b/docs/cs-basics/data-structure/pictures/\346\240\221/\345\256\214\345\205\250\344\272\214\345\217\211\346\240\221.png" differ diff --git "a/docs/cs-basics/data-structure/pictures/\346\240\221/\345\271\263\350\241\241\344\272\214\345\217\211\346\240\221.drawio" "b/docs/cs-basics/data-structure/pictures/\346\240\221/\345\271\263\350\241\241\344\272\214\345\217\211\346\240\221.drawio" new file mode 100644 index 0000000000000000000000000000000000000000..11133b532ad662decfd4aa5af81e1e29b3930534 --- /dev/null +++ "b/docs/cs-basics/data-structure/pictures/\346\240\221/\345\271\263\350\241\241\344\272\214\345\217\211\346\240\221.drawio" @@ -0,0 +1 @@ +7VnJdpswFP0aL+OjiWmZOEm7SIdzsmjSHQbZcAqIynKM+/UVRmIysR2SYKfuCr0r8TTcq6eHGOFJnH3ibhp8YT6NRgj42QhfjxCCEJjykSPrAnEcqwDmPPRVowq4D/9QBQKFLkOfLhoNBWORCNMm6LEkoZ5oYC7nbNVsNmNRs9fUndMt4N5zo230R+iLoEBtZFX4ZxrOA90zNJ2iJnZ1YzWTReD6bFWD8M0ITzhjoijF2YRG+eLpdSneu32mthwYp4k45IU7eumBOPrJb52v09m3AKzusgvl5cmNlmrCI2RG0t/VVBbmeUE+3TiVhWS6SAt702DGZL9yWmKt1sr8vWS64mKxYfJSNkBGmlWV2ivQbuSAC09lbxqujQA1OkJyYpJ/aVytglDQ+9T18pqVlKDEAhFH0oKy6C7SQhSzMKN+PrYwiiYsYnzjCM9m1PQ8iS8EZ79orca3nCkAZedPlAuaPbvysORTbgTKYir4WjZRL2BTSUDtAaTtVU1RCgpqYtKYqzQ8Lz1XNMuCYvoFrKMO1ttLnPiX+faRVsIS2lxWOW++fqgbj3XjOp83KK21svquPfW3tmhr5eXI2ZJ7dMeUsYodLp9TsW9DbDNZY8roYEpjnEauCJ+aw+2iT/XwnYWbTaSFQppCMYyWAoppqrfqe73tyGk5Ai1HxTpsOdqoqZx2f4Hhg8LKG4QRdEZhhLTUUarlWGGEPMvyInWT/qRuaQV201liRXf/BsslXafCsjHUXsZntJcRaLJM0JFZNodi2Tgjlg10Yixbr038slA81MqPOtGT5Srryw2d9JWpYmmcfKpIPmSqaPZMFQ1gNzVK0KCpov1aSXZ+i4A9AtNCBjUhw51C/hCSNI4pSdI+00hPSRJsj5FNkAURsYiJIG5lRN3VAwnWeRfBnnRENA+UHz6q/Bw8NjE2pDzkuYvKm0etRuCMHeg4xEYQEhNYPbXZErmBh/2y1vei7//RRc7oo6t9Q3f0RA12Xcy+NlPbfcB1Z2r7DtIPcSxC0M3+QKma0TivoNM8zUw4tqBhIdsyZDSxW+4PvvGzO93oTnDnEIaKWWiomGWeUcxqXxSVd7xHi1ldt77/Y1b3ddr+mIVON2YRuDOcvE3MImRnYOwds6RZ/XQtmle/rvHNXw== \ No newline at end of file diff --git "a/docs/cs-basics/data-structure/pictures/\346\240\221/\345\271\263\350\241\241\344\272\214\345\217\211\346\240\221.png" "b/docs/cs-basics/data-structure/pictures/\346\240\221/\345\271\263\350\241\241\344\272\214\345\217\211\346\240\221.png" new file mode 100644 index 0000000000000000000000000000000000000000..4cf2630147359ba9ca29eefd96a5731f8ea2d1d6 Binary files /dev/null and "b/docs/cs-basics/data-structure/pictures/\346\240\221/\345\271\263\350\241\241\344\272\214\345\217\211\346\240\221.png" differ diff --git "a/docs/cs-basics/data-structure/pictures/\346\240\221/\346\226\234\346\240\221.drawio" "b/docs/cs-basics/data-structure/pictures/\346\240\221/\346\226\234\346\240\221.drawio" new file mode 100644 index 0000000000000000000000000000000000000000..6eeaa610144239f439b47f65c6ed6ed76c65413d --- /dev/null +++ "b/docs/cs-basics/data-structure/pictures/\346\240\221/\346\226\234\346\240\221.drawio" @@ -0,0 +1 @@ +5VhNc9owEP01HMnY+rCtY0LSdibNTKc5NOnN2AJ7KixXiGD667vGsi0bSGlKcTI5sfskrbT73grBCE8WxUcV5smdjLkYIScuRvh6hJDrOh58lMimQhjzK2Cu0thMaoH79Bc3oGPQVRrzZWeillLoNO+CkcwyHukOFiol191pMym6u+bhnO8A91EodtFvaayTCg2Q3+KfeDpP6p1dj1Uji7CebDJZJmEs1xaEb0Z4oqTUlbUoJlyUxavrUq37cGC0OZjimT5mwfT2s7i+U1/V7ePDOLv8TokYj02Up1CsTMIj5AmIdzUFY14a8BkucjCy6TKv/O2EmYR9IS29MbXyfq5kPTBebpm8hAmI5kU7WEd16jBw4CpSs1sNWydAnY0QJAb8g3O1TlLN7/MwKkfWIEHAEr0Q4Llghsu8EsUsLXhcni0VYiKFVNtAeDbjXhQBvtRK/uDWSOyzqeM0mz9xpXlxsPJuwyc0ApcLrtUGppgFxDcSMD2AqPHXlqIMlFhiqrHQaHjeRG5pBsMw/Resoz2s90ucxZdl+4CXyYx3ywp5q82D7TzaznWZt9N4G+O9tPY83mnRXuXh5HKlIv5MytjcHaGac/2nhthl0mKK7mGqxhQXoU6fusfdR5/Z4YtMt01UC4V2hUJxTwFVmmaV3eu9QNTpBiJ9KVV12Am0VVOT9ssFho+6Vk5wjbjv6BqhPXVgPPA1Qg6y/G+k7mgF7afzAPNvm2UP91rXHZhleq5exu+ol323xzIbmGXvXCyT98Qy632f+wOz7A/y8ONFqh8s+9Gy2yWl8yqeiuTIpyJ+VU9FcqqnIjvvUzE4lSQdW5LOkZJ0LUm6b1+SdEhJUoYvPIwpJgGF2991u69Vn10wlzESwAjxHP+FciXBBQoIfIHCz2riod4mqDeKz6plNsj1OqgyvbegTM95VpnBaZRJn1Um/k/KBLf9D7Ga3v4Ti29+Aw== \ No newline at end of file diff --git "a/docs/cs-basics/data-structure/pictures/\346\240\221/\346\226\234\346\240\221.png" "b/docs/cs-basics/data-structure/pictures/\346\240\221/\346\226\234\346\240\221.png" new file mode 100644 index 0000000000000000000000000000000000000000..273588b98673fbf34e427b5928cfc0ae604db6a2 Binary files /dev/null and "b/docs/cs-basics/data-structure/pictures/\346\240\221/\346\226\234\346\240\221.png" differ diff --git "a/docs/cs-basics/data-structure/pictures/\346\240\221/\346\273\241\344\272\214\345\217\211\346\240\221.drawio" "b/docs/cs-basics/data-structure/pictures/\346\240\221/\346\273\241\344\272\214\345\217\211\346\240\221.drawio" new file mode 100644 index 0000000000000000000000000000000000000000..8379028d2a9a84c94199755c75e3f9c191338da6 --- /dev/null +++ "b/docs/cs-basics/data-structure/pictures/\346\240\221/\346\273\241\344\272\214\345\217\211\346\240\221.drawio" @@ -0,0 +1 @@ +5VnLcpswFP0aL+PRG1gmTpq2M5nJTBZNuiNGNkwxogLHOF9fYSSMME5c2/WjXqF7JK4e5+jqCnp4MCnupZ+GDyLgcQ+BoOjh2x5CEAKmHiUyrxDPcypgLKNAN1oCT9E71yDQ6DQKeGY1zIWI8yi1waFIEj7MLcyXUszsZiMR272m/pivAE9DP15Ff0RBHlaoi5wl/pVH49D0DJlX1Ux801jPJAv9QMwaEL7r4YEUIq9Kk2LA43LxzLpU731ZU1sPTPIk3+SFZ4cW19/kzzALJmPy8P39HlxdaS9vfjzVE+4hFit/N6+qMC4L6ulPUlVIXrO0shcNRkL1q6aVz/Vasd9TYSqusgWT16oBommxrDRegXGjBlx5qnszcGMEyOoIqYkp/pVxMwujnD+l/rCsmSkJKizMJ7GyoCr6WVqJYhQVPCjHFsXxQMRCLhzh0Yiz4VDhWS7FL96oCRzvFYC68zcuc16sXXlY86k2AhcTnsu5aqJfwExLQO8BZOxZQ1EaChtiMpivNTyuPS9pVgXN9F+wjjpYby9xElyX20dZiUi4vaxq3nL+3DRemsZtOW9QW3Ntbbv2PFjZoq2VVyMXUznkH0wZ69jhyzHPP9sQq0w2mKIdTBlM8tjPozd7uF306R4eRbTYREYoxBYKpS0FVNPUbzX3etuR13IEWo6qdVhxtFBTPe3tBYY3Cit7CCPogsIIcZlFKqZHDiNkLctZ6ifbk7qiFdhNZ41V3f0fLCMMTotleqi9jC9oL0Nqs0zwkVlmh2KZXhDLBJLTYtnZNfErovy5UX4xiZ4qL7O+0jBJX50q1sbJp4rkLFNFtmWqSIFra5Sgg6aK7q6S7LyLgE8EZoQMGkKGHwr5LCRJjyrJ9pm29e3FdfvIJciBiDiEIYhbGVF39YEE6+1LsOcTEdmG8sPHlB/FXp9hTDFxqUo+ILTFCL2+Bz2PuKqGMOBsJ01C7DsYJYe9WJvPov/+zkUu6M6F4Yll47Dru+yuidrH51t3WPrsHD2LUxGCbvYPdCwC67iCnn2YObDvQOog16EqhLkt9xsfmbjTjemEdA7hUDFr/XeiPd8t2QXdLSk7tZjV9Qlh90x+/4lRnfv3oUObF9k+qO01MVIZj1xGasG41Nge4xncNKAdNc8intv3GEMeBESlWi61ZchAnzqk/ENKkUsZZdsFNIrtRIvsLdFS5vKna9V8+esa3/0B \ No newline at end of file diff --git "a/docs/cs-basics/data-structure/pictures/\346\240\221/\346\273\241\344\272\214\345\217\211\346\240\221.png" "b/docs/cs-basics/data-structure/pictures/\346\240\221/\346\273\241\344\272\214\345\217\211\346\240\221.png" new file mode 100644 index 0000000000000000000000000000000000000000..429ab1cab531c4e88512394157a5266f41566144 Binary files /dev/null and "b/docs/cs-basics/data-structure/pictures/\346\240\221/\346\273\241\344\272\214\345\217\211\346\240\221.png" differ diff --git "a/docs/cs-basics/data-structure/pictures/\346\240\221/\351\223\276\345\274\217\345\255\230\345\202\250\344\272\214\345\217\211\346\240\221.drawio" "b/docs/cs-basics/data-structure/pictures/\346\240\221/\351\223\276\345\274\217\345\255\230\345\202\250\344\272\214\345\217\211\346\240\221.drawio" new file mode 100644 index 0000000000000000000000000000000000000000..37585459182161ebafa19d63f94eef4a1ba9e6c7 --- /dev/null +++ "b/docs/cs-basics/data-structure/pictures/\346\240\221/\351\223\276\345\274\217\345\255\230\345\202\250\344\272\214\345\217\211\346\240\221.drawio" @@ -0,0 +1 @@ +7Zxbb9owFMc/DY+bcg95LPQyaUya2kntHl1iiFcTZ8bc+ul3HBxIloXCgMQPFkjEx5fE/h38z3EMPXc4Wz9wlCXfWIxpz7Hidc+97TmObVsBfEjLZmuJonBrmHISq0J7wxN5x8poKeuCxHheKSgYo4JkVeOYpSkei4oNcc5W1WITRqtnzdAU1wxPY0Tr1mcSi2Rr7Tvh3v4Fk2lSnNkOom3ODBWFVU/mCYrZqmRy73rukDMmtkez9RBTOXjFuGzr3Tfk7i6M41QcU2HgfX9xfi98h44e3r/es+dF9PbJUdcmNkWHcQz9V8mUpfAx4GyRxlg2Y0GKcZGwKUsRHTGWgdEG4y8sxEbRQwvBwJSIGVW5cIV88yLrf/aL5E/VXJ64XVdSG5WaC87e8JBRxvOLcy0rCPw+5ExYKkp2fyhfYN92R/ahcZSUac4WfIwPDU1fuRviUywOFfR2NOFrgNkMQx+gIscUCbKsXglS/jjdldsjgwNF7QSCriF4NkE76JKgZwge/modQbDfJUDfADwboOt0STAwBA/PjcdMop0SDA3BswmWbks7IKjEeonoQp3pFglUwwq30Zk8FOhVmsp0VgkR+ClD+WisIB7JRx5xoXh6EgUECgKRFHNVacwoRdmc5K3lsMYJofEIbdhCFOcpUjmuwqlkbUTJNIXjMVCRTQ6WmAsC4cONypiROM6vc0IoLYF27KF145/hGvJEeH3YOeooVQWvCK9UVOb1VXq1j3HsInBJSvFNaF2JftQIGnolCKKPEN2hdHoM8zrSmLPsR+H+0pAxIoHdLWHA5spWJqQmDJHPCzKT4klR95UJwWYqwdXY7BrNB8YfwBuGaijnCR96M4S0vU/DWxbnwDcFBwB/lG1gNBcrPBfX84pT7p0K1zjSM9xreUbhqqWJYSRhXNJf8rUDtPeXs12BAYgJzcP9BGYAnLbMNPo30xLEoFWGdo3hY35aA/F0iOsqwM6YOkawWxPsMNRNsO36wpNR7JYmhqZQSxvJ9oxknw7V1UyzfaPZl6Ooi2gHRrRbE+3+X6Ltel7Xol1fJjOi3dbM0PCQSRvRri/AGdH+EGqomWhHRrQvR1ET0XbqK2BGtK8l2pF2kfbuQY8R7dZFu+mRmC6i7dQX4Yxofwi1YQbobH53jWhfjqIuol1fAzOifS3R9m3dIm2nvinMiHZbM0PDhlxtRLu+CGdE+0OovmaiHRrRvhxFXUTbbEJrT7SDqCrau1/KdCfaZhdad6Kt+Ta0omEj2qdA1Wwfmmv2oV2Qoiai7dbXwIxoX020tds57pqNaJ2JdtOvtrQRbbMR7T+garYRzTUb0S5I8eqiDcn9nxrkeaW/hnDv/gA= \ No newline at end of file diff --git "a/docs/cs-basics/data-structure/pictures/\346\240\221/\351\223\276\345\274\217\345\255\230\345\202\250\344\272\214\345\217\211\346\240\221.png" "b/docs/cs-basics/data-structure/pictures/\346\240\221/\351\223\276\345\274\217\345\255\230\345\202\250\344\272\214\345\217\211\346\240\221.png" new file mode 100644 index 0000000000000000000000000000000000000000..2ce05c64ae09be80a5b0be25e99aad059dec5bbf Binary files /dev/null and "b/docs/cs-basics/data-structure/pictures/\346\240\221/\351\223\276\345\274\217\345\255\230\345\202\250\344\272\214\345\217\211\346\240\221.png" differ diff --git "a/docs/cs-basics/data-structure/pictures/\346\240\221/\351\241\272\345\272\217\345\255\230\345\202\250.drawio" "b/docs/cs-basics/data-structure/pictures/\346\240\221/\351\241\272\345\272\217\345\255\230\345\202\250.drawio" new file mode 100644 index 0000000000000000000000000000000000000000..1ddbb02dc6e39e25e35caa8e9ebd47eb3a26e5de --- /dev/null +++ "b/docs/cs-basics/data-structure/pictures/\346\240\221/\351\241\272\345\272\217\345\255\230\345\202\250.drawio" @@ -0,0 +1 @@ +7V1dc5s4FP01PDYDSAh49FfSh3amu+nMto8yyDYtRi6WE3t//UogMGCwiSHgjZlkJuiCJXHP0dXVMSgKmKz3TyHerL5Sl/iKrrp7BUwVXdc0FfE/wnKILbZtxoZl6LnyoqPh2fuXSKMqrTvPJdvchYxSn3mbvNGhQUAclrPhMKSv+csW1M+3usFLcmJ4drB/av3Hc9kqtlq6ebR/Jt5ylbSsITs+s8bJxfJOtivs0teMCcwUMAkpZfHRej8hvnBe4pf4c48VZ9OOhSRgdT7w9OMPePm6oQxPv88OwRr9+uvwSY9recH+Tt6woiOf1zeeiy6zg/QD+rMT/RwvaMA+bSOURvwC3djsjyf50VL8HSV18M7ME6N0QlqjznvHQeSF8evKY+R5gx1x5pXziNtWbO3zksYP8XYTI7vw9sQVnfB8f0J9GkYVgcWCIMfh9i0L6W+SOeOa9lxV08ZfSMjIvtJ9WgoKZzOha8LCA79EfsBMcJREBglDXzO0kKZVhhGJDUsiLtOaj1jxAwnXG6ADJdAVXRy4IzEGeCmgAcm7ld93ePiRLfzMFqbivtW0dJCluA3inoyagh95P+gudMiZG4ByOONwSdgljp7ikvG7UeL3xBYSHzPvJd/dMjBkC9+ox28khR0l8UrCjvQCnvFtyk9lh1+hItMyHnQL6qamQxOipCcJm2wrfxbkW4mddNJKRJzUJ9dzCVaGge0GB9dHgkwwiQ2T8tCQ2uLmPkbEsMx8xIB9RwyjK5THd4SyYd8YyqgrlKf3hLJWQNnuGWWzK5Sf7ghl27gxlK2mOd7eYz8yxz+TnI4fHxM8UUjyuzQrTAsdZ4XG/yIrLBAFgSuzQkuzchUZmt5p4mc3JVjpIkK9QJeElmqGltpZWvZAMNQnwczCfJPOP29edkDrzLIDar0uO5Kbupp+LdLCrEkL2CctLE17QAAYAFoGn8G1PJqGqj3Ymm1Di5+BSDWvjEk6OkMZQ1V7pYzWVeIzu6PEBxWXqn0nPsk02Grmc36KKc98Lk1lPUxMWgWWHaU+KDdlaHaeOEB7MDXD1C3T0A1gFaqvG4KQXVpN0oha2oWuIlCZ8PouEejzHUUgCAoJj9l3BCrTRK+JQPWT3OuS6RYjEKobgcANRyDrbHBoJwIZ2tkw994RqFrIFYGmxQikXYhAcXMVEYgHA5YfEvkIIodMNtxIE/a9ZcCLDmcw4faxCC2eg/2RPLH2XNevim0h3QWuiGTTtrIjKx+bgH4am2AJ34tfFbUXm6o13pYJoA8EEMMdFtLj3glQLf+2TAAwEEBkGfqtEaBMGX4XAsCBAALcwgLZUPsmQJly+y4EMAYCKBmF/1YIkFT8/gSwBgIop98AGyUSWbcEKFNCC97frvBGHDI89wvL0zKnbfnChclnMIXbHI4s9gLh/egzDvV9vNl6UWXxFSvPd7/gA92xpJmkVNQRXEysRamOgByLzBdtBWqUgwkh4wQmpHYpJCSw1MGJ3yfzsP83cRgOlnUgO4XEDenme7KCF4aNWIeScPbCXbiVtpLxxuhGnvTJIvnsnDJG17IQSm+llUauMsb8lztvoj4YisHvZsLL2rHMf8XlIZvQgEOPvQhIgrfslWxZXdTPDIGzOkQp1vDdsK7WBmsHZbVWUPZ4dNs3CcxNKBc9ao2PlGvMJsrRX/iRkLbiUZ0EzWih16BFl6yofryyZVaoAyPexIh9ng29EaQFQa8eQRoJevdLEK1kvd8tQ1pQ/OoxpJHid8cMsfpmSAuSYD2GNJIE75chKfS9MaQFzbAeQxpphvfLEFCiKXXLkBZExXoMaSQq3jFD+s5UQQuqYz2GoIEh1zCk7JupbhlS/YBmywwxB4ZcxZC+M1VQJoi+C0MafXNxvwwx+s5UQY132wfJvFXJ/JCHtDcFHXSmlcYtDAGiegDejoIOygTSAY4bka9BZ+Jkxc4yw3g9T5De5WvQmTg5HhhyFUN6XxR0Jk5e2oJmYMhtytegM3FyOjDkGob0Ll/DzsTJS+8GDwy5TfkadiZOPg4MuYYhvcvXsDNx8tLGSgNDblO+htXPeJ7A2IwynyvZUGN71ftlSO/yNYQnaIjXs59lUXow/4YCDdmKLmmA/S80cq1A5xdh7CCfx8c7RvPYHTeseDCUfjbrksHy2s26ar8I3gyOzva9vDTpf6QNG8zivpd9bxkDy1TIoo9r7WWmvmU0vX2LvRbHH6y7Z0yvu1bZ+b0UzPyGDQYAZWffumGDfX6jM7vXXatgZ+9rN3ps5sO8rGeifHDq/W1N2Nn72o2eivkwBLD1GyOAUaJNzQxlPFNGM2UGFZ47jDRlhhQ+jdoTZaYrVnSQJ4mTzuVHHvD53rZFSlykxpPHVru5qNOaKbalzGzFMhWbt2KJRkVzhmJZiq1X0UP2ItVD52EdomqwlKi8MXus2DNxMIKKNW3lJr9NHy/2nt8v9wAfGeJ+HxUbyb5w5wtXmMoIZHxiigPbjLCYKONRdPFjdGCKC5IE5uaGjY/nxB9j5/cyshcb566RSwkNynImNRxHP+0MPlTYLgWVDL50pDUcfbx4/Bcq8XR9/Ec0YPYf \ No newline at end of file diff --git "a/docs/cs-basics/data-structure/pictures/\346\240\221/\351\241\272\345\272\217\345\255\230\345\202\250.png" "b/docs/cs-basics/data-structure/pictures/\346\240\221/\351\241\272\345\272\217\345\255\230\345\202\250.png" new file mode 100644 index 0000000000000000000000000000000000000000..883e9bc5b938e55bf15081dd407e5292985e324a Binary files /dev/null and "b/docs/cs-basics/data-structure/pictures/\346\240\221/\351\241\272\345\272\217\345\255\230\345\202\250.png" differ diff --git "a/docs/cs-basics/data-structure/pictures/\346\240\221/\351\241\272\345\272\217\345\255\230\345\202\2502.drawio" "b/docs/cs-basics/data-structure/pictures/\346\240\221/\351\241\272\345\272\217\345\255\230\345\202\2502.drawio" new file mode 100644 index 0000000000000000000000000000000000000000..8048a1a724c6a244504718b929e00b01152c3710 --- /dev/null +++ "b/docs/cs-basics/data-structure/pictures/\346\240\221/\351\241\272\345\272\217\345\255\230\345\202\2502.drawio" @@ -0,0 +1 @@ +7V1dc5s4FP01PDaDAPHxaDtOOp12p7PZ2W32ZUc2ss2WWC6WE3t//UogMGBhE4OBFqaZKbrCCO45ulwdybKiT172jwHarL4QF/uKprp7Rb9XNA0A1WT/ccshsjiOFRmWgeeKk46GJ+8/LIyqsO48F28zJ1JCfOptssY5Wa/xnGZsKAjIW/a0BfGzrW7QEp8YnubIP7X+5bl0FVltzTraP2JvuYpbBqYT1byg+GTxJNsVcslbyqRPFX0SEEKjo5f9BPvcebFfos89FNQmNxbgNS3zgd/G33/s9s92oH3Bn/w9/DH+MvsgrvKK/J14YEUzfXa98YzfMj0IP5g/dvw+xwuyph+2IUojdoIGN/tjJTta8v9H8TXYzcxio3BCckWN3R0DkRXGbyuP4qcNmvOaN8YjZlvRF5+VADtE202E7MLbY5ffhOf7E+KTILyQvlhgcz5n9i0NyHecqnEtZ6aqSeNpX8UPjgOK9ymT8N0jJi+YBgd2iqi1ocBREFmPcX1L0UKYVilGxDYkiLhMrnzEih0IuN4BnSaBLu/itTvifYCV1mSNs25lrggO39KF53Thnj+3mpQOolToyS3ZBXN85n510XtRsMT0MiWxm+mYp7ik/A4lfo9tAfYR9V6z3VkGhmjhK/HYkx1hj3u6gN3Uc3hGzy0+le5+uQs5AN5ptqFZQDMsw4zvRFzWUO1srZ5tJfLaSSshcRKfXM8lvTAMbDdofX0kSAWTyDCRh4bEFjX3a0QMoKrZkGG0HTKMpmAe9whmS+sYyrAplO97hLJpZFGGassom02h/NAjlIFqdwxmq2qWt/fot9Txc5zVseNjiscLcYaX5IVJ4bZ5ofFT5oVWjihJfHh3XmjYWcbFCDeU+tlVCSYdRqgX6BLTUk3REpyl5e0JBjtFMDv/wtGuJJht2ecGHlqrAw+nIvuuZ4VZkhV6p1jhGODO1HWoGzYjhAayYEIA7hzgsJDCagxTta4MSdA8wxgI1DYZEwuDt098HnuU+OQHMdBuOe8BMmWyauJz/g0jT3wuvcmuj0CwbOKjdioEWU7mjQGc7PuEBSgLQIu9dqAGdTt3+dIvLU16mbgRIL2FpiKQ1lQE+tijCHSilrUfgmSq6K8VguKofzkGaT9TDJLX1huDoLy2qRhULOXyUFNjDAIXYlDUXEEMYn2fZvtENoaIPpMOOMKEfG+5ZsU54zRm9jGPJN4c+SNR8eK5rl8U3QKyW7s8lp3vH++Y/QPZ4KTrp8HJkPA9P2irLzgVq7w1E0AbCMBqTCun8rdOgGIBuGYC6AMBFD4o7hoBZNLwTQhgDATgESCfn4K2CSCTbm9CAGcgACdAXvKXzA01SwDnxNk8P38SReHFrB9IQFdkSdbI/0zIRgDyL6b0INbeoR0lilzhV++g0siUULzQr64podKjjWoLshpTJqc90gWcvDLZ9oysVlmZvGqC9f0Tudf3v9KyQLcmRwDIjsmtrCwADV1W+15ZAKhnJ9QYP9ucHonJePukwBySAh5mnI5lhVrxWs6aCWANBAjDAewaA5rTBgdpIExRzI4NDDSZOJjz/naFNvyQopmfS1BkTtuy9xYVQwTutjlDFnlr7v3wM3Pi+2iz9cKLRWesPN/9jA5kR+Nm4lI+k3QRthfSTNKc23i2qAemRLERMFmSjuqojaaSMg2vACf26NRD/u8sJUfrZRnITiFxA7L5I87puGHD0xAcTF+ZV7fCJulvNBwp8kofL+LPzgil5EUUAuGt5KKhq+CY/THnTfjIEbKnmbAyOJbZHz89oBOyZtAjL8QWoy19w1sqRf083y9z4RLW+WV89WFdg1ynlorKHotu+yqBuQrlwm/hoSPlKrOJMFAXfjiUWrGojtfvoIV5DS3MRllRg4ZXjhXqwIh3MWKfZUNrBJGtkLwJQSpN9PaXIEDydZ9GGRJnNbdniDYw5CqGSBYyNcuQ4m9518yQSuPB/jIkgb41htSgGpZjSKW55P4yRJdICs0ypAZZsRxD4MCQqxjSdqaq1yA7lmNIpZmH/jJE9sX0ZhlSw5rFcgypNDXRY4a0nqnWsKixHEPsgSHXMAS2nqkWy6iz6+lRsMBtgD2/9rE12It10gqwgwJRdMA9xr31pLJY/qyCe4HWOeCe/zpwW7gbxaJmFdwLFMwB9/yuJq3hXnVDSjnuBbrkgHt+s5HWcJcJkDXCM6yEOIH+kIW0tYURRmPKYtTCMO479rbuLowwZGriAEdHViUYjSl5BXtJD/2146sSjMaUvPHAkKsY0nqq39iCyEubTg8M6eaqBKOxxZH3A0OuYUjrqxKMEvtH9hiettNEWKzilf5GdLkOXOkb0f1lSOtLAmCx3lczQyptY95jhrSdJsIbK4M/Nzytz8fDGn46plwHrrQdb38Z0vrUPTQGNLozoQ7hgEZ3prmhOaDRnclnWKxI1fwuq7Sxc38Z0uQ0NWtt/s/u9dMfSH3Wta+Pf/+528h+LnMKFTb6HE2VqaGwQcYIKFNTcVTFmShTTbHDg6xoNU+2NzjyRF8sHId/xyJPnUePrnYzfk17qji2MnUU21Ic1orNG+XNQcW2FUdTCuQqcReJxDULyhAZGFIis8acseJM+cHIUOz7Wh7y6/3Dxbtnz8s8MLbC531QHFPcC3M+d4WljPSUTyx+4FghFhNlPApPfggPLH5CHGo6tx2Jj2bYH6P592VozzfOXCM24QCGKKd2yxiH/5IeeNKxJBtoXI7G8aYmkswl2cGk4q4mrHj8HdxoJ6zjrwnr0/8B \ No newline at end of file diff --git "a/docs/cs-basics/data-structure/pictures/\346\240\221/\351\241\272\345\272\217\345\255\230\345\202\2502.png" "b/docs/cs-basics/data-structure/pictures/\346\240\221/\351\241\272\345\272\217\345\255\230\345\202\2502.png" new file mode 100644 index 0000000000000000000000000000000000000000..c59574ed918fc24071226b06aeeecb079e642729 Binary files /dev/null and "b/docs/cs-basics/data-structure/pictures/\346\240\221/\351\241\272\345\272\217\345\255\230\345\202\2502.png" differ diff --git "a/docs/cs-basics/data-structure/pictures/\347\272\277\346\200\247\346\225\260\346\215\256\347\273\223\346\236\204/\345\215\225\351\223\276\350\241\2502.png" "b/docs/cs-basics/data-structure/pictures/\347\272\277\346\200\247\346\225\260\346\215\256\347\273\223\346\236\204/\345\215\225\351\223\276\350\241\2502.png" new file mode 100644 index 0000000000000000000000000000000000000000..1fe9f712584aca6e65c50d0fcad4864704b48be9 Binary files /dev/null and "b/docs/cs-basics/data-structure/pictures/\347\272\277\346\200\247\346\225\260\346\215\256\347\273\223\346\236\204/\345\215\225\351\223\276\350\241\2502.png" differ diff --git "a/docs/cs-basics/data-structure/pictures/\347\272\277\346\200\247\346\225\260\346\215\256\347\273\223\346\236\204/\345\217\214\345\220\221\345\276\252\347\216\257\351\223\276\350\241\250.png" "b/docs/cs-basics/data-structure/pictures/\347\272\277\346\200\247\346\225\260\346\215\256\347\273\223\346\236\204/\345\217\214\345\220\221\345\276\252\347\216\257\351\223\276\350\241\250.png" new file mode 100644 index 0000000000000000000000000000000000000000..a10587da1382671fb5c4fead07a8674785379188 Binary files /dev/null and "b/docs/cs-basics/data-structure/pictures/\347\272\277\346\200\247\346\225\260\346\215\256\347\273\223\346\236\204/\345\217\214\345\220\221\345\276\252\347\216\257\351\223\276\350\241\250.png" differ diff --git "a/docs/cs-basics/data-structure/pictures/\347\272\277\346\200\247\346\225\260\346\215\256\347\273\223\346\236\204/\345\217\214\345\220\221\351\223\276\350\241\250.png" "b/docs/cs-basics/data-structure/pictures/\347\272\277\346\200\247\346\225\260\346\215\256\347\273\223\346\236\204/\345\217\214\345\220\221\351\223\276\350\241\250.png" new file mode 100644 index 0000000000000000000000000000000000000000..bf1fe71bff796ce102cf0b4f9a0a47031b811f23 Binary files /dev/null and "b/docs/cs-basics/data-structure/pictures/\347\272\277\346\200\247\346\225\260\346\215\256\347\273\223\346\236\204/\345\217\214\345\220\221\351\223\276\350\241\250.png" differ diff --git "a/docs/cs-basics/data-structure/pictures/\347\272\277\346\200\247\346\225\260\346\215\256\347\273\223\346\236\204/\345\276\252\347\216\257\351\230\237\345\210\227-\345\240\206\346\273\241.png" "b/docs/cs-basics/data-structure/pictures/\347\272\277\346\200\247\346\225\260\346\215\256\347\273\223\346\236\204/\345\276\252\347\216\257\351\230\237\345\210\227-\345\240\206\346\273\241.png" new file mode 100644 index 0000000000000000000000000000000000000000..23cf43107dce669edb6e3c421e80354064b44dbf Binary files /dev/null and "b/docs/cs-basics/data-structure/pictures/\347\272\277\346\200\247\346\225\260\346\215\256\347\273\223\346\236\204/\345\276\252\347\216\257\351\230\237\345\210\227-\345\240\206\346\273\241.png" differ diff --git "a/docs/cs-basics/data-structure/pictures/\347\272\277\346\200\247\346\225\260\346\215\256\347\273\223\346\236\204/\346\225\260\347\273\204.png" "b/docs/cs-basics/data-structure/pictures/\347\272\277\346\200\247\346\225\260\346\215\256\347\273\223\346\236\204/\346\225\260\347\273\204.png" new file mode 100644 index 0000000000000000000000000000000000000000..663ab2e9bcd0d732cbc5102193374ec24bd3da04 Binary files /dev/null and "b/docs/cs-basics/data-structure/pictures/\347\272\277\346\200\247\346\225\260\346\215\256\347\273\223\346\236\204/\346\225\260\347\273\204.png" differ diff --git "a/docs/cs-basics/data-structure/pictures/\347\272\277\346\200\247\346\225\260\346\215\256\347\273\223\346\236\204/\346\240\210.png" "b/docs/cs-basics/data-structure/pictures/\347\272\277\346\200\247\346\225\260\346\215\256\347\273\223\346\236\204/\346\240\210.png" new file mode 100644 index 0000000000000000000000000000000000000000..c1b36ef62d09ec8890eb4b36f09808fb384c6b47 Binary files /dev/null and "b/docs/cs-basics/data-structure/pictures/\347\272\277\346\200\247\346\225\260\346\215\256\347\273\223\346\236\204/\346\240\210.png" differ diff --git "a/docs/cs-basics/data-structure/pictures/\347\272\277\346\200\247\346\225\260\346\215\256\347\273\223\346\236\204/\346\240\210\345\256\236\347\216\260\346\265\217\350\247\210\345\231\250\345\200\222\351\200\200\345\222\214\345\211\215\350\277\233.drawio" "b/docs/cs-basics/data-structure/pictures/\347\272\277\346\200\247\346\225\260\346\215\256\347\273\223\346\236\204/\346\240\210\345\256\236\347\216\260\346\265\217\350\247\210\345\231\250\345\200\222\351\200\200\345\222\214\345\211\215\350\277\233.drawio" new file mode 100644 index 0000000000000000000000000000000000000000..25a0512ed99ec34122e1dadc14445f70a4f0b82d --- /dev/null +++ "b/docs/cs-basics/data-structure/pictures/\347\272\277\346\200\247\346\225\260\346\215\256\347\273\223\346\236\204/\346\240\210\345\256\236\347\216\260\346\265\217\350\247\210\345\231\250\345\200\222\351\200\200\345\222\214\345\211\215\350\277\233.drawio" @@ -0,0 +1 @@ +7Vpbc6M2FP41PCbDHfNobCedTne60+xMm77JIGN1BaJCvu2vrwTiToLt4Mt0sw8bdJCOpO87+o4koxizaP9MQbL+QgKIFV0N9ooxV3Rd01Sb/xGWQ25xVTU3hBQFslJleEE/oDQW1TYogGmjIiMEM5Q0jT6JY+izhg1QSnbNaiuCm70mIIQdw4sPcNf6JwrYOrdOdKey/wJRuC561mw3fxOBorKcSboGAdnVTMZCMWaUEJY/RfsZxAK8Ape83dMbb8uBURizYxq8vk42//y9/DZPbY8eovTLD8d6kF62AG/khOVg2aFAYLdGDL4kwBflHWdZMbw1izAvafwRpEmO+wrtIe/KWyGMZwQTmjU3VquV7vvcnjJKvsPam8Be2pbN38gxQMrg/s3JaSVkPNYgiSCjB15FNtAdibIMM82W5V1FWhlT6xphpRHIQAlL3xWW/EHCeQK0+jC0MA6mIkZ5KSYxbAJ7Lo4w6ET0IIo1lKwekAobhRgwtG267wNO9vCVIN7xMEmFi5RsqA9lq3ooDzhyW34YoCFkHT8ZjeWsz2fW+GS2RYjpuI/WONyak5tya94tt3wMGYRDan6rGDBai1JXR1rdHUdvhAAnBRxq1RJRIX0naCf9/VQRlXscNb6su42vm2lHmwZzrLhpO7pU3JhXiBv7M24GaDCMkeKm4+hCcVP0c9G4cT7jZmj5tncYZ+vNkVuVD+uNe4W4mQzHDSWbOBBHvrnKaR84Jt7kVGg2gStwHDoTtvPGaEdC9/8AqqU1UXVvjWrR2ZEa52OQpshvItlBTM3+8TdCyF6kI0LZmoQkBnhRWT1/Q7cZY8IRB5Ee/hL0PRpuUX7l5Qf1UXWswjLfS4bz0qFe+gop4shAKo3HCqqu5oLzHlTmLZW39FOcEc89IRhtRxfK2O0BW+rAsPR3ql9Gp7XuDV6ySdedBcDXO3sv5GXmryuKNAGMwlisGx5tIiY9oR7IB3gqX0QoCLKF0KdWTT1bkZjJO17dGunmz25lx64cOT0h3Y6Y8dRI7xJCkp+HD1Mz7ouP027rTswObQDPzhb1VKE+DuWJEVOCe8uMYKoDQn70raHVv9UbeyuunpQQ2lulqySEI24w73+T2fmpoEdGrrzL7Lm5W9jKVFUmE2XhKlNN8Wyx4M4QewGe4y5zRWnDDe0M7juXffuNhVzjSzOvqvs9N2YVX5biTRWXU6ouCWMk+qSsuva6HWWnXVZ9MFUfm0Nvdlpq5RrDNIvf2D58w2m2HF34RzXtiNukn5dYrc3GubR2HF2a1r77LBsL3QzQtkGv/e9GfOfiCVl9kLo45TUwXLHqLX8K5d/MS5qAuNeNoPwhzTgXXjQr2fd4WZiKN1fcmbKYKHxDOLGUxZPizRR3+hIDhGcYRUteGURCbuNlmtS65oDkvTdHxM3Z1JpWMZwPjPMCmBUIWGLW01kGBZ+4k1k4CE457/z/Z8TWm2WJz69gC57Fl1dnwcGtOSKFeTC3jpkpy++shONQSIl89kkkRCXf1NY0QzQi3CNiYh25oojBEmIP+N/DzHf7UM4b9wlR3orQANKeFk8gQlj08AwoiEgcFMOQwKiS6t/LoThqzqeP4vAb31Yac6My/CaioGHx8p1Mw/aHVC9jpLvf1l3LBXflvFh9G5crVvWFobH4Dw== \ No newline at end of file diff --git "a/docs/cs-basics/data-structure/pictures/\347\272\277\346\200\247\346\225\260\346\215\256\347\273\223\346\236\204/\346\240\210\345\256\236\347\216\260\346\265\217\350\247\210\345\231\250\345\200\222\351\200\200\345\222\214\345\211\215\350\277\233.png" "b/docs/cs-basics/data-structure/pictures/\347\272\277\346\200\247\346\225\260\346\215\256\347\273\223\346\236\204/\346\240\210\345\256\236\347\216\260\346\265\217\350\247\210\345\231\250\345\200\222\351\200\200\345\222\214\345\211\215\350\277\233.png" new file mode 100644 index 0000000000000000000000000000000000000000..84e117a51f4973d93947a7a24ee53c0db9b87436 Binary files /dev/null and "b/docs/cs-basics/data-structure/pictures/\347\272\277\346\200\247\346\225\260\346\215\256\347\273\223\346\236\204/\346\240\210\345\256\236\347\216\260\346\265\217\350\247\210\345\231\250\345\200\222\351\200\200\345\222\214\345\211\215\350\277\233.png" differ diff --git "a/docs/cs-basics/data-structure/pictures/\347\272\277\346\200\247\346\225\260\346\215\256\347\273\223\346\236\204/\351\230\237\345\210\227.png" "b/docs/cs-basics/data-structure/pictures/\347\272\277\346\200\247\346\225\260\346\215\256\347\273\223\346\236\204/\351\230\237\345\210\227.png" new file mode 100644 index 0000000000000000000000000000000000000000..fd8e334d1131a84105e2c8992f05a03621755c00 Binary files /dev/null and "b/docs/cs-basics/data-structure/pictures/\347\272\277\346\200\247\346\225\260\346\215\256\347\273\223\346\236\204/\351\230\237\345\210\227.png" differ diff --git "a/docs/cs-basics/data-structure/pictures/\347\272\277\346\200\247\346\225\260\346\215\256\347\273\223\346\236\204/\351\241\272\345\272\217\351\230\237\345\210\227\345\201\207\346\272\242\345\207\272.png" "b/docs/cs-basics/data-structure/pictures/\347\272\277\346\200\247\346\225\260\346\215\256\347\273\223\346\236\204/\351\241\272\345\272\217\351\230\237\345\210\227\345\201\207\346\272\242\345\207\272.png" new file mode 100644 index 0000000000000000000000000000000000000000..9a324873490ed3f221cc3c8066742330ff9013ab Binary files /dev/null and "b/docs/cs-basics/data-structure/pictures/\347\272\277\346\200\247\346\225\260\346\215\256\347\273\223\346\236\204/\351\241\272\345\272\217\351\230\237\345\210\227\345\201\207\346\272\242\345\207\272.png" differ diff --git a/docs/cs-basics/data-structure/red-black-tree.md b/docs/cs-basics/data-structure/red-black-tree.md new file mode 100644 index 0000000000000000000000000000000000000000..ce18d6e01380c2e87d1cb0dbb19c89d5019efbd2 --- /dev/null +++ b/docs/cs-basics/data-structure/red-black-tree.md @@ -0,0 +1,22 @@ +--- +category: 计算机基础 +tag: + - 数据结构 +--- + +# 红黑树 + +**红黑树特点** : + +1. 每个节点非红即黑； +2. 根节点总是黑色的； +3. 每个叶子节点都是黑色的空节点（NIL节点）； +4. 如果节点是红色的，则它的子节点必须是黑色的（反之不一定）； +5. 从根节点到叶节点或空子节点的每条路径，必须包含相同数目的黑色节点（即相同的黑色高度）。 + +**红黑树的应用** ：TreeMap、TreeSet以及JDK1.8的HashMap底层都用到了红黑树。 + +**为什么要用红黑树？** 简单来说红黑树就是为了解决二叉查找树的缺陷，因为二叉查找树在某些情况下会退化成一个线性结构。详细了解可以查看 [漫画：什么是红黑树？](https://juejin.im/post/5a27c6946fb9a04509096248#comment)（也介绍到了二叉查找树，非常推荐） + +**相关阅读** ：[《红黑树深入剖析及Java实现》](https://zhuanlan.zhihu.com/p/24367771)（美团点评技术团队） + diff --git a/docs/cs-basics/data-structure/tree.md b/docs/cs-basics/data-structure/tree.md new file mode 100644 index 0000000000000000000000000000000000000000..2c8491aecdcb68496d900f94b5b3836900dc536a --- /dev/null +++ b/docs/cs-basics/data-structure/tree.md @@ -0,0 +1,184 @@ +--- +category: 计算机基础 +tag: + - 数据结构 +--- + +# 树 + +树就是一种类似现实生活中的树的数据结构（倒置的树）。任何一颗非空树只有一个根节点。 + +一棵树具有以下特点： + +1. 一棵树中的任意两个结点有且仅有唯一的一条路径连通。 +2. 一棵树如果有 n 个结点，那么它一定恰好有 n-1 条边。 +3. 一棵树不包含回路。 + +下图就是一颗树，并且是一颗二叉树。 + +![二叉树](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/2019-6/二叉树-2.png) + +如上图所示，通过上面这张图说明一下树中的常用概念： + +- **节点** ：树中的每个元素都可以统称为节点。 +- **根节点** ：顶层节点或者说没有父节点的节点。上图中 A 节点就是根节点。 +- **父节点** ：若一个节点含有子节点，则这个节点称为其子节点的父节点。上图中的 B 节点是 D 节点、E 节点的父节点。 +- **子节点** ：一个节点含有的子树的根节点称为该节点的子节点。上图中 D 节点、E 节点是 B 节点的子节点。 +- **兄弟节点** ：具有相同父节点的节点互称为兄弟节点。上图中 D 节点、E 节点的共同父节点是 B 节点，故 D 和 E 为兄弟节点。 +- **叶子节点** ：没有子节点的节点。上图中的 D、F、H、I 都是叶子节点。 +- **节点的高度** ：该节点到叶子节点的最长路径所包含的边数。 +- **节点的深度** ：根节点到该节点的路径所包含的边数 +- **节点的层数** ：节点的深度+1。 +- **树的高度** ：根节点的高度。 + +> 关于树的深度和高度的定义可以看 stackoverflow 上的这个问题：[What is the difference between tree depth and height?](https://stackoverflow.com/questions/2603692/what-is-the-difference-between-tree-depth-and-height) 。 + +## 二叉树的分类 + +**二叉树**（Binary tree）是每个节点最多只有两个分支（即不存在分支度大于 2 的节点）的树结构。 + +**二叉树** 的分支通常被称作“**左子树**”或“**右子树**”。并且，**二叉树** 的分支具有左右次序，不能随意颠倒。 + +**二叉树** 的第 i 层至多拥有 `2^(i-1)` 个节点，深度为 k 的二叉树至多总共有 `2^(k+1)-1` 个节点（满二叉树的情况），至少有 2^(k) 个节点（关于节点的深度的定义国内争议比较多，我个人比较认可维基百科对[节点深度的定义](https://zh.wikipedia.org/wiki/%E6%A0%91_(%E6%95%B0%E6%8D%AE%E7%BB%93%E6%9E%84)#/%E6%9C%AF%E8%AF%AD)）。 + +![](https://guide-blog-images.oss-cn-shenzhen.aliyuncs.com/github/javaguide/image-20220119112736158.png) + +### 满二叉树 + +一个二叉树，如果每一个层的结点数都达到最大值，则这个二叉树就是 **满二叉树**。也就是说，如果一个二叉树的层数为 K，且结点总数是(2^k) -1 ，则它就是 **满二叉树**。如下图所示： + +![](./pictures/树/满二叉树.png) + +### 完全二叉树 + +除最后一层外，若其余层都是满的，并且最后一层或者是满的，或者是在右边缺少连续若干节点，则这个二叉树就是 **完全二叉树** 。 + +大家可以想象为一棵树从根结点开始扩展，扩展完左子节点才能开始扩展右子节点，每扩展完一层，才能继续扩展下一层。如下图所示： + +![](./pictures/树/完全二叉树.png) + +完全二叉树有一个很好的性质：**父结点和子节点的序号有着对应关系。** + +细心的小伙伴可能发现了，当根节点的值为 1 的情况下，若父结点的序号是 i，那么左子节点的序号就是 2i，右子节点的序号是 2i+1。这个性质使得完全二叉树利用数组存储时可以极大地节省空间，以及利用序号找到某个节点的父结点和子节点，后续二叉树的存储会详细介绍。 + +### 平衡二叉树 + +**平衡二叉树** 是一棵二叉排序树，且具有以下性质： + +1. 可以是一棵空树 +2. 如果不是空树，它的左右两个子树的高度差的绝对值不超过 1，并且左右两个子树都是一棵平衡二叉树。 + +平衡二叉树的常用实现方法有 **红黑树**、**AVL 树**、**替罪羊树**、**加权平衡树**、**伸展树** 等。 + +在给大家展示平衡二叉树之前，先给大家看一棵树： + +![](./pictures/树/斜树.png) + +**你管这玩意儿叫树？？？** + +没错，这玩意儿还真叫树，只不过这棵树已经退化为一个链表了，我们管它叫 **斜树**。 + +**如果这样，那我为啥不直接用链表呢?** + +谁说不是呢？ + +二叉树相比于链表，由于父子节点以及兄弟节点之间往往具有某种特殊的关系，这种关系使得我们在树中对数据进行**搜索**和**修改**时，相对于链表更加快捷便利。 + +但是，如果二叉树退化为一个链表了，那么那么树所具有的优秀性质就难以表现出来，效率也会大打折，为了避免这样的情况，我们希望每个做 “家长”（父结点） 的，都 **一碗水端平**，分给左儿子和分给右儿子的尽可能一样多，相差最多不超过一层，如下图所示： + +![](./pictures/树/平衡二叉树.png) + +## 二叉树的存储 + +二叉树的存储主要分为 **链式存储** 和 **顺序存储** 两种： + +### 链式存储 + +和链表类似，二叉树的链式存储依靠指针将各个节点串联起来，不需要连续的存储空间。 + +每个节点包括三个属性： + +- 数据 data。data 不一定是单一的数据，根据不同情况，可以是多个具有不同类型的数据。 +- 左节点指针 left +- 右节点指针 right。 + +可是 JAVA 没有指针啊！ + +那就直接引用对象呗（别问我对象哪里找） + +![](./pictures/树/链式存储二叉树.png) + +### 顺序存储 + +顺序存储就是利用数组进行存储，数组中的每一个位置仅存储节点的 data，不存储左右子节点的指针，子节点的索引通过数组下标完成。根结点的序号为 1，对于每个节点 Node，假设它存储在数组中下标为 i 的位置，那么它的左子节点就存储在 2 _ i 的位置，它的右子节点存储在下标为 2 _ i+1 的位置。 + +一棵完全二叉树的数组顺序存储如下图所示： + +![](./pictures/树/顺序存储.png) + +大家可以试着填写一下存储如下二叉树的数组，比较一下和完全二叉树的顺序存储有何区别： + +![](./pictures/树/顺序存储2.png) + +可以看到，如果我们要存储的二叉树不是完全二叉树，在数组中就会出现空隙，导致内存利用率降低 + +## 二叉树的遍历 + +### 先序遍历 + +![](./pictures/树/先序遍历.png) + +二叉树的先序遍历，就是先输出根结点，再遍历左子树，最后遍历右子树，遍历左子树和右子树的时候，同样遵循先序遍历的规则，也就是说，我们可以递归实现先序遍历。 + +代码如下： + +```java +public void preOrder(TreeNode root){ + if(root == null){ + return; + } + system.out.println(root.data); + preOrder(root.left); + preOrder(root.right); +} +``` + +### 中序遍历 + +![](./pictures/树/中序遍历.png) + +二叉树的中序遍历，就是先递归中序遍历左子树，再输出根结点的值，再递归中序遍历右子树，大家可以想象成一巴掌把树压扁，父结点被拍到了左子节点和右子节点的中间，如下图所示： + +![](./pictures/树/中序遍历2.png) + +代码如下： + +```java +public void inOrder(TreeNode root){ + if(root == null){ + return; + } + inOrder(root.left); + system.out.println(root.data); + inOrder(root.right); +} +``` + +### 后序遍历 + +![](./pictures/树/后序遍历.png) + +二叉树的后序遍历，就是先递归后序遍历左子树，再递归后序遍历右子树，最后输出根结点的值 + +代码如下： + +```java +public void postOrder(TreeNode root){ + if(root == null){ + return; + } + postOrder(root.left); + postOrder(root.right); + system.out.println(root.data); +} +``` \ No newline at end of file diff --git a/docs/cs-basics/network/http&https.md b/docs/cs-basics/network/http&https.md new file mode 100644 index 0000000000000000000000000000000000000000..5ba8a479a0ebe22037b4910c5ccde115b74cc4e3 --- /dev/null +++ b/docs/cs-basics/network/http&https.md @@ -0,0 +1,149 @@ +--- +title: HTTP vs HTTPS（应用层） +category: 计算机基础 +tag: + - 计算机网络 +--- + +> 本文由 [SnailClimb](https://github.com/Snailclimb) 和 [csguide-dabai](https://github.com/csguide-dabai) （公众号“CS指南”作者）共同完成。 + +## HTTP 协议 + +### HTTP 协议介绍 + +HTTP 协议，全称超文本传输协议（Hypertext Transfer Protocol）。顾名思义，HTTP 协议就是用来规范超文本的传输，超文本，也就是网络上的包括文本在内的各式各样的消，具体来说，主要是来规范浏览器和服务器端的行为的。 + +并且，HTTP 是一个无状态（stateless）协议，也就是说服务器不维护任何有关客户端过去所发请求的消息。这其实是一种懒政，有状态协议会更加复杂，需要维护状态（历史信息），而且如果客户或服务器失效，会产生状态的不一致，解决这种不一致的代价更高。 + +### HTTP 协议通信过程 + +HTTP 是应用层协议，它以 TCP（传输层）作为底层协议，默认端口为 80. 通信过程主要如下： + +1. 服务器在 80 端口等待客户的请求。 +2. 浏览器发起到服务器的 TCP 连接（创建套接字 Socket）。 +3. 服务器接收来自浏览器的 TCP 连接。 +4. 浏览器（HTTP 客户端）与 Web 服务器（HTTP 服务器）交换 HTTP 消息。 +5. 关闭 TCP 连接。 + +### HTTP 协议优点 + +扩展性强、速度快、跨平台支持性好。 + +## HTTPS 协议 + +### HTTPS 协议介绍 + +HTTPS 协议（Hyper Text Transfer Protocol Secure），是 HTTP 的加强安全版本。HTTPS 是基于 HTTP 的，也是用 TCP 作为底层协议，并额外使用 SSL/TLS 协议用作加密和安全认证。默认端口号是 443. + +HTTPS 协议中，SSL 通道通常使用基于密钥的加密算法，密钥长度通常是 40 比特或 128 比特。 + +### HTTPS 协议优点 + +保密性好、信任度高。 + +## HTTPS 的核心—SSL/TLS协议 + +HTTPS 之所以能达到较高的安全性要求，就是结合了 SSL/TLS 和 TCP 协议，对通信数据进行加密，解决了 HTTP 数据透明的问题。接下来重点介绍一下 SSL/TLS 的工作原理。 + +### SSL 和 TLS 的区别？ + +**SSL 和 TLS 没有太大的区别。** + +SSL 指安全套接字协议（Secure Sockets Layer），首次发布与 1996 年。SSL 的首次发布其实已经是他的 3.0 版本，SSL 1.0 从未面世，SSL 2.0 则具有较大的缺陷（DROWN 缺陷——Decrypting RSA with Obsolete and Weakened eNcryption）。很快，在 1999 年，SSL 3.0 进一步升级，**新版本被命名为 TLS 1.0**。因此，TLS 是基于 SSL 之上的，但由于习惯叫法，通常把 HTTPS 中的核心加密协议混成为 SSL/TLS。 + +### SSL/TLS 的工作原理 + +#### 非对称加密 + +SSL/TLS 的核心要素是**非对称加密**。非对称加密采用两个密钥——一个公钥，一个私钥。在通信时，私钥仅由解密者保存，公钥由任何一个想与解密者通信的发送者（加密者）所知。可以设想一个场景， + +> 在某个自助邮局，每个通信信道都是一个邮箱，每一个邮箱所有者都在旁边立了一个牌子，上面挂着一把钥匙：这是我的公钥，发送者请将信件放入我的邮箱，并用公钥锁好。 +> +> 但是公钥只能加锁，并不能解锁。解锁只能由邮箱的所有者——因为只有他保存着私钥。 +> +> 这样，通信信息就不会被其他人截获了，这依赖于私钥的保密性。 + +![](./images/http&https/public-key-cryptography.png) + +非对称加密的公钥和私钥需要采用一种复杂的数学机制生成（密码学认为，为了较高的安全性，尽量不要自己创造加密方案）。公私钥对的生成算法依赖于单向陷门函数。 + +> 单向函数：已知单向函数 f，给定任意一个输入 x，易计算输出 y=f(x)；而给定一个输出 y，假设存在 f(x)=y，很难根据 f 来计算出 x。 +> +> 单向陷门函数：一个较弱的单向函数。已知单向陷门函数 f，陷门 h，给定任意一个输入 x，易计算出输出 y=f(x;h)；而给定一个输出 y，假设存在 f(x;h)=y，很难根据 f 来计算出 x，但可以根据 f 和 h 来推导出 x。 + +![单向函数](./images/http&https/OWF.png) + +上图就是一个单向函数（不是单项陷门函数），假设有一个绝世秘籍，任何知道了这个秘籍的人都可以把苹果汁榨成苹果，那么这个秘籍就是“陷门”了吧。 + +在这里，函数 f 的计算方法相当于公钥，陷门 h 相当于私钥。公钥 f 是公开的，任何人对已有输入，都可以用 f 加密，而要想根据加密信息还原出原信息，必须要有私钥才行。 + +#### 对称加密 + +使用 SSL/TLS 进行通信的双方需要使用非对称加密方案来通信，但是非对称加密设计了较为复杂的数学算法，在实际通信过程中，计算的代价较高，效率太低，因此，SSL/TLS 实际对消息的加密使用的是对称加密。 + +> 对称加密：通信双方共享唯一密钥 k，加解密算法已知，加密方利用密钥 k 加密，解密方利用密钥 k 解密，保密性依赖于密钥 k 的保密性。 + +![](./images/http&https/symmetric-encryption.png) + +对称加密的密钥生成代价比公私钥对的生成代价低得多，那么有的人会问了，为什么 SSL/TLS 还需要使用非对称加密呢？因为对称加密的保密性完全依赖于密钥的保密性。在双方通信之前，需要商量一个用于对称加密的密钥。我们知道网络通信的信道是不安全的，传输报文对任何人是可见的，密钥的交换肯定不能直接在网络信道中传输。因此，使用非对称加密，对对称加密的密钥进行加密，保护该密钥不在网络信道中被窃听。这样，通信双方只需要一次非对称加密，交换对称加密的密钥，在之后的信息通信中，使用绝对安全的密钥，对信息进行对称加密，即可保证传输消息的保密性。 + +#### 公钥传输的信赖性 + +SSL/TLS 介绍到这里，了解信息安全的朋友又会想到一个安全隐患，设想一个下面的场景： + +> 客户端 C 和服务器 S 想要使用 SSL/TLS 通信，由上述 SSL/TLS 通信原理，C 需要先知道 S 的公钥，而 S 公钥的唯一获取途径，就是把 S 公钥在网络信道中传输。要注意网络信道通信中有几个前提： +> +> 1. 任何人都可以捕获通信包 +> 2. 通信包的保密性由发送者设计 +> 3. 保密算法设计方案默认为公开，而（解密）密钥默认是安全的 +> +> 因此，假设 S 公钥不做加密，在信道中传输，那么很有可能存在一个攻击者 A，发送给 C 一个诈包，假装是 S 公钥，其实是诱饵服务器 AS 的公钥。当 C 收获了 AS 的公钥（却以为是 S 的公钥），C 后续就会使用 AS 公钥对数据进行加密，并在公开信道传输，那么 A 将捕获这些加密包，用 AS 的私钥解密，就截获了 C 本要给 S 发送的内容，而 C 和 S 二人全然不知。 +> +> 同样的，S 公钥即使做加密，也难以避免这种信任性问题，C 被 AS 拐跑了！ + +![](./images/http&https/attack1.png) + +为了公钥传输的信赖性问题，第三方机构应运而生——证书颁发机构（CA，Certificate Authority）。CA 默认是受信任的第三方。CA 会给各个服务器颁发证书，证书存储在服务器上，并附有 CA 的**电子签名**（见下节）。 + +当客户端（浏览器）向服务器发送 HTTPS 请求时，一定要先获取目标服务器的证书，并根据证书上的信息，检验证书的合法性。一旦客户端检测到证书非法，就会发生错误。客户端获取了服务器的证书后，由于证书的信任性是由第三方信赖机构认证的，而证书上又包含着服务器的公钥信息，客户端就可以放心的信任证书上的公钥就是目标服务器的公钥。 + +#### 数字签名 + +好，到这一小节，已经是 SSL/TLS 的尾声了。上一小节提到了数字签名，数字签名要解决的问题，是防止证书被伪造。第三方信赖机构 CA 之所以能被信赖，就是靠数字签名技术。 + +数字签名，是 CA 在给服务器颁发证书时，使用散列+加密的组合技术，在证书上盖个章，以此来提供验伪的功能。具体行为如下： + +> CA 知道服务器的公钥，对该公钥采用散列技术生成一个摘要。CA 使用 CA 私钥对该摘要进行加密，并附在证书下方，发送给服务器。 +> +> 现在服务器将该证书发送给客户端，客户端需要验证该证书的身份。客户端找到第三方机构 CA，获知 CA 的公钥，并用 CA 公钥对证书的签名进行解密，获得了 CA 生成的摘要。 +> +> 客户端对证书数据（也就是服务器的公钥）做相同的散列处理，得到摘要，并将该摘要与之前从签名中解码出的摘要做对比，如果相同，则身份验证成功；否则验证失败。 + +![](./images/http&https/digital-signature.png) + +注意，验证身份的证书一定是由 CA 的公钥进行签名，而不能由发送者自己来签名。这是为了抵抗以下的攻击场景： + +> 攻击者使用某种手段，欺骗了客户端，将服务器的公钥替换为攻击者的诱饵公钥。 +> +> 假使证书的签名使用的是服务器的私钥，那么客户端在解码的时候，将会使用假的服务器公钥（实则为诱饵公钥）。那么，如果该证书实则由攻击者（使用自己的私钥签名）发出，那么客户端就会成功验证（攻击者的）身份为真，从而信赖了证书中的公钥。 +> +> 如果使用 CA 的私钥和公钥来对签名处理，则不会出现上述问题。 + +总结来说，带有证书的公钥传输机制如下： + +1. 设有服务器 S，客户端 C，和第三方信赖机构 CA。 +2. S 信任 CA，CA 是知道 S 公钥的，S 向 CA 颁发证书。并附上 CA 私钥对消息摘要的加密签名。 +3. S 获得 CA 颁发的证书，将该证书传递给 C。 +4. C 获得 S 的证书，信任 CA 并知晓 CA 公钥，使用 CA 公钥对 S 证书山的签名解密，同时对消息进行散列处理，得到摘要。比较摘要，验证 S 证书的真实性。 +5. 如果 C 验证 S 证书是真实的，则信任 S 的公钥（在 S 证书中）。 + +![](./images/http&https/public-key-transmission.png) + +## 总结 + +- **端口号** ：HTTP 默认是 80，HTTPS 默认是 443。 +- **URL 前缀** ：HTTP 的 URL 前缀是 `http://`，HTTPS 的 URL 前缀是 `https://`。 +- **安全性和资源消耗** ： HTTP 协议运行在 TCP 之上，所有传输的内容都是明文，客户端和服务器端都无法验证对方的身份。HTTPS 是运行在 SSL/TLS 之上的 HTTP 协议，SSL/TLS 运行在 TCP 之上。所有传输的内容都经过加密，加密采用对称加密，但对称加密的密钥用服务器方的证书进行了非对称加密。所以说，HTTP 安全性没有 HTTPS 高，但是 HTTPS 比 HTTP 耗费更多服务器资源。 + + + diff --git a/docs/cs-basics/network/http1.0&http1.1.md b/docs/cs-basics/network/http1.0&http1.1.md new file mode 100644 index 0000000000000000000000000000000000000000..b3e1bf4c05cbf8a55f23b8b296d1f9a08712a47d --- /dev/null +++ b/docs/cs-basics/network/http1.0&http1.1.md @@ -0,0 +1,107 @@ +--- +title: HTTP 1.0 vs HTTP 1.1（应用层） +category: 计算机基础 +tag: + - 计算机网络 +--- + +> 本文由 [SnailClimb](https://github.com/Snailclimb) 和 [csguide-dabai](https://github.com/csguide-dabai) （公众号“CS指南”作者）共同完成。 + +这篇文章会从下面几个维度来对比 HTTP 1.0 和 HTTP 1.1： + +- 响应状态码 +- 缓存处理 +- 连接方式 +- Host头处理 +- 带宽优化 + +## 响应状态码 + +HTTP/1.0仅定义了16种状态码。HTTP/1.1中新加入了大量的状态码，光是错误响应状态码就新增了24种。比如说，`100 (Continue)`——在请求大资源前的预热请求，`206 (Partial Content)`——范围请求的标识码，`409 (Conflict)`——请求与当前资源的规定冲突，`410 (Gone)`——资源已被永久转移，而且没有任何已知的转发地址。 + +## 缓存处理 + +缓存技术通过避免用户与源服务器的频繁交互，节约了大量的网络带宽，降低了用户接收信息的延迟。 + +### HTTP/1.0 + +HTTP/1.0提供的缓存机制非常简单。服务器端使用`Expires`标签来标志（时间）一个响应体，在`Expires`标志时间内的请求，都会获得该响应体缓存。服务器端在初次返回给客户端的响应体中，有一个`Last-Modified`标签，该标签标记了被请求资源在服务器端的最后一次修改。在请求头中，使用`If-Modified-Since`标签，该标签标志一个时间，意为客户端向服务器进行问询：“该时间之前，我要请求的资源是否有被修改过？”通常情况下，请求头中的`If-Modified-Since`的值即为上一次获得该资源时，响应体中的`Last-Modified`的值。 + +如果服务器接收到了请求头，并判断`If-Modified-Since`时间后，资源确实没有修改过，则返回给客户端一个`304 not modified`响应头，表示”缓冲可用，你从浏览器里拿吧！”。 + +如果服务器判断`If-Modified-Since`时间后，资源被修改过，则返回给客户端一个`200 OK`的响应体，并附带全新的资源内容，表示”你要的我已经改过的，给你一份新的”。 + +![HTTP1.0cache1](./images/http&https/HTTP1.0cache1.png) + +![HTTP1.0cache2](./images/http&https/HTTP1.0cache2.png) + +### HTTP/1.1 + +HTTP/1.1的缓存机制在HTTP/1.0的基础上，大大增加了灵活性和扩展性。基本工作原理和HTTP/1.0保持不变，而是增加了更多细致的特性。其中，请求头中最常见的特性就是`Cache-Control`，详见MDN Web文档 [Cache-Control](https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Headers/Cache-Control). + +## 连接方式 + +**HTTP/1.0 默认使用短连接** ，也就是说，客户端和服务器每进行一次 HTTP 操作，就建立一次连接，任务结束就中断连接。当客户端浏览器访问的某个 HTML 或其他类型的 Web 页中包含有其他的 Web 资源（如 JavaScript 文件、图像文件、CSS 文件等），每遇到这样一个 Web 资源，浏览器就会重新建立一个TCP连接，这样就会导致有大量的“握手报文”和“挥手报文”占用了带宽。 + +**为了解决 HTTP/1.0 存在的资源浪费的问题， HTTP/1.1 优化为默认长连接模式 。** 采用长连接模式的请求报文会通知服务端：“我向你请求连接，并且连接成功建立后，请不要关闭”。因此，该TCP连接将持续打开，为后续的客户端-服务端的数据交互服务。也就是说在使用长连接的情况下，当一个网页打开完成后，客户端和服务器之间用于传输 HTTP 数据的 TCP 连接不会关闭，客户端再次访问这个服务器时，会继续使用这一条已经建立的连接。 + +如果 TCP 连接一直保持的话也是对资源的浪费，因此，一些服务器软件（如 Apache）还会支持超时时间的时间。在超时时间之内没有新的请求达到，TCP 连接才会被关闭。 + +有必要说明的是，HTTP/1.0仍提供了长连接选项，即在请求头中加入`Connection: Keep-alive`。同样的，在HTTP/1.1中，如果不希望使用长连接选项，也可以在请求头中加入`Connection: close`，这样会通知服务器端：“我不需要长连接，连接成功后即可关闭”。 + +**HTTP 协议的长连接和短连接，实质上是 TCP 协议的长连接和短连接。** + +**实现长连接需要客户端和服务端都支持长连接。** + +## Host头处理 + +域名系统（DNS）允许多个主机名绑定到同一个IP地址上，但是HTTP/1.0并没有考虑这个问题，假设我们有一个资源URL是http://example1.org/home.html，HTTP/1.0的请求报文中，将会请求的是`GET /home.html HTTP/1.0`.也就是不会加入主机名。这样的报文送到服务器端，服务器是理解不了客户端想请求的真正网址。 + +因此，HTTP/1.1在请求头中加入了`Host`字段。加入`Host`字段的报文头部将会是: + +``` +GET /home.html HTTP/1.1 +Host: example1.org +``` + +这样，服务器端就可以确定客户端想要请求的真正的网址了。 + +## 带宽优化 + +### 范围请求 + +HTTP/1.1引入了范围请求（range request）机制，以避免带宽的浪费。当客户端想请求一个文件的一部分，或者需要继续下载一个已经下载了部分但被终止的文件，HTTP/1.1可以在请求中加入`Range`头部，以请求（并只能请求字节型数据）数据的一部分。服务器端可以忽略`Range`头部，也可以返回若干`Range`响应。 + +如果一个响应包含部分数据的话，那么将带有`206 (Partial Content)`状态码。该状态码的意义在于避免了HTTP/1.0代理缓存错误地把该响应认为是一个完整的数据响应，从而把他当作为一个请求的响应缓存。 + +在范围响应中，`Content-Range`头部标志指示出了该数据块的偏移量和数据块的长度。 + +### 状态码100 + +HTTP/1.1中新加入了状态码`100`。该状态码的使用场景为，存在某些较大的文件请求，服务器可能不愿意响应这种请求，此时状态码`100`可以作为指示请求是否会被正常响应，过程如下图： + +![HTTP1.1continue1](./images/http&https/HTTP1.1continue1.png) + +![HTTP1.1continue2](./images/http&https/HTTP1.1continue2.png) + +然而在HTTP/1.0中，并没有`100 (Continue)`状态码，要想触发这一机制，可以发送一个`Expect`头部，其中包含一个`100-continue`的值。 + +### 压缩 + +许多格式的数据在传输时都会做预压缩处理。数据的压缩可以大幅优化带宽的利用。然而，HTTP/1.0对数据压缩的选项提供的不多，不支持压缩细节的选择，也无法区分端到端（end-to-end）压缩或者是逐跳（hop-by-hop）压缩。 + +HTTP/1.1则对内容编码（content-codings）和传输编码（transfer-codings）做了区分。内容编码总是端到端的，传输编码总是逐跳的。 + +HTTP/1.0包含了`Content-Encoding`头部，对消息进行端到端编码。HTTP/1.1加入了`Transfer-Encoding`头部，可以对消息进行逐跳传输编码。HTTP/1.1还加入了`Accept-Encoding`头部，是客户端用来指示他能处理什么样的内容编码。 + +## 总结 + +1. **连接方式** : HTTP 1.0 为短连接，HTTP 1.1 支持长连接。 +1. **状态响应码** : HTTP/1.1中新加入了大量的状态码，光是错误响应状态码就新增了24种。比如说，`100 (Continue)`——在请求大资源前的预热请求，`206 (Partial Content)`——范围请求的标识码，`409 (Conflict)`——请求与当前资源的规定冲突，`410 (Gone)`——资源已被永久转移，而且没有任何已知的转发地址。 +1. **缓存处理** : 在 HTTP1.0 中主要使用 header 里的 If-Modified-Since,Expires 来做为缓存判断的标准，HTTP1.1 则引入了更多的缓存控制策略例如 Entity tag，If-Unmodified-Since, If-Match, If-None-Match 等更多可供选择的缓存头来控制缓存策略。 +1. **带宽优化及网络连接的使用** :HTTP1.0 中，存在一些浪费带宽的现象，例如客户端只是需要某个对象的一部分，而服务器却将整个对象送过来了，并且不支持断点续传功能，HTTP1.1 则在请求头引入了 range 头域，它允许只请求资源的某个部分，即返回码是 206（Partial Content），这样就方便了开发者自由的选择以便于充分利用带宽和连接。 +1. **Host头处理** : HTTP/1.1在请求头中加入了`Host`字段。 + +## 参考资料 + +[Key differences between HTTP/1.0 and HTTP/1.1](http://www.ra.ethz.ch/cdstore/www8/data/2136/pdf/pd1.pdf) \ No newline at end of file diff --git a/docs/cs-basics/network/images/http&https/HTTP1.0cache1.png b/docs/cs-basics/network/images/http&https/HTTP1.0cache1.png new file mode 100644 index 0000000000000000000000000000000000000000..a327583c32de7df797ab0cafa67eff6136c2a62f Binary files /dev/null and b/docs/cs-basics/network/images/http&https/HTTP1.0cache1.png differ diff --git a/docs/cs-basics/network/images/http&https/HTTP1.0cache2.png b/docs/cs-basics/network/images/http&https/HTTP1.0cache2.png new file mode 100644 index 0000000000000000000000000000000000000000..bef08dad86316a09b6138759fb7047573ea27cea Binary files /dev/null and b/docs/cs-basics/network/images/http&https/HTTP1.0cache2.png differ diff --git a/docs/cs-basics/network/images/http&https/HTTP1.1continue1.png b/docs/cs-basics/network/images/http&https/HTTP1.1continue1.png new file mode 100644 index 0000000000000000000000000000000000000000..97adbde7cea347c17a72088d3fc05bdb60eb7df0 Binary files /dev/null and b/docs/cs-basics/network/images/http&https/HTTP1.1continue1.png differ diff --git a/docs/cs-basics/network/images/http&https/HTTP1.1continue2.png b/docs/cs-basics/network/images/http&https/HTTP1.1continue2.png new file mode 100644 index 0000000000000000000000000000000000000000..53600aa21faface92e3b9b8cb048215b841d4687 Binary files /dev/null and b/docs/cs-basics/network/images/http&https/HTTP1.1continue2.png differ diff --git a/docs/cs-basics/network/images/http&https/OWF.png b/docs/cs-basics/network/images/http&https/OWF.png new file mode 100644 index 0000000000000000000000000000000000000000..9b4673482f3537a3615c5e59e0e7bb629ebc3a38 Binary files /dev/null and b/docs/cs-basics/network/images/http&https/OWF.png differ diff --git a/docs/cs-basics/network/images/http&https/attack1.png b/docs/cs-basics/network/images/http&https/attack1.png new file mode 100644 index 0000000000000000000000000000000000000000..4c62591dfc0e391f5bfb0dfe6844331f94b394be Binary files /dev/null and b/docs/cs-basics/network/images/http&https/attack1.png differ diff --git a/docs/cs-basics/network/images/http&https/digital-signature.png b/docs/cs-basics/network/images/http&https/digital-signature.png new file mode 100644 index 0000000000000000000000000000000000000000..54071aa3b0bf53aa9c8c4ec1777da67da7b6f8ea Binary files /dev/null and b/docs/cs-basics/network/images/http&https/digital-signature.png differ diff --git a/docs/cs-basics/network/images/http&https/public-key-cryptography.png b/docs/cs-basics/network/images/http&https/public-key-cryptography.png new file mode 100644 index 0000000000000000000000000000000000000000..a6c4143ff7ef5af9f4e2058f2af2c496d736d727 Binary files /dev/null and b/docs/cs-basics/network/images/http&https/public-key-cryptography.png differ diff --git a/docs/cs-basics/network/images/http&https/public-key-transmission.png b/docs/cs-basics/network/images/http&https/public-key-transmission.png new file mode 100644 index 0000000000000000000000000000000000000000..b3eb4a7c120faeccacfda7b7ba4c970d641c8a31 Binary files /dev/null and b/docs/cs-basics/network/images/http&https/public-key-transmission.png differ diff --git a/docs/cs-basics/network/images/http&https/symmetric-encryption.png b/docs/cs-basics/network/images/http&https/symmetric-encryption.png new file mode 100644 index 0000000000000000000000000000000000000000..f1c80cc5bc9f2e9921e54de2e3d5579178e9775f Binary files /dev/null and b/docs/cs-basics/network/images/http&https/symmetric-encryption.png differ diff --git a/docs/cs-basics/network/images/network-layer/TCP-IP-4-model.png b/docs/cs-basics/network/images/network-layer/TCP-IP-4-model.png new file mode 100644 index 0000000000000000000000000000000000000000..7db48d8cc6233cec66b0ae479fd6c347ce6dbf9e Binary files /dev/null and b/docs/cs-basics/network/images/network-layer/TCP-IP-4-model.png differ diff --git a/docs/cs-basics/network/images/network-layer/network-protocol-overview.drawio b/docs/cs-basics/network/images/network-layer/network-protocol-overview.drawio new file mode 100644 index 0000000000000000000000000000000000000000..960c984366415bd7257de1ddfb7482af21e3480a --- /dev/null +++ b/docs/cs-basics/network/images/network-layer/network-protocol-overview.drawio @@ -0,0 +1 @@ +7VzbcqM4EP0aVe0+eIs74hFjO0nVZCYzzu7M7ptsZJsdDF6sjO18/UogbC4icRIMsUNSlUDrAvQ53Wo1QkB1lturCK0Wt6GLfaBI7haoA6AosqWq9B+T7BKJZZmJYB55Lq90EIy9R8yFEpc+eC5e5yqSMPSJt8oLp2EQ4CnJyVAUhZt8tVno56+6QnNcEoynyC9Lv3suWSRSqJgH+TX25ov0yrJhJSVLlFbmT7JeIDfcZETqEKhOFIYkOVpuHewz5aV6SdqNKkr3NxbhgBzTwHDsx4FiP35XNv/0vvSvvvbgrsd7+YX8B/7AYAiBLQMbgqEJbA30bTDUQV8GUOHPQXapcqLwIXAx618Gan+z8Ager9CUlW4oHahsQZY+L56FAeH40jul557vO6EfRnFfqqtj6GpUviZR+BNnSqAyUQ2Dlsx9tGZwstZ7bbKup+HSm/LjslrSZ8QRwduMiKvpCodLTKIdrZKWanrShHPWUDmEmwMD5BTWRQZ9g8sQJ9183/UBF3rAoXkBTIoAJp1BY2kMJvqX4dUITAjD2VQEkzGFeDJrESbdbBsmVQATtSAHWHZsViNgDZqBaTbDxlQIk2taE0lq05qstmFKnXdG99ilXp+fhhFZhPMwQP7wIO0f0GEKO9T5FIYrrqx/MSE7Dgp6IGEesUpVrsOHaIqfuF8tqcfu8UmFR9hHxPuVH7lE2uNN70KP3soeKE2TckCZsAAAQdEcE96qgMH+Nl4Pi1ZlPbbErKc/BJbakPXAKRZbzwTqmt6m9Zh669YDz8t69HasB2rNWo8usB4T9AfAkuODPrCcZqwHyzSWM0XWYxmmitqM5KDctvUYApgMYFFcJHYAB8AegqHFXB11eMztmSxuaAQ4eYJkrIiAkyRjSO8i6SEXZrCfNgFtPeYzhXYHLWBbcWguAWg0A58k6RKeieGTB3QcfX/wWe3PrPTzGs0UpZ3hzCgicOrhrJUoA2898oM3Z8d/s+M/dH422GaKBjt+cgZYtgtl+phZF1ntB6Xn/WBISzyyS93gPEKuhw+OLQgDRgYXrRd7z5q4xDSDp9bkzZS8YoUJCFPgzeTizKo+d2admTtT23Fn+4GnIRsw5DZwoXBEux/Zk4xDY6cHjxaf1eDSOJ6JOp9SiFQ38G+zG0Hq7kJ81BEBs9BHKafyUanpHafrI+LiXMRaDJKzoW02mi2mfHT2K8xrxz/l4Dn5qQclTS+k3gRZHkVvMi5WXzRof0iQoNI6SC/yWh8SJEtqHSRBXrsDKQeS6AWrqjYKkiB9qhg+YRpaoSCHlvHfA3tnT9UbK8dmQcp88ptqAIVeXNJk/t/4PdaWxBTZW8cYsbqysdomBVRbpId8bx4kJT6ekbgkvQI9mrP/1/f3d+nt0MdL7igpKlGJdVrgSw5iHnnwyw6mFEVM5X2GnjdFvs0Llp7rxlGoiI35UKgY3GQzSz6aYL+Ppj/ncZvCXdTBJbPAJa3MJU1ApdOFN4KM4CuoJB3YJB0IpUjVnErLhLQqcWrwedxRSkwpXX1vlIKVlHK9X0JGHUeCZ4kp5FlVL6wyYEuxUswOFVVFUywFl9uOb6lrG6oASgDKd1/u1P3Jza2ddXpJ5/kLloi7F8dqyUvPXVNp20kkeN43aOeDG3spFhFMkBWpSWvXBIvyauXwW9j3Nv6PnohjnuNyR9rMCAXf2QiliWail8HZe+wHmHS0rYG2RtHXtk5b0dz8Mmg7Hl93nD0FZ422OVudqjj3EPfeqSni/+Cc1eU8Z01BTNssZwXL3i6Es38OOs7W4mel98bZ6jzeuXP2pqPsKVLPUPAao1nKXm6e0P7WcbaW0EB5b5y1LnYKduPcdumuU6S7WidtOie8QNJ+tu87ztYRzxZeIkLBkq5mOXu5rxW+3RzeIX4Z3432J/2rzgHXEukWP7sSrU+UG2WzcrFsHjjXHWvrYK1ZiHVbf92gnzp12x5p8/OzjrO1hQ2th7qXm7q9tZ0up1BHdFCYnlmChfHNcrY6dUsvgBhPFiha8w+UUlo8kFkPvoKnb14HnBQk/bKSIIyWyM+UbbjSWKEm8WWePiaUNr01+9AomJdbVq4uTko8yp6A9ynlViSTCAXrGe0p7ZPzRNqEkZu/3r6h661XPtolUi/wvbTNzA8RKXRU1LAzvqXlI2dQaXZiA3tmnXzeQo63tneVn7NkvWRLsmg5WvGDxvqMSZCg6zYf6xVXYLW+k4EhyEkJdoAxABwCW2eAwRGwG9pR6Yi9KY5CrmoDixMgKvpyqGFEy9OF8mfERwYbWTxOEH887Rcz5JBhTWjJxV0N2s6vGeWXb2Wb6tBKBK2/3TfKo5raoVWBVuuTULM8tmkdWhVoNTn9soMt+XQ1vv1meIu/kPR1NxpPhZsK02hDB3S+zfdDNXn80acHo2SHVGccBycOgEnhgNWq/OaFSV6fMzhz5gg+z+3Hv3GfBBEvZNdmOy3k46oa6KYW1mnppmCCAgV0k19ON3p62B872YrlsMu4Ovwf \ No newline at end of file diff --git a/docs/cs-basics/network/images/network-layer/smtp.png b/docs/cs-basics/network/images/network-layer/smtp.png new file mode 100644 index 0000000000000000000000000000000000000000..6580bfb263c7763cd7692d4fc4cf1912cefb57d5 Binary files /dev/null and b/docs/cs-basics/network/images/network-layer/smtp.png differ diff --git a/docs/cs-basics/network/images/network-layer/transport-layer.drawio b/docs/cs-basics/network/images/network-layer/transport-layer.drawio new file mode 100644 index 0000000000000000000000000000000000000000..2222546d6a73bdb336c068018017580482d8856b --- /dev/null +++ b/docs/cs-basics/network/images/network-layer/transport-layer.drawio @@ -0,0 +1 @@ +vZZdb5swFIZ/jS8rAQZiLhtKO22rNimb1lvHPoA1gyPjjKS/fqaYACGVNqnJFfg9xx/nfY4TEE6rw5Omu/JZcZAo8PgB4QcUBL7vxfbRKcdeSZJVLxRacJc0ChvxCk70nLoXHJpZolFKGrGbi0zVNTAz06jWqp2n5UrOd93RAhbChlG5VH8JbspeJcFq1D+BKMphZz9O+khFh2RXSVNSrtqJhDOEU62U6d+qQwqyM2/wpZ/3+E70dDANtfmXCZw9b799ecEvn8O82Xivd1+VunOr/KFy7wp2hzXHwQGt9jWHbhEf4XVbCgObHWVdtLXMrVaaSrpwrmrjINrj2LGQMlVS6be1MKdAcmb1xmj1GyaRmBHY5jZSSNp0zLrZJ8u6AVOVYG6bZe1DIaANHCaS8+IJVAVGH22KiwZe2E9xjRnFjlM7Yg5XrnvLKeLEJVLXWsVp7dF9++IA/AeMYAkjC9E6RfceyghaZyjBKIvQ2kdkycnWbeYw5ibXqoYzIk6iUhS1HTLrJlh93bko7B24d4FKcN5tc5H+2B/eWQPgc4QfgA1jPMe2WmILfLLEFl6LGl5Q+5F+v+otygkDdvEWbUkURt4tbxHxZjjiaInDH34Bpzjia+GIFjh+PlwXB4+A8PASDhJscRzfEEeY3A6HHY5/Xm+xyScAzv4C \ No newline at end of file diff --git a/docs/cs-basics/network/images/osi&tcp-ip-model/TCP-IP-4-model.drawio b/docs/cs-basics/network/images/osi&tcp-ip-model/TCP-IP-4-model.drawio new file mode 100644 index 0000000000000000000000000000000000000000..b2a4c3fdf2a7f439c60bc8318653dbe9601f2f3c --- /dev/null +++ b/docs/cs-basics/network/images/osi&tcp-ip-model/TCP-IP-4-model.drawio @@ -0,0 +1 @@ +7VzZbuM2FP0aAu1DCu0iHyVbmQJFgQIpujwVtEXL6mjxyPLEnq8vL0nJWujEznhJZzwDJBR33UOeu5AKsif59kNFV8tfy5hlyDLiLbKnyLJM0/D4L8jZyRxCfJmRVGmsKu0zntIvTGUaKneTxmzdq1iXZVanq37mvCwKNq97ebSqyud+tUWZ9Udd0YSNMp7mNBvn/pnG9VLmYsvf5//M0mTZjGx6RJbktKms3mS9pHH53MmyI2RPqrKsZSrfTlgGwmvkIts9HihtJ1axoj6mQfB79Aum4VOaT93oj392y60xfbBVN59ptlFvjCKMAhMFGEU+ChwUBihyUWgibKkXqXeNdKpyU8QMBjCRHT4v05o9regcSp/5euB5yzrPVPGiLGoFMJ8qf06zbFJmZSX6smOX4djh+eu6Kj+yTgm2Zrbn8ZIko2vAE1q34oSu52WezlV6LJfmHVlVs20nS8npAytzVlc7XkWVtqtPLVrfUc/P+yVgNrguO/B7Ko+qVZe0Xe+B4QmFzSk4WRqcXMCGOIAT/wmAXQUnyvBirsPJm2M2W9wQJw/fHCdbgxPfQxNEArGxHhGZXgenxYJ5cy1OsU9mhnFDnLBxc5ycQzgFBuAURojYV8IJz5kepxl2HfemOHk3x8nV4OSjcIqIKRIhIpPr4MRMrqF8HU7E8216S/1ErJvj5Glw8hDhwBiQwFMURCgisKv43oId5gMZXgU5c0ZNZumQMwwv4rOQPfS4E/7dEtHbazJfu/MwQQERFoeBsHcd/AzDNdhCj5855Zz9/vAzjdubjHgEoDmCib9e3ceiL+OiLNgAEJVFszQp+OOcC43x/BCElXLHKVAFeRrHMIwW/P3yMDT4nwEQ0x4CYo8BcTR4WBfDg4zwGG+b7wYPotkfV4WjGazLb0M0WBEHEEMAsQKRAGO8xFtsm9Z/qTJI/w3y/MlVT9OtEq942KmHg7Jdl5tqzl5aUGrCLO6FMMYQdETsakTc5FUso3X6uc8VOrmrEX4rUz7lFmHb6yPsmwPo5AupVt1AxaAj57WOalolrB51JJZB+9pfsTI0MRHLy2Bfrle06C0R79MG4jdcnYjNGIAYk9kPHncv+KT5+IZvtUli/ojUfjJg6TysxdqBRqa32vbLnhVCUOqBv6QKZ3T+MRHb9WEwqOW67VCD9I/7mfJUIn6Du4NFdAeDbRYIe5oniC8st4koaiML3IQTNhskHkH5Q3NeOVSVsfBqcQD9KGFx4Ut5qQHfJ9f1rIKuudC1EC5AiI4zWOUan5hbB9dkRE2M6V0x4nshuoEq8/1zEd2wo0sTnSZY9Qaia1iuobiD/HaY3I5htpbWWk4TZDaitbHX6UIYGzsdr+URIj1YRLghNOcJDuTsZwsO5HU4GdoIy4SkNUP08yiat5XbnG7lCOFQ9QyuUqfysEhOg3zbhGl6ZyLM4W7RBKfs65qQmiDinTBfJ0xsn4kwRx1dmjA10cgbEqbYqw9ruVmhpCirnGZnZVN/bxsOudOF6Ks0EoNQEFvLgiIwGzqCgwNg330RQdgX1iI3J7khGe1ZUHOe5cNP6FkUccMTrE4icggYqqGsHAh2Hx2z3Gn1DbSKNbFkW0cOl6NVTSz5TqtH0Co5F60OO7o0rWpCza/R6qzcAlumRSKJbVZWMaseePZxbvRZHfYL+OQiAcTpAu2FRlMUdpxzyaBhhyZfYEcCBExkz4+C0ceefFunQ8Cq+diqHp+Wfl+BgLMRsD/YfZqjH9u/KgGPTw7uBHwEARP3TAQ86ujSBDw+mrgDfgTgpnGuGPe4pwtD3kjkDvmpkJ8r2jfu6dKQv+Fc4wUz6xXn9JA/O7J51BSgvnYKR3cEZgdubidI82VsozhgQoGFhME8UnWkyXXKdRX9MYgj6vCiiXB1pWMrrifBuUok7k9EYggfmvBxweSyhFX3wiEMBnMKy+sXFlh4GjvPEz6vo65oQB0Pha5yxrsmIBYzJBhmspcPUe753mKTePQx+oYNuYzOWBa2dvxwxv3rJc4U/p/L/3YHtHDzuKarOwh6l/7YguZptpPNZJXmp0fzlaho2+JOOUtKxgs26ajocKMlyz4zWIUntKFVSrNT6q9WGWvfn6u9vPz3lDl2X+zrGq93+aw8ZepZOmMV162lWBG0WJ/QdsUXyoLyxcJbzk9oxzdwVa7LBaiKHeW74RQ404omaVG2szWS2QnNn1nxaUOLHchKTENuxzf28IUVJ7df17JJfVKjND9xlDRfb4qvfy344KVaHe4HMHhYsypd9Pf0xWMsrTIXZkIoDu2I1SjqR6GNXYgfc5XYjXZjrlHtRplr7QUXNLYMmwxvKHcCKWBuYDEN2bxrXESizndxLnipixS6m2XXjZ+4bzhXv+vPu/6868+7/vwf6M/xkbDOmx26rLKOPBLmzd0XzxZGhxV3TXiEJrSbc7vWldTcKbyyKjziikxfeK98KlLykrTeNVJLKhqnbO+cKzRjul62H5/IJdB8vW2fR9Ym7rvt2k9PdaI28cVkrbud8k3IerCutR9HaWV9uXU9vqNgv1M2usLHHLojy+tGrMY3CJzvFw7dzcgzwcEf93+xQh5M7P/uhx39Bw== \ No newline at end of file diff --git a/docs/cs-basics/network/images/osi&tcp-ip-model/TCP-IP-4-model.png b/docs/cs-basics/network/images/osi&tcp-ip-model/TCP-IP-4-model.png new file mode 100644 index 0000000000000000000000000000000000000000..7db48d8cc6233cec66b0ae479fd6c347ce6dbf9e Binary files /dev/null and b/docs/cs-basics/network/images/osi&tcp-ip-model/TCP-IP-4-model.png differ diff --git a/docs/cs-basics/network/images/osi&tcp-ip-model/application-layer.drawio b/docs/cs-basics/network/images/osi&tcp-ip-model/application-layer.drawio new file mode 100644 index 0000000000000000000000000000000000000000..bc0d38289678ac25dde43a0dedc2fe3751517d78 --- /dev/null +++ b/docs/cs-basics/network/images/osi&tcp-ip-model/application-layer.drawio @@ -0,0 +1 @@ +5Zhbb5swFMc/jR8rYQzGPAaaLFPVaRKT9uyAuawGZ8Rpkn362eCEa6VVapJJVaTE/p/jS87v2MYAFJbHLzXd5s8iYRzYVnIE6BHYNoQWVj9aObWK73utkNVFYpw6ISr+MCNaRt0XCdsNHKUQXBbboRiLqmKxHGi0rsVh6JYKPhx1SzM2EaKY8qn6s0hk3qrE9jp9zYosP48Msd9aSnp2Nv9kl9NEHHoSWgIU1kLItlQeQ8Z18M5xadut3rBeJlazSv5Lg234dHplx+Al/lU4NHjKTnb9gNpeXinfmz9sJitP5wjUYl8lTHcCAQoOeSFZtKWxth4Uc6XlsuTGnIpKGohqOqpecB4KLuqmL5RQRtJY6TtZixfWs+CYsE2qLBmnO81Mt76ETHcdi7KITdnMmtWSHd8MB7wEWWUnEyWT9Um5mAa25bRNTGI6xHA6dJgdz2Rv3kOMXONITWpll7676KuCAfAOGM4UxtIFwQL4Dlh6+ntBGgUCMuWkQiGHMIZBrkTFRkSMRHmRVaoaq9AxpQc6sIVaAwtjKIsk0cPM0u/ywxolAPoYUgihASnXmpKyIZmScq4Fyp2AWv/48f2qKyclMYtnV86GuI5r3XLlIGvIw5/ygOddr88DX4sHnvBYXRtHmtrzOBK8wS6+IQ4Ehziwd28c3gTH4zq8Lo/EZSRx5ngQe4PwLXk4cHiwuHfnQaY8vkVXxcGgAuLN4fCxh+gtcbguHC4P+944/AmO6PkTnR7ecLvynHvzOO+fPSBfnxef5vxw/BEQfHcgcLpCovVn2bAcPDrP7/54ZU9w6FsIccEiBEsHBCFQl3qtrECgCqtGWYQRWGJAQkBa46P2sjHXl5RNrUqZbALWKT24+Pde34sbbA+7httCOUC8PXbGro//8irE6YbxgMYvWaOPB+8SEmJT76Vd0HyaPiWVhdBjP6DxRv0R+/Ho8dGd24/JTLrB96ebqnbvOxpb760RWv4F \ No newline at end of file diff --git a/docs/cs-basics/network/images/osi&tcp-ip-model/application-layer.png b/docs/cs-basics/network/images/osi&tcp-ip-model/application-layer.png new file mode 100644 index 0000000000000000000000000000000000000000..a1ec5c7e0182f0fdbf77e539f4c0f2cf53b1cebe Binary files /dev/null and b/docs/cs-basics/network/images/osi&tcp-ip-model/application-layer.png differ diff --git a/docs/cs-basics/network/images/osi&tcp-ip-model/nerwork-layer.drawio b/docs/cs-basics/network/images/osi&tcp-ip-model/nerwork-layer.drawio new file mode 100644 index 0000000000000000000000000000000000000000..8940fe5003fa179c532b2f0054b211d1dcb9193e --- /dev/null +++ b/docs/cs-basics/network/images/osi&tcp-ip-model/nerwork-layer.drawio @@ -0,0 +1 @@ +5Zhdb5swFIZ/jS8jYQzGXAZK2knrWjXTJu3OgCGoBqfEWdL9+hlwwmelVSrJpCoXsd/jL85zjo0ByM+PtyXdbu5FzDgwjfgI0A0wTQgNrP4q5bVRXNdphLTMYt2oFdbZH6ZFQ6v7LGa7XkMpBJfZti9GoihYJHsaLUtx6DdLBO/PuqUpGwnriPKx+jOL5aZRiem0+h3L0s1pZojdxpLTU2P9JLsNjcWhI6EAIL8UQjal/OgzXjnv5Jem3+oN63lhJSvkv3QI7n5Yd1+tPHnJ//x62C/iYHe70KP8pnyvH1gvVr6ePFCKfRGzahAIkHfYZJKttzSqrAfFXGkbmXNtTkQhNUS1HFXPOPcFF2U9FoopI0mk9J0sxTPrWHBEWJgoS8rprmJW9T67rBo6EnkW6bJeNSslO77pDnh2sopOJnImy1fVRHcwDavpogPTIprTocVsOTp6Nx3EyNYNqQ6t9Dx2631V0ADeAcMcwwgc4N0AF9YFD7g+CGzgQUDGnJQrZB9G38mFKNiAiJYoz9JCVSPlOqZ0r3JspnJgqQ15FsfVNJP02/gwBgGAPoYUQqhHyjbGpExIxqSsuUChEagvj7PmTUIiFk3mTUhsyzYumTfI6NNwxzTgac/r0sBz0bBGNL4tv8+LI0nMaRwxDrGNL4gDwT4O7Fwbhz3CsXyaNztim5HYmsJBzBDhS+KwYP9Usa+OA4/3Kv9+5t0qYfiN9HDc0LjkbmXbsJ8e5rV5OCMeTzMfHgyqBHGmcLjYQfSS6WE6/d3Ksa6Ng4xweLefBoflDnDga+NwRzge1o+rT8MDDw7zq79bnd4uencSGxAbLNVVxAKeD9SFvlJWwFOFVa0s/TUIMCA+II3xpmplYl5dUMJSlVJZe6xVOnTxy766E9fcFrsa3FI1gHh7bI3tGP/lNYjTkHGPRs9prQ8nbyMSYl3vxJ1X/+oxJZWZqOZeoOGx+RHb8eDl0Z7ajslEvMH3x5uqtt86alvnixEK/gI= \ No newline at end of file diff --git a/docs/cs-basics/network/images/osi&tcp-ip-model/nerwork-layer.png b/docs/cs-basics/network/images/osi&tcp-ip-model/nerwork-layer.png new file mode 100644 index 0000000000000000000000000000000000000000..4c3088c5a7cb4bf2491ca53e0b60b67595cdd987 Binary files /dev/null and b/docs/cs-basics/network/images/osi&tcp-ip-model/nerwork-layer.png differ diff --git a/docs/cs-basics/network/images/osi&tcp-ip-model/network-interface-layer.drawio b/docs/cs-basics/network/images/osi&tcp-ip-model/network-interface-layer.drawio new file mode 100644 index 0000000000000000000000000000000000000000..22d0b52a1479902e4f63b7ddfde6b57957732891 --- /dev/null +++ b/docs/cs-basics/network/images/osi&tcp-ip-model/network-interface-layer.drawio @@ -0,0 +1 @@ +5ZdNj5swEIZ/jY8rYQzGHIGQblXtoc2h6qlywCFoHZwSp0n213cMToDASl1pk61UIUXmHX9lnpmxQSTZHD/VfLt+UrmQyHXyIyIz5LoBxfBrhFMrYHhapajL3GqdsChfhBUdq+7LXOwGHbVSUpfboZipqhKZHmi8rtVh2G2l5HDVLS/ESFhkXI7V72Wu163K3KDTH0VZrM8rYxq2lg0/d7b/ZLfmuTr0JJIiktRK6ba1OSZCGued/dKOm79ivWysFpX+mwHh/uVH+ONLhANcPJ5mn79++zl7sLP85nJv/7DdrD6dPVCrfZULMwlGJD6sSy0WW54Z6wGYg7bWG2nNK1VpCxG2A++llImSqm7mIjkXbJWBvtO1ehY9C82YWK7AUki+M8zM6IvLzNSZ2pSZbdtdi1qL46vuwBcnQ3QKtRG6PkEXO8B1vHaIjUyPWU6HDrMX0FZb9xAT33bkNrSKy9yd96FhAbwBhjuGkQYonqEQN40YhQlKKWIpinyU+ojNUURGwMAnekhl6O1KVeIKjZW4LIsKXjPwoQA9Nh4uIRkia9iUeW6WmQyDLlCcq0gg74OMEDJA5jtjZC5mY2TerYiREbFk8RTBVMnspnm0YpnIJvNoyXzPd+6ZR8QZQgnHUPC5Bvah0FtB8UdQnqLktmXNFyz3pnAwd0kovSMODw/Lmh98NA46UdV8FAcoSlEaotBDYWiqGlQyKMHQiKGwxbdNn5Wg0+mTB+HSuWf6+GTIi5KP5sUmeHnm8GnPnMhDUdSdS7fEJDAkVjCFKaQB4fdMq8tRYzEF7kdjCifTCuiEQIc1+TU3DciyeN4kWpNx/wkvgq94TVwV7svrvKErYAyYJU2CJYZQe6kDeOm8UaJk0dz4EsRa48z0cqk0N7xlDa1CNx7rlB5d+mtvvi4abg+7BhxcThxMt8fO2M3xT94jJV8KGfPsuWj068W7iMTUvvfiLm6eZk7NdanM2g/kur6/xy3oKt58byLe2ES84bfHG7x2X42NrfftTdI/ \ No newline at end of file diff --git a/docs/cs-basics/network/images/osi&tcp-ip-model/network-interface-layer.png b/docs/cs-basics/network/images/osi&tcp-ip-model/network-interface-layer.png new file mode 100644 index 0000000000000000000000000000000000000000..5c1d78017ed0428226e8fc8f240089f199ca4154 Binary files /dev/null and b/docs/cs-basics/network/images/osi&tcp-ip-model/network-interface-layer.png differ diff --git a/docs/cs-basics/network/images/osi&tcp-ip-model/osi-model-detail.png b/docs/cs-basics/network/images/osi&tcp-ip-model/osi-model-detail.png new file mode 100644 index 0000000000000000000000000000000000000000..2d7d69d5a8ebace2f18c2dbf66eb89269e30e2f2 Binary files /dev/null and b/docs/cs-basics/network/images/osi&tcp-ip-model/osi-model-detail.png differ diff --git a/docs/cs-basics/network/images/osi&tcp-ip-model/transport-layer.png b/docs/cs-basics/network/images/osi&tcp-ip-model/transport-layer.png new file mode 100644 index 0000000000000000000000000000000000000000..ed7bcc21f61cebc2a72322ec542a4b4be11f1f53 Binary files /dev/null and b/docs/cs-basics/network/images/osi&tcp-ip-model/transport-layer.png differ diff --git a/docs/cs-basics/network/osi&tcp-ip-model.md b/docs/cs-basics/network/osi&tcp-ip-model.md new file mode 100644 index 0000000000000000000000000000000000000000..24d1941182ebd7e7c32557caff696e41515e8e14 --- /dev/null +++ b/docs/cs-basics/network/osi&tcp-ip-model.md @@ -0,0 +1,116 @@ +--- +title: OSI 和 TCP/IP 网络分层模型详解（基础） +category: 计算机基础 +tag: + - 计算机网络 +--- + +> 本文由 [SnailClimb](https://github.com/Snailclimb) 和 [csguide-dabai](https://github.com/csguide-dabai) （公众号“CS指南”作者）共同完成。 + +## OSI 七层模型 + +**OSI 七层模型** 是国际标准化组织提出一个网络分层模型，其大体结构以及每一层提供的功能如下图所示： + +![osi七层模型](https://guide-blog-images.oss-cn-shenzhen.aliyuncs.com/github/javaguide/osi%E4%B8%83%E5%B1%82%E6%A8%A1%E5%9E%8B.png) + +每一层都专注做一件事情，并且每一层都需要使用下一层提供的功能比如传输层需要使用网络层提供的路有和寻址功能，这样传输层才知道把数据传输到哪里去。 + +**OSI 的七层体系结构概念清楚，理论也很完整，但是它比较复杂而且不实用，而且有些功能在多个层中重复出现。** + +上面这种图可能比较抽象，再来一个比较生动的图片。下面这个图片是我在国外的一个网站上看到的，非常赞！ + +![osi七层模型2](https://guide-blog-images.oss-cn-shenzhen.aliyuncs.com/github/javaguide/osi七层模型2.png) + +**既然 OSI 七层模型这么厉害，为什么干不过 TCP/IP 四 层模型呢？** + +的确，OSI 七层模型当时一直被一些大公司甚至一些国家政府支持。这样的背景下，为什么会失败呢？我觉得主要有下面几方面原因： + +1. OSI 的专家缺乏实际经验，他们在完成 OSI 标准时缺乏商业驱动力 +2. OSI 的协议实现起来过分复杂，而且运行效率很低 +3. OSI 制定标准的周期太长，因而使得按 OSI 标准生产的设备无法及时进入市场（20 世纪 90 年代初期，虽然整套的 OSI 国际标准都已经制定出来，但基于 TCP/IP 的互联网已经抢先在全球相当大的范围成功运行了） +4. OSI 的层次划分不太合理，有些功能在多个层次中重复出现。 + +OSI 七层模型虽然失败了，但是却提供了很多不错的理论基础。为了更好地去了解网络分层，OSI 七层模型还是非常有必要学习的。 + +最后再分享一个关于 OSI 七层模型非常不错的总结图片！ + +![](./images/osi&tcp-ip-model/osi-model-detail.png) + +## TCP/IP 四层模型 + +**TCP/IP 四层模型** 是目前被广泛采用的一种模型,我们可以将 TCP / IP 模型看作是 OSI 七层模型的精简版本，由以下 4 层组成： + +1. 应用层 +2. 传输层 +3. 网络层 +4. 网络接口层 + +需要注意的是，我们并不能将 TCP/IP 四层模型 和 OSI 七层模型完全精确地匹配起来，不过可以简单将两者对应起来，如下图所示： + +![TCP-IP-4-model](./images/osi&tcp-ip-model/TCP-IP-4-model.png) + +### 应用层（Application layer） + +**应用层位于传输层之上，主要提供两个终端设备上的应用程序之间信息交换的服务，它定义了信息交换的格式，消息会交给下一层传输层来传输。** 我们把应用层交互的数据单元称为报文。 + +![](https://guide-blog-images.oss-cn-shenzhen.aliyuncs.com/github/javaguide/5971-2-7I1-20220111095024771-20220111201807861.png) + +应用层协议定义了网络通信规则，对于不同的网络应用需要不同的应用层协议。在互联网中应用层协议很多，如支持 Web 应用的 HTTP 协议，支持电子邮件的 SMTP 协议等等。 + +![application-layer](./images/osi&tcp-ip-model/application-layer.png) + +### 传输层（Transport layer） + +**传输层的主要任务就是负责向两台终端设备进程之间的通信提供通用的数据传输服务。** 应用进程利用该服务传送应用层报文。“通用的”是指并不针对某一个特定的网络应用，而是多种应用可以使用同一个运输层服务。 + +**运输层主要使用以下两种协议：** + +1. **传输控制协议 TCP**（Transmisson Control Protocol）--提供**面向连接**的，**可靠的**数据传输服务。 +2. **用户数据协议 UDP**（User Datagram Protocol）--提供**无连接**的，尽最大努力的数据传输服务（**不保证数据传输的可靠性**）。 + +![transport-layer](./images/osi&tcp-ip-model/transport-layer.png) + +### 网络层（Network layer） + +**网络层负责为分组交换网上的不同主机提供通信服务。** 在发送数据时，网络层把运输层产生的报文段或用户数据报封装成分组和包进行传送。在 TCP/IP 体系结构中，由于网络层使用 IP 协议，因此分组也叫 IP 数据报，简称数据报。 + +注意 ⚠️：**不要把运输层的“用户数据报 UDP”和网络层的“IP 数据报”弄混**。 + +**网络层的还有一个任务就是选择合适的路由，使源主机运输层所传下来的分株，能通过网络层中的路由器找到目的主机。** + +这里强调指出，网络层中的“网络”二字已经不是我们通常谈到的具体网络，而是指计算机网络体系结构模型中第三层的名称。 + +互联网是由大量的异构（heterogeneous）网络通过路由器（router）相互连接起来的。互联网使用的网络层协议是无连接的网际协议（Intert Prococol）和许多路由选择协议，因此互联网的网络层也叫做**网际层**或**IP 层**。 + +![](./images/osi&tcp-ip-model/nerwork-layer.png) + +### 网络接口层（Network interface layer） + +我们可以把网络接口层看作是数据链路层和物理层的合体。 + +1. 数据链路层(data link layer)通常简称为链路层（ 两台主机之间的数据传输，总是在一段一段的链路上传送的）。**数据链路层的作用是将网络层交下来的 IP 数据报组装成帧，在两个相邻节点间的链路上传送帧。每一帧包括数据和必要的控制信息（如同步信息，地址信息，差错控制等）。** +2. **物理层的作用是实现相邻计算机节点之间比特流的透明传送，尽可能屏蔽掉具体传输介质和物理设备的差异** + +![network-interface-layer](./images/osi&tcp-ip-model/network-interface-layer.png) + +## 为什么网络要分层？ + +在这篇文章的最后，我想聊聊：“为什么网络要分层？”。 + +说到分层，我们先从我们平时使用框架开发一个后台程序来说，我们往往会按照每一层做不同的事情的原则将系统分为三层（复杂的系统分层会更多）: + +1. Repository（数据库操作） +2. Service（业务操作） +3. Controller（前后端数据交互） + +**复杂的系统需要分层，因为每一层都需要专注于一类事情。网络分层的原因也是一样，每一层只专注于做一类事情。** + +好了，再来说回：“为什么网络要分层？”。我觉得主要有 3 方面的原因： + +1. **各层之间相互独立**：各层之间相互独立，各层之间不需要关心其他层是如何实现的，只需要知道自己如何调用下层提供好的功能就可以了（可以简单理解为接口调用）**。这个和我们对开发时系统进行分层是一个道理。** +2. **提高了整体灵活性** ：每一层都可以使用最适合的技术来实现，你只需要保证你提供的功能以及暴露的接口的规则没有改变就行了。**这个和我们平时开发系统的时候要求的高内聚、低耦合的原则也是可以对应上的。** +3. **大问题化小** ： 分层可以将复杂的网络间题分解为许多比较小的、界线比较清晰简单的小问题来处理和解决。这样使得复杂的计算机网络系统变得易于设计，实现和标准化。 **这个和我们平时开发的时候，一般会将系统功能分解，然后将复杂的问题分解为容易理解的更小的问题是相对应的，这些较小的问题具有更好的边界（目标和接口）定义。** + +我想到了计算机世界非常非常有名的一句话，这里分享一下： + +> 计算机科学领域的任何问题都可以通过增加一个间接的中间层来解决，计算机整个体系从上到下都是按照严格的层次结构设计的。 \ No newline at end of file diff --git a/docs/cs-basics/network/other-network-questions.md b/docs/cs-basics/network/other-network-questions.md new file mode 100644 index 0000000000000000000000000000000000000000..f482220c2ef7037a6e4bd599bce0f3b547e2dd05 --- /dev/null +++ b/docs/cs-basics/network/other-network-questions.md @@ -0,0 +1,292 @@ +--- +title: 计算机网络常见知识点&面试题（补充） +category: 计算机基础 +tag: + - 计算机网络 +--- + +## 应用层有哪些常见的协议？ + +### HTTP:超文本传输协议 + +**超文本传输协议（HTTP，HyperText Transfer Protocol)** 主要是为 Web 浏览器与 Web 服务器之间的通信而设计的。当我们使用浏览器浏览网页的时候，我们网页就是通过 HTTP 请求进行加载的，整个过程如下图所示。 + +![](https://guide-blog-images.oss-cn-shenzhen.aliyuncs.com/github/javaguide/450px-HTTP-Header.png) + +HTTP 协是基于 TCP协议，发送 HTTP 请求之前首先要建立 TCP 连接也就是要经历 3 次握手。目前使用的 HTTP 协议大部分都是 1.1。在 1.1 的协议里面，默认是开启了 Keep-Alive 的，这样的话建立的连接就可以在多次请求中被复用了。 + + +另外， HTTP 协议是”无状态”的协议，它无法记录客户端用户的状态，一般我们都是通过 Session 来记录客户端用户的状态。 + +### SMTP:简单邮件传输(发送)协议 + +**简单邮件传输(发送)协议（SMTP，Simple Mail Transfer Protocol）** 基于 TCP 协议，用来发送电子邮件。 + +注意⚠️：**接受邮件的协议不是 SMTP 而是 POP3 协议。** + +SMTP 协议这块涉及的内容比较多，下面这两个问题比较重要： + +1. 电子邮件的发送过程 +2. 如何判断邮箱是真正存在的？ + +**电子邮件的发送过程？** + +比如我的邮箱是“dabai@cszhinan.com”，我要向“xiaoma@qq.com”发送邮件，整个过程可以简单分为下面几步： + +1. 通过 **SMTP** 协议，我将我写好的邮件交给163邮箱服务器（邮局）。 +2. 163邮箱服务器发现我发送的邮箱是qq邮箱，然后它使用 SMTP协议将我的邮件转发到 qq邮箱服务器。 +3. qq邮箱服务器接收邮件之后就通知邮箱为“xiaoma@qq.com”的用户来收邮件，然后用户就通过 **POP3/IMAP** 协议将邮件取出。 + +**如何判断邮箱是真正存在的？** + +很多场景(比如邮件营销)下面我们需要判断我们要发送的邮箱地址是否真的存在，这个时候我们可以利用 SMTP 协议来检测： + +1. 查找邮箱域名对应的 SMTP 服务器地址 +2. 尝试与服务器建立连接 +3. 连接成功后尝试向需要验证的邮箱发送邮件 +4. 根据返回结果判定邮箱地址的真实性 + +推荐几个在线邮箱是否有效检测工具： + +1. https://verify-email.org/ +2. http://tool.chacuo.net/mailverify +3. https://www.emailcamel.com/ + +### POP3/IMAP:邮件接收的协议 + +这两个协议没必要多做阐述，只需要了解 **POP3 和 IMAP 两者都是负责邮件接收的协议**即可。另外，需要注意不要将这两者和 SMTP 协议搞混淆了。**SMTP 协议只负责邮件的发送，真正负责接收的协议是POP3/IMAP。** + +IMAP 协议相比于POP3更新一点，为用户提供的可选功能也更多一点,几乎所有现代电子邮件客户端和服务器都支持IMAP。大部分网络邮件服务提供商都支持POP3和IMAP。 + +### FTP:文件传输协议 + +**FTP 协议** 主要提供文件传输服务，基于 TCP 实现可靠的传输。使用 FTP 传输文件的好处是可以屏蔽操作系统和文件存储方式。 + +FTP 是基于客户—服务器（C/S）模型而设计的，在客户端与 FTP 服务器之间建立两个连接。如果我们要基于 FTP 协议开发一个文件传输的软件的话，首先需要搞清楚 FTP 的原理。关于 FTP 的原理，很多书籍上已经描述的非常详细了： + +> FTP 的独特的优势同时也是与其它客户服务器程序最大的不同点就在于它在两台通信的主机之间使用了两条 TCP 连接（其它客户服务器应用程序一般只有一条 TCP 连接）： +> +> 1. 控制连接：用于传送控制信息（命令和响应） +> 2. 数据连接：用于数据传送； +> +> 这种将命令和数据分开传送的思想大大提高了 FTP 的效率。 + +![FTP工作过程](https://guide-blog-images.oss-cn-shenzhen.aliyuncs.com/%E8%AE%A1%E7%AE%97%E6%9C%BA%E7%BD%91%E7%BB%9C%E6%80%BB%E7%BB%93/ftp.png) + + +### Telnet:远程登陆协议 + +**Telnet 协议** 通过一个终端登陆到其他服务器，建立在可靠的传输协议 TCP 之上。Telnet 协议的最大缺点之一是所有数据（包括用户名和密码）均以明文形式发送，这有潜在的安全风险。这就是为什么如今很少使用Telnet并被一种称为SSH的非常安全的协议所取代的主要原因。 + +### SSH:安全的网络传输协议 + +**SSH（ Secure Shell）** 是目前较可靠，专为远程登录会话和其他网络服务提供安全性的协议。利用 SSH 协议可以有效防止远程管理过程中的信息泄露问题。SSH 建立在可靠的传输协议 TCP 之上。 + +**Telnet 和 SSH 之间的主要区别在于 SSH 协议会对传输的数据进行加密保证数据安全性。** + +## TCP 三次握手和四次挥手(面试常客) + +为了准确无误地把数据送达目标处，TCP 协议采用了三次握手策略。 + +### TCP 三次握手漫画图解 + +如下图所示，下面的两个机器人通过 3 次握手确定了对方能正确接收和发送消息(图片来源：《图解 HTTP》)。 + +![TCP三次握手](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/2019/7/三次握手.png) + +**简单示意图：** + +![TCP三次握手](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/2019/7/三次握手2.png) + +* 客户端–发送带有 SYN 标志的数据包–一次握手–服务端 +* 服务端–发送带有 SYN/ACK 标志的数据包–二次握手–客户端 +* 客户端–发送带有带有 ACK 标志的数据包–三次握手–服务端 + +**详细示意图（图片来源不详）** + +![](https://img-blog.csdnimg.cn/img_convert/0c9f470819684156cfdc27c682db4def.png) + +### 为什么要三次握手 + +**三次握手的目的是建立可靠的通信信道，说到通讯，简单来说就是数据的发送与接收，而三次握手最主要的目的就是双方确认自己与对方的发送与接收是正常的。** + +第一次握手：Client 什么都不能确认；Server 确认了对方发送正常，自己接收正常 + +第二次握手：Client 确认了：自己发送、接收正常，对方发送、接收正常；Server 确认了：对方发送正常，自己接收正常 + +第三次握手：Client 确认了：自己发送、接收正常，对方发送、接收正常；Server 确认了：自己发送、接收正常，对方发送、接收正常 + +所以三次握手就能确认双方收发功能都正常，缺一不可。 + +### 第 2 次握手传回了 ACK，为什么还要传回 SYN？ + +接收端传回发送端所发送的 ACK 是为了告诉客户端，我接收到的信息确实就是你所发送的信号了，这表明从客户端到服务端的通信是正常的。而回传 SYN 则是为了建立并确认从服务端到客户端的通信。” + +> SYN 同步序列编号(Synchronize Sequence Numbers) 是 TCP/IP 建立连接时使用的握手信号。在客户机和服务器之间建立正常的 TCP 网络连接时，客户机首先发出一个 SYN 消息，服务器使用 SYN-ACK 应答表示接收到了这个消息，最后客户机再以 ACK(Acknowledgement）消息响应。这样在客户机和服务器之间才能建立起可靠的 TCP 连接，数据才可以在客户机和服务器之间传递。 + +### 为什么要四次挥手 + +![TCP四次挥手](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/2019/7/TCP四次挥手.png) + +断开一个 TCP 连接则需要“四次挥手”： + +* 客户端-发送一个 FIN，用来关闭客户端到服务器的数据传送 +* 服务器-收到这个 FIN，它发回一 个 ACK，确认序号为收到的序号加 1 。和 SYN 一样，一个 FIN 将占用一个序号 +* 服务器-关闭与客户端的连接，发送一个 FIN 给客户端 +* 客户端-发回 ACK 报文确认，并将确认序号设置为收到序号加 1 + +任何一方都可以在数据传送结束后发出连接释放的通知，待对方确认后进入半关闭状态。当另一方也没有数据再发送的时候，则发出连接释放通知，对方确认后就完全关闭了 TCP 连接。 + +举个例子：A 和 B 打电话，通话即将结束后，A 说“我没啥要说的了”，B 回答“我知道了”，但是 B 可能还会有要说的话，A 不能要求 B 跟着自己的节奏结束通话，于是 B 可能又巴拉巴拉说了一通，最后 B 说“我说完了”，A 回答“知道了”，这样通话才算结束。 + +上面讲的比较概括，推荐一篇讲的比较细致的文章：[https://blog.csdn.net/qzcsu/article/details/72861891](https://blog.csdn.net/qzcsu/article/details/72861891) + +## TCP, UDP 协议的区别 + +![TCP、UDP协议的区别](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/2019-11/tcp-vs-udp.jpg) + +UDP 在传送数据之前不需要先建立连接，远地主机在收到 UDP 报文后，不需要给出任何确认。虽然 UDP 不提供可靠交付，但在某些情况下 UDP 却是一种最有效的工作方式（一般用于即时通信），比如： QQ 语音、 QQ 视频 、直播等等 + +TCP 提供面向连接的服务。在传送数据之前必须先建立连接，数据传送结束后要释放连接。 TCP 不提供广播或多播服务。由于 TCP 要提供可靠的，面向连接的传输服务（TCP 的可靠体现在 TCP 在传递数据之前，会有三次握手来建立连接，而且在数据传递时，有确认、窗口、重传、拥塞控制机制，在数据传完后，还会断开连接用来节约系统资源），这难以避免增加了许多开销，如确认，流量控制，计时器以及连接管理等。这不仅使协议数据单元的首部增大很多，还要占用许多处理机资源。TCP 一般用于文件传输、发送和接收邮件、远程登录等场景。 + +## TCP 协议如何保证可靠传输 + +1. 应用数据被分割成 TCP 认为最适合发送的数据块。 +2. TCP 给发送的每一个包进行编号，接收方对数据包进行排序，把有序数据传送给应用层。 +3. **校验和：** TCP 将保持它首部和数据的检验和。这是一个端到端的检验和，目的是检测数据在传输过程中的任何变化。如果收到段的检验和有差错，TCP 将丢弃这个报文段和不确认收到此报文段。 +4. TCP 的接收端会丢弃重复的数据。 +5. **流量控制：** TCP 连接的每一方都有固定大小的缓冲空间，TCP 的接收端只允许发送端发送接收端缓冲区能接纳的数据。当接收方来不及处理发送方的数据，能提示发送方降低发送的速率，防止包丢失。TCP 使用的流量控制协议是可变大小的滑动窗口协议。 （TCP 利用滑动窗口实现流量控制） +6. **拥塞控制：** 当网络拥塞时，减少数据的发送。 +7. **ARQ 协议：** 也是为了实现可靠传输的，它的基本原理就是每发完一个分组就停止发送，等待对方确认。在收到确认后再发下一个分组。 +8. **超时重传：** 当 TCP 发出一个段后，它启动一个定时器，等待目的端确认收到这个报文段。如果不能及时收到一个确认，将重发这个报文段。 + +### ARQ 协议 + +**自动重传请求**（Automatic Repeat-reQuest，ARQ）是 OSI 模型中数据链路层和传输层的错误纠正协议之一。它通过使用确认和超时这两个机制，在不可靠服务的基础上实现可靠的信息传输。如果发送方在发送后一段时间之内没有收到确认帧，它通常会重新发送。ARQ 包括停止等待 ARQ 协议和连续 ARQ 协议。 + +#### 停止等待 ARQ 协议 + +停止等待协议是为了实现可靠传输的，它的基本原理就是每发完一个分组就停止发送，等待对方确认（回复 ACK）。如果过了一段时间（超时时间后），还是没有收到 ACK 确认，说明没有发送成功，需要重新发送，直到收到确认后再发下一个分组。 + +在停止等待协议中，若接收方收到重复分组，就丢弃该分组，但同时还要发送确认。 + +**优缺点：** + +* **优点：** 简单 +* **缺点：** 信道利用率低，等待时间长 + +**1) 无差错情况:** + +发送方发送分组, 接收方在规定时间内收到, 并且回复确认. 发送方再次发送。 + +**2) 出现差错情况（超时重传）:** + +停止等待协议中超时重传是指只要超过一段时间仍然没有收到确认，就重传前面发送过的分组（认为刚才发送过的分组丢失了）。因此每发送完一个分组需要设置一个超时计时器，其重传时间应比数据在分组传输的平均往返时间更长一些。这种自动重传方式常称为 **自动重传请求 ARQ** 。另外在停止等待协议中若收到重复分组，就丢弃该分组，但同时还要发送确认。**连续 ARQ 协议** 可提高信道利用率。发送维持一个发送窗口，凡位于发送窗口内的分组可连续发送出去，而不需要等待对方确认。接收方一般采用累积确认，对按序到达的最后一个分组发送确认，表明到这个分组位置的所有分组都已经正确收到了。 + +**3) 确认丢失和确认迟到** + +* **确认丢失** ：确认消息在传输过程丢失。当 A 发送 M1 消息，B 收到后，B 向 A 发送了一个 M1 确认消息，但却在传输过程中丢失。而 A 并不知道，在超时计时过后，A 重传 M1 消息，B 再次收到该消息后采取以下两点措施：1. 丢弃这个重复的 M1 消息，不向上层交付。 2. 向 A 发送确认消息。（不会认为已经发送过了，就不再发送。A 能重传，就证明 B 的确认消息丢失）。 +* **确认迟到** ：确认消息在传输过程中迟到。A 发送 M1 消息，B 收到并发送确认。在超时时间内没有收到确认消息，A 重传 M1 消息，B 仍然收到并继续发送确认消息（B 收到了 2 份 M1）。此时 A 收到了 B 第二次发送的确认消息。接着发送其他数据。过了一会，A 收到了 B 第一次发送的对 M1 的确认消息（A 也收到了 2 份确认消息）。处理如下：1. A 收到重复的确认后，直接丢弃。2. B 收到重复的 M1 后，也直接丢弃重复的 M1。 + +#### 连续 ARQ 协议 + +连续 ARQ 协议可提高信道利用率。发送方维持一个发送窗口，凡位于发送窗口内的分组可以连续发送出去，而不需要等待对方确认。接收方一般采用累积确认，对按序到达的最后一个分组发送确认，表明到这个分组为止的所有分组都已经正确收到了。 + +**优缺点：** + +* **优点：** 信道利用率高，容易实现，即使确认丢失，也不必重传。 +* **缺点：** 不能向发送方反映出接收方已经正确收到的所有分组的信息。 比如：发送方发送了 5 条 消息，中间第三条丢失（3 号），这时接收方只能对前两个发送确认。发送方无法知道后三个分组的下落，而只好把后三个全部重传一次。这也叫 Go-Back-N（回退 N），表示需要退回来重传已经发送过的 N 个消息。 + +### 滑动窗口和流量控制 + +**TCP 利用滑动窗口实现流量控制。流量控制是为了控制发送方发送速率，保证接收方来得及接收。** 接收方发送的确认报文中的窗口字段可以用来控制发送方窗口大小，从而影响发送方的发送速率。将窗口字段设置为 0，则发送方不能发送数据。 + +### 拥塞控制 + +在某段时间，若对网络中某一资源的需求超过了该资源所能提供的可用部分，网络的性能就要变坏。这种情况就叫拥塞。拥塞控制就是为了防止过多的数据注入到网络中，这样就可以使网络中的路由器或链路不致过载。拥塞控制所要做的都有一个前提，就是网络能够承受现有的网络负荷。拥塞控制是一个全局性的过程，涉及到所有的主机，所有的路由器，以及与降低网络传输性能有关的所有因素。相反，流量控制往往是点对点通信量的控制，是个端到端的问题。流量控制所要做到的就是抑制发送端发送数据的速率，以便使接收端来得及接收。 + +为了进行拥塞控制，TCP 发送方要维持一个 **拥塞窗口(cwnd)** 的状态变量。拥塞控制窗口的大小取决于网络的拥塞程度，并且动态变化。发送方让自己的发送窗口取为拥塞窗口和接收方的接受窗口中较小的一个。 + +TCP 的拥塞控制采用了四种算法，即 **慢开始** 、 **拥塞避免** 、**快重传** 和 **快恢复**。在网络层也可以使路由器采用适当的分组丢弃策略（如主动队列管理 AQM），以减少网络拥塞的发生。 + +* **慢开始：** 慢开始算法的思路是当主机开始发送数据时，如果立即把大量数据字节注入到网络，那么可能会引起网络阻塞，因为现在还不知道网络的符合情况。经验表明，较好的方法是先探测一下，即由小到大逐渐增大发送窗口，也就是由小到大逐渐增大拥塞窗口数值。cwnd 初始值为 1，每经过一个传播轮次，cwnd 加倍。 +* **拥塞避免：** 拥塞避免算法的思路是让拥塞窗口 cwnd 缓慢增大，即每经过一个往返时间 RTT 就把发送放的 cwnd 加 1. +* **快重传与快恢复：** + 在 TCP/IP 中，快速重传和恢复（fast retransmit and recovery，FRR）是一种拥塞控制算法，它能快速恢复丢失的数据包。没有 FRR，如果数据包丢失了，TCP 将会使用定时器来要求传输暂停。在暂停的这段时间内，没有新的或复制的数据包被发送。有了 FRR，如果接收机接收到一个不按顺序的数据段，它会立即给发送机发送一个重复确认。如果发送机接收到三个重复确认，它会假定确认件指出的数据段丢失了，并立即重传这些丢失的数据段。有了 FRR，就不会因为重传时要求的暂停被耽误。 　当有单独的数据包丢失时，快速重传和恢复（FRR）能最有效地工作。当有多个数据信息包在某一段很短的时间内丢失时，它则不能很有效地工作。 + +## 在浏览器中输入 url 地址 ->> 显示主页的过程(面试常客) + +百度好像最喜欢问这个问题。 + +> 打开一个网页，整个过程会使用哪些协议？ + +图解（图片来源：《图解 HTTP》）： + + + +> 上图有一个错误，请注意，是 OSPF 不是 OPSF。 OSPF（Open Shortest Path First，ospf）开放最短路径优先协议, 是由 Internet 工程任务组开发的路由选择协议 + +总体来说分为以下几个过程: + +1. DNS 解析 +2. TCP 连接 +3. 发送 HTTP 请求 +4. 服务器处理请求并返回 HTTP 报文 +5. 浏览器解析渲染页面 +6. 连接结束 + +具体可以参考下面这篇文章： + +* [https://segmentfault.com/a/1190000006879700](https://segmentfault.com/a/1190000006879700) + +## 状态码 + +![状态码](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/2019/7/状态码.png) + +## 各种协议与 HTTP 协议之间的关系 + +一般面试官会通过这样的问题来考察你对计算机网络知识体系的理解。 + +图片来源：《图解 HTTP》 + +![各种协议与HTTP协议之间的关系](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/2019/7/各种协议与HTTP协议之间的关系.png) + +## HTTP 是不保存状态的协议, 如何保存用户状态? + +HTTP 是一种不保存状态，即无状态（stateless）协议。也就是说 HTTP 协议自身不对请求和响应之间的通信状态进行保存。那么我们保存用户状态呢？Session 机制的存在就是为了解决这个问题，Session 的主要作用就是通过服务端记录用户的状态。典型的场景是购物车，当你要添加商品到购物车的时候，系统不知道是哪个用户操作的，因为 HTTP 协议是无状态的。服务端给特定的用户创建特定的 Session 之后就可以标识这个用户并且跟踪这个用户了（一般情况下，服务器会在一定时间内保存这个 Session，过了时间限制，就会销毁这个 Session）。 + +在服务端保存 Session 的方法很多，最常用的就是内存和数据库(比如是使用内存数据库 redis 保存)。既然 Session 存放在服务器端，那么我们如何实现 Session 跟踪呢？大部分情况下，我们都是通过在 Cookie 中附加一个 Session ID 来方式来跟踪。 + +**Cookie 被禁用怎么办?** + +最常用的就是利用 URL 重写把 Session ID 直接附加在 URL 路径的后面。 + +![HTTP是无状态协议](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/2019-6/HTTP是无状态的.png) + +## Cookie 的作用是什么? 和 Session 有什么区别？ + +Cookie 和 Session 都是用来跟踪浏览器用户身份的会话方式，但是两者的应用场景不太一样。 + +**Cookie 一般用来保存用户信息** 比如 ① 我们在 Cookie 中保存已经登录过的用户信息，下次访问网站的时候页面可以自动帮你把登录的一些基本信息给填了；② 一般的网站都会有保持登录，也就是说下次你再访问网站的时候就不需要重新登录了，这是因为用户登录的时候我们可以存放了一个 Token 在 Cookie 中，下次登录的时候只需要根据 Token 值来查找用户即可(为了安全考虑，重新登录一般要将 Token 重写)；③ 登录一次网站后访问网站其他页面不需要重新登录。**Session 的主要作用就是通过服务端记录用户的状态。** 典型的场景是购物车，当你要添加商品到购物车的时候，系统不知道是哪个用户操作的，因为 HTTP 协议是无状态的。服务端给特定的用户创建特定的 Session 之后就可以标识这个用户并且跟踪这个用户了。 + +Cookie 数据保存在客户端(浏览器端)，Session 数据保存在服务器端。 + +Cookie 存储在客户端中，而 Session 存储在服务器上，相对来说 Session 安全性更高。如果要在 Cookie 中存储一些敏感信息，不要直接写入 Cookie 中，最好能将 Cookie 信息加密，然后使用到的时候再去服务器端解密。 + +## URI 和 URL 的区别是什么? + +* URI(Uniform Resource Identifier) 是统一资源标志符，可以唯一标识一个资源。 +* URL(Uniform Resource Locator) 是统一资源定位符，可以提供该资源的路径。它是一种具体的 URI，即 URL 可以用来标识一个资源，而且还指明了如何 locate 这个资源。 + +URI 的作用像身份证号一样，URL 的作用更像家庭住址一样。URL 是一种具体的 URI，它不仅唯一标识资源，而且还提供了定位该资源的信息。 + +## 建议 + +非常推荐大家看一下 《图解 HTTP》 这本书，这本书页数不多，但是内容很是充实，不管是用来系统的掌握网络方面的一些知识还是说纯粹为了应付面试都有很大帮助。下面的一些文章只是参考。大二学习这门课程的时候，我们使用的教材是 《计算机网络第七版》（谢希仁编著），不推荐大家看这本教材，书非常厚而且知识偏理论，不确定大家能不能心平气和的读完。 + +## 参考 + +* [https://blog.csdn.net/qq_16209077/article/details/52718250](https://blog.csdn.net/qq_16209077/article/details/52718250) +* [https://blog.csdn.net/zixiaomuwu/article/details/60965466](https://blog.csdn.net/zixiaomuwu/article/details/60965466) +* [https://blog.csdn.net/turn\_\_back/article/details/73743641](https://blog.csdn.net/turn__back/article/details/73743641) +* diff --git "a/docs/cs-basics/network/\350\260\242\345\270\214\344\273\201\350\200\201\345\270\210\347\232\204\343\200\212\350\256\241\347\256\227\346\234\272\347\275\221\347\273\234\343\200\213\345\206\205\345\256\271\346\200\273\347\273\223.md" "b/docs/cs-basics/network/\350\260\242\345\270\214\344\273\201\350\200\201\345\270\210\347\232\204\343\200\212\350\256\241\347\256\227\346\234\272\347\275\221\347\273\234\343\200\213\345\206\205\345\256\271\346\200\273\347\273\223.md" new file mode 100644 index 0000000000000000000000000000000000000000..6692580bb90c94c7d19cab996ee1fd5b6fee464a --- /dev/null +++ "b/docs/cs-basics/network/\350\260\242\345\270\214\344\273\201\350\200\201\345\270\210\347\232\204\343\200\212\350\256\241\347\256\227\346\234\272\347\275\221\347\273\234\343\200\213\345\206\205\345\256\271\346\200\273\347\273\223.md" @@ -0,0 +1,355 @@ +--- +title: 谢希仁老师的《计算机网络》内容总结 +category: 计算机基础 +tag: + - 计算机网络 +--- + + +本文是我在大二学习计算机网络期间整理， 大部分内容都来自于谢希仁老师的《计算机网络》这本书。 + +为了内容更容易理解，我对之前的整理进行了一波重构，并配上了一些相关的示意图便于理解。 + +![](https://img-blog.csdnimg.cn/img_convert/e7177b00248e30dc49bd6061093a0590.png) + + + + + +- [1. 计算机网络概述](#1-计算机网络概述) + - [1.1. 基本术语](#11-基本术语) + - [1.2. 重要知识点总结](#12-重要知识点总结) +- [2. 物理层（Physical Layer）](#2-物理层physical-layer) + - [2.1. 基本术语](#21-基本术语) + - [2.2. 重要知识点总结](#22-重要知识点总结) + - [2.3. 补充](#23-补充) + - [2.3.1. 物理层主要做啥？](#231-物理层主要做啥) + - [2.3.2. 几种常用的信道复用技术](#232-几种常用的信道复用技术) + - [2.3.3. 几种常用的宽带接入技术，主要是 ADSL 和 FTTx](#233-几种常用的宽带接入技术主要是-adsl-和-fttx) +- [3. 数据链路层（Data Link Layer）](#3-数据链路层data-link-layer) + - [3.1. 基本术语](#31-基本术语) + - [3.2. 重要知识点总结](#32-重要知识点总结) + - [3.3. 补充](#33-补充) +- [4. 网络层（Network Layer）](#4-网络层network-layer) + - [4.1. 基本术语](#41-基本术语) + - [4.2. 重要知识点总结](#42-重要知识点总结) +- [5. 传输层（Transport Layer）](#5-传输层transport-layer) + - [5.1. 基本术语](#51-基本术语) + - [5.2. 重要知识点总结](#52-重要知识点总结) + - [5.3. 补充（重要）](#53-补充重要) +- [6. 应用层（Application Layer）](#6-应用层application-layer) + - [6.1. 基本术语](#61-基本术语) + - [6.2. 重要知识点总结](#62-重要知识点总结) + - [6.3. 补充（重要）](#63-补充重要) + + + + +## 1. 计算机网络概述 + +### 1.1. 基本术语 + +1. **结点 （node）** ：网络中的结点可以是计算机，集线器，交换机或路由器等。 +2. **链路（link ）** : 从一个结点到另一个结点的一段物理线路。中间没有任何其他交点。 +3. **主机（host）** ：连接在因特网上的计算机。 +4. **ISP（Internet Service Provider）** ：因特网服务提供者（提供商）。 + +![ISP (Internet Service Provider) Definition](https://img-blog.csdnimg.cn/img_convert/b83f6951e3f8f4bcde5b227257d603a8.png) + +5. **IXP（Internet eXchange Point）** ： 互联网交换点 IXP 的主要作用就是允许两个网络直接相连并交换分组，而不需要再通过第三个网络来转发分组。 + +![IXP Traffic Levels During the Stratos Skydive — RIPE Labs](https://img-blog.csdnimg.cn/img_convert/7a9568a9e94001fc110801addc8c4ec0.png) + +

https://labs.ripe.net/Members/fergalc/ixp-traffic-during-stratos-skydive

+ +6. **RFC(Request For Comments)** ：意思是“请求评议”，包含了关于 Internet 几乎所有的重要的文字资料。 +7. **广域网 WAN（Wide Area Network）** ：任务是通过长距离运送主机发送的数据。 +8. **城域网 MAN（Metropolitan Area Network）**：用来将多个局域网进行互连。 +9. **局域网 LAN（Local Area Network）** ： 学校或企业大多拥有多个互连的局域网。 + +![MAN & WMAN | Red de área metropolitana, Redes informaticas, Par trenzado](https://img-blog.csdnimg.cn/img_convert/25a5789f8e18995c649f2f864d51e7a9.png) + +

http://conexionesmanwman.blogspot.com/

+ +10. **个人区域网 PAN（Personal Area Network）** ：在个人工作的地方把属于个人使用的电子设备用无线技术连接起来的网络 。 + +![Advantages and disadvantages of personal area network (PAN) - IT Release](https://img-blog.csdnimg.cn/img_convert/5c99dd6011439b1fab6cd2fece155dd5.png) + +

https://www.itrelease.com/2018/07/advantages-and-disadvantages-of-personal-area-network-pan/

+ +12. **分组（packet ）** ：因特网中传送的数据单元。由首部 header 和数据段组成。分组又称为包，首部可称为包头。 +13. **存储转发（store and forward ）** ：路由器收到一个分组，先检查分组是否正确，并过滤掉冲突包错误。确定包正确后，取出目的地址，通过查找表找到想要发送的输出端口地址，然后将该包发送出去。 + +![](https://img-blog.csdnimg.cn/20201025142342169.gif#pic_center) + +14. **带宽（bandwidth）** ：在计算机网络中，表示在单位时间内从网络中的某一点到另一点所能通过的“最高数据率”。常用来表示网络的通信线路所能传送数据的能力。单位是“比特每秒”，记为 b/s。 +15. **吞吐量（throughput ）** ：表示在单位时间内通过某个网络（或信道、接口）的数据量。吞吐量更经常地用于对现实世界中的网络的一种测量，以便知道实际上到底有多少数据量能够通过网络。吞吐量受网络的带宽或网络的额定速率的限制。 + +### 1.2. 重要知识点总结 + +1. **计算机网络（简称网络）把许多计算机连接在一起，而互联网把许多网络连接在一起，是网络的网络。** +2. 小写字母 i 开头的 internet（互联网）是通用名词，它泛指由多个计算机网络相互连接而成的网络。在这些网络之间的通信协议（即通信规则）可以是任意的。大写字母 I 开头的 Internet（互联网）是专用名词，它指全球最大的，开放的，由众多网络相互连接而成的特定的互联网，并采用 TCP/IP 协议作为通信规则，其前身为 ARPANET。Internet 的推荐译名为因特网，现在一般流行称为互联网。 +3. 路由器是实现分组交换的关键构件，其任务是转发收到的分组，这是网络核心部分最重要的功能。分组交换采用存储转发技术，表示把一个报文（要发送的整块数据）分为几个分组后再进行传送。在发送报文之前，先把较长的报文划分成为一个个更小的等长数据段。在每个数据端的前面加上一些由必要的控制信息组成的首部后，就构成了一个分组。分组又称为包。分组是在互联网中传送的数据单元，正是由于分组的头部包含了诸如目的地址和源地址等重要控制信息，每一个分组才能在互联网中独立的选择传输路径，并正确地交付到分组传输的终点。 +4. 互联网按工作方式可划分为边缘部分和核心部分。主机在网络的边缘部分，其作用是进行信息处理。由大量网络和连接这些网络的路由器组成核心部分，其作用是提供连通性和交换。 +5. 计算机通信是计算机中进程（即运行着的程序）之间的通信。计算机网络采用的通信方式是客户-服务器方式（C/S 方式）和对等连接方式（P2P 方式）。 +6. 客户和服务器都是指通信中所涉及的应用进程。客户是服务请求方，服务器是服务提供方。 +7. 按照作用范围的不同，计算机网络分为广域网 WAN，城域网 MAN，局域网 LAN，个人区域网 PAN。 +8. **计算机网络最常用的性能指标是：速率，带宽，吞吐量，时延（发送时延，处理时延，排队时延），时延带宽积，往返时间和信道利用率。** +9. 网络协议即协议，是为进行网络中的数据交换而建立的规则。计算机网络的各层以及其协议集合，称为网络的体系结构。 +10. **五层体系结构由应用层，运输层，网络层（网际层），数据链路层，物理层组成。运输层最主要的协议是 TCP 和 UDP 协议，网络层最重要的协议是 IP 协议。** + +![s](https://img-blog.csdnimg.cn/2020102514243717.png#pic_center) + +下面的内容会介绍计算机网络的五层体系结构：**物理层+数据链路层+网络层（网际层）+运输层+应用层**。 + +## 2. 物理层（Physical Layer） + +![物理层](https://img-blog.csdnimg.cn/img_convert/4749289d6e152bab1c8a8ccfc946a797.png) + +### 2.1. 基本术语 + +1. **数据（data）** :运送消息的实体。 +2. **信号（signal）** ：数据的电气的或电磁的表现。或者说信号是适合在传输介质上传输的对象。 +3. **码元（ code）** ：在使用时间域（或简称为时域）的波形来表示数字信号时，代表不同离散数值的基本波形。 +4. **单工（simplex ）** : 只能有一个方向的通信而没有反方向的交互。 +5. **半双工（half duplex ）** ：通信的双方都可以发送信息，但不能双方同时发送(当然也就不能同时接收)。 +6. **全双工（full duplex）** : 通信的双方可以同时发送和接收信息。 + +![](https://img-blog.csdnimg.cn/img_convert/c5be4756d2d6f46cbb6d785d5b86faf1.png) + +7. **失真**：失去真实性，主要是指接受到的信号和发送的信号不同，有磨损和衰减。影响失真程度的因素：1.码元传输速率 2.信号传输距离 3.噪声干扰 4.传输媒体质量 + +![](https://img-blog.csdnimg.cn/img_convert/aef3aac72e86c1ee6ccb8a91647f656c.png) + +8. **奈氏准则** : 在任何信道中，码元的传输的效率是有上限的，传输速率超过此上限，就会出现严重的码间串扰问题，使接收端对码元的判决（即识别）成为不可能。 +9. **香农定理** ：在带宽受限且有噪声的信道中，为了不产生误差，信息的数据传输速率有上限值。 +10. **基带信号（baseband signal）** : 来自信源的信号。指没有经过调制的数字信号或模拟信号。 +11. **带通（频带）信号（bandpass signal）** ：把基带信号经过载波调制后，把信号的频率范围搬移到较高的频段以便在信道中传输（即仅在一段频率范围内能够通过信道），这里调制过后的信号就是带通信号。 +12. **调制（modulation ）** : 对信号源的信息进行处理后加到载波信号上，使其变为适合在信道传输的形式的过程。 +13. **信噪比（signal-to-noise ratio ）** : 指信号的平均功率和噪声的平均功率之比，记为 S/N。信噪比（dB）=10\*log10（S/N）。 +14. **信道复用（channel multiplexing ）** ：指多个用户共享同一个信道。（并不一定是同时）。 + +![信道复用技术](https://img-blog.csdnimg.cn/img_convert/a4889adaad3314f882e2cfab5f382064.png) + +15. **比特率（bit rate ）** ：单位时间（每秒）内传送的比特数。 +16. **波特率（baud rate）** ：单位时间载波调制状态改变的次数。针对数据信号对载波的调制速率。 +17. **复用（multiplexing）** ：共享信道的方法。 +18. **ADSL（Asymmetric Digital Subscriber Line ）** ：非对称数字用户线。 +19. **光纤同轴混合网（HFC 网）** :在目前覆盖范围很广的有线电视网的基础上开发的一种居民宽带接入网 + +### 2.2. 重要知识点总结 + +1. **物理层的主要任务就是确定与传输媒体接口有关的一些特性，如机械特性，电气特性，功能特性，过程特性。** +2. 一个数据通信系统可划分为三大部分，即源系统，传输系统，目的系统。源系统包括源点（或源站，信源）和发送器，目的系统包括接收器和终点。 +3. **通信的目的是传送消息。如话音，文字，图像等都是消息，数据是运送消息的实体。信号则是数据的电气或电磁的表现。** +4. 根据信号中代表消息的参数的取值方式不同，信号可分为模拟信号（或连续信号）和数字信号（或离散信号）。在使用时间域（简称时域）的波形表示数字信号时，代表不同离散数值的基本波形称为码元。 +5. 根据双方信息交互的方式，通信可划分为单向通信（或单工通信），双向交替通信（或半双工通信），双向同时通信（全双工通信）。 +6. 来自信源的信号称为基带信号。信号要在信道上传输就要经过调制。调制有基带调制和带通调制之分。最基本的带通调制方法有调幅，调频和调相。还有更复杂的调制方法，如正交振幅调制。 +7. 要提高数据在信道上的传递速率，可以使用更好的传输媒体，或使用先进的调制技术。但数据传输速率不可能任意被提高。 +8. 传输媒体可分为两大类，即导引型传输媒体（双绞线，同轴电缆，光纤）和非导引型传输媒体（无线，红外，大气激光）。 +9. 为了有效利用光纤资源，在光纤干线和用户之间广泛使用无源光网络 PON。无源光网络无需配备电源，其长期运营成本和管理成本都很低。最流行的无源光网络是以太网无源光网络 EPON 和吉比特无源光网络 GPON。 + +### 2.3. 补充 + +#### 2.3.1. 物理层主要做啥？ + +物理层主要做的事情就是 **透明地传送比特流**。也可以将物理层的主要任务描述为确定与传输媒体的接口的一些特性，即：机械特性（接口所用接线器的一些物理属性如形状和尺寸），电气特性（接口电缆的各条线上出现的电压的范围），功能特性（某条线上出现的某一电平的电压的意义），过程特性（对于不同功能的各种可能事件的出现顺序）。 + +**物理层考虑的是怎样才能在连接各种计算机的传输媒体上传输数据比特流，而不是指具体的传输媒体。** 现有的计算机网络中的硬件设备和传输媒体的种类非常繁多，而且通信手段也有许多不同的方式。物理层的作用正是尽可能地屏蔽掉这些传输媒体和通信手段的差异，使物理层上面的数据链路层感觉不到这些差异，这样就可以使数据链路层只考虑完成本层的协议和服务，而不必考虑网络的具体传输媒体和通信手段是什么。 + +#### 2.3.2. 几种常用的信道复用技术 + +1. **频分复用(FDM)** ：所有用户在同样的时间占用不同的带宽资源。 +2. **时分复用（TDM）** ：所有用户在不同的时间占用同样的频带宽度（分时不分频）。 +3. **统计时分复用 (Statistic TDM)** ：改进的时分复用，能够明显提高信道的利用率。 +4. **码分复用(CDM)** ： 用户使用经过特殊挑选的不同码型，因此各用户之间不会造成干扰。这种系统发送的信号有很强的抗干扰能力，其频谱类似于白噪声，不易被敌人发现。 +5. **波分复用( WDM)** ：波分复用就是光的频分复用。 + +#### 2.3.3. 几种常用的宽带接入技术，主要是 ADSL 和 FTTx + +用户到互联网的宽带接入方法有非对称数字用户线 ADSL（用数字技术对现有的模拟电话线进行改造，而不需要重新布线。ADSL 的快速版本是甚高速数字用户线 VDSL。），光纤同轴混合网 HFC（是在目前覆盖范围很广的有线电视网的基础上开发的一种居民宽带接入网）和 FTTx（即光纤到······）。 + +## 3. 数据链路层（Data Link Layer） + +![数据链路层](https://guide-blog-images.oss-cn-shenzhen.aliyuncs.com/java-guide-blog/2-data-link-layer.svg) + +### 3.1. 基本术语 + +1. **链路（link）** ：一个结点到相邻结点的一段物理链路。 +2. **数据链路（data link）** ：把实现控制数据运输的协议的硬件和软件加到链路上就构成了数据链路。 +3. **循环冗余检验 CRC（Cyclic Redundancy Check）** ：为了保证数据传输的可靠性，CRC 是数据链路层广泛使用的一种检错技术。 +4. **帧（frame）** ：一个数据链路层的传输单元，由一个数据链路层首部和其携带的封包所组成协议数据单元。 +5. **MTU（Maximum Transfer Uint ）** ：最大传送单元。帧的数据部分的的长度上限。 +6. **误码率 BER（Bit Error Rate ）** ：在一段时间内，传输错误的比特占所传输比特总数的比率。 +7. **PPP（Point-to-Point Protocol ）** ：点对点协议。即用户计算机和 ISP 进行通信时所使用的数据链路层协议。以下是 PPP 帧的示意图： + ![PPP](https://img-blog.csdnimg.cn/img_convert/298dbdeb16f98cec02c3954d8d95c1d6.png) +8. **MAC 地址（Media Access Control 或者 Medium Access Control）** ：意译为媒体访问控制，或称为物理地址、硬件地址，用来定义网络设备的位置。在 OSI 模型中，第三层网络层负责 IP 地址，第二层数据链路层则负责 MAC 地址。因此一个主机会有一个 MAC 地址，而每个网络位置会有一个专属于它的 IP 地址 。地址是识别某个系统的重要标识符，“名字指出我们所要寻找的资源，地址指出资源所在的地方，路由告诉我们如何到达该处。” + +![ARP (Address Resolution Protocol) explained](https://img-blog.csdnimg.cn/img_convert/002b2e6e45d66e805008fafc310afef0.png) + +9. **网桥（bridge）** ：一种用于数据链路层实现中继，连接两个或多个局域网的网络互连设备。 +10. **交换机（switch ）** ：广义的来说，交换机指的是一种通信系统中完成信息交换的设备。这里工作在数据链路层的交换机指的是交换式集线器，其实质是一个多接口的网桥 + +### 3.2. 重要知识点总结 + +1. 链路是从一个结点到相邻结点的一段物理链路，数据链路则在链路的基础上增加了一些必要的硬件（如网络适配器）和软件（如协议的实现） +2. 数据链路层使用的主要是**点对点信道**和**广播信道**两种。 +3. 数据链路层传输的协议数据单元是帧。数据链路层的三个基本问题是：**封装成帧**，**透明传输**和**差错检测** +4. **循环冗余检验 CRC** 是一种检错方法，而帧检验序列 FCS 是添加在数据后面的冗余码 +5. **点对点协议 PPP** 是数据链路层使用最多的一种协议，它的特点是：简单，只检测差错而不去纠正差错，不使用序号，也不进行流量控制，可同时支持多种网络层协议 +6. PPPoE 是为宽带上网的主机使用的链路层协议 +7. **局域网的优点是：具有广播功能，从一个站点可方便地访问全网；便于系统的扩展和逐渐演变；提高了系统的可靠性，可用性和生存性。** +8. 计算机与外接局域网通信需要通过通信适配器（或网络适配器），它又称为网络接口卡或网卡。**计算器的硬件地址就在适配器的 ROM 中**。 +9. 以太网采用的无连接的工作方式，对发送的数据帧不进行编号，也不要求对方发回确认。目的站收到有差错帧就把它丢掉，其他什么也不做 +10. 以太网采用的协议是具有冲突检测的**载波监听多点接入 CSMA/CD**。协议的特点是：**发送前先监听，边发送边监听，一旦发现总线上出现了碰撞，就立即停止发送。然后按照退避算法等待一段随机时间后再次发送。** 因此，每一个站点在自己发送数据之后的一小段时间内，存在着遭遇碰撞的可能性。以太网上的各站点平等地争用以太网信道 +11. 以太网的适配器具有过滤功能，它只接收单播帧，广播帧和多播帧。 +12. 使用集线器可以在物理层扩展以太网（扩展后的以太网仍然是一个网络） + +### 3.3. 补充 + +1. 数据链路层的点对点信道和广播信道的特点，以及这两种信道所使用的协议（PPP 协议以及 CSMA/CD 协议）的特点 +2. 数据链路层的三个基本问题：**封装成帧**，**透明传输**，**差错检测** +3. 以太网的 MAC 层硬件地址 +4. 适配器，转发器，集线器，网桥，以太网交换机的作用以及适用场合 + +## 4. 网络层（Network Layer） + +![网络层](https://img-blog.csdnimg.cn/img_convert/fbf78bdcf3db11526ac1a234a8b98234.png) + +### 4.1. 基本术语 + +1. **虚电路（Virtual Circuit）** : 在两个终端设备的逻辑或物理端口之间，通过建立的双向的透明传输通道。虚电路表示这只是一条逻辑上的连接，分组都沿着这条逻辑连接按照存储转发方式传送，而并不是真正建立了一条物理连接。 +2. **IP（Internet Protocol ）** : 网际协议 IP 是 TCP/IP 体系中两个最主要的协议之一，是 TCP/IP 体系结构网际层的核心。配套的有 ARP，RARP，ICMP，IGMP。 +3. **ARP（Address Resolution Protocol）** : 地址解析协议。地址解析协议 ARP 把 IP 地址解析为硬件地址。 +4. **ICMP（Internet Control Message Protocol ）** ：网际控制报文协议 （ICMP 允许主机或路由器报告差错情况和提供有关异常情况的报告）。 +5. **子网掩码（subnet mask ）** ：它是一种用来指明一个 IP 地址的哪些位标识的是主机所在的子网以及哪些位标识的是主机的位掩码。子网掩码不能单独存在，它必须结合 IP 地址一起使用。 +6. **CIDR（ Classless Inter-Domain Routing ）**：无分类域间路由选择 （特点是消除了传统的 A 类、B 类和 C 类地址以及划分子网的概念，并使用各种长度的“网络前缀”(network-prefix)来代替分类地址中的网络号和子网号）。 +7. **默认路由（default route）** ：当在路由表中查不到能到达目的地址的路由时，路由器选择的路由。默认路由还可以减小路由表所占用的空间和搜索路由表所用的时间。 +8. **路由选择算法（Virtual Circuit）** ：路由选择协议的核心部分。因特网采用自适应的，分层次的路由选择协议。 + +### 4.2. 重要知识点总结 + +1. **TCP/IP 协议中的网络层向上只提供简单灵活的，无连接的，尽最大努力交付的数据报服务。网络层不提供服务质量的承诺，不保证分组交付的时限所传送的分组可能出错，丢失，重复和失序。进程之间通信的可靠性由运输层负责** +2. 在互联网的交付有两种，一是在本网络直接交付不用经过路由器，另一种是和其他网络的间接交付，至少经过一个路由器，但最后一次一定是直接交付 +3. 分类的 IP 地址由网络号字段（指明网络）和主机号字段（指明主机）组成。网络号字段最前面的类别指明 IP 地址的类别。IP 地址是一种分等级的地址结构。IP 地址管理机构分配 IP 地址时只分配网络号，主机号由得到该网络号的单位自行分配。路由器根据目的主机所连接的网络号来转发分组。一个路由器至少连接到两个网络，所以一个路由器至少应当有两个不同的 IP 地址 +4. IP 数据报分为首部和数据两部分。首部的前一部分是固定长度，共 20 字节，是所有 IP 数据包必须具有的（源地址，目的地址，总长度等重要地段都固定在首部）。一些长度可变的可选字段固定在首部的后面。IP 首部中的生存时间给出了 IP 数据报在互联网中所能经过的最大路由器数。可防止 IP 数据报在互联网中无限制的兜圈子。 +5. **地址解析协议 ARP 把 IP 地址解析为硬件地址。ARP 的高速缓存可以大大减少网络上的通信量。因为这样可以使主机下次再与同样地址的主机通信时，可以直接从高速缓存中找到所需要的硬件地址而不需要再去以广播方式发送 ARP 请求分组** +6. 无分类域间路由选择 CIDR 是解决目前 IP 地址紧缺的一个好办法。CIDR 记法在 IP 地址后面加上斜线“/”，然后写上前缀所占的位数。前缀（或网络前缀）用来指明网络，前缀后面的部分是后缀，用来指明主机。CIDR 把前缀都相同的连续的 IP 地址组成一个“CIDR 地址块”，IP 地址分配都以 CIDR 地址块为单位。 +7. 网际控制报文协议是 IP 层的协议。ICMP 报文作为 IP 数据报的数据，加上首部后组成 IP 数据报发送出去。使用 ICMP 数据报并不是为了实现可靠传输。ICMP 允许主机或路由器报告差错情况和提供有关异常情况的报告。ICMP 报文的种类有两种，即 ICMP 差错报告报文和 ICMP 询问报文。 +8. **要解决 IP 地址耗尽的问题，最根本的办法是采用具有更大地址空间的新版本 IP 协议-IPv6。** IPv6 所带来的变化有 ① 更大的地址空间（采用 128 位地址）② 灵活的首部格式 ③ 改进的选项 ④ 支持即插即用 ⑤ 支持资源的预分配 ⑥IPv6 的首部改为 8 字节对齐。 +9. **虚拟专用网络 VPN 利用公用的互联网作为本机构专用网之间的通信载体。VPN 内使用互联网的专用地址。一个 VPN 至少要有一个路由器具有合法的全球 IP 地址，这样才能和本系统的另一个 VPN 通过互联网进行通信。所有通过互联网传送的数据都需要加密。** +10. MPLS 的特点是：① 支持面向连接的服务质量 ② 支持流量工程，平衡网络负载 ③ 有效的支持虚拟专用网 VPN。MPLS 在入口节点给每一个 IP 数据报打上固定长度的“标记”，然后根据标记在第二层（链路层）用硬件进行转发（在标记交换路由器中进行标记交换），因而转发速率大大加快。 + +## 5. 传输层（Transport Layer） + +![传输层](https://img-blog.csdnimg.cn/img_convert/09eb87a29bed99775ef5bde5eb216971.png) + +### 5.1. 基本术语 + +1. **进程（process）** ：指计算机中正在运行的程序实体。 +2. **应用进程互相通信** ：一台主机的进程和另一台主机中的一个进程交换数据的过程（另外注意通信真正的端点不是主机而是主机中的进程，也就是说端到端的通信是应用进程之间的通信）。 +3. **传输层的复用与分用** ：复用指发送方不同的进程都可以通过同一个运输层协议传送数据。分用指接收方的运输层在剥去报文的首部后能把这些数据正确的交付到目的应用进程。 +4. **TCP（Transmission Control Protocol）** ：传输控制协议。 +5. **UDP（User Datagram Protocol）** ：用户数据报协议。 + +![TCP和UDP](https://img-blog.csdnimg.cn/img_convert/2bd5bf90676c338864807ade87b7bdea.png) + +6. **端口（port）** ：端口的目的是为了确认对方机器的哪个进程在与自己进行交互，比如 MSN 和 QQ 的端口不同，如果没有端口就可能出现 QQ 进程和 MSN 交互错误。端口又称协议端口号。 +7. **停止等待协议（stop-and-wait）** ：指发送方每发送完一个分组就停止发送，等待对方确认，在收到确认之后在发送下一个分组。 +8. **流量控制** : 就是让发送方的发送速率不要太快，既要让接收方来得及接收，也不要使网络发生拥塞。 +9. **拥塞控制** ：防止过多的数据注入到网络中，这样可以使网络中的路由器或链路不致过载。拥塞控制所要做的都有一个前提，就是网络能够承受现有的网络负荷。 + +### 5.2. 重要知识点总结 + +1. **运输层提供应用进程之间的逻辑通信，也就是说，运输层之间的通信并不是真正在两个运输层之间直接传输数据。运输层向应用层屏蔽了下面网络的细节（如网络拓补，所采用的路由选择协议等），它使应用进程之间看起来好像两个运输层实体之间有一条端到端的逻辑通信信道。** +2. **网络层为主机提供逻辑通信，而运输层为应用进程之间提供端到端的逻辑通信。** +3. 运输层的两个重要协议是用户数据报协议 UDP 和传输控制协议 TCP。按照 OSI 的术语，两个对等运输实体在通信时传送的数据单位叫做运输协议数据单元 TPDU（Transport Protocol Data Unit）。但在 TCP/IP 体系中，则根据所使用的协议是 TCP 或 UDP，分别称之为 TCP 报文段或 UDP 用户数据报。 +4. **UDP 在传送数据之前不需要先建立连接，远地主机在收到 UDP 报文后，不需要给出任何确认。虽然 UDP 不提供可靠交付，但在某些情况下 UDP 确是一种最有效的工作方式。 TCP 提供面向连接的服务。在传送数据之前必须先建立连接，数据传送结束后要释放连接。TCP 不提供广播或多播服务。由于 TCP 要提供可靠的，面向连接的传输服务，难以避免地增加了许多开销，如确认，流量控制，计时器以及连接管理等。这不仅使协议数据单元的首部增大很多，还要占用许多处理机资源。** +5. 硬件端口是不同硬件设备进行交互的接口，而软件端口是应用层各种协议进程与运输实体进行层间交互的一种地址。UDP 和 TCP 的首部格式中都有源端口和目的端口这两个重要字段。当运输层收到 IP 层交上来的运输层报文时，就能够根据其首部中的目的端口号把数据交付应用层的目的应用层。（两个进程之间进行通信不光要知道对方 IP 地址而且要知道对方的端口号(为了找到对方计算机中的应用进程)） +6. 运输层用一个 16 位端口号标志一个端口。端口号只有本地意义，它只是为了标志计算机应用层中的各个进程在和运输层交互时的层间接口。在互联网的不同计算机中，相同的端口号是没有关联的。协议端口号简称端口。虽然通信的终点是应用进程，但只要把所发送的报文交到目的主机的某个合适端口，剩下的工作（最后交付目的进程）就由 TCP 和 UDP 来完成。 +7. 运输层的端口号分为服务器端使用的端口号（0˜1023 指派给熟知端口，1024˜49151 是登记端口号）和客户端暂时使用的端口号（49152˜65535） +8. **UDP 的主要特点是 ① 无连接 ② 尽最大努力交付 ③ 面向报文 ④ 无拥塞控制 ⑤ 支持一对一，一对多，多对一和多对多的交互通信 ⑥ 首部开销小（只有四个字段：源端口，目的端口，长度和检验和）** +9. **TCP 的主要特点是 ① 面向连接 ② 每一条 TCP 连接只能是一对一的 ③ 提供可靠交付 ④ 提供全双工通信 ⑤ 面向字节流** +10. **TCP 用主机的 IP 地址加上主机上的端口号作为 TCP 连接的端点。这样的端点就叫做套接字（socket）或插口。套接字用（IP 地址：端口号）来表示。每一条 TCP 连接唯一地被通信两端的两个端点所确定。** +11. 停止等待协议是为了实现可靠传输的，它的基本原理就是每发完一个分组就停止发送，等待对方确认。在收到确认后再发下一个分组。 +12. 为了提高传输效率，发送方可以不使用低效率的停止等待协议，而是采用流水线传输。流水线传输就是发送方可连续发送多个分组，不必每发完一个分组就停下来等待对方确认。这样可使信道上一直有数据不间断的在传送。这种传输方式可以明显提高信道利用率。 +13. 停止等待协议中超时重传是指只要超过一段时间仍然没有收到确认，就重传前面发送过的分组（认为刚才发送过的分组丢失了）。因此每发送完一个分组需要设置一个超时计时器，其重传时间应比数据在分组传输的平均往返时间更长一些。这种自动重传方式常称为自动重传请求 ARQ。另外在停止等待协议中若收到重复分组，就丢弃该分组，但同时还要发送确认。连续 ARQ 协议可提高信道利用率。发送维持一个发送窗口，凡位于发送窗口内的分组可连续发送出去，而不需要等待对方确认。接收方一般采用累积确认，对按序到达的最后一个分组发送确认，表明到这个分组位置的所有分组都已经正确收到了。 +14. TCP 报文段的前 20 个字节是固定的，后面有 4n 字节是根据需要增加的选项。因此，TCP 首部的最小长度是 20 字节。 +15. **TCP 使用滑动窗口机制。发送窗口里面的序号表示允许发送的序号。发送窗口后沿的后面部分表示已发送且已收到确认，而发送窗口前沿的前面部分表示不允许发送。发送窗口后沿的变化情况有两种可能，即不动（没有收到新的确认）和前移（收到了新的确认）。发送窗口的前沿通常是不断向前移动的。一般来说，我们总是希望数据传输更快一些。但如果发送方把数据发送的过快，接收方就可能来不及接收，这就会造成数据的丢失。所谓流量控制就是让发送方的发送速率不要太快，要让接收方来得及接收。** +16. 在某段时间，若对网络中某一资源的需求超过了该资源所能提供的可用部分，网络的性能就要变坏。这种情况就叫拥塞。拥塞控制就是为了防止过多的数据注入到网络中，这样就可以使网络中的路由器或链路不致过载。拥塞控制所要做的都有一个前提，就是网络能够承受现有的网络负荷。拥塞控制是一个全局性的过程，涉及到所有的主机，所有的路由器，以及与降低网络传输性能有关的所有因素。相反，流量控制往往是点对点通信量的控制，是个端到端的问题。流量控制所要做到的就是抑制发送端发送数据的速率，以便使接收端来得及接收。 +17. **为了进行拥塞控制，TCP 发送方要维持一个拥塞窗口 cwnd 的状态变量。拥塞控制窗口的大小取决于网络的拥塞程度，并且动态变化。发送方让自己的发送窗口取为拥塞窗口和接收方的接受窗口中较小的一个。** +18. **TCP 的拥塞控制采用了四种算法，即慢开始，拥塞避免，快重传和快恢复。在网络层也可以使路由器采用适当的分组丢弃策略（如主动队列管理 AQM），以减少网络拥塞的发生。** +19. 运输连接的三个阶段，即：连接建立，数据传送和连接释放。 +20. **主动发起 TCP 连接建立的应用进程叫做客户，而被动等待连接建立的应用进程叫做服务器。TCP 连接采用三报文握手机制。服务器要确认用户的连接请求，然后客户要对服务器的确认进行确认。** +21. TCP 的连接释放采用四报文握手机制。任何一方都可以在数据传送结束后发出连接释放的通知，待对方确认后进入半关闭状态。当另一方也没有数据再发送时，则发送连接释放通知，对方确认后就完全关闭了 TCP 连接 + +### 5.3. 补充（重要） + +以下知识点需要重点关注： + +1. 端口和套接字的意义 +2. UDP 和 TCP 的区别以及两者的应用场景 +3. 在不可靠的网络上实现可靠传输的工作原理，停止等待协议和 ARQ 协议 +4. TCP 的滑动窗口，流量控制，拥塞控制和连接管理 +5. TCP 的三次握手，四次挥手机制 + +## 6. 应用层（Application Layer） + +![应用层](https://img-blog.csdnimg.cn/img_convert/3ff57c0632bc7f4017723b1d1b7d3a52.png) + +### 6.1. 基本术语 + +1. **域名系统（DNS）** ：域名系统（DNS，Domain Name System）将人类可读的域名 (例如，www.baidu.com) 转换为机器可读的 IP 地址 (例如，220.181.38.148)。我们可以将其理解为专为互联网设计的电话薄。 + +![](https://img-blog.csdnimg.cn/img_convert/6af26a3293530061785df50e70d53e07.png) + +

https://www.seobility.net/en/wiki/HTTP_headers

+ +2. **文件传输协议（FTP）** ：FTP 是 File Transfer Protocol（文件传输协议）的英文简称，而中文简称为“文传协议”。用于 Internet 上的控制文件的双向传输。同时，它也是一个应用程序（Application）。基于不同的操作系统有不同的 FTP 应用程序，而所有这些应用程序都遵守同一种协议以传输文件。在 FTP 的使用当中，用户经常遇到两个概念："下载"（Download）和"上传"（Upload）。 "下载"文件就是从远程主机拷贝文件至自己的计算机上；"上传"文件就是将文件从自己的计算机中拷贝至远程主机上。用 Internet 语言来说，用户可通过客户机程序向（从）远程主机上传（下载）文件。 + +![FTP工作过程](https://img-blog.csdnimg.cn/img_convert/3f1abf8adba4aa317eca69c489e3db23.png) + +3. **简单文件传输协议（TFTP）** ：TFTP（Trivial File Transfer Protocol,简单文件传输协议）是 TCP/IP 协议族中的一个用来在客户机与服务器之间进行简单文件传输的协议，提供不复杂、开销不大的文件传输服务。端口号为 69。 +4. **远程终端协议（TELNET）** ：Telnet 协议是 TCP/IP 协议族中的一员，是 Internet 远程登陆服务的标准协议和主要方式。它为用户提供了在本地计算机上完成远程主机工作的能力。在终端使用者的电脑上使用 telnet 程序，用它连接到服务器。终端使用者可以在 telnet 程序中输入命令，这些命令会在服务器上运行，就像直接在服务器的控制台上输入一样。可以在本地就能控制服务器。要开始一个 telnet 会话，必须输入用户名和密码来登录服务器。Telnet 是常用的远程控制 Web 服务器的方法。 +5. **万维网（WWW）** ：WWW 是环球信息网的缩写，（亦作“Web”、“WWW”、“'W3'”，英文全称为“World Wide Web”），中文名字为“万维网”，"环球网"等，常简称为 Web。分为 Web 客户端和 Web 服务器程序。WWW 可以让 Web 客户端（常用浏览器）访问浏览 Web 服务器上的页面。是一个由许多互相链接的超文本组成的系统，通过互联网访问。在这个系统中，每个有用的事物，称为一样“资源”；并且由一个全局“统一资源标识符”（URI）标识；这些资源通过超文本传输协议（Hypertext Transfer Protocol）传送给用户，而后者通过点击链接来获得资源。万维网联盟（英语：World Wide Web Consortium，简称 W3C），又称 W3C 理事会。1994 年 10 月在麻省理工学院（MIT）计算机科学实验室成立。万维网联盟的创建者是万维网的发明者蒂姆·伯纳斯-李。万维网并不等同互联网，万维网只是互联网所能提供的服务其中之一，是靠着互联网运行的一项服务。 +6. **万维网的大致工作工程：** + +![万维网的大致工作工程](https://img-blog.csdnimg.cn/img_convert/735f55501e81898aa61b8032f7dbcb73.png) + +7. **统一资源定位符（URL）** ：统一资源定位符是对可以从互联网上得到的资源的位置和访问方法的一种简洁的表示，是互联网上标准资源的地址。互联网上的每个文件都有一个唯一的 URL，它包含的信息指出文件的位置以及浏览器应该怎么处理它。 +8. **超文本传输协议（HTTP）** ：超文本传输协议（HTTP，HyperText Transfer Protocol)是互联网上应用最为广泛的一种网络协议。所有的 WWW 文件都必须遵守这个标准。设计 HTTP 最初的目的是为了提供一种发布和接收 HTML 页面的方法。1960 年美国人 Ted Nelson 构思了一种通过计算机处理文本信息的方法，并称之为超文本（hypertext）,这成为了 HTTP 超文本传输协议标准架构的发展根基。 + +HTTP 协议的本质就是一种浏览器与服务器之间约定好的通信格式。HTTP 的原理如下图所示： + +![](https://img-blog.csdnimg.cn/img_convert/b273efef5f2388e26414135672b00295.png) + +10. **代理服务器（Proxy Server）** ： 代理服务器（Proxy Server）是一种网络实体，它又称为万维网高速缓存。 代理服务器把最近的一些请求和响应暂存在本地磁盘中。当新请求到达时，若代理服务器发现这个请求与暂时存放的的请求相同，就返回暂存的响应，而不需要按 URL 的地址再次去互联网访问该资源。代理服务器可在客户端或服务器工作，也可以在中间系统工作。 +11. **简单邮件传输协议(SMTP)** : SMTP（Simple Mail Transfer Protocol）即简单邮件传输协议,它是一组用于由源地址到目的地址传送邮件的规则，由它来控制信件的中转方式。 SMTP 协议属于 TCP/IP 协议簇，它帮助每台计算机在发送或中转信件时找到下一个目的地。 通过 SMTP 协议所指定的服务器,就可以把 E-mail 寄到收信人的服务器上了，整个过程只要几分钟。SMTP 服务器则是遵循 SMTP 协议的发送邮件服务器，用来发送或中转发出的电子邮件。 + +![一个电子邮件被发送的过程](https://img-blog.csdnimg.cn/img_convert/b16da4d4fea63de5fce53f54973967d7.png) + +

https://www.campaignmonitor.com/resources/knowledge-base/what-is-the-code-that-makes-bcc-or-cc-operate-in-an-email/

+ +11. **搜索引擎** :搜索引擎（Search Engine）是指根据一定的策略、运用特定的计算机程序从互联网上搜集信息，在对信息进行组织和处理后，为用户提供检索服务，将用户检索相关的信息展示给用户的系统。搜索引擎包括全文索引、目录索引、元搜索引擎、垂直搜索引擎、集合式搜索引擎、门户搜索引擎与免费链接列表等。 + +![搜索引擎](https://img-blog.csdnimg.cn/img_convert/68fe865a9d87de361c45f4a42d624035.png) + +12. **垂直搜索引擎** ：垂直搜索引擎是针对某一个行业的专业搜索引擎，是搜索引擎的细分和延伸，是对网页库中的某类专门的信息进行一次整合，定向分字段抽取出需要的数据进行处理后再以某种形式返回给用户。垂直搜索是相对通用搜索引擎的信息量大、查询不准确、深度不够等提出来的新的搜索引擎服务模式，通过针对某一特定领域、某一特定人群或某一特定需求提供的有一定价值的信息和相关服务。其特点就是“专、精、深”，且具有行业色彩，相比较通用搜索引擎的海量信息无序化，垂直搜索引擎则显得更加专注、具体和深入。 +13. **全文索引** :全文索引技术是目前搜索引擎的关键技术。试想在 1M 大小的文件中搜索一个词，可能需要几秒，在 100M 的文件中可能需要几十秒，如果在更大的文件中搜索那么就需要更大的系统开销，这样的开销是不现实的。所以在这样的矛盾下出现了全文索引技术，有时候有人叫倒排文档技术。 +14. **目录索引** ：目录索引（ search index/directory)，顾名思义就是将网站分门别类地存放在相应的目录中，因此用户在查询信息时，可选择关键词搜索，也可按分类目录逐层查找。 + +### 6.2. 重要知识点总结 + +1. 文件传输协议（FTP）使用 TCP 可靠的运输服务。FTP 使用客户服务器方式。一个 FTP 服务器进程可以同时为多个用户提供服务。在进行文件传输时，FTP 的客户和服务器之间要先建立两个并行的 TCP 连接:控制连接和数据连接。实际用于传输文件的是数据连接。 +2. 万维网客户程序与服务器之间进行交互使用的协议是超文本传输协议 HTTP。HTTP 使用 TCP 连接进行可靠传输。但 HTTP 本身是无连接、无状态的。HTTP/1.1 协议使用了持续连接（分为非流水线方式和流水线方式） +3. 电子邮件把邮件发送到收件人使用的邮件服务器，并放在其中的收件人邮箱中，收件人可随时上网到自己使用的邮件服务器读取，相当于电子邮箱。 +4. 一个电子邮件系统有三个重要组成构件：用户代理、邮件服务器、邮件协议（包括邮件发送协议，如 SMTP，和邮件读取协议，如 POP3 和 IMAP）。用户代理和邮件服务器都要运行这些协议。 + +### 6.3. 补充（重要） + +以下知识点需要重点关注： + +1. 应用层的常见协议（重点关注 HTTP 协议） +2. 域名系统-从域名解析出 IP 地址 +3. 访问一个网站大致的过程 +4. 系统调用和应用编程接口概念 diff --git a/docs/cs-basics/operating-system/images/Linux-Logo.png b/docs/cs-basics/operating-system/images/Linux-Logo.png new file mode 100644 index 0000000000000000000000000000000000000000..a3baa4124ca783cc629f2325551e37ad6eea40e4 Binary files /dev/null and b/docs/cs-basics/operating-system/images/Linux-Logo.png differ diff --git "a/docs/cs-basics/operating-system/images/Linux\344\271\213\347\210\266.png" "b/docs/cs-basics/operating-system/images/Linux\344\271\213\347\210\266.png" new file mode 100644 index 0000000000000000000000000000000000000000..80c331948e9782da58e8043904d3f4963d48f7e8 Binary files /dev/null and "b/docs/cs-basics/operating-system/images/Linux\344\271\213\347\210\266.png" differ diff --git "a/docs/cs-basics/operating-system/images/Linux\346\235\203\351\231\220\345\221\275\344\273\244.png" "b/docs/cs-basics/operating-system/images/Linux\346\235\203\351\231\220\345\221\275\344\273\244.png" new file mode 100644 index 0000000000000000000000000000000000000000..4d1cb5b154e7dc2ad67a593f65c24b72b4366096 Binary files /dev/null and "b/docs/cs-basics/operating-system/images/Linux\346\235\203\351\231\220\345\221\275\344\273\244.png" differ diff --git "a/docs/cs-basics/operating-system/images/Linux\346\235\203\351\231\220\350\247\243\350\257\273.png" "b/docs/cs-basics/operating-system/images/Linux\346\235\203\351\231\220\350\247\243\350\257\273.png" new file mode 100644 index 0000000000000000000000000000000000000000..de9b8ab0a74fbb262774c5dfe6d92c02f518e10d Binary files /dev/null and "b/docs/cs-basics/operating-system/images/Linux\346\235\203\351\231\220\350\247\243\350\257\273.png" differ diff --git "a/docs/cs-basics/operating-system/images/Linux\347\233\256\345\275\225\346\240\221.png" "b/docs/cs-basics/operating-system/images/Linux\347\233\256\345\275\225\346\240\221.png" new file mode 100644 index 0000000000000000000000000000000000000000..f93ef5d00a694c44f49395821150d8f3db9479f4 Binary files /dev/null and "b/docs/cs-basics/operating-system/images/Linux\347\233\256\345\275\225\346\240\221.png" differ diff --git a/docs/cs-basics/operating-system/images/linux.png b/docs/cs-basics/operating-system/images/linux.png new file mode 100644 index 0000000000000000000000000000000000000000..121db5060aa9eafd291a7a9e7c105d272be5a195 Binary files /dev/null and b/docs/cs-basics/operating-system/images/linux.png differ diff --git a/docs/cs-basics/operating-system/images/macos.png b/docs/cs-basics/operating-system/images/macos.png new file mode 100644 index 0000000000000000000000000000000000000000..e05e203506d9bce1e79ea4577c6621069c7f4899 Binary files /dev/null and b/docs/cs-basics/operating-system/images/macos.png differ diff --git a/docs/cs-basics/operating-system/images/unix.png b/docs/cs-basics/operating-system/images/unix.png new file mode 100644 index 0000000000000000000000000000000000000000..5771653f1cbb718978f42c2c6ee05928687125ee Binary files /dev/null and b/docs/cs-basics/operating-system/images/unix.png differ diff --git a/docs/cs-basics/operating-system/images/windows.png b/docs/cs-basics/operating-system/images/windows.png new file mode 100644 index 0000000000000000000000000000000000000000..f85ec8e68eccfe1dbf567debadd797ab4e627074 Binary files /dev/null and b/docs/cs-basics/operating-system/images/windows.png differ diff --git "a/docs/cs-basics/operating-system/images/\344\277\256\346\224\271\346\226\207\344\273\266\346\235\203\351\231\220.png" "b/docs/cs-basics/operating-system/images/\344\277\256\346\224\271\346\226\207\344\273\266\346\235\203\351\231\220.png" new file mode 100644 index 0000000000000000000000000000000000000000..fb9551b11725f87df10ca211bd7f75b8cc0ce745 Binary files /dev/null and "b/docs/cs-basics/operating-system/images/\344\277\256\346\224\271\346\226\207\344\273\266\346\235\203\351\231\220.png" differ diff --git "a/docs/cs-basics/operating-system/images/\346\226\207\344\273\266inode\344\277\241\346\201\257.png" "b/docs/cs-basics/operating-system/images/\346\226\207\344\273\266inode\344\277\241\346\201\257.png" new file mode 100644 index 0000000000000000000000000000000000000000..3f40dbeea68bf1680cba72788b4a39ccf4448ce4 Binary files /dev/null and "b/docs/cs-basics/operating-system/images/\346\226\207\344\273\266inode\344\277\241\346\201\257.png" differ diff --git "a/docs/cs-basics/operating-system/images/\347\224\250\346\210\267\346\200\201\344\270\216\345\206\205\346\240\270\346\200\201.png" "b/docs/cs-basics/operating-system/images/\347\224\250\346\210\267\346\200\201\344\270\216\345\206\205\346\240\270\346\200\201.png" new file mode 100644 index 0000000000000000000000000000000000000000..568fe38efb87aca9b73a926c7cc89ea3d947ebd5 Binary files /dev/null and "b/docs/cs-basics/operating-system/images/\347\224\250\346\210\267\346\200\201\344\270\216\345\206\205\346\240\270\346\200\201.png" differ diff --git "a/docs/cs-basics/operating-system/images/\350\277\233\347\250\213-\350\265\204\346\272\220\345\210\206\351\205\215\345\233\276.jpg" "b/docs/cs-basics/operating-system/images/\350\277\233\347\250\213-\350\265\204\346\272\220\345\210\206\351\205\215\345\233\276.jpg" new file mode 100644 index 0000000000000000000000000000000000000000..812c6a15a63547fc73912c15bad02485424a3c3c Binary files /dev/null and "b/docs/cs-basics/operating-system/images/\350\277\233\347\250\213-\350\265\204\346\272\220\345\210\206\351\205\215\345\233\276.jpg" differ diff --git a/docs/cs-basics/operating-system/linux-intro.md b/docs/cs-basics/operating-system/linux-intro.md new file mode 100644 index 0000000000000000000000000000000000000000..0a4f5aba0041779cfc9bb41c776c4e7bac763790 --- /dev/null +++ b/docs/cs-basics/operating-system/linux-intro.md @@ -0,0 +1,412 @@ +--- +title: 后端程序员必备的 Linux 基础知识总结 +category: 计算机基础 +tag: + - 操作系统 + - Linux +--- + +简单介绍一下 Java 程序员必知的 Linux 的一些概念以及常见命令。 + +_如果文章有任何需要改善和完善的地方，欢迎在评论区指出，共同进步！笔芯！_ + +## 1. 从认识操作系统开始 + +![](https://guide-blog-images.oss-cn-shenzhen.aliyuncs.com/2020-8/image-20200807161118901.png) + +正式开始 Linux 之前，简单花一点点篇幅科普一下操作系统相关的内容。 + +### 1.1. 操作系统简介 + +我通过以下四点介绍什么是操作系统： + +1. **操作系统（Operating System，简称 OS）是管理计算机硬件与软件资源的程序，是计算机的基石。** +2. **操作系统本质上是一个运行在计算机上的软件程序 ，用于管理计算机硬件和软件资源。** 举例：运行在你电脑上的所有应用程序都通过操作系统来调用系统内存以及磁盘等等硬件。 +3. **操作系统存在屏蔽了硬件层的复杂性。** 操作系统就像是硬件使用的负责人，统筹着各种相关事项。 +4. **操作系统的内核（Kernel）是操作系统的核心部分，它负责系统的内存管理，硬件设备的管理，文件系统的管理以及应用程序的管理**。 + +> 内核（Kernel）在后文中会提到。 + +![Kernel_Layout](https://guide-blog-images.oss-cn-shenzhen.aliyuncs.com/2020-8/Kernel_Layout.png) + +### 1.2. 操作系统简单分类 + +#### 1.2.1. Windows + +目前最流行的个人桌面操作系统 ，不做多的介绍，大家都清楚。界面简单易操作，软件生态非常好。 + +_玩玩电脑游戏还是必须要有 Windows 的，所以我现在是一台 Windows 用于玩游戏，一台 Mac 用于平时日常开发和学习使用。_ + +![windows](./images/windows.png) + +#### 1.2.2. Unix + +最早的多用户、多任务操作系统 。后面崛起的 Linux 在很多方面都参考了 Unix。 + +目前这款操作系统已经逐渐逐渐退出操作系统的舞台。 + +![unix](./images/unix.png) + +#### 1.2.3. Linux + +**Linux 是一套免费使用、开源的类 Unix 操作系统。** Linux 存在着许多不同的发行版本，但它们都使用了 **Linux 内核** 。 + +> 严格来讲，Linux 这个词本身只表示 Linux 内核，在 GNU/Linux 系统中，Linux 实际就是 Linux 内核，而该系统的其余部分主要是由 GNU 工程编写和提供的程序组成。单独的 Linux 内核并不能成为一个可以正常工作的操作系统。 +> +> **很多人更倾向使用 “GNU/Linux” 一词来表达人们通常所说的 “Linux”。** + +![linux](./images/linux.png) + +#### 1.2.4. Mac OS + +苹果自家的操作系统，编程体验和 Linux 相当，但是界面、软件生态以及用户体验各方面都要比 Linux 操作系统更好。 + +![macos](./images/macos.png) + +### 1.3. 操作系统的内核（Kernel） + +我们先来看看维基百科对于内核的解释，我觉得总结的非常好！ + +> **内核**（英语：Kernel，又称核心）在计算机科学中是一个用来管理软件发出的数据 I/O（输入与输出）要求的电脑程序，将这些要求转译为数据处理的指令并交由中央处理器（CPU）及电脑中其他电子组件进行处理，是现代操作系统中最基本的部分。它是为众多应用程序提供对计算机硬件的安全访问的一部分软件，这种访问是有限的，并由内核决定一个程序在什么时候对某部分硬件操作多长时间。 **直接对硬件操作是非常复杂的。所以内核通常提供一种硬件抽象的方法，来完成这些操作。有了这个，通过进程间通信机制及系统调用，应用进程可间接控制所需的硬件资源（特别是处理器及 IO 设备）。** +> +> 早期计算机系统的设计中，还没有操作系统的内核这个概念。随着计算机系统的发展，操作系统内核的概念才渐渐明晰起来了! + +简单概括两点： + +1. **操作系统的内核（Kernel）是操作系统的核心部分，它负责系统的内存管理，硬件设备的管理，文件系统的管理以及应用程序的管理。** +2. **操作系统的内核是连接应用程序和硬件的桥梁，决定着操作系统的性能和稳定性。** + +### 1.4. 中央处理器（CPU，Central Processing Unit） + +关于 CPU 简单概括三点： + +1. **CPU 是一台计算机的运算核心（Core）+控制核心（ Control Unit），可以称得上是计算机的大脑。** +2. **CPU 主要包括两个部分：控制器+运算器。** +3. **CPU 的根本任务就是执行指令，对计算机来说最终都是一串由“0”和“1”组成的序列。** + +### 1.5. CPU vs Kernel(内核) + +很多人容易无法区分操作系统的内核（Kernel）和中央处理器（CPU），你可以简单从下面两点来区别： + +1. 操作系统的内核（Kernel）属于操作系统层面，而 CPU 属于硬件。 +2. CPU 主要提供运算，处理各种指令的能力。内核（Kernel）主要负责系统管理比如内存管理，它屏蔽了对硬件的操作。 + +下图清晰说明了应用程序、内核、CPU 这三者的关系。 + +![Kernel_Layout](https://guide-blog-images.oss-cn-shenzhen.aliyuncs.com/2020-8/Kernel_Layout.png) + +### 1.6. 系统调用 + +介绍系统调用之前，我们先来了解一下用户态和系统态。 + +根据进程访问资源的特点，我们可以把进程在系统上的运行分为两个级别： + +1. **用户态(user mode)** : 用户态运行的进程或可以直接读取用户程序的数据。 +2. **系统态(kernel mode)**: 可以简单的理解系统态运行的进程或程序几乎可以访问计算机的任何资源，不受限制。 + +**说了用户态和系统态之后，那么什么是系统调用呢？** + +我们运行的程序基本都是运行在用户态，如果我们调用操作系统提供的系统态级别的子功能咋办呢？那就需要系统调用了！ + +也就是说在我们运行的用户程序中，凡是与系统态级别的资源有关的操作（如文件管理、进程控制、内存管理等)，都必须通过系统调用方式向操作系统提出服务请求，并由操作系统代为完成。 + +这些系统调用按功能大致可分为如下几类： + +- **设备管理** ：完成设备的请求或释放，以及设备启动等功能。 +- **文件管理** ：完成文件的读、写、创建及删除等功能。 +- **进程控制** ：完成进程的创建、撤销、阻塞及唤醒等功能。 +- **进程通信** ：完成进程之间的消息传递或信号传递等功能。 +- **内存管理** ：完成内存的分配、回收以及获取作业占用内存区大小及地址等功能。 + +我在网上找了一个图，通过这个图可以很清晰的说明用户程序、系统调用、内核和硬件之间的关系。（_太难了~木有自己画_） + +![](https://guide-blog-images.oss-cn-shenzhen.aliyuncs.com/2020-8/L181kk2Eou-compress.jpg) + +## 2. 初探 Linux + +### 2.1. Linux 简介 + +我们上面已经简单了 Linux，这里只强调三点。 + +- **类 Unix 系统** ： Linux 是一种自由、开放源码的类似 Unix 的操作系统 +- **Linux 本质是指 Linux 内核** ： 严格来讲，Linux 这个词本身只表示 Linux 内核，单独的 Linux 内核并不能成为一个可以正常工作的操作系统。所以，就有了各种 Linux 发行版。 +- **Linux 之父(林纳斯·本纳第克特·托瓦兹 Linus Benedict Torvalds)** ： 一个编程领域的传奇式人物，真大佬！我辈崇拜敬仰之楷模。他是 **Linux 内核** 的最早作者，随后发起了这个开源项目，担任 Linux 内核的首要架构师。他还发起了 Git 这个开源项目，并为主要的开发者。 + +![Linux](./images/Linux之父.png) + +### 2.2. Linux 诞生 + +1989 年，Linus Torvalds 进入芬兰陆军新地区旅，服 11 个月的国家义务兵役，军衔为少尉，主要服务于计算机部门，任务是弹道计算。服役期间，购买了安德鲁·斯图尔特·塔能鲍姆所著的教科书及 minix 源代码，开始研究操作系统。1990 年，他退伍后回到大学，开始接触 Unix。 + +> **Minix** 是一个迷你版本的类 Unix 操作系统，由塔能鲍姆教授为了教学之用而创作，采用微核心设计。它启发了 Linux 内核的创作。 + +1991 年，Linus Torvalds 开源了 Linux 内核。Linux 以一只可爱的企鹅作为标志，象征着敢作敢为、热爱生活。 + +![OPINION: Make the switch to a Linux operating system | Opinion ...](./images/Linux-Logo.png) + +### 2.3. 常见 Linux 发行版本有哪些？ + +Linus Torvalds 开源的只是 Linux 内核，我们上面也提到了操作系统内核的作用。一些组织或厂商将 Linux 内核与各种软件和文档包装起来，并提供系统安装界面和系统配置、设定与管理工具，就构成了 Linux 的发行版本。 + +> 内核主要负责系统的内存管理，硬件设备的管理，文件系统的管理以及应用程序的管理。 + +Linux 的发行版本可以大体分为两类： + +- 商业公司维护的发行版本，以著名的 Red Hat 为代表，比较典型的有 CentOS 。 +- 社区组织维护的发行版本，以 Debian 为代表，比较典型的有 Ubuntu、Debian。 + +对于初学者学习 Linux ,推荐选择 CentOS 。 + +## 3. Linux 文件系统概览 + +### 3.1. Linux 文件系统简介 + +**在 Linux 操作系统中，所有被操作系统管理的资源，例如网络接口卡、磁盘驱动器、打印机、输入输出设备、普通文件或是目录都被看作是一个文件。** 也就是说在 Linux 系统中有一个重要的概念：**一切都是文件**。 + +其实这是 UNIX 哲学的一个体现，在 UNIX 系统中，把一切资源都看作是文件，Linux 的文件系统也是借鉴 UNIX 文件系统而来。 + +### 3.2. inode 介绍 + +**inode 是 linux/unix 文件系统的基础。那么，inode 是什么?有什么作用呢?** + +硬盘的最小存储单位是扇区(Sector)，块(block)由多个扇区组成。文件数据存储在块中。块的最常见的大小是 4kb，约为 8 个连续的扇区组成（每个扇区存储 512 字节）。一个文件可能会占用多个 block，但是一个块只能存放一个文件。 + +虽然，我们将文件存储在了块(block)中，但是我们还需要一个空间来存储文件的 **元信息 metadata** ：如某个文件被分成几块、每一块在的地址、文件拥有者，创建时间，权限，大小等。这种 **存储文件元信息的区域就叫 inode**，译为索引节点：**i（index）+node**。 每个文件都有一个 inode，存储文件的元信息。 + +可以使用 `stat` 命令可以查看文件的 inode 信息。每个 inode 都有一个号码，Linux/Unix 操作系统不使用文件名来区分文件，而是使用 inode 号码区分不同的文件。 + +简单来说：inode 就是用来维护某个文件被分成几块、每一块在的地址、文件拥有者，创建时间，权限，大小等信息。 + +简单总结一下： + +- **inode** ：记录文件的属性信息，可以使用 stat 命令查看 inode 信息。 +- **block** ：实际文件的内容，如果一个文件大于一个块时候，那么将占用多个 block，但是一个块只能存放一个文件。（因为数据是由 inode 指向的，如果有两个文件的数据存放在同一个块中，就会乱套了） + +![文件inode信息](./images/文件inode信息.png) + +### 3.3. Linux 文件类型 + +Linux 支持很多文件类型，其中非常重要的文件类型有: **普通文件**，**目录文件**，**链接文件**，**设备文件**，**管道文件**，**Socket 套接字文件**等。 + +- **普通文件（-）** ： 用于存储信息和数据， Linux 用户可以根据访问权限对普通文件进行查看、更改和删除。比如：图片、声音、PDF、text、视频、源代码等等。 +- **目录文件（d，directory file）** ：目录也是文件的一种，用于表示和管理系统中的文件，目录文件中包含一些文件名和子目录名。打开目录事实上就是打开目录文件。 +- **符号链接文件（l，symbolic link）** ：保留了指向文件的地址而不是文件本身。 +- **字符设备（c，char）** ：用来访问字符设备比如键盘。 +- **设备文件（b，block）** ： 用来访问块设备比如硬盘、软盘。 +- **管道文件(p,pipe)** : 一种特殊类型的文件，用于进程之间的通信。 +- **套接字(s,socket)** ：用于进程间的网络通信，也可以用于本机之间的非网络通信。 + +### 3.4. Linux 目录树 + +所有可操作的计算机资源都存在于目录树这个结构中，对计算资源的访问，可以看做是对这棵目录树的访问。 + +**Linux 的目录结构如下：** + +Linux 文件系统的结构层次鲜明，就像一棵倒立的树，最顶层是其根目录： +![Linux的目录结构](./images/Linux目录树.png) + +**常见目录说明：** + +- **/bin：** 存放二进制可执行文件(ls、cat、mkdir 等)，常用命令一般都在这里； +- **/etc：** 存放系统管理和配置文件； +- **/home：** 存放所有用户文件的根目录，是用户主目录的基点，比如用户 user 的主目录就是/home/user，可以用~user 表示； +- **/usr ：** 用于存放系统应用程序； +- **/opt：** 额外安装的可选应用程序包所放置的位置。一般情况下，我们可以把 tomcat 等都安装到这里； +- **/proc：** 虚拟文件系统目录，是系统内存的映射。可直接访问这个目录来获取系统信息； +- **/root：** 超级用户（系统管理员）的主目录（特权阶级^o^）； +- **/sbin:** 存放二进制可执行文件，只有 root 才能访问。这里存放的是系统管理员使用的系统级别的管理命令和程序。如 ifconfig 等； +- **/dev：** 用于存放设备文件； +- **/mnt：** 系统管理员安装临时文件系统的安装点，系统提供这个目录是让用户临时挂载其他的文件系统； +- **/boot：** 存放用于系统引导时使用的各种文件； +- **/lib ：** 存放着和系统运行相关的库文件 ； +- **/tmp：** 用于存放各种临时文件，是公用的临时文件存储点； +- **/var：** 用于存放运行时需要改变数据的文件，也是某些大文件的溢出区，比方说各种服务的日志文件（系统启动日志等。）等； +- **/lost+found：** 这个目录平时是空的，系统非正常关机而留下“无家可归”的文件（windows 下叫什么.chk）就在这里。 + +## 4. Linux 基本命令 + +下面只是给出了一些比较常用的命令。推荐一个 Linux 命令快查网站，非常不错，大家如果遗忘某些命令或者对某些命令不理解都可以在这里得到解决。 + +Linux 命令大全：[http://man.linuxde.net/](http://man.linuxde.net/) + +### 4.1. 目录切换命令 + +- **`cd usr`：** 切换到该目录下 usr 目录 +- **`cd ..（或cd../）`：** 切换到上一层目录 +- **`cd /`：** 切换到系统根目录 +- **`cd ~`：** 切换到用户主目录 +- **`cd -`：** 切换到上一个操作所在目录 + +### 4.2. 目录的操作命令(增删改查) + +- **`mkdir 目录名称`：** 增加目录。 +- **`ls/ll`**（ll 是 ls -l 的别名，ll 命令可以看到该目录下的所有目录和文件的详细信息）：查看目录信息。 +- **`find 目录 参数`：** 寻找目录（查）。示例：① 列出当前目录及子目录下所有文件和文件夹: `find .`；② 在`/home`目录下查找以.txt 结尾的文件名:`find /home -name "*.txt"` ,忽略大小写: `find /home -iname "*.txt"` ；③ 当前目录及子目录下查找所有以.txt 和.pdf 结尾的文件:`find . \( -name "*.txt" -o -name "*.pdf" \)`或`find . -name "*.txt" -o -name "*.pdf"`。 +- **`mv 目录名称 新目录名称`：** 修改目录的名称（改）。注意：mv 的语法不仅可以对目录进行重命名而且也可以对各种文件，压缩包等进行 重命名的操作。mv 命令用来对文件或目录重新命名，或者将文件从一个目录移到另一个目录中。后面会介绍到 mv 命令的另一个用法。 +- **`mv 目录名称 目录的新位置`：** 移动目录的位置---剪切（改）。注意：mv 语法不仅可以对目录进行剪切操作，对文件和压缩包等都可执行剪切操作。另外 mv 与 cp 的结果不同，mv 好像文件“搬家”，文件个数并未增加。而 cp 对文件进行复制，文件个数增加了。 +- **`cp -r 目录名称 目录拷贝的目标位置`：** 拷贝目录（改），-r 代表递归拷贝 。注意：cp 命令不仅可以拷贝目录还可以拷贝文件，压缩包等，拷贝文件和压缩包时不 用写-r 递归。 +- **`rm [-rf] 目录` :** 删除目录（删）。注意：rm 不仅可以删除目录，也可以删除其他文件或压缩包，为了增强大家的记忆， 无论删除任何目录或文件，都直接使用`rm -rf` 目录/文件/压缩包。 + +### 4.3. 文件的操作命令(增删改查) + +- **`touch 文件名称`:** 文件的创建（增）。 +- **`cat/more/less/tail 文件名称`** ：文件的查看（查） 。命令 `tail -f 文件` 可以对某个文件进行动态监控，例如 tomcat 的日志文件， 会随着程序的运行，日志会变化，可以使用 `tail -f catalina-2016-11-11.log` 监控 文 件的变化 。 +- **`vim 文件`：** 修改文件的内容（改）。vim 编辑器是 Linux 中的强大组件，是 vi 编辑器的加强版，vim 编辑器的命令和快捷方式有很多，但此处不一一阐述，大家也无需研究的很透彻，使用 vim 编辑修改文件的方式基本会使用就可以了。在实际开发中，使用 vim 编辑器主要作用就是修改配置文件，下面是一般步骤： `vim 文件------>进入文件----->命令模式------>按i进入编辑模式----->编辑文件 ------->按Esc进入底行模式----->输入：wq/q!` （输入 wq 代表写入内容并退出，即保存；输入 q!代表强制退出不保存）。 +- **`rm -rf 文件`：** 删除文件（删）。 + +### 4.4. 压缩文件的操作命令 + +**1）打包并压缩文件：** + +Linux 中的打包文件一般是以.tar 结尾的，压缩的命令一般是以.gz 结尾的。而一般情况下打包和压缩是一起进行的，打包并压缩后的文件的后缀名一般.tar.gz。 +命令：`tar -zcvf 打包压缩后的文件名 要打包压缩的文件` ，其中： + +- z：调用 gzip 压缩命令进行压缩 +- c：打包文件 +- v：显示运行过程 +- f：指定文件名 + +比如：假如 test 目录下有三个文件分别是：aaa.txt bbb.txt ccc.txt，如果我们要打包 test 目录并指定压缩后的压缩包名称为 test.tar.gz 可以使用命令：**`tar -zcvf test.tar.gz aaa.txt bbb.txt ccc.txt` 或 `tar -zcvf test.tar.gz /test/`** + +**2）解压压缩包：** + +命令：`tar [-xvf] 压缩文件` + +其中：x：代表解压 + +示例： + +- 将 /test 下的 test.tar.gz 解压到当前目录下可以使用命令：**`tar -xvf test.tar.gz`** +- 将 /test 下的 test.tar.gz 解压到根目录/usr 下:**`tar -xvf test.tar.gz -C /usr`**（- C 代表指定解压的位置） + +### 4.5. Linux 的权限命令 + +操作系统中每个文件都拥有特定的权限、所属用户和所属组。权限是操作系统用来限制资源访问的机制，在 Linux 中权限一般分为读(readable)、写(writable)和执行(excutable)，分为三组。分别对应文件的属主(owner)，属组(group)和其他用户(other)，通过这样的机制来限制哪些用户、哪些组可以对特定的文件进行什么样的操作。 + +通过 **`ls -l`** 命令我们可以 查看某个目录下的文件或目录的权限 + +示例：在随意某个目录下`ls -l` + +![](./images/Linux权限命令.png) + +第一列的内容的信息解释如下： + +![](./images/Linux权限解读.png) + +> 下面将详细讲解文件的类型、Linux 中权限以及文件有所有者、所在组、其它组具体是什么？ + +**文件的类型：** + +- d： 代表目录 +- -： 代表文件 +- l： 代表软链接（可以认为是 window 中的快捷方式） + +**Linux 中权限分为以下几种：** + +- r：代表权限是可读，r 也可以用数字 4 表示 +- w：代表权限是可写，w 也可以用数字 2 表示 +- x：代表权限是可执行，x 也可以用数字 1 表示 + +**文件和目录权限的区别：** + +对文件和目录而言，读写执行表示不同的意义。 + +对于文件： + +| 权限名称 | 可执行操作 | +| :------- | --------------------------: | +| r | 可以使用 cat 查看文件的内容 | +| w | 可以修改文件的内容 | +| x | 可以将其运行为二进制文件 | + +对于目录： + +| 权限名称 | 可执行操作 | +| :------- | -----------------------: | +| r | 可以查看目录下列表 | +| w | 可以创建和删除目录下文件 | +| x | 可以使用 cd 进入目录 | + +需要注意的是： **超级用户可以无视普通用户的权限，即使文件目录权限是 000，依旧可以访问。** + +**在 linux 中的每个用户必须属于一个组，不能独立于组外。在 linux 中每个文件有所有者、所在组、其它组的概念。** + +- **所有者(u)** ：一般为文件的创建者，谁创建了该文件，就天然的成为该文件的所有者，用 `ls ‐ahl` 命令可以看到文件的所有者 也可以使用 chown 用户名 文件名来修改文件的所有者 。 +- **文件所在组(g)** ：当某个用户创建了一个文件后，这个文件的所在组就是该用户所在的组用 `ls ‐ahl`命令可以看到文件的所有组也可以使用 chgrp 组名 文件名来修改文件所在的组。 +- **其它组(o)** ：除开文件的所有者和所在组的用户外，系统的其它用户都是文件的其它组。 + +> 我们再来看看如何修改文件/目录的权限。 + +**修改文件/目录的权限的命令：`chmod`** + +示例：修改/test 下的 aaa.txt 的权限为文件所有者有全部权限，文件所有者所在的组有读写权限，其他用户只有读的权限。 + +**`chmod u=rwx,g=rw,o=r aaa.txt`** 或者 **`chmod 764 aaa.txt`** + +![](./images/修改文件权限.png) + +**补充一个比较常用的东西:** + +假如我们装了一个 zookeeper，我们每次开机到要求其自动启动该怎么办？ + +1. 新建一个脚本 zookeeper +2. 为新建的脚本 zookeeper 添加可执行权限，命令是:`chmod +x zookeeper` +3. 把 zookeeper 这个脚本添加到开机启动项里面，命令是：`chkconfig --add zookeeper` +4. 如果想看看是否添加成功，命令是：`chkconfig --list` + +### 4.6. Linux 用户管理 + +Linux 系统是一个多用户多任务的分时操作系统，任何一个要使用系统资源的用户，都必须首先向系统管理员申请一个账号，然后以这个账号的身份进入系统。 + +用户的账号一方面可以帮助系统管理员对使用系统的用户进行跟踪，并控制他们对系统资源的访问；另一方面也可以帮助用户组织文件，并为用户提供安全性保护。 + +**Linux 用户管理相关命令:** + +- `useradd 选项 用户名`:添加用户账号 +- `userdel 选项 用户名`:删除用户帐号 +- `usermod 选项 用户名`:修改帐号 +- `passwd 用户名`:更改或创建用户的密码 +- `passwd -S 用户名` :显示用户账号密码信息 +- `passwd -d 用户名`: 清除用户密码 + +`useradd` 命令用于 Linux 中创建的新的系统用户。`useradd`可用来建立用户帐号。帐号建好之后，再用`passwd`设定帐号的密码．而可用`userdel`删除帐号。使用`useradd`指令所建立的帐号，实际上是保存在 `/etc/passwd`文本文件中。 + +`passwd`命令用于设置用户的认证信息，包括用户密码、密码过期时间等。系统管理者则能用它管理系统用户的密码。只有管理者可以指定用户名称，一般用户只能变更自己的密码。 + +### 4.7. Linux 系统用户组的管理 + +每个用户都有一个用户组，系统可以对一个用户组中的所有用户进行集中管理。不同 Linux 系统对用户组的规定有所不同，如 Linux 下的用户属于与它同名的用户组，这个用户组在创建用户时同时创建。 + +用户组的管理涉及用户组的添加、删除和修改。组的增加、删除和修改实际上就是对`/etc/group`文件的更新。 + +**Linux 系统用户组的管理相关命令:** + +- `groupadd 选项 用户组` :增加一个新的用户组 +- `groupdel 用户组`:要删除一个已有的用户组 +- `groupmod 选项 用户组` : 修改用户组的属性 + +### 4.8. 其他常用命令 + +- **`pwd`：** 显示当前所在位置 + +- `sudo + 其他命令`：以系统管理者的身份执行指令，也就是说，经由 sudo 所执行的指令就好像是 root 亲自执行。 + +- **`grep 要搜索的字符串 要搜索的文件 --color`：** 搜索命令，--color 代表高亮显示 + +- **`ps -ef`/`ps -aux`：** 这两个命令都是查看当前系统正在运行进程，两者的区别是展示格式不同。如果想要查看特定的进程可以使用这样的格式：**`ps aux|grep redis`** （查看包括 redis 字符串的进程），也可使用 `pgrep redis -a`。 + + 注意：如果直接用 ps（（Process Status））命令，会显示所有进程的状态，通常结合 grep 命令查看某进程的状态。 + +- **`kill -9 进程的pid`：** 杀死进程（-9 表示强制终止。） + + 先用 ps 查找进程，然后用 kill 杀掉 + +- **网络通信命令：** + - 查看当前系统的网卡信息：ifconfig + - 查看与某台机器的连接情况：ping + - 查看当前系统的端口使用：netstat -an +- **net-tools 和 iproute2 ：** + `net-tools`起源于 BSD 的 TCP/IP 工具箱，后来成为老版本 LinuxLinux 中配置网络功能的工具。但自 2001 年起，Linux 社区已经对其停止维护。同时，一些 Linux 发行版比如 Arch Linux 和 CentOS/RHEL 7 则已经完全抛弃了 net-tools，只支持`iproute2`。linux ip 命令类似于 ifconfig，但功能更强大，旨在替代它。更多详情请阅读[如何在 Linux 中使用 IP 命令和示例](https://linoxide.com/linux-command/use-ip-command-linux) +- **`shutdown`：** `shutdown -h now`： 指定现在立即关机；`shutdown +5 "System will shutdown after 5 minutes"`：指定 5 分钟后关机，同时送出警告信息给登入用户。 + +- **`reboot`：** **`reboot`：** 重开机。**`reboot -w`：** 做个重开机的模拟（只有纪录并不会真的重开机）。 diff --git a/docs/cs-basics/operating-system/operating-system-basic-questions-01.md b/docs/cs-basics/operating-system/operating-system-basic-questions-01.md new file mode 100644 index 0000000000000000000000000000000000000000..4d4c96c530a6c62bae988676d4744813194727e7 --- /dev/null +++ b/docs/cs-basics/operating-system/operating-system-basic-questions-01.md @@ -0,0 +1,438 @@ +--- +title: 操作系统常见面试题总结 +category: 计算机基础 +tag: + - 操作系统 +--- + +很多读者抱怨计算操作系统的知识点比较繁杂，自己也没有多少耐心去看，但是面试的时候又经常会遇到。所以，我带着我整理好的操作系统的常见问题来啦！这篇文章总结了一些我觉得比较重要的操作系统相关的问题比如**进程管理**、**内存管理**、**虚拟内存**等等。 + +文章形式通过大部分比较喜欢的面试官和求职者之间的对话形式展开。另外，Guide 哥 也只是在大学的时候学习过操作系统，不过基本都忘了，为了写这篇文章这段时间看了很多相关的书籍和博客。如果文中有任何需要补充和完善的地方，你都可以在 issue 中指出！ + +这篇文章只是对一些操作系统比较重要概念的一个概览，深入学习的话，建议大家还是老老实实地去看书。另外， 这篇文章的很多内容参考了《现代操作系统》第三版这本书，非常感谢。 + +开始本文的内容之前，我们先聊聊为什么要学习操作系统。 + +- **从对个人能力方面提升来说** ：操作系统中的很多思想、很多经典的算法，你都可以在我们日常开发使用的各种工具或者框架中找到它们的影子。比如说我们开发的系统使用的缓存（比如 Redis）和操作系统的高速缓存就很像。CPU 中的高速缓存有很多种，不过大部分都是为了解决 CPU 处理速度和内存处理速度不对等的问题。我们还可以把内存看作外存的高速缓存，程序运行的时候我们把外存的数据复制到内存，由于内存的处理速度远远高于外存，这样提高了处理速度。同样地，我们使用的 Redis 缓存就是为了解决程序处理速度和访问常规关系型数据库速度不对等的问题。高速缓存一般会按照局部性原理（2-8 原则）根据相应的淘汰算法保证缓存中的数据是经常会被访问的。我们平常使用的 Redis 缓存很多时候也会按照 2-8 原则去做，很多淘汰算法都和操作系统中的类似。既说了 2-8 原则，那就不得不提命中率了，这是所有缓存概念都通用的。简单来说也就是你要访问的数据有多少能直接在缓存中直接找到。命中率高的话，一般表明你的缓存设计比较合理，系统处理速度也相对较快。 +- **从面试角度来说** ：尤其是校招，对于操作系统方面知识的考察是非常非常多的。 + +**简单来说，学习操作系统能够提高自己思考的深度以及对技术的理解力，并且，操作系统方面的知识也是面试必备。** + +关于如何学习操作系统，可以看这篇回答：[https://www.zhihu.com/question/270998611/answer/1640198217](https://www.zhihu.com/question/270998611/answer/1640198217)。 + +## 一 操作系统基础 + +面试官顶着蓬松的假发向我走来，只见他一手拿着厚重的 Thinkpad ，一手提着他那淡黄的长裙。 + +### 1.1 什么是操作系统？ + +👨‍💻**面试官** ： 先来个简单问题吧！**什么是操作系统？** + +🙋 **我** ：我通过以下四点向您介绍一下什么是操作系统吧！ + +1. **操作系统（Operating System，简称 OS）是管理计算机硬件与软件资源的程序，是计算机的基石。** +2. **操作系统本质上是一个运行在计算机上的软件程序 ，用于管理计算机硬件和软件资源。** 举例：运行在你电脑上的所有应用程序都通过操作系统来调用系统内存以及磁盘等等硬件。 +3. **操作系统存在屏蔽了硬件层的复杂性。** 操作系统就像是硬件使用的负责人，统筹着各种相关事项。 +4. **操作系统的内核（Kernel）是操作系统的核心部分，它负责系统的内存管理，硬件设备的管理，文件系统的管理以及应用程序的管理**。 内核是连接应用程序和硬件的桥梁，决定着系统的性能和稳定性。 + +![Kernel_Layout](https://guide-blog-images.oss-cn-shenzhen.aliyuncs.com/2020-8/Kernel_Layout.png) + +### 1.2 系统调用 + +👨‍💻**面试官** ：**什么是系统调用呢？** 能不能详细介绍一下。 + +🙋 **我** ：介绍系统调用之前，我们先来了解一下用户态和系统态。 + +根据进程访问资源的特点，我们可以把进程在系统上的运行分为两个级别： + +1. 用户态(user mode) : 用户态运行的进程可以直接读取用户程序的数据。 +2. 系统态(kernel mode):可以简单的理解系统态运行的进程或程序几乎可以访问计算机的任何资源，不受限制。 + +说了用户态和系统态之后，那么什么是系统调用呢？ + +我们运行的程序基本都是运行在用户态，如果我们调用操作系统提供的系统态级别的子功能咋办呢？那就需要系统调用了！ + +也就是说在我们运行的用户程序中，凡是与系统态级别的资源有关的操作（如文件管理、进程控制、内存管理等)，都必须通过系统调用方式向操作系统提出服务请求，并由操作系统代为完成。 + +这些系统调用按功能大致可分为如下几类： + +- 设备管理。完成设备的请求或释放，以及设备启动等功能。 +- 文件管理。完成文件的读、写、创建及删除等功能。 +- 进程控制。完成进程的创建、撤销、阻塞及唤醒等功能。 +- 进程通信。完成进程之间的消息传递或信号传递等功能。 +- 内存管理。完成内存的分配、回收以及获取作业占用内存区大小及地址等功能。 + +## 二 进程和线程 + +### 2.1 进程和线程的区别 + +👨‍💻**面试官**: 好的！我明白了！那你再说一下： **进程和线程的区别**。 + +🙋 **我：** 好的！ 下图是 Java 内存区域，我们从 JVM 的角度来说一下线程和进程之间的关系吧！ + +![](https://oscimg.oschina.net/oscnet/up-cd8ac705f6f004c01e0a1312f1599430ba5.png) + +从上图可以看出：一个进程中可以有多个线程，多个线程共享进程的**堆**和**方法区 (JDK1.8 之后的元空间)**资源，但是每个线程有自己的**程序计数器**、**虚拟机栈** 和 **本地方法栈**。 + +**总结：** 线程是进程划分成的更小的运行单位,一个进程在其执行的过程中可以产生多个线程。线程和进程最大的不同在于基本上各进程是独立的，而各线程则不一定，因为同一进程中的线程极有可能会相互影响。线程执行开销小，但不利于资源的管理和保护；而进程正相反。 + +### 2.2 进程有哪几种状态? + +👨‍💻**面试官** ： 那你再说说**进程有哪几种状态?** + +🙋 **我** ：我们一般把进程大致分为 5 种状态，这一点和[线程](https://github.com/Snailclimb/JavaGuide/blob/master/docs/java/Multithread/JavaConcurrencyBasicsCommonInterviewQuestionsSummary.md#6-%E8%AF%B4%E8%AF%B4%E7%BA%BF%E7%A8%8B%E7%9A%84%E7%94%9F%E5%91%BD%E5%91%A8%E6%9C%9F%E5%92%8C%E7%8A%B6%E6%80%81)很像！ + +- **创建状态(new)** ：进程正在被创建，尚未到就绪状态。 +- **就绪状态(ready)** ：进程已处于准备运行状态，即进程获得了除了处理器之外的一切所需资源，一旦得到处理器资源(处理器分配的时间片)即可运行。 +- **运行状态(running)** ：进程正在处理器上上运行(单核 CPU 下任意时刻只有一个进程处于运行状态)。 +- **阻塞状态(waiting)** ：又称为等待状态，进程正在等待某一事件而暂停运行如等待某资源为可用或等待 IO 操作完成。即使处理器空闲，该进程也不能运行。 +- **结束状态(terminated)** ：进程正在从系统中消失。可能是进程正常结束或其他原因中断退出运行。 + +> 订正：下图中 running 状态被 interrupt 向 ready 状态转换的箭头方向反了。 + +![process-state](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/2019-11/d38202593012b457debbcd74994c6292.png) + +### 2.3 进程间的通信方式 + +👨‍💻**面试官** ：**进程间的通信常见的的有哪几种方式呢?** + +🙋 **我** ：大概有 7 种常见的进程间的通信方式。 + +> 下面这部分总结参考了:[《进程间通信 IPC (InterProcess Communication)》](https://www.jianshu.com/p/c1015f5ffa74) 这篇文章，推荐阅读，总结的非常不错。 + +1. **管道/匿名管道(Pipes)** ：用于具有亲缘关系的父子进程间或者兄弟进程之间的通信。 +1. **有名管道(Names Pipes)** : 匿名管道由于没有名字，只能用于亲缘关系的进程间通信。为了克服这个缺点，提出了有名管道。有名管道严格遵循**先进先出(first in first out)**。有名管道以磁盘文件的方式存在，可以实现本机任意两个进程通信。 +1. **信号(Signal)** ：信号是一种比较复杂的通信方式，用于通知接收进程某个事件已经发生； +1. **消息队列(Message Queuing)** ：消息队列是消息的链表,具有特定的格式,存放在内存中并由消息队列标识符标识。管道和消息队列的通信数据都是先进先出的原则。与管道（无名管道：只存在于内存中的文件；命名管道：存在于实际的磁盘介质或者文件系统）不同的是消息队列存放在内核中，只有在内核重启(即，操作系统重启)或者显式地删除一个消息队列时，该消息队列才会被真正的删除。消息队列可以实现消息的随机查询,消息不一定要以先进先出的次序读取,也可以按消息的类型读取.比 FIFO 更有优势。**消息队列克服了信号承载信息量少，管道只能承载无格式字 节流以及缓冲区大小受限等缺点。** +1. **信号量(Semaphores)** ：信号量是一个计数器，用于多进程对共享数据的访问，信号量的意图在于进程间同步。这种通信方式主要用于解决与同步相关的问题并避免竞争条件。 +1. **共享内存(Shared memory)** ：使得多个进程可以访问同一块内存空间，不同进程可以及时看到对方进程中对共享内存中数据的更新。这种方式需要依靠某种同步操作，如互斥锁和信号量等。可以说这是最有用的进程间通信方式。 +1. **套接字(Sockets)** : 此方法主要用于在客户端和服务器之间通过网络进行通信。套接字是支持 TCP/IP 的网络通信的基本操作单元，可以看做是不同主机之间的进程进行双向通信的端点，简单的说就是通信的两方的一种约定，用套接字中的相关函数来完成通信过程。 + +### 2.4 线程间的同步的方式 + +👨‍💻**面试官** ：**那线程间的同步的方式有哪些呢?** + +🙋 **我** ：线程同步是两个或多个共享关键资源的线程的并发执行。应该同步线程以避免关键的资源使用冲突。操作系统一般有下面三种线程同步的方式： + +1. **互斥量(Mutex)**：采用互斥对象机制，只有拥有互斥对象的线程才有访问公共资源的权限。因为互斥对象只有一个，所以可以保证公共资源不会被多个线程同时访问。比如 Java 中的 synchronized 关键词和各种 Lock 都是这种机制。 +1. **信号量(Semphares)** ：它允许同一时刻多个线程访问同一资源，但是需要控制同一时刻访问此资源的最大线程数量。 +1. **事件(Event)** :Wait/Notify：通过通知操作的方式来保持多线程同步，还可以方便的实现多线程优先级的比较操作。 + +### 2.5 进程的调度算法 + +👨‍💻**面试官** ：**你知道操作系统中进程的调度算法有哪些吗?** + +🙋 **我** ：嗯嗯！这个我们大学的时候学过，是一个很重要的知识点！ + +为了确定首先执行哪个进程以及最后执行哪个进程以实现最大 CPU 利用率，计算机科学家已经定义了一些算法，它们是： + +- **先到先服务(FCFS)调度算法** : 从就绪队列中选择一个最先进入该队列的进程为之分配资源，使它立即执行并一直执行到完成或发生某事件而被阻塞放弃占用 CPU 时再重新调度。 +- **短作业优先(SJF)的调度算法** : 从就绪队列中选出一个估计运行时间最短的进程为之分配资源，使它立即执行并一直执行到完成或发生某事件而被阻塞放弃占用 CPU 时再重新调度。 +- **时间片轮转调度算法** : 时间片轮转调度是一种最古老，最简单，最公平且使用最广的算法，又称 RR(Round robin)调度。每个进程被分配一个时间段，称作它的时间片，即该进程允许运行的时间。 +- **多级反馈队列调度算法** ：前面介绍的几种进程调度的算法都有一定的局限性。如**短进程优先的调度算法，仅照顾了短进程而忽略了长进程** 。多级反馈队列调度算法既能使高优先级的作业得到响应又能使短作业（进程）迅速完成。，因而它是目前**被公认的一种较好的进程调度算法**，UNIX 操作系统采取的便是这种调度算法。 +- **优先级调度** ： 为每个流程分配优先级，首先执行具有最高优先级的进程，依此类推。具有相同优先级的进程以 FCFS 方式执行。可以根据内存要求，时间要求或任何其他资源要求来确定优先级。 + +### 2.6 什么是死锁 + +👨‍💻**面试官** ：**你知道什么是死锁吗?** + +🙋 **我** ：多个进程可以竞争有限数量的资源。当一个进程申请资源时，如果这时没有可用资源，那么这个进程进入等待状态。有时，如果所申请的资源被其他等待进程占有，那么该等待进程有可能再也无法改变状态。这种情况称为 **死锁**。 + +### 2.7 死锁的四个条件 + +👨‍💻**面试官** ：**产生死锁的四个必要条件是什么?** + +🙋 **我** ：如果系统中以下四个条件同时成立，那么就能引起死锁： + +- **互斥**：资源必须处于非共享模式，即一次只有一个进程可以使用。如果另一进程申请该资源，那么必须等待直到该资源被释放为止。 +- **占有并等待**：一个进程至少应该占有一个资源，并等待另一资源，而该资源被其他进程所占有。 +- **非抢占**：资源不能被抢占。只能在持有资源的进程完成任务后，该资源才会被释放。 +- **循环等待**：有一组等待进程 `{P0, P1,..., Pn}`， `P0` 等待的资源被 `P1` 占有，`P1` 等待的资源被 `P2` 占有，......，`Pn-1` 等待的资源被 `Pn` 占有，`Pn` 等待的资源被 `P0` 占有。 + +注意，只有四个条件同时成立时，死锁才会出现。 + +### 2.8 解决死锁的方法 + +解决死锁的方法可以从多个角度去分析，一般的情况下，有**预防，避免，检测和解除四种**。 + +- **预防** 是采用某种策略，**限制并发进程对资源的请求**，从而使得死锁的必要条件在系统执行的任何时间上都不满足。 + +- **避免**则是系统在分配资源时，根据资源的使用情况**提前做出预测**，从而**避免死锁的发生** + +- **检测**是指系统设有**专门的机构**，当死锁发生时，该机构能够检测死锁的发生，并精确地确定与死锁有关的进程和资源。 +- **解除** 是与检测相配套的一种措施，用于**将进程从死锁状态下解脱出来**。 + +#### 死锁的预防 + +死锁四大必要条件上面都已经列出来了，很显然，只要破坏四个必要条件中的任何一个就能够预防死锁的发生。 + +破坏第一个条件 **互斥条件**：使得资源是可以同时访问的，这是种简单的方法，磁盘就可以用这种方法管理，但是我们要知道，有很多资源 **往往是不能同时访问的** ，所以这种做法在大多数的场合是行不通的。 + +破坏第三个条件 **非抢占** ：也就是说可以采用 **剥夺式调度算法**，但剥夺式调度方法目前一般仅适用于 **主存资源** 和 **处理器资源** 的分配，并不适用于所以的资源，会导致 **资源利用率下降**。 + +所以一般比较实用的 **预防死锁的方法**，是通过考虑破坏第二个条件和第四个条件。 + +**1、静态分配策略** + +静态分配策略可以破坏死锁产生的第二个条件（占有并等待）。所谓静态分配策略，就是指一个进程必须在执行前就申请到它所需要的全部资源，并且知道它所要的资源都得到满足之后才开始执行。进程要么占有所有的资源然后开始执行，要么不占有资源，不会出现占有一些资源等待一些资源的情况。 + +静态分配策略逻辑简单，实现也很容易，但这种策略 **严重地降低了资源利用率**，因为在每个进程所占有的资源中，有些资源是在比较靠后的执行时间里采用的，甚至有些资源是在额外的情况下才是用的，这样就可能造成了一个进程占有了一些 **几乎不用的资源而使其他需要该资源的进程产生等待** 的情况。 + +**2、层次分配策略** + +层次分配策略破坏了产生死锁的第四个条件(循环等待)。在层次分配策略下，所有的资源被分成了多个层次，一个进程得到某一次的一个资源后，它只能再申请较高一层的资源；当一个进程要释放某层的一个资源时，必须先释放所占用的较高层的资源，按这种策略，是不可能出现循环等待链的，因为那样的话，就出现了已经申请了较高层的资源，反而去申请了较低层的资源，不符合层次分配策略，证明略。 + +#### 死锁的避免 + +上面提到的 **破坏** 死锁产生的四个必要条件之一就可以成功 **预防系统发生死锁** ，但是会导致 **低效的进程运行** 和 **资源使用率** 。而死锁的避免相反，它的角度是允许系统中**同时存在四个必要条件** ，只要掌握并发进程中与每个进程有关的资源动态申请情况，做出 **明智和合理的选择** ，仍然可以避免死锁，因为四大条件仅仅是产生死锁的必要条件。 + +我们将系统的状态分为 **安全状态** 和 **不安全状态** ，每当在未申请者分配资源前先测试系统状态，若把系统资源分配给申请者会产生死锁，则拒绝分配，否则接受申请，并为它分配资源。 + +> 如果操作系统能够保证所有的进程在有限的时间内得到需要的全部资源，则称系统处于安全状态，否则说系统是不安全的。很显然，系统处于安全状态则不会发生死锁，系统若处于不安全状态则可能发生死锁。 + +那么如何保证系统保持在安全状态呢？通过算法，其中最具有代表性的 **避免死锁算法** 就是 Dijkstra 的银行家算法，银行家算法用一句话表达就是：当一个进程申请使用资源的时候，**银行家算法** 通过先 **试探** 分配给该进程资源，然后通过 **安全性算法** 判断分配后系统是否处于安全状态，若不安全则试探分配作废，让该进程继续等待，若能够进入到安全的状态，则就 **真的分配资源给该进程**。 + +银行家算法详情可见：[《一句话+一张图说清楚——银行家算法》](https://blog.csdn.net/qq_33414271/article/details/80245715) 。 + +操作系统教程树中讲述的银行家算法也比较清晰，可以一看. + +死锁的避免(银行家算法)改善解决了 **资源使用率低的问题** ，但是它要不断地检测每个进程对各类资源的占用和申请情况，以及做 **安全性检查** ，需要花费较多的时间。 + +#### 死锁的检测 + +对资源的分配加以限制可以 **预防和避免** 死锁的发生，但是都不利于各进程对系统资源的**充分共享**。解决死锁问题的另一条途径是 **死锁检测和解除** (这里突然联想到了乐观锁和悲观锁，感觉死锁的检测和解除就像是 **乐观锁** ，分配资源时不去提前管会不会发生死锁了，等到真的死锁出现了再来解决嘛，而 **死锁的预防和避免** 更像是悲观锁，总是觉得死锁会出现，所以在分配资源的时候就很谨慎)。 + +这种方法对资源的分配不加以任何限制，也不采取死锁避免措施，但系统 **定时地运行一个 “死锁检测”** 的程序，判断系统内是否出现死锁，如果检测到系统发生了死锁，再采取措施去解除它。 + +##### 进程-资源分配图 + +操作系统中的每一刻时刻的**系统状态**都可以用**进程-资源分配图**来表示，进程-资源分配图是描述进程和资源申请及分配关系的一种有向图，可用于**检测系统是否处于死锁状态**。 + +用一个方框表示每一个资源类，方框中的黑点表示该资源类中的各个资源，每个键进程用一个圆圈表示，用 **有向边** 来表示**进程申请资源和资源被分配的情况**。 + +图中 2-21 是**进程-资源分配图**的一个例子，其中共有三个资源类，每个进程的资源占有和申请情况已清楚地表示在图中。在这个例子中，由于存在 **占有和等待资源的环路** ，导致一组进程永远处于等待资源的状态，发生了 **死锁**。 + +![进程-资源分配图](./images/进程-资源分配图.jpg) + +进程-资源分配图中存在环路并不一定是发生了死锁。因为循环等待资源仅仅是死锁发生的必要条件，而不是充分条件。图 2-22 便是一个有环路而无死锁的例子。虽然进程 P1 和进程 P3 分别占用了一个资源 R1 和一个资源 R2，并且因为等待另一个资源 R2 和另一个资源 R1 形成了环路，但进程 P2 和进程 P4 分别占有了一个资源 R1 和一个资源 R2，它们申请的资源得到了满足，在有限的时间里会归还资源，于是进程 P1 或 P3 都能获得另一个所需的资源，环路自动解除，系统也就不存在死锁状态了。 + +##### 死锁检测步骤 + +知道了死锁检测的原理，我们可以利用下列步骤编写一个 **死锁检测** 程序，检测系统是否产生了死锁。 + +1. 如果进程-资源分配图中无环路，则此时系统没有发生死锁 +2. 如果进程-资源分配图中有环路，且每个资源类仅有一个资源，则系统中已经发生了死锁。 +3. 如果进程-资源分配图中有环路，且涉及到的资源类有多个资源，此时系统未必会发生死锁。如果能在进程-资源分配图中找出一个 **既不阻塞又非独立的进程** ，该进程能够在有限的时间内归还占有的资源，也就是把边给消除掉了，重复此过程，直到能在有限的时间内 **消除所有的边** ，则不会发生死锁，否则会发生死锁。(消除边的过程类似于 **拓扑排序**) + +#### 死锁的解除 + +当死锁检测程序检测到存在死锁发生时，应设法让其解除，让系统从死锁状态中恢复过来，常用的解除死锁的方法有以下四种： + +1. **立即结束所有进程的执行，重新启动操作系统** ：这种方法简单，但以前所在的工作全部作废，损失很大。 +2. **撤销涉及死锁的所有进程，解除死锁后继续运行** ：这种方法能彻底打破**死锁的循环等待**条件，但将付出很大代价，例如有些进程可能已经计算了很长时间，由于被撤销而使产生的部分结果也被消除了，再重新执行时还要再次进行计算。 +3. **逐个撤销涉及死锁的进程，回收其资源直至死锁解除。** +4. **抢占资源** ：从涉及死锁的一个或几个进程中抢占资源，把夺得的资源再分配给涉及死锁的进程直至死锁解除。 + +## 三 操作系统内存管理基础 + +### 3.1 内存管理介绍 + +👨‍💻 **面试官**: **操作系统的内存管理主要是做什么？** + +🙋 **我：** 操作系统的内存管理主要负责内存的分配与回收（malloc 函数：申请内存，free 函数：释放内存），另外地址转换也就是将逻辑地址转换成相应的物理地址等功能也是操作系统内存管理做的事情。 + +### 3.2 常见的几种内存管理机制 + +👨‍💻 **面试官**: **操作系统的内存管理机制了解吗？内存管理有哪几种方式?** + +🙋 **我：** 这个在学习操作系统的时候有了解过。 + +简单分为**连续分配管理方式**和**非连续分配管理方式**这两种。连续分配管理方式是指为一个用户程序分配一个连续的内存空间，常见的如 **块式管理** 。同样地，非连续分配管理方式允许一个程序使用的内存分布在离散或者说不相邻的内存中，常见的如**页式管理** 和 **段式管理**。 + +1. **块式管理** ： 远古时代的计算机操系统的内存管理方式。将内存分为几个固定大小的块，每个块中只包含一个进程。如果程序运行需要内存的话，操作系统就分配给它一块，如果程序运行只需要很小的空间的话，分配的这块内存很大一部分几乎被浪费了。这些在每个块中未被利用的空间，我们称之为碎片。 +2. **页式管理** ：把主存分为大小相等且固定的一页一页的形式，页较小，相对相比于块式管理的划分力度更大，提高了内存利用率，减少了碎片。页式管理通过页表对应逻辑地址和物理地址。 +3. **段式管理** ： 页式管理虽然提高了内存利用率，但是页式管理其中的页实际并无任何实际意义。 段式管理把主存分为一段段的，段是有实际意义的，每个段定义了一组逻辑信息，例如,有主程序段 MAIN、子程序段 X、数据段 D 及栈段 S 等。 段式管理通过段表对应逻辑地址和物理地址。 + +简单来说：页是物理单位，段是逻辑单位。分页可以有效提高内存利用率，分段可以更好满足用户需求。 + +👨‍💻**面试官** ： 回答的还不错！不过漏掉了一个很重要的 **段页式管理机制** 。段页式管理机制结合了段式管理和页式管理的优点。简单来说段页式管理机制就是把主存先分成若干段，每个段又分成若干页，也就是说 **段页式管理机制** 中段与段之间以及段的内部的都是离散的。 + +🙋 **我** ：谢谢面试官！刚刚把这个给忘记了～ + +### 3.3 快表和多级页表 + +👨‍💻**面试官** ： 页表管理机制中有两个很重要的概念：快表和多级页表，这两个东西分别解决了页表管理中很重要的两个问题。你给我简单介绍一下吧！ + +🙋 **我** ：在分页内存管理中，很重要的两点是： + +1. 虚拟地址到物理地址的转换要快。 +2. 解决虚拟地址空间大，页表也会很大的问题。 + +#### 快表 + +为了解决虚拟地址到物理地址的转换速度，操作系统在 **页表方案** 基础之上引入了 **快表** 来加速虚拟地址到物理地址的转换。我们可以把快表理解为一种特殊的高速缓冲存储器（Cache），其中的内容是页表的一部分或者全部内容。作为页表的 Cache，它的作用与页表相似，但是提高了访问速率。由于采用页表做地址转换，读写内存数据时 CPU 要访问两次主存。有了快表，有时只要访问一次高速缓冲存储器，一次主存，这样可加速查找并提高指令执行速度。 + +使用快表之后的地址转换流程是这样的： + +1. 根据虚拟地址中的页号查快表； +2. 如果该页在快表中，直接从快表中读取相应的物理地址； +3. 如果该页不在快表中，就访问内存中的页表，再从页表中得到物理地址，同时将页表中的该映射表项添加到快表中； +4. 当快表填满后，又要登记新页时，就按照一定的淘汰策略淘汰掉快表中的一个页。 + +看完了之后你会发现快表和我们平时经常在我们开发的系统使用的缓存（比如 Redis）很像，的确是这样的，操作系统中的很多思想、很多经典的算法，你都可以在我们日常开发使用的各种工具或者框架中找到它们的影子。 + +#### 多级页表 + +引入多级页表的主要目的是为了避免把全部页表一直放在内存中占用过多空间，特别是那些根本就不需要的页表就不需要保留在内存中。多级页表属于时间换空间的典型场景，具体可以查看下面这篇文章 + +- 多级页表如何节约内存：[https://www.polarxiong.com/archives/多级页表如何节约内存.html](https://www.polarxiong.com/archives/多级页表如何节约内存.html) + +#### 总结 + +为了提高内存的空间性能，提出了多级页表的概念；但是提到空间性能是以浪费时间性能为基础的，因此为了补充损失的时间性能，提出了快表（即 TLB）的概念。 不论是快表还是多级页表实际上都利用到了程序的局部性原理，局部性原理在后面的虚拟内存这部分会介绍到。 + +### 3.4 分页机制和分段机制的共同点和区别 + +👨‍💻**面试官** ： **分页机制和分段机制有哪些共同点和区别呢？** + +🙋 **我** ： + +1. **共同点** ： + - 分页机制和分段机制都是为了提高内存利用率，减少内存碎片。 + - 页和段都是离散存储的，所以两者都是离散分配内存的方式。但是，每个页和段中的内存是连续的。 +2. **区别** ： + - 页的大小是固定的，由操作系统决定；而段的大小不固定，取决于我们当前运行的程序。 + - 分页仅仅是为了满足操作系统内存管理的需求，而段是逻辑信息的单位，在程序中可以体现为代码段，数据段，能够更好满足用户的需要。 + +### 3.5 逻辑(虚拟)地址和物理地址 + +👨‍💻**面试官** ：你刚刚还提到了**逻辑地址和物理地址**这两个概念，我不太清楚，你能为我解释一下不？ + +🙋 **我：** em...好的嘛！我们编程一般只有可能和逻辑地址打交道，比如在 C 语言中，指针里面存储的数值就可以理解成为内存里的一个地址，这个地址也就是我们说的逻辑地址，逻辑地址由操作系统决定。物理地址指的是真实物理内存中地址，更具体一点来说就是内存地址寄存器中的地址。物理地址是内存单元真正的地址。 + +### 3.6 CPU 寻址了解吗?为什么需要虚拟地址空间? + +👨‍💻**面试官** ：**CPU 寻址了解吗?为什么需要虚拟地址空间?** + +🙋 **我** ：这部分我真不清楚！ + +于是面试完之后我默默去查阅了相关文档！留下了没有技术的泪水。。。 + +> 这部分内容参考了 Microsoft 官网的介绍，地址： + +现代处理器使用的是一种称为 **虚拟寻址(Virtual Addressing)** 的寻址方式。**使用虚拟寻址，CPU 需要将虚拟地址翻译成物理地址，这样才能访问到真实的物理内存。** 实际上完成虚拟地址转换为物理地址转换的硬件是 CPU 中含有一个被称为 **内存管理单元（Memory Management Unit, MMU）** 的硬件。如下图所示： + +![MMU_principle_updated](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/2019-11/2b27dac8cc647f8aac989da2d1166db2.png) + +**为什么要有虚拟地址空间呢？** + +先从没有虚拟地址空间的时候说起吧！没有虚拟地址空间的时候，**程序都是直接访问和操作的都是物理内存** 。但是这样有什么问题呢？ + +1. 用户程序可以访问任意内存，寻址内存的每个字节，这样就很容易（有意或者无意）破坏操作系统，造成操作系统崩溃。 +2. 想要同时运行多个程序特别困难，比如你想同时运行一个微信和一个 QQ 音乐都不行。为什么呢？举个简单的例子：微信在运行的时候给内存地址 1xxx 赋值后，QQ 音乐也同样给内存地址 1xxx 赋值，那么 QQ 音乐对内存的赋值就会覆盖微信之前所赋的值，这就造成了微信这个程序就会崩溃。 + +**总结来说：如果直接把物理地址暴露出来的话会带来严重问题，比如可能对操作系统造成伤害以及给同时运行多个程序造成困难。** + +通过虚拟地址访问内存有以下优势： + +- 程序可以使用一系列相邻的虚拟地址来访问物理内存中不相邻的大内存缓冲区。 +- 程序可以使用一系列虚拟地址来访问大于可用物理内存的内存缓冲区。当物理内存的供应量变小时，内存管理器会将物理内存页（通常大小为 4 KB）保存到磁盘文件。数据或代码页会根据需要在物理内存与磁盘之间移动。 +- 不同进程使用的虚拟地址彼此隔离。一个进程中的代码无法更改正在由另一进程或操作系统使用的物理内存。 + +## 四 虚拟内存 + +### 4.1 什么是虚拟内存(Virtual Memory)? + +👨‍💻**面试官** ：再问你一个常识性的问题！**什么是虚拟内存(Virtual Memory)?** + +🙋 **我** ：这个在我们平时使用电脑特别是 Windows 系统的时候太常见了。很多时候我们使用点开了很多占内存的软件，这些软件占用的内存可能已经远远超出了我们电脑本身具有的物理内存。**为什么可以这样呢？** 正是因为 **虚拟内存** 的存在，通过 **虚拟内存** 可以让程序可以拥有超过系统物理内存大小的可用内存空间。另外，**虚拟内存为每个进程提供了一个一致的、私有的地址空间，它让每个进程产生了一种自己在独享主存的错觉（每个进程拥有一片连续完整的内存空间）**。这样会更加有效地管理内存并减少出错。 + +**虚拟内存**是计算机系统内存管理的一种技术，我们可以手动设置自己电脑的虚拟内存。不要单纯认为虚拟内存只是“使用硬盘空间来扩展内存“的技术。**虚拟内存的重要意义是它定义了一个连续的虚拟地址空间**，并且 **把内存扩展到硬盘空间**。推荐阅读：[《虚拟内存的那点事儿》](https://juejin.im/post/59f8691b51882534af254317) + +维基百科中有几句话是这样介绍虚拟内存的。 + +> **虚拟内存** 使得应用程序认为它拥有连续的可用的内存（一个连续完整的地址空间），而实际上，它通常是被分隔成多个物理内存碎片，还有部分暂时存储在外部磁盘存储器上，在需要时进行数据交换。与没有使用虚拟内存技术的系统相比，使用这种技术的系统使得大型程序的编写变得更容易，对真正的物理内存（例如 RAM）的使用也更有效率。目前，大多数操作系统都使用了虚拟内存，如 Windows 家族的“虚拟内存”；Linux 的“交换空间”等。From: + +### 4.2 局部性原理 + +👨‍💻**面试官** ：要想更好地理解虚拟内存技术，必须要知道计算机中著名的**局部性原理**。另外，局部性原理既适用于程序结构，也适用于数据结构，是非常重要的一个概念。 + +🙋 **我** ：局部性原理是虚拟内存技术的基础，正是因为程序运行具有局部性原理，才可以只装入部分程序到内存就开始运行。 + +> 以下内容摘自《计算机操作系统教程》 第 4 章存储器管理。 + +早在 1968 年的时候，就有人指出我们的程序在执行的时候往往呈现局部性规律，也就是说在某个较短的时间段内，程序执行局限于某一小部分，程序访问的存储空间也局限于某个区域。 + +局部性原理表现在以下两个方面： + +1. **时间局部性** ：如果程序中的某条指令一旦执行，不久以后该指令可能再次执行；如果某数据被访问过，不久以后该数据可能再次被访问。产生时间局部性的典型原因，是由于在程序中存在着大量的循环操作。 +2. **空间局部性** ：一旦程序访问了某个存储单元，在不久之后，其附近的存储单元也将被访问，即程序在一段时间内所访问的地址，可能集中在一定的范围之内，这是因为指令通常是顺序存放、顺序执行的，数据也一般是以向量、数组、表等形式簇聚存储的。 + +时间局部性是通过将近来使用的指令和数据保存到高速缓存存储器中，并使用高速缓存的层次结构实现。空间局部性通常是使用较大的高速缓存，并将预取机制集成到高速缓存控制逻辑中实现。虚拟内存技术实际上就是建立了 “内存一外存”的两级存储器的结构，利用局部性原理实现髙速缓存。 + +### 4.3 虚拟存储器 + +> **勘误：虚拟存储器又叫做虚拟内存，都是 Virtual Memory 的翻译，属于同一个概念。** + +👨‍💻**面试官** ：~~都说了虚拟内存了。你再讲讲**虚拟存储器**把！~~ + +🙋 **我** ： + +> 这部分内容来自：[王道考研操作系统知识点整理](https://wizardforcel.gitbooks.io/wangdaokaoyan-os/content/13.html)。 + +基于局部性原理，在程序装入时，可以将程序的一部分装入内存，而将其他部分留在外存，就可以启动程序执行。由于外存往往比内存大很多，所以我们运行的软件的内存大小实际上是可以比计算机系统实际的内存大小大的。在程序执行过程中，当所访问的信息不在内存时，由操作系统将所需要的部分调入内存，然后继续执行程序。另一方面，操作系统将内存中暂时不使用的内容换到外存上，从而腾出空间存放将要调入内存的信息。这样，计算机好像为用户提供了一个比实际内存大的多的存储器——**虚拟存储器**。 + +实际上，我觉得虚拟内存同样是一种时间换空间的策略，你用 CPU 的计算时间，页的调入调出花费的时间，换来了一个虚拟的更大的空间来支持程序的运行。不得不感叹，程序世界几乎不是时间换空间就是空间换时间。 + +### 4.4 虚拟内存的技术实现 + +👨‍💻**面试官** ：**虚拟内存技术的实现呢？** + +🙋 **我** ：**虚拟内存的实现需要建立在离散分配的内存管理方式的基础上。** 虚拟内存的实现有以下三种方式： + +1. **请求分页存储管理** ：建立在分页管理之上，为了支持虚拟存储器功能而增加了请求调页功能和页面置换功能。请求分页是目前最常用的一种实现虚拟存储器的方法。请求分页存储管理系统中，在作业开始运行之前，仅装入当前要执行的部分段即可运行。假如在作业运行的过程中发现要访问的页面不在内存，则由处理器通知操作系统按照对应的页面置换算法将相应的页面调入到主存，同时操作系统也可以将暂时不用的页面置换到外存中。 +2. **请求分段存储管理** ：建立在分段存储管理之上，增加了请求调段功能、分段置换功能。请求分段储存管理方式就如同请求分页储存管理方式一样，在作业开始运行之前，仅装入当前要执行的部分段即可运行；在执行过程中，可使用请求调入中断动态装入要访问但又不在内存的程序段；当内存空间已满，而又需要装入新的段时，根据置换功能适当调出某个段，以便腾出空间而装入新的段。 +3. **请求段页式存储管理** + +**这里多说一下？很多人容易搞混请求分页与分页存储管理，两者有何不同呢？** + +请求分页存储管理建立在分页管理之上。他们的根本区别是是否将程序全部所需的全部地址空间都装入主存，这也是请求分页存储管理可以提供虚拟内存的原因，我们在上面已经分析过了。 + +它们之间的根本区别在于是否将一作业的全部地址空间同时装入主存。请求分页存储管理不要求将作业全部地址空间同时装入主存。基于这一点，请求分页存储管理可以提供虚存，而分页存储管理却不能提供虚存。 + +不管是上面那种实现方式，我们一般都需要： + +1. 一定容量的内存和外存：在载入程序的时候，只需要将程序的一部分装入内存，而将其他部分留在外存，然后程序就可以执行了； +2. **缺页中断**：如果**需执行的指令或访问的数据尚未在内存**（称为缺页或缺段），则由处理器通知操作系统将相应的页面或段**调入到内存**，然后继续执行程序； +3. **虚拟地址空间** ：逻辑地址到物理地址的变换。 + +### 4.5 页面置换算法 + +👨‍💻**面试官** ：虚拟内存管理很重要的一个概念就是页面置换算法。那你说一下 **页面置换算法的作用?常见的页面置换算法有哪些?** + +🙋 **我** ： + +> 这个题目经常作为笔试题出现，网上已经给出了很不错的回答，我这里只是总结整理了一下。 + +地址映射过程中，若在页面中发现所要访问的页面不在内存中，则发生缺页中断 。 + +> **缺页中断** 就是要访问的**页**不在主存，需要操作系统将其调入主存后再进行访问。 在这个时候，被内存映射的文件实际上成了一个分页交换文件。 + +当发生缺页中断时，如果当前内存中并没有空闲的页面，操作系统就必须在内存选择一个页面将其移出内存，以便为即将调入的页面让出空间。用来选择淘汰哪一页的规则叫做页面置换算法，我们可以把页面置换算法看成是淘汰页面的规则。 + +- **OPT 页面置换算法（最佳页面置换算法）** ：最佳(Optimal, OPT)置换算法所选择的被淘汰页面将是以后永不使用的，或者是在最长时间内不再被访问的页面,这样可以保证获得最低的缺页率。但由于人们目前无法预知进程在内存下的若千页面中哪个是未来最长时间内不再被访问的，因而该算法无法实现。一般作为衡量其他置换算法的方法。 +- **FIFO（First In First Out） 页面置换算法（先进先出页面置换算法）** : 总是淘汰最先进入内存的页面，即选择在内存中驻留时间最久的页面进行淘汰。 +- **LRU （Least Recently Used）页面置换算法（最近最久未使用页面置换算法）** ：LRU 算法赋予每个页面一个访问字段，用来记录一个页面自上次被访问以来所经历的时间 T，当须淘汰一个页面时，选择现有页面中其 T 值最大的，即最近最久未使用的页面予以淘汰。 +- **LFU （Least Frequently Used）页面置换算法（最少使用页面置换算法）** : 该置换算法选择在之前时期使用最少的页面作为淘汰页。 + +## Reference + +- 《计算机操作系统—汤小丹》第四版 +- [《深入理解计算机系统》](https://book.douban.com/subject/1230413/) +- [https://zh.wikipedia.org/wiki/输入输出内存管理单元](https://zh.wikipedia.org/wiki/输入输出内存管理单元) +- [https://baike.baidu.com/item/快表/19781679](https://baike.baidu.com/item/快表/19781679) +- https://www.jianshu.com/p/1d47ed0b46d5 +- +- +- +- 王道考研操作系统知识点整理： https://wizardforcel.gitbooks.io/wangdaokaoyan-os/content/13.html diff --git "a/\346\223\215\344\275\234\347\263\273\347\273\237/Shell.md" b/docs/cs-basics/operating-system/shell-intro.md similarity index 73% rename from "\346\223\215\344\275\234\347\263\273\347\273\237/Shell.md" rename to docs/cs-basics/operating-system/shell-intro.md index 4179f2702bb7dbedc9abd391d71754bdbf0a6645..074f7bfbe556608afc9cab76083151f7f14253b7 100644 --- "a/\346\223\215\344\275\234\347\263\273\347\273\237/Shell.md" +++ b/docs/cs-basics/operating-system/shell-intro.md @@ -1,33 +1,10 @@ - - - -- [Shell 编程入门](#shell-编程入门) - - [走进 Shell 编程的大门](#走进-shell-编程的大门) - - [为什么要学Shell？](#为什么要学shell) - - [什么是 Shell？](#什么是-shell) - - [Shell 编程的 Hello World](#shell-编程的-hello-world) - - [Shell 变量](#shell-变量) - - [Shell 编程中的变量介绍](#shell-编程中的变量介绍) - - [Shell 字符串入门](#shell-字符串入门) - - [Shell 字符串常见操作](#shell-字符串常见操作) - - [Shell 数组](#shell-数组) - - [Shell 基本运算符](#shell-基本运算符) - - [算数运算符](#算数运算符) - - [关系运算符](#关系运算符) - - [逻辑运算符](#逻辑运算符) - - [布尔运算符](#布尔运算符) - - [字符串运算符](#字符串运算符) - - [文件相关运算符](#文件相关运算符) - - [shell流程控制](#shell流程控制) - - [if 条件语句](#if-条件语句) - - [for 循环语句](#for-循环语句) - - [while 语句](#while-语句) - - [shell 函数](#shell-函数) - - [不带参数没有返回值的函数](#不带参数没有返回值的函数) - - [有返回值的函数](#有返回值的函数) - - [带参数的函数](#带参数的函数) - - +--- +title: Shell 编程入门 +category: 计算机基础 +tag: + - 操作系统 + - Linux +--- # Shell 编程入门 @@ -45,20 +22,19 @@ 另外，了解 shell 编程也是大部分互联网公司招聘后端开发人员的要求。下图是我截取的一些知名互联网公司对于 Shell 编程的要求。 -![大型互联网公司对于shell编程技能的要求](http://my-blog-to-use.oss-cn-beijing.aliyuncs.com/18-11-16/60190220.jpg) +![大型互联网公司对于shell编程技能的要求](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/18-11-16/60190220.jpg) ### 什么是 Shell？ 简单来说“Shell编程就是对一堆Linux命令的逻辑化处理”。 - W3Cschool 上的一篇文章是这样介绍 Shell的，如下图所示。 -![什么是 Shell？](http://my-blog-to-use.oss-cn-beijing.aliyuncs.com/18-11-26/19456505.jpg) +![什么是 Shell？](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/18-11-26/19456505.jpg) ### Shell 编程的 Hello World -学习任何一门编程语言第一件事就是输出HelloWord了！下面我会从新建文件到shell代码编写来说下Shell 编程如何输出Hello World。 +学习任何一门编程语言第一件事就是输出HelloWorld了！下面我会从新建文件到shell代码编写来说下Shell 编程如何输出Hello World。 (1)新建一个文件 helloworld.sh :`touch helloworld.sh`，扩展名为 sh（sh代表Shell）（扩展名并不影响脚本执行，见名知意就好，如果你用 php 写 shell 脚本，扩展名就用 php 好了） @@ -78,9 +54,9 @@ echo "helloworld!" shell中 # 符号表示注释。**shell 的第一行比较特殊，一般都会以#!开始来指定使用的 shell 类型。在linux中，除了bash shell以外，还有很多版本的shell， 例如zsh、dash等等...不过bash shell还是我们使用最多的。** -(4) 运行脚本:`./helloworld.sh` 。（注意，一定要写成 `./helloworld.sh` ，而不是 `helloworld.sh` ，运行其它二进制的程序也一样，直接写 `helloworld.sh` ，linux 系统会去 PATH 里寻找有没有叫 test.sh 的，而只有 /bin, /sbin, /usr/bin，/usr/sbin 等在 PATH 里，你的当前目录通常不在 PATH 里，所以写成 `helloworld.sh` 是会找不到命令的，要用`./helloworld.sh` 告诉系统说，就在当前目录找。） +(4) 运行脚本:`./helloworld.sh` 。（注意，一定要写成 `./helloworld.sh` ，而不是 `helloworld.sh` ，运行其它二进制的程序也一样，直接写 `helloworld.sh` ，linux 系统会去 PATH 里寻找有没有叫 helloworld.sh 的，而只有 /bin, /sbin, /usr/bin，/usr/sbin 等在 PATH 里，你的当前目录通常不在 PATH 里，所以写成 `helloworld.sh` 是会找不到命令的，要用`./helloworld.sh` 告诉系统说，就在当前目录找。） -![shell 编程Hello World](http://my-blog-to-use.oss-cn-beijing.aliyuncs.com/18-11-16/55296212.jpg) +![shell 编程Hello World](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/18-11-16/55296212.jpg) ## Shell 变量 @@ -91,18 +67,18 @@ shell中 # 符号表示注释。**shell 的第一行比较特殊，一般都会 **Shell编程中一般分为三种变量：** 1. **我们自己定义的变量（自定义变量）:** 仅在当前 Shell 实例中有效，其他 Shell 启动的程序不能访问局部变量。 -2. **Linux已定义的环境变量**（环境变量， 例如：$PATH, $HOME 等..., 这类变量我们可以直接使用），使用 `env` 命令可以查看所有的环境变量，而set命令既可以查看环境变量也可以查看自定义变量。 +2. **Linux已定义的环境变量**（环境变量， 例如：`PATH`, ​`HOME` 等..., 这类变量我们可以直接使用），使用 `env` 命令可以查看所有的环境变量，而set命令既可以查看环境变量也可以查看自定义变量。 3. **Shell变量** ：Shell变量是由 Shell 程序设置的特殊变量。Shell 变量中有一部分是环境变量，有一部分是局部变量，这些变量保证了 Shell 的正常运行 **常用的环境变量:** -> PATH 决定了shell将到哪些目录中寻找命令或程序 -HOME 当前用户主目录 -HISTSIZE　历史记录数 -LOGNAME 当前用户的登录名 -HOSTNAME　指主机的名称 -SHELL 当前用户Shell类型 -LANGUGE 　语言相关的环境变量，多语言可以修改此环境变量 -MAIL　当前用户的邮件存放目录 +> PATH 决定了shell将到哪些目录中寻找命令或程序 +HOME 当前用户主目录 +HISTSIZE　历史记录数 +LOGNAME 当前用户的登录名 +HOSTNAME　指主机的名称 +SHELL 当前用户Shell类型 +LANGUAGE 　语言相关的环境变量，多语言可以修改此环境变量 +MAIL　当前用户的邮件存放目录 PS1　基本提示符，对于root用户是#，对于普通用户是$ **使用 Linux 已定义的环境变量：** @@ -118,7 +94,7 @@ hello="hello world" echo $hello echo "helloworld!" ``` -![使用自己定义的变量](http://my-blog-to-use.oss-cn-beijing.aliyuncs.com/18-11-17/19835037.jpg) +![使用自己定义的变量](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/18-11-17/19835037.jpg) **Shell 编程中的变量名的命名的注意事项：** @@ -183,7 +159,7 @@ echo $greeting_2 $greeting_3 输出结果： -![输出结果](http://my-blog-to-use.oss-cn-beijing.aliyuncs.com/18-11-17/51148933.jpg) +![输出结果](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/18-11-17/51148933.jpg) **获取字符串长度：** @@ -210,7 +186,7 @@ expr length "$name"; expr 5+6 // 直接输出 5+6 expr 5 + 6 // 输出 11 ``` -对于某些运算符，还需要我们使用符号"\"进行转义，否则就会提示语法错误。 +对于某些运算符，还需要我们使用符号`\`进行转义，否则就会提示语法错误。 ```shell expr 5 * 6 // 输出错误 @@ -234,13 +210,17 @@ echo ${str:0:10} #输出:SnailClimb #!bin/bash #author:amau -var="http://www.runoob.com/linux/linux-shell-variable.html" - -s1=${var%%t*}#h -s2=${var%t*}#http://www.runoob.com/linux/linux-shell-variable.h -s3=${var%%.*}#http://www -s4=${var#*/}#/www.runoob.com/linux/linux-shell-variable.html -s5=${var##*/}#linux-shell-variable.html +var="https://www.runoob.com/linux/linux-shell-variable.html" +# %表示删除从后匹配, 最短结果 +# %%表示删除从后匹配, 最长匹配结果 +# #表示删除从头匹配, 最短结果 +# ##表示删除从头匹配, 最长匹配结果 +# 注: *为通配符, 意为匹配任意数量的任意字符 +s1=${var%%t*} #h +s2=${var%t*} #https://www.runoob.com/linux/linux-shell-variable.h +s3=${var%%.*} #http://www +s4=${var#*/} #/www.runoob.com/linux/linux-shell-variable.html +s5=${var##*/} #linux-shell-variable.html ``` ### Shell 数组 @@ -260,9 +240,9 @@ echo $length #输出：5 echo $length2 #输出：5 # 输出数组第三个元素 echo ${array[2]} #输出：3 -unset array[1]# 删除下表为1的元素也就是删除第二个元素 +unset array[1]# 删除下标为1的元素也就是删除第二个元素 for i in ${array[@]};do echo $i ;done # 遍历数组，输出： 1 3 4 5 -unset arr_number; # 删除数组中的所有元素 +unset array; # 删除数组中的所有元素 for i in ${array[@]};do echo $i ;done # 遍历数组，数组元素为空，没有任何输出内容 ``` @@ -272,7 +252,7 @@ for i in ${array[@]};do echo $i ;done # 遍历数组，数组元素为空，没 > 说明：图片来自《菜鸟教程》 Shell 编程支持下面几种运算符 - + - 算数运算符 - 关系运算符 - 布尔运算符 @@ -281,16 +261,16 @@ for i in ${array[@]};do echo $i ;done # 遍历数组，数组元素为空，没 ### 算数运算符 -![算数运算符](http://my-blog-to-use.oss-cn-beijing.aliyuncs.com/18-11-22/4937342.jpg) +![算数运算符](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/18-11-22/4937342.jpg) -我以加法运算符做一个简单的示例： +我以加法运算符做一个简单的示例（注意：不是单引号，是反引号）： ```shell #!/bin/bash a=3;b=3; val=`expr $a + $b` #输出：Total value : 6 -echo "Total value : $val +echo "Total value : $val" ``` @@ -298,7 +278,7 @@ echo "Total value : $val 关系运算符只支持数字，不支持字符串，除非字符串的值是数字。 -![shell关系运算符](http://my-blog-to-use.oss-cn-beijing.aliyuncs.com/18-11-22/64391380.jpg) +![shell关系运算符](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/18-11-22/64391380.jpg) 通过一个简单的示例演示关系运算符的使用，下面shell程序的作用是当score=100的时候输出A否则输出B。 @@ -322,7 +302,7 @@ B ### 逻辑运算符 -![逻辑运算符](http://my-blog-to-use.oss-cn-beijing.aliyuncs.com/18-11-22/60545848.jpg) +![逻辑运算符](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/18-11-22/60545848.jpg) 示例： @@ -336,18 +316,17 @@ echo $a; ### 布尔运算符 -![布尔运算符](http://my-blog-to-use.oss-cn-beijing.aliyuncs.com/18-11-22/93961425.jpg) +![布尔运算符](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/18-11-22/93961425.jpg) 这里就不做演示了，应该挺简单的。 ### 字符串运算符 -![ 字符串运算符](http://my-blog-to-use.oss-cn-beijing.aliyuncs.com/18-11-22/309094.jpg) +![ 字符串运算符](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/18-11-22/309094.jpg) 简单示例： ```shell - #!/bin/bash a="abc"; b="efg"; @@ -366,7 +345,7 @@ a 不等于 b ### 文件相关运算符 -![文件相关运算符](http://my-blog-to-use.oss-cn-beijing.aliyuncs.com/18-11-22/60359774.jpg) +![文件相关运算符](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/18-11-22/60359774.jpg) 使用方式很简单，比如我们定义好了一个文件路径`file="/usr/learnshell/test.sh"` 如果我们想判断这个文件是否可读，可以这样`if [ -r $file ]` 如果想判断这个文件是否可写，可以这样`-w $file`，是不是很简单。 @@ -380,10 +359,10 @@ a 不等于 b #!/bin/bash a=3; b=9; -if [ $a = $b ] +if [ $a -eq $b ] then echo "a 等于 b" -elif [ $a > $b ] +elif [ $a -gt $b ] then echo "a 大于 b" else @@ -394,7 +373,7 @@ fi 输出结果： ``` -a 大于 b +a 小于 b ``` 相信大家通过上面的示例就已经掌握了 shell 编程中的 if 条件语句。不过，还要提到的一点是，不同于我们常见的 Java 以及 PHP 中的 if 条件语句，shell if 条件语句中不能包含空语句也就是什么都不做的语句。 @@ -467,7 +446,7 @@ done 是的！变形金刚 是一个好电影 ``` -**无线循环：** +**无限循环：** ```shell while true @@ -482,16 +461,20 @@ done ```shell #!/bin/bash -function(){ +hello(){ echo "这是我的第一个 shell 函数!" } -function +echo "-----函数开始执行-----" +hello +echo "-----函数执行完毕-----" ``` 输出结果： ``` +-----函数开始执行----- 这是我的第一个 shell 函数! +-----函数执行完毕----- ``` @@ -526,8 +509,6 @@ echo "输入的两个数字之和为 $?" ### 带参数的函数 - - ```shell #!/bin/bash funWithParam(){ @@ -540,7 +521,6 @@ funWithParam(){ echo "作为一个字符串输出所有参数 $* !" } funWithParam 1 2 3 4 5 6 7 8 9 34 73 - ``` 输出结果： @@ -553,5 +533,4 @@ funWithParam 1 2 3 4 5 6 7 8 9 34 73 第十一个参数为 73 ! 参数总数有 11 个! 作为一个字符串输出所有参数 1 2 3 4 5 6 7 8 9 34 73 ! - ``` diff --git a/docs/database/Redis/images/redis-all/redis-list.drawio b/docs/database/Redis/images/redis-all/redis-list.drawio new file mode 100644 index 0000000000000000000000000000000000000000..afa767154b78e800813cbfe4c672ac94cbdcff60 --- /dev/null +++ b/docs/database/Redis/images/redis-all/redis-list.drawio @@ -0,0 +1 @@ +7VlNc5swFPw1PiaDENjmmNjpx6Gdjt1J2lNHAzKoEYgRcmzn11cYyRgJT1w3DnScU3grIaHd5b2HM4CTdP2Rozz5wiJMB64TrQdwOnBdEEAo/5TIpkICx6mAmJNITaqBOXnGCtTTliTCRWOiYIwKkjfBkGUZDkUDQ5yzVXPagtHmrjmKsQXMQ0Rt9IFEIqnQsTuq8U+YxIneGQyDaiRFerI6SZGgiK32IHg3gBPOmKiu0vUE05I8zUt134cDo7sH4zgTx9wwu/+V/H4g/myezsD35/vZ56/ulVrlCdGlOrB6WLHRDHC2zCJcLgIG8HaVEIHnOQrL0ZXUXGKJSKkaLh6xCBMVLFgmlKJgJGO1F+YCrw8eAuyokZ7CLMWCb+QUdcOVp9hUdnKhile1OL62WLInzEhhSPkh3i1dUyYvFGt/waBrMbi9BD3lUfPm2bwFLbT556INttPWc/sB035d0+i10wj7TaM77hmNw5fTIM6im7KeyCikqChI2ORMHp1vfsjA0cHPMrh2fR1P1/uj042KjiAbR1aRMqiWVRHxGIuXUr0tSSNxHqacY4oEeWo+RpsOaodvjMgHrPM2gKbk4+YaBVvyEKvb9suYuZLpHdcwRUWEtdDWF7tzn26V0f9ula4s4A0N4cbOtX+aB3zfWupNPaCb01cxAXjPF0cofGq68AJjIT8wXXdusxzRY/fbLJ0VDbPbOj1j2PXnrVOG/Z3A82WRWFaQXZUwujHB2SOeMMq4RDKW4VJLQqkBIUrirHSQVA9L/Lbs0Yj8lL1RAymJonKb1vavbhCP9M0/dYA+OFDF95zltTjLLPav1gECu5PmOcvf5aloD7qWx7fkoRf8+siiYggEuhbI/oSil/v+2Pp0/gLZ3y18u20/BTqDJp5O8VoSp2tJxvYrgxcXpIjV351PERnWv7RXPV39/wp49wc= \ No newline at end of file diff --git a/docs/database/Redis/images/redis-all/redis-list.png b/docs/database/Redis/images/redis-all/redis-list.png new file mode 100644 index 0000000000000000000000000000000000000000..31ce99333dbffe9b79b17a019922e2350ffa55d8 Binary files /dev/null and b/docs/database/Redis/images/redis-all/redis-list.png differ diff --git a/docs/database/Redis/images/redis-all/redis-rollBack.png b/docs/database/Redis/images/redis-all/redis-rollBack.png new file mode 100644 index 0000000000000000000000000000000000000000..e7c15dde70259ce15c0468418c5ccc36a410a4a7 Binary files /dev/null and b/docs/database/Redis/images/redis-all/redis-rollBack.png differ diff --git a/docs/database/Redis/images/redis-all/redis-vs-memcached.png b/docs/database/Redis/images/redis-all/redis-vs-memcached.png new file mode 100644 index 0000000000000000000000000000000000000000..8d52b6b71885fcadd36499b5845f8d32baf31dc5 Binary files /dev/null and b/docs/database/Redis/images/redis-all/redis-vs-memcached.png differ diff --git a/docs/database/Redis/images/redis-all/redis4.0-more-thread.png b/docs/database/Redis/images/redis-all/redis4.0-more-thread.png new file mode 100644 index 0000000000000000000000000000000000000000..dfcb638a4b6c2996086c69a025cc8b3845be08c4 Binary files /dev/null and b/docs/database/Redis/images/redis-all/redis4.0-more-thread.png differ diff --git "a/docs/database/Redis/images/redis-all/redis\344\272\213\344\273\266\345\244\204\347\220\206\345\231\250.png" "b/docs/database/Redis/images/redis-all/redis\344\272\213\344\273\266\345\244\204\347\220\206\345\231\250.png" new file mode 100644 index 0000000000000000000000000000000000000000..3b3c276af72c12e01e23cd8e33f0c6c0f6726696 Binary files /dev/null and "b/docs/database/Redis/images/redis-all/redis\344\272\213\344\273\266\345\244\204\347\220\206\345\231\250.png" differ diff --git "a/docs/database/Redis/images/redis-all/redis\344\272\213\345\212\241.png" "b/docs/database/Redis/images/redis-all/redis\344\272\213\345\212\241.png" new file mode 100644 index 0000000000000000000000000000000000000000..adba0c12049c27f60d56650168c6b0d18d702dde Binary files /dev/null and "b/docs/database/Redis/images/redis-all/redis\344\272\213\345\212\241.png" differ diff --git "a/docs/database/Redis/images/redis-all/redis\350\277\207\346\234\237\346\227\266\351\227\264.png" "b/docs/database/Redis/images/redis-all/redis\350\277\207\346\234\237\346\227\266\351\227\264.png" new file mode 100644 index 0000000000000000000000000000000000000000..aa6dcabd64da1920ede525a1ad4a23569f6770bf Binary files /dev/null and "b/docs/database/Redis/images/redis-all/redis\350\277\207\346\234\237\346\227\266\351\227\264.png" differ diff --git a/docs/database/Redis/images/redis-all/try-redis.png b/docs/database/Redis/images/redis-all/try-redis.png new file mode 100644 index 0000000000000000000000000000000000000000..a86d44ef266808f58bb030e173e5a6381f71c683 Binary files /dev/null and b/docs/database/Redis/images/redis-all/try-redis.png differ diff --git a/docs/database/Redis/images/redis-all/what-is-redis.png b/docs/database/Redis/images/redis-all/what-is-redis.png new file mode 100644 index 0000000000000000000000000000000000000000..204f71bd0a147903e89b8c0c17d2ad59e11d9fa4 Binary files /dev/null and b/docs/database/Redis/images/redis-all/what-is-redis.png differ diff --git "a/docs/database/Redis/images/redis-all/\344\275\277\347\224\250\347\274\223\345\255\230\344\271\213\345\220\216.png" "b/docs/database/Redis/images/redis-all/\344\275\277\347\224\250\347\274\223\345\255\230\344\271\213\345\220\216.png" new file mode 100644 index 0000000000000000000000000000000000000000..b49d157c0a2384118aee389539cc6bac74d89bac Binary files /dev/null and "b/docs/database/Redis/images/redis-all/\344\275\277\347\224\250\347\274\223\345\255\230\344\271\213\345\220\216.png" differ diff --git "a/docs/database/Redis/images/redis-all/\345\212\240\345\205\245\345\270\203\351\232\206\350\277\207\346\273\244\345\231\250\345\220\216\347\232\204\347\274\223\345\255\230\345\244\204\347\220\206\346\265\201\347\250\213.png" "b/docs/database/Redis/images/redis-all/\345\212\240\345\205\245\345\270\203\351\232\206\350\277\207\346\273\244\345\231\250\345\220\216\347\232\204\347\274\223\345\255\230\345\244\204\347\220\206\346\265\201\347\250\213.png" new file mode 100644 index 0000000000000000000000000000000000000000..dad4a5d811f1e7320464e1763f4a6dffc60c8402 Binary files /dev/null and "b/docs/database/Redis/images/redis-all/\345\212\240\345\205\245\345\270\203\351\232\206\350\277\207\346\273\244\345\231\250\345\220\216\347\232\204\347\274\223\345\255\230\345\244\204\347\220\206\346\265\201\347\250\213.png" differ diff --git "a/docs/database/Redis/images/redis-all/\345\215\225\344\275\223\346\236\266\346\236\204.png" "b/docs/database/Redis/images/redis-all/\345\215\225\344\275\223\346\236\266\346\236\204.png" new file mode 100644 index 0000000000000000000000000000000000000000..958607d9968705cf6354cc0afe8b1cb021e0e806 Binary files /dev/null and "b/docs/database/Redis/images/redis-all/\345\215\225\344\275\223\346\236\266\346\236\204.png" differ diff --git "a/docs/database/Redis/images/redis-all/\347\274\223\345\255\230\347\232\204\345\244\204\347\220\206\346\265\201\347\250\213.png" "b/docs/database/Redis/images/redis-all/\347\274\223\345\255\230\347\232\204\345\244\204\347\220\206\346\265\201\347\250\213.png" new file mode 100644 index 0000000000000000000000000000000000000000..0d48d49a027d448686e2aa43c4f7908818695f9c Binary files /dev/null and "b/docs/database/Redis/images/redis-all/\347\274\223\345\255\230\347\232\204\345\244\204\347\220\206\346\265\201\347\250\213.png" differ diff --git "a/docs/database/Redis/images/redis-all/\351\233\206\344\270\255\345\274\217\347\274\223\345\255\230\346\236\266\346\236\204.png" "b/docs/database/Redis/images/redis-all/\351\233\206\344\270\255\345\274\217\347\274\223\345\255\230\346\236\266\346\236\204.png" new file mode 100644 index 0000000000000000000000000000000000000000..832ea8fb6e371745ef70aa420f10e6d7f32dac93 Binary files /dev/null and "b/docs/database/Redis/images/redis-all/\351\233\206\344\270\255\345\274\217\347\274\223\345\255\230\346\236\266\346\236\204.png" differ diff --git "a/docs/database/Redis/images/\347\274\223\345\255\230\350\257\273\345\206\231\347\255\226\347\225\245/cache-aside-read.drawio" "b/docs/database/Redis/images/\347\274\223\345\255\230\350\257\273\345\206\231\347\255\226\347\225\245/cache-aside-read.drawio" new file mode 100644 index 0000000000000000000000000000000000000000..bc4c6d0cca713d2e0db2aaac480477ec795407d3 --- /dev/null +++ "b/docs/database/Redis/images/\347\274\223\345\255\230\350\257\273\345\206\231\347\255\226\347\225\245/cache-aside-read.drawio" @@ -0,0 +1 @@ +7Vpbc+o2EP41ekzHl/j2iAmk02nmdA6dpn3qCFsYTWSLY0Qg/fWVbMnYluE4B4jTQh4Se6WVVt+32pU2BvY43T3mcLV8ojEiwDLiHbAfgGWZluPzP0LyVkoCwygFSY5j2WkvmOF/kBSqbhsco3WjI6OUMLxqCiOaZShiDRnMc7ptdltQ0px1BROkCWYRJLr0GcdsWUp9y9vLf0Y4WaqZTTcoW1KoOsuVrJcwptuayJ4Ae5xTysqndDdGRICncCn1pgdaK8NylLE+Ck/Pf/xthHPraf7NePliLeLZ1+c7OcorJBu5YGkse1MI5HSTxUgMYgI73C4xQ7MVjETrlnPOZUuWEtm8wISMKaF5oWsvFgsrirh8zXL6gmotsTt3HVe0KFiEekRTzLs/GPw5IXC9ls/SSpQztDu4fLMClXsjoili+RvvIhVs5VHSEX3fKd+3e1pNxdWyRqkrZVB6UlINvQebP0i834G9db3YW0Njb2vYx5BBDX++ZNYEuQlmRjN0BHlIcJJxWcRxQrwxFChiHlxGsiHFcSzm6qR2T75RTaxiUME3zZgMmFbQIq1O5jkIvG8RqN5rBLod/NmX4u9e4y8TVN3468dflYWH4s+5mtjnGJ8t77jXi/3gece75Z13EWi3845OYFfcUjyfnT//lndO4W/wvBNcTexzg8+Wd9Ql4BrBHzzxmPpN/5Z5jjDoWZ/sxmPq5YJb6nkHgYOnHlOvOfxfw5/vf7rcoxcMrgb84XOPftu/5Z4jDAbtcunguUcvGdxyzzsIHD736HUHjTyUxSPxDzNBgIBGANKIeC38mgjbXIJ2mP0pe4vnvwSiPzny7WEnAS5e3hpoo1j7L1wLa24q3eQROrbIbk5qmDsdmCtZjghk+LVpRhcRcobfKOYGHiw1BSrjqCFK86XWns4eA7VqGQzmCWLaQIVfVMs+wVX0Esd/zFWGcgG/vevbzPV1gXYG/3AX6FElublAF3Nu+9Lxo1GgXUDQBrqwC6h1NFzAJUV2t/bK7reN+HwhBJN7EPrAD8DEAf4U+GPxwNcQmGASgMAG4QRMfDAywcivqdVdSgmF59ytC9cZ8Q62vdrVNdyknJDP8wACp3N4UnadClNlfymM8esJk8pB5vnpY3DrCluU9PSTlBSd9RBVv7IcOi/Vdrptn+f8ZPt+w/s9Vz8/OeZHHqAsvXz2PZcSFN5JNoQ/ELRgh/1hvYJZH68yne7twPcf3w5jsQt49uD37ckUhGMQjGYZxGRMcDrnnWEqSM7m61XTFcvZj3toKRXmnGDnBTCrBQQHjMYFFHzhngxFoVetu/z9iNlyM6/w+QW+wkfxkdkPwcGlJSK99/HF92e9vNDOxEKJ8hExEzsrEK8EzhEJYfSSFGO3AwxXrl3VjOKn0qJ5jPIOjSlMMREzPMIcpjSLlRkSGENS/aUyxTNKPiOcJb/TlTwiSMGvwgsakpAyRtOm7KsMA2eKQZ6qWakM7OhlFKsrBt1fLAbpFeDbsazXscw0vnep6nsuMw1v2LO5pVeRs41Q+9jAM2R1RefgcuUV/rr/QrfkcP+dsz35Fw== \ No newline at end of file diff --git "a/docs/database/Redis/images/\347\274\223\345\255\230\350\257\273\345\206\231\347\255\226\347\225\245/cache-aside-read.png" "b/docs/database/Redis/images/\347\274\223\345\255\230\350\257\273\345\206\231\347\255\226\347\225\245/cache-aside-read.png" new file mode 100644 index 0000000000000000000000000000000000000000..5a687c746b93be790dbc3729b3b1b3bca5001a61 Binary files /dev/null and "b/docs/database/Redis/images/\347\274\223\345\255\230\350\257\273\345\206\231\347\255\226\347\225\245/cache-aside-read.png" differ diff --git "a/docs/database/Redis/images/\347\274\223\345\255\230\350\257\273\345\206\231\347\255\226\347\225\245/cache-aside-write.drawio" "b/docs/database/Redis/images/\347\274\223\345\255\230\350\257\273\345\206\231\347\255\226\347\225\245/cache-aside-write.drawio" new file mode 100644 index 0000000000000000000000000000000000000000..6fddf10f064eb3ecd2446ba3c5663e373533521d --- /dev/null +++ "b/docs/database/Redis/images/\347\274\223\345\255\230\350\257\273\345\206\231\347\255\226\347\225\245/cache-aside-write.drawio" @@ -0,0 +1 @@ +7LzXsuTYkSX6NWl254FtAAIqHqG11ngZgwporfH1A5zMLFaRySZ5L7unZ26fqjwHsYGt3Zcv9+2Iby+qPbgpGgqlT7PmGwSkx7cX/Q2CwPfrdf95Ss7vJW8A+F6QT2X646E/F1jllf0o/PnYWqbZ/IcHl75vlnL4Y2HSd12WLH8oi6ap3//42Kdv/tjrEOXZXxVYSdT8dalXpkvxvRSHsD+X81mZFz97BtH39ztt9PPhHzOZiyjt998VvZhvL2rq++X7VXtQWfMs3s91+V6P/Rt3fxvYlHXLP1LhaIIYQnDfkqb05QKximXAn34u8xY1648Zf4PQ5m6QjO+L/Ln4WTAPUffMYzl/LA46rs/gyaRv+unbi7hvTnn8/yD30O5mqfv3Hy7/x3P9NHfvQrf86RO1ZXN+r3a3FbXD183XC77/ttk0lXt2r2E2/dXN39r8qzvD8gwwm8rPP1Epz/opL6N/osZStrdMQkCX7c+c+/ZZmH+49rzMfZf/7Qo/xv/7tZq/9OJZKRD7N2Q4/uLu9x15bnf91EbNb7ebbFmy6U/3ziXl3eWvHlmyY/lT1JR59/12k32WP94su/RLxJ67wO/6/rq5TFE3f+4mfzbeZb89sPdT+se+f189jpI6n/q1S//0FwIEIchvi/EX1//jj72nWdJP0VL23S+6T8t5aKIfElZ2Tfm7e5+mj5bf1/kpyz+FHvq3bwz+jWC/keQ3BvmGs9/e6DcG/kbi33D6qwT/RgLfGOzbm/iGwz8eftM/leXWw+/68t869F9dh/7fCuJfisxvo+ni+fugqC9B+ZKVR3TIbzhDfxcn4hsBPDJD0s//txTdIkSiz603cD/19Qz67f3+0QCBJFFSZD8EkPh7UnYX/w69oT8IHPQozl2+F+WSWbdyPsX7bbzvsmJpm/sTeF8+S/bDGv9Yp7+0Nj8M0JZNd4u/K/phfbisb7NlOu9Hftx9IT+MzQ8q8EJ/fN7/bFihn/Sg+J1RhX+URT9sef5b0382d/fFD4v3z1g/8G9av/9W1P96ivp/sLH7D7ZWf8XZwH/7DXHuSt/B427tN/z4hW274Qb5MmnoY+GIG4PuB6hvOPWrh39v/8hvJPxVi7lx6gvU7mfgLywjv72Z38Y2/fsw9TcQ7V+CXk0UZw35G85T33X4bu/Ffv38awAO/wt8Q/4a30D0F/iG/wvwTaedpuK5M2cg0KMIasRg+k+/gLcf9oT6EgXq2xv7sakk9mO/34QYbRH3uF2/2LmnFv3t/SUT97Dvpn7W+l7j2fTXIwZ/Y99+t0fzMvV19nMrvuT63riyaf6i6Ie60sm9MTc+vshnQ8rbQyN+3GjLNH26+aVQfO139izSvyMHPzv/C6l5Pv9OVMiv//5FtvD1+jfkD9ICY/+gNYT+BdKSMkbzbv5nOG1tTP/PbKnwvPqVtPzlLj7LNvyNuf7mg0fxz8eBv7FSf3NZoNffpwgg9ItFAf/jOMLfX5Xbsx+ey7L9Cib8JqDyI216P5ffIZ+O+2Xp238Xjj5fP78Q8qV/pDmah+9Bjk95PEJNfnVJ/CwFfpbc12m0RLfJ+P4RYofHCFOlS2rmDkhc3hP3j2o5BePk95Xy/KIFigjuv9TiSWh2XzgL0DCGa8L+CqXUx/oGkRBo8xtmWrAxyqgaWkBkUmbSg4Nxhm2JSs7KcgUjOJyvxapZyJbVWbkyOC93D2vQqM+UBGpgegVFHd3zAfXtjfkLht1NP/sEsdn3PzN+X5Dvq9s0PPy6SYKvzb//YBt+/w6R93tbP8g248j17mgxtCyKMijt4GCTk+znej1YIV/ttDbKhOiZ2lLhrHQIS9TuBkhToTiDRshYLpoRYAxLEBRlYRCbnCnLJOJ4aUaGsO5iVUkJzC5qwjqEMF6KnsktWxBILd0x46sYDqOFrJmcsmXB1JI9NvLa8M6vYoYpKZqWTc3ZY6KuDQ7CwqggmPoutnlDA+CQYGaL87AgIgWmPinC7hINEJ7ijPMmIyQFoj5Pxu4UDhBEhp3Xp9gkhTzfT8BuFG4XRYZcVsjrDVK8i4EDoBeNM0iZKZoV4nKLFJU8Z5BbkqinmH8mzRkWISpzwSAXuVCU+ffXggNu00zmkRWX/oAP0jpr+sU43VZvxkfDMORzvrebXbIRvFkuic7YO7WsVMjaiapY7VZBclo/p/02Pi3uLFJ8SyVrtW2pPPMqY7iRrWq8ao3j6gq+77kbqMU+PqGRZ/l3n2AoZ0BUfe56JN5SpnAd9j5gDfG07JTHrfCsfP+r73+mXA9wi8bOsR+Lbx0yo2+ZL9e4XOocmFau691PIaOQzNO4heeujLYgx+Inpu7qJFChNrtdyHhDADkfdFMh02vTBa0+6UsciJdD4zlqbZ2abS264IvJN4V6hGBc51ao9kznokISv4fmld79gMFbyprq5XZhHpDiM8DTxMOT58FP+lnHfroGH3CYdvMQ360CUM3XnesEDffPPcaT2AbGE3sjSXeGWvyOy7MahPwA8GCCxo+UtaiELPqItTiWiQM+vj0y+ERy3pz4fGWuKl4i+xocKn0fWJU5dUWZFdoIIsGsn3LBGcj6tPrdpfJon3RP2X8LEqnEVQDcosPDevXAiJB1V8bdV9NqIOLFGPVI+bzh4/oEUX5Df0iLfAMTatb1xh2QLQoFIDvNxusgp3Ex/iwEIuDDaM5mmwoiPpfus2VNVe4FxWUE/o6DCoXgC4OfLVYaP7fjktzILvPk5UL8yK/orknvNhL1OzCc44gEL7NJaBmPcE+VFu4oOerqP035yMMDLtdWnuZ7Qg3MwsViniJ8Cnf2RnXIvF4jj9T5ym65C7r2p2as7qnSg0SHFewirONan6A9EpiD4x7cUu4H7T3TyZcjBhplvDpzCYodfERuZEX1bTetAxZbGFjBIzp9XHSdpViIElnR7PILFXOAv8pbMqUn+uFuikx6Xt2HZ2vel6YgF+jrimEX3lSMUB5JcdDdH1f0Vr8bYjt/OacAyBD9BCX53rQipC0KZItozrqW1/xNw5YqI/TbEZVXtr18+5blx/pR6Svq49Ii/RowOEZGq4LcdsPlJWntyG1OWBRD3wPFUVMdlJS4nF1JmkkTiVd/6zOo651lmGkxN9P5lqdPykrZ4V436wwS/Bl7sPGQ0SBjGtQpYgMezHA6YFv2Ho8oKLsSYRZR4nOq8wiY8RYuoTCWntIskcdXNJk9jtFtuU7yk75Bo7mtTG0Er0oVQFAcIdm4J6FH1TUh+m3vWYpM/agPb3BjzhdvYeKjz3VnXpaZwqzvP4+3SZNEVc9GwipgNAg13PLAE2MXKhk2uWAWUPSiPlQ1VpGpHI4dfzdAfD3nAhry92UTmBunIxF5trw9EHyTKxf2NX5vEauN6dHoGU0dKDaJlErdpa8QUmRF8yzqI0i1jphMJTe8X9pDWsAsH2eqx03vJTKn9Dq4BrrbFanex6vJ/dhc6oCZoal6A1jzgXjp2uWYOUpyjqi0mBSdpQ+kZZlvfM9FXigxjbPJNDCT/cBI66NmfO69lwq42QVhhmfDzOG4Nb1xi8LHOA55qjVHFnnm/JQdL6g3hjlzgsW383wbCDj1p6KomAZIRMDHGSoAcnsH4NezlLjxOuPFjSiDsCGOJCpodDEDLjCSRPu3g57X3sKr20p8c2hz7Nz2X6AP9uXITUFbtkZVJzbfDSWwNvePYuZ6hU8vvheeDw/mHtdtxE6U7aX9MTSkkqMCKAfGrels/2AyKpWVfvOpGeJeVMNFr+YzghN6c9H1RpOjwRU7x8/OdegixMPMq7yNlovPVtZ2mpFgUFgFba+BjjbWO4RFPDoZToUWOYjE4zDzduIN2VcG0X8r5LsBaj3dzG1aW92UmOMydfqeT3OQWRYHLWLKlS4h+rhq1lthxlAIuzHxOnfsqxGC2nQCzIHx1rEDCd2ZLRvFzcI+iktgfb0pzshhnGALDxNsmzdjGEYtiLQLRnyJDQWSQMF4Sx9Z+n5hU6alN1YmkRSrQu5WuWbmgYlO6u3M5KN0gYqetGGes44OI01lQDYD+/y7HloT4FJpW1kBmoDZNsnE6FAsFgaMMDafwhHyHlILn55KzkjLj5IxY0XshUKukXKJqFEsC50INFVu3xtcX0tx3WMoldcaSm3cB58Hg6Vb84jR5ltYs8oXDu8SB8s3X/gUQBOQWxmuJEhrcxomhtoftTRmEXpt8vuRKWupvvCNy4uNFBoJLztsrRXv6oj9oYPzcssSMEjItCC2pYgys4b3Ijcqo0bp633AIP/24fFpazp1P3XmkEiHZK5EqCCuvezCYQ+1qB04eTuQ1QopL9thi8mJs00KTDr5Ngtkq6lHfAkMGmjghx3yxWkMcgcW08zK0ELpcnPjgeLf/jBE2qlkizoYYgGc3B8fPGlwaq3i9eE3YtjRC6mb9Q0R7Oq4VIElGkWXb3WYnPzUmmbz8DPhhKqpceNWm+nsm7bzjTBjNflFjWADNnX8uk1IXEqYjzbGEKNWFkECUa1kYS2jxcz9SXP9o0MFZ+hTZxGMrrrJPkMEOpqy9lB10SpwDAqwiNT49llKTATrxx7WsqwO0oUgWaOuU3mmsJyPTJt70oOpEB55gfF2z+Nth5rPSyWpZkU7broUpe3L0oBHKq230KUGPE73NRc3ibS+DaOQc2q7yWZx9u9+w1wJ2w3EOETwJbQs5J+PK4bMTJIZNCyuwFSaI6yq0amGz6iOKAVLQsDeIhIAvgbWRZi8W5I20DeDG6cPJrPhxgyGkOIDF8pi5cfSFZHxho5tuRxhb1ck4tPjszSo9jCN4NkP+GCPvTQCWMP3oIkFtkk4aOCH3ni0AXw1qMmh9XRj8yv2zHi8zRhLCuJs4A3JQ443NbDpww8ZJdkJ7ffaqo0DydCzZvRX5/Xqx9DePUmw5WclIFPh/REOnRNiPCuk+8cwSLS1E3nnFxOkq2QQQHGKarZtg3r9ncCMN9PoVIQBv6hAwDm14ZNWyVSv6+TOoxgBwL02t6pPg7ZK8MU+2GgWInYzR95ue8dICqCUF77Q6ON86xVDOWKycHO99g4GfwRfmfohyU2sEgumdoyPRAgPXbGlNXK0nk31Zx8hWyCzDxcesnDpwv0MfptRJzVUhtGM2QpMNetdErfMSBhl9WH5m/OuW6NGeArapZthVY8Tl5Q29KhFeTteRsEba3dDAwcrN6O9aenju2lRIdeZYpWdZW4eKChXCH1qFHsxq3k9HoGQMBnJwOFCN6ctYEX3yK+wv3qTsZbGfp4j6wL2FUnAJqVoXraeiEo5AJaSy0pv4ilqfRb48mIbvJ21Nuseycs+myuUHMmiq/CM+3E9bvAh72XVSvl1viex2PDbSN3THUnjWMCCFCWCf7Yegu7dfFtM6Ipo0NUjXb08xqMBpmyaDL/dUOgxbP4UITnT2mHnWIiMTdBSnDSM8AstqK3zDoc8CLVXOVSos3ehCsKvJOyCuiRATHxDj+u7bmt3K4xpmC+nWhVfLQRqIU/pIquMMZ1NToBRy4NmkV9jP2TY4N2+XOBfc3Go11A2w6i7sXXbUzKFtqnLrIHGrG4sl1S3qlkpbAB4/Gk2wdr3R/HeHiWQGGZZdmbsrXRl5k4oILkwn6cJ70E7pqnFfRm1clKy25fSei11YQzFXQsQnOWB/+t1xFAh4m8r84r6E72YydLM4O32Mp6fFtWjB5UZvETrRt+svhgWF9aULUi54kO2DvliM6axG3F2K+g6nNGgr+069DBxrllU7rUdlylHSo+dpMxOEaNmIHNpLcfLm0MFuvbKqg4JquPZgS8/0IkWhBkNb+6iN0/F1an1JtzQ+yN8fXOzC0MM2dvzCIrOufQ1zCxBjcIpzbQZEztN9exDfxQzebkBJTz+pJ6nuNty1yFFgwu01JtOLp5ajGOVLXpRlWPvvXygYMw7+f6zW7Wmjd+fq68byr3b5b1lmHwVIcWIqeENb+/GVtHl9BVMxXwzEOVguxjMXFNvxdMTCkpzMd365O5HCWwTQ7B8tQWCyd2GJmeDEjn7oiATaO5WqUguLHJLsrCaQikLP5LwfpzWgFRbHXBFP+ER7qES1HQJ8O15UUyoRLdz6BpADaUxziS+8x7b220lVaVkX01qQ1FXY8IN3nPZXWSaN81NmUxhupTqE8/1WINhkb3ISd9FthfhaN2PWVXQMbLQB3WNutR96MssaygyP6MBIK+wCCfbkloAUAp6RlQPPvTGxJhfdHMFmS+/q2MvW2YMhICsqdK6+rbqSCHL9IL1pF4D1uddFk9siEkiMixgwMunQwJyIDXXoH0ZWIYSFjJR1imCU/MJJcEd9vkZI4P7TXT3Brx0q4gUG9Fu79IreRvTJw7sBWO5bXB0znWese5q3S5Sc4ZZx9ge7L5U7DAHfH5kh1/sykK8VRy0TkTw3DyI/DGdV4zpVJrwBXNA1nGDiMhOn0IONsvz+fNNmWRVkkRRiDpbHInrBW6DOUbBygqN+ToedAHMm69lZx7AKeQJnNEa/PLETQplvmRCmSf7VjZaLCOdfiEk3VKEjDg2xtMpKhOykKk17lIMAYuadQGWECfQQjxaZnTlZHmU+N3izDG9e3l1O41yXajo21XalqbjzqQyaXnYuHjVK3yRr34yQqyZKC2I/IeuXarMTwWUCtpeXEyXiyq4TJNWNRZ9U5fyrXByqXEIWGF6t80mgNLPLh88H+un7njX3cbnPW0n4Eb4HvZuyjkNxTCTTji40sqj86FPXrYstzD1gtVFIXKyl4l2KphsqSPAkbg3N64Ypzs3sF/0rKt5lLd0ynsJ/RTt4LYzN+iNLLeRgLah24vm1MLbUNwuSJO2h8AbQOpIuoIPWN9jWjfPt8Pv0fnZWNdwSMjwmAVIDW3nGeu1ls1DT5UHCVEYHGMnE8tsCTlgKx+bhCq6rDPGcbNJhC4OSqvYlD4C2j09dPK2hRB3sbW6KvULOMn9Mx/69kZkyg+QGdH9DjeJ3g6ZFpuYcHcSN0pEE6UAkscoUZAzyKqFAb5lMFzOVx3HCNKSdp8S2areXOkJnAAcHpdZnASHRXaT0773Ky4HRk/PqidvfjW+hlhnLISVrFGjq9P1GCBDyhJT+S5/eTlBrahfbVffUzoX5kg1sn4v5uf5FXdwCQK63VmtZrhWJEatVvJ+mZbytNOrGtcbG/NNySPsEj0B6DF1u5xcoXXpdMxVuqUXx1SjE5SY2+lLcmwhLynbuZfSTZX7N6HZwCtQlU/ARCNKUCT7Kr7LZ7A9yKFWpV9J2LyYj/1nGWZNumRQqK4VyE47gEJDqlhVOJEgWITXDqSwJmmYQURleOMAp01dYLP5RFeC5tw7XMamzoiFpWaRC5pMXYqlay6/V/LXKQ9twMOv2rFuWHASk4JvduJ/NIgQ4hlCbnaZz+hjE9cuhljCLPlzlDwlx5lBVPc+GtvlbmnOMcbr/WI7MvUKLPIiVlglrMt/C9tNnOJEV9ZnJvVGf5J6c8TuFTMcrj6GSeHSIKpBrODbfUDNjDZvhuOG5PnU2A6jPmVftu9xNHymtC+etq66zhpOJl1GOEiRbvdrjf2Na4wl7w4WCt6w1DBp+NJ7WFI7bfNVo7+NPd5alubYYmLNL7CyPkAwTIxjYPwqiKqkmPNyiSL/eSMvs2zUj7IbQpIQZB25xqAeJrOlfKsa9W1DuE4IMhUskifuQtu4Ze3UftsxB+RgXmK5JyibvTgZLZ4999MHWIYGeIL4c3XPjL2or+AqMVp8j1T8+7YnkgMlPdFl7pshO2hAUnID48wczY4enKhQmACstUclzx60kunZkmq0QjFzpvbj0viHsIVQHwm4n5FNj15PLMdy3kk6NjiKjIZJzHDhZPG5jNTFr4zi2UR8QlWk98Peh/GB6WN15TOwCWborl7BMDCqfhAEkBgxzORzLnb/MbrO6ntQ1Dq0thswAKtr52DPaNBrtlzSG9RauR2KwaQ4lS6TWYoZoSZwhq/FjBMT/aTQVBpA2zwi71BrKbw9Dv1tJMnSOUAm2ROqP/v+IkdbAWDeT+SrNJl8wKZQ9itlvKbAqcEuXYGstki2jUQK3C8bG4UPPRrCh9vcYDVDoj5TdDiNVTMMWr+ZEN7e+09ynDGlyKoaCqChI7eLV3JwLCczgEHWskouyH5Zk87BISE1PU30puGI3rx+TIIhwjfttHrtmE5Q9+UsAEQUOTAKFkxW8kK4kbXZM70LAkyVnYC425p0PTodK71fv2GBKGj/duNXNk/Vcuc+fIhbN0ln82EgIEol1fzZ4NsDju7HRGZpRHovdrt2Gal2sxWhMsoQiVBO89PxkSm0aTOneAcdhCKwJbPmXQ1goMeIGiq5OUUiNppm7cwoFopMpNs4jfZyOxDEcR2iXVFGGEaKFad2KpBcZxaUH9EcC2L+46yogrhgpJEgliJ1aNKNRIrOcvABuk0CBFIGLgvAli0C3V6cj25l5UiEqfmI8WSBgIOEzQ/XI317jLVFROdHeG+moYTpLHWn/UTVfCDyNd8FXQKmlGbTqGSeUjiDH5VpxxwXBSEhg+tNtTfn+LRGb3MNn8ubHNl5bBoxln/FT9AxRWqlPVnGyTxH8fzy9NnYus3noyH3I3CMZK4lj+OSODzSPaQWvEGWjD/3Ly3++C9UCASQqRkt2Y7DDg3LEkSHtDd/MktCnFcMecIK8yQgxE2uj/3WqBdx+1Fp8v54DR7mNz8MA9J+Nq83LUGaH48G+6rUCyLDjARyjSAMEreLlOLIx3OBIKdcIYRZ66mU3z1qa7Z9VVFyUayVnhge0ACfPr3PBx/uSoxTUi4RwGCEx89J3Lom2xQ9VQxSqpWZGj7Lc07Ge7r/vis4z1mbSzgYiD79xfL6qO82Saf2VSGRho+6373xvu6Dw4cLmNriPMJ5mAD69Dbx20Ng7yrPKZmUawm6ZOqu4zQYZPS7dL878mzynKoSluNqpoRQgSA8p7q/Shj4dw/g/34WwfnHVIC/ezr+r8gZ+OXpOPqLDBPsKyHk9eSCEPS3N/5fNBfkV9ke1o9B/iK5/v/jjv1McIB/pn38bs8w8D8xywP635/lgUD/QKIU/Cs5Rv+j5PgfWJX/a7M8bKD+c5ZHiu6QaXYsDZY76dqM31DHew9GMt+gqWKs9WShWXEk47Eae3mMWNCvZaCavaWdbwKVqC1QS8oYPIfl54f/tYr87MmWYl9BqbB5ha/P7ccfEIaB9nX7idcQdte65+3B7MSyMAGRVsFuKbscmArD4qlZkrJJ7IZ/IBzB2IeaEUxS0DutCnwLr8tNSmyRYjV1oi9GJ0ilo6/I8e7pi3NB8hlSIJSY51lcIiAjGArDeHCb68qOk8xp6CqSRhQhtCcjJJjHt4JHUYjGt06+kDthhqWkvC96v/sg8Bd7jIJRBgKxHIuQhQVMiHWfxdYJMISp1kKAQYqu3H3wZ8JrQ2GReV5eDGAiLZ8LN/VCVnlyjKfjwq6iHT/onbDFHYeeuBRBxYJhvtYge/p4JpeaFEOTJLuKPX0pOmEqNX1lvpfn1D05itfAAinZPF/tAmkE2UhuOxmUlZ78nNwJudDQWdEyNNfD04UnJI1/cYYCmN7yc9K91gqWHr6evD5PyFB8bxOkP5t39JRY55Ff8a8n6G8vTCq6IHJ1oD3iINuSkkjePgIYAE8glVMxbubq05g+0HtFjdgC+2YPnTYb2uR1j/V9OukT0GhgKzmipXKElqI7UnOi+p4qageFEVIIhOG0E8M1aq3WVsYD+VI+qfoVKQyBXEUkIIQTxzpJpoNWOkS6imjq/CJay15BO+EQpKkDg+LJl+UvMlRvVpN9WoCZqiCMkYDKUmdsU2QcUqJmIQq1CE6yryeSmbGR7/c2zPT8PvE6cH6Fxdt3Zy2kXFxCIqf7xuaRfC8XA/O220YeZL/mCwbyJIzzTG4zu4sgJa9wUaQbP5Q0ydUfd0H2lcIinog/a8G4Qrz1cVp3l7NeJSfCqLmguYVMqEGLKrgCDRrEz3hCK4VnNAJtPhMdyhdl67sn9SziQDyj2z/Tmwfyufn44AgjcGRYcIF6LcmzOp1N3vfTbEQGEMRnuFOehUGEgZRUNQDBdx5XRIHpa4wZmMwq6hy9nZHPyvYQsYfvr61qhNdHFUgiN66vtshIE3I5JSpbTAlXDBnhgYI6k5EiuB9Ab44LypYRPpXXseYKzLjYQMLF6phospnKWGQgHq5ERTgERqn38S2rLLXT03NgZqoiwevo8aKomjrcWUSzUbm5mT+kdiaqzVAThlHAAvlugeTD8spsV9UVp6UzLX4E0rcgRJZsDtp14p/M+NiI7mk1B9vvt8Nj+IBGmqUXkoB/5lZ3o815Hfe+3N1lDfoOe9TEXziOtS+RktQWU1Xf3xHifGY4oPFxEUSo3xLpnIyycSHmoGvMPH5abGFDJTDXEh5jOcpNHClDJN4AkhTUs/s9S1BMcdyGIovk5Jr4KVEPipMEZ3K1ftwjVb0sY2FW41V3wYIRdNbq99pjFuChH8rRprIubkmwOCtuRhhf3tI6jfXr8FYVW1Ewr06xbvWTxNTVmK3E6IdXA+12k4JqLmNkJBgsO0mtxm+Pj9p+BqtPnPotk3y7DozG0VJov0vIqgYagBwZXMNxYTyCFSv9CW32HpE1LEy7Z79ux+iVjDC7Bs7sO6jXQiqttW2cy/lgxM5gBVXyfAnzkMRcpqqp+sQfbCDs48vwjSQ/Z+V1aBTdtyBOkvDH6CXuBmNbfUg2MQcfi6i5oJnq5px8n+zkPUjuMXh0LuIZZeUNV02+uvBAkZ4UkvTgLpJ6cWVf5kYpwK7i7Jr1vbCi5AM2eHqQTuOdecrbT3UDIuyisbjt3UlKm+lEJwjr/GIYnHRkqJFU7zFTkwUP5jV2zdcpwKc9CZ164vexk3/OtG5nYTJVcmfxY1hXl9PVRzcWm0J8Sb9CMhnDT9+Wm2f0BIgpBylXnsPrtQFRUmJs6nTPWa3u5ypY2SoLF8yaVegEpQgWfyM2w30lLpF4xSizd1YAZLyBpvT9VvKdj5WCiqRx+EVpFBafH6h4MiPeCwDMznlh9/wQW6UJzF5zJ+FHCOg66BDID19NpHBw70/nUIS0xvRKLPL7yfowjO5dBlOq1oxNlGqKflohDCGcJvyDv1hIai1iiAQXgxhoSettbid1yw3yJT0OpHXwqlAOdS55JbsJ1t6/xLLd4ecYQDhAUWrafDSeWx9xbY/Wc9NYVoTt9gyDS4pVhjnzSA+sPX5OP42jB2vHZjSi4qHnoHf1IgqhBP8s+LIqNPyJlS2EQMy+fHdsIalSE5ImpFYKJfZkGCPhRYSU17mYPhlJJ1+a0L4bAyySAWnNohAMPksGjBpxo1PO0gpAkUDUGipubvSWMaFx2ucUqQZRKxQMigBBynY7NwAtx5llH1fdUHf5Luesjyq6K9qXuBcV7O26Dy1rN30hMkMIgizN3otlA6eh6rhyzlAst4FrMOkJcvZAnlltCJLjnTUwMz3+0dMJekTvOcTKN5RTHvznSboBAE5rFAdfJsUMWD7SnyM4Gyk/iHBctC5wUrlFpkYJFEXOT/hUgoHVloTXiG3Jk0+6TGoPGGZfnFz/2ui3wMHwYaTTbqDvLBOywa8I9/IsSlQI0eOU9wyd2yPsGyQJVzy/nBcKXxgrouBmDM8pwITYkKTuaaDrYAyI8JOQC34FbAVMf1B8fgIbmrRPmIF8UN56/PmPP5YDs71iNBY7qfSHZ7JnhsCt+X4SCp2HH1oFSSQPpTk9UH/xgrDnD0FB9w+7BZ9XrHzCo/bzOBQzuW8WbNpbPWH81bBEO6b0g9VopiuoGUdRwbC0OrCdC+TS981JSJ3imdKACkeoyqyL1QqmMB2EQ6acNpslme2wy5I6LBPLBbCJPk6h5lxqeX4j7lHIYu9LO2qntQQxtg6lVucnkAmTFFu5F2SvpT6jQYUr3iOg5g18w/uNMJBx64BNfaR3r0cpoDzZBa5t5FZ9VIVz3gjcNZuyO5hms1VLJBuiB55rHBNy/1reJDMTpQQuFx8ugdg+Z+7xrbwehppq0QDNu2vEvjcRplO80mblS8VSYxF1uezamw/lQ1S7QFdqQC7mp8mMvoR7QS2FN6FodmXwREDUnCmQTuctxEx5E0ZzVlWq4JqByBaZnOT90YV7NWOevA5J+SS12VjBob3eCVOVvsoh4Br5mRyz1lNbkcXr9dqeeHBU4glww1cimOKhN2unch0490kdB/2u40LJwF0jIU8KDQ11/dWZ2NDkrYGGoFJ7afIuCdUMpoHTmM845E7FDN3+MYWYnv0Lqs3goYRBgdzsmMyDj1HItfxEtbK9cQbUP610YAHAp+du/nwY3xbay7R0Dc84YyQr6uq96sW9MMbCN8sAB+i6XjevmfV9Dsk32emqAuRrMjIJu48SbOGx95hOuQE8gpHIjo3zVHWYh+ZkXlUP8AWT7t578LwVQ7YDmqIdKbXnxkDe+JFwGxmLEkoCPimXJyr11REzXScHJUW5wk2RcjdIfQELVW1yH4dpvPY4dxYwFMigaOjIFmmr5OMxP05TEmnOzWHyJGlwtkhRtlUyKjnMafG67Fys2LknhNrC9TFRT2RscCDjMxUutfs8Hgnk1aMFS+N9U6k4egoZ7VKJX8HixpOpqLZ5u1uY7S78Vx5RzYEtu8gfc8V0SIE+/iFdpNZ4N2c/k/7GX5FJZ7XH6ZI1nkij4Vr+6XaTfrwftNAZ6RJn23c5UqvxaNUBDhWYvKOTaIy27lKL3UyNyVrpVqNUBjXS9IUFRumEfCRCTZbUCPXiUg2Gxdq12FvqXjqlR098N5yTE7rtLdOTk2fnK93r8A3qniWRT1ZxtC6fMcqe1UyVUilYpTYpnLjMualheWaw0VlWwSjiiQYGnTFaVfNm4dQJrlA8W2ZffeBXWdVXxUkIxz0TujYHMbFwBCH8BgZDlnHZQlP28gpqnxBpihFuR/ZTrEzGADrHDAMEKrmcRNNNJ9j28+I6mWRq4lMWZNDctl0YUI9NxUh9h+ep7k6dANWQhCMUUSJHZt/xCImEpKfFDLIB4t3xAUYg18bAlM8s885YCYWqDIfasZIJ3lC8LKqwcSzidxaCayEucRPtaKTNN5OUbufOCsn10Zx4rCUPlHFHTGjPbIwZr1cJrkg0FIg2H0yJGbfMOHhwnTbuiFXcyJUknl3wksBBWNPH3+sZBC98OlnXTNoaMnFTSfzYGv/REaMlqkAIpawDi9Z7d2FDxIVGyuTtZuyQDncjYOdiszSPK/oqfdgldj8bxgt8WMhOuU884yY84bbUIpbB0nHwUWXeSEG8SDRCOHYWD0uAvKUA6o+1VR1ye+IrI7IV/lYlNbELps4iEb7pX/DhV3H8uMR2FRk86zBbMLawkqZOIeCEGwlNtfSFkL1VObZIeket4/uTu82qMruOnDp4fiLsBMBEzUhCDvqCJTVaZ2mHxb4iNFslmoPuowAcJuQDtMqutRQV7iynrNRRZuD4Kl+eMAPwPJVzeYCVVyYhaN5OPuNjj3MxEw1vTUNk6GgUCArxIE057Y028vdi3jhcnohWkQ/L3Ag4KAVBVG5TWRaKcUA75XlXJbzIXGCyhzK5t04+WSskojq1KbOn5bAGg06la7cXWTDKkOyMFLj1gKCvggAaIk09fudKBiEoaHpTznmjjktWjYlL0/H5+DF3U53s7Z8097JGKngOBuj0cS5TT9tXwXltx0yI8iwuBVg+1DW8yPx1RWjzARh7oN9e/tLPoV9CMiXE3iafl3pqRpKMiofdeJyK7dlw9R5mllXw1MFgTsMxSyN5TMhPJJ7lxGYvvMv/Sk3aecrmOajCYpLraqGUcXi+PbuyFFMDkVvwBbdKi3JORcoMG9jG0uaTnRe2+zY0XOpHQroQlglUPKkIUjlJwrZWsI9ktxfrUvaXhutwbK4FX1XijUri9xqTx7y8d7dq9fRT2kxhThMKxqniMFan3mZOPT5uY3grPMqOVa02IpeZ1xNCghOOS2nL53N8WJdVQrnM8xaOK2kqMsUCGCR1jIL0FPs6SBpv3qSTgE/CGmSxsgu1ZjUittuaB4hYKsFswJwh5V39cUfmvaCUpV69lNM07GZ/bLicV8GYGTsb1aoiV7tZzG0xLIQODh6iEnKP13cVGTCllg08olGhgTdHvTtWRaeYpX7iFP8VH/UnvyFPnVQ/aynikaqyYWs1r3nMKD13eFsMRISgGGZOc5gUwT2JHnKsFLdHH0ENZUoxUj2hJpPhswJ6MbHuGMHNkVJZ0jCqGwJYeE5NJMEz4iE1lP4mhbdLrOAzZSBRjTw5yBOffI416G7WRYg5hqjAC7bxkARu//ITGmQIxZbnejrnQfo9lPIj1EgO3oick+lmIW6pJeTlnzp4cuVikiNUKgaIfORgtWTO2jvOKKjCrapURhODwifBF1AzT62YZ4ag4pUExMfcqrKPo9gh6Q9nYTWirGmolVtHCtsVtYlp/ritq3CcTHKAEgHsva6zCVy1W90GPgZMKzobDQVS1aSA4uLg4vESRRawS01XcAOJhyvqk/j03xylrXrfsabz4Rz6Y2zuVWpgMDBecPtnh8YYn9u+f0VliIpq77kxuXV7OjldZdYW7yb7eFAfUBMmyuqulCx498nPIz3N+EpmOcfaN+cOl02CUTx9tX1tVjMOxoEpMk0Zqx+NnkqeTNgvrpN3t+G0mx0VJmYyNVO7XjOYoEeGP2Qd+1x4dey7hDihUFwvnen0cbE2f/EgQ6Rii5PVTEJCjYL9NZ4aK6/4OYsfn1Ge0pc83Z5OQdFvfMcZiC0ynduESXv5gQjH+cvqJgBS1LGwSDpEOKGH/eqYoNLKu+elDHvuh2HfsY6q3Tyn6OrQddkxBDK6/Q6zvqBBovB7/256wNT8TgZr8eVQ+We5J+4+ie+P7zACVnH4maJd9AXD0MIE1hNHYCVls12p7f3qHNnQuXLt9WQqtD6b8eDbKA0zd98oAV6KeGRRsRpVrnU/cldADEQHt29uDbFM2qpunTOP5xj2lagnIk9CzzNZAo3A9IzQMmAjCuu8PUnxjU65dSkFHeWzVxVrcsvKFYoVlVtFhTaTWU/q8jriMhCP5Mg043xPFU2EH2VWwOgE9V5lYAK13oLAObK5+3Td8dQ1FJk3jqBuu7fYoCIPCx8rnHXDuxLx8TfjW+9oCHPIV/YQ6BVeo5BhRAotR6Oz/AlfZcKNfHC4NYZ4r33Ob59KyIu1F6WBsUxq7pL8bAtZsT95e9UgniJEJWmd+rh8pV1+9MRAhKLeUOBN8nl141jhAYMCjKHG3FTySpYVny1hVlBW4BlcotazEtOmHbXV5LZrHV+RBEYcs23c8lgzLy2SUxVSon9ioKdoaixyX7ALMt6TecKQIkEFkwXUEyN4ndJYZJIUmhQ4FiGNvpGHJMvbUmk5uDIzXiL7T4aRDg4hUUvY5VFJVjoiXt/879G2V0Tybbng80zYrGGCLSMHQD4CWOq8ZVXMALfqjm52Gvw5rS6tQdMpxuQQM50sKpbHlDJxRp5bwaL5C5j3UOCDE9Y3VihMHFMXYuHw4FpF5PCFvNyHed+iuTjNd9iWgrExGE9aGi1cBjFmEnRMjE48rxmFGDkKRNOih8bimAY5kL07TGeJzJNdZXKy0wgcRYkC7SrnurUUI01IiOR45J3HUUHr1K00cDmJhvOWCF7YB23dbGU4FprAAYMbuGn3e+nc0NeK5DljQTJVrkZBIm6fhXWbBGV3U6nlBgZWrX/OW5zc9dyr95+zh9WvLBgtqZz47zb+VhtPtEcR8YNgU3ocvtIHCFI0HYSZajHP868Egn8ihwD6G+e2/1QOwS/PXv/D3rCHf5FD8NdfRnJ/JJ6sgv97kwn+8a37mUzw/qute/9nfmHELzbuPzuV4E9/+Z1Sv0olAH8pzsh/kDi//n+cSmBSv/vCiAzeP67p8xfSLXFZth+AcBx/z8VR6L0X9rryd8K9GcGxzfEj0eftXFDllgsRaal9SUb5wlNuDgSmNXnkSZilwr96wL8pCX7h58y4tT4RAADorUpYmNrcZvt121AIyl5Zlh7IS38IWb1BE4Ic2LV9Ehv6tOkLvnbY0FmBoKzzboAIJEPgGtYgcogEDZggJIIkZ/rMCUMm+J55slhJn2DOKIk3eizveQ+WpJphBbME83wRwSujXcZwCItJosqWL8kgCXytuQmGe4IhUKAtndbBSUIUdfVVgE8SJTCR3BMy3949XPWj2oWQlxz4m2Xe9P540OVsvpw3syLF88ViZNWjzwsT7TAGWeRWoz8GtEFOBrhq+nMCiYTVhaGo1ikfuje3hCgH+1mnqAGloLb8MIQUpR52gRCldA/jCswmyM5LAq6CXHlePGMF5qMWwtI7pMK1u0ftwvN+I+uLoUkItDMzPqWwZ7XEqFEy8BK9mrYbzrQLgYTuE70pHDsJcsISPMxgJiQmFE55TgN4IL498pu4PcwfS+u3bgOXpoFr4XgEaRnx2jRE1gViWR2DMnq0cPSMaS5ySy3xkRE9AccjbgQFcHEXzX0FJUFPr+L8pAKe2DkdbYr4KfVIitKgsmQ0ymHhw9OaObfe94xYXXUVGw5Zgsi5xDqV7AVm40oLNMlXsgO9Cz9qn/XFxfnDHWXUDeNzAONlHDq5sJSLtrNt/IEnKmcC9y8t3EKnKfzARO4ltR4WzYByL2NsoRGNSppS5mLORSusvLs8+gLdTil4/HNMESis944QTk7CibLrtJeG6D4wUui593NVFgl1aYt+7LTAQrOEU2rHlAdvzRV60PBpsvebQyNCtWiRPmOssrkqj9VG/8IDlYJ7aSYOToqvYwN8h2QKsIUXFWBu0gfkO1m3EZjgKLXFC4HqUM4ITxAxeGLp5NpzQ6w9ybRnoM1gppK+elopTxtUzdvx4lWGe92YbfYAURBltGr5BCFSy7eT0w5VXVovUITk8+swhw5yPb9Qv8WVVq30zyjaZ7rQgeWQOK/bYcxFvjrBGlfNrEUk3MeCw1nolldEHQxMKjZzzp3Yhu1nbWLzvm9HMRR5qgqrHLazIvkCW2LCIiRACIxx3OieDOAuhKIVEytLC2+bKLnn3CcAqOAFP8epe6QKp1JxWLo951OofrTxgMK4q2TFdCCx7a1vJX5b6JoDYfZimD2iNtpdnhd8j/MJWAUI8Fnk3vC06R5yPr3AXFZOGA10zs0lyniCztju5kzDPN/8oE2um3O0gRx4QJ3D+JKogw3IHNCSN0fMcqyc+S1uBEXx3lDj/SFRW4IcBna3d+RiSXYgybBnvtho82DyTLHW2+jlkHxaV4g9IvSEOguDguhjDgjgeVXg1aGoo004+3guGEOPiJ+Hr6EHlYmzbY/ucyMYzvA6uXK+kafmR/B4MhQWZ6VaN1q8Lm6aEwl5PwsT6SQLTkSb5QMrjP0Kw5ATsAig6D0kcSkmA5rcXY9dciIv5NZvLXB3i6lKHYecPi5qiez7dHzmx33+vg84hVilrkCF/pGygAc2LogjAiMJCtIhKOT4eVcYuVBmXPI5eHxw+kYkxDJo6QEK27ilSxH5hAUnkIanEGuUikBrbbKpqFbPmjfuCJaE9vNOMcQsySyZB8fFI1tND/45kq3BYzmwDR4uJDnBLmq02aJck5AnuGSdG33+at/f81wahAGCmiJD04KlAKsWxCqc1iOsJxOANYC701MdjtuOsPmIawJWaedrptvCoiz6/Xkc061Rh0xlO9jY2Zi8BQw8XTHo0MLJCpuyyNsAJSbgJnJoDJ0kkiphA5C6xUz/pCgz0z4a571Hwbsb88txJCkiwG4sUXXBxl2uW8AEsok9YQNglXLd1R6r0EvFLl/rSZIoDj5ssSIVWRkxBGmmLv5AWMb5XFn/emGwZUiWg9QNWhzh92eEhFLx9AEzKUg+T1oB4hKeIA9C/ZFYws6fcBI/f47zJaNYp9AC4zv5Q5jsx37aGW7g4+ISBmmNj9IEm1ZLhEi16V4hrKsRrZ2yjm9pDSs3JWESSZ9zzSvoE/HzHH6v+22pkGYaHNKi16gor/TrnXQD7Ib0RsX2QMGL3+nS77IZ4A221btSEiZPRoSO4BoUR6iPsz9NJSlJksgztDidoeeQwWYOGyYOqcMpFXFuhG5AtaPhD5WFpnDj4GsRdPHsZyILG9g3U0ZtFoYsJddQuEexiOHDJuEF5gFDDDr4NndflnRyGVKLfc58+d2+WocoCcQUVFk7LFjeSwrfI3q3cHkgFoLqcx6EgrFX5al6wnhuTcKE5LBMwZW32chmb/JHBlyhWG1sp+6JgTIKJgozMrno/sKTZ2u4zQJgOheNWVJEd8QJ2ltn+ezGCLakgUDI57UFuHOtxn5eDaBLbQOLclNcijBpnijV57jeGJIxtNCgyh8TP75w4CvgdyvNyJCN3EgUAW4T9uBlgxU4Zjba7Aw9y4jONNNbmZWlJjzfKeN/Oml9wl41ObfHIDuUt67yvVehwZgIto6XvyZEUVWsVKvsQRVpHt12V813jnhwx3tNdUww935H70ADLcJ77O7oyiNemuJnDc/OOI/bWnKzR492/xAV5aPzfVmi1wJYqyXQNXuee9QopA0j2rVgSACnz/kn4oYLZQU5Z9S9ybTCLkUS8KrgU/HpOqCVCxOQDSUsUsWCi88+N9+VUOX52qnboi6GYLCTcSPY826CvHlZB1miqCzSTZoWqQhjBwGfM6IRxMx37OYGEbkdDQ3xGrvTRDut1araTezgu4MVA3spwSC+vZmiE3sIOeWpxAQUsAms+nSAF8LWz4wHCfCreAGILNcGTpwWE/k3Au3y/nmJh0YHHzoKcOaWskyNtdXpUK+rkfeEwgwvwbJBnhL62nrfuWHFvHj3tSQSQR+r3GjWA3bPqanAL2b0AjvT90ENnQiFqom5CMRwrInkQDw8l50izzWjqKxS9WqCkRYPNt3ZrUQkurV2EnvJkI4aXwghZ3PwtmnBmVkFY1BHVPbEHMqicSpEsLgOwQlNDaccofyv9q5r2XHciH6N30kx6pE5iaSYwxtzELNIieTXG9Cd8e56Z+yt8tqucrnqvuAKJVINoPscnEbDmWeLB3glurcWp/i+zjaqr8v1yAra1gNEsfTuG2EaNnAtr/r/s37yrARhCTkXcs32HZc7vJm9VUI1DRe5qAOlO++EFOKvTzouAjiuyBLnXFg5QKfaBR9G3/Oc+qvIHssNlipwsjCDyLuhA8bwRikLIUybmuHahI7isjCbddp3h1XGgVup7Vv8czxniK8ID2KKJApheWxTyB78S9XUpWksDbvg3ONVjlHuOsGDBn5dDR8p6h629MC+NsrLRXXJLBYFPF+NTyxaFz5UDJgjO+/Rs7i9t6+eX38Qw8VykYGYpCmB90lP9fSmGHo7NmWqfPv0651O13B0LZt9KrPWQr/v5H1IJ3Yuq0X4Xu60d3B4XBfqEmwrT0SG2JTlDRNjxnXbtk7CF0YNULjSiQ2+qAn9kX43Cc+2r2pYMOhNOhS8jt13s7dxV/q8DXOZ2DvBKZWFP9S+bGn7nqJVi10BLimlLD2oiD1mkWUmIu2Eqxk0TnYvbwgnCNJVAZjJhUdcWRTdNgBHerwVG5+ZlMIOiJ5oi+ARHiH0NfWbNYcv84lYfPG70xz8pEkxQDXehZ2L1zhznrLKQcDk66d+EjWLF+xDzHkfkDqBuK51y++PXC7Rd7HakRdE974cDk2B4T7oICYV9qbMyZdtAj9dJ34t5q1hBJauvKH2KgaX7mBgEZigSmlDlofhsZvDRMJMoVBMn4ElnIf3mE49TepF0EhxzldYaQvu0M9dx/d5MfZtuF5enbycGd9ktxYSkDTiK0fUnm2AsCpz8uLRdLf+1j/xyS8F/pV685QTlgE4zQ5Cp87Ma7icRLNHo49eJKWXMGplJEtnzjAhMaPPVPaSLLdYxgxsQak71r5eJRR6VMIMp1BeK/3spCitfeCxuQM7qWWPH29BhaWHOFpUzmGTZg+gj1NgnHQ8ajgHa7PfK7apwRvShuU9OjgReaz0By4VUkepvOf8eT6Z2+rS2g1Rb743GWKJ22P/IfOM2t2Cx0KEjXLYux5imBslqzFuR8Qqs09zrZkiZIcuD7sl2tXRJWJfs7jJ7KfaCB1Syif9NGTbs0x4ot9f48mp10B7TtDOBUBC5hJqjwCnmqA62s1c5AyK6JHRSkyrhTnMJAuDHfDCSHykNsIZYWhslWBb894RFe0grmQa8hJVvHDoC5SJPvWaIRfCOGRf1FqCRlJCxuca0YwuEX80fbCQAHmGEaMogWV9CvU4wUcT8cx4+c7Xr+eavY8JSd5czOILMdAb81yBG4WCsDFX6aOXTFPyNyLbvLAx25VvguvdClv1TYUH65B5xEXkeiszGs2H/QjmQL232lOwmXYXguhy7ha+qyLNucbd7iTk4ss0Jokpl9XZWqJfPwbMro6RxdJ8+bNH+5CjhM+7PmA2vt7JkwnuYDpdXOR6d3UEfUbak+1tHeF1HSXL84FyiUZxytDhTJZf993GSb2Vj6IRqVUZMhcBYNM8n5Rpv036PF9H5yct/loA1Dktc9BHQ/AVSYjKh7jAVUWEJsXPHw5pmwswjUDqt+qdHO8IesRwUGLPfRDqvC0PoWTEjmNyWm4Dj/3ifSH5ORwwHQRDymPcLXp42a4IsZuoG44aOrsdUligR3LDzb56cs8mMYI1oPL+JLAR+FHMdlMHAiyKYLFrG11M10MNKB3LCVbftROr9PdEgnnytCowy6e7AJa/XJDbDqh+s6aR5PF9lWpm71whJDb8DokJSFaLjFXvF/QqRE0xL76y9obUluOBUnCXtSZzhna8G+nRvVLpqpRI+OY0q1S33et+Z8bGo5dOiNXPCVT91uFbSl/pCJbqGm4BTdSp+pbimaIMQN1TGEvQHZZc9bCjhokwLcy7RMTkQgHorDd5KVmFccC4edryoXUF5qd5hzA50zTj+6SuRn5aGxsBf96HeiqQQ9YidgnMfznTMSDJgijx3CZYUZQWfpSFWrmhBYXA3TfkfGEaMW0lkV/SYp7cpOdsdQpLhMh61GVp5jk6iWvTyFnlAncXpxismlNB9ts14kkbvQ7hmxUqNo67DM1zdmRYkXupQXw6pmvXGINnQbWQ1cbotvO2IlParrupv/Z4ZYdLjnenxSp2FYiClFqJGQ343uWXC79hCfeazYpRlYIDfQFbvKpwiWqrzFubBognnH2sed2ogXkwmsY1XSlH5FdagBxhBQ/PAoDuRam9mWneYHuo2nhrn8l23kbtOhWMqHrvEO69pnaFJDP6UjjlPI9PNsiLceJgRQAmbUYeNWTenpe06I2DysmZfaSIDkJisaY5Vz1zk3/Nt5V1gJWDcxtZiX/VKqyOoQmGAJZiwNtg3qXq1ESWwdwEa0Zod//0a7W0Tq6Eg6auvh60VZhUY1aKQ2XdCXh4dTDKHfoywcayYEnQrdx3Ntl2BizfV9hOMI9xpMxHNhkA+6yA3e+nb5l0sGeM0hjOSKzImO8S0pqOIBJ4DaJ2tb5oRIvlo+/SujJhuItkWCWkwn2GY0zWwiCWaJFL2vZs3FJts+gv4TmtrqE+OpSIaOU1wB1a9brR5qwwFfdQcFTqy4fHcDyRK0Zo7xajsOhk6Is+vRnmT96VnkRppHeaqzirvC3sfOiQgLN59bazw4ZVUMr0/a+KlPhPFKGfipTY7w/N/ljVQf9dIiX1A5HyS5LEP5cg4H9h/pcPOv/xEfuuTaI/OOhMUv9BdfL3dxAUeVV8/+HjstZjNQ5JJ/zy378z3C99biNU0z4j2BbrenwzZ7Kt42/H9+uZ8EG/ETp/cFfAc9yWrPgHM+77bXfJUhXrP9Mbfz8OS9Ela/P67Xv86UYm/xtGBqZcjvDXjQh+GZhw35r8/u3Lv1rHt9afODiXPzg4P1kk/+rgwHD8t4sDP5/96vpFTPgr \ No newline at end of file diff --git "a/docs/database/Redis/images/\347\274\223\345\255\230\350\257\273\345\206\231\347\255\226\347\225\245/cache-aside-write.png" "b/docs/database/Redis/images/\347\274\223\345\255\230\350\257\273\345\206\231\347\255\226\347\225\245/cache-aside-write.png" new file mode 100644 index 0000000000000000000000000000000000000000..038f8dc2a9ed0fca84276b98a68d6f780b8606f3 Binary files /dev/null and "b/docs/database/Redis/images/\347\274\223\345\255\230\350\257\273\345\206\231\347\255\226\347\225\245/cache-aside-write.png" differ diff --git "a/docs/database/Redis/images/\347\274\223\345\255\230\350\257\273\345\206\231\347\255\226\347\225\245/read-through.drawio" "b/docs/database/Redis/images/\347\274\223\345\255\230\350\257\273\345\206\231\347\255\226\347\225\245/read-through.drawio" new file mode 100644 index 0000000000000000000000000000000000000000..7f7bfd71641b9b8e6822b9368fdca5827fa92ddf --- /dev/null +++ "b/docs/database/Redis/images/\347\274\223\345\255\230\350\257\273\345\206\231\347\255\226\347\225\245/read-through.drawio" @@ -0,0 +1 @@ +7LzXsuvIkiX4NWk281Bt0AAfobXWeGmDIrTW+PoG9sm8om7eriqbqp6xnj6CBAMI6R7Ll3s4+RtMdyc/x2OpDlne/gYB2fkbzPwGQeAHhp+3t+T6VfIBgF8FxVxlvz/01wK7uvPfC/94bKuyfPm7B9dhaNdq/PvCdOj7PF3/riye5+H4+8e+Q/v3vY5xkf9DgZ3G7T+W+lW2lr9KCQj/a7mQV0X5R88g9vl1p4v/ePj3mSxlnA3H3xTB7G8wPQ/D+uuqO+m8fRfvj3X5VY/7J3f/MrA579d/T4WzDRMIJQJbnjPYAxINz4F/AX9vZo/b7fcZ/wZh7dMgtYxx/w57vX5fC2za3rFS6dAO828w+dyci+T/Qp8mnp7p5/XvLv/v9xqmfha9X//lG3dVe/2q9rQVd+PPTRhGnvcun+fqyJ8ly+d/uPmXNv/hzri+A8zn6vsfqFTkw1xU8X+gxlp1jwpCQJ8f75yH7l2Yf3ftZV2GvvjnFX4f/9+u1fKzDd6VAvH/ho7nv7r7SyLv7X6Yu7j9y+02X9d8/pdHcmn1dPlnj6z5uf5L3FZF/+t2m3/Xv79Z9dmPRr13gb/p++fmOsf98n2a/KPxPv/LA8cwZ3/f9z9Uz/J0mOO1Gvo/qZ9Vy9jGv6tI1bfV39z7tkO8/m2dP5TxuSp+f//R2uSPAvC//caivxHPP+I3Fvvtw/1Goi9OxGmZ/8Zyv1H0bwT969PTCYv8RhG/kczvFwTzVn4+foj34kP/Rj4X+G8f6jcKeZsj2Le5t90/Sj7YbxTA/HUc878e2bMzkz8p+7XN/iiG/m7HQe+iPeVHWa25/azsW3w8QPuUlWvXPp/A5/LVit+R82e92jjJWypOm2Ietj6jf+3Xpz2Y+/nzl57+Fjz+AIJ8fjr9m6LfwYTPhy5f5+t55C/Y/juw/Y7sGPr75+OvOPmXZ8q/wUji97L4d2gu/tL0X9HrufgdwP4czAzGbWuBvwoWAn2apCccYf7lT7DslwqQ9I9c6d8++E/JI338dx34kFK8x/xrZf5EdG8t5hU/++gE8Db1R61fNV7dgH8U688F9zdCWtZ5aPI/ZPGjxI/kqrb9V0W/700mfSTzgCFMvRKpHoNE/n6jq7Ls7eZPteJH4Pm7SP8TRfij83+lNu/nv9EV6ufvf46uwDD839C/0xYE/0dtgYA/0RboP0FbMtZsP+1/j+a9S5j/nq81UdR/pi3/Worvso3/ZK5/oRxx8sfjwD9ZqX+6LBD891sIxv5kC0F/sigg8p+wKn9OCP7tVXmIzPheVt0Pd/qLgiqvthnDUv3CdyYZ1nXo/qd49P358ydKvg6vNsfL+IvTfavzVWrqp0vyj1Lgj5LnOovX+LEPvz5C3PhaXLryKN06AJkvBvL5o9luybrFc6W+L4xIk+HzTq++jOXPhbsCLWt6FhJsUEZ/7d8gCgIdYcctGzEnBdMiG4gt2koHcDSvqKsw2d04vmRFlw/0RLNKxbZ7u1BHF/aOqAHN5soooAFmOCyb+JkPaOwfPFjxhz2+2P/8y3+9LcRzQX3ufteJ6OcmBcJ78LzhO/G8Rujns29fdF8I9P70jBTZNk2btH7yiMXLznu9nZxYbE7WmFVKDmxja0heuaQt6U8DlKXSvMmgVKKU7QSwpi2KqrqyqEMttG2RSbK2E0vaT7GmZiTulA1pn2KUrOXAFrYjipSeHbj5U4xE8Uo1bEE7imjp6ZGYRWP6108xy1Y0wyiW7h4J2TQmD+FRXJJs8xQ7gqkDSESyi837eBhTIttcNOn0qQ6Ib3HO+7MZUSLZXBfr9CoPiBLLLdtbbFFiURwX4LQqf0gSS60b5A8mJT3FwAkwq86blMKW7QbxhU1JalGw6KNJ9FssvJPmTZuU1KVk0Ztaadr6t9eCBx7bTBWxnVTBSIzytujGzbr93uzmV8dx9Ht99odKcjGy2x6FLfgns+1MzLuZrjn92YLUvH0v52N+O8Jd5eTRSs7uukp951UlSKvY9XQ3Os83NfLc83ZQTwJixmLfDp4+wUjJgbj+PvUooqMt8T6dY8Rb8m3Zrc5nw3PK8795/ltKMyIdlrjnca6BfSqsseeB0hBKZfBgVnue/zyFTmK6zNMeXYc6OaKSSN+EfqpTQI053H6j0wMB1HIybY3O8G6IenMxtzSSsMsQBWbvvZbvHbYSqyW0pXZGYNIUdqQNbO9hYpp8xhbOnn7A8CPnbQ17fVSElPQO8LKI6BIE8Jt9t2mY7zEAXLbbfTTw6hDUiu3ge1EngutIiDRxgOnCP2jaX5GefJLqqkexOAEinKHpK+cdJqOrMeEdgefSSEwfnwq/sVK0F7HcuadJt8TBo0tnnxOvc7epaavGWlEi2e1brQQL2d/OeLpU390nP1MOPqJMqUkdAo/qCIhRvzAi5v2d88/VvJmodLNmM9GBYAaEMUN00DJfyqY+wIxZTbPzJ+RIYgkobrsLBsjrfEK8C4GKxDhZi9VlokQslfeKrK2ro6T5nCQ+SVhjEHLjyCtitQ0KJ6monepzX1lvNIiDmunb7Gkj1X4BwzVNaAhbbcooREz4mrzyZ8XT9/Btq1cfXnC59+qyPjNm4jYhlcscE3N0cA+qQ9YNTwLaFBu3Fx7oOd+Gtfu3ygCSPV5yq7hNW3OBzkTiLkH4SEd7X2zwLbdYzwRo1enurTUsD/BVuYmTtI/Tdi5Y7lFoh6/qDEnZ97Zqo2psx4snrHTCA8Gm7OmcXdiXZ5+HfL8ZoquznktLVEoMvhPEQ3YNJ9VXU1zsCKYNe7bfA7F9sF5zCOSocYGy8gitjBibBrkyXvK+E/Rg1/G1zknj8TqVjevuwHl0+bV+dAbHQ1LZVNAAJs8qWF1S+2F6gixvPbUvKYfh2GekeXpuwoqW1quvKCttY+kenv0MGkZvm1ZWLu18fZT5m3Fyfnr3wzrDlHjHHu4CZLbolIVNhjqAj7C8ATi2cyQTBiqeTFplnAa85r4KZn7EWyzNdaB1WxKIDUsXn2cNR2nS4mIe0GgfK9OYIVxrIghKE6SYzySMuL5n1HjsPUdTWRAP0QNu7AULNi69+7nprdu2MoQLgvfxLm3TuB64WNxEnAGhll9feGKdUqOithCtEoph+kvXUx1b6uk6yS8DJDRLIWKR8Fy2obXzBhpTVyc4Iym0hXrjP+P3V6ne2QGL39E0oepQaKU2fQZHkKqoum/TX1FuDNRia6UVgsoZsxLhhCTXfH7+rLE1Z/fJt9DTrkQPAVHP3tfhMxfMTV0zWsBeTtTPtr7ArUlWClRjpLTsbWOkbNv6EEchCWKF67xDZaGVHidO2V8tFwr/s9bAwy5IK7padommvR3MRxW+5nkqc6O7iiSw17fqBVF7MMxdUjx5POXHQCBZMJdlzbZAKgEBwdIhUDgHgMDvUhImfCWrF9Mm6UA8RdbQ5OEmUuIUhQ0fF7vuo0M2r5OF9tSXxH3sv8icHOwqbcnYjk7XF748DaWIvgzvxiyMmphhYRDfDy/mnvdjxC6MG+TjNTSUWmAiqITms9O54cVkTK5q4+FTC8TDdMvHcPudwBl7uOj2oMnZEqpTEFfvuUwZEVHu1/7OKOV3rxonyykwLO2ScbbQwFr7EyESEV8sr0GrEsbSeVpFNwumEqijFHxU6tMCjZHt1j5vnWHJ7HlbBvPMpz2pPE/CDrWU2pBRY9p0+6OyUyRG/ZT6vTcN9QRBXTYD1sj629SDpOEutoMRVumc5S1ygdGWV+yybrhHpwV27Yc1TbMRJcYDY6HCxxJNoXB6tI+qgqB0aMs2WjuXKZrTIG+vPSv3wdSgjG5hi0m+QdVIu6goONdA0LY2IYdFAuHTjJ0F8Jm8b5wIzcDiWFRq9hieiCNOmntAEyj1DKlDLl+jFrQTJtlc8DLxI7HQKaVCtThRxF4C2rpwHgE391rezxgqFd4iuUuG8PtisPzsPHJyhA7R7QomkEPmEeXhC98SaENqr6KNAhl9yaLU1Iazkac8xu5d+bw6Za/1D77xRblTYisTVY9vjerfPXm8dHBZH10CRhmdV9SxVUlht+hZ5FZjtTiDPycCCp8Amd625ssIMneJyGxMl1qCSvI+qj4aj0iPu5FX9hPd7Ij28wOx2YK8urTE5Uvo8lCx22Yi1tBkgBZ52aFQXuao9GA5L5wCrbShtA8eqMHjD0OUk8mOZIARHiLp8/HFk5agtzrZXn4jRT2zUobVPBDBba5Hl3iq00z10cbZLS69bXefuFJerNuGMJ9tM19D2/WBGeWcrsD0BLZg2yTwY0KSSsYDrDXHBLPzGBLJeqNKe51sdhkuhh/ePVTypjH3NskampceC0Rik6XoL1WX7JLAoRCPKV3o3qXEJbB57WGjKNoo3yiat9o2V1eGKMXEdoUvv5gKEbEfmh/vOj9OpAeCXFFaXnbTbshx1sG2DrxaaX/EPjORaX6u+aRN5e1jmqVS0PtDNstr+Aw77sn4YaLmKYGw2HFQcL2uGLqwaW4yiLQBc2VNiKbFlxa9ozrjDKxIEf9IaAgEOtiUUfrpKMbEPixhXgGYLqaXsDhKSS9cqKtdnGtfxuYHOvf1dsWj29BYyM7v2mL6yzTCVx7IyZ1HZYaIThxhm4hcm/LQKIyD+e4GEG4xi8ea+cFmOPGtZHrMGEeJ0mISLSVArj+3iBUgLxmluBkbjsZuzBPNsathDbj3B+1r6p+BIrnqu5GQpQrBhETuBbG+HTHDaxhkxj7Iog/KGTI0KgyhJMN0x3FAo/lFYKaHafQayoI/VCDk3cYMKLtia/i++OssJwDw7t2rm8tk7AqEuRcbrVLCH+YoON3gmmkJVMoqlDpzXh+jZmlXSld+abbBxZGvGKjzMKaFhddSyTau+ZVJ8aUrjrzFrj5wmfHKEXJEKv/y0amItyE+zxCPGXUzU2NZ3Vzs0NLywaMI24rFSdFelr+7n6YzG1SgoUN+GFb9OnFp5UDvtqgex8ssBXPrH2jgEfVhtA8tfX03PS6VJlftqret3QdF9Y6gb4PhMLtZ9+sRiCmbUywSrUx7OSJe9q/+igc8WKy9ts77HNWUSKDKIj6rZQs7Riqp1QjYaqGog0VkmP1dkdtPHPBx1rq8fzUv/+6eWPEUh23iO+7X9XjAh3qWVa8U+PrMUrkTj5F6pjtR5rmCJSXJpPCKHoIeaX5sNvIkLOybialhn/UZgK3aNiceNxR6DVswx2jBdk7Uuzaq4DO0lheDoMLKiFrnfqKxCCMdrsYac48+0kAETqM+bCoSxKUP9Lq+2771z4axTAt2600NtFKkV+qSb6rOWcvdlRSY9CJsVwWehjHHR//x5cLgXspTu8eqHSfDS+zHnlIZtM99bo8MbvdTtWaGXS9q6QDA609zKd59vqr/8WmRwnHbdnLz6OQ7tw5SBamV/b5N+C/asW0jHeukV7OaP76UPuiZh+AY4dmA6K4v/N/wmUClRHzs3C+bbwyzs61b4ccbFKK4bHrATjo3BZkxzKHdAikqb7ytOpD2pJdsncrN5WzrtNLi1dB9upPJ3Pt9GlHq3oukPms7rXOBVj43y7mToWbDQtba2a5ftKcG9N2d1z0a1ucrgR8/0I1XlJ1Mf+njj0An9aUPFtIyx6t8Q/uwC1OKuMfzCMvevY0tym1Ri6M5y/UFl3pd853TeDdmCnshLb7+pFFkhNfx9ynHowd09IdJb4FezXNTbGbV1PMY/GKkEdy/hOF72I2uT7+ea+4Hyv3H5X10mILLiGalzPTHj/9gq+TxxgZmUrGbqHpyfQLmnmV00uWLJa17uGF/C++rho6Fo3ixOSLJFl7LUItJS7xz05AFtE+rdKyUNrWneVTPkZxHX1n8vE5rSGmdAXhSkAoo/1IJer5F5PG8aDZS48c59EyggbKEYNPA/Uzd47ZSmlpxcJs5UNw3uPiA91L1N5UVbftQJkucb7X+JkszNWBU5jA1G4fEDRISb8e5aCo2xTb2oq7ZVEYA/ZhlHUOXdzQA5Jc26eZ72ogARkPviJoxgD64lAirYW0g++N39dztKKyJkpA913rfPFYdLRWFWfGBMhrA/n6q8o0NsWlMRSUC+MV8ykABZNYWdrCJ5xhpozNtXxI4t99IFr3xWN4xskTQxk9vAGzYZaw6qP54l34lOLgx8+Agmutjg+NraYqc8zb7cZHaK8p71vERD9bw0xqJ5dUdYXVqG/U3adR7CSUK6ySL13TeCW7QWSqU7AnZ5wMiEjd/SyXcbT8Qrg9tUXVFkWUpGVx5pp4fei3umiWnqAweGETYh4hgwevBvoBTKjO4YA3444lbNMb+6IS6zM6z2Ripig0GRimmo0kFdR1cYDJMIRUx1xrCo1kSkXT7BmwxSaGVfHeZ2Vez7dPSL4uzJMzhF/XjNCpNqWEfT+06hkl6i87l9WXj0t1syE3Bw2xGeDvTehgHL127NUWYSygT9aO82b6QNHCdZ71ubeahLtVH5ZVK51Gwxo1+XywAY14pn4KQGJfh+vfTxvcz7xfgxcQRDV7Guy3NsrNBuoTaKZP7ZS5BsW2vtIySMyQxdnPYwnoNTPfMFZFYOtoHV8zLW1okKAfO033aX3v1s0ZBhvVI11s79EHXx0hA+9gfZXvp0WMoHhekzbpTFEwgc2VDJUZ8GHC9X5bH4feZ4mrtezxldHzNAqRFjvuO9d6q9qWn6ouEGAJOiZtLVb5GPLBXr03CVEMxWPN82CTKlCet11zGnCHjXT42+/tKSofU2X2dBSWSFsFVjEP3IDIdhOiCGkFPWOTgRGyHz2x0uKkXp5KF0QAl4LQkKjlkN+KIPDoYrRfcJAmKdpQzZGS+aQ9XegMnAE8kVZ6k4WlT/ex2n+NOqpE1sqseqIdfTfCYGKyNcrI96Ux9eT4L5GhV4ZrQF7BfkPSGBfV+DwNt8FGB1hMXDFJxXT9xB48koced1RuW7yRy0hu1GNZ5rS4nu+tpe7Cx2NUixm/JF4EB1/bbLVTGkC/X2uRHewlcM3tRTfiDuWXXEYuKdtxnKb1MfV5J3QHgUFO/IRtPGElTHFz+0s9wf5FDq6uglvFltV77z7HslvbpqNJ9J1K9fgKljtaJpvISSXKooJ9oac/yuICoxgrmCc67tiJW+43vFCv4T7RObZOTK0cvEh+2ubaWa9/ewaAW8KWMXSggcOPaDyy4qUUjDzsJvjpEiskCoQ+7LBbstYlbn0AcaVXCNcm+WhDsKGnHEE/d+rS0FDjrD0G5n7l2hzZ1kxuikfYdfMT9IU5JaqjbO5NmZ75ps7tSDycsT2ivYVL5LIwbEC+F7hgxK2esh+F4EXW9NfbTbC4lUJxnHK2Qqx0sMPbdNHnLK5THiiclMd1xb0mw8625Fv3JQeEHkVs2i2BjQGSt1/dAM4fH2BOdbeuuI6X2AoO1/QXCcWZdExc2UdJk1VrWW5KE7weFrarVvuphimlKUk3smaN2WuyeCZ1mNo8N4XsxzDWwTN+4C+MQtn3Qx2PHXJBHBJnj36BsDvMKVr4yD7IXWMYWeIP4S/3MjLvpn+AqOdnCgNbC57EnsgulA9nn3oelemhEM2oHk9yarJ4Z3bhU2RBs9HdLXgNop/MrknqyIyl35+7rMcSXdMTImEhkWNDdiOE3lmO7nzSbWgJDJ9MiF6R08+RaJ/oWNlb1HTK5oDo2hvEYouTEjam+iwXYRSvyNr9kWQTTvigKyKwU5cq1lEfwGl13C3wo7lxGP0wEQLStd/F3NNi92B7lj1qjPg7FaNG8xlTpIies2JAEKzRSzkupcdFYJo+gY52xf2qNHD0eh/Ex03TtXSCXnRkzXrnD1OSoACIEqXJXFluM+BwpQa1O9xy6DdhnG5A3NsV1sUSDx+3gk/hlJlP88rsXblZENleGjZe56abJGA8TIrpH/hTPm3OGbpqpAjo28Yd0pyfP8QoLmFSjaNSKHrc9GzwSkXI7MORgma7kL9vXIlky+jBuZzSu5YbNUC0iQMaxi2BgyeaVIEY71VgDO3ggwNb5BUiHo8v3u6cTdQiaDyKSJRM8bvzGFZlWHfxXiAj7IelcMY4kRGuUVrwCfjzg+HlMYtdWYo7ycBqPlRsv31A6p02JjJSsuNwAnSOHsQpacLFRLENHthrB0wEWeo2oqVG7W6ZSq+v2wU5SqSpktk/z5KyPA0Ge9yk5NW1GUazaSeZkIsX3VkkHMcNzIB68zoomSitOmSlqq3KPpf1EZtiihF+g32VApBTgtgF83WPQG6Tl7DdOiSWEXs6ESFcIOCnE+vIDOnTn1NhkfH3Fz26ZapQtcn85b1QtAOJADzzQIxFabXedTpc5Q3Lk3TLdVBCSKKZUeH/o7uEc384cHL4VCmVXYqdILDPBi5/4CTZlaKN2F8e6ue+qflBdAZfYj/l8d8jzCJKguWcr07SmroD2L6kFH5Clku/zoiffAMbEUATZhtXT/TydyLRtUXIpZw9mqyKlZcPRN6ywzCJKPuT6PJ4dBZOPH5Wln6/fElHx8MMopJxXeINli/LyejT4T6VBlFh2ItF7AhGQfFykjEC/vgeEBe2JEcLZb6Xi6VHf8v2nilpIUqMO5PiCBvj26X+/xPhUYt2K9sgQAWMieU/iti3d5/itYlJyoy70+F3fczLBN4LPU8F9z9o80sVB7O0vUbZ3++6zfOk/FVJ5/GrH05sQGAE4fvmQbWzeJ92XCWBvb7OwvwT2qfKeksmFnmJrrh0GwYBhznwq75cjz6XvqSppu55uySgdiuJ7qvtnCQP/0wP4fzuL4Pr7VIB/83T8PyNn4E9Px7E/yTDBfxJC4L8mDP1/Mxfkz7I97N8H+Se5hP8PJfZHggPyR9rH38gMB/8XZnlA/+9neaDQv8ry+LNEKeTP9Bj7r9Ljf8eq/G+b5eEAzV+zPDLsgCyr5xiwOijPYYOWPj9HOFHFDs01a28XBy2qK5uv1Tiqc8LDYatCzRps/fqQmEzvoVbR5ui7nLC8/K9TlVcme4b/BKWiFo7g7+PHnxCOg879+In3GPX3dhTdyR7kurIhmdXhYauHEloqyxGZVVGKRR5mcKI8yTqnlpNsWjIHo4lCh2zrQ0ocieZ0bWZu1iAptWfu2PWf6UtLSQk5WqK0VBR5UqEgK5oqy/pIVxjqQVDsZRoamsU0KXYXK6a4L3SiT9OoLnRusVIHaUWVrH5u5nj6IAmYOyfRrEKRXM9VzKMSIaVmyBP7AljS0hoxxCHVUJ8+hCsV9LG0qaKobhaw0E4oxId6oZsyu+bbcenU8UGczEE60kFAb1yKpBPRtOAtzN8+3sllFs0yFMVt0sDcqkFaasPceeAXBf1MjhZ0sEQrrig2p0RbUTHTx06GVW2kf0zugjxo7O14Hdv75eniG5ImfjhDCcwf5T3p3hoVz87ASOHvGzKUPvsMGa/wzoGWmiIOagF+g/7OymaSB6J3DzoTAXIdJUvU4yOAIfAGUnkN5xe+ucz5C302zExscGiPyO3ysUvhZ6yfy83egEaL2OkZr7UrdjTTU7obN89UMScszYhGIZxg3ARpMHuz9yoZKVj9ZtpPpDACCg2VgQhJXfui2B7amAjta7JtipvsbGcDnZRH0bYJTVqgYDtYFajZ7Tb/dgA712GUoCGdZ+7UZeg0ZmTDQTRmk7zs3G8kM+fiIBgchB2EYxYM4PoJi3ef3l4ppbzFVMmOnSti5VkuFhEcr4t9yIGXGwGKNEqKXOlyp48htagJSWLaIJJ12TNed0EJ1NIm34g/ZyOESn6Mad4Oj7fhipcQzFqxwkZnzGQkDdyAFguTdzyRnSELFoOOkEsuHUiK/cuTehdxJN/RHd/5IwDF0n4DcEJQJDZtpMT8jhI4g8ln/9dpNqoAKBqw/KUs4ighQEZpOoASh0CoksgODc6ObG6XTYE9zsh34waIPKLPj6haEf5qIkUW5v3TFhXrYqFkZO1IGelJESu+UNDkClqGzwPYw3FBxTajt/I2NXyJmzcXyoRUnzNDtXOVSCwkILWkiqfIqs0xfRSNow9mfg/MLE0iBQM7YZpu6NNbJCyf1IebBWPm5JLWjg1pmiUiUp8OSL+coC5OXd9JVrnzGsQg8yhCbCvWqN8X8c3Nr4Mavt7wiPP5uAJOjFis20Ypi8R36Qwv3l34fOTydJe32CcaMIuACQLvYImWtQ7XtCA4UPJ6ZzhiyXmTZGQ8GulerLrzEe5iW8K+flpi42MtsvcanVM1KW0Sq2MsPQCSlvQr/YEjabY8H0ORx0p6z8KcaifNy6I7e/owHbGm3ba5spsJN3244iSTd8az9rgN+NiXdvW5aspHE2zeTtoJIdaPvM1TA5/+puEbBhb1JTWdcVG4tpmLnZrDCLfQ4bQZqBUKTsWiyXGz3OnC/vqo3Xe0h9RtPgoldNvI6jwjR86ngux6ZADIVcAtmlbWJzmpNt7Q5uCTecshjHcN235OfsWKi2cS7HGARiNm8tY45rVeL0YcLF7SlSBUiADJ7G1pumbMwsmF4jHBZmCmxbWo8KnTzNCBBEUhX3OQ+QeMHe0l2eQSfm2y4cN2btprDgKqV44wfcbgM4VE5LRdtHw9B9oqAGV20Wg6gIdEGeWd/5gbtQT7mncaLvCjmlZOxBSYUb7MT+6rnyAzTIh0ytbm908vq11ukL0obgvMsgTlKlAra/5rpmYbGa176tufU4Bvd5EG/cbvE7f4XlnTLeJsadTBEee4bR5vaO/eWB0aDWTjjqh0ir5DV+2+OZAgrp6UUvuuYDQmRMupuWvzM2etfp6rEXWvbUK0Gk5lUowmOeKDOiz/k7hEETWrLv5VA5D5AdoqCDo5cL92BqqyzhM3rdN4cn2h8s2M+KwAsLjXjT/zQx2NIXFnK9xUmCCg76FTpL5CPVPiyX++vUuT8pYwG7kqnzfrwzT7TxXOmdawDllpGfbtxCiCCIYMTuHmILmzyTEWPRxioTVr9qWbtb0wKVh+HUj7FDSxGptC9ituF+1jgKWqO5D3GEA8QUluu2Iy31tfaevOzveyRFHF/fEMw1tONJa9itgI7SN5Tz/NcwAb12F1shag96B382MapcXgKoWqLnXijZWtpEgugfJ0bKOZ2pCyLmZ2BqXObJoT6cekXDSFlL0ZSZdQWdBxmCMiUSFlL5IYjgFHhawW85NbLfIGQLFINjom7V78UXCxdbv3FKkBMTsSTZoEQdrxei8EbdddlIDQvMjwhL7g7a8meRs2VIQfl9zjuo8d57RDKbFjBIIcwz2L5QCXqRmEei1QonShZ7LZBfLOSF15Y4qy618NsLAD8TWyGXpV7z3EKnaMV1/8FyimBQBeb1WXWGfVCjkhNt4jOAetvqh43owh8nK1x5ZOizRNLW/4VEaAzZFFeML39M0nXWdtAExrKC9+gHfmI/IIcprZfJjYJ8/FfAxq0rt9m5ZUUvJ59bNA1/4q+w7J4p0ssAtjyI1zEgbu5vieAsyoA8nakYWGASaAhLwJueBPwFbEjRfFlzewocvHjJvoFxPs15//BlM1sjucYInUy1UwvpO9chTprM+bUOi+/NAuKTJ9Kc3lgwYsiOJRvAQFO77cHn7hRP1GZxMUSSTlytCu+Hx0RsoGm2lLTkIbJ6czbF/SC4FhomnrTei4N8hnn4eTUAYtsJUJla5YV3mfaDVC4waIRGw17w5HsfvpVBV92hZeiGAbf91SK/jM9oNWOuKIwz+3fjZuZ4tSYp9qoy1vIBOhaK72bsjZKmPBwppQ/VdBrQf4xs8HZSHz2QMO/ZU/gxFngPpmF3iOWdjNWZfu9SBw3+7q4eK6w9Udme6oEfqeec7o87J+KHYhKxlcbyFaQ6l7z9yTZ/P6OGZpZQu0n76VhsFC2V71K4dTbg3PzFUylKrvHj5UjHHjAX2lA4VUXBY7BTLhh40cPYSiPdTRlwBJd+dQvtyPmLDVQxitRdPokm9HMl8ValaOdy88q5kI1H3K6jdtrNYOTx3+pGxdBRqPglsc5ErC2W9tVZFuGN7feHBcESnwwFcqWtJptFuv8T24DGmThMNhEGLFIn0ro28KDQP1w91b+NgWnYlFoNr4WfqpSM0K55HX2e80Fm7Njv3xtcSEWYIbaqzwpYRhiT7smCrCr1kqjfJGtfKjdUcsuOxs5AAgYJZ++X7ZwBG727INnch5c6Jq+h78GuZhnLWJ3TbBEbpv+OE1i3EsEfWhekNTgWJLJzbljklGbCLxX9OptIBPsjLVc0mRaS770pzcr5sRuRHKOwYfWfZyzA9AV/Uzo4/CHKkHP1J+pxJJxiggoJTqwuShPhO275WwomlPfChS4YVZIOKRps/e6zBN95EU7gpGIhWWLRM7EmNXQjIV52XJEsN7BUJdFAMuNiUpjkbFFY+7HdFUvYeXB/+GUDukOWf6jYyNLmR+59Kjj0AgYpG6B6zkGGJoa43ALjFnPDoNakTaBSqTtK7oDht3vFX4ySNqeLDjVuVrbbgBqdA3OOWb0lv/4exXOjz4K7HZog0EU3HmG2k0PTu4vH42zs+LFgYr39LiBB5P6Q0RbwbAYyJb9EwaT/He31p5WJk52xvT6bTGYmaWwXhoVm4kxBLU5mmD0jCf6QgiNZ7NPVoHG7QRv/HdaEkv6LG37EDNvlNszGAgD6j7tky9WcXxtn6nOH9XM1MrteTUxqIJ8raWtkGUhcUnd91Es0xmBhgN1uw03V/EyyD5UvUdhYOHMKjzeqjLixTPZyZMY41SahMoSgYtAkYc63Glrh7VHTYBKTE0Kz6O7Lfc2JwFDJ4dRwhUCyWN54dOcN0X5nuFYhvyW5VU2D62XRwxn8ukWPtE16UdbpMC9ZhGExTTEk/lv/AIjcV0YKQccgDy0wshTqL3ziJ0wK7LwdopjWksjzmJmov+WMI2XToEHgsHByGNmFSEhfUM2hW7RcmPc2dH1PbunGRqZB9UCFdKGd9qzYVoNhmpKSwSya4YLZmd9tw8BXCbd/5MNMIs1DRZPPCWwVHcstffG1iUKAMm3bZc3lsq9TJZ+jq68DVQsyPrUIzkvAfLzv/0UUsmpU4p1ONmHJCB9BPgFFK7tq8rClcB4pFHkI/TDb4s5KC9N57xEJ5oXxsJzxH5PIW4th6kIGEKi1GeW6TTFiF/LYHma+91jz6e+MZKXE18NFlLnZJt8lhCHvoXfoVNmr4eud9ljiwGwpWsI26UZdAoOBNmytAdc6PUYNeuI1H+2RjE8eZuc5rCbROvjX6QigcJsHE7UZCLwYisxdsiH4g01KTuaGR7MkMcguOMfoFOPfSOpqOD49WNPqscnOAK9sUFQJa5WqoTrP0qjUDrcfLZAH+di4VsBXseY9PA4lBUyRdpqvlo9Ul4FvPB4epC9Zp6WeZOImElipL6mMqqVM0TOmjfv2sRpgqRzV/K5D178s1aoVDNbSyFu2yXM1lsrjynu6mSVcf0YOXQa0YUg0sSaMks84WDr1iUpKH5Q7vXgzoeVbcWIc/n9xsk/EN18k9wMTxsT3T4Hgww2etcZr5+bKIL7+dCSsoirSVYvdQ1uqkCvmOs/QKsMzIfv4CNaxzWiMpIaXCo90s9DSvLZi0gXjLN5f4KXHuGmec1MvcIWDBIwjFokZDKG4nneKk9Sv8OflKTDoF2BB6q8YTi+0asFAJZHs+uqqTMRJUOhJFO7TDerSmF5ULHXLtidorS8T6mTsjDRMo3yrGhRqQ1SakXRTr2Bg6x4g1SUynB2vI9gS+NGGhqstNp8tkS6lzWz+HVnZF9K4ctrXnGwCRTXdbutcfMaefXa01/QybFtevNQZUq9wdSTAnS9Wh9/X7PL+dxaqRURdEhSS3PZa7aAItmrllSvurcJ8UQ7YdyU/BNWINsTvGgzqon1PE66wRRWyPZHVhytHqqv+7IcpS0ujabn/G6jj/sj4vW6y5ZK+cWs9409O52m30sho0y4SlAdEodyfapYxOhtapFJiwudfDhqE/HmuSWizzMvBrAydl8iwfytFkL8o4mX62qWq7RikbAzcr3xo/NQmQESlHutqdFk/yb6KEkavl49DHU0pacoPUbarJYIS8hmE0M1wwfjpQpso7T/Rgi4ntqIou+mYyZqQ4PKXxcYpVYaBONG/TNQZ6F9HtuYf+wLlIqcFQDYMQhIgp4/MtvZFIRlNi+5xu8DxnPUKqv2KAF+CByQWW7jXqVnlJ3cBngxVerRU1QpZog+lXCzVZ4++h5s6RLr64zBUtNmpjFQMSsIrMTgR3DWlBTkJgKu86/rupEVDBepd1Kiq5jdmGfGeLU9C5lxeu2buJ5sekJyiRwDIbBpUjd7U0XBjgwb9hitjRI17MKSqtLSCcsSRzgVLqhEiaajHc8pMkVfHha34yh5yz3y7vM19y9u9LBcGT98PHPTp01v499/4nKkDXdPXNjC/vxdAqmzu09OSzu9aC+oC7OtN3fGVUK3pufR/m6+ZPMck1NYC09oVgkq/rG5gT6ouU8QgBzbFkK3rw7eq4EKuV+uE7RP4bTaQ9MnNnZ0i39hhcwxc6ceMk6/r2J+jwOGXUjsbxhg+2NabX3YPUhU6ITm1e0XEYjnUaCLZlbu6iFJU9en1GZM1iZH0+npJkPcRAsxJW5we/irMNBKCFJAdv9DECqNpU2xUQoLw5IUJ8zVNlF/34pw1mGcTwOvKcbryhopj4NQ3FNkYofv8NqbmiUaeKR30MP2EY4qHArfxyq4KqO1Dtm6fMNXFbEa564MqyPf2AYWtnQfuMInKzujid3Q1BfExe5d6HDb6ZCF3C5AH7MyrQK74OR4K1KZx6Xm1kXev977gqIg9joDe2zQ2yLsetnz1nnewwLp9qFKrM4CGyeQhMwvyO0TcSMo6boLkr6YHNh32rJxMXi1+WWPrpyR1JNF3ZZY+1sNbO2wmdShdKZnrluXp+5Zsjoqy4qGF+gMWgsQmL2RxR5V7GOgGl6gb7HMvenCTQc71EbTBIQ8WtHi2H6dyq9/mby7DsGwl0Kzl8CvSFbHLGsRGPVZPZ2MBObQnpxAI7PjiE/21AI+7cWi3IbJHlkbYte+rS4ulJRnW/R3Q1IZChZy3qvvS5f5VRfIzVRsWx2DPhQQlE/OFb6wKgCU6SzD5W803UjFltcVIwTBZaQ6e2qpaztJn2z+P3eJjiWwZhn951fX2vmZ2V6aWJGDm8M9JIsnUOfC25Fp2cybxhSIulwtoFmZkW/V1ubStNSl0PXJuUpMIuI4gRHrmyXUBfWT5XgzTAywDEiGxm/fTrNK1cimof/vbsNjimhq1ZiWUiHMy2wY5UQKCYAz9yPokk54NX92S9uS7yn1ZU96gbNWjxqZbNNJ8qU0RbBKksn2oxwA8sRiUJ4IcbOiaVF4NpKrjwR3puEnoFYVMe4HHu8lJf1ibpKNHcWFyhbZ8TbJKdchs6ZNcj3a0YRTk0i2XbYqXMErkMu5Bwu29sS+2ZXWbzitiJP05LIeOq17R3NyjMaoQUR+9d51tA29xsD3G6qE4ItgTf+xTov31ieg2ZwxJEWabvjWTovCvQyfc9Y0FxT6kmUycdn4bw2xbjDUhulRYBNH97zFrfwfO8egvfsYQtqG8EquiD/Txv/rI032qNKxElyGTONP+kDJCVZLsrOjVQUxU8CwX8ghwD6J+e2/6Ecgj89e/0v+4Y98ic5BNhvH/Q3Cvj5ZRHmN5J9kwko8s0q+N83meDfL7o/kgk+/yC6P/t5kf+yVII/Edz/6lSCf0H/HakE4J+qM/pfpM7w/49TCSz6b34wIkeOr2cFwo32a1JV3RcgXTc4CmkSBx/G4bv4pPyHFV3Hmr4ycz3OBV3thRhTtjZUVFysAu0VQGjZs09dpFWpAjwAwUNJiJu4FtZrjJkEAMDoNNLGtfYx2/BjQyEoh/M8O1HYeAlZs0Mzip74vX9TB/p2GYzcB2IanEjS9vU0QIayKfItZ5IFRIEmQpIySVELcxWkqZDCwL5ZrFRAslecJjszVc+8R1vWrKhGOJJ9f4gAzhmPNV3SZtO4dpRbNimS2Bp+RpCBZEkM6Cq3cwmKlCRDg0vwTaIEZop/Q+b7Z0DqYdL6CPLTk/hw7Ic5Xg+6WizY/bAbWr6/IkbVA/Z+YaIbpzCPvXoKppAxqdkEN914TyDRqL5xDNN79csM1p6S1ei86xS3oBw2dhBFkKo24yGSkpwdUVKD+Qw5RUUidVio7xfPOJH9aqW4Di6l8t3h04f4fr+RC6TIIkXGXdiAVrmrXhPMrFhkjeG268cr6yMgZYbUaEvXScOCtEUfN9kZTUiVV9/TAAFIHo/8IW4v88ez5mM4wK3r4Fa6PknZZrK1LZn3oVTV56hOPiOeA2tZq9LRa3Lm5EAiyUSYYQnc/M3wP0FJ0DfqpLjoUCAP3sDaMnlLfYqmdaiqWJ12OeT09XYp7M8zI87QPNVBIo4kCz61LzWHwXzaGJGhhFpxoU8ZxN27voS0fPmzivtxeg9g/JzHZg+RC8lx9104iVTjLeB50aM9ctsyCC30WVL7ZdEsqAwKzpU62WqUJece7t6MyimHJ2Aw6PVqKRDfc45BcXskQroFhaTqYTB+FmHHyMqR7z3P1XksNpUjBYnbASvDkW6ln3MRfnRPHEAzYKghaE+djLSyQ4ectav2rn1On4KbCDUaGeSFPHk5uc8dCFyKLcEOWTWAfUgfUBxU08VgSmD0nqwkZkAFK75BxPCNpVPbwI+J/ibTXqG+gLlGBdplZwJj0o3gJKtfm979YLY1AGRJVvGmFzOEyp3QzW431k1lw6AEKdfPYQ4TFkZxY0FHqJ1WG99Jcq5sZULbpQjBcKKEjwNtRnS+XjibTPmvjUSL2K9wTJ8sQqkOey291EXdd2sT67nvxAkU+5qGaDx+cBIFgx054zEaoiTOul78TAbwVlLVy5lT5FVwLIw6Cv4bAnQII+9x6hFr4qXWPJ7t7/kUZpxdMmII4al5OZ9o4vjbR00+NrYVQJTDLHvE9M546/sF3/N6A1YhCnxXZTB9fX6GXMwwWCjqhWChwXuFTJtv0Bk/vIJt2feXH/TZ8wqeMdGTCOlrnGCZPrmQKgA9/fDkoiTqVTzqRtK04I8NMZwyvafoaeJPe2chVVQPUix3FauDtS8mLzRnf8xBiai3dZU8YtJI6as0aYg5l5AE3q8KwD2GufpMcK/ngrPMhAZFBI8DqM684/jMUJjheEX3xVfLgzyNMIHnm6GwuhvdefHq90nbXmgkBHmUyhdV8hLWrl9EZR04iiJexGOAZo6IIuSEChnq8HxuLciiVLqgs8HDK+c6c11q/nqYLXGfyw3Y3+8Lz33ALaU680Q6Cs6MA3yw9UACFVlZVNEexSA3KPrSLMQq59PvKRCjO7QSKVVhx4xQ1CUdU0noNyp5kTJ9ldziTAI6e1csVbMHznpwR7RlbFgOmiUXWeGoIjxvAd0bZgyuiepMAS+AffQJMS1IbtXi3ZGUhoJ80aOawhwKuPv8ynNpURYIG5qKLBuRQ7xeUbt0O5+030wAzgSeTi9tPB87whUToYt4rV/wwnSlTdvM5/s6pnurjbnG9Yh5cAn1KBh4eVLYY6Wblw5tU48BSi3AS5XIHHtZojTSASBtT9jhTVFm52Myr0dG4aefitt1ZTkmwX6qMG3Fp0NpOsAC8pm7EBPg1Go7tAGvsVvD70AfKIosTyHq8DKTOAU1RXmhb+FEOdb93vkAwzhim7Ltok2LlWf06xkxpTUie8FMDtPvm1aAeqQvKqPYfGWOdIo3nCQs3/OCFQzvVUZkA7d4CZPz2k8nJ0xiWj3SpOzp3TThrjcyKdFddtQo5+lk52ScG9h6yyltRVpkOhR8C4dDKn3fw+/teCwV2s6jS9nMFpfVnf18J90E+zF7ULE7MfAWDqYK+nwBBJPrjL6SxdlXULEn+RYjUPrrHm9TaUZRFPoOLckW6D1kcNjTQchT7glaQ90HoVtQ6xnkS+eRJT44CK+iIV3DQuZRiwRWxmrtylKV7Jkq/24scvxyaXSDRciSowF+rCNQZINax8zm3jNf4XDuziUrErVETdFPG1GOiiaOmDlsQhnJlaSHQgChcBo0Za7fMJ7XUAgpuxxb8tVjNvLFn4OJBTco0VrHbQZypM2SjaOcSm9muIn0FQ2/2wDCFJK5yKrkTQTJ+NuiXP0UI7Y8kij1fm0B6T27dd6vBjCVvoNltaseTVqMQFbae1xvjukU2VhYF6+Jn2AC+An4PZtmYqlWaWWaBPcZf/GyxUsCt1p9cceBYyV3Xpi9yqtKF9/flAm+vby9Ya+GWrpzVFza3zblkVVkshaKb9MdbClZ1jUnNxp30mVWxI/d1YqDJ1/c8eG5SUj2kXf8CXXQJv3X7k6eMhGVJX236OrN63ysJb/4zOQML1FRv4YwVBV2r4C92SLTcNd1xK1KOQiq3yuOhkj2nn+iXrTSdljwZjNYbCceciwDcI1casA0IaPeuIjuGGlTGh7eQv59+K6Mqe/PTj0WdTVFk5vNB8He7yYou5/3kC1J6io/pGmVyyhxUfA9I5pA3PokXmGSsdcz0JhsiTfPjNvZnaY/xA55OthwcJBTHBK6hym6iY9Sc5HJbEgDu8hpbwdEKe7DwvqQiMAlDKCK0pgEedlsHDwIdCjHF5ZOnQm/TBwS7KNluZbom9tjft+gnxlDWEFGFJO6ZAzeh8B9YMW6BQ9eU5lkzk1pdfsFu/fUVBRWK4bB3goCUMdmUqUbcilDKZoaMj1RnygUtywK3Sxru9L8hmTl1Ucsb/FqCY2fXTtLg2zKZ0OspFhwBfjYtPDK7ZI16TOuBnKJFMm8VDJcPZfkxbZBMp5U7WkymYevhEZt0qLnqVQleapQDhQrb93DKObOOQCyonzHdIv/09c/6SsGKFTI2Ey2PNuhL3eilIItxh4S8tIX2/t/tHdlTW4iSfjXzOsGiPuR+xIgQJxv3Ie4BRLw65dSt8dju2fXEePdCe86ol9oJQJlVX2ZWV9W5gUTffTxSseFjhhXYLB9zMz08E7VE9r1ruPY5VuRPYbtTIVnJX48LO8CdwjN6bnE+yBtagRrEwDFaaIXc7cuNiP3HTsTy7v9sx27CymIO2yKKPB+vi2Dz2zcQ1GVqapMFTmh7O2R90F6tb0beeC64t9i+LpZ4g152yjPJ+WKJ6HAo+msv2zRPHG+rIMc2XEN7tn5ubxJvv0BHy6UsuSwSarsOa/0VEersq61QkMi8qdLPp7xQPn91bSYuzyqNcB9O219MrJSScn853QhnY1FwzJTJm+ZOSzQhSrPz4gQ0tdrXZeR/0CIDhBXGraAFzUAHmkXA3Msi1L8jIbP4iajZXh9VmsdNrnLWSCXiblgrFyY6E1p85q0LjFc1Ah1+CW5mMQbETDbKDD0gMUNTxleZSeX/AyxPC9S8uEzXcERVwaGl+VwR1q0FiqXHuTM8rAWqzPv5m8+wJryyRjdm/oEJDy5zW50blTFyBFqPDMrFagwse+SwgKHydV2bcdKBs2Ym5By7hHU8Rg1lzW33lIph5/ZbAWOF1zavNtUGZh7rwE+Kb9WeYo/LOPA6TJySyGtdd0zNfkJuFfBOzUbDYrAeEVM6pLUdbfV6AYcZAr5Qnz3TH7fnNuwa3FUTryKC2M6g0pbYId+bBquTbO+rf359GikaU+4KjnXIACJA66wBfVeexCj0DsnbFVzbs/tHR3cnOcesTMOKWbqR0yzHqZTo8fZn3asWoPehU+i3IoIMdOiqdG7H+GI3iYKc4qmcyghOjLBxAWpH48cED0KZviDL82FtjdiEJfugdjshuzEtIa3J6+A0kMsKch7t4ijc3gfO0/bcb+VYA6WRrsWTFUeb0jqpnNrwETkkNzt2JiPbblw7uPr+XhqKVNtVVi5uM6gCzlq9e0rmKeV5uzdJsyv5M1aNR9BrkE06/2yBYw8uiRbGzGEN/B0s2qsnm1NxNY5CavEuisV30C5tJN3XbIc0wAn+t05HOxy9tT7APScHZ6QMfnqzUOJyiu2ejEmKQEkeqDXIl2rfgoyyXxvPeLCQLjFFsTqvq8vBW+Z49pgBWlDV9HQpSkoOH7TJkATvQo2g1gIYaF1UkoRKEn2aZetBCM4BdxWtd6EH56nH9Cy7Jnmq1CP7b04EccIp0/xOrXPyXMboOjJhgw6YR250Pf5gFFACOtjEd9a0TBEd8GSxfEro565yqMupl8rT8LfGBtPAzbA53OekHDarZs3esqlVu+8Rdcr7wWnfTXRVRFI9qpfrEaETq5EIqIQs0mZzDn89mOO2dXQkpAbD3d0SBfEKP79onWIhc4XfKe9yzGdTleIulw1CL4H6p1pLQ3iNA3G8/0Gs5FKsHLXoHSSUutqobhWS1tWCcQsd8kVOpxNY78ThvU0yH1/bI0b1ehjOlyd3TQ6rdd5Vxb5IL8JE1hVmG8Q3PiKIS1jOlTD49q5eEbbMwCI6Hdy6FxvmDIu043PaaFh6ZSUas9h3uI+H38dDhg2jMalPmwmzT8tFIStBnz1exUerw2UmYdEdEaNtriz9yrSvdkj0nbHkP7AUcS6xjZwsAiMQag6OBlXB9YBdSxFSHlRd6TQngN+zJO7WRyzfLjwx/KXMnxZj1C/muNAdLi2iFWjtSngEutuA4UYCFazhFEuJ5jigyobJ1eeW12s836DCbDLWuIpTdrOGXfIVi40RYxEdLGrWSzr5nG50H3lkFPDh8rrBKp2btAlJikyAKW6urNHYmWsPMVwJAj9CN1jYEvgFZRcdZCtBIkwNci7hIToRByus1aluWhm+gbs5m5Jm9pkiBunDUSndFX1z52g9HQ3FyY48Lz1tZjHu6SGrPxQ/2mPew/HMyxHUwtjBEGcuF7iS/kMZwQEdt+g/YGo2LDkWHqKs3G4Ri1rKYOfQ1jSwleGpO+9HV0tEtqLlGcvwhAeq2aXofVMBRxuwVTnPxm+YMKwSeA0ZXqaEdiH4oW7bVytEqHRxCsmvFhozbKfZmCIC7Ua2mMNZ6Y7pWizm4xsFZ7Ai7EZGUGHrk16OnELErGP0ShoRc7YQ/aIFikFLFF1ljhzUY/AE8w+xqAWoqNvtKqyVZNLAf6WFiAFSMaBswCHeJarT3oYF3DdFXW41Pdo2c+9Sg0ZLSjO0wd7r7FVQNEIP2RW3vftlQ3yoO3Qm6HDJ616DtYlzhqnOGv1jUjxkbnFkHaYxGyOU7a4pwb3GM8zYx9a9valZ0TuUSqgOobK6/yxFD3OOuZdrAxVYOr0mTdHiLyuL7lajcuIwmw4vmrzRpqZQVRGIdtE0uxHHF5stHwBWMZbSOJNEbzk68pEy0ofy/fh1wPIY+wJ45YM+uH7zEd0v+6uaZDemtBypds9NkN9uopQbdi8gKHlYbWL+UFCaihtbROXhQHMXSCBKiEF6tIsbTAmAnyJGjrFdcuENVFXk/bg78N81ZVbA2MBKT86sEOrUAtpjDJdsDcZhcU2vzk0y2GprPvWatIyAw+6NmnDk6Z/8K70IIg9uZJswZr5eWLGTQMBOJMWTyvZLFAFJY+ff5WkRP+EEfpTkhL59tDsx6wO/J8iKYkPSMo3ShJ99UFAQUOE/11u8vtH7BM3CX9w0Bkn/ovsJPHNcGRpkX364f00l33Rd1HDf/7vV4r7LHPuAZv2GsE6m+ftXZ3RMvdfju/bM8GDviA6P+gVcO+XKcn+PY84R1ORzf9C7k/GYcqaaK4eX77HD1fyt3P+51Iy/J1KPv2dSqb+DiUfqpw2H9x/LOT3y+CPn3Hr+5e/XW3vV3/DCvirg/N+66WvuvkPVQq+SCwgvsapt7d6v+fzANPTFG1/EBuAwP17n4J/3bLqa+mvW8x8KQ82qV/P/zzXftfHX+gL8lFxhF8tsX61xPrpW2Kd/vHbpwZYX7S8+rDTFf0biYK2R7TwG8X93jDry55aP3Pvqw/ys74/Dwv/jjQs/AOH/Ue0vvoYtD5Kw/oFWr9A66cHLeQfL7A6MOeVG/sN7Byf/j8hD/I19HzUMuwHQQ/YBfu9Pembe/W5ySvC/xM= \ No newline at end of file diff --git "a/docs/database/Redis/images/\347\274\223\345\255\230\350\257\273\345\206\231\347\255\226\347\225\245/read-through.png" "b/docs/database/Redis/images/\347\274\223\345\255\230\350\257\273\345\206\231\347\255\226\347\225\245/read-through.png" new file mode 100644 index 0000000000000000000000000000000000000000..7fc545e613fc847f28953dc423a57b8cbd3a1e67 Binary files /dev/null and "b/docs/database/Redis/images/\347\274\223\345\255\230\350\257\273\345\206\231\347\255\226\347\225\245/read-through.png" differ diff --git "a/docs/database/Redis/images/\347\274\223\345\255\230\350\257\273\345\206\231\347\255\226\347\225\245/write-through.drawio" "b/docs/database/Redis/images/\347\274\223\345\255\230\350\257\273\345\206\231\347\255\226\347\225\245/write-through.drawio" new file mode 100644 index 0000000000000000000000000000000000000000..7626c8d1f5004745fcbd532b7a6a90c6f3b2a9e1 --- /dev/null +++ "b/docs/database/Redis/images/\347\274\223\345\255\230\350\257\273\345\206\231\347\255\226\347\225\245/write-through.drawio" @@ -0,0 +1 @@ +7LzXsuvIkiX4NWk281Bl0AAfobXWeGmDIrTW+PoG9sm8om6WsqnqGevpI0gwgNDuy5d7OPkbTHcnP8djqQ5Z3v4GAdn5G8z8BkHgB4aft7fk+r0EAH4vKeYq+73srwV2ded/PPh76VZl+fJ3D67D0K7V+PeF6dD3ebr+XVk8z8Px9499h/bvex3jIv+HAjuN238s9atsLX+VEhD+13Ihr4ryj55B7PPrThf/8fDvM1nKOBuOvymC2d9geh6G9ddVd9J5+67eH+vyqx73r9z9y8DmvF//IxXONkwglAhsec5gD0g0PAf+Cfy9mT1ut99n/BuEtU+D1DLG/Tvs9fp9LbBpe8dKpUM7zL/B5HNzLpL/C32aeHqmn9e/u/y/32uY+ln0fv2nb9xV7fWr2tNW3I0/N2EYed67fJ6rI3+WLJ//4eZf2vyHO+P6DjCfq+9/olKRD3NRxf+JGmvVPSIIAX1+vHMeundh/sO1l3UZ+uJfr/D7+P92rZYfNXhXCsT/GR3Pf3H31468t/th7uL2L7fbfF3z+Z+enUurp8s/e2TNz/Wf4rYq+l+32/y7/v3Nqs9+JOq9C/xN3z831znul+/T5B+N9/lfHjiGOfv7vv+hepanwxyv1dD/Sf2sWsY2/l1Eqr6t/ubetx3i9W/r/CGMz1Xx+/uP1CZ/FID//BuL/kY8/4jfWOy3D/cbib44Eadl/hvL/UbRvxH0r09PJyzyG0X8RjK/XxDMW/n5+CHeiw/9G/lc4L99qN8o5G2OYN/m3nb/KPlgv1EA89dxzP9yZI9mJn9S9kvN/iiG/k7joHfRnvKjrNbcflb2LT4epH3KyrVrn0/gc/lKxe/I+bNebZzkLRWnTTEPW5/Rv/T1aQ/mfv78pae/BY8/gCCfn07/puh3MOHzocvX+Xoe+Qu4/w5sv0M7hv7++fgrTv7lmfJvMJL4vSz+HZqLvzT9V/R6Ln4HsD8HM4Nx21rgr4KFQJ8m6QlHmH/6Eyz7JQIk/bOv9G8f/Kfk2X38dxn4kFK8x/xrZf5k695azLv97CMTwNvUH7V+1XhlA/4RrD/fuL/ZpGWdhyb/Yy9+hPjZuapt/0XR77rJpM/OPGAIU++OVI9BIn+/0VVZ9nbzp1Lxs+H5u0j/hiD80fm/EJv389/ICvXz979GVmAY/mf076QFwf9RWh7A+Edpgf4LpCVjzfbT/o9o3ruE+R/5WhNF/WfS8i938V228T8+/b+wkDj5owXg31wWCP57FYKxP1Eh6E8WBUT+C1blzwnBv78qD5EZ38uq++FOfxFQ5ZU2Y1iqX/jOJMO6Dt2/iUffnz9/IuTr8EpzvIy/ON23Ol+hpn66JP8oBf4oea6zeI0f+/DrI8SNr8WlK4/SrQOQ+WIgnz+a7ZasWzxX6vvCiDQZPu/06stY/ly4K9CypmchwQZl9Nf+DaIg0BF23LIRc1IwLbKB2KKtdABH84q6CpPdjeNLVnT5QE80q1Rsu7cLdXRh74ga0GyujAIaYIbDsomf+YDG/sGDFX/Y44v9z7/819tCPBfU5+53nYh+blIgvAfPG74Tz2uEfj779kX3hUDvT89IkW3TtEnrJ49YvOy819vJicXmZI1ZpeTANraG5JVL2pL+NEBZKs2bDEolStlOAGvaoqiqK4s61ELbFpkkazuxpP0Ua2pG4k7ZkPYpRslaDmxhO6JI6dmBmz/FSBSvVMMWtKOIlp4eiVk0pn/9FLNsRTOMYunukZBNY/IQHsUlyTZPsSOYOoBEJLvYvI+HMSWyzUWTTp/qgPgW57w/mxElks11sU6v8oAosdyyvcUWJRbFcQFOq/KHJLHUukH+YFLSUwycALPqvEkpbNluEF/YlKQWBYs+kkS/xcI7ad60SUldSha9qZWmrX9/LXjgsc1UEdtJFYzEKG+Lbtys2+/Nbn51HEe/12d/qCQXI7vtUdiCfzLbzsS8m+ma0x8VpObtezkf89sR7ionj1RydtdV6juvKkFaxa6nu9F5vqmR5563g3oSEDMW+3bw9AlGSg7E9fepRxEdbYn36Rwj3pJvy251PgrPKc//5vlvKc2IdFjinse5BvapsMaeB0pDKJXBg1ntef7zFDqJ6TJPe3Qd6uSISiJ9E/qpTgE15nD7jU4PBFDLybQ1OsO7IerNxdzSSMIuQxSYvfdavnfYSqyW0JbaGYFJU9iRNrC9h4lp8hlbOHv6AcOPnLc17PVREVLSO8DLIqJLEMBv9t2mYb7HAHDZbvfRwKtDUCu2g+9FnQiuIyHSxAGmC/+gaX9FevJJqqsexeIEiHCGpq+cd5iMrsaEdwSeSyMxfXwq/MZK0V7EcueeJt0SB48unX1OvM7dpqatGmtFiWS3b7USLGR/O+PpUn21T36mHHxEmVKTOgQe0REQo35hRMz7O+efq3kzUelmzWaiA8EMCGOG6KBlvpRNfYAZs5pm50/IkcQSUNx2FwyQ1/mEeBcCFYlxshary0SJWCrv3bK2ro6S5nOS+CRhjUHIjSPvFqttUDhJRe1Un/vKeqNBHNRM32ZPG6n2CxiuaUJD2GpTRiFiwtfklT8rnr6Hb1u98vCCy71Xl/WZMRO3Calc5piYo4N7UB2ybngS0KbYuL3wQM/5Nqzdv1UGkOzxklvFbdqaC3QmEncJwkc62vtig2+5xXomQKtOd2+tYXmAr8hNnKR9nLZzwXKPQjt8RWdIyr63VRtVYztePGGlEx4INmVP5+zCvjz7POT7zRBdnfVcWqJSYvCdIB6yazipvpLiYkcwbdijfg/E9sF6zSGQo8YFysqzaWXE2DTIlfGS952gB7uOr3VOGo/XqWxcdwfOI8uv9aMzOB6SyqaCBjB5VsHqktoP0xNkeeupfUk5DMc+I83TcxNWtLRefUVZaRtL9/DoM2gYvW1aWbm08/VR5m/Gyfnp3Q/rDFPiHXu4C5DZolMWNhnqAD7C8gbg2M6RTBioeDJplXEa8Jr7Cpj5EW+xNNeB1m1JIDYsXXyeNRylSYuLeUCjfaxMY4ZwrYkgKE2QYj6TMOL6nlHjsfccTWVBPEQPuLEXLNi49Opz01u3bWUIFwTv413apnE9cLG4iTgDQi2/vvDEOqVGRW0hWiUUw/SXrqc6ttTTdZJfBkholkLEIuG5bENr5w00pq5OcEZSaAv1xn/G769SvbMDFr+jaULVodBKbfoMjiBVUXXfpr+i3BioxdZKKwSVM2YlwglJrvn8/Flja87uk2+hp12JHgKinr2vw2cumJu6ZrSAvZyon219gVuTrBSoxkhp2dvGSNm29SGOQhLECtd5h8pCKz1OnLK/Wi4U/metgYddkFZ0tewSTXs7mI8ofM3zVOZGdxVJYK9v1Qui9mCYu6R48njKj4FAsmAuy5ptgVQCAoKlQ6BwDgCB36UkTPhKVi+mTdKBeIqsocnDTaTEKQobPi523UeHbF4nC+2pL4n72H+ROTnYVdqSsR2dri98eRpKEX0ZXsUsjJqYYWEQ3w8v5p73Y8QujBvk4zU0lFpgIqiE5qPp3PBiMiZXtfHwqQXiYbrlY7j9TuCMPcRze9DkbAnVKYir91ymjIgo92t/Z5Tyu1eNk+UUGJZ2yThbaGCt/YkQiYgvltegVQlj6TytopsFUwnUUQo+KvVpgcbIdmuft86wZPa8LYN55tOeVJ4nYYdaSm3IqDFtuv1R2SkSo35K/d6bhnqCoC6bAWtk/W3qQdJwF9vBCKt0zvIWucBoyyt2WTfco9MCu/bDmqbZiBLjgbFQ4WOJplA4PdJHVUFQOrRlG62dyxTNaZC3156V+2BqUEa3sMUk36BqpF1UFJxrIGhbm5DDIoHwacbOAvhM3jdOhGZgcSwqNXsMT8QRJ809oAmUeobUIZevUQvaCZNsLniZ+JFY6JRSoVqcKGIvAW1dOM8GN/da3s8YKhXeIrlLhvD7YrD8aB45OUKH6HYFE8gh84jy8IVvCbQhtVfRRoGMvmRRamrD2chTHmP3rnxembLX+gff+KLcKbGViarHt0b17548Xjq4rI8sAaOMzivq2KqksFv0LHKrsVqcwZ8TAYVPgExvW/NlBJm7RGQ2pkstQSV5H1UfjUekx93IK/uJbnZE+/mB2GxBXl1a4vIldHmo2G0zEWtoMkCLvOxQKC9zVHqwnBdOgVbaUNoHD9Tg8YchyslkRzLACA+R9Pn44klL0FudbC+/kaKeWSnDah6I4DbXo0s81Wmm+mjj7BaX3ra7T1wpL9ZtQ5iP2szX0HZ9YEY5pyswPYEt2DYJ/JiQpJLxAGvNMcHsPIZEst6o0l4nm12Gi+GHV4dK3jTm3iZZQ/PSY4FIbLIU/aXqkl0SOBTiMaUL3buUuAQ2rz1sFEUb5RtF81bb5urKEKWY2K7w5RdTISL2Q/PjXefHifRAkCtKy8tu2g05zjrY1oFXKu2P2GcmMs3PNZ+0qbx9TLNUCnp/yGZ5DZ9hxz0ZP0zUPCUQFjsOCq7XFUMXNs1NBpE2YK6sCdG0+NKid1RnnIEVKeIfCQ2BQAebMko/HcWY2IclzCsA08X0EhZHKemFC3W1i3Pty9j8QOe+3q54dBsaC9n5XVtMf5lG+O4HcnLnUZkhohNH2CYi16Y8NArjYL7aAMItZvFYMz/YDCe+lUyPGeMoUVpMoqUEyPXnFrEC5CWjFDdjw9HYjXmiOXY1rAH3/qB9Tf0zUCRXfTcSslQhmJDIvSDWtyNmeA2DzNgHWfRBOUOGRoUhlGSY7jgOaDS/CMz0MI1eQ1nwhwqEvNuYAWVXbA3fF3+d5QQA3r17dXOZjF2BMPdio1VK+MMcBacbXDMtgUpZhVJnzutj1CztSunKL802uDjyFQN1Hsa0sPBaKtnGNb8yKb50xZG32NUHLjPefYQckcq/fHQq4m2IzzPEY0bdzNRYVjcXO7S0fPAowrZicVK0l+Xv7qfpzAYVaOiQH4ZVv05cWjnQqxbV43iZpWBu/QMNPKI+jPahpa/vpsel0uSqXfW2tfugqN4R9G0wHGY36349AjFlc4pFopVpL0fEy/6VX/GAB4u119Z5n6OaEglUWcRntWxhx0gltRoBWy0UdbCIDLO/K3L7iQM+zlqX96/k5d/dEyue4rBNfMf9uh4P+FDPsuqVAl+fWSp34jFSz3QnyjxXsKQkmRTerYegZzc/Nht5Ehb2zcTUsM/6DMBWbZsTjxsKvYYtmGO0YDsn6l0bVfAZWsuLQVBhZUStcz/RWISRDldjjblHH2kgAqdRHzYVCeLSB3pd323f+kdhLNOC3XpTA60U6ZW65Juqc9ZydyUFJr0I21WBp2HM8dF/fLkwuJfy1O6xasfJ8BL7sadUBu1zn9sjg9v9VK2ZYdeLWjoA8PrTXIp3n6/qf3xapHDctp3cPDr5zq2DVEFqZb9vE/6LdmzbSMc66dWs5o8vpQ965iE4Rng2ILrrC/83fCZQKREfO/fL5hvD7GzrVvjxBoUoLpsesJPOTUFmDHNot0CKyhtvqw6kPeklW6dycznbOq20eDV0n+5kMvd+n0aUuvciqc/aTutcoJXPzXLuZKjZsJC1drbrF+2pAX1353WPhvX57sCPH+jGK8pOpr/08Uegk/rSBwtpmeMVvqF92IUpRdzjeYRl797GFuW2qMXRnOX6gku9rvnOabyKmcJeSIuvP2kUGeF1/H3K8egBHf1h0lugV/PcFJtZNfU8Br8YaQT3L2H4Hnaj69Ov55r7gXL/cXkfGabgMqJZKTP98eM/2Cp5vLGBmVTsJqqeXJ+AuWcZnXT5YknrHm7Y38L7qqFj4ShebI5IsoXXMtRi0hLv3DRkAe3TKh0rpU3taR7VcyTn0VcWP6/TGlJaZwCeFKQCyr9Ugp5vEXk8L5qN1PhxDj0TaKAsIdg0cD9T97itlKZWHNxmDhT3DS4+4L1U/U1lRds+lMkS51utv8nSTA0YlTlMzcYhcYOExNtxLpqKTbGNvahrNpURQD9mWcfQ5R0NAPmlTbr5njYigNHQO6JmDKAPLiXCalgbyP74XT13OwproiRkz7XeN49VR0tFYVZ8oIwGsL+fqnxjQ2waU1GJAH4xnzJQAJm1hR1s4jlG2uhM25cEzu03kkVvPJZ3jCwRtPHTGwAbdhmrDqo/3qVfCQ5uzDw4iOb62OD4Wpoi57zNflyk9orynnV8xIM1/LRGYnllR1id2kb9TRr1XkKJwjrJ4jWdd4IbdJYKJXtC9vmAiMTN31IJd9sPhOtDW1RdUWRZSgZXnqnnh16Lu2bJKSqDBwYR9iEiWPB6sC/glMoMLlgD/njiFo2xPzKhLrPzKBsjVbHBwCjFdDSpoK6DC0yGKaQi5lpDeDRLIpJu34AtJim0kq+WmX012z4t/bI4S8IcflE/TqPSlBr28dSuY5ikt+hcXl82Lt3NhtwUPMxmhLczrYdx8NK1W1OEuYQyUT/Km+0LSQPXedbr1mYe6lJ9VF6pdB4Fa9zo98UCMObd5VMQEuMyXP9+2vh+5v0CvJg4osHLeLelWXY2SJdQO2Vyv8wlKLbtlZZRcoYkxm4OW1ivgemeuSISS0f74Ip5eUuLBOXAebpP+2uvftYoyLAe6Xprhz7o+hgJaB/7o2wvPXoMxeOCtFl3ioIJZK5sqMSIDwOu98vyOPw+U1ytfY+njI6vWYC0yHHfsd5b1b70VH2REEPAKXFzqcrXiAf26rVJmGooBmueD5tEmfKk9ZrLmDNkvMvHZn9fSemQOruvs6BE0iK4inHoHkSmgxBdUCPoCYscnIjt8JmNDjf14lSyMBqgBJyWRCWH7EYckUcGo/WCmyRB0Y5yhozMN+3hSm/gBOCJpMqTNDxtqp/d7nPcSTWyRnbVA/XwqwkeE4O1UU62J52pL89ngRytKlwT+gL2C5LesKDe72GgDT4q0HrigkEqrusn7uCRJPS4s3rD8p1ETnqjFsM6r9XlZHc9bQ82FrtaxPgt+SIw4Np+u4XKGPLlWpv8SC+Ba2Yvqgl/MLfsOmJR0Y77LKWXqc8rqTsAHGrqN2TjCSNpioPLX/IZ7i9yaHUV1DK+rNZr/zmW3dI+HVW670Sq10+g1NE60VReIkkOFfQTLe1ZHhcQ1VjBPMF511bEar/xnWIF/4nWqW1ycuXoReLDNtfWcu3bOxjUAr6UsQsFBG5c+4EFN7Vo5GEnwVeHSDFZIPRhl8WCvTZx6xOII61KuCbZVwuCHSXtGOKpW5+WlgJn/SEo9zPX7tCmbnJDNNK+g4+4P8QpSQ11e2fS7Mw3bXZX6uGE5QntNUwqn4VxA+Kl0B0jZuWM9TAcL6Kut8Z+ms2lBIrzjKMVcrWDBca+myZveYXyWPGkJKY77i0Jdr4116I/OSj8IHLLZhFsDIis9foeaObwGHuis23ddaTUXmCwtr9AOM6sa+LCJkqarFrLekuS8P2gsFW12lc9TDFNSaqJPXPUTovdM6HTzOaxIXwvhrkGlukbd2EcwrYP+njsmAvyiCBz/BuUzWFewcp3z4PsBZaxBd4g/lI/M+Nu+ie4Sk62MKC18HnsiexC6UD2ufdhqR4a0YzawSS3JqtnRjcuVTYEG/1VyWsA7XR+t6Se7EjK3bn7egzxJR0xMiYSGRZ0N2L4jeXY7ifNppbA0Mm0yAUp3Ty51om+hY1VfYdMLqiOjWE8hig5cWOq72IBdtGKvM0vWRbBtC+KAjIrRblyLeURvEbX3QIfijuX0Q8TARBt6138HQ12L7ZH+aPWqI9DMVo0rzFVusgJKzYkwQqNlPNSalw0lskj6Fhn7J9aI0ePx2F8zDRdexfIZWfGjHffYWpyVAARglS5K4stRnyOlKBWp3sO3Qbssw3IG5viuliiweN28En8MpMpfvndCzcrIpsrw8bL3HTTZIyHCRHds/8Uz5tzhm6aqQI6NvGHdKcnz/EKC5hUo2jUih63PRs8EpFyOzDkYJmu5C/b1yJZMvowbmc0ruWGzVAtIkDGsYtgYMnmlSBGO9VYAzt4IMDW+QVIh6PL96vTiToEzQcRyZIJHjd+44pMqw7+K0SE/ZB0rhhHEqI1SiveDX484Ph5TGLXVmKO8nAaj5UbL99QOqdNiYyUrLjcAJ0jh7EKWnCxUSxDR7YawdMBFnqNqKlRu1umUqvr9sFOUqkqZLZP8+SsjwNBnvcpOTVtRlGs2knmZCLF91ZJBzHDcyAevM6KJkorTpkpaqtyj6X9RGbYooRfoN9lQKQU4LYBfN1j0Buk5ew3ToklhF7OhEhXCDgpxPryAzp059TYZHx9xc9umWqULXJ/OW9ULQDiQA880CMRWm13nU6XOUNy5FWZbioISRRTKrw/dPdwjm9nDg7fCoWyK7FTJJaZ4MVP/ASbMrRRu4tj3dx3VT+oroBL7Md8vhryPIIkaO7ZyjStqSug/UtqwQdkqeT7vOjJN4AxMRRBtmH1dD9PJzJtW5RcytmD2apIadlw9A0rLLOIkg+5Po9Ho2Dy8aOy9PP1WyIqHn4YhZTzbt5g2aK8vB4N/lNpECWWnUj0nkAEJB8XKSPQr+8BYUF7YoRw9lupeHrUt3z/qaIWktSoAzm+oAG+ffrfLzE+lVi3oj0yRMCYSN6TuG1L9zl+q5iU3KgLPX7X95xM8I3g81Rw37M2j3RxEHv7S5TtVd99li/9p0Iqj1/teHoTAiMAxy8fso3N+6T7MgHs7W0W9pfAPlXeUzK50FNszbXDIBgwzJlP5f1y5Ln0PVUlbdfTLRmlQ1F8T3X/LGHg3zyA//ezCK6/TwX4d0/H/ytyBv70dBz7kwwT/CchBP5rwtD/N3NB/izbw/59kH+SS/j/cMf+SHBA/kj7+Js9w8H/hVke0P/7WR4o9C+yPP4sUQr5MznG/rvk+D+wKv/bZnk4QPPXLI8MOyDL6jkGrA7Kc9igpc/PEU5UsUNzzdrbxUGL6srmazWO6pzwcNiqULMGW78+JCbTe6hVtDn6LicsL//rVOXdkz3Df4JSUQtH8Pfx408Ix0HnfvzEe4z6ezuK7mQPcl3ZkMzq8LDVQwktleWIzKooxSIPMzhRnmSdU8tJNi2Zg9FEoUO29SEljkRzujYzN2uQlNozd+z6z/SlpaSEHC1RWiqKPKlQkBVNlWV9pCsM9SAo9jINDc1imhS7ixVT3Bc60adpVBc6t1ipg7SiSlY/N3M8fZAEzJ2TaFahSK7nKuZRiZBSM+SJfQEsaWmNGOKQaqhPH8KVCvpY2lRRVDcLWGgnFOJDvdBNmV3z7bh06vggTuYgHekgoDcuRdKJaFrwFuZvH+/kMotmGYriNmlgbtUgLbVh7jzwi4J+JkcLOliiFVcUm1OiraiY6WMnw6o20j8md0EeNPZ2vI7t/fJ08Q1JEz+coQTmj/KedG+NimdnYKTw9w0ZSp99hox3886BlpoiDmoBfoP+zspmkgeidw86EwFyHSVL1OMjgCHwBlJ5DecXvrnM+Qt9NsxMbHBoj8jt8rFL4Wesn8vN3oBGi9jpGa+1K3Y001O6GzfPVDEnLM2IRiGcYNwEaTB7s/cqGSlY/WbaT6QwAgoNlYEISV37otge2pgI7WuybYqb7GxnA52UR9G2CU1aoGA7WBWo2e02/3YAO9dhlKAhnWfu1GXoNGZkw0E0ZpO87NxvJDPn4iAYHIQdhGMWDOD6CYt3n95eKaW8xVTJjp0rYuVZLhYRHK+LfciBlxsBijRKilzpcqePIbWoCUli2iCSddkzXndBCdTSJt+IP2cjhEp+jGneDo+34YqXEMxascJGZ8xkJA3cgBYLk3c8kZ0hCxaDjpBLLh1Iiv3Lk3oXcSTf0R3f+SMAxdJ+A3BCUCQ2baTE/I4SOIPJZ//XaTaqACgasPylLOIoIUBGaTqAEodAqJLIDg3Ojmxul02BPc7Id+MGiDyiz89WtSL81USKLMz7py0q1sVCycjakTLSkyJWfKGgyRW0DJ8HsIfjgoptRm/lbWr4EjdvLpQJqT5nhmrnKpFYSEBqSRVPkVWbY/ooGkcfzPwemFmaRAoGdsI03dCnt0hYPqkPNwvGzMklrR0b0jRLRKQ+HZB+OUFdnLq+k6xy5zWIQeYRhNhWrFG/L+Kbm18HNXy94RHn83EFnBixWLeNUhaJ79IZXry78Pnsy9Nd3mKfaMAsAiYIvIMlWtY6XNOC4EDJ653hiCXnTZKR8Uike7Hqzke4i20J+/ppiY2Ptcjea3RO1aS0SayOsfQASFrS7+4PHEmz5fkYijxW0nsW5lQ7aV4W3dnTh+mINe22zZXdTLjpwxUnmbwznrXHbcDHvrSrz1VTPpJg83bSTgixfuRtnhr49DcN3zCwqC+p6YyLwrXNXOzUHEa4hQ6nzUCtUHAqFk2Om+VOF/bXR+2+oz2kbvNRKKHbRlbnGTlyPhVk1yMDQK4CbtG0sj7JSbXxhjYHn8xbDmG8a9j2c/IrVlw8k2CPAzQaMZO3xjGv9Xox4mDxkq4EoUIESGZvS9M1YxZOLhSPCTYDMy2uRYVPnWaGDiQoCvmag8w/YOxoL8kml/Brkw0ftnPTXnMQUL1yhOkzBp8pJCKn7aLl6znQVgEos4tG0wE8JMoo7/zH3Kgl2Ne803CBH9W0ciKmwIzyZX5yX/0EmWFCpFO2Nr9/elntcoPsRXFbYJYlKFeBWlnzXzM128ho3VPf/pwCfLuLNOg3fp+4xffKmm4RZ0ujDo44x23zeEN7dWN1aDSQjTui0in6Dl21++ZAgrh6Ukrtu4LRmBAtp+auzc+ctfp5rkbUvbYJ0Wo4lUkxmuSID+qw/E/iEkXUrLr4Vw1A5gdoqyDo5MD92hmoyjpP3LRO48n1hco3M+KzAsDiXjf+zA91NIbEna1wU2GCgL6HTpH6CvVMiSf/+fYuTcpbwmzkqnzerA/T7D9VOGdawzpkpWXYtxOjCCIYMjiFm4PkzibHWPRwiIXWrNmXbtb2wqRg+XUg7VPQxGpsCtmvuF20jwGWqu5A3mMA8QQlue2KyXxvfaWtOzvfyxJFFffHMwxvOdFY9ipiI7SP5D39NM8BbFyH1clagN6D3s2PaZQWg6sUqrrUiTdWtpIiuQTK07GNZmpDyrqY2RmUOrNpTqQfk3LRFFL2ZiRdQmVBx2GOiESFlL1IYjgGHBWyWsxPbrXIGwDFItnomLR78UfBxdbt3lOkBsTsSDRpEgRpx+u9ELRdd1ECQvMiwxP6gre/muRt2FARflxyj+s+dpzTDqXEjhEIcgz3LJYDXKZmEOq1QInShZ7JZhfIOyN15Y0pyq5/NcDCDsTXyGboFb33EKvYMV598V+gmBYAeL1VXWKdVSvkhNh4j+ActPqi4nkzhsjL1R5bOi3SNLW84VMZATZHFuEJ39M3n3SdtQEwraG8+AHemY/II8hpZvNhYp88F/MxqEnv9m1aUknJ59XPAl37K+w7JIt3ssAujCE3zkkYuJvjewowow4ka0cWGgaYABLyJuSCPwFbETdeFF/ewIYuHzNuol9MsF9//htM1cjucIIlUi9XwfhO9spRpLM+b0Kh+/JDu6TI9KU0lw8asCCKR/ESFOz4cnv4hRP1G51NUCSRlCtDu+Lz0RkpG2ymLTkJbZyczrB9SS8EhommrTeh494gn30eTkIZtMBWJlS6Yl3lfaLVCI0bIBKx1bw7HMXup1NV9GlbeCGCbfx1S63gM9sPWumIIw7/3PrZuJ0tSol9qo22vIFMhKK52rshZ6uMBQtrQvVfAbUe4Bs/H5SFzEcHHPorfwYjzgD1zS7wHLOwm7Mu3etB4L7d1cPFdYerOzLdUSP0PfOc0edl/VDsQlYyuN5CtIZS9565J4/y+jhmaWULtJ++lYbBQtle9SuHU24Nz8xVMpSq7x4+VIxx4wF9pQOFVFwWOwUy4YeNHD2Eoj3U0ZcASXfnUL7cj5iw1UMYrUXT6JJvRzJfFWpWjlcXntVMBOo+ZfWbNlZrh6cOf1K2rgKNR8EtDnIl4ey3tqpINwzvbzw4rogUeOArFS3pNNqt1/geXIa0ScLhMAixYpG+ldE3hYaB+uHuLXxsi87EIlBt/Cz9VKRmhfPI6+x3Ggu3Zsf++FpiwizBDTVW+FLCsEQfdkwV4dcslUZ5o1r50bojFlx2NnIAEDBLv3y/bOCI3W3Zhk7kvDlRNX0Pfg3zMM7axG6b4AjdN/zwmsU4loj6UL2hqUCxpRObcsckIzaR+K/pVFrAJ1mZ6rmkyDSXfWlO7tfNiNwI5R2Djyx7OeYHoKv6mdFHYY7Ugx8pv1OJJGMUEFBKdWHyUJ8J2/dKWNG0Jz4UqfDCLBDxSNNn73WYpvtICncFI5EKy5aJHYmxKyGZivOyZInhvQKhLooBF5uSFEej4orH3Y5oqt7Dy4N/Q6gd0pwz/UbGRhcyv3Pp0UcgELFI3QNWcgwxtLVGYJeYMx6dBjUi7QKVSVpXdIeNO94q/OQRNTzYcavytTbcgFToG5zyTemt/3D2Kx0e/JXYbNEGgqk48400mp4dXF4/G+fnRQuDlW9pcQKPp/SGiDcD4DGRLXomjad472+tPKzMnO2N6XRaYzEzy2A8NCs3EmIJavO0QWmYz3QEkRrP5h6pgw3aiN/4brSkF/TYW3agZt8pNmYwkAfUfVum3qzieFu/U5y/q5mplVpyamPRBHlbS9sgysLik7tuolkmMwOMBmt2mu4v4mWQfKn6jsLBQxjUeT3U5UWK5zMTprFGKbUJFCWDFgEjjvW4UleP6g6bgJQYmhUfR/ZbbmzOAgbPjiMEqoWSxvNDJ7juC/O9QrEN+a1KKmwf2y6OmM9lUqx9ouvSDrdJgXpMowmKaYmn8l94hMZiOjBSDjkA+emFECfRe2cROmDX5WDtlMY0lsecRM1Ffyxhmy4dAo+Fg4OQRkwqwsJ6Bu2K3aLkx7mzI2p7NSeZGtkHFcKVUsa3WnMhmk1GagqLRLIrRktmpz03TwHc5p0/E40wCzVNFg+8ZXAUt+z19wYWJcqASbctl/eWSr1Mlr6OLnwN1OzIOhQjOe/BsvM/fdSSSalTCvW4GQdkIP0EOIXUru3risJVgHjkEeTjdIMvCzlo741nPIQn2tdGwnNEPk8hrq0HKUiYwmKU5xbptEXIX0ug+dp73aOPJ76xElcTH03WUqdkmzyWkIf+hV9hk6avR+53mSOLgXAl64gbZRk0Cs6EmTJ0x9woNdi160iUfzYGcby525ymcNvEa6MfpOJBAmzcThTkYjAia/G2yAciDTWpOxrZnswQh+A4o1+gUw+9o+no4Hh1o88qBye4gn1xAZBlrpbqBGu/SiPQepx8NsBf52IhW8Gex9g0sDgUVfJFmmo+Wn0SnsV8cLi6UL2mXpa5k0hYiaKkPqayKlXzhA7a9+9ahKlCZPOXMnmPTr5ZKxSquY2lcJftciaLzZXndDdVsuqYHqwces2IYnBJAi2ZZb5w8BWLkjQ0f2j3elDHo+rWIuT5/H6DhH+oTv4JLoaH7YkO34MBJnudy8zXj0104f1cSElZpLUEq5e6RjdVwHeMtV+AdUbm4xewcY3DGlEZKQ0O9X6pp2Fl2awFxEumudzfDdeeYeZ5jcw9AhYMknAMWiSk8kbiOV5qj9K/g5/UpEOgHYGHajyh+L4RK4VAlsezqyopM1GlA2GkUzuMd2tKYbnQMdeumJ2idLyPqRPyMJHyjXJsqBFpTVLqRZGOvYFDrHiD1FRKsLZ8T+BLIwaamux0mny2hDqX9XN4dWdk38phS2ueMTDJVJe1e+0xc9r59VrT35BJce16c1Clyv2BFFOCdD1aX7/f88t5nBopVVF0SFLLc5mrNsCimWuWlK8690kxRPuh3BR8E9Ygm1M8qLPqCXW8zjpB1NZIdgeWHK2e6q87shwlra7N5me8ruMP++Oi9bpL1sq5xaw3Db273WYfi2GjTHgKEJ1SR7J96thEaK1qkQmLSx18OOrTsSa55SIPM68GcHI23+KBPG3WgryjyVeqqpZrtKIRcLPyvfFjsxAZgVKUu+1p0ST/JnooiVo+Hn0MtbQlJ2j9hposVshLCGYTwzXDhyNliqzjdD+GiPiemsiibyZjZqrDQwofl1glFtpE4wZ9c5BnIf2eW9g/rIuUChzVABhxiIgCHv/yG5lUBCW27/kG70PGM5TqKzZoAT6IXFDZbqNepafUHVwGePHValETVKkmiH6VcLMV3j563izp0qvrTMFSkyZmMRAxq8jsRGDHsBbUFCSmwq7zr6s6ERWMV2m3kqLrmF3YZ4Y4Nb1LWfG6rZt4Xmx6gjIJHINhcClSd3vThQEOzBu2mC0N0vWsgtLqEtIJSxIHOJVuqISJJuMdD2lyBR+e1jdj6DnL/fIu8zV37650MBxZP3z8s1Nnze9j33+iMmRNd8/c2MJ+PJ2CqXN7Tw6Lez2oL6iLM233d0aVgvfm51G+bv4ks1xTE1hLTygWyaq+sTmBvmg5jxDAHFuWgjevRs+VQKXcD9cp+sdwOu2BiTM7W7ql3/ACptiZEy9Zx783UZ/HIaNuJJY3bLC9Ma32Hqw+ZEp0YvOKlstopNNIsCVzaxe1sOTJ6zMqcwYr8+PplDTzIQ6ChbgyN/hdnHU4CCUkKWC7nwFI1abSppgI5cUBCepzhiq76N8vZTjLMI7Hgfd04xUFzdSnYSiuKVLx43dYzQ2NMk08+/fQA7YRDircyh+HKriqI/WOWfp8A5cV8Zonrgzr4x8YhlY2tN84Aieru+PJ3RDU18RF7l3o8Jup0AVcLoAfszKtwvtgJHir0pnH5WbWhd7/nrsC4iA2ekP7aIhtMXb96Jx1vsewcKpdqDKLg8DmKTQB8ztC20TMOGqK7qKkDzYX9q2WTFwsfl1u6SMrdyTVdGGXNdbOVjNrK3wmVSid6Znr5vWZa4aMvuqigvEFGoPGIiRmf0SRdxXrCJimF+h7LHN/mkDD8R6xwSQBEb92tBimf6fS628mj94xEO5ScP4S6A3Z4ohlJRqrJrO3g5nYFNKLA3B8NIb8bEMh7N9aLMptkOSRtS166dPi6kpFdb5FdzcgkaFkLeu99rp8lVN9jdRExbLZMeBDCUX94FjpA6MKTJHOPlTyTteNWGxxUTFOFFhCprerlrK2m/TN4vd7m+BYBmOe3Xd+fa2Zn5XppYkZObwx0EuydA59LrgVnZ7JvGFIiaTD2QaamRX9Xm1tKk1LXQ5dm5SnwCwiihMcubJdQl1YP1WCN8PIAMeIbGT89uk0r1yJaB7+92obHFNCV63EspAOZ1pgxyohUEwAnrkfRZNywKv7s1/clnhPqyt71A2atXjUymabTpQpoy2CVZZOtBnhBpYjEoXwQoydE0uLwLWVXHkivDcJPQOxqI5xOfZ4KS/rE3WVaO4sLlC2zoi3SU65DJ0za5Dv14winJpEsu2wU+cIXIdcyDlctrcl9s2usnjFbUWepiWR8dRr2zualWc0Qgsi9q/zrKFt7jcGuN1UJwRbAm/8i3VevrE8B83giCMt0nbHs3ReFOhl+p6xoLmm1JMok4/PwnltinGHpTZKiwCbPrznLW7h+d49BO/ZwxbUNoJVdEH+nzb+tTbeaI8qESfJZcw0/qQPkJRkuSg7N1JRFD8JBP+JHALoXzmk/U/lEPzp2et/2zfskT/JIcB++6C/UcDPL4swv5Hsm0xAkW9Wwf++yQT/8a37I5ng8w9b92c/L/LflkrwJxv3vzqV4J/Q/0AqAfin4oz+N4kz/P/jVAKL/psfjMiR4+tZgXCj/ZpUVfcFSNcNjkKaxMGHcfguPin/YUXXsaavzFyPc0FXeyHGlK0NFRUXq0B7BRBa9uxTF2lVqgAPQPBQEuImroX1GmMmAQAwOo20ca19zDb82FAIyuE8z04UNl5C1uzQjKInfu/f1IG+XQYj94GYBieStH09DZChbIp8y5lkAVGgiZCkTFLUwlwFaSqkMLBvFisVkOwVp8nOTNUz79GWNSuqEY5k3x8igHPGY02XtNk0rh3llk2KJLaGnxFkIFkSA7rK7VyCIiXJ0OASfJMogZni35D5/hmQepi0PoL89CQ+HPthjteDrhYLdj/shpbvr4hR9YC9X5joxinMY6+egilkTGo2wU033hNINKpvHMP0Xv0yg7WnZDU67zrFLSiHjR1EEaSqzXiIpCRnR5TUYD5DTlGRSB0W6vvFM05kv1oproNLqXx3+PQhvt9v5AIpskiRcRc2oFXuqtcEMysWWWO47frxyvoISJkhNdrSddKwIG3Rx012RhNS5dX3NEAAkscjf4jby/zxrPkYDnDrOriVrk9StplsbUvmfShV9Tmqk8+I58Ba1qp09JqcOTmQSDIRZlgCN38z/E9QEvSNOikuOhTIgzewtkzeUp+iaR2qKlanXQ45fb1dCvvzzIgzNE91kIgjyYJP7UvNYTCfNkZkKKFWXOhTBnH3ri8hLV/+rOJ+nN4DGD/nsdlD5EJy3H0XTiLVeAt4XvRoj9y2DEILfZbUflk0CyqDgnOlTrYaZcm5h7s3o3LK4QkYDHq9WgrE95xjUNyeHSHdgkJS9TAYP4uwY2TlyPee5+o8FpvKkYLE7YCV4Ui30s+5CD+6Jw6gGTDUELSnTkZa2aFDztpVe9c+p0/BTYQajQzyQp68nNznDgQuxZZgh6wawD6kDygOquliMCUwek9WEjOgghXfIGL4xtKpbeDHRH+Taa9QX8BcowLtsjOBMelGcJLVr03vfgDaGgCyJKt404sZQuVO6Ga3G+umsmFQgpTr5zCHCQujuLGgI9ROq43vJDlXtjKh7VKEYDhRwseBNiM6Xy+cTab810aiRexXOKZPFqFUh72WXuqi7ru1ifXcd+IEin1NQzQePziJgsGOnPEYDVESZ10vfiYDeCup6uXMKfIqOBZGHQX/DQE6hJH3OPWINfFSax7P9vd8CjPOLhkxhPDUvJxPNHH87aMmHxvbCiDKYZY9YnpnvPX9gu95vQGrEAW+qzKYvj4/Qy5mGCwU9UKw0OC9QqbNN+iMH17Btuz7yw/67HkFz5joSYT0NU6wTJ9cSBWAnn54clES9SoecSNpWvDHhhhOmd5T9DTxp72zkCqqBymWu4rVwdoXkxeasz/moETU27pKHjFppPRVmjTEnEtIAu9XBeAew1x9JrjXc8FZZkKDIoLHAVRn3nF8ZijMcLyi++Kr5UGeRpjA881QWN2N7rx49fukbS80EoI8SuWLKnkJa9cvorIOHEURL+IxQDNHRBFyQoUMdXg+txZkUSpd0Nng4ZVznbkuNX89zJa4z+UG7O/3hec+4JZSnXkiHQVnxgE+2HoggYqsLKpoj2KQGxR9aRZilfPp9xSI0R1aiZSqsGNGKOqSjqkk9BuVvEiZvkpucSYBnb0rlqrZA2c9uCPaMjYsB82Si6xwVBGet4DuDTMG10R1poAXwD76hJgWJLdq8e5ISkNBvuhRTWEOBdx9fuW5tCgLhA1NRZaNyCFer6hdup1P2m8mAGcCT6eXNp6PHeGKidBFvNYveGG60qZt5vN9HdO91cZc43rEPLiEegQMvDwp7LHSzUuHtqnHAKUW4KVKZI69LFEa6QCQtifs8KYos/MxmdezR+Gnn4rbdWU5JsF+qjBtxadDaTrAAvKZuxAT4NRqO7QBr7Fbw+9AHyiKLE8h6vAykzgFNUV5oW/hRDnW/d75AMM4Ypuy7aJNi5Vn9OsZMaU1InvBTA7T75tWgHqkLyqj2HxljnSKN5wkLN/zghUM71VGZAO3eAmT89pPJydMYlo90qTs6VWacNcbmZToLjtqlPN0snMyzg1sveWUtiItMh0KvoXDIZW+7+H3djyWCm3n0aVsZovL6s5+vpNugv2YPajYnRh4CwdTBX2+AILJdUZfyeLsK6jYk3yLESj9dY+3qTSjKAp9h5ZkC/QeMjjs6SDkKfcEraHug9AtqPUM8qXzyBIfHIRX0ZCuYSHzqEUCK2O1dmWpSvZMlX8Vixy/XBrdYBGy5GiAH+sIFNmg1jGzuffMVzicu3PJikQtUVP000aUo6KJI2YOm1BGciXpoRBAKJwGTZnrN4znNRRCyi7Hlnz1mI188edgYsENSrTWcZuBHGmzZOMop9KbGW4ifbeG320AYQrJXGRV8iaCZPxtUa5+ihFbHkmUer+2gPSe3TrvVwOYSt/BstpVjyYtRiAr7T2uN8d0imwsrIvXxE8wAfwE/B6lmViqVVqZJsF9xl+8bPGSwK1WX9xx4FjJnRdmr/Kq0sX3N2WCby9vb9iroZbuHBWX9rdNefYqMlkLxbfpDraULOuakxuNO+kyK+LH7mrFwZMv7vjw3CQk++x3/Al10Cb91+5OnjIRlSV9t+jqzet8rCW/+MzkDC9RUb+GMFQVdq+Avdki03DXdcStSjkIqt8rjoZI9p5/ol600nZY8GYzWGwnHnIsA3CNXGrANCGj3riI7hhpUxoe3kL+ffiujKnvz049FnU1RZObzQfB3u8mKLuf95AtSeoqP6RplcsocVHwPSOaQNz6JF5hkrHXM9CYbIk3z4zb2Z2mP8QOeTrYcHCQUxwSuocpuomPUnORyWxIA7vIaW8HRCnuw8L6kIjAJQygitKYBHnZbBw8CHQoxxeWTp0Jv0wcEuwjZbmW6JvbY37foJ8ZQ1hBRhSTumQM3ofAfWDFugUPXlOZZM5NaXX7Bbv31FQUViuGwd4KAlDHZlKlG3IpQymaGjI9UZ8oFLcsCt0sa7vS/IZk5dVHLG/xagmNH62dpUE25bMhVlIsuAJ8bFp45XbJmvQZVwO5RIpkXioZrp5L8mLbIBlPqvY0mczDV0KjNmnR81SqkjxVKAeKlbfuYRRz5xwAWVG+Y7rF/+nrX+krBihUyNhMtjzboS93opSCLcYeEvLSF9vbQPn/2d6VNTlqJOFf41cHiPuR+xIgQJxv3Ie4BRLw65dS93g8M23vRHi8a+86ol9oJSBlVX2ZWZmVn48+XuW40BHjCgy2j5mZHt6pekK73nUcu3xrssewnanwrMSPh+Vd4A6hOT2XeB+UTY1gbQKgOE30Yu7WxWbkvmNnYnm3f7ZjdyEFcYdNEQXez7dl8JmNeyiqMlWVqSInlL098j5Ir7Z3Iw9cV/xbDF83S7whbxvl+aRc8SQUeDSd9ZctmifOl3VQIzuuwT07P5c3ybc/4MOFUpYcNkmVPedVnupoVda1VmhIRP50ycczHii/v5oWc5dHtQa4b6etT0ZWKimZ/5wupLOxaFhmyuQtM4cFulDl+RkRQvp6resy8h8I0YHElYYt4IsaAI+0i4E5lkUpfkbDZ3GT0TK8Pqu1Dpvc5SxQy8RcMFYuTPSmtHlNWpcYLmqEOvySXEzijQiYbRQYesDihqcMr7KTS36GWJ4XKfnwma7giCsDw8tyuCMtWguVSw9yZnlYi9WZd/M3H2BN+WSM7k19AhKe3GY3OjeqYuQINZ6ZlQpUmNh3SWGBw+Rqu7ZjJYNmzE1IOfcI6niMmsuaW2+plMPPbLYCxwsubd5tqgzMvdcAn5RfqzzFH5Zx4HQZuaWQ1rrumZr8BLlXwTs1Gw2awHhFTOqS1HW31egGHFQK+UJ890x+35zbsGtxVE68igtjOoNOW2CHfmwark2zvq39+fRopGlPuCo51yAAiQOusAX1XnsQo9A7J2xVc27P7R0d3JznHrEzDilm6kdMsx6mU6PH2Z92rFqD3oVPotyKCDHToqnRux/hiN4mCnOKpnMoIToywcQFqR+PHCR6FMzwB1+aC21vxCAu3QOx2Q3ZiWkNb09eAa2HWFKQ924RR+fwPnaetuN+K8EcLI12LZiqPL4hqZvOrQETkUNyt2NjPrblwrmPr/fjqaVMtVVh5eI6gy7kqNW3r2CeVpqzd5swv5I3a9V8BLkG0az3yxYw8uiSbG3EEN7A082qsXq2NRFb5ySsEuuuVHwD5dJO3nXJckwDnOh353Cwy9lT7wPQc3Z4QsbkqzcPJSqv2OrFmKQEJNEDvRbpWvVTUEnme+sRFwbCLbYgVvd9fSl4yxzXBitIG7qKhi5NQcHxmzaBNNGrYTOIhRAWWielFIGSZJ922UowglPAbVXrTfjhefoBLcueab4a9djeKyfiGOH0KV6n9jl5bgMUPdmQQSesIxf6Ph8wChLC+ljEt1Y0DNFdsGRx/MqoZ67yqIvp18qT8DfGxtOADfD5nCcknHbr5o2ecqnVO2/R9cp7wWlfTXRVBJK96herEaGTK5GIKMRsUiZzDr/9mGN2NbQk5MbDHR3SBTGKf79oHWKh8wXfae9yTKfTFaIuVw2C74F6Z1pLgzhNg/F8v8FspBKs3DUonaTUuloortXSllUCMctdcoUOZ9PY74RhPQ1y3x9b40Y1+pgOV2c3jU7rdd6VRT7Ib8IEVhXmGwQ3vmJIy5gO1fC4di6e0fYMACL6nRw61xumjMt043NaaFg6JaXac5i3uM/HX4cDhg2jcakPm0nzTwsFYasBX/1ehcdrA2XmIRGdUaMt7uy9inRv9oi03TGkP3AUsa6xDRwsAmMQqg5OxtWBdZA6liKkvKg7UmjPAT/myd0sjlk+XPhj+UsZvqxHqF/NcSA6XFvEqtHaFHCJdbeBQgwEq1nCKJcTTPFBlY2TK8+tLtZ5v8EE2GUt8ZQmbeeMO2QrF5oiRiK62NUslnXzuFzovnLIqeFD5XUCVTs36BKTFBmAVl3d2SOxMlaeYjgShH6E7jGwJfAKWq46yFaCQpga1F1CQnQiDtdZq9JcNDN9A3Zzt6RNbTLEjdMGolO6qvrnTlB6upsLExx43vpazONdUkNWfqj/tMe9h+MZlqOphTGCIE5cL/GlfIYzAgK7b9D+QFRsWHIsPcXZOFyjlrWUwc8hLGnhK0PS996OrhYJ7UXKsxdhCI9Vs8vQeqYCDrdgqvOfDF8wYdgkcJoyPc0I7EPxwt02rlaJ0GjiFRNeLLRm2U8zMMSFWg3tsYYz051StNlNRrYKT+DF2IyMoEPXJj2duAWJ2MdoFLQiZ+whe0SLlAKWqDpLnLmoR+AJZh9jUAvR0TdaVdmqyaUAfysLkAIk48BZgEM8y9UnPYwLuO6KOlzqe7Ts516lhowWFOfpg73X2CqgaIQfMivv+/aqBnnQdujN0OGTVj0H6xJnjVOctfpGpPjI3GJIO0xiNscpW9xTg3uM55mxDy17+9IzIvcoFdAdQ+V1/liKHmcd8y5WhiowdfrMmyNEXteXXK3GZURhNhxftXkjzcwgKqOQbSJp9iMOLzZavgAs4y0k8aYIXvJ1ZaJlpY/l+/DrAdQx9oRxSwb98H3mI7pfd9c0SG9NaLnS7R6boT5dRag2bF7A0PKw2sX8ICE1lLa2icvCAOYukECXkAJ1aZY2GBMBvkQNneK6ZcKaqKtJe/D3Yb7qyq2BsYCUHx3YoVWohTRGmS7Ym4zCYpvfHJrlsFTWfWs1aZmBB12btOFJ0z94V3oQxJ5cSbZgzfw8MeOmgQCcSYunlWwW6IKSx88/mqREfyP985tJSuTbQ7MfZ3XgPytJSXyQpHxLSaIvHgQUECL87+Ymv3/EPuUm4Q8OOuPEfzA7SXwzHFlaZJ9+eD/NZV/0XdTwn//7leI+y5x7kE17jWCdzfP2rs5omfsvx/c3U533fpmS7N+nDedoKrL5d+Tenwd+y++Ow5Q10Vw9vmTt+eFK/nbO/6WVDH+nkk9/KSVT/w0lH7qdNh/cfyzk98vg159x6/vD366296s/fwX88MF5v/XSV938qy4FXxQWEF/j1NvXfL/n8wDT0xRtvxIbgMD9e9+Cf01Z9bX01xQzX8qDTerX+z/PtV/08Qd4QT5qjvAPJdY/lFh/e0qs088/fSLA+oLy6kOmK/onEgW0R7TwE8X9Qpj1JafWF9xX7w/+f6G/wr+jEgv/wGf/EexXH+PWR5VY/+DWP7j1t8ct5OcXXh2w8yqP/QZ5jk//n4j3kK+h5yPWsB8EPWAj7BeG0jcP6zPRK8L/Cw== \ No newline at end of file diff --git "a/docs/database/Redis/images/\347\274\223\345\255\230\350\257\273\345\206\231\347\255\226\347\225\245/write-through.png" "b/docs/database/Redis/images/\347\274\223\345\255\230\350\257\273\345\206\231\347\255\226\347\225\245/write-through.png" new file mode 100644 index 0000000000000000000000000000000000000000..f63c2e81d3ec95fc38cf00a4258ffcf8e8bfc839 Binary files /dev/null and "b/docs/database/Redis/images/\347\274\223\345\255\230\350\257\273\345\206\231\347\255\226\347\225\245/write-through.png" differ diff --git a/docs/database/basis.md b/docs/database/basis.md new file mode 100644 index 0000000000000000000000000000000000000000..e616203fe96beb2971f631527db12be6e3df4e5a --- /dev/null +++ b/docs/database/basis.md @@ -0,0 +1,159 @@ +--- +title: 数据库基础知识 +category: 数据库 +tag: + - 数据库基础 +--- + +数据库知识基础，这部分内容一定要理解记忆。虽然这部分内容只是理论知识，但是非常重要，这是后面学习 MySQL 数据库的基础。PS: 这部分内容由于涉及太多概念性内容，所以参考了维基百科和百度百科相应的介绍。 + +## 什么是数据库, 数据库管理系统, 数据库系统, 数据库管理员? + +* **数据库** : 数据库(DataBase 简称 DB)就是信息的集合或者说数据库是由数据库管理系统管理的数据的集合。 +* **数据库管理系统** : 数据库管理系统(Database Management System 简称 DBMS)是一种操纵和管理数据库的大型软件，通常用于建立、使用和维护数据库。 +* **数据库系统** : 数据库系统(Data Base System，简称 DBS)通常由软件、数据库和数据管理员(DBA)组成。 +* **数据库管理员** : 数据库管理员(Database Administrator, 简称 DBA)负责全面管理和控制数据库系统。 + +数据库系统基本构成如下图所示： + +![数据库系统基本构成](https://img-blog.csdnimg.cn/img_convert/e21120184e63406526a4e873cacd23f2.png) + +## 什么是元组, 码, 候选码, 主码, 外码, 主属性, 非主属性？ + +* **元组** ： 元组（tuple）是关系数据库中的基本概念，关系是一张表，表中的每行（即数据库中的每条记录）就是一个元组，每列就是一个属性。 在二维表里，元组也称为行。 +* **码** ：码就是能唯一标识实体的属性，对应表中的列。 +* **候选码** ： 若关系中的某一属性或属性组的值能唯一的标识一个元组，而其任何、子集都不能再标识，则称该属性组为候选码。例如：在学生实体中，“学号”是能唯一的区分学生实体的，同时又假设“姓名”、“班级”的属性组合足以区分学生实体，那么{学号}和{姓名，班级}都是候选码。 +* **主码** : 主码也叫主键。主码是从候选码中选出来的。 一个实体集中只能有一个主码，但可以有多个候选码。 +* **外码** : 外码也叫外键。如果一个关系中的一个属性是另外一个关系中的主码则这个属性为外码。 +* **主属性** ： 候选码中出现过的属性称为主属性。比如关系 工人（工号，身份证号，姓名，性别，部门）. 显然工号和身份证号都能够唯一标示这个关系，所以都是候选码。工号、身份证号这两个属性就是主属性。如果主码是一个属性组，那么属性组中的属性都是主属性。 +* **非主属性：** 不包含在任何一个候选码中的属性称为非主属性。比如在关系——学生（学号，姓名，年龄，性别，班级）中，主码是“学号”，那么其他的“姓名”、“年龄”、“性别”、“班级”就都可以称为非主属性。 + +## 主键和外键有什么区别? + +* **主键(主码)** ：主键用于唯一标识一个元组，不能有重复，不允许为空。一个表只能有一个主键。 +* **外键(外码)** ：外键用来和其他表建立联系用，外键是另一表的主键，外键是可以有重复的，可以是空值。一个表可以有多个外键。 + +## 为什么不推荐使用外键与级联？ + +对于外键和级联，阿里巴巴开发手册这样说到： + +> 【强制】不得使用外键与级联，一切外键概念必须在应用层解决。 +> +> 说明: 以学生和成绩的关系为例，学生表中的 student_id 是主键，那么成绩表中的 student_id 则为外键。如果更新学生表中的 student_id，同时触发成绩表中的 student_id 更新，即为级联更新。外键与级联更新适用于单机低并发，不适合分布式、高并发集群; 级联更新是强阻塞，存在数据库更新风暴的风 险; 外键影响数据库的插入速度 + +为什么不要用外键呢？大部分人可能会这样回答： + +> 1. **增加了复杂性：** a. 每次做DELETE 或者UPDATE都必须考虑外键约束，会导致开发的时候很痛苦, 测试数据极为不方便; b. 外键的主从关系是定的，假如那天需求有变化，数据库中的这个字段根本不需要和其他表有关联的话就会增加很多麻烦。 +> 2. **增加了额外工作**： 数据库需要增加维护外键的工作，比如当我们做一些涉及外键字段的增，删，更新操作之后，需要触发相关操作去检查，保证数据的的一致性和正确性，这样会不得不消耗资源；（个人觉得这个不是不用外键的原因，因为即使你不使用外键，你在应用层面也还是要保证的。所以，我觉得这个影响可以忽略不计。） +> 3. 外键还会因为需要请求对其他表内部加锁而容易出现死锁情况； +> 4. **对分库分表不友好** ：因为分库分表下外键是无法生效的。 +> 5. ...... + +我个人觉得上面这种回答不是特别的全面，只是说了外键存在的一个常见的问题。实际上，我们知道外键也是有很多好处的，比如： + +1. 保证了数据库数据的一致性和完整性； +2. 级联操作方便，减轻了程序代码量； +3. ...... + +所以说，不要一股脑的就抛弃了外键这个概念，既然它存在就有它存在的道理，如果系统不涉及分库分表，并发量不是很高的情况还是可以考虑使用外键的。 + + +## 什么是 ER 图？ + +> 我们做一个项目的时候一定要试着画 ER 图来捋清数据库设计，这个也是面试官问你项目的时候经常会被问道的。 + +**E-R 图** 也称实体-联系图(Entity Relationship Diagram)，提供了表示实体类型、属性和联系的方法，用来描述现实世界的概念模型。 它是描述现实世界关系概念模型的有效方法。 是表示概念关系模型的一种方式。 + +下图是一个学生选课的 ER 图，每个学生可以选若干门课程，同一门课程也可以被若干人选择，所以它们之间的关系是多对多（M: N）。另外，还有其他两种关系是：1 对 1（1:1）、1 对多（1: N）。 + +![ER图示例](https://img-blog.csdnimg.cn/img_convert/4717673e36966e0e4b33fccfd753f6ea.png) + +我们试着将上面的 ER 图转换成数据库实际的关系模型(实际设计中，我们通常会将任课教师也作为一个实体来处理)： + +![关系模型](https://img-blog.csdnimg.cn/img_convert/5897753dfb301dfa3a814ab06e718a5e.png) + +## 数据库范式了解吗? + +**1NF(第一范式)** + +属性（对应于表中的字段）不能再被分割，也就是这个字段只能是一个值，不能再分为多个其他的字段了。**1NF 是所有关系型数据库的最基本要求** ，也就是说关系型数据库中创建的表一定满足第一范式。 + +**2NF(第二范式)** + +2NF 在 1NF 的基础之上，消除了非主属性对于码的部分函数依赖。如下图所示，展示了第一范式到第二范式的过渡。第二范式在第一范式的基础上增加了一个列，这个列称为主键，非主属性都依赖于主键。 + +![第二范式](https://img-blog.csdnimg.cn/img_convert/bd1d31be3779342427fc9e462bf7f05c.png) + +一些重要的概念： + +* **函数依赖（functional dependency）** ：若在一张表中，在属性（或属性组）X 的值确定的情况下，必定能确定属性 Y 的值，那么就可以说 Y 函数依赖于 X，写作 X → Y。 +* **部分函数依赖（partial functional dependency）** ：如果 X→Y，并且存在 X 的一个真子集 X0，使得 X0→Y，则称 Y 对 X 部分函数依赖。比如学生基本信息表 R 中（学号，身份证号，姓名）当然学号属性取值是唯一的，在 R 关系中，（学号，身份证号）->（姓名），（学号）->（姓名），（身份证号）->（姓名）；所以姓名部分函数依赖与（学号，身份证号）； +* **完全函数依赖(Full functional dependency)** ：在一个关系中，若某个非主属性数据项依赖于全部关键字称之为完全函数依赖。比如学生基本信息表 R（学号，班级，姓名）假设不同的班级学号有相同的，班级内学号不能相同，在 R 关系中，（学号，班级）->（姓名），但是（学号）->(姓名)不成立，（班级）->(姓名)不成立，所以姓名完全函数依赖与（学号，班级）； +* **传递函数依赖** ： 在关系模式 R(U)中，设 X，Y，Z 是 U 的不同的属性子集，如果 X 确定 Y、Y 确定 Z，且有 X 不包含 Y，Y 不确定 X，（X∪Y）∩Z=空集合，则称 Z 传递函数依赖(transitive functional dependency) 于 X。传递函数依赖会导致数据冗余和异常。传递函数依赖的 Y 和 Z 子集往往同属于某一个事物，因此可将其合并放到一个表中。比如在关系 R(学号 , 姓名, 系名，系主任)中，学号 → 系名，系名 → 系主任，所以存在非主属性系主任对于学号的传递函数依赖。。 + +**3NF(第三范式)** + +3NF 在 2NF 的基础之上，消除了非主属性对于码的传递函数依赖 。符合 3NF 要求的数据库设计，**基本**上解决了数据冗余过大，插入异常，修改异常，删除异常的问题。比如在关系 R(学号 , 姓名, 系名，系主任)中，学号 → 系名，系名 → 系主任，所以存在非主属性系主任对于学号的传递函数依赖，所以该表的设计，不符合 3NF 的要求。 + +**总结** + +* 1NF：属性不可再分。 +* 2NF：1NF 的基础之上，消除了非主属性对于码的部分函数依赖。 +* 3NF：3NF 在 2NF 的基础之上，消除了非主属性对于码的传递函数依赖 。 + +## 什么是存储过程? + +我们可以把存储过程看成是一些 SQL 语句的集合，中间加了点逻辑控制语句。存储过程在业务比较复杂的时候是非常实用的，比如很多时候我们完成一个操作可能需要写一大串 SQL 语句，这时候我们就可以写有一个存储过程，这样也方便了我们下一次的调用。存储过程一旦调试完成通过后就能稳定运行，另外，使用存储过程比单纯 SQL 语句执行要快，因为存储过程是预编译过的。 + +存储过程在互联网公司应用不多，因为存储过程难以调试和扩展，而且没有移植性，还会消耗数据库资源。 + +阿里巴巴 Java 开发手册里要求禁止使用存储过程。 + +![阿里巴巴Java开发手册: 禁止存储过程](https://img-blog.csdnimg.cn/img_convert/0fa082bc4d4f919065767476a41b2156.png) + +## drop、delete 与 truncate 区别？ + +### 用法不同 + +* drop(丢弃数据): `drop table 表名` ，直接将表都删除掉，在删除表的时候使用。 +* truncate (清空数据) : `truncate table 表名` ，只删除表中的数据，再插入数据的时候自增长 id 又从 1 开始，在清空表中数据的时候使用。 +* delete（删除数据） : `delete from 表名 where 列名=值`，删除某一列的数据，如果不加 where 子句和`truncate table 表名`作用类似。 + +truncate 和不带 where 子句的 delete、以及 drop 都会删除表内的数据，但是 **truncate 和 delete 只删除数据不删除表的结构(定义)，执行 drop 语句，此表的结构也会删除，也就是执行 drop 之后对应的表不复存在。** + +### 属于不同的数据库语言 + +truncate 和 drop 属于 DDL(数据定义语言)语句，操作立即生效，原数据不放到 rollback segment 中，不能回滚，操作不触发 trigger。而 delete 语句是 DML (数据库操作语言)语句，这个操作会放到 rollback segement 中，事务提交之后才生效。 + +**DML 语句和 DDL 语句区别：** + +* DML 是数据库操作语言（Data Manipulation Language）的缩写，是指对数据库中表记录的操作，主要包括表记录的插入（insert）、更新（update）、删除（delete）和查询（select），是开发人员日常使用最频繁的操作。 +* DDL （Data Definition Language）是数据定义语言的缩写，简单来说，就是对数据库内部的对象进行创建、删除、修改的操作语言。它和 DML 语言的最大区别是 DML 只是对表内部数据的操作，而不涉及到表的定义、结构的修改，更不会涉及到其他对象。DDL 语句更多的被数据库管理员（DBA）所使用，一般的开发人员很少使用。 + +> 由于`select`不会对表进行破坏，所以有的地方也会把`select`单独区分开叫做数据库查询语言DQL（Data Query Language） + +### 执行速度不同 + +一般来说：drop > truncate > delete（这个我没有设计测试过）。 +> `delete`命令执行的时候会产生数据库的`binlog`日志，而日志记录是需要消耗时间的，但是也有个好处方便数据回滚恢复。 +> +> `truncate`命令执行的时候不会产生数据库日志，因此比`delete`要快。除此之外，还会把表的自增值重置和索引恢复到初始大小等。 +> +> `drop`命令会把表占用的空间全部释放掉。 +> +> Tips：你应该更多地关注在使用场景上，而不是执行效率。 + +## 数据库设计通常分为哪几步? + +1. **需求分析** : 分析用户的需求，包括数据、功能和性能需求。 +2. **概念结构设计** : 主要采用 E-R 模型进行设计，包括画 E-R 图。 +3. **逻辑结构设计** : 通过将 E-R 图转换成表，实现从 E-R 模型到关系模型的转换。 +4. **物理结构设计** : 主要是为所设计的数据库选择合适的存储结构和存取路径。 +5. **数据库实施** : 包括编程、测试和试运行 +6. **数据库的运行和维护** : 系统的运行与数据库的日常维护。 + +## 参考 + +* +* +* diff --git a/docs/database/character-set.md b/docs/database/character-set.md new file mode 100644 index 0000000000000000000000000000000000000000..1cca2575e6efecc0075388865fd04f9e713cb3e9 --- /dev/null +++ b/docs/database/character-set.md @@ -0,0 +1,160 @@ +--- +title: 字符集 +category: 数据库 +tag: + - 数据库基础 +--- + + +MySQL 字符编码集中有两套 UTF-8 编码实现：**`utf8`** 和 **`utf8mb4`**。 + +如果使用 **`utf8`** 的话，存储emoji 符号和一些比较复杂的汉字、繁体字就会出错。 + +为什么会这样呢？这篇文章可以从源头给你解答。 + +## 何为字符集？ + +字符是各种文字和符号的统称，包括各个国家文字、标点符号、表情、数字等等。 **字符集** 就是一系列字符的集合。字符集的种类较多，每个字符集可以表示的字符范围通常不同，就比如说有些字符集是无法表示汉字的。 + +**计算机只能存储二进制的数据，那英文、汉字、表情等字符应该如何存储呢？** + +我们要将这些字符和二级制的数据一一对应起来，比如说字符“a”对应“01100001”，反之，“01100001”对应 “a”。我们将字符对应二进制数据的过程称为"**字符编码**"，反之，二进制数据解析成字符的过程称为“**字符解码**”。 + +## 有哪些常见的字符集？ + +常见的字符集有 ASCII、GB2312、GBK、UTF-8......。 + +不同的字符集的主要区别在于： + +- 可以表示的字符范围 +- 编码方式 + +### ASCII + +**ASCII** (**A**merican **S**tandard **C**ode for **I**nformation **I**nterchange，美国信息交换标准代码) 是一套主要用于现代美国英语的字符集（这也是 ASCII 字符集的局限性所在）。 + +**为什么 ASCII 字符集没有考虑到中文等其他字符呢？** 因为计算机是美国人发明的，当时，计算机的发展还处于比较雏形的时代，还未在其他国家大规模使用。因此，美国发布 ASCII 字符集的时候没有考虑兼容其他国家的语言。 + +ASCII 字符集至今为止共定义了 128 个字符，其中有 33 个控制字符（比如回车、删除）无法显示。 + +一个 ASCII 码长度是一个字节也就是 8 个 bit，比如“a”对应的 ASCII 码是“01100001”。不过，最高位是 0 仅仅作为校验位，其余 7 位使用 0 和 1 进行组合，所以，ASCII 字符集可以定义 128（2^7）个字符。 + +由于，ASCII 码可以表示的字符实在是太少了。后来，人们对其进行了扩展得到了 **ASCII 扩展字符集** 。ASCII 扩展字符集使用 8 位（bits）表示一个字符，所以，ASCII 扩展字符集可以定义 256（2^8）个字符。 + +![ASCII字符编码](https://img-blog.csdnimg.cn/img_convert/c1c6375d08ca268690cef2b13591a5b4.png) + +### GB2312 + +我们上面说了，ASCII 字符集是一种现代美国英语适用的字符集。因此，很多国家都捣鼓了一个适合自己国家语言的字符集。 + +GB2312 字符集是一种对汉字比较友好的字符集，共收录 6700 多个汉字，基本涵盖了绝大部分常用汉字。不过，GB2312 字符集不支持绝大部分的生僻字和繁体字。 + +对于英语字符，GB2312 编码和 ASCII 码是相同的，1 字节编码即可。对于非英字符，需要 2 字节编码。 + +### GBK + +GBK 字符集可以看作是 GB2312 字符集的扩展，兼容 GB2312 字符集，共收录了 20000 多个汉字。 + +GBK 中 K 是汉语拼音 Kuo Zhan（扩展）中的“Kuo”的首字母。 + +### GB18030 + +GB18030 完全兼容 GB2312 和 GBK 字符集，纳入中国国内少数民族的文字，且收录了日韩汉字，是目前为止最全面的汉字字符集，共收录汉字 70000 多个。 + +### BIG5 + +BIG5 主要针对的是繁体中文，收录了 13000 多个汉字。 + +### Unicode & UTF-8编码 + +为了更加适合本国语言，诞生了很多种字符集。 + +我们上面也说了不同的字符集可以表示的字符范围以及编码规则存在差异。这就导致了一个非常严重的问题：**使用错误的编码方式查看一个包含字符的文件就会产生乱码现象。** + +就比如说你使用 UTF-8 编码方式打开 GB2312 编码格式的文件就会出现乱码。示例：“牛”这个汉字 GB2312 编码后的十六进制数值为 “C5A3”，而 “C5A3” 用 UTF-8 解码之后得到的却是 “ţ”。 + +你可以通过这个网站在线进行编码和解码：https://www.haomeili.net/HanZi/ZiFuBianMaZhuanHuan + +![](https://img-blog.csdnimg.cn/836c49b117ee4408871b0020b74c991d.png) + +这样我们就搞懂了乱码的本质： **编码和解码时用了不同或者不兼容的字符集** 。 + +![](https://guide-blog-images.oss-cn-shenzhen.aliyuncs.com/javaguide/a8808cbabeea49caa3af27d314fa3c02-1.jpg) + +为了解决这个问题，人们就想：“如果我们能够有一种字符集将世界上所有的字符都纳入其中就好了！”。 + +然后，**Unicode** 带着这个使命诞生了。 + +Unicode 字符集中包含了世界上几乎所有已知的字符。不过，Unicode 字符集并没有规定如何存储这些字符（也就是如何使用二进制数据表示这些字符）。 + +然后，就有了 **UTF-8**（**8**-bit **U**nicode **T**ransformation **F**ormat）。类似的还有 UTF-16、 UTF-32。 + +UTF-8 使用 1 到 4 个字节为每个字符编码， UTF-16 使用 2 或 4 个字节为每个字符编码，UTF-32 固定位 4 个字节为每个字符编码。 + +UTF-8 可以根据不同的符号自动选择编码的长短，像英文字符只需要 1 个字节就够了，这一点 ASCII 字符集一样 。因此，对于英语字符，UTF-8 编码和 ASCII 码是相同的。 + +UTF-32 的规则最简单，不过缺陷也比较明显，对于英文字母这类字符消耗的空间是 UTF-8 的 4 倍之多。 + +**UTF-8** 是目前使用最广的一种字符编码，。 + +![](https://guide-blog-images.oss-cn-shenzhen.aliyuncs.com/javaguide/1280px-Utf8webgrowth.svg.png) + +## MySQL 字符集 + +MySQL 支持很多种字符编码的方式，比如 UTF-8、GB2312、GBK、BIG5。 + +你可以通过 `SHOW CHARSET` 命令来查看。 + +![](https://guide-blog-images.oss-cn-shenzhen.aliyuncs.com/javaguide/image-20211008164229671.png) + +通常情况下，我们建议使用 UTF-8 作为默认的字符编码方式。 + +不过，这里有一个小坑。 + +MySQL 字符编码集中有两套 UTF-8 编码实现： + +- **`utf8`** ： `utf8`编码只支持`1-3`个字节 。 在 `utf8` 编码中，中文是占 3 个字节，其他数字、英文、符号占一个字节。但 emoji 符号占 4 个字节，一些较复杂的文字、繁体字也是 4 个字节。 +- **`utf8mb4`** ： UTF-8 的完整实现，正版！最多支持使用 4 个字节表示字符，因此，可以用来存储 emoji 符号。 + +**为什么有两套 UTF-8 编码实现呢？** 原因如下： + +![](https://guide-blog-images.oss-cn-shenzhen.aliyuncs.com/javaguide/image-20211008164542347.png) + +因此，如果你需要存储`emoji`类型的数据或者一些比较复杂的文字、繁体字到 MySQL 数据库的话，数据库的编码一定要指定为`utf8mb4` 而不是`utf8` ，要不然存储的时候就会报错了。 + +演示一下吧！（环境：MySQL 5.7+） + +建表语句如下，我们指定数据库 CHARSET 为 `utf8` 。 + +```sql +CREATE TABLE `user` ( + `id` varchar(66) CHARACTER SET utf8mb4 NOT NULL, + `name` varchar(33) CHARACTER SET utf8mb4 NOT NULL, + `phone` varchar(33) CHARACTER SET utf8mb4 DEFAULT NULL, + `password` varchar(100) CHARACTER SET utf8mb4 DEFAULT NULL +) ENGINE=InnoDB DEFAULT CHARSET=utf8; +``` + +当我们执行下面的 insert 语句插入数据到数据库时，果然报错！ + +```sql +INSERT INTO `user` (`id`, `name`, `phone`, `password`) +VALUES + ('A00003', 'guide哥😘😘😘', '181631312312', '123456'); + +``` + +报错信息如下： + +``` +Incorrect string value: '\xF0\x9F\x98\x98\xF0\x9F...' for column 'name' at row 1 +``` + +## 参考 + +- 字符集和字符编码（Charset & Encoding）： https://www.cnblogs.com/skynet/archive/2011/05/03/2035105.html +- 十分钟搞清字符集和字符编码：http://cenalulu.github.io/linux/character-encoding/ +- Unicode-维基百科：https://zh.wikipedia.org/wiki/Unicode +- GB2312-维基百科：https://zh.wikipedia.org/wiki/GB_2312 +- UTF-8-维基百科：https://zh.wikipedia.org/wiki/UTF-8 +- GB18030-维基百科: https://zh.wikipedia.org/wiki/GB_18030 \ No newline at end of file diff --git a/docs/database/mysql/a-thousand-lines-of-mysql-study-notes.md b/docs/database/mysql/a-thousand-lines-of-mysql-study-notes.md new file mode 100644 index 0000000000000000000000000000000000000000..53350ec5ae75b31fe53de2789d877f83b25913ff --- /dev/null +++ b/docs/database/mysql/a-thousand-lines-of-mysql-study-notes.md @@ -0,0 +1,953 @@ +--- +title: 一千行 MySQL 学习笔记 +category: 数据库 +tag: + - MySQL +--- + +> 原文地址：https://shockerli.net/post/1000-line-mysql-note/ ，JavaGuide 对本文进行了简答排版，新增了目录。 +> 作者：格物 + +非常不错的总结，强烈建议保存下来，需要的时候看一看。 + +### 基本操作 + +```mysql +/* Windows服务 */ +-- 启动MySQL + net start mysql +-- 创建Windows服务 + sc create mysql binPath= mysqld_bin_path(注意：等号与值之间有空格) +/* 连接与断开服务器 */ +mysql -h 地址 -P 端口 -u 用户名 -p 密码 +SHOW PROCESSLIST -- 显示哪些线程正在运行 +SHOW VARIABLES -- 显示系统变量信息 +``` + +### 数据库操作 + +```mysql +/* 数据库操作 */ ------------------ +-- 查看当前数据库 + SELECT DATABASE(); +-- 显示当前时间、用户名、数据库版本 + SELECT now(), user(), version(); +-- 创建库 + CREATE DATABASE[ IF NOT EXISTS] 数据库名 数据库选项 + 数据库选项： + CHARACTER SET charset_name + COLLATE collation_name +-- 查看已有库 + SHOW DATABASES[ LIKE 'PATTERN'] +-- 查看当前库信息 + SHOW CREATE DATABASE 数据库名 +-- 修改库的选项信息 + ALTER DATABASE 库名 选项信息 +-- 删除库 + DROP DATABASE[ IF EXISTS] 数据库名 + 同时删除该数据库相关的目录及其目录内容 +``` + +### 表的操作 + +```mysql +-- 创建表 + CREATE [TEMPORARY] TABLE[ IF NOT EXISTS] [库名.]表名 ( 表的结构定义 )[ 表选项] + 每个字段必须有数据类型 + 最后一个字段后不能有逗号 + TEMPORARY 临时表，会话结束时表自动消失 + 对于字段的定义： + 字段名 数据类型 [NOT NULL | NULL] [DEFAULT default_value] [AUTO_INCREMENT] [UNIQUE [KEY] | [PRIMARY] KEY] [COMMENT 'string'] +-- 表选项 + -- 字符集 + CHARSET = charset_name + 如果表没有设定，则使用数据库字符集 + -- 存储引擎 + ENGINE = engine_name + 表在管理数据时采用的不同的数据结构，结构不同会导致处理方式、提供的特性操作等不同 + 常见的引擎：InnoDB MyISAM Memory/Heap BDB Merge Example CSV MaxDB Archive + 不同的引擎在保存表的结构和数据时采用不同的方式 + MyISAM表文件含义：.frm表定义，.MYD表数据，.MYI表索引 + InnoDB表文件含义：.frm表定义，表空间数据和日志文件 + SHOW ENGINES -- 显示存储引擎的状态信息 + SHOW ENGINE 引擎名 {LOGS|STATUS} -- 显示存储引擎的日志或状态信息 + -- 自增起始数 + AUTO_INCREMENT = 行数 + -- 数据文件目录 + DATA DIRECTORY = '目录' + -- 索引文件目录 + INDEX DIRECTORY = '目录' + -- 表注释 + COMMENT = 'string' + -- 分区选项 + PARTITION BY ... (详细见手册) +-- 查看所有表 + SHOW TABLES[ LIKE 'pattern'] + SHOW TABLES FROM 库名 +-- 查看表结构 + SHOW CREATE TABLE 表名 （信息更详细） + DESC 表名 / DESCRIBE 表名 / EXPLAIN 表名 / SHOW COLUMNS FROM 表名 [LIKE 'PATTERN'] + SHOW TABLE STATUS [FROM db_name] [LIKE 'pattern'] +-- 修改表 + -- 修改表本身的选项 + ALTER TABLE 表名 表的选项 + eg: ALTER TABLE 表名 ENGINE=MYISAM; + -- 对表进行重命名 + RENAME TABLE 原表名 TO 新表名 + RENAME TABLE 原表名 TO 库名.表名 （可将表移动到另一个数据库） + -- RENAME可以交换两个表名 + -- 修改表的字段机构（13.1.2. ALTER TABLE语法） + ALTER TABLE 表名 操作名 + -- 操作名 + ADD[ COLUMN] 字段定义 -- 增加字段 + AFTER 字段名 -- 表示增加在该字段名后面 + FIRST -- 表示增加在第一个 + ADD PRIMARY KEY(字段名) -- 创建主键 + ADD UNIQUE [索引名] (字段名)-- 创建唯一索引 + ADD INDEX [索引名] (字段名) -- 创建普通索引 + DROP[ COLUMN] 字段名 -- 删除字段 + MODIFY[ COLUMN] 字段名 字段属性 -- 支持对字段属性进行修改，不能修改字段名(所有原有属性也需写上) + CHANGE[ COLUMN] 原字段名 新字段名 字段属性 -- 支持对字段名修改 + DROP PRIMARY KEY -- 删除主键(删除主键前需删除其AUTO_INCREMENT属性) + DROP INDEX 索引名 -- 删除索引 + DROP FOREIGN KEY 外键 -- 删除外键 +-- 删除表 + DROP TABLE[ IF EXISTS] 表名 ... +-- 清空表数据 + TRUNCATE [TABLE] 表名 +-- 复制表结构 + CREATE TABLE 表名 LIKE 要复制的表名 +-- 复制表结构和数据 + CREATE TABLE 表名 [AS] SELECT * FROM 要复制的表名 +-- 检查表是否有错误 + CHECK TABLE tbl_name [, tbl_name] ... [option] ... +-- 优化表 + OPTIMIZE [LOCAL | NO_WRITE_TO_BINLOG] TABLE tbl_name [, tbl_name] ... +-- 修复表 + REPAIR [LOCAL | NO_WRITE_TO_BINLOG] TABLE tbl_name [, tbl_name] ... [QUICK] [EXTENDED] [USE_FRM] +-- 分析表 + ANALYZE [LOCAL | NO_WRITE_TO_BINLOG] TABLE tbl_name [, tbl_name] ... +``` + +### 数据操作 + +```mysql +/* 数据操作 */ ------------------ +-- 增 + INSERT [INTO] 表名 [(字段列表)] VALUES (值列表)[, (值列表), ...] + -- 如果要插入的值列表包含所有字段并且顺序一致，则可以省略字段列表。 + -- 可同时插入多条数据记录！ + REPLACE 与 INSERT 完全一样，可互换。 + INSERT [INTO] 表名 SET 字段名=值[, 字段名=值, ...] +-- 查 + SELECT 字段列表 FROM 表名[ 其他子句] + -- 可来自多个表的多个字段 + -- 其他子句可以不使用 + -- 字段列表可以用*代替，表示所有字段 +-- 删 + DELETE FROM 表名[ 删除条件子句] + 没有条件子句，则会删除全部 +-- 改 + UPDATE 表名 SET 字段名=新值[, 字段名=新值] [更新条件] +``` + +### 字符集编码 + +```mysql +/* 字符集编码 */ ------------------ +-- MySQL、数据库、表、字段均可设置编码 +-- 数据编码与客户端编码不需一致 +SHOW VARIABLES LIKE 'character_set_%' -- 查看所有字符集编码项 + character_set_client 客户端向服务器发送数据时使用的编码 + character_set_results 服务器端将结果返回给客户端所使用的编码 + character_set_connection 连接层编码 +SET 变量名 = 变量值 + SET character_set_client = gbk; + SET character_set_results = gbk; + SET character_set_connection = gbk; +SET NAMES GBK; -- 相当于完成以上三个设置 +-- 校对集 + 校对集用以排序 + SHOW CHARACTER SET [LIKE 'pattern']/SHOW CHARSET [LIKE 'pattern'] 查看所有字符集 + SHOW COLLATION [LIKE 'pattern'] 查看所有校对集 + CHARSET 字符集编码 设置字符集编码 + COLLATE 校对集编码 设置校对集编码 +``` + +### 数据类型(列类型) + +```mysql +/* 数据类型（列类型） */ ------------------ +1. 数值类型 +-- a. 整型 ---------- + 类型 字节 范围（有符号位） + tinyint 1字节 -128 ~ 127 无符号位：0 ~ 255 + smallint 2字节 -32768 ~ 32767 + mediumint 3字节 -8388608 ~ 8388607 + int 4字节 + bigint 8字节 + int(M) M表示总位数 + - 默认存在符号位，unsigned 属性修改 + - 显示宽度，如果某个数不够定义字段时设置的位数，则前面以0补填，zerofill 属性修改 + 例：int(5) 插入一个数'123'，补填后为'00123' + - 在满足要求的情况下，越小越好。 + - 1表示bool值真，0表示bool值假。MySQL没有布尔类型，通过整型0和1表示。常用tinyint(1)表示布尔型。 +-- b. 浮点型 ---------- + 类型 字节 范围 + float(单精度) 4字节 + double(双精度) 8字节 + 浮点型既支持符号位 unsigned 属性，也支持显示宽度 zerofill 属性。 + 不同于整型，前后均会补填0. + 定义浮点型时，需指定总位数和小数位数。 + float(M, D) double(M, D) + M表示总位数，D表示小数位数。 + M和D的大小会决定浮点数的范围。不同于整型的固定范围。 + M既表示总位数（不包括小数点和正负号），也表示显示宽度（所有显示符号均包括）。 + 支持科学计数法表示。 + 浮点数表示近似值。 +-- c. 定点数 ---------- + decimal -- 可变长度 + decimal(M, D) M也表示总位数，D表示小数位数。 + 保存一个精确的数值，不会发生数据的改变，不同于浮点数的四舍五入。 + 将浮点数转换为字符串来保存，每9位数字保存为4个字节。 +2. 字符串类型 +-- a. char, varchar ---------- + char 定长字符串，速度快，但浪费空间 + varchar 变长字符串，速度慢，但节省空间 + M表示能存储的最大长度，此长度是字符数，非字节数。 + 不同的编码，所占用的空间不同。 + char,最多255个字符，与编码无关。 + varchar,最多65535字符，与编码有关。 + 一条有效记录最大不能超过65535个字节。 + utf8 最大为21844个字符，gbk 最大为32766个字符，latin1 最大为65532个字符 + varchar 是变长的，需要利用存储空间保存 varchar 的长度，如果数据小于255个字节，则采用一个字节来保存长度，反之需要两个字节来保存。 + varchar 的最大有效长度由最大行大小和使用的字符集确定。 + 最大有效长度是65532字节，因为在varchar存字符串时，第一个字节是空的，不存在任何数据，然后还需两个字节来存放字符串的长度，所以有效长度是65535-1-2=65532字节。 + 例：若一个表定义为 CREATE TABLE tb(c1 int, c2 char(30), c3 varchar(N)) charset=utf8; 问N的最大值是多少？ 答：(65535-1-2-4-30*3)/3 +-- b. blob, text ---------- + blob 二进制字符串（字节字符串） + tinyblob, blob, mediumblob, longblob + text 非二进制字符串（字符字符串） + tinytext, text, mediumtext, longtext + text 在定义时，不需要定义长度，也不会计算总长度。 + text 类型在定义时，不可给default值 +-- c. binary, varbinary ---------- + 类似于char和varchar，用于保存二进制字符串，也就是保存字节字符串而非字符字符串。 + char, varchar, text 对应 binary, varbinary, blob. +3. 日期时间类型 + 一般用整型保存时间戳，因为PHP可以很方便的将时间戳进行格式化。 + datetime 8字节 日期及时间 1000-01-01 00:00:00 到 9999-12-31 23:59:59 + date 3字节 日期 1000-01-01 到 9999-12-31 + timestamp 4字节 时间戳 19700101000000 到 2038-01-19 03:14:07 + time 3字节 时间 -838:59:59 到 838:59:59 + year 1字节 年份 1901 - 2155 +datetime YYYY-MM-DD hh:mm:ss +timestamp YY-MM-DD hh:mm:ss + YYYYMMDDhhmmss + YYMMDDhhmmss + YYYYMMDDhhmmss + YYMMDDhhmmss +date YYYY-MM-DD + YY-MM-DD + YYYYMMDD + YYMMDD + YYYYMMDD + YYMMDD +time hh:mm:ss + hhmmss + hhmmss +year YYYY + YY + YYYY + YY +4. 枚举和集合 +-- 枚举(enum) ---------- +enum(val1, val2, val3...) + 在已知的值中进行单选。最大数量为65535. + 枚举值在保存时，以2个字节的整型(smallint)保存。每个枚举值，按保存的位置顺序，从1开始逐一递增。 + 表现为字符串类型，存储却是整型。 + NULL值的索引是NULL。 + 空字符串错误值的索引值是0。 +-- 集合（set） ---------- +set(val1, val2, val3...) + create table tab ( gender set('男', '女', '无') ); + insert into tab values ('男, 女'); + 最多可以有64个不同的成员。以bigint存储，共8个字节。采取位运算的形式。 + 当创建表时，SET成员值的尾部空格将自动被删除。 +``` + +### 列属性(列约束) + +```mysql +/* 列属性（列约束） */ ------------------ +1. PRIMARY 主键 + - 能唯一标识记录的字段，可以作为主键。 + - 一个表只能有一个主键。 + - 主键具有唯一性。 + - 声明字段时，用 primary key 标识。 + 也可以在字段列表之后声明 + 例：create table tab ( id int, stu varchar(10), primary key (id)); + - 主键字段的值不能为null。 + - 主键可以由多个字段共同组成。此时需要在字段列表后声明的方法。 + 例：create table tab ( id int, stu varchar(10), age int, primary key (stu, age)); +2. UNIQUE 唯一索引（唯一约束） + 使得某字段的值也不能重复。 +3. NULL 约束 + null不是数据类型，是列的一个属性。 + 表示当前列是否可以为null，表示什么都没有。 + null, 允许为空。默认。 + not null, 不允许为空。 + insert into tab values (null, 'val'); + -- 此时表示将第一个字段的值设为null, 取决于该字段是否允许为null +4. DEFAULT 默认值属性 + 当前字段的默认值。 + insert into tab values (default, 'val'); -- 此时表示强制使用默认值。 + create table tab ( add_time timestamp default current_timestamp ); + -- 表示将当前时间的时间戳设为默认值。 + current_date, current_time +5. AUTO_INCREMENT 自动增长约束 + 自动增长必须为索引（主键或unique） + 只能存在一个字段为自动增长。 + 默认为1开始自动增长。可以通过表属性 auto_increment = x进行设置，或 alter table tbl auto_increment = x; +6. COMMENT 注释 + 例：create table tab ( id int ) comment '注释内容'; +7. FOREIGN KEY 外键约束 + 用于限制主表与从表数据完整性。 + alter table t1 add constraint `t1_t2_fk` foreign key (t1_id) references t2(id); + -- 将表t1的t1_id外键关联到表t2的id字段。 + -- 每个外键都有一个名字，可以通过 constraint 指定 + 存在外键的表，称之为从表（子表），外键指向的表，称之为主表（父表）。 + 作用：保持数据一致性，完整性，主要目的是控制存储在外键表（从表）中的数据。 + MySQL中，可以对InnoDB引擎使用外键约束： + 语法： + foreign key (外键字段） references 主表名 (关联字段) [主表记录删除时的动作] [主表记录更新时的动作] + 此时需要检测一个从表的外键需要约束为主表的已存在的值。外键在没有关联的情况下，可以设置为null.前提是该外键列，没有not null。 + 可以不指定主表记录更改或更新时的动作，那么此时主表的操作被拒绝。 + 如果指定了 on update 或 on delete：在删除或更新时，有如下几个操作可以选择： + 1. cascade，级联操作。主表数据被更新（主键值更新），从表也被更新（外键值更新）。主表记录被删除，从表相关记录也被删除。 + 2. set null，设置为null。主表数据被更新（主键值更新），从表的外键被设置为null。主表记录被删除，从表相关记录外键被设置成null。但注意，要求该外键列，没有not null属性约束。 + 3. restrict，拒绝父表删除和更新。 + 注意，外键只被InnoDB存储引擎所支持。其他引擎是不支持的。 + +``` + +### 建表规范 + +```mysql +/* 建表规范 */ ------------------ + -- Normal Format, NF + - 每个表保存一个实体信息 + - 每个具有一个ID字段作为主键 + - ID主键 + 原子表 + -- 1NF, 第一范式 + 字段不能再分，就满足第一范式。 + -- 2NF, 第二范式 + 满足第一范式的前提下，不能出现部分依赖。 + 消除复合主键就可以避免部分依赖。增加单列关键字。 + -- 3NF, 第三范式 + 满足第二范式的前提下，不能出现传递依赖。 + 某个字段依赖于主键，而有其他字段依赖于该字段。这就是传递依赖。 + 将一个实体信息的数据放在一个表内实现。 +``` + +### SELECT + +```mysql +/* SELECT */ ------------------ +SELECT [ALL|DISTINCT] select_expr FROM -> WHERE -> GROUP BY [合计函数] -> HAVING -> ORDER BY -> LIMIT +a. select_expr + -- 可以用 * 表示所有字段。 + select * from tb; + -- 可以使用表达式（计算公式、函数调用、字段也是个表达式） + select stu, 29+25, now() from tb; + -- 可以为每个列使用别名。适用于简化列标识，避免多个列标识符重复。 + - 使用 as 关键字，也可省略 as. + select stu+10 as add10 from tb; +b. FROM 子句 + 用于标识查询来源。 + -- 可以为表起别名。使用as关键字。 + SELECT * FROM tb1 AS tt, tb2 AS bb; + -- from子句后，可以同时出现多个表。 + -- 多个表会横向叠加到一起，而数据会形成一个笛卡尔积。 + SELECT * FROM tb1, tb2; + -- 向优化符提示如何选择索引 + USE INDEX、IGNORE INDEX、FORCE INDEX + SELECT * FROM table1 USE INDEX (key1,key2) WHERE key1=1 AND key2=2 AND key3=3; + SELECT * FROM table1 IGNORE INDEX (key3) WHERE key1=1 AND key2=2 AND key3=3; +c. WHERE 子句 + -- 从from获得的数据源中进行筛选。 + -- 整型1表示真，0表示假。 + -- 表达式由运算符和运算数组成。 + -- 运算数：变量（字段）、值、函数返回值 + -- 运算符： + =, <=>, <>, !=, <=, <, >=, >, !, &&, ||, + in (not) null, (not) like, (not) in, (not) between and, is (not), and, or, not, xor + is/is not 加上ture/false/unknown，检验某个值的真假 + <=>与<>功能相同，<=>可用于null比较 +d. GROUP BY 子句, 分组子句 + GROUP BY 字段/别名 [排序方式] + 分组后会进行排序。升序：ASC，降序：DESC + 以下[合计函数]需配合 GROUP BY 使用： + count 返回不同的非NULL值数目 count(*)、count(字段) + sum 求和 + max 求最大值 + min 求最小值 + avg 求平均值 + group_concat 返回带有来自一个组的连接的非NULL值的字符串结果。组内字符串连接。 +e. HAVING 子句，条件子句 + 与 where 功能、用法相同，执行时机不同。 + where 在开始时执行检测数据，对原数据进行过滤。 + having 对筛选出的结果再次进行过滤。 + having 字段必须是查询出来的，where 字段必须是数据表存在的。 + where 不可以使用字段的别名，having 可以。因为执行WHERE代码时，可能尚未确定列值。 + where 不可以使用合计函数。一般需用合计函数才会用 having + SQL标准要求HAVING必须引用GROUP BY子句中的列或用于合计函数中的列。 +f. ORDER BY 子句，排序子句 + order by 排序字段/别名 排序方式 [,排序字段/别名 排序方式]... + 升序：ASC，降序：DESC + 支持多个字段的排序。 +g. LIMIT 子句，限制结果数量子句 + 仅对处理好的结果进行数量限制。将处理好的结果的看作是一个集合，按照记录出现的顺序，索引从0开始。 + limit 起始位置, 获取条数 + 省略第一个参数，表示从索引0开始。limit 获取条数 +h. DISTINCT, ALL 选项 + distinct 去除重复记录 + 默认为 all, 全部记录 +``` + +### UNION + +```mysql +/* UNION */ ------------------ + 将多个select查询的结果组合成一个结果集合。 + SELECT ... UNION [ALL|DISTINCT] SELECT ... + 默认 DISTINCT 方式，即所有返回的行都是唯一的 + 建议，对每个SELECT查询加上小括号包裹。 + ORDER BY 排序时，需加上 LIMIT 进行结合。 + 需要各select查询的字段数量一样。 + 每个select查询的字段列表(数量、类型)应一致，因为结果中的字段名以第一条select语句为准。 +``` + +### 子查询 + +```mysql +/* 子查询 */ ------------------ + - 子查询需用括号包裹。 +-- from型 + from后要求是一个表，必须给子查询结果取个别名。 + - 简化每个查询内的条件。 + - from型需将结果生成一个临时表格，可用以原表的锁定的释放。 + - 子查询返回一个表，表型子查询。 + select * from (select * from tb where id>0) as subfrom where id>1; +-- where型 + - 子查询返回一个值，标量子查询。 + - 不需要给子查询取别名。 + - where子查询内的表，不能直接用以更新。 + select * from tb where money = (select max(money) from tb); + -- 列子查询 + 如果子查询结果返回的是一列。 + 使用 in 或 not in 完成查询 + exists 和 not exists 条件 + 如果子查询返回数据，则返回1或0。常用于判断条件。 + select column1 from t1 where exists (select * from t2); + -- 行子查询 + 查询条件是一个行。 + select * from t1 where (id, gender) in (select id, gender from t2); + 行构造符：(col1, col2, ...) 或 ROW(col1, col2, ...) + 行构造符通常用于与对能返回两个或两个以上列的子查询进行比较。 + -- 特殊运算符 + != all() 相当于 not in + = some() 相当于 in。any 是 some 的别名 + != some() 不等同于 not in，不等于其中某一个。 + all, some 可以配合其他运算符一起使用。 +``` + +### 连接查询(join) + +```mysql +/* 连接查询(join) */ ------------------ + 将多个表的字段进行连接，可以指定连接条件。 +-- 内连接(inner join) + - 默认就是内连接，可省略inner。 + - 只有数据存在时才能发送连接。即连接结果不能出现空行。 + on 表示连接条件。其条件表达式与where类似。也可以省略条件（表示条件永远为真） + 也可用where表示连接条件。 + 还有 using, 但需字段名相同。 using(字段名) + -- 交叉连接 cross join + 即，没有条件的内连接。 + select * from tb1 cross join tb2; +-- 外连接(outer join) + - 如果数据不存在，也会出现在连接结果中。 + -- 左外连接 left join + 如果数据不存在，左表记录会出现，而右表为null填充 + -- 右外连接 right join + 如果数据不存在，右表记录会出现，而左表为null填充 +-- 自然连接(natural join) + 自动判断连接条件完成连接。 + 相当于省略了using，会自动查找相同字段名。 + natural join + natural left join + natural right join +select info.id, info.name, info.stu_num, extra_info.hobby, extra_info.sex from info, extra_info where info.stu_num = extra_info.stu_id; +``` + +### TRUNCATE + +```mysql +/* TRUNCATE */ ------------------ +TRUNCATE [TABLE] tbl_name +清空数据 +删除重建表 +区别： +1，truncate 是删除表再创建，delete 是逐条删除 +2，truncate 重置auto_increment的值。而delete不会 +3，truncate 不知道删除了几条，而delete知道。 +4，当被用于带分区的表时，truncate 会保留分区 +``` + +### 备份与还原 + +```mysql +/* 备份与还原 */ ------------------ +备份，将数据的结构与表内数据保存起来。 +利用 mysqldump 指令完成。 +-- 导出 +mysqldump [options] db_name [tables] +mysqldump [options] ---database DB1 [DB2 DB3...] +mysqldump [options] --all--database +1. 导出一张表 +　　mysqldump -u用户名 -p密码 库名 表名 > 文件名(D:/a.sql) +2. 导出多张表 +　　mysqldump -u用户名 -p密码 库名 表1 表2 表3 > 文件名(D:/a.sql) +3. 导出所有表 +　　mysqldump -u用户名 -p密码 库名 > 文件名(D:/a.sql) +4. 导出一个库 +　　mysqldump -u用户名 -p密码 --lock-all-tables --database 库名 > 文件名(D:/a.sql) +可以-w携带WHERE条件 +-- 导入 +1. 在登录mysql的情况下： +　　source 备份文件 +2. 在不登录的情况下 +　　mysql -u用户名 -p密码 库名 < 备份文件 +``` + +### 视图 + +```mysql +什么是视图： + 视图是一个虚拟表，其内容由查询定义。同真实的表一样，视图包含一系列带有名称的列和行数据。但是，视图并不在数据库中以存储的数据值集形式存在。行和列数据来自由定义视图的查询所引用的表，并且在引用视图时动态生成。 + 视图具有表结构文件，但不存在数据文件。 + 对其中所引用的基础表来说，视图的作用类似于筛选。定义视图的筛选可以来自当前或其它数据库的一个或多个表，或者其它视图。通过视图进行查询没有任何限制，通过它们进行数据修改时的限制也很少。 + 视图是存储在数据库中的查询的sql语句，它主要出于两种原因：安全原因，视图可以隐藏一些数据，如：社会保险基金表，可以用视图只显示姓名，地址，而不显示社会保险号和工资数等，另一原因是可使复杂的查询易于理解和使用。 +-- 创建视图 +CREATE [OR REPLACE] [ALGORITHM = {UNDEFINED | MERGE | TEMPTABLE}] VIEW view_name [(column_list)] AS select_statement + - 视图名必须唯一，同时不能与表重名。 + - 视图可以使用select语句查询到的列名，也可以自己指定相应的列名。 + - 可以指定视图执行的算法，通过ALGORITHM指定。 + - column_list如果存在，则数目必须等于SELECT语句检索的列数 +-- 查看结构 + SHOW CREATE VIEW view_name +-- 删除视图 + - 删除视图后，数据依然存在。 + - 可同时删除多个视图。 + DROP VIEW [IF EXISTS] view_name ... +-- 修改视图结构 + - 一般不修改视图，因为不是所有的更新视图都会映射到表上。 + ALTER VIEW view_name [(column_list)] AS select_statement +-- 视图作用 + 1. 简化业务逻辑 + 2. 对客户端隐藏真实的表结构 +-- 视图算法(ALGORITHM) + MERGE 合并 + 将视图的查询语句，与外部查询需要先合并再执行！ + TEMPTABLE 临时表 + 将视图执行完毕后，形成临时表，再做外层查询！ + UNDEFINED 未定义(默认)，指的是MySQL自主去选择相应的算法。 +``` + +### 事务(transaction) + +```mysql +事务是指逻辑上的一组操作，组成这组操作的各个单元，要不全成功要不全失败。 + - 支持连续SQL的集体成功或集体撤销。 + - 事务是数据库在数据完整性方面的一个功能。 + - 需要利用 InnoDB 或 BDB 存储引擎，对自动提交的特性支持完成。 + - InnoDB被称为事务安全型引擎。 +-- 事务开启 + START TRANSACTION; 或者 BEGIN; + 开启事务后，所有被执行的SQL语句均被认作当前事务内的SQL语句。 +-- 事务提交 + COMMIT; +-- 事务回滚 + ROLLBACK; + 如果部分操作发生问题，映射到事务开启前。 +-- 事务的特性 + 1. 原子性（Atomicity） + 事务是一个不可分割的工作单位，事务中的操作要么都发生，要么都不发生。 + 2. 一致性（Consistency） + 事务前后数据的完整性必须保持一致。 + - 事务开始和结束时，外部数据一致 + - 在整个事务过程中，操作是连续的 + 3. 隔离性（Isolation） + 多个用户并发访问数据库时，一个用户的事务不能被其它用户的事务所干扰，多个并发事务之间的数据要相互隔离。 + 4. 持久性（Durability） + 一个事务一旦被提交，它对数据库中的数据改变就是永久性的。 +-- 事务的实现 + 1. 要求是事务支持的表类型 + 2. 执行一组相关的操作前开启事务 + 3. 整组操作完成后，都成功，则提交；如果存在失败，选择回滚，则会回到事务开始的备份点。 +-- 事务的原理 + 利用InnoDB的自动提交(autocommit)特性完成。 + 普通的MySQL执行语句后，当前的数据提交操作均可被其他客户端可见。 + 而事务是暂时关闭“自动提交”机制，需要commit提交持久化数据操作。 +-- 注意 + 1. 数据定义语言（DDL）语句不能被回滚，比如创建或取消数据库的语句，和创建、取消或更改表或存储的子程序的语句。 + 2. 事务不能被嵌套 +-- 保存点 + SAVEPOINT 保存点名称 -- 设置一个事务保存点 + ROLLBACK TO SAVEPOINT 保存点名称 -- 回滚到保存点 + RELEASE SAVEPOINT 保存点名称 -- 删除保存点 +-- InnoDB自动提交特性设置 + SET autocommit = 0|1; 0表示关闭自动提交，1表示开启自动提交。 + - 如果关闭了，那普通操作的结果对其他客户端也不可见，需要commit提交后才能持久化数据操作。 + - 也可以关闭自动提交来开启事务。但与START TRANSACTION不同的是， + SET autocommit是永久改变服务器的设置，直到下次再次修改该设置。(针对当前连接) + 而START TRANSACTION记录开启前的状态，而一旦事务提交或回滚后就需要再次开启事务。(针对当前事务) + +``` + +### 锁表 + +```mysql +/* 锁表 */ +表锁定只用于防止其它客户端进行不正当地读取和写入 +MyISAM 支持表锁，InnoDB 支持行锁 +-- 锁定 + LOCK TABLES tbl_name [AS alias] +-- 解锁 + UNLOCK TABLES +``` + +### 触发器 + +```mysql +/* 触发器 */ ------------------ + 触发程序是与表有关的命名数据库对象，当该表出现特定事件时，将激活该对象 + 监听：记录的增加、修改、删除。 +-- 创建触发器 +CREATE TRIGGER trigger_name trigger_time trigger_event ON tbl_name FOR EACH ROW trigger_stmt + 参数： + trigger_time是触发程序的动作时间。它可以是 before 或 after，以指明触发程序是在激活它的语句之前或之后触发。 + trigger_event指明了激活触发程序的语句的类型 + INSERT：将新行插入表时激活触发程序 + UPDATE：更改某一行时激活触发程序 + DELETE：从表中删除某一行时激活触发程序 + tbl_name：监听的表，必须是永久性的表，不能将触发程序与TEMPORARY表或视图关联起来。 + trigger_stmt：当触发程序激活时执行的语句。执行多个语句，可使用BEGIN...END复合语句结构 +-- 删除 +DROP TRIGGER [schema_name.]trigger_name +可以使用old和new代替旧的和新的数据 + 更新操作，更新前是old，更新后是new. + 删除操作，只有old. + 增加操作，只有new. +-- 注意 + 1. 对于具有相同触发程序动作时间和事件的给定表，不能有两个触发程序。 +-- 字符连接函数 +concat(str1,str2,...]) +concat_ws(separator,str1,str2,...) +-- 分支语句 +if 条件 then + 执行语句 +elseif 条件 then + 执行语句 +else + 执行语句 +end if; +-- 修改最外层语句结束符 +delimiter 自定义结束符号 + SQL语句 +自定义结束符号 +delimiter ; -- 修改回原来的分号 +-- 语句块包裹 +begin + 语句块 +end +-- 特殊的执行 +1. 只要添加记录，就会触发程序。 +2. Insert into on duplicate key update 语法会触发： + 如果没有重复记录，会触发 before insert, after insert; + 如果有重复记录并更新，会触发 before insert, before update, after update; + 如果有重复记录但是没有发生更新，则触发 before insert, before update +3. Replace 语法 如果有记录，则执行 before insert, before delete, after delete, after insert +``` + +### SQL编程 + +```mysql +/* SQL编程 */ ------------------ +--// 局部变量 ---------- +-- 变量声明 + declare var_name[,...] type [default value] + 这个语句被用来声明局部变量。要给变量提供一个默认值，请包含一个default子句。值可以被指定为一个表达式，不需要为一个常数。如果没有default子句，初始值为null。 +-- 赋值 + 使用 set 和 select into 语句为变量赋值。 + - 注意：在函数内是可以使用全局变量（用户自定义的变量） +--// 全局变量 ---------- +-- 定义、赋值 +set 语句可以定义并为变量赋值。 +set @var = value; +也可以使用select into语句为变量初始化并赋值。这样要求select语句只能返回一行，但是可以是多个字段，就意味着同时为多个变量进行赋值，变量的数量需要与查询的列数一致。 +还可以把赋值语句看作一个表达式，通过select执行完成。此时为了避免=被当作关系运算符看待，使用:=代替。（set语句可以使用= 和 :=）。 +select @var:=20; +select @v1:=id, @v2=name from t1 limit 1; +select * from tbl_name where @var:=30; +select into 可以将表中查询获得的数据赋给变量。 + -| select max(height) into @max_height from tb; +-- 自定义变量名 +为了避免select语句中，用户自定义的变量与系统标识符（通常是字段名）冲突，用户自定义变量在变量名前使用@作为开始符号。 +@var=10; + - 变量被定义后，在整个会话周期都有效（登录到退出） +--// 控制结构 ---------- +-- if语句 +if search_condition then + statement_list +[elseif search_condition then + statement_list] +... +[else + statement_list] +end if; +-- case语句 +CASE value WHEN [compare-value] THEN result +[WHEN [compare-value] THEN result ...] +[ELSE result] +END +-- while循环 +[begin_label:] while search_condition do + statement_list +end while [end_label]; +- 如果需要在循环内提前终止 while循环，则需要使用标签；标签需要成对出现。 + -- 退出循环 + 退出整个循环 leave + 退出当前循环 iterate + 通过退出的标签决定退出哪个循环 +--// 内置函数 ---------- +-- 数值函数 +abs(x) -- 绝对值 abs(-10.9) = 10 +format(x, d) -- 格式化千分位数值 format(1234567.456, 2) = 1,234,567.46 +ceil(x) -- 向上取整 ceil(10.1) = 11 +floor(x) -- 向下取整 floor (10.1) = 10 +round(x) -- 四舍五入去整 +mod(m, n) -- m%n m mod n 求余 10%3=1 +pi() -- 获得圆周率 +pow(m, n) -- m^n +sqrt(x) -- 算术平方根 +rand() -- 随机数 +truncate(x, d) -- 截取d位小数 +-- 时间日期函数 +now(), current_timestamp(); -- 当前日期时间 +current_date(); -- 当前日期 +current_time(); -- 当前时间 +date('yyyy-mm-dd hh:ii:ss'); -- 获取日期部分 +time('yyyy-mm-dd hh:ii:ss'); -- 获取时间部分 +date_format('yyyy-mm-dd hh:ii:ss', '%d %y %a %d %m %b %j'); -- 格式化时间 +unix_timestamp(); -- 获得unix时间戳 +from_unixtime(); -- 从时间戳获得时间 +-- 字符串函数 +length(string) -- string长度，字节 +char_length(string) -- string的字符个数 +substring(str, position [,length]) -- 从str的position开始,取length个字符 +replace(str ,search_str ,replace_str) -- 在str中用replace_str替换search_str +instr(string ,substring) -- 返回substring首次在string中出现的位置 +concat(string [,...]) -- 连接字串 +charset(str) -- 返回字串字符集 +lcase(string) -- 转换成小写 +left(string, length) -- 从string2中的左边起取length个字符 +load_file(file_name) -- 从文件读取内容 +locate(substring, string [,start_position]) -- 同instr,但可指定开始位置 +lpad(string, length, pad) -- 重复用pad加在string开头,直到字串长度为length +ltrim(string) -- 去除前端空格 +repeat(string, count) -- 重复count次 +rpad(string, length, pad) --在str后用pad补充,直到长度为length +rtrim(string) -- 去除后端空格 +strcmp(string1 ,string2) -- 逐字符比较两字串大小 +-- 流程函数 +case when [condition] then result [when [condition] then result ...] [else result] end 多分支 +if(expr1,expr2,expr3) 双分支。 +-- 聚合函数 +count() +sum(); +max(); +min(); +avg(); +group_concat() +-- 其他常用函数 +md5(); +default(); +--// 存储函数，自定义函数 ---------- +-- 新建 + CREATE FUNCTION function_name (参数列表) RETURNS 返回值类型 + 函数体 + - 函数名，应该合法的标识符，并且不应该与已有的关键字冲突。 + - 一个函数应该属于某个数据库，可以使用db_name.funciton_name的形式执行当前函数所属数据库，否则为当前数据库。 + - 参数部分，由"参数名"和"参数类型"组成。多个参数用逗号隔开。 + - 函数体由多条可用的mysql语句，流程控制，变量声明等语句构成。 + - 多条语句应该使用 begin...end 语句块包含。 + - 一定要有 return 返回值语句。 +-- 删除 + DROP FUNCTION [IF EXISTS] function_name; +-- 查看 + SHOW FUNCTION STATUS LIKE 'partten' + SHOW CREATE FUNCTION function_name; +-- 修改 + ALTER FUNCTION function_name 函数选项 +--// 存储过程，自定义功能 ---------- +-- 定义 +存储存储过程 是一段代码（过程），存储在数据库中的sql组成。 +一个存储过程通常用于完成一段业务逻辑，例如报名，交班费，订单入库等。 +而一个函数通常专注与某个功能，视为其他程序服务的，需要在其他语句中调用函数才可以，而存储过程不能被其他调用，是自己执行 通过call执行。 +-- 创建 +CREATE PROCEDURE sp_name (参数列表) + 过程体 +参数列表：不同于函数的参数列表，需要指明参数类型 +IN，表示输入型 +OUT，表示输出型 +INOUT，表示混合型 +注意，没有返回值。 +``` + +### 存储过程 + +```mysql +/* 存储过程 */ ------------------ +存储过程是一段可执行性代码的集合。相比函数，更偏向于业务逻辑。 +调用：CALL 过程名 +-- 注意 +- 没有返回值。 +- 只能单独调用，不可夹杂在其他语句中 +-- 参数 +IN|OUT|INOUT 参数名 数据类型 +IN 输入：在调用过程中，将数据输入到过程体内部的参数 +OUT 输出：在调用过程中，将过程体处理完的结果返回到客户端 +INOUT 输入输出：既可输入，也可输出 +-- 语法 +CREATE PROCEDURE 过程名 (参数列表) +BEGIN + 过程体 +END +``` + +### 用户和权限管理 + +```mysql +/* 用户和权限管理 */ ------------------ +-- root密码重置 +1. 停止MySQL服务 +2. [Linux] /usr/local/mysql/bin/safe_mysqld --skip-grant-tables & + [Windows] mysqld --skip-grant-tables +3. use mysql; +4. UPDATE `user` SET PASSWORD=PASSWORD("密码") WHERE `user` = "root"; +5. FLUSH PRIVILEGES; +用户信息表：mysql.user +-- 刷新权限 +FLUSH PRIVILEGES; +-- 增加用户 +CREATE USER 用户名 IDENTIFIED BY [PASSWORD] 密码(字符串) + - 必须拥有mysql数据库的全局CREATE USER权限，或拥有INSERT权限。 + - 只能创建用户，不能赋予权限。 + - 用户名，注意引号：如 'user_name'@'192.168.1.1' + - 密码也需引号，纯数字密码也要加引号 + - 要在纯文本中指定密码，需忽略PASSWORD关键词。要把密码指定为由PASSWORD()函数返回的混编值，需包含关键字PASSWORD +-- 重命名用户 +RENAME USER old_user TO new_user +-- 设置密码 +SET PASSWORD = PASSWORD('密码') -- 为当前用户设置密码 +SET PASSWORD FOR 用户名 = PASSWORD('密码') -- 为指定用户设置密码 +-- 删除用户 +DROP USER 用户名 +-- 分配权限/添加用户 +GRANT 权限列表 ON 表名 TO 用户名 [IDENTIFIED BY [PASSWORD] 'password'] + - all privileges 表示所有权限 + - *.* 表示所有库的所有表 + - 库名.表名 表示某库下面的某表 + GRANT ALL PRIVILEGES ON `pms`.* TO 'pms'@'%' IDENTIFIED BY 'pms0817'; +-- 查看权限 +SHOW GRANTS FOR 用户名 + -- 查看当前用户权限 + SHOW GRANTS; 或 SHOW GRANTS FOR CURRENT_USER; 或 SHOW GRANTS FOR CURRENT_USER(); +-- 撤消权限 +REVOKE 权限列表 ON 表名 FROM 用户名 +REVOKE ALL PRIVILEGES, GRANT OPTION FROM 用户名 -- 撤销所有权限 +-- 权限层级 +-- 要使用GRANT或REVOKE，您必须拥有GRANT OPTION权限，并且您必须用于您正在授予或撤销的权限。 +全局层级：全局权限适用于一个给定服务器中的所有数据库，mysql.user + GRANT ALL ON *.*和 REVOKE ALL ON *.*只授予和撤销全局权限。 +数据库层级：数据库权限适用于一个给定数据库中的所有目标，mysql.db, mysql.host + GRANT ALL ON db_name.*和REVOKE ALL ON db_name.*只授予和撤销数据库权限。 +表层级：表权限适用于一个给定表中的所有列，mysql.talbes_priv + GRANT ALL ON db_name.tbl_name和REVOKE ALL ON db_name.tbl_name只授予和撤销表权限。 +列层级：列权限适用于一个给定表中的单一列，mysql.columns_priv + 当使用REVOKE时，您必须指定与被授权列相同的列。 +-- 权限列表 +ALL [PRIVILEGES] -- 设置除GRANT OPTION之外的所有简单权限 +ALTER -- 允许使用ALTER TABLE +ALTER ROUTINE -- 更改或取消已存储的子程序 +CREATE -- 允许使用CREATE TABLE +CREATE ROUTINE -- 创建已存储的子程序 +CREATE TEMPORARY TABLES -- 允许使用CREATE TEMPORARY TABLE +CREATE USER -- 允许使用CREATE USER, DROP USER, RENAME USER和REVOKE ALL PRIVILEGES。 +CREATE VIEW -- 允许使用CREATE VIEW +DELETE -- 允许使用DELETE +DROP -- 允许使用DROP TABLE +EXECUTE -- 允许用户运行已存储的子程序 +FILE -- 允许使用SELECT...INTO OUTFILE和LOAD DATA INFILE +INDEX -- 允许使用CREATE INDEX和DROP INDEX +INSERT -- 允许使用INSERT +LOCK TABLES -- 允许对您拥有SELECT权限的表使用LOCK TABLES +PROCESS -- 允许使用SHOW FULL PROCESSLIST +REFERENCES -- 未被实施 +RELOAD -- 允许使用FLUSH +REPLICATION CLIENT -- 允许用户询问从属服务器或主服务器的地址 +REPLICATION SLAVE -- 用于复制型从属服务器（从主服务器中读取二进制日志事件） +SELECT -- 允许使用SELECT +SHOW DATABASES -- 显示所有数据库 +SHOW VIEW -- 允许使用SHOW CREATE VIEW +SHUTDOWN -- 允许使用mysqladmin shutdown +SUPER -- 允许使用CHANGE MASTER, KILL, PURGE MASTER LOGS和SET GLOBAL语句，mysqladmin debug命令；允许您连接（一次），即使已达到max_connections。 +UPDATE -- 允许使用UPDATE +USAGE -- “无权限”的同义词 +GRANT OPTION -- 允许授予权限 +``` + +### 表维护 + +```mysql +/* 表维护 */ +-- 分析和存储表的关键字分布 +ANALYZE [LOCAL | NO_WRITE_TO_BINLOG] TABLE 表名 ... +-- 检查一个或多个表是否有错误 +CHECK TABLE tbl_name [, tbl_name] ... [option] ... +option = {QUICK | FAST | MEDIUM | EXTENDED | CHANGED} +-- 整理数据文件的碎片 +OPTIMIZE [LOCAL | NO_WRITE_TO_BINLOG] TABLE tbl_name [, tbl_name] ... +``` + +### 杂项 + +```mysql +/* 杂项 */ ------------------ +1. 可用反引号（`）为标识符（库名、表名、字段名、索引、别名）包裹，以避免与关键字重名！中文也可以作为标识符！ +2. 每个库目录存在一个保存当前数据库的选项文件db.opt。 +3. 注释： + 单行注释 # 注释内容 + 多行注释 /* 注释内容 */ + 单行注释 -- 注释内容 (标准SQL注释风格，要求双破折号后加一空格符（空格、TAB、换行等）) +4. 模式通配符： + _ 任意单个字符 + % 任意多个字符，甚至包括零字符 + 单引号需要进行转义 \' +5. CMD命令行内的语句结束符可以为 ";", "\G", "\g"，仅影响显示结果。其他地方还是用分号结束。delimiter 可修改当前对话的语句结束符。 +6. SQL对大小写不敏感 +7. 清除已有语句：\c +``` + diff --git a/docs/database/mysql/how-sql-executed-in-mysql.md b/docs/database/mysql/how-sql-executed-in-mysql.md new file mode 100644 index 0000000000000000000000000000000000000000..5bff9e94b326007120beaf9452487376cc4161ff --- /dev/null +++ b/docs/database/mysql/how-sql-executed-in-mysql.md @@ -0,0 +1,138 @@ +--- +title: 一条 SQL 语句在 MySQL 中如何被执行的? +category: 数据库 +tag: + - MySQL +--- + +本文来自[木木匠](https://github.com/kinglaw1204)投稿。 + +本篇文章会分析下一个 sql 语句在 MySQL 中的执行流程，包括 sql 的查询在 MySQL 内部会怎么流转，sql 语句的更新是怎么完成的。 + +在分析之前我会先带着你看看 MySQL 的基础架构，知道了 MySQL 由那些组件组成以及这些组件的作用是什么，可以帮助我们理解和解决这些问题。 + +## 一 MySQL 基础架构分析 + +### 1.1 MySQL 基本架构概览 + +下图是 MySQL 的一个简要架构图，从下图你可以很清晰的看到用户的 SQL 语句在 MySQL 内部是如何执行的。 + +先简单介绍一下下图涉及的一些组件的基本作用帮助大家理解这幅图，在 1.2 节中会详细介绍到这些组件的作用。 + +- **连接器：** 身份认证和权限相关(登录 MySQL 的时候)。 +- **查询缓存：** 执行查询语句的时候，会先查询缓存（MySQL 8.0 版本后移除，因为这个功能不太实用）。 +- **分析器：** 没有命中缓存的话，SQL 语句就会经过分析器，分析器说白了就是要先看你的 SQL 语句要干嘛，再检查你的 SQL 语句语法是否正确。 +- **优化器：** 按照 MySQL 认为最优的方案去执行。 + + +![](https://guide-blog-images.oss-cn-shenzhen.aliyuncs.com/javaguide/13526879-3037b144ed09eb88.png) + +简单来说 MySQL 主要分为 Server 层和存储引擎层： + +- **Server 层**：主要包括连接器、查询缓存、分析器、优化器、执行器等，所有跨存储引擎的功能都在这一层实现，比如存储过程、触发器、视图，函数等，还有一个通用的日志模块 binlog 日志模块。 +- **存储引擎**： 主要负责数据的存储和读取，采用可以替换的插件式架构，支持 InnoDB、MyISAM、Memory 等多个存储引擎，其中 InnoDB 引擎有自有的日志模块 redolog 模块。**现在最常用的存储引擎是 InnoDB，它从 MySQL 5.5.5 版本开始就被当做默认存储引擎了。** + +### 1.2 Server 层基本组件介绍 + +#### 1) 连接器 + +连接器主要和身份认证和权限相关的功能相关，就好比一个级别很高的门卫一样。 + +主要负责用户登录数据库，进行用户的身份认证，包括校验账户密码，权限等操作，如果用户账户密码已通过，连接器会到权限表中查询该用户的所有权限，之后在这个连接里的权限逻辑判断都是会依赖此时读取到的权限数据，也就是说，后续只要这个连接不断开，即使管理员修改了该用户的权限，该用户也是不受影响的。 + +#### 2) 查询缓存(MySQL 8.0 版本后移除) + +查询缓存主要用来缓存我们所执行的 SELECT 语句以及该语句的结果集。 + +连接建立后，执行查询语句的时候，会先查询缓存，MySQL 会先校验这个 sql 是否执行过，以 Key-Value 的形式缓存在内存中，Key 是查询预计，Value 是结果集。如果缓存 key 被命中，就会直接返回给客户端，如果没有命中，就会执行后续的操作，完成后也会把结果缓存起来，方便下一次调用。当然在真正执行缓存查询的时候还是会校验用户的权限，是否有该表的查询条件。 + +MySQL 查询不建议使用缓存，因为查询缓存失效在实际业务场景中可能会非常频繁，假如你对一个表更新的话，这个表上的所有的查询缓存都会被清空。对于不经常更新的数据来说，使用缓存还是可以的。 + +所以，一般在大多数情况下我们都是不推荐去使用查询缓存的。 + +MySQL 8.0 版本后删除了缓存的功能，官方也是认为该功能在实际的应用场景比较少，所以干脆直接删掉了。 + +#### 3) 分析器 + +MySQL 没有命中缓存，那么就会进入分析器，分析器主要是用来分析 SQL 语句是来干嘛的，分析器也会分为几步： + +**第一步，词法分析**，一条 SQL 语句有多个字符串组成，首先要提取关键字，比如 select，提出查询的表，提出字段名，提出查询条件等等。做完这些操作后，就会进入第二步。 + +**第二步，语法分析**，主要就是判断你输入的 sql 是否正确，是否符合 MySQL 的语法。 + +完成这 2 步之后，MySQL 就准备开始执行了，但是如何执行，怎么执行是最好的结果呢？这个时候就需要优化器上场了。 + +#### 4) 优化器 + +优化器的作用就是它认为的最优的执行方案去执行（有时候可能也不是最优，这篇文章涉及对这部分知识的深入讲解），比如多个索引的时候该如何选择索引，多表查询的时候如何选择关联顺序等。 + +可以说，经过了优化器之后可以说这个语句具体该如何执行就已经定下来。 + +#### 5) 执行器 + +当选择了执行方案后，MySQL 就准备开始执行了，首先执行前会校验该用户有没有权限，如果没有权限，就会返回错误信息，如果有权限，就会去调用引擎的接口，返回接口执行的结果。 + +## 二 语句分析 + +### 2.1 查询语句 + +说了以上这么多，那么究竟一条 sql 语句是如何执行的呢？其实我们的 sql 可以分为两种，一种是查询，一种是更新（增加，更新，删除）。我们先分析下查询语句，语句如下： + +```sql +select * from tb_student A where A.age='18' and A.name=' 张三 '; +``` + +结合上面的说明，我们分析下这个语句的执行流程： + +* 先检查该语句是否有权限，如果没有权限，直接返回错误信息，如果有权限，在 MySQL8.0 版本以前，会先查询缓存，以这条 sql 语句为 key 在内存中查询是否有结果，如果有直接缓存，如果没有，执行下一步。 +* 通过分析器进行词法分析，提取 sql 语句的关键元素，比如提取上面这个语句是查询 select，提取需要查询的表名为 tb_student，需要查询所有的列，查询条件是这个表的 id='1'。然后判断这个 sql 语句是否有语法错误，比如关键词是否正确等等，如果检查没问题就执行下一步。 +* 接下来就是优化器进行确定执行方案，上面的 sql 语句，可以有两种执行方案： + + a.先查询学生表中姓名为“张三”的学生，然后判断是否年龄是 18。 + b.先找出学生中年龄 18 岁的学生，然后再查询姓名为“张三”的学生。 + 那么优化器根据自己的优化算法进行选择执行效率最好的一个方案（优化器认为，有时候不一定最好）。那么确认了执行计划后就准备开始执行了。 + +* 进行权限校验，如果没有权限就会返回错误信息，如果有权限就会调用数据库引擎接口，返回引擎的执行结果。 + +### 2.2 更新语句 + +以上就是一条查询 sql 的执行流程，那么接下来我们看看一条更新语句如何执行的呢？sql 语句如下： + +``` +update tb_student A set A.age='19' where A.name=' 张三 '; +``` +我们来给张三修改下年龄，在实际数据库肯定不会设置年龄这个字段的，不然要被技术负责人打的。其实这条语句也基本上会沿着上一个查询的流程走，只不过执行更新的时候肯定要记录日志啦，这就会引入日志模块了，MySQL 自带的日志模块是 **binlog（归档日志）** ，所有的存储引擎都可以使用，我们常用的 InnoDB 引擎还自带了一个日志模块 **redo log（重做日志）**，我们就以 InnoDB 模式下来探讨这个语句的执行流程。流程如下： + +* 先查询到张三这一条数据，如果有缓存，也是会用到缓存。 +* 然后拿到查询的语句，把 age 改为 19，然后调用引擎 API 接口，写入这一行数据，InnoDB 引擎把数据保存在内存中，同时记录 redo log，此时 redo log 进入 prepare 状态，然后告诉执行器，执行完成了，随时可以提交。 +* 执行器收到通知后记录 binlog，然后调用引擎接口，提交 redo log 为提交状态。 +* 更新完成。 + +**这里肯定有同学会问，为什么要用两个日志模块，用一个日志模块不行吗?** + +这是因为最开始 MySQL 并没有 InnoDB 引擎（InnoDB 引擎是其他公司以插件形式插入 MySQL 的），MySQL 自带的引擎是 MyISAM，但是我们知道 redo log 是 InnoDB 引擎特有的，其他存储引擎都没有，这就导致会没有 crash-safe 的能力(crash-safe 的能力即使数据库发生异常重启，之前提交的记录都不会丢失)，binlog 日志只能用来归档。 + +并不是说只用一个日志模块不可以，只是 InnoDB 引擎就是通过 redo log 来支持事务的。那么，又会有同学问，我用两个日志模块，但是不要这么复杂行不行，为什么 redo log 要引入 prepare 预提交状态？这里我们用反证法来说明下为什么要这么做？ + +* **先写 redo log 直接提交，然后写 binlog**，假设写完 redo log 后，机器挂了，binlog 日志没有被写入，那么机器重启后，这台机器会通过 redo log 恢复数据，但是这个时候 binlog 并没有记录该数据，后续进行机器备份的时候，就会丢失这一条数据，同时主从同步也会丢失这一条数据。 +* **先写 binlog，然后写 redo log**，假设写完了 binlog，机器异常重启了，由于没有 redo log，本机是无法恢复这一条记录的，但是 binlog 又有记录，那么和上面同样的道理，就会产生数据不一致的情况。 + +如果采用 redo log 两阶段提交的方式就不一样了，写完 binlog 后，然后再提交 redo log 就会防止出现上述的问题，从而保证了数据的一致性。那么问题来了，有没有一个极端的情况呢？假设 redo log 处于预提交状态，binlog 也已经写完了，这个时候发生了异常重启会怎么样呢？ +这个就要依赖于 MySQL 的处理机制了，MySQL 的处理过程如下： + +* 判断 redo log 是否完整，如果判断是完整的，就立即提交。 +* 如果 redo log 只是预提交但不是 commit 状态，这个时候就会去判断 binlog 是否完整，如果完整就提交 redo log, 不完整就回滚事务。 + +这样就解决了数据一致性的问题。 + +## 三 总结 + +* MySQL 主要分为 Server 层和引擎层，Server 层主要包括连接器、查询缓存、分析器、优化器、执行器，同时还有一个日志模块（binlog），这个日志模块所有执行引擎都可以共用，redolog 只有 InnoDB 有。 +* 引擎层是插件式的，目前主要包括，MyISAM,InnoDB,Memory 等。 +* 查询语句的执行流程如下：权限校验（如果命中缓存）--->查询缓存--->分析器--->优化器--->权限校验--->执行器--->引擎 +* 更新语句执行流程如下：分析器---->权限校验---->执行器--->引擎---redo log(prepare 状态)--->binlog--->redo log(commit状态) + +## 四 参考 + +* 《MySQL 实战45讲》 +* MySQL 5.6参考手册: diff --git a/docs/database/mysql/innodb-implementation-of-mvcc.md b/docs/database/mysql/innodb-implementation-of-mvcc.md new file mode 100644 index 0000000000000000000000000000000000000000..96fa1f7982b501c328234d22e908e4a9e2c0a5b1 --- /dev/null +++ b/docs/database/mysql/innodb-implementation-of-mvcc.md @@ -0,0 +1,226 @@ +--- +title: InnoDB存储引擎对MVCC的实现 +category: 数据库 +tag: + - MySQL +--- + +## 一致性非锁定读和锁定读 + +### 一致性非锁定读 + +对于 [**一致性非锁定读（Consistent Nonlocking Reads）** ](https://dev.mysql.com/doc/refman/5.7/en/innodb-consistent-read.html)的实现，通常做法是加一个版本号或者时间戳字段，在更新数据的同时版本号 + 1 或者更新时间戳。查询时，将当前可见的版本号与对应记录的版本号进行比对，如果记录的版本小于可见版本，则表示该记录可见 + +在 `InnoDB` 存储引擎中，[多版本控制 (multi versioning)](https://dev.mysql.com/doc/refman/5.7/en/innodb-multi-versioning.html) 就是对非锁定读的实现。如果读取的行正在执行 `DELETE` 或 `UPDATE` 操作，这时读取操作不会去等待行上锁的释放。相反地，`InnoDB` 存储引擎会去读取行的一个快照数据，对于这种读取历史数据的方式，我们叫它快照读 (snapshot read) + +在 `Repeatable Read` 和 `Read Committed` 两个隔离级别下，如果是执行普通的 `select` 语句（不包括 `select ... lock in share mode` ,`select ... for update`）则会使用 `一致性非锁定读（MVCC）`。并且在 `Repeatable Read` 下 `MVCC` 实现了可重复读和防止部分幻读 + +### 锁定读 + +如果执行的是下列语句，就是 [**锁定读（Locking Reads）**](https://dev.mysql.com/doc/refman/5.7/en/innodb-locking-reads.html) + +- `select ... lock in share mode` +- `select ... for update` +- `insert`、`update`、`delete` 操作 + +在锁定读下，读取的是数据的最新版本，这种读也被称为 `当前读（current read）`。锁定读会对读取到的记录加锁： + +- `select ... lock in share mode`：对记录加 `S` 锁，其它事务也可以加`S`锁，如果加 `x` 锁则会被阻塞 + +- `select ... for update`、`insert`、`update`、`delete`：对记录加 `X` 锁，且其它事务不能加任何锁 + +在一致性非锁定读下，即使读取的记录已被其它事务加上 `X` 锁，这时记录也是可以被读取的，即读取的快照数据。上面说了，在 `Repeatable Read` 下 `MVCC` 防止了部分幻读，这边的 “部分” 是指在 `一致性非锁定读` 情况下，只能读取到第一次查询之前所插入的数据（根据 Read View 判断数据可见性，Read View 在第一次查询时生成）。但是！如果是 `当前读` ，每次读取的都是最新数据，这时如果两次查询中间有其它事务插入数据，就会产生幻读。所以， **`InnoDB` 在实现`Repeatable Read` 时，如果执行的是当前读，则会对读取的记录使用 `Next-key Lock` ，来防止其它事务在间隙间插入数据** + +## InnoDB 对 MVCC 的实现 + +`MVCC` 的实现依赖于：**隐藏字段、Read View、undo log**。在内部实现中，`InnoDB` 通过数据行的 `DB_TRX_ID` 和 `Read View` 来判断数据的可见性，如不可见，则通过数据行的 `DB_ROLL_PTR` 找到 `undo log` 中的历史版本。每个事务读到的数据版本可能是不一样的，在同一个事务中，用户只能看到该事务创建 `Read View` 之前已经提交的修改和该事务本身做的修改 + +### 隐藏字段 + +在内部，`InnoDB` 存储引擎为每行数据添加了三个 [隐藏字段](https://dev.mysql.com/doc/refman/5.7/en/innodb-multi-versioning.html)： + +- `DB_TRX_ID（6字节）`：表示最后一次插入或更新该行的事务 id。此外，`delete` 操作在内部被视为更新，只不过会在记录头 `Record header` 中的 `deleted_flag` 字段将其标记为已删除 +- `DB_ROLL_PTR（7字节）` 回滚指针，指向该行的 `undo log` 。如果该行未被更新，则为空 +- `DB_ROW_ID（6字节）`：如果没有设置主键且该表没有唯一非空索引时，`InnoDB` 会使用该 id 来生成聚簇索引 + +### ReadView + +```c +class ReadView { + /* ... */ +private: + trx_id_t m_low_limit_id; /* 大于等于这个 ID 的事务均不可见 */ + + trx_id_t m_up_limit_id; /* 小于这个 ID 的事务均可见 */ + + trx_id_t m_creator_trx_id; /* 创建该 Read View 的事务ID */ + + trx_id_t m_low_limit_no; /* 事务 Number, 小于该 Number 的 Undo Logs 均可以被 Purge */ + + ids_t m_ids; /* 创建 Read View 时的活跃事务列表 */ + + m_closed; /* 标记 Read View 是否 close */ +} +``` + +[`Read View`](https://github.com/facebook/mysql-8.0/blob/8.0/storage/innobase/include/read0types.h#L298) 主要是用来做可见性判断，里面保存了 “当前对本事务不可见的其他活跃事务” + +主要有以下字段： + +- `m_low_limit_id`：目前出现过的最大的事务 ID+1，即下一个将被分配的事务 ID。大于等于这个 ID 的数据版本均不可见 +- `m_up_limit_id`：活跃事务列表 `m_ids` 中最小的事务 ID，如果 `m_ids` 为空，则 `m_up_limit_id` 为 `m_low_limit_id`。小于这个 ID 的数据版本均可见 +- `m_ids`：`Read View` 创建时其他未提交的活跃事务 ID 列表。创建 `Read View`时，将当前未提交事务 ID 记录下来，后续即使它们修改了记录行的值，对于当前事务也是不可见的。`m_ids` 不包括当前事务自己和已提交的事务（正在内存中） +- `m_creator_trx_id`：创建该 `Read View` 的事务 ID + +**事务可见性示意图**（[图源](https://leviathan.vip/2019/03/20/InnoDB%E7%9A%84%E4%BA%8B%E5%8A%A1%E5%88%86%E6%9E%90-MVCC/#MVCC-1)）： + +![trans_visible](https://leviathan.vip/2019/03/20/InnoDB%E7%9A%84%E4%BA%8B%E5%8A%A1%E5%88%86%E6%9E%90-MVCC/trans_visible.jpg) + +### undo-log + +`undo log` 主要有两个作用： + +- 当事务回滚时用于将数据恢复到修改前的样子 +- 另一个作用是 `MVCC` ，当读取记录时，若该记录被其他事务占用或当前版本对该事务不可见，则可以通过 `undo log` 读取之前的版本数据，以此实现非锁定读 + +**在 `InnoDB` 存储引擎中 `undo log` 分为两种： `insert undo log` 和 `update undo log`：** + +1. **`insert undo log`** ：指在 `insert` 操作中产生的 `undo log`。因为 `insert` 操作的记录只对事务本身可见，对其他事务不可见，故该 `undo log` 可以在事务提交后直接删除。不需要进行 `purge` 操作 + +**`insert` 时的数据初始状态：** + +![](https://ddmcc-1255635056.file.myqcloud.com/317e91e1-1ee1-42ad-9412-9098d5c6a9ad.png) + +2. **`update undo log`** ：`update` 或 `delete` 操作中产生的 `undo log`。该 `undo log`可能需要提供 `MVCC` 机制，因此不能在事务提交时就进行删除。提交时放入 `undo log` 链表，等待 `purge线程` 进行最后的删除 + +**数据第一次被修改时：** + +![](https://ddmcc-1255635056.file.myqcloud.com/c52ff79f-10e6-46cb-b5d4-3c9cbcc1934a.png) + +**数据第二次被修改时：** + +![](https://ddmcc-1255635056.file.myqcloud.com/6a276e7a-b0da-4c7b-bdf7-c0c7b7b3b31c.png) + +不同事务或者相同事务的对同一记录行的修改，会使该记录行的 `undo log` 成为一条链表，链首就是最新的记录，链尾就是最早的旧记录。 + +### 数据可见性算法 + +在 `InnoDB` 存储引擎中，创建一个新事务后，执行每个 `select` 语句前，都会创建一个快照（Read View），**快照中保存了当前数据库系统中正处于活跃（没有 commit）的事务的 ID 号**。其实简单的说保存的是系统中当前不应该被本事务看到的其他事务 ID 列表（即 m_ids）。当用户在这个事务中要读取某个记录行的时候，`InnoDB` 会将该记录行的 `DB_TRX_ID` 与 `Read View` 中的一些变量及当前事务 ID 进行比较，判断是否满足可见性条件 + +[具体的比较算法](https://github.com/facebook/mysql-8.0/blob/8.0/storage/innobase/include/read0types.h#L161)如下：[图源](https://leviathan.vip/2019/03/20/InnoDB%E7%9A%84%E4%BA%8B%E5%8A%A1%E5%88%86%E6%9E%90-MVCC/#MVCC-1) + +![](https://ddmcc-1255635056.file.myqcloud.com/8778836b-34a8-480b-b8c7-654fe207a8c2.png) + +1. 如果记录 DB_TRX_ID < m_up_limit_id，那么表明最新修改该行的事务（DB_TRX_ID）在当前事务创建快照之前就提交了，所以该记录行的值对当前事务是可见的 + +2. 如果 DB_TRX_ID >= m_low_limit_id，那么表明最新修改该行的事务（DB_TRX_ID）在当前事务创建快照之后才修改该行，所以该记录行的值对当前事务不可见。跳到步骤 5 + +3. m_ids 为空，则表明在当前事务创建快照之前，修改该行的事务就已经提交了，所以该记录行的值对当前事务是可见的 + +4. 如果 m_up_limit_id <= DB_TRX_ID < m_low_limit_id，表明最新修改该行的事务（DB_TRX_ID）在当前事务创建快照的时候可能处于“活动状态”或者“已提交状态”；所以就要对活跃事务列表 m_ids 进行查找（源码中是用的二分查找，因为是有序的） + + - 如果在活跃事务列表 m_ids 中能找到 DB_TRX_ID，表明：① 在当前事务创建快照前，该记录行的值被事务 ID 为 DB_TRX_ID 的事务修改了，但没有提交；或者 ② 在当前事务创建快照后，该记录行的值被事务 ID 为 DB_TRX_ID 的事务修改了。这些情况下，这个记录行的值对当前事务都是不可见的。跳到步骤 5 + + - 在活跃事务列表中找不到，则表明“id 为 trx_id 的事务”在修改“该记录行的值”后，在“当前事务”创建快照前就已经提交了，所以记录行对当前事务可见 + +5. 在该记录行的 DB_ROLL_PTR 指针所指向的 `undo log` 取出快照记录，用快照记录的 DB_TRX_ID 跳到步骤 1 重新开始判断，直到找到满足的快照版本或返回空 + +## RC 和 RR 隔离级别下 MVCC 的差异 + +在事务隔离级别 `RC` 和 `RR` （InnoDB 存储引擎的默认事务隔离级别）下，`InnoDB` 存储引擎使用 `MVCC`（非锁定一致性读），但它们生成 `Read View` 的时机却不同 + +- 在 RC 隔离级别下的 **`每次select`** 查询前都生成一个`Read View` (m_ids 列表) +- 在 RR 隔离级别下只在事务开始后 **`第一次select`** 数据前生成一个`Read View`（m_ids 列表） + +## MVCC 解决不可重复读问题 + +虽然 RC 和 RR 都通过 `MVCC` 来读取快照数据，但由于 **生成 Read View 时机不同**，从而在 RR 级别下实现可重复读 + +举个例子： + +![](https://ddmcc-1255635056.file.myqcloud.com/6fb2b9a1-5f14-4dec-a797-e4cf388ed413.png) + +### 在 RC 下 ReadView 生成情况 + +1. **`假设时间线来到 T4 ，那么此时数据行 id = 1 的版本链为`：** + + ![](https://ddmcc-1255635056.file.myqcloud.com/a3fd1ec6-8f37-42fa-b090-7446d488fd04.png) + +由于 RC 级别下每次查询都会生成`Read View` ，并且事务 101、102 并未提交，此时 `103` 事务生成的 `Read View` 中活跃的事务 **`m_ids` 为：[101,102]** ，`m_low_limit_id`为：104，`m_up_limit_id`为：101，`m_creator_trx_id` 为：103 + +- 此时最新记录的 `DB_TRX_ID` 为 101，m_up_limit_id <= 101 < m_low_limit_id，所以要在 `m_ids` 列表中查找，发现 `DB_TRX_ID` 存在列表中，那么这个记录不可见 +- 根据 `DB_ROLL_PTR` 找到 `undo log` 中的上一版本记录，上一条记录的 `DB_TRX_ID` 还是 101，不可见 +- 继续找上一条 `DB_TRX_ID`为 1，满足 1 < m_up_limit_id，可见，所以事务 103 查询到数据为 `name = 菜花` + +2. **`时间线来到 T6 ，数据的版本链为`：** + + ![markdown](https://ddmcc-1255635056.file.myqcloud.com/528559e9-dae8-4d14-b78d-a5b657c88391.png) + +因为在 RC 级别下，重新生成 `Read View`，这时事务 101 已经提交，102 并未提交，所以此时 `Read View` 中活跃的事务 **`m_ids`：[102]** ，`m_low_limit_id`为：104，`m_up_limit_id`为：102，`m_creator_trx_id`为：103 + +- 此时最新记录的 `DB_TRX_ID` 为 102，m_up_limit_id <= 102 < m_low_limit_id，所以要在 `m_ids` 列表中查找，发现 `DB_TRX_ID` 存在列表中，那么这个记录不可见 + +- 根据 `DB_ROLL_PTR` 找到 `undo log` 中的上一版本记录，上一条记录的 `DB_TRX_ID` 为 101，满足 101 < m_up_limit_id，记录可见，所以在 `T6` 时间点查询到数据为 `name = 李四`，与时间 T4 查询到的结果不一致，不可重复读！ + +3. **`时间线来到 T9 ，数据的版本链为`：** + +![markdown](https://ddmcc-1255635056.file.myqcloud.com/6f82703c-36a1-4458-90fe-d7f4edbac71a.png) + +重新生成 `Read View`， 这时事务 101 和 102 都已经提交，所以 **m_ids** 为空，则 m_up_limit_id = m_low_limit_id = 104，最新版本事务 ID 为 102，满足 102 < m_low_limit_id，可见，查询结果为 `name = 赵六` + +> **总结：** **在 RC 隔离级别下，事务在每次查询开始时都会生成并设置新的 Read View，所以导致不可重复读** + +### 在 RR 下 ReadView 生成情况 + +**在可重复读级别下，只会在事务开始后第一次读取数据时生成一个 Read View（m_ids 列表）** + +1. **`在 T4 情况下的版本链为`：** + +![markdown](https://ddmcc-1255635056.file.myqcloud.com/0e906b95-c916-4f30-beda-9cb3e49746bf.png) + +在当前执行 `select` 语句时生成一个 `Read View`，此时 **`m_ids`：[101,102]** ，`m_low_limit_id`为：104，`m_up_limit_id`为：101，`m_creator_trx_id` 为：103 + +此时和 RC 级别下一样： + +- 最新记录的 `DB_TRX_ID` 为 101，m_up_limit_id <= 101 < m_low_limit_id，所以要在 `m_ids` 列表中查找，发现 `DB_TRX_ID` 存在列表中，那么这个记录不可见 +- 根据 `DB_ROLL_PTR` 找到 `undo log` 中的上一版本记录，上一条记录的 `DB_TRX_ID` 还是 101，不可见 +- 继续找上一条 `DB_TRX_ID`为 1，满足 1 < m_up_limit_id，可见，所以事务 103 查询到数据为 `name = 菜花` + +2. **`时间点 T6 情况下`：** + + ![markdown](https://ddmcc-1255635056.file.myqcloud.com/79ed6142-7664-4e0b-9023-cf546586aa39.png) + + 在 RR 级别下只会生成一次`Read View`，所以此时依然沿用 **`m_ids` ：[101,102]** ，`m_low_limit_id`为：104，`m_up_limit_id`为：101，`m_creator_trx_id` 为：103 + +- 最新记录的 `DB_TRX_ID` 为 102，m_up_limit_id <= 102 < m_low_limit_id，所以要在 `m_ids` 列表中查找，发现 `DB_TRX_ID` 存在列表中，那么这个记录不可见 + +- 根据 `DB_ROLL_PTR` 找到 `undo log` 中的上一版本记录，上一条记录的 `DB_TRX_ID` 为 101，不可见 + +- 继续根据 `DB_ROLL_PTR` 找到 `undo log` 中的上一版本记录，上一条记录的 `DB_TRX_ID` 还是 101，不可见 + +- 继续找上一条 `DB_TRX_ID`为 1，满足 1 < m_up_limit_id，可见，所以事务 103 查询到数据为 `name = 菜花` + +3. **时间点 T9 情况下：** + +![markdown](https://ddmcc-1255635056.file.myqcloud.com/cbbedbc5-0e3c-4711-aafd-7f3d68a4ed4e.png) + +此时情况跟 T6 完全一样，由于已经生成了 `Read View`，此时依然沿用 **`m_ids` ：[101,102]** ，所以查询结果依然是 `name = 菜花` + +## MVCC➕Next-key-Lock 防止幻读 + +`InnoDB`存储引擎在 RR 级别下通过 `MVCC`和 `Next-key Lock` 来解决幻读问题： + +**1、执行普通 `select`，此时会以 `MVCC` 快照读的方式读取数据** + +在快照读的情况下，RR 隔离级别只会在事务开启后的第一次查询生成 `Read View` ，并使用至事务提交。所以在生成 `Read View` 之后其它事务所做的更新、插入记录版本对当前事务并不可见，实现了可重复读和防止快照读下的 “幻读” + +**2、执行 select...for update/lock in share mode、insert、update、delete 等当前读** + +在当前读下，读取的都是最新的数据，如果其它事务有插入新的记录，并且刚好在当前事务查询范围内，就会产生幻读！`InnoDB` 使用 [Next-key Lock](https://dev.mysql.com/doc/refman/5.7/en/innodb-locking.html#innodb-next-key-locks) 来防止这种情况。当执行当前读时，会锁定读取到的记录的同时，锁定它们的间隙，防止其它事务在查询范围内插入数据。只要我不让你插入，就不会发生幻读 + +## 参考 + +- **《MySQL 技术内幕 InnoDB 存储引擎第 2 版》** +- [Innodb 中的事务隔离级别和锁的关系](https://tech.meituan.com/2014/08/20/innodb-lock.html) +- [MySQL 事务与 MVCC 如何实现的隔离级别](https://blog.csdn.net/qq_35190492/article/details/109044141) +- [InnoDB 事务分析-MVCC](https://leviathan.vip/2019/03/20/InnoDB%E7%9A%84%E4%BA%8B%E5%8A%A1%E5%88%86%E6%9E%90-MVCC/) diff --git a/docs/database/mysql/mysql-high-performance-optimization-specification-recommendations.md b/docs/database/mysql/mysql-high-performance-optimization-specification-recommendations.md new file mode 100644 index 0000000000000000000000000000000000000000..7c2b7def8ad61a79774630cb195b2771029750d9 --- /dev/null +++ b/docs/database/mysql/mysql-high-performance-optimization-specification-recommendations.md @@ -0,0 +1,396 @@ +--- +title: MySQL 高性能优化规范建议 +category: 数据库 +tag: + - MySQL +--- + +> 作者: 听风，原文地址: 。JavaGuide 已获得作者授权。 + +## 数据库命令规范 + +- 所有数据库对象名称必须使用小写字母并用下划线分割 +- 所有数据库对象名称禁止使用 MySQL 保留关键字（如果表名中包含关键字查询时，需要将其用单引号括起来） +- 数据库对象的命名要能做到见名识意，并且最后不要超过 32 个字符 +- 临时库表必须以 tmp_为前缀并以日期为后缀，备份表必须以 bak_为前缀并以日期 (时间戳) 为后缀 +- 所有存储相同数据的列名和列类型必须一致（一般作为关联列，如果查询时关联列类型不一致会自动进行数据类型隐式转换，会造成列上的索引失效，导致查询效率降低） + +------ + +## 数据库基本设计规范 + +### 1. 所有表必须使用 Innodb 存储引擎 + +没有特殊要求（即 Innodb 无法满足的功能如：列存储，存储空间数据等）的情况下，所有表必须使用 Innodb 存储引擎（MySQL5.5 之前默认使用 Myisam，5.6 以后默认的为 Innodb）。 + +Innodb 支持事务，支持行级锁，更好的恢复性，高并发下性能更好。 + +### 2. 数据库和表的字符集统一使用 UTF8 + +兼容性更好，统一字符集可以避免由于字符集转换产生的乱码，不同的字符集进行比较前需要进行转换会造成索引失效，如果数据库中有存储 emoji 表情的需要，字符集需要采用 utf8mb4 字符集。 + +参考文章：[MySQL 字符集不一致导致索引失效的一个真实案例](https://blog.csdn.net/horses/article/details/107243447) + +### 3. 所有表和字段都需要添加注释 + +使用 comment 从句添加表和列的备注，从一开始就进行数据字典的维护 + +### 4. 尽量控制单表数据量的大小,建议控制在 500 万以内。 + +500 万并不是 MySQL 数据库的限制，过大会造成修改表结构，备份，恢复都会有很大的问题。 + +可以用历史数据归档（应用于日志数据），分库分表（应用于业务数据）等手段来控制数据量大小 + +### 5. 谨慎使用 MySQL 分区表 + +分区表在物理上表现为多个文件，在逻辑上表现为一个表； + +谨慎选择分区键，跨分区查询效率可能更低； + +建议采用物理分表的方式管理大数据。 + +### 6.尽量做到冷热数据分离,减小表的宽度 + +> MySQL 限制每个表最多存储 4096 列，并且每一行数据的大小不能超过 65535 字节。 + +减少磁盘 IO,保证热数据的内存缓存命中率（表越宽，把表装载进内存缓冲池时所占用的内存也就越大,也会消耗更多的 IO）； + +更有效的利用缓存，避免读入无用的冷数据； + +经常一起使用的列放到一个表中（避免更多的关联操作）。 + +### 7. 禁止在表中建立预留字段 + +预留字段的命名很难做到见名识义。 + +预留字段无法确认存储的数据类型，所以无法选择合适的类型。 + +对预留字段类型的修改，会对表进行锁定。 + +### 8. 禁止在数据库中存储图片,文件等大的二进制数据 + +通常文件很大，会短时间内造成数据量快速增长，数据库进行数据库读取时，通常会进行大量的随机 IO 操作，文件很大时，IO 操作很耗时。 + +通常存储于文件服务器，数据库只存储文件地址信息 + +### 9. 禁止在线上做数据库压力测试 + +### 10. 禁止从开发环境,测试环境直接连接生产环境数据库 + +------ + +## 数据库字段设计规范 + +### 1. 优先选择符合存储需要的最小的数据类型 + +**原因：** + +列的字段越大，建立索引时所需要的空间也就越大，这样一页中所能存储的索引节点的数量也就越少也越少，在遍历时所需要的 IO 次数也就越多，索引的性能也就越差。 + +**方法：** + +**a.将字符串转换成数字类型存储,如:将 IP 地址转换成整形数据** + +MySQL 提供了两个方法来处理 ip 地址 + +- inet_aton 把 ip 转为无符号整型 (4-8 位) +- inet_ntoa 把整型的 ip 转为地址 + +插入数据前，先用 inet_aton 把 ip 地址转为整型，可以节省空间，显示数据时，使用 inet_ntoa 把整型的 ip 地址转为地址显示即可。 + +**b.对于非负型的数据 (如自增 ID,整型 IP) 来说,要优先使用无符号整型来存储** + +**原因：** + +无符号相对于有符号可以多出一倍的存储空间 + +``` +SIGNED INT -2147483648~2147483647 +UNSIGNED INT 0~4294967295 +``` + +VARCHAR(N) 中的 N 代表的是字符数，而不是字节数，使用 UTF8 存储 255 个汉字 Varchar(255)=765 个字节。**过大的长度会消耗更多的内存。** + +### 2. 避免使用 TEXT,BLOB 数据类型，最常见的 TEXT 类型可以存储 64k 的数据 + +**a. 建议把 BLOB 或是 TEXT 列分离到单独的扩展表中** + +MySQL 内存临时表不支持 TEXT、BLOB 这样的大数据类型，如果查询中包含这样的数据，在排序等操作时，就不能使用内存临时表，必须使用磁盘临时表进行。而且对于这种数据，MySQL 还是要进行二次查询，会使 sql 性能变得很差，但是不是说一定不能使用这样的数据类型。 + +如果一定要使用，建议把 BLOB 或是 TEXT 列分离到单独的扩展表中，查询时一定不要使用 select * 而只需要取出必要的列，不需要 TEXT 列的数据时不要对该列进行查询。 + +**2、TEXT 或 BLOB 类型只能使用前缀索引** + +因为[MySQL](https://mp.weixin.qq.com/s?__biz=MzI4Njc5NjM1NQ==&mid=2247487885&idx=1&sn=65b1bf5f7d4505502620179669a9c2df&chksm=ebd62ea1dca1a7b7bf884bcd9d538d78ba064ee03c09436ca8e57873b1d98a55afd6d7884cfc&scene=21#wechat_redirect) 对索引字段长度是有限制的，所以 TEXT 类型只能使用前缀索引，并且 TEXT 列上是不能有默认值的 + +### 3. 避免使用 ENUM 类型 + +修改 ENUM 值需要使用 ALTER 语句 + +ENUM 类型的 ORDER BY 操作效率低，需要额外操作 + +禁止使用数值作为 ENUM 的枚举值 + +### 4. 尽可能把所有列定义为 NOT NULL + +**原因：** + +索引 NULL 列需要额外的空间来保存，所以要占用更多的空间 + +进行比较和计算时要对 NULL 值做特别的处理 + +### 5. 使用 TIMESTAMP(4 个字节) 或 DATETIME 类型 (8 个字节) 存储时间 + +TIMESTAMP 存储的时间范围 1970-01-01 00:00:01 ~ 2038-01-19-03:14:07 + +TIMESTAMP 占用 4 字节和 INT 相同，但比 INT 可读性高 + +超出 TIMESTAMP 取值范围的使用 DATETIME 类型存储 + +**经常会有人用字符串存储日期型的数据（不正确的做法）** + +- 缺点 1：无法用日期函数进行计算和比较 +- 缺点 2：用字符串存储日期要占用更多的空间 + +### 6. 同财务相关的金额类数据必须使用 decimal 类型 + +- 非精准浮点：float,double +- 精准浮点：decimal + +Decimal 类型为精准浮点数，在计算时不会丢失精度 + +占用空间由定义的宽度决定，每 4 个字节可以存储 9 位数字，并且小数点要占用一个字节 + +可用于存储比 bigint 更大的整型数据 + +------ + +## 索引设计规范 + +### 1. 限制每张表上的索引数量,建议单张表索引不超过 5 个 + +索引并不是越多越好！索引可以提高效率同样可以降低效率。 + +索引可以增加查询效率，但同样也会降低插入和更新的效率，甚至有些情况下会降低查询效率。 + +因为 MySQL 优化器在选择如何优化查询时，会根据统一信息，对每一个可以用到的索引来进行评估，以生成出一个最好的执行计划，如果同时有很多个索引都可以用于查询，就会增加 MySQL 优化器生成执行计划的时间，同样会降低查询性能。 + +### 2. 禁止给表中的每一列都建立单独的索引 + +5.6 版本之前，一个 sql 只能使用到一个表中的一个索引，5.6 以后，虽然有了合并索引的优化方式，但是还是远远没有使用一个联合索引的查询方式好。 + +### 3. 每个 Innodb 表必须有个主键 + +Innodb 是一种索引组织表：数据的存储的逻辑顺序和索引的顺序是相同的。每个表都可以有多个索引，但是表的存储顺序只能有一种。 + +Innodb 是按照主键索引的顺序来组织表的 + +- 不要使用更新频繁的列作为主键，不适用多列主键（相当于联合索引） +- 不要使用 UUID,MD5,HASH,字符串列作为主键（无法保证数据的顺序增长） +- 主键建议使用自增 ID 值 + +------ + +### 4. 常见索引列建议 + +- 出现在 SELECT、UPDATE、DELETE 语句的 WHERE 从句中的列 +- 包含在 ORDER BY、GROUP BY、DISTINCT 中的字段 +- 并不要将符合 1 和 2 中的字段的列都建立一个索引， 通常将 1、2 中的字段建立联合索引效果更好 +- 多表 join 的关联列 + +------ + +### 5.如何选择索引列的顺序 + +建立索引的目的是：希望通过索引进行数据查找，减少随机 IO，增加查询性能 ，索引能过滤出越少的数据，则从磁盘中读入的数据也就越少。 + +- 区分度最高的放在联合索引的最左侧（区分度=列中不同值的数量/列的总行数） +- 尽量把字段长度小的列放在联合索引的最左侧（因为字段长度越小，一页能存储的数据量越大，IO 性能也就越好） +- 使用最频繁的列放到联合索引的左侧（这样可以比较少的建立一些索引） + +------ + +### 6. 避免建立冗余索引和重复索引（增加了查询优化器生成执行计划的时间） + +- 重复索引示例：primary key(id)、index(id)、unique index(id) +- 冗余索引示例：index(a,b,c)、index(a,b)、index(a) + +------ + +### 7. 对于频繁的查询优先考虑使用覆盖索引 + +> 覆盖索引：就是包含了所有查询字段 (where,select,order by,group by 包含的字段) 的索引 + +**覆盖索引的好处：** + +- **避免 Innodb 表进行索引的二次查询:** Innodb 是以聚集索引的顺序来存储的，对于 Innodb 来说，二级索引在叶子节点中所保存的是行的主键信息，如果是用二级索引查询数据的话，在查找到相应的键值后，还要通过主键进行二次查询才能获取我们真实所需要的数据。而在覆盖索引中，二级索引的键值中可以获取所有的数据，避免了对主键的二次查询 ，减少了 IO 操作，提升了查询效率。 +- **可以把随机 IO 变成顺序 IO 加快查询效率:** 由于覆盖索引是按键值的顺序存储的，对于 IO 密集型的范围查找来说，对比随机从磁盘读取每一行的数据 IO 要少的多，因此利用覆盖索引在访问时也可以把磁盘的随机读取的 IO 转变成索引查找的顺序 IO。 + +------ + +### 8.索引 SET 规范 + +**尽量避免使用外键约束** + +- 不建议使用外键约束（foreign key），但一定要在表与表之间的关联键上建立索引 +- 外键可用于保证数据的参照完整性，但建议在业务端实现 +- 外键会影响父表和子表的写操作从而降低性能 + +------ + +## 数据库 SQL 开发规范 + +### 1. 建议使用预编译语句进行数据库操作 + +预编译语句可以重复使用这些计划，减少 SQL 编译所需要的时间，还可以解决动态 SQL 所带来的 SQL 注入的问题。 + +只传参数，比传递 SQL 语句更高效。 + +相同语句可以一次解析，多次使用，提高处理效率。 + +### 2. 避免数据类型的隐式转换 + +隐式转换会导致索引失效如: + +``` +select name,phone from customer where id = '111'; +``` + +### 3. 充分利用表上已经存在的索引 + +避免使用双%号的查询条件。如：`a like '%123%'`，（如果无前置%,只有后置%，是可以用到列上的索引的） + +一个 SQL 只能利用到复合索引中的一列进行范围查询。如：有 a,b,c 列的联合索引，在查询条件中有 a 列的范围查询，则在 b,c 列上的索引将不会被用到。 + +在定义联合索引时，如果 a 列要用到范围查找的话，就要把 a 列放到联合索引的右侧，使用 left join 或 not exists 来优化 not in 操作，因为 not in 也通常会使用索引失效。 + +### 4. 数据库设计时，应该要对以后扩展进行考虑 + +### 5. 程序连接不同的数据库使用不同的账号，禁止跨库查询 + +- 为数据库迁移和分库分表留出余地 +- 降低业务耦合度 +- 避免权限过大而产生的安全风险 + +### 6. 禁止使用 SELECT * 必须使用 SELECT <字段列表> 查询 + +**原因：** + +- 消耗更多的 CPU 和 IO 以网络带宽资源 +- 无法使用覆盖索引 +- 可减少表结构变更带来的影响 + +### 7. 禁止使用不含字段列表的 INSERT 语句 + +如： + +``` +insert into values ('a','b','c'); +``` + +应使用： + +``` +insert into t(c1,c2,c3) values ('a','b','c'); +``` + +### 8. 避免使用子查询，可以把子查询优化为 join 操作 + +通常子查询在 in 子句中，且子查询中为简单 SQL(不包含 union、group by、order by、limit 从句) 时,才可以把子查询转化为关联查询进行优化。 + +**子查询性能差的原因：** + +子查询的结果集无法使用索引，通常子查询的结果集会被存储到临时表中，不论是内存临时表还是磁盘临时表都不会存在索引，所以查询性能会受到一定的影响。特别是对于返回结果集比较大的子查询，其对查询性能的影响也就越大。 + +由于子查询会产生大量的临时表也没有索引，所以会消耗过多的 CPU 和 IO 资源，产生大量的慢查询。 + +### 9. 避免使用 JOIN 关联太多的表 + +对于 MySQL 来说，是存在关联缓存的，缓存的大小可以由 join_buffer_size 参数进行设置。 + +在 MySQL 中，对于同一个 SQL 多关联（join）一个表，就会多分配一个关联缓存，如果在一个 SQL 中关联的表越多，所占用的内存也就越大。 + +如果程序中大量的使用了多表关联的操作，同时 join_buffer_size 设置的也不合理的情况下，就容易造成服务器内存溢出的情况，就会影响到服务器数据库性能的稳定性。 + +同时对于关联操作来说，会产生临时表操作，影响查询效率，MySQL 最多允许关联 61 个表，建议不超过 5 个。 + +### 10. 减少同数据库的交互次数 + +数据库更适合处理批量操作，合并多个相同的操作到一起，可以提高处理效率。 + +### 11. 对应同一列进行 or 判断时，使用 in 代替 or + +in 的值不要超过 500 个，in 操作可以更有效的利用索引，or 大多数情况下很少能利用到索引。 + +### 12. 禁止使用 order by rand() 进行随机排序 + +order by rand() 会把表中所有符合条件的数据装载到内存中，然后在内存中对所有数据根据随机生成的值进行排序，并且可能会对每一行都生成一个随机值，如果满足条件的数据集非常大，就会消耗大量的 CPU 和 IO 及内存资源。 + +推荐在程序中获取一个随机值，然后从数据库中获取数据的方式。 + +### 13. WHERE 从句中禁止对列进行函数转换和计算 + +对列进行函数转换或计算时会导致无法使用索引 + +**不推荐：** + +``` +where date(create_time)='20190101' +``` + +**推荐：** + +``` +where create_time >= '20190101' and create_time < '20190102' +``` + +### 14. 在明显不会有重复值时使用 UNION ALL 而不是 UNION + +- UNION 会把两个结果集的所有数据放到临时表中后再进行去重操作 +- UNION ALL 不会再对结果集进行去重操作 + +### 15. 拆分复杂的大 SQL 为多个小 SQL + +- 大 SQL 逻辑上比较复杂，需要占用大量 CPU 进行计算的 SQL +- MySQL 中，一个 SQL 只能使用一个 CPU 进行计算 +- SQL 拆分后可以通过并行执行来提高处理效率 + +------ + +## 数据库操作行为规范 + +### 1. 超 100 万行的批量写 (UPDATE,DELETE,INSERT) 操作,要分批多次进行操作 + +**大批量操作可能会造成严重的主从延迟** + +主从环境中,大批量操作可能会造成严重的主从延迟，大批量的写操作一般都需要执行一定长的时间， +而只有当主库上执行完成后，才会在其他从库上执行，所以会造成主库与从库长时间的延迟情况 + +**binlog 日志为 row 格式时会产生大量的日志** + +大批量写操作会产生大量日志，特别是对于 row 格式二进制数据而言，由于在 row 格式中会记录每一行数据的修改，我们一次修改的数据越多，产生的日志量也就会越多，日志的传输和恢复所需要的时间也就越长，这也是造成主从延迟的一个原因 + +**避免产生大事务操作** + +大批量修改数据，一定是在一个事务中进行的，这就会造成表中大批量数据进行锁定，从而导致大量的阻塞，阻塞会对 MySQL 的性能产生非常大的影响。 + +特别是长时间的阻塞会占满所有数据库的可用连接，这会使生产环境中的其他应用无法连接到数据库，因此一定要注意大批量写操作要进行分批 + +### 2. 对于大表使用 pt-online-schema-change 修改表结构 + +- 避免大表修改产生的主从延迟 +- 避免在对表字段进行修改时进行锁表 + +对大表数据结构的修改一定要谨慎，会造成严重的锁表操作，尤其是生产环境，是不能容忍的。 + +pt-online-schema-change 它会首先建立一个与原表结构相同的新表，并且在新表上进行表结构的修改，然后再把原表中的数据复制到新表中，并在原表中增加一些触发器。把原表中新增的数据也复制到新表中，在行所有数据复制完成之后，把新表命名成原表，并把原来的表删除掉。把原来一个 DDL 操作，分解成多个小的批次进行。 + +### 3. 禁止为程序使用的账号赋予 super 权限 + +- 当达到最大连接数限制时，还运行 1 个有 super 权限的用户连接 +- super 权限只能留给 DBA 处理问题的账号使用 + +### 4. 对于程序连接数据库账号,遵循权限最小原则 + +- 程序使用数据库账号只能在一个 DB 下使用，不准跨库 +- 程序使用的账号原则上不准有 drop 权限 diff --git a/docs/database/mysql/mysql-index.md b/docs/database/mysql/mysql-index.md new file mode 100644 index 0000000000000000000000000000000000000000..04a46e4406205c4713b4c8334dc3f9fa06d7d49b --- /dev/null +++ b/docs/database/mysql/mysql-index.md @@ -0,0 +1,266 @@ +--- +title: MySQL 索引详解 +category: 数据库 +tag: + - MySQL +--- + + + +## 何为索引？有什么作用？ + +**索引是一种用于快速查询和检索数据的数据结构。常见的索引结构有: B 树， B+树和 Hash。** + +索引的作用就相当于目录的作用。打个比方: 我们在查字典的时候，如果没有目录，那我们就只能一页一页的去找我们需要查的那个字，速度很慢。如果有目录了，我们只需要先去目录里查找字的位置，然后直接翻到那一页就行了。 + +## 索引的优缺点 + +**优点** ： + +- 使用索引可以大大加快 数据的检索速度（大大减少检索的数据量）, 这也是创建索引的最主要的原因。 +- 通过创建唯一性索引，可以保证数据库表中每一行数据的唯一性。 + +**缺点** ： + +- 创建索引和维护索引需要耗费许多时间。当对表中的数据进行增删改的时候，如果数据有索引，那么索引也需要动态的修改，会降低 SQL 执行效率。 +- 索引需要使用物理文件存储，也会耗费一定空间。 + +但是，**使用索引一定能提高查询性能吗?** + +大多数情况下，索引查询都是比全表扫描要快的。但是如果数据库的数据量不大，那么使用索引也不一定能够带来很大提升。 + +## 索引的底层数据结构 + +### Hash表 & B+树 + +哈希表是键值对的集合，通过键(key)即可快速取出对应的值(value)，因此哈希表可以快速检索数据（接近 O（1））。 + +**为何能够通过 key 快速取出 value呢？** 原因在于 **哈希算法**（也叫散列算法）。通过哈希算法，我们可以快速找到 value 对应的 index，找到了 index 也就找到了对应的 value。 + +```java +hash = hashfunc(key) +index = hash % array_size +``` + + + +![](https://img-blog.csdnimg.cn/20210513092328171.png) + +但是！哈希算法有个 **Hash 冲突** 问题，也就是说多个不同的 key 最后得到的 index 相同。通常情况下，我们常用的解决办法是 **链地址法**。链地址法就是将哈希冲突数据存放在链表中。就比如 JDK1.8 之前 `HashMap` 就是通过链地址法来解决哈希冲突的。不过，JDK1.8 以后`HashMap`为了减少链表过长的时候搜索时间过长引入了红黑树。 + +![](https://img-blog.csdnimg.cn/20210513092224836.png) + +为了减少 Hash 冲突的发生，一个好的哈希函数应该“均匀地”将数据分布在整个可能的哈希值集合中。 + +既然哈希表这么快，**为什么MySQL 没有使用其作为索引的数据结构呢？** + +**1.Hash 冲突问题** ：我们上面也提到过Hash 冲突了，不过对于数据库来说这还不算最大的缺点。 + +**2.Hash 索引不支持顺序和范围查询(Hash 索引不支持顺序和范围查询是它最大的缺点：** 假如我们要对表中的数据进行排序或者进行范围查询，那 Hash 索引可就不行了。 + +试想一种情况: + +```java +SELECT * FROM tb1 WHERE id < 500;Copy to clipboardErrorCopied +``` + +在这种范围查询中，优势非常大，直接遍历比 500 小的叶子节点就够了。而 Hash 索引是根据 hash 算法来定位的，难不成还要把 1 - 499 的数据，每个都进行一次 hash 计算来定位吗?这就是 Hash 最大的缺点了。 + +### B 树& B+树 + +B 树也称 B-树,全称为 **多路平衡查找树** ，B+ 树是 B 树的一种变体。B 树和 B+树中的 B 是 `Balanced` （平衡）的意思。 + +目前大部分数据库系统及文件系统都采用 B-Tree 或其变种 B+Tree 作为索引结构。 + +**B 树& B+树两者有何异同呢？** + +- B 树的所有节点既存放键(key) 也存放 数据(data)，而 B+树只有叶子节点存放 key 和 data，其他内节点只存放 key。 +- B 树的叶子节点都是独立的;B+树的叶子节点有一条引用链指向与它相邻的叶子节点。 +- B 树的检索的过程相当于对范围内的每个节点的关键字做二分查找，可能还没有到达叶子节点，检索就结束了。而 B+树的检索效率就很稳定了，任何查找都是从根节点到叶子节点的过程，叶子节点的顺序检索很明显。 + +![](https://img-blog.csdnimg.cn/20210420165409106.png) + +在 MySQL 中，MyISAM 引擎和 InnoDB 引擎都是使用 B+Tree 作为索引结构，但是，两者的实现方式不太一样。（下面的内容整理自《Java 工程师修炼之道》） + +MyISAM 引擎中，B+Tree 叶节点的 data 域存放的是数据记录的地址。在索引检索的时候，首先按照 B+Tree 搜索算法搜索索引，如果指定的 Key 存在，则取出其 data 域的值，然后以 data 域的值为地址读取相应的数据记录。这被称为“非聚簇索引”。 + +InnoDB 引擎中，其数据文件本身就是索引文件。相比 MyISAM，索引文件和数据文件是分离的，其表数据文件本身就是按 B+Tree 组织的一个索引结构，树的叶节点 data 域保存了完整的数据记录。这个索引的 key 是数据表的主键，因此 InnoDB 表数据文件本身就是主索引。这被称为“聚簇索引（或聚集索引）”，而其余的索引都作为辅助索引，辅助索引的 data 域存储相应记录主键的值而不是地址，这也是和 MyISAM 不同的地方。在根据主索引搜索时，直接找到 key 所在的节点即可取出数据；在根据辅助索引查找时，则需要先取出主键的值，再走一遍主索引。 因此，在设计表的时候，不建议使用过长的字段作为主键，也不建议使用非单调的字段作为主键，这样会造成主索引频繁分裂。 + +## 索引类型 + +### 主键索引(Primary Key) + +数据表的主键列使用的就是主键索引。 + +一张数据表有只能有一个主键，并且主键不能为 null，不能重复。 + +在 MySQL 的 InnoDB 的表中，当没有显示的指定表的主键时，InnoDB 会自动先检查表中是否有唯一索引且不允许存在null值的字段，如果有，则选择该字段为默认的主键，否则 InnoDB 将会自动创建一个 6Byte 的自增主键。 + +### 二级索引(辅助索引) + +**二级索引又称为辅助索引，是因为二级索引的叶子节点存储的数据是主键。也就是说，通过二级索引，可以定位主键的位置。** + +唯一索引，普通索引，前缀索引等索引属于二级索引。 + +**PS:不懂的同学可以暂存疑，慢慢往下看，后面会有答案的，也可以自行搜索。** + +1. **唯一索引(Unique Key)** ：唯一索引也是一种约束。**唯一索引的属性列不能出现重复的数据，但是允许数据为 NULL，一张表允许创建多个唯一索引。** 建立唯一索引的目的大部分时候都是为了该属性列的数据的唯一性，而不是为了查询效率。 +2. **普通索引(Index)** ：**普通索引的唯一作用就是为了快速查询数据，一张表允许创建多个普通索引，并允许数据重复和 NULL。** +3. **前缀索引(Prefix)** ：前缀索引只适用于字符串类型的数据。前缀索引是对文本的前几个字符创建索引，相比普通索引建立的数据更小， + 因为只取前几个字符。 +4. **全文索引(Full Text)** ：全文索引主要是为了检索大文本数据中的关键字的信息，是目前搜索引擎数据库使用的一种技术。Mysql5.6 之前只有 MYISAM 引擎支持全文索引，5.6 之后 InnoDB 也支持了全文索引。 + +二级索引: +![](https://img-blog.csdnimg.cn/20210420165254215.png) + +## 聚集索引与非聚集索引 + +### 聚集索引 + +**聚集索引即索引结构和数据一起存放的索引。主键索引属于聚集索引。** + +在 Mysql 中，InnoDB 引擎的表的 `.ibd`文件就包含了该表的索引和数据，对于 InnoDB 引擎表来说，该表的索引(B+树)的每个非叶子节点存储索引，叶子节点存储索引和索引对应的数据。 + +#### 聚集索引的优点 + +聚集索引的查询速度非常的快，因为整个 B+树本身就是一颗多叉平衡树，叶子节点也都是有序的，定位到索引的节点，就相当于定位到了数据。 + +#### 聚集索引的缺点 + +1. **依赖于有序的数据** ：因为 B+树是多路平衡树，如果索引的数据不是有序的，那么就需要在插入时排序，如果数据是整型还好，否则类似于字符串或 UUID 这种又长又难比较的数据，插入或查找的速度肯定比较慢。 +2. **更新代价大** ： 如果对索引列的数据被修改时，那么对应的索引也将会被修改， + 而且况聚集索引的叶子节点还存放着数据，修改代价肯定是较大的， + 所以对于主键索引来说，主键一般都是不可被修改的。 + +### 非聚集索引 + +**非聚集索引即索引结构和数据分开存放的索引。** + +**二级索引属于非聚集索引。** + +> MYISAM 引擎的表的.MYI 文件包含了表的索引， +> 该表的索引(B+树)的每个叶子非叶子节点存储索引， +> 叶子节点存储索引和索引对应数据的指针，指向.MYD 文件的数据。 +> +> **非聚集索引的叶子节点并不一定存放数据的指针， +> 因为二级索引的叶子节点就存放的是主键，根据主键再回表查数据。** + +#### 非聚集索引的优点 + +**更新代价比聚集索引要小** 。非聚集索引的更新代价就没有聚集索引那么大了，非聚集索引的叶子节点是不存放数据的 + +#### 非聚集索引的缺点 + +1. 跟聚集索引一样，非聚集索引也依赖于有序的数据 +2. **可能会二次查询(回表)** :这应该是非聚集索引最大的缺点了。 当查到索引对应的指针或主键后，可能还需要根据指针或主键再到数据文件或表中查询。 + +这是 MySQL 的表的文件截图: + +![](https://img-blog.csdnimg.cn/20210420165311654.png) + +聚集索引和非聚集索引: + +![](https://img-blog.csdnimg.cn/20210420165326946.png) + +### 非聚集索引一定回表查询吗(覆盖索引)? + +**非聚集索引不一定回表查询。** + +> 试想一种情况，用户准备使用 SQL 查询用户名，而用户名字段正好建立了索引。 + +```text + SELECT name FROM table WHERE name='guang19'; +``` + +> 那么这个索引的 key 本身就是 name，查到对应的 name 直接返回就行了，无需回表查询。 + +**即使是 MYISAM 也是这样，虽然 MYISAM 的主键索引确实需要回表， +因为它的主键索引的叶子节点存放的是指针。但是如果 SQL 查的就是主键呢?** + +```text +SELECT id FROM table WHERE id=1; +``` + +主键索引本身的 key 就是主键，查到返回就行了。这种情况就称之为覆盖索引了。 + +## 覆盖索引 + +如果一个索引包含（或者说覆盖）所有需要查询的字段的值，我们就称之为“覆盖索引”。我们知道在 InnoDB 存储引擎中，如果不是主键索引，叶子节点存储的是主键+列值。最终还是要“回表”，也就是要通过主键再查找一次。这样就会比较慢覆盖索引就是把要查询出的列和索引是对应的，不做回表操作！ + +**覆盖索引即需要查询的字段正好是索引的字段，那么直接根据该索引，就可以查到数据了， +而无需回表查询。** + +> 如主键索引，如果一条 SQL 需要查询主键，那么正好根据主键索引就可以查到主键。 +> +> 再如普通索引，如果一条 SQL 需要查询 name，name 字段正好有索引， +> 那么直接根据这个索引就可以查到数据，也无需回表。 + +覆盖索引: +![](https://img-blog.csdnimg.cn/20210420165341868.png) + +## 创建索引的注意事项 + +**1.选择合适的字段创建索引：** + +- **不为 NULL 的字段** ：索引字段的数据应该尽量不为 NULL，因为对于数据为 NULL 的字段，数据库较难优化。如果字段频繁被查询，但又避免不了为 NULL，建议使用 0,1,true,false 这样语义较为清晰的短值或短字符作为替代。 +- **被频繁查询的字段** ：我们创建索引的字段应该是查询操作非常频繁的字段。 +- **被作为条件查询的字段** ：被作为 WHERE 条件查询的字段，应该被考虑建立索引。 +- **频繁需要排序的字段** ：索引已经排序，这样查询可以利用索引的排序，加快排序查询时间。 +- **被经常频繁用于连接的字段** ：经常用于连接的字段可能是一些外键列，对于外键列并不一定要建立外键，只是说该列涉及到表与表的关系。对于频繁被连接查询的字段，可以考虑建立索引，提高多表连接查询的效率。 + +**2.被频繁更新的字段应该慎重建立索引。** + +虽然索引能带来查询上的效率，但是维护索引的成本也是不小的。 +如果一个字段不被经常查询，反而被经常修改，那么就更不应该在这种字段上建立索引了。 + +**3.尽可能的考虑建立联合索引而不是单列索引。** + +因为索引是需要占用磁盘空间的，可以简单理解为每个索引都对应着一颗 B+树。如果一个表的字段过多，索引过多，那么当这个表的数据达到一个体量后，索引占用的空间也是很多的，且修改索引时，耗费的时间也是较多的。如果是联合索引，多个字段在一个索引上，那么将会节约很大磁盘空间，且修改数据的操作效率也会提升。 + +**4.注意避免冗余索引** 。 + +冗余索引指的是索引的功能相同，能够命中索引(a, b)就肯定能命中索引(a) ，那么索引(a)就是冗余索引。如（name,city ）和（name ）这两个索引就是冗余索引，能够命中前者的查询肯定是能够命中后者的 在大多数情况下，都应该尽量扩展已有的索引而不是创建新索引。 + +**5.考虑在字符串类型的字段上使用前缀索引代替普通索引。** + +前缀索引仅限于字符串类型，较普通索引会占用更小的空间，所以可以考虑使用前缀索引带替普通索引。 + +## 使用索引的一些建议 + +- 对于中到大型表索引都是非常有效的，但是特大型表的话维护开销会很大，不适合建索引 +- 避免 where 子句中对字段施加函数，这会造成无法命中索引。 +- 在使用 InnoDB 时使用与业务无关的自增主键作为主键，即使用逻辑主键，而不要使用业务主键。 +- 删除长期未使用的索引，不用的索引的存在会造成不必要的性能损耗 MySQL 5.7 可以通过查询 sys 库的 schema_unused_indexes 视图来查询哪些索引从未被使用 +- 在使用 limit offset 查询缓慢时，可以借助索引来提高性能 + +## MySQL 如何为表字段添加索引？ + +1.添加 PRIMARY KEY（主键索引） + +```sql +ALTER TABLE `table_name` ADD PRIMARY KEY ( `column` ) +``` + +2.添加 UNIQUE(唯一索引) + +```sqlite +ALTER TABLE `table_name` ADD UNIQUE ( `column` ) +``` + +3.添加 INDEX(普通索引) + +```sql +ALTER TABLE `table_name` ADD INDEX index_name ( `column` ) +``` + +4.添加 FULLTEXT(全文索引) + +```sql +ALTER TABLE `table_name` ADD FULLTEXT ( `column`) +``` + +5.添加多列索引 + +```sql +ALTER TABLE `table_name` ADD INDEX index_name ( `column1`, `column2`, `column3` ) +``` diff --git a/docs/database/mysql/mysql-logs.md b/docs/database/mysql/mysql-logs.md new file mode 100644 index 0000000000000000000000000000000000000000..cb7990f709f3f1d7b13077c19dad253a75b17981 --- /dev/null +++ b/docs/database/mysql/mysql-logs.md @@ -0,0 +1,291 @@ +--- +title: MySQL三大日志(binlog、redo log和undo log)详解 +category: 数据库 +tag: + - MySQL +--- + + + +> 本文来自公号程序猿阿星投稿，JavaGuide 对其做了补充完善。 + +## 前言 + +`MySQL` 日志 主要包括错误日志、查询日志、慢查询日志、事务日志、二进制日志几大类。其中，比较重要的还要属二进制日志 `binlog`（归档日志）和事务日志 `redo log`（重做日志）和 `undo log`（回滚日志）。 + +![](https://cdn.jsdelivr.net/gh/18702524676/CND5/image/mysql/03/01.png) + +今天就来聊聊 `redo log`（重做日志）、`binlog`（归档日志）、两阶段提交、`undo log` （回滚日志）。 + +## redo log + +`redo log`（重做日志）是`InnoDB`存储引擎独有的，它让`MySQL`拥有了崩溃恢复能力。 + +比如 `MySQL` 实例挂了或宕机了，重启时，`InnoDB`存储引擎会使用`redo log`恢复数据，保证数据的持久性与完整性。 + +![](https://cdn.jsdelivr.net/gh/18702524676/CND5/image/mysql/03/02.png) + +`MySQL` 中数据是以页为单位，你查询一条记录，会从硬盘把一页的数据加载出来，加载出来的数据叫数据页，会放入到 `Buffer Pool` 中。 + +后续的查询都是先从 `Buffer Pool` 中找，没有命中再去硬盘加载，减少硬盘 `IO` 开销，提升性能。 + +更新表数据的时候，也是如此，发现 `Buffer Pool` 里存在要更新的数据，就直接在 `Buffer Pool` 里更新。 + +然后会把“在某个数据页上做了什么修改”记录到重做日志缓存（`redo log buffer`）里，接着刷盘到 `redo log` 文件里。 + +![](https://cdn.jsdelivr.net/gh/18702524676/CND5/image/mysql/03/03.png) + +> 图片笔误提示：第4步 “清空 redo log buffe 刷盘到 redo 日志中”这句话中的 buffe 应该是 buffer。 + +理想情况，事务一提交就会进行刷盘操作，但实际上，刷盘的时机是根据策略来进行的。 + +> 小贴士：每条 redo 记录由“表空间号+数据页号+偏移量+修改数据长度+具体修改的数据”组成 + +### 刷盘时机 + +`InnoDB` 存储引擎为 `redo log` 的刷盘策略提供了 `innodb_flush_log_at_trx_commit` 参数，它支持三种策略： + +- **0** ：设置为 0 的时候，表示每次事务提交时不进行刷盘操作 +- **1** ：设置为 1 的时候，表示每次事务提交时都将进行刷盘操作（默认值） +- **2** ：设置为 2 的时候，表示每次事务提交时都只把 redo log buffer 内容写入 page cache + +`innodb_flush_log_at_trx_commit` 参数默认为 1 ，也就是说当事务提交时会调用 `fsync` 对 redo log 进行刷盘 + +另外，`InnoDB` 存储引擎有一个后台线程，每隔`1` 秒，就会把 `redo log buffer` 中的内容写到文件系统缓存（`page cache`），然后调用 `fsync` 刷盘。 + +![](https://cdn.jsdelivr.net/gh/18702524676/CND5/image/mysql/03/04.png) + +也就是说，一个没有提交事务的 `redo log` 记录，也可能会刷盘。 + +**为什么呢？** + +因为在事务执行过程 `redo log` 记录是会写入`redo log buffer` 中，这些 `redo log` 记录会被后台线程刷盘。 + +![](https://cdn.jsdelivr.net/gh/18702524676/CND5/image/mysql/03/05.png) + +除了后台线程每秒`1`次的轮询操作，还有一种情况，当 `redo log buffer` 占用的空间即将达到 `innodb_log_buffer_size` 一半的时候，后台线程会主动刷盘。 + +下面是不同刷盘策略的流程图。 + +#### innodb_flush_log_at_trx_commit=0 + +![](https://cdn.jsdelivr.net/gh/18702524676/CND5/image/mysql/03/06.png) + +为`0`时，如果`MySQL`挂了或宕机可能会有`1`秒数据的丢失。 + +#### innodb_flush_log_at_trx_commit=1 + +![](https://cdn.jsdelivr.net/gh/18702524676/CND5/image/mysql/03/07.png) + +为`1`时， 只要事务提交成功，`redo log`记录就一定在硬盘里，不会有任何数据丢失。 + +如果事务执行期间`MySQL`挂了或宕机，这部分日志丢了，但是事务并没有提交，所以日志丢了也不会有损失。 + +#### innodb_flush_log_at_trx_commit=2 + +![](https://cdn.jsdelivr.net/gh/18702524676/CND5/image/mysql/03/09.png) + +为`2`时， 只要事务提交成功，`redo log buffer`中的内容只写入文件系统缓存（`page cache`）。 + +如果仅仅只是`MySQL`挂了不会有任何数据丢失，但是宕机可能会有`1`秒数据的丢失。 + +### 日志文件组 + +硬盘上存储的 `redo log` 日志文件不只一个，而是以一个**日志文件组**的形式出现的，每个的`redo`日志文件大小都是一样的。 + +比如可以配置为一组`4`个文件，每个文件的大小是 `1GB`，整个 `redo log` 日志文件组可以记录`4G`的内容。 + +它采用的是环形数组形式，从头开始写，写到末尾又回到头循环写，如下图所示。 + +![](https://cdn.jsdelivr.net/gh/18702524676/CND5/image/mysql/03/10.png) + +在个**日志文件组**中还有两个重要的属性，分别是 `write pos、checkpoint` + +- **write pos** 是当前记录的位置，一边写一边后移 +- **checkpoint** 是当前要擦除的位置，也是往后推移 + +每次刷盘 `redo log` 记录到**日志文件组**中，`write pos` 位置就会后移更新。 + +每次 `MySQL` 加载**日志文件组**恢复数据时，会清空加载过的 `redo log` 记录，并把 `checkpoint` 后移更新。 + +`write pos` 和 `checkpoint` 之间的还空着的部分可以用来写入新的 `redo log` 记录。 + +![](https://cdn.jsdelivr.net/gh/18702524676/CND5/image/mysql/03/11.png) + +如果 `write pos` 追上 `checkpoint` ，表示**日志文件组**满了，这时候不能再写入新的 `redo log` 记录，`MySQL` 得停下来，清空一些记录，把 `checkpoint` 推进一下。 + +![](https://cdn.jsdelivr.net/gh/18702524676/CND5/image/mysql/03/12.png) + +### redo log 小结 + +相信大家都知道 `redo log` 的作用和它的刷盘时机、存储形式。 + +现在我们来思考一个问题： **只要每次把修改后的数据页直接刷盘不就好了，还有 `redo log` 什么事？** + +它们不都是刷盘么？差别在哪里？ + +```java +1 Byte = 8bit +1 KB = 1024 Byte +1 MB = 1024 KB +1 GB = 1024 MB +1 TB = 1024 GB +``` + +实际上，数据页大小是`16KB`，刷盘比较耗时，可能就修改了数据页里的几 `Byte` 数据，有必要把完整的数据页刷盘吗？ + +而且数据页刷盘是随机写，因为一个数据页对应的位置可能在硬盘文件的随机位置，所以性能是很差。 + +如果是写 `redo log`，一行记录可能就占几十 `Byte`，只包含表空间号、数据页号、磁盘文件偏移 +量、更新值，再加上是顺序写，所以刷盘速度很快。 + +所以用 `redo log` 形式记录修改内容，性能会远远超过刷数据页的方式，这也让数据库的并发能力更强。 + +> 其实内存的数据页在一定时机也会刷盘，我们把这称为页合并，讲 `Buffer Pool`的时候会对这块细说 + +## binlog + +`redo log` 它是物理日志，记录内容是“在某个数据页上做了什么修改”，属于 `InnoDB` 存储引擎。 + +而 `binlog` 是逻辑日志，记录内容是语句的原始逻辑，类似于“给 ID=2 这一行的 c 字段加 1”，属于`MySQL Server` 层。 + +不管用什么存储引擎，只要发生了表数据更新，都会产生 `binlog` 日志。 + +那 `binlog` 到底是用来干嘛的？ + +可以说`MySQL`数据库的**数据备份、主备、主主、主从**都离不开`binlog`，需要依靠`binlog`来同步数据，保证数据一致性。 + +![](https://cdn.jsdelivr.net/gh/18702524676/CND5/image/mysql/04/01.png) + +`binlog`会记录所有涉及更新数据的逻辑操作，并且是顺序写。 + +### 记录格式 + +`binlog` 日志有三种格式，可以通过`binlog_format`参数指定。 + +- **statement** +- **row** +- **mixed** + +指定`statement`，记录的内容是`SQL`语句原文，比如执行一条`update T set update_time=now() where id=1`，记录的内容如下。 + +![](https://cdn.jsdelivr.net/gh/18702524676/CND5/image/mysql/04/02.png) + +同步数据时，会执行记录的`SQL`语句，但是有个问题，`update_time=now()`这里会获取当前系统时间，直接执行会导致与原库的数据不一致。 + +为了解决这种问题，我们需要指定为`row`，记录的内容不再是简单的`SQL`语句了，还包含操作的具体数据，记录内容如下。 + +![](https://cdn.jsdelivr.net/gh/18702524676/CND5/image/mysql/04/03.png) + +`row`格式记录的内容看不到详细信息，要通过`mysqlbinlog`工具解析出来。 + +`update_time=now()`变成了具体的时间`update_time=1627112756247`，条件后面的@1、@2、@3 都是该行数据第 1 个~3 个字段的原始值（**假设这张表只有 3 个字段**）。 + +这样就能保证同步数据的一致性，通常情况下都是指定为`row`，这样可以为数据库的恢复与同步带来更好的可靠性。 + +但是这种格式，需要更大的容量来记录，比较占用空间，恢复与同步时会更消耗`IO`资源，影响执行速度。 + +所以就有了一种折中的方案，指定为`mixed`，记录的内容是前两者的混合。 + +`MySQL`会判断这条`SQL`语句是否可能引起数据不一致，如果是，就用`row`格式，否则就用`statement`格式。 + +### 写入机制 + +`binlog`的写入时机也非常简单，事务执行过程中，先把日志写到`binlog cache`，事务提交的时候，再把`binlog cache`写到`binlog`文件中。 + +因为一个事务的`binlog`不能被拆开，无论这个事务多大，也要确保一次性写入，所以系统会给每个线程分配一个块内存作为`binlog cache`。 + +我们可以通过`binlog_cache_size`参数控制单个线程 binlog cache 大小，如果存储内容超过了这个参数，就要暂存到磁盘（`Swap`）。 + +`binlog`日志刷盘流程如下 + +![](https://cdn.jsdelivr.net/gh/18702524676/CND5/image/mysql/04/04.png) + +- **上图的 write，是指把日志写入到文件系统的 page cache，并没有把数据持久化到磁盘，所以速度比较快** +- **上图的 fsync，才是将数据持久化到磁盘的操作** + +`write`和`fsync`的时机，可以由参数`sync_binlog`控制，默认是`0`。 + +为`0`的时候，表示每次提交事务都只`write`，由系统自行判断什么时候执行`fsync`。 + +![](https://cdn.jsdelivr.net/gh/18702524676/CND5/image/mysql/04/05.png) + +虽然性能得到提升，但是机器宕机，`page cache`里面的 binlog 会丢失。 + +为了安全起见，可以设置为`1`，表示每次提交事务都会执行`fsync`，就如同**binlog 日志刷盘流程**一样。 + +最后还有一种折中方式，可以设置为`N(N>1)`，表示每次提交事务都`write`，但累积`N`个事务后才`fsync`。 + +![](https://cdn.jsdelivr.net/gh/18702524676/CND5/image/mysql/04/06.png) + +在出现`IO`瓶颈的场景里，将`sync_binlog`设置成一个比较大的值，可以提升性能。 + +同样的，如果机器宕机，会丢失最近`N`个事务的`binlog`日志。 + +## 两阶段提交 + +`redo log`（重做日志）让`InnoDB`存储引擎拥有了崩溃恢复能力。 + +`binlog`（归档日志）保证了`MySQL`集群架构的数据一致性。 + +虽然它们都属于持久化的保证，但是侧重点不同。 + +在执行更新语句过程，会记录`redo log`与`binlog`两块日志，以基本的事务为单位，`redo log`在事务执行过程中可以不断写入，而`binlog`只有在提交事务时才写入，所以`redo log`与`binlog`的写入时机不一样。 + +![](https://cdn.jsdelivr.net/gh/18702524676/CND5/image/mysql/05/01.png) + +回到正题，`redo log`与`binlog`两份日志之间的逻辑不一致，会出现什么问题？ + +我们以`update`语句为例，假设`id=2`的记录，字段`c`值是`0`，把字段`c`值更新成`1`，`SQL`语句为`update T set c=1 where id=2`。 + +假设执行过程中写完`redo log`日志后，`binlog`日志写期间发生了异常，会出现什么情况呢？ + +![](https://cdn.jsdelivr.net/gh/18702524676/CND5/image/mysql/05/02.png) + +由于`binlog`没写完就异常，这时候`binlog`里面没有对应的修改记录。因此，之后用`binlog`日志恢复数据时，就会少这一次更新，恢复出来的这一行`c`值是`0`，而原库因为`redo log`日志恢复，这一行`c`值是`1`，最终数据不一致。 + +![](https://cdn.jsdelivr.net/gh/18702524676/CND5/image/mysql/05/03.png) + +为了解决两份日志之间的逻辑一致问题，`InnoDB`存储引擎使用**两阶段提交**方案。 + +原理很简单，将`redo log`的写入拆成了两个步骤`prepare`和`commit`，这就是**两阶段提交**。 + +![](https://cdn.jsdelivr.net/gh/18702524676/CND5/image/mysql/05/04.png) + +使用**两阶段提交**后，写入`binlog`时发生异常也不会有影响，因为`MySQL`根据`redo log`日志恢复数据时，发现`redo log`还处于`prepare`阶段，并且没有对应`binlog`日志，就会回滚该事务。 + +![](https://cdn.jsdelivr.net/gh/18702524676/CND5/image/mysql/05/05.png) + +再看一个场景，`redo log`设置`commit`阶段发生异常，那会不会回滚事务呢？ + +![](https://cdn.jsdelivr.net/gh/18702524676/CND5/image/mysql/05/06.png) + +并不会回滚事务，它会执行上图框住的逻辑，虽然`redo log`是处于`prepare`阶段，但是能通过事务`id`找到对应的`binlog`日志，所以`MySQL`认为是完整的，就会提交事务恢复数据。 + +## undo log + +> 这部分内容为 JavaGuide 的补充： + +我们知道如果想要保证事务的原子性，就需要在异常发生时，对已经执行的操作进行**回滚**，在 MySQL 中，恢复机制是通过 **回滚日志（undo log）** 实现的，所有事务进行的修改都会先记录到这个回滚日志中，然后再执行相关的操作。如果执行过程中遇到异常的话，我们直接利用 **回滚日志** 中的信息将数据回滚到修改之前的样子即可！并且，回滚日志会先于数据持久化到磁盘上。这样就保证了即使遇到数据库突然宕机等情况，当用户再次启动数据库的时候，数据库还能够通过查询回滚日志来回滚将之前未完成的事务。 + +另外，`MVCC` 的实现依赖于：**隐藏字段、Read View、undo log**。在内部实现中，`InnoDB` 通过数据行的 `DB_TRX_ID` 和 `Read View` 来判断数据的可见性，如不可见，则通过数据行的 `DB_ROLL_PTR` 找到 `undo log` 中的历史版本。每个事务读到的数据版本可能是不一样的，在同一个事务中，用户只能看到该事务创建 `Read View` 之前已经提交的修改和该事务本身做的修改 + +## 总结 + +> 这部分内容为 JavaGuide 的补充： + +MySQL InnoDB 引擎使用 **redo log(重做日志)** 保证事务的**持久性**，使用 **undo log(回滚日志)** 来保证事务的**原子性**。 + +`MySQL`数据库的**数据备份、主备、主主、主从**都离不开`binlog`，需要依靠`binlog`来同步数据，保证数据一致性。 + +## 站在巨人的肩膀上 + +- 《MySQL 实战 45 讲》 +- 《从零开始带你成为 MySQL 实战优化高手》 +- 《MySQL 是怎样运行的：从根儿上理解 MySQL》 +- 《MySQL 技术 Innodb 存储引擎》 + +## MySQL 好文推荐 + +- [CURD 这么多年，你有了解过 MySQL 的架构设计吗？](https://mp.weixin.qq.com/s/R-1km7r0z3oWfwYQV8iiqA) +- [浅谈 MySQL InnoDB 的内存组件](https://mp.weixin.qq.com/s/7Kab4IQsNcU_bZdbv_MuOg) diff --git a/docs/database/mysql/mysql-questions-01.md b/docs/database/mysql/mysql-questions-01.md new file mode 100644 index 0000000000000000000000000000000000000000..2a300b182240ee5add817c0680b80aa50ac48f74 --- /dev/null +++ b/docs/database/mysql/mysql-questions-01.md @@ -0,0 +1,292 @@ +--- +title: MySQL知识点&面试题总结 +category: 数据库 +tag: + - MySQL + - 大厂面试 +--- + + +## MySQL 基础 + +### 关系型数据库介绍 + +顾名思义，关系型数据库就是一种建立在关系模型的基础上的数据库。关系模型表明了数据库中所存储的数据之间的联系（一对一、一对多、多对多）。 + +关系型数据库中，我们的数据都被存放在了各种表中（比如用户表），表中的每一行就存放着一条数据（比如一个用户的信息）。 + +![](https://guide-blog-images.oss-cn-shenzhen.aliyuncs.com/java-guide-blog/5e3c1a71724a38245aa43b02_99bf70d46cc247be878de9d3a88f0c44.png) + +大部分关系型数据库都使用 SQL 来操作数据库中的数据。并且，大部分关系型数据库都支持事务的四大特性(ACID)。 + +**有哪些常见的关系型数据库呢？** + +MySQL、PostgreSQL、Oracle、SQL Server、SQLite（微信本地的聊天记录的存储就是用的 SQLite） ......。 + +### MySQL 介绍 + +![](https://img-blog.csdnimg.cn/20210327143351823.png) + +**MySQL 是一种关系型数据库，主要用于持久化存储我们的系统中的一些数据比如用户信息。** + +由于 MySQL 是开源免费并且比较成熟的数据库，因此，MySQL 被大量使用在各种系统中。任何人都可以在 GPL(General Public License) 的许可下下载并根据个性化的需要对其进行修改。MySQL 的默认端口号是**3306**。 + +## 存储引擎 + +### 存储引擎相关的命令 + +**查看 MySQL 提供的所有存储引擎** + +```sql +mysql> show engines; +``` + +![查看MySQL提供的所有存储引擎](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/2019-6/mysql-engines.png) + +从上图我们可以查看出 MySQL 当前默认的存储引擎是 InnoDB，并且在 5.7 版本所有的存储引擎中只有 InnoDB 是事务性存储引擎，也就是说只有 InnoDB 支持事务。 + +**查看 MySQL 当前默认的存储引擎** + +我们也可以通过下面的命令查看默认的存储引擎。 + +```sql +mysql> show variables like '%storage_engine%'; +``` + +**查看表的存储引擎** + +```sql +show table status like "table_name" ; +``` + +![查看表的存储引擎](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/2019-6/查看表的存储引擎.png) + +### MyISAM 和 InnoDB 的区别 + +![](https://img-blog.csdnimg.cn/20210327145248960.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM0MzM3Mjcy,size_16,color_FFFFFF,t_70) + +MySQL 5.5 之前，MyISAM 引擎是 MySQL 的默认存储引擎，可谓是风光一时。 + +虽然，MyISAM 的性能还行，各种特性也还不错（比如全文索引、压缩、空间函数等）。但是，MyISAM 不支持事务和行级锁，而且最大的缺陷就是崩溃后无法安全恢复。 + +5.5 版本之后，MySQL 引入了 InnoDB（事务性数据库引擎），MySQL 5.5 版本后默认的存储引擎为 InnoDB。小伙子，一定要记好这个 InnoDB ，你每次使用 MySQL 数据库都是用的这个存储引擎吧？ + +言归正传！咱们下面还是来简单对比一下两者： + +**1.是否支持行级锁** + +MyISAM 只有表级锁(table-level locking)，而 InnoDB 支持行级锁(row-level locking)和表级锁,默认为行级锁。 + +也就说，MyISAM 一锁就是锁住了整张表，这在并发写的情况下是多么滴憨憨啊！这也是为什么 InnoDB 在并发写的时候，性能更牛皮了！ + +**2.是否支持事务** + +MyISAM 不提供事务支持。 + +InnoDB 提供事务支持，具有提交(commit)和回滚(rollback)事务的能力。 + +**3.是否支持外键** + +MyISAM 不支持，而 InnoDB 支持。 + +🌈 拓展一下： + +一般我们也是不建议在数据库层面使用外键的，应用层面可以解决。不过，这样会对数据的一致性造成威胁。具体要不要使用外键还是要根据你的项目来决定。 + +**4.是否支持数据库异常崩溃后的安全恢复** + +MyISAM 不支持，而 InnoDB 支持。 + +使用 InnoDB 的数据库在异常崩溃后，数据库重新启动的时候会保证数据库恢复到崩溃前的状态。这个恢复的过程依赖于 `redo log` 。 + +🌈 拓展一下： + +- MySQL InnoDB 引擎使用 **redo log(重做日志)** 保证事务的**持久性**，使用 **undo log(回滚日志)** 来保证事务的**原子性**。 +- MySQL InnoDB 引擎通过 **锁机制**、**MVCC** 等手段来保证事务的隔离性（ 默认支持的隔离级别是 **`REPEATABLE-READ`** ）。 +- 保证了事务的持久性、原子性、隔离性之后，一致性才能得到保障。 + +**5.是否支持 MVCC** + +MyISAM 不支持，而 InnoDB 支持。 + +讲真，这个对比有点废话，毕竟 MyISAM 连行级锁都不支持。 + +MVCC 可以看作是行级锁的一个升级，可以有效减少加锁操作，提供性能。 + +### 关于 MyISAM 和 InnoDB 的选择问题 + +大多数时候我们使用的都是 InnoDB 存储引擎，在某些读密集的情况下，使用 MyISAM 也是合适的。不过，前提是你的项目不介意 MyISAM 不支持事务、崩溃恢复等缺点（可是~我们一般都会介意啊！）。 + +《MySQL 高性能》上面有一句话这样写到: + +> 不要轻易相信“MyISAM 比 InnoDB 快”之类的经验之谈，这个结论往往不是绝对的。在很多我们已知场景中，InnoDB 的速度都可以让 MyISAM 望尘莫及，尤其是用到了聚簇索引，或者需要访问的数据都可以放入内存的应用。 + +一般情况下我们选择 InnoDB 都是没有问题的，但是某些情况下你并不在乎可扩展能力和并发能力，也不需要事务支持，也不在乎崩溃后的安全恢复问题的话，选择 MyISAM 也是一个不错的选择。但是一般情况下，我们都是需要考虑到这些问题的。 + +因此，对于咱们日常开发的业务系统来说，你几乎找不到什么理由再使用 MyISAM 作为自己的 MySQL 数据库的存储引擎。 + +## 锁机制与 InnoDB 锁算法 + +**MyISAM 和 InnoDB 存储引擎使用的锁：** + +- MyISAM 采用表级锁(table-level locking)。 +- InnoDB 支持行级锁(row-level locking)和表级锁,默认为行级锁 + +**表级锁和行级锁对比：** + +- **表级锁：** MySQL 中锁定 **粒度最大** 的一种锁，对当前操作的整张表加锁，实现简单，资源消耗也比较少，加锁快，不会出现死锁。其锁定粒度最大，触发锁冲突的概率最高，并发度最低，MyISAM 和 InnoDB 引擎都支持表级锁。 +- **行级锁：** MySQL 中锁定 **粒度最小** 的一种锁，只针对当前操作的行进行加锁。 行级锁能大大减少数据库操作的冲突。其加锁粒度最小，并发度高，但加锁的开销也最大，加锁慢，会出现死锁。 + +**InnoDB 存储引擎的锁的算法有三种：** + +- Record lock：记录锁，单个行记录上的锁 +- Gap lock：间隙锁，锁定一个范围，不包括记录本身 +- Next-key lock：record+gap 临键锁，锁定一个范围，包含记录本身 + +## 查询缓存 + +执行查询语句的时候，会先查询缓存。不过，MySQL 8.0 版本后移除，因为这个功能不太实用 + +`my.cnf` 加入以下配置，重启 MySQL 开启查询缓存 + +```properties +query_cache_type=1 +query_cache_size=600000 +``` + +MySQL 执行以下命令也可以开启查询缓存 + +```properties +set global query_cache_type=1; +set global query_cache_size=600000; +``` + +如上，**开启查询缓存后在同样的查询条件以及数据情况下，会直接在缓存中返回结果**。这里的查询条件包括查询本身、当前要查询的数据库、客户端协议版本号等一些可能影响结果的信息。（**查询缓存不命中的情况：（1）**）因此任何两个查询在任何字符上的不同都会导致缓存不命中。此外，（**查询缓存不命中的情况：（2）**）如果查询中包含任何用户自定义函数、存储函数、用户变量、临时表、MySQL 库中的系统表，其查询结果也不会被缓存。 + +（**查询缓存不命中的情况：（3）**）**缓存建立之后**，MySQL 的查询缓存系统会跟踪查询中涉及的每张表，如果这些表（数据或结构）发生变化，那么和这张表相关的所有缓存数据都将失效。 + +**缓存虽然能够提升数据库的查询性能，但是缓存同时也带来了额外的开销，每次查询后都要做一次缓存操作，失效后还要销毁。** 因此，开启查询缓存要谨慎，尤其对于写密集的应用来说更是如此。如果开启，要注意合理控制缓存空间大小，一般来说其大小设置为几十 MB 比较合适。此外，**还可以通过 sql_cache 和 sql_no_cache 来控制某个查询语句是否需要缓存：** + +```sql +select sql_no_cache count(*) from usr; +``` + +## 事务 + +### 何为事务？ + +一言蔽之，**事务是逻辑上的一组操作，要么都执行，要么都不执行。** + +**可以简单举一个例子不？** + +事务最经典也经常被拿出来说例子就是转账了。假如小明要给小红转账 1000 元，这个转账会涉及到两个关键操作就是： + +1. 将小明的余额减少 1000 元 +2. 将小红的余额增加 1000 元。 + +事务会把这两个操作就可以看成逻辑上的一个整体，这个整体包含的操作要么都成功，要么都要失败。 + +这样就不会出现小明余额减少而小红的余额却并没有增加的情况。 + +### 何为数据库事务？ + +数据库事务在我们日常开发中接触的最多了。如果你的项目属于单体架构的话，你接触到的往往就是数据库事务了。 + +平时，我们在谈论事务的时候，如果没有特指**分布式事务**，往往指的就是**数据库事务**。 + +**那数据库事务有什么作用呢？** + +简单来说：数据库事务可以保证多个对数据库的操作（也就是 SQL 语句）构成一个逻辑上的整体。构成这个逻辑上的整体的这些数据库操作遵循：**要么全部执行成功,要么全部不执行** 。 + +```sql +# 开启一个事务 +START TRANSACTION; +# 多条 SQL 语句 +SQL1,SQL2... +## 提交事务 +COMMIT; +``` + +![](https://guide-blog-images.oss-cn-shenzhen.aliyuncs.com/2020-12/640-20201207160554677.png) + +另外，关系型数据库（例如：`MySQL`、`SQL Server`、`Oracle` 等）事务都有 **ACID** 特性： + +![事务的特性](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/2019-6/%E4%BA%8B%E5%8A%A1%E7%89%B9%E6%80%A7.png) + +### 何为 ACID 特性呢？ + +1. **原子性**（`Atomicity`） ： 事务是最小的执行单位，不允许分割。事务的原子性确保动作要么全部完成，要么完全不起作用； +2. **一致性**（`Consistency`）： 执行事务前后，数据保持一致，例如转账业务中，无论事务是否成功，转账者和收款人的总额应该是不变的； +3. **隔离性**（`Isolation`）： 并发访问数据库时，一个用户的事务不被其他事务所干扰，各并发事务之间数据库是独立的； +4. **持久性**（`Durability`）： 一个事务被提交之后。它对数据库中数据的改变是持久的，即使数据库发生故障也不应该对其有任何影响。 + +**数据事务的实现原理呢？** + +我们这里以 MySQL 的 InnoDB 引擎为例来简单说一下。 + +MySQL InnoDB 引擎使用 **redo log(重做日志)** 保证事务的**持久性**，使用 **undo log(回滚日志)** 来保证事务的**原子性**。 + +MySQL InnoDB 引擎通过 **锁机制**、**MVCC** 等手段来保证事务的隔离性（ 默认支持的隔离级别是 **`REPEATABLE-READ`** ）。 + +保证了事务的持久性、原子性、隔离性之后，一致性才能得到保障。 + +### 并发事务带来哪些问题? + +在典型的应用程序中，多个事务并发运行，经常会操作相同的数据来完成各自的任务（多个用户对同一数据进行操作）。并发虽然是必须的，但可能会导致以下的问题。 + +- **脏读（Dirty read）:** 当一个事务正在访问数据并且对数据进行了修改，而这种修改还没有提交到数据库中，这时另外一个事务也访问了这个数据，然后使用了这个数据。因为这个数据是还没有提交的数据，那么另外一个事务读到的这个数据是“脏数据”，依据“脏数据”所做的操作可能是不正确的。 +- **丢失修改（Lost to modify）:** 指在一个事务读取一个数据时，另外一个事务也访问了该数据，那么在第一个事务中修改了这个数据后，第二个事务也修改了这个数据。这样第一个事务内的修改结果就被丢失，因此称为丢失修改。 例如：事务 1 读取某表中的数据 A=20，事务 2 也读取 A=20，事务 1 修改 A=A-1，事务 2 也修改 A=A-1，最终结果 A=19，事务 1 的修改被丢失。 +- **不可重复读（Unrepeatable read）:** 指在一个事务内多次读同一数据。在这个事务还没有结束时，另一个事务也访问该数据。那么，在第一个事务中的两次读数据之间，由于第二个事务的修改导致第一个事务两次读取的数据可能不太一样。这就发生了在一个事务内两次读到的数据是不一样的情况，因此称为不可重复读。 +- **幻读（Phantom read）:** 幻读与不可重复读类似。它发生在一个事务（T1）读取了几行数据，接着另一个并发事务（T2）插入了一些数据时。在随后的查询中，第一个事务（T1）就会发现多了一些原本不存在的记录，就好像发生了幻觉一样，所以称为幻读。 + +**不可重复读和幻读区别：** + +不可重复读的重点是修改比如多次读取一条记录发现其中某些列的值被修改，幻读的重点在于新增或者删除比如多次查询同一条查询语句（DQL）时，记录发现记录增多或减少了。 + +### 事务隔离级别有哪些? + +SQL 标准定义了四个隔离级别： + +- **READ-UNCOMMITTED(读取未提交)：** 最低的隔离级别，允许读取尚未提交的数据变更，**可能会导致脏读、幻读或不可重复读**。 +- **READ-COMMITTED(读取已提交)：** 允许读取并发事务已经提交的数据，**可以阻止脏读，但是幻读或不可重复读仍有可能发生**。 +- **REPEATABLE-READ(可重复读)：** 对同一字段的多次读取结果都是一致的，除非数据是被本身事务自己所修改，**可以阻止脏读和不可重复读，但幻读仍有可能发生**。 +- **SERIALIZABLE(可串行化)：** 最高的隔离级别，完全服从 ACID 的隔离级别。所有的事务依次逐个执行，这样事务之间就完全不可能产生干扰，也就是说，**该级别可以防止脏读、不可重复读以及幻读**。 + +--- + +| 隔离级别 | 脏读 | 不可重复读 | 幻读 | +| :--------------: | :--: | :--------: | :--: | +| READ-UNCOMMITTED | √ | √ | √ | +| READ-COMMITTED | × | √ | √ | +| REPEATABLE-READ | × | × | √ | +| SERIALIZABLE | × | × | × | + +### MySQL 的默认隔离级别是什么? + +MySQL InnoDB 存储引擎的默认支持的隔离级别是 **REPEATABLE-READ（可重读）**。我们可以通过`SELECT @@tx_isolation;`命令来查看，MySQL 8.0 该命令改为`SELECT @@transaction_isolation;` + +```sql +mysql> SELECT @@tx_isolation; ++-----------------+ +| @@tx_isolation | ++-----------------+ +| REPEATABLE-READ | ++-----------------+ +``` + +~~这里需要注意的是：与 SQL 标准不同的地方在于 InnoDB 存储引擎在 **REPEATABLE-READ（可重读）** 事务隔离级别下使用的是 Next-Key Lock 锁算法，因此可以避免幻读的产生，这与其他数据库系统(如 SQL Server)是不同的。所以说 InnoDB 存储引擎的默认支持的隔离级别是 **REPEATABLE-READ（可重读）** 已经可以完全保证事务的隔离性要求，即达到了 SQL 标准的 **SERIALIZABLE(可串行化)** 隔离级别。~~ + +🐛 问题更正：**MySQL InnoDB 的 REPEATABLE-READ（可重读）并不保证避免幻读，需要应用使用加锁读来保证。而这个加锁读使用到的机制就是 Next-Key Locks。** + +因为隔离级别越低，事务请求的锁越少，所以大部分数据库系统的隔离级别都是 **READ-COMMITTED(读取提交内容)** ，但是你要知道的是 InnoDB 存储引擎默认使用 **REPEATABLE-READ（可重读）** 并不会有任何性能损失。 + +InnoDB 存储引擎在 **分布式事务** 的情况下一般会用到 **SERIALIZABLE(可串行化)** 隔离级别。 + +🌈 拓展一下(以下内容摘自《MySQL 技术内幕：InnoDB 存储引擎(第 2 版)》7.7 章)： + +> InnoDB 存储引擎提供了对 XA 事务的支持，并通过 XA 事务来支持分布式事务的实现。分布式事务指的是允许多个独立的事务资源（transactional resources）参与到一个全局的事务中。事务资源通常是关系型数据库系统，但也可以是其他类型的资源。全局事务要求在其中的所有参与的事务要么都提交，要么都回滚，这对于事务原有的 ACID 要求又有了提高。另外，在使用分布式事务时，InnoDB 存储引擎的事务隔离级别必须设置为 SERIALIZABLE。 + +## 参考 + +- 《高性能 MySQL》 +- https://www.omnisci.com/technical-glossary/relational-database diff --git a/docs/database/mysql/some-thoughts-on-database-storage-time.md b/docs/database/mysql/some-thoughts-on-database-storage-time.md new file mode 100644 index 0000000000000000000000000000000000000000..ccad646e5d4067308ab99dfec535c595f7da1710 --- /dev/null +++ b/docs/database/mysql/some-thoughts-on-database-storage-time.md @@ -0,0 +1,162 @@ +--- +title: 关于数据库中如何存储时间的一点思考 +category: 数据库 +tag: + - MySQL +--- + + + +我们平时开发中不可避免的就是要存储时间，比如我们要记录操作表中这条记录的时间、记录转账的交易时间、记录出发时间等等。你会发现时间这个东西与我们开发的联系还是非常紧密的，用的好与不好会给我们的业务甚至功能带来很大的影响。所以，我们有必要重新出发，好好认识一下这个东西。 + +这是一篇短小精悍的文章，仔细阅读一定能学到不少东西！ + +### 1.切记不要用字符串存储日期 + +我记得我在大学的时候就这样干过，而且现在很多对数据库不太了解的新手也会这样干，可见，这种存储日期的方式的优点还是有的，就是简单直白，容易上手。 + +但是，这是不正确的做法，主要会有下面两个问题： + +1. 字符串占用的空间更大！ +2. 字符串存储的日期效率比较低（逐个字符进行比对），无法用日期相关的 API 进行计算和比较。 + +### 2.Datetime 和 Timestamp 之间抉择 + +Datetime 和 Timestamp 是 MySQL 提供的两种比较相似的保存时间的数据类型。他们两者究竟该如何选择呢？ + +**通常我们都会首选 Timestamp。** 下面说一下为什么这样做! + +#### 2.1 DateTime 类型没有时区信息 + +**DateTime 类型是没有时区信息的（时区无关）** ，DateTime 类型保存的时间都是当前会话所设置的时区对应的时间。这样就会有什么问题呢？当你的时区更换之后，比如你的服务器更换地址或者更换客户端连接时区设置的话，就会导致你从数据库中读出的时间错误。不要小看这个问题，很多系统就是因为这个问题闹出了很多笑话。 + +**Timestamp 和时区有关**。Timestamp 类型字段的值会随着服务器时区的变化而变化，自动换算成相应的时间，说简单点就是在不同时区，查询到同一个条记录此字段的值会不一样。 + +下面实际演示一下！ + +建表 SQL 语句： + +```sql +CREATE TABLE `time_zone_test` ( + `id` bigint(20) NOT NULL AUTO_INCREMENT, + `date_time` datetime DEFAULT NULL, + `time_stamp` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, + PRIMARY KEY (`id`) +) ENGINE=InnoDB DEFAULT CHARSET=utf8; +``` + +插入数据： + +```sql +INSERT INTO time_zone_test(date_time,time_stamp) VALUES(NOW(),NOW()); +``` + +查看数据： + +```sql +select date_time,time_stamp from time_zone_test; +``` + +结果： + +``` ++---------------------+---------------------+ +| date_time | time_stamp | ++---------------------+---------------------+ +| 2020-01-11 09:53:32 | 2020-01-11 09:53:32 | ++---------------------+---------------------+ +``` + +现在我们运行 + +修改当前会话的时区: + +```sql +set time_zone='+8:00'; +``` + +再次查看数据： + +``` ++---------------------+---------------------+ +| date_time | time_stamp | ++---------------------+---------------------+ +| 2020-01-11 09:53:32 | 2020-01-11 17:53:32 | ++---------------------+---------------------+ +``` + +**扩展：一些关于 MySQL 时区设置的一个常用 sql 命令** + +```sql +# 查看当前会话时区 +SELECT @@session.time_zone; +# 设置当前会话时区 +SET time_zone = 'Europe/Helsinki'; +SET time_zone = "+00:00"; +# 数据库全局时区设置 +SELECT @@global.time_zone; +# 设置全局时区 +SET GLOBAL time_zone = '+8:00'; +SET GLOBAL time_zone = 'Europe/Helsinki'; +``` + +#### 2.2 DateTime 类型耗费空间更大 + +Timestamp 只需要使用 4 个字节的存储空间，但是 DateTime 需要耗费 8 个字节的存储空间。但是，这样同样造成了一个问题，Timestamp 表示的时间范围更小。 + +- DateTime ：1000-01-01 00:00:00 ~ 9999-12-31 23:59:59 +- Timestamp： 1970-01-01 00:00:01 ~ 2037-12-31 23:59:59 + +> Timestamp 在不同版本的 MySQL 中有细微差别。 + +### 3 再看 MySQL 日期类型存储空间 + +下图是 MySQL 5.6 版本中日期类型所占的存储空间： + +![](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/2019-11/FhRGUVHFK0ujRPNA75f6CuOXQHTE.jpeg) + +可以看出 5.6.4 之后的 MySQL 多出了一个需要 0 ～ 3 字节的小数位。DateTime 和 Timestamp 会有几种不同的存储空间占用。 + +为了方便，本文我们还是默认 Timestamp 只需要使用 4 个字节的存储空间，但是 DateTime 需要耗费 8 个字节的存储空间。 + +### 4.数值型时间戳是更好的选择吗？ + +很多时候，我们也会使用 int 或者 bigint 类型的数值也就是时间戳来表示时间。 + +这种存储方式的具有 Timestamp 类型的所具有一些优点，并且使用它的进行日期排序以及对比等操作的效率会更高，跨系统也很方便，毕竟只是存放的数值。缺点也很明显，就是数据的可读性太差了，你无法直观的看到具体时间。 + +时间戳的定义如下： + +> 时间戳的定义是从一个基准时间开始算起，这个基准时间是「1970-1-1 00:00:00 +0:00」，从这个时间开始，用整数表示，以秒计时，随着时间的流逝这个时间整数不断增加。这样一来，我只需要一个数值，就可以完美地表示时间了，而且这个数值是一个绝对数值，即无论的身处地球的任何角落，这个表示时间的时间戳，都是一样的，生成的数值都是一样的，并且没有时区的概念，所以在系统的中时间的传输中，都不需要进行额外的转换了，只有在显示给用户的时候，才转换为字符串格式的本地时间。 + +数据库中实际操作： + +```sql +mysql> select UNIX_TIMESTAMP('2020-01-11 09:53:32'); ++---------------------------------------+ +| UNIX_TIMESTAMP('2020-01-11 09:53:32') | ++---------------------------------------+ +| 1578707612 | ++---------------------------------------+ +1 row in set (0.00 sec) + +mysql> select FROM_UNIXTIME(1578707612); ++---------------------------+ +| FROM_UNIXTIME(1578707612) | ++---------------------------+ +| 2020-01-11 09:53:32 | ++---------------------------+ +1 row in set (0.01 sec) +``` + +### 5.总结 + +MySQL 中时间到底怎么存储才好？Datetime?Timestamp? 数值保存的时间戳？ + +好像并没有一个银弹，很多程序员会觉得数值型时间戳是真的好，效率又高还各种兼容，但是很多人又觉得它表现的不够直观。这里插一嘴，《高性能 MySQL 》这本神书的作者就是推荐 Timestamp，原因是数值表示时间不够直观。下面是原文： + + + +每种方式都有各自的优势，根据实际场景才是王道。下面再对这三种方式做一个简单的对比，以供大家实际开发中选择正确的存放时间的数据类型： + + \ No newline at end of file diff --git a/docs/database/mysql/transaction-isolation-level.md b/docs/database/mysql/transaction-isolation-level.md new file mode 100644 index 0000000000000000000000000000000000000000..2d2930beac3268151df64a3d480cb6cc4029e24c --- /dev/null +++ b/docs/database/mysql/transaction-isolation-level.md @@ -0,0 +1,146 @@ +--- +title: 事务隔离级别(图文详解) +category: 数据库 +tag: + - MySQL +--- + + +> 本文由 [SnailClimb](https://github.com/Snailclimb) 和 [guang19](https://github.com/guang19) 共同完成。 + +## 事务隔离级别(图文详解) + +### 什么是事务? + +事务是逻辑上的一组操作，要么都执行，要么都不执行。 + +事务最经典也经常被拿出来说例子就是转账了。假如小明要给小红转账1000元，这个转账会涉及到两个关键操作就是：将小明的余额减少1000元，将小红的余额增加1000元。万一在这两个操作之间突然出现错误比如银行系统崩溃，导致小明余额减少而小红的余额没有增加，这样就不对了。事务就是保证这两个关键操作要么都成功，要么都要失败。 + +### 事务的特性(ACID) + +![事务的特性](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/2019-6/事务特性.png) + + +1. **原子性：** 事务是最小的执行单位，不允许分割。事务的原子性确保动作要么全部完成，要么完全不起作用； +2. **一致性：** 执行事务前后，数据保持一致，例如转账业务中，无论事务是否成功，转账者和收款人的总额应该是不变的； +3. **隔离性：** 并发访问数据库时，一个用户的事务不被其他事务所干扰，各并发事务之间数据库是独立的； +4. **持久性：** 一个事务被提交之后。它对数据库中数据的改变是持久的，即使数据库发生故障也不应该对其有任何影响。 + +### 并发事务带来的问题 + +在典型的应用程序中，多个事务并发运行，经常会操作相同的数据来完成各自的任务（多个用户对统一数据进行操作）。并发虽然是必须的，但可能会导致以下的问题。 + +- **脏读（Dirty read）:** 当一个事务正在访问数据并且对数据进行了修改，而这种修改还没有提交到数据库中，这时另外一个事务也访问了这个数据，然后使用了这个数据。因为这个数据是还没有提交的数据，那么另外一个事务读到的这个数据是“脏数据”，依据“脏数据”所做的操作可能是不正确的。 +- **丢失修改（Lost to modify）:** 指在一个事务读取一个数据时，另外一个事务也访问了该数据，那么在第一个事务中修改了这个数据后，第二个事务也修改了这个数据。这样第一个事务内的修改结果就被丢失，因此称为丢失修改。 例如：事务1读取某表中的数据A=20，事务2也读取A=20，事务1修改A=A-1，事务2也修改A=A-1，最终结果A=19，事务1的修改被丢失。 +- **不可重复读（Unrepeatableread）:** 指在一个事务内多次读同一数据。在这个事务还没有结束时，另一个事务也访问该数据。那么，在第一个事务中的两次读数据之间，由于第二个事务的修改导致第一个事务两次读取的数据可能不太一样。这就发生了在一个事务内两次读到的数据是不一样的情况，因此称为不可重复读。 +- **幻读（Phantom read）:** 幻读与不可重复读类似。它发生在一个事务（T1）读取了几行数据，接着另一个并发事务（T2）插入了一些数据时。在随后的查询中，第一个事务（T1）就会发现多了一些原本不存在的记录，就好像发生了幻觉一样，所以称为幻读。 + +**不可重复度和幻读区别：** + +不可重复读的重点是修改，幻读的重点在于新增或者删除。 + +例1（同样的条件, 你读取过的数据, 再次读取出来发现值不一样了 ）：事务1中的A先生读取自己的工资为 1000的操作还没完成，事务2中的B先生就修改了A的工资为2000，导 致A再读自己的工资时工资变为 2000；这就是不可重复读。 + + 例2（同样的条件, 第1次和第2次读出来的记录数不一样 ）：假某工资单表中工资大于3000的有4人，事务1读取了所有工资大于3000的人，共查到4条记录，这时事务2 又插入了一条工资大于3000的记录，事务1再次读取时查到的记录就变为了5条，这样就导致了幻读。 + +### 事务隔离级别 + +**SQL 标准定义了四个隔离级别：** + +- **READ-UNCOMMITTED(读取未提交)：** 最低的隔离级别，允许读取尚未提交的数据变更，**可能会导致脏读、幻读或不可重复读**。 +- **READ-COMMITTED(读取已提交)：** 允许读取并发事务已经提交的数据，**可以阻止脏读，但是幻读或不可重复读仍有可能发生**。 +- **REPEATABLE-READ(可重复读)：** 对同一字段的多次读取结果都是一致的，除非数据是被本身事务自己所修改，**可以阻止脏读和不可重复读，但幻读仍有可能发生**。 +- **SERIALIZABLE(可串行化)：** 最高的隔离级别，完全服从ACID的隔离级别。所有的事务依次逐个执行，这样事务之间就完全不可能产生干扰，也就是说，**该级别可以防止脏读、不可重复读以及幻读**。 + +---- + +| 隔离级别 | 脏读 | 不可重复读 | 幻影读 | +| :---: | :---: | :---:| :---: | +| READ-UNCOMMITTED | √ | √ | √ | +| READ-COMMITTED | × | √ | √ | +| REPEATABLE-READ | × | × | √ | +| SERIALIZABLE | × | × | × | + +MySQL InnoDB 存储引擎的默认支持的隔离级别是 **REPEATABLE-READ（可重读）**。我们可以通过`SELECT @@tx_isolation;`命令来查看，MySQL 8.0 该命令改为`SELECT @@transaction_isolation;` + +```sql +mysql> SELECT @@tx_isolation; ++-----------------+ +| @@tx_isolation | ++-----------------+ +| REPEATABLE-READ | ++-----------------+ +``` + +~~这里需要注意的是：与 SQL 标准不同的地方在于 InnoDB 存储引擎在 **REPEATABLE-READ（可重读）** 事务隔离级别下使用的是 Next-Key Lock 锁算法，因此可以避免幻读的产生，这与其他数据库系统(如 SQL Server)是不同的。所以说 InnoDB 存储引擎的默认支持的隔离级别是 **REPEATABLE-READ（可重读）** 已经可以完全保证事务的隔离性要求，即达到了 SQL 标准的 **SERIALIZABLE(可串行化)** 隔离级别。~~ + +🐛 问题更正：**MySQL InnoDB 的 REPEATABLE-READ（可重读）并不保证避免幻读，需要应用使用加锁读来保证。而这个加锁读使用到的机制就是 Next-Key Locks。** + +因为隔离级别越低，事务请求的锁越少，所以大部分数据库系统的隔离级别都是 **READ-COMMITTED(读取提交内容)** ，但是你要知道的是 InnoDB 存储引擎默认使用 **REPEATABLE-READ（可重读）** 并不会有任何性能损失。 + +InnoDB 存储引擎在 **分布式事务** 的情况下一般会用到 **SERIALIZABLE(可串行化)** 隔离级别。 + +🌈 拓展一下(以下内容摘自《MySQL 技术内幕：InnoDB 存储引擎(第 2 版)》7.7 章)： + +> InnoDB 存储引擎提供了对 XA 事务的支持，并通过 XA 事务来支持分布式事务的实现。分布式事务指的是允许多个独立的事务资源（transactional resources）参与到一个全局的事务中。事务资源通常是关系型数据库系统，但也可以是其他类型的资源。全局事务要求在其中的所有参与的事务要么都提交，要么都回滚，这对于事务原有的 ACID 要求又有了提高。另外，在使用分布式事务时，InnoDB 存储引擎的事务隔离级别必须设置为 SERIALIZABLE。 + +### 实际情况演示 + +在下面我会使用 2 个命令行mysql ，模拟多线程（多事务）对同一份数据的脏读问题。 + +MySQL 命令行的默认配置中事务都是自动提交的，即执行SQL语句后就会马上执行 COMMIT 操作。如果要显式地开启一个事务需要使用命令：`START TRANSACTION`。 + +我们可以通过下面的命令来设置隔离级别。 + +```sql +SET [SESSION|GLOBAL] TRANSACTION ISOLATION LEVEL [READ UNCOMMITTED|READ COMMITTED|REPEATABLE READ|SERIALIZABLE] +``` + +我们再来看一下我们在下面实际操作中使用到的一些并发控制语句: + +- `START TRANSACTION` |`BEGIN`：显式地开启一个事务。 +- `COMMIT`：提交事务，使得对数据库做的所有修改成为永久性。 +- `ROLLBACK`：回滚会结束用户的事务，并撤销正在进行的所有未提交的修改。 + +#### 脏读(读未提交) + +
+ +
+ +#### 避免脏读(读已提交) + +
+ +
+ +#### 不可重复读 + +还是刚才上面的读已提交的图，虽然避免了读未提交，但是却出现了，一个事务还没有结束，就发生了 不可重复读问题。 + +
+ +
+ +#### 可重复读 + +
+ +
+ +#### 防止幻读(可重复读) + +
+ +
+ +一个事务对数据库进行操作，这种操作的范围是数据库的全部行，然后第二个事务也在对这个数据库操作，这种操作可以是插入一行记录或删除一行记录，那么第一个是事务就会觉得自己出现了幻觉，怎么还有没有处理的记录呢? 或者 怎么多处理了一行记录呢? + +幻读和不可重复读有些相似之处 ，但是不可重复读的重点是修改，幻读的重点在于新增或者删除。 + +### 参考 + +- 《MySQL技术内幕：InnoDB存储引擎》 +- +- [Mysql 锁：灵魂七拷问](https://tech.youzan.com/seven-questions-about-the-lock-of-mysql/) +- [Innodb 中的事务隔离级别和锁的关系](https://tech.meituan.com/2014/08/20/innodb-lock.html) diff --git a/docs/database/redis/3-commonly-used-cache-read-and-write-strategies.md b/docs/database/redis/3-commonly-used-cache-read-and-write-strategies.md new file mode 100644 index 0000000000000000000000000000000000000000..00b6535aa5e9652f9a8fd8145b72961f57e07fbc --- /dev/null +++ b/docs/database/redis/3-commonly-used-cache-read-and-write-strategies.md @@ -0,0 +1,116 @@ +--- +title: 3种常用的缓存读写策略 +category: 数据库 +tag: + - Redis +--- + + +看到很多小伙伴简历上写了“**熟练使用缓存**”，但是被我问到“**缓存常用的3种读写策略**”的时候却一脸懵逼。 + +在我看来，造成这个问题的原因是我们在学习 Redis 的时候，可能只是简单了写一些 Demo，并没有去关注缓存的读写策略，或者说压根不知道这回事。 + +但是，搞懂3种常见的缓存读写策略对于实际工作中使用缓存以及面试中被问到缓存都是非常有帮助的！ + +下面我会简单介绍一下自己对于这 3 种缓存读写策略的理解。 + +另外，**这3 种缓存读写策略各有优劣，不存在最佳，需要我们根据具体的业务场景选择更适合的。** + +*个人能力有限。如果文章有任何需要补充/完善/修改的地方，欢迎在评论区指出，共同进步！——爱你们的 Guide 哥* + +### Cache Aside Pattern（旁路缓存模式） + +**Cache Aside Pattern 是我们平时使用比较多的一个缓存读写模式，比较适合读请求比较多的场景。** + +Cache Aside Pattern 中服务端需要同时维系 DB 和 cache，并且是以 DB 的结果为准。 + +下面我们来看一下这个策略模式下的缓存读写步骤。 + +**写** ： + +- 先更新 DB +- 然后直接删除 cache 。 + +简单画了一张图帮助大家理解写的步骤。 + +![](https://img-blog.csdnimg.cn/img_convert/5687fe759a1dac9ed9554d27e3a23b6d.png) + +**读** : + +- 从 cache 中读取数据，读取到就直接返回 +- cache中读取不到的话，就从 DB 中读取数据返回 +- 再把数据放到 cache 中。 + +简单画了一张图帮助大家理解读的步骤。 + +![](https://img-blog.csdnimg.cn/img_convert/a8c18b5f5b1aed03234bcbbd8c173a87.png) + + +你仅仅了解了上面这些内容的话是远远不够的，我们还要搞懂其中的原理。 + +比如说面试官很可能会追问：“**在写数据的过程中，可以先删除 cache ，后更新 DB 么？**” + +**答案：** 那肯定是不行的！因为这样可能会造成**数据库（DB）和缓存（Cache）数据不一致**的问题。为什么呢？比如说请求1 先写数据A，请求2随后读数据A的话就很有可能产生数据不一致性的问题。这个过程可以简单描述为： + +> 请求1先把cache中的A数据删除 -> 请求2从DB中读取数据->请求1再把DB中的A数据更新。 + +当你这样回答之后，面试官可能会紧接着就追问：“**在写数据的过程中，先更新DB，后删除cache就没有问题了么？**” + +**答案：** 理论上来说还是可能会出现数据不一致性的问题，不过概率非常小，因为缓存的写入速度是比数据库的写入速度快很多！ + +比如请求1先读数据 A，请求2随后写数据A，并且数据A不在缓存中的话也有可能产生数据不一致性的问题。这个过程可以简单描述为： + +> 请求1从DB读数据A->请求2写更新数据 A 到数据库并把删除cache中的A数据->请求1将数据A写入cache。 + +现在我们再来分析一下 **Cache Aside Pattern 的缺陷**。 + +**缺陷1：首次请求数据一定不在 cache 的问题** + +解决办法：可以将热点数据可以提前放入cache 中。 + +**缺陷2：写操作比较频繁的话导致cache中的数据会被频繁被删除，这样会影响缓存命中率 。** + +解决办法： + +- 数据库和缓存数据强一致场景 ：更新DB的时候同样更新cache，不过我们需要加一个锁/分布式锁来保证更新cache的时候不存在线程安全问题。 +- 可以短暂地允许数据库和缓存数据不一致的场景 ：更新DB的时候同样更新cache，但是给缓存加一个比较短的过期时间，这样的话就可以保证即使数据不一致的话影响也比较小。 + +### Read/Write Through Pattern（读写穿透） + +Read/Write Through Pattern 中服务端把 cache 视为主要数据存储，从中读取数据并将数据写入其中。cache 服务负责将此数据读取和写入 DB，从而减轻了应用程序的职责。 + +这种缓存读写策略小伙伴们应该也发现了在平时在开发过程中非常少见。抛去性能方面的影响，大概率是因为我们经常使用的分布式缓存 Redis 并没有提供 cache 将数据写入DB的功能。 + +**写（Write Through）：** + +- 先查 cache，cache 中不存在，直接更新 DB。 +- cache 中存在，则先更新 cache，然后 cache 服务自己更新 DB（**同步更新 cache 和 DB**）。 + +简单画了一张图帮助大家理解写的步骤。 + +![](https://img-blog.csdnimg.cn/20210201100340808.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM0MzM3Mjcy,size_16,color_FFFFFF,t_70) + +**读(Read Through)：** + +- 从 cache 中读取数据，读取到就直接返回 。 +- 读取不到的话，先从 DB 加载，写入到 cache 后返回响应。 + +简单画了一张图帮助大家理解读的步骤。 + +![](https://img-blog.csdnimg.cn/img_convert/9ada757c78614934aca11306f334638d.png) + +Read-Through Pattern 实际只是在 Cache-Aside Pattern 之上进行了封装。在 Cache-Aside Pattern 下，发生读请求的时候，如果 cache 中不存在对应的数据，是由客户端自己负责把数据写入 cache，而 Read-Through Pattern 则是 cache 服务自己来写入缓存的，这对客户端是透明的。 + +和 Cache Aside Pattern 一样， Read-Through Pattern 也有首次请求数据一定不再 cache 的问题，对于热点数据可以提前放入缓存中。 + +### Write Behind Pattern（异步缓存写入） + +Write Behind Pattern 和 Read/Write Through Pattern 很相似，两者都是由 cache 服务来负责 cache 和 DB 的读写。 + +但是，两个又有很大的不同：**Read/Write Through 是同步更新 cache 和 DB，而 Write Behind Caching 则是只更新缓存，不直接更新 DB，而是改为异步批量的方式来更新 DB。** + +很明显，这种方式对数据一致性带来了更大的挑战，比如cache数据可能还没异步更新DB的话，cache服务可能就就挂掉了。 + +这种策略在我们平时开发过程中也非常非常少见，但是不代表它的应用场景少，比如消息队列中消息的异步写入磁盘、MySQL 的 InnoDB Buffer Pool 机制都用到了这种策略。 + +Write Behind Pattern 下 DB 的写性能非常高，非常适合一些数据经常变化又对数据一致性要求没那么高的场景，比如浏览量、点赞量。 diff --git a/docs/database/redis/images/redis-all/cache-process.png b/docs/database/redis/images/redis-all/cache-process.png new file mode 100644 index 0000000000000000000000000000000000000000..8c695fb3aa3906afb031476de4d0c1d13d1e6237 Binary files /dev/null and b/docs/database/redis/images/redis-all/cache-process.png differ diff --git a/docs/database/redis/images/redis-all/redis-list.drawio b/docs/database/redis/images/redis-all/redis-list.drawio new file mode 100644 index 0000000000000000000000000000000000000000..afa767154b78e800813cbfe4c672ac94cbdcff60 --- /dev/null +++ b/docs/database/redis/images/redis-all/redis-list.drawio @@ -0,0 +1 @@ +7VlNc5swFPw1PiaDENjmmNjpx6Gdjt1J2lNHAzKoEYgRcmzn11cYyRgJT1w3DnScU3grIaHd5b2HM4CTdP2Rozz5wiJMB64TrQdwOnBdEEAo/5TIpkICx6mAmJNITaqBOXnGCtTTliTCRWOiYIwKkjfBkGUZDkUDQ5yzVXPagtHmrjmKsQXMQ0Rt9IFEIqnQsTuq8U+YxIneGQyDaiRFerI6SZGgiK32IHg3gBPOmKiu0vUE05I8zUt134cDo7sH4zgTx9wwu/+V/H4g/myezsD35/vZ56/ulVrlCdGlOrB6WLHRDHC2zCJcLgIG8HaVEIHnOQrL0ZXUXGKJSKkaLh6xCBMVLFgmlKJgJGO1F+YCrw8eAuyokZ7CLMWCb+QUdcOVp9hUdnKhile1OL62WLInzEhhSPkh3i1dUyYvFGt/waBrMbi9BD3lUfPm2bwFLbT556INttPWc/sB035d0+i10wj7TaM77hmNw5fTIM6im7KeyCikqChI2ORMHp1vfsjA0cHPMrh2fR1P1/uj042KjiAbR1aRMqiWVRHxGIuXUr0tSSNxHqacY4oEeWo+RpsOaodvjMgHrPM2gKbk4+YaBVvyEKvb9suYuZLpHdcwRUWEtdDWF7tzn26V0f9ula4s4A0N4cbOtX+aB3zfWupNPaCb01cxAXjPF0cofGq68AJjIT8wXXdusxzRY/fbLJ0VDbPbOj1j2PXnrVOG/Z3A82WRWFaQXZUwujHB2SOeMMq4RDKW4VJLQqkBIUrirHSQVA9L/Lbs0Yj8lL1RAymJonKb1vavbhCP9M0/dYA+OFDF95zltTjLLPav1gECu5PmOcvf5aloD7qWx7fkoRf8+siiYggEuhbI/oSil/v+2Pp0/gLZ3y18u20/BTqDJp5O8VoSp2tJxvYrgxcXpIjV351PERnWv7RXPV39/wp49wc= \ No newline at end of file diff --git a/docs/database/redis/images/redis-all/redis-list.png b/docs/database/redis/images/redis-all/redis-list.png new file mode 100644 index 0000000000000000000000000000000000000000..31ce99333dbffe9b79b17a019922e2350ffa55d8 Binary files /dev/null and b/docs/database/redis/images/redis-all/redis-list.png differ diff --git a/docs/database/redis/images/redis-all/redis-rollBack.png b/docs/database/redis/images/redis-all/redis-rollBack.png new file mode 100644 index 0000000000000000000000000000000000000000..e7c15dde70259ce15c0468418c5ccc36a410a4a7 Binary files /dev/null and b/docs/database/redis/images/redis-all/redis-rollBack.png differ diff --git a/docs/database/redis/images/redis-all/redis-vs-memcached.png b/docs/database/redis/images/redis-all/redis-vs-memcached.png new file mode 100644 index 0000000000000000000000000000000000000000..8d52b6b71885fcadd36499b5845f8d32baf31dc5 Binary files /dev/null and b/docs/database/redis/images/redis-all/redis-vs-memcached.png differ diff --git a/docs/database/redis/images/redis-all/redis4.0-more-thread.png b/docs/database/redis/images/redis-all/redis4.0-more-thread.png new file mode 100644 index 0000000000000000000000000000000000000000..dfcb638a4b6c2996086c69a025cc8b3845be08c4 Binary files /dev/null and b/docs/database/redis/images/redis-all/redis4.0-more-thread.png differ diff --git "a/docs/database/redis/images/redis-all/redis\344\272\213\344\273\266\345\244\204\347\220\206\345\231\250.png" "b/docs/database/redis/images/redis-all/redis\344\272\213\344\273\266\345\244\204\347\220\206\345\231\250.png" new file mode 100644 index 0000000000000000000000000000000000000000..3b3c276af72c12e01e23cd8e33f0c6c0f6726696 Binary files /dev/null and "b/docs/database/redis/images/redis-all/redis\344\272\213\344\273\266\345\244\204\347\220\206\345\231\250.png" differ diff --git "a/docs/database/redis/images/redis-all/redis\344\272\213\345\212\241.png" "b/docs/database/redis/images/redis-all/redis\344\272\213\345\212\241.png" new file mode 100644 index 0000000000000000000000000000000000000000..adba0c12049c27f60d56650168c6b0d18d702dde Binary files /dev/null and "b/docs/database/redis/images/redis-all/redis\344\272\213\345\212\241.png" differ diff --git "a/docs/database/redis/images/redis-all/redis\350\277\207\346\234\237\346\227\266\351\227\264.png" "b/docs/database/redis/images/redis-all/redis\350\277\207\346\234\237\346\227\266\351\227\264.png" new file mode 100644 index 0000000000000000000000000000000000000000..aa6dcabd64da1920ede525a1ad4a23569f6770bf Binary files /dev/null and "b/docs/database/redis/images/redis-all/redis\350\277\207\346\234\237\346\227\266\351\227\264.png" differ diff --git a/docs/database/redis/images/redis-all/try-redis.png b/docs/database/redis/images/redis-all/try-redis.png new file mode 100644 index 0000000000000000000000000000000000000000..a86d44ef266808f58bb030e173e5a6381f71c683 Binary files /dev/null and b/docs/database/redis/images/redis-all/try-redis.png differ diff --git a/docs/database/redis/images/redis-all/what-is-redis.png b/docs/database/redis/images/redis-all/what-is-redis.png new file mode 100644 index 0000000000000000000000000000000000000000..204f71bd0a147903e89b8c0c17d2ad59e11d9fa4 Binary files /dev/null and b/docs/database/redis/images/redis-all/what-is-redis.png differ diff --git "a/docs/database/redis/images/redis-all/\344\275\277\347\224\250\347\274\223\345\255\230\344\271\213\345\220\216.png" "b/docs/database/redis/images/redis-all/\344\275\277\347\224\250\347\274\223\345\255\230\344\271\213\345\220\216.png" new file mode 100644 index 0000000000000000000000000000000000000000..b49d157c0a2384118aee389539cc6bac74d89bac Binary files /dev/null and "b/docs/database/redis/images/redis-all/\344\275\277\347\224\250\347\274\223\345\255\230\344\271\213\345\220\216.png" differ diff --git "a/docs/database/redis/images/redis-all/\345\212\240\345\205\245\345\270\203\351\232\206\350\277\207\346\273\244\345\231\250\345\220\216\347\232\204\347\274\223\345\255\230\345\244\204\347\220\206\346\265\201\347\250\213.png" "b/docs/database/redis/images/redis-all/\345\212\240\345\205\245\345\270\203\351\232\206\350\277\207\346\273\244\345\231\250\345\220\216\347\232\204\347\274\223\345\255\230\345\244\204\347\220\206\346\265\201\347\250\213.png" new file mode 100644 index 0000000000000000000000000000000000000000..dad4a5d811f1e7320464e1763f4a6dffc60c8402 Binary files /dev/null and "b/docs/database/redis/images/redis-all/\345\212\240\345\205\245\345\270\203\351\232\206\350\277\207\346\273\244\345\231\250\345\220\216\347\232\204\347\274\223\345\255\230\345\244\204\347\220\206\346\265\201\347\250\213.png" differ diff --git "a/docs/database/redis/images/redis-all/\345\215\225\344\275\223\346\236\266\346\236\204.png" "b/docs/database/redis/images/redis-all/\345\215\225\344\275\223\346\236\266\346\236\204.png" new file mode 100644 index 0000000000000000000000000000000000000000..958607d9968705cf6354cc0afe8b1cb021e0e806 Binary files /dev/null and "b/docs/database/redis/images/redis-all/\345\215\225\344\275\223\346\236\266\346\236\204.png" differ diff --git "a/docs/database/redis/images/redis-all/\347\274\223\345\255\230\347\232\204\345\244\204\347\220\206\346\265\201\347\250\213.png" "b/docs/database/redis/images/redis-all/\347\274\223\345\255\230\347\232\204\345\244\204\347\220\206\346\265\201\347\250\213.png" new file mode 100644 index 0000000000000000000000000000000000000000..0d48d49a027d448686e2aa43c4f7908818695f9c Binary files /dev/null and "b/docs/database/redis/images/redis-all/\347\274\223\345\255\230\347\232\204\345\244\204\347\220\206\346\265\201\347\250\213.png" differ diff --git "a/docs/database/redis/images/redis-all/\351\233\206\344\270\255\345\274\217\347\274\223\345\255\230\346\236\266\346\236\204.png" "b/docs/database/redis/images/redis-all/\351\233\206\344\270\255\345\274\217\347\274\223\345\255\230\346\236\266\346\236\204.png" new file mode 100644 index 0000000000000000000000000000000000000000..832ea8fb6e371745ef70aa420f10e6d7f32dac93 Binary files /dev/null and "b/docs/database/redis/images/redis-all/\351\233\206\344\270\255\345\274\217\347\274\223\345\255\230\346\236\266\346\236\204.png" differ diff --git "a/docs/database/redis/images/\347\274\223\345\255\230\350\257\273\345\206\231\347\255\226\347\225\245/cache-aside-read.drawio" "b/docs/database/redis/images/\347\274\223\345\255\230\350\257\273\345\206\231\347\255\226\347\225\245/cache-aside-read.drawio" new file mode 100644 index 0000000000000000000000000000000000000000..bc4c6d0cca713d2e0db2aaac480477ec795407d3 --- /dev/null +++ "b/docs/database/redis/images/\347\274\223\345\255\230\350\257\273\345\206\231\347\255\226\347\225\245/cache-aside-read.drawio" @@ -0,0 +1 @@ +7Vpbc+o2EP41ekzHl/j2iAmk02nmdA6dpn3qCFsYTWSLY0Qg/fWVbMnYluE4B4jTQh4Se6WVVt+32pU2BvY43T3mcLV8ojEiwDLiHbAfgGWZluPzP0LyVkoCwygFSY5j2WkvmOF/kBSqbhsco3WjI6OUMLxqCiOaZShiDRnMc7ptdltQ0px1BROkCWYRJLr0GcdsWUp9y9vLf0Y4WaqZTTcoW1KoOsuVrJcwptuayJ4Ae5xTysqndDdGRICncCn1pgdaK8NylLE+Ck/Pf/xthHPraf7NePliLeLZ1+c7OcorJBu5YGkse1MI5HSTxUgMYgI73C4xQ7MVjETrlnPOZUuWEtm8wISMKaF5oWsvFgsrirh8zXL6gmotsTt3HVe0KFiEekRTzLs/GPw5IXC9ls/SSpQztDu4fLMClXsjoili+RvvIhVs5VHSEX3fKd+3e1pNxdWyRqkrZVB6UlINvQebP0i834G9db3YW0Njb2vYx5BBDX++ZNYEuQlmRjN0BHlIcJJxWcRxQrwxFChiHlxGsiHFcSzm6qR2T75RTaxiUME3zZgMmFbQIq1O5jkIvG8RqN5rBLod/NmX4u9e4y8TVN3468dflYWH4s+5mtjnGJ8t77jXi/3gece75Z13EWi3845OYFfcUjyfnT//lndO4W/wvBNcTexzg8+Wd9Ql4BrBHzzxmPpN/5Z5jjDoWZ/sxmPq5YJb6nkHgYOnHlOvOfxfw5/vf7rcoxcMrgb84XOPftu/5Z4jDAbtcunguUcvGdxyzzsIHD736HUHjTyUxSPxDzNBgIBGANKIeC38mgjbXIJ2mP0pe4vnvwSiPzny7WEnAS5e3hpoo1j7L1wLa24q3eQROrbIbk5qmDsdmCtZjghk+LVpRhcRcobfKOYGHiw1BSrjqCFK86XWns4eA7VqGQzmCWLaQIVfVMs+wVX0Esd/zFWGcgG/vevbzPV1gXYG/3AX6FElublAF3Nu+9Lxo1GgXUDQBrqwC6h1NFzAJUV2t/bK7reN+HwhBJN7EPrAD8DEAf4U+GPxwNcQmGASgMAG4QRMfDAywcivqdVdSgmF59ytC9cZ8Q62vdrVNdyknJDP8wACp3N4UnadClNlfymM8esJk8pB5vnpY3DrCluU9PSTlBSd9RBVv7IcOi/Vdrptn+f8ZPt+w/s9Vz8/OeZHHqAsvXz2PZcSFN5JNoQ/ELRgh/1hvYJZH68yne7twPcf3w5jsQt49uD37ckUhGMQjGYZxGRMcDrnnWEqSM7m61XTFcvZj3toKRXmnGDnBTCrBQQHjMYFFHzhngxFoVetu/z9iNlyM6/w+QW+wkfxkdkPwcGlJSK99/HF92e9vNDOxEKJ8hExEzsrEK8EzhEJYfSSFGO3AwxXrl3VjOKn0qJ5jPIOjSlMMREzPMIcpjSLlRkSGENS/aUyxTNKPiOcJb/TlTwiSMGvwgsakpAyRtOm7KsMA2eKQZ6qWakM7OhlFKsrBt1fLAbpFeDbsazXscw0vnep6nsuMw1v2LO5pVeRs41Q+9jAM2R1RefgcuUV/rr/QrfkcP+dsz35Fw== \ No newline at end of file diff --git "a/docs/database/redis/images/\347\274\223\345\255\230\350\257\273\345\206\231\347\255\226\347\225\245/cache-aside-read.png" "b/docs/database/redis/images/\347\274\223\345\255\230\350\257\273\345\206\231\347\255\226\347\225\245/cache-aside-read.png" new file mode 100644 index 0000000000000000000000000000000000000000..5a687c746b93be790dbc3729b3b1b3bca5001a61 Binary files /dev/null and "b/docs/database/redis/images/\347\274\223\345\255\230\350\257\273\345\206\231\347\255\226\347\225\245/cache-aside-read.png" differ diff --git "a/docs/database/redis/images/\347\274\223\345\255\230\350\257\273\345\206\231\347\255\226\347\225\245/cache-aside-write.drawio" "b/docs/database/redis/images/\347\274\223\345\255\230\350\257\273\345\206\231\347\255\226\347\225\245/cache-aside-write.drawio" new file mode 100644 index 0000000000000000000000000000000000000000..6fddf10f064eb3ecd2446ba3c5663e373533521d --- /dev/null +++ "b/docs/database/redis/images/\347\274\223\345\255\230\350\257\273\345\206\231\347\255\226\347\225\245/cache-aside-write.drawio" @@ -0,0 +1 @@ +7LzXsuTYkSX6NWl254FtAAIqHqG11ngZgwporfH1A5zMLFaRySZ5L7unZ26fqjwHsYGt3Zcv9+2Iby+qPbgpGgqlT7PmGwSkx7cX/Q2CwPfrdf95Ss7vJW8A+F6QT2X646E/F1jllf0o/PnYWqbZ/IcHl75vlnL4Y2HSd12WLH8oi6ap3//42Kdv/tjrEOXZXxVYSdT8dalXpkvxvRSHsD+X81mZFz97BtH39ztt9PPhHzOZiyjt998VvZhvL2rq++X7VXtQWfMs3s91+V6P/Rt3fxvYlHXLP1LhaIIYQnDfkqb05QKximXAn34u8xY1648Zf4PQ5m6QjO+L/Ln4WTAPUffMYzl/LA46rs/gyaRv+unbi7hvTnn8/yD30O5mqfv3Hy7/x3P9NHfvQrf86RO1ZXN+r3a3FbXD183XC77/ttk0lXt2r2E2/dXN39r8qzvD8gwwm8rPP1Epz/opL6N/osZStrdMQkCX7c+c+/ZZmH+49rzMfZf/7Qo/xv/7tZq/9OJZKRD7N2Q4/uLu9x15bnf91EbNb7ebbFmy6U/3ziXl3eWvHlmyY/lT1JR59/12k32WP94su/RLxJ67wO/6/rq5TFE3f+4mfzbeZb89sPdT+se+f189jpI6n/q1S//0FwIEIchvi/EX1//jj72nWdJP0VL23S+6T8t5aKIfElZ2Tfm7e5+mj5bf1/kpyz+FHvq3bwz+jWC/keQ3BvmGs9/e6DcG/kbi33D6qwT/RgLfGOzbm/iGwz8eftM/leXWw+/68t869F9dh/7fCuJfisxvo+ni+fugqC9B+ZKVR3TIbzhDfxcn4hsBPDJD0s//txTdIkSiz603cD/19Qz67f3+0QCBJFFSZD8EkPh7UnYX/w69oT8IHPQozl2+F+WSWbdyPsX7bbzvsmJpm/sTeF8+S/bDGv9Yp7+0Nj8M0JZNd4u/K/phfbisb7NlOu9Hftx9IT+MzQ8q8EJ/fN7/bFihn/Sg+J1RhX+URT9sef5b0382d/fFD4v3z1g/8G9av/9W1P96ivp/sLH7D7ZWf8XZwH/7DXHuSt/B427tN/z4hW274Qb5MmnoY+GIG4PuB6hvOPWrh39v/8hvJPxVi7lx6gvU7mfgLywjv72Z38Y2/fsw9TcQ7V+CXk0UZw35G85T33X4bu/Ffv38awAO/wt8Q/4a30D0F/iG/wvwTaedpuK5M2cg0KMIasRg+k+/gLcf9oT6EgXq2xv7sakk9mO/34QYbRH3uF2/2LmnFv3t/SUT97Dvpn7W+l7j2fTXIwZ/Y99+t0fzMvV19nMrvuT63riyaf6i6Ie60sm9MTc+vshnQ8rbQyN+3GjLNH26+aVQfO139izSvyMHPzv/C6l5Pv9OVMiv//5FtvD1+jfkD9ICY/+gNYT+BdKSMkbzbv5nOG1tTP/PbKnwvPqVtPzlLj7LNvyNuf7mg0fxz8eBv7FSf3NZoNffpwgg9ItFAf/jOMLfX5Xbsx+ey7L9Cib8JqDyI216P5ffIZ+O+2Xp238Xjj5fP78Q8qV/pDmah+9Bjk95PEJNfnVJ/CwFfpbc12m0RLfJ+P4RYofHCFOlS2rmDkhc3hP3j2o5BePk95Xy/KIFigjuv9TiSWh2XzgL0DCGa8L+CqXUx/oGkRBo8xtmWrAxyqgaWkBkUmbSg4Nxhm2JSs7KcgUjOJyvxapZyJbVWbkyOC93D2vQqM+UBGpgegVFHd3zAfXtjfkLht1NP/sEsdn3PzN+X5Dvq9s0PPy6SYKvzb//YBt+/w6R93tbP8g248j17mgxtCyKMijt4GCTk+znej1YIV/ttDbKhOiZ2lLhrHQIS9TuBkhToTiDRshYLpoRYAxLEBRlYRCbnCnLJOJ4aUaGsO5iVUkJzC5qwjqEMF6KnsktWxBILd0x46sYDqOFrJmcsmXB1JI9NvLa8M6vYoYpKZqWTc3ZY6KuDQ7CwqggmPoutnlDA+CQYGaL87AgIgWmPinC7hINEJ7ijPMmIyQFoj5Pxu4UDhBEhp3Xp9gkhTzfT8BuFG4XRYZcVsjrDVK8i4EDoBeNM0iZKZoV4nKLFJU8Z5BbkqinmH8mzRkWISpzwSAXuVCU+ffXggNu00zmkRWX/oAP0jpr+sU43VZvxkfDMORzvrebXbIRvFkuic7YO7WsVMjaiapY7VZBclo/p/02Pi3uLFJ8SyVrtW2pPPMqY7iRrWq8ao3j6gq+77kbqMU+PqGRZ/l3n2AoZ0BUfe56JN5SpnAd9j5gDfG07JTHrfCsfP+r73+mXA9wi8bOsR+Lbx0yo2+ZL9e4XOocmFau691PIaOQzNO4heeujLYgx+Inpu7qJFChNrtdyHhDADkfdFMh02vTBa0+6UsciJdD4zlqbZ2abS264IvJN4V6hGBc51ao9kznokISv4fmld79gMFbyprq5XZhHpDiM8DTxMOT58FP+lnHfroGH3CYdvMQ360CUM3XnesEDffPPcaT2AbGE3sjSXeGWvyOy7MahPwA8GCCxo+UtaiELPqItTiWiQM+vj0y+ERy3pz4fGWuKl4i+xocKn0fWJU5dUWZFdoIIsGsn3LBGcj6tPrdpfJon3RP2X8LEqnEVQDcosPDevXAiJB1V8bdV9NqIOLFGPVI+bzh4/oEUX5Df0iLfAMTatb1xh2QLQoFIDvNxusgp3Ex/iwEIuDDaM5mmwoiPpfus2VNVe4FxWUE/o6DCoXgC4OfLVYaP7fjktzILvPk5UL8yK/orknvNhL1OzCc44gEL7NJaBmPcE+VFu4oOerqP035yMMDLtdWnuZ7Qg3MwsViniJ8Cnf2RnXIvF4jj9T5ym65C7r2p2as7qnSg0SHFewirONan6A9EpiD4x7cUu4H7T3TyZcjBhplvDpzCYodfERuZEX1bTetAxZbGFjBIzp9XHSdpViIElnR7PILFXOAv8pbMqUn+uFuikx6Xt2HZ2vel6YgF+jrimEX3lSMUB5JcdDdH1f0Vr8bYjt/OacAyBD9BCX53rQipC0KZItozrqW1/xNw5YqI/TbEZVXtr18+5blx/pR6Svq49Ii/RowOEZGq4LcdsPlJWntyG1OWBRD3wPFUVMdlJS4nF1JmkkTiVd/6zOo651lmGkxN9P5lqdPykrZ4V436wwS/Bl7sPGQ0SBjGtQpYgMezHA6YFv2Ho8oKLsSYRZR4nOq8wiY8RYuoTCWntIskcdXNJk9jtFtuU7yk75Bo7mtTG0Er0oVQFAcIdm4J6FH1TUh+m3vWYpM/agPb3BjzhdvYeKjz3VnXpaZwqzvP4+3SZNEVc9GwipgNAg13PLAE2MXKhk2uWAWUPSiPlQ1VpGpHI4dfzdAfD3nAhry92UTmBunIxF5trw9EHyTKxf2NX5vEauN6dHoGU0dKDaJlErdpa8QUmRF8yzqI0i1jphMJTe8X9pDWsAsH2eqx03vJTKn9Dq4BrrbFanex6vJ/dhc6oCZoal6A1jzgXjp2uWYOUpyjqi0mBSdpQ+kZZlvfM9FXigxjbPJNDCT/cBI66NmfO69lwq42QVhhmfDzOG4Nb1xi8LHOA55qjVHFnnm/JQdL6g3hjlzgsW383wbCDj1p6KomAZIRMDHGSoAcnsH4NezlLjxOuPFjSiDsCGOJCpodDEDLjCSRPu3g57X3sKr20p8c2hz7Nz2X6AP9uXITUFbtkZVJzbfDSWwNvePYuZ6hU8vvheeDw/mHtdtxE6U7aX9MTSkkqMCKAfGrels/2AyKpWVfvOpGeJeVMNFr+YzghN6c9H1RpOjwRU7x8/OdegixMPMq7yNlovPVtZ2mpFgUFgFba+BjjbWO4RFPDoZToUWOYjE4zDzduIN2VcG0X8r5LsBaj3dzG1aW92UmOMydfqeT3OQWRYHLWLKlS4h+rhq1lthxlAIuzHxOnfsqxGC2nQCzIHx1rEDCd2ZLRvFzcI+iktgfb0pzshhnGALDxNsmzdjGEYtiLQLRnyJDQWSQMF4Sx9Z+n5hU6alN1YmkRSrQu5WuWbmgYlO6u3M5KN0gYqetGGes44OI01lQDYD+/y7HloT4FJpW1kBmoDZNsnE6FAsFgaMMDafwhHyHlILn55KzkjLj5IxY0XshUKukXKJqFEsC50INFVu3xtcX0tx3WMoldcaSm3cB58Hg6Vb84jR5ltYs8oXDu8SB8s3X/gUQBOQWxmuJEhrcxomhtoftTRmEXpt8vuRKWupvvCNy4uNFBoJLztsrRXv6oj9oYPzcssSMEjItCC2pYgys4b3Ijcqo0bp633AIP/24fFpazp1P3XmkEiHZK5EqCCuvezCYQ+1qB04eTuQ1QopL9thi8mJs00KTDr5Ngtkq6lHfAkMGmjghx3yxWkMcgcW08zK0ELpcnPjgeLf/jBE2qlkizoYYgGc3B8fPGlwaq3i9eE3YtjRC6mb9Q0R7Oq4VIElGkWXb3WYnPzUmmbz8DPhhKqpceNWm+nsm7bzjTBjNflFjWADNnX8uk1IXEqYjzbGEKNWFkECUa1kYS2jxcz9SXP9o0MFZ+hTZxGMrrrJPkMEOpqy9lB10SpwDAqwiNT49llKTATrxx7WsqwO0oUgWaOuU3mmsJyPTJt70oOpEB55gfF2z+Nth5rPSyWpZkU7broUpe3L0oBHKq230KUGPE73NRc3ibS+DaOQc2q7yWZx9u9+w1wJ2w3EOETwJbQs5J+PK4bMTJIZNCyuwFSaI6yq0amGz6iOKAVLQsDeIhIAvgbWRZi8W5I20DeDG6cPJrPhxgyGkOIDF8pi5cfSFZHxho5tuRxhb1ck4tPjszSo9jCN4NkP+GCPvTQCWMP3oIkFtkk4aOCH3ni0AXw1qMmh9XRj8yv2zHi8zRhLCuJs4A3JQ443NbDpww8ZJdkJ7ffaqo0DydCzZvRX5/Xqx9DePUmw5WclIFPh/REOnRNiPCuk+8cwSLS1E3nnFxOkq2QQQHGKarZtg3r9ncCMN9PoVIQBv6hAwDm14ZNWyVSv6+TOoxgBwL02t6pPg7ZK8MU+2GgWInYzR95ue8dICqCUF77Q6ON86xVDOWKycHO99g4GfwRfmfohyU2sEgumdoyPRAgPXbGlNXK0nk31Zx8hWyCzDxcesnDpwv0MfptRJzVUhtGM2QpMNetdErfMSBhl9WH5m/OuW6NGeArapZthVY8Tl5Q29KhFeTteRsEba3dDAwcrN6O9aenju2lRIdeZYpWdZW4eKChXCH1qFHsxq3k9HoGQMBnJwOFCN6ctYEX3yK+wv3qTsZbGfp4j6wL2FUnAJqVoXraeiEo5AJaSy0pv4ilqfRb48mIbvJ21Nuseycs+myuUHMmiq/CM+3E9bvAh72XVSvl1viex2PDbSN3THUnjWMCCFCWCf7Yegu7dfFtM6Ipo0NUjXb08xqMBpmyaDL/dUOgxbP4UITnT2mHnWIiMTdBSnDSM8AstqK3zDoc8CLVXOVSos3ehCsKvJOyCuiRATHxDj+u7bmt3K4xpmC+nWhVfLQRqIU/pIquMMZ1NToBRy4NmkV9jP2TY4N2+XOBfc3Go11A2w6i7sXXbUzKFtqnLrIHGrG4sl1S3qlkpbAB4/Gk2wdr3R/HeHiWQGGZZdmbsrXRl5k4oILkwn6cJ70E7pqnFfRm1clKy25fSei11YQzFXQsQnOWB/+t1xFAh4m8r84r6E72YydLM4O32Mp6fFtWjB5UZvETrRt+svhgWF9aULUi54kO2DvliM6axG3F2K+g6nNGgr+069DBxrllU7rUdlylHSo+dpMxOEaNmIHNpLcfLm0MFuvbKqg4JquPZgS8/0IkWhBkNb+6iN0/F1an1JtzQ+yN8fXOzC0MM2dvzCIrOufQ1zCxBjcIpzbQZEztN9exDfxQzebkBJTz+pJ6nuNty1yFFgwu01JtOLp5ajGOVLXpRlWPvvXygYMw7+f6zW7Wmjd+fq68byr3b5b1lmHwVIcWIqeENb+/GVtHl9BVMxXwzEOVguxjMXFNvxdMTCkpzMd365O5HCWwTQ7B8tQWCyd2GJmeDEjn7oiATaO5WqUguLHJLsrCaQikLP5LwfpzWgFRbHXBFP+ER7qES1HQJ8O15UUyoRLdz6BpADaUxziS+8x7b220lVaVkX01qQ1FXY8IN3nPZXWSaN81NmUxhupTqE8/1WINhkb3ISd9FthfhaN2PWVXQMbLQB3WNutR96MssaygyP6MBIK+wCCfbkloAUAp6RlQPPvTGxJhfdHMFmS+/q2MvW2YMhICsqdK6+rbqSCHL9IL1pF4D1uddFk9siEkiMixgwMunQwJyIDXXoH0ZWIYSFjJR1imCU/MJJcEd9vkZI4P7TXT3Brx0q4gUG9Fu79IreRvTJw7sBWO5bXB0znWese5q3S5Sc4ZZx9ge7L5U7DAHfH5kh1/sykK8VRy0TkTw3DyI/DGdV4zpVJrwBXNA1nGDiMhOn0IONsvz+fNNmWRVkkRRiDpbHInrBW6DOUbBygqN+ToedAHMm69lZx7AKeQJnNEa/PLETQplvmRCmSf7VjZaLCOdfiEk3VKEjDg2xtMpKhOykKk17lIMAYuadQGWECfQQjxaZnTlZHmU+N3izDG9e3l1O41yXajo21XalqbjzqQyaXnYuHjVK3yRr34yQqyZKC2I/IeuXarMTwWUCtpeXEyXiyq4TJNWNRZ9U5fyrXByqXEIWGF6t80mgNLPLh88H+un7njX3cbnPW0n4Eb4HvZuyjkNxTCTTji40sqj86FPXrYstzD1gtVFIXKyl4l2KphsqSPAkbg3N64Ypzs3sF/0rKt5lLd0ynsJ/RTt4LYzN+iNLLeRgLah24vm1MLbUNwuSJO2h8AbQOpIuoIPWN9jWjfPt8Pv0fnZWNdwSMjwmAVIDW3nGeu1ls1DT5UHCVEYHGMnE8tsCTlgKx+bhCq6rDPGcbNJhC4OSqvYlD4C2j09dPK2hRB3sbW6KvULOMn9Mx/69kZkyg+QGdH9DjeJ3g6ZFpuYcHcSN0pEE6UAkscoUZAzyKqFAb5lMFzOVx3HCNKSdp8S2areXOkJnAAcHpdZnASHRXaT0773Ky4HRk/PqidvfjW+hlhnLISVrFGjq9P1GCBDyhJT+S5/eTlBrahfbVffUzoX5kg1sn4v5uf5FXdwCQK63VmtZrhWJEatVvJ+mZbytNOrGtcbG/NNySPsEj0B6DF1u5xcoXXpdMxVuqUXx1SjE5SY2+lLcmwhLynbuZfSTZX7N6HZwCtQlU/ARCNKUCT7Kr7LZ7A9yKFWpV9J2LyYj/1nGWZNumRQqK4VyE47gEJDqlhVOJEgWITXDqSwJmmYQURleOMAp01dYLP5RFeC5tw7XMamzoiFpWaRC5pMXYqlay6/V/LXKQ9twMOv2rFuWHASk4JvduJ/NIgQ4hlCbnaZz+hjE9cuhljCLPlzlDwlx5lBVPc+GtvlbmnOMcbr/WI7MvUKLPIiVlglrMt/C9tNnOJEV9ZnJvVGf5J6c8TuFTMcrj6GSeHSIKpBrODbfUDNjDZvhuOG5PnU2A6jPmVftu9xNHymtC+etq66zhpOJl1GOEiRbvdrjf2Na4wl7w4WCt6w1DBp+NJ7WFI7bfNVo7+NPd5alubYYmLNL7CyPkAwTIxjYPwqiKqkmPNyiSL/eSMvs2zUj7IbQpIQZB25xqAeJrOlfKsa9W1DuE4IMhUskifuQtu4Ze3UftsxB+RgXmK5JyibvTgZLZ4999MHWIYGeIL4c3XPjL2or+AqMVp8j1T8+7YnkgMlPdFl7pshO2hAUnID48wczY4enKhQmACstUclzx60kunZkmq0QjFzpvbj0viHsIVQHwm4n5FNj15PLMdy3kk6NjiKjIZJzHDhZPG5jNTFr4zi2UR8QlWk98Peh/GB6WN15TOwCWborl7BMDCqfhAEkBgxzORzLnb/MbrO6ntQ1Dq0thswAKtr52DPaNBrtlzSG9RauR2KwaQ4lS6TWYoZoSZwhq/FjBMT/aTQVBpA2zwi71BrKbw9Dv1tJMnSOUAm2ROqP/v+IkdbAWDeT+SrNJl8wKZQ9itlvKbAqcEuXYGstki2jUQK3C8bG4UPPRrCh9vcYDVDoj5TdDiNVTMMWr+ZEN7e+09ynDGlyKoaCqChI7eLV3JwLCczgEHWskouyH5Zk87BISE1PU30puGI3rx+TIIhwjfttHrtmE5Q9+UsAEQUOTAKFkxW8kK4kbXZM70LAkyVnYC425p0PTodK71fv2GBKGj/duNXNk/Vcuc+fIhbN0ln82EgIEol1fzZ4NsDju7HRGZpRHovdrt2Gal2sxWhMsoQiVBO89PxkSm0aTOneAcdhCKwJbPmXQ1goMeIGiq5OUUiNppm7cwoFopMpNs4jfZyOxDEcR2iXVFGGEaKFad2KpBcZxaUH9EcC2L+46yogrhgpJEgliJ1aNKNRIrOcvABuk0CBFIGLgvAli0C3V6cj25l5UiEqfmI8WSBgIOEzQ/XI317jLVFROdHeG+moYTpLHWn/UTVfCDyNd8FXQKmlGbTqGSeUjiDH5VpxxwXBSEhg+tNtTfn+LRGb3MNn8ubHNl5bBoxln/FT9AxRWqlPVnGyTxH8fzy9NnYus3noyH3I3CMZK4lj+OSODzSPaQWvEGWjD/3Ly3++C9UCASQqRkt2Y7DDg3LEkSHtDd/MktCnFcMecIK8yQgxE2uj/3WqBdx+1Fp8v54DR7mNz8MA9J+Nq83LUGaH48G+6rUCyLDjARyjSAMEreLlOLIx3OBIKdcIYRZ66mU3z1qa7Z9VVFyUayVnhge0ACfPr3PBx/uSoxTUi4RwGCEx89J3Lom2xQ9VQxSqpWZGj7Lc07Ge7r/vis4z1mbSzgYiD79xfL6qO82Saf2VSGRho+6373xvu6Dw4cLmNriPMJ5mAD69Dbx20Ng7yrPKZmUawm6ZOqu4zQYZPS7dL878mzynKoSluNqpoRQgSA8p7q/Shj4dw/g/34WwfnHVIC/ezr+r8gZ+OXpOPqLDBPsKyHk9eSCEPS3N/5fNBfkV9ke1o9B/iK5/v/jjv1McIB/pn38bs8w8D8xywP635/lgUD/QKIU/Cs5Rv+j5PgfWJX/a7M8bKD+c5ZHiu6QaXYsDZY76dqM31DHew9GMt+gqWKs9WShWXEk47Eae3mMWNCvZaCavaWdbwKVqC1QS8oYPIfl54f/tYr87MmWYl9BqbB5ha/P7ccfEIaB9nX7idcQdte65+3B7MSyMAGRVsFuKbscmArD4qlZkrJJ7IZ/IBzB2IeaEUxS0DutCnwLr8tNSmyRYjV1oi9GJ0ilo6/I8e7pi3NB8hlSIJSY51lcIiAjGArDeHCb68qOk8xp6CqSRhQhtCcjJJjHt4JHUYjGt06+kDthhqWkvC96v/sg8Bd7jIJRBgKxHIuQhQVMiHWfxdYJMISp1kKAQYqu3H3wZ8JrQ2GReV5eDGAiLZ8LN/VCVnlyjKfjwq6iHT/onbDFHYeeuBRBxYJhvtYge/p4JpeaFEOTJLuKPX0pOmEqNX1lvpfn1D05itfAAinZPF/tAmkE2UhuOxmUlZ78nNwJudDQWdEyNNfD04UnJI1/cYYCmN7yc9K91gqWHr6evD5PyFB8bxOkP5t39JRY55Ff8a8n6G8vTCq6IHJ1oD3iINuSkkjePgIYAE8glVMxbubq05g+0HtFjdgC+2YPnTYb2uR1j/V9OukT0GhgKzmipXKElqI7UnOi+p4qageFEVIIhOG0E8M1aq3WVsYD+VI+qfoVKQyBXEUkIIQTxzpJpoNWOkS6imjq/CJay15BO+EQpKkDg+LJl+UvMlRvVpN9WoCZqiCMkYDKUmdsU2QcUqJmIQq1CE6yryeSmbGR7/c2zPT8PvE6cH6Fxdt3Zy2kXFxCIqf7xuaRfC8XA/O220YeZL/mCwbyJIzzTG4zu4sgJa9wUaQbP5Q0ydUfd0H2lcIinog/a8G4Qrz1cVp3l7NeJSfCqLmguYVMqEGLKrgCDRrEz3hCK4VnNAJtPhMdyhdl67sn9SziQDyj2z/Tmwfyufn44AgjcGRYcIF6LcmzOp1N3vfTbEQGEMRnuFOehUGEgZRUNQDBdx5XRIHpa4wZmMwq6hy9nZHPyvYQsYfvr61qhNdHFUgiN66vtshIE3I5JSpbTAlXDBnhgYI6k5EiuB9Ab44LypYRPpXXseYKzLjYQMLF6phospnKWGQgHq5ERTgERqn38S2rLLXT03NgZqoiwevo8aKomjrcWUSzUbm5mT+kdiaqzVAThlHAAvlugeTD8spsV9UVp6UzLX4E0rcgRJZsDtp14p/M+NiI7mk1B9vvt8Nj+IBGmqUXkoB/5lZ3o815Hfe+3N1lDfoOe9TEXziOtS+RktQWU1Xf3xHifGY4oPFxEUSo3xLpnIyycSHmoGvMPH5abGFDJTDXEh5jOcpNHClDJN4AkhTUs/s9S1BMcdyGIovk5Jr4KVEPipMEZ3K1ftwjVb0sY2FW41V3wYIRdNbq99pjFuChH8rRprIubkmwOCtuRhhf3tI6jfXr8FYVW1Ewr06xbvWTxNTVmK3E6IdXA+12k4JqLmNkJBgsO0mtxm+Pj9p+BqtPnPotk3y7DozG0VJov0vIqgYagBwZXMNxYTyCFSv9CW32HpE1LEy7Z79ux+iVjDC7Bs7sO6jXQiqttW2cy/lgxM5gBVXyfAnzkMRcpqqp+sQfbCDs48vwjSQ/Z+V1aBTdtyBOkvDH6CXuBmNbfUg2MQcfi6i5oJnq5px8n+zkPUjuMXh0LuIZZeUNV02+uvBAkZ4UkvTgLpJ6cWVf5kYpwK7i7Jr1vbCi5AM2eHqQTuOdecrbT3UDIuyisbjt3UlKm+lEJwjr/GIYnHRkqJFU7zFTkwUP5jV2zdcpwKc9CZ164vexk3/OtG5nYTJVcmfxY1hXl9PVRzcWm0J8Sb9CMhnDT9+Wm2f0BIgpBylXnsPrtQFRUmJs6nTPWa3u5ypY2SoLF8yaVegEpQgWfyM2w30lLpF4xSizd1YAZLyBpvT9VvKdj5WCiqRx+EVpFBafH6h4MiPeCwDMznlh9/wQW6UJzF5zJ+FHCOg66BDID19NpHBw70/nUIS0xvRKLPL7yfowjO5dBlOq1oxNlGqKflohDCGcJvyDv1hIai1iiAQXgxhoSettbid1yw3yJT0OpHXwqlAOdS55JbsJ1t6/xLLd4ecYQDhAUWrafDSeWx9xbY/Wc9NYVoTt9gyDS4pVhjnzSA+sPX5OP42jB2vHZjSi4qHnoHf1IgqhBP8s+LIqNPyJlS2EQMy+fHdsIalSE5ImpFYKJfZkGCPhRYSU17mYPhlJJ1+a0L4bAyySAWnNohAMPksGjBpxo1PO0gpAkUDUGipubvSWMaFx2ucUqQZRKxQMigBBynY7NwAtx5llH1fdUHf5Luesjyq6K9qXuBcV7O26Dy1rN30hMkMIgizN3otlA6eh6rhyzlAst4FrMOkJcvZAnlltCJLjnTUwMz3+0dMJekTvOcTKN5RTHvznSboBAE5rFAdfJsUMWD7SnyM4Gyk/iHBctC5wUrlFpkYJFEXOT/hUgoHVloTXiG3Jk0+6TGoPGGZfnFz/2ui3wMHwYaTTbqDvLBOywa8I9/IsSlQI0eOU9wyd2yPsGyQJVzy/nBcKXxgrouBmDM8pwITYkKTuaaDrYAyI8JOQC34FbAVMf1B8fgIbmrRPmIF8UN56/PmPP5YDs71iNBY7qfSHZ7JnhsCt+X4SCp2HH1oFSSQPpTk9UH/xgrDnD0FB9w+7BZ9XrHzCo/bzOBQzuW8WbNpbPWH81bBEO6b0g9VopiuoGUdRwbC0OrCdC+TS981JSJ3imdKACkeoyqyL1QqmMB2EQ6acNpslme2wy5I6LBPLBbCJPk6h5lxqeX4j7lHIYu9LO2qntQQxtg6lVucnkAmTFFu5F2SvpT6jQYUr3iOg5g18w/uNMJBx64BNfaR3r0cpoDzZBa5t5FZ9VIVz3gjcNZuyO5hms1VLJBuiB55rHBNy/1reJDMTpQQuFx8ugdg+Z+7xrbwehppq0QDNu2vEvjcRplO80mblS8VSYxF1uezamw/lQ1S7QFdqQC7mp8mMvoR7QS2FN6FodmXwREDUnCmQTuctxEx5E0ZzVlWq4JqByBaZnOT90YV7NWOevA5J+SS12VjBob3eCVOVvsoh4Br5mRyz1lNbkcXr9dqeeHBU4glww1cimOKhN2unch0490kdB/2u40LJwF0jIU8KDQ11/dWZ2NDkrYGGoFJ7afIuCdUMpoHTmM845E7FDN3+MYWYnv0Lqs3goYRBgdzsmMyDj1HItfxEtbK9cQbUP610YAHAp+du/nwY3xbay7R0Dc84YyQr6uq96sW9MMbCN8sAB+i6XjevmfV9Dsk32emqAuRrMjIJu48SbOGx95hOuQE8gpHIjo3zVHWYh+ZkXlUP8AWT7t578LwVQ7YDmqIdKbXnxkDe+JFwGxmLEkoCPimXJyr11REzXScHJUW5wk2RcjdIfQELVW1yH4dpvPY4dxYwFMigaOjIFmmr5OMxP05TEmnOzWHyJGlwtkhRtlUyKjnMafG67Fys2LknhNrC9TFRT2RscCDjMxUutfs8Hgnk1aMFS+N9U6k4egoZ7VKJX8HixpOpqLZ5u1uY7S78Vx5RzYEtu8gfc8V0SIE+/iFdpNZ4N2c/k/7GX5FJZ7XH6ZI1nkij4Vr+6XaTfrwftNAZ6RJn23c5UqvxaNUBDhWYvKOTaIy27lKL3UyNyVrpVqNUBjXS9IUFRumEfCRCTZbUCPXiUg2Gxdq12FvqXjqlR098N5yTE7rtLdOTk2fnK93r8A3qniWRT1ZxtC6fMcqe1UyVUilYpTYpnLjMualheWaw0VlWwSjiiQYGnTFaVfNm4dQJrlA8W2ZffeBXWdVXxUkIxz0TujYHMbFwBCH8BgZDlnHZQlP28gpqnxBpihFuR/ZTrEzGADrHDAMEKrmcRNNNJ9j28+I6mWRq4lMWZNDctl0YUI9NxUh9h+ep7k6dANWQhCMUUSJHZt/xCImEpKfFDLIB4t3xAUYg18bAlM8s885YCYWqDIfasZIJ3lC8LKqwcSzidxaCayEucRPtaKTNN5OUbufOCsn10Zx4rCUPlHFHTGjPbIwZr1cJrkg0FIg2H0yJGbfMOHhwnTbuiFXcyJUknl3wksBBWNPH3+sZBC98OlnXTNoaMnFTSfzYGv/REaMlqkAIpawDi9Z7d2FDxIVGyuTtZuyQDncjYOdiszSPK/oqfdgldj8bxgt8WMhOuU884yY84bbUIpbB0nHwUWXeSEG8SDRCOHYWD0uAvKUA6o+1VR1ye+IrI7IV/lYlNbELps4iEb7pX/DhV3H8uMR2FRk86zBbMLawkqZOIeCEGwlNtfSFkL1VObZIeket4/uTu82qMruOnDp4fiLsBMBEzUhCDvqCJTVaZ2mHxb4iNFslmoPuowAcJuQDtMqutRQV7iynrNRRZuD4Kl+eMAPwPJVzeYCVVyYhaN5OPuNjj3MxEw1vTUNk6GgUCArxIE057Y028vdi3jhcnohWkQ/L3Ag4KAVBVG5TWRaKcUA75XlXJbzIXGCyhzK5t04+WSskojq1KbOn5bAGg06la7cXWTDKkOyMFLj1gKCvggAaIk09fudKBiEoaHpTznmjjktWjYlL0/H5+DF3U53s7Z8097JGKngOBuj0cS5TT9tXwXltx0yI8iwuBVg+1DW8yPx1RWjzARh7oN9e/tLPoV9CMiXE3iafl3pqRpKMiofdeJyK7dlw9R5mllXw1MFgTsMxSyN5TMhPJJ7lxGYvvMv/Sk3aecrmOajCYpLraqGUcXi+PbuyFFMDkVvwBbdKi3JORcoMG9jG0uaTnRe2+zY0XOpHQroQlglUPKkIUjlJwrZWsI9ktxfrUvaXhutwbK4FX1XijUri9xqTx7y8d7dq9fRT2kxhThMKxqniMFan3mZOPT5uY3grPMqOVa02IpeZ1xNCghOOS2nL53N8WJdVQrnM8xaOK2kqMsUCGCR1jIL0FPs6SBpv3qSTgE/CGmSxsgu1ZjUittuaB4hYKsFswJwh5V39cUfmvaCUpV69lNM07GZ/bLicV8GYGTsb1aoiV7tZzG0xLIQODh6iEnKP13cVGTCllg08olGhgTdHvTtWRaeYpX7iFP8VH/UnvyFPnVQ/aynikaqyYWs1r3nMKD13eFsMRISgGGZOc5gUwT2JHnKsFLdHH0ENZUoxUj2hJpPhswJ6MbHuGMHNkVJZ0jCqGwJYeE5NJMEz4iE1lP4mhbdLrOAzZSBRjTw5yBOffI416G7WRYg5hqjAC7bxkARu//ITGmQIxZbnejrnQfo9lPIj1EgO3oick+lmIW6pJeTlnzp4cuVikiNUKgaIfORgtWTO2jvOKKjCrapURhODwifBF1AzT62YZ4ag4pUExMfcqrKPo9gh6Q9nYTWirGmolVtHCtsVtYlp/ritq3CcTHKAEgHsva6zCVy1W90GPgZMKzobDQVS1aSA4uLg4vESRRawS01XcAOJhyvqk/j03xylrXrfsabz4Rz6Y2zuVWpgMDBecPtnh8YYn9u+f0VliIpq77kxuXV7OjldZdYW7yb7eFAfUBMmyuqulCx498nPIz3N+EpmOcfaN+cOl02CUTx9tX1tVjMOxoEpMk0Zqx+NnkqeTNgvrpN3t+G0mx0VJmYyNVO7XjOYoEeGP2Qd+1x4dey7hDihUFwvnen0cbE2f/EgQ6Rii5PVTEJCjYL9NZ4aK6/4OYsfn1Ge0pc83Z5OQdFvfMcZiC0ynduESXv5gQjH+cvqJgBS1LGwSDpEOKGH/eqYoNLKu+elDHvuh2HfsY6q3Tyn6OrQddkxBDK6/Q6zvqBBovB7/256wNT8TgZr8eVQ+We5J+4+ie+P7zACVnH4maJd9AXD0MIE1hNHYCVls12p7f3qHNnQuXLt9WQqtD6b8eDbKA0zd98oAV6KeGRRsRpVrnU/cldADEQHt29uDbFM2qpunTOP5xj2lagnIk9CzzNZAo3A9IzQMmAjCuu8PUnxjU65dSkFHeWzVxVrcsvKFYoVlVtFhTaTWU/q8jriMhCP5Mg043xPFU2EH2VWwOgE9V5lYAK13oLAObK5+3Td8dQ1FJk3jqBuu7fYoCIPCx8rnHXDuxLx8TfjW+9oCHPIV/YQ6BVeo5BhRAotR6Oz/AlfZcKNfHC4NYZ4r33Ob59KyIu1F6WBsUxq7pL8bAtZsT95e9UgniJEJWmd+rh8pV1+9MRAhKLeUOBN8nl141jhAYMCjKHG3FTySpYVny1hVlBW4BlcotazEtOmHbXV5LZrHV+RBEYcs23c8lgzLy2SUxVSon9ioKdoaixyX7ALMt6TecKQIkEFkwXUEyN4ndJYZJIUmhQ4FiGNvpGHJMvbUmk5uDIzXiL7T4aRDg4hUUvY5VFJVjoiXt/879G2V0Tybbng80zYrGGCLSMHQD4CWOq8ZVXMALfqjm52Gvw5rS6tQdMpxuQQM50sKpbHlDJxRp5bwaL5C5j3UOCDE9Y3VihMHFMXYuHw4FpF5PCFvNyHed+iuTjNd9iWgrExGE9aGi1cBjFmEnRMjE48rxmFGDkKRNOih8bimAY5kL07TGeJzJNdZXKy0wgcRYkC7SrnurUUI01IiOR45J3HUUHr1K00cDmJhvOWCF7YB23dbGU4FprAAYMbuGn3e+nc0NeK5DljQTJVrkZBIm6fhXWbBGV3U6nlBgZWrX/OW5zc9dyr95+zh9WvLBgtqZz47zb+VhtPtEcR8YNgU3ocvtIHCFI0HYSZajHP868Egn8ihwD6G+e2/1QOwS/PXv/D3rCHf5FD8NdfRnJ/JJ6sgv97kwn+8a37mUzw/qute/9nfmHELzbuPzuV4E9/+Z1Sv0olAH8pzsh/kDi//n+cSmBSv/vCiAzeP67p8xfSLXFZth+AcBx/z8VR6L0X9rryd8K9GcGxzfEj0eftXFDllgsRaal9SUb5wlNuDgSmNXnkSZilwr96wL8pCX7h58y4tT4RAADorUpYmNrcZvt121AIyl5Zlh7IS38IWb1BE4Ic2LV9Ehv6tOkLvnbY0FmBoKzzboAIJEPgGtYgcogEDZggJIIkZ/rMCUMm+J55slhJn2DOKIk3eizveQ+WpJphBbME83wRwSujXcZwCItJosqWL8kgCXytuQmGe4IhUKAtndbBSUIUdfVVgE8SJTCR3BMy3949XPWj2oWQlxz4m2Xe9P540OVsvpw3syLF88ViZNWjzwsT7TAGWeRWoz8GtEFOBrhq+nMCiYTVhaGo1ikfuje3hCgH+1mnqAGloLb8MIQUpR52gRCldA/jCswmyM5LAq6CXHlePGMF5qMWwtI7pMK1u0ftwvN+I+uLoUkItDMzPqWwZ7XEqFEy8BK9mrYbzrQLgYTuE70pHDsJcsISPMxgJiQmFE55TgN4IL498pu4PcwfS+u3bgOXpoFr4XgEaRnx2jRE1gViWR2DMnq0cPSMaS5ySy3xkRE9AccjbgQFcHEXzX0FJUFPr+L8pAKe2DkdbYr4KfVIitKgsmQ0ymHhw9OaObfe94xYXXUVGw5Zgsi5xDqV7AVm40oLNMlXsgO9Cz9qn/XFxfnDHWXUDeNzAONlHDq5sJSLtrNt/IEnKmcC9y8t3EKnKfzARO4ltR4WzYByL2NsoRGNSppS5mLORSusvLs8+gLdTil4/HNMESis944QTk7CibLrtJeG6D4wUui593NVFgl1aYt+7LTAQrOEU2rHlAdvzRV60PBpsvebQyNCtWiRPmOssrkqj9VG/8IDlYJ7aSYOToqvYwN8h2QKsIUXFWBu0gfkO1m3EZjgKLXFC4HqUM4ITxAxeGLp5NpzQ6w9ybRnoM1gppK+elopTxtUzdvx4lWGe92YbfYAURBltGr5BCFSy7eT0w5VXVovUITk8+swhw5yPb9Qv8WVVq30zyjaZ7rQgeWQOK/bYcxFvjrBGlfNrEUk3MeCw1nolldEHQxMKjZzzp3Yhu1nbWLzvm9HMRR5qgqrHLazIvkCW2LCIiRACIxx3OieDOAuhKIVEytLC2+bKLnn3CcAqOAFP8epe6QKp1JxWLo951OofrTxgMK4q2TFdCCx7a1vJX5b6JoDYfZimD2iNtpdnhd8j/MJWAUI8Fnk3vC06R5yPr3AXFZOGA10zs0lyniCztju5kzDPN/8oE2um3O0gRx4QJ3D+JKogw3IHNCSN0fMcqyc+S1uBEXx3lDj/SFRW4IcBna3d+RiSXYgybBnvtho82DyTLHW2+jlkHxaV4g9IvSEOguDguhjDgjgeVXg1aGoo004+3guGEOPiJ+Hr6EHlYmzbY/ucyMYzvA6uXK+kafmR/B4MhQWZ6VaN1q8Lm6aEwl5PwsT6SQLTkSb5QMrjP0Kw5ATsAig6D0kcSkmA5rcXY9dciIv5NZvLXB3i6lKHYecPi5qiez7dHzmx33+vg84hVilrkCF/pGygAc2LogjAiMJCtIhKOT4eVcYuVBmXPI5eHxw+kYkxDJo6QEK27ilSxH5hAUnkIanEGuUikBrbbKpqFbPmjfuCJaE9vNOMcQsySyZB8fFI1tND/45kq3BYzmwDR4uJDnBLmq02aJck5AnuGSdG33+at/f81wahAGCmiJD04KlAKsWxCqc1iOsJxOANYC701MdjtuOsPmIawJWaedrptvCoiz6/Xkc061Rh0xlO9jY2Zi8BQw8XTHo0MLJCpuyyNsAJSbgJnJoDJ0kkiphA5C6xUz/pCgz0z4a571Hwbsb88txJCkiwG4sUXXBxl2uW8AEsok9YQNglXLd1R6r0EvFLl/rSZIoDj5ssSIVWRkxBGmmLv5AWMb5XFn/emGwZUiWg9QNWhzh92eEhFLx9AEzKUg+T1oB4hKeIA9C/ZFYws6fcBI/f47zJaNYp9AC4zv5Q5jsx37aGW7g4+ISBmmNj9IEm1ZLhEi16V4hrKsRrZ2yjm9pDSs3JWESSZ9zzSvoE/HzHH6v+22pkGYaHNKi16gor/TrnXQD7Ib0RsX2QMGL3+nS77IZ4A221btSEiZPRoSO4BoUR6iPsz9NJSlJksgztDidoeeQwWYOGyYOqcMpFXFuhG5AtaPhD5WFpnDj4GsRdPHsZyILG9g3U0ZtFoYsJddQuEexiOHDJuEF5gFDDDr4NndflnRyGVKLfc58+d2+WocoCcQUVFk7LFjeSwrfI3q3cHkgFoLqcx6EgrFX5al6wnhuTcKE5LBMwZW32chmb/JHBlyhWG1sp+6JgTIKJgozMrno/sKTZ2u4zQJgOheNWVJEd8QJ2ltn+ezGCLakgUDI57UFuHOtxn5eDaBLbQOLclNcijBpnijV57jeGJIxtNCgyh8TP75w4CvgdyvNyJCN3EgUAW4T9uBlgxU4Zjba7Aw9y4jONNNbmZWlJjzfKeN/Oml9wl41ObfHIDuUt67yvVehwZgIto6XvyZEUVWsVKvsQRVpHt12V813jnhwx3tNdUww935H70ADLcJ77O7oyiNemuJnDc/OOI/bWnKzR492/xAV5aPzfVmi1wJYqyXQNXuee9QopA0j2rVgSACnz/kn4oYLZQU5Z9S9ybTCLkUS8KrgU/HpOqCVCxOQDSUsUsWCi88+N9+VUOX52qnboi6GYLCTcSPY826CvHlZB1miqCzSTZoWqQhjBwGfM6IRxMx37OYGEbkdDQ3xGrvTRDut1araTezgu4MVA3spwSC+vZmiE3sIOeWpxAQUsAms+nSAF8LWz4wHCfCreAGILNcGTpwWE/k3Au3y/nmJh0YHHzoKcOaWskyNtdXpUK+rkfeEwgwvwbJBnhL62nrfuWHFvHj3tSQSQR+r3GjWA3bPqanAL2b0AjvT90ENnQiFqom5CMRwrInkQDw8l50izzWjqKxS9WqCkRYPNt3ZrUQkurV2EnvJkI4aXwghZ3PwtmnBmVkFY1BHVPbEHMqicSpEsLgOwQlNDaccofyv9q5r2XHciH6N30kx6pE5iaSYwxtzELNIieTXG9Cd8e56Z+yt8tqucrnqvuAKJVINoPscnEbDmWeLB3glurcWp/i+zjaqr8v1yAra1gNEsfTuG2EaNnAtr/r/s37yrARhCTkXcs32HZc7vJm9VUI1DRe5qAOlO++EFOKvTzouAjiuyBLnXFg5QKfaBR9G3/Oc+qvIHssNlipwsjCDyLuhA8bwRikLIUybmuHahI7isjCbddp3h1XGgVup7Vv8czxniK8ID2KKJApheWxTyB78S9XUpWksDbvg3ONVjlHuOsGDBn5dDR8p6h629MC+NsrLRXXJLBYFPF+NTyxaFz5UDJgjO+/Rs7i9t6+eX38Qw8VykYGYpCmB90lP9fSmGHo7NmWqfPv0651O13B0LZt9KrPWQr/v5H1IJ3Yuq0X4Xu60d3B4XBfqEmwrT0SG2JTlDRNjxnXbtk7CF0YNULjSiQ2+qAn9kX43Cc+2r2pYMOhNOhS8jt13s7dxV/q8DXOZ2DvBKZWFP9S+bGn7nqJVi10BLimlLD2oiD1mkWUmIu2Eqxk0TnYvbwgnCNJVAZjJhUdcWRTdNgBHerwVG5+ZlMIOiJ5oi+ARHiH0NfWbNYcv84lYfPG70xz8pEkxQDXehZ2L1zhznrLKQcDk66d+EjWLF+xDzHkfkDqBuK51y++PXC7Rd7HakRdE974cDk2B4T7oICYV9qbMyZdtAj9dJ34t5q1hBJauvKH2KgaX7mBgEZigSmlDlofhsZvDRMJMoVBMn4ElnIf3mE49TepF0EhxzldYaQvu0M9dx/d5MfZtuF5enbycGd9ktxYSkDTiK0fUnm2AsCpz8uLRdLf+1j/xyS8F/pV685QTlgE4zQ5Cp87Ma7icRLNHo49eJKWXMGplJEtnzjAhMaPPVPaSLLdYxgxsQak71r5eJRR6VMIMp1BeK/3spCitfeCxuQM7qWWPH29BhaWHOFpUzmGTZg+gj1NgnHQ8ajgHa7PfK7apwRvShuU9OjgReaz0By4VUkepvOf8eT6Z2+rS2g1Rb743GWKJ22P/IfOM2t2Cx0KEjXLYux5imBslqzFuR8Qqs09zrZkiZIcuD7sl2tXRJWJfs7jJ7KfaCB1Syif9NGTbs0x4ot9f48mp10B7TtDOBUBC5hJqjwCnmqA62s1c5AyK6JHRSkyrhTnMJAuDHfDCSHykNsIZYWhslWBb894RFe0grmQa8hJVvHDoC5SJPvWaIRfCOGRf1FqCRlJCxuca0YwuEX80fbCQAHmGEaMogWV9CvU4wUcT8cx4+c7Xr+eavY8JSd5czOILMdAb81yBG4WCsDFX6aOXTFPyNyLbvLAx25VvguvdClv1TYUH65B5xEXkeiszGs2H/QjmQL232lOwmXYXguhy7ha+qyLNucbd7iTk4ss0Jokpl9XZWqJfPwbMro6RxdJ8+bNH+5CjhM+7PmA2vt7JkwnuYDpdXOR6d3UEfUbak+1tHeF1HSXL84FyiUZxytDhTJZf993GSb2Vj6IRqVUZMhcBYNM8n5Rpv036PF9H5yct/loA1Dktc9BHQ/AVSYjKh7jAVUWEJsXPHw5pmwswjUDqt+qdHO8IesRwUGLPfRDqvC0PoWTEjmNyWm4Dj/3ifSH5ORwwHQRDymPcLXp42a4IsZuoG44aOrsdUligR3LDzb56cs8mMYI1oPL+JLAR+FHMdlMHAiyKYLFrG11M10MNKB3LCVbftROr9PdEgnnytCowy6e7AJa/XJDbDqh+s6aR5PF9lWpm71whJDb8DokJSFaLjFXvF/QqRE0xL76y9obUluOBUnCXtSZzhna8G+nRvVLpqpRI+OY0q1S33et+Z8bGo5dOiNXPCVT91uFbSl/pCJbqGm4BTdSp+pbimaIMQN1TGEvQHZZc9bCjhokwLcy7RMTkQgHorDd5KVmFccC4edryoXUF5qd5hzA50zTj+6SuRn5aGxsBf96HeiqQQ9YidgnMfznTMSDJgijx3CZYUZQWfpSFWrmhBYXA3TfkfGEaMW0lkV/SYp7cpOdsdQpLhMh61GVp5jk6iWvTyFnlAncXpxismlNB9ts14kkbvQ7hmxUqNo67DM1zdmRYkXupQXw6pmvXGINnQbWQ1cbotvO2IlParrupv/Z4ZYdLjnenxSp2FYiClFqJGQ343uWXC79hCfeazYpRlYIDfQFbvKpwiWqrzFubBognnH2sed2ogXkwmsY1XSlH5FdagBxhBQ/PAoDuRam9mWneYHuo2nhrn8l23kbtOhWMqHrvEO69pnaFJDP6UjjlPI9PNsiLceJgRQAmbUYeNWTenpe06I2DysmZfaSIDkJisaY5Vz1zk3/Nt5V1gJWDcxtZiX/VKqyOoQmGAJZiwNtg3qXq1ESWwdwEa0Zod//0a7W0Tq6Eg6auvh60VZhUY1aKQ2XdCXh4dTDKHfoywcayYEnQrdx3Ntl2BizfV9hOMI9xpMxHNhkA+6yA3e+nb5l0sGeM0hjOSKzImO8S0pqOIBJ4DaJ2tb5oRIvlo+/SujJhuItkWCWkwn2GY0zWwiCWaJFL2vZs3FJts+gv4TmtrqE+OpSIaOU1wB1a9brR5qwwFfdQcFTqy4fHcDyRK0Zo7xajsOhk6Is+vRnmT96VnkRppHeaqzirvC3sfOiQgLN59bazw4ZVUMr0/a+KlPhPFKGfipTY7w/N/ljVQf9dIiX1A5HyS5LEP5cg4H9h/pcPOv/xEfuuTaI/OOhMUv9BdfL3dxAUeVV8/+HjstZjNQ5JJ/zy378z3C99biNU0z4j2BbrenwzZ7Kt42/H9+uZ8EG/ETp/cFfAc9yWrPgHM+77bXfJUhXrP9Mbfz8OS9Ela/P67Xv86UYm/xtGBqZcjvDXjQh+GZhw35r8/u3Lv1rHt9afODiXPzg4P1kk/+rgwHD8t4sDP5/96vpFTPgr \ No newline at end of file diff --git "a/docs/database/redis/images/\347\274\223\345\255\230\350\257\273\345\206\231\347\255\226\347\225\245/cache-aside-write.png" "b/docs/database/redis/images/\347\274\223\345\255\230\350\257\273\345\206\231\347\255\226\347\225\245/cache-aside-write.png" new file mode 100644 index 0000000000000000000000000000000000000000..038f8dc2a9ed0fca84276b98a68d6f780b8606f3 Binary files /dev/null and "b/docs/database/redis/images/\347\274\223\345\255\230\350\257\273\345\206\231\347\255\226\347\225\245/cache-aside-write.png" differ diff --git "a/docs/database/redis/images/\347\274\223\345\255\230\350\257\273\345\206\231\347\255\226\347\225\245/read-through.drawio" "b/docs/database/redis/images/\347\274\223\345\255\230\350\257\273\345\206\231\347\255\226\347\225\245/read-through.drawio" new file mode 100644 index 0000000000000000000000000000000000000000..7f7bfd71641b9b8e6822b9368fdca5827fa92ddf --- /dev/null +++ "b/docs/database/redis/images/\347\274\223\345\255\230\350\257\273\345\206\231\347\255\226\347\225\245/read-through.drawio" @@ -0,0 +1 @@ +7LzXsuvIkiX4NWk281Bt0AAfobXWeGmDIrTW+PoG9sm8om7eriqbqp6xnj6CBAMI6R7Ll3s4+RtMdyc/x2OpDlne/gYB2fkbzPwGQeAHhp+3t+T6VfIBgF8FxVxlvz/01wK7uvPfC/94bKuyfPm7B9dhaNdq/PvCdOj7PF3/riye5+H4+8e+Q/v3vY5xkf9DgZ3G7T+W+lW2lr9KCQj/a7mQV0X5R88g9vl1p4v/ePj3mSxlnA3H3xTB7G8wPQ/D+uuqO+m8fRfvj3X5VY/7J3f/MrA579d/T4WzDRMIJQJbnjPYAxINz4F/AX9vZo/b7fcZ/wZh7dMgtYxx/w57vX5fC2za3rFS6dAO828w+dyci+T/Qp8mnp7p5/XvLv/v9xqmfha9X//lG3dVe/2q9rQVd+PPTRhGnvcun+fqyJ8ly+d/uPmXNv/hzri+A8zn6vsfqFTkw1xU8X+gxlp1jwpCQJ8f75yH7l2Yf3ftZV2GvvjnFX4f/9+u1fKzDd6VAvH/ho7nv7r7SyLv7X6Yu7j9y+02X9d8/pdHcmn1dPlnj6z5uf5L3FZF/+t2m3/Xv79Z9dmPRr13gb/p++fmOsf98n2a/KPxPv/LA8cwZ3/f9z9Uz/J0mOO1Gvo/qZ9Vy9jGv6tI1bfV39z7tkO8/m2dP5TxuSp+f//R2uSPAvC//caivxHPP+I3Fvvtw/1Goi9OxGmZ/8Zyv1H0bwT969PTCYv8RhG/kczvFwTzVn4+foj34kP/Rj4X+G8f6jcKeZsj2Le5t90/Sj7YbxTA/HUc878e2bMzkz8p+7XN/iiG/m7HQe+iPeVHWa25/azsW3w8QPuUlWvXPp/A5/LVit+R82e92jjJWypOm2Ietj6jf+3Xpz2Y+/nzl57+Fjz+AIJ8fjr9m6LfwYTPhy5f5+t55C/Y/juw/Y7sGPr75+OvOPmXZ8q/wUji97L4d2gu/tL0X9HrufgdwP4czAzGbWuBvwoWAn2apCccYf7lT7DslwqQ9I9c6d8++E/JI338dx34kFK8x/xrZf5EdG8t5hU/++gE8Db1R61fNV7dgH8U688F9zdCWtZ5aPI/ZPGjxI/kqrb9V0W/700mfSTzgCFMvRKpHoNE/n6jq7Ls7eZPteJH4Pm7SP8TRfij83+lNu/nv9EV6ufvf46uwDD839C/0xYE/0dtgYA/0RboP0FbMtZsP+1/j+a9S5j/nq81UdR/pi3/Worvso3/ZK5/oRxx8sfjwD9ZqX+6LBD891sIxv5kC0F/sigg8p+wKn9OCP7tVXmIzPheVt0Pd/qLgiqvthnDUv3CdyYZ1nXo/qd49P358ydKvg6vNsfL+IvTfavzVWrqp0vyj1Lgj5LnOovX+LEPvz5C3PhaXLryKN06AJkvBvL5o9luybrFc6W+L4xIk+HzTq++jOXPhbsCLWt6FhJsUEZ/7d8gCgIdYcctGzEnBdMiG4gt2koHcDSvqKsw2d04vmRFlw/0RLNKxbZ7u1BHF/aOqAHN5soooAFmOCyb+JkPaOwfPFjxhz2+2P/8y3+9LcRzQX3ufteJ6OcmBcJ78LzhO/G8Rujns29fdF8I9P70jBTZNk2btH7yiMXLznu9nZxYbE7WmFVKDmxja0heuaQt6U8DlKXSvMmgVKKU7QSwpi2KqrqyqEMttG2RSbK2E0vaT7GmZiTulA1pn2KUrOXAFrYjipSeHbj5U4xE8Uo1bEE7imjp6ZGYRWP6108xy1Y0wyiW7h4J2TQmD+FRXJJs8xQ7gqkDSESyi837eBhTIttcNOn0qQ6Ib3HO+7MZUSLZXBfr9CoPiBLLLdtbbFFiURwX4LQqf0gSS60b5A8mJT3FwAkwq86blMKW7QbxhU1JalGw6KNJ9FssvJPmTZuU1KVk0Ztaadr6t9eCBx7bTBWxnVTBSIzytujGzbr93uzmV8dx9Ht99odKcjGy2x6FLfgns+1MzLuZrjn92YLUvH0v52N+O8Jd5eTRSs7uukp951UlSKvY9XQ3Os83NfLc83ZQTwJixmLfDp4+wUjJgbj+PvUooqMt8T6dY8Rb8m3Zrc5nw3PK8795/ltKMyIdlrjnca6BfSqsseeB0hBKZfBgVnue/zyFTmK6zNMeXYc6OaKSSN+EfqpTQI053H6j0wMB1HIybY3O8G6IenMxtzSSsMsQBWbvvZbvHbYSqyW0pXZGYNIUdqQNbO9hYpp8xhbOnn7A8CPnbQ17fVSElPQO8LKI6BIE8Jt9t2mY7zEAXLbbfTTw6hDUiu3ge1EngutIiDRxgOnCP2jaX5GefJLqqkexOAEinKHpK+cdJqOrMeEdgefSSEwfnwq/sVK0F7HcuadJt8TBo0tnnxOvc7epaavGWlEi2e1brQQL2d/OeLpU390nP1MOPqJMqUkdAo/qCIhRvzAi5v2d88/VvJmodLNmM9GBYAaEMUN00DJfyqY+wIxZTbPzJ+RIYgkobrsLBsjrfEK8C4GKxDhZi9VlokQslfeKrK2ro6T5nCQ+SVhjEHLjyCtitQ0KJ6monepzX1lvNIiDmunb7Gkj1X4BwzVNaAhbbcooREz4mrzyZ8XT9/Btq1cfXnC59+qyPjNm4jYhlcscE3N0cA+qQ9YNTwLaFBu3Fx7oOd+Gtfu3ygCSPV5yq7hNW3OBzkTiLkH4SEd7X2zwLbdYzwRo1enurTUsD/BVuYmTtI/Tdi5Y7lFoh6/qDEnZ97Zqo2psx4snrHTCA8Gm7OmcXdiXZ5+HfL8ZoquznktLVEoMvhPEQ3YNJ9VXU1zsCKYNe7bfA7F9sF5zCOSocYGy8gitjBibBrkyXvK+E/Rg1/G1zknj8TqVjevuwHl0+bV+dAbHQ1LZVNAAJs8qWF1S+2F6gixvPbUvKYfh2GekeXpuwoqW1quvKCttY+kenv0MGkZvm1ZWLu18fZT5m3Fyfnr3wzrDlHjHHu4CZLbolIVNhjqAj7C8ATi2cyQTBiqeTFplnAa85r4KZn7EWyzNdaB1WxKIDUsXn2cNR2nS4mIe0GgfK9OYIVxrIghKE6SYzySMuL5n1HjsPUdTWRAP0QNu7AULNi69+7nprdu2MoQLgvfxLm3TuB64WNxEnAGhll9feGKdUqOithCtEoph+kvXUx1b6uk6yS8DJDRLIWKR8Fy2obXzBhpTVyc4Iym0hXrjP+P3V6ne2QGL39E0oepQaKU2fQZHkKqoum/TX1FuDNRia6UVgsoZsxLhhCTXfH7+rLE1Z/fJt9DTrkQPAVHP3tfhMxfMTV0zWsBeTtTPtr7ArUlWClRjpLTsbWOkbNv6EEchCWKF67xDZaGVHidO2V8tFwr/s9bAwy5IK7padommvR3MRxW+5nkqc6O7iiSw17fqBVF7MMxdUjx5POXHQCBZMJdlzbZAKgEBwdIhUDgHgMDvUhImfCWrF9Mm6UA8RdbQ5OEmUuIUhQ0fF7vuo0M2r5OF9tSXxH3sv8icHOwqbcnYjk7XF748DaWIvgzvxiyMmphhYRDfDy/mnvdjxC6MG+TjNTSUWmAiqITms9O54cVkTK5q4+FTC8TDdMvHcPudwBl7uOj2oMnZEqpTEFfvuUwZEVHu1/7OKOV3rxonyykwLO2ScbbQwFr7EyESEV8sr0GrEsbSeVpFNwumEqijFHxU6tMCjZHt1j5vnWHJ7HlbBvPMpz2pPE/CDrWU2pBRY9p0+6OyUyRG/ZT6vTcN9QRBXTYD1sj629SDpOEutoMRVumc5S1ygdGWV+yybrhHpwV27Yc1TbMRJcYDY6HCxxJNoXB6tI+qgqB0aMs2WjuXKZrTIG+vPSv3wdSgjG5hi0m+QdVIu6goONdA0LY2IYdFAuHTjJ0F8Jm8b5wIzcDiWFRq9hieiCNOmntAEyj1DKlDLl+jFrQTJtlc8DLxI7HQKaVCtThRxF4C2rpwHgE391rezxgqFd4iuUuG8PtisPzsPHJyhA7R7QomkEPmEeXhC98SaENqr6KNAhl9yaLU1Iazkac8xu5d+bw6Za/1D77xRblTYisTVY9vjerfPXm8dHBZH10CRhmdV9SxVUlht+hZ5FZjtTiDPycCCp8Amd625ssIMneJyGxMl1qCSvI+qj4aj0iPu5FX9hPd7Ij28wOx2YK8urTE5Uvo8lCx22Yi1tBkgBZ52aFQXuao9GA5L5wCrbShtA8eqMHjD0OUk8mOZIARHiLp8/HFk5agtzrZXn4jRT2zUobVPBDBba5Hl3iq00z10cbZLS69bXefuFJerNuGMJ9tM19D2/WBGeWcrsD0BLZg2yTwY0KSSsYDrDXHBLPzGBLJeqNKe51sdhkuhh/ePVTypjH3NskampceC0Rik6XoL1WX7JLAoRCPKV3o3qXEJbB57WGjKNoo3yiat9o2V1eGKMXEdoUvv5gKEbEfmh/vOj9OpAeCXFFaXnbTbshx1sG2DrxaaX/EPjORaX6u+aRN5e1jmqVS0PtDNstr+Aw77sn4YaLmKYGw2HFQcL2uGLqwaW4yiLQBc2VNiKbFlxa9ozrjDKxIEf9IaAgEOtiUUfrpKMbEPixhXgGYLqaXsDhKSS9cqKtdnGtfxuYHOvf1dsWj29BYyM7v2mL6yzTCVx7IyZ1HZYaIThxhm4hcm/LQKIyD+e4GEG4xi8ea+cFmOPGtZHrMGEeJ0mISLSVArj+3iBUgLxmluBkbjsZuzBPNsathDbj3B+1r6p+BIrnqu5GQpQrBhETuBbG+HTHDaxhkxj7Iog/KGTI0KgyhJMN0x3FAo/lFYKaHafQayoI/VCDk3cYMKLtia/i++OssJwDw7t2rm8tk7AqEuRcbrVLCH+YoON3gmmkJVMoqlDpzXh+jZmlXSld+abbBxZGvGKjzMKaFhddSyTau+ZVJ8aUrjrzFrj5wmfHKEXJEKv/y0amItyE+zxCPGXUzU2NZ3Vzs0NLywaMI24rFSdFelr+7n6YzG1SgoUN+GFb9OnFp5UDvtqgex8ssBXPrH2jgEfVhtA8tfX03PS6VJlftqret3QdF9Y6gb4PhMLtZ9+sRiCmbUywSrUx7OSJe9q/+igc8WKy9ts77HNWUSKDKIj6rZQs7Riqp1QjYaqGog0VkmP1dkdtPHPBx1rq8fzUv/+6eWPEUh23iO+7X9XjAh3qWVa8U+PrMUrkTj5F6pjtR5rmCJSXJpPCKHoIeaX5sNvIkLOybialhn/UZgK3aNiceNxR6DVswx2jBdk7Uuzaq4DO0lheDoMLKiFrnfqKxCCMdrsYac48+0kAETqM+bCoSxKUP9Lq+2771z4axTAt2600NtFKkV+qSb6rOWcvdlRSY9CJsVwWehjHHR//x5cLgXspTu8eqHSfDS+zHnlIZtM99bo8MbvdTtWaGXS9q6QDA609zKd59vqr/8WmRwnHbdnLz6OQ7tw5SBamV/b5N+C/asW0jHeukV7OaP76UPuiZh+AY4dmA6K4v/N/wmUClRHzs3C+bbwyzs61b4ccbFKK4bHrATjo3BZkxzKHdAikqb7ytOpD2pJdsncrN5WzrtNLi1dB9upPJ3Pt9GlHq3oukPms7rXOBVj43y7mToWbDQtba2a5ftKcG9N2d1z0a1ucrgR8/0I1XlJ1Mf+njj0An9aUPFtIyx6t8Q/uwC1OKuMfzCMvevY0tym1Ri6M5y/UFl3pd853TeDdmCnshLb7+pFFkhNfx9ynHowd09IdJb4FezXNTbGbV1PMY/GKkEdy/hOF72I2uT7+ea+4Hyv3H5X10mILLiGalzPTHj/9gq+TxxgZmUrGbqHpyfQLmnmV00uWLJa17uGF/C++rho6Fo3ixOSLJFl7LUItJS7xz05AFtE+rdKyUNrWneVTPkZxHX1n8vE5rSGmdAXhSkAoo/1IJer5F5PG8aDZS48c59EyggbKEYNPA/Uzd47ZSmlpxcJs5UNw3uPiA91L1N5UVbftQJkucb7X+JkszNWBU5jA1G4fEDRISb8e5aCo2xTb2oq7ZVEYA/ZhlHUOXdzQA5Jc26eZ72ogARkPviJoxgD64lAirYW0g++N39dztKKyJkpA913rfPFYdLRWFWfGBMhrA/n6q8o0NsWlMRSUC+MV8ykABZNYWdrCJ5xhpozNtXxI4t99IFr3xWN4xskTQxk9vAGzYZaw6qP54l34lOLgx8+Agmutjg+NraYqc8zb7cZHaK8p71vERD9bw0xqJ5dUdYXVqG/U3adR7CSUK6ySL13TeCW7QWSqU7AnZ5wMiEjd/SyXcbT8Qrg9tUXVFkWUpGVx5pp4fei3umiWnqAweGETYh4hgwevBvoBTKjO4YA3444lbNMb+6IS6zM6z2Ripig0GRimmo0kFdR1cYDJMIRUx1xrCo1kSkXT7BmwxSaGVfHeZ2Vez7dPSL4uzJMzhF/XjNCpNqWEfT+06hkl6i87l9WXj0t1syE3Bw2xGeDvTehgHL127NUWYSygT9aO82b6QNHCdZ71ubeahLtVH5ZVK51Gwxo1+XywAY14pn4KQGJfh+vfTxvcz7xfgxcQRDV7Guy3NsrNBuoTaKZP7ZS5BsW2vtIySMyQxdnPYwnoNTPfMFZFYOtoHV8zLW1okKAfO033aX3v1s0ZBhvVI11s79EHXx0hA+9gfZXvp0WMoHhekzbpTFEwgc2VDJUZ8GHC9X5bH4feZ4mrtezxldHzNAqRFjvuO9d6q9qWn6ouEGAJOiZtLVb5GPLBXr03CVEMxWPN82CTKlCet11zGnCHjXT42+/tKSofU2X2dBSWSFsFVjEP3IDIdhOiCGkFPWOTgRGyHz2x0uKkXp5KF0QAl4LQkKjlkN+KIPDoYrRfcJAmKdpQzZGS+aQ9XegMnAE8kVZ6k4WlT/ex2n+NOqpE1sqseqIdfTfCYGKyNcrI96Ux9eT4L5GhV4ZrQF7BfkPSGBfV+DwNt8FGB1hMXDFJxXT9xB48koced1RuW7yRy0hu1GNZ5rS4nu+tpe7Cx2NUixm/JF4EB1/bbLVTGkC/X2uRHewlcM3tRTfiDuWXXEYuKdtxnKb1MfV5J3QHgUFO/IRtPGElTHFz+0s9wf5FDq6uglvFltV77z7HslvbpqNJ9J1K9fgKljtaJpvISSXKooJ9oac/yuICoxgrmCc67tiJW+43vFCv4T7RObZOTK0cvEh+2ubaWa9/ewaAW8KWMXSggcOPaDyy4qUUjDzsJvjpEiskCoQ+7LBbstYlbn0AcaVXCNcm+WhDsKGnHEE/d+rS0FDjrD0G5n7l2hzZ1kxuikfYdfMT9IU5JaqjbO5NmZ75ps7tSDycsT2ivYVL5LIwbEC+F7hgxK2esh+F4EXW9NfbTbC4lUJxnHK2Qqx0sMPbdNHnLK5THiiclMd1xb0mw8625Fv3JQeEHkVs2i2BjQGSt1/dAM4fH2BOdbeuuI6X2AoO1/QXCcWZdExc2UdJk1VrWW5KE7weFrarVvuphimlKUk3smaN2WuyeCZ1mNo8N4XsxzDWwTN+4C+MQtn3Qx2PHXJBHBJnj36BsDvMKVr4yD7IXWMYWeIP4S/3MjLvpn+AqOdnCgNbC57EnsgulA9nn3oelemhEM2oHk9yarJ4Z3bhU2RBs9HdLXgNop/MrknqyIyl35+7rMcSXdMTImEhkWNDdiOE3lmO7nzSbWgJDJ9MiF6R08+RaJ/oWNlb1HTK5oDo2hvEYouTEjam+iwXYRSvyNr9kWQTTvigKyKwU5cq1lEfwGl13C3wo7lxGP0wEQLStd/F3NNi92B7lj1qjPg7FaNG8xlTpIies2JAEKzRSzkupcdFYJo+gY52xf2qNHD0eh/Ex03TtXSCXnRkzXrnD1OSoACIEqXJXFluM+BwpQa1O9xy6DdhnG5A3NsV1sUSDx+3gk/hlJlP88rsXblZENleGjZe56abJGA8TIrpH/hTPm3OGbpqpAjo28Yd0pyfP8QoLmFSjaNSKHrc9GzwSkXI7MORgma7kL9vXIlky+jBuZzSu5YbNUC0iQMaxi2BgyeaVIEY71VgDO3ggwNb5BUiHo8v3u6cTdQiaDyKSJRM8bvzGFZlWHfxXiAj7IelcMY4kRGuUVrwCfjzg+HlMYtdWYo7ycBqPlRsv31A6p02JjJSsuNwAnSOHsQpacLFRLENHthrB0wEWeo2oqVG7W6ZSq+v2wU5SqSpktk/z5KyPA0Ge9yk5NW1GUazaSeZkIsX3VkkHMcNzIB68zoomSitOmSlqq3KPpf1EZtiihF+g32VApBTgtgF83WPQG6Tl7DdOiSWEXs6ESFcIOCnE+vIDOnTn1NhkfH3Fz26ZapQtcn85b1QtAOJADzzQIxFabXedTpc5Q3Lk3TLdVBCSKKZUeH/o7uEc384cHL4VCmVXYqdILDPBi5/4CTZlaKN2F8e6ue+qflBdAZfYj/l8d8jzCJKguWcr07SmroD2L6kFH5Clku/zoiffAMbEUATZhtXT/TydyLRtUXIpZw9mqyKlZcPRN6ywzCJKPuT6PJ4dBZOPH5Wln6/fElHx8MMopJxXeINli/LyejT4T6VBlFh2ItF7AhGQfFykjEC/vgeEBe2JEcLZb6Xi6VHf8v2nilpIUqMO5PiCBvj26X+/xPhUYt2K9sgQAWMieU/iti3d5/itYlJyoy70+F3fczLBN4LPU8F9z9o80sVB7O0vUbZ3++6zfOk/FVJ5/GrH05sQGAE4fvmQbWzeJ92XCWBvb7OwvwT2qfKeksmFnmJrrh0GwYBhznwq75cjz6XvqSppu55uySgdiuJ7qvtnCQP/0wP4fzuL4Pr7VIB/83T8PyNn4E9Px7E/yTDBfxJC4L8mDP1/Mxfkz7I97N8H+Se5hP8PJfZHggPyR9rH38gMB/8XZnlA/+9neaDQv8ry+LNEKeTP9Bj7r9Ljf8eq/G+b5eEAzV+zPDLsgCyr5xiwOijPYYOWPj9HOFHFDs01a28XBy2qK5uv1Tiqc8LDYatCzRps/fqQmEzvoVbR5ui7nLC8/K9TlVcme4b/BKWiFo7g7+PHnxCOg879+In3GPX3dhTdyR7kurIhmdXhYauHEloqyxGZVVGKRR5mcKI8yTqnlpNsWjIHo4lCh2zrQ0ocieZ0bWZu1iAptWfu2PWf6UtLSQk5WqK0VBR5UqEgK5oqy/pIVxjqQVDsZRoamsU0KXYXK6a4L3SiT9OoLnRusVIHaUWVrH5u5nj6IAmYOyfRrEKRXM9VzKMSIaVmyBP7AljS0hoxxCHVUJ8+hCsV9LG0qaKobhaw0E4oxId6oZsyu+bbcenU8UGczEE60kFAb1yKpBPRtOAtzN8+3sllFs0yFMVt0sDcqkFaasPceeAXBf1MjhZ0sEQrrig2p0RbUTHTx06GVW2kf0zugjxo7O14Hdv75eniG5ImfjhDCcwf5T3p3hoVz87ASOHvGzKUPvsMGa/wzoGWmiIOagF+g/7OymaSB6J3DzoTAXIdJUvU4yOAIfAGUnkN5xe+ucz5C302zExscGiPyO3ysUvhZ6yfy83egEaL2OkZr7UrdjTTU7obN89UMScszYhGIZxg3ARpMHuz9yoZKVj9ZtpPpDACCg2VgQhJXfui2B7amAjta7JtipvsbGcDnZRH0bYJTVqgYDtYFajZ7Tb/dgA712GUoCGdZ+7UZeg0ZmTDQTRmk7zs3G8kM+fiIBgchB2EYxYM4PoJi3ef3l4ppbzFVMmOnSti5VkuFhEcr4t9yIGXGwGKNEqKXOlyp48htagJSWLaIJJ12TNed0EJ1NIm34g/ZyOESn6Mad4Oj7fhipcQzFqxwkZnzGQkDdyAFguTdzyRnSELFoOOkEsuHUiK/cuTehdxJN/RHd/5IwDF0n4DcEJQJDZtpMT8jhI4g8ln/9dpNqoAKBqw/KUs4ighQEZpOoASh0CoksgODc6ObG6XTYE9zsh34waIPKLPj6haEf5qIkUW5v3TFhXrYqFkZO1IGelJESu+UNDkClqGzwPYw3FBxTajt/I2NXyJmzcXyoRUnzNDtXOVSCwkILWkiqfIqs0xfRSNow9mfg/MLE0iBQM7YZpu6NNbJCyf1IebBWPm5JLWjg1pmiUiUp8OSL+coC5OXd9JVrnzGsQg8yhCbCvWqN8X8c3Nr4Mavt7wiPP5uAJOjFis20Ypi8R36Qwv3l34fOTydJe32CcaMIuACQLvYImWtQ7XtCA4UPJ6ZzhiyXmTZGQ8GulerLrzEe5iW8K+flpi42MtsvcanVM1KW0Sq2MsPQCSlvQr/YEjabY8H0ORx0p6z8KcaifNy6I7e/owHbGm3ba5spsJN3244iSTd8az9rgN+NiXdvW5aspHE2zeTtoJIdaPvM1TA5/+puEbBhb1JTWdcVG4tpmLnZrDCLfQ4bQZqBUKTsWiyXGz3OnC/vqo3Xe0h9RtPgoldNvI6jwjR86ngux6ZADIVcAtmlbWJzmpNt7Q5uCTecshjHcN235OfsWKi2cS7HGARiNm8tY45rVeL0YcLF7SlSBUiADJ7G1pumbMwsmF4jHBZmCmxbWo8KnTzNCBBEUhX3OQ+QeMHe0l2eQSfm2y4cN2btprDgKqV44wfcbgM4VE5LRdtHw9B9oqAGV20Wg6gIdEGeWd/5gbtQT7mncaLvCjmlZOxBSYUb7MT+6rnyAzTIh0ytbm908vq11ukL0obgvMsgTlKlAra/5rpmYbGa176tufU4Bvd5EG/cbvE7f4XlnTLeJsadTBEee4bR5vaO/eWB0aDWTjjqh0ir5DV+2+OZAgrp6UUvuuYDQmRMupuWvzM2etfp6rEXWvbUK0Gk5lUowmOeKDOiz/k7hEETWrLv5VA5D5AdoqCDo5cL92BqqyzhM3rdN4cn2h8s2M+KwAsLjXjT/zQx2NIXFnK9xUmCCg76FTpL5CPVPiyX++vUuT8pYwG7kqnzfrwzT7TxXOmdawDllpGfbtxCiCCIYMTuHmILmzyTEWPRxioTVr9qWbtb0wKVh+HUj7FDSxGptC9ituF+1jgKWqO5D3GEA8QUluu2Iy31tfaevOzveyRFHF/fEMw1tONJa9itgI7SN5Tz/NcwAb12F1shag96B382MapcXgKoWqLnXijZWtpEgugfJ0bKOZ2pCyLmZ2BqXObJoT6cekXDSFlL0ZSZdQWdBxmCMiUSFlL5IYjgFHhawW85NbLfIGQLFINjom7V78UXCxdbv3FKkBMTsSTZoEQdrxei8EbdddlIDQvMjwhL7g7a8meRs2VIQfl9zjuo8d57RDKbFjBIIcwz2L5QCXqRmEei1QonShZ7LZBfLOSF15Y4qy618NsLAD8TWyGXpV7z3EKnaMV1/8FyimBQBeb1WXWGfVCjkhNt4jOAetvqh43owh8nK1x5ZOizRNLW/4VEaAzZFFeML39M0nXWdtAExrKC9+gHfmI/IIcprZfJjYJ8/FfAxq0rt9m5ZUUvJ59bNA1/4q+w7J4p0ssAtjyI1zEgbu5vieAsyoA8nakYWGASaAhLwJueBPwFbEjRfFlzewocvHjJvoFxPs15//BlM1sjucYInUy1UwvpO9chTprM+bUOi+/NAuKTJ9Kc3lgwYsiOJRvAQFO77cHn7hRP1GZxMUSSTlytCu+Hx0RsoGm2lLTkIbJ6czbF/SC4FhomnrTei4N8hnn4eTUAYtsJUJla5YV3mfaDVC4waIRGw17w5HsfvpVBV92hZeiGAbf91SK/jM9oNWOuKIwz+3fjZuZ4tSYp9qoy1vIBOhaK72bsjZKmPBwppQ/VdBrQf4xs8HZSHz2QMO/ZU/gxFngPpmF3iOWdjNWZfu9SBw3+7q4eK6w9Udme6oEfqeec7o87J+KHYhKxlcbyFaQ6l7z9yTZ/P6OGZpZQu0n76VhsFC2V71K4dTbg3PzFUylKrvHj5UjHHjAX2lA4VUXBY7BTLhh40cPYSiPdTRlwBJd+dQvtyPmLDVQxitRdPokm9HMl8ValaOdy88q5kI1H3K6jdtrNYOTx3+pGxdBRqPglsc5ErC2W9tVZFuGN7feHBcESnwwFcqWtJptFuv8T24DGmThMNhEGLFIn0ro28KDQP1w91b+NgWnYlFoNr4WfqpSM0K55HX2e80Fm7Njv3xtcSEWYIbaqzwpYRhiT7smCrCr1kqjfJGtfKjdUcsuOxs5AAgYJZ++X7ZwBG727INnch5c6Jq+h78GuZhnLWJ3TbBEbpv+OE1i3EsEfWhekNTgWJLJzbljklGbCLxX9OptIBPsjLVc0mRaS770pzcr5sRuRHKOwYfWfZyzA9AV/Uzo4/CHKkHP1J+pxJJxiggoJTqwuShPhO275WwomlPfChS4YVZIOKRps/e6zBN95EU7gpGIhWWLRM7EmNXQjIV52XJEsN7BUJdFAMuNiUpjkbFFY+7HdFUvYeXB/+GUDukOWf6jYyNLmR+59Kjj0AgYpG6B6zkGGJoa43ALjFnPDoNakTaBSqTtK7oDht3vFX4ySNqeLDjVuVrbbgBqdA3OOWb0lv/4exXOjz4K7HZog0EU3HmG2k0PTu4vH42zs+LFgYr39LiBB5P6Q0RbwbAYyJb9EwaT/He31p5WJk52xvT6bTGYmaWwXhoVm4kxBLU5mmD0jCf6QgiNZ7NPVoHG7QRv/HdaEkv6LG37EDNvlNszGAgD6j7tky9WcXxtn6nOH9XM1MrteTUxqIJ8raWtkGUhcUnd91Es0xmBhgN1uw03V/EyyD5UvUdhYOHMKjzeqjLixTPZyZMY41SahMoSgYtAkYc63Glrh7VHTYBKTE0Kz6O7Lfc2JwFDJ4dRwhUCyWN54dOcN0X5nuFYhvyW5VU2D62XRwxn8ukWPtE16UdbpMC9ZhGExTTEk/lv/AIjcV0YKQccgDy0wshTqL3ziJ0wK7LwdopjWksjzmJmov+WMI2XToEHgsHByGNmFSEhfUM2hW7RcmPc2dH1PbunGRqZB9UCFdKGd9qzYVoNhmpKSwSya4YLZmd9tw8BXCbd/5MNMIs1DRZPPCWwVHcstffG1iUKAMm3bZc3lsq9TJZ+jq68DVQsyPrUIzkvAfLzv/0UUsmpU4p1ONmHJCB9BPgFFK7tq8rClcB4pFHkI/TDb4s5KC9N57xEJ5oXxsJzxH5PIW4th6kIGEKi1GeW6TTFiF/LYHma+91jz6e+MZKXE18NFlLnZJt8lhCHvoXfoVNmr4eud9ljiwGwpWsI26UZdAoOBNmytAdc6PUYNeuI1H+2RjE8eZuc5rCbROvjX6QigcJsHE7UZCLwYisxdsiH4g01KTuaGR7MkMcguOMfoFOPfSOpqOD49WNPqscnOAK9sUFQJa5WqoTrP0qjUDrcfLZAH+di4VsBXseY9PA4lBUyRdpqvlo9Ul4FvPB4epC9Zp6WeZOImElipL6mMqqVM0TOmjfv2sRpgqRzV/K5D178s1aoVDNbSyFu2yXM1lsrjynu6mSVcf0YOXQa0YUg0sSaMks84WDr1iUpKH5Q7vXgzoeVbcWIc/n9xsk/EN18k9wMTxsT3T4Hgww2etcZr5+bKIL7+dCSsoirSVYvdQ1uqkCvmOs/QKsMzIfv4CNaxzWiMpIaXCo90s9DSvLZi0gXjLN5f4KXHuGmec1MvcIWDBIwjFokZDKG4nneKk9Sv8OflKTDoF2BB6q8YTi+0asFAJZHs+uqqTMRJUOhJFO7TDerSmF5ULHXLtidorS8T6mTsjDRMo3yrGhRqQ1SakXRTr2Bg6x4g1SUynB2vI9gS+NGGhqstNp8tkS6lzWz+HVnZF9K4ctrXnGwCRTXdbutcfMaefXa01/QybFtevNQZUq9wdSTAnS9Wh9/X7PL+dxaqRURdEhSS3PZa7aAItmrllSvurcJ8UQ7YdyU/BNWINsTvGgzqon1PE66wRRWyPZHVhytHqqv+7IcpS0ujabn/G6jj/sj4vW6y5ZK+cWs9409O52m30sho0y4SlAdEodyfapYxOhtapFJiwudfDhqE/HmuSWizzMvBrAydl8iwfytFkL8o4mX62qWq7RikbAzcr3xo/NQmQESlHutqdFk/yb6KEkavl49DHU0pacoPUbarJYIS8hmE0M1wwfjpQpso7T/Rgi4ntqIou+mYyZqQ4PKXxcYpVYaBONG/TNQZ6F9HtuYf+wLlIqcFQDYMQhIgp4/MtvZFIRlNi+5xu8DxnPUKqv2KAF+CByQWW7jXqVnlJ3cBngxVerRU1QpZog+lXCzVZ4++h5s6RLr64zBUtNmpjFQMSsIrMTgR3DWlBTkJgKu86/rupEVDBepd1Kiq5jdmGfGeLU9C5lxeu2buJ5sekJyiRwDIbBpUjd7U0XBjgwb9hitjRI17MKSqtLSCcsSRzgVLqhEiaajHc8pMkVfHha34yh5yz3y7vM19y9u9LBcGT98PHPTp01v499/4nKkDXdPXNjC/vxdAqmzu09OSzu9aC+oC7OtN3fGVUK3pufR/m6+ZPMck1NYC09oVgkq/rG5gT6ouU8QgBzbFkK3rw7eq4EKuV+uE7RP4bTaQ9MnNnZ0i39hhcwxc6ceMk6/r2J+jwOGXUjsbxhg+2NabX3YPUhU6ITm1e0XEYjnUaCLZlbu6iFJU9en1GZM1iZH0+npJkPcRAsxJW5we/irMNBKCFJAdv9DECqNpU2xUQoLw5IUJ8zVNlF/34pw1mGcTwOvKcbryhopj4NQ3FNkYofv8NqbmiUaeKR30MP2EY4qHArfxyq4KqO1Dtm6fMNXFbEa564MqyPf2AYWtnQfuMInKzujid3Q1BfExe5d6HDb6ZCF3C5AH7MyrQK74OR4K1KZx6Xm1kXev977gqIg9joDe2zQ2yLsetnz1nnewwLp9qFKrM4CGyeQhMwvyO0TcSMo6boLkr6YHNh32rJxMXi1+WWPrpyR1JNF3ZZY+1sNbO2wmdShdKZnrluXp+5Zsjoqy4qGF+gMWgsQmL2RxR5V7GOgGl6gb7HMvenCTQc71EbTBIQ8WtHi2H6dyq9/mby7DsGwl0Kzl8CvSFbHLGsRGPVZPZ2MBObQnpxAI7PjiE/21AI+7cWi3IbJHlkbYte+rS4ulJRnW/R3Q1IZChZy3qvvS5f5VRfIzVRsWx2DPhQQlE/OFb6wKgCU6SzD5W803UjFltcVIwTBZaQ6e2qpaztJn2z+P3eJjiWwZhn951fX2vmZ2V6aWJGDm8M9JIsnUOfC25Fp2cybxhSIulwtoFmZkW/V1ubStNSl0PXJuUpMIuI4gRHrmyXUBfWT5XgzTAywDEiGxm/fTrNK1cimof/vbsNjimhq1ZiWUiHMy2wY5UQKCYAz9yPokk54NX92S9uS7yn1ZU96gbNWjxqZbNNJ8qU0RbBKksn2oxwA8sRiUJ4IcbOiaVF4NpKrjwR3puEnoFYVMe4HHu8lJf1ibpKNHcWFyhbZ8TbJKdchs6ZNcj3a0YRTk0i2XbYqXMErkMu5Bwu29sS+2ZXWbzitiJP05LIeOq17R3NyjMaoQUR+9d51tA29xsD3G6qE4ItgTf+xTov31ieg2ZwxJEWabvjWTovCvQyfc9Y0FxT6kmUycdn4bw2xbjDUhulRYBNH97zFrfwfO8egvfsYQtqG8EquiD/Txv/rI032qNKxElyGTONP+kDJCVZLsrOjVQUxU8CwX8ghwD6J+e2/6Ecgj89e/0v+4Y98ic5BNhvH/Q3Cvj5ZRHmN5J9kwko8s0q+N83meDfL7o/kgk+/yC6P/t5kf+yVII/Edz/6lSCf0H/HakE4J+qM/pfpM7w/49TCSz6b34wIkeOr2cFwo32a1JV3RcgXTc4CmkSBx/G4bv4pPyHFV3Hmr4ycz3OBV3thRhTtjZUVFysAu0VQGjZs09dpFWpAjwAwUNJiJu4FtZrjJkEAMDoNNLGtfYx2/BjQyEoh/M8O1HYeAlZs0Mzip74vX9TB/p2GYzcB2IanEjS9vU0QIayKfItZ5IFRIEmQpIySVELcxWkqZDCwL5ZrFRAslecJjszVc+8R1vWrKhGOJJ9f4gAzhmPNV3SZtO4dpRbNimS2Bp+RpCBZEkM6Cq3cwmKlCRDg0vwTaIEZop/Q+b7Z0DqYdL6CPLTk/hw7Ic5Xg+6WizY/bAbWr6/IkbVA/Z+YaIbpzCPvXoKppAxqdkEN914TyDRqL5xDNN79csM1p6S1ei86xS3oBw2dhBFkKo24yGSkpwdUVKD+Qw5RUUidVio7xfPOJH9aqW4Di6l8t3h04f4fr+RC6TIIkXGXdiAVrmrXhPMrFhkjeG268cr6yMgZYbUaEvXScOCtEUfN9kZTUiVV9/TAAFIHo/8IW4v88ez5mM4wK3r4Fa6PknZZrK1LZn3oVTV56hOPiOeA2tZq9LRa3Lm5EAiyUSYYQnc/M3wP0FJ0DfqpLjoUCAP3sDaMnlLfYqmdaiqWJ12OeT09XYp7M8zI87QPNVBIo4kCz61LzWHwXzaGJGhhFpxoU8ZxN27voS0fPmzivtxeg9g/JzHZg+RC8lx9104iVTjLeB50aM9ctsyCC30WVL7ZdEsqAwKzpU62WqUJece7t6MyimHJ2Aw6PVqKRDfc45BcXskQroFhaTqYTB+FmHHyMqR7z3P1XksNpUjBYnbASvDkW6ln3MRfnRPHEAzYKghaE+djLSyQ4ectav2rn1On4KbCDUaGeSFPHk5uc8dCFyKLcEOWTWAfUgfUBxU08VgSmD0nqwkZkAFK75BxPCNpVPbwI+J/ibTXqG+gLlGBdplZwJj0o3gJKtfm979YLY1AGRJVvGmFzOEyp3QzW431k1lw6AEKdfPYQ4TFkZxY0FHqJ1WG99Jcq5sZULbpQjBcKKEjwNtRnS+XjibTPmvjUSL2K9wTJ8sQqkOey291EXdd2sT67nvxAkU+5qGaDx+cBIFgx054zEaoiTOul78TAbwVlLVy5lT5FVwLIw6Cv4bAnQII+9x6hFr4qXWPJ7t7/kUZpxdMmII4al5OZ9o4vjbR00+NrYVQJTDLHvE9M546/sF3/N6A1YhCnxXZTB9fX6GXMwwWCjqhWChwXuFTJtv0Bk/vIJt2feXH/TZ8wqeMdGTCOlrnGCZPrmQKgA9/fDkoiTqVTzqRtK04I8NMZwyvafoaeJPe2chVVQPUix3FauDtS8mLzRnf8xBiai3dZU8YtJI6as0aYg5l5AE3q8KwD2GufpMcK/ngrPMhAZFBI8DqM684/jMUJjheEX3xVfLgzyNMIHnm6GwuhvdefHq90nbXmgkBHmUyhdV8hLWrl9EZR04iiJexGOAZo6IIuSEChnq8HxuLciiVLqgs8HDK+c6c11q/nqYLXGfyw3Y3+8Lz33ALaU680Q6Cs6MA3yw9UACFVlZVNEexSA3KPrSLMQq59PvKRCjO7QSKVVhx4xQ1CUdU0noNyp5kTJ9ldziTAI6e1csVbMHznpwR7RlbFgOmiUXWeGoIjxvAd0bZgyuiepMAS+AffQJMS1IbtXi3ZGUhoJ80aOawhwKuPv8ynNpURYIG5qKLBuRQ7xeUbt0O5+030wAzgSeTi9tPB87whUToYt4rV/wwnSlTdvM5/s6pnurjbnG9Yh5cAn1KBh4eVLYY6Wblw5tU48BSi3AS5XIHHtZojTSASBtT9jhTVFm52Myr0dG4aefitt1ZTkmwX6qMG3Fp0NpOsAC8pm7EBPg1Go7tAGvsVvD70AfKIosTyHq8DKTOAU1RXmhb+FEOdb93vkAwzhim7Ltok2LlWf06xkxpTUie8FMDtPvm1aAeqQvKqPYfGWOdIo3nCQs3/OCFQzvVUZkA7d4CZPz2k8nJ0xiWj3SpOzp3TThrjcyKdFddtQo5+lk52ScG9h6yyltRVpkOhR8C4dDKn3fw+/teCwV2s6jS9nMFpfVnf18J90E+zF7ULE7MfAWDqYK+nwBBJPrjL6SxdlXULEn+RYjUPrrHm9TaUZRFPoOLckW6D1kcNjTQchT7glaQ90HoVtQ6xnkS+eRJT44CK+iIV3DQuZRiwRWxmrtylKV7Jkq/24scvxyaXSDRciSowF+rCNQZINax8zm3jNf4XDuziUrErVETdFPG1GOiiaOmDlsQhnJlaSHQgChcBo0Za7fMJ7XUAgpuxxb8tVjNvLFn4OJBTco0VrHbQZypM2SjaOcSm9muIn0FQ2/2wDCFJK5yKrkTQTJ+NuiXP0UI7Y8kij1fm0B6T27dd6vBjCVvoNltaseTVqMQFbae1xvjukU2VhYF6+Jn2AC+An4PZtmYqlWaWWaBPcZf/GyxUsCt1p9cceBYyV3Xpi9yqtKF9/flAm+vby9Ya+GWrpzVFza3zblkVVkshaKb9MdbClZ1jUnNxp30mVWxI/d1YqDJ1/c8eG5SUj2kXf8CXXQJv3X7k6eMhGVJX236OrN63ysJb/4zOQML1FRv4YwVBV2r4C92SLTcNd1xK1KOQiq3yuOhkj2nn+iXrTSdljwZjNYbCceciwDcI1casA0IaPeuIjuGGlTGh7eQv59+K6Mqe/PTj0WdTVFk5vNB8He7yYou5/3kC1J6io/pGmVyyhxUfA9I5pA3PokXmGSsdcz0JhsiTfPjNvZnaY/xA55OthwcJBTHBK6hym6iY9Sc5HJbEgDu8hpbwdEKe7DwvqQiMAlDKCK0pgEedlsHDwIdCjHF5ZOnQm/TBwS7KNluZbom9tjft+gnxlDWEFGFJO6ZAzeh8B9YMW6BQ9eU5lkzk1pdfsFu/fUVBRWK4bB3goCUMdmUqUbcilDKZoaMj1RnygUtywK3Sxru9L8hmTl1Ucsb/FqCY2fXTtLg2zKZ0OspFhwBfjYtPDK7ZI16TOuBnKJFMm8VDJcPZfkxbZBMp5U7WkymYevhEZt0qLnqVQleapQDhQrb93DKObOOQCyonzHdIv/09c/6SsGKFTI2Ey2PNuhL3eilIItxh4S8tIX2/t/tHdlTW4iSfjXzOsGiPuR+xIgQJxv3Ie4BRLw65dSt8dju2fXEePdCe86ol9oJQJlVX2ZWV9W5gUTffTxSseFjhhXYLB9zMz08E7VE9r1ruPY5VuRPYbtTIVnJX48LO8CdwjN6bnE+yBtagRrEwDFaaIXc7cuNiP3HTsTy7v9sx27CymIO2yKKPB+vi2Dz2zcQ1GVqapMFTmh7O2R90F6tb0beeC64t9i+LpZ4g152yjPJ+WKJ6HAo+msv2zRPHG+rIMc2XEN7tn5ubxJvv0BHy6UsuSwSarsOa/0VEersq61QkMi8qdLPp7xQPn91bSYuzyqNcB9O219MrJSScn853QhnY1FwzJTJm+ZOSzQhSrPz4gQ0tdrXZeR/0CIDhBXGraAFzUAHmkXA3Msi1L8jIbP4iajZXh9VmsdNrnLWSCXiblgrFyY6E1p85q0LjFc1Ah1+CW5mMQbETDbKDD0gMUNTxleZSeX/AyxPC9S8uEzXcERVwaGl+VwR1q0FiqXHuTM8rAWqzPv5m8+wJryyRjdm/oEJDy5zW50blTFyBFqPDMrFagwse+SwgKHydV2bcdKBs2Ym5By7hHU8Rg1lzW33lIph5/ZbAWOF1zavNtUGZh7rwE+Kb9WeYo/LOPA6TJySyGtdd0zNfkJuFfBOzUbDYrAeEVM6pLUdbfV6AYcZAr5Qnz3TH7fnNuwa3FUTryKC2M6g0pbYId+bBquTbO+rf359GikaU+4KjnXIACJA66wBfVeexCj0DsnbFVzbs/tHR3cnOcesTMOKWbqR0yzHqZTo8fZn3asWoPehU+i3IoIMdOiqdG7H+GI3iYKc4qmcyghOjLBxAWpH48cED0KZviDL82FtjdiEJfugdjshuzEtIa3J6+A0kMsKch7t4ijc3gfO0/bcb+VYA6WRrsWTFUeb0jqpnNrwETkkNzt2JiPbblw7uPr+XhqKVNtVVi5uM6gCzlq9e0rmKeV5uzdJsyv5M1aNR9BrkE06/2yBYw8uiRbGzGEN/B0s2qsnm1NxNY5CavEuisV30C5tJN3XbIc0wAn+t05HOxy9tT7APScHZ6QMfnqzUOJyiu2ejEmKQEkeqDXIl2rfgoyyXxvPeLCQLjFFsTqvq8vBW+Z49pgBWlDV9HQpSkoOH7TJkATvQo2g1gIYaF1UkoRKEn2aZetBCM4BdxWtd6EH56nH9Cy7Jnmq1CP7b04EccIp0/xOrXPyXMboOjJhgw6YR250Pf5gFFACOtjEd9a0TBEd8GSxfEro565yqMupl8rT8LfGBtPAzbA53OekHDarZs3esqlVu+8Rdcr7wWnfTXRVRFI9qpfrEaETq5EIqIQs0mZzDn89mOO2dXQkpAbD3d0SBfEKP79onWIhc4XfKe9yzGdTleIulw1CL4H6p1pLQ3iNA3G8/0Gs5FKsHLXoHSSUutqobhWS1tWCcQsd8kVOpxNY78ThvU0yH1/bI0b1ehjOlyd3TQ6rdd5Vxb5IL8JE1hVmG8Q3PiKIS1jOlTD49q5eEbbMwCI6Hdy6FxvmDIu043PaaFh6ZSUas9h3uI+H38dDhg2jMalPmwmzT8tFIStBnz1exUerw2UmYdEdEaNtriz9yrSvdkj0nbHkP7AUcS6xjZwsAiMQag6OBlXB9YBdSxFSHlRd6TQngN+zJO7WRyzfLjwx/KXMnxZj1C/muNAdLi2iFWjtSngEutuA4UYCFazhFEuJ5jigyobJ1eeW12s836DCbDLWuIpTdrOGXfIVi40RYxEdLGrWSzr5nG50H3lkFPDh8rrBKp2btAlJikyAKW6urNHYmWsPMVwJAj9CN1jYEvgFZRcdZCtBIkwNci7hIToRByus1aluWhm+gbs5m5Jm9pkiBunDUSndFX1z52g9HQ3FyY48Lz1tZjHu6SGrPxQ/2mPew/HMyxHUwtjBEGcuF7iS/kMZwQEdt+g/YGo2LDkWHqKs3G4Ri1rKYOfQ1jSwleGpO+9HV0tEtqLlGcvwhAeq2aXofVMBRxuwVTnPxm+YMKwSeA0ZXqaEdiH4oW7bVytEqHRxCsmvFhozbKfZmCIC7Ua2mMNZ6Y7pWizm4xsFZ7Ai7EZGUGHrk16OnELErGP0ShoRc7YQ/aIFikFLFF1ljhzUY/AE8w+xqAWoqNvtKqyVZNLAf6WFiAFSMaBswCHeJarT3oYF3DdFXW41Pdo2c+9Sg0ZLSjO0wd7r7FVQNEIP2RW3vftlQ3yoO3Qm6HDJ616DtYlzhqnOGv1jUjxkbnFkHaYxGyOU7a4pwb3GM8zYx9a9valZ0TuUSqgOobK6/yxFD3OOuZdrAxVYOr0mTdHiLyuL7lajcuIwmw4vmrzRpqZQVRGIdtE0uxHHF5stHwBWMZbSOJNEbzk68pEy0ofy/fh1wPIY+wJ45YM+uH7zEd0v+6uaZDemtBypds9NkN9uopQbdi8gKHlYbWL+UFCaihtbROXhQHMXSCBKiEF6tIsbTAmAnyJGjrFdcuENVFXk/bg78N81ZVbA2MBKT86sEOrUAtpjDJdsDcZhcU2vzk0y2GprPvWatIyAw+6NmnDk6Z/8K70IIg9uZJswZr5eWLGTQMBOJMWTyvZLFAFJY+ff5WkRP+EEfpTkhL59tDsx6wO/J8iKYkPSMo3ShJ99UFAQUOE/11u8vtH7BM3CX9w0Bkn/ovsJPHNcGRpkX364f00l33Rd1HDf/7vV4r7LHPuAZv2GsE6m+ftXZ3RMvdfju/bM8GDviA6P+gVcO+XKcn+PY84R1ORzf9C7k/GYcqaaK4eX77HD1fyt3P+51Iy/J1KPv2dSqb+DiUfqpw2H9x/LOT3y+CPn3Hr+5e/XW3vV3/DCvirg/N+66WvuvkPVQq+SCwgvsapt7d6v+fzANPTFG1/EBuAwP17n4J/3bLqa+mvW8x8KQ82qV/P/zzXftfHX+gL8lFxhF8tsX61xPrpW2Kd/vHbpwZYX7S8+rDTFf0biYK2R7TwG8X93jDry55aP3Pvqw/ys74/Dwv/jjQs/AOH/Ue0vvoYtD5Kw/oFWr9A66cHLeQfL7A6MOeVG/sN7Byf/j8hD/I19HzUMuwHQQ/YBfu9Pembe/W5ySvC/xM= \ No newline at end of file diff --git "a/docs/database/redis/images/\347\274\223\345\255\230\350\257\273\345\206\231\347\255\226\347\225\245/read-through.png" "b/docs/database/redis/images/\347\274\223\345\255\230\350\257\273\345\206\231\347\255\226\347\225\245/read-through.png" new file mode 100644 index 0000000000000000000000000000000000000000..7fc545e613fc847f28953dc423a57b8cbd3a1e67 Binary files /dev/null and "b/docs/database/redis/images/\347\274\223\345\255\230\350\257\273\345\206\231\347\255\226\347\225\245/read-through.png" differ diff --git "a/docs/database/redis/images/\347\274\223\345\255\230\350\257\273\345\206\231\347\255\226\347\225\245/write-through.drawio" "b/docs/database/redis/images/\347\274\223\345\255\230\350\257\273\345\206\231\347\255\226\347\225\245/write-through.drawio" new file mode 100644 index 0000000000000000000000000000000000000000..7626c8d1f5004745fcbd532b7a6a90c6f3b2a9e1 --- /dev/null +++ "b/docs/database/redis/images/\347\274\223\345\255\230\350\257\273\345\206\231\347\255\226\347\225\245/write-through.drawio" @@ -0,0 +1 @@ +7LzXsuvIkiX4NWk281Bl0AAfobXWeGmDIrTW+PoG9sm8om6WsqnqGevpI0gwgNDuy5d7OPkbTHcnP8djqQ5Z3v4GAdn5G8z8BkHgB4aft7fk+r0EAH4vKeYq+73srwV2ded/PPh76VZl+fJ3D67D0K7V+PeF6dD3ebr+XVk8z8Px9499h/bvex3jIv+HAjuN238s9atsLX+VEhD+13Ihr4ryj55B7PPrThf/8fDvM1nKOBuOvymC2d9geh6G9ddVd9J5+67eH+vyqx73r9z9y8DmvF//IxXONkwglAhsec5gD0g0PAf+Cfy9mT1ut99n/BuEtU+D1DLG/Tvs9fp9LbBpe8dKpUM7zL/B5HNzLpL/C32aeHqmn9e/u/y/32uY+ln0fv2nb9xV7fWr2tNW3I0/N2EYed67fJ6rI3+WLJ//4eZf2vyHO+P6DjCfq+9/olKRD3NRxf+JGmvVPSIIAX1+vHMeundh/sO1l3UZ+uJfr/D7+P92rZYfNXhXCsT/GR3Pf3H31468t/th7uL2L7fbfF3z+Z+enUurp8s/e2TNz/Wf4rYq+l+32/y7/v3Nqs9+JOq9C/xN3z831znul+/T5B+N9/lfHjiGOfv7vv+hepanwxyv1dD/Sf2sWsY2/l1Eqr6t/ubetx3i9W/r/CGMz1Xx+/uP1CZ/FID//BuL/kY8/4jfWOy3D/cbib44Eadl/hvL/UbRvxH0r09PJyzyG0X8RjK/XxDMW/n5+CHeiw/9G/lc4L99qN8o5G2OYN/m3nb/KPlgv1EA89dxzP9yZI9mJn9S9kvN/iiG/k7joHfRnvKjrNbcflb2LT4epH3KyrVrn0/gc/lKxe/I+bNebZzkLRWnTTEPW5/Rv/T1aQ/mfv78pae/BY8/gCCfn07/puh3MOHzocvX+Xoe+Qu4/w5sv0M7hv7++fgrTv7lmfJvMJL4vSz+HZqLvzT9V/R6Ln4HsD8HM4Nx21rgr4KFQJ8m6QlHmH/6Eyz7JQIk/bOv9G8f/Kfk2X38dxn4kFK8x/xrZf5k695azLv97CMTwNvUH7V+1XhlA/4RrD/fuL/ZpGWdhyb/Yy9+hPjZuapt/0XR77rJpM/OPGAIU++OVI9BIn+/0VVZ9nbzp1Lxs+H5u0j/hiD80fm/EJv389/ICvXz979GVmAY/mf076QFwf9RWh7A+Edpgf4LpCVjzfbT/o9o3ruE+R/5WhNF/WfS8i938V228T8+/b+wkDj5owXg31wWCP57FYKxP1Eh6E8WBUT+C1blzwnBv78qD5EZ38uq++FOfxFQ5ZU2Y1iqX/jOJMO6Dt2/iUffnz9/IuTr8EpzvIy/ON23Ol+hpn66JP8oBf4oea6zeI0f+/DrI8SNr8WlK4/SrQOQ+WIgnz+a7ZasWzxX6vvCiDQZPu/06stY/ly4K9CypmchwQZl9Nf+DaIg0BF23LIRc1IwLbKB2KKtdABH84q6CpPdjeNLVnT5QE80q1Rsu7cLdXRh74ga0GyujAIaYIbDsomf+YDG/sGDFX/Y44v9z7/819tCPBfU5+53nYh+blIgvAfPG74Tz2uEfj779kX3hUDvT89IkW3TtEnrJ49YvOy819vJicXmZI1ZpeTANraG5JVL2pL+NEBZKs2bDEolStlOAGvaoqiqK4s61ELbFpkkazuxpP0Ua2pG4k7ZkPYpRslaDmxhO6JI6dmBmz/FSBSvVMMWtKOIlp4eiVk0pn/9FLNsRTOMYunukZBNY/IQHsUlyTZPsSOYOoBEJLvYvI+HMSWyzUWTTp/qgPgW57w/mxElks11sU6v8oAosdyyvcUWJRbFcQFOq/KHJLHUukH+YFLSUwycALPqvEkpbNluEF/YlKQWBYs+kkS/xcI7ad60SUldSha9qZWmrX9/LXjgsc1UEdtJFYzEKG+Lbtys2+/Nbn51HEe/12d/qCQXI7vtUdiCfzLbzsS8m+ma0x8VpObtezkf89sR7ionj1RydtdV6juvKkFaxa6nu9F5vqmR5563g3oSEDMW+3bw9AlGSg7E9fepRxEdbYn36Rwj3pJvy251PgrPKc//5vlvKc2IdFjinse5BvapsMaeB0pDKJXBg1ntef7zFDqJ6TJPe3Qd6uSISiJ9E/qpTgE15nD7jU4PBFDLybQ1OsO7IerNxdzSSMIuQxSYvfdavnfYSqyW0JbaGYFJU9iRNrC9h4lp8hlbOHv6AcOPnLc17PVREVLSO8DLIqJLEMBv9t2mYb7HAHDZbvfRwKtDUCu2g+9FnQiuIyHSxAGmC/+gaX9FevJJqqsexeIEiHCGpq+cd5iMrsaEdwSeSyMxfXwq/MZK0V7EcueeJt0SB48unX1OvM7dpqatGmtFiWS3b7USLGR/O+PpUn21T36mHHxEmVKTOgQe0REQo35hRMz7O+efq3kzUelmzWaiA8EMCGOG6KBlvpRNfYAZs5pm50/IkcQSUNx2FwyQ1/mEeBcCFYlxshary0SJWCrv3bK2ro6S5nOS+CRhjUHIjSPvFqttUDhJRe1Un/vKeqNBHNRM32ZPG6n2CxiuaUJD2GpTRiFiwtfklT8rnr6Hb1u98vCCy71Xl/WZMRO3Calc5piYo4N7UB2ybngS0KbYuL3wQM/5Nqzdv1UGkOzxklvFbdqaC3QmEncJwkc62vtig2+5xXomQKtOd2+tYXmAr8hNnKR9nLZzwXKPQjt8RWdIyr63VRtVYztePGGlEx4INmVP5+zCvjz7POT7zRBdnfVcWqJSYvCdIB6yazipvpLiYkcwbdijfg/E9sF6zSGQo8YFysqzaWXE2DTIlfGS952gB7uOr3VOGo/XqWxcdwfOI8uv9aMzOB6SyqaCBjB5VsHqktoP0xNkeeupfUk5DMc+I83TcxNWtLRefUVZaRtL9/DoM2gYvW1aWbm08/VR5m/Gyfnp3Q/rDFPiHXu4C5DZolMWNhnqAD7C8gbg2M6RTBioeDJplXEa8Jr7Cpj5EW+xNNeB1m1JIDYsXXyeNRylSYuLeUCjfaxMY4ZwrYkgKE2QYj6TMOL6nlHjsfccTWVBPEQPuLEXLNi49Opz01u3bWUIFwTv413apnE9cLG4iTgDQi2/vvDEOqVGRW0hWiUUw/SXrqc6ttTTdZJfBkholkLEIuG5bENr5w00pq5OcEZSaAv1xn/G769SvbMDFr+jaULVodBKbfoMjiBVUXXfpr+i3BioxdZKKwSVM2YlwglJrvn8/Flja87uk2+hp12JHgKinr2vw2cumJu6ZrSAvZyon219gVuTrBSoxkhp2dvGSNm29SGOQhLECtd5h8pCKz1OnLK/Wi4U/metgYddkFZ0tewSTXs7mI8ofM3zVOZGdxVJYK9v1Qui9mCYu6R48njKj4FAsmAuy5ptgVQCAoKlQ6BwDgCB36UkTPhKVi+mTdKBeIqsocnDTaTEKQobPi523UeHbF4nC+2pL4n72H+ROTnYVdqSsR2dri98eRpKEX0ZXsUsjJqYYWEQ3w8v5p73Y8QujBvk4zU0lFpgIqiE5qPp3PBiMiZXtfHwqQXiYbrlY7j9TuCMPcRze9DkbAnVKYir91ymjIgo92t/Z5Tyu1eNk+UUGJZ2yThbaGCt/YkQiYgvltegVQlj6TytopsFUwnUUQo+KvVpgcbIdmuft86wZPa8LYN55tOeVJ4nYYdaSm3IqDFtuv1R2SkSo35K/d6bhnqCoC6bAWtk/W3qQdJwF9vBCKt0zvIWucBoyyt2WTfco9MCu/bDmqbZiBLjgbFQ4WOJplA4PdJHVUFQOrRlG62dyxTNaZC3156V+2BqUEa3sMUk36BqpF1UFJxrIGhbm5DDIoHwacbOAvhM3jdOhGZgcSwqNXsMT8QRJ809oAmUeobUIZevUQvaCZNsLniZ+JFY6JRSoVqcKGIvAW1dOM8GN/da3s8YKhXeIrlLhvD7YrD8aB45OUKH6HYFE8gh84jy8IVvCbQhtVfRRoGMvmRRamrD2chTHmP3rnxembLX+gff+KLcKbGViarHt0b17548Xjq4rI8sAaOMzivq2KqksFv0LHKrsVqcwZ8TAYVPgExvW/NlBJm7RGQ2pkstQSV5H1UfjUekx93IK/uJbnZE+/mB2GxBXl1a4vIldHmo2G0zEWtoMkCLvOxQKC9zVHqwnBdOgVbaUNoHD9Tg8YchyslkRzLACA+R9Pn44klL0FudbC+/kaKeWSnDah6I4DbXo0s81Wmm+mjj7BaX3ra7T1wpL9ZtQ5iP2szX0HZ9YEY5pyswPYEt2DYJ/JiQpJLxAGvNMcHsPIZEst6o0l4nm12Gi+GHV4dK3jTm3iZZQ/PSY4FIbLIU/aXqkl0SOBTiMaUL3buUuAQ2rz1sFEUb5RtF81bb5urKEKWY2K7w5RdTISL2Q/PjXefHifRAkCtKy8tu2g05zjrY1oFXKu2P2GcmMs3PNZ+0qbx9TLNUCnp/yGZ5DZ9hxz0ZP0zUPCUQFjsOCq7XFUMXNs1NBpE2YK6sCdG0+NKid1RnnIEVKeIfCQ2BQAebMko/HcWY2IclzCsA08X0EhZHKemFC3W1i3Pty9j8QOe+3q54dBsaC9n5XVtMf5lG+O4HcnLnUZkhohNH2CYi16Y8NArjYL7aAMItZvFYMz/YDCe+lUyPGeMoUVpMoqUEyPXnFrEC5CWjFDdjw9HYjXmiOXY1rAH3/qB9Tf0zUCRXfTcSslQhmJDIvSDWtyNmeA2DzNgHWfRBOUOGRoUhlGSY7jgOaDS/CMz0MI1eQ1nwhwqEvNuYAWVXbA3fF3+d5QQA3r17dXOZjF2BMPdio1VK+MMcBacbXDMtgUpZhVJnzutj1CztSunKL802uDjyFQN1Hsa0sPBaKtnGNb8yKb50xZG32NUHLjPefYQckcq/fHQq4m2IzzPEY0bdzNRYVjcXO7S0fPAowrZicVK0l+Xv7qfpzAYVaOiQH4ZVv05cWjnQqxbV43iZpWBu/QMNPKI+jPahpa/vpsel0uSqXfW2tfugqN4R9G0wHGY36349AjFlc4pFopVpL0fEy/6VX/GAB4u119Z5n6OaEglUWcRntWxhx0gltRoBWy0UdbCIDLO/K3L7iQM+zlqX96/k5d/dEyue4rBNfMf9uh4P+FDPsuqVAl+fWSp34jFSz3QnyjxXsKQkmRTerYegZzc/Nht5Ehb2zcTUsM/6DMBWbZsTjxsKvYYtmGO0YDsn6l0bVfAZWsuLQVBhZUStcz/RWISRDldjjblHH2kgAqdRHzYVCeLSB3pd323f+kdhLNOC3XpTA60U6ZW65Juqc9ZydyUFJr0I21WBp2HM8dF/fLkwuJfy1O6xasfJ8BL7sadUBu1zn9sjg9v9VK2ZYdeLWjoA8PrTXIp3n6/qf3xapHDctp3cPDr5zq2DVEFqZb9vE/6LdmzbSMc66dWs5o8vpQ965iE4Rng2ILrrC/83fCZQKREfO/fL5hvD7GzrVvjxBoUoLpsesJPOTUFmDHNot0CKyhtvqw6kPeklW6dycznbOq20eDV0n+5kMvd+n0aUuvciqc/aTutcoJXPzXLuZKjZsJC1drbrF+2pAX1353WPhvX57sCPH+jGK8pOpr/08Uegk/rSBwtpmeMVvqF92IUpRdzjeYRl797GFuW2qMXRnOX6gku9rvnOabyKmcJeSIuvP2kUGeF1/H3K8egBHf1h0lugV/PcFJtZNfU8Br8YaQT3L2H4Hnaj69Ov55r7gXL/cXkfGabgMqJZKTP98eM/2Cp5vLGBmVTsJqqeXJ+AuWcZnXT5YknrHm7Y38L7qqFj4ShebI5IsoXXMtRi0hLv3DRkAe3TKh0rpU3taR7VcyTn0VcWP6/TGlJaZwCeFKQCyr9Ugp5vEXk8L5qN1PhxDj0TaKAsIdg0cD9T97itlKZWHNxmDhT3DS4+4L1U/U1lRds+lMkS51utv8nSTA0YlTlMzcYhcYOExNtxLpqKTbGNvahrNpURQD9mWcfQ5R0NAPmlTbr5njYigNHQO6JmDKAPLiXCalgbyP74XT13OwproiRkz7XeN49VR0tFYVZ8oIwGsL+fqnxjQ2waU1GJAH4xnzJQAJm1hR1s4jlG2uhM25cEzu03kkVvPJZ3jCwRtPHTGwAbdhmrDqo/3qVfCQ5uzDw4iOb62OD4Wpoi57zNflyk9orynnV8xIM1/LRGYnllR1id2kb9TRr1XkKJwjrJ4jWdd4IbdJYKJXtC9vmAiMTN31IJd9sPhOtDW1RdUWRZSgZXnqnnh16Lu2bJKSqDBwYR9iEiWPB6sC/glMoMLlgD/njiFo2xPzKhLrPzKBsjVbHBwCjFdDSpoK6DC0yGKaQi5lpDeDRLIpJu34AtJim0kq+WmX012z4t/bI4S8IcflE/TqPSlBr28dSuY5ikt+hcXl82Lt3NhtwUPMxmhLczrYdx8NK1W1OEuYQyUT/Km+0LSQPXedbr1mYe6lJ9VF6pdB4Fa9zo98UCMObd5VMQEuMyXP9+2vh+5v0CvJg4osHLeLelWXY2SJdQO2Vyv8wlKLbtlZZRcoYkxm4OW1ivgemeuSISS0f74Ip5eUuLBOXAebpP+2uvftYoyLAe6Xprhz7o+hgJaB/7o2wvPXoMxeOCtFl3ioIJZK5sqMSIDwOu98vyOPw+U1ytfY+njI6vWYC0yHHfsd5b1b70VH2REEPAKXFzqcrXiAf26rVJmGooBmueD5tEmfKk9ZrLmDNkvMvHZn9fSemQOruvs6BE0iK4inHoHkSmgxBdUCPoCYscnIjt8JmNDjf14lSyMBqgBJyWRCWH7EYckUcGo/WCmyRB0Y5yhozMN+3hSm/gBOCJpMqTNDxtqp/d7nPcSTWyRnbVA/XwqwkeE4O1UU62J52pL89ngRytKlwT+gL2C5LesKDe72GgDT4q0HrigkEqrusn7uCRJPS4s3rD8p1ETnqjFsM6r9XlZHc9bQ82FrtaxPgt+SIw4Np+u4XKGPLlWpv8SC+Ba2Yvqgl/MLfsOmJR0Y77LKWXqc8rqTsAHGrqN2TjCSNpioPLX/IZ7i9yaHUV1DK+rNZr/zmW3dI+HVW670Sq10+g1NE60VReIkkOFfQTLe1ZHhcQ1VjBPMF511bEar/xnWIF/4nWqW1ycuXoReLDNtfWcu3bOxjUAr6UsQsFBG5c+4EFN7Vo5GEnwVeHSDFZIPRhl8WCvTZx6xOII61KuCbZVwuCHSXtGOKpW5+WlgJn/SEo9zPX7tCmbnJDNNK+g4+4P8QpSQ11e2fS7Mw3bXZX6uGE5QntNUwqn4VxA+Kl0B0jZuWM9TAcL6Kut8Z+ms2lBIrzjKMVcrWDBca+myZveYXyWPGkJKY77i0Jdr4116I/OSj8IHLLZhFsDIis9foeaObwGHuis23ddaTUXmCwtr9AOM6sa+LCJkqarFrLekuS8P2gsFW12lc9TDFNSaqJPXPUTovdM6HTzOaxIXwvhrkGlukbd2EcwrYP+njsmAvyiCBz/BuUzWFewcp3z4PsBZaxBd4g/lI/M+Nu+ie4Sk62MKC18HnsiexC6UD2ufdhqR4a0YzawSS3JqtnRjcuVTYEG/1VyWsA7XR+t6Se7EjK3bn7egzxJR0xMiYSGRZ0N2L4jeXY7ifNppbA0Mm0yAUp3Ty51om+hY1VfYdMLqiOjWE8hig5cWOq72IBdtGKvM0vWRbBtC+KAjIrRblyLeURvEbX3QIfijuX0Q8TARBt6138HQ12L7ZH+aPWqI9DMVo0rzFVusgJKzYkwQqNlPNSalw0lskj6Fhn7J9aI0ePx2F8zDRdexfIZWfGjHffYWpyVAARglS5K4stRnyOlKBWp3sO3Qbssw3IG5viuliiweN28En8MpMpfvndCzcrIpsrw8bL3HTTZIyHCRHds/8Uz5tzhm6aqQI6NvGHdKcnz/EKC5hUo2jUih63PRs8EpFyOzDkYJmu5C/b1yJZMvowbmc0ruWGzVAtIkDGsYtgYMnmlSBGO9VYAzt4IMDW+QVIh6PL96vTiToEzQcRyZIJHjd+44pMqw7+K0SE/ZB0rhhHEqI1SiveDX484Ph5TGLXVmKO8nAaj5UbL99QOqdNiYyUrLjcAJ0jh7EKWnCxUSxDR7YawdMBFnqNqKlRu1umUqvr9sFOUqkqZLZP8+SsjwNBnvcpOTVtRlGs2knmZCLF91ZJBzHDcyAevM6KJkorTpkpaqtyj6X9RGbYooRfoN9lQKQU4LYBfN1j0Buk5ew3ToklhF7OhEhXCDgpxPryAzp059TYZHx9xc9umWqULXJ/OW9ULQDiQA880CMRWm13nU6XOUNy5FWZbioISRRTKrw/dPdwjm9nDg7fCoWyK7FTJJaZ4MVP/ASbMrRRu4tj3dx3VT+oroBL7Md8vhryPIIkaO7ZyjStqSug/UtqwQdkqeT7vOjJN4AxMRRBtmH1dD9PJzJtW5RcytmD2apIadlw9A0rLLOIkg+5Po9Ho2Dy8aOy9PP1WyIqHn4YhZTzbt5g2aK8vB4N/lNpECWWnUj0nkAEJB8XKSPQr+8BYUF7YoRw9lupeHrUt3z/qaIWktSoAzm+oAG+ffrfLzE+lVi3oj0yRMCYSN6TuG1L9zl+q5iU3KgLPX7X95xM8I3g81Rw37M2j3RxEHv7S5TtVd99li/9p0Iqj1/teHoTAiMAxy8fso3N+6T7MgHs7W0W9pfAPlXeUzK50FNszbXDIBgwzJlP5f1y5Ln0PVUlbdfTLRmlQ1F8T3X/LGHg3zyA//ezCK6/TwX4d0/H/ytyBv70dBz7kwwT/CchBP5rwtD/N3NB/izbw/59kH+SS/j/cMf+SHBA/kj7+Js9w8H/hVke0P/7WR4o9C+yPP4sUQr5MznG/rvk+D+wKv/bZnk4QPPXLI8MOyDL6jkGrA7Kc9igpc/PEU5UsUNzzdrbxUGL6srmazWO6pzwcNiqULMGW78+JCbTe6hVtDn6LicsL//rVOXdkz3Df4JSUQtH8Pfx408Ix0HnfvzEe4z6ezuK7mQPcl3ZkMzq8LDVQwktleWIzKooxSIPMzhRnmSdU8tJNi2Zg9FEoUO29SEljkRzujYzN2uQlNozd+z6z/SlpaSEHC1RWiqKPKlQkBVNlWV9pCsM9SAo9jINDc1imhS7ixVT3Bc60adpVBc6t1ipg7SiSlY/N3M8fZAEzJ2TaFahSK7nKuZRiZBSM+SJfQEsaWmNGOKQaqhPH8KVCvpY2lRRVDcLWGgnFOJDvdBNmV3z7bh06vggTuYgHekgoDcuRdKJaFrwFuZvH+/kMotmGYriNmlgbtUgLbVh7jzwi4J+JkcLOliiFVcUm1OiraiY6WMnw6o20j8md0EeNPZ2vI7t/fJ08Q1JEz+coQTmj/KedG+NimdnYKTw9w0ZSp99hox3886BlpoiDmoBfoP+zspmkgeidw86EwFyHSVL1OMjgCHwBlJ5DecXvrnM+Qt9NsxMbHBoj8jt8rFL4Wesn8vN3oBGi9jpGa+1K3Y001O6GzfPVDEnLM2IRiGcYNwEaTB7s/cqGSlY/WbaT6QwAgoNlYEISV37otge2pgI7WuybYqb7GxnA52UR9G2CU1aoGA7WBWo2e02/3YAO9dhlKAhnWfu1GXoNGZkw0E0ZpO87NxvJDPn4iAYHIQdhGMWDOD6CYt3n95eKaW8xVTJjp0rYuVZLhYRHK+LfciBlxsBijRKilzpcqePIbWoCUli2iCSddkzXndBCdTSJt+IP2cjhEp+jGneDo+34YqXEMxascJGZ8xkJA3cgBYLk3c8kZ0hCxaDjpBLLh1Iiv3Lk3oXcSTf0R3f+SMAxdJ+A3BCUCQ2baTE/I4SOIPJZ//XaTaqACgasPylLOIoIUBGaTqAEodAqJLIDg3Ojmxul02BPc7Id+MGiDyiz89WtSL81USKLMz7py0q1sVCycjakTLSkyJWfKGgyRW0DJ8HsIfjgoptRm/lbWr4EjdvLpQJqT5nhmrnKpFYSEBqSRVPkVWbY/ooGkcfzPwemFmaRAoGdsI03dCnt0hYPqkPNwvGzMklrR0b0jRLRKQ+HZB+OUFdnLq+k6xy5zWIQeYRhNhWrFG/L+Kbm18HNXy94RHn83EFnBixWLeNUhaJ79IZXry78Pnsy9Nd3mKfaMAsAiYIvIMlWtY6XNOC4EDJ653hiCXnTZKR8Uike7Hqzke4i20J+/ppiY2Ptcjea3RO1aS0SayOsfQASFrS7+4PHEmz5fkYijxW0nsW5lQ7aV4W3dnTh+mINe22zZXdTLjpwxUnmbwznrXHbcDHvrSrz1VTPpJg83bSTgixfuRtnhr49DcN3zCwqC+p6YyLwrXNXOzUHEa4hQ6nzUCtUHAqFk2Om+VOF/bXR+2+oz2kbvNRKKHbRlbnGTlyPhVk1yMDQK4CbtG0sj7JSbXxhjYHn8xbDmG8a9j2c/IrVlw8k2CPAzQaMZO3xjGv9Xox4mDxkq4EoUIESGZvS9M1YxZOLhSPCTYDMy2uRYVPnWaGDiQoCvmag8w/YOxoL8kml/Brkw0ftnPTXnMQUL1yhOkzBp8pJCKn7aLl6znQVgEos4tG0wE8JMoo7/zH3Kgl2Ne803CBH9W0ciKmwIzyZX5yX/0EmWFCpFO2Nr9/elntcoPsRXFbYJYlKFeBWlnzXzM128ho3VPf/pwCfLuLNOg3fp+4xffKmm4RZ0ujDo44x23zeEN7dWN1aDSQjTui0in6Dl21++ZAgrh6Ukrtu4LRmBAtp+auzc+ctfp5rkbUvbYJ0Wo4lUkxmuSID+qw/E/iEkXUrLr4Vw1A5gdoqyDo5MD92hmoyjpP3LRO48n1hco3M+KzAsDiXjf+zA91NIbEna1wU2GCgL6HTpH6CvVMiSf/+fYuTcpbwmzkqnzerA/T7D9VOGdawzpkpWXYtxOjCCIYMjiFm4PkzibHWPRwiIXWrNmXbtb2wqRg+XUg7VPQxGpsCtmvuF20jwGWqu5A3mMA8QQlue2KyXxvfaWtOzvfyxJFFffHMwxvOdFY9ipiI7SP5D39NM8BbFyH1clagN6D3s2PaZQWg6sUqrrUiTdWtpIiuQTK07GNZmpDyrqY2RmUOrNpTqQfk3LRFFL2ZiRdQmVBx2GOiESFlL1IYjgGHBWyWsxPbrXIGwDFItnomLR78UfBxdbt3lOkBsTsSDRpEgRpx+u9ELRdd1ECQvMiwxP6gre/muRt2FARflxyj+s+dpzTDqXEjhEIcgz3LJYDXKZmEOq1QInShZ7JZhfIOyN15Y0pyq5/NcDCDsTXyGboFb33EKvYMV598V+gmBYAeL1VXWKdVSvkhNh4j+ActPqi4nkzhsjL1R5bOi3SNLW84VMZATZHFuEJ39M3n3SdtQEwraG8+AHemY/II8hpZvNhYp88F/MxqEnv9m1aUknJ59XPAl37K+w7JIt3ssAujCE3zkkYuJvjewowow4ka0cWGgaYABLyJuSCPwFbETdeFF/ewIYuHzNuol9MsF9//htM1cjucIIlUi9XwfhO9spRpLM+b0Kh+/JDu6TI9KU0lw8asCCKR/ESFOz4cnv4hRP1G51NUCSRlCtDu+Lz0RkpG2ymLTkJbZyczrB9SS8EhommrTeh494gn30eTkIZtMBWJlS6Yl3lfaLVCI0bIBKx1bw7HMXup1NV9GlbeCGCbfx1S63gM9sPWumIIw7/3PrZuJ0tSol9qo22vIFMhKK52rshZ6uMBQtrQvVfAbUe4Bs/H5SFzEcHHPorfwYjzgD1zS7wHLOwm7Mu3etB4L7d1cPFdYerOzLdUSP0PfOc0edl/VDsQlYyuN5CtIZS9565J4/y+jhmaWULtJ++lYbBQtle9SuHU24Nz8xVMpSq7x4+VIxx4wF9pQOFVFwWOwUy4YeNHD2Eoj3U0ZcASXfnUL7cj5iw1UMYrUXT6JJvRzJfFWpWjlcXntVMBOo+ZfWbNlZrh6cOf1K2rgKNR8EtDnIl4ey3tqpINwzvbzw4rogUeOArFS3pNNqt1/geXIa0ScLhMAixYpG+ldE3hYaB+uHuLXxsi87EIlBt/Cz9VKRmhfPI6+x3Ggu3Zsf++FpiwizBDTVW+FLCsEQfdkwV4dcslUZ5o1r50bojFlx2NnIAEDBLv3y/bOCI3W3Zhk7kvDlRNX0Pfg3zMM7axG6b4AjdN/zwmsU4loj6UL2hqUCxpRObcsckIzaR+K/pVFrAJ1mZ6rmkyDSXfWlO7tfNiNwI5R2Djyx7OeYHoKv6mdFHYY7Ugx8pv1OJJGMUEFBKdWHyUJ8J2/dKWNG0Jz4UqfDCLBDxSNNn73WYpvtICncFI5EKy5aJHYmxKyGZivOyZInhvQKhLooBF5uSFEej4orH3Y5oqt7Dy4N/Q6gd0pwz/UbGRhcyv3Pp0UcgELFI3QNWcgwxtLVGYJeYMx6dBjUi7QKVSVpXdIeNO94q/OQRNTzYcavytTbcgFToG5zyTemt/3D2Kx0e/JXYbNEGgqk48400mp4dXF4/G+fnRQuDlW9pcQKPp/SGiDcD4DGRLXomjad472+tPKzMnO2N6XRaYzEzy2A8NCs3EmIJavO0QWmYz3QEkRrP5h6pgw3aiN/4brSkF/TYW3agZt8pNmYwkAfUfVum3qzieFu/U5y/q5mplVpyamPRBHlbS9sgysLik7tuolkmMwOMBmt2mu4v4mWQfKn6jsLBQxjUeT3U5UWK5zMTprFGKbUJFCWDFgEjjvW4UleP6g6bgJQYmhUfR/ZbbmzOAgbPjiMEqoWSxvNDJ7juC/O9QrEN+a1KKmwf2y6OmM9lUqx9ouvSDrdJgXpMowmKaYmn8l94hMZiOjBSDjkA+emFECfRe2cROmDX5WDtlMY0lsecRM1Ffyxhmy4dAo+Fg4OQRkwqwsJ6Bu2K3aLkx7mzI2p7NSeZGtkHFcKVUsa3WnMhmk1GagqLRLIrRktmpz03TwHc5p0/E40wCzVNFg+8ZXAUt+z19wYWJcqASbctl/eWSr1Mlr6OLnwN1OzIOhQjOe/BsvM/fdSSSalTCvW4GQdkIP0EOIXUru3risJVgHjkEeTjdIMvCzlo741nPIQn2tdGwnNEPk8hrq0HKUiYwmKU5xbptEXIX0ug+dp73aOPJ76xElcTH03WUqdkmzyWkIf+hV9hk6avR+53mSOLgXAl64gbZRk0Cs6EmTJ0x9woNdi160iUfzYGcby525ymcNvEa6MfpOJBAmzcThTkYjAia/G2yAciDTWpOxrZnswQh+A4o1+gUw+9o+no4Hh1o88qBye4gn1xAZBlrpbqBGu/SiPQepx8NsBf52IhW8Gex9g0sDgUVfJFmmo+Wn0SnsV8cLi6UL2mXpa5k0hYiaKkPqayKlXzhA7a9+9ahKlCZPOXMnmPTr5ZKxSquY2lcJftciaLzZXndDdVsuqYHqwces2IYnBJAi2ZZb5w8BWLkjQ0f2j3elDHo+rWIuT5/H6DhH+oTv4JLoaH7YkO34MBJnudy8zXj0104f1cSElZpLUEq5e6RjdVwHeMtV+AdUbm4xewcY3DGlEZKQ0O9X6pp2Fl2awFxEumudzfDdeeYeZ5jcw9AhYMknAMWiSk8kbiOV5qj9K/g5/UpEOgHYGHajyh+L4RK4VAlsezqyopM1GlA2GkUzuMd2tKYbnQMdeumJ2idLyPqRPyMJHyjXJsqBFpTVLqRZGOvYFDrHiD1FRKsLZ8T+BLIwaamux0mny2hDqX9XN4dWdk38phS2ueMTDJVJe1e+0xc9r59VrT35BJce16c1Clyv2BFFOCdD1aX7/f88t5nBopVVF0SFLLc5mrNsCimWuWlK8690kxRPuh3BR8E9Ygm1M8qLPqCXW8zjpB1NZIdgeWHK2e6q87shwlra7N5me8ruMP++Oi9bpL1sq5xaw3Db273WYfi2GjTHgKEJ1SR7J96thEaK1qkQmLSx18OOrTsSa55SIPM68GcHI23+KBPG3WgryjyVeqqpZrtKIRcLPyvfFjsxAZgVKUu+1p0ST/JnooiVo+Hn0MtbQlJ2j9hposVshLCGYTwzXDhyNliqzjdD+GiPiemsiibyZjZqrDQwofl1glFtpE4wZ9c5BnIf2eW9g/rIuUChzVABhxiIgCHv/yG5lUBCW27/kG70PGM5TqKzZoAT6IXFDZbqNepafUHVwGePHValETVKkmiH6VcLMV3j563izp0qvrTMFSkyZmMRAxq8jsRGDHsBbUFCSmwq7zr6s6ERWMV2m3kqLrmF3YZ4Y4Nb1LWfG6rZt4Xmx6gjIJHINhcClSd3vThQEOzBu2mC0N0vWsgtLqEtIJSxIHOJVuqISJJuMdD2lyBR+e1jdj6DnL/fIu8zV37650MBxZP3z8s1Nnze9j33+iMmRNd8/c2MJ+PJ2CqXN7Tw6Lez2oL6iLM233d0aVgvfm51G+bv4ks1xTE1hLTygWyaq+sTmBvmg5jxDAHFuWgjevRs+VQKXcD9cp+sdwOu2BiTM7W7ql3/ACptiZEy9Zx783UZ/HIaNuJJY3bLC9Ma32Hqw+ZEp0YvOKlstopNNIsCVzaxe1sOTJ6zMqcwYr8+PplDTzIQ6ChbgyN/hdnHU4CCUkKWC7nwFI1abSppgI5cUBCepzhiq76N8vZTjLMI7Hgfd04xUFzdSnYSiuKVLx43dYzQ2NMk08+/fQA7YRDircyh+HKriqI/WOWfp8A5cV8Zonrgzr4x8YhlY2tN84Aieru+PJ3RDU18RF7l3o8Jup0AVcLoAfszKtwvtgJHir0pnH5WbWhd7/nrsC4iA2ekP7aIhtMXb96Jx1vsewcKpdqDKLg8DmKTQB8ztC20TMOGqK7qKkDzYX9q2WTFwsfl1u6SMrdyTVdGGXNdbOVjNrK3wmVSid6Znr5vWZa4aMvuqigvEFGoPGIiRmf0SRdxXrCJimF+h7LHN/mkDD8R6xwSQBEb92tBimf6fS628mj94xEO5ScP4S6A3Z4ohlJRqrJrO3g5nYFNKLA3B8NIb8bEMh7N9aLMptkOSRtS166dPi6kpFdb5FdzcgkaFkLeu99rp8lVN9jdRExbLZMeBDCUX94FjpA6MKTJHOPlTyTteNWGxxUTFOFFhCprerlrK2m/TN4vd7m+BYBmOe3Xd+fa2Zn5XppYkZObwx0EuydA59LrgVnZ7JvGFIiaTD2QaamRX9Xm1tKk1LXQ5dm5SnwCwiihMcubJdQl1YP1WCN8PIAMeIbGT89uk0r1yJaB7+92obHFNCV63EspAOZ1pgxyohUEwAnrkfRZNywKv7s1/clnhPqyt71A2atXjUymabTpQpoy2CVZZOtBnhBpYjEoXwQoydE0uLwLWVXHkivDcJPQOxqI5xOfZ4KS/rE3WVaO4sLlC2zoi3SU65DJ0za5Dv14winJpEsu2wU+cIXIdcyDlctrcl9s2usnjFbUWepiWR8dRr2zualWc0Qgsi9q/zrKFt7jcGuN1UJwRbAm/8i3VevrE8B83giCMt0nbHs3ReFOhl+p6xoLmm1JMok4/PwnltinGHpTZKiwCbPrznLW7h+d49BO/ZwxbUNoJVdEH+nzb+tTbeaI8qESfJZcw0/qQPkJRkuSg7N1JRFD8JBP+JHALoXzmk/U/lEPzp2et/2zfskT/JIcB++6C/UcDPL4swv5Hsm0xAkW9Wwf++yQT/8a37I5ng8w9b92c/L/LflkrwJxv3vzqV4J/Q/0AqAfin4oz+N4kz/P/jVAKL/psfjMiR4+tZgXCj/ZpUVfcFSNcNjkKaxMGHcfguPin/YUXXsaavzFyPc0FXeyHGlK0NFRUXq0B7BRBa9uxTF2lVqgAPQPBQEuImroX1GmMmAQAwOo20ca19zDb82FAIyuE8z04UNl5C1uzQjKInfu/f1IG+XQYj94GYBieStH09DZChbIp8y5lkAVGgiZCkTFLUwlwFaSqkMLBvFisVkOwVp8nOTNUz79GWNSuqEY5k3x8igHPGY02XtNk0rh3llk2KJLaGnxFkIFkSA7rK7VyCIiXJ0OASfJMogZni35D5/hmQepi0PoL89CQ+HPthjteDrhYLdj/shpbvr4hR9YC9X5joxinMY6+egilkTGo2wU033hNINKpvHMP0Xv0yg7WnZDU67zrFLSiHjR1EEaSqzXiIpCRnR5TUYD5DTlGRSB0W6vvFM05kv1oproNLqXx3+PQhvt9v5AIpskiRcRc2oFXuqtcEMysWWWO47frxyvoISJkhNdrSddKwIG3Rx012RhNS5dX3NEAAkscjf4jby/zxrPkYDnDrOriVrk9StplsbUvmfShV9Tmqk8+I58Ba1qp09JqcOTmQSDIRZlgCN38z/E9QEvSNOikuOhTIgzewtkzeUp+iaR2qKlanXQ45fb1dCvvzzIgzNE91kIgjyYJP7UvNYTCfNkZkKKFWXOhTBnH3ri8hLV/+rOJ+nN4DGD/nsdlD5EJy3H0XTiLVeAt4XvRoj9y2DEILfZbUflk0CyqDgnOlTrYaZcm5h7s3o3LK4QkYDHq9WgrE95xjUNyeHSHdgkJS9TAYP4uwY2TlyPee5+o8FpvKkYLE7YCV4Ui30s+5CD+6Jw6gGTDUELSnTkZa2aFDztpVe9c+p0/BTYQajQzyQp68nNznDgQuxZZgh6wawD6kDygOquliMCUwek9WEjOgghXfIGL4xtKpbeDHRH+Taa9QX8BcowLtsjOBMelGcJLVr03vfgDaGgCyJKt404sZQuVO6Ga3G+umsmFQgpTr5zCHCQujuLGgI9ROq43vJDlXtjKh7VKEYDhRwseBNiM6Xy+cTab810aiRexXOKZPFqFUh72WXuqi7ru1ifXcd+IEin1NQzQePziJgsGOnPEYDVESZ10vfiYDeCup6uXMKfIqOBZGHQX/DQE6hJH3OPWINfFSax7P9vd8CjPOLhkxhPDUvJxPNHH87aMmHxvbCiDKYZY9YnpnvPX9gu95vQGrEAW+qzKYvj4/Qy5mGCwU9UKw0OC9QqbNN+iMH17Btuz7yw/67HkFz5joSYT0NU6wTJ9cSBWAnn54clES9SoecSNpWvDHhhhOmd5T9DTxp72zkCqqBymWu4rVwdoXkxeasz/moETU27pKHjFppPRVmjTEnEtIAu9XBeAew1x9JrjXc8FZZkKDIoLHAVRn3nF8ZijMcLyi++Kr5UGeRpjA881QWN2N7rx49fukbS80EoI8SuWLKnkJa9cvorIOHEURL+IxQDNHRBFyQoUMdXg+txZkUSpd0Nng4ZVznbkuNX89zJa4z+UG7O/3hec+4JZSnXkiHQVnxgE+2HoggYqsLKpoj2KQGxR9aRZilfPp9xSI0R1aiZSqsGNGKOqSjqkk9BuVvEiZvkpucSYBnb0rlqrZA2c9uCPaMjYsB82Si6xwVBGet4DuDTMG10R1poAXwD76hJgWJLdq8e5ISkNBvuhRTWEOBdx9fuW5tCgLhA1NRZaNyCFer6hdup1P2m8mAGcCT6eXNp6PHeGKidBFvNYveGG60qZt5vN9HdO91cZc43rEPLiEegQMvDwp7LHSzUuHtqnHAKUW4KVKZI69LFEa6QCQtifs8KYos/MxmdezR+Gnn4rbdWU5JsF+qjBtxadDaTrAAvKZuxAT4NRqO7QBr7Fbw+9AHyiKLE8h6vAykzgFNUV5oW/hRDnW/d75AMM4Ypuy7aJNi5Vn9OsZMaU1InvBTA7T75tWgHqkLyqj2HxljnSKN5wkLN/zghUM71VGZAO3eAmT89pPJydMYlo90qTs6VWacNcbmZToLjtqlPN0snMyzg1sveWUtiItMh0KvoXDIZW+7+H3djyWCm3n0aVsZovL6s5+vpNugv2YPajYnRh4CwdTBX2+AILJdUZfyeLsK6jYk3yLESj9dY+3qTSjKAp9h5ZkC/QeMjjs6SDkKfcEraHug9AtqPUM8qXzyBIfHIRX0ZCuYSHzqEUCK2O1dmWpSvZMlX8Vixy/XBrdYBGy5GiAH+sIFNmg1jGzuffMVzicu3PJikQtUVP000aUo6KJI2YOm1BGciXpoRBAKJwGTZnrN4znNRRCyi7Hlnz1mI188edgYsENSrTWcZuBHGmzZOMop9KbGW4ifbeG320AYQrJXGRV8iaCZPxtUa5+ihFbHkmUer+2gPSe3TrvVwOYSt/BstpVjyYtRiAr7T2uN8d0imwsrIvXxE8wAfwE/B6lmViqVVqZJsF9xl+8bPGSwK1WX9xx4FjJnRdmr/Kq0sX3N2WCby9vb9iroZbuHBWX9rdNefYqMlkLxbfpDraULOuakxuNO+kyK+LH7mrFwZMv7vjw3CQk++x3/Al10Cb91+5OnjIRlSV9t+jqzet8rCW/+MzkDC9RUb+GMFQVdq+Avdki03DXdcStSjkIqt8rjoZI9p5/ol600nZY8GYzWGwnHnIsA3CNXGrANCGj3riI7hhpUxoe3kL+ffiujKnvz049FnU1RZObzQfB3u8mKLuf95AtSeoqP6RplcsocVHwPSOaQNz6JF5hkrHXM9CYbIk3z4zb2Z2mP8QOeTrYcHCQUxwSuocpuomPUnORyWxIA7vIaW8HRCnuw8L6kIjAJQygitKYBHnZbBw8CHQoxxeWTp0Jv0wcEuwjZbmW6JvbY37foJ8ZQ1hBRhSTumQM3ofAfWDFugUPXlOZZM5NaXX7Bbv31FQUViuGwd4KAlDHZlKlG3IpQymaGjI9UZ8oFLcsCt0sa7vS/IZk5dVHLG/xagmNH62dpUE25bMhVlIsuAJ8bFp45XbJmvQZVwO5RIpkXioZrp5L8mLbIBlPqvY0mczDV0KjNmnR81SqkjxVKAeKlbfuYRRz5xwAWVG+Y7rF/+nrX+krBihUyNhMtjzboS93opSCLcYeEvLSF9vbQPn/2d6VNTlqJOFf41cHiPuR+xIgQJxv3Ie4BRLw65dS93g8M23vRHi8a+86ol9oJSBlVX2ZWZmVn48+XuW40BHjCgy2j5mZHt6pekK73nUcu3xrssewnanwrMSPh+Vd4A6hOT2XeB+UTY1gbQKgOE30Yu7WxWbkvmNnYnm3f7ZjdyEFcYdNEQXez7dl8JmNeyiqMlWVqSInlL098j5Ir7Z3Iw9cV/xbDF83S7whbxvl+aRc8SQUeDSd9ZctmifOl3VQIzuuwT07P5c3ybc/4MOFUpYcNkmVPedVnupoVda1VmhIRP50ycczHii/v5oWc5dHtQa4b6etT0ZWKimZ/5wupLOxaFhmyuQtM4cFulDl+RkRQvp6resy8h8I0YHElYYt4IsaAI+0i4E5lkUpfkbDZ3GT0TK8Pqu1Dpvc5SxQy8RcMFYuTPSmtHlNWpcYLmqEOvySXEzijQiYbRQYesDihqcMr7KTS36GWJ4XKfnwma7giCsDw8tyuCMtWguVSw9yZnlYi9WZd/M3H2BN+WSM7k19AhKe3GY3OjeqYuQINZ6ZlQpUmNh3SWGBw+Rqu7ZjJYNmzE1IOfcI6niMmsuaW2+plMPPbLYCxwsubd5tqgzMvdcAn5RfqzzFH5Zx4HQZuaWQ1rrumZr8BLlXwTs1Gw2awHhFTOqS1HW31egGHFQK+UJ890x+35zbsGtxVE68igtjOoNOW2CHfmwark2zvq39+fRopGlPuCo51yAAiQOusAX1XnsQo9A7J2xVc27P7R0d3JznHrEzDilm6kdMsx6mU6PH2Z92rFqD3oVPotyKCDHToqnRux/hiN4mCnOKpnMoIToywcQFqR+PHCR6FMzwB1+aC21vxCAu3QOx2Q3ZiWkNb09eAa2HWFKQ924RR+fwPnaetuN+K8EcLI12LZiqPL4hqZvOrQETkUNyt2NjPrblwrmPr/fjqaVMtVVh5eI6gy7kqNW3r2CeVpqzd5swv5I3a9V8BLkG0az3yxYw8uiSbG3EEN7A082qsXq2NRFb5ySsEuuuVHwD5dJO3nXJckwDnOh353Cwy9lT7wPQc3Z4QsbkqzcPJSqv2OrFmKQEJNEDvRbpWvVTUEnme+sRFwbCLbYgVvd9fSl4yxzXBitIG7qKhi5NQcHxmzaBNNGrYTOIhRAWWielFIGSZJ922UowglPAbVXrTfjhefoBLcueab4a9djeKyfiGOH0KV6n9jl5bgMUPdmQQSesIxf6Ph8wChLC+ljEt1Y0DNFdsGRx/MqoZ67yqIvp18qT8DfGxtOADfD5nCcknHbr5o2ecqnVO2/R9cp7wWlfTXRVBJK96herEaGTK5GIKMRsUiZzDr/9mGN2NbQk5MbDHR3SBTGKf79oHWKh8wXfae9yTKfTFaIuVw2C74F6Z1pLgzhNg/F8v8FspBKs3DUonaTUuloortXSllUCMctdcoUOZ9PY74RhPQ1y3x9b40Y1+pgOV2c3jU7rdd6VRT7Ib8IEVhXmGwQ3vmJIy5gO1fC4di6e0fYMACL6nRw61xumjMt043NaaFg6JaXac5i3uM/HX4cDhg2jcakPm0nzTwsFYasBX/1ehcdrA2XmIRGdUaMt7uy9inRv9oi03TGkP3AUsa6xDRwsAmMQqg5OxtWBdZA6liKkvKg7UmjPAT/myd0sjlk+XPhj+UsZvqxHqF/NcSA6XFvEqtHaFHCJdbeBQgwEq1nCKJcTTPFBlY2TK8+tLtZ5v8EE2GUt8ZQmbeeMO2QrF5oiRiK62NUslnXzuFzovnLIqeFD5XUCVTs36BKTFBmAVl3d2SOxMlaeYjgShH6E7jGwJfAKWq46yFaCQpga1F1CQnQiDtdZq9JcNDN9A3Zzt6RNbTLEjdMGolO6qvrnTlB6upsLExx43vpazONdUkNWfqj/tMe9h+MZlqOphTGCIE5cL/GlfIYzAgK7b9D+QFRsWHIsPcXZOFyjlrWUwc8hLGnhK0PS996OrhYJ7UXKsxdhCI9Vs8vQeqYCDrdgqvOfDF8wYdgkcJoyPc0I7EPxwt02rlaJ0GjiFRNeLLRm2U8zMMSFWg3tsYYz051StNlNRrYKT+DF2IyMoEPXJj2duAWJ2MdoFLQiZ+whe0SLlAKWqDpLnLmoR+AJZh9jUAvR0TdaVdmqyaUAfysLkAIk48BZgEM8y9UnPYwLuO6KOlzqe7Ts516lhowWFOfpg73X2CqgaIQfMivv+/aqBnnQdujN0OGTVj0H6xJnjVOctfpGpPjI3GJIO0xiNscpW9xTg3uM55mxDy17+9IzIvcoFdAdQ+V1/liKHmcd8y5WhiowdfrMmyNEXteXXK3GZURhNhxftXkjzcwgKqOQbSJp9iMOLzZavgAs4y0k8aYIXvJ1ZaJlpY/l+/DrAdQx9oRxSwb98H3mI7pfd9c0SG9NaLnS7R6boT5dRag2bF7A0PKw2sX8ICE1lLa2icvCAOYukECXkAJ1aZY2GBMBvkQNneK6ZcKaqKtJe/D3Yb7qyq2BsYCUHx3YoVWohTRGmS7Ym4zCYpvfHJrlsFTWfWs1aZmBB12btOFJ0z94V3oQxJ5cSbZgzfw8MeOmgQCcSYunlWwW6IKSx88/mqREfyP985tJSuTbQ7MfZ3XgPytJSXyQpHxLSaIvHgQUECL87+Ymv3/EPuUm4Q8OOuPEfzA7SXwzHFlaZJ9+eD/NZV/0XdTwn//7leI+y5x7kE17jWCdzfP2rs5omfsvx/c3U533fpmS7N+nDedoKrL5d+Tenwd+y++Ow5Q10Vw9vmTt+eFK/nbO/6WVDH+nkk9/KSVT/w0lH7qdNh/cfyzk98vg159x6/vD366296s/fwX88MF5v/XSV938qy4FXxQWEF/j1NvXfL/n8wDT0xRtvxIbgMD9e9+Cf01Z9bX01xQzX8qDTerX+z/PtV/08Qd4QT5qjvAPJdY/lFh/e0qs088/fSLA+oLy6kOmK/onEgW0R7TwE8X9Qpj1JafWF9xX7w/+f6G/wr+jEgv/wGf/EexXH+PWR5VY/+DWP7j1t8ct5OcXXh2w8yqP/QZ5jk//n4j3kK+h5yPWsB8EPWAj7BeG0jcP6zPRK8L/Cw== \ No newline at end of file diff --git "a/docs/database/redis/images/\347\274\223\345\255\230\350\257\273\345\206\231\347\255\226\347\225\245/write-through.png" "b/docs/database/redis/images/\347\274\223\345\255\230\350\257\273\345\206\231\347\255\226\347\225\245/write-through.png" new file mode 100644 index 0000000000000000000000000000000000000000..f63c2e81d3ec95fc38cf00a4258ffcf8e8bfc839 Binary files /dev/null and "b/docs/database/redis/images/\347\274\223\345\255\230\350\257\273\345\206\231\347\255\226\347\225\245/write-through.png" differ diff --git a/docs/database/redis/redis-memory-fragmentation.md b/docs/database/redis/redis-memory-fragmentation.md new file mode 100644 index 0000000000000000000000000000000000000000..2a4df61f75821dffd34be2dcf80953f55ce77a4e --- /dev/null +++ b/docs/database/redis/redis-memory-fragmentation.md @@ -0,0 +1,122 @@ +--- +title: Redis 内存碎片 +category: 数据库 +tag: + - Redis +--- + +## 什么是内存碎片? + +你可以将内存碎片简单地理解为那些不可用的空闲内存。 + +举个例子：操作系统为你分配了 32 字节的连续内存空间，而你存储数据实际只需要使用 24 字节内存空间，那这多余出来的 8 字节内存空间如果后续没办法再被分配存储其他数据的话，就可以被称为内存碎片。 + +![内存碎片](https://guide-blog-images.oss-cn-shenzhen.aliyuncs.com/github/javaguide/memory-fragmentation.png) + +Redis 内存碎片虽然不会影响 Redis 性能，但是会增加内存消耗。 + +## 为什么会有 Redis 内存碎片? + +Redis 内存碎片产生比较常见的 2 个原因： + +**1、Redis 存储存储数据的时候向操作系统申请的内存空间可能会大于数据实际需要的存储空间。** + +以下是这段 Redis 官方的原话： + +> To store user keys, Redis allocates at most as much memory as the `maxmemory` setting enables (however there are small extra allocations possible). + +Redis 使用 `zmalloc` 方法(Redis 自己实现的内存分配方法)进行内存分配的时候，除了要分配 `size` 大小的内存之外，还会多分配 `PREFIX_SIZE` 大小的内存。 + +`zmalloc` 方法源码如下（源码地址：https://github.com/antirez/redis-tools/blob/master/zmalloc.c）： + +```java +void *zmalloc(size_t size) { + // 分配指定大小的内存 + void *ptr = malloc(size+PREFIX_SIZE); + if (!ptr) zmalloc_oom_handler(size); +#ifdef HAVE_MALLOC_SIZE + update_zmalloc_stat_alloc(zmalloc_size(ptr)); + return ptr; +#else + *((size_t*)ptr) = size; + update_zmalloc_stat_alloc(size+PREFIX_SIZE); + return (char*)ptr+PREFIX_SIZE; +#endif +} +``` + +另外，Redis 可以使用多种内存分配器来分配内存（ libc、jemalloc、tcmalloc），默认使用 [jemalloc](https://github.com/jemalloc/jemalloc)，而 jemalloc 按照一系列固定的大小（8 字节、16 字节、32 字节......）来分配内存的。jemalloc 划分的内存单元如下图所示： + +![jemalloc 内存单元示意图](https://img-blog.csdnimg.cn/6803d3929e3e46c1b1c9d0bb9ee8e717.png) + +当程序申请的内存最接近某个固定值时，jemalloc 会给它分配相应大小的空间，就比如说程序需要申请 17 字节的内存，jemalloc 会直接给它分配 32 字节的内存，这样会导致有 15 字节内存的浪费。不过，jemalloc 专门针对内存碎片问题做了优化，一般不会存在过度碎片化的问题。 + +**2、频繁修改 Redis 中的数据也会产生内存碎片。** + +当 Redis 中的某个数据删除时，Redis 通常不会轻易释放内存给操作系统。 + +这个在 Redis 官方文档中也有对应的原话: + +![](https://guide-blog-images.oss-cn-shenzhen.aliyuncs.com/github/javaguide/redis-docs-memory-optimization.png) + +文档地址：https://redis.io/topics/memory-optimization 。 + +## 如何查看 Redis 内存碎片的信息？ + +使用 `info memory` 命令即可查看 Redis 内存相关的信息。下图中每个参数具体的含义，Redis 官方文档有详细的介绍：https://redis.io/commands/INFO 。 + +![](https://guide-blog-images.oss-cn-shenzhen.aliyuncs.com/github/javaguide/redis-info-memory.png) + +Redis 内存碎片率的计算公式：`mem_fragmentation_ratio` （内存碎片率）= `used_memory_rss` (操作系统实际分配给 Redis 的物理内存空间大小)/ `used_memory`(Redis 内存分配器为了存储数据实际申请使用的内存空间大小) + +也就是说，`mem_fragmentation_ratio` （内存碎片率）的值越大代表内存碎片率越严重。 + +一定不要误认为`used_memory_rss` 减去 `used_memory`值就是内存碎片的大小！！！这不仅包括内存碎片，还包括其他进程开销，以及共享库、堆栈等的开销。 + +很多小伙伴可能要问了：“多大的内存碎片率才是需要清理呢？”。 + +通常情况下，我们认为 `mem_fragmentation_ratio > 1.5` 的话才需要清理内存碎片。 `mem_fragmentation_ratio > 1.5` 意味着你使用 Redis 存储实际大小 2G 的数据需要使用大于 3G 的内存。 + +如果想要快速查看内存碎片率的话，你还可以通过下面这个命令： + +```bash +> redis-cli -p 6379 info | grep mem_fragmentation_ratio +``` + +另外，内存碎片率可能存在小于 1 的情况。这种情况我在日常使用中还没有遇到过，感兴趣的小伙伴可以看看这篇文章 [故障分析 | Redis 内存碎片率太低该怎么办？- 爱可生开源社区](https://mp.weixin.qq.com/s/drlDvp7bfq5jt2M5pTqJCw) 。 + +## 如何清理 Redis 内存碎片？ + +Redis4.0-RC3 版本以后自带了内存整理，可以避免内存碎片率过大的问题。 + +直接通过 `config set` 命令将 `activedefrag` 配置项设置为 `yes` 即可。 + +```bash +config set activedefrag yes +``` + +具体什么时候清理需要通过下面两个参数控制： + +```bash +# 内存碎片占用空间达到 500mb 的时候开始清理 +config set active-defrag-ignore-bytes 500mb +# 内存碎片率大于 1.5 的时候开始清理 +config set active-defrag-threshold-lower 50 +``` + +通过 Redis 自动内存碎片清理机制可能会对 Redis 的性能产生影响，我们可以通过下面两个参数来减少对 Redis 性能的影响： + +```bash +# 内存碎片清理所占用 CPU 时间的比例不低于 20% +config set active-defrag-cycle-min 20 +# 内存碎片清理所占用 CPU 时间的比例不高于 50% +config set active-defrag-cycle-max 50 +``` + +另外，重启节点可以做到内存碎片重新整理。如果你采用的是高可用架构的 Redis 集群的话，你可以将碎片率过高的主节点转换为从节点，以便进行安全重启。 + +## 参考 + +- Redis 官方文档：https://redis.io/topics/memory-optimization +- Redis 核心技术与实战 - 极客时间 - 删除数据后，为什么内存占用率还是很高？：https://time.geekbang.org/column/article/289140 +- Redis 源码解析——内存分配：https://shinerio.cc/2020/05/17/redis/Redis%E6%BA%90%E7%A0%81%E8%A7%A3%E6%9E%90%E2%80%94%E2%80%94%E5%86%85%E5%AD%98%E7%AE%A1%E7%90%86/ \ No newline at end of file diff --git a/docs/database/redis/redis-questions-01.md b/docs/database/redis/redis-questions-01.md new file mode 100644 index 0000000000000000000000000000000000000000..238627845cd36916f521c2eb1f3124f256cad5ac --- /dev/null +++ b/docs/database/redis/redis-questions-01.md @@ -0,0 +1,872 @@ +--- +title: Redis知识点&面试题总结 +category: 数据库 +tag: + - Redis +--- + +### 简单介绍一下 Redis 呗! + +简单来说 **Redis 就是一个使用 C 语言开发的数据库**，不过与传统数据库不同的是 **Redis 的数据是存在内存中的** ，也就是它是内存数据库，所以读写速度非常快，因此 Redis 被广泛应用于缓存方向。 + +另外，**Redis 除了做缓存之外，也经常用来做分布式锁，甚至是消息队列。** + +**Redis 提供了多种数据类型来支持不同的业务场景。Redis 还支持事务 、持久化、Lua 脚本、多种集群方案。** + +### 分布式缓存常见的技术选型方案有哪些？ + +分布式缓存的话，使用的比较多的主要是 **Memcached** 和 **Redis**。不过，现在基本没有看过还有项目使用 **Memcached** 来做缓存，都是直接用 **Redis**。 + +Memcached 是分布式缓存最开始兴起的那会，比较常用的。后来，随着 Redis 的发展，大家慢慢都转而使用更加强大的 Redis 了。 + +分布式缓存主要解决的是单机缓存的容量受服务器限制并且无法保存通用信息的问题。因为，本地缓存只在当前服务里有效，比如如果你部署了两个相同的服务，他们两者之间的缓存数据是无法共同的。 + +### 说一下 Redis 和 Memcached 的区别和共同点 + +现在公司一般都是用 Redis 来实现缓存，而且 Redis 自身也越来越强大了！不过，了解 Redis 和 Memcached 的区别和共同点，有助于我们在做相应的技术选型的时候，能够做到有理有据！ + +**共同点** ： + +1. 都是基于内存的数据库，一般都用来当做缓存使用。 +2. 都有过期策略。 +3. 两者的性能都非常高。 + +**区别** ： + +1. **Redis 支持更丰富的数据类型（支持更复杂的应用场景）**。Redis 不仅仅支持简单的 k/v 类型的数据，同时还提供 list，set，zset，hash 等数据结构的存储。Memcached 只支持最简单的 k/v 数据类型。 +2. **Redis 支持数据的持久化，可以将内存中的数据保持在磁盘中，重启的时候可以再次加载进行使用,而 Memcached 把数据全部存在内存之中。** +3. **Redis 有灾难恢复机制。** 因为可以把缓存中的数据持久化到磁盘上。 +4. **Redis 在服务器内存使用完之后，可以将不用的数据放到磁盘上。但是，Memcached 在服务器内存使用完之后，就会直接报异常。** +5. **Memcached 没有原生的集群模式，需要依靠客户端来实现往集群中分片写入数据；但是 Redis 目前是原生支持 cluster 模式的。** +6. **Memcached 是多线程，非阻塞 IO 复用的网络模型；Redis 使用单线程的多路 IO 复用模型。** （Redis 6.0 引入了多线程 IO ） +7. **Redis 支持发布订阅模型、Lua 脚本、事务等功能，而 Memcached 不支持。并且，Redis 支持更多的编程语言。** +8. **Memcached 过期数据的删除策略只用了惰性删除，而 Redis 同时使用了惰性删除与定期删除。** + +相信看了上面的对比之后，我们已经没有什么理由可以选择使用 Memcached 来作为自己项目的分布式缓存了。 + +### 缓存数据的处理流程是怎样的？ + +作为暖男一号，我给大家画了一个草图。 + +![正常缓存处理流程](./images/redis-all/cache-process.png) + +简单来说就是: + +1. 如果用户请求的数据在缓存中就直接返回。 +2. 缓存中不存在的话就看数据库中是否存在。 +3. 数据库中存在的话就更新缓存中的数据。 +4. 数据库中不存在的话就返回空数据。 + +### 为什么要用 Redis/为什么要用缓存？ + +_简单，来说使用缓存主要是为了提升用户体验以及应对更多的用户。_ + +下面我们主要从“高性能”和“高并发”这两点来看待这个问题。 + +![](./images/redis-all/使用缓存之后.png) + +**高性能** ： + +对照上面 👆 我画的图。我们设想这样的场景： + +假如用户第一次访问数据库中的某些数据的话，这个过程是比较慢，毕竟是从硬盘中读取的。但是，如果说，用户访问的数据属于高频数据并且不会经常改变的话，那么我们就可以很放心地将该用户访问的数据存在缓存中。 + +**这样有什么好处呢？** 那就是保证用户下一次再访问这些数据的时候就可以直接从缓存中获取了。操作缓存就是直接操作内存，所以速度相当快。 + +不过，要保持数据库和缓存中的数据的一致性。 如果数据库中的对应数据改变的之后，同步改变缓存中相应的数据即可！ + +**高并发：** + +一般像 MySQL 这类的数据库的 QPS 大概都在 1w 左右（4 核 8g） ，但是使用 Redis 缓存之后很容易达到 10w+，甚至最高能达到 30w+（就单机 redis 的情况，redis 集群的话会更高）。 + +> QPS（Query Per Second）：服务器每秒可以执行的查询次数； + +由此可见，直接操作缓存能够承受的数据库请求数量是远远大于直接访问数据库的，所以我们可以考虑把数据库中的部分数据转移到缓存中去，这样用户的一部分请求会直接到缓存这里而不用经过数据库。进而，我们也就提高了系统整体的并发。 + +### Redis 除了做缓存，还能做什么？ + +- **分布式锁** ： 通过 Redis 来做分布式锁是一种比较常见的方式。通常情况下，我们都是基于 Redisson 来实现分布式锁。相关阅读：[《分布式锁中的王者方案 - Redisson》](https://mp.weixin.qq.com/s/CbnPRfvq4m1sqo2uKI6qQw)。 +- **限流** ：一般是通过 Redis + Lua 脚本的方式来实现限流。相关阅读：[《我司用了 6 年的 Redis 分布式限流器，可以说是非常厉害了！》](https://mp.weixin.qq.com/s/kyFAWH3mVNJvurQDt4vchA)。 +- **消息队列** ：Redis 自带的 list 数据结构可以作为一个简单的队列使用。Redis5.0 中增加的 Stream 类型的数据结构更加适合用来做消息队列。它比较类似于 Kafka，有主题和消费组的概念，支持消息持久化以及 ACK 机制。 +- **复杂业务场景** ：通过 Redis 以及 Redis 扩展（比如 Redisson）提供的数据结构，我们可以很方便地完成很多复杂的业务场景比如通过 bitmap 统计活跃用户、通过 sorted set 维护排行榜。 +- ...... + +### Redis 常见数据结构以及使用场景分析 + +你可以自己本机安装 redis 或者通过 redis 官网提供的[在线 redis 环境](https://try.redis.io/)。 + +![try-redis](./images/redis-all/try-redis.png) + +#### string + +1. **介绍** ：string 数据结构是简单的 key-value 类型。虽然 Redis 是用 C 语言写的，但是 Redis 并没有使用 C 的字符串表示，而是自己构建了一种 **简单动态字符串**（simple dynamic string，**SDS**）。相比于 C 的原生字符串，Redis 的 SDS 不光可以保存文本数据还可以保存二进制数据，并且获取字符串长度复杂度为 O(1)（C 字符串为 O(N)）,除此之外，Redis 的 SDS API 是安全的，不会造成缓冲区溢出。 +2. **常用命令：** `set,get,strlen,exists,decr,incr,setex` 等等。 +3. **应用场景：** 一般常用在需要计数的场景，比如用户的访问次数、热点文章的点赞转发数量等等。 + +下面我们简单看看它的使用！ + +**普通字符串的基本操作：** + +```bash +127.0.0.1:6379> set key value #设置 key-value 类型的值 +OK +127.0.0.1:6379> get key # 根据 key 获得对应的 value +"value" +127.0.0.1:6379> exists key # 判断某个 key 是否存在 +(integer) 1 +127.0.0.1:6379> strlen key # 返回 key 所储存的字符串值的长度。 +(integer) 5 +127.0.0.1:6379> del key # 删除某个 key 对应的值 +(integer) 1 +127.0.0.1:6379> get key +(nil) +``` + +**批量设置** : + +```bash +127.0.0.1:6379> mset key1 value1 key2 value2 # 批量设置 key-value 类型的值 +OK +127.0.0.1:6379> mget key1 key2 # 批量获取多个 key 对应的 value +1) "value1" +2) "value2" +``` + +**计数器（字符串的内容为整数的时候可以使用）：** + +```bash +127.0.0.1:6379> set number 1 +OK +127.0.0.1:6379> incr number # 将 key 中储存的数字值增一 +(integer) 2 +127.0.0.1:6379> get number +"2" +127.0.0.1:6379> decr number # 将 key 中储存的数字值减一 +(integer) 1 +127.0.0.1:6379> get number +"1" +``` + +**过期（默认为永不过期）**： + +```bash +127.0.0.1:6379> expire key 60 # 数据在 60s 后过期 +(integer) 1 +127.0.0.1:6379> setex key 60 value # 数据在 60s 后过期 (setex:[set] + [ex]pire) +OK +127.0.0.1:6379> ttl key # 查看数据还有多久过期 +(integer) 56 +``` + +#### list + +1. **介绍** ：**list** 即是 **链表**。链表是一种非常常见的数据结构，特点是易于数据元素的插入和删除并且可以灵活调整链表长度，但是链表的随机访问困难。许多高级编程语言都内置了链表的实现比如 Java 中的 **LinkedList**，但是 C 语言并没有实现链表，所以 Redis 实现了自己的链表数据结构。Redis 的 list 的实现为一个 **双向链表**，即可以支持反向查找和遍历，更方便操作，不过带来了部分额外的内存开销。 +2. **常用命令:** `rpush,lpop,lpush,rpop,lrange,llen` 等。 +3. **应用场景:** 发布与订阅或者说消息队列、慢查询。 + +下面我们简单看看它的使用！ + +**通过 `rpush/lpop` 实现队列：** + +```bash +127.0.0.1:6379> rpush myList value1 # 向 list 的头部（右边）添加元素 +(integer) 1 +127.0.0.1:6379> rpush myList value2 value3 # 向list的头部（最右边）添加多个元素 +(integer) 3 +127.0.0.1:6379> lpop myList # 将 list的尾部(最左边)元素取出 +"value1" +127.0.0.1:6379> lrange myList 0 1 # 查看对应下标的list列表， 0 为 start,1为 end +1) "value2" +2) "value3" +127.0.0.1:6379> lrange myList 0 -1 # 查看列表中的所有元素，-1表示倒数第一 +1) "value2" +2) "value3" +``` + +**通过 `rpush/rpop` 实现栈：** + +```bash +127.0.0.1:6379> rpush myList2 value1 value2 value3 +(integer) 3 +127.0.0.1:6379> rpop myList2 # 将 list的头部(最右边)元素取出 +"value3" +``` + +我专门画了一个图方便小伙伴们来理解： + +![redis list](./images/redis-all/redis-list.png) + +**通过 `lrange` 查看对应下标范围的列表元素：** + +```bash +127.0.0.1:6379> rpush myList value1 value2 value3 +(integer) 3 +127.0.0.1:6379> lrange myList 0 1 # 查看对应下标的list列表， 0 为 start,1为 end +1) "value1" +2) "value2" +127.0.0.1:6379> lrange myList 0 -1 # 查看列表中的所有元素，-1表示倒数第一 +1) "value1" +2) "value2" +3) "value3" +``` + +通过 `lrange` 命令，你可以基于 list 实现分页查询，性能非常高！ + +**通过 `llen` 查看链表长度：** + +```bash +127.0.0.1:6379> llen myList +(integer) 3 +``` + +#### hash + +1. **介绍** ：hash 类似于 JDK1.8 前的 HashMap，内部实现也差不多(数组 + 链表)。不过，Redis 的 hash 做了更多优化。另外，hash 是一个 string 类型的 field 和 value 的映射表，**特别适合用于存储对象**，后续操作的时候，你可以直接仅仅修改这个对象中的某个字段的值。 比如我们可以 hash 数据结构来存储用户信息，商品信息等等。 +2. **常用命令：** `hset,hmset,hexists,hget,hgetall,hkeys,hvals` 等。 +3. **应用场景:** 系统中对象数据的存储。 + +下面我们简单看看它的使用！ + +```bash +127.0.0.1:6379> hmset userInfoKey name "guide" description "dev" age "24" +OK +127.0.0.1:6379> hexists userInfoKey name # 查看 key 对应的 value中指定的字段是否存在。 +(integer) 1 +127.0.0.1:6379> hget userInfoKey name # 获取存储在哈希表中指定字段的值。 +"guide" +127.0.0.1:6379> hget userInfoKey age +"24" +127.0.0.1:6379> hgetall userInfoKey # 获取在哈希表中指定 key 的所有字段和值 +1) "name" +2) "guide" +3) "description" +4) "dev" +5) "age" +6) "24" +127.0.0.1:6379> hkeys userInfoKey # 获取 key 列表 +1) "name" +2) "description" +3) "age" +127.0.0.1:6379> hvals userInfoKey # 获取 value 列表 +1) "guide" +2) "dev" +3) "24" +127.0.0.1:6379> hset userInfoKey name "GuideGeGe" # 修改某个字段对应的值 +127.0.0.1:6379> hget userInfoKey name +"GuideGeGe" +``` + +#### set + +1. **介绍 ：** set 类似于 Java 中的 `HashSet` 。Redis 中的 set 类型是一种无序集合，集合中的元素没有先后顺序。当你需要存储一个列表数据，又不希望出现重复数据时，set 是一个很好的选择，并且 set 提供了判断某个成员是否在一个 set 集合内的重要接口，这个也是 list 所不能提供的。可以基于 set 轻易实现交集、并集、差集的操作。比如：你可以将一个用户所有的关注人存在一个集合中，将其所有粉丝存在一个集合。Redis 可以非常方便的实现如共同关注、共同粉丝、共同喜好等功能。这个过程也就是求交集的过程。 +2. **常用命令：** `sadd,spop,smembers,sismember,scard,sinterstore,sunion` 等。 +3. **应用场景:** 需要存放的数据不能重复以及需要获取多个数据源交集和并集等场景 + +下面我们简单看看它的使用！ + +```bash +127.0.0.1:6379> sadd mySet value1 value2 # 添加元素进去 +(integer) 2 +127.0.0.1:6379> sadd mySet value1 # 不允许有重复元素 +(integer) 0 +127.0.0.1:6379> smembers mySet # 查看 set 中所有的元素 +1) "value1" +2) "value2" +127.0.0.1:6379> scard mySet # 查看 set 的长度 +(integer) 2 +127.0.0.1:6379> sismember mySet value1 # 检查某个元素是否存在set 中，只能接收单个元素 +(integer) 1 +127.0.0.1:6379> sadd mySet2 value2 value3 +(integer) 2 +127.0.0.1:6379> sinterstore mySet3 mySet mySet2 # 获取 mySet 和 mySet2 的交集并存放在 mySet3 中 +(integer) 1 +127.0.0.1:6379> smembers mySet3 +1) "value2" +``` + +#### sorted set + +1. **介绍：** 和 set 相比，sorted set 增加了一个权重参数 score，使得集合中的元素能够按 score 进行有序排列，还可以通过 score 的范围来获取元素的列表。有点像是 Java 中 HashMap 和 TreeSet 的结合体。 +2. **常用命令：** `zadd,zcard,zscore,zrange,zrevrange,zrem` 等。 +3. **应用场景：** 需要对数据根据某个权重进行排序的场景。比如在直播系统中，实时排行信息包含直播间在线用户列表，各种礼物排行榜，弹幕消息（可以理解为按消息维度的消息排行榜）等信息。 + +```bash +127.0.0.1:6379> zadd myZset 3.0 value1 # 添加元素到 sorted set 中 3.0 为权重 +(integer) 1 +127.0.0.1:6379> zadd myZset 2.0 value2 1.0 value3 # 一次添加多个元素 +(integer) 2 +127.0.0.1:6379> zcard myZset # 查看 sorted set 中的元素数量 +(integer) 3 +127.0.0.1:6379> zscore myZset value1 # 查看某个 value 的权重 +"3" +127.0.0.1:6379> zrange myZset 0 -1 # 顺序输出某个范围区间的元素，0 -1 表示输出所有元素 +1) "value3" +2) "value2" +3) "value1" +127.0.0.1:6379> zrange myZset 0 1 # 顺序输出某个范围区间的元素，0 为 start 1 为 stop +1) "value3" +2) "value2" +127.0.0.1:6379> zrevrange myZset 0 1 # 逆序输出某个范围区间的元素，0 为 start 1 为 stop +1) "value1" +2) "value2" +``` + +#### bitmap + +1. **介绍：** bitmap 存储的是连续的二进制数字（0 和 1），通过 bitmap, 只需要一个 bit 位来表示某个元素对应的值或者状态，key 就是对应元素本身 。我们知道 8 个 bit 可以组成一个 byte，所以 bitmap 本身会极大的节省储存空间。 +2. **常用命令：** `setbit` 、`getbit` 、`bitcount`、`bitop` +3. **应用场景：** 适合需要保存状态信息（比如是否签到、是否登录...）并需要进一步对这些信息进行分析的场景。比如用户签到情况、活跃用户情况、用户行为统计（比如是否点赞过某个视频）。 + +```bash +# SETBIT 会返回之前位的值（默认是 0）这里会生成 7 个位 +127.0.0.1:6379> setbit mykey 7 1 +(integer) 0 +127.0.0.1:6379> setbit mykey 7 0 +(integer) 1 +127.0.0.1:6379> getbit mykey 7 +(integer) 0 +127.0.0.1:6379> setbit mykey 6 1 +(integer) 0 +127.0.0.1:6379> setbit mykey 8 1 +(integer) 0 +# 通过 bitcount 统计被被设置为 1 的位的数量。 +127.0.0.1:6379> bitcount mykey +(integer) 2 +``` + +针对上面提到的一些场景，这里进行进一步说明。 + +**使用场景一：用户行为分析** +很多网站为了分析你的喜好，需要研究你点赞过的内容。 + +```bash +# 记录你喜欢过 001 号小姐姐 +127.0.0.1:6379> setbit beauty_girl_001 uid 1 +``` + +**使用场景二：统计活跃用户** + +使用时间作为 key，然后用户 ID 为 offset，如果当日活跃过就设置为 1 + +那么我该如何计算某几天/月/年的活跃用户呢(暂且约定，统计时间内只要有一天在线就称为活跃)，有请下一个 redis 的命令 + +```bash +# 对一个或多个保存二进制位的字符串 key 进行位元操作，并将结果保存到 destkey 上。 +# BITOP 命令支持 AND 、 OR 、 NOT 、 XOR 这四种操作中的任意一种参数 +BITOP operation destkey key [key ...] +``` + +初始化数据： + +```bash +127.0.0.1:6379> setbit 20210308 1 1 +(integer) 0 +127.0.0.1:6379> setbit 20210308 2 1 +(integer) 0 +127.0.0.1:6379> setbit 20210309 1 1 +(integer) 0 +``` + +统计 20210308~20210309 总活跃用户数: 1 + +```bash +127.0.0.1:6379> bitop and desk1 20210308 20210309 +(integer) 1 +127.0.0.1:6379> bitcount desk1 +(integer) 1 +``` + +统计 20210308~20210309 在线活跃用户数: 2 + +```bash +127.0.0.1:6379> bitop or desk2 20210308 20210309 +(integer) 1 +127.0.0.1:6379> bitcount desk2 +(integer) 2 +``` + +**使用场景三：用户在线状态** + +对于获取或者统计用户在线状态，使用 bitmap 是一个节约空间且效率又高的一种方法。 + +只需要一个 key，然后用户 ID 为 offset，如果在线就设置为 1，不在线就设置为 0。 + +### Redis 单线程模型详解 + +**Redis 基于 Reactor 模式来设计开发了自己的一套高效的事件处理模型** （Netty 的线程模型也基于 Reactor 模式，Reactor 模式不愧是高性能 IO 的基石），这套事件处理模型对应的是 Redis 中的文件事件处理器（file event handler）。由于文件事件处理器（file event handler）是单线程方式运行的，所以我们一般都说 Redis 是单线程模型。 + +**既然是单线程，那怎么监听大量的客户端连接呢？** + +Redis 通过**IO 多路复用程序** 来监听来自客户端的大量连接（或者说是监听多个 socket），它会将感兴趣的事件及类型（读、写）注册到内核中并监听每个事件是否发生。 + +这样的好处非常明显： **I/O 多路复用技术的使用让 Redis 不需要额外创建多余的线程来监听客户端的大量连接，降低了资源的消耗**（和 NIO 中的 `Selector` 组件很像）。 + +另外， Redis 服务器是一个事件驱动程序，服务器需要处理两类事件：1. 文件事件; 2. 时间事件。 + +时间事件不需要多花时间了解，我们接触最多的还是 **文件事件**（客户端进行读取写入等操作，涉及一系列网络通信）。 + +《Redis 设计与实现》有一段话是如是介绍文件事件的，我觉得写得挺不错。 + +> Redis 基于 Reactor 模式开发了自己的网络事件处理器：这个处理器被称为文件事件处理器（file event handler）。文件事件处理器使用 I/O 多路复用（multiplexing）程序来同时监听多个套接字，并根据套接字目前执行的任务来为套接字关联不同的事件处理器。 +> +> 当被监听的套接字准备好执行连接应答（accept）、读取（read）、写入（write）、关 闭（close）等操作时，与操作相对应的文件事件就会产生，这时文件事件处理器就会调用套接字之前关联好的事件处理器来处理这些事件。 +> +> **虽然文件事件处理器以单线程方式运行，但通过使用 I/O 多路复用程序来监听多个套接字**，文件事件处理器既实现了高性能的网络通信模型，又可以很好地与 Redis 服务器中其他同样以单线程方式运行的模块进行对接，这保持了 Redis 内部单线程设计的简单性。 + +可以看出，文件事件处理器（file event handler）主要是包含 4 个部分： + +- 多个 socket（客户端连接） +- IO 多路复用程序（支持多个客户端连接的关键） +- 文件事件分派器（将 socket 关联到相应的事件处理器） +- 事件处理器（连接应答处理器、命令请求处理器、命令回复处理器） + +![](./images/redis-all/redis事件处理器.png) + +

《Redis设计与实现：12章》

+ +### Redis 没有使用多线程？为什么不使用多线程？ + +虽然说 Redis 是单线程模型，但是，实际上，**Redis 在 4.0 之后的版本中就已经加入了对多线程的支持。** + +![redis4.0 more thread](./images/redis-all/redis4.0-more-thread.png) + +不过，Redis 4.0 增加的多线程主要是针对一些大键值对的删除操作的命令，使用这些命令就会使用主处理之外的其他线程来“异步处理”。 + +大体上来说，**Redis 6.0 之前主要还是单线程处理。** + +**那，Redis6.0 之前 为什么不使用多线程？** + +我觉得主要原因有下面 3 个： + +1. 单线程编程容易并且更容易维护； +2. Redis 的性能瓶颈不在 CPU ，主要在内存和网络； +3. 多线程就会存在死锁、线程上下文切换等问题，甚至会影响性能。 + +### Redis6.0 之后为何引入了多线程？ + +**Redis6.0 引入多线程主要是为了提高网络 IO 读写性能**，因为这个算是 Redis 中的一个性能瓶颈（Redis 的瓶颈主要受限于内存和网络）。 + +虽然，Redis6.0 引入了多线程，但是 Redis 的多线程只是在网络数据的读写这类耗时操作上使用了，执行命令仍然是单线程顺序执行。因此，你也不需要担心线程安全问题。 + +Redis6.0 的多线程默认是禁用的，只使用主线程。如需开启需要修改 redis 配置文件 `redis.conf` ： + +```bash +io-threads-do-reads yes +``` + +开启多线程后，还需要设置线程数，否则是不生效的。同样需要修改 redis 配置文件 `redis.conf` : + +```bash +io-threads 4 #官网建议4核的机器建议设置为2或3个线程，8核的建议设置为6个线程 +``` + +推荐阅读： + +1. [Redis 6.0 新特性-多线程连环 13 问！](https://mp.weixin.qq.com/s/FZu3acwK6zrCBZQ_3HoUgw) +2. [为什么 Redis 选择单线程模型](https://draveness.me/whys-the-design-redis-single-thread/) + +### Redis 给缓存数据设置过期时间有啥用？ + +一般情况下，我们设置保存的缓存数据的时候都会设置一个过期时间。为什么呢？ + +因为内存是有限的，如果缓存中的所有数据都是一直保存的话，分分钟直接 Out of memory。 + +Redis 自带了给缓存数据设置过期时间的功能，比如： + +```bash +127.0.0.1:6379> exp key 60 # 数据在 60s 后过期 +(integer) 1 +127.0.0.1:6379> setex key 60 value # 数据在 60s 后过期 (setex:[set] + [ex]pire) +OK +127.0.0.1:6379> ttl key # 查看数据还有多久过期 +(integer) 56 +``` + +注意：**Redis 中除了字符串类型有自己独有设置过期时间的命令 `setex` 外，其他方法都需要依靠 `expire` 命令来设置过期时间 。另外， `persist` 命令可以移除一个键的过期时间。** + +**过期时间除了有助于缓解内存的消耗，还有什么其他用么？** + +很多时候，我们的业务场景就是需要某个数据只在某一时间段内存在，比如我们的短信验证码可能只在 1 分钟内有效，用户登录的 token 可能只在 1 天内有效。 + +如果使用传统的数据库来处理的话，一般都是自己判断过期，这样更麻烦并且性能要差很多。 + +### Redis 是如何判断数据是否过期的呢？ + +Redis 通过一个叫做过期字典（可以看作是 hash 表）来保存数据过期的时间。过期字典的键指向 Redis 数据库中的某个 key(键)，过期字典的值是一个 long long 类型的整数，这个整数保存了 key 所指向的数据库键的过期时间（毫秒精度的 UNIX 时间戳）。 + +![redis过期字典](./images/redis-all/redis过期时间.png) + +过期字典是存储在 redisDb 这个结构里的： + +```c +typedef struct redisDb { + ... + + dict *dict; //数据库键空间,保存着数据库中所有键值对 + dict *expires // 过期字典,保存着键的过期时间 + ... +} redisDb; +``` + +### 过期的数据的删除策略了解么？ + +如果假设你设置了一批 key 只能存活 1 分钟，那么 1 分钟后，Redis 是怎么对这批 key 进行删除的呢？ + +常用的过期数据的删除策略就两个（重要！自己造缓存轮子的时候需要格外考虑的东西）： + +1. **惰性删除** ：只会在取出 key 的时候才对数据进行过期检查。这样对 CPU 最友好，但是可能会造成太多过期 key 没有被删除。 +2. **定期删除** ： 每隔一段时间抽取一批 key 执行删除过期 key 操作。并且，Redis 底层会通过限制删除操作执行的时长和频率来减少删除操作对 CPU 时间的影响。 + +定期删除对内存更加友好，惰性删除对 CPU 更加友好。两者各有千秋，所以 Redis 采用的是 **定期删除+惰性/懒汉式删除** 。 + +但是，仅仅通过给 key 设置过期时间还是有问题的。因为还是可能存在定期删除和惰性删除漏掉了很多过期 key 的情况。这样就导致大量过期 key 堆积在内存里，然后就 Out of memory 了。 + +怎么解决这个问题呢？答案就是：**Redis 内存淘汰机制。** + +### Redis 内存淘汰机制了解么？ + +> 相关问题：MySQL 里有 2000w 数据，Redis 中只存 20w 的数据，如何保证 Redis 中的数据都是热点数据? + +Redis 提供 6 种数据淘汰策略： + +1. **volatile-lru（least recently used）**：从已设置过期时间的数据集（server.db[i].expires）中挑选最近最少使用的数据淘汰 +2. **volatile-ttl**：从已设置过期时间的数据集（server.db[i].expires）中挑选将要过期的数据淘汰 +3. **volatile-random**：从已设置过期时间的数据集（server.db[i].expires）中任意选择数据淘汰 +4. **allkeys-lru（least recently used）**：当内存不足以容纳新写入数据时，在键空间中，移除最近最少使用的 key（这个是最常用的） +5. **allkeys-random**：从数据集（server.db[i].dict）中任意选择数据淘汰 +6. **no-eviction**：禁止驱逐数据，也就是说当内存不足以容纳新写入数据时，新写入操作会报错。这个应该没人使用吧！ + +4.0 版本后增加以下两种： + +7. **volatile-lfu（least frequently used）**：从已设置过期时间的数据集（server.db[i].expires）中挑选最不经常使用的数据淘汰 +8. **allkeys-lfu（least frequently used）**：当内存不足以容纳新写入数据时，在键空间中，移除最不经常使用的 key + +### Redis 持久化机制(怎么保证 Redis 挂掉之后再重启数据可以进行恢复) + +很多时候我们需要持久化数据也就是将内存中的数据写入到硬盘里面，大部分原因是为了之后重用数据（比如重启机器、机器故障之后恢复数据），或者是为了防止系统故障而将数据备份到一个远程位置。 + +Redis 不同于 Memcached 的很重要一点就是，Redis 支持持久化，而且支持两种不同的持久化操作。**Redis 的一种持久化方式叫快照（snapshotting，RDB），另一种方式是只追加文件（append-only file, AOF）**。这两种方法各有千秋，下面我会详细这两种持久化方法是什么，怎么用，如何选择适合自己的持久化方法。 + +**快照（snapshotting）持久化（RDB）** + +Redis 可以通过创建快照来获得存储在内存里面的数据在某个时间点上的副本。Redis 创建快照之后，可以对快照进行备份，可以将快照复制到其他服务器从而创建具有相同数据的服务器副本（Redis 主从结构，主要用来提高 Redis 性能），还可以将快照留在原地以便重启服务器的时候使用。 + +快照持久化是 Redis 默认采用的持久化方式，在 Redis.conf 配置文件中默认有此下配置： + +```conf +save 900 1 #在900秒(15分钟)之后，如果至少有1个key发生变化，Redis就会自动触发BGSAVE命令创建快照。 + +save 300 10 #在300秒(5分钟)之后，如果至少有10个key发生变化，Redis就会自动触发BGSAVE命令创建快照。 + +save 60 10000 #在60秒(1分钟)之后，如果至少有10000个key发生变化，Redis就会自动触发BGSAVE命令创建快照。 +``` + +**AOF（append-only file）持久化** + +与快照持久化相比，AOF 持久化的实时性更好，因此已成为主流的持久化方案。默认情况下 Redis 没有开启 AOF（append only file）方式的持久化，可以通过 appendonly 参数开启： + +```conf +appendonly yes +``` + +开启 AOF 持久化后每执行一条会更改 Redis 中的数据的命令，Redis 就会将该命令写入到内存缓存 `server.aof_buf` 中，然后再根据 `appendfsync` 配置来决定何时将其同步到硬盘中的 AOF 文件。 + +AOF 文件的保存位置和 RDB 文件的位置相同，都是通过 dir 参数设置的，默认的文件名是 `appendonly.aof`。 + +在 Redis 的配置文件中存在三种不同的 AOF 持久化方式，它们分别是： + +```conf +appendfsync always #每次有数据修改发生时都会写入AOF文件,这样会严重降低Redis的速度 +appendfsync everysec #每秒钟同步一次，显式地将多个写命令同步到硬盘 +appendfsync no #让操作系统决定何时进行同步 +``` + +为了兼顾数据和写入性能，用户可以考虑 `appendfsync everysec` 选项 ，让 Redis 每秒同步一次 AOF 文件，Redis 性能几乎没受到任何影响。而且这样即使出现系统崩溃，用户最多只会丢失一秒之内产生的数据。当硬盘忙于执行写入操作的时候，Redis 还会优雅的放慢自己的速度以便适应硬盘的最大写入速度。 + +**相关 issue** ： + +- [Redis 的 AOF 方式 #783](https://github.com/Snailclimb/JavaGuide/issues/783) +- [Redis AOF 重写描述不准确 #1439](https://github.com/Snailclimb/JavaGuide/issues/1439) + +**拓展：Redis 4.0 对于持久化机制的优化** + +Redis 4.0 开始支持 RDB 和 AOF 的混合持久化（默认关闭，可以通过配置项 `aof-use-rdb-preamble` 开启）。 + +如果把混合持久化打开，AOF 重写的时候就直接把 RDB 的内容写到 AOF 文件开头。这样做的好处是可以结合 RDB 和 AOF 的优点, 快速加载同时避免丢失过多的数据。当然缺点也是有的， AOF 里面的 RDB 部分是压缩格式不再是 AOF 格式，可读性较差。 + +官方文档地址：https://redis.io/topics/persistence + +![](https://cdn.jsdelivr.net/gh/javaguide-tech/image-host-github-stars-01@main/webfunny_monitor/image-20210807145107290.png) + +**补充内容：AOF 重写** + +AOF 重写可以产生一个新的 AOF 文件，这个新的 AOF 文件和原有的 AOF 文件所保存的数据库状态一样，但体积更小。 + +AOF 重写是一个有歧义的名字，该功能是通过读取数据库中的键值对来实现的，程序无须对现有 AOF 文件进行任何读入、分析或者写入操作。 + +在执行 BGREWRITEAOF 命令时，Redis 服务器会维护一个 AOF 重写缓冲区，该缓冲区会在子进程创建新 AOF 文件期间，记录服务器执行的所有写命令。当子进程完成创建新 AOF 文件的工作之后，服务器会将重写缓冲区中的所有内容追加到新 AOF 文件的末尾，使得新的 AOF 文件保存的数据库状态与现有的数据库状态一致。最后，服务器用新的 AOF 文件替换旧的 AOF 文件，以此来完成 AOF 文件重写操作。 + +### Redis bigkey + +#### 什么是 bigkey？ + +简单来说，如果一个 key 对应的 value 所占用的内存比较大，那这个 key 就可以看作是 bigkey。具体多大才算大呢？有一个不是特别精确的参考标准：string 类型的 value 超过 10 kb，复合类型的 value 包含的元素超过 5000 个（对于复合类型的 value 来说，不一定包含的元素越多，占用的内存就越多）。 + +#### bigkey 有什么危害？ + +除了会消耗更多的内存空间，bigkey 对性能也会有比较大的影响。 + +因此，我们应该尽量避免写入 bigkey！ + +#### 如何发现 bigkey？ + +**1、使用 Redis 自带的 `--bigkeys` 参数来查找。** + +```bash +# redis-cli -p 6379 --bigkeys + +# Scanning the entire keyspace to find biggest keys as well as +# average sizes per key type. You can use -i 0.1 to sleep 0.1 sec +# per 100 SCAN commands (not usually needed). + +[00.00%] Biggest string found so far '"ballcat:oauth:refresh_auth:f6cdb384-9a9d-4f2f-af01-dc3f28057c20"' with 4437 bytes +[00.00%] Biggest list found so far '"my-list"' with 17 items + +-------- summary ------- + +Sampled 5 keys in the keyspace! +Total key length in bytes is 264 (avg len 52.80) + +Biggest list found '"my-list"' has 17 items +Biggest string found '"ballcat:oauth:refresh_auth:f6cdb384-9a9d-4f2f-af01-dc3f28057c20"' has 4437 bytes + +1 lists with 17 items (20.00% of keys, avg size 17.00) +0 hashs with 0 fields (00.00% of keys, avg size 0.00) +4 strings with 4831 bytes (80.00% of keys, avg size 1207.75) +0 streams with 0 entries (00.00% of keys, avg size 0.00) +0 sets with 0 members (00.00% of keys, avg size 0.00) +0 zsets with 0 members (00.00% of keys, avg size 0.00 +``` + +从这个命令的运行结果，我们可以看出：这个命令会扫描(Scan) Redis 中的所有 key ，会对 Redis 的性能有一点影响。并且，这种方式只能找出每种数据结构 top 1 bigkey（占用内存最大的 string 数据类型，包含元素最多的复合数据类型）。 + +**2、分析 RDB 文件** + +通过分析 RDB 文件来找出 big key。这种方案的前提是你的 Redis 采用的是 RDB 持久化。 + +网上有现成的代码/工具可以直接拿来使用： + +- [redis-rdb-tools](https://github.com/sripathikrishnan/redis-rdb-tools) ：Python 语言写的用来分析 Redis 的 RDB 快照文件用的工具 +- [rdb_bigkeys](https://github.com/weiyanwei412/rdb_bigkeys) : Go 语言写的用来分析 Redis 的 RDB 快照文件用的工具，性能更好。 + +### Redis 事务 + +Redis 可以通过 **`MULTI`，`EXEC`，`DISCARD` 和 `WATCH`** 等命令来实现事务(transaction)功能。 + +```bash +> MULTI +OK +> SET USER "Guide哥" +QUEUED +> GET USER +QUEUED +> EXEC +1) OK +2) "Guide哥" +``` + +使用 [`MULTI`](https://redis.io/commands/multi) 命令后可以输入多个命令。Redis 不会立即执行这些命令，而是将它们放到队列，当调用了 [`EXEC`](https://redis.io/commands/exec) 命令将执行所有命令。 + +这个过程是这样的： + +1. 开始事务（`MULTI`）。 +2. 命令入队(批量操作 Redis 的命令，先进先出（FIFO）的顺序执行)。 +3. 执行事务(`EXEC`)。 + +你也可以通过 [`DISCARD`](https://redis.io/commands/discard) 命令取消一个事务，它会清空事务队列中保存的所有命令。 + +```bash +> MULTI +OK +> SET USER "Guide哥" +QUEUED +> GET USER +QUEUED +> DISCARD +OK +``` + +[`WATCH`](https://redis.io/commands/watch) 命令用于监听指定的键，当调用 `EXEC` 命令执行事务时，如果一个被 `WATCH` 命令监视的键被修改的话，整个事务都不会执行，直接返回失败。 + +```bash +> WATCH USER +OK +> MULTI +> SET USER "Guide哥" +OK +> GET USER +Guide哥 +> EXEC +ERR EXEC without MULTI +``` + +Redis 官网相关介绍 [https://redis.io/topics/transactions](https://redis.io/topics/transactions) 如下： + +![redis事务](./images/redis-all/redis事务.png) + +但是，Redis 的事务和我们平时理解的关系型数据库的事务不同。我们知道事务具有四大特性： **1. 原子性**，**2. 隔离性**，**3. 持久性**，**4. 一致性**。 + +1. **原子性（Atomicity）：** 事务是最小的执行单位，不允许分割。事务的原子性确保动作要么全部完成，要么完全不起作用； +2. **隔离性（Isolation）：** 并发访问数据库时，一个用户的事务不被其他事务所干扰，各并发事务之间数据库是独立的； +3. **持久性（Durability）：** 一个事务被提交之后。它对数据库中数据的改变是持久的，即使数据库发生故障也不应该对其有任何影响。 +4. **一致性（Consistency）：** 执行事务前后，数据保持一致，多个事务对同一个数据读取的结果是相同的； + +**Redis 是不支持 roll back 的，因而不满足原子性的（而且不满足持久性）。** + +Redis 官网也解释了自己为啥不支持回滚。简单来说就是 Redis 开发者们觉得没必要支持回滚，这样更简单便捷并且性能更好。Redis 开发者觉得即使命令执行错误也应该在开发过程中就被发现而不是生产过程中。 + +![redis roll back](./images/redis-all/redis-rollBack.png) + +你可以将 Redis 中的事务就理解为 ：**Redis 事务提供了一种将多个命令请求打包的功能。然后，再按顺序执行打包的所有命令，并且不会被中途打断。** + +**相关 issue** : + +- [issue452: 关于 Redis 事务不满足原子性的问题](https://github.com/Snailclimb/JavaGuide/issues/452) 。 +- [Issue491:关于 redis 没有事务回滚？](https://github.com/Snailclimb/JavaGuide/issues/491) + +### Redis 可以做消息队列么？ + +Redis 5.0 新增加的一个数据结构 `Stream` 可以用来做消息队列，`Stream` 支持： + +- 发布 / 订阅模式 +- 按照消费者组进行消费 +- 消息持久化（ RDB 和 AOF） + +不过，和专业的消息队列相比，还是有很多欠缺的地方比如消息丢失和堆积问题不好解决。 + +我们通常建议是不需要使用 Redis 来做消息队列的，你完全可以选择市面上比较成熟的一些消息队列比如 RocketMQ、Kafka。 + +相关文章推荐：[Redis 消息队列的三种方案（List、Streams、Pub/Sub）](https://javakeeper.starfish.ink/data-management/Redis/Redis-MQ.html)。 + +### 缓存穿透 + +#### 什么是缓存穿透？ + +缓存穿透说简单点就是大量请求的 key 根本不存在于缓存中，导致请求直接到了数据库上，根本没有经过缓存这一层。举个例子：某个黑客故意制造我们缓存中不存在的 key 发起大量请求，导致大量请求落到数据库。 + +#### 缓存穿透情况的处理流程是怎样的？ + +如下图所示，用户的请求最终都要跑到数据库中查询一遍。 + +![缓存穿透情况](https://img-blog.csdnimg.cn/6358650a9bf742838441d636430c90b9.png) + + +#### 有哪些解决办法？ + +最基本的就是首先做好参数校验，一些不合法的参数请求直接抛出异常信息返回给客户端。比如查询的数据库 id 不能小于 0、传入的邮箱格式不对的时候直接返回错误消息给客户端等等。 + +**1）缓存无效 key** + +如果缓存和数据库都查不到某个 key 的数据就写一个到 Redis 中去并设置过期时间，具体命令如下： `SET key value EX 10086` 。这种方式可以解决请求的 key 变化不频繁的情况，如果黑客恶意攻击，每次构建不同的请求 key，会导致 Redis 中缓存大量无效的 key 。很明显，这种方案并不能从根本上解决此问题。如果非要用这种方式来解决穿透问题的话，尽量将无效的 key 的过期时间设置短一点比如 1 分钟。 + +另外，这里多说一嘴，一般情况下我们是这样设计 key 的： `表名:列名:主键名:主键值` 。 + +如果用 Java 代码展示的话，差不多是下面这样的： + +```java +public Object getObjectInclNullById(Integer id) { + // 从缓存中获取数据 + Object cacheValue = cache.get(id); + // 缓存为空 + if (cacheValue == null) { + // 从数据库中获取 + Object storageValue = storage.get(key); + // 缓存空对象 + cache.set(key, storageValue); + // 如果存储数据为空，需要设置一个过期时间(300秒) + if (storageValue == null) { + // 必须设置过期时间，否则有被攻击的风险 + cache.expire(key, 60 * 5); + } + return storageValue; + } + return cacheValue; +} +``` + +**2）布隆过滤器** + +布隆过滤器是一个非常神奇的数据结构，通过它我们可以非常方便地判断一个给定数据是否存在于海量数据中。我们需要的就是判断 key 是否合法，有没有感觉布隆过滤器就是我们想要找的那个“人”。 + +具体是这样做的：把所有可能存在的请求的值都存放在布隆过滤器中，当用户请求过来，先判断用户发来的请求的值是否存在于布隆过滤器中。不存在的话，直接返回请求参数错误信息给客户端，存在的话才会走下面的流程。 + +加入布隆过滤器之后的缓存处理流程图如下。 + +![](./images/redis-all/加入布隆过滤器后的缓存处理流程.png) + +但是，需要注意的是布隆过滤器可能会存在误判的情况。总结来说就是： **布隆过滤器说某个元素存在，小概率会误判。布隆过滤器说某个元素不在，那么这个元素一定不在。** + +_为什么会出现误判的情况呢? 我们还要从布隆过滤器的原理来说！_ + +我们先来看一下，**当一个元素加入布隆过滤器中的时候，会进行哪些操作：** + +1. 使用布隆过滤器中的哈希函数对元素值进行计算，得到哈希值（有几个哈希函数得到几个哈希值）。 +2. 根据得到的哈希值，在位数组中把对应下标的值置为 1。 + +我们再来看一下，**当我们需要判断一个元素是否存在于布隆过滤器的时候，会进行哪些操作：** + +1. 对给定元素再次进行相同的哈希计算； +2. 得到值之后判断位数组中的每个元素是否都为 1，如果值都为 1，那么说明这个值在布隆过滤器中，如果存在一个值不为 1，说明该元素不在布隆过滤器中。 + +然后，一定会出现这样一种情况：**不同的字符串可能哈希出来的位置相同。** （可以适当增加位数组大小或者调整我们的哈希函数来降低概率） + +更多关于布隆过滤器的内容可以看我的这篇原创：[《不了解布隆过滤器？一文给你整的明明白白！》](https://javaguide.cn/cs-basics/data-structure/bloom-filter/) ，强烈推荐，个人感觉网上应该找不到总结的这么明明白白的文章了。 + +### 缓存雪崩 + +#### 什么是缓存雪崩？ + +我发现缓存雪崩这名字起的有点意思，哈哈。 + +实际上，缓存雪崩描述的就是这样一个简单的场景：**缓存在同一时间大面积的失效，后面的请求都直接落到了数据库上，造成数据库短时间内承受大量请求。** 这就好比雪崩一样，摧枯拉朽之势，数据库的压力可想而知，可能直接就被这么多请求弄宕机了。 + +举个例子：系统的缓存模块出了问题比如宕机导致不可用。造成系统的所有访问，都要走数据库。 + +还有一种缓存雪崩的场景是：**有一些被大量访问数据（热点缓存）在某一时刻大面积失效，导致对应的请求直接落到了数据库上。** 这样的情况，有下面几种解决办法： + +举个例子 ：秒杀开始 12 个小时之前，我们统一存放了一批商品到 Redis 中，设置的缓存过期时间也是 12 个小时，那么秒杀开始的时候，这些秒杀的商品的访问直接就失效了。导致的情况就是，相应的请求直接就落到了数据库上，就像雪崩一样可怕。 + +#### 有哪些解决办法？ + +**针对 Redis 服务不可用的情况：** + +1. 采用 Redis 集群，避免单机出现问题整个缓存服务都没办法使用。 +2. 限流，避免同时处理大量的请求。 + +**针对热点缓存失效的情况：** + +1. 设置不同的失效时间比如随机设置缓存的失效时间。 +2. 缓存永不失效。 + +### 如何保证缓存和数据库数据的一致性？ + +细说的话可以扯很多，但是我觉得其实没太大必要（小声 BB：很多解决方案我也没太弄明白）。我个人觉得引入缓存之后，如果为了短时间的不一致性问题，选择让系统设计变得更加复杂的话，完全没必要。 + +下面单独对 **Cache Aside Pattern（旁路缓存模式）** 来聊聊。 + +Cache Aside Pattern 中遇到写请求是这样的：更新 DB，然后直接删除 cache 。 + +如果更新数据库成功，而删除缓存这一步失败的情况的话，简单说两个解决方案： + +1. **缓存失效时间变短（不推荐，治标不治本）** ：我们让缓存数据的过期时间变短，这样的话缓存就会从数据库中加载数据。另外，这种解决办法对于先操作缓存后操作数据库的场景不适用。 +2. **增加 cache 更新重试机制（常用）**： 如果 cache 服务当前不可用导致缓存删除失败的话，我们就隔一段时间进行重试，重试次数可以自己定。如果多次重试还是失败的话，我们可以把当前更新失败的 key 存入队列中，等缓存服务可用之后，再将缓存中对应的 key 删除即可。 + +相关文章推荐：[缓存和数据库一致性问题，看这篇就够了 - 水滴与银弹](https://mp.weixin.qq.com/s?__biz=MzIyOTYxNDI5OA==&mid=2247487312&idx=1&sn=fa19566f5729d6598155b5c676eee62d&chksm=e8beb8e5dfc931f3e35655da9da0b61c79f2843101c130cf38996446975014f958a6481aacf1&scene=178&cur_album_id=1699766580538032128#rd) + +### 参考 + +- 《Redis 开发与运维》 +- 《Redis 设计与实现》 +- Redis 命令总结：http://Redisdoc.com/string/set.html +- 通俗易懂的 Redis 数据结构基础教程：[https://juejin.im/post/5b53ee7e5188251aaa2d2e16](https://juejin.im/post/5b53ee7e5188251aaa2d2e16) +- WHY Redis choose single thread (vs multi threads): [https://medium.com/@jychen7/sharing-redis-single-thread-vs-multi-threads-5870bd44d153](https://medium.com/@jychen7/sharing-redis-single-thread-vs-multi-threads-5870bd44d153) diff --git a/docs/distributed-system/api-gateway.md b/docs/distributed-system/api-gateway.md new file mode 100644 index 0000000000000000000000000000000000000000..ac449ce337799fa6c0fa2e6c7f511a291c86eebf --- /dev/null +++ b/docs/distributed-system/api-gateway.md @@ -0,0 +1,109 @@ +--- +title: 网关 +category: 分布式 +--- + +## 何为网关？为什么要网关？ + +![微服务-网关](https://guide-blog-images.oss-cn-shenzhen.aliyuncs.com/javaguide/%E5%BE%AE%E6%9C%8D%E5%8A%A1-%E7%BD%91%E5%85%B3.png) + +微服务背景下，一个系统被拆分为多个服务，但是像安全认证，流量控制，日志，监控等功能是每个服务都需要的，没有网关的话，我们就需要在每个服务中单独实现，这使得我们做了很多重复的事情并且没有一个全局的视图来统一管理这些功能。 + +综上：**一般情况下，网关都会提供请求转发、安全认证（身份/权限认证）、流量控制、负载均衡、容灾、日志、监控这些功能。** + +上面介绍了这么多功能，实际上，网关主要做了一件事情：**请求过滤** 。 + +## 有哪些常见的网关系统？ + +### Netflix Zuul + +Zuul 是 Netflix 开发的一款提供动态路由、监控、弹性、安全的网关服务。 + +Zuul 主要通过过滤器（类似于 AOP）来过滤请求，从而实现网关必备的各种功能。 + +![Zuul架构](https://img-blog.csdnimg.cn/img_convert/865991e34f69f8cb345b4aff918e946e.png) + +我们可以自定义过滤器来处理请求，并且，Zuul 生态本身就有很多现成的过滤器供我们使用。就比如限流可以直接用国外朋友写的 [spring-cloud-zuul-ratelimit](https://github.com/marcosbarbero/spring-cloud-zuul-ratelimit) (这里只是举例说明，一般是配合 hystrix 来做限流)： + +```xml + + org.springframework.cloud + spring-cloud-starter-netflix-zuul + + + com.marcosbarbero.cloud + spring-cloud-zuul-ratelimit + 2.2.0.RELEASE + +``` + +Zuul 1.x 基于同步 IO，性能较差。Zuul 2.x 基于 Netty 实现了异步 IO，性能得到了大幅改进。 + +- Github 地址 ： https://github.com/Netflix/zuul +- 官方 Wiki ： https://github.com/Netflix/zuul/wiki + +### Spring Cloud Gateway + +SpringCloud Gateway 属于 Spring Cloud 生态系统中的网关，其诞生的目标是为了替代老牌网关 **Zuul **。准确点来说，应该是 Zuul 1.x。SpringCloud Gateway 起步要比 Zuul 2.x 更早。 + +为了提升网关的性能，SpringCloud Gateway 基于 Spring WebFlux 。Spring WebFlux 使用 Reactor 库来实现响应式编程模型，底层基于 Netty 实现异步 IO。 + +Spring Cloud Gateway 的目标，不仅提供统一的路由方式，并且基于 Filter 链的方式提供了网关基本的功能，例如：安全，监控/指标，和限流。 + +Spring Cloud Gateway 和 Zuul 2.x 的差别不大，也是通过过滤器来处理请求。不过，目前更加推荐使用 Spring Cloud Gateway 而非 Zuul，Spring Cloud 生态对其支持更加友好。 + +- Github 地址 ： https://github.com/spring-cloud/spring-cloud-gateway +- 官网 ： https://spring.io/projects/spring-cloud-gateway + +### Kong + +Kong 是一款基于 [OpenResty](https://github.com/openresty/) 的高性能、云原生、可扩展的网关系统。 + +> OpenResty 是一个基于 Nginx 与 Lua 的高性能 Web 平台，其内部集成了大量精良的 Lua 库、第三方模块以及大多数的依赖项。用于方便地搭建能够处理超高并发、扩展性极高的动态 Web 应用、Web 服务和动态网关。 + +Kong 提供了插件机制来扩展其功能。比如、在服务上启用 Zipkin 插件 + +```shell +$ curl -X POST http://kong:8001/services/{service}/plugins \ + --data "name=zipkin" \ + --data "config.http_endpoint=http://your.zipkin.collector:9411/api/v2/spans" \ + --data "config.sample_ratio=0.001" +``` + +- Github 地址： https://github.com/Kong/kong +- 官网地址 ： https://konghq.com/kong + +### APISIX + +APISIX 是一款基于 Nginx 和 etcd 的高性能、云原生、可扩展的网关系统。 + +> *etcd*是使用 Go 语言开发的一个开源的、高可用的分布式 key-value 存储系统，使用 Raft 协议做分布式共识。 + +与传统 API 网关相比，APISIX 具有动态路由和插件热加载，特别适合微服务系统下的 API 管理。并且，APISIX 与 SkyWalking（分布式链路追踪系统）、Zipkin（分布式链路追踪系统）、Prometheus（监控系统） 等 DevOps 生态工具对接都十分方便。 + +![apisix架构图](https://img-blog.csdnimg.cn/img_convert/727732fad2e943bdd2c502b83ddb1b89.png) + +作为 NGINX 和 Kong 的替代项目，APISIX 目前已经是 Apache 顶级开源项目，并且是最快毕业的国产开源项目。国内目前已经有很多知名企业（比如金山、有赞、爱奇艺、腾讯、贝壳）使用 APISIX 处理核心的业务流量。 + +根据官网介绍：“APISIX 已经生产可用，功能、性能、架构全面优于 Kong”。 + +- Github 地址 ：https://github.com/apache/apisix +- 官网地址： https://apisix.apache.org/zh/ + +相关阅读： + +- [有了 NGINX 和 Kong，为什么还需要 Apache APISIX](https://www.apiseven.com/zh/blog/why-we-need-Apache-APISIX) +- [APISIX 技术博客](https://www.apiseven.com/zh/blog) +- [APISIX 用户案例](https://www.apiseven.com/zh/usercases) + +### Shenyu + +Shenyu 是一款基于 WebFlux 的可扩展、高性能、响应式网关，Apache 顶级开源项目。 + +![Shenyu架构](https://img-blog.csdnimg.cn/1104eb413cba468cba4dce119165e84e.png) + +Shenyu 通过插件扩展功能，插件是 ShenYu 的灵魂，并且插件也是可扩展和热插拔的。不同的插件实现不同的功能。Shenyu 自带了诸如限流、熔断、转发 、重写、重定向、和路由监控等插件。 + +- Github 地址： https://github.com/apache/incubator-shenyu +- 官网地址 ： https://shenyu.apache.org/ + diff --git a/docs/distributed-system/distributed-id.md b/docs/distributed-system/distributed-id.md new file mode 100644 index 0000000000000000000000000000000000000000..97d663666b385b1aca8d26310ce72ca94ab3d55e --- /dev/null +++ b/docs/distributed-system/distributed-id.md @@ -0,0 +1,360 @@ +--- +title: 分布式 ID +category: 分布式 +--- + +## 分布式 ID 介绍 + +### 何为 ID？ + +日常开发中，我们需要对系统中的各种数据使用 ID 唯一表示，比如用户 ID 对应且仅对应一个人，商品 ID 对应且仅对应一件商品，订单 ID 对应且仅对应一个订单。 + +![](https://guide-blog-images.oss-cn-shenzhen.aliyuncs.com/javaguide/up-79beb853b8319f850638c9708f83039dfda.png) + +我们现实生活中也有各种 ID，比如身份证 ID 对应且仅对应一个人、地址 ID 对应且仅对应 + +简单来说，**ID 就是数据的唯一标识**。 + +### 何为分布式 ID？ + +分布式 ID 是分布式系统下的 ID。分布式 ID 不存在与现实生活中，属于计算机系统中的一个概念。 + +我简单举一个分库分表的例子。 + +我司的一个项目，使用的是单机 MySQL 。但是，没想到的是，项目上线一个月之后，随着使用人数越来越多，整个系统的数据量将越来越大。 + +单机 MySQL 已经没办法支撑了，需要进行分库分表（推荐 Sharding-JDBC）。 + +在分库之后， 数据遍布在不同服务器上的数据库，数据库的自增主键已经没办法满足生成的主键唯一了。**我们如何为不同的数据节点生成全局唯一主键呢？** + +![](https://oscimg.oschina.net/oscnet/up-d78d9d5362c71f4713a090baf7ec65d2b6d.png) + +这个时候就需要生成**分布式 ID**了。 + +### 分布式 ID 需要满足哪些要求? + +![](https://img-blog.csdnimg.cn/20210610082309988.png) + +分布式 ID 作为分布式系统中必不可少的一环，很多地方都要用到分布式 ID。 + +一个最基本的分布式 ID 需要满足下面这些要求： + +- **全局唯一** ：ID 的全局唯一性肯定是首先要满足的！ +- **高性能** ： 分布式 ID 的生成速度要快，对本地资源消耗要小。 +- **高可用** ：生成分布式 ID 的服务要保证可用性无限接近于 100%。 +- **方便易用** ：拿来即用，使用方便，快速接入！ + +除了这些之外，一个比较好的分布式 ID 还应保证： + +- **安全** ：ID 中不包含敏感信息。 +- **有序递增** ：如果要把 ID 存放在数据库的话，ID 的有序性可以提升数据库写入速度。并且，很多时候 ，我们还很有可能会直接通过 ID 来进行排序。 +- **有具体的业务含义** ：生成的 ID 如果能有具体的业务含义，可以让定位问题以及开发更透明化（通过 ID 就能确定是哪个业务）。 +- **独立部署** ：也就是分布式系统单独有一个发号器服务，专门用来生成分布式 ID。这样就生成 ID 的服务可以和业务相关的服务解耦。不过，这样同样带来了网络调用消耗增加的问题。总的来说，如果需要用到分布式 ID 的场景比较多的话，独立部署的发号器服务还是很有必要的。 + +## 分布式 ID 常见解决方案 + +### 数据库 + +#### 数据库主键自增 + +这种方式就比较简单直白了，就是通过关系型数据库的自增主键产生来唯一的 ID。 + +![](https://img-blog.csdnimg.cn/20210610081957287.png) + +以 MySQL 举例，我们通过下面的方式即可。 + +**1.创建一个数据库表。** + +```sql +CREATE TABLE `sequence_id` ( + `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT, + `stub` char(10) NOT NULL DEFAULT '', + PRIMARY KEY (`id`), + UNIQUE KEY `stub` (`stub`) +) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; +``` + +`stub` 字段无意义，只是为了占位，便于我们插入或者修改数据。并且，给 `stub` 字段创建了唯一索引，保证其唯一性。 + +**2.通过 `replace into` 来插入数据。** + +```java +BEGIN; +REPLACE INTO sequence_id (stub) VALUES ('stub'); +SELECT LAST_INSERT_ID(); +COMMIT; +``` + +插入数据这里，我们没有使用 `insert into` 而是使用 `replace into` 来插入数据，具体步骤是这样的： + +1)第一步： 尝试把数据插入到表中。 + +2)第二步： 如果主键或唯一索引字段出现重复数据错误而插入失败时，先从表中删除含有重复关键字值的冲突行，然后再次尝试把数据插入到表中。 + +这种方式的优缺点也比较明显： + +- **优点** ：实现起来比较简单、ID 有序递增、存储消耗空间小 +- **缺点** ： 支持的并发量不大、存在数据库单点问题（可以使用数据库集群解决，不过增加了复杂度）、ID 没有具体业务含义、安全问题（比如根据订单 ID 的递增规律就能推算出每天的订单量，商业机密啊！ ）、每次获取 ID 都要访问一次数据库（增加了对数据库的压力，获取速度也慢） + +#### 数据库号段模式 + +数据库主键自增这种模式，每次获取 ID 都要访问一次数据库，ID 需求比较大的时候，肯定是不行的。 + +如果我们可以批量获取，然后存在在内存里面，需要用到的时候，直接从内存里面拿就舒服了！这也就是我们说的 **基于数据库的号段模式来生成分布式 ID。** + +数据库的号段模式也是目前比较主流的一种分布式 ID 生成方式。像滴滴开源的[Tinyid](https://github.com/didi/tinyid/wiki/tinyid%E5%8E%9F%E7%90%86%E4%BB%8B%E7%BB%8D) 就是基于这种方式来做的。不过，TinyId 使用了双号段缓存、增加多 db 支持等方式来进一步优化。 + +以 MySQL 举例，我们通过下面的方式即可。 + +**1.创建一个数据库表。** + +```sql +CREATE TABLE `sequence_id_generator` ( + `id` int(10) NOT NULL, + `current_max_id` bigint(20) NOT NULL COMMENT '当前最大id', + `step` int(10) NOT NULL COMMENT '号段的长度', + `version` int(20) NOT NULL COMMENT '版本号', + `biz_type` int(20) NOT NULL COMMENT '业务类型', + PRIMARY KEY (`id`) +) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; +``` + +`current_max_id` 字段和`step`字段主要用于获取批量 ID，获取的批量 id 为： `current_max_id ~ current_max_id+step`。 + +![](https://img-blog.csdnimg.cn/20210610081149228.png) + +`version` 字段主要用于解决并发问题（乐观锁）,`biz_type` 主要用于表示业务类型。 + +**2.先插入一行数据。** + +```sql +INSERT INTO `sequence_id_generator` (`id`, `current_max_id`, `step`, `version`, `biz_type`) +VALUES + (1, 0, 100, 0, 101); +``` + +**3.通过 SELECT 获取指定业务下的批量唯一 ID** + +```sql +SELECT `current_max_id`, `step`,`version` FROM `sequence_id_generator` where `biz_type` = 101 +``` + +结果： + +``` +id current_max_id step version biz_type +1 0 100 1 101 +``` + +**4.不够用的话，更新之后重新 SELECT 即可。** + +```sql +UPDATE sequence_id_generator SET current_max_id = 0+100, version=version+1 WHERE version = 0 AND `biz_type` = 101 +SELECT `current_max_id`, `step`,`version` FROM `sequence_id_generator` where `biz_type` = 101 +``` + +结果： + +``` +id current_max_id step version biz_type +1 100 100 1 101 +``` + +相比于数据库主键自增的方式，**数据库的号段模式对于数据库的访问次数更少，数据库压力更小。** + +另外，为了避免单点问题，你可以从使用主从模式来提高可用性。 + +**数据库号段模式的优缺点:** + +- **优点** ：ID 有序递增、存储消耗空间小 +- **缺点** ：存在数据库单点问题（可以使用数据库集群解决，不过增加了复杂度）、ID 没有具体业务含义、安全问题（比如根据订单 ID 的递增规律就能推算出每天的订单量，商业机密啊！ ） + +#### NoSQL + +![](https://img-blog.csdnimg.cn/2021061008245858.png) + +一般情况下，NoSQL 方案使用 Redis 多一些。我们通过 Redis 的 `incr` 命令即可实现对 id 原子顺序递增。 + +```bash +127.0.0.1:6379> set sequence_id_biz_type 1 +OK +127.0.0.1:6379> incr sequence_id_biz_type +(integer) 2 +127.0.0.1:6379> get sequence_id_biz_type +"2" +``` + +为了提高可用性和并发，我们可以使用 Redis Cluster。Redis Cluster 是 Redis 官方提供的 Redis 集群解决方案（3.0+版本）。 + +除了 Redis Cluster 之外，你也可以使用开源的 Redis 集群方案[Codis](https://github.com/CodisLabs/codis) （大规模集群比如上百个节点的时候比较推荐）。 + +除了高可用和并发之外，我们知道 Redis 基于内存，我们需要持久化数据，避免重启机器或者机器故障后数据丢失。Redis 支持两种不同的持久化方式：**快照（snapshotting，RDB）**、**只追加文件（append-only file, AOF）**。 并且，Redis 4.0 开始支持 **RDB 和 AOF 的混合持久化**（默认关闭，可以通过配置项 `aof-use-rdb-preamble` 开启）。 + +关于 Redis 持久化，我这里就不过多介绍。不了解这部分内容的小伙伴，可以看看 [JavaGuide 对于 Redis 知识点的总结](https://snailclimb.gitee.io/javaguide/#/docs/database/Redis/redis-all)。 + +**Redis 方案的优缺点：** + +- **优点** ： 性能不错并且生成的 ID 是有序递增的 +- **缺点** ： 和数据库主键自增方案的缺点类似 + +除了 Redis 之外，MongoDB ObjectId 经常也会被拿来当做分布式 ID 的解决方案。 + +![](https://img-blog.csdnimg.cn/20210207103320582.png) + +MongoDB ObjectId 一共需要 12 个字节存储： + +- 0~3：时间戳 +- 3~6： 代表机器 ID +- 7~8：机器进程 ID +- 9~11 ：自增值 + +**MongoDB 方案的优缺点：** + +- **优点** ： 性能不错并且生成的 ID 是有序递增的 +- **缺点** ： 需要解决重复 ID 问题（当机器时间不对的情况下，可能导致会产生重复 ID） 、有安全性问题（ID 生成有规律性） + +### 算法 + +#### UUID + +UUID 是 Universally Unique Identifier（通用唯一标识符） 的缩写。UUID 包含 32 个 16 进制数字（8-4-4-4-12）。 + +JDK 就提供了现成的生成 UUID 的方法，一行代码就行了。 + +```java +//输出示例：cb4a9ede-fa5e-4585-b9bb-d60bce986eaa +UUID.randomUUID() +``` + +[RFC 4122](https://tools.ietf.org/html/rfc4122) 中关于 UUID 的示例是这样的： + +![](https://img-blog.csdnimg.cn/20210202110824430.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM0MzM3Mjcy,size_16,color_FFFFFF,t_70) + +我们这里重点关注一下这个 Version(版本)，不同的版本对应的 UUID 的生成规则是不同的。 + +5 种不同的 Version(版本)值分别对应的含义（参考[维基百科对于 UUID 的介绍](https://zh.wikipedia.org/wiki/%E9%80%9A%E7%94%A8%E5%94%AF%E4%B8%80%E8%AF%86%E5%88%AB%E7%A0%81)）： + +- **版本 1** : UUID 是根据时间和节点 ID（通常是 MAC 地址）生成； +- **版本 2** : UUID 是根据标识符（通常是组或用户 ID）、时间和节点 ID 生成； +- **版本 3、版本 5** : 版本 5 - 确定性 UUID 通过散列（hashing）名字空间（namespace）标识符和名称生成； +- **版本 4** : UUID 使用[随机性](https://zh.wikipedia.org/wiki/随机性)或[伪随机性](https://zh.wikipedia.org/wiki/伪随机性)生成。 + +下面是 Version 1 版本下生成的 UUID 的示例： + +![](https://img-blog.csdnimg.cn/20210202113013477.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM0MzM3Mjcy,size_16,color_FFFFFF,t_70) + +JDK 中通过 `UUID` 的 `randomUUID()` 方法生成的 UUID 的版本默认为 4。 + +```java +UUID uuid = UUID.randomUUID(); +int version = uuid.version();// 4 +``` + +另外，Variant(变体)也有 4 种不同的值，这种值分别对应不同的含义。这里就不介绍了，貌似平时也不怎么需要关注。 + +需要用到的时候，去看看维基百科对于 UUID 的 Variant(变体) 相关的介绍即可。 + +从上面的介绍中可以看出，UUID 可以保证唯一性，因为其生成规则包括 MAC 地址、时间戳、名字空间（Namespace）、随机或伪随机数、时序等元素，计算机基于这些规则生成的 UUID 是肯定不会重复的。 + +虽然，UUID 可以做到全局唯一性，但是，我们一般很少会使用它。 + +比如使用 UUID 作为 MySQL 数据库主键的时候就非常不合适： + +- 数据库主键要尽量越短越好，而 UUID 的消耗的存储空间比较大（32 个字符串，128 位）。 +- UUID 是无顺序的，InnoDB 引擎下，数据库主键的无序性会严重影响数据库性能。 + +最后，我们再简单分析一下 **UUID 的优缺点** （面试的时候可能会被问到的哦！） : + +- **优点** ：生成速度比较快、简单易用 +- **缺点** ： 存储消耗空间大（32 个字符串，128 位） 、 不安全（基于 MAC 地址生成 UUID 的算法会造成 MAC 地址泄露)、无序（非自增）、没有具体业务含义、需要解决重复 ID 问题（当机器时间不对的情况下，可能导致会产生重复 ID） + +#### Snowflake(雪花算法) + +Snowflake 是 Twitter 开源的分布式 ID 生成算法。Snowflake 由 64 bit 的二进制数字组成，这 64bit 的二进制被分成了几部分，每一部分存储的数据都有特定的含义： + +- **第 0 位**： 符号位（标识正负），始终为 0，没有用，不用管。 +- **第 1~41 位** ：一共 41 位，用来表示时间戳，单位是毫秒，可以支撑 2 ^41 毫秒（约 69 年） +- **第 42~52 位** ：一共 10 位，一般来说，前 5 位表示机房 ID，后 5 位表示机器 ID（实际项目中可以根据实际情况调整）。这样就可以区分不同集群/机房的节点。 +- **第 53~64 位** ：一共 12 位，用来表示序列号。 序列号为自增值，代表单台机器每毫秒能够产生的最大 ID 数(2^12 = 4096),也就是说单台机器每毫秒最多可以生成 4096 个 唯一 ID。 + +![](https://oscimg.oschina.net/oscnet/up-a7e54a77b5ab1d9fa16d5ae3a3c50c5aee9.png) + +如果你想要使用 Snowflake 算法的话，一般不需要你自己再造轮子。有很多基于 Snowflake 算法的开源实现比如美团 的 Leaf、百度的 UidGenerator，并且这些开源实现对原有的 Snowflake 算法进行了优化。 + +另外，在实际项目中，我们一般也会对 Snowflake 算法进行改造，最常见的就是在 Snowflake 算法生成的 ID 中加入业务类型信息。 + +我们再来看看 Snowflake 算法的优缺点 ： + +- **优点** ：生成速度比较快、生成的 ID 有序递增、比较灵活（可以对 Snowflake 算法进行简单的改造比如加入业务 ID） +- **缺点** ： 需要解决重复 ID 问题（依赖时间，当机器时间不对的情况下，可能导致会产生重复 ID）。 + +### 开源框架 + +#### UidGenerator(百度) + +[UidGenerator](https://github.com/baidu/uid-generator) 是百度开源的一款基于 Snowflake(雪花算法)的唯一 ID 生成器。 + +不过，UidGenerator 对 Snowflake(雪花算法)进行了改进，生成的唯一 ID 组成如下。 + +![](https://oscimg.oschina.net/oscnet/up-ad5b9dd0077a949db923611b2450277e406.png) + +可以看出，和原始 Snowflake(雪花算法)生成的唯一 ID 的组成不太一样。并且，上面这些参数我们都可以自定义。 + +UidGenerator 官方文档中的介绍如下： + +![](https://oscimg.oschina.net/oscnet/up-358b1a4cddb3675018b8595f66ece9cae88.png) + +自 18 年后，UidGenerator 就基本没有再维护了，我这里也不过多介绍。想要进一步了解的朋友，可以看看 [UidGenerator 的官方介绍](https://github.com/baidu/uid-generator/blob/master/README.zh_cn.md)。 + +#### Leaf(美团) + +**[Leaf](https://github.com/Meituan-Dianping/Leaf)** 是美团开源的一个分布式 ID 解决方案 。这个项目的名字 Leaf（树叶） 起源于德国哲学家、数学家莱布尼茨的一句话： “There are no two identical leaves in the world”（世界上没有两片相同的树叶） 。这名字起得真心挺不错的，有点文艺青年那味了！ + +![](https://img-blog.csdnimg.cn/20210422145229617.png) + +Leaf 提供了 **号段模式** 和 **Snowflake(雪花算法)** 这两种模式来生成分布式 ID。并且，它支持双号段，还解决了雪花 ID 系统时钟回拨问题。不过，时钟问题的解决需要弱依赖于 Zookeeper 。 + +Leaf 的诞生主要是为了解决美团各个业务线生成分布式 ID 的方法多种多样以及不可靠的问题。 + +Leaf 对原有的号段模式进行改进，比如它这里增加了双号段避免获取 DB 在获取号段的时候阻塞请求获取 ID 的线程。简单来说，就是我一个号段还没用完之前，我自己就主动提前去获取下一个号段（图片来自于美团官方文章：[《Leaf——美团点评分布式 ID 生成系统》](https://tech.meituan.com/2017/04/21/mt-leaf.html)）。 + +![](https://img-blog.csdnimg.cn/20210422144846724.png) + +根据项目 README 介绍，在 4C8G VM 基础上，通过公司 RPC 方式调用，QPS 压测结果近 5w/s，TP999 1ms。 + +#### Tinyid(滴滴) + +[Tinyid](https://github.com/didi/tinyid) 是滴滴开源的一款基于数据库号段模式的唯一 ID 生成器。 + +数据库号段模式的原理我们在上面已经介绍过了。**Tinyid 有哪些亮点呢？** + +为了搞清楚这个问题，我们先来看看基于数据库号段模式的简单架构方案。（图片来自于 Tinyid 的官方 wiki:[《Tinyid 原理介绍》](https://github.com/didi/tinyid/wiki/tinyid%E5%8E%9F%E7%90%86%E4%BB%8B%E7%BB%8D)） + +![](https://oscimg.oschina.net/oscnet/up-4afc0e45c0c86ba5ad645d023dce11e53c2.png) + +在这种架构模式下，我们通过 HTTP 请求向发号器服务申请唯一 ID。负载均衡 router 会把我们的请求送往其中的一台 tinyid-server。 + +这种方案有什么问题呢？在我看来（Tinyid 官方 wiki 也有介绍到），主要由下面这 2 个问题： + +- 获取新号段的情况下，程序获取唯一 ID 的速度比较慢。 +- 需要保证 DB 高可用，这个是比较麻烦且耗费资源的。 + +除此之外，HTTP 调用也存在网络开销。 + +Tinyid 的原理比较简单，其架构如下图所示： + +![](https://oscimg.oschina.net/oscnet/up-53f74cd615178046d6c04fe50513fee74ce.png) + +相比于基于数据库号段模式的简单架构方案，Tinyid 方案主要做了下面这些优化： + +- **双号段缓存** ：为了避免在获取新号段的情况下，程序获取唯一 ID 的速度比较慢。 Tinyid 中的号段在用到一定程度的时候，就会去异步加载下一个号段，保证内存中始终有可用号段。 +- **增加多 db 支持** ：支持多个 DB，并且，每个 DB 都能生成唯一 ID，提高了可用性。 +- **增加 tinyid-client** ：纯本地操作，无 HTTP 请求消耗，性能和可用性都有很大提升。 + +Tinyid 的优缺点这里就不分析了，结合数据库号段模式的优缺点和 Tinyid 的原理就能知道。 + +## 分布式 ID 生成方案总结 + +这篇文章中，我基本上已经把最常见的分布式 ID 生成方案都总结了一波。 + +除了上面介绍的方式之外，像 ZooKeeper 这类中间件也可以帮助我们生成唯一 ID。**没有银弹，一定要结合实际项目来选择最适合自己的方案。** diff --git a/docs/distributed-system/distributed-process-coordination/zookeeper/images/curator.png b/docs/distributed-system/distributed-process-coordination/zookeeper/images/curator.png new file mode 100644 index 0000000000000000000000000000000000000000..360993d541c37863f7791b3e83f58401dfabf28e Binary files /dev/null and b/docs/distributed-system/distributed-process-coordination/zookeeper/images/curator.png differ diff --git "a/docs/distributed-system/distributed-process-coordination/zookeeper/images/watche\346\234\272\345\210\266.png" "b/docs/distributed-system/distributed-process-coordination/zookeeper/images/watche\346\234\272\345\210\266.png" new file mode 100644 index 0000000000000000000000000000000000000000..c85c45011acba4b753ab8f44dc3c6ae04cf50dc1 Binary files /dev/null and "b/docs/distributed-system/distributed-process-coordination/zookeeper/images/watche\346\234\272\345\210\266.png" differ diff --git a/docs/distributed-system/distributed-process-coordination/zookeeper/images/znode-structure.png b/docs/distributed-system/distributed-process-coordination/zookeeper/images/znode-structure.png new file mode 100644 index 0000000000000000000000000000000000000000..0f2c9d6cc44df320ac3dcd80aa59ccdc073c8605 Binary files /dev/null and b/docs/distributed-system/distributed-process-coordination/zookeeper/images/znode-structure.png differ diff --git "a/docs/distributed-system/distributed-process-coordination/zookeeper/images/zookeeper\351\233\206\347\276\244.png" "b/docs/distributed-system/distributed-process-coordination/zookeeper/images/zookeeper\351\233\206\347\276\244.png" new file mode 100644 index 0000000000000000000000000000000000000000..e6a6e7110552cd2963e4d6517eb1792295a708e1 Binary files /dev/null and "b/docs/distributed-system/distributed-process-coordination/zookeeper/images/zookeeper\351\233\206\347\276\244.png" differ diff --git "a/docs/distributed-system/distributed-process-coordination/zookeeper/images/zookeeper\351\233\206\347\276\244\344\270\255\347\232\204\350\247\222\350\211\262.png" "b/docs/distributed-system/distributed-process-coordination/zookeeper/images/zookeeper\351\233\206\347\276\244\344\270\255\347\232\204\350\247\222\350\211\262.png" new file mode 100644 index 0000000000000000000000000000000000000000..fba78b60315439a8cb74ae843fab12516f52a296 Binary files /dev/null and "b/docs/distributed-system/distributed-process-coordination/zookeeper/images/zookeeper\351\233\206\347\276\244\344\270\255\347\232\204\350\247\222\350\211\262.png" differ diff --git "a/docs/distributed-system/distributed-process-coordination/zookeeper/images/\350\277\236\346\216\245ZooKeeper\346\234\215\345\212\241.png" "b/docs/distributed-system/distributed-process-coordination/zookeeper/images/\350\277\236\346\216\245ZooKeeper\346\234\215\345\212\241.png" new file mode 100644 index 0000000000000000000000000000000000000000..c7c37bbdd4d0534535930844ff7d414ed1b31f3b Binary files /dev/null and "b/docs/distributed-system/distributed-process-coordination/zookeeper/images/\350\277\236\346\216\245ZooKeeper\346\234\215\345\212\241.png" differ diff --git a/docs/distributed-system/distributed-process-coordination/zookeeper/zookeeper-in-action.md b/docs/distributed-system/distributed-process-coordination/zookeeper/zookeeper-in-action.md new file mode 100644 index 0000000000000000000000000000000000000000..bd150e114b8cc9e32679daa0a1775d9ea0d2096f --- /dev/null +++ b/docs/distributed-system/distributed-process-coordination/zookeeper/zookeeper-in-action.md @@ -0,0 +1,296 @@ +# ZooKeeper 实战 + +## 1. 前言 + +这篇文章简单给演示一下 ZooKeeper 常见命令的使用以及 ZooKeeper Java客户端 Curator 的基本使用。介绍到的内容都是最基本的操作，能满足日常工作的基本需要。 + +如果文章有任何需要改善和完善的地方，欢迎在评论区指出，共同进步！ + +## 2. ZooKeeper 安装和使用 + +### 2.1. 使用Docker 安装 zookeeper + +**a.使用 Docker 下载 ZooKeeper** + +```shell +docker pull zookeeper:3.5.8 +``` + +**b.运行 ZooKeeper** + +```shell +docker run -d --name zookeeper -p 2181:2181 zookeeper:3.5.8 +``` + +### 2.2. 连接 ZooKeeper 服务 + +**a.进入ZooKeeper容器中** + +先使用 `docker ps` 查看 ZooKeeper 的 ContainerID，然后使用 `docker exec -it ContainerID /bin/bash` 命令进入容器中。 + +**b.先进入 bin 目录,然后通过 `./zkCli.sh -server 127.0.0.1:2181`命令连接ZooKeeper 服务** + +```bash +root@eaf70fc620cb:/apache-zookeeper-3.5.8-bin# cd bin +``` + +如果你看到控制台成功打印出如下信息的话，说明你已经成功连接 ZooKeeper 服务。 + +![](./images/连接ZooKeeper服务.png) + +### 2.3. 常用命令演示 + +#### 2.3.1. 查看常用命令(help 命令) + +通过 `help` 命令查看 ZooKeeper 常用命令 + +#### 2.3.2. 创建节点(create 命令) + +通过 `create` 命令在根目录创建了 node1 节点，与它关联的字符串是"node1" + +```shell +[zk: 127.0.0.1:2181(CONNECTED) 34] create /node1 “node1” +``` + +通过 `create` 命令在根目录创建了 node1 节点，与它关联的内容是数字 123 + +```shell +[zk: 127.0.0.1:2181(CONNECTED) 1] create /node1/node1.1 123 +Created /node1/node1.1 +``` + +#### 2.3.3. 更新节点数据内容(set 命令) + +```shell +[zk: 127.0.0.1:2181(CONNECTED) 11] set /node1 "set node1" +``` + +#### 2.3.4. 获取节点的数据(get 命令) + +`get` 命令可以获取指定节点的数据内容和节点的状态,可以看出我们通过 `set` 命令已经将节点数据内容改为 "set node1"。 + +```shell +set node1 +cZxid = 0x47 +ctime = Sun Jan 20 10:22:59 CST 2019 +mZxid = 0x4b +mtime = Sun Jan 20 10:41:10 CST 2019 +pZxid = 0x4a +cversion = 1 +dataVersion = 1 +aclVersion = 0 +ephemeralOwner = 0x0 +dataLength = 9 +numChildren = 1 + +``` + +#### 2.3.5. 查看某个目录下的子节点(ls 命令) + +通过 `ls` 命令查看根目录下的节点 + +```shell +[zk: 127.0.0.1:2181(CONNECTED) 37] ls / +[dubbo, ZooKeeper, node1] +``` + +通过 `ls` 命令查看 node1 目录下的节点 + +```shell +[zk: 127.0.0.1:2181(CONNECTED) 5] ls /node1 +[node1.1] +``` + +ZooKeeper 中的 ls 命令和 linux 命令中的 ls 类似， 这个命令将列出绝对路径 path 下的所有子节点信息（列出 1 级，并不递归） + +#### 2.3.6. 查看节点状态(stat 命令) + +通过 `stat` 命令查看节点状态 + +```shell +[zk: 127.0.0.1:2181(CONNECTED) 10] stat /node1 +cZxid = 0x47 +ctime = Sun Jan 20 10:22:59 CST 2019 +mZxid = 0x47 +mtime = Sun Jan 20 10:22:59 CST 2019 +pZxid = 0x4a +cversion = 1 +dataVersion = 0 +aclVersion = 0 +ephemeralOwner = 0x0 +dataLength = 11 +numChildren = 1 +``` + +上面显示的一些信息比如 cversion、aclVersion、numChildren 等等，我在上面 “znode(数据节点)的结构” 这部分已经介绍到。 + +#### 2.3.7. 查看节点信息和状态(ls2 命令) + +`ls2` 命令更像是 `ls` 命令和 `stat` 命令的结合。 `ls2` 命令返回的信息包括 2 部分： + +1. 子节点列表 +2. 当前节点的 stat 信息。 + +```shell +[zk: 127.0.0.1:2181(CONNECTED) 7] ls2 /node1 +[node1.1] +cZxid = 0x47 +ctime = Sun Jan 20 10:22:59 CST 2019 +mZxid = 0x47 +mtime = Sun Jan 20 10:22:59 CST 2019 +pZxid = 0x4a +cversion = 1 +dataVersion = 0 +aclVersion = 0 +ephemeralOwner = 0x0 +dataLength = 11 +numChildren = 1 + +``` + +#### 2.3.8. 删除节点(delete 命令) + +这个命令很简单，但是需要注意的一点是如果你要删除某一个节点，那么这个节点必须无子节点才行。 + +```shell +[zk: 127.0.0.1:2181(CONNECTED) 3] delete /node1/node1.1 +``` + +在后面我会介绍到 Java 客户端 API 的使用以及开源 ZooKeeper 客户端 ZkClient 和 Curator 的使用。 + +## 3. ZooKeeper Java客户端 Curator简单使用 + +Curator 是Netflix公司开源的一套 ZooKeeper Java客户端框架，相比于 Zookeeper 自带的客户端 zookeeper 来说，Curator 的封装更加完善，各种 API 都可以比较方便地使用。 + +![](./images/curator.png) + +下面我们就来简单地演示一下 Curator 的使用吧！ + +Curator4.0+版本对ZooKeeper 3.5.x支持比较好。开始之前，请先将下面的依赖添加进你的项目。 + +```xml + + org.apache.curator + curator-framework + 4.2.0 + + + org.apache.curator + curator-recipes + 4.2.0 + +``` + +### 3.1. 连接 ZooKeeper 客户端 + +通过 `CuratorFrameworkFactory` 创建 `CuratorFramework` 对象，然后再调用 `CuratorFramework` 对象的 `start()` 方法即可！ + +```java +private static final int BASE_SLEEP_TIME = 1000; +private static final int MAX_RETRIES = 3; + +// Retry strategy. Retry 3 times, and will increase the sleep time between retries. +RetryPolicy retryPolicy = new ExponentialBackoffRetry(BASE_SLEEP_TIME, MAX_RETRIES); +CuratorFramework zkClient = CuratorFrameworkFactory.builder() + // the server to connect to (can be a server list) + .connectString("127.0.0.1:2181") + .retryPolicy(retryPolicy) + .build(); +zkClient.start(); +``` + +对于一些基本参数的说明： + +- `baseSleepTimeMs`：重试之间等待的初始时间 +- `maxRetries` ：最大重试次数 +- `connectString` ：要连接的服务器列表 +- `retryPolicy` ：重试策略 + +### 3.2. 数据节点的增删改查 + +#### 3.2.1. 创建节点 + +我们在 [ZooKeeper常见概念解读](./zookeeper-intro.md) 中介绍到，我们通常是将 znode 分为 4 大类： + +- **持久（PERSISTENT）节点** ：一旦创建就一直存在即使 ZooKeeper 集群宕机，直到将其删除。 +- **临时（EPHEMERAL）节点** ：临时节点的生命周期是与 **客户端会话（session）** 绑定的，**会话消失则节点消失** 。并且，临时节点 **只能做叶子节点** ，不能创建子节点。 +- **持久顺序（PERSISTENT_SEQUENTIAL）节点** ：除了具有持久（PERSISTENT）节点的特性之外， 子节点的名称还具有顺序性。比如 `/node1/app0000000001` 、`/node1/app0000000002` 。 +- **临时顺序（EPHEMERAL_SEQUENTIAL）节点** ：除了具备临时（EPHEMERAL）节点的特性之外，子节点的名称还具有顺序性。 + +你在使用的ZooKeeper 的时候，会发现 `CreateMode` 类中实际有 7种 znode 类型 ，但是用的最多的还是上面介绍的 4 种。 + +**a.创建持久化节点** + +你可以通过下面两种方式创建持久化的节点。 + +```java +//注意:下面的代码会报错，下文说了具体原因 +zkClient.create().forPath("/node1/00001"); +zkClient.create().withMode(CreateMode.PERSISTENT).forPath("/node1/00002"); +``` + +但是，你运行上面的代码会报错，这是因为的父节点`node1`还未创建。 + +你可以先创建父节点 `node1` ，然后再执行上面的代码就不会报错了。 + +```java +zkClient.create().forPath("/node1"); +``` + +更推荐的方式是通过下面这行代码， **`creatingParentsIfNeeded()` 可以保证父节点不存在的时候自动创建父节点，这是非常有用的。** + +```java +zkClient.create().creatingParentsIfNeeded().withMode(CreateMode.PERSISTENT).forPath("/node1/00001"); +``` + +**b.创建临时节点** + +```java +zkClient.create().creatingParentsIfNeeded().withMode(CreateMode.EPHEMERAL).forPath("/node1/00001"); +``` + +**c.创建节点并指定数据内容** + +```java +zkClient.create().creatingParentsIfNeeded().withMode(CreateMode.EPHEMERAL).forPath("/node1/00001","java".getBytes()); +zkClient.getData().forPath("/node1/00001");//获取节点的数据内容，获取到的是 byte数组 +``` + +**d.检测节点是否创建成功** + +```java +zkClient.checkExists().forPath("/node1/00001");//不为null的话，说明节点创建成功 +``` + +#### 3.2.2. 删除节点 + +**a.删除一个子节点** + +```java +zkClient.delete().forPath("/node1/00001"); +``` + +**b.删除一个节点以及其下的所有子节点** + +```java +zkClient.delete().deletingChildrenIfNeeded().forPath("/node1"); +``` + +#### 3.2.3. 获取/更新节点数据内容 + +```java +zkClient.create().creatingParentsIfNeeded().withMode(CreateMode.EPHEMERAL).forPath("/node1/00001","java".getBytes()); +zkClient.getData().forPath("/node1/00001");//获取节点的数据内容 +zkClient.setData().forPath("/node1/00001","c++".getBytes());//更新节点数据内容 +``` + +#### 3.2.4. 获取某个节点的所有子节点路径 + +```java +List childrenPaths = zkClient.getChildren().forPath("/node1"); +``` + + + + + diff --git a/docs/distributed-system/distributed-process-coordination/zookeeper/zookeeper-intro.md b/docs/distributed-system/distributed-process-coordination/zookeeper/zookeeper-intro.md new file mode 100644 index 0000000000000000000000000000000000000000..3a5e92cb15dd2d6f1039a79458ce4026319f0f02 --- /dev/null +++ b/docs/distributed-system/distributed-process-coordination/zookeeper/zookeeper-intro.md @@ -0,0 +1,280 @@ +# ZooKeeper 相关概念总结(入门) + +## 1. 前言 + +相信大家对 ZooKeeper 应该不算陌生。但是你真的了解 ZooKeeper 到底有啥用不？如果别人/面试官让你给他讲讲对于 ZooKeeper 的认识，你能回答到什么地步呢？ + +拿我自己来说吧！我本人曾经使用 Dubbo 来做分布式项目的时候，使用了 ZooKeeper 作为注册中心。为了保证分布式系统能够同步访问某个资源，我还使用 ZooKeeper 做过分布式锁。另外，我在学习 Kafka 的时候，知道 Kafka 很多功能的实现依赖了 ZooKeeper。 + +前几天，总结项目经验的时候，我突然问自己 ZooKeeper 到底是个什么东西？想了半天，脑海中只是简单的能浮现出几句话： + +1. ZooKeeper 可以被用作注册中心、分布式锁； +2. ZooKeeper 是 Hadoop 生态系统的一员； +3. 构建 ZooKeeper 集群的时候，使用的服务器最好是奇数台。 + +由此可见，我对于 ZooKeeper 的理解仅仅是停留在了表面。 + +所以，通过本文，希望带大家稍微详细的了解一下 ZooKeeper 。如果没有学过 ZooKeeper ，那么本文将会是你进入 ZooKeeper 大门的垫脚砖。如果你已经接触过 ZooKeeper ，那么本文将带你回顾一下 ZooKeeper 的一些基础概念。 + +另外，本文不光会涉及到 ZooKeeper 的一些概念，后面的文章会介绍到 ZooKeeper 常见命令的使用以及使用 Apache Curator 作为 ZooKeeper 的客户端。 + +_如果文章有任何需要改善和完善的地方，欢迎在评论区指出，共同进步！_ + +## 2. ZooKeeper 介绍 + +### 2.1. ZooKeeper 由来 + +正式介绍 ZooKeeper 之前，我们先来看看 ZooKeeper 的由来，还挺有意思的。 + +下面这段内容摘自《从 Paxos 到 ZooKeeper 》第四章第一节，推荐大家阅读一下： + +> ZooKeeper 最早起源于雅虎研究院的一个研究小组。在当时，研究人员发现，在雅虎内部很多大型系统基本都需要依赖一个类似的系统来进行分布式协调，但是这些系统往往都存在分布式单点问题。所以，雅虎的开发人员就试图开发一个通用的无单点问题的分布式协调框架，以便让开发人员将精力集中在处理业务逻辑上。 +> +> 关于“ZooKeeper”这个项目的名字，其实也有一段趣闻。在立项初期，考虑到之前内部很多项目都是使用动物的名字来命名的（例如著名的 Pig 项目),雅虎的工程师希望给这个项目也取一个动物的名字。时任研究院的首席科学家 RaghuRamakrishnan 开玩笑地说：“在这样下去，我们这儿就变成动物园了！”此话一出，大家纷纷表示就叫动物园管理员吧一一一因为各个以动物命名的分布式组件放在一起，雅虎的整个分布式系统看上去就像一个大型的动物园了，而 ZooKeeper 正好要用来进行分布式环境的协调一一于是，ZooKeeper 的名字也就由此诞生了。 + +### 2.2. ZooKeeper 概览 + +ZooKeeper 是一个开源的**分布式协调服务**，它的设计目标是将那些复杂且容易出错的分布式一致性服务封装起来，构成一个高效可靠的原语集，并以一系列简单易用的接口提供给用户使用。 + +> **原语：** 操作系统或计算机网络用语范畴。是由若干条指令组成的，用于完成一定功能的一个过程。具有不可分割性·即原语的执行必须是连续的，在执行过程中不允许被中断。 + +**ZooKeeper 为我们提供了高可用、高性能、稳定的分布式数据一致性解决方案，通常被用于实现诸如数据发布/订阅、负载均衡、命名服务、分布式协调/通知、集群管理、Master 选举、分布式锁和分布式队列等功能。** + +另外，**ZooKeeper 将数据保存在内存中，性能是非常棒的。 在“读”多于“写”的应用程序中尤其地高性能，因为“写”会导致所有的服务器间同步状态。（“读”多于“写”是协调服务的典型场景）。** + +### 2.3. ZooKeeper 特点 + +- **顺序一致性：** 从同一客户端发起的事务请求，最终将会严格地按照顺序被应用到 ZooKeeper 中去。 +- **原子性：** 所有事务请求的处理结果在整个集群中所有机器上的应用情况是一致的，也就是说，要么整个集群中所有的机器都成功应用了某一个事务，要么都没有应用。 +- **单一系统映像 ：** 无论客户端连到哪一个 ZooKeeper 服务器上，其看到的服务端数据模型都是一致的。 +- **可靠性：** 一旦一次更改请求被应用，更改的结果就会被持久化，直到被下一次更改覆盖。 + +### 2.4. ZooKeeper 典型应用场景 + +ZooKeeper 概览中，我们介绍到使用其通常被用于实现诸如数据发布/订阅、负载均衡、命名服务、分布式协调/通知、集群管理、Master 选举、分布式锁和分布式队列等功能。 + +下面选 3 个典型的应用场景来专门说说： + +1. **分布式锁** ： 通过创建唯一节点获得分布式锁，当获得锁的一方执行完相关代码或者是挂掉之后就释放锁。 +2. **命名服务** ：可以通过 ZooKeeper 的顺序节点生成全局唯一 ID +3. **数据发布/订阅** ：通过 **Watcher 机制** 可以很方便地实现数据发布/订阅。当你将数据发布到 ZooKeeper 被监听的节点上，其他机器可通过监听 ZooKeeper 上节点的变化来实现配置的动态更新。 + +实际上，这些功能的实现基本都得益于 ZooKeeper 可以保存数据的功能，但是 ZooKeeper 不适合保存大量数据，这一点需要注意。 + +### 2.5. 有哪些著名的开源项目用到了 ZooKeeper? + +1. **Kafka** : ZooKeeper 主要为 Kafka 提供 Broker 和 Topic 的注册以及多个 Partition 的负载均衡等功能。 +2. **Hbase** : ZooKeeper 为 Hbase 提供确保整个集群只有一个 Master 以及保存和提供 regionserver 状态信息（是否在线）等功能。 +3. **Hadoop** : ZooKeeper 为 Namenode 提供高可用支持。 + +## 3. ZooKeeper 重要概念解读 + +_破音：拿出小本本，下面的内容非常重要哦！_ + +### 3.1. Data model（数据模型） + +ZooKeeper 数据模型采用层次化的多叉树形结构，每个节点上都可以存储数据，这些数据可以是数字、字符串或者是二级制序列。并且。每个节点还可以拥有 N 个子节点，最上层是根节点以“/”来代表。每个数据节点在 ZooKeeper 中被称为 **znode**，它是 ZooKeeper 中数据的最小单元。并且，每个 znode 都一个唯一的路径标识。 + +强调一句：**ZooKeeper 主要是用来协调服务的，而不是用来存储业务数据的，所以不要放比较大的数据在 znode 上，ZooKeeper 给出的上限是每个结点的数据大小最大是 1M。** + +从下图可以更直观地看出：ZooKeeper 节点路径标识方式和 Unix 文件系统路径非常相似，都是由一系列使用斜杠"/"进行分割的路径表示，开发人员可以向这个节点中写入数据，也可以在节点下面创建子节点。这些操作我们后面都会介绍到。 + +![ZooKeeper 数据模型](./images/znode-structure.png) + +### 3.2. znode（数据节点） + +介绍了 ZooKeeper 树形数据模型之后，我们知道每个数据节点在 ZooKeeper 中被称为 **znode**，它是 ZooKeeper 中数据的最小单元。你要存放的数据就放在上面，是你使用 ZooKeeper 过程中经常需要接触到的一个概念。 + +#### 3.2.1. znode 4 种类型 + +我们通常是将 znode 分为 4 大类： + +- **持久（PERSISTENT）节点** ：一旦创建就一直存在即使 ZooKeeper 集群宕机，直到将其删除。 +- **临时（EPHEMERAL）节点** ：临时节点的生命周期是与 **客户端会话（session）** 绑定的，**会话消失则节点消失** 。并且，**临时节点只能做叶子节点** ，不能创建子节点。 +- **持久顺序（PERSISTENT_SEQUENTIAL）节点** ：除了具有持久（PERSISTENT）节点的特性之外， 子节点的名称还具有顺序性。比如 `/node1/app0000000001` 、`/node1/app0000000002` 。 +- **临时顺序（EPHEMERAL_SEQUENTIAL）节点** ：除了具备临时（EPHEMERAL）节点的特性之外，子节点的名称还具有顺序性。 + +#### 3.2.2. znode 数据结构 + +每个 znode 由 2 部分组成: + +- **stat** ：状态信息 +- **data** ： 节点存放的数据的具体内容 + +如下所示，我通过 get 命令来获取 根目录下的 dubbo 节点的内容。（get 命令在下面会介绍到）。 + +```shell +[zk: 127.0.0.1:2181(CONNECTED) 6] get /dubbo +# 该数据节点关联的数据内容为空 +null +# 下面是该数据节点的一些状态信息，其实就是 Stat 对象的格式化输出 +cZxid = 0x2 +ctime = Tue Nov 27 11:05:34 CST 2018 +mZxid = 0x2 +mtime = Tue Nov 27 11:05:34 CST 2018 +pZxid = 0x3 +cversion = 1 +dataVersion = 0 +aclVersion = 0 +ephemeralOwner = 0x0 +dataLength = 0 +numChildren = 1 +``` + +Stat 类中包含了一个数据节点的所有状态信息的字段，包括事务 ID-cZxid、节点创建时间-ctime 和子节点个数-numChildren 等等。 + +下面我们来看一下每个 znode 状态信息究竟代表的是什么吧！（下面的内容来源于《从 Paxos 到 ZooKeeper 分布式一致性原理与实践》，因为 Guide 确实也不是特别清楚，要学会参考资料的嘛！ ） ： + +| znode 状态信息 | 解释 | +| -------------- | ------------------------------------------------------------ | +| cZxid | create ZXID，即该数据节点被创建时的事务 id | +| ctime | create time，即该节点的创建时间 | +| mZxid | modified ZXID，即该节点最终一次更新时的事务 id | +| mtime | modified time，即该节点最后一次的更新时间 | +| pZxid | 该节点的子节点列表最后一次修改时的事务 id，只有子节点列表变更才会更新 pZxid，子节点内容变更不会更新 | +| cversion | 子节点版本号，当前节点的子节点每次变化时值增加 1 | +| dataVersion | 数据节点内容版本号，节点创建时为 0，每更新一次节点内容(不管内容有无变化)该版本号的值增加 1 | +| aclVersion | 节点的 ACL 版本号，表示该节点 ACL 信息变更次数 | +| ephemeralOwner | 创建该临时节点的会话的 sessionId；如果当前节点为持久节点，则 ephemeralOwner=0 | +| dataLength | 数据节点内容长度 | +| numChildren | 当前节点的子节点个数 | + +### 3.3. 版本（version） + +在前面我们已经提到，对应于每个 znode，ZooKeeper 都会为其维护一个叫作 **Stat** 的数据结构，Stat 中记录了这个 znode 的三个相关的版本： + +- **dataVersion** ：当前 znode 节点的版本号 +- **cversion** ： 当前 znode 子节点的版本 +- **aclVersion** ： 当前 znode 的 ACL 的版本。 + +### 3.4. ACL（权限控制） + +ZooKeeper 采用 ACL（AccessControlLists）策略来进行权限控制，类似于 UNIX 文件系统的权限控制。 + +对于 znode 操作的权限，ZooKeeper 提供了以下 5 种： + +- **CREATE** : 能创建子节点 +- **READ** ：能获取节点数据和列出其子节点 +- **WRITE** : 能设置/更新节点数据 +- **DELETE** : 能删除子节点 +- **ADMIN** : 能设置节点 ACL 的权限 + +其中尤其需要注意的是，**CREATE** 和 **DELETE** 这两种权限都是针对 **子节点** 的权限控制。 + +对于身份认证，提供了以下几种方式： + +- **world** ： 默认方式，所有用户都可无条件访问。 +- **auth** :不使用任何 id，代表任何已认证的用户。 +- **digest** :用户名:密码认证方式： _username:password_ 。 +- **ip** : 对指定 ip 进行限制。 + +### 3.5. Watcher（事件监听器） + +Watcher（事件监听器），是 ZooKeeper 中的一个很重要的特性。ZooKeeper 允许用户在指定节点上注册一些 Watcher，并且在一些特定事件触发的时候，ZooKeeper 服务端会将事件通知到感兴趣的客户端上去，该机制是 ZooKeeper 实现分布式协调服务的重要特性。 + +![watcher机制](./images/watche机制.png) + +_破音：非常有用的一个特性，都拿出小本本记好了，后面用到 ZooKeeper 基本离不开 Watcher（事件监听器）机制。_ + +### 3.6. 会话（Session） + +Session 可以看作是 ZooKeeper 服务器与客户端的之间的一个 TCP 长连接，通过这个连接，客户端能够通过心跳检测与服务器保持有效的会话，也能够向 ZooKeeper 服务器发送请求并接受响应，同时还能够通过该连接接收来自服务器的 Watcher 事件通知。 + +Session 有一个属性叫做：`sessionTimeout` ，`sessionTimeout` 代表会话的超时时间。当由于服务器压力太大、网络故障或是客户端主动断开连接等各种原因导致客户端连接断开时，只要在`sessionTimeout`规定的时间内能够重新连接上集群中任意一台服务器，那么之前创建的会话仍然有效。 + +另外，在为客户端创建会话之前，服务端首先会为每个客户端都分配一个 `sessionID`。由于 `sessionID`是 ZooKeeper 会话的一个重要标识，许多与会话相关的运行机制都是基于这个 `sessionID` 的，因此，无论是哪台服务器为客户端分配的 `sessionID`，都务必保证全局唯一。 + +## 4. ZooKeeper 集群 + +为了保证高可用，最好是以集群形态来部署 ZooKeeper，这样只要集群中大部分机器是可用的（能够容忍一定的机器故障），那么 ZooKeeper 本身仍然是可用的。通常 3 台服务器就可以构成一个 ZooKeeper 集群了。ZooKeeper 官方提供的架构图就是一个 ZooKeeper 集群整体对外提供服务。 + +![](./images/zookeeper集群.png) + +上图中每一个 Server 代表一个安装 ZooKeeper 服务的服务器。组成 ZooKeeper 服务的服务器都会在内存中维护当前的服务器状态，并且每台服务器之间都互相保持着通信。集群间通过 ZAB 协议（ZooKeeper Atomic Broadcast）来保持数据的一致性。 + +**最典型集群模式： Master/Slave 模式（主备模式）**。在这种模式中，通常 Master 服务器作为主服务器提供写服务，其他的 Slave 服务器从服务器通过异步复制的方式获取 Master 服务器最新的数据提供读服务。 + +### 4.1. ZooKeeper 集群角色 + +但是，在 ZooKeeper 中没有选择传统的 Master/Slave 概念，而是引入了 Leader、Follower 和 Observer 三种角色。如下图所示 + +![](./images/zookeeper集群中的角色.png) + +ZooKeeper 集群中的所有机器通过一个 **Leader 选举过程** 来选定一台称为 “**Leader**” 的机器，Leader 既可以为客户端提供写服务又能提供读服务。除了 Leader 外，**Follower** 和 **Observer** 都只能提供读服务。Follower 和 Observer 唯一的区别在于 Observer 机器不参与 Leader 的选举过程，也不参与写操作的“过半写成功”策略，因此 Observer 机器可以在不影响写性能的情况下提升集群的读性能。 + +| 角色 | 说明 | +| -------- | ------------------------------------------------------------ | +| Leader | 为客户端提供读和写的服务，负责投票的发起和决议，更新系统状态。 | +| Follower | 为客户端提供读服务，如果是写服务则转发给 Leader。参与选举过程中的投票。 | +| Observer | 为客户端提供读服务，如果是写服务则转发给 Leader。不参与选举过程中的投票，也不参与“过半写成功”策略。在不影响写性能的情况下提升集群的读性能。此角色于 ZooKeeper3.3 系列新增的角色。 | + +当 Leader 服务器出现网络中断、崩溃退出与重启等异常情况时，就会进入 Leader 选举过程，这个过程会选举产生新的 Leader 服务器。 + +这个过程大致是这样的： + +1. **Leader election（选举阶段）**：节点在一开始都处于选举阶段，只要有一个节点得到超半数节点的票数，它就可以当选准 leader。 +2. **Discovery（发现阶段）** ：在这个阶段，followers 跟准 leader 进行通信，同步 followers 最近接收的事务提议。 +3. **Synchronization（同步阶段）** :同步阶段主要是利用 leader 前一阶段获得的最新提议历史，同步集群中所有的副本。同步完成之后 + 准 leader 才会成为真正的 leader。 +4. **Broadcast（广播阶段）** :到了这个阶段，ZooKeeper 集群才能正式对外提供事务服务，并且 leader 可以进行消息广播。同时如果有新的节点加入，还需要对新节点进行同步。 + +### 4.2. ZooKeeper 集群中的服务器状态 + +- **LOOKING** ：寻找 Leader。 +- **LEADING** ：Leader 状态，对应的节点为 Leader。 +- **FOLLOWING** ：Follower 状态，对应的节点为 Follower。 +- **OBSERVING** ：Observer 状态，对应节点为 Observer，该节点不参与 Leader 选举。 + +### 4.3. ZooKeeper 集群为啥最好奇数台？ + +ZooKeeper 集群在宕掉几个 ZooKeeper 服务器之后，如果剩下的 ZooKeeper 服务器个数大于宕掉的个数的话整个 ZooKeeper 才依然可用。假如我们的集群中有 n 台 ZooKeeper 服务器，那么也就是剩下的服务数必须大于 n/2。先说一下结论，2n 和 2n-1 的容忍度是一样的，都是 n-1，大家可以先自己仔细想一想，这应该是一个很简单的数学问题了。 + +比如假如我们有 3 台，那么最大允许宕掉 1 台 ZooKeeper 服务器，如果我们有 4 台的的时候也同样只允许宕掉 1 台。 +假如我们有 5 台，那么最大允许宕掉 2 台 ZooKeeper 服务器，如果我们有 6 台的的时候也同样只允许宕掉 2 台。 + +综上，何必增加那一个不必要的 ZooKeeper 呢？ + +### 4.4. ZooKeeper 选举的过半机制防止脑裂 + +**何为集群脑裂？** + +对于一个集群，通常多台机器会部署在不同机房，来提高这个集群的可用性。保证可用性的同时，会发生一种机房间网络线路故障，导致机房间网络不通，而集群被割裂成几个小集群。这时候子集群各自选主导致“脑裂”的情况。 + +举例说明：比如现在有一个由 6 台服务器所组成的一个集群，部署在了 2 个机房，每个机房 3 台。正常情况下只有 1 个 leader，但是当两个机房中间网络断开的时候，每个机房的 3 台服务器都会认为另一个机房的 3 台服务器下线，而选出自己的 leader 并对外提供服务。若没有过半机制，当网络恢复的时候会发现有 2 个 leader。仿佛是 1 个大脑（leader）分散成了 2 个大脑，这就发生了脑裂现象。脑裂期间 2 个大脑都可能对外提供了服务，这将会带来数据一致性等问题。 + +**过半机制是如何防止脑裂现象产生的？** + +ZooKeeper 的过半机制导致不可能产生 2 个 leader，因为少于等于一半是不可能产生 leader 的，这就使得不论机房的机器如何分配都不可能发生脑裂。 + +## 5. ZAB 协议和 Paxos 算法 + +Paxos 算法应该可以说是 ZooKeeper 的灵魂了。但是，ZooKeeper 并没有完全采用 Paxos 算法 ，而是使用 ZAB 协议作为其保证数据一致性的核心算法。另外，在 ZooKeeper 的官方文档中也指出，ZAB 协议并不像 Paxos 算法那样，是一种通用的分布式一致性算法，它是一种特别为 Zookeeper 设计的崩溃可恢复的原子消息广播算法。 + +### 5.1. ZAB 协议介绍 + +ZAB（ZooKeeper Atomic Broadcast 原子广播） 协议是为分布式协调服务 ZooKeeper 专门设计的一种支持崩溃恢复的原子广播协议。 在 ZooKeeper 中，主要依赖 ZAB 协议来实现分布式数据一致性，基于该协议，ZooKeeper 实现了一种主备模式的系统架构来保持集群中各个副本之间的数据一致性。 + +### 5.2. ZAB 协议两种基本的模式：崩溃恢复和消息广播 + +ZAB 协议包括两种基本的模式，分别是 + +- **崩溃恢复** ：当整个服务框架在启动过程中，或是当 Leader 服务器出现网络中断、崩溃退出与重启等异常情况时，ZAB 协议就会进入恢复模式并选举产生新的 Leader 服务器。当选举产生了新的 Leader 服务器，同时集群中已经有过半的机器与该 Leader 服务器完成了状态同步之后，ZAB 协议就会退出恢复模式。其中，**所谓的状态同步是指数据同步，用来保证集群中存在过半的机器能够和 Leader 服务器的数据状态保持一致**。 +- **消息广播** ：**当集群中已经有过半的 Follower 服务器完成了和 Leader 服务器的状态同步，那么整个服务框架就可以进入消息广播模式了。** 当一台同样遵守 ZAB 协议的服务器启动后加入到集群中时，如果此时集群中已经存在一个 Leader 服务器在负责进行消息广播，那么新加入的服务器就会自觉地进入数据恢复模式：找到 Leader 所在的服务器，并与其进行数据同步，然后一起参与到消息广播流程中去。 + +关于 **ZAB 协议&Paxos 算法** 需要讲和理解的东西太多了，具体可以看下面这两篇文章： + +- [图解 Paxos 一致性协议](http://codemacro.com/2014/10/15/explain-poxos/) +- [Zookeeper ZAB 协议分析](https://dbaplus.cn/news-141-1875-1.html) + +## 6. 总结 + +1. ZooKeeper 本身就是一个分布式程序（只要半数以上节点存活，ZooKeeper 就能正常服务）。 +2. 为了保证高可用，最好是以集群形态来部署 ZooKeeper，这样只要集群中大部分机器是可用的（能够容忍一定的机器故障），那么 ZooKeeper 本身仍然是可用的。 +3. ZooKeeper 将数据保存在内存中，这也就保证了 高吞吐量和低延迟（但是内存限制了能够存储的容量不太大，此限制也是保持 znode 中存储的数据量较小的进一步原因）。 +4. ZooKeeper 是高性能的。 在“读”多于“写”的应用程序中尤其地明显，因为“写”会导致所有的服务器间同步状态。（“读”多于“写”是协调服务的典型场景。） +5. ZooKeeper 有临时节点的概念。 当创建临时节点的客户端会话一直保持活动，瞬时节点就一直存在。而当会话终结时，瞬时节点被删除。持久节点是指一旦这个 znode 被创建了，除非主动进行 znode 的移除操作，否则这个 znode 将一直保存在 ZooKeeper 上。 +6. ZooKeeper 底层其实只提供了两个功能：① 管理（存储、读取）用户程序提交的数据；② 为用户程序提供数据节点监听服务。 + +## 7. 参考 + +1. 《从 Paxos 到 ZooKeeper 分布式一致性原理与实践》 diff --git a/docs/distributed-system/distributed-process-coordination/zookeeper/zookeeper-plus.md b/docs/distributed-system/distributed-process-coordination/zookeeper/zookeeper-plus.md new file mode 100644 index 0000000000000000000000000000000000000000..19ad41e45821fea33c194d7665317c53fbe28819 --- /dev/null +++ b/docs/distributed-system/distributed-process-coordination/zookeeper/zookeeper-plus.md @@ -0,0 +1,375 @@ +# ZooKeeper 相关概念总结(进阶) + +> [FrancisQ](https://juejin.im/user/5c33853851882525ea106810) 投稿。 + +## 1. 好久不见 + +离上一篇文章的发布也快一个月了，想想已经快一个月没写东西了，其中可能有期末考试、课程设计和驾照考试，但这都不是借口！ + +一到冬天就懒的不行，望广大掘友督促我🙄🙄✍️✍️。 + +> 文章很长，先赞后看，养成习惯。❤️ 🧡 💛 💚 💙 💜 + +## 2. 什么是ZooKeeper + +`ZooKeeper` 由 `Yahoo` 开发，后来捐赠给了 `Apache` ，现已成为 `Apache` 顶级项目。`ZooKeeper` 是一个开源的分布式应用程序协调服务器，其为分布式系统提供一致性服务。其一致性是通过基于 `Paxos` 算法的 `ZAB` 协议完成的。其主要功能包括：配置维护、分布式同步、集群管理、分布式事务等。 + +![zookeeper](https://img-blog.csdnimg.cn/img_convert/7c349891b773671514a68f057b2e14f8.png) + +简单来说， `ZooKeeper` 是一个 **分布式协调服务框架** 。分布式？协调服务？这啥玩意？🤔🤔 + +其实解释到分布式这个概念的时候，我发现有些同学并不是能把 **分布式和集群 **这两个概念很好的理解透。前段时间有同学和我探讨起分布式的东西，他说分布式不就是加机器吗？一台机器不够用再加一台抗压呗。当然加机器这种说法也无可厚非，你一个分布式系统必定涉及到多个机器，但是你别忘了，计算机学科中还有一个相似的概念—— `Cluster` ，集群不也是加机器吗？但是 集群 和 分布式 其实就是两个完全不同的概念。 + +比如，我现在有一个秒杀服务，并发量太大单机系统承受不住，那我加几台服务器也 **一样** 提供秒杀服务，这个时候就是 **`Cluster` 集群** 。 + +![cluster](https://img-blog.csdnimg.cn/img_convert/ffcb080eb66f242ffcd8d2047a7f46aa.png) + +但是，我现在换一种方式，我将一个秒杀服务 **拆分成多个子服务** ，比如创建订单服务，增加积分服务，扣优惠券服务等等，**然后我将这些子服务都部署在不同的服务器上** ，这个时候就是 **`Distributed` 分布式** 。 + +![distributed](https://img-blog.csdnimg.cn/img_convert/07191f38aa947b0075e5c0a6a019a11d.png) + +而我为什么反驳同学所说的分布式就是加机器呢？因为我认为加机器更加适用于构建集群，因为它真是只有加机器。而对于分布式来说，你首先需要将业务进行拆分，然后再加机器（不仅仅是加机器那么简单），同时你还要去解决分布式带来的一系列问题。 + +![](https://img-blog.csdnimg.cn/img_convert/2b2fbc21abfb3f6547a2121f28c6d00f.png) + +比如各个分布式组件如何协调起来，如何减少各个系统之间的耦合度，分布式事务的处理，如何去配置整个分布式系统等等。`ZooKeeper` 主要就是解决这些问题的。 + +## 3. 一致性问题 + +设计一个分布式系统必定会遇到一个问题—— **因为分区容忍性（partition tolerance）的存在，就必定要求我们需要在系统可用性（availability）和数据一致性（consistency）中做出权衡** 。这就是著名的 `CAP` 定理。 + +理解起来其实很简单，比如说把一个班级作为整个系统，而学生是系统中的一个个独立的子系统。这个时候班里的小红小明偷偷谈恋爱被班里的大嘴巴小花发现了，小花欣喜若狂告诉了周围的人，然后小红小明谈恋爱的消息在班级里传播起来了。当在消息的传播（散布）过程中，你抓到一个同学问他们的情况，如果回答你不知道，那么说明整个班级系统出现了数据不一致的问题（因为小花已经知道这个消息了）。而如果他直接不回答你，因为整个班级有消息在进行传播（为了保证一致性，需要所有人都知道才可提供服务），这个时候就出现了系统的可用性问题。 + +![](https://img-blog.csdnimg.cn/img_convert/34ffff41f6ca4f221ca9d9ad6f0b5470.png) + +而上述前者就是 `Eureka` 的处理方式，它保证了AP（可用性），后者就是我们今天所要讲的 `ZooKeeper` 的处理方式，它保证了CP（数据一致性）。 + +## 4. 一致性协议和算法 + +而为了解决数据一致性问题，在科学家和程序员的不断探索中，就出现了很多的一致性协议和算法。比如 2PC（两阶段提交），3PC（三阶段提交），Paxos算法等等。 + +这时候请你思考一个问题，同学之间如果采用传纸条的方式去传播消息，那么就会出现一个问题——我咋知道我的小纸条有没有传到我想要传递的那个人手中呢？万一被哪个小家伙给劫持篡改了呢，对吧？ + +![](https://img-blog.csdnimg.cn/img_convert/b0e01fe3213dcc1535c31298ba9bdfbc.png) + +这个时候就引申出一个概念—— **拜占庭将军问题** 。它意指 **在不可靠信道上试图通过消息传递的方式达到一致性是不可能的**， 所以所有的一致性算法的 **必要前提** 就是安全可靠的消息通道。 + +而为什么要去解决数据一致性的问题？你想想，如果一个秒杀系统将服务拆分成了下订单和加积分服务，这两个服务部署在不同的机器上了，万一在消息的传播过程中积分系统宕机了，总不能你这边下了订单却没加积分吧？你总得保证两边的数据需要一致吧？ + +### 4.1. 2PC（两阶段提交） + +两阶段提交是一种保证分布式系统数据一致性的协议，现在很多数据库都是采用的两阶段提交协议来完成 **分布式事务** 的处理。 + +在介绍2PC之前，我们先来想想分布式事务到底有什么问题呢？ + +还拿秒杀系统的下订单和加积分两个系统来举例吧（我想你们可能都吐了🤮🤮🤮），我们此时下完订单会发个消息给积分系统告诉它下面该增加积分了。如果我们仅仅是发送一个消息也不收回复，那么我们的订单系统怎么能知道积分系统的收到消息的情况呢？如果我们增加一个收回复的过程，那么当积分系统收到消息后返回给订单系统一个 `Response` ，但在中间出现了网络波动，那个回复消息没有发送成功，订单系统是不是以为积分系统消息接收失败了？它是不是会回滚事务？但此时积分系统是成功收到消息的，它就会去处理消息然后给用户增加积分，这个时候就会出现积分加了但是订单没下成功。 + +所以我们所需要解决的是在分布式系统中，整个调用链中，我们所有服务的数据处理要么都成功要么都失败，即所有服务的 **原子性问题** 。 + +在两阶段提交中，主要涉及到两个角色，分别是协调者和参与者。 + +第一阶段：当要执行一个分布式事务的时候，事务发起者首先向协调者发起事务请求，然后协调者会给所有参与者发送 `prepare` 请求（其中包括事务内容）告诉参与者你们需要执行事务了，如果能执行我发的事务内容那么就先执行但不提交，执行后请给我回复。然后参与者收到 `prepare` 消息后，他们会开始执行事务（但不提交），并将 `Undo` 和 `Redo` 信息记入事务日志中，之后参与者就向协调者反馈是否准备好了。 + +第二阶段：第二阶段主要是协调者根据参与者反馈的情况来决定接下来是否可以进行事务的提交操作，即提交事务或者回滚事务。 + +比如这个时候 **所有的参与者** 都返回了准备好了的消息，这个时候就进行事务的提交，协调者此时会给所有的参与者发送 **`Commit` 请求** ，当参与者收到 `Commit` 请求的时候会执行前面执行的事务的 **提交操作** ，提交完毕之后将给协调者发送提交成功的响应。 + +而如果在第一阶段并不是所有参与者都返回了准备好了的消息，那么此时协调者将会给所有参与者发送 **回滚事务的 `rollback` 请求**，参与者收到之后将会 **回滚它在第一阶段所做的事务处理** ，然后再将处理情况返回给协调者，最终协调者收到响应后便给事务发起者返回处理失败的结果。 + +![2PC流程](https://img-blog.csdnimg.cn/img_convert/7ce4e40b68d625676bb42c29efce046a.png) + +个人觉得 2PC 实现得还是比较鸡肋的，因为事实上它只解决了各个事务的原子性问题，随之也带来了很多的问题。 + +![](https://img-blog.csdnimg.cn/img_convert/9af1ad68517561a8e9f5d3455a32132d.png) + +* **单点故障问题**，如果协调者挂了那么整个系统都处于不可用的状态了。 +* **阻塞问题**，即当协调者发送 `prepare` 请求，参与者收到之后如果能处理那么它将会进行事务的处理但并不提交，这个时候会一直占用着资源不释放，如果此时协调者挂了，那么这些资源都不会再释放了，这会极大影响性能。 +* **数据不一致问题**，比如当第二阶段，协调者只发送了一部分的 `commit` 请求就挂了，那么也就意味着，收到消息的参与者会进行事务的提交，而后面没收到的则不会进行事务提交，那么这时候就会产生数据不一致性问题。 + +### 4.2. 3PC（三阶段提交） + +因为2PC存在的一系列问题，比如单点，容错机制缺陷等等，从而产生了 **3PC（三阶段提交）** 。那么这三阶段又分别是什么呢？ + +> 千万不要吧PC理解成个人电脑了，其实他们是 phase-commit 的缩写，即阶段提交。 + +1. **CanCommit阶段**：协调者向所有参与者发送 `CanCommit` 请求，参与者收到请求后会根据自身情况查看是否能执行事务，如果可以则返回 YES 响应并进入预备状态，否则返回 NO 。 +2. **PreCommit阶段**：协调者根据参与者返回的响应来决定是否可以进行下面的 `PreCommit` 操作。如果上面参与者返回的都是 YES，那么协调者将向所有参与者发送 `PreCommit` 预提交请求，**参与者收到预提交请求后，会进行事务的执行操作，并将 `Undo` 和 `Redo` 信息写入事务日志中** ，最后如果参与者顺利执行了事务则给协调者返回成功的响应。如果在第一阶段协调者收到了 **任何一个 NO** 的信息，或者 **在一定时间内** 并没有收到全部的参与者的响应，那么就会中断事务，它会向所有参与者发送中断请求（abort），参与者收到中断请求之后会立即中断事务，或者在一定时间内没有收到协调者的请求，它也会中断事务。 +3. **DoCommit阶段**：这个阶段其实和 `2PC` 的第二阶段差不多，如果协调者收到了所有参与者在 `PreCommit` 阶段的 YES 响应，那么协调者将会给所有参与者发送 `DoCommit` 请求，**参与者收到 `DoCommit` 请求后则会进行事务的提交工作**，完成后则会给协调者返回响应，协调者收到所有参与者返回的事务提交成功的响应之后则完成事务。若协调者在 `PreCommit` 阶段 **收到了任何一个 NO 或者在一定时间内没有收到所有参与者的响应** ，那么就会进行中断请求的发送，参与者收到中断请求后则会 **通过上面记录的回滚日志** 来进行事务的回滚操作，并向协调者反馈回滚状况，协调者收到参与者返回的消息后，中断事务。 + +![3PC流程](https://img-blog.csdnimg.cn/img_convert/d0b44361c746593f70a6e42c298b413a.png) + +> 这里是 `3PC` 在成功的环境下的流程图，你可以看到 `3PC` 在很多地方进行了超时中断的处理，比如协调者在指定时间内为收到全部的确认消息则进行事务中断的处理，这样能 **减少同步阻塞的时间** 。还有需要注意的是，**`3PC` 在 `DoCommit` 阶段参与者如未收到协调者发送的提交事务的请求，它会在一定时间内进行事务的提交**。为什么这么做呢？是因为这个时候我们肯定**保证了在第一阶段所有的协调者全部返回了可以执行事务的响应**，这个时候我们有理由**相信其他系统都能进行事务的执行和提交**，所以**不管**协调者有没有发消息给参与者，进入第三阶段参与者都会进行事务的提交操作。 + +总之，`3PC` 通过一系列的超时机制很好的缓解了阻塞问题，但是最重要的一致性并没有得到根本的解决，比如在 `PreCommit` 阶段，当一个参与者收到了请求之后其他参与者和协调者挂了或者出现了网络分区，这个时候收到消息的参与者都会进行事务提交，这就会出现数据不一致性问题。 + +所以，要解决一致性问题还需要靠 `Paxos` 算法⭐️ ⭐️ ⭐️ 。 + +### 4.3. `Paxos` 算法 + +`Paxos` 算法是基于**消息传递且具有高度容错特性的一致性算法**，是目前公认的解决分布式一致性问题最有效的算法之一，**其解决的问题就是在分布式系统中如何就某个值（决议）达成一致** 。 + +在 `Paxos` 中主要有三个角色，分别为 `Proposer提案者`、`Acceptor表决者`、`Learner学习者`。`Paxos` 算法和 `2PC` 一样，也有两个阶段，分别为 `Prepare` 和 `accept` 阶段。 + +#### 4.3.1. prepare 阶段 + +* `Proposer提案者`：负责提出 `proposal`，每个提案者在提出提案时都会首先获取到一个 **具有全局唯一性的、递增的提案编号N**，即在整个集群中是唯一的编号 N，然后将该编号赋予其要提出的提案，在**第一阶段是只将提案编号发送给所有的表决者**。 +* `Acceptor表决者`：每个表决者在 `accept` 某提案后，会将该提案编号N记录在本地，这样每个表决者中保存的已经被 accept 的提案中会存在一个**编号最大的提案**，其编号假设为 `maxN`。每个表决者仅会 `accept` 编号大于自己本地 `maxN` 的提案，在批准提案时表决者会将以前接受过的最大编号的提案作为响应反馈给 `Proposer` 。 + +> 下面是 `prepare` 阶段的流程图，你可以对照着参考一下。 + +![paxos第一阶段](https://img-blog.csdnimg.cn/img_convert/22e8d512d954676bdf0cc92d200af8ef.png) + +#### 4.3.2. accept 阶段 + +当一个提案被 `Proposer` 提出后，如果 `Proposer` 收到了超过半数的 `Acceptor` 的批准（`Proposer` 本身同意），那么此时 `Proposer` 会给所有的 `Acceptor` 发送真正的提案（你可以理解为第一阶段为试探），这个时候 `Proposer` 就会发送提案的内容和提案编号。 + +表决者收到提案请求后会再次比较本身已经批准过的最大提案编号和该提案编号，如果该提案编号 **大于等于** 已经批准过的最大提案编号，那么就 `accept` 该提案（此时执行提案内容但不提交），随后将情况返回给 `Proposer` 。如果不满足则不回应或者返回 NO 。 + +![paxos第二阶段1](https://img-blog.csdnimg.cn/img_convert/b82536f956f70a584c6a20c10113f225.png) + +当 `Proposer` 收到超过半数的 `accept` ，那么它这个时候会向所有的 `acceptor` 发送提案的提交请求。需要注意的是，因为上述仅仅是超过半数的 `acceptor` 批准执行了该提案内容，其他没有批准的并没有执行该提案内容，所以这个时候需要**向未批准的 `acceptor` 发送提案内容和提案编号并让它无条件执行和提交**，而对于前面已经批准过该提案的 `acceptor` 来说 **仅仅需要发送该提案的编号** ，让 `acceptor` 执行提交就行了。 + +![paxos第二阶段2](https://img-blog.csdnimg.cn/img_convert/743889b97485fdfe2094e5ef0af6b141.png) + +而如果 `Proposer` 如果没有收到超过半数的 `accept` 那么它将会将 **递增** 该 `Proposal` 的编号，然后 **重新进入 `Prepare` 阶段** 。 + +> 对于 `Learner` 来说如何去学习 `Acceptor` 批准的提案内容，这有很多方式，读者可以自己去了解一下，这里不做过多解释。 + +#### 4.3.3. `paxos` 算法的死循环问题 + +其实就有点类似于两个人吵架，小明说我是对的，小红说我才是对的，两个人据理力争的谁也不让谁🤬🤬。 + +比如说，此时提案者 P1 提出一个方案 M1，完成了 `Prepare` 阶段的工作，这个时候 `acceptor` 则批准了 M1，但是此时提案者 P2 同时也提出了一个方案 M2，它也完成了 `Prepare` 阶段的工作。然后 P1 的方案已经不能在第二阶段被批准了（因为 `acceptor` 已经批准了比 M1 更大的 M2），所以 P1 自增方案变为 M3 重新进入 `Prepare` 阶段，然后 `acceptor` ，又批准了新的 M3 方案，它又不能批准 M2 了，这个时候 M2 又自增进入 `Prepare` 阶段。。。 + +就这样无休无止的永远提案下去，这就是 `paxos` 算法的死循环问题。 + +![](https://img-blog.csdnimg.cn/img_convert/72ccf65cdc107346ff2a1a881d296a2b.png) + +那么如何解决呢？很简单，人多了容易吵架，我现在 **就允许一个能提案** 就行了。 + +## 5. 引出 `ZAB` + +### 5.1. `Zookeeper` 架构 + +作为一个优秀高效且可靠的分布式协调框架，`ZooKeeper` 在解决分布式数据一致性问题时并没有直接使用 `Paxos` ，而是专门定制了一致性协议叫做 `ZAB(ZooKeeper Atomic Broadcast)` 原子广播协议，该协议能够很好地支持 **崩溃恢复** 。 + +![Zookeeper架构](https://img-blog.csdnimg.cn/img_convert/0c38d08ea026e25bf3849cc7654a4e79.png) + +### 5.2. `ZAB` 中的三个角色 + +和介绍 `Paxos` 一样，在介绍 `ZAB` 协议之前，我们首先来了解一下在 `ZAB` 中三个主要的角色，`Leader 领导者`、`Follower跟随者`、`Observer观察者` 。 + +* `Leader` ：集群中 **唯一的写请求处理者** ，能够发起投票（投票也是为了进行写请求）。 +* `Follower`：能够接收客户端的请求，如果是读请求则可以自己处理，**如果是写请求则要转发给 `Leader`** 。在选举过程中会参与投票，**有选举权和被选举权** 。 +* `Observer` ：就是没有选举权和被选举权的 `Follower` 。 + +在 `ZAB` 协议中对 `zkServer`(即上面我们说的三个角色的总称) 还有两种模式的定义，分别是 **消息广播** 和 **崩溃恢复** 。 + +### 5.3. 消息广播模式 + +说白了就是 `ZAB` 协议是如何处理写请求的，上面我们不是说只有 `Leader` 能处理写请求嘛？那么我们的 `Follower` 和 `Observer` 是不是也需要 **同步更新数据** 呢？总不能数据只在 `Leader` 中更新了，其他角色都没有得到更新吧？ + +不就是 **在整个集群中保持数据的一致性** 嘛？如果是你，你会怎么做呢？ + +![](https://img-blog.csdnimg.cn/img_convert/e6064aea729dcc2d927d5d81c4797e74.png) + +废话，第一步肯定需要 `Leader` 将写请求 **广播** 出去呀，让 `Leader` 问问 `Followers` 是否同意更新，如果超过半数以上的同意那么就进行 `Follower` 和 `Observer` 的更新（和 `Paxos` 一样）。当然这么说有点虚，画张图理解一下。 + +![消息广播](https://img-blog.csdnimg.cn/img_convert/08ccce48190fe4edcbcbb223d6231876.png) + +嗯。。。看起来很简单，貌似懂了🤥🤥🤥。这两个 `Queue` 哪冒出来的？答案是 **`ZAB` 需要让 `Follower` 和 `Observer` 保证顺序性** 。何为顺序性，比如我现在有一个写请求A，此时 `Leader` 将请求A广播出去，因为只需要半数同意就行，所以可能这个时候有一个 `Follower` F1因为网络原因没有收到，而 `Leader` 又广播了一个请求B，因为网络原因，F1竟然先收到了请求B然后才收到了请求A，这个时候请求处理的顺序不同就会导致数据的不同，从而 **产生数据不一致问题** 。 + +所以在 `Leader` 这端，它为每个其他的 `zkServer` 准备了一个 **队列** ，采用先进先出的方式发送消息。由于协议是 **通过 `TCP` **来进行网络通信的，保证了消息的发送顺序性，接受顺序性也得到了保证。 + +除此之外，在 `ZAB` 中还定义了一个 **全局单调递增的事务ID `ZXID`** ，它是一个64位long型，其中高32位表示 `epoch` 年代，低32位表示事务id。`epoch` 是会根据 `Leader` 的变化而变化的，当一个 `Leader` 挂了，新的 `Leader` 上位的时候，年代（`epoch`）就变了。而低32位可以简单理解为递增的事务id。 + +定义这个的原因也是为了顺序性，每个 `proposal` 在 `Leader` 中生成后需要 **通过其 `ZXID` 来进行排序** ，才能得到处理。 + +### 5.4. 崩溃恢复模式 + +说到崩溃恢复我们首先要提到 `ZAB` 中的 `Leader` 选举算法，当系统出现崩溃影响最大应该是 `Leader` 的崩溃，因为我们只有一个 `Leader` ，所以当 `Leader` 出现问题的时候我们势必需要重新选举 `Leader` 。 + +`Leader` 选举可以分为两个不同的阶段，第一个是我们提到的 `Leader` 宕机需要重新选举，第二则是当 `Zookeeper` 启动时需要进行系统的 `Leader` 初始化选举。下面我先来介绍一下 `ZAB` 是如何进行初始化选举的。 + +假设我们集群中有3台机器，那也就意味着我们需要两台以上同意（超过半数）。比如这个时候我们启动了 `server1` ，它会首先 **投票给自己** ，投票内容为服务器的 `myid` 和 `ZXID` ，因为初始化所以 `ZXID` 都为0，此时 `server1` 发出的投票为 (1,0)。但此时 `server1` 的投票仅为1，所以不能作为 `Leader` ，此时还在选举阶段所以整个集群处于 **`Looking` 状态**。 + +接着 `server2` 启动了，它首先也会将投票选给自己(2,0)，并将投票信息广播出去（`server1`也会，只是它那时没有其他的服务器了），`server1` 在收到 `server2` 的投票信息后会将投票信息与自己的作比较。**首先它会比较 `ZXID` ，`ZXID` 大的优先为 `Leader`，如果相同则比较 `myid`，`myid` 大的优先作为 `Leader`**。所以此时`server1` 发现 `server2` 更适合做 `Leader`，它就会将自己的投票信息更改为(2,0)然后再广播出去，之后`server2` 收到之后发现和自己的一样无需做更改，并且自己的 **投票已经超过半数** ，则 **确定 `server2` 为 `Leader`**，`server1` 也会将自己服务器设置为 `Following` 变为 `Follower`。整个服务器就从 `Looking` 变为了正常状态。 + +当 `server3` 启动发现集群没有处于 `Looking` 状态时，它会直接以 `Follower` 的身份加入集群。 + +还是前面三个 `server` 的例子，如果在整个集群运行的过程中 `server2` 挂了，那么整个集群会如何重新选举 `Leader` 呢？其实和初始化选举差不多。 + +首先毫无疑问的是剩下的两个 `Follower` 会将自己的状态 **从 `Following` 变为 `Looking` 状态** ，然后每个 `server` 会向初始化投票一样首先给自己投票（这不过这里的 `zxid` 可能不是0了，这里为了方便随便取个数字）。 + +假设 `server1` 给自己投票为(1,99)，然后广播给其他 `server`，`server3` 首先也会给自己投票(3,95)，然后也广播给其他 `server`。`server1` 和 `server3` 此时会收到彼此的投票信息，和一开始选举一样，他们也会比较自己的投票和收到的投票（`zxid` 大的优先，如果相同那么就 `myid` 大的优先）。这个时候 `server1` 收到了 `server3` 的投票发现没自己的合适故不变，`server3` 收到 `server1` 的投票结果后发现比自己的合适于是更改投票为(1,99)然后广播出去，最后 `server1` 收到了发现自己的投票已经超过半数就把自己设为 `Leader`，`server3` 也随之变为 `Follower`。 + +> 请注意 `ZooKeeper` 为什么要设置奇数个结点？比如这里我们是三个，挂了一个我们还能正常工作，挂了两个我们就不能正常工作了（已经没有超过半数的节点数了，所以无法进行投票等操作了）。而假设我们现在有四个，挂了一个也能工作，**但是挂了两个也不能正常工作了**，这是和三个一样的，而三个比四个还少一个，带来的效益是一样的，所以 `Zookeeper` 推荐奇数个 `server` 。 + +那么说完了 `ZAB` 中的 `Leader` 选举方式之后我们再来了解一下 **崩溃恢复** 是什么玩意？ + +其实主要就是 **当集群中有机器挂了，我们整个集群如何保证数据一致性？** + +如果只是 `Follower` 挂了，而且挂的没超过半数的时候，因为我们一开始讲了在 `Leader` 中会维护队列，所以不用担心后面的数据没接收到导致数据不一致性。 + +如果 `Leader` 挂了那就麻烦了，我们肯定需要先暂停服务变为 `Looking` 状态然后进行 `Leader` 的重新选举（上面我讲过了），但这个就要分为两种情况了，分别是 **确保已经被Leader提交的提案最终能够被所有的Follower提交** 和 **跳过那些已经被丢弃的提案** 。 + +确保已经被Leader提交的提案最终能够被所有的Follower提交是什么意思呢？ + +假设 `Leader (server2)` 发送 `commit` 请求（忘了请看上面的消息广播模式），他发送给了 `server3`，然后要发给 `server1` 的时候突然挂了。这个时候重新选举的时候我们如果把 `server1` 作为 `Leader` 的话，那么肯定会产生数据不一致性，因为 `server3` 肯定会提交刚刚 `server2` 发送的 `commit` 请求的提案，而 `server1` 根本没收到所以会丢弃。 + +![崩溃恢复](https://img-blog.csdnimg.cn/img_convert/ffcb12c6fb2bad76ac7105696655e85c.png) + +那怎么解决呢？ + +聪明的同学肯定会质疑，**这个时候 `server1` 已经不可能成为 `Leader` 了，因为 `server1` 和 `server3` 进行投票选举的时候会比较 `ZXID` ，而此时 `server3` 的 `ZXID` 肯定比 `server1` 的大了**。(不理解可以看前面的选举算法) + +那么跳过那些已经被丢弃的提案又是什么意思呢？ + +假设 `Leader (server2)` 此时同意了提案N1，自身提交了这个事务并且要发送给所有 `Follower` 要 `commit` 的请求，却在这个时候挂了，此时肯定要重新进行 `Leader` 的选举，比如说此时选 `server1` 为 `Leader` （这无所谓）。但是过了一会，这个 **挂掉的 `Leader` 又重新恢复了** ，此时它肯定会作为 `Follower` 的身份进入集群中，需要注意的是刚刚 `server2` 已经同意提交了提案N1，但其他 `server` 并没有收到它的 `commit` 信息，所以其他 `server` 不可能再提交这个提案N1了，这样就会出现数据不一致性问题了，所以 **该提案N1最终需要被抛弃掉** 。 + +![崩溃恢复](https://img-blog.csdnimg.cn/img_convert/abb6efc7d4df9c82b162cbecb129a6e3.png) + +## 6. Zookeeper的几个理论知识 + +了解了 `ZAB` 协议还不够，它仅仅是 `Zookeeper` 内部实现的一种方式，而我们如何通过 `Zookeeper` 去做一些典型的应用场景呢？比如说集群管理，分布式锁，`Master` 选举等等。 + +这就涉及到如何使用 `Zookeeper` 了，但在使用之前我们还需要掌握几个概念。比如 `Zookeeper` 的 **数据模型** 、**会话机制**、**ACL**、**Watcher机制** 等等。 + +### 6.1. 数据模型 + +`zookeeper` 数据存储结构与标准的 `Unix` 文件系统非常相似，都是在根节点下挂很多子节点(树型)。但是 `zookeeper` 中没有文件系统中目录与文件的概念，而是 **使用了 `znode` 作为数据节点** 。`znode` 是 `zookeeper` 中的最小数据单元，每个 `znode` 上都可以保存数据，同时还可以挂载子节点，形成一个树形化命名空间。 + +![zk数据模型](https://img-blog.csdnimg.cn/img_convert/8f35dba8c44c4a10d81e3395df971ce7.png) + +每个 `znode` 都有自己所属的 **节点类型** 和 **节点状态**。 + +其中节点类型可以分为 **持久节点**、**持久顺序节点**、**临时节点** 和 **临时顺序节点**。 + +* 持久节点：一旦创建就一直存在，直到将其删除。 +* 持久顺序节点：一个父节点可以为其子节点 **维护一个创建的先后顺序** ，这个顺序体现在 **节点名称** 上，是节点名称后自动添加一个由 10 位数字组成的数字串，从 0 开始计数。 +* 临时节点：临时节点的生命周期是与 **客户端会话** 绑定的，**会话消失则节点消失** 。临时节点 **只能做叶子节点** ，不能创建子节点。 +* 临时顺序节点：父节点可以创建一个维持了顺序的临时节点(和前面的持久顺序性节点一样)。 + +节点状态中包含了很多节点的属性比如 `czxid` 、`mzxid` 等等，在 `zookeeper` 中是使用 `Stat` 这个类来维护的。下面我列举一些属性解释。 + +* `czxid`：`Created ZXID`，该数据节点被 **创建** 时的事务ID。 +* `mzxid`：`Modified ZXID`，节点 **最后一次被更新时** 的事务ID。 +* `ctime`：`Created Time`，该节点被创建的时间。 +* `mtime`： `Modified Time`，该节点最后一次被修改的时间。 +* `version`：节点的版本号。 +* `cversion`：**子节点** 的版本号。 +* `aversion`：节点的 `ACL` 版本号。 +* `ephemeralOwner`：创建该节点的会话的 `sessionID` ，如果该节点为持久节点，该值为0。 +* `dataLength`：节点数据内容的长度。 +* `numChildre`：该节点的子节点个数，如果为临时节点为0。 +* `pzxid`：该节点子节点列表最后一次被修改时的事务ID，注意是子节点的 **列表** ，不是内容。 + +### 6.2. 会话 + +我想这个对于后端开发的朋友肯定不陌生，不就是 `session` 吗？只不过 `zk` 客户端和服务端是通过 **`TCP` 长连接** 维持的会话机制，其实对于会话来说你可以理解为 **保持连接状态** 。 + +在 `zookeeper` 中，会话还有对应的事件，比如 `CONNECTION_LOSS 连接丢失事件` 、`SESSION_MOVED 会话转移事件` 、`SESSION_EXPIRED 会话超时失效事件` 。 + +### 6.3. ACL + +`ACL` 为 `Access Control Lists` ，它是一种权限控制。在 `zookeeper` 中定义了5种权限，它们分别为： + +* `CREATE` ：创建子节点的权限。 +* `READ`：获取节点数据和子节点列表的权限。 +* `WRITE`：更新节点数据的权限。 +* `DELETE`：删除子节点的权限。 +* `ADMIN`：设置节点 ACL 的权限。 + +### 6.4. Watcher机制 + +`Watcher` 为事件监听器，是 `zk` 非常重要的一个特性，很多功能都依赖于它，它有点类似于订阅的方式，即客户端向服务端 **注册** 指定的 `watcher` ，当服务端符合了 `watcher` 的某些事件或要求则会 **向客户端发送事件通知** ，客户端收到通知后找到自己定义的 `Watcher` 然后 **执行相应的回调方法** 。 + +![watcher机制](https://img-blog.csdnimg.cn/img_convert/241ab8cc37571034fa984322b753c7ba.png) + +## 7. Zookeeper的几个典型应用场景 + +前面说了这么多的理论知识，你可能听得一头雾水，这些玩意有啥用？能干啥事？别急，听我慢慢道来。 + +![](https://img-blog.csdnimg.cn/img_convert/9c9bd2a892e23e0b7582370c50117d8c.png) + +### 7.1. 选主 + +还记得上面我们的所说的临时节点吗？因为 `Zookeeper` 的强一致性，能够很好地在保证 **在高并发的情况下保证节点创建的全局唯一性** (即无法重复创建同样的节点)。 + +利用这个特性，我们可以 **让多个客户端创建一个指定的节点** ，创建成功的就是 `master`。 + +但是，如果这个 `master` 挂了怎么办？？？ + +你想想为什么我们要创建临时节点？还记得临时节点的生命周期吗？`master` 挂了是不是代表会话断了？会话断了是不是意味着这个节点没了？还记得 `watcher` 吗？我们是不是可以 **让其他不是 `master` 的节点监听节点的状态** ，比如说我们监听这个临时节点的父节点，如果子节点个数变了就代表 `master` 挂了，这个时候我们 **触发回调函数进行重新选举** ，或者我们直接监听节点的状态，我们可以通过节点是否已经失去连接来判断 `master` 是否挂了等等。 + +![选主](https://img-blog.csdnimg.cn/img_convert/a94707028c5581c815f72fba0f50f43a.png) + +总的来说，我们可以完全 **利用 临时节点、节点状态 和 `watcher` 来实现选主的功能**，临时节点主要用来选举，节点状态和`watcher` 可以用来判断 `master` 的活性和进行重新选举。 + +### 7.2. 分布式锁 + +分布式锁的实现方式有很多种，比如 `Redis` 、数据库 、`zookeeper` 等。个人认为 `zookeeper` 在实现分布式锁这方面是非常非常简单的。 + +上面我们已经提到过了 **zk在高并发的情况下保证节点创建的全局唯一性**，这玩意一看就知道能干啥了。实现互斥锁呗，又因为能在分布式的情况下，所以能实现分布式锁呗。 + +如何实现呢？这玩意其实跟选主基本一样，我们也可以利用临时节点的创建来实现。 + +首先肯定是如何获取锁，因为创建节点的唯一性，我们可以让多个客户端同时创建一个临时节点，**创建成功的就说明获取到了锁** 。然后没有获取到锁的客户端也像上面选主的非主节点创建一个 `watcher` 进行节点状态的监听，如果这个互斥锁被释放了（可能获取锁的客户端宕机了，或者那个客户端主动释放了锁）可以调用回调函数重新获得锁。 + +> `zk` 中不需要向 `redis` 那样考虑锁得不到释放的问题了，因为当客户端挂了，节点也挂了，锁也释放了。是不是很简单？ + +那能不能使用 `zookeeper` 同时实现 **共享锁和独占锁** 呢？答案是可以的，不过稍微有点复杂而已。 + +还记得 **有序的节点** 吗？ + +这个时候我规定所有创建节点必须有序，当你是读请求（要获取共享锁）的话，如果 **没有比自己更小的节点，或比自己小的节点都是读请求** ，则可以获取到读锁，然后就可以开始读了。**若比自己小的节点中有写请求** ，则当前客户端无法获取到读锁，只能等待前面的写请求完成。 + +如果你是写请求（获取独占锁），若 **没有比自己更小的节点** ，则表示当前客户端可以直接获取到写锁，对数据进行修改。若发现 **有比自己更小的节点，无论是读操作还是写操作，当前客户端都无法获取到写锁** ，等待所有前面的操作完成。 + +这就很好地同时实现了共享锁和独占锁，当然还有优化的地方，比如当一个锁得到释放它会通知所有等待的客户端从而造成 **羊群效应** 。此时你可以通过让等待的节点只监听他们前面的节点。 + +具体怎么做呢？其实也很简单，你可以让 **读请求监听比自己小的最后一个写请求节点，写请求只监听比自己小的最后一个节点** ，感兴趣的小伙伴可以自己去研究一下。 + +### 7.3. 命名服务 + +如何给一个对象设置ID，大家可能都会想到 `UUID`，但是 `UUID` 最大的问题就在于它太长了。。。(太长不一定是好事，嘿嘿嘿)。那么在条件允许的情况下，我们能不能使用 `zookeeper` 来实现呢？ + +我们之前提到过 `zookeeper` 是通过 **树形结构** 来存储数据节点的，那也就是说，对于每个节点的 **全路径**，它必定是唯一的，我们可以使用节点的全路径作为命名方式了。而且更重要的是，路径是我们可以自己定义的，这对于我们对有些有语意的对象的ID设置可以更加便于理解。 + +### 7.4. 集群管理和注册中心 + +看到这里是不是觉得 `zookeeper` 实在是太强大了，它怎么能这么能干！ + +别急，它能干的事情还很多呢。可能我们会有这样的需求，我们需要了解整个集群中有多少机器在工作，我们想对集群中的每台机器的运行时状态进行数据采集，对集群中机器进行上下线操作等等。 + +而 `zookeeper` 天然支持的 `watcher` 和 临时节点能很好的实现这些需求。我们可以为每条机器创建临时节点，并监控其父节点，如果子节点列表有变动（我们可能创建删除了临时节点），那么我们可以使用在其父节点绑定的 `watcher` 进行状态监控和回调。 + +![集群管理](https://img-blog.csdnimg.cn/img_convert/6115820219c35c68bcb2c9a855ebace3.png) + +至于注册中心也很简单，我们同样也是让 **服务提供者** 在 `zookeeper` 中创建一个临时节点并且将自己的 `ip、port、调用方式` 写入节点，当 **服务消费者** 需要进行调用的时候会 **通过注册中心找到相应的服务的地址列表(IP端口什么的)** ，并缓存到本地(方便以后调用)，当消费者调用服务时，不会再去请求注册中心，而是直接通过负载均衡算法从地址列表中取一个服务提供者的服务器调用服务。 + +当服务提供者的某台服务器宕机或下线时，相应的地址会从服务提供者地址列表中移除。同时，注册中心会将新的服务地址列表发送给服务消费者的机器并缓存在消费者本机（当然你可以让消费者进行节点监听，我记得 `Eureka` 会先试错，然后再更新）。 + +![注册中心](https://img-blog.csdnimg.cn/img_convert/0b5b3911a7c2dae23391d17c91416b29.png) + +## 8. 总结 + +看到这里的同学实在是太有耐心了👍👍👍，如果觉得我写得不错的话点个赞哈。 + +不知道大家是否还记得我讲了什么😒。 + +![](https://img-blog.csdnimg.cn/img_convert/b0bde9f3979b8f19187e6c374ad98993.png) + +这篇文章中我带大家入门了 `zookeeper` 这个强大的分布式协调框架。现在我们来简单梳理一下整篇文章的内容。 + +* 分布式与集群的区别 + +* `2PC` 、`3PC` 以及 `paxos` 算法这些一致性框架的原理和实现。 + +* `zookeeper` 专门的一致性算法 `ZAB` 原子广播协议的内容（`Leader` 选举、崩溃恢复、消息广播）。 + +* `zookeeper` 中的一些基本概念，比如 `ACL`，数据节点，会话，`watcher`机制等等。 + +* `zookeeper` 的典型应用场景，比如选主，注册中心等等。 + + 如果忘了可以回去看看再次理解一下，如果有疑问和建议欢迎提出🤝🤝🤝。 diff --git a/docs/distributed-system/distributed-transaction.md b/docs/distributed-system/distributed-transaction.md new file mode 100644 index 0000000000000000000000000000000000000000..c020c89ecd8e984304a62a713414c0b7ac9763a1 --- /dev/null +++ b/docs/distributed-system/distributed-transaction.md @@ -0,0 +1,23 @@ +--- +title: 分布式事务 +category: 分布式 +--- + +分布式事务相关的面试题为我的[知识星球](https://www.yuque.com/docs/share/8a30ffb5-83f3-40f9-baf9-38de68b906dc)专属内容，已经整理到了[《Java 面试指北》](https://www.yuque.com/docs/share/f37fc804-bfe6-4b0d-b373-9c462188fec7)中。 + +《Java 面试指北》的部分内容展示如下，你可以将其看作是 [JavaGuide](https://javaguide.cn/#/) 的补充完善，两者可以配合使用。 + +![](https://guide-blog-images.oss-cn-shenzhen.aliyuncs.com/xingqiu/1&e=1648742399&token=kIxbL07-8jAj8w1n4s9zv64FuZZNEATmlU_Vm6zD:HyfLWy5gNC5F_XukPYrlj_a4EJI=.png) + +我已经在星球更新了 **7** 个高质量的小册： **《Java 面试进阶指北》**（持续完善中）、 **《从零开始写一个 RPC 框架》**（已更新完） 、**《Kafka 常见面试题/知识点总结》**、**《程序员副业赚钱之路》**（持续完善）、**《分布式、高并发、Devops 知识扫盲》**、**《Java 必读源码系列》**（目前已经整理了 Dubbo 2.6.x 、Netty 4.x、SpringBoot2.1 的源码）（持续完善中）。 + +![](https://guide-blog-images.oss-cn-shenzhen.aliyuncs.com/xingqiu/image-20220211231206733.png) + +如果你需要专属面试小册/一对一交流/简历修改/专属求职指南/学习打卡，不妨花 3 分钟左右看看星球的详细介绍： [JavaGuide 知识星球详细介绍](https://www.yuque.com/docs/share/8a30ffb5-83f3-40f9-baf9-38de68b906dc) （一定要确定自己真的需要再加入，一定要看完详细介绍之后再加我）。 + +星球目前的定价为 **159/年**，即将调整为 **199/年**。如果的认可 JavaGuide，相信我，并且需要星球提供的专属服务，那欢迎你加入我的星球。你可以添加我的私人微信领取星球专属优惠券，限时 **100/年** 加入。一定要备注“**星球优惠券**”！ + +![](https://guide-blog-images.oss-cn-shenzhen.aliyuncs.com/xingqiu/image-20220211231926486.png) + +**用心做内容，真心希望帮助到你，拒绝知识付费割韭菜。加油！！！** + diff --git a/docs/distributed-system/rpc/dubbo.md b/docs/distributed-system/rpc/dubbo.md new file mode 100644 index 0000000000000000000000000000000000000000..e436d3885c2486316979839d277100b5e6297028 --- /dev/null +++ b/docs/distributed-system/rpc/dubbo.md @@ -0,0 +1,501 @@ +# Dubbo知识点&面试题总结 + +这篇文章是我根据官方文档以及自己平时的使用情况，对 Dubbo 所做的一个总结。欢迎补充！ + +## RPC基础 + +### 何为 RPC? + +**RPC（Remote Procedure Call）** 即远程过程调用，通过名字我们就能看出 RPC 关注的是远程调用而非本地调用。 + +**为什么要 RPC ？** 因为，两个不同的服务器上的服务提供的方法不在一个内存空间，所以，需要通过网络编程才能传递方法调用所需要的参数。并且，方法调用的结果也需要通过网络编程来接收。但是，如果我们自己手动网络编程来实现这个调用过程的话工作量是非常大的，因为，我们需要考虑底层传输方式（TCP还是UDP）、序列化方式等等方面。 + + +**RPC 能帮助我们做什么呢？** 简单来说，通过 RPC 可以帮助我们调用远程计算机上某个服务的方法，这个过程就像调用本地方法一样简单。并且！我们不需要了解底层网络编程的具体细节。 + + +举个例子：两个不同的服务 A、B 部署在两台不同的机器上，服务 A 如果想要调用服务 B 中的某个方法的话就可以通过 RPC 来做。 + +一言蔽之：**RPC 的出现就是为了让你调用远程方法像调用本地方法一样简单。** + +### RPC 的原理是什么? + +为了能够帮助小伙伴们理解 RPC 原理，我们可以将整个 RPC的 核心功能看作是下面👇 6 个部分实现的： + + +1. **客户端（服务消费端）** ：调用远程方法的一端。 +1. **客户端 Stub（桩）** ： 这其实就是一代理类。代理类主要做的事情很简单，就是把你调用方法、类、方法参数等信息传递到服务端。 +1. **网络传输** ： 网络传输就是你要把你调用的方法的信息比如说参数啊这些东西传输到服务端，然后服务端执行完之后再把返回结果通过网络传输给你传输回来。网络传输的实现方式有很多种比如最近基本的 Socket或者性能以及封装更加优秀的 Netty（推荐）。 +1. **服务端 Stub（桩）** ：这个桩就不是代理类了。我觉得理解为桩实际不太好，大家注意一下就好。这里的服务端 Stub 实际指的就是接收到客户端执行方法的请求后，去指定对应的方法然后返回结果给客户端的类。 +1. **服务端（服务提供端）** ：提供远程方法的一端。 + +具体原理图如下，后面我会串起来将整个RPC的过程给大家说一下。 + + +![RPC原理图](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/18-12-6/37345851.jpg) + +1. 服务消费端（client）以本地调用的方式调用远程服务； +1. 客户端 Stub（client stub） 接收到调用后负责将方法、参数等组装成能够进行网络传输的消息体（序列化）：`RpcRequest`； +1. 客户端 Stub（client stub） 找到远程服务的地址，并将消息发送到服务提供端； +1. 服务端 Stub（桩）收到消息将消息反序列化为Java对象: `RpcRequest`； +1. 服务端 Stub（桩）根据`RpcRequest`中的类、方法、方法参数等信息调用本地的方法； +1. 服务端 Stub（桩）得到方法执行结果并将组装成能够进行网络传输的消息体：`RpcResponse`（序列化）发送至消费方； +1. 客户端 Stub（client stub）接收到消息并将消息反序列化为Java对象:`RpcResponse` ，这样也就得到了最终结果。over! + +相信小伙伴们看完上面的讲解之后，已经了解了 RPC 的原理。 + +虽然篇幅不多，但是基本把 RPC 框架的核心原理讲清楚了！另外，对于上面的技术细节，我会在后面的章节介绍到。 + +**最后，对于 RPC 的原理，希望小伙伴不单单要理解，还要能够自己画出来并且能够给别人讲出来。因为，在面试中这个问题在面试官问到 RPC 相关内容的时候基本都会碰到。** + +## Dubbo基础 + +### 什么是 Dubbo? + +![](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/2020-8/427f2168-1930-4c14-8760-415fac8db1d0-20200802184737978.png) + +[Apache Dubbo](https://github.com/apache/dubbo) |ˈdʌbəʊ| 是一款高性能、轻量级的开源 Java RPC 框架。 + +根据 [Dubbo 官方文档](https://dubbo.apache.org/zh/)的介绍，Dubbo 提供了六大核心能力 + +1. 面向接口代理的高性能RPC调用。 +2. 智能容错和负载均衡。 +3. 服务自动注册和发现。 +4. 高度可扩展能力。 +5. 运行期流量调度。 +6. 可视化的服务治理与运维。 + +![Dubbo提供的六大核心能力](https://guide-blog-images.oss-cn-shenzhen.aliyuncs.com/%E6%BA%90%E7%A0%81/dubbo/dubbo%E6%8F%90%E4%BE%9B%E7%9A%84%E5%85%AD%E5%A4%A7%E6%A0%B8%E5%BF%83%E8%83%BD%E5%8A%9B.png) + +简单来说就是： **Dubbo 不光可以帮助我们调用远程服务，还提供了一些其他开箱即用的功能比如智能负载均衡。** + +Dubbo 目前已经有接近 34.4 k 的 Star 。 + +在 **2020 年度 OSC 中国开源项目** 评选活动中，Dubbo 位列开发框架和基础组件类项目的第7名。相比几年前来说，热度和排名有所下降。 + +![](https://guide-blog-images.oss-cn-shenzhen.aliyuncs.com/%E6%BA%90%E7%A0%81/dubbo/image-20210107153159545.png) + +Dubbo 是由阿里开源，后来加入了 Apache 。正式由于 Dubbo 的出现，才使得越来越多的公司开始使用以及接受分布式架构。 + +### 为什么要用 Dubbo? + +随着互联网的发展，网站的规模越来越大，用户数量越来越多。单一应用架构 、垂直应用架构无法满足我们的需求，这个时候分布式服务架构就诞生了。 + +分布式服务架构下，系统被拆分成不同的服务比如短信服务、安全服务，每个服务独立提供系统的某个核心服务。 + +我们可以使用 Java RMI（Java Remote Method Invocation）、Hessian这种支持远程调用的框架来简单地暴露和引用远程服务。但是！当服务越来越多之后，服务调用关系越来越复杂。当应用访问压力越来越大后，负载均衡以及服务监控的需求也迫在眉睫。我们可以用 F5 这类硬件来做负载均衡，但这样增加了成本，并且存在单点故障的风险。 + +不过，Dubbo 的出现让上述问题得到了解决。**Dubbo 帮助我们解决了什么问题呢？** + +1. **负载均衡** ： 同一个服务部署在不同的机器时该调用哪一台机器上的服务。 +2. **服务调用链路生成** ： 随着系统的发展，服务越来越多，服务间依赖关系变得错踪复杂，甚至分不清哪个应用要在哪个应用之前启动，架构师都不能完整的描述应用的架构关系。Dubbo 可以为我们解决服务之间互相是如何调用的。 +3. **服务访问压力以及时长统计、资源调度和治理** ：基于访问压力实时管理集群容量，提高集群利用率。 +4. ...... + +![](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/18-9-26/43050183.jpg) + +另外，Dubbo 除了能够应用在分布式系统中，也可以应用在现在比较火的微服务系统中。不过，由于 Spring Cloud 在微服务中应用更加广泛，所以，我觉得一般我们提 Dubbo 的话，大部分是分布式系统的情况。 + +**我们刚刚提到了分布式这个概念，下面再给大家介绍一下什么是分布式？为什么要分布式？** + +## 分布式基础 + +### 什么是分布式? + +分布式或者说 SOA 分布式重要的就是面向服务，说简单的分布式就是我们把整个系统拆分成不同的服务然后将这些服务放在不同的服务器上减轻单体服务的压力提高并发量和性能。比如电商系统可以简单地拆分成订单系统、商品系统、登录系统等等，拆分之后的每个服务可以部署在不同的机器上，如果某一个服务的访问量比较大的话也可以将这个服务同时部署在多台机器上。 + +![分布式事务示意图](https://guide-blog-images.oss-cn-shenzhen.aliyuncs.com/java-guide-blog/%E5%88%86%E5%B8%83%E5%BC%8F%E4%BA%8B%E5%8A%A1%E7%A4%BA%E6%84%8F%E5%9B%BE.png) + +### 为什么要分布式? + +从开发角度来讲单体应用的代码都集中在一起，而分布式系统的代码根据业务被拆分。所以，每个团队可以负责一个服务的开发，这样提升了开发效率。另外，代码根据业务拆分之后更加便于维护和扩展。 + +另外，我觉得将系统拆分成分布式之后不光便于系统扩展和维护，更能提高整个系统的性能。你想一想嘛？把整个系统拆分成不同的服务/系统，然后每个服务/系统 单独部署在一台服务器上，是不是很大程度上提高了系统性能呢？ + +## Dubbo 架构 + +### Dubbo 架构中的核心角色有哪些？ + +[官方文档中的框架设计章节](https://dubbo.apache.org/zh/docs/v2.7/dev/design/) 已经介绍的非常详细了，我这里把一些比较重要的点再提一下。 + +![dubbo-relation](https://guide-blog-images.oss-cn-shenzhen.aliyuncs.com/%E6%BA%90%E7%A0%81/dubbo/dubbo-relation.jpg) + +上述节点简单介绍以及他们之间的关系： + +- **Container：** 服务运行容器，负责加载、运行服务提供者。必须。 +- **Provider：** 暴露服务的服务提供方，会向注册中心注册自己提供的服务。必须。 +- **Consumer：** 调用远程服务的服务消费方，会向注册中心订阅自己所需的服务。必须。 +- **Registry：** 服务注册与发现的注册中心。注册中心会返回服务提供者地址列表给消费者。非必须。 +- **Monitor：** 统计服务的调用次数和调用时间的监控中心。服务消费者和提供者会定时发送统计数据到监控中心。 非必须。 + +### Dubbo 中的 Invoker 概念了解么？ + +`Invoker` 是 Dubbo 领域模型中非常重要的一个概念，你如果阅读过 Dubbo 源码的话，你会无数次看到这玩意。就比如下面我要说的负载均衡这块的源码中就有大量 `Invoker` 的身影。 + +简单来说，`Invoker` 就是 Dubbo 对远程调用的抽象。 + +![dubbo_rpc_invoke.jpg](https://guide-blog-images.oss-cn-shenzhen.aliyuncs.com/java-guide-blog/dubbo_rpc_invoke.jpg) + +按照 Dubbo 官方的话来说，`Invoker` 分为 + +- 服务提供 `Invoker` +- 服务消费 `Invoker` + +假如我们需要调用一个远程方法，我们需要动态代理来屏蔽远程调用的细节吧！我们屏蔽掉的这些细节就依赖对应的 `Invoker` 实现， `Invoker` 实现了真正的远程服务调用。 + +### Dubbo 的工作原理了解么？ + +下图是 Dubbo 的整体设计，从下至上分为十层，各层均为单向依赖。 + +> 左边淡蓝背景的为服务消费方使用的接口，右边淡绿色背景的为服务提供方使用的接口，位于中轴线上的为双方都用到的接口。 + +![dubbo-framework](https://guide-blog-images.oss-cn-shenzhen.aliyuncs.com/source-code/dubbo/dubbo-framework.jpg) + +- **config 配置层**：Dubbo相关的配置。支持代码配置，同时也支持基于 Spring 来做配置，以 `ServiceConfig`, `ReferenceConfig` 为中心 +- **proxy 服务代理层**：调用远程方法像调用本地的方法一样简单的一个关键，真实调用过程依赖代理类，以 `ServiceProxy` 为中心。 +- **registry 注册中心层**：封装服务地址的注册与发现。 +- **cluster 路由层**：封装多个提供者的路由及负载均衡，并桥接注册中心，以 `Invoker` 为中心。 +- **monitor 监控层**：RPC 调用次数和调用时间监控，以 `Statistics` 为中心。 +- **protocol 远程调用层**：封装 RPC 调用，以 `Invocation`, `Result` 为中心。 +- **exchange 信息交换层**：封装请求响应模式，同步转异步，以 `Request`, `Response` 为中心。 +- **transport 网络传输层**：抽象 mina 和 netty 为统一接口，以 `Message` 为中心。 +- **serialize 数据序列化层** ：对需要在网络传输的数据进行序列化。 + +### Dubbo 的 SPI 机制了解么？ 如何扩展 Dubbo 中的默认实现？ + +SPI（Service Provider Interface） 机制被大量用在开源项目中，它可以帮助我们动态寻找服务/功能（比如负载均衡策略）的实现。 + +SPI 的具体原理是这样的：我们将接口的实现类放在配置文件中，我们在程序运行过程中读取配置文件，通过反射加载实现类。这样，我们可以在运行的时候，动态替换接口的实现类。和 IoC 的解耦思想是类似的。 + +Java 本身就提供了 SPI 机制的实现。不过，Dubbo 没有直接用，而是对 Java原生的 SPI机制进行了增强，以便更好满足自己的需求。 + +**那我们如何扩展 Dubbo 中的默认实现呢？** + +比如说我们想要实现自己的负载均衡策略，我们创建对应的实现类 `XxxLoadBalance` 实现 `LoadBalance` 接口或者 `AbstractLoadBalance` 类。 + +```java +package com.xxx; + +import org.apache.dubbo.rpc.cluster.LoadBalance; +import org.apache.dubbo.rpc.Invoker; +import org.apache.dubbo.rpc.Invocation; +import org.apache.dubbo.rpc.RpcException; + +public class XxxLoadBalance implements LoadBalance { + public Invoker select(List> invokers, Invocation invocation) throws RpcException { + // ... + } +} +``` + +我们将这个实现类的路径写入到`resources` 目录下的 `META-INF/dubbo/org.apache.dubbo.rpc.cluster.LoadBalance`文件中即可。 + +```java +src + |-main + |-java + |-com + |-xxx + |-XxxLoadBalance.java (实现LoadBalance接口) + |-resources + |-META-INF + |-dubbo + |-org.apache.dubbo.rpc.cluster.LoadBalance (纯文本文件，内容为：xxx=com.xxx.XxxLoadBalance) +``` + +`org.apache.dubbo.rpc.cluster.LoadBalance` + +``` +xxx=com.xxx.XxxLoadBalance +``` + +其他还有很多可供扩展的选择，你可以在[官方文档@SPI扩展实现](https://dubbo.apache.org/zh/docs/v2.7/dev/impls/)这里找到。 + +![](https://img-blog.csdnimg.cn/20210328091015555.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM0MzM3Mjcy,size_16,color_FFFFFF,t_70) + +### Dubbo 的微内核架构了解吗？ + +Dubbo 采用 微内核（Microkernel） + 插件（Plugin） 模式，简单来说就是微内核架构。微内核只负责组装插件。 + +**何为微内核架构呢？** 《软件架构模式》 这本书是这样介绍的： + +> 微内核架构模式（有时被称为插件架构模式）是实现基于产品应用程序的一种自然模式。基于产品的应用程序是已经打包好并且拥有不同版本，可作为第三方插件下载的。然后，很多公司也在开发、发布自己内部商业应用像有版本号、说明及可加载插件式的应用软件（这也是这种模式的特征）。微内核系统可让用户添加额外的应用如插件，到核心应用，继而提供了可扩展性和功能分离的用法。 + +微内核架构包含两类组件：**核心系统（core system）** 和 **插件模块（plug-in modules）**。 + +![](https://guide-blog-images.oss-cn-shenzhen.aliyuncs.com/source-code/dubbo/%E5%BE%AE%E5%86%85%E6%A0%B8%E6%9E%B6%E6%9E%84%E7%A4%BA%E6%84%8F%E5%9B%BE.png) + +核心系统提供系统所需核心能力，插件模块可以扩展系统的功能。因此， 基于微内核架构的系统，非常易于扩展功能。 + +我们常见的一些IDE，都可以看作是基于微内核架构设计的。绝大多数 IDE比如IDEA、VSCode都提供了插件来丰富自己的功能。 + +正是因为Dubbo基于微内核架构，才使得我们可以随心所欲替换Dubbo的功能点。比如你觉得Dubbo 的序列化模块实现的不满足自己要求，没关系啊！你自己实现一个序列化模块就好了啊！ + +通常情况下，微核心都会采用 Factory、IoC、OSGi 等方式管理插件生命周期。Dubbo 不想依赖 Spring 等 IoC 容器，也不想自己造一个小的 IoC 容器（过度设计），因此采用了一种最简单的 Factory 方式管理插件 ：**JDK 标准的 SPI 扩展机制** （`java.util.ServiceLoader`）。 + +### 关于Dubbo架构的一些自测小问题 + +#### 注册中心的作用了解么？ + +注册中心负责服务地址的注册与查找，相当于目录服务，服务提供者和消费者只在启动时与注册中心交互。 + +#### 服务提供者宕机后，注册中心会做什么？ + +注册中心会立即推送事件通知消费者。 + +#### 监控中心的作用呢？ + +监控中心负责统计各服务调用次数，调用时间等。 + +#### 注册中心和监控中心都宕机的话，服务都会挂掉吗？ + +不会。两者都宕机也不影响已运行的提供者和消费者，消费者在本地缓存了提供者列表。注册中心和监控中心都是可选的，服务消费者可以直连服务提供者。 + + +## Dubbo 的负载均衡策略 + +### 什么是负载均衡？ + +先来看一下稍微官方点的解释。下面这段话摘自维基百科对负载均衡的定义： + +> 负载均衡改善了跨多个计算资源（例如计算机，计算机集群，网络链接，中央处理单元或磁盘驱动）的工作负载分布。负载平衡旨在优化资源使用，最大化吞吐量，最小化响应时间，并避免任何单个资源的过载。使用具有负载平衡而不是单个组件的多个组件可以通过冗余提高可靠性和可用性。负载平衡通常涉及专用软件或硬件。 + +**上面讲的大家可能不太好理解，再用通俗的话给大家说一下。** + +我们的系统中的某个服务的访问量特别大，我们将这个服务部署在了多台服务器上，当客户端发起请求的时候，多台服务器都可以处理这个请求。那么，如何正确选择处理该请求的服务器就很关键。假如，你就要一台服务器来处理该服务的请求，那该服务部署在多台服务器的意义就不复存在了。负载均衡就是为了避免单个服务器响应同一请求，容易造成服务器宕机、崩溃等问题，我们从负载均衡的这四个字就能明显感受到它的意义。 + +### Dubbo 提供的负载均衡策略有哪些？ + +在集群负载均衡时，Dubbo 提供了多种均衡策略，默认为 `random` 随机调用。我们还可以自行扩展负载均衡策略（参考Dubbo SPI机制）。 + +在 Dubbo 中，所有负载均衡实现类均继承自 `AbstractLoadBalance`，该类实现了 `LoadBalance` 接口，并封装了一些公共的逻辑。 + +```java +public abstract class AbstractLoadBalance implements LoadBalance { + + static int calculateWarmupWeight(int uptime, int warmup, int weight) { + } + + @Override + public Invoker select(List> invokers, URL url, Invocation invocation) { + } + + protected abstract Invoker doSelect(List> invokers, URL url, Invocation invocation); + + + int getWeight(Invoker invoker, Invocation invocation) { + + } +} +``` + +`AbstractLoadBalance` 的实现类有下面这些： + +![](https://guide-blog-images.oss-cn-shenzhen.aliyuncs.com/java-guide-blog/image-20210326105257812.png) + +官方文档对负载均衡这部分的介绍非常详细，推荐小伙伴们看看，地址：[https://dubbo.apache.org/zh/docs/v2.7/dev/source/loadbalance/#m-zhdocsv27devsourceloadbalance](https://dubbo.apache.org/zh/docs/v2.7/dev/source/loadbalance/#m-zhdocsv27devsourceloadbalance ) 。 + +#### RandomLoadBalance + +根据权重随机选择（对加权随机算法的实现）。这是Dubbo默认采用的一种负载均衡策略。 + +` RandomLoadBalance` 具体的实现原理非常简单，假如有两个提供相同服务的服务器 S1,S2，S1的权重为7，S2的权重为3。 + +我们把这些权重值分布在坐标区间会得到：S1->[0, 7) ，S2->[7, 10)。我们生成[0, 10) 之间的随机数，随机数落到对应的区间，我们就选择对应的服务器来处理请求。 + +![RandomLoadBalance](https://guide-blog-images.oss-cn-shenzhen.aliyuncs.com/java-guide-blog/%20RandomLoadBalance.png) + +`RandomLoadBalance` 的源码非常简单，简单花几分钟时间看一下。 + +> 以下源码来自 Dubbo master 分支上的最新的版本 2.7.9。 + +```java +public class RandomLoadBalance extends AbstractLoadBalance { + + public static final String NAME = "random"; + + @Override + protected Invoker doSelect(List> invokers, URL url, Invocation invocation) { + + int length = invokers.size(); + boolean sameWeight = true; + int[] weights = new int[length]; + int totalWeight = 0; + // 下面这个for循环的主要作用就是计算所有该服务的提供者的权重之和 totalWeight（）， + // 除此之外，还会检测每个服务提供者的权重是否相同 + for (int i = 0; i < length; i++) { + int weight = getWeight(invokers.get(i), invocation); + totalWeight += weight; + weights[i] = totalWeight; + if (sameWeight && totalWeight != weight * (i + 1)) { + sameWeight = false; + } + } + if (totalWeight > 0 && !sameWeight) { + // 随机生成一个 [0, totalWeight) 区间内的数字 + int offset = ThreadLocalRandom.current().nextInt(totalWeight); + // 判断会落在哪个服务提供者的区间 + for (int i = 0; i < length; i++) { + if (offset < weights[i]) { + return invokers.get(i); + } + } + + return invokers.get(ThreadLocalRandom.current().nextInt(length)); + } + +} + +``` + +#### LeastActiveLoadBalance + +`LeastActiveLoadBalance` 直译过来就是**最小活跃数负载均衡**。 + +这个名字起得有点不直观，不仔细看官方对活跃数的定义，你压根不知道这玩意是干嘛的。 + +我这么说吧！初始状态下所有服务提供者的活跃数均为 0（每个服务提供者的中特定方法都对应一个活跃数，我在后面的源码中会提到），每收到一个请求后，对应的服务提供者的活跃数 +1，当这个请求处理完之后，活跃数 -1。 + +因此，**Dubbo 就认为谁的活跃数越少，谁的处理速度就越快，性能也越好，这样的话，我就优先把请求给活跃数少的服务提供者处理。** + +**如果有多个服务提供者的活跃数相等怎么办？** + +很简单，那就再走一遍 `RandomLoadBalance` 。 + +```java +public class LeastActiveLoadBalance extends AbstractLoadBalance { + + public static final String NAME = "leastactive"; + + @Override + protected Invoker doSelect(List> invokers, URL url, Invocation invocation) { + int length = invokers.size(); + int leastActive = -1; + int leastCount = 0; + int[] leastIndexes = new int[length]; + int[] weights = new int[length]; + int totalWeight = 0; + int firstWeight = 0; + boolean sameWeight = true; + // 这个 for 循环的主要作用是遍历 invokers 列表，找出活跃数最小的 Invoker + // 如果有多个 Invoker 具有相同的最小活跃数，还会记录下这些 Invoker 在 invokers 集合中的下标，并累加它们的权重，比较它们的权重值是否相等 + for (int i = 0; i < length; i++) { + Invoker invoker = invokers.get(i); + // 获取 invoker 对应的活跃(active)数 + int active = RpcStatus.getStatus(invoker.getUrl(), invocation.getMethodName()).getActive(); + int afterWarmup = getWeight(invoker, invocation); + weights[i] = afterWarmup; + if (leastActive == -1 || active < leastActive) { + leastActive = active; + leastCount = 1; + leastIndexes[0] = i; + totalWeight = afterWarmup; + firstWeight = afterWarmup; + sameWeight = true; + } else if (active == leastActive) { + leastIndexes[leastCount++] = i; + totalWeight += afterWarmup; + if (sameWeight && afterWarmup != firstWeight) { + sameWeight = false; + } + } + } + // 如果只有一个 Invoker 具有最小的活跃数，此时直接返回该 Invoker 即可 + if (leastCount == 1) { + return invokers.get(leastIndexes[0]); + } + // 如果有多个 Invoker 具有相同的最小活跃数，但它们之间的权重不同 + // 这里的处理方式就和 RandomLoadBalance 一致了 + if (!sameWeight && totalWeight > 0) { + int offsetWeight = ThreadLocalRandom.current().nextInt(totalWeight); + for (int i = 0; i < leastCount; i++) { + int leastIndex = leastIndexes[i]; + offsetWeight -= weights[leastIndex]; + if (offsetWeight < 0) { + return invokers.get(leastIndex); + } + } + } + return invokers.get(leastIndexes[ThreadLocalRandom.current().nextInt(leastCount)]); + } +} + +``` + +活跃数是通过 `RpcStatus` 中的一个 `ConcurrentMap` 保存的，根据 URL 以及服务提供者被调用的方法的名称，我们便可以获取到对应的活跃数。也就是说服务提供者中的每一个方法的活跃数都是互相独立的。 + +```java +public class RpcStatus { + + private static final ConcurrentMap> METHOD_STATISTICS = + new ConcurrentHashMap>(); + + public static RpcStatus getStatus(URL url, String methodName) { + String uri = url.toIdentityString(); + ConcurrentMap map = METHOD_STATISTICS.computeIfAbsent(uri, k -> new ConcurrentHashMap<>()); + return map.computeIfAbsent(methodName, k -> new RpcStatus()); + } + public int getActive() { + return active.get(); + } + +} +``` + +#### ConsistentHashLoadBalance + +`ConsistentHashLoadBalance` 小伙伴们应该也不会陌生，在分库分表、各种集群中就经常使用这个负载均衡策略。 + +`ConsistentHashLoadBalance` 即**一致性Hash负载均衡策略**。 `ConsistentHashLoadBalance` 中没有权重的概念，具体是哪个服务提供者处理请求是由你的请求的参数决定的，也就是说相同参数的请求总是发到同一个服务提供者。 + +![](https://guide-blog-images.oss-cn-shenzhen.aliyuncs.com/java-guide-blog/consistent-hash-data-incline.jpg) + +另外，Dubbo 为了避免数据倾斜问题（节点不够分散，大量请求落到同一节点），还引入了虚拟节点的概念。通过虚拟节点可以让节点更加分散，有效均衡各个节点的请求量。 + + + +![](https://guide-blog-images.oss-cn-shenzhen.aliyuncs.com/java-guide-blog/consistent-hash-invoker.jpg) + +官方有详细的源码分析：[https://dubbo.apache.org/zh/docs/v2.7/dev/source/loadbalance/#23-consistenthashloadbalance](https://dubbo.apache.org/zh/docs/v2.7/dev/source/loadbalance/#23-consistenthashloadbalance) 。这里还有一个相关的 [PR#5440](https://github.com/apache/dubbo/pull/5440) 来修复老版本中 ConsistentHashLoadBalance 存在的一些Bug。感兴趣的小伙伴，可以多花点时间研究一下。我这里不多分析了，这个作业留给你们！ + +#### RoundRobinLoadBalance + +加权轮询负载均衡。 + +轮询就是把请求依次分配给每个服务提供者。加权轮询就是在轮询的基础上，让更多的请求落到权重更大的服务提供者上。比如假如有两个提供相同服务的服务器 S1,S2，S1的权重为7，S2的权重为3。 + +如果我们有 10 次请求，那么 7 次会被 S1处理，3次被 S2处理。 + +但是，如果是 `RandomLoadBalance` 的话，很可能存在10次请求有9次都被 S1 处理的情况（概率性问题）。 + +Dubbo 中的 `RoundRobinLoadBalance` 的代码实现被修改重建了好几次，Dubbo-2.6.5 版本的 `RoundRobinLoadBalance` 为平滑加权轮询算法。 + +## Dubbo序列化协议 + +### Dubbo 支持哪些序列化方式呢？ + +![](https://img-blog.csdnimg.cn/20210328092219640.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM0MzM3Mjcy,size_16,color_FFFFFF,t_70) + +Dubbo 支持多种序列化方式：JDK自带的序列化、hessian2、JSON、Kryo、FST、Protostuff，ProtoBuf等等。 + +Dubbo 默认使用的序列化方式是 hession2。 + +### 谈谈你对这些序列化协议了解？ + +一般我们不会直接使用 JDK 自带的序列化方式。主要原因有两个： + +1. **不支持跨语言调用** : 如果调用的是其他语言开发的服务的时候就不支持了。 +2. **性能差** ：相比于其他序列化框架性能更低，主要原因是序列化之后的字节数组体积较大，导致传输成本加大。 + +JSON 序列化由于性能问题，我们一般也不会考虑使用。 + +像 Protostuff，ProtoBuf、hessian2这些都是跨语言的序列化方式，如果有跨语言需求的话可以考虑使用。 + +Kryo和FST这两种序列化方式是 Dubbo 后来才引入的，性能非常好。不过，这两者都是专门针对 Java 语言的。Dubbo 官网的一篇文章中提到说推荐使用 Kryo 作为生产环境的序列化方式。(文章地址：[https://dubbo.apache.org/zh/docs/v2.7/user/references/protocol/rest/](https://dubbo.apache.org/zh/docs/v2.7/user/references/protocol/rest/)) + +![](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/2020-8/569e541a-22b2-4846-aa07-0ad479f07440.png) + +Dubbo 官方文档中还有一个关于这些[序列化协议的性能对比图](https://dubbo.apache.org/zh/docs/v2.7/user/serialization/#m-zhdocsv27userserialization)可供参考。 + +![](https://img-blog.csdnimg.cn/20210328093219609.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM0MzM3Mjcy,size_16,color_FFFFFF,t_70) + diff --git a/docs/distributed-system/rpc/why-use-rpc.md b/docs/distributed-system/rpc/why-use-rpc.md new file mode 100644 index 0000000000000000000000000000000000000000..a2fe5dbefa27faae2eed8519e460727403d8e7c1 --- /dev/null +++ b/docs/distributed-system/rpc/why-use-rpc.md @@ -0,0 +1,75 @@ +# 服务之间的调用为啥不直接用 HTTP 而用 RPC？ + +## 什么是 RPC?RPC原理是什么? + +### **什么是 RPC？** + +RPC（Remote Procedure Call）—远程过程调用，它是一种通过网络从远程计算机程序上请求服务，而不需要了解底层网络技术的协议。比如两个不同的服务 A、B 部署在两台不同的机器上，那么服务 A 如果想要调用服务 B 中的某个方法该怎么办呢？使用 HTTP请求 当然可以，但是可能会比较慢而且一些优化做的并不好。 RPC 的出现就是为了解决这个问题。 + +### **RPC原理是什么？** + +![RPC原理图](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/18-12-6/37345851.jpg) + +1. 服务消费端（client）以本地调用的方式调用远程服务； +2. 客户端 Stub（client stub） 接收到调用后负责将方法、参数等组装成能够进行网络传输的消息体（序列化）：`RpcRequest`； +3. 客户端 Stub（client stub） 找到远程服务的地址，并将消息发送到服务提供端； +4. 服务端 Stub（桩）收到消息将消息反序列化为Java对象: `RpcRequest`； +5. 服务端 Stub（桩）根据`RpcRequest`中的类、方法、方法参数等信息调用本地的方法； +6. 服务端 Stub（桩）得到方法执行结果并将组装成能够进行网络传输的消息体：`RpcResponse`（序列化）发送至消费方； +7. 客户端 Stub（client stub）接收到消息并将消息反序列化为Java对象:`RpcResponse` ，这样也就得到了最终结果。 + +下面再贴一个网上的时序图，辅助理解： + +![RPC原理时序图](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/18-12-6/32527396.jpg) + +### RPC 解决了什么问题？ + +从上面对 RPC 介绍的内容中，概括来讲RPC 主要解决了：**让分布式或者微服务系统中不同服务之间的调用像本地调用一样简单。** + +### 常见的 RPC 框架总结? + +- **RMI（JDK自带）：** JDK自带的RPC，有很多局限性，不推荐使用。 +- **Dubbo:** Dubbo是 阿里巴巴公司开源的一个高性能优秀的服务框架，使得应用可通过高性能的 RPC 实现服务的输出和输入功能，可以和 Spring框架无缝集成。目前 Dubbo 已经成为 Spring Cloud Alibaba 中的官方组件。 +- **gRPC** ：gRPC是可以在任何环境中运行的现代开源高性能RPC框架。它可以通过可插拔的支持来有效地连接数据中心内和跨数据中心的服务，以实现负载平衡，跟踪，运行状况检查和身份验证。它也适用于分布式计算的最后一英里，以将设备，移动应用程序和浏览器连接到后端服务。 +- **Hessian：** Hessian是一个轻量级的remoting on http工具，使用简单的方法提供了RMI的功能。 相比WebService，Hessian更简单、快捷。采用的是二进制RPC协议，因为采用的是二进制协议，所以它很适合于发送二进制数据。 +- **Thrift：** Apache Thrift是Facebook开源的跨语言的RPC通信框架，目前已经捐献给Apache基金会管理，由于其跨语言特性和出色的性能，在很多互联网公司得到应用，有能力的公司甚至会基于thrift研发一套分布式服务框架，增加诸如服务注册、服务发现等功能。 + +### RPC学习材料 + +- [跟着 Guide 哥造轮子](https://github.com/Snailclimb/guide-rpc-framework) + +## 既有 HTTP ,为啥用 RPC 进行服务调用? + +### RPC 只是一种设计而已 + +RPC 只是一种概念、一种设计，就是为了解决 **不同服务之间的调用问题**, 它一般会包含有 **传输协议** 和 **序列化协议** 这两个。 + +但是，HTTP 是一种协议，RPC框架可以使用 HTTP协议作为传输协议或者直接使用TCP作为传输协议，使用不同的协议一般也是为了适应不同的场景。 + +### HTTP 和 TCP + +**可能现在很多对计算机网络不太熟悉的朋友已经被搞蒙了，要想真正搞懂，还需要来简单复习一下计算机网络基础知识：** + +> 我们通常谈计算机网络的五层协议的体系结构是指：应用层、传输层、网络层、数据链路层、物理层。 +> +> **应用层(application-layer）的任务是通过应用进程间的交互来完成特定网络应用。** HTTP 属于应用层协议，它会基于TCP/IP通信协议来传递数据（HTML 文件, 图片文件, 查询结果等）。HTTP协议工作于客户端-服务端架构上。浏览器作为HTTP客户端通过 URL 向HTTP服务端即WEB服务器发送所有请求。Web服务器根据接收到的请求后，向客户端发送响应信息。HTTP协议建立在 TCP 协议之上。 +> +> **传输层(transport layer)的主要任务就是负责向两台主机进程之间的通信提供通用的数据传输服务**。TCP是传输层协议，主要解决数据如何在网络中传输。相比于UDP,**TCP** 提供的是**面向连接**的，**可靠的**数据传输服务。 + +### RPC框架功能更齐全 + +成熟的 RPC框架还提供好了“服务自动注册与发现”、"智能负载均衡"、“可视化的服务治理和运维”、“运行期流量调度”等等功能，这些也算是选择 +RPC 进行服务注册和发现的一方面原因吧！ + +**相关阅读：** + +- http://www.ruanyifeng.com/blog/2016/08/http.html （HTTP 协议入门- 阮一峰） + +### 一个常见的错误观点 + +很多文章中还会提到说 HTTP 协议相较于自定义 TCP 报文协议，增加的开销在于连接的建立与断开，但是这个观点已经被否认，下面截取自知乎中一个回答，原回答地址：https://www.zhihu.com/question/41609070/answer/191965937 。 + +>首先要否认一点 HTTP 协议相较于自定义 TCP 报文协议，增加的开销在于连接的建立与断开。HTTP 协议是支持连接池复用的，也就是建立一定数量的连接不断开，并不会频繁的创建和销毁连接。二一要说的是 HTTP 也可以使用 Protobuf 这种二进制编码协议对内容进行编码，因此二者最大的区别还是在传输协议上。 + + + diff --git a/docs/distributed-system/theorem&algorithm&protocol/cap&base-theorem.md b/docs/distributed-system/theorem&algorithm&protocol/cap&base-theorem.md new file mode 100644 index 0000000000000000000000000000000000000000..fdd4af2d97e6851b7c9fb825f2c83f40fb88dc16 --- /dev/null +++ b/docs/distributed-system/theorem&algorithm&protocol/cap&base-theorem.md @@ -0,0 +1,161 @@ +--- +title: CAP & BASE理论 +category: 分布式 +tag: + - 分布式协议&算法 +--- + +经历过技术面试的小伙伴想必对这个两个概念已经再熟悉不过了！ + +Guide哥当年参加面试的时候，不夸张地说，只要问到分布式相关的内容，面试官几乎是必定会问这两个分布式相关的理论。 + +并且，这两个理论也可以说是小伙伴们学习分布式相关内容的基础了！ + +因此，小伙伴们非常非常有必要将这理论搞懂，并且能够用自己的理解给别人讲出来。 + +这篇文章我会站在自己的角度对这两个概念进行解读！ + +*个人能力有限。如果文章有任何需要改善和完善的地方，欢迎在评论区指出，共同进步！——爱你们的Guide哥* + +## CAP理论 + +[CAP 理论/定理](https://zh.wikipedia.org/wiki/CAP%E5%AE%9A%E7%90%86)起源于 2000年，由加州大学伯克利分校的Eric Brewer教授在分布式计算原理研讨会（PODC）上提出，因此 CAP定理又被称作 **布鲁尔定理（Brewer’s theorem）** + +2年后，麻省理工学院的Seth Gilbert和Nancy Lynch 发表了布鲁尔猜想的证明，CAP理论正式成为分布式领域的定理。 + +### 简介 + +**CAP** 也就是 **Consistency（一致性）**、**Availability（可用性）**、**Partition Tolerance（分区容错性）** 这三个单词首字母组合。 + +![](https://guide-blog-images.oss-cn-shenzhen.aliyuncs.com/2020-11/cap.png) + +CAP 理论的提出者布鲁尔在提出 CAP 猜想的时候，并没有详细定义 **Consistency**、**Availability**、**Partition Tolerance** 三个单词的明确定义。 + +因此，对于 CAP 的民间解读有很多，一般比较被大家推荐的是下面 👇 这种版本的解读。 + +在理论计算机科学中，CAP 定理（CAP theorem）指出对于一个分布式系统来说，当设计读写操作时，只能同时满足以下三点中的两个： + +- **一致性（Consistency）** : 所有节点访问同一份最新的数据副本 +- **可用性（Availability）**: 非故障的节点在合理的时间内返回合理的响应（不是错误或者超时的响应）。 +- **分区容错性（Partition tolerance）** : 分布式系统出现网络分区的时候，仍然能够对外提供服务。 + +**什么是网络分区？** + +> 分布式系统中，多个节点之前的网络本来是连通的，但是因为某些故障（比如部分节点网络出了问题）某些节点之间不连通了，整个网络就分成了几块区域，这就叫网络分区。 + +![partition-tolerance](https://guide-blog-images.oss-cn-shenzhen.aliyuncs.com/2020-11/partition-tolerance.png) + +### 不是所谓的“3 选 2” + +大部分人解释这一定律时，常常简单的表述为：“一致性、可用性、分区容忍性三者你只能同时达到其中两个，不可能同时达到”。实际上这是一个非常具有误导性质的说法，而且在 CAP 理论诞生 12 年之后，CAP 之父也在 2012 年重写了之前的论文。 + +> **当发生网络分区的时候，如果我们要继续服务，那么强一致性和可用性只能 2 选 1。也就是说当网络分区之后 P 是前提，决定了 P 之后才有 C 和 A 的选择。也就是说分区容错性（Partition tolerance）我们是必须要实现的。** +> +> 简而言之就是：CAP 理论中分区容错性 P 是一定要满足的，在此基础上，只能满足可用性 A 或者一致性 C。 + +因此，**分布式系统理论上不可能选择 CA 架构，只能选择 CP 或者 AP 架构。** 比如 ZooKeeper、HBase 就是 CP 架构，Cassandra、Eureka 就是 AP 架构，Nacos 不仅支持 CP 架构也支持 AP 架构。 + +**为啥不可能选择 CA 架构呢？** 举个例子：若系统出现“分区”，系统中的某个节点在进行写操作。为了保证 C， 必须要禁止其他节点的读写操作，这就和 A 发生冲突了。如果为了保证 A，其他节点的读写操作正常的话，那就和 C 发生冲突了。 + +**选择 CP 还是 AP 的关键在于当前的业务场景，没有定论，比如对于需要确保强一致性的场景如银行一般会选择保证 CP 。** + +另外，需要补充说明的一点是： **如果网络分区正常的话（系统在绝大部分时候所处的状态），也就说不需要保证 P 的时候，C 和 A 能够同时保证。** + +### CAP 实际应用案例 + +我这里以注册中心来探讨一下 CAP 的实际应用。考虑到很多小伙伴不知道注册中心是干嘛的，这里简单以 Dubbo 为例说一说。 + +下图是 Dubbo 的架构图。**注册中心 Registry 在其中扮演了什么角色呢？提供了什么服务呢？** + +注册中心负责服务地址的注册与查找，相当于目录服务，服务提供者和消费者只在启动时与注册中心交互，注册中心不转发请求，压力较小。 + +![](https://guide-blog-images.oss-cn-shenzhen.aliyuncs.com/2020-11/dubbo-architecture.png) + +常见的可以作为注册中心的组件有：ZooKeeper、Eureka、Nacos...。 + +1. **ZooKeeper 保证的是 CP。** 任何时刻对 ZooKeeper 的读请求都能得到一致性的结果，但是， ZooKeeper 不保证每次请求的可用性比如在 Leader 选举过程中或者半数以上的机器不可用的时候服务就是不可用的。 +2. **Eureka 保证的则是 AP。** Eureka 在设计的时候就是优先保证 A （可用性）。在 Eureka 中不存在什么 Leader 节点，每个节点都是一样的、平等的。因此 Eureka 不会像 ZooKeeper 那样出现选举过程中或者半数以上的机器不可用的时候服务就是不可用的情况。 Eureka 保证即使大部分节点挂掉也不会影响正常提供服务，只要有一个节点是可用的就行了。只不过这个节点上的数据可能并不是最新的。 +3. **Nacos 不仅支持 CP 也支持 AP。** + +### 总结 + +在进行分布式系统设计和开发时，我们不应该仅仅局限在 CAP 问题上，还要关注系统的扩展性、可用性等等 + +在系统发生“分区”的情况下，CAP 理论只能满足 CP 或者 AP。要注意的是，这里的前提是系统发生了“分区” + +如果系统没有发生“分区”的话，节点间的网络连接通信正常的话，也就不存在 P 了。这个时候，我们就可以同时保证 C 和 A 了。 + +总结：**如果系统发生“分区”，我们要考虑选择 CP 还是 AP。如果系统没有发生“分区”的话，我们要思考如何保证 CA 。** + +### 推荐阅读 + +1. [CAP 定理简化](https://medium.com/@ravindraprasad/cap-theorem-simplified-28499a67eab4) （英文，有趣的案例） +2. [神一样的 CAP 理论被应用在何方](https://juejin.im/post/6844903936718012430) （中文，列举了很多实际的例子） +3. [请停止呼叫数据库 CP 或 AP ](https://martin.kleppmann.com/2015/05/11/please-stop-calling-databases-cp-or-ap.html) （英文，带给你不一样的思考） + +## BASE 理论 + +[BASE 理论](https://dl.acm.org/doi/10.1145/1394127.1394128)起源于 2008 年， 由eBay的架构师Dan Pritchett在ACM上发表。 + +### 简介 + +**BASE** 是 **Basically Available（基本可用）** 、**Soft-state（软状态）** 和 **Eventually Consistent（最终一致性）** 三个短语的缩写。BASE 理论是对 CAP 中一致性 C 和可用性 A 权衡的结果，其来源于对大规模互联网系统分布式实践的总结，是基于 CAP 定理逐步演化而来的，它大大降低了我们对系统的要求。 + +### BASE 理论的核心思想 + +即使无法做到强一致性，但每个应用都可以根据自身业务特点，采用适当的方式来使系统达到最终一致性。 + +> 也就是牺牲数据的一致性来满足系统的高可用性，系统中一部分数据不可用或者不一致时，仍需要保持系统整体“主要可用”。 + +**BASE 理论本质上是对 CAP 的延伸和补充，更具体地说，是对 CAP 中 AP 方案的一个补充。** + +**为什么这样说呢？** + +CAP 理论这节我们也说过了： + +> 如果系统没有发生“分区”的话，节点间的网络连接通信正常的话，也就不存在 P 了。这个时候，我们就可以同时保证 C 和 A 了。因此，**如果系统发生“分区”，我们要考虑选择 CP 还是 AP。如果系统没有发生“分区”的话，我们要思考如何保证 CA 。** + +因此，AP 方案只是在系统发生分区的时候放弃一致性，而不是永远放弃一致性。在分区故障恢复后，系统应该达到最终一致性。这一点其实就是 BASE 理论延伸的地方。 + +### BASE 理论三要素 + +![BASE理论三要素](https://imgconvert.csdnimg.cn/aHR0cHM6Ly91c2VyLWdvbGQtY2RuLnhpdHUuaW8vMjAxOC81LzI0LzE2MzkxNDgwNmQ5ZTE1YzY?x-oss-process=image/format,png) + +#### 1. 基本可用 + +基本可用是指分布式系统在出现不可预知故障的时候，允许损失部分可用性。但是，这绝不等价于系统不可用。 + +**什么叫允许损失部分可用性呢？** + +- **响应时间上的损失**: 正常情况下，处理用户请求需要 0.5s 返回结果，但是由于系统出现故障，处理用户请求的时间变为 3 s。 +- **系统功能上的损失**：正常情况下，用户可以使用系统的全部功能，但是由于系统访问量突然剧增，系统的部分非核心功能无法使用。 + +#### 2. 软状态 + +软状态指允许系统中的数据存在中间状态（**CAP 理论中的数据不一致**），并认为该中间状态的存在不会影响系统的整体可用性，即允许系统在不同节点的数据副本之间进行数据同步的过程存在延时。 + +#### 3. 最终一致性 + +最终一致性强调的是系统中所有的数据副本，在经过一段时间的同步后，最终能够达到一个一致的状态。因此，最终一致性的本质是需要系统保证最终数据能够达到一致，而不需要实时保证系统数据的强一致性。 + +> 分布式一致性的 3 种级别： +> +> 1. **强一致性** ：系统写入了什么，读出来的就是什么。 +> +> 2. **弱一致性** ：不一定可以读取到最新写入的值，也不保证多少时间之后读取到的数据是最新的，只是会尽量保证某个时刻达到数据一致的状态。 +> +> 3. **最终一致性** ：弱一致性的升级版，系统会保证在一定时间内达到数据一致的状态。 +> +> **业界比较推崇是最终一致性级别，但是某些对数据一致要求十分严格的场景比如银行转账还是要保证强一致性。** + +那实现最终一致性的具体方式是什么呢? [《分布式协议与算法实战》](http://gk.link/a/10rZM) 中是这样介绍： + +> - **读时修复** : 在读取数据时，检测数据的不一致，进行修复。比如 Cassandra 的 Read Repair 实现，具体来说，在向 Cassandra 系统查询数据的时候，如果检测到不同节点 的副本数据不一致，系统就自动修复数据。 +> - **写时修复** : 在写入数据，检测数据的不一致时，进行修复。比如 Cassandra 的 Hinted Handoff 实现。具体来说，Cassandra 集群的节点之间远程写数据的时候，如果写失败 就将数据缓存下来，然后定时重传，修复数据的不一致性。 +> - **异步修复** : 这个是最常用的方式，通过定时对账检测副本数据的一致性，并修复。 + +比较推荐 **写时修复**，这种方式对性能消耗比较低。 + +### 总结 + +**ACID 是数据库事务完整性的理论，CAP 是分布式系统设计理论，BASE 是 CAP 理论中 AP 方案的延伸。** diff --git a/docs/distributed-system/theorem&algorithm&protocol/paxos-algorithm.md b/docs/distributed-system/theorem&algorithm&protocol/paxos-algorithm.md new file mode 100644 index 0000000000000000000000000000000000000000..139b3e112f9ef44ef0daf216e29963465b69ed44 --- /dev/null +++ b/docs/distributed-system/theorem&algorithm&protocol/paxos-algorithm.md @@ -0,0 +1,9 @@ +--- +title: Paxos 算法 +category: 分布式 +tag: + - 分布式协议&算法 +--- + +Paxos 算法诞生于 1990 年，这是一种解决分布式系统一致性的经典算法 。但是，由于 Paxos 算法在国际上被公认的非常难以理解和实现，因此不断有人尝试简化这一算法。到了2013 年才诞生了一个比 Paxos 算法更易理解和实现的分布式一致性算法—[Raft 算法](https://javaguide.cn/distributed-system/theorem&algorithm&protocol/raft-algorithm/)。 + diff --git a/docs/distributed-system/theorem&algorithm&protocol/raft-algorithm.md b/docs/distributed-system/theorem&algorithm&protocol/raft-algorithm.md new file mode 100644 index 0000000000000000000000000000000000000000..0cd534684f23dc4f063cbb2351003630818b1293 --- /dev/null +++ b/docs/distributed-system/theorem&algorithm&protocol/raft-algorithm.md @@ -0,0 +1,167 @@ +--- +title: Raft 算法 +category: 分布式 +tag: + - 分布式协议&算法 +--- + +## 1 背景 + +当今的数据中心和应用程序在高度动态的环境中运行，为了应对高度动态的环境，它们通过额外的服务器进行横向扩展，并且根据需求进行扩展和收缩。同时，服务器和网络故障也很常见。 + +因此，系统必须在正常操作期间处理服务器的上下线。它们必须对变故做出反应并在几秒钟内自动适应；对客户来说的话，明显的中断通常是不可接受的。 + +幸运的是，分布式共识可以帮助应对这些挑战。 + +### 1.1 拜占庭将军 + +在介绍共识算法之前，先介绍一个简化版拜占庭将军的例子来帮助理解共识算法。 + +> 假设多位拜占庭将军中没有叛军，信使的信息可靠但有可能被暗杀的情况下，将军们如何达成是否要进攻的一致性决定？ + +解决方案大致可以理解成：先在所有的将军中选出一个大将军，用来做出所有的决定。 + +举例如下：假如现在一共有 3 个将军 A，B 和 C，每个将军都有一个随机时间的倒计时器，倒计时一结束，这个将军就把自己当成大将军候选人，然后派信使传递选举投票的信息给将军 B 和 C，如果将军 B 和 C 还没有把自己当作候选人（自己的倒计时还没有结束），并且没有把选举票投给其他人，它们就会把票投给将军 A，信使回到将军 A 时，将军 A 知道自己收到了足够的票数，成为大将军。在有了大将军之后，是否需要进攻就由大将军 A 决定，然后再去派信使通知另外两个将军，自己已经成为了大将军。如果一段时间还没收到将军 B 和 C 的回复（信使可能会被暗示），那就再重派一个信使，直到收到回复。 + +### 1.2 共识算法 + +共识是可容错系统中的一个基本问题：即使面对故障，服务器也可以在共享状态上达成一致。 + +共识算法允许一组节点像一个整体一样一起工作，即使其中的一些节点出现故障也能够继续工作下去，其正确性主要是源于复制状态机的性质：一组`Server`的状态机计算相同状态的副本，即使有一部分的`Server`宕机了它们仍然能够继续运行。 + +![rsm-architecture.png](https://guide-blog-images.oss-cn-shenzhen.aliyuncs.com/github/javaguide/paxos-rsm-architecture.png) + +`图-1 复制状态机架构` + +一般通过使用复制日志来实现复制状态机。每个`Server`存储着一份包括命令序列的日志文件，状态机会按顺序执行这些命令。因为每个日志包含相同的命令，并且顺序也相同，所以每个状态机处理相同的命令序列。由于状态机是确定性的，所以处理相同的状态，得到相同的输出。 + +因此共识算法的工作就是保持复制日志的一致性。服务器上的共识模块从客户端接收命令并将它们添加到日志中。它与其他服务器上的共识模块通信，以确保即使某些服务器发生故障。每个日志最终包含相同顺序的请求。一旦命令被正确地复制，它们就被称为已提交。每个服务器的状态机按照日志顺序处理已提交的命令，并将输出返回给客户端，因此，这些服务器形成了一个单一的、高度可靠的状态机。 + +适用于实际系统的共识算法通常具有以下特性： + +- 安全。确保在非拜占庭条件（也就是上文中提到的简易版拜占庭）下的安全性，包括网络延迟、分区、包丢失、复制和重新排序。 +- 高可用。只要大多数服务器都是可操作的，并且可以相互通信，也可以与客户端进行通信，那么这些服务器就可以看作完全功能可用的。因此，一个典型的由五台服务器组成的集群可以容忍任何两台服务器端故障。假设服务器因停止而发生故障；它们稍后可能会从稳定存储上的状态中恢复并重新加入集群。 +- 一致性不依赖时序。错误的时钟和极端的消息延迟，在最坏的情况下也只会造成可用性问题，而不会产生一致性问题。 + +- 在集群中大多数服务器响应，命令就可以完成，不会被少数运行缓慢的服务器来影响整体系统性能。 + +## 2 基础 + +### 2.1 节点类型 + +一个 Raft 集群包括若干服务器，以典型的 5 服务器集群举例。在任意的时间，每个服务器一定会处于以下三个状态中的一个： + +- `Leader`：负责发起心跳，响应客户端，创建日志，同步日志。 +- `Candidate`：Leader 选举过程中的临时角色，由 Follower 转化而来，发起投票参与竞选。 +- `Follower`：接受 Leader 的心跳和日志同步数据，投票给 Candidate。 + +在正常的情况下，只有一个服务器是 Leader，剩下的服务器是 Follower。Follower 是被动的，它们不会发送任何请求，只是响应来自 Leader 和 Candidate 的请求。 + +![](https://guide-blog-images.oss-cn-shenzhen.aliyuncs.com/github/javaguide/paxos-server-state.png) + +`图-2：服务器的状态` + +### 2.2 任期 + +![](https://guide-blog-images.oss-cn-shenzhen.aliyuncs.com/github/javaguide/paxos-term.png) + +`图-3：任期` + +如图 3 所示，raft 算法将时间划分为任意长度的任期（term），任期用连续的数字表示，看作当前 term 号。每一个任期的开始都是一次选举，在选举开始时，一个或多个 Candidate 会尝试成为 Leader。如果一个 Candidate 赢得了选举，它就会在该任期内担任 Leader。如果没有选出 Leader，将会开启另一个任期，并立刻开始下一次选举。raft 算法保证在给定的一个任期最少要有一个 Leader。 + +每个节点都会存储当前的 term 号，当服务器之间进行通信时会交换当前的 term 号；如果有服务器发现自己的 term 号比其他人小，那么他会更新到较大的 term 值。如果一】个 Candidate 或者 Leader 发现自己的 term 过期了，他会立即退回成 Follower。如果一台服务器收到的请求的 term 号是过期的，那么它会拒绝此次请求。 + +### 2.3 日志 + +- `entry`：每一个事件成为 entry，只有 Leader 可以创建 entry。entry 的内容为``其中 cmd 是可以应用到状态机的操作。 +- `log`：由 entry 构成的数组，每一个 entry 都有一个表明自己在 log 中的 index。只有 Leader 才可以改变其他节点的 log。entry 总是先被 Leader 添加到自己的 log 数组中，然后再发起共识请求，获得同意后才会被 Leader 提交给状态机。Follower 只能从 Leader 获取新日志和当前的 commitIndex，然后把对应的 entry 应用到自己的状态机中。 + +## 3 领导人选举 + +raft 使用心跳机制来触发 Leader 的选举。 + +如果一台服务器能够收到来自 Leader 或者 Candidate 的有效信息，那么它会一直保持为 Follower 状态，并且刷新自己的 electionElapsed，重新计时。 + +Leader 会向所有的 Follower 周期性发送心跳来保证自己的 Leader 地位。如果一个 Follower 在一个周期内没有收到心跳信息，就叫做选举超时，然后它就会认为此时没有可用的 Leader，并且开始进行一次选举以选出一个新的 Leader。 + +为了开始新的选举，Follower 会自增自己的 term 号并且转换状态为 Candidate。然后他会向所有节点发起 RequestVoteRPC 请求， Candidate 的状态会持续到以下情况发生： + +- 赢得选举 +- 其他节点赢得选举 +- 一轮选举结束，无人胜出 + +赢得选举的条件是：一个 Candidate 在一个任期内收到了来自集群内的多数选票`（N/2+1）`，就可以成为 Leader。 + +在 Candidate 等待选票的时候，它可能收到其他节点声明自己是 Leader 的心跳，此时有两种情况： + +- 该 Leader 的 term 号大于等于自己的 term 号，说明对方已经成为 Leader，则自己回退为 Follower。 +- 该 Leader 的 term 号小于自己的 term 号，那么会拒绝该请求并让该节点更新 term。 + +由于可能同一时刻出现多个 Candidate，导致没有 Candidate 获得大多数选票，如果没有其他手段来重新分配选票的话，那么可能会无限重复下去。 + +raft 使用了随机的选举超时时间来避免上述情况。每一个 Candidate 在发起选举后，都会随机化一个新的枚举超时时间，这种机制使得各个服务器能够分散开来，在大多数情况下只有一个服务器会率先超市；它会在其他服务器超时之前赢得选举。 + +## 4 日志复制 + +一旦选出了 Leader，它就开始接受客户端的请求。每一个客户端的请求都包含一条需要被复制状态机（`Replicated State Mechine`）执行的命令。 + +Leader 收到客户端请求后，会生成一个 entry，包含``，再将这个 entry 添加到自己的日志末尾后，向所有的节点广播该 entry，要求其他服务器复制这条 entry。 + +如果 Follower 接受该 entry，则会将 entry 添加到自己的日志后面，同时返回给 Leader 同意。 + +如果 Leader 收到了多数的成功响应，Leader 会将这个 entry 应用到自己的状态机中，之后可以成为这个 entry 是 committed 的，并且向客户端返回执行结果。 + +raft 保证以下两个性质： + +- 在两个日志里，有两个 entry 拥有相同的 index 和 term，那么它们一定有相同的 cmd +- 在两个日志里，有两个 entry 拥有相同的 index 和 term，那么它们前面的 entry 也一定相同 + +通过“仅有 Leader 可以生存 entry”来保证第一个性质，第二个性质需要一致性检查来进行保证。 + +一般情况下，Leader 和 Follower 的日志保持一致，然后，Leader 的崩溃会导致日志不一样，这样一致性检查会产生失败。Leader 通过强制 Follower 复制自己的日志来处理日志的不一致。这就意味着，在 Follower 上的冲突日志会被领导者的日志覆盖。 + +为了使得 Follower 的日志和自己的日志一致，Leader 需要找到 Follower 与它日志一致的地方，然后删除 Follower 在该位置之后的日志，接着把这之后的日志发送给 Follower。 + +`Leader` 给每一个`Follower` 维护了一个 `nextIndex`，它表示 `Leader` 将要发送给该追随者的下一条日志条目的索引。当一个 `Leader` 开始掌权时，它会将 `nextIndex` 初始化为它的最新的日志条目索引数+1。如果一个 `Follower` 的日志和 `Leader` 的不一致，`AppendEntries` 一致性检查会在下一次 `AppendEntries RPC` 时返回失败。在失败之后，`Leader` 会将 `nextIndex` 递减然后重试 `AppendEntries RPC`。最终 `nextIndex` 会达到一个 `Leader` 和 `Follower` 日志一致的地方。这时，`AppendEntries` 会返回成功，`Follower` 中冲突的日志条目都被移除了，并且添加所缺少的上了 `Leader` 的日志条目。一旦 `AppendEntries` 返回成功，`Follower` 和 `Leader` 的日志就一致了，这样的状态会保持到该任期结束。 + +## 5 安全性 + +### 5.1 选举限制 + +Leader 需要保证自己存储全部已经提交的日志条目。这样才可以使日志条目只有一个流向：从 Leader 流向 Follower，Leader 永远不会覆盖已经存在的日志条目。 + +每个 Candidate 发送 RequestVoteRPC 时，都会带上最后一个 entry 的信息。所有节点收到投票信息时，会对该 entry 进行比较，如果发现自己的更新，则拒绝投票给该 Candidate。 + +判断日志新旧的方式：如果两个日志的 term 不同，term 大的更新；如果 term 相同，更长的 index 更新。 + +### 5.2 节点崩溃 + +如果 Leader 崩溃，集群中的节点在 electionTimeout 时间内没有收到 Leader 的心跳信息就会触发新一轮的选主，在选主期间整个集群对外是不可用的。 + +如果 Follower 和 Candidate 崩溃，处理方式会简单很多。之后发送给它的 RequestVoteRPC 和 AppendEntriesRPC 会失败。由于 raft 的所有请求都是幂等的，所以失败的话会无限的重试。如果崩溃恢复后，就可以收到新的请求，然后选择追加或者拒绝 entry。 + +### 5.3 时间与可用性 + +raft 的要求之一就是安全性不依赖于时间：系统不能仅仅因为一些事件发生的比预想的快一些或者慢一些就产生错误。为了保证上述要求，最好能满足以下的时间条件： + +`broadcastTime << electionTimeout << MTBF` + +- `broadcastTime`：向其他节点并发发送消息的平均响应时间； +- `electionTimeout`：选举超时时间； +- `MTBF(mean time between failures)`：单台机器的平均健康时间； + +`broadcastTime`应该比`electionTimeout`小一个数量级，为的是使`Leader`能够持续发送心跳信息（heartbeat）来阻止`Follower`开始选举； + +`electionTimeout`也要比`MTBF`小几个数量级，为的是使得系统稳定运行。当`Leader`崩溃时，大约会在整个`electionTimeout`的时间内不可用；我们希望这种情况仅占全部时间的很小一部分。 + +由于`broadcastTime`和`MTBF`是由系统决定的属性，因此需要决定`electionTimeout`的时间。 + +一般来说，broadcastTime 一般为 `0.5～20ms`，electionTimeout 可以设置为 `10～500ms`，MTBF 一般为一两个月。 + +## 6 参考 + +- https://tanxinyu.work/raft/ +- https://github.com/OneSizeFitsQuorum/raft-thesis-zh_cn/blob/master/raft-thesis-zh_cn.md +- https://github.com/ongardie/dissertation/blob/master/stanford.pdf +- https://knowledge-sharing.gitbooks.io/raft/content/chapter5.html + diff --git a/docs/high-availability/cluster.md b/docs/high-availability/cluster.md new file mode 100644 index 0000000000000000000000000000000000000000..5da34020f32a4faabdb116ff82aeeaf3357cff2f --- /dev/null +++ b/docs/high-availability/cluster.md @@ -0,0 +1,3 @@ +# 集群 + +相同的服务部署多份，避免单点故障。 \ No newline at end of file diff --git a/docs/high-availability/disaster-recovery&remote-live.md b/docs/high-availability/disaster-recovery&remote-live.md new file mode 100644 index 0000000000000000000000000000000000000000..0b8f87afa41fd76f367bb570b6f9a8d274a2ebd5 --- /dev/null +++ b/docs/high-availability/disaster-recovery&remote-live.md @@ -0,0 +1,14 @@ +# 灾备设计&异地多活 + +**灾备** = 容灾+备份。 + +- **备份** ： 将系统所产生的的所有重要数据多备份几份。 +- **容灾** ： 在异地建立两个完全相同的系统。当某个地方的系统突然挂掉，整个应用系统可以切换到另一个，这样系统就可以正常提供服务了。 + +**异地多活** 描述的是将服务部署在异地并且服务同时对外提供服务。和传统的灾备设计的最主要区别在于“多活”，即所有站点都是同时在对外提供服务的。异地多活是为了应对突发状况比如火灾、地震等自然或者人为灾害。 + +相关阅读： + +- [搞懂异地多活，看这篇就够了](https://mp.weixin.qq.com/s/T6mMDdtTfBuIiEowCpqu6Q) +- [四步构建异地多活](https://mp.weixin.qq.com/s/hMD-IS__4JE5_nQhYPYSTg) +- [《从零开始学架构》— 28 | 业务高可用的保障：异地多活架构](http://gk.link/a/10pKZ) diff --git a/docs/high-availability/fallback&circuit-breaker.md b/docs/high-availability/fallback&circuit-breaker.md new file mode 100644 index 0000000000000000000000000000000000000000..acc7b6737baeee63db0dd1a46647b8443e0b04be --- /dev/null +++ b/docs/high-availability/fallback&circuit-breaker.md @@ -0,0 +1,22 @@ +# 降级&熔断 + +降级&熔断相关的面试题为我的[知识星球](https://www.yuque.com/docs/share/8a30ffb5-83f3-40f9-baf9-38de68b906dc)专属内容，已经整理到了[《Java 面试指北》](https://www.yuque.com/docs/share/f37fc804-bfe6-4b0d-b373-9c462188fec7)中。 + +《Java 面试指北》的部分内容展示如下，你可以将其看作是 [JavaGuide](https://javaguide.cn/#/) 的补充完善，两者可以配合使用。 + +![](https://guide-blog-images.oss-cn-shenzhen.aliyuncs.com/xingqiu/1&e=1648742399&token=kIxbL07-8jAj8w1n4s9zv64FuZZNEATmlU_Vm6zD:HyfLWy5gNC5F_XukPYrlj_a4EJI=.png) + +我已经在星球更新了 **7** 个高质量的小册： **《Java 面试进阶指北》**（持续完善中）、 **《从零开始写一个 RPC 框架》**（已更新完） 、**《Kafka 常见面试题/知识点总结》**、**《程序员副业赚钱之路》**（持续完善）、**《分布式、高并发、Devops 知识扫盲》**、**《Java 必读源码系列》**（目前已经整理了 Dubbo 2.6.x 、Netty 4.x、SpringBoot2.1 的源码）（持续完善中）。 + +![](https://guide-blog-images.oss-cn-shenzhen.aliyuncs.com/xingqiu/image-20220211231206733.png) + +如果你需要专属面试小册/一对一交流/简历修改/专属求职指南/学习打卡，不妨花 3 分钟左右看看星球的详细介绍： [JavaGuide 知识星球详细介绍](https://www.yuque.com/docs/share/8a30ffb5-83f3-40f9-baf9-38de68b906dc) （一定要确定自己真的需要再加入，一定要看完详细介绍之后再加我）。 + +星球目前的定价为 **159/年**，即将调整为 **199/年**。如果的认可 JavaGuide，相信我，并且需要星球提供的专属服务，那欢迎你加入我的星球。你可以添加我的私人微信领取星球专属优惠券，限时 **100/年** 加入。一定要备注“**星球优惠券**”！ + +![](https://guide-blog-images.oss-cn-shenzhen.aliyuncs.com/xingqiu/image-20220211231926486.png) + +**用心做内容，真心希望帮助到你，拒绝知识付费割韭菜。加油！！！** + + + diff --git a/docs/high-availability/high-availability-system-design.md b/docs/high-availability/high-availability-system-design.md new file mode 100644 index 0000000000000000000000000000000000000000..e336f6762519d8927a9c35a037c885c285bc1f21 --- /dev/null +++ b/docs/high-availability/high-availability-system-design.md @@ -0,0 +1,70 @@ +# 高可用系统设计 + +一篇短小的文章，面试经常遇到的这个问题。本文主要包括下面这些内容： + +1. 高可用的定义 +2. 哪些情况可能会导致系统不可用？ +3. 有哪些提高系统可用性的方法？只是简单的提一嘴，更具体内容在后续的文章中介绍，就拿限流来说，你需要搞懂：何为限流？如何限流？为什么要限流？如何做呢？说一下原理？。 + +## 什么是高可用？可用性的判断标准是啥？ + +**高可用描述的是一个系统在大部分时间都是可用的，可以为我们提供服务的。高可用代表系统即使在发生硬件故障或者系统升级的时候，服务仍然是可用的。** + +**一般情况下，我们使用多少个 9 来评判一个系统的可用性，比如 99.9999% 就是代表该系统在所有的运行时间中只有 0.0001% 的时间是不可用的，这样的系统就是非常非常高可用的了！当然，也会有系统如果可用性不太好的话，可能连 9 都上不了。** + +除此之外，系统的可用性还可以用某功能的失败次数与总的请求次数之比来衡量，比如对网站请求 1000 次，其中有 10 次请求失败，那么可用性就是 99%。 + +## 哪些情况会导致系统不可用？ + +1. 黑客攻击； +2. 硬件故障，比如服务器坏掉。 +3. 并发量/用户请求量激增导致整个服务宕掉或者部分服务不可用。 +4. 代码中的坏味道导致内存泄漏或者其他问题导致程序挂掉。 +5. 网站架构某个重要的角色比如 Nginx 或者数据库突然不可用。 +6. 自然灾害或者人为破坏。 +7. ...... + +## 有哪些提高系统可用性的方法？ + +### 1. 注重代码质量，测试严格把关 + +我觉得这个是最最最重要的，代码质量有问题比如比较常见的内存泄漏、循环依赖都是对系统可用性极大的损害。大家都喜欢谈限流、降级、熔断，但是我觉得从代码质量这个源头把关是首先要做好的一件很重要的事情。如何提高代码质量？比较实际可用的就是 CodeReview，不要在乎每天多花的那 1 个小时左右的时间，作用可大着呢！ + +另外，安利这个对提高代码质量有实际效果的宝贝： + +1. sonarqube ：保证你写出更安全更干净的代码！（ps: 目前所在的项目基本都会用到这个插件）。 +2. Alibaba 开源的 Java 诊断工具 Arthas 也是很不错的选择。 +3. IDEA 自带的代码分析等工具进行代码扫描也是非常非常棒的。 + +### 2.使用集群，减少单点故障 + +先拿常用的 Redis 举个例子！我们如何保证我们的 Redis 缓存高可用呢？答案就是使用集群，避免单点故障。当我们使用一个 Redis 实例作为缓存的时候，这个 Redis 实例挂了之后，整个缓存服务可能就挂了。使用了集群之后，即使一台 Redis 实例挂了，不到一秒就会有另外一台 Redis 实例顶上。 + +### 3.限流 + +流量控制（flow control），其原理是监控应用流量的 QPS 或并发线程数等指标，当达到指定的阈值时对流量进行控制，以避免被瞬时的流量高峰冲垮，从而保障应用的高可用性。——来自 alibaba-[Sentinel](https://github.com/alibaba/Sentinel "Sentinel") 的 wiki。 + +### 4.超时和重试机制设置 + +一旦用户请求超过某个时间的得不到响应，就抛出异常。这个是非常重要的，很多线上系统故障都是因为没有进行超时设置或者超时设置的方式不对导致的。我们在读取第三方服务的时候，尤其适合设置超时和重试机制。一般我们使用一些 RPC 框架的时候，这些框架都自带的超时重试的配置。如果不进行超时设置可能会导致请求响应速度慢，甚至导致请求堆积进而让系统无法再处理请求。重试的次数一般设为 3 次，再多次的重试没有好处，反而会加重服务器压力（部分场景使用失败重试机制会不太适合）。 + +### 5.熔断机制 + +超时和重试机制设置之外，熔断机制也是很重要的。 熔断机制说的是系统自动收集所依赖服务的资源使用情况和性能指标，当所依赖的服务恶化或者调用失败次数达到某个阈值的时候就迅速失败，让当前系统立即切换依赖其他备用服务。 比较常用的流量控制和熔断降级框架是 Netflix 的 Hystrix 和 alibaba 的 Sentinel。 + +### 6.异步调用 + +异步调用的话我们不需要关心最后的结果，这样我们就可以用户请求完成之后就立即返回结果，具体处理我们可以后续再做，秒杀场景用这个还是蛮多的。但是，使用异步之后我们可能需要 **适当修改业务流程进行配合**，比如**用户在提交订单之后，不能立即返回用户订单提交成功，需要在消息队列的订单消费者进程真正处理完该订单之后，甚至出库后，再通过电子邮件或短信通知用户订单成功**。除了可以在程序中实现异步之外，我们常常还使用消息队列，消息队列可以通过异步处理提高系统性能（削峰、减少响应所需时间）并且可以降低系统耦合性。 + +### 7.使用缓存 + +如果我们的系统属于并发量比较高的话，如果我们单纯使用数据库的话，当大量请求直接落到数据库可能数据库就会直接挂掉。使用缓存缓存热点数据，因为缓存存储在内存中，所以速度相当地快！ + +### 8.其他 + +1. **核心应用和服务优先使用更好的硬件** +2. **监控系统资源使用情况增加报警设置。** +3. **注意备份，必要时候回滚。** +4. **灰度发布：** 将服务器集群分成若干部分，每天只发布一部分机器，观察运行稳定没有故障，第二天继续发布一部分机器，持续几天才把整个集群全部发布完毕，期间如果发现问题，只需要回滚已发布的一部分服务器即可 +5. **定期检查/更换硬件：** 如果不是购买的云服务的话，定期还是需要对硬件进行一波检查的，对于一些需要更换或者升级的硬件，要及时更换或者升级。 +6. .....(想起来再补充！也欢迎各位欢迎补充！) diff --git a/docs/high-availability/limit-request.md b/docs/high-availability/limit-request.md new file mode 100644 index 0000000000000000000000000000000000000000..8c93674f721ee9d60766db73f7a99476f637fb64 --- /dev/null +++ b/docs/high-availability/limit-request.md @@ -0,0 +1,203 @@ +# 限流 + +## 何为限流？为什么要限流？ + +针对软件系统来说，限流就是对请求的速率进行限制，避免瞬时的大量请求击垮软件系统。毕竟，软件系统的处理能力是有限的。如果说超过了其处理能力的范围，软件系统可能直接就挂掉了。 + +限流可能会导致用户的请求无法被正确处理，不过，这往往也是权衡了软件系统的稳定性之后得到的最优解。 + +现实生活中，处处都有限流的实际应用，就比如排队买票是为了避免大量用户涌入购票而导致售票员无法处理。 + +![排队示意图](https://img-blog.csdnimg.cn/f9f17071fc4d489d85d2a234fb298df1.png) + +## 常见限流算法 + +简单介绍 4 种非常好理解并且容易实现的限流算法！ + +> 图片来源于 InfoQ 的一篇文章[《分布式服务限流实战，已经为你排好坑了》](https://www.infoq.cn/article/Qg2tX8fyw5Vt-f3HH673)。 + +### 固定窗口计数器算法 + +固定窗口其实就是时间窗口。**固定窗口计数器算法** 规定了我们单位时间处理的请求数量。 + +假如我们规定系统中某个接口 1 分钟只能访问 33 次的话，使用固定窗口计数器算法的实现思路如下： + +- 给定一个变量 `counter` 来记录当前接口处理的请求数量，初始值为 0（代表接口当前 1 分钟内还未处理请求）。 +- 1 分钟之内每处理一个请求之后就将 `counter+1` ，当 `counter=33` 之后（也就是说在这 1 分钟内接口已经被访问 33 次的话），后续的请求就会被全部拒绝。 +- 等到 1 分钟结束后，将 `counter` 重置 0，重新开始计数。 + +**这种限流算法无法保证限流速率，因而无法保证突然激增的流量。** + +就比如说我们限制某个接口 1 分钟只能访问 1000 次，该接口的 QPS 为 500，前 55s 这个接口 1 个请求没有接收，后 1s 突然接收了 1000 个请求。然后，在当前场景下，这 1000 个请求在 1s 内是没办法被处理的，系统直接就被瞬时的大量请求给击垮了。 + +![固定窗口计数器算法](https://static001.infoq.cn/resource/image/8d/15/8ded7a2b90e1482093f92fff555b3615.png) + +### 滑动窗口计数器算法 + +**滑动窗口计数器算法** 算的上是固定窗口计数器算法的升级版。 + +滑动窗口计数器算法相比于固定窗口计数器算法的优化在于：**它把时间以一定比例分片** 。 + +例如我们的接口限流每分钟处理 60 个请求，我们可以把 1 分钟分为 60 个窗口。每隔 1 秒移动一次，每个窗口一秒只能处理 不大于 `60(请求数)/60（窗口数）` 的请求， 如果当前窗口的请求计数总和超过了限制的数量的话就不再处理其他请求。 + +很显然， **当滑动窗口的格子划分的越多，滑动窗口的滚动就越平滑，限流的统计就会越精确。** + +![滑动窗口计数器算法](https://static001.infoq.cn/resource/image/ae/15/ae4d3cd14efb8dc7046d691c90264715.png) + +### 漏桶算法 + +我们可以把发请求的动作比作成注水到桶中，我们处理请求的过程可以比喻为漏桶漏水。我们往桶中以任意速率流入水，以一定速率流出水。当水超过桶流量则丢弃，因为桶容量是不变的，保证了整体的速率。 + +如果想要实现这个算法的话也很简单，准备一个队列用来保存请求，然后我们定期从队列中拿请求来执行就好了（和消息队列削峰/限流的思想是一样的）。 + +![漏桶算法](https://static001.infoq.cn/resource/image/75/03/75938d1010138ce66e38c6ed0392f103.png) + +### 令牌桶算法 + +令牌桶算法也比较简单。和漏桶算法算法一样，我们的主角还是桶（这限流算法和桶过不去啊）。不过现在桶里装的是令牌了，请求在被处理之前需要拿到一个令牌，请求处理完毕之后将这个令牌丢弃（删除）。我们根据限流大小，按照一定的速率往桶里添加令牌。如果桶装满了，就不能继续往里面继续添加令牌了。 + +![令牌桶算法](https://static001.infoq.cn/resource/image/ec/93/eca0e5eaa35dac938c673fecf2ec9a93.png) + +## 单机限流 + +单机限流可以直接使用 Google Guava 自带的限流工具类 `RateLimiter` 。 `RateLimiter` 基于令牌桶算法，可以应对突发流量。 + +> Guava 地址：https://github.com/google/guava + +除了最基本的令牌桶算法(平滑突发限流)实现之外，Guava 的`RateLimiter`还提供了 **平滑预热限流** 的算法实现。 + +平滑突发限流就是按照指定的速率放令牌到桶里，而平滑预热限流会有一段预热时间，预热时间之内，速率会逐渐提升到配置的速率。 + +我们下面通过两个简单的小例子来详细了解吧！ + +我们直接在项目中引入 Guava 相关的依赖即可使用。 + +```xml + + com.google.guava + guava + 31.0.1-jre + +``` + +下面是一个简单的 Guava 平滑突发限流的 Demo。 + +```java +import com.google.common.util.concurrent.RateLimiter; + +/** + * 微信搜 JavaGuide 回复"面试突击"即可免费领取个人原创的 Java 面试手册 + * + * @author Guide哥 + * @date 2021/10/08 19:12 + **/ +public class RateLimiterDemo { + + public static void main(String[] args) { + // 1s 放 5 个令牌到桶里也就是 0.2s 放 1个令牌到桶里 + RateLimiter rateLimiter = RateLimiter.create(5); + for (int i = 0; i < 10; i++) { + double sleepingTime = rateLimiter.acquire(1); + System.out.printf("get 1 tokens: %ss%n", sleepingTime); + } + } +} + +``` + +输出： + +```bash +get 1 tokens: 0.0s +get 1 tokens: 0.188413s +get 1 tokens: 0.197811s +get 1 tokens: 0.198316s +get 1 tokens: 0.19864s +get 1 tokens: 0.199363s +get 1 tokens: 0.193997s +get 1 tokens: 0.199623s +get 1 tokens: 0.199357s +get 1 tokens: 0.195676s +``` + +下面是一个简单的 Guava 平滑预热限流的 Demo。 + +```java +import com.google.common.util.concurrent.RateLimiter; +import java.util.concurrent.TimeUnit; + +/** + * 微信搜 JavaGuide 回复"面试突击"即可免费领取个人原创的 Java 面试手册 + * + * @author Guide哥 + * @date 2021/10/08 19:12 + **/ +public class RateLimiterDemo { + + public static void main(String[] args) { + // 1s 放 5 个令牌到桶里也就是 0.2s 放 1个令牌到桶里 + // 预热时间为3s,也就说刚开始的 3s 内发牌速率会逐渐提升到 0.2s 放 1 个令牌到桶里 + RateLimiter rateLimiter = RateLimiter.create(5, 3, TimeUnit.SECONDS); + for (int i = 0; i < 20; i++) { + double sleepingTime = rateLimiter.acquire(1); + System.out.printf("get 1 tokens: %sds%n", sleepingTime); + } + } +} +``` + +输出： + +```bash +get 1 tokens: 0.0s +get 1 tokens: 0.561919s +get 1 tokens: 0.516931s +get 1 tokens: 0.463798s +get 1 tokens: 0.41286s +get 1 tokens: 0.356172s +get 1 tokens: 0.300489s +get 1 tokens: 0.252545s +get 1 tokens: 0.203996s +get 1 tokens: 0.198359s +``` + +另外，**Bucket4j** 是一个非常不错的基于令牌/漏桶算法的限流库。 + +> Bucket4j 地址：https://github.com/vladimir-bukhtoyarov/bucket4j + +相对于，Guava 的限流工具类来说，Bucket4j 提供的限流功能更加全面。不仅支持单机限流和分布式限流，还可以集成监控，搭配 Prometheus 和 Grafana 使用。 + +不过，毕竟 Guava 也只是一个功能全面的工具类库，其提供的开箱即用的限流功能在很多单机场景下还是比较实用的。 + +Spring Cloud Gateway 中自带的单机限流的早期版本就是基于 Bucket4j 实现的。后来，替换成了 **Resilience4j**。 + +Resilience4j 是一个轻量级的容错组件，其灵感来自于 Hystrix。自[Netflix 宣布不再积极开发 Hystrix](https://github.com/Netflix/Hystrix/commit/a7df971cbaddd8c5e976b3cc5f14013fe6ad00e6) 之后，Spring 官方和 Netflix 都更推荐使用 Resilience4j 来做限流熔断。 + +> Resilience4j 地址: https://github.com/resilience4j/resilience4j + +一般情况下，为了保证系统的高可用，项目的限流和熔断都是要一起做的。 + +Resilience4j 不仅提供限流，还提供了熔断、负载保护、自动重试等保障系统高可用开箱即用的功能。并且，Resilience4j 的生态也更好，很多网关都使用 Resilience4j 来做限流熔断的。 + +因此，在绝大部分场景下 Resilience4j 或许会是更好的选择。如果是一些比较简单的限流场景的话，Guava 或者 Bucket4j 也是不错的选择。 + +## 分布式限流 + +分布式限流常见的方案： + +- **借助中间件架限流** ：可以借助 Sentinel 或者使用 Redis 来自己实现对应的限流逻辑。 +- **网关层限流** ：比较常用的一种方案，直接在网关层把限流给安排上了。不过，通常网关层限流通常也需要借助到中间件/框架。就比如 Spring Cloud Gateway 的分布式限流实现`RedisRateLimiter`就是基于 Redis+Lua 来实现的，再比如 Spring Cloud Gateway 还可以整合 Sentinel 来做限流。 + +如果你要基于 Redis 来手动实现限流逻辑的话，建议配合 Lua 脚本来做。 + +网上也有很多现成的脚本供你参考，就比如 Apache 网关项目 ShenYu 的 RateLimiter 限流插件就基于 Redis + Lua 实现了令牌桶算法/并发令牌桶算法、漏桶算法、滑动窗口算法。 + +> ShenYu 地址: https://github.com/apache/incubator-shenyu + +![](https://img-blog.csdnimg.cn/e1e2a75f489e4854990dabe3b6cec522.png) + +## 相关阅读 + +- 服务治理之轻量级熔断框架 Resilience4j ：https://xie.infoq.cn/article/14786e571c1a4143ad1ef8f19 +- 超详细的 Guava RateLimiter 限流原理解析：https://cloud.tencent.com/developer/article/1408819 +- 实战 Spring Cloud Gateway 之限流篇 👍：https://www.aneasystone.com/archives/2020/08/spring-cloud-gateway-current-limiting.html diff --git a/docs/high-availability/performance-test.md b/docs/high-availability/performance-test.md new file mode 100644 index 0000000000000000000000000000000000000000..dc3ff9ba74973addc1f24d9076b3c2fad7f3d2ea --- /dev/null +++ b/docs/high-availability/performance-test.md @@ -0,0 +1,150 @@ +# 性能测试入门 + +性能测试一般情况下都是由测试这个职位去做的，那还需要我们开发学这个干嘛呢？了解性能测试的指标、分类以及工具等知识有助于我们更好地去写出性能更好的程序，另外作为开发这个角色，如果你会性能测试的话，相信也会为你的履历加分不少。 + +这篇文章是我会结合自己的实际经历以及在测试这里取的经所得，除此之外，我还借鉴了一些优秀书籍，希望对你有帮助。 + +本文思维导图： + + + +## 一 不同角色看网站性能 + +### 1.1 用户 + +当用户打开一个网站的时候，最关注的是什么？当然是网站响应速度的快慢。比如我们点击了淘宝的主页，淘宝需要多久将首页的内容呈现在我的面前，我点击了提交订单按钮需要多久返回结果等等。 + +所以，用户在体验我们系统的时候往往根据你的响应速度的快慢来评判你的网站的性能。 + +### 1.2 开发人员 + +用户与开发人员都关注速度，这个速度实际上就是我们的系统**处理用户请求的速度**。 + +开发人员一般情况下很难直观的去评判自己网站的性能，我们往往会根据网站当前的架构以及基础设施情况给一个大概的值,比如： + +1. 项目架构是分布式的吗？ +2. 用到了缓存和消息队列没有？ +3. 高并发的业务有没有特殊处理？ +4. 数据库设计是否合理？ +5. 系统用到的算法是否还需要优化？ +6. 系统是否存在内存泄露的问题？ +7. 项目使用的 Redis 缓存多大？服务器性能如何？用的是机械硬盘还是固态硬盘？ +8. ...... + +### 1.3 测试人员 + +测试人员一般会根据性能测试工具来测试，然后一般会做出一个表格。这个表格可能会涵盖下面这些重要的内容： + +1. 响应时间； +2. 请求成功率； +3. 吞吐量； +4. ...... + +### 1.4 运维人员 + +运维人员会倾向于根据基础设施和资源的利用率来判断网站的性能，比如我们的服务器资源使用是否合理、数据库资源是否存在滥用的情况、当然，这是传统的运维人员，现在 Devpos 火起来后，单纯干运维的很少了。我们这里暂且还保留有这个角色。 + +## 二 性能测试需要注意的点 + +几乎没有文章在讲性能测试的时候提到这个问题，大家都会讲如何去性能测试，有哪些性能测试指标这些东西。 + +### 2.1 了解系统的业务场景 + +**性能测试之前更需要你了解当前的系统的业务场景。** 对系统业务了解的不够深刻，我们很容易犯测试方向偏执的错误，从而导致我们忽略了对系统某些更需要性能测试的地方进行测试。比如我们的系统可以为用户提供发送邮件的功能，用户配置成功邮箱后只需输入相应的邮箱之后就能发送，系统每天大概能处理上万次发邮件的请求。很多人看到这个可能就直接开始使用相关工具测试邮箱发送接口，但是，发送邮件这个场景可能不是当前系统的性能瓶颈，这么多人用我们的系统发邮件， 还可能有很多人一起发邮件，单单这个场景就这么人用，那用户管理可能才是性能瓶颈吧！ + +### 2.2 历史数据非常有用 + +当前系统所留下的历史数据非常重要，一般情况下，我们可以通过相应的些历史数据初步判定这个系统哪些接口调用的比较多、哪些 service 承受的压力最大，这样的话，我们就可以针对这些地方进行更细致的性能测试与分析。 + +另外，这些地方也就像这个系统的一个短板一样，优化好了这些地方会为我们的系统带来质的提升。 + +### 三 性能测试的指标 + +### 3.1 响应时间 + +**响应时间就是用户发出请求到用户收到系统处理结果所需要的时间。** 重要吗？实在太重要！ + +比较出名的 2-5-8 原则是这样描述的：通常来说，2到5秒，页面体验会比较好，5到8秒还可以接受，8秒以上基本就很难接受了。另外，据统计当网站慢一秒就会流失十分之一的客户。 + +但是，在某些场景下我们也并不需要太看重 2-5-8 原则 ，比如我觉得系统导出导入大数据量这种就不需要，系统生成系统报告这种也不需要。 + +### 3.2 并发数 + +**并发数是系统能同时处理请求的数目即同时提交请求的用户数目。** + +不得不说，高并发是现在后端架构中非常非常火热的一个词了，这个与当前的互联网环境以及中国整体的互联网用户量都有很大关系。一般情况下，你的系统并发量越大，说明你的产品做的就越大。但是，并不是每个系统都需要达到像淘宝、12306 这种亿级并发量的。 + +### 3.3 吞吐量 + +吞吐量指的是系统单位时间内系统处理的请求数量。衡量吞吐量有几个重要的参数：QPS（TPS）、并发数、响应时间。 + +1. QPS（Query Per Second）：服务器每秒可以执行的查询次数； +2. TPS（Transaction Per Second）：服务器每秒处理的事务数（这里的一个事务可以理解为客户发出请求到收到服务器的过程）； +3. 并发数；系统能同时处理请求的数目即同时提交请求的用户数目。 +4. 响应时间： 一般取多次请求的平均响应时间 + +理清他们的概念，就很容易搞清楚他们之间的关系了。 + +- **QPS（TPS）** = 并发数/平均响应时间 +- **并发数** = QPS\平均响应时间 + +书中是这样描述 QPS 和 TPS 的区别的。 + +> QPS vs TPS：QPS 基本类似于 TPS，但是不同的是，对于一个页面的一次访问，形成一个TPS；但一次页面请求，可能产生多次对服务器的请求，服务器对这些请求，就可计入“QPS”之中。如，访问一个页面会请求服务器2次，一次访问，产生一个“T”，产生2个“Q”。 + +### 3.4 性能计数器 + +**性能计数器是描述服务器或者操作系统的一些数据指标如内存使用、CPU使用、磁盘与网络I/O等情况。** + +### 四 几种常见的性能测试 + +### 性能测试 + +性能测试方法是通过测试工具模拟用户请求系统，目的主要是为了测试系统的性能是否满足要求。通俗地说，这种方法就是要在特定的运行条件下验证系统的能力状态。 + +性能测试是你在对系统性能已经有了解的前提之后进行的，并且有明确的性能指标。 + +### 负载测试 + +对被测试的系统继续加大请求压力，直到服务器的某个资源已经达到饱和了，比如系统的缓存已经不够用了或者系统的响应时间已经不满足要求了。 + +负载测试说白点就是测试系统的上线。 + +### 压力测试 + +不去管系统资源的使用情况，对系统继续加大请求压力，直到服务器崩溃无法再继续提供服务。 + +### 稳定性测试 + +模拟真实场景，给系统一定压力，看看业务是否能稳定运行。 + +## 五 常用性能测试工具 + +这里就不多扩展了，有时间的话会单独拎一个熟悉的说一下。 + +### 5.1 后端常用 + +没记错的话，除了 LoadRunner 其他几款性能测试工具都是开源免费的。 + +1. Jmeter ：Apache JMeter 是 JAVA 开发的性能测试工具。 +2. LoadRunner：一款商业的性能测试工具。 +3. Galtling ：一款基于Scala 开发的高性能服务器性能测试工具。 +4. ab ：全称为 Apache Bench 。Apache 旗下的一款测试工具，非常实用。 + +### 5.2 前端常用 + +1. Fiddler：抓包工具，它可以修改请求的数据，甚至可以修改服务器返回的数据，功能非常强大，是Web 调试的利器。 +2. HttpWatch: 可用于录制HTTP请求信息的工具。 + +## 六 常见的性能优化策略 + +性能优化之前我们需要对请求经历的各个环节进行分析，排查出可能出现性能瓶颈的地方，定位问题。 + +下面是一些性能优化时，我经常拿来自问的一些问题： + +1. 系统是否需要缓存？ +2. 系统架构本身是不是就有问题？ +3. 系统是否存在死锁的地方？ +4. 系统是否存在内存泄漏？（Java 的自动回收内存虽然很方便，但是，有时候代码写的不好真的会造成内存泄漏） +5. 数据库索引使用是否合理？ +6. ...... \ No newline at end of file diff --git a/docs/high-availability/timeout-and-retry.md b/docs/high-availability/timeout-and-retry.md new file mode 100644 index 0000000000000000000000000000000000000000..9bddb0d1442d724e91bf7833380fc3a85eaafb99 --- /dev/null +++ b/docs/high-availability/timeout-and-retry.md @@ -0,0 +1,8 @@ +--- +title: 超时&重试机制 +category: 高可用 +--- + +**一旦用户的请求超过某个时间得不到响应就结束此次请求并抛出异常。** 如果不进行超时设置可能会导致请求响应速度慢，甚至导致请求堆积进而让系统无法在处理请求。 + +另外，重试的次数一般设为 3 次，再多次的重试没有好处，反而会加重服务器压力（部分场景使用失败重试机制会不太适合）。 \ No newline at end of file diff --git a/docs/high-performance/load-balancing.md b/docs/high-performance/load-balancing.md new file mode 100644 index 0000000000000000000000000000000000000000..a9d98b2cea58821f040fdad69e0a2424b2769cc7 --- /dev/null +++ b/docs/high-performance/load-balancing.md @@ -0,0 +1,13 @@ +# 负载均衡 + +负载均衡系统通常用于将任务比如用户请求处理分配到多个服务器处理以提高网站、应用或者数据库的性能和可靠性。 + +常见的负载均衡系统包括 3 种： + +1. **DNS 负载均衡** ：一般用来实现地理级别的均衡。 +2. **硬件负载均衡** ： 通过单独的硬件设备比如 F5 来实现负载均衡功能（硬件的价格一般很贵）。 +3. **软件负载均衡** ：通过负载均衡软件比如 Nginx 来实现负载均衡功能。 + +## 推荐阅读 + +- [《凤凰架构》-负载均衡](http://icyfenix.cn/architect-perspective/general-architecture/diversion-system/load-balancing.html) diff --git a/docs/high-performance/message-queue/kafka-questions-01.md b/docs/high-performance/message-queue/kafka-questions-01.md new file mode 100644 index 0000000000000000000000000000000000000000..8cea44f2225cb022225e2a86ccd69a5dcf178c8e --- /dev/null +++ b/docs/high-performance/message-queue/kafka-questions-01.md @@ -0,0 +1,222 @@ + +# Kafka知识点&面试题总结 + +### Kafka 是什么？主要应用场景有哪些？ + +Kafka 是一个分布式流式处理平台。这到底是什么意思呢？ + +流平台具有三个关键功能： + +1. **消息队列**：发布和订阅消息流，这个功能类似于消息队列，这也是 Kafka 也被归类为消息队列的原因。 +2. **容错的持久方式存储记录消息流**： Kafka 会把消息持久化到磁盘，有效避免了消息丢失的风险。 +3. **流式处理平台：** 在消息发布的时候进行处理，Kafka 提供了一个完整的流式处理类库。 + +Kafka 主要有两大应用场景： + +1. **消息队列** ：建立实时流数据管道，以可靠地在系统或应用程序之间获取数据。 +2. **数据处理：** 构建实时的流数据处理程序来转换或处理数据流。 + +### 和其他消息队列相比,Kafka的优势在哪里？ + +我们现在经常提到 Kafka 的时候就已经默认它是一个非常优秀的消息队列了，我们也会经常拿它跟 RocketMQ、RabbitMQ 对比。我觉得 Kafka 相比其他消息队列主要的优势如下： + +1. **极致的性能** ：基于 Scala 和 Java 语言开发，设计中大量使用了批量处理和异步的思想，最高可以每秒处理千万级别的消息。 +2. **生态系统兼容性无可匹敌** ：Kafka 与周边生态系统的兼容性是最好的没有之一，尤其在大数据和流计算领域。 + +实际上在早期的时候 Kafka 并不是一个合格的消息队列，早期的 Kafka 在消息队列领域就像是一个衣衫褴褛的孩子一样，功能不完备并且有一些小问题比如丢失消息、不保证消息可靠性等等。当然，这也和 LinkedIn 最早开发 Kafka 用于处理海量的日志有很大关系，哈哈哈，人家本来最开始就不是为了作为消息队列滴，谁知道后面误打误撞在消息队列领域占据了一席之地。 + +随着后续的发展，这些短板都被 Kafka 逐步修复完善。所以，**Kafka 作为消息队列不可靠这个说法已经过时！** + +### 队列模型了解吗？Kafka 的消息模型知道吗？ + +> 题外话：早期的 JMS 和 AMQP 属于消息服务领域权威组织所做的相关的标准，我在 [JavaGuide](https://github.com/Snailclimb/JavaGuide)的 [《消息队列其实很简单》](https://github.com/Snailclimb/JavaGuide#%E6%95%B0%E6%8D%AE%E9%80%9A%E4%BF%A1%E4%B8%AD%E9%97%B4%E4%BB%B6)这篇文章中介绍过。但是，这些标准的进化跟不上消息队列的演进速度，这些标准实际上已经属于废弃状态。所以，可能存在的情况是：不同的消息队列都有自己的一套消息模型。 + +#### 队列模型：早期的消息模型 + +![队列模型](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/2019-11/队列模型23.png) + +**使用队列（Queue）作为消息通信载体，满足生产者与消费者模式，一条消息只能被一个消费者使用，未被消费的消息在队列中保留直到被消费或超时。** 比如：我们生产者发送 100 条消息的话，两个消费者来消费一般情况下两个消费者会按照消息发送的顺序各自消费一半（也就是你一个我一个的消费。） + +**队列模型存在的问题：** + +假如我们存在这样一种情况：我们需要将生产者产生的消息分发给多个消费者，并且每个消费者都能接收到完整的消息内容。 + +这种情况，队列模型就不好解决了。很多比较杠精的人就说：我们可以为每个消费者创建一个单独的队列，让生产者发送多份。这是一种非常愚蠢的做法，浪费资源不说，还违背了使用消息队列的目的。 + +#### 发布-订阅模型:Kafka 消息模型 + +发布-订阅模型主要是为了解决队列模型存在的问题。 + +![发布订阅模型](https://guide-blog-images.oss-cn-shenzhen.aliyuncs.com/java-guide-blog/%E5%8F%91%E5%B8%83%E8%AE%A2%E9%98%85%E6%A8%A1%E5%9E%8B.png) + +发布订阅模型（Pub-Sub） 使用**主题（Topic）** 作为消息通信载体，类似于**广播模式**；发布者发布一条消息，该消息通过主题传递给所有的订阅者，**在一条消息广播之后才订阅的用户则是收不到该条消息的**。 + +**在发布 - 订阅模型中，如果只有一个订阅者，那它和队列模型就基本是一样的了。所以说，发布 - 订阅模型在功能层面上是可以兼容队列模型的。** + +**Kafka 采用的就是发布 - 订阅模型。** + +> **RocketMQ 的消息模型和 Kafka 基本是完全一样的。唯一的区别是 Kafka 中没有队列这个概念，与之对应的是 Partition（分区）。** + +### 什么是Producer、Consumer、Broker、Topic、Partition？ + +Kafka 将生产者发布的消息发送到 **Topic（主题）** 中，需要这些消息的消费者可以订阅这些 **Topic（主题）**，如下图所示： + +![Kafka Topic Partition](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/2019-11/KafkaTopicPartitioning.png) + +上面这张图也为我们引出了，Kafka 比较重要的几个概念： + +1. **Producer（生产者）** : 产生消息的一方。 +2. **Consumer（消费者）** : 消费消息的一方。 +3. **Broker（代理）** : 可以看作是一个独立的 Kafka 实例。多个 Kafka Broker 组成一个 Kafka Cluster。 + +同时，你一定也注意到每个 Broker 中又包含了 Topic 以及 Partition 这两个重要的概念： + +- **Topic（主题）** : Producer 将消息发送到特定的主题，Consumer 通过订阅特定的 Topic(主题) 来消费消息。 +- **Partition（分区）** : Partition 属于 Topic 的一部分。一个 Topic 可以有多个 Partition ，并且同一 Topic 下的 Partition 可以分布在不同的 Broker 上，这也就表明一个 Topic 可以横跨多个 Broker 。这正如我上面所画的图一样。 + +> 划重点：**Kafka 中的 Partition（分区） 实际上可以对应成为消息队列中的队列。这样是不是更好理解一点？** + +### Kafka 的多副本机制了解吗？带来了什么好处？ + +还有一点我觉得比较重要的是 Kafka 为分区（Partition）引入了多副本（Replica）机制。分区（Partition）中的多个副本之间会有一个叫做 leader 的家伙，其他副本称为 follower。我们发送的消息会被发送到 leader 副本，然后 follower 副本才能从 leader 副本中拉取消息进行同步。 + +> 生产者和消费者只与 leader 副本交互。你可以理解为其他副本只是 leader 副本的拷贝，它们的存在只是为了保证消息存储的安全性。当 leader 副本发生故障时会从 follower 中选举出一个 leader,但是 follower 中如果有和 leader 同步程度达不到要求的参加不了 leader 的竞选。 + +**Kafka 的多分区（Partition）以及多副本（Replica）机制有什么好处呢？** + +1. Kafka 通过给特定 Topic 指定多个 Partition, 而各个 Partition 可以分布在不同的 Broker 上, 这样便能提供比较好的并发能力（负载均衡）。 +2. Partition 可以指定对应的 Replica 数, 这也极大地提高了消息存储的安全性, 提高了容灾能力，不过也相应的增加了所需要的存储空间。 + +### Zookeeper 在 Kafka 中的作用知道吗？ + +> **要想搞懂 zookeeper 在 Kafka 中的作用 一定要自己搭建一个 Kafka 环境然后自己进 zookeeper 去看一下有哪些文件夹和 Kafka 有关，每个节点又保存了什么信息。** 一定不要光看不实践，这样学来的也终会忘记！这部分内容参考和借鉴了这篇文章：https://www.jianshu.com/p/a036405f989c 。 + + + +下图就是我的本地 Zookeeper ，它成功和我本地的 Kafka 关联上（以下文件夹结构借助 idea 插件 Zookeeper tool 实现）。 + + + +ZooKeeper 主要为 Kafka 提供元数据的管理的功能。 + +从图中我们可以看出，Zookeeper 主要为 Kafka 做了下面这些事情： + +1. **Broker 注册** ：在 Zookeeper 上会有一个专门**用来进行 Broker 服务器列表记录**的节点。每个 Broker 在启动时，都会到 Zookeeper 上进行注册，即到 `/brokers/ids` 下创建属于自己的节点。每个 Broker 就会将自己的 IP 地址和端口等信息记录到该节点中去 +2. **Topic 注册** ： 在 Kafka 中，同一个**Topic 的消息会被分成多个分区**并将其分布在多个 Broker 上，**这些分区信息及与 Broker 的对应关系**也都是由 Zookeeper 在维护。比如我创建了一个名字为 my-topic 的主题并且它有两个分区，对应到 zookeeper 中会创建这些文件夹：`/brokers/topics/my-topic/Partitions/0`、`/brokers/topics/my-topic/Partitions/1` +3. **负载均衡** ：上面也说过了 Kafka 通过给特定 Topic 指定多个 Partition, 而各个 Partition 可以分布在不同的 Broker 上, 这样便能提供比较好的并发能力。 对于同一个 Topic 的不同 Partition，Kafka 会尽力将这些 Partition 分布到不同的 Broker 服务器上。当生产者产生消息后也会尽量投递到不同 Broker 的 Partition 里面。当 Consumer 消费的时候，Zookeeper 可以根据当前的 Partition 数量以及 Consumer 数量来实现动态负载均衡。 +4. ...... + +### Kafka 如何保证消息的消费顺序？ + +我们在使用消息队列的过程中经常有业务场景需要严格保证消息的消费顺序，比如我们同时发了 2 个消息，这 2 个消息对应的操作分别对应的数据库操作是： + +1. 更改用户会员等级。 +2. 根据会员等级计算订单价格。 + +假如这两条消息的消费顺序不一样造成的最终结果就会截然不同。 + +我们知道 Kafka 中 Partition(分区)是真正保存消息的地方，我们发送的消息都被放在了这里。而我们的 Partition(分区) 又存在于 Topic(主题) 这个概念中，并且我们可以给特定 Topic 指定多个 Partition。 + +![](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/2019-11/KafkaTopicPartionsLayout.png) + +每次添加消息到 Partition(分区) 的时候都会采用尾加法，如上图所示。 **Kafka 只能为我们保证 Partition(分区) 中的消息有序。** + +> 消息在被追加到 Partition(分区)的时候都会分配一个特定的偏移量（offset）。Kafka 通过偏移量（offset）来保证消息在分区内的顺序性。 + +所以，我们就有一种很简单的保证消息消费顺序的方法：**1 个 Topic 只对应一个 Partition**。这样当然可以解决问题，但是破坏了 Kafka 的设计初衷。 + +Kafka 中发送 1 条消息的时候，可以指定 topic, partition, key,data（数据） 4 个参数。如果你发送消息的时候指定了 Partition 的话，所有消息都会被发送到指定的 Partition。并且，同一个 key 的消息可以保证只发送到同一个 partition，这个我们可以采用表/对象的 id 来作为 key 。 + +总结一下，对于如何保证 Kafka 中消息消费的顺序，有了下面两种方法： + +1. 1 个 Topic 只对应一个 Partition。 +2. （推荐）发送消息的时候指定 key/Partition。 + +当然不仅仅只有上面两种方法，上面两种方法是我觉得比较好理解的， + +### Kafka 如何保证消息不丢失 + +#### 生产者丢失消息的情况 + +生产者(Producer) 调用`send`方法发送消息之后，消息可能因为网络问题并没有发送过去。 + +所以，我们不能默认在调用`send`方法发送消息之后消息发送成功了。为了确定消息是发送成功，我们要判断消息发送的结果。但是要注意的是 Kafka 生产者(Producer) 使用 `send` 方法发送消息实际上是异步的操作，我们可以通过 `get()`方法获取调用结果，但是这样也让它变为了同步操作，示例代码如下： + +> **详细代码见我的这篇文章：[Kafka系列第三篇！10 分钟学会如何在 Spring Boot 程序中使用 Kafka 作为消息队列?](https://mp.weixin.qq.com/s?__biz=Mzg2OTA0Njk0OA==&mid=2247486269&idx=2&sn=ec00417ad641dd8c3d145d74cafa09ce&chksm=cea244f6f9d5cde0c8eb233fcc4cf82e11acd06446719a7af55230649863a3ddd95f78d111de&token=1633957262&lang=zh_CN#rd)** + +```java +SendResult sendResult = kafkaTemplate.send(topic, o).get(); +if (sendResult.getRecordMetadata() != null) { + logger.info("生产者成功发送消息到" + sendResult.getProducerRecord().topic() + "-> " + sendRe + sult.getProducerRecord().value().toString()); +} +``` + +但是一般不推荐这么做！可以采用为其添加回调函数的形式，示例代码如下： + +````java + ListenableFuture> future = kafkaTemplate.send(topic, o); + future.addCallback(result -> logger.info("生产者成功发送消息到topic:{} partition:{}的消息", result.getRecordMetadata().topic(), result.getRecordMetadata().partition()), + ex -> logger.error("生产者发送消失败，原因：{}", ex.getMessage())); +```` + +如果消息发送失败的话，我们检查失败的原因之后重新发送即可！ + +**另外这里推荐为 Producer 的`retries `（重试次数）设置一个比较合理的值，一般是 3 ，但是为了保证消息不丢失的话一般会设置比较大一点。设置完成之后，当出现网络问题之后能够自动重试消息发送，避免消息丢失。另外，建议还要设置重试间隔，因为间隔太小的话重试的效果就不明显了，网络波动一次你3次一下子就重试完了** + +#### 消费者丢失消息的情况 + +我们知道消息在被追加到 Partition(分区)的时候都会分配一个特定的偏移量（offset）。偏移量（offset)表示 Consumer 当前消费到的 Partition(分区)的所在的位置。Kafka 通过偏移量（offset）可以保证消息在分区内的顺序性。 + +![kafka offset](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/2019-11/kafka-offset.jpg) + +当消费者拉取到了分区的某个消息之后，消费者会自动提交了 offset。自动提交的话会有一个问题，试想一下，当消费者刚拿到这个消息准备进行真正消费的时候，突然挂掉了，消息实际上并没有被消费，但是 offset 却被自动提交了。 + +**解决办法也比较粗暴，我们手动关闭自动提交 offset，每次在真正消费完消息之后再自己手动提交 offset 。** 但是，细心的朋友一定会发现，这样会带来消息被重新消费的问题。比如你刚刚消费完消息之后，还没提交 offset，结果自己挂掉了，那么这个消息理论上就会被消费两次。 + +#### Kafka 弄丢了消息 + + 我们知道 Kafka 为分区（Partition）引入了多副本（Replica）机制。分区（Partition）中的多个副本之间会有一个叫做 leader 的家伙，其他副本称为 follower。我们发送的消息会被发送到 leader 副本，然后 follower 副本才能从 leader 副本中拉取消息进行同步。生产者和消费者只与 leader 副本交互。你可以理解为其他副本只是 leader 副本的拷贝，它们的存在只是为了保证消息存储的安全性。 + +**试想一种情况：假如 leader 副本所在的 broker 突然挂掉，那么就要从 follower 副本重新选出一个 leader ，但是 leader 的数据还有一些没有被 follower 副本的同步的话，就会造成消息丢失。** + +**设置 acks = all** + +解决办法就是我们设置 **acks = all**。acks 是 Kafka 生产者(Producer) 很重要的一个参数。 + +acks 的默认值即为1，代表我们的消息被leader副本接收之后就算被成功发送。当我们配置 **acks = all** 代表则所有副本都要接收到该消息之后该消息才算真正成功被发送。 + +**设置 replication.factor >= 3** + +为了保证 leader 副本能有 follower 副本能同步消息，我们一般会为 topic 设置 **replication.factor >= 3**。这样就可以保证每个 分区(partition) 至少有 3 个副本。虽然造成了数据冗余，但是带来了数据的安全性。 + +**设置 min.insync.replicas > 1** + +一般情况下我们还需要设置 **min.insync.replicas> 1** ，这样配置代表消息至少要被写入到 2 个副本才算是被成功发送。**min.insync.replicas** 的默认值为 1 ，在实际生产中应尽量避免默认值 1。 + +但是，为了保证整个 Kafka 服务的高可用性，你需要确保 **replication.factor > min.insync.replicas** 。为什么呢？设想一下假如两者相等的话，只要是有一个副本挂掉，整个分区就无法正常工作了。这明显违反高可用性！一般推荐设置成 **replication.factor = min.insync.replicas + 1**。 + +**设置 unclean.leader.election.enable = false** + +> **Kafka 0.11.0.0版本开始 unclean.leader.election.enable 参数的默认值由原来的true 改为false** + +我们最开始也说了我们发送的消息会被发送到 leader 副本，然后 follower 副本才能从 leader 副本中拉取消息进行同步。多个 follower 副本之间的消息同步情况不一样，当我们配置了 **unclean.leader.election.enable = false** 的话，当 leader 副本发生故障时就不会从 follower 副本中和 leader 同步程度达不到要求的副本中选择出 leader ，这样降低了消息丢失的可能性。 + +### Kafka 如何保证消息不重复消费 + +**kafka出现消息重复消费的原因：** + +- 服务端侧已经消费的数据没有成功提交 offset（根本原因）。 +- Kafka 侧 由于服务端处理业务时间长或者网络链接等等原因让 Kafka 认为服务假死，触发了分区 rebalance。 + +**解决方案：** + +- 消费消息服务做幂等校验，比如 Redis 的set、MySQL 的主键等天然的幂等功能。这种方法最有效。 +- 将 **`enable.auto.commit`** 参数设置为 false，关闭自动提交，开发者在代码中手动提交 offset。那么这里会有个问题：**什么时候提交offset合适？** + * 处理完消息再提交：依旧有消息重复消费的风险，和自动提交一样 + * 拉取到消息即提交：会有消息丢失的风险。允许消息延时的场景，一般会采用这种方式。然后，通过定时任务在业务不繁忙（比如凌晨）的时候做数据兜底。 + +### Reference + +- Kafka 官方文档： https://kafka.apache.org/documentation/ +- 极客时间—《Kafka核心技术与实战》第11节：无消息丢失配置怎么实现？ diff --git a/docs/high-performance/message-queue/message-queue.md b/docs/high-performance/message-queue/message-queue.md new file mode 100644 index 0000000000000000000000000000000000000000..161bd5a021d9101e6b57ec26aeb42b1305b43006 --- /dev/null +++ b/docs/high-performance/message-queue/message-queue.md @@ -0,0 +1,138 @@ +# 消息队列知识点&面试题总结 + +“RabbitMQ？”“Kafka？”“RocketMQ？”...在日常学习与开发过程中，我们常常听到消息队列这个关键词。我也在我的多篇文章中提到了这个概念。可能你是熟练使用消息队列的老手，又或者你是不懂消息队列的新手，不论你了不了解消息队列，本文都将带你搞懂消息队列的一些基本理论。如果你是老手，你可能从本文学到你之前不曾注意的一些关于消息队列的重要概念，如果你是新手，相信本文将是你打开消息队列大门的一板砖。 + +## 一 什么是消息队列 + +我们可以把消息队列看作是一个存放消息的容器，当我们需要使用消息的时候，直接从容器中取出消息供自己使用即可。 + +![Message queue](https://guide-blog-images.oss-cn-shenzhen.aliyuncs.com/%E6%B6%88%E6%81%AF%E9%98%9F%E5%88%97/message-queue-small.png) + +消息队列是分布式系统中重要的组件之一。使用消息队列主要是为了通过异步处理提高系统性能和削峰、降低系统耦合性。 + +我们知道队列 Queue 是一种先进先出的数据结构，所以消费消息时也是按照顺序来消费的。 + +## 二 为什么要用消息队列 + +通常来说，使用消息队列能为我们的系统带来下面三点好处： + +1. **通过异步处理提高系统性能（减少响应所需时间）。** +2. **削峰/限流** +3. **降低系统耦合性。** + +如果在面试的时候你被面试官问到这个问题的话，一般情况是你在你的简历上涉及到消息队列这方面的内容，这个时候推荐你结合你自己的项目来回答。 + +《大型网站技术架构》第四章和第七章均有提到消息队列对应用性能及扩展性的提升。 + +### 2.1 通过异步处理提高系统性能（减少响应所需时间） + +![通过异步处理提高系统性能](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/2019-11/Asynchronous-message-queue.png) + +将用户的请求数据存储到消息队列之后就立即返回结果。随后，系统再对消息进行消费。 + +因为用户请求数据写入消息队列之后就立即返回给用户了，但是请求数据在后续的业务校验、写数据库等操作中可能失败。因此，**使用消息队列进行异步处理之后，需要适当修改业务流程进行配合**，比如用户在提交订单之后，订单数据写入消息队列，不能立即返回用户订单提交成功，需要在消息队列的订单消费者进程真正处理完该订单之后，甚至出库后，再通过电子邮件或短信通知用户订单成功，以免交易纠纷。这就类似我们平时手机订火车票和电影票。 + +### 2.2 削峰/限流 + +**先将短时间高并发产生的事务消息存储在消息队列中，然后后端服务再慢慢根据自己的能力去消费这些消息，这样就避免直接把后端服务打垮掉。** + +举例：在电子商务一些秒杀、促销活动中，合理使用消息队列可以有效抵御促销活动刚开始大量订单涌入对系统的冲击。如下图所示： + +![削峰](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/2019-11/削峰-消息队列.png) + +### 2.3 降低系统耦合性 + +使用消息队列还可以降低系统耦合性。我们知道如果模块之间不存在直接调用，那么新增模块或者修改模块就对其他模块影响较小，这样系统的可扩展性无疑更好一些。还是直接上图吧： + +![解耦](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/2019-11/消息队列-解耦.png) + +生产者（客户端）发送消息到消息队列中去，接受者（服务端）处理消息，需要消费的系统直接去消息队列取消息进行消费即可而不需要和其他系统有耦合，这显然也提高了系统的扩展性。 + +**消息队列使利用发布-订阅模式工作，消息发送者（生产者）发布消息，一个或多个消息接受者（消费者）订阅消息。** 从上图可以看到**消息发送者（生产者）和消息接受者（消费者）之间没有直接耦合**，消息发送者将消息发送至分布式消息队列即结束对消息的处理，消息接受者从分布式消息队列获取该消息后进行后续处理，并不需要知道该消息从何而来。**对新增业务，只要对该类消息感兴趣，即可订阅该消息，对原有系统和业务没有任何影响，从而实现网站业务的可扩展性设计**。 + +消息接受者对消息进行过滤、处理、包装后，构造成一个新的消息类型，将消息继续发送出去，等待其他消息接受者订阅该消息。因此基于事件（消息对象）驱动的业务架构可以是一系列流程。 + +另外，为了避免消息队列服务器宕机造成消息丢失，会将成功发送到消息队列的消息存储在消息生产者服务器上，等消息真正被消费者服务器处理后才删除消息。在消息队列服务器宕机后，生产者服务器会选择分布式消息队列服务器集群中的其他服务器发布消息。 + +**备注：** 不要认为消息队列只能利用发布-订阅模式工作，只不过在解耦这个特定业务环境下是使用发布-订阅模式的。除了发布-订阅模式，还有点对点订阅模式（一个消息只有一个消费者），我们比较常用的是发布-订阅模式。另外，这两种消息模型是 JMS 提供的，AMQP 协议还提供了 5 种消息模型。 + +## 三 使用消息队列带来的一些问题 + +- **系统可用性降低：** 系统可用性在某种程度上降低，为什么这样说呢？在加入 MQ 之前，你不用考虑消息丢失或者说 MQ 挂掉等等的情况，但是，引入 MQ 之后你就需要去考虑了！ +- **系统复杂性提高：** 加入 MQ 之后，你需要保证消息没有被重复消费、处理消息丢失的情况、保证消息传递的顺序性等等问题！ +- **一致性问题：** 我上面讲了消息队列可以实现异步，消息队列带来的异步确实可以提高系统响应速度。但是，万一消息的真正消费者并没有正确消费消息怎么办？这样就会导致数据不一致的情况了! + +## 四 JMS VS AMQP + +### 4.1 JMS + +#### 4.1.1 JMS 简介 + +JMS（JAVA Message Service,java 消息服务）是 java 的消息服务，JMS 的客户端之间可以通过 JMS 服务进行异步的消息传输。**JMS（JAVA Message Service，Java 消息服务）API 是一个消息服务的标准或者说是规范**，允许应用程序组件基于 JavaEE 平台创建、发送、接收和读取消息。它使分布式通信耦合度更低，消息服务更加可靠以及异步性。 + +**ActiveMQ 就是基于 JMS 规范实现的。** + +#### 4.1.2 JMS 两种消息模型 + +**① 点到点（P2P）模型** + +![队列模型](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/2019-11/队列模型23.png) + +使用**队列（Queue）**作为消息通信载体；满足**生产者与消费者模式**，一条消息只能被一个消费者使用，未被消费的消息在队列中保留直到被消费或超时。比如：我们生产者发送 100 条消息的话，两个消费者来消费一般情况下两个消费者会按照消息发送的顺序各自消费一半（也就是你一个我一个的消费。） + +**② 发布/订阅（Pub/Sub）模型** + +![发布订阅模型](https://guide-blog-images.oss-cn-shenzhen.aliyuncs.com/java-guide-blog/%E5%8F%91%E5%B8%83%E8%AE%A2%E9%98%85%E6%A8%A1%E5%9E%8B.png) + +发布订阅模型（Pub/Sub） 使用**主题（Topic）**作为消息通信载体，类似于**广播模式**；发布者发布一条消息，该消息通过主题传递给所有的订阅者，**在一条消息广播之后才订阅的用户则是收不到该条消息的**。 + +#### 4.1.3 JMS 五种不同的消息正文格式 + +JMS 定义了五种不同的消息正文格式，以及调用的消息类型，允许你发送并接收以一些不同形式的数据，提供现有消息格式的一些级别的兼容性。 + +- StreamMessage -- Java 原始值的数据流 +- MapMessage--一套名称-值对 +- TextMessage--一个字符串对象 +- ObjectMessage--一个序列化的 Java 对象 +- BytesMessage--一个字节的数据流 + +### 4.2 AMQP + +AMQP，即 Advanced Message Queuing Protocol，一个提供统一消息服务的应用层标准 **高级消息队列协议**（二进制应用层协议），是应用层协议的一个开放标准，为面向消息的中间件设计，兼容 JMS。基于此协议的客户端与消息中间件可传递消息，并不受客户端/中间件同产品，不同的开发语言等条件的限制。 + +**RabbitMQ 就是基于 AMQP 协议实现的。** + +### 4.3 JMS vs AMQP + +| 对比方向 | JMS | AMQP | +| :----------- | :-------------------------------------- | :----------------------------------------------------------- | +| 定义 | Java API | 协议 | +| 跨语言 | 否 | 是 | +| 跨平台 | 否 | 是 | +| 支持消息类型 | 提供两种消息模型：①Peer-2-Peer;②Pub/sub | 提供了五种消息模型：①direct exchange；②fanout exchange；③topic change；④headers exchange；⑤system exchange。本质来讲，后四种和 JMS 的 pub/sub 模型没有太大差别，仅是在路由机制上做了更详细的划分； | +| 支持消息类型 | 支持多种消息类型 ，我们在上面提到过 | byte[]（二进制） | + +**总结：** + +- AMQP 为消息定义了线路层（wire-level protocol）的协议，而 JMS 所定义的是 API 规范。在 Java 体系中，多个 client 均可以通过 JMS 进行交互，不需要应用修改代码，但是其对跨平台的支持较差。而 AMQP 天然具有跨平台、跨语言特性。 +- JMS 支持 TextMessage、MapMessage 等复杂的消息类型；而 AMQP 仅支持 byte[] 消息类型（复杂的类型可序列化后发送）。 +- 由于 Exchange 提供的路由算法，AMQP 可以提供多样化的路由方式来传递消息到消息队列，而 JMS 仅支持 队列 和 主题/订阅 方式两种。 + +## 五 常见的消息队列对比 + +| 对比方向 | 概要 | +| -------- | ------------------------------------------------------------ | +| 吞吐量 | 万级的 ActiveMQ 和 RabbitMQ 的吞吐量（ActiveMQ 的性能最差）要比 十万级甚至是百万级的 RocketMQ 和 Kafka 低一个数量级。 | +| 可用性 | 都可以实现高可用。ActiveMQ 和 RabbitMQ 都是基于主从架构实现高可用性。RocketMQ 基于分布式架构。 kafka 也是分布式的，一个数据多个副本，少数机器宕机，不会丢失数据，不会导致不可用 | +| 时效性 | RabbitMQ 基于 erlang 开发，所以并发能力很强，性能极其好，延时很低，达到微秒级。其他三个都是 ms 级。 | +| 功能支持 | 除了 Kafka，其他三个功能都较为完备。 Kafka 功能较为简单，主要支持简单的 MQ 功能，在大数据领域的实时计算以及日志采集被大规模使用，是事实上的标准 | +| 消息丢失 | ActiveMQ 和 RabbitMQ 丢失的可能性非常低， RocketMQ 和 Kafka 理论上不会丢失。 | + +**总结：** + +- ActiveMQ 的社区算是比较成熟，但是较目前来说，ActiveMQ 的性能比较差，而且版本迭代很慢，不推荐使用。 +- RabbitMQ 在吞吐量方面虽然稍逊于 Kafka 和 RocketMQ ，但是由于它基于 erlang 开发，所以并发能力很强，性能极其好，延时很低，达到微秒级。但是也因为 RabbitMQ 基于 erlang 开发，所以国内很少有公司有实力做 erlang 源码级别的研究和定制。如果业务场景对并发量要求不是太高（十万级、百万级），那这四种消息队列中，RabbitMQ 一定是你的首选。如果是大数据领域的实时计算、日志采集等场景，用 Kafka 是业内标准的，绝对没问题，社区活跃度很高，绝对不会黄，何况几乎是全世界这个领域的事实性规范。 +- RocketMQ 阿里出品，Java 系开源项目，源代码我们可以直接阅读，然后可以定制自己公司的 MQ，并且 RocketMQ 有阿里巴巴的实际业务场景的实战考验。RocketMQ 社区活跃度相对较为一般，不过也还可以，文档相对来说简单一些，然后接口这块不是按照标准 JMS 规范走的有些系统要迁移需要修改大量代码。还有就是阿里出台的技术，你得做好这个技术万一被抛弃，社区黄掉的风险，那如果你们公司有技术实力我觉得用 RocketMQ 挺好的 +- Kafka 的特点其实很明显，就是仅仅提供较少的核心功能，但是提供超高的吞吐量，ms 级的延迟，极高的可用性以及可靠性，而且分布式可以任意扩展。同时 kafka 最好是支撑较少的 topic 数量即可，保证其超高吞吐量。kafka 唯一的一点劣势是有可能消息重复消费，那么对数据准确性会造成极其轻微的影响，在大数据领域中以及日志采集中，这点轻微影响可以忽略这个特性天然适合大数据实时计算以及日志收集。 + +参考：《Java 工程师面试突击第 1 季-中华石杉老师》 \ No newline at end of file diff --git "a/\350\256\241\347\256\227\346\234\272\347\275\221\347\273\234\344\270\216\346\225\260\346\215\256\351\200\232\344\277\241/rabbitmq.md" b/docs/high-performance/message-queue/rabbitmq-intro.md similarity index 78% rename from "\350\256\241\347\256\227\346\234\272\347\275\221\347\273\234\344\270\216\346\225\260\346\215\256\351\200\232\344\277\241/rabbitmq.md" rename to docs/high-performance/message-queue/rabbitmq-intro.md index 7b1508f456c008962cac5e43d78e0706b44697b5..d676114c8e69a3ccce00aa8a56033456cafa3b10 100644 --- "a/\350\256\241\347\256\227\346\234\272\347\275\221\347\273\234\344\270\216\346\225\260\346\215\256\351\200\232\344\277\241/rabbitmq.md" +++ b/docs/high-performance/message-queue/rabbitmq-intro.md @@ -1,25 +1,5 @@ - - -- [一文搞懂 RabbitMQ 的重要概念以及安装](#一文搞懂-rabbitmq-的重要概念以及安装) - - [一 RabbitMQ 介绍](#一-rabbitmq-介绍) - - [1.1 RabbitMQ 简介](#11-rabbitmq-简介) - - [1.2 RabbitMQ 核心概念](#12-rabbitmq-核心概念) - - [1.2.1 Producer(生产者) 和 Consumer(消费者)](#121-producer生产者-和-consumer消费者) - - [1.2.2 Exchange(交换器)](#122-exchange交换器) - - [1.2.3 Queue(消息队列)](#123-queue消息队列) - - [1.2.4 Broker（消息中间件的服务节点）](#124-broker消息中间件的服务节点) - - [1.2.5 Exchange Types(交换器类型)](#125-exchange-types交换器类型) - - [① fanout](#①-fanout) - - [② direct](#②-direct) - - [③ topic](#③-topic) - - [④ headers(不推荐)](#④-headers不推荐) - - [二 安装 RabbitMq](#二-安装-rabbitmq) - - [2.1 安装 erlang](#21-安装-erlang) - - [2.2 安装 RabbitMQ](#22-安装-rabbitmq) - - - -# 一文搞懂 RabbitMQ 的重要概念以及安装 + +# RabbitMQ 入门总结 ## 一 RabbitMQ 介绍 @@ -32,7 +12,7 @@ RabbitMQ 是采用 Erlang 语言实现 AMQP(Advanced Message Queuing Protocol， RabbitMQ 发展到今天，被越来越多的人认可，这和它在易用性、扩展性、可靠性和高可用性等方面的卓著表现是分不开的。RabbitMQ 的具体特点可以概括为以下几点： - **可靠性：** RabbitMQ使用一些机制来保证消息的可靠性，如持久化、传输确认及发布确认等。 -- **灵活的路由：** 在消息进入队列之前，通过交换器来路由消息。对于典型的路由功能，RabbitMQ 己经提供了一些内置的交换器来实现。针对更复杂的路由功能，可以将多个交换器绑定在一起，也可以通过插件机制来实现自己的交换器。这个后面会在我们将 RabbitMQ 核心概念的时候详细介绍到。 +- **灵活的路由：** 在消息进入队列之前，通过交换器来路由消息。对于典型的路由功能，RabbitMQ 己经提供了一些内置的交换器来实现。针对更复杂的路由功能，可以将多个交换器绑定在一起，也可以通过插件机制来实现自己的交换器。这个后面会在我们讲 RabbitMQ 核心概念的时候详细介绍到。 - **扩展性：** 多个RabbitMQ节点可以组成一个集群，也可以根据实际业务情况动态地扩展集群中节点。 - **高可用性：** 队列可以在集群中的机器上设置镜像，使得在部分节点出现问题的情况下队列仍然可用。 - **支持多种协议：** RabbitMQ 除了原生支持 AMQP 协议，还支持 STOMP、MQTT 等多种消息中间件协议。 @@ -46,7 +26,7 @@ RabbitMQ 整体上是一个生产者与消费者模型，主要负责接收、 下面再来看看图1—— RabbitMQ 的整体模型架构。 -![图1-RabbitMQ 的整体模型架构](http://my-blog-to-use.oss-cn-beijing.aliyuncs.com/18-12-16/96388546.jpg) +![图1-RabbitMQ 的整体模型架构](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/18-12-16/96388546.jpg) 下面我会一一介绍上图中的一些概念。 @@ -67,7 +47,7 @@ RabbitMQ 整体上是一个生产者与消费者模型，主要负责接收、 Exchange(交换器) 示意图如下： -![Exchange(交换器) 示意图](http://my-blog-to-use.oss-cn-beijing.aliyuncs.com/18-12-16/24007899.jpg) +![Exchange(交换器) 示意图](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/18-12-16/24007899.jpg) 生产者将消息发给交换器的时候，一般会指定一个 **RoutingKey(路由键)**，用来指定这个消息的路由规则，而这个 **RoutingKey 需要与交换器类型和绑定键(BindingKey)联合使用才能最终生效**。 @@ -75,7 +55,7 @@ RabbitMQ 中通过 **Binding(绑定)** 将 **Exchange(交换器)** 与 **Queue( Binding(绑定) 示意图： -![Binding(绑定) 示意图](http://my-blog-to-use.oss-cn-beijing.aliyuncs.com/18-12-16/70553134.jpg) +![Binding(绑定) 示意图](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/18-12-16/70553134.jpg) 生产者将消息发送给交换器时，需要一个RoutingKey,当 BindingKey 和 RoutingKey 相匹配时，消息会被路由到对应的队列中。在绑定多个队列到同一个交换器的时候，这些绑定允许使用相同的 BindingKey。BindingKey 并不是在所有的情况下都生效，它依赖于交换器类型，比如fanout类型的交换器就会无视，而是将消息路由到所有绑定到该交换器的队列中。 @@ -85,7 +65,7 @@ Binding(绑定) 示意图： **RabbitMQ** 中消息只能存储在 **队列** 中，这一点和 **Kafka** 这种消息中间件相反。Kafka 将消息存储在 **topic（主题）** 这个逻辑层面，而相对应的队列逻辑只是topic实际存储文件中的位移标识。 RabbitMQ 的生产者生产消息并最终投递到队列中，消费者可以从队列中获取消息并消费。 -**多个消费者可以订阅同一个队列**，这时队列中的消息会被平均分摊（Round-Robin，即轮询）给多个消费者进行处理，而不是每个消费者都收到所有的消息并处理，这样避免的消息被重复消费。 +**多个消费者可以订阅同一个队列**，这时队列中的消息会被平均分摊（Round-Robin，即轮询）给多个消费者进行处理，而不是每个消费者都收到所有的消息并处理，这样避免消息被重复消费。 **RabbitMQ** 不支持队列层面的广播消费,如果有广播消费的需求，需要在其上进行二次开发,这样会很麻烦，不建议这样做。 @@ -95,7 +75,7 @@ Binding(绑定) 示意图： 下图展示了生产者将消息存入 RabbitMQ Broker,以及消费者从Broker中消费数据的整个流程。 -![消息队列的运转过程](http://my-blog-to-use.oss-cn-beijing.aliyuncs.com/18-12-16/67952922.jpg) +![消息队列的运转过程](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/18-12-16/67952922.jpg) 这样图1中的一些关于 RabbitMQ 的基本概念我们就介绍完毕了，下面再来介绍一下 **Exchange Types(交换器类型)** 。 @@ -111,7 +91,7 @@ fanout 类型的Exchange路由规则非常简单，它会把所有发送到该Ex direct 类型的Exchange路由规则也很简单，它会把消息路由到那些 Bindingkey 与 RoutingKey 完全匹配的 Queue 中。 -![direct 类型交换器](http://my-blog-to-use.oss-cn-beijing.aliyuncs.com/18-12-16/37008021.jpg) +![direct 类型交换器](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/18-12-16/37008021.jpg) 以上图为例，如果发送消息的时候设置路由键为“warning”,那么消息会路由到 Queue1 和 Queue2。如果在发送消息的时候设置路由键为"Info”或者"debug”，消息只会路由到Queue2。如果以其他的路由键发送消息，则消息不会路由到这两个队列中。 @@ -123,28 +103,32 @@ direct 类型常用在处理有优先级的任务，根据任务的优先级把 - RoutingKey 为一个点号“．”分隔的字符串（被点号“．”分隔开的每一段独立的字符串称为一个单词），如 “com.rabbitmq.client”、“java.util.concurrent”、“com.hidden.client”; - BindingKey 和 RoutingKey 一样也是点号“．”分隔的字符串； -- BindingKey 中可以存在两种特殊字符串“*”和“#”，用于做模糊匹配，其中“#”用于匹配一个单词，“#”用于匹配多规格单词(可以是零个)。 +- BindingKey 中可以存在两种特殊字符串“\*”和“#”，用于做模糊匹配，其中“\*”用于匹配一个单词，“#”用于匹配多个单词(可以是零个)。 -![topic 类型交换器](http://my-blog-to-use.oss-cn-beijing.aliyuncs.com/18-12-16/73843.jpg) +![topic 类型交换器](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/18-12-16/73843.jpg) 以上图为例： -- 路由键为 “com.rabbitmq.client” 的消息会同时路由到 Queuel 和 Queue2; +- 路由键为 “com.rabbitmq.client” 的消息会同时路由到 Queue1 和 Queue2; - 路由键为 “com.hidden.client” 的消息只会路由到 Queue2 中； - 路由键为 “com.hidden.demo” 的消息只会路由到 Queue2 中； -- 路由键为 “java.rabbitmq.demo” 的消息只会路由到Queuel中； +- 路由键为 “java.rabbitmq.demo” 的消息只会路由到 Queue1 中； - 路由键为 “java.util.concurrent” 的消息将会被丢弃或者返回给生产者（需要设置 mandatory 参数），因为它没有匹配任何路由键。 ##### ④ headers(不推荐) -headers 类型的交换器不依赖于路由键的匹配规则来路由消息，而是根据发送的消息内容中的 headers 属性进行匹配。在绑定队列和交换器时制定一组键值对，当发送消息到交换器时，RabbitMQ会获取到该消息的 headers（也是一个键值对的形式)'对比其中的键值对是否完全匹配队列和交换器绑定时指定的键值对，如果完全匹配则消息会路由到该队列，否则不会路由到该队列。headers 类型的交换器性能会很差，而且也不实用，基本上不会看到它的存在。 +headers 类型的交换器不依赖于路由键的匹配规则来路由消息，而是根据发送的消息内容中的 headers 属性进行匹配。在绑定队列和交换器时指定一组键值对，当发送消息到交换器时，RabbitMQ会获取到该消息的 headers（也是一个键值对的形式)，对比其中的键值对是否完全匹配队列和交换器绑定时指定的键值对，如果完全匹配则消息会路由到该队列，否则不会路由到该队列。headers 类型的交换器性能会很差，而且也不实用，基本上不会看到它的存在。 -## 二 安装 RabbitMq +## 二 安装 RabbitMQ 通过 Docker 安装非常方便，只需要几条命令就好了，我这里是只说一下常规安装方法。 前面提到了 RabbitMQ 是由 Erlang语言编写的，也正因如此，在安装RabbitMQ 之前需要安装 Erlang。 +注意：在安装 RabbitMQ 的时候需要注意 RabbitMQ 和 Erlang 的版本关系，如果不注意的话会导致出错，两者对应关系如下: + +![RabbitMQ 和 Erlang 的版本关系](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/2019-3/RabbitMQ-Erlang.png) + ### 2.1 安装 erlang **1 下载 erlang 安装包** @@ -152,10 +136,10 @@ headers 类型的交换器不依赖于路由键的匹配规则来路由消息， 在官网下载然后上传到 Linux 上或者直接使用下面的命令下载对应的版本。 ```shell -[root@SnailClimb local]#wget http://erlang.org/download/otp_src_19.3.tar.gz +[root@SnailClimb local]#wget https://erlang.org/download/otp_src_19.3.tar.gz ``` -erlang 官网下载：[http://www.erlang.org/downloads](http://www.erlang.org/downloads) +erlang 官网下载：[https://www.erlang.org/downloads](https://www.erlang.org/downloads) **2 解压 erlang 安装包** @@ -173,7 +157,7 @@ erlang 官网下载：[http://www.erlang.org/downloads](http://www.erlang.org/do ```shell [root@SnailClimb local]#yum -y install make gcc gcc-c++ kernel-devel m4 ncurses-devel openssl-devel unixODBC-devel -``` +``` **5 进入erlang 安装包解压文件对 erlang 进行安装环境的配置** @@ -207,7 +191,7 @@ make && make install ```erlang io:format("hello world~n", []). ``` -![输出“hello world”](http://my-blog-to-use.oss-cn-beijing.aliyuncs.com/18-12-12/49570541.jpg) +![输出“hello world”](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/18-12-12/49570541.jpg) 大功告成，我们的 erlang 已经安装完成。 @@ -238,7 +222,7 @@ export ERL_HOME PATH [root@SnailClimb etc]# erl ``` -![输入 erl 查看 erlang 环境变量是否配置正确](http://my-blog-to-use.oss-cn-beijing.aliyuncs.com/18-12-12/62504246.jpg) +![输入 erl 查看 erlang 环境变量是否配置正确](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/18-12-12/62504246.jpg) ### 2.2 安装 RabbitMQ @@ -249,7 +233,7 @@ wget https://www.rabbitmq.com/releases/rabbitmq-server/v3.6.8/rabbitmq-server-3. ``` 或者直接在官网下载 -https://www.rabbitmq.com/install-rpm.html[enter link description here](https://www.rabbitmq.com/install-rpm.html) +[https://www.rabbitmq.com/install-rpm.html](https://www.rabbitmq.com/install-rpm.html) **2. 安装rpm** @@ -275,23 +259,23 @@ rabbitmq-plugins enable rabbitmq_management chkconfig rabbitmq-server on ``` -**4. 启动服务** +**5. 启动服务** ```shell service rabbitmq-server start ``` -**5. 查看服务状态** +**6. 查看服务状态** ```shell service rabbitmq-server status ``` -**6. 访问 RabbitMQ 控制台** +**7. 访问 RabbitMQ 控制台** 浏览器访问：http://你的ip地址:15672/ -默认用户名和密码： guest/guest;但是需要注意的是：guestuest用户只是被容许从localhost访问。官网文档描述如下： +默认用户名和密码：guest/guest; 但是需要注意的是：guest用户只是被容许从localhost访问。官网文档描述如下： ```shell “guest” user can only connect via localhost @@ -315,6 +299,6 @@ Setting permissions for user "root" in vhost "/" ... 再次访问:http://你的ip地址:15672/ ,输入用户名和密码：root root -![RabbitMQ控制台](http://my-blog-to-use.oss-cn-beijing.aliyuncs.com/18-12-12/45835332.jpg) +![RabbitMQ控制台](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/18-12-12/45835332.jpg) diff --git a/docs/high-performance/message-queue/rocketmq-intro.md b/docs/high-performance/message-queue/rocketmq-intro.md new file mode 100644 index 0000000000000000000000000000000000000000..d4eafba441c8215a405fb62f1755f055d7c2d89b --- /dev/null +++ b/docs/high-performance/message-queue/rocketmq-intro.md @@ -0,0 +1,456 @@ +# RocketMQ入门总结 + +> 文章很长，点赞再看，养成好习惯😋😋😋 +> +> [本文由 FrancisQ 老哥投稿！](https://mp.weixin.qq.com/s?__biz=Mzg2OTA0Njk0OA==&mid=2247485969&idx=1&sn=6bd53abde30d42a778d5a35ec104428c&chksm=cea245daf9d5cccce631f93115f0c2c4a7634e55f5bef9009fd03f5a0ffa55b745b5ef4f0530&token=294077121&lang=zh_CN#rd) + +## 消息队列扫盲 + +消息队列顾名思义就是存放消息的队列，队列我就不解释了，别告诉我你连队列都不知道是啥吧？ + +所以问题并不是消息队列是什么，而是 **消息队列为什么会出现？消息队列能用来干什么？用它来干这些事会带来什么好处？消息队列会带来副作用吗？** + +### 消息队列为什么会出现？ + +消息队列算是作为后端程序员的一个必备技能吧，因为**分布式应用必定涉及到各个系统之间的通信问题**，这个时候消息队列也应运而生了。可以说分布式的产生是消息队列的基础，而分布式怕是一个很古老的概念了吧，所以消息队列也是一个很古老的中间件了。 + +### 消息队列能用来干什么？ + +#### 异步 + +你可能会反驳我，应用之间的通信又不是只能由消息队列解决，好好的通信为什么中间非要插一个消息队列呢？我不能直接进行通信吗？ + +很好👍，你又提出了一个概念，**同步通信**。就比如现在业界使用比较多的 `Dubbo` 就是一个适用于各个系统之间同步通信的 `RPC` 框架。 + +我来举个🌰吧，比如我们有一个购票系统，需求是用户在购买完之后能接收到购买完成的短信。 + +![](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/2019-11/16ef37fee7e09230.jpg) + +我们省略中间的网络通信时间消耗，假如购票系统处理需要 150ms ，短信系统处理需要 200ms ，那么整个处理流程的时间消耗就是 150ms + 200ms = 350ms。 + +当然，乍看没什么问题。可是仔细一想你就感觉有点问题，我用户购票在购票系统的时候其实就已经完成了购买，而我现在通过同步调用非要让整个请求拉长时间，而短信系统这玩意又不是很有必要，它仅仅是一个辅助功能增强用户体验感而已。我现在整个调用流程就有点 **头重脚轻** 的感觉了，购票是一个不太耗时的流程，而我现在因为同步调用，非要等待发送短信这个比较耗时的操作才返回结果。那我如果再加一个发送邮件呢？ + +![](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/2019-11/16ef380429cf373e.jpg) + +这样整个系统的调用链又变长了，整个时间就变成了550ms。 + +当我们在学生时代需要在食堂排队的时候，我们和食堂大妈就是一个同步的模型。 + +我们需要告诉食堂大妈：“姐姐，给我加个鸡腿，再加个酸辣土豆丝，帮我浇点汁上去，多打点饭哦😋😋😋” 咦~~~ 为了多吃点，真恶心。 + +然后大妈帮我们打饭配菜，我们看着大妈那颤抖的手和掉落的土豆丝不禁咽了咽口水。 + +最终我们从大妈手中接过饭菜然后去寻找座位了... + +回想一下，我们在给大妈发送需要的信息之后我们是 **同步等待大妈给我配好饭菜** 的，上面我们只是加了鸡腿和土豆丝，万一我再加一个番茄牛腩，韭菜鸡蛋，这样是不是大妈打饭配菜的流程就会变长，我们等待的时间也会相应的变长。 + +![](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/2019-11/006APoFYly1fvd9cwjlfrj30as0b03ym.jpg) + +那后来，我们工作赚钱了有钱去饭店吃饭了，我们告诉服务员来一碗牛肉面加个荷包蛋 **(传达一个消息)** ，然后我们就可以在饭桌上安心的玩手机了 **(干自己其他事情)** ，等到我们的牛肉面上了我们就可以吃了。这其中我们也就传达了一个消息，然后我们又转过头干其他事情了。这其中虽然做面的时间没有变短，但是我们只需要传达一个消息就可以干其他事情了，这是一个 **异步** 的概念。 + +所以，为了解决这一个问题，聪明的程序员在中间也加了个类似于服务员的中间件——消息队列。这个时候我们就可以把模型给改造了。 + +![](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/2019-11/16ef38124f55eaea.jpg) + +这样，我们在将消息存入消息队列之后我们就可以直接返回了(我们告诉服务员我们要吃什么然后玩手机)，所以整个耗时只是 150ms + 10ms = 160ms。 + +> 但是你需要注意的是，整个流程的时长是没变的，就像你仅仅告诉服务员要吃什么是不会影响到做面的速度的。 + +#### 解耦 + +回到最初同步调用的过程，我们写个伪代码简单概括一下。 + +![](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/2019-11/16ef381a505d3e1f.jpg) + +那么第二步，我们又添加了一个发送邮件，我们就得重新去修改代码，如果我们又加一个需求：用户购买完还需要给他加积分，这个时候我们是不是又得改代码？ + +![](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/2019-11/16ef381c4e1b1ac7.jpg) + +如果你觉得还行，那么我这个时候不要发邮件这个服务了呢，我是不是又得改代码，又得重启应用？ + +![](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/2019-11/16ef381f273a66bd.jpg) + +这样改来改去是不是很麻烦，那么 **此时我们就用一个消息队列在中间进行解耦** 。你需要注意的是，我们后面的发送短信、发送邮件、添加积分等一些操作都依赖于上面的 `result` ，这东西抽象出来就是购票的处理结果呀，比如订单号，用户账号等等，也就是说我们后面的一系列服务都是需要同样的消息来进行处理。既然这样，我们是不是可以通过 **“广播消息”** 来实现。 + +我上面所讲的“广播”并不是真正的广播，而是接下来的系统作为消费者去 **订阅** 特定的主题。比如我们这里的主题就可以叫做 `订票` ，我们购买系统作为一个生产者去生产这条消息放入消息队列，然后消费者订阅了这个主题，会从消息队列中拉取消息并消费。就比如我们刚刚画的那张图，你会发现，在生产者这边我们只需要关注 **生产消息到指定主题中** ，而 **消费者只需要关注从指定主题中拉取消息** 就行了。 + +![](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/2019-11/16ef382674b66892.jpg) + +> 如果没有消息队列，每当一个新的业务接入，我们都要在主系统调用新接口、或者当我们取消某些业务，我们也得在主系统删除某些接口调用。有了消息队列，我们只需要关心消息是否送达了队列，至于谁希望订阅，接下来收到消息如何处理，是下游的事情，无疑极大地减少了开发和联调的工作量。 + +#### 削峰 + +我们再次回到一开始我们使用同步调用系统的情况，并且思考一下，如果此时有大量用户请求购票整个系统会变成什么样？ + +![](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/2019-11/16ef382a9756bb1c.jpg) + +如果，此时有一万的请求进入购票系统，我们知道运行我们主业务的服务器配置一般会比较好，所以这里我们假设购票系统能承受这一万的用户请求，那么也就意味着我们同时也会出现一万调用发短信服务的请求。而对于短信系统来说并不是我们的主要业务，所以我们配备的硬件资源并不会太高，那么你觉得现在这个短信系统能承受这一万的峰值么，且不说能不能承受，系统会不会 **直接崩溃** 了？ + +短信业务又不是我们的主业务，我们能不能 **折中处理** 呢？如果我们把购买完成的信息发送到消息队列中，而短信系统 **尽自己所能地去消息队列中取消息和消费消息** ，即使处理速度慢一点也无所谓，只要我们的系统没有崩溃就行了。 + +留得江山在，还怕没柴烧？你敢说每次发送验证码的时候是一发你就收到了的么？ + +#### 消息队列能带来什么好处？ + +其实上面我已经说了。**异步、解耦、削峰。** 哪怕你上面的都没看懂也千万要记住这六个字，因为他不仅是消息队列的精华，更是编程和架构的精华。 + +#### 消息队列会带来副作用吗？ + +没有哪一门技术是“银弹”，消息队列也有它的副作用。 + +比如，本来好好的两个系统之间的调用，我中间加了个消息队列，如果消息队列挂了怎么办呢？是不是 **降低了系统的可用性** ？ + +那这样是不是要保证HA(高可用)？是不是要搞集群？那么我 **整个系统的复杂度是不是上升了** ？ + +抛开上面的问题不讲，万一我发送方发送失败了，然后执行重试，这样就可能产生重复的消息。 + +或者我消费端处理失败了，请求重发，这样也会产生重复的消息。 + +对于一些微服务来说，消费重复消息会带来更大的麻烦，比如增加积分，这个时候我加了多次是不是对其他用户不公平？ + +那么，又 **如何解决重复消费消息的问题** 呢？ + +如果我们此时的消息需要保证严格的顺序性怎么办呢？比如生产者生产了一系列的有序消息(对一个id为1的记录进行删除增加修改)，但是我们知道在发布订阅模型中，对于主题是无顺序的，那么这个时候就会导致对于消费者消费消息的时候没有按照生产者的发送顺序消费，比如这个时候我们消费的顺序为修改删除增加，如果该记录涉及到金额的话是不是会出大事情？ + +那么，又 **如何解决消息的顺序消费问题** 呢？ + +就拿我们上面所讲的分布式系统来说，用户购票完成之后是不是需要增加账户积分？在同一个系统中我们一般会使用事务来进行解决，如果用 `Spring` 的话我们在上面伪代码中加入 `@Transactional` 注解就好了。但是在不同系统中如何保证事务呢？总不能这个系统我扣钱成功了你那积分系统积分没加吧？或者说我这扣钱明明失败了，你那积分系统给我加了积分。 + +那么，又如何 **解决分布式事务问题** 呢？ + +我们刚刚说了，消息队列可以进行削峰操作，那如果我的消费者如果消费很慢或者生产者生产消息很快，这样是不是会将消息堆积在消息队列中？ + +那么，又如何 **解决消息堆积的问题** 呢？ + +可用性降低，复杂度上升，又带来一系列的重复消费，顺序消费，分布式事务，消息堆积的问题，这消息队列还怎么用啊😵？ + +![](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/2019-11/16ef382d709abc9d.png) + +别急，办法总是有的。 + +## RocketMQ是什么？ + +![](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/2019-11/16ef383014430799.jpg) + +哇，你个混蛋！上面给我抛出那么多问题，你现在又讲 `RocketMQ` ，还让不让人活了？！🤬 + +别急别急，话说你现在清楚 `MQ` 的构造吗，我还没讲呢，我们先搞明白 `MQ` 的内部构造，再来看看如何解决上面的一系列问题吧，不过你最好带着问题去阅读和了解喔。 + +`RocketMQ` 是一个 **队列模型** 的消息中间件，具有**高性能、高可靠、高实时、分布式** 的特点。它是一个采用 `Java` 语言开发的分布式的消息系统，由阿里巴巴团队开发，在2016年底贡献给 `Apache`，成为了 `Apache` 的一个顶级项目。 在阿里内部，`RocketMQ` 很好地服务了集团大大小小上千个应用，在每年的双十一当天，更有不可思议的万亿级消息通过 `RocketMQ` 流转。 + +废话不多说，想要了解 `RocketMQ` 历史的同学可以自己去搜寻资料。听完上面的介绍，你只要知道 `RocketMQ` 很快、很牛、而且经历过双十一的实践就行了！ + +## 队列模型和主题模型 + +在谈 `RocketMQ` 的技术架构之前，我们先来了解一下两个名词概念——**队列模型** 和 **主题模型** 。 + +首先我问一个问题，消息队列为什么要叫消息队列？ + +你可能觉得很弱智，这玩意不就是存放消息的队列嘛？不叫消息队列叫什么？ + +的确，早期的消息中间件是通过 **队列** 这一模型来实现的，可能是历史原因，我们都习惯把消息中间件成为消息队列。 + +但是，如今例如 `RocketMQ` 、`Kafka` 这些优秀的消息中间件不仅仅是通过一个 **队列** 来实现消息存储的。 + +### 队列模型 + +就像我们理解队列一样，消息中间件的队列模型就真的只是一个队列。。。我画一张图给大家理解。 + +![](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/2019-11/16ef3834ae653469.jpg) + +在一开始我跟你提到了一个 **“广播”** 的概念，也就是说如果我们此时我们需要将一个消息发送给多个消费者(比如此时我需要将信息发送给短信系统和邮件系统)，这个时候单个队列即不能满足需求了。 + +当然你可以让 `Producer` 生产消息放入多个队列中，然后每个队列去对应每一个消费者。问题是可以解决，创建多个队列并且复制多份消息是会很影响资源和性能的。而且，这样子就会导致生产者需要知道具体消费者个数然后去复制对应数量的消息队列，这就违背我们消息中间件的 **解耦** 这一原则。 + +### 主题模型 + +那么有没有好的方法去解决这一个问题呢？有，那就是 **主题模型** 或者可以称为 **发布订阅模型** 。 + +> 感兴趣的同学可以去了解一下设计模式里面的观察者模式并且手动实现一下，我相信你会有所收获的。 + +在主题模型中，消息的生产者称为 **发布者(Publisher)** ，消息的消费者称为 **订阅者(Subscriber)** ，存放消息的容器称为 **主题(Topic)** 。 + +其中，发布者将消息发送到指定主题中，订阅者需要 **提前订阅主题** 才能接受特定主题的消息。 + +![](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/2019-11/16ef3837887d9a54sds.jpg) + +### RocketMQ中的消息模型 + +`RocketMQ` 中的消息模型就是按照 **主题模型** 所实现的。你可能会好奇这个 **主题** 到底是怎么实现的呢？你上面也没有讲到呀！ + +其实对于主题模型的实现来说每个消息中间件的底层设计都是不一样的，就比如 `Kafka` 中的 **分区** ，`RocketMQ` 中的 **队列** ，`RabbitMQ` 中的 `Exchange` 。我们可以理解为 **主题模型/发布订阅模型** 就是一个标准，那些中间件只不过照着这个标准去实现而已。 + +所以，`RocketMQ` 中的 **主题模型** 到底是如何实现的呢？首先我画一张图，大家尝试着去理解一下。 + +![](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/2019-11/16ef383d3e8c9788.jpg) + +我们可以看到在整个图中有 `Producer Group` 、`Topic` 、`Consumer Group` 三个角色，我来分别介绍一下他们。 + +- `Producer Group` 生产者组： 代表某一类的生产者，比如我们有多个秒杀系统作为生产者，这多个合在一起就是一个 `Producer Group` 生产者组，它们一般生产相同的消息。 +- `Consumer Group` 消费者组： 代表某一类的消费者，比如我们有多个短信系统作为消费者，这多个合在一起就是一个 `Consumer Group` 消费者组，它们一般消费相同的消息。 +- `Topic` 主题： 代表一类消息，比如订单消息，物流消息等等。 + +你可以看到图中生产者组中的生产者会向主题发送消息，而 **主题中存在多个队列**，生产者每次生产消息之后是指定主题中的某个队列发送消息的。 + +每个主题中都有多个队列(分布在不同的 `Broker`中，如果是集群的话，`Broker`又分布在不同的服务器中)，集群消费模式下，一个消费者集群多台机器共同消费一个 `topic` 的多个队列，**一个队列只会被一个消费者消费**。如果某个消费者挂掉，分组内其它消费者会接替挂掉的消费者继续消费。就像上图中 `Consumer1` 和 `Consumer2` 分别对应着两个队列，而 `Consumer3` 是没有队列对应的，所以一般来讲要控制 **消费者组中的消费者个数和主题中队列个数相同** 。 + +当然也可以消费者个数小于队列个数，只不过不太建议。如下图。 + +![](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/2019-11/16ef3850c808d707.jpg) + +**每个消费组在每个队列上维护一个消费位置** ，为什么呢？ + +因为我们刚刚画的仅仅是一个消费者组，我们知道在发布订阅模式中一般会涉及到多个消费者组，而每个消费者组在每个队列中的消费位置都是不同的。如果此时有多个消费者组，那么消息被一个消费者组消费完之后是不会删除的(因为其它消费者组也需要呀)，它仅仅是为每个消费者组维护一个 **消费位移(offset)** ，每次消费者组消费完会返回一个成功的响应，然后队列再把维护的消费位移加一，这样就不会出现刚刚消费过的消息再一次被消费了。 + +![](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/2019-11/16ef3857fefaa079.jpg) + +可能你还有一个问题，**为什么一个主题中需要维护多个队列** ？ + +答案是 **提高并发能力** 。的确，每个主题中只存在一个队列也是可行的。你想一下，如果每个主题中只存在一个队列，这个队列中也维护着每个消费者组的消费位置，这样也可以做到 **发布订阅模式** 。如下图。 + +![](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/2019-11/16ef38600cdb6d4b.jpg) + +但是，这样我生产者是不是只能向一个队列发送消息？又因为需要维护消费位置所以一个队列只能对应一个消费者组中的消费者，这样是不是其他的 `Consumer` 就没有用武之地了？从这两个角度来讲，并发度一下子就小了很多。 + +所以总结来说，`RocketMQ` 通过**使用在一个 `Topic` 中配置多个队列并且每个队列维护每个消费者组的消费位置** 实现了 **主题模式/发布订阅模式** 。 + +## RocketMQ的架构图 + +讲完了消息模型，我们理解起 `RocketMQ` 的技术架构起来就容易多了。 + +`RocketMQ` 技术架构中有四大角色 `NameServer` 、`Broker` 、`Producer` 、`Consumer` 。我来向大家分别解释一下这四个角色是干啥的。 + +- `Broker`： 主要负责消息的存储、投递和查询以及服务高可用保证。说白了就是消息队列服务器嘛，生产者生产消息到 `Broker` ，消费者从 `Broker` 拉取消息并消费。 + + 这里，我还得普及一下关于 `Broker` 、`Topic` 和 队列的关系。上面我讲解了 `Topic` 和队列的关系——一个 `Topic` 中存在多个队列，那么这个 `Topic` 和队列存放在哪呢？ + + **一个 `Topic` 分布在多个 `Broker`上，一个 `Broker` 可以配置多个 `Topic` ，它们是多对多的关系**。 + + 如果某个 `Topic` 消息量很大，应该给它多配置几个队列(上文中提到了提高并发能力)，并且 **尽量多分布在不同 `Broker` 上，以减轻某个 `Broker` 的压力** 。 + + `Topic` 消息量都比较均匀的情况下，如果某个 `broker` 上的队列越多，则该 `broker` 压力越大。 + + ![](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/2019-11/16ef38687488a5a4.jpg) + + > 所以说我们需要配置多个Broker。 + +- `NameServer`： 不知道你们有没有接触过 `ZooKeeper` 和 `Spring Cloud` 中的 `Eureka` ，它其实也是一个 **注册中心** ，主要提供两个功能：**Broker管理** 和 **路由信息管理** 。说白了就是 `Broker` 会将自己的信息注册到 `NameServer` 中，此时 `NameServer` 就存放了很多 `Broker` 的信息(Broker的路由表)，消费者和生产者就从 `NameServer` 中获取路由表然后照着路由表的信息和对应的 `Broker` 进行通信(生产者和消费者定期会向 `NameServer` 去查询相关的 `Broker` 的信息)。 + +- `Producer`： 消息发布的角色，支持分布式集群方式部署。说白了就是生产者。 + +- `Consumer`： 消息消费的角色，支持分布式集群方式部署。支持以push推，pull拉两种模式对消息进行消费。同时也支持集群方式和广播方式的消费，它提供实时消息订阅机制。说白了就是消费者。 + +听完了上面的解释你可能会觉得，这玩意好简单。不就是这样的么？ + +![](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/2019-11/16ef386c6d1e8bdb.jpg) + +嗯？你可能会发现一个问题，这老家伙 `NameServer` 干啥用的，这不多余吗？直接 `Producer` 、`Consumer` 和 `Broker` 直接进行生产消息，消费消息不就好了么？ + +但是，我们上文提到过 `Broker` 是需要保证高可用的，如果整个系统仅仅靠着一个 `Broker` 来维持的话，那么这个 `Broker` 的压力会不会很大？所以我们需要使用多个 `Broker` 来保证 **负载均衡** 。 + +如果说，我们的消费者和生产者直接和多个 `Broker` 相连，那么当 `Broker` 修改的时候必定会牵连着每个生产者和消费者，这样就会产生耦合问题，而 `NameServer` 注册中心就是用来解决这个问题的。 + +> 如果还不是很理解的话，可以去看我介绍 `Spring Cloud` 的那篇文章，其中介绍了 `Eureka` 注册中心。 + +当然，`RocketMQ` 中的技术架构肯定不止前面那么简单，因为上面图中的四个角色都是需要做集群的。我给出一张官网的架构图，大家尝试理解一下。 + +![](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/2019-11/16ef386fa3be1e53.jpg) + +其实和我们最开始画的那张乞丐版的架构图也没什么区别，主要是一些细节上的差别。听我细细道来🤨。 + +第一、我们的 `Broker` **做了集群并且还进行了主从部署** ，由于消息分布在各个 `Broker` 上，一旦某个 `Broker` 宕机，则该`Broker` 上的消息读写都会受到影响。所以 `Rocketmq` 提供了 `master/slave` 的结构，` salve` 定时从 `master` 同步数据(同步刷盘或者异步刷盘)，如果 `master` 宕机，**则 `slave` 提供消费服务，但是不能写入消息** (后面我还会提到哦)。 + +第二、为了保证 `HA` ，我们的 `NameServer` 也做了集群部署，但是请注意它是 **去中心化** 的。也就意味着它没有主节点，你可以很明显地看出 `NameServer` 的所有节点是没有进行 `Info Replicate` 的，在 `RocketMQ` 中是通过 **单个Broker和所有NameServer保持长连接** ，并且在每隔30秒 `Broker` 会向所有 `Nameserver` 发送心跳，心跳包含了自身的 `Topic` 配置信息，这个步骤就对应这上面的 `Routing Info` 。 + +第三、在生产者需要向 `Broker` 发送消息的时候，**需要先从 `NameServer` 获取关于 `Broker` 的路由信息**，然后通过 **轮询** 的方法去向每个队列中生产数据以达到 **负载均衡** 的效果。 + +第四、消费者通过 `NameServer` 获取所有 `Broker` 的路由信息后，向 `Broker` 发送 `Pull` 请求来获取消息数据。`Consumer` 可以以两种模式启动—— **广播（Broadcast）和集群（Cluster）**。广播模式下，一条消息会发送给 **同一个消费组中的所有消费者** ，集群模式下消息只会发送给一个消费者。 + +## 如何解决 顺序消费、重复消费 + +其实，这些东西都是我在介绍消息队列带来的一些副作用的时候提到的，也就是说，这些问题不仅仅挂钩于 `RocketMQ` ，而是应该每个消息中间件都需要去解决的。 + +在上面我介绍 `RocketMQ` 的技术架构的时候我已经向你展示了 **它是如何保证高可用的** ，这里不涉及运维方面的搭建，如果你感兴趣可以自己去官网上照着例子搭建属于你自己的 `RocketMQ` 集群。 + +> 其实 `Kafka` 的架构基本和 `RocketMQ` 类似，只是它注册中心使用了 `Zookeeper` 、它的 **分区** 就相当于 `RocketMQ` 中的 **队列** 。还有一些小细节不同会在后面提到。 + +### 顺序消费 + +在上面的技术架构介绍中，我们已经知道了 **`RocketMQ` 在主题上是无序的、它只有在队列层面才是保证有序** 的。 + +这又扯到两个概念——**普通顺序** 和 **严格顺序** 。 + +所谓普通顺序是指 消费者通过 **同一个消费队列收到的消息是有顺序的** ，不同消息队列收到的消息则可能是无顺序的。普通顺序消息在 `Broker` **重启情况下不会保证消息顺序性** (短暂时间) 。 + +所谓严格顺序是指 消费者收到的 **所有消息** 均是有顺序的。严格顺序消息 **即使在异常情况下也会保证消息的顺序性** 。 + +但是，严格顺序看起来虽好，实现它可会付出巨大的代价。如果你使用严格顺序模式，`Broker` 集群中只要有一台机器不可用，则整个集群都不可用。你还用啥？现在主要场景也就在 `binlog` 同步。 + +一般而言，我们的 `MQ` 都是能容忍短暂的乱序，所以推荐使用普通顺序模式。 + +那么，我们现在使用了 **普通顺序模式** ，我们从上面学习知道了在 `Producer` 生产消息的时候会进行轮询(取决你的负载均衡策略)来向同一主题的不同消息队列发送消息。那么如果此时我有几个消息分别是同一个订单的创建、支付、发货，在轮询的策略下这 **三个消息会被发送到不同队列** ，因为在不同的队列此时就无法使用 `RocketMQ` 带来的队列有序特性来保证消息有序性了。 + +![](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/2019-11/16ef3874585e096e.jpg) + +那么，怎么解决呢？ + +其实很简单，我们需要处理的仅仅是将同一语义下的消息放入同一个队列(比如这里是同一个订单)，那我们就可以使用 **Hash取模法** 来保证同一个订单在同一个队列中就行了。 + +### 重复消费 + +emmm，就两个字—— **幂等** 。在编程中一个*幂等* 操作的特点是其任意多次执行所产生的影响均与一次执行的影响相同。比如说，这个时候我们有一个订单的处理积分的系统，每当来一个消息的时候它就负责为创建这个订单的用户的积分加上相应的数值。可是有一次，消息队列发送给订单系统 FrancisQ 的订单信息，其要求是给 FrancisQ 的积分加上 500。但是积分系统在收到 FrancisQ 的订单信息处理完成之后返回给消息队列处理成功的信息的时候出现了网络波动(当然还有很多种情况，比如Broker意外重启等等)，这条回应没有发送成功。 + +那么，消息队列没收到积分系统的回应会不会尝试重发这个消息？问题就来了，我再发这个消息，万一它又给 FrancisQ 的账户加上 500 积分怎么办呢？ + +所以我们需要给我们的消费者实现 **幂等** ，也就是对同一个消息的处理结果，执行多少次都不变。 + +那么如何给业务实现幂等呢？这个还是需要结合具体的业务的。你可以使用 **写入 `Redis`** 来保证，因为 `Redis` 的 `key` 和 `value` 就是天然支持幂等的。当然还有使用 **数据库插入法** ，基于数据库的唯一键来保证重复数据不会被插入多条。 + +不过最主要的还是需要 **根据特定场景使用特定的解决方案** ，你要知道你的消息消费是否是完全不可重复消费还是可以忍受重复消费的，然后再选择强校验和弱校验的方式。毕竟在 CS 领域还是很少有技术银弹的说法。 + +而在整个互联网领域，幂等不仅仅适用于消息队列的重复消费问题，这些实现幂等的方法，也同样适用于，**在其他场景中来解决重复请求或者重复调用的问题** 。比如将HTTP服务设计成幂等的，**解决前端或者APP重复提交表单数据的问题** ，也可以将一个微服务设计成幂等的，解决 `RPC` 框架自动重试导致的 **重复调用问题** 。 + +## 分布式事务 + +如何解释分布式事务呢？事务大家都知道吧？**要么都执行要么都不执行** 。在同一个系统中我们可以轻松地实现事务，但是在分布式架构中，我们有很多服务是部署在不同系统之间的，而不同服务之间又需要进行调用。比如此时我下订单然后增加积分，如果保证不了分布式事务的话，就会出现A系统下了订单，但是B系统增加积分失败或者A系统没有下订单，B系统却增加了积分。前者对用户不友好，后者对运营商不利，这是我们都不愿意见到的。 + +那么，如何去解决这个问题呢？ + +如今比较常见的分布式事务实现有 2PC、TCC 和事务消息(half 半消息机制)。每一种实现都有其特定的使用场景，但是也有各自的问题，**都不是完美的解决方案**。 + +在 `RocketMQ` 中使用的是 **事务消息加上事务反查机制** 来解决分布式事务问题的。我画了张图，大家可以对照着图进行理解。 + +![](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/2019-11/16ef38798d7a987f.png) + +在第一步发送的 half 消息 ，它的意思是 **在事务提交之前，对于消费者来说，这个消息是不可见的** 。 + +> 那么，如何做到写入消息但是对用户不可见呢？RocketMQ事务消息的做法是：如果消息是half消息，将备份原消息的主题与消息消费队列，然后 **改变主题** 为RMQ_SYS_TRANS_HALF_TOPIC。由于消费组未订阅该主题，故消费端无法消费half类型的消息，**然后RocketMQ会开启一个定时任务，从Topic为RMQ_SYS_TRANS_HALF_TOPIC中拉取消息进行消费**，根据生产者组获取一个服务提供者发送回查事务状态请求，根据事务状态来决定是提交或回滚消息。 + +你可以试想一下，如果没有从第5步开始的 **事务反查机制** ，如果出现网路波动第4步没有发送成功，这样就会产生 MQ 不知道是不是需要给消费者消费的问题，他就像一个无头苍蝇一样。在 `RocketMQ` 中就是使用的上述的事务反查来解决的，而在 `Kafka` 中通常是直接抛出一个异常让用户来自行解决。 + +你还需要注意的是，在 `MQ Server` 指向系统B的操作已经和系统A不相关了，也就是说在消息队列中的分布式事务是——**本地事务和存储消息到消息队列才是同一个事务**。这样也就产生了事务的**最终一致性**，因为整个过程是异步的，**每个系统只要保证它自己那一部分的事务就行了**。 + +## 消息堆积问题 + +在上面我们提到了消息队列一个很重要的功能——**削峰** 。那么如果这个峰值太大了导致消息堆积在队列中怎么办呢？ + +其实这个问题可以将它广义化，因为产生消息堆积的根源其实就只有两个——生产者生产太快或者消费者消费太慢。 + +我们可以从多个角度去思考解决这个问题，当流量到峰值的时候是因为生产者生产太快，我们可以使用一些 **限流降级** 的方法，当然你也可以增加多个消费者实例去水平扩展增加消费能力来匹配生产的激增。如果消费者消费过慢的话，我们可以先检查 **是否是消费者出现了大量的消费错误** ，或者打印一下日志查看是否是哪一个线程卡死，出现了锁资源不释放等等的问题。 + +> 当然，最快速解决消息堆积问题的方法还是增加消费者实例，不过 **同时你还需要增加每个主题的队列数量** 。 +> +> 别忘了在 `RocketMQ` 中，**一个队列只会被一个消费者消费** ，如果你仅仅是增加消费者实例就会出现我一开始给你画架构图的那种情况。 + +![](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/2019-11/16ef387d939ab66d.jpg) + +## 回溯消费 + +回溯消费是指 `Consumer` 已经消费成功的消息，由于业务上需求需要重新消费，在`RocketMQ` 中， `Broker` 在向`Consumer` 投递成功消息后，**消息仍然需要保留** 。并且重新消费一般是按照时间维度，例如由于 `Consumer` 系统故障，恢复后需要重新消费1小时前的数据，那么 `Broker` 要提供一种机制，可以按照时间维度来回退消费进度。`RocketMQ` 支持按照时间回溯消费，时间维度精确到毫秒。 + +这是官方文档的解释，我直接照搬过来就当科普了😁😁😁。 + +## RocketMQ 的刷盘机制 + +上面我讲了那么多的 `RocketMQ` 的架构和设计原理，你有没有好奇 + +在 `Topic` 中的 **队列是以什么样的形式存在的？** + +**队列中的消息又是如何进行存储持久化的呢？** + +我在上文中提到的 **同步刷盘** 和 **异步刷盘** 又是什么呢？它们会给持久化带来什么样的影响呢？ + +下面我将给你们一一解释。 + +### 同步刷盘和异步刷盘 + +![](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/2019-11/16ef387fba311cda.jpg) + +如上图所示，在同步刷盘中需要等待一个刷盘成功的 `ACK` ，同步刷盘对 `MQ` 消息可靠性来说是一种不错的保障，但是 **性能上会有较大影响** ，一般地适用于金融等特定业务场景。 + +而异步刷盘往往是开启一个线程去异步地执行刷盘操作。消息刷盘采用后台异步线程提交的方式进行， **降低了读写延迟** ，提高了 `MQ` 的性能和吞吐量，一般适用于如发验证码等对于消息保证要求不太高的业务场景。 + +一般地，**异步刷盘只有在 `Broker` 意外宕机的时候会丢失部分数据**，你可以设置 `Broker` 的参数 `FlushDiskType` 来调整你的刷盘策略(ASYNC_FLUSH 或者 SYNC_FLUSH)。 + +### 同步复制和异步复制 + +上面的同步刷盘和异步刷盘是在单个结点层面的，而同步复制和异步复制主要是指的 `Borker` 主从模式下，主节点返回消息给客户端的时候是否需要同步从节点。 + +- 同步复制： 也叫 “同步双写”，也就是说，**只有消息同步双写到主从节点上时才返回写入成功** 。 +- 异步复制： **消息写入主节点之后就直接返回写入成功** 。 + +然而，很多事情是没有完美的方案的，就比如我们进行消息写入的节点越多就更能保证消息的可靠性，但是随之的性能也会下降，所以需要程序员根据特定业务场景去选择适应的主从复制方案。 + +那么，**异步复制会不会也像异步刷盘那样影响消息的可靠性呢？** + +答案是不会的，因为两者就是不同的概念，对于消息可靠性是通过不同的刷盘策略保证的，而像异步同步复制策略仅仅是影响到了 **可用性** 。为什么呢？其主要原因**是 `RocketMQ` 是不支持自动主从切换的，当主节点挂掉之后，生产者就不能再给这个主节点生产消息了**。 + +比如这个时候采用异步复制的方式，在主节点还未发送完需要同步的消息的时候主节点挂掉了，这个时候从节点就少了一部分消息。但是此时生产者无法再给主节点生产消息了，**消费者可以自动切换到从节点进行消费**(仅仅是消费)，所以在主节点挂掉的时间只会产生主从结点短暂的消息不一致的情况，降低了可用性，而当主节点重启之后，从节点那部分未来得及复制的消息还会继续复制。 + +在单主从架构中，如果一个主节点挂掉了，那么也就意味着整个系统不能再生产了。那么这个可用性的问题能否解决呢？**一个主从不行那就多个主从的呗**，别忘了在我们最初的架构图中，每个 `Topic` 是分布在不同 `Broker` 中的。 + +![](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/2019-11/16ef38687488a5a4.jpg) + +但是这种复制方式同样也会带来一个问题，那就是无法保证 **严格顺序** 。在上文中我们提到了如何保证的消息顺序性是通过将一个语义的消息发送在同一个队列中，使用 `Topic` 下的队列来保证顺序性的。如果此时我们主节点A负责的是订单A的一系列语义消息，然后它挂了，这样其他节点是无法代替主节点A的，如果我们任意节点都可以存入任何消息，那就没有顺序性可言了。 + +而在 `RocketMQ` 中采用了 `Dledger` 解决这个问题。他要求在写入消息的时候，要求**至少消息复制到半数以上的节点之后**，才给客⼾端返回写⼊成功，并且它是⽀持通过选举来动态切换主节点的。这里我就不展开说明了，读者可以自己去了解。 + +> 也不是说 `Dledger` 是个完美的方案，至少在 `Dledger` 选举过程中是无法提供服务的，而且他必须要使用三个节点或以上，如果多数节点同时挂掉他也是无法保证可用性的，而且要求消息复制半数以上节点的效率和直接异步复制还是有一定的差距的。 + +### 存储机制 + +还记得上面我们一开始的三个问题吗？到这里第三个问题已经解决了。 + +但是，在 `Topic` 中的 **队列是以什么样的形式存在的？队列中的消息又是如何进行存储持久化的呢？** 还未解决，其实这里涉及到了 `RocketMQ` 是如何设计它的存储结构了。我首先想大家介绍 `RocketMQ` 消息存储架构中的三大角色——`CommitLog` 、`ConsumeQueue` 和 `IndexFile` 。 + +- `CommitLog`： **消息主体以及元数据的存储主体**，存储 `Producer` 端写入的消息主体内容,消息内容不是定长的。单个文件大小默认1G ，文件名长度为20位，左边补零，剩余为起始偏移量，比如00000000000000000000代表了第一个文件，起始偏移量为0，文件大小为1G=1073741824；当第一个文件写满了，第二个文件为00000000001073741824，起始偏移量为1073741824，以此类推。消息主要是**顺序写入日志文件**，当文件满了，写入下一个文件。 +- `ConsumeQueue`： 消息消费队列，**引入的目的主要是提高消息消费的性能**(我们再前面也讲了)，由于`RocketMQ` 是基于主题 `Topic` 的订阅模式，消息消费是针对主题进行的，如果要遍历 `commitlog` 文件中根据 `Topic` 检索消息是非常低效的。`Consumer` 即可根据 `ConsumeQueue` 来查找待消费的消息。其中，`ConsumeQueue`（逻辑消费队列）**作为消费消息的索引**，保存了指定 `Topic` 下的队列消息在 `CommitLog` 中的**起始物理偏移量 `offset` **，消息大小 `size` 和消息 `Tag` 的 `HashCode` 值。**`consumequeue` 文件可以看成是基于 `topic` 的 `commitlog` 索引文件**，故 `consumequeue` 文件夹的组织方式如下：topic/queue/file三层组织结构，具体存储路径为：$HOME/store/consumequeue/{topic}/{queueId}/{fileName}。同样 `consumequeue` 文件采取定长设计，每一个条目共20个字节，分别为8字节的 `commitlog` 物理偏移量、4字节的消息长度、8字节tag `hashcode`，单个文件由30W个条目组成，可以像数组一样随机访问每一个条目，每个 `ConsumeQueue`文件大小约5.72M； +- `IndexFile`： `IndexFile`（索引文件）提供了一种可以通过key或时间区间来查询消息的方法。这里只做科普不做详细介绍。 + +总结来说，整个消息存储的结构，最主要的就是 `CommitLoq` 和 `ConsumeQueue` 。而 `ConsumeQueue` 你可以大概理解为 `Topic` 中的队列。 + +![](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/2019-11/16ef3884c02acc72.png) + +`RocketMQ` 采用的是 **混合型的存储结构** ，即为 `Broker` 单个实例下所有的队列共用一个日志数据文件来存储消息。有意思的是在同样高并发的 `Kafka` 中会为每个 `Topic` 分配一个存储文件。这就有点类似于我们有一大堆书需要装上书架，`RockeMQ` 是不分书的种类直接成批的塞上去的，而 `Kafka` 是将书本放入指定的分类区域的。 + +而 `RocketMQ` 为什么要这么做呢？原因是 **提高数据的写入效率** ，不分 `Topic` 意味着我们有更大的几率获取 **成批** 的消息进行数据写入，但也会带来一个麻烦就是读取消息的时候需要遍历整个大文件，这是非常耗时的。 + +所以，在 `RocketMQ` 中又使用了 `ConsumeQueue` 作为每个队列的索引文件来 **提升读取消息的效率**。我们可以直接根据队列的消息序号，计算出索引的全局位置（索引序号*索引固定⻓度20），然后直接读取这条索引，再根据索引中记录的消息的全局位置，找到消息。 + +讲到这里，你可能对 `RockeMQ` 的存储架构还有些模糊，没事，我们结合着图来理解一下。 + +![](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/2019-11/16ef388763c25c62.jpg) + +emmm，是不是有一点复杂🤣，看英文图片和英文文档的时候就不要怂，硬着头皮往下看就行。 + +> 如果上面没看懂的读者一定要认真看下面的流程分析！ + +首先，在最上面的那一块就是我刚刚讲的你现在可以直接 **把 `ConsumerQueue` 理解为 `Queue`**。 + +在图中最左边说明了红色方块代表被写入的消息，虚线方块代表等待被写入的。左边的生产者发送消息会指定 `Topic` 、`QueueId` 和具体消息内容，而在 `Broker` 中管你是哪门子消息，他直接 **全部顺序存储到了 CommitLog**。而根据生产者指定的 `Topic` 和 `QueueId` 将这条消息本身在 `CommitLog` 的偏移(offset)，消息本身大小，和tag的hash值存入对应的 `ConsumeQueue` 索引文件中。而在每个队列中都保存了 `ConsumeOffset` 即每个消费者组的消费位置(我在架构那里提到了，忘了的同学可以回去看一下)，而消费者拉取消息进行消费的时候只需要根据 `ConsumeOffset` 获取下一个未被消费的消息就行了。 + +上述就是我对于整个消息存储架构的大概理解(这里不涉及到一些细节讨论，比如稀疏索引等等问题)，希望对你有帮助。 + +因为有一个知识点因为写嗨了忘讲了，想想在哪里加也不好，所以我留给大家去思考🤔🤔一下吧。 + +![](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/2019-11/e314ee45gy1g05zgr67bbj20gp0b3aba.jpg) + +为什么 `CommitLog` 文件要设计成固定大小的长度呢？提醒：**内存映射机制**。 + +## 总结 + +总算把这篇博客写完了。我讲的你们还记得吗😅？ + +这篇文章中我主要想大家介绍了 + +1. 消息队列出现的原因 +2. 消息队列的作用(异步，解耦，削峰) +3. 消息队列带来的一系列问题(消息堆积、重复消费、顺序消费、分布式事务等等) +4. 消息队列的两种消息模型——队列和主题模式 +5. 分析了 `RocketMQ` 的技术架构(`NameServer` 、`Broker` 、`Producer` 、`Comsumer`) +6. 结合 `RocketMQ` 回答了消息队列副作用的解决方案 +7. 介绍了 `RocketMQ` 的存储机制和刷盘策略。 + +等等。。。 + +> 如果喜欢可以点赞哟👍👍👍。 diff --git a/docs/high-performance/message-queue/rocketmq-questions.md b/docs/high-performance/message-queue/rocketmq-questions.md new file mode 100644 index 0000000000000000000000000000000000000000..68957689c11e2cfdce9af1c91ae48c3d98fc53bf --- /dev/null +++ b/docs/high-performance/message-queue/rocketmq-questions.md @@ -0,0 +1,199 @@ +# RocketMQ常见问题 + +本文来自读者 [PR](https://github.com/Snailclimb/JavaGuide/pull/291)。 + +## 1 单机版消息中心 + +一个消息中心，最基本的需要支持多生产者、多消费者，例如下： + +```java +class Scratch { + + public static void main(String[] args) { + // 实际中会有 nameserver 服务来找到 broker 具体位置以及 broker 主从信息 + Broker broker = new Broker(); + Producer producer1 = new Producer(); + producer1.connectBroker(broker); + Producer producer2 = new Producer(); + producer2.connectBroker(broker); + + Consumer consumer1 = new Consumer(); + consumer1.connectBroker(broker); + Consumer consumer2 = new Consumer(); + consumer2.connectBroker(broker); + + for (int i = 0; i < 2; i++) { + producer1.asyncSendMsg("producer1 send msg" + i); + producer2.asyncSendMsg("producer2 send msg" + i); + } + System.out.println("broker has msg:" + broker.getAllMagByDisk()); + + for (int i = 0; i < 1; i++) { + System.out.println("consumer1 consume msg：" + consumer1.syncPullMsg()); + } + for (int i = 0; i < 3; i++) { + System.out.println("consumer2 consume msg：" + consumer2.syncPullMsg()); + } + } + +} + +class Producer { + + private Broker broker; + + public void connectBroker(Broker broker) { + this.broker = broker; + } + + public void asyncSendMsg(String msg) { + if (broker == null) { + throw new RuntimeException("please connect broker first"); + } + new Thread(() -> { + broker.sendMsg(msg); + }).start(); + } +} + +class Consumer { + private Broker broker; + + public void connectBroker(Broker broker) { + this.broker = broker; + } + + public String syncPullMsg() { + return broker.getMsg(); + } + +} + +class Broker { + + // 对应 RocketMQ 中 MessageQueue，默认情况下 1 个 Topic 包含 4 个 MessageQueue + private LinkedBlockingQueue messageQueue = new LinkedBlockingQueue(Integer.MAX_VALUE); + + // 实际发送消息到 broker 服务器使用 Netty 发送 + public void sendMsg(String msg) { + try { + messageQueue.put(msg); + // 实际会同步或异步落盘，异步落盘使用的定时任务定时扫描落盘 + } catch (InterruptedException e) { + + } + } + + public String getMsg() { + try { + return messageQueue.take(); + } catch (InterruptedException e) { + + } + return null; + } + + public String getAllMagByDisk() { + StringBuilder sb = new StringBuilder("\n"); + messageQueue.iterator().forEachRemaining((msg) -> { + sb.append(msg + "\n"); + }); + return sb.toString(); + } +} +``` + +问题： +1. 没有实现真正执行消息存储落盘 +2. 没有实现 NameServer 去作为注册中心，定位服务 +3. 使用 LinkedBlockingQueue 作为消息队列，注意，参数是无限大，在真正 RocketMQ 也是如此是无限大，理论上不会出现对进来的数据进行抛弃，但是会有内存泄漏问题（阿里巴巴开发手册也因为这个问题，建议我们使用自制线程池） +4. 没有使用多个队列（即多个 LinkedBlockingQueue），RocketMQ 的顺序消息是通过生产者和消费者同时使用同一个 MessageQueue 来实现，但是如果我们只有一个 MessageQueue，那我们天然就支持顺序消息 +5. 没有使用 MappedByteBuffer 来实现文件映射从而使消息数据落盘非常的快（实际 RocketMQ 使用的是 FileChannel+DirectBuffer） + +## 2 分布式消息中心 + +### 2.1 问题与解决 + +#### 2.1.1 消息丢失的问题 + +1. 当你系统需要保证百分百消息不丢失，你可以使用生产者每发送一个消息，Broker 同步返回一个消息发送成功的反馈消息 +2. 即每发送一个消息，同步落盘后才返回生产者消息发送成功，这样只要生产者得到了消息发送生成的返回，事后除了硬盘损坏，都可以保证不会消息丢失 +3. 但是这同时引入了一个问题，同步落盘怎么才能快？ + +#### 2.1.2 同步落盘怎么才能快 + +1. 使用 FileChannel + DirectBuffer 池，使用堆外内存，加快内存拷贝 +2. 使用数据和索引分离，当消息需要写入时，使用 commitlog 文件顺序写，当需要定位某个消息时，查询index 文件来定位，从而减少文件IO随机读写的性能损耗 + +#### 2.1.3 消息堆积的问题 + +1. 后台定时任务每隔72小时，删除旧的没有使用过的消息信息 +2. 根据不同的业务实现不同的丢弃任务，具体参考线程池的 AbortPolicy，例如FIFO/LRU等（RocketMQ没有此策略） +3. 消息定时转移，或者对某些重要的 TAG 型（支付型）消息真正落库 + +#### 2.1.4 定时消息的实现 + +1. 实际 RocketMQ 没有实现任意精度的定时消息，它只支持某些特定的时间精度的定时消息 +2. 实现定时消息的原理是：创建特定时间精度的 MessageQueue，例如生产者需要定时1s之后被消费者消费，你只需要将此消息发送到特定的 Topic，例如：MessageQueue-1 表示这个 MessageQueue 里面的消息都会延迟一秒被消费，然后 Broker 会在 1s 后发送到消费者消费此消息，使用 newSingleThreadScheduledExecutor 实现 + +#### 2.1.5 顺序消息的实现 + +1. 与定时消息同原理，生产者生产消息时指定特定的 MessageQueue ，消费者消费消息时，消费特定的 MessageQueue，其实单机版的消息中心在一个 MessageQueue 就天然支持了顺序消息 +2. 注意：同一个 MessageQueue 保证里面的消息是顺序消费的前提是：消费者是串行的消费该 MessageQueue，因为就算 MessageQueue 是顺序的，但是当并行消费时，还是会有顺序问题，但是串行消费也同时引入了两个问题： +>1. 引入锁来实现串行 +>2. 前一个消费阻塞时后面都会被阻塞 + +#### 2.1.6 分布式消息的实现 + +1. 需要前置知识：2PC +2. RocketMQ4.3 起支持，原理为2PC，即两阶段提交，prepared->commit/rollback +3. 生产者发送事务消息，假设该事务消息 Topic 为 Topic1-Trans，Broker 得到后首先更改该消息的 Topic 为 Topic1-Prepared，该 Topic1-Prepared 对消费者不可见。然后定时回调生产者的本地事务A执行状态，根据本地事务A执行状态，来是否将该消息修改为 Topic1-Commit 或 Topic1-Rollback，消费者就可以正常找到该事务消息或者不执行等 + +>注意，就算是事务消息最后回滚了也不会物理删除，只会逻辑删除该消息 + +#### 2.1.7 消息的 push 实现 + +1. 注意，RocketMQ 已经说了自己会有低延迟问题，其中就包括这个消息的 push 延迟问题 +2. 因为这并不是真正的将消息主动的推送到消费者，而是 Broker 定时任务每5s将消息推送到消费者 +3. pull模式需要我们手动调用consumer拉消息，而push模式则只需要我们提供一个listener即可实现对消息的监听，而实际上，RocketMQ的push模式是基于pull模式实现的，它没有实现真正的push。 +4. push方式里，consumer把轮询过程封装了，并注册MessageListener监听器，取到消息后，唤醒MessageListener的consumeMessage()来消费，对用户而言，感觉消息是被推送过来的。 + +#### 2.1.8 消息重复发送的避免 + +1. RocketMQ 会出现消息重复发送的问题，因为在网络延迟的情况下，这种问题不可避免的发生，如果非要实现消息不可重复发送，那基本太难，因为网络环境无法预知，还会使程序复杂度加大，因此默认允许消息重复发送 +2. RocketMQ 让使用者在消费者端去解决该问题，即需要消费者端在消费消息时支持幂等性的去消费消息 +3. 最简单的解决方案是每条消费记录有个消费状态字段，根据这个消费状态字段来判断是否消费或者使用一个集中式的表，来存储所有消息的消费状态，从而避免重复消费 +4. 具体实现可以查询关于消息幂等消费的解决方案 + +#### 2.1.9 广播消费与集群消费 + +1. 消息消费区别：广播消费，订阅该 Topic 的消息者们都会消费**每个**消息。集群消费，订阅该 Topic 的消息者们只会有一个去消费**某个**消息 +2. 消息落盘区别：具体表现在消息消费进度的保存上。广播消费，由于每个消费者都独立的去消费每个消息，因此每个消费者各自保存自己的消息消费进度。而集群消费下，订阅了某个 Topic，而旗下又有多个 MessageQueue，每个消费者都可能会去消费不同的 MessageQueue，因此总体的消费进度保存在 Broker 上集中的管理 + +#### 2.1.10 RocketMQ 不使用 ZooKeeper 作为注册中心的原因，以及自制的 NameServer 优缺点？ + +1. ZooKeeper 作为支持顺序一致性的中间件，在某些情况下，它为了满足一致性，会丢失一定时间内的可用性，RocketMQ 需要注册中心只是为了发现组件地址，在某些情况下，RocketMQ 的注册中心可以出现数据不一致性，这同时也是 NameServer 的缺点，因为 NameServer 集群间互不通信，它们之间的注册信息可能会不一致 +2. 另外，当有新的服务器加入时，NameServer 并不会立马通知到 Producer，而是由 Producer 定时去请求 NameServer 获取最新的 Broker/Consumer 信息（这种情况是通过 Producer 发送消息时，负载均衡解决） + +#### 2.1.11 其它 + +![][1] + +加分项咯 +1. 包括组件通信间使用 Netty 的自定义协议 +2. 消息重试负载均衡策略（具体参考 Dubbo 负载均衡策略） +3. 消息过滤器（Producer 发送消息到 Broker，Broker 存储消息信息，Consumer 消费时请求 Broker 端从磁盘文件查询消息文件时,在 Broker 端就使用过滤服务器进行过滤） +4. Broker 同步双写和异步双写中 Master 和 Slave 的交互 +5. Broker 在 4.5.0 版本更新中引入了基于 Raft 协议的多副本选举，之前这是商业版才有的特性 [ISSUE-1046][2] + +## 3 参考 + +1. 《RocketMQ技术内幕》：https://blog.csdn.net/prestigeding/article/details/85233529 +2. 关于 RocketMQ 对 MappedByteBuffer 的一点优化：https://lishoubo.github.io/2017/09/27/MappedByteBuffer%E7%9A%84%E4%B8%80%E7%82%B9%E4%BC%98%E5%8C%96/ +3. 十分钟入门RocketMQ：https://developer.aliyun.com/article/66101 +4. 分布式事务的种类以及 RocketMQ 支持的分布式消息：https://www.infoq.cn/article/2018/08/rocketmq-4.3-release +5. 滴滴出行基于RocketMQ构建企业级消息队列服务的实践：https://yq.aliyun.com/articles/664608 +6. 基于《RocketMQ技术内幕》源码注释：https://github.com/LiWenGu/awesome-rocketmq + +[1]: https://leran2deeplearnjavawebtech.oss-cn-beijing.aliyuncs.com/somephoto/RocketMQ%E6%B5%81%E7%A8%8B.png +[2]: http://rocketmq.apache.org/release_notes/release-notes-4.5.0/ diff --git a/docs/high-performance/read-and-write-separation-and-library-subtable.md b/docs/high-performance/read-and-write-separation-and-library-subtable.md new file mode 100644 index 0000000000000000000000000000000000000000..4937d9fd7f3c961899c5b0a7e7aa9ec4cbf8d1c4 --- /dev/null +++ b/docs/high-performance/read-and-write-separation-and-library-subtable.md @@ -0,0 +1,190 @@ +# 读写分离&分库分表 + +大家好呀！今天和小伙伴们聊聊读写分离以及分库分表。 + +相信很多小伙伴们对于这两个概念已经比较熟悉了，这篇文章全程都是大白话的形式，希望能够给你带来不一样的感受。 + +如果你之前不太了解这两个概念，那我建议你搞懂之后，可以把自己对于读写分离以及分库分表的理解讲给你的同事/朋友听听。 + +**原创不易，若有帮助，点赞/分享就是对我最大的鼓励！** + +_个人能力有限。如果文章有任何需要补充/完善/修改的地方，欢迎在评论区指出，共同进步！_ + +## 读写分离 + +### 何为读写分离？ + +见名思意，根据读写分离的名字，我们就可以知道：**读写分离主要是为了将对数据库的读写操作分散到不同的数据库节点上。** 这样的话，就能够小幅提升写性能，大幅提升读性能。 + +我简单画了一张图来帮助不太清楚读写分离的小伙伴理解。 + +![读写分离](https://guide-blog-images.oss-cn-shenzhen.aliyuncs.com/java-guide-blog/9c624bc130d053860a5089cb9a53310a.png) + +一般情况下，我们都会选择一主多从，也就是一台主数据库负责写，其他的从数据库负责读。主库和从库之间会进行数据同步，以保证从库中数据的准确性。这样的架构实现起来比较简单，并且也符合系统的写少读多的特点。 + +### 读写分离会带来什么问题？如何解决？ + +读写分离对于提升数据库的并发非常有效，但是，同时也会引来一个问题：主库和从库的数据存在延迟，比如你写完主库之后，主库的数据同步到从库是需要时间的，这个时间差就导致了主库和从库的数据不一致性问题。这也就是我们经常说的 **主从同步延迟** 。 + +主从同步延迟问题的解决，没有特别好的一种方案（可能是我太菜了，欢迎评论区补充）。你可以根据自己的业务场景，参考一下下面几种解决办法。 + +**1.强制将读请求路由到主库处理。** + +既然你从库的数据过期了，那我就直接从主库读取嘛！这种方案虽然会增加主库的压力，但是，实现起来比较简单，也是我了解到的使用最多的一种方式。 + +比如 `Sharding-JDBC` 就是采用的这种方案。通过使用 Sharding-JDBC 的 `HintManager` 分片键值管理器，我们可以强制使用主库。 + +```java +HintManager hintManager = HintManager.getInstance(); +hintManager.setMasterRouteOnly(); +// 继续JDBC操作 +``` + +对于这种方案，你可以将那些必须获取最新数据的读请求都交给主库处理。 + +**2.延迟读取。** + +还有一些朋友肯定会想既然主从同步存在延迟，那我就在延迟之后读取啊，比如主从同步延迟 0.5s,那我就 1s 之后再读取数据。这样多方便啊！方便是方便，但是也很扯淡。 + +不过，如果你是这样设计业务流程就会好很多：对于一些对数据比较敏感的场景，你可以在完成写请求之后，避免立即进行请求操作。比如你支付成功之后，跳转到一个支付成功的页面，当你点击返回之后才返回自己的账户。 + +另外，[《MySQL 实战 45 讲》](https://time.geekbang.org/column/intro/100020801?code=ieY8HeRSlDsFbuRtggbBQGxdTh-1jMASqEIeqzHAKrI%3D)这个专栏中的[《读写分离有哪些坑？》](https://time.geekbang.org/column/article/77636)这篇文章还介绍了很多其他比较实际的解决办法，感兴趣的小伙伴可以自行研究一下。 + +### 如何实现读写分离？ + +不论是使用哪一种读写分离具体的实现方案，想要实现读写分离一般包含如下几步： + +1. 部署多台数据库，选择其中的一台作为主数据库，其他的一台或者多台作为从数据库。 +2. 保证主数据库和从数据库之间的数据是实时同步的，这个过程也就是我们常说的**主从复制**。 +3. 系统将写请求交给主数据库处理，读请求交给从数据库处理。 + +落实到项目本身的话，常用的方式有两种： + +**1.代理方式** + +![读写分离-代理层](https://guide-blog-images.oss-cn-shenzhen.aliyuncs.com/java-guide-blog/461112716e30db118f4c784adc6e2ff7.png) + +我们可以在应用和数据中间加了一个代理层。应用程序所有的数据请求都交给代理层处理，代理层负责分离读写请求，将它们路由到对应的数据库中。 + +提供类似功能的中间件有 **MySQL Router**（官方）、**Atlas**（基于 MySQL Proxy）、**Maxscale**、**MyCat**。 + +**2.组件方式** + +在这种方式中，我们可以通过引入第三方组件来帮助我们读写请求。 + +这也是我比较推荐的一种方式。这种方式目前在各种互联网公司中用的最多的，相关的实际的案例也非常多。如果你要采用这种方式的话，推荐使用 `sharding-jdbc` ，直接引入 jar 包即可使用，非常方便。同时，也节省了很多运维的成本。 + +你可以在 shardingsphere 官方找到[sharding-jdbc 关于读写分离的操作](https://shardingsphere.apache.org/document/legacy/3.x/document/cn/manual/sharding-jdbc/usage/read-write-splitting/)。 + +### 主从复制原理了解么？ + +MySQL binlog(binary log 即二进制日志文件) 主要记录了 MySQL 数据库中数据的所有变化(数据库执行的所有 DDL 和 DML 语句)。因此，我们根据主库的 MySQL binlog 日志就能够将主库的数据同步到从库中。 + +更具体和详细的过程是这个样子的（图片来自于：[《MySQL Master-Slave Replication on the Same Machine》](https://www.toptal.com/mysql/mysql-master-slave-replication-tutorial)）： + +![MySQL主从复制](https://guide-blog-images.oss-cn-shenzhen.aliyuncs.com/java-guide-blog/78816271d3ab52424bfd5ad3086c1a0f.png) + +1. 主库将数据库中数据的变化写入到 binlog +2. 从库连接主库 +3. 从库会创建一个 I/O 线程向主库请求更新的 binlog +4. 主库会创建一个 binlog dump 线程来发送 binlog ，从库中的 I/O 线程负责接收 +5. 从库的 I/O 线程将接收的 binlog 写入到 relay log 中。 +6. 从库的 SQL 线程读取 relay log 同步数据本地（也就是再执行一遍 SQL ）。 + +怎么样？看了我对主从复制这个过程的讲解，你应该搞明白了吧! + +你一般看到 binlog 就要想到主从复制。当然，除了主从复制之外，binlog 还能帮助我们实现数据恢复。 + +🌈 拓展一下： + +不知道大家有没有使用过阿里开源的一个叫做 canal 的工具。这个工具可以帮助我们实现 MySQL 和其他数据源比如 Elasticsearch 或者另外一台 MySQL 数据库之间的数据同步。很显然，这个工具的底层原理肯定也是依赖 binlog。canal 的原理就是模拟 MySQL 主从复制的过程，解析 binlog 将数据同步到其他的数据源。 + +另外，像咱们常用的分布式缓存组件 Redis 也是通过主从复制实现的读写分离。 + +🌕 简单总结一下： + +**MySQL 主从复制是依赖于 binlog 。另外，常见的一些同步 MySQL 数据到其他数据源的工具（比如 canal）的底层一般也是依赖 binlog 。** + +## 分库分表 + +读写分离主要应对的是数据库读并发，没有解决数据库存储问题。试想一下：**如果 MySQL 一张表的数据量过大怎么办?** + +换言之，**我们该如何解决 MySQL 的存储压力呢？** + +答案之一就是 **分库分表**。 + +### 何为分库？ + +**分库** 就是将数据库中的数据分散到不同的数据库上。 + +下面这些操作都涉及到了分库： + +- 你将数据库中的用户表和用户订单表分别放在两个不同的数据库。 +- 由于用户表数据量太大，你对用户表进行了水平切分，然后将切分后的 2 张用户表分别放在两个不同的数据库。 + +### 何为分表？ + +**分表** 就是对单表的数据进行拆分，可以是垂直拆分，也可以是水平拆分。 + +**何为垂直拆分？** + +简单来说，垂直拆分是对数据表列的拆分，把一张列比较多的表拆分为多张表。 + +举个例子：我们可以将用户信息表中的一些列单独抽出来作为一个表。 + +**何为水平拆分？** + +简单来说，水平拆分是对数据表行的拆分，把一张行比较多的表拆分为多张表。 + +举个例子：我们可以将用户信息表拆分成多个用户信息表，这样就可以避免单一表数据量过大对性能造成影响。 + +[《从零开始学架构》](https://time.geekbang.org/column/intro/100006601?code=i00Nq3pHUcUj04ZWy70NCRl%2FD2Lfj8GVzcGzZ3Wf5Ug%3D) 中的有一张图片对于垂直拆分和水平拆分的描述还挺直观的。 + +![](https://guide-blog-images.oss-cn-shenzhen.aliyuncs.com/java-guide-blog/662ea3bda90061d0b40177e3a46fefc3.jpg) + +### 什么情况下需要分库分表？ + +遇到下面几种场景可以考虑分库分表： + +- 单表的数据达到千万级别以上，数据库读写速度比较缓慢（分表）。 +- 数据库中的数据占用的空间越来越大，备份时间越来越长（分库）。 +- 应用的并发量太大（分库）。 + +### 分库分表会带来什么问题呢？ + +记住，你在公司做的任何技术决策，不光是要考虑这个技术能不能满足我们的要求，是否适合当前业务场景，还要重点考虑其带来的成本。 + +引入分库分表之后，会给系统带来什么挑战呢？ + +- **join 操作** ： 同一个数据库中的表分布在了不同的数据库中，导致无法使用 join 操作。这样就导致我们需要手动进行数据的封装，比如你在一个数据库中查询到一个数据之后，再根据这个数据去另外一个数据库中找对应的数据。 +- **事务问题** ：同一个数据库中的表分布在了不同的数据库中，如果单个操作涉及到多个数据库，那么数据库自带的事务就无法满足我们的要求了。 +- **分布式 id** ：分库之后， 数据遍布在不同服务器上的数据库，数据库的自增主键已经没办法满足生成的主键唯一了。我们如何为不同的数据节点生成全局唯一主键呢？这个时候，我们就需要为我们的系统引入分布式 id 了。 +- ...... + +另外，引入分库分表之后，一般需要 DBA 的参与，同时还需要更多的数据库服务器，这些都属于成本。 + +### 分库分表有没有什么比较推荐的方案？ + +ShardingSphere 项目（包括 Sharding-JDBC、Sharding-Proxy 和 Sharding-Sidecar）是当当捐入 Apache 的，目前主要由京东数科的一些巨佬维护。 + +![](https://img-blog.csdnimg.cn/img_convert/60649996bfc69acb1953063dddf0c2e6.png) + +ShardingSphere 绝对可以说是当前分库分表的首选！ShardingSphere 的功能完善，除了支持读写分离和分库分表，还提供分布式事务、数据库治理等功能。 + +另外，ShardingSphere 的生态体系完善，社区活跃，文档完善，更新和发布比较频繁。 + +艿艿之前写了一篇分库分表的实战文章，各位朋友可以看看：[《芋道 Spring Boot 分库分表入门》](https://mp.weixin.qq.com/s/A2MYOFT7SP-7kGOon8qJaw) 。 + +### 分库分表后，数据怎么迁移呢？ + +分库分表之后，我们如何将老库（单库单表）的数据迁移到新库（分库分表后的数据库系统）呢？ + +比较简单同时也是非常常用的方案就是**停机迁移**，写个脚本老库的数据写到新库中。比如你在凌晨 2 点，系统使用的人数非常少的时候，挂一个公告说系统要维护升级预计 1 小时。然后，你写一个脚本将老库的数据都同步到新库中。 + +如果你不想停机迁移数据的话，也可以考虑**双写方案**。双写方案是针对那种不能停机迁移的场景，实现起来要稍微麻烦一些。具体原理是这样的： + +- 我们对老库的更新操作（增删改），同时也要写入新库（双写）。如果操作的数据不存在于新库的话，需要插入到新库中。 这样就能保证，咱们新库里的数据是最新的。 +- 在迁移过程，双写只会让被更新操作过的老库中的数据同步到新库，我们还需要自己写脚本将老库中的数据和新库的数据做比对。如果新库中没有，那咱们就把数据插入到新库。如果新库有，旧库没有，就把新库对应的数据删除（冗余数据清理）。 +- 重复上一步的操作，直到老库和新库的数据一致为止。 + +想要在项目中实施双写还是比较麻烦的，很容易会出现问题。我们可以借助上面提到的数据库同步工具 Canal 做增量数据迁移（还是依赖 binlog，开发和维护成本较低）。 diff --git a/docs/high-quality-technical-articles/advanced-programmer/seven-tips-for-becoming-an-advanced-programmer.md b/docs/high-quality-technical-articles/advanced-programmer/seven-tips-for-becoming-an-advanced-programmer.md new file mode 100644 index 0000000000000000000000000000000000000000..cd8ac374ceffcdaef27d0eb25864f815cff1b455 --- /dev/null +++ b/docs/high-quality-technical-articles/advanced-programmer/seven-tips-for-becoming-an-advanced-programmer.md @@ -0,0 +1,96 @@ +--- +title: 给想成长为高级别开发同学的七条建议 +category: 技术文章精选集 +tag: + - 练级攻略 +--- + +> 普通程序员要想成长为高级程序员甚至是专家等更高级别，应该注意在哪些方面注意加强？ +> +> 开发内功修炼号主飞哥在这篇文章中就给出了七条实用的建议。 +> +> 原文：https://mp.weixin.qq.com/s/8lMGzBzXine-NAsqEaIE4g + +### 建议1：刻意加强需求评审能力 + +先从需求评审开始说。在互联网公司，需求评审是开发工作的主要入口。 + +对于普通程序员来说，一般就是根据产品经理提的需求细节，开始设想这个功能要怎么实现，开发成本大概需要多长时间。把自己当成了需求到代码之间的翻译官。很少去思考需求的合理性，对于自己做的事情有多大价值，不管也不问。 + +而对于高级别的程序员来说，并不会一开始就陷入细节，而是会更多地会从产品本身出发，询问产品经理为啥要做这个细节，目的是啥。换个说法，就是会先考虑这个需求是不是合理。 + +如果需求高级不合理就进行 PK ，要么对需求进行调整，要么就砍掉。不过要注意的是 PK 和调整需求不仅仅砍需求，还有另外一个方向，那就是对需求进行加强。 + +产品同学由于缺乏技术背景，很可能想的并不够充分，这个时候如果你有更好的想法，也完全可以提出来，加到需求里，让这个需求变得更有价值。 + +总之，高级程序员并不会一五一十地按产品经理的需求文档来进行后面的开发，而是**一切从有利于业务的角度出发思考，对产品经理的需求进行删、改、增。** + +这样的工作表面看似和开发无关，但是只有这样才能保证后续所有开发同学都是有价值的，而不是做一堆无用功。无用功做的多了会极大的挫伤开发的成就感。 + +所以，**普通程序员要想成长为更高级别的开发，一定要加强需求评审能力的培养**。 + +### 建议2：主动思考效率 + +普通的程序员，按部就班的去写代码，有活儿来我就干，没活儿的时候我就呆着。很少去深度思考现有的这些代码为什么要这么写，这么写的好处是啥，有哪些地方存在瓶颈，我是否可以把它优化一些。 + +而高级一点程序员，并不会局限于把手头的活儿开发就算完事。他们会主动去琢磨，现在这种开发模式是不是不够的好。那么我是否能做一个什么东西能把这个效率给提升起来。 + +举一个小例子，我 6 年前接手一个项目的时候，我发现运营一个月会找我四次，就是找我给她发送一个推送。她说以前的开发都是这么帮他弄的。虽然这个需求处理起来很简单，改两行发布一下就完事。但是烦啊，你想象一下你正专心写代码呢，她又双叒来找你了，思路全被她中断了。而且频繁地操作线上本来就会引入不确定的风险，万一那天手一抽抽搞错了，线上就完蛋了。 + +我的做法就是，我专门抽了一周的时间，给她做了一套运营后台。这样以后所有的运营推送她就直接在后台上操作就完事了。我倒出精力去做其它更有价值的事情去了。 + +所以，**第二个建议就是要主动思考一下现有工作中哪些地方效率有改进的空间，想到了就主动去改进它！** + +### 建议3：加强内功能力 + +哪些算是内功呢，我想内功修炼的读者们肯定也都很熟悉的了，指的就是大家学校里都学过的操作系统、网络等这些基础。 + +普通的程序员会觉得，这些基础知识我都会好么，我大学可是足足学了四年的。工作了以后并不会刻意来回头再来加强自己在这些基础上的深层次的提升。 + +高级的程序员，非常清楚自己当年学的那点知识太皮毛了。工作之余也会深入地去研究 Linux、研究网络等方向的底层实现。 + +事实上，互联网业界的技术大牛们很大程度是因为对这些基础的理解相当是深厚，具备了深厚的内功以后才促使他们成长为了技术大牛。 + +我很难相信一个不理解底层，只会 CURD，只会用别人框架的开发将来能在技术方向成长为大牛。 + +所以，**还建议多多锻炼底层技术内功能力**。如果你不知道怎么练，那就坚持看「开发内功修炼」公众号。 + +### 建议4：思考性能 + +普通程序员往往就是把需求开发完了就不管了，只要需求实现了，测试通过了就可以交付了。将来流量会有多大，没想过。自己的服务 QPS 能支撑多少，不清楚。 + +而高级的程序员往往会关注自己写出来的代码的性能。 + +在需求评审的时候，他们一般就会估算大概的请求流量有多大。进而设计阶段就会根据这个量设计符合性能要求的方案。 + +在上线之前也会进行性能压测，检验一下在性能上是否符合预期。如果性能存在问题，瓶颈在哪儿，怎么样能进行优化一下。 + +所以，**第四个建议就是一定要多多主动你所负责业务的性能，并多多进行优化和改进**。我想这个建议的重要程度非常之高。但这是需要你具备深厚的内功才可以办的到的，否则如果你连网络是怎么工作的都不清楚，谈何优化！ + +### 建议5：重视线上 + +普通程序员往往对线上的事情很少去关注，手里记录的服务器就是自己的开发机和发布机，线上机器有几台，流量多大，最近有没有波动这些可能都不清楚。 + +而高级的程序员深深的明白，有条件的话，会尽量多多观察自己的线上服务，观察一下代码跑的咋样，有没有啥 error log。请求峰值的时候 CPU、内存的消耗咋样。网络端口消耗的情况咋样，是否需要调节一些参数配置。 + +当性能不尽如人意的时候，可能会回头再来思考出性能的改进方案，重新开发和上线。 + +你会发现在线上出问题的时候，能紧急扑上前线救火的都是高级一点的程序员。 + +所以，**飞哥给的第五个建议就是要多多观察线上运行情况**。只有多多关注线上，当线上出故障的时候，你才能承担的起快速排出线上问题的重任。 + +### 建议6：关注全局 + +普通程序员是你分配给我哪个模块，我就干哪个模块，给自己的工作设定了非常小的一个边界，自己所有的眼光都聚集在这个小框框内。 + +高级程序员是团队内所有项目模块，哪怕不是他负责的，他也会去熟悉，去了解。具备这种思维的同学无论在技术上，无论是在业务上，成长的也都是最快的。在职级上得到晋升，或者是职位上得到提拔的往往都是这类同学。 + +甚至有更高级别的同学，还不止于把目光放在团队内，甚至还会关注公司内其它团队，甚至是业界的业务和技术栈。写到这里我想起了张一鸣说过的，不给自己的工作设边界。 + +所以，**建议要有大局观，不仅仅是你负责的模块，整个项目其实你都应该去关注**。而不是连自己组内同学做的是啥都不知道。 + +### 建议7：归纳总结能力 + +普通程序员往往是工作的事情做完就拉到，很少回头去对自己的技术，对业务进行归纳和总结。 + +而高级的程序员往往都会在一件比较大的事情做完之后总结一下，做个ppt，写个博客啥的记录下来。这样既对自己的工作是一个归纳，也可以分享给其它同学，促进团队的共同成长。 diff --git a/docs/high-quality-technical-articles/interview/screen-candidates-for-packaging.md b/docs/high-quality-technical-articles/interview/screen-candidates-for-packaging.md new file mode 100644 index 0000000000000000000000000000000000000000..1269b39eb25f1f56591374daafd2bd44ba2b48a5 --- /dev/null +++ b/docs/high-quality-technical-articles/interview/screen-candidates-for-packaging.md @@ -0,0 +1,115 @@ +--- +title: 包装严重的IT行业，作为面试官，我是如何甄别应聘者的包装程度 +category: 技术文章精选集 +tag: + - 面试 +--- + +> 经常听到培训班待过的朋友给我说他们的老师是怎么教他们“包装”自己的，不光是培训班，我认识的很多朋友也都会在面试之前“包装”一下自己，所以这个现象是普遍存在的。但是面试官也不都是傻子，通过下面这篇文章来看看面试官是如何甄别应聘者的包装程度。 +> +> **原文地址** ： https://dwz.cn/mUjRa2Jr + +## 前言 + +上到职场干将下到职场萌新，都会接触到包装简历这个词语。当你简历投到心仪的公司，公司内负责求职的工作人员是如何甄别简历的包装程度的？Coody 老师根据自己的经验写下了这篇文章，谁都不是天才，包装无可厚非，切勿对号入座! + +## 正文 + +在互联网极速膨胀的社会背景下，各行各业涌入互联网的 IT 民工日益增大。 + +早在 2016 年，我司发布了 Java、Ios 工程师的招聘信息，就 Java 工程师单个岗位而言，日收简历近 200 份，Ios 日收简历近一千份。 + +没错，这就是当年培训机构对 Ios 工程师这个岗位发起的市场讨伐。而随着近几年的发展，市场供大于求现象日益严重。人员摸底成为用人单位对人才考核的重大难题。 + +笔者初次与求职者以面试的形式进行沟通是 2015 年 6 月。由于当时笔者从业时间短，经验不够丰富，错过了一些优秀的求职者。 + +三年后的，今天，笔者再次因公司规模扩大而深入与求职者进行沟通。 + +### 1.初选如何鉴别劣质简历 + +培训机构除了提供技术培训，往往还提供**简历编写指导**、**面试指导**。很多潜移默化的东西，我们很难甄别。但培训机构包装的简历，存在千遍一律的特征。 + +**年龄较小却具备高级文凭** + +年龄较小却具备高级文凭，这个或许不能作为一项标准，但是大部分的应聘者，均符合传统文凭的市场情况。个别技术爱好者可能通过自考获得文凭，这种情况需提供独有的技术亮点。 + +**年龄较大却几乎不具备技术经验** + +年龄较大却几乎不具备技术经验，相对前一点，这个问题就比较严重了。大家都知道，一个正常的人，对新事物的接受能力会随着年龄的增长而降低，互联网技术也包括其内。如果一个人年龄较大不具备技术经验，那么只有两种情况： + +1. 中途转行(通过培训、自学等方式强行入行)。 +2. 由于能力问题，已有的经验不敢写入简历中(能力与经验/薪资不符)。 + +**项目经验多为管理系统** + +项目经验，这一项用来评估应聘者的水平太合适不过了。随着互联网的发展迭代，每一年都会出来很多创新型的互联网公司和新兴行业。笔者最近发布的招聘需求里面。CRM 系统、商城、XX 管理系统、问卷系统、课堂系统占了 90%的份额。试问现在 2019 年，内部管理系统这么火爆么。言归正传，我们对于简历的评估，应当多考虑“确有其事”的项目。比如说该人员当时就职于 XX 公司，该公司当时的背景下确实研发了该项目（外包除外）。 + +**项目的背景不符合互联网发展背景** + +项目背景，每年的市场走向不同，从早些年的电商、彩票风波，到后来的 O2O、夺宝、直播、新零售。每个系列的产品的出现，都符合市场的定义。如果简历中出现 18 年、19 年才刚立项做彩票(15 年政府禁止互联网彩票)、O2O、商城、夺宝(17 年初禁止夺宝类产品)、直播等产品。显然是非常不符合市场需求的。这种情况下需考虑具体情况是否存在理解空间。 + +**缺乏新意** + +不同工作经验下多个项目技术架构或项目结构一致，缺乏新意。一般情况而言，不同的公司技术栈不同，甚至产品的走向和模式完全不同。故此，当一个应聘者多家公司的多个项目中写到的技术千遍一律，业务流程异曲同工。看似整洁，实则更加缺乏说服力。 + +**技术过于新颖，对旧技术却只字不提** + +技术过于新颖，根据互联网技术发展的走向来看，我们在不断向新型技术靠拢。但是任何企业作为资历深厚的 CTO、架构师来说。往往会选择更稳定、更成熟、学习成本更低的已有技术。对新技术的追求不会过于明显。而培训机构则是“哪项技术火我们就教哪项”。故此，出现了很多走入互联网行业的新人对旧技术一窍不通。甚至很多技术都没听过。 + +**工作经验较丰富，但从事的工作较低级。** + +工作经验比较丰富，单从事的工作比较低级，这里存在很大的问题，要么就是原公司没法提供合理的舞台给该人员更好的发展空间，要么就是该人员能力不够，没法完成更高级的工作。当然，还有一种情况就是该人员包装过多的经验导致简历中不和谐。这种情况需要评估公司规模和背景。 + +**公司背景跨省跨市** + +可能很多用人单位和鄙人一样，最近接受到的简历，90%为跨市跳槽的人员。其中武汉占了 60%以上。均为武汉 XX 网络科技有限公司。公司规模均小于 50 人。也有厦门、宁波、南京等等。这个问题笔者就不提了，大家都懂的。跨地区跳槽不好查证。 + +**缺少业余热情于技术的证明** + +有些眼高手低的技术员，做了几个管理系统。用到的技术确是各种分布式、集群、高并发、大数据、消息队列、搜索引擎、镜像容器、多数据库、数据中心等等。期望的薪资也高于行业标准。一个对技术很热情的人，业余时间肯定在技术方面花费过不少时间。那么可以从该人员的博客、git 地址入手。甚至可以通过手机号、邮箱、昵称、马甲。去搜索引擎进行搜集，核实该人员是否在论坛、贴吧、开源组织有过技术背景。 + +### 2. 进入面试阶段，如何甄别对方的水分 + +在甄别对方水分这一块，并没有明确的标准，但是笔者可以提几个点。这也是笔者在实际面试中惯用的做法。 + +**通过公司规模、团队规模、人员分配是否合理、人员合作方式来判断对方是否具备工作经验** + +当招聘初级、初中级 IT 人员的时候，可以询问一些问题，比如公司有多少人、产品团队多少人、产品、技术、后端、前端、客户端、UI、测试各多少人。工作中如何合作的、产品做了多少时间、何时上线的、上线后多长时间迭代一个版本、多长时间迭代一个活动、发展至今多少用户(后端)、多大并发等等(后端)。根据笔者的经验，如果一个人没有任何从业周期，面对这些问题的时候，或多或少答非所问或者给出的答案非常不合理。 + +**背景公司入职时间、项目立项实现、完工时间、产品技术栈、迭代流程的核实** + +很多应聘者对于简历过于包装，只为了追求更高的薪资。当我们问起：你是 xx 年 xx 月入职的该公司？你们项目是 xx 年 xx 月上线的？你们项目使用到 xx 技术？你们每次上线前夕是如何评审的。面对这些问题，应聘者给出的答案经常与简历不符合。这样问题就来了。关于项目使用到的技术，很多项目我们可以通过搜索该项目的地址、APP。通过 http 协议、技术特征、抛出异常特征来大致判别对方使用到的技术。如果应聘者给出的答案明显与之不匹配，嘿嘿。 + +**通过技术深度，甄别对方的技术水平** + +1. 确定对方的技术栈，如：你做过最满意的项目是哪个，为什么？你最喜欢使用的技术是哪些，为什么？ + +2. 确定对方项目的发展程度，如：你们产品做了多久，迭代了多久，发布了多少版本，发展到了多少用户，带来多大并发，多少流水？ + +3. 确定对方的技术属性，如：平时你会通过什么渠道跟其他技术人形成技术沟通与交流，主要交流过哪些技术？ + +笔者最近接待的面试者，很多面试者的简历上，写着层出不穷的各种技术，为了不跨越求职者的技术栈，笔者专门挑应聘者简历写到或用到的技术来进行询问。笔者举几个例子。 + +**1)某求职者简历上写着熟练使用 redis。** + +1. 介绍一下你使用过 redis 的哪些数据结构，并描述一下使用的业务场景； +2. 介绍一下你操作 redis 用到的是什么插件； +3. 介绍一下你们使用的序列化方式； +4. 介绍一下你们使用 redis 遇到过给你印象较深的问题； + +**2)某求职者声称熟练 http 协议并编写过爬虫。** + +1. 介绍一下你所了解的几个 http head 头并描述其用途； +2. 如果前端提交成功，后端无法接受数据，这时候你将如何排查问题； +3. 描述一下 http 基本报文结构; +4. 如果服务器返回 cookie，存储在响应内容里面 head 头的字段叫做什么; +5. 当服务端返回 Transer-Encoding：chunked 代表什么含义 +6. 是否了解分段加载并描述下其技术流程。 + +当然，面向不同的技术，对应的技术深度自然也不一样。 + +大体上的套路便是如此：你说你杀过猪。那么你杀过几头猪，分别是啥时候，杀过多大的猪，有啥毛色。事实上对方可能给你的回答是：杀过、十几头、杀过五十斤的、杀过绿色、黄色、红色、蓝色的猪。那么问题就来了。 + +然而笔者碰到的问题是：使用 git 两年却不知道 github、使用 redis 一年却不知道数据结构也不知道序列化、专业做爬虫却不懂 content-type 含义、使用搜索引擎技术却说不出两个分词插件、使用数据库读写分离却不知道同步延时等等。 + +写在最后，笔者认为在招聘途中，并不是不允许求职者包装，但是尽可能满足能筹平衡。虽然这篇文章没有完美的结尾，但是笔者提供了面试失败的各种经验。笔者最终招到了如意的小伙伴。也希望所有技术面试官早日找到符合自己产品发展的 IT 伙伴。 diff --git a/docs/high-quality-technical-articles/interview/technical-preliminary-preparation.md b/docs/high-quality-technical-articles/interview/technical-preliminary-preparation.md new file mode 100644 index 0000000000000000000000000000000000000000..ea031996c5fc1cad64b73dba3374fd6cbe8a340a --- /dev/null +++ b/docs/high-quality-technical-articles/interview/technical-preliminary-preparation.md @@ -0,0 +1,213 @@ +--- +title: 从面试官和候选者的角度谈如何准备技术初试 +category: 技术文章精选集 +tag: + - 面试 +--- + +> **内容总结：** +> +> 从面试官和面试者两个角度探讨了技术面试！非常不错！ +> +> - 通过技术基础考察候选者，才能考察到候选者的真实技术实力：技术深度和广度。 +> - 实战与理论结合。比如，候选人叙述 JVM 内存模型布局之后，可以接着问：有哪些原因可能会导致 OOM , 有哪些预防措施? 你是否遇到过内存泄露的问题? 如何排查和解决这类问题? +> - 项目经历考察不宜超过两个。因为要深入考察一个项目的详情，所占用的时间还是比较大的。一般来说，会让候选人挑选一个他或她觉得最有收获的/最有挑战的/印象最深刻的/自己觉得特有意思的项目。然后围绕这个项目进行发问。通常是从项目背景出发，考察项目的技术栈、项目模块及交互的整体理解、项目中遇到的有挑战性的技术问题及解决方案、排查和解决问题、代码可维护性问题、工程质量保障等。 +> - 多问少说，让候选者多表现。根据候选者的回答适当地引导或递进或横向移动。 +> +> **原文地址：** https://www.cnblogs.com/lovesqcc/p/15169365.html + +## 考察目标和思路 + +首先明确，技术初试的考察目标： + +- 候选人的技术基础； +- 候选人解决问题的思路和能力。 + +技术基础是基石（冰山之下的东西），占七分， 解决问题的思路和能力是落地（冰山之上露出的部分），占三分。 业务和技术基础考察，三七开。 + +## 技术基础考察 + +### 为什么要考察技术基础? + +程序员最重要的两种技术思维能力，是逻辑思维能力和抽象设计能力。逻辑思维能力是基础，抽象设计能力是高阶。 考察技术基础，正好可以同时考察这两种思维能力。能不能理解基础技术概念及关联，是考察逻辑思维能力；能不能把业务问题抽象成技术问题并合理的组织映射，是考察抽象设计能力。 + +绝大部分业务问题，都可以抽象成技术问题。在某种意义上，业务问题只是技术问题的领域化表述。 + +因此，**通过技术基础考察候选者，才能考察到候选者的真实技术实力：技术深度和广度。** + +### 技术基础怎么考察？ + +技术基础怎么考察？通过有效的多角度的发问模式来考察。 + +#### 是什么-为什么 + +是什么考察对概念的基本理解，为什么考察对概念的实现原理。 + +比如：索引是什么？ 索引是如何实现的？ + +#### 引导-横向发问-深入发问 + +引导性，比如 “你对 Java 同步工具熟悉吗？” 作个试探，得到肯定答复后，可以进一步问： “你熟悉哪些同步工具类？” 了解候选者的广度； + +获取候选者的回答后，可以进一步问：“ 谈谈 `ConcurrentHashMap` 或 `AQS` 的实现原理？” + +一个人在多大程度上把技术原理能讲得清晰，包括思路和细节，说明他对技术的掌握能力有多强。 + +#### 跳跃式/交叉式发问 + +比如：讲到哈希高效查找，可以谈谈哈希一致性算法 。 两者既有关联又有很多不同点。也是一种技术广度的考察方法。 + +#### 总结性发问 + +比如：你在做 XXX 中，获得了哪些可以分享的经验？ 考察候选人的归纳总结能力。 + +#### 实战与理论结合 + +比如，候选人叙述 JVM 内存模型布局之后，可以接着问：有哪些原因可能会导致 OOM , 有哪些预防措施? 你是否遇到过内存泄露的问题? 如何排查和解决这类问题? + +比如，候选人有谈到 SQL 优化和索引优化，那就正好谈谈索引的实现原理，如何建立最佳索引？ + +再比如，候选人有谈到事务，那就正好谈谈事务实现原理，隔离级别，快照实现等； + +#### 熟悉与不熟悉结合 + +针对候选人简历上写的熟悉的部分，和没有写出的都问下。比如候选人简历上写着：熟悉 JVM 内存模型， 那我就考察下内存管理相关（熟悉部分），再考察下 Java 并发工具类（不确定是否熟悉部分）。 + +#### 死知识与活知识结合 + +比如，查找算法有哪些？顺序查找、二分查找、哈希查找。这些大家通常能说出来，也是“死知识”。 + +这些查找算法各适用于什么场景？在你工作中，有哪些场景用到了哪些查找算法？为什么？ 这些是“活知识”。 + +#### 学习或工作中遇到的 + +有时，在学习和工作中遇到的问题，也可以作为面试题。 + +比如，最近在学习《操作系统导论》并发部分，有一章节是如何使数据结构成为线程安全的。这里就有一些可以提问的地方：如何实现一个锁？如何实现一个线程安全的计数器？如何实现一个线程安全的链表？如何实现一个线程安全的 `Map` ？如何提升并发的性能？ + +工作中遇到的问题，也可以抽象提炼出来，作为技术基础面试题。 + +#### 技术栈适配度发问 + +如果候选人（简历上所写的）使用的某些技术与本公司的技术栈比较契合，则可以针对这些技术点进行深入提问，考察候选人在这些技术点的掌握程度。如果掌握程度比较好，则技术适配度相对更高一些。 + +当然，这一点并不能作为筛掉那些没有使用该技术栈的候选人的依据。比如本公司使用 `MongoDB` 和 `MySQL`， 而一个候选人没有用过 `Mongodb，` 但使用过 `MySQL`, `Redis`, `ES`, `HBase` 等多种存储系统，那么适配度并不比仅使用过 `MySQL` 和 `MongoDB` 的候选人逊色，因为他所涉及的技术广度更大，可以推断出他有足够能力掌握 `Mongodb`。 + +#### 创造有个性的面试题库 + +每个技术面试官都会有一个面试题库。持续积累面试题库，日常中突然想到的问题，就随手记录下来。 + +## 业务维度考察 + +### 为什么要考察业务维度？ + +技术基础考察，容易错过的地方是，候选人的非技术能力特质，比如沟通组织能力、带项目能力、抗压能力、解决实际问题的能力、团队影响力、其它性格特质等。 + +### 为什么不能单考察业务维度？ + +因为业务方面通常比较熟悉，可能就直接按照现有方案说出来了，很难考察到候选人的深入理解、横向拓展和归纳总结能力。 + +这一点，建议有针对性地考察下候选人的归纳总结能力：比如， 微服务搭建或开发或维护/保证系统稳定性或性能方面的过程中，你收获了哪些可以分享的经验？ + +## 解决问题能力考察 + +仅仅只是技术基础还不够，通常最好结合实际业务，针对他项目里的业务，抽象出技术问题进行考察。 + +解决思路重在层层递进。这一点对于面试官的要求也比较高，兼具良好的倾听能力、技术深度和业务经验。首先要仔细倾听候选人的阐述，找到适当的技术切入点，然后进行发问。如果进不去，那就容易考察失败。 + +### 设计问题 + +- 比如多个机器间共享大量业务对象，这些业务对象之间有些联合字段是重复的，如何去重？ +- 如果瞬时有大量请求涌入，如何保证服务器的稳定性？ + +### 项目经历 + +项目经历考察不宜超过两个。因为要深入考察一个项目的详情，所占用的时间还是比较大的。 + +一般来说，会让候选人挑选一个他或她觉得最有收获的/最有挑战的/印象最深刻的/自己觉得特有意思的项目。然后围绕这个项目进行发问。通常是从项目背景出发，考察项目的技术栈、项目模块及交互的整体理解、项目中遇到的有挑战性的技术问题及解决方案、排查和解决问题、代码可维护性问题、工程质量保障等。 + +## 面试官如何做好一场面试? + +### 预先准备 + +面试官也需要做一些准备。比如熟悉候选者的技能优势、工作经历等，做一个面试设计。 + +在面试将要开始时，做好面试准备。此外，面试官也需要对公司的一些基本情况有所了解，尤其是公司所使用技术栈、业务全景及方向、工作内容、晋升制度等，这一点技术型候选人问得比较多。 + +### 面试启动 + +一般以候选人自我介绍启动，不过候选人往往会谈得比较散，因此，我会直接提问：谈谈你有哪些优势以及自己觉得可以改进的地方？ + +然后以一个相对简单的基础题作为技术提问的开始：你熟悉哪些查找算法？大多数人是能答上顺序查找、二分查找、哈希查找的。 + +### 问题设计 + +提前阅读候选人简历，从简历中筛选出关键词，根据这些关键词进行有针对性地问题设计。 + +比如候选人简历里提到 `MVVM` ，可以问 `MVVM` 与 `MVC` 的区别； 提到了观察者模式，可以谈谈观察者模式，顺便问问他还熟悉哪些设计模式。 + +### 宽松氛围 + +即使问的问题比较多比较难，也要注意保持宽松氛围。 + +在面试前，根据候选人基本信息适当调侃一下，比如一位候选人叫汪奎，那我就说：之前我们团队有位叫袁奎，我们都喊他奎爷。 + +在面试过程中，适当提示，或者给出少量自己的看法，也能缓解候选人的紧张情绪。 + +### 学会倾听 + +多问少说，让候选者多表现。根据候选者的回答适当地引导或递进或横向移动。 + +引导候选人表现他最优势的一面，让他或她感觉好一些：毕竟一场面试双方都付出了时间和精力，不应该是面试官 Diss 候选人的场合，而应该让彼此有更好的交流。很大可能，你也能从候选人那里学到不少东西。 + +面试这件事，只不过双方的角色和立场有所不同，但并不代表面试官的水平就一定高于候选人。 + +### 记录重点 + +认真客观地记录候选人的回答，尽可能避免任何主观评价，亦不作任何加工（比如自己给总结一下，总结能力也是候选人的一个特质）。 + +## 作出判断 + +面试过程是一种铺垫，关键的是作出判断。 + +作出判断最容易陷入误区的是：贪深求全。总希望候选人技术又深入又全面。实际上，这是一种奢望。如果候选人的技术能力又深入又全面，很可能也会面临两种情况： + +1. 候选人有更好的选择； +2. 候选人在其它方面可能存在不足，比如团队协作方面。 + +一个比较合适的尺度是： + +1. 他或她的技术水平能否胜任当前工作； +2. 他或她的技术水平与同组团队成员水平如何； +3. 他或她的技术水平是否与年限相对匹配，是否有潜力胜任更复杂的任务。 + +**不同年龄看重的东西不一样。** + +对于三年以下的工程师，应当更看重其技术基础，因为这代表着他的未来潜能；同时也考察下他在实际开发中的体现，比如团队协作、业务经验、抗压能力、主动学习的热情和能力等。 + +对于三年以上的工程师，应当更看重其业务经验、解决问题能力，看看他或她是如何分析具体问题，在业务范畴内考察其技术基础的深度和广度。 + +如何判断一个候选人的真实技术水平及是否适合所需，这方面，我也在学习中。 + +## 给候选人的话 + +### 关注技术基础 + +一个常见的疑惑是：开发业务系统的大多数时候，基本不涉及数据结构与算法的设计与实现，为什么要考察 `HashMap` 的实现原理？为什么要学好数据结构与算法、操作系统、网络通信这些基础课程？ + +现在我可以给出一个答案了： + +- 正如上面所述，绝大多数的业务问题，实际上最终都会映射到基础技术问题上：数据结构与算法的实现、内存管理、并发控制、网络通信等；这些是理解现代互联网大规模程序以及解决程序疑难问题的基石，—— 除非能祝福自己永远都不会遇到疑难问题，永远都只满足于编写 CRUD； +- 这些技术基础正是程序世界里最有趣最激动人心的地方。如果对这些不感兴趣，就很难在这个领域里深入进去，不如及早转行从事其它职业，非技术的世界一直都很精彩广阔（有时我也想多出去走走，不想局限于技术世界）； +- 技术基础是程序员的内功，而具体技术则是招式。徒有招式而内功不深，遇到高手（优秀同行从业者的竞争及疑难杂症）容易不堪一击； +- 具备扎实的专业技术基础，能达到的上限更高，未来更有可能胜任复杂的技术问题求解，或者在同样的问题上能够做到更好的方案； +- 人们喜欢跟与自己相似的人合作，牛人倾向于与牛人合作能得到更好的效果；如果一个团队大部分人技术基础比较好，那么进来一个技术基础比较薄弱的人，协作成本会变高；如果你想和牛人一起合作拿到更好的结果，那就要让自己至少在技术基础上能够与牛人搭配的上； +- 在 CRUD 的基础上拓展其它才能也不失为一种好的选择，但这不会是一个真正的程序员的姿态，顶多是有技术基础的产品经理、项目经理、HR、运营、客满等其它岗位人才。这是职业选择的问题，已经超出了考察程序员的范畴。 + +### 不要在意某个问题回答不上来 + +如果面试官问你很多问题，而有些没有回答上来，不要在意。面试官很可能只是在测试你的技术深度和广度，然后判断你是否达到某个水位线。 + +重点是：有些问题你答得很有深度，也体现了你的深度思考能力。 + +这一点是我当了技术面试官才领会到的。当然，并不是每位技术面试官都是这么想的，但我觉得这应该是个更合适的方式。 \ No newline at end of file diff --git a/docs/high-quality-technical-articles/interview/the-experience-and-thinking-of-an-interview-experienced-by-an-older-programmer.md b/docs/high-quality-technical-articles/interview/the-experience-and-thinking-of-an-interview-experienced-by-an-older-programmer.md new file mode 100644 index 0000000000000000000000000000000000000000..efb606407714a08121d1ac2c972e9c44e8f81fd7 --- /dev/null +++ b/docs/high-quality-technical-articles/interview/the-experience-and-thinking-of-an-interview-experienced-by-an-older-programmer.md @@ -0,0 +1,361 @@ +--- +title: 一位大龄程序员所经历的面试的历炼和思考 +category: 技术文章精选集 +tag: + - 面试 +--- + +> **内容总结** ： +> +> 本文的作者，今年 36 岁，已有 8 年 JAVA 开发经验。在阿里云三年半，有赞四年半，已是标准的大龄程序员了。 +> +> 下面是本文作者关于面试和个人能力提升的一些小建议（很实用） ： +> +> 1. 个人介绍，是对自己的一个更为清晰、深入和全面的认识契机。 +> 2. 简历是充分展示自己的浓缩精华，也是重新审视自己和过往经历的契机。不仅仅是简要介绍技能和经验，更要最大程度凸显自己的优势领域（差异化）。 +> 3. 我个人是不赞成海投的，而倾向于定向投。找准方向投，虽然目标更少，但更有效率。 +> 4. 技术探索，一定要先理解原理。原理不懂，就会浮于表层，不能真正掌握它。技术原理探究要掌握到什么程度？数据结构与算法设计、考量因素、技术机制、优化思路。要在脑中回放，直到一切细节而清晰可见。如果能够清晰有条理地表述出来，就更好了。技术原理探究，一定要看源码。看了源码与没看源码是有区别的。没看源码，虽然说得出来，但终是隔了一层纸；看了源码，才捅破了那层纸，有了自己的理解，也就能说得更加有底气了。当然，也可能是我缺乏演戏的本领。 +> 5. 要善于从失败中学习。正是在杭州四个月空档期的持续学习、思考、积累和提炼，以及面试失败的反思、不断调整对策、完善准备、改善原有的短板，采取更为合理的方式，才在回武汉的短短两个周内拿到比较满意的 offer 。 +> 6. 面试是通过沟通来理解双方的过程。面试中的问题，千变万化，但有一些问题是需要提前准备好的。 +> +> **原文地址** ：https://www.cnblogs.com/lovesqcc/p/14354921.html + +从每一段经历中学习，在每一件事情中修行。善于从挫折中学习。 + +## 引子 + +我今年 36 岁，已有 8 年 JAVA 开发经验。在阿里云三年半，有赞四年半，已是标准的大龄程序员了。 + +在多年的读书、学习和思考中，我的价值观、人生观和世界观也逐步塑造成型。我意识到自己的志趣在于做教育文化方面，因此在半冲动之下，8 月份下旬，裸辞去找工作了。有限理性难以阻挡冲动的个性。不建议裸辞，做事应该有规划、科学合理。 + +尽管我最初认为自己“有理想有目标有意愿有能力”，找一份教育开发的工作应该不难，但事实上我还是过于乐观了。现实很快给我泼了一瓢瓢冷水。我屡战屡败，又屡败屡战。惊讶地发现自己还有这个韧性。面试是一项历炼，如果没有被失败击倒，那么从中会生长出一份韧性，这种韧性能让人走得更远。谁没有经历过失败的历练呢？失败是最伟大的导师了，如果你愿意跟他学一学的话。 + +在面试的过程中，我很快发现自己的劣势： + +- 投入精力做业务，技术深度不够，对原理的理解局限于较浅的层次； +- 视野不够开阔，局限于自己所做的订单业务线，对其它关联业务线（比如商品、营销、支付等）了解不够； +- 思维不够开阔，大部分时间投入在开发和测试上，对运维、产品、业务、商业层面思考都思考不多； +- 缺乏管理经验，年龄偏大；这两项劣势我一度低估，但逐渐凸显出来，甚至让我一度不自信，但最终我还是走出来了。 + +但我也有自己的优势。职业竞争的基本法则是稀缺性和差异化。能够解决大型项目的架构设计和攻克技术难题，精通某个高端技术领域是稀缺性体现；而能够做事能做到缜密周全精细化，有高并发大流量系统开发经验，则是差异性体现。稀缺性是上策，差异化是中策，而降格以求就是下策了。 + +我缺乏稀缺性优势，但还有一点差异化优势： + +- 对每一份工作都很踏实，时间均在 3 年 - 5 年之间，有一点大厂光环，能获得更多面试机会（虽然不一定能面上）； +- 坚持写博客，孜孜不倦地追求软件开发的“道”，时常思考记录开发中遇到的问题及解决方案； +- 做事认真严谨，能够从整体分析和思考问题，也很注重基础提升； +- 对工程质量、性能优化、稳定性建设、业务配置化设计有实践经验； +- 大流量微服务系统的长期开发维护经验。 + +我投出简历的公司并不多。在不多的面试中，我逐渐意识到网上的“斩获几十家大厂 offer”的说法并不可信。理由如下： + +- 如果能真斩获大量大厂 offer ，面试的级别很大概率是初级工程师。要知道面试 4 年以上的工程师，面试的深度和广度令人发指，从基础的算法、到各种中间件的原理机制到实际运维架构，无所不包，真个是沉浸在“技术的海洋”，除非一个人的背景和实力非常强大，平时也做了非常深且广的沉淀； +- 一个背景和实力非常强大的人，是不会有兴趣去投入这么多精力去面各种公司，仅仅是为了吹嘘自己有多能耐；实力越强的人，他会有自己的选择逻辑，投的简历会更定向精准。话说，他为什么不花更多精力投入在那些能够让他有最大化收益的优秀企业呢？ +- 培训机构做的广告。因为他们最清楚新手需要的是信心，哪怕是伪装出来的信心。 + +好了，闲话不多说了。我讲讲自己在面试中所经受的历练和思考吧。 + +## 准备工作 + +人生或许很长，但面试的时间很短，最长不过一小时或一个半小时。别人如何在短短一小时内能够更清晰地认识长达三十多年的你呢？这就需要你做大量细致的准备工作了。在某种程度上，面试与舞蹈有异曲同工之妙：台上五分钟，台下十年功。 + +准备工作主要包括简历准备、个人介绍、公司了解、技术探索、表述能力、常见问题、中高端职位、好的心态。准备工作是对自身和对外部世界的一次全面深入的重新认知。 + +初期，我以为自己准备很充分，简历改改就完事了。随着一次次受挫，才发现自己的准备很不充分。在现在的我看来，准备七分，应变三分。准备，就是要知己知彼，知道对方会问哪些问题（通常是系统/项目/技术的深度和广度）、自己应当如何作答；应变，就是当自己遇到不会、不懂、不知道的问题时，如何合理地展示自己的解决思路，以及根据面试中答不上来的问题查漏补缺，夯实基础。 + +这个过程，实际上也是学习的过程。持续的反思和提炼、学习新的内容、重新认识自己和过往经历等。 + +### 简历准备 + +最开始，我做得比较简单。把以前的简历拿出来，添加上新的工作经历，略作修改，但整体上模板基本不变。 + +在基本面上，我做的是较为细致的，诚实地写上了自己擅长和熟悉的技能和经验经历，排版也尽力做得整洁美观（学过一些 UI 设计）。不浮夸也不故作谦虚。 + +在扩展面上，我做的还是不够的。有一天，一位猎头打电话给我，问：“你最大的优势是什么？”。我顿时说不上来。当时也未多加思考。在后续面试屡遭失败之后，一度有些不自信之后，我开始仔细思考自己的优势来。然后将“对工程质量、性能优化、稳定性建设、业务配置化设计有深入思考和实践经验”写在了“技能素养”栏的第一行，因为这确实是我所做过的、最实在且脚踏实地的且具备概括性的。 + +有时，简历内容的编排顺序也很重要。之前，我把掌握的语言及技术写在前面，而“项目管理能力和团队影响力”之类的写在后面。但投年糕妈妈之后，未有面试直接被拉到不合适里面，受到了刺激，我意识到或许是对方觉得我管理经验不足。因此，刻意将“项目管理能力和团队影响力”提到了前面，表示自己是重视管理方面的，不过，投过新的简历之后，没有回应。我意识到，这样的编排顺序可能会让人误解我是管理能力偏重的（事实上有一位 HR 问我是不是还在写代码），但实际上管理方面我是欠缺的，最后，我还是调回了原来的顺序，凸出自己“工程师的本色”。后面，我又做了一些语句的编排上的修改。 + +随着面试的进展，有时，也会发现自己的简历上写得不够或者以前做得不够的地方。比如，在订单导出这段经历里，我只是写了大幅提升性能和稳定性，显得定性描述化，因此，我添加了一些量化的东西（2w 阻塞 => 300w+，1w/1min）作为证实；比如，8 月份离职，到 12 月份面试的时候，有一段空档期，有些企业会问到这个。因此，我索性加了一句话，说明这段时间我在干些啥；比如，代表性系统和项目，每一个系统和项目的价值和意义（不一定写在上面，但是心里要有数）。功夫要下足。 + +再比如，我很详细地写了有赞的工作经历及经验，但阿里云的那段基本没动。而有些企业对这段经历更感兴趣，我却觉得没太多可说的，留在脑海里的只有少量印象深刻的东西，以及一些博客文章的记录，相比这段工作经历来说显得太单薄。这里实质上不是简历的问题，而是过往经历复盘的问题。建议，在每个项目结束后，都要写个自我复盘。避免时间将这些可贵的经历冲淡。 + +每个人其实都有很多可说的东西，但记录下来的又有多少呢？值得谈道的有多少呢？过往不努力，面试徒伤悲。 + +**简历更新的心得** ： + +- 简历是充分展示自己的浓缩精华，也是重新审视自己和过往经历的契机； +- 不仅仅是简要介绍技能和经验，更要最大程度凸显自己的优势领域（差异化）； +- 增强工作经历的表述，凸显贡献，赢得别人的认可； +- 复盘并记录每一个项目中的收获，为跳槽和面试打下好的铺垫。 + +### 个人介绍 + +面试前通常会要求做个简要的个人介绍。个人介绍通常作为进入面试的前奏曲和缓冲阶段，缓和下紧张气氛。 + +我最开始的个人介绍，个性啊业余生活啊工作经历啊志趣啊等等，似乎不知道该说些什么。实际上，个人介绍是一个充分展示自己的主页。主页应当让自己最最核心的优势一目了然（需要挖掘自己的经历并仔细提炼）。我现在的个人介绍一般会包括：个性（比如偏安静）、做事风格（工作认真严谨、注重质量、善于整体思考）、最大优势（owner 意识、执行力、工程把控能力）、工作经历简述（在每个公司的工作负责什么、贡献了什么、收获了什么）。个人介绍简明扼要，无需赘言。 + +个人介绍，是对自己的一个更为清晰、深入和全面的认识契机。 + +### 公司了解 + +很多人可能跟我一样，对公司业务了解甚少，就直接投出去了。这样其实是不合理的。首先，我个人是不赞成海投的，而倾向于定向投。找准方向投，虽然目标更少，但更有效率。这跟租房一样，我一般在豆瓣上租房，虽然目标源少，但逮着一个就是好运。 + +投一家公司，是因为这家公司符合意向，值得争取，而不是因为这是一家公司。就像找对象，不是为了找一个女人。要确定这家公司是否符合意向，就应当多去了解这家公司：主营业务、未来发展及规划、所在行业及地位、财务状况、业界及网络评价等。 + +在面试的过程中适当谈到公司的业务及思考，是可加分项。亦可用于“你有什么想问的？”的提问。 + +### 技术探索 + +技术能力是一个技术人的基本素养。因此，我觉得，无论未来做什么工作，技术能力过硬，总归是最不可或缺的不可忽视的。 + +原理和设计思想是软件技术中最为精髓的东西。一般软件技术可以分为两个方面： + +- 原理：事物如何工作的基本规律和流程； +- 架构：如何组织大规模逻辑的艺术。 + +**技术探索，一定要先理解原理。原理不懂，就会浮于表层，不能真正掌握它。技术原理探究要掌握到什么程度？数据结构与算法设计、考量因素、技术机制、优化思路。要在脑中回放，直到一切细节而清晰可见。如果能够清晰有条理地表述出来，就更好了。** + +**技术原理探究，一定要看源码。看了源码与没看源码是有区别的。没看源码，虽然说得出来，但终是隔了一层纸；看了源码，才捅破了那层纸，有了自己的理解，也就能说得更加有底气了。当然，也可能是我缺乏演戏的本领。** + +我个人不太赞成刷题式面试。虽然刷题确实是进厂的捷径，但也有缺点： + +- 它依然是别人的知识体系，而不是自己总结的知识体系； +- 技术探究是为了未来的工作准备，而不是为了应对一时之需，否则即使进去了还是会处于麻痹状态。 + +经过系统的整理，我逐步形成了适合自己的技术体系结构：[“互联网应用服务端的常用技术思想与机制纲要”](https://www.cnblogs.com/lovesqcc/p/13633409.html) 。在这个基础上，再博采众长，看看面试题进行自测和查漏补缺，是更恰当的方式。我会在这个体系上深耕细作。 + +### 表述能力 + +目前，绝大多数企业的主要面试形式是通过口头沟通进行的，少部分企业可能有笔试或机试。口头沟通的形式是有其局限性的。对表述能力的要求比较高，而对专业能力的凸显并不明显。一个人掌握的专业和经验的深度和广度，很难通过几分钟的表述呈现出来。往往深度和广度越大，反而越难表述。而技术人员往往疏于表达。 + +我平时写得多说得少，说起来不利索。有时没讲清楚背景，就直接展开，兼之啰嗦、跳跃和回旋往复（这种方式可能更适合写小说），让面试官有时摸不着头脑。表述的条理性和清晰性也是很重要的。不妨自己测试一下：Dubbo 的架构设计是怎样的？ Redis 的持久化机制是怎样的？然后自己回答试试看。 + +表述能力的基本法则： + +- 先总后分，先整体后局部； +- 先说基本思路，然后说优化； +- 体现互动。先综述，然后向面试官询问要听哪方面，再分述。避免自己一脑瓜子倾倒出来，让面试官猝不及防；系统设计的场景题，多问一些要求，比如时间要求、空间要求、要支持多大数据量或并发量、是否要考虑某些情况等。 + +### 常见问题 + +面试是通过沟通来理解双方的过程。面试中的问题，千变万化，但有一些问题是需要提前准备好的。 + +比如“灵魂 N 问”： + +- 你为什么从 XXX 离职？ +- 你的期望薪资是多少？ +- 你有一段空档期，能解释下怎么回事么？ +- 你的职业规划是怎样的？ + +高频技术问题： + +- 基础：数据结构与算法、网络； +- 微服务：技术体系、组件、基础设施等； +- Dubbo：Dubbo 整体架构、扩展机制、服务暴露、引用、调用、优雅停机等； +- MySQL：索引与事务的实现原理、SQL 优化、分库分表； +- Redis : 数据结构、缓存、分布式锁、持久化机制、复制机制； +- 分布式：分布式事务、一致性问题； +- 消息中间件：原理、对比； +- 架构： 架构设计方法、架构经验、设计模式； +- 性能优化： JVM、GC、应用层面的性能优化； +- 并发基础：ConcurrentHashMap, AQS, CAS，线程池等； +- 高并发：IO 多路复用；缓存问题及方案； +- 稳定性：稳定性的思想及经验； +- 生产问题：工具及排查方法。 + +### 中高端职位 + +说起来，我这人可能有点不太自信。我是怀着“踏实做一个工程师”的思想投简历的。 + +对于大龄程序员，企业的期望更高。我的每一份“高级工程师”投递，自动被转换为“技术专家”或“架构师”。无力反驳，倍感压力。面试中高端职位，需要更多准备： + +- 你有带团队经历吗？ +- 在你 X 年的工作经历中，有多少时间用于架构设计？ +- 架构过程是怎样的？你有哪些架构设计思想或方法论？ + +如果不作准备，就被一下子问懵，乱了阵脚。实际上，我或许还是存着侥幸心理把“技术专家”和“架构师”岗位当做“高工”来面试的，也就无一不遭遇失败了。显然，我把次序弄反了：应当以“技术专家”和“架构师”的规格来面试高级工程师。 + +好吧，那就迎难而上吧！我不是惧怕挑战的人。 + +此外，“技术专家”和“架构师”职位应当至少留一天的时间来准备。已经有丰富经验的技术专家和架构师可以忽略。 + +### 好的心态 + +保持好的心态也尤为重要。我经历了“乐观-不自信-重拾信心”的心态变化过程。 + +很长一段时间，由于“求成心切”，生怕某个技术问题回答不上来搞砸，因此小心谨慎，略显紧张，结果已经梳理好的往往说不清楚或者说得不够有条理。冲着“拿 offer ”的心态去面试，真的很难受，会觉得每场面试都很被动那么难过，甚至有点想要“降格以求”。 + +有时，我在想：咋就混成这个样子了呢？按理来说，这个时候我应该有能力去追求自己喜爱的事业了啊！还是平时有点松懈了，视野狭窄，积累不够，导致今天的不利处境。 + +我是一个守时的人，也希望对方尽可能守时。杭州的面试官中，基本是守时的，即使迟到也在心理接受范围内，回武汉面试后，节奏就有点被少量企业带偏了。有一两次，我甚至不确定面试官什么时候进入会议。我想，难道这是人才应该受到的“礼待”吗？我有点被轻微冒犯的感觉了。不过我还是“很有涵养地”表示没事。但我始终觉得：面试官迟到，是对人才的不尊重。进入不尊重人才的公司，我是怀有疑虑的。良禽择木而栖，良臣择主而事。难道我能因为此刻的不利处境，而放弃一些基本的原则底线，而屈从于一份不尊重人才的 offer 吗？ + +我意识到：一个人应当用其实力去赢得对方的尊重和赏识，以后的合作才会更顺畅。不若，哪怕惜其无缘，亦不可强留。无论别人怎么存疑，心无旁骛地打磨实力，挖掘自己的才干和优势，终会发出自己的光芒。因此，我的心态顿时转变了：应当专注去沟通，与对方充分认识了解，赢得对方心服的认可，而不是拿到一张入门券，成为干活的工具。 + +有一个“石头和玉”的小故事，把自己当做人才，并努力去提升自己，才能获得“人才的礼遇”；把自己当石头贱卖，放松努力，也就只能得到“石头的礼遇”。尽管一个人不一定马上就具备人才的能力，但在自己的内心里，就应当从人才的视角去观察待入职的企业，而不仅仅是为了找一份“赚更多钱”的工作。 + +此外，焦虑也是不必要的。焦虑的实质是现实与目标的差距。一个人总可以评估目标的合理性及如何达成目标。如果目标过高，则适当调整目标级别；目标可行，则作出合理的决策，并通过持续的努力和恰当的出击来实现目标。决策、努力和出击能力都是可以持续修炼的。 + +## 面试历炼 + +技术人的面试还是更偏重于技术，因此，技术的深度和广度还是要好好准备的。面试官和候选人的处境是不一样的，一个面试官问的只是少量点，但是多个面试官合起来就是一个面。明白这一点，作为面试官的你就不要忘乎所以，以为自己就比候选人厉害。 + +我面的企业不多，因为我已经打算从事教育事业，用“志趣和驱动力”这项就直接过滤了很多企业的面试邀请。在杭州面试的基本是教育企业，连阿里华为等抛来的橄榄枝都婉拒了（尽管我也不一定能面上）。虽然做法有点“直男”，但投入最多精力于自己期望从事的行业和事业，才是值得的。 + +我所认为的教育事业，并不局限于现在常谈起的在线教育或 K12 教育，而是一个教育体系，任何可以更好滴起到教育效果的事业，包括而不限于教学、阅读、音乐、设计等。 + +### 接力棒科技-高工 + +面的第一家。畅谈一番后，没音讯了。但我也没有太在意。面试官问的比较偏交易业务性的东西，较深的就是如何保证应用的数据一致性了。 + +此时的我，就像在路上扔了一颗探路的小石子，尚未意识到自己的处境。 + +### 网易云音乐-高工 + +接着是网易云音乐。大厂就是大厂。一面问的尽是缓存、分布式锁、Dubbo、ZK， MQ 中间件相关的机制。很遗憾，由于我平时关于技术原理的沉淀还是很少，基本是“一问两不知”，挂得很出彩。 + +此时，我初步意识到自己的技术底子还很薄弱，也就开始了广阔的技术学习和夯实，自底向上地梳理原理和逻辑，系统地进行整理总结，最终初步形成了自己的互联网服务端技术知识体系结构。 + +### 铭师堂-技术专家 + +架构师面试的。问的相对多了一些，DB, Redis 等。反馈是技术还行，但缺乏管理经验。这是我第一次意识到大龄程序员缺乏管理经验的不利。中小企业的技术专家线招聘中，往往附加了管理经验的需求。应聘时要注意。 + +缺乏管理经验，该怎么办呢？思考过一段时间后，我的想法是： + +- 改变能改变的，不能改变的，学习它。比如技术原理的学习是我能够改变的，但管理经验属于难以一时改变的，那就多了解点管理的基本理论吧。 +- 从经历中挖掘相关经验。虽然我没有正式带团队的实际经验，但是有带项目和带工程师，管控某个业务线的基本管理经验。多多挖掘自己的经历。 + +### 字节教育-高工 + +字节教育面试，我给自己挖了不少坑往里跳。 + +比如面试官问，讲一个你比较成就感的项目经历。我选择的是近 4 年前的周期购项目。虽然这是我入职有赞的第一个有代表性的项目，但时间太久，又没有详细记录，很多技术细节遗忘不清晰了。我讲到当时印象比较深的“一体化”设计思想，却忘记了当时为什么会有这种思想（未做仔细记录）。 + +再比如，一个上课的场景题，我问是用 CS 架构还是 BS 架构？面试官说用 CS 架构吧。这不是给自己挖坑吗？明明自己不熟悉 CS 架构，何必问这个选择呢，不如直接按照 BS 架构来讲解。哎！ + +字节教育给我的反馈是：业务 Sense 不错，系统设计能力有待提高。我觉得还是比较中肯的。因此，也开始注重系统设计实战方面的文章阅读和思考训练。 + +经验是： + +- 做项目时，要详细记录每个项目的技术栈、技术决策及原因、技术细节，为面试做好铺垫； +- 提前准备好印象最深刻的最代表性的系统和项目，避免选择距离当前时间较久的缺乏详细记录的项目； +- 选择熟悉的项目和架构，至少有好的第一印象，不然给面试官的印象就是你啥都不会。 + +### 咪咕数媒-架构师 + +好家伙，一下子 3 位面试官群面。可能我以前经历的太少了吧。似乎国企面试较高端职位，喜欢采取这种形式。兼听则明偏听则暗嘛。问的问题也很广泛，从 ES 的基本原理，到机房的数据迁移。有些技术机制虽然学习过，但不牢固，不清晰，答的也不好。比如 ES 的搜索原理优化，讲过倒排索引后，我对 Term Index 和 Trie 树 讲不清楚。这说明，知道并不代表真正理解了。只有能够清晰有条理地把思路和细节都讲清楚，才算是真正理解了。 + +印象深刻的是，有一个问题：你有哪些架构思想？这是第一次被问到架构设计方面的东西，我顿时有点慌乱。虽然平时多有思考，也有写过文章，却没有形成系统精炼的方法论，结果就是答的比较凌乱。 + +### 涂鸦智能-高工 + +应聘涂鸦智能，是因为我觉得这家企业不错。优秀的企业至少应该多沟通一下，说不准以后有合作机会呢！看问题的思维要开阔一些，不能死守在自己想到的那一个事情上。 + +涂鸦智能给我的整体观感还是不错的。面试官也很有礼貌有耐心，整体架构、技术和项目都问了很多，问到了我熟悉的地方，答得也还可以。也许我的经验正好是切中他们的需求吧。 + +若不是当时想做教育的执念特别强，我很大概率会入职涂鸦智能。物联网在我看来应该是很有趣的领域。 + +### 跟谁学-技术专家 + +“跟谁学”基本能答上来。不过反馈是：对于提问抓重点的能力有所欠缺，对于技术的归纳整理也不够。我当时还有点不服气，认为自己写了那么多文章，也算是有不少思考，怎能算是总结不够呢？顶多是有技术盲点。技术犹如海洋，谁能没有盲点？ + +不过现在反观，确实距离自己应该有的程度不够。对技术原理机制和生产问题排查的总结不够，不够清晰细致；对设计实践的经验总结也不够，不够系统扎实。这个事情还要持续深入地去做。 + +此外，面得越多，越发现自己的表述能力确实有所欠缺。啰嗦、容易就一点展开说个没完、脱离背景直接说方案、跳跃、回旋往复，然后面试官很可能没耐心了。应该遵循“先总后分”、“基本思路-实现-优化”的一些基本逻辑来作答会更好一些。表述能力真的很重要，不可只顾着敲代码。还有每次面教育企业就不免紧张，生怕错过这个机会。 + +这是第二家直接告诉我年龄与经验不匹配的企业，加深了我对年龄偏大的忧虑，以致于开始有点不自信了。 + +那么我又是怎么重拾信心的呢？有一句老话：“留得青山在，不怕没柴烧”。就算我年龄比较大，如果我的技术能力打磨得足够硬朗，就不信找不到一家能够认可我的企业。大不了我去做开源项目好了。具备好的技术能力，并不一定就局限在企业的范围内去发挥作用，也没必要局限于那些被年龄偏见所蒙蔽的人的认知里。外界的认可固然重要，内在的可贵性却远胜于外在。 + +### 亿童文教-架构师 + +也是采用的 3 人同时面试。主要问的是项目经历，技术方面问得倒不是深入。个人觉得答得还行。面试官也问了架构设计相关的问题，我答得一般。此时，我仍然没有意识到自己在以面“高级工程师”的规格来面试“架构师”岗位。 + +面试官比较温和，HR 也在积极联系和沟通，感觉还不错。只是，我没有主动去问反馈意见，也就没有下文了。 + +### 新东方-高工 + +面试新东方，主要是因为切中我做教育的期望，虽然职位需求是做信息管理系统，距离我理想中的业务还有一定距离。经过沟通了解，他们更需要的是对运维方面更熟悉的工程师，不过我正好对运维方面不太熟悉，平时关注不多，因此不太符合他们的真实招聘要求。面试官也是很温和的人，老家在宜昌，是我本科上大学的地方，面试体验不错。 + +以后要花些时间学习一些运维相关的东西。作为一名优秀的工程师和合格的架构师，是要广泛学习和熟悉系统所采用的各种组件、中间件、运维部署等的。要有综观能力，不过我醒悟的可能有点迟。Better later than never. + +### ZOOM-高工 + +ZOOM 的一位面试官或许是我见过的所有面试官中最差劲的。共有两位面试官，一位显得很有耐心，另一位则挺着胖胖的肚子，还打着哈欠，一副不怎么关心面试和候选人的样子。我心想，你要不想面，为啥还要来面呢？你以为候选人就低你一等么？换个位置我可以暴打你。不过我还是很有礼貌的，当做什么事也没发生。公司在挑人，候选人也在挑选公司。 + +想想，ZOOM 还是疫情期间我们公司用过的远程通信会议软件。印象还不错，有这样的工程师和面试官藏于其中，我也是服了。难倒他是传说中的大大神？据我所知，国外对国内的互联网软件技术设施基本呈碾压态势，中国大部分企业所用的框架、中间件、基础设施等基本是拿国外的来用或者做定制化，真正有自研的很少，有什么好自满的呢？ + +### 阿优文化-高工 + +阿优文化有四轮技术面。其中第一个技术面给我印象比较深刻。看上去，面试官对操作系统的原理机制特别擅长和熟悉。很多问题我都没答上来。本以为挂了，不过又给了扳回一局的机会。第二位面试问的项目经历和技术问题是我很熟悉的。第三位面试官问的比较广泛，有答的上来的，有答不上来的。不过面试官很耐心。第四位是技术总监，也问得很广泛细致。 + +整体来说，面试氛围还是很宽松的。不过，阿优当时的招聘需求并不强烈，估计是希望后续有机会时再联系我。可惜我那时准备回武汉了。主要是考虑父母年事已高，希望能多陪陪父母。 + +想想，我想问题做决策还是过于简单的，不会做很复杂的计算和权衡。 + +### 小米-专家/架构 + +应聘小米，主要是因为职位与之前在有赞做的很相似，都是做交易中台相关。浏览小米官网之后，觉得他们做的事情很棒，可是与我想做教育文化事业的初衷不太贴合。 + +加入小米的意愿不太强烈，面试也就失去了大半动力。我这个性子还是要改一改。 + +### 视觉中国-高工 + +围绕技术、项目和经历来问。总体来说，技术深度并不是太难，项目方面也涉及到了。人力面前辈很温和，我以为会针对自己的经历进行一番“轰炸”，结果是为前辈讲了讲有赞的产品服务和生意模式，然后略略带了下自己的一些经历。 + +### 科大讯飞-架构师 + +一二面，感觉面试官对安排的面试不太感兴趣。架构师，至少是一个对技术和设计能力非常高要求的职位。一面的技术和架构都问了些，二面总围绕我的背景和非技术相关的东西问，似乎对我的外在更关注，而对我自身的技术和设计能力不感兴趣。交流偏浅。 + +能力固然有高下之分，但尊重人才的基本礼节却是不变的。尊重人才，是指聚焦人才的能力和才学，而不是一些与才学不甚相关的东西。 + +### 青藤云-高工 + +青藤云的技术面试风格是温和的。感受到坦率交流的味道，被认可的感觉。感受到 HR 求才若渴的心情。和我之前认为的“应当用其实力去赢得对方的尊重和赏识”不谋而合。 + +### 腾讯会议-高工 + +和腾讯面试官是用腾讯会议软件面试腾讯会议的职位。哈哈。由于网络不太稳定，面试过程充满了磕磕碰碰，一句话没说完整就听不清楚了。可想情况如何。但是我们都很有很有很有耐心，最终一起完成了一面。面试是双方智慧与力量的较量，更是双方一起去完成一件事情、发现彼此的合作。这样想来，传统的“单方考验筛选式”的面试观念需要革新。 + +由于我已经拿到 offer , 且腾讯会议的事情并不太贴合自己的初衷，因此，我与腾讯方面沟通，停止了二面。 + +### 最终选择 + +当拿到多个 offer 时，如何选择呢？我个人主要看重： + +1. 志趣与驱动力； +2. 薪资待遇； +3. 公司发展前景和个人发展空间； +4. 工作氛围； +5. 小而有战斗力的企业。 + +在视觉中国与青藤云之间如何选择？作个对比： + +- 薪资待遇：两者的薪资待遇不相上下，也都是认可我的；视觉中国给出的是 Leader 的职位，而青藤云给出的是核心业务的承诺； +- 工作氛围：青藤云应该更偏工程师文化氛围，而视觉中国更偏业务化； +- 挑战性：青藤云的技术挑战更强，而视觉中国的业务挑战性更强； +- 志趣与驱动力：视觉中国更符合我想做文化的事情，而青藤云安全并不贴合我想做教育文化事业的初衷，而且比较偏技术和底层（我更希望做一些人文性的事情）。但青藤云做的是关于安全的事情，安全是一件很有价值很有意义的事情。而且，以后安全也可以服务于教育行业。有点曲线救国的味道。尤其是创始人张福的理想主义信念“让安全之光照亮互联网的每个角落”及自己的身体力行，让人更有一些触动。最终，我觉得做安全比做图片版权保护稍胜出一小筹。 + +此外，我觉得做教育，更适合自己的是编程教育，或者是工程师教育。我还想成为一名系统设计师。还需要积累更多生产实践经验。可以多与初中级工程师打交道，在企业内部做培训指导。或者工作之余录制视频，上传到 B 站，服务广大吃瓜群众。将来，我或许还会写一本关于编程设计的书，汇聚毕生所学。 + +因此，经过一天慎重的考虑，我决定，加入青藤云安全。当然，做这个选择的同时，也意味着我选择了一个更大的挑战：在安全方面我基本一穷二白，需要学习很多很多的知识和经验，对于我这个大龄程序员来说，是一项不小的挑战。 + +## 小结 + +很多事情都有解决的方法，即使“头疼的”大龄程序员找工作也不例外。确立明确清晰的目标、制定科学合理的决策、持续的努力、掌握基本面、恰当的出击，终能斩获胜利的果实。但要强调一下：功夫在平时。平时要是不累积好，面试的时候就要花更多时间去学习，会受挫、磕磕碰碰、过得也不太舒坦。还是平摊到平时比较好。此外，平时视野也要保持开阔，切忌在面试的时候才“幡然醒悟”。 + +一个重要经验是，要善于从失败中学习。正是在杭州四个月空档期的持续学习、思考、积累和提炼，以及面试失败的反思、不断调整对策、完善准备、改善原有的短板，采取更为合理的方式，才在回武汉的短短两个周内拿到比较满意的 offer 。 + +此外，值得提及的是，对于技术人员，写博客是一件很有价值的事情。面试通过沟通去了解对方，有其局限性所在。面试未能筛选出符合的人才其实是有比较大概率的： + +1. 面试的时间很短，即使是很有经验的面试官，也会看走眼（根本局限性）； +2. 面试官问到的正好是自己不会的（运气问题）； +3. 面试官情绪不好，没兴趣（运气问题）； +4. 面试官自身的水平。 + +因此，具备真才实学而被 PASS 掉，并不值得伤心。写博客的意义在于，有更多展示自己思考和平时工作的维度。 + +尊重人才的企业，一定是希望从多方面去认识候选人（在优点和缺点之间选择确认是否符合期望），包括博客；不尊重人才的企业，则会倾向于用偷懒的方法，对候选人真实的本领不在意，用一些外在的标准去快速过滤，固然高效，最终对人才的识别能力并不会有多大进步。 + +经过这一段面试的历炼，我觉得现在相比离职时的自己，又有了不少进步的。不说脱胎换骨，至少也是蜕了一层皮吧。差距，差距还是有的。起码面试那些知名大厂企业的技术专家和架构师还有差距。这与我平时工作的挑战性、认知视野的局限性及总结不足有关。下一次，我希望积蓄足够实力做到更好，和内心热爱的有价值有意义的事情再近一些些。 + +面试，其实也是一段工作经历。 \ No newline at end of file diff --git a/docs/high-quality-technical-articles/personal-experience/8-years-programmer-work-summary.md b/docs/high-quality-technical-articles/personal-experience/8-years-programmer-work-summary.md new file mode 100644 index 0000000000000000000000000000000000000000..3209bfa7ee8ca0139106faee2ab993e9ccd9e412 --- /dev/null +++ b/docs/high-quality-technical-articles/personal-experience/8-years-programmer-work-summary.md @@ -0,0 +1,239 @@ +--- +title: 一个中科大差生的 8 年程序员工作总结 +category: 技术文章精选集 +tag: + - 个人经历 +--- + +> **《一个中科大差生的 8 年程序员工作总结》** 这篇文章是我上上个星期发现的一篇好文，我刚刚才把它看完。 +> +> 说实话，我对别人的经历还是非常感兴趣的。高中、大学那会，看过了很多人的传记。 +> +> 这篇文章讲述了一位中科大的朋友 8 年的经历：**从 2013 年毕业之后加入上海航天 x 院某卫星研究所，再到入职华为，从华为离职。** +> +> 除了丰富的经历之外，作者在文章还给出了很多自己对于工作/生活的思考。我觉得非常受用！我在这里，向这位作者表达一下衷心的感谢。 +> +> 我对这篇文章进行了重新排版，在这里分享一下（已经通过微信联系原作者申请了转载权限）！ +> +> **原文地址** ：https://www.cnblogs.com/scada/p/14259332.html + +------ + +## 前言 + +今年终于从大菊花厂离职了，离职前收入大概 60w 不到吧！在某乎属于比较差的，今天终于有空写一下自己的职场故事，也算是给自己近 8 年的程序员工作做个总结复盘。 + +近 8 年有些事情做对了，也有更多事情做错了，在这里记录一下，希望能够给后人一些帮助吧，也欢迎私信交流。文笔不好，见谅，有些细节记不清了，如果有出入，就当是我编的这个故事吧。 + +*PS：有几个问题先在这里解释一下，评论就不一一回复了* + +1. 关于差生，我本人在科大时确实成绩偏下，差生主要讲这一点，没其他意思。 +2. 因为买房是我人生中的大事，我认为需要记录和总结一下，本文中会有买房，房价之类的信息出现，您如果对房价，炒房等反感的话，请您停止阅读，并且我再这里为浪费您的时间先道个歉。 + +## 2013 年 + +### 加入上海航天 x 院某卫星研究所 + +本人 86 年生人，13 年从中科大软件相关专业毕业，由于父母均是老师，从小接受的教育就是努力学习，找个稳定的“好工作”，报效国家。 + +于是乎，毕业时候头脑一热加入了上海航天 x 院某卫星研究所，没有经过自己认真思考，仅仅听从父母意见，就草率的决定了自己的第一份工作，这也为我 5 年后离职埋下了隐患。这里总结第一条经验： + +**如果你的亲人是普通阶层，那对于人生中一些大事来说，他们给的建议往往就是普通阶层的思维，他们的阶层就是他们一生思维决策的结果，如果你的目标是跳出本阶层，那最好只把他们的建议当成参考。** + +13 年 4 月份，我坐上火车来到上海，在一路换乘地铁来到了大闵行，出了地铁走路到单位，一路上建筑都比较老旧，我心里想这跟老家也没什么区别嘛，还大上海呢。 + +到达单位报道，负责报道的老师很亲切，填写完资料，分配了一间宿舍，还给了大概 3k 左右安家费，当时我心里那个激动啊（乡下孩子没有见过钱啊，见谅），拿了安家费，在附近小超市买好生活用品，这样我就开始了自己航天生涯。 + +经过 1 个月集中培训后，我分配到部门，主要负责卫星上嵌入式软件开发。不过说是高大上的卫星软件开发，其实刚开始就是打杂，给实验室、厂房推箱子搬设备，呵呵，说航天是个体力活相信很多航天人都有同感吧。不过当时年轻，心思很单纯，每天搬完设备，晚上主动加班，看文档材料，画软件流程图，编程练习，日子过得很充实。 + +记得第一个月到手大概 5k 左右（好少呀），当时很多一起入职的同事抱怨，我没有，我甚至不太愿意和他们比较工资，这里总结第二条经验： + +**不要和你的同事比工资，没有意义，比工资总会有人受伤，更多的是负面影响，并且很多时候受伤的会是你。** + +### 工作中暂露头角 + +工作大概一个月的时候，我遇到了一件事情，让我从新员工里面开始暂露头角。事情是这样的当时国家要对军工单位进行 GJB5000A 软件开发等级认证（搞过这个认证的同学应该都知道，过这个认证那是要多酸爽有多酸爽），但是当时一个负责配置管理的同事却提出离职，原因是他考上了公务员，当时我们用的那个软件平台后台的版本控制是 SVN 实现的，恰好我在学校写程序时用过，呵呵，话说回来现在学生自己写软件很少有人会在本地搭版本控制器吧！我记得当时还被同学嘲笑过，这让我想起了乔布斯学习美术字的故事，这里总结一下： + +**不要说一项技能没有用，任何你掌握的技能都有价值，但是你要学会找到发挥它的场景。如果有一天你落水了，你可能会很庆幸，自己以前学会了游泳。** + +**工作中如果要上升，你要勇于承担麻烦的、有挑战的任务，当你推掉麻烦的时候，你也推掉了机遇。** + +好了，扯远了，回到前面，当时我主动跟单位认证负责人提出，我可以帮忙负责这方面的工作，我有一定经验。这里要提一下这个负责人，是位女士，她是我非常敬佩的一个前辈，认真，负责，无私，整个人为国家的航天事业奉献了几十年，其实航天领域有非常多这样的老前辈，他们默默奋斗，拿着不高的薪水，为祖国的国防建设做出了巨大的贡献。当时这位负责人，看我平时工作认真积极，思维反应也比较灵活（因为过认证需要和认证专家现场答辩的）就同意了我的请求，接受到这个任务之后，我迅速投入，学习认证流程、体系文件、迅速掌握认证工作要点，一点一点把相关的工作做好，同时周期性对业务进行复盘，总结复盘可能是我自己的一个优点： + +**很多人喜欢不停的做事，但不会停下来思考，缺乏总结复盘的能力，其实阶段性总结复盘，不仅能够固化前面的经验，也能梳理后面的方向；把事情做对很重要，但是更重要的是做对的事；另外不要贪快，方向正确慢就是快**(后半句是我后来才想明白的，如果早想明白，就不会混成目前这样了） + +1 个月后，当时有惊无险通过了当年的认证，当时负责人主动向单位申请了 2k 特别奖，当时我真的非常高兴，主要是自己的工作产生了价值，得到了认可。后来几个月的日子平淡无奇，有印象的好像只有两件事情。 + +一件事情是当年端午，当时我们在单位的宿舍休息，突然楼道上一阵骚动，我打开宿舍门一看，原来是书记来慰问，还给每个人送了一箱消暑饮料，这件事印象比较深刻，是我觉得国企虽然有各种各样的问题，但是论人文关怀，还是国企要好得多。 + +### 错失一次暴富的机会 + +另一件事是当年室友刚买房，然后天天研究生财&之道，一会劝我买房，一会劝我买比&特&币，我当时没有鸟他，为什么呢，因为当时的室友生活习惯不太好，会躺在床上抽烟，还在宿舍内做饭(我们宿舍是那种很老的单位房，通风不好），我有鼻炎，所以不是很喜欢他（嗯，这里要向室友道歉，当年真是太幼稚了）。现在 B&T&C4 万美元了，我当时要是听了室友也能小发一笔了（其实我后来 18 年买了，但是没有拿住这是后话），这里要总结一下： + +**不要因为某人的外在，如外貌、习惯、学历等对人贴上标签，去盲目否定别人，对于别人的建议，应该从客观出发，综合分析，从善如流是一项非常难得的品质。** + +**人很难挣到他认知之外的财富，就算偶然拿到了，也可能很快失去。所以不要羡慕别人投机获得的财富，努力提升你的思维，财商才是正道。** + +### 航天生涯的第一个正式项目 + +转眼到了 9 月份（我 4 月份入职的），我迎来了我航天生涯第一个正式的型号项目（型号，是军工的术语，就相当于某个产品系列比如华为的 mate）,当时分配给我的型号正式启动，我终于可以开始写卫星上的代码了。 + +当时真的是心无旁骛，一心投身军工码农事业，每天实验室，测试厂房，评审会，日子虽然忙碌，但是也算充实。并且由于我的努力工作，加上还算可以的技术水平，我很快就能独立胜任一些型号基础性的工作了，并且我的努力也受到了型号（产品）线的领导的认可，他们开始计划让我担任型号主管设计师，这是一般工作 1-2 年的员工的岗位，当时还是有的激动的。 + +## 2014 年 + +### 升任主管设计师后的一次波折 + +转眼间到 2014 年了，大概上半年吧，我正式升任主管设计师，研发工作上也开时独挡一面了，但是没多久产品研发就给了我当头一棒。 + +事情是这样的，当时有一个版本软件编写完毕，加载到整星上进行测试，有一天大领导来检查，当时非常巧，领导来时测试主岗按某个岗位的人员要求，发送了一串平时整星没有使用的命令（我在实验室是验证过的），结果我的软件立刻崩溃，无法运行。由于正好领导视察，这个问题立马被上报到质量处，于是我开始了苦逼的技术归零攻关（搞航天的都懂，我就不解释了）。 + +期间每天都有 3 个以上领导，询问进度，当时作为新人的我压力可想而知，可是我无论如何都查不出来问题，在实验室我的软件完全正常！后来，某天中午我突然想到，整星上可能有不同的环境，具体过程就不说了。后人查出来是一个负责加载我软件的第三方软件没有受控，非法篡改了我程序的 4 个字节，而这 4 字节正好是那天发送命令才会执行的代码，结果导致我的软件崩溃。最后我花了进一个月完成了所有质量归零报告，技术分析报告，当然负责技术的领导没有责怪，相反的还更加看重我了，后来我每遇到一个质量问题，无论多忙最后定要写一份总结分析报告，这成了我一个技术习惯，也为后来我升任软件开发组长奠定了技术影响基础。 + +**强烈建议技术团队定期开展质量回溯，需要文档化，还要当面讲解，深入的技术回溯有助于增加团队技术交流活跃度，同时提升团队技术积淀，是提升产品质量，打造优秀团队的有效方法。** + +**个人的话建议养成写技术总结文章的习惯，这不仅能提升个人技术，同时分享也可以增加你的影响力** + +### 职场软技能的重新认识 + +上半年就在忙碌中度过了，到了年底，发生了一件对我们组影响很大的事情，年底单位开展优秀小组评比， 其实这个很多公司都有，那为什么说对我们组影响很大内，这里我先卖关子。这里先不得不提一个人，是个女孩子，南京大学的，比我晚来一年，她做事积极，反应灵敏，还做得一手不错的 PPT，非常优秀，就是黑了点（希望她看到了不要来找我，呵呵）。 + +当时单位开展优秀小组评比，我们当时是新员工，什么都很新鲜，就想参加一下，当时领导说我们每年都参加的，我们问，我们每年做不少东西，怎么没有看到过评比的奖状，领导有点不好意思，说我们没有进过决赛。我们又问，多少名可以进入决赛圈，答曰前 27 名即可（总共好像 50+个组）我们当时心里真是一万个羊驼跑过。。。。 + +其实当时我们组每年是做不少事情的，我们觉得我们不应该排名如此之低，于是我们几个年轻人开始策划，先是对我们的办公室彻底改造(因为要现场先打分，然后进决赛），然后好好梳理了我们当年取得的成绩，现场评比时我自告奋勇进行答辩（我沟通表达能力还不错，这也算我一个优势吧），后面在加上前文提到的女孩子做的漂亮 PPT，最后我们组拿到了铜牌班组的好成绩，我也因为这次答辩的优秀表现在领导那里又得到了认可，写了大半段了，再总结一下： + +**职场软技能如自我展示很重要，特别是程序员，往往在这方面是个弱项，如果可以的话，可以通过练习，培训强化一下这些软技能，对职场的中后期非常有帮助。** + +## 2015 年 + +时间总是过得很快，一下就到 2015 年了，这一年发生了一件对我影响很大的事情。 + +### 升任小组副组长 + +当时我们小组有 18 个人了，有一天部门开会，主任要求大家匿名投票选副组长（当时部门领导还是很民主的），因为日常事务逐渐增多，老组长精力有限，想把一些事物分担出来，当天选举结果就出来了，我由于前面的技术积累和沟通表达能力的展现，居然升任副组长，当时即有些意外，因为总是有传言说国企没背景一辈子就是最最底层，后来我仔细思考过，下面是我不成熟的想法： + +**不要总觉得国企事业单位的人都是拼背景，拼关系，我承认存在关系户，但是不要把关系户和低能力挂钩，背景只是一个放大器，当关系户做出了成绩时它会正面放大影响，当关系户做了不光彩的事情是，它也会让影响更坏。没有背景，你可以作出更大的贡献来达到自己的目标，你奋斗的过程是更大的财富。另外，我遇到的关系户能力都很强，也可能是巧合，也可能是他们的父辈给给他们在经验层次上比我们更优秀的教育。** + +### 学习团队管理技巧 + +升任副组长后，我的工作更加忙碌了，不仅要做自己项目的事情，还要横向管理和协调组内其他项目的事情，有人说要多体谅军工单位的基层班组长，这话真是没错啊。这个时候我开始学习一些管理技巧，如何凝聚团队，如何统一协调资源等等，这段时间我还是在不断成长。不过记得当年还是犯了一个很大的方向性错误，虽然更多的原因可能归结为体制吧，但是当时其实可以在力所能及的范围内做一些事情的。 + +具体是这样的，当时管理上有项目线，有行政线，就是很常见的矩阵式管理体系，不过在这个特殊的体制下面出现了一些问题。当时部门一把手被上级强制要求不得挂名某个型号，因为他要负责部门资源调配，而下面的我们每个人都归属 1-2 个型号（项目），在更高层的管理上又有横向的行政线（不归属型号），又有纵向的型号管理线。 + +而型号的任务往往是第一线的，因为产品还是第一位的，但是个人的绩效、升迁又归属行政线管理，这种形式在能够高效沟通的民企或者外企一般来说不是问题，但是在沟通效率缓慢，还有其他掣肘因素的国企最终导致组内每个人忙于自身的型号任务，各自单打独斗，无法聚焦，一年忙到头最终却得不到部门认可，我也因为要两面管理疲于应付，后来曾经反思过，其实可以聚焦精力打造通用平台（虽然这在我们行业很难）部分解决这个问题： + +**无论个人还是团队，做事情要聚焦，因为个人和团队资源永远都是有限的，如果集中一个事情都做不好，那分散就更难以成功，但是在聚焦之前要深入思考，往什么方向聚焦才是正确的，只有持续做正确的事情才是最重要的。** + +## 2016 年 + +这一年是我人生的关键一年，发生了很多事情。 + +### 升任小组副组长 + +第一件事情是我正式升任组长，由于副组长的工作经验，在组长的岗位上也做得比较顺利，在保证研发工作的同时，继续带领团队连续获得铜牌以上班组奖励，另外各种认证检查都稳稳当通过，但是就在这个时候，因为年轻，我犯下了一个至今非常后悔的错误。 + +大概是这样的，我们部门当时有两个大组，一个是我们的软件研发组，一个是负责系统设计的系统分析组。 + +当时两个组的工作界面是系统组下发软件任务书给软件组，软件组依照任务书开发，当时由于历史原因，软件组有不少 10 年以上的老员工，而系统组由于新成立由很多员工工作时间不到 2 年，不知道从什么时候起，也不知道是从哪位人员开始，软件组的不少同事认为自己是给系统组打工的。并且，由于系统组同事工作年限较短，实际设计经验不足，任务书中难免出现遗漏，从而导致实际产品出错，两组同事矛盾不断加深。 + +最后，出现了一个爆发：当时系统组主推一项新的平台，虽然这个平台得到了行政线的支持，但是由于军工产品迭代严谨，这个新平台当时没有型号愿意使用，同时平台的部分负责人，居然没有完整的型号经验！由于这个新平台的软件需要软件组实现，但是因为已经形成的偏见，软件同事认为这项工作中自己是为利益既得者打工。 + +我当时也因为即负责实际软件开发，又负责部分行政事务，并且年轻思想不成熟，也持有类似的思想。过程中的摩擦、冲突就不说了，最后的结果是系统组、软件组多人辞职，系统组组长离职，部门主任离职创业（当然他们辞职不全是这个原因，包括我离职也不全是这个原因，但是我相信这件事情有一定的影响），这件事情我非常后悔，后来反思过其实当时自己应该站出来，协调两组矛盾，全力支持部门技术升级，可能最终就不会有那么多优秀的同事离开了。 + +**公司战略的转型，技术的升级迭代，一定会伴随着阵痛，作为基层组织者，应该摒弃个人偏见，带领团队配合部门、公司主战略，主战略的成功才是团队成功的前提。** + +### 买房 + +16 年我第二件大事情就是买房，关注过近几年房价的人都可能还记得，16 年一线城市猛涨的情景。其实当时 15 年底，上海市中心和学区房已经开始上涨，我 15 年底听同事开始讨论上涨的房价，我心里开始有了买房的打算，大约 16 春节（2 月份吧，具体记不得了），我回老家探望父母，同时跟他们提出了买房的打算。 + +我的父亲是一个“央视新闻爱好者”，爱好看狼咸平，XX 刀，XX 檀的节目，大家懂了吧，父亲说上海房价太高了，都是泡沫，不要买。这个时候我已经不是菜鸟了，我想起我总结的第一条经验（见上文），我开始收集往年的房价数据，中央历年的房价政策，在复盘 15 年的经济政策时我发现，当年有 5 次降息降准，提升公积金贷款额度，放松贷款要求于是我判定房价一定会继续涨，涨到一个幅度各地才会出台各种限购政策，并且房价在城市中是按内环往外涨的于是我开始第一次在人生大事上反对父母，我坚决表态要买房。父亲还是不太同意，他说年底吧，先看看情况（实际是年底母亲的退休公积金可以拿出来大概十几万吧，另外未来丈母娘的公积金也能拿出来了大概比这多些）。我还是不同意，父亲最终拗不过我，终于松口，于是我们拿着双方家庭凑的 50w 现金开始买房，后来上海的房价大家都看到了。这件事也是我做的不多的正确的事情之一。 + +但是最可笑的是，我研究房价的同时居然犯下了一个匪夷所思的错误，我居然没有研究买房子最重要的因素是什么，我们当时一心想买一手房（现在想想真是脑子进水），最后买了一套松江区交通不便的房子，这第一套房子的地理位置也为我后来第二次离职埋下了隐患，这个后面会说。 + +**一线或者准一线城市能买尽量买，不要听信房产崩溃论，如果买不起，那可以在有潜力的城市群里用父母的名义先买一套，毕竟大多数人的财富其实是涨不过通货膨胀的。另外买房最重要的三个要素是，地段，地段，地段。** + +买房的那天上午和女朋友领的证，话说当时居然把身份证写错了三次 。。。 + +这下我终于算是有个家了，交完首付那个时候身上真的是身无分文了。航天的基层员工的收入真的是不高，我记得我当时作为组长，每月到手大概也就 7k-8k 的样子，另外有少量的奖金，但是总数仍然不高，好在公积金比较多，我日常也没什么消费欲望，房贷到是压力不大。 + +买完房子之后，我心里想，这下真的是把双方家庭都掏空了（我们双方家庭都比较普通，我的收入也在知乎垫底，没办法）万一有个意外怎么办，我思来想去，于是在我下一个月发工资之后，做了一个我至今也不知道是对是错的举动，我利用当月的工资，给全家人家人买了保险保险，各种重疾，意外都配好了。但是为什么我至今也不知道对错呢，因为后来老丈人，我母亲都遭遇病魔，但是两次保险公司都拒赔，找出的理由我真是哑口无言，谁叫我近视呢。另外真的是要感谢国家，亲人重病之后，最终还是走了医保，赔偿了部分，不然真的是一笔不小的负担。 + +## 2017 年 + +对我人生重大影响的 2016 年，在历史的长河中终究连浪花都激不起来。历史长河静静流淌到了 2017 年，这一年我参加了中国深空探测项目，当然后面我没有等到天问一号发射就离开了航天，但是有时候仰望星空的时候，想想我的代码正在遥远的星空发挥作用，心里也挺感慨的，我也算是重大历史的参与者了，呵呵。好了不说工作了，平淡无奇的 2017 年，对我来说也发生了两件大事。 + +### 买了第二套房子 + +第一件事是我买了第二套房子，说来可笑，当年第一套房子都是掏空家里，这第二年就买了第二套房子，生活真的是难以捉摸。到 2017 年时，前文说道，我母亲和丈母娘先后退休，公积金提取出来了，然后在双方家里各自办了酒席，酒席之后，双方父母都把所有礼金给了我们，父母对自己的孩子真的是无私之至。当时我们除了月光之外，其实没有什么外债，就是生活简单点。拿到这笔钱后，我们就在想如何使用，一天我在菜市场买菜，有人给我一张 xuanchuan 页，本来对于这样的 xuanchuan 页我一般是直接扔掉的，但是当天鬼死神差我看了一眼，只见上面写着“嘉善高铁房，紧邻上海 1.5w”我当时就石化了，我记得去年我研究上海房价的时候，曾经在网站上看到过嘉善的房价，我清楚的记得是 5-6k，我突然意识到我是不是错过了什么机会，反思一下： + +**工作生活中尽量保持好奇心，不要对什么的持怀疑态度，很多机会就隐藏在不起眼的细节中，比如二十年前有人告诉你未来可以在网上购物，有人告诉你未来可以用手机支付，你先别把他直接归为骗子，静下来想一想，凡事要有好奇心，但是要有自己的判断。** + +于是我立马飞奔回家，开始分析，大城市周边的房价。我分析了昆山，燕郊，东莞，我发现燕郊极其特殊，几乎没有产业，纯粹是承接大城市人口溢出，因此房价成高度波动。而昆山和东莞，由于自身有产业支撑，又紧邻大城市，因此房价稳定上涨。我和妻子一商量，开始了外地看房之旅，后来我们去了嘉善，觉得没有产业支撑，昆山限购，我们又到嘉兴看房，我发现嘉兴房价也涨了很多，但是这里购房的大多数新房，都是上海购房者，入住率比较低，很多都是打算买给父母住的，但是实际情况是父母几乎不在里面住，我觉得这里买房不妥，存在一个变现的问题。于是我开始继续寻找，一天我看着杭州湾的地图，突然想到，杭州湾北侧不行，那南侧呢？南侧绍兴，宁波经济不是更达吗。于是我们目光投向绍兴，看了一个月后，最后在绍兴紧贴杭州的一个区，购买了一套小房子，后来 17 年房价果然如我预料的那样完成中心城市的上涨之后开始带动三四线城市上涨。后来国家出台了大湾区政策，我对我的小房子更有信心了。这里稍微总结一下我个人不成熟的看法： + +**在稳定通胀的时代，负债其实是一种财富。长三角城市群会未来强于珠港澳，因为香港和澳门和深圳存在竞争关系，而长三角城市间更多的是互补，未来我们看澳门可能就跟看一个中等省会城市一样了。** + +### 准备要孩子 + +2017 年的第二件事是，我们终于准备要孩子了，但是妻子怎么也备孕不成功，我们开始频繁的去医院，从 10 元挂号费的普通门诊，看到 200 元，300 元挂号费的专家门诊，看到 600 元的特需门诊，从综合医院看到妇幼医院，从西医看到中医，每个周末不是在医院排队，就是在去医院的路上。最后的诊疗结果是有一定的希望，但是有困难，得到消息时我真的感觉眼前一片黑暗，这种从来在新闻上才能看到了事情居然落到了我们头上，我们甚至开始接触地下 XX 市场。同时越来越高的医疗开销（专家门诊以上就不能报销了）也开始成为了我的负担，前文说了，我收入一直不高，又还贷款，又支付医疗开支渐渐的开始捉襟见肘，我甚至动了卖小房子的打算。 + +## 2018 年 + +前面说到，2017 年开始频繁出入医院，同时项目也越来越忙，我渐渐的开始喘不过气起来，最后医生也给了结论，需要做手术，手术有不小的失败的几率。我和妻子商量后一咬牙做吧，如果失败就走地下的路子，但是可能需要准备一笔钱（手术如果成功倒是花销不会太大），哎，古人说一分钱难倒英雄汉，真是诚不欺我啊，这个时候我已经开始萌生离职的想法了。怎么办呢，生活还是要继续，我想起了经常来单位办理贷款的银行人员，贷款吧，这种事情保险公司肯定不赔的嘛，于是我办理了一笔贷款，准备应急。 + +### 项目结束，离职 + +时间慢慢的时间走到了 8 月份，我的项目已经告一定段落，一颗卫星圆满发射成功，深空项目也通过了初样阶段我的第一份工作也算有始有终了。我开始在网上投递简历，我技术还算可以，沟通交流也不错，面试很顺利，一个月就拿到了 6 个 offer，其中就有大菊花厂的 offer，定级 16A，25k 月薪后来政策改革加了绩效工资 6k(其实我定级和总薪水还是有些偏低了和我是国企，本来总薪水就低有很大关系，话说菊花厂级别后面真的是注水严重，博士入职轻松 17 级)菊花厂的 offer 审批流程是我见过最长，我当时的接口人天天催于流程都走了近 2 个月。我向领导提出了离职，离职的过程很痛苦，有过经历的人估计都知道，这里就不说了。话说我为什么会选择华为呢，一是当时急需钱，二是总觉得搞嵌入式的不到华为看看真的是人生遗憾。现在想想没有认真去理解公司的企业文化就进入一家公司还是太草率了： + +**如果你不认同一个公司的企业文化，你大概率干不长，干不到中高层，IT 人你不及时突破到中高层很快你就会面临非常多问题；公司招人主要有两种人，一种是合格的人，一种是合适的人，合格的人是指技能合格，合适的人是指认同文化。企业招人就是先把合格的人找进来，然后通过日日宣讲，潜移默化把不合适的人淘汰掉。** + +### 入职华为 + +经过一阵折腾终于离职成功，开始入职华为。离职我做了一件比较疯狂的事情，当时因为手上有一笔现金了，一直在支付利息，心里就像拿它干点啥。那时由于看病，接触了地下 XX 市场，听说了 B&TC，走之前我心一横买 B&T&C，后来不断波动，最终我还是卖了，挣了一些钱，但是最终没有拿到现在，果然是考验人性啊。 + +## 2019 年 + +### 成功转正 + +华为的试用期真长，整整 6 个月，每个月还有流程跟踪，交流访谈，终于我转正了，转正答辩我不出意料拿到了 Excellent 评价，涨了点薪水，呵呵还不错。华为的事情我不太想说太多，总之我觉得自己没有资格评判这个公司，从公司看公司的角度华为真正是个伟大的公司，任老爷子也是一个值得敬佩的企业家。 + +在华为干了半年后，我发现我终究还是入职的时候太草率了，我当时没有具体的了解这个岗位，这个部门。入职之后我发现，**我所在的是硬件部门，我在一个硬件部门的软件组，我真是脑子秀逗了**。 + +**在一个部门，你需要尽力进入到部门主航道里，尽力不要在边缘的航道工作，特别是那些节奏快，考核严格的部门。** + +更严峻的是我所在的大组，居然是一个分布在全国 4 地的组，大组长（华为叫 LM）在上海，4 地各有一个本地业务负责人。我立刻意识到，到年终考评时，所有的成果一定会是 4 地分配，并且 4 地的负责人会占去一大部分，这是组织结构形成的优势。我所在的小组到时候会难以突破，资源分配会非常激烈。 + +### 备孕成功 + +先不说这些，在 18 年时妻子做完了手术，手术居然很成功。休息完之后我们 19 年初开始备孕了，这次真的是上天保佑，运气不错，很快就怀上了。这段时间，我虽然每天做地铁 1.5 小时到公司上班，经受高强度的工作，我心里每天还是乐滋滋的。但是，突然有一天，PL（华为小组长）根我说，LM 需要派人去杭研所支持工作，我是最合适人选，让我有个心里准备。当时我是不想去的，这个时候妻子是最需要关怀的时候，我想 LM 表达了我的意愿，并且我也知道如果去了杭州年底绩效考评肯定不高。过程不多说了，反正结果是我去了杭州。 + +于是我开始了两头奔波的日子，每个月回上海一趟。这过程中还有个插曲，家里老家城中村改造，分了一点钱，父母执意卖掉了老家学校周边的房子，丈母娘也处理老家的一些房子，然后把钱都给了我们，然后我用这笔家里最后的资产，同时利用华为的现金流在绍、甬不限购地区购买一些房子，我没有炒房的想法，只是防止被通货膨胀侵蚀而已，不过后来结果证明我貌似又蒙对了啊，我自己的看法是： + +**杭绍甬在经济层面会连成紧密的一片，在行政区上杭州兼并绍 部分区域的概率其实不大，行政区的扩展应该是先兼并自身的下级代管城市。** + +### 宝宝出生 + +不说房子了，继续工作吧。10 月份干了快一年时候，我华为的师傅（华为有师徒培养体系）偷偷告诉我被定为备选 PL 了，虽然不知道真假，但是我心里还是有点小高兴。不过我心里也慢慢意识到这个公司可能不是我真正想要的公司，这么多年了，愚钝如我慢慢也开始知道自己想干什么了。因为我的宝宝出生了，看着这只四脚吞金兽，我意识到自己已经是一个父亲了。 + +2019 年随着美国不断升级的制裁消息，我在华为的日子也走到年底，马上将迎来神奇的 2020 年。 + +## 2020 + +> 2020 就少写一些了，有些东西真的可能忘却更好。 + +### 在家办公 + +年初就给大家来了一个重击，新冠疫情改变了太多的东西。这个时候真的是看出华为的执行力，居家办公也效率不减多少，并且迅速实现了复工。到了 3-4 月份，华为开始正式评议去年绩效等级，我心里开始有预感，以前的分析大概率会兑现，并且绩效和收入挂钩，华为是个风险意识极强的公司，去年的制裁会导致公司开始风险预备，虽然我日常工作还是受到多数人好评，但是我知道这其实在评议人员那里，没有任何意义。果然绩效评议结果出来了，呵呵，我很不满意。绩效沟通时 LM 破例跟我沟通了很长时间，我直接表达了我的想法。LM 承诺钱不会少，呵呵，我不评价吧。后来一天开始组织调整，成立一个新的小组，LM 给我电话让我当组长,我拒绝了，这件事情我不知道对错，我当时是这样考虑的 + +1. **升任新的职位，未必是好事，更高的职位意味着更高的要求，因此对备选人员要么在原岗位已经能力有余，要么时间精力有余；我认为当时我这两个都不满足，呵呵离家有点远，LM 很可以只是因为绩效事情做些补偿。** +2. **华为不会垮，这点大家有信心，但未来一定会出现战略收缩，最后这艘大船上还剩下哪些人不清楚，底层士兵有可能是牺牲品。** +3. **我 34 岁了** + +### 提出离职 + +另外我一直思考未来想做什么，已经有了一丝眉目，就这样，我拿了年终奖约 7 月就提出了离职，后来部门还让我做了最后一次贡献，把我硬留到 10 月份，这样就可以参加上半年考核了，让帮忙背了一个 C 呵呵，这是工作多年，最差绩效吧。 + +这里还有一个小插曲，最后这三个月我负责什么工作呢，因为 20 年 3 月开始我就接手了部分部门招聘工作（在华为干过的都知道为什么非 HR 也要帮忙招聘，呵呵大坑啊，就不多解释了），结果最后三个月我这个待离职员工居然继续负责招聘，真的是很搞笑，不过由于我在上一份工作中其实一直也有招聘的工作，所以也算做的轻车熟路，每天看 50 份左右简历（我看得都非常仔细，我害怕自己的疏忽会导致一个优秀的人才错失机会，所以比较慢）其实也蛮有收货，最后好歹对程序员如何写简历有了一些心得。 + +## 总结 + +好了 7 年多，近 8 年的职场讲完了，不管过去如何，未来还是要继续努力，希望看到这篇文章觉得有帮助的朋友，可以帮忙点个推荐，这样可能更多的人看到，也许可以避免更多的人犯我犯的错误。另外欢迎私信或者其他方式交流（某 Xin 号，jingyewandeng），可以讨论职场经验，方向，我也可以帮忙改简历（免费啊），不用怕打扰，能帮助别人是一项很有成绩感的事，并且过程中也会有收获，程序员也不要太腼腆呵呵 \ No newline at end of file diff --git a/docs/high-quality-technical-articles/personal-experience/two-years-of-back-end-develop--experience-in-didi&toutiao.md b/docs/high-quality-technical-articles/personal-experience/two-years-of-back-end-develop--experience-in-didi&toutiao.md new file mode 100644 index 0000000000000000000000000000000000000000..549848e63695cc76946a4fb0c3cd134beed918f9 --- /dev/null +++ b/docs/high-quality-technical-articles/personal-experience/two-years-of-back-end-develop--experience-in-didi&toutiao.md @@ -0,0 +1,148 @@ +--- +title: 我在滴滴和头条的两年后端研发工作经验分享 +category: 技术文章精选集 +tag: + - 个人经历 +--- + +> 内容总结： +> +> - 要学会深入思考，总结沉淀，这是我觉得最重要也是最有意义的一件事。 +> - 积极学习，保持技术热情。如果我们积极学习，保持技术能力、知识储备与工作年限成正比，这到了 35 岁哪还有什么焦虑呢，这样的大牛我觉得应该也是各大公司抢着要吧？ +> - 在能为公司办成事，创造价值这一点上，我觉得最重要的两个字就是主动，主动承担任务，主动沟通交流，主动推动项目进展，主动协调资源，主动向上反馈，主动创造影响力等等。 +> - 脸皮要厚一点，多找人聊，快速融入，最忌讳有问题也不说，自己把自己孤立起来。 +> - 想舔就舔，不想舔也没必要酸别人，Respect Greatness。 +> - 时刻准备着，技术在手就没什么可怕的，哪天干得不爽了直接跳槽。 +> - 平时积极总结沉淀，多跟别人交流，形成方法论。 +> - ...... +> +> 原文地址：https://www.nowcoder.com/discuss/351805 + +先简单交代一下背景吧，某不知名 985 的本硕，17 年毕业加入滴滴，当时找工作时候也是在牛客这里跟大家一起奋战的。今年下半年跳槽到了头条，一直从事后端研发相关的工作。之前没有实习经历，算是两年半的工作经验吧。这两年半之间完成了一次晋升，换了一家公司，有过开心满足的时光，也有过迷茫挣扎的日子，不过还算顺利地从一只职场小菜鸟转变为了一名资深划水员。在这个过程中，总结出了一些还算实用的划水经验，有些是自己领悟到的，有些是跟别人交流学到的，在这里跟大家分享一下。 + +## 学会深入思考，总结沉淀 + +**我想说的第一条就是要学会深入思考，总结沉淀，这是我觉得最重要也是最有意义的一件事。** + +**先来说深入思考。** 在程序员这个圈子里，常能听到一些言论：_“我这个工作一点技术含量都没有，每天就 CRUD，再写写 if-else，这 TM 能让我学到什么东西？”_ + +抛开一部分调侃和戏谑的论调不谈，这可能确实是一部分同学的真实想法，至少曾经的我，就这么认为过。后来随着工作经验的积累，加上和一些高 level 的同学交流探讨之后，我发现这个想法其实是非常错误的。之所以出现没什么可学的这样的看法，基本上是思维懒惰的结果。**任何一件看起来很不起眼的小事，只要进行深入思考，稍微纵向挖深或者横向拓宽一下，都是足以让人沉溺的知识海洋。** + +举一个例子。某次有个同学跟我说，这周有个服务 OOM 了，查了一周发现有个地方 defer 写的有问题，改了几行代码上线修复了，周报都没法写。可能大家也遇到过这样的场景，还算是有一定的代表性。其实就查 bug 这件事来说，是一个发现问题，排查问题，解决问题的过程，包含了触发、定位、复现、根因、修复、复盘等诸多步骤，花了一周来做这件事，一定有不断尝试与纠错的过程，这里面其实就有很多思考的空间。比如说定位，如何缩小范围的？走了哪些弯路？用了哪些分析工具？比如说根因，可以研究的点起码有 linux 的 OOM，k8s 的 OOM，go 的内存管理，defer 机制，函数闭包的原理等等。如果这些真的都不涉及，仍然花了一周时间做这件事，那复盘应该会有很多思考，提出来几十个 WHY 没问题吧... + +**再来说下总结沉淀。** 这个我觉得也是大多数程序员比较欠缺的地方，只顾埋头干活，可以把一件事做的很好。但是几乎从来不做抽象总结，以至于工作好几年了，所掌握的知识还是零星的几点，不成体系，不仅容易遗忘，而且造成自己视野比较窄，看问题比较局限。适时地做一些总结沉淀是很重要的，这是一个从术到道的过程，会让自己看问题的角度更广，层次更高。遇到同类型的问题，可以按照总结好的方法论，系统化、层次化地推进和解决。 + +还是举一个例子。做后台服务，今天优化了 1G 内存，明天优化了 50%的读写耗时，是不是可以做一下性能优化的总结？比如说在应用层，可以管理服务对接的应用方，梳理他们访问的合理性；在架构层，可以做缓存、预处理、读写分离、异步、并行等等；在代码层，可以做的事情更多了，资源池化、对象复用、无锁化设计、大 key 拆分、延迟处理、编码压缩、gc 调优还有各种语言相关的高性能实践...等下次再遇到需要性能优化的场景，一整套思路立马就能套用过来了，剩下的就是工具和实操的事儿了。 + +还有的同学说了，我就每天跟 PM 撕撕逼，做做需求，也不做性能优化啊。先不讨论是否可以搞性能优化，单就做业务需求来讲，也有可以总结的地方。比如说，如何做系统建设？系统核心能力，系统边界，系统瓶颈，服务分层拆分，服务治理这些问题有思考过吗？每天跟 PM 讨论需求，那作为技术同学该如何培养产品思维，引导产品走向，如何做到架构先行于业务，这些问题也是可以思考和总结的吧。就想一下，连接手维护别人烂代码这种蛋疼的事情，都能让 Martin Fowler 整出来一套重构理论，还显得那么高大上，我们确实也没啥必要对自己的工作妄自菲薄... + +所以说： **学习和成长是一个自驱的过程，如果觉得没什么可学的，大概率并不是真的没什么可学的，而是因为自己太懒了，不仅是行动上太懒了，思维上也太懒了。可以多写技术文章，多分享，强迫自己去思考和总结，毕竟如果文章深度不够，大家也不好意思公开分享。** + +## 积极学习，保持技术热情 + +最近两年在互联网圈里广泛传播的一种焦虑论叫做 35 岁程序员现象，大意是说程序员这个行业干到 35 岁就基本等着被裁员了。不可否认，互联网行业在这一点上确实不如公务员等体制内职业。但是，这个问题里 35 岁程序员并不是绝对生理意义上的 35 岁，应该是指那些工作十几年和工作两三年没什么太大区别的程序员。后面的工作基本是在吃老本，没有主动学习与充电，35 岁和 25 岁差不多，而且没有了 25 岁时对学习成长的渴望，反而添了家庭生活的诸多琐事，薪资要求往往也较高，在企业看来这确实是没什么竞争力。 + +**如果我们积极学习，保持技术能力、知识储备与工作年限成正比，这到了 35 岁哪还有什么焦虑呢，这样的大牛我觉得应该也是各大公司抢着要吧？** 但是，**学习这件事，其实是一个反人类的过程，这就需要我们强迫自己跳出自己的安逸区，主动学习，保持技术热情。** 在滴滴时有一句话大概是，**主动跳出自己的舒适区，感到挣扎与压力的时候，往往是黎明前的黑暗，那才是成长最快的时候。相反如果感觉自己每天都过得很安逸，工作只是在混时长，那可能真的是温水煮青蛙了。** + +刚毕业的这段时间，往往空闲时间还比较多，正是努力学习技术的好时候。借助这段时间夯实基础，培养出良好的学习习惯，保持积极的学习态度，应该是受益终身的。至于如何高效率学习，网上有很多大牛写这样的帖子，到了公司后内网也能找到很多这样的分享，我就不多谈了。 + +**_可以加入学习小组和技术社区，公司内和公司外的都可以，关注前沿技术。_** + +## 主动承担，及时交流反馈 + +前两条还是从个人的角度出发来说的，希望大家可以提升个人能力，保持核心竞争力，但从公司角度来讲，公司招聘员工入职，最重要的是让员工创造出业务价值，为公司服务。虽然对于校招生一般都会有一定的培养体系，但实际上公司确实没有帮助我们成长的义务。 + +**在能为公司办成事，创造价值这一点上，我觉得最重要的两个字就是主动，主动承担任务，主动沟通交流，主动推动项目进展，主动协调资源，主动向上反馈，主动创造影响力等等。** + +我当初刚入职的时候，基本就是 leader 给分配什么任务就把本职工作做好，然后就干自己的事了，几乎从来不主动去跟别人交流或者主动去思考些能帮助项目发展的点子。自以为把本职工作保质保量完成就行了，后来发现这么做其实是非常不够的，这只是最基本的要求。而有些同学的做法则是 leader 只需要同步一下最近要做什么方向，下面的一系列事情基本不需要 leader 操心了 ，这样的同学我是 leader 我也喜欢啊。入职后经常会听到的一个词叫 owner 意识，大概就是这个意思吧。 + +在这个过程中，另外很重要的一点就是及时向上沟通反馈。项目进展不顺利，遇到什么问题，及时跟 leader 同步，技术方案拿捏不准可以跟 leader 探讨，一些资源协调不了可以找 leader 帮忙，不要有太多顾忌，认为这些会太麻烦，leader 其实就是干这个事的。。如果项目进展比较顺利，确实也不需要 leader 介入，那也需要及时把项目的进度，取得的收益及时反馈，自己有什么想法也提出来探讨，问问 leader 对当前进展的建议，还有哪些地方需要改进，消除信息误差。做这些事一方面是合理利用 leader 的各种资源，另一方面也可以让 leader 了解到自己的工作量，对项目整体有所把控，毕竟 leader 也有 leader，也是要汇报的。可能算是大家比较反感的向上管理吧，有内味了，这个其实我也做得不好。但是最基本的一点，不要接了一个任务闷着头干活甚至与世隔绝了，一个月了也没跟 leader 同步过，想着憋个大招之类的，那基本凉凉。 + +**一定要主动，可以先从强迫自己在各种公开场合发言开始，有问题或想法及时 one-one。** + +除了以上几点，还有一些小点我觉得也是比较重要的，列在下面： + +## 第一件事建立信任 + +无论是校招还是社招，刚入职的第一件事是非常重要的，直接决定了 leader 和同事对自己的第一印象。入职后要做的第一件事一定要做好，最起码的要顺利完成而且不能出线上事故。这件事的目的就是为了建立信任，让团队觉得自己起码是靠谱的。如果这件事做得比较好，后面一路都会比较顺利。如果这件事就搞杂了，可能有的 leader 还会给第二次机会，再搞不好，后面就很难了，这一条对于社招来说更为重要。 + +而刚入职，公司技术栈不熟练，业务繁杂很难理清什么头绪，压力确实比较大。这时候一方面需要自己投入更多的精力，另一方面要多跟组内的同学交流，不懂就问。**最有效率的学习方式，我觉得不是什么看书啊学习视频啊，而是直接去找对应的人聊，让别人讲一遍自己基本就全懂了，这效率比看文档看代码快多了，不仅省去了过滤无用信息的过程，还了解到了业务的演变历史。当然，这需要一定的沟通技巧，毕竟同事们也都很忙。** + +**脸皮要厚一点，多找人聊，快速融入，最忌讳有问题也不说，自己把自己孤立起来。** + +## 超出预期 + +超出预期这个词的外延范围很广，比如 leader 让去做个值周，解答用户群里大家的问题，结果不仅解答了大家的问题，还收集了这些问题进行分类，进而做了一个智能问答机器人解放了值周的人力，这可以算超出预期。比如 leader 让给运营做一个小工具，结果建设了一系列的工具甚至发展成了一个平台，成为了一个完整的项目，这也算超出预期。超出预期要求我们有把事情做大的能力，也就是想到了 leader 没想到的地方，并且创造了实际价值，拿到了业务收益。这个能力其实也比较重要，在工作中发现，有的人能把一个小盘子越做越大，而有的人恰好反之，那么那些有创新能力，经常超出预期的同学发展空间显然就更大一点。 + +**这块其实比较看个人能力，暂时没想到什么太好的捷径，多想一步吧。** + +## 体系化思考，系统化建设 + +这句话是晋升时候总结出来的，大意就是做系统建设要有全局视野，不要局限于某一个小点，应该有良好的规划能力和清晰的演进蓝图。比如，今天加了一个监控，明天加一个报警，这些事不应该成为一个个孤岛，而是属于稳定性建设一期其中的一小步。这一期稳定性建设要做的工作是报警配置和监控梳理，包括机器监控、系统监控、业务监控、数据监控等，预期能拿到 XXX 的收益。这个工作还有后续的 roadmap，稳定性建设二期要做容量规划，接入压测，三期要做降级演练，多活容灾，四期要做...给人的感觉就是这个人思考非常全面，办事有体系有规划。 + +**平时积极总结沉淀，多跟别人交流，形成方法论。** + +## 提升自己的软素质能力 + +这里的软素质能力其实想说的就是 PPT、沟通、表达、时间管理、设计、文档等方面的能力。说实话，我觉得我当时能晋升就是因为 PPT 做的好了一点...可能大家平时对这些能力都不怎么关注，以前我也不重视，觉得比较简单，用时候直接上就行了，但事实可能并不像想象得那样简单。比如晋升时候 PPT+演讲+答辩这个工作，其实有很多细节的思考在里面，内容如何选取，排版怎么设计，怎样引导听众的情绪，如何回答评委的问题等等。晋升时候我见过很多同学 PPT 内容编排杂乱无章，演讲过程也不流畅自然，虽然确实做了很多实际工作，但在表达上欠缺了很多，属于会做不会说，如果再遇到不了解实际情况的外部门评委，吃亏是可以预见的。 + +**_公司内网一般都会有一些软素质培训课程，可以找一些场合刻意训练。_** + +以上都是这些分享还都算比较伟光正，但是社会吧也不全是那么美好的。。下面这些内容有负能量倾向，三观特别正的同学以及观感不适者建议跳过。 + +## 拍马屁是真的香 + +拍马屁这东西入职前我是很反感的，我最初想加入互联网公司的原因就是觉得互联网公司的人情世故没那么多，事实证明，我错了...入职前几天，部门群里大 leader 发了一条消息，后面几十条带着大拇指的消息立马跟上，学习了，点赞，真不错，优秀，那场面，说是红旗招展锣鼓喧天鞭炮齐鸣一点也不过分。除了惊叹大家超强的信息接收能力和处理速度外，更进一步我还发现，连拍马屁都是有队形的，一级部门 leader 发消息，几个二级部门 leader 跟上，后面各组长跟上，最后是大家的狂欢，让我一度怀疑拍马屁的速度就决定了职业生涯的发展前景（没错，现在我已经不怀疑了）。 + +坦诚地说，我到现在也没习惯在群里拍马屁，但也不反感了，可以说把这个事当成一乐了。倒不是说我没有那个口才和能力（事实上也不需要什么口才，大家都简单直接），在某些场合，为活跃气氛的需要，我也能小嘴儿抹了蜜，甚至能把古诗文彩虹屁给 leader 安排上。而是我发现我的直属 leader 也不怎么在群里拍马屁，所以我表面上不公开拍马屁其实属于暗地里事实上迎合了 leader 的喜好... + +但是拍马屁这个事只要掌握好度，整体来说还是香的，最多是没用，至少不会有什么坏处嘛。大家能力都差不多，每一次在群里拍马屁的机会就是一次露脸的机会，按某个同事的说法，这就叫打造个人技术影响力... + +**想舔就舔，不想舔也没必要酸别人，Respect Greatness。** + +## 永不缺席的撕逼甩锅实战 + +有人的地方，就有江湖。虽然搞技术的大多城府也不深，但撕逼甩锅邀功抢活这些闹心的事儿基本也不会缺席，甚至我还见到过公开群发邮件撕逼的...这部分话题涉及到一些敏感信息就不多说了，而且我们低职级的遇到这些事儿的机会也不会太多。只是给大家提个醒，在工作的时候迟早都会吃到这方面的瓜，到时候留个心眼。 + +**稍微注意一下，咱不会去欺负别人，但也不能轻易让别人给欺负了。** + +## 不要被画饼蒙蔽了双眼 + +说实话，我个人是比较反感灌鸡汤、打鸡血、谈梦想、讲奋斗这一类行为的，9102 年都快过完了，这一套\*\*\*治还在大行其道，真不知道是该可笑还是可悲。当然，这些词本身并没有什么问题，但是这些东西应该是自驱的，而不应该成为外界的一种强 push。『我必须努力奋斗』这个句式我觉得是正常的，但是『你必须努力奋斗』这种话多少感觉有点诡异，努力奋斗所以让公司的股东们发家致富？尤其在钱没给够的情况下，这些行为无异于耍流氓。我们需要对 leader 的这些画饼操作保持清醒的认知，理性分析，作出决策。比如感觉钱没给够（或者职级太低，同理）的时候，可能有以下几种情况： + +1. leader 并没有注意到你薪资较低这一事实 +2. leader 知道这个事实，但是不知道你有多强烈的涨薪需求 +3. leader 知道你有涨薪的需求，但他觉得你能力还不够 +4. leader 知道你有涨薪的需求，能力也够，但是他不想给你涨 +5. leader 想给你涨，也向上反馈和争取了，但是没有资源 + +这时候我们需要做的是向上反馈，跟 leader 沟通确认。如果是 1 和 2，那么通过沟通可以消除信息误差。如果是 3，需要分情况讨论。如果是 4 和 5，已经可以考虑撤退了。对于这些事儿，也没必要抱怨，抱怨解决不了任何问题。我们要做的就是努力提升好个人能力，保持个人竞争力，等一个合适的时机，跳槽就完事了。 + +**时刻准备着，技术在手就没什么可怕的，哪天干得不爽了直接跳槽。** + +## 学会包装 + +这一条说白了就是，要会吹。忘了从哪儿看到的了，能说、会写、善做是对职场人的三大要求。能说是很重要的，能说才能要来项目，拉来资源，招来人。同样一件事，不同的人能说出来完全不一样的效果。比如我做了个小工具上线了，我就只能说出来基本事实，而让 leader 描述一下，这就成了，打造了 XXX 的工具抓手，改进了 XXX 的完整生态，形成了 XXX 的业务闭环。老哥，我服了，硬币全给你还不行嘛。据我的观察，每个互联网公司都有这么几个词，抓手、生态、闭环、拉齐、梳理、迭代、owner 意识等等等等，我们需要做的就是熟读并背诵全文，啊不，是牢记并熟练使用。 + +这是对事情的包装，对人的包装也是一样的，尤其是在晋升和面试这样的应试型场合，特点是流程短一锤子买卖，包装显得尤为重要。晋升和面试这里就不展开说了，这里面的道和术太多了。。下面的场景提炼自面试过程中和某公司面试官的谈话，大家可以感受一下： + +1. 我们背后是一个四五百亿美金的市场... +2. 我负责过每天千亿级别访问量的系统... +3. 工作两年能达到这个程度挺不错的... +4. 贵司技术氛围挺好的，业务发展前景也很广阔... +5. 啊，彼此彼此... +6. 嗯，久仰久仰... + +人生如戏，全靠演技 + +**可以多看 leader 的 PPT，多听老板的向上汇报和宣讲会。** + +## 选择和努力哪个更重要？ + +这还用问么，当然是选择。在完美的选择面前，努力显得一文不值，我有个多年没联系的高中同学今年已经在时代广场敲钟了...但是这样的案例太少了，做出完美选择的随机成本太高，不确定性太大。对于大多数刚毕业的同学，对行业的判断力还不够成熟，对自身能力和创业难度把握得也不够精准，此时拉几个人去创业，显得风险太高。我觉得更为稳妥的一条路是，先加入规模稍大一点的公司，找一个好 leader，抱好大腿，提升自己的个人能力。好平台加上大腿，再加上个人努力，这个起飞速度已经可以了。等后面积累了一定人脉和资金，深刻理解了市场和需求，对自己有信心了，可以再去考虑创业的事。 + +## 后记 + +本来还想分享一些生活方面的故事，发现已经这么长了，那就先这样叭。上面写的一些总结和建议我自己做的也不是很好，还需要继续加油，和大家共勉。另外，其中某些观点，由于个人视角的局限性也不保证是普适和正确的，可能再工作几年这些观点也会发生改变，欢迎大家跟我交流~（甩锅成功） + +最后祝大家都能找到心仪的工作，快乐工作，幸福生活，广阔天地，大有作为。 \ No newline at end of file diff --git a/docs/high-quality-technical-articles/readme.md b/docs/high-quality-technical-articles/readme.md new file mode 100644 index 0000000000000000000000000000000000000000..814cb784d34df7389d26ac556348514fea8af34e --- /dev/null +++ b/docs/high-quality-technical-articles/readme.md @@ -0,0 +1,5 @@ + +# Java 技术文章精选集 + +在这里我会精选一些和 Java 相关的优质技术文章，每一篇都值得你阅读 3 遍以上！ + diff --git a/docs/high-quality-technical-articles/work/get-into-work-mode-quickly-when-you-join-a-company.md b/docs/high-quality-technical-articles/work/get-into-work-mode-quickly-when-you-join-a-company.md new file mode 100644 index 0000000000000000000000000000000000000000..56d3f7da93d18c6c79960f4ffa94405b222879d9 --- /dev/null +++ b/docs/high-quality-technical-articles/work/get-into-work-mode-quickly-when-you-join-a-company.md @@ -0,0 +1,94 @@ +--- +title: 新入职一家公司如何快速进入工作状态 +category: 技术文章精选集 +tag: + - 工作 +--- + +> 强烈建议每一位即将入职/在职的小伙伴看看这篇文章，看完之后可以帮助你少踩很多坑。整篇文章逻辑清晰，内容全面！ +> +> 我对原文进行了内容和排版完善。 +> +> **原文地址** ：https://www.cnblogs.com/hunternet/p/14675348.html + +![新入职一家公司如何快速进入状态](https://guide-blog-images.oss-cn-shenzhen.aliyuncs.com/javaguide/%E6%96%B0%E5%85%A5%E8%81%8C%E4%B8%80%E5%AE%B6%E5%85%AC%E5%8F%B8%E5%A6%82%E4%BD%95%E5%BF%AB%E9%80%9F%E8%BF%9B%E5%85%A5%E7%8A%B6%E6%80%81.png) + +一年一度的金三银四跳槽大戏即将落幕，相信很多跳槽的小伙伴们已经找到了心仪的工作，即将或已经有了新的开始。 + +相信有过跳槽经验的小伙伴们都知道，每到一个新的公司面临的可能都是新的业务、新的技术、新的团队......这些可能会打破你原来工作思维、编码习惯、合作方式...... + +而于公司而言，又不能给你几个月的时间去慢慢的熟悉。这个时候，如何快速进入工作状态，尽快发挥自己的价值是非常重要的。 + +有些人可能会很幸运，入职的公司会有完善的流程与机制，通过一带一、各种培训等方式可以在短时间内快速的让新人进入工作状态。有些人可能就没有那么幸运了，就比如我在几年前跳槽进入某厂的时候，当时还没有像我们现在这么完善的带新人融入的机制，又赶上团队最忙的一段时间，刚一入职的当天下午就让给了我几个线上问题去排查，也没有任何的文档和培训。遇到情况，很多人可能会因为难以快速适应，最终承受不起压力而萌生退意。 + +![bad175e3a380bea.](https://hunter-picgos.oss-cn-shanghai.aliyuncs.com/picgo/bad175e3a380bea..jpg) + +那么，**我们应该如何去快速的让自己进入工作状态，适应新的工作节奏呢？** + +新的工作面对着一堆的代码仓库，很多人常常感觉无从下手。但回顾一下自己过往的工作与项目的经验，我们可以发现它们有着异曲同工之处。当开始一个新的项目，一般会经历几个步骤：需求->设计->开发->测试->发布，就这么循环往复，我们完成了一个又一个的项目。 + +![项目流程](https://guide-blog-images.oss-cn-shenzhen.aliyuncs.com/javaguide/%E9%A1%B9%E7%9B%AE%E6%B5%81%E7%A8%8B.png) + +而在这个过程中主要有四个方面的知识那就是业务、技术、项目与团队贯穿始终。新入职一家公司，我们第一阶段的目标就是要具备能够跟着团队做项目的能力，因此我们所应尽快掌握的知识点也要从这四个方面入手。 + +## 业务 + +很多人可能会认为作为一个技术人，最应该了解的不应该是技术吗？于是他们在进入一家公司后，就迫不及待的研究起来了一些技术文档，系统架构，甚至抱起来源代码就开始“啃”，如果你也是这么做的，那就大错特错了！在几乎所有的公司里，技术都是作为一个工具存在的，虽然它很重要，但是它也是为了承载业务所存在的，技术解决了如何做的问题，而业务却告诉我们，做什么，为什么做。一旦脱离了业务，那么技术的存在将毫无意义。 + +想要了解业务，有两个非常重要的方式 + +**一是靠问** + +如果你加入的团队，有着完善的业务培训机制，详尽的需求文档，也许你不需要过多的询问就可以了解业务，但这只是理想中的情况，大多数公司是没有这个条件的。因此我们只能靠问。 + +这里不得不提的是，作为一个新人一定要有一定的脸皮厚度，不懂就要问。我见过很多新人会因为内向、腼腆，遇到疑问总是不好意思去问，这导致他们很长一段时间都难以融入团队、承担更重要的责任。不怕要怕挨训、怕被怼，而且我相信绝对多数的程序员还是很好沟通的！ + +**二是靠测试** + +我认为测试绝对是一个人快速了解团队业务的方式。通过测试我们可以走一走自己团队所负责项目的整体流程，如果遇到自己走不下去或想不通的地方及时去问，在这个过程中我们自然而然的就可以快速的了解到核心的业务流程。 + +在了解业务的过程中，我们应该注意的是不要让自己过多的去追求细节，我们的目的是先能够整体了解业务流程，我们面向哪些用户，提供了哪些服务...... + +## 技术 + +在我们初步了解完业务之后，就该到技术了，也许你已经按捺不住翻开源代码的准备了，但还是要先提醒你一句先不要着急。 + +这个时候我们应该先按照自己了解到的业务，结合自己过往的工作经验去思考一下如果是自己去实现这个系统，应该如何去做？这一步很重要，它可以在后面我们具体去了解系统的技术实现的时候去对比一下与自己的实现思路有哪些差异，为什么会有这些差异，哪些更好，哪些不好，对于不好我们可以提出自己的意见，对于更好的我们可以吸收学习为己用！ + +接下来，我们就是要了解技术了，但也不是一上来就去翻源代码。 **应该按照从宏观到细节，由外而内逐步地对系统进行分析。** + +首先，我们应该简单的了解一下 **自己团队/项目的所用到的技术栈** ，Java 还是.NET、亦或是多种语言并存，项目是前后端分离还是服务端全包，使用的数据库是 MySQL 还是 PostgreSQL......，这样我们可能会对所用到的技术和框架，以及自己所负责的内容有一定的预期，这一点有的人可能在面试的时候就会简单了解过。 + +下一步，我们应该了解的是 **系统的宏观业务架构** 。自己的团队主要负责哪些系统，每个系统又主要包含哪些模块，又与哪些外部系统进行交互......对于这些，最好可以通过流程图或者思维导图等方式整理出来。 + +然后，我们要做的是看一下 **自己的团队提供了哪些对外的接口或者服务** 。每个接口和服务所提供功能是什么。这一点我们可以继续去测试自己的系统，这个时候我们要看一看主要流程中主要包含了哪些页面，每个页面又调用了后端的哪些接口，每个后端接口又对应着哪个代码仓库。(如果是单纯做后端服务的，可以看一下我们提供了哪些服务，又有哪些上游服务，每个上游服务调用自己团队的哪些服务......)，同样我们应该用画图的形式整理出来。 + +接着，我们要了解一下 **自己的系统或服务又依赖了哪些外部服务** ，也就是说需要哪些外部系统的支持，这些服务也许是团队之外、公司之外，也可能是其他公司提供的。这个时候我们可以简单的进入代码看一下与外部系统的交互是怎么做的，包括通讯框架(REST、RPC)、通讯协议...... + +到了代码层面，我们首先应该了解每个模块代码的层次结构，一个模块分了多少层，每个层次的职责是什么，了解了这个就对系统的整个设计有了初步的概念，紧接着就是代码的目录结构、配置文件的位置。 + +最后，我们可以寻找一个示例，可以是一个接口，一个页面，让我们的思路跟随者代码的运行的路线，从入参到出参，完整的走一遍来验证一下我们之前的了解。 + +到了这里我们对于技术层面的了解就可以先告一段落了，我们的目的知识对系统有一个初步的认知，更细节的东西，后面我们会有大把的时间去了解 + +## 项目与团队 + +上面我们提到，新入职一家公司，第一阶段的目标是有跟着团队做项目的能力，接下来我们要了解的就是项目是如何运作的。 + +我们应该把握从需求设计到代码编写入库最终到发布上线的整个过程中的一些关键点。例如项目采用敏捷还是瀑布的模式，一个迭代周期是多长，需求的来源以及展现形式，有没有需求评审，代码的编写规范是什么，编写完成后如何构建，如何入库，有没有提交规范，如何交付测试，发布前的准备是什么，发布工具如何使用...... + +关于项目我们只需要观察同事，或者自己亲身经历一个迭代的开发，就能够大概了解清楚。 + +在了解项目运作的同时，我们还应该去了解团队，同样我们应该先从外部开始，我们对接了哪些外部团队，比如需求从哪里来，是否对接公司外部的团队，提供服务的上游团队有哪些，依赖的下游团队有哪些，团队之间如何沟通，常用的沟通方式是什么....... + +接下来则是团队内部，团队中有哪些角色，每个人的职责是什么，这样遇到问题我们也可以清楚的找到对应的同事寻求帮助。是否有一些定期的活动与会议，例如每日站会、周例会，是否有一些约定俗成的规矩，是否有一些内部评审，分享机制...... + +## 总结 + +新入职一家公司，面临新的工作挑战，能够尽快进入工作状态，实现自己的价值，将会给你带来一个好的开始。 + +作为一个程序员，能够尽快进入工作状态，意味着我们首先应该具备跟着团队做项目的能力，这里我站在了一个后端开发的角度上从业务、技术、项目与团队四个方面总结了一些方法和经验。 + +关于如何快速进入工作状态，如果你有好的方法与建议，欢迎在评论区留言。 + +最后我们用一张思维导图来回顾一下这篇文章的内容。如果你觉得这篇文章对你有所帮助，可以关注文末公众号，我会经常分享一些自己成长过程中的经验与心得，与大家一起学习与进步。 \ No newline at end of file diff --git a/docs/home.md b/docs/home.md new file mode 100644 index 0000000000000000000000000000000000000000..08b16375142d3920ed4fc98b31c471fa837d2ff1 --- /dev/null +++ b/docs/home.md @@ -0,0 +1,52 @@ +--- +icon: creative +title: JavaGuide（Java学习&&面试指南） +--- + +
+

+ + + +

+

+ + + +

+

+ 阅读 + stars + forks + issues +

+
+ +> 1. **面试专版** ：准备面试的小伙伴可以考虑面试专版：[《Java 面试进阶指北 》](https://www.yuque.com/docs/share/f37fc804-bfe6-4b0d-b373-9c462188fec7) (质量很高，专为面试打造，配合 JavaGuide 食用) +> 2. **转载须知** ：以下所有文章如非文首说明为转载皆为我（Guide 哥）的原创，转载在文首注明出处，如发现恶意抄袭/搬运，会动用法律武器维护自己的权益。让我们一起维护一个良好的技术创作环境！⛽️ + +你可能需要： + +- [项目介绍](/javaguide/intro) +- [贡献指南](/javaguide/contribution-guideline) +- [常见问题](/javaguide/faq) +- [项目代办](/javaguide/todo) + +## 面试资源 + + + +## 联系我 + +想要参与项目维护或者学习交流的话，欢迎添加我的微信：“**JavaGuide1996**” 备注“**Github**”即可！ + +![](../media/pictures/weixin.jpeg) + +## 公众号 + +如果大家想要实时关注我更新的文章以及分享的干货的话，可以关注我的公众号“**JavaGuide**”。 + +**《Java 面试突击》:** 由本文档衍生的专为面试而生的《Java 面试突击》V4.0 PDF 版本[公众号](#公众号)后台回复 **"面试突击"** 即可领取！ + +![我的公众号](https://cdn.jsdelivr.net/gh/javaguide-tech/blog-images/2020-08/167598cd2e17b8ec.png) + diff --git a/docs/java/basis/bigdecimal.md b/docs/java/basis/bigdecimal.md new file mode 100644 index 0000000000000000000000000000000000000000..f5641a90432e7fea71c2f04fb43bc46f07140f7e --- /dev/null +++ b/docs/java/basis/bigdecimal.md @@ -0,0 +1,345 @@ +--- +title: BigDecimal解决浮点数运算精度丢失问题 +category: Java +tag: + - Java基础 +--- + +《阿里巴巴 Java 开发手册》中提到：“为了避免精度丢失，可以使用 `BigDecimal` 来进行浮点数的运算”。 + +这篇文章，我就简单解释一下浮点数运算出现精度丢失的原因以及 `BigDecimal` 的常见用法，希望对大家有帮助！ + +## BigDecimal 介绍 + +`BigDecimal` 可以实现对浮点数的运算，不会造成精度丢失。通常情况下，大部分需要浮点数精确运算结果的业务场景（比如涉及到钱的场景）都是通过 `BigDecimal` 来做的。 + +纳尼，浮点数的运算竟然还会有精度丢失的风险吗？确实会！ + +示例代码： + +```java +float a = 2.0f - 1.9f; +float b = 1.8f - 1.7f; +System.out.println(a);// 0.100000024 +System.out.println(b);// 0.099999905 +System.out.println(a == b);// false +``` + +**为什么浮点数 `float` 或 `double` 运算的时候会有精度丢失的风险呢？** + +这个和计算机保存浮点数的机制有很大关系。我们知道计算机是二进制的，而且计算机在表示一个数字时，宽度是有限的，无限循环的小数存储在计算机时，只能被截断，所以就会导致小数精度发生损失的情况。这也就是解释了为什么浮点数没有办法用二进制精确表示。 + +就比如说十进制下的 0.2 就没办法精确转换成二进制小数： + +```java +// 0.2 转换为二进制数的过程为，不断乘以 2，直到不存在小数为止， +// 在这个计算过程中，得到的整数部分从上到下排列就是二进制的结果。 +0.2 * 2 = 0.4 -> 0 +0.4 * 2 = 0.8 -> 0 +0.8 * 2 = 1.6 -> 1 +0.6 * 2 = 1.2 -> 1 +0.2 * 2 = 0.4 -> 0（发生循环） +... +``` + +关于浮点数的更多内容，建议看一下[计算机系统基础（四）浮点数](http://kaito-kidd.com/2018/08/08/computer-system-float-point/)这篇文章。 + +## BigDecimal 的用处 + +《阿里巴巴 Java 开发手册》中提到：**浮点数之间的等值判断，基本数据类型不能用==来比较，包装数据类型不能用 equals 来判断。** + +![](https://guide-blog-images.oss-cn-shenzhen.aliyuncs.com/javaguide/image-20211213101646884.png) + +具体原因我们在上面已经详细介绍了，这里就不多提了，我们下面直接上实例： + +```java +float a = 1.0f - 0.9f; +float b = 0.9f - 0.8f; +System.out.println(a);// 0.100000024 +System.out.println(b);// 0.099999964 +System.out.println(a == b);// false +``` + +从输出结果就可以看出发生精度丢失的问题。 + +想要解决这个问题也很简单，直接使用 `BigDecimal` 来定义浮点数的值，再进行浮点数的运算操作即可。 + +```java +BigDecimal a = new BigDecimal("1.0"); +BigDecimal b = new BigDecimal("0.9"); +BigDecimal c = new BigDecimal("0.8"); + +BigDecimal x = a.subtract(b); +BigDecimal y = b.subtract(c); + +System.out.println(x); /* 0.1 */ +System.out.println(y); /* 0.1 */ +System.out.println(Objects.equals(x, y)); /* true */ +``` + +## BigDecimal 常见方法 + +### 加减乘除 + +`add` 方法用于将两个 `BigDecimal` 对象相加，`subtract` 方法用于将两个 `BigDecimal` 对象相减。`multiply` 方法用于将两个 `BigDecimal` 对象相乘，`divide` 方法用于将两个 `BigDecimal` 对象相除。 + +```java +BigDecimal a = new BigDecimal("1.0"); +BigDecimal b = new BigDecimal("0.9"); +System.out.println(a.add(b));// 1.9 +System.out.println(a.subtract(b));// 0.1 +System.out.println(a.multiply(b));// 0.90 +System.out.println(a.divide(b));// 无法除尽，抛出 ArithmeticException 异常 +System.out.println(a.divide(b, 2, RoundingMode.HALF_UP));// 1.11 +``` + +这里需要注意的是，在我们使用 `divide` 方法的时候尽量使用 3 个参数版本，并且`RoundingMode` 不要选择 `UNNECESSARY`，否则很可能会遇到 `ArithmeticException`（无法除尽出现无限循环小数的时候），其中 `scale` 表示要保留几位小数，`roundingMode` 代表保留规则。 + +```java +public BigDecimal divide(BigDecimal divisor, int scale, RoundingMode roundingMode) { + return divide(divisor, scale, roundingMode.oldMode); +} +``` + +保留规则非常多，这里列举几种: + +```java +public enum RoundingMode { + // 2.5 -> 3 , 1.6 -> 2 + // -1.6 -> -2 , -2.5 -> -3 + UP(BigDecimal.ROUND_UP), + // 2.5 -> 2 , 1.6 -> 1 + // -1.6 -> -1 , -2.5 -> -2 + DOWN(BigDecimal.ROUND_DOWN), + // 2.5 -> 3 , 1.6 -> 2 + // -1.6 -> -1 , -2.5 -> -2 + CEILING(BigDecimal.ROUND_CEILING), + // 2.5 -> 2 , 1.6 -> 1 + // -1.6 -> -2 , -2.5 -> -3 + FLOOR(BigDecimal.ROUND_FLOOR), + // 2.5 -> 3 , 1.6 -> 2 + // -1.6 -> -2 , -2.5 -> -3 + HALF_UP(BigDecimal.ROUND_HALF_UP), + //...... +} +``` + +### 大小比较 + +`a.compareTo(b)` : 返回 -1 表示 `a` 小于 `b`，0 表示 `a` 等于 `b` ， 1 表示 `a` 大于 `b`。 + +```java +BigDecimal a = new BigDecimal("1.0"); +BigDecimal b = new BigDecimal("0.9"); +System.out.println(a.compareTo(b));// 1 +``` + +### 保留几位小数 + +通过 `setScale`方法设置保留几位小数以及保留规则。保留规则有挺多种，不需要记，IDEA 会提示。 + +```java +BigDecimal m = new BigDecimal("1.255433"); +BigDecimal n = m.setScale(3,RoundingMode.HALF_DOWN); +System.out.println(n);// 1.255 +``` + +## BigDecimal 的使用注意事项 + +注意：我们在使用 `BigDecimal` 时，为了防止精度丢失，推荐使用它的`BigDecimal(String val)`构造方法或者 `BigDecimal.valueOf(double val)` 静态方法来创建对象。 + +《阿里巴巴 Java 开发手册》对这部分内容也有提到，如下图所示。 + +![](https://guide-blog-images.oss-cn-shenzhen.aliyuncs.com/javaguide/image-20211213102222601.png) + +## BigDecimal 工具类分享 + +网上有一个使用人数比较多的 `BigDecimal` 工具类，提供了多个静态方法来简化 `BigDecimal` 的操作。 + +我对其进行了简单改进，分享一下源码： + +```java +import java.math.BigDecimal; +import java.math.RoundingMode; + +/** + * 简化BigDecimal计算的小工具类 + */ +public class BigDecimalUtil { + + /** + * 默认除法运算精度 + */ + private static final int DEF_DIV_SCALE = 10; + + private BigDecimalUtil() { + } + + /** + * 提供精确的加法运算。 + * + * @param v1 被加数 + * @param v2 加数 + * @return 两个参数的和 + */ + public static double add(double v1, double v2) { + BigDecimal b1 = BigDecimal.valueOf(v1); + BigDecimal b2 = BigDecimal.valueOf(v2); + return b1.add(b2).doubleValue(); + } + + /** + * 提供精确的减法运算。 + * + * @param v1 被减数 + * @param v2 减数 + * @return 两个参数的差 + */ + public static double subtract(double v1, double v2) { + BigDecimal b1 = BigDecimal.valueOf(v1); + BigDecimal b2 = BigDecimal.valueOf(v2); + return b1.subtract(b2).doubleValue(); + } + + /** + * 提供精确的乘法运算。 + * + * @param v1 被乘数 + * @param v2 乘数 + * @return 两个参数的积 + */ + public static double multiply(double v1, double v2) { + BigDecimal b1 = BigDecimal.valueOf(v1); + BigDecimal b2 = BigDecimal.valueOf(v2); + return b1.multiply(b2).doubleValue(); + } + + /** + * 提供（相对）精确的除法运算，当发生除不尽的情况时，精确到 + * 小数点以后10位，以后的数字四舍五入。 + * + * @param v1 被除数 + * @param v2 除数 + * @return 两个参数的商 + */ + public static double divide(double v1, double v2) { + return divide(v1, v2, DEF_DIV_SCALE); + } + + /** + * 提供（相对）精确的除法运算。当发生除不尽的情况时，由scale参数指 + * 定精度，以后的数字四舍五入。 + * + * @param v1 被除数 + * @param v2 除数 + * @param scale 表示表示需要精确到小数点以后几位。 + * @return 两个参数的商 + */ + public static double divide(double v1, double v2, int scale) { + if (scale < 0) { + throw new IllegalArgumentException( + "The scale must be a positive integer or zero"); + } + BigDecimal b1 = BigDecimal.valueOf(v1); + BigDecimal b2 = BigDecimal.valueOf(v2); + return b1.divide(b2, scale, RoundingMode.HALF_UP).doubleValue(); + } + + /** + * 提供精确的小数位四舍五入处理。 + * + * @param v 需要四舍五入的数字 + * @param scale 小数点后保留几位 + * @return 四舍五入后的结果 + */ + public static double round(double v, int scale) { + if (scale < 0) { + throw new IllegalArgumentException( + "The scale must be a positive integer or zero"); + } + BigDecimal b = BigDecimal.valueOf(v); + BigDecimal one = new BigDecimal("1"); + return b.divide(one, scale, RoundingMode.HALF_UP).doubleValue(); + } + + /** + * 提供精确的类型转换(Float) + * + * @param v 需要被转换的数字 + * @return 返回转换结果 + */ + public static float convertToFloat(double v) { + BigDecimal b = new BigDecimal(v); + return b.floatValue(); + } + + /** + * 提供精确的类型转换(Int)不进行四舍五入 + * + * @param v 需要被转换的数字 + * @return 返回转换结果 + */ + public static int convertsToInt(double v) { + BigDecimal b = new BigDecimal(v); + return b.intValue(); + } + + /** + * 提供精确的类型转换(Long) + * + * @param v 需要被转换的数字 + * @return 返回转换结果 + */ + public static long convertsToLong(double v) { + BigDecimal b = new BigDecimal(v); + return b.longValue(); + } + + /** + * 返回两个数中大的一个值 + * + * @param v1 需要被对比的第一个数 + * @param v2 需要被对比的第二个数 + * @return 返回两个数中大的一个值 + */ + public static double returnMax(double v1, double v2) { + BigDecimal b1 = new BigDecimal(v1); + BigDecimal b2 = new BigDecimal(v2); + return b1.max(b2).doubleValue(); + } + + /** + * 返回两个数中小的一个值 + * + * @param v1 需要被对比的第一个数 + * @param v2 需要被对比的第二个数 + * @return 返回两个数中小的一个值 + */ + public static double returnMin(double v1, double v2) { + BigDecimal b1 = new BigDecimal(v1); + BigDecimal b2 = new BigDecimal(v2); + return b1.min(b2).doubleValue(); + } + + /** + * 精确对比两个数字 + * + * @param v1 需要被对比的第一个数 + * @param v2 需要被对比的第二个数 + * @return 如果两个数一样则返回0，如果第一个数比第二个数大则返回1，反之返回-1 + */ + public static int compareTo(double v1, double v2) { + BigDecimal b1 = BigDecimal.valueOf(v1); + BigDecimal b2 = BigDecimal.valueOf(v2); + return b1.compareTo(b2); + } + +} +``` + +## 总结 + +浮点数没有办法用二进制精确表示，因此存在精度丢失的风险。 + +不过，Java 提供了`BigDecimal` 来操作浮点数。`BigDecimal` 的实现利用到了 `BigInteger` （用来操作大整数）, 所不同的是 `BigDecimal` 加入了小数位的概念。 + diff --git a/docs/java/basis/generics.md b/docs/java/basis/generics.md new file mode 100644 index 0000000000000000000000000000000000000000..164794b674e502c9c42833a79fb3f15e1d706fb9 --- /dev/null +++ b/docs/java/basis/generics.md @@ -0,0 +1,29 @@ +--- +title: 泛型连环炮 +category: Java +tag: + - Java基础 +--- + +泛型相关的面试题为我的[知识星球](https://www.yuque.com/docs/share/8a30ffb5-83f3-40f9-baf9-38de68b906dc)专属内容，已经整理到了[《Java 面试指北》](https://www.yuque.com/docs/share/f37fc804-bfe6-4b0d-b373-9c462188fec7)中。 + +《Java 面试指北》的部分内容展示如下，你可以将其看作是 [JavaGuide](https://javaguide.cn/#/) 的补充完善，两者可以配合使用。 + +![](https://guide-blog-images.oss-cn-shenzhen.aliyuncs.com/xingqiu/1&e=1648742399&token=kIxbL07-8jAj8w1n4s9zv64FuZZNEATmlU_Vm6zD:HyfLWy5gNC5F_XukPYrlj_a4EJI=.png) + +我已经在星球更新了 **7** 个高质量的小册： **《Java 面试进阶指北》**（持续完善中）、 **《从零开始写一个 RPC 框架》**（已更新完） 、**《Kafka 常见面试题/知识点总结》**、**《程序员副业赚钱之路》**（持续完善）、**《分布式、高并发、Devops 知识扫盲》**、**《Java 必读源码系列》**（目前已经整理了 Dubbo 2.6.x 、Netty 4.x、SpringBoot2.1 的源码）（持续完善中）。 + +![](https://guide-blog-images.oss-cn-shenzhen.aliyuncs.com/xingqiu/image-20220211231206733.png) + +如果你需要专属面试小册/一对一交流/简历修改/专属求职指南/学习打卡，不妨花 3 分钟左右看看星球的详细介绍： [JavaGuide 知识星球详细介绍](https://www.yuque.com/docs/share/8a30ffb5-83f3-40f9-baf9-38de68b906dc) （一定要确定自己真的需要再加入，一定要看完详细介绍之后再加我）。 + +星球目前的定价为 **159/年**，即将调整为 **199/年**。如果的认可 JavaGuide，相信我，并且需要星球提供的专属服务，那欢迎你加入我的星球。你可以添加我的私人微信领取星球专属优惠券，限时 **100/年** 加入。一定要备注“**星球优惠券**”！ + +![](https://guide-blog-images.oss-cn-shenzhen.aliyuncs.com/xingqiu/image-20220211231926486.png) + +**用心做内容，真心希望帮助到你，拒绝知识付费割韭菜。加油！！！** + + + + + diff --git a/docs/java/basis/images/checked-exception.png b/docs/java/basis/images/checked-exception.png new file mode 100644 index 0000000000000000000000000000000000000000..aee555bb4362580b921ea330dd97413c1d9595d6 Binary files /dev/null and b/docs/java/basis/images/checked-exception.png differ diff --git a/docs/java/basis/images/image-20211213102222601.png b/docs/java/basis/images/image-20211213102222601.png new file mode 100644 index 0000000000000000000000000000000000000000..2c70eab885e7589c1c461d27423f15dced240a61 Binary files /dev/null and b/docs/java/basis/images/image-20211213102222601.png differ diff --git a/docs/java/basis/images/java-se-specifications.png b/docs/java/basis/images/java-se-specifications.png new file mode 100644 index 0000000000000000000000000000000000000000..63a5755cff64d195c01f161b2f877a47bf69bfae Binary files /dev/null and b/docs/java/basis/images/java-se-specifications.png differ diff --git a/docs/java/basis/images/java-value-passing-01.drawio b/docs/java/basis/images/java-value-passing-01.drawio new file mode 100644 index 0000000000000000000000000000000000000000..75e85435c838c7c2467f5e0210b90ca0f4ce3b66 --- /dev/null +++ b/docs/java/basis/images/java-value-passing-01.drawio @@ -0,0 +1 @@ +7VfbjpswEP0aS+1DKi6BhEcgJG2lqqtut7vtS+WAAygOzhrn1q/vGEy4ZndVKbsvVR7iOR57xnPOgEGmvzkuON4mX1hEKDK06IjMGTIMXdds+JPIqUQM3VZIzNNIedXAbfqHKFBT6C6NSN5yFIxRkW7bYMiyjISihWHO2aHttmK0HXWLY9IDbkNM++h9GomkRKfGpMY/kjROqsi67ZQzG1w5q5PkCY7YoQGZATJ9zpgoR5ujT6isXlWXct38wuw5MU4y8ZIFEfua5d/uKLF/Z/78093NXbgYqV32mO7UgVFgoamFXB8FY+T5yJkUyBx5MJgXiPsZ7/FCEoMMm0Jwb8nlAcVJVc1+3MlTeSuWiVFecOqCg25vQRhePQ+juPiXoWbIgZhTNNVk/CpUGQYycEzkWqqS50CGIEe5QSI2FAAdhrngbE18RhkHJGMZkYmklHYgTNM4AzOE8hHAvT3hIgXiXTWxSaNIhvEOSSrI7RaHMuYBdA4YZ7ssIrKyGlgULwn1cLiOC7wbHKqghK3byq5ckGF6xa/YU2CRMhl7ZMpt8zURYaLO1ae74g7yJscGpOhfELYhgp/ARc0aEyXFQ61kfaqwpKlihWHVPPF5q1pfMFASG5bbd5NnHv/z6zG4If6PKIzu3fVIt/t6UxKSVXmJiAwTRNRTULbbGO+kTNwAOYFS7NR4X+0O2ZYBlOC6Oqr51C8w3pBYTHGeV3KrulrvEtbUHNC8WhE7DHsChZlo4iw17ZxVj88B1i9S7KgWUY9bc4Bwe4Bw62qET69HuP6fcCBcaxEOHWb1KZ+8JuVy/QXK8y3O/p3yZcE3vCdcY5Dvcvc345vokUUmQ3w79sTE9lUaXH/zDjfGV+pw/Azdb9zer0R3p72H3uCv291Db/BO8UkWufLqLW9XsrRp+RTEXPThBg1QEn56UFeqwvgpjQ9WZc6OzcnZqbKOqXhojBurwKoXSeO8JoJbvsqYcZGwmGWYBjWqyJN+T1MHJ2c7HpIXPBGhAjERz/ZSXwwNtq0nyOaEwgVy3054SAEqwg1LiwZVWhu3tda9BJbHVGua3xmdbbqSHXf2KavQ2wekgU8Nt610yC9na3aytawnszK7WbXcYVDGrxvjXP6hXgGz/nAr3evvXzP4Cw== \ No newline at end of file diff --git a/docs/java/basis/images/java-value-passing-01.png b/docs/java/basis/images/java-value-passing-01.png new file mode 100644 index 0000000000000000000000000000000000000000..f871d26e52744788d324e743635828f5a8c98e33 Binary files /dev/null and b/docs/java/basis/images/java-value-passing-01.png differ diff --git a/docs/java/basis/images/java-value-passing-02.drawio b/docs/java/basis/images/java-value-passing-02.drawio new file mode 100644 index 0000000000000000000000000000000000000000..2ebb067432610d23ec3cc33fe609d5b3cfe75152 --- /dev/null +++ b/docs/java/basis/images/java-value-passing-02.drawio @@ -0,0 +1 @@ +7Vlbc9o4FP41mtl9oGNZvj5iAnSzvWQ2k2mzLzvCFrY3xmJlEaC/fiVbvjuEUmiTTuEB69P9fN85OjIATVa7OcPr6D0NSAJ0LdgBdAV0HULNEj8S2ReIDi2FhCwOVKsauI2/EAVqCt3EAclaDTmlCY/XbdCnaUp83sIwY3TbbrakSXvWNQ5JD7j1cdJHP8UBjwrU0e0af0viMCpnhpZb1Kxw2VjtJItwQLcNCE0BmjBKefG02k1IIq1X2qXoN3uitloYIyk/psPi72gzG7OHT/q7PY4/hNtr+HGkF6M84mSjNqwWy/elBRjdpAGRg0CAvG0Uc3K7xr6s3QrSBRbxVaKqwwRnmXquNpwXHgj3I1VYxkkyoQll+QwowMRZ+rIRZ/SBNGos3yGLpajpb1bt/5EwTnYNSG1+TuiKcLYXTVQtKiWlpDjSNQVsa2J1S2FRg1RkKxArMYXV4LW9xYMy+deYv29uEgj9qSJlPKIhTXEyrVGvJkQTpbrNO0rXysD/Es73ypnwhtM2ScKGbP9Z9c8L97LwxiyLV7tm5dVelZ4kIaMb5pMD+zSU52IWEn6gHVRuJY1wkFNGEszjx7aTDtGTdx0zhveNBmsapzxrjHwjgVoqut2WimW2PeuZ5iNodpRRLKDWSbWT06VjDHiulXDpXTRfXK0p678NLStGWa6KsWigo/WurhRPofzFcqm/gakJvCsw1uWDMwOO/ns5vFhtMUPR/gfECwIDk9hD8cK1bISt88QLRXpJqtEPFnAoWJgXixVaz9Q/ZaywXnesGEHYOYdfQrSwLhct8lgxngJ3+hJjxXJJLH8wtwhsd6EdlOrJsWIEkdmPFvb3jBb2NxOOtCHCc7I14FjHUiwsyNs8tplIaUo6tCkIJ3GYiqIveCEC9yQfsUjNx6piFQdBHuWGhNOJfKIy5pIeQ1NbVSEPuueRgKF33drunxjGgAT0S0kADmng+yf3JnECY8gBHX2BrDMd1si129Z39Dd9F3RQ3/yVq36L/QP6Mc3+ukuI9U86mf1xd3Pnz0ewb34ZIIX/TMDUAN4EiEUXIdMTD7McGV/jRzyXl97SwRbsGG+FlvDW3E17DmvITM4VczrA0eT85VTFNGIFLgJj84V6boIXJPGw/xDmeHfyhiNbqtyQmJd/8zG5yAGonHuEtK5kzyBA6LbdX0cD+aIz4P7wDO6/0e4+/MnuJ/NJdm3S+/V79nZ/zNWepMFYviOp7RngLKrCQYN5id9gLthMc0QcD5UeyvciejNdrHLHIl3Un8sXyS7mnxvPzW6iWPeShbJT96w35XfwPUL+qZjupIwD1Pd5bvBoHjjIvy7Z7CWHvTjWGaHInlWnA0mm4XRPo/Y4RXbdG+eEdHNQe+jn195rUxLSzqOk7jgXVpL5S0kvTUmjc0mpN9CFtfTsJdivTow6i0LFZyCxUn2zNU5Pv0CDqQVcE3gamNrA84BjNC5WxdDt6V7HfeuJ9OkoVZdqgUZbLQP3KdPqq/6E+5Qo1v/DFGqr/85C0/8B \ No newline at end of file diff --git a/docs/java/basis/images/java-value-passing-02.png b/docs/java/basis/images/java-value-passing-02.png new file mode 100644 index 0000000000000000000000000000000000000000..556bcc1c308872bd5164b735216333b483637239 Binary files /dev/null and b/docs/java/basis/images/java-value-passing-02.png differ diff --git a/docs/java/basis/images/java-value-passing-03.drawio b/docs/java/basis/images/java-value-passing-03.drawio new file mode 100644 index 0000000000000000000000000000000000000000..263a457cea2b7df2b03ae5925d0483188f6d452b --- /dev/null +++ b/docs/java/basis/images/java-value-passing-03.drawio @@ -0,0 +1 @@ +7Vlbd+I2EP41Pqd9IMeWfOPREMh2l223zTbZ5k3YwlYxFivErb++ki3jKw7pQki7PTygGY1u8818GtsaHC52dwwto480wLEG9GCnwVsNAMPQbfEnNftMAwxbaUJGAmVVKO7JX1gpdaVdkwCvKoac0piTZVXp0yTBPq/oEGN0WzWb0bi66hKFuKG491Hc1D6SgEeZ1gVOoX+HSRjlKxt2P+tZoNxYnWQVoYBuSyo40uCQUcqz1mI3xLH0Xu6XbNz4SO9hYwwn/JQB06doPfbY/BFM9oj8HG7fG7/0QDbLBsVrdWC1Wb7PPcDoOgmwnMTQ4GAbEY7vl8iXvVsButBFfBGr7jBGq5VqHw6cCnPM/UgJMxLHQxpTlq4AA4TdmS+NOKNzXOqxfRdPZ6KneVh1/g1mHO9KKnX4O0wXmLO9MFG9wDWzISoUe0BXyGwLYIGtdFEJVOgoJVLBFB4mL/wtGsrl7e7/6et+bD6YCXE/333++OCaH/xNz254Gwci/JRIGY9oSBMUjwrtoMBDF1JhM6F0qfz7J+Z8r3IJrTmtYiRcyPZf1PhU+EMKN1Yu3u7Knbd7JR3FYEXXzMcdUaYczxELMe9wh7KTPuhElOEYcbKppmgbOOlQjzG0LxksKUn4qjTzJ6koAgXm3KMCxbSqefWMuWvXwiJbvwiSw0FOipsuh1bS1o65TC2a7q2IKPvrmuYdvVUaE54wAHC5KzpFK5T/O4LohPygjSzNG2n9kWy4Y80FP+bzi+1mS2QDrsAWsxm2/Va2CJz+VO+M1NPZwrEqoIImVRhtVGFdiims74Mp7CZTtNoZzrmp4lR0urZ9kXx8ilAS/p+SxdWc399GnqPlpOxfKClbYXe+GXaot8Gegq1r8iY5DWLhQV7FsYpEQhNcg02pUEzCRIi+wAUL/UDiQUT966mOBQmClE3aAqfGMKKTcAmPqaujKmox+ucJARM0YqBJzGZLCIBLhYBxPAZWS5T889Rf8XWAU8jTyaaswQml4MiWulr+BxZ2A7Mt/10wheKJ7yzgQ9u9sWrwA3DTQgImbCGBg+XZ72b3P3c3tx4T/KureOO6ZXyXR8/OHUvMVjQBadEwuNU80Fo0XJk0sCFow2kjjb7tQHQm0nBqUXD1Qt75PsgCvvlCvmvbZy/ks4w0nsnIK5fxr5ORbq2Ec1sy0nnNjDz+MuWCFdyENPVvh5tfqaCrhYLdEgmvXMrlRUDXC3GcBJ78siAkXzqXZE++iPGm+gwcjHeEfym1S6OEVAySwmHMs1fK5ctAeCKxl9C2OtL+ZdVis7yrsUd2TGXUURbW2arOQpkbGvO8tFoFLytW64/BVsX8m4vVx99B4gS/7Z5+ZZ8eJpt36MN80cvTu5QZ8g6zNG+ojUxtMNT6jrrVBqIxTjXee7RBd/IbXpnunmdUwxaMmjJi49WIKS/QvljT1QQ4Yv18qWwZsYM+1Lzm+9K38Y4kRlMcD5A/D1N9ffHSKxNbySXyHaS/dE4ukoHKtXtQr5P5ER5uSffj1AyNxrN2Czu7LQlrvPyeFmLxHTSL1+JzMhz9DQ== \ No newline at end of file diff --git a/docs/java/basis/images/java-value-passing-03.png b/docs/java/basis/images/java-value-passing-03.png new file mode 100644 index 0000000000000000000000000000000000000000..b002a57d1a3ee99d178bb5f98fed1143022e5671 Binary files /dev/null and b/docs/java/basis/images/java-value-passing-03.png differ diff --git "a/docs/java/basis/images/java\347\250\213\345\272\217\350\275\254\345\217\230\344\270\272\346\234\272\345\231\250\344\273\243\347\240\201\347\232\204\350\277\207\347\250\213.drawio" "b/docs/java/basis/images/java\347\250\213\345\272\217\350\275\254\345\217\230\344\270\272\346\234\272\345\231\250\344\273\243\347\240\201\347\232\204\350\277\207\347\250\213.drawio" new file mode 100644 index 0000000000000000000000000000000000000000..bc9ad63aee55114b73a3f727f9f17d2b5f6f267b --- /dev/null +++ "b/docs/java/basis/images/java\347\250\213\345\272\217\350\275\254\345\217\230\344\270\272\346\234\272\345\231\250\344\273\243\347\240\201\347\232\204\350\277\207\347\250\213.drawio" @@ -0,0 +1 @@ +1VpXl+JIsv41PM4eefOY8l7IAII3eQRCHhl+/U1VUdNVXTVze3d7pneKOigz0kd8YTLEBudvs9yFzdmsk7TcYEgyb3Bhg2EoilDwsVKWVwrL0q+EvCuSZ6dvBK94pE8i8qTeiyTtP3Qc6rociuYjMa6rKo2HD7Sw6+rpY7esLj+u2oR5+ongxWH5mXookuH8SmUw+htdSYv8/LYySrGvLbfwrfPzJP05TOrpHQkXNzjf1fXwWrrNfFquzHvjy+s46Q9af99Yl1bDjwwoPZ+WDyU6+NaJbDAtJH9jf3vO0g/L24HTBJ7/Wa274VzndRWW4jcq19X3KknXWRFY+9bHqOsGElFIvKTDsDyFGd6HGpLOw618tr6uuS70h0d521d97+L0T/aPPSERdnk6/Ek/4neGQ6Sm9S0dugWO69IyHIrx4z7CJ2Ty3/t94yosPBn7bzD5uckxLO/PlTYYVcLtcn0TVh/YT7X3FQ9cVlfDb/0LAwHsgDLN/K0RlvLn82WW6I3wr0s4hm9UuNXo+56Q9rrkG/k74X8T7Sqn6VwMqdeELxKYoH5/FGNWlCVfl3X3MhbPspSK4/VQQ1df03ctCc1GyIqV/poO8fkDCsa0G9L5z3HwWW7PAdRTtZ62BSOf9embpqLsk3Z+p6Vv4366pPFfoU4rVp6NKPlz1Yv4QfWifqV6EV+o13dSgLa3eZFAlm2hxeZfncWKz/8P5B814hO0qZhJo+yzMiRhymTx95Dv6gHyo65g9Tf2RSFexYb8C0eZ9x/s5+gHTn6nIBj5WUGQLxQERf8qDUE/C+ef5XHIH1QJ9leqBPl3eZyNSG1YfsOBjUhuWHYDmLXASBsgbUR6A0HOUBuR2QB6A/AXCtgwxEYkNhz3pADYB/1VTitFEzKlv9JslqLxkPoLnBbGflRKAv/VXutN2f9enYTs6pbgxfqRb9Xjc7qXijB/qC3P2k/UZeoHdZn5L3X5ZSjounB516Gpi2ro3828XQnvghvsI05w4rv4/t/rDwuvO/iGk9+P8p9Dh/pDQxP951bmX3EZ9v3XJuGfHbCS+P9axEr/XZ5ivZrEsPtq8jl+w766BWnD/le2H4pi+Cjkj8Ks6ir9TvJPUlgW+RqIxVB06RoIroIt4MUfPBtuRZK8WLqvUPXR+n0dgf93odtbqPaGFPoLpJBfIAX7y7zEPz1XwPygtSd/ZeTG/BUG9V0Exm4YesO8C9feZu/eqV54WzH++v25g6b6P2Sb/7JLV8SQBIl8YdCZOI0/Xbp+htmmvwvZkF9+j2K/wMkf8L+4veQ4fzdwRhil5bbui+dVNKqHob7BDuXawIXxNX8RwAdXuf59YSSH+gUpffOae82KeRUb97IkeKMibxRYTsIhhFB9rWJSU+UbjC/2nO1OiC7nNYB/lrc7i7scltS1ysPPET4FYXtTjJUCAstzERV0PRFTDuxRJ5orSrtUoofKyXrusjvNFXOlzwiqF7XtWJMvuYmtiY2D+JdCKXzZ2/mSdMR0MDvK3QQcb+vqfDk7Na7kyh2I7h6IGmOeJIYUmcVnma21ROEG41j8fkngcwkDeIAHLJHDDZZodltSdHLHIzwDJ2un0obQouV4MR29r4ArA34LlrN0TDNr4ATAd9zClX6WuTm4TGbtHpTqETnOBNopzk87HEeOQGUEXdyfSYaIQ3AgbBrQsRBd0uWi3FcELRkoGTDmhxjt0uk00h6n5EIMZSZ1rGUkiSSRam9rE5BLS3OKSaOBTciJhwbmkl8LONlk25yRBWLrHEEAllUoh1kxKiIAHqwMBU7GADLQXvSWOnmtNKkYMHHToJA76CaLJvkWz8SdAzkBTtOZXeAw7izkaMxx92M9BKgoCrmdXlGrUCaDAd0Zu5SGsZsXLphUmjx5oUcI0V3ZN5crbZjTxPfdwNh0UAeQA1xwfrQXzdguOe9PQXpt63M5CSM4U/u2f3gC0QE+5i+7R3AV7+BK2FSzFA+2BmdG6c5Kmx8vDt8UDIKOnHYecWL2zGULdAioPXF1jwbJmkhnXQB/mYQ503YhNKVcFlm6sHuAeuIZfNnLQLlhj/SCmpNqgs5k0H3xaTbm2vIZ6AgzA4cYZLnW89ZcuTrk4xWflApUBOishprbSNXBrVhtAMbRWyCRqEJzDKvr/YPUS2aPgZGwjlJ6t/HJuHPCZFT3Gkbbkinxd/Ye448ZSkBl9v0h5xfudaJLSpP7adHmcTRsK0bvu0cDW1CHRIMDM5TjnvGrpSJnswiuB48AWyAyinHNxUYr45rh3MlG/GW8xjHcMieyBnV1a84UrYAUGNykmBHbBQml78OePO/pFzaJYnUiosmvgaQ+Fk8B/MNYkrhahNsKQ8fU1qvHtgdyLukFJ+ZiHFzyOMEWxdII+XS/jsnoCPSyXZXK8ZHbyhL0aEVxlYHHtOxMeg8HAQE30rtQgxa2W2FaEfIiDkFFjo/ALeVcpZL65mcxtIxSgk/BggOCwJWAadyxsWSFEbeCWZg0DaCHlOZGubrw7Ft7QR74zOSPJYpoQrpAVRLcGohQJ41UQvIxog27Lqgj5ZsdXWk1Qe7hBuC/y06mFQb3VmSYmLlFna360QnOPZWx2irsfXcNeqdzOiScueBhGMHBRO9i4CNCI9XSgw1ieRxmD70EiQ219eLM9h7pnC0aea7LgeyOL9C7SpnWsA9zC4KdQygV99DqJlPyVcbQocOTkNsbcVv4GyrL5qD2uSNf6jJemajVacNUFqgJYRuO59jh/VN57gkG1yOjR7is4cLCVbw9wgAhGwM+50s5oHTxkNK6hl7tQfPZG8bt5m48iarN7VeBUnd7r3hhqMKKT7te22oEf/B3sIqp+klohda8FffZJ/pbOIwP/orYCkty2AkDDb43MUomguvtZZRHveBT4RRC71nCUsx1BXnFs9SOAY3PQe44YtSpmYuSrHOLvLaucn5+zPjFSYlzBL0Il/Itiop0/CBJxc/nGgvM4rIiX97q0EOzIMUZfyeLVH7NW7I2bRldjqaDibwts3doozNbK2stFC8nSUaBPo++dlMNOZ2V8ynmB3Hcot6eYEHgTbsjWl+xGHSvIOAew/rd9Pvp/shPxew/anGNwaVgmTCiwzrPD5kSD+TwIdtXN9o6MiI1qdsgOMYTkx0ExdmRIksNCLqCoc0xFwfpeGn8lG7q0mpIBc6f1ytbQvwYHqi8mjSbH5TGW1exzMWUYuQs3wvyvGX7du3YZ9yOmyVpN5gV2dbJwrDW/oJwQV4w02BRmJMiE3nsIjz1ezpi9tOJlxEYC3KV2wd9agMacVptVcTrCvb9YbzZ8LmuTR2L034RKr9teOAeUNob8A5d3GWfRwcZdjKkrRD4Wop046Gtcq6llB3PrdKIi5TbBvws4BQbVy6khK9MXEsg02Kko3iIKKs7Vuedoaqgv+D+bA/WINqVGHKY7A23fWJ4WwhN84pWEppVhOjV7eFWNvPA9JhqhPq4mtud4ygjYa78oFxB1qTTnWiZQq2R4sacTy2MhDEO6g+XxO6dkLYZljcYduqpobWN+/XgOAC1hHC3nPfGlW6PBZ0eoDgiZosUJ6grhW4Imoi7gWi5O2mFreAT8Dvvey5blQ9eaXDPUI+A6T3ttjdGUJx33f4hGMMR+D5J9ncR9jcm7RbKKyP4E43KohDNSc1frmU9o/IFK5OCy1xmnHOeBwna1fy2cCfcapNx0JC+YKntsanisNCRxLrbVXXcExYF0NHWH/oaIaSjZ5SryeT8otMK30VuRNIrBj1QgN7TJxdyynUKitmG9pE5m8VN3KrsArAMRU+B7zxK11vjgHyRythxnIPQWQyL8a1cHQxqzA3PKsvCB+fFipDwEA4I3Kn2cMwCMtVGqnBrHGfPjYqcU0rjkWksrLsaoJOj6J0Tb3Eh7qR95rFo7Y+8cz0NB7hb554fmCCaD2bNKHRj5/16GGgXrRwQFJNXe6PIaP105/0geYj+aVAPpYSs8tzhC6se+mtRQQvFKSEArfYoLjVyWvNvEsjCDIxUUoF+DaBqtQcYz95vqOqZfrcGcvqtjU/3FTgyO5IXxwjZclWO/DRi0Qrb1cgrWejI5PWWHkxoayX1sk/xnVgAeRnGRM6NAE11m11ju9xCgl4+2hgoJnIgcaHbY0em0L0D9DFqTQcIgoNzzkWcTpxy+sgbwg3vku1kNjQ+wQaDg+WaNPmaC+6WPVFTzKBXNGBEVJKdixeobED7StfmkTZanKOKo48sg18Q3ABeNYw/2mE7bGGsZEOKxGG+SnWVeOWsnTmlc0rMN5fiMPXaRhNOw3htjmefmWRI5FzBTO9iPDN8a131oZ3HC1MivOkUNdh3aBMDvVpMz7r4kz+sIXGEU72U3M4EYkcr2zxtxoDFXbfAv930VmsMoYPGfwvcWuIbIuRXGT8yFZWiwWpiZ5UIrtUh1VwxPLXPri9h/grBS82fxyTWjcqkr/7YndqSP4Edkdr7Y8xb21AhK6akNefk+0slXGoMLxIsPjY2Fw5OrJbcSc55QdIan5Ipgq9O2kI98iLmWOZh2tTQe4sMwPUQbwV9savoIAirZsfngGrRXgeuY+PnpB0vrE57u5pQ7SIvncFbFIATnHFJJr/PLoKKxpXPIh6vC0586SSb2MWECu/NlEwXJlGKIn8mxC4WGkJo1Wkai8vFTg9W1SYw7vNYL3REQoUBVd3sd6KhHOVg5+ecBG+dXLMMDAvvRsaYJJkqtOWlN7ROY7jYavV2jpSw6MZ8F4rdKc9oNHJ2nXJfozl2rs3bCd5cJIQNHo5fx/2oHEzQVq1SyOWxGlwtFxp7xfctCWz3FouTdF2sGwntGhe6hsJT3o20667nT5psFv4Jhy7v6mlNTF5VgEdUQ1kLZcqqVZ8vwnnZp46wU6G08hyoqw0qKFPRfddcmt3k3bdVtGpovAig1EJGj+SA7q9DEZj5ZPGBvsMTGE+y0qQHVaTz8cID4+bH0a52tMEb7hOyW/B8uTkmZ3Glvh0cQj5oJQyanc4LVyfAXGMoA1khkeMj6JcJ1FCMbmBRp61emedcFI4cnue9fb8WYFn9Bj+vF15Jrc5lvEcfAFoJtwuXmw4vPaIOyCZw4PUg7drV/+uo5ai7M+3dQY2AJNsHTFKH4NgIhzLl3JqH0Q3XDkR0RMDsyUOLgIsj4ew+WjC3FoqrddrXnJx3I9EGZX9xFEmlls7hJS7I5sNIBwwndb5xlU476Cu4/uXy6+32tquT/FFV19v5T8lwfJfgwFnqc4IDY75IcLwRf366Ef+c4VhfLZIbwL+8P+Q3LP182cjBgvRCAVo4hvL6m7H3easfyJtRzfya7PqUOoNLCes7TpHZMMi6/ttSr8usiTR8A8j/0dT0H+R03hZ/l7imnvV3aR/u5fPdDxfwv+LFCPrdS1Gc+SLdzXyVYfv3E2xrbuT3X929vgj79ttFXPw/ \ No newline at end of file diff --git "a/docs/java/basis/images/java\347\250\213\345\272\217\350\275\254\345\217\230\344\270\272\346\234\272\345\231\250\344\273\243\347\240\201\347\232\204\350\277\207\347\250\213.png" "b/docs/java/basis/images/java\347\250\213\345\272\217\350\275\254\345\217\230\344\270\272\346\234\272\345\231\250\344\273\243\347\240\201\347\232\204\350\277\207\347\250\213.png" new file mode 100644 index 0000000000000000000000000000000000000000..fc750c3f4bab8976bc8e7e5a28e4182786bc2cea Binary files /dev/null and "b/docs/java/basis/images/java\347\250\213\345\272\217\350\275\254\345\217\230\344\270\272\346\234\272\345\231\250\344\273\243\347\240\201\347\232\204\350\277\207\347\250\213.png" differ diff --git a/docs/java/basis/images/shallow&deep-copy.drawio b/docs/java/basis/images/shallow&deep-copy.drawio new file mode 100644 index 0000000000000000000000000000000000000000..95242394fd8f6a5764da6ebdc2f106a588dc657f --- /dev/null +++ b/docs/java/basis/images/shallow&deep-copy.drawio @@ -0,0 +1 @@ +7Vxbd6M2EP41PJKDEAL8aHxJu2fbTbubs92+9GCQMRuMXCzHcX99BQhzk2NnbTDeED8EjYSE5puLZgZbgqPly31krxa/ERcHkqq4LxIcS6oKgKKzfzFll1JUoHOKF/kuH5UTPvv/YU5UOHXju3hdGkgJCai/KhMdEobYoSWaHUVkWx42J0F51ZXt4Rrhs2MHdepX36WLlGqqRk7/BfveIlsZ6IO0Z2lng/lO1gvbJdsCCU4kOIoIoenV8mWEg5h7GV/S+6YHevcPFuGQnnLDdvFH+H2Gn1bqs7cMjM34y5cHGaJ0mmc72PAd86elu4wFEdmELo5nARK0tguf4s8r24l7twx1RlvQZcC7vcBer/n1fsdJ4wlTZ8Eb9Wfn23nGEcUvBRLfyz0mS0yjHRuS9SoKZ2wmWjpvb3OcoMb3tyhgBA0+0Oay4e0nz9nHLjgH38BNzagxD7tMnHiTRHRBPBLawSSnWjl7FdbKx3wkZMXZ9R1TuuO6YW8oKbOc8TDa/cXvTxrf4sadBlBGGL8Uu8e7YusBRz7bPo448SA2a7KJHPyaMPHtUzvyMH2NT1o6MGbOq1hHOLCp/1zWxYvDlj13SQn0gO3AmhPGhCKg+r8bknXI6wSSIRugwtVL3smuvPj/CkdrEoIRWe2yCdkDpnOmI9pQtrkfBCMSkChZAbo2NudOPIhG5AkXenTHxLP5ZdTTQKiknQjUtRNkGlvUTtSYcprXVc47Ra3op2K0rJ+DU/UTdEs/B83qZ3d0c47ij1A3kz++sQI9/buUzpY9KkQCnTVa1VkgQP5GjicDo8xMVcBMBOrMBNmZ7PLcVBvSo6HrRpjxtTN65CJsuppIj0x1BhM9ugTGQK0ojIHqGCuCI2hzCgOPQezseZGjmFmRGrDZveuVHf64eDwkZrYgHel05SWOCQ3DhJYlo4xtSEJcEQROsgPfC1nTYUjHXtSKEfZZiDfkHUvfdRNvLxLF8gngIlKD1Lvy4QhqddugCeys2pjYaD+NndXM69tZUVDd29nL2VkEr25n9d7O3p6dRcq17awokrkJOwur2Tbj6tm2TLnfabYt82lHo3nEEx8dieaRKKbrs21naWfnkm06qPG65WRbnlzL9FNrWT/hqfqJuqWfR0PIPtvWgM5C0Zm21WQbEgWBbwMeKiLgpQmShopk6rd1BiWs06cxPJrCt8otDxhcRgS02glVHVz5hKpr1zDcZ1hZdKqV1btlZW+28A6riW14YsKluUDgaDDe51veZJYq6RZNhHCr6RZ0tELfp1uunG6p+zJR+bBdX4au4csKQcg+I/Ct2Hcg/DjDB5o36gPNn8UHCgNukQ/UG5N1pbeQN2chkVqP+dq1kIKT00SXLCSZKL4wLckypIkpWZo0GHcUmkJgpqkXis0ryW7RAUgUmzcHlOAAFANlSBZ4z0AZWgUpQYWnZaRETq3PokjNZVEA0GppFMFLAE0Z1tnfi810GD19VT/ubP93b/sBfJIFNQ4GnzWSBsyuGtJAk4bme9bbitrKquDtuHYRU2/2LAqqvBTYwOZKs2Jm1pl3xdLsscLsQRCKkZdwnzxZWgy8xOaAu+/LBV7JrcMosneFASvih3RdmPkhJuSisk/BcVHhAfL0xOEyQBXJSB8gl5P9Tn5cdM4vQvTV4YqF0MvOUfCyYWPFYbF16NSLG81ZB/22rYMMQOUbhV2wD03l+vvq9Gs2QwZtlqeFwJ//Jb0+rnrbGV2vhlUyuHpcJZKC2zimV1LGsrnnbitvqovZeX6yoq+cvlI5lVVDBHJTtVMxxke/PdlXBjpXGZB1kXVoytS65FO4/vMxwPo/4Wj66+PDo3N/IIVlMmc5kiZakssyEso0SWFNE8rwg/1s38e/2ZGBOItOkRKgMylJkK95Z7bUWBqM4iQZ8z5xXYIvlS7DnmAApWG91NsN6QjsGQ4s23nyEnp18YLXFhzorOSTzEnZwZ/Ea8tQEXunmrgJhPJwwcMoyx8QvIe2d/4l3/R28WPN/FdP0rAg//EYOPkf \ No newline at end of file diff --git a/docs/java/basis/images/shallow&deep-copy.png b/docs/java/basis/images/shallow&deep-copy.png new file mode 100644 index 0000000000000000000000000000000000000000..4839114442e7e9087c2a3ddf85f035d6efb6d187 Binary files /dev/null and b/docs/java/basis/images/shallow&deep-copy.png differ diff --git a/docs/java/basis/images/types-of-exceptions-in-java.drawio b/docs/java/basis/images/types-of-exceptions-in-java.drawio new file mode 100644 index 0000000000000000000000000000000000000000..f212b14339682f00e1de9af01ab033a3a2470be5 --- /dev/null +++ b/docs/java/basis/images/types-of-exceptions-in-java.drawio @@ -0,0 +1 @@ +7Vtdd6M2EP01PGaPkQDjR3+m6Uma9Djbdh9lEIZGRq6QY7u/vhIWNiDsOE0M3l2OH4xGQkJzZ0Z3JDDgcLG5ZWgZPlAfEwN0/I0BRwYAZte2xZ+UbJWkA82dZM4iX8kOgmn0L84aKukq8nFSaMgpJTxaFoUejWPs8YIMMUbXxWYBJcVRl2iONcHUQ0SX/hn5PNxJXdA9yH/B0TzMRjad3q5mgbLGaiZJiHy6zong2IBDRinfXS02Q0yk9jK97O6bHKndPxjDMT/nhmA0jm55TBZxH94/P8EpHPdvLPVsfJtNGPti/qpIGQ/pnMaIjA/SAaOr2Mey144oHdrcU7oUQlMI/8acbxWYaMWpEIV8QVSteGC2/Uve/8XOit9Ud2lhtCmUtqoU0JirTk1XlPcalZXJC+ZeqEbYzUpO5aiylCihK+bhExrKjA6xOeYn2oE9pMIZMF1g8eTiPoYJ4tFr8TmQMsr5vp26tc8Y2uYaLGkU8yTX85MUiAbKwaCjjEu5FyzbQKm9e7K5uNg9QFbKzeQgSs3qHSZmN2FiZVP5vyZ3VSYGvwcTc8wGbExN+hWRlVLDcyhiP5oJaypb38G2JIzrMOJ4ukQpQGuxiJ22oyAiZEgJZWlf0EfYDTxpGpzRF5yrcTwXz4IzLOgVM443p21IxzwDp1NUNrBUeX1Yq8xsAQpz61QGapWZ5KB6PxIAXIO71+K24NyVoVON4dl++zFAYCNL/CbiuXArSt9yNYdgKwuNLu9ng3jEEWsCUYtv442Hlzyi8WXjm41d36qKby6YQce5dHwDpbXEaTq8OT9NdPsUsvEmO7A7JaR2jqjuKoH1CUQB6o4kkkR2UScKXA97lSRh5tqWfQ7N/JAT2fa1eVFXQ+GHBsDqHTH6HAB75pYHANiXQqCnIfC44o/BA15Qtq12CTF/XlR7UZ0xjXFJ90qESDSPRdET+sJCPpDajDxE+qpiEfl+GiqrcC6Gz/fGwo95jmkXgYMVntOrAu5SuGXhMwfcHxHjK0QekBdGMW6xO4adYzeNnZ6lTjnyXh7FPCeErlvojkDnVMTLmqGzNOjuHlu8juDVNRvHy36bYeDY78sDggMAPkrCPeXIASjlT4gLUOJUAjpwD2t2KAAuwtN1ledUaldoNJN9Mk3vlmn6Ln3QaPqbHTllTnlhvi9wKBtCP0mkX9G49d9j8bZxmmM1cmjwXZ1LZbp/e+fKrga/pp0rnbAOQ+y9CJxAp55NrCAIQHX65zszx774JtaNWc7/KtbH/YF3LQm41Z77vulfZx/8Oo36l55UfI292j0MO0c8rNubdS6+wWJa1+Zg4AwC+kPFONApcYiKTcbqPS7rYhg4dWPQsBeA64NA3+kVefPRmPQTcm+RoZQypF7T5BvoOdOQoCT5jfKJVFSL3yn8uo0nT0Df3J/+ft+idhK1btOoQT1RmkQEt053Dnxu1ZFmvfDpJ8saUu2OY26E0kbhjVskL2756PPcHUeto7rfMNCPCvos4qHoN/JaLz6RtTXPfKCetaXMZ4gS3kJ3ArrmSQ/Uk707QvAckeeQYeRPOeK4xTCPoX11FEgnrndCO5v01ZSB1FTSIngCwf2a2dy5DWhZ0EdYELCsL5/Egyq6qpkJWRX7b2PbEPysPzTGljEYGr1uKpkYA3ExSSX9X9ErupVf/RnAIdKlZ6xgQM4/K/nJXIr6TZLC3hcNTGe5SRHO6sXVPP2XQ42MnhjTNUTeIMbPhtoNI56gB42+fuR4HSGFoBkmA+S9zFN5efCc7TuqnNt5HKS/tE+xAMq4CUcy1bzAq9olSmBVvQTiVriO+f5gJIqH7yZ35nr4/BSO/wM= \ No newline at end of file diff --git a/docs/java/basis/images/types-of-exceptions-in-java.png b/docs/java/basis/images/types-of-exceptions-in-java.png new file mode 100644 index 0000000000000000000000000000000000000000..4a07d44cc2881a9a8576ab978d8b08b69d135a5e Binary files /dev/null and b/docs/java/basis/images/types-of-exceptions-in-java.png differ diff --git a/docs/java/basis/images/unchecked-exception.png b/docs/java/basis/images/unchecked-exception.png new file mode 100644 index 0000000000000000000000000000000000000000..7c95b04a51754949d10e812ee42f813ba3cb78d1 Binary files /dev/null and b/docs/java/basis/images/unchecked-exception.png differ diff --git "a/docs/java/basis/images/\347\274\226\350\257\221\345\236\213\350\257\255\350\250\200\345\222\214\350\247\243\351\207\212\345\236\213\350\257\255\350\250\200.drawio" "b/docs/java/basis/images/\347\274\226\350\257\221\345\236\213\350\257\255\350\250\200\345\222\214\350\247\243\351\207\212\345\236\213\350\257\255\350\250\200.drawio" new file mode 100644 index 0000000000000000000000000000000000000000..3866134e65e0c21594473a8157cd2a993441d185 --- /dev/null +++ "b/docs/java/basis/images/\347\274\226\350\257\221\345\236\213\350\257\255\350\250\200\345\222\214\350\247\243\351\207\212\345\236\213\350\257\255\350\250\200.drawio" @@ -0,0 +1 @@ +5VpXd+PIjv41epw9zOGxmDPFIInSG7MoUcxi0K/foix3t7s96czMnd67to9ZhcoAPgAFcoPzt1nuwuZs1klabjAkmTe4sMEwFEUo+FgpyxuFZek3Qt4VyavTV4JXPNIXEXlR70WS9h86DnVdDkXzkRjXVZXGwwda2HX19LFbVpcfV23CPP2B4MVh+SP1UCTD+Y3KYPRXupIW+fl9ZZRi31pu4Xvn10n6c5jU0zckXNzgfFfXw1vpNvNpuTLvnS9v46Rfaf2ysS6thj8yQLE4p7dcZM8lifUwcU6PTr+gL/H0w/J+4jSBDHhV624413ldhaX4lcp19b1K0nVaBNa+9jHquoFEFBIv6TAsL2mG96GGpPNwK1+tP279dZq+vnfxax8XblDuHrmUp4hpXdpbkj31C/ZSgbDL0+G3zkW8dVwP880KL87IaX1Lh26BHbq0DIdi/Cjt8KU0+Zd+X/kKCy/Wfs7m39r2GJb310objCrhAbi+CasP/Kfa+6oRXFZXwy/9k4MAdkCZZv7aCEv56/mcJfpCEOkNx29YaiMyGyBtWHQjkhtW3DDciwKEZ4HZMMhGpDYc2LCwQGw4bgPwdThANgz6PjE8bfT9YpD2tut38ncK9FU9VllP52JIvSZ8inWCRuKjKmRFWfJ1WXfPsXiWpVQcr3wZuvqaftOS0GyErPrWX9MhPv+eJo1pN6Tzb4r+1Uq98PkyUBj5qk9f4Y6yL9r5G6i/j/sryvK57n6iLN+xGNqSZi0Wt6f54tbTFtBoGWGUltu6L4airmB7VA9DfYMdyrWBC+Nr/pTOB46vP9/MAcoiX8cOK5i5sG/ezGpWzKtMueeS4J2KvFNgOQmHECrrWxWTmirfYHyx52x3QnQ5rwH8sbzdWdzlsKSuVR7+HuFTELY3xVgpILA8F1FB1xMx5cAedaK5orRLJXqonKznLrvTXDFX+oygelHbjjX5kpvYmtg4iH8plMKXvZ0vSUdMB7Oj3E3A8bauzpezU+NKrtyB6O6BqDHmSWJIkVl8ltlaSxRuMI7F75cEPpcwgAd4wBI53GCJZrclRSd3PMIzcLJ2Km0ILVqOF9PR+wq4MuC3YDlLxzSzBk4AfMctXOlnmZuDy2TW7kGpHpHjTKCd4vy0w3HkCFRG0MX9mWSIOAQHwqYBHQvRJV0uyn3VoCUDJQPG/BCjXTqdRtrjlFyIocykjrWMJJEkUu1tbQJyaWlOMWk0sAk58dDAXPJrASebbJszskBsnSMIwLIK5TArRkUEwIOVocDJGEAG2oveUievlSYVAyZuGhRyB91k0STf4pm4cyAnwGk6swscxp2FHI057n6shwAVRSG30ytqFcpkMKA7Y5fSMHbzwgWTSpMnL/QIIbor++ZypQ1zmvi+GxibDuoAcoALzo/2ohnbJef9KUivbX0uJ2EEZ2rf9g9PIDrAx/xl9wiu4h1cCZtqluLB1uDMKN1ZafPjxeGbgkHQkdPOI07MnrlsgQ4Vak9c3aNBsibSWRfAXyZhzrRdCI0pl0WWLuweoJ54Bl/2MlBu2CO9oOakmqAzGXRf/DAbc235DHSEmYFDDLJc63lrrlwd8vGKT0oFKgJ0VkPNbaTq4FasNgDj6C2QSFShOYbV9f5B6iWzx8BIWEcpvdv4ZNw5YTKqew39sGRK/J29x/hjhhJQmX1/yPmFe5voktLkflq0eRwN24rR++7RwBbUIdHgwAzluGf8aqnI2SyC68EjwBaIjGJcc7HRyrhmOHeyEX8Zr3EMt8yJrEFd3ZozRSsgBQY3KWbEdkFC6fuwJ897+skmUaxORDT5NZDUx+IpgH8YSxJXi3Bb1dAxNfgfbHsg55JecGIuxsEljxNsUSyNkE/365iMjkAv2xVUjo/cVpagRyuKqww8pmVn0ns4CAi4kd6FGrSw3QrTipAXcQgqcnwEbinnKpXUNz+LYWglJfgULDggCFwJmMYdG0tWGHErmIVJ0wD6SGlulKsLz761F+SBz0z+WKKIJqQLhJLg1kCEmDRSCcnHiDbsuqCOlG92dKXVBLmHG4B/LjuZVhjcW5FhYuYWdbbqRyc491TGaquw99016J3O6ZBw5oKHYQQHE72LgY8IjVRLDzaI5XGYPfQSJDZE68WZ7T3SOVs08lyXA9kdX6BflTKtYR/mFgQ7h1Aq7qHVTabkq4yhL4YnIbc34rbwN1SWzUHtc0e+1GW8MlGr04apLFATwjYcz7HD+6fy3BMMrkdGj3BZw4WFq3h7hAFCNgZ8zpdyQOniIaV1Db3ag+azN4zbzd14ElWb268Cpe72XvHCUIUVn3a9ttUI/uDvYBVT9ZPQCq15K+6zT/Qwvh0f/BWxFZbksBMGGnxvYpRMBNfbc5RHPfVT4RRC71nCUsx1BXnVZ6kdAxqfg9xxxKhTMxclWecWeW1d5fz8mPGLkxLnCHoRLuVbFBXp+EGSip/PNRaYxWXVfHmrQwfNghRn/J0sUvk1b8natGV0OZoOJvK2zN6hjc5sray1ULycJBkF+jz62k015HRWzqeYH8Rxi3p7ggWBN+2OaH3FYtC9KQH3GNb/Tb+f7o/8VMz+oxbXIFsKlgkjOqzz/JAp8UAOH7J9daOtIyNSk7oNgmM8MdlBUJwdKbLUgKArPGKOuThIx0vjp3RTl1ZDKnD+vF7ZEuLH8EDl1aTZ/KA03rqKZS6mFCNn+V6Q5y3bt2vHPuN23CxJu8GsyLZOFoa19heEC/KCmQaLwpwUmchjF+Gp39MRs59OvIwwcKHK7YM+tQGNOK22AvG6Kvv+MN5s+FzXpo7Fab8Ild82PHAPKO0NeIcu7rLPo4MMOxnSVgh8LUW68dBWOddSyo7nVmnERcptA34WcIqNKxdSwjcmriWQaTHSUTzUKKs7Vuedoaqgv+D+bA/WINqVGHKY7A23fWJ4W6ia5hWtJDSrCNGr28OtbOaB6THVCPVxNbc7x1FGwlz5QbmCrEmnO9EyhVojxY05n1oR2gkO4odLYvdOSNsMyxsMO/XU0NrG/XpwHIBaQrhbznvjSrfHgk4PUBwRs0WKE8RKoRuCJuJuIFruTlrVVvDhfULK+57LVvDBiw3uGeoRML2n3fbGCIrzrts/BGM4At8nyf4uwv7GpN1CeWUEf6JRWRSiOan5y7WsZ1S+YGVScJnLjHPO8yBBu5rfFu6EW20yDhrSFyy1PTZVHBY6klh3u6qOe8KiADra+kNfI4R09IxyNZmcX3Ra4bvIjUh6xaAHCtB7+uRCTrlOQTHb0D4yZ7O4iVuVXQCWoegp8J1H6XprHJAvUhk7jnMQOothMb6Vq4NBjbnhWWVZ+OC8WBESHsIBgTvVHo5ZQKbaSBVujePsuVGRc0ppPDKNhXVXA3RyFL1z4i0u1Dtpn3ksWvsj71xPwwHu1rnnByaI5oNZMwrd2Hm/HgbaRSsHBMXk1d4oMlo/3Xk/SB6ifxrUQykhqzx3+MKqh/5aVNBCcUoIQKs9ikuNnMI1ugFZmIGRSirQrwFUrfYA49n7DVU90+/WQE6/tfHpviqOzI7kxTFCtlzBkZ9GLFrVdjXyShY6Mnm9pQcT2lpJvexTfCcWQF6GMZFzI0BT3WbX2C63kKCXjzYGiokcSFzo9tiRKXTvAH2MWtMBguDgnHMRpxOnnD7yhnDDu2Q7mQ2NT7DB4GC5Jk2+5oK7ZU/UFDPoFQ0YEZVk5+IFKhvQvtK1eaSN8LKgiqOPLINfENwA3hDGH+2wHbYwVrIhReIwX6W6Srxy1s6c0jkl5ptLcZh6baMJp2G8Nsezz0wyJHKuYKZ3MZ4ZvrWu+tDO44UpEd50ihrsO7SJgV4tpmdd/Mkf1pA4wqleSm5nArGjlW2eNmPA4q5b4N9ueqs1htBB478Fbi3xDRHyq4wfmYpK0WA1sbNKBNfqkGquGJ7aZ9eXMH9VwUvNn8ck1o3KpK/+2J3akj+BHZHa+2PMW9tQISumpDXn5PtLJVxqDC8SLD42NhcOTqyW3EnOeUHSGp+SKYKvTtpCPfIi5ljmYdrU0HuLDMD1EG8FfbGr6CAIK7Ljc0C1aK8D17Hxc9KOF1anvV1NqHaRl87gLQrACc64JJPfZxdBRePKZxGP1wUnvnSSTexiQtVUuCpdmEQpivyZELtYaAihVadpLC4XOz1YVZvAuM9jvdARCRUGVHWz34mGcpSDnZ9zEgm52SwDw8K7kTEmSaYKbXnpDa3TGC62Wr2dIyUsujHfhWJ3yjMajZxdp9zXaI6da/N2gjcXCWGDh+PXcT8qBxO0VasUcnmsBlfLhcZe9fuWBLZ7i8VJui7WjYR2jQtdQ+Ep70baddfzJ002C/+EQ5d39bQmJq8qwCOqoayFMmXVqs8X4bzsU0fYqVBaeQ7U1QYVlKnovmsuzW7y7tsqWhEaLwIotZDRIzmg++tQBGY+WXyg7/AExpOsNOlBFel8vPDAuPlxtKsdbfCG+4TsFjxfbo7JWVypbweHkA9aCYNmp/PC1Qkw1xjKQFZI5PgI+mUCNRSjG1jUaatX5jkXhSOH53lv368FWFa/wc/rhVdSq3MZ79EHgFbC7cLlpsNLj6gDsgkceD1Iu3b1/zpqOeruTHt3UCMgyfYBk9QhODbCoUw5t+ZhdMO1AxEdETB78tAi4OJIOLuPFsytheJqnfY1J+fdSLRB2V8cRVKppXN4iQuy+TDSAcNJnW9cpdMO+gquf15+vd3ednWSP6rqejv/W/IbGIV+SHDQyCcJDoz5McHxhfj3ZziYfyPrmM7FEKzD/4d81Y7ftAjza+ZnZXlV/lCm8tMz4n8wU0n9W4nK39r1X05UvvEOebZNL51aW5/K90MWc01I0s/0I7th6A0D/nLS8r8pQYnTP12Gkv1p3xr8FsZ+/60B+VOBkfpVMEZ/4ZXB52BjV3R9mvT/ldRznWXbMIcAeL53W0Hwe0j6CLsf8BMxJEEinyCOidM3xP3NuCLexb281z/BFfIJrlD0HwMW/d/vGN9fzf1fQ+P7vv+1l3i/DtE/5vb+MeRSMZNG2Y/ITcKUyf4J5KLIT4dcDP83kLvq16sRJf8aKsk/isqfC5Tkfw6U1Ibl19DzCxZhgZFWgEK8wviLob7xrZACNgzx87xZT9GETOnP4MtSNB5S/wBMMfxj4Ep9BtP/aOD6/i3Ot+qySujtYvEmTvIzyg8x0/eigSwZPvL/I5+rukq/E8qLFL7et8eQ0Wn3yYv4W5EkT3PxmcA/mpCnPXht6k/Zhz8RNX13GyHxz9IJnwgV+8eE+snXNV9FSG0AvwHoWoBVKMVPnSuAl03+2RlSyP+/0kWpn026+Cefw6y4JFe5rmKGsqRfSOVgQXpSgBaOobx+O/jFkHd/yBlQ0Bk8DfIP1ya4lLB6APGpV3D996Xellm9Ar7aip9Td37lA6D3xb/RJOpV/8ZDcM/f55xD+Pq06Bf8n8h1YAj7Qf9w5hP9Yz6L7P68/q0f0nz5+vLZ9s03rLj4vw== \ No newline at end of file diff --git "a/docs/java/basis/images/\347\274\226\350\257\221\345\236\213\350\257\255\350\250\200\345\222\214\350\247\243\351\207\212\345\236\213\350\257\255\350\250\200.png" "b/docs/java/basis/images/\347\274\226\350\257\221\345\236\213\350\257\255\350\250\200\345\222\214\350\247\243\351\207\212\345\236\213\350\257\255\350\250\200.png" new file mode 100644 index 0000000000000000000000000000000000000000..950a56c2871651618330079880aa82570fdf6ae6 Binary files /dev/null and "b/docs/java/basis/images/\347\274\226\350\257\221\345\236\213\350\257\255\350\250\200\345\222\214\350\247\243\351\207\212\345\236\213\350\257\255\350\250\200.png" differ diff --git a/docs/java/basis/io.md b/docs/java/basis/io.md new file mode 100644 index 0000000000000000000000000000000000000000..9bf93fb898f28e66f00c8202f3d4653d33e4fb13 --- /dev/null +++ b/docs/java/basis/io.md @@ -0,0 +1,131 @@ +--- +title: IO模型详解 +category: Java +tag: + - Java基础 +--- + + +IO 模型这块确实挺难理解的，需要太多计算机底层知识。写这篇文章用了挺久，就非常希望能把我所知道的讲出来吧!希望朋友们能有收获！为了写这篇文章，还翻看了一下《UNIX 网络编程》这本书，太难了，我滴乖乖！心痛~ + +_个人能力有限。如果文章有任何需要补充/完善/修改的地方，欢迎在评论区指出，共同进步！_ + +## 前言 + +I/O 一直是很多小伙伴难以理解的一个知识点，这篇文章我会将我所理解的 I/O 讲给你听，希望可以对你有所帮助。 + +## I/O + +### 何为 I/O? + +I/O（**I**nput/**O**utpu） 即**输入／输出** 。 + +**我们先从计算机结构的角度来解读一下 I/O。** + +根据冯.诺依曼结构，计算机结构分为 5 大部分：运算器、控制器、存储器、输入设备、输出设备。 + +![冯诺依曼体系结构](https://img-blog.csdnimg.cn/20190624122126398.jpeg?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9pcy1jbG91ZC5ibG9nLmNzZG4ubmV0,size_16,color_FFFFFF,t_70) + +输入设备（比如键盘）和输出设备（比如显示器）都属于外部设备。网卡、硬盘这种既可以属于输入设备，也可以属于输出设备。 + +输入设备向计算机输入数据，输出设备接收计算机输出的数据。 + +**从计算机结构的视角来看的话， I/O 描述了计算机系统与外部设备之间通信的过程。** + +**我们再先从应用程序的角度来解读一下 I/O。** + +根据大学里学到的操作系统相关的知识：为了保证操作系统的稳定性和安全性，一个进程的地址空间划分为 **用户空间（User space）** 和 **内核空间（Kernel space ）** 。 + +像我们平常运行的应用程序都是运行在用户空间，只有内核空间才能进行系统态级别的资源有关的操作，比如文件管理、进程通信、内存管理等等。也就是说，我们想要进行 IO 操作，一定是要依赖内核空间的能力。 + +并且，用户空间的程序不能直接访问内核空间。 + +当想要执行 IO 操作时，由于没有执行这些操作的权限，只能发起系统调用请求操作系统帮忙完成。 + +因此，用户进程想要执行 IO 操作的话，必须通过 **系统调用** 来间接访问内核空间 + +我们在平常开发过程中接触最多的就是 **磁盘 IO（读写文件）** 和 **网络 IO（网络请求和响应）**。 + +**从应用程序的视角来看的话，我们的应用程序对操作系统的内核发起 IO 调用（系统调用），操作系统负责的内核执行具体的 IO 操作。也就是说，我们的应用程序实际上只是发起了 IO 操作的调用而已，具体 IO 的执行是由操作系统的内核来完成的。** + +当应用程序发起 I/O 调用后，会经历两个步骤： + +1. 内核等待 I/O 设备准备好数据 +2. 内核将数据从内核空间拷贝到用户空间。 + +### 有哪些常见的 IO 模型? + +UNIX 系统下， IO 模型一共有 5 种： **同步阻塞 I/O**、**同步非阻塞 I/O**、**I/O 多路复用**、**信号驱动 I/O** 和**异步 I/O**。 + +这也是我们经常提到的 5 种 IO 模型。 + +## Java 中 3 种常见 IO 模型 + +### BIO (Blocking I/O) + +**BIO 属于同步阻塞 IO 模型** 。 + +同步阻塞 IO 模型中，应用程序发起 read 调用后，会一直阻塞，直到内核把数据拷贝到用户空间。 + +![图源：《深入拆解Tomcat & Jetty》](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/6a9e704af49b4380bb686f0c96d33b81~tplv-k3u1fbpfcp-watermark.image) + +在客户端连接数量不高的情况下，是没问题的。但是，当面对十万甚至百万级连接的时候，传统的 BIO 模型是无能为力的。因此，我们需要一种更高效的 I/O 处理模型来应对更高的并发量。 + +### NIO (Non-blocking/New I/O) + +Java 中的 NIO 于 Java 1.4 中引入，对应 `java.nio` 包，提供了 `Channel` , `Selector`，`Buffer` 等抽象。NIO 中的 N 可以理解为 Non-blocking，不单纯是 New。它是支持面向缓冲的，基于通道的 I/O 操作方法。 对于高负载、高并发的（网络）应用，应使用 NIO 。 + +Java 中的 NIO 可以看作是 **I/O 多路复用模型**。也有很多人认为，Java 中的 NIO 属于同步非阻塞 IO 模型。 + +跟着我的思路往下看看，相信你会得到答案！ + +我们先来看看 **同步非阻塞 IO 模型**。 + +![图源：《深入拆解Tomcat & Jetty》](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/bb174e22dbe04bb79fe3fc126aed0c61~tplv-k3u1fbpfcp-watermark.image) + +同步非阻塞 IO 模型中，应用程序会一直发起 read 调用，等待数据从内核空间拷贝到用户空间的这段时间里，线程依然是阻塞的，直到在内核把数据拷贝到用户空间。 + +相比于同步阻塞 IO 模型，同步非阻塞 IO 模型确实有了很大改进。通过轮询操作，避免了一直阻塞。 + +但是，这种 IO 模型同样存在问题：**应用程序不断进行 I/O 系统调用轮询数据是否已经准备好的过程是十分消耗 CPU 资源的。** + +这个时候，**I/O 多路复用模型** 就上场了。 + +![](https://p6-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/88ff862764024c3b8567367df11df6ab~tplv-k3u1fbpfcp-watermark.image) + +IO 多路复用模型中，线程首先发起 select 调用，询问内核数据是否准备就绪，等内核把数据准备好了，用户线程再发起 read 调用。read 调用的过程（数据从内核空间 -> 用户空间）还是阻塞的。 + +> 目前支持 IO 多路复用的系统调用，有 select，epoll 等等。select 系统调用，目前几乎在所有的操作系统上都有支持。 +> +> - **select 调用** ：内核提供的系统调用，它支持一次查询多个系统调用的可用状态。几乎所有的操作系统都支持。 +> - **epoll 调用** ：linux 2.6 内核，属于 select 调用的增强版本，优化了 IO 的执行效率。 + +**IO 多路复用模型，通过减少无效的系统调用，减少了对 CPU 资源的消耗。** + +Java 中的 NIO ，有一个非常重要的**选择器 ( Selector )** 的概念，也可以被称为 **多路复用器**。通过它，只需要一个线程便可以管理多个客户端连接。当客户端数据到了之后，才会为其服务。 + +![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/0f483f2437ce4ecdb180134270a00144~tplv-k3u1fbpfcp-watermark.image) + +### AIO (Asynchronous I/O) + +AIO 也就是 NIO 2。Java 7 中引入了 NIO 的改进版 NIO 2,它是异步 IO 模型。 + +异步 IO 是基于事件和回调机制实现的，也就是应用操作之后会直接返回，不会堵塞在那里，当后台处理完成，操作系统会通知相应的线程进行后续的操作。 + +![](https://p1-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/3077e72a1af049559e81d18205b56fd7~tplv-k3u1fbpfcp-watermark.image) + +目前来说 AIO 的应用还不是很广泛。Netty 之前也尝试使用过 AIO，不过又放弃了。这是因为，Netty 使用了 AIO 之后，在 Linux 系统上的性能并没有多少提升。 + +最后，来一张图，简单总结一下 Java 中的 BIO、NIO、AIO。 + +![](https://images.xiaozhuanlan.com/photo/2020/33b193457c928ae02217480f994814b6.png) + +## 参考 + +- 《深入拆解 Tomcat & Jetty》 +- 如何完成一次 IO：[https://llc687.top/post/如何完成一次-io/](https://llc687.top/post/如何完成一次-io/) +- 程序员应该这样理解 IO：[https://www.jianshu.com/p/fa7bdc4f3de7](https://www.jianshu.com/p/fa7bdc4f3de7) +- 10 分钟看懂， Java NIO 底层原理：https://www.cnblogs.com/crazymakercircle/p/10225159.html +- IO 模型知多少 | 理论篇：https://www.cnblogs.com/sheng-jie/p/how-much-you-know-about-io-models.html +- 《UNIX 网络编程 卷 1；套接字联网 API 》6.2 节 IO 模型 + diff --git a/docs/java/basis/java-basic-questions-01.md b/docs/java/basis/java-basic-questions-01.md new file mode 100644 index 0000000000000000000000000000000000000000..51d1f7048e17bd552d38483fe02ae08aefcd30c1 --- /dev/null +++ b/docs/java/basis/java-basic-questions-01.md @@ -0,0 +1,837 @@ +--- +title: Java基础常见知识&面试题总结(上) +category: Java +tag: + - Java基础 +--- + +## 基础概念与常识 + +### Java 语言有哪些特点? + +1. 简单易学； +2. 面向对象（封装，继承，多态）； +3. 平台无关性（ Java 虚拟机实现平台无关性）； +4. 支持多线程（ C++ 语言没有内置的多线程机制，因此必须调用操作系统的多线程功能来进行多线程程序设计，而 Java 语言却提供了多线程支持）； +5. 可靠性； +6. 安全性； +7. 支持网络编程并且很方便（ Java 语言诞生本身就是为简化网络编程设计的，因此 Java 语言不仅支持网络编程而且很方便）； +8. 编译与解释并存； + +> **🐛 修正（参见： [issue#544](https://github.com/Snailclimb/JavaGuide/issues/544)）** ：C++11 开始（2011 年的时候）,C++就引入了多线程库，在 windows、linux、macos 都可以使用`std::thread`和`std::async`来创建线程。参考链接：http://www.cplusplus.com/reference/thread/thread/?kw=thread + +🌈 拓展一下： + +“Write Once, Run Anywhere（一次编写，随处运行）”这句宣传口号，真心经典，流传了好多年！以至于，直到今天，依然有很多人觉得跨平台是 Java 语言最大的优势。实际上，跨平台已经不是 Java 最大的卖点了，各种 JDK 新特性也不是。目前市面上虚拟化技术已经非常成熟，比如你通过 Docker 就很容易实现跨平台了。在我看来，Java 强大的生态才是！ + +### JVM vs JDK vs JRE + +#### JVM + +Java 虚拟机（JVM）是运行 Java 字节码的虚拟机。JVM 有针对不同系统的特定实现（Windows，Linux，macOS），目的是使用相同的字节码，它们都会给出相同的结果。字节码和不同系统的 JVM 实现是 Java 语言“一次编译，随处可以运行”的关键所在。 + +**JVM 并不是只有一种！只要满足 JVM 规范，每个公司、组织或者个人都可以开发自己的专属 JVM。** 也就是说我们平时接触到的 HotSpot VM 仅仅是是 JVM 规范的一种实现而已。 + +除了我们平时最常用的 HotSpot VM 外，还有 J9 VM、Zing VM、JRockit VM 等 JVM 。维基百科上就有常见 JVM 的对比：[Comparison of Java virtual machines](https://en.wikipedia.org/wiki/Comparison_of_Java_virtual_machines) ，感兴趣的可以去看看。并且，你可以在 [Java SE Specifications](https://docs.oracle.com/javase/specs/index.html) 上找到各个版本的 JDK 对应的 JVM 规范。 + +![Java SE Specifications](./images/java-se-specifications.png) + +#### JDK 和 JRE + +JDK 是 Java Development Kit 缩写，它是功能齐全的 Java SDK。它拥有 JRE 所拥有的一切，还有编译器（javac）和工具（如 javadoc 和 jdb）。它能够创建和编译程序。 + +JRE 是 Java 运行时环境。它是运行已编译 Java 程序所需的所有内容的集合，包括 Java 虚拟机（JVM），Java 类库，java 命令和其他的一些基础构件。但是，它不能用于创建新程序。 + +如果你只是为了运行一下 Java 程序的话，那么你只需要安装 JRE 就可以了。如果你需要进行一些 Java 编程方面的工作，那么你就需要安装 JDK 了。但是，这不是绝对的。有时，即使您不打算在计算机上进行任何 Java 开发，仍然需要安装 JDK。例如，如果要使用 JSP 部署 Web 应用程序，那么从技术上讲，您只是在应用程序服务器中运行 Java 程序。那你为什么需要 JDK 呢？因为应用程序服务器会将 JSP 转换为 Java servlet，并且需要使用 JDK 来编译 servlet。 + +### 什么是字节码?采用字节码的好处是什么? + +在 Java 中，JVM 可以理解的代码就叫做字节码（即扩展名为 `.class` 的文件），它不面向任何特定的处理器，只面向虚拟机。Java 语言通过字节码的方式，在一定程度上解决了传统解释型语言执行效率低的问题，同时又保留了解释型语言可移植的特点。所以， Java 程序运行时相对来说还是高效的（不过，和 C++，Rust，Go 等语言还是有一定差距的），而且，由于字节码并不针对一种特定的机器，因此，Java 程序无须重新编译便可在多种不同操作系统的计算机上运行。 + +**Java 程序从源代码到运行的过程如下图所示：** + +![Java程序转变为机器代码的过程](./images/java程序转变为机器代码的过程.png) + +我们需要格外注意的是 `.class->机器码` 这一步。在这一步 JVM 类加载器首先加载字节码文件，然后通过解释器逐行解释执行，这种方式的执行速度会相对比较慢。而且，有些方法和代码块是经常需要被调用的(也就是所谓的热点代码)，所以后面引进了 JIT（just-in-time compilation） 编译器，而 JIT 属于运行时编译。当 JIT 编译器完成第一次编译后，其会将字节码对应的机器码保存下来，下次可以直接使用。而我们知道，机器码的运行效率肯定是高于 Java 解释器的。这也解释了我们为什么经常会说 **Java 是编译与解释共存的语言** 。 + +> HotSpot 采用了惰性评估(Lazy Evaluation)的做法，根据二八定律，消耗大部分系统资源的只有那一小部分的代码（热点代码），而这也就是 JIT 所需要编译的部分。JVM 会根据代码每次被执行的情况收集信息并相应地做出一些优化，因此执行的次数越多，它的速度就越快。JDK 9 引入了一种新的编译模式 AOT(Ahead of Time Compilation)，它是直接将字节码编译成机器码，这样就避免了 JIT 预热等各方面的开销。JDK 支持分层编译和 AOT 协作使用。但是 ，AOT 编译器的编译质量是肯定比不上 JIT 编译器的。 + +### 为什么说 Java 语言“编译与解释并存”？ + +其实这个问题我们讲字节码的时候已经提到过，因为比较重要，所以我们这里再提一下。 + +我们可以将高级编程语言按照程序的执行方式分为两种： + +- **编译型** ：[编译型语言](https://zh.wikipedia.org/wiki/%E7%B7%A8%E8%AD%AF%E8%AA%9E%E8%A8%80) 会通过[编译器](https://zh.wikipedia.org/wiki/%E7%B7%A8%E8%AD%AF%E5%99%A8)将源代码一次性翻译成可被该平台执行的机器码。一般情况下，编译语言的执行速度比较快，开发效率比较低。常见的编译性语言有 C、C++、Go、Rust 等等。 +- **解释型** ：[解释型语言](https://zh.wikipedia.org/wiki/%E7%9B%B4%E8%AD%AF%E8%AA%9E%E8%A8%80)会通过[解释器](https://zh.wikipedia.org/wiki/直譯器)一句一句的将代码解释（interpret）为机器代码后再执行。解释型语言开发效率比较快，执行速度比较慢。常见的解释性语言有 Python、JavaScript、PHP 等等。 + +![编译型语言和解释型语言](./images/编译型语言和解释型语言.png) + +根据维基百科介绍： + +> 为了改善编译语言的效率而发展出的[即时编译](https://zh.wikipedia.org/wiki/即時編譯)技术，已经缩小了这两种语言间的差距。这种技术混合了编译语言与解释型语言的优点，它像编译语言一样，先把程序源代码编译成[字节码](https://zh.wikipedia.org/wiki/字节码)。到执行期时，再将字节码直译，之后执行。[Java](https://zh.wikipedia.org/wiki/Java)与[LLVM](https://zh.wikipedia.org/wiki/LLVM)是这种技术的代表产物。 +> +> 相关阅读：[基本功 | Java 即时编译器原理解析及实践](https://tech.meituan.com/2020/10/22/java-jit-practice-in-meituan.html) + +**为什么说 Java 语言“编译与解释并存”？** + +这是因为 Java 语言既具有编译型语言的特征，也具有解释型语言的特征。因为 Java 程序要经过先编译，后解释两个步骤，由 Java 编写的程序需要先经过编译步骤，生成字节码（`.class` 文件），这种字节码必须由 Java 解释器来解释执行。 + +### Oracle JDK vs OpenJDK + +可能在看这个问题之前很多人和我一样并没有接触和使用过 OpenJDK 。那么 Oracle JDK 和 OpenJDK 之间是否存在重大差异？下面我通过收集到的一些资料，为你解答这个被很多人忽视的问题。 + +对于 Java 7，没什么关键的地方。OpenJDK 项目主要基于 Sun 捐赠的 HotSpot 源代码。此外，OpenJDK 被选为 Java 7 的参考实现，由 Oracle 工程师维护。关于 JVM，JDK，JRE 和 OpenJDK 之间的区别，Oracle 博客帖子在 2012 年有一个更详细的答案： + +> 问：OpenJDK 存储库中的源代码与用于构建 Oracle JDK 的代码之间有什么区别？ +> +> 答：非常接近 - 我们的 Oracle JDK 版本构建过程基于 OpenJDK 7 构建，只添加了几个部分，例如部署代码，其中包括 Oracle 的 Java 插件和 Java WebStart 的实现，以及一些闭源的第三方组件，如图形光栅化器，一些开源的第三方组件，如 Rhino，以及一些零碎的东西，如附加文档或第三方字体。展望未来，我们的目的是开源 Oracle JDK 的所有部分，除了我们考虑商业功能的部分。 + +**总结：** + +1. Oracle JDK 大概每 6 个月发一次主要版本，而 OpenJDK 版本大概每三个月发布一次。但这不是固定的，我觉得了解这个没啥用处。详情参见：[https://blogs.oracle.com/java-platform-group/update-and-faq-on-the-java-se-release-cadence](https://blogs.oracle.com/java-platform-group/update-and-faq-on-the-java-se-release-cadence) 。 +2. OpenJDK 是一个参考模型并且是完全开源的，而 Oracle JDK 是 OpenJDK 的一个实现，并不是完全开源的； +3. Oracle JDK 比 OpenJDK 更稳定。OpenJDK 和 Oracle JDK 的代码几乎相同，但 Oracle JDK 有更多的类和一些错误修复。因此，如果您想开发企业/商业软件，我建议您选择 Oracle JDK，因为它经过了彻底的测试和稳定。某些情况下，有些人提到在使用 OpenJDK 可能会遇到了许多应用程序崩溃的问题，但是，只需切换到 Oracle JDK 就可以解决问题； +4. 在响应性和 JVM 性能方面，Oracle JDK 与 OpenJDK 相比提供了更好的性能； +5. Oracle JDK 不会为即将发布的版本提供长期支持，用户每次都必须通过更新到最新版本获得支持来获取最新版本； +6. Oracle JDK 使用 BCL/OTN 协议获得许可，而 OpenJDK 根据 GPL v2 许可获得许可。 + +🌈 拓展一下： + +- BCL 协议（Oracle Binary Code License Agreement）： 可以使用 JDK（支持商用），但是不能进行修改。 +- OTN 协议（Oracle Technology Network License Agreement）： 11 及之后新发布的 JDK 用的都是这个协议，可以自己私下用，但是商用需要付费。 + +![](https://guide-blog-images.oss-cn-shenzhen.aliyuncs.com/java-guide-blog/20210425151835918.png) + +相关阅读 👍：[《Differences Between Oracle JDK and OpenJDK》](https://www.baeldung.com/oracle-jdk-vs-openjdk) + +### Java 和 C++ 的区别? + +我知道很多人没学过 C++，但是面试官就是没事喜欢拿咱们 Java 和 C++ 比呀！没办法！！！就算没学过 C++，也要记下来。 + +虽然，Java 和 C++ 都是面向对象的语言，都支持封装、继承和多态，但是，它们还是有挺多不相同的地方： + +- Java 不提供指针来直接访问内存，程序内存更加安全 +- Java 的类是单继承的，C++ 支持多重继承；虽然 Java 的类不可以多继承，但是接口可以多继承。 +- Java 有自动内存管理垃圾回收机制(GC)，不需要程序员手动释放无用内存。 +- C ++同时支持方法重载和操作符重载，但是 Java 只支持方法重载（操作符重载增加了复杂性，这与 Java 最初的设计思想不符）。 +- ...... + +## 基本语法 + +### 字符型常量和字符串常量的区别? + +1. **形式** : 字符常量是单引号引起的一个字符，字符串常量是双引号引起的 0 个或若干个字符。 +2. **含义** : 字符常量相当于一个整型值( ASCII 值),可以参加表达式运算; 字符串常量代表一个地址值(该字符串在内存中存放位置)。 +3. **占内存大小** ： 字符常量只占 2 个字节; 字符串常量占若干个字节。 + + (**注意： `char` 在 Java 中占两个字节**) + +### 注释有哪几种形式？ + +Java 中的注释有三种： + +1. 单行注释 + +2. 多行注释 + +3. 文档注释。 + +在我们编写代码的时候，如果代码量比较少，我们自己或者团队其他成员还可以很轻易地看懂代码，但是当项目结构一旦复杂起来，我们就需要用到注释了。注释并不会执行(编译器在编译代码之前会把代码中的所有注释抹掉,字节码中不保留注释)，是我们程序员写给自己看的，注释是你的代码说明书，能够帮助看代码的人快速地理清代码之间的逻辑关系。因此，在写程序的时候随手加上注释是一个非常好的习惯。 + +《Clean Code》这本书明确指出： + +> **代码的注释不是越详细越好。实际上好的代码本身就是注释，我们要尽量规范和美化自己的代码来减少不必要的注释。** +> +> **若编程语言足够有表达力，就不需要注释，尽量通过代码来阐述。** +> +> 举个例子： +> +> 去掉下面复杂的注释，只需要创建一个与注释所言同一事物的函数即可 +> +> ```java +> // check to see if the employee is eligible for full benefits +> if ((employee.flags & HOURLY_FLAG) && (employee.age > 65)) +> ``` +> +> 应替换为 +> +> ```java +> if (employee.isEligibleForFullBenefits()) +> ``` + +### 标识符和关键字的区别是什么？ + +在我们编写程序的时候，需要大量地为程序、类、变量、方法等取名字，于是就有了 **标识符** 。简单来说， **标识符就是一个名字** 。 + +有一些标识符，Java 语言已经赋予了其特殊的含义，只能用于特定的地方，这些特殊的标识符就是 **关键字** 。简单来说，**关键字是被赋予特殊含义的标识**符 。比如，在我们的日常生活中，如果我们想要开一家店，则要给这个店起一个名字，起的这个“名字”就叫标识符。但是我们店的名字不能叫“警察局”，因为“警察局”这个名字已经被赋予了特殊的含义，而“警察局”就是我们日常生活中的关键字。 + +### Java 语言关键字有哪些？ + +| 分类 | 关键字 | | | | | | | +| :------------------- | -------- |-------- | -------- | -------- | --------| --------| -------- | +| 访问控制 | private | protected | public | | | | | +| 类，方法和变量修饰符 | abstract | class | extends | final | implements | interface | native | +| | new | static | strictfp | synchronized | transient | volatile | enum | +| 程序控制 | break | continue | return | do | while | if | else | +| | for | instanceof | switch | case | default | assert | | +| 错误处理 | try | catch | throw | throws | finally | | | +| 包相关 | import | package | | | | | | +| 基本类型 | boolean | byte | char | double | float | int | long | +| | short | | | | | | | +| 变量引用 | super | this | void | | | | | +| 保留字 | goto | const | | | | | | + +> Tips：所有的关键字都是小写的，在 IDE 中会以特殊颜色显示。 +> +> `default` 这个关键字很特殊，既属于程序控制，也属于类，方法和变量修饰符，还属于访问控制。 +> +> - 在程序控制中，当在 `switch` 中匹配不到任何情况时，可以使用 `default` 来编写默认匹配的情况。 +> - 在类，方法和变量修饰符中，从 JDK8 开始引入了默认方法，可以使用 `default` 关键字来定义一个方法的默认实现。 +> - 在访问控制中，如果一个方法前没有任何修饰符，则默认会有一个修饰符 `default`，但是这个修饰符加上了就会报错。 + +注意 ⚠️：虽然 `true`, `false`, 和 `null` 看起来像关键字但实际上他们是字面值，同时你也不可以作为标识符来使用。 + +官方文档：[https://docs.oracle.com/javase/tutorial/java/nutsandbolts/_keywords.html](https://docs.oracle.com/javase/tutorial/java/nutsandbolts/_keywords.html) + +### 自增自减运算符 + +在写代码的过程中，常见的一种情况是需要某个整数类型变量增加 1 或减少 1，Java 提供了一种特殊的运算符，用于这种表达式，叫做自增运算符（++)和自减运算符（--）。 + +++ 和 -- 运算符可以放在变量之前，也可以放在变量之后，当运算符放在变量之前时(前缀)，先自增/减，再赋值；当运算符放在变量之后时(后缀)，先赋值，再自增/减。例如，当 `b = ++a` 时，先自增（自己增加 1），再赋值（赋值给 b）；当 `b = a++` 时，先赋值(赋值给 b)，再自增（自己增加 1）。也就是，++a 输出的是 a+1 的值，a++输出的是 a 值。用一句口诀就是：“符号在前就先加/减，符号在后就后加/减”。 + +### continue、break 和 return 的区别是什么？ + +在循环结构中，当循环条件不满足或者循环次数达到要求时，循环会正常结束。但是，有时候可能需要在循环的过程中，当发生了某种条件之后 ，提前终止循环，这就需要用到下面几个关键词： + +1. `continue` ：指跳出当前的这一次循环，继续下一次循环。 +2. `break` ：指跳出整个循环体，继续执行循环下面的语句。 + +`return` 用于跳出所在方法，结束该方法的运行。return 一般有两种用法： + +1. `return;` ：直接使用 return 结束方法执行，用于没有返回值函数的方法 +2. `return value;` ：return 一个特定值，用于有返回值函数的方法 + +思考一下：下列语句的运行结果是什么？ + +```java + public static void main(String[] args) { + boolean flag = false; + for (int i = 0; i <= 3; i++) { + if (i == 0) { + System.out.println("0"); + } else if (i == 1) { + System.out.println("1"); + continue; + } else if (i == 2) { + System.out.println("2"); + flag = true; + } else if (i == 3) { + System.out.println("3"); + break; + } else if (i == 4) { + System.out.println("4"); + } + System.out.println("xixi"); + } + if (flag) { + System.out.println("haha"); + return; + } + System.out.println("heihei"); + } +``` + +运行结果： + +``` +0 +xixi +1 +2 +xixi +3 +haha +``` + +### 方法 + +#### 什么是方法的返回值?方法有哪几种类型？ + +**方法的返回值** 是指我们获取到的某个方法体中的代码执行后产生的结果！（前提是该方法可能产生结果）。返回值的作用是接收出结果，使得它可以用于其他的操作！ + +我们可以按照方法的返回值和参数类型将方法分为下面这几种： + +**1.无参数无返回值的方法** + +```java +public void f1() { + //...... +} +// 下面这个方法也没有返回值，虽然用到了 return +public void f(int a) { + if (...) { + // 表示结束方法的执行,下方的输出语句不会执行 + return; + } + System.out.println(a); +} +``` + +**2.有参数无返回值的方法** + +```java +public void f2(Parameter 1, ..., Parameter n) { + //...... +} +``` + +**3.有返回值无参数的方法** + +```java +public int f3() { + //...... + return x; +} +``` + +**4.有返回值有参数的方法** + +```java +public int f4(int a, int b) { + return a * b; +} +``` + +#### 静态方法为什么不能调用非静态成员? + +这个需要结合 JVM 的相关知识，主要原因如下： + +1. 静态方法是属于类的，在类加载的时候就会分配内存，可以通过类名直接访问。而非静态成员属于实例对象，只有在对象实例化之后才存在，需要通过类的实例对象去访问。 +2. 在类的非静态成员不存在的时候静态成员就已经存在了，此时调用在内存中还不存在的非静态成员，属于非法操作。 + +#### 静态方法和实例方法有何不同？ + +**1、调用方式** + +在外部调用静态方法时，可以使用 `类名.方法名` 的方式，也可以使用 `对象.方法名` 的方式，而实例方法只有后面这种方式。也就是说，**调用静态方法可以无需创建对象** 。 + +不过，需要注意的是一般不建议使用 `对象.方法名` 的方式来调用静态方法。这种方式非常容易造成混淆，静态方法不属于类的某个对象而是属于这个类。 + +因此，一般建议使用 `类名.方法名` 的方式来调用静态方法。 + +```java +public class Person { + public void method() { + //...... + } + + public static void staicMethod(){ + //...... + } + public static void main(String[] args) { + Person person = new Person(); + // 调用实例方法 + person.method(); + // 调用静态方法 + Person.staicMethod() + } +} +``` + +**2、访问类成员是否存在限制** + +静态方法在访问本类的成员时，只允许访问静态成员（即静态成员变量和静态方法），不允许访问实例成员（即实例成员变量和实例方法），而实例方法不存在这个限制。 + +#### 重载和重写的区别 + +> 重载就是同样的一个方法能够根据输入数据的不同，做出不同的处理 +> +> 重写就是当子类继承自父类的相同方法，输入数据一样，但要做出有别于父类的响应时，你就要覆盖父类方法 + +**重载** + +发生在同一个类中（或者父类和子类之间），方法名必须相同，参数类型不同、个数不同、顺序不同，方法返回值和访问修饰符可以不同。 + +《Java 核心技术》这本书是这样介绍重载的： + +> 如果多个方法(比如 `StringBuilder` 的构造方法)有相同的名字、不同的参数， 便产生了重载。 +> +> ```java +> StringBuilder sb = new StringBuilder(); +> StringBuilder sb2 = new StringBuilder("HelloWorld"); +> ``` +> +> 编译器必须挑选出具体执行哪个方法，它通过用各个方法给出的参数类型与特定方法调用所使用的值类型进行匹配来挑选出相应的方法。 如果编译器找不到匹配的参数， 就会产生编译时错误， 因为根本不存在匹配， 或者没有一个比其他的更好(这个过程被称为重载解析(overloading resolution))。 +> +> Java 允许重载任何方法， 而不只是构造器方法。 + +综上：重载就是同一个类中多个同名方法根据不同的传参来执行不同的逻辑处理。 + +**重写** + +重写发生在运行期，是子类对父类的允许访问的方法的实现过程进行重新编写。 + +1. 方法名、参数列表必须相同，子类方法返回值类型应比父类方法返回值类型更小或相等，抛出的异常范围小于等于父类，访问修饰符范围大于等于父类。 +2. 如果父类方法访问修饰符为 `private/final/static` 则子类就不能重写该方法，但是被 `static` 修饰的方法能够被再次声明。 +3. 构造方法无法被重写 + +综上：**重写就是子类对父类方法的重新改造，外部样子不能改变，内部逻辑可以改变。** + +| 区别点 | 重载方法 | 重写方法 | +| :--------- | :------- | :--------------------------------------------------------------- | +| 发生范围 | 同一个类 | 子类 | +| 参数列表 | 必须修改 | 一定不能修改 | +| 返回类型 | 可修改 | 子类方法返回值类型应比父类方法返回值类型更小或相等 | +| 异常 | 可修改 | 子类方法声明抛出的异常类应比父类方法声明抛出的异常类更小或相等； | +| 访问修饰符 | 可修改 | 一定不能做更严格的限制（可以降低限制） | +| 发生阶段 | 编译期 | 运行期 | + +**方法的重写要遵循“两同两小一大”**（以下内容摘录自《疯狂 Java 讲义》，[issue#892](https://github.com/Snailclimb/JavaGuide/issues/892) ）： + +- “两同”即方法名相同、形参列表相同； +- “两小”指的是子类方法返回值类型应比父类方法返回值类型更小或相等，子类方法声明抛出的异常类应比父类方法声明抛出的异常类更小或相等； +- “一大”指的是子类方法的访问权限应比父类方法的访问权限更大或相等。 + +⭐️ 关于 **重写的返回值类型** 这里需要额外多说明一下，上面的表述不太清晰准确：如果方法的返回类型是 void 和基本数据类型，则返回值重写时不可修改。但是如果方法的返回值是引用类型，重写时是可以返回该引用类型的子类的。 + +```java +public class Hero { + public String name() { + return "超级英雄"; + } +} +public class SuperMan extends Hero{ + @Override + public String name() { + return "超人"; + } + public Hero hero() { + return new Hero(); + } +} + +public class SuperSuperMan extends SuperMan { + public String name() { + return "超级超级英雄"; + } + + @Override + public SuperMan hero() { + return new SuperMan(); + } +} +``` + +### == 和 equals() 的区别 + +**`==`** 对于基本类型和引用类型的作用效果是不同的： + +- 对于基本数据类型来说，`==` 比较的是值。 +- 对于引用数据类型来说，`==` 比较的是对象的内存地址。 + +> 因为 Java 只有值传递，所以，对于 == 来说，不管是比较基本数据类型，还是引用数据类型的变量，其本质比较的都是值，只是引用类型变量存的值是对象的地址。 + +**`equals()`** 不能用于判断基本数据类型的变量，只能用来判断两个对象是否相等。`equals()`方法存在于`Object`类中，而`Object`类是所有类的直接或间接父类，因此所有的类都有`equals()`方法。 + +`Object` 类 `equals()` 方法： + +```java +public boolean equals(Object obj) { + return (this == obj); +} +``` + +`equals()` 方法存在两种使用情况： + +- **类没有重写 `equals()`方法** ：通过`equals()`比较该类的两个对象时，等价于通过“==”比较这两个对象，使用的默认是 `Object`类`equals()`方法。 +- **类重写了 `equals()`方法** ：一般我们都重写 `equals()`方法来比较两个对象中的属性是否相等；若它们的属性相等，则返回 true(即，认为这两个对象相等)。 + +举个例子（这里只是为了举例。实际上，你按照下面这种写法的话，像 IDEA 这种比较智能的 IDE 都会提示你将 `==` 换成 `equals()` ）： + +```java +String a = new String("ab"); // a 为一个引用 +String b = new String("ab"); // b为另一个引用,对象的内容一样 +String aa = "ab"; // 放在常量池中 +String bb = "ab"; // 从常量池中查找 +System.out.println(aa == bb);// true +System.out.println(a == b);// false +System.out.println(a.equals(b));// true +System.out.println(42 == 42.0);// true +``` + +`String` 中的 `equals` 方法是被重写过的，因为 `Object` 的 `equals` 方法是比较的对象的内存地址，而 `String` 的 `equals` 方法比较的是对象的值。 + +当创建 `String` 类型的对象时，虚拟机会在常量池中查找有没有已经存在的值和要创建的值相同的对象，如果有就把它赋给当前引用。如果没有就在常量池中重新创建一个 `String` 对象。 + +`String`类`equals()`方法： + +```java +public boolean equals(Object anObject) { + if (this == anObject) { + return true; + } + if (anObject instanceof String) { + String anotherString = (String)anObject; + int n = value.length; + if (n == anotherString.value.length) { + char v1[] = value; + char v2[] = anotherString.value; + int i = 0; + while (n-- != 0) { + if (v1[i] != v2[i]) + return false; + i++; + } + return true; + } + } + return false; +} +``` + +### hashCode() 与 equals() + +面试官可能会问你：“你重写过 `hashCode()` 和 `equals()`么?为什么重写 `equals()` 时必须重写 `hashCode()` 方法？” + +一个非常基础的问题，面试中的重中之重，然而，很多求职者还是会回答不到点子上去。 + +#### hashCode() 有什么用？ + +`hashCode()` 的作用是获取哈希码（`int` 整数），也称为散列码。这个哈希码的作用是确定该对象在哈希表中的索引位置。 + +`hashCode()`定义在 JDK 的 `Object` 类中，这就意味着 Java 中的任何类都包含有 `hashCode()` 函数。另外需要注意的是： `Object` 的 `hashCode()` 方法是本地方法，也就是用 C 语言或 C++ 实现的，该方法通常用来将对象的内存地址转换为整数之后返回。 + +```java +public native int hashCode(); +``` + +散列表存储的是键值对(key-value)，它的特点是：**能根据“键”快速的检索出对应的“值”。这其中就利用到了散列码！（可以快速找到所需要的对象）** + +#### 为什么要有 hashCode？ + +我们以“`HashSet` 如何检查重复”为例子来说明为什么要有 `hashCode`？ + +下面这段内容摘自我的 Java 启蒙书《Head First Java》: + +> 当你把对象加入 `HashSet` 时，`HashSet` 会先计算对象的 `hashCode` 值来判断对象加入的位置，同时也会与其他已经加入的对象的 `hashCode` 值作比较，如果没有相符的 `hashCode`，`HashSet` 会假设对象没有重复出现。但是如果发现有相同 `hashCode` 值的对象，这时会调用 `equals()` 方法来检查 `hashCode` 相等的对象是否真的相同。如果两者相同，`HashSet` 就不会让其加入操作成功。如果不同的话，就会重新散列到其他位置。这样我们就大大减少了 `equals` 的次数，相应就大大提高了执行速度。 + +其实， `hashCode()` 和 `equals()`都是用于比较两个对象是否相等。 + +**那为什么 JDK 还要同时提供这两个方法呢？** + +这是因为在一些容器（比如 `HashMap`、`HashSet`）中，有了 `hashCode()` 之后，判断元素是否在对应容器中的效率会更高（参考添加元素进`HastSet`的过程）！ + +我们在前面也提到了添加元素进`HastSet`的过程，如果 `HashSet` 在对比的时候，同样的 `hashCode` 有多个对象，它会继续使用 `equals()` 来判断是否真的相同。也就是说 `hashCode` 帮助我们大大缩小了查找成本。 + +**那为什么不只提供 `hashCode()` 方法呢？** + +这是因为两个对象的`hashCode` 值相等并不代表两个对象就相等。 + +**那为什么两个对象有相同的 `hashCode` 值，它们也不一定是相等的？** + +因为 `hashCode()` 所使用的哈希算法也许刚好会让多个对象传回相同的哈希值。越糟糕的哈希算法越容易碰撞，但这也与数据值域分布的特性有关（所谓哈希碰撞也就是指的是不同的对象得到相同的 `hashCode` )。 + +总结下来就是 ： + +- 如果两个对象的`hashCode` 值相等，那这两个对象不一定相等（哈希碰撞）。 +- 如果两个对象的`hashCode` 值相等并且`equals()`方法也返回 `true`，我们才认为这两个对象相等。 +- 如果两个对象的`hashCode` 值不相等，我们就可以直接认为这两个对象不相等。 + +相信大家看了我前面对 `hashCode()` 和 `equals()` 的介绍之后，下面这个问题已经难不倒你们了。 + +#### 为什么重写 equals() 时必须重写 hashCode() 方法？ + +因为两个相等的对象的 `hashCode` 值必须是相等。也就是说如果 `equals` 方法判断两个对象是相等的，那这两个对象的 `hashCode` 值也要相等。 + +如果重写 `equals()` 时没有重写 `hashCode()` 方法的话就可能会导致 `equals` 方法判断是相等的两个对象，`hashCode` 值却不相等。 + +**思考** ：重写 `equals()` 时没有重写 `hashCode()` 方法的话，使用 `HashMap` 可能会出现什么问题。 + +**总结** ： + +- `equals` 方法判断两个对象是相等的，那这两个对象的 `hashCode` 值也要相等。 +- 两个对象有相同的 `hashCode` 值，他们也不一定是相等的（哈希碰撞）。 + +更多关于 `hashCode()` 和 `equals()` 的内容可以查看：[Java hashCode() 和 equals()的若干问题解答](https://www.cnblogs.com/skywang12345/p/3324958.html) + +### 什么是可变长参数？ + +从 Java5 开始，Java 支持定义可变长参数，所谓可变长参数就是允许在调用方法时传入不定长度的参数。就比如下面的这个 `printVariable` 方法就可以接受 0 个或者多个参数。 + +```java +public static void method1(String... args) { + //...... +} +``` + +另外，可变参数只能作为函数的最后一个参数，但其前面可以有也可以没有任何其他参数。 + +```java +public static void method2(String arg1, String... args) { + //...... +} +``` + +**遇到方法重载的情况怎么办呢？会优先匹配固定参数还是可变参数的方法呢？** + +答案是会优先匹配固定参数的方法，因为固定参数的方法匹配度更高。 + +我们通过下面这个例子来证明一下。 + +```java +/** + * 微信搜 JavaGuide 回复"面试突击"即可免费领取个人原创的 Java 面试手册 + * + * @author Guide哥 + * @date 2021/12/13 16:52 + **/ +public class VariableLengthArgument { + + public static void printVariable(String... args) { + for (String s : args) { + System.out.println(s); + } + } + + public static void printVariable(String arg1, String arg2) { + System.out.println(arg1 + arg2); + } + + public static void main(String[] args) { + printVariable("a", "b"); + printVariable("a", "b", "c", "d"); + } +} +``` + +输出： + +``` +ab +a +b +c +d +``` + +另外，Java 的可变参数编译后实际会被转换成一个数组，我们看编译后生成的 `class`文件就可以看出来了。 + +```java +public class VariableLengthArgument { + + public static void printVariable(String... args) { + String[] var1 = args; + int var2 = args.length; + + for(int var3 = 0; var3 < var2; ++var3) { + String s = var1[var3]; + System.out.println(s); + } + + } + // ...... +} +``` + +## 基本数据类型 + +### Java 中的几种基本数据类型了解么？ + +Java 中有 8 种基本数据类型，分别为： + +1. 6 种数字类型： + - 4 种整数型：`byte`、`short`、`int`、`long` + - 2 种浮点型：`float`、`double` +2. 1 种字符类型：`char` +3. 1 种布尔型：`boolean`。 + +这 8 种基本数据类型的默认值以及所占空间的大小如下： + +| 基本类型 | 位数 | 字节 | 默认值 | 取值范围 | +| :-------- | :--- | :--- | :------ | ------------------------------------------ | +| `byte` | 8 | 1 | 0 | -128 ~ 127 | +| `short` | 16 | 2 | 0 | -32768 ~ 32767 | +| `int` | 32 | 4 | 0 | -2147483648 ~ 2147483647 | +| `long` | 64 | 8 | 0L | -9223372036854775808 ~ 9223372036854775807 | +| `char` | 16 | 2 | 'u0000' | 0 ~ 65535 | +| `float` | 32 | 4 | 0f | 1.4E-45 ~ 3.4028235E38 | +| `double` | 64 | 8 | 0d | 4.9E-324 ~ 1.7976931348623157E308 | +| `boolean` | 1 | | false | true、false | + +对于 `boolean`，官方文档未明确定义，它依赖于 JVM 厂商的具体实现。逻辑上理解是占用 1 位，但是实际中会考虑计算机高效存储因素。 + +另外，Java 的每种基本类型所占存储空间的大小不会像其他大多数语言那样随机器硬件架构的变化而变化。这种所占存储空间大小的不变性是 Java 程序比用其他大多数语言编写的程序更具可移植性的原因之一（《Java 编程思想》2.2 节有提到）。 + +**注意：** + +1. Java 里使用 `long` 类型的数据一定要在数值后面加上 **L**，否则将作为整型解析。 +2. `char a = 'h'`char :单引号，`String a = "hello"` :双引号。 + +这八种基本类型都有对应的包装类分别为：`Byte`、`Short`、`Integer`、`Long`、`Float`、`Double`、`Character`、`Boolean` 。 + +包装类型不赋值就是 `Null` ，而基本类型有默认值且不是 `Null`。 + +另外，这个问题建议还可以先从 JVM 层面来分析。 + +基本数据类型直接存放在 Java 虚拟机栈中的局部变量表中，而包装类型属于对象类型，我们知道对象实例都存在于堆中。相比于对象类型， 基本数据类型占用的空间非常小。 + +> 《深入理解 Java 虚拟机》 ：局部变量表主要存放了编译期可知的基本数据类型 **（boolean、byte、char、short、int、float、long、double）**、**对象引用**（reference 类型，它不同于对象本身，可能是一个指向对象起始地址的引用指针，也可能是指向一个代表对象的句柄或其他与此对象相关的位置）。 + +### 包装类型的常量池技术了解么？ + +Java 基本类型的包装类的大部分都实现了常量池技术。 + +`Byte`,`Short`,`Integer`,`Long` 这 4 种包装类默认创建了数值 **[-128，127]** 的相应类型的缓存数据，`Character` 创建了数值在 **[0,127]** 范围的缓存数据，`Boolean` 直接返回 `True` or `False`。 + +**Integer 缓存源码：** + +```java +public static Integer valueOf(int i) { + if (i >= IntegerCache.low && i <= IntegerCache.high) + return IntegerCache.cache[i + (-IntegerCache.low)]; + return new Integer(i); +} +private static class IntegerCache { + static final int low = -128; + static final int high; + static { + // high value may be configured by property + int h = 127; + } +} +``` + +**`Character` 缓存源码:** + +```java +public static Character valueOf(char c) { + if (c <= 127) { // must cache + return CharacterCache.cache[(int)c]; + } + return new Character(c); +} + +private static class CharacterCache { + private CharacterCache(){} + static final Character cache[] = new Character[127 + 1]; + static { + for (int i = 0; i < cache.length; i++) + cache[i] = new Character((char)i); + } + +} +``` + +**`Boolean` 缓存源码：** + +```java +public static Boolean valueOf(boolean b) { + return (b ? TRUE : FALSE); +} +``` + +如果超出对应范围仍然会去创建新的对象，缓存的范围区间的大小只是在性能和资源之间的权衡。 + +两种浮点数类型的包装类 `Float`,`Double` 并没有实现常量池技术。 + +```java +Integer i1 = 33; +Integer i2 = 33; +System.out.println(i1 == i2);// 输出 true + +Float i11 = 333f; +Float i22 = 333f; +System.out.println(i11 == i22);// 输出 false + +Double i3 = 1.2; +Double i4 = 1.2; +System.out.println(i3 == i4);// 输出 false +``` + +下面我们来看一下问题。下面的代码的输出结果是 `true` 还是 `false` 呢？ + +```java +Integer i1 = 40; +Integer i2 = new Integer(40); +System.out.println(i1==i2); +``` + +`Integer i1=40` 这一行代码会发生装箱，也就是说这行代码等价于 `Integer i1=Integer.valueOf(40)` 。因此，`i1` 直接使用的是常量池中的对象。而`Integer i2 = new Integer(40)` 会直接创建新的对象。 + +因此，答案是 `false` 。你答对了吗？ + +记住：**所有整型包装类对象之间值的比较，全部使用 equals 方法比较**。 + +![](https://img-blog.csdnimg.cn/20210422164544846.png) + +### 自动装箱与拆箱了解吗？原理是什么？ + +**什么是自动拆装箱？** + +- **装箱**：将基本类型用它们对应的引用类型包装起来； +- **拆箱**：将包装类型转换为基本数据类型； + +举例： + +```java +Integer i = 10; //装箱 +int n = i; //拆箱 +``` + +上面这两行代码对应的字节码为： + +```java + L1 + + LINENUMBER 8 L1 + + ALOAD 0 + + BIPUSH 10 + + INVOKESTATIC java/lang/Integer.valueOf (I)Ljava/lang/Integer; + + PUTFIELD AutoBoxTest.i : Ljava/lang/Integer; + + L2 + + LINENUMBER 9 L2 + + ALOAD 0 + + ALOAD 0 + + GETFIELD AutoBoxTest.i : Ljava/lang/Integer; + + INVOKEVIRTUAL java/lang/Integer.intValue ()I + + PUTFIELD AutoBoxTest.n : I + + RETURN +``` + +从字节码中，我们发现装箱其实就是调用了 包装类的`valueOf()`方法，拆箱其实就是调用了 `xxxValue()`方法。 + +因此， + +- `Integer i = 10` 等价于 `Integer i = Integer.valueOf(10)` +- `int n = i` 等价于 `int n = i.intValue()`; + +注意：**如果频繁拆装箱的话，也会严重影响系统的性能。我们应该尽量避免不必要的拆装箱操作。** + +```java +private static long sum() { + // 应该使用 long 而不是 Long + Long sum = 0L; + for (long i = 0; i <= Integer.MAX_VALUE; i++) + sum += i; + return sum; +} +``` + +## 参考 + +- https://stackoverflow.com/questions/1906445/what-is-the-difference-between-jdk-and-jre +- https://www.educba.com/oracle-vs-openjdk/ +- https://stackoverflow.com/questions/22358071/differences-between-oracle-jdk-and-openjdk diff --git a/docs/java/basis/java-basic-questions-02.md b/docs/java/basis/java-basic-questions-02.md new file mode 100644 index 0000000000000000000000000000000000000000..064a66cf106d6721332e20af0930950e02149aa3 --- /dev/null +++ b/docs/java/basis/java-basic-questions-02.md @@ -0,0 +1,351 @@ +--- +title: Java基础常见知识&面试题总结(中) +category: Java +tag: + - Java基础 +--- + +## 面向对象基础 + +### 面向对象和面向过程的区别 + +两者的主要区别在于解决问题的方式不同： + +- 面向过程把解决问题的过程拆成一个个方法，通过一个个方法的执行解决问题。 +- 面向对象会先抽象出对象，然后用对象执行方法的方式解决问题。 + +另外，面向对象开发的程序一般更易维护、易复用、易扩展。 + +相关 issue : [面向过程 ：面向过程性能比面向对象高？？](https://github.com/Snailclimb/JavaGuide/issues/431) + +### 成员变量与局部变量的区别有哪些？ + +- **语法形式** ：从语法形式上看，成员变量是属于类的，而局部变量是在代码块或方法中定义的变量或是方法的参数；成员变量可以被 `public`,`private`,`static` 等修饰符所修饰，而局部变量不能被访问控制修饰符及 `static` 所修饰；但是，成员变量和局部变量都能被 `final` 所修饰。 +- **存储方式** ：从变量在内存中的存储方式来看,如果成员变量是使用 `static` 修饰的，那么这个成员变量是属于类的，如果没有使用 `static` 修饰，这个成员变量是属于实例的。而对象存在于堆内存，局部变量则存在于栈内存。 +- **生存时间** ：从变量在内存中的生存时间上看，成员变量是对象的一部分，它随着对象的创建而存在，而局部变量随着方法的调用而自动消失。 +- **默认值** ：从变量是否有默认值来看，成员变量如果没有被赋初始值，则会自动以类型的默认值而赋值（一种情况例外:被 `final` 修饰的成员变量也必须显式地赋值），而局部变量则不会自动赋值。 + +### 创建一个对象用什么运算符?对象实体与对象引用有何不同? + +new 运算符，new 创建对象实例（对象实例在堆内存中），对象引用指向对象实例（对象引用存放在栈内存中）。 + +一个对象引用可以指向 0 个或 1 个对象（一根绳子可以不系气球，也可以系一个气球）;一个对象可以有 n 个引用指向它（可以用 n 条绳子系住一个气球）。 + +### 对象的相等与指向他们的引用相等,两者有什么不同? + +- 对象的相等一般比较的是内存中存放的内容是否相等。 +- 引用相等一般比较的是他们指向的内存地址是否相等。 + +### 一个类的构造方法的作用是什么? + +构造方法是一种特殊的方法，主要作用是完成对象的初始化工作。 + +### 如果一个类没有声明构造方法，该程序能正确执行吗? + +如果一个类没有声明构造方法，也可以执行！因为一个类即使没有声明构造方法也会有默认的不带参数的构造方法。如果我们自己添加了类的构造方法（无论是否有参），Java 就不会再添加默认的无参数的构造方法了，这时候，就不能直接 new 一个对象而不传递参数了，所以我们一直在不知不觉地使用构造方法，这也是为什么我们在创建对象的时候后面要加一个括号（因为要调用无参的构造方法）。如果我们重载了有参的构造方法，记得都要把无参的构造方法也写出来（无论是否用到），因为这可以帮助我们在创建对象的时候少踩坑。 + +### 构造方法有哪些特点？是否可被 override? + +构造方法特点如下： + +- 名字与类名相同。 +- 没有返回值，但不能用 void 声明构造函数。 +- 生成类的对象时自动执行，无需调用。 + +构造方法不能被 override（重写）,但是可以 overload（重载）,所以你可以看到一个类中有多个构造函数的情况。 + +### 面向对象三大特征 + +#### 封装 + +封装是指把一个对象的状态信息（也就是属性）隐藏在对象内部，不允许外部对象直接访问对象的内部信息。但是可以提供一些可以被外界访问的方法来操作属性。就好像我们看不到挂在墙上的空调的内部的零件信息（也就是属性），但是可以通过遥控器（方法）来控制空调。如果属性不想被外界访问，我们大可不必提供方法给外界访问。但是如果一个类没有提供给外界访问的方法，那么这个类也没有什么意义了。就好像如果没有空调遥控器，那么我们就无法操控空凋制冷，空调本身就没有意义了（当然现在还有很多其他方法 ，这里只是为了举例子）。 + +```java +public class Student { + private int id;//id属性私有化 + private String name;//name属性私有化 + + //获取id的方法 + public int getId() { + return id; + } + + //设置id的方法 + public void setId(int id) { + this.id = id; + } + + //获取name的方法 + public String getName() { + return name; + } + + //设置name的方法 + public void setName(String name) { + this.name = name; + } +} +``` + +#### 继承 + +不同类型的对象，相互之间经常有一定数量的共同点。例如，小明同学、小红同学、小李同学，都共享学生的特性（班级、学号等）。同时，每一个对象还定义了额外的特性使得他们与众不同。例如小明的数学比较好，小红的性格惹人喜爱；小李的力气比较大。继承是使用已存在的类的定义作为基础建立新类的技术，新类的定义可以增加新的数据或新的功能，也可以用父类的功能，但不能选择性地继承父类。通过使用继承，可以快速地创建新的类，可以提高代码的重用，程序的可维护性，节省大量创建新类的时间 ，提高我们的开发效率。 + +**关于继承如下 3 点请记住：** + +1. 子类拥有父类对象所有的属性和方法（包括私有属性和私有方法），但是父类中的私有属性和方法子类是无法访问，**只是拥有**。 +2. 子类可以拥有自己属性和方法，即子类可以对父类进行扩展。 +3. 子类可以用自己的方式实现父类的方法。（以后介绍）。 + +#### 多态 + +多态，顾名思义，表示一个对象具有多种的状态，具体表现为父类的引用指向子类的实例。 + +**多态的特点:** + +- 对象类型和引用类型之间具有继承（类）/实现（接口）的关系； +- 引用类型变量发出的方法调用的到底是哪个类中的方法，必须在程序运行期间才能确定； +- 多态不能调用“只在子类存在但在父类不存在”的方法； +- 如果子类重写了父类的方法，真正执行的是子类覆盖的方法，如果子类没有覆盖父类的方法，执行的是父类的方法。 + +### 接口和抽象类有什么共同点和区别？ + +**共同点** ： + +- 都不能被实例化。 +- 都可以包含抽象方法。 +- 都可以有默认实现的方法（Java 8 可以用 `default` 关键在接口中定义默认方法）。 + +**区别** ： + +- 接口主要用于对类的行为进行约束，你实现了某个接口就具有了对应的行为。抽象类主要用于代码复用，强调的是所属关系（比如说我们抽象了一个发送短信的抽象类，）。 +- 一个类只能继承一个类，但是可以实现多个接口。 +- 接口中的成员变量只能是 `public static final` 类型的，不能被修改且必须有初始值，而抽象类的成员变量默认 default，可在子类中被重新定义，也可被重新赋值。 + +### 深拷贝和浅拷贝区别了解吗？什么是引用拷贝？ + +关于深拷贝和浅拷贝区别，我这里先给结论： + +- **浅拷贝**：浅拷贝会在堆上创建一个新的对象（区别于引用拷贝的一点），不过，如果原对象内部的属性是引用类型的话，浅拷贝会直接复制内部对象的引用地址，也就是说拷贝对象和原对象共用同一个内部对象。 +- **深拷贝** ：深拷贝会完全复制整个对象，包括这个对象所包含的内部对象。 + +上面的结论没有完全理解的话也没关系，我们来看一个具体的案例！ + +**浅拷贝** + +浅拷贝的示例代码如下，我们这里实现了 `Cloneable` 接口，并重写了 `clone()` 方法。 + +`clone()` 方法的实现很简单，直接调用的是父类 `Object` 的 `clone()` 方法。 + +```java +public class Address implements Cloneable{ + private String name; + // 省略构造函数、Getter&Setter方法 + @Override + public Address clone() { + try { + return (Address) super.clone(); + } catch (CloneNotSupportedException e) { + throw new AssertionError(); + } + } +} + +public class Person implements Cloneable { + private Address address; + // 省略构造函数、Getter&Setter方法 + @Override + public Person clone() { + try { + Person person = (Person) super.clone(); + return person; + } catch (CloneNotSupportedException e) { + throw new AssertionError(); + } + } +} +``` + +测试 ： + +```java +Person person1 = new Person(new Address("武汉")); +Person person1Copy = person1.clone(); +// true +System.out.println(person1.getAddress() == person1Copy.getAddress()); +``` + +从输出结构就可以看出， `person1` 的克隆对象和 `person1` 使用的仍然是同一个 `Address` 对象。 + +**深拷贝** + +这里我们简单对 `Person` 类的 `clone()` 方法进行修改，连带着要把 `Person` 对象内部的 `Address` 对象一起复制。 + +```java +@Override +public Person clone() { + try { + Person person = (Person) super.clone(); + person.setAddress(person.getAddress().clone()); + return person; + } catch (CloneNotSupportedException e) { + throw new AssertionError(); + } +} +``` + +测试 ： + +```java +Person person1 = new Person(new Address("武汉")); +Person person1Copy = person1.clone(); +// false +System.out.println(person1.getAddress() == person1Copy.getAddress()); +``` + +从输出结构就可以看出，虽然 `person1` 的克隆对象和 `person1` 包含的 `Address` 对象已经是不同的了。 + +**那什么是引用拷贝呢？** 简单来说，引用拷贝就是两个不同的引用指向同一个对象。 + +我专门画了一张图来描述浅拷贝、深拷贝、引用拷贝： + +![](./images/shallow&deep-copy.png) + +## Java 常见对象 + +### Object + +#### Object 类的常见方法有哪些？ + +Object 类是一个特殊的类，是所有类的父类。它主要提供了以下 11 个方法： + +```java +public final native Class getClass()//native方法，用于返回当前运行时对象的Class对象，使用了final关键字修饰，故不允许子类重写。 + +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方法一样，只不过该方法一直等待，没有超时时间这个概念 + +protected void finalize() throws Throwable { }//实例被垃圾回收器回收的时候触发的操作 +``` + +### String + +#### String、StringBuffer、StringBuilder 的区别？String 为什么是不可变的? + +**可变性** + +简单的来说：`String` 类中使用 `final` 关键字修饰字符数组来保存字符串，~~所以`String` 对象是不可变的。~~ + +```java +public final class String implements java.io.Serializable, Comparable, CharSequence { + private final char value[]; + //... +} +``` + +> 🐛 修正 ： 我们知道被 `final` 关键字修饰的类不能被继承，修饰的方法不能被重写，修饰的变量是基本数据类型则值不能改变，修饰的变量是引用类型则不能再指向其他对象。因此，`final` 关键字修饰的数组保存字符串并不是 `String` 不可变的根本原因，因为这个数组保存的字符串是可变的（`final` 修饰引用类型变量的情况）。 +> +> `String` 真正不可变有下面几点原因： +> +> 1. 保存字符串的数组被 `final` 修饰且为私有的，并且`String` 类没有提供/暴露修改这个字符串的方法。 +> 2. `String` 类被 `final` 修饰导致其不能被继承，进而避免了子类破坏 `String` 不可变。 +> +> 相关阅读：[如何理解 String 类型值的不可变？ - 知乎提问](https://www.zhihu.com/question/20618891/answer/114125846) +> +> 补充（来自[issue 675](https://github.com/Snailclimb/JavaGuide/issues/675)）：在 Java 9 之后，`String` 、`StringBuilder` 与 `StringBuffer` 的实现改用 byte 数组存储字符串。 + +`StringBuilder` 与 `StringBuffer` 都继承自 `AbstractStringBuilder` 类，在 `AbstractStringBuilder` 中也是使用字符数组保存字符串，不过没有使用 `final` 和 `private` 关键字修饰，最关键的是这个 `AbstractStringBuilder` 类还提供了很多修改字符串的方法比如 `append` 方法。 + +```java +abstract class AbstractStringBuilder implements Appendable, CharSequence { + char[] value; + public AbstractStringBuilder append(String str) { + if (str == null) + return appendNull(); + int len = str.length(); + ensureCapacityInternal(count + len); + str.getChars(0, len, value, count); + count += len; + return this; + } + //... +} +``` + +**线程安全性** + +`String` 中的对象是不可变的，也就可以理解为常量，线程安全。`AbstractStringBuilder` 是 `StringBuilder` 与 `StringBuffer` 的公共父类，定义了一些字符串的基本操作，如 `expandCapacity`、`append`、`insert`、`indexOf` 等公共方法。`StringBuffer` 对方法加了同步锁或者对调用的方法加了同步锁，所以是线程安全的。`StringBuilder` 并没有对方法进行加同步锁，所以是非线程安全的。 + +**性能** + +每次对 `String` 类型进行改变的时候，都会生成一个新的 `String` 对象，然后将指针指向新的 `String` 对象。`StringBuffer` 每次都会对 `StringBuffer` 对象本身进行操作，而不是生成新的对象并改变对象引用。相同情况下使用 `StringBuilder` 相比使用 `StringBuffer` 仅能获得 10%~15% 左右的性能提升，但却要冒多线程不安全的风险。 + +**对于三者使用的总结：** + +1. 操作少量的数据: 适用 `String` +2. 单线程操作字符串缓冲区下操作大量数据: 适用 `StringBuilder` +3. 多线程操作字符串缓冲区下操作大量数据: 适用 `StringBuffer` + +#### 字符串拼接用“+” 还是 StringBuilder? + +Java 语言本身并不支持运算符重载，“+”和“+=”是专门为 String 类重载过的运算符，也是 Java 中仅有的两个重载过的元素符。 + +```java +String str1 = "he"; +String str2 = "llo"; +String str3 = "world"; +String str4 = str1 + str2 + str3; +``` + +对象引用和“+”的字符串拼接方式，实际上是通过 `StringBuilder` 调用 `append()` 方法实现的，拼接完成之后调用 `toString()` 得到一个 `String` 对象 。 + +![](https://guide-blog-images.oss-cn-shenzhen.aliyuncs.com/touzi/image-20220131173604062.png) + +不过，在循环内使用“+”进行字符串的拼接的话，存在比较明显的缺陷：**编译器不会创建单个 `StringBuilder` 以复用，会导致创建过多的 `StringBuilder` 对象**。 + +```java +String[] arr = {"he", "llo", "world"}; +String s = ""; +for (int i = 0; i < arr.length; i++) { + s += arr[i]; +} +System.out.println(s); +``` + +`StringBuilder` 对象是在循环内部被创建的，这意味着每循环一次就会创建一个 `StringBuilder` 对象。 + +![](https://guide-blog-images.oss-cn-shenzhen.aliyuncs.com/touzi/image-20220131175013108.png) + +如果直接使用 `StringBuilder` 对象进行字符串拼接的话，就不会存在这个问题了。 + +#### String#equals() 和 Object#equals() 有何区别？ + +`String` 中的 `equals` 方法是被重写过的，比较的是 String 字符串的值是否相等。 `Object` 的 `equals` 方法是比较的对象的内存地址。 + +#### 字符串常量池的作用了解吗？ + +**字符串常量池** 是 JVM 为了提升性能和减少内存消耗针对字符串（String 类）专门开辟的一块区域，主要目的是为了避免字符串的重复创建。 + +```java +String aa = "ab"; // 放在常量池中 +String bb = "ab"; // 从常量池中查找 +System.out.println(aa==bb);// true +``` + +JDK1.7 之前运行时常量池逻辑包含字符串常量池存放在方法区。JDK1.7 的时候，字符串常量池被从方法区拿到了堆中。 + +你可以在 JVM 部分找到更多关于字符串常量池的介绍。 diff --git a/docs/java/basis/java-basic-questions-03.md b/docs/java/basis/java-basic-questions-03.md new file mode 100644 index 0000000000000000000000000000000000000000..a4320573f98d2c6c8eda648cbc916579ccc4ce21 --- /dev/null +++ b/docs/java/basis/java-basic-questions-03.md @@ -0,0 +1,471 @@ +--- +title: Java基础知识&面试题总结(下) +category: Java +tag: + - Java基础 +--- + +## 泛型 + +#### Java 泛型了解么？什么是类型擦除？介绍一下常用的通配符？ + +**Java 泛型（generics）** 是 JDK 5 中引入的一个新特性, 泛型提供了编译时类型安全检测机制，该机制允许程序员在编译时检测到非法的类型。泛型的本质是参数化类型，也就是说所操作的数据类型被指定为一个参数。 + +Java 的泛型是伪泛型，这是因为 Java 在运行期间，所有的泛型信息都会被擦掉，这也就是通常所说类型擦除 。 + +```java +List list = new ArrayList<>(); + +list.add(12); +//这里直接添加会报错 +list.add("a"); +Class clazz = list.getClass(); +Method add = clazz.getDeclaredMethod("add", Object.class); +//但是通过反射添加是可以的 +//这就说明在运行期间所有的泛型信息都会被擦掉 +add.invoke(list, "kl"); +System.out.println(list); +``` + +泛型一般有三种使用方式: 泛型类、泛型接口、泛型方法。 + +**1.泛型类**： + +```java +//此处T可以随便写为任意标识，常见的如T、E、K、V等形式的参数常用于表示泛型 +//在实例化泛型类时，必须指定T的具体类型 +public class Generic { + private T key; + public Generic(T key) { + this.key = key; + } + public T getKey() { + return key; + } +} +``` + +如何实例化泛型类： + +```java +Generic genericInteger = new Generic(123456); +``` + +**2.泛型接口** ： + +```java +public interface Generator { + public T method(); +} +``` + +实现泛型接口，不指定类型： + +```java +class GeneratorImpl implements Generator{ + @Override + public T method() { + return null; + } +} +``` + +实现泛型接口，指定类型： + +```java +class GeneratorImpl implements Generator{ + @Override + public String method() { + return "hello"; + } +} +``` + +**3.泛型方法** ： + +```java +public static void printArray(E[] inputArray) { + for (E element : inputArray) { + System.out.printf("%s ", element); + } + System.out.println(); +} +``` + +使用： + +```java +// 创建不同类型数组： Integer, Double 和 Character +Integer[] intArray = { 1, 2, 3 }; +String[] stringArray = { "Hello", "World" }; +printArray(intArray); +printArray(stringArray); +``` + +#### 常用的通配符有哪些？ + +**常用的通配符为： T，E，K，V，？** + +- ？ 表示不确定的 Java 类型 +- T (type) 表示具体的一个 Java 类型 +- K V (key value) 分别代表 Java 键值中的 Key Value +- E (element) 代表 Element + +#### 你的项目中哪里用到了泛型？ + +- 可用于定义通用返回结果 `CommonResult` 通过参数 `T` 可根据具体的返回类型动态指定结果的数据类型 +- 定义 `Excel` 处理类 `ExcelUtil` 用于动态指定 `Excel` 导出的数据类型 +- 用于构建集合工具类。参考 `Collections` 中的 `sort`, `binarySearch` 方法 +- ...... + +## 反射 + +### 何为反射？ + +如果说大家研究过框架的底层原理或者咱们自己写过框架的话，一定对反射这个概念不陌生。 + +反射之所以被称为框架的灵魂，主要是因为它赋予了我们在运行时分析类以及执行类中方法的能力。 + +通过反射你可以获取任意一个类的所有属性和方法，你还可以调用这些方法和属性。 + +### 反射机制优缺点 + +- **优点** ： 可以让咱们的代码更加灵活、为各种框架提供开箱即用的功能提供了便利 +- **缺点** ：让我们在运行时有了分析操作类的能力，这同样也增加了安全问题。比如可以无视泛型参数的安全检查（泛型参数的安全检查发生在编译时）。另外，反射的性能也要稍差点，不过，对于框架来说实际是影响不大的。[Java Reflection: Why is it so slow?](https://stackoverflow.com/questions/1392351/java-reflection-why-is-it-so-slow) + +### 反射的应用场景 + +像咱们平时大部分时候都是在写业务代码，很少会接触到直接使用反射机制的场景。 + +但是，这并不代表反射没有用。相反，正是因为反射，你才能这么轻松地使用各种框架。像 Spring/Spring Boot、MyBatis 等等框架中都大量使用了反射机制。 + +**这些框架中也大量使用了动态代理，而动态代理的实现也依赖反射。** + +比如下面是通过 JDK 实现动态代理的示例代码，其中就使用了反射类 `Method` 来调用指定的方法。 + +```java +public class DebugInvocationHandler implements InvocationHandler { + /** + * 代理类中的真实对象 + */ + private final Object target; + + public DebugInvocationHandler(Object target) { + this.target = target; + } + + + public Object invoke(Object proxy, Method method, Object[] args) throws InvocationTargetException, IllegalAccessException { + System.out.println("before method " + method.getName()); + Object result = method.invoke(target, args); + System.out.println("after method " + method.getName()); + return result; + } +} + +``` + +另外，像 Java 中的一大利器 **注解** 的实现也用到了反射。 + +为什么你使用 Spring 的时候 ，一个`@Component`注解就声明了一个类为 Spring Bean 呢？为什么你通过一个 `@Value`注解就读取到配置文件中的值呢？究竟是怎么起作用的呢？ + +这些都是因为你可以基于反射分析类，然后获取到类/属性/方法/方法的参数上的注解。你获取到注解之后，就可以做进一步的处理。 + +## 注解 + +`Annontation` （注解） 是Java5 开始引入的新特性，可以看作是一种特殊的注释，主要用于修饰类、方法或者变量。 + +注解本质是一个继承了`Annotation` 的特殊接口： + +```java +@Target(ElementType.METHOD) +@Retention(RetentionPolicy.SOURCE) +public @interface Override { + +} + +public interface Override extends Annotation{ + +} +``` + +注解只有被解析之后才会生效，常见的解析方法有两种： + +- **编译期直接扫描** ：编译器在编译 Java 代码的时候扫描对应的注解并处理，比如某个方法使用`@Override` 注解，编译器在编译的时候就会检测当前的方法是否重写了父类对应的方法。 +- **运行期通过反射处理** ：像框架中自带的注解(比如 Spring 框架的 `@Value` 、`@Component`)都是通过反射来进行处理的。 + +JDK 提供了很多内置的注解（比如 `@Override` 、`@Deprecated`），同时，我们还可以自定义注解。 + +## 异常 + +**Java 异常类层次结构图概览** ： + +![types-of-exceptions-in-java](./images/types-of-exceptions-in-java.png) + + + +![](https://guide-blog-images.oss-cn-shenzhen.aliyuncs.com/2020-12/Java%E5%BC%82%E5%B8%B8%E7%B1%BB%E5%B1%82%E6%AC%A1%E7%BB%93%E6%9E%84%E5%9B%BE2.png) + +

图片来自：https://chercher.tech/java-programming/exceptions-java

+ +### Exception 和 Error 有什么区别？ + +在 Java 中，所有的异常都有一个共同的祖先 `java.lang` 包中的 `Throwable` 类。`Throwable` 类有两个重要的子类: + +- **`Exception`** :程序本身可以处理的异常，可以通过 `catch` 来进行捕获。`Exception` 又可以分为 Checked Exception (受检查异常，必须处理) 和 Unchecked Exception (不受检查异常，可以不处理)。 +- **`Error`** ：`Error` 属于程序无法处理的错误 ，我们没办法通过 `catch` 来进行捕获 。例如Java 虚拟机运行错误（`Virtual MachineError`）、虚拟机内存不够错误(`OutOfMemoryError`)、类定义错误（`NoClassDefFoundError`）等 。这些异常发生时，Java 虚拟机（JVM）一般会选择线程终止。 + +### Checked Exception 和 Unchecked Exception 有什么区别？ + +**Checked Exception** 即受检查异常，Java 代码在编译过程中，如果受检查异常没有被 `catch`/`throw` 处理的话，就没办法通过编译 。 + +比如下面这段 IO 操作的代码： + +![](./images/checked-exception.png) + +除了`RuntimeException`及其子类以外，其他的`Exception`类及其子类都属于受检查异常 。常见的受检查异常有： IO 相关的异常、`ClassNotFoundException` 、`SQLException`...。 + +**Unchecked Exception** 即 **不受检查异常** ，Java 代码在编译过程中 ，我们即使不处理不受检查异常也可以正常通过编译。 + +`RuntimeException` 及其子类都统称为非受检查异常，例如：`NullPointerException`、`NumberFormatException`（字符串转换为数字）、`ArrayIndexOutOfBoundsException`（数组越界）、`ClassCastException`（类型转换错误）、`ArithmeticException`（算术错误）等。 + +![](./images/unchecked-exception.png) + +### Throwable 类常用方法有哪些？ + +- `String getMessage()`: 返回异常发生时的简要描述 +- `String toString()`: 返回异常发生时的详细信息 +- `String getLocalizedMessage()`: 返回异常对象的本地化信息。使用 `Throwable` 的子类覆盖这个方法，可以生成本地化信息。如果子类没有覆盖该方法，则该方法返回的信息与 `getMessage()`返回的结果相同 +- `void printStackTrace()`: 在控制台上打印 `Throwable` 对象封装的异常信息 + +### try-catch-finally 如何使用？ + +- **`try`块：** 用于捕获异常。其后可接零个或多个 `catch` 块，如果没有 `catch` 块，则必须跟一个 `finally` 块。 +- **`catch`块：** 用于处理 try 捕获到的异常。 +- **`finally` 块：** 无论是否捕获或处理异常，`finally` 块里的语句都会被执行。当在 `try` 块或 `catch` 块中遇到 `return` 语句时，`finally` 语句块将在方法返回之前被执行。 + +示例： + +```java +try { + System.out.println("Try to do something"); + throw new RuntimeException("RuntimeException"); +} catch (Exception e) { + System.out.println("Catch Exception -> " + e.getMessage()); +} finally { + System.out.println("Finally"); +} +``` + +输出： + +``` +Try to do something +Catch Exception -> RuntimeException +Finally +``` + +**注意：不要在 finally 语句块中使用 return!** 当 try 语句和 finally 语句中都有 return 语句时，try 语句块中的 return 语句会被忽略。这是因为 try 语句中的 return 返回值会先被暂存在一个本地变量中，当执行到 finally 语句中的 return 之后，这个本地变量的值就变为了 finally 语句中的 return 返回值。 + +[jvm 官方文档](https://docs.oracle.com/javase/specs/jvms/se7/html/jvms-4.html#jvms-4.10.2.5)中有明确提到： + +> If the `try` clause executes a *return*, the compiled code does the following: +> +> 1. Saves the return value (if any) in a local variable. +> 2. Executes a *jsr* to the code for the `finally` clause. +> 3. Upon return from the `finally` clause, returns the value saved in the local variable. + +先执行一部分的，先把返回的结果存到一段内存中； + +示例： + +```java +public static void main(String[] args) { + System.out.println(f(2)); +} + +public static int f(int value) { + try { + return value * value; + } finally { + if (value == 2) { + return 0; + } + } +} +``` + +输出： + +``` +0 +``` + +### finally 中的代码一定会执行吗？ + +不一定的！在某些情况下，finally 中的代码不会被执行。 + +就比如说 `finally` 之前虚拟机被终止运行的话，finally 中的代码就不会被执行。 + +```java +try { + System.out.println("Try to do something"); + throw new RuntimeException("RuntimeException"); +} catch (Exception e) { + System.out.println("Catch Exception -> " + e.getMessage()); + // 终止当前正在运行的Java虚拟机 + System.exit(1); +} finally { + System.out.println("Finally"); +} +``` + +输出： + +``` +Try to do something +Catch Exception -> RuntimeException +``` + +另外，在以下 2 种特殊情况下，`finally` 块的代码也不会被执行： + +1. 程序所在的线程死亡。 +2. 关闭 CPU。 + +相关 issue： 。 + +🧗🏻进阶一下：从字节码角度分析`try catch finally`这个语法糖背后的实现原理。 + +### 如何使用 `try-with-resources` 代替`try-catch-finally`？ + +1. **适用范围（资源的定义）：** 任何实现 `java.lang.AutoCloseable`或者 `java.io.Closeable` 的对象 +2. **关闭资源和 finally 块的执行顺序：** 在 `try-with-resources` 语句中，任何 catch 或 finally 块在声明的资源关闭后运行 + +《Effective Java》中明确指出： + +> 面对必须要关闭的资源，我们总是应该优先使用 `try-with-resources` 而不是`try-finally`。随之产生的代码更简短，更清晰，产生的异常对我们也更有用。`try-with-resources`语句让我们更容易编写必须要关闭的资源的代码，若采用`try-finally`则几乎做不到这点。 + +Java 中类似于`InputStream`、`OutputStream` 、`Scanner` 、`PrintWriter`等的资源都需要我们调用`close()`方法来手动关闭，一般情况下我们都是通过`try-catch-finally`语句来实现这个需求，如下： + +```java +//读取文本文件的内容 +Scanner scanner = null; +try { + scanner = new Scanner(new File("D://read.txt")); + while (scanner.hasNext()) { + System.out.println(scanner.nextLine()); + } +} catch (FileNotFoundException e) { + e.printStackTrace(); +} finally { + if (scanner != null) { + scanner.close(); + } +} +``` + +使用 Java 7 之后的 `try-with-resources` 语句改造上面的代码: + +```java +try (Scanner scanner = new Scanner(new File("test.txt"))) { + while (scanner.hasNext()) { + System.out.println(scanner.nextLine()); + } +} catch (FileNotFoundException fnfe) { + fnfe.printStackTrace(); +} +``` + +当然多个资源需要关闭的时候，使用 `try-with-resources` 实现起来也非常简单，如果你还是用`try-catch-finally`可能会带来很多问题。 + +通过使用分号分隔，可以在`try-with-resources`块中声明多个资源。 + +```java +try (BufferedInputStream bin = new BufferedInputStream(new FileInputStream(new File("test.txt"))); + BufferedOutputStream bout = new BufferedOutputStream(new FileOutputStream(new File("out.txt")))) { + int b; + while ((b = bin.read()) != -1) { + bout.write(b); + } + } + catch (IOException e) { + e.printStackTrace(); + } +``` + +## I/O + +### 什么是序列化?什么是反序列化? + +如果我们需要持久化 Java 对象比如将 Java 对象保存在文件中，或者在网络传输 Java 对象，这些场景都需要用到序列化。 + +简单来说： + +- **序列化**： 将数据结构或对象转换成二进制字节流的过程 +- **反序列化**：将在序列化过程中所生成的二进制字节流转换成数据结构或者对象的过程 + +对于 Java 这种面向对象编程语言来说，我们序列化的都是对象（Object）也就是实例化后的类(Class)，但是在 C++这种半面向对象的语言中，struct(结构体)定义的是数据结构类型，而 class 对应的是对象类型。 + +维基百科是如是介绍序列化的： + +> **序列化**（serialization）在计算机科学的数据处理中，是指将数据结构或对象状态转换成可取用格式（例如存成文件，存于缓冲，或经由网络中发送），以留待后续在相同或另一台计算机环境中，能恢复原先状态的过程。依照序列化格式重新获取字节的结果时，可以利用它来产生与原始对象相同语义的副本。对于许多对象，像是使用大量引用的复杂对象，这种序列化重建的过程并不容易。面向对象中的对象序列化，并不概括之前原始对象所关系的函数。这种过程也称为对象编组（marshalling）。从一系列字节提取数据结构的反向操作，是反序列化（也称为解编组、deserialization、unmarshalling）。 + +综上：**序列化的主要目的是通过网络传输对象或者说是将对象存储到文件系统、数据库、内存中。** + +![](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/2020-8/a478c74d-2c48-40ae-9374-87aacf05188c.png) + +

https://www.corejavaguru.com/java/serialization/interview-questions-1

+ +### Java 序列化中如果有些字段不想进行序列化，怎么办？ + +对于不想进行序列化的变量，使用 `transient` 关键字修饰。 + +`transient` 关键字的作用是：阻止实例中那些用此关键字修饰的的变量序列化；当对象被反序列化时，被 `transient` 修饰的变量值不会被持久化和恢复。 + +关于 `transient` 还有几点注意： + +- `transient` 只能修饰变量，不能修饰类和方法。 +- `transient` 修饰的变量，在反序列化后变量值将会被置成类型的默认值。例如，如果是修饰 `int` 类型，那么反序列后结果就是 `0`。 +- `static` 变量因为不属于任何对象(Object)，所以无论有没有 `transient` 关键字修饰，均不会被序列化。 + +### 获取用键盘输入常用的两种方法 + +方法 1：通过 `Scanner` + +```java +Scanner input = new Scanner(System.in); +String s = input.nextLine(); +input.close(); +``` + +方法 2：通过 `BufferedReader` + +```java +BufferedReader input = new BufferedReader(new InputStreamReader(System.in)); +String s = input.readLine(); +``` + +### Java 中 IO 流分为几种? + +- 按照流的流向分，可以分为输入流和输出流； +- 按照操作单元划分，可以划分为字节流和字符流； +- 按照流的角色划分为节点流和处理流。 + +Java IO 流共涉及 40 多个类，这些类看上去很杂乱，但实际上很有规则，而且彼此之间存在非常紧密的联系， Java IO 流的 40 多个类都是从如下 4 个抽象类基类中派生出来的。 + +- InputStream/Reader: 所有的输入流的基类，前者是字节输入流，后者是字符输入流。 +- OutputStream/Writer: 所有输出流的基类，前者是字节输出流，后者是字符输出流。 + +按操作方式分类结构图： + +![IO-操作方式分类](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/2019-6/IO-操作方式分类.png) + +按操作对象分类结构图： + +![IO-操作对象分类](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/2019-6/IO-操作对象分类.png) + +### 既然有了字节流,为什么还要有字符流? + +问题本质想问：**不管是文件读写还是网络发送接收，信息的最小存储单元都是字节，那为什么 I/O 流操作要分为字节流操作和字符流操作呢？** + +回答：字符流是由 Java 虚拟机将字节转换得到的，问题就出在这个过程还算是非常耗时，并且，如果我们不知道编码类型就很容易出现乱码问题。所以， I/O 流就干脆提供了一个直接操作字符的接口，方便我们平时对字符进行流操作。如果音频文件、图片等媒体文件用字节流比较好，如果涉及到字符的话使用字符流比较好。 \ No newline at end of file diff --git "a/Java\347\233\270\345\205\263/final\343\200\201static\343\200\201this\343\200\201super.md" b/docs/java/basis/java-keyword-summary.md similarity index 42% rename from "Java\347\233\270\345\205\263/final\343\200\201static\343\200\201this\343\200\201super.md" rename to docs/java/basis/java-keyword-summary.md index 2c8a917f710241d5a97ed04c0937c884d45dea4b..141b6778cb04ec11331adca3d1858519558ceb7d 100644 --- "a/Java\347\233\270\345\205\263/final\343\200\201static\343\200\201this\343\200\201super.md" +++ b/docs/java/basis/java-keyword-summary.md @@ -1,85 +1,60 @@ - - -- [final,static,this,super 关键字总结](#finalstaticthissuper-关键字总结) - - [final 关键字](#final-关键字) - - [static 关键字](#static-关键字) - - [this 关键字](#this-关键字) - - [super 关键字](#super-关键字) - - [参考](#参考) -- [static 关键字详解](#static-关键字详解) - - [static 关键字主要有以下四种使用场景](#static-关键字主要有以下四种使用场景) - - [修饰成员变量和成员方法\(常用\)](#修饰成员变量和成员方法常用) - - [静态代码块](#静态代码块) - - [静态内部类](#静态内部类) - - [静态导包](#静态导包) - - [补充内容](#补充内容) - - [静态方法与非静态方法](#静态方法与非静态方法) - - [static{}静态代码块与{}非静态代码块\(构造代码块\)](#static静态代码块与非静态代码块构造代码块) - - [参考](#参考-1) - - - # final,static,this,super 关键字总结 ## final 关键字 -**final关键字主要用在三个地方：变量、方法、类。** +**final 关键字，意思是最终的、不可修改的，最见不得变化 ，用来修饰类、方法和变量，具有以下特点：** + +1. final 修饰的类不能被继承，final 类中的所有成员方法都会被隐式的指定为 final 方法； -1. **对于一个final变量，如果是基本数据类型的变量，则其数值一旦在初始化之后便不能更改；如果是引用类型的变量，则在对其初始化之后便不能再让其指向另一个对象。** +2. final 修饰的方法不能被重写； -2. **当用final修饰一个类时，表明这个类不能被继承。final类中的所有成员方法都会被隐式地指定为final方法。** +3. final 修饰的变量是常量，如果是基本数据类型的变量，则其数值一旦在初始化之后便不能更改；如果是引用类型的变量，则在对其初始化之后便不能让其指向另一个对象。 -3. 使用final方法的原因有两个。第一个原因是把方法锁定，以防任何继承类修改它的含义；第二个原因是效率。在早期的Java实现版本中，会将final方法转为内嵌调用。但是如果方法过于庞大，可能看不到内嵌调用带来的任何性能提升（现在的Java版本已经不需要使用final方法进行这些优化了）。类中所有的private方法都隐式地指定为final。 +说明：使用 final 方法的原因有两个。第一个原因是把方法锁定，以防任何继承类修改它的含义；第二个原因是效率。在早期的 Java 实现版本中，会将 final 方法转为内嵌调用。但是如果方法过于庞大，可能看不到内嵌调用带来的任何性能提升（现在的 Java 版本已经不需要使用 final 方法进行这些优化了）。类中所有的 private 方法都隐式地指定为 final。 ## static 关键字 **static 关键字主要有以下四种使用场景：** -1. **修饰成员变量和成员方法:** 被 static 修饰的成员属于类，不属于单个这个类的某个对象，被类中所有对象共享，可以并且建议通过类名调用。被static 声明的成员变量属于静态成员变量，静态变量 存放在 Java 内存区域的方法区。调用格式：`类名.静态变量名` `类名.静态方法名()` +1. **修饰成员变量和成员方法:** 被 static 修饰的成员属于类，不属于单个这个类的某个对象，被类中所有对象共享，可以并且建议通过类名调用。被 static 声明的成员变量属于静态成员变量，静态变量 存放在 Java 内存区域的方法区。调用格式：`类名.静态变量名` `类名.静态方法名()` 2. **静态代码块:** 静态代码块定义在类中方法外, 静态代码块在非静态代码块之前执行(静态代码块—>非静态代码块—>构造方法)。 该类不管创建多少对象，静态代码块只执行一次. -3. **静态内部类（static修饰类的话只能修饰内部类）：** 静态内部类与非静态内部类之间存在一个最大的区别: 非静态内部类在编译完成之后会隐含地保存着一个引用，该引用是指向创建它的外围类，但是静态内部类却没有。没有这个引用就意味着：1. 它的创建是不需要依赖外围类的创建。2. 它不能使用任何外围类的非static成员变量和方法。 -4. **静态导包(用来导入类中的静态资源，1.5之后的新特性):** 格式为：`import static` 这两个关键字连用可以指定导入某个类中的指定静态资源，并且不需要使用类名调用类中静态成员，可以直接使用类中静态成员变量和成员方法。 +3. **静态内部类（static 修饰类的话只能修饰内部类）：** 静态内部类与非静态内部类之间存在一个最大的区别: 非静态内部类在编译完成之后会隐含地保存着一个引用，该引用是指向创建它的外围类，但是静态内部类却没有。没有这个引用就意味着：1. 它的创建是不需要依赖外围类的创建。2. 它不能使用任何外围类的非 static 成员变量和方法。 +4. **静态导包(用来导入类中的静态资源，1.5 之后的新特性):** 格式为：`import static` 这两个关键字连用可以指定导入某个类中的指定静态资源，并且不需要使用类名调用类中静态成员，可以直接使用类中静态成员变量和成员方法。 ## this 关键字 -this关键字用于引用类的当前实例。 例如： +this 关键字用于引用类的当前实例。 例如： ```java class Manager { Employees[] employees; - void manageEmployees() { int totalEmp = this.employees.length; System.out.println("Total employees: " + totalEmp); this.report(); } - void report() { } } ``` -在上面的示例中，this关键字用于两个地方： +在上面的示例中，this 关键字用于两个地方： -- this.employees.length：访问类Manager的当前实例的变量。 -- this.report（）：调用类Manager的当前实例的方法。 +- this.employees.length：访问类 Manager 的当前实例的变量。 +- this.report（）：调用类 Manager 的当前实例的方法。 此关键字是可选的，这意味着如果上面的示例在不使用此关键字的情况下表现相同。 但是，使用此关键字可能会使代码更易读或易懂。 - - ## super 关键字 -super关键字用于从子类访问父类的变量和方法。 例如： +super 关键字用于从子类访问父类的变量和方法。 例如： ```java public class Super { protected int number; - protected showNumber() { System.out.println("number = " + number); } } - public class Sub extends Super { void bar() { super.number = 10; @@ -88,18 +63,16 @@ public class Sub extends Super { } ``` -在上面的例子中，Sub 类访问父类成员变量 number 并调用其其父类 Super 的 `showNumber（）` 方法。 +在上面的例子中，Sub 类访问父类成员变量 number 并调用其父类 Super 的 `showNumber（）` 方法。 **使用 this 和 super 要注意的问题：** -- super 调用父类中的其他构造方法时，调用时要放在构造方法的首行！this 调用本类中的其他构造方法时，也要放在首行。 -- this、super不能用在static方法中。 +- 在构造器中使用 `super()` 调用父类中的其他构造方法时，该语句必须处于构造器的首行，否则编译器会报错。另外，this 调用本类中的其他构造方法时，也要放在首行。 +- this、super 不能用在 static 方法中。 **简单解释一下：** -被 static 修饰的成员属于类，不属于单个这个类的某个对象，被类中所有对象共享。而 this 代表对本类对象的引用，指向本类对象；而 super 代表对父类对象的引用，指向父类对象；所以， **this和super是属于对象范畴的东西，而静态方法是属于类范畴的东西**。 - - +被 static 修饰的成员属于类，不属于单个这个类的某个对象，被类中所有对象共享。而 this 代表对本类对象的引用，指向本类对象；而 super 代表对父类对象的引用，指向父类对象；所以， **this 和 super 是属于对象范畴的东西，而静态方法是属于类范畴的东西**。 ## 参考 @@ -113,22 +86,20 @@ public class Sub extends Super { 1. 修饰成员变量和成员方法 2. 静态代码块 3. 修饰类(只能修饰内部类) -4. 静态导包(用来导入类中的静态资源，1.5之后的新特性) +4. 静态导包(用来导入类中的静态资源，1.5 之后的新特性) ### 修饰成员变量和成员方法(常用) -被 static 修饰的成员属于类，不属于单个这个类的某个对象，被类中所有对象共享，可以并且建议通过类名调用。被static 声明的成员变量属于静态成员变量，静态变量 存放在 Java 内存区域的方法区。 - -方法区与 Java 堆一样，是各个线程共享的内存区域，它用于存储已被虚拟机加载的类信息、常量、静态变量、即时编译器编译后的代码等数据。虽然Java虚拟机规范把方法区描述为堆的一个逻辑部分，但是它却有一个别名叫做 Non-Heap（非堆），目的应该是与 Java 堆区分开来。 - - HotSpot 虚拟机中方法区也常被称为 “永久代”，本质上两者并不等价。仅仅是因为 HotSpot 虚拟机设计团队用永久代来实现方法区而已，这样 HotSpot 虚拟机的垃圾收集器就可以像管理 Java 堆一样管理这部分内存了。但是这并不是一个好主意，因为这样更容易遇到内存溢出问题。 +被 static 修饰的成员属于类，不属于单个这个类的某个对象，被类中所有对象共享，可以并且建议通过类名调用。被 static 声明的成员变量属于静态成员变量，静态变量 存放在 Java 内存区域的方法区。 +方法区与 Java 堆一样，是各个线程共享的内存区域，它用于存储已被虚拟机加载的类信息、常量、静态变量、即时编译器编译后的代码等数据。虽然 Java 虚拟机规范把方法区描述为堆的一个逻辑部分，但是它却有一个别名叫做 Non-Heap（非堆），目的应该是与 Java 堆区分开来。 +HotSpot 虚拟机中方法区也常被称为 “永久代”，本质上两者并不等价。仅仅是因为 HotSpot 虚拟机设计团队用永久代来实现方法区而已，这样 HotSpot 虚拟机的垃圾收集器就可以像管理 Java 堆一样管理这部分内存了。但是这并不是一个好主意，因为这样更容易遇到内存溢出问题。 调用格式： -- 类名.静态变量名 -- 类名.静态方法名() +- `类名.静态变量名` +- `类名.静态方法名()` 如果变量或者方法被 private 则代表该属性或者该方法只能在类的内部被访问而不能在类的外部被访问。 @@ -136,125 +107,105 @@ public class Sub extends Super { ```java public class StaticBean { - String name; - 静态变量 + //静态变量 static int age; - public StaticBean(String name) { this.name = name; } - 静态方法 - static void SayHello() { - System.out.println(Hello i am java); + //静态方法 + static void sayHello() { + System.out.println("Hello i am java"); } @Override public String toString() { - return StaticBean{ + - name=' + name + ''' + age + age + - '}'; + return "StaticBean{"+ + "name=" + name + ",age=" + age + + "}"; } } ``` ```java public class StaticDemo { - public static void main(String[] args) { - StaticBean staticBean = new StaticBean(1); - StaticBean staticBean2 = new StaticBean(2); - StaticBean staticBean3 = new StaticBean(3); - StaticBean staticBean4 = new StaticBean(4); + StaticBean staticBean = new StaticBean("1"); + StaticBean staticBean2 = new StaticBean("2"); + StaticBean staticBean3 = new StaticBean("3"); + StaticBean staticBean4 = new StaticBean("4"); StaticBean.age = 33; - StaticBean{name='1'age33} StaticBean{name='2'age33} StaticBean{name='3'age33} StaticBean{name='4'age33} - System.out.println(staticBean+ +staticBean2+ +staticBean3+ +staticBean4); - StaticBean.SayHello();Hello i am java + System.out.println(staticBean + " " + staticBean2 + " " + staticBean3 + " " + staticBean4); + //StaticBean{name=1,age=33} StaticBean{name=2,age=33} StaticBean{name=3,age=33} StaticBean{name=4,age=33} + StaticBean.sayHello();//Hello i am java } - } ``` - ### 静态代码块 -静态代码块定义在类中方法外, 静态代码块在非静态代码块之前执行(静态代码块—非静态代码块—构造方法)。 该类不管创建多少对象，静态代码块只执行一次. +静态代码块定义在类中方法外, 静态代码块在非静态代码块之前执行(静态代码块 —> 非静态代码块 —> 构造方法)。 该类不管创建多少对象，静态代码块只执行一次. -静态代码块的格式是 +静态代码块的格式是 ``` -static { -语句体; +static { +语句体; } ``` +一个类中的静态代码块可以有多个，位置可以随便放，它不在任何的方法体内，JVM 加载类时会执行这些静态的代码块，如果静态代码块有多个，JVM 将按照它们在类中出现的先后顺序依次执行它们，每个代码块只会被执行一次。 -一个类中的静态代码块可以有多个，位置可以随便放，它不在任何的方法体内，JVM加载类时会执行这些静态的代码块，如果静态代码块有多个，JVM将按照它们在类中出现的先后顺序依次执行它们，每个代码块只会被执行一次。 - -![](http://my-blog-to-use.oss-cn-beijing.aliyuncs.com/18-9-14/88531075.jpg) +![](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/18-9-14/88531075.jpg) 静态代码块对于定义在它之后的静态变量，可以赋值，但是不能访问. - ### 静态内部类 静态内部类与非静态内部类之间存在一个最大的区别，我们知道非静态内部类在编译完成之后会隐含地保存着一个引用，该引用是指向创建它的外围类，但是静态内部类却没有。没有这个引用就意味着： 1. 它的创建是不需要依赖外围类的创建。 -2. 它不能使用任何外围类的非static成员变量和方法。 - +2. 它不能使用任何外围类的非 static 成员变量和方法。 Example（静态内部类实现单例模式） ```java public class Singleton { - - 声明为 private 避免调用默认构造方法创建对象 + //声明为 private 避免调用默认构造方法创建对象 private Singleton() { } - - 声明为 private 表明静态内部该类只能在该 Singleton 类中被访问 + // 声明为 private 表明静态内部该类只能在该 Singleton 类中被访问 private static class SingletonHolder { private static final Singleton INSTANCE = new Singleton(); } - public static Singleton getUniqueInstance() { return SingletonHolder.INSTANCE; } } ``` -当 Singleton 类加载时，静态内部类 SingletonHolder 没有被加载进内存。只有当调用 `getUniqueInstance() `方法从而触发 `SingletonHolder.INSTANCE` 时 SingletonHolder 才会被加载，此时初始化 INSTANCE 实例，并且 JVM 能确保 INSTANCE 只被实例化一次。 +当 Singleton 类加载时，静态内部类 SingletonHolder 没有被加载进内存。只有当调用 `getUniqueInstance()`方法从而触发 `SingletonHolder.INSTANCE` 时 SingletonHolder 才会被加载，此时初始化 INSTANCE 实例，并且 JVM 能确保 INSTANCE 只被实例化一次。 这种方式不仅具有延迟初始化的好处，而且由 JVM 提供了对线程安全的支持。 ### 静态导包 -格式为：import static +格式为：import static 这两个关键字连用可以指定导入某个类中的指定静态资源，并且不需要使用类名调用类中静态成员，可以直接使用类中静态成员变量和成员方法 ```java - - - Math. --- 将Math中的所有静态资源导入，这时候可以直接使用里面的静态方法，而不用通过类名进行调用 - 如果只想导入单一某个静态方法，只需要将换成对应的方法名即可 - -import static java.lang.Math.; - - 换成import static java.lang.Math.max;具有一样的效果 - + //将Math中的所有静态资源导入，这时候可以直接使用里面的静态方法，而不用通过类名进行调用 + //如果只想导入单一某个静态方法，只需要将*换成对应的方法名即可 +import static java.lang.Math.*;//换成import static java.lang.Math.max;具有一样的效果 public class Demo { public static void main(String[] args) { - int max = max(1,2); System.out.println(max); } } - ``` - -## 补充内容 +## 补充内容 ### 静态方法与非静态方法 @@ -265,84 +216,89 @@ Example ```java class Foo { int i; - public Foo(int i) { + public Foo(int i) { this.i = i; } - public static String method1() { - return An example string that doesn't depend on i (an instance variable); - + return "An example string that doesn't depend on i (an instance variable)"; } - public int method2() { - return this.i + 1; Depends on i + return this.i + 1; //Depends on i } - } ``` -你可以像这样调用静态方法：`Foo.method1（）`。 如果您尝试使用这种方法调用 method2 将失败。 但这样可行：`Foo bar = new Foo（1）;bar.method2（）;` + +你可以像这样调用静态方法：`Foo.method1()`。 如果您尝试使用这种方法调用 method2 将失败。 但这样可行 + +```java +Foo bar = new Foo(1); +bar.method2(); +``` 总结： -- 在外部调用静态方法时，可以使用”类名.方法名”的方式，也可以使用”对象名.方法名”的方式。而实例方法只有后面这种方式。也就是说，调用静态方法可以无需创建对象。 -- 静态方法在访问本类的成员时，只允许访问静态成员（即静态成员变量和静态方法），而不允许访问实例成员变量和实例方法；实例方法则无此限制 +- 在外部调用静态方法时，可以使用”类名.方法名”的方式，也可以使用”对象名.方法名”的方式。而实例方法只有后面这种方式。也就是说，调用静态方法可以无需创建对象。 +- 静态方法在访问本类的成员时，只允许访问静态成员（即静态成员变量和静态方法），而不允许访问实例成员变量和实例方法；实例方法则无此限制 -### static{}静态代码块与{}非静态代码块(构造代码块) +### `static{}`静态代码块与`{}`非静态代码块(构造代码块) -相同点： 都是在JVM加载类时且在构造方法执行之前执行，在类中都可以定义多个，定义多个时按定义的顺序执行，一般在代码块中对一些static变量进行赋值。 +相同点： 都是在 JVM 加载类时且在构造方法执行之前执行，在类中都可以定义多个，定义多个时按定义的顺序执行，一般在代码块中对一些 static 变量进行赋值。 -不同点： 静态代码块在非静态代码块之前执行(静态代码块—非静态代码块—构造方法)。静态代码块只在第一次new执行一次，之后不再执行，而非静态代码块在每new一次就执行一次。 非静态代码块可在普通方法中定义(不过作用不大)；而静态代码块不行。 +不同点： 静态代码块在非静态代码块之前执行(静态代码块 -> 非静态代码块 -> 构造方法)。静态代码块只在第一次 new 执行一次，之后不再执行，而非静态代码块在每 new 一次就执行一次。 非静态代码块可在普通方法中定义(不过作用不大)；而静态代码块不行。 -一般情况下,如果有些代码比如一些项目最常用的变量或对象必须在项目启动的时候就执行的时候,需要使用静态代码块,这种代码是主动执行的。如果我们想要设计不需要创建对象就可以调用类中的方法，例如：Arrays类，Character类，String类等，就需要使用静态方法, 两者的区别是 静态代码块是自动执行的而静态方法是被调用的时候才执行的. +> **🐛 修正（参见： [issue #677](https://github.com/Snailclimb/JavaGuide/issues/677)）** ：静态代码块可能在第一次 new 对象的时候执行，但不一定只在第一次 new 的时候执行。比如通过 `Class.forName("ClassDemo")`创建 Class 对象的时候也会执行，即 new 或者 `Class.forName("ClassDemo")` 都会执行静态代码块。 +一般情况下,如果有些代码比如一些项目最常用的变量或对象必须在项目启动的时候就执行的时候,需要使用静态代码块,这种代码是主动执行的。如果我们想要设计不需要创建对象就可以调用类中的方法，例如：`Arrays` 类，`Character` 类，`String` 类等，就需要使用静态方法, 两者的区别是 静态代码块是自动执行的而静态方法是被调用的时候才执行的. -Example +Example： ```java public class Test { public Test() { - System.out.print(默认构造方法！--); + System.out.print("默认构造方法！--"); } - - 非静态代码块 + //非静态代码块 { - System.out.print(非静态代码块！--); + System.out.print("非静态代码块！--"); } - 静态代码块 + //静态代码块 static { - System.out.print(静态代码块！--); + System.out.print("静态代码块！--"); } - - public static void test() { - System.out.print(静态方法中的内容! --); + private static void test() { + System.out.print("静态方法中的内容! --"); { - System.out.print(静态方法中的代码块！--); + System.out.print("静态方法中的代码块！--"); } - } public static void main(String[] args) { - - Test test = new Test(); - Test.test();静态代码块！--静态方法中的内容! --静态方法中的代码块！-- + Test test = new Test(); + Test.test();//静态代码块！--静态方法中的内容! --静态方法中的代码块！-- } +} ``` -当执行 `Test.test();` 时输出： +上述代码输出： + +``` +静态代码块！--非静态代码块！--默认构造方法！--静态方法中的内容! --静态方法中的代码块！-- +``` + +当只执行 `Test.test();` 时输出： ``` 静态代码块！--静态方法中的内容! --静态方法中的代码块！-- ``` -当执行 `Test test = new Test();` 时输出： +当只执行 `Test test = new Test();` 时输出： ``` 静态代码块！--非静态代码块！--默认构造方法！-- ``` - -非静态代码块与构造函数的区别是： 非静态代码块是给所有对象进行统一初始化，而构造函数是给对应的对象初始化，因为构造函数是可以多个的，运行哪个构造函数就会建立什么样的对象，但无论建立哪个对象，都会先执行相同的构造代码块。也就是说，构造代码块中定义的是不同对象共性的初始化内容。 +非静态代码块与构造函数的区别是： 非静态代码块是给所有对象进行统一初始化，而构造函数是给对应的对象初始化，因为构造函数是可以多个的，运行哪个构造函数就会建立什么样的对象，但无论建立哪个对象，都会先执行相同的构造代码块。也就是说，构造代码块中定义的是不同对象共性的初始化内容。 ### 参考 -- httpsblog.csdn.netchen13579867831articledetails78995480 -- httpwww.cnblogs.comchenssyp3388487.html -- httpwww.cnblogs.comQian123p5713440.html +- https://blog.csdn.net/chen13579867831/article/details/78995480 +- https://www.cnblogs.com/chenssy/p/3388487.html +- https://www.cnblogs.com/Qian123/p/5713440.html \ No newline at end of file diff --git a/docs/java/basis/proxy.md b/docs/java/basis/proxy.md new file mode 100644 index 0000000000000000000000000000000000000000..0006caed0aaff5853e7944fa7e18776af3cbace7 --- /dev/null +++ b/docs/java/basis/proxy.md @@ -0,0 +1,404 @@ +--- +title: 代理详解！静态代理+JDK/CGLIB 动态代理实战 +category: Java +tag: + - Java基础 +--- + +## 1. 代理模式 + +代理模式是一种比较好理解的设计模式。简单来说就是 **我们使用代理对象来代替对真实对象(real object)的访问，这样就可以在不修改原目标对象的前提下，提供额外的功能操作，扩展目标对象的功能。** + +**代理模式的主要作用是扩展目标对象的功能，比如说在目标对象的某个方法执行前后你可以增加一些自定义的操作。** + +举个例子：你找了小红来帮你问话，小红就可以看作是代理你的代理对象，代理的行为（方法）是问话。 + +![Understanding the Proxy Design Pattern | by Mithun Sasidharan | Medium](https://guide-blog-images.oss-cn-shenzhen.aliyuncs.com/2020-8/1*DjWCgTFm-xqbhbNQVsaWQw.png) + +

https://medium.com/@mithunsasidharan/understanding-the-proxy-design-pattern-5e63fe38052a

+ +代理模式有静态代理和动态代理两种实现方式，我们 先来看一下静态代理模式的实现。 + +## 2. 静态代理 + +**静态代理中，我们对目标对象的每个方法的增强都是手动完成的（_后面会具体演示代码_），非常不灵活（_比如接口一旦新增加方法，目标对象和代理对象都要进行修改_）且麻烦(_需要对每个目标类都单独写一个代理类_)。** 实际应用场景非常非常少，日常开发几乎看不到使用静态代理的场景。 + +上面我们是从实现和应用角度来说的静态代理，从 JVM 层面来说， **静态代理在编译时就将接口、实现类、代理类这些都变成了一个个实际的 class 文件。** + +静态代理实现步骤: + +1. 定义一个接口及其实现类； +2. 创建一个代理类同样实现这个接口 +3. 将目标对象注入进代理类，然后在代理类的对应方法调用目标类中的对应方法。这样的话，我们就可以通过代理类屏蔽对目标对象的访问，并且可以在目标方法执行前后做一些自己想做的事情。 + +下面通过代码展示！ + +**1.定义发送短信的接口** + +```java +public interface SmsService { + String send(String message); +} +``` + +**2.实现发送短信的接口** + +```java +public class SmsServiceImpl implements SmsService { + public String send(String message) { + System.out.println("send message:" + message); + return message; + } +} +``` + +**3.创建代理类并同样实现发送短信的接口** + +```java +public class SmsProxy implements SmsService { + + private final SmsService smsService; + + public SmsProxy(SmsService smsService) { + this.smsService = smsService; + } + + @Override + public String send(String message) { + //调用方法之前，我们可以添加自己的操作 + System.out.println("before method send()"); + smsService.send(message); + //调用方法之后，我们同样可以添加自己的操作 + System.out.println("after method send()"); + return null; + } +} +``` + +**4.实际使用** + +```java +public class Main { + public static void main(String[] args) { + SmsService smsService = new SmsServiceImpl(); + SmsProxy smsProxy = new SmsProxy(smsService); + smsProxy.send("java"); + } +} +``` + +运行上述代码之后，控制台打印出： + +```bash +before method send() +send message:java +after method send() +``` + +可以输出结果看出，我们已经增加了 `SmsServiceImpl` 的`send()`方法。 + +## 3. 动态代理 + +相比于静态代理来说，动态代理更加灵活。我们不需要针对每个目标类都单独创建一个代理类，并且也不需要我们必须实现接口，我们可以直接代理实现类( _CGLIB 动态代理机制_)。 + +**从 JVM 角度来说，动态代理是在运行时动态生成类字节码，并加载到 JVM 中的。** + +说到动态代理，Spring AOP、RPC 框架应该是两个不得不提的，它们的实现都依赖了动态代理。 + +**动态代理在我们日常开发中使用的相对较少，但是在框架中的几乎是必用的一门技术。学会了动态代理之后，对于我们理解和学习各种框架的原理也非常有帮助。** + +就 Java 来说，动态代理的实现方式有很多种，比如 **JDK 动态代理**、**CGLIB 动态代理**等等。 + +[guide-rpc-framework](https://github.com/Snailclimb/guide-rpc-framework) 使用的是 JDK 动态代理，我们先来看看 JDK 动态代理的使用。 + +另外，虽然 [guide-rpc-framework](https://github.com/Snailclimb/guide-rpc-framework) 没有用到 **CGLIB 动态代理** ，我们这里还是简单介绍一下其使用以及和**JDK 动态代理**的对比。 + +### 3.1. JDK 动态代理机制 + +#### 3.1.1. 介绍 + +**在 Java 动态代理机制中 `InvocationHandler` 接口和 `Proxy` 类是核心。** + +`Proxy` 类中使用频率最高的方法是：`newProxyInstance()` ，这个方法主要用来生成一个代理对象。 + +```java + public static Object newProxyInstance(ClassLoader loader, + Class[] interfaces, + InvocationHandler h) + throws IllegalArgumentException + { + ...... + } +``` + +这个方法一共有 3 个参数： + +1. **loader** :类加载器，用于加载代理对象。 +2. **interfaces** : 被代理类实现的一些接口； +3. **h** : 实现了 `InvocationHandler` 接口的对象； + +要实现动态代理的话，还必须需要实现`InvocationHandler` 来自定义处理逻辑。 当我们的动态代理对象调用一个方法时，这个方法的调用就会被转发到实现`InvocationHandler` 接口类的 `invoke` 方法来调用。 + +```java +public interface InvocationHandler { + + /** + * 当你使用代理对象调用方法的时候实际会调用到这个方法 + */ + public Object invoke(Object proxy, Method method, Object[] args) + throws Throwable; +} +``` + +`invoke()` 方法有下面三个参数： + +1. **proxy** :动态生成的代理类 +2. **method** : 与代理类对象调用的方法相对应 +3. **args** : 当前 method 方法的参数 + +也就是说：**你通过`Proxy` 类的 `newProxyInstance()` 创建的代理对象在调用方法的时候，实际会调用到实现`InvocationHandler` 接口的类的 `invoke()`方法。** 你可以在 `invoke()` 方法中自定义处理逻辑，比如在方法执行前后做什么事情。 + +#### 3.1.2. JDK 动态代理类使用步骤 + +1. 定义一个接口及其实现类； +2. 自定义 `InvocationHandler` 并重写`invoke`方法，在 `invoke` 方法中我们会调用原生方法（被代理类的方法）并自定义一些处理逻辑； +3. 通过 `Proxy.newProxyInstance(ClassLoader loader,Class[] interfaces,InvocationHandler h)` 方法创建代理对象； + +#### 3.1.3. 代码示例 + +这样说可能会有点空洞和难以理解，我上个例子，大家感受一下吧！ + +**1.定义发送短信的接口** + +```java +public interface SmsService { + String send(String message); +} +``` + +**2.实现发送短信的接口** + +```java +public class SmsServiceImpl implements SmsService { + public String send(String message) { + System.out.println("send message:" + message); + return message; + } +} +``` + +**3.定义一个 JDK 动态代理类** + +```java +import java.lang.reflect.InvocationHandler; +import java.lang.reflect.InvocationTargetException; +import java.lang.reflect.Method; + +/** + * @author shuang.kou + * @createTime 2020年05月11日 11:23:00 + */ +public class DebugInvocationHandler implements InvocationHandler { + /** + * 代理类中的真实对象 + */ + private final Object target; + + public DebugInvocationHandler(Object target) { + this.target = target; + } + + + public Object invoke(Object proxy, Method method, Object[] args) throws InvocationTargetException, IllegalAccessException { + //调用方法之前，我们可以添加自己的操作 + System.out.println("before method " + method.getName()); + Object result = method.invoke(target, args); + //调用方法之后，我们同样可以添加自己的操作 + System.out.println("after method " + method.getName()); + return result; + } +} + +``` + +`invoke()` 方法: 当我们的动态代理对象调用原生方法的时候，最终实际上调用到的是 `invoke()` 方法，然后 `invoke()` 方法代替我们去调用了被代理对象的原生方法。 + +**4.获取代理对象的工厂类** + +```java +public class JdkProxyFactory { + public static Object getProxy(Object target) { + return Proxy.newProxyInstance( + target.getClass().getClassLoader(), // 目标类的类加载 + target.getClass().getInterfaces(), // 代理需要实现的接口，可指定多个 + new DebugInvocationHandler(target) // 代理对象对应的自定义 InvocationHandler + ); + } +} +``` + +`getProxy()` ：主要通过`Proxy.newProxyInstance（）`方法获取某个类的代理对象 + +**5.实际使用** + +```java +SmsService smsService = (SmsService) JdkProxyFactory.getProxy(new SmsServiceImpl()); +smsService.send("java"); +``` + +运行上述代码之后，控制台打印出： + +``` +before method send +send message:java +after method send +``` + +### 3.2. CGLIB 动态代理机制 + +#### 3.2.1. 介绍 + +**JDK 动态代理有一个最致命的问题是其只能代理实现了接口的类。** + +**为了解决这个问题，我们可以用 CGLIB 动态代理机制来避免。** + +[CGLIB](https://github.com/cglib/cglib)(_Code Generation Library_)是一个基于[ASM](http://www.baeldung.com/java-asm)的字节码生成库，它允许我们在运行时对字节码进行修改和动态生成。CGLIB 通过继承方式实现代理。很多知名的开源框架都使用到了[CGLIB](https://github.com/cglib/cglib)， 例如 Spring 中的 AOP 模块中：如果目标对象实现了接口，则默认采用 JDK 动态代理，否则采用 CGLIB 动态代理。 + +**在 CGLIB 动态代理机制中 `MethodInterceptor` 接口和 `Enhancer` 类是核心。** + +你需要自定义 `MethodInterceptor` 并重写 `intercept` 方法，`intercept` 用于拦截增强被代理类的方法。 + +```java +public interface MethodInterceptor +extends Callback{ + // 拦截被代理类中的方法 + public Object intercept(Object obj, java.lang.reflect.Method method, Object[] args, + MethodProxy proxy) throws Throwable; +} + +``` + +1. **obj** :被代理的对象（需要增强的对象） +2. **method** :被拦截的方法（需要增强的方法） +3. **args** :方法入参 +4. **proxy** :用于调用原始方法 + +你可以通过 `Enhancer`类来动态获取被代理类，当代理类调用方法的时候，实际调用的是 `MethodInterceptor` 中的 `intercept` 方法。 + +#### 3.2.2. CGLIB 动态代理类使用步骤 + +1. 定义一个类； +2. 自定义 `MethodInterceptor` 并重写 `intercept` 方法，`intercept` 用于拦截增强被代理类的方法，和 JDK 动态代理中的 `invoke` 方法类似； +3. 通过 `Enhancer` 类的 `create()`创建代理类； + +#### 3.2.3. 代码示例 + +不同于 JDK 动态代理不需要额外的依赖。[CGLIB](https://github.com/cglib/cglib)(_Code Generation Library_) 实际是属于一个开源项目，如果你要使用它的话，需要手动添加相关依赖。 + +```xml + + cglib + cglib + 3.3.0 + +``` + +**1.实现一个使用阿里云发送短信的类** + +```java +package github.javaguide.dynamicProxy.cglibDynamicProxy; + +public class AliSmsService { + public String send(String message) { + System.out.println("send message:" + message); + return message; + } +} +``` + +**2.自定义 `MethodInterceptor`（方法拦截器）** + +```java +import net.sf.cglib.proxy.MethodInterceptor; +import net.sf.cglib.proxy.MethodProxy; + +import java.lang.reflect.Method; + +/** + * 自定义MethodInterceptor + */ +public class DebugMethodInterceptor implements MethodInterceptor { + + + /** + * @param o 代理对象（增强的对象） + * @param method 被拦截的方法（需要增强的方法） + * @param args 方法入参 + * @param methodProxy 用于调用原始方法 + */ + @Override + public Object intercept(Object o, Method method, Object[] args, MethodProxy methodProxy) throws Throwable { + //调用方法之前，我们可以添加自己的操作 + System.out.println("before method " + method.getName()); + Object object = methodProxy.invokeSuper(o, args); + //调用方法之后，我们同样可以添加自己的操作 + System.out.println("after method " + method.getName()); + return object; + } + +} +``` + +**3.获取代理类** + +```java +import net.sf.cglib.proxy.Enhancer; + +public class CglibProxyFactory { + + public static Object getProxy(Class clazz) { + // 创建动态代理增强类 + Enhancer enhancer = new Enhancer(); + // 设置类加载器 + enhancer.setClassLoader(clazz.getClassLoader()); + // 设置被代理类 + enhancer.setSuperclass(clazz); + // 设置方法拦截器 + enhancer.setCallback(new DebugMethodInterceptor()); + // 创建代理类 + return enhancer.create(); + } +} +``` + +**4.实际使用** + +```java +AliSmsService aliSmsService = (AliSmsService) CglibProxyFactory.getProxy(AliSmsService.class); +aliSmsService.send("java"); +``` + +运行上述代码之后，控制台打印出： + +```bash +before method send +send message:java +after method send +``` + +### 3.3. JDK 动态代理和 CGLIB 动态代理对比 + +1. **JDK 动态代理只能代理实现了接口的类或者直接代理接口，而 CGLIB 可以代理未实现任何接口的类。** 另外， CGLIB 动态代理是通过生成一个被代理类的子类来拦截被代理类的方法调用，因此不能代理声明为 final 类型的类和方法。 +2. 就二者的效率来说，大部分情况都是 JDK 动态代理更优秀，随着 JDK 版本的升级，这个优势更加明显。 + +## 4. 静态代理和动态代理的对比 + +1. **灵活性** ：动态代理更加灵活，不需要必须实现接口，可以直接代理实现类，并且可以不需要针对每个目标类都创建一个代理类。另外，静态代理中，接口一旦新增加方法，目标对象和代理对象都要进行修改，这是非常麻烦的！ +2. **JVM 层面** ：静态代理在编译时就将接口、实现类、代理类这些都变成了一个个实际的 class 文件。而动态代理是在运行时动态生成类字节码，并加载到 JVM 中的。 + +## 5. 总结 + +这篇文章中主要介绍了代理模式的两种实现：静态代理以及动态代理。涵盖了静态代理和动态代理实战、静态代理和动态代理的区别、JDK 动态代理和 Cglib 动态代理区别等内容。 + +文中涉及到的所有源码，你可以在这里找到：[https://github.com/Snailclimb/guide-rpc-framework-learning/tree/master/src/main/java/github/javaguide/proxy](https://github.com/Snailclimb/guide-rpc-framework-learning/tree/master/src/main/java/github/javaguide/proxy) 。 + diff --git a/docs/java/basis/reflection.md b/docs/java/basis/reflection.md new file mode 100644 index 0000000000000000000000000000000000000000..98ae943f25400819a55810df06fa27c30447bf58 --- /dev/null +++ b/docs/java/basis/reflection.md @@ -0,0 +1,185 @@ +--- +title: 反射机制详解！ +category: Java +tag: + - Java基础 +--- + +## 何为反射？ + +如果说大家研究过框架的底层原理或者咱们自己写过框架的话，一定对反射这个概念不陌生。 + +反射之所以被称为框架的灵魂，主要是因为它赋予了我们在运行时分析类以及执行类中方法的能力。 + +通过反射你可以获取任意一个类的所有属性和方法，你还可以调用这些方法和属性。 + +## 反射的应用场景了解么？ + +像咱们平时大部分时候都是在写业务代码，很少会接触到直接使用反射机制的场景。 + +但是，这并不代表反射没有用。相反，正是因为反射，你才能这么轻松地使用各种框架。像 Spring/Spring Boot、MyBatis 等等框架中都大量使用了反射机制。 + +**这些框架中也大量使用了动态代理，而动态代理的实现也依赖反射。** + +比如下面是通过 JDK 实现动态代理的示例代码，其中就使用了反射类 `Method` 来调用指定的方法。 + +```java +public class DebugInvocationHandler implements InvocationHandler { + /** + * 代理类中的真实对象 + */ + private final Object target; + + public DebugInvocationHandler(Object target) { + this.target = target; + } + + + public Object invoke(Object proxy, Method method, Object[] args) throws InvocationTargetException, IllegalAccessException { + System.out.println("before method " + method.getName()); + Object result = method.invoke(target, args); + System.out.println("after method " + method.getName()); + return result; + } +} + +``` + +另外，像 Java 中的一大利器 **注解** 的实现也用到了反射。 + +为什么你使用 Spring 的时候 ，一个`@Component`注解就声明了一个类为 Spring Bean 呢？为什么你通过一个 `@Value`注解就读取到配置文件中的值呢？究竟是怎么起作用的呢？ + +这些都是因为你可以基于反射分析类，然后获取到类/属性/方法/方法的参数上的注解。你获取到注解之后，就可以做进一步的处理。 + +## 谈谈反射机制的优缺点 + +**优点** ： 可以让咱们的代码更加灵活、为各种框架提供开箱即用的功能提供了便利 + +**缺点** ：让我们在运行时有了分析操作类的能力，这同样也增加了安全问题。比如可以无视泛型参数的安全检查（泛型参数的安全检查发生在编译时）。另外，反射的性能也要稍差点，不过，对于框架来说实际是影响不大的。相关阅读：[Java Reflection: Why is it so slow?](https://stackoverflow.com/questions/1392351/java-reflection-why-is-it-so-slow) + +## 反射实战 + +### 获取 Class 对象的四种方式 + +如果我们动态获取到这些信息，我们需要依靠 Class 对象。Class 类对象将一个类的方法、变量等信息告诉运行的程序。Java 提供了四种方式获取 Class 对象: + +**1. 知道具体类的情况下可以使用：** + +```java +Class alunbarClass = TargetObject.class; +``` + +但是我们一般是不知道具体类的，基本都是通过遍历包下面的类来获取 Class 对象，通过此方式获取 Class 对象不会进行初始化 + +**2. 通过 `Class.forName()`传入类的全路径获取：** + +```java +Class alunbarClass1 = Class.forName("cn.javaguide.TargetObject"); +``` + +**3. 通过对象实例`instance.getClass()`获取：** + +```java +TargetObject o = new TargetObject(); +Class alunbarClass2 = o.getClass(); +``` + +**4. 通过类加载器`xxxClassLoader.loadClass()`传入类路径获取:** + +```java +Class clazz = ClassLoader.loadClass("cn.javaguide.TargetObject"); +``` + +通过类加载器获取 Class 对象不会进行初始化，意味着不进行包括初始化等一系列步骤，静态代码块和静态对象不会得到执行 + +### 反射的一些基本操作 + +1. 创建一个我们要使用反射操作的类 `TargetObject`。 + +```java +package cn.javaguide; + +public class TargetObject { + private String value; + + public TargetObject() { + value = "JavaGuide"; + } + + public void publicMethod(String s) { + System.out.println("I love " + s); + } + + private void privateMethod() { + System.out.println("value is " + value); + } +} +``` + +2. 使用反射操作这个类的方法以及参数 + +```java +package cn.javaguide; + +import java.lang.reflect.Field; +import java.lang.reflect.InvocationTargetException; +import java.lang.reflect.Method; + +public class Main { + public static void main(String[] args) throws ClassNotFoundException, NoSuchMethodException, IllegalAccessException, InstantiationException, InvocationTargetException, NoSuchFieldException { + /** + * 获取 TargetObject 类的 Class 对象并且创建 TargetObject 类实例 + */ + Class tagetClass = Class.forName("cn.javaguide.TargetObject"); + TargetObject targetObject = (TargetObject) tagetClass.newInstance(); + /** + * 获取 TargetObject 类中定义的所有方法 + */ + Method[] methods = targetClass.getDeclaredMethods(); + for (Method method : methods) { + System.out.println(method.getName()); + } + + /** + * 获取指定方法并调用 + */ + Method publicMethod = targetClass.getDeclaredMethod("publicMethod", + String.class); + + publicMethod.invoke(targetObject, "JavaGuide"); + + /** + * 获取指定参数并对参数进行修改 + */ + Field field = targetClass.getDeclaredField("value"); + //为了对类中的参数进行修改我们取消安全检查 + field.setAccessible(true); + field.set(targetObject, "JavaGuide"); + + /** + * 调用 private 方法 + */ + Method privateMethod = targetClass.getDeclaredMethod("privateMethod"); + //为了调用private方法我们取消安全检查 + privateMethod.setAccessible(true); + privateMethod.invoke(targetObject); + } +} + +``` + +输出内容： + +``` +publicMethod +privateMethod +I love JavaGuide +value is JavaGuide +``` + +**注意** : 有读者提到上面代码运行会抛出 `ClassNotFoundException` 异常,具体原因是你没有下面把这段代码的包名替换成自己创建的 `TargetObject` 所在的包 。 + +```java +Class targetClass = Class.forName("cn.javaguide.TargetObject"); +``` + diff --git a/docs/java/basis/why-there-only-value-passing-in-java.md b/docs/java/basis/why-there-only-value-passing-in-java.md new file mode 100644 index 0000000000000000000000000000000000000000..9167002e5110f50fb2b0bfec6025a782ef3efd83 --- /dev/null +++ b/docs/java/basis/why-there-only-value-passing-in-java.md @@ -0,0 +1,174 @@ +--- +category: Java +tag: + - Java基础 +--- + + + +# 为什么 Java 中只有值传递？ + +开始之前，我们先来搞懂下面这两个概念： + +- 形参&实参 +- 值传递&引用传递 + +## 形参&实参 + +方法的定义可能会用到 **参数**（有参的方法），参数在程序语言中分为： + +- **实参（实际参数）** ：用于传递给函数/方法的参数，必须有确定的值。 +- **形参（形式参数）** ：用于定义函数/方法，接收实参，不需要有确定的值。 + +```java +String hello = "Hello!"; +// hello 为实参 +sayHello(hello); +// str 为形参 +void sayHello(String str) { + System.out.println(str); +} +``` + +## 值传递&引用传递 + +程序设计语言将实参传递给方法（或函数）的方式分为两种： + +- **值传递** ：方法接收的是实参值的拷贝，会创建副本。 +- **引用传递** ：方法接收的直接是实参所引用的对象在堆中的地址，不会创建副本，对形参的修改将影响到实参。 + +很多程序设计语言（比如 C++、 Pascal )提供了两种参数传递的方式，不过，在 Java 中只有值传递。 + +## 为什么 Java 只有值传递？ + +**为什么说 Java 只有值传递呢？** 不需要太多废话，我通过 3 个例子来给大家证明。 + +### 案例1：传递基本类型参数 + +代码： + +```java +public static void main(String[] args) { + int num1 = 10; + int num2 = 20; + swap(num1, num2); + System.out.println("num1 = " + num1); + System.out.println("num2 = " + num2); +} + +public static void swap(int a, int b) { + int temp = a; + a = b; + b = temp; + System.out.println("a = " + a); + System.out.println("b = " + b); +} +``` + +输出： + +``` +a = 20 +b = 10 +num1 = 10 +num2 = 20 +``` + +解析： + +在 `swap()` 方法中，`a`、`b` 的值进行交换，并不会影响到 `num1`、`num2`。因为，`a`、`b` 的值，只是从 `num1`、`num2` 的复制过来的。也就是说，a、b 相当于 `num1`、`num2` 的副本，副本的内容无论怎么修改，都不会影响到原件本身。 + +![基本数据类型参数](./images/java-value-passing-01.png) + +通过上面例子，我们已经知道了一个方法不能修改一个基本数据类型的参数，而对象引用作为参数就不一样，请看案例2。 + +### 案例2：传递引用类型参数1 + +代码： + +```java + public static void main(String[] args) { + int[] arr = { 1, 2, 3, 4, 5 }; + System.out.println(arr[0]); + change(arr); + System.out.println(arr[0]); + } + + public static void change(int[] array) { + // 将数组的第一个元素变为0 + array[0] = 0; + } +``` + +输出： + +``` +1 +0 +``` + +解析： + +![引用数据类型参数1](./images/java-value-passing-02.png) + +看了这个案例很多人肯定觉得 Java 对引用类型的参数采用的是引用传递。 + +实际上，并不是的，这里传递的还是值，不过，这个值是实参的地址罢了！ + +也就是说 `change` 方法的参数拷贝的是 `arr` （实参）的地址，因此，它和 `arr` 指向的是同一个数组对象。这也就说明了为什么方法内部对形参的修改会影响到实参。 + +为了更强有力地反驳 Java 对引用类型的参数采用的不是引用传递，我们再来看下面这个案例！ + +### 案例3 ：传递引用类型参数2 + +```java +public class Person { + private String name; + // 省略构造函数、Getter&Setter方法 +} + +public static void main(String[] args) { + Person xiaoZhang = new Person("小张"); + Person xiaoLi = new Person("小李"); + swap(xiaoZhang, xiaoLi); + System.out.println("xiaoZhang:" + xiaoZhang.getName()); + System.out.println("xiaoLi:" + xiaoLi.getName()); +} + +public static void swap(Person person1, Person person2) { + Person temp = person1; + person1 = person2; + person2 = temp; + System.out.println("person1:" + person1.getName()); + System.out.println("person2:" + person2.getName()); +} +``` + +输出: + +``` +person1:小李 +person2:小张 +xiaoZhang:小张 +xiaoLi:小李 +``` + +解析： + +怎么回事？？？两个引用类型的形参互换并没有影响实参啊！ + +`swap` 方法的参数 `person1` 和 `person2` 只是拷贝的实参 `xiaoZhang` 和 `xiaoLi` 的地址。因此， `person1` 和 `person2` 的互换只是拷贝的两个地址的互换罢了，并不会影响到实参 `xiaoZhang` 和 `xiaoLi` 。 + +![引用数据类型参数2](./images/java-value-passing-03.png) + +## 总结 + +Java 中将实参传递给方法（或函数）的方式是 **值传递** ： + +- 如果参数是基本类型的话，很简单，传递的就是基本类型的字面量值的拷贝，会创建副本。 +- 如果参数是引用类型，传递的就是实参所引用的对象在堆中地址值的拷贝，同样也会创建副本。 + +## 参考 + +- 《Java 核心技术卷 Ⅰ》基础知识第十版第四章 4.5 小节 +- [Java 到底是值传递还是引用传递？ - Hollis的回答 - 知乎](https://www.zhihu.com/question/31203609/answer/576030121) \ No newline at end of file diff --git "a/Java\347\233\270\345\205\263/ArrayList.md" b/docs/java/collection/arraylist-source-code.md similarity index 53% rename from "Java\347\233\270\345\205\263/ArrayList.md" rename to docs/java/collection/arraylist-source-code.md index c3e8dd47896f8ec31b3606fa67c7a52a0818895e..9f08ec51a56235345ec75ff8442213b1072e2124 100644 --- "a/Java\347\233\270\345\205\263/ArrayList.md" +++ b/docs/java/collection/arraylist-source-code.md @@ -1,34 +1,43 @@ - +--- +title: ArrayList源码&扩容机制分析 +category: Java +tag: + - Java集合 +--- -- [ArrayList简介](#arraylist简介) -- [ArrayList核心源码](#arraylist核心源码) -- [ArrayList源码分析](#arraylist源码分析) - - [System.arraycopy\(\)和Arrays.copyOf\(\)方法](#systemarraycopy和arrayscopyof方法) - - [两者联系与区别](#两者联系与区别) - - [ArrayList核心扩容技术](#arraylist核心扩容技术) - - [内部类](#内部类) -- [ArrayList经典Demo](#arraylist经典demo) - +## 1. ArrayList 简介 +`ArrayList` 的底层是数组队列，相当于动态数组。与 Java 中的数组相比，它的容量能动态增长。在添加大量元素前，应用程序可以使用`ensureCapacity`操作来增加 `ArrayList` 实例的容量。这可以减少递增式再分配的数量。 -### ArrayList简介 -　　ArrayList 的底层是数组队列，相当于动态数组。与 Java 中的数组相比，它的容量能动态增长。在添加大量元素前，应用程序可以使用`ensureCapacity`操作来增加 ArrayList 实例的容量。这可以减少递增式再分配的数量。 - - 它继承于 **AbstractList**，实现了 **List**, **RandomAccess**, **Cloneable**, **java.io.Serializable** 这些接口。 - - 在我们学数据结构的时候就知道了线性表的顺序存储，插入删除元素的时间复杂度为**O（n）**,求表长以及增加元素，取第 i 元素的时间复杂度为**O（1）** +`ArrayList`继承于 **`AbstractList`** ，实现了 **`List`**, **`RandomAccess`**, **`Cloneable`**, **`java.io.Serializable`** 这些接口。 -　 ArrayList 继承了AbstractList，实现了List。它是一个数组队列，提供了相关的添加、删除、修改、遍历等功能。 +```java + +public class ArrayList extends AbstractList + implements List, RandomAccess, Cloneable, java.io.Serializable{ + + } +``` + +- `RandomAccess` 是一个标志接口，表明实现这个这个接口的 List 集合是支持**快速随机访问**的。在 `ArrayList` 中，我们即可以通过元素的序号快速获取元素对象，这就是快速随机访问。 +- `ArrayList` 实现了 **`Cloneable` 接口** ，即覆盖了函数`clone()`，能被克隆。 +- `ArrayList` 实现了 `java.io.Serializable`接口，这意味着`ArrayList`支持序列化，能通过序列化去传输。 -　　ArrayList 实现了**RandomAccess 接口**， RandomAccess 是一个标志接口，表明实现这个这个接口的 List 集合是支持**快速随机访问**的。在 ArrayList 中，我们即可以通过元素的序号快速获取元素对象，这就是快速随机访问。 +### 1.1. Arraylist 和 Vector 的区别? -　　ArrayList 实现了**Cloneable 接口**，即覆盖了函数 clone()，**能被克隆**。 +1. `ArrayList` 是 `List` 的主要实现类，底层使用 `Object[ ]`存储，适用于频繁的查找工作，线程不安全 ； +2. `Vector` 是 `List` 的古老实现类，底层使用 `Object[ ]`存储，线程安全的。 -　　ArrayList 实现**java.io.Serializable 接口**，这意味着ArrayList**支持序列化**，**能通过序列化去传输**。 +### 1.2. Arraylist 与 LinkedList 区别? -　　和 Vector 不同，**ArrayList 中的操作不是线程安全的**！所以，建议在单线程中才使用 ArrayList，而在多线程中可以选择 Vector 或者 CopyOnWriteArrayList。 -### ArrayList核心源码 +1. **是否保证线程安全：** `ArrayList` 和 `LinkedList` 都是不同步的，也就是不保证线程安全； +2. **底层数据结构：** `Arraylist` 底层使用的是 **`Object` 数组**；`LinkedList` 底层使用的是 **双向链表** 数据结构（JDK1.6 之前为循环链表，JDK1.7 取消了循环。注意双向链表和双向循环链表的区别，下面有介绍到！） +3. **插入和删除是否受元素位置的影响：** ① **`ArrayList` 采用数组存储，所以插入和删除元素的时间复杂度受元素位置的影响。** 比如：执行`add(E e)`方法的时候， `ArrayList` 会默认在将指定的元素追加到此列表的末尾，这种情况时间复杂度就是 O(1)。但是如果要在指定位置 i 插入和删除元素的话（`add(int index, E element)`）时间复杂度就为 O(n-i)。因为在进行上述操作的时候集合中第 i 和第 i 个元素之后的(n-i)个元素都要执行向后位/向前移一位的操作。 ② **`LinkedList` 采用链表存储，所以对于`add(E e)`方法的插入，删除元素时间复杂度不受元素位置的影响，近似 O(1)，如果是要在指定位置`i`插入和删除元素的话（`(add(int index, E element)`） 时间复杂度近似为`o(n))`因为需要先移动到指定位置再插入。** +4. **是否支持快速随机访问：** `LinkedList` 不支持高效的随机元素访问，而 `ArrayList` 支持。快速随机访问就是通过元素的序号快速获取元素对象(对应于`get(int index)`方法)。 +5. **内存空间占用：** `ArrayList` 的空 间浪费主要体现在在 list 列表的结尾会预留一定的容量空间，而 `LinkedList` 的空间花费则体现在它的每一个元素都需要消耗比 `ArrayList` 更多的空间（因为要存放直接后继和直接前驱以及数据）。 + +## 2. ArrayList 核心源码解读 ```java package java.util; @@ -68,23 +77,25 @@ public class ArrayList extends AbstractList private int size; /** - * 带初始容量参数的构造函数。（用户自己指定容量） + * 带初始容量参数的构造函数（用户可以在创建ArrayList对象时自己指定集合的初始大小） */ public ArrayList(int initialCapacity) { if (initialCapacity > 0) { - //创建initialCapacity大小的数组 + //如果传入的参数大于0，创建initialCapacity大小的数组 this.elementData = new Object[initialCapacity]; } else if (initialCapacity == 0) { - //创建空数组 + //如果传入的参数等于0，创建空数组 this.elementData = EMPTY_ELEMENTDATA; } else { + //其他情况，抛出异常 throw new IllegalArgumentException("Illegal Capacity: "+ initialCapacity); } } /** - *默认构造函数，DEFAULTCAPACITY_EMPTY_ELEMENTDATA 为0.初始化为10，也就是说初始其实是空数组 当添加第一个元素的时候数组容量才变成10 + *默认无参构造函数 + *DEFAULTCAPACITY_EMPTY_ELEMENTDATA 为0.初始化为10，也就是说初始其实是空数组 当添加第一个元素的时候数组容量才变成10 */ public ArrayList() { this.elementData = DEFAULTCAPACITY_EMPTY_ELEMENTDATA; @@ -94,22 +105,22 @@ public class ArrayList extends AbstractList * 构造一个包含指定集合的元素的列表，按照它们由集合的迭代器返回的顺序。 */ public ArrayList(Collection c) { - // + //将指定集合转换为数组 elementData = c.toArray(); - //如果指定集合元素个数不为0 + //如果elementData数组的长度不为0 if ((size = elementData.length) != 0) { - // c.toArray 可能返回的不是Object类型的数组所以加上下面的语句用于判断， - //这里用到了反射里面的getClass()方法 + // 如果elementData不是Object类型数据（c.toArray可能返回的不是Object类型的数组所以加上下面的语句用于判断） if (elementData.getClass() != Object[].class) + //将原来不是Object类型的elementData数组的内容，赋值给新的Object类型的elementData数组 elementData = Arrays.copyOf(elementData, size, Object[].class); } else { - // 用空数组代替 + // 其他情况，用空数组代替 this.elementData = EMPTY_ELEMENTDATA; } } /** - * 修改这个ArrayList实例的容量是列表的当前大小。 应用程序可以使用此操作来最小化ArrayList实例的存储。 + * 修改这个ArrayList实例的容量是列表的当前大小。 应用程序可以使用此操作来最小化ArrayList实例的存储。 */ public void trimToSize() { modCount++; @@ -127,21 +138,23 @@ public class ArrayList extends AbstractList * @param minCapacity 所需的最小容量 */ public void ensureCapacity(int minCapacity) { + //如果是true，minExpand的值为0，如果是false,minExpand的值为10 int minExpand = (elementData != DEFAULTCAPACITY_EMPTY_ELEMENTDATA) // any size if not default element table ? 0 // larger than default for default empty table. It's already // supposed to be at default size. : DEFAULT_CAPACITY; - + //如果最小容量大于已有的最大容量 if (minCapacity > minExpand) { ensureExplicitCapacity(minCapacity); } } - //得到最小扩容量 + //1.得到最小扩容量 + //2.通过最小容量扩容 private void ensureCapacityInternal(int minCapacity) { if (elementData == DEFAULTCAPACITY_EMPTY_ELEMENTDATA) { - // 获取默认的容量和传入参数的较大值 + // 获取“默认的容量”和“传入参数”两者之间的最大值 minCapacity = Math.max(DEFAULT_CAPACITY, minCapacity); } @@ -192,7 +205,7 @@ public class ArrayList extends AbstractList } /** - *返回此列表中的元素数。 + *返回此列表中的元素数。 */ public int size() { return size; @@ -210,12 +223,12 @@ public class ArrayList extends AbstractList * 如果此列表包含指定的元素，则返回true 。 */ public boolean contains(Object o) { - //indexOf()方法：返回此列表中指定元素的首次出现的索引，如果此列表不包含此元素，则为-1 + //indexOf()方法：返回此列表中指定元素的首次出现的索引，如果此列表不包含此元素，则为-1 return indexOf(o) >= 0; } /** - *返回此列表中指定元素的首次出现的索引，如果此列表不包含此元素，则为-1 + *返回此列表中指定元素的首次出现的索引，如果此列表不包含此元素，则为-1 */ public int indexOf(Object o) { if (o == null) { @@ -248,7 +261,7 @@ public class ArrayList extends AbstractList } /** - * 返回此ArrayList实例的浅拷贝。 （元素本身不被复制。） + * 返回此ArrayList实例的浅拷贝。 （元素本身不被复制。） */ public Object clone() { try { @@ -264,7 +277,7 @@ public class ArrayList extends AbstractList } /** - *以正确的顺序（从第一个到最后一个元素）返回一个包含此列表中所有元素的数组。 + *以正确的顺序（从第一个到最后一个元素）返回一个包含此列表中所有元素的数组。 *返回的数组将是“安全的”，因为该列表不保留对它的引用。 （换句话说，这个方法必须分配一个新的数组）。 *因此，调用者可以自由地修改返回的数组。 此方法充当基于阵列和基于集合的API之间的桥梁。 */ @@ -273,11 +286,11 @@ public class ArrayList extends AbstractList } /** - * 以正确的顺序返回一个包含此列表中所有元素的数组（从第一个到最后一个元素）; - *返回的数组的运行时类型是指定数组的运行时类型。 如果列表适合指定的数组，则返回其中。 - *否则，将为指定数组的运行时类型和此列表的大小分配一个新数组。 + * 以正确的顺序返回一个包含此列表中所有元素的数组（从第一个到最后一个元素）; + *返回的数组的运行时类型是指定数组的运行时类型。 如果列表适合指定的数组，则返回其中。 + *否则，将为指定数组的运行时类型和此列表的大小分配一个新数组。 *如果列表适用于指定的数组，其余空间（即数组的列表数量多于此元素），则紧跟在集合结束后的数组中的元素设置为null 。 - *（这仅在调用者知道列表不包含任何空元素的情况下才能确定列表的长度。） + *（这仅在调用者知道列表不包含任何空元素的情况下才能确定列表的长度。） */ @SuppressWarnings("unchecked") public T[] toArray(T[] a) { @@ -308,7 +321,7 @@ public class ArrayList extends AbstractList } /** - * 用指定的元素替换此列表中指定位置的元素。 + * 用指定的元素替换此列表中指定位置的元素。 */ public E set(int index, E element) { //对index进行界限检查 @@ -321,7 +334,7 @@ public class ArrayList extends AbstractList } /** - * 将指定的元素追加到此列表的末尾。 + * 将指定的元素追加到此列表的末尾。 */ public boolean add(E e) { ensureCapacityInternal(size + 1); // Increments modCount!! @@ -331,7 +344,7 @@ public class ArrayList extends AbstractList } /** - * 在此列表中的指定位置插入指定的元素。 + * 在此列表中的指定位置插入指定的元素。 *先调用 rangeCheckForAdd 对index进行界限检查；然后调用 ensureCapacityInternal 方法保证capacity足够大； *再将从index开始之后的所有成员后移一个位置；将element插入index位置；最后size加1。 */ @@ -347,7 +360,7 @@ public class ArrayList extends AbstractList } /** - * 删除该列表中指定位置的元素。 将任何后续元素移动到左侧（从其索引中减去一个元素）。 + * 删除该列表中指定位置的元素。 将任何后续元素移动到左侧（从其索引中减去一个元素）。 */ public E remove(int index) { rangeCheck(index); @@ -360,7 +373,7 @@ public class ArrayList extends AbstractList System.arraycopy(elementData, index+1, elementData, index, numMoved); elementData[--size] = null; // clear to let GC do its work - //从列表中删除的元素 + //从列表中删除的元素 return oldValue; } @@ -399,7 +412,7 @@ public class ArrayList extends AbstractList } /** - * 从列表中删除所有元素。 + * 从列表中删除所有元素。 */ public void clear() { modCount++; @@ -485,7 +498,7 @@ public class ArrayList extends AbstractList } /** - * 从此列表中删除指定集合中包含的所有元素。 + * 从此列表中删除指定集合中包含的所有元素。 */ public boolean removeAll(Collection c) { Objects.requireNonNull(c); @@ -495,7 +508,7 @@ public class ArrayList extends AbstractList /** * 仅保留此列表中包含在指定集合中的元素。 - *换句话说，从此列表中删除其中不包含在指定集合中的所有元素。 + *换句话说，从此列表中删除其中不包含在指定集合中的所有元素。 */ public boolean retainAll(Collection c) { Objects.requireNonNull(c); @@ -505,8 +518,8 @@ public class ArrayList extends AbstractList /** * 从列表中的指定位置开始，返回列表中的元素（按正确顺序）的列表迭代器。 - *指定的索引表示初始调用将返回的第一个元素为next 。 初始调用previous将返回指定索引减1的元素。 - *返回的列表迭代器是fail-fast 。 + *指定的索引表示初始调用将返回的第一个元素为next 。 初始调用previous将返回指定索引减1的元素。 + *返回的列表迭代器是fail-fast 。 */ public ListIterator listIterator(int index) { if (index < 0 || index > size) @@ -515,7 +528,7 @@ public class ArrayList extends AbstractList } /** - *返回列表中的列表迭代器（按适当的顺序）。 + *返回列表中的列表迭代器（按适当的顺序）。 *返回的列表迭代器是fail-fast 。 */ public ListIterator listIterator() { @@ -523,75 +536,103 @@ public class ArrayList extends AbstractList } /** - *以正确的顺序返回该列表中的元素的迭代器。 - *返回的迭代器是fail-fast 。 + *以正确的顺序返回该列表中的元素的迭代器。 + *返回的迭代器是fail-fast 。 */ public Iterator iterator() { return new Itr(); } - + ``` -### ArrayList源码分析 -#### System.arraycopy()和Arrays.copyOf()方法 -　　通过上面源码我们发现这两个实现数组复制的方法被广泛使用而且很多地方都特别巧妙。比如下面add(int index, E element)方法就很巧妙的用到了arraycopy()方法让数组自己复制自己实现让index开始之后的所有成员后移一个位置: -```java - /** - * 在此列表中的指定位置插入指定的元素。 - *先调用 rangeCheckForAdd 对index进行界限检查；然后调用 ensureCapacityInternal 方法保证capacity足够大； - *再将从index开始之后的所有成员后移一个位置；将element插入index位置；最后size加1。 + +## 3. ArrayList 扩容机制分析 + +### 3.1. 先从 ArrayList 的构造函数说起 + +**（JDK8）ArrayList 有三种方式来初始化，构造方法源码如下：** + +```java + /** + * 默认初始容量大小 */ - public void add(int index, E element) { - rangeCheckForAdd(index); + private static final int DEFAULT_CAPACITY = 10; - ensureCapacityInternal(size + 1); // Increments modCount!! - //arraycopy()方法实现数组自己复制自己 - //elementData:源数组;index:源数组中的起始位置;elementData：目标数组；index + 1：目标数组中的起始位置； size - index：要复制的数组元素的数量； - System.arraycopy(elementData, index, elementData, index + 1, size - index); - elementData[index] = element; - size++; + + private static final Object[] DEFAULTCAPACITY_EMPTY_ELEMENTDATA = {}; + + /** + *默认构造函数，使用初始容量10构造一个空列表(无参数构造) + */ + public ArrayList() { + this.elementData = DEFAULTCAPACITY_EMPTY_ELEMENTDATA; } -``` -又如toArray()方法中用到了copyOf()方法 -```java /** - *以正确的顺序（从第一个到最后一个元素）返回一个包含此列表中所有元素的数组。 - *返回的数组将是“安全的”，因为该列表不保留对它的引用。 （换句话说，这个方法必须分配一个新的数组）。 - *因此，调用者可以自由地修改返回的数组。 此方法充当基于阵列和基于集合的API之间的桥梁。 + * 带初始容量参数的构造函数。（用户自己指定容量） */ - public Object[] toArray() { - //elementData：要复制的数组；size：要复制的长度 - return Arrays.copyOf(elementData, size); + public ArrayList(int initialCapacity) { + if (initialCapacity > 0) {//初始容量大于0 + //创建initialCapacity大小的数组 + this.elementData = new Object[initialCapacity]; + } else if (initialCapacity == 0) {//初始容量等于0 + //创建空数组 + this.elementData = EMPTY_ELEMENTDATA; + } else {//初始容量小于0，抛出异常 + throw new IllegalArgumentException("Illegal Capacity: "+ + initialCapacity); + } + } + + + /** + *构造包含指定collection元素的列表，这些元素利用该集合的迭代器按顺序返回 + *如果指定的集合为null，throws NullPointerException。 + */ + public ArrayList(Collection c) { + elementData = c.toArray(); + if ((size = elementData.length) != 0) { + // c.toArray might (incorrectly) not return Object[] (see 6260652) + if (elementData.getClass() != Object[].class) + elementData = Arrays.copyOf(elementData, size, Object[].class); + } else { + // replace with empty array. + this.elementData = EMPTY_ELEMENTDATA; + } } + ``` -##### 两者联系与区别 -**联系：** -看两者源代码可以发现`copyOf()`内部调用了`System.arraycopy()`方法 -**区别：** -1. arraycopy()需要目标数组，将原数组拷贝到你自己定义的数组里，而且可以选择拷贝的起点和长度以及放入新数组中的位置 -2. copyOf()是系统自动在内部新建一个数组，并返回该数组。 -#### ArrayList 核心扩容技术 + +细心的同学一定会发现 ：**以无参数构造方法创建 `ArrayList` 时，实际上初始化赋值的是一个空数组。当真正对数组进行添加元素操作时，才真正分配容量。即向数组中添加第一个元素时，数组容量扩为 10。** 下面在我们分析 ArrayList 扩容时会讲到这一点内容！ + +> 补充：JDK6 new 无参构造的 `ArrayList` 对象时，直接创建了长度是 10 的 `Object[]` 数组 elementData 。 + +### 3.2. 一步一步分析 ArrayList 扩容机制 + +这里以无参构造函数创建的 ArrayList 为例分析 + +#### 3.2.1. 先来看 `add` 方法 + ```java -//下面是ArrayList的扩容机制 -//ArrayList的扩容机制提高了性能，如果每次只扩充一个， -//那么频繁的插入会导致频繁的拷贝，降低性能，而ArrayList的扩容机制避免了这种情况。 /** - * 如有必要，增加此ArrayList实例的容量，以确保它至少能容纳元素的数量 - * @param minCapacity 所需的最小容量 + * 将指定的元素追加到此列表的末尾。 */ - public void ensureCapacity(int minCapacity) { - int minExpand = (elementData != DEFAULTCAPACITY_EMPTY_ELEMENTDATA) - // any size if not default element table - ? 0 - // larger than default for default empty table. It's already - // supposed to be at default size. - : DEFAULT_CAPACITY; - - if (minCapacity > minExpand) { - ensureExplicitCapacity(minCapacity); - } + public boolean add(E e) { + //添加元素之前，先调用ensureCapacityInternal方法 + ensureCapacityInternal(size + 1); // Increments modCount!! + //这里看到ArrayList添加元素的实质就相当于为数组赋值 + elementData[size++] = e; + return true; } +``` + +> **注意** ：JDK11 移除了 `ensureCapacityInternal()` 和 `ensureExplicitCapacity()` 方法 + +#### 3.2.2. 再来看看 `ensureCapacityInternal()` 方法 + +（JDK7）可以看到 `add` 方法 首先调用了`ensureCapacityInternal(size + 1)` + +```java //得到最小扩容量 private void ensureCapacityInternal(int minCapacity) { if (elementData == DEFAULTCAPACITY_EMPTY_ELEMENTDATA) { @@ -601,25 +642,49 @@ public class ArrayList extends AbstractList ensureExplicitCapacity(minCapacity); } - //判断是否需要扩容,上面两个方法都要调用 +``` + +**当 要 add 进第 1 个元素时，minCapacity 为 1，在 Math.max()方法比较后，minCapacity 为 10。** + +> 此处和后续 JDK8 代码格式化略有不同，核心代码基本一样。 + +#### 3.2.3. `ensureExplicitCapacity()` 方法 + +如果调用 `ensureCapacityInternal()` 方法就一定会进入（执行）这个方法，下面我们来研究一下这个方法的源码！ + +```java + //判断是否需要扩容 private void ensureExplicitCapacity(int minCapacity) { modCount++; - // 如果说minCapacity也就是所需的最小容量大于保存ArrayList数据的数组的长度的话，就需要调用grow(minCapacity)方法扩容。 - //这个minCapacity到底为多少呢？举个例子在添加元素(add)方法中这个minCapacity的大小就为现在数组的长度加1 + // overflow-conscious code if (minCapacity - elementData.length > 0) //调用grow方法进行扩容，调用此方法代表已经开始扩容了 grow(minCapacity); } ``` + +我们来仔细分析一下： + +- 当我们要 add 进第 1 个元素到 ArrayList 时，elementData.length 为 0 （因为还是一个空的 list），因为执行了 `ensureCapacityInternal()` 方法 ，所以 minCapacity 此时为 10。此时，`minCapacity - elementData.length > 0`成立，所以会进入 `grow(minCapacity)` 方法。 +- 当 add 第 2 个元素时，minCapacity 为 2，此时 e lementData.length(容量)在添加第一个元素后扩容成 10 了。此时，`minCapacity - elementData.length > 0` 不成立，所以不会进入 （执行）`grow(minCapacity)` 方法。 +- 添加第 3、4···到第 10 个元素时，依然不会执行 grow 方法，数组容量都为 10。 + +直到添加第 11 个元素，minCapacity(为 11)比 elementData.length（为 10）要大。进入 grow 方法进行扩容。 + +#### 3.2.4. `grow()` 方法 + ```java + /** + * 要分配的最大数组大小 + */ + private static final int MAX_ARRAY_SIZE = Integer.MAX_VALUE - 8; + /** * ArrayList扩容的核心方法。 */ private void grow(int minCapacity) { - //elementData为保存ArrayList数据的数组 - ///elementData.length求数组长度elementData.size是求数组中的元素个数 // oldCapacity为旧容量，newCapacity为新容量 int oldCapacity = elementData.length; //将oldCapacity 右移一位，其效果相当于oldCapacity /2， @@ -628,110 +693,251 @@ public class ArrayList extends AbstractList //然后检查新容量是否大于最小需要容量，若还是小于最小需要容量，那么就把最小需要容量当作数组的新容量， if (newCapacity - minCapacity < 0) newCapacity = minCapacity; - //再检查新容量是否超出了ArrayList所定义的最大容量， - //若超出了，则调用hugeCapacity()来比较minCapacity和 MAX_ARRAY_SIZE， - //如果minCapacity大于MAX_ARRAY_SIZE，则新容量则为Interger.MAX_VALUE，否则，新容量大小则为 MAX_ARRAY_SIZE。 + // 如果新容量大于 MAX_ARRAY_SIZE,进入(执行) `hugeCapacity()` 方法来比较 minCapacity 和 MAX_ARRAY_SIZE， + //如果minCapacity大于最大容量，则新容量则为`Integer.MAX_VALUE`，否则，新容量大小则为 MAX_ARRAY_SIZE 即为 `Integer.MAX_VALUE - 8`。 if (newCapacity - MAX_ARRAY_SIZE > 0) newCapacity = hugeCapacity(minCapacity); // minCapacity is usually close to size, so this is a win: elementData = Arrays.copyOf(elementData, newCapacity); } - ``` -　　扩容机制代码已经做了详细的解释。另外值得注意的是大家很容易忽略的一个运算符：**移位运算符** -　　**简介**：移位运算符就是在二进制的基础上对数字进行平移。按照平移的方向和填充数字的规则分为三种:<<(左移)、>>(带符号右移)和>>>(无符号右移)。 -　　**作用**：**对于大数据的2进制运算,位移运算符比那些普通运算符的运算要快很多,因为程序仅仅移动一下而已,不去计算,这样提高了效率,节省了资源** -　　比如这里：int newCapacity = oldCapacity + (oldCapacity >> 1); -右移一位相当于除2，右移n位相当于除以 2 的 n 次方。这里 oldCapacity 明显右移了1位所以相当于oldCapacity /2。 -**另外需要注意的是：** +**int newCapacity = oldCapacity + (oldCapacity >> 1),所以 ArrayList 每次扩容之后容量都会变为原来的 1.5 倍左右（oldCapacity 为偶数就是 1.5 倍，否则是 1.5 倍左右）！** 奇偶不同，比如 ：10+10/2 = 15, 33+33/2=49。如果是奇数的话会丢掉小数. + +> ">>"（移位运算符）：>>1 右移一位相当于除 2，右移 n 位相当于除以 2 的 n 次方。这里 oldCapacity 明显右移了 1 位所以相当于 oldCapacity /2。对于大数据的 2 进制运算,位移运算符比那些普通运算符的运算要快很多,因为程序仅仅移动一下而已,不去计算,这样提高了效率,节省了资源 + +**我们再来通过例子探究一下`grow()` 方法 ：** + +- 当 add 第 1 个元素时，oldCapacity 为 0，经比较后第一个 if 判断成立，newCapacity = minCapacity(为 10)。但是第二个 if 判断不会成立，即 newCapacity 不比 MAX_ARRAY_SIZE 大，则不会进入 `hugeCapacity` 方法。数组容量为 10，add 方法中 return true,size 增为 1。 +- 当 add 第 11 个元素进入 grow 方法时，newCapacity 为 15，比 minCapacity（为 11）大，第一个 if 判断不成立。新容量没有大于数组最大 size，不会进入 hugeCapacity 方法。数组容量扩为 15，add 方法中 return true,size 增为 11。 +- 以此类推······ + +**这里补充一点比较重要，但是容易被忽视掉的知识点：** + +- java 中的 `length`属性是针对数组说的,比如说你声明了一个数组,想知道这个数组的长度则用到了 length 这个属性. +- java 中的 `length()` 方法是针对字符串说的,如果想看这个字符串的长度则用到 `length()` 这个方法. +- java 中的 `size()` 方法是针对泛型集合说的,如果想看这个泛型有多少个元素,就调用此方法来查看! + +#### 3.2.5. `hugeCapacity()` 方法。 + +从上面 `grow()` 方法源码我们知道： 如果新容量大于 MAX_ARRAY_SIZE,进入(执行) `hugeCapacity()` 方法来比较 minCapacity 和 MAX_ARRAY_SIZE，如果 minCapacity 大于最大容量，则新容量则为`Integer.MAX_VALUE`，否则，新容量大小则为 MAX_ARRAY_SIZE 即为 `Integer.MAX_VALUE - 8`。 + +```java + private static int hugeCapacity(int minCapacity) { + if (minCapacity < 0) // overflow + throw new OutOfMemoryError(); + //对minCapacity和MAX_ARRAY_SIZE进行比较 + //若minCapacity大，将Integer.MAX_VALUE作为新数组的大小 + //若MAX_ARRAY_SIZE大，将MAX_ARRAY_SIZE作为新数组的大小 + //MAX_ARRAY_SIZE = Integer.MAX_VALUE - 8; + return (minCapacity > MAX_ARRAY_SIZE) ? + Integer.MAX_VALUE : + MAX_ARRAY_SIZE; + } +``` + +### 3.3. `System.arraycopy()` 和 `Arrays.copyOf()`方法 + +阅读源码的话，我们就会发现 ArrayList 中大量调用了这两个方法。比如：我们上面讲的扩容操作以及`add(int index, E element)`、`toArray()` 等方法中都用到了该方法！ + +#### 3.3.1. `System.arraycopy()` 方法 + +源码： + +```java + // 我们发现 arraycopy 是一个 native 方法,接下来我们解释一下各个参数的具体意义 + /** + * 复制数组 + * @param src 源数组 + * @param srcPos 源数组中的起始位置 + * @param dest 目标数组 + * @param destPos 目标数组中的起始位置 + * @param length 要复制的数组元素的数量 + */ + public static native void arraycopy(Object src, int srcPos, + Object dest, int destPos, + int length); +``` + +场景： + +```java + /** + * 在此列表中的指定位置插入指定的元素。 + *先调用 rangeCheckForAdd 对index进行界限检查；然后调用 ensureCapacityInternal 方法保证capacity足够大； + *再将从index开始之后的所有成员后移一个位置；将element插入index位置；最后size加1。 + */ + public void add(int index, E element) { + rangeCheckForAdd(index); + + ensureCapacityInternal(size + 1); // Increments modCount!! + //arraycopy()方法实现数组自己复制自己 + //elementData:源数组;index:源数组中的起始位置;elementData：目标数组；index + 1：目标数组中的起始位置； size - index：要复制的数组元素的数量； + System.arraycopy(elementData, index, elementData, index + 1, size - index); + elementData[index] = element; + size++; + } +``` + +我们写一个简单的方法测试以下： + +```java +public class ArraycopyTest { + + public static void main(String[] args) { + // TODO Auto-generated method stub + int[] a = new int[10]; + a[0] = 0; + a[1] = 1; + a[2] = 2; + a[3] = 3; + System.arraycopy(a, 2, a, 3, 3); + a[2]=99; + for (int i = 0; i < a.length; i++) { + System.out.print(a[i] + " "); + } + } + +} +``` + +结果： + +``` +0 1 99 2 3 0 0 0 0 0 +``` + +#### 3.3.2. `Arrays.copyOf()`方法 + +源码： + +```java + public static int[] copyOf(int[] original, int newLength) { + // 申请一个新的数组 + int[] copy = new int[newLength]; + // 调用System.arraycopy,将源数组中的数据进行拷贝,并返回新的数组 + System.arraycopy(original, 0, copy, 0, + Math.min(original.length, newLength)); + return copy; + } +``` + +场景： + +```java + /** + 以正确的顺序返回一个包含此列表中所有元素的数组（从第一个到最后一个元素）; 返回的数组的运行时类型是指定数组的运行时类型。 + */ + public Object[] toArray() { + //elementData：要复制的数组；size：要复制的长度 + return Arrays.copyOf(elementData, size); + } +``` + +个人觉得使用 `Arrays.copyOf()`方法主要是为了给原有数组扩容，测试代码如下： -1. java 中的**length 属性**是针对数组说的,比如说你声明了一个数组,想知道这个数组的长度则用到了 length 这个属性. +```java +public class ArrayscopyOfTest { + + public static void main(String[] args) { + int[] a = new int[3]; + a[0] = 0; + a[1] = 1; + a[2] = 2; + int[] b = Arrays.copyOf(a, 10); + System.out.println("b.length"+b.length); + } +} +``` + +结果： -2. java 中的**length()方法**是针对字 符串String说的,如果想看这个字符串的长度则用到 length()这个方法. +``` +10 +``` -3. .java 中的**size()方法**是针对泛型集合说的,如果想看这个泛型有多少个元素,就调用此方法来查看! +#### 3.3.3. 两者联系和区别 + +**联系：** +看两者源代码可以发现 `copyOf()`内部实际调用了 `System.arraycopy()` 方法 + +**区别：** + +`arraycopy()` 需要目标数组，将原数组拷贝到你自己定义的数组里或者原数组，而且可以选择拷贝的起点和长度以及放入新数组中的位置 `copyOf()` 是系统自动在内部新建一个数组，并返回该数组。 + +### 3.4. `ensureCapacity`方法 + +ArrayList 源码中有一个 `ensureCapacity` 方法不知道大家注意到没有，这个方法 ArrayList 内部没有被调用过，所以很显然是提供给用户调用的，那么这个方法有什么作用呢？ -#### 内部类 ```java - (1)private class Itr implements Iterator - (2)private class ListItr extends Itr implements ListIterator - (3)private class SubList extends AbstractList implements RandomAccess - (4)static final class ArrayListSpliterator implements Spliterator + /** + 如有必要，增加此 ArrayList 实例的容量，以确保它至少可以容纳由minimum capacity参数指定的元素数。 + * + * @param minCapacity 所需的最小容量 + */ + public void ensureCapacity(int minCapacity) { + int minExpand = (elementData != DEFAULTCAPACITY_EMPTY_ELEMENTDATA) + // any size if not default element table + ? 0 + // larger than default for default empty table. It's already + // supposed to be at default size. + : DEFAULT_CAPACITY; + + if (minCapacity > minExpand) { + ensureExplicitCapacity(minCapacity); + } + } + +``` + +**最好在 add 大量元素之前用 `ensureCapacity` 方法，以减少增量重新分配的次数** + +我们通过下面的代码实际测试以下这个方法的效果： + +```java +public class EnsureCapacityTest { + public static void main(String[] args) { + ArrayList list = new ArrayList(); + final int N = 10000000; + long startTime = System.currentTimeMillis(); + for (int i = 0; i < N; i++) { + list.add(i); + } + long endTime = System.currentTimeMillis(); + System.out.println("使用ensureCapacity方法前："+(endTime - startTime)); + + } +} +``` + +运行结果： + +``` +使用ensureCapacity方法前：2158 ``` -　　ArrayList有四个内部类，其中的**Itr是实现了Iterator接口**，同时重写了里面的**hasNext()**，**next()**，**remove()**等方法；其中的**ListItr**继承**Itr**，实现了**ListIterator接口**，同时重写了**hasPrevious()**，**nextIndex()**，**previousIndex()**，**previous()**，**set(E e)**，**add(E e)**等方法，所以这也可以看出了 **Iterator和ListIterator的区别:**ListIterator在Iterator的基础上增加了添加对象，修改对象，逆向遍历等方法，这些是Iterator不能实现的。 -### ArrayList经典Demo ```java -package list; -import java.util.ArrayList; -import java.util.Iterator; - -public class ArrayListDemo { - - public static void main(String[] srgs){ - ArrayList arrayList = new ArrayList(); - - System.out.printf("Before add:arrayList.size() = %d\n",arrayList.size()); - - arrayList.add(1); - arrayList.add(3); - arrayList.add(5); - arrayList.add(7); - arrayList.add(9); - System.out.printf("After add:arrayList.size() = %d\n",arrayList.size()); - - System.out.println("Printing elements of arrayList"); - // 三种遍历方式打印元素 - // 第一种：通过迭代器遍历 - System.out.print("通过迭代器遍历:"); - Iterator it = arrayList.iterator(); - while(it.hasNext()){ - System.out.print(it.next() + " "); - } - System.out.println(); - - // 第二种：通过索引值遍历 - System.out.print("通过索引值遍历:"); - for(int i = 0; i < arrayList.size(); i++){ - System.out.print(arrayList.get(i) + " "); - } - System.out.println(); - - // 第三种：for循环遍历 - System.out.print("for循环遍历:"); - for(Integer number : arrayList){ - System.out.print(number + " "); - } - - // toArray用法 - // 第一种方式(最常用) - Integer[] integer = arrayList.toArray(new Integer[0]); - - // 第二种方式(容易理解) - Integer[] integer1 = new Integer[arrayList.size()]; - arrayList.toArray(integer1); - - // 抛出异常，java不支持向下转型 - //Integer[] integer2 = new Integer[arrayList.size()]; - //integer2 = arrayList.toArray(); - System.out.println(); - - // 在指定位置添加元素 - arrayList.add(2,2); - // 删除指定位置上的元素 - arrayList.remove(2); - // 删除指定元素 - arrayList.remove((Object)3); - // 判断arrayList是否包含5 - System.out.println("ArrayList contains 5 is: " + arrayList.contains(5)); - - // 清空ArrayList - arrayList.clear(); - // 判断ArrayList是否为空 - System.out.println("ArrayList is empty: " + arrayList.isEmpty()); +public class EnsureCapacityTest { + public static void main(String[] args) { + ArrayList list = new ArrayList(); + final int N = 10000000; + list = new ArrayList(); + long startTime1 = System.currentTimeMillis(); + list.ensureCapacity(N); + for (int i = 0; i < N; i++) { + list.add(i); + } + long endTime1 = System.currentTimeMillis(); + System.out.println("使用ensureCapacity方法后："+(endTime1 - startTime1)); } } ``` +运行结果： + +``` +使用ensureCapacity方法后：1773 +``` + +通过运行结果，我们可以看出向 ArrayList 添加大量元素之前最好先使用`ensureCapacity` 方法，以减少增量重新分配的次数。 diff --git a/docs/java/collection/concurrent-hash-map-source-code.md b/docs/java/collection/concurrent-hash-map-source-code.md new file mode 100644 index 0000000000000000000000000000000000000000..74e5faac17dc9955c0a341e17079fea9544596b1 --- /dev/null +++ b/docs/java/collection/concurrent-hash-map-source-code.md @@ -0,0 +1,594 @@ +--- +title: ConcurrentHashMap源码&底层数据结构分析 +category: Java +tag: + - Java集合 +--- + + +> 本文来自公众号：末读代码的投稿，原文地址：https://mp.weixin.qq.com/s/AHWzboztt53ZfFZmsSnMSw 。 + +上一篇文章介绍了 HashMap 源码，反响不错，也有很多同学发表了自己的观点，这次又来了，这次是 `ConcurrentHashMap ` 了，作为线程安全的HashMap ，它的使用频率也是很高。那么它的存储结构和实现原理是怎么样的呢？ + +## 1. ConcurrentHashMap 1.7 + +### 1. 存储结构 + +> 下图存在两个笔误 : Segmeng -> Segment ; HashEntity -> HashEntry + +![Java 7 ConcurrentHashMap 存储结构](./images/image-20200405151029416.png) + +Java 7 中 `ConcurrentHashMap` 的存储结构如上图，`ConcurrnetHashMap` 由很多个 `Segment` 组合，而每一个 `Segment` 是一个类似于 HashMap 的结构，所以每一个 `HashMap` 的内部可以进行扩容。但是 `Segment` 的个数一旦**初始化就不能改变**，默认 `Segment` 的个数是 16 个，你也可以认为 `ConcurrentHashMap` 默认支持最多 16 个线程并发。 + +### 2. 初始化 + +通过 ConcurrentHashMap 的无参构造探寻 ConcurrentHashMap 的初始化流程。 + +```java + /** + * Creates a new, empty map with a default initial capacity (16), + * load factor (0.75) and concurrencyLevel (16). + */ + public ConcurrentHashMap() { + this(DEFAULT_INITIAL_CAPACITY, DEFAULT_LOAD_FACTOR, DEFAULT_CONCURRENCY_LEVEL); + } +``` + +无参构造中调用了有参构造，传入了三个参数的默认值，他们的值是。 + +```java + /** + * 默认初始化容量 + */ + static final int DEFAULT_INITIAL_CAPACITY = 16; + + /** + * 默认负载因子 + */ + static final float DEFAULT_LOAD_FACTOR = 0.75f; + + /** + * 默认并发级别 + */ + static final int DEFAULT_CONCURRENCY_LEVEL = 16; +``` + +接着看下这个有参构造函数的内部实现逻辑。 + +```java +@SuppressWarnings("unchecked") +public ConcurrentHashMap(int initialCapacity,float loadFactor, int concurrencyLevel) { + // 参数校验 + if (!(loadFactor > 0) || initialCapacity < 0 || concurrencyLevel <= 0) + throw new IllegalArgumentException(); + // 校验并发级别大小，大于 1<<16，重置为 65536 + if (concurrencyLevel > MAX_SEGMENTS) + concurrencyLevel = MAX_SEGMENTS; + // Find power-of-two sizes best matching arguments + // 2的多少次方 + int sshift = 0; + int ssize = 1; + // 这个循环可以找到 concurrencyLevel 之上最近的 2的次方值 + while (ssize < concurrencyLevel) { + ++sshift; + ssize <<= 1; + } + // 记录段偏移量 + this.segmentShift = 32 - sshift; + // 记录段掩码 + this.segmentMask = ssize - 1; + // 设置容量 + if (initialCapacity > MAXIMUM_CAPACITY) + initialCapacity = MAXIMUM_CAPACITY; + // c = 容量 / ssize ，默认 16 / 16 = 1，这里是计算每个 Segment 中的类似于 HashMap 的容量 + int c = initialCapacity / ssize; + if (c * ssize < initialCapacity) + ++c; + int cap = MIN_SEGMENT_TABLE_CAPACITY; + //Segment 中的类似于 HashMap 的容量至少是2或者2的倍数 + while (cap < c) + cap <<= 1; + // create segments and segments[0] + // 创建 Segment 数组，设置 segments[0] + Segment s0 = new Segment(loadFactor, (int)(cap * loadFactor), + (HashEntry[])new HashEntry[cap]); + Segment[] ss = (Segment[])new Segment[ssize]; + UNSAFE.putOrderedObject(ss, SBASE, s0); // ordered write of segments[0] + this.segments = ss; +} +``` + +总结一下在 Java 7 中 ConcurrnetHashMap 的初始化逻辑。 + +1. 必要参数校验。 +2. 校验并发级别 concurrencyLevel 大小，如果大于最大值，重置为最大值。无参构造**默认值是 16.** +3. 寻找并发级别 concurrencyLevel 之上最近的 **2 的幂次方**值，作为初始化容量大小，**默认是 16**。 +4. 记录 segmentShift 偏移量，这个值为【容量 = 2 的N次方】中的 N，在后面 Put 时计算位置时会用到。**默认是 32 - sshift = 28**. +5. 记录 segmentMask，默认是 ssize - 1 = 16 -1 = 15. +6. **初始化 segments[0]**，**默认大小为 2**，**负载因子 0.75**，**扩容阀值是 2*0.75=1.5**，插入第二个值时才会进行扩容。 + +### 3. put + +接着上面的初始化参数继续查看 put 方法源码。 + +```java +/** + * Maps the specified key to the specified value in this table. + * Neither the key nor the value can be null. + * + *

The value can be retrieved by calling the get method + * with a key that is equal to the original key. + * + * @param key key with which the specified value is to be associated + * @param value value to be associated with the specified key + * @return the previous value associated with key, or + * null if there was no mapping for key + * @throws NullPointerException if the specified key or value is null + */ +public V put(K key, V value) { + Segment s; + if (value == null) + throw new NullPointerException(); + int hash = hash(key); + // hash 值无符号右移 28位（初始化时获得），然后与 segmentMask=15 做与运算 + // 其实也就是把高4位与segmentMask（1111）做与运算 + int j = (hash >>> segmentShift) & segmentMask; + if ((s = (Segment)UNSAFE.getObject // nonvolatile; recheck + (segments, (j << SSHIFT) + SBASE)) == null) // in ensureSegment + // 如果查找到的 Segment 为空，初始化 + s = ensureSegment(j); + return s.put(key, hash, value, false); +} + +/** + * Returns the segment for the given index, creating it and + * recording in segment table (via CAS) if not already present. + * + * @param k the index + * @return the segment + */ +@SuppressWarnings("unchecked") +private Segment ensureSegment(int k) { + final Segment[] ss = this.segments; + long u = (k << SSHIFT) + SBASE; // raw offset + Segment seg; + // 判断 u 位置的 Segment 是否为null + if ((seg = (Segment)UNSAFE.getObjectVolatile(ss, u)) == null) { + Segment proto = ss[0]; // use segment 0 as prototype + // 获取0号 segment 里的 HashEntry 初始化长度 + int cap = proto.table.length; + // 获取0号 segment 里的 hash 表里的扩容负载因子，所有的 segment 的 loadFactor 是相同的 + float lf = proto.loadFactor; + // 计算扩容阀值 + int threshold = (int)(cap * lf); + // 创建一个 cap 容量的 HashEntry 数组 + HashEntry[] tab = (HashEntry[])new HashEntry[cap]; + if ((seg = (Segment)UNSAFE.getObjectVolatile(ss, u)) == null) { // recheck + // 再次检查 u 位置的 Segment 是否为null，因为这时可能有其他线程进行了操作 + Segment s = new Segment(lf, threshold, tab); + // 自旋检查 u 位置的 Segment 是否为null + while ((seg = (Segment)UNSAFE.getObjectVolatile(ss, u)) + == null) { + // 使用CAS 赋值，只会成功一次 + if (UNSAFE.compareAndSwapObject(ss, u, null, seg = s)) + break; + } + } + } + return seg; +} +``` + +上面的源码分析了 ConcurrentHashMap 在 put 一个数据时的处理流程，下面梳理下具体流程。 + +1. 计算要 put 的 key 的位置，获取指定位置的 Segment。 + +2. 如果指定位置的 Segment 为空，则初始化这个 Segment. + + **初始化 Segment 流程：** + + 1. 检查计算得到的位置的 Segment 是否为null. + 2. 为 null 继续初始化，使用 Segment[0] 的容量和负载因子创建一个 HashEntry 数组。 + 3. 再次检查计算得到的指定位置的 Segment 是否为null. + 4. 使用创建的 HashEntry 数组初始化这个 Segment. + 5. 自旋判断计算得到的指定位置的 Segment 是否为null，使用 CAS 在这个位置赋值为 Segment. + +3. Segment.put 插入 key,value 值。 + +上面探究了获取 Segment 段和初始化 Segment 段的操作。最后一行的 Segment 的 put 方法还没有查看，继续分析。 + +```java +final V put(K key, int hash, V value, boolean onlyIfAbsent) { + // 获取 ReentrantLock 独占锁，获取不到，scanAndLockForPut 获取。 + HashEntry node = tryLock() ? null : scanAndLockForPut(key, hash, value); + V oldValue; + try { + HashEntry[] tab = table; + // 计算要put的数据位置 + int index = (tab.length - 1) & hash; + // CAS 获取 index 坐标的值 + HashEntry first = entryAt(tab, index); + for (HashEntry e = first;;) { + if (e != null) { + // 检查是否 key 已经存在，如果存在，则遍历链表寻找位置，找到后替换 value + K k; + if ((k = e.key) == key || + (e.hash == hash && key.equals(k))) { + oldValue = e.value; + if (!onlyIfAbsent) { + e.value = value; + ++modCount; + } + break; + } + e = e.next; + } + else { + // first 有值没说明 index 位置已经有值了，有冲突，链表头插法。 + if (node != null) + node.setNext(first); + else + node = new HashEntry(hash, key, value, first); + int c = count + 1; + // 容量大于扩容阀值，小于最大容量，进行扩容 + if (c > threshold && tab.length < MAXIMUM_CAPACITY) + rehash(node); + else + // index 位置赋值 node，node 可能是一个元素，也可能是一个链表的表头 + setEntryAt(tab, index, node); + ++modCount; + count = c; + oldValue = null; + break; + } + } + } finally { + unlock(); + } + return oldValue; +} +``` + +由于 Segment 继承了 ReentrantLock，所以 Segment 内部可以很方便的获取锁，put 流程就用到了这个功能。 + +1. tryLock() 获取锁，获取不到使用 **`scanAndLockForPut`** 方法继续获取。 + +2. 计算 put 的数据要放入的 index 位置，然后获取这个位置上的 HashEntry 。 + +3. 遍历 put 新元素，为什么要遍历？因为这里获取的 HashEntry 可能是一个空元素，也可能是链表已存在，所以要区别对待。 + + 如果这个位置上的 **HashEntry 不存在**： + + 1. 如果当前容量大于扩容阀值，小于最大容量，**进行扩容**。 + 2. 直接头插法插入。 + + 如果这个位置上的 **HashEntry 存在**： + + 1. 判断链表当前元素 Key 和 hash 值是否和要 put 的 key 和 hash 值一致。一致则替换值 + 2. 不一致，获取链表下一个节点，直到发现相同进行值替换，或者链表表里完毕没有相同的。 + 1. 如果当前容量大于扩容阀值，小于最大容量，**进行扩容**。 + 2. 直接链表头插法插入。 + +4. 如果要插入的位置之前已经存在，替换后返回旧值，否则返回 null. + +这里面的第一步中的 scanAndLockForPut 操作这里没有介绍，这个方法做的操作就是不断的自旋 `tryLock()` 获取锁。当自旋次数大于指定次数时，使用 `lock()` 阻塞获取锁。在自旋时顺表获取下 hash 位置的 HashEntry。 + +```java +private HashEntry scanAndLockForPut(K key, int hash, V value) { + HashEntry first = entryForHash(this, hash); + HashEntry e = first; + HashEntry node = null; + int retries = -1; // negative while locating node + // 自旋获取锁 + while (!tryLock()) { + HashEntry f; // to recheck first below + if (retries < 0) { + if (e == null) { + if (node == null) // speculatively create node + node = new HashEntry(hash, key, value, null); + retries = 0; + } + else if (key.equals(e.key)) + retries = 0; + else + e = e.next; + } + else if (++retries > MAX_SCAN_RETRIES) { + // 自旋达到指定次数后，阻塞等到只到获取到锁 + lock(); + break; + } + else if ((retries & 1) == 0 && + (f = entryForHash(this, hash)) != first) { + e = first = f; // re-traverse if entry changed + retries = -1; + } + } + return node; +} + +``` + +### 4. 扩容 rehash + +ConcurrentHashMap 的扩容只会扩容到原来的两倍。老数组里的数据移动到新的数组时，位置要么不变，要么变为 index+ oldSize，参数里的 node 会在扩容之后使用链表**头插法**插入到指定位置。 + +```java +private void rehash(HashEntry node) { + HashEntry[] oldTable = table; + // 老容量 + int oldCapacity = oldTable.length; + // 新容量，扩大两倍 + int newCapacity = oldCapacity << 1; + // 新的扩容阀值 + threshold = (int)(newCapacity * loadFactor); + // 创建新的数组 + HashEntry[] newTable = (HashEntry[]) new HashEntry[newCapacity]; + // 新的掩码，默认2扩容后是4，-1是3，二进制就是11。 + int sizeMask = newCapacity - 1; + for (int i = 0; i < oldCapacity ; i++) { + // 遍历老数组 + HashEntry e = oldTable[i]; + if (e != null) { + HashEntry next = e.next; + // 计算新的位置，新的位置只可能是不便或者是老的位置+老的容量。 + int idx = e.hash & sizeMask; + if (next == null) // Single node on list + // 如果当前位置还不是链表，只是一个元素，直接赋值 + newTable[idx] = e; + else { // Reuse consecutive sequence at same slot + // 如果是链表了 + HashEntry lastRun = e; + int lastIdx = idx; + // 新的位置只可能是不便或者是老的位置+老的容量。 + // 遍历结束后，lastRun 后面的元素位置都是相同的 + for (HashEntry last = next; last != null; last = last.next) { + int k = last.hash & sizeMask; + if (k != lastIdx) { + lastIdx = k; + lastRun = last; + } + } + // ，lastRun 后面的元素位置都是相同的，直接作为链表赋值到新位置。 + newTable[lastIdx] = lastRun; + // Clone remaining nodes + for (HashEntry p = e; p != lastRun; p = p.next) { + // 遍历剩余元素，头插法到指定 k 位置。 + V v = p.value; + int h = p.hash; + int k = h & sizeMask; + HashEntry n = newTable[k]; + newTable[k] = new HashEntry(h, p.key, v, n); + } + } + } + } + // 头插法插入新的节点 + int nodeIndex = node.hash & sizeMask; // add the new node + node.setNext(newTable[nodeIndex]); + newTable[nodeIndex] = node; + table = newTable; +} +``` + +有些同学可能会对最后的两个 for 循环有疑惑，这里第一个 for 是为了寻找这样一个节点，这个节点后面的所有 next 节点的新位置都是相同的。然后把这个作为一个链表赋值到新位置。第二个 for 循环是为了把剩余的元素通过头插法插入到指定位置链表。这样实现的原因可能是基于概率统计，有深入研究的同学可以发表下意见。 + +### 5. get + +到这里就很简单了，get 方法只需要两步即可。 + +1. 计算得到 key 的存放位置。 +2. 遍历指定位置查找相同 key 的 value 值。 + +```java +public V get(Object key) { + Segment s; // manually integrate access methods to reduce overhead + HashEntry[] tab; + int h = hash(key); + long u = (((h >>> segmentShift) & segmentMask) << SSHIFT) + SBASE; + // 计算得到 key 的存放位置 + if ((s = (Segment)UNSAFE.getObjectVolatile(segments, u)) != null && + (tab = s.table) != null) { + for (HashEntry e = (HashEntry) UNSAFE.getObjectVolatile + (tab, ((long)(((tab.length - 1) & h)) << TSHIFT) + TBASE); + e != null; e = e.next) { + // 如果是链表，遍历查找到相同 key 的 value。 + K k; + if ((k = e.key) == key || (e.hash == h && key.equals(k))) + return e.value; + } + } + return null; +} +``` + +## 2. ConcurrentHashMap 1.8 + +### 1. 存储结构 + +![Java8 ConcurrentHashMap 存储结构（图片来自 javadoop）](./images/java8_concurrenthashmap.png) + +可以发现 Java8 的 ConcurrentHashMap 相对于 Java7 来说变化比较大，不再是之前的 **Segment 数组 + HashEntry 数组 + 链表**，而是 **Node 数组 + 链表 / 红黑树**。当冲突链表达到一定长度时，链表会转换成红黑树。 + +### 2. 初始化 initTable + +```java +/** + * Initializes table, using the size recorded in sizeCtl. + */ +private final Node[] initTable() { + Node[] tab; int sc; + while ((tab = table) == null || tab.length == 0) { + ／／　如果 sizeCtl < 0 ,说明另外的线程执行CAS 成功，正在进行初始化。 + if ((sc = sizeCtl) < 0) + // 让出 CPU 使用权 + Thread.yield(); // lost initialization race; just spin + else if (U.compareAndSwapInt(this, SIZECTL, sc, -1)) { + try { + if ((tab = table) == null || tab.length == 0) { + int n = (sc > 0) ? sc : DEFAULT_CAPACITY; + @SuppressWarnings("unchecked") + Node[] nt = (Node[])new Node[n]; + table = tab = nt; + sc = n - (n >>> 2); + } + } finally { + sizeCtl = sc; + } + break; + } + } + return tab; +} +``` + +从源码中可以发现 ConcurrentHashMap 的初始化是通过**自旋和 CAS** 操作完成的。里面需要注意的是变量 `sizeCtl` ，它的值决定着当前的初始化状态。 + +1. -1 说明正在初始化 +2. -N 说明有N-1个线程正在进行扩容 +3. 表示 table 初始化大小，如果 table 没有初始化 +4. 表示 table 容量，如果 table　已经初始化。 + +### 3. put + +直接过一遍 put 源码。 + +```java +public V put(K key, V value) { + return putVal(key, value, false); +} + +/** Implementation for put and putIfAbsent */ +final V putVal(K key, V value, boolean onlyIfAbsent) { + // key 和 value 不能为空 + if (key == null || value == null) throw new NullPointerException(); + int hash = spread(key.hashCode()); + int binCount = 0; + for (Node[] tab = table;;) { + // f = 目标位置元素 + Node f; int n, i, fh;// fh 后面存放目标位置的元素 hash 值 + if (tab == null || (n = tab.length) == 0) + // 数组桶为空，初始化数组桶（自旋+CAS) + tab = initTable(); + else if ((f = tabAt(tab, i = (n - 1) & hash)) == null) { + // 桶内为空，CAS 放入，不加锁，成功了就直接 break 跳出 + if (casTabAt(tab, i, null,new Node(hash, key, value, null))) + break; // no lock when adding to empty bin + } + else if ((fh = f.hash) == MOVED) + tab = helpTransfer(tab, f); + else { + V oldVal = null; + // 使用 synchronized 加锁加入节点 + synchronized (f) { + if (tabAt(tab, i) == f) { + // 说明是链表 + if (fh >= 0) { + binCount = 1; + // 循环加入新的或者覆盖节点 + for (Node e = f;; ++binCount) { + K ek; + if (e.hash == hash && + ((ek = e.key) == key || + (ek != null && key.equals(ek)))) { + oldVal = e.val; + if (!onlyIfAbsent) + e.val = value; + break; + } + Node pred = e; + if ((e = e.next) == null) { + pred.next = new Node(hash, key, + value, null); + break; + } + } + } + else if (f instanceof TreeBin) { + // 红黑树 + Node p; + binCount = 2; + if ((p = ((TreeBin)f).putTreeVal(hash, key, + value)) != null) { + oldVal = p.val; + if (!onlyIfAbsent) + p.val = value; + } + } + } + } + if (binCount != 0) { + if (binCount >= TREEIFY_THRESHOLD) + treeifyBin(tab, i); + if (oldVal != null) + return oldVal; + break; + } + } + } + addCount(1L, binCount); + return null; +} +``` + +1. 根据 key 计算出 hashcode 。 + +2. 判断是否需要进行初始化。 + +3. 即为当前 key 定位出的 Node，如果为空表示当前位置可以写入数据，利用 CAS 尝试写入，失败则自旋保证成功。 + +4. 如果当前位置的 `hashcode == MOVED == -1`,则需要进行扩容。 + +5. 如果都不满足，则利用 synchronized 锁写入数据。 + +6. 如果数量大于 `TREEIFY_THRESHOLD` 则要执行树化方法，在treeifyBin中会首先判断当前数组长度≥64时才会将链表转换为红黑树。 + +### 4. get + +get 流程比较简单，直接过一遍源码。 + +```java +public V get(Object key) { + Node[] tab; Node e, p; int n, eh; K ek; + // key 所在的 hash 位置 + int h = spread(key.hashCode()); + if ((tab = table) != null && (n = tab.length) > 0 && + (e = tabAt(tab, (n - 1) & h)) != null) { + // 如果指定位置元素存在，头结点hash值相同 + if ((eh = e.hash) == h) { + if ((ek = e.key) == key || (ek != null && key.equals(ek))) + // key hash 值相等，key值相同，直接返回元素 value + return e.val; + } + else if (eh < 0) + // 头结点hash值小于0，说明正在扩容或者是红黑树，find查找 + return (p = e.find(h, key)) != null ? p.val : null; + while ((e = e.next) != null) { + // 是链表，遍历查找 + if (e.hash == h && + ((ek = e.key) == key || (ek != null && key.equals(ek)))) + return e.val; + } + } + return null; +} +``` + +总结一下 get 过程： + +1. 根据 hash 值计算位置。 +2. 查找到指定位置，如果头节点就是要找的，直接返回它的 value. +3. 如果头节点 hash 值小于 0 ，说明正在扩容或者是红黑树，查找之。 +4. 如果是链表，遍历查找之。 + +总结： + +总的来说 ConcurrentHashMap 在 Java8 中相对于 Java7 来说变化还是挺大的， + +## 3. 总结 + +Java7 中 ConcurrentHashMap 使用的分段锁，也就是每一个 Segment 上同时只有一个线程可以操作，每一个 Segment 都是一个类似 HashMap 数组的结构，它可以扩容，它的冲突会转化为链表。但是 Segment 的个数一但初始化就不能改变。 + +Java8 中的 ConcurrentHashMap 使用的 Synchronized 锁加 CAS 的机制。结构也由 Java7 中的 **Segment 数组 + HashEntry 数组 + 链表** 进化成了 **Node 数组 + 链表 / 红黑树**，Node 是类似于一个 HashEntry 的结构。它的冲突再达到一定大小时会转化成红黑树，在冲突小于一定数量时又退回链表。 + +有些同学可能对 Synchronized 的性能存在疑问，其实 Synchronized 锁自从引入锁升级策略后，性能不再是问题，有兴趣的同学可以自己了解下 Synchronized 的**锁升级**。 diff --git "a/Java\347\233\270\345\205\263/HashMap.md" b/docs/java/collection/hashmap-source-code.md similarity index 71% rename from "Java\347\233\270\345\205\263/HashMap.md" rename to docs/java/collection/hashmap-source-code.md index 45fad50cdb3617b94f0b0a08a230538bd43cc63f..7d8e4c46a2b85bd270b0f306f8d58d0915e550a4 100644 --- "a/Java\347\233\270\345\205\263/HashMap.md" +++ b/docs/java/collection/hashmap-source-code.md @@ -1,45 +1,48 @@ - +--- +title: HashMap源码&底层数据结构分析 +category: Java +tag: + - Java集合 +--- -- [HashMap 简介](#hashmap-简介) -- [底层数据结构分析](#底层数据结构分析) - - [JDK1.8之前](#jdk18之前) - - [JDK1.8之后](#jdk18之后) -- [HashMap源码分析](#hashmap源码分析) - - [构造方法](#构造方法) - - [put方法](#put方法) - - [get方法](#get方法) - - [resize方法](#resize方法) -- [HashMap常用方法测试](#hashmap常用方法测试) - - > 感谢 [changfubai](https://github.com/changfubai) 对本文的改进做出的贡献！ ## HashMap 简介 -HashMap 主要用来存放键值对，它基于哈希表的Map接口实现，是常用的Java集合之一。 -JDK1.8 之前 HashMap 由 数组+链表 组成的，数组是 HashMap 的主体，链表则是主要为了解决哈希冲突而存在的（“拉链法”解决冲突）.JDK1.8 以后在解决哈希冲突时有了较大的变化，当链表长度大于阈值（默认为 8）时，将链表转化为红黑树，以减少搜索时间。 +HashMap 主要用来存放键值对，它基于哈希表的 Map 接口实现，是常用的 Java 集合之一，是非线程安全的。 + + `HashMap` 可以存储 null 的 key 和 value，但 null 作为键只能有一个，null 作为值可以有多个 + +JDK1.8 之前 HashMap 由 数组+链表 组成的，数组是 HashMap 的主体，链表则是主要为了解决哈希冲突而存在的（“拉链法”解决冲突）。 JDK1.8 以后的 `HashMap` 在解决哈希冲突时有了较大的变化，当链表长度大于阈值（默认为 8）（将链表转换成红黑树前会判断，如果当前数组的长度小于 64，那么会选择先进行数组扩容，而不是转换为红黑树）时，将链表转化为红黑树，以减少搜索时间。 + +`HashMap` 默认的初始化大小为 16。之后每次扩充，容量变为原来的 2 倍。并且， `HashMap` 总是使用 2 的幂作为哈希表的大小。 ## 底层数据结构分析 -### JDK1.8之前 -JDK1.8 之前 HashMap 底层是 **数组和链表** 结合在一起使用也就是 **链表散列**。**HashMap 通过 key 的 hashCode 经过扰动函数处理过后得到 hash 值，然后通过 `(n - 1) & hash` 判断当前元素存放的位置（这里的 n 指的是数组的长度），如果当前位置存在元素的话，就判断该元素与要存入的元素的 hash 值以及 key 是否相同，如果相同的话，直接覆盖，不相同就通过拉链法解决冲突。** -**所谓扰动函数指的就是 HashMap 的 hash 方法。使用 hash 方法也就是扰动函数是为了防止一些实现比较差的 hashCode() 方法 换句话说使用扰动函数之后可以减少碰撞。** +### JDK1.8 之前 + +JDK1.8 之前 HashMap 底层是 **数组和链表** 结合在一起使用也就是 **链表散列**。 + +HashMap 通过 key 的 hashCode 经过扰动函数处理过后得到 hash 值，然后通过 `(n - 1) & hash` 判断当前元素存放的位置（这里的 n 指的是数组的长度），如果当前位置存在元素的话，就判断该元素与要存入的元素的 hash 值以及 key 是否相同，如果相同的话，直接覆盖，不相同就通过拉链法解决冲突。 + +所谓扰动函数指的就是 HashMap 的 hash 方法。使用 hash 方法也就是扰动函数是为了防止一些实现比较差的 hashCode() 方法 换句话说使用扰动函数之后可以减少碰撞。 **JDK 1.8 HashMap 的 hash 方法源码:** -JDK 1.8 的 hash方法 相比于 JDK 1.7 hash 方法更加简化，但是原理不变。 +JDK 1.8 的 hash 方法 相比于 JDK 1.7 hash 方法更加简化，但是原理不变。 - ```java - static final int hash(Object key) { - int h; - // key.hashCode()：返回散列值也就是hashcode - // ^ ：按位异或 - // >>>:无符号右移，忽略符号位，空位都以0补齐 - return (key == null) ? 0 : (h = key.hashCode()) ^ (h >>> 16); - } - ``` -对比一下 JDK1.7的 HashMap 的 hash 方法源码. +```java + static final int hash(Object key) { + int h; + // key.hashCode()：返回散列值也就是hashcode + // ^ ：按位异或 + // >>>:无符号右移，忽略符号位，空位都以0补齐 + return (key == null) ? 0 : (h = key.hashCode()) ^ (h >>> 16); + } +``` + +对比一下 JDK1.7 的 HashMap 的 hash 方法源码. ```java static int hash(int h) { @@ -56,57 +59,62 @@ static int hash(int h) { 所谓 **“拉链法”** 就是：将链表和数组相结合。也就是说创建一个链表数组，数组中每一格就是一个链表。若遇到哈希冲突，则将冲突的值加到链表中即可。 -![jdk1.8之前的内部结构](https://user-gold-cdn.xitu.io/2018/3/20/16240dbcc303d872?w=348&h=427&f=png&s=10991) +![jdk1.8之前的内部结构](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/2019-7/jdk1.8之前的内部结构.png) + +### JDK1.8 之后 + +相比于之前的版本，JDK1.8 以后在解决哈希冲突时有了较大的变化。 -### JDK1.8之后 -相比于之前的版本，jdk1.8在解决哈希冲突时有了较大的变化，当链表长度大于阈值（默认为8）时，将链表转化为红黑树，以减少搜索时间。 +当链表长度大于阈值（默认为 8）时，会首先调用 `treeifyBin()`方法。这个方法会根据 HashMap 数组来决定是否转换为红黑树。只有当数组长度大于或者等于 64 的情况下，才会执行转换红黑树操作，以减少搜索时间。否则，就是只是执行 `resize()` 方法对数组扩容。相关源码这里就不贴了，重点关注 `treeifyBin()`方法即可！ -![JDK1.8之后的HashMap底层数据结构](http://my-blog-to-use.oss-cn-beijing.aliyuncs.com/18-8-22/67233764.jpg) +![](https://oscimg.oschina.net/oscnet/up-bba283228693dae74e78da1ef7a9a04c684.png) **类的属性：** + ```java public class HashMap extends AbstractMap implements Map, Cloneable, Serializable { // 序列号 - private static final long serialVersionUID = 362498820763181265L; + private static final long serialVersionUID = 362498820763181265L; // 默认的初始容量是16 - static final int DEFAULT_INITIAL_CAPACITY = 1 << 4; + static final int DEFAULT_INITIAL_CAPACITY = 1 << 4; // 最大容量 - static final int MAXIMUM_CAPACITY = 1 << 30; + static final int MAXIMUM_CAPACITY = 1 << 30; // 默认的填充因子 static final float DEFAULT_LOAD_FACTOR = 0.75f; // 当桶(bucket)上的结点数大于这个值时会转成红黑树 - static final int TREEIFY_THRESHOLD = 8; + static final int TREEIFY_THRESHOLD = 8; // 当桶(bucket)上的结点数小于这个值时树转链表 static final int UNTREEIFY_THRESHOLD = 6; - // 桶中结构转化为红黑树对应的table的最小大小 + // 桶中结构转化为红黑树对应的table的最小容量 static final int MIN_TREEIFY_CAPACITY = 64; // 存储元素的数组，总是2的幂次倍 - transient Node[] table; + transient Node[] table; // 存放具体元素的集 transient Set> entrySet; // 存放元素的个数，注意这个不等于数组的长度。 transient int size; // 每次扩容和更改map结构的计数器 - transient int modCount; - // 临界值 当实际大小(容量*填充因子)超过临界值时，会进行扩容 + transient int modCount; + // 临界值(容量*填充因子) 当实际大小超过临界值时，会进行扩容 int threshold; // 加载因子 final float loadFactor; } ``` -- **loadFactor加载因子** - loadFactor加载因子是控制数组存放数据的疏密程度，loadFactor越趋近于1，那么 数组中存放的数据(entry)也就越多，也就越密，也就是会让链表的长度增加，loadFactor越小，也就是趋近于0，数组中存放的数据(entry)也就越少，也就越稀疏。 +- **loadFactor 加载因子** + + loadFactor 加载因子是控制数组存放数据的疏密程度，loadFactor 越趋近于 1，那么 数组中存放的数据(entry)也就越多，也就越密，也就是会让链表的长度增加，loadFactor 越小，也就是趋近于 0，数组中存放的数据(entry)也就越少，也就越稀疏。 - **loadFactor太大导致查找元素效率低，太小导致数组的利用率低，存放的数据会很分散。loadFactor的默认值为0.75f是官方给出的一个比较好的临界值**。 - - 给定的默认容量为 16，负载因子为 0.75。Map 在使用过程中不断的往里面存放数据，当数量达到了 16 * 0.75 = 12 就需要将当前 16 的容量进行扩容，而扩容这个过程涉及到 rehash、复制数据等操作，所以非常消耗性能。 + **loadFactor 太大导致查找元素效率低，太小导致数组的利用率低，存放的数据会很分散。loadFactor 的默认值为 0.75f 是官方给出的一个比较好的临界值**。 + + 给定的默认容量为 16，负载因子为 0.75。Map 在使用过程中不断的往里面存放数据，当数量达到了 16 \* 0.75 = 12 就需要将当前 16 的容量进行扩容，而扩容这个过程涉及到 rehash、复制数据等操作，所以非常消耗性能。 - **threshold** - **threshold = capacity * loadFactor**，**当Size>=threshold**的时候，那么就要考虑对数组的扩增了，也就是说，这个的意思就是 **衡量数组是否需要扩增的一个标准**。 + **threshold = capacity \* loadFactor**，**当 Size>=threshold**的时候，那么就要考虑对数组的扩增了，也就是说，这个的意思就是 **衡量数组是否需要扩增的一个标准**。 -**Node节点类源码:** +**Node 节点类源码:** ```java // 继承自 Map.Entry @@ -149,7 +157,9 @@ static class Node implements Map.Entry { } } ``` + **树节点类源码:** + ```java static final class TreeNode extends LinkedHashMap.Entry { TreeNode parent; // 父 @@ -168,26 +178,30 @@ static final class TreeNode extends LinkedHashMap.Entry { r = p; } ``` -## HashMap源码分析 + +## HashMap 源码分析 + ### 构造方法 -![四个构造方法](https://user-gold-cdn.xitu.io/2018/3/20/162410d912a2e0e1?w=336&h=90&f=jpeg&s=26744) + +HashMap 中有四个构造方法，它们分别如下： + ```java // 默认构造函数。 public HashMap() { this.loadFactor = DEFAULT_LOAD_FACTOR; // all other fields defaulted } - + // 包含另一个“Map”的构造函数 public HashMap(Map m) { this.loadFactor = DEFAULT_LOAD_FACTOR; putMapEntries(m, false);//下面会分析到这个方法 } - + // 指定“容量大小”的构造函数 public HashMap(int initialCapacity) { this(initialCapacity, DEFAULT_LOAD_FACTOR); } - + // 指定“容量大小”和“加载因子”的构造函数 public HashMap(int initialCapacity, float loadFactor) { if (initialCapacity < 0) @@ -201,7 +215,7 @@ static final class TreeNode extends LinkedHashMap.Entry { } ``` -**putMapEntries方法：** +**putMapEntries 方法：** ```java final void putMapEntries(Map m, boolean evict) { @@ -229,17 +243,22 @@ final void putMapEntries(Map m, boolean evict) { } } ``` -### put方法 -HashMap只提供了put用于添加元素，putVal方法只是给put方法调用的一个方法，并没有提供给用户使用。 -**对putVal方法添加元素的分析如下：** +### put 方法 -- ①如果定位到的数组位置没有元素 就直接插入。 -- ②如果定位到的数组位置有元素就和要插入的key比较，如果key相同就直接覆盖，如果key不相同，就判断p是否是一个树节点，如果是就调用`e = ((TreeNode)p).putTreeVal(this, tab, hash, key, value)`将元素添加进入。如果不是就遍历链表插入。 +HashMap 只提供了 put 用于添加元素，putVal 方法只是给 put 方法调用的一个方法，并没有提供给用户使用。 +**对 putVal 方法添加元素的分析如下：** +1. 如果定位到的数组位置没有元素 就直接插入。 +2. 如果定位到的数组位置有元素就和要插入的 key 比较，如果 key 相同就直接覆盖，如果 key 不相同，就判断 p 是否是一个树节点，如果是就调用`e = ((TreeNode)p).putTreeVal(this, tab, hash, key, value)`将元素添加进入。如果不是就遍历链表插入(插入的是链表尾部)。 -![put方法](https://user-gold-cdn.xitu.io/2018/9/2/16598bf758c747e6?w=999&h=679&f=png&s=54486) +![ ](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/2019-7/put方法.png) + +说明:上图有两个小问题： + +- 直接覆盖之后应该就会 return，不会有后续操作。参考 JDK8 HashMap.java 658 行（[issue#608](https://github.com/Snailclimb/JavaGuide/issues/608)）。 +- 当链表长度大于阈值（默认为 8）并且 HashMap 数组长度超过 64 的时候才会执行链表转红黑树的操作，否则就只是对数组扩容。参考 HashMap 的 `treeifyBin()` 方法（[issue#1087](https://github.com/Snailclimb/JavaGuide/issues/1087)）。 ```java public V put(K key, V value) { @@ -275,7 +294,9 @@ final V putVal(int hash, K key, V value, boolean onlyIfAbsent, if ((e = p.next) == null) { // 在尾部插入新结点 p.next = newNode(hash, key, value, null); - // 结点数量达到阈值，转化为红黑树 + // 结点数量达到阈值(默认为 8 )，执行 treeifyBin 方法 + // 这个方法会根据 HashMap 数组来决定是否转换为红黑树。 + // 只有当数组长度大于或者等于 64 的情况下，才会执行转换红黑树操作，以减少搜索时间。否则，就是只是对数组扩容。 if (binCount >= TREEIFY_THRESHOLD - 1) // -1 for 1st treeifyBin(tab, hash); // 跳出循环 @@ -291,7 +312,7 @@ final V putVal(int hash, K key, V value, boolean onlyIfAbsent, } } // 表示在桶中找到key值、hash值与插入元素相等的结点 - if (e != null) { + if (e != null) { // 记录e的value V oldValue = e.value; // onlyIfAbsent为false或者旧值为null @@ -312,21 +333,21 @@ final V putVal(int hash, K key, V value, boolean onlyIfAbsent, // 插入后回调 afterNodeInsertion(evict); return null; -} +} ``` -**我们再来对比一下 JDK1.7 put方法的代码** +**我们再来对比一下 JDK1.7 put 方法的代码** -**对于put方法的分析如下：** +**对于 put 方法的分析如下：** -- ①如果定位到的数组位置没有元素 就直接插入。 -- ②如果定位到的数组位置有元素，遍历以这个元素为头结点的链表，依次和插入的key比较，如果key相同就直接覆盖，不同就采用头插法插入元素。 +- ① 如果定位到的数组位置没有元素 就直接插入。 +- ② 如果定位到的数组位置有元素，遍历以这个元素为头结点的链表，依次和插入的 key 比较，如果 key 相同就直接覆盖，不同就采用头插法插入元素。 ```java public V put(K key, V value) - if (table == EMPTY_TABLE) { - inflateTable(threshold); -} + if (table == EMPTY_TABLE) { + inflateTable(threshold); +} if (key == null) return putForNullKey(value); int hash = hash(key); @@ -337,7 +358,7 @@ public V put(K key, V value) V oldValue = e.value; e.value = value; e.recordAccess(this); - return oldValue; + return oldValue; } } @@ -347,9 +368,8 @@ public V put(K key, V value) } ``` +### get 方法 - -### get方法 ```java public V get(Object key) { Node e; @@ -380,8 +400,11 @@ final Node getNode(int hash, Object key) { return null; } ``` -### resize方法 -进行扩容，会伴随着一次重新hash分配，并且会遍历hash表中所有的元素，是非常耗时的。在编写程序中，要尽量避免resize。 + +### resize 方法 + +进行扩容，会伴随着一次重新 hash 分配，并且会遍历 hash 表中所有的元素，是非常耗时的。在编写程序中，要尽量避免 resize。 + ```java final Node[] resize() { Node[] oldTab = table; @@ -400,7 +423,7 @@ final Node[] resize() { } else if (oldThr > 0) // initial capacity was placed in threshold newCap = oldThr; - else { + else { // signifies using defaults newCap = DEFAULT_INITIAL_CAPACITY; newThr = (int)(DEFAULT_LOAD_FACTOR * DEFAULT_INITIAL_CAPACITY); @@ -424,7 +447,7 @@ final Node[] resize() { newTab[e.hash & (newCap - 1)] = e; else if (e instanceof TreeNode) ((TreeNode)e).split(this, newTab, j, oldCap); - else { + else { Node loHead = null, loTail = null; Node hiHead = null, hiTail = null; Node next; @@ -464,7 +487,9 @@ final Node[] resize() { return newTab; } ``` -## HashMap常用方法测试 + +## HashMap 常用方法测试 + ```java package map; @@ -510,7 +535,8 @@ public class HashMapDemo { } /** - * 另外一种不常用的遍历方式 + * 如果既要遍历key又要value，那么建议这种方式，因为如果先获取keySet然后再执行map.get(key)，map内部会执行两次遍历。 + * 一次是在获取keySet的时候，一次是在遍历所有key的时候。 */ // 当我调用put(key,value)方法的时候，首先会把key和value封装到 // Entry这个静态内部类对象中，把Entry对象再添加到数组中，所以我们想获取 @@ -520,7 +546,7 @@ public class HashMapDemo { for (java.util.Map.Entry entry : entrys) { System.out.println(entry.getKey() + "--" + entry.getValue()); } - + /** * HashMap其他常用方法 */ @@ -536,5 +562,4 @@ public class HashMapDemo { } } - ``` diff --git "a/docs/java/collection/images/TreeMap\347\273\247\346\211\277\347\273\223\346\236\204.png" "b/docs/java/collection/images/TreeMap\347\273\247\346\211\277\347\273\223\346\236\204.png" new file mode 100755 index 0000000000000000000000000000000000000000..b423f99915d2c1227f9d43d82ae8ac98a4096d05 Binary files /dev/null and "b/docs/java/collection/images/TreeMap\347\273\247\346\211\277\347\273\223\346\236\204.png" differ diff --git a/docs/java/collection/images/ad28e3ba-e419-4724-869c-73879e604da1.png b/docs/java/collection/images/ad28e3ba-e419-4724-869c-73879e604da1.png new file mode 100755 index 0000000000000000000000000000000000000000..8d802d64b333d6b58974d9c440f669a05a19e43e Binary files /dev/null and b/docs/java/collection/images/ad28e3ba-e419-4724-869c-73879e604da1.png differ diff --git a/docs/java/collection/images/image-20200405151029416.png b/docs/java/collection/images/image-20200405151029416.png new file mode 100755 index 0000000000000000000000000000000000000000..e8f6a24044c60ec3d211c51a41b865eafefa1710 Binary files /dev/null and b/docs/java/collection/images/image-20200405151029416.png differ diff --git a/docs/java/collection/images/java-collection-hierarchy.png b/docs/java/collection/images/java-collection-hierarchy.png new file mode 100755 index 0000000000000000000000000000000000000000..84c470a1effc8c52dc35a0f75a285022e7d4d6d8 Binary files /dev/null and b/docs/java/collection/images/java-collection-hierarchy.png differ diff --git a/docs/java/collection/images/java8_concurrenthashmap.png b/docs/java/collection/images/java8_concurrenthashmap.png new file mode 100755 index 0000000000000000000000000000000000000000..604c4931f52f8e09996aadc4718afe4b0f8a210e Binary files /dev/null and b/docs/java/collection/images/java8_concurrenthashmap.png differ diff --git "a/docs/java/collection/images/jdk1.8\344\271\213\345\211\215\347\232\204\345\206\205\351\203\250\347\273\223\346\236\204-HashMap.png" "b/docs/java/collection/images/jdk1.8\344\271\213\345\211\215\347\232\204\345\206\205\351\203\250\347\273\223\346\236\204-HashMap.png" new file mode 100755 index 0000000000000000000000000000000000000000..df7fe6780df6e784212879814e431f0696aaef5e Binary files /dev/null and "b/docs/java/collection/images/jdk1.8\344\271\213\345\211\215\347\232\204\345\206\205\351\203\250\347\273\223\346\236\204-HashMap.png" differ diff --git "a/docs/java/collection/images/jdk1.8\344\271\213\345\220\216\347\232\204\345\206\205\351\203\250\347\273\223\346\236\204-HashMap.png" "b/docs/java/collection/images/jdk1.8\344\271\213\345\220\216\347\232\204\345\206\205\351\203\250\347\273\223\346\236\204-HashMap.png" new file mode 100755 index 0000000000000000000000000000000000000000..1228048a96ef72b7c8e5d5d528341507d770c0fa Binary files /dev/null and "b/docs/java/collection/images/jdk1.8\344\271\213\345\220\216\347\232\204\345\206\205\351\203\250\347\273\223\346\236\204-HashMap.png" differ diff --git a/docs/java/collection/java-collection-precautions-for-use.md b/docs/java/collection/java-collection-precautions-for-use.md new file mode 100644 index 0000000000000000000000000000000000000000..6a65c33a2641c931c856f2ad501232d91f694210 --- /dev/null +++ b/docs/java/collection/java-collection-precautions-for-use.md @@ -0,0 +1,439 @@ +--- +title: Java集合使用注意事项总结 +category: Java +tag: + - Java集合 +--- + +这篇文章我根据《阿里巴巴 Java 开发手册》总结了关于集合使用常见的注意事项以及其具体原理。 + +强烈建议小伙伴们多多阅读几遍，避免自己写代码的时候出现这些低级的问题。 + +## 集合判空 + +《阿里巴巴 Java 开发手册》的描述如下： + +> **判断所有集合内部的元素是否为空，使用 `isEmpty()` 方法，而不是 `size()==0` 的方式。** + +这是因为 `isEmpty()` 方法的可读性更好，并且时间复杂度为 O(1)。 + +绝大部分我们使用的集合的 `size()` 方法的时间复杂度也是 O(1)，不过，也有很多复杂度不是 O(1) 的，比如 `java.util.concurrent` 包下的某些集合（`ConcurrentLinkedQueue` 、`ConcurrentHashMap`...）。 + +下面是 `ConcurrentHashMap` 的 `size()` 方法和 `isEmpty()` 方法的源码。 + +```java +public int size() { + long n = sumCount(); + return ((n < 0L) ? 0 : + (n > (long)Integer.MAX_VALUE) ? Integer.MAX_VALUE : + (int)n); +} +final long sumCount() { + CounterCell[] as = counterCells; CounterCell a; + long sum = baseCount; + if (as != null) { + for (int i = 0; i < as.length; ++i) { + if ((a = as[i]) != null) + sum += a.value; + } + } + return sum; +} +public boolean isEmpty() { + return sumCount() <= 0L; // ignore transient negative values +} +``` + +## 集合转 Map + +《阿里巴巴 Java 开发手册》的描述如下： + +> **在使用 `java.util.stream.Collectors` 类的 `toMap()` 方法转为 `Map` 集合时，一定要注意当 value 为 null 时会抛 NPE 异常。** + +```java +class Person { + private String name; + private String phoneNumber; + // getters and setters +} + +List bookList = new ArrayList<>(); +bookList.add(new Person("jack","18163138123")); +bookList.add(new Person("martin",null)); +// 空指针异常 +bookList.stream().collect(Collectors.toMap(Person::getName, Person::getPhoneNumber)); +``` + +下面我们来解释一下原因。 + +首先，我们来看 `java.util.stream.Collectors` 类的 `toMap()` 方法 ，可以看到其内部调用了 `Map` 接口的 `merge()` 方法。 + +```java +public static > +Collector toMap(Function keyMapper, + Function valueMapper, + BinaryOperator mergeFunction, + Supplier mapSupplier) { + BiConsumer accumulator + = (map, element) -> map.merge(keyMapper.apply(element), + valueMapper.apply(element), mergeFunction); + return new CollectorImpl<>(mapSupplier, accumulator, mapMerger(mergeFunction), CH_ID); +} +``` + +`Map` 接口的 `merge()` 方法如下，这个方法是接口中的默认实现。 + +> 如果你还不了解 Java 8 新特性的话，请看这篇文章：[《Java8 新特性总结》](https://mp.weixin.qq.com/s/ojyl7B6PiHaTWADqmUq2rw) 。 + +```java +default V merge(K key, V value, + BiFunction remappingFunction) { + Objects.requireNonNull(remappingFunction); + Objects.requireNonNull(value); + V oldValue = get(key); + V newValue = (oldValue == null) ? value : + remappingFunction.apply(oldValue, value); + if(newValue == null) { + remove(key); + } else { + put(key, newValue); + } + return newValue; +} +``` + +`merge()` 方法会先调用 `Objects.requireNonNull()` 方法判断 value 是否为空。 + +```java +public static T requireNonNull(T obj) { + if (obj == null) + throw new NullPointerException(); + return obj; +} +``` + +## 集合遍历 + +《阿里巴巴 Java 开发手册》的描述如下： + +> **不要在 foreach 循环里进行元素的 `remove/add` 操作。remove 元素请使用 `Iterator` 方式，如果并发操作，需要对 `Iterator` 对象加锁。** + +通过反编译你会发现 foreach 语法糖底层其实还是依赖 `Iterator` 。不过， `remove/add` 操作直接调用的是集合自己的方法，而不是 `Iterator` 的 `remove/add`方法 + +这就导致 `Iterator` 莫名其妙地发现自己有元素被 `remove/add` ，然后，它就会抛出一个 `ConcurrentModificationException` 来提示用户发生了并发修改异常。这就是单线程状态下产生的 **fail-fast 机制**。 + +> **fail-fast 机制** ：多个线程对 fail-fast 集合进行修改的时候，可能会抛出`ConcurrentModificationException`。 即使是单线程下也有可能会出现这种情况，上面已经提到过。 + +Java8 开始，可以使用 `Collection#removeIf()`方法删除满足特定条件的元素,如 + +```java +List list = new ArrayList<>(); +for (int i = 1; i <= 10; ++i) { + list.add(i); +} +list.removeIf(filter -> filter % 2 == 0); /* 删除list中的所有偶数 */ +System.out.println(list); /* [1, 3, 5, 7, 9] */ +``` + +除了上面介绍的直接使用 `Iterator` 进行遍历操作之外，你还可以： + +- 使用普通的 for 循环 +- 使用 fail-safe 的集合类。`java.util`包下面的所有的集合类都是 fail-fast 的，而`java.util.concurrent`包下面的所有的类都是 fail-safe 的。 +- ...... + +## 集合去重 + +《阿里巴巴 Java 开发手册》的描述如下： + +> **可以利用 `Set` 元素唯一的特性，可以快速对一个集合进行去重操作，避免使用 `List` 的 `contains()` 进行遍历去重或者判断包含操作。** + +这里我们以 `HashSet` 和 `ArrayList` 为例说明。 + +```java +// Set 去重代码示例 +public static Set removeDuplicateBySet(List data) { + + if (CollectionUtils.isEmpty(data)) { + return new HashSet<>(); + } + return new HashSet<>(data); +} + +// List 去重代码示例 +public static List removeDuplicateByList(List data) { + + if (CollectionUtils.isEmpty(data)) { + return new ArrayList<>(); + + } + List result = new ArrayList<>(data.size()); + for (T current : data) { + if (!result.contains(current)) { + result.add(current); + } + } + return result; +} + +``` + +两者的核心差别在于 `contains()` 方法的实现。 + +`HashSet` 的 `contains()` 方法底部依赖的 `HashMap` 的 `containsKey()` 方法，时间复杂度接近于 O（1）（没有出现哈希冲突的时候为 O（1））。 + +```java +private transient HashMap map; +public boolean contains(Object o) { + return map.containsKey(o); +} +``` + +我们有 N 个元素插入进 Set 中，那时间复杂度就接近是 O (n)。 + +`ArrayList` 的 `contains()` 方法是通过遍历所有元素的方法来做的，时间复杂度接近是 O(n)。 + +```java +public boolean contains(Object o) { + return indexOf(o) >= 0; +} +public int indexOf(Object o) { + if (o == null) { + for (int i = 0; i < size; i++) + if (elementData[i]==null) + return i; + } else { + for (int i = 0; i < size; i++) + if (o.equals(elementData[i])) + return i; + } + return -1; +} + +``` + +我们的 `List` 有 N 个元素，那时间复杂度就接近是 O (n^2)。 + +## 集合转数组 + +《阿里巴巴 Java 开发手册》的描述如下： + +> **使用集合转数组的方法，必须使用集合的 `toArray(T[] array)`，传入的是类型完全一致、长度为 0 的空数组。** + +`toArray(T[] array)` 方法的参数是一个泛型数组，如果 `toArray` 方法中没有传递任何参数的话返回的是 `Object`类 型数组。 + +```java +String [] s= new String[]{ + "dog", "lazy", "a", "over", "jumps", "fox", "brown", "quick", "A" +}; +List list = Arrays.asList(s); +Collections.reverse(list); +//没有指定类型的话会报错 +s=list.toArray(new String[0]); +``` + +由于 JVM 优化，`new String[0]`作为`Collection.toArray()`方法的参数现在使用更好，`new String[0]`就是起一个模板的作用，指定了返回数组的类型，0 是为了节省空间，因为它只是为了说明返回的类型。详见： + +## 数组转集合 + +《阿里巴巴 Java 开发手册》的描述如下： + +> **使用工具类 `Arrays.asList()` 把数组转换成集合时，不能使用其修改集合相关的方法， 它的 `add/remove/clear` 方法会抛出 `UnsupportedOperationException` 异常。** + +我在之前的一个项目中就遇到一个类似的坑。 + +`Arrays.asList()`在平时开发中还是比较常见的，我们可以使用它将一个数组转换为一个 `List` 集合。 + +```java +String[] myArray = {"Apple", "Banana", "Orange"}; +List myList = Arrays.asList(myArray); +//上面两个语句等价于下面一条语句 +List myList = Arrays.asList("Apple","Banana", "Orange"); +``` + +JDK 源码对于这个方法的说明： + +```java +/** + *返回由指定数组支持的固定大小的列表。此方法作为基于数组和基于集合的API之间的桥梁， + * 与 Collection.toArray()结合使用。返回的List是可序列化并实现RandomAccess接口。 + */ +public static List asList(T... a) { + return new ArrayList<>(a); +} +``` + +下面我们来总结一下使用注意事项。 + +**1、`Arrays.asList()`是泛型方法，传递的数组必须是对象数组，而不是基本类型。** + +```java +int[] myArray = {1, 2, 3}; +List myList = Arrays.asList(myArray); +System.out.println(myList.size());//1 +System.out.println(myList.get(0));//数组地址值 +System.out.println(myList.get(1));//报错：ArrayIndexOutOfBoundsException +int[] array = (int[]) myList.get(0); +System.out.println(array[0]);//1 +``` + +当传入一个原生数据类型数组时，`Arrays.asList()` 的真正得到的参数就不是数组中的元素，而是数组对象本身！此时 `List` 的唯一元素就是这个数组，这也就解释了上面的代码。 + +我们使用包装类型数组就可以解决这个问题。 + +```java +Integer[] myArray = {1, 2, 3}; +``` + +**2、使用集合的修改方法: `add()`、`remove()`、`clear()`会抛出异常。** + +```java +List myList = Arrays.asList(1, 2, 3); +myList.add(4);//运行时报错：UnsupportedOperationException +myList.remove(1);//运行时报错：UnsupportedOperationException +myList.clear();//运行时报错：UnsupportedOperationException +``` + +`Arrays.asList()` 方法返回的并不是 `java.util.ArrayList` ，而是 `java.util.Arrays` 的一个内部类,这个内部类并没有实现集合的修改方法或者说并没有重写这些方法。 + +```java +List myList = Arrays.asList(1, 2, 3); +System.out.println(myList.getClass());//class java.util.Arrays$ArrayList +``` + +下图是 `java.util.Arrays$ArrayList` 的简易源码，我们可以看到这个类重写的方法有哪些。 + +```java + private static class ArrayList extends AbstractList + implements RandomAccess, java.io.Serializable + { + ... + + @Override + public E get(int index) { + ... + } + + @Override + public E set(int index, E element) { + ... + } + + @Override + public int indexOf(Object o) { + ... + } + + @Override + public boolean contains(Object o) { + ... + } + + @Override + public void forEach(Consumer action) { + ... + } + + @Override + public void replaceAll(UnaryOperator operator) { + ... + } + + @Override + public void sort(Comparator c) { + ... + } + } +``` + +我们再看一下`java.util.AbstractList`的 `add/remove/clear` 方法就知道为什么会抛出 `UnsupportedOperationException` 了。 + +```java +public E remove(int index) { + throw new UnsupportedOperationException(); +} +public boolean add(E e) { + add(size(), e); + return true; +} +public void add(int index, E element) { + throw new UnsupportedOperationException(); +} + +public void clear() { + removeRange(0, size()); +} +protected void removeRange(int fromIndex, int toIndex) { + ListIterator it = listIterator(fromIndex); + for (int i=0, n=toIndex-fromIndex; i List arrayToList(final T[] array) { + final List l = new ArrayList(array.length); + + for (final T s : array) { + l.add(s); + } + return l; +} + + +Integer [] myArray = { 1, 2, 3 }; +System.out.println(arrayToList(myArray).getClass());//class java.util.ArrayList +``` + +2、最简便的方法 + +```java +List list = new ArrayList<>(Arrays.asList("a", "b", "c")) +``` + +3、使用 Java8 的 `Stream`(推荐) + +```java +Integer [] myArray = { 1, 2, 3 }; +List myList = Arrays.stream(myArray).collect(Collectors.toList()); +//基本类型也可以实现转换（依赖boxed的装箱操作） +int [] myArray2 = { 1, 2, 3 }; +List myList = Arrays.stream(myArray2).boxed().collect(Collectors.toList()); +``` + +4、使用 Guava + +对于不可变集合，你可以使用[`ImmutableList`](https://github.com/google/guava/blob/master/guava/src/com/google/common/collect/ImmutableList.java)类及其[`of()`](https://github.com/google/guava/blob/master/guava/src/com/google/common/collect/ImmutableList.java#L101)与[`copyOf()`](https://github.com/google/guava/blob/master/guava/src/com/google/common/collect/ImmutableList.java#L225)工厂方法：（参数不能为空） + +```java +List il = ImmutableList.of("string", "elements"); // from varargs +List il = ImmutableList.copyOf(aStringArray); // from array +``` + +对于可变集合，你可以使用[`Lists`](https://github.com/google/guava/blob/master/guava/src/com/google/common/collect/Lists.java)类及其[`newArrayList()`](https://github.com/google/guava/blob/master/guava/src/com/google/common/collect/Lists.java#L87)工厂方法： + +```java +List l1 = Lists.newArrayList(anotherListOrCollection); // from collection +List l2 = Lists.newArrayList(aStringArray); // from array +List l3 = Lists.newArrayList("or", "string", "elements"); // from varargs +``` + +5、使用 Apache Commons Collections + +```java +List list = new ArrayList(); +CollectionUtils.addAll(list, str); +``` + +6、 使用 Java9 的 `List.of()`方法 + +```java +Integer[] array = {1, 2, 3}; +List list = List.of(array); +``` \ No newline at end of file diff --git a/docs/java/collection/java-collection-questions-01.md b/docs/java/collection/java-collection-questions-01.md new file mode 100644 index 0000000000000000000000000000000000000000..900c1c7108a1463bb0635d99afb495a785f18312 --- /dev/null +++ b/docs/java/collection/java-collection-questions-01.md @@ -0,0 +1,326 @@ +--- +title: Java集合常见知识点&面试题总结(上) +category: Java +tag: + - Java集合 +--- + +## 集合概述 + +### Java 集合概览 + +Java 集合， 也叫作容器，主要是由两大接口派生而来：一个是 `Collection`接口，主要用于存放单一元素；另一个是 `Map` 接口，主要用于存放键值对。对于`Collection` 接口，下面又有三个主要的子接口：`List`、`Set` 和 `Queue`。 + +Java 集合框架如下图所示： + +![](./images/java-collection-hierarchy.png) + + +注：图中只列举了主要的继承派生关系，并没有列举所有关系。比方省略了`AbstractList`, `NavigableSet`等抽象类以及其他的一些辅助类，如想深入了解，可自行查看源码。 + +### 说说 List, Set, Queue, Map 四者的区别？ + +- `List`(对付顺序的好帮手): 存储的元素是有序的、可重复的。 +- `Set`(注重独一无二的性质): 存储的元素是无序的、不可重复的。 +- `Queue`(实现排队功能的叫号机): 按特定的排队规则来确定先后顺序，存储的元素是有序的、可重复的。 +- `Map`(用 key 来搜索的专家): 使用键值对（key-value）存储，类似于数学上的函数 y=f(x)，"x" 代表 key，"y" 代表 value，key 是无序的、不可重复的，value 是无序的、可重复的，每个键最多映射到一个值。 + +### 集合框架底层数据结构总结 + +先来看一下 `Collection` 接口下面的集合。 + +#### List + +- `Arraylist`： `Object[]` 数组 +- `Vector`：`Object[]` 数组 +- `LinkedList`： 双向链表(JDK1.6 之前为循环链表，JDK1.7 取消了循环) + +#### Set + +- `HashSet`(无序，唯一): 基于 `HashMap` 实现的，底层采用 `HashMap` 来保存元素 +- `LinkedHashSet`: `LinkedHashSet` 是 `HashSet` 的子类，并且其内部是通过 `LinkedHashMap` 来实现的。有点类似于我们之前说的 `LinkedHashMap` 其内部是基于 `HashMap` 实现一样，不过还是有一点点区别的 +- `TreeSet`(有序，唯一): 红黑树(自平衡的排序二叉树) + +#### Queue + +- `PriorityQueue`: `Object[]` 数组来实现二叉堆 +- `ArrayQueue`: `Object[]` 数组 + 双指针 + +再来看看 `Map` 接口下面的集合。 + +#### Map + +- `HashMap`： JDK1.8 之前 `HashMap` 由数组+链表组成的，数组是 `HashMap` 的主体，链表则是主要为了解决哈希冲突而存在的（“拉链法”解决冲突）。JDK1.8 以后在解决哈希冲突时有了较大的变化，当链表长度大于阈值（默认为 8）（将链表转换成红黑树前会判断，如果当前数组的长度小于 64，那么会选择先进行数组扩容，而不是转换为红黑树）时，将链表转化为红黑树，以减少搜索时间 +- `LinkedHashMap`： `LinkedHashMap` 继承自 `HashMap`，所以它的底层仍然是基于拉链式散列结构即由数组和链表或红黑树组成。另外，`LinkedHashMap` 在上面结构的基础上，增加了一条双向链表，使得上面的结构可以保持键值对的插入顺序。同时通过对链表进行相应的操作，实现了访问顺序相关逻辑。详细可以查看：[《LinkedHashMap 源码详细分析（JDK1.8）》](https://www.imooc.com/article/22931) +- `Hashtable`： 数组+链表组成的，数组是 `Hashtable` 的主体，链表则是主要为了解决哈希冲突而存在的 +- `TreeMap`： 红黑树（自平衡的排序二叉树） + +### 如何选用集合? + +主要根据集合的特点来选用，比如我们需要根据键值获取到元素值时就选用 `Map` 接口下的集合，需要排序时选择 `TreeMap`,不需要排序时就选择 `HashMap`,需要保证线程安全就选用 `ConcurrentHashMap`。 + +当我们只需要存放元素值时，就选择实现`Collection` 接口的集合，需要保证元素唯一时选择实现 `Set` 接口的集合比如 `TreeSet` 或 `HashSet`，不需要就选择实现 `List` 接口的比如 `ArrayList` 或 `LinkedList`，然后再根据实现这些接口的集合的特点来选用。 + +### 为什么要使用集合？ + +当我们需要保存一组类型相同的数据的时候，我们应该是用一个容器来保存，这个容器就是数组，但是，使用数组存储对象具有一定的弊端， +因为我们在实际开发中，存储的数据的类型是多种多样的，于是，就出现了“集合”，集合同样也是用来存储多个数据的。 + +数组的缺点是一旦声明之后，长度就不可变了；同时，声明数组时的数据类型也决定了该数组存储的数据的类型；而且，数组存储的数据是有序的、可重复的，特点单一。 +但是集合提高了数据存储的灵活性，Java 集合不仅可以用来存储不同类型不同数量的对象，还可以保存具有映射关系的数据。 + +## Collection 子接口之 List + +### Arraylist 和 Vector 的区别? + +- `ArrayList` 是 `List` 的主要实现类，底层使用 `Object[ ]`存储，适用于频繁的查找工作，线程不安全 ； +- `Vector` 是 `List` 的古老实现类，底层使用`Object[ ]` 存储，线程安全的。 + +### Arraylist 与 LinkedList 区别? + +1. **是否保证线程安全：** `ArrayList` 和 `LinkedList` 都是不同步的，也就是不保证线程安全； +2. **底层数据结构：** `Arraylist` 底层使用的是 **`Object` 数组**；`LinkedList` 底层使用的是 **双向链表** 数据结构（JDK1.6 之前为循环链表，JDK1.7 取消了循环。注意双向链表和双向循环链表的区别，下面有介绍到！） +3. **插入和删除是否受元素位置的影响：** + - `ArrayList` 采用数组存储，所以插入和删除元素的时间复杂度受元素位置的影响。 比如：执行`add(E e)`方法的时候， `ArrayList` 会默认在将指定的元素追加到此列表的末尾，这种情况时间复杂度就是 O(1)。但是如果要在指定位置 i 插入和删除元素的话（`add(int index, E element)`）时间复杂度就为 O(n-i)。因为在进行上述操作的时候集合中第 i 和第 i 个元素之后的(n-i)个元素都要执行向后位/向前移一位的操作。 + - `LinkedList` 采用链表存储，所以，如果是在头尾插入或者删除元素不受元素位置的影响（`add(E e)`、`addFirst(E e)`、`addLast(E e)`、`removeFirst()` 、 `removeLast()`），近似 O(1)，如果是要在指定位置 `i` 插入和删除元素的话（`add(int index, E element)`，`remove(Object o)`） 时间复杂度近似为 O(n) ，因为需要先移动到指定位置再插入。 +4. **是否支持快速随机访问：** `LinkedList` 不支持高效的随机元素访问，而 `ArrayList` 支持。快速随机访问就是通过元素的序号快速获取元素对象(对应于`get(int index)`方法)。 +5. **内存空间占用：** ArrayList 的空 间浪费主要体现在在 list 列表的结尾会预留一定的容量空间，而 LinkedList 的空间花费则体现在它的每一个元素都需要消耗比 ArrayList 更多的空间（因为要存放直接后继和直接前驱以及数据）。 + +#### 补充内容:双向链表和双向循环链表 + +**双向链表：** 包含两个指针，一个 prev 指向前一个节点，一个 next 指向后一个节点。 + +> 另外推荐一篇把双向链表讲清楚的文章：[https://juejin.cn/post/6844903648154271757](https://juejin.cn/post/6844903648154271757) + +![双向链表](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/2019-6/双向链表.png) + +**双向循环链表：** 最后一个节点的 next 指向 head，而 head 的 prev 指向最后一个节点，构成一个环。 + +![双向循环链表](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/2019-6/双向循环链表.png) + +#### 补充内容:RandomAccess 接口 + +```java +public interface RandomAccess { +} +``` + +查看源码我们发现实际上 `RandomAccess` 接口中什么都没有定义。所以，在我看来 `RandomAccess` 接口不过是一个标识罢了。标识什么？ 标识实现这个接口的类具有随机访问功能。 + +在 `binarySearch（)` 方法中，它要判断传入的 list 是否 `RandomAccess` 的实例，如果是，调用`indexedBinarySearch()`方法，如果不是，那么调用`iteratorBinarySearch()`方法 + +```java + public static + int binarySearch(List> list, T key) { + if (list instanceof RandomAccess || list.size() arrayList = new ArrayList(); + arrayList.add(-1); + arrayList.add(3); + arrayList.add(3); + arrayList.add(-5); + arrayList.add(7); + arrayList.add(4); + arrayList.add(-9); + arrayList.add(-7); + System.out.println("原始数组:"); + System.out.println(arrayList); + // void reverse(List list)：反转 + Collections.reverse(arrayList); + System.out.println("Collections.reverse(arrayList):"); + System.out.println(arrayList); + + // void sort(List list),按自然排序的升序排序 + Collections.sort(arrayList); + System.out.println("Collections.sort(arrayList):"); + System.out.println(arrayList); + // 定制排序的用法 + Collections.sort(arrayList, new Comparator() { + + @Override + public int compare(Integer o1, Integer o2) { + return o2.compareTo(o1); + } + }); + System.out.println("定制排序后："); + System.out.println(arrayList); +``` + +Output: + +``` +原始数组: +[-1, 3, 3, -5, 7, 4, -9, -7] +Collections.reverse(arrayList): +[-7, -9, 4, 7, -5, 3, 3, -1] +Collections.sort(arrayList): +[-9, -7, -5, -1, 3, 3, 4, 7] +定制排序后： +[7, 4, 3, 3, -1, -5, -7, -9] +``` + +#### 重写 compareTo 方法实现按年龄来排序 + +```java +// person对象没有实现Comparable接口，所以必须实现，这样才不会出错，才可以使treemap中的数据按顺序排列 +// 前面一个例子的String类已经默认实现了Comparable接口，详细可以查看String类的API文档，另外其他 +// 像Integer类等都已经实现了Comparable接口，所以不需要另外实现了 +public class Person implements Comparable { + private String name; + private int age; + + public Person(String name, int age) { + super(); + this.name = name; + this.age = age; + } + + public String getName() { + return name; + } + + public void setName(String name) { + this.name = name; + } + + public int getAge() { + return age; + } + + public void setAge(int age) { + this.age = age; + } + + /** + * T重写compareTo方法实现按年龄来排序 + */ + @Override + public int compareTo(Person o) { + if (this.age > o.getAge()) { + return 1; + } + if (this.age < o.getAge()) { + return -1; + } + return 0; + } +} + +``` + +```java + public static void main(String[] args) { + TreeMap pdata = new TreeMap(); + pdata.put(new Person("张三", 30), "zhangsan"); + pdata.put(new Person("李四", 20), "lisi"); + pdata.put(new Person("王五", 10), "wangwu"); + pdata.put(new Person("小红", 5), "xiaohong"); + // 得到key的值的同时得到key所对应的值 + Set keys = pdata.keySet(); + for (Person key : keys) { + System.out.println(key.getAge() + "-" + key.getName()); + + } + } +``` + +Output： + +``` +5-小红 +10-王五 +20-李四 +30-张三 +``` + +### 无序性和不可重复性的含义是什么 + +1、什么是无序性？无序性不等于随机性 ，无序性是指存储的数据在底层数组中并非按照数组索引的顺序添加 ，而是根据数据的哈希值决定的。 + +2、什么是不可重复性？不可重复性是指添加的元素按照 equals()判断时 ，返回 false，需要同时重写 equals()方法和 HashCode()方法。 + +### 比较 HashSet、LinkedHashSet 和 TreeSet 三者的异同 + +- `HashSet`、`LinkedHashSet` 和 `TreeSet` 都是 `Set` 接口的实现类，都能保证元素唯一，并且都不是线程安全的。 +- `HashSet`、`LinkedHashSet` 和 `TreeSet` 的主要区别在于底层数据结构不同。`HashSet` 的底层数据结构是哈希表（基于 `HashMap` 实现）。`LinkedHashSet` 的底层数据结构是链表和哈希表，元素的插入和取出顺序满足 FIFO。`TreeSet` 底层数据结构是红黑树，元素是有序的，排序的方式有自然排序和定制排序。 +- 底层数据结构不同又导致这三者的应用场景不同。`HashSet` 用于不需要保证元素插入和取出顺序的场景，`LinkedHashSet` 用于保证元素的插入和取出顺序满足 FIFO 的场景，`TreeSet` 用于支持对元素自定义排序规则的场景。 + +## Collection 子接口之 Queue + +### Queue 与 Deque 的区别 + +`Queue` 是单端队列，只能从一端插入元素，另一端删除元素，实现上一般遵循 **先进先出（FIFO）** 规则。 + +`Queue` 扩展了 `Collection` 的接口，根据 **因为容量问题而导致操作失败后处理方式的不同** 可以分为两类方法: 一种在操作失败后会抛出异常，另一种则会返回特殊值。 + +| `Queue` 接口 | 抛出异常 | 返回特殊值 | +| ------------ | --------- | ---------- | +| 插入队尾 | add(E e) | offer(E e) | +| 删除队首 | remove() | poll() | +| 查询队首元素 | element() | peek() | + +`Deque` 是双端队列，在队列的两端均可以插入或删除元素。 + +`Deque` 扩展了 `Queue` 的接口, 增加了在队首和队尾进行插入和删除的方法，同样根据失败后处理方式的不同分为两类： + +| `Deque` 接口 | 抛出异常 | 返回特殊值 | +| ------------ | ------------- | --------------- | +| 插入队首 | addFirst(E e) | offerFirst(E e) | +| 插入队尾 | addLast(E e) | offerLast(E e) | +| 删除队首 | removeFirst() | pollFirst() | +| 删除队尾 | removeLast() | pollLast() | +| 查询队首元素 | getFirst() | peekFirst() | +| 查询队尾元素 | getLast() | peekLast() | + +事实上，`Deque` 还提供有 `push()` 和 `pop()` 等其他方法，可用于模拟栈。 + + +### ArrayDeque 与 LinkedList 的区别 + +`ArrayDeque` 和 `LinkedList` 都实现了 `Deque` 接口，两者都具有队列的功能，但两者有什么区别呢？ + +- `ArrayDeque` 是基于可变长的数组和双指针来实现，而 `LinkedList` 则通过链表来实现。 + +- `ArrayDeque` 不支持存储 `NULL` 数据，但 `LinkedList` 支持。 + +- `ArrayDeque` 是在 JDK1.6 才被引入的，而`LinkedList` 早在 JDK1.2 时就已经存在。 + +- `ArrayDeque` 插入时可能存在扩容过程, 不过均摊后的插入操作依然为 O(1)。虽然 `LinkedList` 不需要扩容，但是每次插入数据时均需要申请新的堆空间，均摊性能相比更慢。 + +从性能的角度上，选用 `ArrayDeque` 来实现队列要比 `LinkedList` 更好。此外，`ArrayDeque` 也可以用于实现栈。 + +### 说一说 PriorityQueue + +`PriorityQueue` 是在 JDK1.5 中被引入的, 其与 `Queue` 的区别在于元素出队顺序是与优先级相关的，即总是优先级最高的元素先出队。 + +这里列举其相关的一些要点： + +- `PriorityQueue` 利用了二叉堆的数据结构来实现的，底层使用可变长的数组来存储数据 +- `PriorityQueue` 通过堆元素的上浮和下沉，实现了在 O(logn) 的时间复杂度内插入元素和删除堆顶元素。 +- `PriorityQueue` 是非线程安全的，且不支持存储 `NULL` 和 `non-comparable` 的对象。 +- `PriorityQueue` 默认是小顶堆，但可以接收一个 `Comparator` 作为构造参数，从而来自定义元素优先级的先后。 + +`PriorityQueue` 在面试中可能更多的会出现在手撕算法的时候，典型例题包括堆排序、求第K大的数、带权图的遍历等，所以需要会熟练使用才行。 \ No newline at end of file diff --git a/docs/java/collection/java-collection-questions-02.md b/docs/java/collection/java-collection-questions-02.md new file mode 100644 index 0000000000000000000000000000000000000000..08fcc1a9bd9accd229ecc1c297d4d3edaa01d40d --- /dev/null +++ b/docs/java/collection/java-collection-questions-02.md @@ -0,0 +1,340 @@ +--- +title: Java集合常见知识点&面试题总结(下) +category: Java +tag: + - Java集合 +--- + +## Map 接口 + +### HashMap 和 Hashtable 的区别 + +1. **线程是否安全：** `HashMap` 是非线程安全的，`Hashtable` 是线程安全的,因为 `Hashtable` 内部的方法基本都经过`synchronized` 修饰。（如果你要保证线程安全的话就使用 `ConcurrentHashMap` 吧！）； +2. **效率：** 因为线程安全的问题，`HashMap` 要比 `Hashtable` 效率高一点。另外，`Hashtable` 基本被淘汰，不要在代码中使用它； +3. **对 Null key 和 Null value 的支持：** `HashMap` 可以存储 null 的 key 和 value，但 null 作为键只能有一个，null 作为值可以有多个；Hashtable 不允许有 null 键和 null 值，否则会抛出 `NullPointerException`。 +4. **初始容量大小和每次扩充容量大小的不同 ：** ① 创建时如果不指定容量初始值，`Hashtable` 默认的初始大小为 11，之后每次扩充，容量变为原来的 2n+1。`HashMap` 默认的初始化大小为 16。之后每次扩充，容量变为原来的 2 倍。② 创建时如果给定了容量初始值，那么 Hashtable 会直接使用你给定的大小，而 `HashMap` 会将其扩充为 2 的幂次方大小（`HashMap` 中的`tableSizeFor()`方法保证，下面给出了源代码）。也就是说 `HashMap` 总是使用 2 的幂作为哈希表的大小,后面会介绍到为什么是 2 的幂次方。 +5. **底层数据结构：** JDK1.8 以后的 `HashMap` 在解决哈希冲突时有了较大的变化，当链表长度大于阈值（默认为 8）（将链表转换成红黑树前会判断，如果当前数组的长度小于 64，那么会选择先进行数组扩容，而不是转换为红黑树）时，将链表转化为红黑树，以减少搜索时间。Hashtable 没有这样的机制。 + +**`HashMap` 中带有初始容量的构造函数：** + +```java + public HashMap(int initialCapacity, float loadFactor) { + if (initialCapacity < 0) + throw new IllegalArgumentException("Illegal initial capacity: " + + initialCapacity); + if (initialCapacity > MAXIMUM_CAPACITY) + initialCapacity = MAXIMUM_CAPACITY; + if (loadFactor <= 0 || Float.isNaN(loadFactor)) + throw new IllegalArgumentException("Illegal load factor: " + + loadFactor); + this.loadFactor = loadFactor; + this.threshold = tableSizeFor(initialCapacity); + } + public HashMap(int initialCapacity) { + this(initialCapacity, DEFAULT_LOAD_FACTOR); + } +``` + +下面这个方法保证了 `HashMap` 总是使用 2 的幂作为哈希表的大小。 + +```java + /** + * Returns a power of two size for the given target capacity. + */ + static final int tableSizeFor(int cap) { + int n = cap - 1; + n |= n >>> 1; + n |= n >>> 2; + n |= n >>> 4; + n |= n >>> 8; + n |= n >>> 16; + return (n < 0) ? 1 : (n >= MAXIMUM_CAPACITY) ? MAXIMUM_CAPACITY : n + 1; + } +``` + +### HashMap 和 HashSet 区别 + +如果你看过 `HashSet` 源码的话就应该知道：`HashSet` 底层就是基于 `HashMap` 实现的。（`HashSet` 的源码非常非常少，因为除了 `clone()`、`writeObject()`、`readObject()`是 `HashSet` 自己不得不实现之外，其他方法都是直接调用 `HashMap` 中的方法。 + +| `HashMap` | `HashSet` | +| :------------------------------------: | :----------------------------------------------------------: | +| 实现了 `Map` 接口 | 实现 `Set` 接口 | +| 存储键值对 | 仅存储对象 | +| 调用 `put()`向 map 中添加元素 | 调用 `add()`方法向 `Set` 中添加元素 | +| `HashMap` 使用键（Key）计算 `hashcode` | `HashSet` 使用成员对象来计算 `hashcode` 值，对于两个对象来说 `hashcode` 可能相同，所以`equals()`方法用来判断对象的相等性 | + +### HashMap 和 TreeMap 区别 + +`TreeMap` 和`HashMap` 都继承自`AbstractMap` ，但是需要注意的是`TreeMap`它还实现了`NavigableMap`接口和`SortedMap` 接口。 + +![](./images/TreeMap继承结构.png) + +实现 `NavigableMap` 接口让 `TreeMap` 有了对集合内元素的搜索的能力。 + +实现`SortedMap`接口让 `TreeMap` 有了对集合中的元素根据键排序的能力。默认是按 key 的升序排序，不过我们也可以指定排序的比较器。示例代码如下： + +```java +/** + * @author shuang.kou + * @createTime 2020年06月15日 17:02:00 + */ +public class Person { + private Integer age; + + public Person(Integer age) { + this.age = age; + } + + public Integer getAge() { + return age; + } + + + public static void main(String[] args) { + TreeMap treeMap = new TreeMap<>(new Comparator() { + @Override + public int compare(Person person1, Person person2) { + int num = person1.getAge() - person2.getAge(); + return Integer.compare(num, 0); + } + }); + treeMap.put(new Person(3), "person1"); + treeMap.put(new Person(18), "person2"); + treeMap.put(new Person(35), "person3"); + treeMap.put(new Person(16), "person4"); + treeMap.entrySet().stream().forEach(personStringEntry -> { + System.out.println(personStringEntry.getValue()); + }); + } +} +``` + +输出: + +``` +person1 +person4 +person2 +person3 +``` + +可以看出，`TreeMap` 中的元素已经是按照 `Person` 的 age 字段的升序来排列了。 + +上面，我们是通过传入匿名内部类的方式实现的，你可以将代码替换成 Lambda 表达式实现的方式： + +```java +TreeMap treeMap = new TreeMap<>((person1, person2) -> { + int num = person1.getAge() - person2.getAge(); + return Integer.compare(num, 0); +}); +``` + +**综上，相比于`HashMap`来说 `TreeMap` 主要多了对集合中的元素根据键排序的能力以及对集合内元素的搜索的能力。** + +### HashSet 如何检查重复 + +以下内容摘自我的 Java 启蒙书《Head first java》第二版： + +当你把对象加入`HashSet`时，`HashSet` 会先计算对象的`hashcode`值来判断对象加入的位置，同时也会与其他加入的对象的 `hashcode` 值作比较，如果没有相符的 `hashcode`，`HashSet` 会假设对象没有重复出现。但是如果发现有相同 `hashcode` 值的对象，这时会调用`equals()`方法来检查 `hashcode` 相等的对象是否真的相同。如果两者相同，`HashSet` 就不会让加入操作成功。 + +在openjdk8中，`HashSet`的`add()`方法只是简单的调用了`HashMap`的`put()`方法，并且判断了一下返回值以确保是否有重复元素。直接看一下`HashSet`中的源码： +```java +// Returns: true if this set did not already contain the specified element +// 返回值：当set中没有包含add的元素时返回真 +public boolean add(E e) { + return map.put(e, PRESENT)==null; +} +``` + +而在`HashMap`的`putVal()`方法中也能看到如下说明： +```java +// Returns : previous value, or null if none +// 返回值：如果插入位置没有元素返回null，否则返回上一个元素 +final V putVal(int hash, K key, V value, boolean onlyIfAbsent, + boolean evict) { +... +} +``` + +也就是说，在openjdk8中，实际上无论`HashSet`中是否已经存在了某元素，`HashSet`都会直接插入，只是会在`add()`方法的返回值处告诉我们插入前是否存在相同元素。 + +**`hashCode()`与 `equals()` 的相关规定：** + +1. 如果两个对象相等，则 `hashcode` 一定也是相同的 +2. 两个对象相等,对两个 `equals()` 方法返回 true +3. 两个对象有相同的 `hashcode` 值，它们也不一定是相等的 +4. 综上，`equals()` 方法被覆盖过，则 `hashCode()` 方法也必须被覆盖 +5. `hashCode()`的默认行为是对堆上的对象产生独特值。如果没有重写 `hashCode()`，则该 class 的两个对象无论如何都不会相等（即使这两个对象指向相同的数据）。 + +**==与 equals 的区别** + +对于基本类型来说，== 比较的是值是否相等； + +对于引用类型来说，== 比较的是两个引用是否指向同一个对象地址（两者在内存中存放的地址（堆内存地址）是否指向同一个地方）； + +对于引用类型（包括包装类型）来说，equals 如果没有被重写，对比它们的地址是否相等；如果 equals()方法被重写（例如 String），则比较的是地址里的内容。 + +### HashMap 的底层实现 + +#### JDK1.8 之前 + +JDK1.8 之前 `HashMap` 底层是 **数组和链表** 结合在一起使用也就是 **链表散列**。**HashMap 通过 key 的 hashCode 经过扰动函数处理过后得到 hash 值，然后通过 (n - 1) & hash 判断当前元素存放的位置（这里的 n 指的是数组的长度），如果当前位置存在元素的话，就判断该元素与要存入的元素的 hash 值以及 key 是否相同，如果相同的话，直接覆盖，不相同就通过拉链法解决冲突。** + +**所谓扰动函数指的就是 HashMap 的 hash 方法。使用 hash 方法也就是扰动函数是为了防止一些实现比较差的 hashCode() 方法 换句话说使用扰动函数之后可以减少碰撞。** + +**JDK 1.8 HashMap 的 hash 方法源码:** + +JDK 1.8 的 hash 方法 相比于 JDK 1.7 hash 方法更加简化，但是原理不变。 + +```java + static final int hash(Object key) { + int h; + // key.hashCode()：返回散列值也就是hashcode + // ^ ：按位异或 + // >>>:无符号右移，忽略符号位，空位都以0补齐 + return (key == null) ? 0 : (h = key.hashCode()) ^ (h >>> 16); + } +``` + +对比一下 JDK1.7 的 HashMap 的 hash 方法源码. + +```java +static int hash(int h) { + // This function ensures that hashCodes that differ only by + // constant multiples at each bit position have a bounded + // number of collisions (approximately 8 at default load factor). + + h ^= (h >>> 20) ^ (h >>> 12); + return h ^ (h >>> 7) ^ (h >>> 4); +} +``` + +相比于 JDK1.8 的 hash 方法 ，JDK 1.7 的 hash 方法的性能会稍差一点点，因为毕竟扰动了 4 次。 + +所谓 **“拉链法”** 就是：将链表和数组相结合。也就是说创建一个链表数组，数组中每一格就是一个链表。若遇到哈希冲突，则将冲突的值加到链表中即可。 + +![jdk1.8之前的内部结构-HashMap](./images/jdk1.8之前的内部结构-HashMap.png) + +#### JDK1.8 之后 + +相比于之前的版本， JDK1.8 之后在解决哈希冲突时有了较大的变化，当链表长度大于阈值（默认为 8）（将链表转换成红黑树前会判断，如果当前数组的长度小于 64，那么会选择先进行数组扩容，而不是转换为红黑树）时，将链表转化为红黑树，以减少搜索时间。 + +![jdk1.8之后的内部结构-HashMap](./images/jdk1.8之后的内部结构-HashMap.png) + +> TreeMap、TreeSet 以及 JDK1.8 之后的 HashMap 底层都用到了红黑树。红黑树就是为了解决二叉查找树的缺陷，因为二叉查找树在某些情况下会退化成一个线性结构。 + +### HashMap 的长度为什么是 2 的幂次方 + +为了能让 HashMap 存取高效，尽量较少碰撞，也就是要尽量把数据分配均匀。我们上面也讲到了过了，Hash 值的范围值-2147483648 到 2147483647，前后加起来大概 40 亿的映射空间，只要哈希函数映射得比较均匀松散，一般应用是很难出现碰撞的。但问题是一个 40 亿长度的数组，内存是放不下的。所以这个散列值是不能直接拿来用的。用之前还要先做对数组的长度取模运算，得到的余数才能用来要存放的位置也就是对应的数组下标。这个数组下标的计算方法是“ `(n - 1) & hash`”。（n 代表数组长度）。这也就解释了 HashMap 的长度为什么是 2 的幂次方。 + +**这个算法应该如何设计呢？** + +我们首先可能会想到采用%取余的操作来实现。但是，重点来了：**“取余(%)操作中如果除数是 2 的幂次则等价于与其除数减一的与(&)操作（也就是说 hash%length==hash&(length-1)的前提是 length 是 2 的 n 次方；）。”** 并且 **采用二进制位操作 &，相对于%能够提高运算效率，这就解释了 HashMap 的长度为什么是 2 的幂次方。** + +### HashMap 多线程操作导致死循环问题 + +主要原因在于并发下的 Rehash 会造成元素之间会形成一个循环链表。不过，jdk 1.8 后解决了这个问题，但是还是不建议在多线程下使用 HashMap,因为多线程下使用 HashMap 还是会存在其他问题比如数据丢失。并发环境下推荐使用 ConcurrentHashMap 。 + +详情请查看： + +### HashMap 有哪几种常见的遍历方式? + +[HashMap 的 7 种遍历方式与性能分析！](https://mp.weixin.qq.com/s/zQBN3UvJDhRTKP6SzcZFKw) + +### ConcurrentHashMap 和 Hashtable 的区别 + +`ConcurrentHashMap` 和 `Hashtable` 的区别主要体现在实现线程安全的方式上不同。 + +- **底层数据结构：** JDK1.7 的 `ConcurrentHashMap` 底层采用 **分段的数组+链表** 实现，JDK1.8 采用的数据结构跟 `HashMap1.8` 的结构一样，数组+链表/红黑二叉树。`Hashtable` 和 JDK1.8 之前的 `HashMap` 的底层数据结构类似都是采用 **数组+链表** 的形式，数组是 HashMap 的主体，链表则是主要为了解决哈希冲突而存在的； +- **实现线程安全的方式（重要）：** ① **在 JDK1.7 的时候，`ConcurrentHashMap`（分段锁）** 对整个桶数组进行了分割分段(`Segment`)，每一把锁只锁容器其中一部分数据，多线程访问容器里不同数据段的数据，就不会存在锁竞争，提高并发访问率。 **到了 JDK1.8 的时候已经摒弃了 `Segment` 的概念，而是直接用 `Node` 数组+链表+红黑树的数据结构来实现，并发控制使用 `synchronized` 和 CAS 来操作。（JDK1.6 以后 对 `synchronized` 锁做了很多优化）** 整个看起来就像是优化过且线程安全的 `HashMap`，虽然在 JDK1.8 中还能看到 `Segment` 的数据结构，但是已经简化了属性，只是为了兼容旧版本；② **`Hashtable`(同一把锁)** :使用 `synchronized` 来保证线程安全，效率非常低下。当一个线程访问同步方法时，其他线程也访问同步方法，可能会进入阻塞或轮询状态，如使用 put 添加元素，另一个线程不能使用 put 添加元素，也不能使用 get，竞争会越来越激烈效率越低。 + +**两者的对比图：** + +**Hashtable:** + +![Hashtable全表锁](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/2019-6/HashTable全表锁.png) + +

https://www.cnblogs.com/chengxiao/p/6842045.html>

+ +**JDK1.7 的 ConcurrentHashMap：** + +![JDK1.7的ConcurrentHashMap](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/2019-6/ConcurrentHashMap分段锁.jpg) + +

https://www.cnblogs.com/chengxiao/p/6842045.html>

+ +**JDK1.8 的 ConcurrentHashMap：** + +![Java8 ConcurrentHashMap 存储结构（图片来自 javadoop）](./images/java8_concurrenthashmap.png) + +JDK1.8 的 `ConcurrentHashMap` 不再是 **Segment 数组 + HashEntry 数组 + 链表**，而是 **Node 数组 + 链表 / 红黑树**。不过，Node 只能用于链表的情况，红黑树的情况需要使用 **`TreeNode`**。当冲突链表达到一定长度时，链表会转换成红黑树。 + +### ConcurrentHashMap 线程安全的具体实现方式/底层具体实现 + +#### JDK1.7（上面有示意图） + +首先将数据分为一段一段的存储，然后给每一段数据配一把锁，当一个线程占用锁访问其中一个段数据时，其他段的数据也能被其他线程访问。 + +**`ConcurrentHashMap` 是由 `Segment` 数组结构和 `HashEntry` 数组结构组成**。 + +Segment 实现了 `ReentrantLock`,所以 `Segment` 是一种可重入锁，扮演锁的角色。`HashEntry` 用于存储键值对数据。 + +```java +static class Segment extends ReentrantLock implements Serializable { +} +``` + +一个 `ConcurrentHashMap` 里包含一个 `Segment` 数组。`Segment` 的结构和 `HashMap` 类似，是一种数组和链表结构，一个 `Segment` 包含一个 `HashEntry` 数组，每个 `HashEntry` 是一个链表结构的元素，每个 `Segment` 守护着一个 `HashEntry` 数组里的元素，当对 `HashEntry` 数组的数据进行修改时，必须首先获得对应的 `Segment` 的锁。 + +#### JDK1.8 （上面有示意图） + +`ConcurrentHashMap` 取消了 `Segment` 分段锁，采用 CAS 和 `synchronized` 来保证并发安全。数据结构跟 HashMap1.8 的结构类似，数组+链表/红黑二叉树。Java 8 在链表长度超过一定阈值（8）时将链表（寻址时间复杂度为 O(N)）转换为红黑树（寻址时间复杂度为 O(log(N))） + +`synchronized` 只锁定当前链表或红黑二叉树的首节点，这样只要 hash 不冲突，就不会产生并发，效率又提升 N 倍。 + +## Collections 工具类 + +Collections 工具类常用方法: + +1. 排序 +2. 查找,替换操作 +3. 同步控制(不推荐，需要线程安全的集合类型时请考虑使用 JUC 包下的并发集合) + +### 排序操作 + +```java +void reverse(List list)//反转 +void shuffle(List list)//随机排序 +void sort(List list)//按自然排序的升序排序 +void sort(List list, Comparator c)//定制排序，由Comparator控制排序逻辑 +void swap(List list, int i , int j)//交换两个索引位置的元素 +void rotate(List list, int distance)//旋转。当distance为正数时，将list后distance个元素整体移到前面。当distance为负数时，将 list的前distance个元素整体移到后面 +``` + +### 查找,替换操作 + +```java +int binarySearch(List list, Object key)//对List进行二分查找，返回索引，注意List必须是有序的 +int max(Collection coll)//根据元素的自然顺序，返回最大的元素。 类比int min(Collection coll) +int max(Collection coll, Comparator c)//根据定制排序，返回最大元素，排序规则由Comparatator类控制。类比int min(Collection coll, Comparator c) +void fill(List list, Object obj)//用指定的元素代替指定list中的所有元素 +int frequency(Collection c, Object o)//统计元素出现次数 +int indexOfSubList(List list, List target)//统计target在list中第一次出现的索引，找不到则返回-1，类比int lastIndexOfSubList(List source, list target) +boolean replaceAll(List list, Object oldVal, Object newVal)//用新元素替换旧元素 +``` + +### 同步控制 + +`Collections` 提供了多个`synchronizedXxx()`方法·，该方法可以将指定集合包装成线程同步的集合，从而解决多线程并发访问集合时的线程安全问题。 + +我们知道 `HashSet`，`TreeSet`，`ArrayList`,`LinkedList`,`HashMap`,`TreeMap` 都是线程不安全的。`Collections` 提供了多个静态方法可以把他们包装成线程同步的集合。 + +**最好不要用下面这些方法，效率非常低，需要线程安全的集合类型时请考虑使用 JUC 包下的并发集合。** + +方法如下： + +```java +synchronizedCollection(Collection c) //返回指定 collection 支持的同步（线程安全的）collection。 +synchronizedList(List list)//返回指定列表支持的同步（线程安全的）List。 +synchronizedMap(Map m) //返回由指定映射支持的同步（线程安全的）Map。 +synchronizedSet(Set s) //返回指定 set 支持的同步（线程安全的）set。 +``` diff --git a/docs/java/concurrent/aqs.md b/docs/java/concurrent/aqs.md new file mode 100644 index 0000000000000000000000000000000000000000..2a2f651cae3a2c17002a22635d394d2023e6fa86 --- /dev/null +++ b/docs/java/concurrent/aqs.md @@ -0,0 +1,706 @@ +--- +title: AQS 原理以及 AQS 同步组件总结 +category: Java +tag: + - Java并发 +--- + + +开始之前，先来看几道常见的面试题！建议你带着这些问题来看这篇文章： + +- 何为 AQS？AQS 原理了解吗？ +- `CountDownLatch` 和 `CyclicBarrier` 了解吗？两者的区别是什么？ +- 用过 `Semaphore` 吗？应用场景了解吗？ +- ...... + +## AQS 简单介绍 + +AQS 的全称为 `AbstractQueuedSynchronizer` ，翻译过来的意思就是抽象队列同步器。这个类在 `java.util.concurrent.locks` 包下面。 + +![enter image description here](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/Java%20%E7%A8%8B%E5%BA%8F%E5%91%98%E5%BF%85%E5%A4%87%EF%BC%9A%E5%B9%B6%E5%8F%91%E7%9F%A5%E8%AF%86%E7%B3%BB%E7%BB%9F%E6%80%BB%E7%BB%93/AQS.png) + +AQS 就是一个抽象类，主要用来构建锁和同步器。 + +```java +public abstract class AbstractQueuedSynchronizer extends AbstractOwnableSynchronizer implements java.io.Serializable { +} +``` + +AQS 为构建锁和同步器提供了一些通用功能的是实现，因此，使用 AQS 能简单且高效地构造出应用广泛的大量的同步器，比如我们提到的 `ReentrantLock`，`Semaphore`，其他的诸如 `ReentrantReadWriteLock`，`SynchronousQueue`，`FutureTask`(jdk1.7) 等等皆是基于 AQS 的。 + +## AQS 原理 + +> 在面试中被问到并发知识的时候，大多都会被问到“请你说一下自己对于 AQS 原理的理解”。下面给大家一个示例供大家参考，面试不是背题，大家一定要加入自己的思想，即使加入不了自己的思想也要保证自己能够通俗的讲出来而不是背出来。 + +下面大部分内容其实在 AQS 类注释上已经给出了，不过是英语看着比较吃力一点，感兴趣的话可以看看源码。 + +### AQS 原理概览 + +AQS 核心思想是，如果被请求的共享资源空闲，则将当前请求资源的线程设置为有效的工作线程，并且将共享资源设置为锁定状态。如果被请求的共享资源被占用，那么就需要一套线程阻塞等待以及被唤醒时锁分配的机制，这个机制 AQS 是用 **CLH 队列锁**实现的，即将暂时获取不到锁的线程加入到队列中。 + +> CLH(Craig,Landin,and Hagersten)队列是一个虚拟的双向队列（虚拟的双向队列即不存在队列实例，仅存在结点之间的关联关系）。AQS 是将每条请求共享资源的线程封装成一个 CLH 锁队列的一个结点（Node）来实现锁的分配。 + +看个 AQS(`AbstractQueuedSynchronizer`)原理图： + +![enter image description here](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/Java%20%E7%A8%8B%E5%BA%8F%E5%91%98%E5%BF%85%E5%A4%87%EF%BC%9A%E5%B9%B6%E5%8F%91%E7%9F%A5%E8%AF%86%E7%B3%BB%E7%BB%9F%E6%80%BB%E7%BB%93/CLH.png) + +AQS 使用一个 int 成员变量来表示同步状态，通过内置的 FIFO 队列来完成获取资源线程的排队工作。AQS 使用 CAS 对该同步状态进行原子操作实现对其值的修改。 + +```java +private volatile int state;//共享变量，使用volatile修饰保证线程可见性 +``` + +状态信息通过 `protected` 类型的`getState()`，`setState()`，`compareAndSetState()` 进行操作 + +```java +//返回同步状态的当前值 +protected final int getState() { + return state; +} + // 设置同步状态的值 +protected final void setState(int newState) { + state = newState; +} +//原子地（CAS操作）将同步状态值设置为给定值update如果当前同步状态的值等于expect（期望值） +protected final boolean compareAndSetState(int expect, int update) { + return unsafe.compareAndSwapInt(this, stateOffset, expect, update); +} +``` + +### AQS 对资源的共享方式 + +AQS 定义两种资源共享方式 + +**1)Exclusive**（独占） + +只有一个线程能执行，如 `ReentrantLock`。又可分为公平锁和非公平锁，`ReentrantLock` 同时支持两种锁，下面以 `ReentrantLock` 对这两种锁的定义做介绍： + +- **公平锁** ：按照线程在队列中的排队顺序，先到者先拿到锁 +- **非公平锁** ：当线程要获取锁时，先通过两次 CAS 操作去抢锁，如果没抢到，当前线程再加入到队列中等待唤醒。 + +> 说明：下面这部分关于 `ReentrantLock` 源代码内容节选自：https://www.javadoop.com/post/AbstractQueuedSynchronizer-2 ，这是一篇很不错文章，推荐阅读。 + +**下面来看 `ReentrantLock` 中相关的源代码：** + +`ReentrantLock` 默认采用非公平锁，因为考虑获得更好的性能，通过 `boolean` 来决定是否用公平锁（传入 true 用公平锁）。 + +```java +/** Synchronizer providing all implementation mechanics */ +private final Sync sync; +public ReentrantLock() { + // 默认非公平锁 + sync = new NonfairSync(); +} +public ReentrantLock(boolean fair) { + sync = fair ? new FairSync() : new NonfairSync(); +} +``` + +`ReentrantLock` 中公平锁的 `lock` 方法 + +```java +static final class FairSync extends Sync { + final void lock() { + acquire(1); + } + // AbstractQueuedSynchronizer.acquire(int arg) + public final void acquire(int arg) { + if (!tryAcquire(arg) && + acquireQueued(addWaiter(Node.EXCLUSIVE), arg)) + selfInterrupt(); + } + protected final boolean tryAcquire(int acquires) { + final Thread current = Thread.currentThread(); + int c = getState(); + if (c == 0) { + // 1. 和非公平锁相比，这里多了一个判断：是否有线程在等待 + if (!hasQueuedPredecessors() && + compareAndSetState(0, acquires)) { + setExclusiveOwnerThread(current); + return true; + } + } + else if (current == getExclusiveOwnerThread()) { + int nextc = c + acquires; + if (nextc < 0) + throw new Error("Maximum lock count exceeded"); + setState(nextc); + return true; + } + return false; + } +} +``` + +非公平锁的 `lock` 方法： + +```java +static final class NonfairSync extends Sync { + final void lock() { + // 2. 和公平锁相比，这里会直接先进行一次CAS，成功就返回了 + if (compareAndSetState(0, 1)) + setExclusiveOwnerThread(Thread.currentThread()); + else + acquire(1); + } + // AbstractQueuedSynchronizer.acquire(int arg) + public final void acquire(int arg) { + if (!tryAcquire(arg) && + acquireQueued(addWaiter(Node.EXCLUSIVE), arg)) + selfInterrupt(); + } + protected final boolean tryAcquire(int acquires) { + return nonfairTryAcquire(acquires); + } +} +/** + * Performs non-fair tryLock. tryAcquire is implemented in + * subclasses, but both need nonfair try for trylock method. + */ +final boolean nonfairTryAcquire(int acquires) { + final Thread current = Thread.currentThread(); + int c = getState(); + if (c == 0) { + // 这里没有对阻塞队列进行判断 + if (compareAndSetState(0, acquires)) { + setExclusiveOwnerThread(current); + return true; + } + } + else if (current == getExclusiveOwnerThread()) { + int nextc = c + acquires; + if (nextc < 0) // overflow + throw new Error("Maximum lock count exceeded"); + setState(nextc); + return true; + } + return false; +} +``` + +总结：公平锁和非公平锁只有两处不同： + +1. 非公平锁在调用 lock 后，首先就会调用 CAS 进行一次抢锁，如果这个时候恰巧锁没有被占用，那么直接就获取到锁返回了。 +2. 非公平锁在 CAS 失败后，和公平锁一样都会进入到 `tryAcquire` 方法，在 `tryAcquire` 方法中，如果发现锁这个时候被释放了（state == 0），非公平锁会直接 CAS 抢锁，但是公平锁会判断等待队列是否有线程处于等待状态，如果有则不去抢锁，乖乖排到后面。 + +公平锁和非公平锁就这两点区别，如果这两次 CAS 都不成功，那么后面非公平锁和公平锁是一样的，都要进入到阻塞队列等待唤醒。 + +相对来说，非公平锁会有更好的性能，因为它的吞吐量比较大。当然，非公平锁让获取锁的时间变得更加不确定，可能会导致在阻塞队列中的线程长期处于饥饿状态。 + +**2)Share**（共享） + +多个线程可同时执行，如 `Semaphore/CountDownLatch`。`Semaphore`、`CountDownLatCh`、 `CyclicBarrier`、`ReadWriteLock` 我们都会在后面讲到。 + +`ReentrantReadWriteLock` 可以看成是组合式，因为 `ReentrantReadWriteLock` 也就是读写锁允许多个线程同时对某一资源进行读。 + +不同的自定义同步器争用共享资源的方式也不同。自定义同步器在实现时只需要实现共享资源 state 的获取与释放方式即可，至于具体线程等待队列的维护（如获取资源失败入队/唤醒出队等），AQS 已经在上层已经帮我们实现好了。 + +### AQS 底层使用了模板方法模式 + +同步器的设计是基于模板方法模式的，如果需要自定义同步器一般的方式是这样（模板方法模式很经典的一个应用）： + +1. 使用者继承 `AbstractQueuedSynchronizer` 并重写指定的方法。（这些重写方法很简单，无非是对于共享资源 state 的获取和释放） +2. 将 AQS 组合在自定义同步组件的实现中，并调用其模板方法，而这些模板方法会调用使用者重写的方法。 + +这和我们以往通过实现接口的方式有很大区别，这是模板方法模式很经典的一个运用。 + +**AQS 使用了模板方法模式，自定义同步器时需要重写下面几个 AQS 提供的钩子方法：** + +```java +protected boolean tryAcquire(int)//独占方式。尝试获取资源，成功则返回true，失败则返回false。 +protected boolean tryRelease(int)//独占方式。尝试释放资源，成功则返回true，失败则返回false。 +protected boolean tryAcquireShared(int)//共享方式。尝试获取资源。负数表示失败；0表示成功，但没有剩余可用资源；正数表示成功，且有剩余资源。 +protected boolean tryReleaseShared(int)//共享方式。尝试释放资源，成功则返回true，失败则返回false。 +protected boolean isHeldExclusively()//该线程是否正在独占资源。只有用到condition才需要去实现它。 +``` + +**什么是钩子方法呢？** 钩子方法是一种被声明在抽象类中的方法，一般使用 `protected` 关键字修饰，它可以是空方法（由子类实现），也可以是默认实现的方法。模板设计模式通过钩子方法控制固定步骤的实现。 + +篇幅问题，这里就不详细介绍模板方法模式了，不太了解的小伙伴可以看看这篇文章：[用Java8 改造后的模板方法模式真的是 yyds!](https://mp.weixin.qq.com/s/zpScSCktFpnSWHWIQem2jg)。 + +除了上面提到的钩子方法之外，AQS 类中的其他方法都是 `final` ，所以无法被其他类重写。 + +以 `ReentrantLock` 为例，state 初始化为 0，表示未锁定状态。A 线程 `lock()` 时，会调用 `tryAcquire()` 独占该锁并将 `state+1` 。此后，其他线程再 `tryAcquire()` 时就会失败，直到 A 线程 `unlock()` 到 `state=`0（即释放锁）为止，其它线程才有机会获取该锁。当然，释放锁之前，A 线程自己是可以重复获取此锁的（state 会累加），这就是可重入的概念。但要注意，获取多少次就要释放多少次，这样才能保证 state 是能回到零态的。 + +再以 `CountDownLatch` 以例，任务分为 N 个子线程去执行，state 也初始化为 N（注意 N 要与线程个数一致）。这 N 个子线程是并行执行的，每个子线程执行完后` countDown()` 一次，state 会 CAS(Compare and Swap) 减 1。等到所有子线程都执行完后(即 `state=0` )，会 `unpark()` 主调用线程，然后主调用线程就会从 `await()` 函数返回，继续后余动作。 + +一般来说，自定义同步器要么是独占方法，要么是共享方式，他们也只需实现`tryAcquire-tryRelease`、`tryAcquireShared-tryReleaseShared`中的一种即可。但 AQS 也支持自定义同步器同时实现独占和共享两种方式，如`ReentrantReadWriteLock`。 + +推荐两篇 AQS 原理和相关源码分析的文章： + +- [Java并发之AQS详解](https://www.cnblogs.com/waterystone/p/4920797.html) +- [Java并发包基石-AQS详解](https://www.cnblogs.com/chengxiao/p/7141160.html) + +## Semaphore(信号量) + +`synchronized` 和 `ReentrantLock` 都是一次只允许一个线程访问某个资源，`Semaphore`(信号量)可以指定多个线程同时访问某个资源。 + +示例代码如下： + +```java +/** + * + * @author Snailclimb + * @date 2018年9月30日 + * @Description: 需要一次性拿一个许可的情况 + */ +public class SemaphoreExample1 { + // 请求的数量 + private static final int threadCount = 550; + + public static void main(String[] args) throws InterruptedException { + // 创建一个具有固定线程数量的线程池对象（如果这里线程池的线程数量给太少的话你会发现执行的很慢） + ExecutorService threadPool = Executors.newFixedThreadPool(300); + // 一次只能允许执行的线程数量。 + final Semaphore semaphore = new Semaphore(20); + + for (int i = 0; i < threadCount; i++) { + final int threadnum = i; + threadPool.execute(() -> {// Lambda 表达式的运用 + try { + semaphore.acquire();// 获取一个许可，所以可运行线程数量为20/1=20 + test(threadnum); + semaphore.release();// 释放一个许可 + } catch (InterruptedException e) { + // TODO Auto-generated catch block + e.printStackTrace(); + } + + }); + } + threadPool.shutdown(); + System.out.println("finish"); + } + + public static void test(int threadnum) throws InterruptedException { + Thread.sleep(1000);// 模拟请求的耗时操作 + System.out.println("threadnum:" + threadnum); + Thread.sleep(1000);// 模拟请求的耗时操作 + } +} +``` + +执行 `acquire()` 方法阻塞，直到有一个许可证可以获得然后拿走一个许可证；每个 `release` 方法增加一个许可证，这可能会释放一个阻塞的 `acquire()` 方法。然而，其实并没有实际的许可证这个对象，`Semaphore` 只是维持了一个可获得许可证的数量。 `Semaphore` 经常用于限制获取某种资源的线程数量。 + +当然一次也可以一次拿取和释放多个许可，不过一般没有必要这样做： + +```java +semaphore.acquire(5);// 获取5个许可，所以可运行线程数量为20/5=4 +test(threadnum); +semaphore.release(5);// 释放5个许可 +``` + +除了 `acquire()` 方法之外，另一个比较常用的与之对应的方法是 `tryAcquire()` 方法，该方法如果获取不到许可就立即返回 false。 + +`Semaphore` 有两种模式，公平模式和非公平模式。 + +- **公平模式：** 调用 `acquire()` 方法的顺序就是获取许可证的顺序，遵循 FIFO； +- **非公平模式：** 抢占式的。 + +`Semaphore` 对应的两个构造方法如下： + +```java + public Semaphore(int permits) { + sync = new NonfairSync(permits); + } + + public Semaphore(int permits, boolean fair) { + sync = fair ? new FairSync(permits) : new NonfairSync(permits); + } +``` + +**这两个构造方法，都必须提供许可的数量，第二个构造方法可以指定是公平模式还是非公平模式，默认非公平模式。** + +[issue645 补充内容](https://github.com/Snailclimb/JavaGuide/issues/645) ：`Semaphore` 与 `CountDownLatch` 一样，也是共享锁的一种实现。它默认构造 AQS 的 state 为 `permits`。当执行任务的线程数量超出 `permits`，那么多余的线程将会被放入阻塞队列 Park,并自旋判断 state 是否大于 0。只有当 state 大于 0 的时候，阻塞的线程才能继续执行,此时先前执行任务的线程继续执行 `release()` 方法，`release()` 方法使得 state 的变量会加 1，那么自旋的线程便会判断成功。 +如此，每次只有最多不超过 `permits` 数量的线程能自旋成功，便限制了执行任务线程的数量。 + +## CountDownLatch （倒计时器） + +`CountDownLatch` 允许 `count` 个线程阻塞在一个地方，直至所有线程的任务都执行完毕。 + +`CountDownLatch` 是共享锁的一种实现,它默认构造 AQS 的 `state` 值为 `count`。当线程使用 `countDown()` 方法时,其实使用了`tryReleaseShared`方法以 CAS 的操作来减少 `state`,直至 `state` 为 0 。当调用 `await()` 方法的时候，如果 `state` 不为 0，那就证明任务还没有执行完毕，`await()` 方法就会一直阻塞，也就是说 `await()` 方法之后的语句不会被执行。然后，`CountDownLatch` 会自旋 CAS 判断 `state == 0`，如果 `state == 0` 的话，就会释放所有等待的线程，`await()` 方法之后的语句得到执行。 + +### CountDownLatch 的两种典型用法 + +**1、某一线程在开始运行前等待 n 个线程执行完毕。** + +将 `CountDownLatch` 的计数器初始化为 n （`new CountDownLatch(n)`），每当一个任务线程执行完毕，就将计数器减 1 （`countdownlatch.countDown()`），当计数器的值变为 0 时，在 `CountDownLatch 上 await()` 的线程就会被唤醒。一个典型应用场景就是启动一个服务时，主线程需要等待多个组件加载完毕，之后再继续执行。 + +**2、实现多个线程开始执行任务的最大并行性。** + +注意是并行性，不是并发，强调的是多个线程在某一时刻同时开始执行。类似于赛跑，将多个线程放到起点，等待发令枪响，然后同时开跑。做法是初始化一个共享的 `CountDownLatch` 对象，将其计数器初始化为 1 （`new CountDownLatch(1)`），多个线程在开始执行任务前首先 `coundownlatch.await()`，当主线程调用 `countDown()` 时，计数器变为 0，多个线程同时被唤醒。 + +### CountDownLatch 的使用示例 + +```java +/** + * + * @author SnailClimb + * @date 2018年10月1日 + * @Description: CountDownLatch 使用方法示例 + */ +public class CountDownLatchExample1 { + // 请求的数量 + private static final int threadCount = 550; + + public static void main(String[] args) throws InterruptedException { + // 创建一个具有固定线程数量的线程池对象（如果这里线程池的线程数量给太少的话你会发现执行的很慢） + ExecutorService threadPool = Executors.newFixedThreadPool(300); + final CountDownLatch countDownLatch = new CountDownLatch(threadCount); + for (int i = 0; i < threadCount; i++) { + final int threadnum = i; + threadPool.execute(() -> {// Lambda 表达式的运用 + try { + test(threadnum); + } catch (InterruptedException e) { + // TODO Auto-generated catch block + e.printStackTrace(); + } finally { + countDownLatch.countDown();// 表示一个请求已经被完成 + } + + }); + } + countDownLatch.await(); + threadPool.shutdown(); + System.out.println("finish"); + } + + public static void test(int threadnum) throws InterruptedException { + Thread.sleep(1000);// 模拟请求的耗时操作 + System.out.println("threadnum:" + threadnum); + Thread.sleep(1000);// 模拟请求的耗时操作 + } +} + +``` + +上面的代码中，我们定义了请求的数量为 550，当这 550 个请求被处理完成之后，才会执行`System.out.println("finish");`。 + +与 `CountDownLatch` 的第一次交互是主线程等待其他线程。主线程必须在启动其他线程后立即调用 `CountDownLatch.await()` 方法。这样主线程的操作就会在这个方法上阻塞，直到其他线程完成各自的任务。 + +其他 N 个线程必须引用闭锁对象，因为他们需要通知 `CountDownLatch` 对象，他们已经完成了各自的任务。这种通知机制是通过 `CountDownLatch.countDown()`方法来完成的；每调用一次这个方法，在构造函数中初始化的 count 值就减 1。所以当 N 个线程都调 用了这个方法，count 的值等于 0，然后主线程就能通过 `await()`方法，恢复执行自己的任务。 + +再插一嘴：`CountDownLatch` 的 `await()` 方法使用不当很容易产生死锁，比如我们上面代码中的 for 循环改为： + +```java +for (int i = 0; i < threadCount-1; i++) { +....... +} +``` + +这样就导致 `count` 的值没办法等于 0，然后就会导致一直等待。 + +### CountDownLatch 的不足 + +`CountDownLatch` 是一次性的，计数器的值只能在构造方法中初始化一次，之后没有任何机制再次对其设置值，当 `CountDownLatch` 使用完毕后，它不能再次被使用。 + +### CountDownLatch 相常见面试题 + +- `CountDownLatch` 怎么用？应用场景是什么？ +- `CountDownLatch` 和 `CyclicBarrier` 的不同之处？ +- `CountDownLatch` 类中主要的方法？ + +## CyclicBarrier(循环栅栏) + +`CyclicBarrier` 和 `CountDownLatch` 非常类似，它也可以实现线程间的技术等待，但是它的功能比 `CountDownLatch` 更加复杂和强大。主要应用场景和 `CountDownLatch` 类似。 + +> `CountDownLatch` 的实现是基于 AQS 的，而 `CycliBarrier` 是基于 `ReentrantLock`(`ReentrantLock` 也属于 AQS 同步器)和 `Condition` 的。 + +`CyclicBarrier` 的字面意思是可循环使用（Cyclic）的屏障（Barrier）。它要做的事情是：让一组线程到达一个屏障（也可以叫同步点）时被阻塞，直到最后一个线程到达屏障时，屏障才会开门，所有被屏障拦截的线程才会继续干活。 + +`CyclicBarrier` 默认的构造方法是 `CyclicBarrier(int parties)`，其参数表示屏障拦截的线程数量，每个线程调用 `await()` 方法告诉 `CyclicBarrier` 我已经到达了屏障，然后当前线程被阻塞。 + +再来看一下它的构造函数： + +```java +public CyclicBarrier(int parties) { + this(parties, null); +} + +public CyclicBarrier(int parties, Runnable barrierAction) { + if (parties <= 0) throw new IllegalArgumentException(); + this.parties = parties; + this.count = parties; + this.barrierCommand = barrierAction; +} +``` + +其中，parties 就代表了有拦截的线程的数量，当拦截的线程数量达到这个值的时候就打开栅栏，让所有线程通过。 + +### CyclicBarrier 的应用场景 + +`CyclicBarrier` 可以用于多线程计算数据，最后合并计算结果的应用场景。比如我们用一个 Excel 保存了用户所有银行流水，每个 Sheet 保存一个帐户近一年的每笔银行流水，现在需要统计用户的日均银行流水，先用多线程处理每个 sheet 里的银行流水，都执行完之后，得到每个 sheet 的日均银行流水，最后，再用 barrierAction 用这些线程的计算结果，计算出整个 Excel 的日均银行流水。 + +### CyclicBarrier 的使用示例 + +示例 1： + +```java +/** + * + * @author Snailclimb + * @date 2018年10月1日 + * @Description: 测试 CyclicBarrier 类中带参数的 await() 方法 + */ +public class CyclicBarrierExample2 { + // 请求的数量 + private static final int threadCount = 550; + // 需要同步的线程数量 + private static final CyclicBarrier cyclicBarrier = new CyclicBarrier(5); + + public static void main(String[] args) throws InterruptedException { + // 创建线程池 + ExecutorService threadPool = Executors.newFixedThreadPool(10); + + for (int i = 0; i < threadCount; i++) { + final int threadNum = i; + Thread.sleep(1000); + threadPool.execute(() -> { + try { + test(threadNum); + } catch (InterruptedException e) { + // TODO Auto-generated catch block + e.printStackTrace(); + } catch (BrokenBarrierException e) { + // TODO Auto-generated catch block + e.printStackTrace(); + } + }); + } + threadPool.shutdown(); + } + + public static void test(int threadnum) throws InterruptedException, BrokenBarrierException { + System.out.println("threadnum:" + threadnum + "is ready"); + try { + /**等待60秒，保证子线程完全执行结束*/ + cyclicBarrier.await(60, TimeUnit.SECONDS); + } catch (Exception e) { + System.out.println("-----CyclicBarrierException------"); + } + System.out.println("threadnum:" + threadnum + "is finish"); + } + +} +``` + +运行结果，如下： + +``` +threadnum:0is ready +threadnum:1is ready +threadnum:2is ready +threadnum:3is ready +threadnum:4is ready +threadnum:4is finish +threadnum:0is finish +threadnum:1is finish +threadnum:2is finish +threadnum:3is finish +threadnum:5is ready +threadnum:6is ready +threadnum:7is ready +threadnum:8is ready +threadnum:9is ready +threadnum:9is finish +threadnum:5is finish +threadnum:8is finish +threadnum:7is finish +threadnum:6is finish +...... +``` + +可以看到当线程数量也就是请求数量达到我们定义的 5 个的时候， `await()` 方法之后的方法才被执行。 + +另外，`CyclicBarrier` 还提供一个更高级的构造函数 `CyclicBarrier(int parties, Runnable barrierAction)`，用于在线程到达屏障时，优先执行 `barrierAction`，方便处理更复杂的业务场景。示例代码如下： + +```java +/** + * + * @author SnailClimb + * @date 2018年10月1日 + * @Description: 新建 CyclicBarrier 的时候指定一个 Runnable + */ +public class CyclicBarrierExample3 { + // 请求的数量 + private static final int threadCount = 550; + // 需要同步的线程数量 + private static final CyclicBarrier cyclicBarrier = new CyclicBarrier(5, () -> { + System.out.println("------当线程数达到之后，优先执行------"); + }); + + public static void main(String[] args) throws InterruptedException { + // 创建线程池 + ExecutorService threadPool = Executors.newFixedThreadPool(10); + + for (int i = 0; i < threadCount; i++) { + final int threadNum = i; + Thread.sleep(1000); + threadPool.execute(() -> { + try { + test(threadNum); + } catch (InterruptedException e) { + // TODO Auto-generated catch block + e.printStackTrace(); + } catch (BrokenBarrierException e) { + // TODO Auto-generated catch block + e.printStackTrace(); + } + }); + } + threadPool.shutdown(); + } + + public static void test(int threadnum) throws InterruptedException, BrokenBarrierException { + System.out.println("threadnum:" + threadnum + "is ready"); + cyclicBarrier.await(); + System.out.println("threadnum:" + threadnum + "is finish"); + } + +} +``` + +运行结果，如下： + +``` +threadnum:0is ready +threadnum:1is ready +threadnum:2is ready +threadnum:3is ready +threadnum:4is ready +------当线程数达到之后，优先执行------ +threadnum:4is finish +threadnum:0is finish +threadnum:2is finish +threadnum:1is finish +threadnum:3is finish +threadnum:5is ready +threadnum:6is ready +threadnum:7is ready +threadnum:8is ready +threadnum:9is ready +------当线程数达到之后，优先执行------ +threadnum:9is finish +threadnum:5is finish +threadnum:6is finish +threadnum:8is finish +threadnum:7is finish +...... +``` + +### CyclicBarrier 源码分析 + +当调用 `CyclicBarrier` 对象调用 `await()` 方法时，实际上调用的是 `dowait(false, 0L)`方法。 `await()` 方法就像树立起一个栅栏的行为一样，将线程挡住了，当拦住的线程数量达到 `parties` 的值时，栅栏才会打开，线程才得以通过执行。 + +```java +public int await() throws InterruptedException, BrokenBarrierException { + try { + return dowait(false, 0L); + } catch (TimeoutException toe) { + throw new Error(toe); // cannot happen + } +} +``` + +`dowait(false, 0L)`： + +```java + // 当线程数量或者请求数量达到 count 时 await 之后的方法才会被执行。上面的示例中 count 的值就为 5。 + private int count; + /** + * Main barrier code, covering the various policies. + */ + private int dowait(boolean timed, long nanos) + throws InterruptedException, BrokenBarrierException, + TimeoutException { + final ReentrantLock lock = this.lock; + // 锁住 + lock.lock(); + try { + final Generation g = generation; + + if (g.broken) + throw new BrokenBarrierException(); + + // 如果线程中断了，抛出异常 + if (Thread.interrupted()) { + breakBarrier(); + throw new InterruptedException(); + } + // cout减1 + int index = --count; + // 当 count 数量减为 0 之后说明最后一个线程已经到达栅栏了，也就是达到了可以执行await 方法之后的条件 + if (index == 0) { // tripped + boolean ranAction = false; + try { + final Runnable command = barrierCommand; + if (command != null) + command.run(); + ranAction = true; + // 将 count 重置为 parties 属性的初始化值 + // 唤醒之前等待的线程 + // 下一波执行开始 + nextGeneration(); + return 0; + } finally { + if (!ranAction) + breakBarrier(); + } + } + + // loop until tripped, broken, interrupted, or timed out + for (;;) { + try { + if (!timed) + trip.await(); + else if (nanos > 0L) + nanos = trip.awaitNanos(nanos); + } catch (InterruptedException ie) { + if (g == generation && ! g.broken) { + breakBarrier(); + throw ie; + } else { + // We're about to finish waiting even if we had not + // been interrupted, so this interrupt is deemed to + // "belong" to subsequent execution. + Thread.currentThread().interrupt(); + } + } + + if (g.broken) + throw new BrokenBarrierException(); + + if (g != generation) + return index; + + if (timed && nanos <= 0L) { + breakBarrier(); + throw new TimeoutException(); + } + } + } finally { + lock.unlock(); + } + } + +``` + +总结：`CyclicBarrier` 内部通过一个 count 变量作为计数器，count 的初始值为 parties 属性的初始化值，每当一个线程到了栅栏这里了，那么就将计数器减一。如果 count 值为 0 了，表示这是这一代最后一个线程到达栅栏，就尝试执行我们构造方法中输入的任务。 + +### CyclicBarrier 和 CountDownLatch 的区别 + +下面这个是国外一个大佬的回答： + +`CountDownLatch` 是计数器，只能使用一次，而 `CyclicBarrier` 的计数器提供 `reset` 功能，可以多次使用。但是我不那么认为它们之间的区别仅仅就是这么简单的一点。我们来从 jdk 作者设计的目的来看，javadoc 是这么描述它们的： + +> CountDownLatch: A synchronization aid that allows one or more threads to wait until a set of operations being performed in other threads completes.(CountDownLatch: 一个或者多个线程，等待其他多个线程完成某件事情之后才能执行；) +> CyclicBarrier : A synchronization aid that allows a set of threads to all wait for each other to reach a common barrier point.(CyclicBarrier : 多个线程互相等待，直到到达同一个同步点，再继续一起执行。) + +对于 `CountDownLatch` 来说，重点是“一个线程（多个线程）等待”，而其他的 N 个线程在完成“某件事情”之后，可以终止，也可以等待。而对于 `CyclicBarrier`，重点是多个线程，在任意一个线程没有完成，所有的线程都必须等待。 + +`CountDownLatch` 是计数器，线程完成一个记录一个，只不过计数不是递增而是递减，而 `CyclicBarrier` 更像是一个阀门，需要所有线程都到达，阀门才能打开，然后继续执行。 + +### ReentrantLock 和 ReentrantReadWriteLock + +`ReentrantLock` 和 `synchronized` 的区别在上面已经讲过了这里就不多做讲解。另外，需要注意的是：读写锁 `ReentrantReadWriteLock` 可以保证多个线程可以同时读，所以在读操作远大于写操作的时候，读写锁就非常有用了。 diff --git "a/Java\347\233\270\345\205\263/Multithread/Atomic.md" b/docs/java/concurrent/atomic-classes.md similarity index 38% rename from "Java\347\233\270\345\205\263/Multithread/Atomic.md" rename to docs/java/concurrent/atomic-classes.md index 33dd7ef3d9baa50fd717efedb8e3384d79941ffb..7628e1fe7d2834765ad9a36482a9483aceb2e38c 100644 --- "a/Java\347\233\270\345\205\263/Multithread/Atomic.md" +++ b/docs/java/concurrent/atomic-classes.md @@ -1,10 +1,12 @@ -> 个人觉得这一节掌握基本的使用即可！ +--- +title: Atomic 原子类总结 +category: Java +tag: + - Java并发 +--- -**本节思维导图:** -![](https://user-gold-cdn.xitu.io/2018/10/30/166c58b785368234?w=1200&h=657&f=png&s=49615) - -### 1 Atomic 原子类介绍 +## Atomic 原子类介绍 Atomic 翻译成中文是原子的意思。在化学上，我们知道原子是构成一般物质的最小单位，在化学反应中是不可分割的。在我们这里 Atomic 是指一个操作是不可中断的。即使是在多个线程一起执行的时候，一个操作一旦开始，就不会被其他线程干扰。 @@ -12,23 +14,22 @@ Atomic 翻译成中文是原子的意思。在化学上，我们知道原子是 并发包 `java.util.concurrent` 的原子类都存放在`java.util.concurrent.atomic`下,如下图所示。 -![ JUC 原子类概览](https://user-gold-cdn.xitu.io/2018/10/30/166c4ac08d4c5547?w=317&h=367&f=png&s=13267) +![JUC原子类概览](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/2019-6/JUC原子类概览.png) -根据操作的数据类型，可以将JUC包中的原子类分为4类 +根据操作的数据类型，可以将 JUC 包中的原子类分为 4 类 -**基本类型** +**基本类型** 使用原子的方式更新基本类型 - AtomicInteger：整型原子类 - AtomicLong：长整型原子类 -- AtomicBoolean ：布尔型原子类 +- AtomicBoolean ：布尔型原子类 **数组类型** 使用原子的方式更新数组里的某个元素 - - AtomicIntegerArray：整型数组原子类 - AtomicLongArray：长整型数组原子类 - AtomicReferenceArray ：引用类型数组原子类 @@ -36,31 +37,154 @@ Atomic 翻译成中文是原子的意思。在化学上，我们知道原子是 **引用类型** - AtomicReference：引用类型原子类 -- AtomicStampedRerence：原子更新引用类型里的字段原子类 -- AtomicMarkableReference ：原子更新带有标记位的引用类型 +- AtomicMarkableReference：原子更新带有标记的引用类型。该类将 boolean 标记与引用关联起来，~~也可以解决使用 CAS 进行原子更新时可能出现的 ABA 问题。~~ +- AtomicStampedReference ：原子更新带有版本号的引用类型。该类将整数值与引用关联起来，可用于解决原子的更新数据和数据的版本号，可以解决使用 CAS 进行原子更新时可能出现的 ABA 问题。 **对象的属性修改类型** - AtomicIntegerFieldUpdater:原子更新整型字段的更新器 - AtomicLongFieldUpdater：原子更新长整型字段的更新器 -- AtomicStampedReference ：原子更新带有版本号的引用类型。该类将整数值与引用关联起来，可用于解决原子的更新数据和数据的版本号，可以解决使用 CAS 进行原子更新时可能出现的 ABA 问题。 +- AtomicReferenceFieldUpdater：原子更新引用类型里的字段 + +> **🐛 修正（参见：[issue#626](https://github.com/Snailclimb/JavaGuide/issues/626)）** : `AtomicMarkableReference` 不能解决 ABA 问题。 + +```java + /** + +AtomicMarkableReference是将一个boolean值作是否有更改的标记，本质就是它的版本号只有两个，true和false， + +修改的时候在这两个版本号之间来回切换，这样做并不能解决ABA的问题，只是会降低ABA问题发生的几率而已 + +@author : mazh + +@Date : 2020/1/17 14:41 +*/ + +public class SolveABAByAtomicMarkableReference { + + private static AtomicMarkableReference atomicMarkableReference = new AtomicMarkableReference(100, false); + + public static void main(String[] args) { + + Thread refT1 = new Thread(() -> { + try { + TimeUnit.SECONDS.sleep(1); + } catch (InterruptedException e) { + e.printStackTrace(); + } + atomicMarkableReference.compareAndSet(100, 101, atomicMarkableReference.isMarked(), !atomicMarkableReference.isMarked()); + atomicMarkableReference.compareAndSet(101, 100, atomicMarkableReference.isMarked(), !atomicMarkableReference.isMarked()); + }); + + Thread refT2 = new Thread(() -> { + boolean marked = atomicMarkableReference.isMarked(); + try { + TimeUnit.SECONDS.sleep(2); + } catch (InterruptedException e) { + e.printStackTrace(); + } + boolean c3 = atomicMarkableReference.compareAndSet(100, 101, marked, !marked); + System.out.println(c3); // 返回true,实际应该返回false + }); + + refT1.start(); + refT2.start(); + } + } +``` + +**CAS ABA 问题** + +- 描述: 第一个线程取到了变量 x 的值 A，然后巴拉巴拉干别的事，总之就是只拿到了变量 x 的值 A。这段时间内第二个线程也取到了变量 x 的值 A，然后把变量 x 的值改为 B，然后巴拉巴拉干别的事，最后又把变量 x 的值变为 A （相当于还原了）。在这之后第一个线程终于进行了变量 x 的操作，但是此时变量 x 的值还是 A，所以 compareAndSet 操作是成功。 +- 例子描述(可能不太合适，但好理解): 年初，现金为零，然后通过正常劳动赚了三百万，之后正常消费了（比如买房子）三百万。年末，虽然现金零收入（可能变成其他形式了），但是赚了钱是事实，还是得交税的！ +- 代码例子（以`AtomicInteger`为例） + +```java +import java.util.concurrent.atomic.AtomicInteger; + +public class AtomicIntegerDefectDemo { + public static void main(String[] args) { + defectOfABA(); + } + + static void defectOfABA() { + final AtomicInteger atomicInteger = new AtomicInteger(1); + + Thread coreThread = new Thread( + () -> { + final int currentValue = atomicInteger.get(); + System.out.println(Thread.currentThread().getName() + " ------ currentValue=" + currentValue); + + // 这段目的：模拟处理其他业务花费的时间 + try { + Thread.sleep(300); + } catch (InterruptedException e) { + e.printStackTrace(); + } + + boolean casResult = atomicInteger.compareAndSet(1, 2); + System.out.println(Thread.currentThread().getName() + + " ------ currentValue=" + currentValue + + ", finalValue=" + atomicInteger.get() + + ", compareAndSet Result=" + casResult); + } + ); + coreThread.start(); + + // 这段目的：为了让 coreThread 线程先跑起来 + try { + Thread.sleep(100); + } catch (InterruptedException e) { + e.printStackTrace(); + } + + Thread amateurThread = new Thread( + () -> { + int currentValue = atomicInteger.get(); + boolean casResult = atomicInteger.compareAndSet(1, 2); + System.out.println(Thread.currentThread().getName() + + " ------ currentValue=" + currentValue + + ", finalValue=" + atomicInteger.get() + + ", compareAndSet Result=" + casResult); + + currentValue = atomicInteger.get(); + casResult = atomicInteger.compareAndSet(2, 1); + System.out.println(Thread.currentThread().getName() + + " ------ currentValue=" + currentValue + + ", finalValue=" + atomicInteger.get() + + ", compareAndSet Result=" + casResult); + } + ); + amateurThread.start(); + } +} +``` + +输出内容如下： + +``` +Thread-0 ------ currentValue=1 +Thread-1 ------ currentValue=1, finalValue=2, compareAndSet Result=true +Thread-1 ------ currentValue=2, finalValue=1, compareAndSet Result=true +Thread-0 ------ currentValue=1, finalValue=2, compareAndSet Result=true +``` 下面我们来详细介绍一下这些原子类。 -### 2 基本类型原子类 +## 基本类型原子类 -#### 2.1 基本类型原子类介绍 +### 基本类型原子类介绍 使用原子的方式更新基本类型 - AtomicInteger：整型原子类 - AtomicLong：长整型原子类 -- AtomicBoolean ：布尔型原子类 +- AtomicBoolean ：布尔型原子类 上面三个类提供的方法几乎相同，所以我们这里以 AtomicInteger 为例子来介绍。 - **AtomicInteger 类常用方法** - +**AtomicInteger 类常用方法** + ```java public final int get() //获取当前的值 public final int getAndSet(int newValue)//获取当前的值，并设置新的值 @@ -71,7 +195,7 @@ boolean compareAndSet(int expect, int update) //如果输入的数值等于预 public final void lazySet(int newValue)//最终设置为newValue,使用 lazySet 设置之后可能导致其他线程在之后的一小段时间内还是可以读到旧的值。 ``` -#### 2.2 AtomicInteger 常见方法使用 +### AtomicInteger 常见方法使用 ```java import java.util.concurrent.atomic.AtomicInteger; @@ -93,18 +217,18 @@ public class AtomicIntegerTest { } ``` -#### 2.3 基本数据类型原子类的优势 +### 基本数据类型原子类的优势 通过一个简单例子带大家看一下基本数据类型原子类的优势 -**①多线程环境不使用原子类保证线程安全（基本数据类型）** +**① 多线程环境不使用原子类保证线程安全（基本数据类型）** ```java class Test { private volatile int count = 0; //若要线程安全执行执行count++，需要加锁 public synchronized void increment() { - count++; + count++; } public int getCount() { @@ -112,7 +236,8 @@ class Test { } } ``` -**②多线程环境使用原子类保证线程安全（基本数据类型）** + +**② 多线程环境使用原子类保证线程安全（基本数据类型）** ```java class Test2 { @@ -128,7 +253,8 @@ class Test2 { } ``` -#### 2.4 AtomicInteger 线程安全原理简单分析 + +### AtomicInteger 线程安全原理简单分析 AtomicInteger 类的部分源码： @@ -149,16 +275,14 @@ AtomicInteger 类的部分源码： AtomicInteger 类主要利用 CAS (compare and swap) + volatile 和 native 方法来保证原子操作，从而避免 synchronized 的高开销，执行效率大为提升。 -CAS的原理是拿期望的值和原本的一个值作比较，如果相同则更新成新的值。UnSafe 类的 objectFieldOffset() 方法是一个本地方法，这个方法是用来拿到“原来的值”的内存地址，返回值是 valueOffset。另外 value 是一个volatile变量，在内存中可见，因此 JVM 可以保证任何时刻任何线程总能拿到该变量的最新值。 - +CAS 的原理是拿期望的值和原本的一个值作比较，如果相同则更新成新的值。UnSafe 类的 objectFieldOffset() 方法是一个本地方法，这个方法是用来拿到“原来的值”的内存地址。另外 value 是一个 volatile 变量，在内存中可见，因此 JVM 可以保证任何时刻任何线程总能拿到该变量的最新值。 -### 3 数组类型原子类 +## 数组类型原子类 -#### 3.1 数组类型原子类介绍 +### 数组类型原子类介绍 使用原子的方式更新数组里的某个元素 - - AtomicIntegerArray：整形数组原子类 - AtomicLongArray：长整形数组原子类 - AtomicReferenceArray ：引用类型数组原子类 @@ -172,11 +296,12 @@ public final int get(int i) //获取 index=i 位置元素的值 public final int getAndSet(int i, int newValue)//返回 index=i 位置的当前的值，并将其设置为新值：newValue public final int getAndIncrement(int i)//获取 index=i 位置元素的值，并让该位置的元素自增 public final int getAndDecrement(int i) //获取 index=i 位置元素的值，并让该位置的元素自减 -public final int getAndAdd(int delta) //获取 index=i 位置元素的值，并加上预期的值 -boolean compareAndSet(int expect, int update) //如果输入的数值等于预期值，则以原子方式将 index=i 位置的元素值设置为输入值（update） +public final int getAndAdd(int i, int delta) //获取 index=i 位置元素的值，并加上预期的值 +boolean compareAndSet(int i, int expect, int update) //如果输入的数值等于预期值，则以原子方式将 index=i 位置的元素值设置为输入值（update） public final void lazySet(int i, int newValue)//最终 将index=i 位置的元素设置为newValue,使用 lazySet 设置之后可能导致其他线程在之后的一小段时间内还是可以读到旧的值。 ``` -#### 3.2 AtomicIntegerArray 常见方法使用 + +### AtomicIntegerArray 常见方法使用 ```java @@ -203,19 +328,19 @@ public class AtomicIntegerArrayTest { } ``` -### 4 引用类型原子类 +## 引用类型原子类 -#### 4.1 引用类型原子类介绍 +### 引用类型原子类介绍 基本类型原子类只能更新一个变量，如果需要原子更新多个变量，需要使用 引用类型原子类。 - AtomicReference：引用类型原子类 -- AtomicStampedRerence：原子更新引用类型里的字段原子类 -- AtomicMarkableReference ：原子更新带有标记位的引用类型 +- AtomicStampedReference：原子更新带有版本号的引用类型。该类将整数值与引用关联起来，可用于解决原子的更新数据和数据的版本号，可以解决使用 CAS 进行原子更新时可能出现的 ABA 问题。 +- AtomicMarkableReference ：原子更新带有标记的引用类型。该类将 boolean 标记与引用关联起来，~~也可以解决使用 CAS 进行原子更新时可能出现的 ABA 问题。~~ 上面三个类提供的方法几乎相同，所以我们这里以 AtomicReference 为例子来介绍。 -#### 4.2 AtomicReference 类使用示例 +### AtomicReference 类使用示例 ```java import java.util.concurrent.atomic.AtomicReference; @@ -262,29 +387,147 @@ class Person { } ``` -上述代码首先创建了一个 Person 对象，然后把 Person 对象设置进 AtomicReference 对象中，然后调用 compareAndSet 方法，该方法就是通过通过 CAS 操作设置 ar。如果 ar 的值为 person 的话，则将其设置为 updatePerson。实现原理与 AtomicInteger 类中的 compareAndSet 方法相同。运行上面的代码后的输出结果如下： + +上述代码首先创建了一个 Person 对象，然后把 Person 对象设置进 AtomicReference 对象中，然后调用 compareAndSet 方法，该方法就是通过 CAS 操作设置 ar。如果 ar 的值为 person 的话，则将其设置为 updatePerson。实现原理与 AtomicInteger 类中的 compareAndSet 方法相同。运行上面的代码后的输出结果如下： ``` Daisy 20 ``` +### AtomicStampedReference 类使用示例 -### 5 对象的属性修改类型原子类 +```java +import java.util.concurrent.atomic.AtomicStampedReference; + +public class AtomicStampedReferenceDemo { + public static void main(String[] args) { + // 实例化、取当前值和 stamp 值 + final Integer initialRef = 0, initialStamp = 0; + final AtomicStampedReference asr = new AtomicStampedReference<>(initialRef, initialStamp); + System.out.println("currentValue=" + asr.getReference() + ", currentStamp=" + asr.getStamp()); + + // compare and set + final Integer newReference = 666, newStamp = 999; + final boolean casResult = asr.compareAndSet(initialRef, newReference, initialStamp, newStamp); + System.out.println("currentValue=" + asr.getReference() + + ", currentStamp=" + asr.getStamp() + + ", casResult=" + casResult); + + // 获取当前的值和当前的 stamp 值 + int[] arr = new int[1]; + final Integer currentValue = asr.get(arr); + final int currentStamp = arr[0]; + System.out.println("currentValue=" + currentValue + ", currentStamp=" + currentStamp); + + // 单独设置 stamp 值 + final boolean attemptStampResult = asr.attemptStamp(newReference, 88); + System.out.println("currentValue=" + asr.getReference() + + ", currentStamp=" + asr.getStamp() + + ", attemptStampResult=" + attemptStampResult); + + // 重新设置当前值和 stamp 值 + asr.set(initialRef, initialStamp); + System.out.println("currentValue=" + asr.getReference() + ", currentStamp=" + asr.getStamp()); + + // [不推荐使用，除非搞清楚注释的意思了] weak compare and set + // 困惑！weakCompareAndSet 这个方法最终还是调用 compareAndSet 方法。[版本: jdk-8u191] + // 但是注释上写着 "May fail spuriously and does not provide ordering guarantees, + // so is only rarely an appropriate alternative to compareAndSet." + // todo 感觉有可能是 jvm 通过方法名在 native 方法里面做了转发 + final boolean wCasResult = asr.weakCompareAndSet(initialRef, newReference, initialStamp, newStamp); + System.out.println("currentValue=" + asr.getReference() + + ", currentStamp=" + asr.getStamp() + + ", wCasResult=" + wCasResult); + } +} +``` -#### 5.1 对象的属性修改类型原子类介绍 +输出结果如下： + +``` +currentValue=0, currentStamp=0 +currentValue=666, currentStamp=999, casResult=true +currentValue=666, currentStamp=999 +currentValue=666, currentStamp=88, attemptStampResult=true +currentValue=0, currentStamp=0 +currentValue=666, currentStamp=999, wCasResult=true +``` + +### AtomicMarkableReference 类使用示例 + +```java +import java.util.concurrent.atomic.AtomicMarkableReference; + +public class AtomicMarkableReferenceDemo { + public static void main(String[] args) { + // 实例化、取当前值和 mark 值 + final Boolean initialRef = null, initialMark = false; + final AtomicMarkableReference amr = new AtomicMarkableReference<>(initialRef, initialMark); + System.out.println("currentValue=" + amr.getReference() + ", currentMark=" + amr.isMarked()); + + // compare and set + final Boolean newReference1 = true, newMark1 = true; + final boolean casResult = amr.compareAndSet(initialRef, newReference1, initialMark, newMark1); + System.out.println("currentValue=" + amr.getReference() + + ", currentMark=" + amr.isMarked() + + ", casResult=" + casResult); + + // 获取当前的值和当前的 mark 值 + boolean[] arr = new boolean[1]; + final Boolean currentValue = amr.get(arr); + final boolean currentMark = arr[0]; + System.out.println("currentValue=" + currentValue + ", currentMark=" + currentMark); + + // 单独设置 mark 值 + final boolean attemptMarkResult = amr.attemptMark(newReference1, false); + System.out.println("currentValue=" + amr.getReference() + + ", currentMark=" + amr.isMarked() + + ", attemptMarkResult=" + attemptMarkResult); + + // 重新设置当前值和 mark 值 + amr.set(initialRef, initialMark); + System.out.println("currentValue=" + amr.getReference() + ", currentMark=" + amr.isMarked()); + + // [不推荐使用，除非搞清楚注释的意思了] weak compare and set + // 困惑！weakCompareAndSet 这个方法最终还是调用 compareAndSet 方法。[版本: jdk-8u191] + // 但是注释上写着 "May fail spuriously and does not provide ordering guarantees, + // so is only rarely an appropriate alternative to compareAndSet." + // todo 感觉有可能是 jvm 通过方法名在 native 方法里面做了转发 + final boolean wCasResult = amr.weakCompareAndSet(initialRef, newReference1, initialMark, newMark1); + System.out.println("currentValue=" + amr.getReference() + + ", currentMark=" + amr.isMarked() + + ", wCasResult=" + wCasResult); + } +} +``` + +输出结果如下： + +``` +currentValue=null, currentMark=false +currentValue=true, currentMark=true, casResult=true +currentValue=true, currentMark=true +currentValue=true, currentMark=false, attemptMarkResult=true +currentValue=null, currentMark=false +currentValue=true, currentMark=true, wCasResult=true +``` + +## 对象的属性修改类型原子类 + +### 对象的属性修改类型原子类介绍 如果需要原子更新某个类里的某个字段时，需要用到对象的属性修改类型原子类。 - AtomicIntegerFieldUpdater:原子更新整形字段的更新器 - AtomicLongFieldUpdater：原子更新长整形字段的更新器 -- AtomicStampedReference ：原子更新带有版本号的引用类型。该类将整数值与引用关联起来，可用于解决原子的更新数据和数据的版本号，可以解决使用 CAS 进行原子更新时可能出现的 ABA 问题。 +- AtomicReferenceFieldUpdater ：原子更新引用类型里的字段的更新器 要想原子地更新对象的属性需要两步。第一步，因为对象的属性修改类型原子类都是抽象类，所以每次使用都必须使用静态方法 newUpdater()创建一个更新器，并且需要设置想要更新的类和属性。第二步，更新的对象属性必须使用 public volatile 修饰符。 上面三个类提供的方法几乎相同，所以我们这里以 `AtomicIntegerFieldUpdater`为例子来介绍。 -#### 5.2 AtomicIntegerFieldUpdater 类使用示例 +### AtomicIntegerFieldUpdater 类使用示例 ```java import java.util.concurrent.atomic.AtomicIntegerFieldUpdater; @@ -335,3 +578,6 @@ class User { 23 ``` +## Reference + +- 《Java 并发编程的艺术》 diff --git a/docs/java/concurrent/completablefuture-intro.md b/docs/java/concurrent/completablefuture-intro.md new file mode 100644 index 0000000000000000000000000000000000000000..810d5a61708c87daf0cb07629cf592776800111f --- /dev/null +++ b/docs/java/concurrent/completablefuture-intro.md @@ -0,0 +1,526 @@ +--- +title: CompletableFuture入门 +category: Java +tag: + - Java并发 +--- + + +自己在项目中使用 `CompletableFuture` 比较多，看到很多开源框架中也大量使用到了 `CompletableFuture` 。 + +因此，专门写一篇文章来介绍这个 Java 8 才被引入的一个非常有用的用于异步编程的类。 + +## 简单介绍 + +`CompletableFuture` 同时实现了 `Future` 和 `CompletionStage` 接口。 + +```java +public class CompletableFuture implements Future, CompletionStage { +} +``` + +`CompletableFuture` 除了提供了更为好用和强大的 `Future` 特性之外，还提供了函数式编程的能力。 + +![](https://guide-blog-images.oss-cn-shenzhen.aliyuncs.com/javaguide/image-20210902092441434.png) + +`Future` 接口有 5 个方法： + +- `boolean cancel(boolean mayInterruptIfRunning)` ：尝试取消执行任务。 +- `boolean isCancelled()` ：判断任务是否被取消。 +- `boolean isDone()` ： 判断任务是否已经被执行完成。 +- `get()` ：等待任务执行完成并获取运算结果。 +- `get(long timeout, TimeUnit unit)` ：多了一个超时时间。 + +![](https://guide-blog-images.oss-cn-shenzhen.aliyuncs.com/javaguide/image-20210902093026059.png) + +`CompletionStage` 接口中的方法比较多，`CompletableFuture` 的函数式能力就是这个接口赋予的。从这个接口的方法参数你就可以发现其大量使用了 Java8 引入的函数式编程。 + +由于方法众多，所以这里不能一一讲解，下文中我会介绍大部分常见方法的使用。 + +## 常见操作 + +### 创建 CompletableFuture + +常见的创建 `CompletableFuture` 对象的方法如下： + +1. 通过 new 关键字。 +2. 基于 `CompletableFuture` 自带的静态工厂方法：`runAsync()` 、`supplyAsync()` 。 + +#### new 关键字 + +通过 new 关键字创建 `CompletableFuture` 对象这种使用方式可以看作是将 `CompletableFuture` 当做 `Future` 来使用。 + +我在我的开源项目 [guide-rpc-framework](https://github.com/Snailclimb/guide-rpc-framework) 中就是这种方式创建的 `CompletableFuture` 对象。 + +下面咱们来看一个简单的案例。 + +我们通过创建了一个结果值类型为 `RpcResponse` 的 `CompletableFuture`，你可以把 `resultFuture` 看作是异步运算结果的载体。 + +```java +CompletableFuture> resultFuture = new CompletableFuture<>(); +``` + +假设在未来的某个时刻，我们得到了最终的结果。这时，我们可以调用 `complete()` 方法为其传入结果，这表示 `resultFuture` 已经被完成了。 + +```java +// complete() 方法只能调用一次，后续调用将被忽略。 +resultFuture.complete(rpcResponse); +``` + +你可以通过 `isDone()` 方法来检查是否已经完成。 + +```java +public boolean isDone() { + return result != null; +} +``` + +获取异步计算的结果也非常简单，直接调用 `get()` 方法即可！ + +```java +rpcResponse = completableFuture.get(); +``` + +注意 ： `get()` 方法并不会阻塞，因为我们已经知道异步运算的结果了。 + +如果你已经知道计算的结果的话，可以使用静态方法 `completedFuture()` 来创建 `CompletableFuture` 。 + +```java +CompletableFuture future = CompletableFuture.completedFuture("hello!"); +assertEquals("hello!", future.get()); +``` + +`completedFuture()` 方法底层调用的是带参数的 new 方法，只不过，这个方法不对外暴露。 + +```java +public static CompletableFuture completedFuture(U value) { + return new CompletableFuture((value == null) ? NIL : value); +} +``` + +#### 静态工厂方法 + +这两个方法可以帮助我们封装计算逻辑。 + +```java +static CompletableFuture supplyAsync(Supplier supplier); +// 使用自定义线程池(推荐) +static CompletableFuture supplyAsync(Supplier supplier, Executor executor); +static CompletableFuture runAsync(Runnable runnable); +// 使用自定义线程池(推荐) +static CompletableFuture runAsync(Runnable runnable, Executor executor); +``` + +`runAsync()` 方法接受的参数是 `Runnable` ，这是一个函数式接口，不允许返回值。当你需要异步操作且不关心返回结果的时候可以使用 `runAsync()` 方法。 + +```java +@FunctionalInterface +public interface Runnable { + public abstract void run(); +} +``` + +`supplyAsync()` 方法接受的参数是 `Supplier` ，这也是一个函数式接口，`U` 是返回结果值的类型。 + +```java +@FunctionalInterface +public interface Supplier { + + /** + * Gets a result. + * + * @return a result + */ + T get(); +} +``` + +当你需要异步操作且关心返回结果的时候,可以使用 `supplyAsync()` 方法。 + +```java +CompletableFuture future = CompletableFuture.runAsync(() -> System.out.println("hello!")); +future.get();// 输出 "hello!" +CompletableFuture future2 = CompletableFuture.supplyAsync(() -> "hello!"); +assertEquals("hello!", future2.get()); +``` + +### 处理异步结算的结果 + +当我们获取到异步计算的结果之后，还可以对其进行进一步的处理，比较常用的方法有下面几个： + +- `thenApply()` +- `thenAccept()` +- `thenRun()` +- `whenComplete()` + +`thenApply()` 方法接受一个 `Function` 实例，用它来处理结果。 + +```java +// 沿用上一个任务的线程池 +public CompletableFuture thenApply( + Function fn) { + return uniApplyStage(null, fn); +} + +//使用默认的 ForkJoinPool 线程池（不推荐） +public CompletableFuture thenApplyAsync( + Function fn) { + return uniApplyStage(defaultExecutor(), fn); +} +// 使用自定义线程池(推荐) +public CompletableFuture thenApplyAsync( + Function fn, Executor executor) { + return uniApplyStage(screenExecutor(executor), fn); +} +``` + +`thenApply()` 方法使用示例如下： + +```java +CompletableFuture future = CompletableFuture.completedFuture("hello!") + .thenApply(s -> s + "world!"); +assertEquals("hello!world!", future.get()); +// 这次调用将被忽略。 +future.thenApply(s -> s + "nice!"); +assertEquals("hello!world!", future.get()); +``` + +你还可以进行 **流式调用**： + +```java +CompletableFuture future = CompletableFuture.completedFuture("hello!") + .thenApply(s -> s + "world!").thenApply(s -> s + "nice!"); +assertEquals("hello!world!nice!", future.get()); +``` + +**如果你不需要从回调函数中获取返回结果，可以使用 `thenAccept()` 或者 `thenRun()`。这两个方法的区别在于 `thenRun()` 不能访问异步计算的结果。** + +`thenAccept()` 方法的参数是 `Consumer` 。 + +```java +public CompletableFuture thenAccept(Consumer action) { + return uniAcceptStage(null, action); +} + +public CompletableFuture thenAcceptAsync(Consumer action) { + return uniAcceptStage(defaultExecutor(), action); +} + +public CompletableFuture thenAcceptAsync(Consumer action, + Executor executor) { + return uniAcceptStage(screenExecutor(executor), action); +} +``` + +顾名思义，`Consumer` 属于消费型接口，它可以接收 1 个输入对象然后进行“消费”。 + +```java +@FunctionalInterface +public interface Consumer { + + void accept(T t); + + default Consumer andThen(Consumer after) { + Objects.requireNonNull(after); + return (T t) -> { accept(t); after.accept(t); }; + } +} +``` + +`thenRun()` 的方法是的参数是 `Runnable` 。 + +```java +public CompletableFuture thenRun(Runnable action) { + return uniRunStage(null, action); +} + +public CompletableFuture thenRunAsync(Runnable action) { + return uniRunStage(defaultExecutor(), action); +} + +public CompletableFuture thenRunAsync(Runnable action, + Executor executor) { + return uniRunStage(screenExecutor(executor), action); +} +``` + +`thenAccept()` 和 `thenRun()` 使用示例如下： + +```java +CompletableFuture.completedFuture("hello!") + .thenApply(s -> s + "world!").thenApply(s -> s + "nice!").thenAccept(System.out::println);//hello!world!nice! + +CompletableFuture.completedFuture("hello!") + .thenApply(s -> s + "world!").thenApply(s -> s + "nice!").thenRun(() -> System.out.println("hello!"));//hello! +``` + +`whenComplete()` 的方法的参数是 `BiConsumer` 。 + +```java +public CompletableFuture whenComplete( + BiConsumer action) { + return uniWhenCompleteStage(null, action); +} + + +public CompletableFuture whenCompleteAsync( + BiConsumer action) { + return uniWhenCompleteStage(defaultExecutor(), action); +} +// 使用自定义线程池(推荐) +public CompletableFuture whenCompleteAsync( + BiConsumer action, Executor executor) { + return uniWhenCompleteStage(screenExecutor(executor), action); +} +``` + +相对于 `Consumer` ， `BiConsumer` 可以接收 2 个输入对象然后进行“消费”。 + +```java +@FunctionalInterface +public interface BiConsumer { + void accept(T t, U u); + + default BiConsumer andThen(BiConsumer after) { + Objects.requireNonNull(after); + + return (l, r) -> { + accept(l, r); + after.accept(l, r); + }; + } +} +``` + +`whenComplete()` 使用示例如下： + +```java +CompletableFuture future = CompletableFuture.supplyAsync(() -> "hello!") + .whenComplete((res, ex) -> { + // res 代表返回的结果 + // ex 的类型为 Throwable ，代表抛出的异常 + System.out.println(res); + // 这里没有抛出异常所有为 null + assertNull(ex); + }); +assertEquals("hello!", future.get()); +``` + +### 异常处理 + +你可以通过 `handle()` 方法来处理任务执行过程中可能出现的抛出异常的情况。 + +```java +public CompletableFuture handle( + BiFunction fn) { + return uniHandleStage(null, fn); +} + +public CompletableFuture handleAsync( + BiFunction fn) { + return uniHandleStage(defaultExecutor(), fn); +} + +public CompletableFuture handleAsync( + BiFunction fn, Executor executor) { + return uniHandleStage(screenExecutor(executor), fn); +} +``` + +示例代码如下： + +```java +CompletableFuture future + = CompletableFuture.supplyAsync(() -> { + if (true) { + throw new RuntimeException("Computation error!"); + } + return "hello!"; +}).handle((res, ex) -> { + // res 代表返回的结果 + // ex 的类型为 Throwable ，代表抛出的异常 + return res != null ? res : "world!"; +}); +assertEquals("world!", future.get()); +``` + +你还可以通过 `exceptionally()` 方法来处理异常情况。 + +```java +CompletableFuture future + = CompletableFuture.supplyAsync(() -> { + if (true) { + throw new RuntimeException("Computation error!"); + } + return "hello!"; +}).exceptionally(ex -> { + System.out.println(ex.toString());// CompletionException + return "world!"; +}); +assertEquals("world!", future.get()); +``` + +如果你想让 `CompletableFuture` 的结果就是异常的话，可以使用 `completeExceptionally()` 方法为其赋值。 + +```java +CompletableFuture completableFuture = new CompletableFuture<>(); +// ... +completableFuture.completeExceptionally( + new RuntimeException("Calculation failed!")); +// ... +completableFuture.get(); // ExecutionException +``` + +### 组合 CompletableFuture + +你可以使用 `thenCompose()` 按顺序链接两个 `CompletableFuture` 对象。 + +```java +public CompletableFuture thenCompose( + Function> fn) { + return uniComposeStage(null, fn); +} + +public CompletableFuture thenComposeAsync( + Function> fn) { + return uniComposeStage(defaultExecutor(), fn); +} + +public CompletableFuture thenComposeAsync( + Function> fn, + Executor executor) { + return uniComposeStage(screenExecutor(executor), fn); +} +``` + +`thenCompose()` 方法会使用示例如下： + +```java +CompletableFuture future + = CompletableFuture.supplyAsync(() -> "hello!") + .thenCompose(s -> CompletableFuture.supplyAsync(() -> s + "world!")); +assertEquals("hello!world!", future.get()); +``` + +在实际开发中，这个方法还是非常有用的。比如说，我们先要获取用户信息然后再用用户信息去做其他事情。 + +和 `thenCompose()` 方法类似的还有 `thenCombine()` 方法， `thenCombine()` 同样可以组合两个 `CompletableFuture` 对象。 + +```java +CompletableFuture completableFuture + = CompletableFuture.supplyAsync(() -> "hello!") + .thenCombine(CompletableFuture.supplyAsync( + () -> "world!"), (s1, s2) -> s1 + s2) + .thenCompose(s -> CompletableFuture.supplyAsync(() -> s + "nice!")); +assertEquals("hello!world!nice!", completableFuture.get()); +``` + +**那 `thenCompose()` 和 `thenCombine()` 有什么区别呢？** + +- `thenCompose()` 可以两个 `CompletableFuture` 对象，并将前一个任务的返回结果作为下一个任务的参数，它们之间存在着先后顺序。 +- `thenCombine()` 会在两个任务都执行完成后，把两个任务的结果合并。两个任务是并行执行的，它们之间并没有先后依赖顺序。 + +### 并行运行多个 CompletableFuture + +你可以通过 `CompletableFuture` 的 `allOf()`这个静态方法来并行运行多个 `CompletableFuture` 。 + +实际项目中，我们经常需要并行运行多个互不相关的任务，这些任务之间没有依赖关系，可以互相独立地运行。 + +比说我们要读取处理 6 个文件，这 6 个任务都是没有执行顺序依赖的任务，但是我们需要返回给用户的时候将这几个文件的处理的结果进行统计整理。像这种情况我们就可以使用并行运行多个 `CompletableFuture` 来处理。 + +示例代码如下： + +```java +CompletableFuture task1 = + CompletableFuture.supplyAsync(()->{ + //自定义业务操作 + }); +...... +CompletableFuture task6 = + CompletableFuture.supplyAsync(()->{ + //自定义业务操作 + }); +...... + CompletableFuture headerFuture=CompletableFuture.allOf(task1,.....,task6); + + try { + headerFuture.join(); + } catch (Exception ex) { + ...... + } +System.out.println("all done. "); +``` + +经常和 `allOf()` 方法拿来对比的是 `anyOf()` 方法。 + +**`allOf()` 方法会等到所有的 `CompletableFuture` 都运行完成之后再返回** + +```java +Random rand = new Random(); +CompletableFuture future1 = CompletableFuture.supplyAsync(() -> { + try { + Thread.sleep(1000 + rand.nextInt(1000)); + } catch (InterruptedException e) { + e.printStackTrace(); + } finally { + System.out.println("future1 done..."); + } + return "abc"; +}); +CompletableFuture future2 = CompletableFuture.supplyAsync(() -> { + try { + Thread.sleep(1000 + rand.nextInt(1000)); + } catch (InterruptedException e) { + e.printStackTrace(); + } finally { + System.out.println("future2 done..."); + } + return "efg"; +}); +``` + +调用 `join()` 可以让程序等`future1` 和 `future2` 都运行完了之后再继续执行。 + +```java +CompletableFuture completableFuture = CompletableFuture.allOf(future1, future2); +completableFuture.join(); +assertTrue(completableFuture.isDone()); +System.out.println("all futures done..."); +``` + +输出： + +```java +future1 done... +future2 done... +all futures done... +``` + +**`anyOf()` 方法不会等待所有的 `CompletableFuture` 都运行完成之后再返回，只要有一个执行完成即可！** + +```java +CompletableFuture f = CompletableFuture.anyOf(future1, future2); +System.out.println(f.get()); +``` + +输出结果可能是： + +```java +future2 done... +efg +``` + +也可能是： + +``` +future1 done... +abc +``` + +## 后记 + +这篇文章只是简单介绍了 `CompletableFuture` 比较常用的一些 API 。 + +如果想要深入学习的话，可以多找一些书籍和博客看。 + +另外，建议G友们可以看看京东的 [asyncTool](https://gitee.com/jd-platform-opensource/asyncTool) 这个并发框架，里面大量使用到了 `CompletableFuture` 。 diff --git "a/docs/java/concurrent/images/ThreadLocal\345\206\205\351\203\250\347\261\273.png" "b/docs/java/concurrent/images/ThreadLocal\345\206\205\351\203\250\347\261\273.png" new file mode 100644 index 0000000000000000000000000000000000000000..32326a223401d0c2e110f0545fcfa71b995e359c Binary files /dev/null and "b/docs/java/concurrent/images/ThreadLocal\345\206\205\351\203\250\347\261\273.png" differ diff --git a/docs/java/concurrent/images/interview-questions/cpu-cache.drawio b/docs/java/concurrent/images/interview-questions/cpu-cache.drawio new file mode 100644 index 0000000000000000000000000000000000000000..4121eaff4bf7924a7b5da92cc66edc8f35b2f544 --- /dev/null +++ b/docs/java/concurrent/images/interview-questions/cpu-cache.drawio @@ -0,0 +1 @@ +7VnZcqM4FP0aHuMChFgevSaVmtSk2jPVPY8K3IAqGLmFHDv99S2BMKuzTJp2ajLJg9HRfs/RPSwGmm8Ol5xskxsWQWrYZnQw0MKwbcsyXfmjkKcSCQKvBGJOI92oBtb0B2jQ1OiORpC3GgrGUkG3bTBkWQahaGGEc7ZvN7tnaXvWLYmhB6xDkvbRrzQSSYn6tlfjV0DjpJrZcoOyZkOqxnoneUIitm9AaGmgOWdMlFebwxxSFbwqLmW/1Yna48I4ZOI1Hf76sb6Jrtj+Kvy+/jP6I/+Kr/0LuxzlkaQ7vWG9WPFURYCzXRaBGsQy0GyfUAHrLQlV7V5yLrFEbFJdfc8yoUmUy5FlmqZzljJejIXu/RDCUOK54OwBGjV3Pnaw6pE/gAgTPdwxZqpGLxW4gMPJGFjHyEpJAtuA4E+ySa3HsotW41Fm+5pb29FY0uQ10CDReoqPY9chlxc66m9gAPUYmN/+LYEvENNcAM/fSUibALAiDN4QAYHrIeJ2CWjwafljEILbhKABQix3gBBvLD4sr38kltjwsTGdG0vHmM0NmcIUsjJm8mJVINNr8kguVa4ybDeVa5zd8RZr7vedOuhFQC/yIqJT2cByt4ciklW9vIqLXzXVwgjknL7hm2r+aqpyGrmCABlT3JOHJEO0NdDmOmMZdIShIZLSOJPFUJIHEp8paqnMhVNdsaFRpKYZFF0tS6WNlNxBOiPhQ1zg3ckbsnJ1uaHFWfFfjCmIoEzNfYFGzw5HUWkxunhAjP5QdhhNjMFwdviQlHdz/7iZ3O9kcjTAlTnAFRqLq8rnP4uXOgh/NC+tNvFJzdTx2oyc30yrI/B//upyhc3O6Tl//jp1JzonYQLvOzi9A4JcFKCof6RWq+nCWT1zcEpmRn4scILXprLRnN92Pi0bXWP5CGzgl70dsmiqXjiobJSSPKelNxMu+vAzLg8HKr6pYE6wHejyP0XZNKvy4qCjXRSeGoVb4FRuWaXCxQluIOq98egwI7fFdjyEF5NFn8IGRXiAoQrjkMr7+sf2OoZY0zPcMipXWN+od84rNjvEl+vXvZrvRLoDIa8ttSorVwNJ+mIQvYEKER23/Q5duefQVVNVzypqNPU451QPxs7kRIZ5q36KoZyOhJyJaf1eFfVfWdwQmknkBjZMp78R3OL1rtDzlaXt41/l3W0uvYGbXjx00zuiW/Sf2sc/1bbZdIsLaRe293HswjurXdjBRFpE/YdainF9PAmCf2kgauh2AnC7ZjTy6UeveO/wH1Lb+VzDndgnUs3bbQNNOs/qrmlPqk9j7xaOLNbflcrm9dc5tPwJ \ No newline at end of file diff --git a/docs/java/concurrent/images/interview-questions/cpu-cache.png b/docs/java/concurrent/images/interview-questions/cpu-cache.png new file mode 100755 index 0000000000000000000000000000000000000000..895f3f4ba6aa67c368e031d12db1582df1a9c318 Binary files /dev/null and b/docs/java/concurrent/images/interview-questions/cpu-cache.png differ diff --git a/docs/java/concurrent/images/interview-questions/jmm.drawio b/docs/java/concurrent/images/interview-questions/jmm.drawio new file mode 100644 index 0000000000000000000000000000000000000000..c9c642fa39f615894aa9c463b17e87e42053badb --- /dev/null +++ b/docs/java/concurrent/images/interview-questions/jmm.drawio @@ -0,0 +1 @@ +7Vpbc5s6EP41ekwGIS7iEXxJpzOdZprpnNNHBWSbCSAHy7HdX18JhLnJDZnajp02ebC0Eiv0fbvaXQCgUbq9y8ly8YVFNAGmEW0BGgPThNBwxI+U7EqJ57mlYJ7HkZpUCx7in1QJDSVdxxFdtSZyxhIeL9vCkGUZDXlLRvKcbdrTZixpr7okc9oTPIQk6Uv/iyO+KKXYdGv5JxrPF9XK0PHKkZRUk9VOVgsSsU1DhCYAjXLGeNlKtyOaSPAqXMrrpgdG9zeW04wPuYB8+vYjS9P07jn79uX+6TucPH+9qWB+Icla7VjdLd9VEORsnUVUaoEABZtFzOnDkoRydCNIF7IFTxM1PGMZVyyK+xH9OElGLGF5oQtFhOJZKOQrnrMn2hhxQkwfZ3LkifJwodSpu6M5p9uD+4Z7NIUZUpZSnu/EFHWBVRGgLBBaqr+p+TQr2aLBJUJKSJQNzfe6a5hFQyH9BtS9Dw86hBcHunls0NsgUxjZ1NWB7DkuIs4pQLbbICPYBxk6GpDhyUBGfZAnDvBGwB+BiS0bgSEb2AHYlg1/DDzcI0Jgwttot1HNWEY7FCgRSeJ5JrqhwJAKeSARjsV57quBNI4iuYyW3toADI1bHZ0/3OFP4yTQ0DnJqeizP5yPWM7F+Yjzz0fewJ93aT7iauhzQeCDYCobPgY4gD22hGKRsh7CdHgsn82oE2pjeeR6j8ZJjim3E8tdDQWmhgJ8KgrwAAr6J9cVU2DhS6MAwtdDBc0iX5Zg8qhJyGoVl6CRnPfFv4FfYJTv/pfnza1ddX+ouUVnvFWHUdnbqZ6GBBr1qr0OBWIDbJ2H9PVEUuxjTvlrB0Wf0gZltoaxSpbThPD4pX27OhrVCvcsFhvZW4zZScB7eXW5TXVVs2zsKuoE0J5JlTj0FBVWtd/2HxjagLz9Gg3tvQzDRt6trU+J3moafVX7mzyXcWjqjT9KWHtHOnKQh6J+EJhO/bE1PUPlbNv9o97W2cfpElZoaeKtBQIMguBforqtDti2K9i6EH3WRBVqqjnJlg1Efir584Ff8jeVtE08gF3ZPuxAxgAHasJ6yGe6XBzDbTphytHUeZ4Gfetk6OvKvI+KPjKtC0NfV6V9VPRt49JsX1egDUBfSjzgT+vnIVfJB8SdBAsP46ObPB2PD80Lh7+ID8u7MD6qSv1aahq6jXmpwzRM1ZdKboxbw8BKUCuSnV2jc0/zWAAnM7hxTelRavGyAHi3IrvzatHunqiDi+yOIss9bx1lXtnTnHcyyPer2eGt4TX+2lbXPaeG1+9dqxPLWOc1PM3TnTIyyZchIjKNgOeqyBSIxrSQ+J/JC7mTX4YA00lkcfmYt4zVeV7LzyoK47tZFdbniwnQWW4Luqtx0ZoXv3KpsYxxEwxEdJDlrFqqXEa+l0HAt3tecRnFbUIeaRKQ8GleyLuL1y4IHdVvhN6g+C90cmGlTK59g05RIwtTbRucp6mRscaPuk+oBkRi0a2/rSnNtf5CCU1+AQ== \ No newline at end of file diff --git a/docs/java/concurrent/images/interview-questions/jmm.png b/docs/java/concurrent/images/interview-questions/jmm.png new file mode 100755 index 0000000000000000000000000000000000000000..782ff7e7d8f5b1471bdca0c254bb7248137d1dca Binary files /dev/null and b/docs/java/concurrent/images/interview-questions/jmm.png differ diff --git a/docs/java/concurrent/images/interview-questions/jmm2.drawio b/docs/java/concurrent/images/interview-questions/jmm2.drawio new file mode 100644 index 0000000000000000000000000000000000000000..ee36a4dae9e62f820cba94f473c8c5ad80b41a33 --- /dev/null +++ b/docs/java/concurrent/images/interview-questions/jmm2.drawio @@ -0,0 +1 @@ +7Vpbk6MoGP01PHaXiKI+ahLnVls1u/2wM4+0EnXbSMaQTrK/fkEx3kgqvRN7Mj1TeQgckMs5fB98IkCz1f5dSdbpHyymOTCNeA/QHJgmtKAn/iRyqBHPc2ogKbNYVWqBh+xfqkBDodssppteRc5YzrN1H4xYUdCI9zBSlmzXr7Zkeb/XNUnoCHiISD5G/85intaoazot/p5mSdr0DLGa8Io0ldVMNimJ2a4DoQVAs5IxXqdW+xnNJXkNL/Vz4YnS48BKWvBLHjD9L1v7T/YXRvifT19D1/sQeHeqlWeSb9WE1WD5oWGgZNsiprIRCFCwSzNOH9YkkqU7obnAUr7KVfGSFVyJKIYj8lmez1jOyqotFBPqLiOBb3jJnminBEcufVzKkifKo1Q1p0ZHS073J6cNj2SKVUjZivLyIKqoB6yG/0OzJFV+18ppNljakRIhBRK1hJJj2y3LIqGIfgHp5psnHcKbIx1dm/Q+yRTGNnV0JHvYQQRPQbLdJxnBMckQa0iGk5FsjUleYODNgD8DC1smAkMmXAxcWyb8OfDckRCCE95nu89qwQo6kEBBJM+SQmQjwSEVeCAZzoQ791XBKotj2Y1W3nYBGBqzurp+7kA/jZFAQ2ckU8lnvzkbsfDN2Qj+bSMv0M+7NRtxNPI5IPBBEMqE7wI3gCO1RMPixHqK08v38uWS4ki7l8eO92hM4qacwV7uaCQwNRK4U0ngXiDB2HP9xBJY7q1JAK8dOIzIRBh5KB7TH4b+3Apf4cxq22OSj9jrbBVQEyksLBC4IAh+bxHqAYTsvm4643jVLQJqYg2plg3EziD184Ff6xdK2RYecB2ZPm1AxgUG1KX1lM0MtbiG2QxOWFhzwvI07FuTsa8LQt4q+8i0box9TQzxZtm3jVtb+7rg4gL2JeIBP2wjkZ9SD+j2twLkXqaHPZkeumjh19HD8m5ND03oMIoTitiXFwfy+JOTzSarz/qk5GP4TNTQ45zGCX1QXbCSpyxhBckXLRrQfca/KDVl+qtM39sqN993iuYHlamHLts+r4+YHtuWET1HTHO3QsqE8jMVHb3g3TPyGUFLmhOePffHq1NZ9fCZZWImx/U0CIPw0I/W01QPmZ2rkEE7wysBb9BOzcKoHaE/OXSqrWWFzenhmsPdwX7JqJorsHa91/23q//I/3dcRRinHJR8GyUc1Ax4jnJQgUiEFeJ/JM/knbyZAybOZYzxWPaMCH/bymutyijuNpVV+KICxOt9tW6bcpFKqn/Z1Vy6uoUI3o0qqlFd1d3IF2MI+PbIWm8jxsnJI80DEj0lFT7svHUNEKt8xwMH1a9qkwvrYLLvOzRFqCTi194SO75d64ZKrsZ+4VQO2bzgPcKPdcjw3jDMvlO2rbNuWWY+0zITDMl1NY2r/lEu2LYGTs34nz4YD87OpoHum28DruyHnWGIqhbZqaEN65uG9T2eWGTbW/66evutBFr8Bw== \ No newline at end of file diff --git a/docs/java/concurrent/images/interview-questions/jmm2.png b/docs/java/concurrent/images/interview-questions/jmm2.png new file mode 100755 index 0000000000000000000000000000000000000000..40341b1bf10bd51c10626f3108b87b1184cc1212 Binary files /dev/null and b/docs/java/concurrent/images/interview-questions/jmm2.png differ diff --git a/docs/java/concurrent/images/interview-questions/synchronized-get-lock-code-block.drawio b/docs/java/concurrent/images/interview-questions/synchronized-get-lock-code-block.drawio new file mode 100644 index 0000000000000000000000000000000000000000..6c8c150c7cae93c3b9ac5b21e155130c2f3252c9 --- /dev/null +++ b/docs/java/concurrent/images/interview-questions/synchronized-get-lock-code-block.drawio @@ -0,0 +1 @@ +7VpZc6M4EP41qtp9IAWIQzwax5mp2Z3a1E7VXm8yCMMEI4/AsT2/fiUhbuw4jh1njspDoLt19fV1CwM4XW7fMbyKP9KQpMDUwy2At8A0DUN3+D9B2ZUUz3NLwoIloRJqCJ+Sr0QRdUVdJyHJO4IFpWmRrLrEgGYZCYoODTNGN12xiKbdVVd4QQaETwFOh9S/k7CISyoy3Yb+niSLuFrZcLySs8SVsDpJHuOQblokOANwyigtyqfldkpSobxKL+W4uz3cemOMZMUxA7TdwzbJqMc+3G/md5a/+vJ5p6lj5MWuOjAJ+fnVK2VFTBc0w+msofqMrrOQiFl1/tbI/E7pihMNTvxMimKnjInXBeWkuFimiltrQozPH0gRxIozPJM6Zk7XLCAHDlL5BmYLUhyQs0o5ccrWAkpj7whdkoLtuAAjKS6Sx64XYOVMi1quHnpPE75lU1eOD5FZDlFuDy29O0W5UTWqsRp/aG2jIUlbPsOuasOPOF2rIwDTSQuh7xXORLykOC+34nxZCxf0l6G2SnEimPyRbLlc2HA7TlIR53Sr5cnXJFsAOOESc8pCwjRO5i/loICmlJVctpj/YnuCY/JD6U7z6KJf6wERzQotwssk3ZXD+HJ4uZJMCC3pf3PKXapPrmfLcZZrOWFJ1J00l/4opuQutm0fzVnI/zMHIA9MXDBDYGIANK10xk1Qqk0JdlWZr7hBgpgEDx3lRDjNSUeB4zrHCdPyH1fpSpcBR45Tj7vCYVjz9RvTZmQpn9TD6Hb0G6/NVdMyHCbrvJ5JSvS3vKRZUlCRoghreUh5gu6pBo7TS7ZNKhXZbxMnBfm0wjLRbTieHps2oyRNp6XN+awwiiIzCIRQwegDaXFCZ+7YzqFE+0hYQbYHU6Pimp7VTXEV0G0anDRcBf9xCyMdfX827eTB5yY953sBsyuBlAtfGaSuYjBuDbb7R4y/sSyvIvzLCZp+oztuRbndqjXKt516E2lEzW2gg/aX4+55SuR6IkxJvNgp2hXOb/BP/4/1+/Tjf7O/6OL+1k5m6LWcxzHRSc4zYQzvWmIrIZDvX8dGemcd20bdMvcJeeToB+Uhgofk+UO547N6vvVUeTbEwW8J02ce4OCADFlIzUQtxUsrzwa+DmY28HiNhSSFc+8kRQcTB8ws4CPgT/Sj0TOmy7lA66eQ8/iY7SFpiAmKRpHUCRCZR2dCUmTf2F0n10ew1INDLDUM+0Jg6g1dtDZZ3xD8nEUPFTv6ymhGespVJJwmi4y/BmU1BX2htYS33xPFWCZhKPP+mIm7WHC8lc9gM9irfhx7aLGq52sbzLxU8VNdmHQMVoXWT4OZttnDEXhtg8FrVD9n0PnTdzHmdepXz7hY/TpaaV3dghKVQ5zHdQs5qviXWPHsRjO8bhy6/Xbw0k2HOZInj6lXbIAmYKIbA5s/q4nvW++NN/XuSJZ83abecEdxDdlgMpUl4xR4rqTcAZ8/3EnK5AN+xO/Et4OqmJyz0bK6V9AaDi9oZSU7qGn5UrfAmwof4S0GX79aqlxGOAoEE/uNYm2K5yT1cfCwkPT+4i1UcNR7y8N8+SfnLHjsU7G2Bi+B0lYPpR1nxP/QCEz3U/8p/jee5M23kORPy+vjBwKDe4T9nxBekP5fpvVh0Ks4FpoB9RX3bTtSIZxbttW9c49w0A34quntN7j7Lqb3NuRHtsK2SBJIAsnEBWj/1XBNLk/4ujfGKCDj4DJHtmU3HjiI5BEfPBpcDPcVweXQXdl34GYu8H0BQKJw4TB19wO7GdS7bla3BVdzM2PEz0QZMZMViyxdPKdVhToAIdG5lzWn9w1cuJhnsp3daw5GblWMS3Xp46YbFnTfSo93/iv/Kmhq63g3vevHPc3bk7f0gy6wLGNe/PVg8JXizLf74z7jPC/ceWXAmwvZffrW220hLhDujvvm4h3tLQn4AliUBDFmuaqcKxxeF5GGTgD33kcd9d2l+vcrGP+QE5P0kQgrtvi9CqHFKBcVnIyyJU5bvI3SqGBauvrEk/LMRJjG9xzUP6pojxTOqCm/ErzatSpewn0mU7PWe5GcgvFKKOJzVbNKHxXmpizsrlgPnNc9q9bTlmmhUlGm5akHu9JZmOSrFCt9JVmaVCtFKcVFb/lhNTUMVlt89/A9GaOGvCFyeesPkNXE8ZFfrVQwP/Oe6AzBZvVu3qyxH2zYI8HW/+3a+YLN+wmutXV6iGjBk8EVom4BbPUNeCZwtaA5us6J4Mpfm1/DluLNb4rh7H8= \ No newline at end of file diff --git a/docs/java/concurrent/images/interview-questions/synchronized-get-lock-code-block.png b/docs/java/concurrent/images/interview-questions/synchronized-get-lock-code-block.png new file mode 100755 index 0000000000000000000000000000000000000000..df596f5ace04e252e7af395ad22e9a4b7fd9d7a5 Binary files /dev/null and b/docs/java/concurrent/images/interview-questions/synchronized-get-lock-code-block.png differ diff --git a/docs/java/concurrent/images/interview-questions/synchronized-release-lock-block.drawio b/docs/java/concurrent/images/interview-questions/synchronized-release-lock-block.drawio new file mode 100644 index 0000000000000000000000000000000000000000..fb244f533590a0dd1e3e59a0b245a7d111bcc43f --- /dev/null +++ b/docs/java/concurrent/images/interview-questions/synchronized-release-lock-block.drawio @@ -0,0 +1 @@ +7Vrrj6M2EP9rLLUfWPHGfIRsdquqV121Unv96IAhdAnOGZJN7q+vDYZgcF7bPLa600kXMzN+zXhmfh4vsCaLzTNFy/knEuMcmHq8AdYjME3D0F32wynbhuL7XkNIaRYLoR3hJfuGBVEX1FUW41ISrAjJq2wpEyNSFDiqJBqilLzJYgnJ5VmXKMUjwkuE8jH1ryyu5g0Vmt6O/gvO0nk7s+H6DWeBWmGxk3KOYvLWI1lTYE0oIVXTWmwmOOfKa/XS9Hvaw+0WRnFRndIhXWkpWr9Y+R9f9LX/p7kw0kSzmlHWKF+JDQPTzdl4YblEBddrjspGhe7XFV9quIi1ZY4yzmRNvGFy8Y7LN1pthfZa4oxstDL7lhUpsAImMSM0xlRjZPbRdIpITmjDpensJ8fnHHPC/nd3TQ/+3HVISFFpCVpk+bbpxqZDi2XNtCyb/VIyIxUZkbvRSlSUWolplsiDlvUh5EMy9W76W3PT+nfqAuiDwANTCAIDwEmrM6b8Rm1CUFZluWQGieY4epWUk6C8xJIC1TpHGdXK71fpQpcRizDv3e4SxXHH1x9Mh+JF3RIN5XL0B7/PFcNSFGershuplhgueUGKrCIUb7Kqd0CaDcibGp0bU9qiScmqiDH3Y4Ox3+ZZhV+WKOLcNxZ2GW1eLXLB7uIMX3H5iqtoLjhJlueTxuRsVCtJEjOKuFBFySvucWJ35jput5J+jBFhZ41phTc9kog5z5gscEW3TERwTd9uuogEYLXx8G0XTg1PZIl5L5S6Qg6JCJ52Q++CHGuIOHdGzHNH+sUxi/nik9BqTlJSoHy6o4Y7C3Ct7mR+I2QptPsPrqqtSGBoxXzgRKvs1XFJVjTCBzYCGzm++oOWoDhHVbaWM5pKraLrZ5KxpXQWtKApWdCzBpapEE1xJXoNjNMt4/328u5hL2YMuv3C+z94htsS/hYD1h+PG+lrK754/BDDGvCg5et+n1ksZBrCVEj85+PQWOOAnGHd5ty4JnzXuQkoRdue2JILlPvncaAuzeM4UAZCR+Shqx+UH57/c+V9Q5JnjWaHF3USeAzIjTPm/yn7M8jlM7D1BKYO8HUQuGBqgxCCMABTH7AUAw0w9YAfAGjX+CwEgVP3mnCsxoAaMzp0Tk64c7KY8fx+LNme7uyD5BsjDBNl8nUjiGfJhZIvdB4c2Tl0Rfr1rXH6NQznSvnXHx/VzrxDQ7B9VoNEKumrIAUeKFeQUJ6lBfuMmPZ4cA251jJ2sQsEY5HFcZ0rVCaW88fpVr6AzawBYHKdscVsfWww81p4qb2KSwZr3fCHwUzHHOQf694GM0ZmuQFiuoDOj0Icw7wP5G1T+K0gb7tPyeW6PMci5ZQXHnjUdECo197ogwDyBvQAfBofgLOukD1T1mn6g18pPYXD3fZKaSjqaAyOhCFgqZWb6RH44+R2I5vACKttMoOO7Ry8c7zfJp3H3M8mjjJtMRAYTGr0OAG+V1OeQMgaTzUl+BWt0TMvOrdYcUaV6HmAWw2X4dYasI6gK5vqkePQDoS2UzXTcOe1OFr9mKk0RzOchyh6TWv6cPJe0HfFd++EhfW/esyKxWPC59asqyRhQ07CJlScP6jIwsPI/p7z52eh9vwVbtJn73NQhL87Efmk3SUJH0u6g8SpUPrVc2l3AzmSS48OZMHBQA18uERSVhrUujOqMvUzzCiDKeV+7JuY2xrC3MtBp/27UhZCuCpB9+jx2A/VljWzHVt+hUlQJEf8trgxLGTse6rYW3g5seTh8CwBa3QXeLyicfiViZGbHd72EeFUdDEK5SfFnj3owvBuiC6Ux0wBLs6st+ldVazXOqfYNsf5GvO0rqy37S+uSbxmlZxZELpAucx+E6rkfLtZZ83MWczCVGNbjboHtUF/jl40AUQ4W2ARiZ2xA1mI4ftLq5kVZT6WsEHb4QvcCbwRGsuz97vPOrSiDXRu2rDTtWnvqpwsKe00H2flMkdC61mRZ72Jk5ygqr+gsdv69RUsqGE/g37T2n8Z4qurkKFRX9y6SmV7pzuxLikg4ZlXhQs4oO3L8MpWveI5CnhlX8sB7/KKN9RsjMp5F1LvhrDswYOGbfkPg+Lt6RhLDrT20H57MNa5bza2ZSrnudQbifLIwB9HptW/MfBnb5goTz0wo1rMcKArg3LVY8I4AnelMxdAyCvX/NofqGoyH+PSfYUI7gwMrnhVMK5VpVbfj/WR8r9bd3Rb7NpZ590RfPi6fapDnhvBR6/77g0iePuycaq7M+Rlc8zFkZf9cWtsV3B317udv7PP3Z+xNqbe/TGwNf0X \ No newline at end of file diff --git a/docs/java/concurrent/images/interview-questions/synchronized-release-lock-block.png b/docs/java/concurrent/images/interview-questions/synchronized-release-lock-block.png new file mode 100755 index 0000000000000000000000000000000000000000..7123b2e6e1ba7e096972e83a52011bf1cf626c45 Binary files /dev/null and b/docs/java/concurrent/images/interview-questions/synchronized-release-lock-block.png differ diff --git a/docs/java/concurrent/images/java-thread-pool-summary/CachedThreadPool-execute.png b/docs/java/concurrent/images/java-thread-pool-summary/CachedThreadPool-execute.png new file mode 100644 index 0000000000000000000000000000000000000000..284c57b06f2dce19367219817c0e45c8a0c5a416 Binary files /dev/null and b/docs/java/concurrent/images/java-thread-pool-summary/CachedThreadPool-execute.png differ diff --git "a/docs/java/concurrent/images/java-thread-pool-summary/Executors\345\267\245\345\205\267\347\261\273.png" "b/docs/java/concurrent/images/java-thread-pool-summary/Executors\345\267\245\345\205\267\347\261\273.png" new file mode 100644 index 0000000000000000000000000000000000000000..5ef33155973951fbcf94a6132d000be22a525040 Binary files /dev/null and "b/docs/java/concurrent/images/java-thread-pool-summary/Executors\345\267\245\345\205\267\347\261\273.png" differ diff --git "a/docs/java/concurrent/images/java-thread-pool-summary/Executor\346\241\206\346\236\266\347\232\204\344\275\277\347\224\250\347\244\272\346\204\217\345\233\276.png" "b/docs/java/concurrent/images/java-thread-pool-summary/Executor\346\241\206\346\236\266\347\232\204\344\275\277\347\224\250\347\244\272\346\204\217\345\233\276.png" new file mode 100644 index 0000000000000000000000000000000000000000..c6d135b6c525dca2f8651397c45f36d41434b09c Binary files /dev/null and "b/docs/java/concurrent/images/java-thread-pool-summary/Executor\346\241\206\346\236\266\347\232\204\344\275\277\347\224\250\347\244\272\346\204\217\345\233\276.png" differ diff --git a/docs/java/concurrent/images/java-thread-pool-summary/FixedThreadPool.png b/docs/java/concurrent/images/java-thread-pool-summary/FixedThreadPool.png new file mode 100644 index 0000000000000000000000000000000000000000..b41a6fb9f5e764066a87d8401de843291140dc33 Binary files /dev/null and b/docs/java/concurrent/images/java-thread-pool-summary/FixedThreadPool.png differ diff --git "a/docs/java/concurrent/images/java-thread-pool-summary/ScheduledThreadPoolExecutor\346\211\247\350\241\214\345\221\250\346\234\237\344\273\273\345\212\241\346\255\245\351\252\244.png" "b/docs/java/concurrent/images/java-thread-pool-summary/ScheduledThreadPoolExecutor\346\211\247\350\241\214\345\221\250\346\234\237\344\273\273\345\212\241\346\255\245\351\252\244.png" new file mode 100644 index 0000000000000000000000000000000000000000..a4534876e974340c21187399cf4c4a0ad16a38ba Binary files /dev/null and "b/docs/java/concurrent/images/java-thread-pool-summary/ScheduledThreadPoolExecutor\346\211\247\350\241\214\345\221\250\346\234\237\344\273\273\345\212\241\346\255\245\351\252\244.png" differ diff --git "a/docs/java/concurrent/images/java-thread-pool-summary/ScheduledThreadPoolExecutor\346\234\272\345\210\266.png" "b/docs/java/concurrent/images/java-thread-pool-summary/ScheduledThreadPoolExecutor\346\234\272\345\210\266.png" new file mode 100644 index 0000000000000000000000000000000000000000..40bd4bb759f6b85c7dc574202462a2b4697e8223 Binary files /dev/null and "b/docs/java/concurrent/images/java-thread-pool-summary/ScheduledThreadPoolExecutor\346\234\272\345\210\266.png" differ diff --git a/docs/java/concurrent/images/java-thread-pool-summary/SingleThreadExecutor.png b/docs/java/concurrent/images/java-thread-pool-summary/SingleThreadExecutor.png new file mode 100644 index 0000000000000000000000000000000000000000..4fe717ca196b92ed7b13a94f2368f4f208d97750 Binary files /dev/null and b/docs/java/concurrent/images/java-thread-pool-summary/SingleThreadExecutor.png differ diff --git "a/docs/java/concurrent/images/java-thread-pool-summary/threadpoolexecutor\346\236\204\351\200\240\345\207\275\346\225\260.png" "b/docs/java/concurrent/images/java-thread-pool-summary/threadpoolexecutor\346\236\204\351\200\240\345\207\275\346\225\260.png" new file mode 100644 index 0000000000000000000000000000000000000000..6e3c7082eedf987b3a247caaf3fb81c752c15676 Binary files /dev/null and "b/docs/java/concurrent/images/java-thread-pool-summary/threadpoolexecutor\346\236\204\351\200\240\345\207\275\346\225\260.png" differ diff --git "a/docs/java/concurrent/images/java-thread-pool-summary/\344\273\273\345\212\241\347\232\204\346\211\247\350\241\214\347\233\270\345\205\263\346\216\245\345\217\243.png" "b/docs/java/concurrent/images/java-thread-pool-summary/\344\273\273\345\212\241\347\232\204\346\211\247\350\241\214\347\233\270\345\205\263\346\216\245\345\217\243.png" new file mode 100644 index 0000000000000000000000000000000000000000..9ee5d1422afb73fe0ddc330a1c5b9d75f06a0cb1 Binary files /dev/null and "b/docs/java/concurrent/images/java-thread-pool-summary/\344\273\273\345\212\241\347\232\204\346\211\247\350\241\214\347\233\270\345\205\263\346\216\245\345\217\243.png" differ diff --git "a/docs/java/concurrent/images/java-thread-pool-summary/\345\233\276\350\247\243\347\272\277\347\250\213\346\261\240\345\256\236\347\216\260\345\216\237\347\220\206.png" "b/docs/java/concurrent/images/java-thread-pool-summary/\345\233\276\350\247\243\347\272\277\347\250\213\346\261\240\345\256\236\347\216\260\345\216\237\347\220\206.png" new file mode 100644 index 0000000000000000000000000000000000000000..f2b8ed15c4faf9ba2a74b414ab5c0a5631754655 Binary files /dev/null and "b/docs/java/concurrent/images/java-thread-pool-summary/\345\233\276\350\247\243\347\272\277\347\250\213\346\261\240\345\256\236\347\216\260\345\216\237\347\220\206.png" differ diff --git "a/docs/java/concurrent/images/java-thread-pool-summary/\347\272\277\347\250\213\346\261\240\345\220\204\344\270\252\345\217\202\346\225\260\344\271\213\351\227\264\347\232\204\345\205\263\347\263\273.png" "b/docs/java/concurrent/images/java-thread-pool-summary/\347\272\277\347\250\213\346\261\240\345\220\204\344\270\252\345\217\202\346\225\260\344\271\213\351\227\264\347\232\204\345\205\263\347\263\273.png" new file mode 100644 index 0000000000000000000000000000000000000000..2534b55267ac52dc78b6d645eb64517ffb5a74b9 Binary files /dev/null and "b/docs/java/concurrent/images/java-thread-pool-summary/\347\272\277\347\250\213\346\261\240\345\220\204\344\270\252\345\217\202\346\225\260\344\271\213\351\227\264\347\232\204\345\205\263\347\263\273.png" differ diff --git a/docs/java/concurrent/images/thread-local/1.png b/docs/java/concurrent/images/thread-local/1.png new file mode 100644 index 0000000000000000000000000000000000000000..dedb437bd95046ae997b159e39629457a892ab3f Binary files /dev/null and b/docs/java/concurrent/images/thread-local/1.png differ diff --git a/docs/java/concurrent/images/thread-local/10.png b/docs/java/concurrent/images/thread-local/10.png new file mode 100644 index 0000000000000000000000000000000000000000..9841d74d570c2903be03bca2bfd6a0029161c62a Binary files /dev/null and b/docs/java/concurrent/images/thread-local/10.png differ diff --git a/docs/java/concurrent/images/thread-local/11.png b/docs/java/concurrent/images/thread-local/11.png new file mode 100644 index 0000000000000000000000000000000000000000..7146c9b36218cffb039c26388f6b99df9ac56a69 Binary files /dev/null and b/docs/java/concurrent/images/thread-local/11.png differ diff --git a/docs/java/concurrent/images/thread-local/12.png b/docs/java/concurrent/images/thread-local/12.png new file mode 100644 index 0000000000000000000000000000000000000000..f3c8653f8c8adf86fecf20fd56aaff0471000d18 Binary files /dev/null and b/docs/java/concurrent/images/thread-local/12.png differ diff --git a/docs/java/concurrent/images/thread-local/13.png b/docs/java/concurrent/images/thread-local/13.png new file mode 100644 index 0000000000000000000000000000000000000000..7762127c71c74bd9cc75a1ab59a2c31ebc4f0af5 Binary files /dev/null and b/docs/java/concurrent/images/thread-local/13.png differ diff --git a/docs/java/concurrent/images/thread-local/14.png b/docs/java/concurrent/images/thread-local/14.png new file mode 100644 index 0000000000000000000000000000000000000000..1076d862e3120caf93b03fad97f3745c26a244f3 Binary files /dev/null and b/docs/java/concurrent/images/thread-local/14.png differ diff --git a/docs/java/concurrent/images/thread-local/15.png b/docs/java/concurrent/images/thread-local/15.png new file mode 100644 index 0000000000000000000000000000000000000000..736f3008e7667544b723e570a4edbd80127df7ef Binary files /dev/null and b/docs/java/concurrent/images/thread-local/15.png differ diff --git a/docs/java/concurrent/images/thread-local/16.png b/docs/java/concurrent/images/thread-local/16.png new file mode 100644 index 0000000000000000000000000000000000000000..e05352c52399560a10cb2acacda55bb72a3011d2 Binary files /dev/null and b/docs/java/concurrent/images/thread-local/16.png differ diff --git a/docs/java/concurrent/images/thread-local/17.png b/docs/java/concurrent/images/thread-local/17.png new file mode 100644 index 0000000000000000000000000000000000000000..e2c61f7732eaa9d725e2ecb85d840954ee56a971 Binary files /dev/null and b/docs/java/concurrent/images/thread-local/17.png differ diff --git a/docs/java/concurrent/images/thread-local/18.png b/docs/java/concurrent/images/thread-local/18.png new file mode 100644 index 0000000000000000000000000000000000000000..97457a27f121681f5b10d43a1a137f2fd43619a6 Binary files /dev/null and b/docs/java/concurrent/images/thread-local/18.png differ diff --git a/docs/java/concurrent/images/thread-local/19.png b/docs/java/concurrent/images/thread-local/19.png new file mode 100644 index 0000000000000000000000000000000000000000..ba9ede437a1b15f2d9962f61d4d28e41009c3361 Binary files /dev/null and b/docs/java/concurrent/images/thread-local/19.png differ diff --git a/docs/java/concurrent/images/thread-local/2.png b/docs/java/concurrent/images/thread-local/2.png new file mode 100644 index 0000000000000000000000000000000000000000..bb1ffac6d4280eec1304c3d9f931deeea19b48ad Binary files /dev/null and b/docs/java/concurrent/images/thread-local/2.png differ diff --git a/docs/java/concurrent/images/thread-local/20.png b/docs/java/concurrent/images/thread-local/20.png new file mode 100644 index 0000000000000000000000000000000000000000..9528b250fb50b03bce49d92dc6654e0c39cef02b Binary files /dev/null and b/docs/java/concurrent/images/thread-local/20.png differ diff --git a/docs/java/concurrent/images/thread-local/21.png b/docs/java/concurrent/images/thread-local/21.png new file mode 100644 index 0000000000000000000000000000000000000000..ee0b6728d11fafccecad8c2f22d879d50f80cdbb Binary files /dev/null and b/docs/java/concurrent/images/thread-local/21.png differ diff --git a/docs/java/concurrent/images/thread-local/22.png b/docs/java/concurrent/images/thread-local/22.png new file mode 100644 index 0000000000000000000000000000000000000000..0e4311c283e4c774fcb997d1f175febae62bac4c Binary files /dev/null and b/docs/java/concurrent/images/thread-local/22.png differ diff --git a/docs/java/concurrent/images/thread-local/23.png b/docs/java/concurrent/images/thread-local/23.png new file mode 100644 index 0000000000000000000000000000000000000000..f5438fcb5f65f865e30df4d752a92ffce64d71b0 Binary files /dev/null and b/docs/java/concurrent/images/thread-local/23.png differ diff --git a/docs/java/concurrent/images/thread-local/24.png b/docs/java/concurrent/images/thread-local/24.png new file mode 100644 index 0000000000000000000000000000000000000000..90889b1a4243bcceff317aaaa30bcb968d118c4b Binary files /dev/null and b/docs/java/concurrent/images/thread-local/24.png differ diff --git a/docs/java/concurrent/images/thread-local/25.png b/docs/java/concurrent/images/thread-local/25.png new file mode 100644 index 0000000000000000000000000000000000000000..935ca8dbeb180b79f6384aaaf8ff9358980a6f7d Binary files /dev/null and b/docs/java/concurrent/images/thread-local/25.png differ diff --git a/docs/java/concurrent/images/thread-local/26.png b/docs/java/concurrent/images/thread-local/26.png new file mode 100644 index 0000000000000000000000000000000000000000..d3816d258101310bf96947322f4f4d84288b9d12 Binary files /dev/null and b/docs/java/concurrent/images/thread-local/26.png differ diff --git a/docs/java/concurrent/images/thread-local/27.png b/docs/java/concurrent/images/thread-local/27.png new file mode 100644 index 0000000000000000000000000000000000000000..3589fb71aa287d0c6b8f06c37c301febe98efe1b Binary files /dev/null and b/docs/java/concurrent/images/thread-local/27.png differ diff --git a/docs/java/concurrent/images/thread-local/28.png b/docs/java/concurrent/images/thread-local/28.png new file mode 100644 index 0000000000000000000000000000000000000000..ecb9a0212ea686e33ee78d16c9aa6bd25d91919d Binary files /dev/null and b/docs/java/concurrent/images/thread-local/28.png differ diff --git a/docs/java/concurrent/images/thread-local/29.png b/docs/java/concurrent/images/thread-local/29.png new file mode 100644 index 0000000000000000000000000000000000000000..804f008959e793c73fcca77ab941e910f2dcc9ca Binary files /dev/null and b/docs/java/concurrent/images/thread-local/29.png differ diff --git a/docs/java/concurrent/images/thread-local/3.png b/docs/java/concurrent/images/thread-local/3.png new file mode 100644 index 0000000000000000000000000000000000000000..f6e4724bde913adbfc11e15c983c132acaaad6cc Binary files /dev/null and b/docs/java/concurrent/images/thread-local/3.png differ diff --git a/docs/java/concurrent/images/thread-local/30.png b/docs/java/concurrent/images/thread-local/30.png new file mode 100644 index 0000000000000000000000000000000000000000..e4584707e1720d8d9af8ac69feda8680e84d8c8b Binary files /dev/null and b/docs/java/concurrent/images/thread-local/30.png differ diff --git a/docs/java/concurrent/images/thread-local/31.png b/docs/java/concurrent/images/thread-local/31.png new file mode 100644 index 0000000000000000000000000000000000000000..3058afca72fa664a0728b700cc21ee903f395181 Binary files /dev/null and b/docs/java/concurrent/images/thread-local/31.png differ diff --git a/docs/java/concurrent/images/thread-local/4.png b/docs/java/concurrent/images/thread-local/4.png new file mode 100644 index 0000000000000000000000000000000000000000..0416e3fc27c5e47e6921a82ab987f3166f3ce461 Binary files /dev/null and b/docs/java/concurrent/images/thread-local/4.png differ diff --git a/docs/java/concurrent/images/thread-local/5.png b/docs/java/concurrent/images/thread-local/5.png new file mode 100644 index 0000000000000000000000000000000000000000..cfeb708ebf0a82950c39436063fa0cfe3590be5f Binary files /dev/null and b/docs/java/concurrent/images/thread-local/5.png differ diff --git a/docs/java/concurrent/images/thread-local/6.png b/docs/java/concurrent/images/thread-local/6.png new file mode 100644 index 0000000000000000000000000000000000000000..bb9208aa94f0a88e9df2578a3b64da536f1980a8 Binary files /dev/null and b/docs/java/concurrent/images/thread-local/6.png differ diff --git a/docs/java/concurrent/images/thread-local/7.png b/docs/java/concurrent/images/thread-local/7.png new file mode 100644 index 0000000000000000000000000000000000000000..bed724cd074e159232b9ea8b2368b6223563853e Binary files /dev/null and b/docs/java/concurrent/images/thread-local/7.png differ diff --git a/docs/java/concurrent/images/thread-local/8.png b/docs/java/concurrent/images/thread-local/8.png new file mode 100644 index 0000000000000000000000000000000000000000..b6da2aa37f558c606089ed7ea5a5605bd5bd49d3 Binary files /dev/null and b/docs/java/concurrent/images/thread-local/8.png differ diff --git a/docs/java/concurrent/images/thread-local/9.png b/docs/java/concurrent/images/thread-local/9.png new file mode 100644 index 0000000000000000000000000000000000000000..6429d04248353da59470f3ecf556e415a885cf62 Binary files /dev/null and b/docs/java/concurrent/images/thread-local/9.png differ diff --git a/docs/java/concurrent/images/thread-pool/19a0255a-6ef3-4835-98d1-a839d1983332.png b/docs/java/concurrent/images/thread-pool/19a0255a-6ef3-4835-98d1-a839d1983332.png new file mode 100644 index 0000000000000000000000000000000000000000..1797a14a9426743d79eb77e670d06bbfc8192879 Binary files /dev/null and b/docs/java/concurrent/images/thread-pool/19a0255a-6ef3-4835-98d1-a839d1983332.png differ diff --git a/docs/java/concurrent/images/thread-pool/1bc44c67-26ba-42ab-bcb8-4e29e6fd99b9.png b/docs/java/concurrent/images/thread-pool/1bc44c67-26ba-42ab-bcb8-4e29e6fd99b9.png new file mode 100644 index 0000000000000000000000000000000000000000..68ec405a0d1cf6cf5abf852c034a89f58bcd6e89 Binary files /dev/null and b/docs/java/concurrent/images/thread-pool/1bc44c67-26ba-42ab-bcb8-4e29e6fd99b9.png differ diff --git a/docs/java/concurrent/images/thread-pool/5b9b814d-722a-4116-b066-43dc80fc1dc4.png b/docs/java/concurrent/images/thread-pool/5b9b814d-722a-4116-b066-43dc80fc1dc4.png new file mode 100644 index 0000000000000000000000000000000000000000..7d28f577fe10b7efca2fe3419779c8de7d45c75b Binary files /dev/null and b/docs/java/concurrent/images/thread-pool/5b9b814d-722a-4116-b066-43dc80fc1dc4.png differ diff --git a/docs/java/concurrent/images/thread-pool/b6fd95a7-4c9d-4fc6-ad26-890adb3f6c4c.png b/docs/java/concurrent/images/thread-pool/b6fd95a7-4c9d-4fc6-ad26-890adb3f6c4c.png new file mode 100644 index 0000000000000000000000000000000000000000..ef000d07eb204b1116f25d98238f9dce07711963 Binary files /dev/null and b/docs/java/concurrent/images/thread-pool/b6fd95a7-4c9d-4fc6-ad26-890adb3f6c4c.png differ diff --git a/docs/java/concurrent/images/thread-pool/ddf22709-bff5-45b4-acb7-a3f2e6798608.png b/docs/java/concurrent/images/thread-pool/ddf22709-bff5-45b4-acb7-a3f2e6798608.png new file mode 100644 index 0000000000000000000000000000000000000000..f74fd2a2af3d5783accb00b6440e194f4f246405 Binary files /dev/null and b/docs/java/concurrent/images/thread-pool/ddf22709-bff5-45b4-acb7-a3f2e6798608.png differ diff --git "a/docs/java/concurrent/images/thread-pool/\347\272\277\347\250\213\346\261\240\344\275\277\347\224\250\344\270\215\345\275\223\345\257\274\350\207\264\346\255\273\351\224\201.drawio" "b/docs/java/concurrent/images/thread-pool/\347\272\277\347\250\213\346\261\240\344\275\277\347\224\250\344\270\215\345\275\223\345\257\274\350\207\264\346\255\273\351\224\201.drawio" new file mode 100644 index 0000000000000000000000000000000000000000..3a2c775adc788199932d87a448f45418eb3cf0eb --- /dev/null +++ "b/docs/java/concurrent/images/thread-pool/\347\272\277\347\250\213\346\261\240\344\275\277\347\224\250\344\270\215\345\275\223\345\257\274\350\207\264\346\255\273\351\224\201.drawio" @@ -0,0 +1 @@ +7Vpbj5s4GP01fkwFBgw8QkLaSl2p0qzU3acVA+ayJTglziTpr18bTLg5WaYThrQdaTRjf75gn/Md+7M9QFtuju8Lf5v8QUKcAaiER6CtAISqqiD2h1tOlcWyYWWIizQUlRrDQ/odC6MirPs0xLtORUpIRtNt1xiQPMcB7dj8oiCHbrWIZN2vbv0YDwwPgZ8NrV/SkCZiFtBs7B9wGif1l1VkVyUbv64sZrJL/JAcWibNA9qyIIRWqc1xiTMOXo1L1W59ofQ8sALndEyDKF4s0OLpz4do5cF/PirF8tNuoVW9PPnZXkxYDJaeagQKss9DzDtRgeYekpTih60f8NID45zZErrJRHGUZtmSZKQo22qhj60oYPYdLchX3CpBgYUfI1YynIaY2RMuKD62TGJa7zHZYFqcWBVRaguEhYsZInto+FJrEpIWV0jYfOEi8bnjBkWWEEA+A1R9WlCjCKNACmpo2o+KMgmoqj43qsaNUb09RlCbGyM0xMgzgGsClyXYbxdYa+BZwPK4kRWxrI24xWVpHXgIuA5g02KVbae06LwV++GVHeCoA9AZVrSLbNcvc5LjnhMLk5+lcc6yAWMAM7vLkU/Z2uuIgk0ahvwzUiobsrnHRySnYvdQ0W3YPe9Bgl5Twq4pYRdOxa45il0ELBs4JieVsWUteR3HKxNvpA5IVdHcrFoSVhGwl8Bx3qT6g6xKY4BXZdWW7FYo4+jvtn7eoQV92/MYsMRlsSuBcVgFBsmxKWSpuPzLhe4Ad80TDnMPt/QEFTiKzDfWwF0Cy+IWVsG1ygVjDSxN3o/NSpXSkVhXTl63t+uxMyiq4YvB9B2MAcMC80tu0A5pej7QjxsNbIW6LMSx4KOGbuQ1RtdpdDh0GmgZQ6dR7am8RhLT4JCdR0SWFDQhMcn9zGusPXU1dT4RshVw/4spPQm8/T0lXTIYgsXpL9G+zPzNM++MOrs6tgtXp+cKeUf2RYCvzFutj3Z+EWN6raKgg6NyleICZz5Nn7qnuNvzpb3xdZ0vdFd81ePubLYmXyBdNNw/hxvoxGfhCXZGo78zyuKdVz2jQP031QwcqxnrrjQDjTn4mgN3+65wr8f9ghBSRZdCyAsrHhwb6N3/pWB/4dNnvxaE6Ddd+LSRAqzZuBMB1nf8b3xdAki9K75U2WPGxAtm/usumGj2SFEd8ZCC89Dhz3zgfFUV+rvkDHQLVG7/7FOKi7y0QEU7Q1o/7cGukKBxDdr/dfsWcIYEt9o2Wh3iC59JykbS8Ibsd0aXuf6tViV50a4hZdiV2XUBQ+91VC0Jg45Kds8TfwHhsjeeSl+clVEK1pmCS+kORGwAZ1Veig3OeQu1JePqSxPIeMS7XXsR128ja1PpHQCV2WUteaV67jqty9fpKxRPE9pOQJCmzk6Q5EliaoJgR4OTbaWv83bep1SfX3Mvf4/4AUp/Gs0Zs2uu/thrEpT/yppD81MquWyentKfRnOm5LntVgSxbPOPdVV02vx7oub9Bw== \ No newline at end of file diff --git "a/docs/java/concurrent/images/thread-pool/\347\272\277\347\250\213\346\261\240\344\275\277\347\224\250\344\270\215\345\275\223\345\257\274\350\207\264\346\255\273\351\224\201.png" "b/docs/java/concurrent/images/thread-pool/\347\272\277\347\250\213\346\261\240\344\275\277\347\224\250\344\270\215\345\275\223\345\257\274\350\207\264\346\255\273\351\224\201.png" new file mode 100644 index 0000000000000000000000000000000000000000..cde5c8cf4f7ea34c6ca8df272f217b3b5acc43cd Binary files /dev/null and "b/docs/java/concurrent/images/thread-pool/\347\272\277\347\250\213\346\261\240\344\275\277\347\224\250\344\270\215\345\275\223\345\257\274\350\207\264\346\255\273\351\224\201.png" differ diff --git "a/docs/java/concurrent/images/threadlocal\346\225\260\346\215\256\347\273\223\346\236\204.png" "b/docs/java/concurrent/images/threadlocal\346\225\260\346\215\256\347\273\223\346\236\204.png" new file mode 100644 index 0000000000000000000000000000000000000000..a7470446844dfb798ec1c9aee92a0493b523bf56 Binary files /dev/null and "b/docs/java/concurrent/images/threadlocal\346\225\260\346\215\256\347\273\223\346\236\204.png" differ diff --git "a/Java\347\233\270\345\205\263/Multithread/\345\271\266\345\217\221\345\256\271\345\231\250\346\200\273\347\273\223.md" b/docs/java/concurrent/java-concurrent-collections.md similarity index 30% rename from "Java\347\233\270\345\205\263/Multithread/\345\271\266\345\217\221\345\256\271\345\231\250\346\200\273\347\273\223.md" rename to docs/java/concurrent/java-concurrent-collections.md index 96a9fe23176c3c149edb17321c0632d32c0f7efe..bc467a878c304c5e40711a9334e59bc0508f4cf3 100644 --- "a/Java\347\233\270\345\205\263/Multithread/\345\271\266\345\217\221\345\256\271\345\231\250\346\200\273\347\273\223.md" +++ b/docs/java/concurrent/java-concurrent-collections.md @@ -1,52 +1,29 @@ +--- +title: Java 常见并发容器总结 +category: Java +tag: + - Java并发 +--- - +JDK 提供的这些容器大部分在 `java.util.concurrent` 包中。 -- [一 JDK 提供的并发容器总结](#一-jdk-提供的并发容器总结) -- [二 ConcurrentHashMap](#二-concurrenthashmap) -- [三 CopyOnWriteArrayList](#三-copyonwritearraylist) - - [3.1 CopyOnWriteArrayList 简介](#31-copyonwritearraylist-简介) - - [3.2 CopyOnWriteArrayList 是如何做到的？](#32-copyonwritearraylist-是如何做到的？) - - [3.3 CopyOnWriteArrayList 读取和写入源码简单分析](#33-copyonwritearraylist-读取和写入源码简单分析) - - [3.3.1 CopyOnWriteArrayList 读取操作的实现](#331-copyonwritearraylist-读取操作的实现) - - [3.3.2 CopyOnWriteArrayList 写入操作的实现](#332-copyonwritearraylist-写入操作的实现) -- [四 ConcurrentLinkedQueue](#四-concurrentlinkedqueue) -- [五 BlockingQueue](#五-blockingqueue) - - [5.1 BlockingQueue 简单介绍](#51-blockingqueue-简单介绍) - - [5.2 ArrayBlockingQueue](#52-arrayblockingqueue) - - [5.3 LinkedBlockingQueue](#53-linkedblockingqueue) - - [5.4 PriorityBlockingQueue](#54-priorityblockingqueue) -- [六 ConcurrentSkipListMap](#六-concurrentskiplistmap) -- [七 参考](#七-参考) +- **`ConcurrentHashMap`** : 线程安全的 `HashMap` +- **`CopyOnWriteArrayList`** : 线程安全的 `List`，在读多写少的场合性能非常好，远远好于 `Vector`。 +- **`ConcurrentLinkedQueue`** : 高效的并发队列，使用链表实现。可以看做一个线程安全的 `LinkedList`，这是一个非阻塞队列。 +- **`BlockingQueue`** : 这是一个接口，JDK 内部通过链表、数组等方式实现了这个接口。表示阻塞队列，非常适合用于作为数据共享的通道。 +- **`ConcurrentSkipListMap`** : 跳表的实现。这是一个 Map，使用跳表的数据结构进行快速查找。 - +## ConcurrentHashMap -## 一 JDK 提供的并发容器总结 +我们知道 `HashMap` 不是线程安全的，在并发场景下如果要保证一种可行的方式是使用 `Collections.synchronizedMap()` 方法来包装我们的 `HashMap`。但这是通过使用一个全局的锁来同步不同线程间的并发访问，因此会带来不可忽视的性能问题。 -JDK提供的这些容器大部分在 `java.util.concurrent` 包中。 +所以就有了 `HashMap` 的线程安全版本—— `ConcurrentHashMap` 的诞生。 +在 `ConcurrentHashMap` 中，无论是读操作还是写操作都能保证很高的性能：在进行读操作时(几乎)不需要加锁，而在写操作时通过锁分段技术只对所操作的段加锁而不影响客户端对其它段的访问。 -- **ConcurrentHashMap:** 线程安全的HashMap -- **CopyOnWriteArrayList:** 线程安全的List，在读多写少的场合性能非常好，远远好于Vector. -- **ConcurrentLinkedQueue:** 高效的并发队列，使用链表实现。可以看做一个线程安全的 LinkedList，这是一个非阻塞队列。 -- **BlockingQueue:** 这是一个接口，JDK内部通过链表、数组等方式实现了这个接口。表示阻塞队列，非常适合用于作为数据共享的通道。 -- **ConcurrentSkipListMap:** 跳表的实现。这是一个Map，使用跳表的数据结构进行快速查找。 +## CopyOnWriteArrayList -## 二 ConcurrentHashMap - -我们知道 HashMap 不是线程安全的，在并发场景下如果要保证一种可行的方式是使用 `Collections.synchronizedMap()` 方法来包装我们的 HashMap。但这是通过使用一个全局的锁来同步不同线程间的并发访问，因此会带来不可忽视的性能问题。 - -所以就有了 HashMap 的线程安全版本—— ConcurrentHashMap 的诞生。在ConcurrentHashMap中，无论是读操作还是写操作都能保证很高的性能：在进行读操作时(几乎)不需要加锁，而在写操作时通过锁分段技术只对所操作的段加锁而不影响客户端对其它段的访问。 - -关于 ConcurrentHashMap 相关问题，我在 [《这几道Java集合框架面试题几乎必问》](https://github.com/Snailclimb/JavaGuide/blob/master/Java%E7%9B%B8%E5%85%B3/%E8%BF%99%E5%87%A0%E9%81%93Java%E9%9B%86%E5%90%88%E6%A1%86%E6%9E%B6%E9%9D%A2%E8%AF%95%E9%A2%98%E5%87%A0%E4%B9%8E%E5%BF%85%E9%97%AE.md) 这篇文章中已经提到过。下面梳理一下关于 ConcurrentHashMap 比较重要的问题： - -- [ConcurrentHashMap 和 Hashtable 的区别](https://github.com/Snailclimb/JavaGuide/blob/master/Java%E7%9B%B8%E5%85%B3/%E8%BF%99%E5%87%A0%E9%81%93Java%E9%9B%86%E5%90%88%E6%A1%86%E6%9E%B6%E9%9D%A2%E8%AF%95%E9%A2%98%E5%87%A0%E4%B9%8E%E5%BF%85%E9%97%AE.md#concurrenthashmap-%E5%92%8C-hashtable-%E7%9A%84%E5%8C%BA%E5%88%AB) -- [ConcurrentHashMap线程安全的具体实现方式/底层具体实现](https://github.com/Snailclimb/JavaGuide/blob/master/Java%E7%9B%B8%E5%85%B3/%E8%BF%99%E5%87%A0%E9%81%93Java%E9%9B%86%E5%90%88%E6%A1%86%E6%9E%B6%E9%9D%A2%E8%AF%95%E9%A2%98%E5%87%A0%E4%B9%8E%E5%BF%85%E9%97%AE.md#concurrenthashmap%E7%BA%BF%E7%A8%8B%E5%AE%89%E5%85%A8%E7%9A%84%E5%85%B7%E4%BD%93%E5%AE%9E%E7%8E%B0%E6%96%B9%E5%BC%8F%E5%BA%95%E5%B1%82%E5%85%B7%E4%BD%93%E5%AE%9E%E7%8E%B0) - - - -## 三 CopyOnWriteArrayList - -### 3.1 CopyOnWriteArrayList 简介 +### CopyOnWriteArrayList 简介 ```java public class CopyOnWriteArrayList @@ -54,21 +31,21 @@ extends Object implements List, RandomAccess, Cloneable, Serializable ``` -在很多应用场景中，读操作可能会远远大于写操作。由于读操作根本不会修改原有的数据，因此对于每次读取都进行加锁其实是一种资源浪费。我们应该允许多个线程同时访问List的内部数据，毕竟读取操作是安全的。 +在很多应用场景中，读操作可能会远远大于写操作。由于读操作根本不会修改原有的数据，因此对于每次读取都进行加锁其实是一种资源浪费。我们应该允许多个线程同时访问 `List` 的内部数据，毕竟读取操作是安全的。 -这和我们之前在多线程章节讲过 `ReentrantReadWriteLock` 读写锁的思想非常类似，也就是读读共享、写写互斥、读写互斥、写读互斥。JDK中提供了 `CopyOnWriteArrayList` 类比相比于在读写锁的思想又更进一步。为了将读取的性能发挥到极致，`CopyOnWriteArrayList` 读取是完全不用加锁的，并且更厉害的是：写入也不会阻塞读取操作。只有写入和写入之间需要进行同步等待。这样一来，读操作的性能就会大幅度提升。**那它是怎么做的呢？** +这和我们之前在多线程章节讲过 `ReentrantReadWriteLock` 读写锁的思想非常类似，也就是读读共享、写写互斥、读写互斥、写读互斥。JDK 中提供了 `CopyOnWriteArrayList` 类比相比于在读写锁的思想又更进一步。为了将读取的性能发挥到极致，`CopyOnWriteArrayList` 读取是完全不用加锁的，并且更厉害的是：写入也不会阻塞读取操作。只有写入和写入之间需要进行同步等待。这样一来，读操作的性能就会大幅度提升。**那它是怎么做的呢？** -### 3.2 CopyOnWriteArrayList 是如何做到的？ +### CopyOnWriteArrayList 是如何做到的？ - `CopyOnWriteArrayList` 类的所有可变操作（add，set等等）都是通过创建底层数组的新副本来实现的。当 List 需要被修改的时候，我并不修改原有内容，而是对原有数据进行一次复制，将修改的内容写入副本。写完之后，再将修改完的副本替换原来的数据，这样就可以保证写操作不会影响读操作了。 +`CopyOnWriteArrayList` 类的所有可变操作（add，set 等等）都是通过创建底层数组的新副本来实现的。当 List 需要被修改的时候，我并不修改原有内容，而是对原有数据进行一次复制，将修改的内容写入副本。写完之后，再将修改完的副本替换原来的数据，这样就可以保证写操作不会影响读操作了。 -从 `CopyOnWriteArrayList` 的名字就能看出`CopyOnWriteArrayList` 是满足`CopyOnWrite` 的ArrayList，所谓`CopyOnWrite` 也就是说：在计算机，如果你想要对一块内存进行修改时，我们不在原有内存块中进行写操作，而是将内存拷贝一份，在新的内存中进行写操作，写完之后呢，就将指向原来内存指针指向新的内存，原来的内存就可以被回收掉了。 +从 `CopyOnWriteArrayList` 的名字就能看出 `CopyOnWriteArrayList` 是满足 `CopyOnWrite` 的。所谓 `CopyOnWrite` 也就是说：在计算机，如果你想要对一块内存进行修改时，我们不在原有内存块中进行写操作，而是将内存拷贝一份，在新的内存中进行写操作，写完之后呢，就将指向原来内存指针指向新的内存，原来的内存就可以被回收掉了。 -### 3.3 CopyOnWriteArrayList 读取和写入源码简单分析 +### CopyOnWriteArrayList 读取和写入源码简单分析 -#### 3.3.1 CopyOnWriteArrayList 读取操作的实现 +#### CopyOnWriteArrayList 读取操作的实现 -读取操作没有任何同步控制和锁操作，理由就是内部数组 array 不会发生修改，只会被另外一个 array 替换，因此可以保证数据安全。 +读取操作没有任何同步控制和锁操作，理由就是内部数组 `array` 不会发生修改，只会被另外一个 `array` 替换，因此可以保证数据安全。 ```java /** The array, accessed only via getArray/setArray. */ @@ -88,7 +65,7 @@ implements List, RandomAccess, Cloneable, Serializable #### 3.3.2 CopyOnWriteArrayList 写入操作的实现 -CopyOnWriteArrayList 写入操作 add() 方法在添加集合的时候加了锁，保证了同步，避免了多线程写的时候会 copy 出多个副本出来。 +`CopyOnWriteArrayList` 写入操作 `add()`方法在添加集合的时候加了锁，保证了同步，避免了多线程写的时候会 copy 出多个副本出来。 ```java /** @@ -113,41 +90,49 @@ CopyOnWriteArrayList 写入操作 add() 方法在添加集合的时候加了锁 } ``` -## 四 ConcurrentLinkedQueue +## ConcurrentLinkedQueue -Java提供的线程安全的 Queue 可以分为**阻塞队列**和**非阻塞队列**，其中阻塞队列的典型例子是 BlockingQueue，非阻塞队列的典型例子是ConcurrentLinkedQueue，在实际应用中要根据实际需要选用阻塞队列或者非阻塞队列。 **阻塞队列可以通过加锁来实现，非阻塞队列可以通过 CAS 操作实现。** +Java 提供的线程安全的 `Queue` 可以分为**阻塞队列**和**非阻塞队列**，其中阻塞队列的典型例子是 `BlockingQueue`，非阻塞队列的典型例子是 `ConcurrentLinkedQueue`，在实际应用中要根据实际需要选用阻塞队列或者非阻塞队列。 **阻塞队列可以通过加锁来实现，非阻塞队列可以通过 CAS 操作实现。** -从名字可以看出，`ConcurrentLinkedQueue`这个队列使用链表作为其数据结构．ConcurrentLinkedQueue 应该算是在高并发环境中性能最好的队列了。它之所有能有很好的性能，是因为其内部复杂的实现。 +从名字可以看出，`ConcurrentLinkedQueue`这个队列使用链表作为其数据结构．`ConcurrentLinkedQueue` 应该算是在高并发环境中性能最好的队列了。它之所有能有很好的性能，是因为其内部复杂的实现。 -ConcurrentLinkedQueue 内部代码我们就不分析了，大家知道ConcurrentLinkedQueue 主要使用 CAS 非阻塞算法来实现线程安全就好了。 +`ConcurrentLinkedQueue` 内部代码我们就不分析了，大家知道 `ConcurrentLinkedQueue` 主要使用 CAS 非阻塞算法来实现线程安全就好了。 -ConcurrentLinkedQueue 适合在对性能要求相对较高，同时对队列的读写存在多个线程同时进行的场景，即如果对队列加锁的成本较高则适合使用无锁的ConcurrentLinkedQueue来替代。 +`ConcurrentLinkedQueue` 适合在对性能要求相对较高，同时对队列的读写存在多个线程同时进行的场景，即如果对队列加锁的成本较高则适合使用无锁的 `ConcurrentLinkedQueue` 来替代。 -## 五 BlockingQueue +## BlockingQueue -### 5.1 BlockingQueue 简单介绍 +### BlockingQueue 简介 -上面我们己经提到了 ConcurrentLinkedQueue 作为高性能的非阻塞队列。下面我们要讲到的是阻塞队列——BlockingQueue。阻塞队列（BlockingQueue）被广泛使用在“生产者-消费者”问题中，其原因是BlockingQueue提供了可阻塞的插入和移除的方法。当队列容器已满，生产者线程会被阻塞，直到队列未满；当队列容器为空时，消费者线程会被阻塞，直至队列非空时为止。 +上面我们己经提到了 `ConcurrentLinkedQueue` 作为高性能的非阻塞队列。下面我们要讲到的是阻塞队列——`BlockingQueue`。阻塞队列（`BlockingQueue`）被广泛使用在“生产者-消费者”问题中，其原因是 `BlockingQueue` 提供了可阻塞的插入和移除的方法。当队列容器已满，生产者线程会被阻塞，直到队列未满；当队列容器为空时，消费者线程会被阻塞，直至队列非空时为止。 -BlockingQueue 是一个接口，继承自 Queue，所以其实现类也可以作为 Queue 的实现来使用，而 Queue 又继承自 Collection 接口。下面是 BlockingQueue 的相关实现类： +`BlockingQueue` 是一个接口，继承自 `Queue`，所以其实现类也可以作为 `Queue` 的实现来使用，而 `Queue` 又继承自 `Collection` 接口。下面是 `BlockingQueue` 的相关实现类： -![BlockingQueue 的实现类](http://my-blog-to-use.oss-cn-beijing.aliyuncs.com/18-12-9/51622268.jpg) +![BlockingQueue 的实现类](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/18-12-9/51622268.jpg) -**下面主要介绍一下:ArrayBlockingQueue、LinkedBlockingQueue、PriorityBlockingQueue，这三个 BlockingQueue 的实现类。** +下面主要介绍一下 3 个常见的 `BlockingQueue` 的实现类：`ArrayBlockingQueue`、`LinkedBlockingQueue` 、`PriorityBlockingQueue` 。 -### 5.2 ArrayBlockingQueue +### ArrayBlockingQueue -**ArrayBlockingQueue** 是 BlockingQueue 接口的有界队列实现类，底层采用**数组**来实现。ArrayBlockingQueue一旦创建，容量不能改变。其并发控制采用可重入锁来控制，不管是插入操作还是读取操作，都需要获取到锁才能进行操作。当队列容量满时，尝试将元素放入队列将导致操作阻塞;尝试从一个空队列中取一个元素也会同样阻塞。 +`ArrayBlockingQueue` 是 `BlockingQueue` 接口的有界队列实现类，底层采用数组来实现。 -ArrayBlockingQueue 默认情况下不能保证线程访问队列的公平性，所谓公平性是指严格按照线程等待的绝对时间顺序，即最先等待的线程能够最先访问到 ArrayBlockingQueue。而非公平性则是指访问 ArrayBlockingQueue 的顺序不是遵守严格的时间顺序，有可能存在，当 ArrayBlockingQueue 可以被访问时，长时间阻塞的线程依然无法访问到 ArrayBlockingQueue。如果保证公平性，通常会降低吞吐量。如果需要获得公平性的 ArrayBlockingQueue，可采用如下代码： +```java +public class ArrayBlockingQueue +extends AbstractQueue +implements BlockingQueue, Serializable{} +``` + +`ArrayBlockingQueue` 一旦创建，容量不能改变。其并发控制采用可重入锁 `ReentrantLock` ，不管是插入操作还是读取操作，都需要获取到锁才能进行操作。当队列容量满时，尝试将元素放入队列将导致操作阻塞;尝试从一个空队列中取一个元素也会同样阻塞。 + +`ArrayBlockingQueue` 默认情况下不能保证线程访问队列的公平性，所谓公平性是指严格按照线程等待的绝对时间顺序，即最先等待的线程能够最先访问到 `ArrayBlockingQueue`。而非公平性则是指访问 `ArrayBlockingQueue` 的顺序不是遵守严格的时间顺序，有可能存在，当 `ArrayBlockingQueue` 可以被访问时，长时间阻塞的线程依然无法访问到 `ArrayBlockingQueue`。如果保证公平性，通常会降低吞吐量。如果需要获得公平性的 `ArrayBlockingQueue`，可采用如下代码： ```java private static ArrayBlockingQueue blockingQueue = new ArrayBlockingQueue(10,true); ``` -### 5.3 LinkedBlockingQueue +### LinkedBlockingQueue -**LinkedBlockingQueue** 底层基于**单向链表**实现的阻塞队列，可以当做无界队列也可以当做有界队列来使用，同样满足FIFO的特性，与ArrayBlockingQueue 相比起来具有更高的吞吐量，为了防止 LinkedBlockingQueue 容量迅速增，损耗大量内存。通常在创建LinkedBlockingQueue 对象时，会指定其大小，如果未指定，容量等于Integer.MAX_VALUE。 +`LinkedBlockingQueue` 底层基于**单向链表**实现的阻塞队列，可以当做无界队列也可以当做有界队列来使用，同样满足 FIFO 的特性，与 `ArrayBlockingQueue` 相比起来具有更高的吞吐量，为了防止 `LinkedBlockingQueue` 容量迅速增，损耗大量内存。通常在创建 `LinkedBlockingQueue` 对象时，会指定其大小，如果未指定，容量等于 `Integer.MAX_VALUE` 。 **相关构造方法:** @@ -176,48 +161,42 @@ private static ArrayBlockingQueue blockingQueue = new ArrayBlockingQueu } ``` -### 5.4 PriorityBlockingQueue +### PriorityBlockingQueue -**PriorityBlockingQueue** 是一个支持优先级的无界阻塞队列。默认情况下元素采用自然顺序进行排序，也可以通过自定义类实现 `compareTo()` 方法来指定元素排序规则，或者初始化时通过构造器参数 `Comparator` 来指定排序规则。 +`PriorityBlockingQueue` 是一个支持优先级的无界阻塞队列。默认情况下元素采用自然顺序进行排序，也可以通过自定义类实现 `compareTo()` 方法来指定元素排序规则，或者初始化时通过构造器参数 `Comparator` 来指定排序规则。 -PriorityBlockingQueue 并发控制采用的是 **ReentrantLock**，队列为无界队列（ArrayBlockingQueue 是有界队列，LinkedBlockingQueue 也可以通过在构造函数中传入 capacity 指定队列最大的容量，但是 PriorityBlockingQueue 只能指定初始的队列大小，后面插入元素的时候，**如果空间不够的话会自动扩容**）。 +`PriorityBlockingQueue` 并发控制采用的是可重入锁 `ReentrantLock`，队列为无界队列（`ArrayBlockingQueue` 是有界队列，`LinkedBlockingQueue` 也可以通过在构造函数中传入 `capacity` 指定队列最大的容量，但是 `PriorityBlockingQueue` 只能指定初始的队列大小，后面插入元素的时候，**如果空间不够的话会自动扩容**）。 -简单地说，它就是 PriorityQueue 的线程安全版本。不可以插入 null 值，同时，插入队列的对象必须是可比较大小的（comparable），否则报 ClassCastException 异常。它的插入操作 put 方法不会 block，因为它是无界队列（take 方法在队列为空的时候会阻塞）。 +简单地说，它就是 `PriorityQueue` 的线程安全版本。不可以插入 null 值，同时，插入队列的对象必须是可比较大小的（comparable），否则报 `ClassCastException` 异常。它的插入操作 put 方法不会 block，因为它是无界队列（take 方法在队列为空的时候会阻塞）。 -**推荐文章：** +**推荐文章：** [《解读 Java 并发队列 BlockingQueue》](https://javadoop.com/post/java-concurrent-queue) -《解读 Java 并发队列 BlockingQueue》 +## ConcurrentSkipListMap -[https://javadoop.com/post/java-concurrent-queue](https://javadoop.com/post/java-concurrent-queue) +下面这部分内容参考了极客时间专栏[《数据结构与算法之美》](https://time.geekbang.org/column/intro/126?code=zl3GYeAsRI4rEJIBNu5B/km7LSZsPDlGWQEpAYw5Vu0=&utm_term=SPoster "《数据结构与算法之美》")以及《实战 Java 高并发程序设计》。 -## 六 ConcurrentSkipListMap - -下面这部分内容参考了极客时间专栏[《数据结构与算法之美》](https://time.geekbang.org/column/intro/126?code=zl3GYeAsRI4rEJIBNu5B/km7LSZsPDlGWQEpAYw5Vu0=&utm_term=SPoster)以及《实战Java高并发程序设计》。 - -**为了引出ConcurrentSkipListMap，先带着大家简单理解一下跳表。** +为了引出 `ConcurrentSkipListMap`，先带着大家简单理解一下跳表。 对于一个单链表，即使链表是有序的，如果我们想要在其中查找某个数据，也只能从头到尾遍历链表，这样效率自然就会很低，跳表就不一样了。跳表是一种可以用来快速查找的数据结构，有点类似于平衡树。它们都可以对元素进行快速的查找。但一个重要的区别是：对平衡树的插入和删除往往很可能导致平衡树进行一次全局的调整。而对跳表的插入和删除只需要对整个数据结构的局部进行操作即可。这样带来的好处是：在高并发的情况下，你会需要一个全局锁来保证整个平衡树的线程安全。而对于跳表，你只需要部分锁即可。这样，在高并发环境下，你就可以拥有更好的性能。而就查询的性能而言，跳表的时间复杂度也是 **O(logn)** 所以在并发数据结构中，JDK 使用跳表来实现一个 Map。 跳表的本质是同时维护了多个链表，并且链表是分层的， -![2级索引跳表](http://my-blog-to-use.oss-cn-beijing.aliyuncs.com/18-12-9/93666217.jpg) +![2级索引跳表](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/18-12-9/93666217.jpg) 最低层的链表维护了跳表内所有的元素，每上面一层链表都是下面一层的子集。 -跳表内的所有链表的元素都是排序的。查找时，可以从顶级链表开始找。一旦发现被查找的元素大于当前链表中的取值，就会转入下一层链表继续找。这也就是说在查找过程中，搜索是跳跃式的。如上图所示，在跳表中查找元素18。 +跳表内的所有链表的元素都是排序的。查找时，可以从顶级链表开始找。一旦发现被查找的元素大于当前链表中的取值，就会转入下一层链表继续找。这也就是说在查找过程中，搜索是跳跃式的。如上图所示，在跳表中查找元素 18。 -![在跳表中查找元素18](http://my-blog-to-use.oss-cn-beijing.aliyuncs.com/18-12-9/32005738.jpg) +![在跳表中查找元素18](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/18-12-9/32005738.jpg) -查找18 的时候原来需要遍历 18 次，现在只需要 7 次即可。针对链表长度比较大的时候，构建索引查找效率的提升就会非常明显。 +查找 18 的时候原来需要遍历 18 次，现在只需要 7 次即可。针对链表长度比较大的时候，构建索引查找效率的提升就会非常明显。 从上面很容易看出，**跳表是一种利用空间换时间的算法。** -使用跳表实现Map 和使用哈希算法实现Map的另外一个不同之处是：哈希并不会保存元素的顺序，而跳表内所有的元素都是排序的。因此在对跳表进行遍历时，你会得到一个有序的结果。所以，如果你的应用需要有序性，那么跳表就是你不二的选择。JDK 中实现这一数据结构的类是ConcurrentSkipListMap。 - - +使用跳表实现 `Map` 和使用哈希算法实现 `Map` 的另外一个不同之处是：哈希并不会保存元素的顺序，而跳表内所有的元素都是排序的。因此在对跳表进行遍历时，你会得到一个有序的结果。所以，如果你的应用需要有序性，那么跳表就是你不二的选择。JDK 中实现这一数据结构的类是 `ConcurrentSkipListMap`。 -## 七 参考 +## 参考 -- 《实战Java高并发程序设计》 +- 《实战 Java 高并发程序设计》 - https://javadoop.com/post/java-concurrent-queue - https://juejin.im/post/5aeebd02518825672f19c546 diff --git a/docs/java/concurrent/java-concurrent-questions-01.md b/docs/java/concurrent/java-concurrent-questions-01.md new file mode 100644 index 0000000000000000000000000000000000000000..641409fa0502e4fa9522885edc5ffc3e503b0698 --- /dev/null +++ b/docs/java/concurrent/java-concurrent-questions-01.md @@ -0,0 +1,282 @@ +--- +title: Java 并发常见知识点&面试题总结（基础篇） +category: Java +tag: + - Java并发 +--- + +## 什么是线程和进程? + +### 何为进程? + +进程是程序的一次执行过程，是系统运行程序的基本单位，因此进程是动态的。系统运行一个程序即是一个进程从创建，运行到消亡的过程。 + +在 Java 中，当我们启动 main 函数时其实就是启动了一个 JVM 的进程，而 main 函数所在的线程就是这个进程中的一个线程，也称主线程。 + +如下图所示，在 windows 中通过查看任务管理器的方式，我们就可以清楚看到 window 当前运行的进程（.exe 文件的运行）。 + +![进程示例图片-Windows](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/2019-6/进程示例图片-Windows.png) + +### 何为线程? + +线程与进程相似，但线程是一个比进程更小的执行单位。一个进程在其执行的过程中可以产生多个线程。与进程不同的是同类的多个线程共享进程的**堆**和**方法区**资源，但每个线程有自己的**程序计数器**、**虚拟机栈**和**本地方法栈**，所以系统在产生一个线程，或是在各个线程之间作切换工作时，负担要比进程小得多，也正因为如此，线程也被称为轻量级进程。 + +Java 程序天生就是多线程程序，我们可以通过 JMX 来看一下一个普通的 Java 程序有哪些线程，代码如下。 + +```java +public class MultiThread { + public static void main(String[] args) { + // 获取 Java 线程管理 MXBean + ThreadMXBean threadMXBean = ManagementFactory.getThreadMXBean(); + // 不需要获取同步的 monitor 和 synchronizer 信息，仅获取线程和线程堆栈信息 + ThreadInfo[] threadInfos = threadMXBean.dumpAllThreads(false, false); + // 遍历线程信息，仅打印线程 ID 和线程名称信息 + for (ThreadInfo threadInfo : threadInfos) { + System.out.println("[" + threadInfo.getThreadId() + "] " + threadInfo.getThreadName()); + } + } +} +``` + +上述程序输出如下（输出内容可能不同，不用太纠结下面每个线程的作用，只用知道 main 线程执行 main 方法即可）： + +``` +[5] Attach Listener //添加事件 +[4] Signal Dispatcher // 分发处理给 JVM 信号的线程 +[3] Finalizer //调用对象 finalize 方法的线程 +[2] Reference Handler //清除 reference 线程 +[1] main //main 线程,程序入口 +``` + +从上面的输出内容可以看出：**一个 Java 程序的运行是 main 线程和多个其他线程同时运行**。 + +## 请简要描述线程与进程的关系,区别及优缺点？ + +**从 JVM 角度说进程和线程之间的关系** + +### 图解进程和线程的关系 + +下图是 Java 内存区域，通过下图我们从 JVM 的角度来说一下线程和进程之间的关系。 + +![](../jvm/pictures/java内存区域/Java运行时数据区域JDK1.8.png) + +从上图可以看出：一个进程中可以有多个线程，多个线程共享进程的**堆**和**方法区 (JDK1.8 之后的元空间)**资源，但是每个线程有自己的**程序计数器**、**虚拟机栈** 和 **本地方法栈**。 + +**总结：** **线程是进程划分成的更小的运行单位。线程和进程最大的不同在于基本上各进程是独立的，而各线程则不一定，因为同一进程中的线程极有可能会相互影响。线程执行开销小，但不利于资源的管理和保护；而进程正相反。** + +下面是该知识点的扩展内容！ + +下面来思考这样一个问题：为什么**程序计数器**、**虚拟机栈**和**本地方法栈**是线程私有的呢？为什么堆和方法区是线程共享的呢？ + +### 程序计数器为什么是私有的? + +程序计数器主要有下面两个作用： + +1. 字节码解释器通过改变程序计数器来依次读取指令，从而实现代码的流程控制，如：顺序执行、选择、循环、异常处理。 +2. 在多线程的情况下，程序计数器用于记录当前线程执行的位置，从而当线程被切换回来的时候能够知道该线程上次运行到哪儿了。 + +需要注意的是，如果执行的是 native 方法，那么程序计数器记录的是 undefined 地址，只有执行的是 Java 代码时程序计数器记录的才是下一条指令的地址。 + +所以，程序计数器私有主要是为了**线程切换后能恢复到正确的执行位置**。 + +### 虚拟机栈和本地方法栈为什么是私有的? + +- **虚拟机栈：** 每个 Java 方法在执行的同时会创建一个栈帧用于存储局部变量表、操作数栈、常量池引用等信息。从方法调用直至执行完成的过程，就对应着一个栈帧在 Java 虚拟机栈中入栈和出栈的过程。 +- **本地方法栈：** 和虚拟机栈所发挥的作用非常相似，区别是： **虚拟机栈为虚拟机执行 Java 方法 （也就是字节码）服务，而本地方法栈则为虚拟机使用到的 Native 方法服务。** 在 HotSpot 虚拟机中和 Java 虚拟机栈合二为一。 + +所以，为了**保证线程中的局部变量不被别的线程访问到**，虚拟机栈和本地方法栈是线程私有的。 + +### 一句话简单了解堆和方法区 + +堆和方法区是所有线程共享的资源，其中堆是进程中最大的一块内存，主要用于存放新创建的对象 (几乎所有对象都在这里分配内存)，方法区主要用于存放已被加载的类信息、常量、静态变量、即时编译器编译后的代码等数据。 + +## 说说并发与并行的区别? + +- **并发：** 同一时间段，多个任务都在执行 (单位时间内不一定同时执行)； +- **并行：** 单位时间内，多个任务同时执行。 + +## 为什么要使用多线程呢? + +先从总体上来说： + +- **从计算机底层来说：** 线程可以比作是轻量级的进程，是程序执行的最小单位,线程间的切换和调度的成本远远小于进程。另外，多核 CPU 时代意味着多个线程可以同时运行，这减少了线程上下文切换的开销。 +- **从当代互联网发展趋势来说：** 现在的系统动不动就要求百万级甚至千万级的并发量，而多线程并发编程正是开发高并发系统的基础，利用好多线程机制可以大大提高系统整体的并发能力以及性能。 + +再深入到计算机底层来探讨： + +- **单核时代**： 在单核时代多线程主要是为了提高单进程利用 CPU 和 IO 系统的效率。 假设只运行了一个 Java 进程的情况，当我们请求 IO 的时候，如果 Java 进程中只有一个线程，此线程被 IO 阻塞则整个进程被阻塞。CPU 和 IO 设备只有一个在运行，那么可以简单地说系统整体效率只有 50%。当使用多线程的时候，一个线程被 IO 阻塞，其他线程还可以继续使用 CPU。从而提高了 Java 进程利用系统资源的整体效率。 +- **多核时代**: 多核时代多线程主要是为了提高进程利用多核 CPU 的能力。举个例子：假如我们要计算一个复杂的任务，我们只用一个线程的话，不论系统有几个 CPU 核心，都只会有一个 CPU 核心被利用到。而创建多个线程，这些线程可以被映射到底层多个 CPU 上执行，在任务中的多个线程没有资源竞争的情况下，任务执行的效率会有显著性的提高，约等于（单核时执行时间/CPU 核心数）。 + +## 使用多线程可能带来什么问题? + +并发编程的目的就是为了能提高程序的执行效率提高程序运行速度，但是并发编程并不总是能提高程序运行速度的，而且并发编程可能会遇到很多问题，比如：内存泄漏、死锁、线程不安全等等。 + +## 说说线程的生命周期和状态? + +Java 线程在运行的生命周期中的指定时刻只可能处于下面 6 种不同状态的其中一个状态（图源《Java 并发编程艺术》4.1.4 节）。 + +![Java 线程的状态 ](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/19-1-29/Java%E7%BA%BF%E7%A8%8B%E7%9A%84%E7%8A%B6%E6%80%81.png) + +线程在生命周期中并不是固定处于某一个状态而是随着代码的执行在不同状态之间切换。Java 线程状态变迁如下图所示（图源《Java 并发编程艺术》4.1.4 节）： + +![Java 线程状态变迁 ](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/19-1-29/Java+%E7%BA%BF%E7%A8%8B%E7%8A%B6%E6%80%81%E5%8F%98%E8%BF%81.png) + +> 订正(来自[issue736](https://github.com/Snailclimb/JavaGuide/issues/736))：原图中 wait 到 runnable 状态的转换中，`join`实际上是`Thread`类的方法，但这里写成了`Object`。 + +由上图可以看出：线程创建之后它将处于 **NEW（新建）** 状态，调用 `start()` 方法后开始运行，线程这时候处于 **READY（可运行）** 状态。可运行状态的线程获得了 CPU 时间片（timeslice）后就处于 **RUNNING（运行）** 状态。 + +> 在操作系统中层面线程有 READY 和 RUNNING 状态，而在 JVM 层面只能看到 RUNNABLE 状态（图源：[HowToDoInJava](https://howtodoinJava.com/ "HowToDoInJava")：[Java Thread Life Cycle and Thread States](https://howtodoinJava.com/Java/multi-threading/Java-thread-life-cycle-and-thread-states/ "Java Thread Life Cycle and Thread States")），所以 Java 系统一般将这两个状态统称为 **RUNNABLE（运行中）** 状态 。 +> +> **为什么 JVM 没有区分这两种状态呢？** （摘自：[java线程运行怎么有第六种状态？ - Dawell的回答](https://www.zhihu.com/question/56494969/answer/154053599) ） 现在的时分（time-sharing）多任务（multi-task）操作系统架构通常都是用所谓的“时间分片（time quantum or time slice）”方式进行抢占式（preemptive）轮转调度（round-robin式）。这个时间分片通常是很小的，一个线程一次最多只能在 CPU 上运行比如 10-20ms 的时间（此时处于 running 状态），也即大概只有 0.01 秒这一量级，时间片用后就要被切换下来放入调度队列的末尾等待再次调度。（也即回到 ready 状态）。线程切换的如此之快，区分这两种状态就没什么意义了。 + +![RUNNABLE-VS-RUNNING](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/2019-3/RUNNABLE-VS-RUNNING.png) + +当线程执行 `wait()`方法之后，线程进入 **WAITING（等待）** 状态。进入等待状态的线程需要依靠其他线程的通知才能够返回到运行状态，而 **TIMED_WAITING(超时等待)** 状态相当于在等待状态的基础上增加了超时限制，比如通过 `sleep（long millis）`方法或 `wait（long millis）`方法可以将 Java 线程置于 TIMED_WAITING 状态。当超时时间到达后 Java 线程将会返回到 RUNNABLE 状态。当线程调用同步方法时，在没有获取到锁的情况下，线程将会进入到 **BLOCKED（阻塞）** 状态。线程在执行 Runnable 的`run()`方法之后将会进入到 **TERMINATED（终止）** 状态。 + +相关阅读：[挑错 |《Java 并发编程的艺术》中关于线程状态的三处错误](https://mp.weixin.qq.com/s/UOrXql_LhOD8dhTq_EPI0w) 。 + +## 什么是上下文切换? + +线程在执行过程中会有自己的运行条件和状态（也称上下文），比如上文所说到过的程序计数器，栈信息等。当出现如下情况的时候，线程会从占用 CPU 状态中退出。 +- 主动让出 CPU，比如调用了 `sleep()`, `wait()` 等。 +- 时间片用完，因为操作系统要防止一个线程或者进程长时间占用CPU导致其他线程或者进程饿死。 +- 调用了阻塞类型的系统中断，比如请求 IO，线程被阻塞。 +- 被终止或结束运行 + +这其中前三种都会发生线程切换，线程切换意味着需要保存当前线程的上下文，留待线程下次占用 CPU 的时候恢复现场。并加载下一个将要占用 CPU 的线程上下文。这就是所谓的 **上下文切换**。 + +上下文切换是现代操作系统的基本功能，因其每次需要保存信息恢复信息，这将会占用 CPU，内存等系统资源进行处理，也就意味着效率会有一定损耗，如果频繁切换就会造成整体效率低下。 + +## 什么是线程死锁?如何避免死锁? + +### 认识线程死锁 + +线程死锁描述的是这样一种情况：多个线程同时被阻塞，它们中的一个或者全部都在等待某个资源被释放。由于线程被无限期地阻塞，因此程序不可能正常终止。 + +如下图所示，线程 A 持有资源 2，线程 B 持有资源 1，他们同时都想申请对方的资源，所以这两个线程就会互相等待而进入死锁状态。 + +![线程死锁示意图 ](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/2019-4/2019-4%E6%AD%BB%E9%94%811.png) + +下面通过一个例子来说明线程死锁,代码模拟了上图的死锁的情况 (代码来源于《并发编程之美》)： + +```java +public class DeadLockDemo { + private static Object resource1 = new Object();//资源 1 + private static Object resource2 = new Object();//资源 2 + + public static void main(String[] args) { + new Thread(() -> { + synchronized (resource1) { + System.out.println(Thread.currentThread() + "get resource1"); + try { + Thread.sleep(1000); + } catch (InterruptedException e) { + e.printStackTrace(); + } + System.out.println(Thread.currentThread() + "waiting get resource2"); + synchronized (resource2) { + System.out.println(Thread.currentThread() + "get resource2"); + } + } + }, "线程 1").start(); + + new Thread(() -> { + synchronized (resource2) { + System.out.println(Thread.currentThread() + "get resource2"); + try { + Thread.sleep(1000); + } catch (InterruptedException e) { + e.printStackTrace(); + } + System.out.println(Thread.currentThread() + "waiting get resource1"); + synchronized (resource1) { + System.out.println(Thread.currentThread() + "get resource1"); + } + } + }, "线程 2").start(); + } +} +``` + +Output + +``` +Thread[线程 1,5,main]get resource1 +Thread[线程 2,5,main]get resource2 +Thread[线程 1,5,main]waiting get resource2 +Thread[线程 2,5,main]waiting get resource1 +``` + +线程 A 通过 `synchronized (resource1)` 获得 `resource1` 的监视器锁，然后通过`Thread.sleep(1000);`让线程 A 休眠 1s 为的是让线程 B 得到执行然后获取到 resource2 的监视器锁。线程 A 和线程 B 休眠结束了都开始企图请求获取对方的资源，然后这两个线程就会陷入互相等待的状态，这也就产生了死锁。上面的例子符合产生死锁的四个必要条件。 + +学过操作系统的朋友都知道产生死锁必须具备以下四个条件： + +1. 互斥条件：该资源任意一个时刻只由一个线程占用。 +2. 请求与保持条件：一个进程因请求资源而阻塞时，对已获得的资源保持不放。 +3. 不剥夺条件:线程已获得的资源在未使用完之前不能被其他线程强行剥夺，只有自己使用完毕后才释放资源。 +4. 循环等待条件:若干进程之间形成一种头尾相接的循环等待资源关系。 + +### 如何预防和避免线程死锁? + +**如何预防死锁？** 破坏死锁的产生的必要条件即可： + +1. **破坏请求与保持条件** ：一次性申请所有的资源。 +2. **破坏不剥夺条件** ：占用部分资源的线程进一步申请其他资源时，如果申请不到，可以主动释放它占有的资源。 +3. **破坏循环等待条件** ：靠按序申请资源来预防。按某一顺序申请资源，释放资源则反序释放。破坏循环等待条件。 + +**如何避免死锁？** + +避免死锁就是在资源分配时，借助于算法（比如银行家算法）对资源分配进行计算评估，使其进入安全状态。 + +> **安全状态** 指的是系统能够按照某种线程推进顺序（P1、P2、P3.....Pn）来为每个线程分配所需资源，直到满足每个线程对资源的最大需求，使每个线程都可顺利完成。称序列为安全序列。 + +我们对线程 2 的代码修改成下面这样就不会产生死锁了。 + +```java + new Thread(() -> { + synchronized (resource1) { + System.out.println(Thread.currentThread() + "get resource1"); + try { + Thread.sleep(1000); + } catch (InterruptedException e) { + e.printStackTrace(); + } + System.out.println(Thread.currentThread() + "waiting get resource2"); + synchronized (resource2) { + System.out.println(Thread.currentThread() + "get resource2"); + } + } + }, "线程 2").start(); +``` + +Output + +``` +Thread[线程 1,5,main]get resource1 +Thread[线程 1,5,main]waiting get resource2 +Thread[线程 1,5,main]get resource2 +Thread[线程 2,5,main]get resource1 +Thread[线程 2,5,main]waiting get resource2 +Thread[线程 2,5,main]get resource2 + +Process finished with exit code 0 +``` + +我们分析一下上面的代码为什么避免了死锁的发生? + +线程 1 首先获得到 resource1 的监视器锁,这时候线程 2 就获取不到了。然后线程 1 再去获取 resource2 的监视器锁，可以获取到。然后线程 1 释放了对 resource1、resource2 的监视器锁的占用，线程 2 获取到就可以执行了。这样就破坏了破坏循环等待条件，因此避免了死锁。 + +## 说说 sleep() 方法和 wait() 方法区别和共同点? + +- 两者最主要的区别在于：**`sleep()` 方法没有释放锁，而 `wait()` 方法释放了锁** 。 +- 两者都可以暂停线程的执行。 +- `wait()` 通常被用于线程间交互/通信，`sleep() `通常被用于暂停执行。 +- `wait()` 方法被调用后，线程不会自动苏醒，需要别的线程调用同一个对象上的 `notify() `或者 `notifyAll()` 方法。`sleep() `方法执行完成后，线程会自动苏醒。或者可以使用 `wait(long timeout)` 超时后线程会自动苏醒。 + +## 为什么我们调用 start() 方法时会执行 run() 方法，为什么我们不能直接调用 run() 方法？ + +这是另一个非常经典的 Java 多线程面试问题，而且在面试中会经常被问到。很简单，但是很多人都会答不上来！ + +new 一个 Thread，线程进入了新建状态。调用 `start()`方法，会启动一个线程并使线程进入了就绪状态，当分配到时间片后就可以开始运行了。 `start()` 会执行线程的相应准备工作，然后自动执行 `run()` 方法的内容，这是真正的多线程工作。 但是，直接执行 `run()` 方法，会把 `run()` 方法当成一个 main 线程下的普通方法去执行，并不会在某个线程中执行它，所以这并不是多线程工作。 + +**总结： 调用 `start()` 方法方可启动线程并使线程进入就绪状态，直接执行 `run()` 方法的话不会以多线程的方式执行。** diff --git a/docs/java/concurrent/java-concurrent-questions-02.md b/docs/java/concurrent/java-concurrent-questions-02.md new file mode 100644 index 0000000000000000000000000000000000000000..ebfdbc5e25c128783efb2acd5ab59ff04588a0a0 --- /dev/null +++ b/docs/java/concurrent/java-concurrent-questions-02.md @@ -0,0 +1,1068 @@ +--- +title: Java 并发常见知识点&面试题总结（进阶篇） +category: Java +tag: + - Java并发 +--- + +## 1.synchronized 关键字 + +### 1.1.说一说自己对于 synchronized 关键字的了解 + +**`synchronized` 关键字解决的是多个线程之间访问资源的同步性，`synchronized`关键字可以保证被它修饰的方法或者代码块在任意时刻只能有一个线程执行。** + +另外，在 Java 早期版本中，`synchronized` 属于 **重量级锁**，效率低下。 + +**为什么呢？** + +因为监视器锁（monitor）是依赖于底层的操作系统的 `Mutex Lock` 来实现的，Java 的线程是映射到操作系统的原生线程之上的。如果要挂起或者唤醒一个线程，都需要操作系统帮忙完成，而操作系统实现线程之间的切换时需要从用户态转换到内核态，这个状态之间的转换需要相对比较长的时间，时间成本相对较高。 + +庆幸的是在 Java 6 之后 Java 官方对从 JVM 层面对 `synchronized` 较大优化，所以现在的 `synchronized` 锁效率也优化得很不错了。JDK1.6 对锁的实现引入了大量的优化，如自旋锁、适应性自旋锁、锁消除、锁粗化、偏向锁、轻量级锁等技术来减少锁操作的开销。 + +所以，你会发现目前的话，不论是各种开源框架还是 JDK 源码都大量使用了 `synchronized` 关键字。 + +### 1.2. 说说自己是怎么使用 synchronized 关键字 + +**synchronized 关键字最主要的三种使用方式：** + +**1.修饰实例方法:** 作用于当前对象实例加锁，进入同步代码前要获得 **当前对象实例的锁** + +```java +synchronized void method() { + //业务代码 +} +``` + +**2.修饰静态方法:** 也就是给当前类加锁，会作用于类的所有对象实例 ，进入同步代码前要获得 **当前 class 的锁**。因为静态成员不属于任何一个实例对象，是类成员（ _static 表明这是该类的一个静态资源，不管 new 了多少个对象，只有一份_）。所以，如果一个线程 A 调用一个实例对象的非静态 `synchronized` 方法，而线程 B 需要调用这个实例对象所属类的静态 `synchronized` 方法，是允许的，不会发生互斥现象，**因为访问静态 `synchronized` 方法占用的锁是当前类的锁，而访问非静态 `synchronized` 方法占用的锁是当前实例对象锁**。 + +```java +synchronized static void method() { + //业务代码 +} +``` + +**3.修饰代码块** ：指定加锁对象，对给定对象/类加锁。`synchronized(this|object)` 表示进入同步代码库前要获得**给定对象的锁**。`synchronized(类.class)` 表示进入同步代码前要获得 **当前 class 的锁** + +```java +synchronized(this) { + //业务代码 +} +``` + +**总结：** + +- `synchronized` 关键字加到 `static` 静态方法和 `synchronized(class)` 代码块上都是是给 Class 类上锁。 +- `synchronized` 关键字加到实例方法上是给对象实例上锁。 +- 尽量不要使用 `synchronized(String a)` 因为 JVM 中，字符串常量池具有缓存功能！ + +下面我以一个常见的面试题为例讲解一下 `synchronized` 关键字的具体使用。 + +面试中面试官经常会说：“单例模式了解吗？来给我手写一下！给我解释一下双重检验锁方式实现单例模式的原理呗！” + +**双重校验锁实现对象单例（线程安全）** + +```java +public class Singleton { + + private volatile static Singleton uniqueInstance; + + private Singleton() { + } + + public static Singleton getUniqueInstance() { + //先判断对象是否已经实例过，没有实例化过才进入加锁代码 + if (uniqueInstance == null) { + //类对象加锁 + synchronized (Singleton.class) { + if (uniqueInstance == null) { + uniqueInstance = new Singleton(); + } + } + } + return uniqueInstance; + } +} +``` + +另外，需要注意 `uniqueInstance` 采用 `volatile` 关键字修饰也是很有必要。 + +`uniqueInstance` 采用 `volatile` 关键字修饰也是很有必要的， `uniqueInstance = new Singleton();` 这段代码其实是分为三步执行： + +1. 为 `uniqueInstance` 分配内存空间 +2. 初始化 `uniqueInstance` +3. 将 `uniqueInstance` 指向分配的内存地址 + +但是由于 JVM 具有指令重排的特性，执行顺序有可能变成 1->3->2。指令重排在单线程环境下不会出现问题，但是在多线程环境下会导致一个线程获得还没有初始化的实例。例如，线程 T1 执行了 1 和 3，此时 T2 调用 `getUniqueInstance`() 后发现 `uniqueInstance` 不为空，因此返回 `uniqueInstance`，但此时 `uniqueInstance` 还未被初始化。 + +使用 `volatile` 可以禁止 JVM 的指令重排，保证在多线程环境下也能正常运行。 + +### 1.3. 构造方法可以使用 synchronized 关键字修饰么？ + +先说结论：**构造方法不能使用 synchronized 关键字修饰。** + +构造方法本身就属于线程安全的，不存在同步的构造方法一说。 + +### 1.3. 讲一下 synchronized 关键字的底层原理 + +**synchronized 关键字底层原理属于 JVM 层面。** + +#### 1.3.1. synchronized 同步语句块的情况 + +```java +public class SynchronizedDemo { + public void method() { + synchronized (this) { + System.out.println("synchronized 代码块"); + } + } +} + +``` + +通过 JDK 自带的 `javap` 命令查看 `SynchronizedDemo` 类的相关字节码信息：首先切换到类的对应目录执行 `javac SynchronizedDemo.java` 命令生成编译后的 .class 文件，然后执行`javap -c -s -v -l SynchronizedDemo.class`。 + +![synchronized关键字原理](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/2019-6/synchronized关键字原理.png) + +从上面我们可以看出：**`synchronized` 同步语句块的实现使用的是 `monitorenter` 和 `monitorexit` 指令，其中 `monitorenter` 指令指向同步代码块的开始位置，`monitorexit` 指令则指明同步代码块的结束位置。** + +当执行 `monitorenter` 指令时，线程试图获取锁也就是获取 **对象监视器 `monitor`** 的持有权。 + +> 在 Java 虚拟机(HotSpot)中，Monitor 是基于 C++实现的，由[ObjectMonitor](https://github.com/openjdk-mirror/jdk7u-hotspot/blob/50bdefc3afe944ca74c3093e7448d6b889cd20d1/src/share/vm/runtime/objectMonitor.cpp)实现的。每个对象中都内置了一个 `ObjectMonitor`对象。 +> +> 另外，`wait/notify`等方法也依赖于`monitor`对象，这就是为什么只有在同步的块或者方法中才能调用`wait/notify`等方法，否则会抛出`java.lang.IllegalMonitorStateException`的异常的原因。 + +在执行`monitorenter`时，会尝试获取对象的锁，如果锁的计数器为 0 则表示锁可以被获取，获取后将锁计数器设为 1 也就是加 1。 + +![执行 monitorenter 获取锁](./images/interview-questions/synchronized-get-lock-code-block.png) + +对象锁的的拥有者线程才可以执行 `monitorexit` 指令来释放锁。在执行 `monitorexit` 指令后，将锁计数器设为 0，表明锁被释放，其他线程可以尝试获取锁。 + + + +![执行 monitorexit 释放锁](./images/interview-questions/synchronized-release-lock-block.png) + +如果获取对象锁失败，那当前线程就要阻塞等待，直到锁被另外一个线程释放为止。 + +#### 1.3.2. synchronized 修饰方法的的情况 + +```java +public class SynchronizedDemo2 { + public synchronized void method() { + System.out.println("synchronized 方法"); + } +} + +``` + +![synchronized关键字原理](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/2019-6/synchronized关键字原理2.png) + +`synchronized` 修饰的方法并没有 `monitorenter` 指令和 `monitorexit` 指令，取得代之的确实是 `ACC_SYNCHRONIZED` 标识，该标识指明了该方法是一个同步方法。JVM 通过该 `ACC_SYNCHRONIZED` 访问标志来辨别一个方法是否声明为同步方法，从而执行相应的同步调用。 + +如果是实例方法，JVM 会尝试获取实例对象的锁。如果是静态方法，JVM 会尝试获取当前 class 的锁。 + +#### 1.3.3.总结 + +`synchronized` 同步语句块的实现使用的是 `monitorenter` 和 `monitorexit` 指令，其中 `monitorenter` 指令指向同步代码块的开始位置，`monitorexit` 指令则指明同步代码块的结束位置。 + +`synchronized` 修饰的方法并没有 `monitorenter` 指令和 `monitorexit` 指令，取得代之的确实是 `ACC_SYNCHRONIZED` 标识，该标识指明了该方法是一个同步方法。 + +**不过两者的本质都是对对象监视器 monitor 的获取。** + +相关推荐：[Java锁与线程的那些事 - 有赞技术团队](https://tech.youzan.com/javasuo-yu-xian-cheng-de-na-xie-shi/) 。 + +🧗🏻进阶一下：学有余力的小伙伴可以抽时间详细研究一下对象监视器 `monitor`。 + +### 1.4. 说说 JDK1.6 之后的 synchronized 关键字底层做了哪些优化，可以详细介绍一下这些优化吗 + +JDK1.6 对锁的实现引入了大量的优化，如偏向锁、轻量级锁、自旋锁、适应性自旋锁、锁消除、锁粗化等技术来减少锁操作的开销。 + +锁主要存在四种状态，依次是：无锁状态、偏向锁状态、轻量级锁状态、重量级锁状态，他们会随着竞争的激烈而逐渐升级。注意锁可以升级不可降级，这种策略是为了提高获得锁和释放锁的效率。 + +关于这几种优化的详细信息可以查看下面这篇文章：[Java6 及以上版本对 synchronized 的优化](https://www.cnblogs.com/wuqinglong/p/9945618.html) + +### 1.5. 谈谈 synchronized 和 ReentrantLock 的区别 + +#### 1.5.1. 两者都是可重入锁 + +**“可重入锁”** 指的是自己可以再次获取自己的内部锁。比如一个线程获得了某个对象的锁，此时这个对象锁还没有释放，当其再次想要获取这个对象的锁的时候还是可以获取的，如果不可锁重入的话，就会造成死锁。同一个线程每次获取锁，锁的计数器都自增 1，所以要等到锁的计数器下降为 0 时才能释放锁。 + +#### 1.5.2.synchronized 依赖于 JVM 而 ReentrantLock 依赖于 API + +`synchronized` 是依赖于 JVM 实现的，前面我们也讲到了 虚拟机团队在 JDK1.6 为 `synchronized` 关键字进行了很多优化，但是这些优化都是在虚拟机层面实现的，并没有直接暴露给我们。`ReentrantLock` 是 JDK 层面实现的（也就是 API 层面，需要 lock() 和 unlock() 方法配合 try/finally 语句块来完成），所以我们可以通过查看它的源代码，来看它是如何实现的。 + +#### 1.5.3.ReentrantLock 比 synchronized 增加了一些高级功能 + +相比`synchronized`，`ReentrantLock`增加了一些高级功能。主要来说主要有三点： + +- **等待可中断** : `ReentrantLock`提供了一种能够中断等待锁的线程的机制，通过 `lock.lockInterruptibly()` 来实现这个机制。也就是说正在等待的线程可以选择放弃等待，改为处理其他事情。 +- **可实现公平锁** : `ReentrantLock`可以指定是公平锁还是非公平锁。而`synchronized`只能是非公平锁。所谓的公平锁就是先等待的线程先获得锁。`ReentrantLock`默认情况是非公平的，可以通过 `ReentrantLock`类的`ReentrantLock(boolean fair)`构造方法来制定是否是公平的。 +- **可实现选择性通知（锁可以绑定多个条件）**: `synchronized`关键字与`wait()`和`notify()`/`notifyAll()`方法相结合可以实现等待/通知机制。`ReentrantLock`类当然也可以实现，但是需要借助于`Condition`接口与`newCondition()`方法。 + +> `Condition`是 JDK1.5 之后才有的，它具有很好的灵活性，比如可以实现多路通知功能也就是在一个`Lock`对象中可以创建多个`Condition`实例（即对象监视器），**线程对象可以注册在指定的`Condition`中，从而可以有选择性的进行线程通知，在调度线程上更加灵活。 在使用`notify()/notifyAll()`方法进行通知时，被通知的线程是由 JVM 选择的，用`ReentrantLock`类结合`Condition`实例可以实现“选择性通知”** ，这个功能非常重要，而且是 Condition 接口默认提供的。而`synchronized`关键字就相当于整个 Lock 对象中只有一个`Condition`实例，所有的线程都注册在它一个身上。如果执行`notifyAll()`方法的话就会通知所有处于等待状态的线程这样会造成很大的效率问题，而`Condition`实例的`signalAll()`方法 只会唤醒注册在该`Condition`实例中的所有等待线程。 + +**如果你想使用上述功能，那么选择 ReentrantLock 是一个不错的选择。性能已不是选择标准** + +## 2. volatile 关键字 + +我们先要从 **CPU 缓存模型** 说起！ + +### 2.1. CPU 缓存模型 + +**为什么要弄一个 CPU 高速缓存呢？** + +类比我们开发网站后台系统使用的缓存（比如 Redis）是为了解决程序处理速度和访问常规关系型数据库速度不对等的问题。 **CPU 缓存则是为了解决 CPU 处理速度和内存处理速度不对等的问题。** + +我们甚至可以把 **内存可以看作外存的高速缓存**，程序运行的时候我们把外存的数据复制到内存，由于内存的处理速度远远高于外存，这样提高了处理速度。 + +总结：**CPU Cache 缓存的是内存数据用于解决 CPU 处理速度和内存不匹配的问题，内存缓存的是硬盘数据用于解决硬盘访问速度过慢的问题。** + +为了更好地理解，我画了一个简单的 CPU Cache 示意图如下（实际上，现代的 CPU Cache 通常分为三层，分别叫 L1,L2,L3 Cache）: + +![cpu-cache](./images/interview-questions/cpu-cache.png) + +**CPU Cache 的工作方式：** + +先复制一份数据到 CPU Cache 中，当 CPU 需要用到的时候就可以直接从 CPU Cache 中读取数据，当运算完成后，再将运算得到的数据写回 Main Memory 中。但是，这样存在 **内存缓存不一致性的问题** ！比如我执行一个 i++操作的话，如果两个线程同时执行的话，假设两个线程从 CPU Cache 中读取的 i=1，两个线程做了 1++运算完之后再写回 Main Memory 之后 i=2，而正确结果应该是 i=3。 + +**CPU 为了解决内存缓存不一致性问题可以通过制定缓存一致协议或者其他手段来解决。** + +### 2.2. 讲一下 JMM(Java 内存模型) + +Java 内存模型抽象了线程和主内存之间的关系，就比如说线程之间的共享变量必须存储在主内存中。Java 内存模型主要目的是为了屏蔽系统和硬件的差异，避免一套代码在不同的平台下产生的效果不一致。 + +在 JDK1.2 之前，Java 的内存模型实现总是从**主存**（即共享内存）读取变量，是不需要进行特别的注意的。而在当前的 Java 内存模型下，线程可以把变量保存**本地内存**（比如机器的寄存器）中，而不是直接在主存中进行读写。这就可能造成一个线程在主存中修改了一个变量的值，而另外一个线程还继续使用它在寄存器中的变量值的拷贝，造成**数据的不一致**。 + +> - **主内存** ：所有线程创建的实例对象都存放在主内存中，不管该实例对象是成员变量还是方法中的本地变量(也称局部变量) +> - **本地内存** ：每个线程都有一个私有的本地内存来存储共享变量的副本，并且，每个线程只能访问自己的本地内存，无法访问其他线程的本地内存。本地内存是 JMM 抽象出来的一个概念，存储了主内存中的共享变量副本。 + +![JMM(Java 内存模型)](./images/interview-questions/jmm.png) + +要解决这个问题，就需要把变量声明为 **`volatile`** ，这就指示 JVM，这个变量是共享且不稳定的，每次使用它都到主存中进行读取。 + +所以，**`volatile` 关键字 除了防止 JVM 的指令重排 ，还有一个重要的作用就是保证变量的可见性。** + +![volatile关键字可见性](./images/interview-questions/jmm2.png) + +### 2.3. 并发编程的三个重要特性 + +1. **原子性** : 一次操作或者多次操作，要么所有的操作全部都得到执行并且不会受到任何因素的干扰而中断，要么都不执行。`synchronized` 可以保证代码片段的原子性。 +2. **可见性** ：当一个线程对共享变量进行了修改，那么另外的线程都是立即可以看到修改后的最新值。`volatile` 关键字可以保证共享变量的可见性。 +3. **有序性** ：代码在执行的过程中的先后顺序，Java 在编译器以及运行期间的优化，代码的执行顺序未必就是编写代码时候的顺序。`volatile` 关键字可以禁止指令进行重排序优化。 + +### 2.4. 说说 synchronized 关键字和 volatile 关键字的区别 + +`synchronized` 关键字和 `volatile` 关键字是两个互补的存在，而不是对立的存在！ + +- **`volatile` 关键字**是线程同步的**轻量级实现**，所以 **`volatile `性能肯定比` synchronized `关键字要好** 。但是 **`volatile` 关键字只能用于变量而 `synchronized` 关键字可以修饰方法以及代码块** 。 +- **`volatile` 关键字能保证数据的可见性，但不能保证数据的原子性。`synchronized` 关键字两者都能保证。** +- **`volatile`关键字主要用于解决变量在多个线程之间的可见性，而 `synchronized` 关键字解决的是多个线程之间访问资源的同步性。** + +## 3. ThreadLocal + +### 3.1. ThreadLocal 简介 + +通常情况下，我们创建的变量是可以被任何一个线程访问并修改的。**如果想实现每一个线程都有自己的专属本地变量该如何解决呢？** JDK 中提供的`ThreadLocal`类正是为了解决这样的问题。 **`ThreadLocal`类主要解决的就是让每个线程绑定自己的值，可以将`ThreadLocal`类形象的比喻成存放数据的盒子，盒子中可以存储每个线程的私有数据。** + +**如果你创建了一个`ThreadLocal`变量，那么访问这个变量的每个线程都会有这个变量的本地副本，这也是`ThreadLocal`变量名的由来。他们可以使用 `get（）` 和 `set（）` 方法来获取默认值或将其值更改为当前线程所存的副本的值，从而避免了线程安全问题。** + +再举个简单的例子： + +比如有两个人去宝屋收集宝物，这两个共用一个袋子的话肯定会产生争执，但是给他们两个人每个人分配一个袋子的话就不会出现这样的问题。如果把这两个人比作线程的话，那么 ThreadLocal 就是用来避免这两个线程竞争的。 + +### 3.2. ThreadLocal 示例 + +相信看了上面的解释，大家已经搞懂 ThreadLocal 类是个什么东西了。 + +```java +import java.text.SimpleDateFormat; +import java.util.Random; + +public class ThreadLocalExample implements Runnable{ + + // SimpleDateFormat 不是线程安全的，所以每个线程都要有自己独立的副本 + private static final ThreadLocal formatter = ThreadLocal.withInitial(() -> new SimpleDateFormat("yyyyMMdd HHmm")); + + public static void main(String[] args) throws InterruptedException { + ThreadLocalExample obj = new ThreadLocalExample(); + for(int i=0 ; i<10; i++){ + Thread t = new Thread(obj, ""+i); + Thread.sleep(new Random().nextInt(1000)); + t.start(); + } + } + + @Override + public void run() { + System.out.println("Thread Name= "+Thread.currentThread().getName()+" default Formatter = "+formatter.get().toPattern()); + try { + Thread.sleep(new Random().nextInt(1000)); + } catch (InterruptedException e) { + e.printStackTrace(); + } + //formatter pattern is changed here by thread, but it won't reflect to other threads + formatter.set(new SimpleDateFormat()); + + System.out.println("Thread Name= "+Thread.currentThread().getName()+" formatter = "+formatter.get().toPattern()); + } + +} + +``` + +Output: + +``` +Thread Name= 0 default Formatter = yyyyMMdd HHmm +Thread Name= 0 formatter = yy-M-d ah:mm +Thread Name= 1 default Formatter = yyyyMMdd HHmm +Thread Name= 2 default Formatter = yyyyMMdd HHmm +Thread Name= 1 formatter = yy-M-d ah:mm +Thread Name= 3 default Formatter = yyyyMMdd HHmm +Thread Name= 2 formatter = yy-M-d ah:mm +Thread Name= 4 default Formatter = yyyyMMdd HHmm +Thread Name= 3 formatter = yy-M-d ah:mm +Thread Name= 4 formatter = yy-M-d ah:mm +Thread Name= 5 default Formatter = yyyyMMdd HHmm +Thread Name= 5 formatter = yy-M-d ah:mm +Thread Name= 6 default Formatter = yyyyMMdd HHmm +Thread Name= 6 formatter = yy-M-d ah:mm +Thread Name= 7 default Formatter = yyyyMMdd HHmm +Thread Name= 7 formatter = yy-M-d ah:mm +Thread Name= 8 default Formatter = yyyyMMdd HHmm +Thread Name= 9 default Formatter = yyyyMMdd HHmm +Thread Name= 8 formatter = yy-M-d ah:mm +Thread Name= 9 formatter = yy-M-d ah:mm +``` + +从输出中可以看出，Thread-0 已经改变了 formatter 的值，但仍然是 thread-2 默认格式化程序与初始化值相同，其他线程也一样。 + +上面有一段代码用到了创建 `ThreadLocal` 变量的那段代码用到了 Java8 的知识，它等于下面这段代码，如果你写了下面这段代码的话，IDEA 会提示你转换为 Java8 的格式(IDEA 真的不错！)。因为 ThreadLocal 类在 Java 8 中扩展，使用一个新的方法`withInitial()`，将 Supplier 功能接口作为参数。 + +```java +private static final ThreadLocal formatter = new ThreadLocal(){ + @Override + protected SimpleDateFormat initialValue(){ + return new SimpleDateFormat("yyyyMMdd HHmm"); + } +}; +``` + +### 3.3. ThreadLocal 原理 + +从 `Thread`类源代码入手。 + +```java +public class Thread implements Runnable { + //...... + //与此线程有关的ThreadLocal值。由ThreadLocal类维护 + ThreadLocal.ThreadLocalMap threadLocals = null; + + //与此线程有关的InheritableThreadLocal值。由InheritableThreadLocal类维护 + ThreadLocal.ThreadLocalMap inheritableThreadLocals = null; + //...... +} +``` + +从上面`Thread`类 源代码可以看出`Thread` 类中有一个 `threadLocals` 和 一个 `inheritableThreadLocals` 变量，它们都是 `ThreadLocalMap` 类型的变量,我们可以把 `ThreadLocalMap` 理解为`ThreadLocal` 类实现的定制化的 `HashMap`。默认情况下这两个变量都是 null，只有当前线程调用 `ThreadLocal` 类的 `set`或`get`方法时才创建它们，实际上调用这两个方法的时候，我们调用的是`ThreadLocalMap`类对应的 `get()`、`set()`方法。 + +`ThreadLocal`类的`set()`方法 + +```java +public void set(T value) { + Thread t = Thread.currentThread(); + ThreadLocalMap map = getMap(t); + if (map != null) + map.set(this, value); + else + createMap(t, value); +} +ThreadLocalMap getMap(Thread t) { + return t.threadLocals; +} +``` + +通过上面这些内容，我们足以通过猜测得出结论：**最终的变量是放在了当前线程的 `ThreadLocalMap` 中，并不是存在 `ThreadLocal` 上，`ThreadLocal` 可以理解为只是`ThreadLocalMap`的封装，传递了变量值。** `ThrealLocal` 类中可以通过`Thread.currentThread()`获取到当前线程对象后，直接通过`getMap(Thread t)`可以访问到该线程的`ThreadLocalMap`对象。 + +**每个`Thread`中都具备一个`ThreadLocalMap`，而`ThreadLocalMap`可以存储以`ThreadLocal`为 key ，Object 对象为 value 的键值对。** + +```java +ThreadLocalMap(ThreadLocal firstKey, Object firstValue) { + //...... +} +``` + +比如我们在同一个线程中声明了两个 `ThreadLocal` 对象的话， `Thread`内部都是使用仅有的那个`ThreadLocalMap` 存放数据的，`ThreadLocalMap`的 key 就是 `ThreadLocal`对象，value 就是 `ThreadLocal` 对象调用`set`方法设置的值。 + +![ThreadLocal数据结构](./images/threadlocal数据结构.png) + +`ThreadLocalMap`是`ThreadLocal`的静态内部类。 + +![ThreadLocal内部类](./images/ThreadLocal内部类.png) + +### 3.4. ThreadLocal 内存泄露问题 + +`ThreadLocalMap` 中使用的 key 为 `ThreadLocal` 的弱引用,而 value 是强引用。所以，如果 `ThreadLocal` 没有被外部强引用的情况下，在垃圾回收的时候，key 会被清理掉，而 value 不会被清理掉。这样一来，`ThreadLocalMap` 中就会出现 key 为 null 的 Entry。假如我们不做任何措施的话，value 永远无法被 GC 回收，这个时候就可能会产生内存泄露。ThreadLocalMap 实现中已经考虑了这种情况，在调用 `set()`、`get()`、`remove()` 方法的时候，会清理掉 key 为 null 的记录。使用完 `ThreadLocal`方法后 最好手动调用`remove()`方法 + +```java +static class Entry extends WeakReference> { + /** The value associated with this ThreadLocal. */ + Object value; + + Entry(ThreadLocal k, Object v) { + super(k); + value = v; + } +} +``` + +**弱引用介绍：** + +> 如果一个对象只具有弱引用，那就类似于**可有可无的生活用品**。弱引用与软引用的区别在于：只具有弱引用的对象拥有更短暂的生命周期。在垃圾回收器线程扫描它 所管辖的内存区域的过程中，一旦发现了只具有弱引用的对象，不管当前内存空间足够与否，都会回收它的内存。不过，由于垃圾回收器是一个优先级很低的线程， 因此不一定会很快发现那些只具有弱引用的对象。 +> +> 弱引用可以和一个引用队列（ReferenceQueue）联合使用，如果弱引用所引用的对象被垃圾回收，Java 虚拟机就会把这个弱引用加入到与之关联的引用队列中。 + +## 4. 线程池 + +### 4.1. 为什么要用线程池？ + +> **池化技术想必大家已经屡见不鲜了，线程池、数据库连接池、Http 连接池等等都是对这个思想的应用。池化技术的思想主要是为了减少每次获取资源的消耗，提高对资源的利用率。** + +**线程池**提供了一种限制和管理资源（包括执行一个任务）的方式。 每个**线程池**还维护一些基本统计信息，例如已完成任务的数量。 + +这里借用《Java 并发编程的艺术》提到的来说一下**使用线程池的好处**： + +- **降低资源消耗**。通过重复利用已创建的线程降低线程创建和销毁造成的消耗。 +- **提高响应速度**。当任务到达时，任务可以不需要等到线程创建就能立即执行。 +- **提高线程的可管理性**。线程是稀缺资源，如果无限制的创建，不仅会消耗系统资源，还会降低系统的稳定性，使用线程池可以进行统一的分配，调优和监控。 + +### 4.2. 实现 Runnable 接口和 Callable 接口的区别 + +`Runnable`自 Java 1.0 以来一直存在，但`Callable`仅在 Java 1.5 中引入,目的就是为了来处理`Runnable`不支持的用例。**`Runnable` 接口** 不会返回结果或抛出检查异常，但是 **`Callable` 接口** 可以。所以，如果任务不需要返回结果或抛出异常推荐使用 **`Runnable` 接口** ，这样代码看起来会更加简洁。 + +工具类 `Executors` 可以实现将 `Runnable` 对象转换成 `Callable` 对象。（`Executors.callable(Runnable task)` 或 `Executors.callable(Runnable task, Object result)`）。 + +`Runnable.java` + +```java +@FunctionalInterface +public interface Runnable { + /** + * 被线程执行，没有返回值也无法抛出异常 + */ + public abstract void run(); +} +``` + +`Callable.java` + +```java +@FunctionalInterface +public interface Callable { + /** + * 计算结果，或在无法这样做时抛出异常。 + * @return 计算得出的结果 + * @throws 如果无法计算结果，则抛出异常 + */ + V call() throws Exception; +} +``` + +### 4.3. 执行 execute()方法和 submit()方法的区别是什么呢？ + +1. **`execute()`方法用于提交不需要返回值的任务，所以无法判断任务是否被线程池执行成功与否；** +2. **`submit()`方法用于提交需要返回值的任务。线程池会返回一个 `Future` 类型的对象，通过这个 `Future` 对象可以判断任务是否执行成功**，并且可以通过 `Future` 的 `get()`方法来获取返回值，`get()`方法会阻塞当前线程直到任务完成，而使用 `get(long timeout，TimeUnit unit)`方法则会阻塞当前线程一段时间后立即返回，这时候有可能任务没有执行完。 + +我们以 **`AbstractExecutorService` 接口** 中的一个 `submit` 方法为例子来看看源代码： + +```java +public Future submit(Runnable task) { + if (task == null) throw new NullPointerException(); + RunnableFuture ftask = newTaskFor(task, null); + execute(ftask); + return ftask; +} +``` + +上面方法调用的 `newTaskFor` 方法返回了一个 `FutureTask` 对象。 + +```java +protected RunnableFuture newTaskFor(Runnable runnable, T value) { + return new FutureTask(runnable, value); +} +``` + +我们再来看看`execute()`方法： + +```java +public void execute(Runnable command) { + ... +} +``` + +### 4.4. 如何创建线程池 + +《阿里巴巴 Java 开发手册》中强制线程池不允许使用 Executors 去创建，而是通过 ThreadPoolExecutor 的方式，这样的处理方式让写的同学更加明确线程池的运行规则，规避资源耗尽的风险 + +> Executors 返回线程池对象的弊端如下： +> +> - **FixedThreadPool 和 SingleThreadExecutor** ： 允许请求的队列长度为 Integer.MAX_VALUE ，可能堆积大量的请求，从而导致 OOM。 +> - **CachedThreadPool 和 ScheduledThreadPool** ： 允许创建的线程数量为 Integer.MAX_VALUE ，可能会创建大量线程，从而导致 OOM。 + +**方式一：通过构造方法实现** + +![ThreadPoolExecutor构造方法](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/2019-6/ThreadPoolExecutor构造方法.png) + +**方式二：通过 Executor 框架的工具类 Executors 来实现** + +我们可以创建三种类型的 ThreadPoolExecutor： + +- **FixedThreadPool** ： 该方法返回一个固定线程数量的线程池。该线程池中的线程数量始终不变。当有一个新的任务提交时，线程池中若有空闲线程，则立即执行。若没有，则新的任务会被暂存在一个任务队列中，待有线程空闲时，便处理在任务队列中的任务。 +- **SingleThreadExecutor：** 方法返回一个只有一个线程的线程池。若多余一个任务被提交到该线程池，任务会被保存在一个任务队列中，待线程空闲，按先入先出的顺序执行队列中的任务。 +- **CachedThreadPool：** 该方法返回一个可根据实际情况调整线程数量的线程池。线程池的线程数量不确定，但若有空闲线程可以复用，则会优先使用可复用的线程。若所有线程均在工作，又有新的任务提交，则会创建新的线程处理任务。所有线程在当前任务执行完毕后，将返回线程池进行复用。 + +对应 Executors 工具类中的方法如图所示： + +![Executor框架的工具类](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/2019-6/Executor框架的工具类.png) + +### 4.5 ThreadPoolExecutor 类分析 + +`ThreadPoolExecutor` 类中提供的四个构造方法。我们来看最长的那个，其余三个都是在这个构造方法的基础上产生（其他几个构造方法说白点都是给定某些默认参数的构造方法比如默认制定拒绝策略是什么），这里就不贴代码讲了，比较简单。 + +```java +/** + * 用给定的初始参数创建一个新的ThreadPoolExecutor。 + */ +public ThreadPoolExecutor(int corePoolSize, + int maximumPoolSize, + long keepAliveTime, + TimeUnit unit, + BlockingQueue workQueue, + ThreadFactory threadFactory, + RejectedExecutionHandler handler) { + if (corePoolSize < 0 || + maximumPoolSize <= 0 || + maximumPoolSize < corePoolSize || + keepAliveTime < 0) + throw new IllegalArgumentException(); + if (workQueue == null || threadFactory == null || handler == null) + throw new NullPointerException(); + this.corePoolSize = corePoolSize; + this.maximumPoolSize = maximumPoolSize; + this.workQueue = workQueue; + this.keepAliveTime = unit.toNanos(keepAliveTime); + this.threadFactory = threadFactory; + this.handler = handler; +} +``` + +**下面这些对创建 非常重要，在后面使用线程池的过程中你一定会用到！所以，务必拿着小本本记清楚。** + +#### 4.5.1 `ThreadPoolExecutor`构造函数重要参数分析 + +**`ThreadPoolExecutor` 3 个最重要的参数：** + +- **`corePoolSize` :** 核心线程数定义了最小可以同时运行的线程数量。 +- **`maximumPoolSize` :** 当队列中存放的任务达到队列容量的时候，当前可以同时运行的线程数量变为最大线程数。 +- **`workQueue`:** 当新任务来的时候会先判断当前运行的线程数量是否达到核心线程数，如果达到的话，新任务就会被存放在队列中。 + +`ThreadPoolExecutor`其他常见参数: + +1. **`keepAliveTime`**:当线程池中的线程数量大于 `corePoolSize` 的时候，如果这时没有新的任务提交，核心线程外的线程不会立即销毁，而是会等待，直到等待的时间超过了 `keepAliveTime`才会被回收销毁； +2. **`unit`** : `keepAliveTime` 参数的时间单位。 +3. **`threadFactory`** :executor 创建新线程的时候会用到。 +4. **`handler`** :饱和策略。关于饱和策略下面单独介绍一下。 + +#### 4.5.2 `ThreadPoolExecutor` 饱和策略 + +**`ThreadPoolExecutor` 饱和策略定义:** + +如果当前同时运行的线程数量达到最大线程数量并且队列也已经被放满了任务时，`ThreadPoolTaskExecutor` 定义一些策略: + +- **`ThreadPoolExecutor.AbortPolicy`：** 抛出 `RejectedExecutionException`来拒绝新任务的处理。 +- **`ThreadPoolExecutor.CallerRunsPolicy`：** 调用执行自己的线程运行任务，也就是直接在调用`execute`方法的线程中运行(`run`)被拒绝的任务，如果执行程序已关闭，则会丢弃该任务。因此这种策略会降低对于新任务提交速度，影响程序的整体性能。如果您的应用程序可以承受此延迟并且你要求任何一个任务请求都要被执行的话，你可以选择这个策略。 +- **`ThreadPoolExecutor.DiscardPolicy`：** 不处理新任务，直接丢弃掉。 +- **`ThreadPoolExecutor.DiscardOldestPolicy`：** 此策略将丢弃最早的未处理的任务请求。 + +举个例子： Spring 通过 `ThreadPoolTaskExecutor` 或者我们直接通过 `ThreadPoolExecutor` 的构造函数创建线程池的时候，当我们不指定 `RejectedExecutionHandler` 饱和策略的话来配置线程池的时候默认使用的是 `ThreadPoolExecutor.AbortPolicy`。在默认情况下，`ThreadPoolExecutor` 将抛出 `RejectedExecutionException` 来拒绝新来的任务 ，这代表你将丢失对这个任务的处理。 对于可伸缩的应用程序，建议使用 `ThreadPoolExecutor.CallerRunsPolicy`。当最大池被填满时，此策略为我们提供可伸缩队列。（这个直接查看 `ThreadPoolExecutor` 的构造函数源码就可以看出，比较简单的原因，这里就不贴代码了） + +### 4.6 一个简单的线程池 Demo + +为了让大家更清楚上面的面试题中的一些概念，我写了一个简单的线程池 Demo。 + +首先创建一个 `Runnable` 接口的实现类（当然也可以是 `Callable` 接口，我们上面也说了两者的区别。） + +`MyRunnable.java` + +```java +import java.util.Date; + +/** + * 这是一个简单的Runnable类，需要大约5秒钟来执行其任务。 + * @author shuang.kou + */ +public class MyRunnable implements Runnable { + + private String command; + + public MyRunnable(String s) { + this.command = s; + } + + @Override + public void run() { + System.out.println(Thread.currentThread().getName() + " Start. Time = " + new Date()); + processCommand(); + System.out.println(Thread.currentThread().getName() + " End. Time = " + new Date()); + } + + private void processCommand() { + try { + Thread.sleep(5000); + } catch (InterruptedException e) { + e.printStackTrace(); + } + } + + @Override + public String toString() { + return this.command; + } +} + +``` + +编写测试程序，我们这里以阿里巴巴推荐的使用 `ThreadPoolExecutor` 构造函数自定义参数的方式来创建线程池。 + +`ThreadPoolExecutorDemo.java` + +```java +import java.util.concurrent.ArrayBlockingQueue; +import java.util.concurrent.ThreadPoolExecutor; +import java.util.concurrent.TimeUnit; + +public class ThreadPoolExecutorDemo { + + private static final int CORE_POOL_SIZE = 5; + private static final int MAX_POOL_SIZE = 10; + private static final int QUEUE_CAPACITY = 100; + private static final Long KEEP_ALIVE_TIME = 1L; + public static void main(String[] args) { + + //使用阿里巴巴推荐的创建线程池的方式 + //通过ThreadPoolExecutor构造函数自定义参数创建 + ThreadPoolExecutor executor = new ThreadPoolExecutor( + CORE_POOL_SIZE, + MAX_POOL_SIZE, + KEEP_ALIVE_TIME, + TimeUnit.SECONDS, + new ArrayBlockingQueue<>(QUEUE_CAPACITY), + new ThreadPoolExecutor.CallerRunsPolicy()); + + for (int i = 0; i < 10; i++) { + //创建WorkerThread对象（WorkerThread类实现了Runnable 接口） + Runnable worker = new MyRunnable("" + i); + //执行Runnable + executor.execute(worker); + } + //终止线程池 + executor.shutdown(); + while (!executor.isTerminated()) { + } + System.out.println("Finished all threads"); + } +} +``` + +可以看到我们上面的代码指定了： + +1. `corePoolSize`: 核心线程数为 5。 +2. `maximumPoolSize` ：最大线程数 10 +3. `keepAliveTime` : 等待时间为 1L。 +4. `unit`: 等待时间的单位为 TimeUnit.SECONDS。 +5. `workQueue`：任务队列为 `ArrayBlockingQueue`，并且容量为 100; +6. `handler`:饱和策略为 `CallerRunsPolicy`。 + +**Output：** + +``` +pool-1-thread-3 Start. Time = Sun Apr 12 11:14:37 CST 2020 +pool-1-thread-5 Start. Time = Sun Apr 12 11:14:37 CST 2020 +pool-1-thread-2 Start. Time = Sun Apr 12 11:14:37 CST 2020 +pool-1-thread-1 Start. Time = Sun Apr 12 11:14:37 CST 2020 +pool-1-thread-4 Start. Time = Sun Apr 12 11:14:37 CST 2020 +pool-1-thread-3 End. Time = Sun Apr 12 11:14:42 CST 2020 +pool-1-thread-4 End. Time = Sun Apr 12 11:14:42 CST 2020 +pool-1-thread-1 End. Time = Sun Apr 12 11:14:42 CST 2020 +pool-1-thread-5 End. Time = Sun Apr 12 11:14:42 CST 2020 +pool-1-thread-1 Start. Time = Sun Apr 12 11:14:42 CST 2020 +pool-1-thread-2 End. Time = Sun Apr 12 11:14:42 CST 2020 +pool-1-thread-5 Start. Time = Sun Apr 12 11:14:42 CST 2020 +pool-1-thread-4 Start. Time = Sun Apr 12 11:14:42 CST 2020 +pool-1-thread-3 Start. Time = Sun Apr 12 11:14:42 CST 2020 +pool-1-thread-2 Start. Time = Sun Apr 12 11:14:42 CST 2020 +pool-1-thread-1 End. Time = Sun Apr 12 11:14:47 CST 2020 +pool-1-thread-4 End. Time = Sun Apr 12 11:14:47 CST 2020 +pool-1-thread-5 End. Time = Sun Apr 12 11:14:47 CST 2020 +pool-1-thread-3 End. Time = Sun Apr 12 11:14:47 CST 2020 +pool-1-thread-2 End. Time = Sun Apr 12 11:14:47 CST 2020 + +``` + +### 4.7 线程池原理分析 + +承接 4.6 节，我们通过代码输出结果可以看出：**线程池首先会先执行 5 个任务，然后这些任务有任务被执行完的话，就会去拿新的任务执行。** 大家可以先通过上面讲解的内容，分析一下到底是咋回事？（自己独立思考一会） + +现在，我们就分析上面的输出内容来简单分析一下线程池原理。 + +**为了搞懂线程池的原理，我们需要首先分析一下 `execute`方法。** 在 4.6 节中的 Demo 中我们使用 `executor.execute(worker)`来提交一个任务到线程池中去，这个方法非常重要，下面我们来看看它的源码： + +```java +// 存放线程池的运行状态 (runState) 和线程池内有效线程的数量 (workerCount) +private final AtomicInteger ctl = new AtomicInteger(ctlOf(RUNNING, 0)); + +private static int workerCountOf(int c) { + return c & CAPACITY; +} + +private final BlockingQueue workQueue; + +public void execute(Runnable command) { + // 如果任务为null，则抛出异常。 + if (command == null) + throw new NullPointerException(); + // ctl 中保存的线程池当前的一些状态信息 + int c = ctl.get(); + + // 下面会涉及到 3 步 操作 + // 1.首先判断当前线程池中执行的任务数量是否小于 corePoolSize + // 如果小于的话，通过addWorker(command, true)新建一个线程，并将任务(command)添加到该线程中；然后，启动该线程从而执行任务。 + if (workerCountOf(c) < corePoolSize) { + if (addWorker(command, true)) + return; + c = ctl.get(); + } + // 2.如果当前执行的任务数量大于等于 corePoolSize 的时候就会走到这里 + // 通过 isRunning 方法判断线程池状态，线程池处于 RUNNING 状态并且队列可以加入任务，该任务才会被加入进去 + if (isRunning(c) && workQueue.offer(command)) { + int recheck = ctl.get(); + // 再次获取线程池状态，如果线程池状态不是 RUNNING 状态就需要从任务队列中移除任务，并尝试判断线程是否全部执行完毕。同时执行拒绝策略。 + if (!isRunning(recheck) && remove(command)) + reject(command); + // 如果当前线程池为空就新创建一个线程并执行。 + else if (workerCountOf(recheck) == 0) + addWorker(null, false); + } + //3. 通过addWorker(command, false)新建一个线程，并将任务(command)添加到该线程中；然后，启动该线程从而执行任务。 + //如果addWorker(command, false)执行失败，则通过reject()执行相应的拒绝策略的内容。 + else if (!addWorker(command, false)) + reject(command); +} +``` + +通过下图可以更好的对上面这 3 步做一个展示，下图是我为了省事直接从网上找到，原地址不明。 + +![图解线程池实现原理](./images/java-thread-pool-summary/图解线程池实现原理.png) + +现在，让我们在回到 4.6 节我们写的 Demo， 现在是不是很容易就可以搞懂它的原理了呢？ + +没搞懂的话，也没关系，可以看看我的分析： + +> 我们在代码中模拟了 10 个任务，我们配置的核心线程数为 5 、等待队列容量为 100 ，所以每次只可能存在 5 个任务同时执行，剩下的 5 个任务会被放到等待队列中去。当前的5个任务中如果有任务被执行完了，线程池就会去拿新的任务执行。 + +## 5. Atomic 原子类 + +### 5.1. 介绍一下 Atomic 原子类 + +`Atomic` 翻译成中文是原子的意思。在化学上，我们知道原子是构成一般物质的最小单位，在化学反应中是不可分割的。在我们这里 Atomic 是指一个操作是不可中断的。即使是在多个线程一起执行的时候，一个操作一旦开始，就不会被其他线程干扰。 + +所以，所谓原子类说简单点就是具有原子/原子操作特征的类。 + +并发包 `java.util.concurrent` 的原子类都存放在`java.util.concurrent.atomic`下,如下图所示。 + +![JUC原子类概览](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/2019-6/JUC原子类概览.png) + +### 5.2. JUC 包中的原子类是哪 4 类? + +**基本类型** + +使用原子的方式更新基本类型 + +- `AtomicInteger`：整形原子类 +- `AtomicLong`：长整型原子类 +- `AtomicBoolean`：布尔型原子类 + +**数组类型** + +使用原子的方式更新数组里的某个元素 + +- `AtomicIntegerArray`：整形数组原子类 +- `AtomicLongArray`：长整形数组原子类 +- `AtomicReferenceArray`：引用类型数组原子类 + +**引用类型** + +- `AtomicReference`：引用类型原子类 +- `AtomicStampedReference`：原子更新带有版本号的引用类型。该类将整数值与引用关联起来，可用于解决原子的更新数据和数据的版本号，可以解决使用 CAS 进行原子更新时可能出现的 ABA 问题。 +- `AtomicMarkableReference` ：原子更新带有标记位的引用类型 + +**对象的属性修改类型** + +- `AtomicIntegerFieldUpdater`：原子更新整形字段的更新器 +- `AtomicLongFieldUpdater`：原子更新长整形字段的更新器 +- `AtomicReferenceFieldUpdater`：原子更新引用类型字段的更新器 + +### 5.3. 讲讲 AtomicInteger 的使用 + +**AtomicInteger 类常用方法** + +```java +public final int get() //获取当前的值 +public final int getAndSet(int newValue)//获取当前的值，并设置新的值 +public final int getAndIncrement()//获取当前的值，并自增 +public final int getAndDecrement() //获取当前的值，并自减 +public final int getAndAdd(int delta) //获取当前的值，并加上预期的值 +boolean compareAndSet(int expect, int update) //如果输入的数值等于预期值，则以原子方式将该值设置为输入值（update） +public final void lazySet(int newValue)//最终设置为newValue,使用 lazySet 设置之后可能导致其他线程在之后的一小段时间内还是可以读到旧的值。 +``` + +**AtomicInteger 类的使用示例** + +使用 AtomicInteger 之后，不用对 increment() 方法加锁也可以保证线程安全。 + +```java +class AtomicIntegerTest { + private AtomicInteger count = new AtomicInteger(); + //使用AtomicInteger之后，不需要对该方法加锁，也可以实现线程安全。 + public void increment() { + count.incrementAndGet(); + } + + public int getCount() { + return count.get(); + } +} + +``` + +### 5.4. 能不能给我简单介绍一下 AtomicInteger 类的原理 + +AtomicInteger 线程安全原理简单分析 + +AtomicInteger 类的部分源码： + +```java +// setup to use Unsafe.compareAndSwapInt for updates（更新操作时提供“比较并替换”的作用） +private static final Unsafe unsafe = Unsafe.getUnsafe(); +private static final long valueOffset; + +static { + try { + valueOffset = unsafe.objectFieldOffset + (AtomicInteger.class.getDeclaredField("value")); + } catch (Exception ex) { throw new Error(ex); } +} + +private volatile int value; +``` + +AtomicInteger 类主要利用 CAS (compare and swap) + volatile 和 native 方法来保证原子操作，从而避免 synchronized 的高开销，执行效率大为提升。 + +CAS 的原理是拿期望的值和原本的一个值作比较，如果相同则更新成新的值。UnSafe 类的 objectFieldOffset() 方法是一个本地方法，这个方法是用来拿到“原来的值”的内存地址，返回值是 valueOffset。另外 value 是一个 volatile 变量，在内存中可见，因此 JVM 可以保证任何时刻任何线程总能拿到该变量的最新值。 + +关于 Atomic 原子类这部分更多内容可以查看我的这篇文章：并发编程面试必备：[JUC 中的 Atomic 原子类总结](https://mp.weixin.qq.com/s?__biz=Mzg2OTA0Njk0OA==&mid=2247484834&idx=1&sn=7d3835091af8125c13fc6db765f4c5bd&source=41#wechat_redirect) + +## 6. AQS + +### 6.1. AQS 介绍 + +AQS 的全称为（`AbstractQueuedSynchronizer`），这个类在` java.util.concurrent.locks `包下面。 + +![AQS类](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/2019-6/AQS类.png) + +AQS 是一个用来构建锁和同步器的框架，使用 AQS 能简单且高效地构造出大量应用广泛的同步器，比如我们提到的 `ReentrantLock`，`Semaphore`，其他的诸如 `ReentrantReadWriteLock`，`SynchronousQueue`，`FutureTask` 等等皆是基于 AQS 的。当然，我们自己也能利用 AQS 非常轻松容易地构造出符合我们自己需求的同步器。 + +### 6.2. AQS 原理分析 + +AQS 原理这部分参考了部分博客，在 6.2 节末尾放了链接。 + +> 在面试中被问到并发知识的时候，大多都会被问到“请你说一下自己对于 AQS 原理的理解”。下面给大家一个示例供大家参加，面试不是背题，大家一定要加入自己的思想，即使加入不了自己的思想也要保证自己能够通俗的讲出来而不是背出来。 + +下面大部分内容其实在 AQS 类注释上已经给出了，不过是英语看着比较吃力一点，感兴趣的话可以看看源码。 + +#### 6.2.1. AQS 原理概览 + +**AQS 核心思想是，如果被请求的共享资源空闲，则将当前请求资源的线程设置为有效的工作线程，并且将共享资源设置为锁定状态。如果被请求的共享资源被占用，那么就需要一套线程阻塞等待以及被唤醒时锁分配的机制，这个机制 AQS 是用 CLH 队列锁实现的，即将暂时获取不到锁的线程加入到队列中。** + +> CLH(Craig,Landin and Hagersten)队列是一个虚拟的双向队列（虚拟的双向队列即不存在队列实例，仅存在结点之间的关联关系）。AQS 是将每条请求共享资源的线程封装成一个 CLH 锁队列的一个结点（Node）来实现锁的分配。 + +看个 AQS(AbstractQueuedSynchronizer)原理图： + +![AQS原理图](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/2019-6/AQS原理图.png) + +AQS 使用一个 int 成员变量来表示同步状态，通过内置的 FIFO 队列来完成获取资源线程的排队工作。AQS 使用 CAS 对该同步状态进行原子操作实现对其值的修改。 + +```java +private volatile int state;//共享变量，使用volatile修饰保证线程可见性 +``` + +状态信息通过 protected 类型的 getState，setState，compareAndSetState 进行操作 + +```java + +//返回同步状态的当前值 +protected final int getState() { + return state; +} +//设置同步状态的值 +protected final void setState(int newState) { + state = newState; +} +//原子地（CAS操作）将同步状态值设置为给定值update如果当前同步状态的值等于expect（期望值） +protected final boolean compareAndSetState(int expect, int update) { + return unsafe.compareAndSwapInt(this, stateOffset, expect, update); +} +``` + +#### 6.2.2. AQS 对资源的共享方式 + +**AQS 定义两种资源共享方式** + +- **Exclusive**（独占）：只有一个线程能执行，如 `ReentrantLock`。又可分为公平锁和非公平锁： + - 公平锁：按照线程在队列中的排队顺序，先到者先拿到锁 + - 非公平锁：当线程要获取锁时，无视队列顺序直接去抢锁，谁抢到就是谁的 +- **Share**（共享）：多个线程可同时执行，如` CountDownLatch`、`Semaphore`、 `CyclicBarrier`、`ReadWriteLock` 我们都会在后面讲到。 + +`ReentrantReadWriteLock` 可以看成是组合式，因为 `ReentrantReadWriteLock` 也就是读写锁允许多个线程同时对某一资源进行读。 + +不同的自定义同步器争用共享资源的方式也不同。自定义同步器在实现时只需要实现共享资源 state 的获取与释放方式即可，至于具体线程等待队列的维护（如获取资源失败入队/唤醒出队等），AQS 已经在顶层实现好了。 + +#### 6.2.3. AQS 底层使用了模板方法模式 + +同步器的设计是基于模板方法模式的，如果需要自定义同步器一般的方式是这样（模板方法模式很经典的一个应用）： + +1. 使用者继承 `AbstractQueuedSynchronizer` 并重写指定的方法。（这些重写方法很简单，无非是对于共享资源 state 的获取和释放） +2. 将 AQS 组合在自定义同步组件的实现中，并调用其模板方法，而这些模板方法会调用使用者重写的方法。 + +这和我们以往通过实现接口的方式有很大区别，这是模板方法模式很经典的一个运用。 + +**AQS 使用了模板方法模式，自定义同步器时需要重写下面几个 AQS 提供的钩子方法：** + +```java +protected boolean tryAcquire(int)//独占方式。尝试获取资源，成功则返回true，失败则返回false。 +protected boolean tryRelease(int)//独占方式。尝试释放资源，成功则返回true，失败则返回false。 +protected int tryAcquireShared(int)//共享方式。尝试获取资源。负数表示失败；0表示成功，但没有剩余可用资源；正数表示成功，且有剩余资源。 +protected boolean tryReleaseShared(int)//共享方式。尝试释放资源，成功则返回true，失败则返回false。 +protected boolean isHeldExclusively()//该线程是否正在独占资源。只有用到condition才需要去实现它。 +``` + +**什么是钩子方法呢？** 钩子方法是一种被声明在抽象类中的方法，它可以是空方法（由子类实现），也可以是默认实现的方法。模板设计模式通过钩子方法控制固定步骤的实现。 + +除了上面提到的钩子方法之外，AQS 类中的其他方法都是 `final` ，所以无法被其他类重写。 + +以 `ReentrantLock` 为例，state 初始化为 0，表示未锁定状态。A 线程 `lock()` 时，会调用 `tryAcquire()` 独占该锁并将 `state+1` 。此后，其他线程再 `tryAcquire()` 时就会失败，直到 A 线程 `unlock()` 到 `state=`0（即释放锁）为止，其它线程才有机会获取该锁。当然，释放锁之前，A 线程自己是可以重复获取此锁的（state 会累加），这就是可重入的概念。但要注意，获取多少次就要释放多少次，这样才能保证 state 是能回到零态的。 + +再以 `CountDownLatch` 以例，任务分为 N 个子线程去执行，state 也初始化为 N（注意 N 要与线程个数一致）。这 N 个子线程是并行执行的，每个子线程执行完后` countDown()` 一次，state 会 CAS(Compare and Swap) 减 1。等到所有子线程都执行完后(即 `state=0` )，会 `unpark()` 主调用线程，然后主调用线程就会从 `await()` 函数返回，继续后余动作。 + +一般来说，自定义同步器要么是独占方法，要么是共享方式，他们也只需实现`tryAcquire-tryRelease`、`tryAcquireShared-tryReleaseShared`中的一种即可。但 AQS 也支持自定义同步器同时实现独占和共享两种方式，如`ReentrantReadWriteLock`。 + +推荐两篇 AQS 原理和相关源码分析的文章： + +- https://www.cnblogs.com/waterystone/p/4920797.html +- https://www.cnblogs.com/chengxiao/archive/2017/07/24/7141160.html + +### 6.3. AQS 组件总结 + +- **`Semaphore`(信号量)-允许多个线程同时访问：** `synchronized` 和 `ReentrantLock` 都是一次只允许一个线程访问某个资源，`Semaphore`(信号量)可以指定多个线程同时访问某个资源。 +- **`CountDownLatch `（倒计时器）：** `CountDownLatch` 是一个同步工具类，用来协调多个线程之间的同步。这个工具通常用来控制线程等待，它可以让某一个线程等待直到倒计时结束，再开始执行。 +- **`CyclicBarrier`(循环栅栏)：** `CyclicBarrier` 和 `CountDownLatch` 非常类似，它也可以实现线程间的技术等待，但是它的功能比 `CountDownLatch` 更加复杂和强大。主要应用场景和 `CountDownLatch` 类似。`CyclicBarrier` 的字面意思是可循环使用（`Cyclic`）的屏障（`Barrier`）。它要做的事情是，让一组线程到达一个屏障（也可以叫同步点）时被阻塞，直到最后一个线程到达屏障时，屏障才会开门，所有被屏障拦截的线程才会继续干活。`CyclicBarrier` 默认的构造方法是 `CyclicBarrier(int parties)`，其参数表示屏障拦截的线程数量，每个线程调用 `await()` 方法告诉 `CyclicBarrier` 我已经到达了屏障，然后当前线程被阻塞。 + +### 6.4. 用过 CountDownLatch 么？什么场景下用的？ + +`CountDownLatch` 的作用就是 允许 count 个线程阻塞在一个地方，直至所有线程的任务都执行完毕。之前在项目中，有一个使用多线程读取多个文件处理的场景，我用到了 `CountDownLatch` 。具体场景是下面这样的： + +我们要读取处理 6 个文件，这 6 个任务都是没有执行顺序依赖的任务，但是我们需要返回给用户的时候将这几个文件的处理的结果进行统计整理。 + +为此我们定义了一个线程池和 count 为 6 的`CountDownLatch`对象 。使用线程池处理读取任务，每一个线程处理完之后就将 count-1，调用`CountDownLatch`对象的 `await()`方法，直到所有文件读取完之后，才会接着执行后面的逻辑。 + +伪代码是下面这样的： + +```java +public class CountDownLatchExample1 { + // 处理文件的数量 + private static final int threadCount = 6; + + public static void main(String[] args) throws InterruptedException { + // 创建一个具有固定线程数量的线程池对象（推荐使用构造方法创建） + ExecutorService threadPool = Executors.newFixedThreadPool(10); + final CountDownLatch countDownLatch = new CountDownLatch(threadCount); + for (int i = 0; i < threadCount; i++) { + final int threadnum = i; + threadPool.execute(() -> { + try { + //处理文件的业务操作 + //...... + } catch (InterruptedException e) { + e.printStackTrace(); + } finally { + //表示一个文件已经被完成 + countDownLatch.countDown(); + } + + }); + } + countDownLatch.await(); + threadPool.shutdown(); + System.out.println("finish"); + } +} +``` + +**有没有可以改进的地方呢？** + +可以使用 `CompletableFuture` 类来改进！Java8 的 `CompletableFuture` 提供了很多对多线程友好的方法，使用它可以很方便地为我们编写多线程程序，什么异步、串行、并行或者等待所有线程执行完任务什么的都非常方便。 + +```java +CompletableFuture task1 = + CompletableFuture.supplyAsync(()->{ + //自定义业务操作 + }); +...... +CompletableFuture task6 = + CompletableFuture.supplyAsync(()->{ + //自定义业务操作 + }); +...... +CompletableFuture headerFuture=CompletableFuture.allOf(task1,.....,task6); + +try { + headerFuture.join(); +} catch (Exception ex) { + //...... +} +System.out.println("all done. "); +``` + +上面的代码还可以继续优化，当任务过多的时候，把每一个 task 都列出来不太现实，可以考虑通过循环来添加任务。 + +```java +//文件夹位置 +List filePaths = Arrays.asList(...) +// 异步处理所有文件 +List> fileFutures = filePaths.stream() + .map(filePath -> doSomeThing(filePath)) + .collect(Collectors.toList()); +// 将他们合并起来 +CompletableFuture allFutures = CompletableFuture.allOf( + fileFutures.toArray(new CompletableFuture[fileFutures.size()]) +); + +``` + +## 7 Reference + +- 《深入理解 Java 虚拟机》 +- 《实战 Java 高并发程序设计》 +- 《Java 并发编程的艺术》 +- https://www.cnblogs.com/waterystone/p/4920797.html +- https://www.cnblogs.com/chengxiao/archive/2017/07/24/7141160.html +- diff --git a/docs/java/concurrent/java-thread-pool-best-practices.md b/docs/java/concurrent/java-thread-pool-best-practices.md new file mode 100644 index 0000000000000000000000000000000000000000..d92705b70322a8b69127fc89a7f4c40bdef2511d --- /dev/null +++ b/docs/java/concurrent/java-thread-pool-best-practices.md @@ -0,0 +1,308 @@ +--- +title: Java 线程池最佳实践 +category: Java +tag: + - Java并发 +--- + +这篇文章篇幅虽短，但是绝对是干货。标题稍微有点夸张，嘿嘿，实际都是自己使用线程池的时候总结的一些个人感觉比较重要的点。 + +## 线程池知识回顾 + +开始这篇文章之前还是简单介绍一嘴线程池，之前写的[《新手也能看懂的线程池学习总结》](https://mp.weixin.qq.com/s?__biz=Mzg2OTA0Njk0OA==&mid=2247485808&idx=1&sn=1013253533d73450cef673aee13267ab&chksm=cea246bbf9d5cfad1c21316340a0ef1609a7457fea4113a1f8d69e8c91e7d9cd6285f5ee1490&token=510053261&lang=zh_CN&scene=21#wechat_redirect)这篇文章介绍的很详细了。 + +### 为什么要使用线程池？ + +> **池化技术想必大家已经屡见不鲜了，线程池、数据库连接池、Http 连接池等等都是对这个思想的应用。池化技术的思想主要是为了减少每次获取资源的消耗，提高对资源的利用率。** + +**线程池**提供了一种限制和管理资源（包括执行一个任务）的方式。 每个**线程池**还维护一些基本统计信息，例如已完成任务的数量。 + +这里借用《Java 并发编程的艺术》提到的来说一下**使用线程池的好处**： + +- **降低资源消耗**。通过重复利用已创建的线程降低线程创建和销毁造成的消耗。 +- **提高响应速度**。当任务到达时，任务可以不需要等到线程创建就能立即执行。 +- **提高线程的可管理性**。线程是稀缺资源，如果无限制的创建，不仅会消耗系统资源，还会降低系统的稳定性，使用线程池可以进行统一的分配，调优和监控。 + +### 线程池在实际项目的使用场景 + +**线程池一般用于执行多个不相关联的耗时任务，没有多线程的情况下，任务顺序执行，使用了线程池的话可让多个不相关联的任务同时执行。** + +假设我们要执行三个不相关的耗时任务，Guide 画图给大家展示了使用线程池前后的区别。 + +注意：**下面三个任务可能做的是同一件事情，也可能是不一样的事情。** + +![使用线程池前后对比](./images/thread-pool/1bc44c67-26ba-42ab-bcb8-4e29e6fd99b9.png) + +### 如何使用线程池？ + +一般是通过 `ThreadPoolExecutor` 的构造函数来创建线程池，然后提交任务给线程池执行就可以了。 + + `ThreadPoolExecutor`构造函数如下： + +```java + /** + * 用给定的初始参数创建一个新的ThreadPoolExecutor。 + */ + public ThreadPoolExecutor(int corePoolSize,//线程池的核心线程数量 + int maximumPoolSize,//线程池的最大线程数 + long keepAliveTime,//当线程数大于核心线程数时，多余的空闲线程存活的最长时间 + TimeUnit unit,//时间单位 + BlockingQueue workQueue,//任务队列，用来储存等待执行任务的队列 + ThreadFactory threadFactory,//线程工厂，用来创建线程，一般默认即可 + RejectedExecutionHandler handler//拒绝策略，当提交的任务过多而不能及时处理时，我们可以定制策略来处理任务 + ) { + if (corePoolSize < 0 || + maximumPoolSize <= 0 || + maximumPoolSize < corePoolSize || + keepAliveTime < 0) + throw new IllegalArgumentException(); + if (workQueue == null || threadFactory == null || handler == null) + throw new NullPointerException(); + this.corePoolSize = corePoolSize; + this.maximumPoolSize = maximumPoolSize; + this.workQueue = workQueue; + this.keepAliveTime = unit.toNanos(keepAliveTime); + this.threadFactory = threadFactory; + this.handler = handler; + } +``` + +简单演示一下如何使用线程池，更详细的介绍，请看：[《新手也能看懂的线程池学习总结》](https://mp.weixin.qq.com/s?__biz=Mzg2OTA0Njk0OA==&mid=2247485808&idx=1&sn=1013253533d73450cef673aee13267ab&chksm=cea246bbf9d5cfad1c21316340a0ef1609a7457fea4113a1f8d69e8c91e7d9cd6285f5ee1490&token=510053261&lang=zh_CN&scene=21#wechat_redirect) 。 + +```java + private static final int CORE_POOL_SIZE = 5; + private static final int MAX_POOL_SIZE = 10; + private static final int QUEUE_CAPACITY = 100; + private static final Long KEEP_ALIVE_TIME = 1L; + + public static void main(String[] args) { + + //使用阿里巴巴推荐的创建线程池的方式 + //通过ThreadPoolExecutor构造函数自定义参数创建 + ThreadPoolExecutor executor = new ThreadPoolExecutor( + CORE_POOL_SIZE, + MAX_POOL_SIZE, + KEEP_ALIVE_TIME, + TimeUnit.SECONDS, + new ArrayBlockingQueue<>(QUEUE_CAPACITY), + new ThreadPoolExecutor.CallerRunsPolicy()); + + for (int i = 0; i < 10; i++) { + executor.execute(() -> { + try { + Thread.sleep(2000); + } catch (InterruptedException e) { + e.printStackTrace(); + } + System.out.println("CurrentThread name:" + Thread.currentThread().getName() + "date：" + Instant.now()); + }); + } + //终止线程池 + executor.shutdown(); + try { + executor.awaitTermination(5, TimeUnit.SECONDS); + } catch (InterruptedException e) { + e.printStackTrace(); + } + System.out.println("Finished all threads"); + } +``` + +控制台输出： + +```java +CurrentThread name:pool-1-thread-5date：2020-06-06T11:45:31.639Z +CurrentThread name:pool-1-thread-3date：2020-06-06T11:45:31.639Z +CurrentThread name:pool-1-thread-1date：2020-06-06T11:45:31.636Z +CurrentThread name:pool-1-thread-4date：2020-06-06T11:45:31.639Z +CurrentThread name:pool-1-thread-2date：2020-06-06T11:45:31.639Z +CurrentThread name:pool-1-thread-2date：2020-06-06T11:45:33.656Z +CurrentThread name:pool-1-thread-4date：2020-06-06T11:45:33.656Z +CurrentThread name:pool-1-thread-1date：2020-06-06T11:45:33.656Z +CurrentThread name:pool-1-thread-3date：2020-06-06T11:45:33.656Z +CurrentThread name:pool-1-thread-5date：2020-06-06T11:45:33.656Z +Finished all threads +``` + +## 线程池最佳实践 + +简单总结一下我了解的使用线程池的时候应该注意的东西，网上似乎还没有专门写这方面的文章。 + +因为Guide还比较菜，有补充和完善的地方，可以在评论区告知或者在微信上与我交流。 + +### 1. 使用 `ThreadPoolExecutor ` 的构造函数声明线程池 + +**1. 线程池必须手动通过 `ThreadPoolExecutor ` 的构造函数来声明，避免使用`Executors ` 类的 `newFixedThreadPool` 和 `newCachedThreadPool` ，因为可能会有 OOM 的风险。** + +> Executors 返回线程池对象的弊端如下： +> +> - **`FixedThreadPool` 和 `SingleThreadExecutor`** ： 允许请求的队列长度为 `Integer.MAX_VALUE`,可能堆积大量的请求，从而导致 OOM。 +> - **CachedThreadPool 和 ScheduledThreadPool** ： 允许创建的线程数量为 `Integer.MAX_VALUE` ，可能会创建大量线程，从而导致 OOM。 + +说白了就是：**使用有界队列，控制线程创建数量。** + +除了避免 OOM 的原因之外，不推荐使用 `Executors `提供的两种快捷的线程池的原因还有： + +1. 实际使用中需要根据自己机器的性能、业务场景来手动配置线程池的参数比如核心线程数、使用的任务队列、饱和策略等等。 +2. 我们应该显示地给我们的线程池命名，这样有助于我们定位问题。 + +### 2.监测线程池运行状态 + +你可以通过一些手段来检测线程池的运行状态比如 SpringBoot 中的 Actuator 组件。 + +除此之外，我们还可以利用 `ThreadPoolExecutor` 的相关 API做一个简陋的监控。从下图可以看出， `ThreadPoolExecutor`提供了获取线程池当前的线程数和活跃线程数、已经执行完成的任务数、正在排队中的任务数等等。 + +![](./images/thread-pool/ddf22709-bff5-45b4-acb7-a3f2e6798608.png) + +下面是一个简单的 Demo。`printThreadPoolStatus()`会每隔一秒打印出线程池的线程数、活跃线程数、完成的任务数、以及队列中的任务数。 + +```java + /** + * 打印线程池的状态 + * + * @param threadPool 线程池对象 + */ + public static void printThreadPoolStatus(ThreadPoolExecutor threadPool) { + ScheduledExecutorService scheduledExecutorService = new ScheduledThreadPoolExecutor(1, createThreadFactory("print-images/thread-pool-status", false)); + scheduledExecutorService.scheduleAtFixedRate(() -> { + log.info("========================="); + log.info("ThreadPool Size: [{}]", threadPool.getPoolSize()); + log.info("Active Threads: {}", threadPool.getActiveCount()); + log.info("Number of Tasks : {}", threadPool.getCompletedTaskCount()); + log.info("Number of Tasks in Queue: {}", threadPool.getQueue().size()); + log.info("========================="); + }, 0, 1, TimeUnit.SECONDS); + } +``` + +### 3.建议不同类别的业务用不同的线程池 + +很多人在实际项目中都会有类似这样的问题：**我的项目中多个业务需要用到线程池，是为每个线程池都定义一个还是说定义一个公共的线程池呢？** + +一般建议是不同的业务使用不同的线程池，配置线程池的时候根据当前业务的情况对当前线程池进行配置，因为不同的业务的并发以及对资源的使用情况都不同，重心优化系统性能瓶颈相关的业务。 + +**我们再来看一个真实的事故案例！** (本案例来源自：[《线程池运用不当的一次线上事故》](https://club.perfma.com/article/646639) ，很精彩的一个案例) + +![案例代码概览](./images/thread-pool/5b9b814d-722a-4116-b066-43dc80fc1dc4.png) + +上面的代码可能会存在死锁的情况，为什么呢？画个图给大家捋一捋。 + +试想这样一种极端情况：假如我们线程池的核心线程数为 **n**，父任务（扣费任务）数量为 **n**，父任务下面有两个子任务（扣费任务下的子任务），其中一个已经执行完成，另外一个被放在了任务队列中。由于父任务把线程池核心线程资源用完，所以子任务因为无法获取到线程资源无法正常执行，一直被阻塞在队列中。父任务等待子任务执行完成，而子任务等待父任务释放线程池资源，这也就造成了 **"死锁"**。 + +![线程池使用不当导致死锁](./images/thread-pool/线程池使用不当导致死锁.png) + +解决方法也很简单，就是新增加一个用于执行子任务的线程池专门为其服务。 + +### 4.别忘记给线程池命名 + +初始化线程池的时候需要显示命名（设置线程池名称前缀），有利于定位问题。 + +默认情况下创建的线程名字类似 pool-1-thread-n 这样的，没有业务含义，不利于我们定位问题。 + +给线程池里的线程命名通常有下面两种方式： + +**1.利用 guava 的 `ThreadFactoryBuilder` ** + +```java +ThreadFactory threadFactory = new ThreadFactoryBuilder() + .setNameFormat(threadNamePrefix + "-%d") + .setDaemon(true).build(); +ExecutorService threadPool = new ThreadPoolExecutor(corePoolSize, maximumPoolSize, keepAliveTime, TimeUnit.MINUTES, workQueue, threadFactory) +``` + +**2.自己实现 `ThreadFactor`。** + +```java +import java.util.concurrent.Executors; +import java.util.concurrent.ThreadFactory; +import java.util.concurrent.atomic.AtomicInteger; +/** + * 线程工厂，它设置线程名称，有利于我们定位问题。 + */ +public final class NamingThreadFactory implements ThreadFactory { + + private final AtomicInteger threadNum = new AtomicInteger(); + private final ThreadFactory delegate; + private final String name; + + /** + * 创建一个带名字的线程池生产工厂 + */ + public NamingThreadFactory(ThreadFactory delegate, String name) { + this.delegate = delegate; + this.name = name; // TODO consider uniquifying this + } + + @Override + public Thread newThread(Runnable r) { + Thread t = delegate.newThread(r); + t.setName(name + " [#" + threadNum.incrementAndGet() + "]"); + return t; + } + +} +``` + +### 5.正确配置线程池参数 + +说到如何给线程池配置参数，美团的骚操作至今让我难忘（后面会提到）！ + +我们先来看一下各种书籍和博客上一般推荐的配置线程池参数的方式，可以作为参考！ + +#### 常规操作 + +很多人甚至可能都会觉得把线程池配置过大一点比较好！我觉得这明显是有问题的。就拿我们生活中非常常见的一例子来说：**并不是人多就能把事情做好，增加了沟通交流成本。你本来一件事情只需要 3 个人做，你硬是拉来了 6 个人，会提升做事效率嘛？我想并不会。** 线程数量过多的影响也是和我们分配多少人做事情一样，对于多线程这个场景来说主要是增加了**上下文切换**成本。不清楚什么是上下文切换的话，可以看我下面的介绍。 + +> 上下文切换： +> +> 多线程编程中一般线程的个数都大于 CPU 核心的个数，而一个 CPU 核心在任意时刻只能被一个线程使用，为了让这些线程都能得到有效执行，CPU 采取的策略是为每个线程分配时间片并轮转的形式。当一个线程的时间片用完的时候就会重新处于就绪状态让给其他线程使用，这个过程就属于一次上下文切换。概括来说就是：当前任务在执行完 CPU 时间片切换到另一个任务之前会先保存自己的状态，以便下次再切换回这个任务时，可以再加载这个任务的状态。**任务从保存到再加载的过程就是一次上下文切换**。 +> +> 上下文切换通常是计算密集型的。也就是说，它需要相当可观的处理器时间，在每秒几十上百次的切换中，每次切换都需要纳秒量级的时间。所以，上下文切换对系统来说意味着消耗大量的 CPU 时间，事实上，可能是操作系统中时间消耗最大的操作。 +> +> Linux 相比与其他操作系统（包括其他类 Unix 系统）有很多的优点，其中有一项就是，其上下文切换和模式切换的时间消耗非常少。 + +**类比于实现世界中的人类通过合作做某件事情，我们可以肯定的一点是线程池大小设置过大或者过小都会有问题，合适的才是最好。** + +**如果我们设置的线程池数量太小的话，如果同一时间有大量任务/请求需要处理，可能会导致大量的请求/任务在任务队列中排队等待执行，甚至会出现任务队列满了之后任务/请求无法处理的情况，或者大量任务堆积在任务队列导致 OOM。这样很明显是有问题的！ CPU 根本没有得到充分利用。** + +**但是，如果我们设置线程数量太大，大量线程可能会同时在争取 CPU 资源，这样会导致大量的上下文切换，从而增加线程的执行时间，影响了整体执行效率。** + +有一个简单并且适用面比较广的公式： + +- **CPU 密集型任务(N+1)：** 这种任务消耗的主要是 CPU 资源，可以将线程数设置为 N（CPU 核心数）+1，比 CPU 核心数多出来的一个线程是为了防止线程偶发的缺页中断，或者其它原因导致的任务暂停而带来的影响。一旦任务暂停，CPU 就会处于空闲状态，而在这种情况下多出来的一个线程就可以充分利用 CPU 的空闲时间。 +- **I/O 密集型任务(2N)：** 这种任务应用起来，系统会用大部分的时间来处理 I/O 交互，而线程在处理 I/O 的时间段内不会占用 CPU 来处理，这时就可以将 CPU 交出给其它线程使用。因此在 I/O 密集型任务的应用中，我们可以多配置一些线程，具体的计算方法是 2N。 + +**如何判断是 CPU 密集任务还是 IO 密集任务？** + +CPU 密集型简单理解就是利用 CPU 计算能力的任务比如你在内存中对大量数据进行排序。但凡涉及到网络读取，文件读取这类都是 IO 密集型，这类任务的特点是 CPU 计算耗费时间相比于等待 IO 操作完成的时间来说很少，大部分时间都花在了等待 IO 操作完成上。 + +#### 美团的骚操作 + +美团技术团队在[《Java线程池实现原理及其在美团业务中的实践》](https://tech.meituan.com/2020/04/02/java-pooling-pratice-in-meituan.html)这篇文章中介绍到对线程池参数实现可自定义配置的思路和方法。 + +美团技术团队的思路是主要对线程池的核心参数实现自定义可配置。这三个核心参数是： + +- **`corePoolSize` :** 核心线程数线程数定义了最小可以同时运行的线程数量。 +- **`maximumPoolSize` :** 当队列中存放的任务达到队列容量的时候，当前可以同时运行的线程数量变为最大线程数。 +- **`workQueue`:** 当新任务来的时候会先判断当前运行的线程数量是否达到核心线程数，如果达到的话，新任务就会被存放在队列中。 + +**为什么是这三个参数？** + +我在这篇[《新手也能看懂的线程池学习总结》](https://mp.weixin.qq.com/s?__biz=Mzg2OTA0Njk0OA==&mid=2247485808&idx=1&sn=1013253533d73450cef673aee13267ab&chksm=cea246bbf9d5cfad1c21316340a0ef1609a7457fea4113a1f8d69e8c91e7d9cd6285f5ee1490&token=510053261&lang=zh_CN&scene=21#wechat_redirect) 中就说过这三个参数是 `ThreadPoolExecutor` 最重要的参数，它们基本决定了线程池对于任务的处理策略。 + +**如何支持参数动态配置？** 且看 `ThreadPoolExecutor` 提供的下面这些方法。 + +![](./images/thread-pool/b6fd95a7-4c9d-4fc6-ad26-890adb3f6c4c.png) + +格外需要注意的是`corePoolSize`， 程序运行期间的时候，我们调用 `setCorePoolSize（） `这个方法的话，线程池会首先判断当前工作线程数是否大于`corePoolSize`，如果大于的话就会回收工作线程。 + +另外，你也看到了上面并没有动态指定队列长度的方法，美团的方式是自定义了一个叫做 `ResizableCapacityLinkedBlockIngQueue` 的队列（主要就是把`LinkedBlockingQueue`的capacity 字段的final关键字修饰给去掉了，让它变为可变的）。 + +最终实现的可动态修改线程池参数效果如下。👏👏👏 + +![动态配置线程池参数最终效果](./images/thread-pool/19a0255a-6ef3-4835-98d1-a839d1983332.png) + +还没看够？推荐 why神的[《如何设置线程池参数？美团给出了一个让面试官虎躯一震的回答。》](https://mp.weixin.qq.com/s/9HLuPcoWmTqAeFKa1kj-_A)这篇文章，深度剖析，很不错哦！ + + + diff --git a/docs/java/concurrent/java-thread-pool-summary.md b/docs/java/concurrent/java-thread-pool-summary.md new file mode 100644 index 0000000000000000000000000000000000000000..7ec85fe6aafd24e8d7a17fbd0d064d99e45788bf --- /dev/null +++ b/docs/java/concurrent/java-thread-pool-summary.md @@ -0,0 +1,882 @@ +--- +title: Java 线程池详解 +category: Java +tag: + - Java并发 +--- + + + +## 一 使用线程池的好处 + +> **池化技术想必大家已经屡见不鲜了，线程池、数据库连接池、Http 连接池等等都是对这个思想的应用。池化技术的思想主要是为了减少每次获取资源的消耗，提高对资源的利用率。** + +**线程池**提供了一种限制和管理资源（包括执行一个任务）的方式。 每个**线程池**还维护一些基本统计信息，例如已完成任务的数量。 + +这里借用《Java 并发编程的艺术》提到的来说一下**使用线程池的好处**： + +- **降低资源消耗**。通过重复利用已创建的线程降低线程创建和销毁造成的消耗。 +- **提高响应速度**。当任务到达时，任务可以不需要等到线程创建就能立即执行。 +- **提高线程的可管理性**。线程是稀缺资源，如果无限制的创建，不仅会消耗系统资源，还会降低系统的稳定性，使用线程池可以进行统一的分配，调优和监控。 + +## 二 Executor 框架 + +### 2.1 简介 + +`Executor` 框架是 Java5 之后引进的，在 Java 5 之后，通过 `Executor` 来启动线程比使用 `Thread` 的 `start` 方法更好，除了更易管理，效率更好（用线程池实现，节约开销）外，还有关键的一点：有助于避免 this 逃逸问题。 + +> 补充：this 逃逸是指在构造函数返回之前其他线程就持有该对象的引用. 调用尚未构造完全的对象的方法可能引发令人疑惑的错误。 + +`Executor` 框架不仅包括了线程池的管理，还提供了线程工厂、队列以及拒绝策略等，`Executor` 框架让并发编程变得更加简单。 + +### 2.2 Executor 框架结构(主要由三大部分组成) + +#### 1) 任务(`Runnable` /`Callable`) + +执行任务需要实现的 **`Runnable` 接口** 或 **`Callable`接口**。**`Runnable` 接口**或 **`Callable` 接口** 实现类都可以被 **`ThreadPoolExecutor`** 或 **`ScheduledThreadPoolExecutor`** 执行。 + +#### 2) 任务的执行(`Executor`) + +如下图所示，包括任务执行机制的核心接口 **`Executor`** ，以及继承自 `Executor` 接口的 **`ExecutorService` 接口。`ThreadPoolExecutor`** 和 **`ScheduledThreadPoolExecutor`** 这两个关键类实现了 **ExecutorService 接口**。 + +**这里提了很多底层的类关系，但是，实际上我们需要更多关注的是 `ThreadPoolExecutor` 这个类，这个类在我们实际使用线程池的过程中，使用频率还是非常高的。** + +> **注意：** 通过查看 `ScheduledThreadPoolExecutor` 源代码我们发现 `ScheduledThreadPoolExecutor` 实际上是继承了 `ThreadPoolExecutor` 并实现了 ScheduledExecutorService ，而 `ScheduledExecutorService` 又实现了 `ExecutorService`，正如我们下面给出的类关系图显示的一样。 + +**`ThreadPoolExecutor` 类描述:** + +```java +//AbstractExecutorService实现了ExecutorService接口 +public class ThreadPoolExecutor extends AbstractExecutorService +``` + +**`ScheduledThreadPoolExecutor` 类描述:** + +```java +//ScheduledExecutorService继承ExecutorService接口 +public class ScheduledThreadPoolExecutor + extends ThreadPoolExecutor + implements ScheduledExecutorService +``` + +![任务的执行相关接口](./images/java-thread-pool-summary/任务的执行相关接口.png) + +#### 3) 异步计算的结果(`Future`) + +**`Future`** 接口以及 `Future` 接口的实现类 **`FutureTask`** 类都可以代表异步计算的结果。 + +当我们把 **`Runnable`接口** 或 **`Callable` 接口** 的实现类提交给 **`ThreadPoolExecutor`** 或 **`ScheduledThreadPoolExecutor`** 执行。（调用 `submit()` 方法时会返回一个 **`FutureTask`** 对象） + +### 2.3 Executor 框架的使用示意图 + +![Executor 框架的使用示意图](./images/java-thread-pool-summary/Executor框架的使用示意图.png) + +1. **主线程首先要创建实现 `Runnable` 或者 `Callable` 接口的任务对象。** +2. **把创建完成的实现 `Runnable`/`Callable`接口的 对象直接交给 `ExecutorService` 执行**: `ExecutorService.execute（Runnable command）`）或者也可以把 `Runnable` 对象或`Callable` 对象提交给 `ExecutorService` 执行（`ExecutorService.submit（Runnable task）`或 `ExecutorService.submit（Callable task）`）。 +3. **如果执行 `ExecutorService.submit（…）`，`ExecutorService` 将返回一个实现`Future`接口的对象**（我们刚刚也提到过了执行 `execute()`方法和 `submit()`方法的区别，`submit()`会返回一个 `FutureTask 对象）。由于 FutureTask` 实现了 `Runnable`，我们也可以创建 `FutureTask`，然后直接交给 `ExecutorService` 执行。 +4. **最后，主线程可以执行 `FutureTask.get()`方法来等待任务执行完成。主线程也可以执行 `FutureTask.cancel（boolean mayInterruptIfRunning）`来取消此任务的执行。** + +## 三 (重要)ThreadPoolExecutor 类简单介绍 + +**线程池实现类 `ThreadPoolExecutor` 是 `Executor` 框架最核心的类。** + +### 3.1 ThreadPoolExecutor 类分析 + +`ThreadPoolExecutor` 类中提供的四个构造方法。我们来看最长的那个，其余三个都是在这个构造方法的基础上产生（其他几个构造方法说白点都是给定某些默认参数的构造方法比如默认制定拒绝策略是什么）。 + +```java + /** + * 用给定的初始参数创建一个新的ThreadPoolExecutor。 + */ + public ThreadPoolExecutor(int corePoolSize,//线程池的核心线程数量 + int maximumPoolSize,//线程池的最大线程数 + long keepAliveTime,//当线程数大于核心线程数时，多余的空闲线程存活的最长时间 + TimeUnit unit,//时间单位 + BlockingQueue workQueue,//任务队列，用来储存等待执行任务的队列 + ThreadFactory threadFactory,//线程工厂，用来创建线程，一般默认即可 + RejectedExecutionHandler handler//拒绝策略，当提交的任务过多而不能及时处理时，我们可以定制策略来处理任务 + ) { + if (corePoolSize < 0 || + maximumPoolSize <= 0 || + maximumPoolSize < corePoolSize || + keepAliveTime < 0) + throw new IllegalArgumentException(); + if (workQueue == null || threadFactory == null || handler == null) + throw new NullPointerException(); + this.corePoolSize = corePoolSize; + this.maximumPoolSize = maximumPoolSize; + this.workQueue = workQueue; + this.keepAliveTime = unit.toNanos(keepAliveTime); + this.threadFactory = threadFactory; + this.handler = handler; + } +``` + +下面这些对创建非常重要，在后面使用线程池的过程中你一定会用到！所以，务必拿着小本本记清楚。 + +**`ThreadPoolExecutor` 3 个最重要的参数：** + +- **`corePoolSize` :** 核心线程数线程数定义了最小可以同时运行的线程数量。 +- **`maximumPoolSize` :** 当队列中存放的任务达到队列容量的时候，当前可以同时运行的线程数量变为最大线程数。 +- **`workQueue`:** 当新任务来的时候会先判断当前运行的线程数量是否达到核心线程数，如果达到的话，新任务就会被存放在队列中。 + +`ThreadPoolExecutor`其他常见参数 : + +1. **`keepAliveTime`**:当线程池中的线程数量大于 `corePoolSize` 的时候，如果这时没有新的任务提交，核心线程外的线程不会立即销毁，而是会等待，直到等待的时间超过了 `keepAliveTime`才会被回收销毁； +2. **`unit`** : `keepAliveTime` 参数的时间单位。 +3. **`threadFactory`** :executor 创建新线程的时候会用到。 +4. **`handler`** :饱和策略。关于饱和策略下面单独介绍一下。 + +下面这张图可以加深你对线程池中各个参数的相互关系的理解（图片来源：《Java 性能调优实战》）： + +![线程池各个参数的关系](./images/java-thread-pool-summary/线程池各个参数之间的关系.png) + +**`ThreadPoolExecutor` 饱和策略定义:** + +如果当前同时运行的线程数量达到最大线程数量并且队列也已经被放满了任务时，`ThreadPoolTaskExecutor` 定义一些策略: + +- **`ThreadPoolExecutor.AbortPolicy`** ：抛出 `RejectedExecutionException`来拒绝新任务的处理。 +- **`ThreadPoolExecutor.CallerRunsPolicy`** ：调用执行自己的线程运行任务，也就是直接在调用`execute`方法的线程中运行(`run`)被拒绝的任务，如果执行程序已关闭，则会丢弃该任务。因此这种策略会降低对于新任务提交速度，影响程序的整体性能。如果您的应用程序可以承受此延迟并且你要求任何一个任务请求都要被执行的话，你可以选择这个策略。 +- **`ThreadPoolExecutor.DiscardPolicy`** ：不处理新任务，直接丢弃掉。 +- **`ThreadPoolExecutor.DiscardOldestPolicy`** ： 此策略将丢弃最早的未处理的任务请求。 + +举个例子： + +> Spring 通过 `ThreadPoolTaskExecutor` 或者我们直接通过 `ThreadPoolExecutor` 的构造函数创建线程池的时候，当我们不指定 `RejectedExecutionHandler` 饱和策略的话来配置线程池的时候默认使用的是 `ThreadPoolExecutor.AbortPolicy`。在默认情况下，`ThreadPoolExecutor` 将抛出 `RejectedExecutionException` 来拒绝新来的任务 ，这代表你将丢失对这个任务的处理。 对于可伸缩的应用程序，建议使用 `ThreadPoolExecutor.CallerRunsPolicy`。当最大池被填满时，此策略为我们提供可伸缩队列。（这个直接查看 `ThreadPoolExecutor` 的构造函数源码就可以看出，比较简单的原因，这里就不贴代码了。） + +### 3.2 推荐使用 `ThreadPoolExecutor` 构造函数创建线程池 + +在《阿里巴巴 Java 开发手册》“并发处理”这一章节，明确指出线程资源必须通过线程池提供，不允许在应用中自行显式创建线程。 + +**为什么呢？** + +> 使用线程池的好处是减少在创建和销毁线程上所消耗的时间以及系统资源开销，解决资源不足的问题。如果不使用线程池，有可能会造成系统创建大量同类线程而导致消耗完内存或者“过度切换”的问题。 + +另外，《阿里巴巴 Java 开发手册》中强制线程池不允许使用 `Executors` 去创建，而是通过 `ThreadPoolExecutor` 构造函数的方式，这样的处理方式让写的同学更加明确线程池的运行规则，规避资源耗尽的风险 + +> `Executors` 返回线程池对象的弊端如下(后文会详细介绍到)： +> +> - **`FixedThreadPool` 和 `SingleThreadExecutor`** ： 允许请求的队列长度为 `Integer.MAX_VALUE`,可能堆积大量的请求，从而导致 OOM。 +> - **`CachedThreadPool` 和 `ScheduledThreadPool`** ： 允许创建的线程数量为 `Integer.MAX_VALUE` ，可能会创建大量线程，从而导致 OOM。 + +**方式一：通过`ThreadPoolExecutor`构造函数实现（推荐）** +![通过构造方法实现](./images/java-thread-pool-summary/threadpoolexecutor构造函数.png) + +**方式二：通过 `Executor` 框架的工具类 `Executors` 来实现** +我们可以创建三种类型的 `ThreadPoolExecutor`： + +- `FixedThreadPool` +- `SingleThreadExecutor` +- CachedThreadPool + +对应 Executors 工具类中的方法如图所示： + +![通过Executor 框架的工具类Executors来实现](./images/java-thread-pool-summary/Executors工具类.png) + +## 四 ThreadPoolExecutor 使用+原理分析 + +我们上面讲解了 `Executor`框架以及 `ThreadPoolExecutor` 类，下面让我们实战一下，来通过写一个 `ThreadPoolExecutor` 的小 Demo 来回顾上面的内容。 + +### 4.1 示例代码:`Runnable`+`ThreadPoolExecutor` + +首先创建一个 `Runnable` 接口的实现类（当然也可以是 `Callable` 接口，我们上面也说了两者的区别。） + +`MyRunnable.java` + +```java +import java.util.Date; + +/** + * 这是一个简单的Runnable类，需要大约5秒钟来执行其任务。 + * @author shuang.kou + */ +public class MyRunnable implements Runnable { + + private String command; + + public MyRunnable(String s) { + this.command = s; + } + + @Override + public void run() { + System.out.println(Thread.currentThread().getName() + " Start. Time = " + new Date()); + processCommand(); + System.out.println(Thread.currentThread().getName() + " End. Time = " + new Date()); + } + + private void processCommand() { + try { + Thread.sleep(5000); + } catch (InterruptedException e) { + e.printStackTrace(); + } + } + + @Override + public String toString() { + return this.command; + } +} + +``` + +编写测试程序，我们这里以阿里巴巴推荐的使用 `ThreadPoolExecutor` 构造函数自定义参数的方式来创建线程池。 + +`ThreadPoolExecutorDemo.java` + +```java +import java.util.concurrent.ArrayBlockingQueue; +import java.util.concurrent.ThreadPoolExecutor; +import java.util.concurrent.TimeUnit; + +public class ThreadPoolExecutorDemo { + + private static final int CORE_POOL_SIZE = 5; + private static final int MAX_POOL_SIZE = 10; + private static final int QUEUE_CAPACITY = 100; + private static final Long KEEP_ALIVE_TIME = 1L; + public static void main(String[] args) { + + //使用阿里巴巴推荐的创建线程池的方式 + //通过ThreadPoolExecutor构造函数自定义参数创建 + ThreadPoolExecutor executor = new ThreadPoolExecutor( + CORE_POOL_SIZE, + MAX_POOL_SIZE, + KEEP_ALIVE_TIME, + TimeUnit.SECONDS, + new ArrayBlockingQueue<>(QUEUE_CAPACITY), + new ThreadPoolExecutor.CallerRunsPolicy()); + + for (int i = 0; i < 10; i++) { + //创建WorkerThread对象（WorkerThread类实现了Runnable 接口） + Runnable worker = new MyRunnable("" + i); + //执行Runnable + executor.execute(worker); + } + //终止线程池 + executor.shutdown(); + while (!executor.isTerminated()) { + } + System.out.println("Finished all threads"); + } +} + +``` + +可以看到我们上面的代码指定了： + +1. `corePoolSize`: 核心线程数为 5。 +2. `maximumPoolSize` ：最大线程数 10 +3. `keepAliveTime` : 等待时间为 1L。 +4. `unit`: 等待时间的单位为 TimeUnit.SECONDS。 +5. `workQueue`：任务队列为 `ArrayBlockingQueue`，并且容量为 100; +6. `handler`:饱和策略为 `CallerRunsPolicy`。 + +**Output：** + +``` +pool-1-thread-3 Start. Time = Sun Apr 12 11:14:37 CST 2020 +pool-1-thread-5 Start. Time = Sun Apr 12 11:14:37 CST 2020 +pool-1-thread-2 Start. Time = Sun Apr 12 11:14:37 CST 2020 +pool-1-thread-1 Start. Time = Sun Apr 12 11:14:37 CST 2020 +pool-1-thread-4 Start. Time = Sun Apr 12 11:14:37 CST 2020 +pool-1-thread-3 End. Time = Sun Apr 12 11:14:42 CST 2020 +pool-1-thread-4 End. Time = Sun Apr 12 11:14:42 CST 2020 +pool-1-thread-1 End. Time = Sun Apr 12 11:14:42 CST 2020 +pool-1-thread-5 End. Time = Sun Apr 12 11:14:42 CST 2020 +pool-1-thread-1 Start. Time = Sun Apr 12 11:14:42 CST 2020 +pool-1-thread-2 End. Time = Sun Apr 12 11:14:42 CST 2020 +pool-1-thread-5 Start. Time = Sun Apr 12 11:14:42 CST 2020 +pool-1-thread-4 Start. Time = Sun Apr 12 11:14:42 CST 2020 +pool-1-thread-3 Start. Time = Sun Apr 12 11:14:42 CST 2020 +pool-1-thread-2 Start. Time = Sun Apr 12 11:14:42 CST 2020 +pool-1-thread-1 End. Time = Sun Apr 12 11:14:47 CST 2020 +pool-1-thread-4 End. Time = Sun Apr 12 11:14:47 CST 2020 +pool-1-thread-5 End. Time = Sun Apr 12 11:14:47 CST 2020 +pool-1-thread-3 End. Time = Sun Apr 12 11:14:47 CST 2020 +pool-1-thread-2 End. Time = Sun Apr 12 11:14:47 CST 2020 + +``` + +### 4.2 线程池原理分析 + +承接 4.1 节，我们通过代码输出结果可以看出：**线程池首先会先执行 5 个任务，然后这些任务有任务被执行完的话，就会去拿新的任务执行。** 大家可以先通过上面讲解的内容，分析一下到底是咋回事？（自己独立思考一会） + +现在，我们就分析上面的输出内容来简单分析一下线程池原理。 + +**为了搞懂线程池的原理，我们需要首先分析一下 `execute`方法。** 在 4.1 节中的 Demo 中我们使用 `executor.execute(worker)`来提交一个任务到线程池中去，这个方法非常重要，下面我们来看看它的源码： + +```java + // 存放线程池的运行状态 (runState) 和线程池内有效线程的数量 (workerCount) + private final AtomicInteger ctl = new AtomicInteger(ctlOf(RUNNING, 0)); + + private static int workerCountOf(int c) { + return c & CAPACITY; + } + //任务队列 + private final BlockingQueue workQueue; + + public void execute(Runnable command) { + // 如果任务为null，则抛出异常。 + if (command == null) + throw new NullPointerException(); + // ctl 中保存的线程池当前的一些状态信息 + int c = ctl.get(); + + // 下面会涉及到 3 步 操作 + // 1.首先判断当前线程池中之行的任务数量是否小于 corePoolSize + // 如果小于的话，通过addWorker(command, true)新建一个线程，并将任务(command)添加到该线程中；然后，启动该线程从而执行任务。 + if (workerCountOf(c) < corePoolSize) { + if (addWorker(command, true)) + return; + c = ctl.get(); + } + // 2.如果当前之行的任务数量大于等于 corePoolSize 的时候就会走到这里 + // 通过 isRunning 方法判断线程池状态，线程池处于 RUNNING 状态才会被并且队列可以加入任务，该任务才会被加入进去 + if (isRunning(c) && workQueue.offer(command)) { + int recheck = ctl.get(); + // 再次获取线程池状态，如果线程池状态不是 RUNNING 状态就需要从任务队列中移除任务，并尝试判断线程是否全部执行完毕。同时执行拒绝策略。 + if (!isRunning(recheck) && remove(command)) + reject(command); + // 如果当前线程池为空就新创建一个线程并执行。 + else if (workerCountOf(recheck) == 0) + addWorker(null, false); + } + //3. 通过addWorker(command, false)新建一个线程，并将任务(command)添加到该线程中；然后，启动该线程从而执行任务。 + //如果addWorker(command, false)执行失败，则通过reject()执行相应的拒绝策略的内容。 + else if (!addWorker(command, false)) + reject(command); + } +``` + +通过下图可以更好的对上面这 3 步做一个展示，下图是我为了省事直接从网上找到，原地址不明。 + +![图解线程池实现原理](https://guide-blog-images.oss-cn-shenzhen.aliyuncs.com/javaguide/%E5%9B%BE%E8%A7%A3%E7%BA%BF%E7%A8%8B%E6%B1%A0%E5%AE%9E%E7%8E%B0%E5%8E%9F%E7%90%86.png) + +**`addWorker` 这个方法主要用来创建新的工作线程，如果返回 true 说明创建和启动工作线程成功，否则的话返回的就是 false。** + +```java + // 全局锁，并发操作必备 + private final ReentrantLock mainLock = new ReentrantLock(); + // 跟踪线程池的最大大小，只有在持有全局锁mainLock的前提下才能访问此集合 + private int largestPoolSize; + // 工作线程集合，存放线程池中所有的（活跃的）工作线程，只有在持有全局锁mainLock的前提下才能访问此集合 + private final HashSet workers = new HashSet<>(); + //获取线程池状态 + private static int runStateOf(int c) { return c & ~CAPACITY; } + //判断线程池的状态是否为 Running + private static boolean isRunning(int c) { + return c < SHUTDOWN; + } + + + /** + * 添加新的工作线程到线程池 + * @param firstTask 要执行 + * @param core参数为true的话表示使用线程池的基本大小，为false使用线程池最大大小 + * @return 添加成功就返回true否则返回false + */ + private boolean addWorker(Runnable firstTask, boolean core) { + retry: + for (;;) { + //这两句用来获取线程池的状态 + int c = ctl.get(); + int rs = runStateOf(c); + + // Check if queue empty only if necessary. + if (rs >= SHUTDOWN && + ! (rs == SHUTDOWN && + firstTask == null && + ! workQueue.isEmpty())) + return false; + + for (;;) { + //获取线程池中工作的线程的数量 + int wc = workerCountOf(c); + // core参数为true的话表明队列也满了，线程池大小变为 maximumPoolSize + if (wc >= CAPACITY || + wc >= (core ? corePoolSize : maximumPoolSize)) + return false; + //原子操作将workcount的数量加1 + if (compareAndIncrementWorkerCount(c)) + break retry; + // 如果线程的状态改变了就再次执行上述操作 + c = ctl.get(); + if (runStateOf(c) != rs) + continue retry; + // else CAS failed due to workerCount change; retry inner loop + } + } + // 标记工作线程是否启动成功 + boolean workerStarted = false; + // 标记工作线程是否创建成功 + boolean workerAdded = false; + Worker w = null; + try { + + w = new Worker(firstTask); + final Thread t = w.thread; + if (t != null) { + // 加锁 + final ReentrantLock mainLock = this.mainLock; + mainLock.lock(); + try { + //获取线程池状态 + int rs = runStateOf(ctl.get()); + //rs < SHUTDOWN 如果线程池状态依然为RUNNING,并且线程的状态是存活的话，就会将工作线程添加到工作线程集合中 + //(rs=SHUTDOWN && firstTask == null)如果线程池状态小于STOP，也就是RUNNING或者SHUTDOWN状态下，同时传入的任务实例firstTask为null，则需要添加到工作线程集合和启动新的Worker + // firstTask == null证明只新建线程而不执行任务 + if (rs < SHUTDOWN || + (rs == SHUTDOWN && firstTask == null)) { + if (t.isAlive()) // precheck that t is startable + throw new IllegalThreadStateException(); + workers.add(w); + //更新当前工作线程的最大容量 + int s = workers.size(); + if (s > largestPoolSize) + largestPoolSize = s; + // 工作线程是否启动成功 + workerAdded = true; + } + } finally { + // 释放锁 + mainLock.unlock(); + } + //// 如果成功添加工作线程，则调用Worker内部的线程实例t的Thread#start()方法启动真实的线程实例 + if (workerAdded) { + t.start(); + /// 标记线程启动成功 + workerStarted = true; + } + } + } finally { + // 线程启动失败，需要从工作线程中移除对应的Worker + if (! workerStarted) + addWorkerFailed(w); + } + return workerStarted; + } +``` + +更多关于线程池源码分析的内容推荐这篇文章：硬核干货：[4W字从源码上分析JUC线程池ThreadPoolExecutor的实现原理](https://www.throwx.cn/2020/08/23/java-concurrency-thread-pool-executor/) + +现在，让我们在回到 4.1 节我们写的 Demo， 现在应该是不是很容易就可以搞懂它的原理了呢？ + +没搞懂的话，也没关系，可以看看我的分析： + +> 我们在代码中模拟了 10 个任务，我们配置的核心线程数为 5 、等待队列容量为 100 ，所以每次只可能存在 5 个任务同时执行，剩下的 5 个任务会被放到等待队列中去。当前的 5 个任务中如果有任务被执行完了，线程池就会去拿新的任务执行。 + +### 4.3 几个常见的对比 + +#### 4.3.1 `Runnable` vs `Callable` + +`Runnable`自 Java 1.0 以来一直存在，但`Callable`仅在 Java 1.5 中引入,目的就是为了来处理`Runnable`不支持的用例。**`Runnable` 接口**不会返回结果或抛出检查异常，但是 **`Callable` 接口**可以。所以，如果任务不需要返回结果或抛出异常推荐使用 **`Runnable` 接口**，这样代码看起来会更加简洁。 + +工具类 `Executors` 可以实现将 `Runnable` 对象转换成 `Callable` 对象。（`Executors.callable(Runnable task)` 或 `Executors.callable(Runnable task, Object result)`）。 + +`Runnable.java` + +```java +@FunctionalInterface +public interface Runnable { + /** + * 被线程执行，没有返回值也无法抛出异常 + */ + public abstract void run(); +} +``` + +`Callable.java` + +```java +@FunctionalInterface +public interface Callable { + /** + * 计算结果，或在无法这样做时抛出异常。 + * @return 计算得出的结果 + * @throws 如果无法计算结果，则抛出异常 + */ + V call() throws Exception; +} + +``` + +#### 4.3.2 `execute()` vs `submit()` + +- `execute()`方法用于提交不需要返回值的任务，所以无法判断任务是否被线程池执行成功与否； +- `submit()`方法用于提交需要返回值的任务。线程池会返回一个 `Future` 类型的对象，通过这个 `Future` 对象可以判断任务是否执行成功，并且可以通过 `Future` 的 `get()`方法来获取返回值，`get()`方法会阻塞当前线程直到任务完成，而使用 `get（long timeout，TimeUnit unit）`方法的话，如果在 `timeout` 时间内任务还没有执行完，就会抛出 `java.util.concurrent.TimeoutException`。 + +这里只是为了演示使用，推荐使用 `ThreadPoolExecutor` 构造方法来创建线程池。 + +示例1：使用 `get() `方法获取返回值。 + +```java +ExecutorService executorService = Executors.newFixedThreadPool(3); + +Future submit = executorService.submit(() -> { + try { + Thread.sleep(5000L); + } catch (InterruptedException e) { + e.printStackTrace(); + } + return "abc"; +}); + +String s = submit.get(); +System.out.println(s); +executorService.shutdown(); +``` + +输出： + +``` +abc +``` + +示例2：使用 `get（long timeout，TimeUnit unit） `方法获取返回值。 + +```java +ExecutorService executorService = Executors.newFixedThreadPool(3); + +Future submit = executorService.submit(() -> { + try { + Thread.sleep(5000L); + } catch (InterruptedException e) { + e.printStackTrace(); + } + return "abc"; +}); + +String s = submit.get(3, TimeUnit.SECONDS); +System.out.println(s); +executorService.shutdown(); +``` + +输出： + +``` +Exception in thread "main" java.util.concurrent.TimeoutException + at java.util.concurrent.FutureTask.get(FutureTask.java:205) +``` + +#### 4.3.3 `shutdown()`VS`shutdownNow()` + +- **`shutdown（）`** :关闭线程池，线程池的状态变为 `SHUTDOWN`。线程池不再接受新任务了，但是队列里的任务得执行完毕。 +- **`shutdownNow（）`** :关闭线程池，线程的状态变为 `STOP`。线程池会终止当前正在运行的任务，并停止处理排队的任务并返回正在等待执行的 List。 + +#### 4.3.2 `isTerminated()` VS `isShutdown()` + +- **`isShutDown`** 当调用 `shutdown()` 方法后返回为 true。 +- **`isTerminated`** 当调用 `shutdown()` 方法后，并且所有提交的任务完成后返回为 true + +### 4.4 加餐:`Callable`+`ThreadPoolExecutor`示例代码 + +`MyCallable.java` + +```java + +import java.util.concurrent.Callable; + +public class MyCallable implements Callable { + @Override + public String call() throws Exception { + Thread.sleep(1000); + //返回执行当前 Callable 的线程名字 + return Thread.currentThread().getName(); + } +} +``` + +`CallableDemo.java` + +```java + +import java.util.ArrayList; +import java.util.Date; +import java.util.List; +import java.util.concurrent.ArrayBlockingQueue; +import java.util.concurrent.Callable; +import java.util.concurrent.ExecutionException; +import java.util.concurrent.Future; +import java.util.concurrent.ThreadPoolExecutor; +import java.util.concurrent.TimeUnit; + +public class CallableDemo { + + private static final int CORE_POOL_SIZE = 5; + private static final int MAX_POOL_SIZE = 10; + private static final int QUEUE_CAPACITY = 100; + private static final Long KEEP_ALIVE_TIME = 1L; + + public static void main(String[] args) { + + //使用阿里巴巴推荐的创建线程池的方式 + //通过ThreadPoolExecutor构造函数自定义参数创建 + ThreadPoolExecutor executor = new ThreadPoolExecutor( + CORE_POOL_SIZE, + MAX_POOL_SIZE, + KEEP_ALIVE_TIME, + TimeUnit.SECONDS, + new ArrayBlockingQueue<>(QUEUE_CAPACITY), + new ThreadPoolExecutor.CallerRunsPolicy()); + + List> futureList = new ArrayList<>(); + Callable callable = new MyCallable(); + for (int i = 0; i < 10; i++) { + //提交任务到线程池 + Future future = executor.submit(callable); + //将返回值 future 添加到 list，我们可以通过 future 获得 执行 Callable 得到的返回值 + futureList.add(future); + } + for (Future fut : futureList) { + try { + System.out.println(new Date() + "::" + fut.get()); + } catch (InterruptedException | ExecutionException e) { + e.printStackTrace(); + } + } + //关闭线程池 + executor.shutdown(); + } +} +``` + +Output: + +``` +Wed Nov 13 13:40:41 CST 2019::pool-1-thread-1 +Wed Nov 13 13:40:42 CST 2019::pool-1-thread-2 +Wed Nov 13 13:40:42 CST 2019::pool-1-thread-3 +Wed Nov 13 13:40:42 CST 2019::pool-1-thread-4 +Wed Nov 13 13:40:42 CST 2019::pool-1-thread-5 +Wed Nov 13 13:40:42 CST 2019::pool-1-thread-3 +Wed Nov 13 13:40:43 CST 2019::pool-1-thread-2 +Wed Nov 13 13:40:43 CST 2019::pool-1-thread-1 +Wed Nov 13 13:40:43 CST 2019::pool-1-thread-4 +Wed Nov 13 13:40:43 CST 2019::pool-1-thread-5 +``` + +## 五 几种常见的线程池详解 + +### 5.1 FixedThreadPool + +#### 5.1.1 介绍 + +`FixedThreadPool` 被称为可重用固定线程数的线程池。通过 Executors 类中的相关源代码来看一下相关实现： + +```java + /** + * 创建一个可重用固定数量线程的线程池 + */ + public static ExecutorService newFixedThreadPool(int nThreads, ThreadFactory threadFactory) { + return new ThreadPoolExecutor(nThreads, nThreads, + 0L, TimeUnit.MILLISECONDS, + new LinkedBlockingQueue(), + threadFactory); + } +``` + +另外还有一个 `FixedThreadPool` 的实现方法，和上面的类似，所以这里不多做阐述： + +```java + public static ExecutorService newFixedThreadPool(int nThreads) { + return new ThreadPoolExecutor(nThreads, nThreads, + 0L, TimeUnit.MILLISECONDS, + new LinkedBlockingQueue()); + } +``` + +**从上面源代码可以看出新创建的 `FixedThreadPool` 的 `corePoolSize` 和 `maximumPoolSize` 都被设置为 nThreads，这个 nThreads 参数是我们使用的时候自己传递的。** + +#### 5.1.2 执行任务过程介绍 + +`FixedThreadPool` 的 `execute()` 方法运行示意图（该图片来源：《Java 并发编程的艺术》）： + +![FixedThreadPool的execute()方法运行示意图](./images/java-thread-pool-summary/FixedThreadPool.png) + +**上图说明：** + +1. 如果当前运行的线程数小于 corePoolSize， 如果再来新任务的话，就创建新的线程来执行任务； +2. 当前运行的线程数等于 corePoolSize 后， 如果再来新任务的话，会将任务加入 `LinkedBlockingQueue`； +3. 线程池中的线程执行完 手头的任务后，会在循环中反复从 `LinkedBlockingQueue` 中获取任务来执行； + +#### 5.1.3 为什么不推荐使用`FixedThreadPool`？ + +**`FixedThreadPool` 使用无界队列 `LinkedBlockingQueue`（队列的容量为 Integer.MAX_VALUE）作为线程池的工作队列会对线程池带来如下影响 ：** + +1. 当线程池中的线程数达到 `corePoolSize` 后，新任务将在无界队列中等待，因此线程池中的线程数不会超过 corePoolSize； +2. 由于使用无界队列时 `maximumPoolSize` 将是一个无效参数，因为不可能存在任务队列满的情况。所以，通过创建 `FixedThreadPool`的源码可以看出创建的 `FixedThreadPool` 的 `corePoolSize` 和 `maximumPoolSize` 被设置为同一个值。 +3. 由于 1 和 2，使用无界队列时 `keepAliveTime` 将是一个无效参数； +4. 运行中的 `FixedThreadPool`（未执行 `shutdown()`或 `shutdownNow()`）不会拒绝任务，在任务比较多的时候会导致 OOM（内存溢出）。 + +### 5.2 SingleThreadExecutor 详解 + +#### 5.2.1 介绍 + +`SingleThreadExecutor` 是只有一个线程的线程池。下面看看**SingleThreadExecutor 的实现：** + +```java + /** + *返回只有一个线程的线程池 + */ + public static ExecutorService newSingleThreadExecutor(ThreadFactory threadFactory) { + return new FinalizableDelegatedExecutorService + (new ThreadPoolExecutor(1, 1, + 0L, TimeUnit.MILLISECONDS, + new LinkedBlockingQueue(), + threadFactory)); + } +``` + +```java + public static ExecutorService newSingleThreadExecutor() { + return new FinalizableDelegatedExecutorService + (new ThreadPoolExecutor(1, 1, + 0L, TimeUnit.MILLISECONDS, + new LinkedBlockingQueue())); + } +``` + +从上面源代码可以看出新创建的 `SingleThreadExecutor` 的 `corePoolSize` 和 `maximumPoolSize` 都被设置为 1.其他参数和 `FixedThreadPool` 相同。 + +#### 5.2.2 执行任务过程介绍 + +`SingleThreadExecutor` 的运行示意图（该图片来源：《Java 并发编程的艺术》）： +![SingleThreadExecutor的运行示意图](./images/java-thread-pool-summary/SingleThreadExecutor.png) + +**上图说明** : + +1. 如果当前运行的线程数少于 `corePoolSize`，则创建一个新的线程执行任务； +2. 当前线程池中有一个运行的线程后，将任务加入 `LinkedBlockingQueue` +3. 线程执行完当前的任务后，会在循环中反复从`LinkedBlockingQueue` 中获取任务来执行； + +#### 5.2.3 为什么不推荐使用`SingleThreadExecutor`？ + +`SingleThreadExecutor` 使用无界队列 `LinkedBlockingQueue` 作为线程池的工作队列（队列的容量为 Intger.MAX_VALUE）。`SingleThreadExecutor` 使用无界队列作为线程池的工作队列会对线程池带来的影响与 `FixedThreadPool` 相同。说简单点就是可能会导致 OOM， + +### 5.3 CachedThreadPool 详解 + +#### 5.3.1 介绍 + +`CachedThreadPool` 是一个会根据需要创建新线程的线程池。下面通过源码来看看 `CachedThreadPool` 的实现： + +```java + /** + * 创建一个线程池，根据需要创建新线程，但会在先前构建的线程可用时重用它。 + */ + public static ExecutorService newCachedThreadPool(ThreadFactory threadFactory) { + return new ThreadPoolExecutor(0, Integer.MAX_VALUE, + 60L, TimeUnit.SECONDS, + new SynchronousQueue(), + threadFactory); + } + +``` + +```java + public static ExecutorService newCachedThreadPool() { + return new ThreadPoolExecutor(0, Integer.MAX_VALUE, + 60L, TimeUnit.SECONDS, + new SynchronousQueue()); + } +``` + +`CachedThreadPool` 的`corePoolSize` 被设置为空（0），`maximumPoolSize`被设置为 `Integer.MAX.VALUE`，即它是无界的，这也就意味着如果主线程提交任务的速度高于 `maximumPool` 中线程处理任务的速度时，`CachedThreadPool` 会不断创建新的线程。极端情况下，这样会导致耗尽 cpu 和内存资源。 + +#### 5.3.2 执行任务过程介绍 + +`CachedThreadPool` 的 `execute()` 方法的执行示意图（该图片来源：《Java 并发编程的艺术》）： +![CachedThreadPool的execute()方法的执行示意图](./images/java-thread-pool-summary/CachedThreadPool-execute.png) + +**上图说明：** + +1. 首先执行 `SynchronousQueue.offer(Runnable task)` 提交任务到任务队列。如果当前 `maximumPool` 中有闲线程正在执行 `SynchronousQueue.poll(keepAliveTime,TimeUnit.NANOSECONDS)`，那么主线程执行 offer 操作与空闲线程执行的 `poll` 操作配对成功，主线程把任务交给空闲线程执行，`execute()`方法执行完成，否则执行下面的步骤 2； +2. 当初始 `maximumPool` 为空，或者 `maximumPool` 中没有空闲线程时，将没有线程执行 `SynchronousQueue.poll(keepAliveTime,TimeUnit.NANOSECONDS)`。这种情况下，步骤 1 将失败，此时 `CachedThreadPool` 会创建新线程执行任务，execute 方法执行完成； + +#### 5.3.3 为什么不推荐使用`CachedThreadPool`？ + +`CachedThreadPool`允许创建的线程数量为 `Integer.MAX_VALUE` ，可能会创建大量线程，从而导致 OOM。 + +## 六 ScheduledThreadPoolExecutor 详解 + +**`ScheduledThreadPoolExecutor` 主要用来在给定的延迟后运行任务，或者定期执行任务。** 这个在实际项目中基本不会被用到，也不推荐使用，大家只需要简单了解一下它的思想即可。 + +### 6.1 简介 + +`ScheduledThreadPoolExecutor` 使用的任务队列 `DelayQueue` 封装了一个 `PriorityQueue`，`PriorityQueue` 会对队列中的任务进行排序，执行所需时间短的放在前面先被执行(`ScheduledFutureTask` 的 `time` 变量小的先执行)，如果执行所需时间相同则先提交的任务将被先执行(`ScheduledFutureTask` 的 `squenceNumber` 变量小的先执行)。 + +**`ScheduledThreadPoolExecutor` 和 `Timer` 的比较：** + +- `Timer` 对系统时钟的变化敏感，`ScheduledThreadPoolExecutor`不是； +- `Timer` 只有一个执行线程，因此长时间运行的任务可以延迟其他任务。 `ScheduledThreadPoolExecutor` 可以配置任意数量的线程。 此外，如果你想（通过提供 ThreadFactory），你可以完全控制创建的线程; +- 在`TimerTask` 中抛出的运行时异常会杀死一个线程，从而导致 `Timer` 死机:-( ...即计划任务将不再运行。`ScheduledThreadExecutor` 不仅捕获运行时异常，还允许您在需要时处理它们（通过重写 `afterExecute` 方法`ThreadPoolExecutor`）。抛出异常的任务将被取消，但其他任务将继续运行。 + +**综上，在 JDK1.5 之后，你没有理由再使用 Timer 进行任务调度了。** + +> 关于定时任务的详细介绍，小伙伴们可以在 JavaGuide 的项目首页搜索“定时任务”找到对应的原创内容。 + +### 6.2 运行机制 + +![ScheduledThreadPoolExecutor运行机制](./images/java-thread-pool-summary/ScheduledThreadPoolExecutor机制.png) + +**`ScheduledThreadPoolExecutor` 的执行主要分为两大部分：** + +1. 当调用 `ScheduledThreadPoolExecutor` 的 **`scheduleAtFixedRate()`** 方法或者 **`scheduleWithFixedDelay()`** 方法时，会向 `ScheduledThreadPoolExecutor` 的 **`DelayQueue`** 添加一个实现了 **`RunnableScheduledFuture`** 接口的 **`ScheduledFutureTask`** 。 +2. 线程池中的线程从 `DelayQueue` 中获取 `ScheduledFutureTask`，然后执行任务。 + +**`ScheduledThreadPoolExecutor` 为了实现周期性的执行任务，对 `ThreadPoolExecutor`做了如下修改：** + +- 使用 **`DelayQueue`** 作为任务队列； +- 获取任务的方不同 +- 执行周期任务后，增加了额外的处理 + +### 6.3 ScheduledThreadPoolExecutor 执行周期任务的步骤 + +![ScheduledThreadPoolExecutor执行周期任务的步骤](./images/java-thread-pool-summary/ScheduledThreadPoolExecutor执行周期任务步骤.png) + +1. 线程 1 从 `DelayQueue` 中获取已到期的 `ScheduledFutureTask（DelayQueue.take()）`。到期任务是指 `ScheduledFutureTask`的 time 大于等于当前系统的时间； +2. 线程 1 执行这个 `ScheduledFutureTask`； +3. 线程 1 修改 `ScheduledFutureTask` 的 time 变量为下次将要被执行的时间； +4. 线程 1 把这个修改 time 之后的 `ScheduledFutureTask` 放回 `DelayQueue` 中（`DelayQueue.add()`)。 + +## 七 线程池大小确定 + +**线程池数量的确定一直是困扰着程序员的一个难题，大部分程序员在设定线程池大小的时候就是随心而定。** + +很多人甚至可能都会觉得把线程池配置过大一点比较好！我觉得这明显是有问题的。就拿我们生活中非常常见的一例子来说：**并不是人多就能把事情做好，增加了沟通交流成本。你本来一件事情只需要 3 个人做，你硬是拉来了 6 个人，会提升做事效率嘛？我想并不会。** 线程数量过多的影响也是和我们分配多少人做事情一样，对于多线程这个场景来说主要是增加了**上下文切换**成本。不清楚什么是上下文切换的话，可以看我下面的介绍。 + +> 上下文切换： +> +> 多线程编程中一般线程的个数都大于 CPU 核心的个数，而一个 CPU 核心在任意时刻只能被一个线程使用，为了让这些线程都能得到有效执行，CPU 采取的策略是为每个线程分配时间片并轮转的形式。当一个线程的时间片用完的时候就会重新处于就绪状态让给其他线程使用，这个过程就属于一次上下文切换。概括来说就是：当前任务在执行完 CPU 时间片切换到另一个任务之前会先保存自己的状态，以便下次再切换回这个任务时，可以再加载这个任务的状态。**任务从保存到再加载的过程就是一次上下文切换**。 +> +> 上下文切换通常是计算密集型的。也就是说，它需要相当可观的处理器时间，在每秒几十上百次的切换中，每次切换都需要纳秒量级的时间。所以，上下文切换对系统来说意味着消耗大量的 CPU 时间，事实上，可能是操作系统中时间消耗最大的操作。 +> +> Linux 相比与其他操作系统（包括其他类 Unix 系统）有很多的优点，其中有一项就是，其上下文切换和模式切换的时间消耗非常少。 + +**类比于实现世界中的人类通过合作做某件事情，我们可以肯定的一点是线程池大小设置过大或者过小都会有问题，合适的才是最好。** + +**如果我们设置的线程池数量太小的话，如果同一时间有大量任务/请求需要处理，可能会导致大量的请求/任务在任务队列中排队等待执行，甚至会出现任务队列满了之后任务/请求无法处理的情况，或者大量任务堆积在任务队列导致 OOM。这样很明显是有问题的！ CPU 根本没有得到充分利用。** + +**但是，如果我们设置线程数量太大，大量线程可能会同时在争取 CPU 资源，这样会导致大量的上下文切换，从而增加线程的执行时间，影响了整体执行效率。** + +有一个简单并且适用面比较广的公式： + +- **CPU 密集型任务(N+1)：** 这种任务消耗的主要是 CPU 资源，可以将线程数设置为 N（CPU 核心数）+1，比 CPU 核心数多出来的一个线程是为了防止线程偶发的缺页中断，或者其它原因导致的任务暂停而带来的影响。一旦任务暂停，CPU 就会处于空闲状态，而在这种情况下多出来的一个线程就可以充分利用 CPU 的空闲时间。 +- **I/O 密集型任务(2N)：** 这种任务应用起来，系统会用大部分的时间来处理 I/O 交互，而线程在处理 I/O 的时间段内不会占用 CPU 来处理，这时就可以将 CPU 交出给其它线程使用。因此在 I/O 密集型任务的应用中，我们可以多配置一些线程，具体的计算方法是 2N。 + +**如何判断是 CPU 密集任务还是 IO 密集任务？** + +CPU 密集型简单理解就是利用 CPU 计算能力的任务比如你在内存中对大量数据进行排序。但凡涉及到网络读取，文件读取这类都是 IO 密集型，这类任务的特点是 CPU 计算耗费时间相比于等待 IO 操作完成的时间来说很少，大部分时间都花在了等待 IO 操作完成上。 + +## 八 参考 + +- 《Java 并发编程的艺术》 +- [Java Scheduler ScheduledExecutorService ScheduledThreadPoolExecutor Example](https://www.journaldev.com/2340/java-scheduler-scheduledexecutorservice-scheduledthreadpoolexecutor-example "Java Scheduler ScheduledExecutorService ScheduledThreadPoolExecutor Example") +- [java.util.concurrent.ScheduledThreadPoolExecutor Example](https://examples.javacodegeeks.com/core-java/util/concurrent/scheduledthreadpoolexecutor/java-util-concurrent-scheduledthreadpoolexecutor-example/ "java.util.concurrent.ScheduledThreadPoolExecutor Example") +- [ThreadPoolExecutor – Java Thread Pool Example](https://www.journaldev.com/1069/threadpoolexecutor-java-thread-pool-example-executorservice "ThreadPoolExecutor – Java Thread Pool Example") + +## 九 其他推荐阅读 + +- [Java 并发（三）线程池原理](https://www.cnblogs.com/warehouse/p/10720781.html "Java并发（三）线程池原理") +- [如何优雅的使用和理解线程池](https://github.com/crossoverJie/JCSprout/blob/master/MD/ThreadPoolExecutor.md "如何优雅的使用和理解线程池") diff --git a/docs/java/concurrent/reentrantlock.md b/docs/java/concurrent/reentrantlock.md new file mode 100644 index 0000000000000000000000000000000000000000..4c6a48cf620da2ab1a2b417a8e72065944a5a60c --- /dev/null +++ b/docs/java/concurrent/reentrantlock.md @@ -0,0 +1,994 @@ +--- +title: 从ReentrantLock的实现看AQS的原理及应用 +category: Java +tag: + - Java并发 +--- + +> 本文转载自：https://tech.meituan.com/2019/12/05/aqs-theory-and-apply.html +> +> 作者：美团技术团队 + +## 前言 + +Java 中的大部分同步类（Lock、Semaphore、ReentrantLock 等）都是基于 AbstractQueuedSynchronizer（简称为 AQS）实现的。AQS 是一种提供了原子式管理同步状态、阻塞和唤醒线程功能以及队列模型的简单框架。本文会从应用层逐渐深入到原理层，并通过 ReentrantLock 的基本特性和 ReentrantLock 与 AQS 的关联，来深入解读 AQS 相关独占锁的知识点，同时采取问答的模式来帮助大家理解 AQS。由于篇幅原因，本篇文章主要阐述 AQS 中独占锁的逻辑和 Sync Queue，不讲述包含共享锁和 Condition Queue 的部分（本篇文章核心为 AQS 原理剖析，只是简单介绍了 ReentrantLock，感兴趣同学可以阅读一下 ReentrantLock 的源码）。 + +## 1 ReentrantLock + +### 1.1 ReentrantLock 特性概览 + +ReentrantLock 意思为可重入锁，指的是一个线程能够对一个临界资源重复加锁。为了帮助大家更好地理解 ReentrantLock 的特性，我们先将 ReentrantLock 跟常用的 Synchronized 进行比较，其特性如下（蓝色部分为本篇文章主要剖析的点）： + +![img](https://p0.meituan.net/travelcube/412d294ff5535bbcddc0d979b2a339e6102264.png) + +下面通过伪代码，进行更加直观的比较： + +```java +// **************************Synchronized的使用方式************************** +// 1.用于代码块 +synchronized (this) {} +// 2.用于对象 +synchronized (object) {} +// 3.用于方法 +public synchronized void test () {} +// 4.可重入 +for (int i = 0; i < 100; i++) { + synchronized (this) {} +} +// **************************ReentrantLock的使用方式************************** +public void test () throw Exception { + // 1.初始化选择公平锁、非公平锁 + ReentrantLock lock = new ReentrantLock(true); + // 2.可用于代码块 + lock.lock(); + try { + try { + // 3.支持多种加锁方式，比较灵活; 具有可重入特性 + if(lock.tryLock(100, TimeUnit.MILLISECONDS)){ } + } finally { + // 4.手动释放锁 + lock.unlock() + } + } finally { + lock.unlock(); + } +} +``` + +### 1.2 ReentrantLock 与 AQS 的关联 + +通过上文我们已经了解，ReentrantLock 支持公平锁和非公平锁（关于公平锁和非公平锁的原理分析，可参考《[不可不说的 Java“锁”事](https://mp.weixin.qq.com/s?__biz=MjM5NjQ5MTI5OA==&mid=2651749434&idx=3&sn=5ffa63ad47fe166f2f1a9f604ed10091&chksm=bd12a5778a652c61509d9e718ab086ff27ad8768586ea9b38c3dcf9e017a8e49bcae3df9bcc8&scene=38#wechat_redirect)》），并且 ReentrantLock 的底层就是由 AQS 来实现的。那么 ReentrantLock 是如何通过公平锁和非公平锁与 AQS 关联起来呢？ 我们着重从这两者的加锁过程来理解一下它们与 AQS 之间的关系（加锁过程中与 AQS 的关联比较明显，解锁流程后续会介绍）。 + +非公平锁源码中的加锁流程如下： + +```java +// java.util.concurrent.locks.ReentrantLock#NonfairSync + +// 非公平锁 +static final class NonfairSync extends Sync { + ... + final void lock() { + if (compareAndSetState(0, 1)) + setExclusiveOwnerThread(Thread.currentThread()); + else + acquire(1); + } + ... +} +``` + +这块代码的含义为： + +- 若通过 CAS 设置变量 State（同步状态）成功，也就是获取锁成功，则将当前线程设置为独占线程。 +- 若通过 CAS 设置变量 State（同步状态）失败，也就是获取锁失败，则进入 Acquire 方法进行后续处理。 + +第一步很好理解，但第二步获取锁失败后，后续的处理策略是怎么样的呢？这块可能会有以下思考： + +- 某个线程获取锁失败的后续流程是什么呢？有以下两种可能： + +(1) 将当前线程获锁结果设置为失败，获取锁流程结束。这种设计会极大降低系统的并发度，并不满足我们实际的需求。所以就需要下面这种流程，也就是 AQS 框架的处理流程。 + +(2) 存在某种排队等候机制，线程继续等待，仍然保留获取锁的可能，获取锁流程仍在继续。 + +- 对于问题 1 的第二种情况，既然说到了排队等候机制，那么就一定会有某种队列形成，这样的队列是什么数据结构呢？ +- 处于排队等候机制中的线程，什么时候可以有机会获取锁呢？ +- 如果处于排队等候机制中的线程一直无法获取锁，还是需要一直等待吗，还是有别的策略来解决这一问题？ + +带着非公平锁的这些问题，再看下公平锁源码中获锁的方式： + +``` +// java.util.concurrent.locks.ReentrantLock#FairSync + +static final class FairSync extends Sync { + ... + final void lock() { + acquire(1); + } + ... +} +``` + +看到这块代码，我们可能会存在这种疑问：Lock 函数通过 Acquire 方法进行加锁，但是具体是如何加锁的呢？ + +结合公平锁和非公平锁的加锁流程，虽然流程上有一定的不同，但是都调用了 Acquire 方法，而 Acquire 方法是 FairSync 和 UnfairSync 的父类 AQS 中的核心方法。 + +对于上边提到的问题，其实在 ReentrantLock 类源码中都无法解答，而这些问题的答案，都是位于 Acquire 方法所在的类 AbstractQueuedSynchronizer 中，也就是本文的核心——AQS。下面我们会对 AQS 以及 ReentrantLock 和 AQS 的关联做详细介绍（相关问题答案会在 2.3.5 小节中解答）。 + +## 2 AQS + +首先，我们通过下面的架构图来整体了解一下 AQS 框架： + +![](https://p1.meituan.net/travelcube/82077ccf14127a87b77cefd1ccf562d3253591.png) + +- 上图中有颜色的为 Method，无颜色的为 Attribution。 +- 总的来说，AQS 框架共分为五层，自上而下由浅入深，从 AQS 对外暴露的 API 到底层基础数据。 +- 当有自定义同步器接入时，只需重写第一层所需要的部分方法即可，不需要关注底层具体的实现流程。当自定义同步器进行加锁或者解锁操作时，先经过第一层的 API 进入 AQS 内部方法，然后经过第二层进行锁的获取，接着对于获取锁失败的流程，进入第三层和第四层的等待队列处理，而这些处理方式均依赖于第五层的基础数据提供层。 + +下面我们会从整体到细节，从流程到方法逐一剖析 AQS 框架，主要分析过程如下： + +![](https://p1.meituan.net/travelcube/d2f7f7fffdc30d85d17b44266c3ab05323338.png) + +### 2.1 原理概览 + +AQS 核心思想是，如果被请求的共享资源空闲，那么就将当前请求资源的线程设置为有效的工作线程，将共享资源设置为锁定状态；如果共享资源被占用，就需要一定的阻塞等待唤醒机制来保证锁分配。这个机制主要用的是 CLH 队列的变体实现的，将暂时获取不到锁的线程加入到队列中。 + +CLH：Craig、Landin and Hagersten 队列，是单向链表，AQS 中的队列是 CLH 变体的虚拟双向队列（FIFO），AQS 是通过将每条请求共享资源的线程封装成一个节点来实现锁的分配。 + +主要原理图如下： + +![](https://p0.meituan.net/travelcube/7132e4cef44c26f62835b197b239147b18062.png) + +AQS 使用一个 Volatile 的 int 类型的成员变量来表示同步状态，通过内置的 FIFO 队列来完成资源获取的排队工作，通过 CAS 完成对 State 值的修改。 + +#### 2.1.1 AQS 数据结构 + +先来看下 AQS 中最基本的数据结构——Node，Node 即为上面 CLH 变体队列中的节点。 + +![](https://p1.meituan.net/travelcube/960271cf2b5c8a185eed23e98b72c75538637.png) + +解释一下几个方法和属性值的含义： + +| 方法和属性值 | 含义 | +| :----------- | :----------------------------------------------------------- | +| waitStatus | 当前节点在队列中的状态 | +| thread | 表示处于该节点的线程 | +| prev | 前驱指针 | +| predecessor | 返回前驱节点，没有的话抛出 npe | +| nextWaiter | 指向下一个处于 CONDITION 状态的节点（由于本篇文章不讲述 Condition Queue 队列，这个指针不多介绍） | +| next | 后继指针 | + +线程两种锁的模式： + +| 模式 | 含义 | +| :-------- | :----------------------------- | +| SHARED | 表示线程以共享的模式等待锁 | +| EXCLUSIVE | 表示线程正在以独占的方式等待锁 | + +waitStatus 有下面几个枚举值： + +| 枚举 | 含义 | +| :-------- | :----------------------------------------------- | +| 0 | 当一个 Node 被初始化的时候的默认值 | +| CANCELLED | 为 1，表示线程获取锁的请求已经取消了 | +| CONDITION | 为-2，表示节点在等待队列中，节点线程等待唤醒 | +| PROPAGATE | 为-3，当前线程处在 SHARED 情况下，该字段才会使用 | +| SIGNAL | 为-1，表示线程已经准备好了，就等资源释放了 | + +#### 2.1.2 同步状态 State + +在了解数据结构后，接下来了解一下 AQS 的同步状态——State。AQS 中维护了一个名为 state 的字段，意为同步状态，是由 Volatile 修饰的，用于展示当前临界资源的获锁情况。 + +```java +// java.util.concurrent.locks.AbstractQueuedSynchronizer + +private volatile int state; +``` + +下面提供了几个访问这个字段的方法： + +| 方法名 | 描述 | +| :----------------------------------------------------------- | :---------------------- | +| protected final int getState() | 获取 State 的值 | +| protected final void setState(int newState) | 设置 State 的值 | +| protected final boolean compareAndSetState(int expect, int update) | 使用 CAS 方式更新 State | + +这几个方法都是 Final 修饰的，说明子类中无法重写它们。我们可以通过修改 State 字段表示的同步状态来实现多线程的独占模式和共享模式（加锁过程）。 + +![](https://p0.meituan.net/travelcube/27605d483e8935da683a93be015713f331378.png) + +![](https://p0.meituan.net/travelcube/3f1e1a44f5b7d77000ba4f9476189b2e32806.png) + +对于我们自定义的同步工具，需要自定义获取同步状态和释放状态的方式，也就是 AQS 架构图中的第一层：API 层。 + +## 2.2 AQS 重要方法与 ReentrantLock 的关联 + +从架构图中可以得知，AQS 提供了大量用于自定义同步器实现的 Protected 方法。自定义同步器实现的相关方法也只是为了通过修改 State 字段来实现多线程的独占模式或者共享模式。自定义同步器需要实现以下方法（ReentrantLock 需要实现的方法如下，并不是全部）： + +| 方法名 | 描述 | +| :------------------------------------------ | :----------------------------------------------------------- | +| protected boolean isHeldExclusively() | 该线程是否正在独占资源。只有用到 Condition 才需要去实现它。 | +| protected boolean tryAcquire(int arg) | 独占方式。arg 为获取锁的次数，尝试获取资源，成功则返回 True，失败则返回 False。 | +| protected boolean tryRelease(int arg) | 独占方式。arg 为释放锁的次数，尝试释放资源，成功则返回 True，失败则返回 False。 | +| protected int tryAcquireShared(int arg) | 共享方式。arg 为获取锁的次数，尝试获取资源。负数表示失败；0 表示成功，但没有剩余可用资源；正数表示成功，且有剩余资源。 | +| protected boolean tryReleaseShared(int arg) | 共享方式。arg 为释放锁的次数，尝试释放资源，如果释放后允许唤醒后续等待结点返回 True，否则返回 False。 | + +一般来说，自定义同步器要么是独占方式，要么是共享方式，它们也只需实现 tryAcquire-tryRelease、tryAcquireShared-tryReleaseShared 中的一种即可。AQS 也支持自定义同步器同时实现独占和共享两种方式，如 ReentrantReadWriteLock。ReentrantLock 是独占锁，所以实现了 tryAcquire-tryRelease。 + +以非公平锁为例，这里主要阐述一下非公平锁与 AQS 之间方法的关联之处，具体每一处核心方法的作用会在文章后面详细进行阐述。 + +![](https://p1.meituan.net/travelcube/b8b53a70984668bc68653efe9531573e78636.png) + +为了帮助大家理解 ReentrantLock 和 AQS 之间方法的交互过程，以非公平锁为例，我们将加锁和解锁的交互流程单独拎出来强调一下，以便于对后续内容的理解。 + +![](https://p1.meituan.net/travelcube/7aadb272069d871bdee8bf3a218eed8136919.png) + +加锁： + +- 通过 ReentrantLock 的加锁方法 Lock 进行加锁操作。 +- 会调用到内部类 Sync 的 Lock 方法，由于 Sync#lock 是抽象方法，根据 ReentrantLock 初始化选择的公平锁和非公平锁，执行相关内部类的 Lock 方法，本质上都会执行 AQS 的 Acquire 方法。 +- AQS 的 Acquire 方法会执行 tryAcquire 方法，但是由于 tryAcquire 需要自定义同步器实现，因此执行了 ReentrantLock 中的 tryAcquire 方法，由于 ReentrantLock 是通过公平锁和非公平锁内部类实现的 tryAcquire 方法，因此会根据锁类型不同，执行不同的 tryAcquire。 +- tryAcquire 是获取锁逻辑，获取失败后，会执行框架 AQS 的后续逻辑，跟 ReentrantLock 自定义同步器无关。 + +解锁： + +- 通过 ReentrantLock 的解锁方法 Unlock 进行解锁。 +- Unlock 会调用内部类 Sync 的 Release 方法，该方法继承于 AQS。 +- Release 中会调用 tryRelease 方法，tryRelease 需要自定义同步器实现，tryRelease 只在 ReentrantLock 中的 Sync 实现，因此可以看出，释放锁的过程，并不区分是否为公平锁。 +- 释放成功后，所有处理由 AQS 框架完成，与自定义同步器无关。 + +通过上面的描述，大概可以总结出 ReentrantLock 加锁解锁时 API 层核心方法的映射关系。 + +![](https://p0.meituan.net/travelcube/f30c631c8ebbf820d3e8fcb6eee3c0ef18748.png) + +## 2.3 通过 ReentrantLock 理解 AQS + +ReentrantLock 中公平锁和非公平锁在底层是相同的，这里以非公平锁为例进行分析。 + +在非公平锁中，有一段这样的代码： + +```java +// java.util.concurrent.locks.ReentrantLock + +static final class NonfairSync extends Sync { + ... + final void lock() { + if (compareAndSetState(0, 1)) + setExclusiveOwnerThread(Thread.currentThread()); + else + acquire(1); + } + ... +} +``` + +看一下这个 Acquire 是怎么写的： + +```java +// java.util.concurrent.locks.AbstractQueuedSynchronizer + +public final void acquire(int arg) { + if (!tryAcquire(arg) && acquireQueued(addWaiter(Node.EXCLUSIVE), arg)) + selfInterrupt(); +} +``` + +再看一下 tryAcquire 方法： + +```java +// java.util.concurrent.locks.AbstractQueuedSynchronizer + +protected boolean tryAcquire(int arg) { + throw new UnsupportedOperationException(); +} +``` + +可以看出，这里只是 AQS 的简单实现，具体获取锁的实现方法是由各自的公平锁和非公平锁单独实现的（以 ReentrantLock 为例）。如果该方法返回了 True，则说明当前线程获取锁成功，就不用往后执行了；如果获取失败，就需要加入到等待队列中。下面会详细解释线程是何时以及怎样被加入进等待队列中的。 + +### 2.3.1 线程加入等待队列 + +#### 2.3.1.1 加入队列的时机 + +当执行 Acquire(1)时，会通过 tryAcquire 获取锁。在这种情况下，如果获取锁失败，就会调用 addWaiter 加入到等待队列中去。 + +#### 2.3.1.2 如何加入队列 + +获取锁失败后，会执行 addWaiter(Node.EXCLUSIVE)加入等待队列，具体实现方法如下： + +```java +// java.util.concurrent.locks.AbstractQueuedSynchronizer + +private Node addWaiter(Node mode) { + Node node = new Node(Thread.currentThread(), mode); + // Try the fast path of enq; backup to full enq on failure + Node pred = tail; + if (pred != null) { + node.prev = pred; + if (compareAndSetTail(pred, node)) { + pred.next = node; + return node; + } + } + enq(node); + return node; +} +private final boolean compareAndSetTail(Node expect, Node update) { + return unsafe.compareAndSwapObject(this, tailOffset, expect, update); +} +``` + +主要的流程如下： + +- 通过当前的线程和锁模式新建一个节点。 +- Pred 指针指向尾节点 Tail。 +- 将 New 中 Node 的 Prev 指针指向 Pred。 +- 通过 compareAndSetTail 方法，完成尾节点的设置。这个方法主要是对 tailOffset 和 Expect 进行比较，如果 tailOffset 的 Node 和 Expect 的 Node 地址是相同的，那么设置 Tail 的值为 Update 的值。 + +```java +// java.util.concurrent.locks.AbstractQueuedSynchronizer + +static { + try { + stateOffset = unsafe.objectFieldOffset(AbstractQueuedSynchronizer.class.getDeclaredField("state")); + headOffset = unsafe.objectFieldOffset(AbstractQueuedSynchronizer.class.getDeclaredField("head")); + tailOffset = unsafe.objectFieldOffset(AbstractQueuedSynchronizer.class.getDeclaredField("tail")); + waitStatusOffset = unsafe.objectFieldOffset(Node.class.getDeclaredField("waitStatus")); + nextOffset = unsafe.objectFieldOffset(Node.class.getDeclaredField("next")); + } catch (Exception ex) { + throw new Error(ex); + } +} +``` + +从 AQS 的静态代码块可以看出，都是获取一个对象的属性相对于该对象在内存当中的偏移量，这样我们就可以根据这个偏移量在对象内存当中找到这个属性。tailOffset 指的是 tail 对应的偏移量，所以这个时候会将 new 出来的 Node 置为当前队列的尾节点。同时，由于是双向链表，也需要将前一个节点指向尾节点。 + +- 如果 Pred 指针是 Null（说明等待队列中没有元素），或者当前 Pred 指针和 Tail 指向的位置不同（说明被别的线程已经修改），就需要看一下 Enq 的方法。 + +```java +// java.util.concurrent.locks.AbstractQueuedSynchronizer + +private Node enq(final Node node) { + for (;;) { + Node t = tail; + if (t == null) { // Must initialize + if (compareAndSetHead(new Node())) + tail = head; + } else { + node.prev = t; + if (compareAndSetTail(t, node)) { + t.next = node; + return t; + } + } + } +} +``` + +如果没有被初始化，需要进行初始化一个头结点出来。但请注意，初始化的头结点并不是当前线程节点，而是调用了无参构造函数的节点。如果经历了初始化或者并发导致队列中有元素，则与之前的方法相同。其实，addWaiter 就是一个在双端链表添加尾节点的操作，需要注意的是，双端链表的头结点是一个无参构造函数的头结点。 + +总结一下，线程获取锁的时候，过程大体如下： + +1. 当没有线程获取到锁时，线程 1 获取锁成功。 +2. 线程 2 申请锁，但是锁被线程 1 占有。 + +![img](https://p0.meituan.net/travelcube/e9e385c3c68f62c67c8d62ab0adb613921117.png) + +1. 如果再有线程要获取锁，依次在队列中往后排队即可。 + +回到上边的代码，hasQueuedPredecessors 是公平锁加锁时判断等待队列中是否存在有效节点的方法。如果返回 False，说明当前线程可以争取共享资源；如果返回 True，说明队列中存在有效节点，当前线程必须加入到等待队列中。 + +```java +// java.util.concurrent.locks.ReentrantLock + +public final boolean hasQueuedPredecessors() { + // The correctness of this depends on head being initialized + // before tail and on head.next being accurate if the current + // thread is first in queue. + Node t = tail; // Read fields in reverse initialization order + Node h = head; + Node s; + return h != t && ((s = h.next) == null || s.thread != Thread.currentThread()); +} +``` + +看到这里，我们理解一下 h != t && ((s = h.next) == null || s.thread != Thread.currentThread());为什么要判断的头结点的下一个节点？第一个节点储存的数据是什么？ + +> 双向链表中，第一个节点为虚节点，其实并不存储任何信息，只是占位。真正的第一个有数据的节点，是在第二个节点开始的。当 h != t 时： 如果(s = h.next) == null，等待队列正在有线程进行初始化，但只是进行到了 Tail 指向 Head，没有将 Head 指向 Tail，此时队列中有元素，需要返回 True（这块具体见下边代码分析）。 如果(s = h.next) != null，说明此时队列中至少有一个有效节点。如果此时 s.thread == Thread.currentThread()，说明等待队列的第一个有效节点中的线程与当前线程相同，那么当前线程是可以获取资源的；如果 s.thread != Thread.currentThread()，说明等待队列的第一个有效节点线程与当前线程不同，当前线程必须加入进等待队列。 + +```java +// java.util.concurrent.locks.AbstractQueuedSynchronizer#enq + +if (t == null) { // Must initialize + if (compareAndSetHead(new Node())) + tail = head; +} else { + node.prev = t; + if (compareAndSetTail(t, node)) { + t.next = node; + return t; + } +} +``` + +节点入队不是原子操作，所以会出现短暂的 head != tail，此时 Tail 指向最后一个节点，而且 Tail 指向 Head。如果 Head 没有指向 Tail（可见 5、6、7 行），这种情况下也需要将相关线程加入队列中。所以这块代码是为了解决极端情况下的并发问题。 + +#### 2.3.1.3 等待队列中线程出队列时机 + +回到最初的源码： + +```java +// java.util.concurrent.locks.AbstractQueuedSynchronizer + +public final void acquire(int arg) { + if (!tryAcquire(arg) && acquireQueued(addWaiter(Node.EXCLUSIVE), arg)) + selfInterrupt(); +} +``` + +上文解释了 addWaiter 方法，这个方法其实就是把对应的线程以 Node 的数据结构形式加入到双端队列里，返回的是一个包含该线程的 Node。而这个 Node 会作为参数，进入到 acquireQueued 方法中。acquireQueued 方法可以对排队中的线程进行“获锁”操作。 + +总的来说，一个线程获取锁失败了，被放入等待队列，acquireQueued 会把放入队列中的线程不断去获取锁，直到获取成功或者不再需要获取（中断）。 + +下面我们从“何时出队列？”和“如何出队列？”两个方向来分析一下 acquireQueued 源码： + +```java +// java.util.concurrent.locks.AbstractQueuedSynchronizer + +final boolean acquireQueued(final Node node, int arg) { + // 标记是否成功拿到资源 + boolean failed = true; + try { + // 标记等待过程中是否中断过 + boolean interrupted = false; + // 开始自旋，要么获取锁，要么中断 + for (;;) { + // 获取当前节点的前驱节点 + final Node p = node.predecessor(); + // 如果p是头结点，说明当前节点在真实数据队列的首部，就尝试获取锁（别忘了头结点是虚节点） + if (p == head && tryAcquire(arg)) { + // 获取锁成功，头指针移动到当前node + setHead(node); + p.next = null; // help GC + failed = false; + return interrupted; + } + // 说明p为头节点且当前没有获取到锁（可能是非公平锁被抢占了）或者是p不为头结点，这个时候就要判断当前node是否要被阻塞（被阻塞条件：前驱节点的waitStatus为-1），防止无限循环浪费资源。具体两个方法下面细细分析 + if (shouldParkAfterFailedAcquire(p, node) && parkAndCheckInterrupt()) + interrupted = true; + } + } finally { + if (failed) + cancelAcquire(node); + } +} +``` + +注：setHead 方法是把当前节点置为虚节点，但并没有修改 waitStatus，因为它是一直需要用的数据。 + +```java +// java.util.concurrent.locks.AbstractQueuedSynchronizer + +private void setHead(Node node) { + head = node; + node.thread = null; + node.prev = null; +} + +// java.util.concurrent.locks.AbstractQueuedSynchronizer + +// 靠前驱节点判断当前线程是否应该被阻塞 +private static boolean shouldParkAfterFailedAcquire(Node pred, Node node) { + // 获取头结点的节点状态 + int ws = pred.waitStatus; + // 说明头结点处于唤醒状态 + if (ws == Node.SIGNAL) + return true; + // 通过枚举值我们知道waitStatus>0是取消状态 + if (ws > 0) { + do { + // 循环向前查找取消节点，把取消节点从队列中剔除 + node.prev = pred = pred.prev; + } while (pred.waitStatus > 0); + pred.next = node; + } else { + // 设置前任节点等待状态为SIGNAL + compareAndSetWaitStatus(pred, ws, Node.SIGNAL); + } + return false; +} +``` + +parkAndCheckInterrupt 主要用于挂起当前线程，阻塞调用栈，返回当前线程的中断状态。 + +```java +// java.util.concurrent.locks.AbstractQueuedSynchronizer + +private final boolean parkAndCheckInterrupt() { + LockSupport.park(this); + return Thread.interrupted(); +} +``` + +上述方法的流程图如下： + +![](https://p0.meituan.net/travelcube/c124b76dcbefb9bdc778458064703d1135485.png) + +从上图可以看出，跳出当前循环的条件是当“前置节点是头结点，且当前线程获取锁成功”。为了防止因死循环导致 CPU 资源被浪费，我们会判断前置节点的状态来决定是否要将当前线程挂起，具体挂起流程用流程图表示如下（shouldParkAfterFailedAcquire 流程）： + +![](https://p0.meituan.net/travelcube/9af16e2481ad85f38ca322a225ae737535740.png) + +从队列中释放节点的疑虑打消了，那么又有新问题了： + +- shouldParkAfterFailedAcquire 中取消节点是怎么生成的呢？什么时候会把一个节点的 waitStatus 设置为-1？ +- 是在什么时间释放节点通知到被挂起的线程呢？ + +### 2.3.2 CANCELLED 状态节点生成 + +acquireQueued 方法中的 Finally 代码： + +```java +// java.util.concurrent.locks.AbstractQueuedSynchronizer + +final boolean acquireQueued(final Node node, int arg) { + boolean failed = true; + try { + ... + for (;;) { + final Node p = node.predecessor(); + if (p == head && tryAcquire(arg)) { + ... + failed = false; + ... + } + ... + } finally { + if (failed) + cancelAcquire(node); + } +} +``` + +通过 cancelAcquire 方法，将 Node 的状态标记为 CANCELLED。接下来，我们逐行来分析这个方法的原理： + +```java +// java.util.concurrent.locks.AbstractQueuedSynchronizer + +private void cancelAcquire(Node node) { + // 将无效节点过滤 + if (node == null) + return; + // 设置该节点不关联任何线程，也就是虚节点 + node.thread = null; + Node pred = node.prev; + // 通过前驱节点，跳过取消状态的node + while (pred.waitStatus > 0) + node.prev = pred = pred.prev; + // 获取过滤后的前驱节点的后继节点 + Node predNext = pred.next; + // 把当前node的状态设置为CANCELLED + node.waitStatus = Node.CANCELLED; + // 如果当前节点是尾节点，将从后往前的第一个非取消状态的节点设置为尾节点 + // 更新失败的话，则进入else，如果更新成功，将tail的后继节点设置为null + if (node == tail && compareAndSetTail(node, pred)) { + compareAndSetNext(pred, predNext, null); + } else { + int ws; + // 如果当前节点不是head的后继节点，1:判断当前节点前驱节点的是否为SIGNAL，2:如果不是，则把前驱节点设置为SINGAL看是否成功 + // 如果1和2中有一个为true，再判断当前节点的线程是否为null + // 如果上述条件都满足，把当前节点的前驱节点的后继指针指向当前节点的后继节点 + if (pred != head && ((ws = pred.waitStatus) == Node.SIGNAL || (ws <= 0 && compareAndSetWaitStatus(pred, ws, Node.SIGNAL))) && pred.thread != null) { + Node next = node.next; + if (next != null && next.waitStatus <= 0) + compareAndSetNext(pred, predNext, next); + } else { + // 如果当前节点是head的后继节点，或者上述条件不满足，那就唤醒当前节点的后继节点 + unparkSuccessor(node); + } + node.next = node; // help GC + } +} +``` + +当前的流程： + +- 获取当前节点的前驱节点，如果前驱节点的状态是 CANCELLED，那就一直往前遍历，找到第一个 waitStatus <= 0 的节点，将找到的 Pred 节点和当前 Node 关联，将当前 Node 设置为 CANCELLED。 +- 根据当前节点的位置，考虑以下三种情况： + +(1) 当前节点是尾节点。 + +(2) 当前节点是 Head 的后继节点。 + +(3) 当前节点不是 Head 的后继节点，也不是尾节点。 + +根据上述第二条，我们来分析每一种情况的流程。 + +当前节点是尾节点。 + +![](https://p1.meituan.net/travelcube/b845211ced57561c24f79d56194949e822049.png) + +当前节点是 Head 的后继节点。 + +![](https://p1.meituan.net/travelcube/ab89bfec875846e5028a4f8fead32b7117975.png) + +当前节点不是 Head 的后继节点，也不是尾节点。 + +![](https://p0.meituan.net/travelcube/45d0d9e4a6897eddadc4397cf53d6cd522452.png) + +通过上面的流程，我们对于 CANCELLED 节点状态的产生和变化已经有了大致的了解，但是为什么所有的变化都是对 Next 指针进行了操作，而没有对 Prev 指针进行操作呢？什么情况下会对 Prev 指针进行操作？ + +> 执行 cancelAcquire 的时候，当前节点的前置节点可能已经从队列中出去了（已经执行过 Try 代码块中的 shouldParkAfterFailedAcquire 方法了），如果此时修改 Prev 指针，有可能会导致 Prev 指向另一个已经移除队列的 Node，因此这块变化 Prev 指针不安全。 shouldParkAfterFailedAcquire 方法中，会执行下面的代码，其实就是在处理 Prev 指针。shouldParkAfterFailedAcquire 是获取锁失败的情况下才会执行，进入该方法后，说明共享资源已被获取，当前节点之前的节点都不会出现变化，因此这个时候变更 Prev 指针比较安全。 +> +> ```java +> do { +> node.prev = pred = pred.prev; +> } while (pred.waitStatus > 0); +> ``` + +### 2.3.3 如何解锁 + +我们已经剖析了加锁过程中的基本流程，接下来再对解锁的基本流程进行分析。由于 ReentrantLock 在解锁的时候，并不区分公平锁和非公平锁，所以我们直接看解锁的源码： + +```java +// java.util.concurrent.locks.ReentrantLock + +public void unlock() { + sync.release(1); +} +``` + +可以看到，本质释放锁的地方，是通过框架来完成的。 + +```java +// java.util.concurrent.locks.AbstractQueuedSynchronizer + +public final boolean release(int arg) { + if (tryRelease(arg)) { + Node h = head; + if (h != null && h.waitStatus != 0) + unparkSuccessor(h); + return true; + } + return false; +} +``` + +在 ReentrantLock 里面的公平锁和非公平锁的父类 Sync 定义了可重入锁的释放锁机制。 + +```java +// java.util.concurrent.locks.ReentrantLock.Sync + +// 方法返回当前锁是不是没有被线程持有 +protected final boolean tryRelease(int releases) { + // 减少可重入次数 + int c = getState() - releases; + // 当前线程不是持有锁的线程，抛出异常 + if (Thread.currentThread() != getExclusiveOwnerThread()) + throw new IllegalMonitorStateException(); + boolean free = false; + // 如果持有线程全部释放，将当前独占锁所有线程设置为null，并更新state + if (c == 0) { + free = true; + setExclusiveOwnerThread(null); + } + setState(c); + return free; +} +``` + +我们来解释下述源码： + +```java +// java.util.concurrent.locks.AbstractQueuedSynchronizer + +public final boolean release(int arg) { + // 上边自定义的tryRelease如果返回true，说明该锁没有被任何线程持有 + if (tryRelease(arg)) { + // 获取头结点 + Node h = head; + // 头结点不为空并且头结点的waitStatus不是初始化节点情况，解除线程挂起状态 + if (h != null && h.waitStatus != 0) + unparkSuccessor(h); + return true; + } + return false; +} +``` + +这里的判断条件为什么是 h != null && h.waitStatus != 0？ + +> h == null Head 还没初始化。初始情况下，head == null，第一个节点入队，Head 会被初始化一个虚拟节点。所以说，这里如果还没来得及入队，就会出现 head == null 的情况。 +> +> h != null && waitStatus == 0 表明后继节点对应的线程仍在运行中，不需要唤醒。 +> +> h != null && waitStatus < 0 表明后继节点可能被阻塞了，需要唤醒。 + +再看一下 unparkSuccessor 方法： + +```java +// java.util.concurrent.locks.AbstractQueuedSynchronizer + +private void unparkSuccessor(Node node) { + // 获取头结点waitStatus + int ws = node.waitStatus; + if (ws < 0) + compareAndSetWaitStatus(node, ws, 0); + // 获取当前节点的下一个节点 + Node s = node.next; + // 如果下个节点是null或者下个节点被cancelled，就找到队列最开始的非cancelled的节点 + if (s == null || s.waitStatus > 0) { + s = null; + // 就从尾部节点开始找，到队首，找到队列第一个waitStatus<0的节点。 + for (Node t = tail; t != null && t != node; t = t.prev) + if (t.waitStatus <= 0) + s = t; + } + // 如果当前节点的下个节点不为空，而且状态<=0，就把当前节点unpark + if (s != null) + LockSupport.unpark(s.thread); +} +``` + +为什么要从后往前找第一个非 Cancelled 的节点呢？原因如下。 + +之前的 addWaiter 方法： + +```java +// java.util.concurrent.locks.AbstractQueuedSynchronizer + +private Node addWaiter(Node mode) { + Node node = new Node(Thread.currentThread(), mode); + // Try the fast path of enq; backup to full enq on failure + Node pred = tail; + if (pred != null) { + node.prev = pred; + if (compareAndSetTail(pred, node)) { + pred.next = node; + return node; + } + } + enq(node); + return node; +} +``` + +我们从这里可以看到，节点入队并不是原子操作，也就是说，node.prev = pred; compareAndSetTail(pred, node) 这两个地方可以看作 Tail 入队的原子操作，但是此时 pred.next = node;还没执行，如果这个时候执行了 unparkSuccessor 方法，就没办法从前往后找了，所以需要从后往前找。还有一点原因，在产生 CANCELLED 状态节点的时候，先断开的是 Next 指针，Prev 指针并未断开，因此也是必须要从后往前遍历才能够遍历完全部的 Node。 + +综上所述，如果是从前往后找，由于极端情况下入队的非原子操作和 CANCELLED 节点产生过程中断开 Next 指针的操作，可能会导致无法遍历所有的节点。所以，唤醒对应的线程后，对应的线程就会继续往下执行。继续执行 acquireQueued 方法以后，中断如何处理？ + +### 2.3.4 中断恢复后的执行流程 + +唤醒后，会执行 return Thread.interrupted();，这个函数返回的是当前执行线程的中断状态，并清除。 + +```java +// java.util.concurrent.locks.AbstractQueuedSynchronizer + +private final boolean parkAndCheckInterrupt() { + LockSupport.park(this); + return Thread.interrupted(); +} +``` + +再回到 acquireQueued 代码，当 parkAndCheckInterrupt 返回 True 或者 False 的时候，interrupted 的值不同，但都会执行下次循环。如果这个时候获取锁成功，就会把当前 interrupted 返回。 + +```java +// java.util.concurrent.locks.AbstractQueuedSynchronizer + +final boolean acquireQueued(final Node node, int arg) { + boolean failed = true; + try { + boolean interrupted = false; + for (;;) { + final Node p = node.predecessor(); + if (p == head && tryAcquire(arg)) { + setHead(node); + p.next = null; // help GC + failed = false; + return interrupted; + } + if (shouldParkAfterFailedAcquire(p, node) && parkAndCheckInterrupt()) + interrupted = true; + } + } finally { + if (failed) + cancelAcquire(node); + } +} +``` + +如果 acquireQueued 为 True，就会执行 selfInterrupt 方法。 + +```java +// java.util.concurrent.locks.AbstractQueuedSynchronizer + +static void selfInterrupt() { + Thread.currentThread().interrupt(); +} +``` + +该方法其实是为了中断线程。但为什么获取了锁以后还要中断线程呢？这部分属于 Java 提供的协作式中断知识内容，感兴趣同学可以查阅一下。这里简单介绍一下： + +1. 当中断线程被唤醒时，并不知道被唤醒的原因，可能是当前线程在等待中被中断，也可能是释放了锁以后被唤醒。因此我们通过 Thread.interrupted()方法检查中断标记（该方法返回了当前线程的中断状态，并将当前线程的中断标识设置为 False），并记录下来，如果发现该线程被中断过，就再中断一次。 +2. 线程在等待资源的过程中被唤醒，唤醒后还是会不断地去尝试获取锁，直到抢到锁为止。也就是说，在整个流程中，并不响应中断，只是记录中断记录。最后抢到锁返回了，那么如果被中断过的话，就需要补充一次中断。 + +这里的处理方式主要是运用线程池中基本运作单元 Worder 中的 runWorker，通过 Thread.interrupted()进行额外的判断处理，感兴趣的同学可以看下 ThreadPoolExecutor 源码。 + +### 2.3.5 小结 + +我们在 1.3 小节中提出了一些问题，现在来回答一下。 + +> Q：某个线程获取锁失败的后续流程是什么呢？ +> +> A：存在某种排队等候机制，线程继续等待，仍然保留获取锁的可能，获取锁流程仍在继续。 +> +> Q：既然说到了排队等候机制，那么就一定会有某种队列形成，这样的队列是什么数据结构呢？ +> +> A：是 CLH 变体的 FIFO 双端队列。 +> +> Q：处于排队等候机制中的线程，什么时候可以有机会获取锁呢？ +> +> A：可以详细看下 2.3.1.3 小节。 +> +> Q：如果处于排队等候机制中的线程一直无法获取锁，需要一直等待么？还是有别的策略来解决这一问题？ +> +> A：线程所在节点的状态会变成取消状态，取消状态的节点会从队列中释放，具体可见 2.3.2 小节。 +> +> Q：Lock 函数通过 Acquire 方法进行加锁，但是具体是如何加锁的呢？ +> +> A：AQS 的 Acquire 会调用 tryAcquire 方法，tryAcquire 由各个自定义同步器实现，通过 tryAcquire 完成加锁过程。 + +## 3 AQS 应用 + +### 3.1 ReentrantLock 的可重入应用 + +ReentrantLock 的可重入性是 AQS 很好的应用之一，在了解完上述知识点以后，我们很容易得知 ReentrantLock 实现可重入的方法。在 ReentrantLock 里面，不管是公平锁还是非公平锁，都有一段逻辑。 + +公平锁： + +```java +// java.util.concurrent.locks.ReentrantLock.FairSync#tryAcquire + +if (c == 0) { + if (!hasQueuedPredecessors() && compareAndSetState(0, acquires)) { + setExclusiveOwnerThread(current); + return true; + } +} +else if (current == getExclusiveOwnerThread()) { + int nextc = c + acquires; + if (nextc < 0) + throw new Error("Maximum lock count exceeded"); + setState(nextc); + return true; +} +``` + +非公平锁： + +```java +// java.util.concurrent.locks.ReentrantLock.Sync#nonfairTryAcquire + +if (c == 0) { + if (compareAndSetState(0, acquires)){ + setExclusiveOwnerThread(current); + return true; + } +} +else if (current == getExclusiveOwnerThread()) { + int nextc = c + acquires; + if (nextc < 0) // overflow + throw new Error("Maximum lock count exceeded"); + setState(nextc); + return true; +} +``` + +从上面这两段都可以看到，有一个同步状态 State 来控制整体可重入的情况。State 是 Volatile 修饰的，用于保证一定的可见性和有序性。 + +```java +// java.util.concurrent.locks.AbstractQueuedSynchronizer + +private volatile int state; +``` + +接下来看 State 这个字段主要的过程： + +1. State 初始化的时候为 0，表示没有任何线程持有锁。 +2. 当有线程持有该锁时，值就会在原来的基础上+1，同一个线程多次获得锁是，就会多次+1，这里就是可重入的概念。 +3. 解锁也是对这个字段-1，一直到 0，此线程对锁释放。 + +### 3.2 JUC 中的应用场景 + +除了上边 ReentrantLock 的可重入性的应用，AQS 作为并发编程的框架，为很多其他同步工具提供了良好的解决方案。下面列出了 JUC 中的几种同步工具，大体介绍一下 AQS 的应用场景： + +| 同步工具 | 同步工具与 AQS 的关联 | +| :--------------------- | :----------------------------------------------------------- | +| ReentrantLock | 使用 AQS 保存锁重复持有的次数。当一个线程获取锁时，ReentrantLock 记录当前获得锁的线程标识，用于检测是否重复获取，以及错误线程试图解锁操作时异常情况的处理。 | +| Semaphore | 使用 AQS 同步状态来保存信号量的当前计数。tryRelease 会增加计数，acquireShared 会减少计数。 | +| CountDownLatch | 使用 AQS 同步状态来表示计数。计数为 0 时，所有的 Acquire 操作（CountDownLatch 的 await 方法）才可以通过。 | +| ReentrantReadWriteLock | 使用 AQS 同步状态中的 16 位保存写锁持有的次数，剩下的 16 位用于保存读锁的持有次数。 | +| ThreadPoolExecutor | Worker 利用 AQS 同步状态实现对独占线程变量的设置（tryAcquire 和 tryRelease）。 | + +### 3.3 自定义同步工具 + +了解 AQS 基本原理以后，按照上面所说的 AQS 知识点，自己实现一个同步工具。 + +```java +public class LeeLock { + + private static class Sync extends AbstractQueuedSynchronizer { + @Override + protected boolean tryAcquire (int arg) { + return compareAndSetState(0, 1); + } + + @Override + protected boolean tryRelease (int arg) { + setState(0); + return true; + } + + @Override + protected boolean isHeldExclusively () { + return getState() == 1; + } + } + + private Sync sync = new Sync(); + + public void lock () { + sync.acquire(1); + } + + public void unlock () { + sync.release(1); + } +} +``` + +通过我们自己定义的 Lock 完成一定的同步功能。 + +```java +public class LeeMain { + + static int count = 0; + static LeeLock leeLock = new LeeLock(); + + public static void main (String[] args) throws InterruptedException { + + Runnable runnable = new Runnable() { + @Override + public void run () { + try { + leeLock.lock(); + for (int i = 0; i < 10000; i++) { + count++; + } + } catch (Exception e) { + e.printStackTrace(); + } finally { + leeLock.unlock(); + } + + } + }; + Thread thread1 = new Thread(runnable); + Thread thread2 = new Thread(runnable); + thread1.start(); + thread2.start(); + thread1.join(); + thread2.join(); + System.out.println(count); + } +} +``` + +上述代码每次运行结果都会是 20000。通过简单的几行代码就能实现同步功能，这就是 AQS 的强大之处。 + +## 总结 + +我们日常开发中使用并发的场景太多，但是对并发内部的基本框架原理了解的人却不多。由于篇幅原因，本文仅介绍了可重入锁 ReentrantLock 的原理和 AQS 原理，希望能够成为大家了解 AQS 和 ReentrantLock 等同步器的“敲门砖”。 + +## 参考资料 + +- Lea D. The java. util. concurrent synchronizer framework[J]. Science of Computer Programming, 2005, 58(3): 293-309. +- 《Java 并发编程实战》 +- [不可不说的 Java“锁”事](https://tech.meituan.com/2018/11/15/java-lock.html) \ No newline at end of file diff --git a/docs/java/concurrent/threadlocal.md b/docs/java/concurrent/threadlocal.md new file mode 100644 index 0000000000000000000000000000000000000000..a4aff50f23acddf86cb806279ea5466ee817f9df --- /dev/null +++ b/docs/java/concurrent/threadlocal.md @@ -0,0 +1,914 @@ +--- +title: 万字解析 ThreadLocal 关键字 +category: Java +tag: + - Java并发 +--- + + + +> 本文来自一枝花算不算浪漫投稿， 原文地址：[https://juejin.im/post/5eacc1c75188256d976df748](https://juejin.im/post/5eacc1c75188256d976df748)。 + +### 前言 + +![](./images/thread-local/1.png) + +**全文共 10000+字，31 张图，这篇文章同样耗费了不少的时间和精力才创作完成，原创不易，请大家点点关注+在看，感谢。** + +对于`ThreadLocal`，大家的第一反应可能是很简单呀，线程的变量副本，每个线程隔离。那这里有几个问题大家可以思考一下： + +- `ThreadLocal`的 key 是**弱引用**，那么在 `ThreadLocal.get()`的时候，发生**GC**之后，key 是否为**null**？ +- `ThreadLocal`中`ThreadLocalMap`的**数据结构**？ +- `ThreadLocalMap`的**Hash 算法**？ +- `ThreadLocalMap`中**Hash 冲突**如何解决？ +- `ThreadLocalMap`的**扩容机制**？ +- `ThreadLocalMap`中**过期 key 的清理机制**？**探测式清理**和**启发式清理**流程？ +- `ThreadLocalMap.set()`方法实现原理？ +- `ThreadLocalMap.get()`方法实现原理？ +- 项目中`ThreadLocal`使用情况？遇到的坑？ +- ...... + +上述的一些问题你是否都已经掌握的很清楚了呢？本文将围绕这些问题使用图文方式来剖析`ThreadLocal`的**点点滴滴**。 + +### 目录 + +**注明：** 本文源码基于`JDK 1.8` + +### `ThreadLocal`代码演示 + +我们先看下`ThreadLocal`使用示例： + +```java +public class ThreadLocalTest { + private List messages = Lists.newArrayList(); + + public static final ThreadLocal holder = ThreadLocal.withInitial(ThreadLocalTest::new); + + public static void add(String message) { + holder.get().messages.add(message); + } + + public static List clear() { + List messages = holder.get().messages; + holder.remove(); + + System.out.println("size: " + holder.get().messages.size()); + return messages; + } + + public static void main(String[] args) { + ThreadLocalTest.add("一枝花算不算浪漫"); + System.out.println(holder.get().messages); + ThreadLocalTest.clear(); + } +} +``` + +打印结果： + +```java +[一枝花算不算浪漫] +size: 0 +``` + +`ThreadLocal`对象可以提供线程局部变量，每个线程`Thread`拥有一份自己的**副本变量**，多个线程互不干扰。 + +### `ThreadLocal`的数据结构 + +![](./images/thread-local/2.png) + +`Thread`类有一个类型为`ThreadLocal.ThreadLocalMap`的实例变量`threadLocals`，也就是说每个线程有一个自己的`ThreadLocalMap`。 + +`ThreadLocalMap`有自己的独立实现，可以简单地将它的`key`视作`ThreadLocal`，`value`为代码中放入的值（实际上`key`并不是`ThreadLocal`本身，而是它的一个**弱引用**）。 + +每个线程在往`ThreadLocal`里放值的时候，都会往自己的`ThreadLocalMap`里存，读也是以`ThreadLocal`作为引用，在自己的`map`里找对应的`key`，从而实现了**线程隔离**。 + +`ThreadLocalMap`有点类似`HashMap`的结构，只是`HashMap`是由**数组+链表**实现的，而`ThreadLocalMap`中并没有**链表**结构。 + +我们还要注意`Entry`， 它的`key`是`ThreadLocal k` ，继承自`WeakReference`， 也就是我们常说的弱引用类型。 + +### GC 之后 key 是否为 null？ + +回应开头的那个问题， `ThreadLocal` 的`key`是弱引用，那么在`ThreadLocal.get()`的时候，发生`GC`之后，`key`是否是`null`？ + +为了搞清楚这个问题，我们需要搞清楚`Java`的**四种引用类型**： + +- **强引用**：我们常常 new 出来的对象就是强引用类型，只要强引用存在，垃圾回收器将永远不会回收被引用的对象，哪怕内存不足的时候 +- **软引用**：使用 SoftReference 修饰的对象被称为软引用，软引用指向的对象在内存要溢出的时候被回收 +- **弱引用**：使用 WeakReference 修饰的对象被称为弱引用，只要发生垃圾回收，若这个对象只被弱引用指向，那么就会被回收 +- **虚引用**：虚引用是最弱的引用，在 Java 中使用 PhantomReference 进行定义。虚引用中唯一的作用就是用队列接收对象即将死亡的通知 + +接着再来看下代码，我们使用反射的方式来看看`GC`后`ThreadLocal`中的数据情况：(下面代码来源自：https://blog.csdn.net/thewindkee/article/details/103726942 本地运行演示 GC 回收场景) + +```java +public class ThreadLocalDemo { + + public static void main(String[] args) throws NoSuchFieldException, IllegalAccessException, InterruptedException { + Thread t = new Thread(()->test("abc",false)); + t.start(); + t.join(); + System.out.println("--gc后--"); + Thread t2 = new Thread(() -> test("def", true)); + t2.start(); + t2.join(); + } + + private static void test(String s,boolean isGC) { + try { + new ThreadLocal<>().set(s); + if (isGC) { + System.gc(); + } + Thread t = Thread.currentThread(); + Class clz = t.getClass(); + Field field = clz.getDeclaredField("threadLocals"); + field.setAccessible(true); + Object ThreadLocalMap = field.get(t); + Class tlmClass = ThreadLocalMap.getClass(); + Field tableField = tlmClass.getDeclaredField("table"); + tableField.setAccessible(true); + Object[] arr = (Object[]) tableField.get(ThreadLocalMap); + for (Object o : arr) { + if (o != null) { + Class entryClass = o.getClass(); + Field valueField = entryClass.getDeclaredField("value"); + Field referenceField = entryClass.getSuperclass().getSuperclass().getDeclaredField("referent"); + valueField.setAccessible(true); + referenceField.setAccessible(true); + System.out.println(String.format("弱引用key:%s,值:%s", referenceField.get(o), valueField.get(o))); + } + } + } catch (Exception e) { + e.printStackTrace(); + } + } +} +``` + +结果如下： + +```java +弱引用key:java.lang.ThreadLocal@433619b6,值:abc +弱引用key:java.lang.ThreadLocal@418a15e3,值:java.lang.ref.SoftReference@bf97a12 +--gc后-- +弱引用key:null,值:def +``` + +![](./images/thread-local/3.png) + +如图所示，因为这里创建的`ThreadLocal`并没有指向任何值，也就是没有任何引用： + +```java +new ThreadLocal<>().set(s); +``` + +所以这里在`GC`之后，`key`就会被回收，我们看到上面`debug`中的`referent=null`, 如果**改动一下代码：** + +![](./images/thread-local/4.png) + +这个问题刚开始看，如果没有过多思考，**弱引用**，还有**垃圾回收**，那么肯定会觉得是`null`。 + +其实是不对的，因为题目说的是在做 `ThreadLocal.get()` 操作，证明其实还是有**强引用**存在的，所以 `key` 并不为 `null`，如下图所示，`ThreadLocal`的**强引用**仍然是存在的。 + +![image.png](./images/thread-local/5.png) + +如果我们的**强引用**不存在的话，那么 `key` 就会被回收，也就是会出现我们 `value` 没被回收，`key` 被回收，导致 `value` 永远存在，出现内存泄漏。 + +### `ThreadLocal.set()`方法源码详解 + +![](./images/thread-local/6.png) + +`ThreadLocal`中的`set`方法原理如上图所示，很简单，主要是判断`ThreadLocalMap`是否存在，然后使用`ThreadLocal`中的`set`方法进行数据处理。 + +代码如下： + +```java +public void set(T value) { + Thread t = Thread.currentThread(); + ThreadLocalMap map = getMap(t); + if (map != null) + map.set(this, value); + else + createMap(t, value); +} + +void createMap(Thread t, T firstValue) { + t.threadLocals = new ThreadLocalMap(this, firstValue); +} +``` + +主要的核心逻辑还是在`ThreadLocalMap`中的，一步步往下看，后面还有更详细的剖析。 + +### `ThreadLocalMap` Hash 算法 + +既然是`Map`结构，那么`ThreadLocalMap`当然也要实现自己的`hash`算法来解决散列表数组冲突问题。 + +```java +int i = key.threadLocalHashCode & (len-1); +``` + +`ThreadLocalMap`中`hash`算法很简单，这里`i`就是当前 key 在散列表中对应的数组下标位置。 + +这里最关键的就是`threadLocalHashCode`值的计算，`ThreadLocal`中有一个属性为`HASH_INCREMENT = 0x61c88647` + +```java +public class ThreadLocal { + private final int threadLocalHashCode = nextHashCode(); + + private static AtomicInteger nextHashCode = new AtomicInteger(); + + private static final int HASH_INCREMENT = 0x61c88647; + + private static int nextHashCode() { + return nextHashCode.getAndAdd(HASH_INCREMENT); + } + + static class ThreadLocalMap { + ThreadLocalMap(ThreadLocal firstKey, Object firstValue) { + table = new Entry[INITIAL_CAPACITY]; + int i = firstKey.threadLocalHashCode & (INITIAL_CAPACITY - 1); + + table[i] = new Entry(firstKey, firstValue); + size = 1; + setThreshold(INITIAL_CAPACITY); + } + } +} +``` + +每当创建一个`ThreadLocal`对象，这个`ThreadLocal.nextHashCode` 这个值就会增长 `0x61c88647` 。 + +这个值很特殊，它是**斐波那契数** 也叫 **黄金分割数**。`hash`增量为 这个数字，带来的好处就是 `hash` **分布非常均匀**。 + +我们自己可以尝试下： + +![](./images/thread-local/8.png) + +可以看到产生的哈希码分布很均匀，这里不去细纠**斐波那契**具体算法，感兴趣的可以自行查阅相关资料。 + +### `ThreadLocalMap` Hash 冲突 + +> **注明：** 下面所有示例图中，**绿色块**`Entry`代表**正常数据**，**灰色块**代表`Entry`的`key`值为`null`，**已被垃圾回收**。**白色块**表示`Entry`为`null`。 + +虽然`ThreadLocalMap`中使用了**黄金分割数**来作为`hash`计算因子，大大减少了`Hash`冲突的概率，但是仍然会存在冲突。 + +`HashMap`中解决冲突的方法是在数组上构造一个**链表**结构，冲突的数据挂载到链表上，如果链表长度超过一定数量则会转化成**红黑树**。 + +而 `ThreadLocalMap` 中并没有链表结构，所以这里不能使用 `HashMap` 解决冲突的方式了。 + +![](./images/thread-local/7.png) + +如上图所示，如果我们插入一个`value=27`的数据，通过 `hash` 计算后应该落入槽位 4 中，而槽位 4 已经有了 `Entry` 数据。 + +此时就会线性向后查找，一直找到 `Entry` 为 `null` 的槽位才会停止查找，将当前元素放入此槽位中。当然迭代过程中还有其他的情况，比如遇到了 `Entry` 不为 `null` 且 `key` 值相等的情况，还有 `Entry` 中的 `key` 值为 `null` 的情况等等都会有不同的处理，后面会一一详细讲解。 + +这里还画了一个`Entry`中的`key`为`null`的数据（**Entry=2 的灰色块数据**），因为`key`值是**弱引用**类型，所以会有这种数据存在。在`set`过程中，如果遇到了`key`过期的`Entry`数据，实际上是会进行一轮**探测式清理**操作的，具体操作方式后面会讲到。 + +### `ThreadLocalMap.set()`详解 + +#### `ThreadLocalMap.set()`原理图解 + +看完了`ThreadLocal` **hash 算法**后，我们再来看`set`是如何实现的。 + +往`ThreadLocalMap`中`set`数据（**新增**或者**更新**数据）分为好几种情况，针对不同的情况我们画图来说明。 + +**第一种情况：** 通过`hash`计算后的槽位对应的`Entry`数据为空： + +![](./images/thread-local/9.png) + +这里直接将数据放到该槽位即可。 + +**第二种情况：** 槽位数据不为空，`key`值与当前`ThreadLocal`通过`hash`计算获取的`key`值一致： + +![](./images/thread-local/10.png) + +这里直接更新该槽位的数据。 + +**第三种情况：** 槽位数据不为空，往后遍历过程中，在找到`Entry`为`null`的槽位之前，没有遇到`key`过期的`Entry`： + +![](./images/thread-local/11.png) + +遍历散列数组，线性往后查找，如果找到`Entry`为`null`的槽位，则将数据放入该槽位中，或者往后遍历过程中，遇到了**key 值相等**的数据，直接更新即可。 + +**第四种情况：** 槽位数据不为空，往后遍历过程中，在找到`Entry`为`null`的槽位之前，遇到`key`过期的`Entry`，如下图，往后遍历过程中，遇到了`index=7`的槽位数据`Entry`的`key=null`： + +![](./images/thread-local/12.png) + +散列数组下标为 7 位置对应的`Entry`数据`key`为`null`，表明此数据`key`值已经被垃圾回收掉了，此时就会执行`replaceStaleEntry()`方法，该方法含义是**替换过期数据的逻辑**，以**index=7**位起点开始遍历，进行探测式数据清理工作。 + +初始化探测式清理过期数据扫描的开始位置：`slotToExpunge = staleSlot = 7` + +以当前`staleSlot`开始 向前迭代查找，找其他过期的数据，然后更新过期数据起始扫描下标`slotToExpunge`。`for`循环迭代，直到碰到`Entry`为`null`结束。 + +如果找到了过期的数据，继续向前迭代，直到遇到`Entry=null`的槽位才停止迭代，如下图所示，**slotToExpunge 被更新为 0**： + +![](./images/thread-local/13.png) + +以当前节点(`index=7`)向前迭代，检测是否有过期的`Entry`数据，如果有则更新`slotToExpunge`值。碰到`null`则结束探测。以上图为例`slotToExpunge`被更新为 0。 + +上面向前迭代的操作是为了更新探测清理过期数据的起始下标`slotToExpunge`的值，这个值在后面会讲解，它是用来判断当前过期槽位`staleSlot`之前是否还有过期元素。 + +接着开始以`staleSlot`位置(`index=7`)向后迭代，**如果找到了相同 key 值的 Entry 数据：** + +![](./images/thread-local/14.png) + +从当前节点`staleSlot`向后查找`key`值相等的`Entry`元素，找到后更新`Entry`的值并交换`staleSlot`元素的位置(`staleSlot`位置为过期元素)，更新`Entry`数据，然后开始进行过期`Entry`的清理工作，如下图所示： + +![](https://guide-blog-images.oss-cn-shenzhen.aliyuncs.com/java-guide-blog/view.png)向后遍历过程中，如果没有找到相同 key 值的 Entry 数据： + +![](./images/thread-local/15.png) + +从当前节点`staleSlot`向后查找`key`值相等的`Entry`元素，直到`Entry`为`null`则停止寻找。通过上图可知，此时`table`中没有`key`值相同的`Entry`。 + +创建新的`Entry`，替换`table[stableSlot]`位置： + +![](./images/thread-local/16.png) + +替换完成后也是进行过期元素清理工作，清理工作主要是有两个方法：`expungeStaleEntry()`和`cleanSomeSlots()`，具体细节后面会讲到，请继续往后看。 + +#### `ThreadLocalMap.set()`源码详解 + +上面已经用图的方式解析了`set()`实现的原理，其实已经很清晰了，我们接着再看下源码： + +`java.lang.ThreadLocal`.`ThreadLocalMap.set()`: + +```java +private void set(ThreadLocal key, Object value) { + Entry[] tab = table; + int len = tab.length; + int i = key.threadLocalHashCode & (len-1); + + for (Entry e = tab[i]; + e != null; + e = tab[i = nextIndex(i, len)]) { + ThreadLocal k = e.get(); + + if (k == key) { + e.value = value; + return; + } + + if (k == null) { + replaceStaleEntry(key, value, i); + return; + } + } + + tab[i] = new Entry(key, value); + int sz = ++size; + if (!cleanSomeSlots(i, sz) && sz >= threshold) + rehash(); +} +``` + +这里会通过`key`来计算在散列表中的对应位置，然后以当前`key`对应的桶的位置向后查找，找到可以使用的桶。 + +```java +Entry[] tab = table; +int len = tab.length; +int i = key.threadLocalHashCode & (len-1); +``` + +什么情况下桶才是可以使用的呢？ + +1. `k = key` 说明是替换操作，可以使用 +2. 碰到一个过期的桶，执行替换逻辑，占用过期桶 +3. 查找过程中，碰到桶中`Entry=null`的情况，直接使用 + +接着就是执行`for`循环遍历，向后查找，我们先看下`nextIndex()`、`prevIndex()`方法实现： + +![](./images/thread-local/17.png) + +```java +private static int nextIndex(int i, int len) { + return ((i + 1 < len) ? i + 1 : 0); +} + +private static int prevIndex(int i, int len) { + return ((i - 1 >= 0) ? i - 1 : len - 1); +} +``` + +接着看剩下`for`循环中的逻辑： + +1. 遍历当前`key`值对应的桶中`Entry`数据为空，这说明散列数组这里没有数据冲突，跳出`for`循环，直接`set`数据到对应的桶中 +2. 如果`key`值对应的桶中`Entry`数据不为空 + 2.1 如果`k = key`，说明当前`set`操作是一个替换操作，做替换逻辑，直接返回 + 2.2 如果`key = null`，说明当前桶位置的`Entry`是过期数据，执行`replaceStaleEntry()`方法(核心方法)，然后返回 +3. `for`循环执行完毕，继续往下执行说明向后迭代的过程中遇到了`entry`为`null`的情况 + 3.1 在`Entry`为`null`的桶中创建一个新的`Entry`对象 + 3.2 执行`++size`操作 +4. 调用`cleanSomeSlots()`做一次启发式清理工作，清理散列数组中`Entry`的`key`过期的数据 + 4.1 如果清理工作完成后，未清理到任何数据，且`size`超过了阈值(数组长度的 2/3)，进行`rehash()`操作 + 4.2 `rehash()`中会先进行一轮探测式清理，清理过期`key`，清理完成后如果**size >= threshold - threshold / 4**，就会执行真正的扩容逻辑(扩容逻辑往后看) + +接着重点看下`replaceStaleEntry()`方法，`replaceStaleEntry()`方法提供替换过期数据的功能，我们可以对应上面**第四种情况**的原理图来再回顾下，具体代码如下： + +`java.lang.ThreadLocal.ThreadLocalMap.replaceStaleEntry()`: + +```java +private void replaceStaleEntry(ThreadLocal key, Object value, + int staleSlot) { + Entry[] tab = table; + int len = tab.length; + Entry e; + + int slotToExpunge = staleSlot; + for (int i = prevIndex(staleSlot, len); + (e = tab[i]) != null; + i = prevIndex(i, len)) + + if (e.get() == null) + slotToExpunge = i; + + for (int i = nextIndex(staleSlot, len); + (e = tab[i]) != null; + i = nextIndex(i, len)) { + + ThreadLocal k = e.get(); + + if (k == key) { + e.value = value; + + tab[i] = tab[staleSlot]; + tab[staleSlot] = e; + + if (slotToExpunge == staleSlot) + slotToExpunge = i; + cleanSomeSlots(expungeStaleEntry(slotToExpunge), len); + return; + } + + if (k == null && slotToExpunge == staleSlot) + slotToExpunge = i; + } + + tab[staleSlot].value = null; + tab[staleSlot] = new Entry(key, value); + + if (slotToExpunge != staleSlot) + cleanSomeSlots(expungeStaleEntry(slotToExpunge), len); +} +``` + +`slotToExpunge`表示开始探测式清理过期数据的开始下标，默认从当前的`staleSlot`开始。以当前的`staleSlot`开始，向前迭代查找，找到没有过期的数据，`for`循环一直碰到`Entry`为`null`才会结束。如果向前找到了过期数据，更新探测清理过期数据的开始下标为 i，即`slotToExpunge=i` + +```java +for (int i = prevIndex(staleSlot, len); + (e = tab[i]) != null; + i = prevIndex(i, len)){ + + if (e.get() == null){ + slotToExpunge = i; + } +} +``` + +接着开始从`staleSlot`向后查找，也是碰到`Entry`为`null`的桶结束。 +如果迭代过程中，**碰到 k == key**，这说明这里是替换逻辑，替换新数据并且交换当前`staleSlot`位置。如果`slotToExpunge == staleSlot`，这说明`replaceStaleEntry()`一开始向前查找过期数据时并未找到过期的`Entry`数据，接着向后查找过程中也未发现过期数据，修改开始探测式清理过期数据的下标为当前循环的 index，即`slotToExpunge = i`。最后调用`cleanSomeSlots(expungeStaleEntry(slotToExpunge), len);`进行启发式过期数据清理。 + +```java +if (k == key) { + e.value = value; + + tab[i] = tab[staleSlot]; + tab[staleSlot] = e; + + if (slotToExpunge == staleSlot) + slotToExpunge = i; + + cleanSomeSlots(expungeStaleEntry(slotToExpunge), len); + return; +} +``` + +`cleanSomeSlots()`和`expungeStaleEntry()`方法后面都会细讲，这两个是和清理相关的方法，一个是过期`key`相关`Entry`的启发式清理(`Heuristically scan`)，另一个是过期`key`相关`Entry`的探测式清理。 + +**如果 k != key**则会接着往下走，`k == null`说明当前遍历的`Entry`是一个过期数据，`slotToExpunge == staleSlot`说明，一开始的向前查找数据并未找到过期的`Entry`。如果条件成立，则更新`slotToExpunge` 为当前位置，这个前提是前驱节点扫描时未发现过期数据。 + +```java +if (k == null && slotToExpunge == staleSlot) + slotToExpunge = i; +``` + +往后迭代的过程中如果没有找到`k == key`的数据，且碰到`Entry`为`null`的数据，则结束当前的迭代操作。此时说明这里是一个添加的逻辑，将新的数据添加到`table[staleSlot]` 对应的`slot`中。 + +```java +tab[staleSlot].value = null; +tab[staleSlot] = new Entry(key, value); +``` + +最后判断除了`staleSlot`以外，还发现了其他过期的`slot`数据，就要开启清理数据的逻辑： + +```java +if (slotToExpunge != staleSlot) + cleanSomeSlots(expungeStaleEntry(slotToExpunge), len); +``` + +### `ThreadLocalMap`过期 key 的探测式清理流程 + +上面我们有提及`ThreadLocalMap`的两种过期`key`数据清理方式：**探测式清理**和**启发式清理**。 + +我们先讲下探测式清理，也就是`expungeStaleEntry`方法，遍历散列数组，从开始位置向后探测清理过期数据，将过期数据的`Entry`设置为`null`，沿途中碰到未过期的数据则将此数据`rehash`后重新在`table`数组中定位，如果定位的位置已经有了数据，则会将未过期的数据放到最靠近此位置的`Entry=null`的桶中，使`rehash`后的`Entry`数据距离正确的桶的位置更近一些。操作逻辑如下： + +![](./images/thread-local/18.png) + +如上图，`set(27)` 经过 hash 计算后应该落到`index=4`的桶中，由于`index=4`桶已经有了数据，所以往后迭代最终数据放入到`index=7`的桶中，放入后一段时间后`index=5`中的`Entry`数据`key`变为了`null` + +![](./images/thread-local/19.png) + +如果再有其他数据`set`到`map`中，就会触发**探测式清理**操作。 + +如上图，执行**探测式清理**后，`index=5`的数据被清理掉，继续往后迭代，到`index=7`的元素时，经过`rehash`后发现该元素正确的`index=4`，而此位置已经有了数据，往后查找离`index=4`最近的`Entry=null`的节点(刚被探测式清理掉的数据：`index=5`)，找到后移动`index= 7`的数据到`index=5`中，此时桶的位置离正确的位置`index=4`更近了。 + +经过一轮探测式清理后，`key`过期的数据会被清理掉，没过期的数据经过`rehash`重定位后所处的桶位置理论上更接近`i= key.hashCode & (tab.len - 1)`的位置。这种优化会提高整个散列表查询性能。 + +接着看下`expungeStaleEntry()`具体流程，我们还是以先原理图后源码讲解的方式来一步步梳理： + +![](./images/thread-local/20.png) + +我们假设`expungeStaleEntry(3)` 来调用此方法，如上图所示，我们可以看到`ThreadLocalMap`中`table`的数据情况，接着执行清理操作： + +![](./images/thread-local/21.png) + +第一步是清空当前`staleSlot`位置的数据，`index=3`位置的`Entry`变成了`null`。然后接着往后探测： + +![](./images/thread-local/22.png) + +执行完第二步后，index=4 的元素挪到 index=3 的槽位中。 + +继续往后迭代检查，碰到正常数据，计算该数据位置是否偏移，如果被偏移，则重新计算`slot`位置，目的是让正常数据尽可能存放在正确位置或离正确位置更近的位置 + +![](./images/thread-local/23.png) + +在往后迭代的过程中碰到空的槽位，终止探测，这样一轮探测式清理工作就完成了，接着我们继续看看具体**实现源代码**： + +```java +private int expungeStaleEntry(int staleSlot) { + Entry[] tab = table; + int len = tab.length; + + tab[staleSlot].value = null; + tab[staleSlot] = null; + size--; + + Entry e; + int i; + for (i = nextIndex(staleSlot, len); + (e = tab[i]) != null; + i = nextIndex(i, len)) { + ThreadLocal k = e.get(); + if (k == null) { + e.value = null; + tab[i] = null; + size--; + } else { + int h = k.threadLocalHashCode & (len - 1); + if (h != i) { + tab[i] = null; + + while (tab[h] != null) + h = nextIndex(h, len); + tab[h] = e; + } + } + } + return i; +} +``` + +这里我们还是以`staleSlot=3` 来做示例说明，首先是将`tab[staleSlot]`槽位的数据清空，然后设置`size--` +接着以`staleSlot`位置往后迭代，如果遇到`k==null`的过期数据，也是清空该槽位数据，然后`size--` + +```java +ThreadLocal k = e.get(); + +if (k == null) { + e.value = null; + tab[i] = null; + size--; +} +``` + +如果`key`没有过期，重新计算当前`key`的下标位置是不是当前槽位下标位置，如果不是，那么说明产生了`hash`冲突，此时以新计算出来正确的槽位位置往后迭代，找到最近一个可以存放`entry`的位置。 + +```java +int h = k.threadLocalHashCode & (len - 1); +if (h != i) { + tab[i] = null; + + while (tab[h] != null) + h = nextIndex(h, len); + + tab[h] = e; +} +``` + +这里是处理正常的产生`Hash`冲突的数据，经过迭代后，有过`Hash`冲突数据的`Entry`位置会更靠近正确位置，这样的话，查询的时候 效率才会更高。 + +### `ThreadLocalMap`扩容机制 + +在`ThreadLocalMap.set()`方法的最后，如果执行完启发式清理工作后，未清理到任何数据，且当前散列数组中`Entry`的数量已经达到了列表的扩容阈值`(len*2/3)`，就开始执行`rehash()`逻辑： + +```java +if (!cleanSomeSlots(i, sz) && sz >= threshold) + rehash(); +``` + +接着看下`rehash()`具体实现： + +```java +private void rehash() { + expungeStaleEntries(); + + if (size >= threshold - threshold / 4) + resize(); +} + +private void expungeStaleEntries() { + Entry[] tab = table; + int len = tab.length; + for (int j = 0; j < len; j++) { + Entry e = tab[j]; + if (e != null && e.get() == null) + expungeStaleEntry(j); + } +} +``` + +这里首先是会进行探测式清理工作，从`table`的起始位置往后清理，上面有分析清理的详细流程。清理完成之后，`table`中可能有一些`key`为`null`的`Entry`数据被清理掉，所以此时通过判断`size >= threshold - threshold / 4` 也就是`size >= threshold * 3/4` 来决定是否扩容。 + +我们还记得上面进行`rehash()`的阈值是`size >= threshold`，所以当面试官套路我们`ThreadLocalMap`扩容机制的时候 我们一定要说清楚这两个步骤： + +![](./images/thread-local/24.png) + +接着看看具体的`resize()`方法，为了方便演示，我们以`oldTab.len=8`来举例： + +![](./images/thread-local/25.png) + +扩容后的`tab`的大小为`oldLen * 2`，然后遍历老的散列表，重新计算`hash`位置，然后放到新的`tab`数组中，如果出现`hash`冲突则往后寻找最近的`entry`为`null`的槽位，遍历完成之后，`oldTab`中所有的`entry`数据都已经放入到新的`tab`中了。重新计算`tab`下次扩容的**阈值**，具体代码如下： + +```java +private void resize() { + Entry[] oldTab = table; + int oldLen = oldTab.length; + int newLen = oldLen * 2; + Entry[] newTab = new Entry[newLen]; + int count = 0; + + for (int j = 0; j < oldLen; ++j) { + Entry e = oldTab[j]; + if (e != null) { + ThreadLocal k = e.get(); + if (k == null) { + e.value = null; + } else { + int h = k.threadLocalHashCode & (newLen - 1); + while (newTab[h] != null) + h = nextIndex(h, newLen); + newTab[h] = e; + count++; + } + } + } + + setThreshold(newLen); + size = count; + table = newTab; +} +``` + +### `ThreadLocalMap.get()`详解 + +上面已经看完了`set()`方法的源码，其中包括`set`数据、清理数据、优化数据桶的位置等操作，接着看看`get()`操作的原理。 + +#### `ThreadLocalMap.get()`图解 + +**第一种情况：** 通过查找`key`值计算出散列表中`slot`位置，然后该`slot`位置中的`Entry.key`和查找的`key`一致，则直接返回： + +![](./images/thread-local/26.png) + +**第二种情况：** `slot`位置中的`Entry.key`和要查找的`key`不一致： + +![](./images/thread-local/27.png) + +我们以`get(ThreadLocal1)`为例，通过`hash`计算后，正确的`slot`位置应该是 4，而`index=4`的槽位已经有了数据，且`key`值不等于`ThreadLocal1`，所以需要继续往后迭代查找。 + +迭代到`index=5`的数据时，此时`Entry.key=null`，触发一次探测式数据回收操作，执行`expungeStaleEntry()`方法，执行完后，`index 5,8`的数据都会被回收，而`index 6,7`的数据都会前移，此时继续往后迭代，到`index = 6`的时候即找到了`key`值相等的`Entry`数据，如下图所示： + +![](./images/thread-local/28.png) + +#### `ThreadLocalMap.get()`源码详解 + +`java.lang.ThreadLocal.ThreadLocalMap.getEntry()`: + +```java +private Entry getEntry(ThreadLocal key) { + int i = key.threadLocalHashCode & (table.length - 1); + Entry e = table[i]; + if (e != null && e.get() == key) + return e; + else + return getEntryAfterMiss(key, i, e); +} + +private Entry getEntryAfterMiss(ThreadLocal key, int i, Entry e) { + Entry[] tab = table; + int len = tab.length; + + while (e != null) { + ThreadLocal k = e.get(); + if (k == key) + return e; + if (k == null) + expungeStaleEntry(i); + else + i = nextIndex(i, len); + e = tab[i]; + } + return null; +} +``` + +### `ThreadLocalMap`过期 key 的启发式清理流程 + +上面多次提及到`ThreadLocalMap`过期key的两种清理方式：**探测式清理(expungeStaleEntry())**、**启发式清理(cleanSomeSlots())** + +探测式清理是以当前`Entry` 往后清理，遇到值为`null`则结束清理，属于**线性探测清理**。 + +而启发式清理被作者定义为：**Heuristically scan some cells looking for stale entries**. + +![](./images/thread-local/29.png) + +具体代码如下： + +```java +private boolean cleanSomeSlots(int i, int n) { + boolean removed = false; + Entry[] tab = table; + int len = tab.length; + do { + i = nextIndex(i, len); + Entry e = tab[i]; + if (e != null && e.get() == null) { + n = len; + removed = true; + i = expungeStaleEntry(i); + } + } while ( (n >>>= 1) != 0); + return removed; +} +``` + +### `InheritableThreadLocal` + +我们使用`ThreadLocal`的时候，在异步场景下是无法给子线程共享父线程中创建的线程副本数据的。 + +为了解决这个问题，JDK 中还有一个`InheritableThreadLocal`类，我们来看一个例子： + +```java +public class InheritableThreadLocalDemo { + public static void main(String[] args) { + ThreadLocal ThreadLocal = new ThreadLocal<>(); + ThreadLocal inheritableThreadLocal = new InheritableThreadLocal<>(); + ThreadLocal.set("父类数据:threadLocal"); + inheritableThreadLocal.set("父类数据:inheritableThreadLocal"); + + new Thread(new Runnable() { + @Override + public void run() { + System.out.println("子线程获取父类ThreadLocal数据：" + ThreadLocal.get()); + System.out.println("子线程获取父类inheritableThreadLocal数据：" + inheritableThreadLocal.get()); + } + }).start(); + } +} +``` + +打印结果： + +```java +子线程获取父类ThreadLocal数据：null +子线程获取父类inheritableThreadLocal数据：父类数据:inheritableThreadLocal +``` + +实现原理是子线程是通过在父线程中通过调用`new Thread()`方法来创建子线程，`Thread#init`方法在`Thread`的构造方法中被调用。在`init`方法中拷贝父线程数据到子线程中： + +```java +private void init(ThreadGroup g, Runnable target, String name, + long stackSize, AccessControlContext acc, + boolean inheritThreadLocals) { + if (name == null) { + throw new NullPointerException("name cannot be null"); + } + + if (inheritThreadLocals && parent.inheritableThreadLocals != null) + this.inheritableThreadLocals = + ThreadLocal.createInheritedMap(parent.inheritableThreadLocals); + this.stackSize = stackSize; + tid = nextThreadID(); +} +``` + +但`InheritableThreadLocal`仍然有缺陷，一般我们做异步化处理都是使用的线程池，而`InheritableThreadLocal`是在`new Thread`中的`init()`方法给赋值的，而线程池是线程复用的逻辑，所以这里会存在问题。 + +当然，有问题出现就会有解决问题的方案，阿里巴巴开源了一个`TransmittableThreadLocal`组件就可以解决这个问题，这里就不再延伸，感兴趣的可自行查阅资料。 + +### `ThreadLocal`项目中使用实战 + +#### `ThreadLocal`使用场景 + +我们现在项目中日志记录用的是`ELK+Logstash`，最后在`Kibana`中进行展示和检索。 + +现在都是分布式系统统一对外提供服务，项目间调用的关系可以通过 `traceId` 来关联，但是不同项目之间如何传递 `traceId` 呢？ + +这里我们使用 `org.slf4j.MDC` 来实现此功能，内部就是通过 `ThreadLocal` 来实现的，具体实现如下： + +当前端发送请求到**服务 A**时，**服务 A**会生成一个类似`UUID`的`traceId`字符串，将此字符串放入当前线程的`ThreadLocal`中，在调用**服务 B**的时候，将`traceId`写入到请求的`Header`中，**服务 B**在接收请求时会先判断请求的`Header`中是否有`traceId`，如果存在则写入自己线程的`ThreadLocal`中。 + +![](./images/thread-local/30.png) + +图中的`requestId`即为我们各个系统链路关联的`traceId`，系统间互相调用，通过这个`requestId`即可找到对应链路，这里还有会有一些其他场景： + +![](./images/thread-local/31.png) + +针对于这些场景，我们都可以有相应的解决方案，如下所示 + +#### Feign 远程调用解决方案 + +**服务发送请求：** + +```java +@Component +@Slf4j +public class FeignInvokeInterceptor implements RequestInterceptor { + + @Override + public void apply(RequestTemplate template) { + String requestId = MDC.get("requestId"); + if (StringUtils.isNotBlank(requestId)) { + template.header("requestId", requestId); + } + } +} +``` + +**服务接收请求：** + +```java +@Slf4j +@Component +public class LogInterceptor extends HandlerInterceptorAdapter { + + @Override + public void afterCompletion(HttpServletRequest arg0, HttpServletResponse arg1, Object arg2, Exception arg3) { + MDC.remove("requestId"); + } + + @Override + public void postHandle(HttpServletRequest arg0, HttpServletResponse arg1, Object arg2, ModelAndView arg3) { + } + + @Override + public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { + + String requestId = request.getHeader(BaseConstant.REQUEST_ID_KEY); + if (StringUtils.isBlank(requestId)) { + requestId = UUID.randomUUID().toString().replace("-", ""); + } + MDC.put("requestId", requestId); + return true; + } +} +``` + +#### 线程池异步调用，requestId 传递 + +因为`MDC`是基于`ThreadLocal`去实现的，异步过程中，子线程并没有办法获取到父线程`ThreadLocal`存储的数据，所以这里可以自定义线程池执行器，修改其中的`run()`方法： + +```java +public class MyThreadPoolTaskExecutor extends ThreadPoolTaskExecutor { + + @Override + public void execute(Runnable runnable) { + Map context = MDC.getCopyOfContextMap(); + super.execute(() -> run(runnable, context)); + } + + @Override + private void run(Runnable runnable, Map context) { + if (context != null) { + MDC.setContextMap(context); + } + try { + runnable.run(); + } finally { + MDC.remove(); + } + } +} +``` + +#### 使用 MQ 发送消息给第三方系统 + +在 MQ 发送的消息体中自定义属性`requestId`，接收方消费消息后，自己解析`requestId`使用即可。 diff --git a/docs/java/jvm/class-file-structure.md b/docs/java/jvm/class-file-structure.md new file mode 100644 index 0000000000000000000000000000000000000000..edbfdf5349ef6032d123cf4372cb27b3be11d67a --- /dev/null +++ b/docs/java/jvm/class-file-structure.md @@ -0,0 +1,211 @@ +--- +category: Java +tag: + - JVM +--- + +# 类文件结构详解 + +## 一 概述 + +在 Java 中，JVM 可以理解的代码就叫做`字节码`（即扩展名为 `.class` 的文件），它不面向任何特定的处理器，只面向虚拟机。Java 语言通过字节码的方式，在一定程度上解决了传统解释型语言执行效率低的问题，同时又保留了解释型语言可移植的特点。所以 Java 程序运行时比较高效，而且，由于字节码并不针对一种特定的机器，因此，Java 程序无须重新编译便可在多种不同操作系统的计算机上运行。 + +Clojure（Lisp 语言的一种方言）、Groovy、Scala 等语言都是运行在 Java 虚拟机之上。下图展示了不同的语言被不同的编译器编译成`.class`文件最终运行在 Java 虚拟机之上。`.class`文件的二进制格式可以使用 [WinHex](https://www.x-ways.net/winhex/) 查看。 + +![java虚拟机](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/bg/desktop类文件结构概览.png) + +可以说`.class`文件是不同的语言在 Java 虚拟机之间的重要桥梁，同时也是支持 Java 跨平台很重要的一个原因。 + +## 二 Class 文件结构总结 + +根据 Java 虚拟机规范，Class 文件通过 `ClassFile` 定义，有点类似 C 语言的结构体。 + +`ClassFile` 的结构如下： + +```java +ClassFile { + u4 magic; //Class 文件的标志 + u2 minor_version;//Class 的小版本号 + u2 major_version;//Class 的大版本号 + u2 constant_pool_count;//常量池的数量 + cp_info constant_pool[constant_pool_count-1];//常量池 + u2 access_flags;//Class 的访问标记 + u2 this_class;//当前类 + u2 super_class;//父类 + u2 interfaces_count;//接口 + u2 interfaces[interfaces_count];//一个类可以实现多个接口 + u2 fields_count;//Class 文件的字段属性 + field_info fields[fields_count];//一个类可以有多个字段 + u2 methods_count;//Class 文件的方法数量 + method_info methods[methods_count];//一个类可以有个多个方法 + u2 attributes_count;//此类的属性表中的属性数 + attribute_info attributes[attributes_count];//属性表集合 +} +``` + +通过分析 `ClassFile` 的内容，我们便可以知道 class 文件的组成。 + +![](https://guide-blog-images.oss-cn-shenzhen.aliyuncs.com/java-guide-blog/16d5ec47609818fc.jpeg) + +下面这张图是通过 IDEA 插件 `jclasslib` 查看的，你可以更直观看到 Class 文件结构。 + +![](https://guide-blog-images.oss-cn-shenzhen.aliyuncs.com/java-guide-blog/image-20210401170711475.png) + +使用 `jclasslib` 不光可以直观地查看某个类对应的字节码文件，还可以查看类的基本信息、常量池、接口、属性、函数等信息。 + +下面详细介绍一下 Class 文件结构涉及到的一些组件。 + +### 2.1 魔数（Magic Number） + +```java + u4 magic; //Class 文件的标志 +``` + +每个 Class 文件的头 4 个字节称为魔数（Magic Number）,它的唯一作用是**确定这个文件是否为一个能被虚拟机接收的 Class 文件**。 + +程序设计者很多时候都喜欢用一些特殊的数字表示固定的文件类型或者其它特殊的含义。 + +### 2.2 Class 文件版本号（Minor&Major Version） + +```java + u2 minor_version;//Class 的小版本号 + u2 major_version;//Class 的大版本号 +``` + +紧接着魔数的四个字节存储的是 Class 文件的版本号：第 5 和第 6 位是**次版本号**，第 7 和第 8 位是**主版本号**。 + +每当 Java 发布大版本（比如 Java 8，Java9）的时候，主版本号都会加 1。你可以使用 `javap -v` 命令来快速查看 Class 文件的版本号信息。 + +高版本的 Java 虚拟机可以执行低版本编译器生成的 Class 文件，但是低版本的 Java 虚拟机不能执行高版本编译器生成的 Class 文件。所以，我们在实际开发的时候要确保开发的的 JDK 版本和生产环境的 JDK 版本保持一致。 + +### 2.3 常量池（Constant Pool） + +```java + u2 constant_pool_count;//常量池的数量 + cp_info constant_pool[constant_pool_count-1];//常量池 +``` + +紧接着主次版本号之后的是常量池，常量池的数量是 `constant_pool_count-1`（**常量池计数器是从 1 开始计数的，将第 0 项常量空出来是有特殊考虑的，索引值为 0 代表“不引用任何一个常量池项”**）。 + +常量池主要存放两大常量：字面量和符号引用。字面量比较接近于 Java 语言层面的的常量概念，如文本字符串、声明为 final 的常量值等。而符号引用则属于编译原理方面的概念。包括下面三类常量： + +- 类和接口的全限定名 +- 字段的名称和描述符 +- 方法的名称和描述符 + +常量池中每一项常量都是一个表，这 14 种表有一个共同的特点：**开始的第一位是一个 u1 类型的标志位 -tag 来标识常量的类型，代表当前这个常量属于哪种常量类型．** + +| 类型 | 标志（tag） | 描述 | +| :------------------------------: | :---------: | :--------------------: | +| CONSTANT_utf8_info | 1 | UTF-8 编码的字符串 | +| CONSTANT_Integer_info | 3 | 整形字面量 | +| CONSTANT_Float_info | 4 | 浮点型字面量 | +| CONSTANT_Long_info | ５ | 长整型字面量 | +| CONSTANT_Double_info | ６ | 双精度浮点型字面量 | +| CONSTANT_Class_info | ７ | 类或接口的符号引用 | +| CONSTANT_String_info | ８ | 字符串类型字面量 | +| CONSTANT_Fieldref_info | ９ | 字段的符号引用 | +| CONSTANT_Methodref_info | 10 | 类中方法的符号引用 | +| CONSTANT_InterfaceMethodref_info | 11 | 接口中方法的符号引用 | +| CONSTANT_NameAndType_info | 12 | 字段或方法的符号引用 | +| CONSTANT_MothodType_info | 16 | 标志方法类型 | +| CONSTANT_MethodHandle_info | 15 | 表示方法句柄 | +| CONSTANT_InvokeDynamic_info | 18 | 表示一个动态方法调用点 | + +`.class` 文件可以通过`javap -v class类名` 指令来看一下其常量池中的信息(`javap -v class类名-> temp.txt` ：将结果输出到 temp.txt 文件)。 + +### 2.4 访问标志(Access Flags) + +在常量池结束之后，紧接着的两个字节代表访问标志，这个标志用于识别一些类或者接口层次的访问信息，包括：这个 Class 是类还是接口，是否为 `public` 或者 `abstract` 类型，如果是类的话是否声明为 `final` 等等。 + +类访问和属性修饰符: + +![类访问和属性修饰符](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/2019-6/访问标志.png) + +我们定义了一个 Employee 类 + +```java +package top.snailclimb.bean; +public class Employee { + ... +} +``` + +通过`javap -v class类名` 指令来看一下类的访问标志。 + +![查看类的访问标志](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/2019-6/查看类的访问标志.png) + +### 2.5 当前类（This Class）、父类（Super Class）、接口（Interfaces）索引集合 + +```java + u2 this_class;//当前类 + u2 super_class;//父类 + u2 interfaces_count;//接口 + u2 interfaces[interfaces_count];//一个类可以实现多个接口 +``` + +类索引用于确定这个类的全限定名，父类索引用于确定这个类的父类的全限定名，由于 Java 语言的单继承，所以父类索引只有一个，除了 `java.lang.Object` 之外，所有的 java 类都有父类，因此除了 `java.lang.Object` 外，所有 Java 类的父类索引都不为 0。 + +接口索引集合用来描述这个类实现了那些接口，这些被实现的接口将按 `implements` (如果这个类本身是接口的话则是`extends`) 后的接口顺序从左到右排列在接口索引集合中。 + +### 2.6 字段表集合（Fields） + +```java + u2 fields_count;//Class 文件的字段的个数 + field_info fields[fields_count];//一个类会可以有个字段 +``` + +字段表（field info）用于描述接口或类中声明的变量。字段包括类级变量以及实例变量，但不包括在方法内部声明的局部变量。 + +**field info(字段表) 的结构:** + +![字段表的结构 ](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/2019-6/字段表的结构.png) + +- **access_flags:** 字段的作用域（`public` ,`private`,`protected`修饰符），是实例变量还是类变量（`static`修饰符）,可否被序列化（transient 修饰符）,可变性（final）,可见性（volatile 修饰符，是否强制从主内存读写）。 +- **name_index:** 对常量池的引用，表示的字段的名称； +- **descriptor_index:** 对常量池的引用，表示字段和方法的描述符； +- **attributes_count:** 一个字段还会拥有一些额外的属性，attributes_count 存放属性的个数； +- **attributes[attributes_count]:** 存放具体属性具体内容。 + +上述这些信息中，各个修饰符都是布尔值，要么有某个修饰符，要么没有，很适合使用标志位来表示。而字段叫什么名字、字段被定义为什么数据类型这些都是无法固定的，只能引用常量池中常量来描述。 + +**字段的 access_flag 的取值:** + +![字段的 access_flag 的取值](https://guide-blog-images.oss-cn-shenzhen.aliyuncs.com/JVM/image-20201031084342859.png) + +### 2.7 方法表集合（Methods） + +```java + u2 methods_count;//Class 文件的方法的数量 + method_info methods[methods_count];//一个类可以有个多个方法 +``` + +methods_count 表示方法的数量，而 method_info 表示方法表。 + +Class 文件存储格式中对方法的描述与对字段的描述几乎采用了完全一致的方式。方法表的结构如同字段表一样，依次包括了访问标志、名称索引、描述符索引、属性表集合几项。 + +**method_info(方法表的) 结构:** + +![方法表的结构](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/2019-6/方法表的结构.png) + +**方法表的 access_flag 取值：** + +![方法表的 access_flag 取值](https://guide-blog-images.oss-cn-shenzhen.aliyuncs.com/JVM/image-20201031084248965.png) + +注意：因为`volatile`修饰符和`transient`修饰符不可以修饰方法，所以方法表的访问标志中没有这两个对应的标志，但是增加了`synchronized`、`native`、`abstract`等关键字修饰方法，所以也就多了这些关键字对应的标志。 + +### 2.8 属性表集合（Attributes） + +```java + u2 attributes_count;//此类的属性表中的属性数 + attribute_info attributes[attributes_count];//属性表集合 +``` + +在 Class 文件，字段表，方法表中都可以携带自己的属性表集合，以用于描述某些场景专有的信息。与 Class 文件中其它的数据项目要求的顺序、长度和内容不同，属性表集合的限制稍微宽松一些，不再要求各个属性表具有严格的顺序，并且只要不与已有的属性名重复，任何人实现的编译器都可以向属性表中写 入自己定义的属性信息，Java 虚拟机运行时会忽略掉它不认识的属性。 + +## 参考 + +- +- +- +- 《实战 Java 虚拟机》 diff --git a/docs/java/jvm/class-loading-process.md b/docs/java/jvm/class-loading-process.md new file mode 100644 index 0000000000000000000000000000000000000000..fbe1b161d68ea01138d211ee0207c5ae17fdb620 --- /dev/null +++ b/docs/java/jvm/class-loading-process.md @@ -0,0 +1,112 @@ +--- +category: Java +tag: + - JVM +--- + + +# 类加载过程详解 + +## 类的生命周期 + +一个类的完整生命周期如下： + +![](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/2019-11/类加载过程-完善.png) + +## 类加载过程 + +Class 文件需要加载到虚拟机中之后才能运行和使用，那么虚拟机是如何加载这些 Class 文件呢？ + +系统加载 Class 类型的文件主要三步：**加载->连接->初始化**。连接过程又可分为三步：**验证->准备->解析**。 + +![](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/2019-6/类加载过程.png) + +详见：[jvm规范5.4](https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-5.html#jvms-5.4) 。 + +![](https://img-blog.csdnimg.cn/20210607102244508.png) + +### 加载 + +类加载过程的第一步，主要完成下面 3 件事情： + +1. 通过全类名获取定义此类的二进制字节流 +2. 将字节流所代表的静态存储结构转换为方法区的运行时数据结构 +3. 在内存中生成一个代表该类的 `Class` 对象，作为方法区这些数据的访问入口 + +虚拟机规范上面这 3 点并不具体，因此是非常灵活的。比如："通过全类名获取定义此类的二进制字节流" 并没有指明具体从哪里获取、怎样获取。比如：比较常见的就是从 `ZIP` 包中读取（日后出现的 `JAR`、`EAR`、`WAR` 格式的基础）、其他文件生成（典型应用就是 `JSP`）等等。 + +**一个非数组类的加载阶段（加载阶段获取类的二进制字节流的动作）是可控性最强的阶段，这一步我们可以去完成还可以自定义类加载器去控制字节流的获取方式（重写一个类加载器的 `loadClass()` 方法）。数组类型不通过类加载器创建，它由 Java 虚拟机直接创建。** + +类加载器、双亲委派模型也是非常重要的知识点，这部分内容会在后面的文章中单独介绍到。 + +加载阶段和连接阶段的部分内容是交叉进行的，加载阶段尚未结束，连接阶段可能就已经开始了。 + +### 验证 + +![验证阶段示意图](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/2019-6/验证阶段.png) + +### 准备 + +**准备阶段是正式为类变量分配内存并设置类变量初始值的阶段**，这些内存都将在方法区中分配。对于该阶段有以下几点需要注意： + +1. 这时候进行内存分配的仅包括类变量（ Class Variables ，即静态变量，被 `static` 关键字修饰的变量，只与类相关，因此被称为类变量），而不包括实例变量。实例变量会在对象实例化时随着对象一块分配在 Java 堆中。 +2. 从概念上讲，类变量所使用的内存都应当在 **方法区** 中进行分配。不过有一点需要注意的是：JDK 7 之前，HotSpot 使用永久代来实现方法区的时候，实现是完全符合这种逻辑概念的。 而在 JDK 7 及之后，HotSpot 已经把原本放在永久代的字符串常量池、静态变量等移动到堆中，这个时候类变量则会随着 Class 对象一起存放在 Java 堆中。相关阅读：[《深入理解Java虚拟机（第3版）》勘误#75](https://github.com/fenixsoft/jvm_book/issues/75) +3. 这里所设置的初始值"通常情况"下是数据类型默认的零值（如 0、0L、null、false 等），比如我们定义了`public static int value=111` ，那么 value 变量在准备阶段的初始值就是 0 而不是 111（初始化阶段才会赋值）。特殊情况：比如给 value 变量加上了 final 关键字`public static final int value=111` ，那么准备阶段 value 的值就被赋值为 111。 + +**基本数据类型的零值** ： (图片来自《深入理解 Java 虚拟机》第 3 版 7.33 ) + + + +![基本数据类型的零值](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/2019-6/基本数据类型的零值.png) + +### 解析 + +解析阶段是虚拟机将常量池内的符号引用替换为直接引用的过程。解析动作主要针对类或接口、字段、类方法、接口方法、方法类型、方法句柄和调用限定符 7 类符号引用进行。 + +符号引用就是一组符号来描述目标，可以是任何字面量。**直接引用**就是直接指向目标的指针、相对偏移量或一个间接定位到目标的句柄。在程序实际运行时，只有符号引用是不够的，举个例子：在程序执行方法时，系统需要明确知道这个方法所在的位置。Java 虚拟机为每个类都准备了一张方法表来存放类中所有的方法。当需要调用一个类的方法的时候，只要知道这个方法在方法表中的偏移量就可以直接调用该方法了。通过解析操作符号引用就可以直接转变为目标方法在类中方法表的位置，从而使得方法可以被调用。 + +综上，解析阶段是虚拟机将常量池内的符号引用替换为直接引用的过程，也就是得到类或者字段、方法在内存中的指针或者偏移量。 + +### 初始化 + +初始化阶段是执行初始化方法 ` ()`方法的过程，是类加载的最后一步，这一步 JVM 才开始真正执行类中定义的 Java 程序代码(字节码)。 + +> 说明： ` ()`方法是编译之后自动生成的。 + +对于` ()` 方法的调用，虚拟机会自己确保其在多线程环境中的安全性。因为 ` ()` 方法是带锁线程安全，所以在多线程环境下进行类初始化的话可能会引起多个进程阻塞，并且这种阻塞很难被发现。 + +对于初始化阶段，虚拟机严格规范了有且只有 5 种情况下，必须对类进行初始化(只有主动去使用类才会初始化类)： + +1. 当遇到 `new` 、 `getstatic`、`putstatic` 或 `invokestatic` 这 4 条直接码指令时，比如 `new` 一个类，读取一个静态字段(未被 final 修饰)、或调用一个类的静态方法时。 + - 当 jvm 执行 `new` 指令时会初始化类。即当程序创建一个类的实例对象。 + - 当 jvm 执行 `getstatic` 指令时会初始化类。即程序访问类的静态变量(不是静态常量，常量会被加载到运行时常量池)。 + - 当 jvm 执行 `putstatic` 指令时会初始化类。即程序给类的静态变量赋值。 + - 当 jvm 执行 `invokestatic` 指令时会初始化类。即程序调用类的静态方法。 +2. 使用 `java.lang.reflect` 包的方法对类进行反射调用时如 `Class.forname("...")`, `newInstance()` 等等。如果类没初始化，需要触发其初始化。 +3. 初始化一个类，如果其父类还未初始化，则先触发该父类的初始化。 +4. 当虚拟机启动时，用户需要定义一个要执行的主类 (包含 `main` 方法的那个类)，虚拟机会先初始化这个类。 +5. `MethodHandle` 和 `VarHandle` 可以看作是轻量级的反射调用机制，而要想使用这 2 个调用， + 就必须先使用 `findStaticVarHandle` 来初始化要调用的类。 +6. **「补充，来自[issue745](https://github.com/Snailclimb/JavaGuide/issues/745)」** 当一个接口中定义了 JDK8 新加入的默认方法（被 default 关键字修饰的接口方法）时，如果有这个接口的实现类发生了初始化，那该接口要在其之前被初始化。 + +## 卸载 + +> 卸载这部分内容来自 [issue#662](https://github.com/Snailclimb/JavaGuide/issues/662)由 **[guang19](https://github.com/guang19)** 补充完善。 + +卸载类即该类的 Class 对象被 GC。 + +卸载类需要满足 3 个要求: + +1. 该类的所有的实例对象都已被 GC，也就是说堆不存在该类的实例对象。 +2. 该类没有在其他任何地方被引用 +3. 该类的类加载器的实例已被 GC + +所以，在 JVM 生命周期内，由 jvm 自带的类加载器加载的类是不会被卸载的。但是由我们自定义的类加载器加载的类是可能被卸载的。 + +只要想通一点就好了，jdk 自带的 `BootstrapClassLoader`, `ExtClassLoader`, `AppClassLoader` 负责加载 jdk 提供的类，所以它们(类加载器的实例)肯定不会被回收。而我们自定义的类加载器的实例是可以被回收的，所以使用我们自定义加载器加载的类是可以被卸载掉的。 + +**参考** + +- 《深入理解 Java 虚拟机》 +- 《实战 Java 虚拟机》 +- diff --git a/docs/java/jvm/classloader.md b/docs/java/jvm/classloader.md new file mode 100644 index 0000000000000000000000000000000000000000..93cd907e45ac8bf15f4fb2bbacd70923411ff2c8 --- /dev/null +++ b/docs/java/jvm/classloader.md @@ -0,0 +1,123 @@ +--- +category: Java +tag: + - JVM +--- + +# 类加载器详解 + +## 回顾一下类加载过程 + +类加载过程：**加载->连接->初始化**。连接过程又可分为三步：**验证->准备->解析**。 + +![类加载过程](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/2019-6/类加载过程.png) + +一个非数组类的加载阶段（加载阶段获取类的二进制字节流的动作）是可控性最强的阶段，这一步我们可以去自定义类加载器去控制字节流的获取方式（重写一个类加载器的 `loadClass()` 方法）。数组类型不通过类加载器创建，它由 Java 虚拟机直接创建。 + +所有的类都由类加载器加载，加载的作用就是将 `.class`文件加载到内存。 + +## 类加载器总结 + +JVM 中内置了三个重要的 ClassLoader，除了 BootstrapClassLoader 其他类加载器均由 Java 实现且全部继承自`java.lang.ClassLoader`： + +1. **BootstrapClassLoader(启动类加载器)** ：最顶层的加载类，由 C++实现，负责加载 `%JAVA_HOME%/lib`目录下的 jar 包和类或者被 `-Xbootclasspath`参数指定的路径中的所有类。 +2. **ExtensionClassLoader(扩展类加载器)** ：主要负责加载 `%JRE_HOME%/lib/ext` 目录下的 jar 包和类，或被 `java.ext.dirs` 系统变量所指定的路径下的 jar 包。 +3. **AppClassLoader(应用程序类加载器)** ：面向我们用户的加载器，负责加载当前应用 classpath 下的所有 jar 包和类。 + +## 双亲委派模型 + +### 双亲委派模型介绍 + +每一个类都有一个对应它的类加载器。系统中的 ClassLoader 在协同工作的时候会默认使用 **双亲委派模型** 。即在类加载的时候，系统会首先判断当前类是否被加载过。已经被加载的类会直接返回，否则才会尝试加载。加载的时候，首先会把该请求委派给父类加载器的 `loadClass()` 处理，因此所有的请求最终都应该传送到顶层的启动类加载器 `BootstrapClassLoader` 中。当父类加载器无法处理时，才由自己来处理。当父类加载器为 null 时，会使用启动类加载器 `BootstrapClassLoader` 作为父类加载器。 + +![ClassLoader](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/2019-6/classloader_WPS图片.png) + +每个类加载都有一个父类加载器，我们通过下面的程序来验证。 + +```java +public class ClassLoaderDemo { + public static void main(String[] args) { + System.out.println("ClassLodarDemo's ClassLoader is " + ClassLoaderDemo.class.getClassLoader()); + System.out.println("The Parent of ClassLodarDemo's ClassLoader is " + ClassLoaderDemo.class.getClassLoader().getParent()); + System.out.println("The GrandParent of ClassLodarDemo's ClassLoader is " + ClassLoaderDemo.class.getClassLoader().getParent().getParent()); + } +} +``` + +Output + +``` +ClassLodarDemo's ClassLoader is sun.misc.Launcher$AppClassLoader@18b4aac2 +The Parent of ClassLodarDemo's ClassLoader is sun.misc.Launcher$ExtClassLoader@1b6d3586 +The GrandParent of ClassLodarDemo's ClassLoader is null +``` + +`AppClassLoader`的父类加载器为`ExtClassLoader`， +`ExtClassLoader`的父类加载器为 null，**null 并不代表`ExtClassLoader`没有父类加载器，而是 `BootstrapClassLoader`** 。 + +其实这个双亲翻译的容易让别人误解，我们一般理解的双亲都是父母，这里的双亲更多地表达的是“父母这一辈”的人而已，并不是说真的有一个 Mother ClassLoader 和一个 Father ClassLoader 。另外，类加载器之间的“父子”关系也不是通过继承来体现的，是由“优先级”来决定。官方 API 文档对这部分的描述如下: + +> The Java platform uses a delegation model for loading classes. **The basic idea is that every class loader has a "parent" class loader.** When loading a class, a class loader first "delegates" the search for the class to its parent class loader before attempting to find the class itself. + +### 双亲委派模型实现源码分析 + +双亲委派模型的实现代码非常简单，逻辑非常清晰，都集中在 `java.lang.ClassLoader` 的 `loadClass()` 中，相关代码如下所示。 + +```java +private final ClassLoader parent; +protected Class loadClass(String name, boolean resolve) + throws ClassNotFoundException + { + synchronized (getClassLoadingLock(name)) { + // 首先，检查请求的类是否已经被加载过 + Class c = findLoadedClass(name); + if (c == null) { + long t0 = System.nanoTime(); + try { + if (parent != null) {//父加载器不为空，调用父加载器loadClass()方法处理 + c = parent.loadClass(name, false); + } else {//父加载器为空，使用启动类加载器 BootstrapClassLoader 加载 + c = findBootstrapClassOrNull(name); + } + } catch (ClassNotFoundException e) { + //抛出异常说明父类加载器无法完成加载请求 + } + + if (c == null) { + long t1 = System.nanoTime(); + //自己尝试加载 + c = findClass(name); + + // this is the defining class loader; record the stats + sun.misc.PerfCounter.getParentDelegationTime().addTime(t1 - t0); + sun.misc.PerfCounter.getFindClassTime().addElapsedTimeFrom(t1); + sun.misc.PerfCounter.getFindClasses().increment(); + } + } + if (resolve) { + resolveClass(c); + } + return c; + } + } +``` + +### 双亲委派模型的好处 + +双亲委派模型保证了 Java 程序的稳定运行，可以避免类的重复加载（JVM 区分不同类的方式不仅仅根据类名，相同的类文件被不同的类加载器加载产生的是两个不同的类），也保证了 Java 的核心 API 不被篡改。如果没有使用双亲委派模型，而是每个类加载器加载自己的话就会出现一些问题，比如我们编写一个称为 `java.lang.Object` 类的话，那么程序运行的时候，系统就会出现多个不同的 `Object` 类。 + +### 如果我们不想用双亲委派模型怎么办？ + +~~为了避免双亲委托机制，我们可以自己定义一个类加载器，然后重写 `loadClass()` 即可。~~ + +**🐛 修正（参见：[issue871](https://github.com/Snailclimb/JavaGuide/issues/871) ）** ：自定义加载器的话，需要继承 `ClassLoader` 。如果我们不想打破双亲委派模型，就重写 `ClassLoader` 类中的 `findClass()` 方法即可，无法被父类加载器加载的类最终会通过这个方法被加载。但是，如果想打破双亲委派模型则需要重写 `loadClass()` 方法 + +## 自定义类加载器 + +除了 `BootstrapClassLoader` 其他类加载器均由 Java 实现且全部继承自`java.lang.ClassLoader`。如果我们要自定义自己的类加载器，很明显需要继承 `ClassLoader`。 + +## 推荐阅读 + +- +- +- diff --git a/docs/java/jvm/java-jvm-questions-01.md b/docs/java/jvm/java-jvm-questions-01.md new file mode 100644 index 0000000000000000000000000000000000000000..ffc718a457c36fc4ec78246c589969d2884e0ec3 --- /dev/null +++ b/docs/java/jvm/java-jvm-questions-01.md @@ -0,0 +1,20 @@ +## Java 内存区域 + +对于 Java 程序员来说，在虚拟机自动内存管理机制下，不再需要像 C/C++程序开发程序员这样为每一个 new 操作去写对应的 delete/free 操作，不容易出现内存泄漏和内存溢出问题。正是因为 Java 程序员把内存控制权利交给 Java 虚拟机，一旦出现内存泄漏和溢出方面的问题，如果不了解虚拟机是怎样使用内存的，那么排查错误将会是一个非常艰巨的任务。 + +### Java 内存区域和内存模型(JMM)有何区别？ + +**Java 内存区域和内存模型是完全不一样的两个东西！！！** + +- Java 内存区域定义了JVM 在运行时如何分区存储程序数据，就比如说堆主要用于存放对象实例。 +- Java 内存模型抽象了线程和主内存之间的关系，就比如说线程之间的共享变量必须存储在主内存中，其目的是为了屏蔽系统和硬件的差异，避免一套代码在不同的平台下产生的效果不一致。 + +### 简单介绍一下 Java 内存区域（运行时数据区） + + + + + +## 参考 + +- 嘿，同学，你要的 Java 内存模型 (JMM) 来了：https://xie.infoq.cn/article/739920a92d0d27e2053174ef2 \ No newline at end of file diff --git a/docs/java/jvm/jdk-monitoring-and-troubleshooting-tools.md b/docs/java/jvm/jdk-monitoring-and-troubleshooting-tools.md new file mode 100644 index 0000000000000000000000000000000000000000..37e2c0d320e89ada67feb8b647d0e5be56666f1b --- /dev/null +++ b/docs/java/jvm/jdk-monitoring-and-troubleshooting-tools.md @@ -0,0 +1,311 @@ +--- +category: Java +tag: + - JVM +--- + +# JDK 监控和故障处理工具总结 + +## JDK 命令行工具 + +这些命令在 JDK 安装目录下的 bin 目录下： + +- **`jps`** (JVM Process Status）: 类似 UNIX 的 `ps` 命令。用于查看所有 Java 进程的启动类、传入参数和 Java 虚拟机参数等信息； +- **`jstat`**（JVM Statistics Monitoring Tool）: 用于收集 HotSpot 虚拟机各方面的运行数据; +- **`jinfo`** (Configuration Info for Java) : Configuration Info for Java,显示虚拟机配置信息; +- **`jmap`** (Memory Map for Java) : 生成堆转储快照; +- **`jhat`** (JVM Heap Dump Browser) : 用于分析 heapdump 文件，它会建立一个 HTTP/HTML 服务器，让用户可以在浏览器上查看分析结果; +- **`jstack`** (Stack Trace for Java) : 生成虚拟机当前时刻的线程快照，线程快照就是当前虚拟机内每一条线程正在执行的方法堆栈的集合。 + +### `jps`:查看所有 Java 进程 + +`jps`(JVM Process Status) 命令类似 UNIX 的 `ps` 命令。 + +`jps`：显示虚拟机执行主类名称以及这些进程的本地虚拟机唯一 ID（Local Virtual Machine Identifier,LVMID）。`jps -q` ：只输出进程的本地虚拟机唯一 ID。 + +```powershell +C:\Users\SnailClimb>jps +7360 NettyClient2 +17396 +7972 Launcher +16504 Jps +17340 NettyServer +``` + +`jps -l`:输出主类的全名，如果进程执行的是 Jar 包，输出 Jar 路径。 + +```powershell +C:\Users\SnailClimb>jps -l +7360 firstNettyDemo.NettyClient2 +17396 +7972 org.jetbrains.jps.cmdline.Launcher +16492 sun.tools.jps.Jps +17340 firstNettyDemo.NettyServer +``` + +`jps -v`：输出虚拟机进程启动时 JVM 参数。 + +`jps -m`：输出传递给 Java 进程 main() 函数的参数。 + +### `jstat`: 监视虚拟机各种运行状态信息 + +jstat（JVM Statistics Monitoring Tool） 使用于监视虚拟机各种运行状态信息的命令行工具。 它可以显示本地或者远程（需要远程主机提供 RMI 支持）虚拟机进程中的类信息、内存、垃圾收集、JIT 编译等运行数据，在没有 GUI，只提供了纯文本控制台环境的服务器上，它将是运行期间定位虚拟机性能问题的首选工具。 + +**`jstat` 命令使用格式：** + +```powershell +jstat -