Background最近一段时间接手了几个Spark相关的大数据项目，主要使用Scala来编写代码，做了几个需求，感觉Scala这门语言还挺有意思，Scala以前也学习过，但是是很早了，很多语法点都忘了，在工作中经常编写的代码是Spark Job，使用stream的方式来编写代码，感觉非常的舒服。Spark中经常使用的一个操作是使用$来选择Column，比如下面使用$选择dt这一列，

最近遇到一个spring static bean的坑，我们知道使用Java Config的方式定义一个Bean 非常简单，只需在Configuration的method上加上 @Bean 注解即可。 但是这里有个例外，假如你的Bean不是一个普通的Bean，而是一个BeanFactoryPostProcessor就需要使用static方法来定义这个Bean。 否则你会得到一个警告： @Bean method TestConfig.customEditorConfigurer is non-static and returns an object assignable to Spring's BeanFactoryPostProcessor interface. This will result in a failure to process annotations such as @Autowired, @Resource and @PostConstruct within the method's declaring @Configuration class. Add the 'static' modifier to this method to avoid these container lifecycle issues; see @Bean javadoc for complete details. 也就是说，如果你的bean是一个BFPP，必须定义为static，否则，使用@Autowired, @Resource and @PostConstruct 会有问题。 来看 @Bean注解源码里的注释： 1234567891011121314Special consideration must be taken for @Bean methods that return Spring BeanFactoryPostProcessor (BFPP) types. Because BFPP objects must be instantiated very early in the container lifecycle,they can interfere with processing of annotations such as @Autowired, @Value, and @PostConstruct within @Configuration classes. To avoid these lifecycle issues, mark BFPP-returning @Bean methods as static. For example: @Bean public static PropertySourcesPlaceholderConfigurer pspc() { // instantiate, configure and return pspc ... } By marking this method as static, it can be invoked without causing instantiation of its declaring @Configuration class, thus avoiding the above-mentioned lifecycle conflicts. Note however that static @Bean methods will not be enhanced for scoping and AOP semantics as mentioned above. This works out in BFPP cases, as they are not typically referenced by other @Bean methods. As a reminder, a WARN-level log message will be issued for any non-static @Bean methods having a return type assignable to BeanFactoryPostProcessor. 因为BFPP都需要在在Spring容器的早期进行实例化，因为他们会干扰正常的Bean实例化中处理 @Autowired @Value @PostConstruct ，这篇Blog尝试寻找一下Static Bean背后的原理。

Spring事件驱动Spring 事件驱动的代码都位于spring-context 模块的event包中，主要包括：事件(Event)发布者() Publisher) ,订阅者(Listener)组成。 事件ApplicationEventjava的所有事件对象一般都是java.util.EventObject的子类，Spring的整个继承体系如下:

Spring事务使用Spring配置事务还是挺简单的，第一步创建事务管理器TransactionManager，然后在配置中增加一个@EnableTransactionManagement就可以启用Spring事务了，所以关键类就是@EnableTransactionManagement 1234@Bean public DataSourceTransactionManager transactionManager() { return new DataSourceTransactionManager(dataSource()); } 我们可以看到@EnableTransactionManagement 上实际上是import了TransactionManagementConfigurationSelector类，在这个Selector中实际import了两个配置类： AutoProxyRegistrar ProxyTransactionManagementConfiguration 1234567891011121314@Override protected String[] selectImports(AdviceMode adviceMode) { switch (adviceMode) { case PROXY: return new String[] {AutoProxyRegistrar.class.getName(), ProxyTransactionManagementConfiguration.class.getName()}; case ASPECTJ: return new String[] {determineTransactionAspectClass()}; default: return null; } } 下面我们来根据这个入口来分析一下Spring是如何处理事务的：

Spring Boot 启动SpringBoot的启动类很简单，只需要调用SpringApplication的run方法即可，这篇文章来分析一下SpringBoot的启动类SpringApplication初始化的过程。 123public static void main(String[] args) { SpringApplication.run(Application.class, args); } 在SpingApplication 中 初始化了一个SpringApplication, 参数是当前SpringBoot启动的类 123public static ConfigurableApplicationContext run(Class<?>[] primarySources, String[] args) { return new SpringApplication(primarySources).run(args); } SpringApplication初始化 从classpath推断 webApplicationType 设置Initializers 设置Listeners 推断main class,主要用于log print以及banner print 123456789public SpringApplication(ResourceLoader resourceLoader, Class<?>... primarySources) { this.resourceLoader = resourceLoader; Assert.notNull(primarySources, "PrimarySources must not be null"); this.primarySources = new LinkedHashSet<>(Arrays.asList(primarySources)); this.webApplicationType = WebApplicationType.deduceFromClasspath(); setInitializers((Collection) getSpringFactoriesInstances(ApplicationContextInitializer.class)); setListeners((Collection) getSpringFactoriesInstances(ApplicationListener.class)); this.mainApplicationClass = deduceMainApplicationClass(); }

Spring Bean生命周期中，BeanDefinition是最重要的部分，在初始化和实例化Bean之前，首先要把所有的需要Spring管理的Bean对应的BeanDefinition加载到Spring容器中，这一步非常关键，因为BeanDefinition是Bean关联的元数据，这一篇文章就以AnnotationConfigApplicationContext来分析一下Spring容器是如何加载BeanDefinition的。 第一阶段：扫描Class文件加载BeanDefinition123456public AnnotationConfigApplicationContext(String... basePackages) { this(); scan(basePackages); refresh(); } 我们先以package的方式来分析，初始化AnnotationConfigApplicationContext的时候会scan对应的包路径，然后进行refresh scan的动作是在ClassPathBeanDefinitionScanner的doScan方法中完成的,主要任务是查找classpath下面的Class文件，判断是否为Bean，然后生成BeanDefinition。

Spring Environment 体系 Environment Interface representing the environment in which the current application is running. Models two key aspects of the application environment: profiles and properties. Methods related to property access are exposed via the PropertyResolver superinterface. Environment 继承自PropertyResolver 定义了应用运行环境的两大关键要素： profiles 和properties，其中properties接口通过父类的PropertyResolver 暴露接口.