springboot面试题 springcloud常用注解
大家好，关于springboot面试题很多朋友都还不太明白，今天小编就来为大家分享关于springcloud常用注解的知识，希望对各位有所帮助！
阿里面试必备:100个高频Spring面试题,助你一臂之力!
100个高频Spring面试题，让面试也能聊出花！
1、 Spring是什么？
2、Spring框架的好处？
3、Spring有哪些模块？
4、解释Core Container（Application context）模块
5、BeanFactory实现实例
6、XMLBeanFactory
7、解释AOP模块
8、解释JDBC抽象和DAO模块
9、解释对象/关系映射集成模块
10、解释Spring web模块
11、解释Spring MVC模块
12、Spring配置文件
13、如何才能有多个Spring配置文件？
14、ApplicationContext有哪些常见实现？
15、Bean Factory和ApplicationContext有什么区别？
16、Spring框架的一些最佳实践是什么？
17、使用Spring框架的方式有哪些？
18、我们如何使用Spring创建restful web服务来返回JSON响应结果？
19、Spring vs Spring MVC vs Spring Boot?
20、一个Spring大概是什么样子？
B:依赖注入
21、Spring的IOC容器是什么？
22、IOC的好处有哪些？
23、Spirng中有多少种IOC容器？
24、BeanFactory和ApplicationContext比较
25、什么是Spring中的依赖注入？
26、紧耦合和松耦合有什么区别？
27、IOC（依赖注入）有哪些不同类型？
28、你建议使用构造方法注入还是Setter注入？
C.Spring Beans
29、Spring beans是什么？
30、Spring bean定义包含什么？
31、如何向Spring容器提供配置元数据？
32、怎么定义bean的作用域？
33、说明Sprig支持的bean作用域
34、单例作用域是线程安全的吗？
35、解释Spring Bean的声明周期
36、有哪些重要的bean生命周期方法？你能重写它们吗？
37、Spring的内部bean是什么？
38、如何在Spring中注入Java集合？
39、什么是Spring Bean装配？
40、什么是Bean自动装配？
41、解释不同类型的自动装配
42、自动注入有限制吗？
43、你能在Spring中注入null和空字符串吗？
D.Spring注解
44、有哪些重要的Spring注解？
45、@RequestParam注解的作用是什么？
46、注解@Primary的重要性
47、XML配置和注解之间有什么区别？
48、@SpringBootApplication的作用是什么？
49、解释@InitBinder？
50、定义@ControllerAdvice
100个高频Spring面试题，让面试也能聊出花！
51、我们可以将一个个对象作为控制器处理程序方法的响应吗？
52、解释@ModelAttribute？
53、@RequestMapping注解
54、什么是spring中基于java的配置？给出一注解示例
55、什么是基于注解的容器配置？
56、如何打开注解装配？
E.Spring数据访问
57、Spring JDBC API中有哪些类？
58、如何在Spring框架中更高效地使用JDBC？
59、JdbcTemplate
60、如何通过spring JdbcTemplate获取数据？
61、NamedParameterJdbcTemplate的优点是什么？
62、什么是SpringJDBCTemplate类以及如何使用它？
63、 JDBC和Spring JDBC有什么区别？
64、Spring DAO支持
65、使用Spring访问Hibernate有哪些方式？
66、Spring支持的ORM
67、如何使用HibernateDaoSupport集成Spring和Hibernate？
68、Spring支持的事务管理类型？
69、Spring框架的事务管理有哪些优点？
70、哪种事务管理类型更可取？
F:Spring AOP
71、解释AOP
72、AOP有哪些优点？
73、AOP有哪些实现？
74、AOP术语有哪些？
75、切面
76、连接点
77、通知
78、切点
79、什么是引入？
80、什么是目标对象？
81、什么是代理？
82、有哪些不同类型的代理？
83、什么是植入。什么是植入应用的不同点？
84、Spring AOP中关注点和横切关注点有什么区别?
85、解释基于XML Schema方式的切面实现
86、解释基于注解的切面实现
G.Spring Model View Controller(MVC)
87、什么是Spring MVC框架？
88、创建spring mvc应用程序所需的最少配置是什么？
89、说出Spring MVC请求处理的主要流程？
90、DispatcherServlet
91、WebApplicationContext
92、 Spring MVC中的控制器是什么？
93、你如何将spring mvc框架与MVC架构联系起来？
94、Spring MVC中的ViewResolver是什么？
95、MultipartResolver是什么？怎么使用？
96、如何在spring mvc应用程序中上传文件？
97、Spring Web MVC怎么校验数据？
这里有三种方式去提供校验：使用注解、手动校验、或者两者混合。
98、什么是springmvc拦截器以及如何使用它？
H.扩展
99、Spring Security是什么？
100、为什么要用SpringBoot
（需要这份spring面试题答案PDF版，可以加群：927953692免费领取）
面试必问之spring 面试题
什么是 Spring Boot?
多年来，随着新功能的增加，spring变得越来越复杂。只需访问 页面，我们就会看到可以在我们的应用程序中使用的所有 Spring项目的不同功能。如果必须启动一个新的 Spring项目，我们必须添加构建路径或添加 Maven依赖关系，配置应用程序服务器，添加 spring配置。因此，开始一个新的 spring项目需要很多努力，因为我们现在必须从头开始做所有事情。
Spring Boot是解决这个问题的方法Spring Boot已经建立在现有 spring框架之上使用
spring启动，我们避免了之前我们必须做的所有样板代码和配置。因此，Spring帮助我们以最少的工作量，更加健壮地使用现有的 Spring功能。
Spring Boot有哪些优点? Spring Boot的优点有:
Boot可以
减少开发，测试时间和努力。
使用 JavaConfig有助于避免使用 XML。
避免大量的 Maven导入和各种版本冲突。
提供意见发展方法。
通过提供默认值快速开始开发
没有单独的 Web服务器需要这意味着你不再需要启动 TomcatGlassfish或其他任何东西
需要更少的配置因为没有 web.xml文件。只需添加用@ Configuration注释的类，然后添加用@Bean注释的方法，Spring将自动加载对象并像以前一样对其进行管理。您甚至可以将@Autowired添加到 bean方法中，以使 Spring自动装入需要的依赖关系中。基于环境的配置使用这些属性，您可以将您正在使用的环境传递到应用程序:- Dspring.profiles.active={enviornment}。在加载主应用程序属性文件后，Spring将在(application{environment}.properties)中加载后续的应用程序属性文件。
什么是 Spring Profiles?
Spring Profiles允许用户根据配置文件(dev，test，prod等)来注册 bean。因此，当应用程序在开发中运行时，只有某些 bean可以加载，而在 PRODUCTION中，某些其他 bean可以加载。假设我们的要求是 Swagger文档仅适用于 QA环境，并且禁用所有其他文档。这可以使用配置文件来完成。Spring Boot使得使用配置文件非常简单。
什么是 Spring Batch?
Spring Boot Batch提供可重用的函数，这些函数在处理大量记录时非常重要，包括日志/跟踪，事务管理，作业处理统计信息，作业重新启动，跳过和资源管理。它还提供了更先进的技术服务和功能，通过优化和分区技术，可以实现极高批量和高性能批处理作业。简单以及复杂的大批量批处理作业可以高度可扩展的方式利用框架处理重要大量的信息。
什么是 FreeMarker模板?
FreeMarker是一个基于 Java的模板引擎，最初专注于使用 MVC软件架构进行动态网页生成。使用 Freemarker的主要优点是表示层和业务层的完全分离。程序员可以处理应用程序代码，而设计人员可以处理 html页面设计。最后使用 freemarker可以将这些结合起来，给出最终的输出页面。
如何使用 Spring Boot实现异常处理?
Spring提供了一种使用ControllerAdvice处理异常的非常有用的方法。我们通过实现一个 ControlerAdvice类，来处理控制器类抛出的所有异常。
面试- 必知必会的微服务面试题
SOA与微服务的区别？
SOA的提出是在企业计算领域，就是要将紧耦合的系统，划分为面向业务的，粗粒度，松耦合，无状态的服务。服务发布出来供其他服务调用，一组互相依赖的服务就构成了SOA架构下的系统。
基于这些基础的服务，可以将业务过程用类似BPEL流程的方式编排起来，而BPEL反映的是业务处理的过程，这些过程对于业务人员更为直观，调整也比hardcode的代码更容易。
当然企业还需要对服务治理，比如服务注册库，监控管理等。
我们知道企业计算领域，如果不是交易系统的话，并发量都不是很大的，所以大多数情况下，一台服务器就容纳将许许多多的服务，这些服务采用统一的基础设施，可能都运行在一个应用服务器的进程中。虽然说是面向服务了，但还是单一的系统。
而微服务架构大体是从互联网企业兴起的，由于大规模用户，对分布式系统的要求很高，如果像企业计算那样的系统，伸缩就需要多个容纳续续多多的服务的系统实例，前面通过负载均衡使得多个系统成为一个集群。但这是很不方便的，互联网企业迭代的周期很短，一周可能发布一个版本，甚至可能每天一个版本，而不同的子系统的发布周期是不一样的。而且，不同的子系统也不像原来企业计算那样采用集中式的存储，使用昂贵的Oracle存储整个系统的数据，二是使用MongoDB，HBase，Cassandra等NOSQL数据库和Redis，memcache等分布式缓存。那么就倾向采用以子系统为分割，不同的子系统采用自己的架构，那么各个服务运行自己的Web容器中，当需要增加计算能力的时候，只需要增加这个子系统或服务的实例就好了，当升级的时候，可以不影响别的子系统。这种组织方式大体上就被称作微服务架构。
微服务与SOA相比，更强调分布式系统的特性，比如横向伸缩性，服务发现，负载均衡，故障转移，高可用。互联网开发对服务治理提出了更多的要求，比如多版本，比如灰度升级，比如服务降级，比如分布式跟踪，这些都是在SOA实践中重视不够的。
Docker容器技术的出现，为微服务提供了更便利的条件，比如更小的部署单元，每个服务可以通过类似Node.js或Spring Boot的技术跑在自己的进程中。可能在几十台计算机中运行成千上万个Docker容器，每个容器都运行着服务的一个实例。随时可以增加某个服务的实例数，或者某个实例崩溃后，在其他的计算机上再创建该服务的新的实例。
如何拆分服务？
要围绕业务模块进行拆分，拆分粒度应该保证微服务具有业务的独立性与完整性，尽可能少的存在服务依赖，链式调用。但是，在实际开发过程中，有的时候单体架构更加适合当前的项目。实际上，微服务的设计并不是一蹴而就的，它是一个设计与反馈过程。因此，我们在设计之初可以将服务的粒度设计的大一些，并考虑其可扩展性，随着业务的发展，进行动态地拆分也是一个不错的选择。
REST的名称"表现层状态转化"中，省略了主语。"表现层"其实指的是"资源"（Resources）的"表现层"。
所谓"资源"，就是网络上的一个实体，或者说是网络上的一个具体信息。它可以是一段文本、一张图片、一首歌曲、一种服务，总之就是一个具体的实在。你可以用一个URI（统一资源定位符）指向它，每种资源对应一个特定的URI。要获取这个资源，访问它的URI就可以，因此URI就成了每一个资源的地址或独一无二的识别符。
客户端用到的手段，只能是HTTP协议。具体来说，就是HTTP协议里面，四个表示操作方式的动词：GET、POST、PUT、DELETE。它们分别对应四种基本操作：GET用来获取资源，POST用来新建资源（也可以用于更新资源），PUT用来更新资源，DELETE用来删除资源。
实际上呢，不是所有的东西都是“资源”，尤其是在业务系统中，缺点如下：
有个接口是更新订单状态，你是用上面的GET POST PUT DELETE哪个呢，看样子应该是PUT，但是路径呢PUT/tickets/12
我有时候多个接口，更新订单收款状态，更新订单支款状态，更新订单结算状态；
Restful的路径明显不友好不够用；
再比如，批量删除，DELETE还好用么，DELETE/tickets/12#删除ticekt 12这种形式如果要传数组怎么办，url是不是不够友好？
再比如，Resuful要求 GET/tickets#获取ticket列表。我们曾经有个需求，对方会把不超过1000个订单id传给我们，我们系统过滤其中一部分特殊订单；这也是个查询服务，用GET/tickets#获取ticket列表的形式，1000个订单id显然是超过GET url长度的，这里也不合适；再者，我想开发多个条件查询列表服务，路径这么浅显然不合适；
实际业务中，我们webapi的路径是这样的：systemAlias/controller/action
总结下规则：
简单查询尽量用GET，好处是可以直接带查询参数copy api路径；
复杂查询和更新用POST，用的最多；
不用PUT和DELETE，原因是增加复杂度，并没有带来什么好处
看看BAT的很多openapi，也是写着restful，实际没有严格遵守，都是get和post，这是也很多人不知道put和delete的原因
如：
//根据订单id获取订单
GET oms/order/queryOrderById?id=value1¶m2=value2
//根据订单id List获取订单
POST oms/order/queryOrderByIdList
//根据条件查询订单，带分页参数
POST oms/order/queryOrderByCondition
//更新订单收款状态
POST oms/order/updateOrderCollectionStatus
//批量更新订单收款状态
POST oms/order/updateOrderCollectionStatusInBatch
//批量更新订单收款状态
POST oms/order/updateOrderCollectionStatusInBatch
//批量删除订单，带操作来源
POST oms/order/deleteOrderInBatch
微服务如何进行数据库管理？
CAP原理(CAP Theorem)
在足球比赛里，一个球员在一场比赛中进三个球，称之为帽子戏法(Hat-trick)。在分布式数据系统中，也有一个帽子原理(CAP Theorem)，不过此帽子非彼帽子。CAP原理中，有三个要素：
CAP原理指的是，这三个要素最多只能同时实现两点，不可能三者兼顾。
因此在进行分布式架构设计时，必须做出取舍。而对于分布式数据系统，分区容忍性是基本要求，否则就失去了价值，因此设计分布式数据系统，就是在一致性和可用性之间取一个平衡。
对于大多数 WEB应用，其实并不需要强一致性，因此牺牲一致性而换取高可用性，是目前多数分布式数据库产品的方向。
当然，牺牲一致性，并不是完全不管数据的一致性，否则数据是混乱的，那么系统可用性再高分布式再好也没有了价值。
牺牲一致性，只是不再要求关系型数据库中的强一致性，而是只要系统能达到最终一致性即可，考虑到客户体验，这个最终一致的时间窗口，要尽可能的对用户透明，也就是需要保障“用户感知到的一致性”。
通常是通过数据的多份异步复制来实现系统的高可用和数据的最终一致性的，“用户感知到的一致性”的时间窗口则取决于数据复制到一致状态的时间。
最终一致性(eventually consistent)
对于一致性，可以分为从客户端和服务端两个不同的视角。
从客户端来看，一致性主要指的是多并发访问时更新过的数据如何获取的问题。
从服务端来看，则是更新如何复制分布到整个系统，以保证数据最终一致。
一致性是因为有并发读写才有的问题，因此在理解一致性的问题时，一定要注意结合考虑并发读写的场景。
从客户端角度，多进程并发访问时，更新过的数据在不同进程如何获取的不同策略，决定了不同的一致性。
对于关系型数据库，要求更新过的数据能被后续的访问都能看到，这是强一致性;如果能容忍后续的部分或者全部访问不到，则是弱一致性;如果经过一段时间后要求能访问到更新后的数据，则是最终一致性。
从服务端角度，如何尽快将更新后的数据分布到整个系统，降低达到最终一致性的时间窗口，是提高系统的可用度和用户体验非常重要的方面。
那么问题来了，如何实现数据的最终一致性呢?答案就在事件驱动架构。
最佳解决办法是采用事件驱动架构。其中碰到的一个挑战是如何原子性的更新状态和发布事件。有几种方法可以解决此问题，包括将数据库视为消息队列和事件源等。
从目前技术应用范围和成熟度看，推荐使用第一种方式(本地事务发布事件)，来实现事件投递原子化，即可靠事件投递。
SpringCloud和Dubbo有哪些区别？
总体来说，两者各有优势。虽说后者服务调用的功能，但也避免了上面提到的原生RPC带来的问题。而且REST相比RPC更为灵活，服务提供方和调用方的依赖只依靠一纸契约，不存在代码级别的依赖，这在强调快速演化的微服务环境下，显得更加合适。
品牌机与组装机的区别：很明显SpringCloud比dubbo的功能更强大，覆盖面更广，而且能够与SpringFramework、SpringBoot、SpringData、SpringBatch等其他Spring项目完美融合，这些对于微服务至关重要。使用Dubbo构建的微服务架构就像组装电脑、各环节我们选择自由度高，但是最总可能会因为内存质量而影响整体，但对于高手这也就不是问题。而SpringCloud就像品牌机，在Spring Source的整合下，做了大量的兼容性测试，保证了机器拥有更高的稳定性。
在面临微服务基础框架选型时Dubbo与SpringCloud只能二选一。
好了，文章到这里就结束啦，如果本次分享的springboot面试题和springcloud常用注解问题对您有所帮助，还望关注下本站哦！