ConfigurableBeanFactory提供了接口來进行自定义Scope的注册 我们只需要实现Scope接口，注意这里的Scope不是注解@Scope。 Scope接口有如下定义(下文中所有上下文均指代作用域的上下文) Spring附赠了一个简单实现的SimpleThreadScope可以作为参考。 在这里我们一起来创建一个新的WorldScope(平行世界)，通过一个全局的世界标识符来决定当前上下文。 定义好了Scope，接着我们把它注册到容器中

上文讲到如何将Bean注册到容器中。整个过程看上去像是魔法一样，没有任何耦合，只是加了一个注解就完成了。 其实秘密就藏在了注解里，注解包含了配置项，Spring容器解析注解从而找到你的Bean。 在Spring中主要有两种方式发现你的Bean @ComponentScan告诉Spring容器通过类路径扫描来发现用户定义的Bean。 你可能会想你并没有定义过这一注解，让我们点开@SpringBootApplication类源码，你会发现它已经包含了@ComoponentScan。

任何应用都不可避免地要使用配置文件，而一些配置信息包含敏感信息，如果明文放在配置文件中上传到远程仓库里显然是不合适地。 一种做法是在仓库里不记录敏感信息，而在生产环境下单独配置。这样虽然保护了信息但是会变得非常麻烦，换一个环境又要重新配置。 而我的做法是直接在配置文件中加密，通过一个统一密钥来管理所有的敏感信息。 我们有如下配置项 对应的我们有 其中app-id, app-secret, password都是敏感信息。 导入xconfig

在开篇"Spring Boot是什么"一节，我们讲到Spring Boot是一个容器。 如果你有心翻看Spring Boot Starter的依赖，你会发现除了包含基础设施的spring-core项目外，最主要的项目便是spring-context，直译为上下文，亦即容器。 即使你没有用过Spring也一定听过依赖注入/控制反转。 在大型项目中，代码中存在千丝万缕的依赖关系，如果不能正确管理这些依赖关系，生产效率和质量都会大打折扣。例如下面这个例子

在Spring Boot中大量使用注解来简化配置。 但是随着注解的增加，重复的注解本身又变得繁琐。 所以Spring Boot定义了新的元注解(Meta-Annotation)结构来简化重复注解的配置。 注意：Spring Boot元注解的定义方式只作用于由Spring Boot框架解析的注解。其他第三方项目的注解不一定使用了这一框架来解析。 现在我们有一组常用的配置，我们需要在很多地方重复定义 而在Spring Boot中你可以这样定义 看上去就像是把元注解就地展开

尽管网上已经有许许多多的Spring Boot教程，但是其侧重点总是在如何搭建和配置WEB服务而非Spring Boot本身。 本教程将着重于Spring Boot本身，一方面介绍核心特性的用法，一方面结合源码一步步揭开Spring Boot的"魔法"。 Spring Boot提供的是一个快速开发框架，在其之上集成了许多组件集合可以开发各类应用，其中最常见的就是Web服务。本教程将主要针对Spring Boot本身和Spring Boot Web进行讲解。

世界由数据（值）和过程（函数），而过程又有白盒和黑盒。对于黑盒的过程，我们虽然能够得到输入输出却不能确切了解到系统内部。例如 这个简单的问题所有人脑都是一个实现，但是没有人可以用数字符号精确描述人脑是如何做到的。如何解析人脑构造似乎是脑科学家的工作，而统计学家（数据科学家）想要的只是以最低成本解答这一问题。这便开启了统计学回归分析的大门。(分类也可以看作是离散回归的一种，后文不作区分)

Database normalization is the process of structuring a relational database in accordance with a series of so-called normal forms in order to reduce data redundancy and improve data integrity. It was first proposed by Edgar F. Codd as an integral part

几天前我在stackoverflow上遇到了一个有趣的问题，我们从这个问题谈开去 @Nik Kotovski: 听说volatile可以阻止重排序，那么他的作用范围是多大呢？一行，一个大括号还是多少？举例： 可以肯定的是k和v肯定不会重排序，那么i,j,flag和v呢？i,j,k之间呢？ 我的回答很长，浓缩成一句即是 The volatile only guarantee the happens-before relation. 题主给我的回复是

我们还是以吮指原味鸡为例，KFC分为后厨和前台。后厨产鸡(producer)，前台卖鸡(consumer)，由不同的人(thread)来负责。 两种策略各有优劣， 在实践中应该选用合适的模型。 为了防止顾客久等，KFC在前台和后厨之间放置了一个货架(buffer)，用来暂时存放多于的鸡。这是一种最典型最直接的处理方式来避免人员(thread)等待。事实上RxJava就是这么做的。observeOn操作符就带有一个bufferSize参数可以设置货架的大小。

RxJava 为我们提供了两个调度操作符subscribeOn和observeOn. 它们分别可以在订阅(subscribe)阶段和观察(observe)阶段进行线程的调度。 示例代码

继续刚才KFC的例子。 我们都知道吮指原味鸡来自于鸡的不同部位，分别有鸡腿，鸡胸和鸡肋。 现在我这个人很挑，不吃鸡肋，该怎么办呢。 最直接的想法，我们当然可以很直接在KFC(Publisher)内做判断。 但是很快我们就发现了问题 想象一条流水线，KFC是起点，我是终点，我们不应该让KFC再也不生产鸡肋，而是应该在流水线上安排一个工人(KFC服务员)，由服务员来帮我们过滤鸡肋。KFC对服务员负责，服务员对我负责。

Reactive-streams 是 RxJava的唯一依赖，它是一项响应式编程API标准，已被java标准库收录。 Reactive-streams只定义了4个接口共计7个方法，这7个方法构成了整个Reactive世界。 由于这些方法都太直观了没什么好说的，我就举个例子: