java面试技术栈

墨蓝 2022-09-10 01:17 134阅读 0赞

# java基础 #

## 数据结构 ##

### 排序算法 ###

#### 算法分类 ####

十种常见排序算法可以分为两大类：

比较类排序：通过比较来决定元素间的相对次序，由于其时间复杂度不能突破O(nlogn)，因此也称为非线性时间比较类排序。
    
    非比较类排序：不通过比较来决定元素间的相对次序，它可以突破基于比较排序的时间下界，以线性时间运行，因此也称为线性时间非比较类排序。

![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5a6r5bSO5LiN6aqP_size_20_color_FFFFFF_t_70_g_se_x_16]

#### 算法复杂度 ####

![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5a6r5bSO5LiN6aqP_size_20_color_FFFFFF_t_70_g_se_x_16 1]

#### 相关概念 ####

1.  稳定：如果a原本在b前面，而a=b，排序之后a仍然在b的前面。
2.  不稳定：如果a原本在b的前面，而a=b，排序之后 a 可能会出现在 b 的后面。
3.  时间复杂度：对排序数据的总的操作次数。反映当n变化时，操作次数呈现什么规律。
4.  空间复杂度：是指算法在计算机

内执行时所需存储空间的度量，它也是数据规模n的函数。

### 冒泡排序（Bubble Sort） ###

冒泡排序是一种简单的排序算法。它重复地走访过要排序的数列，一次比较两个元素，如果它们的顺序错误就把它们交换过来。走访数列的工作是重复地进行直到没有再需要交换，也就是说该数列已经排序完成。这个算法的名字由来是因为越小的元素会经由交换慢慢“浮”到数列的顶端。

#### 算法描述 ####

1.  比较相邻的元素。如果第一个比第二个大，就交换它们两个；
2.  对每一对相邻元素作同样的工作，从开始第一对到结尾的最后一对，这样在最后的元素应该会是最大的数；
3.  针对所有的元素重复以上的步骤，除了最后一个；
4.  重复步骤1~3，直到排序完成。

#### 动图演示 ####

![在这里插入图片描述][e43b4520f647426b8a38238f481c7af3.gif_pic_center]

#### 代码实现 ####

### 选择排序（Selection Sort） ###

选择排序(Selection-sort)是一种简单直观的排序算法。它的工作原理：首先在未排序序列中找到最小（大）元素，存放到排序序列的起始位置，然后，再从剩余未排序元素中继续寻找最小（大）元素，然后放到已排序序列的末尾。以此类推，直到所有元素均排序完毕。

#### 算法描述 ####

n个记录的直接选择排序可经过n-1趟直接选择排序得到有序结果。具体算法描述如下：

1.  初始状态：无序区为R\[1…n\]，有序区为空；
2.  第i趟排序(i=1,2,3…n-1)开始时，当前有序区和无序区分别为R\[1…i-1\]和R(i…n）。该趟排序从当前无序区中-选出关键字最小的记录  
    R\[k\]，将它与无序区的第1个记录R交换，使R\[1…i\]和R\[i+1…n)分别变为记录个数增加1个的新有序区和记录个数减少1个的新无序区；
3.  n-1趟结束，数组有序化了。

#### 动图演示 ####

![在这里插入图片描述][cfd9b423203d41d0ab65ea0e948891ad.gif_pic_center]

#### 代码实现 ####

#### 算法分析 ####

表现最稳定的排序算法之一，因为无论什么数据进去都是O(n2)的时间复杂度，所以用到它的时候，数据规模越小越好。唯一的好处可能就是不占用额外的内存空间了吧。理论上讲，选择排序可能也是平时排序一般人想到的最多的排序方法了吧。

### 插入排序（Insertion Sort） ###

插入排序（Insertion-Sort）的算法描述是一种简单直观的排序算法。它的工作原理是通过构建有序序列，对于未排序数据，在已排序序列中从后向前扫描，找到相应位置并插入。

#### 算法描述 ####

一般来说，插入排序都采用in-place在数组上实现。具体算法描述如下：

1.  从第一个元素开始，该元素可以认为已经被排序；
2.  取出下一个元素，在已经排序的元素序列中从后向前扫描；
3.  如果该元素（已排序）大于新元素，将该元素移到下一位置；
4.  重复步骤3，直到找到已排序的元素小于或者等于新元素的位置；
5.  将新元素插入到该位置后；
6.  重复步骤2~5。

#### 动图演示 ####

![在这里插入图片描述][1647aed877f7487bbd5966633b84fb08.gif_pic_center]

#### 代码实现 ####

#### 算法分析 ####

插入排序在实现上，通常采用in-place排序（即只需用到O(1)的额外空间的排序），因而在从后向前扫描过程中，需要反复把已排序元素逐步向后挪位，为最新元素提供插入空间。

### 希尔排序（Shell Sort） ###

1959年Shell发明，第一个突破O(n2)的排序算法，是简单插入排序的改进版。它与插入排序的不同之处在于，它会优先比较距离较远的元素。希尔排序又叫缩小增量排序。

#### 算法描述 ####

先将整个待排序的记录序列分割成为若干子序列分别进行直接插入排序，具体算法描述：

1.  选择一个增量序列t1，t2，…，tk，其中ti>tj，tk=1；
2.  按增量序列个数k，对序列进行k 趟排序；
3.  每趟排序，根据对应的增量ti，将待排序列分割成若干长度为m 的子序列，分别对各子表进行直接插入排序。仅增量因子为1  
    时，整个序列作为一个表来处理，表长度即为整个序列的长度。

#### 动图演示 ####

![在这里插入图片描述][f425c22c71df4c8f8393ebbc5d7e2130.gif_pic_center]

#### 代码实现 ####

#### 算法分析 ####

希尔排序的核心在于间隔序列的设定。既可以提前设定好间隔序列，也可以动态的定义间隔序列。动态定义间隔序列的算法是《算法（第4版）》的合著者Robert Sedgewick提出的。

### 归并排序（Merge Sort） ###

归并排序是建立在归并操作上的一种有效的排序算法。该算法是采用分治法（Divide and Conquer）的一个非常典型的应用。将已有序的子序列合并，得到完全有序的序列；即先使每个子序列有序，再使子序列段间有序。若将两个有序表合并成一个有序表，称为2-路归并。

#### 算法描述 ####

1.  把长度为n的输入序列分成两个长度为n/2的子序列；
2.  对这两个子序列分别采用归并排序；
3.  将两个排序好的子序列合并成一个最终的排序序列。

#### 动图演示 ####

![在这里插入图片描述][0d35f85ca48f49c8a823a16c3d2976de.gif_pic_center]

#### 代码实现 ####

#### 算法分析 ####

归并排序是一种稳定的排序方法。和选择排序一样，归并排序的性能不受输入数据的影响，但表现比选择排序好的多，因为始终都是O(nlogn）的时间复杂度。代价是需要额外的内存空间。

### 快速排序（Quick Sort） ###

快速排序的基本思想：通过一趟排序将待排记录分隔成独立的两部分，其中一部分记录的关键字均比另一部分的关键字小，则可分别对这两部分记录继续进行排序，以达到整个序列有序。

#### 算法描述 ####

快速排序使用分治法来把一个串（list）分为两个子串（sub-lists）。具体算法描述如下：

1.  从数列中挑出一个元素，称为 “基准”（pivot）；
2.  重新排序数列，所有元素比基准值小的摆放在基准前面，所有元素比基准值大的摆在基准的后面（相同的数可以到任一边）。在这个分区退出之后，该基准就处于数列的中间位置。这个称为分区（partition）操作；
3.  递归地（recursive）把小于基准值元素的子数列和大于基准值元素的子数列排序。

#### 动图演示 ####

![在这里插入图片描述][f7138fb897154d5bbc326af7564d35bc.gif_pic_center]

#### 代码实现 ####

### 堆排序（Heap Sort） ###

堆排序（Heapsort）是指利用堆这种数据结构所设计的一种排序算法。堆积是一个近似完全二叉树的结构，并同时满足堆积的性质：即子结点的键值或索引总是小于（或者大于）它的父节点。

#### 算法描述 ####

1.  将初始待排序关键字序列(R1,R2….Rn)构建成大顶堆，此堆为初始的无序区；
2.  将堆顶元素R\[1\]与最后一个元素R\[n\]交换，此时得到新的无序区(R1,R2,……Rn-1)和新的有序区(Rn),且满足R\[1,2…n-1\]<=R\[n\]；
3.  由于交换后新的堆顶R\[1\]可能违反堆的性质，因此需要对当前无序区(R1,R2,……Rn-1)调整为新堆，然后再次将R\[1\]与无序区最后一个元素交换，得到新的无序区(R1,R2….Rn-2)和新的有序区(Rn-1,Rn)。不断重复此过程直到有序区的元素个数为n-1，则整个排序过程完成。

#### 动图演示 ####

![在这里插入图片描述][2f0fd58930b14c77955d43535653acbf.gif_pic_center]

#### 代码实现 ####

var len;    // 因为声明的多个函数都需要数据长度，所以把len设置成为全局变量
     
    function buildMaxHeap(arr) {    // 建立大顶堆
        len = arr.length;
        for (var i = Math.floor(len/2); i >= 0; i--) { 
            heapify(arr, i);
        }
    }
     
    function heapify(arr, i) {      // 堆调整
        var left = 2 * i + 1,
            right = 2 * i + 2,
            largest = i;
     
        if (left < len && arr[left] > arr[largest]) { 
            largest = left;
        }
     
        if (right < len && arr[right] > arr[largest]) { 
            largest = right;
        }
     
        if (largest != i) { 
            swap(arr, i, largest);
            heapify(arr, largest);
        }
    }
     
    function swap(arr, i, j) { 
        var temp = arr[i];
        arr[i] = arr[j];
        arr[j] = temp;
    }
     
    function heapSort(arr) { 
        buildMaxHeap(arr);
     
        for (var i = arr.length - 1; i > 0; i--) { 
            swap(arr, 0, i);
            len--;
            heapify(arr, 0);
        }
        return arr;
    }

### 计数排序（Counting Sort） ###

计数排序不是基于比较的排序算法，其核心在于将输入的数据值转化为键存储在额外开辟的数组空间中。 作为一种线性时间复杂度的排序，计数排序要求输入的数据必须是有确定范围的整数。

#### 算法描述 ####

1.  找出待排序的数组中最大和最小的元素；
2.  统计数组中每个值为i的元素出现的次数，存入数组C的第i项；
3.  对所有的计数累加（从C中的第一个元素开始，每一项和前一项相加）；
4.  反向填充目标数组：将每个元素i放在新数组的第C(i)项，每放一个元素就将C(i)减去1。

#### 动图演示 ####

![在这里插入图片描述][c29df51c15924e25ab7eb3b118b3a366.gif_pic_center]

#### 代码实现 ####

#### 算法分析 ####

计数排序是一个稳定的排序算法。当输入的元素是 n 个 0到 k 之间的整数时，时间复杂度是O(n+k)，空间复杂度也是O(n+k)，其排序速度快于任何比较排序算法。当k不是很大并且序列比较集中时，计数排序是一个很有效的排序算法。

### 桶排序（Bucket Sort） ###

桶排序是计数排序的升级版。它利用了函数的映射关系，高效与否的关键就在于这个映射函数的确定。桶排序 (Bucket sort)的工作的原理：假设输入数据服从均匀分布，将数据分到有限数量的桶里，每个桶再分别排序（有可能再使用别的排序算法或是以递归方式继续使用桶排序进行排）。

#### 算法描述 ####

1.  设置一个定量的数组当作空桶；
2.  遍历输入数据，并且把数据一个一个放到对应的桶里去；
3.  对每个不是空的桶进行排序；
4.  从不是空的桶里把排好序的数据拼接起来。

#### 动图演示 ####

![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5a6r5bSO5LiN6aqP_size_14_color_FFFFFF_t_70_g_se_x_16_pic_center]

#### 代码实现 ####

#### 算法分析 ####

桶排序最好情况下使用线性时间O(n)，桶排序的时间复杂度，取决与对各个桶之间数据进行排序的时间复杂度，因为其它部分的时间复杂度都为O(n)。很显然，桶划分的越小，各个桶之间的数据越少，排序所用的时间也会越少。但相应的空间消耗就会增大。

### 基数排序（Radix Sort） ###

基数排序是按照低位先排序，然后收集；再按照高位排序，然后再收集；依次类推，直到最高位。有时候有些属性是有优先级顺序的，先按低优先级排序，再按高优先级排序。最后的次序就是高优先级高的在前，高优先级相同的低优先级高的在前。

#### 算法描述 ####

1.  取得数组中的最大数，并取得位数；
2.  arr为原始数组，从最低位开始取每个位组成radix数组；
3.  对radix进行计数排序（利用计数排序适用于小范围数的特点）；

#### 动图演示 ####

![在这里插入图片描述][c4efed64b44d49a9abc2bc6347162116.gif_pic_center]

#### 代码实现 ####

#### 算法分析 ####

基数排序基于分别排序，分别收集，所以是稳定的。但基数排序的性能比桶排序要略差，每一次关键字的桶分配都需要O(n)的时间复杂度，而且分配之后得到新的关键字序列又需要O(n)的时间复杂度。假如待排数据可以分为d个关键字，则基数排序的时间复杂度将是O(d\*2n) ，当然d要远远小于n，因此基本上还是线性级别的。

基数排序的空间复杂度为O(n+k)，其中k为桶的数量。一般来说n>>k，因此额外空间需要大概n个左右。

### JDK的数据结构 ###

#### ArrayList和LinkedList的区别？ ####

最明显的区别是 ArrrayList底层的数据结构是数组，支持随机访问，而 LinkedList 的底层数据结构是双向循环链表，不支持随机访问。使用下标访问一个元素，ArrayList 的时间复杂度是 O(1)，而 LinkedList 是 O(n)。

#### map ####

1.  有没有使用过ConcurrentHashMap?  
    在JDK1.7版本中，ConcurrentHashMap的数据结构是由一个Segment数组和多个HashEntry组成，主要实现原理是实现了锁分离的思路解决了多线程的安全问题，如下图所示：  
    ![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5a6r5bSO5LiN6aqP_size_20_color_FFFFFF_t_70_g_se_x_16_pic_center]CurrentHashMap的结构

Segment数组的意义就是将一个大的table分割成多个小的table来进行加锁，也就是上面的提到的锁分离技术，而每一个Segment元素存储的是HashEntry数组+链表，这个和HashMap的数据存储结构一样。

ConcurrentHashMap 与HashMap和Hashtable 最大的不同在于：put和 get 两次Hash到达指定的HashEntry，第一次hash到达Segment,第二次到达Segment里面的Entry,然后在遍历entry链表.

1.  HashMap为什么线程不安全？  
    在JDK1.7中，当并发执行扩容操作时会造成环形链和数据丢失的情况。  
    在JDK1.8中，在并发执行put操作时会发生数据覆盖的情况。
2.  ConcurrentHashMap锁的原理？  
    ConcurrentHashMap使用分段锁技术，将数据分成一段一段的存储，然后给每一段数据配一把锁，当一个线程占用锁访问其中一个段数据的时候，其他段的数据也能被其他线程访问，能够实现真正的并发访问。如下图是ConcurrentHashMap的内部结构图：  
    ![在这里插入图片描述][22c6d85ce4f54bdd8e297da96fc531ba.png]
3.  HashMap 、HashTable和 ConcurrentHashMap的区别？

HashMap

底层数组+链表实现，可以存储null键和null值，线程不安全
    初始size为16，扩容：newsize = oldsize*2，size一定为2的n次幂
    扩容针对整个Map，每次扩容时，原来数组中的元素依次重新计算存放位置，并重新插入
    插入元素后才判断该不该扩容，有可能无效扩容（插入后如果扩容，如果没有再次插入，就会产生无效扩容）
    当Map中元素总数超过Entry数组的75%，触发扩容操作，为了减少链表长度，元素分配更均匀
    计算index方法：index = hash & (tab.length – 1)

HashTable

底层数组+链表实现，无论key还是value都不能为null，线程安全，实现线程安全的方式是在修改数据时锁住整个HashTable，效率低，ConcurrentHashMap做了相关优化
    初始size为11，扩容：newsize = olesize*2+1
    计算index的方法：index = (hash & 0x7FFFFFFF) % tab.length

ConcurrentHashMap

底层采用分段的数组+链表实现，线程安全
    通过把整个Map分为N个Segment，可以提供相同的线程安全，但是效率提升N倍，默认提升16倍。(读操作不加锁，由于HashEntry的value变量是 volatile的，也能保证读取到最新的值。)
    Hashtable的synchronized是针对整张Hash表的，即每次锁住整张表让线程独占，ConcurrentHashMap允许多个修改操作并发进行，其关键在于使用了锁分离技术
    有些方法需要跨段，比如size()和containsValue()，它们可能需要锁定整个表而而不仅仅是某个段，这需要按顺序锁定所有段，操作完毕后，又按顺序释放所有段的锁
    扩容：段内扩容（段内元素超过该段对应Entry数组长度的75%触发扩容，不会对整个Map进行扩容），插入前检测需不需要扩容，有效避免无效扩容

#### 线程安全的list 是哪个 ####

Vector

这个是最常听到的线程安全的List实现，但是已经不常用了。  
内部实现直接使用synchronized 关键字对 一些操作的方法加锁。性能很慢。

SynchronizedList

使用Collections.synchronizedList(list); 将list包装成SynchronizedList  
需要注意的是SynchronizedList的add等操作加了锁，但是iterator()方法没有加锁，如果使用迭代器遍历的时候需要在外面手动加锁。  
适用场景：当不需要使用iterator()并且对性能要求不高的场景。

SynchronizedList 和 Vector区别

1.  SynchronizedList 有较好的扩展性，可以将ArrayList，LinkedList等都改成同步的，而Vector底层只有数组的结构。
2.  SynchronizedList 并没有对Iterator方法进行加锁，遍历时需要手动同步处理，Vector加锁了。
3.  SynchronizedList 可以指定锁定的对象。
4.  扩容机制不一样SynchronizedList 1.5倍 ，Vector 2倍。
5.  SynchronizedList使用同步代码块，锁的范围更小。Vector锁的方法。

CopyOnWriteArrayList

在写的时候加锁（ReentrantLock锁），读的时候不加锁，大大提升了读的速度。  
添加元素的时候，先加锁，再复制替换操作，再释放锁。

public boolean add(E e) { 
            final ReentrantLock lock = this.lock;
            lock.lock();
            try { 
                Object[] elements = getArray();
                int len = elements.length;
                Object[] newElements = Arrays.copyOf(elements, len + 1);
                newElements[len] = e;
                setArray(newElements);
                return true;
            } finally { 
                lock.unlock();
            }
        }

适用场景：适用于读多写少的场景。

CopyOnWriteArraySet 这个集合也是在add时加锁，不过在增加元素前会先判断元素是否存在，不存在才会调add方法。

### （map，list ）在什么情况下，会进行扩容，每次扩容多少？ ###

#### map ####

当HashMap的size达到临界值capacity \* loadFactor - 1时，HashMap会进行扩容，将自身容量增加一倍。  
比如对未指定capacity和loadFactor的HashMap，缺省容量和负载因子分别为16和0.75，因此当map中存储的元素数量达到16 \* 0.75 - 1即为11时，该map会将自身容量扩大到2 \* 16 = 32。

在JDK1.7中，如果通过无参构造的话，初始数组容量为0，当真正对数组进行添加时，才真正分配容量。  
每次按照1.5倍（位运算）的比率通过copeOf的方式扩容。  
在JKD1.6中，如果通过无参构造的话，初始数组容量为10.每次通过copeOf的方式扩容后容量为原来的1.5倍加1.以上就是动态扩容的原理。

#### list ####

ArrayList就是动态数组，也是一个对象。创建一个ArrayList对象，该对象存放在堆内存中，且是一个内存连续的内存区域。随着向ArrayList中不断添加元素，其容量也自动增长。自动增长会带来数据向新数组的重新拷贝。

ArrayList的底层是由一个Object\[\]数组构成的，而这个Object\[\]数组，默认的长度是10，所以有的文章会说ArrayList长度容量为10。

不同JdK版本ArrayList 扩容机制不同  
JDK1.6及以前版本

一般情况下，使用的时候会像这样进行声明：  
List arrayList = new ArrayList();  
如果像上面这样使用默认的构造方法，初始容量被设置为10。当ArrayList中的元素超过10个以后，会重新分配内存空间，使数组的大小增长到16。可以通过调试看到动态增长的数量变化：10->16->25->38->58->88->…

也可以使用下面的方式进行声明：  
List arrayList = new ArrayList(4);  
将ArrayList的默认容量设置为4。当ArrayList中的元素超过4个以后，会重新分配内存空间，使数组的大小增长到7。  
可以通过调试看到动态增长的数量变化：4->7->11->17->26->…  
JDK1.7及以后版本

位运算向右移一位（约变为原来的1/2）再加上原来的容量，是加上扩充了1.5倍。

## 线程 ##

### 什么情况下会出现死锁？一般死锁的应对策略有什么？ ###

死锁发生的四个必要条件是：  
1.资源互斥使用。  
2.多个进程保持一定的资源，但又请求新的资源。  
3.资源不可被剥夺。  
4.多个进程循环等待。

一般死锁的应对策略有：  
1.死锁预防。如进程需要的所有资源，在一开始就全部申请好得到之后再开始执行。  
2.死锁避免。如进程每次申请申请资源的时候，根据一定的算法，去看该请求可能不可能造成死锁，如果可能，就不给它分配该资源。  
3.死锁处理。破坏四个必要条件的其中一个，比如kill掉一个进程。  
4.死锁忽略。不管死锁，由用户自行处理，比如重启电脑。一般的系统其实都采取这种策略。

### 线程的创建方式？ ###

1.  实现Rannable接口
2.  实现Callable接口
3.  继承Thread类
4.  线程池创建

### 线程的内存大小一样吗？ ###

不一样  
jdk1.4默认的单个线程是占用256k的内存  
jdk1.5+默认的单个线程是占用1M的内存  
可以通过-Xss参数设定，一般默认就好  
占jvm的内存

### wait和sleep的区别？ ###

sleep()：方法是线程类（Thread）的静态方法，让调用线程进入睡眠状态，让出执行机会给其他线程，等到休眠时间结束后，线程进入就绪状态和其他线程一起竞争cpu的执行时间。因为sleep() 是static静态的方法，他不能改变对象的机锁，当一个synchronized块中调用了sleep() 方法，线程虽然进入休眠，但是对象的机锁没有被释放，其他线程依然无法访问这个对象。

wait()：wait()是Object类的方法，当一个线程执行到wait方法时，它就进入到一个和该对象相关的等待池，同时释放对象的机锁，使得其他线程能够访问，可以通过notify，notifyAll方法来唤醒等待的线程。

### 线程池在项目的使用？ ###

1.  ThreadPoolExecutor的拒绝机制
2.  线程池的构造参数

### HashMap是不是线程安全的？HashMap为什么不是线程安全的？ ###

![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5a6r5bSO5LiN6aqP_size_20_color_FFFFFF_t_70_g_se_x_16_pic_center 1]  
上面的是HashMap的存储数据结构，通过给Map的key计算hash值，然后决定value放到数组的对应索引位置上，这样就可以通过计算key的hash值，直接去数组中拿到value（所以HashMap是O(1)的复杂度）。

当key冲突（不同的key生成的hash值是 相同的）的时候，就需要把多个value放到同一个位置，这时候，jdk1.7以前就是通过链表的方式挂在同一个位置上，jdk1.8以后就是通过平衡树的方式来代替链表的方式（这样就是怕出现冲突太多，链表太长，影响HashMap的性能）。

当我们多个线程同时插入数据库的时候就会出现线程不安全，putVal()是put()方法中调用的，由于put()和putVal()代码没有同步，插入一个value的时候会进行判空处理，在多线程的时候，如果正好2个线程都检查到对应位置是空的，都会插进去的话，先插进去的就会被后插进去的节点覆盖，而不是都挂在后面。就会出现数据错误，导致线程不安全

### JUC ###

JUC就是java.util .concurrent工具包的简称。这是一个处理线程的工具包。

### 内存泄露的处理？ ###

1.  单例造成的内存泄漏：这样不管传入什么Context最终将使用Application的Context，而单例的生命周期和应用的一样长，这样就防止了内存泄漏。
2.  非静态内部类创建静态实例造成的内存泄漏：将内部类设为静态内部类或将该内部类抽取出来封装成一个单例，如果需要使用Context，就使用Application的Context。
3.  Handler造成的内存泄漏：将Handler类独立出来或者使用静态内部类，这样便可以避免内存泄漏。
4.  线程造成的内存泄漏：将AsyncTask和Runnable类独立出来或者使用静态内部类，这样便可以避免内存泄漏。
5.  资源未关闭造成的内存泄漏：对于使用了BraodcastReceiver，ContentObserver，File，Cursor，Stream，Bitmap等资源，应该在Activity销毁时及时关闭或者注销，否则这些资源将不会被回收，从而造成内存泄漏。
6.  使用ListView时造成的内存泄漏：在构造Adapter时，使用缓存的convertView。
7.  集合容器中的内存泄露：在退出程序之前，将集合里的东西clear，然后置为null，再退出程序。
8.  WebView造成的泄露：为WebView另外开启一个进程，通过AIDL与主线程进行通信，WebView所在的进程可以根据业务的需要选择合适的时机进行销毁，从而达到内存的完整释放。

### 如何避免内存泄漏？ ###

1.  在涉及使用Context时，对于生命周期比Activity长的对象应该使用Application的Context。凡是使用Context优先考虑Application的Context，当然它并不是万能的，对于有些地方则必须使用Activity的Context。对于Application，Service，Activity三者的Context的应用场景如下：![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5a6r5bSO5LiN6aqP_size_20_color_FFFFFF_t_70_g_se_x_16 2]其中，NO1表示Application和Service可以启动一个Activity，不过需要创建一个新的task任务队列。而对于Dialog而言，只有在Activity中才能创建。除此之外三者都可以使用。

2、对于需要在静态内部类中使用非静态外部成员变量（如：Context、View )，可以在静态内部类中使用弱引用来引用外部类的变量来避免内存泄漏。  
3、对于不再需要使用的对象，显示的将其赋值为null，比如使用完Bitmap后先调用recycle()，再赋为null。  
4、保持对对象生命周期的敏感，特别注意单例、静态对象、全局性集合等的生命周期。  
5、对于生命周期比Activity长的内部类对象，并且内部类中使用了外部类的成员变量，可以这样做避免内存泄漏：  
1）将内部类改为静态内部类  
2）静态内部类中使用弱引用来引用外部类的成员变量

## JVM ##

### 什么是jvm? ###

1.  jvm是一种用于计算设备的规范，它是一个虚构出来的机器，是通过在实际的计算机上仿真模拟各种功能实现的。
2.  jvm包含一套字节码指令集，一组寄存器，一个栈，一个垃圾回收堆和一个存储方法域。
3.  JVM屏蔽了与具体操作系统平台相关的信息，使Java程序只需生成在Java虚拟机上运行的目标代码（字节码）,就可以在多种平台上不加修改地运行。

JVM在执行字节码时，实际上最终还是把字节码解释成具体平台上的机器指令执行。

### jdk、jre、jvm是什么关系？ ###

1.  JRE(Java Runtime Environment)，也就是java平台。所有的java程序都要在JRE环境下才能运行。
2.  JDK(Java Development Kit)，是开发者用来编译、调试程序用的开发包。JDK也是JAVA程序需要在JRE上运行。
3.  JVM(Java Virtual  
    Machine)，是JRE的一部分。它是一个虚构出来的计算机，是通过在实际的计算机上仿真模拟各种计算机功能来实现的。

JVM有自己完善的硬件架构，如处理器、堆栈、寄存器等，还具有相应的指令系统。  
Java语言最重要的特点就是跨平台运行。使用JVM就是为了支持与操作系统无关，实现跨平台。

### JVM原理 ###

*  jvm是java的核心和基础，在java编译器和os平台之间的虚拟处理器，可在上面执行字节码程序。
 *  java编译器只要面向jvm，生成jvm能理解的字节码文件。java源文件经编译成字节码程序，通过jvm将每条指令翻译成不同的机器码，通过特定平台运行。

### JVM执行程序的过程 ###

*  加载.class文件
 *  管理并分配内存
 *  执行垃圾收集

JRE（java运行时环境）由JVM构造的java程序的运行环，也是Java程序运行的环境，但是他同时一个操作系统的一个应用程序一个进程，  
因此他也有他自己的运行的生命周期，也有自己的代码和数据空间。  
JVM在整个jdk中处于最底层，负责于操作系统的交互，用来屏蔽操作系统环境，  
提供一个完整的Java运行环境，因此也就虚拟计算机。

操作系统装入JVM是通过jdk中Java.exe来完成，  
通过下面4步来完成JVM环境：

1.  创建JVM装载环境和配置
2.  装载JVM.dll
3.  初始化JVM.dll并挂界到JNIENV(JNI调用接口)实例
4.  调用JNIEnv实例装载并处理class类。

### JVM的生命周期 ###

1.  JVM实例对应了一个独立运行的java程序它是进程级别

a) 启动。启动一个Java程序时，一个JVM实例就产生了，任何一个拥有public static void  
main(String\[\] args)函数的class都可以作为JVM实例运行的起点

b) 运行。main()作为该程序初始线程的起点，任何其他线程均由该线程启动。JVM内部有两种线程：守护线程和非守护线程，main()属于非守护线程，守护线程通常由JVM自己使用，java程序也可以表明自己创建的线程是守护线程

c) 消亡。当程序中的所有非守护线程都终止时，JVM才退出；若安全管理器允许，程序也可以使用Runtime类或者System.exit()来退出

1.  JVM执行引擎实例则对应了属于用户运行程序的线程它是线程级别的

### GC的执行流程 ###

● 新生代 GC（Minor GC）：从年轻代空间（包括 Eden 和 Survivor 区域）回收内存被称为 Minor GC,因为 Java 对象大多都具备朝生夕灭的特性，所以 Minor GC 非常频繁，一般回收速度也比较快。这一定义既清晰又易于理解。但是，当发生Minor GC事件的时候，有一些有趣的地方需要注意到：

1.  当 JVM 无法为一个新的对象分配空间时会触发 Minor GC，比如当 Eden 区满了。所以分配率越高，越频繁执行 Minor GC。
2.  内存池被填满的时候，其中的内容全部会被复制，指针会从0开始跟踪空闲内存。Eden 和 Survivor 区进行了标记和复制操作，取代了经典的标记、扫描、压缩、清理操作。所以 Eden 和 Survivor 区不存在内存碎片。写指针总是停留在所使用内存池的顶部。
3.  执行 Minor GC 操作时，不会影响到永久代。从永久代到年轻代的引用被当成 GC roots，从年轻代到永久代的引用在标记阶段被直接忽略掉。
4.  质疑常规的认知，所有的 Minor GC 都会触发“全世界的暂停（stop-the-world）”，停止应用程序的线程。对于大部分应用程序，停顿导致的延迟都是可以忽略不计的。其中的真相就 是，大部分 Eden 区中的对象都能被认为是垃圾，永远也不会被复制到 Survivor 区或者老年代空间。如果正好相反，Eden 区大部分新生对象不符合 GC 条件，Minor GC 执行时暂停的时间将会长很多。  
    所以 Minor GC 的情况就相当清楚了——每次 Minor GC 会清理年轻代的内存。

● 老年代 GC（Major GC / Full GC）：指发生在老年代的 GC，出现了 Major GC，经常会伴随至少一次的 Minor GC（但非绝对的，ParallelScavenge 收集器的收集策略里就有直接进行 Major GC 的策略选择过程） 。MajorGC 的速度一般会比 Minor GC 慢 10倍以上。

### 垃圾回收算法 ###

1.  标记-清除算法：

最基础的垃圾收集算法，算法分为“标记”和“清除”两个阶段：首先标记出所有需要回收的对象，在标记完成之后统一回收掉所有被标记的对象。

标记-清除算法的缺点有两个：首先，效率问题，标记和清除效率都不高。其次，标记清除之后会产生大量的不连续的内存碎片，空间碎片太多会导致当程序需要为较大对象分配内存时无法找到足够的连续内存而不得不提前触发另一次垃圾收集动作。

1.  复制算法：

将可用内存按容量分成大小相等的两块，每次只使用其中一块，当这块内存使用完了，就将还存活的对象复制到另一块内存上去，然后把使用过的内存空间一次清理掉。这样使得每次都是对其中一块内存进行回收，内存分配时不用考虑内存碎片等复杂情况，只需要移动堆顶指针，按顺序分配内存即可，实现简单，运行高效。

复制算法的缺点显而易见，可使用的内存降为原来一半。

1.  标记-整理算法：

标记-整理算法在标记-清除算法基础上做了改进，标记阶段是相同的标记出所有需要回收的对象，在标记完成之后不是直接对可回收对象进行清理，而是让所有存活的对象都向一端移动，在移动过程中清理掉可回收的对象，这个过程叫做整理。

标记-整理算法相比标记-清除算法的优点是内存被整理以后不会产生大量不连续内存碎片问题。

复制算法在对象存活率高的情况下就要执行较多的复制操作，效率将会变低，而在对象存活率高的情况下使用标记-整理算法效率会大大提高。

1.  分代收集算法：

根据内存中对象的存活周期不同，将内存划分为几块，java的虚拟机中一般把内存划分为新生代和年老代，当新创建对象时一般在新生代中分配内存空间，当新生代垃圾收集器回收几次之后仍然存活的对象会被移动到年老代内存中，当大对象在新生代中无法找到足够的连续内存时也直接在年老代中创建。

### volatile关键字的作用 ###

1.  保证内存可见性
2.  禁止指令重排序
3.  不保证原子性

### 类加载器 ###

JVM预定义有三种类加载器，当一个 JVM启动的时候，Java开始使用如下三种类加载器：

1.  根类加载器（bootstrap class loader）:它用来加载 Java 的核心类，是用原生代码来实现的，并不继承自java.lang.ClassLoader（负责加载$JAVA\_HOME中jre/lib/rt.jar里所有的class，由C++实现，不是ClassLoader子类）。由于引导类加载器涉及到虚拟机本地实现细节，开发者无法直接获取到启动类加载器的引用，所以不允许直接通过引用进行操作。
2.  扩展类加载器（extensions classloader）：它负责加载JRE的扩展目录，lib/ext或者由java.ext.dirs系统属性指定的目录中的JAR包的类。由Java语言实现，父类加载器为null。
3.  系统类加载器（system classloader）：被称为系统（也称为应用）类加载器，它负责在JVM启动时加载来自Java命令的-classpath选项、java.class.path系统属性，或者CLASSPATH换将变量所指定的JAR包和类路径。程序可以通过ClassLoader的静态方法getSystemClassLoader()来获取系统类加载器。如果没有特别指定，则用户自定义的类加载器都以此类加载器作为父加载器。由Java语言实现，父类加载器为ExtClassLoader。

类加载器加载Class大致要经过如下8个步骤：

检测此Class是否载入过，即在缓冲区中是否有此Class，如果有直接进入第8步，否则进入第2步。
    如果没有父类加载器，则要么Parent是根类加载器，要么本身就是根类加载器，则跳到第4步，如果父类加载器存在，则进入第3步。
    请求使用父类加载器去载入目标类，如果载入成功则跳至第8步，否则接着执行第5步。
    请求使用根类加载器去载入目标类，如果载入成功则跳至第8步，否则跳至第7步。
    当前类加载器尝试寻找Class文件，如果找到则执行第6步，如果找不到则执行第7步。
    从文件中载入Class，成功后跳至第8步。
    抛出ClassNotFountException异常。
    返回对应的java.lang.Class对象。

### 类加载机制 ###

1.  全盘负责：所谓全盘负责，就是当一个类加载器负责加载某个Class时，该Class所依赖和引用其他Class也将由该类加载器负责载入，除非显示使用另外一个类加载器来载入。
2.  双亲委派：所谓的双亲委派，则是先让父类加载器试图加载该Class，只有在父类加载器无法加载该类时才尝试从自己的类路径中加载该类。通俗的讲，就是某个特定的类加载器在接到加载类的请求时，首先将加载任务委托给父加载器，依次递归，如果父加载器可以完成类加载任务，就成功返回；只有父加载器无法完成此加载任务时，才自己去加载。
3.  缓存机制。缓存机制将会保证所有加载过的Class都会被缓存，当程序中需要使用某个Class时，类加载器先从缓存区中搜寻该Class，只有当缓存区中不存在该Class对象时，系统才会读取该类对应的二进制数据，并将其转换成Class对象，存入缓冲区中。这就是为很么修改了Class后，必须重新启动JVM，程序所做的修改才会生效的原因。

### jvm调优 ###

[jvm调优][jvm]

## 锁 ##

### 悲观锁 ###

当要对数据库中的一条数据进行修改的时候，为了避免同时被其他人修改，最好的办法就是直接对该数据进行加锁以防止并发。这种借助数据库锁机制，在修改数据之前先锁定，再修改的方式被称之为悲观并发控制【Pessimistic Concurrency Control，缩写“PCC”，又名“悲观锁”】。

悲观锁，具有强烈的独占和排他特性。它指的是对数据被外界(包括本系统当前的其他事务，以及来自外部系统的事务处理)修改持保守态度。因此，在整个数据处理过程中，将数据处于锁定状态。悲观锁的实现，往往依靠数据库提供的锁机制(也只有数据库层提供的锁机制才能真正保证数据访问的排他性，否则，即使在本系统中实现了加锁机制，也无法保证外部系统不会修改数据)。  
之所以叫做悲观锁，是因为这是一种对数据的修改持有悲观态度的并发控制方式。总是假设最坏的情况，每次读取数据的时候都默认其他线程会更改数据，因此需要进行加锁操作，当其他线程想要访问数据时，都需要阻塞挂起。悲观锁的实现：

1.  传统的关系型数据库使用这种锁机制，比如行锁、表锁、读锁、写锁等，都是在操作之前先上锁。
2.  Java 里面的同步 synchronized 关键字的实现。

悲观锁主要分为共享锁和排他锁：

1.  共享锁【shared locks】又称为读锁，简称 S  
    锁。顾名思义，共享锁就是多个事务对于同一数据可以共享一把锁，都能访问到数据，但是只能读不能修改。
2.  排他锁【exclusive locks】又称为写锁，简称 X  
    锁。顾名思义，排他锁就是不能与其他锁并存，如果一个事务获取了一个数据行的排他锁，其他事务就不能再获取该行的其他锁，包括共享锁和排他锁。获取排他锁的事务可以对数据行读取和修改。

悲观并发控制实际上是“先取锁再访问”的保守策略，为数据处理的安全提供了保证。但是在效率方面，处理加锁的机制会让数据库产生额外的开销，还有增加产生死锁的机会。另外还会降低并行性，一个事务如果锁定了某行数据，其他事务就必须等待该事务处理完才可以处理那行数据。

悲观锁的实现，往往依靠数据库提供的锁机制。在数据库中，悲观锁的流程如下：

1.  在对记录进行修改前，先尝试为该记录加上排他锁(exclusive locks)。
2.  如果加锁失败，说明该记录正在被修改，那么当前查询可能要等待或者抛出异常。具体响应方式由开发者根据实际需要决定。
3.  如果成功加锁，那么就可以对记录做修改，事务完成后就会解锁了。
4.  期间如果有其他对该记录做修改或加排他锁的操作，都会等待解锁或直接抛出异常。

### 乐观锁 ###

乐观锁是相对悲观锁而言的，乐观锁假设数据一般情况不会造成冲突，所以在数据进行提交更新的时候，才会正式对数据的冲突与否进行检测，如果冲突，则返回给用户异常信息，让用户决定如何去做。乐观锁适用于读多写少的场景，这样可以提高程序的吞吐量。

乐观锁采取了更加宽松的加锁机制。也是为了避免数据库幻读、业务处理时间过长等原因引起数据处理错误的一种机制，但乐观锁不会刻意使用数据库本身的锁机制，而是依据数据本身来保证数据的正确性。乐观锁的实现：

1.  CAS 实现：Java 中java.util.concurrent.atomic包下面的原子变量使用了乐观锁的一种 CAS 实现方式。
2.  版本号控制：一般是在数据表中加上一个数据版本号 version 字段，表示数据被修改的次数。当数据被修改时，version 值会  
    \+1。当线程 A 要更新数据时，在读取数据的同时也会读取 version 值，在提交更新时，若刚才读取到的 version 值与当前数据库中的 version 值相等时才更新，否则重试更新操作，直到更新成功。

乐观并发控制相信事务之间的数据竞争(data race)的概率是比较小的，因此尽可能直接做下去，直到提交的时候才去锁定，所以不会产生任何锁和死锁。

乐观锁实现方式

主要就是两个步骤：冲突检测和数据更新

## 序列化 ##

### Serializable类的作用？ ###

序列化是将对象状态转换为可保持或传输的格式的过程。与序列化相对的是反序列化，它将流转换为对象。这两个过程结合起来，可以轻松地存储和传输数据。

### 什么是序列化？为什么要用序列化？ ###

将java对象持久化到磁盘  
远程传输使用，可以使java对象以流的方式进行传输

### 有没有使用过序列化？ ###

原始的实现 Serializable 接口有很大的局限性，现在大部分使用 json 序列化的方式，惊醒对象的存储或者传输。

## 反射 ##

### 反射的原理是什么？ ###

Java反射机制是在运行状态中，对于任意一个类，都能够知道这个类的所有属性和方法；对于任意一个对象，都能够调用它的任意一个方法和属性；这种动态获取的信息以及动态调用对象的方法的功能称为Java语言的反射机制。

### java反射机制有三个动态特性？ ###

1.  运行时生成对象实例。
2.  运行时调用方法。
3.  运行时更改属性。

## 基础 ##

### int 所占的长度？ ###

boolean 1个字节
    byte 1个字节
    short 2个字节
    char 2个字节
    int 4个字节
    float 4个字节
    long 8个字节
    double 8个字节

### int可以直接赋值给char吗？ ###

不可以，简单地来讲，就是只能从一个范围较小的数字转换到一个范围较大的数字，如32位的int类型到64位的long是可以隐式转换的，即可以直接把一个int类型的变量赋给一个long类型的变量。

类似的，我们可以直接把一个16位的char类型的变量赋给一个32位的int类型的变量，但是，反之便不可以，需要用显式转换。

### 创建对象的方式有几种？ ###

1.  用new语句创建对象，这是最常用的创建对象的方式。
2.  运用反射手段，调用Java.lang.Class或者java.lang.reflect.Constructor类的newInstance()实例方法。
3.  调用对象的clone()方法。
4.  运用反序列化手段，调用java.io.ObjectInputStream对象的readObject()方法.

### Object类有哪些方法？ ###

1.  clone方法

保护方法，实现对象的浅复制，只有实现了Cloneable接口才可以调用该方法，否则抛出CloneNotSupportedException异常。

主要是JAVA里除了8种基本类型传参数是值传递，其他的类对象传参数都是引用传递，我们有时候不希望在方法里讲参数改变，这是就需要在类中复写clone方法。

1.  getClass方法

final方法，获得运行时类型。

1.  toString方法

该方法用得比较多，一般子类都有覆盖。

1.  finalize方法

该方法用于释放资源。因为无法确定该方法什么时候被调用，很少使用。

1.  equals方法

该方法是非常重要的一个方法。一般equals和==是不一样的，但是在Object中两者是一样的。子类一般都要重写这个方法。

1.  hashCode方法

该方法用于哈希查找，可以减少在查找中使用equals的次数，重写了equals方法一般都要重写hashCode方法。这个方法在一些具有哈希功能的Collection中用到。

一般必须满足obj1.equals(obj2)==true。可以推出obj1.hash- Code()==obj2.hashCode()，但是hashCode相等不一定就满足equals。不过为了提高效率，应该尽量使上面两个条件接近等价。

如果不重写hashcode(),在HashSet中添加两个equals的对象，会将两个对象都加入进去。

1.  wait方法

wait方法就是使当前线程等待该对象的锁，当前线程必须是该对象的拥有者，也就是具有该对象的锁。wait()方法一直等待，直到获得锁或者被中断。wait(long timeout)设定一个超时间隔，如果在规定时间内没有获得锁就返回。

调用该方法后当前线程进入睡眠状态，直到以下事件发生。

（1）其他线程调用了该对象的notify方法。

（2）其他线程调用了该对象的notifyAll方法。

（3）其他线程调用了interrupt中断该线程。

（4）时间间隔到了。

此时该线程就可以被调度了，如果是被中断的话就抛出一个InterruptedException异常。

1.  notify方法

该方法唤醒在该对象上等待的某个线程。

1.  notifyAll方法

该方法唤醒在该对象上等待的所有线程。

### hashcode和equals的区别？ ###

1.  首先equals()和hashcode()这两个方法都是从object类中继承过来的。  
    　　equals()是对两个对象的地址值进行的比较（即比较引用是否相同）。  
    　　hashCode()是一个本地方法，它的实现是根据本地机器相关的。
2.  Java语言对equals()的要求如下，这些要求是必须遵循的：  
    　　A 对称性：如果x.equals(y)返回是“true”，那么y.equals(x)也应该返回是“true”。  
    　　B 反射性：x.equals(x)必须返回是“true”。  
    　　C 类推性：如果x.equals(y)返回是“true”，而且y.equals(z)返回是“true”，那么z.equals(x)也应该返回是“true”。  
    　　D 一致性：如果x.equals(y)返回是“true”，只要x和y内容一直不变，不管你重复x.equals(y)多少次，返回都是“true”。  
    　　任何情况下，x.equals(null)，永远返回是“false”；x.equals(和x不同类型的对象)永远返回是“false”。
3.  equals()相等的两个对象，hashcode()一定相等；  
    　　反过来：hashcode()不等，一定能推出equals()也不等；  
    　　hashcode()相等，equals()可能相等，也可能不等。

# 微服务 #

## SpringCloud和Dubbo的区别和优缺点？ ##

1.  从整体架构上来看：二者模式接近，都需要服务提供方，注册中心，服务消费方。差异不大。
2.  从核心要素来看：Spring Cloud 更胜一筹，在开发过程中只要整合Spring Cloud的子项目就可以顺利的完成各种组件的融合，而Dubbo缺需要通过实现各种Filter来做定制，开发成本以及技术难度略高。  
    Dubbo只是实现了服务治理，而Spring Cloud子项目分别覆盖了微服务架构下的众多部件，而服务治理只是其中的一个方面。Dubbo提供了各种Filter，对于上述中“无”的要素，可以通过扩展Filter来完善。
3.  从协议上看：Dubbo缺省协议采用单一长连接和NIO异步通讯，适合于小数据量大并发的服务调用，以及服务消费者机器数远大于服务提供者机器数的情况，Spring Cloud 使用HTTP协议的REST API。  
    dubbo支持各种通信协议，而且消费方和服务方使用长链接方式交互，通信速度上略胜Spring Cloud，如果对于系统的响应时间有严格要求，长链接更合适。
4.  从服务依赖方式看：Dubbo服务依赖略重，需要有完善的版本管理机制，但是程序入侵少。而Spring Cloud通过Json交互，省略了版本管理的问题，但是具体字段含义需要统一管理，自身Rest API方式交互，为跨平台调用奠定了基础。
5.  从组件运行流程看：Dubbo每个组件都是需要部署在单独的服务器上，gateway用来接受前端请求、聚合服务，并批量调用后台原子服务。每个service层和单独的DB交互。Spring Cloud所有请求都统一通过 API 网关（Zuul）来访问内部服务。网关接收到请求后，从注册中心（Eureka）获取可用服务。由 Ribbon 进行均衡负载后，分发到后端的具体实例。微服务之间通过 Feign 进行通信处理业务。  
    业务部署方式相同，都需要前置一个网关来隔绝外部直接调用原子服务的风险。Dubbo需要自己开发一套API 网关，而Spring Cloud则可以通过Zuul配置即可完成网关定制。使用方式上Spring Cloud略胜一筹。

## 组件 ##

### Hystrix ###

#### Hystrix设计目标： ####

对来自依赖的延迟和故障进行防护和控制——这些依赖通常都是通过网络访问的
    阻止故障的连锁反应
    快速失败并迅速恢复
    回退并优雅降级
    提供近实时的监控与告警

#### Hystrix遵循的设计原则： ####

防止任何单独的依赖耗尽资源（线程）
    过载立即切断并快速失败，防止排队
    尽可能提供回退以保护用户免受故障
    使用隔离技术（例如隔板，泳道和断路器模式）来限制任何一个依赖的影响
    通过近实时的指标，监控和告警，确保故障被及时发现
    通过动态修改配置属性，确保故障及时恢复
    防止整个依赖客户端执行失败，而不仅仅是网络通信

#### Hystrix如何实现这些设计目标？ ####

使用命令模式将所有对外部服务（或依赖关系）的调用包装在HystrixCommand或HystrixObservableCommand对象中，并将该对象放在单独的线程中执行；
    每个依赖都维护着一个线程池（或信号量），线程池被耗尽则拒绝请求（而不是让请求排队）。
    记录请求成功，失败，超时和线程拒绝。
    服务错误百分比超过了阈值，熔断器开关自动打开，一段时间内停止对该服务的所有请求。
    请求失败，被拒绝，超时或熔断时执行降级逻辑。
    近实时地监控指标和配置的修改。

#### hystrix的作用? ####

1.  基于命令模式的请求：解耦了请求者和接受者，使得发送出去的命令可以排队、异步执行。
2.  资源隔离：用ConcurrentHashMap绑定commandKey和线程池，当某个功能运行不稳定或有问题时，服务的其他部分不受影响。服务恢复比较快。
3.  熔断和服务降级：用ConcurrentHashMap绑定commandKey和HystrixCircuitBreaker类（断路器类），统计每次请求的结果并记录，根据结果判断是否开启断路器，自定义异常返回结果实现熔断降级。

### Feign ###

#### Feign的工作原理? ####

feign是一个伪客户端，即它不做任何的请求处理。Feign通过处理注解生成request，从而实现简化HTTP API开发的目的，即开发人员可以使用注解的方式定制request api模板，在发送http request请求之前，feign通过处理注解的方式替换掉request模板中的参数，这种实现方式显得更为直接、可理解。

### eurak和nacos的区别 ###

Eureka

优点：

1.  Spring Cloud 官方推荐
2.  AP模型，数据最终一致性
3.  开箱即用，具有控制台管理

缺点：

1.  客户端注册服务上报所有信息，节点多的情况下，网络，服务端压力过大，且浪费内存
2.  客户端更新服务信息通过简单的轮询机制，当服务数量巨大时，服务器压力过大。
3.  集群伸缩性不强，服务端集群通过广播式的复制，增加服务器压力
4.  Eureka2.0 闭源（Spring Cloud最新版本还是使用的1.X版本的Eureka）

Nacos

优点：

1.  开箱即用，适用于dubbo，spring cloud等
2.  AP模型，数据最终一致性
3.  注册中心，配置中心二合一(二合一也不一定是优点)，提供控制台管理
4.  纯国产，各种有中文文档，久经双十一考验

缺点：

1.  刚刚开源不久，社区热度不够，依然存在bug

## 微服务的CAP定理和BASE理论? ##

cap定理:  
CAP原则又称CAP定理，指的是在一个分布式系统中， Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性），三者不可得兼。  
CAP原则是NOSQL数据库的基石。Consistency（一致性）。 Availability（可用性）。Partition tolerance（分区容错性）。  
分布式系统的CAP理论：理论首先把分布式系统中的三个特性进行了如下归纳：  
一致性（C）：在分布式系统中的所有数据备份，在同一时刻是否同样的值。（等同于所有节点访问同一份最新的数据副本）  
可用性（A）：在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求。（对数据更新具备高可用性）  
分区容忍性（P）：以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择。  
定理：任何分布式系统只可同时满足二点，没法三者兼顾

eureka：当集群一个eureka节点down后，为了满足可用性A，舍去了一致性，后面恢复后数据一致。

zookeeper: 当集群一个zookeeper节点down后，为了满足一致性，暂时无法注册后面恢复后都可注册。

base理论:  
eBay 的架构师 Dan Pritchett 源于对大规模分布式系统的实践总结，在 ACM 上发表文章提出 BASE 理论，BASE 理论是对 CAP 理论的延伸，核心思想是即使无法做到强一致性（Strong Consistency，CAP 的一致性就是强一致性），但应用可以采用适合的方式达到最终一致性（Eventual Consitency）。

### 分布式事务的特性? ###

分布式事务本身就是事务，所以也有事务的特性。事务有四个特征ACID：  
A：原子性（Atomicity）  
事务中的各个操作单元要么全部做，要么就全部不做。不能事务执行后，处于只做一半的状态。  
C：一致性（Consistency）  
事务执行后，必须由一个一致状态变为另外一个一致状态。  
I：隔离性（Isolation）  
事务之间不能相互干扰。  
D：持久性（Durability）  
一旦事务完成，对于数据的变更是永久的。

### 什么是分布式事务? ###

分布式事务指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上,且属于不同的应用，分布式事务需要保证这些操作要么全部成功，要么全部失败。本质上来说，分布式事务就是为了保证不同数据库的数据一致性。

## 分布式事务使用的什么? ##

1.  两阶段提交（2PC）
2.  三阶段提交（3PC）
3.  补偿事务（TCC）
4.  本地消息表（消息队列）
5.  Sagas事务模型（最终一致性）

[具体可参考此篇文章][Link 1]

# 中间件 #

## kafaka ##

### Kafka的优势？ ###

1.  高吞吐量、低延迟：kafka每秒可以处理几十万条消息，它的延迟最低只有几毫秒；
2.  可扩展性：kafka集群支持热扩展；
3.  持久性、可靠性：消息被持久化到本地磁盘，并且支持数据备份防止数据丢失；
4.  容错性：允许集群中节点故障（若副本数量为n,则允许n-1个节点故障）；
5.  高并发：支持数千个客户端同时读写。

### Kafka适用场景？ ###

1.  日志收集：一个公司可以用Kafka可以收集各种服务的log，通过kafka以统一接口服务的方式开放给各种consumer；
2.  消息系统：解耦生产者和消费者、缓存消息等；
3.  用户活动跟踪：kafka经常被用来记录web用户或者app用户的各种活动，如浏览网页、搜索、点击等活动，这些活动信息被各个服务器发布到kafka的topic中，然后消费者通过订阅这些topic来做实时的监控分析，亦可保存到数据库；
4.  1.  运营指标：kafka也经常用来记录运营监控数据。包括收集各种分布式应用的数据，生产各种操作的集中反馈，比如报警和报告；
5.  流式处理：比如spark streaming和storm。

## rabbitMQ ##

### RabbitMQ是什么？ ###

RabbitMQ是实现了高级消息队列协议（AMQP）的开源消息代理软件（亦称面向消息的中间件）。RabbitMQ服务器是用Erlang语言编写的，而群集和故障转移是构建在开放电信平台框架上的。所有主要的编程语言均有与代理接口通讯的客户端库。

### RabbitMQ特点? ###

1.  可靠性: RabbitMQ使用一些机制来保证可靠性， 如持久化、传输确认及发布确认等。
2.  灵活的路由 : 在消息进入队列之前，通过交换器来路由消息。对于典型的路由功能， RabbitMQ  
    己经提供了一些内置的交换器来实现。针对更复杂的路由功能，可以将多个 交换器绑定在一起， 也可以通过插件机制来实现自己的交换器。
3.  扩展性: 多个RabbitMQ节点可以组成一个集群，也可以根据实际业务情况动态地扩展 集群中节点。
4.  高可用性 : 队列可以在集群中的机器上设置镜像，使得在部分节点出现问题的情况下队 列仍然可用。
5.  多种协议: RabbitMQ除了原生支持AMQP协议，还支持STOMP， MQTT等多种消息 中间件协议。
6.  多语言客户端 :RabbitMQ 几乎支持所有常用语言，比如 Java、 Python、 Ruby、 PHP、 C\#、  
    JavaScript 等。
7.  管理界面 : RabbitMQ 提供了一个易用的用户界面，使得用户可以监控和管理消息、集 群中的节点等。
8.  令插件机制 : RabbitMQ 提供了许多插件 ， 以实现从多方面进行扩展，当然也可以编写自 己的插件。

## ES搜索引擎 ##

### 什么是ES，为什么要用ES？ ###

Elasticsearch是一个基于Lucene的搜索引擎。它提供了具有HTTP Web界面和无架构JSON文档的分布式，多租户能力的全文搜索引擎。Elasticsearch是用Java开发的，根据Apache许可条款作为开源发布。

用ES做一个全文索引

### ElasticSearch中的分片是什么? ###

因为Elasticsearch是一个分布式搜索引擎，所以索引通常被分割成分布在多个节点上的被称为分片的元素

### Elasticsearch中的倒排索引是什么？ ###

倒排索引是搜索引擎的核心。搜索引擎的主要目标是在查找发生搜索条件的文档时提供快速搜索。倒排索引是一种像数据结构一样的散列图，可将用户从单词导向文档或网页。它是搜索引擎的核心。其主要目标是快速搜索从数百万文件中查找数据。

# nginx #

## 请解释一下什么是 Nginx ？ ##

Nginx ，是一个 Web 服务器和反向代理服务器，用于 HTTP、HTTPS、SMTP、POP3 和 IMAP 协议。  
目前使用的最多的 Web 服务器或者代理服务器，像淘宝、新浪、网易、迅雷等都在使用。  
Nginx 的主要功能如下：  
作为 http server (代替 Apache ，对 PHP 需要 FastCGI 处理器支持)  
FastCGI：Nginx 本身不支持 PHP 等语言，但是它可以通过 FastCGI 来将请求扔给某些语言或框架处理。  
反向代理服务器  
实现负载均衡  
虚拟主机

## Nginx 常用命令？ ##

1.  启动 nginx 。
2.  停止 nginx -s stop 或 nginx -s quit 。
3.  重载配置 ./sbin/nginx -s reload(平滑重启) 或 service nginx reload 。
4.  重载指定配置文件 .nginx -c /usr/local/nginx/conf/nginx.conf 。
5.  查看 nginx 版本 nginx -v 。
6.  检查配置文件是否正确 nginx -t 。
7.  显示帮助信息 nginx -h 。

## Nginx 有哪些优点？ ##

1.  跨平台、配置简单。
2.  非阻塞、高并发连接
3.  内存消耗小
4.  成本低廉，且开源。
5.  稳定性高，宕机的概率非常小。

## 使用“反向代理服务器”的优点是什么？ ##

反向代理服务器可以隐藏源服务器的存在和特征。它充当互联网云和 Web 服务器之间的中间层。这对于安全方面来说是很好的，特别是当我们使用 Web 托管服务时。

## 什么是反向代理？ ##

反向代理（Reverse Proxy）方式，是指以代理服务器来接受 Internet上的连接请求，然后将请求，发给内部网络上的服务器并将从服务器上得到的结果返回给 Internet 上请求连接的客户端，此时代理服务器对外就表现为一个反向代理服务器。

反向代理总结就一句话：代理端代理的是服务端。

## 什么是正向代理？ ##

一个位于客户端和原始服务器(origin server)之间的服务器，为了从原始服务器取得内容，客户端向代理发送一个请求并指定目标(原始服务器)，然后代理向原始服务器转交请求并将获得的内容返回给客户端。

*  客户端才能使用正向代理。
 *  正向代理总结就一句话：代理端代理的是客户端。例如说：?我们使用的翻墙软件，OpenVPN 等等。

## 为什么 Nginx 不使用多线程？ ##

Apache: 创建多个进程或线程，而每个进程或线程都会为其分配 cpu 和内存（线程要比进程小的多，所以 worker 支持比 perfork 高的并发），并发过大会榨干服务器资源。

Nginx: 采用单线程来异步非阻塞处理请求（管理员可以配置 Nginx 主进程的工作进程的数量）(epoll)，不会为每个请求分配 cpu 和内存资源，节省了大量资源，同时也减少了大量的 CPU 的上下文切换。所以才使得 Nginx 支持更高的并发。

## Nginx 有哪些负载均衡策略？ ##

1.  轮询（默认）round\_robin：每个请求按时间顺序逐一分配到不同的后端服务器，如果后端服务器 down 掉，能自动剔除。
2.  IP 哈希 ip\_hash：每个请求按访问 ip 的 hash 结果分配，这样每个访客固定访问一个后端服务器，可以解决 session  
    共享的问题。
3.  最少连接 least\_conn：下一个请求将被分派到活动连接数量最少的服务器

# spring #

## 对spring中的事物有没有了解？ ##

Spring支持事务类型：编程式事务和声明式事务  
编程式事务：在代码中进行硬编码，与业务的耦合度高，难以复用  
声明式事务：本质使用AOP，将业务和事务管理分离，降低耦合度和提高事务的复用能力。声明式事务可以通过注解和配置来管理事务，操作简单。

## 谈谈Spirng ioc 和 Aop？ ##

### ioc ###

IOC控制反转主要强调的是程序之间的关系是由容器（spring）控制的，容器控制对象，控制了对外部资源的获取。而反转即为，在传统的编程中都是由我们创建对象获取依赖对象，而在IOC中是容器帮我们创建对象并注入依赖对象，正是容器帮我们查找和注入对象，对象是被获取，所以叫反转。

可以理解为当一个对象a调用另一个对象b的时候，传统的写法是在对象a中把对象b实例化，但是在spring中，a和b对象都是spring初始化并管理的，通过set方法注入或者构

简单理解：功能对象不是自己实例化，通过注入实现（优点：解决硬编码问题）

### AOP ###

主要是管理系统层的业务，比如日志，权限，事物等。AOP是将封装好的对象剖开，找出其中对多个对象产生影响的公共行为，并将其封装为一个可重用的模块，这个模块被命名为切面（aspect），切面将那些与业务逻辑无关，却被业务模块共同调用的逻辑提取并封装起来，减少了系统中的重复代码，降低了模块间的耦合度，同时提高了系统的可维护性。

*  面向切面编程，通过预编译方式和运行期动态代理实现程序功能的统一维护的一种技术。
 *  在不影响原来功能代码的基础上，使用动态代理加入自己需要的一些功能（比如权限的验证，事务的控制，日志的记录等等），移除之后，并不影响原来的功能
 *  面向切面编程是通过动态代理实现的，是对面向对象思想的补充。
 *  可以提供声明式的事务管理。
 *  spring支持用户自定义的切面。

## 项目中对AOP的实际应用？ ##

1.  权限的验证
2.  事务的控制
3.  日志的记录

## Controller 是单例的还是多例的？ ##

controller默认是单例的，不要使用非静态的成员变量，否则会发生数据逻辑混乱。  
正因为单例所以不是线程安全的。

## spring的事务的失效场景？ ##

1.  注解下的方法，必须是 pulbic 的
2.  事务嵌套时不能调用本类的方法，因为使用的是动态代理，首个方法已经被代理，如果调用当前累的方法是没有被代理的
3.  在代码中 使用了 try cache 由于异常不能被抛出则无法生效
4.  roolback 指定的异常级别较低，没有被覆盖到

## spring 事务的传播机制有哪些？ ##

1.  propagation-requierd：如果当前没有事务，就新建一个事务，如果已存在一个事务中，则加入到这个事务中，这个是默认选项。
2.  propagation-supports：如果当前有事务，则支持当前事务，如果当前没有事务，就以非事务方法执行。
3.  propagation-mandatory：如果当前有事务，则使用当前的事务，如果没有当前事务，就抛出异常。
4.  propagation-required\_new：无论当前有没有事务，都要新建事务，如果当前存在事务，把当前事务挂起。
5.  propagation-not\_supported：以非事务方式执行操作，如果当前存在事务，就把当前事务挂起。
6.  propagation-never：以非事务方式执行操作，如果当前事务存在则抛出异常。
7.  propagation-nested：如果当前存在事务，则作为子事务在嵌套事务内执行。如果当前没有事务，则执行与propagation\_required类似的操作

## spring中的事务隔离级别？ ##

1.  isolation\_default：使用数据库默认的事务隔离级别
2.  isolation\_read\_uncommitted：允许读取尚未提交的修改，可能导致脏读、幻读和不可重复读
3.  isolation\_read\_committed：允许从已经提交的事务读取，可防止脏读、但幻读，不可重复读仍然有可能发生
4.  isolation\_repeatable\_read：对相同字段的多次读取的结果是一致的，除非数据被当前事务自生修改。可防止脏读和不可重复读，但幻读仍有可能发生
5.  isolation\_serializable：完全服从acid隔离原则，确保不发生脏读、不可重复读、和幻读，但执行效率最低。

## 什么是Spring框架？ ##

Spring是一种轻量级框架，旨在提高开发人员的开发效率以及系统的可维护性。

我们一般说的Spring框架就是Spring Framework，它是很多模块的集合，使用这些模块可以很方便地协助我们进行开发。这些模块是核心容器、数据访问/集成、Web、AOP（面向切面编程）、工具、消息和测试模块。比如Core Container中的Core组件是Spring所有组件的核心，Beans组件和Context组件是实现IOC和DI的基础，AOP组件用来实现面向切面编程。

## Spring中的bean生命周期？ ##

1.  Bean容器找到配置文件中Spring Bean的定义。
2.  Bean容器利用Java Reflection API创建一个Bean的实例。
3.  如果涉及到一些属性值，利用set()方法设置一些属性值。
4.  如果Bean实现了BeanNameAware接口，调用setBeanName()方法，传入Bean的名字。
5.  如果Bean实现了BeanClassLoaderAware接口，调用setBeanClassLoader()方法，传入ClassLoader对象的实例。
6.  如果Bean实现了BeanFactoryAware接口，调用setBeanClassFacotory()方法，传入ClassLoader对象的实例。
7.  与上面的类似，如果实现了其他\*Aware接口，就调用相应的方法。
8.  如果有和加载这个Bean的Spring容器相关的BeanPostProcessor对象，执行postProcessBeforeInitialization()方法。
9.  如果Bean实现了InitializingBean接口，执行afeterPropertiesSet()方法。
10. 如果Bean在配置文件中的定义包含init-method属性，执行指定的方法。
11. 如果有和加载这个Bean的Spring容器相关的BeanPostProcess对象，执行postProcessAfterInitialization()方法。
12. 当要销毁Bean的时候，如果Bean实现了DisposableBean接口，执行destroy()方法。
13. 当要销毁Bean的时候，如果Bean在配置文件中的定义包含destroy-method属性，执行指定的方法。

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

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

## 将一个类声明为Spring的bean的注解有哪些？ ##

我们一般使用@Autowired注解去自动装配bean。而想要把一个类标识为可以用@Autowired注解自动装配的bean，可以采用以下的注解实现：

1.  @Component注解。通用的注解，可标注任意类为Spring组件。如果一个Bean不知道属于哪一个层，可以使用@Component注解标注。
2.  @Repository注解。对应持久层，即Dao层，主要用于数据库相关操作。
3.  @Service注解。对应服务层，即Service层，主要涉及一些复杂的逻辑，需要用到Dao层（注入）。
4.  @Controller注解。对应SpringMVC的控制层，即Controller层，主要用于接受用户请求并调用Service层的方法返回数据给前端页面。

## spring 常用注解 ##

@Repository : 数据访问组件 也就是DAO层 用于操作数据库

@Autowired : 可以对类成员变量,方法以及构造函数进行标注,完成自动壮派的工作,通过@Autowired的使用来消除get.set方法

@SpringBootApplication : 用在main方法之上,相当于@Configuration,@EnableAutoConfiguration,@ComponentScan 的组合,

@Configuration : 表示将该类左卫springboot配置文件类  
@EnableAutoConfiguration : 表示程序启动的时候,自动加载springboot默认的配置

@ComponentScan : 表示程序启动的时候,自动扫描当前包以及子包所有的类，除了@Mapper都可以使用。扫描多个，同@MapperScan

@MapperScan:扫描标注有@Mapper的注解 扫描多个可以使用\{\}，比如

@MapperScan({ "com.bdaim.*.dao","com.bdaim.platform.modules.sys.dao"})

@EnableTransactionManagement : //启用实物,要在对应方法之上加@Transactional

@Transactional : 实质上是使用了JDBC的事物进行事务管理,是基于Spring的动态代理机制;必须放在public之上

@Component : 放在DAO类之上,将该类纳入到spring管理容器当中

@Before : (“execution(\* springboot …*.*(…))”) //执行springboot下的子包以及子子包的方法,在方法执行前调用

@Pointcut : (“execution(\* \*.perform(…))”) //定义切点，标记方法

@AfterReturning : (“performance()”) //切点执行成功之后执行

@AfterThrowing : (“performance()”) //切点抛出异常后执行  
@Service : 用于业务逻辑层

@Controller : 表现层,也叫控制器,注解的bean会被spring-mvc框架所使用

@RunWith : 可以理解为测试运行器,例如@RunWith(JUnit4.class)就是指用JUnit4来运行

@SpringBootTest : 单元测试

@MockBean : 用于单元测试,可以将一个不存在的实力作为对象去测试代码的正确性

## springmvc常用注解？ ##

@Controller

在SpringMVC 中，控制器Controller 负责处理由DispatcherServlet 分发的请求，它把用户请求的数据经过业务处理层处理之后封装成一个Model ，然后再把该Model 返回给对应的View 进行展示。在SpringMVC 中提供了一个非常简便的定义Controller 的方法，你无需继承特定的类或实现特定的接口，只需使用@Controller 标记一个类是Controller ，然后使用@RequestMapping 和@RequestParam 等一些注解用以定义URL 请求和Controller 方法之间的映射，这样的Controller 就能被外界访问到。此外Controller 不会直接依赖于HttpServletRequest 和HttpServletResponse 等HttpServlet 对象，它们可以通过Controller 的方法参数灵活的获取到。

@Controller 用于标记在一个类上，使用它标记的类就是一个SpringMVC Controller 对象。分发处理器将会扫描使用了该注解的类的方法，并检测该方法是否使用了@RequestMapping 注解。@Controller 只是定义了一个控制器类，而使用@RequestMapping 注解的方法才是真正处理请求的处理器。单单使用@Controller 标记在一个类上还不能真正意义上的说它就是SpringMVC 的一个控制器类，因为这个时候Spring 还不认识它。那么要如何做Spring 才能认识它呢？这个时候就需要我们把这个控制器类交给Spring 来管理。有两种方式：

（1）在SpringMVC 的配置文件中定义MyController 的bean 对象。

（2）在SpringMVC 的配置文件中告诉Spring 该到哪里去找标记为@Controller 的Controller 控制器。

@RequestMapping

RequestMapping是一个用来处理请求地址映射的注解，可用于类或方法上。用于类上，表示类中的所有响应请求的方法都是以该地址作为父路径。

@Resource和@Autowired

@Resource和@Autowired都是做bean的注入时使用，其实@Resource并不是Spring的注解，它的包是javax.annotation.Resource，需要导入，但是Spring支持该注解的注入。

@ResponseBody

作用： 该注解用于将Controller的方法返回的对象，通过适当的HttpMessageConverter转换为指定格式后，写入到Response对象的body数据区。

使用时机：返回的数据不是html标签的页面，而是其他某种格式的数据时（如json、xml等）使用；

@Component

相当于通用的注解，当不知道一些类归到哪个层时使用，但是不建议。

@Repository

用于注解dao层，在daoImpl类上面注解。

## springboot常用注解？ ##

@Service:

注解在类上，表示这是一个业务层bean  
@Controller：

注解在类上，表示这是一个控制层bean  
@Repository:

注解在类上，表示这是一个数据访问层bean  
@Component：

注解在类上，表示通用bean ，value不写默认就是类名首字母小写

@Autowired：

按类型注入.默认属性required= true;当不能确定 Spring 容器中一定拥有某个类的Bean 时， 可以在需要自动注入该类 Bean 的地方可以使用@Autowired(required = false)， 这等于告诉Spring：在找不到匹配Bean时也不抛出BeanCreationException 异常。

@Configuration：

注解在类上，表示这是一个IOC容器，相当于spring的配置文件，java配置的方式。 IOC容器的配置类一般与 @Bean 注解配合使用，用@Configuration 注解类等价与 XML 中配置 beans，用@Bean 注解方法等价于 XML 中配置 bean。@Bean： 注解在方法上，声明当前方法返回一个Bean

@Scope：注解在类上，描述spring容器如何创建Bean实例。

1、singleton： 表示在spring容器中的单例，通过spring容器获得该bean时总是返回唯一的实例

2、prototype：表示每次获得bean都会生成一个新的对象

3、request：表示在一次http请求内有效（只适用于web应用）

4、session：表示在一个用户会话内有效（只适用于web应用）

5、globalSession：表示在全局会话内有效（只适用于web应用）

在多数情况，我们只会使用singleton和prototype两种scope，如果未指定scope属性，默认为singleton  
@Value：

注解在变量上，从配置文件中读取

@ConfigurationProperties：

赋值，将注解转换成对象。给对象赋值

@SpringBootApplication：

约定优于配置　　@SpringBootApplication=@ComponentScan+@Configuration+@EnableAutoConfiguration。 放在主程序入口类上, 主程序入口类(启动类) 放在root 包下，这样程序启动时所有的相关配置，类都能扫描，查找到

@EnableAutoConfiguration：

启用 Spring 应用程序上下文的自动配置，试图猜测和配置您可能需要的bean。自动配置类通常采用基于你的classpath 和已经定义的 beans 对象进行应用。被 @EnableAutoConfiguration 注解的类所在的包有特定的意义，并且作为默认配置使用。通常推荐将 @EnableAutoConfiguration 配置在 root 包下，这样所有的子包、类都可以被查找到。

@ComponentScan：

注解在类上，扫描标注了@Controller等注解的类，注册为bean 。@ComponentScan 为

@Configuration：

注解的类配置组件扫描指令。@ComponentScan 注解会自动扫描指定包下的全部标有 @Component注解的类，并注册成bean，当然包括 @Component下的子注解@Service、@Repository、@Controller。

@RestController：

@RestController 是一个结合了 @ResponseBody 和 @Controller 的注解(像:resetful接口调用时,返回的是json等就使用)

@PathVariable和@RequestParam：

都是将request里的参数的值绑定到contorl里的方法参数里的，区别在于，URL写法不同。

使用@RequestParam时，URL是这样的：http://host:port/path?参数名=参数值

使用@PathVariable时，URL是这样的：http://host:port/path/参数值

当请求参数username不存在时会有异常发生,可以通过设置属性required=false解决,例如: @RequestParam(value=“username”,required=false)

不写的时候也可以获取到参数值，但是必须名称对应。参数可以省略不写

@RequestMapping： 和请求报文是做对应的

1、value，指定请求的地址  
　　　　　2、method ，请求方法类型 这个不写的话，自适应：get或者post  
　　　　　3、consumes ，请求的提交内容类型  
　　　　　4、produces ，指定返回的内容类型 仅当request请求头中的(Accept)类型中包含该指定类型才返回  
　　　　　5、 params ，指定request中必须包含某些参数值  
　　　　　6、headers ，指定request中必须包含指定的header值

7、 name ， 指定映射的名称

@RequestMapping(method = RequestMethod.GET)/@GetMapping

@Responsebody：

注解表示该方法的返回的结果直接写入 HTTP 响应正文（ResponseBody）中，一般在异步获取数据时使用，通常是在使用 @RequestMapping 后，返回值通常解析为跳转路径，加上@Responsebody 后返回结果不会被解析为跳转路径，而是直接写入HTTP 响应正文中。（@RequestMapping(value = “/change”,method = RequestMethod.POST,produces = “application/json;charset=utf-8”)）

@EnablCaching：

@EnableCaching注解是spring framework中的注解驱动的缓存管理功能。自spring版本3.1起加入了该注解。如果你使用了这个注解，那么你就不需要在XML文件中配置cache manager了。

@suppresswarnings：抑制警告

@Transactional：事务注解

## [springboot传送门][springboot] ##

## RequestMapping 和 GetMapping 的不同之处在哪里？ ##

*  RequestMapping 具有类属性的，可以进行 GET,POST,PUT 或者其它的注释中具有的请求方法。
 *  GetMapping 是 GET 请求方法中的一个特例。它只是 ResquestMapping 的一个延伸，目的是为了提高清晰度。

# 容器编排 #

## k8s ##

[传送门][Link 2]  
[传送门][Link 3]

# 容器化docker #

[容器化docker][docker]

## docker常用的命令 ##

[docker常用的命令][docker 1]

## docker镜像 ##

### docker镜像组成结构 ###

[docker镜像组成结构][docker 2]

### docker镜像的相关命令 ###

1.  docker image ls / docker images ： 查看镜像列表
2.  docker image pull \[镜像名字\]:\[tag\] : 从镜像仓库下啦镜像
3.  docker push \[镜像名字\]:\[tag\] : 往镜像仓库上传镜像
4.  docker image rm \[镜像名字\]:\[tag\] | 镜像id/ docker rmi \[镜像名字\]:\[tag\] |镜像id

# redis #

## redis 的架构 ##

redis普通主从模式

通过持久化功能，Redis保证了即使在服务器重启的情况下也不会损失（或少量损失）数据，因为持久化会把内存中数据保存到硬盘上，重启会从硬盘上加载数据。 。但是由于数据是存储在一台服务器上的，如果这台服务器出现硬盘故障等问题，也会导致数据丢失。为了避免单点故障，通常的做法是将数据库复制多个副本以部署在不同的服务器上，这样即使有一台服务器出现故障，其他服务器依然可以继续提供服务。为此， Redis 提供了复制（replication）功能，可以实现当一台数据库中的数据更新后，自动将更新的数据同步到其他数据库上。

在复制的概念中，数据库分为两类，一类是主数据库（master），另一类是从数据库（slave）。主数据库可以进行读写操作，当写操作导致数据变化时会自动将数据同步给从数据库。而从数据库一般是只读的，并接受主数据库同步过来的数据。一个主数据库可以拥有多个从数据库，而一个从数据库只能拥有一个主数据库。  
redis的普通主从模式，能较好地避免单独故障问题，以及提出了读写分离，降低了Master节点的压力。互联网上大多数的对redis读写分离的教程，都是基于这一模式或架构下进行的。但实际上这一架构并非是目前最好的redis高可用架构。

redis哨兵模式高可用架构

当主数据库遇到异常中断服务后，开发者可以通过手动的方式选择一个从数据库来升格为主数据库，以使得系统能够继续提供服务。然而整个过程相对麻烦且需要人工介入，难以实现自动化。 为此，Redis 2.8开始提供了哨兵工具来实现自动化的系统监控和故障恢复功能。 哨兵的作用就是监控redis主、从数据库是否正常运行，主出现故障自动将从数据库转换为主数据库。

顾名思义，哨兵的作用就是监控Redis系统的运行状况。它的功能包括以下两个。

1.  监控主数据库和从数据库是否正常运行。
2.  主数据库出现故障时自动将从数据库转换为主数据库。

redis-cluster群集高可用架构

即使使用哨兵，redis每个实例也是全量存储，每个redis存储的内容都是完整的数据，浪费内存且有木桶效应。为了最大化利用内存，可以采用cluster群集，就是分布式存储。即每台redis存储不同的内容。  
采用redis-cluster架构正是满足这种分布式存储要求的集群的一种体现。redis-cluster架构中，被设计成共有16384个hash slot。每个master分得一部分slot，其算法为：hash\_slot = crc16(key) mod 16384 ，这就找到对应slot。采用hash slot的算法，实际上是解决了redis-cluster架构下，有多个master节点的时候，数据如何分布到这些节点上去。key是可用key，如果有\{\}则取\{\}内的作为可用key，否则整个可以是可用key。群集至少需要3主3从，且每个实例使用不同的配置文件。  
在redis-cluster架构中，redis-master节点一般用于接收读写，而redis-slave节点则一般只用于备份，其与对应的master拥有相同的slot集合，若某个redis-master意外失效，则再将其对应的slave进行升级为临时redis-master。

## redis与mysql的同步问题 ##

### 读操作 ###

1.  客户端请求服务器的时候，发现如果服务器的缓存中存在，则直接取服务器的；
2.  如果缓存中不存在，则去请求数据库，并且将数据库计算出来的数据回填给缓存；
3.  返回数据给客户端；

### 写操作 ###

1.  Cache Aside 更新策略：同时更新缓存和数据库；
2.  Read/Write Through 更新策略：先更新缓存，缓存负责同步更新数据库；
3.  Write Behind Caching 更新策略：先更新缓存，缓存定时异步更新数据库；

## redis实现分布式锁 ##

[传送门][Link 4]

## redis的淘汰机制 ##

1.  volatile-lru：从已设置过期时间的数据集（server.db\[i\].expires）中挑选最近最 少使用的数据淘汰
2.  volatile-ttl：从已设置过期时间的数据集（server.db\[i\].expires）中挑选将要过 期的数据淘汰
3.  volatile-random：从已设置过期时间的数据集（server.db\[i\].expires）中任意 选择数据淘汰
4.  allkeys-lru：从数据集（server.db\[i\].dict）中挑选最近最少使用的数据淘汰
5.  allkeys-random：从数据集（server.db\[i\].dict）中任意选择数据淘汰
6.  no-enviction（驱逐）：禁止驱逐数据

注意这里的 6 种机制，volatile 和 allkeys 规定了是对已设置过期时间的数据集淘  
汰数据还是从全部数据集淘汰数据，后面的 lru、ttl 以及 random 是三种不同的  
淘汰策略，再加上一种 no-enviction 永不回收的策略。

使用策略规则：

1.  如果数据呈现幂律分布，也就是一部分数据访问频率高，一部分数据访问频率 低，则使用 allkeys-lru
2.  如果数据呈现平等分布，也就是所有的数据访问频率都相同，则使用 allkeys-random

## reids的主从复制原理 ##

[传送门][Link 5]

## redis的雪崩怎么处理 ##

1.  可以使用分布式锁 单机版的话本地锁
2.  消息中间件方式
3.  一级和二级缓存 Redis+Ehchache
4.  均摊分配Redis的key的失效时间

## redis的持久化机制 ##

1.  RDBRedis DataBase)持久化方式： 是指用数据集快照的方式半持久化模式) 记录 redis  
    数据库的所有键值对,在某个时间点将数据写入一个临时文件，持久化 结束后，用这个临时文件替换上次持久化的文件，达到数据恢复。

优点：

*  只有一个文件 dump.rdb，方便持久化。
 *  容灾性好，一个文件可以保存到安全的磁盘。
 *  性能最大化，fork 子进程来完成写操作，让主进程继续处理命令，所以是 IO 最大化。使用单独子进程来进行持久化，主进程不会进行任何 IO操作，保证了 redis 的高性能)
 *  相对于数据集大时，比 AOF 的启动效率更高。

缺点：

*  数据安全性低。RDB 是间隔一段时间进行持久化，如果持久化之间 redis 发生故障，会发生数据丢失。所以这种方式更适合数据要求不严谨的时候)
 *  AOFAppend-only file)持久化方式： 是指所有的命令行记录以 redis 命令请 求协议的格式完全持久化存储)保存为aof 文件。

1.  AOF持久化(即Append OnlyFile持久化)，则是将Redis执行的每次写命令记录到单独的日志文件中，当重启Redis会重新将持久化的日志中文件恢复数据。

优点：

*  数据安全，aof 持久化可以配置 appendfsync 属性，有 always，每进行一次 命令操作就记录到 aof 文件中一次。
 *  通过 append 模式写文件，即使中途服务器宕机，可以通过 redis-check-aof 工具解决数据一致性问题。
 *  AOF 机制的 rewrite 模式。AOF 文件没被 rewrite  
    之前（文件过大时会对命令进行合并重写），可以删除其中的某些命令（比如误操作的 flushall）

缺点：

*  AOF 文件比 RDB 文件大，且恢复速度慢。
 *  数据集大的时候，比 rdb 启动效率低。

## 什么是 缓存击穿，缓存穿透，缓存雪崩？ ##

缓存穿透

描述：
    
       缓存穿透是指缓存和数据库中都没有的数据，而用户不断发起请求，如发起为id为“-1”的数据或id为特别大不存在的数据。这时的用户很可能是攻击者，攻击会导致数据库压力过大。
    
      解决方案：
    
    接口层增加校验，如用户鉴权校验，id做基础校验，id<=0的直接拦截；
    从缓存取不到的数据，在数据库中也没有取到，这时也可以将key-value对写为key-null，缓存有效时间可以设置短点，如30秒（设置太长会导致正常情况也没法使用）。这样可以防止攻击用户反复用同一个id暴力攻击

缓存击穿

描述：
    
      缓存击穿是指缓存中没有但数据库中有的数据（一般是缓存时间到期），这时由于并发用户特别多，同时读缓存没读到数据，又同时去数据库去取数据，引起数据库压力瞬间增大，造成过大压力
    
      解决方案：
    
    设置热点数据永远不过期。
    加互斥锁

缓存雪崩

描述：
    
      缓存雪崩是指缓存中数据大批量到过期时间，而查询数据量巨大，引起数据库压力过大甚至down机。和缓存击穿不同的是，        缓存击穿指并发查同一条数据，缓存雪崩是不同数据都过期了，很多数据都查不到从而查数据库。
    
     解决方案：
    
    缓存数据的过期时间设置随机，防止同一时间大量数据过期现象发生。
    如果缓存数据库是分布式部署，将热点数据均匀分布在不同搞得缓存数据库中。
    设置热点数据永远不过期。

## redis的过期策略是什么? ##

定时删除
    
        含义：在设置key的过期时间的同时，为该key创建一个定时器，让定时器在key的过期时间来临时，对key进行删除
        优点：保证内存被尽快释放
        缺点：
            若过期key很多，删除这些key会占用很多的CPU时间，在CPU时间紧张的情况下，CPU不能把所有的时间用来做要紧的事儿，还需要去花时间删除这些key
            定时器的创建耗时，若为每一个设置过期时间的key创建一个定时器（将会有大量的定时器产生），性能影响严重
            没人用
            
    惰性删除
    
        含义：key过期的时候不删除，每次从数据库获取key的时候去检查是否过期，若过期，则删除，返回null。
        优点：删除操作只发生在从数据库取出key的时候发生，而且只删除当前key，所以对CPU时间的占用是比较少的，而且此时的删除是已经到了非做不可的地步（如果此时还不删除的话，我们就会获取到了已经过期的key了）
        缺点：若大量的key在超出超时时间后，很久一段时间内，都没有被获取过，那么可能发生内存泄露（无用的垃圾占用了大量的内存）
        
    定期删除
    
        含义：每隔一段时间执行一次删除(在redis.conf配置文件设置hz，1s刷新的频率)过期key操作
        优点：
            通过限制删除操作的时长和频率，来减少删除操作对CPU时间的占用--处理"定时删除"的缺点
            定期删除过期key--处理"惰性删除"的缺点
        缺点
            在内存友好方面，不如"定时删除"
            在CPU时间友好方面，不如"惰性删除"
        难点
            合理设置删除操作的执行时长（每次删除执行多长时间）和执行频率（每隔多长时间做一次删除）（这个要根据服务器运行情况来定了）

# 场景模拟 #

## 秒杀场景的设计 ##

小库存商品秒杀架构设计

![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5a6r5bSO5LiN6aqP_size_20_color_FFFFFF_t_70_g_se_x_16 3]  
大库存商品秒杀架构设计  
![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5a6r5bSO5LiN6aqP_size_20_color_FFFFFF_t_70_g_se_x_16 4]  
总的来说，面对巨量的流量我们的方式就是首先通过各种条件先筛选掉无效流量，进行流量错峰，然后再对现有的系统性能做出优化，比如页面静态化，库存商品预热，也可以通过独立部署的方式和其他的环境做隔离，最后还要解决高并发下缓存一致性、库存不能超卖的问题，防止大量的并发打爆你的数据库。

## 设计一个二维码登录或者授权的场景 ##

假设现在有2个设备，A设备需要扫码授权登陆，B设备是已经登陆了的设备。然后实现如下文所示

一：A设备生成生成二维码：  
　　  
　　A设备向服务器请求getLoginCode接口，这个接口根据请求的sessionId进行base64或其他加密方式进行加密，然后以此作为二维码的值，并将这个loginCode写到redis里，设置5分钟过期。然后将这个loginCode返回给A设备，A设备以此值来生成登陆的二维码。  
　　  
　　二：B设备扫码授权  
　　  
　　B设备来扫A设备的二维码的时候，携带二维码的值，请求授权登陆的接口scanConfirmLogin，此接口里先校验二维码是否过期，没过期的话进行后面的业务逻辑处理，将用户的基本信息和token写到redis里。  
　　  
　　三：A设备轮询获取授权状态  
　　  
　　B设备以每秒一次的频率来刷 获取用户授权状态接口，若状态为已授权，拿到用户信息去做后面的逻辑处理。

## 服务多实例下，需要处理数据库中的一批数据怎么协调和分配 ##

例如实例数为4，我们可以使用注册中心的思想，在处理的固定时间三十秒（时间无所谓）前，向redis中进行注册表示当前实例正常，三十秒后，所有实例取自己的编号（1,2,3,4），将数据库数据 取余 为4，得到分配给自己的数据进行处理，（数据上有标识是否处理过）

## 有100G的IP日志文件，怎么得到其中访问最多的ip ##

首先解决大文件问题，也就是如何处理100G的一个大文件，这个通常的解决方法就是将大文件分解成许多小文件。我们可以通过对IP地址求hash然后对1024取模将一个100G的大文件分解成1024个小文件（file0,file1…file1023），注意这里的1024个文件并不是平均分的，也就是每个文件大小并不是（100G/1204）。当然我们考虑的时候可以假设文件是平均分的，那么每个文件大小为100M，这样一个100M的文件是可以全部读入大小为1G内存中。这样就解决了第一个文件太大不能一次读入内存的问题。

考虑到ip地址是32位，那么总共有232=4G种可能出现的ip地址，每个ip地址出现的次数不确定，这个具体是由100G大文件决定的。对每个小文件进行处理，我们知道前面每个文件中的ip是通过hash(ip)%1024。这样相当于将232=4G种ip地址进行了分段，每个文件中可能出现的ip最大范围是4G/1024=4M，并且每个文件之间的ip不会出现相同情况。

创建一个hashmap，读取小文件中的每个ip地址，判断hashmap中是否有这个ip，如果没有，这往haspmap中插入一个<ip,1>的键值对，即hashmap.put(ip,1)；如果haspmap中已经存在了这个ip，那么求出这个ip所对应的值count=haspmap.get(ip)，然后往修改这个ip所对应的value，使其数量增加1，即hashmap.set(ip,count+1)。

当我们求出每个文件中出现次数最大的ip地址以后，我们在比较这1024个文件中的那个ip出现次数最大。

## 性能瓶颈怎么优化 ##

**CPU：**

如果CPU User非常高，需要查看消耗在哪个进程，可以用top(linux)命令看出，接着用top –H –p 看哪个线程消耗资源高，如果是java应用，就可以用jstack看出此线程正在执行的堆栈，看资源消耗在哪个方法上，查看源代码就知道问题所在；

如果CPU Sys非常高，可以用strace(linux)看系统调用的资源消耗及时间；

如果CPU Wait非常高，考虑磁盘读写，可以通过减少日志输出、异步或换速度快的硬盘。

**内存：**

内存的问题主要看某个进程占用的内存是否非常大以及是否有大量的swap(虚拟内存交换)。

**磁盘IO：**

磁盘I/O一个最显著的指标是繁忙率，可以通过减少日志输出、异步或换速度快的硬盘。

**网络IO：**

网络I/O主要考虑传输内容大小，不能超过硬件网络传输的最大值70%，可以通过压缩、减少内容大小、在本地设置缓存以及分多次传输等。

**内核参数：**

注意运行参数不要超过内核参数而导致系统出现问题

**JVM：**

jvm主要分析GC/FULL GC是否频繁，以及垃圾回收的时间，可以用jstat命令来查看，对于每个代大小以及GC频繁，通过jmap将内存dump,再借助工具HeapAnalyzer来分析哪地方占用的内存较高以及是否有内存泄漏可能。

**线程池：**

如果线程不够用，可以通过参数调整，增加线程；对于线程池中的线程设置比较大的情况，还是不够用可能的原因是：某个线程被阻塞来不及释放，可能在等锁、方法耗时较长、数据库等待时间很长等原因导致，需要进一步分析才能定位。

**JDBC连接池：**

连接池不够用的情况下，可以通过参数进行调整增加；但是对于数据库本身处理很慢的情况下，调整没有多大的效果，需要查看数据库方面以及因代码导致连接未释放的原因。

**SQL：**

慢SQL，可以通过查看执行计划看SQL慢在哪里来进一步优化。

# mysql #

## 索引原理 ##

索引的目的在于提高查询效率，与我们查阅图书所用的目录是一个道理：先定位到章，然后定位到该章下的一个小节，然后找到页数。相似的例子还有：查字典，查火车车次，飞机航班等

本质都是：通过不断地缩小想要获取数据的范围来筛选出最终想要的结果，同时把随机的事件变成顺序的事件，也就是说，有了这种索引机制，我们可以总是用同一种查找方式来锁定数据。

## MySQL的索引分类 ##

1.  普通索引index :加速查找
2.  唯一索引
    
    主键索引：primary key ：加速查找+约束（不为空且唯一）  
    唯一索引：unique：加速查找+约束 （唯一）
3.  联合索引
    
    \-primary key(id,name):联合主键索引  
    \-unique(id,name):联合唯一索引  
    \-index(id,name):联合普通索引
4.  全文索引fulltext :用于搜索很长一篇文章的时候，效果最好。
5.  空间索引spatial :了解就好，几乎不用

## 组合索引，如果只用到部分的字段，那么索引会生效吗？ ##

组合索引 idx(a,b,c) , 其中索引有 a，b，c 三个字段，其实组合索引的实际的索引是三个 a ，ab ，abc ，最左原则，从上面这个组合可以看到，当字段使用 a 或者 ab ，或者abc 时有索引，只使用 b ，或者 bc 将没有索引。

## sql语句的优化 ##

sql中如果知道查询的详细字段尽量写详细的字段，避免写“\*”号，在数据量比较大的时候尽量先限制一个范围可以很快地响应对用户的体验比较好，查询1条数据时用limit 1，尽量避免全文检索，两张不同的表全连接时，union All 的效率要比union的效率要高，因为union 会去重 排序，union All则不会

## 组合索引需要满足什么原则？ ##

最左匹配原则

## sql语句的执行顺序是怎样的？ ##

1.  from

先确定从哪个表中取数据，所以最先执行from tab。存在多表连接，from tab1，tab2。可以对表加别名，方便后面的引用。

1.  where

where语句是对条件加以限定，如果没有需要限定的，那就写成where 1=1，表示总为true，无附加条件。

1.  group by…… having

分组语句，比如按照员工姓名分组，要就行分组的字段，必须出现在select中，否则就会报错。having是和group by配合使用的，用来作条件限定。

1.  聚合函数

常用的聚合函数有max，min， count，sum，聚合函数的执行在group by之后，having之前。如果在where中写聚合函数，就会出错。

1.  select语句

选出要查找的字段，如果全选可以select \*。

1.  order by

排序语句，默认为升序排列。如果要降序排列，就写成order by \[XX\] desc。order by语句在最后执行，只有select选出要查找的字段，才能进行排序。

## mysql的调优怎么做的? ##

*  设计角度：存储引擎的选择，字段类型选择，范式
 *  功能角度：可以利用 mysql 自身的特性，如索引，查询缓存，碎片整理，分区、分 表等
 *  sql 语句的优化方面:尽量简化查询语句，能查询字段少就尽量少查询字段，优化分 页语句、分组语句等。
 *  部署大负载架构体系：数据库服务器单独出来，负载大时可以采用主从复制，读写 分离机制进行设计
 *  从硬件上升级数据库服务器。

## mysql innodb 和 myisam的区别? ##

1、事务和外键

InnoDB具有事务，支持4个事务隔离级别，回滚，崩溃修复能力和多版本并发的事务安全，包括ACID。如果应用中需要执行大量的INSERT或UPDATE操作，则应该使用InnoDB，这样可以提高多用户并发操作的性能

MyISAM管理非事务表。它提供高速存储和检索，以及全文搜索能力。如果应用中需要执行大量的SELECT查询，那么MyISAM是更好的选择

2、全文索引

Innodb不支持全文索引，如果一定要用的话，最好使用sphinx等搜索引擎。myisam对中文支持的不是很好

不过新版本的Innodb已经支持了

3、锁

mysql支持三种锁定级别，行级、页级、表级;

MyISAM支持表级锁定，提供与 Oracle 类型一致的不加锁读取(non-locking read in SELECTs)

InnoDB支持行级锁，InnoDB表的行锁也不是绝对的，如果在执行一个SQL语句时MySQL不能确定要扫描的范围，InnoDB表同样会锁全表，注意间隙锁的影响

例如update table set num=1 where name like “%aaa%”

4、存储

MyISAM在磁盘上存储成三个文件。第一个文件的名字以表的名字开始，扩展名指出文件类型， .frm文件存储表定义，数据文件的扩展名为.MYD， 索引文件的扩展名是.MYI

InnoDB，基于磁盘的资源是InnoDB表空间数据文件和它的日志文件，InnoDB 表的大小只受限于操作系统文件的大小

注意：MyISAM表是保存成文件的形式，在跨平台的数据转移中使用MyISAM存储会省去不少的麻烦

5、索引

InnoDB（索引组织表）使用的聚簇索引、索引就是数据，顺序存储，因此能缓存索引，也能缓存数据

MyISAM（堆组织表）使用的是非聚簇索引、索引和文件分开，随机存储，只能缓存索引

6、并发

MyISAM读写互相阻塞：不仅会在写入的时候阻塞读取，MyISAM还会在读取的时候阻塞写入，但读本身并不会阻塞另外的读

InnoDB 读写阻塞与事务隔离级别相关

## innodb 和 myisam场景选择? ##

MyISAM

不需要事务支持（不支持）
    并发相对较低（锁定机制问题）
    数据修改相对较少（阻塞问题），以读为主
    数据一致性要求不是非常高
    
    尽量索引（缓存机制）
    调整读写优先级，根据实际需求确保重要操作更优先
    启用延迟插入改善大批量写入性能
    尽量顺序操作让insert数据都写入到尾部，减少阻塞
    分解大的操作，降低单个操作的阻塞时间
    降低并发数，某些高并发场景通过应用来进行排队机制
    对于相对静态的数据，充分利用Query Cache可以极大的提高访问效率
    MyISAM的Count只有在全表扫描的时候特别高效，带有其他条件的count都需要进行实际的数据访问

InnoDB

需要事务支持（具有较好的事务特性）
    行级锁定对高并发有很好的适应能力，但需要确保查询是通过索引完成
    数据更新较为频繁的场景
    数据一致性要求较高
    硬件设备内存较大，可以利用InnoDB较好的缓存能力来提高内存利用率，尽可能减少磁盘 IO
    
    主键尽可能小，避免给Secondary index带来过大的空间负担
    避免全表扫描，因为会使用表锁
    尽可能缓存所有的索引和数据，提高响应速度
    在大批量小插入的时候，尽量自己控制事务而不要使用autocommit自动提交
    合理设置innodb_flush_log_at_trx_commit参数值，不要过度追求安全性
    避免主键更新，因为这会带来大量的数据移动

## 事务的隔离级别? ##

<table> 
 <thead> 
  <tr> 
   <th>事务隔离级别</th> 
   <th>脏读</th> 
   <th>不可重复读</th> 
   <th>幻读</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>读未提交（read-uncommitted）</td> 
   <td>是</td> 
   <td>是</td> 
   <td>是</td> 
  </tr> 
  <tr> 
   <td>不可重复读（read-committed）</td> 
   <td>否</td> 
   <td>是</td> 
   <td>是</td> 
  </tr> 
  <tr> 
   <td>可重复读（repeatable-read）</td> 
   <td>否</td> 
   <td>否</td> 
   <td>是</td> 
  </tr> 
  <tr> 
   <td>串行化（serializable）</td> 
   <td>否</td> 
   <td>否</td> 
   <td>否</td> 
  </tr> 
 </tbody> 
</table>

mysql默认的事务隔离级别为repeatable-read

## 事务的特性 ##

**原子性（Atomicity）**  
　　原子性是指事务包含的所有操作要么全部成功，要么全部失败回滚，这和前面两篇博客介绍事务的功能是一样的概念，因此事务的操作如果成功就必须要完全应用到数据库，如果操作失败则不能对数据库有任何影响。

**一致性（Consistency）**  
　　一致性是指事务必须使数据库从一个一致性状态变换到另一个一致性状态，也就是说一个事务执行之前和执行之后都必须处于一致性状态。  
　　拿转账来说，假设用户A和用户B两者的钱加起来一共是5000，那么不管A和B之间如何转账，转几次账，事务结束后两个用户的钱相加起来应该还得是5000，这就是事务的一致性。

**隔离性（Isolation）**  
　　隔离性是当多个用户并发访问数据库时，比如操作同一张表时，数据库为每一个用户开启的事务，不能被其他事务的操作所干扰，多个并发事务之间要相互隔离。  
　　即要达到这么一种效果：对于任意两个并发的事务T1和T2，在事务T1看来，T2要么在T1开始之前就已经结束，要么在T1结束之后才开始，这样每个事务都感觉不到有其他事务在并发地执行。

**持久性（Durability）**  
　　持久性是指一个事务一旦被提交了，那么对数据库中的数据的改变就是永久性的，即便是在数据库系统遇到故障的情况下也不会丢失提交事务的操作。  
　　  
　　例如我们在使用JDBC操作数据库时，在提交事务方法后，提示用户事务操作完成，当我们程序执行完成直到看到提示后，就可以认定事务以及正确提交，即使这时候数据库出现了问题，也必须要将我们的事务完全执行完成，否则就会造成我们看到提示事务处理完毕，但是数据库因为故障而没有执行事务的重大错误。

## 隔离带来的问题？ ##

**脏读**  
　　脏读是指在一个事务处理过程里读取了另一个未提交的事务中的数据。

**不可重复读**  
　　不可重复读是指在对于数据库中的某个数据，一个事务范围内多次查询却返回了不同的数据值，这是由于在查询间隔，被另一个事务修改并提交了。

**虚读(幻读)**  
　　幻读是事务非独立执行时发生的一种现象。例如事务T1对一个表中所有的行的某个数据项做了从“1”修改为“2”的操作，这时事务T2又对这个表中插入了一行数据项，而这个数据项的数值还是为“1”并且提交给数据库。而操作事务T1的用户如果再查看刚刚修改的数据，会发现还有一行没有修改，其实这行是从事务T2中添加的，就好像产生幻觉一样，这就是发生了幻读。

## MYSQL相关的原理结构？ ##

[传送门][Link 6]

## 归档 ##

一、 归档流程：

1.  导出需要的数据
2.  创建临时表table\_tmp
3.  导入数据到临时表
4.  修改原始表名为table\_bak
5.  修改临时表为原始表名

二、归档方式对比

1.  select into outfile load data infile 导入导出的方式

SELECT \* FROM student where create\_time > ‘2018-10-01 00:00:00’ into /data/mysql/student.sql

source /data/mysql/student.sql

1.  INSERT INTO 直接读取写入的方式

INSERT INTO student\_tmp SELECT \* FROM student where create\_time > ‘2019-02-16 00:00:00’

1.  mysql官方自带逻辑备份工具mysqldump

mysqldump --user=root --host=127.0.0.1 -p --skip-lock-tables --single-transaction --flush-logs --hex-blob --master-data=2 test student --where=“create\_time > ‘2019-04-16 00:00:00’” > /data/mysql/student.sql

1.  Percona归档工具pt-archiver

pt-archiver \\

–source h=127.0.0.1, u=root, p=123456, D=test, t=student \\

–dest h=127.0.0.1, P=3306,u=root,p=123456, D=test,t=student\_tmp \\

–progress 50000 \\

–where “create\_time > ‘2019-02-16 00:00:00’” \\

–bulk-insert \\

–statistics \\

–charset=UTF8 \\

–limit=50000 --txn-size 1000 \\

–no-delete

# 算法基础 #

## 快排的原理，时间和空间的复杂度 ##

快速排序是通过一次分割将一个数列分割成以某个数为界限的左右两部分，一边数小于这个分界值，另一边大于这个分界值。分别再将两遍的数，按照同样的方法各选取一个分界值，分成大于和小于分界值的两部分，依次类推，直到分界值左右部分的数不可再分为止。

快速排序  
时间复杂度(平均)O(nlog2n)  
时间复杂度(最坏)O(n2)  
时间复杂度(最好)O(nlog2n)  
空间复杂度O(nlog2n)  
不稳定  
较复杂

## 两个链表的首个公公节点 ##

链表只要存在公共节点，那么公共节点后面所有的节点都是公共的。因此，对于这种一般两种思路  
思路一：将两个链表分别压入两个栈中，然后从栈顶不断比较。知道遇到第一个不相等的节点，然后公共节点就是该节点的下一个节点  
思路二：如果能将链表尾部对齐，那么就可以两两比较了，先分别获取两个链表的长度，然后分别获取两个链表的

# 设计模式 #

[设计模式][Link 7]

[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5a6r5bSO5LiN6aqP_size_20_color_FFFFFF_t_70_g_se_x_16]: /images/20220829/34672cd33f614427bb4d73484db37e11.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5a6r5bSO5LiN6aqP_size_20_color_FFFFFF_t_70_g_se_x_16 1]: /images/20220829/ea61bf53f50b4c2c91c70b1875ffdaae.png
[e43b4520f647426b8a38238f481c7af3.gif_pic_center]: /images/20220829/19d40fb454054e6e98b75cb0427264d9.png
[cfd9b423203d41d0ab65ea0e948891ad.gif_pic_center]: /images/20220829/3be3e1b97556493697b29da6408529cb.png
[1647aed877f7487bbd5966633b84fb08.gif_pic_center]: /images/20220829/9dafaa4dc2bc4c91a08ef2389f9781d3.png
[f425c22c71df4c8f8393ebbc5d7e2130.gif_pic_center]: /images/20220829/7c274dd8dab0404eb535089102b45100.png
[0d35f85ca48f49c8a823a16c3d2976de.gif_pic_center]: /images/20220829/ad1fbce3b7be4db79333af6d9a85fc17.png
[f7138fb897154d5bbc326af7564d35bc.gif_pic_center]: /images/20220829/30c7cfe99cf841499bd89dc9d5724029.png
[2f0fd58930b14c77955d43535653acbf.gif_pic_center]: /images/20220829/ffa3b875c352495183062dad22930121.png
[c29df51c15924e25ab7eb3b118b3a366.gif_pic_center]: /images/20220829/05416df041ed485c9940931c95021ead.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5a6r5bSO5LiN6aqP_size_14_color_FFFFFF_t_70_g_se_x_16_pic_center]: /images/20220829/37f7c1ac86d24e45867e841160214c3b.png
[c4efed64b44d49a9abc2bc6347162116.gif_pic_center]: /images/20220829/e4871197a0ff4c6a8da82d9d5f175126.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5a6r5bSO5LiN6aqP_size_20_color_FFFFFF_t_70_g_se_x_16_pic_center]: /images/20220829/3c6e738e810a4673be99510f4976dce5.png
[22c6d85ce4f54bdd8e297da96fc531ba.png]: /images/20220829/b687d4a713134e5e85e6bdcbb8b6a05d.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5a6r5bSO5LiN6aqP_size_20_color_FFFFFF_t_70_g_se_x_16_pic_center 1]: /images/20220829/e6af4e6c0aff4e029beb28dc4ab12d0f.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5a6r5bSO5LiN6aqP_size_20_color_FFFFFF_t_70_g_se_x_16 2]: /images/20220829/b53d94b0443e4be1bff3e8dda56c1b01.png
[jvm]: https://zhuanlan.zhihu.com/p/91223656
[Link 1]: https://bocloud.blog.csdn.net/article/details/97238041?utm_medium=distribute.pc_relevant.none-task-blog-2~default~BlogCommendFromMachineLearnPai2~default-1.essearch_pc_relevant&depth_1-utm_source=distribute.pc_relevant.none-task-blog-2~default~BlogCommendFromMachineLearnPai2~default-1.essearch_pc_relevant
[springboot]: https://blog.csdn.net/u012068483/article/details/105039330/
[Link 2]: https://zhuanlan.zhihu.com/p/354505651
[Link 3]: https://blog.csdn.net/mingongge/article/details/100613465
[docker]: https://www.cnblogs.com/flaming/p/11438244.html
[docker 1]: https://www.cnblogs.com/DeepInThought/p/10896790.html
[docker 2]: https://www.cnblogs.com/s-b-b/p/8533936.html
[Link 4]: https://www.jianshu.com/p/47fd7f86c848
[Link 5]: https://www.cnblogs.com/daofaziran/p/10978628.html
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5a6r5bSO5LiN6aqP_size_20_color_FFFFFF_t_70_g_se_x_16 3]: /images/20220829/cb80c70195e64180aa0356c9b9c2bbd3.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5a6r5bSO5LiN6aqP_size_20_color_FFFFFF_t_70_g_se_x_16 4]: /images/20220829/c6827d716ac94b4a984bcbdc328ff692.png
[Link 6]: https://blog.csdn.net/qq_45938466/article/details/107941557
[Link 7]: https://blog.csdn.net/itissohardtog/category_9626707.html