【无标题】

阶段总结：

目标一：熟悉java语法、集合、IO等基础框架【常用的Map,BIO、NIO等】

内容：

一、面向对象特性：封装、继承、多态
二、map:

1. 常见的map集合有哪些？HashMap、HashTable、ConcurrentHashMap
2. HashMap和HashTable的区别？HashMap是基于数组和单项链表实现的，键值可以为空，线程不安全。HashTable是基于哈希表实现的，键值不能为空，线程安全
3. HashMap和TreeMap的区别？HashMap数据无序，TreeMap数据有序
4. Set集合特点？元素不重复

三、IO:

1. 同步和异步？同步和异步关注的是消息通知的机制，是自己主动获取还是别人通知
2. 阻塞和非阻塞？阻塞和非阻塞关注的是等待消息通知的过程中，能不能处理别的任务
   以小明下载文件为例：
   (1).同步阻塞：小明一直盯着下载进度条，看到100%的时候完成
   同步行为：小明一直盯着下载进度条
   阻塞表现：在文件下载到100%期间，小明不能做别的工作
   (2).同步非阻塞：小明提交下载任务后就去干别的了，每过一段时间就来看一眼进度条，看到100%的时候完成
   同步行为：小明每过一段时间就去看一眼进度条
   非阻塞表现：小明在文件下载到100%期间去干别的了
   (3).异步阻塞：小明换了个有下载通知完成的软件，下载完成会’叮‘的一声，但是小明提交完下载任务后，还是一直盯着进度条到100%，中间没干别的工作
   异步行为：下载完成有’叮‘一声通知。
   阻塞表现：小明在文件下载期间没干别的工作
   (4).异步非阻塞：小明使用上面的软件，提交完下载任务就去干别的了，听到’叮‘一声就知道完成了
   异步行为：下载完成’叮‘一声通知
   非阻塞表现：文件下载期间小明去干别的工作了

目标二：熟悉 JVM 原理。[ 运⾏时内存区域、类加载、垃圾回收 ]

内容：

一、运行时内存区域：

1. 虚拟机栈：
   (1).线程私有，每一个线程都独享一个虚拟机栈，他的生命周期与线程相同
   (2)存放基本数据类型和对象的引用
2. 本地方法栈：作用和虚拟机栈类似，虚拟机栈执行的是java方法，而本地方法栈执行的是Native方法
3. 堆：
   (1).线程共享区域
   (2)存放new的对象
4. 方法区：
   (1).线程共享区域
   (2).存储已经被虚拟机加载过的类信息、常量和静态变量等等
5. 程序计数器：
   (1).线程私有，每一个线程都有一个程序计数器
   (2).记录当前线程所执行的位置

二、类加载：jvm把.class文件加载到内存，并对数据进行校验、准备、解析和初始化最终形成jvm可以直接使用的java类型的全过程

1. 加载：将class文件字节码内容加载到内存中，并将这些静态数据转换成方法区中的运行时数据结构，在堆中生成一个代表这个类的java.lang.Class的对象，作为方法区类数据的访问入口
2. 连接：主要是将已经读到内存中的二进制数据合并到jvm运行时环境中去
   (1).验证：保证Class流的格式是否正确，包括文件格式、元数据、字节码和符号引用验证
   (2).准备：为静态变量赋默认值
   (3).解析：符号引用转为直接引用
3. 初始化：执行静态块，为静态变量复制为初始值

二、垃圾回收：

1. 如何确定对象已死？
   (1).引用计数算法：为对象添加一个引用计数器，每当对象在一个地方被引用，计数器加1，对象引用失效计数器减1，当为0时表示改对象没有被引用
   (2).可达性分析算法：以GC Root对象作为根节点，沿着引用链进行搜索，凡是在引用链上的对象都不会被回收

2. 垃圾回收算法：
   (1)标记清除算法：对无效的对象进行标记，然后清除
   (2).标记复制算法：把java堆分成两块，每次垃圾回收时只使用其中一块，然后把不需要回收的对象复制到另一块。
   (3).标记整理算法：存活的对象整理到堆的一端，然后直接清除存活对象以外的区域

3. 垃圾回收过程/机制：新创建的对象先会被放到新生代的Eden区，如果Eden区已经满，则进行一次Minor GC（标记复制算法），如果对象经过一次Minor GC还存活，并且能被Survivor空间接受，将被移动到Survivor空间中。并将其年龄设置为1，对象在Survivor空间每熬过一次Minor GC，年龄就加1，当年龄达到一档程度时（默认为15），就会被晋升到老年代，如果老年代满了，就执行Full GC，因为不经常执行，所以采用标记整理算法

目标三：SpringCloud、Dubbo基本原理

内容：

一、SpringCloud:为微服务提供的一组框架的集合

1. 五大核心组件：Eureka Ribbon Feign Hystrix Zuul
2. Eureka:服务注册与发现
3. Ribbon:服务间调用的负载均衡
4. Feign:根据注解和选择的机器，拼接url地址，发起请求
5. Hystrix:发起请求是通过Hystrix线程池来走的，不同的服务走不同的线程池，实现了不同服务调用的隔离，避免了服务的雪崩问题
6. Zuul:前端、移动端调用后端服务，统一从Zuul网关进入，由网关请求转发给对应的服务

一、Dubbo:

1. 什么是RPC? 远程过程调用，它对应的是本地过程调用。用于分布式系统之间通信，可以用HTTP传输，也可以基于TCP自定义协议传输
2. 说说你对dubbo的了解？(历史背景)阿里巴巴开源的一个基于Java的RPC框架。（总体架构）
   注册中心 生产者 消费者 容器, 首先服务提供者启动，然后向注册中心注册自己所能提供的服务，服务消费者向注册中心订阅自己所需要的服务，注册中心将提供者的元信息发送给消费者，之后消费者因为已经从注册中心获取到提供者的地址，因此可以通过负载均衡选择一个提供者直接调用
   3.服务暴露流程？消费者启动，根据配置参数组装成url,通过Proxy组件根据具体的协议Protocol将要暴露出去的接口封装成invoker,然后转换成Exporter，通过Registry 注册到注册中心
   4.服务引入流程？根据配置参数组装成url,然后构建RegistryDirectory向注册中心注册消费者信息，并且订阅提供者。获取到提供者信息之后，会进行Dubbo协议的引入，然后创建Invoker,期间包含NettyClient来进行远程通信，最终返回代理类。
   5.服务调用流程？调用某个接口的方法会调用之前生成的代理类，制作一个invoker,此时会记录请求和请求的ID等待服务端的响应,服务端接到请求之后，找到相应的exporter ，调用真正的实现类，组装好结果返回，带上之前的请求ID.

目标四：网络【HTTP TCP UDP】

内容：

一、网络:

1. 7层模型：应用层、表示层、会话层、传输层、网络层、数据链路层、物理层

一、HTTP:

1. 概念：http是一个无状态协议。无状态是指浏览器和服务器之间不需要建立持久的连接

二、TCP:

1. 三次握手过程？①主机A发送标志syn = 1，随机产生sequence number的数据包到主机B，主机A进入SYN_SEND ②主机B接收到主机A syn = 1的连接请求，向A发送标志syn = 1，ack = 1，随机产生的sequence number，以及ack number = (A的seq + 1)的数据包，主机B进入SYN_RCVD状态 ③ 主机A收到后检查ack是否正确，如果正确，主机A再次发送ack number(B的seq + 1)，ack = 1标志，主机A进入ESTABLISHED状态 ④ 主机B收到后检查ack是否正确 如果正确 主机B进入ESTABLISHED状态 双方成功建立连接
2. 四次挥手过程？①主机A发送FIN进入终止等待状态 ②主机B接到A的连接释放报文段后，就给立即给主机A发送确认，B进入关闭等待状态 ，此时TCP服务器进程就通知高层应用进程，因此A到B的连接释放了。③此时，如果B没有数据报要发送给A，其应用进程就通知TCP释放连接，然后给A发送连接释放报文段，并等待确认。④A给B发送确认后，进入时间等待状态，此时TCP连接还没有释放掉，经过时间等待计时器设置2MSL后，A进入关闭状态
3. 为什么建立连接需要三次握手？断开连接需要四次挥手？建立连接时，SYN和ACK可以放一个包里发送。断开连接时，被动断开的一方可能还有数据需要发送，所以不能把FIN和ACK同一个包发送给主动的一方
   三、UDP:
4. TCP和UDP区别？①TCP是有连接的，两台主机数据交互之前必须进行三次握手建立连接； UDP是无连接的，他没有建立连接这个过程。② TCP是可靠传输，他通过确认和重传机制保证数据传输的可靠性；UDP是不可靠的传输

目标五：分布式事务

内容：

一、什么是分布式事务？分布式事务是指事务的参与者、支持事务的服务器、资源管理器以及事务管理器分别位于不同分布式系统的不同节点之上(一个事务，横跨多个服务，操作多个库)
二、CAP定理：分布式事务无法同时满足三个属性：

1. 一致性：（Consistency）客户端知道一系列操作都会同时发生（生效）
2. 可用性：（Availability）每个操作都必须可以预期的响应结束（有限时间内、正常结果）
3. 分区容错性：（Partition tolerance）即使出现单个组件无法可用，操作依然可以完成

三、什么是数据一致性？数据一致性分为强一致性、最终一致性、弱一致性

1. 强一致性：时刻保证客户端看到的数据是一致的
2. 最终一致性：允许存在中间态，只要求经过一段时间后，数据是一致的
3. 弱一致性：存在部分数据不一致

四、BASE定理：BASE是Basically Available(基本可用)、Soft state(软状态)、Eventually consistent(最终一致性)的缩写。BASE定理是CAP定理演化而来，其核心思想是即使无法达到强一致性，但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性。
五、事务分类：刚性事务、柔性事务

1. 刚性事务：通常无业务改造，强一致性，低并发，适合短事务(CP)；XA(2PC)、3PC
2. 柔性事务：通常有业务改造，最终一致性，高并发，适合长事务(AP)；柔性事务分为补偿型和通知型，补偿型有TCC、Saga，通知型有MQ消息事务、本地消息表事务

六、分布式事务解决方案：

1. TCC模型：①Try初步操作:完成所有业务检查，预留所需的业务资源；②Confirm确认操作：真正执行业务逻辑，只使用预留的业务资源，需要支持幂等；②Cancel取消操作：释放预留的业务资源，支持幂等；
2. Saga模型：把一个分布式事务拆分成多个本地事务，每个本地事务都有相应的执行模块和补偿模块，当任意一个本地事务执行失败的时，可以通过相关的补偿方法恢复之前的事务，达到事务最终一致性（有基于时间和基于命令两种方式，基于命令的方式引入了协调中心监听各事件）
3. XA模型：主要使用两阶段提交来保证分布式事务的完成性（2PC:①阶段一：协调者向所有参与者发送事务，询问是否可以执行提交操作；参与者执行事务操作，并将其计入本机事务日志；各参与者向协调者反馈事务的响应；②阶段二：如果所有参与者都返回yes,则协调者通知所有参与者提交事务，否则执行回滚事务）

七、你们是如何解决分布式事务的？

1. 强一致性场景：Seata AT
2. 弱一致性场景：Seata TCC
3. 最终一致性场景：MQ

目标六：缓存雪崩、缓存击穿

内容：

一、缓存雪崩：

1. 场景：同一时间段内，由于原有缓存失效，新缓存未到，所有原本应该访问缓存的请求都去访问数据库了，从而对数据库cpu和内存造成巨大压力，严重的会造成数据库宕机，进而形成一系列的连锁反应，造成整个系统崩溃。
2. 解决方案：①加锁排队（根据key获取value值为空时，锁上，从数据库中load完数据再释放锁。其他线程获取锁失败，则等待一段时间，如果缓存已经更新，则直接从缓存中换取数据即可，否则重试获取锁） ② 建立备份缓存，缓存A和缓存B，设置B的缓存时间比A长，先从A读取缓存，A没有读B，且更新AB缓存 ③为key设置不同的失效时间

二、缓存击穿：

1. 场景：用户查询的数据在数据库中没有，所以缓存中也不会有，这样用户查询数据的时候就会绕过缓存，直接查询数据库，每次都返回空。
2. 解决方案：①预先把数据库中的数据加到布隆过滤器，查询缓存之前先通过布隆过滤器判断是否存在，如果不存在直接返回。如果存在则先查缓存，不存在则查DB ② 给空值的数据也加缓存，有效时间设置的短点

三、缓存预热：

1. 场景：系统上线后，将相关的缓存数据直接加载到缓存系统，避免用户先查DB再缓存数据。

四、缓存并发：

1. 场景：高并发，并且缓存失效的情况下，出现多个线程同时访问DB,并更新缓存。会造成数据压力过大和数据不一致问题。
2. 解决方案：加锁排队

目标七：数据库【索引、锁、事务、引擎】

内容：

一、索引：
(1)索引分类：

1. 聚集索引：数据行的物理顺序和列值的逻辑顺序相同（这个列一般指主键）；
2. 非聚集索引：索引的逻辑顺序和磁盘上行的物理存储顺序不同（普通索引、唯一索引、全文索引–MYISAM）；如果查询列中有索引没有覆盖的列，则需要二次查询
   (2)索引设计原则：
3. 最左匹配原则：联合索引情况下，如果索引中的某一列遇到范围查询或者缺少一列作为查询条件，后续索引列就不会命中
4. 为经常作为查询条件的字段建立索引
5. 为经常用作排期和分组的字段建立索引
6. 尽量使用数据量少的索引
7. 尽量使用前缀来做索引

(3)哪些语句不会触发索引： is null, != ,not in,%开头的like

二、存储引擎：

1. MyISAM(mysql5.5之前默认引擎)：不支持事务，不支持外键，不支持行级锁，数据文件和索引文件分开
2. INNODB(mysql5.5之后默认引擎)：支持事务，支持外键，支持行锁(适合处理多并发的更新请求)

三、锁：

(1)锁的分类：

1. 根据性能划分：乐观锁和悲观锁
2. 根据对数据库操作类型划分：读锁（共享锁）和写锁（排他锁）
3. 根据数据粒度划分：行锁、表锁、页锁

(2)行锁表锁页锁比较：

1. 行锁：开销大，加锁慢；会出现死锁；锁定粒度小，锁冲突的概率底，并发度高
2. 表锁：开销小，加锁快；不会出现死锁；锁定粒度大，锁冲突的概率高，并发度低
3. 页锁：开销和加锁时间介于行锁和表锁之间；会出现死锁；锁定粒度介于行锁和表锁之间，并发度一般

(3)死锁：指两个或两个以上的线程因为争夺资源导致互相等待的现象，若无外力作用，他们都将无法推进下去，
例子：session1锁住id=1的行，session2锁住id=2的行；session1获取id=2的锁，session2获取id=1的锁，此时便会出现死锁

(4)如何加锁：

1. MYISAM在执行查询语句（select）的时候会自动给涉及的表加读锁，执行更新操作的时候也会自动给涉及的表加写锁
2. INNODB在执行查询语句（select）的时候不会自动加读锁，执行更新操作的时候会自动加写锁

(5)并发事务带来的问题：

1. 脏读：一个事务对一条数据进行修改，但还没提交，此时另一个事务读取同一条数据
2. 不可重复读：一个事务按相同的查询条件检索之前读取过的数据，却发现其他事务已经删除了该数据
3. 幻读：一个事务按相同的查询条件检索之前读取过的数据，却发现其他事务插入了满足其查询条件的新数据
   解决方法：加锁，所版本并发控制

四、事务：

1. 原子性：事务的全部操作是不能分割的
2. 一致性：几个并行的事务的执行结果和按照顺序串行的执行结果一样
3. 隔离性：事务的执行不受其他事务的干扰
4. 永久性：执行成的事务所修改的数据不会丢失