java知识框架图

这个时候做bgsave cow的机制就没了

大量请求会让值升高 超出阈值断开

预估体量参数动态调整

用单链表进行的纵向延伸，当采用头插法时会容易出现逆序且环形链表死循环问题，线程不安全

调用putForNullKey()方法

加入了红黑树使用尾插法，能够避免出现逆序且链表死循环的问题。

扩容时，利用 2 的次幂数值的二进制特点，既省去重新计算 hash 的时间，又把之前冲突的节点散列到了其他位置

两个版本中如果键为null，那么调用hash()方法得到的都将是0，所以键为null的元素都始终位于哈希表table【0】中

Hash公式跟长度有关

引用类型：默认情况下，对比它们的地址是否相等；如果equals()方法被重写，则根据重写的要求来比较。

String的equals()方法仅仅是对比它的 数据值，而不是对象的 内存地址

对于基本类型来说，== 比较的是它们的值

对于引用类型来说，== 比较的是它们在内存中存放的地址（堆内存地址）

继承了reentranLock

尝试获取锁存在并发竞争  自旋  阻塞

cas失败自旋保证成功

System.arraycopy

第一次握手：客户端发送syn包(syn=j)到服务器，并指明客户端的初始化序列号 ISN©。此时客户端处于 SYN_SEND 状态。等待服务器确认；

首部的同步位SYN=1，初始序号seq=x，SYN=1的报文段不能携带数据，但要消耗掉一个序号。

服务端会以自己的 SYN 报文作为应答，并且也是指定了自己的初始化序列号 ISN(s)。同时会把客户端的 ISN + 1 作为ACK 的值，表示自己已经收到了客户端的 SYN，此时服务器处于 SYN_REVD 的状态。

在确认报文段中SYN=1，ACK=1，确认号ack=x+1，初始序号seq=y。

客户端收到 SYN 报文之后，会发送一个 ACK 报文，当然，也是一样把服务器的 ISN + 1 作为 ACK 的值，表示已经收到了服务端的 SYN 报文，此时客户端处于 established （已连接）状态。服务器收到 ACK 报文之后，也处于 established （已连接）状态，此时，双方已建立起了连接。

确认报文段ACK=1，确认号ack=y+1，序号seq=x+1（初始为seq=x，第二个报文段所以要+1），ACK报文段可以携带数据，不携带数据则不消耗序号。

第一次挥手：客户端发送一个 FIN 报文，报文中会指定一个序列号。此时客户端处于 FIN_WAIT1 状态。

即发出连接释放报文段（FIN=1，序号seq=u），并停止再发送数据，主动关闭TCP连接，进入FIN_WAIT1（终止等待1）状态，等待服务端的确认。

第二次挥手：服务端收到 FIN 之后，会发送 ACK 报文，且把客户端的序列号值 +1 作为 ACK 报文的序列号值，表明已经收到客户端的报文了，此时服务端处于 CLOSE_WAIT 状态。

即服务端收到连接释放报文段后即发出确认报文段（ACK=1，确认号ack=u+1，序号seq=v），服务端进入CLOSE_WAIT（关闭等待）状态，此时的TCP处于半关闭状态，客户端到服务端的连接释放。客户端收到服务端的确认后，进入FIN_WAIT2（终止等待2）状态，等待服务端发出的连接释放报文段。

第三次挥手：如果服务端也想断开连接了，和客户端的第一次挥手一样，发给 FIN 报文，且指定一个序列号。此时服务端处于 LAST_ACK 的状态。

即服务端没有要向客户端发出的数据，服务端发出连接释放报文段（FIN=1，ACK=1，序号seq=w，确认号ack=u+1），服务端进入LAST_ACK（最后确认）状态，等待客户端的确认。

第四次挥手：客户端收到 FIN 之后，一样发送一个 ACK 报文作为应答，且把服务端的序列号值 +1 作为自己 ACK 报文的序列号值，此时客户端处于 TIME_WAIT 状态。需要过一阵子以确保服务端收到自己的 ACK 报文之后才会进入 CLOSED 状态，服务端收到 ACK 报文之后，就处于关闭连接了，处于 CLOSED 状态。

即客户端收到服务端的连接释放报文段后，对此发出确认报文段（ACK=1，seq=u+1，ack=w+1），客户端进入TIME_WAIT（时间等待）状态。此时TCP未释放掉，需要经过时间等待计时器设置的时间2MSL后，客户端才进入CLOSED状态。

完成三次握手，建立起连接的就会放在全连接队列中。如果队列满了就有可能会出现丢包现象。

第三次的ACK在网络中丢失，那么Server 端该TCP连接的状态为SYN_RECV,并且会根据 TCP的超时重传机制，会等待3秒、6秒、12秒后重新发送SYN+ACK包，以便Client重新发送ACK包。
而Server重发SYN+ACK包的次数，可以通过设置/proc/sys/net/ipv4/tcp_synack_retries修改，默认值为5.
如果重发指定次数之后，仍然未收到 client 的ACK应答，那么一段时间后，Server自动关闭这个连接

第三次握手中的ACK包丢失的情况下，Client 向 server端发送数据，Server端将以 RST包响应，方能感知到Server的错误。

验证信息的完整性。

采用协商的密钥对数据加密

身份认证和密钥协商

NIO 的 Buffer 和 channel 都是既可以读也可以写

Buffer主要用于和NIO通道进行交互，数据是从通道读入到缓冲区的，然后从缓冲区中写入到通道中的。

channel 类似于流，每个 channel 对应一个 buffer缓冲区，buffer 底层就是个数组

channel 会注册到 selector 上，由 selector 根据 channel 读写事件的发生将其交由某个空闲的线程处理

提高资源利用率和吞吐率

程序计数器、寄存器和栈

Mark Word

Klass Point（对象指向它的类元数据的指针，虚拟机通过这个指针来确定这个对象是哪个类的实例。）

Monitor

加锁的过程会清除工作内存中的共享变量，再从主内存读取

而释放锁的过程则是将工作内存中的共享变量写回主内存

当多个线程进入同步代码块时，首先进入entryList

有一个线程获取到monitor锁后，就赋值给当前线程，并且计数器+1

如果线程调用wait方法，将释放锁，当前线程置为null，计数器-1，同时进入waitSet等待被唤醒，调用notify或者notifyAll之后又会进入entryList竞争锁

如果线程执行完毕，同样释放锁，计数器-1，当前线程置为null

mark Word 中有线程信息 cas 比较

对象头是由Mark Word和Klass pointer 组成，锁争夺也就是对象头指向的Monitor对象的争夺，一旦有线程持有了这个对象，标志位修改为1，就进入偏向模式，同时会把这个线程的ID记录在对象的Mark Word中。

当线程访问同步块获取锁时，会在对象头和栈帧中的锁记录里存储偏向锁的线程ID，之后这个线程再次进入同步块时都不需要CAS来加锁和解锁了，偏向锁会永远偏向第一个获得锁的线程，如果后续没有其他线程获得过这个锁，持有锁的线程就永远不需要进行同步，反之，当有其他线程竞争偏向锁时，持有偏向锁的线程就会释放偏向锁。可以用过设置-XX:+UseBiasedLocking开启偏向锁。

轻量级锁主要就是通过CAS修改对象头锁记录和自旋来实现

复制了一份mark work 叫 Lock record 也是cas尝试改变指针

JVM的对象的对象头中包含有一些锁的标志位，代码进入同步块的时候，JVM将会使用CAS方式来尝试获取锁，如果更新成功则会把对象头中的状态位标记为轻量级锁，如果更新失败，当前线程就尝试自旋来获得锁。

除了拥有锁的线程其他全部阻塞。

死循环

由于大部分时候，锁被占用的时间很短，共享变量的锁定时间也很短，所有没有必要挂起线程，用户态和内核态的来回上下文切换严重影响性能。自旋的概念就是让线程执行一个忙循环，可以理解为就是啥也不干，防止从用户态转入内核态，自旋锁可以通过设置-XX:+UseSpining来开启，自旋的默认次数是10次，可以使用-XX:PreBlockSpin设置。

自适应锁就是自适应的自旋锁，自旋的时间不是固定时间，而是由前一次在同一个锁上的自旋时间和锁的持有者状态来决定。

锁消除指的是JVM检测到一些同步的代码块，完全不存在数据竞争的场景，也就是不需要加锁，就会进行锁消除。

锁粗化指的是有很多操作都是对同一个对象进行加锁，就会把锁的同步范围扩展到整个操作序列之外。

为了提高程序的执行效率，编译器和CPU会对程序中代码进行重排序。

as-if-serial

happens-before

工作内存强制刷新主内存的数据

单一线程持有

在第一个线程获取到锁之后，在他执行完之前不允许其他的线程获取锁并操作共享数据，

计数器

可重入的函数一定是线程安全的，反之则不一定成立

线程请求一个由其它线程持有的对象锁时，该线程会阻塞，而当线程请求由自己持有的对象锁时，如果该锁是重入锁，请求就会成功，否则阻塞。

若一个程序或子程序可以“在任意时刻被中断然后操作系统调度执行另外一段代码，这段代码又调用了该子程序不会出错”，则称其为可重入（reentrant或re-entrant）的。即当该子程序正在运行时，执行线程可以再次进入并执行它，仍然获得符合设计时预期的结果。与多线程并发执行的线程安全不同，可重入强调对单个线程执行时重新进入同一个子程序仍然是安全的

锁升级不可逆

从set方法我们可以看到，首先获取到了当前线程t，然后调用getMap获取ThreadLocalMap，如果map存在，则将当前线程对象t作为key，要存储的对象作为value存到map里面去。如果该Map不存在，则初始化一个。

首先获取当前线程，然后调用getMap方法获取一个ThreadLocalMap，如果map不为null，那就使用当前线程作为ThreadLocalMap的Entry的键，然后值就作为相应的的值，如果没有那就设置一个初始值。

ReadLock

WriteLock

有两个子类用于sync的初始化，FairSync和NonfairSync。这其实就是我们所熟知的公平锁和非公平锁。ReentrantLock默认情况下使用了非公平锁，当然也可以在创建ReentrantLock的时候显示指定。

NonfairSync

FairSync

AbstractQueuedSynchronizer

ReentrantLock通过使用AQS来实现加解锁

CAS

// 获取锁
void lock()

// 如果当前线程未被中断，则获取锁，可以响应中断
void lockInterruptibly()

// 返回绑定到此 Lock 实例的新 Condition 实例
Condition newCondition()

// 仅在调用时锁为空闲状态才获取该锁，可以响应中断
boolean tryLock()

// 如果锁在给定的等待时间内空闲，并且当前线程未被中断，则获取锁
boolean tryLock(long time, TimeUnit unit)

// 释放锁  unlock()

当第二个操作是volatile写时，不管第一个操作是什么，都不能重排序。这个规则确保volatile写之前的操作不会被编译器重排序到volatile写之后。
当第一个操作是volatile读时，不管第二个操作是什么，都不能重排序。这个规则确保volatile读之后的操作不会被编译器重排序到volatile读之前。
当第一个操作是volatile写，第二个操作是volatile读时，不能重排序。

总线风暴

处理器嗅探总线

lock 前缀指令 内存屏障

volatile变量规则：对一个volatile域的写，happens-before于任意后续对这个volatile域的读。

as-if-serial语义的意思是：不管编译器和CPU如何重排序，必须保证在单线程情况下程序的结果是正确的。

编译器和处理器不会对存在数据依赖关系的操作做重排序，因为这种重排序会改变执行结果。但是，如果操作之间不存在数据依赖关系，这些操作就可能被编译器和处理器重排序。例如：修改顺序后运算结果改变

.实例化时工作队列使用延时队列（DelayedWorkQueue）

提交的任务装饰成ScheduledFutureTask类型，并把任务加入到工作队列

ScheduledFutureTask实现Delayed和Comparable接口，提交到工作队列中的任务是按照任务执行时间排序的（最早执行的任务在头部），因为工作队列是个小顶堆

只能从工作队列中获取已到执行时间的任务

corePoolSize：核心线程池大小

maximumPoolSize: 线程池最大大小

workQueue: 任务的缓存队列，必须是阻塞队列

keepAliveTime 非核心线程等待超时时间

RejectedExecutionHandler：拒绝策略（线程池无法执行该任务时的处理策略）

threadFactory 控制线程创建的工作

unit 时间单位

线程工厂(ThreadFactory)

调用线程可以根据返回的Future对象获取任务执行结果

Worker是通过继承AQS，使用AQS来实现独占锁这个功能

lock方法一旦获取了独占锁，表示当前线程正在执行任务中。则不应该中断线程

如果该线程现在不是独占锁的状态，也就是空闲的状态，说明它没有在处理任务，这时可以对该线程进行中断。

线程池在执行shutdown方法或tryTerminate方法时会调用interruptIdleWorkers方法来中断空闲的线程，interruptIdleWorkers方法会使用tryLock方法来判断线程池中的线程是否是空闲状态；如果线程是空闲状态则可以安全回收。

Worker被创建出来后，就会不断地进行轮询，然后获取任务去执行，核心线程可以无限等待获取任务，非核心线程要限时获取任务。当Worker无法获取到任务，也就是获取的任务为空时，循环会结束，Worker会主动消除自身在线程池内的引用。

volatile关键字修饰变量，就是告知线程对该变量的访问必须重主内存中获取。而对它的改变必须同步刷新到主内存中。这样就能保证线程对变量访问的可见性。

关键字synchronized可以修饰方法或者代码块，使用synchronized可以确保多个线程在同一时刻，只能有一个线程处于方法或者同步块中，它保证了线程对变量访问的可见性和排他性。

（monitor)，获取到该对象的监视器才能进入同步块，或者同步方法，而没有获取到监视器(monitor)的线程会阻塞在同步块或者同步方法的入口，进入BLOCKED状态

wait()/notify()

wait()/notifyAll

notify()/notifyAll()

Object

courrent包下的Lock

CountDownLatch是一个同步的辅助类，允许一个或多个线程一直等待，直到其它线程完成它们的操作。

创建CountDownLatch并设置计数器值。

启动多线程并且调用CountDownLatch实例的countDown()方法。

主线程调用 await() 方法，这样主线程的操作就会在这个方法上阻塞，直到其他线程完成各自的任务，count值为0，停止阻塞，主线程继续执行。

说白了就是通过count变量来控制等待，如果count值为0了(其他线程的任务都完成了)，那就可以继续执行。

CyclicBarrier允许一组线程互相等待，直到到达某个点。

叫做cyclic是因为当所有等待线程都被释放以后，CyclicBarrier可以被重用(对比于CountDownLatch是不能重用的)

区别：CountDownLatch注重的是等待其他线程完成；CyclicBarrier注重的是：当线程到达某个状态后，暂停下来等待其他线程，所有线程均到达以后，继续执行。

第一个是缩小锁的范围：将与锁无关代码移除同步代码块，尤其是那些可能发生阻塞的操作比如I/O；

第二个是减少锁的粒度：使用多个相互独立锁管理独立的状态变量，改变某个变量只用获取对应变量锁，而不用获取整体锁，其他线程仍然能使用其他变量。

第三个是锁分段：比如ConcurrentHashMap底层的链表数组，对数组中每一个数组元素进行加锁，数组长度是多少就有多少个锁，也就最大支持多少并发。

写时复制

在往集合中添加数据的时候，先拷贝存储的数组，然后添加元素到拷贝好的数组中，然后用现在的数组去替换成员变量的数组（就是get等读取操作读取的数组）。

比读写锁有改进的地方，那就是读取的时候可以写入的 ，这样省去了读写之间的竞争

存放对象实例

新生代

存放局部变量的数据信息

可以运行的.class文件

用于存储编译器产生的字面量和符号引用。这部分内容在类被加载后，都会存储到方法区中的RCP。值得注意的是，运行时产生的新常量也可以被放入常量池中，比如 String 类中的 intern() 方法产生的常量。

加载类的时候优先加载jdk的核心类库（lib目录），再去加载jdk的扩展类库（lib/ext目录），最后再加载应该程序的类。

对象存活比较多的时候适用

老年代

提前GC

碎片空间

扫描了两次

存活对象少 比较高效

扫描了整个空间（标记存活对象并复制异动）

适合年轻代

需要空闲空间

需要复制移动对象

年轻

老年

永久

对cpu资源敏感

无法处理浮动垃圾

基于标记清除算法 大量空间碎片

初始标记 stw 从gc root 开始直接可达的对象

并发标记 gc root 对对象进行可达性分析 找出存活对象

最终标记

筛选回收

young gc

mixed gc

-XX:newSize设置绝对大小

invokeBeanFactoryPostProcessors

能不能实例化 需要实例化么 根据信息来

是否单例等等

判断是不是factory bean

单例池  只是一个ConcurrentHashMap而已

正在创建的 容器

根据注入模型

默认

自动注入

三级缓存没自己 因二级之后去加载B了

GC

产生bean 复杂

实现接口

asm字节码编辑技术动态创建类 基于classLoad装载

生成一个class对象

文件格式验证

元数据验证

字节码验证

符号引用验证

默认值

static会分配内存

解析具体类的信息

父类没初始化 先初始化父类

a. sinter命令可以获得A和B两个用户的共同好友 

b. sismember命令可以判断A是否是B的好友

c. scard命令可以获取好友数量 

d. 关注时，smove命令可以将B从A的粉丝集合转移到A的好友集合

只需要调整前后节点指针

还会比较value

成绩

积分

排行榜

键值的底层都是SDS

AOF缓存区

记录本身长度  C需要遍历

修改字符减少内存重新分配

二进制安全

杜绝缓冲区溢出

兼容部分C字符串函数

保存多个客户端的状态信息

列表订阅发布  慢查询  监视器

数据库  哈希键

Hash表节点

hash冲突用单向链表解决

渐进式 rehash

每个字典带 两个hash表

5分钟一次

冷备

恢复的时候比较快

缺点

通过保存Redis服务器所执行的写命令来记录数据库状态。

配置

数据齐全

回复慢文件大

从节点发送命令主节点做bgsave同时开启buffer

指令流

Redis的主从同步机制可以确保redis的master和slave之间的数据同步。

全量复制和增量复制

问题

RDB

横向扩容

针对很多Key

集群部署

加随机值

使用互斥锁，但是该方案吞吐量明显下降了；

针对一个热点Key

互斥锁

热点数据不失效

布隆过滤器

缓存空值

利用互斥锁，缓存失效的时候，先去获得锁，得到锁了，再去请求数据库，没得到锁，则休眠一段时间重试；

延时双删

这种情况下，准备一个分布式锁，大家去抢锁，抢到锁就做Set操作即可，比较简单。
如果对这个Key操作要求顺序
假设有一个Key1，系统A需要将Key1设置为ValueA，系统B需要将Key1设置为ValueB，系统C需要将Key1设置为ValueC。期望按照Key1的Value值按照 ValueA→ValueB→ValueC的顺序变化。这种时候我们在数据写入数据库的时候，需要保存一个时间戳。假设时间戳如下：系统A Key 1 {ValueA 3:00}系统B Key 1 {ValueB 3:05}系统C Key 1 {ValueC 3:10}那么，假设这会系统B先抢到锁，将Key1设置为{ValueB 3:05}。接下来系统A抢到锁，发现自己的ValueA的时间戳早于缓存中的时间戳，那就不做Set操作了。以此类推。

创建一个定时器

不再是Redis去主动删除，而是在客户端要获取某个key的时候，Redis会先去检测一下这个key是否已经过期

Redis默认每隔100ms就随机抽取一些设置了过期时间的key，检测这些key是否过期，如果过期了就将其删掉。

创建 redis 备份文件也可以使用命令 BGSAVE，该命令在后台执行。

如果需要恢复数据，只需将备份文件 (dump.rdb) 移动到 redis 安装目录并启动服务即可。获取 redis 目录可以使用 CONFIG 命令

将请求打造成一个zset数组，当每一次请求进来的时候，value保持唯一，可以用UUID生成，而score可以用当前时间戳表示，因为score我们可以用来计算当前时间戳之内有多少的请求数量。而zset数据结构也提供了range方法让我们可以很轻易的获取到2个时间戳内有多少请求

空轮训

Hash

由于redis是单线程运行的，如果一次操作的value很大会对整个redis的响应时间造成负面影响，导致IO网络拥

(1)利用二级缓存

即将热点Key+随机数，随机分配至Redis其他节点中。这样访问热点key的时候就不会全部命中到一台机器上了。

Redis-client在操作的时候，会产生具有不同事件类型的Socket。在服务端，有一段I/O多路复用程序，将其置入队列之中。然后文件事件分派器依次去队列中取，转发到不同的事件处理器中。

 read得读到很多才返回 为0会卡在那 直到新数据来或者链接关闭

写不会阻塞除非缓冲区满了

非阻塞的IO 提供了一个选项 no_blocking 读写都不会阻塞  读多少写多少 取决于内核的套接字字节分配

非阻塞IO也有问题 线程要读数据 读了一点就返回了 线程什么时候知道继续读？写一样

一般都是select解决 但是性能低 现在都是epoll

现在我们是三个主节点分别是：A, B, C 三个节点，它们可以是一台机器上的三个端口，也可以是三台不同的服务器。那么，采用哈希槽 (hash slot)的方式来分配16384个slot 的话，它们三个节点分别承担的slot 区间是：
节点A覆盖0－5460;
节点B覆盖5461－10922;
节点C覆盖10923－16383.

B树是一棵多叉查找树树，一个节点可以拥有两个以上的节点。

B树的非叶子节点上也有完整的行数据，B+树只在叶子节点上有数据，非叶子节点上只有键，优点是内存中存放的键数量更多，查找更快。

B+树的叶子节点上包含所有的键，B树的叶子节点上不一定有所有的键。

B+树的叶子节点通过链表进行连接，范围查询更加快速。

相比于二叉树而言，B树最大的优点在于中间层可以存放于内存中，且相同数据量的情况下，B树的高度低于二叉树，可以减少查找的过程，从而加快存储速度

使hash索引的查找速度很快，在使用时却也不一定比B+Tree更好。

hash索引无法处理范围查询，范围查询速度较慢；

hash索引无法避免排序运算；

hash索引不能利用部分索引键查询，组合索引的场景下，hash索引需要将多个索引键进行合并计算hash值，无法单独利用；

hash索引不可避免地存在表扫描地情况，即使通过hash定位到数据，仍然需要对原始数据进行对比，才可以查找到正确地数据；

hash索引在大量hash值相等地情况下，性能并不一定比B-Tree索引高。

最基本的索引类型，没有唯一性之类的限制。

数据库表经常有一列或列组合，其值唯一标识表中的每一行。
该列称为表的主键。

。该索引要求主键中的每个值都唯一

使用主键索引时，它还允许对数据的快速访问。

唯一索引是不允许其中任何两行具有相同索引值的索引。

在聚集索引中，表中行的物理顺序与键值的逻辑（索引）顺序相同。一个表只能包含一个聚集索引。

多扫描一次

也称非聚集索引。在非聚集索引中，数据库表中记录的物理顺序与索引顺序可以不相同。一个表中只能有一个聚集索引，但表中的每一列都可以有自己的非聚集索引。

联合索引是由多个字段组成的索引。其中，只有第一个字段是有序的，其他字段仅在前面字段相等的情况下有序，但从整体的角度而言，是无序的。

应用于联合索引的非常重要的原则，即查询时，会按照联合索引建立的顺序，从左到右进行匹配。

对于联合索引，MySQL 会一直向右匹配直到遇到范围查询（> ， < ，between，like）就停止匹配。比如 a = 3 and b = 4 and c > 5 and d = 6，如果建立的是（a,b,c,d）这种顺序的索引，那么 d 是用不到索引的，但是如果建立的是 （a,b,d,c）这种顺序的索引的话，那么就没问题，而且 a，b，d 的顺序可以随意调换。

= 和 in 可以乱序，比如 a = 3 and b = 4 and c = 5 建立 （a，b，c）索引可以任意顺序。

如果建立的索引顺序是 （a，b）那么直接采用 where b = 5 这种查询条件是无法利用到索引的，这一条最能体现最左匹配的特性。

在MySQL中，会自动为主键创建主键索引，同时，主键索引上包含所有的数据。而对于其他的所有非主键索引，非主键索引中只包含索引键和主键数据。因此在非主键索引上查询到主键后，需要通过该主键在主键索引上查找数据，这个过程称为“回表”。

当select语句查询的内容，在非主键索引上就已经全部包含，不需要再进入主键索引查找时，称为“覆盖索引”。

索引查询时时常带有where语句，当多个条件并列，且条件在索引数据中包含时，MySQL会使用“索引下推”在索引上进行匹配，过滤以减少数据，加快查询速度。

不需要多个回表  一边遍历 一边判断

hash

比如复合索引：a->b->c，当 where a="" and b>10 and 3=""，这时候只能用到 a 和 b，c 用不到索引，因为在范围之后索引都失效（和 B+树结构有关）

InnoDB会进行change buffering操作。将更改排入队列，之后再在后台将其合并到索引中。甚至，为了后续物理更新更加高效，会将变更进行合并。

这种特性不需要手动开启，而是默认开启的。在MySQL5.1版本，change buffering操作仅仅适用于insert。而在MySQL5.5版本之后，change buffering操作则扩展到update和delete里

记录在页内存

记录不再页中

数据读是随机IO 成本高 

机械硬盘 change buffer 收益大 写多读少 marge

读取的记录的事务ID小于低水位，说明这个版本的数据在开启本事务前已经提交，是可见的，直接返回这个数据

读取的记录的事务ID大于高水位，说明这个版本的数据在开启本事务后提交的，不可见，从记录中取出 DBROLLPTR 指向的记录并读取其事务 ID，开始下一轮的判断

读取的记录的事务ID介于低水位和高水位中间，此时判断事务ID是否在一致性视图的事务数组中：
1，如果不在，说明这个版本的数据在开启本事务前已经提交，是可见的，直接返回这个数据
2，如果在，说明这个版本的数据是由开启事务后的其他活跃事务提交的，对本事务是不可见的，因此需要从记录中取出 DBROLLPTR 指向的记录并读取其事务 ID，开始下一轮的判断

每次读取前生成一个

第一次生成一个

MySQL5.5引入 自动添加 读锁不互斥 写锁互斥

多个事务之前操作，如果查询的时候修改字段容易让线程池饱满

超时时间

死锁机制 事务回滚

死锁消耗CPU

控制并发度

分治

lock in share mode

for update

行锁

sync_binlog 可以优化日志写入时机

客户端空闲时间

 删除整个表（结构和数据）

DELETE 可以是 table 和 view

TRUNCATE 只能对 TABLE

truncate table 在功能上 与不带 WHERE 子句的 DELETE 语句相同

MySQL的慢查询日志用来记录在MySQL中响应时间超过参数 long_query_time（单位秒，默认值 10）设置的值并且扫描记录数不小于 min_examined_row_limit（默认值 0）的语句，

开启慢查询日志

设置慢查询阀值

确定慢查询日志路径

确定慢查询日志的文件名

根据上面的查询结果，可以直接查看 /data/mysql/data/3306/mysql-slow.log 文件获取已经执行完的慢查询

like "%张三%"      like "%张三"

双路排序

单路排序

a->c：a 有效，c 无效 b->c：b、c 都无效 c：c 无效

buffer pool

机械磁盘的随机io不太行 减少随机io性能大幅提升 设置为 1最好

现在都是ssd了 设置为0就够了 8.0之后默认是0

• 轻量级：一个 callback 函数。 • 异步性：不会 block 正常的读写请求。 • 主动推送：Watch 被触发时，由 Zookeeper 服务端主动将更新推送给客 户端。 • 一次性：数据变化时，Watch 只会被触发一次。如果客户端想得到后续更 新的通知，必须要在 Watch 被触发后重新注册一个 Watch。 • 仅通知：仅通知变更类型，不附带变更后的结果。 • 顺序性：如果多个更新触发了多个 Watch，那 Watch 被触发的顺序与更 新顺序一致

由于 watcher 是一次性的，所以需要自己去实现永久 watch

如果被 watch 的节点频繁更新，会出现“丢数据”的情况

watcher 数量过多会导致性能下降

第一类，在约定目录下创建临时目录节点，监听节点数目是否是我 们要求的数目

 第二类，和分布式锁服务中的控制时序场景基本原理一致，
入列有编号，出列按编号。在特定的目录下创建 PERSISTENT_SEQUENTIAL
节点，创建成功时 Watcher 通知等待的队列，队列删除序列号最小的节点用
以消费。此场景下 Zookeeper 的 znode 用于消息存储，znode 存储的数据就
是消息队列中的消息内容，SEQUENTIAL 序列号就是消息的编号，按序取出
即可。由于创建的节点是持久化的，所以不必担心队列消息的丢失问题。

IO多路复用

select

poll

epoll

监听事件

任务队列

任务队列

监听端口所有准备就绪的时间

监听准备工作

头部是固定长度的，然后头部里面会填写 body 的长度， body 是不固定长度的，这样伸缩性就比较好了，可以先解析头部，然后根据头部得到 body 的 len 然后解析 body。

get provider

set provider

各种信息 保存在 ServiceBean

是否暴露 不是延迟暴露

检查

doexportURL 暴露URL

注册到注册表进去

Java SPI 在查找扩展实现类的时候遍历 SPI 的配置文件并且将实现类全部实例化，假设一个实现类初始化过程比较消耗资源且耗时，但是你的代码里面又用不上它，这就产生了资源的浪费。

为什么用 Javassist，很简单，就是快，且字节码生成方便。 ASM 比 Javassist 更快，但是没有快一个数量级，而Javassist 只需用字符串拼接就可以生成字节码，而 ASM 需要手工生成，成本较高，比较麻烦。

聚集索引

快速失败，当请求失败之后快速返回异常结果，不做任何重试。改容错机制会对请求做负载均衡，通常使用在非幂等性的接口上。该机制受网络抖动的影响较大。

同步

异步

单向

优点

缺点

即使磁盘损坏，消息丢失的非常少，且消息实时性不会受影响，同时Master宕机后，消费者仍然可以从Slave消费，而且此过程对应用透明，不需要人工干预，性能同多Master模式几乎一样；

Master宕机，磁盘损坏情况下会丢失少量消息。

数据与服务都无单点故障，Master宕机情况下，消息无延迟，服务可用性与数据可用性都非常高；

性能比异步复制模式略低（大约低10%左右），发送单个消息的RT会略高，且目前版本在主节点宕机后，备机不能自动切换为主机。

# 开启消息轨迹 traceTopicEnable=true

消息被写入内存的PAGECACHE，返回写成功状态，当内存里的消息量积累到一定程度时，统一触发写磁盘操作，快速写入 。吞吐量高，当磁盘损坏时，会丢失消息

消息写入内存的PAGECACHE后，立刻通知刷盘线程刷盘，然后等待刷盘完成，刷盘线程执行完成后唤醒等待的线程，给应用返回消息写成功的状态。吞吐量低，但不会造成消息丢失

master和slave均写成功，才返回客户端成功。maste挂了以后可以保证数据不丢失，但是同步复制会增加数据写入延迟，降低吞吐量

master写成功，返回客户端成功。拥有较低的延迟和较高的吞吐量，但是当master出现故障后，有可能造成数据丢失

顺序发送 顺序消费由 消费者保证