单列：每次都是，protoType每次都new一个

ioc容器的初始化

1、Springmvc 运行流程

1. 用户发送请求给控制器DispatcherServlet(核心控制器)
2. 核心控制器通过调用HandlerMapping（映射处理器），根据注解或者xml 请求获取Handle处理器；
3. Handle处理器会生成一个处理器对象返回给核心控制器
4. 核心控制器拿着处理器对象调用适配处理器（HandlerAdapter），调用具体的处理器controller对象
5. 具体的处理器会生成一个ModelAndView，返回给核心控制器
6. 核心控制器携带ModelAndView传给ViewResolver解析
7. 解析后返回具体的View(视图)给核心控制器
8. 核心控制器对View进行渲染视图
9. 最后将视图返回给前端

2、Spring 的注入方式

23、 Application Context获取的几种方式

2、Spring常用注解

事务：

1. @EnableTransactionManagement

import(………)

1. @Order（控制多个bean的执行顺序）

2. @Async 线程池的注解

3. 切面

4. 配置

3、Springmvc常用注解

1. 路径

、

1. 参数

1. 统一异常处理：

RestControllerAdvice里面包含了@ControllerAdvice和@ResonseBody
、
请求参数
、
跨域：

4、Springboot的常见注解

1. propertise
2. @SpringBootApplication
3. @EnableAutoConfiguration
4. @SpringBootConfugruation
5. @ComponentScan
6. @AutoConfigurationPackage

5、Springmvc异常处理机制

6、Configuration

7、SpringBoot的自动化装配：

AutoConfiguanationPakages这个Bean


@ConditionalOnClass

8、什么是IOC 和 DI

IOC就是控制反转，是指创建对象的控制权的转移，以前创建对象的主动权和时机是由自己把控的，而现在这种权力转移到Spring容器中，并由容器根据配置文件去创建实例和管理各个实例之间的依赖关系，对象与对象之间松散耦合，也利于功能的复用。DI依赖注入，和控制反转是同一个概念的不同角度的描述，即 应用程序在运行时依赖IoC容器来动态注入对象需要的外部资源。
DI—Dependency Injection，即“依赖注入”：组件之间依赖关系由容器在运行期决定，形象的说，即由容器动态的将某个依赖关系注入到组件之中。通过依赖注入机制，我们只需要通过简单的配置，而无需任何代码就可指定目标需要的资源，完成自身的业务逻辑，而不需要关心具体的资源来自何处，由谁实现。
ioc容器里面重要的几个接口

9、IOC容器的初始化流程：

10、IOC容器getBean流程

10、Bean的循环依赖问题：

• 如果对象都是多例对象 会报循环依赖异常

  单例对象:

• 如果是通过构造器依赖的属性, 会报循环依赖异常

• 如果是通过属性依赖产生的循环依赖, 默认允许循环依赖
• 设置allowCircularReferences为false 会报循环依赖异常

二级缓冲用来解决尚未填充属性的bean
三级缓冲有时候用来存储代理对象的处理，在使用aop进行增强的时候

10、 Bean的覆盖问题

默认情况: 同一个配置文件中出现id相同的bean会报错
不同的配置文件出现id相同的bean 后加载的bean会将先加载的bean覆盖掉
称为bean的覆盖
bean的覆盖不会报错，但可能影响我们的项目 ， 可以通过属性设置 不允许bean的覆盖
allowBeanDefinitionOverriding设置为false

11、Bean的生命周期：

1. 实例化对象（空参构造）
2. 设置属性
3. Bean实现了BeanNameAware接口，执行setBeanName方法设置Bean的名称
4. 实现BeanFactoryAware接口，得到IOC容器实例ApplicationContext

12、事务的传播行为：

事务的第一个方面是传播行为（propagation behavior）。当事务方法被另一个事务方法调用时，必须指定事务应该如何传播。例如：方法可能继续在现有事务中运行，也可能开启一个新事务，并在自己的事务中运行。Spring定义了七种传播行为：

13、@Confination（proxyBeanMethods=true）单例模式

14、 @Import

@ Import（User.class）

@Import(MyConfig.class)

批量导入：String【】

15、@ConfigurationProperties

16、Eureka

Eureka: 宕机的话，不会宕机有缓冲，新的服务无法注册到Eureka；

Ereka集群就是相互注册；数据之间进行数据同步，没有主从模式

自我保护机制：

Eureka的注册：

17、SOA

服务粒度
SOA 的服务粒度要粗一些，而微服务的服务粒度要细一些。例如，对一个电商企业来说，商品管理系统是一个 SOA 架构中的服务；而如果采用微服务架构，则商品管理系统会被拆分为更多的服务，比如商品基本信息管理、供应商管理、入库管理等更多服务。

服务通信
SOA 采用了 ESB 作为服务间通信的关键组件，负责服务定义、服务路由、消息转换、消息传递，一般情况下都是重量级的实现。微服务则使用统一的协议和格式，例如：HTTP RESTful 协议、TCP RPC 协议，不需要 ESB 这样的重量级实现。

服务交付
SOA 对服务的交付没有特殊要求，因为 SOA 更多考虑的是兼容已有的系统；微服务的架构理念则要求快速交付，相应地要求采取自动化测试、持续集成、自动化部署、自动化运维等的最佳实践。

应用场景
SOA 更加适合于庞大、复杂、异构的企业级系统。这类系统的典型特征就是很多系统已经发展多年，各个服务具有异构性，比如：采用不同的企业级技术、有的是内部开发的、有的是外部购买的，无法完全推倒重来或者进行大规模的优化和重构。因为成本和影响太大，只能采用兼容的方式进行处理，而承担兼容任务的就是 ESB。

微服务更加适合于快速、轻量级、基于 Web 的互联网系统，这类系统业务变化快，需要快速尝试、快速交付；同时基本都是基于 Web，虽然开发技术可能差异很大（例如，Java、.NET、PHP 等），但对外接口基本都是提供 HTTP RESTful 风格的接口，无须考虑在接口层进行类似 SOA 的 ESB 那样的处理。

18、http协议与tcp协议区别

1、性质不同：
http是一个简单的请求-响应协议。TCP是一种面向连接的、可靠的、基于字节流的传输层通信协议。

2、连接不同：
TCP连接到不同但互连的计算机通信网络的主计算机中的成对进程之间依靠TCP提供可靠的通信服务。http通常运行在TCP之上。指定了客户端可能发送给服务器什么样的消息以及得到什么样的响应。

3、功能不同：
当应用层向TCP层发送用于网间传输的、用8位字节表示的数据流，TCP则把数据流分割成适当长度的报文段，最大传输段大小（MSS）通常受该计算机连接的网络的数据链路层的最大传送单元（MTU）限制。HTTP协议是基于请求/响应范式的。

4、HTTP：
超文本传输协议，是应用层的协议，以TCP为基础
TCP：传输控制协议，是传输层的协议，以IP协议为基础

5、从本质上说:
Http协议是建立在TCP协议基础之上的。当浏览器需要从服务器 获取网页数据的时候，会发出一次http请求。Http通过TCP建立起一个到服务器的通道。
当一个网页完成之后，客户端和服务器端之间用于传输HTTP数据的TCP连接不会关闭，如果客户端再次访问这个页面时，会继续使用这一条已经建立的连接Keep-Alive不会永久保持连接，它有一个保持时间，可以在不同的服务器软件中设定这个时间，

6、连接状态
Http是无转态的连接，TCP是有状态的长连接

19、JAVA异常的理解：

20、应用层：

21、 BIO、NIO、AIO 有什么区别？（高薪常问）

BIO：Block IO 同步阻塞式 IO，就是我们平常使用的传统 IO，它的特点是模式简单使用方便，并发处理能力低。
NIO：New IO 同步非阻塞 IO，是传统 IO 的升级，客户端和服务器端通过 Channel（通道）通讯，实现了多路复用。
AIO：Asynchronous IO 是 NIO 的升级，也叫 NIO2，实现了异步非堵塞 IO ，异步 IO 的操作基于事件和回调机制。

22、sql优化

23、Java中4种权限修饰符及其作用范围

、
对于class的权限修饰只可以用public和default(默认的)。
public类可以在任意地方被访问。
default类只可以被同一个包内部的类访问。

24、线程池：

线程的执行状态：

23、 Application Context获取的几种方式

三、RestFul和RPC的区别

1、从本质区别上看，RPC是基于TCP实现的，RestFul是基于HTTP来实现的。
2、从传输速度上来看，因为HTTP封装的数据量更多所以数据传输量更大，所以RPC的传输速度是比RestFul更快的。
3、因为HTTP协议是各个框架都普遍支持的。在toC情况下，因为不知道情况来源的框架、数据形势是什么样的，所以在网关可以使用RestFul利用http来接受。而在微服务内部的各模块之间因为各协议方案是公司内部自己定的，所以知道各种数据方式，可以使用TCP传输以使各模块之间的数据传输更快。所以可以网关和外界的数据传输使用RestFul，微服务内部的各模块之间使用RPC。
4、RestFul的API的设计上是面向资源的，对于同一资源的获取、传输、修改可以使用GET、POST、PUT来对同一个URL进行区别，而RPC通常把动词直接体现在URL上
————————————————
版权声明：本文为CSDN博主「温文尔雅的清欢渡」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/weixin_46460843/article/details/118633583

23、结束语：

最后的话就是说希望各位面试官能给我这次机会，之前的话一面的话是那个方老师跟我讲过，刚好他那个团队的话缺一个开发吗，然后的话希望自己能够加入这个团队，然后就是
我也相信自己能在这个团队中成长，能够帮助团队去做一些事情。不管是ssm还是说微服务我这边的话去干活的话都是没什么问题的