spring常用的注解有哪些 说出SpringMVC常用的5个注解

大家好，感谢邀请，今天来为大家分享一下spring常用的注解有哪些的问题，以及和说出SpringMVC常用的5个注解的一些困惑，大家要是还不太明白的话，也没有关系，因为接下来将为大家分享，希望可以帮助到大家，解决大家的问题，下面就开始吧！

spring的核心技术有哪些

一：控制反转

**1.**Spring三个核心思想是什么：控制反转，依赖注入和面向切面编程。

**2.**Spring最核心，最基础的概念是什么？将spring类比java，java最核心，最基础的概念就是object了。java中，所有的操作都是针对object的（基础类型除外），java中，一切皆对象，一切都是object。类比下来，spring中最基础的概念是bean。在spring中，所以的类都可以认为是一个bean。（个人认为）在spring中的所有文件，都可以认为是注册了的bean和未注册的bean。spring中所有操作都是针对bean的操作。自然，spring的三大核心思想中操作的对象，也是bean.

3.代码讲解IOC控制反转

（1）定义一个接口publicinterfaceIPrint{/***onLine:对象需要实现这个方法来实现打印对象的功能*void返回类型*/StringprintObject();}12345678

（2）实现接口publicclassUserBeanimplementsIPrint{@OverridepublicStringprintObject(){//TODOAuto-generatedmethodstubSystem.out.println("打印对象UserBean:");return"abc";}}publicclassMyBeanimplementsIPrint{@OverridepublicStringprintObject(){//TODOAuto-generatedmethodstubSystem.out.println("打印对象MyBean:");returnnull;}}12345678910111213141516171819

（3）测试IPrintprint=newUserBean();print.printObject();12很正常的执行结果（“打印对象UserBean：”）。但是这时候我想修改一下，打印第二个实现类，这时候就需要修改代码了，修改代码毕竟是不符合开闭原则，又比较麻烦的事，这时候就需要用到spring的控制反转：对继承了接口IPrint的具体实现类的具体对象的创建，不依赖于调用他的客户端代码，而将控制权交给spring（其实就是xml文件），这就是控制反转。

4.控制反转实现测试类：/读取配置文件（将配置文件中的bean加载进内存）ApplicationContextctx=newClassPathXmlApplicationContext("/testSpring/resources/applicationContext.xml");//获取的实例IPrintbean=(IPrint)ctx.getBean("userBean");//调用方法bean.printObject();1234567891011121314151617181920212223242526如果想要打印另一个实现类，只要修改配置文件：

1总结：从spring的控制反转实现可以看出，客户端的实现不必去修改代码，从而达到了松耦合的目的。控制反转最后就是将主动权交给接口。

二：依赖注入常用的注入方式有四种：1.属性注入2.构造方法注入3.工厂方法注入4.注解注入(1)属性注入packagetest;publicclassUser{privateStringname;privateStringgender;publicStringgetName(){returnname;}publicUser(Stringname,Integerage){this.name=name;this.age=age;}publicvoidsetName(Stringname){this.name=name;}publicStringgetGender(){returngender;}publicvoidsetGender(Stringgender){this.gender=gender;}@OverridepublicStringtoString(){return"User[name="+name+",gender="+gender+"]";}}1234567891011121314151617181920212223242526

spring.xml文件配置：1234测试函数：publicstaticvoidmain(Stringargs[]){ApplicationContextatc=newClassPathXmlApplicationContext("spring.xml");Useruser=(User)atc.getBean("user");System.out.println(user);//printUser[name=cup,gender=man]}123456而如果我们把POJO中的getName方法去掉，结果不变，但setName方法删掉，我们再运行程序，会看到

2)构造函数注入：在xml文件定义Bean：调用测试函数：publicstaticvoidmain(Stringargs[]){ApplicationContextatc=newClassPathXmlApplicationContext("spring.xml");Useruser=(User)atc.getBean("user1");System.out.println(user.getName()+"——"+user.getAge());//printcup——25}12345678

(3)工厂方法注入i.非静态工厂方法先定义工厂类：packagetest;publicclassUserFactory{publicUsercreateUser(){Useruser=newUser("cup",25);returnuser;}}12345678进行Bean配置：12调用测试函数：publicstaticvoidmain(Stringargs[]){ApplicationContextatc=newClassPathXmlApplicationContext("spring.xml");Useruser=(User)atc.getBean("user3");System.out.println(user.getName()+"——"+user.getAge());//printcup——25}123456(4)注解注入i.对类成员变量注解使用@Autowire实现自动注入,格式如：@ComponentpublicclassIdCard{.....}1234publicclassUser{//Autowired默认按类型注入，@required表明如果找不到对应的bean则为null，但如果设定为true(也是默认值)，则要求一定要找到匹配的bean，否则会抛出异常。//Qualifier常用于容器有一个以上相同类型的Bean,通过指定名字来指定唯一的Bean@Autowired(required=false)@Qualifier("idCard")privateIdCardidCard;//也可以将IdCard配置在xml文件中注入.....}12345678ii.对类成员方法进行注解@Autowiredpublicvoidinit(@Qualifier（“usar1")Useruser1,@Qualifier("user2")Useruser2){this.user1=user1;this.user2=user2;}

spring的事务注解作用于哪一层

作用在c等，既控制层。

SpringBoot中，@Autowired和@Resource使用起来到底有什么区别

这个问题也有一段时间了，当初也就随手一写，直到最近还有网友在看，为了保证大家看的时候不会出现理解方面的问题，于2021-5-10编辑一次，希望能更加严谨一点，至少不会误导大家。

首先，这个问题有点不准确，这2个注解是使用Spring框架过程中常用的注解，而SpringMVC和SpringBoot等框架都是基于Spring的进阶框架，并没有对这2个注解的使用进行修改或者调整，所以，只讨论Spring框架如何处理这2个注解即可，而不是讨论在SpringBoot中的使用区别。

【结论】在绝大部分情况下，使用这2个注解的任何一个都可以实现自动装配，在使用方面是无感的。

如果要讨论区别，基本上就是2点：

所属不同：@Resource注解是javax包的；@Autowired是Spring声明的；装配机制不同：@Resource会优先byName来装配，即使名称不匹配，也会尝试byType来装配；@Autowired则是先查找匹配类型对象的数量，如果有且仅有1个，则直接装配，如果为0个，则无法装配，此时需要考虑该注解的required属性，默认是true，就会因为“必须装配却没有匹配类型的对象”而抛出异常，如果显式的设置为false，则不装配，保持被自动装配的属性为null值，如果匹配类型的对象超过1个，则会尝试byName，如果成功，则装配，如果失败，则抛出异常。

如果一定要说还有其它区别，可以是：

作用范围不同：@Resource用于对字段、Setter方法进行注解，@Autowired可用于构造方法、Setter方法和字段；当同一种类型的对象有多个时（例如声明的类型是接口，在Spring容器中有2个或多个实现类的对象），需要指定名称，@Resource可直接配置name属性来指定bean-name，而@Autowired需要配合@Qualifer注解，由@Qualifer注解来指定bean-name，当用于字段时，直接在字段的声明之前使用这2个注解，当用于Setter方法时，在方法的声明之前使用@Autowired，在方法的参数之前使用@Qualifer；

另外，还有很多关于使用@Autowired的细节问题，例如“是不是不建议使用了”、“到底应该怎么用”等等，所以，接下来主要讨论这些问题。

关于“是不是不建议使用了”，这种问题的主要原因应该是最近几年IntelliJIDEA越来越流行了，而许多版本的IntelliJIDEA对@Autowired的预判是有问题的！也就是说：IntelliJIDEA会在编码期实时预判是否存在可以装配的对象，如果它认为没有，就会报错，事实上，它的判断并不完全准确！

例如，尝试在Service组件中装配一个Mapper接口类型的字段时：

（截图来自IntelliJIDEA2020.1.4）

以上报错就是IntelliJIDEA预判错误导致的，如果使用的是Eclipse就不会有这样的问题，解决方案可以是：

在UserMapper接口上添加@Repository注解；将以上代码中的@Autowired配置为@Autowired(required=false)，因为@Autowired默认是required=true，同时IntelliJIDEA认为没有可装配对象，所以报错，显式的配置为required=false之后，即使IntelliJIDEA认为没有可装配对象也不会报错了；将以上代码中的@Autowired改为@Resource。

再例如在使用SpringSecurity进行配置时也会有类似的问题，只不过这次它认为“存在多个匹配类型的对象”：

（截图来自IntelliJIDEA2020.1.4）

解决以上报错信息的方式可以是：

将声明的UserDetailsService接口类型改为你的UserDetailsServiceImpl实现类类型，例如privateUserDetailsServerImplservice;即可；将以上代码中的@Autowired改为@Resource。

由于许多类似问题都可以通过“将@Autowired改为@Resource”来解决，加上一些相关说法（详见下文），且某些片面的断章取义，导致网上还存在“使用@Resource取代@Autowired”、“以后不要再用@Autowired”的说法，而这些说法都是错误的，没有任何官方（开发工具的IntelliJIDEA，或框架官方Spring）说过这样的话！

首先，使用Spring实现自动装配时，有3种方式：

通过构造方法注入；通过Setter注入（即与字段属性匹配的set方法）；通过字段注入；

基本示例参见下图：

以上图片来自Spring官方提供的资料，可以看到最后还附了个URL，是国外网友写的一篇主题为《whyfieldinjectionisevil》的讨论文章，有兴趣且有一定英语阅读能力的朋友可以自行上网查看全文，大意是“使用字段注入时可能导致NPE”！为什么会这样呢？假设你有如下代码：

如果你因为某种原因直接创建对象，即通过UserServiceservice=newUserService();来创建对象，其中的userRepository属性肯定是没有值的，后续使用这个service对象时，只要涉及调用userRepository就会出现NPE了！

既然UserService是一个组件，为什么还会直接创建对象呢？其实这也算是一个低概率的特殊情况，在彼此不太熟悉的协同工作中可能出现，例如你和我一起开发项目，我对你写的那部分代码不太了解……再就是测试使用时，也可能出现直接创建对象的情况……

如果将代码改为下面这样：

则刚才的问题就不存在了！因为现在的构造方法是需要参数的，你不给参数，就创建不了对象！如果能创建出对象，就肯定给了参数，则userRepository肯定有值，就不会出现NPE！当然，如果你一定要传个null进去就没办法了，Nozuonodiewhyyoutry？

所以，使用构造方法传递参数是一种强制依赖的做法，可以保证不会出现NPE，但是，如果参数太多会不会很奇怪？真的有必要把代码写得这么滴水不漏吗？这个就看你自己了！首先，是IntelliJIDEA并不建议你使用字段注入：

（截图来自IntelliJIDEA2020.1.4）

而Spring的观点，可参见下图：

可以看到，Spring是无所谓的，反正都能用（Springdoesn'tcare,canuseeither），当然，也列举了使用构造方法注入和使用Setter注入的区别（虽然我在前面都是写的字段注入，在NPE问题上，字段注入和Setter注入是一样的）。

既然Spring都无所谓了，我们为什么还要纠结注入方式呢？还是那句话，只要你能保证不出错，怎么都行！可能95%以上的Java从业者不是在写大厂的大型项目，合格的程序员也不会乱写代码，由Setter或字段注入导致NPE的概率本来就极低，不一定需要为了“保证极端情况下也不出错”而刻意的把代码调整为构造方法注入，只要注意规避这个问题即可！

另外，我在上面的代码演示中，在构造方法上加了@Autowired注解，在这里解释一下：

如果类中只存在默认构造方法（无论是你显式的添加的，还是根本不写，由编译器添加的），则无需@Autowired注解，Spring会自动调用，当然，加了也不会出错；如果类中只存在唯一的构造方法，Spring会自动调用，且会自动从Spring容器中找对象装配为调用构造方法的参数，这种情况也是不需要添加@Autowired注解的，加了也不会出错；如果类中存在多个构造方法，且都没有添加@Autowired注解时，当存在无参数构造方法时，Spring会自动调用无参数构造方法，如果你想要Spring调用另外某一个构造方法，就在那个构造方法上添加@Autowired注解；如果类中存在多个构造方法，且超过1个构造方法上都添加了@Autowired注解……你别作，你不需要知道Spring怎么处理，你只要把@Autowired删得只有1个了，就肯定没问题！

所以，从道理上来说，应该推荐显式的为某1个构造方法添加@Autowired注解，哪怕是不需要添加也能用，因为这样会保证多构造方法的情况下代码更加直观，增加代码的可读性，但是，从实际工作出发，可能就变成了“有啥好加的？这点道理都不懂还上什么班？”……大家都懒得加了，所以，又不是什么很难懂的原理，加不加就自行把握吧。

最后，再总结一下使用原则：

@Autowired和@Resource在使用时可以不纠结它们的区别，使用它们的目的就是为了装配对象，只要能装得上，装的是对的，无所谓使用哪个？一定要区分选取，先保证“在同一个项目中使用同一个”，不要一个类使用@Autowired，另一个类又使用@Resource，然后，我个人建议使用@Autowired，原因嘛，很简单，你既然用Spring框架，就用它带的注解呗；关于@Autowired的使用方式，不怕麻烦就都使用构造方法注入，且显式的添加@Autowired，如果怕麻烦，只要不出错，就随意吧。

Spring官方也考虑到了网友关于@Resource或相关注解的问题，因为没什么需要特别解释的了，就直接贴图好了，大家自行查阅，以下图片仍是来自Spring官方资料：

最后，近期因为工作的关系看了不少Spring的官方资料，包括官方的Spring学习教程，有些感慨，给我的感觉，Spring对外提倡实用主义，极少和你讲理论，源码什么的更是少得可怜，这也和面向对象的思想保持一致，人家都帮你做好了，你好好用就行了，不必关心实现细节，希望大家也能这样！现在IT行业真的被一些大厂带节奏了，网上各种吸引眼球的XX源码解析、XX底层原理、XX加载过程分析、XX算法、大厂案例、大厂面试题……很多时候真的想喷一句“你咋不从操作系统开始做软件研发呢”……真的，绝大部分Java从业者一辈子都进不了大厂，也接触不到超过20台以上服务器才能扛得住的项目，除非是为了应付面试，你甚至不需要知道i++和++i的区别，如果只是自己写代码自己用，你也不需要知道private和public的区别……如果你只想开自己的私家车，不想修车也不想造车，除了吹牛，你都不需要知道发动机的型号……多掌握实用技术，多积累解决问题的经验，原理什么的能不管就不要管，当熟练到一定程度后，再考虑要不要深入了解原理。

好了，就这么多，如果有错别字，大家将就一下吧（可编辑次数有限），如果有觉得不对的地方，欢迎留言讨论。

spring入门详解

Spring是一个轻量级的Java框架，它提供了许多功能强大的工具和库，用于简化Java开发过程中的许多常见任务。如果您想深入了解Spring，以下是一些入门详解：

1.Spring框架的核心概念：Spring框架由多个模块组成，每个模块都提供了不同的功能。其中最核心的概念是IoC（InversionofControl）和DI（DependencyInjection），它们可以帮助我们管理应用程序中的对象和依赖关系。

2.Spring的核心容器：Spring框架的核心容器是BeanFactory和ApplicationContext，它们可以管理应用程序中的对象和依赖关系。BeanFactory是一个较早的版本，而ApplicationContext是一个较新的版本，它提供了更多的功能和扩展。

3.SpringMVC：SpringMVC是Spring框架中的一个模块，它提供了一个基于模型-视图-控制器（MVC）模式的Web应用程序开发框架。它可以帮助我们轻松地创建Web应用程序，并提供了许多有用的功能，如数据绑定、表单验证和国际化等。

4.SpringBoot：SpringBoot是一个快速开发框架，它可以帮助我们快速创建基于Spring框架的Web应用程序。它可以自动配置许多常见的Spring特性，如数据源、消息队列和安全性等。

5.SpringSecurity：SpringSecurity是一个用于身份验证和授权的框架，它可以帮助我们保护Web应用程序免受未经授权的访问。它提供了许多有用的功能，如身份验证、授权、密码重置等。

springboot怎么识别注解

SpringBoot可以通过使用反射机制来识别注解。1.首先，SpringBoot会扫描所有的类，查找是否使用了特定的注解。2.一旦发现了目标注解，SpringBoot会使用Java的反射机制来解析该注解的信息。3.通过反射，SpringBoot可以获取到注解的属性值，从而根据这些属性值来决定后续的处理逻辑。4.在SpringBoot中，注解不仅仅是一个标记，它们通常携带一些信息，例如配置数据源、定义路由等。因此，SpringBoot能够根据注解的信息来进行相应的业务处理，并提供相应的功能。总结起来，SpringBoot通过反射机制来识别注解，并根据注解的属性值来决定后续的处理逻辑和功能。

spring有什么缺点吗

明明一个很轻量级的框架，却给人感觉大而全，这就是它的缺点。Spring的核心概念是啥，最主要的，IoC和AOP，这两个核心服务的对象是啥，就是那堆beans，Spring我们可以理解为就是存放这些bean的容器，它最核心的就干这些事。IoC干嘛的，就是为了让开发者关注的重心放在如何使用这些bean。不管bean怎么来，只要@Autowired就给我老老实实出现，让我调接口就好，不需要每次用之前都要手动构建，尽量减少手动实例化bean的次数。SpringBoot以前，主要在beans.xml中注册bean，SpringBoot的话只要在Configuration中定义一个@Bean方法即可，就为了做好这件事，Spring弄了多少东西，BeanDefinition，BeanFactory，FactoryBean，然后Bean的生命周期接口好几个，Aware接口又好几个，等等，然后是AOP，AOP是很好的特性，在Spring中其主要目的就是以一种非浸入的方式对bean进行扩展，看到没，又是bean。为了对bean支持，Spring弄了一套AspctJ的子集，既有Java原生的接口代理，又有更加灵活的Cglib，光是AOP的概念就不少，更不要说实现的原理。简单的大e家都可以说出一二三四五，但深入细节谁有把握？所以，Spring就是围绕着bean展开的，它主要就是作为bean的容器，在这个基础上，有了SpringMVC，有了JPA，有了Cloud，有了DataFlow，以及其他模块。但这些模块的本质，不全是Spring，比如JPA，核心还是Hibernate，Cloud，核心是另外一套微服务框架。Spring就好比胶水，通过bean把这些模块粘在一起。实践过程中，反复的提醒自己，不要用Spring玩花，让它老老实实的做bean的容器就好了。我这么说，不看源码，你会觉得Spring重吗？可就这么些个东西，Spring弄出了多少名堂。随便找个地方打断点，调用就不下二十来层，在现在这种强调轻量化服务的大环境下，不被吐槽才怪。当然，我认为也不能全怪Spring。Java这门语言动态性本来就是它的弱项，Spring能把Java包装的像个动态化的语言已经蛮拼了。Spring背的最大的锅，我认为就是J2EE，就凭那套在当时有一定价值但放现在已经淘汰的标准，没有Spring，Java的企业级市场未必有今天。不过话说回来，从学习企业级Java开发的角度看，Spring的代码依然是教科书般的代码。面向对象封装，编程原则，设计模式，都是具有很高的参考价值。如果你才开始，我建议先沉住气，老老实实的敲代码，看文档，不管最后还在不在Java圈，将来一定会收获不小。有时候，你不复杂一些，又怎么能体会到简单的价值呢？

OK，本文到此结束，希望对大家有所帮助。