知识点整理

并行：同一时刻都在执行
并发：同一时间段都执行，依赖CPU快速切换

进程：系统进行资源分配和调度的基本单位
线程：线程是进程的一个执行路径，一个进程中至少有一个线程，进程中的多个线程共享进程的资源，线程是 CPU分配的基本单位。

继承Thread类，重写run()方法
实现 Runnable 接口，重写run()方法
实现Callable接口，重写call()方法，可以通过FutureTask获取任务执行的返回值
 
JVM执行start方法，会先创建一条线程，由创建出来的新线程去执行thread的run方法，这才起到多线程的效果。

线程本地变量，如果创建一个ThreadLocal变量，那么访问这个变量的每个线程都会有这个变量的一个本地拷贝，多个线程操作这个变量的时候，实际是操作自己本地内存里面的变量，从而起到线程隔离的作用，避免了线程安全问题。

Thread类有一个类型为ThreadLocal.ThreadLocalMap的实例变量threadLocals，每个线程都有一个属于自己的ThreadLocalMap。

ThreadLocalMap内部维护着Entry数组，每个Entry代表一个完整的对象，key是ThreadLocal的弱引用，value是ThreadLocal的泛型值。

每个线程在往ThreadLocal里设置值的时候，都是往自己的ThreadLocalMap里存，读也是以某个ThreadLocal作为引用，在自己的map里找对应的key，从而实现了线程隔离。

ThreadLocal本身不存储值，它只是作为一个key来让线程往ThreadLocalMap里存取值。

ThreadLocal提供线程局部变量：它实现了让每一个线程都有自己专属的本地变量副本，通过使用get()和set()方法，获取默认值或将其值更改为当前线程所存的副本的值，从而避免了线程安全问题。
 
在不使用某个ThreadLocal对象后，要记得remove()，如果不清理自定义的 ThreadLocal 变量，可能会影响后续业务逻辑和造成内存泄露等问题
 
SimpleDateFormat是线程不安全的，在使用时一般不要定义为静态的，如果静态就必须加锁，不然就会报错。
原因：SimpleDateFormat 类内部有一个Calendar对象引用，它用来储存和这个 SimpleDateFormat 相关的日期信息，如果你的 SimpleDateFormat 是个 static 的，那么多个 thread 之间就会共享这个 SimpleDateFormat，同时也是共享这个Calendar引用。

 解决：1.将SimpleDateFormat定义成局部变量
           2.ThreadLocal
           3.DateTimeFormatter 代替 SimpleDateFormat
   
Thread 类里边有一个 ThreadLocal，ThreadLocal 里边有一个 ThreadLocalMap，ThreadLocalMap 里边实际干活的是一个 Entry。
threadLocalMap 实际上就是一个以 threadLocal 实例为 key，任意对象为 value 的 Entry 对象。

管理线程，避免增加创建线程和销毁线程的资源损耗
提高响应速度
重复利用

创建线程池，调用execute()方法添加一个任务：
1.如果正在运行的线程数量小于 corePoolSize，那么马上创建线程运行这个任务；
2.如果正在运行的线程数量大于或等于 corePoolSize，那么将这个任务放入队列；
3.如果这时候队列满了，而且正在运行的线程数量小于 maximumPoolSize，那么还是要创建非核心线程立刻运行这个任务；
4.如果队列满了，而且正在运行的线程数量大于或等于 maximumPoolSize，那么线程池会根据拒绝策略来对应处理。

corePoolSize：核心线程数
maximumPoolSize：最大线程数
keepAliveTime：非核心线程闲置存活时间
unit：keepAliveTime的时间单位
workQueue：等待队列
threadFactory：创建一个新线程时使用的工厂
handler：拒绝策略

1.直接抛异常（默认）
2.用调用者所在的线程来执行任务
3.丢弃阻塞队列里最老的任务，也就是队列里靠前的任务
4.当前任务直接丢弃

1.execute 用于提交不需要返回值的任务
2.submit()方法用于提交需要返回值的任务。线程池会返回一个future类型的对象，通过这个 future 对象可以判断任务是否执行成功，并且可以通过future的get()方法来获取返回值

调用 shutdown() 方法，将线程池状态置为shutdown,并不会立即停止：
1.停止接受外部提交任务
2.执行完当前任务和等待队列任务
3.停止
 
shutdown()方法的原理是逐个调用线程池中工作线程的interrupt方法来中断线程。

硬件：摩尔定律失效
软件：高并发系统，异步+回调等生产需求

        在new一个线程，调用他的start()方法时，其实是调用了Thread类里边的本地start0()方法，这个方法与底层的C++代码相对应，底层实际是对操作系统的调用。

线程的daemon属性为true表示是守护线程，false表示是用户线程
管程：Monitor(监视器)，就是我们平时所说的锁

Future：JUC下的一个接口，定义了操作异步任务执行的一些方法。
FutureTask调用get()方法会阻塞等待结果出来再运行，所以一般get()要放最后使用或者设置超时时间。
轮询比阻塞好一点，但是还会浪费一些CPU资源。

CompletableFuture扩展了Future：它实现了Future 接口和 CompletionStage 接口，他有函数式编程和回调处理能力，能代表一个完成阶段，计算完成后触发某些动作。它有默认的线程池，也可以指定线程池。它在异步任务结束或出错时，能自动调用某个方法；主线程设置好回调后，异步任务之间可以顺序执行。

例子：
如果现在有一些网站物品价格初始数据串，我们想要进行比价，可以将这些数据保存到Redis的Zset里边，保证数据没有重复，然后进行比较，
第一种笨办法就是一条数据一条数据的过，但是这样性能不高；
第二种，在JUC里边，有一个 CompletableFuture，用他做多线程异步并发是不阻塞的，而且可以自定义线程池，线程池根据数据量的大小伸缩，在数据量变大时仍能保证效率，大大提升程序性能。

乐观锁：无锁编程，采用CAS实现，适合读多场景
悲观锁：synchronized和lock的实现都是悲观锁，适合写多场景
公平锁：按顺序获得锁（避免锁饥饿）
非公平锁：直接尝试获取，获取不到再进入等待队列（减小线程开销，会导致锁饥饿）

如果为了更高的吞吐量，非公平锁是比较合适的，因为节省很多线程切换时间，吞吐量自然就上去了；否则就用公平锁，大家公平使用。

可重入锁(递归锁)：在一个 synchronized 修饰的方法或代码块的内部调用本类的其他 synchronized 修饰的方法或代码块时，是永远可以得到锁的。

重入原理：每个锁对象拥有一个锁计数器 和 一个指向持有该锁的线程的指针，当执行 monitorenter 时，如果目标锁对象的计数器为零，那么说明它没有被其他线程所持有，Java虚拟机会将该锁对象的持有线程设置为当前线程，并且将其计数器加1。
在目标锁对象的计数器不为零的情况下，如果锁对象的持有线程是当前线程，那么 Java 虚拟机可以将其计数器加1，否则需要等待，直至持有线程释放该锁。
当执行monitorexit时，Java虚拟机则需将锁对象的计数器减1。计数器为零代表锁已被释放。

死锁：死锁是指两个或两个以上的线程在执行过程中，因争夺资源而造成的一种互相等待的现象（竞争资源，进程运行推进的顺序不合适，资源分配不当）

一个线程不应该由其他线程来强制中断或停止，而是应该由线程自己自行停止。中断只是一种协作机制，中断的过程完全需要我们自己实现。

实例方法interrupt()仅仅是设置线程的中断状态为true，不会停止线程。
isInterrupted()通过检查中断标志位，判断当前线程是否被中断。
静态interrupted()方法：返回当前线程的中断状态并将中断状态设为false

中断标识停止线程：1、volatile标记；2、AtomicBoolean标记；3、interrupt() + isInterrupted()

如果线程处于被阻塞状态（例如处于sleep, wait, join 等状态），在别的线程中调用当前线程对象的interrupt方法，那么线程将立即退出被阻塞状态，并抛出一个InterruptedException异常
 
线程等待唤醒机制：
1、Object 的 wait() + notify()；
2、JUC包中 Condition 的 await() 方法让线程等待，signal() 方法唤醒线程；
3、LockSupport类中的park等待和unpark唤醒,不需要锁块，无顺序要求（一个线程只能发一张通行证，比如 t1 park一次，t2可以 unpark 唤醒，如果 t1 park 了两次，就需要两个线程 t2 park 一次，t3 park 一次，以此类推，一个线程只能唤醒一次阻塞。）

这个规范定义了程序中各个变量的读写访问方式，以及一个线程对共享变量的写入和对另一个线程的可见。
 
三大特性：
1、可见性：一个线程修改了某一个共享变量的值，其他线程是否能够立即知道该变更。
普通变量不保证可见性，因为所有变量存储在主内存，每个线程都有自己的工作内存，操作变量时，线程需要将主内存变量拷贝到工作内存进行。
2、原子性：一个操作是不可中断的
3、有序性：一个线程的执行并不总是从上到下，编译器和处理器会进行重排序提高性能，指令重排单线程环境可确保程序最终执行结果和代码顺序执行的结果一致，多线程环境中线程交替执行,结果无法确定。
 
Happens-Before规则：
如果一个操作happens-before另一个操作，那么第一个操作的执行结果将对第二个操作可见，而且第一个操作的执行顺序排在第二个操作之前。

volatile用来保证可见性、有序性(禁止令重排)：就是在写一个volatile变量时，写完后会立即刷新回主内存，读一个volatile变量时时，会直接从主内存读取。
 
它的底层采用的是内存屏障，内存屏障是一组JVM指令，也叫同步点，作用就是保证 此点之前的所有读写操作都执行完，才可以执行此点之后的操作。

它底层其实是 利用Unsafe类本地方法loadFence(),storeFence()，调用底层C++四大屏障：loadload()，storestore()，loadstore()，storeload()。
    
volatile变量不保证原子性，不适合参与到依赖当前值的运算
    
使用场景：1、单一赋值时。2、一次性标志。3、读远多于写的变量，读时volatile保证可见性，写时synchronized保证原子性。4、双重检查锁的单例模式，使用volatile禁重排，防止获取对象为空。

CAS是JDK提供的、通过硬件保证的非阻塞原子性操作：执行CAS操作的时候，会将内存位置的值与预期原值比较：如果相匹配，那么处理器会自动将该位置值更新为新值，如果不匹配，处理器不做任何操作，多个线程同时执行CAS操作只有一个会成功。

CAS的原子性实际是由CPU实现的，如果是多核系统，还会先给总线加锁，只有一个线程会对总线加锁成功。
Unsafe是CAS的核心类，由于Java方法无法直接访问底层系统，需要通过本地（native）方法来访问，Unsafe相当于一个后门，其内部方法操作可以像C的指针一样直接操作内存。
 
存在问题：1、长时间循环开销大。2、ABA问题。
如何解决：
AtomicStampedReference ： 维护一个对象引用以及一个整数“标记”，可以原子方式更新。携带版本号的引用类型原子类，可以解决ABA问题，可以记录修改过几次
AtomicMarkableReference ： 维护一个对象引用以及一个标记位，可以原子方式更新。一次性的，只能记录是否修改过，因为它将状态标记简化为了Boolean 的 true/false

AtomicInteger、AtomicBoolean、AtomicLong、AtomicIntegerArray、AtomicReference 
 
对象的属性修改原子类： 以一种线程安全的方式操作非线程安全对象内的某些字段。
AtomicIntegerFieldUpdater 原子更新对象中int类型字段的值
AtomicLongFieldUpdater 原子更新对象中Long类型字段的值
使用要求：1、更新的对象属性必须使用 public volatile 修饰符。 2、因为对象的属性修改类型原子类都是抽象类，所以每次使用都必须使用静态方法newUpdater()创建一个更新器，并且需要设置想要更新的类和属性。
 
原子操作增强类：
DoubleAccumulator、DoubleAdder、LongAccumulator、LongAdder
LongAdder只能用来计算加法，且从零开始计算，LongAccumulator提供了自定义的函数操作。

LongAdder的基本思路就是分散热点，将value值分散到一个Cell数组中，不同线程会命中到数组的不同槽中，各个线程只对自己槽中的那个值进行CAS操作，这样热点就被分散了，冲突的概率就小很多。如果要获取真正的long值，只要将各个槽中的变量值累加返回。

LongAdder在无竞争的情况，跟AtomicLong一样，对同一个base进行操作，当出现竞争关系时则是采用化整为零的做法，从空间换时间，用一个数组cells，将一个value拆分进这个数组cells。多个线程需要同时对value进行操作时候，可以对线程id进行hash得到hash值，再根据hash值映射到这个数组cells的某个下标，再对该下标所对应的值进行自增操作。当所有线程操作完毕，将数组cells的所有值和无竞争值base都加起来作为最终结果。

强引用：最常见，如一个对象赋值给一个引用变量，当对象被强引用变量引用时，处于可达状态，不可回收。
软引用：常用于内存敏感的程序，如高速缓存，内存够就保留，不够就回收。
弱引用：垃圾回收机制一运行就回收。
虚引用：和没引用一样，任何时候都可能被回收，常用于跟踪对象回收状态，对象被回收时通知。

假如有一个应用需要读取大量的本地图片：如果每次读取图片都从硬盘读取则会严重影响性能，如果一次性全部加载到内存中又可能造成内存溢出。

此时使用软引用可以解决这个问题：
用一个HashMap来保存  图片的路径  和  相应图片对象关联的软引用  之间的映射关系，在内存不足时，JVM会自动回收这些缓存图片对象所占用的空间，从而有效地避免了OOM的问题。

指不再会被使用的对象或者变量占用的内存不能被回收。

ThreadLocalMap中的Entry的key指向一个ThreadLocal，这个ThreadLocal就被WeakReference 包装成了一个弱引用。
 
当ThreadLocal的外部强引用t1被置为null时，根据可达性分析，这个ThreadLocal就会被回收，这样一来，ThreadLocalMap 中就会出现一个 key 为 null 的 Entry，在使用线程池的情况下，为了复用，我们是不会结束线程的，长时间就会造成内存泄露。

对象头：
     Mark Word：存储对象的 HashCode、分代年龄 和 锁标志位等。
     类型指针：指向类元数据的指针
实例数据：存放类（包含父类）属性，数组长度。
对齐填充：不必须存在，为了对齐8字节整数倍

在Java5以前，Synchronized是重量级的，因为monitor依赖操作系统的Lock，需要用户态和内核态之间的转换，效率较低。

Java6开始，引入了轻量级锁和偏向锁，让锁有个逐步升级的过程。
每个对象天生就是Monitor锁，如果一个java对象被某个线程锁住，则该java对象的Mark Word字段中LockWord指向monitor的起始地址，Monitor的Owner字段会存放拥有相关联对象锁的线程id。

1.无锁
2.偏向锁：
多线程下，锁总被同一个线程持有：在第一次获得锁时，记下偏向线程ID，以后不需要再次加锁和释放锁，而是直接比较对象头里面存储的偏向线程ID是否是它，是就直接进入，不是则意味着发生了竞争，需要锁升级。
偏向锁只有遇到其他线程尝试竞争偏向锁时，持有偏向锁的线程才会释放锁，线程是不会主动释放偏向锁的。
3.轻量级锁：
CAS自旋，Java6之前默认10次，之后变为自适应
4.重锁：大量线程竞争，冲突很高

锁消除：每个线程new自己new对象当做锁，相当于没加，没用
锁粗化：连续几个synchronized 使用同一个锁对象，编译器将他们合并加大范围

通过内置的FIFO队列来完成资源获取线程的排队工作，并通过一个int类变量表示持有锁的状态。

锁面向程序员，而同步器面向锁的实现者，而在JUC中，加锁就会导致阻塞，有阻塞就需要排队，实现排队必然就需要队列。

抢到资源的线程执行，抢不到的线程排队等候(仍然保留获取锁的可能且获取锁流程仍在继续)

AQS使用一个volatile的int型成员变量表示同步状态，把要去抢占资源的线层加入AQS的等待队列(CLH队列变体)，他将请求线程封装成一个Node，通过CAS、自旋以及 LockSupport.park() 的方式，维护state变量的状态，使并发达到同步的效果。

一个资源能够被多个读线程访问，或者被一个写线程访问，但是不能同时存在读写线程(读读共存，读写互斥)

子主题

虚拟主机：对 交换机 和 队列 逻辑隔离
交换机：接收生产者发来的消息，并分配给队列
队列：存储消息，消费者从这里取

一个连接包含多个信道，连接是线程共享的，信道是线程私有的
因为连接使用TCP连接，需要三握四挥，每个线程建立一个连接比较耗资源

简单模式
生产者将消息发送给队列，消费者从队列中获取消息队列

工作队列模式
消费者从一个变成了多个
 
广播模式
增加了交换机，生产者只生产了一条消息，它对应的所有消费者都能全部接收

1.异步处理
用户注册 -- 保存数据库 -- 发送短信 -- 发送邮件
用户将注册信息提交保存到数据库，然后将注册成功的消息保存到消息中间件，然后直接返回。其他服务从消息中间件获取消息，该发短信发短信，该发邮件发邮件。
 
2.应用解耦
订单系统下订单，库存系统减库存
如果订单系统直接调用库存系统，库存系统升级了，订单系统也要跟着升级。
可以让订单系统下完订单后，将订单信息发送给消息队列，库存系统实时订阅消息队列，有订单信息时自己分析参数减库存。
 
3.流量控制
大量请求时，全部处理业务，可能将资源耗尽
可以将请求先存储到消息队列里边，然后直接返回成功，其他业务服务订阅消息队列，根据它自己的消费能力挨个进行处理，防止宕机。

生产者与消息代理建立一条长连接，在连接里边开辟多条 channel来发送消息，每一个消息必须指定路由键，消息到达消息代理服务器，会交给交换机，交换机根据自己和消息队列的绑定关系，决定将消息放到哪个队列里边。

消费者与消息代理服务器建立长连接，连接里边有多个信道，用于监听消息队列，监听到消息来消费

direct
单播，点对点通信，路由键和队列完全匹配
fanout
广播到绑定它的所有队列
topic
部分广播模式，使用通配符匹配单词(#:0个或多个单词；*:一个单词)
headers

生产者投送消息给Broker保证
confirmCallback 确认回调，消息只要被broker接收到就会执行
Exchange交给Queue保证
returnCallback 回调，消息没有投递给指定的queue，触发这个失败回调
Queue到 消费者
ack确认机制，消费者从queue中成功拿到消息，会给Broker返回一个ack

问题：自动确认模式，如果消息收到一半宕机了，MQ会删除所有消息，导致数据丢失。所以我们采用手动确认方式，处理一个回复一个。一旦consumer宕机，所有 unacked 会回到ready。

解耦
多个子系统之间需要交互数据，就需要考虑哪些系统都需要这些数据？后边哪个系统不需要了或者哪个系统又需要了？需要数据的系统挂了怎么办？要不要重发？要不要把消息存起来?
管理这样的耦合关系，就可以用MQ
如果使用 MQ，A 系统产生一条数据，发送到 MQ 里面去，哪个系统需要数据自己去 MQ 里面消费。如果新系统需要数据，直接从 MQ 里消费即可；如果某个系统不需要这条数据了，就取消对 MQ 消息的消费即可。这样下来，A 系统压根儿不需要去考虑要给谁发送数据，也不需要考虑人家是否调用成功、失败超时等情况。
异步
A 系统接收一个请求，需要在自己本地写库，还需要在 BCD 三个系统写库，自己本地写库要 3ms，BCD 三个系统分别写库要 300ms、450ms、200ms。最终请求总延时是 3 + 300 + 450 + 200 = 953ms，就特别慢。
一般互联网类的企业，对于用户直接的操作，一般要求是每个请求都必须在 200 ms 以内完成，对用户几乎是无感知的。
如果使用 MQ，那么 A 系统连续发送 3 条消息到 MQ 队列中，假如耗时 5ms，A 系统从接受一个请求到返回响应给用户，总时长是 3 + 5 = 8ms，8s后直接返回，真快。
削峰
每天 0:00 到 12:00，A 系统风平浪静，每秒并发请求数量就 50 个。结果每次一到 12:00 ~ 13:00 ，每秒并发请求数量突然会暴增到 5k+ 条。但是系统是直接基于 MySQL 的，大量的请求涌入 MySQL，每秒钟对 MySQL 执行约 5k 条 SQL。
一般的 MySQL，扛到每秒 2k 个请求就差不多了，如果每秒请求到 5k 的话，可能就直接把 MySQL 给打死了，导致系统崩溃，用户也就没法再使用系统了。
但是高峰期一过，到了下午的时候，就成了低峰期，可能也就 1w 的用户同时在网站上操作，每秒中的请求数量可能也就 50 个请求，对整个系统几乎没有任何的压力。

如果使用 MQ，每秒 5k 个请求写入 MQ，A 系统每秒钟最多处理 2k 个请求，因为 MySQL 每秒钟最多处理 2k 个。A 系统从 MQ 中慢慢拉取请求，每秒钟就拉取 2k 个请求，不要超过自己每秒能处理的最大请求数量就 ok，这样下来，哪怕是高峰期的时候，A 系统也绝对不会挂掉。而 MQ 每秒钟 5k 个请求进来，就 2k 个请求出去，结果就导致在中午高峰期（1 个小时），可能有几十万甚至几百万的请求积压在 MQ 中。
这个短暂的高峰期积压是 ok 的，因为高峰期过了之后，每秒钟就 50 个请求进 MQ，但是 A 系统依然会按照每秒 2k 个请求的速度在处理。所以说，只要高峰期一过，A 系统就会快速将积压的消息给解决掉。

程序计数器：用于存放下一条指令所在单元的地址
 
虚拟机栈：线程私有，生命周期与线程相同。描述的是 Java 方法执行的线程内存模型，用来存储局部变量表、操作数栈、动态连接等
 
本地方法栈：和虚拟机栈相似，它是为虚拟机用到的本地方法服务
 
堆：线程共享，虚拟机启动时创建，目的是存放对象实例。根据垃圾回收机制划分为：新生代（Eden，s0，s1），老年代
 
 方法区：各线程共享，用于存储已被虚拟机加载的类型信息、常量、静态变量、即时编译器编译后的代码缓存等数据。
    jdk1.6，使用永久代实现方法区
    jdk1.7，将字符串常量池、静态变量，存放在堆上
    jdk8开始，用元空间代替永久代：元空间与永久代的区别：元空间不在虚拟机设置的内存中，而是使用本地内存

从一个new指令开始：
1.在常量池中定位这个类的符号引用
2.检查这个引用指向的类是否被加载过，没有才开始类加载
3.加载完后分配内存
4.然后初始化零值
5.设置对象头

内存规整：指针碰撞
不规整  ：维护一个空闲列表

会，方案如下：
1.采用 CAS 分配重试的方式来保证更新操作的原子性
2.每个线程在 Java 堆中预先分配一小块内存，也就是本地线程分配缓冲（TLAB），要分配内存的线程，先在本地缓冲区中分配，只有本地缓冲区用完了，分配新的缓存区时才需要同步锁定。

对象头：存hash码，分代年龄，锁信息和类型指针
实例数据：真正信息
对齐填充：占位

内存泄露：内存空间没有被正确释放
原因：
1.静态集合生命周期和JVM一致，它引用的对象不能被释放。
2.静态遍历引用的对象也不能被释放。
3.不再使用对象没有及时将对象设置为 null
4.ThreadLocal 使用不当
 
内存溢出：内存不够了

引用计数器：
在对象中添加一个计数器，每有一个地方引用它，计数器就加一，引用失效时减一，为0就说明是垃圾了

可达性分析：
将GC Roots作为初始存活对象集，从它出发，把所有能被引用的对象加到集合中，也就是标记，最后，未被标记的就是可以回收的。
 
GC Roots对象：栈中引用对象，静态属性引用对象，常量引用对象

对象被回收前调用该对象的finalize()方法，这是它逃脱死亡的最后一次机会

1.new的对象先放伊甸园区。此区有大小限制。

2.当伊甸园的空间填满时，程序又需要创建对象，JVM的垃圾回收器将对伊甸园区进行垃圾回收(Minor GC)，将伊甸园区中不再被其他对象所引用的对象进行销毁

3.然后将伊甸园中的剩余对象移动到幸存者0区。

4.如果再次触发垃圾回收，此时上次幸存下来的放到幸存者0区的，如果没有回收，就会放到幸存者1区。

5.如果再次经历垃圾回收，此时会重新放回幸存者0区，接着再去幸存者1区。

6.啥时候能去养老区呢?可以设置次数。默认是15次。可以设置参数: -XX:MaxTenuringThreshold=进行设置。

7.在养老区，相对悠闲。当养老区内存不足时，再次触发GC: Major GC，进行养老区的内存清理。

8.若养老区执行了Major GC之后发现依然无法进行对象的保存，就会产生OOM异常

标记-清除算法：
标记阶段，在可达对象的对象头中标记
清除：对堆内存从头到尾进行线性的遍历，如果发现某个对象在其Header中没有标记为可达对象，则将其回收
(清除就是把需要清除的对象地址保存在空闲的地址列表里，下次有新对象需要加载时，判断垃圾的位置空间是否够，如果够就存放)
缺点：会产生碎片，GC时需要停顿，效率不高

复制算法：
将活着的内存空间分为两块，每次使用其中一块。在垃圾回收时，将正在使用的内存中的存活的对象复制到未被使用的内存块中，之后清除正在使用的内存块中的所有的对象，交换两个内存的角色，最后完成垃圾回收
它实现简单不会出现碎片，但浪费内存空间

标记压缩算法：
标记：从根节点开始标记所有被引用的对象
清除：将所有的存活对象压缩在内存的一端，按照顺序排放，之后清理边界外所有的空间
最终效果等同于标记清除算法执行完成后，再进行一次内存碎片整理。

分代收集算法：
不同生命周期的对象可以采取不同的收集方式，以便提高回收效率
新生代的存活对象比较少：适合复制算法
老年代使用：标记-整理算法

Minor GC：指目标只是新生代的垃圾收集，Eden满时触发

Major GC：指目标只是老年代的垃圾收集

Full  GC：收集整个 Java 堆和方法区的垃圾收集，触发：Young GC 之后老年代空间不足；System.gc()命令

长期存活对象：分代年龄达到15（默认可修改）
大对象直接进入老年代

单线程收集器
进行垃圾收集时，必须暂停其他所有工作线程，直到垃圾收集结束（STW）

新生代：标记-复制算法
老年代：标记-压缩算法

Serial 收集器的多线程并行版本，使用多条线程进行垃圾收集。

基于标记-复制算法实现，能够并行收集

它主要关注的是垃圾收集的吞吐量(单位时间处理请求的数量)

Serial， Parallel 的老年代版本，采用标记-压缩算法

并发标记清除收集器，jdk1.5推出，它第一次实现了让垃圾收集线程与用户线程同时工作，它是老年代的收集器，采用标记-清除算法。
 
初始标记：仍是STW，仅标记GC Roots直接关联的对象
并发标记：从GC Roots直接对象开始全局遍历，时间较长但无需停顿
重新标记：STW，标记并发标记阶段产生对象
并发清除：并发清理死亡对象
 
 优点：并发收集，低延迟
 缺点：
 会产生碎片
 在并发阶段会占用一部分线程导致应用程序变慢
 如果并发阶段产生垃圾对象，CMS无法进行标记，没有及时回收

区域化分代式，在延迟可控的情况下，获得尽可能高的吞吐量
 
他把堆分成很多不相关的区域，使用不同的region表示Eden，s0，s1，老年代等，G1跟踪各个region里面垃圾堆积的价值大小，在后台维护一个优先列表，每次根据允许的收集时间，优先回收价值最大的Region，避免整堆收集
 
初始标记：标记了从 GC Root 开始直接关联可达的对象，STW执行。
并发标记：并发执行，从 GC Root 开始递归扫描整个堆里的对象图，找出要回收的对象。
最终标记：STW，标记再并发标记过程中产生的垃圾。
筛选回收：制定回收计划，选择多个 Region 构成回收集，把回收集中 Region 的存活对象复制到空的 Region 中，再清理掉整个旧 Region 的全部空间。需要 STW。
 
优点：
并行并发
分代收集兼顾年轻代与老年代
region之间用复制算法，整体可以看做是标记压缩算法，避免了内存碎片
可预测停顿时间

1、如果一个类加载器收到了类加载请求，它并不会自己先去加载。而是把这个请求委托给父类的加载器去执行
2、如果父类加载器还存在其父类加载器，则进一步向上委托，依次递归，请求最终将达到顶层的启动类加载器
3、如果父类的加载器可以完成类加载任务，就成功返回，倘若父类加载器无法完成此加载任务，子加载器才会尝试自己去加载
 
作用：
避免类的重复加载
保护程序安全，防止核心API被篡改

一致性，可用性，分区容错性

分布式系统分区是必然存在的，在分区容错的前提下， ⼀致性和可⽤性是⽭盾的。

BASE理论：
基于CAP演化而来，核心思想是 即便不能达到强一致性，也可以根据应⽤特点采⽤适当的⽅式来达到最终⼀致性的效果。

同⼀个接⼝，多次发出同⼀个请求，请求的结果是⼀致的。
 
问题情景：
1.提交form表单快速点了两次，表中出现两条相同记录，只是id不同
2.接口超时重试机制，其实可能成功了
3.mq消费者有时会读取到重复消息，也会产生重复数据

1.insert前先select
2.加唯一索引，重复插入会抛异常，我们捕获这个异常
3.加悲观锁：更新时把对应行数据锁住，同⼀时刻只允许⼀个请求获得
锁，其他请求则等待。缺点是获取不到锁就报失败了。
4.加乐观锁：表中增加version字段，在更新前，先查询⼀下数据，将version也作为更新的条件，同时也更新version
5.状态机：有状态的业务(订单：下单，已支付，完成等)，可以限制状态流动实现幂等
6.分布式锁
7.token机制：请求接⼝之前，需要先获取⼀个唯⼀的token，再带着这个token去完成业务操作，服务端根据这个token是否存在，来判断是否是重复的请求。

1.重载

2.重写

3.抽象类与接口

4.为什么重写 quals 时必须重写 hashCode ⽅法？

5.深拷贝和浅拷贝

6.创建对象的方式

7.String 和 StringBuilder、StringBuffer

8.String s = new String("abc") 创建了几个对象？

9.intern 方法

10.反射

11.Java8新特性

12.集合容器：快速失败和安全失败

13.流的特性

map

List

Set

Queue

客户发起请求 --> MySQL接收请求，三次握手建立TCP连接 
--> 身份认证，从线程池分配交互线程 --> 解析SQL语句，创建语法树 
--> SQL优化，生成执行计划 --> 执行器调用存储引擎api --> 文件系统读取存储数据

InnoDB(5.5后默认)：
支持事务，支持外键，支持行级锁，索引是聚簇索引，数据结构是 B+树
8.0前两张表保存(1表结构，2数据和索引)
8.0合并为了一张表

MyISAM：
不支持事务，不支持外键，只支持表级锁，索引为非聚簇索引，数据结构是B树
崩溃后无法安全恢复
保存了三张表，访问快，适合主要读的业务
MyISAM索引文件和数据文件分离，索引仅保存数据地址，它的索引都是非聚簇的，每次都要进行一次回表，并且回表是根据地址直接去拿，比较快速

索引是一种数据结构，存储引擎用它来加快查询效率，减少磁盘I/O次数。
缺点：
创建维护耗费时间空间，修改表数据也要维护，降低更新表的速度。

表中的数据以页为单位存储，表中的每条记录以单链表连接，页之间通过双向链表连接

当数据量少时，可以被放在一个页中：如果按照主键查找，主键一般是递增的，可以使用二分查找；如果以其他列作为条件搜索，只能遍历，效率较差。

当数据量大点，一页存不下时，第一步就需要先定位页，然后按上述查找。

如果没有索引，就不能快速定位所在的页，只能从第一页开始按顺序找。

基于这种情况，考虑可以给所有的页建立一个目录项，让目录项连续依次递增，每个目录项记录页的最小记录和页号，就可以利用二分法查找目录项，快速定位到所在页。

随着数据的增大，目录项越来越多难以管理，考虑将目录项以单链表的方式存储，所有目录项也存储到一个页中，把它叫做目录页。

数据再增大，导致一个目录页存不下，考虑将目录项放在多个目录页中，目录页之间逻辑连续，采用双向链表链接。

当目录页大于一个时，考虑将目录页再向上抽取一个更高级的页。

这样就一步步演化出了B+树

B+树 非叶子节点仅用于索引，不保存数据记录，跟记录有关的信息都放在叶子节点中。而B树中，非叶子节点既
保存索引，也保存数据记录。

聚簇索引：
所有完整用户记录都存储在叶子节点，记录之间单向链表相连，索引即数据，数据即索引
这种索引自动创建，数据访问快，无需回表，但插入速度严重依赖插入顺序，更新主键代价较高

非聚簇索引（二级索引）：
可以有多个，不保存完整记录，需要回表操作

联合索引：同时为多个列建立索引，本质上也是二级索引

从功能逻辑上来说，分为：普通索引、唯一索引、主键索引、全文索引。
按照物理实现来分，分为：聚簇索引 和 非聚簇索引。
按照作用字段个数来分，分成：单列索引 和 联合索引。

1.唯一性约束的字段
2.频繁使用where查询的字段
3.经常GROUP BY 和 ORDER BY 的列
4.UPDATE，DELETE 时的 where 条件列
5.DISTINCT的字段
6.多表JOIN连接时创建索引注意
   连接表的数量尽量不超过3张，每加一张表就相当于嵌套一次循环
   对 where 条件创建索引
   用于连接的字段创建索引
7.尽量给数据类型小的列添加索引，节省空间，让一页存在更多记录，比较速度页更快
8.使用区分度高的列作为索引
9.联合索引时，使用最频繁的列放在联合索引的左侧

1.where，group by ，orderby 条件使用不到的字段不要加索引
2.数据量小的表不要添加索引
3.有大量重复数据的列不要添加索引
4.经常更新的表尽量少创建索引
5.不建议使用无序的值作为索引
6.不再使用或很少使用的索引及时删除

1.观察服务器是否存在周期性波动，是的话可以尝试加缓存或者调整缓存失效策略
2.开启慢查询日志
3.分析SQL语句：EXPLAIN, SHOW PROFILE
4.如果SQL等待时间较长：调整服务器参数
5.如果SQL执行之间较长：优化索引，SQL语句本身，表设计
6.还不行考虑达到瓶颈，考虑读写分离，分库分表

定位问题：
用户反馈、日志分析、系统监控（服务器资源监控，数据库内活动会话监控）

调优步骤：
首先，要选择适合的DBMS
第二，优化表设计：表间关系，存储引擎，三范式和反范式化，数据类型选择
第三，逻辑优化：SQL语句
第四，物理优化：索引的创建和使用
第五，考虑使用缓存
第六，库级优化：读写分离，分库分表

数据库结构优化：冷热分离，增加中间表，冗余字段，优化字段数据类型

1.最佳左前缀规则：对于多列索引，过滤条件要使用索引必须按照索引建立时的顺序，依次满足，一旦跳过某个字段，索引后面的字段都无法被使用。

2.计算，函数，类型转换导致索引失效

3.范围条件右边的列索引失效：所以在创建索引时，务必把涉及范围查找的字段放在最后

4.不等于索引失效

5.is null可以使用索引，is not null无法使用索引

6.like以通配符%开头索引失效

覆盖索引：一个索引包含了满足查询结果的数据就叫做覆盖索引。

好处：避免回表，可以把随机IO变成顺序IO加快查询效率（覆盖索引是按键值的顺序存储的）

索引下推：key1是索引，如下查询 EXPLAIN SELECT * FROM s1 WHERE key1 > 'z' AND key1 LIKE '%a';

优化器会 先用索引查询条件 key1 > 'z'，不回表，继续在这些索引中过滤条件 key1 LIKE '%a'，最后只回表一次

ICP可用于InnoDB 和 MyISAM，对于InnoDB表，ICP仅用于二级索引，覆盖索引时不支持ICP

1.每个字段原子不可再分
2.不能产生部分依赖（所有非主键字段完全依赖主键）
3.不能产生传递依赖（数据表中的每一个非主键字段都和主键字段直接相关）

原子性：事务不可再分，要么同时成功，要么同时失败
一致性（语义上）：事务执行前后，数据从一个 合法性状态 变换到 另外一个合法性状态
隔离性：一个事务的执行不能被其他事务干扰
持久性：一个事务一旦被提交，它对数据库中数据的改变就是永久性的

隔离级别
读未提交：问题：脏读、幻读、不可重复读
读已提交：解决：脏读。 问题：幻读、不可重复读
可重复读（mysql默认）：解决：脏读、不可重复读。 问题：幻读
序列化读：性能低

事务的隔离性由锁机制实现，而事务的 原子性、一致性和持久性 由事务的 redo日志 和 undo日志 来保证，
都是存储引擎层生成的日志。

redo日志：重做日志，保证事务持久性
记录的是物理级别上页的修改，主要为了保证数据的可靠性

InnoDB以页存储，访问页之前，会先把磁盘上的页缓存到Buffer Pull，缓存池中的脏页以一定的频率刷盘；
叫 checkPoint机制，它不是每次变更就触发，所以如果刚提交到缓存还没刷盘宕机了，这些数据就丢失了；
想要保证数据可靠性，粗暴方法是只要内存中数据修改了就立即刷盘，但这样会导致仅修改了一个字节，就
不得不刷新整个页，或者一条修改语句修改了不相邻的多个页，就会多次随机IO
这时redo日志就来了，思路是：不频繁刷盘，而是先将所做的修改保存到一个文件里边

过程：给内存读数据 -> 生成 redo log buffer -> commit追加到 redo log file -> 定期刷新到盘

undo日志：回滚日志，保证事务原子性、一致性
记录的是逻辑操作日志（逆过程），用于回滚和MVCC（一致性非锁定读）

在事物更新数据之前，有一步写入 undo log 的操作，保证事务原子性
写undo log 时，会先申请一个undo页，为每一个事务申请undo页比较浪费内存，所以undo页设计为可重用的
当事务提交时，先判断当前undo页是否可重用（使用空间是否小于3/4）

注意区分binlog，bin log是数据库层产生的，一个事物过程中，会一直不断的往redo log顺序记录，而bin log不会记录，直到这个事务提交，才会一次写入到bin log文件中。

通过数据行的多个版本管理来实现数据库的并发控制，不用等待一个事务释放锁，就能看到它被更新之前的值

这里有两个概念：
快照读：基于MVCC，不加锁，提高并发性能，读到的数据不一定是最新的
当前读：读到的是最新数据，会加锁

MVCC实现依赖：隐藏字段，Undo log，read view
隐藏字段两个：当前修改记录事务的ID，undo日志回滚指针（数据改动会记到undo日志，每条undo日志也都有一个回滚指针属性，可以将这些undo日志都连起来，串成一个链表，就是版本链）
read view：历史快照，记录多个事务对同一数据修改产生的多个版本

隔离级别：读已提交和可重复读使用到了MVCC（读未提交和序列化用不着）

ReadView结构：
creator_trx_id：创建这个ReadView的事物ID
trx_ids：创建ReadView时当前系统的活跃的读写事物列表
up_limit_id：活跃事物中最小的ID
low_limit_id：已提交事物最大的事物ID（1，2，3事物，1、2未提交3已提交，最大事物ID为3+1=4）

ReadView规则：
1.被访问事务id 与 ReadView中事务创建者id 相同，表示访问自己修改过得数据，可以访问
2.被访问事务id 小于 ReadView中最小未提交事务id，表示被访问事务已提交，可以访问
3.被访问事务id 大于等于 ReadView中最大已提交事务id，不可访问
4.被访问事务id 在 最小未提交事务id 和 最大已提交事务id 之间，需要比较 活跃事务列表，在列表中，不可访问，不在，可以访问。


过程：
获取ReadView -> 查询数据 -> 对比 -> 如果不符合ReadView规则，顺着版本链从undo log中找历史快照 -> 如果找到最后一个版本还不可见，说明此记录对该事务完全不可见 -> 最后返回符合规则的数据。

慢查询日志：记录时间超过long_query_time的查询
通用查询日志：记录所有连接所有指令，用于复原实际场景或审计
错误日志：记录出现的问题
二进制日志：从服务器用来存放主服务器二进制日志内容的一个中间文件
中继日志：只在主从服务器架构的从服务器上存在

怎么保证binlog 和 redolog 一致性：两阶段提交，将 redolog 的写入拆成 预备 和 提交 两个阶段

作用：
读写分离（读多写少）
数据备份（热备份）
实现高可用（冗余机制）

原理：
基于binlog进行数据同步，基于三个线程，一个主库线程，两个从库线程
主库线程：从库连接时，主库将二级制日志发送给从库
从库I/O线程：连接到主库，向主库发送请求更新binlog，本拷贝到本地中继日志
从库SQL线程：读取从库中继日志并执行

过程（三步）：
主库记录binlog -> 从库连接主库将binlog拷贝到自己中继日志 -> 从库重做中继日志事件

如何解决数据一致性问题？
异步复制：客户端提交COMMIT之后不需要等从库返回任何结果，而是直接将结果返回给客户端，
这样不会影响主库写效率，但可能会存在主库宕机，而Binlog还没有同步到从库的情况

半同步复制：客户端提交COMMIT之后不直接将结果返回给客户端，而是等待至少有一个从库接收到了Binlog，并且写入到中继日志中，再返回给客户端。
MySQL5.7增加了一个参数，对应答的从库数量进行设置，默认为1

上边两个都无法最终保证数据一致性
组复制：基于Paxos协议的状态机复制
将多个节点共同组成一个复制组，读写事务想要进行提交，必须要经过组里“大多数人”（对应Node节点）的同意（N／2＋1），这样才可以进行提交，而不是原发起方一个说了算。

而针对只读事务则不需要经过组内同意，直接COMMIT即可。

在一个复制组内有多个节点组成，它们各自维护了自己的数据副本，并且在一致性协议层实现了原子消息和全局有序消息，从而保证组内数据的一致性。

3.x  单线程
4.x  加了异步删除（惰性删除：避免删除大文件卡顿）
6.x  多线程IO

基于内存操作
单线程数据结构简单
多路复用和非阻塞 I/O
避免不必要的上下文切换和线程竞争

对于 Redis 系统来说，主要的性能瓶颈是内存或者网络带宽而并非 CPU。

通过监测文件的读写事件后再通知线程执行相关操作，保证Redis的非阻塞IO能顺利执行的机制。
多路：多个socket连接
复用：复用一个线程
 
 多路复用主要有三种技术：select，poll，epoll
 epoll是目前最好用的多路复用技术，可以让单个线程高效的处理多个连接请求。

Redis 6.0 将网络数据读写、请求协议解析通过多个IO线程来处理，对于真正的命令执行来说，仍然使用主线程操作。多个线程IO解决网络IO问题，单个工作线程保证安全性。
 
多线程机制默认关闭，启动需要在配置文件中开启，线程数配置需小于核数。

抖音直播连续点赞，微信公众号喜欢作者，阅读量

Map<String,Map<Object,Object>>
京东早期手机购物车
加入购物车  ：hset shopcar : uid 1024 334488 1
增加商品数量：hincrby shopcar : uid 1024 334488 1
商品总数    ：hlen shopcar : uid 1024
全选        : hgetall shopcar : uid 1024

双端链表结构
微信公众号订阅的消息：关注了A，B两个公众号，A发布文章01，B发布文章02，lpush likeArtical ：用户id 01 02
商品评论列表：某商品被不同用户评论 【items:comment:1001】为key
lpush items:comment:1001 {"id":1001,"name":"huawei","date":1600484283054,"content":"评论"}

无重复容器
抽奖：SPOP，随机弹出并删除 ； SRANDMEMBER，随机弹出不删除
朋友圈点赞：点赞，取消赞，统计数量，遍历展示
微博好友关注社交关系：共同关注(交集)
QQ可能认识的人：先交集，再差集

sdiff a b   : 差集：属于a不属于b
sinter a b  : 交集
sunion a b  : 并集

排行榜
根据商品销售对商品进行排序显示：
   zadd goods:sellsort 9 1001 15 1002
   ZRANGE goods:sellsort 0 10 withscores
抖音热搜

在⾯对需要展示最新列表、排行榜等场景时，如果数据更新频繁或者需要分页显示，建议使⽤ZSet

用String类型作为底层数据结构实现的一种统计二值状态的数据类型，本质是由多个二进制位组成的数组
用git获取，得到对应ASCII码值

场景：二值统计，如是否签到，广告是否被点击，日活
签到日历实现：如果每个用户每天一条数据，大体量下很可怕。可以使用bitmap，一个月最多31天，使用int刚好32位，一个int类型可以搞定一个月的记录。
bitlen,统计字节：8位算一个字节，超过8位扩容
bitcount,统计多少个1

UV：独立访客，也就是客户端IP（去重）
PV：页面浏览量（不用去重）
DAU：日活
MAU：月活

去重统计功能的基数估计算法(基数：一组数去除重复的)，它不保存数据，只记录数量，会有0.81%的误差。
实践，天猫首页亿级UV统计

1、集群要发送心跳包，心跳包包含结点完整配置，其中就有插槽配置，如果槽位为65536，发送心跳信息的消息头达8k，发送的心跳包过于庞大，浪费带宽。
2、Redis集群结点不会超过1000个，16384个槽够用了。
3、槽位越小，节点少的情况下，压缩比高，容易传输

以给定的经纬度为中心，找出某一半径内的元素
实战：美团地图位置附近的酒店推送

是一个很长的二进制数组(初值为0)+一系列随机hash算法映射函数，主要用于判断一个元素是否在集合中。

特点：
1、高效插入查询，占用空间少，但返回结果不确定
2、判断结果存在，不一定存在，判断结果不存在，一定不存在
3、可添加元素，不可删除元素(删元素误判率增加)
4、误判只会发生在过滤器没有添加过的元素

场景：
解决缓存穿透：
 -先查询Redis，没有，再查询数据库，也没有，叫缓存穿透。
 -大量请求穿透查询数据库，会把他拖垮。
 -可将已存在数据的key存到布隆过滤器中，请求时先到布隆过滤器查询是否存在，不存在直接返回，存在才去Redis，MySQL查询。

原理：
添加key时，使用多个hash函数对进行哈希运算，得到多个位置，将数字中这几个对应的位置都置为1，查询时，对key多次哈希的位置都为1，则可能存在，有一个为0，就一定不存在。
所以结论是：有，可能有，无，一定无。

查询一条数据，这条数据既不在Redis，也不再MySQL，但是请求每次都会打到数据库，导致数据库压力暴增，称为缓存穿透。
解决：
1、一旦发生穿透，可以根据查询的数据，在Redis中缓存一个空值或者缺省值，避免下次还打到数据库
2、Google的布隆过滤器Guava，只能单机用：默认误判率0.03，使用了5个Hash函数，误判率可以自定义，但误判率越小，效率越低。
3、Redis布隆过滤器

大量请求查询一个key，这个key失效了，全部打到了MySQL，导致数据库压力剧增。
解决：
1、对于访问频繁的热点key，干脆就不设置过期时间
2、互斥独占锁防止击穿
   
案例：淘宝聚划算实现(24h高并发) + 防止缓存击穿
实现：Redis的list，采用定时器扫描数据库，将参与聚划算活动的特价商品新增进入redis的list中，分页从Redis读到页面展示。活动商品到期时删除Redis数据，从数据库读取新一轮活动商品。
隐患：在更新活动商品时，删除和插入没有原子性，高并发下，更新时间容易出现热点key失效，缓存击穿。
解决：双缓存，定时轮询，互斥更新，差异失效时间
开辟两块缓存A和B，AB失效时间不同，更新时先更新B再更新A

独占性：任何时刻只能有且仅有一个线程持有
高可用：集群环境下不能因为某个结点挂了出现获取锁或释放锁失败
防死锁：超时控制，兜底方案
不乱抢：自己加锁只能自己释放
可重入：同一个节点的同一个线程如果获得锁之后，它也可以再次获取这个锁。

CAP：Redis单机CP，  Redis集群AP
  zookeeper集群CP，  Eureka集群AP

1、在单机环境下，可以使用synchronized或Lock加锁
问题：在分布式系统中，竞争线程可能不在同一节点上，所以需要一个让所以线程都能访问到的锁(Redis或zookeeper)。

2、可以使用setnx分布式锁
问题：如果出异常的话，可能无法释放锁，所以必须在代码finally释放锁
3、问题：如果服务器直接挂了宕机了，没有走到finally，也不能释放锁，需要给key加一个过期时间
4、问题：保证自己的锁自己删，别人不能动，还需要在finally中判断value。
5、问题：finally块的判断和删除锁不是原子的，可以使用lua脚本保证原子性。
 
6、这样也有问题，不能确保redisLock过期时间大于业务执行的时间，如何续期？
客户端A获取锁，通过exists判断，如果锁不存在，加锁成功，在获取锁成功后，会启动一个 watchdog 后台线程定时任务，每隔10秒检查一次，如果客户端A还持有锁key，那么就会不断的延长锁key的生存时间，默认每次续命又从30秒新开始。
当锁不是当前线程的时候，证明其他线程持有锁了，返回当前锁的过期时间，加锁失败。

单机：
加锁 set/setnx + 过期时间
解锁 先判断key值与锁值是否相等，然后再删 + lua脚本
 
多机：
一主多从缺点：线程1获取到锁，写入master，还没同步给slave呢master就故障了，另一slave上位，线程2又拿到了锁，所以两个线程获取到锁了。

RedLock：多主模式  N = 2X + 1

看门狗 + 三段Luau脚本：
首次新建，同线程可重入，然后根据返回时间决定锁还有多久过期，过期后触发unlock()和消除分布式锁看门狗

立即删除：能保证内存数据最大新鲜度，但性能消耗大，对CPU不友好，用处理器性能换取存储空间。
 
惰性删除：数据到达过期时间，不做处理。等下次访问该数据时，如果未过期，返回数据 ；发现已过期，删除，返回不存在。对内存不友好，用存储空间换取处理器性能。
 
定期删除：每隔一段时间执行一次删除过期键操作，随机抽取key是否过期删除，并通过限制删除操作执行的时长和频率来减少删除操作对CPU时间的影响。
难点：合理地设置删除操作的执行时长和执行频率。
缺点：随机抽取，可能会有漏网之鱼

以上三种都不完美，所以出现了缓存淘汰策略。。。

2个纬度：
 过期键中筛选
 所有键中筛选
4个方面：
 LRU
 LFU
 random
 ttl
 
默认为：noeviction: 不会驱逐任何key
我们用：allkeys-lru: 对所有key使用LRU算法进行删除

redis 是 key-value 数据库，每个键值对都会有一个dictEntry，里面是指向key、value的指针，next指向下一个dictEntry，其中key类型一般为字符串，value 类型则为redis对象(redisObject)
 
Redis定义了redisObject结构体来表示string、hash、list、set、zset等数据类型。它是一个结构体，里边有 type，encoding，lru(最近访问时间戳)，refcount，ptr(指向真正数据的指针)
 
bitmap,hyperLogLog 实质是String
GEO实质是Zset

Redis没有直接复用C语言的字符串，而是新建了属于自己的结构--SDS，Redis里所有包含字符串的键值队都由SDS实现(所有键+包含字符串的值)

String有三种编码格式：
int：保存long型的有符号整数，8个字节64位，但如果是浮点数，Redis内部会自动将其转化为字符串，再保存。
embstr：SDS简单动态字符串，保存长度小于44字节的字符串
raw：保存长度大于44字节的字符串

SDS属性：len，alloc，flags，buf[]

好处：
1.字符串长度处理
C语言用char数组保存字符串，获取字符串长度O(n)，SDS直接读取O(1)；
2.内存重新分配
C语言可能下标越界或内存溢出
SDS可空间预分配，SDS 修改后，len 长度小于 1M，那么将会额外分配与 len 相同长度的未使用空间。如果修改后长度大于 1M，那么将分配1M的使用空间。
SDS惰性空间释放，SDS 缩短时并不会回收多余的内存空间，而是使用 free 字段将多出来的空间记录下来。如果后续有变更操作，直接使用 free 中记录的空间，减少了内存的分配
3.二进制安全
C语言以 '\0' 作为结束，可能丢失数据，SDS根据 len 长度来判断字符串结束，解决二进制安全的问题。

Redis 启动时会预先建立 10000 个分别存储 0~9999 的 redisObject 变量作为共享对象，这就意味着如果 set字符串的键值在这之间的话，可以 直接指向共享对象 而不需要再建立新对象，此时键值不占空间！
-------------------
set k1 v1时，底层调用setCommand()方法，当v1长度小于等于20时，Redis会将键值转化为long型来进行存储，对应int编码类型，如果其值在0到10000，直接从共享数据拿，否则直接赋值，节省指针开销；

当v1长度大于20小于等于44时，Redis采用embstr编码，将字符串sds结构体与其对应的 redisObject 对象分配在同一块连续的内存空间，就像嵌入一样，避免内存碎片；

当v1长度大于44时，redis将采用raw编码，此时动态字符串sds的内存与其依赖的redisObject的内存不再连续了。
-------------------
对于embstr,由于其实现是只读的,因此在对embstr对象进行修改时,都会先转化为raw再进行修改。因此,只要是修改embstr对象,修改后的对象一定是raw的,无论是否达到了44个字节。

底层结构为：ziplist + hashtable
当 哈希对象保存的键值对数量小于 512 个，且所有的键值对的健和值的字符串长度都小于等于 64byte时用 ziplist，反之不满足就用hashtable，可升级不可降级。

本质上是字节数组，可以将其分成三个部分：header + entry集合 + end
 
zlentry结构：prev_len + encoding + entry-data
prev_len：前一个节点的长度，值可以为1或者5，前一个entry长度小于254，值为1，否则为5。（为什么没有255，因为zlend默认255，其他地方就不能用了）
 
压缩列表的遍历：
通过指向表尾节点的位置指针p1, 减去节点的previous_entry_length，得到前一个节点起始地址的指针。

ziplist是一个经过特殊编码的双向链表，它不存储指向上一个链表节点和指向下一个链表节点的指针，而是存储上一个节点长度和当前节点长度，通过牺牲部分读写性能，来换取高效的内存空间利用率，节约内存，是一种时间换空间的思想。只用在字段个数少，字段值小的场景里面。
 
优势：
1.普通的双向链表会有两个指针，在存储数据很小的情况下，我们存储的实际数据的大小可能还没有指针占用的内存大，得不偿失。ziplist 是一个特殊的双向链表，没有维护双向指针prev next，而是存储上一个 entry的长度和 当前entry的长度，通过长度推算下一个元素在什么地方。牺牲读取的性能，获得高效的存储空间。
 
2.链表在内存中一般是不连续的，遍历相对比较慢，而ziplist可以很好的解决这个问题，ziplist将一些必要的偏移量信息记录在了每一个节点里，使之能跳到上一个节点或下一个节点。
 
3.头节点有一个参数 len，用来记录链表长度的。因此获取链表长度时不用再遍历整个链表，直接拿到len值就可以了，这个时间复杂度是 O(1)。

在Redis中，hashtable被称为字典，它是一个数组 + 链表结构，可以实现O(1)复杂度的读写操作。

list底层用quicklist来存储，quicklist是一个双向链表，双向链表的每个节点都是一个ziplist

Redis用 intset 或 hashtable 存储set。如果元素都是整数类型，就用 intset 存储。如果不是整数类型，就用 hashtable（数组+链表的存来储结构）。key就是元素的值，value为null。

当有序集合中包含的元素数量超过配置值（默认为128），或者有序集合中新添加元素的 member 的长度大于配置值（默认为 64 ）时，redis会使用跳跃表作为有序集合的底层实现，否则会使用ziplist。

skiplist是一种以空间换取时间的结构，由链表 + 多级索引组成，是可以实现二分查找的有序链表。
实现：索引升级，两两取首。
跳表在数据量较大的情况下才能体现出来优势，而且应该是读多写少的情况下才能使用，所以它的适用范围应该还是比较有限的。
缺点：维护成本相对较高，新增或者删除时需要把所有索引都更新一遍。

1、当 master 主服务器上的数据发生改变时，则将其改变写入二进制事件日志文件中(BinaryLog)；
2、salve 从服务器会在一定时间间隔内对 master 主服务器上的二进制日志进行探测其是否发生过改变，如果发生了改变，则开始一个 I/O Thread 请求 master 二进制事件日志；
3、同时 master 主服务器为每个 I/O Thread 启动一个dump  Thread，用于向其发送二进制事件日志；
4、slave 从服务器将接收到的二进制事件日志保存至自己本地的中继日志文件中(RelayLog)；
5、salve 从服务器将启动 SQL Thread 从中继日志中读取二进制日志，在本地重放，使得其数据和主服务器保持一致；
6、最后 I/O Thread 和 SQL Thread 将进入睡眠状态，等待下一次被唤醒；

canal 模拟 MySQL slave 的交互协议，伪装自己为 MySQL slave ，向 MySQL master 发送dump 协议。
MySQL master 收到 dump 请求，开始推送 binary log 给 slave (即 canal )，canal 解析 binary log 对象(原始为 byte 流)

如果redis中有数据，需要和数据库中的值相同；
如果redis中无数据，数据库中的值要是最新值。

给缓存设置过期时间，是保证最终一致性的解决方案。
 
我们可以对存入缓存的数据设置过期时间，所有的写操作以数据库为准，对缓存操作只是尽最大努力即可。也就是说如果数据库写成功，缓存更新失败，那么只要到达过期时间，则后面的读请求自然会从数据库中读取新值然后回填缓存，达到一致性，切记以mysql的数据库写入库为准。

什么时候同步直写策略：
小数据，某条、某一小挫热点数据，要求立刻变更，可以前台服务降级一下，后台马上同步直写。
 
什么时候异步缓写策略：
1.正常业务,马上更新了mysql,可以在业务上容许出现1个小时后redis起效。
2.出现异常后,不得不将失败的动作重新修补,不得不借助kafka或者RabbitMQ等消息中间件,实现解耦后重试重写。

1.先更新数据库，再更新缓存
问题：数据库更新成功，Redis更新失败的话，会产生数据不一致，从Redis读到脏数据。
 
2.先删除缓存，再更新数据库
问题：
A线程先成功删除Redis缓存，然后去更新MySQL，在MySQL还没有更新好时，B要来读取缓存：在高并发下，会出现缓存击穿；在低并发下，B可能会读到数据库未更新的旧数据，并将它写回缓存，A线程白干了，出现了数据不一致，缓存中是B回写的旧值，MySQL是A更新的新值。
解决：延时双删策略：当A线程更新完成MySQL之后，延迟一会(大于B线程读取数据再写入缓存的时间)，再删除一次缓存。

延迟时间：需要根据读数据业务逻辑估算，再加上百毫秒，确保读请求结束。
MySQL采用主从读写分离，请求B去从库查询，这时，还没有完成主从同步，因此查询到的是旧值怎么办？睡眠时间修改为在主从同步的延时时间基础上，加几百ms
这样等一会导致吞吐量降低，怎么办？第二次删除新起一个线程去执行，异步删除。
 
3.先更新数据库，再删除缓存(一般用这个)
问题：更新数据库后，假如缓存删除失败或者来不及，导致请求再次访问redis时缓存命中，读取到的是缓存旧值。
解决：canal思想：先更新数据库，将操作记录到binlog日志，订阅binlog日志，非业务代码获取操作信息，然后删除缓存，删除失败时将这些信息发到消息队列，从消息队列中获取数据重试。

Redis利用epoll来实现IO多路复用，将连接信息和时间放到队列中，依次放到文件事件分派器，事件分派器将事件分发给事件处理器。

I/O 多路复用机制：就是说通过一种机制，可以监视多个描述符，一旦某个描述符就绪，能够通知程序进行相应的读写操作。这种机制的使用需要 select 、 poll 、 epoll 来配合。多个连接共用一个阻塞对象，应用程序只需要在一个阻塞对象上等待，无需阻塞等待所有连接。当某条连接有新的数据可以处理时，操作系统通知应用程序，线程从阻塞状态返回，开始进行业务处理。

Redis 服务采用 Reactor 的方式来实现文件事件处理器（每一个网络连接其实都对应一个文件描述符） 
Redis基于Reactor模式开发了网络事件处理器，这个处理器被称为文件事件处理器。它的组成结构为4部分：多个套接字、IO多路复用程序、文件事件分派器、事件处理器。
 
因为文件事件分派器队列的消费是单线程的，所以Redis才叫单线程模型

基于 I/O 复用模型：多个连接共用一个阻塞对象，应用程序只需要在一个阻塞对象上等待，无需阻塞等待所有连接。当某条连接有新的数据可以处理时，操作系统通知应用程序，线程从阻塞状态返回，开始进行业务处理。
 
Reactor 模式中有 2 个关键组成：
1）Reactor：Reactor 在一个单独的线程中运行，负责监听和分发事件，分发给适当的处理程序来对 IO 事件做出反应。
2）Handlers：处理程序执行 I/O 事件要完成的实际事件，Reactor 通过调度适当的处理程序来响应 I/O 事件，处理程序执行非阻塞操作。

select()：bitmap记录
 
流程：select是一个阻塞函数，当没有数据时，会一直阻塞在select那一行，当有数据时，会将rset对应位置置为1，select函数返回不再阻塞，然后遍历，判断哪个fd被置为了，处理数据。
 
优点：select 其实就是把NIO中用户态要遍历的fd数组拷贝到了内核态，让内核态来遍历，因为用户态判断socket是否有数据还是要调用内核态的，所有拷贝到内核态后，这样遍历判断的时候就不用一直用户态和内核态频繁切换了。
 
缺点：
bitmap默认1024，可以调但还是有限制
rset不可复用，没有重新置0；
用户到内核拷贝有开销
select返回后还是要遍历
  
poll()：它搞了一个结构体pollfd
 
流程：将多个fd拷贝到内核态，poll为阻塞方法，如果有数据了将对应fd的revents置为POLLIN, poll方法返回，循环遍历找到被置位的，将revents置0以便复用，fd处理。
 
解决问题：(解决了select的前两个问题)
解决了bitmap大小限制
解决了rset不可重用问题
 
epoll()
流程：epoll是非阻塞的，当有数据的时候，会把有数据的fd放到队首，epoll会返回有数据的fd的个数，根据个数读取前N个fd处理。

多路复用快的原因在于，操作系统提供了这样的系统调用，使得原来的 while 循环里多次系统调用，变成了一次系统调用 + 内核层遍历这些文件描述符。
 
epoll是现在最先进的IO多路复用器，Redis、Nginx，linux中的Java NIO都使用的是epoll。
 
这里“多路”指的是多个网络连接，“复用”指的是复用同一个线程。
 
1、一个socket的生命周期中只有一次从用户态拷贝到内核态的过程，开销小；
2、使用event事件通知机制，每次socket中有数据会主动通知内核，并加入到就绪链表中，不需要遍历所有的socket。
 
在多路复用IO模型中，会有一个内核线程不断地去轮询多个 socket 的状态，只有当真正读写事件发送时，才真正调用实际的IO读写操作。因为在多路复用IO模型中，只需要使用一个线程就可以管理多个socket，系统不需要建立新的进程或者线程，也不必维护这些线程和进程，并且只有真正有读写事件进行时，才会使用IO资源，所以它大大减少来资源占用。

多路I/O复用模型是利用 select、poll、epoll 可以同时监察多个流的 I/O 事件的能力，在空闲的时候，会把当前线程阻塞掉，当有一个或多个流有 I/O 事件时，就从阻塞态中唤醒，于是程序就会轮询一遍所有的流（epoll 是只轮询那些真正发出了事件的流），并且只依次顺序的处理就绪的流，这种做法就避免了大量的无用操作。
 
采用多路 I/O 复用技术可以让单个线程高效的处理多个连接请求（尽量减少网络 IO 的时间消耗），且 Redis 在内存中操作数据的速度非常快，也就是说内存内的操作不会成为影响Redis性能的瓶颈。

都是用来创建对象的

当使用beanFactory时必须要遵循完整的创建流程，这个过程由Spring管理控制

而使用factoryBean只需要调用getObject就可以返回具体的对象，整个对象的创建过程是由用户自己来控制的，更加灵活。

ApplicationContext 由 BeanFactory 派生而来，提供了更多面向实际应用的功能

BeanFactory 和 ApplicationContext 的实例化时机不太一样，BeanFactory 采用的是延迟初始化的方式，只有在第一次 getBean()的时候，才会实例化 Bean；ApplicationContext 启动之后会实例化所有的 Bean 定义。

实例化：调用构造方法实例化--createBeanInstance()
属性赋值：设置属性和依赖--populateBean()
初始化：initializeBean() -- 前置处理器-- 初始化 --后置处理器
销毁：

创建过程：
AbstractApplicationContext 类里边有一个 refresh() 方法，里边调用 finishBeanFactoryInitialization() 方法，它里边再调用 AbstractBeanFactory的 getBean() ,真正操作在 doGetBean 中

singleton、prototype、request、session、globalSession(spring5中也不存在)

Spring中的单例Bean不是线程安全的
单例Bean，全局只有一个，所以线程共享。
如果单例Bean是一个无状态的，线程不会对Bean执行查询以外的操作，那他就是安全的，如Spring MVC 的Controller、Service、Dao 等。
假如这个 Bean 是有状态的，也就是会对 Bean 中的成员变量进行写操作，那么可能就存在线程安全的问题。

1.定义为多例
2.避免可变的成员变量
3.ThredLoca 能保证多线程下变量的隔离，可以在类中定义一个 ThreadLocal 成员变量，将需要可变成员变量保存在 ThreadLocal 里(推荐)

自己依赖自己，或者和别的Bean相互依赖(只有单例bean才会存在循环依赖，原型情况下会直接抛异常)
 
循环依赖发生在属性赋值阶段，Spring 通过三级缓存解决循环依赖：
一级缓存 : Map<String,Object> singletonObjects，单例池，用于保存实例化、属性赋值（注入）、初始化完成的 bean 实例
二级缓存 : Map<String,Object> earlySingletonObjects，早期曝光对象，用于保存实例化完成的 bean 实例
三级缓存 : Map<String,ObjectFactory<?>> singletonFactories，早期曝光对象工厂，用于保存 bean 创建工厂，以便于后面扩展有机会创建代理对象。
 
过程：
1.创建 A 实例，实例化的时候把 A 对象⼯⼚放⼊三级缓存，表示 A 开始实例化了
2.A 注⼊属性时，发现依赖 B，此时 B 还没有被创建出来，所以去实例化 B
3.B 注⼊属性时发现依赖 A，它就会从缓存里找 A 对象。依次从⼀级到三级缓存查询 A，从三级缓存通过对象⼯⼚拿到 A，把 A 放⼊⼆级缓存，同时删除三级缓存中的 A，此时，B 已经实例化并且初始化完成，把 B 放入⼀级缓存。
4.接着 A 继续属性赋值，顺利从⼀级缓存拿到实例化且初始化完成的 B 对象，A 对象创建也完成，删除⼆级缓存中的 A，同时把 A 放⼊⼀级缓存
 
所以，Spring 能解决 setter 注入的循环依赖，因为实例化和属性赋值是分开的，里面有操作的空间，如果都是构造器注入的话，那么都得在实例化这一步完成注入，所以自然是无法支持了。

AOP 的核心为动态代理，分为JDK和CGLIB两种：

JDK动态代理需要实现一个接口，通过实现 InvocationHandler 定义横切逻辑，再通过反射调用目标代码，Proxy生成代理对象
    
CGLIB动态代理没有接口的限制，通过字节码技术为一个类创建子类，在子类中拦截父类方法调用，织入横切逻辑
 
CGLIB代理对象比JDK的性能高一点，但CGLIB创建对象时间比较长，所以单例对象用CGLIB较合适，反之用JDK

Spring AOP，运行时增强，基于动态代理只能用于Spring容器
 
AspectJ，可单独使用，编译时增强，通过修改代码静态织入

ISOLATION_DEFAULT：使用后端数据库默认的隔离界别，MySQL 默认可重复读
ISOLATION_READ_UNCOMMITTED：读未提交
ISOLATION_READ_COMMITTED：读已提交
ISOLATION_REPEATABLE_READ：可重复读
ISOLATION_SERIALIZABLE：串行化

当多个事务同时存在的时候——一般指的是多个事务方法相互调用时，Spring 如何处理这些事务的行为。
事务传播机制是使用简单的 ThreadLocal 实现的，所以，如果调用的方法是在新线程调用的，事务传播实际上是会失效的
 
 1.没有事务就新建，有就加入
 2.支持当前事务，没有就非事务
 3.使用当前事务，没有就抛异常
 4.新建事务，存在当前事务就挂起当前事务（默认）
 5.以非事务方式执行，当前存在事务就挂起它
 6.以非事务方式执行，当前存在事务就抛异常
 7.如果当前存在事务，在当前事务内执行，否则使用1

通过AOP动态代理实现

Spring 容器在初始化每个单例 bean 的时候，会遍历容器中的所有 BeanPostProcessor 实现类，会遍历容器中所以的切面，然后查找与当前实例化Bean 匹配的切面，也就是匹配 @Transactional 注解，根据得到的切面创建代理对象。
当通过代理对象调用 Bean 方法的时候，在执行目标方法时进行事务增强操作。

非public方法：不是 public 则不会获取@Transactional 的属性配置信息

@Transactional 注解属性 propagation 设置错误

@Transactional 注解属性 rollbackFor 设置错误

同一个类中方法调用，导致@Transactional 失效：比如有一个类 Test，它的一个方法 A，A 再调用本类的方法 B（不论方法 B 是用 public 还是 private 修饰），但方法 A 没有声明注解事务，而 B 方法有。则外部调用方法 A 之后，方法 B 的事务是不会起作用的。因为只有当事务方法被当前类以外的代码调用时，才会由 Spring 生成的代理对象来管理。

1.客户端向服务端发送一次请求，这个请求会先到前端控制器 DispatcherServlet(也叫中央控制器)。
2.DispatcherServlet 接收到请求后会调用 HandlerMapping 处理器映射器。由此得知，该请求该由哪个 Controller 来处理（并未调用 Controller，只是得知）
3.DispatcherServlet 调用 HandlerAdapter 处理器适配器，告诉处理器适配器应该要去执行哪个 Controller
4.HandlerAdapter 处理器适配器去执行 Controller 并得到 ModelAndView(数据和视图)，并层层返回给 DispatcherServlet
5.DispatcherServlet 将 ModelAndView 交给 ViewReslover 视图解析器解析，然后返回真正的视图。
6.DispatcherServlet 将模型数据填充到视图中
7.DispatcherServlet 将结果响应给客户端

@SpringBootApplication是一个复合注解，包含 @EnableAutoConfiguration 开启自动配置
@EnableAutoConfiguration 注入了自动装配类 @Import({AutoConfigurationImportSelector.class})
 
AutoConfigurationImportSelector 实现了ImportSelector接口，这个接口的作用就是收集需要导入的配置类，配合@Import(）就可以将相应的类导入到 Spring 容器中
 
获取注入类的方法是 selectImports()，过程： 
 1.获取注解的属性
 2.获取所有需要自动装配的配置类的路径：从 META-INF/spring.factories 获取自动配置
 3.去掉重复的和需要排除的，把需要自动加载的配置类的路径存储起来

Spring 容器和Bean是松耦合的，Bean并不知道Spring容器的存在，理论上我们可以随心所欲的把Spring容器换成其他容器
但是，在开发中往往我们需要用的Spring容器提供的各种资源，如获取容器中的配置，Bean等，这时，我们就需要某一个Bean能够感知到Spring容器的存在，这样才能想容器要一些东西，这就用到了Aware接口。

SqlSessionFactoryBuilder 用来创建 SqlSessionFactory ，一旦创建好就不需要它了，因此它的最佳作用域是方法作用域（局部变量）。
 
SqlSessionFactory 一旦被创建就应该在应用的运行期间一直存在，没有任何理由丢弃它或重新创建另一个实例。因此 SqlSessionFactory 的最佳作用域是应用作用域。 有很多方法可以做到，最简单的就是使用单例模式或者静态单例模式。
 
每个线程都应该有它自己的 SqlSession 实例。SqlSession 的实例不是线程安全的，因此是不能被共享的，所以它的最佳的作用域是请求或方法作用域。使用Web框架时，考虑将 SqlSession 放在一个和 HTTP 请求相似的作用域中，每次收到 HTTP 请求，就可以打开一个 SqlSession，返回一个响应后，就关闭它，应该把这个关闭操作放到 finally 块中。
 
映射器接口的实例是从 SqlSession 中获得，映射器实例应该在调用它们的方法中被获取，使用完毕之后即可丢弃，它不需要显示的被关闭。

${}是拼接符，字符串替换，没有预编译处理

#{}是占位符，预编译处理
它会将SQL中的#{}替换为？，调用PreparedStatement的set方法来赋值。
可以有效防止SQL注入

一级缓存：基于 PerpetualCache 的 HashMap 本地缓存，其存储作用域为SqlSession，各个SqlSession之间的缓存相互隔离，当 Session flush 或 close 之后，该 SqlSession 中的所有 Cache 就将清空，MyBatis默认打开一级缓存
 
二级缓存与一级缓存其机制相同，默认也是采用 PerpetualCache，HashMap 存储，不同之处在于其存储作用域为 Mapper(Namespace)，可以在多个SqlSession之间共享，并且可自定义存储源，如 Ehcache。

默认不打开二级缓存，要开启二级缓存，使用二级缓存属性类需要实现Serializable序列化接口(可用来保存对象的状态),可在它的映射文件中配置。

两大步

整体流程

Mapper映射其实是通过动态代理实现的

SimpleExecutor：每次执行一次update或select，用完就关闭
ReuseExecutor：以sql作为key查找Statement对象，存在就使用，不存在就创建，用完不关闭，而是放在Map中下次使用
BatchExecutor：执行update，不支持select，，将所有SQL加到批处理中统一执行

实现Mybatis的Interceptor接口并重写intercept()方法