文章目录
从今天开始,我们的笔记更侧重于 一些小细节的学习 和 一些固定的操作的截图 还有那些 代码的解释,而至于课程中跑起来的小项目实在是不值得花大力气去完整细致的截图了。所有难免笔记看起来散乱一些。
一、官方文档
SpringBoot的官方文档:SpringBoot
二、入门程序
1.完整流程
创建工程
导入spring boot相关的依赖
<parent>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-parent</artifactId>
<version>1.5.9.RELEASE</version>
</parent>
<dependencies>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
</dependency>
</dependencies>
编写主程序类
@SpringBootApplication
public class HelloWorldMainApplication {
public static void main(String[] args) {
SpringApplication.run(HelloWorldMainApplication.class,args);
}
}
编写相关的Controller
@Controller
public class HelloController {
@ResponseBody
@RequestMapping("/hello")
public String hello(){
return "Hello World!";
}
}
运行测试
略
2.局部代码解释
3.springboot官方文档
三、将刚刚的代码完成部署
四、SpringBoot的依赖管理
1.如何自定义版本
2.springboot官方文档查看starter
3.查看依赖树
五、SpringBoot自动配置
1.关于包扫描
2.查看源码
六、常用的注解
@Configuration
1.Configuration的基本使用
2.单实例
3.proxyBeanMethods
我们知道配置类里面的user01方法就是给容器中注册组件的,因为该方法上面标注了@Bean注解。
而现在我在配置类外面把user01这个方法多调了两遍,那么该方法返回的User对象是从容器中拿的吗?还是说这尼玛就是一个普通方法的调用呢?
如果是普通方法的调用那么你调用几次就返回几个对象,要是从容器中拿那么就只有那么一个。
我们在外部无论对配置类中的组件注册方法调用多少次,获取到的都是之前注册到容器中的单实例对象。所以两次调用user01方法获取到的两个User对象是同一个对象。
那么其原因何在呢?原因就是@Configuration(proxyBeanMethods = true)。我们知道配置类本身也是组件,从IDEA控制台打印出的结果中我们还能知道它并不是一个普通对象,而是一个被Spring CGLIB增强了的代理对象,我们获取到的配置类组件本身就是一个代理对象。当我们在外部通过该代理对象来调用其方法时,Spring Boot默认会检查容器中是否有该方法已经返回了的组件,若有则不会新创,而是直接拿;若没有则再来调用该方法创建一个新的,总之,Spring Boot总会检查方法返回的组件是否在容器中存在。当然了,这一切的前提是@Configuration注解里面的proxyBeanMethods属性的值为true(@Configuration(proxyBeanMethods = true)),即在配置类中的方法被代理的情况下(proxyBeanMethods翻译过来就是代理bean的方法嘛),我们才能看到上述这种现象。
4.proxyBeanMethods为true的作用
说了这么多,那么它适用于什么场景呢?我就直说了吧!组件依赖必须使用默认的Full模式,其他则默认使用Lite模式。
那么,将配置类编写为轻量级模式有什么优点呢?优点就是Spring Boot不会来检查组件注册的方法(例如user01方法)返回的东东在容器中有没有,相当于就跳过了检查,这样,我们整个Spring Boot应用启动并运行起来就非常快了。而如果是将配置类编写为全模式,那么外界对它里面的方法的每一次调用,Spring Boot都会检查容器中是不是有了该方法已经返回了的组件。
虽然Spring Boot给我们带来了Full和Lite这两种配置模式,但是在Spring Boot的最佳实践中,我们推荐的做法是这样子的——如果我们只是向容器中单单注册组件,而且也不存在组件依赖,那么一般使用Lite模式,因为这样的话,我们Spring Boot应用整个的启动速度就会非常快,加载起来也会非常快哟;如果存在组件依赖,那么一般使用Full模式,因为这样能保证某一个组件它所依赖的组件就是容器中的组件。
5.注解配置过的组件
- 我们说了一下使用@Configuration注解结合@Bean注解来向容器中注册组件。
- 咱们就来说说给容器中注册组件的其他方法,因为我们以前的方法也是可以使用的嘛!
- 我们可以给类上标注一个@Component注解,以代表该类是一个组件,或者标注一个@Controller注解,以代表它是前端控制器组件;或者标注一个@Service注解,以代表它是service层组件;或者标注一个@Repository注解,代表它是Dao层组件
- @ComponentScan代表包扫描,也还是可以使用的
结
@Import
我们说了一下使用@Configuration注解结合@Bean注解来向容器中注册组件。接下来,介绍另外一种给容器中添加组件的方式,即使用@Import注解给容器中导入一个组件。
@Import注解应该写在哪儿呢?我们只要写在任何一个配置类或者组件里面都是可行的。注意,@Import注解要写在容器中的组件它所属类型的那个类上,这个类可以是配置类,也可以是其他注解(例如@Component、@Controller、@Service以及@Repository)标注的类,总之,只要是容器中组件所属类型的类都行。这里,我们不妨将其标注在MyConfig配置类上。
此时,@Import({User.class, DBHelper.class})注解就会给容器中自动创建出User和DBHelper这两个类型的组件,注意,调用的是这两个类中的无参构造器来创建出的对象并放在容器中的哟!
那不妨我们现在来看一下容器中到底会不会有这两个组件?怎么验证呢?不就是从容器中获取组件吗,这有什么难的,但问题就是我们给容器中放了非常多User这种类型的组件,那咋个办呢?我们可以在主程序类中编写下面这样的代码来进行验证。
@Conditional
@Conditional满足Conditional指定的条件,则进行组件注入
@ImportResource
@ConfigurationProperties
@ConfigurationProperties的作用仅仅是配置绑定,你还需要用@Component注解或者@EnableConfigurationProperties注入容器
七、用源码学注解
1.按需加载
springboot得益于conditional注解完成了按需加载,springboot一启动会加载所有的配置,但是呢它不会全部生效,而是存在某个类、存在某个组件等等条件满足的情况下才会加载相关代码。
2.EnableConfigurationProperties
3.定制化配置
我觉得这个是相当相当的重要:P324 06-自动配置原理
如果有一天我们遇到一个没有学过的组件,你不知道该在resources下的application.yml中添加什么配置参数,如果它是springboot里面的组件的话,按照下面的流程图去做。
比如你要整合redis的组件:
修改端口