Java全面面试宝典

原理上来说：ConcurrentHashMap 采用了分段锁技术，其中 Segment /ˈseɡmənt/继承于 ReentrantLock。不会像 HashTable 那样不管是 put 还是 get 操作都需要做同步处理，理论上 ConcurrentHashMap 支持 CurrencyLevel (Segment 数组数量)的线程并发。每当一个线程占用锁访问一个 Segment 时，不会影响到其他的 Segment。所以每次都需要先hash到segment，然后再次hash到hashEntry。跟hashMap一样也是通过bit位运算定位index。其实这个加锁的粒度还是挺大的--加锁的是segment，然后segment下面的HashEntry[]才是真正放数据的地方，然后每个HashEntry又可能是一个链表。比如两个线程都定位到同一个segment，这时候就需要先获取到segment锁，才能进行。如果锁的是segment下面的HashEntry粒度就会小很多（这句话是帮助理解锁segment粒度过大）。segment跟HashEntry[]默认都是16个

Java8中 ConcurrentHashMap基于分段锁+CAS保证线程安全，分段锁基于synchronized关键字实现；当node=null的时候直接通过CAS保证并发，当不为空的时候通过synchronize加锁。这里是通过对每一个node加锁（或者CAS），粒度比jdk1.7的时候对一个大的segment加Lock锁粒度小多了

put 方法

get方法

put方法

初始化table方法initTable()

get方法

• Arraylist： Object[]数组
• Vector：Object[]数组
• LinkedList： 双向链表(JDK1.6 之前为循环链表，JDK1.7 取消了循环)

• HashSet（无序，唯一）: 基于 HashMap 实现的，底层采用 HashMap 来保存元素
• LinkedHashSet：LinkedHashSet 是 HashSet 的子类，并且其内部是通过 LinkedHashMap 来实现的。有点类似于我们之前说的 LinkedHashMap 其内部是基于 HashMap 实现一样，不过还是有一点点区别的
• TreeSet（有序，唯一）： 红黑树(自平衡的排序二叉树)

HashMap： JDK1.8 之前 HashMap 由数组+链表组成的，数组是 HashMap 的主体，链表则是主要为了解决哈希冲突而存在的（“拉链法”解决冲突）。JDK1.8 以后在解决哈希冲突时有了较大的变化，当链表长度大于阈值（默认为 8）（将链表转换成红黑树前会判断，如果当前数组的长度小于 64，那么会选择先进行数组扩容，而不是转换为红黑树）时，将链表转化为红黑树，以减少搜索时间

LinkedHashMap： LinkedHashMap 继承自 HashMap，所以它的底层仍然是基于拉链式散列结构即由数组和链表或红黑树组成。另外，LinkedHashMap 在上面结构的基础上，增加了一条双向链表，使得上面的结构可以保持键值对的插入顺序。同时通过对链表进行相应的操作，实现了访问顺序相关逻辑

Hashtable： 数组+链表组成的，数组是 HashMap 的主体，链表则是主要为了解决哈希冲突而存在的

TreeMap： 红黑树（自平衡的排序二叉树）

因为 ConcurrentHashMap 是用于多线程的 ，如果ConcurrentHashMap.get(key)得到了 null ，这就无法判断，是映射的value是 null ，还是没有找到对应的key而为 null ，就有了二义性

我们用反证法来推理：

假设 ConcurrentHashMap 允许存放值为 null 的 value，这时有A、B两个线程，线程A调用ConcurrentHashMap.get(key)方法，返回为 null ，我们不知道这个 null 是没有映射的 null ，还是存的值就是 null 。

假设此时，返回为 null 的真实情况是没有找到对应的 key。那么，我们可以用 ConcurrentHashMap.containsKey(key)来验证我们的假设是否成立，我们期望的结果是返回 false 。

但是在我们调用 ConcurrentHashMap.get(key)方法之后，containsKey方法之前，线程B执行了ConcurrentHashMap.put(key, null)的操作。那么我们调用containsKey方法返回的就是 true 了，这就与我们的假设的真实情况不符合了，这就有了二义性。（因为可能是key没映射也有可能是value为空，所以你无法通过containsKey判断出来，而hashmap则可以通过containsKey判断出来）

这个问题其实有人问过了，而且Doug老爷子也回答了，就是value为空存在二义性，但是为什么key不能为空则没有明确说明。doug认为不管容器是否考虑了线程安全问题，都不应该允许null值的出现。他觉得在现有的某些集合里面允许了null值的出现，是集合的设计问题。他也一直在和Josh Bloch讨论这个事情

• Doug对Tutika遇到的问题给出了自己的建议：可以定义一个名称为NULL的全局的Object。当需要用null值的时候，用这个NULL来代替，以假乱真

COMMIT_MESSAGE,//提交事务，它允许消费者消费此消息

ROLLBACK_MESSAGE,//回滚事务，它代表该消息将被删除，不允许被消费

UNKNOW;//中间状态，它代表需要检查消息队列来确定状态，三天后删除

事务消息发送步骤

事务消息回查步骤

事务消息限制

消息交互流程图

Broker管理

路由信息管理

Remoting Module：整个Broker的实体，负责处理来自clients端的请求

Client Manager：负责管理客户端(Producer/Consumer)和维护Consumer的Topic订阅信息

Store Service：提供方便简单的API接口处理消息存储到物理硬盘和查询功能。

HA Service：高可用服务，提供Master Broker 和 Slave Broker之间的数据同步功能

Index Service：根据特定的Message key对投递到Broker的消息进行索引服务，以提供消息的快速查询

消息主体以及元数据的存储主体。顺序写入，消息内容不是定长的，理解成消息拼接。文件固定大小1G，文件名20位，左边补0，剩余为起始偏移量，如果文件写满，创建第二个文件，且文件名为起始偏移量

Kafka每个分区都有个commitlog文件，而rmq都在同一个log中，所以当topic多的时候rmq变现更好（延迟更低），因为文件多了顺序读写会影响到

一个queue一个consumeQueue文件，ConsumeQueue（逻辑消费队列）作为消费消息的索引，保存了指定Topic下的队列消息在CommitLog中的起始物理偏移量offset，消息大小size和消息Tag的HashCode值。consumequeue文件可以看成是基于topic的commitlog索引文件。采取定长设计，每一个条目共20个字节，分别为8字节的commitlog物理偏移量、4字节的消息长度、8字节tag hashcode，单个文件由30W个条目组成，可以像数组一样随机访问每一个条目，每个ConsumeQueue文件大小约5.72M

每个topic的队列会分布在不同的broker上，所以每台broker只保存自己的queue文件，并不是一个topic文件夹下面就有它全部的队列（比如brokerA的xxxx队列文件夹下只有1这个queue的文件夹）

IndexFile（索引文件）提供了一种可以通过key或时间区间来查询消息的方法。Index文件的存储位置是：$HOME \store\index${fileName}，文件名fileName是以创建时的时间戳命名的，固定的单个IndexFile文件大小：40+500W*4+2000W*20=420000040个字节大小，约为400M，一个IndexFile可以保存 2000W个索引，IndexFile的底层存储设计为在文件系统中实现HashMap结构，故rocketmq的索引文件其底层实现为hash索引。索引文件由索引文件头 40byte（IndexHeader）+4byte（ 槽位 Slot ）+20byte（消息的索引内容）三部分构成

这些文件是将RocketMQ的一些关键配置信息进行存盘保存。例如Topic配置、消费者组配置、消费者组消息偏移量Offset 等等一些信息

这个文件是RocketMQ用来判断程序是否正常关闭的一个标识文件。正常情况下，会在启动时创建，而关闭服务时删除。但是如果遇到一些服务器宕机，或者kill -9这样一些非正常关闭服务的情况，这个abort文件就不会删除，因此RocketMQ就可以判断上一次服务是非正常关闭的，后续就会做一些数据恢复的操作

数据存盘检查点

RocketMQ中的MessageId的长度总共有16字节，其中包含了消息存储主机地址（IP地址和端口），消息Commit Log offset。“按照MessageId查询消息”在RocketMQ中具体做法是：Client端从MessageId中解析出Broker的地址（IP地址和端口）和Commit Log 的偏移地址后封装成一个RPC请求后通过Remoting通信层发送（业务请求码：VIEW_MESSAGE_BY_ID）。Broker端走的是QueryMessageProcessor，读取消息的过程用其中的 commitLog offset 和 size 去 commitLog 中找到真正的记录并解析成一个完整的消息返回

按照Message Key查询消息，主要是基于RocketMQ的IndexFile索引文件来实现的。RocketMQ的索引文件逻辑结构，类似JDK中HashMap的实现，按照Message Key查询消息”的方式，RocketMQ的具体做法是，主要通过Broker端的QueryMessageProcessor业务处理器来查询，读取消息的过程就是用topic和key找到IndexFile索引文件中的一条记录，根据其中的commitLog offset从CommitLog文件中读取消息的实体内容

只有在消息真正持久化至磁盘后RocketMQ的Broker端才会真正返回给Producer端一个成功的ACK响应。同步刷盘对MQ消息可靠性来说是一种不错的保障，但是性能上会有较大影响，一般适用于金融业务应用该模式较多

能够充分利用OS【操作系统】内存的PageCache的优势，只要消息写入PageCache即可将成功的ACK返回给Producer端。消息刷盘采用后台异步线程提交的方式进行，降低了读写延迟，提高了MQ的性能和吞吐量

刷盘方式是通过Broker配置文件里的flushDiskType 参数设置的，这个参数被配置成SYNC_FLUSH（同步）、ASYNC_FLUSH（异步）中的 一个

页缓存（PageCache)是OS对文件的缓存，用于加速对文件的读写。一般来说，程序对文件进行顺序读写的速度几乎接近于内存的读写速度，主要原因就是由于OS使用PageCache机制对读写访问操作进行了性能优化，将一部分的内存用作PageCache。对于数据的写入，OS会先写入至Cache内，随后通过异步的方式由pdflush内核线程将Cache内的数据刷盘至物理磁盘上。对于数据的读取，如果一次读取文件时出现未命中PageCache的情况，OS从物理磁盘上访问读取文件的同时，会顺序对其他相邻块的数据文件进行预读取

同步复制是等Master和Slave都写入消息成功后才反馈给客户端写入成功的状态。在同步复制下，如果Master节点故障，Slave上有全部的数据备份，这样容易恢复数据。但是同步复制会增大数据写入的延迟，降低系统的吞吐量

异步复制是只要master写入消息成功，就反馈给客户端写入成功的状态。然后再异步的将消息复制给Slave节点。在异步复制下，系统拥有较低的延迟和较高的吞吐量。但是如果master节点故障，而有些数据没有完成复制，就会造成数据丢失

消息复制方式是通过Broker配置文件里的brokerRole参数进行设置的，这个参数可以被设置成ASYNC_MASTER（异步）、 SYNC_MASTER（同步）、SLAVE三个值中的一个

Producer发送消息时，默认会轮询目标Topic下的所有MessageQueue，并采用递增取模（也就是轮训，比如count++，count%queueNum）的方式往不同的MessageQueue上发送消息，以达到让消息平均落在不同的queue上的目的。而由于MessageQueue是分布在不同的Broker上的，所以消息也会发送到不同的broker上

集群模式

广播模式

Producer的send方法本身支持内部重试，重试逻辑如下：

• 1：至多重试2次（同步发送为2次，异步发送为0次）
• 2：如果发送失败，则轮转到下一个Broker。这个方法的总耗时不超过sendMsgTimeout设置的值，默认10s
• 3：如果本身向broker发送消息产生超时异常，就不会再重试。

可以通过((MessageExt) msg).getReconsumeTimes()获取到消息重试次数，进而业务处理，比如超过三次就落db人工兜底

注意 消费者和生产者的重试还是有区别的：

• 默认重试次数：Product默认是2次，而Consumer默认是16次。
• 重试时间间隔：Product是立刻重试，而Consumer是有一定时间间隔的。
• Product在异步情况重试失效，而对于Consumer在广播情况下重试失效

重试消息rocketmq内部如何处理

一个死信队列对应一个ConsumGroup，而不是对应某个消费者实例

如果一个ConsumeGroup没有产生死信队列，RocketMQ就不会为其创建相应的死信队列

一个死信队列包含了这个ConsumeGroup里的所有死信消息，而不区分该消息属于哪个Topic

死信队列中的消息不会再被消费者正常消费，除非人工去修改队列的权限

死信队列的有效期跟正常消息相同。默认3天，对应broker.conf中的fileReservedTime属性。超过这个最长时间的消息都会被删除，而不管消息是否消费过

1：生产者发送消息到broker丢失消息

2：master节点同步消息到slave丢失

3：消息刷盘丢失消息

4：消费者消费的时候实际没消费成功结果ack返回的成功，比如你异步去处理消息，主线程返回成功ack

生产者使用事务消息机制，当然直接采用同步发送机制也不是不行，productor存在重试机制（虽然只有两次）

Broker配置同步刷盘+Dledger主从架构

消费者不要使用异步消费

整个MQ挂了之后准备降级方案

对于局部有序的要求，只需要将有序的一组消息都存入同一个MessageQueue里，这样MessageQueue的FIFO设计天生就可以保证这一组消息的有序。RocketMQ中，可以在发送者发送消息时指定一个MessageSelector对象（消费者不能哦，但是可以自定义消费者负载），让这个对象来决定消息发入哪一个MessageQueue。这样就可以保证一组有序的消息能够发到同一个MessageQueue里（通过同一组消息的唯一标识对queue数量取模，比如orderId）

只能通过保证只有一个队列来进行处理，但有多少这种需求？反而降低性能，都没必要用mq了

直接通过控制台查看消息消费差值

也可以通过mqadmin指令在后台检查各个Topic的消息延迟情况

还有RocketMQ也会在他的 ${storePathRootDir}/config 目录下落地一系列的json文件，也可以用来跟踪消息积压情况

Topic下的MessageQueue配置得是足够多

Topic下的MessageQueue配置不多

操作系统层面如何处理socket

设计思想：假如能够预先传入一个 Socket 列表，如果列表中的 Socket 都没有数据，挂起进程，直到有一个 Socket 收到数据，唤醒进程。这种方法很直接，也是 Select 的设计思想
实现方法：操作系统实现的时候，将进程放入每个需要监听的socket等待队列中去，只要某个socket有数据了进程也就能够被唤醒（所谓唤起进程，就是将进程从所有的等待队列中移除，加入到cpu工作队列里面）

当进程 A 被唤醒后，它知道至少有一个 Socket 接收了数据。程序只需遍历一遍 Socket 列表，就可以得到就绪的 Socket

select存在的缺点：

• 每次调用 Select 都需要将进程加入到所有监视 Socket 的等待队列，每次唤醒都需要从每个队列中移除。这里涉及了两次遍历，而且每次都要将整个 FDS 列表传递给内核，有一定的开销（正是因为遍历操作开销大，出于效率的考量，才会规定 Select 的最大监视数量，默认只能监视 1024 个 Socket）
• 进程被唤醒后，程序并不知道哪些 Socket 收到数据，还需要遍历一次

1.相比select, 把fd的bitMap变为了fd的链表, 2.fd的个数上限大于1024个, 但依旧会有用户态和内核态切换的性能问题. 3.依旧存在时间复杂度O(n)的问题, 提升性能不大

Epoll 的设计思路

Epoll 的原理与工作流程

epoll使用到的数据结构

select跟poll都是直接将进程放入每个socket的等待队列中，而epoll则是放入eventpoll到每个socket的等待队列，然后进程放入eventpoll的等待队列，这样间接实现了功能。当某个socket收到数据的时候会操作eventpoll中介（并不会将epoll对象从socket的等待队列中移除），接着将存在事件的socket放入它的“就绪列表”rdlist中，我们的进程阻塞在eventpoll中的等待队列：如果“就绪列表”rdlist不为空则唤醒进程，为空则阻塞进程（唤醒进程后会从epoll的等待队列移除，做完事后再将进程放回epoll等待队列中，这里只会放到epoll一个上，为O（1））
epoll是个对象并不是个进程，中断程序操作这个对象，将有数据socket添加到epoll对象的就绪列表中，此时就绪列表不为空，epoll_wait立即返回，唤醒进程

结合上面说的设计思想讲，相当于使用了eventpoll中介来 “维护等待队列” ，由eventpoll来管理需要维护那些socket，从而避免重复移除socket跟添加socket（本身需监视socket列表基本不会变）；通过eventpoll里的 “就绪列表” 来改变进场状态，进而实现阻塞与唤醒进程

使用IO复用，Linux下一般默认就是epoll，Java NIO在Linux下默认也是epoll机制，但是JDK中epoll的实现却是有漏洞的，其中最有名的java nio epoll bug就是即使是关注的select轮询事件返回数量为0，NIO照样不断的从select本应该阻塞的Selector.select()/Selector.select(timeout)中wake up出来，导致CPU 100%问题。

问题就是连接出现了RST，因为poll和epoll对于突然中断的连接socket会对返回的eventSet事件集合置为POLLHUP或者POLLERR，eventSet事件集合发生了变化，这就导致Selector会被唤醒，进而导致CPU 100%问题。根本原因就是JDK没有处理好这种情况，比如SelectionKey中就没定义有异常事件的类型。

nio epoll bug不是linux epoll的问题，而是JDK自己实现epoll时没有考虑这种情况，或者说因为其他系统不存在这个问题（java甩锅给到Linux），Linux出现这种情况的时候会置为POLLHUP或者POLLERR，而Java没有去处理这种异常情况，所以导致整个bug发生

一种是nio事件类型SelectionKey新加一种"错误"类型，比如针对linux epoll中的epollhup和epollerr，如果出现这种事件，建议程序直接close socket，但这种方式相对来说对于目前的nio SelectionKey改动有点大，因为SelectionKey的定义目前是针对所有jdk平台的；

还有一种是针对jdk nio 对epoll的封装中，对于epoll的epollhup和epollerr事件，epoll封装内部直接处理，比如close socket，但是这种方案也有一点尴尬的是，可能上层应用代码还保留有出现问题的socket引用，这时最好是应用程序能够感知这种情况来处理比较好。

当然模仿netty的处理方式也是可以的

1.对Selector的select操作周期进行统计，每完成一次空的select操作进行一次计数， 2.若在某个周期内连续发生N次空轮询，则认为触发了epoll死循环bug。 3.重建Selector，判断是否是其他线程发起的重建请求，若不是则将原SocketChannel从旧的Selector上去除注册，重新注册到新的Selector上，并将原来的Selector关闭。

1) Netty 抽象出两组线程池BossGroup和WorkerGroup，BossGroup专门负责接收客户端的连接, WorkerGroup专门负责网络的读写

2) BossGroup和WorkerGroup类型都是NioEventLoopGroup

3) NioEventLoopGroup 相当于一个事件循环线程组, 这个组中含有多个事件循环线程 ， 每一个事件循环线程是NioEventLoop

4) 每个NioEventLoop都有一个selector , 用于监听注册在其上的socketChannel的网络通讯

5) 每个Boss NioEventLoop线程内部循环执行的步骤有 3 步

• 处理accept事件 , 与client 建立连接 , 生成 NioSocketChannel
• 将NioSocketChannel注册到某个worker NIOEventLoop上的selector
• 处理任务队列的任务 ， 即runAllTasks

6) 每个worker NIOEventLoop线程循环执行的步骤

• 轮询注册到自己selector上的所有NioSocketChannel 的read, write事件
• 处理 I/O 事件， 即read , write 事件， 在对应NioSocketChannel 处理业务
• runAllTasks处理任务队列TaskQueue的任务 ，一些耗时的业务处理一般可以放入TaskQueue中慢慢处理，这样不影响数据在 pipeline 中的流动处理

7) 每个worker NIOEventLoop处理NioSocketChannel业务时，会使用 pipeline (管道)，管道中维护了很多 handler 处理器用来处理 channel 中的数据

1、创建ServerBootStrap实例
2、创建并绑定好两个线程组bossGroup和workerGroup，bossGroup用来处理连接事件，workerGroup用来处理读写事件
3、当bossGroup监听到连接事件后，将连接channel绑定到workerGroup中的一个selector中去
4、workerGroup中的selector监听到channel的读写事件后，交给管道ChannelPipeline处理
5、 ChannelPipeline 中又维护了一个由 ChannelHandlerContext 组成的双向链表，并且每个 ChannelHandlerContext 中又关联着一个 ChannelHandler
6、其中会帮我们创建好编解码和其他基本的ChannelHandler，也就通过责任链模式执行了

1、创建BootStrap实例 2、创建处理客户端的线程组 3、创建客户端连接的NioSocketChannel 4、创建pipeline管道与ChannelHandler

第一次握手：建立连接时，客户端发送syn包（syn=x）到服务器，并进入SYN_SENT状态，等待服务器确认；SYN：同步序列编号（Synchronize Sequence Numbers）。通俗讲就是客户端请求连接服务器

第二次握手：服务器收到syn包，必须确认客户的SYN（ack=x+1），同时自己也发送一个SYN包（syn=y），即SYN+ACK包，此时服务器进入SYN_RECV状态；通俗讲就是服务器接受客户端的连接请求，然后发送一个确认信息跟连接请求回去

第三次握手：客户端收到服务器的SYN+ACK包，向服务器发送确认包ACK(ack=y+1），此包发送完毕，客户端和服务器进入。通俗讲就是客户端接受服务端连接请求，发送确认信息回去

第一次：客户端请求断开FIN,seq=u，进入FIN-WAIT-1状态。通俗：客户端请求断开连接

第二次：服务器收到客户端的后，发出ACK=1确认标志和客户端的确认号ack=u+1，自己的序列号seq=v，进入CLOSE-WAIT状态。通俗：服务端确认客户端的断开请求，并告诉客户端我同意断开

第三次：客户端收到服务器确认结果后，进入FIN-WAIT-2状态。此时服务器发送断开FIN信号，确认标志ACK=1，确认序号ack=u+1，自己序号seq=w，服务器进入LAST-ACK（最后确认态）。通俗：服务端请求断开连接

第四次：客户端收到回复后，发送确认ACK=1，ack=w+1，自己的seq=u+1，客户端进入TIME-WAIT（时间等待）。客户端经过2个最长报文段寿命后，客户端CLOSE；服务器收到确认后，立刻进入CLOSE状态。通俗：客户端同意服务端断开请求，并告诉服务端我同意断开，服务端收到回复后立马断开，客户端经过2个最长报文段寿命后也断开

讲“三次握手”的目的是“为了防止已失效的连接请求报文段突然又传送到了服务端，因而产生错误”。怎么说呢？比如在第一次握手客户端请求连接服务端的时候请求丢失了（实际没有丢失，而是因为网络原因发的很慢），然后客户端又发送一个请求连接信息，此时其实存在两个请求连接服务端的信息，假设采用两次握手（客户端请求连接、服务端确认连接后直接开始连接了），当第一个消息在连接已经关闭后才到达服务端的话，服务端以为是客户端的新连接请求，然后服务端同意，但是此时客户端是没有这个连接请求的，这就白白浪费了服务端资源，搞得服务端认为新的连接已建立好，一直等待接收客户端的信息

虽然按道理，四个报文都发送完毕，我们可以直接进入CLOSE状态了，但是我们必须假象网络是不可靠的，有可以最后一个ACK丢失。所以TIME_WAIT状态就是用来重发可能丢失的ACK报文。Client端等待了2MSL后依然没有收到回复，则证明Server端已正常关闭，那好，我Client端也可以关闭连接了

虚拟机把描述类的数据从Class文件加载到内存，并对数据进行校验、转换解析和初始化，最终形成可以被虚拟机直接使用的Java类型，这就是虚拟机的类加载机制

1、加载（Loading）

2、验证（Verification）

3、准备（Preparation)

4、解析（Resolution）

5、初始化（Initialization）

6、使用（Using）

7、卸载（Unloading）

引导类加载器：负责加载支撑JVM运行的位于JRE的lib目录下的核心类库，比如rt.jar、charsets.jar等

扩展类加载器：负责加载支撑JVM运行的位于JRE的lib目录下的ext扩展目录中的JAR类包，父类加载器为引导类加载器，但是由于引导类为c++对象，所以父类为空

自定义加载器：负责加载用户自定义路径下的类包。父类加载器为应用程序加载器

1、首先通过java命令执行java程序的时候，会调用jvm.dll文件创建jvm虚拟机
2、创建一个引导类加载器实例
3、C++会调用java代码创建JVM启动器实例sun.misc.Launcher /laːntʃər/。sun.misc.Launcher初始化使用单例模式设计，保证一个JVM虚拟机内只有一个sun.misc.Launcher实例。
4、在Launcher构造方法内部，其创建了两个类加载器，分别是sun.misc.Launcher.ExtClassLoader(扩展类加载器)和sun.misc.Launcher.AppClassLoader(应用类加载器)。
5、JVM默认使用Launcher的getClassLoader()方法返回的类加载器AppClassLoader的实例加载我们的应用程序。

自定义类加载器只需要继承 java.lang.ClassLoader 类，该类有两个核心方法，一个是loadClass(String, boolean)，实现了双亲委派机制，还有一个方法是findClass（默认实现是空方法），所以我们自定义类加载器主要是重写findClass方法。而findClass方法中最重要的就是defineClass(name, res);也就是真正加载类的方法

案例讲解：首先复制User.class到D:/test/test也存在User.class文件，我们如果classpath下面存在User.class这个文件的时候，首先代码写的是先app加载，发现app中找到了，所以就返回了。如果删除classpath下面存在User.class，就是由我们自定义类加载器MyClassLoader加载的

双亲委派机制说简单点就是，先找父亲加载，不行再由儿子自己加载

比如我们的Math类，最先会找应用程序类加载器加载，应用程序类加载器会先委托扩展类加载器加载（这里不要想着Math不就是由app类加载器加载的吗，干嘛还要往上委托，下面会分析），扩展类加载器再委托引导类加载器，顶层引导类加载器在自己的类加载路径里找了半天没找到Math类，则向下退回加载Math类的请求，扩展类加载器收到回复就自己加载，在自己的类加载路径里找了半天也没找到Math类，又向下退回Math类的加载请求给应用程序类加载器，应用程序类加载器于是在自己的类加载路径里找Math类，结果找到了就自己加载了

从AppClassLoader源码看双亲委派机制，查看笔记

沙箱安全机制：自己写的java.lang.String.class类不会被加载，这样便可以防止核心API库被随意篡改

避免类的重复加载：当父亲已经加载了该类时，就没有必要子ClassLoader再加载一次，保证被加载类的唯一性

“全盘负责”是指当一个ClassLoder装载一个类时，除非显式的 去指定使用另外一个ClassLoder，不然该类所依赖及引用的类也由这个ClassLoder载入。

双亲委派机制在loadClass方法中实现，如果要打破双亲委派，我们只要重写loadClass方法即可，直接调用自己的findClass方法即可（ps：在父类的findClass方法中会去类加载器的资源目录查找）

使用打破双亲委派机制的自定义类加载器加载我们自己写的java.lang.Long测试

• 具体可以查看笔记，挺有意思的

为何tomcat需要打破双亲委派

tomcat的几个主要类加载器

tomcat 这种类加载机制违背了java 推荐的双亲委派模型了吗？

tomcat的JasperLoader热加载大概原理

程序计数器（Program Counter Register）是一块较小的内存空间，它可以看作是当前线程所执行的字节码的行号指示器。

每条线程都需要有一个独立的程序计数器，各条线程之间计数器互不影响，独立存储，我们称这类内存区域为“线程私有”的内存

如果线程正在执行的是一个Java方法，这个计数器记录的是正在执行的虚拟机字节码指令的地址；如果正在执行的是本地（Native）方法，这个计数器值则应为空（Undefined）。此内存区域是唯一一个在《Java虚拟机规范》中没有规定任何OutOfMemoryError情况的区域。

Java虚拟机栈（Java Virtual Machine Stack）也是线程私有的，它的生命周期与线程相同。虚拟机栈描述的是Java方法执行的线程内存模型：每个方法被执行的时候，Java虚拟机都会同步创建一个栈帧[1]（Stack Frame）用于存储局部变量表、操作数栈、动态连接、方法出口等信息。每一个方法被调用直至执行完毕的过程，就对应着一个栈帧在虚拟机栈中从入栈到出栈的过程

局部变量表存放了编译期可知的各种Java虚拟机基本数据类型（boolean、byte、char、short、int、float、long、double）、对象引用（reference类型，它并不等同于对象本身，可能是一个指向对象起始地址的引用指针，也可能是指向一个代表对象的句柄或者其他与此对象相关的位置）和returnAddress类型（指向了一条字节码指令的地址）

本地方法栈（Native Method Stacks）与虚拟机栈所发挥的作用是非常相似的，其区别只是虚拟机栈为虚拟机执行Java方法（也就是字节码）服务，而本地方法栈则是为虚拟机使用到的本地（Native）方法服务。

Java堆（Java Heap）是虚拟机所管理的内存中最大的一块。Java堆是被所有线程共享的一块内存区域，在虚拟机启动时创建。此内存区域的唯一目的就是存放对象实例，Java世界里“几乎”所有的对象实例都在这里分配内存。在《Java虚拟机规范》中对Java堆的描述是：“所有的对象实例以及数组都应当在堆上分配 [1] ”，而这里笔者写的“几乎”是指从实现角度来看，随着Java语言的发展，现在已经能看到些许迹象表明日后可能出现值类型的支持，即使只考虑现在，由于即时编译技术的进步，尤其是逃逸分析技术的日渐强大，栈上分配、标量替换 [2] 优化手段已经导致一些微妙的变化悄然发生，所以说Java对象实例都分配在堆上也渐渐变得不是那么绝对了

堆是GC的主要发生区域，由于现代垃圾收集器大部分都是基于分代收集理论设计的，所以Java堆分为新生代、老年代、永久代、Eden、Survivor，但是这些区域划分仅仅是一部分垃圾收集器的共同特性或者说设计风格而已，而非某个Java虚拟机具体实现的固有内存布局，更不是《Java虚拟机规范》里对Java堆的进一步细致划分。在十年之前（以G1收集器的出现为分界），作为业界绝对主流的HotSpot虚拟机，它内部的垃圾收集器全部都基于“经典分代” [3] 来设计，需要新生代、老年代收集器搭配才能工作，在这种背景下，上述说法还算是不会产生太大歧义。但是到了今天，垃圾收集器技术与十年前已不可同日而语，HotSpot里面也出现了不采用分代设计的新垃圾收集器，再按照上面的提法就有很多需要商榷的地方了

如果从分配内存的角度看，所有线程共享的Java堆中可以划分出多个线程私有的分配缓冲区（Thread Local Allocation Buffer，TLAB）

方法区（元空间）

运行时常量池

Jdk1.6及之前： 有永久代, 运行时常量池在永久代，运行时常量池包含字符串常量池
Jdk1.7：有永久代，但已经逐步“去永久代”，字符串常量池、静态变量从永久代里的运行时常量池分离到堆里
Jdk1.8及之后： 无永久代，运行时常量池在元空间，字符串常量池里依然在堆里

直接内存（Direct Memory）并不是虚拟机运行时数据区的一部分，也不是《Java虚拟机规范》中定义的内存区域。但是这部分内存也被频繁地使用，而且也可能导致OutOfMemoryError异常出现

在JDK 1.4中新加入了NIO（New Input/Output）类，引入了一种基于通道（Channel）与缓冲区（Buffer）的I/O方式，它可以使用Native函数库直接分配堆外内存，然后通过一个存储在Java堆里面的DirectByteBuffer对象作为这块内存的引用进行操作。这样能在一些场景中显著提高性能，因为避免了在Java堆和Native堆中来回复制数据。（零拷贝），一般服务器管理员配置虚拟机参数时，会根据实际内存去设置-Xmx等参数信息，但经常忽略掉直接内存，使得各个内存区域总和大于物理内存限制（包括物理的和操作系统级的限制），从而导致动态扩展时出现OutOfMemoryError异常

什么时候回收？

-Xmx：堆的最大值，超出会报OutOfMemoryError

-Xms：堆的最小值（初始化大小），将堆的最小值-Xms参数与最大值-Xmx参数设置为一样即可避免堆自动扩展

-Xmn：指年轻代大小，不设置默认为堆的1/3大小

-Xss：是指设定每个线程的堆栈大小，默认1M，如果超出了会报栈溢出（StackOverFlowError），-Xss设置越小，一个线程栈里能分配的栈帧就越少，但是对JVM整体来说能开启的线程数会更多

-XX：MaxMetaspaceSize： 设置元空间最大值， 默认是-1， 即不限制， 或者说只受限于本地内存大小。

-XX：MetaspaceSize： 指定元空间触发Fullgc的初始阈值(元空间无固定初始大小)， 以字节为单位，默认是21M，达到该值就会触发full gc进行类型卸载， 同时收集器会对该值进行调整： 如果释放了大量的空间， 就适当降低该值； 如果释放了很少的空间， 那么在不超过-XX：MaxMetaspaceSize（如果设置了的话） 的情况下， 适当提高该值。这个跟早期jdk版本的-XX:PermSize参数意思不一样，-XX:PermSize代表永久代的初始容量。
【建议在JVM参数中将MetaspaceSize和MaxMetaspaceSize设置成一样的值】

虚拟机遇到一条new指令时，首先将去检查这个指令的参数（无参构造的话只有一个new指令，参数为自己类，有参的话有多少个就有多少个new、dup、invokespecial指令）是否能在常量池中定位到一个类的符号引用，并且检查这个符号引用代表的类是否已被加载、解析和初始化过。如果没有，那必须先执行相应的类加载过程。

在类加载检查通过后，接下来虚拟机将为新生对象分配内存。对象所需内存的大小在类加载完成后便可完全确定，为对象分配空间的任务等同于把 一块确定大小的内存从Java堆中划分出来。

划分内存的方法

内存分配并发问题

内存分配完成后，虚拟机需要将分配到的内存空间都初始化为零值（不包括对象头）， 如果使用TLAB，这一工作过程也可以提前至TLAB分配时进行。这一步操作保证了对象的实例字段在Java代码中可以不赋初始值就直接使用，使程序能访问到这些字段的数据类型所对应的零值

初始化零值之后，虚拟机要对对象进行必要的设置，例如这个对象是哪个类的实例、如何才能找到类的元数据信息、对象的哈希码、对象的GC分代年龄等信息。这些信息存放在对象的对象头Object Header之中。jvm通过对象头中的klass指针去找到放在方法区中的类元信息

对象存储布局

执行<init>方法，即对象按照程序员的意愿进行初始化。对应到语言层面上讲，就是为属性赋值（注意，这与上面的赋零值不同，这是由程序员赋的值），和执行构造方法。这个init方法不要想着就是构造方法，要是构造方法为空构造呢？所以不要这么想

1.jdk1.6 update14开始，在64bit操作系统中，JVM支持指针压缩

2.jvm配置参数:UseCompressedOops，compressed--压缩、oop(ordinary object pointer)--对象指针

3.启用指针压缩:-XX:+UseCompressedOops(默认开启)，禁止指针压缩:-XX:-UseCompressedOops

在 Java 中，“指针压缩”（Compressed Oops，其中Oops代表Ordinary Object Pointers）是 HotSpot JVM 的一个功能，它允许64位JVM在不牺牲太多性能的情况下利用更小的内存空间存储对象引用。

在 64 位架构上，原生的指针（地址）大小为 64 位（8 字节），使得可以访问非常大的内存空间（理论上高达 16 Exabytes，1 EB = 1,000,000 TB）。然而，对于大多数应用程序而言，它们实际上并不需要如此巨大的地址空间。默认情况下，即使是一个中等规模的应用程序，每个对象引用都使用 8 字节存储也显得极为浪费。这会导致以下问题：

1. 内存使用增加：每个指针占用的空间加倍将导致每个对象以及类的元空间占用的总内存显著增加。
2. 缓存效率降低：更大的指针意味着更少的指针能够放进 CPU 缓存中，从而降低缓存的效率，因为缓存行能够存储的对象指针数量减少了。
3. 带宽消耗增加：传输大小增加的指针需要数据总线和内存总线更多的带宽，这在内存密集型应用程序中可能成为性能瓶颈。

指针压缩通过将 64 位的指针存储为 32 位的偏移量来节省内存空间。由于对象在 Java 中通常是 8 字节对齐的，因此这 32 位的偏移量可以乘以 8（或左移 3 位），转换成真实的 64 位内存地址，这允许最多访问 32 GB（2^32 * 8 字节）的内存地址空间。这对于大多数 Java 应用来

简单理解：对象头使用的8byte的整数倍对齐，然后在堆中表示的是压缩的编码，java堆内存进行8byte划分，对象指针就不用存对象真实的64bit地址了，而是存一个堆中的映射地址编号，这样就使用1byte表示64bit地址，也就是可以表示32G的内存空间，这也是为什么jvm内存为什么不建议超过32G的原因

我们通过JVM内存分配可以知道JAVA中的对象都是在堆上进行分配，当对象没有被引用的时候，需要依靠GC进行回收内存，如果对象数量较多的时候，会给GC带来较大压力，也间接影响了应用的性能。为了减少临时对象在堆内分配的数量，JVM通过逃逸分析确定该对象不会被外部访问。如果不会可以将该对象在栈上分配内存，这样该对象所占用的内存空间就可以随栈帧出栈而销毁，就减轻了垃圾回收的压力。

对象逃逸分析：就是分析对象动态作用域，当一个对象在方法中被定义后，它可能被外部方法所引用，例如作为调用参数传递到其他地方中

JVM对于这种情况可以通过开启逃逸分析参数(-XX:+DoEscapeAnalysis)来优化对象内存分配位置，使其通过标量替换优先分配在栈上(栈上分配)，JDK7之后默认开启逃逸分析，如果要关闭使用参数(-XX:-DoEscapeAnalysis)

标量替换

标量与聚合量

总结：栈上分配是通过标量替换进行的，而能否在栈上分配则依赖于逃逸分析，能逃逸才在栈上分配

大多数情况下，对象在新生代中 Eden 区分配。当 Eden 区没有足够空间进行分配时，虚拟机将发起一次Minor GC

Minor GC和Full GC 有什么不同呢？

Eden与Survivor区默认8:1:1

大对象就是需要大量连续内存空间的对象（比如：字符串、数组）。JVM参数 -XX:PretenureSizeThreshold 可以设置大对象的大小，如果对象超过设置大小会直接进入老年代，不会进入年轻代，这个参数只在 Serial 和ParNew两个收集器下有效。

为什么要这样呢？

既然虚拟机采用了分代收集的思想来管理内存，那么内存回收时就必须能识别哪些对象应放在新生代，哪些对象应放在老年代中。为了做到这一点，虚拟机给每个对象一个对象年龄（Age）计数器。

如果对象在 Eden 出生并经过第一次 Minor GC 后仍然能够存活，并且能被 Survivor 容纳的话，将被移动到 Survivor 空间中，并将对象年龄设为1。对象在 Survivor 中每熬过一次 MinorGC，年龄就增加1岁，当它的年龄增加到一定程度（默认为15岁，CMS收集器默认6岁，不同的垃圾收集器会略微有点不同）（最大为15岁，因为Mark word中分代年龄为4bit），就会被晋升到老年代中。对象晋升到老年代的年龄阈值，可以通过参数 -XX:MaxTenuringThreshold 来设置。

当前放对象的Survivor区域里(放对象的那块s区)，一批对象的总大小大于这块Survivor区域内存大小的50%(-XX:TargetSurvivorRatio可以指定)，那么此时大于等于这批对象年龄最大值的对象，就可以直接进入老年代了，例如Survivor区域里现在有一批对象，年龄1+年龄2+年龄n的多个年龄对象总和超过了Survivor区域的50%，此时就会把年龄n(含)以上的对象都放入老年代。这个规则其实是希望那些可能是长期存活的对象，尽早进入老年代。对象动态年龄判断机制一般是在minor gc之后触发的

总体表征就是，年龄从小到大进行累加，当加入某个年龄段后，累加和超过survivor区域*TargetSurvivorRatio的时候，就从这个年龄段网上的年龄的对象进行晋升。并不是相同年龄的对象和来判断

字面上就能理解，就是老年代为了能有足够的内存迎接下一次进入老年代的对象而设计的机制

年轻代每次minor gc之前JVM都会计算下老年代剩余可用空间，如果这个可用空间小于年轻代里现有的所有对象大小之和(包括垃圾对象)，就会看一个“-XX:-HandlePromotionFailure”(jdk1.8默认就设置了)的参数是否设置了，如果有这个参数，就会看看老年代的可用内存大小，是否大于之前每一次minor gc后进入老年代的对象的平均大小。如果上一步结果是小于或者之前说的参数没有设置，那么就会触发一次Full gc，对老年代和年轻代一起回收一次垃圾，如果回收完还是没有足够空间存放新的对象就会发生"OOM"。当然，如果minor gc之后剩余存活的需要挪动到老年代的对象大小还是大于老年代可用空间，那么也会触发full gc，full gc完之后如果还是没有空间放minor gc之后的存活对象，则也会发生“OOM”

这样给老年代的担保机制，避免了minor gc后剩余的空间还是无法放入老年代，减少了一次minor gc，而且既然都小于了那后面很容易占满了

引用计数法

可达性分析算法

即使在可达性分析算法中不可达的对象，也并非是“非死不可”的，这时候它们暂时处于“缓刑”阶段，要真正宣告一个对象死亡，至少要经历再次标记过程

• 标记的前提是对象在进行可达性分析后发现没有与GC Roots相连接的引用链

两次标记过程

注意：一个对象的finalize()方法只会被执行一次，也就是说通过调用finalize方法自我救命的机会就一次

• finalize()方法的运行代价高昂， 不确定性大， 无法保证各个对象的调用顺序， 如今已被官方明确声明为不推荐使用的语法。 有些资料描述它适合做“关闭外部资源”之类的清理性工作， 这完全是对finalize()方法用途的一种自我安慰。 finalize()能做的所有工作， 使用try-finally或者其他方式都可以做得更好、更及时， 所以建议大家完全可以忘掉Java语言里面的这个方法

类需要同时满足下面3个条件才能算是 “无用的类” ：

• 该类所有的对象实例都已经被回收，也就是 Java 堆中不存在该类的任何实例。
• 加载该类的 ClassLoader 已经被回收。
• 该类对应的 java.lang.Class 对象没有在任何地方被引用，无法在任何地方通过反射访问该类的方法。

将Eden区跟survivor尽量的分大些避免对象因为内存不足放到full gc中去，只有真正不会被回收的才去到老年代

为了解决效率问题，“复制”收集算法出现了。它可以将内存分为大小相同的两块，每次使用其中的一块。当这一块的内存使用完后，就将还存活的对象复制到另一块去，然后再把使用的空间一次清理掉。这样就使每次的内存回收都是对内存区间的一半进行回收

因为是直接复制到另外一块内存，所以会顺序写入，收集之后也是没有内存碎片的

算法分为“标记”和“清除”阶段：标记存活的对象， 统一回收所有未被标记的对象(一般选择这种)；也可以反过来，标记出所有需要回收的对象，在标记完成后统一回收所有被标记的对象 。它是最基础的收集算法，比较简单，但是会带来两个明显的问题：

1. 效率问题 (如果需要标记的对象太多，效率不高)
2. 空间问题（标记清除后会产生大量不连续的碎片）

根据老年代的特点特出的一种标记算法，标记过程仍然与“标记-清除”算法一样，但后续步骤不是直接对可回收对象回收，而是让所有存活的对象向一端移动，然后直接清理掉边界端以外的内存。

就回收效率而言，标记清除/整理比标记复制是要快的，复制多了一个复制的过程
标记清除：标记存活对象，清理未标记对象
标记整理：标记存活对象，移动标记对象
标记复制：标记存活对象，复制对象到s区，清理原空间

我们常说的复制比清理/整理快是因为它并不会产生内存碎片，对后续的内存分配友好，而且其内存都是连续的，内存有局部性原则（高速缓存）所以会更快，在回收的时候因为没有碎片扫描也快些，以及年轻代比老年代空间小，小就说明快

看名字就知道这个收集器是一个单线程收集器了。它的 “单线程” 的意义不仅仅意味着它只会使用一条垃圾收集线程去完成垃圾收集工作，更重要的是它在进行垃圾收集工作的时候必须暂停其他所有的工作线程（ "Stop The World" ），直到它收集结束

新生代采用复制算法，老年代采用标记-整理算法

Serial收集器有没有优于其他垃圾收集器的地方呢？

Serial Old收集器是Serial收集器的老年代版本，它同样是一个单线程收集器。它主要有两大用途：

• 一种用途是在JDK1.5以及以前的版本中与Parallel Scavenge收集器搭配使用，
• 另一种用途是作为CMS收集器的后备方案

Parallel收集器其实就是Serial收集器的多线程版本，除了使用多线程进行垃圾收集外，其余行为（控制参数、收集算法、回收策略等等）和Serial收集器类似。默认的收集线程数跟cpu核数相同，当然也可以用参数(-XX:ParallelGCThreads)指定收集线程数，但是一般不推荐修改

Parallel Scavenge收集器关注点是吞吐量（高效率的利用CPU）。CMS等垃圾收集器的关注点更多的是用户线程的停顿时间（提高用户体验）。所谓吞吐量就是CPU中用于运行用户代码的时间与CPU总消耗时间的比值

新生代采用复制算法，老年代采用标记-整理算法

Parallel Old收集器是Parallel Scavenge收集器的老年代版本。使用多线程和“标记-整理”算法。在注重吞吐量以及CPU资源的场合，都可以优先考虑 Parallel Scavenge收集器和Parallel Old收集器(JDK8默认的新生代和老年代收集器)

ParNew收集器其实跟Parallel收集器很类似，区别主要在于它可以和CMS收集器配合使用

新生代采用复制算法，老年代采用标记-整理算法

它是许多运行在Server模式下的虚拟机的首要选择，除了Serial收集器外，只有它能与CMS收集器配合工作

CMS（Concurrent Mark Sweep）收集器是一种以获取最短回收停顿时间为目标的收集器。它非常符合在注重用户体验的应用上使用，它是HotSpot虚拟机第一款真正意义上的并发收集器，它第一次实现了让垃圾收集线程与用户线程（基本上）同时工作

从名字中的Mark Sweep这两个词可以看出，CMS收集器是一种 “标记-清除”算法实现的，整个过程分为五个步骤：

主要优点：并发收集、低停顿

几个明显的缺点：

• 对CPU资源敏感（会和服务抢资源）；
• 无法处理浮动垃圾(在并发标记和并发清理阶段又产生垃圾，这种浮动垃圾只能等到下一次gc再清理了)；
• 它使用的回收算法-“标记-清除”算法会导致收集结束时会有大量空间碎片产生，当然通过参数-XX:+UseCMSCompactAtFullCollection可以让jvm在执行完标记清除后再做整理
• 执行过程中的不确定性，会存在上一次垃圾回收还没执行完，然后垃圾回收又被触发的情况，特别是在并发标记和并发清理阶段会出现，一边回收，系统一边运行，也许没回收完就再次触发full gc，也就是"concurrent mode failure"，此时会进入stop the world，用serial old垃圾收集器来回收

CMS的相关核心参数

G1收集器

大对象处理方式

GC的运作过程

优先列表回收

G1具备的特点

G1垃圾收集分类

G1垃圾收集器优化建议

什么场景适合使用G1

每秒几十万并发的系统如何优化JVM

ZGC是一款JDK 11中新加入的具有实验性质的低延迟垃圾收集器，ZGC可以说源自于是Azul System公司开发的C4（Concurrent Continuously Compacting Collector） 收集器

ZGC目标

不分代(暂时)

ZGC内存布局

ZGC是能自动感知NUMA架构

ZGC运作过程

颜色指针

ZGC中的读屏障

ZGC存在的问题

ZGC触发GC时机

白色： 表示对象尚未被垃圾收集器访问过。 显然在可达性分析刚刚开始的阶段， 所有的对象都是白色的， 若在分析结束的阶段， 仍然是白色的对象， 即代表不可达。白色表示没扫描到的，但不代表不会扫描到。只有说结束后还是白色才为是垃圾对象

灰色： 表示对象已经被垃圾收集器访问过， 但这个对象上至少存在一个引用还没有被扫描过。

黑色： 表示对象已经被垃圾收集器访问过， 且这个对象的所有引用都已经扫描过。 黑色的对象代表已经扫描过， 它是安全存活的， 如果有其他对象引用指向了黑色对象， 无须重新扫描一遍。 黑色对象不可能直接（不经过灰色对象） 指向某个白色对象

在并发标记过程中，如果由于方法运行结束导致部分局部变量(gcroot)被销毁，这个gcroot引用的对象之前又被扫描过(被标记为非垃圾对象)，那么本轮GC不会回收这部分内存。这部分本应该回收但是没有回收到的内存，被称之为“浮动垃圾”。浮动垃圾并不会影响垃圾回收的正确性，只是需要等到下一轮垃圾回收中才被清除

另外，针对并发标记(还有并发清理)开始后产生的新对象，通常的做法是直接全部当成黑色，本轮不会进行清除。这部分对象期间可能也会变为垃圾，这也算是浮动垃圾的一部分

增量更新（Incremental Update）

原始快照（Snapshot At The Beginning，SATB）

各垃圾收集器解决方案

写屏障：其实就是指在赋值操作前后，加入一些处理（可以参考AOP的概念）

读屏障：其实就是在读取操作前将数据保存起来

我的理解：SATB相对增量更新效率会高(当然SATB可能造成更多的浮动垃圾)，因为不需要在重新标记阶段再次深度扫描被删除引用对象，而CMS对增量引用的根对象会做深度扫描，G1因为很多对象都位于不同的region，CMS就一块老年代区域，重新深度扫描对象的话G1的代价会比CMS高，所以G1选择SATB不深度扫描对象，只是简单标记，等到下一轮GC再深度扫描

在minor gc的时候，可能存在一些对象是被老年代的对象的变量引用着，如果说在gcroot可达性分析的时候不去扫描老年代中的对象，可能新生代中会存在一些非垃圾对象无法被标记到，这就存在问题，但是如果直接去扫描全部的老年代对象代价太高了。所以虚拟机就使用记忆集卡表来维护：只要老年代中对象的变量引用了新生代的对象（写屏障实现），就将这个老年代对象中的卡页标记成1，代表元素脏，在minor gc的时候会扫描所有变脏的卡页，而不用把全部的老年代对象全部扫描一遍，也就能解决上面的效率问题了。在实际中，其实跨代引用的对象极少的

卡表是使用一个字节数组实现：CARD_TABLE[ ]，每个元素对应着其标识的内存区域一块特定大小的内存块，称为“卡页”

一个卡页中可包含多个对象，只要有一个对象的字段存在跨代指针，其对应的卡表的元素标识就变成1，表示该元素变脏，否则为0.
卡表为一个位数组，0101这种，初始全是0,，变脏设置1，每一个0或者1对应一块卡页，卡表存在新生代，卡页存在老年代

安全点的理解：在GC要开始的时候，会设置一个GC的开始标记，用户线程中在到达一个安全点的时候都会去断言检查这个标记，如果是GC开始的标记就停止自己线程，当所有用户线程都到达安全点并停止后，GC才能开始。如果没有这个机制，那么就会造成我们代码的一些执行不对，比如我们一行代码可能对应多个jvm指令，那总得等到这些指令都执行完才能GC吧，不然会打乱代码的原子性，又比如我们多行代码有牵扯原子性不能暂停后再继续运行，这也是一样的道理。这些点就是安全点
所以GC不是想什么时候做就立即触发的，是需要等待所有线程运行到安全点后才能触发

安全区域的理解：比如一个线程执行到了sleep操作了，并且sleep很久，难道我们GC就要等到这个sleep结束才开始GC吗。也就是说在这一行或者这一段代码的运行时不会改变我们GC所关心的对象引用的变化时，它是一直安全的，可以随时暂停该用户线程去开始GC，这些区域就叫做安全区域

可以列出正在运行的虚拟机进程，并显示虚拟机执行主类（Main Class，main()函数所在的类）名称以及这些进程的本地虚拟机唯一ID（LVMID，Local Virtual Machine Identifier）

jps命令格式：jps [ options ] [ hostid ]

• -q: 只输出 LVMID，省略主类的名称
• -m: 输出虚拟机进行启动时传递给主类 main() 函数的参数
• -l: 输出主类的全名，如果进程执行的是 JAR 包，则输出 JAR 路径
• -v: 输出虚拟机进程启动时的 JVM 参数

jinfo（Configuration Info for Java）的作用是实时查看和调整虚拟机各项参数。使用jps命令的-v参数可以查看虚拟机启动时显式指定的参数列表，但如果想知道未被显式指定的参数的系统默认值，除了去找资料外，就只能使用jinfo的-flag选项进行查询了

jinfo命令格式：jinfo [ option ] pid

• -flags 查看jvm的参数
• -sysprops 查看java系统参数
• -flag [+|-] 修改正在运行的Java应用程序JVM参数，其中+是开启对应参数，-是关闭对应参数

jmap（Memory Map for Java）命令用于生成堆转储快照（一般称为heapdump或dump文件）。

jmap命令格式：jmap [ option ] vmid

• -dump: 使用hprof二进制形式输出jvm的heap内容到文件，生成 Java 堆转储快照。格式为 -dum:[live,]format=b,file=filename, 其中 live 子参数说明是否只 dump 存活的对象。
• -finalizeinfo: 显示在F-Queue 中等待Finalizer 线程执行 finalize 方法的对象。只在 Linux/Solaris 平台有效。
• -heap: 显示 Java 堆详细信息，如使用哪种回收器、参数配置、分代状况等。只在 Linux/Solaris 平台有效。
• -histo: 显示堆中对象统计信息，包括类、实例数量、合计容量。
• -permstat: 以 ClassLoader 为统计口径显示永久代内存状态。只在 Linux/Solaris 平台有效。
• -F: 当虚拟机进程对 -dump 选项没有响应时，可使用这个选项强制生成 dump 快照。只在 Linux/Solaris 平台有效。

jmap执行期间会对进程产生很大影响，甚至卡顿，线上慎用

其它方式获得堆转储快照文件

jstat（JVM Statistics Monitoring Tool）是用于监视虚拟机各种运行状态信息的命令行工具。它可以显示本地或者远程 [1] 虚拟机进程中的类加载、内存、垃圾收集、即时编译等运行时数据，在没有GUI图形界面、只提供了纯文本控制台环境的服务器上，它将是运行期定位虚拟机性能问题的常用工具

jstat命令格式：jstat [ option vmid [interval[s|ms] [count]] ]

• -class: 监视类加载，卸载数量、总空间以及类装载所耗费的时间
• -gc: 监视 Java 堆状况，包括 Eden 区、2个 Survivor 区、老年区、永久代等的容量，已用空间，垃圾收集时间合计等信息
• -gccapacity: 监视内容与 -gc 基本相同，但输出主要关注 Java 堆各个区域使用到的最大、最小空间
• -gcutil: 监视内容与 -gc 基本相同，但输出主要关注已使用空间占总空间的百分比
• -gccause: 与 -gcutil功能一样，但是会额外输出导致上一次垃圾收集产生的原因
• -gcnew: 监视新生代垃圾收集状况
• -gcnewcapacity: 监视内容与 -gcnew 基本相同，输出主要关注使用到的最大、最小空间
• -gcold: 监视老年代垃圾收集状况
• -gcoldcapacity: 监视内容与 -gcold 基本相同，输出主要关注使用到的最大、最小空间
• -gcpermcapacity: 输出永久代使用的最大、最小空间
• -compiler: 输出即时编译器编译过的方法、耗时等信息
• -printcompilation: 输出已经被即时编译的方法

假设需要每250毫秒查询一次进程2764垃圾收集状况，一共查询20次，那命令应当是：jstat -gc 2764 250 20

jstack（Stack Trace for Java）命令用于生成虚拟机当前时刻的线程快照。线程快照就是当前虚拟机内每一条线程正在执行的方法堆栈的集合，生成线程快照的目的通常是定位线程出现长时间停顿的原因，如线程间死锁、死循环、请求外部资源导致的长时间挂起等，都是导致线程长时间停顿的常见原因。线程出现停顿时通过jstack来查看各个线程的调用堆栈，就可以获知没有响应的线程到底在后台做些什么事情，或者等待着什么资源

jstack命令格式：jstack [ option ] vmid

• -F: 当正常输出的请求不被响应时，强制输出线程堆栈。
• -l: 除堆栈外，显示关于锁的附加信息
• -m: 如果遇到本地方法的话，可以显示 C/C++ 的堆栈

可以执行命令 jstat -gc pid 1000 10 (每隔1秒执行1次命令，共执行10次)，通过观察EU(eden区的使用)来估算每秒eden大概新增多少对象，如果系统负载不高，可以把频率1秒换成1分钟，甚至10分钟来观察整体情况。注意，一般系统可能有高峰期和日常期，所以需要在不同的时间分别估算不同情况下对象增长速率

知道年轻代对象增长速率我们就能推根据eden区的大小推算出Young GC大概多久触发一次，Young GC的平均耗时可以通过 YGCT/YGC 公式算出，根据结果我们大概就能知道系统大概多久会因为Young GC的执行而卡顿多久

这个因为之前已经大概知道Young GC的频率，假设是每5分钟一次，那么可以执行命令 jstat -gc pid 300000 10 ，观察每次结果eden，survivor和老年代使用的变化情况，在每次gc后eden区使用一般会大幅减少，survivor和老年代都有可能增长，这些增长的对象就是每次Young GC后存活的对象，同时还可以看出每次Young GC后进去老年代大概多少对象，从而可以推算出老年代对象增长速率

知道了老年代对象的增长速率就可以推算出Full GC的触发频率了，Full GC的每次耗时可以用公式 FGCT/FGC 计算得出

1. 字符串的分配，和其他的对象分配一样，耗费高昂的时间与空间代价，作为最基础的数据类型，大量频繁的创建字符串，极大程度地影响程序的性能
2. JVM为了提高性能和减少内存开销，在实例化字符串常量的时候进行了一些优化：

• 为字符串开辟一个字符串常量池，类似于缓存区

• 创建字符串常量时，首先查询字符串常量池是否存在该字符串
• 存在该字符串，返回引用实例，不存在，实例化该字符串并放入池中

直接赋值字符串：String s = "libo"; // s指向常量池中的引用

new String()：String s1 = new String("libo"); // s1指向内存中的对象引用（堆中的地址）

• 这种方式会保证字符串常量池和堆中都有这个对象，没有就创建，最后返回堆内存中的对象引用
  

intern方法：String s2 = s1.intern();如果说常量池中存在则指向常量池地址，如果不存在，则指向s1对象堆中的地址

• 在1.6的时候还会将字符串复制到常量池中去，并指向的是常量池中的地址

• Jdk1.6及之前： 有永久代, 运行时常量池在永久代，运行时常量池包含字符串常量池
• Jdk1.7：有永久代，但已经逐步“去永久代”，字符串常量池从永久代里的运行时常量池分离到堆里
• Jdk1.8及之后： 无永久代，运行时常量池在元空间，字符串常量池里依然在堆里

String s1 = new String("he") + new String("llo");
相当于new StringBuilder("he").append("llo").toString();而toString里面为new String(value, 0, count)所以s1>>堆
String s2 = s1.intern();
System.out.println(s1 == s2);
// 在 JDK 1.6 下输出是 false，创建了 6 个对象
// 在 JDK 1.7 及以上的版本输出是 true，创建了 5 个对象
// 当然我们这里没有考虑GC，但这些对象确实存在或存在过

String s2="li" + "bo";//编译器直接优化成“libo”

String s2="li" + new String("bo");
用new String() 创建的字符串不是常量，不能在编译期就确定，所以编译器不能直接优化

虚拟机遇到一条new指令时，首先将去检查这个指令的参数（无参构造的话只有一个new指令，参数为自己类，有参的话有多少个就有多少个new、dup、invokespecial指令）是否能在常量池中定位到一个类的符号引用，并且检查这个符号引用代表的类是否已被加载、解析和初始化过。如果没有，那必须先执行相应的类加载过程

在类加载检查通过后，接下来虚拟机将为新生对象分配内存。对象所需内存的大小在类加载完成后便可完全确定，为对象分配空间的任务等同于把一块确定大小的内存从Java堆中划分出来

内存分配完成后，虚拟机需要将分配到的内存空间都初始化为零值（不包括对象头）， 如果使用TLAB，这一工作过程也可以提前至TLAB分配时进行。这一步操作保证了对象的实例字段在Java代码中可以不赋初始值就直接使用，使程序能访问到这些字段的数据类型所对应的零值

初始化零值之后，虚拟机要对对象进行必要的设置，例如这个对象是哪个类的实例、如何才能找到类的元数据信息、对象的哈希码、对象的GC分代年龄等信息。这些信息存放在对象的对象头Object Header之中。

执行<init>方法，即对象按照程序员的意愿进行初始化。对应到语言层面上讲，就是为属性赋值（注意，这与上面的赋零值不同，这是由程序员赋的值），和执行构造方法。这个init方法不要想着就是构造方法，要是构造方法为空构造呢？所以不要这么想

如果Java堆中内存是绝对规整的，所有用过的内存都放在一边，空闲的内存放在另一边，中间放着一个指针作为分界点的指示器，那所分配内存就仅仅是把那个指针向空闲空间那边挪动一段与对象大小相等的距离

如果Java堆中的内存并不是规整的，已使用的内存和空 闲的内存相互交错，那就没有办法简单地进行指针碰撞了，虚拟机就必须维护一个列表，记 录上哪些内存块是可用的，在分配的时候从列表中找到一块足够大的空间划分给对象实例， 并更新列表上的记录

• 第一部分用于存储对象自身的运行时数据， 如哈希码（HashCode）、GC分代年龄、锁状态标志、线程持有的锁、偏向线程ID、偏向时间戳等。
• 另外一部分是类型指针，即对象指向它的类元数据的指针，虚拟机通过这个指针来确定这个对象是哪个类的实例
• 如果是数组，还有一部分为数组长度

对象真正存储的有效信息。无论是从父类继承下来的，还是在子类中定义的字段都必须记录起来

并不是必然存在的，也没有特别的含义，它仅仅起着占位符的作用。由于HotSpot虚拟机的自动内存管理系统要求对象起始地址必须是8字节的整数倍（站在计算机组成原理的角度上讲，64位操作系统采用8字节的寻址是最快的，所以在不满足的时候就对齐8的整数倍去填充）。换句话说就是任何对象的大小都必须是8字节的整数倍。对象头部分已经被精心设计成正好是8字节的倍数（1倍或者2倍），因此，如果对象实例数据部分没有对齐的话，就需要通过对齐填充来补全

• 堆内存设置过小，由于请求突然增加，那么我们可以根据我们的场景适量增加堆内存限制；
• 内存泄漏导致，一般只存在业务上的泄漏（长生命周期对象持有短生命周期的引用），理论上jvm不会出现泄漏，这种的话一般是代码bug，定位到具体代码即可

生成dump几种方式

dump文件分析工具

free-m查看虚拟机内存使用情况，当然有时候设置了初始=最大，看不出来

oom造成服务挂了

一直在gc导致服务响应不了

cup占用过高，没cpu资源来响应服务

频繁创建对象，一般为bug，需要优化或更改

内存溢出过多导致oom

堆外内存溢出

通过加大内存，优化各区的比例、更换垃圾收集器等方式

查看jvm各个区域的内存大小合理进行优化

计算机在运行时，先从内存中取出第一条指令，通过控制器的译码，按指令的要求，从存储器中取出数据进行指定的运算和逻辑操作等加工，然后再按地址把结果送到内存中去。接下来，再取出第二条指令，在控制器的指挥下完成规定操作。依此进行下去。直至遇到停止指令。 程序与数据一样存贮，按程序编排的顺序，一步一步地取出指令，自动地完成指令规定的操作是计算机最基本的工作模型。这一原理最初是由美籍匈牙利数学家冯.诺依曼于1945年提出来的，故称为冯.诺依曼计算机模型

控制器(Control)：是整个计算机的中枢神经，其功能是对程序规定的控制信息进行解释（比如将程序的指令解释成计算机的设备能识别的信息），根据其要求进行控制，调度程序、数据、地址，协调计算机各部分工作及内存与外设的访问等

运算器(Datapath)：运算器的功能是对数据进行各种算术运算和逻辑运算，即对数据进行加工处理

存储器(Memory)：存储器的功能是存储程序、数据和各种信号、命令等信息，并在需要时提供这些信息

输入(Input system)：输入设备是计算机的重要组成部分，输入设备与输出设备合称为外部设备，简称外设，输入设备的作用是将程序、原始数据、文字、字符、控制命令或现场采集的数据等信息输入到计算机。常见的输入设备有键盘、鼠标器、光电输入机、磁带机、磁盘机、光盘机等

输出(Output system)：输出设备与输入设备同样是计算机的重要组成部分，它把外算机的中间结果或最后结果、机内的各种数据符号及文字或各种控制信号等信息输出出来。微机常用的输出设备有显示终端CRT、打印机、激光印字机、绘图仪及磁带、光盘机等

控制单元

运算单元

存储单元

cpu三级缓存

• 存储器存储空间大小：内存>L3>L2>L1>寄存器；
• 存储器速度快慢排序：寄存器>L1>L2>L3>内存；

还有一点值得注意的是：缓存是由最小的存储区块-缓存行(cacheline)组成，缓存行大小通常为64byte

• 比如你的L1缓存大小是512kb,而cacheline = 64byte,那么就是L1里有512 * 1024/64个cacheline】

CPU读取存储器数据过程

CPU为何要有高速缓存

CPU运行安全等级

Linux为内核代码和数据结构预留了几个页框，这些页永远不会被转出到磁盘上。用户程序运行在用户方式下，而系统调用运行在内核方式下。在这两种方式下所用的堆栈不一样：用户方式下用的是一般的堆栈(用户空间的堆栈)，而内核方式下用的是固定大小的堆栈（内核空间的堆栈，一般为一个内存页的大小），即每个进程与线程其实有两个堆栈，分别运行与用户态与内核态

内核线程(KLT)：系统内核管理线程(KLT)，内核保存线程的状态和上下文信息，线程阻塞不会引起进程阻塞。在多处理器系统上，多线程在多处理器上并行运行。线程的创建、调度和管理由内核完成，效率比ULT要慢，比进程操作快

用户线程(ULT)：用户程序实现,不依赖操作系统核心,应用提供创建、同步、调度和管理线程的函数来控制用户线程。不需要用户态/内核态切换，速度快。内核对ULT无感知，线程阻塞则进程（包括它的所有线程）阻塞。

jvm是采用的内核线程模型

进程：现代操作系统在运行一个程序时，会为其创建一个进程；例如，启动一个Java程序，操作系统就会创建一个Java进程。进程是OS(操作系统)资源分配的最小单位

线程：是OS(操作系统)调度CPU的最小单元，也叫轻量级进程（Light Weight Process），在一个进程里可以创建多个线程，这些线程都拥有各自的计数器、堆栈和局部变量等属性，并且能够访问共享的内存变量。CPU在这些线程上高速切换，让使用者感觉到这些线程在同时执行，即并发的概念，相似的概念还有并行

线程上下文切换过程：每个线程分配到cpu时间片的时候，就真正执行，当这个时间片走完了就停止（可以理解为执行完时间片的时间），等着下次分配时间片（如果线程还未结束）

并发跟并行：

• 并发是指一个处理器同时处理多个任务。
• 并行是指多个处理器或者是多核的处理器同时处理多个不同的任务。

并发是逻辑上的同时发生(simultaneous)，而并行是物理上的同时发生

栈指令集架构

寄存器指令集架构

Java符合典型的栈指令集架构特征

简单理解，比如：a=1;b=2;要计算a+b=？，在寄存器指令中，直接把a跟b拿到cpu中，计算出结果，再返回。但是在栈指令集架构的话，需要先将a压入线程栈中，然后再出栈放到局部变量表中，b也是这样，最后再拉到cpu中计算，每次入栈跟出栈都是需要cpu去做（就是前面说的在局部变量表跟操作数栈中）

Java内存模型(Java Memory Model简称JMM)是一种抽象的概念，并不真实存在，它描述的是一组规则或规范，通过这组规范定义了程序中各个变量（包括实例字段，静态字段和构成数组对象的元素）的访问方式。JVM运行程序的实体是线程，而每个线程创建时JVM都会为其创建一个工作内存(有些地方称为栈空间，就是虚拟机栈)，用于存储线程私有的数据，而Java内存模型中规定所有变量都存储在主内存，主内存是共享内存区域，所有线程都可以访问，但线程对变量的操作(读取赋值等)必须在工作内存中进行，首先要将变量从主内存拷贝的自己的工作内存空间，然后对变量进行操作，操作完成后再将变量写回主内存，不能直接操作主内存中的变量，工作内存中存储着主内存中的变量副本拷贝，前面说过，工作内存是每个线程的私有数据区域，因此不同的线程间无法访问对方的工作内存，线程间的通信(传值)必须通过主内存来完成。

java内存模型为一个抽象的概念，它描述着工作内存跟主内存之间的交互方式：线程对变量的操作(读取赋值等)必须在工作内存中进行，首先要将变量从主内存拷贝的自己的工作内存空间，然后对变量进行操作，操作完成后再将变量写回主内存，不能直接操作主内存中的变量

主内存

工作内存

工作内存跟主内存可能存在cpu寄存器、CPU缓存区、主内存中任何一个地方，只是jvm逻辑划分成了不同的区域，并不是真正对应着硬件的内存

在早期的c、c++语言中是没有定义内存模型的，其行为依赖于处理器本身的内存一致性模型，但不同的处理器处理结果可能会不一样，Java设计之初就引入了线程的概念，以充分利用现代处理器的计算能力，这既带来了强大、灵活的多线程机制，也带来了线程安全等令人混淆的问题，为了解决这个问题，Java内存模型（Java Memory Model，JMM）为我们提供了一个在纷乱之中达成一致的指导准则。规定了什么样的执行是符合规范的
java内存模型围绕着在并发过程中如何处理可见性、原子性、有序性这三个特性而建立的模型。

八大原子操作

同步规则分析

原子性

可见性

有序性

原子性问题

可见性问题

有序性问题

保证被volatile修饰的共享变量对所有线程总是可见的，也就是当一个线程修改了一个被volatile修饰共享变量的值，新值总是可以被其他线程立即得知。原理是通过MESI协议实现可见性

只能通过锁来串行化解决

volatile关键字另一个作用就是禁止指令重排优化，从而避免多线程环境下程序出现乱序执行的现象，关于指令重排优化前面已详细分析过，这里主要简单说明一下volatile是如何实现禁止指令重排优化的。先了解一个概念，内存屏障(Memory Barrier）

volatile是怎么实现禁止指令重排的

描述：该Cache line有效，数据已被修改了，和内存中的数据不一致，数据只存在于本Cache中。

监听任务：缓存行必须时刻监听所有试图读该缓存行相对在主内存的操作，这种操作必须在缓存将该缓存行写回主内存并将状态变成S（共享）状态之前被延迟执行。

描述：该Cache line有效，数据和内存中的数据一致，数据只存在于本Cache中。

监听任务：缓存行也必须监听其它缓存读主存中该缓存行的操作，一旦有这种操作，该缓存行需要变成S（共享）状态。

描述：该Cache line有效，数据和内存中的数据一致，数据存在于很多Cache中。

监听任务：缓存行也必须监听其它缓存使该缓存行无效或者独享该缓存行的请求，并将该缓存行变成无效（Invalid）。

描述：该Cache line无效。

监听任务：无

1：线程A读取到主内存的数据a=0；此时a变量在该cpu核上为E（独享）状态。 2：线程B读取到主内存的数据a=0；此时因为a已经在线程A上，所以他们的状态都是S（共享）状态。 3：线程A跟线程B同时去修改变量a；他们一开始都会写进自己的缓存中并且成功，接着都写回主内存，然后再总线那里就会通过总线裁决的方式选举哪个去写到主内存中去，比如这里A写成功，然后B的数据就会被失效并丢弃。 4：如果保证了可见性的情况下，那么B线程会感知到此时a的数据为a=1了，所以就会重新load到cpu缓存中去，也就变成了S（共享）状态了

CPU缓存系统中是以缓存行（cache line）为单位存储的。目前主流的CPU Cache 的 Cache Line 大小都是64Bytes。在多线程情况下，如果需要修改“共享同一个缓存行的变量”，就会无意中影响彼此的性能，这就是伪共享（False Sharing）

• 举个例子: 现在有2个int型变量 a 、b，如果有t1在访问a，t2在访问b，而a与b刚好在同一个cache line中，此时t1先修改a，将导致b被刷新

Java8中新增了一个注解：@sun.misc.Contended。加上这个注解的类会自动补齐缓存行（也就不会存在多个变量共享一个CacheLine），需要注意的是此注解默认是无效的，需要在jvm启动时设置 -XX:-RestrictContended 才会生效。

问题引发：比如你需要修改本地缓存中的一条信息，那么你必须将I（无效）状态通知到其他拥有该缓存数据的CPU缓存中，并且等待确认。等待确认的过程会阻塞处理器，这会降低处理器的性能。因为这个等待远远比一个指令的执行时间长的多

解决方案：存储缓存（Store/stɔːr/ Bufferes）

同步实例方法，锁是当前实例对象

• public synchronized void method()

同步类方法，锁是当前类对象

• public static synchronized void method()

同步代码块，锁是括号里面的对象

• synchronized (obj)

任何一个对象都有一个Monitor与之关联，当且一个Monitor被持有后，它将处于锁定状态。Synchronized在JVM里的实现都是 基于进入和退出Monitor对象来实现方法同步和代码块同步，虽然具体实现细节不一样，但是都可以通过成对的MonitorEnter和MonitorExit指令来实现

monitorenter：每个对象都是一个监视器锁（monitor）。当monitor被占用时就处于锁定状态，线程执行monitorenter指令时尝试获取monitor的所有权，过程如下：

1. 如果monitor的进入数为0，则该线程进入monitor，然后将进入数设置为1，该线程即为monitor的所有者；
2. 如果线程已经占有该monitor，只是重新进入，则进入monitor的进入数加1；所以说重量级锁其实也是支持重入的
3. 如果其他线程已经占用了monitor，则该线程进入阻塞状态，直到monitor的进入数为0，再重新尝试获取monitor的所有权

monitorexit：执行monitorexit的线程必须是objectref所对应的monitor的所有者。指令执行时，monitor的进入数减1，如果减1后进入数为0，那线程退出monitor，不再是这个monitor的所有者。其他被这个monitor阻塞的线程可以尝试去获取这个 monitor 的所有权

在Java的设计中 ，每一个Java对象自打娘胎里出来就带了一把看不见的锁，它叫做内部锁或者Monitor锁。也就是通常说Synchronized的对象锁，MarkWord锁标识位为10，其中指针指向的是Monitor对象的起始地址

锁的状态总共有四种，无锁状态、偏向锁、轻量级锁和重量级锁。随着锁的竞争，锁可以从偏向锁升级到轻量级锁，再升级的重量级锁，但是锁的升级是单向的，也就是说只能从低到高升级，不会出现锁的降级。从JDK 1.6 中默认是开启偏向锁和轻量级锁的，可以通过-XX:-UseBiasedLocking来禁用偏向锁

图大概理解：当线程访问同步代码块的时候，会去检查mark work的锁状态，

偏向锁：如果是偏向锁，那就比较下mark word中记录的是否为当前线程id，是的话就执行，不是的话就尝试通过CAS操作去获取偏向锁，如果获取偏向锁失败说明需要升级为轻量级锁了，等待原持有锁的线程到达安全点后，如果原持有锁的线程已经退出同步代码块或未活动状态（如等待），则并不会升级锁而是重新尝试获取偏向锁，如果原持有锁的线程未退出同步块，则升级为轻量级锁，并且会让原持有锁的线程拿到轻量级锁，唤醒后继续执行；

轻量级锁：分配锁记录对象并将mark word拷贝到锁记录对象中去（栈上分配），尝试把对象头的mark word指向该锁记录对象（当前线程的锁记录对象），指向失败的话就开始自旋。如果自旋失败一定次数后还没分配到锁就需要升级为重量级锁了。

重量级锁：mark word中的monitor指针指向ObjectMonitor对象，通过操作系统的Mutex lock（互斥锁）实现锁机制，它是一个重量级锁，性能较低，被阻塞的线程会被挂起、等待重新调度，会导致“用户态和内核态”两个态之间来回切换，对性能有较大影响。

• 不管什么锁都是串行化线程，重量级锁之所以慢是因为需要调用操作系统级别（内核态）的指令，而且会挂起阻塞的线程，来回切换。偏向锁、轻量锁并不会，大部分场景都不会升级重量锁，在偏向锁跟轻量锁基本都能满足了

偏向锁

轻量级锁

自旋锁

消除锁

锁粗化

进程与线程

协程

现代操作系统基本采用时分的形式调度运行的线程，操作系统会分出一个个时间片，线程会分配到若干时间片，当线程的时间片用完了就会发生线程调度，并等待着下次分配。线程分配到的时间片多少也就决定了线程使用处理器资源的多少，而线程优先级就是决定线程需要多或者少分配一些处理器资源的线程属性

• 注意：线程优先级不能作为程序正确性的依赖，因为操作系统可以完全不用理会Java线程对于优先级的设定

初始(NEW)：新创建了一个线程对象，但还没有调用start()方法

运行(RUNNABLE)：Java线程将操作系统中的就绪（ready）和运行中（running）两种状态笼统的称为“运行”。

• 线程对象创建后，其他线程(比如main线程）调用了该对象的start()方法。该状态的线程位于可运行线程池中，等待被线程调度选中，获取CPU的使用权，此时处于就绪状态（ready）。就绪状态的线程在获得CPU时间片后变为运行中状态（running）

阻塞(BLOCKED)：表示线程阻塞于锁。

等待(WAITING)：进入该状态的线程需要等待其他线程做出一些特定动作（通知或中断）。

超时等待(TIMED_WAITING)：该状态不同于WAITING，它可以在指定的时间后自行返回

终止(TERMINATED)：表示该线程已经执行完毕

注意：Java将操作系统中的运行和就绪两个状态合并称为运行状态。阻塞状态是线程阻塞在进入synchronized关键字修饰的方法或代码块时的状态，但是阻塞在java.concurrent包中Lock接口的线程状态却是等待状态，因为java.concurrent包中Lock接口对于阻塞的实现均使用了LockSupport类中的相关方法

守护线程（Daemon线程）

非守护线程

中断可以理解为线程的一个标识位属性，它表示一个运行中的线程是否被其他线程进行了中断操作。中断好比其他线程对该线程打了个招呼，其他线程通过调用该线程的interrupt() /ˌɪntəˈrʌpt/  方法对其进行中断操作

线程通过检查自身是否被中断来进行响应，线程通过方法isInterrupted()【是否中断过，false表示未中断】来进行判断是否被中断，也可以调用静态方法Thread.interrupted()对当前线程的中断标识位进行复位。如果该线程已经处于终结状态，即使该线程被中断过，在调用该线程对象的isInterrupted()时依旧会返回false

从Java的API中可以看到，许多声明抛出InterruptedException的方法（例如Thread.sleep(longmillis)方法）这些方法在抛出InterruptedException之前，Java虚拟机会先将该线程的中断标识位清除，然后抛出InterruptedException，此时调用isInterrupted()方法将会返回false

暂停、恢复和停止操作对应在线程Thread的API就是suspend()（暂停）、resume()（恢复）和stop()（停止），这些API是过期的，也就是不建议使用的
不建议使用的原因主要有：以suspend()方法为例，在调用后，线程不会释放已经占有的资源（比如锁），而是占有着资源进入睡眠状态，这样容易引发死锁问题。同样，stop()方法在终结一个线程时不会保证线程的资源正常释放，通常是没有给予线程完成资源释放工作的机会，因此会导致程序可能工作在不确定状态下

前面提到的中断状态是线程的一个标识位，而中断操作是一种简便的线程间交互方式，而这种交互方式最适合用来取消或停止任务。除了中断以外，还可以利用一个boolean变量来控制是否需要停止任务并终止该线程。

wait()方法

wait(long)

wait(long,int)

notify()方法

notifyAll()

如果一个线程A执行了B.join()语句，其含义是：当前线程A等待B线程终止之后才从B.join()返回。线程Thread除了提供join()方法之外，还提供了join(long millis)和join(longmillis,int nanos)两个具备超时特性的方法。这两个超时方法表示，如果线程B在给定的超时时间里没有终止，那么将会从该超时方法中返回

• join方法也是使用的wait跟notifyAll实现

ThreadLocal提供了线程内存储变量的能力，这些变量不同之处在于每一个线程读取的变量是对应的互相独立的。通过get和set方法就可以得到当前线程对应的值

让出cpu的使用权，使线程处于可运行状态，但是，实际中无法保证yield()达到让步目的，因为让步的线程还有可能被线程调度程序再次选中

在ReentrantLock内部定义了一个Sync/sɪŋk/ 的内部类，该类继承AbstractQueuedSynchronized，对该抽象类的部分方法做了实现；并且还定义了两个子类：
1、FairSync /fer/公平锁的实现
2、NonfairSync 非公平锁的实现
这两个类都继承自Sync，也就是间接继承了AbstractQueuedSynchronized，所以这一个ReentrantLock同时具备公平与非公平特性。
上面主要涉及的设计模式：模板模式-子类根据需要做具体业务实现

State三种访问方式： getState()、setState()、compareAndSetState() /kəmˈper/

Exclusive-独占，只有一个线程能执行，如ReentrantLock

Share-共享，多个线程可以同时执行，如Semaphore/CountDownLatch

同步等待队列

条件等待队列

不同的自定义同步器争用共享资源的方式也不同。自定义同步器在实现时只需要实现共享资源state的获取与释放方式即可，至于具体线程等待队列的维护（如获取资源失败入队/唤醒出队等），AQS已经在顶层实现好了，自定义同步器实现时主要实现以下几种方法：

• isHeldExclusively()：该线程是否正在独占资源。只有用到condition才需要去实现它。
• tryAcquire(int)：独占方式。尝试获取资源，成功则返回true，失败则返回false。
• tryRelease(int)：独占方式。尝试释放资源，成功则返回true，失败则返回false。
• tryAcquireShared(int)：共享方式。尝试获取资源。负数表示失败；0表示成功，但没有剩余可用资源；正数表示成功，且有剩余资源。
• tryReleaseShared(int)：共享方式。尝试释放资源，如果释放后允许唤醒后续等待结点返回true，否则返回false。

1）线程再次获取锁。锁需要去识别获取锁的线程是否为当前占据锁的线程，如果是，则再次成功获取。
2）锁的最终释放。线程重复n次获取了锁，随后在第n次释放该锁后，其他线程能够获取到该锁。锁的最终释放要求锁对于获取进行计数自增，计数表示当前锁被重复获取的次数，而锁被释放时，计数自减，当计数等于0时表示锁已经成功释放（次数基于state）

Semaphore 字面意思是信号量的意思，它的作用是控制访问特定资源的线程数目，底层依赖AQS的状态State，是在生产当中比较常用的一个工具类。比如限流

CountDownLatch这个类能够使一个线程等待其他线程完成各自的工作后再执行。例如，应用程序的主线程希望在负责启动框架服务的线程已经启动所有的框架服务之后再执行。简单说就是一个线程需要等待其他线程全部执行完才执行，不然一直阻塞不往下面执行

• Zookeeper分布式锁,Jmeter模拟高并发等

CountDownLatch是通过一个计数器来实现的，计数器的初始值为线程的数量。每当一个线程完成了自己的任务后，计数器的值就会减1。当计数器值到达0时，它表示所有的线程已经完成了任务，然后在闭锁上等待的线程就可以恢复执行任务

栅栏屏障，让一组线程到达一个屏障（也可以叫同步点）时被阻塞，直到最后一个线程到达屏障时，屏障才会开门，所有被屏障拦截的线程才会继续运行。
CyclicBarrier默认的构造方法是CyclicBarrier（int parties），其参数表示屏障拦截的线程数量，每个线程调用await方法告CyclicBarrier我已经到达了屏障，然后当前线程被阻塞。当所有线程到达屏障时，被await()阻塞的线程继续执行
有点像我们前面CountDownLatch的一种写法

CountDownLatch的计数器只能使用一次，而CyclicBarrier的计数器可以使用reset()方法重置。所以CyclicBarrier能处理更为复杂的业务场景。例如，如果计算发生错误，可以重置计数器，并让线程重新执行一次。 CyclicBarrier还提供其他有用的方法，比如getNumberWaiting方法可以获得Cyclic-Barrier阻塞的线程数量。isBroken()方法用来了解阻塞的线程是否被中断

BlockingQueue，是java.util.concurrent 包提供的用于解决并发生产者 - 消费者问题的最有用的类，它的特性是在任意时刻只有一个线程可以进行take/teɪk/（拿）或者put操作，并且BlockingQueue提供了超时return null的机制，在许多生产场景里都可以看到这个工具的身影

• 1）支持阻塞的插入方法：意思是当队列满时，队列会阻塞插入元素的线程，直到队列不满。
• 2）支持阻塞的移除方法：意思是在队列为空时，获取元素的线程会等待队列变为非空。

插入方法

移除方法

检查方法

注意：如果是无界阻塞队列，队列不可能会出现满的情况，所以使用put或offer方法永远不会被阻塞，而且使用offer方法时，该方法永远返回true

记忆方法：put和take分别尾首含有字母t（停）一直阻塞，offer和poll都含有字母o并且支持超时设置有返回值无异常

无限队列 （unbounded queue ） - 几乎可以无限增长

有限队列 （ bounded queue ） - 定义了最大容量

队列实质就是一种存储数据的结构

• 通常用链表或者数组实现
• 一般而言队列具备FIFO先进先出的特性，当然也有双端队列（Deque）优先级队列
• 主要操作：入队（EnQueue）与出队（Dequeue）

1. ArrayBlockingQueue：一个由数组结构组成的有界阻塞队列。
2. LinkedBlockingQueue：一个由链表结构组成的有界阻塞队列。
3. PriorityBlockingQueue：一个支持优先级排序的无界阻塞队列。
4. DelayQueue：一个使用优先级队列实现的无界阻塞队列。
5. SynchronousQueue：一个不存储元素的阻塞队列。
6. LinkedTransferQueue：一个由链表结构组成的无界阻塞队列。
7. LinkedBlockingDeque：一个由链表结构组成的双向阻塞队列。

ArrayBlockingQueue是一个用数组实现的有界阻塞队列。容量大小在创建ArrayBlockingQueue对象时已定义好。此队列按照先进先出（FIFO）的原则对元素进行排序。

队列创建

工作原理

LinkedBlockingQueue是一个用链表实现的有界阻塞队列。此队列的默认和最大长度为Integer.MAX_VALUE。此队列按照先进先出的原则对元素进行排序。

//blockingQueue 的容量将设置为 Integer.MAX_VALUE 。
BlockingQueue<String> blockingQueue = new LinkedBlockingQueue<>();

PriorityBlockingQueue是一个支持优先级的无界阻塞队列。默认情况下元素采取自然顺序升序排列。也可以自定义类实现compareTo()方法来指定元素排序规则，或者初始化PriorityBlockingQueue时，指定构造参数Comparator来对元素进行排序。需要注意的是不能保证同优先级元素的顺序

DelayQueue是一个支持延时获取元素的无界阻塞队列。队列使用PriorityQueue来实现(基于数组的扩容实现)。队列中的元素必须实现Delayed接口，在创建元素时可以指定多久才能从队列中获取该元素。只有在延迟期满时才能从队列中提取元素

队列创建

应用场景

工作原理

基于链表形式的队列，通过compare and swap(简称CAS)协议的方式，来保证多线程情况下数据的安全，不加锁，主要使用了Java中的sun.misc.Unsafe类来实现；

缓存行：缓存的最小操作单位

比较并交换：CAS操作需要输入两个数值，一个旧值（期望操作前的值）和一个新值，在操作期间先比较下在旧值有没有发生变化，如果没有发生变化，才交换成新值，发生了变化则不交换。

CPU流水线：CPU流水线的工作方式就象工业生产上的装配流水线，在CPU中由5~6个不同功能的电路单元组成一条指令处理流水线，然后将一条X86指令分成5~6步后再由这些电路单元分别执行，这样就能实现在一个CPU时钟周期完成一条指令，因此提高CPU的运算速度。

内存顺序冲突：内存顺序冲突一般是由假共享引起，假共享是指多个CPU同时修改同一个缓存行的不同部分而引起其中一个CPU的操作无效，当出现这个内存顺序冲突时，CPU必须清空流水线。

处理器自动保证基本内存操作的原子性

使用总线锁保证原子性

使用缓存锁保证原子性

使用循环CAS实现原子操作

使用锁机制实现原子操作

ABA问题

循环时间长开销大

只能保证一个共享变量的原子操作

基本数据类型：AtomicInteger、AtomicLong、AtomicBoolean

引用类型：AtomicReference、AtomicReference的ABA实例：AtomicStampedRerence、AtomicMarkableReference

数组类型：AtomicIntegerArray、AtomicLongArray、AtomicReferenceArray

属性原子修改器（Updater）：AtomicIntegerFieldUpdater、AtomicLongFieldUpdater、AtomicReferenceFieldUpdater

• int addAndGet(int delta) ：以原子方式将输入的数值与实例中的值（AtomicInteger里的value）相加，并返回结果
• boolean compareAndSet(int expect, int update) ：如果输入的数值等于预期值，则以原子方式将该值设置为输入的值。
• int getAndIncrement()：以原子方式将当前值加1，注意：这里返回的是自增前的值。
• void lazySet(int newValue)：最终会设置成newValue，使用lazySet设置值后，可能导致其他线程在之后的一小段时间内还是可以读到旧的值。
• int getAndSet(int newValue)：以原子方式设置为newValue的值，并返回旧值

Atomic包提供了三种基本类型的原子更新，但是Java的基本类型里还有char，float和double等。那么问题来了，如何原子的更新其他的基本类型呢？Atomic包里的类基本都是使用Unsafe实现的，Unsafe只提供了三种CAS方法，compareAndSwapObject，compareAndSwapInt和compareAndSwapLong，再看AtomicBoolean源码，发现其是先把Boolean转换成整型，再使用compareAndSwapInt进行CAS，所以原子更新double也可以用类似的思路来实现（拆分开，操作完再合并）

• int addAndGet(int i, int delta)：以原子方式将输入值与数组中索引i的元素相加。
• boolean compareAndSet(int i, int expect, int update)：如果当前值等于预期值，则以原子方式将数组位置i的元素设置成update值

需要注意的是，数组value通过构造方法传递进去，然后AtomicIntegerArray会将当前数组复制一份，所以当AtomicIntegerArray对内部的数组元素进行修改时，不会影响传入的数组。

• AtomicReference：原子更新引用类型。
• AtomicReferenceFieldUpdater：原子更新引用类型里的字段。
• AtomicMarkableReference：原子更新带有标记位的引用类型（解决ABA问题）。可以原子的更新一个布尔类型的标记位和引用类型。构造方法是AtomicMarkableReference(V initialRef, boolean initialMark)

如果我们只需要某个类里的某个字段，那么就需要使用原子更新字段类，Atomic包提供了以下三个类：

• AtomicIntegerFieldUpdater：原子更新整型的字段的更新器。
• AtomicLongFieldUpdater：原子更新长整型字段的更新器。
• AtomicStampedReference：原子更新带有版本号的引用类型。该类将整数值与引用关联起来，可用于原子的更新数据和数据的版本号，可以解决使用CAS进行原子更新时可能出现的ABA问题

要想原子地更新字段类需要两步。第一步，因为原子更新字段类都是抽象类，每次使用的时候必须使用静态方法newUpdater()创建一个更新器，并且需要设置想要更新的类和属性。第二步，更新类的字段（属性）必须使用public volatile修饰符

Unsafe是位于sun.misc包下的一个类，主要提供一些用于执行低级别、不安全操作的方法，如直接访问系统内存资源、自主管理内存资源等，这些方法在提升Java运行效率、增强Java语言底层资源操作能力方面起到了很大的作用。但由于Unsafe类使Java语言拥有了类似C语言指针一样操作内存空间的能力，这无疑也增加了程序发生相关指针问题的风险。在程序中过度、不正确使用Unsafe类会使得程序出错的概率变大，使得Java这种安全的语言变得不再“安全”，因此对Unsafe的使用一定要慎重。需要向C++一样自己释放资源，因为这样申请的资源并不会由JVM管理

Unsafe提供的API大致可分为内存操作、CAS、Class相关、对象操作、线程调度、系统信息获取、内存屏障、数组操作等几类

线程是调度CPU资源的最小单位，线程模型分为KLT模型与ULT模型，JVM使用的KLT模型，Java线程与OS线程保持1:1的映射关系，也就是说有一个java线程也会在操作系统里有一个对应的线程。Java线程有多种生命状态

协程 (纤程，用户级线程)，目的是为了追求最大力度的发挥硬件性能和提升软件的速度，协程基本原理是:在某个点挂起当前的任务，并且保存栈信息，去执行另一个任务；等完成或达到某个条件时，再还原原来的栈信息并继续执行(整个过程线程不需要上下文切换)

线程的实现方式

“线程池”，顾名思义就是一个线程缓存，线程是稀缺资源，如果被无限制的创建，不仅会消耗系统资源，还会降低系统的稳定性，因此Java中提供线程池对线程进行统一分配、调优和监控

线程池的好处：

• 降低资源消耗。通过重复利用已创建的线程降低线程创建和销毁造成的消耗。
• 提高响应速度。当任务到达时，任务可以不需要的等到线程创建就能立即执行。
• 提高线程的可管理性。线程是稀缺资源，如果无限制的创建，不仅会消耗系统资源，还会降低系统的稳定性，使用线程池可以进行统一的分配，调优和监控。

CPU密集型（CPU-bound）

IO密集型（I/O bound）

CPU密集型 vs IO密集型

Executor是一个接口，它是Executor框架的基础，它将任务的提交与任务的执行分离开来。 ThreadPoolExecutor是线程池的核心实现类，用来执行被提交的任务。 ScheduledThreadPoolExecutor是一个实现类，可以在给定的延迟后运行命令，或者定期执行命令。ScheduledThreadPoolExecutor比Timer更灵活，功能更强大。 Future接口和实现Future接口的FutureTask类，代表异步计算的结果。 Runnable接口和Callable接口的实现类，都可以被ThreadPoolExecutor或Scheduled-ThreadPoolExecutor执行

结构

• execute（Runnable command）：履行Ruannable类型的任务,
• submit（task）：可用来提交Callable或Runnable任务，并返回代表此任务的Future对象
• shutdown（）：在完成已提交的任务后封闭办事，不再接管新任务,
• shutdownNow（）：停止所有正在履行的任务并封闭办事。
• isTerminated（）：测试是否所有任务都履行完毕了。
• isShutdown（）：测试是否该ExecutorService已被关闭。

corePoolSize：线程池中的核心线程数，当提交一个任务时，线程池创建一个新线程执行任务，直到当前线程数等于corePoolSize；如果当前线程数为corePoolSize，继续提交的任务被保存到阻塞队列中，等待被执行；如果执行了线程池的prestartAllCoreThreads()方法，线程池会提前创建并启动所有核心线程

maximumPoolSize：线程池中允许的最大线程数。如果当前阻塞队列满了，且继续提交任务，则创建新的线程执行任务，前提是当前线程数小于maximumPoolSize

keepAliveTime：线程池维护线程所允许的空闲时间。当线程池中的线程数量大于corePoolSize的时候，如果这时没有新的任务提交，核心线程外的线程不会立即销毁，而是会等待，直到等待的时间超过了keepAliveTime

unit：keepAliveTime的单位；可选的单位有天（DAYS）、小时（HOURS）、分钟（MINUTES）、毫秒（MILLISECONDS）、微秒（MICROSECONDS，千分之一毫秒）和纳秒（NANOSECONDS）

workQueue：用来保存等待被执行的任务的阻塞队列，且任务必须实现Runable接口，在JDK中提供了如下阻塞队列：

• ArrayBlockingQueue：基于数组结构的有界阻塞队列，按FIFO排序任务；
• LinkedBlockingQuene：基于链表结构的阻塞队列，按FIFO排序任务，吞吐量通常要高于ArrayBlockingQuene；
• SynchronousQuene：一个不存储元素的阻塞队列，每个插入操作必须等到另一个线程调用移除操作，否则插入操作一直处于阻塞状态，吞吐量通常要高于LinkedBlockingQuene；
• priorityBlockingQuene：具有优先级的无界阻塞队列；

threadFactory：它是ThreadFactory类型的变量，用来创建新线程。默认使用Executors.defaultThreadFactory() 来创建线程。使用默认的ThreadFactory来创建线程时，会使新创建的线程具有相同的NORM_PRIORITY优先级并且是非守护线程，同时也设置了线程的名称

handler：线程池的饱和策略，当阻塞队列满了，且没有空闲的工作线程，如果继续提交任务，必须采取一种策略处理该任务，线程池提供了4种策略：

• AbortPolicy：直接抛出异常，默认策略；
• CallerRunsPolicy：用调用者所在的线程来执行任务；
• DiscardOldestPolicy：丢弃阻塞队列中靠最前的任务，并执行当前任务；
• DiscardPolicy：直接丢弃任务；

上面的4种策略都是ThreadPoolExecutor的内部类。当然也可以根据应用场景实现RejectedExecutionHandler接口，自定义饱和策略，如记录日志或持久化存储不能处理的任务

public void execute() //提交任务无返回值，所以无法判断任务是否被线程池执行成功。

public Future<?> submit() //任务执行完成后有返回值，线程池会返回一个future类型的对象，通过这个future对象可以判断任务是否执行成功，并且可以通过future的get()方法来获取返回值，get()方法会阻塞当前线程直到任务完成，而使用get（long timeout，TimeUnit unit）方法则会阻塞当前线程一段时间后立即返回，这时候有可能任务没有执行完

//在完成已提交的任务后封闭办事，不再接管新任务
public void shutdown()

//停止所有正在履行的任务并封闭办事。
public List<Runnable> shutdownNow()

可以通过调用线程池的shutdown或shutdownNow方法来关闭线程池。它们的原理是遍历线程池中的工作线程，然后逐个调用线程的interrupt方法来中断线程，所以无法响应中断的任务可能永远无法终止。但是它们存在一定的区别，shutdownNow首先将线程池的状态设置成STOP，然后尝试停止所有的正在执行或暂停任务的线程，并返回等待执行任务的列表，而shutdown只是将线程池的状态设置成SHUTDOWN状态，然后中断所有没有正在执行任务的线程

只要调用了这两个关闭方法中的任意一个，isShutdown方法就会返回true。当所有的任务都已关闭后，才表示线程池关闭成功，这时调用isTerminaed方法会返回true。至于应该调用哪一种方法来关闭线程池，应该由提交到线程池的任务特性决定，通常调用shutdown方法来关闭线程池，如果任务不一定要执行完，则可以调用shutdownNow方法

• public long getTaskCount() //线程池已执行与未执行的任务总数
• public long getCompletedTaskCount() //已完成的任务数
• public int getPoolSize() //线程池当前的线程数
• public int getActiveCount() //线程池中正在执行任务的线程数量
• public int getLargestPoolSize() //线程池里曾经创建过的最大线程数量。通过这个数据可以知道线程池是否曾经满过。该数值等于线程池的最大大小，则线程池曾经满过

protected void beforeExecute(Thread t, Runnable r) { }
protected void afterExecute(Runnable r, Throwable t) { }
protected void terminated() { }

通过扩展线程池进行监控。可以通过继承线程池来自定义线程池，重写线程池的beforeExecute、afterExecute和terminated方法，也可以在任务执行前、执行后和线程池关闭前执行一些代码来进行监控。例如，监控任务的平均执行时间、最大执行时间和最小执行时间等。

要想合理地配置线程池，就必须首先分析任务特性，可以从以下几个角度来分析。

• 任务的性质：CPU密集型任务、IO密集型任务和混合型任务。
• 任务的优先级：高、中和低。
• 任务的执行时间：长、中和短。
• 任务的依赖性：是否依赖其他系统资源，如数据库连接

性质不同的任务可以用不同规模的线程池分开处理。

• CPU密集型任务应配置尽可能小的线程，如配置N cpu +1个线程的线程池。
• 由于IO密集型任务线程并不是一直在执行任务，则应配置尽可能多的线程，如2*N cpu 。
• 混合型的任务，如果可以拆分，将其拆分成一个CPU密集型任务和一个IO密集型任务
• 优先级不同的任务可以使用优先级队列PriorityBlockingQueue来处理。它可以让优先级高的任务先执行。（注意：如果一直有优先级高的任务提交到队列里，那么优先级低的任务可能永远不能执行。）
• 执行时间不同的任务可以交给不同规模的线程池来处理，或者可以使用优先级队列，让执行时间短的任务先执行
• 依赖数据库连接池的任务，因为线程提交SQL后需要等待数据库返回结果，等待的时间越长，则CPU空闲时间就越长，那么线程数应该设置得越大，这样才能更好地利用CPU

建议使用有界队列。有界队列能增加系统的稳定性和预警能力，可以根据需要设大一点儿，比如几千。有一次，我们系统里后台任务线程池的队列和线程池全满了，不断抛出抛弃任务的异常，通过排查发现是数据库出现了问题，导致执行SQL变得非常缓慢，因为后台任务线程池里的任务全是需要向数据库查询和插入数据的，所以导致线程池里的工作线程全部阻塞，任务积压在线程池里。如果当时我们设置成无界队列，那么线程池的队列就会越来越多，有可能会撑满内存，导致整个系统不可用，而不只是后台任务出现问题。当然，我们的系统所有的任务是用单独的服务器部署的，我们使用不同规模的线程池完成不同类型的任务，但是出现这样问题时也会影响到其他任务

ctl饰演者什么角色

ctl相关方法

ctl表示runState-线程池存在5种状态

ThreadPoolExecutor采取上述步骤的总体设计思路，是为了在执行execute()方法时，尽可能地避免获取全局锁（那将会是一个严重的可伸缩瓶颈，在队列排队而不需要一起强锁）。在ThreadPoolExecutor完成预热之后（当前运行的线程数大于等于corePoolSize），几乎所有的execute()方法调用都是执行步骤2，而步骤2不需要获取全局锁。

线程池中的线程执行任务分两种情况，如下：
1）在execute()方法中创建一个线程时，会让这个线程执行当前任务。
2）这个线程执行完上图中1的任务后，会反复从BlockingQueue获取任务来执行

execute方法提交任务的时候，会根据线程池数量是否创建worker，线程池中的每一个线程被封装成一个Worker对象，ThreadPool维护的其实就是一组Worker对象，Worker类继承了AQS，并实现了Runnable接口，注意其中的firstTask和thread属性：firstTask用它来保存传入的任务，thread是在调用构造方法时通过ThreadFactory来创建的线程（创建的时候其实就是new Thread并且设置Thread中的target为worker自己【Runnable不就是这么用的】），是用来处理任务的线程。在Worker的run方法中去执行了我们提交线程的run方法(注意这里并不会启动线程start)

Fork/Join 框架是 Java7 提供了的一个用于并行执行任务的框架， 是一个把大任务分割成若干个小任务，最终汇总每个小任务结果后得到大任务结果的框架

Fork 就是把一个大任务切分为若干子任务并行的执行，Join 就是合并这些子任务的执行结果，最后得到这个大任务的结果

工作窃取（work-stealing）算法是指某个线程从其他队列里窃取任务来执行。

把这个任务分割为若干互不依赖的子任务，为了减少线程间的竞争，于是把这些子任务分别放到不同的队列里，并为每个队列创建一个单独的线程来执行队列里的任务，线程和队列一一对应。若某个线程执行完自己的队列了，会帮助别的线程执行：被窃取任务线程永远从双端队列的尾部拿任务执行，而窃取任务的线程永远从双端队列的头部拿任务执行

Disruptor【美 /dɪsˈrʌptər/ 】是一个开源框架，研发的初衷是为了解决高并发下列队锁的问题，最早由LMAX（一种新型零售金融交易平台）提出并使用，能够在无锁的情况下实现队列的并发操作，并号称能够在一个线程里每秒处理6百万笔订单(这个真假就不清楚了！牛皮谁都会吹)

Disruptor通过以下设计来解决队列速度慢的问题：

• 环形数组结构：为了避免垃圾回收，采用数组而非链表。同时，数组对处理器的缓存机制更加友好（回顾一下：CPU加载空间局部性原则）。
• 元素位置定位：数组长度2^n，通过位运算，加快定位的速度。下标采取递增的形式。不用担心index溢出的问题。index是long类型，即使100万QPS的处理速度，也需要30万年才能用完。
• 无锁设计：每个生产者或者消费者线程，会先申请可以操作的元素在数组中的位置，申请到之后，直接在该位置写入或者读取数据。

每次存一个数据Sequence/ˈsiːkwəns/加一，然后取数据的时候在根据这个Sequence用位运算取模数组长度定位到元素真正索引。数组构建成了一个逻辑环，当元素中已经存在数据的时候，生产者会阻塞，会等到消费者消费后再生产

Disruptor大部分的并发代码都是通过对Sequence的值同步修改实现的，而非锁，同步修改到后就不占用资源了，这段Sequence就是该线程独占的，这是disruptor高性能的一个主要原因。
而BlockingQueue在消息入队的时候需要一直占用资源，只有入队结束后才会释放，其他线程才可以操作队列，还有它还是入队一次占用一次ReentrantLock锁，而Disruptor则是每个线程一次一个一个入队多个消息

进程是程序的一次执行过程，是系统运行程序的基本单位，因此进程是动态的。系统运行一个程序即是一个进程从创建，运行到消亡的过程。
在 Java 中，当我们启动 main 函数时其实就是启动了一个 JVM 的进程，而 main 函数所在的线程就是这个进程中的一个线程，也称主线程

线程与进程相似，但线程是一个比进程更小的执行单位。一个进程在其执行的过程中可以产生多个线程。与进程不同的是同类的多个线程共享进程的堆和方法区资源，但每个线程有自己的程序计数器、虚拟机栈和本地方法栈，所以系统在产生一个线程，或是在各个线程之间作切换工作时，负担要比进程小得多，也正因为如此，线程也被称为轻量级进程

初始(NEW)：新创建了一个线程对象，但还没有调用start()方法

运行(RUNNABLE)：Java线程将操作系统中的就绪（ready）和运行中（running）两种状态笼统的称为“运行”。

• 线程对象创建后，其他线程(比如main线程）调用了该对象的start()方法。该状态的线程位于可运行线程池中，等待被线程调度选中，获取CPU的使用权，此时处于就绪状态（ready）。就绪状态的线程在获得CPU时间片后变为运行中状态（running）

阻塞(BLOCKED)：表示线程阻塞于锁。

等待(WAITING)：进入该状态的线程需要等待其他线程做出一些特定动作（通知或中断）。

超时等待(TIMED_WAITING)：该状态不同于WAITING，它可以在指定的时间后自行返回

终止(TERMINATED)：表示该线程已经执行完毕

注意：Java将操作系统中的运行和就绪两个状态合并称为运行状态。阻塞状态是线程阻塞在进入synchronized关键字修饰的方法或代码块时的状态，但是阻塞在java.concurrent包中Lock接口的线程状态却是等待状态，因为java.concurrent包中Lock接口对于阻塞的实现均使用了LockSupport类中的相关方法

当线程执行 wait()方法之后，线程进入 WAITING（等待） 状态。进入等待状态的线程需要依靠其他线程的通知或中断才能够返回到运行状态，而 TIME_WAITING(超时等待) 状态相当于在等待状态的基础上增加了超时限制，比如通过 sleep（long millis）方法或 wait（long millis）方法可以将 Java 线程置于 TIMED WAITING 状态。当超时时间到达后 Java 线程将会返回到 RUNNABLE 状态。当线程调用同步方法时，在没有获取到锁的情况下，线程将会进入到 BLOCKED（阻塞） 状态。线程在执行 Runnable 的run()方法之后将会进入到 TERMINATED（终止） 状态。

线程死锁描述的是这样一种情况：多个线程同时被阻塞，它们中的一个或者全部都在等待某个资源被释放。由于线程被无限期地阻塞，因此程序不可能正常终止。

比如，线程 A 持有资源 2，线程 B 持有资源 1，他们同时都想申请对方的资源，所以这两个线程就会互相等待而进入死锁状态。

1. 互斥条件：该资源任意一个时刻只由一个线程占用。
2. 请求与保持条件：一个进程因请求资源而阻塞时，对已获得的资源保持不放。
3. 不剥夺条件：线程已获得的资源在末使用完之前不能被其他线程强行剥夺，只有自己使用完毕后才释放资源。
4. 循环等待条件：若干进程之间形成一种头尾相接的循环等待资源关系。

我上面说了产生死锁的四个必要条件，为了避免死锁，我们只要破坏产生死锁的四个条件中的其中一个就可以了。现在我们来挨个分析一下：

• 破坏互斥条件 ：这个条件我们没有办法破坏，因为我们用锁本来就是想让他们互斥的（临界资源需要互斥访问）。
• 破坏请求与保持条件 ：一次性申请所有的资源。
• 破坏不剥夺条件 ：占用部分资源的线程进一步申请其他资源时，如果申请不到，可以主动释放它占有的资源。
• 破坏循环等待条件 ：靠按序申请资源来预防。按某一顺序申请资源，释放资源则反序释放。破坏循环等待条件。（两个线程都按照同样的获取锁资源顺序，这样B线程没有获取到第一个资源也就不会获取并占用第二个资源）

因为监视器锁（monitor）是依赖于底层的操作系统的 Mutex Lock 来实现的，Java 的线程是映射到操作系统的原生线程之上的。如果要挂起或者唤醒一个线程，都需要操作系统帮忙完成，而操作系统实现线程之间的切换时需要从用户态转换到内核态，这个状态之间的转换需要相对比较长的时间，时间成本相对较高

不管什么锁都是串行化线程，重量级锁之所以慢是因为需要调用操作系统级别（内核态）的指令，而且会挂起阻塞的线程，来回切换。偏向锁、轻量锁并不会，大部分场景都不会升级重量锁，在偏向锁跟轻量锁基本都能满足了

同步实例方法，锁是当前实例对象

• public synchronized void method()

同步类方法，锁是当前类对象

• public static synchronized void method()

同步代码块，锁是括号里面的对象

• synchronized (obj)

创建对象的时候会分为三个指令：1-new（堆中开辟空间）、2-invokespecial（初始化对象）、3-astore_1（将instance指向堆中的地址），java存在指令重排优化，因为不可见性，所以可能存在线程B拿到线程A的没有初始化的空对象（1-new（堆中开辟空间）、3-astore_1（将instance指向堆中的地址）、2-invokespecial（初始化对象））

假如使用强引用作为ThreadLocalMap里面的key存在什么问题呢，比如说我们创建了一个ThreadLocal变量，并设置了值，此时我们ThreadLocal对象存在两个引用指向它（我们自己的TIME_THREADLOCAL 跟ThreadLocalMap的Entry对象里面的引用），如果我们将TIME_THREADLOCAL=null，此时这个ThreadLocal对象因为存在引用无法被回收，只有当前线程结束后随着ThreadLocalMap释放才会被回收

corePoolSize：线程池中的核心线程数，当提交一个任务时，线程池创建一个新线程执行任务，直到当前线程数等于corePoolSize；如果当前线程数为corePoolSize，继续提交的任务被保存到阻塞队列中，等待被执行；如果执行了线程池的prestartAllCoreThreads()方法，线程池会提前创建并启动所有核心线程

maximumPoolSize：线程池中允许的最大线程数。如果当前阻塞队列满了，且继续提交任务，则创建新的线程执行任务，前提是当前线程数小于maximumPoolSize

keepAliveTime：线程池维护线程所允许的空闲时间。当线程池中的线程数量大于corePoolSize的时候，如果这时没有新的任务提交，核心线程外的线程不会立即销毁，而是会等待，直到等待的时间超过了keepAliveTime

unit：keepAliveTime的单位；可选的单位有天（DAYS）、小时（HOURS）、分钟（MINUTES）、毫秒（MILLISECONDS）、微秒（MICROSECONDS，千分之一毫秒）和纳秒（NANOSECONDS）

workQueue：用来保存等待被执行的任务的阻塞队列，且任务必须实现Runable接口，在JDK中提供了如下阻塞队列：

• ArrayBlockingQueue：基于数组结构的有界阻塞队列，按FIFO排序任务；
• LinkedBlockingQuene：基于链表结构的阻塞队列，按FIFO排序任务，吞吐量通常要高于ArrayBlockingQuene；
• SynchronousQuene：一个不存储元素的阻塞队列，每个插入操作必须等到另一个线程调用移除操作，否则插入操作一直处于阻塞状态，吞吐量通常要高于LinkedBlockingQuene；
• priorityBlockingQuene：具有优先级的无界阻塞队列；

threadFactory：它是ThreadFactory类型的变量，用来创建新线程。默认使用Executors.defaultThreadFactory() 来创建线程。使用默认的ThreadFactory来创建线程时，会使新创建的线程具有相同的NORM_PRIORITY优先级并且是非守护线程，同时也设置了线程的名称

handler：线程池的饱和策略，当阻塞队列满了，且没有空闲的工作线程，如果继续提交任务，必须采取一种策略处理该任务，线程池提供了4种策略：

• AbortPolicy：直接抛出异常，默认策略；
• CallerRunsPolicy：用调用者所在的线程来执行任务；
• DiscardOldestPolicy：丢弃阻塞队列中靠最前的任务，并执行当前任务；
• DiscardPolicy：直接丢弃任务；

上面的4种策略都是ThreadPoolExecutor的内部类。当然也可以根据应用场景实现RejectedExecutionHandler接口，自定义饱和策略，如记录日志或持久化存储不能处理的任务

ThreadPoolExecutor采取上述步骤的总体设计思路，是为了在执行execute()方法时，尽可能地避免获取全局锁（那将会是一个严重的可伸缩瓶颈）。在ThreadPoolExecutor完成预热之后（当前运行的线程数大于等于corePoolSize），几乎所有的execute()方法调用都是执行步骤2，而步骤2不需要获取全局锁。

线程池中的线程执行任务分两种情况，如下：
1）在execute()方法中创建一个线程时，会让这个线程执行当前任务。
2）这个线程执行完上图中1的任务后，会反复从BlockingQueue获取任务来执行

MMM（Master-Master replication manager for Mysql），Mysql主主复制管理器是一套灵活的脚本程序，基于perl实现，用来对mysql replication（复制）进行监控和故障迁移，并能管理mysql Master-Master复制的配置(同一时间只有一个节点是可写的)

MHA服务，有两种角色， MHA Manager(管理节点)和 MHA Node(数据节点)。在MySQL故障切换过程中，MHA能做到在0~30秒之内自动完成数据库的故障切换操作，目前MHA主要支持一主多从的架构，要搭建MHA,要求一个复制集群中必须最少有三台数据库服务器

二叉树是n(n>=0)个结点的有限集合，该集合或者为空集（称为空二叉树），或者由一个根结点和两棵互不相交的、分别称为根结点的左子树和右子树组成。
插入一个数据的时候它会先比较如果比这个数大就往右边走，直到走到最下面一层

二叉树的特点：

• 1）每个结点最多有两颗子树，所以二叉树中不存在度大于2的结点。
• 2）左子树和右子树是有顺序的，次序不能任意颠倒。
• 3）即使树中某结点只有一棵子树，也要区分它是左子树还是右子树

二叉树的性质：

• 1）在二叉树的第i层上最多有2i-1 个节点 。（i>=1）
• 2）二叉树中如果深度为k,那么最多有2k-1个节点。(k>=1）
• 3）n0=n2+1 n0表示度数为0的节点数，n2表示度数为2的节点数。
• 4）在完全二叉树中，具有n个节点的完全二叉树的深度为[log2n]+1，其中[log2n]是向下取整

为什么mysql不使用二叉树为索引结构

红黑树也是二叉查找树，所以又可叫二叉平衡树。我们知道，二叉查找树这一数据结构并不难，而红黑树之所以难是难在它是自平衡的二叉查找树，在进行插入和删除等可能会破坏树的平衡的操作时，需要重新自处理达到平衡状态。现在在脑海想下怎么实现？是不是太多情景需要考虑了？先来看下红黑树的定义和一些基本性质

• 所谓的平衡说的是不会造成结构线性化，规定叶子节点的高度差不超过1
  

红黑树定义和性质：

• 性质1：每个节点要么是黑色，要么是红色。
• 性质2：根节点是黑色。
• 性质3：每个叶子节点（NIL）是黑色。
• 性质4：每个红色结点的两个子结点一定都是黑色。
• 性质5：任意一结点到每个叶子结点的路径都包含数量相同的黑结点。

为什么mysql不使用二叉树为索引结构

相当于红黑树的节点横向扩展放更多的数据（红黑树一个节点只有一个数据，B-Tree一个节点有多个数据），在存放相同数据的情况下，横向放的越多，高度也就会越低

m阶B-Tree满足以下条件：

• 每个节点最多拥有m个子树
• 根节点至少有2个子树
• 分支节点至少拥有m/2颗子树（除根节点和叶子节点外都是分支节点）
• 所有叶子节点都在同一层、每个节点最多可以有m-1个key，并且以升序排列

从查找过程中发现，B树的比对次数磁盘IO的次数与二叉树相差不了多少，所以这样看来并没有什么优势。但是仔细一看会发现，比对是在内存中完成中，不涉及到磁盘IO，耗时可以忽略不计。另外B树中一个节点可以存放很多的key（个数由树阶决定）。相同数量的key在B树中生成的节点要远远少于二叉树中的节点，相差的节点数量就等同于磁盘IO的次数。这样到达一定数量后，性能的差异就显现出来了

为什么mysql不使用B-Tree为索引结构

B-Tree只是每个节点存多个数据，而B+Tree是每个节点存多个数据的索引（），数据存在最下层的叶子节点，最下层数据有序且不同叶子会指向下一个叶子

B+Tree特点：

• 有m个子树的节点包含有m个元素（B-Tree中是m-1）
• 根节点和分支节点中不保存数据，只用于索引，所有数据都保存在叶子节点中。也就是最下面那行包含了所有的数据
• 所有分支节点和根节点都同时存在于子节点中，在子节点元素中是最大或者最小的元素。
• 叶子节点会包含所有的关键字，以及指向数据记录的指针，并且叶子节点本身是根据关键字的大小从小到大顺序链接。

• 非叶子节点不存储data，只存储索引(冗余)，可以放更多的索引
• 叶子节点包含所有索引字段
• 叶子节点用指针连接，提高区间访问的性能，这里用了双向，标准的只有单向

• 最底下为叶子节点，存储我们的索引跟数据（叶子节点中包含所有数据）；这个Data可能是行地址，也可能就是所有的行数据，这跟存储引擎有关，InnoDb为行数据
  
• 非叶子节点（第一第二行）只存储索引，保证可以放入更多的索引
• 在非叶子节点中间存储了下一个节点的地址，比如【15-56】这个节点的中间存放着【15-20-49】这个节点的地址，【15-20-49】又在【15-56】大小之间
• 两个叶子节点相当于双向链表一样存储了各自的地址：这个地址在范围查找的时候有很大的帮助，如果我找col>20的，那我只要找到col=20就可以了，然后就直接返回后面的数据（所以范围查找可以走索引），在B-Tree树就不行
• 叶子结点跟非叶子节点都是有序的，左<右，如果把下图红色框出来的单独拎出来也相当于一个二叉树结构，当数据在一个格子放不下的时候会把最小的那个提到冗余节点中

在delete、update的时候有时候会重新整理索引结构，这个可以在可视化网站上试试就知道了。如果说索引值存在大量的null，null会放在叶子节点的最左边，有大量null的时候去查找个人感觉索引这方面影响并不会很大，主要是其他原因，比如下面
允许null的字段需要额外的空间来保存字段Null到null标志位映射的对应关系，所以保存这个映射关系的null标志位长度并不是固定的。也就是null字段越多并不是越省空间。实际生产环境中应尽量减少canbenull的字段

1、从代码编写角度分许,数据插入的时候,的确可以带来方便,但是在读取数据的时候,会带来大量的数据非空检查,否则抛出NullPointException.
2、从数据库字段长度占用角度分析,相同长度字段,null比非null存储空间长度占用多1个字节,因为需要一个额外字段判断是否是null值.
3、从sql语句查询角度分析,null值列和其他列进行操作可能引发错误.

查找数据的时候跟上面说的B-Tree一样，每次IO读取一页索引数据到内存，然后在内存中比较（二分查找，耗时忽略不计），也就是说我们这里查找数据最多也就3次IO，可想为什么索引能做到了吧，就算数据量大道两千万也是3次IO，一样很快，下面分析

几个问题

对索引的key进行一次hash计算就可以定位出数据存储的位置
很多时候Hash索引要比B+ 树索引更高效

• 比如当没有hash冲突的时候一下子就能确定数据地址，而B+树可能需要几次的IO

仅能满足 “=”，“IN”，不支持范围查询

• 它是没法范围查找的，范围查找走不了索引

hash冲突问题

• hash冲突问题影响不会很大

比如我要对col3这一列构建hash索引，会先对列值取通过hash()得到一个数字，然后放入到对应的hash结构中，如果存在hash相等的会形成一个链表，数据为Map<列值，行数据地址>。当取数据的时候也是 先计算出hash()，然后定位到hash表中的位置，如果有多个map，就遍历得到，然后再从磁盘中读取数据

聚集索引（clustered index）就是按照每张表的主键构造一棵B+树，同时叶子节点中存放的即为整张表的行记录数据（聚集索引-叶节点包含了完整的数据记录），也将聚集索引的叶子节点称为数据页。聚集索引的这个特性决定了索引组织表中数据也是索引的一部分。聚集不就是非稀疏吗，嘿嘿【每张表只能拥有一个聚集索引】

InnoDB索引实现主键索引为聚集索引，Secondary索引（二级索引）为非聚集索引（辅助索引），所以说不要理解为InnoDb都是聚集索引啊

而且在我们InnoDb的表中，数据都是通过构建聚集索引构建的，也就是说id就是个索引，表数据文件本身就是按B+Tree组织的一个索引结构文件
聚集索引默认是主键，如果表中没有定义主键，InnoDB 会选择一个唯一且非空的索引代替。如果没有这样的索引，InnoDB 会隐式定义一个主键（类似oracle中的RowId）来作为聚集索引。如果已经设置了主键为聚集索引又希望再单独设置聚集索引，必须先删除主键，然后添加我们想要的聚集索引，最后恢复设置主键即可

InnoDb中的聚集索引文件结构

为什么建议InnoDB表必须建主键，并且推荐使用整型的自增主键？

为什么非主键索引结构中的叶子节点存储的是主键值？(一致性和节省存储空间)

辅助索引（Secondary Index，也称非聚集索引），叶子节点并不包含行记录的全部数据。叶子节点除了包含键值以外，每个叶子节点中的索引行中还包含了指向主键的指针。
辅助索引的存在并不影响数据在聚集索引中的组织，因此每张表上可以有多个辅助索引。当通过辅助索引来寻找数据时，InnoDB存储引擎会遍历辅助索引并通过叶级别的指针获得指向主键索引的主键，然后再通过聚集索引来找到一个完整的行记录（也就是回表查询操作，会根据这个id去查找到数据）

MyISAM中文件结构

使用EXPLAIN关键字可以模拟优化器执行SQL语句，分析你的查询语句或是结构的性能瓶颈 。
在 select 语句之前增加 explain 关键字，MySQL 会在查询上设置一个标记，执行查询会返回执行计划的信息，而不是执行这条SQL
注意：如果 from 中包含子查询，仍会执行该子查询，将结果放入临时表中

在查询中的每个表会输出一行，如果有两个表通过 join 连接查询，那么会输出两行

explain extended

explain partitions

id列

select_type列

table列

type列

possible_keys列

key列

key_len列

ref列

rows列

Extra列

全值匹配

最左前缀法则

• 如果索引了多列，要遵守最左前缀法则。指的是查询从索引的最左前列开始并且不跳过索引中的列

不在索引列上做任何操作（计算、函数、（自动or手动）类型转换）

存储引擎不能使用索引中范围条件右边的列

尽量使用覆盖索引（只访问索引的查询（索引列包含查询列）），减少 select * 语句

mysql在使用不等于（！=或者<>）的时候无法使用索引会导致全表扫描

is null,is not null 一般情况下也无法使用索引

• 如果字段设置了不可为null，mysql直接返回空数据，而不去找表

like以%通配符开头（'$abc...'）mysql索引失效会变成全表扫描操作

字符串不加单引号索引失效

• name为字符串类型，使用数字索引会失效。所以需要保持跟索引类型一样

少用or或in

范围查询优化

原子性(Atomicity)：原子性操作可以理解为把一个事务中个多个操作看成为一个操作一样，只存在全部成功跟全部失败的可能

一致性(Consistent)：原子性站在操作层面（多个操作看成一个操作），一致性为站在数据的层面上--事务的各个操作都修改数据成功，也就是数据从一个状态到另一个状态必须是一致的，比如A向B转账（A、B的总金额就是一个一致性状态），不可能出现A扣了钱，B却没收到的情况发生

隔离性(Isolation)：事务处理过程中的中间状态对外部是不可见的，数据的隔离性是针对并发事务而言，非并发事务是天然隔离的。并发事务是指两个事务操作了同一份数据的情况；

持久性(Durable)：事务完成之后,它对于数据的修改是永久性的,即使出现系统故障也能够保持

更新丢失(Lost Update)（脏写）

脏读（Dirty Reads）

不可重读（Non-Repeatable Reads）

幻读（Phantom Reads）

数据库的事务隔离越严格，并发副作用越小,但付出的代价也就越大，因为事务隔离实质上就是使事务在一定程度上“串行化”进行，这显然与“并发”是矛盾的。同时，不同的应用对读一致性和事务隔离程度的要求也是不同的，比如许多应用对“不可重复读"和“幻读”并不敏感，可能更关心数据并发访问的能力

Mysql默认的事务隔离级别是可重复读，用Spring开发程序时，如果不设置隔离级别默认用Mysql设置的隔离级别，如果Spring设置了就用spring设置的隔离级别

四种隔离级别

数据的隔离级别是针对会话的（也就是连接）

可重复读级别下出现幻读解释

可串行化下的加锁避免幻读说明

MyISAM存储引擎默认在select加读锁（表锁），写时加写锁（表锁），加上它不支持事务begin-commit，所以它压根就不需要隔离级别，这本身就相当于默认串行化了

说说我对事务隔离级别的理解吧

从性能上分为乐观锁(用版本对比来实现)和悲观锁

从对数据库操作的类型分，分为读锁和写锁(都属于悲观锁)

从对数据操作的粒度分，分为表锁和行锁

表锁（分为读锁跟写锁）
InnoDb跟MyISAM都支持

行锁（只有InnoDb有）

总结

间隙锁(Gap Lock)

临键锁(Next-key Locks)

无索引行锁会升级为表锁

lock in share mode(共享锁) 和for update(排它锁)

Innodb行锁跟MYISAM表锁结论

行锁分析

系统库锁相关数据表

死锁

锁优化建议

表锁（分为读锁跟写锁）
InnoDb跟MyISAM都支持

行锁（只有InnoDb有）

lock in share mode(共享锁) 和for update(排它锁)

默认加锁方式

Mysql在可重复读隔离级别下如何保证事务较高的隔离性，上一篇讲过，同样的sql查询语句在一个事务里多次执行查询结果相同，就算其它事务对数据有修改也不会影响当前事务sql语句的查询结果。这个隔离性就是靠MVCC(Multi-Version Concurrency Control)机制来保证的，对一行数据的读操作默认是不会通过加锁互斥来保证隔离性，避免了频繁加锁互斥，而在串行化隔离级别为了保证较高的隔离性是通过将所有操作加锁互斥来实现的

Mysql在读已提交和可重复读隔离级别下都实现了MVCC机制

undo日志版本链

read view机制

undo版本链比对规则

客户端执行
update account set name = 'libo666' where id = 1; //id=1的name原始值为libo

• 1、如果bufferPool池（数据库的增删改查都是操作bufferPool中的数据，内存大小一般设置为机器内存的60%）中有id=1的数据直接用即可，如果没有需要从idb文件中加载id=1数据所在的page页至bufferPool缓存中；
• 2、写入更新数据的旧值到undo版本链日志（InnoDb特有）中。如果事务提交失败可以使用undo日志恢复bufferPool池中的数据；
• 3、更改bufferPool池中的数据为新数据name=libo666；
• 4、同时会将新数据写入到redo log bufferPool池中；
• 5、当提交事务的时候，将redo log bufferPool中的日志写入磁盘中的redo日志文件（InnoDb特有，如果事务提交成功后，bufferPool的数据没来得及写入磁盘的idb文件中，此时宕机了，可以使用redo日志文件恢复bufferPool的缓存数据），也就是将新数据写入redo日志文件中（redo日志都是顺序写入的，速度非常快，而且是特定大小的文件，写满了就再创建一个文件）；
• 6、当提交事务同时，将新数据写入binlog日志文件（属于server层，主要用于恢复数据）；
• 7、写入binlog成功后，写入commit标记（用于保证redo日志跟binlog日志数据一致）到redo文件中，事务到这里算提交完成；
• 8、后台会有IO线程，随机将bufferPool池中的数据以page页为单位写入到磁盘中，这步完成后磁盘数据才为新数据libo666

• 因为来一个请求就直接对磁盘文件进行随机读写，然后更新磁盘文件里的数据，性能可能相当差。
• 因为磁盘随机读写的性能是非常差的，所以直接更新磁盘文件是不能让数据库抗住很高并发的。
• Mysql这套机制看起来复杂，但它可以保证每个更新请求都是更新内存BufferPool，然后顺序写日志文件，同时还能保证各种异常情况下的数据一致性。
• 更新内存的性能是极高的，然后顺序写磁盘上的日志文件的性能也是非常高的，要远高于随机读写磁盘文件。

正是通过这套机制，才能让我们的MySQL数据库在较高配置的机器上每秒可以抗下几干的读写请求。

为了保证数据的一致性和耐久性，InnoDB存储引擎和MySQL服务器层在处理事务时需要同步redo log和binlog。
采用两阶段提交

1.事务开始执行，数据库的修改操作首先写入redo log的Log Buffer。
2.当事务提交时，InnoDB会遵循两阶段提交协议来确保binlog和redo log的同步：

• 第一阶段：将redo log从Log Buffer刷入redo log files，确保这些修改被持久化到磁盘。然后事务会被标记为prepare状态。
• 第二阶段：MySQL服务器层记录相应的修改到binlog。完成后，InnoDB会将事务从prepare状态改为commit状态，此时事务被认为是提交成功的。

3.如果在第二阶段写入binlog之前发生崩溃，MySQL在重启时会检查所有处于prepare状态的事务，并通过binlog来决定是否提交或回滚这些事务。

这种两阶段提交机制确保了即使在系统崩溃的情况下，redo log和binlog也能保持一致性，从而保证了数据库的一致性和可靠性

在 MySQL 中，InnoDB 存储引擎使用一块称为缓冲池（Buffer Pool）的内存区域，来缓存频繁访问的数据，以减少对磁盘I/O的依赖，提高数据库性能。缓冲池的有效管理对于数据库的整体性能是非常关键的。以下是一些有关于 InnoDB 缓冲池内存管理的要点：

缓冲池的作用
数据页缓存：当一个数据页（如：表的数据和索引）被加载到 Buffer Pool 时，InnoDB 可以直接从内存中访问它，而不是从磁盘中读取。这大大加速了数据检索。
脏页的刷新：当事务修改了缓存的数据页时，这些数据页被标记为"脏页"。这些脏页最终会在一定时机（如：事务提交、检查点创建或者背景写入任务触发时）被刷新回磁盘。
Change Buffer：对非唯一非聚簇索引的修改不会立即写入磁盘，而是缓存到 Buffer Pool 中的 Change Buffer 区域，当这一部分的数据页被加载到 Buffer Pool 时，变更才会被合并并应用到页上。
读写冲突减少：Buffer Pool 提供了一种机制来管理对数据的并发访问，包括锁和数据一致性。

内存分配与管理
大小设置：Buffer Pool 的大小由 innodb_buffer_pool_size 配置参数控制。建议将其设置为可用内存的大部分，但要为操作系统和其他服务器进程留出足够空间。
多个 Buffer Pool 实例：可以将 Buffer Pool 分割为多个独立的实例，通过 innodb_buffer_pool_instances 配置。这有助于减少争用并改善多核系统上的性能。
LRU 算法：Buffer Pool 使用最近最少使用（LRU）列表维护页面。最常访问的页位于列表的前端，而最少访问的页位于列表后端，从而可以在需要时逐出。

内存压缩，预读和刷新策略
内存压缩：InnoDB 可以缩放页来压缩数据，从而在Buffer Pool中存储更多的数据。
预读：InnoDB 使用预读机制自动或手动预加载可能即将被查询的数据页。
脏页刷新策略：通过 innodb_flush_method 和相关的 innodb_io_capacity 参数配置，InnoDB 可以管理脏页何时被写入磁盘。

监控和维护
性能监控：使用 SHOW ENGINE INNODB STATUS SQL 语句或者性能模式（Performance Schema）获取 Buffer Pool 的状态信息。
页面压缩: 对于压缩表，InnoDB Buffer Pool 会在需要时自动解压和重新压缩页。
内存管理: InnoDB 缓冲池内存管理是内置的，MySQL 数据库管理员通常不需要手动管理内存分配。

配置 Buffer Pool 的大小和行为通常依赖于系统的工作负载、硬件资源和性能要求。为了优化性能，数据库管理员可能需要调整 Buffer Pool 相关配置参数，并监控其性能指标，通过试验找到最佳的配置。

理解：name>'xxx'，mysql根据ASCLL码估算，排在前面的结果集会很大（避免回表次数，故不走索引），排到后面的认为结果集会很小（回表少，故走索引）

• name>xxx在数据量大的时候，name>a就更大了，所以不走索引，而name>zzz 的结果集一般会小（毕竟z在字母顺序最后面），所以走索引
• 通过实验证明确实如此，而且就算是表中数据量小，name>a也是ALL，name>zzz因为z在字母顺序最后面mysql估计结果集很少会选择走索引
  这里我觉得是可以继续优化的，比如应该是表数据小的时候a、z都不走索引，表数据大的时候a-ALL，z-range，而不是z不管数据多不多都走索引

理解：in跟or，mysql觉得就算表数据量大结果也不会很多，回表次数自然少，所以表数据量大走索引，表数据量少不走索引
跟上面的范围查找相反居然，按理是不是应该一样的，毕竟记录多回表次数多（我复制过一个表当查询到的数据多，in和or也会走索引）。可以这么理解，name>xx比name in (...)跟or比较，name>xxx在数据量大的时候，结果集一般会更大，所以回表次数就多，此时不走索引比走索引可能更好，然后in跟or就算数据量大的时候，结果集也不会很大，然后回表次数也就不会很大，而且我可以直接通过全部索引快速定位找到，自然是走索引好些

但是在数据量少的时候都不走索引，这就有点儿奇怪，只能认为它跟>或者like采用判断方式不同了，它觉得数据少就都没必要走索引了，可能这个开发者认为回表代价大。其实就是在数据量少的情况下，在索引检索跟回表直接平衡选择中，like跟>选择了回表，in跟or选择了不回表

理解：like xx%，在索引树上其实跟>'xxx'一样的道理，所以是否采用索引判断也一样，但它在表数据量小的时候都走索引

• like xx%在数据量大的时候，like aa%就更大了，所以不走索引，而like zz% 的结果集一般会小（毕竟z在字母顺序最后面），所以走索引
• 表数据量小，结果集肯定小，所以回表次数少，故like xx%都是range

索引下推

MySQL支持两种方式的排序filesort和index，Using index是指MySQL扫描索引本身完成排序。index效率高，filesort效率低

order by满足两种情况会使用Using index。
1) order by语句使用索引最左前列。
2) 使用where子句与order by子句条件列组合满足索引最左前列

尽量在索引列上完成排序，遵循索引建立（索引创建的顺序）时的最左前缀法则

如果order by的条件不在索引列上，就会产生Using filesort

能用覆盖索引尽量用覆盖索引

group by与order by很类似，其实质是先排序后分组，遵照索引创建顺序的最左前缀法则。对于group by的优化如果不需要排序的可以加上order by null禁止排序。注意，where高于having，能写在where中的限定条件就不要去having限定了

• 单路排序：是一次性取出满足条件行的所有字段，然后在sort buffer（每个客户端建立连接后server端都会为其开辟一块内存缓存池）中进行排序；用trace工具可以看到sort_mode信息里显示< sort_key, additional_fields >或者< sort_key, packed_additional_fields >
  
  
• 双路排序（又叫回表排序模式）：是首先根据相应的条件取出相应的排序字段和可以直接定位行数据的行 ID，然后在 sort buffer 中进行排序，排序完后需要再次取回其它需要的字段；用trace工具可以看到sort_mode信息里显示< sort_key, rowid >

MySQL 通过比较系统变量 max_length_for_sort_data(默认1024字节) 的大小和需要查询的字段总大小来判断使用哪种排序模式。

• 如果 字段的总长度小于max_length_for_sort_data ，那么使用 单路排序模式；
• 如果 字段的总长度大于max_length_for_sort_data ，那么使用 双路排序模式。

单路排序首先会在索引树中找到满足条件的id，然后回表获取全部数据，接着把数据放入sort buffer
双路排序在索引树中找到满足条件的数据后放入sort buffer中，排序完成后再回表数据

不管是单路排序还是双路排序，当sort_buffer内存不能一次性放下当前需要排序的所有记录的时候，都会降级采用磁盘排序。那怎么理解这个磁盘排序呢？可以这么理解：分批次的拉取需要排序的记录，每次排完后放入磁盘中，继续下一批记录排序，当全部排序后后再整理起来（可以理解为把每个批次的最大最小都保存在sort_buffer中，便于后续排序所有批次）

注意，如果全部使用sort_buffer内存排序一般情况下效率会高于磁盘文件排序，但不能因为这个就随便增大sort_buffer(默认1M)，mysql很多参数设置都是做过优化的，不要轻易调整。

表示从表 employees 中取出从 10001 行开始的 10 行记录。看似只查询了 10 条记录，实际这条 SQL 是先读取 10010 条记录，然后抛弃前 10000 条记录，得到 10 条我们想要的数据。因此要查询一张大表比较靠后的数据，执行效率是非常低的。

• select * from employees limit 10000,10;
• select * from employees ORDER BY name limit 90000,5;

那这种该怎么优化呢？

• 如果是主键有序可以修改成id范围查询：select * from employees where id > 90000 limit 5;  但是实际场景基本不适用
• 如果非主键条件可以采用子查询（让排序时返回的字段尽可能少）：select * from employees e inner join (select id from employees order by name limit 90000,5) ed on e.id = ed.id;
• 业务限制：一般这种场景很少的，谁会没事查那么多页，通过业务处理，比如添加条件、只提供近一年的数据查看等

mysql的表关联常见有两种算法

对于关联sql的优化

count(*)、count(1)、count(字段)、count(主键 id)
只有count(字段)不会统计null值

常见优化方法

在MySQL中，选择正确的数据类型，对于性能至关重要。一般应该遵循下面两步： （1）确定合适的类型：数字、字符串、时间、二进制； （2）确定具体的类型：有无符号、取值范围、变长定长等。 在MySQL数据类型设置方面，尽量用更小的数据类型，因为它们通常有更好的性能，花费更少的硬件资源。并且，尽量把字段定义为NOT NULL，避免使用NULL

Server层：主要包括连接器、查询缓存、分析器、优化器、执行器等，涵盖 MySQL 的大多数核心服务功能，以及所有的内置函数（如日期、时间、数学和加密函数等），所有跨存储引擎的功能都在这一层实现，比如存储过程、触发器、视图等

Store层：存储引擎层负责数据的存储和提取。其架构模式是插件式的，支持 InnoDB、MyISAM、Memory 等多个存储引擎。现在最常用的存储引擎是 InnoDB，它从 MySQL 5.5.5 版本开始成为了默认存储引擎。也就是说如果我们在create table时不指定表的存储引擎类型,默认会给你设置存储引擎为InnoDB

向mysql发起通信都必须先跟Server端建立通信连接，而建立连接的工作就是由连接器完成的。

连接命令中的 mysql 是客户端工具，用来跟服务端建立连接。在完成经典的 TCP 握手后，连接器就要开始认证你的身份，这个时候用的就是你输入的用户名和密码。

• 1、如果用户名或密码不对，你就会收到一个"Access denied for user"的错误，然后客户端程序结束执行。
• 2、如果用户名密码认证通过，连接器会到权限表里面查出你拥有的权限。之后，这个连接里面的权限判断逻辑，都将依赖于此时读到的权限（缓存起来）

这就意味着，一个用户成功建立连接后，即使你用管理员账号对这个用户的权限做了修改，也不会影响已经存在连接的权限。修改完成后，只有再新建的连接才会使用新的权限设置。用户的权限表在系统表空间的mysql的user表中。

连接完成后，如果你没有后续的动作，这个连接就处于空闲状态，你可以在 show processlist 命令中看到它，其中的 Command 列显示为“Sleep”的这一行，就表示现在系统里面有一个空闲连接，关闭连接 kill <id>

客户端如果长时间不发送command到Server端，连接器就会自动将它断开。这个时间是由参数 wait_timeout 控制的，默认值是 8 小时。

在实际中都会将连接放入连接池中，保持长连接，但是长连接有些时候会导致 MySQL 占用内存涨得特别快，这是因为 MySQL 在执行过程中临时使用的内存是管理在连接对象里面的（每次连接成功后都会开辟一些空间用来缓存各种信息，比如权限等）。这些资源会在连接断开的时候才释放。所以如果长连接累积下来，可能导致内存占用太大，被系统强行杀掉（OOM），从现象看就是 MySQL 异常重启了

怎么解决长连接占用内存太大这类问题呢？
1、定期断开长连接。使用一段时间，或者程序里面判断执行过一个占用内存的大查询后，断开连接，之后要查询再重连。
2、如果你用的是 MySQL 5.7 或更新版本，可以在每次执行一个比较大的操作后，通过执行 mysql_reset_connection 来重新初始化连接资源。这个过程不需要重连和重新做权限验证，但是会将连接恢复到刚刚创建完时的状态。

连接建立完成后，你就可以执行 select 语句了。执行逻辑就会来到第二步：查询缓存。

MySQL 拿到一个查询请求后，会先到查询缓存看看，之前是不是执行过这条语句。之前执行过的语句及其结果可能会以 key-value 对的形式，被直接缓存在内存中。key 是查询的语句，value 是查询的结果。如果你的查询能够直接在这个缓存中找到 key，那么这个 value 就会被直接返回给客户端。
如果语句不在查询缓存中，就会继续后面的执行阶段。执行完成后，执行结果会被存入查询缓存中。你可以看到，如果查询命中缓存，MySQL 不需要执行后面的复杂操作，就可以直接返回结果，这个效率会很高。

大多数情况查询缓存就是个鸡肋，为什么呢？
因为查询缓存往往弊大于利。查询缓存的失效非常频繁，只要有对一个表的更新，这个表上所有的查询缓存都会被清空。因此很可能你费劲地把结果存起来，还没使用呢，就被一个更新全清空了。对于更新压力大的数据库来说，查询缓存的命中率会非常低。
一般建议大家在静态表里使用查询缓存，什么叫静态表呢？就是一般我们极少更新的表。比如，一个系统配置表、字典表，那这张表上的查询才适合使用查询缓存。好在 MySQL 也提供了这种“按需使用”的方式。你可以将my.cnf参数 query_cache_type 设置成 DEMAND。
mysql8.0已经移除了查询缓存功能

如果没有命中查询缓存，就要开始真正执行语句了。首先，MySQL 需要知道你要做什么，因此需要对 SQL 语句做解析。

词法分析：分析器先会做“词法分析”。你输入的是由多个字符串和空格组成的一条 SQL 语句，MySQL 需要识别出里面的字符串分别是什么，代表什么。
语法分析：根据词法分析的结果，语法分析器会根据语法规则，判断你输入的这个 SQL 语句是否满足 MySQL 语法

经过了分析器，MySQL 就知道你要做什么了。在开始执行之前，还要先经过优化器的处理

优化器是在表里面有多个索引的时候，决定使用哪个索引；或者在一个语句有多表关联（join）的时候，决定各个表的连接顺序

优化后就真正调用存储引擎接口开始查询语句

开始执行的时候，要先判断一下你对这个表 T 有没有执行查询的权限，如果没有，就会返回没有权限的错误，如下所示 (在工程实现上，如果命中查询缓存，会在查询缓存返回结果的时候，做权限验证。查询也会在优化器之前调用 precheck 验证权限)

执行步骤：

1. 调用 InnoDB 引擎接口取这个表的第一行，判断是否满足查询条件，如果不是则跳过，如果是则将这行存在结果集中；
2. 调用引擎接口取“下一行”，重复相同的判断逻辑，直到取到这个表的最后一行。
3. 执行器将上述遍历过程中所有满足条件的行组成的记录集作为结果集返回给客户端

【强制】表达是与否概念的字段，必须使用 is_xxx 的方式命名，数据类型是 unsigned tinyint（1 表示是，0 表示否）。

【强制】表名、字段名必须使用小写字母或数字，禁止出现数字开头，禁止两个下划线中间只出现数字。数据库字段名的修改代价很大，因为无法进行预发布，所以字段名称需要慎重考虑。

【强制】表名不使用复数名词

【强制】禁用保留字，如 desc、range、match、delayed 等，请参考 MySQL 官方保留字。

【强制】主键索引名为 pk_字段名；唯一索引名为 uk_字段名；普通索引名则为 idx_字段名

【强制】小数类型为 decimal，禁止使用 float 和 double

【强制】如果存储的字符串长度几乎相等，使用 char 定长字符串类型

【强制】varchar 是可变长字符串，不预先分配存储空间，长度不要超过 5000，如果存储长度大于此值，定义字段类型为 text，独立出来一张表，用主键来对应，避免影响其它字段索引效率。

【强制】表必备三字段：id, gmt_create, gmt_modified。

【强制】业务上具有唯一特性的字段，即使是组合字段，也必须建成唯一索引。

【强制】超过三个表禁止 join。需要 join 的字段，数据类型保持绝对一致；多表关联查询时，保证被关联的字段需要有索引。

【强制】在 varchar 字段上建立索引时，必须指定索引长度，没必要对全字段建立索引，根据实际文本区分度决定索引长度。

【强制】页面搜索严禁左模糊或者全模糊，如果需要请走搜索引擎来解决。

【强制】不要使用 count(列名)或 count(常量)来替代 count(*)，count(*)是 SQL92 定义的标准统计行数的语法，跟数据库无关，跟 NULL 和非 NULL 无关。

【强制】count(distinct col) 计算该列除 NULL 之外的不重复行数，注意 count(distinct col1, col2) 如果其中一列全为 NULL，那么即使另一列有不同的值，也返回为 0。

【强制】当某一列的值全是 NULL 时，count(col)的返回结果为 0，但 sum(col)的返回结果为NULL，因此使用 sum()时需注意 NPE 问题。
正例：可以使用如下方式来避免 sum 的 NPE 问题：SELECT IFNULL(SUM(column), 0) FROM table;

【强制】使用 ISNULL()来判断是否为 NULL 值

【强制】代码中写分页查询逻辑时，若 count 为 0 应直接返回，避免执行后面的分页语句

【强制】不得使用外键与级联，一切外键概念必须在应用层解决

【强制】禁止使用存储过程，存储过程难以调试和扩展，更没有移植性

【强制】数据订正（特别是删除或修改记录操作）时，要先 select，避免出现误删除，确认无误才能执行更新语句。

【强制】对于数据库中表记录的查询和变更，只要涉及多个表，都需要在列名前加表的别名（或表名）进行限定。

【强制】在表查询中，一律不要使用 * 作为查询的字段列表，需要哪些字段必须明确写明

【强制】POJO 类的布尔属性不能加 is，而数据库字段必须加 is_，要求在 resultMap 中进行字段与属性之间的映射。

【强制】不要用 resultClass 当返回参数，即使所有类属性名与数据库字段一一对应，也需要定义<resultMap>；反过来，每一个表也必然有一个<resultMap>与之对应。

【强制】sql.xml 配置参数使用：#{}，#param# 不要使用${} 此种方式容易出现 SQL 注入

【强制】iBATIS 自带的 queryForList(String statementName,int start,int size)不推荐使用。说明：其实现方式是在数据库取到 statementName 对应的 SQL 语句的所有记录，再通过 subList 取start,size 的子集合

【强制】不允许直接拿 HashMap 与 Hashtable 作为查询结果集的输出

【强制】更新数据表记录时，必须同时更新记录对应的 gmt_modified 字段值为当前时间

数据库在刷新脏页（flush）我也无奈啊

拿不到锁我能怎么办

扎心了，没用到索引

呵呵，数据库自己选错索引了

Redis 的单线程主要是指 Redis 的网络 IO 和键值对读写是由一个线程来完成的，这也是 Redis 对外提供键值存储服务的主要流程。但 Redis 的其他功能，比如持久化、异步删除、集群数据同步等，其实是由额外的线程执行的

因为它所有的数据都在内存中，所有的运算都是内存级别的运算，而且单线程避免了多线程的切换性能损耗问题。正因为 Redis 是单线程，所以要小心使用 Redis 指令，对于那些耗时的指令(比如keys)，一定要谨慎使用，一不小心就可能会导致 Redis 卡顿。 当然还有一个原因就是因为redis的多路复用IO模型。redis官方说明是支持每秒10w级别的命令处理

Redis的IO多路复用：redis利用epoll来实现IO多路复用，将连接信息和事件放到队列中，依次放到文件事件分派器（根据事件类型分派到不同处理器中处理），事件分派器将事件分发给事件处理器。这就是Redis 单线程如何处理那么多的并发客户端连接的原因。这个结合Netty的线程模型看容易理解

常用操作命令介绍

string应用场景

常用操作命令介绍

应用场景

Hash结构优缺点

List常用操作命令介绍

应用场景

Set常用操作命令介绍

应用场景

ZSet常用操作命令介绍

应用场景

• 计数器：可以对 String 进行自增自减运算，从而实现计数器功能。Redis 这种内存型数据库的读写性能非常高，很适合存储频繁读写的计数量。 
• 分布式ID生成：利用自增特性，一次请求一个大一点的步长如 incr 2000 ,缓存在本地使用，用完再请求。
• 海量数据统计：位图（bitmap）:存储是否参过某次活动，是否已读谋篇文章，用户是否为会员， 日活统计。
• 会话缓存：可以使用 Redis 来统一存储多台应用服务器的会话信息。当应用服务器不再存储用户的会话信息，也就不再具有状态，一个用户可以请求任意一个应用服务器，从而更容易实现高可用性以及可伸缩性。
• 分布式队列/阻塞队列：List 是一个双向链表，可以通过 lpush/rpush 和 rpop/lpop 写入和读取消息。可以通过使用brpop/blpop 来实现阻塞队列。
• 分布式锁实现：在分布式场景下，无法使用基于进程的锁来对多个节点上的进程进行同步。可以使用 Redis 自带的 SETNX 命令实现分布式锁。
• 热点数据存储：最新评论，最新文章列表，使用list 存储,ltrim取出热点数据，删除老数据。
• 社交类需求：Set 可以实现交集，从而实现共同好友等功能，Set通过求差集，可以进行好友推荐，文章推荐。
• 排行榜：sorted_set可以实现有序性操作，从而实现排行榜等功能。
• 延迟队列：使用sorted_set，使用 【当前时间戳 + 需要延迟的时长】做score, 消息内容作为元素,调用zadd来生产消息，消费者使用zrangbyscore获取当前时间之前的数据做轮询处理。消费完再删除任务 rem  key  member （可以直接使用带移除的命令：ZREMRANGEBYRANK key start stop）

KEYS pattern //查找所有符合给定模式 pattern 的 key 

• KEYS * 匹配数据库中所有 key 。
• KEYS h?llo 匹配 hello ， hallo 和 hxllo 等。
• KEYS h*llo 匹配 hllo 和 heeeeello 等。
• KEYS h[ae]llo 匹配 hello 和 hallo ，但不匹配 hillo 。

用来列出所有满足特定正则字符串规则的key，当redis数据量比较大时，性能比较差，要避免使用

SCAN cursor [MATCH pattern] [COUNT count]
scan 命令提供了三个参数，第一个是 cursor 整数值(hash桶的索引值)，第二个是 key 的正则模式，第三个是一次遍历的key的数量(参考值，底层遍历的数量不一定)，并不是符合条件的结果数量。第一次遍历时，cursor 值为 0，然后将返回结果中第一个整数值作为下一次遍历的 cursor。一直遍历到返回的 cursor 值为 0 时结束

注意：但是scan并非完美无瑕， 如果在scan的过程中如果有键的变化（增加、 删除、 修改） ，那么遍历效果可能会碰到如下问题： 新增的键可能没有遍历到， 遍历出了重复的键等情况， 也就是说scan并不能保证完整的遍历出来所有的键， 这些是我们在开发时需要考虑的

理解scan的cursor：我们的redis都是存的<key-value>的数据，不同的数据结构类型value不同而已。所以redis会有一个类似hash的桶，用来定位key的，当桶不够用的时候会触发rehash。所以这个cursor值的就是hash桶的索引值

分为 9 大块，每个块都有非常多的参数，这 9 个块分别是:

• Server 服务器运行的环境参数 
• Clients 客户端相关信息 
• Memory 服务器运行内存统计数据 
• Persistence 持久化信息 
• Stats 通用统计数据 
• Replication 主从复制相关信息 
• CPU CPU 使用情况 
• Cluster 集群信息 
• KeySpace 键值对统计数量信息（通过这个获取到key的数量）

//测试每秒能处理多少get命令
[root@redis01 redis-5.0.5]# src/redis-benchmark get
====== get ======
  100000 requests completed in 1.03 seconds//100000个请求在1.03秒内完成
  50 parallel clients
  3 bytes payload
  keep alive: 1

99.88% <= 1 milliseconds
100.00% <= 2 milliseconds
96993.21 requests per second

命令记不住那么多的，所以要学会查看帮助，只要知道有那个东西在就行
127.0.0.1:6379> help set
  SET key value [expiration EX seconds|PX milliseconds] [NX|XX]
  summary: Set the string value of a key
  since: 1.0.0
  group: string

bitMap使用

场景-日活跃用户

GeoHash是一种地理位置编码方法。 由Gustavo Niemeyer 和 G.M. Morton于2008年发明，它将地理位置编码为一串简短的字母和数字。它是一种分层的空间数据结构，将空间细分为网格形状的桶，这是所谓的z顺序曲线的众多应用之一，通常是空间填充曲线。底层通过跳表实现，跟redis zset一样

RDB快照策略配置与save、bgsave

bgsave的写时复制(COW)机制

save与bgsave对比

aof基本介绍

开启aof和策略配置

AOF重写

生产环境可以都启用，redis启动时如果既有rdb文件又有aof文件则优先选择aof文件恢复数据，因为aof一般来说数据更全一点

重启 Redis 时，我们很少使用 RDB来恢复内存状态，因为会丢失大量数据。我们通常使用 AOF 日志重放，但是重放 AOF 日志性能【写是没关系的，一样快】相对 RDB来说要慢很多，这样在 Redis 实例很大的情况下，启动需要花费很长的时间。 Redis 4.0 为了解决这个问题，带来了一个新的持久化选项——混合持久化

通过如下配置可以开启混合持久化(必须先开启aof，而aof默认是没有打开的)： aof-use-rdb-preamble yes   //默认是打开的

如果开启了混合持久化，AOF在重写时，不再是单纯将内存数据转换为RESP命令写入AOF文件，而是将重写这一刻之前的内存做RDB快照处理，并且将RDB快照内容和增量的AOF修改内存数据的命令存在一起，都写入新的AOF文件，新的文件一开始不叫appendonly.aof，等到重写完新的AOF文件才会进行改名，覆盖原有的AOF文件，完成新旧两个AOF文件的替换。 于是在 Redis 重启的时候，可以先加载 RDB 的内容，然后再重放增量 AOF 日志就可以完全替代之前的 AOF 全量文件重放，因此重启效率大幅得到提升

1. 写crontab定时调度脚本，每小时都copy一份rdb或aof的备份到一个目录中去，仅仅保留最近48小时的备份
2. 每天都保留一份当日的数据备份到一个目录中去，可以保留最近1个月的备份
3. 每次copy备份的时候，都把太旧的备份给删了
4. 每天晚上将当前机器上的备份复制一份到其他机器上，以防机器损坏

全量复制

数据部分复制

如果有很多从节点，为了缓解主从复制风暴(多个从节点同时复制主节点导致主节点压力过大)，可以做如下架构，让部分从节点与从节点(与主节点同步)同步数据
默认配置了从节点只读，所以从节点还是可以读的，只是不能写

sentinel/ˈsentɪnl/哨兵是特殊的redis服务，不提供读写服务，主要用来监控redis实例节点。

哨兵架构下client端第一次从哨兵找出redis的主节点，后续就直接访问redis的主节点，不会每次都通过sentinel代理访问redis的主节点，当redis的主节点发生变化，哨兵会第一时间感知到，并且将新的redis主节点通知给client端(这里面redis的client端一般都实现了订阅功能，订阅sentinel发布的节点变动消息)

当一个master服务器被某sentinel视为下线状态后，该sentinel会与其他sentinel协商选出sentinel的leader进行故障转移工作。每个发现master服务器进入下线的sentinel都可以要求其他sentinel选自己为sentinel的leader，选举是先到先得。同时每个sentinel每次选举都会自增配置纪元(选举周期)，每个纪元中只会选择一个sentinel的leader。如果所有超过一半的sentinel选举某sentinel作为leader。之后该sentinel进行故障转移操作，从存活的slave中选举出新的master，这个选举过程跟集群的master选举很类似。

哨兵集群只有一个哨兵节点，redis的主从也能正常运行以及选举master，如果master挂了，那唯一的那个哨兵节点就是哨兵leader了，可以正常选举新master。不过为了高可用一般都推荐至少部署三个哨兵节点。为什么推荐奇数个哨兵节点原理跟集群奇数个master节点类似

当原master的redis实例再次启动时，哨兵集群根据集群元数据信息就可以将原master的redis节点作为从节点加入集群

客户端可以一次性发送多个请求而不用等待服务器的响应，待所有命令都发送完后再一次性读取服务的响应，这样可以极大的降低多条命令执行的网络传输开销，管道执行多条命令的网络开销实际上只相当于一次命令执行的网络开销。需要注意到是用pipeline方式打包命令发送，redis必须在处理完所有命令前先缓存起所有命令的处理结果。打包的命令越多，缓存消耗内存也越多。所以并不是打包的命令越多好。

pipeline中发送的每个command都会被server立即执行，如果执行失败，将会在此后的响应中得到信息；也就是pipeline并不是表达“所有command都一起成功”的语义，管道中前面命令失败，后面命令不会有影响，继续执行，也就是不保证原子性

Redis在2.6推出了脚本功能，允许开发者使用Lua语言编写脚本传到Redis中执行。使用脚本的好处如下:

• 减少网络开销：本来5次网络请求的操作，可以用一个请求完成，原先5次请求的逻辑放在redis服务器上完成。使用脚本，减少了网络往返时延。这点跟管道类似。
• 原子操作：Redis会将整个脚本作为一个整体执行，中间不会被其他命令插入。管道不是原子的，不过redis的批量操作命令(类似mset)是原子的。
• 替代redis的事务功能：redis自带的事务功能很鸡肋，报错不支持回滚，而redis的lua脚本几乎实现了常规的事务功能，支持报错回滚操作，官方推荐如果要使用redis的事务功能可以用redis lua替代。

注意，不要在Lua脚本中出现死循环和耗时的运算，否则redis会阻塞，将不接受其他的命令， 所以使用时要注意不能出现死循环、耗时的运算。redis是单线程执行脚本。管道不会阻塞redis客户端继续发送命令（在服务端未响应时，客户端可以继续向服务端发送请求）

在redis3.0以前的版本要实现集群一般是借助哨兵sentinel工具来监控master节点的状态，如果master节点异常，则会做主从切换，将某一台slave作为master，哨兵的配置略微复杂，并且性能和高可用性等各方面表现一般，特别是在主从切换的瞬间存在访问瞬断的情况，而且哨兵模式只有一个主节点对外提供服务，没法支持很高的并发，且单个主节点内存也不宜设置得过大，否则会导致持久化文件过大，影响数据恢复或主从同步的效率

redis集群是一个由多个主从节点群组成的分布式服务器群，它具有复制、高可用和分片特性。Redis集群不需要sentinel哨兵·也能完成节点移除和故障转移的功能。需要将每个节点设置成集群模式，这种集群模式没有中心节点，可水平扩展，据官方文档称可以线性扩展到上万个节点(官方推荐不超过1000个节点)。redis集群的性能和高可用性均优于之前版本的哨兵模式，且集群配置非常简单

代理模式

直连模式

持久内存型NVM

Redis集群原理分析：
Redis Cluster 将所有数据划分为 16384（2的14次幂） 个 slots(槽位)，每个节点负责其中一部分槽位。槽位的信息存储于每个节点中。
当 Redis Cluster 的客户端来连接集群时，它也会得到一份集群的槽位配置信息并将其缓存在客户端本地。这样当客户端要查找某个 key 时，可以直接定位到目标节点。同时因为槽位的信息可能会存在客户端与服务器不一致的情况，还需要纠正机制来实现槽位信息的校验调整

槽位定位算法
Cluster 默认会对 key 值使用 crc16 算法进行 hash 得到一个整数值，然后用这个整数值对 16384 进行取模来得到具体槽位。
槽位定位是客户端完成的，比如Jedis它会实现，而服务端只是维护这种集群
HASH_SLOT = CRC16(key) mod 16384

当作水平扩展的时候需要为新增master分配hash slot（从所有主节点抽取），删除时同样需要将hash slot给到其他节点（只能全部归还给同一个主节点）

跳转重定位
当客户端向一个错误的节点发出了指令，该节点会发现指令的 key 所在的槽位并不归自己管理，这时它会向客户端发送一个特殊的跳转指令携带目标操作的节点地址，告诉客户端去连这个节点去获取数据。客户端收到指令后除了跳转到正确的节点上去操作，还会同步更新纠正本地的槽位映射表缓存，后续所有 key 将使用新的槽位映射表

所以说客户端跟服务器每一台集群节点都有维护这个槽位的分布情况，以上就是他们的纠正机制

Redis集群节点间的通信机制
redis cluster节点间采取gossip /ˈɡɑːsɪp/ 协议进行通信

维护集群的元数据(集群节点信息，主从角色，节点数量，各节点共享的数据等)有两种方式：集中式和gossip

集中式： 优点在于元数据的更新和读取，时效性非常好，一旦元数据出现变更立即就会更新到集中式的存储中，其他节点读取的时候立即就可以感知到；不足在于所有的元数据的更新压力全部集中在一个地方，可能导致元数据的存储压力。 很多中间件都会借助zookeeper集中式存储元数据

gossip：gossip协议包含多种消息，包括ping，pong，meet，fail等等。 

• meet：某个节点发送meet给新加入的节点，让新节点加入集群中，然后新节点就会开始与其他节点进行通信；
• ping：每个节点都会频繁给其他节点发送ping，其中包含自己的状态还有自己维护的集群元数据，互相通过ping交换元数据(类似自己感知到的集群节点增加和移除，hash slot信息等)； 
• pong: 对ping和meet消息的返回，包含自己的状态和其他信息，也可以用于信息广播和更新； 
• fail: 某个节点判断另一个节点fail之后，就发送fail给其他节点，通知其他节点，指定的节点宕机了

gossip协议的优点在于元数据的更新比较分散，不是集中在一个地方，更新请求会陆陆续续，打到所有节点上去更新，有一定的延时，降低了压力；缺点在于元数据更新有延时可能导致集群的一些操作会有一些滞后

gossip通信的10000端口：每个节点都有一个专门用于节点间gossip通信的端口，就是自己提供服务的端口号+10000，比如7001，那么用于节点间通信的就是17001端口。 每个节点每隔一段时间都会往另外几个节点发送ping消息，同时其他节点接收到ping消息之后返回pong消息

网络抖动造成脑裂问题

Redis集群选举原理分析

集群脑裂数据丢失问题

集群是否完整才能对外提供服务

Redis集群为什么至少需要三个master节点，并且推荐节点数为奇数？

Redis集群对批量操作命令的支持

redis字符串【sds】设计原理

不同版本redis字符串设计原理区别

redis数据库db（16个）

<k-v>DB数据结构dict

hash桶数据结构dictht

<key-value>数据结构dictEntry

value数据结构表示--redisObject

长整型使用int类型编码：（这里说的长整形理解成long别被这个int搞混了）上面说了这个*ptr就是我们的数据指针，但是也有可能就是我们的数据，为什么这么说呢？首先*ptr占用8个字节，而我们的长整型固定也是8个字节，那如果是整形数据是不是可以直接存储在*ptr中呢？当然是可以，redis也是这么做的，这么做的好处除了减少内存消耗还减少了内存寻址io（指针指向数据地址读取时需要寻址）

低于44字节使用embstr类型编码：在64位操作系统上，每次寻址都是读取一个缓存行，缓存行的大小为64byte（字节），然后我们看下redisObject 才占用16个字节（看上面redisObject代码），那缓存行后面的内存就使用不到了岂不是很浪费？还剩64byte-16byte=48byte，redis当然是需要利用起来的。是不是可以这样：前面16个字节存放RedisObject，然后后面48个字节就直接放我们的数据，这样cpu读取一个缓存行就直接读取到了数据，不用再次读取，同时也减少内存浪费。

关于为什么是44个字节解释：如果type为string类型的，48byte存放的话使用的是前面说的sdshdr8（sdshdr5是放不下的，sdshdr5能表示字节的长度范围为0-31【2^5-1】），然后我们看sdshdr8除了数据外还需占用4字节，那么真正存放数据的 buf[] 可用内存为44字节

高于44字节使用raw：高于的话这个*ptr只能是指向数据的指针了

List是一个有序(按加入的时序排序)的数据结构，Redis采用quicklist（双端链表） 和 ziplist 作为List的底层实现

ziplist(压缩列表)结构详解

List使用quicklist编码

Hash 数据结构底层实现为一个字典( dict ),也是Redis Db用来存储K-V的数据结构,当数据量比较小，且单个元素比较小时，底层用ziplist存储，数据大小和元素数量阈值，使用ziplist的时候其实是有序的
可以通过参数设置
以下都是redis默认设置：
hash-max-ziplist-entries  512    //  ziplist 元素个数超过 512 ，将改为hashtable编码
hash-max-ziplist-value    64      //  单个元素大小超过 64 byte时，将改为hashtable编码

使用ziplist编码

使用hashtable编码

Set 为无序的，自动去重的集合数据类型，Set 数据结构底层实现为一个value 为 null 的 字典( dict ),当数据可以用整形表示时，Set集合将被编码为intset数据结构。以下两个条件任意满足时
Set将用hashtable存储数据：

• 1， 元素个数大于 set-max-intset-entries , 
• 2 ， 元素无法用整形表示
  set-max-intset-entries 512       // intset 能存储的最大元素个数，超过则用hashtable编码
  

使用intset编码

使用hashtable存储

ZSet  为有序的，自动去重的集合数据类型，ZSet 数据结构底层实现为字典(dict) + 跳表(skiplist) ,当数据比较少且元素大小未达到阈值时，用ziplist编码结构存储

使用ziplist编码

使用字典(dict) + 跳表(skiplist)编码

redis 6.0 以前线程执行模式，如下操作在一个线程中执行完成：read（读取命令）-->parse解析命令-->command execute（执行命令）-->write（响应客户端）

可以通过如下参数配置多线程模型（默认都是不开启的）：如：
 io-threads 4  // 这里说 有三个IO 线程，还有一个线程是main线程，main线程负责IO读写和命令执行操作

默认情况下，如上配置，有三个IO线程， 这三个IO线程只会执行 IO中的write 操作，也就是说，read 和 命令执行 都由main线程执行。最后写回客户端才是多线程执行

如想多线程执行命令步骤需要开启如下配置，同样执行命令的操作还是只有main线程完成【多线程读命令、解析命令、写回结果，单线程执行命令】

开启如下参数将支持IO线程执行 读写任务：
io-threads-do-reads yes // 将支持IO线程执行 读写任务。

我们知道redis存在一个命令setnx key value ，若给定的 key 已经存在，则 SETNX 不做任何动作且返回0。因为redis是单线程的所以我们可以利用这点实现一个分布式锁：当设置成功时我才去执行业务代码，设置失败则不给执行，业务代码执行完后再删除锁即可
public String deduct_stock_redis() {
    String lock = "product:001";
    //尝试获取锁
    Boolean ifAbsent = stringRedisTemplate.opsForValue().setIfAbsent(lock, "lock");
    if (!ifAbsent) {
        return "服务器繁忙，请稍后再试！";
    }
    //----------执行业务
    //释放锁
    stringRedisTemplate.delete(lock);    
}

存在问题的：

• 1、如果说在执行业务代码出了异常的时候，那么这个锁永远得不到释放造成其他线程永远无法进入业务代码；解决办法：可以通过try起来，在finally中释放锁，这样就算出异常也会释放锁
• 2、如果在执行业务代码的时候宕机了呢（比如被运维关了），锁永远释放不了，就算try起来也没用？解决办法：加上过期时间，到了一定时间自动释放锁
• 3、如果在加锁后，加过期时间的时候宕机了呢？因为过期时间没有加上导致锁永远释放不了？解决办法：保证加锁与设置过期时间为原子操作，使用SET product:10001 true  ex  10  nx

public String deduct_stock_redis() {
    String lock = "product:001";
    //尝试获取锁，获取成功添加过期时间
    Boolean ifAbsent = stringRedisTemplate.opsForValue().setIfAbsent(lock, "lock",10, TimeUnit.SECONDS);
    if (!ifAbsent) {
        return "服务器繁忙，请稍后再试！";
    }
    try {
    //----------执行业务
    } finally {
        //释放锁
        stringRedisTemplate.delete(lock);
    }
}

锁被别的线程释放的问题分析：这里我们设置了锁过期时间为10s，比如存在这么一种情况：
1：T1线程拿到锁并且设置过期时间为10s，此时执行业务代码，但是由于某种原因，业务代码需要执行15s；
2：T1设置好锁的过期时间后，redis那边会在10s后释放锁，但是此时T1线程却还没有执行结束，而且因为锁到了过期时间被redis删除了，所以此时T2线程可以获取到锁了；
3：接着T1线程执行完，准备删除锁，但是这个锁却是T2线程加的，这样T1就把T2线程的锁给删除了。在高并发场景下导致锁跟没加一样，达不到我们想要的效果，这就是问题！！！

当然同时也存在业务执行时间大于锁过期时间导致的问题

解决办法：解决这个问题也简单，因为是删除了别的线程的锁，那我们可以每次在删除的时候判断下即可，如果是自己的锁就删除，否者不给删除。

通过UUID保证只能释放自己线程加的锁:
public String deduct_stock_redis() {
    String lock = "product:001";
    String clientId = UUID.randomUUID().toString();
    //尝试获取锁，获取成功添加过期时间
    Boolean ifAbsent = stringRedisTemplate.opsForValue().setIfAbsent(lock, clientId,10, TimeUnit.SECONDS);
    if (!ifAbsent) {
        return "服务器繁忙，请稍后再试！";
    }
    try {
    //----------执行业务
    } finally {
        //释放锁时判断是否为自己的锁
        if(clientId.equals(stringRedisTemplate.opsForValue().get(lock))){
            //释放锁
            stringRedisTemplate.delete(lock);
        }
    }
}

关于锁过期时间设置多少的权衡：其实这个过期时间设置多少都不好说，因为你也不知道你的业务代码会不会因为某种原因导致长时间没执行完，设置太长又不好，万一加锁的那台服务挂了不主动释放锁了（锁续命的时候不存在这个问题，当加锁的服务器挂了续命线程也挂了，自然会自动释放锁），其他线程就只能长时间等待redis锁过期时间到来。设置太短呢又会加大业务代码没执行完锁就过期的可能性，所以这个东西真的不好说

存在问题分析：比如上面设置锁过期时间为10s的情况，T1线程也确实是要执行15s的时候。到了10s的时候锁过期释放了，这时候T2线程获取锁且已经进来了。这其实就已经是存在问题了，因为没有保证同一时候只有一个线程在执行业务操作。比如T1在执行代码扣减库存前锁已过期且T2线程获取到锁，这个时候T2线程获取的库存跟T1线程获取的库存是一样的，也就导致了超卖

通过锁续命解决：我们可以在加锁后创建一个定时任务线程，每隔多久去查看下业务线程的锁是否还在，如果不在了就给锁续命。比如我设置锁过期时间为30s，然后在线程加锁后开启一个定时任务线程，每隔10s去检查下业务线程的锁是否还存在（线程没主动释放的情况下锁是不可能不存在的，因为会续命），如果存在则续命30s。这样就可以很好的解决锁自动释放但是业务尚未执行完的问题

//----------------------------------开启定时线程检查锁是否过期，如过期则续命一波  伪代码
//判断锁是否存在
if(距离上次检查时间是否达到10s && redis.get(lock) != null){
    //存在重新加锁也就是续命
    redis.setnx(lock, clientId,30, TimeUnit.SECONDS);
}else{
    //不存在的情况只有是锁是线程释放的情况，直接结束看门狗线程
}

看门狗这个代码如果自己去写的话很容易就出问题，所以不建议自己去写。可以使用Redisson

redisson说白了也是跟Jedis一样是一个redis客户端，而redisson更多的是提供一些分布式场景下的api，比如分布式锁、读写锁、布隆过滤器 https://redisson.org/

redisson原理分析

redisson存在的问题以及解决方案

缓存穿透问题

解决方案

缓存失效（击穿）问题

解决方案：设置随机过期时间解决

缓存雪崩问题

预防和解决缓存雪崩方案

热点缓存与缓存重建问题

使用互斥锁解决

在大并发下，同时操作数据库与缓存会存在数据不一致性问题，先来看看两种造成数据库与缓存不一致的情况

双写不一致问题

读写并发不一致问题

解决方案

key名设计

value设计

bigkey的危害

bigkey的产生

如何优化bigkey

1.【推荐】 O(N)命令关注N的数量 例如hgetall、lrange、smembers、zrange、sinter等并非不能使用，但是需要明确N的值。有遍历的需求可以使用hscan、sscan、zscan代替

2.【推荐】：禁用命令
禁止线上使用keys、flushall（清空整个 Redis 服务器的数据）、flushdb（清空当前数据库中的所有 key）等，通过redis的rename机制禁掉命令，或者使用scan的方式渐进式处理

3.【推荐】合理使用select
redis的多数据库较弱，使用数字进行区分，很多客户端支持较差，同时多业务用多数据库实际还是单线程处理，会有干扰

4.【推荐】使用批量操作提高效率
原生命令：例如mget、mset。
非原生命令：可以使用pipeline提高效率。
但要注意控制一次批量操作的元素个数(例如500以内，实际也和元素字节数有关)

5.【建议】Redis事务功能较弱，不建议过多使用，可以用lua替代

1.【推荐】使用多台redis实例
避免多个应用使用一个Redis实例
正例：不相干的业务拆分，公共数据做服务化

2.【推荐】使用带有连接池的数据库
使用带有连接池的数据库，可以有效控制连接，同时提高效率

3.【建议】客户端添加熔断降级
高并发下建议客户端添加熔断功能(例如sentinel、hystrix)

4.【推荐】设置合理的密码
设置合理的密码，如有必要可以使用SSL加密访问

5. 注意结合过期key淘汰策略考虑

连接池参数含义

优化建议

三种清除策略

注意：当Redis运行在主从模式时，只有主结点才会执行过期删除策略，然后把删除操作”del key”同步到从结点删除数据

Redis 的单线程主要是指 Redis 的网络 IO 和键值对读写是由一个线程来完成的，这也是 Redis 对外提供键值存储服务的主要流程。但 Redis 的其他功能，比如持久化、异步删除、集群数据同步等，其实是由额外的线程执行的

redis 6.0 以前线程执行模式，如下操作在一个线程中执行完成：read（读取命令）-->parse解析命令-->command execute（执行命令）-->write（响应客户端）

可以通过如下参数配置多线程模型（默认都是不开启的）：如：
 io-threads 4  // 这里说 有三个IO 线程，还有一个线程是main线程，main线程负责IO读写和命令执行操作

默认情况下，如上配置，有三个IO线程， 这三个IO线程只会执行 IO中的write 操作，也就是说，read 和 命令执行 都由main线程执行。最后写回客户端才是多线程执行

如想多线程执行命令步骤需要开启如下配置，同样执行命令的操作还是只有main线程完成【多线程读命令、解析命令、写回结果，单线程执行命令】

开启如下参数将支持IO线程执行 读写任务：
io-threads-do-reads yes // 将支持IO线程执行 读写任务。

a) 针对设置了过期时间的key做处理：

1. volatile-ttl：在筛选时，会针对设置了过期时间的键值对，根据过期时间的先后进行删除，越早过期的越先被删除。
2. volatile-random：就像它的名称一样，在设置了过期时间的键值对中，进行随机删除。
3. volatile-lru：会使用 LRU 算法筛选设置了过期时间的键值对删除。
4. volatile-lfu：会使用 LFU 算法筛选设置了过期时间的键值对删除

b) 针对所有的key做处理：

1. allkeys-random：从所有键值对中随机选择并删除数据。
2. allkeys-lru：使用 LRU 算法在所有数据中进行筛选删除。
3. allkeys-lfu：使用 LFU 算法在所有数据中进行筛选删除

c) 不处理：

1. noeviction：不会剔除任何数据，拒绝所有写入操作并返回客户端错误信息"(error) OOM command not allowed when used memory"，此时Redis只响应读操作

Redis 可以通过创建快照来获得存储在内存里面的数据在某个时间点上的副本。Redis 创建快照之后，可以对快照进行备份，可以将快照复制到其他服务器从而创建具有相同数据的服务器副本（Redis 主从结构，主要用来提高 Redis 性能），还可以将快照留在原地以便重启服务器的时候使用

快照持久化是 Redis 默认采用的持久化方式，在 Redis.conf 配置文件中默认有此下配置：

• save 900 1           #在900秒(15分钟)之后，如果至少有1个key发生变化，Redis就会自动触发BGSAVE命令创建快照。
• save 300 10          #在300秒(5分钟)之后，如果至少有10个key发生变化，Redis就会自动触发BGSAVE命令创建快照。
• save 60 10000        #在60秒(1分钟)之后，如果至少有10000个key发生变化，Redis就会自动触发BGSAVE命令创建快照。

将修改的每一条指令记录进文件appendonly.aof中(先写入os cache，每隔一段时间fsync到磁盘)

打开方式：默认是没有打开的，你可以通过修改配置文件来打开 AOF 功能：
appendonly yes

可以配置 Redis 多久才将数据 fsync 到磁盘一次。有三个选项：

• appendfsync always：每次有新命令追加到 AOF 文件时就执行一次 fsync ，非常慢，也非常安全。最多丢失一条命令
• appendfsync everysec：每秒 fsync 一次，足够快，并且在故障时只会丢失 1 秒钟的数据。当打开aof后默认为这个策略
• appendfsync no：从不 fsync ，将数据交给操作系统来处理。更快，也更不安全的选择

AOF 重写

每个子目录项都被称作为 znode(目录节点)，和文件系统类似，我们能够自由的增加、删除znode，在一个znode下增加、删除子znode

znode目录节点类型

客户端注册监听它关心的任意节点，或者目录节点及递归子目录节点 

• 1. 如果注册的是对某个节点的监听，则当这个节点被删除，或者被修改时，对应的客户端将被通知
• 2. 如果注册的是对某个目录的监听，则当这个目录有子节点被创建，或者有子节点被删除，对应的客户端将被通知
• 3. 如果注册的是对某个目录的递归子节点进行监听，则当这个目录下面的任意子节点有目录结构的变化（有子节点被创建，或被删除）或者根节点有数据变化时，对应的客户端将被通知。

注意：所有的通知都是一次性的，及无论是对节点还是对目录进行的监听，一旦触发，对应的监听即被移除。递归子节点，监听是对所有子节点的，所以，每个子节点下面的事件同样只会被触发一次。

ls [-s] [-w] [-R] path     -s 状态信息      -R 递归查看所有子节点      -w 添加一个 watch（监视器），如果该节点发生变化，watch 可以使客户端得到通知。watch 只能被触发一次。如果要一直获得 znode 的创建和删除的通知，     那么就需要不断的在znode上开启观察模式。如果在该 path 下节点发生变化，会产生 NodeChildrenChanged 事件，删除节点，会产生 NodeDeleted 事件。

create [-s] [-e] [-c] [-t ttl] path [data] [acl]
中括号为可选项，没有则默认创建持久化节点
    -s: 顺序节点
    -e: 临时节点
    -c: 容器节点
    -t:  可以给节点添加过期时间，默认禁用，需要通过系统参数启用

临时节点不能创建子节点，Zookeeper中临时节点生命周期是和SESSION绑定的

create -c 创建容器节点，如果Container节点下面以前有现在没有子节点（以前没有现在也没有是不会被清除的，表现跟持久化节点一样），则Container节点在未来会被Zookeeper自动清除,定时任务默认60s 检查一次

删除节点（不能存在子节点）
delete [-v version] path

删除所有节点（自己也会删除） 包括子节点
deleteall path

set [-s] [-v version] path data
    -s 除了设置节点值，还会多输出节点状态信息
    -v 修改的时候可以带上版本号，如果版本号跟当前数据版本不同则修改失败

通过set带上版本号实现乐观锁

get [-s] [-w] path
    -s 除了输出节点值，还会多输出节点状态信息
    -w 添加一个 watch（监视器），如果节点内容发生改变，会产生 NodeDataChanged 事件；如果删除节点，会产生 NodeDeleted 事件。

语法：与 get 的区别是，不会列出 znode 的值。
stat [-w] path
    -w 添加一个 watch（监视器），如果节点内容发生改变，会产生 NodeDataChanged 事件；如果删除节点，会产生 NodeDeleted 事件

Stat输出信息：

• cZxid：创建znode的事务ID（Zxid的值）。
• mZxid：最后修改znode的事务ID。
• pZxid：最后添加或删除子节点的事务ID（子节点列表发生变化才会发生改变）。
• ctime：znode创建时间。
• mtime：znode最近修改时间。
• dataVersion：znode的当前数据版本。
• cversion：znode的子节点结果集版本（一个节点的子节点增加、删除都会影响这个版本）。
• aclVersion：表示对此znode的acl版本。
• ephemeralOwner：znode是临时znode时，表示znode所有者的 session ID。 如果znode不是临时znode，则该字段设置为零。
• dataLength：znode数据字段的长度。
• numChildren：znode的子znode的数量

get  -w  /path   // 注册监听的同时获取数据 stat -w /path   // 对节点进行监听，且获取元数据信息

①：客户端A注册监听，get -w /test
②：客户端B修改数据，set /test data
③：客户端立马触发NodeDataChanged监听事件
④：如果再次修改并不会触发监听了，因为监听已经被删除了，这是一次性的

ls -w /path
//针对递归子目录的监听
ls -R -w /path ： -R 区分大小写，一定用大写

如下对/test （子节点node01、node02）节点进行递归监听，但是每个目录下的目录监听也是一次性的，如第一次在/test/node01 目录下创建节点时，触发监听事件，第二次则没有，同样，因为是递归的目录监听，所以在/test/node02下进行节点创建时，触发事件，但是再次创建时，没有触发事件。简单说就是循环给每个都设置了监听事件（一次性），当然/test字节本身也添加了监听

None 连接建立事件 NodeCreated 节点创建 NodeDeleted 节点删除 NodeDataChanged 节点数据变化 NodeChildrenChanged 子节点列表变化 DataWatchRemoved 节点监听被移除 ChildWatchRemoved 子节点监听被移除

Zookeeper 的ACL 权限控制,可以控制节点的读写操作,保证数据的安全性，Zookeeper ACL 权限设置分为 3 部分组成，分别是：权限模式（Scheme）、授权对象（ID）、权限信息（Permission）。最终组成一条例如“scheme:id:permission”格式的 ACL 请求信息

Scheme（权限模式）：用来设置 ZooKeeper 服务器进行权限验证的方式。ZooKeeper 的权限验证方式大体分为两种类型：
world：开放模式（默认值），其实这种授权模式对应于系统中的所有用户，本质上起不到任何作用。设置了 world 权限模式系统中的所有用户操作都可以不进行权限验证。

• ip:一种是范围验证。所谓的范围验证就是说 ZooKeeper 可以针对一个 IP 或者一段 IP 地址授予某种权限。比如我们可以让一个 IP 地址为“ip：192.168.0.110”的机器对服务器上的某个数据节点具有写入的权限。或者也可以通过“ip:192.168.0.1/24”给一段 IP 地址的机器赋权。
• 
  
• digest :另一种权限模式就是口令验证，也可以理解为用户名密码的方式。在 ZooKeeper 中这种验证方式是 Digest 认证，而 Digest 这种认证方式首先在客户端传送“username:password”这种形式的权限表示符后，ZooKeeper 服务端会对密码 部分使用 SHA-1 和 BASE64 算法进行加密，以保证安全性。还可以auth，用户密码认证模式，只有在会话中添加了认证才可以防问。digest与auth类似，区别在于auth用明文密码，而digest 用sha-1+base64加密后的密码。在实际使用中digest 更常见。
• 
  
• 还有一种Super权限模式,  Super可以认为是一种特殊的 Digest 认证。具有 Super 权限的客户端可以对 ZooKeeper 上的任意数据节点进行任意操作

授权对象（ID）：授权对象就是说我们要把权限赋予谁，而对应于 4 种不同的权限模式来说，如果我们选择采用 IP 方式，使用的授权对象可以是一个 IP 地址或 IP 地址段；而如果使用 Digest 或 Super 方式，则对应于一个用户名。如果是 World 模式，是授权系统中所有的用户

权限信息（Permission）：权限就是指我们可以在数据节点上执行的操作种类，如下所示：在 ZooKeeper 中已经定义好的权限有 5 种：

• 数据节点（c: create）创建权限，授予权限的对象可以在数据节点下创建子节点；
• 数据节点（w: wirte）更新权限，授予权限的对象可以更新该数据节点；
• 数据节点（r: read）读取权限，授予权限的对象可以读取该节点的内容以及子节点的列表信息；
• 数据节点（d: delete）删除权限，授予权限的对象可以删除该数据节点的子节点；
• 数据节点（a: admin）管理者权限，授予权限的对象可以对该数据节点体进行 ACL 权限设置

命令               使用方式                                              描述
getAcl       getAcl <path>                         获取某个节点的acl权限信息
setAcl        setAcl <path> <acl>               设置某个节点的acl权限信息
addauth    addauth <scheme> <auth>    输入认证授权信息，相当于注册用户信息，注册时输入明文密码，zk将以密文的形式存储

可以通过系统参数zookeeper.skipACL=yes进行配置，默认是no,可以配置为true, 则配置过的ACL将不再进行权限检测

节点创建的同时设置ACL
create [-s] [-e] [-c]   path [data] [acl]

或者用setAcl 设置
setAcl /zk-node  digest:libo:NEWhlz5DqG8dUwfzG9BaOrVjTVA=:cdrwa

针对每一次客户端的事务操作，Zookeeper都会将他们记录到事务日志中，当然，Zookeeper也会将数据变更应用到内存数据库中。我们可以在zookeeper的主配置文件zoo.cfg 中配置内存中的数据持久化目录，也就是事务日志的存储路径 dataLogDir. 如果没有配置dataLogDir（非必填）, 事务日志将存储到dataDir （必填项）目录

zookeeper提供了格式化工具可以进行数据查看事务日志数据

事务日志文件预分配：Zookeeper进行事务日志文件操作的时候会频繁进行磁盘IO操作，事务日志的不断追加写操作会触发底层磁盘IO为文件开辟新的磁盘块，即磁盘Seek。因此，为了提升磁盘IO的效率，Zookeeper在创建事务日志文件的时候就进行文件空间的预分配- 即在创建文件的时候，就向操作系统申请一块大一点的磁盘块。这个预分配的磁盘大小可以通过系统参数 zookeeper.preAllocSize 进行配置

事务日志文件名为： log.<当时最大事务ID>，应为日志文件时顺序写入的，所以这个最大事务ID也将是整个事务日志文件中，最小的事务ID，日志满了即进行下一次事务日志文件的创建

数据快照用于记录Zookeeper服务器上某一时刻的全量数据，并将其写入到指定的磁盘文件中

可以通过配置snapCount配置每间隔事务请求个数，生成快照，数据存储在dataDir 指定的目录中， 为了避免集群中所有机器在同一时间进行快照，实际的快照生成时机为事务数达到 [snapCount/2   + 随机数(随机数范围为1 ~ snapCount/2 )] 个数时开始快照

快照事务日志文件名为： snapshot.<当时最大事务ID>，日志满了即进行下一次事务日志文件的创建

有了事务日志，为啥还要快照数据？

实现原理

存在的问题-羊群效应

实现原理

个别情况说明与优化

临时节点不能创建子节点，也就不能在其下创建临时顺序节点。所以需要创建一个持久化节点（更好的是使用容器节点，当没有子节点后会在未来会自动删除），然后在其下面创建临时顺序节点

读写锁以及读写不一致情况

Zookeeper 共享锁实现原理

• 共享可重入锁：全局同步的完全分布式锁，这意味着在任何快照上，没有两个客户端会认为它们持有相同的锁。
• 共享锁：与共享可重入锁相似，但不可重入。
• 共享可重入读写锁：可跨JVM使用的可重入读/写互斥量。读写锁维护一对相关联的锁，一个用于只读操作，另一个用于写操作。只要没有写入器，读取锁就可以同时由多个读取器进程持有。写锁是排他的。
• 共享信号量：跨JVM工作的计数信号量。所有JVM中使用相同锁定路径的所有进程都将获得进程间有限的一组租约。此外，这种信号量大多是“公平的”-每个用户都将按照请求的顺序获得租约（从ZK的角度来看）。
• 多共享锁：一种将多个锁作为一个实体进行管理的容器。调用acquire（）时，将获取所有锁。如果失败，则释放所有获取的路径。同样，当调用release（）时，将释放所有锁（忽略故障）。

ZAB 协议的消息广播过程使用的是一个原子广播协议，类似一个 两阶段提交过程。对于客户端发送的写请求，全部由 Leader 接收，Leader 将请求封装成一个事务 Proposal，将其发送给所有 Follwer ，然后，根据所有 Follwer 的反馈，如果超过半数(含leader自己)成功响应，则执行 commit 操作

还有一些细节：

1. Leader 在收到客户端请求之后，会将这个请求封装成一个事务，并给这个事务分配一个全局递增的唯一 ID，称为事务ID（ZXID），ZAB 协议需要保证事务的顺序，因此必须将每一个事务按照 ZXID 进行先后排序然后处理，主要通过消息队列实现。
2. 在 Leader 和 Follwer 之间还有一个消息队列，用来解耦他们之间的耦合，解除同步阻塞。
3. zookeeper集群中为保证任何所有进程能够有序的顺序执行，只能是 Leader 服务器接受写请求，即使是 Follower 服务器接受到客户端的写请求，也会转发到 Leader 服务器进行处理，Follower只能处理读请求。
4. ZAB协议规定了如果一个事务在一台机器上被处理(commit)成功，那么应该在所有的机器上都被处理成功，哪怕机器出现故障崩溃。

刚刚我们说消息广播过程中，Leader 崩溃怎么办？还能保证数据一致吗？

实际上，当 Leader 崩溃，即进入我们开头所说的崩溃恢复模式（崩溃即：Leader 失去与过半 Follwer 的联系）。下面来详细讲述。
假设1：Leader 在复制数据给所有 Follwer 之后，还没来得及收到Follower的ack返回就崩溃，怎么办？
假设2：Leader 在收到 ack 并提交了自己，同时发送了部分 commit 出去之后崩溃怎么办？

针对这些问题，ZAB 定义了 2 个原则：

1. ZAB 协议确保丢弃那些只在 Leader 提出/复制，但没有提交的事务。
2. ZAB 协议确保那些已经在 Leader 提交的事务最终会被所有服务器提交。（因为leader提交的数据说明已经发送到follower去了）

所以，ZAB 设计了下面这样一个选举算法：
能够确保提交已经被 Leader 提交的事务，同时丢弃已经被跳过的事务。
针对这个要求，如果让 Leader 选举算法能够保证新选举出来的 Leader 服务器拥有集群中所有机器 ZXID 最大的事务，那么就能够保证这个新选举出来的 Leader 一定具有所有已经提交的提案。
而且这么做有一个好处是：可以省去 Leader 服务器检查事务的提交和丢弃工作的这一步操作。

服务刚启动的时候发送自投票后，会从recvqueue队列拿取远端发送过来的票据，如果远端为following或者leader，说明本机是新加入的节点

这种情况一般是已选出leader的集群，有新机器加入的时候，新机器处于Looking状态，会先给自己投票，其他机器收到后会回发已选出的leader票据过来，才来到这个逻辑。这个票据的发送方可能为FOLLOWING或LEADING

从recvQueue队列中处理远端票据，收到新加入服务的自投票据

如果本服务器不是looking选举状态，但是远端服务器是looking选举状态，这种情况为收到新加入节点的自投票据，则将本机器认为的leader发给远端服务器，leader已经有了，我直接告诉你就行了，你不用再选了if(ackstate == QuorumPeer.ServerState.LOOKING)

场景:首先，我们迎来了订单的高峰期，在mq的broker上堆积了成千上万条消息没有处理，这个时候，我们随便打开了消费者，就会出现下面请如此多的消息瞬间推送给消费者，我们的消费者不能处理这么多消息 就会导致消费者出现巨大压力，甚至服务器崩溃

我觉得消息队列只要自己控制消费者的ack+限制消费者线程其实就算是流控了，因为我处理完一条消息才会处理第二条，但是会一直占着资源

Rebalance的时候会停止所有kafka服务，因为当前版本的Kafka触发Rebalance时候会重新分配所有的Consumer对应的分区，并不是像一致性哈希（一致性Hash算法对于节点的增减都只需重定位环空间中的一小部分数据，具有较好的容错性和可扩展性。）那样尽量保证其他节点不影响。所以要尽量避免发生Rebalance的发生

第一阶段：选择组协调器
组协调器GroupCoordinator：每个consumer group都会选择一个broker作为自己的组协调器coordinator，负责监控这个消费组里的所有消费者的心跳，以及判断是否宕机，然后开启消费者rebalance。
consumer group中的每个consumer启动时会向kafka集群中的某个节点发送 FindCoordinatorRequest 请求来查找对应的组协调器GroupCoordinator，并跟其建立网络连接。

组协调器选择方式：通过如下公式可以选出__consumer_offsets的哪个分区（比如分区10），这个分区leader对应的broker就是这个consumer group的coordinator
公式：hash(consumer group id) % __consumer_offsets主题的分区数

第二阶段：加入消费组JOIN GROUP
所有消费者会向 GroupCoordinator 发送 JoinGroupRequest 请求。GroupCoordinator 从中选择一个consumer担任group的leader消费组协调器（第一个加入group的consumer作为leader），GroupCoordinator 把consumer group所有成员信息以及他们的订阅信息发送给这个leader，接着这个leader会负责制定分区方案。

第三阶段：同步更新分配方案（ SYNC GROUP)
consumer leader会把这个分配方案封装进SyncGroupRequest请求并发送给GroupCoordinator，组内所有成员都会发送SyncGroup请求，接着GroupCoordinator就把属于每个consumer的分区方案作为SyncGroupRequest请求的response返还给consumer，他们会根据指定分区的leader broker进行网络连接以及消息消费。

主要有三种rebalance的策略：range、round-robin、sticky
Kafka 提供了消费者客户端参数partition.assignment.strategy 来设置消费者与订阅主题之间的分区分配策略。默认情况为range分配策略。

range策略：就是算出平均分配多少，直接一次性分配，多余的平均分配给前面的消费者。比如有10个分区(0-9)，3个消费者：分区0~3给一个consumer，分区4~6给一个consumer，分区7~9给一个consumer

round-robin策略：就是轮询分配，比如分区0、3、6、9给一个consumer，分区1、4、7给一个consumer，分区2、5、8给一个consumer

sticky策略：就是在rebalance的时候，需要保证如下两个原则。
1）分区的分配要尽可能均匀 。
2）分区的分配尽可能与上次分配的保持相同。
当两者发生冲突时，第一个目标优先于第二个目标 。这样可以最大程度维持原来的分区分配的策略。
比如对于第一种range情况的分配，如果第三个consumer挂了，那么重新用sticky策略分配的结果如下：
consumer1除了原有的0~3，会再分配一个7
consumer2除了原有的4~6，会再分配8和9

HW俗称高水位，HighWatermark的缩写，取一个partition对应的ISR中最小的LEO(log-end-offset)作为HW，consumer最多只能消费到该HW所在的位置。另外每个replica都有HW,leader和follower各自负责更新自己的HW的状态。对于leader新写入的消息，consumer不能立刻消费，leader会等待该消息被所有ISR中的replicas同步后更新HW，此时消息才能被consumer消费。这样就保证了如果leader所在的broker失效，该消息仍然可以从新选举的leader中获取。对于来自内部broker的读取请求，没有HW的限制

leader HW：更新时会比较所有满足条件的副本的LEO，包括自己的LEO和remote LEO，选取最小值作为更新后的leader HW
follower HW：更新发生在follower副本更新LEO之后，一旦follower向log写完数据，它就会尝试更新HW值。比较自己的LEO值与fetch响应中leader副本的HW值，取最小者作为follower副本的HW值。可以看出，如果follower的LEO值超过了leader的HW值，那么follower HW值是不会超过leader HW值的

图详细的说明了当producer生产消息至broker后，ISR以及HW和LEO的流转过程：

由此可见，Kafka的复制机制既不是完全的同步复制，也不是单纯的异步复制。事实上，同步复制要求所有能工作的follower都复制完，这条消息才会被commit，这种复制方式极大的影响了吞吐率。而异步复制方式下，follower异步的从leader复制数据，数据只要被leader写入log就被认为已经commit，这种情况下如果follower都还没有复制完，落后于leader时，突然leader宕机，则会丢失数据。而Kafka的这种使用ISR的方式则很好的均衡了确保数据不丢失以及吞吐率

（1）acks=0： 表示producer不需要等待任何broker确认收到消息的回复，就可以继续发送下一条消息。性能最高，但是最容易丢消息。大数据统计报表场景，对性能要求很高，对数据丢失不敏感的情况可以用这种。 （2）acks=1： 至少要等待leader已经成功将数据写入本地log，但是不需要等待所有follower是否成功写入。就可以继续发送下一条消息。这种情况下，如果follower没有成功备份数据，而此时leader又挂掉，则消息会丢失。 （3）acks=-1或all： 这意味着leader需要等待所有备份(min.insync.replicas配置的备份个数)都成功写入日志，这种策略会保证只要有一个备份存活就不会丢失数据。这是最强的数据保证。一般除非是金融级别，或跟钱打交道的场景才会使用这种配置。当然如果min.insync.replicas配置的是1则也可能丢消息，跟acks=1情况类似

如果消费这边配置的是自动提交，万一消费到数据还没处理完，就自动提交offset了，但是此时你consumer直接宕机了，未处理完的数据丢失了，下次也消费不到了

Nacos 数据模型 Key 由三元组唯一确定, Namespace默认是空串，公共命名空间（public），分组默认是 DEFAULT_GROUP。NameSpace、group可以进行资源隔离，比如我们dev环境下的NameSpace下的服务是调用不到prod的NameSpace下的微服务)

比如我们可以这样划分数据领域：可以划分dev与prod的NameSpace；交易之类的放在一个group中，仓储的放在另一个group中；订单服务跟支付服务集群，分为北京、南京两城市的集群，Nacos如果要做到同城优先调用，也就是北京的订单服务优先调用北京的支付服务，需要我们自己去写负载均衡算法，比如Ribbon的自定义负载
集群配置案例：spring.cloud.nacos.discovery.cluster-name=NJ

不同的NameSpace不能相互调用

不同的group不能相互调用

每一个环境一份配置，不能动态更改配置

将配置统一放在nacos上

支持动态修改

同一个微服务的通用配置

不同微服务的通用配置

精准配置 > 不同环境的通用配置 > 不同工程的(ext-config) > 不同工程(shared-  dataids)

服务注册：Nacos Client会通过发送REST请求的方式向Nacos Server注册自己的服务，提供自身的元数据，比如ip地址、端口等信息。Nacos Server接收到注册请求后，就会把这些元数据信息存储在一个双层的内存Map中。 
服务心跳：在服务注册后，Nacos Client会维护一个定时心跳来持续通知Nacos Server，说明服务一直处于可用状态，防止被剔除。默认5s发送一次心跳。
服务健康检查：Nacos Server会开启一个定时任务用来检查注册服务实例的健康情况，对于超过15s没有收到客户端心跳的实例会将它的healthy属性置为false(客户端服务发现时不会发现)，如果某个实例超过30秒没有收到心跳，直接剔除该实例(被剔除的实例如果恢复发送心跳则会重新注册)
服务发现：服务消费者（Nacos Client）在调用服务提供者的服务时，会发送一个REST请求给Nacos Server，获取上面注册的服务清单，并且缓存在Nacos Client本地，同时会在Nacos Client本地开启一个定时任务定时拉取服务端最新的注册表信息更新到本地缓存
服务同步：Nacos Server集群之间会互相同步服务实例，用来保证服务信息的一致性

Map<namespace, Map<group::serviceName, Service>>

可以通过注入DiscoveryClient，去注册中心拿到server地址，然后自定义RestTemplate重写方法，根据自己的负载算法得到ip

经过阅读源码RestTemplate组件得知，不管是post,get请求最终是会调用我们的doExecute()方法，而且在通过调试时可知此时的URL已经是选择完后的具体url，所以我们写一个自定义的MyRestTemplate类继承RestTemplate，然后重新doExucute()方法，重写的时候根据算法改掉URL即可，接着使用我们的自定义的MyRestTemplate进行服务间的调用即可。

通过服务消费者配置一个用于负载的restTemplate，在其上加上@LoadBalanced，声明此restTemplate用来负载均衡的

然后使用restTemplate进行服务之间的调用（指明服务名+请求地址即可），需要配置一个@LoadBalanced声明的RestTemplate不然不行，Eureka注册中心可以应该是他有实现负载。使用了全局的负载策略-随机，不设置默认轮训

需求介绍：order-a使用轮训负载，order-b使用随机负载 具体实现代码：针对不同的服务使用不同的负载配置类

基于上面场景的配置：
#自定义Ribbon的细粒度配置
order-a:
  ribbon:
    NFLoadBalancerRuleClassName: com.netflix.loadbalancer.RoundRobinRule
order-b:
  ribbon:
    NFLoadBalancerRuleClassName: com.netflix.loadbalancer.RandomRule

ribbon没有基于权重的算法，但是nacos中可以设置，所以我们可以获取到nacos设置的权重 然后进行权重算法

第一步:获取当前服务所在的集群
第二步:获取一个负载均衡对象
第三步:获取当前调用的微服务的名称
第四步:获取nacos clinet的服务注册发现组件的api
第五步:获取所有的服务实例
第六步:过滤筛选同集群下的所有实例
第七步:选择合适的一个实例调用

比如 order-center 存在二个版本 V1(老版本)  V2（新版本）,product-center也存在二个版本V1(老版本)  V2新版本 现在需要做到的是order-center(V1)---->product-center（v1），order-center(V2)---->product-center（v2）。记住v2版本是小面积部署的，用来测试用户对新版本功能的。若用户完全接受了v2。我们就可以把V1版本卸载完全部署V2版本。
实现场景说明：同版本能调用，不同版本不能调用

实现方法：同一个集群,同版本号 优先调用策略，可以通过配置一个版本号参数，然后获取比较

默认情况下，Feign的调用式不打印日志，我们需要通过自定义来打印我们的Feign的日志（basic适用于生产环境）

• NONE，无记录（DEFAULT）
• BASIC，只记录请求方法和 URL 以及响应状态代码和执行时间
• HEADERS，记录基本信息以及请求和响应标头
• FULL，记录请求和响应的头文件，正文和元数据

开启feign日志实现

feign.httpclient.max‐connections=200 #最大连接数 feign.httpclient.max‐connections‐per‐route: 50 #为每个url请求设置最大连接数 feign.httpclient.enabled: true #让feign底层使用HttpClient去调用

Http是膜前比较通用的网络请求方式，用来访问请求交换数据，有效的使用Http可以使应用访问速度变得更快，更节省带宽。OKhttp是一个很棒的Http客户端，具有以下功能和特性：

• 支持SPDY，可以合并多个到同一个主机的请求；
• 使用连接池技术减少请求的延迟（如果SPDY是可用的话）；
• 使用GZIP压缩减少传输的数据量；
• 缓存响应避免重复的网络请求

①：正常情况下，微服务A B  C  D 都是正常的
②：随着时间推移，在某一个时间点 微服务A突然挂了，此时的微服务B 还在疯狂的调用微服务A，由于A已经挂了，所以B调用A必须等待服务调用超时。而我们知道每次B->A的时候B都会去创建线程（而线程由是计算机的资源 比如cpu  内存等）。由于是高并发场景 B就会阻塞大量的线程。那么B所在的机器就会去创建线程，但是计算机资源是有限的，最后B的服务器就会宕机
③：由于微服务A这个猪队友活生生的把微服务B给拖死，导致微服务B也宕机了，然后也会导致微服务C D 出现类似的情况，最终我们的猪队友A成功的把微服务 B C  D 都拖死了。这种情况也叫做服务雪崩。也有一个专业术语( cascading failures ) 级联故障

超时：超时机制不难，也就是配置一下超时时间，例如1秒——每次请求在1秒内必须返回，否则到点就把线程掐死，释放资源！
思路：一旦超时，就释放资源。由于释放资源速度较快，应用就不会那么容易被拖死，自然就不会造成上游服务死亡，当然如果这样的话就需要在每个服务都设置超时机制

实时监测应用，如果发现在一定时间内失败次数/失败率达到一定阈值，就“跳闸”，断路器打开——此时，请求直接返回，而不去调用原本调用的逻辑。跳闸一段时间后（例如15秒），断路器会进入半开状态，这是一个瞬间态，此时允许一次请求调用该调的逻辑，如果成功，则断路器关闭，应用正常调用；如果调用依然不成功，断路器继续回到打开状态，过段时间再进入半开状态尝试——通过”跳闸“，应用可以保护自己，而且避免浪费资源；而通过半开的设计，可实现应用的“自我修复“。hystrix存在断路器半开，而sentinel没有半开

sentinel整合feign

sentinel整合ribbon

①：解析 SQL：得到 SQL 的类型（UPDATE），表（product），条件（where name = 'TXC';）等相关的信息。
②：查询前镜像：根据解析得到的条件信息，生成查询语句，定位数据。
select id, name, since from product where name = 'TXC';
③：执行业务 SQL：更新这条记录的 name 为 'GTS'。
update product set name = 'GTS' where name = 'TXC';
④：查询后镜像：根据前镜像的结果，通过 主键 定位数据（通过id获取，因为name都变了）
select id, name, since from product where id = 1`;
⑤：插入回滚日志：把前后镜像数据以及业务 SQL 相关的信息组成一条回滚日志记录，插入到 UNDO_LOG 表中。
⑥：提交前，向 TC 注册分支：申请 product 表中，主键值等于 1 的记录的 全局锁 。
⑦：本地事务提交：业务数据的更新和前面步骤中生成的 UNDO LOG 一并提交。
⑧：将本地事务提交的结果上报给 TC。

①：收到 TC 的分支提交请求，把请求放入一个异步任务的队列中，马上返回提交成功的结果给 TC。
②：异步任务将异步批量地删除相应 UNDO LOG 记录。

收到 TC 的分支回滚请求，开启一个本地事务，执行如下操作 ①：通过 XID 和 Branch ID 查找到相应的 UNDO LOG 记录； ②：数据校验：拿 UNDO LOG 中的后镜与当前数据进行比较，如果有不同，说明数据被当前全局事务之外的动作做了修改； ③：根据 UNDO LOG 中的前镜像和业务 SQL 的相关信息生成并执行回滚的语句； ④：提交本地事务。并把本地事务的执行结果（即分支事务回滚的结果）上报给 TC

• 路由网关的基本构建模块，它是由ID、目标URl、断言集合和过滤器集合定义，如果集合断言为真，则匹配路由。
• Predicate(断言)：这是java 8的一个函数式接口predicate,可以用于lambda表达式和方法引用，输入类型是：Spring Framework ServerWebExchange,允许开发人员匹配来自HTTP请求的任何内容，例如请求头headers和参数paramers
• Filter(过滤器)：这些是使用特定工厂构建的Spring Framework GatewayFilter实例，这里可以在发送下游请求之前或之后修改请求和响应

-Path配置路由

After路由断言工厂

Before路由断言工厂

Between路由断言工厂

Cookie路由断言工厂

Header路由断言工厂

Host路由断言工厂

RemoteAddr路由断言工厂

Method路由断言工厂

Query路由断言工厂

自定义谓词工厂（路由断言工厂）

SpringCloudGateway 内置了很多的过滤器工厂，当然可以自己根据场景自定义Filter。路由过滤器允许以某种方式修改请求进来的http请求或返回的http响应。路由过滤器主要作用于需要处理的特定路由。gateway提供了很多种类的过滤器工厂，过滤器的实现类将近二十多个。总的来说，可以分为七类：Header、Parameter、Path、Status、Redirect跳转、Hystrix熔断和RateLimiter。

方案：系统中某些页面只有在正常登录后才可以使用，用户请求这些页面时要检查session中有无该用户信息，我们可以编写一个用于检测用户是否登录的过滤器，如果用户未登录，则重定向到指定的登录页面

IP绑定 ip_hash。每个请求按访问ip的hash结果分配，这样每个访客固定访问一个后端服务器，可以解决session的问题

缺点：不能充分考虑到各个服务器的性能，不能均衡负载出去，有可能同一时刻的访问通过ip_hash出来都请求到一台服务器上，而且这台服务器的性能不行？？？

这种方案关键就是，将token保存在cookie中，用户每次请求都带上这个cookie，然后服务器判断这个cookie中的token是否有效即可。上面那种是把session保存在了服务器中

OAuth（开放授权）是一个开放标准，允许用户(你)授权第三方应用(王者农药)访问用户存储在另外的服务提供者(QQ服务器)上的信息，而不需要将用户名和密码提供给第三方移动应用(王者农药)­­­­­这个就是典型的授权码模式

密码模式：适用的业务场景 客户端应用(手机app) 是高度受信用的，一般是自己公司开发的app项目。

授权码模式(最安全的模式)  业务场景   第三方不授信的，搭建自己的开发能力平台。

简化模式(开发中几乎接触不到 适用于 客户端就是一堆js  css html 没有前端服务器)

客户端模式(开发中几乎用不到,这种模式 用户都没有参与过程)

问题分析

Spring Core Container
模块作用: Core 和 Beans 模块是框架的基础部分，提供 IOC（控制反转）和依赖注入（DI）特性。 这里的基础 概念是 BeanFactory，它提供对 Factory 模式的经典实现来消除对程序’性单例模式的需要，并真 正地允许你从程序逻辑中分离出依赖关系和配置

Spring Data Access/Integration

Spring Web Web 模块：提供了基础的面向 Web 的集成特性c 例如，多文件上传、使用 servlet listeners 初始化IoC 容器以及一个面向 Web 的应用上下文。 它还包含 Spring 远程支持中 Web 的相关部分。

Spring Aop
Aspects 模块提供了对 AspectJ 的集成支持。
Instrumentation 模块提供了 class instrumentation 支持和 classloader 实现，使得可以在特定的应用服务器上使用

Test Test 模块支持使用 JUnit 和 TestNG 对 Spring 组件进行测试

什么是控制反转?

依赖注入

①:在不指定@Scope的情况下，所有的bean都是单实例的bean,而且是饿汉加载(容器启动实例就创建好了)

②:指定@Scope为 prototype 表示为多实例的，而且还是懒汉模式加载（IOC容器启动的时候，并不会创建对象，而是在第一次使用的时候才会创建）

③:@Scope指定的作用域方法取值   b) prototype 多实例的   c) request  同一次请求   d) session  同一个会话级别

①:通过@CompentScan +@Controller @Service @Repository/rɪˈpɑːzətɔːri/ @compent。适用场景: 针对我们自己写的组件可以通过该方式来进行加载到容器中。
②:通过@Bean的方式来导入组件(适用于导入第三方组件的类)

③:通过@Import来导入组件 （导入组件的id为全类名路径）

④:通过实现FacotryBean接口来实现注册组件

①:什么是bean的生命周期?

②:通过  InitializingBean和DisposableBean 的二个接口实现bean的初始化以及销毁方法

③:通过JSR250规范 提供的注解@PostConstruct 和@ProDestory标注的方法

④:通过Spring的BeanPostProcessor的  bean的后置处理器会拦截所有bean创建过程

@AutoWired的使用

@Resource(JSR250规范)

@InJect（JSR330规范）

• @Profile标识在类上，那么只有当前环境匹配，整个配置类才会生效
• @Profile标识在Bean上 ，那么只有当前环境的Bean才会被激活
• 没有标志为@Profile的bean 不管在什么环境都可以被激活

激活切换环境的方法

• 方法一:通过运行时jvm参数来切换  -Dspring.profiles.active=test|dev|prod
• 方法二:通过代码的方式来激活ctx.getEnvironment().setActiveProfiles("test","dev");

BeanFactory是spring的顶层核心接口，用作于bean生命周期的管理，使用了简单工厂模式，负责生产bean

beanfactory顾名思义，它的核心概念就是bean工厂，用作于bean生命周期的管理，而applicationcontext这个概念就比较丰富了，单看名字（应用上下文）就能看出它包含的范围更广，它继承自bean factory但不仅仅是继承自这一个接口，还有继承了其他的接口，所以它不仅仅有bean factory相关概念，更是一个应用系统的上下文，其设计初衷应该是一个包罗万象的对外暴露的一个综合的API。applicationcontext有很多的扩展接口，通过源码看的话它有创建好几个开创者对象（比如后置处理器）（一开始出来的对象保证后面的一系列工作），比如AnnotationConfigApplicationContext加载配置文件，触发类路径扫描，以编程方式注册bean定义和带注解的类，以及（从5.0开始）注册功能bean定义

首先会通过BeanDefinitionReader读取我们的配置（xml、配置类、注解配置），然后通过BeanDefinitionScanner扫描出哪些类需要创建bean，知道了哪些类需要创建bean后，就可以包装成BeanDefinition定义了，接着BeanDefinitionRegistry就会把这些BeanDefinition放入一个beanDefinitionMap中去供BeanFactory使用，此外还有两个后置处理器，Bean工厂后置处理器提供我们在getBean前修改bean定义的能力，以及提供bean定义注册器后置处理器可以去添加图纸（mybatis的Mapper就是通过这个添加的动态代理）。BeanFactory会通过这些个BeanDefinition开始创建我们的bean。创建bean的时候也会调用很多的后置处理器（9次调用），还有在初始化的时候会回调很多的Aware（Aware的作用就是当我们需要用到spring容器中的属性时就可以通过实现Aware接口来获取）

在创建bean的时候分为实例化、填充属性、初始化（会调回调很多的Aware，Aware的作用就是当我们需要用到spring容器中的属性时就可以通过实现Aware接口来获取），最后就是放入到一级缓存中，也是个Map，当然在这个bean创建时也会调用很多的后置处理器：总共有9次调用，在每个阶段的前后都有调用，比如BeanPostProcessor.postProcessAfterInitialization()，这就也是我们AOP创建代理的地方

首先把这些扩展接口按照getBean前跟getBean中划分。

getBean前：主要有BeanFactoryPostProcessor（Bean工厂后置处理器）、BeanDefinitionRegistryPostProcessor（bean定义注册器后置处理器 ）Bean工厂后置处理器提供我们在getBean前修改bean定义的能力，bean定义注册器后置处理器可以去添加图纸（mybatis的Mapper就是通过这个添加的动态代理）。spring很多地方都是依赖这些扩展接口做的，比如在applicationContext创建好几个开创者的实例（加载配置实例、扫描实例、bean定义注册器等），而且在一开始会存在一个ConfigurationClassPostProcessor（继承Bean工厂后置处理器也继承bean定义注册器后置处理器）会解析加了@Configuration的配置类，还会解析@ComponentScan、@ComponentScans注解扫描的包，以及解析@Import等注解。

getBean中：主要是在bean的生命周期中的后置处理器跟Aware（感知到...）。后置处理器在bean的各个阶段前中后基本都有调用，总共调用9次，比如实例化前InstantiationAwareBeanPostProcessor，在这里我们可以直接返回bean，而不走后面的阶段了。这些后置处理器可以帮我们做很多事情，而且spring中也是很多地方用到了：解决循环引用AOP（实例化后、赋值前）、初始化后AOP:创建代理（初始时）等等。除了后置处理器还有回调很多的Aware，这些Aware的作用就是当我们需要用到spring容器中的属性时就可以通过实现Aware接口来获取，比如我们要拿到beanName可以实现BeanNameAware，想拿到ApplicationContext上下文可以实现ApplicationContextAware等等。

如果配置类中加了@Configuration，会创建动态代理，也就是每次会从ioc容器中拿Tank，而不是new
如果配置类中没有加@Configuration，每次都会调用createTank()，也就每次都会new一个Tank对象

如果是两个都是用的@Component的话，会报异常，如果是一个@Component一个@Bean的话，@Bean的会覆盖@Component的（@Bean是后面解析的，@Component是通过@ComponentScan注解扫描第一个解析的）

• BeanDefinitionRegistryPostProcessor执行：context手动添加的》》PriorityOrdered级别》》Ordered级别》》没有实现任何优先级接口
• BeanFactoryPostProcessor执行：同时实现了BeanDefinitionRegistryPostProcessor的》》PriorityOrdered级别》》Ordered级别》》没有实现任何优先级接口

• BeanDefinitionRegistryPostProcessor的执行是每次执行完都会清理掉已经执行过的，然后再重新从Map<BeanDefinition>中获取，这样保证了当我们开元者ConfigurationClassPostProcessor在进行扫描后，后面可以执行到我们写的BeanDefinitionRegistryPostProcessor
• BeanFactoryPostProcessor的执行而是只从Map<BeanDefinition>拿取一次，然后根据执行优先级放到不同List中，在依次循环执行

所谓的循环依赖是指，A 依赖 B，B 又依赖 A，它们之间形成了循环依赖。或者是 A 依赖 B，B 依赖 C，C 又依赖 A。

此时是存在循环依赖问题的，我在给A设置B属性时会去调用getBean(B)，然后B那里又会去getBean(A)，所以造成一个死循环调用

在getBean的时候判断一级缓存中是否存在，如果存在则直接返回。把添加bean到一级缓存从原来初始化后添加改为实例化添加

可以看到解是解决了循环依赖的问题，但是其实还是存在问题的

存在的问题

在实例化阶段把bean放到二级缓存中，初始化后放入一级缓存中，在getBean的时候先从一级缓存中拿，如果一级缓存不存在再从二级缓存拿。尽管二级缓存放入的是纯净bean，依旧是不影响的，比如getA-->getB-->getA，B拿到A的纯净bean返回，接着A会初始化完，因为使用的是同一个对象引用，所以当我getA结束后，B.A自然也是成熟状态Bean了（这里其实也会拿到脏数据的，在spring中是通过两把锁跟二级缓存保证的每次都是成熟bean）

循环依赖中存在动态代理问题

1.populateBean 调用 BeanFactroy.getBean("beanA") 以获取 beanB 的依赖。
2.getBean("beanB") 会先调用 getSingleton("beanA")，尝试从缓存中获取 beanA。此时由于 beanA 还没完全实例化好
3.于是 this.singletonObjects.get("beanA") 返回 null。
4.接着 this.earlySingletonObjects.get("beanA") 也返回空，因为 beanA 早期引用还没放入到这个缓存中。
5.最后调用 singletonFactory.getObject() 返回 singletonObject，此时 singletonObject != null。singletonObject 指向 BeanA@1234，也就是 createBeanInstance 创建的原始对象。此时 beanB 获取到了这个原始对象的引用，beanB 就能顺利完成实例化。beanB 完成实例化后，beanA 就能获取到 beanB 所指向的实例，beanA 随之也完成了实例化工作。由于 beanB.beanA 和 beanA 指向的是同一个对象 BeanA@1234，所以 beanB 中的 beanA 此时也处于可用状态了

当我们getBean的时候，首先会去一级缓存中找，找不到再调用createBean逻辑。在createBean中会将beanName添加到正在创建的集合列表中（表示这个bean正在创建），接着会在三级缓存singletonFactories中放入一个接口函数。当循环依赖B去getA的时候，getSingleton首先会判断一级缓存是否存在，不存在则到二级缓存中找，找不到再到三级缓存中找，因为前面不管怎么样都将早期对象包装成ObjectFactory（接口函数）放入到了三级缓存中，自然能拿到，也表示此时为循环依赖情况，接着调用ObjectFactory的getObject方法（就是那个接口函数），接口函数会传入我们早期bean，函数里面判断是否需要aop，需要则返回代理对象，不需要则直接原封不动返回传入的早期bean（调用createBean会调用bean的后置处理器，如果我们有aop的话就会创建代理对象返回，如果没有直接返回），最后将这个接口函数返回的对象放入到二级缓存中（这也表示只有在循环依赖的时候才会用到二级缓存），那放入二级缓存有啥用，我不放也不影响逻辑啊？确实不影响，只是这样就可以避免多次调用三级缓存的调用

通过三级缓存解决，首先，Spring内部维护了三个Map，也就是我们通常说的三级缓存。 singletonObjects 它是我们最熟悉的朋友，俗称“单例池”“容器”，缓存创建完成单例Bean的地方。 singletonFactories 映射创建Bean的原始工厂 earlySingletonObjects 映射Bean的早期引用，也就是说在这个Map里的Bean不是完整的，甚至还不能称之为“Bean”，只是一个Instance.

为什么需要二级缓存？

为什么需要三级缓存？

从流程图应该不难看出来，在Bean调用构造器实例化之前，一二三级缓存并没有Bean的任何相关信息，在实例化之后才放入三级缓存中，因此当getBean的时候缓存并没有命中，这样就抛出了循环依赖的异常了

为什么可以这么做，因为我们的bean是单例的，而且是字段注入（setter注入）的，单例意味着只需要创建一次对象，后面就可以从缓存中取出来，字段注入，意味着我们无需调用构造方法进行注入。如果是原型bean，那么就意味着每次都要去创建对象，无法利用缓存

首先在容器初始化后是不会出现读取到不完整bean的，虽然说通过二级缓存将早期对象与成熟对象分离，但它并没有完全解决，完全解决还是得需要两把锁：

• 从缓存中拿加锁：初始化容器过程中通过在getSingleton方法中加了synchronized 锁，然后把整个Bean的创建过程也锁起来，锁的都是同一把锁（一级缓存对象）synchronized (this.singletonObjects)
• 然后在钩子方法getSingleton那里把整个createBean创建Bean的过程中使用了synchronized 包起来，非钩子中的createBean没有锁，因为只有循环依赖才需要避免获取不成熟bean

• 通知（Advice）在切面的某个特定连接点上执行的动作，通俗一点说就是定义了“什么时候“和”什么时候做什么”。通知有很多种类型：前置通知（Before）、后置通知（AfterReturning）、异常通知（AfterThrowing）、最终通知（After）、环绕通知（Around）。
• 连接点（Join Point）是程序执行过程中能够应用通知的所有点。就好比切点表达式匹配的方法，真正需要增强的方法
• 切点（Poincut）是定义了在“什么地方”进行切入，哪些连接点会得到通知。显然，切点一定是连接点。就好比切点表达式
• 切面（Aspect）是通知和切点的结合。通知和切点共同定义了切面的全部内容——是什么，何时，何地完成功能。就是下面讲到的advisor，也是我们注解中使用@Aspect注解的类
• 引入（Introduction）允许我们向现有的类中添加新方法或者属性。
• 织入（Weaving）将通知切入到连接点的过程，分为编译期织入、类加载期织入和运行期织入。

它基于动态代理来实现。默认地，如果使用接口的，用 JDK 提供的动态代理实现，如果没有接口，使用 CGLIB 实现。大家一定要明白背后的意思，包括什么时候会不用 JDK 提供的动态代理，而用 CGLIB 实现

Spring AOP 只能作用于 Spring 容器中的 Bean，它是使用纯粹的 Java 代码实现的，只能作用于 bean 的方法

Spring 延用了 AspectJ 中的概念，包括使用了 AspectJ 提供的 jar 包中的注解，但是不依赖于其实现功能

• Spring 1.2 基于接口的配置：最早的 Spring AOP 是完全基于几个接口的，想看源码的同学可以从这里起步。
• Spring 2.0 schema-based 配置：Spring 2.0 以后使用 XML 的方式来配置，使用 命名空间 <aop ></aop>
• Spring 2.0 @AspectJ 配置：使用注解的方式来配置，这种方式感觉是最方便的，还有，这里虽然叫做 @AspectJ，但是这个和 AspectJ 其实没啥关系

AspectJ 能干很多 Spring AOP 干不了的事情，它是 AOP 编程的完全解决方案。Spring AOP 致力于解决的是企业级开发中最普遍的 AOP 需求（方法织入），而不是力求成为一个像 AspectJ 一样的 AOP 编程完全解决方案

AspectJ 在实际代码运行前完成了织入，所以大家会说它生成的类是没有额外运行时开销的

拦截粒度为类级别案例

拦截粒度为方法级别案例

自动代理方式案例

spring5.2.9版本通知方法的执行顺序

@Aspect public class LogUtil {     /**      * 方法执行前执行      * @param joinPoint      */     @Before("execution( public int lb.study.tulin.springaoptest.MyCalculate.*(int,int))")     public static void start(JoinPoint joinPoint){         Object[] args = joinPoint.getArgs();         String name = joinPoint.getSignature().getName();         System.out.println(name+"方法开始执行，参数是："+ Arrays.asList(args));     } }

@Before前置通知并获取方法参数
@After后置通知，方法执行后执行
@AfterReturning，方法执行后，且能拿到执行结果
@AfterThrowing方法出现异常执行
@Around环绕通知

前面我们知道了spring aop创建代理对象时机：如果存在循环依赖，则在实例化后创建；如果不存在循环依赖，则在初始化后创建，对应着BeanPostProcessor.postProcessAfterInitialization()方法。只需要研究正常bean的代理就行了，循环依赖的bean也差不多流程，而且我们在doCreateBean之前就已经解析好了我们的切面Aspect，接着我们在getBean的时候spring就会一个一个的去比较要不要创建代理对象，如果要就创建，放入bean缓存池中，也就是<beanName,代理对象>，当我们getBean的时候其实拿到的是代理对象，调用方法也就调用到了代理对象的方法

在目标对象调用方法后，我们getBean的时候因为单例池中放的其实是代理对象，所有拿到的自然也是代理对象，使得方法调用到动态代理对象的加强方法上

使用(exposeProxy = true)+((Calculate) AopContext.currentProxy()).div(numA,numB);//必须配合(exposeProxy = true)使用
exposeProxy = true会将代理对象放入到线程变量中，通过AopContext.currentProxy()可以拿到，也就会被增强了

cglib：使用的是继承的方式，当调用目标方法的时候，是调用的子类（代理对象）的方法，自然是加强了，方法里调用也是调用到代理对象的方法，所以在cglib中是会重复调用的

jdk代理：通过反射调用目标方法，所以在方法里面调用也是调用的目标对象的方法并不是代理对象的方法，所以并不会重复调用

关于spring中cglib并不会重复调用的解释：我测试了在spring5.29版本中，在cglib的情况下（强制使用cglib：@EnableAspectJAutoProxy(proxyTargetClass = true)）上面的案例没有执行区别。原因在于spring中是通过advisor去调用的目标方法（advisor里面保存了目标对象），并没有直接调用代理对象的方法，自然方法里面的调用并不会加强

入口：@EnableAspectJAutoProxy注解会注册一个AspectJAutoProxyRegistrar（实现了ImportBeanDefinitionRegistrar），在解析import注解的时候会调用其registerBeanDefinitions方法，方法里主要是注册了一个InstantiationAwareBeanPostProcessor类型的bean后置处理器（在bean实例化前调用）AnnotationAwareAspectJAutoProxyCreator，在实例化前调用后置处理器的postProcessBeforeInitialization()实现解析我们的aop，非循环依赖在初始化后调用postProcessAfterInitialization()创建我们的动态代理

刷选合适advisor集合：首先获取到前面解析到的所有List<Advisor>缓存，匹配规则也不难，首先进行类级别刷选，再进行方法级别刷选（循环当前class包括它父类的所有方法），匹配方式是通过Aspect的方式匹配，这也说明了spring只是用到了Aspect的匹配方法而已。另外也有一个关键地方：这里会对我们的advisor排序，从而实现调用的时候按照advice通知类型执行

代理创建：如果前面刷选advisor集合不为空，说明需要增强创建动态代理对象。而且会在Map缓存中放入一个标识防止重复创建代理。如果ProxyTargetClass=false且targetClass对象实现了接口，走jdk动态代理，否则走cglib动态代理

代理invoke调用：因为IOC一级缓存放入的为代理对象，自然我们拿到的就是代理对象。如果设置了exposeProxy = true，会把我们的代理对象暴露到线程变量中，这里有几种情况不会增强：执行方法为equals或hashCode方法不会增强，执行的class对象是DecoratingProxy类型 也不要拦截器执行。使用责任链模式调用通知，通知执行顺序：环绕before-->普通before-->目标方法执行-->环绕afterReturning/环绕after/出现异常（看你怎么写）-->普通afterReturning或者异常AfterThrowing-->普通after

隔离级别是数据库的，spring只是去帮忙设置，毕竟隔离级别是会话级别的

事务的传播特性指的是当一个事务方法被另一个事务方法调用时，这个事务方法应该如何进行？

事务传播行为类型 外部不存在事务 外部存在事务 使用方式
REQUIRED（默认） 开启新的事务 融合到外部事务中 @Transactional(propagation = Propagation.REQUIRED)适用增删改查
SUPPORTS 不开启新的事务 融合到外部事务中 @Transactional(propagation = Propagation.SUPPORTS)适用查询
REQUIRES_NEW 开启新的事务 挂起外部事务，创建新的事务 @Transactional(propagation = Propagation.REQUIRES_NEW)适用内部事务和外部事务不存在业务关联情况，如日志
NOT_SUPPORTED 不开启新的事务 挂起外部事务 @Transactional(propagation = Propagation.NOT_SUPPORTED)不常用
NEVER  不开启新的事务 抛出异常 @Transactional(propagation = Propagation.NEVER )不常用
MANDATORY 抛出异常 融合到外部事务中 @Transactional(propagation = Propagation.MANDATORY)不常用
NESTED 开启新的事务 融合到外部事务中,SavePoint机制，外层影响内层， 内层不会影响外层 @Transactional(propagation = Propagation.NESTED)不常用

指定事务等待的最长时间（秒）,当前事务访问数据时，有可能访问的数据被别的数据进行加锁的处理，那么此时事务就必须等待，如果等待时间过长给用户造成的体验感差

readonly:只会设置在查询的业务方法中
connection.setReadOnly(true)    通知数据库，当前数据库操作是只读，数据库就会对当前只读做相应优化

设置 当前事务出现的那些异常就进行回滚或者提交。

spring声明式事务管理默认对非检查型异常和运行时异常进行事务回滚，而对检查型异常则不进行回滚操作
1、继承自RuntimeException或Error的是非检查型异常==>>回滚
2、继承自Exception的则是检查型异常（RuntimeException本身也是Exception的子类）==>>提交

常见的RuntimeException
        1、NullPointerException：一般都是在null对象上调用方法了。
        2、NumberFormatException：继承IllegalArgumentException(非法参数)，字符串转换为数字时出现。
        3、ArrayIndexOutOfBoundsException:数组越界。
        4、StringIndexOutOfBoundsException：字符串越界。比如 String s="hello"; char c=s.chatAt(6);
        5、ClassCastException:类型转换错误。比如 Object obj=new Object(); String s=(String)obj;
        6、UnsupportedOperationException:该操作不被支持。有可能子类中不想支持父类中有的方法，可以直接抛出
        7、ArithmeticException：算术错误，典型的就是0作为除数的时候。

@Transactional注解应该写在哪

Spring框架提供两种方式来进行编程式事务管理：

• TransactionTemplate.
• PlatformTransactionManager 的实现。

Spring团队推荐使用第一种方式进行编程式事务管理。

Model1 模型是很早以前项目开发的一种常见模型，项目主要由 jsp 和 JavaBean 两部分组成。

它的优点是：结构简单。开发小型项目时效率高。

它的缺点也同样明显：
第一：JSP 的职责兼顾于展示数据和处理数据（也就是干了控制器和视图的事）
第二：所有逻辑代码都是写在 JSP 中的，导致代码重用性很低。
第三：由于展示数据的代码和部分的业务代码交织在一起，维护非常不便。

所以，结论是此种设计模型已经被淘汰没人使用了

在Model 1模式下，整个Web应用几乎全部由JSP页面组成，JSP页面接收处理客户端请求，对请求处理后直接做出响应。用少量的JavaBean来处理数据库连接、数据库访问等操作。  就像刚学java的时候，jsp本来就是servlet，它本来就能处理，也能写java代码，这种模式就是说控制器逻辑全在jsp中写

Model2 模型是在 Model1 的基础上进行改良，它是 MVC 模型的一个经典应用。它把处理请求和展示数据进行分离，让每个部分各司其职。
此时的 JSP 已经就是纯粹的展示数据了，而处理请求的事情交由控制器来完成，使每个组件充分独立，提高了代码可重用性和易维护性

Model 2是基于MVC架构的设计模式
在Model 2架构中，Servlet作为前端控制器，负责接收客户端发送的请求

在Servlet中只包含控制逻辑和简单的前端处理；后端JavaBean来完成实际的逻辑处理；最后，转发到相应的JSP页面处理显示逻辑

Model 2具有组件化的特点，更适用于大规模应用的开发。

1）前端控制器DispatcherServlet /dɪˈspætʃər/由框架提供作用：接收请求，处理响应结果
2）处理器映射器HandlerMapping由框架提供作用：根据请求URL，找到对应的Handler
3）处理器适配器HandlerAdapter由框架提供作用：调用处理器（Handler也就是Controller）的方法
4）处理器Handler又名Controller,后端处理器作用：接收用户请求数据，调用业务方法处理请求
5）视图解析器ViewResolver由框架提供作用：视图解析，把逻辑视图名称解析成真正的物理视图。支持多种视图技术：JSTLView,FreeMarker...
6）视图View,程序员开发作用：将数据展现给用户

处理器映射器-HandlerMapping

处理器适配器-HandlerAdapter

视图解析器-View Resolver

@RequestParam

@RequestBody

@PathVariable

AOP 思想是 Spring 框架的两大核心之一，是解决方法调用依赖以及提高方便后期代码维护的重要思想。它是把我们代码中高度重复的部分抽取出来，并在适当的时机，通过代理机制来执行，从而做到不修改源码对已经写好的方法进行增强。而拦截器正是这种思想的具体实现

自定义拦截器中三个方法说明及使用场景

Bean 被创建两次 ？

在 Spring MVC 配置文件中引用业务层的 Bean

其实在springboot中service层是可以注入controller的，但是他们是一个controller对象，也就是说会把springmvc容器中的bean全部注入到springioc中

为什么要分父子容器