前段时间敖丙不是在复习嘛，很多小伙伴也想要我的复习路线，以及我自己笔记里面的一些知识点，好了，丙丙花了一个月的时间，整整一个月啊，给大家整理出来了。
一上来我就放个大招好吧，我的复习脑图，可以说是全得不行，为了防止被盗图，我加了水印哈。
这期看下去你会发现很硬核，而且我会持续更新，啥也不说了，看在我熬夜一个月满脸痘痘的份上，你可以点赞了哈哈。
注：如果图被压缩了，可以去公众号【三太子敖丙】回复【复习】获取原图
Spring Core：框架的最基础部分，提供 IoC 容器，对 bean 进行管理。
Spring Context：继承BeanFactory，提供上下文信息，扩展出JNDI、EJB、电子邮件、国际化等功能。
Spring DAO：提供了JDBC的抽象层，还提供了声明性事务管理方法。
Spring ORM：提供了JPA、JDO、Hibernate、MyBatis 等ORM映射层.
Spring AOP：集成了所有AOP功能
Spring Web：提供了基础的 Web 开发的上下文信息，现有的Web框架，如JSF、Tapestry、Structs等，提供了集成
Spring Web MVC：提供了 Web 应用的 Model-View-Controller 全功能实现。
singleton（单例）
prototype（原型）
request
session
global session
resource定位
即寻找用户定义的bean资源，由 ResourceLoader通过统一的接口Resource接口来完成
beanDefinition载入
BeanDefinitionReader读取、解析Resource定位的资源 成BeanDefinition 载入到ioc中（通过HashMap进行维护BD）
BeanDefinition注册
即向IOC容器注册这些BeanDefinition， 通过BeanDefinitionRegistery实现
定义BeanDefinitionReader解析xml的document
BeanDefinitionDocumentReader解析document成beanDefinition
过程在Ioc初始化后，依赖注入的过程是用户第一次向IoC容器索要Bean时触发
如果设置lazy-init=true，会在第一次getBean的时候才初始化bean， lazy-init=false，会容器启动的时候直接初始化（singleton bean）；
调用BeanFactory.getBean（）生成bean的；
生成bean过程运用装饰器模式产生的bean都是beanWrapper（bean的增强）；
其实就是通过在beanDefinition载入时，如果bean有依赖关系，通过占位符来代替，在调用getbean时候，如果遇到占位符，从ioc里获取bean注入到本实例来
IOC：控制反转：将对象的创建权，由Spring管理.
DI（依赖注入）：在Spring创建对象的过程中，把对象依赖的属性注入到类中。
构造器注入
setter方法注入
注解注入
接口注入
Bean在创建的时候可以给该Bean打标，如果递归调用回来发现正在创建中的话，即说明了循环依赖了。
Spring中循环依赖场景有：
1、切面（aspect）：类是对物体特征的抽象，切面就是对横切关注点的抽象
2、横切关注点：对哪些方法进行拦截，拦截后怎么处理，这些关注点称之为横切关注点。
3、连接点（joinpoint）：被拦截到的点，因为 Spring 只支持方法类型的连接点，所以在Spring 中连接点指的就是被拦截到的方法，实际上连接点还可以是字段或者构造器。
4、切入点（pointcut）：对连接点进行拦截的定义
5、通知（advice）：所谓通知指的就是指拦截到连接点之后要执行的代码，通知分为前置、后置、异常、最终、环绕通知五类。
6、目标对象：代理的目标对象
7、织入（weave）：将切面应用到目标对象并导致代理对象创建的过程
8、引入（introduction）：在不修改代码的前提下，引入可以在运行期为类动态地添加方法或字段。
传统oop开发代码逻辑自上而下的，这个过程中会产生一些横切性问题，这些问题与我们主业务逻辑关系不大，会散落在代码的各个地方，造成难以维护，aop思想就是把业务逻辑与横切的问题进行分离，达到解耦的目的，提高代码重用性和开发效率；
@EnableAspectJAutoProxy给容器（beanFactory）中注册一个AnnotationAwareAspectJAutoProxyCreator对象；
AnnotationAwareAspectJAutoProxyCreator对目标对象进行代理对象的创建，对象内部，是封装JDK和CGlib两个技术，实现动态代理对象创建的（创建代理对象过程中，会先创建一个代理工厂，获取到所有的增强器（通知方法），将这些增强器和目标类注入代理工厂，再用代理工厂创建对象）；
代理对象执行目标方法，得到目标方法的拦截器链，利用拦截器的链式机制，依次进入每一个拦截器进行执行
（1）：用户请求发送给DispatcherServlet，DispatcherServlet调用HandlerMapping处理器映射器；
（2）：HandlerMapping根据xml或注解找到对应的处理器，生成处理器对象返回给DispatcherServlet；
（3）：DispatcherServlet会调用相应的HandlerAdapter；
（4）：HandlerAdapter经过适配调用具体的处理器去处理请求，生成ModelAndView返回给DispatcherServlet
（5）：DispatcherServlet将ModelAndView传给ViewReslover解析生成View返回给DispatcherServlet；
（6）：DispatcherServlet根据View进行渲染视图；
->DispatcherServlet->HandlerMapping->Handler
->DispatcherServlet->HandlerAdapter处理handler->ModelAndView
->DispatcherServlet->ModelAndView->ViewReslover->View
->DispatcherServlet->返回给客户
默认情况下一级缓存是开启的，而且是不能关闭的。
new springApplication对象，利用spi机制加载applicationContextInitializer，
applicationLister接口实例（META-INF/spring.factories）；
调run方法准备Environment，加载应用上下文（applicationContext），发布事件 很多通过lister实现
创建spring容器， refreshContext（） ，实现starter自动化配置，spring.factories文件加载， bean实例化
核心注解是@SpringBootApplication 由以下三种组成
spring-boot-starter-web - Web 和 RESTful 应用程序；
spring-boot-starter-test - 单元测试和集成测试；
spring-boot-starter-jdbc - 传统的 JDBC；
spring-boot-starter-security - 使用 SpringSecurity 进行身份验证和授权；
spring-boot-starter-data-jpa - 带有 Hibernate 的 Spring Data JPA；
spring-boot-starter-data-rest - 使用 Spring Data REST 公布简单的 REST 服务
（1）：Application.yml
一般用来定义单个应用级别的，如果搭配 spring-cloud-config 使用
（2）.Bootstrap.yml（先加载）
系统级别的一些参数配置，这些参数一般是不变的
（1）：zuul则是netflix公司的项目集成在spring-cloud中使用而已， Gateway是spring-cloud的
一个子项目；
（2）：zuul不提供异步支持流控等均由hystrix支持， gateway提供了异步支持，提供了抽象负载均衡，提供了抽象流控； 理论上gateway则更适合于提高系统吞吐量（但不一定能有更好的性能），最终性能还需要通过严密的压测来决定
（3）：两者底层实现都是servlet，但是gateway多嵌套了一层webflux框架
（4）： zuul可用至其他微服务框架中，内部没有实现限流、负载均衡；gateway只能用在springcloud中；
（1）：请求给zuulservlet处理（HttpServlet子类） zuulservlet中有一个zuulRunner对象，该对象中初始化了RequestContext（存储请求的数据），RequestContext被所有的zuulfilter共享；
（2）： zuulRunner中有 FilterProcessor（zuulfilter的管理器），其从filterloader 中获取zuulfilter；
（3）：有了这些filter之后， zuulservelet执行的Pre-> route-> post 类型的过滤器，如果在执行这些过滤器有错误的时候则会执行error类型的过滤器，执行完后把结果返回给客户端.
（1）：请求到达DispatcherHandler， DispatchHandler在IOC容器初始化时会在容器中实例化HandlerMapping接口
（2）：用handlerMapping根据请求URL匹配到对应的Route，然后有对应的filter做对应的请求转发最终response返回去
Zookeeper 的核心是原子广播，这个机制保证了各个 server 之间的同步。实现这个机制的协议叫做 Zab 协议。Zab 协议有两种模式，它们分别是恢复模式和广播模式。
通过维护一个自己的线程池，当线程池达到阈值的时候，就启动服务降级，返回fallback默认值
防止雪崩，及时释放资源，防止系统发生更多的额级联故障，需要对故障和延迟进行隔离，防止单个依赖关系的失败影响整个应用程序；
ActiveMQ：Apache出品，最早使用的消息队列产品，时间比较长了，最近版本更新比较缓慢。
RabbitMQ：erlang语言开发，支持很多的协议，非常重量级，更适合于企业级的开发。性能较好，但是不利于做二次开发和维护。
RocketMQ：阿里开源的消息中间件，纯Java开发，具有高吞吐量、高可用性、适合大规模分布式系统应用的特点，分布式事务。
ZeroMQ：号称最快的消息队列系统，尤其针对大吞吐量的需求场景，采用 C 语言实现。
消息队列的选型需要根据具体应用需求而定，ZeroMQ 小而美，RabbitMQ 大而稳，Kakfa 和 RocketMQ 快而强劲
（1个字节是8个bit）
整数型：byte（1字节）、short（2字节）、int（4字节）、long（8字节）
浮点型：float（4字节）、double（8字节）
布尔型：boolean（1字节）
字符型：char（2字节）
包括 类File，outputStream，inputStream，writer，readerseralizable（5类1接口）
NIO三大核心内容 selector（选择器，用于监听channel），channel（通道），buffer（缓冲区）
NIO与IO区别，IO面向流，NIO面向缓冲区；io阻塞，nio非阻塞
throwable为父类，子为error跟exception，exception分runtime（空指针，越界等）跟checkexception（sql，io，找不到类等异常）
sleep属于线程类，wait属于object类；sleep不释放锁
线程中创建副本，访问自己内部的副本变量，内部实现是其内部类名叫ThreadLocalMap的成员变量threadLocals，key为本身，value为实际存值的变量副本
如果是强引用，设置tl=null，但是key的引用依然指向ThreadLocal对象，所以会有内存泄漏，而使用弱引用则不会；
但是还是会有内存泄漏存在，ThreadLocal被回收，key的值变成null，导致整个value再也无法被访问到；
解决办法：在使用结束时，调用ThreadLocal.remove来释放其value的引用；
ThreadLocal是不具备继承性的，所以是无法获取到的，但是我们可以用InteritableThreadLocal来实现这个功能。InteritableThreadLocal继承来ThreadLocal，重写了createdMap方法，已经对应的get和set方法，不是在利用了threadLocals，而是interitableThreadLocals变量。
这个变量会在线程初始化的时候（调用init方法），会判断父线程的interitableThreadLocals变量是否为空，如果不为空，则把放入子线程中，但是其实这玩意没啥鸟用，当父线程创建完子线程后，如果改变父线程内容是同步不到子线程的。。。同样，如果在子线程创建完后，再去赋值，也是没啥鸟用的
线程池有5种状态：running，showdown，stop，Tidying，TERMINATED。
running：线程池处于运行状态，可以接受任务，执行任务，创建线程默认就是这个状态了
showdown：调用showdown（）函数，不会接受新任务，但是会慢慢处理完堆积的任务。
stop：调用showdownnow（）函数，不会接受新任务，不处理已有的任务，会中断现有的任务。
Tidying：当线程池状态为showdown或者stop，任务数量为0，就会变为tidying。这个时候会调用钩子函数terminated（）。
TERMINATED：terminated（）执行完成。
在线程池中，用了一个原子类来记录线程池的信息，用了int的高3位表示状态，后面的29位表示线程池中线程的个数。
如果提交任务的时候使用了submit，则返回的feature里会存有异常信息，但是如果数execute则会打印出异常栈。但是不会给其他线程造成影响。之后线程池会删除该线程，会新增加一个worker。
contentionList（请求锁线程队列）
entryList（有资格的候选者队列）
waitSet（wait方法后阻塞队列）
onDeck（竞争候选者）
ower（竞争到锁线程）
!ower（执行成功释放锁后状态）；
Synchronized 是非公平锁。
Synchronized 在线程进入 ContentionList 时，等待的线程会先尝试自旋获取锁，如果获取不到就进入 ContentionList，这明显对于已经进入队列的线程是不公平的，还有一个不公平的事情就是自旋获取锁的线程还可能直接抢占 OnDeck 线程的锁资源。
底层是由一对monitorenter和monitorexit指令实现的（监视器锁）
每个对象有一个监视器锁（monitor）。当monitor被占用时就会处于锁定状态，线程执行monitorenter指令时尝试获取monitor的所有权，过程：
内部自定义了同步器 Sync，加锁的时候通过CAS 算法 ，将线程对象放到一个双向链表 中，每次获取锁的时候 ，看下当前维 护的那个线程ID和当前请求的线程ID是否一样，一样就可重入了；
（1）：tryLock 能获得锁就返回 true，不能就立即返回 false，
（2）：tryLock（long timeout，TimeUnit unit），可以增加时间限制，如果超过该时间段还没获得锁，返回 false
（3）：lock 能获得锁就返回 true，不能的话一直等待获得锁
（4）：lock 和 lockInterruptibly，如果两个线程分别执行这两个方法，但此时中断这两个线程， lock 不会抛出异常，而 lockInterruptibly 会抛出异常。
CountDownLatch是等待其他线程执行到某一个点的时候，在继续执行逻辑（子线程不会被阻塞，会继续执行），只能被使用一次。最常见的就是join形式，主线程等待子线程执行完任务，在用主线程去获取结果的方式（当然不一定），内部是用计数器相减实现的（没错，又特么是AQS），AQS的state承担了计数器的作用，初始化的时候，使用CAS赋值，主线程调用await（）则被加入共享线程等待队列里面，子线程调用countDown的时候，使用自旋的方式，减1，知道为0，就触发唤醒。
CyclicBarrier回环屏障，主要是等待一组线程到底同一个状态的时候，放闸。CyclicBarrier还可以传递一个Runnable对象，可以到放闸的时候，执行这个任务。CyclicBarrier是可循环的，当调用await的时候如果count变成0了则会重置状态，如何重置呢，CyclicBarrier新增了一个字段parties，用来保存初始值，当count变为0的时候，就重新赋值。还有一个不同点，CyclicBarrier不是基于AQS的，而是基于RentrantLock实现的。存放的等待队列是用了条件变量的方式。
信号量是一种固定资源的限制的一种并发工具包，基于AQS实现的，在构造的时候会设置一个值，代表着资源数量。信号量主要是应用于是用于多个共享资源的互斥使用，和用于并发线程数的控制（druid的数据库连接数，就是用这个实现的），信号量也分公平和非公平的情况，基本方式和reentrantLock差不多，在请求资源调用task时，会用自旋的方式减1，如果成功，则获取成功了，如果失败，导致资源数变为了0，就会加入队列里面去等待。调用release的时候会加一，补充资源,并唤醒等待队列。
（1）：可重入锁是指同一个线程可以多次获取同一把锁，不会因为之前已经获取过还没释放而阻塞；
（2）：reentrantLock和synchronized都是可重入锁
（3）：可重入锁的一个优点是可一定程度避免死锁
（1）：先通过CAS尝试获取锁， 如果此时已经有线程占据了锁，那就加入AQS队列并且被挂起；
（2）： 当锁被释放之后， 排在队首的线程会被唤醒CAS再次尝试获取锁，
（3）：如果是非公平锁， 同时还有另一个线程进来尝试获取可能会让这个线程抢到锁；
（4）：如果是公平锁， 会排到队尾，由队首的线程获取到锁。
Node内部类构成的一个双向链表结构的同步队列，通过控制（volatile的int类型）state状态来判断锁的状态，对于非可重入锁状态不是0则去阻塞；
对于可重入锁如果是0则执行，非0则判断当前线程是否是获取到这个锁的线程，是的话把state状态＋1，比如重入5次，那么state=5。 而在释放锁的时候，同样需要释放5次直到state=0其他线程才有资格获得锁
内存值V，旧的预期值A，要修改的新值B，当A=V时，将内存值修改为B，否则什么都不做；
（1）：ABA问题；
（2）：如果CAS失败，自旋会给CPU带来压力；
（3）：只能保证对一个变量的原子性操作，i++这种是不能保证的
（1）：Atomic系列
（1）：公平锁指在分配锁前检查是否有线程在排队等待获取该锁，优先分配排队时间最长的线程，非公平直接尝试获取锁
（2）：公平锁需多维护一个锁线程队列，效率低；默认非公平
（1）：ReentrantLock为独占锁（悲观加锁策略）
（2）：ReentrantReadWriteLock中读锁为共享锁
（3）： JDK1.8 邮戳锁（StampedLock）， 不可重入锁
读的过程中也允许获取写锁后写入！这样一来，我们读的数据就可能不一致，所以，需要一点额外的代码来判断读的过程中是否有写入，这种读锁是一种乐观锁， 乐观锁的并发效率更高，但一旦有小概率的写入导致读取的数据不一致，需要能检测出来，再读一遍就行
无锁
偏向锁
会偏向第一个访问锁的线程，当一个线程访问同步代码块获得锁时，会在对象头和栈帧记录里存储锁偏向的线程ID，当这个线程再次进入同步代码块时，就不需要CAS操作来加锁了，只要测试一下对象头里是否存储着指向当前线程的偏向锁
如果偏向锁未启动，new出的对象是普通对象（即无锁，有稍微竞争会成轻量级锁），如果启动，new出的对象是匿名偏向（偏向锁）
对象头主要包括两部分数据：Mark Word（标记字段， 存储对象自身的运行时数据）、class Pointer（类型指针， 是对象指向它的类元数据的指针）
轻量级锁（自旋锁）
（1）：在把线程进行阻塞操作之前先让线程自旋等待一段时间，可能在等待期间其他线程已经 解锁，这时就无需再让线程执行阻塞操作，避免了用户态到内核态的切换。（自适应自旋时间为一个线程上下文切换的时间）
（2）：在用自旋锁时有可能造成死锁，当递归调用时有可能造成死锁
（3）：自旋锁底层是通过指向线程栈中Lock Record的指针来实现的
重量级锁
（1）：轻量级锁是通过CAS来避免进入开销较大的互斥操作
（2）：偏向锁是在无竞争场景下完全消除同步，连CAS也不执行
（1）：某线程自旋次数超过10次；
（2）：等待的自旋线程超过了系统core数的一半；
常用的读写锁ReentrantReanWritelock，这个其实和reentrantLock相似，也是基于AQS的，但是这个是基于共享资源的，不是互斥，关键在于state的处理，读写锁把高16为记为读状态，低16位记为写状态，就分开了，读读情况其实就是读锁重入，读写/写读/写写都是互斥的，只要判断低16位就好了。
（1）：利用节点名称唯一性来实现，加锁时所有客户端一起创建节点，只有一个创建成功者获得锁，解锁时删除节点。
（2）：利用临时顺序节点实现，加锁时所有客户端都创建临时顺序节点，创建节点序列号最小的获得锁，否则监视比自己序列号次小的节点进行等待
（3）：方案2比1好处是当zookeeper宕机后，临时顺序节点会自动删除释放锁，不会造成锁等待；
（4）：方案1会产生惊群效应（当有很多进程在等待锁的时候，在释放锁的时候会有很多进程就过来争夺锁）。
（5）：由于需要频繁创建和删除节点，性能上不如redis锁
（1）：变量可见性
（2）：防止指令重排序
（3）：保障变量单次读，写操作的原子性，但不能保证i++这种操作的原子性，因为本质是读，写两次操作
volatile可见性是有指令原子性保证的，在jmm中定义了8类原子性指令，比如write，store，read，load。而volatile就要求write-store，load-read成为一个原子性操作，这样子可以确保在读取的时候都是从主内存读入，写入的时候会同步到主内存中（准确来说也是内存屏障），指令重排则是由内存屏障来保证的，由两个内存屏障:
jdk是最小的开发环境，由jre++java工具组成。
jre是java运行的最小环境，由jvm+核心类库组成。
jvm是虚拟机，是java字节码运行的容器，如果只有jvm是无法运行java的，因为缺少了核心类库。
（1）：堆<对象，静态变量，共享
（2）：方法区<存放类信息，常量池，共享>（java8移除了永久代（PermGen），替换为元空间（Metaspace））
（4）：本地方法栈<存放各种native方法的局部变量表之类的信息>
（5）：程序计数器<记录当前线程执行到哪一条字节码指令位置>
（1）：强（内存泄露主因）
（2）：软（只有软引用的话，空间不足将被回收），适合缓存用
（3）：弱（只，GC会回收）
（4）：虚引用（用于跟踪GC状态）用于管理堆外内存
一个对象分为3个区域：对象头、实例数据、对齐填充
对象头：主要是包括两部分，1.存储自身的运行时数据比如hash码，分代年龄，锁标记等（但是不是绝对哦，锁状态如果是偏向锁，轻量级锁，是没有hash码的。。。是不固定的）2.指向类的元数据指针。还有可能存在第三部分，那就是数组类型，会多一块记录数组的长度（因为数组的长度是jvm判断不出来的，jvm只有元数据信息）
实例数据：会根据虚拟机分配策略来定，分配策略中，会把相同大小的类型放在一起，并按照定义顺序排列（父类的变量也会在哦）
对齐填充：这个意义不是很大，主要在虚拟机规范中对象必须是8字节的整数，所以当对象不满足这个情况时，就会用占位符填充
一般判断对象是否存活有两种算法，一种是引用计数，另外一种是可达性分析。在java中主要是第二种
根据GC ROOTS。GC ROOTS可以的对象有：虚拟机栈中的引用对象，方法区的类变量的引用，方法区中的常量引用，本地方法栈中的对象引用。
（1）：加载
获取类的二进制字节流，将其静态存储结构转化为方法区的运行时数据结构
（2）：校验
文件格式验证，元数据验证，字节码验证，符号引用验证
（3）：准备
在方法区中对类的static变量分配内存并设置类变量数据类型默认的初始值，不包括实例变量，实例变量将会在对象实例化的时候随着对象一起分配在Java堆中
（4）：解析
将常量池内的符号引用替换为直接引用的过程
（5）：初始化
为类的静态变量赋予正确的初始值（Java代码中被显式地赋予的值）
（1）：启动类加载器（home）
加载jvm核心类库，如java.lang.*等
（2）：扩展类加载器（ext），
父加载器为启动类加载器，从jre/lib/ext下加载类库
（3）：应用程序类加载器（用户classpath路径）
父加载器为扩展类加载器，从环境变量中加载类
（1）：类加载器收到类加载的请求
（2）：把这个请求委托给父加载器去完成，一直向上委托，直到启动类加载器
（3）：启动器加载器检查能不能加载，能就加载（结束）；否则，抛出异常，通知子加载器进行加载
（4）：保障类的唯一性和安全性以及保证JDK核心类的优先加载
保证java基础类在不同的环境还是同一个Class对象，避免出现了自定义类覆盖基础类的情况，导致出现安全问题。还可以避免类的重复加载。
（1）：自定义类加载器，继承ClassLoader类重写loadClass方法；
（2）：SPI
tomcat有着特殊性，它需要容纳多个应用，需要做到应用级别的隔离，而且需要减少重复性加载，所以划分为：/common 容器和应用共享的类信息，/server容器本身的类信息，/share应用通用的类信息,/WEB-INF/lib应用级别的类信息。整体可以分为：boostrapClassLoader->ExtensionClassLoader->ApplicationClassLoader->CommonClassLoader->CatalinaClassLoader（容器本身的加载器）/ShareClassLoader（共享的）->WebAppClassLoader。虽然第一眼是满足双亲委派模型的，但是不是的，因为双亲委派模型是要先提交给父类装载，而tomcat是优先判断是否是自己负责的文件位置，进行加载的。
（1）：服务提供接口（服务发现机制）：
（2）：通过加载ClassPath下META_INF/services，自动加载文件里所定义的类
（3）：通过ServiceLoader.load/Service.providers方法通过反射拿到实现类的实例
（1）：应用于JDBC获取数据库驱动连接过程就是应用这一机制
（2）：apache最早提供的common-logging只有接口.没有实现…发现日志的提供商通过SPI来具体找到日志提供商实现类
（1）：双亲委派核心是越基础的类由越上层的加载器进行加载， 基础的类总是作为被调用代码调用的API，无法实现基础类调用用户的代码….
（2）：JNDI服务它的代码由启动类加载器去加载，但是他需要调独立厂商实现的应用程序，如何解决?
线程上下文件类加载器（Thread Context ClassLoader）， JNDI服务使用这个线程上下文类加载器去加载所需要的SPI代码，也就是父类加载器请求子类加载器去完成类加载动作Java中所有涉及SPI的加载动作基本上都采用这种方式，例如JNDI，JDBC
（1）：老年代空间不足
（2）：永久代（方法区）空间不足
（3）：显式调用system.gc（）
Ehcache中的一些版本，各种 NIO 框架，Dubbo，Memcache 等中会用到，NIO包下ByteBuffer来创建堆外内存
堆外内存，其实就是不受JVM控制的内存。
减少了垃圾回收的工作，因为垃圾回收会暂停其他的工作。
加快了复制的速度。因为堆内在 flush 到远程时，会先复制到直接内存（非堆内存），然后在发送；而堆外内存相当于省略掉了复制这项工作。
可以扩展至更大的内存空间。比如超过 1TB 甚至比主存还大的空间。
堆外内存难以控制，如果内存泄漏，那么很难排查，通过-XX：MaxDirectMemerySize来指定，当达到阈值的时候，调用system.gc来进行一次full gc
堆外内存相对来说，不适合存储很复杂的对象。一般简单的对象或者扁平化的比较适合
jstat查看内存回收概况，实时查看各个分区的分配回收情况，
jmap查看内存栈，查看内存中对象占用大小，
jstack查看线程栈，死锁，性能瓶颈
（1）： Serial 收集器 复制算法，单线程，新生代）
（2）： ParNew 收集器（复制算法，多线程，新生代）
（3）： Parallel Scavenge 收集器（多线程，复制算法，新生代，高吞吐量）
（4）：Serial Old 收集器（标记-整理算法，老年代）
（5）：Parallel Old 收集器（标记-整理算法，老年代，注重吞吐量的场景下，jdk8默认采用 Parallel Scavenge + Parallel Old 的组合）
（6）：CMS 收集器（标记-清除算法，老年代，垃圾回收线程几乎能做到与用户线程同时工作，吞吐量低，内存碎片）以牺牲吞吐量为代价来获得最短回收停顿时间-XX：+UseConcMarkSweepGC
jdk1.8 默认垃圾收集器Parallel Scavenge（新生代）+Parallel Old（老年代）
jdk1.9 默认垃圾收集器G1
（1）：应用程序对停顿比较敏感
（2）：在JVM中，有相对较多存活时间较长的对象（老年代比较大）会更适合使用CMS
（1）：初始标识<找到gcroot（stw）>
1：系统类加载器加载的对象
2：处于激活状态的线程
3：JNI栈中的对象
4：正在被用于同步的各种锁对象
5：JVM自身持有的对象，比如系统类加载器等。
（2）：并发标记（三色标记算法）
三色标记算法处理并发标记出现对象引用变化情况：
黑：自己+子对象标记完成
灰：自己完成，子对象未完成
白：未标记；
并发标记 黑->灰->白
重新标记 灰->白引用消失，黑引用指向->白，导致白漏标
cms处理办法是incremental update方案 （增量更新）把黑色变成灰色
多线程下并发标记依旧会产生漏标问题，所以cms必须remark一遍（jdk1.9以后不用cms了）
SATB（snapshot at the begining）把白放入栈中，标记过程是和应用程序并发运行的（不需要Stop-The-World）
这种方式会造成某些是垃圾的对象也被当做是存活的，所以G1会使得占用的内存被实际需要的内存大。不过下一次就回收了
ZGC 处理方案： 颜色指针（color pointers） 2*42方=4T
（3）：重新标记（stw）
（4）并发清理
备注：重新标记是防止标记成垃圾之后，对象被引用
（5）：G1 收集器（新生代 + 老年代，在多 CPU 和大内存的场景下有很好的性能）
G1在java9 便是默认的垃圾收集器，是cms 的替代者
逻辑分代，用分区（region）的思想（默认分2048份） 还是有stw
为解决CMS算法产生空间碎片HotSpot提供垃圾收集器，通过-XX：+UseG1GC来启用
（1）：young gc（eden region被耗尽无法申请内存时，就会触发）
（2）：mixed gc（当老年代大小占整个堆大小百分比达到该阈值时，会触发）
（3）：full gc（对象内存分配速度过快，mixed gc来不及回收，导致老年代被填满，就会触发）
（8）：ZGC和shenandoah （oracle产收费） no stw
（1）：dashboard命令查看总体jvm运行情况
（2）：jvm显示jvm详细信息
（3）：thread 显示jvm里面所有线程信息（类似于jstack） 查看死锁线程命令thread -b
（4）：sc * 显示所有类（search class）
（5）：trace 跟踪方法
第一步：jps获取进程号
第二步：jmap -histo pid | head -20 得知有个对象在不断创建
备注：jmap如果线上服务器堆内存特别大，，会卡死需堆转存（一般会说在测试环境压测，导出转存）
-XX：+HeapDumpOnOutOfMemoryError或jmap -dumpLformat=b，file=xxx pid 转出文件进行分析
（arthas没有实现jmap命令）heapdump --live /xxx/xx.hprof导出文件
回收过程
（1）：young gc（年轻代回收）–当年轻代的Eden区用尽时–stw
第一阶段，扫描根。
根是指static变量指向的对象，正在执行的方法调用链条上的局部变量等
第二阶段，更新RS（Remembered Sets）。
处理dirty card queue中的card，更新RS。此阶段完成后，RS可以准确的反映老年代对所在的内存分段中对象的引用
第三阶段，处理RS。
识别被老年代对象指向的Eden中的对象，这些被指向的Eden中的对象被认为是存活的对象。
第四阶段，复制对象。
此阶段，对象树被遍历，Eden区内存段中存活的对象会被复制到Survivor区中空的内存分段
第五阶段，处理引用。
处理Soft，Weak，Phantom，Final，JNI Weak 等引用。
（2）：concrruent marking（老年代并发标记）
当堆内存使用达到一定值（默认45%）时，不需要Stop-The-World，在并发标记前先进行一次young gc
（3）：混合回收（mixed gc）
并发标记过程结束以后，紧跟着就会开始混合回收过程。混合回收的意思是年轻代和老年代会同时被回收
（4）：Full GC?
Full GC是指上述方式不能正常工作，G1会停止应用程序的执行，使用单线程的内存回收算法进行垃圾回收，性能会非常差，应用程序停顿时间会很长。要避免Full GC的发生，一旦发生需要进行调整。
比如堆内存太小，当G1在复制存活对象的时候没有空的内存分段可用，则会回退到full gc，这种情况可以通过增大内存解决
尽管G1堆内存仍然是分代的，但是同一个代的内存不再采用连续的内存结构
年轻代分为Eden和Survivor两个区，老年代分为Old和Humongous两个区
新分配的对象会被分配到Eden区的内存分段上
Humongous区用于保存大对象，如果一个对象占用的空间超过内存分段Region的一半；
如果对象的大小超过一个甚至几个分段的大小，则对象会分配在物理连续的多个Humongous分段上。
Humongous对象因为占用内存较大并且连续会被优先回收
为了在回收单个内存分段的时候不必对整个堆内存的对象进行扫描（单个内存分段中的对象可能被其他内存分段中的对象引用）引入了RS数据结构。RS使得G1可以在年轻代回收的时候不必去扫描老年代的对象，从而提高了性能。每一个内存分段都对应一个RS，RS保存了来自其他分段内的对象对于此分段的引用
JVM会对应用程序的每一个引用赋值语句object.field=object进行记录和处理，把引用关系更新到RS中。但是这个RS的更新并不是实时的。G1维护了一个Dirty Card Queue
这是为了性能的需要，使用队列性能会好很多。
栈上分配->tlab->堆上分配
由于堆内存是应用程序共享的，应用程序的多个线程在分配内存的时候需要加锁以进行同步。为了避免加锁，提高性能每一个应用程序的线程会被分配一个TLAB。TLAB中的内存来自于G1年轻代中的内存分段。当对象不是Humongous对象，TLAB也能装的下的时候，对象会被优先分配于创建此对象的线程的TLAB中。这样分配会很快，因为TLAB隶属于线程，所以不需要加锁
G1会在年轻代回收过程中把Eden区中的对象复制（“提升”）到Survivor区中，Survivor区中的对象复制到Old区中。G1的回收过程是多线程执行的，为了避免多个线程往同一个内存分段进行复制，那么复制的过程也需要加锁。为了避免加锁，G1的每个线程都关联了一个PLAB，这样就不需要进行加锁了
（1）：jmap -heap 10765如上图，可以查看新生代，老生代堆内存的分配大小以及使用情况；
（2）：jstat 查看GC收集情况
（3）：jmap -dump：live，format=b，file=到本地
（4）：通过MAT工具打开分析
（1）：生产者（Provider）启动，向注册中心（Register）注册
（2）：消费者（Consumer）订阅，而后注册中心通知消费者
（3）：消费者从生产者进行消费
（4）：监控中心（Monitor）统计生产者和消费者
推荐使用Hessian序列化，还有Duddo、FastJson、Java自带序列化
默认使用 Netty 框架，也是推荐的选择，另外内容还集成有Mina、Grizzly。
（1）：随机调用<默认>
（2）：权重轮询
（3）：最少活跃数
（4）：一致性Hash
（1）消费者调用需要消费的服务，
（2）：客户端存根将方法、入参等信息序列化发送给服务端存根
（3）：服务端存根反序列化操作根据解码结果调用本地的服务进行相关处理
（4）：本地服务执行具体业务逻辑并将处理结果返回给服务端存根
（5）：服务端存根序列化
（6）：客户端存根反序列化
（7）：服务消费方得到最终结果
RPC框架的实现目标PC框架的实现目标是把调用、编码/解码的过程给封装起来，让用户感觉上像调用本地服务一样的调用远程服务
（1）：纯内存操作，避免大量访问数据库，减少直接读取磁盘数据，redis将数据储存在内存里面，读写数据的时候都不会受到硬盘 I/O 速度的限制，所以速度快
（2）：单线程操作，避免了不必要的上下文切换和竞争条件，也不存在多进程或者多线程导致的切换而消耗CPU，不用去考虑各种锁的问题，不存在加锁释放锁操作，没有因为可能出现死锁而导致的性能消耗
（3）：采用了非阻塞I/O多路复用机制
（1）Simple dynamic string（SDS）的数据结构
struct sdshdr{
//记录buf数组中已使用字节的数量
//等于 SDS 保存字符串的长度
int len；
//记录 buf 数组中未使用字节的数量
int free；
//字节数组，用于保存字符串
char buf[]；
}
它的优点：
（1）不会出现字符串变更造成的内存溢出问题
（2）获取字符串长度时间复杂度为1
（3）空间预分配， 惰性空间释放free字段，会默认留够一定的空间防止多次重分配内存
应用场景：
String 缓存结构体用户信息，计数
2.哈希表节点采用单链表结构。
3.rehash优化 （采用分而治之的思想，将庞大的迁移工作量划分到每一次CURD中，避免了服务繁忙）
应用场景：
保存结构体信息可部分获取不用序列化所有字段
应用场景：
（1）：比如twitter的关注列表，粉丝列表等都可以用Redis的list结构来实现
（2）：list的实现为一个双向链表，即可以支持反向查找和遍历
内部实现是一个 value为null的HashMap，实际就是通过计算hash的方式来快速排重的，这也是set能提供判断一个成员 是否在集合内的原因。
应用场景：
去重的场景，交集（sinter）、并集（sunion）、差集（sdiff），实现如共同关注、共同喜好、二度好友等功能
内部使用HashMap和跳跃表（SkipList）来保证数据的存储和有序，HashMap里放的是成员到score的映射，而跳跃表里存放的是所有的成员，排序依据是HashMap里存的score，使用跳跃表的结构可以获得比较高的查找效率，并且在实现上比较简单。
跳表：每个节点中维持多个指向其他节点的指针，从而达到快速访问节点的目的
应用场景：
实现延时队列
（1）：Multi开启事务
（2）：Exec执行事务块内命令
（3）：Discard 取消事务
（4）：Watch 监视一个或多个key，如果事务执行前key被改动，事务将打断
（1）：所有命令都将会被串行化的顺序执行，事务执行期间，Redis不会再为其它客户端的请求提供任何服务，从而保证了事物中的所有命令被原子的执行
（2）：Redis事务中如果有某一条命令执行失败，其后的命令仍然会被继续执行
（3）：在事务开启之前，如果客户端与服务器之间出现通讯故障并导致网络断开，其后所有待执行的语句都将不会被服务器执行。然而如果网络中断事件是发生在客户端执行EXEC命令之后，那么该事务中的所有命令都会被服务器执行
（4）：当使用Append-Only模式时，Redis会通过调用系统函数write将该事务内的所有写操作在本次调用中全部写入磁盘。
然而如果在写入的过程中出现系统崩溃，如电源故障导致的宕机，那么此时也许只有部分数据被写入到磁盘，而另外一部分数据却已经丢失。
Redis服务器会在重新启动时执行一系列必要的一致性检测，一旦发现类似问题，就会立即退出并给出相应的错误提示。此时，我们就要充分利用Redis工具包中提供的redis-check-aof工具，该工具可以帮助我们定位到数据不一致的错误，并将已经写入的部分数据进行回滚。修复之后我们就可以再次重新启动Redis服务器了
（1）：全量拷贝，
1.slave第一次启动时，连接Master，发送PSYNC命令，
2.master会执行bgsave命令来生成rdb文件，期间的所有写命令将被写入缓冲区。
（1）：master挂掉，且当前master没有slave
（2）：集群超过半数以上master挂掉，无论是否有slave集群进入fail状态
（1）：会话缓存session cache
（2）：排行榜/计数器ZRANGE
（3）：发布/订阅
（1）：先进先出算法（FIFO）
（2）：最近使用最少Least Frequently Used（LFU）
（3）：最长时间未被使用的Least Recently Used（LRU）
当存在热点数据时，LRU的效率很好，但偶发性的、周期性的批量操作会导致LRU命中率急剧下降，缓存污染情况比较严重
（1）：惰性删除，cpu友好，但是浪费cpu资源
（2）：定时删除（不常用）
（3）：定期删除，cpu友好，节省空间
同一时刻大量缓存失效；
（1）：缓存数据增加过期标记
（2）：设置不同的缓存失效时间
（3）：双层缓存策略C1为短期，C2为长期
（4）：定时更新策略
频繁请求查询系统中不存在的数据导致；
（1）：cache null策略，查询反馈结果为null仍然缓存这个null结果，设置不超过5分钟过期时间
（2）：布隆过滤器，所有可能存在的数据映射到足够大的bitmap中
google布隆过滤器：基于内存，重启失效不支持大数据量，无法在分布式场景
redis布隆过滤器：可扩展性，不存在重启失效问题，需要网络io，性能低于google
（1）：数据结构使用不合理bigkey
（2）：CPU饱和
（3）：持久化阻塞，rdb fork子线程，aof每秒刷盘等
（1）：使用本地缓存
（2）： 利用分片算法的特性，对key进行打散处理（给hot key加上前缀或者后缀，把一个hotkey 的数量变成 redis 实例个数N的倍数M，从而由访问一个 redis key 变成访问 N * M 个redis key）
2.6版本以后lua脚本保证setnx跟setex进行原子性（setnx之后，未setex，服务挂了，锁不释放）
a获取锁，超过过期时间，自动释放锁，b获取到锁执行，a代码执行完remove锁，a和b是一样的key，导致a释放了b的锁。
解决办法：remove之前判断value（高并发下value可能被修改，应该用lua来保证原子性）
bgsave做镜像全量持久化，aof做增量持久化。因为bgsave会耗费较长时间，不够实时，在停机的时候会导致大量丢失数据 ，所以需要aof来配合使用。在redis实例重启时，会使用bgsave持久化文件重新构建内存，再使用aof重放近期的操作指令来 实 现完整恢复重启之前的状态。
取决于aof日志sync属性的配置，如果不要求性能，在每条写指令时都sync一下磁盘，就不会丢失数据。但是在高性能的要求下每次都sync是不现实的，一般都使用定时sync，比如1s1次，这个时候最多就会丢失1s的数据.
（1）：基于redis的redission分布式可重入锁RLock，以及配合java集合中lock；
（2）：Redission 内部提供了一个监控锁的看门狗，不断延长锁的有效期，默认检查锁的超时时间是30秒
（3）：此方案的问题：如果你对某个redis master实例，写入了myLock这种锁key的value，此时会异步复制给对应的master ，slave实例。但是这个过程中一旦发生redis master宕机，主备切换，redis slave变为了redis master。
接着就会导致，客户端2来尝试加锁的时候，在新的redis master上完成了加锁，而客户端1也以为自己成功加了锁。
此时就会导致多个客户端对一个分布式锁完成了加锁
解决办法：只需要将新的redis实例，在一个TTL时间内，对客户端不可用即可，在这个时间内，所有客户端锁将被失效或者自动释放.
fork和cow。fork是指redis通过创建子进程来进行bgsave操作，cow指的是copy on write，子进程创建后，父子进程共享数据段，父进程继续提供读写服务，写进的页面数据会逐渐和子进程分离开来。
（1）：R文件格式紧凑，方便数据恢复，保存rdb文件时父进程会fork出子进程由其完成具体持久化工作，最大化redis性能，恢复大数据集速度更快，只有手动提交save命令或关闭命令时才触发备份操作；
（2）：A记录对服务器的每次写操作（默认1s写入一次），保存数据更完整，在redis重启是会重放这些命令来恢复数据，操作效率高，故障丢失数据更少，但是文件体积更大；
使用keys指令可以扫出指定模式的key列表。
如果这个redis正在给线上的业务提供服务，那使用keys指令会有什么问题？
redis的单线程的。keys指令会导致线程阻塞一段时间，线上服务会停顿，直到指令执行完毕，服务才能恢复。这个时候可以使用scan指令，scan指令可以无阻塞的提取出指定模式的key列表，但是会有一定的重复概率，在客户端做一次去重就可以了 ，但是整体所花费的时间会比直接用keys指令长。
一般使用list结构作为队列，rpush生产消息，lpop消费消息。当lpop没有消息的时候，要适当sleep一会再重试。
list还有个指令叫blpop，在没有消息的时候，它会阻塞住直到消息到来。
使用pub/sub主题订阅者模式，可以实现1：N的消息队列。
在消费者下线的情况下，生产的消息会丢失，得使用专业的消息队列如rabbitmq等。
使用sortedset，想要执行时间的时间戳作为score，消息内容作为key调用zadd来生产消息，消费者用zrangebyscore指令获取N秒之前的数据轮询进行处理。
（1）：skiplist的复杂度和红黑树一样，而且实现起来更简单。
（2）：在并发环境下红黑树在插入和删除时需要rebalance，性能不如跳表。
一： 确保每列的原子性
二：非主键列不存在对主键的部分依赖 （要求每个表只描述一件事情）
三： 满足第二范式，并且表中的列不存在对非主键列的传递依赖
（1）：主库db的更新事件（update、insert、delete）被写到binlog
（2）：主库创建一个binlog dump thread线程，把binlog的内容发送到从库
（3）：从库创建一个I/O线程，读取主库传过来的binlog内容并写入到relay log.
（4）：从库还会创建一个SQL线程，从relay log里面读取内容写入到slave的db.
（1）：异步复制（默认）
主库写入binlog日志后即可成功返回客户端，无须等待binlog日志传递给从库的过程，但是一旦主库宕机，就有可能出现丢失数据的情况。
（2）半同步复制：（ 5.5版本之后）
（安装半同步复制插件）确保从库接收完成主库传递过来的binlog内容已经写入到自己的relay log（传送log）后才会通知主库上面的等待线程。如果等待超时，则关闭半同步复制，并自动转换为异步复制模式，直到至少有一台从库通知主库已经接收到binlog信息为止
（1）：Myiasm是mysql默认的存储引擎，不支持数据库事务，行级锁，外键；插入更新需锁表，效率低，查询速度快，Myisam使用的是非聚集索引
（2）：innodb 支持事务，底层为B+树实现，适合处理多重并发更新操作，普通select都是快照读，快照读不加锁。InnoDb使用的是聚集索引
（1）：聚集索引就是以主键创建的索引
（2）：每个表只能有一个聚簇索引，因为一个表中的记录只能以一种物理顺序存放，实际的数据页只能按照一颗 B+ 树进行排序
（3）：表记录的排列顺序和与索引的排列顺序一致
（4）：聚集索引存储记录是物理上连续存在
（5）：聚簇索引主键的插入速度要比非聚簇索引主键的插入速度慢很多
（6）：聚簇索引适合排序，非聚簇索引不适合用在排序的场合，因为聚簇索引叶节点本身就是索引和数据按相同顺序放置在一起，索引序即是数据序，数据序即是索引序，所以很快。非聚簇索引叶节点是保留了一个指向数据的指针，索引本身当然是排序的，但是数据并未排序，数据查询的时候需要消耗额外更多的I/O，所以较慢
（7）：更新聚集索引列的代价很高，因为会强制innodb将每个被更新的行移动到新的位置
（1）：除了主键以外的索引
（2）：聚集索引的叶节点就是数据节点，而非聚簇索引的叶节点仍然是索引节点，并保留一个链接指向对应数据块
（3）：聚簇索引适合排序，非聚簇索引不适合用在排序的场合
（4）：聚集索引存储记录是物理上连续存在，非聚集索引是逻辑上的连续。
使用聚簇索引找到包含第一个值的行后，便可以确保包含后续索引值的行在物理相邻
在聚簇索引中不要包含经常修改的列，因为码值修改后，数据行必须移动到新的位置，索引此时会重排，会造成很大的资源浪费
优先使用用户自定义主键作为主键，如果用户没有定义主键，则选取一个Unique键作为主键，如果表中连Unique键都没有定义的话，则InnoDB会为表默认添加一个名为row_id隐藏列作为主键。
每个表你最多可以建立249个非聚簇索引。非聚簇索引需要大量的硬盘空间和内存
（1）：BTree索引可能需要多次运用折半查找来找到对应的数据块
（2）：HASH索引是通过HASH函数，计算出HASH值，在表中找出对应的数据
（3）：大量不同数据等值精确查询，HASH索引效率通常比B+TREE高
（4）：HASH索引不支持模糊查询、范围查询和联合索引中的最左匹配规则，而这些Btree索引都支持
（1）：需要查询，排序，分组和联合操作的字段适合建立索引
（2）：索引多，数据更新表越慢，尽量使用字段值不重复比例大的字段作为索引，联合索引比多个独立索引效率高
（3）：对数据进行频繁查询进建立索引，如果要频繁更改数据不建议使用索引
（4）：当对表中的数据进行增加、删除和修改的时候，索引也要动态的维护，降低了数据的维护速度。
（1）：B+Tree非叶子节点只存储键值信息，降低B+Tree的高度，所有叶子节点之间都有一个链指针，数据记录都存放在叶子节点中
（2）： 红黑树这种结构，h明显要深的多，效率明显比B-Tree差很多
（3）：B+树也存在劣势，由于键会重复出现，因此会占用更多的空间。但是与带来的性能优势相比，空间劣势往往可以接受，因此B+树的在数据库中的使用比B树更加广泛
（1）：条件是or，如果还想让or条件生效，给or每个字段加个索引
（2）：like开头%
（3）：如果列类型是字符串，那一定要在条件中将数据使用引号引用起来，否则不会使用索引
（4）：where中索引列使用了函数或有运算
ACID 原子性，一致性，隔离性，永久性
（1）：通过预写日志方式实现的，redo和undo机制是数据库实现事务的基础
（2）：redo日志用来在断电/数据库崩溃等状况发生时重演一次刷数据的过程，把redo日志里的数据刷到数据库里，保证了事务 的持久性（Durability）
（3）：undo日志是在事务执行失败的时候撤销对数据库的操作，保证了事务的原子性
（1）：读未提交read-uncommitted-- 脏，不可重复读–幻读
A读取了B未提交的事务，B回滚，A 出现脏读；
（2）：不可重复读read-committed-- 不可重复读–幻读
A只能读B已提交的事务，但是A还没结束，B又更新数据隐式提交，然后A又读了一次出现不可重复读；
（3）：可重复读repeatable-read<默认>-- 幻读
事务开启，不允许其他事务的UPDATE修改操作
A读取B已提交的事务，然而B在该表插入新的行，之后A在读取的时候多出一行，出现幻读；
（4）：串行化serializable–
（1）Propagation.REQUIRED<默认>
如果当前存在事务，则加入该事务，如果当前不存在事务，则创建一个新的事务。
（2）Propagation.SUPPORTS
如果当前存在事务，则加入该事务；如果当前不存在事务，则以非事务的方式继续运行。
（3）Propagation.MANDATORY
如果当前存在事务，则加入该事务；如果当前不存在事务，则抛出异常。
（4）Propagation.REQUIRES_NEW
重新创建一个新的事务，如果当前存在事务，延缓当前的事务。
（5）Propagation.NOT_SUPPORTED
以非事务的方式运行，如果当前存在事务，暂停当前的事务。
（6）Propagation.NEVER
以非事务的方式运行，如果当前存在事务，则抛出异常。
（7）Propagation.NESTED
如果没有，就新建一个事务；如果有，就在当前事务中嵌套其他事务。
（1）：互斥： 资源x的任意一个时刻只能被一个线程持有
（2）：占有且等待：线程1占有资源x的同时等待资源y，并不释放x
（3）：不可抢占：资源x一旦被线程1占有，其他线程不能抢占x
（4）：循环等待：线程1持有x，等待y，线程2持有y，等待x
当全部满足时才会死锁
底层实现是AOP，动态代理
（1）：实现是通过Spring代理来实现的。生成当前类的代理类，调用代理类的invoke（）方法，在invoke（）方法中调用 TransactionInterceptor拦截器的invoke（）方法；
（2）：非public方式其事务是失效的；
（3）：自调用也会失效，因为动态代理机制导致
（4）多个方法外层加入try…catch，解决办法是可以在catch里 throw new RuntimeException（）来处理
有一个事务管理器的概念，负责协调多个数据库（资源管理器）的事务
不适合高并发场景，严重依赖数据库层面，同步阻塞问题；协调者故障则所有参与者会阻塞
严重依赖代码补偿和回滚，一般银行用，和钱相关的支付、交易等相关的场景，我们会用TCC
Try，对各个服务的资源做检测，对资源进行锁定或者预留
Confirm，在各个服务中执行实际的操作
Cancel，如果任何一个服务的业务方法执行出错，那么这里就需要进行补偿，即执行已操作成功的业务逻辑的回滚操作
1）：本地消息服务
本地消息表其实是国外的 ebay 搞出来的这么一套思想。
主动方是认证服务，有个消息异常处理系统，mq，还有消息消费端应用系统，还有采集服务；
2）：独立消息最终一致性方案：
A 主动方应用系统，B消息服务子系统，C消息状态确认子系统，C2消息管理子系统
D 消息恢复子系统，mq ，消息消费端E ，被动系统F
流程：
A预发送消息给B，然后执行A业务逻辑，B存储预发送消息，A执行完业务逻辑发送业务操作结果给B，B更新预发送消息为确认并发送消息状态同时发送消息给mq，然后被E监听然后发送给F消费掉
C：对预发送消息异常的处理，去查询待确认状态超时的消息，去A中查询进行数据处理，如果A中业务处理成功了，那么C需改消息状态为确认并发送状态，然后发送消息给mq；如果A中业务处理失败了..那么C直接把消息删除即可.
C2 ： 查询消息的页面，对消息的可视化，以及批量处理死亡消息；
D： B给mq放入数据如果失败，，通过D去重试，多次重试失败，消息设置为死亡
E：确保F执行完成，发送消息给B删除消息
优化建议：
（1）数据库：如果用redis，持久化要配置成appendfsync always，确保每次新添加消息都能持久化进磁盘
（2）在被动方应用业务幂等性判断比较麻烦或者比较耗性能情况下，增加消息日志记录表.用于判断之前有无发送过；
（1）业务主动方完成业务处理之后，设置时间阶梯型通知规则向业务活动的被动方发送消息，允许消息丢失.
（2）被动方根据定时策略，向主动方查询，恢复丢失的业务消息
（3）被动方的处理结果不影响主动方的处理结果
（4）需增加业务查询，通知服务，校对系统服务的建设成本
（5）适用于对业务最终一致性的时间敏感度低，跨企业的业务通知活动
（6）比如银行通知，商户通知，交易业务平台间商户通知，多次通知，查询校对等
应用层基于SQL解析实现了自动补偿，从而最大程度的降低业务侵入性；
将分布式事务中TC（事务协调者）独立部署，负责事务的注册、回滚；
通过全局锁实现了写隔离与读隔离。
TCP向上层提供面向连接的可靠服务 ，UDP向上层提供无连接不可靠服务。
虽然 UDP 并没有 TCP 传输来的准确，但是也能在很多实时性要求高的地方有所作为
对数据准确性要求高，速度可以相对较慢的，可以选用TCP
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Z5cVyZQc-1588909160041)(https://tva1.sinaimg.cn/large/007S8ZIlgy1gek7kv86p8j31a80s0wny.jpg)]
（1）：客户端发送终止命令FIN
（2）：服务端收到后回复ACK，处于close_wait状态
（3）：服务器将关闭前需要发送信息发送给客户端后处于last_ack状态
（4）：客户端收到FIN后发送ack后处于tim-wait而后进入close状态
为了防止服务器端开启一些无用的连接增加服务器开销以及防止已失效的连接请求报文段突然又传送到了服务端
java也开始承认了函数式编程， 就是说函数既可以作为参数，也可以作为返回值，
大大的简化了代码的开发
打破接口里面是只能有抽象方法，不能有任何方法的实现，接口里面也可以有方法的实现了
之前使用的java.util.Date月份从0开始，我们一般会+1使用，很不方便，java.time.LocalDate月份和星期都改成了enum
java.util.Date和SimpleDateFormat都不是线程安全的，而LocalDate和LocalTime和最基本的String一样，是不变类型，不但线程安全，而且不能修改。
新接口更好用的原因是考虑到了日期时间的操作，经常发生往前推或往后推几天的情况。用java.util.Date配合Calendar要写好多代码，而且一般的开发人员还不一定能写对。
（1）：JDK1.7版本的ReentrantLock+Segment+HashEntry（数组）
（2）：JDK1.7采用segment的分段锁机制实现线程安全
（3）：JDK1.8版本中synchronized+CAS+HashEntry（数组）+红黑树
（4）：JDK1.8采用CAS+Synchronized保证线程安全
（5）：查询时间复杂度从原来的遍历链表O（n），变成遍历红黑树O（logN）
1.8 HashMap数组+链表+红黑树来实现hashmap，当碰撞的元素个数大于8时 & 总容量大于64，会有红黑树的引入
除了添加之后，效率都比链表高，1.8之后链表新进元素加到末尾
（1）：因为粒度降低了，在相对而言的低粒度加锁方式，synchronized并不比ReentrantLock差
（2）：基于JVM的synchronized优化空间更大
（3）：在大数据量下，基于API的ReentrantLock会比基于JVM的内存压力开销更多的内存
模块是一个包的容器，Java 9 最大的变化之一是引入了模块系统（Jigsaw 项目）。
通常，您希望在代码中创建一个集合（例如，List 或 Set ），并直接用一些元素填充它。 实例化集合，几个 “add” 调用，使得代码重复。 Java 9，添加了几种集合工厂方法：
Set<Integer> ints = Set.of（1， 2， 3）；
List<String> strings = List.of（"first"， "second"）；
Stream 接口中添加了 4 个新的方法：dropWhile， takeWhile， ofNullable。还有个 iterate 方法的新重载方法
Javadoc 现在支持在 API 文档中的进行搜索。另外，Javadoc 的输出现在符合兼容 HTML5 标准。
redis代理集群模式，spring有哪些注解，b+b 红黑树区别，三次握手，valitile重排序底层代码，
cas 事务的4个特性，java8 java11 特性， filter和interceptor的区别 @autowired原理，
dispatcherservlet，分布式事务解决方案spring都有哪些模块，fork join队列，排序算法，
两种：collection和map，其中collection分为set和List。
ArrayList和linkedList使用的最多，也最具代表性。
ArrayList实现是一个数组，可变数组，默认初始化长度为10，也可以我们设置容量，但是没有设置的时候是默认的空数组，只有在第一步add的时候会进行扩容至10（重新创建了数组），后续扩容按照3/2的大小进行扩容，是线程不安全的，适用多读取，少插入的情况
linkedList是基于双向链表的实现，使用了尾插法的方式，内部维护了链表的长度，以及头节点和尾节点，所以获取长度不需要遍历。适合一些插入/删除频繁的情况。
Vector是线程安全的，实现方式和ArrayList相似，也是基于数组，但是方法上面都有synchronized关键词修饰。其扩容方式是原来的两倍。
hashMap是map类型的一种最常用的数据结构，其底部实现是数组+链表（在1.8版本后变为了数组+链表/红黑树的方式），其key是可以为null的，默认hash值为0。扩容以2的幂等次（为什么。。。因为只有是2的幂等次的时候（n-1）&x==x%n，当然不一定只有一个原因）。是线程不安全的
hashTable的实现形式和hashMap差不多，它是线程安全的，是继承了Dictionary，也是key-value的模式，但是其key不能为null。
ConcurrentHashMap是JUC并发包的一种，在hashMap的基础上做了修改，因为hashmap其实是线程不安全的，那在并发情况下使用hashTable嘛，但是hashTable是全程加锁的，性能不好，所以采用分段的思想，把原本的一个数组分成默认16段，就可以最多容纳16个线程并发操作，16个段叫做Segment，是基于ReetrantLock来实现的
hashMap是Map的结构，内部用了数组+链表的方式，在1.8后，当链表长度达到8的时候，会变成红黑树，这样子就可以把查询的复杂度变成O（nlogn）了，默认负载因子是0.75，为什么是0.75呢？
我们知道当负载因子太小，就很容易触发扩容，如果负载因子太大就容易出现碰撞。所以这个是空间和时间的一个均衡点，在1.8的hashmap介绍中，就有描述了，貌似是0.75的负载因子中，能让随机hash更加满足0.5的泊松分布。
除此之外，1.7的时候是头插法，1.8后就变成了尾插法，主要是为了解决rehash出现的死循环问题，而且1.7的时候是先扩容后插入，1.8则是先插入后扩容(为什么？正常来说，如果先插入，就有可能节点变为树化，那么是不是多做一次树转化，比1.7要多损耗，个人猜测，因为读写问题，因为hashmap并不是线程安全的，如果说是先扩容，后写入，那么在扩容期间，是访问不到新放入的值的，是不是不太合适，所以会先放入值，这样子在扩容期间，那个值是在的）。
1.7版本的时候用了9次扰动，5次异或，4次位移，减少hash冲突，但是1.8就只用了两次，觉得就足够了一次异或，一次位移。
concurrentHashMap是线程安全的map结构，它的核心思想是分段锁。在1.7版本的时候，内部维护了segment数组，默认是16个，segment中有一个table数组（相当于一个segmeng存放着一个hashmap。。。），segment继承了reentrantlock，使用了互斥锁，map的size其实就是segment数组的count和。而在1.8的时候做了一个大改版，废除了segment，采用了cas加synchronize方式来进行分段锁（还有自旋锁的保证），而且节点对象改用了Node不是之前的HashEntity。
Node可以支持链表和红黑树的转化，比如TreeBin就是继承了Node，这样子可以直接用instanceof来区分。1.8的put就很复杂来，会先计算出hash值，然后根据hash值选出Node数组的下标（默认数组是空的，所以一开始put的时候会初始化，指定负载因子是0.75，不可变），判断是否为空，如果为空，则用cas的操作来赋值首节点，如果失败，则因为自旋，会进入非空节点的逻辑，这个时候会用synchronize加锁头节点（保证整条链路锁定）这个时候还会进行二次判断，是否是同一个首节点，在分首节点到底是链表还是树结构，进行遍历判断。
1.7版本的concurrentHashMap是基于了segment的，segment内部维护了HashEntity数组，所以扩容是在这个基础上的，类比hashmap的扩容，
1.8版本的concurrentHashMap扩容方式比较复杂，利用了ForwardingNode,先会根据机器内核数来分配每个线程能分到的busket数，（最小是16），这样子可以做到多线程协助迁移，提升速度。然后根据自己分配的busket数来进行节点转移，如果为空，就放置ForwardingNode，代表已经迁移完成，如果是非空节点（判断是不是ForwardingNode，是就结束了），加锁，链路循环,进行迁移。
判断key是否是null，如果是null对应的hash值就是0，获得hash值过后则进行扰动，（1.7是9次，5次异或，4次位移，1.8是2次），获取到的新hash值找出所在的index，（n-1）&hash，根据下标找到对应的Node/entity，然后遍历链表/红黑树，如果遇到hash值相同且equals相同，则覆盖值，如果不是则新增。如果节点数大于8了，则进行树化（1.8）。完成后，判断当前的长度是否大于阀值，是就扩容（1.7是先扩容在put）。
都是map惹的祸，我们知道在map中判断是否是同一个对象的时候，会先判断hash值，在判断equals的，如果我们只是重写了hashcode，没有顺便修改equals，比如Intger，hashcode就是value值，如果我们不改写equals，而是用了Object的equals，那么就是判断两者指针是否一致了，那就会出现valueOf和new出来的对象会对于map而言是两个对象，那就是个问题了
TreeMap是Map中的一种很特殊的map，我们知道Map基本是无序的，但是TreeMap是会自动进行排序的，也就是一个有序Map(使用了红黑树来实现），如果设置了Comparator比较器，则会根据比较器来对比两者的大小，如果没有则key需要是Comparable的子类（代码中没有事先check，会直接抛出转化异常，有点坑啊）。
LinkedHashMap是HashMap的一种特殊分支，是某种有序的hashMap，和TreeMap是不一样的概念，是用了HashMap+链表的方式来构造的，有两者有序模式：访问有序，插入顺序，插入顺序是一直存在的，因为是调用了hashMap的put方法，并没有重载，但是重载了newNode方法，在这个方法中，会把节点插入链表中，访问有序默认是关闭的，如果打开，则在每次get的时候都会把链表的节点移除掉，放到链表的最后面。这样子就是一个LRU的一种实现方式。
TODO（未完待续）
内容过于硬核了，导致很多排版细节，我没办法做得像其他期一样精致了，大家见谅。
涉及的内容和东西太多了，可能很多都是点到为止，也有很多不全的，也有很多错误的点，已经快3W字了，我校验实在困难，我会放在GitHub上面，大家可以跟我一起更新这个文章，造福后人吧。
搞不好下次我需要看的时候，我都得看着这个复习了。
我是敖丙，一个在互联网苟且偷生的工具人。
你知道的越多，你不知道的越多，人才们的 【三连】 就是丙丙创作的最大动力，我们下期见！
注：如果本篇博客有任何错误和建议，欢迎人才们留言，你快说句话啊！
文章持续更新，可以微信搜索「 三太子敖丙 」第一时间阅读，回复【资料】【面试】【简历】有我准备的一线大厂面试资料和简历模板，本文 GitHub 已经收录，有大厂面试完整考点，欢迎Star。