找到
11
篇与
spring
相关的结果
- 第 2 页
-
Spring Boot的自动配置 随着Ruby、Groovy等动态语言的流行，相比较之下Java的开发显得格外笨重。繁多的配置、低下的开发效率、复杂的部署流程以及第三方技术集成难度大等问题一直被人们所诟病。随着Spring家族中的新星Spring Boot的诞生，这些问题都在逐渐被解决。 个人觉得Spring Boot中最重要的两个优势就是可以使用starter简化依赖配置和Spring的自动配置。 使用starter简化依赖配置 Spring提供了一系列starter来简化Maven配置。其核心原理也就是Maven和Gradle的依赖传递方案。当我们在我们的pom文件中增加对某个starter的依赖时，该starter的依赖也会自动的传递性被依赖进来。而且，很多starter也依赖了其他的starter。例如web starter就依赖了tomcat starter，并且大多数starter基本都依赖了spring-boot-starter。 Spring自动配置 Spring Boot会根据类路径中的jar包、类，为jar包里的类自动配置，这样可以极大的减少配置的数量。简单点说就是它会根据定义在classpath下的类，自动的给你生成一些Bean，并加载到Spring的Context中。自动配置充分的利用了spring 4.0的条件化配置特性，能够自动配置特定的Spring bean，用来启动某项特性。 条件化配置 假设你希望一个或多个bean只有在某种特殊的情况下才需要被创建，比如，一个应用同时服务于中美用户，要在中美部署，有的服务在美国集群中需要提供，在中国集群中就不需要提供。在Spring 4之前，要实现这种级别的条件化配置是比较复杂的，但是，Spring 4引入了一个新的@Conditional注解可以有效的解决这类问题。 @Bean @Conditional(ChinaEnvironmentCondition.class) public ServiceBean serviceBean(){ return new ServiceBean(); } 当@Conditional(ChinaEnvironmentCondition.class)条件的值为true的时候，该ServiceBean才会被创建，否则该bean就会被忽略。 @Conditional指定了一个条件。他的条件的实现是一个Java类——ChinaEnvironmentCondition，要实现以上功能就要定义ChinaEnvironmentCondition类，并继承Condition接口并重写其中的matches方法。 class ChinaEnvironmentCondition implements Condition{ public final boolean matches(ConditionContext context, AnnotatedTypeMetadata metadata) { Environment env = context.getEnvironment(); return env.containProperty("ENV_CN"); } } 在上面的代码中，matches方法的内容比较简单，他通过给定的ConditionContext对象进而获取Environment对象，然后使用该对象检查环境中是否存在ENV_CN属性。如果存在该方法则直接返回true，反之返回false。当该方法返回true的时候，就符合了@Conditional指定的条件，那么ServiceBean就会被创建。反之，如果环境中没有这个属性，那么这个ServiceBean就不会被创建。 除了可以自定义一些条件之外，Spring 4本身提供了很多已有的条件供直接使用，如： @ConditionalOnBean @ConditionalOnClass @ConditionalOnExpression @ConditionalOnMissingBean @ConditionalOnMissingClass @ConditionalOnNotWebApplication Spring Boot应用的启动入口 自动配置充分的利用了spring 4.0的条件化配置特性，那么，Spring Boot是如何实现自动配置的？Spring 4中的条件化配置又是怎么运用到Spring Boot中的呢？这要从Spring Boot的启动类说起。Spring Boot应用通常有一个名为*Application的入口类，入口类中有一个main方法，这个方法其实就是一个标准的Java应用的入口方法。一般在main方法中使用SpringApplication.run()来启动整个应用。值得注意的是，这个入口类要使用@SpringBootApplication注解声明。@SpringBootApplication是Spring Boot的核心注解，他是一个组合注解。 @Target({ElementType.TYPE}) @Retention(RetentionPolicy.RUNTIME) @Documented @Inherited @SpringBootConfiguration @EnableAutoConfiguration @ComponentScan( excludeFilters = {@Filter( type = FilterType.CUSTOM, classes = {TypeExcludeFilter.class} ), @Filter( type = FilterType.CUSTOM, classes = {AutoConfigurationExcludeFilter.class} )} ) public @interface SpringBootApplication { // 略 } @SpringBootApplication是一个组合注解，它主要包含@SpringBootConfiguration、@EnableAutoConfiguration等几个注解。也就是说可以直接在启动类中使用这些注解来代替@ SpringBootApplication注解。 关于Spring Boot中的Spring自动化配置主要是@EnableAutoConfiguration的功劳。该注解可以让Spring Boot根据类路径中的jar包依赖为当前项目进行自动配置。 至此，我们知道，Spring Boot的自动化配置主要是通过@EnableAutoConfiguration来实现的，因为我们在程序的启动入口使用了@SpringBootApplication注解，而该注解中组合了@EnableAutoConfiguration注解。所以，在启动类上使用@EnableAutoConfiguration注解，就会开启自动配置。 那么，本着刨根问底的原则，当然要知道@EnableAutoConfiguration又是如何实现自动化配置的，因为目前为止，我们还没有发现Spring 4中条件化配置的影子。 EnableAutoConfiguration 其实Spring框架本身也提供了几个名字为@Enable开头的Annotation定义。比如@EnableScheduling、@EnableCaching、@EnableMBeanExport等，@EnableAutoConfiguration的理念和这些注解其实是一脉相承的。 @EnableScheduling是通过@Import将Spring调度框架相关的bean定义都加载到IoC容器。 @EnableMBeanExport是通过@Import将JMX相关的bean定义加载到IoC容器。 @EnableAutoConfiguration也是借助@Import的帮助，将所有符合自动配置条件的bean定义加载到IoC容器。 下面是EnableAutoConfiguration注解的源码： @Target({ElementType.TYPE}) @Retention(RetentionPolicy.RUNTIME) @Documented @Inherited @AutoConfigurationPackage @Import({EnableAutoConfigurationImportSelector.class}) public @interface EnableAutoConfiguration { //略 } 观察@EnableAutoConfiguration可以发现，这里Import了@EnableAutoConfigurationImportSelector，这就是Spring Boot自动化配置的“始作俑者”。 至此，我们知道，至此，我们知道，由于我们在Spring Boot的启动类上使用了@SpringBootApplication注解，而该注解组合了@EnableAutoConfiguration注解，@EnableAutoConfiguration是自动化配置的“始作俑者”，而@EnableAutoConfiguration中Import了@EnableAutoConfigurationImportSelector注解，该注解的内部实现已经很接近我们要找的“真相”了。 EnableAutoConfigurationImportSelector EnableAutoConfigurationImportSelector的源码在这里就不贴了，感兴趣的可以直接去看一下，其实实现也比较简单，主要就是使用Spring 4 提供的的SpringFactoriesLoader工具类。通过SpringFactoriesLoader.loadFactoryNames()读取了ClassPath下面的META-INF/spring.factories文件。 这里要简单提一下spring.factories文件，它是一个典型的java properties文件，配置的格式为Key = Value形式。 EnableAutoConfigurationImportSelector通过读取spring.factories中的key为org.springframework.boot.autoconfigure.EnableAutoConfiguration的值。如spring-boot-autoconfigure-1.5.1.RELEASE.jar中的spring.factories文件包含以下内容： # Auto Configure org.springframework.boot.autoconfigure.EnableAutoConfiguration=\ org.springframework.boot.autoconfigure.admin.SpringApplicationAdminJmxAutoConfiguration,\ org.springframework.boot.autoconfigure.aop.AopAutoConfiguration,\ org.springframework.boot.autoconfigure.amqp.RabbitAutoConfiguration,\ org.springframework.boot.autoconfigure.batch.BatchAutoConfiguration,\ org.springframework.boot.autoconfigure.cache.CacheAutoConfiguration,\ org.springframework.boot.autoconfigure.cassandra.CassandraAutoConfiguration,\ org.springframework.boot.autoconfigure.cloud.CloudAutoConfiguration,\ ...... org.springframework.boot.autoconfigure.webservices.WebServicesAutoConfiguration 上面的EnableAutoConfiguration配置了多个类，这些都是Spring Boot中的自动配置相关类；在启动过程中会解析对应类配置信息。每个Configuation都定义了相关bean的实例化配置。都说明了哪些bean可以被自动配置，什么条件下可以自动配置，并把这些bean实例化出来。 如果我们新定义了一个starter的话，也要在该starter的jar包中提供 spring.factories文件，并且为其配置org.springframework.boot.autoconfigure.EnableAutoConfiguration对应的配置类。 Configuation 我们从spring-boot-autoconfigure-1.5.1.RELEASE.jar中的spring.factories文件随便找一个Configuration，看看他是如何自动加载bean的。 @Configuration @AutoConfigureAfter({JmxAutoConfiguration.class}) @ConditionalOnProperty( prefix = "spring.application.admin", value = {"enabled"}, havingValue = "true", matchIfMissing = false ) public class SpringApplicationAdminJmxAutoConfiguration { @Bean @ConditionalOnMissingBean public SpringApplicationAdminMXBeanRegistrar springApplicationAdminRegistrar() throws MalformedObjectNameException { String jmxName = this.environment.getProperty("spring.application.admin.jmx-name", "org.springframework.boot:type=Admin,name=SpringApplication"); if(this.mbeanExporter != null) { this.mbeanExporter.addExcludedBean(jmxName); } return new SpringApplicationAdminMXBeanRegistrar(jmxName); } } 看到上面的代码，终于找到了我们要找的东西——Spring 4的条件化配置。上面SpringApplicationAdminJmxAutoConfiguration在决定对哪些bean进行自动化配置的时候，使用了两个条件注解：ConditionalOnProperty和ConditionalOnMissingBean。只有满足这种条件的时候，对应的bean才会被创建。这样做的好处是什么？这样可以保证某些bean在没满足特定条件的情况下就可以不必初始化，避免在bean初始化过程中由于条件不足，导致应用启动失败。 总结 至此，我们可以总结一下Spring Boot的自动化配置的实现： 通过Spring 4的条件配置决定哪些bean可以被配置，将这些条件定义成具体的Configuation，然后将这些Configuation配置到spring.factories文件中，作为key: org.springframework.boot.autoconfigure.EnableAutoConfiguration的值，这时候，容器在启动的时候，由于使用了EnableAutoConfiguration注解，该注解Import的EnableAutoConfigurationImportSelector会去扫描classpath下的所有spring.factories文件，然后进行bean的自动化配置。 所以，如果我们想要自定义一个starter的话，可以通过以上方式将自定义的starter中的bean自动化配置到Spring的上下文中，从而避免大量的配置。
-
Spring的事务管理机制 在我的博客（http://www.hollischuang.com/）中，多篇文章介绍了事务相关的内容，其中包括数据库的事务的相关介绍、分布式事务的相关介绍以及在Spring中使用注解进行事务的配置方式等。 本文在以上文章的基础上，一起来学习一下Spring中对事务的支持——Spring的事务管理机制。 Spring对事务管理的支持 与EJB类似，Spring提供了对编码式和声明式事务管理的支持。但是，Spring对事务管理的能力远远超过EJB。这里就不详细介绍编码式事务和声明式事务的区别了。有兴趣的读者可以自行Google。 Spring对事务管理是通过事务管理器来实现的。Spring提供了许多内置事务管理器实现： 事务管理器(org.springframework.*) 使用场景 DataSourceTransactionManager 数据源事务管理器，提供对单个javax.sql.DataSource事务管理，用于Spring JDBC抽象框架、iBATIS或MyBatis框架的事务管理； JdoTransactionManager 提供对单个javax.jdo.PersistenceManagerFactory事务管理，用于集成JDO框架时的事务管理； JpaTransactionManager 提供对单个javax.persistence.EntityManagerFactory事务支持，用于集成JPA实现框架时的事务管理； HibernateTransactionManager 提供对单个org.hibernate.SessionFactory事务支持，用于集成Hibernate框架时的事务管理；该事务管理器只支持Hibernate3+版本，且Spring3.0+版本只支持Hibernate 3.2+版本； JtaTransactionManager 提供对分布式事务管理的支持，并将事务管理委托给Java EE应用服务器事务管理器； OC4JjtaTransactionManager Spring提供的对OC4J10.1.3+应用服务器事务管理器的适配器，此适配器用于对应用服务器提供的高级事务的支持； WebSphereUowTransactionManager Spring提供的对WebSphere 6.0+应用服务器事务管理器的适配器，此适配器用于对应用服务器提供的高级事务的支持； WebLogicJtaTransactionManager Spring提供的对WebLogic 8.1+应用服务器事务管理器的适配器，此适配器用于对应用服务器提供的高级事务的支持。 以上就是Spring中支持使用的事务管理器，一般我们比较常用的就是HibernateTransactionManager和DataSourceTransactionManager。我们在使用事务的时候要声明要使用哪种事务管理器。如： 事务属性 spring中，声明事务是通过事务属性来定义的。事务属性描述了事务策略如何应用到方法上事务属性包含5个方面： 传播行为 隔离级别 回滚规则 事务超时 是否只读 这里简单介绍一下这五个属性。 传播行为 传播行为定义了客户端与被调用方法之间的事务边界，即传播规则回答了这样的一个问题，新的事务应该被启动还是挂起，或者方法是否要在事务环境中运行。（后面会有单独的文章介绍该属性） 隔离级别 隔离级别定义了一个事务可能受其他并发事务影响的程度。多事务并发可能会导致脏读、幻读、不可重复读等各种读现象。(具体参考：数据库的读现象浅析) ISOLATION_DEFAULT:使用后端数据库默认的规则 ISOLATION_READ_UNCOMMITTED:允许读取尚未提交的数据变更，可能会导致脏读，幻读或不可重复读 ISOLATION_READ_COMMITTED:允许读取并发事务已经提交的数据，可以防止脏读，但是幻读或不可重复读仍有可能发生 ISOLATION_REPEATABLE_READ:对同意字段的多次读取结果是一致的，除非数据是被本事务自己所修改，看阻止脏读和不可重复读，但幻读仍有可能发生 ISOLATIOM_SERIALIZABLE:完全服从ACID的隔离级别，确保阻止脏读，不可重复读以及幻读，这是最慢的数据隔离级别 （具体参考：深入分析事务的隔离级别） 是否只读 如果事务只对后端的数据库进行读操作，数据库可以利用事务ID只读特性来进行一些特定的优化。通过将事务设置为只读，你就可以给数据库一个机会，让他应用它认为合适的优化措施。因为是否只读是在事务启动的时候由数据库实施的，所以只有对那些具备可能启动一个新事务的传播行为（PROPAGATION_REQUIRED,PROPAGATION_REQUIRED_NEW,PROPAGATION_NESTED）的方法来说，才有意义。 事务超时 为了使应用程序很好地运行，事务不能运行太长时间。因为超时时钟会在事务开始时启动，所以只有对那些具备可能启动一个新事务的传播行为（PROPAGATION_REQUIRED,PROPAGATION_REQUIRED_NEW,PROPAGATION_NESTED）的方法来说，才有意义。 事务回滚 事务回滚规则定义了哪些异常会导致事务回滚而哪些不会。默认情况下，事务只有在遇到运行时期异常才回滚，而在遇到检查型异常时不会回滚。 配置方式 事务属性的配置方式通过以下关键字来指定： 关键字 含义 isolation 指定事务的隔离级别 propagation 定义事务的传播规则 read-only 指定事务为只读 rollback-forno-rollback-for rollback-for指定事务对哪些检查型异常应当回滚而不提交no-rollback-for指定事务对哪些异常应当继续执行而不回滚 timeout 对于长时间运行的事务定义超时时间 XML中事务属性的配置方式如下： 注解中事务属性的配置方式如下： @Transaction(propagation=Propagation. REQUIRED,readOnly=true) public void add(String username){ //... } 总结 事务是企业应用开发中很重要的组成部分，他让软件变得更加健壮。他保证了全有或全无的操作。 Spring同时支持编码式和声明式事务管理，无论使用哪种方式进行事务管理，都应该知道与事务相关的五个属性。 参考资料 《Spring实战》 spring 事务属性 摄于 2016.04.16 @江郎山
-
Spring官方都推荐使用的@Transactional事务，为啥我不建议使用！ 事务管理在系统开发中是不可缺少的一部分，Spring提供了很好事务管理机制，主要分为编程式事务和声明式事务两种。 关于事务的基础知识，如什么是事务，数据库事务以及Spring事务的ACID、隔离级别、传播机制、行为等，就不在这篇文章中详细介绍了。默认大家都有一定的了解。 本文，作者会先简单介绍下什么是声明式事务和编程式事务，再说一下为什么我不建议使用声明式事务。 编程式事务 基于底层的API，如PlatformTransactionManager、TransactionDefinition 和 TransactionTemplate 等核心接口，开发者完全可以通过编程的方式来进行事务管理。 编程式事务方式需要是开发者在代码中手动的管理事务的开启、提交、回滚等操作。 public void test() { TransactionDefinition def = new DefaultTransactionDefinition(); TransactionStatus status = transactionManager.getTransaction(def); try { // 事务操作 // 事务提交 transactionManager.commit(status); } catch (DataAccessException e) { // 事务提交 transactionManager.rollback(status); throw e; } } 如以上代码，开发者可以通过API自己控制事务。 声明式事务 声明式事务管理方法允许开发者配置的帮助下来管理事务，而不需要依赖底层API进行硬编码。开发者可以只使用注解或基于配置的 XML 来管理事务。 @Transactional public void test() { // 事务操作 } 如上，使用@Transactional即可给test方法增加事务控制。 当然，上面的代码只是简化后的，想要使用事务还需要一些配置内容。这里就不详细阐述了。 这两种事务，格子有各自的优缺点，那么，各自有哪些适合的场景呢？为什么有人会拒绝使用声明式事务呢？ 声明式事务的优点 通过上面的例子，其实我们可以很容易的看出来，声明式事务帮助我们节省了很多代码，他会自动帮我们进行事务的开启、提交以及回滚等操作，把程序员从事务管理中解放出来。 声明式事务管理使用了 AOP 实现的，本质就是在目标方法执行前后进行拦截。在目标方法执行前加入或创建一个事务，在执行方法执行后，根据实际情况选择提交或是回滚事务。 使用这种方式，对代码没有侵入性，方法内只需要写业务逻辑就可以了。 但是，声明式事务真的有这么好么？倒也不见得。 声明式事务的粒度问题 首先，声明式事务有一个局限，那就是他的最小粒度要作用在方法上。 也就是说，如果想要给一部分代码块增加事务的话，那就需要把这个部分代码块单独独立出来作为一个方法。 但是，正是因为这个粒度问题，本人并不建议过度的使用声明式事务。 首先，因为声明式事务是通过注解的，有些时候还可以通过配置实现，这就会导致一个问题，那就是这个事务有可能被开发者忽略。 事务被忽略了有什么问题呢？ 首先，如果开发者没有注意到一个方法是被事务嵌套的，那么就可能会再方法中加入一些如RPC远程调用、消息发送、缓存更新、文件写入等操作。 我们知道，这些操作如果被包在事务中，有两个问题： 1、这些操作自身是无法回滚的，这就会导致数据的不一致。可能RPC调用成功了，但是本地事务回滚了，可是PRC调用无法回滚了。 2、在事务中有远程调用，就会拉长整个事务。那么久会导致本事务的数据库连接一直被占用，那么如果类似操作过多，就会导致数据库连接池耗尽。 有些时候，即使没有在事务中进行远程操作，但是有些人还是可能会不经意的进行一些内存操作，如运算。或者如果遇到分库分表的情况，有可能不经意间进行跨库操作。 但是如果是编程式事务的话，业务代码中就会清清楚楚看到什么地方开启事务，什么地方提交，什么时候回滚。这样有人改这段代码的时候，就会强制他考虑要加的代码是否应该方法事务内。 有些人可能会说，已经有了声明式事务，但是写代码的人没注意，这能怪谁。 话虽然是这么说，但是我们还是希望可以通过一些机制或者规范，降低这些问题发生的概率。 比如建议大家使用编程式事务，而不是声明式事务。因为，作者工作这么多年来，发生过不止一次开发者没注意到声明式事务而导致的故障。 因为有些时候，声明式事务确实不够明显。 声明式事务用不对容易失效 除了事务的粒度问题，还有一个问题那就是声明式事务虽然看上去帮我们简化了很多代码，但是一旦没用对，也很容易导致事务失效。 如以下几种场景就可能导致声明式事务失效： 1、@Transactional 应用在非 public 修饰的方法上2、@Transactional 注解属性 propagation 设置错误3、@Transactional 注解属性 rollbackFor 设置错误4、同一个类中方法调用，导致@Transactional失效5、异常被catch捕获导致@Transactional失效6、数据库引擎不支持事务 以上几个问题，如果使用编程式事务的话，很多都是可以避免的。 使用声明事务失效的问题我们发生过很多次。不知道大家有没有遇到过，我是实际遇到过的 因为Spring的事务是基于AOP实现的，但是在代码中，有时候我们会有很多切面，不同的切面可能会来处理不同的事情，多个切面之间可能会有相互影响。 在之前的一个项目中，我就发现我们的Service层的事务全都失效了，一个SQL执行失败后并没有回滚，排查下来才发现，是因为一位同事新增了一个切面，这个切面里面做个异常的统一捕获，导致事务的切面没有捕获到异常，导致事务无法回滚。 这样的问题，发生过不止一次，而且不容易被发现。 很多人还是会说，说到底还是自己能力不行，对事务理解不透彻，用错了能怪谁。 但是我还是那句话，我们确实无法保证所有人的能力都很高，也无法要求所有开发者都能不出错。我们能做的就是，尽量可以通过机制或者规范，来避免或者降低这些问题发生的概率。 其实，如果大家有认真看过阿里巴巴出的那份Java开发手册的话，其实就能发现，其中的很多规约并不是完完全全容易被人理解，有些也比较生硬，但是其实，这些规范都是从无数个坑里爬出来的开发者们总结出来的。 关于@Transactional的用法，规约中也有提到过，只不过规约中的观点没有我这么鲜明： 总结 最后，相信本文的观点很多人都并不一定认同，很多人会说：Spring官方都推荐无侵入性的声明式事务，你有啥资格出来BB 。 说实话，刚工作的前几年，我也热衷于使用声明式事务，觉得很干净，也很”优雅”。觉得师兄们使用编程式事务多此一举，没有工匠精神。 但是慢慢的，线上发生过几次问题之后，我们复盘后发现，很多时候你自己写的代码很优雅，这完全没问题。 但是，优雅的同时也带来了一些副作用，师兄们又不能批评我，因为我的用法确实没错… 所以，有些事，还是要痛过之后才知道。 当然，本文并不要求大家一定要彻底不使用声明式事务，只是建议大家日后在使用事务的时候，能够考虑到本文中提到的观点，然后自行选择。
-
[Code]使用反射获取Spring的Bean /** * Bean的转换类 * 会将形如APP_INFO_SERVICE的字符串转换成T类型appInfoService * Created by hollis on 15/7/21. */ public class BeanTransverter implements BeanFactoryAware { private BeanFactory beanFactory; /** * 获取类型为clazz，beanId为enumName（A_BEAN -> aBean）的Bean。 * @param enumName * @return */ public T getBean(String enumName) { String beanName = toBeanName(enumName); return (T) beanFactory.getBean(beanName); } private String toBeanName(String enumName) { String lowerCase = enumName.toLowerCase(); String replacedStr = StringUtils.replace(lowerCase, "_", " "); String capitaliseAllWords = StringUtils.capitaliseAllWords(replacedStr); String[] parts = StringUtils.split(capitaliseAllWords, " "); String join = StringUtils.join(parts, ""); return StringUtils.uncapitalise(join); } public void setBeanFactory(BeanFactory beanFactory) throws BeansException { this.beanFactory = beanFactory; } } /** * @author hollis */ public class LabelItemProcessor implements ItemProcessor { private BeanTransverter beanTransverter; public List process(AppinfoDO item) throws Exception { List appLabelDOs = new ArrayList(); for(LabelItemEnum labelItem : LabelItemEnum.values()){ LabelMarker labelMarker = beanTransverter.getBean(labelItem.toString()); AppLabelDO appLabelDO = labelMarker.marking(item); if(StringUtils.isNotBlank(appLabelDO.getLabelName())){ appLabelDOs.add(appLabelDO); } } return appLabelDOs; } public void setBeanTransverter(BeanTransverter beanTransverter) { this.beanTransverter = beanTransverter; } }
-
Spring Boot 2.0发布，新特性一览 北京时间 2018 年 3 月 1 日早上，Spring Boot 2.0 如约发布，并提供了 Maven 中央仓库地址。在Spring Boot的官网中，2.0.0已经是最新的Spring Boot推荐版本。 官方表示，这个版本经历了 17 个月的开发，有 215 个不同的使用者提供了超过 6800 次的提交。该版本是自 4 年前发布 Spring Boot 1.0 以来的第一次重大修订，也是首个提供对 Spring Framework 5.0 支持的 GA 稳定版本。 Spring Boot 2.0 主要有以下特性（详见：Spring Boot 2.0 Release Notes）。 基于 Java 8，支持 Java 9 Spring Boot 2.0要求Java的版本最低为Java 8，许多现有的API已经更新，采用了Java 8的新特性，如：接口的默认方法、函数式的回调、javax.time等新的API。如果你还在使用Java 7或者更早的版本，那么在使用Spring Boot 2.0之前要先升级到Java 8。 Spring Boot 2.0 也针对Java 9 做了相应测试，支持良好。 依赖组件的升级 Spring Boot 2.0 基于 Spring Framework 5构建，本次Spring Boot的升级，同时也升级了部分其依赖的第三方组件。主要的几个有： Tomcat 8.5 Flyway 5 Hibernate 5.2 Thymeleaf 3 对响应式应用更好的支持 作为 Java 世界首个响应式 Web 框架，Spring 5 最大的亮点莫过于提供了完整的端到端响应式编程的支持。基于Spring 5构建的Spring Boot 2.0，在响应式编程方面给予了更好的支持，主要体现在以下几个方面： 使用 Spring WebFlux/WebFlux.fn 提供响应式 Web 编程支持 为各种组件的响应式编程提供了自动化配置，如：Reactive Spring Data、Reactive Spring Security 等 用于响应式 Spring Data Cassandra, MongoDB, Couchbase 和 Redis 的自动化配置和启动器 POM 支持HTTP/2 HTTP/2是第二代的HTTP协议，Spring Boot的Web容器选择中Tomcat, Undertow 和 Jetty 均已支持 HTTP/2。 Gradle 插件 Spring Boot的Gradle插件已基本重写，所有，有了许多重大改进。Spring Boot 2.0 要求 Gradle 4.x 引入对 Kotlin 1.2.x 的支持 Spring Boot 2.0 支持 Kotlin 1.2.x，并提供了一个 runApplication 函数，让你通过惯用的 Kotlin 来运行 Spring Boot 应用程序。 全新的执行器架构 在基于Spring Boot的应用程序内通过Endpoint可以根据应用程序业务需求实现自定义的监控接口，Spring 2.0 对于执行器端点（Actuator Endpoint）有很多改进和优化，经过重新设计后的Spring Boot 2 在Endpoint方面带来了全新的架构。全新的执行器架构，支持 Spring MVC, WebFlux 和 Jersey。 支持 Quartz 调度程序 Spring Boot 2 针对Quartz调度器提供了支持。你可以加入spring-boot-starter-quartz starter来启用。而且支持基于内存和基于jdbc两种存储。 动画ASCII艺术 最后一项，仅仅是为了好玩，启动时的 ASCII 图像 Spring Boot banner 现已支持 GIF
![[Code]使用反射获取Spring的Bean](http://blog.kuydata.cn/usr/themes/joe/assets/images/thumb/12.jpg?version=1)
