java程序员技能树-持续更新思维导图模板

数据结构

List

ArrayList

非线程安全&链接看分析源码

底层是数组

Array循环删除报错？如何解决？

倒序删除

迭代器删除：iterator.remove

copyOnWrite容器删除

支持随机访问

Vector

Vector就是ArrayList的线程安全版，它的方法前都加了synchronized锁，其他实现逻辑都相同。 如果对线程安全要求不高的话，可以选择ArrayList，毕竟synchronized也很耗性能

LinkedList

双向链表-LinkedList由链表实现，插入和删除方便，适用于变更多/读写少的场景

不支持随机访问

Set

hashSet

LinkedList、 ConcurrentLinkedQueue、 LinkedBlockingQueue对比分析

linkeList并发生时容易出现问题，

LinkedBlockingQueue是使用锁机制， ConcurrentLinkedQueue是使用CAS算法， 虽然LinkedBlockingQueue的底层获取锁也是使用的CAS算法

取元素，ConcurrentLinkedQueue不支持阻塞去取元素， LinkedBlockingQueue支持阻塞的take()方法， 如需要ConcurrentLinkedQueue的消费者产生阻塞效果，需要自行实现

插入元素：ConcurrentLinkedQueue肯定是最快的

TreeSet

Map

HashMap

<ul><li>最常用的Map,它根据键的HashCode 值存储数据,根据键可以直接获取它的值，具有很快的访问速度。</li><li>HashMap最多只允许一条记录的键为Null(多条会覆盖);</li><li>允许多条记录的值为 Null。非同步的。</li></ul>

jdk1.7-1.8区别

1.7

插入采用头插法

提高了插入效率，高并发下容易出现死循环

多线程下容易出现resize()死循环

并发执行put操作导致环形链表

数组+链表

1.8

尾插法

数组+链表+红黑树（链表长度>8&数组长度>64）

不保证有序

存储顺序按照hash算法计算而来 数组下标：算法讲究随机性，均匀性，不具备规律

HashMap扩容为什么是2^n-1

map扩容时按：(n-1)&hash计算，2的n次幂转为2进制后计算能够充分的散列，使数据可以均匀分布到map的位置上

线程不安全

无同步锁

hashmap中的fail-fast策略

一旦使用迭代器过程中发现并发修改hashmap则抛出异常： ConcurrentModificationException

在修改hashmap时候会记录变量modCount，修改一次+1， 最后判断modCount和exceptCount是否一致，否则报错

TreeMap

能够把它保存的记录根据键(key)排序,默认是按升序排序，也可以指定排序的比较器，当用Iterator 遍历TreeMap时，得到的记录是排过序的。 TreeMap不允许key的值为null。非同步的

Hashtable

与 HashMap类似,不同的是:key和value的值均不允许为null; 它支持线程的同步（synchronized 锁住整个map），即任一时刻只有一个线程能写Hashtable,因此也导致了Hashtale在写入时会比较慢。

LinkedHashMap

一个双向链表继承了hashmap, 包含了beforce、after指向

保存了记录的插入顺序，在用Iterator遍历LinkedHashMap时，先得到的记录肯定是先插入的.在遍历的时候会比HashMap慢。key和value均允许为空，非同步的

ConCurrentHashMap

jdk1.7&&jdk1.8

https://www.jianshu.com/p/865c813f2726

segment默认16个

1.数据结构：取消了Segment分段锁的数据结构，取而代之的是数组+链表+红黑树的结构。 2.保证线程安全机制：JDK1.7采用segment的分段锁机制实现线程安全，其中segment继承自ReentrantLock。JDK1.8采用CAS+Synchronized保证线程安全。 3.锁的粒度：原来是对需要进行数据操作的Segment加锁，现调整为对每个数组元素加锁（Node）。 4.链表转化为红黑树:定位结点的hash算法简化会带来弊端,Hash冲突加剧,因此在链表节点数量大于8时，会将链表转化为红黑树进行存储。 5.查询时间复杂度：从原来的遍历链表O(n)，变成遍历红黑树O(logN)。

Stack/栈

栈是Vector的一个子类，它实现了一个标准的后进先出的栈

树

二叉树

有序数据优势：二分查找 链表优势：数据插入删除 二叉树综合二者优势

特点

左节点小于等于根节点，右节点大于等于根节点

二叉树插入数据，等于遍历节点有序插入

查找数据，因为数据有序，效率比较高，相当于二分查找

最值查找更加便捷

完全二叉树

定义：一棵二叉树中，只有最下面两层结点的度差可以小于2， 并且最下一层的叶结点集中在靠左的若干位置上。这样的二叉树称为完全二叉树。(设数的度为h，则树的h-1层为满二叉树，且h层的数据都在最左侧)

特点：叶子结点只能出现在最下层和次下层，且最下层的叶子结点集中在树的左部。 显然，满二叉树必定是完全二叉树，而完全二叉树未必是满二叉树

满二叉树

除最后一层无任何子节点外，每一层上的所有结点都有两个子结点的二叉树

平衡二叉树（AVL树）

左右子树的高度差的绝对值不大于1，且左右子树均为平衡二叉树

如果插入或者删除一个节点使得高度之差大于1，就要进行节点之间的旋转，将二叉树重新维持在一个平衡状态。

二叉查找树链接(https://www.cnblogs.com/gaochundong/p/binary_search_tree.html)

也称有序二叉树（ordered binary tree）,排序二叉树（sorted binary tree），时间复杂度(log^2N)

特点

根节点左侧，都小于根节点；右侧节点，都大于根节点

前序遍历#当前节点-左节点-右节点

中序遍历#左节点-当前节点-右节点

后序遍历#左节点-右节点-当前节点

B树=B-Tree

数据均匀存在所有节点中

https://www.cnblogs.com/yfzhou/p/10290006.html

子主题

B+Tree

数据存储在叶子节点

对于范围查找来说，B+只需遍历叶子节点链表即可，B树却需要重复地中序遍历。

红黑树

自平衡二叉树，每次查询时间复杂度LogN

为什么mysql的索引使用B+树而不是B树呢？

<ol><li> B+树更适合外部存储(一般指磁盘存储),由于内节点(非叶子节点)不存储data，所以一个节点可以存储更多的内节点， 每个节点能索引的范围更大更精确。也就是说使用B+树单次磁盘IO的信息量相比较B树更大，IO效率更高。</li><li> - mysql是关系型数据库，经常会按照区间来访问某个索引列，B+树的叶子节点间按顺序建立了链指针，加强了区间访问性， 所以B+树对索引列上的区间范围查询很友好。而B树每个节点的key和data在一起，无法进行区间查找</li></ol>

队列

非阻塞队列

ConcurrentLinkedQueue

阻塞队列

LinkedBlockingQueue

常用算法

整体对比

时间/空间复杂度对比

子主题

基础算法

选择排序

每次从待排序的数据中选取最小的数据，放到已排序数据后面

<ul><li>举例：数组 int[] arr={5,2,8,4,9,1}; ------------------------------------------------------- </li><li> 第一趟排序：原始数据：5 2 8 4 9 1 最小数据1，把1放在首位，也就是1和5互换位置，    排序结果：1 2 8 4 9 5 -------------------------------------------------------</li><li> 第二趟排序： 第1以外的数据{2 8 4 9 5}进行比较，2最小，      排序结果：1 2 8 4 9 5 -------------------------------------------------------</li><li> 第三趟排序： 除1、2以外的数据{8 4 9 5}进行比较，4最小，8和4交换      排序结果：1 2 4 8 9 5 -------------------------------------------------------</li><li> 第四趟排序： 除第1、2、4以外的其他数据{8 9 5}进行比较，5最小，8和5交换      排序结果：1 2 4 5 9 8 -------------------------------------------------------</li><li> 第五趟排序： 除第1、2、4、5以外的其他数据{9 8}进行比较，8最小，8和9交换      排序结果：1 2 4 5 8 9</li></ul>

冒泡排序

子主题

插入排序

快速排序

归并排序

堆排序

桶排序

基数排序

二分查找

java排序工具

JVM

类加载机制

加载过程

加载

生成一个类的Class对象，作为方法区中这个类的各种数据的入口

可以从class文件，或者zip等文件获取，可以实时计算生成

验证

验证class文件字节流是否符合虚拟机要求，是否会危害虚拟机安全

准备

在方法区内，为类的成员变量设置初值

解析

虚拟机将常量池中的符号引用替换为直接引用的过程

符号引用是指class文件中的 CONSTANT_Class_info / CONSTANT_Field_info

直接引用指向目标的指针，相对偏移量

初始化

真正执行类中定义的Java程序代码

执行类构造器<client>方法的过程

client方法是虚拟机自动收集类中的类变量的赋值操作和静态语句块组合而成

client方法执行前，会保证父类的client已执行

不执行初始化情况

子类引用父类静态字段，知会触发父类的初始化

对象数组类型

通过类名获取CLass对象

通过Class.forName加载指定类时，如果指定参数initialize为false时，也不会触发类初始化，其实这个参数是告诉虚拟机，是否要对类进行初始化

ClassLoader默认的loadClass方法，也不会触发初始化动

使用

卸载

类加载器

启动类加载器-Bootstrap ClassLoader

java_home\lib下的类

-Xbootclasspath参数指定路径中的，且被虚拟机认可（按文件名识别，如rt.jar）的类。

扩展类加载器-Extension ClassLoader

java_home\ext下的类

通过java.ext.dirs系统变量指定路径中的类库

应用程序类加载器-Application ClassLoader

加载用户指定路径classPath上的类

双亲委派模型

当一个类收到类加载请求，并不会马上加载，而是请求父类加载，每一个层次皆是如此，最终请求都会传到启动加载器来处理 只有当父类加载器无法处理时，子类加载器才会自己处理

破坏双亲委派模型

加载的基础类中需要回调用户的代码，基础加载器无法识别用户代码？需要破坏双亲委派模型

JNDI破坏双亲委派模型 JNDI是Java标准服务，它的代码由启动类加载器去加载。但是JNDI需要回调独立厂商实现的代码，而类加载器无法识别这些回调代码（SPI）。 为了解决这个问题，引入了一个线程上下文类加载器。可通过Thread.setContextClassLoader()设置。 利用线程上下文类加载器去加载所需要的SPI代码，即父类加载器请求子类加载器去完成类加载的过程，而破坏了双亲委派模型。

Spring破坏双亲委派模型 Spring要对用户程序进行组织和管理，而用户程序一般放在WEB-INF目录下，由WebAppClassLoader类加载器加载， 而Spring由Common类加载器或Shared类加载器加载。 那么Spring是如何访问WEB-INF下的用户程序呢？ 使用线程上下文类加载器。 Spring加载类所用的classLoader都是通过Thread.currentThread().getContextClassLoader()获取的。 当线程创建时会默认创建一个AppClassLoader类加载器（对应Tomcat中的WebAppclassLoader类加载器）： setContextClassLoader(AppClassLoader)。 利用这个来加载用户程序。即任何一个线程都可通过getContextClassLoader()获取到WebAppclassLoader。

执行引擎

https://www.cnblogs.com/codehaogg/p/13334713.html

jvm在加载了class文件后，并不能直接在本地执行，需要执行引擎转换为本地方法指令，才能执行

内存模型

java对象模型

分代年龄：4bit，最大值=2^4

java堆

JVM最大的内存空间，线程共享

存储java实例对象的地方，GC的主要场所

保存绝大部分的java实例，分为新生代，老生代

通过-Xmx和-Xms控制大小

OutOfMemeoryError:当无法分配内存

分类

新生代

8 - Eden

Eden空间耗尽触发MinorGC，存活对象晋升到S0

1 - survivor space0 1 - survivor space1

触发Minor GC Eden空间和s0存活的对象，指向到S1空间，S0和S1交换指针

一个对象被复制15次则提前晋升到老年代

因为对象头里就给了它4个bit来存放，因此最大值就是1111=15，所以你设置很大是没啥用的

标记复制算法

老年代

java8删除

元空间

标记清除算法

方法区

所有java线程共享的。别名 non-heap 非堆

1.存储类结构信息，常量，静态变量，构造函数，及编译后代码 2.运行时常量池，类和接口被加载，常量池被创建

通过-XX：MaxPermSize，设置大小

栈(stack)

和线程关联，每创建一个线程，都要分配，均为线程私有

java虚拟机栈

与线程的生命周期一致

存储局部变量表、操作数栈、动态链接、方法出口（局部变量表存储：基本类型，对象引用，returnAddress-指向了一条字节码指令的地址） 等信息

stackoverflow：当线程请求的栈深度超过虚拟机栈深度；OutOfMemeroy:当栈扩展无法申请到做够的内存时

参数：-Xss

程序计数器

较小的内存空间，可以看做当前线程执行字节码行号的计数器

执行java方法时，记录的是执行字节码地址；执行Native方法，记录为空(Undefined)

本地方法栈

与虚拟机栈类似，主要是执行Native方法服务

native方法

简单地讲，一个Native Method就是一个java调用非java代码的接口。 一个Native Method是这样一个java的方法：该方法的实现由非java语言实现，比如C。 这个特征并非java所特有，很多其它的编程语言都有这一机制， 比如在C＋＋中，你可以用extern "C"告知C＋＋编译器去调用一个C的函数

GC回收

java引用

强引用

类似 B b=new B(),只要引用存在就不会被回收

软引用

软引用是一种相对强引用弱化一些的引用，可以让对象豁免一些垃圾收集，只有当 JVM 认为内存不足时， 才会去试图回收软引用指向的对象。JVM 会确保在抛出 OutOfMemoryError 之前，清理软引用指向的对象。 软引用通常用来实现内存敏感的缓存，如果还有空闲内

弱引用

非必需对象，常用来防止内存泄漏；只能生存到下次GC；GC时不论空间是否足够，弱引用对象都会被回收

虚引用

最弱的引用关系，无法通过引用获取对象，主要是再对象回收后会收到系统通知

要注意的是，虚引用必须和引用队列关联使用，当垃圾回收器准备回收一个对象时，如果发现它还有虚引用，就会把这个虚引用加入到与之关联的引用队列中。程序可以通过判断引用队列中是否已经加入了虚引用，来了解被引用的对象是否将要被垃圾回收。如果程序发现某个虚引用已经被加入到引用队列，那么就可以在所引用的对象的内存被回收之前采取必要的行动。

对象存活

引用计数法

对象添加引用计数器，引用 +1， =0则判断无引用

效率高，but循环引用问题

可达性分析

以 GC Root为根节点，到FGC Root无引用链接，判断无引用

GC Root有哪些

虚拟机栈（栈帧中的本地变量表）中的引用对象

本地方法栈中的引用对象

方法区中类的静态类属性，引用的对象

方法区中常量类属性，引用的对象

GC算法

标记清除

首先标记所有需要回收的对象，标记完成后一次回收所有标记对象

标记整理

首先标记需要清除的对象，然后存活对象压缩到堆的其中一块，按顺序排放 避免了“标记清除”的碎片问题，避免了"复制"算法的空间问题

复制

内存分为相等的两块，一块使用完时，将存活对象复制到另一块内存中，最后回收使用完的内存

垃圾收集器

Serial收集器

单线程，最古老，最稳定以及效率高的收集器，可能会产生较长的停顿

Stop The World，它在工作时，会暂停其他的所有的工作线程，直到结束

ParNew收集器

Serial收集器的多线程版本

首选的新生代收集器

Parallel Old 收集器

新生代收集器

并行多线程收集器，采用"复制算法"

GC自适应调节策略

-XX:+UseAdaptiveSizePolicy

不需要指定新生代大小，Eden&Survivor比例，晋升老年嗲年龄 虚拟机会根据系统运行情况，动态调整这些参数，以提供最合适的停顿时间\最大吞吐量

CMS收集器

concurrent mark sweep

以获取最短回收停顿时间为准的收集器 基于"标记-清除"算法实现

处理过程

初始标记：stop the world 只标记GC Roots直连对象，速度较块 并发标记：GC Roots tracing过程 重新标记：修正再并发标记期间程序运行导致的变动的对象标记，stop the world 并发清除：并发清除标记对象

优劣对比

对CPU资源敏感，回收线程数=(cpu数据+3)/4 CMS无法处理浮动垃圾：在并发清除阶段，用户线程产生的新的垃圾 会产生大量的空间碎片，影响内存使用率，大对象分配很麻烦，空间不足会导致FULL GC

子主题

G1收集器

-XX:+UseG1GC

Garbage-First

并行并发，发挥多核心优势，缩短stop the world时间

分代收集：逻辑分代，不存在老年代新生代

内存分区思路：回收时以分区为单位，基于"标记-整理"减少空间碎片

分区：G1把堆内空间分为若干相等区域，分配对象逐段使用， G1对象的存储并没有要求物理上的连续，逻辑上连续就好

-XX:G1HeapRegionSize=n可指定分区大小(1MB~32MB，且必须是2的幂)

可预测的停顿：G1除了降低线程的停顿时间，还建立了停顿时间模型， 可约定x ms时间片内，最多消耗y ms在垃圾收集上

处理过程

初始标记：STW 标记GCRoots 直连对象

并发标记：多线程并发标记整个分区内GC Roots关联的存活对象

最终标记：STW 标记距离上次STW中间，用户程序继续运行导致的对象关联变化的对象

筛选回收：对各个region回收价值和成本排序，根据用户的设置GC停顿时间来制定回收计划； 因为只回收了一部分region 时间是可控的，效率也比较高

回收模式

Young GC Minor GC

对Eden区域进行GC

eden空间即将耗尽，Eden数据转移到survivor，如果survivor空间不足，则数据直接转移到old空间中， survivor数据也会移动到新的survivor中，部分可能会晋升到old空间中，Eden空间清空，GC结束

过程

阶段1：根扫描  静态和本地对象被扫描 阶段2：更新RS  处理dirty card队列更新RS 阶段3：处理RS  检测从年轻代指向年老代的对象 阶段4：对象拷贝  拷贝存活的对象到survivor/old区域 阶段5：处理引用队列  软引用，弱引用，虚引用处理

Mixed GC Major GC

除了对新生代的对象回收，也对老年代中标记的对象进行回收

过程

全局并发标记 拷贝存活对象

全局标记5步骤

初始标记（initial mark，STW） 在此阶段，G1 GC 对根进行标记。该阶段与常规的 (STW) 年轻代垃圾回收密切相关。 根区域扫描（root region scan） G1 GC 在初始标记的存活区扫描对老年代的引用，并标记被引用的对象。该阶段与应用程序（非 STW）同时运行， 并且只有完成该阶段后，才能开始下一次 STW 年轻代垃圾回收。 并发标记（Concurrent Marking） G1 GC 在整个堆中查找可访问的（存活的）对象。该阶段与应用程序同时运行，可以被 STW 年轻代垃圾回收中断 最终标记（Remark，STW） 该阶段是 STW 回收，帮助完成标记周期。G1 GC 清空 SATB 缓冲区，跟踪未被访问的存活对象，并执行引用处理。 清除垃圾（Cleanup，STW） 在这个最后阶段，G1 GC 执行统计和 RSet 净化的 STW 操作。在统计期间，G1 GC 会识别完全空闲的区域和 可供进行混合垃圾回收的区域。清理阶段在将空白区域重置并返回到空闲列表时为部分并发。

调优

-XX:+UseG1GC -Xmx32g -XX:MaxGCPauseMillis=200

需要在吞吐量跟MaxGCPauseMillis之间做一个平衡。如果MaxGCPauseMillis设置的过小，那么GC就会频繁，吞吐量就会下降。如果MaxGCPauseMillis设置的过大，应用程序暂停时间就会变长。G1的默认暂停时间是200毫秒，我们可以从这里入手，调整合适的时间

FUll GC

G1触发FullGC后，会退化使用serial收集器进行垃圾收集，单线程工作，效率较低，达到秒级，程序造成假死

发生GC情况

并发模式失败 G1启动标记周期，但在MixGC前老年代已经填满，这时G1会放弃标记周期

应对： <ul><li>调整堆大小</li><li>调整周期 = 增加线程数-XX:ConcGCThreads等</li></ul>

晋升失败 or 疏散失败 G1进行GC时候没有足够空间提供给晋升对象，触发FUll GC

a,增加 -XX:G1ReservePercent 选项的值（并相应增加总的堆大小），为“目标空间”增加预留内存量。 b,通过减少 -XX:InitiatingHeapOccupancyPercent 提前启动标记周期。 c,也可以通过增加 -XX:ConcGCThreads 选项的值来增加并行标记线程的数目

巨型对象分配失败

增加内存或者增大-XX:G1HeapRegionSize

大对象的分配

TLAB(Thread Lcoal Allocation Buffer)本地线程分配缓冲区

Eden区中分配

Humongous区中分配

该分区主要存放巨型对象，如果一个放不下，会找连续的分区来存放 没有连续分区，则可能会触发Full GC

Serial收集器             Serial Old收集器 Parallel New收集器  Parallel Old 收集器 ParNew收集器          CMS收集器 G1回收器：逻辑上不区分新老代，          但是每个region可以归属新老代

调优

JVM内存和操作系统内存映射关系

java并发

基础知识

1. 并发编程的优缺点

1. 为什么要用到并发（优点）

充分利用多核CPU的运算能力

方便业务拆分

2.并发编程的缺点

频繁的上下文切换

线程安全（常见的避免死锁的方式）

3. 易混淆的概念

同步 VS 异步

并发 VS 并行

阻塞 VS 非阻塞

临界区资源

2. 线程的状态和基本操作

1. 如何新建线程

继承Thread类

实现Runnable接口

实现Callable接口

几种新建线程方式的比较

2. 线程状态的转换

NEW

RUNNABLE

WAITING

TIMED_WAITING

TERMINATED

BLOCKED

3. 线程的基本操作

interrupt

抛出InterruptedException异常时， 会清除中断标志位

interrupt(), interrupted(), isInterrupt()

sleep

sleep与wait的区别

join

让父线程等待子线程结束之后才能继续运行

yield

yield仅仅只会把时间片让给同 优先级的线程，而sleep没有这个要求

4. 守护线程Daemon

只要当前JVM实例中尚存在任何一个非守护线程没有结束，守护线程就全部工作； 只有当最后一个非守护线程结束时，守护线程随着JVM一同结束工作。 Daemon的作用是为其他线程的运行提供便利服务，守护线程最典型的应用就是 GC (垃圾回收器)，它就是一个很称职的守护者

并发理论（JMM）

1.JMM内存模型

1.哪些是共享数据

实例域

静态域

数组

2.抽象结构

线程将数据拷贝到工作内存，再刷新到主存。 各个线程通过主存中的数据来完成隐式通信

2. 重排序

1.什么是重排序

为了提高执行性能，编译器和处理器会对指令 进行重排序

针对编译器重排序，编译器重排序规则 会禁止一些特定类型的编译器重排序

针对处理器重排序，编译器会在生成指令的时候 插入内存屏障来禁止特定类型的处理器重排序

2. 数据依赖性

int a=1; int b=2; int sum = a+b;//对以上的依赖性

3. as-if-serial

遵守as-if-serial语义的编译器，runtime和处理器共同为编写单线程程序的程序员创建了 一个幻觉：单线程程序是按程序的顺序来执行的

3.happens-before规则

1. 定义

如果A happens-before B，则A操作的结果对操作B可见，且A操作在操作B之前执行

如果指令重排序之后的结果，与按照happens-before关系执行的结果一致， 则指令可以重排序

2.理解

站在程序员角度：为编程人员提供了一个类似强内存的内存结构，方便编程

站在编译器和处理器厂商：在不影响正确结果的前提下，可以让编译器 和处理器厂商尽情优化

3.具体规则

程序顺序规则

volatile变量规则

监视器锁规则

传递性

start规则

join规则

线程中断规则

对象finnalize规则

并发关键字

1.synchronized

1. 如何使用？

实例方法（锁的是实例对象）

静态方法（锁的是类对象）

代码块根据配置，锁的是实例对象也可以是类对象

synchronized,synchronized (this)锁的是对象，synchronized (Demo.class)锁的是方法

2. moniter机制

字节码中会添加monitor enter和monitor exit指令

锁的重入性：同一个锁程，不需要再次申请获取锁

3. synchronized的happens-before关系

不禁止指令重排，保证有序性

4. synchronized的内存语义

共享变量会刷新到主存中，线程每次会从主存中 读取最新的值到自身的工作内存中

5.锁优化

锁状态

无锁状态

偏向锁

当一个线程访问同步块并获取锁时，会在对象头和栈帧中的锁记录里存储锁偏向的线程ID， 以后该线程在进入和退出同步块时不需要进行CAS操作来加锁和解锁， 只需简单地测试一下对象头的Mark Word里是否存储着指向当前线程的偏向锁

适用

始终只有一个线程在执行同步块，在它没有执行完释放锁之前，没有其它线程去执行同步块， 在锁无竞争的情况下使用，一旦有了竞争就升级为轻量级锁

轻量级锁

如持有锁的线程能在很短时间内释放锁资源，那么那些等待竞争锁的线程就不需要做内核态和用户态之间的切换进入阻塞挂起状态， 它们只需要等一等（自旋），等持有锁的线程释放锁后即可立即获取锁，这样就避免用户线程和内核的切换的消耗。

适用

轻量级锁尽可能的减少线程的阻塞，这对于锁的竞争不激烈，且占用锁时间非常短的代码块来说性能能大幅度的提升， 因为自旋的消耗会小于线程阻塞挂起再唤醒的操作的消耗，这些操作会导致线程发生两次上下文切换

重量级锁synchronized

<ul><li>作用于方法时，锁住的是对象的实例(this)；</li><li>当作用于静态方法时，锁住的是Class实例，又因为Class的相关数据存储在永久代PermGen（jdk1.8则是metaspace）， 永久代是全局共享的，因此静态方法锁相当于类的一个全局锁，会锁所有调用该方法的线程；</li><li>synchronized作用于一个对象实例时，锁住的是所有以该对象为锁的代码块。</li></ul>

synchronized与static synchronized 的区别 一个是实例锁（锁在某一个实例对象上，如果该类是单例，那么该锁也具有全局锁的概念）， 一个是全局锁（该锁针对的是类，无论实例多少个对象，那么线程都共享该锁）。 实例锁对应的就是synchronized关键字，而类锁（全局锁）对应的就是static synchronized （或者是锁在该类的class或者classloader对象上）。

CAS操作

是一种乐观锁策略

利用现代处理器的CMPXCHG

存在ABA的问题；自旋时间可能过长的问题

JAVA对象头

对象的hashcode

对象的分代年龄

是否是偏向锁的标志位

锁标志位

6. 锁升级策略

轻量级锁

加锁：在对象头和栈帧的锁记录中，添加自身的线程ID

锁撤销：在全局安全点上进行

轻量级锁

加锁：Displace mark word，对象头mark word通过CAS指向栈中锁记录

锁撤销：如果CAS替换回对象头失败，则升级成重量级锁

重量级锁

各种锁的比较

reentrantlock

2. volatile

1.实现原理

写volatile变量在编译时添加Lock指令

缓存一致性：每个处理器会通过总线嗅探出自己的 工作内存中数据是否发生变化

特性

保证可见性

不保证原子性

保证不了线程安全

禁止指令重排

2.happens-before关系的推导

A happens before B,B happens before C, 则 A happens before C

3.内存语义

写volatile变量会重新刷新到主存中，其他线程读volatile变量 会重新从主存中读取最新值

4.内存语义的实现

通过在特定位置处插入内存屏障来防止重排序

3.final

1.如何使用

变量

基本类型

类变量（static变量）：只能在声明时赋值或者 在静态代码块中赋值

实例变量：声明时赋值，构造器以及非静态代码块中赋值

局部变量：有且仅有一次赋值机会

引用类型

final修饰的引用类型只保证引用的对象地址不变，其对象 的属性是可以改变的

方法

被final修饰的方法不能被子类重写，但是可以被重载

类

被final修饰的类，不能被子类继承

2. final的重排序规则

final域为基本类型

禁止对final于的写重排序到构造函数之外

禁止读对象的引用和读该对象包含的final域重排序

final域为引用类型

对一个final修饰的对象的成员域的写入，与随后在构造函数之外 把这个被构造的对象的引用赋给一个引用变量，这两个操作是不能被重排序的

3. final实现原理

插入StoreStore和LoadLoad内存屏障

4. finla引用不能从构造函数函数中“溢出”(this逃逸)

4.三大性质

原子性

synchronzied

可见性

synchronized

volatile

有序性

synchronized

volatile

Lock体系

1. Lock与synchronized的比较

Lock提供了基于API的可操作性，提供能可响应中断式 获取锁，超时获取锁以及非阻塞式获取锁的特性

synchronized执行完同步块以及遇到异常会自动释放锁， 而Lock要显示的调用unlock方法释放锁

2. AQS

1. 设计意图（模板方法设计模式）

AQS提供给同步组件实现者，为其屏蔽了同步状态的管理，线程排队等底层操作 实现者只需要通过AQS提供的模板方法实现同步组件的语义即可

lock（同步组件）是面向使用者的，定义了接口， 隐藏了实现细节

2. 如何使用AQS实现自定义同步组件

重写protected方法，告诉AQS如何判断当前 同步状态获取是否成功或者失败

同步组件调用AQS的模板方法，实现同步语义。而提供的模板方法 又会调用被重写的方法

实现自定义同步组件时，推荐采用继承AQS的静态内部类

3. 可重写的方法

4. AQS提供的模板方法

3. AQS源码解析

1. AQS同步队列的数据结构

带头结点的双向链表实现的队列

2. 独占式锁

同步状态获取成功则退出；失败则通过addWaiter方法将当前线程 封装成节点加入同步队列，acquireQueued方法使得当前线程等待获取同步状态

如果获取同步状态并且是同步队列中的头结点，则表明获取锁成功， 并唤醒后继结点

可响应中断式获取锁以及超时获取锁特性的实现原理

3.共享式锁

锁获取原理

锁释放原理

可响应中断式获取锁以及可超时获取锁特性的实现原理

4.ReentrantLock

1.重入锁的实现原理

2.公平锁的实现原理

3.非公平锁的实现原理

4.公平锁和非公平锁的比较

加锁/释放过程

5.ReentrantReadWriteLock

1.如何表示读写状态的

低16位用来表示写状态，高16位用来表示读状态

如果有一个线程已经占用了读锁，则此时其他线程如果要申请读锁，可以申请成功。 如果有一个线程已经占用了读锁，则此时其他线程如果要申请写锁，则申请写锁的线程会一直等待释放读锁，因为读写不能同时操作。 如果有一个线程已经占用了写锁，则此时其他线程如果申请写锁或者读锁，都必须等待之前的线程释放写锁，同样也因为读写不能同时，并且两个线程不应该同时写。

2.WriteLock的获取和释放

当ReadLock已经被其他线程获取或者WriteLock被其他线程获取，当前线程 获取WriteLock失败；否则获取成功。支持重入性

WriteLock释放时将写状态通过CAS操作减一

3.ReadLock的获取和释放

当WriteLock已经被其他线程获取的话，ReadLock获取失败；否则获取成功。支持重入性

通过CAS操作将读状态减一

4.锁降级策略

按照WriteLock.lock()-->ReadLock.lock()-->WriteLock.unlock()的顺序，WriteLock会降级为ReadLock

5.生成Condition等待队列

WriteLock可以通过newCondition方法生成Condition等待队列， 而ReadLock无法生成Conditon等待队列

6.应用场景

适用于读多写少的应用场景，比如缓存设计上

6. Condition机制

1.与Object的wait/notify机制相比 具有的特性

Condition能够支持不响应中断，而Object不支持

Lock能够支持多个Condition等待队列，而Object只能支持一个

Condition能够支持设置超时时间的await，而Object不能

2.与Object的wait/notify相对应的方法

针对Object的wait方法：await, awaitNanos,...

针对Object的notify/notifyAll方法：signal，signalAll方法

3.底层数据结构

复用AQS的Node类，由不带头结点的链表实现的队列

4. awiat实现原理

将调用await方法的线程封装成Node，尾插入到同步队列中，并通过LockSupport.park方法 将当前线程置于WAITING状态，直至其他线程通过signal/signalAll方法将其移入到同步队列中， 使其有机会在同步队列中通过自旋获取到Lock，从而当前线程才能从await方法处退出

5.signal/signalAll实现原理

将等待队列的队头结点移入到同步队列中

6. await和signal/signalAll的结合使用

7.LockSupport

1. 主要功能

可阻塞线程以及唤醒线程，功能实现依赖于Unsafe类

2. 与synchronized阻塞唤醒相比具有的特色

LockSupport通过LockSupport.unpark(thread)可以指定 哪个线程被唤醒，而synchronized不能

并发容器

1. concurrentHashMap

1. 关键属性

table：元素为Node类的哈希桶数组

nextTable：扩容时的新数组

sizeCtl：控制数组的大小

Unsafe u：提供对哈希桶数组元素的CAS操作

2. 重要内部类

Node：实现Map.entry接口，存放key，value

TreeNode：继承Node，会被封装成TreeBin

TreeBin：进一步封装TreeNode，链表过长时转换成红黑树时使用

ForwardingNode：扩容时出现的特殊结点

3. 涉及到的CAS操作

tabAt：查询哈希桶数组的元素

casTabAt：设置哈希桶数组中索引为i的元素

setTabAt：设置哈希桶数组中索引为i的元素

4. 构造方法

数组长度总是会保证为2的幂次方

5. put执行流程

1.如果当前数组还未初始化，先进行初始化

2.spread方法重哈希（高16位和低16位异或操作），将哈希值与数组长度与运算，确定待插入结点的索引为i

3.当前哈希桶中i处为null，直接插入

4. i处结点不为null的话并且结点hash>0，说明i处为链表头结点。遍历链表，遇到与key相同的结点则覆盖其value， 如果遍历完没有找到，则尾插入新结点

5. i处结点不为null的话并且结点状态为MOVED，则说明在扩容，帮助扩容

6.i处结点不为null的话并且结点位TreeBin，则使用红黑树的方式插入结点

7. 插入新结点后，检查链表长度是否大于8，若大于，则转换成红黑树

8. 检测数组长度，若超过临界值，则扩容

6. get执行流程

7. 扩容机制

8. 用于统计size的方法的执行流程

9. 1.8版本的ConcurrentHashMap与之前版本的比较

减小锁粒度

采用了synchronized而不是lock，大量使用CAS操作

2. CopyOnWriteArrayList

1. 实现原理

利用了读写分离的思想；当写线程写入数据的时候会复制新建一个新容器，当数据更新完成 后，再将旧容器引用指向新容器。读线程感知数据更新是延时的，也就是说COW是牺牲了 数据实时性而保证数据最终一致性

由于写线程写数据是在新容器写入的，因此读线程不会被阻塞

2. COW和ReentrantReadWriteLock的区别

相同点

1. 两者都采用了读写分离的思想，并且读和 读线程之间都不会被阻塞

不同点

1. 当写线程在写数据时，ReadWriteLock会阻塞读线程，而 由于COW采用了延时更新的策略，COW并不会阻塞读线程

ReadWriteLock保证了数据实时性而COW保证数据最终一致性

3. 应用场景

适用于读多写少的场景，比如系统的黑名单，白名单设置

4. 为什么具有弱一致性

COW的实现是采用数组，而数组的引用是volatile修饰，但是数组的元素并不是 volatile的。因此数据更新只有当volatile引用指向新数组时才会生效

5. COW的缺点

由于在写数据时，会复制，因此可能会出现内存使用瞬间增加， 导致minor GC和major GC

只具有数据最终一致性，对数据实时性要求高的场景不合适

3. ThreadLocal

1. 实现思想

采用“空间换时间的”思想，每个线程拥有变量副本，达到 隔离线程的目的，线程间不受影响解决线程安全的问题

2. set方法原理

数据存放在由当前线程Thread维护的ThreadLocalMap中，数据结构为 当前ThreadLocal实例为key，值为value的键值对

3. get方法原理

以当前ThreadLocal为键，从当前线程Thread维护的ThreadLocalMap中获取value

4. remove方法原理

从当前线程Thread维护的ThreadLocalMap中删除以当前ThreadLocal实例为键的键值对

5. ThreadLocalMap

底层数据结构

键为ThreadLocal实例，值为value的Entry数组

数组大小为2的幂次方

键ThreadLocal为弱引用

set方法原理

1. 计算ThreadLocal的hashcode

总是加上0x61c88647，这是“Fibonacci Hashing”

2. 计算待插入的索引为i

采用与运算

3.如何解决hash冲突

当索引为i处有Entry的话（hash冲突），就采用线性探测，进行环形搜素

4. 加载因子

ThreadLocalMap初始大小为16，加载因子为2/3

5. 扩容resize

容量为原数组大小的两倍

getEntry方法原理

根据ThreadLocal的hashcode进行定位，如果所定位的Entry的key 与所查找的key相同则直接返回，否则，环形向后继续探测。

remove原理

先找到对应的entry，然后让它的Key为null，之后再对其进行清理

6. ThreadLocal内存泄漏

造成内存泄露的原因

由于ThreadLocal在Entry中是弱引用，当外部ThreadLocal实例被置为null后，根据可达性分析， 堆中ThreadLocal不可达，会被GC掉，因此就存在key为null的entry。无法通过key为null去访问entry， 因此，就会存在threadRef->currentThread->threadLocalMap->entry->valueRef->valueMemory引用链 造成valueMemory不会被GC掉，造成内存泄漏

怎样来解决内存泄漏

关键方法cleanSomeSlots，expungeStaleEntry，replaceStaleEntry

在ThreadLocal的set，getEntry以及remove方法中都利用以上三个关键方法 对潜在的内存泄漏进行处理

为什么要使用弱引用

如果使用强引用的话，即使显示对ThreadLocal的实例置为null的话，由于Thread，ThreadLocal以及 ThreadLocalMap引用链关系，ThreadLocal也不会被GC掉，反而会程序员带来困扰；

使用弱引用，尽管存在ThreadLocal内存泄漏的危险，但实际上已经对其进行了处理

7. ThreadLocal的最佳实践

使用完ThreadLocal后要remove掉

8. 应用场景

hibernate管理seesion，每个线程维护其自身的session，彼此不干扰

用于解决对象不能被多个线程共享的问题

BlockingQueue

1.BlockingQueue的基本操作

2. 常用的BlockingQueue

ArrayBlockingQueue：由数组实现的有界阻塞队列

LinkedBlockingQueue：由链表实现的有界阻塞队列，可指定长度，如果没有指定则为Integer.MAX_VALUE

PriorityBlockingQueue：支持优先级的无界阻塞队列

SynchronousQueue：不存储任何元素阻塞队列

LinkedTransferQueue：由链表实现的无界阻塞队列

LinkedBlockingDeque：由链表实现的无界阻塞队列

DelayQueue：存在实现了Delayed接口的数据的无界阻塞队列

3. ArrayBlockingQueue与LinkedBlockingQueue 实现原理

会有notFull和notEmpty两个等待队列，分别存放 被阻塞的插入数据线程以及被阻塞的消费数据的线程

ArrayBlockingQueue只有一个lock，而LinkedBlockingQueue有两个lock， 因此LinkedBlockingQueue的并发度更高，吞吐量更大

通过put和take方法了解生产者-消费者的正确写法

ConcurrentLinkedQueue

1. 实现原理

主要采用CAS操作以保证线程安全，并且采用了延时更新的策略，提高吞吐量

2. 数据结构

由Node构成的链式队列

3. 核心方法

offer方法实现原理

poll方法实现原理

4. HOPS延迟更新的设计意图

尽可能的减少CAS操作，以提升吞吐量和执行效率

线程池（Executor体系）

1. ThreadPoolExecutor

1. 为什么要使用线程池

降低资源损耗

提升系统响应速度

提高线程的可管理性

2. 执行流程

核心线程corePool，阻塞队列workQueue以及最大线程池maxPool三级缓存的工作方式

3. 构造器各个参数的意义

coolPoolSize：核心线程池的大小

maximumPoolSize：线程池最大容量

keepAliveTime：空闲线程可存活时间

线程数量>coolPoolsize+queueSize,，会创建 maxPoolSize-coolPoolSize的任务， 这些线程是借的，有时间限制

unit：keepAliveTime的时间单位

workQueue：存放任务的阻塞队列

threadFactory：生产线程的工厂类

handler：饱和丢弃策略。共四种： AbortPolicy，CallerRunsPolicy，DiscardPolicy，DiscardOldestPolicy

4. 如何关闭线程池

shutdown：正在执行任务的线程，将任务执行完。空闲线程以中断的方式关闭

shutdownNow：停止所有线程，包括正在执行任务的线程。返回未执行的任务列表

showdown将线程池状态设置为SHUTDOWN，而shutdownNow将线程池状态设置为STOP

isTerminated来检查线程池是否已经关闭

5. 如何配置线程池

CPU密集型：Ncpu+1

IO密集型：2Ncpu

任务按照IO密集型和CPU密集型进行拆分

2. ScheduledThreadPoolExecutor

1. UML（类结构）

继承了ThreadPoolExecutor，并实现了ScheduledExecutorService

2. 常用方法

可延时执行任务：schedule(.....)

可周期执行任务：scheduledAtFixedRate(...)和scheduledWithFixedDelay

scheduledAtFixedRate和scheduledWithFixedDelay的区别：...AtFixedRate不要求任务结束 了才开始统计延时时间，而....WithFixedDelay要求从任务结束开始统计延时时间

3. ScheduledFutureTask

可周期执行的异步任务，每一次执行完后会重新设置任务下一次执行的任务， 并且会添加到阻塞队列中

4. DelayedWorkQueue

按优先级排序的有界阻塞队列，底层数据结构是堆

3. FutureTask

1. FutureTask的几种状态

未启动（还未执行run方法），已启动(已执行run方法），已结束（正常结束，被取消，出现异常）

2. get()

未启动和已启动状态，get方法会阻塞当前线程直到异步任务执行结束

3. cancel()

未启动状态时，调用cancel方法后该异步任务永远不会再执行

已启动状态，调用cancel方法后根据参数是否中断当前执行任务的线程

已结束状态，调用cancel方法时会返回false

4. 应用场景

当一个线程需要等到另一个任务执行结束后才能继续进行时，可以使用futureTask

5. 实现了Runnable接口

futureTask同样可以交由executor执行，获取直接调用run方法执行

原子操作类

1. 实现原理

借住与Unsafe类的CAS操作，达到并发安全的目的

2. 原子更新基本类型

AtomicInteger， AtomicLong，AtomicBoolean

3. 原子更新数组类型

AtomicIntegerArray，AtomicLongArray，AtomicReferenceArray

4. 原子更新引用类型

AtomicReference，AtomicReferenceFieldUpdater，AtomicMarkableReference

5. 原子更新字段类型

AtomicIntegerFieldUpdater，AtomicLongUpdater，AtomicStampedReference

并发工具

1. 倒计时器CountDownLatch

当CountDownLatch维护的计数器减至为0的时候，调用await方法的线程 才会继续往下执行，否则会阻塞等待

适用于一个线程需要等待其他多个线程执行结果的应用场景

2. 循环栅栏CyclicBarrier

当一组线程都达到了“临界点”时，所有的线程才能继续往前执行，否则 阻塞等待

3. CountDownLatch和CyclicBarrier的比较

1. CyclicBarrier能够复用，而CountDownLatch维护的倒计数器不能复用

2. CyclicBarrier会在await处阻塞等待，而CountDownLatch在await出不会阻塞等待

3. CyclicBarrier提供了例如isBroken，getNumerWaiting等方法能够 查询当前状态，而CountDownLatch提供的方法较少

4. 资源访问控制Semaphore

适用于对特定资源需要控制能够并发访问资源的线程个数。需要先执行acquire方法获取 许可证，如果获取成功后线程才能往下继续执行，否则只能阻塞等待；使用完后需要 用release方法归还许可

5. 数据交换Exchanger

为两个线程提供了一个同步点，当两个线程都达到了同步点之后就可以使用exchange方法，互相交换数据； 如果一个线程先达到了同步点，会在同步点阻塞等待直到另外一个线程也到达同步点

并发实践

生产者-消费者问题

1.使用Object的wait/notifyAll方式实现

使用Object的消息通知机制可能存在的问题

notify过早，wait线程无法再获取到通知以至于 一直阻塞等待。解决办法：添加状态标志

wait条件变化。解决方法：使用while进行wait条件的判断，而不是 在if中进行判断

“假死”状态：使用notifyAll而不是notify

标准范式

永远在while中对wait条件进行判断，而不是在if中进行判断

使用notifyAll进行通知，而不要使用notify进行通知

2.使用lock的condition的await/signalAll方式实现

3. 使用blockingQueue方式实现

由于BlockingQueue有可阻塞的插入和删除数据的put和take方法，因此，在实现上 比使用Object和lock的方式更加简洁

java线程和操作系统线程的关系

子主题

运维统计

常规监控

监控

定义

通过技术手段发现服务异常情况，持续优化业务可用性与用户体验

方式

主动：代码埋点，服务主动上报自身运行情况， 优点：可以细化到具体业务属性，快准狠 缺点：代码侵入，有成本

无侵入：无需埋点，从外部探测服务运行情况，如：ping探测，端口检测，日志采集

旁路检测：与程序逻辑无关，对服务质量与口碑的监控，如舆情监控

指标

种类

基础监控

监控范围较广，主要包括IASS层（服务器，系统，网络等）

服务端监控

一般指后台服务，如QQ的后台消息服务，商城订单服务

客户端监控

指app

WEB端监控

对网站 实施域名的拨测

目标

全、快、准

核心目标

请求量

成功率

耗时

常用监控软件

Zabbix

适合85%以上的泛互联网企业。

Nagios

适合复杂IT环境的企业

Ganglia

适合大型服务集群监控

Zenoss

企业级智能监控软件

Open-falcon

小米开源

监控宝

移动监控服务产品

360网站服务监控

站长免费使用，提供http监控、ping监控、域名dns监控、服务器监控

阿里云监控

阿里云用户

百度云观测

个人站长可用

promethus

JVM性能调优监控工具

jps

-q 不输出类名、Jar名和传入main方法的参数 -m 输出传入main方法的参数 -l 输出main类或Jar的全限名 -v 输出传入JVM的参数

root@ubuntu:/# jps -m -l 2458 org.artifactory.standalone.main.Main /usr/local/artifactory-2.2.5/etc/jetty.xml 29920 com.sun.tools.hat.Main -port 9998 /tmp/dump.dat 3149 org.apache.catalina.startup.Bootstrap start 30972 sun.tools.jps.Jps -m -l 8247 org.apache.catalina.startup.Bootstrap start 25687 com.sun.tools.hat.Main -port 9999 dump.dat 21711 mrf-center.jar

jstack

$ ps -ef | grep inyu-admin  #获取应用进程 top -Hp 2115 #获取最耗cpu资源的线程  $ pstree -p 2115 #属性显示进程关系 printf "%x\n" 2115 #线程id转16进制 $jstack 2115 | grep  843 # 获取进程堆栈信息 #可定位到代码协助排查故障

jmap jhat

jmap -permstat pid #打印类加载器持久代信息 jmap -heap 21711   #打印堆内存占用情况，GC算法等 jmap -dump:format=b,file=/tmp/dump.dat 21711 #dump进程内存信息到文件协助排查问题，可用MAT、VisualVM等工具查看

jstat

jstat -gc pid  250 4    # 间隔为250ms，采样数为4：

inux系统下的最常用性能工具

top

可以查看机器CPU，内存这些情况

vmstat

可对操作系统的虚拟内存、进程、CPU活动进行监控

nload

网卡流量监控工具

iftop

是类似于top的实时流量监控工具。

APM-Application Performance Management

背景：互联网业务调用愈加复杂，大规模集群业务模块之间互相调用，且不同业务可能使用的开发语言各不相同， apm可以帮助分析系统性能，理解系统行为。 目前市场上的apm系统大多是模仿谷歌的Dapper

APM核心功能

应用系统存活检测

系统指标占用检测(CPU/内存)

业务关键时间检测

服务调用跟踪

智能监控告警

监测数据持久化存储

关键技术

获取JVM关键数据

服务调用追踪

时间序列-profile

告警

开源技术

分布式跟踪系统：Zipkin

http://blog.csdn.net/manzhizhen/article/details/52811600

大众点评网 CAT

Prometheus

开源的系统监控和报警工具，最初由SoundCloud推出

Hawkular

功能完备的APM系统，应用程序中嵌入Hawkular客户端，主动将采集数据通过Http或者Kafka传递给Hawkular

Pinpoint

国开源的一个功能完备的APM系统，支持JVM性能数据采集、服务Trace、告警等功能。

Appdash

用Go实现的分布式系统跟踪工具套件

Apache HTrace

Cloudera开源出来的一个分布式系统跟踪框架，支持HDFS和HBase等系统。该项目目前还在孵化阶段

京东Ｈydra

京东开源的基于Dubbo的调用分布跟踪系统，类似ZipKin，功能不够完善。

Cicada

宜人贷开源的类似ZipKin分布式跟踪系统，功能不够完善

Spring Boot Admin

监控数据不能持久化存储，没有Trace功能，没有监控告警功能，但可周期性采集metrics， 发送给其他监控软件如slack进行告警处理，同时也可以实现监控数据存储

统计分析

埋点

所谓埋点就是在应用中特定的流程收集一些信息，用来跟踪应用使用的状况，后续用来进一步优化产品或是提供运营的数据支撑， 包括访问（Visits），访客（Visitor），停留时间（Time On Site），页面查看（Page Views，又称为页面浏览）和 跳出率（Bounce Rate，又可称为蹦失率）。这样的信息收集可以大致分为两种：页面统计（track this virtual page view）， 统计操作行为（track this button by an event）。

数据埋点的方式

产品研发过程中注入代码统计，并搭配相应的后台系统

前端埋点

后端埋点

接入第三方的统计平台：友盟，魔方，百度移动等

美团点评埋点案例

https://tech.meituan.com/2017/03/02/mt-mobile-analytics-practice.html

要求：准确性、及时性、埋点效率&开发效率、动态部署&修复能力

声明式埋点

将埋点代码和具体的交互和业务逻辑解耦，开发者只用关心需要埋点的控件， 并且为这些控件声明需要的埋点数据即可，从而降低埋点的成本

无痕埋点

声明埋点事件的唯一事件id，然后通过某种方式将业务和埋点数据关联实现

持续集成(CI/CD)

持续

频繁多次的将代码集成到master

流程

提交-测试-构建-测试-部署-回滚

优点

快速发现错误 防止分支偏离主干太多

目的

可以快速迭代，同时可以保持高质量

持续交付

交付给质量团队或者用户

持续部署

交付完成后即可部署到生产环境

Jenkins

https://www.liaoxuefeng.com/article/1083282007018592

环境分离

自动化运维工具

Ansible

https://www.cnblogs.com/heiye123/articles/7855890.html

puppet

https://www.cnblogs.com/keerya/p/8040071.html#_label0

chef

https://www.ibm.com/developerworks/cn/cloud/library/1407_caomd_chef/

开发：线下开发用到服务器，错误较多 测试：copy线上的配置测试 预发：一般和线上同数据库，环境真实，预防问题发生 生产：真实环境

测试

TDD理论

what

单元测试驱动开发

三层含义

Test-Driven Development，测试驱动开发。 Task-Driven Development，任务驱动开发，要对问题进行分析并进行任务分解。 Test-Driven Design，测试保护下的设计改善。TDD 并不能直接提高设计能力， 它只是给你更多机会和保障去改善设计

why

基于测试用例编码功能代码，XP（Extreme Programming）的核心实践.

一次关注一点，降低开发者负担

迎接需求变化或改善代码涉及，提前澄清需求

快速反馈

how

先写测试代码，后开发

单元测试

单元测试的标准

单元测试应该在最低的功能/参数上验证程序的正确性

单元测试过后，机器状态保持不变。

单元测试要快（一个测试运行时间是几秒钟，而不是几分钟）

单元测试要多次运行结果一致

单元测试的运行成功/失败/取消不依赖其他的用例，要体现独立性

单元测试应该覆盖所有代码路径(包括错误路径，公开|私有方法)，保证覆盖率

应该集成到自动化测试框架中

单元测试应该和代码一起维护保存

测试框架

JUnit

TestNG

其他

单元测试功能点

模块接口测试

局部数据结构测试

路径测试

错误处理测试

边界条件测试

集成测试

集成测试界于单元测试和系统测试之间，起到“桥梁作用”， 一般由开发小组采用白盒加黑盒的方式来测试，既验证“设计”，又验证“需求”

压力测试

压力测试确立系统稳定性的一种测试方法,在软件工程、金融风险管理等领域应用比较普遍。 通常在系统正常运作范围之外进行,以考察其功能极限和隐患

全链路压测

A/B、灰度、蓝绿测试

虚拟化

KVM

Xen

OpenVZ

容器技术

Docker

云技术

OpenStack

文档管理

DevOps

网络

网络模型

IO

特点

当一个线程调用read() 或 write()时，该线程被阻塞，直到有一些数据被读取，或数据完全写入

场景

长连接，大批量数据传输

BIO

采用BIO通信模型的服务端，通常由一个独立的Acceptor线程负责监听客户端的连接， 它接收到客户端连接请求之后为每个客户端创建一个新的线程进行链路处理处理完成后， 通过输出流返回应答给客户端，线程销毁。即典型的一请求一应答通宵模型。

伪异步I/O编程：Acceptor 采用线程池替换

IO多路复用

NIO

Channel

Buffer

Selector

是select/epoll/poll的外包类，在不同的平台可能有不同的实现

poll()/epoll()方法主要是监控文件描述符(内核设置状态反馈)

特点

使用一个线程发送读取数据请求，没有得到响应之前，线程是空闲的， 此时线程可以去执行别的任务，而不是像IO中那样只能等待响应完成

场景

短链接，小数据量传输

三种模型

Reactor单线程模型

Reactor多线程模型

主从Reactor多线程模型

AIO

须直接调用API的read或write方法即可，会返回一个带回调函数的对象

对于读操作而言，当有流可读取时，操作系统会将可读的流传入read方法的缓冲区，并通知应用程序； 对于写操作而言，当操作系统将write方法传递的流写入完毕时，操作系统主动通知应用程

高性能IO设计

Reactor模式/Proactor模式

http://www.kuqin.com/ace-2002-12/Part-One/Chapter-8.htm http://blog.csdn.net/russell_tao/article/details/17452997

EPoll Selector

selector将用户关心的描述符集合（bitmap）拷贝到内核中，内核轮询这个集合,并更改描述符标识符

<ul><li>selector最大描述符数1024，随着数量增大，轮询耗时严重</li></ul>

epoll改进了slector，将描述符集合放在红黑树，另外保存一个list存放socket和事件：事件回调机制，不用再轮询

<ul><li>epoll没有描述符数量限制</li></ul>

协议

OSI七层网络协议

https://www.cnblogs.com/Robin-YB/p/6668762.html

TCP/IP

四层模型

链路层：对0/1机型分组，定义数据帧。却让主机的物理地址，传输数据

网络层：定义IP地址，确认主机的网络位置，通过IP和MAC寻址，对网络数据包机型路由转发

传输层：定义端口，确认主机上应用程序的身份，并将数据交给对应的程序处理

应用层：定于数据格式，并按照格式解读展示数据

三次握手/四次挥手

https://blog.csdn.net/whuslei/article/details/6667471/

HTTP

子主题

HTTP2.0

HTTPS

TCP/UDP

TCP为什么是三次握手，不是两次？

Tcp是面向连接的，传输层通信协议 Udp是无连接的，不可靠的、传输层通信协议

安全

设计思想

中间件

消息中间件

消息队列

点对点

生产者发布一条消息到quene，quene中消息只能被一个客户端消费，消费后不保存消息

发布订阅

TOPIC：发布到topic的消息会被所有订阅者消费

发布订阅模式下，当发布者消息量很大时，显然单个订阅者的处理能力是不足的。 实际上现实场景中是多个订阅者节点组成一个订阅组负载均衡消费topic消息即分组订阅，这样订阅者很容易实现消费能力线性扩展。

优点

异步 可恢复性 灵活&峰值处理 缓存

中间件

kafka

Kafka只支持消息持久化，消费端为拉模型，消费状态和订阅关系由客户端端负责维护，消息消费完后不会立即删除，会保留历史消息。 因此支持多订阅时，消息只会存储一份就可以了。但是可能产生重复消费的情况。

点对点

pub/sub

概念

Broker

一个kafka集群由一个或多个broker构成

Topic

简单理解为消息的类别，或者为消息的队列

Partition

一个topic可以由一个或多个partition构成

Producer

消息生产者

Consumer

消息消费方，每个consumer都有consumer group(未指定则默认)， 同一个Topic的消息只能由一个consumer group中的一个consumer消费， 多个consumer group可以重复消费

核心概念

消息存储

消息消费后需要删除？

1.防止重复消费 2.保证消息队列有足够的空间，并提高利用效率

kafka的消息无论是否消费都有保存

kafka的消息存储也有有限制，超出限制也要删除

1.基于时间删除/ 删除一周前的数据 2.基于空间删除/ 文件超过1G后删除旧的数据

配置可在config/server.properties中配置

RabbitMQ

基于AMQP协议（Advanced Message Queue Protocol）

高级消息队列协议（AMQP1）是一个异步消息传递所使用的应用层协议规范。 作为线路层协议，而不是API（例如JMS2），AMQP客户端能够无视消息的来源任意发送和接受信息。

点对点

生产端通过路由规则发送消息到不同queue，消费端根据queue名称消费消息。 RabbitMQ既支持内存队列也支持持久化队列，消费端为推模型，消费状态和订阅关系由服务端负责维护， 消息消费完后立即删除，不保留历史消息。

发布订阅

当RabbitMQ需要支持多订阅时，发布者发送的消息通过路由同时写到多个Queue，不同订阅组消费不同的Queue。 所以支持多订阅时，消息会多个拷贝。

rabbitMq和Kafaka对比

https://mp.weixin.qq.com/s/kEWZLhEWtd5H8t0pjBtHwg

RocketMQ

基础概念

NameServer

担当注册中心角色，支持集群化部署，保证高可用

保存有Topic-Queue路由配置信息 保存有Broker配置信息

consumer可以从NameServer获取broker的地址来获取信息

Broker

Broker向所有的注册，定时心跳(30s)

子主题

Broker和NameServer保持心跳通过tcp

<ul><li>broker同时支持消息的查询</li><li>集群内的broker间不通信</li><li>broker会将消息的TOPIC配置同步到NameServer</li></ul>

集群部署：master和slave同步方式

slave不停的向master发消息拉取数据更新

broker支持读写分离么？

消息写入一般都是master

消息的读取可以是master或者slave

master broker宕机？

4.5之前不会自动从master切到slave，需要手动切重启服务，导致服务一段时间不可用

-Dledger可以实现RocketMQ的高可用主从自动切换效果

-在master宕机后Dledger会在slave机器中选举一个新的leader，耗时10s左右，

Topic

消息类型的集合，再写入或读取消息前，都要确认关联的topic

Consumer

从NameServer拉取对应Topic关联Broker列表

消息读取过程:向broker发送请求，获取消息，broker判断从master或者slave获取消息

如当前master消息同步slave尚未完成，则从master获取

如当前从master获取消息的客户端数量较大，并发情况，则会分部分请求到slave获取

<strong style="margin: 0px; padding: 0px; max-width: 100%; color: rgb(51, 51, 51); font-family: -apple-system-font, BlinkMacSystemFont, "Helvetica Neue", "PingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif; font-size: 14px; text-align: justify; box-sizing: border-box !important; overflow-wrap: break-word !important;">Producer

从NameServer拉取Broker列表

Producer和NameServer建立Tcp链接， 在发送消息前获取Topic关联的broker注册信息， 再根据负载均衡的策略获取需要链接的broker地址， broker获取到消息，主从同步消息

模式：

单机开发测试

<ul><li>镜像集群模式</li></ul>

案例

如何发送有序消息

ActiveMQ

基于STOMP协议（注：我只知道是基于JMS）

Java消息服务（Java Message Service，JMS）应用程序接口是一个Java平台中关于面向消息中间件（MOM）的API， 用于在两个应用程序之间，或分布式系统中发送消息，进行异步通信。点对点与发布订阅最初是由JMS定义的

消息推送方式

push

如果消费方能力弱，容易造成消息积压

prefetch limit 设置消息推送限制，具体数量视情况而定

消息消费后，返回ACK后，推送下一条消息 ack反馈，可设置消费一条反馈一次，消费一批反馈一次(提高效率)

如果prefetchACK为true，那么prefetch必须大于0；当prefetchACK为false时，你可以指定prefetch为0以及任意大小的正数。 不过，当prefetch=0是，表示consumer将使用PULL(拉取)的方式从broker端获取消息，broker端将不会主动push消息给client端， 直到client端发送PullCommand时； 当prefetch>0时，就开启了broker push模式，此后只要当client端消费且ACK了一定的消息之后，会立即push给client端多条消息

pull

prefectLimit=0，则模式为pull 客户端拉取模式

同步获取消息

ActiveMQMessageConsumer的receive()方法

异步获取消息

消费者实现MessageListener接口，监听消息

消息顺序

保证消息消费有序

消息发送有序

通信

Dubbo

Alibaba开源的分布式服务框架，它最大的特点是按照分层的方式来架构，使用这种方式可以使各个层之间解耦合（或者最大限度地松耦合）

核心配置

dubbo:service

服务配置-发布一个服务

用户定义服务元信息，一个服务可以用多个协议暴露，一个服务也可以注册到多个注册中心

dubbo:reference

服务饮用配置

创建一个远程服务代理，一个服务可以指向多个注册中心

dubbo:protocol

协议配置

配置提供服务的协议信息，协议由提供方指定，消费方被动接收

dubbo:application

应用配置

配置当前应用信息

dubbo:module

应用模块

可空

dubbo:registry

注册中心

链接注册中心的配置信息

duubo:monitor

监控中心

用于配置监控中心的配置-可空

dubbo:consumer

服务消费方配置

dubbo:provider

服务提供方

dubbo:method

服务方法的配置

dubbo:argument

参数配置

支持的协议

dubbo-默认

dubbo缺省协议，采用一长连接和NIO异步通讯，适用于小数据量大并发的服务调用 以及消费机器远大于服务提供方的情况

不适合传送大数据量的服务，如文件视频等，除非请求量很低

<dubbo:provider protocol="dubbo" />  <dubbo:service protocol="dubbo" />

RMI

采用jdk标准实现，采用的阻塞式短链接和jdk标准序列化

多连接-短连接-tcp协议，同步传输

如使用rmi提供服务，且应用依赖common-collections包，存在反序列化安全风险

<dubbo:protocol name="rmi" port="1099" />  <dubbo:provider protocol="rmi" />  <dubbo:service protocol="rmi" />

http

基于http表单的远程调用协议

多链接-短链接-http协议-同步传输

<dubbo:protocol name="http" port="8080" />  <dubbo:protocol ... server="jetty" />  <dubbo:protocol ... server="servlet" />

webservice

基于webservice的远程调用协议，可以和标准webService交互

多连接-短连接-HTTP-同步传输

<dubbo:protocol name="webservice" port="8080" server="jetty" />  <dubbo:provider protocol="webservice" />  <dubbo:service protocol="webservice" />

hessian

Hession协议用于集成Hession服务，底层采用Http通讯，采用Servlet暴露服务，Dubbo缺省内嵌Jetty作为服务器实现

dubbo的Hession服务和标准的Hession服务可以直接交互

特点-多链接/短链接/http/同步传输

<dubbo:protocol name="hessian" port="8080" server="jetty" />  <dubbo:provider protocol="hessian" />  <dubbo:service protocol="hessian" />

thrift

基于原生thrift协议的扩展

memcached

基于memcached的rpc协议

redis

基于 Redis实现的 RPC 协议

注册

RegistryFactory registryFactory = ExtensionLoader.getExtensionLoader(RegistryFactory.class).getAdaptiveExtension(); Registry registry = registryFactory.getRegistry(URL.valueOf("zookeeper://10.20.153.10:2181")); registry.register(URL.valueOf("redis://10.20.153.11/com.foo.BarService?category=providers&dynamic=false&application=foo&group=member&loadbalance=consistenthash"));

架构组件

架构图

调用过程

- 

dubbo服务集群配置-集群容错

I Failover Cluster(默认)

失败自动切换，失败后重试其他服务器，通常用于读操作

<dubbo:service retries="2" cluster="failover"/> 或：<dubbo:reference retries="2" cluster="failover"/> cluster="failover"可以不用写,因为默认就是 failover

Failfast Cluster

快速失败，只发起一次调用，失败即报错，通常用于非幂等性的写操作

Failback Cluster

失败自动恢复，后台记录失败请求，定时重发，通常用于消息通知

常见问题

服务提供者能实现失效踢出是什么原理

服务调用是阻塞的么

Netty

子主题

gRpc

Google开发的高性能、通用的开源RPC框架，其由Google主要面向移动应用开发并基于HTTP/2协议标准而设计， 基于ProtoBuf(Protocol Buffers)序列化协议开发，且支持众多开发语言。本身它不是分布式的， 所以要实现上面的框架的功能需要进一步的开发。

Thrift

Apache的一个跨语言的高性能的服务框架，也得到了广泛的应用。

motan

新浪微博开源的一个Java 框架。它诞生的比较晚，起于2013年，2016年5月开源。 Motan 在微博平台中已经广泛应用，每天为数百个服务完成近千亿次的调用。

rpcx

Go语言生态圈的Dubbo，比Dubbo更轻量，实现了Dubbo的许多特性， 借助于Go语言优秀的并发特性和简洁语法，可以使用较少的代码实现分布式的RPC服务。

服务器

Tomcat

Jetty

Nginx

服务端缓存

redis

数据结构

存储对象底层结构

REDIS_ENCODING_INT         long 类型的整数 REDIS_ENCODING_EMBSTR  embstr 编码的简单动态字符串(redis3.0添加) REDIS_ENCODING_RAW       简单动态字符串 REDIS_ENCODING_HT           字典 REDIS_ENCODING_LINKEDLIST 双端链表 REDIS_ENCODING_ZIPLIST        压缩列表 REDIS_ENCODING_INTSET        整数集合 REDIS_ENCODING_SKIPLIST      跳跃表和字典

string

可选：int / raw / embstr

string类型的抉择

对象可转long 用 int

length<39用embstr  否则用raw

embstr对比raw

embstr只分配一次内存

raw需要分配两次：sds&object,释放时也需要两次

SDS(Simple Dynamic String)简单动态字符串，它是由C语言完成

应用场景

基本缓存功能，利用redis的支持的高并发在db间做缓存屏障

计数器，点赞数等数据，可以异步定时缓存这些非及时数据到db

共享用户session，redis高效更新获取用户session，提高响应效率

分布式锁

List

可选：ziplist / linkedlist     

zipList

ziplist是一种压缩链表，好处是更能节省内存空间，因为它所存储的内容都是在连续的内存区域当中的。 当列表对象元素不大，每个元素也不大的时候，就采用ziplist存储。但当数据量过大时就ziplist就不好用了。  因为为了保证他存储内容在内存中的连续性，插入的复杂度是O(N)，即每次插入都会重新进行realloc。 对象结构中ptr所指向的就是一个ziplist。整个ziplist只需要malloc一次，它们在内存中是一块连续的区域

malloc : 作用是在内存的动态存储区中分配一个长度为size的连续空间 realloc : realloc函数用于修改一个原先已经分配的内存块的大小，可以使一块内存的扩大或缩小

linkedList

双向链表。它的结构比较简单，节点中存放pre和next两个指针，还有节点相关的信息。 当每增加一个node的时候，就需要重新malloc一块内存

应用场景

消息队列：redis阻塞链表可以很好支持，rPush,lPop

排行榜等列表数据

对于频繁变更且有分页的数据，推荐使用sorted set/list变更后获取分页lrange,容易有重复值

hash

可选：ziplist或者hashtable 

zipList

hashTable

由dict结构实现

dict对象的 dictht ht[2] dicht[0] 是用于真正存放数据， dicht[1]一般在哈希表元素过多进行rehash的时候用于中转数据

应用场景

购物车场景，(key,filed,value)=(用户id,商品id,商品数量)

set

可选：intset或者hashtable

hashTable

intSet

整数集合，存储同类型数据，支持三种长度的整数: int16_t/int32_t/int64_t

查找元素时间复杂度：O(logN) 插入数据时间复杂度不一定为O(logN); 如果插入数据int32_t数据到int_16集合中，涉及到集合的升级，把int16转为32，重新分配内存 插入int16到int32集合中，不会集合类型降级

应用场景

黑/白名单

关注/粉丝名单

zset(sorted set)

可选: ziplist 或者 skipList&dict

skiplist&dict

skiplist:跳表,实现了快速查找，大多情况下和平衡树查不多，可以作为替代品

ziplist

ziplist作为集合和作为哈希对象是一样的，member和score顺序存放。 按照score从小到大顺序排列

应用场景

排行榜，可以根据score排序

高级数据结构

bitmap

hypelogs

geo

redis持久化

RDB

可以指定时间间隔生成数据集的备份文件/可以指定不同的时间间隔

优点

· rdb数据结构紧凑，可以指定多时间点进行数据备份/在恢复时有多版本 · rbd是一份内容紧凑的数据，方便数据加密传输备份 · rdb数据备份性能更好，fork出来一个子线程来备份，不影响主线程工作 · rdb的数据恢复速度比较快；当数据修改较多时尤为显著

缺点

rdb不能尽量保证数据的完整性：容易丢失时间间隔内的数据

每次保存 RDB 的时候，Redis 都要 fork() 出一个子进程，并由子进程来进行实际的持久化工作。 在数据集比较庞大时， fork() 可能会非常耗时，造成服务器在某某毫秒内停止处理客户端；  如果数据集非常巨大，并且 CPU 时间非常紧张的话，那么这种停止时间甚至可能会长达整整一秒。  虽然 AOF 重写也需要进行 fork() ，但无论 AOF 重写的执行间隔有多长，数据的耐久性都不会有任何损失

fork失败案例 redis存储类14G数据，内存只有16G

fork

fork()系统调用是Unix下以自身进程创建子进程的系统调用，一次调用，两次返回，如果返回是0，则是子进程，  如果返回值>0，则是父进程（返回值是子进程的pid），这是众为周知的。 还有一个很重要的东西是，在fork()的调用处，整个父进程空间会原模原样地复制到子进程中，  包括指令，变量值，程序调用栈，环境变量，缓冲区，等等。

AOF

记录所有写操作到log文件，以追加的形式写入，恢复时可以执行log中的数据集 可以rewrite.来调整log文件大小

优点

1.fsync策略可以设置每次写入/每秒执行，最小损失数据同步 2. redis-check-aof 可以对写入有问题的命令进行修复 3.aof文件过大时，redis会对文件重写，以最小命令集来压缩文件大小，    并且会在重写后替换现有的aof文件,不用担心期间异常导致的数丢失 4.aof文件即便再flushall后仍可恢复/修改aof,删掉最后的命令

缺点

1.相同的数据集来说，AOF 文件的体积通常要大于 RDB 文件的体积 2.使用的fsync aof速度慢于rdb

事件

AOF 在过去曾经发生过这样的 bug ：因为个别命令的原因，导致 AOF 文件在重新载入时，无法将数据集恢复成保存时的原样。  （举个例子，阻塞命令 BRPOPLPUSH 就曾经引起过这样的 bug 。） 测试套件里为这种情况添加了测试：它们会自动生成随机的、复杂的数据集，并通过重新载入这些数据来确保一切正常。 虽然这种 bug 在 AOF 文件中并不常见，但是对比来说， RDB 几乎是不可能出现这种 bug 的。

基于内存的

为什么这么快

单线程

不用切换线程上下文

数据结构简单

底层模型不同

它们之间底层实现方式以及与客户端之间通信的应用协议不一样，Redis直接自己构建了VM 机制， 因为一般的系统调用系统函数的话，会浪费一定的时间去移动和请求

多路IO复用模型，非阻塞

多路I/O复用模型是利用 select、poll、epoll 可以同时监察多个流的 I/O 事件的能力，在空闲的时候，会把当前线程阻塞掉， 当有一个或多个流有 I/O 事件时，就从阻塞态中唤醒，于是程序就会轮询一遍所有的流（epoll 是只轮询那些真正发出了事件的流）， 并且只依次顺序的处理就绪的流，这种做法就避免了大量的无用操作

基于数据存储的/基于硬盘/基于内存/基于cpu缓存  做对比

QPS数据

内存淘汰机制

noeviction -> 不做任何处理，只在写入时，提示错误 volatile-ttl -> 删除最近到期的key allkeys-random -> 随机删除任意key volatile-random -> 删除具有过期时间的随机秘钥 allkeys-lfu -> 移除最近最少使用的key 默认 volatile-lfu -> 在设置了过期时间的键空间中，移除最近最少使用的key allkeys-lru -> 移除最少使用的key volatile-lru -> 在设置了过期时间的键空间中，移除最少使用的key

redis常见性能问题和解决方案

(1) Master最好不要做任何持久化工作，如RDB内存快照和AOF日志文件 (2) 如果数据比较重要，某个Slave开启AOF备份数据，策略设置为每秒同步一次 (3) 为了主从复制的速度和连接的稳定性，Master和Slave最好在同一个局域网内 (4) 尽量避免在压力很大的主库上增加从库 (5) 主从复制不要用图状结构，用单向链表结构更为稳定，即：Master <- Slave1 <- Slave2 <- Slave3... 这样的结构方便解决单点故障问题，实现Slave对Master的替换。如果Master挂了，可以立刻启用Slave1做Master，其他不变。

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

读取：先读缓存，后读数据库 写入：先写数据库，后删除缓存【缓存刷新成本不固定，按缓存读取实际情况而定】

实例

redis分布式锁

实现：

setnx:set not exist

分布式锁-续约问题

watchDog-看门狗

<ul><li>如果拿到分布式锁的节点宕机，且这个锁正好处于锁住的状态时，会出现锁死的状态，为了避免这种情况的发生，锁都会设置一个过期时间。这样也存在一个问题，加入一个线程拿到了锁设置了30s超时，在30s后这个线程还没有执行完毕，锁超时释放了，就会导致问题，Redisson给出了自己的答案，就是 watch dog 自动延期机制。</li><li>Redisson提供了一个监控锁的看门狗，它的作用是在Redisson实例被关闭前，不断的延长锁的有效期，也就是说，如果一个拿到锁的线程一直没有完成逻辑，那么看门狗会帮助线程不断的延长锁超时时间，锁不会因为超时而被释放。</li><li>默认情况下，看门狗的续期时间是30s，也可以通过修改Config.lockWatchdogTimeout来另行指定。</li><li>另外Redisson 还提供了可以指定leaseTime参数的加锁方法来指定加锁的时间。超过这个时间后锁便自动解开了，不会延长锁的有效期。</li></ul>

redis-session共享

分布式session共享问题

redis-消息队列

消息队列

client

jedis

同步阻塞

lettuce

基于nettty异步非阻塞

redission

watchdog

基于nettty异步非阻塞

哨兵模式

哨兵就会自动地对配置的master-slave进行管理，在master发生故障时，及时地提升slave为新的master，保证可用性。

1.在sentinel.conf文件中配置主从机器以及权重，权重是在主服务器失效后计算重新选取新的主节点

2.Sentinel每秒会向master发送ping，（验证最后一次回复时间间隔-可修改）来验证节点是否正常服务

3.当主节点被一个Sentinel被标记为不正常，其他的sentinel机器也会每秒1次发请求验证   当大于指定比例sentinel机器验证节点不正常，则标记为客观下线

3.1 master被标记为客观下线，sentinel会向master下的slave机器发送info验证，由10次/S改为1次/S

4. 期间若master的ping命令有效回复，则会移除下线状态

tair

分布式

集群架构

必须有 configServer,dataServer,client ,可选模块 invalidserver

configServer

1) 通过维护和dataserver心跳来获知集群中存活节点的信息 2) 根据存活节点的信息来构建数据在集群中的分布表。 3) 提供数据分布表的查询服务。 4) 调度dataserver之间的数据迁移、复制。

DataServer

1) 提供存储引擎 2) 接受client的put/get/remove等操作 3) 执行数据迁移，复制等 4) 插件：在接受请求的时候处理一些自定义功能 5) 访问统计

invalidServer

1) 接收来自client的invalid/hide等请求后，对属于同一组的集群（双机房独立集群部署方式）     做delete/hide操作，保证同一组集群的一致。 2) 集群断网之后的，脏数据清理。 3) 访问统计

client

1) 在应用端提供访问Tair集群的接口。 2) 更新并缓存数据分布表和invalidserver地址等。 3) LocalCache，避免过热数据访问影响tair集群服务。 4) 流控

使用场景

缓存使用

<ul><li>使用key/value格式存储</li><li>接受数据丢失</li><li>数据访问速度快</li><li>单条数据存储大小在10KB下</li><li>数据变更不频繁</li><li>数据量很大，有极大增长可能性</li></ul>

持久化使用

<ul><li>使用key/value格式存储</li><li>数据需要持久化</li><li>单条数据存储大小在10KB下</li><li>数据读写比例较高</li><li>数据量很大，有极大增长可能性</li></ul>

不适合

读写比例低 单条数据大小过大 数据需要模糊查询，或者根据value反差key

tair对比redis

memcache

分布式对象缓存

特点

<ul><li>协议简单</li><li>基于内存存储方式</li><li>基于libevent事件处理</li><li>memcached不互相通信的分布式</li></ul>

libevent是个程序库，它将Linux的epoll、BSD类操作系统的kqueue等事件处理功能封装成统一的接口。 即使对服务器的连接数增加，也能发挥O(1)的性能。  memcached使用这个libevent库，因此能在Linux、BSD、Solaris等操作系统上发挥其高性能。

<ul><li>高并发处理</li><li>大数据量的处理</li></ul>

工作原理

内存结构

https://blog.csdn.net/liyongming1982/article/details/13168649

<ul><li>slab_class里，存放的是一组组chunk大小相同的slab</li><li>每个slab里面包含若干个page，page的默认大小是1M，如果slab大小100M，就包含100个page</li><li>每个page里面包含若干个chunk，chunk是数据的实际存放单位，每个slab里面的chunk大小相同</li></ul>

内存分配

利用slab allocation机制来分配和管理内存 将分配的内存分割成等长内存块，再把等长内存块分成组(可事前指定块大小) 数据存储时，按键值大小匹配slab,就近存放，存在空间浪费情况

存放数据，先申请slab内存，申请的内存以page为单位，存放第一个数据时，无论大小都会有1M大小的page分配给slab 申请到page后会按照chunk大小切分，变成一个chunk组，用于存放数据

每个slab-->page中的chunk等长，不同的slab的chunk大小是可指定增长因子的，默认1.25

图片参考 https://segmentfault.com/a/1190000012950110#articleHeader2

内存回收

当数据容量用完MemCached分配的内存后，就会基于LRU(Least Recently Used)算法清理失效的缓存数据（放入数据时可设置失效时间），或者清理最近最少使用的缓存数据，然后放入新的数据。

在LRU中，MemCached使用的是一种LazyExpiration策略，自己不会监控存入的key/vlue对是否过期， 而是在获取key值时查看记录的时间戳，检查key/value对空间是否过期，这样可减轻服务器的负载

如果如果MemCache启动没有追加-M，则表示禁止LRU，这种情况下内存不够会报Out Of Memory错误。

存在问题：

内存分配会存在空间浪费，但是避免了管理内存碎片的问题

内存回收LRU不针对全局，针对slab

存放value数据大小限制，slab会先以page为单位申请内存：1MB，所以value不能大于1M

分布式

客户端可能会对应多个MemCached服务器来提供服务，这就是MemCached的分布式。

server端由C实现，单线程/单进程/异步IO，基于libevent作为事件通知

不同server端的数不互相通信，保存的数据也不同

保存/获取数据，会对key值经过算法，来确认数据存在哪一台服务器

算法：

余数算法

先求得键的整数散列值（也是就键string的HashCODE值什么是HashCode） 再除以服务器台数，根据余数确定存取服务器，这种方法计算简单，高效， 但在memcached服务器增加或减少时，几乎所有的缓存都会失效

一致性hash算法 散列算法

先算出MemCached服务器的散列值，并将其分布到0到2的32次方的圆上，然后用同样的方法算出存储数据的键的散列值并映射至圆上，最后从数据映射到的位置开始顺时针查找，将数据保存到查找到的第一个服务器上，如果超过2的32次方，依然找不到服务器，就将数据保存到第一台MemCached服务器上。如果添加了一台MemCached服务器，只在圆上增加服务器的逆时针方向的第一台服务器上的键会受到影响。

MemCached线程管理

MemCached网络模型是典型的单进程多线程模型，采用libevent处理网络请求，主进程负责将新来的连接分配给work线程，work线程负责处理连接，有点类似与负载均衡，通过主进程分发到对应的工作线程。

默认有7个线程，4个主要的工作线程，3个辅助线程，线程可划分为以下4种

主线程：负责memcached服务器初始化，监听TCP，Unix Domain连接请求

工作线程池：线程池数量4可通过启动参数修改，负责TCP/UDP UNIX域套接口链路上的请求

assoc维护线程：服务端内存中维护一张巨大的hash表，该线程负责维护

alsb线程：内存管理模块，负责class中slab的平衡，启动中可关闭

memcache全面解析

https://blog.csdn.net/u010282707/article/details/12912045

总体来说

memcache中存储的item个数是没有限制的，只要内存足够

memccache单进程在32位机器中最大使用内存是2G，64位没有影响

key的最大长度250字节，超长无法存储

单个value最大1M，超过无法存储

不能遍历服务端中的所有数据，这会阻塞其他操作，且速度很慢

存入key值时候，expire=0不失效，其实在30天后会失效

memcache的高性能源自于两段式hash结构：  1-客户端hash算出key值存储节点  2-服务端hash 找到真正的item返回客户端 非阻塞，基于事件的服务端程序

操作系统

进程，线程，协程

定义

进程：是具有一定独立功能的程序关于某个数据集合上的 一次运行活动，进程是系统进行资源分配和调度的基本单位。     每个进程都有自己独立的内存空间，由于进程比较 重量，占据独立的内存，所以上下文进程间切换开销比较大

线程：线程是进程的一个实体，是CPU调度和分派的基本单位，是比进 程更小的能独立运行的基本单位线程自己基本不拥有系统资源，   只拥有一点在运行中比不可少的资源（如程序计数器，寄存器和栈）

协程：协程是一种用户态的轻量级线程，协程的调度完全由用户控制。 协程拥有自己的寄存器和栈。协程调度切换 时，将寄存器和栈保存在其他地方，在切回 来的时候，恢复先前保存的寄存器上下文和栈，基本没有 内核切换的开销，可以不加锁，所以上下文切换非常快

比较

进程和线程的比较： 1. 进程是系统资源分派和调度的基本单位，而线程是CPU调度和分派的基本单位； 2. 进程拥有自己独立的资源，而线程是进程的一个实体，共享进程的资源，自己只拥有极少的资源；

线程和协程的区别： 协程是用户态轻量级线程，能由用户控制切换，切换开销较小，而线程的切换 不能由用户控制并且切换开销较大

Spring

Ioc容器

BeanFactory

Application Content 

Spring Bean

定义

xml < id ='' class='' />

参数

作用域

singleton：单例容器内只会初始化一次

prototype：每次容器内的调用都会创建一个新的实例

request：每次http请求都会创建一次对象

session：每个http-session共享一个bean，不同session间不共享

global-session：一般用于Portlet应用环境，该运用域仅适用于WebApplicationContext环境

生命周期

定义继承

Aop切面

动态代理

jdk：只能针对实现接口的方式实现代理

<ul><li>通过实现InvocationHandler接口创建自己的调用处理器；</li><li>通过为Proxy类指定ClassLoader对象和一组interface来创建动态代理</li><li>通过反射机制获取动态代理类的构造函数，其唯一参数类型就是调用处理器接口类型；</li><li>通过构造函数创建动态代理类实例，构造时调用处理器对象作为参数参入；</li></ul>

cglib：通过指定类继承实现子类，实现代理

利用ASM开源包，对代理对象类的class文件加载进来，通过修改其字节码生成子类来处理。

spring事务

MVC

SpringMVC是一款轻量级WEB开发框架，将web层分为Model/View/Control三层，职责解耦/简化开发

MVC的处理流程

设计模式

工厂模式

https://blog.csdn.net/Fly_as_tadpole/article/details/88326807

单例模式

三种单例模式

双重锁

策略模式

解决多if/else问题

适配器模式

通过调用接口通用方法，底层实现对不同实现类的调用 调用-播放器，区分mp3/mp4的接口

观察者模式

被观察者保留观察者对象引用，再变更后，通过引用触发变更通知

模板模式

抽象类中定义调用的方法A-包含多个抽象方法BCD，子类实现定义的抽象方法，再调用A时会执行BCD方法

数据库

mysql

数据库三大范式

子主题

索引

优点

<ul><li>索引大大减少了MySQL服务器需要扫描的数据量。  </li><li>索引可以帮助服务器避免排序和临时表。  </li><li>索引可以将随机I/O变为顺序I/O。 </li></ul>

缺点

① 创建索引和维护索引需要时间成本，这个成本随着数据量的增加而加大 ② 创建索引和维护索引需要空间成本，每一条索引都要占据数据库的物理存储空间，      数据量越大，占用空间也越大（数据表占据的是数据库的数据空间） ③ 会降低表的增删改的效率，因为每次增删改索引需要进行动态维护，导致时间变长

类型

常规索引/主键索引/唯一索引/全文索引/外键索引

聚簇索引/聚集索引

定义：数据行的物理顺序与列值（一般是主键的那一列）的逻辑顺序相同，一个表中只能拥有一个聚集索引

mysql 主键默认聚集索引 在已有数据上建立聚集索引，因为聚集索引的物理顺序性，会比较耗性能

非聚簇索引/非聚集索引

定义：该索引中索引的逻辑顺序与磁盘上行的物理存储顺序不同，一个表中可以拥有多个非聚集索引。

按定义，除了聚集索引以外的索引都是非聚集索引，只是人们想细分一下非聚集索引，分成普通索引，唯一索引，全文索引。 如果非要把非聚集索引类比成现实生活中的东西，那么非聚集索引就像新华字典的偏旁字典，他结构顺序与实际存放顺序不一定一致。

非聚集索引的二次查询问题

立两列以上的索引，即可查询复合索引里的列的数据而不需要进行回表二次查询， 如index(col1, col2)，

数据结构

B Tree

适用范维索引

默认使用B+树索引

定义

B+树是一个平衡的多叉树，从根节点到每个叶子节点的高度差值不超过1，而且同层级的节点间有指针相互链接。

Hash

实现方式

key=（索引列）.hash

value =(索引列).行对应指针

局限性

hash的全匹配,不支持部分匹配, 不能用like

不适用于排序，不能顺序存储

hash冲突的代价

索引失效场景

查询包含计算 y=3+2

like “%”在前会使索引失效

包含隐式转换的条件：查找列为varchar，条件为 int，在查找时会转为varchar

!=  <> 可能导致不走索引

存储引擎

MyISAM 发音为 "my-z[ei]m"

B+Tree作为索引结构

非聚簇索引

不持支事务&只支持表锁

自增列必须是索引，组合索引不必第一位

可以无主键，无索引

保存有总行数，count(*) 可以立即返回，有wherel两种效率都一样

支持FULLTEXT类型的全文索引

索引保存：以表名+.MYI文件分别保存

InnoDB

B+Tree作为索引结构

聚簇索引

子主题

支持事务&行锁

Innodb的行锁模式有以下几种：共享锁，排他锁，意向共享锁(表锁)，意向排他锁(表锁)，间隙锁

防止死锁

数据库参数

程序中约定代码读取顺序一致

处理一张表时，尽量保证顺序一致

调整事务隔离级别/ 避免两个事务同时操作一行不存在的数据，容易发生死锁

自增列必须是索引，组合索引必须第一位

没有设定主键或者非空唯一索引，就会自动生成一个6字节的主键(用户不可见)

没有保存总行数，需要遍历表，效率低

不支持FULLTEXT类型的全文索引，可以使用sphinx插件支持全文索引

索引保存：索引和数据一起保存在表中

补充

查看引擎

show create table table_name;

修改表引擎

alter table tablename type=innodb;或者使用 alter table tablename engine = innodb;

innodb是开启自动提交的，如何提高性能

多条语句绑定一个事物，减小数据库开销

避免死锁

一个事务获取排他锁||意向排他锁后尽量减少程序运算，减少锁持有时间

使用where查询，尽量走索引，尽量避免获取意向排他锁

区别补充

琐事

行锁

what

只对表中当前行进行锁定，表中其他的未锁定行仍然可以被操作

行锁是mysql最小粒度的锁，减少了数据的操作冲突，但是实现的成本有点高

容易发生死锁

定义

where语句，操作主键索引时，会锁定主键索引； 操作非主键索引时，会先锁定非主键索引，然后锁定关联的主键索引；

实例

表TEST( id , name , age){ id 主键}

update name='after' where id ='1' T1:先锁定主键索引【id】， T2:并发-- 去锁定非主键索引【name】-->死锁

update name ='after' where name ='before' T1:先锁定非主键索引【name】 T2:并发-- 去锁定主键索引【id】-->死锁

优点

· 有许多线程访问不同的行时，只存在少量的冲突。 · 回滚时只有少量的更改 · 可以长时间锁定单一的行

缺点

· 相对页级锁&表级锁占用更多内存

· 当表中大部分行在使用中时，效率会比较慢（需要获取更多的锁）

再大部分数据上面使用GROUP BY，效率较低（比表级锁和页级锁慢）

表锁

what

直接锁定整张表，不允许其他的写操作，如果锁定的是写锁，不允许其他的读操作

write:表上无锁-落锁，有锁-添加到写锁队列中 read:表上无锁-落锁，有锁-添加到读锁队列中

表中锁释放后，写锁队列先获取表，然后读锁队列获取 ex:当对表有大量更新时，只有更新完成才能查到；

不会发生死锁

死锁案例

事务1, 锁表A,--> 后续锁表B=【死锁】 事务2, 锁表B,--> 后续锁表A=【死锁】

乐观锁

乐观认为每次操作都不会有冲突，不加锁，更新后判断是否有冲突

乐观锁需要自己实现： <ol><li>  一般实现表中加seq字段</li><li>每次update前,seq+1</li><li>更新时对比结果seq == db.seq</li><li>true--更新； false -- 不更新</li></ol>

悲观锁

悲观的认为每次变更都会有操作冲突，只有获取锁才能对数据进行操作

共享锁

对某一资源加共享锁，自身可以读该资源，其他人也可以读该资源（也可以再继续加共享锁，即共享锁可多个共存）， 但无法修改。要想修改就必须等所有共享锁都释放完之后。 语法为：select * from table lock in share mode

排他锁

对某一资源加排他锁，自身可以进行增删改查，其他人无法进行任何操作。 需要执行的语句后面加上for update就可以了

页锁

行锁：速度较快，冲突比较多； 表锁：速度慢，冲突少； 页锁：介于两者之间，一次锁定相邻的一组数据

优化

让sql语句查询mysql服务器的缓存： 语句中包含SQL函数都不会开启查询缓存 EX: now()/CURDATE()

当知道结果只有一个时候，语句加上：LIMIT 1 【查到1条就停止】 当数据量越大，效果越好

select (条件...)代替 *

永远为每张表设置一个ID，设置 AUTO_INCREMENT

尽可能的设置字段为 NOT NULL

NULL 在保存的时候也需要额外的空间，          在比较的时候也很复杂

把ip地址存储为UNSINGN INT

要使用这样的WHERE条件：IP between ip1 and ip2。 我们必需要使用UNSIGNED INT，因为 IP地址会使用整个32位的无符号整形。 而你的查询，你可以使用 INET_ATON() 来把一个字符串IP转成一个整形，并使用 INET_NTOA() 把一个整形转成一个字符串IP。在PHP中，也有这样的函数 ip2long() 和 long2ip()。

查询优化， <ul><li>尽量减少查询条件，</li><li>尽量走索引，</li><li>尽量避免全表扫描,</li><li>尽量减少模糊查询 like "%**%"</li></ul>

索引失效？

对索引列进行判空， is NULL /  is NOT NULL

对索引字段进行模糊查询  like  %

对索引字段进行比较【!=】运算【+1】

以下用法：<> 、not in、not exist、!=

建议主键设置自增id

提高数据如插入效率 减少二级缓存的索引存储空间

请使用innodb引擎，支持行锁，Myisam只支持表锁

时间类型：优先使用dateTime(8bite),TimeStamp(4bite)

不要给每一列都添加索引，优先给where的条件，order by 、group by 的条件添加索引

like查询，like ‘%name%’ 无法使用索引，like ‘name%’ 阔以使用索引

主从复制

提高可用性，与数据的安全可靠性(master/slave) master负责读写，slave只负责读

架构

一主多从

主节点故障，风险较大

双主双从

过程

1.master改动，写入二进制文件中 2.slave间隔时间内对master服务器上的二进制文件禁写探测 3.文件变化，slave请求IO线程获取master二进制日志 4.master为每个IO线程启动dump thread 发送二进制日志 5.slave接收二进制日志到本中继日志中 6.slave读取中继日志，本地回房，保证和master数据一致 7.IO thread和 dump thread 睡眠，等待唤醒

多实例配置

一台linux安装一个mysql，启动多个mysql数据库实例，而不需要安装多个

子主题

noSql

MongoDB

第一章简介

特征

面向文档

BSON格式（二进制json）

支持Ad hoc查询的nosql

即席查询

索引

B树

LSM树

3.2版本可用

支持为字段添加二级索引，每个集合允许64个索引

持久化

写日志文件（bin log?）

默认开启 100ms写一次

存储引擎

WireTiger

扩展

基于范围分片

只在分片节点内冗余数据

基于hash和tag分片

复制

集合内可复制

自动容灾

工具

mongodump /mongosniff /mongostat /mongotop 等等

应用场景

可变的schema

数据集大小超过内存，会开始访问磁盘，速度变慢，mmap

第二章 mongo命令行

CRUD

创建

insert()

mongo中的库、集合在第一次插入数据时才会创建，不用手动创建

查询

find()/count()

条件关键字 $AND $OR $LT $GT

pretty()格式化

更新

update()

$set指定更新内容，否则执行替换更新

$unset去掉指定字段

 $push更新集合

删除

drop()

删除集合

remove()

删除文档

高级查询

explain()

参数：

explain(工作模式)

关键输出：

totalKyesExamined 用到的索引数

totalDocsExcamined 遍历文档数

executionTimeMills 执行时间

索引

createIndex()

参数：{ 索引字段:索引名}

getIndexes()

数据库命令

db.stats()

数据库信息

db.cols.stats()

集合信息

db.currentOp()

监控当前操作

db.serverStatus()

集群维度的统计信息

connections

"connections" : { "current" : <num>, "available" : <num>, "totalCreated" : <num>, "active" : <num> }

命令执行原理

db.runCommand()

执行内建命令的函数

$cmd

内建命令集合

命令帮助

db.help()

查看命令源码

输入命令但是不加括号 eg: 输入db.cols.save查看save()源码

第三章 ruby驱动

mongo驱动作用

生成对象ID

时间+机器id+进程+计数器（4+3+2+3=12bytes）

对象和BSON格式之间转换

和数据库建立TCP连接

第四章为业务设计mongo数据库

设计schema的技巧

设置唯一“主键”

设置一个slug字段，让它做唯一索引，保存一个便于阅读理解的key

比如商品编号 "IPhoneUsbCharger-34212"

不用ObjectId，因为ObjecID是一串无意义的字符

表示关联关系

因为mongo不支持join连接，所以可以直接把被关联的对象的信息保存在数据文档中 (也可以按关联对象的id查询，直接保存只是减少查询次数&最好保存不经常变动的信息）

比如每个子类别不仅保存一个父类别的id，还保存了父类别的名称等（用户查询需要返回的信息）

这种方式违反了数据库的第二，三范式

存在传递依赖，父类别改名时，所有子类别文档也要更新

不是每个属性都依赖主键

设计mongo 库、表时的限制

数据库限制索引和集合数不能超过26000(WiredTiger引擎不限制)

创建数据库后，mongo会在/data/db目录创建一系列文件，以库名为前缀

xx.ns文件表示数据库xx的命名空间，固定大小16MB

16MB能保存不超过26000个元数据

可以通过修改--nssize改变限制

存储集合和索引的文件大小不超过2GB

mongo以预分配的方式在磁盘创建文件

扩容过程 64mb->128mb ... -> 2gb

db.stats() 输出的 fileSize表示数据库文件占用字节

总索引大小最好能够被装入内存

db.stats() indexSize查看全部索引大小

集合

集合名不超过128字符

固定集合（达到固定大小时，最先输入的记录被覆盖）

固定空间占用的集合（16kb等）

固定文档数的集合

TTL集合

用createIndex-- expireAfterSeconds创建一个管理超时时间索引

索引字段比较字段的值和当前时间差，超过expireAS会删除文档（不是删除集合）

固定集合不支持TTL

文档

尽量使用短的字段名，因为字段名也被大量保存

字符串必须用utf8编码

数值类型

小数值要保存成整数（放大若干倍）

因为BSON不支持小数位

单个文档大小限制为16MB

文档嵌套深度最大值100

第五章 mongo支持的查询方式

查询语言

比较

$lt,$gt

db.xx.find({'age':{'$gt':20}})

范围

$in $all $nin

布尔查询

$ne $not $or  $nor...

db.xx.find({'$and':['xxxxxx']})

包含某个字段

$exists

数组

包含某些字段 $elemMatch

大小 $size

自定义

$where 结合js函数查询

正则

前缀表达式可以用索引，其他不行

特殊查询

$mod 整除计算结果匹配

$type 字段类型匹配

$text 在文本上执行搜索

查询结果过滤

控制返回字段,再传一个参数值为1包含，0不包含

只返回 id db.xx.find({'name':'xx'},{'id':1})

跳过多少个记录

$skip

返回数量

$limit

排序

$sort

返回一定范围

$slice

{$slice:-5} 最后5个

第六章 mongo的聚合查询框架

定义

mongo中的聚合类似于SQL中的group by

聚合管道

每一步的处理输出是下一步的输入

常用操作

$project

指定输出字段

$match

条件过滤

$group

根据指定key分组

$unwind

"展开，放松" 扩展数组，把每个元素为一个文档

$sort

$out

输出到新集合

示例

db.products.aggregate([{$match : ... } , {$group : ...},{$sort : ...},{ $out : ....}])

聚合操作内支持的函数

$group函数，用来改变输出集合的内容

$sum , $avg , $addToSet ....

$group:{ _id:{user:'$user_id', list: {$push: '$name'}}

字符串函数

$concat $substr $toLower .....

算术函数

$add $mod ...

日期函数

逻辑函数

集合操作符

处理输出的数组

$setUnion 合并两个集合

$setIntersection 返回公共元素

$setDifference 返回不同元素

....

聚合的性能

性能相关的选项

explain

返回聚合操作的查询信息，索引，扫描范围等

allowDiskUse

当处理大集合时，允许访问磁盘

cursor

用返回结果的指针来代替返回整个结果，减小返回数据大小

优化手段

在管道操作中减小文档的数量和大小

只有$match 和 $sort才能使用索引

使用分片集群时，$match和$project会在单个分片执行，其他的操作符会在主要片执行

？？？？

map-reduce

需要自己编写js函数，比聚合出现早，但不再作为主要查询手段

第七章 mongo中的更新操作

更新操作

方式

update全部替换

update + $set 更新指定字段

网络传输的内容少

格式

db.xx.update( {查询条件},{$操作符：{更新内容}，{更新选项}} )

选项

multi:true

批量更新，默认只会更新一个文档，不保证批量操作的原子性，需要自己处理失败

upsert:true

文档不存在时，插入新记录，新记录会合并查询和更新指定的字段做为内容

操作符

$inc N

N也可以是负数

$set

设置字段值

$unset

删除字段

$rename

重命名字段key

$setOnInsert:默认值

和upsert同时使用，在添加时使用默认值

数组操作符

$push $each $sort 等等

删除

remove全部文档

db.xxx.remove()

remove某些文档

db.xxx.remove({查询条件})

原子性操作

findAndModify

原子操作：(借助锁机制)相当于CAS操作，先查询获得结果然后更新,返回被更新的文档

限制

一次只能更新一个文档

参数

new：true

是否返回更新后的文档，否则返回更新之前的

sort

因为只能更新一个，可以用sort选择要更新的文档

upsert

如题用upsert的方式修改

fields

控制文档返回的字段

$isolated操作符

db.xx.update(   {$isolated:true} ,   {$set:xxx} )

使用它，表示当前操作是独立的,持有锁并阻塞其他操作

限制

在分片集合上无法使用

如果操作中途失败，mongo不会回滚数据

锁机制

WiredTiger引擎

支持文档级别的锁（SQL中的行锁）

老版本

数据库级别的锁

第八章索引

基本概念

用B树实现

每个索引至少需要8kb空间 ???

被索引的字段最大不超过1024kb

可以通过索引文档个数和大小估算B树的内存占用

节点空间利用率为60% ？？

非聚集索引

聚集索引的索引顺序和数据在磁盘的物理顺序一致

innodb的主键

mongo中的索引不是聚集索引，索引顺序和数据顺序没有关系

设计索引

保证索引大小能保存在内存中，避免磁盘I/O

索引越多，数据变化时，需要执行更新索引的操作越多

使用复合索引时，注意选择的字段顺序

索引类型

唯一索引

createIndex({unique:true})

保证索引字段在文档中唯一，插入重复数据会提示异常

唯一索引最好在填充数据前创建，否则需要手动对字段去重

多键索引

当索引字段是数组类型时使用，数组中的值都会保存在索引里

哈希索引

createIndex({recipe_name:'hashed'})

一般值相似的几个索引会保存在相邻的位置，Aa Abc Abb ....

哈希索引会把索引的值经过hash计算后再保存，这样索引会在集群中均匀分布（适合分片集合类型）

限制

不支持范围查询，仅支持等值查询

不支持多建索引

浮点数会被当做整数计算，4.2 和 4.3的索引相同

TTL索引

db.eventlog.createIndex( { "lastModifiedDate": 1 }, { expireAfterSeconds: 3600 } )

适用于时间类型字段

过期时间是字段值X + expireAfterSeconds 秒

对嵌套的文档字段无效

操作索引

常用命令

db.collection. getIndexes() / dropIndex() / createIndex()

整理碎片

db.values.reIndex()

随着数据的变化，索引更新后会产生碎片

索引构建

大型数据库创建索引耗时会很长

处理办法

在后台构建索引

createIndex({background:true})

离线构建索引

复制主节点，构建索引，替换

索引创建过程中会对数据库加锁

构建执行步骤

对索引值做排序

把排序值插入索引

查看构建进度

db.currentOp()

索引优化

profile分析器

配置命令

db.setProfilingLevel(0/1/2,timeout)

0 禁用 1 记录慢操作 2 记录全部读写操作

查询监控结果

db.system.profile.find()

结果保存在system.profile集合

explain函数

xx.find(xx).explain("executionStats")

参数指定输出内容

参数

allPlansExecution/executionStats/queryPlaner

输出关注

nReturned

查询匹配和返回的文档数量

totalKeyExamined

查询扫描的文档数量，越小越好

mongoDB内置的查询优化器

选择最优索引组合成查询计划

生成的查询计划会被缓存一段时间

原则

避免scanAndOrder,如果要排序，优先尝试使用索引排序

优先使用满足所有查询字段的索引

第九章文本搜索

第十章 WireTiger简介

可插拔的存储引擎接口

存储引擎

mongo数据库和硬件的直接接口

影响读写磁盘数据的方式，数据存储时的数据结构

v3.0提供了引擎切换的功能，满足不同使用场景的需要

wiredTiger

特点

多核可伸缩 Scalable Multicore Programming

风险指针和无锁算法的应用

使用mvcc架构

使用B树，可以切换LSM树

LSM在写入表现好，读表现差

文档级别的并发控制

多个客户端可以同时修改集合的不同文档

使用wiredTiger

确保64位系统

配置

engineConfig

cacheSize

申请多少内存

journalCompressor

使用哪种日志压缩器，默认snappy

collectionConfig

blockCompressor

集合数据压缩方式默认snappy,可选zlib 或 none

indexConfig

prefixCompression

是否压缩索引，默认true

对比MMAPv1引擎

磁盘占用明显减少

mmap每次数据增长会申请2G的磁盘空间

性能对比

使用mongobenchmark执行测试脚本

读写性能wiredTiger优于mmapv1

开启压缩的wt在插入上比未开启压缩的wt慢,在读取上快，磁盘占用小

如果磁盘空间充足使用不压缩的wt

对比RocksDB

RockDB使用LSM树引擎，适用于高并发写入场景

mongoDB可以使用RocksDBm引擎

第十一章副本集

副本集的特点

节点分为主从裁判(arbiterOnly) 三种，可以包含50个节点(v3.0)

裁判不复制数据

提高读性能

不能保证一致性读（只有最终一致）

不适用写请求大于读请求的场景

不适用于大数据集存储，需要使用分片代替

自动容灾

冗余数据

历史数据还是要备份快照，两者结合使用

副本集的命令

rs.initiate()

初始化

rs.reconfig()

重新配置，注意配置变化会导致重新选举主节点

rs.add("pc.local:7000")

添加节点

rs.slaveOk()

开启从节点的读取，默认情况，从节点无法查询

db.isMaster()、rs.status()

副本集的节点信息

db.getReplicationInfo()

当前节点的数据复制情况

rs.help()

副本集命令帮助

工作原理

oplog介绍

保存在副本集每个节点的local数据库中

local数据库还保存了索引，集群选举信息等等重要数据

是一个固定大小的集合

64位系统默认大小为1G或者磁盘可用空间的5%

启动命令 mongod -oplogSize 设置自定义大小

记录节点所有数据变化，每条记录保存了时间戳，操作类型，操作数据等

用oplog实现数据复制

主节点写入

操作记录到oplog

不会同步写所有从节点，通过writeConcern控制

从节点同步

通过长轮询请求，复制主节点oplog

根据本地oplog日志的时间戳，在主节点oplog中找到新产生的数据(找不到同步点，说明相差太多，要重新同步)

写入数据，更新本地oplog

实现自动容灾

心跳信息

2秒 ping一次，用来实现容灾和选举的判断

节点挂了

挂从节点

不处理

挂主节点

选举新主节点

降级

主节点发现副本集只有自己，则自动降级为从节点

拒绝了写请求，可以避免数据无法冗余，丢失高可用

可以处理网络分区的问题，避免因为分区导致出现多个主节点

但不能完全避免，不一定只有主节点自身在一个网络分区，比如5个节点分成2+3

回滚

从节点复制时发现自己本地有主节点不存在的操作，则把这些操作回滚

从节点之前是主节点，然后挂了，有数据没被复制

管理副本集

每次重新配置都会重新选主节点

重新配置过程

config= rs.config()

config.members[1].host

假设修改第二个节点的host

rs.reconfig(config)

配置参数

priority

被选为主节点的优先级，0表示永远不做主节点

buildIndex

是否构建索引，备份节点不需要提供查询，设置为false

slaveDelay

复制的延迟时间，但是首先要配置节点优先级为0，才能生效

状态枚举

STARTUP

RECOVERING

FATAL

DOWN()

ROLLBACK

PRIMARY

SECONDARY

ARBITER

读写请求配置

写关注点

默认为1

设置为0，存在风险，无法正常故障转移

getLastError命令配置关注点

w

每次写要复制到几个服务器

wtimeout

写请求复制到其他节点的超时时间

读偏好

primary

唯一保证一致性读的模式

只读主节点

primaryPreffered

主优先，不可用读从库

secondary

只读从库

secondaryPreffered

从库优先

nearest

读响应延迟最低的节点

标签节点

每个节点都可以被打上若干tag

通过getLastErrorModes命令，配置每次写到哪些标签，写标签中的几个节点

getLastErrorModes:{multiCity:{beijing:2},multiRegion:{us:3}}

定义了multiCity/Region两个模式，选择bj和us标签的节点

第十二章分片集群

简介

分片集群结构

config service

保存集群元数据，数据在集群上的分布信息

提供高可用的持久化存储

两阶段提交更新配置

shard (replica set)

每个分片都是一个副本集

mongos进程

从config server读取节点，把客户端请求路由到合适的分片

把配置数据写到config server,使用两阶段提交

以独立进程运行，负责和客户端驱动连接

数据分片方式

基于“块”分片，“块”包含一个集合中的一部分文档

一个集合的文档会分布在多个片上

维护分片集群

创建

1.创建副本集

mongod --shardsvr --replSet xxx

2.创建config server

mongod --configsvr xxxx

3.启动mongos进程

mongos --configdb configserver(ip:port) xxx

4.连接mongos进程，执行分片命令

sh.addShard(xxx)

sh.enableSharding("shard db name")

sh.shardCollection("collection name",{分片键1,2,3...})

mongodb会在分片键上创建索引

数据迁移

分割

当数据“块”chunk size超过64mb,会分割成两个”块“

迁移

当数据在分片之间分布不均匀时发生

查看状态

分片集群状态

sh.status()

集群变动日志

use config; db.changelog.find()

balancer工作机制

文档介绍

管理分片集群数据

分片键选择

不要产生热点

分片键要让数据分布均匀

对查询友好，避免全局查询

分片键最好是查询常用的字段

不要让分片数据块的粒度过粗

分片键没有代表性，会使相同键的数据过多，超过分片单位"块"最大64mb的限制

不要使用objectID做分片键

objectID是自增的，新数据会集中到最后一个分片

查询

分类

目标查询：查询包含分片键

全局查询：查询不包含分片键

需要在每个分片执行查询

通过explain命令查看是否为全局查询

索引

分片集合在每个分片上的索引字段是一样的

只能在分片键和_id字段创建唯一索引

部署最佳实践

减少使用的机器

副本集成员保存数据，需要单独的机器

副本集的裁判，不需要保存数据，可以和其他程序共享机器

config server实例，可以和其他程序共享机器

优化方式

要保证config server每个实例实时在线

当数量少于3台，配置服务器集群会变为只读，即没有主服务器，则分片集群不支持更改集群元数据的操作，例如块拆分和迁移。虽然不能拆分或迁移任何块，但应用程序可以将数据写入分片集群（最多挂2台，否则停止服务）。

当加载大量数据到分片集合时怎样节省时间

使用预分割和预迁移的方式手动处理

添加分片耗时长

mongo集群，预估的数据迁移速度为100~200MB每分钟

在分片服务器内存占用到80%-90%之前就应该尽快提前迁移

Hbase

Redis

BitmapImageRenderer

性能

分布式设计

分布式事务

XA(两阶段提交)

优劣

适合单模块应用，跨多个数据库的操作， 严格依赖数据层处理复杂业务，效率低，不适合高并发场景

微服务场景只允许当期模块访问当前数据库， 如果访问多库，容易造成数据混乱，无法控制

过程

两阶段提交有一个事务管理器的概念，负责协调多个数据库的事务，事务管理器先询问多个数据是否准备好？ OK就提交事务，如何一个数据库NOK，回滚事务

TCC 方案

Try、Confirm、Cancel

Try:         对资源进行预检测，或者锁定预留 Confirm: 对各个服务进行实际的操作，CRUD操作 Cancle:   执行出错的补偿，就是回滚操作

过程

A转账给B，try阶段就要冻结A扣款金额，B账户确认是否可用 confirm 就要A扣款，B加钱 cancle   A扣款冻结取消|已扣除添加，B账户解冻|扣除

优劣

严格依赖代码来执行回滚和补偿，代码工作量大，维护太麻烦容易出错

本地事务表

过程

图例

A系统本地事务处理同时，插入记录到消息表，然后发送消息到MQ B系统收到MQ，插入记录到消息表&&并校验是否已经执行过？执行业务 B执行成功: 更新B本地消息表状态，以及A系统消息表 B执行失败：A系统轮询消息表状态，重新发送MQ

优劣

高并发i情况不适用，扩展性差

可靠消息最终一致性

过程

图例

基于本地事务表，只不过不用本地消息表，而是用MQ来实现消息事务

A系统发送Prepare消息到MQ，本地事务执行成功？确认发送：取消发送&回滚 B系统收到消息执行本地事务,并确认消息ACK【可靠消息状态变更】 MQ自动轮询是有prepare消息回调接口，确认B事务是否成功 失败则确认重试or回滚

优劣

消息服务单独部署扩展性好，维护性好 降低业务系统以及消息系统之间的耦合

消息需要发送两次请求

项目开发/管理

代码CR

代码设计

是否存在冗余代码

业务划分是否合理，是否有相互耦合

复杂业务必须提供时序图，流程图

代码逻辑清晰，注释完整，可读性强

阿里代码检测插件

是否合理使用设计模式or 设计模式使用过度

if-else 是否使用过度，使用策略模式

https://blog.csdn.net/ypp91zr/article/details/81705345

线程池的使用，参数设置是否正确

锁的使用是否准确，锁的范围，粒度是否准确

事务是否使用正确，是否生效/嵌套

优化部分

是否使用缓存

乐观锁代替悲观锁

慢操作采用异步处理

多接口聚合采用多线程处理

异常处理

是否有统一的错误码

异常是否有统一处理机制

直接抛出

重试

熔断

降级

恢复

关闭任务

数据库

数据表设计是否合理(三大范式)

索引设置是否合理，是否生效

数据一致性

分布式事务

分布式锁

异步调用操作是否有失败补偿操作

单元测试是否覆盖

日志打印是否规范

核心代码部分是否有关键信息打印

报错信息，是否有可追踪信息打印如入参。traceId,方便后续排查

是否潜藏NPE

编程风格依赖<阿里巴巴编码规范>

搜索引擎