Java中的周杰伦

调用者在获取自旋锁时，如果当前锁被其他调用者调用，他不会让进程进入睡眠状态，而是一直在原地自旋等待其他调用者释放锁

他是忙等待锁

可能死锁

无锁机制，CAS，原子类中

调用者在获取互斥锁时，如果当前锁被其他进程所占用，它会让进程进入到睡眠状态，加入到等待队列中，然后使用调度机制让进程处理其他业务，如果其他调用者释放了锁，那么就从等待队列中拿出这个进程获取锁

当多个线程想要获取公平锁时，如果当前锁被其他线程所持有，那么就会按照等待的先后顺序将这些线程加入到等待队列当中，释放锁时，从队列头部获取最早开始等待的线程来持有锁

不能保证公平性，当多个线程获取非公平锁时，如果当前锁被其他线程所持有那么他不会按照先后顺序进行加锁，而是会抢锁，那个线程抢到了哪个线程获取锁

多个线程可以同时获取锁

一个线程只能获取一个锁

ReentrantLock使用独占方式实现互斥锁

ReentrantReadWriteLock中写操作的独占锁，读操作是共享锁

高级别锁，可以区分读写操作，符合条件时允许多个线程访问对象，当是读操作时，允许多个线程来获取读锁，但不允许写锁，如果时写操作时，所有线程都要睡眠等待

也叫可重入锁，可以理解为是一种 特殊的互斥锁，也是一个线程可以获取一个锁，允许在还没有释放锁时，反复对该锁进行加锁操作

写操作比较少的情况下，即冲突发生很少的情况，减少锁竞争带来消耗，增大了吞吐量

写操作很多的情况下使用

(1)将该类的构造方法定义为私有方法，这样其他处的代码就无法通过调用该类的构造方法来实例化该类的对象，只有通过该类提供的静态方法来得到该类的唯一实例；(2)在该类内提供一个静态方法，当我们调用这个方法时，如果类持有的引用不为空就返回这个引用，如果类保持的引用为空就创建该类的实例并将实例的引用赋予该类保持的引用。

(1)需要生成唯一序列的环境；(2)需要频繁实例化然后销毁的对象；(3)创建对象时耗时过多或者耗资源过多，但又经常用到的对象；(4)方便资源相互通信的环境。

可以避免全局使用的类总是被创建和销毁，可以节省系统资源，确保只有一个实例

没有接口，不能继承，与单一职责原则冲突，一个类应该只关心内部逻辑，而不关心外面怎么样来实例化

懒汉式

饿汉式

双重检验锁

静态内部类

枚举类

线程安全方面：饿汉式天生就是线程安全的，可以直接用于多线程而不会出现问题，懒汉式本身是非线程安全的。

资源加载和性能方面：饿汉式在类创建的同时就实例化一个静态对象出来，不管之后会不会使用这个单例，都会占据一定的内存，但是相应的，在第一次调用时速度也会更快，因为其资源已经初始化完成，而懒汉式顾名思义，会延迟加载，在第一次使用该单例的时候才会实例化对象出来，第一次调用时要做初始化，如果要做的工作比较多，性能上会有些延迟，之后就和饿汉式一样了。

序列化

克隆

反射

解决方案如下：

1、防止反射

定义一个全局变量，当第二次创建的时候抛出异常

2、防止克隆破坏

重写clone(),直接返回单例对象

3、防止序列化破坏

添加readResolve()方法 , 该返回Object对象 也就是instance

提供一个统一的工厂类

不在提供一个统一的工厂类，针对每个对象来提供一个工厂

工厂类不单单可以创建一个对象，而是可以创建一组对象

静态代理

动态代理

时间复杂度为O(log n)

根节点必须为黑色，叶子节点下的null节点也必须为黑色

根节点到每个叶子节点经过的黑色节点个数都是相同的

不允许出现连续两个红色结点，每个红色结点下都有两个黑色节点

查询复杂度O(log n)

将待排序的数组构建成大顶堆，第一个元素就是最大元素，让它与最后一个数进行调换位置，然后将整下的n-1个数继续组成大顶堆，以此类推

每一个节点都比他的左右节点大的完全二叉树

每一个节点都比他的左右节点小的完全二叉树

最坏为O(n 2)，平均最好都为O(nlog 2 n) 空间O(1)，不稳定

大根堆那么堆里是一千万个元素，然后10次取堆顶，占用内存大。用小根堆堆里就10个元素，第11个元素进入后调整堆，弹出堆顶的那个最小元素，那么就可以保证堆里的元素就是最大的那10个，省内存。

从一个数组中随机选出一个数N作为基数，通过一趟排序将数组分割成三个部分，1、小于N的区域 2、等于N的区域 3、大于N的区域，然后再按照此方法对小于区的和大于区分别递归进行，从而达到整个数据变成有序数组。

时间O(N*logN) 空间O(log N),不稳定

固定选取

随机选取

三数取中

存在含有n个元素的数组，每一趟对相邻的两个元素进行大小判断，大的放到后面，这样一趟下来，最大的元素将放到最后，此时，最后的元素固定不动，第二趟再继续循环前面的n-1个元素，循环n趟后，整个数组排序完成

O(n 2) 空间o(1),稳定

1.存在n个元素的数组

2.第一趟从n个元素中找到最小的值放到索引为0的位置

3.第二趟从n-1个元素中找到最小的值放到索引为1的位置

循环往复，直到循环结束

第一趟比较n-1次，第二趟比较n-2次，又是一个等差数列，时间复杂度为O(N^2)，额外空间复杂度O(1)，不稳定性排序

假设初始序列有N个记录，则可以看成是N个有序的子序列，每个子序列的长度为1，然后两两归并，得到N/2个长度为2或者1的有序子序列，再两两归并…如此重复，直到得到一个长度为N的有序序列为止，这种排序方法称为2路归并排序

O(nlog n),空间O(1),稳定

如果在下单时需要进行短信通知的话，如果不引入消息队列，那么业务流程会直接为下单然后再到短信，需要等到短信发送成功才完成整个业务，但是引入消息队列那么在下单成功后，订单业务也就完成了，不需要等待短信通知的完成。提高了效率

比如在疫情时，有大量的人感染或者以为感染，然后流量激增的开始挂号治疗，那么在此时我们的服务就有可能会扛不住，那么引入消息队列的话，将下单请求加入到消息队列当中，每次完成最大的处理量，然后那其他请求等待而不是立刻请求到服务器上

每一个服务只需要管好自己的业务即可，比如下单服务，只需要管理好下单即可，不要管理短息通知业务

在发送到Mq时丢失，此时可以选择用 RabbitMQ 提供的事务功能，就是生产者**发送数据之前**开启 RabbitMQ 事务 `channel.txSelect` ，然后发送消息，如果消息没有成功被 RabbitMQ 接收到，那么生产者会收到异常报错，此时就可以回滚事务 `channel.txRollback` ，然后重试发送消息；如果收到了消息，那么可以提交事务 `channel.txCommit` 。但是开启事务会影响性能

如果要确保写mq的消息别丢，可以开启confirm模式，在生产者那里设置开启 `confirm` 模式之后，你每次写的消息都会分配一个唯一的 id，然后如果写入了 RabbitMQ 中，RabbitMQ 会给你回传一个 `ack` 消息，告诉你说这个消息 ok 了。如果 RabbitMQ 没能处理这个消息，会回调你的一个 `nack` 接口，告诉你这个消息接收失败，你可以重试。而且你可以结合这个机制自己在内存里维护每个消息 id 的状态，如果超过一定时间还没接收到这个消息的回调，那么你可以重发

就是 RabbitMQ 自己弄丢了数据，这个你必须**开启 RabbitMQ 的持久化**，就是消息写入之后会持久化到磁盘，哪怕是 RabbitMQ 自己挂了，**恢复之后会自动读取之前存储的数据**，一般数据不会丢。除非极其罕见的是，RabbitMQ 还没持久化，自己就挂了，**可能导致少量数据丢失**，但是这个概率较小。

设置持久化有**两个步骤**：

- 创建 queue 的时候将其设置为持久化<br>

这样就可以保证 RabbitMQ 持久化 queue 的元数据，但是它是不会持久化 queue 里的数据的。

- 第二个是发送消息的时候将消息的 `deliveryMode` 设置为 2<br>

就是将消息设置为持久化的，此时 RabbitMQ 就会将消息持久化到磁盘上去。

必须要同时设置这两个持久化才行，RabbitMQ 哪怕是挂了，再次重启，也会从磁盘上重启恢复 queue，恢复这个 queue 里的数据。

注意，哪怕是你给 RabbitMQ 开启了持久化机制，也有一种可能，就是这个消息写到了 RabbitMQ 中，但是还没来得及持久化到磁盘上，结果不巧，此时 RabbitMQ 挂了，就会导致内存里的一点点数据丢失。

==所以，持久化可以跟生产者那边的 `confirm` 机制配合起来，只有消息被持久化到磁盘之后，才会通知生产者 `ack` 了，所以哪怕是在持久化到磁盘之前，RabbitMQ 挂了，数据丢了，生产者收不到 `ack` ，你也是可以自己重发的。==

主要是因为你消费的时候，**刚消费到，还没处理，结果进程挂了**，比如重启了，那么就尴尬了，RabbitMQ 认为你都消费了，这数据就丢了。

这个时候得用 RabbitMQ 提供的 `ack` 机制，简单来说，就是你必须关闭 RabbitMQ 的自动 `ack` ，可以通过一个 api 来调用就行，然后每次你自己代码里确保处理完的时候，再在程序里 `ack` 一把。这样的话，如果你还没处理完，不就没有 `ack` 了？那 RabbitMQ 就认为你还没处理完，这个时候 RabbitMQ 会把这个消费分配给别的 consumer 去处理，消息是不会丢的。

生产者 开启事务：同步，不推荐

   开启confirm模式  异步，推荐

消费者  关闭mq自动ack

mq 开启持久化

集群下使用setnx会出现的问题

如果发生故障，则需要选举得出新协调者

如果处于第一阶段，骑士影响不大，都回滚好了，在第一阶段事务肯定还没提交

如果处于第二阶段，则需要考虑每个参与者的自身情况只有自己和协调者知道，因此新协调者无法通过在场的参与者的状态推断出挂了的参与者是什么情况。    这里可以说那个日志解决，让协调者将自己发过的请求记录一下，这样新的协调者就会知道什么时候应该发送了

2pc是一种尽量保证强一致性的分布式事务，因此它是同步阻塞的，而同步阻塞就导致长久的资源锁定问题，总体效率低，还有单点故障问题，在极端条件下存在数据不一致的风险

增加了预提交阶段使得故障恢复之后协调者的决策复杂度降低，但整体的交互过程更长了，性能有所下降，并且还会存在数据不一致

Try指的是预留，资源的锁定和预留

Confirm指的是确认操作，这一步其实就是真正的执行了

Cancel指的是撤销

和2pc一样的流程，比如一个事务要执行3个操作，那么先对3个操作执行预留动作，如果预留成功就执行确认操作，如果有一个预留失败就执行撤销动作

TCC对业务的侵入较大和业务紧耦合，撤销和确认操作的执行可能需要重试，因此还需要保证操作的幂等，TCC可以跨数据库，跨不同的业务系统来实现事务

引用循环

ArrayList有两种修改方法一个是remove另一个是fastRemove，一个根据对象删除一个根据索引删除，其实foreach写法是对实际的Iterable、hasNext、next方法的简写，问题在fastRemove方法中，它的第一行是把modCount变量的值加一，这里会做迭代器内部修改次数检查，因为上面的remove(Object)方法修改了modCount的值，所以才会报出并发修改异常。

不要使用ArrayList的remove，改为用Iterator的remove即可

Java.lang.IllegalStateException异常（非法状态异常）出现的原因是 删除了一个不满足条件的元素。通过Iterator来删除，首先需要使用next方法迭代出集合中的元素，然后才能调用remove方法，否则集合可能抛出java.lang.IllegalStateException异常。

通过foreach方式进行删除的modCount变量的改变，会出现非法状态异常，可通过iterator迭代器的方式进行判断，删除。

通过for循环变量list的长度，正序来进行list中元素的移除，会出现漏删除的情况，可通过倒序删除的方式来解决。

ArrayList

LinkedList

Vector

Deque接口

PriorityQueue

HashSet

LinkedHashSet

SortSet接口

底层采用数组+链表或红黑树组成，在这个基础上增加了一个双向链表来保证插入数据的有序性

底层红黑树

用在方法体内部用来抛出一个Throwable类型的异常，如果是检查异常则需要在方法声明处，声明要抛出的错误，该调用者必须处理异常或继续抛出异常

用在方法声明处，用来声明程序有可能需要抛出的异常，仅当是受检查异常时调用者必须进行处理或者继续抛出异常。当调用者无法处理异常时应当继续抛出异常

select的timeout是微秒的，epoll是毫秒，所以select的实时性会更好

select 的描述符类型使用数组实现，FD_SETSIZE 大小默认为 1024或2048，因此默认只能监听少于 1024或2048 个描述符，epoll没有描述符数量限制

select支持全平台，epoll只支持linux

需要监控的描述符状态变化多，而且都是非常短暂的，也没有必要使用 epoll。因为 epoll 中的所有描述符都存储在内核中，造成每次需要对描述符的状态改变都需要通过 epoll_ctl() 进行系统调用，频繁系统调用降低效率。并且 epoll 的描述符存储在内核，不容易调试

epoll支持LT和ET 行触发，和边缘触发，行触发是epoll_wait检测到了描述符时间到达，将其加载到进程中，进程可以不用立即处理，而ET需要立即处理

epoll使用了epoll_event结构来处理，没有最大连接数的限制
select函数每次需要遍历fd_set，判断标志位有没有发生变化，如果发生变化则通知程序做中断处理
epoll函数不需要每次遍历全部文件描述符，epoll把就绪文件的文件描述符专门维护了一块空间，每次从就绪队列当中拿就可以了，这是两者最大区别
fd_set就是bitmap的数据结构，可以简单理解为只要位为0，那说明还没数据到缓冲区，为1反之

在本地有不止一个版本，在提交时git不知道要提交哪一个

首先使用 git pull，把本地版本更新成最新的

git diff，此命令比较的是工作目录(Working tree)和暂存区域快照(index)之间的差异（也就是修改之后还没有暂存起来的变化内容）

编辑一下冲突的文件：vim 日记
把那些多余的字段都删除掉，然后就commit一下再push一下就可以了

cpu和编译器为了更好的执行程序，它们会对指令进行优化，这往往会引起一些逻辑上的错误，这个逻辑错误指的就是，程序代码的顺序。只有当单线程下不改变结果的情况下就会发生指令重排，两条语句间是相互独立的。jvm提供了happens-before8条原则，还提供了4个屏障（读读，读写，写读，写写）来防止发生指令重排

写屏障会确保指令重排序时，不会将写屏障之前的代码排在写屏障之后

读屏障会确保指令重排序时，不会将读屏障之后的代码排在读屏障之前

为什么不能保证原子性，因为在java中之只有基础变量具有原子性像int i=1,但是int j=i 或 i++这种操作就不是原子性的，所以不能保证原子性

只能升不能降，无锁->偏向锁->轻量级锁->重量级锁

偏向锁和轻量级锁都是为了解决重量级锁在没有多线程竞争的条件下，使用底层操作系统互斥量带来的性能问题

轻量级锁和偏向锁不同的是，轻量级锁在无竞争的条件下会使用CAS来替代使用互斥量，而偏向锁在无竞争的条件下直接会把整个同步消除

偏向锁的加锁

偏向锁解锁

锁消除

锁粗化

可以调用lock.interrupt方法来使当先线程停止等待，去做其他事情

使用Condition类和newCondition方法来实现，一个lock可以创建多个condition实例，多个线程对象可以注册到condition中，从而可以实现多路通知功能，使用condition中的signalAll方法来实现选择性通知功能，唤醒注册在该condition中的线程对象

lock首先会使用cas对state进行判断，如果是0则说明当前锁没有被占用，则使当前线程占有锁

如果为1则被其他占用，进入acquire方法，里面有一个if( ! tryAcquire(1)&&···)的判断进入到tryAcquire方法

进入到这个方法时会调用nofairTryAcquire方法进行判断，判断当前状态值是否为0，为0则设置当前线程占用锁将state设置为1，如果不为0，则会判断当前对象与当前持有锁对象是否相等，相等会增加状态值，从这里就能看出来可重入锁的原则，同一个线程可以反复的使用它占用的锁

如果都不满足返回false，在acquire中就会执行acquireQueued方法也就是CLH队列抢占

使用一个版本号解决ABA问题，ABA问题是一个线程获取到变量最开始的值，进入等待状态，另外一个线程也获取到了该变量它将当前变量改为另外一个数，改完之后又改回原来的数退出。此时第一个线程被唤醒，它读到的还是原来的数，但是这个数已经被修改过了。使用原子引用AtomicReference + 某种记录机制类似于时间戳=AtomicStampedReference

可以讲多个变量封装为一个对象解决

允许count个线程阻塞在同一个地方，直到线程完成工作为止

有一个多线程下处理多个文件的任务

使用线程池处理任务，每一次处理文件count数都会-1，调用它的wait方法直到所有文件都获取完之后才会执行其他业务

调用了wait方法使线程进入到等待状态，需要通过其他线程执行notify或notifyAll方法进行唤醒

当线程尝试获取同步锁时，如果当前锁已经被别人线程所占用，那么将会进入到阻塞状态

当前线程执行了sleep()方法，或者调用了其他线程的join()方法，或者发出了I/O请求时，就会进入这个状态。线程会进入到阻塞状态。当sleep()状态超时、join()等待线程终止或者超时、或者I/O处理完毕时，线程重新转入就绪状态。

最小同时运行线程数

最大同时执行线程数量

如果当前线程池中的数量大于核心线程数，此时没有新来的请求，那么核心线程之外的线程不会立即销毁，而是会等待这个时间后被销毁

等待时间的时间单位

当线程池中线程数量大于核心线程数，那么新来的请求就会加入到阻塞队列当中

生成新的线程

如果当前线程池数量大于最大线程数并且阻塞队列中也已经满了，那么就会使用饱和策略还处理

AbortPolicy终止策略，当来新任务时会直接拒绝，排除RejectExecutionException异常

CallerRunsPolicy，只要当前线程池未关闭，在调用者线程内，直接调用被丢弃的任务，会导致性能急剧下降

DiscardPolicy丢弃策略，不处理新任务，直接丢弃

DiscardOldPolicy丢弃最早策略，丢弃最早进行等待的线程

FixedThreadPool固定线程数量的线程池

SignalThreadPool只有一个线程的线程池，会反复使用这一个线程

newCachedThreadPool根据实际情况调整线程数量的线程池

内存问题，因为在写入的时候是需要将当前容器进行复制的

数据一致性问题，只能保证数据的最终一致性，不能保证数据的实时一致性。所以如果你希望写入的的数据，马上能读到，请不要使用CopyOnWrite容器。【当执行add或remove操作没完成时，get获取的仍然是旧数组的元素】

ConcurrentLinkedQueue

底层使用数组，并发控制采用可重入锁来实现，不管是插入还是取出都需要获取锁，不能保证公平性，使用ReentrantLock和Condition实现生产者消费者的同步问题

底层使用单向链表，未指定容量使用Integer.MAX_VALUE，使用ReentrantLock和Condition实现生产者消费者的同步问题

支持优先级的无界阻塞队列，并发控制采用ReentrantLock，不可以插入null值，必须插入的值可以比较大小，否则会报出ClassCastException异常

他们都是使用ReentrantLock和Condition实现生产者消费者的同步问题

A是基于数组的，L是基于链表的

A中生产和消费都是同一把锁，而L中生产和消费使用的是不同的锁，生产是putLock，消费是takeLock

A必须指定容量大小，L可以不指定大小但是默认为Integer.MAX_VALUE,也可以自己指定大小

统计队列中元素个数的方式不一样，A是建立了一个int的变量，L是定义了一个AutomaticInteger对象

实现生产或消费的方式不一样，A中插入和删除一个元素时，直接删除枚举对象，不会产生任何或销毁任何额外实例，L中是维护一个Node<E>节点会额外产生一个Node对象，这在高并发的情况下，会影响到性能。所以A效率会更高一点

跳表是一种用来快速查询的数据结构，跳表的插入和删除只需要对局部进行操作即可，在高并发的情况下，只需要部分加锁即可 时间复杂度为o(log n)

跳表的本质是同时维护了多个链表，来做索引，并且分层，最低级链表是全部元素，每上一层就是下面一层的子集，跳表内所有元素都是排序的，查找时从顶层链表开始查找，一旦发现该元素大于链表中的某个值就会进入下一层继续寻找

主要使用CAS+volatile和Native方法来保证原子性，从而避免synchronize的开销，使用unsafe类的中objectFieldOffset方法，返回一个valueOffset，另外还有一个被volatile修饰的变量value，所以jvm可以保证任何时候都能拿到最新值。还有一个getAndIncrement方法调用unsafe中getAndAddSet传入3个参数 this，valueOffset，1分别为当前地址，预期地址，如果相等则+1，里面有一个dowhile循环

key.threadLocalHashCode& len-1

在set时，如果存在与key的hash值相等的，就使用线性探测方式来尝试在数组的下一个索引存放值

会经过两次判断，都成功才会进行扩容。在set方法中，首先会清理掉key为null的Entry，如果此时还大于等于数组长度的3分之2，则进入rehash方法中，在rehash中，会进行一次全量清理，如果当前数组长度大于等于数组定义长度的2分之一，就会进行扩容。扩容会使Entry数组增加2倍

Spring中的事务隔离就是使用ThreadLocal来实现的，保证单个线程中的数据库操作是同一个数据库连接下的，采用这种方式时，不需要业务层感知并管理connection对象，通过传播级别，管理事务间的切换，恢复，挂起。在TransactionSynchronizationManager中

Map中是以ThreadLocal为key，Entry是继承于weakReference弱引用的，而value又是强引用，当这个key与其他对象之间没有强引用，那么在GC时就会对该Key进行垃圾回收，所以会出现大量key为null，但是value还存在的Entry，这就会造成内存泄漏

解决

ThreadLocal虽然会使数据或对象变成线程专属变量，但是这个变量或对象没有存储在栈中，还是存储在堆中，但是使用了一些机制将可见性改为了线程可见性

使用InheritableThreadLocal来实现线程共享

内存泄露

内存溢出

方法区

堆

虚拟机栈

本地方法栈

程序计数器

将文件转为二进制流

静态结构转化为运行时数据结构

生成class文件

验证生成的class文件中的字节流是否符合jvm的规范

在方法区中分配内存空间

虚拟机将常量池中的符号引用转化为直接引用

真正赋值，执行类构造方法

forName

loaderClass·

经过语法语义的分析以及注解的处理最后才会生成class文件

加载又可以分为，装载 连接 初始化

装载

连接

初始化

把字节码转换成操作系统可识别的执行指令，jvm字节码解释器和即时编译器

调用系统的硬件执行最终程序指令

启动类加载器

扩展类加载器

应用类加载器

用户自定义类加载器

我们创建一个自定义string类，但是在加载自定义String类的时候会率先使用启动类加载器加载，而启动类加载器在加载的过程中会先加载jdk自带的文件（rt.jar包中java\lang\String.class），报错信息说没有main方法，就是因为加载的是rt.jar包中的string类。这样可以保证对java核心源代码的保护，这就是沙箱安全机制。

自定义类加载器，重写loadClass方法

使用线程上下文类加载器

spi机制

例子

实现一个系统，这个系统中需要大量的图片，如果一次性全部加载有可能会引起OOM，此时可以使用HashMap保存图片的路径和图片对象关联的软引用的映射关系，当内存不足时就会回收这些图片对象，来确保不会报出OOM

第一次标记出不可达对象

第二次当这些不可达对象执行finalize方法时，如果在这个期间与GCRoots有了引用关系，则成功逃脱不需要被回收，如果没有则说明真的需要被回收了

指针碰撞

空闲链表

解决内存碎片问题

由于要移动存活对象，所以要更新引用，效率比较低

会产生大量内存碎片

效率低

不占用额外的内存空间

内存缩水，对堆内存使用率下降

避免了内存碎片

CMS，并发标记收集回收器，使用标记-清除算法，是以获取最短垃圾回收停顿时间为目的的垃圾回收器，非常适用于使用在注重用户体验的服务上

年轻代使用ParNew 老年代使用CMS+SerialOld的组合（SerialOld作为CMS出错后的后备收集器，CMS必须要在老年代堆内存使用完之前完成垃圾回收，否则CMS回收失败，采用SerialOld）

收集的步骤

缺点与优点

它不仅可以满足获取最短垃圾回收停顿时间，还可以建立一个可预测的回收停顿模型

它可以通过多个cpu来缩短回收停顿时间，G1回收器可以通过并发的方式让java线程继续运行

可根据用户设置停顿时间，制定回收计划(但是也可能存在超出用户的停顿时间).

region 大小和大对象很难保证一致，这会导致空间的浪费；特别大的对象是可能占用超过一个 region 的。并且，region 太小不合适，会令你在分配大对象时更难找到连续空间，这是一个长久存在的情况。

初始标记

并发标记

最终标记

筛选回收

事务是最小的执行单位，原子性保证事务要么都执行，要么都不执行

执行事务后，保证事务从一个正确的状态转换到另一个正确的状态

并发访问数据库时，一个事务的操作不受其他事务影响

事务执行完之后对数据库中的数据进行修改或更新，对这个数据修改是永久的

允许读取未提交的数据

允许读取并发访问期间已经提交的数据

对同一字段的多次读取都是相同的结果，除非是数据内部自己修改了值

最高隔离级别，完全符合ACID，事务会依次逐个执行

一个事务读取的数据是在另一个事务中还没有被提交的数据

并发读取数据时，一个事务读取数据但是还未提交，另一个事务修改这个数据导致两次读取结果不一致

并发读取数据时，一个事务前后两次查询范围数据，后一次查询看到了第一次未读到的数据，就像幻觉一样

行锁只能锁住行，但是幻读产生的原因是插入要更新的记录是行与行之间的间隙，所以行锁无法锁住

使用间隙锁+行锁=next-key Lock

用来解决索引记录之间间隙上的锁，保证某个间隙内的数据在锁定情况下不会发生任何变化

undo log是逻辑日志，记录是事务提交之前操作记录的日志，用于回滚，redo log是物理日志，记录的是事务提交后的新数据，用于服务器宕机之后恢复数据

所有的版本数据只会存储一份，使用回滚指针将他们连接起来

由所有未提交的事务ID和已提交的最大事务ID组成

主键索引

查询速度非常快，因为节点都是有序的

依赖于有序，如果是整型还好，但如果传入的是UUID或者字符串的话，就会大大降低速度

更新代价大，叶子节点存放着数据如果修改索引列的数据时，对应的索引也需要修改

二级索引

更新代价小，叶子节点不存放数据了

有可能会二次回表，第一次根据索引查找到对应的数据指针，第二次会根据数据指针在进行查询

优点

缺点

b树索引的非叶子节点存放索引和数据，叶子节点也存放索引和数据

b+树索引的非叶子节点存放的是索引，叶子节点存放的是数据和索引，叶子节点之间具有一条引用链进行

可以降低磁盘IO读写次数

查询具有稳定性

遍历效率更高

如果我们使用where name='?'时就不会走索引，而使用where userid=1and name='?'时就会走索引

经常用来查询的字段

经常用于连接的字段

不为null的字段

经常被作为条件查询的字段

不经常用于查询的字段

经常修改的字段

注意冗余索引

字符串类型考虑使用前缀索引

尽量建立联合索引而不是单列索引

创建表时会生成一个user.ibd用于存放索引和user.frm用于存放数据结构

因为innDB创建表时默认使用主键作为索引，所以不需要myi文件

脏页：内存中的页数据与磁盘中的页数据不一样

因为在执行一条更新修改语句时，内存中的页数据不会立刻同步到磁盘中，而是先存储在redo log日志上，如果redo log日志满了，他就会暂停其他线程执行，将内存中的页数据同步到磁盘中

这条语句上涉及的表或行有可能被其他用户加锁了，这是我们就需要等待锁的释放

数据库在查询时会根据索引来判断，是走索引快还是全表扫描，这个依据是索引的区分度，一个索引上的不同的数据越多，代表出现相同的索引越少，区分度也就越大，区分度越大代表基数越大，基数越大代表查询的行数越少。而选择基数是根据采样的方式，这种方式会造成失误，也就会让这条语句走全表扫描

还会出现数据冗余的情况和更新异常

根据数据库里面数据表的相关性进行拆分。 例如，用户表中既有用户的登录信息又有用户的基本信息，可以将用户表拆分成两个单独的表，甚至放到单独的库做分库。

简单来说垂直拆分是指数据表列的拆分，把一张列比较多的表拆分为多张表。

保持数据表结构不变，通过某种策略存储数据分片。这样每一片数据分散到不同的表或者库中，达到了分布式的目的。 水平拆分使用多个库或者表来扛更高的并发，可以支撑非常大的数据量

客户端代理： 分片逻辑在应用端，封装在jar包中，通过修改或者封装JDBC层来实现

中间件代理： 在应用和数据中间加了一个代理层。分片逻辑统一维护在中间件服务中

1.按照range来分，一般是时间范围，但是这个方式会引起热点问题，导致大量请求都打在最新的数据上了

2.对某个字段进行hash 均匀分布，可以平均分配每个库的数据量，这种方式的弊端在于扩容比较麻烦，会有一个数据迁移的过程，之前的数据需要重新计算在库中的位置

Sharding-jdbc

Mycat

可以使用redis生成id 灵活不依赖于数据库，但是引入新的程序增加了复杂度

雪花算法

解决

1、如果不同程序会并发存取多个表，尽量约定以相同的顺序访问表，可以大大降低死锁机会。

2、在同一个事务中，尽可能做到一次锁定所需要的所有资源，减少死锁产生概率；

3、对于非常容易产生死锁的业务部分，可以尝试使用升级锁定颗粒度，通过表级锁定来减少死锁产生的概率；

应用

底层有三个属性

好处

应用

linkedlist每个元素占用的内存空间较大，因为还要维护前后指针

ziplist存储在一段连续的内存上，所以存储效率很高。但是，它不利于修改操作，插入和删除操作需要频繁的申请和释放内存。

应用

intset其实底层就是一个数组，并且按照插入的顺序来存储。只有当满足两个条件时才会使用intset

应用

ziplist每个集合元素使用两个紧挨在一起的压缩列表来表示，第一个节点表示元素的成员，第二个节点表示元素的分值

ziplist可以使用更加紧凑的数据结构来实现多个元素的连续存储，节省空间

skiplist使用dict来表示元素与分值之间的关系

跳表时间复杂度O(log n)分析

应用

解决

让热点数据永不失效，或者快要过期时，使用另一个异步线程为该数据重新设置过期时间

使用分布式锁，当读取的数据为null时，重新为查询数据库的过程加锁

可以设置随机的过期时间防止同时过期

使用redis高可用的集群机制，主从机制，防止全盘崩溃

使用本地内存和服务限流降级策略，防止mysql崩溃

使用redis的AOF和RDB，进行持久化，快速恢复数据

如果布隆过滤器判断当前元素在缓存中，则不一定在

如果判断不在缓存，则一定不在

组成

是应用层和TCP/IP协议通信的中间软件通信层，是一组接口，一个Socket就是进程中通信的一端

select

epoll

文件尺寸小，恢复快，对redis的性能影响小

appendsync-always

appendsync-everysec

appendsync-no

实时性比较好，更加安全，秒级持久化，可追加写，可读性好

从已过期的数据集中挑选最不经常使用的数据进行淘汰

从已过期的数据集中挑选将要被淘汰的数据进行淘汰

从已过期的数据集中挑选最近最少使用的数据进行淘汰

从已过期的数据集中随机挑选数据淘汰

当内存不能容下新的数据时，挑选最不经常使用的进行淘汰

当内存不足时，随机挑选淘汰

当内存不足时，挑选最近最少使用的进行淘汰

禁止驱逐数据，当内存不足以容纳新的数据时，新写入就会报错

当数据库的主机宕机或者主机不够用时，机器的数量就会下降，造成数据的命中率下降

如果服务器节点数太少，就会造成分配不均匀，导致大量的数据存放在一个服务器节点上

解决

解决的是redis中主从机制中的主节点挂了不能自动故障转移的问题

（三个定时任务）（心跳机制+投票裁决）

问题一：sentinel没有配置从节点信息如何知道从节点信息的？

每隔10秒，sentinel向主节点发送info命令，用于发现新的slave节点

问题二、如何加入新的sentinel？

每隔2秒，向redis数据节点_ sentinel_:hello频道发送本sentinel节点的信息和对主节点的判断：这是进行对主节点进行客观下线和领导者选举的重要依据；也是发现新sentinel节点的重要依据

问题三：如何判断一个节点的需要主观下线的？

每隔1秒每个sentinel对其他的redis节点（master，slave，sentinel）执行ping操作，对于master来说，若超过down-after-milliseconds内没有回复，就对该节点进行主观下线并询问其他的Sentinel节点是否可以客观下线

1）监控（Monitoring）： Sentinel 会不断地检查你的主服务器和从服务器是否运作正常。
2）提醒（Notification）： 当被监控的某个 Redis 服务器出现问题时， Sentinel 可以通过 API 向管理员或者其他应用程序发送通知。
3）自动故障迁移（Automatic failover）： 当一个主服务器不能正常工作时， Sentinel 会开始一次自动故障迁移操作， 它会将失效主服务器的其中一个从服务器升级为新的主服务器， 并让失效主服务器的其他从服务器改为复制新的主服务器； 当客户端试图连接失效的主服务器时，集群也会向客户端返回新主服务器的地址，使得集群可以使用新主服务器代替失效服务器。

主观下线：每隔1秒每个sentinel对其他的redis节点（master，slave，sentinel）执行ping操作，若master超过down-after-milliseconds内没有回复，就对该节点进行主观下线，每个sentinel节点对redis节点失败的“偏见”

客观下线：当sentinel主观下线的节点是主节点时，sentinel会通过命令sentinel is-master-down-by-addr来询问其sentinel对主节点的判断，如果超过quorum个数就认为主节点需要客观下线, 所有sentinel节点对redis节点失败达成共识

使用raft协议（解决分布式系统一致性问题的协议）

1）每个做主观下线的sentinel节点向其他sentinel节点发送命令，要求将自己设置为leader

2）收到的sentinel可以同意或拒绝

3）如果该sentinel节点发现自己的票数已经超过了半数并且超过了quorum那么当选leader

4）如果此过程选举出了多个leader，那么将等待一段时间重新进行选举

1）过滤故障节点

2）根据slave-priority优先级进行选择

3）选择复制偏移量大的从节点为主节点

4）选择runid最小的从成为主（说明重启的时间靠前）

集群中的每个节点都有N-1个复制品，其中一个为主节点，其余的为从节点，如果主节点下线了，集群就会把这个主节点的一个从节点设置为新的主节点继续工作，这样集群就不会因为一个主节点的下线而无法正常工作

全量同步，增量同步

休眠的目的

弊端

UDP是无连接的，不可靠的，基于数据报文段的用户数据报协议，传输的数据少，速度快，头字节为8个字节

传输数据时无需建立连接，远程主机在接收到UDP报文后不需要确认

TCP是面向连接的，可靠的，基于字节流的传输层协议，它传输的数据多，速度慢，头字节为20-60个字节

TCP会在传输数据时建立连接，数据传送后释放连接，可靠性体现在，在建立连接和释放连接时有三次握手和四次挥手，在传输数据时还有确认，窗口，重传，拥塞控制等。所需资源多，需要确认，计数器，连接控制等

qq语音，视频等

文件传输发送，远程登录等

在不知道网络的情况下，先测试一下，窗口指数增长

将拥塞窗口缓慢增大，每经过一个往返时间就把发送方的窗口+1

没有 FRR，如果数据包丢失了，TCP将会使用定时器来要求传输暂停。在暂停的这段时间内，没有新的或复制的数据包被发送。有了 FRR，如果接收机接收到一个不按顺序的数据段，它会立即给发送机发送一个重复确认。如果发送机接收到三个重复确认，它会假定确认件指出的数据段丢失了，并立即重传这些丢失的数据段。有了 FRR，就不会因为重传时要求的暂停被耽误

流量控制

一个TCP分节丢失，导致其后续分节不按序到达接收端的时候。该后续分节将被接收端一直保持直到丢失的第一个分节被发送端重传并到达接收端为止

放弃tcp协议

HTTP管道化要求服务端必须按照请求发送的顺序返回响应，那如果一个响应返回延迟了，那么其后续的响应都会被延迟，直到队头的响应送达

HTTP2.0实现多路复用，一个连接即可实现并行

在发送端两个send方法中直接使用recv方法防止连续发送

由于粘包问题是由接收端无止境的接收，所以发送端发送数据之前可以先告诉接收端发送数据的大小

DNS规定了两个服务器，一个是主域名服务器，一个是辅助域名服务器，因为辅助域名服务器会定时的向主域名服务器进行查询为了了解数据是否发生变动，如果发生变动，则需要进行一个区域查询来解决数据同步的问题，区域传送使用TCP是因为数据同步的传送量比一个请求应答的数据量要大很多，所以使用TCP协议，因为他是可靠的，传送的数据量很大

客户端向DNS服务器发送解析请求，一般请求结果都不会超过512个字节，所以使用UDP不用三次握手来建立连接，提高速度

客户端向服务器发送一个带有SYN标识的请求，该请求的序列号为x，处于同步发送状态

服务器接收客户端的请求，并向客户端发送一个带有SYN和ACK标识的响应，序列号为y，确认序列号为x+1，服务器同步接收状态

客户端接收到服务器的响应，并向服务器发送一个带有ACK标识的响应，序列号为x+1，确认序列号为y+1

都会处于已建立状态

两次握手不可以吗？

第二次握手传回了ACK，为什么还要回传SYN？

3次都可以携带数据吗？

客户端向服务器发送一个带有FIN标识的请求，序列号为u，此时客户端处于FIN_CLOSE阶段

服务器接收到客户端的请求，并发送给客户端一个响应，该响应是带有ACK标识的序列号为v，确认序列号为u+1，此时服务器处于半关闭状态，CLOSE_WAIT，客户端处于FIN_CLOSE2阶段

当服务器完成自己的业务后也想要断开连接，回向客户端发送一个带有FIN和ACK的请求，序列号为w，确认序列号为u+1，服务端处于LAST_ACK阶段

客户端向服务端发送一个带有ACK标识响应，序列号为u+1，确认序列号为w+1，发送完之后客户端会等待2倍的最大生存时间MSL，处于TIME_WAIT阶段，之后客户端服务器都会处于关闭状态

为什么会等待2MSL

Time_wait

为什么要4次挥手

CMSA/CD载波监听多点接入协议，ppp点对点协议

ARP地址解析协议，IP子网协议

TCP和UDP

HTTP，FTP文件传输协议

SSL安全套接字层协议，TLS传输层安全协议

XDP外部数据表示协议

解析域名时使用

建立连接

发送数据时使用到ip协议

ip数据包在路由器之间，路由器选择这个协议

地址解析协议，路由器在服务器中通信时，需要将ip地址转化为MAC地址

建立连接后使用http访问页面

短连接

长连接

如409

410

1.0

1.1

1.0中会直接将整个对象请求过来

1.1中引入了range头域，允许请求资源的一部分，会返回206

一个连接可以并发处理多个请求

可以将header中的数据进行压缩

它允许服务端推送消息给客户端，在服务端确认连接之前，免得客户端向服务器发送连接请求

客户端向服务器端索要并验证公钥。

双方协商生成"对话密钥"。

双方采用"对话密钥"进行加密通信。

常见算法

常用算法

请求成功

请求成功，但是资源被永久转移

暂时地把内容转移到一个新的URL，但是老的URL还没有废除

请求的资源并没有被修改过

表示服务器允许访问，但是因为请求不符合条件

请求资源的访问被拒绝了

请求内容不存在

禁止请求中指定的方法

服务器错误

网关错误

服务器暂时处于超负载或者停机维护

网关超时，服务器作为网关或代理，没有及时从上层接收到请求

是一段json数据，存储jwt的元信息

是一段json数据，可以添加自定义的内容

是对前两部分的签名，防止数据篡改

块式管理

页式管理

段式管理

进程对于分配的资源，其他进程不能够访问只有当这个进程释放了这个资源，它才可以访问，否则会发生阻塞

进程获取一定资源后，又请求获取其他资源，但是这个资源有可能被其他进程所占用，这个事件会发生阻塞，但是它获取的资源还会继续使用

进程在使用资源时，在没有使用完之前，不允许其他进程剥夺

在发生死锁时必定存在一个进程-资源的循环链

通过设置一些限制条件，破坏必要条件中的一个或多个来预防

在获取资源过程中，使用某种方法让进程不会进入到不安全状态，也就是不会进入死锁

允许死锁的发生，但是经过系统检验之后来消除死锁

检验死锁的发生之后将进程从死锁的状态中脱离出来

ps -aux 查询内存中进程信息；
ps -aux | grep 查询进程的详细信息；

netstat -anp | grep 端口号

netstat -nultp 查看全部端口号

top

放入对应的CPU的可执行队列中

放入对应事件的等待队列中

是指进程不响应异步信号,内核的某些处理流程是不能被打断的

向进程发送一个SIGSTOP信号，它就会因响应信号而进入TASK_STOPPED状态,除非处于D状态

进程在断点处停下来的时候就处于TASK_TRACED状态，处于TASK_TRACED状态的进程不能响应SIGCONT信号而被唤醒，只能等到调试进程通过系统调用

不可被kill，即不相应任务信号，无法用SIGKILL杀死

-l

显示当前目录所在的绝对路径

-p

生成一个空的文件

用来更名或者移动文件到另一个目录当中

显示文件内容

-n 显示行数

-b 显示行数，但是不显示空的行

-r 递归拷贝

-p 保留原有的属性，权限，修改时间

-f 强制拷贝

-r 递归删除

-f 强制删除

-n 分别是显示文件后10行，和文件前十行

统计指定文档中的字节数、单词数、行数

-c 字节数 -l 行数 -m 字符数 -w 单词数

查找文件里符合条件的字符串

文本编辑器

vim的问题

解压

Resource资源定位，这个Resource资源就是BeanDefinition，也就是容器找数据的过程

BeanDefinition载入过程，这个载入过程就是把用户定义好的Bean表示成容器内部的数据结构，而这个数据结构就是BeanDefinition

将这些BeanDefinition注册进容器，就是将前面保存的BeanDefinition加入到HashMap中

JDK动态代理

cglib代理

静态代理

动态代理

利用反射机制生成一个实现代理接口的匿名类，在调用具体方法时使用InvokeHandler来处理

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

springaop是基于代理模式实现的，而AspectJ Aop是基于字节码操作

SpringAOP是运行时增强，那个是编译时增强

基于XML文件的事务配置

基于注解的事务配置

TransactionDefinition.propagation_required

TransactionDefinition.propagation_supports

TransactionDefinition.propagation_mandatory

TransactionDefinition.propagation_required_new

TransactionDefinition.propagation_not_supported

TransactionDefinition.propagation_never

TransactionDefinition.propagation_nested

Autowired默认是按照类型进行加载，Resource默认使用名称加载，如果Autowired需要使用name来进行加载则应配合@Qualifier注解使用，Resource（type=“”）如果指定name名称，则只会根据name进行装配。当找不到指定名称类型的Bean时才会用类型进行装配

Autowired时Spring下的，Resource时jdk1.6之后提出来的

在容器启动，为对象赋值的时候，遇到@Autowired注解，会用后置处理器机制，来创建属性的实例，然后再利用反射机制，将实例化好的属性，赋值给对象上

可见它间接实现InstantiationAwareBeanPostProcessor，就具备了实例化前后(而不是初始化前后)管理对象的能力，实现了BeanPostProcessor，具有初始化前后管理对象的能力，实现BeanFactoryAware，具备随时拿到BeanFactory的能力，也就是说，这个注解具备一切后置处理器的能力。

@Controller返回一个页面

@RestController只返回对象，对象数据直接以 JSON 或 XML 形式写入 HTTP 响应(Response)中，是@Controller和@ResponseBody的结合

@Component用于配置在类上，通过指定的路径来加入到容器当中

@Bean用在方法上，用来告诉Spring容器这个哪个类的实例

@Bean比@Component的自定义性更强，并且有些地方只能通过@Bean来加入到容器中，比如第三方库中的类需要加载到容器中

无法解决只能报出BeanCurrentlyCreationException异常，所以不要使用构造器注入

无法解决

一般采用提前暴露对象的方法

如果没有三级缓存，在AOP场景则为了循环依赖中最终取到的实例是代理对象，则必须在对象实例化的一开始就得执行后置处理器(依赖注入及init方法前)就先生成代理对象，并放到二级缓存中，这样的化就不符合Spring生命周期的设计。按照Spring生命周期的设计原则，AOP生成代理对象的基础是当前对象实例已经初始化完毕(实例+依赖注入+init方法调用+相关BeanPostProcessor调用完毕)，因此引入了三级缓存，A如果是AOP增量对象，B依赖A时

Spring 需要三级缓存的目的是为了在没有循环依赖的情况下，延迟代理对象的创建，使 Bean 的创建符合 Spring 的设计原则

分析getSingleton()的整个过程，Spring首先从一级缓存singletonObjects中获取。如果获取不到，并且对象正在创建中，就再从二级缓存earlySingletonObjects中获取。如果还是获取不到且允许singletonFactories通过getObject()获取，就从三级缓存singletonFactory.getObject()(三级缓存)获取，如果获取到了则：从singletonFactories中移除，并放入earlySingletonObjects中。其实也就是从三级缓存移动到了二级缓存

如果有一个A对象，它的属性是B对象，而B对象的属性也是A对象

首先A对象实例化然后属性注入，发现依赖于B对象，但是B对象此时还没有创建出来，就会出实例化B对象，B对象实例化之后，发现需要依赖A对象，但此时A对象已经实例化了，所以B对象最终完成创建，B对象返回到A对象的属性注入的方法上，A对象完成创建

使用三级缓存解决，三级缓存我理解的就是3个map，首先需要明确的是我对三级缓存的定义是                                             
singletonObjects（一级，日常实际获取Bean的地方）；

earlySingletonObjects（二级，还没进行属性注入，由三级缓存放进来）；

singletonFactories（三级，Value是一个对象工厂）
A对象实例化之后，属性注入之前，其实会把A对象放入三级缓存中，key是BeanName，Value是ObjectFactory
等到A对象属性注入时，发现还依赖B，又会去实例化B
B属性注入需要获取A,这里就是从三级缓存中拿出ObjectFactory，从ObjectFactory得到对应的Bean
拿到之后将三级缓存中的A记录消除，然后放在二级缓存中
显然二级缓存Key是BeanName，Value是Bean（这里的Bean还是没有属性注入的Bean）
等到完成初始化之后，就会从二级缓存中消除，放到一级缓存中
我们自己去getBean时，实际拿到的是一级缓存的

Service

Dao

sql注入，在实现定义好的查询语句的结尾添加额外的sql语句，欺骗数据库服务器进行非授权的任意查询，盗取数据库数据。

JDK提供的数据类型

用户自定义的数据类型

@SpringBootApplication中有三个注解：@SpringBootConfiguration  @EnableAutoConfiguration和@ComponentScan

@EnableAutoConfiguration：帮助SpringBoot将所有符合条件的@Configuration配置都加载到当前SpringBoot创建并使用的IoC容器，而这个注解也是一个复合注解，其中的关键功能由@Import提供，其导入的AutoConfigurationImportSelector的selectImports()方法通过SpringFactoriesLoader.loadFactoryNames()扫描所有具有META-INF/spring.factories的jar包

@ComponentScan：组件扫描，可自动发现和装配Bean

主要创建了配置环境(environment)、事件监听(listeners)、应用上下文(applicationContext)，并基于以上条件，在容器中开始实例化我们需要的Bean