面试篇 （2022）

前言

每年都要尝试面试，这个是在…额，忘记是谁说的了，但是我觉得说得很有道理，因此不管要不要重新寻找工作都要尝试吗，面试一波

这一波主要是面试一个微服务开发岗位的面试

面试题

基本上都是没有答出来的问题，这些问题印象比较深刻

一、dubbo 服务发现的过程

• Provider(提供者)绑定指定端口并启动服务
• 指供者连接注册中心，并发本机IP、端口、应用信息和提供服务信息发送至注册中心存储
• Consumer(消费者），连接注册中心 ，并发送应用信息、所求服务信息至注册中心
• 注册中心根据 消费 者所求服务信息匹配对应的提供者列表发送至Consumer 应用缓存。
• Consumer 在发起远程调用时基于缓存的消费者列表择其一发起调用。
• Provider 状态变更会实时通知注册中心、在由注册中心实时推送至Consumer

二、dubbo每次服务调用都要去zookeeper获取信息吗

• 答:不需要
  • 从上面的流程可以知道它是存储在Consumer应用缓存中的

三、讲讲mysql的索引树

• mysql的索引树是B+树
• B+树是B树的加强版
• B树的特点：每一个节点都是由两个数据项三个指针组成的，因此它的高度比一般的二叉树更低，查询速度更快，但是他对于数据排序 的效率不高
• B+树区别于B树的特点：B+树非叶子节点不存在值只有键，每个叶子节点存在头尾指针，维护了一个链表结构，存在一定的顺序排序，因此它的查询效率特别高，特别是范围查询的时候

四、dubbo和spring cloud 和spring cloud alibaba 有什么区别

• dubbo和spring cloud
  • 网络：dubbo是二进制传输优于cloud的http方式，它占用的带宽会小一点
  • 架构： dubbo的核心只有几个（生产者、消费者、注册中心、监控中心），但是cloud因为是spring，因此的它架构可以有断路器、网关、消息总线等，而dubbo当也可以是实现这些功能，但是它的包容性就比不上cloud了
  • 服务调用：dubbo是RPC，cloud是REST API
• spring cloud 和spring cloud alibaba

	SpringCloud	SpringCloudAlibaba
注册中心	Eureka	nacos
消息中间件	无(第三方替代方案：rabbitmq)	RecketMQ
分布式事务解决方案	无	Seata
网关	zuul	gateway
熔断降级	Eureka	Sentinel

五、Spring 循环依赖是怎么解决的

• 参考链接
• 1、构造器的循环依赖：这种依赖spring是处理不了的，直 接抛出BeanCurrentlylnCreationException异常
• 2、非单例循环依赖：无法处理
• 3、单例模式下的setter循环依赖：通过“三级缓存”处理循环依赖。
  • 这三级缓存的作用分别是：
    singletonFactories ： 进入实例化阶段的单例对象工厂的cache （三级缓存）
    earlySingletonObjects ：完成实例化但是尚未初始化的，提前暴光的单例对象的Cache （二级缓存）
    singletonObjects：完成初始化的单例对象的cache（一级缓存）
  • 流程：
    开始初始化对象A，将A构造放入三级缓存，
    开始注入A的依赖B，将B构造放入三级缓存，
    开始注入B的依赖A，发现A在三级缓存中有，将A放入二级缓存中，注入完成，将B放入一级缓存中
    将B注入给A，A注入完成，将A放入一级缓存中
    循环依赖注入结束 完成

六、Spring 事务的原理

• 原理：AOP。声明式事务管理建立在AOP之上，其本质是对方法前后进行拦截，然后在目标方法开始之前创建或者加入一个事务，执行完目标方法之后根据执行的情况提交或者回滚。

七、ACP框架

• C: 一致性(Consistency) (所有节点在同一时间具有相同的数据)
  A: 可用性(Availability) (保证每个请求不管成功或者失败都有响应)
  P: 分隔容忍(Partition tolerance) (系统中任意信息的丢失或失败不会影响系统的继续运作)

八、说一下C指的是什么？它是怎么实现的？

• zookeeper和consul 基本上实现一致性原理都差不多，就是，在leader挂掉了之后，重新选举出leader之前会导致集群的服务不可以用，因此这也是为什么不能保证高可用性的原因

九、Spring IOC和AOP的实现

• 这个不讲了

十、jvm的内存结构

• 详细
• 程序计数器、虚拟机栈、本地方法栈、堆、本地方法区

十一、GC回收机制，什么条件下进行回收，回收的代数放哪里？

• 什么时候进行回收？
  • 1、系统空闲的时候
  • 2、堆内存满了之后
  • 3、主动调用System.gc()尝试进行回收
• java采用**“可达性分析”算法来判断对象**是否存活
• 复制算法(新生代回收算法)、标记整理算法(老年代回收算法)
• 分代收集算法
  当前JVM垃圾收集都采用的是"分代收集(Generational Collection)"算法，这个算法并没有新思想，只是根据对象存活周期的不同将内存划分为几块。
  一般是把Java堆分为新生代和老年代。在新生代中，每次垃圾回收都有大批对象死去，只有少量存活，因此我们采用复制算法；而老年代中对象存活率高、没有额外空间对它进行分配担保，就必须采用"标记-清理"或者"标记-整理"算法。
• Minor GC又称为新生代GC : 指的是发生在新生代的垃圾收集。因为Java对象大多都具备朝生夕灭的特性，因此Minor GC(采用复制算法)非常频繁，一般回收速度也比较快。
• Full GC 又称为老年代GC或者Major GC : 指发生在老年代的垃圾收集。出现了Major GC，经常会伴随至少一次的Minor GC(并非绝对，在Parallel Scavenge收集器中就有直接进行Full GC的策略选择过程)。Major GC的速度一般会比Minor GC慢10倍以上。