在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世界。 由于这些方法都太直观了没什么好说的，我就举个例子: