Vert.x Core

Vert.x core contains fairly low-level functionality, including support for HTTP, TCP, file system access, and various other features. You can use this directly in your own applications, and it’s used by many of the other components of Vert.x.

Vert.x中，有以下的核心概念需要了解

Vertx

Vertx实例(instance)可以通过静态工厂方法

1

Vertx vertx = Vertx.vertx();

创建，一个Vertx实例可以用于部署HTTP、TCP Server,client等等操作，可以将Vertx instance看做一个Vert.x Core API 的入口。

Eventloop

Vert.x使用了Reactor模型，通过Event driven的方式，将Events分发到handlers中进行处理，任何event都不会阻塞Eventloop线程，这样Eventloop线程可以一直保持高速分发Events的速度。假设在同一时间有很多HTTP请求到达服务器，Eventloop会将每一个http request分发到handler中处理，比如有10K个Requests,假设服务器想在1s内处理这些requests，那么平均算下来Eventloop必须能在0.1ms内分发完每个event，一旦Eventloop被阻塞，整个服务器吞吐量都会受到极大影响。所以Eventloop绝对不应该被阻塞住，所有交给Eventloop去处理的event都应该是non-blocking(I/O)的方式或者CPU执行时间较短的，这样才能确保每个event得到及时的分发。

而Vert.x不仅仅实现了Reactor模型，还实现了Multi-Reactor模型，也就是说，每个Vertx instance都会有多个Eventloop，默认的设置是Eventloop数量对应CPU核心数量乘以2，在VertxOptions类中可以看到

1
2
3
4

/**
 * The default number of event loop threads to be used  = 2 * number of cores on the machine
 */
public static final int DEFAULT_EVENT_LOOP_POOL_SIZE = 2 * CpuCoreSensor.availableProcessors();

可以通过setEventLoopPoolSize()方法改变Vertx实例拥有Eventloop的数量。

流的概念

流(Stream)是Java8中新增加的API中的一员。流(Stream)通过声明式方式来处理集合(Collection),并且支持并行化操作。先来看一个例子。

假如现在有一个Student列表，Student的属性包括姓名name,年龄age,分数mark，现在要筛选出年龄小于20岁并且分数大于80的学生的姓名名单，以前的做法是这样的

1
2
3
4
5
6
7
8

List<Student> studentList = new ArrayList<>();
//增加studentList数据
List<String> studentNameList = new ArrayList<>();
for (Student student : studentList) {
    if (student.getAge() < 20 && student.getMark() > 80) {
        studentNameList.add(student.getName());
    }
}

使用了流以后，代码变成这样了

1
2
3
4
5

studentNameList = studentList.stream()
                .filter(student -> student.getAge() < 20)
                .filter(student -> student.getMark() > 80)
                .map(Student::getName)
                .collect(Collectors.toList());

通过Stream API来操作集合，这种方式有以下几个好处

• 声明性
  比起自己实现的方式更简洁易读
• 复合性
  具有更佳的灵活性，可以将多个处理链式调用起来
• 并行化处理
  支持并行化操作，性能更好

流的特性

在使用流(Stream)之前，先需要了解流的一些特性。

懒惰特性(laziness)

Stream的操作并不会立即执行，只有在真正需要结果的时候才会执行。

一次消费

Stream只能被消费一次，比如使用多次foreach进行多次遍历是不行的，只能遍历一次，如果要再遍历只能重新生成流。

流可以是无限的

集合是有固定大小的，而流(Stream)可以是无限的。limit和findAny这种短路操作可以对无限流完成很快的计算。

使用内部迭代(internal iteration)

在以前的版本中迭代往往都是外部迭代，需要用户通过比如(for,foreach)这样的循环操作去手动迭代，而Stream API则使用内部迭代，替用户完成了迭代的过程，这样也不用去保存一堆中间变量。

中间操作(intermediate operations)与终端操作(terminal operations)

中间操作通常返回类型是Stream，中间操作会返回一个新的Stream，终端操作会返回用户需要的类型。

Lambda表达式

Java8中引入了Lambda表达式，Lambda表达式其实就是匿名函数。匿名函数就是没有方法名的函数。可以看下面一个例子，假如定义一个打印Hello,world的线程，之前可能这样写

1
2
3
4
5
6

Thread thread1 = new Thread(new Runnable() {
            @Override
            public void run() {
                System.out.println("Hello,world");
            }
        });

通过匿名内部类的方式，将打印Hello,world告诉Thread，在Java8中，引入Lambda表达式大大简化了代码，可以直接将行为进行传递

1

Thread thread2 = new Thread(() -> System.out.println("Hello,world"));

Lambda表达式的定义

1

(int x, int y) -> x + y;

其中(int x, int y)是Lambda表达式的参数，->箭头后面的x+y是函数的主体部分。返回值为x+y。
在上面的线程打印例子中，

1

() -> System.out.println("Hello,world")

这段代码也是Lambda表达式，输入参数为空，返回类型也是void。

解释器模式

意图

给定一个语言，定义它的文法的一种表示，并定义一个解释器，这个解释器使用该表示来解释语言中的句子。

使用场景

当有一个语言需要解释执行, 并且你可将该语言中的句子表示为一个抽象语法树时，可使用解释器模式。而当存在以下情况时该模式效果最好：

• 该文法简单对于复杂的文法, 文法的类层次变得庞大而无法管理。此时语法分析程序生成器这样的工具是更好的选择。它们无需构建抽象语法树即可解释表达式, 这样可以节省空间而且还可能节省时间。
• 效率不是一个关键问题最高效的解释器通常不是通过直接解释语法分析树实现的, 而是首先将它们转换成另一种形式。例如，正则表达式通常被转换成状态机。但即使在这种情况下, 转换器仍可用解释器模式实现, 该模式仍是有用的。

结构

解释器模式结构如下

• AbstractExpression(抽象表达式)
  
  – 声明一个抽象的解释操作，这个接口为抽象语法树中所有的节点所共享。

• TerminalExpression(终结符表达式)
  
  – 实现与文法中的终结符相关联的解释操作。
  
  – 一个句子中的每个终结符需要该类的一个实例。

• NonterminalExpression(非终结符表达式)
  
  – 对文法中的每一条规则R ::= R1R2. . . Rn都需要一个NonterminalExpression类。
  
  – 为从R1到Rn的每个符号都维护一个AbstractExpression类型的实例变量。
  
  – 为文法中的非终结符实现解释(Interpret)操作。解释(Interpret)一般要递归地调用表示R1到Rn的那些对象的解释操作。

• Context(上下文)
  
  – 包含解释器之外的一些全局信息。

• Client(客户端)
  
  – 构建(或被给定) 表示该文法定义的语言中一个特定的句子的抽象语法树。该抽象语法树由NonterminalExpression和TerminalExpression的实例装配而成。
  
  – 调用解释操作。

协作

• Client构建(或被给定)一个句子, 它是NonterminalExpression和TerminalExpression的实例的一个抽象语法树，然后初始化上下文并调用解释操作。
• 每一非终结符表达式节点定义相应子表达式的解释操作。而各终结符表达式的解释操作构成了递归的基础。
• 每一节点的解释操作用上下文来存储和访问解释器的状态。

效果

解释器模式有下列的优点和不足:

• 易于改变和扩展文法
  
  – 因为该模式使用类来表示文法规则, 你可使用继承来改变或扩展该文法。已有的表达式可被增量式地改变,而新的表达式可定义为旧表达式的变体。

• 也易于实现文法
  
  – 定义抽象语法树中各个节点的类的实现大体类似。这些类易于直接编写，通常它们也可用一个编译器或语法分析程序生成器自动生成。

• 复杂的文法难以维护
  
  – 解释器模式为文法中的每一条规则至少定义了一个类(使用BNF定义的文法规则需要更多的类)。因此包含许多规则的文法可能难以管理和维护。可应用其他的设计模式来缓解这一问题。但当文法非常复杂时, 其他的技术如语法分析程序或编译器生成器更为合适。

• 增加了新的解释表达式的方式
  
  – 解释器模式使得实现新表达式“计算”变得容易。例如，你可以在表达式类上定义一个新的操作以支持优美打印或表达式的类型检查。如果你经常创建新的解释表达式的方式, 那么可以考虑使用Visitor模式以避免修改这些代表文法的类。

访问者模式

意图

表示一个作用于某对象结构中的各元素的操作。它使你可以在不改变各元素的类的前提下定义作用于这些元素的新操作。

使用场景

在下列情况下使用Visitor模式：

• 一个对象结构包含很多类对象，它们有不同的接口，而你想对这些对象实施一些依赖于其具体类的操作。
• 需要对一个对象结构中的对象进行很多不同的并且不相关的操作，而你想避免让这些操作“污染”这些对象的类。Visitor使得你可以将相关的操作集中起来定义在一个类中。当该对象结构被很多应用共享时，用Visitor模式让每个应用仅包含需要用到的操作。
• 定义对象结构的类很少改变，但经常需要在此结构上定义新的操作。改变对象结构类需要重定义对所有访问者的接口，这可能需要很大的代价。如果对象结构类经常改变，那么可能还是在这些类中定义这些操作较好。

结构

访问者模式结构如下

• Visitor
  
  – 为该对象结构中ConcreteElement的每一个类声明一个Visit操作。该操作的方法名和参数标识了发送Visit请求给该Visitor的那个类。这使得Visitor可以确定正被访问元素的具体的类。这样Visitor就可以通过该元素的特定接口直接访问它。

• ConcreteVisitor
  
  – 实现每个由Visitor声明的操作。每一个操作实现了Structure对象中相关的类所定义的算法的一部分。ConcreteVisitor为该算法提供了上下文并存储它的局部状态。这一状态常常在遍历该结构的过程中累积结果。

• Element
  
  – 定义一个Accept操作，它以一个访问者为参数。

• ConcreteElement
  
  – 实现Accept操作，该操作以一个访问者为参数。

• ObjectStructure
  
  – 能枚举它的元素。
  
  – 可以提供一个高层的接口以允许该访问者访问它的元素。
  
  – 可以是一个Composite模式或是一个集合，如一个列表或一个无序集合。

协作

• 一个使用Visitor模式的Client必须创建一个ConcreteVisitor对象，然后遍历该对象结构，并用该访问者访问每一个元素。
• 当一个元素被访问时，它调用对应于它的类的Visitor操作。如果必要，该元素将自身作为这个操作的一个参数以便该访问者访问它的状态。

效果

• 访问者模式使得易于增加新的操作
  
  – 访问者使得增加依赖于复杂对象结构的构件的操作变得容易了。仅需增加一个新的Visitor即可在一个对象结构上定义一个新的操作。相反，如果每个功能都分散在多个类之上的话，定义新的操作时必须修改每一类。

• 访问者集中相关的操作而分离无关的操作
  
  – 相关的行为不是分布在定义该对象结构的各个类上，而是集中在一个Visitor中。无关行为却被分别放在它们各自的Visitor子类中。这就既简化了这些元素的类，也简化了在这些访问者中定义的算法。所有与它的算法相关的数据结构都可以被隐藏在访问者中。

• 增加新的ConcreteElement类很困难
  
  – Visitor模式使得难以增加新的Element的子类。每添加一个新的ConcreteElement都要在Visitor中添加一个新的抽象操作，并在每一个ConcreteElement类中实现相应的操作。有时可以在Visitor中提供一个缺省的实现，这一实现可以被大多数的ConcreteVisitor继承，但这与其说是一个规律还不如说是一种例外。所以在应用访问者模式时考虑关键的问题是系统的哪个部分会经常变化，是作用于对象结构上的算法呢还是构成该结构的各个对象的类。如果老是有新的ConcreteElement类加入进来的话，Visitor类层次将变得难以维护。在这种情况下，直接在构成该结构的类中定义这些操作可能更容易一些。如果Element类层次是稳定的，而你不断地增加操作获修改算法，访问者模式可以帮助你管理这些改动。

• 通过类层次进行访问
  
  – 一个迭代器可以通过调用节点对象的特定操作来遍历整个对象结构，同时访问这些对象。但是迭代器不能对具有不同元素类型的对象结构进行操作，而Visitor可以对不同类型对象进行操作。

• 累积状态
  
  – 当访问者访问对象结构中的每一个元素时，它可能会累积状态。如果没有访问者，这一状态将作为额外的参数传递给进行遍历的操作，或者定义为全局变量。

• 破坏封装
  
  – 访问者方法假定ConcreteElement接口的功能足够强，足以让访问者进行它们的工作。结果是，该模式常常迫使你提供访问元素内部状态的公共操作，这可能会破坏它的封装性。

中介者模式

意图

用一个中介对象来封装一系列的对象交互。中介者使各对象不需要显式地相互引用，从而使其耦合松散，而且可以独立地改变它们之间的交互。

使用场景

在下列情况下使用中介者模式:

• 一组对象以定义良好但是复杂的方式进行通信。产生的相互依赖关系结构混乱且难以理解。
• 一个对象引用其他很多对象并且直接与这些对象通信,导致难以复用该对象。
• 想定制一个分布在多个类中的行为，而又不想生成太多的子类。

结构

中介者模式结构如下

• Mediator
  
  – 中介者定义一个接口用于与各同事(Colleague)对象通信。

• ConcreteMediator
  
  – 具体中介者通过协调各同事对象实现协作行为。
  
  – 了解并维护它的各个同事。

• Colleague
  
  – 每一个同事类都知道它的中介者对象。
  
  – 每一个同事对象在需与其他的同事通信的时候，与它的中介者通信。

协作

Colleague向一个Mediator对象发送和接收请求。Mediator在各Coleague间适当地转发请求以实现协作行为。

效果

中介者模式有以下优点和缺点:

1. 减少了子类生成
   
   Mediator将原本分布于多个对象间的行为集中在一起。改变这些行为只需生成Mediator的子类即可。这样各个Colleague类可被重用。

2. 它将各Colleague解耦
   
   Mediator有利于各Colleague间的松耦合. 你可以独立的改变和复用各Colleague类和Mediator类。

3. 它简化了对象协议
   
   用Mediator和各Colleague间的一对多的交互来代替多对多的交互。一对多的关系更易于理解、维护和扩展。

4. 它对对象如何协作进行了抽象
   
   将中介作为一个独立的概念并将其封装在一个对象中，使你将注意力从对象各自本身的行为转移到它们之间的交互上来。这有助于弄清楚一个系统中的对象是如何交互的。

5. 它使控制集中化
   
   中介者模式将交互的复杂性变为中介者的复杂性。因为中介者封装
   了协议, 它可能变得比任一个Colleague都复杂。这可能使得中介者自身成为一个难于维护的
   庞然大物。

迭代器模式

迭代器模式(Iterator)又可以称为游标(Cursor)。

意图

提供一种方法顺序访问一个聚合对象中各个元素, 而又不需暴露该对象的内部表示。

使用场景

迭代器模式可用来：

• 访问一个聚合对象的内容而无需暴露它的内部表示。
• 支持对聚合对象的多种遍历。
• 为遍历不同的聚合结构提供一个统一的接口(即, 支持多态迭代)。

结构

迭代器模式结构如下

• Iterator（迭代器）
  
  – 迭代器定义访问和遍历元素的接口。

• ConcreteIterator（具体迭代器）
  
  – 具体迭代器实现迭代器接口。
  
  – 对该聚合遍历时跟踪当前位置。

• Aggregate（聚合）
  
  – 聚合定义创建相应迭代器对象的接口。

• ConcreteAggregate（具体聚合）
  
  – 具体聚合实现创建相应迭代器的接口，该操作返回ConcreteIterator的一个适当的实例。

协作

ConcreteIterator跟踪聚合中的当前对象，并能够计算出待遍历的后继对象。

效果

迭代器模式有三个重要的作用：

1. 它支持以不同的方式遍历一个聚合复杂的聚合可用多种方式进行遍历。
   
   迭代器模式使得改变遍历算法变得很容易: 仅需用一个不同的迭代器的实例代替原先的实例即可。你也可以自己定义迭代器的子类以支持新的遍历。

2. 迭代器简化了聚合的接口
   
   有了迭代器的遍历接口，聚合本身就不再需要类似的遍历接口了。这样就简化了聚合的接口。

3. 在同一个聚合上可以有多个遍历
   
   每个迭代器保持它自己的遍历状态。因此你可以同时进行多个遍历。

观察者模式

观察者模式(Observer)又可以称为发布-订阅模式(Publish-Subscribe)

意图

定义对象间的一种一对多的依赖关系,当一个对象的状态发生改变时, 所有依赖于它的对象都得到通知并被自动更新。

使用场景

在以下任一情况下可以使用观察者模式：

• 当一个抽象模型有两个方面, 其中一个方面依赖于另一方面。将这二者封装在独立的对象中以使它们可以各自独立地改变和复用。
• 当对一个对象的改变需要同时改变其它对象, 而不知道具体有多少对象有待改变。
• 当一个对象必须通知其它对象，而它又不能假定其它对象是谁。换言之, 你不希望这些对象是紧密耦合的。

结构

观察者模式结构如下

• Subject（目标）
  
  – 目标知道它的观察者。可以有任意多个观察者观察同一个目标。
  
  – 提供注册和删除观察者对象的接口。

• Observer（观察者）
  
  – 为那些在目标发生改变时需获得通知的对象定义一个更新接口。

• ConcreteSubject（具体目标）
  
  – 将有关状态存入各ConcreteObserver对象。
  
  – 当它的状态发生改变时, 向它的各个观察者发出通知。

• ConcreteObserver（具体观察者）
  
  – 维护一个指向ConcreteSubject对象的引用。
  
  – 存储有关状态，这些状态应与目标的状态保持一致。
  
  – 实现Observer的更新接口以使自身状态与目标的状态保持一致。

协作

• 当ConcreteSubject发生任何可能导致其观察者与其本身状态不一致的改变时，它将通知它的各个观察者。
• 在得到一个具体目标的改变通知后, ConcreteObserver对象可向目标对象查询信息。ConcreteObserver使用这些信息以使它的状态与目标对象的状态一致。

效果

Observer模式允许你独立的改变目标和观察者。你可以单独复用目标对象而无需同时复用其观察者, 反之亦然。它也使你可以在不改动目标和其他的观察者的前提下增加观察者。
下面是观察者模式其它一些优缺点：

• 目标和观察者间的抽象耦合
  
  一个目标所知道的仅仅是它有一系列观察者, 每个都符合抽象的Observer类的简单接口。目标不知道任何一个观察者属于哪一个具体的类。这样目标和观察者之间的耦合是抽象的和最小的。
• 支持广播通信
  
  不像通常的请求, 目标发送的通知不需指定它的接收者。通知被自动广播给所有已向该目标对象登记的有关对象。目标对象并不关心到底有多少对象对自己感兴趣；它唯一的责任就是通知它的各观察者。这给了你在任何时刻增加和删除观察者的自由。处理还是忽略一个通知取决于观察者。
• 意外的更新
  
  因为一个观察者并不知道其它观察者的存在, 它可能对改变目标的最终代价一无所知。在目标上一个看似无害的的操作可能会引起一系列对观察者以及依赖于这些观察者的那些对象的更新。此外, 如果依赖准则的定义或维护不当，常常会引起错误的更新, 这种错误通常很难捕捉。

职责链模式

意图

使多个对象都有机会处理请求，从而避免请求的发送者和接收者之间的耦合关系。将这些对象连成一条链，并沿着这条链传递该请求，直到有一个对象处理它为止。

使用场景

在以下条件下使用职责链：

• 有多个的对象可以处理一个请求，哪个对象处理该请求运行时刻自动确定。
• 你想在不明确指定接收者的情况下，向多个对象中的一个提交一个请求。
• 可处理一个请求的对象集合应被动态指定。

结构

职责链模式结构如下

• Handler
  
  – 定义一个处理请求的接口。
  
  – (可选) 实现后继链。

• ConcreteHandler
  
  – 处理它所负责的请求。
  
  – 可访问它的后继者。
  
  – 如果可处理该请求，就处理之；否则将该请求转发给它的后继者。

• Client
  
  – 向链上的具体处理者(ConcreteHandler)对象提交请求。

协作

当客户提交一个请求时，请求沿链传递直至有一个ConcreteHandler对象负责处理它。

效果

职责链有下列优点和缺点：

• 降低耦合度
  
  该模式使得一个对象无需知道是其他哪一个对象处理其请求。对象仅需知道该请求会被“正确”地处理。接收者和发送者都没有对方的明确的信息，且链中的对象不需知道链的结构。结果是，职责链可简化对象的相互连接。它们仅需保持一个指向其后继者的引用，而不需保持它所有的候选接受者的引用。
• 增强了给对象指派职责( Responsibility)的灵活性
  
  当在对象中分派职责时，职责链给你更多的灵活性。你可以通过在运行时刻对该链进行动态的增加或修改来增加或改变处理一个请求的那些职责。你可以将这种机制与静态地指定Handler的继承机制结合起来使用。
• 不保证请求被接受
  
  既然一个请求没有明确的接收者，那么就不能保证它一定会被处理，该请求可能一直到链的末端都得不到处理。一个请求也可能因该链没有被正确配置而得不到处理。

备忘录模式

意图

在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态。这样以后就可将该对象恢复到原先保存的状态。

使用场景

在以下情况下使用备忘录模式：

• 必须保存一个对象在某一个时刻的(部分)状态, 这样以后需要时它才能恢复到先前的状态。
• 支持取消操作。
• 如果一个用接口来让其它对象直接得到这些状态，将会暴露对象的实现细节并破坏对象的封装性。

结构

备忘录模式结构如下

• Memento(备忘录)
  
  – Memento存储Originator对象的内部状态。Originator根据需要决定Memento存储Originator的哪些内部状态。
  
  – 防止Originator以外的其他对象访问Memento。Memento实际上有两个接口，管理者(caretaker)只能看到Memento的窄接口—它只能将Memento传递给其他对象。相反, Originator能够看到一个宽接口, 允许它访问返回到先前状态所需的所有数据。理想的情况是只允许生成本Memento的那个原发器访问本Memento的内部状态。

• Originator(原发器)
  
  – Originator创建一个Memento,用以记录当前时刻它的内部状态。
  
  – 使用Memento恢复内部状态。

• Caretaker(管理器)
  
  – 负责保存好Memento。
  
  – 不能对Memento的内容进行操作或检查。

协作

• Caretaker向Originator请求一个Memento，保留一段时间后，将其送回给Originator。有时Caretaker不会将Memento返回给Originator, 因为Originator可能根本不需要退到先前的状态。
• Memento是被动的。只有创建Memento的Originator会对它的状态进行赋值和检索。

时序图如下所示

效果

• 保持封装边界
  
  – 使用备忘录可以避免暴露一些只应由Originator管理却又必须存储在Originator之外的信息。该模式把可能很复杂的Originator内部信息对其他对象屏蔽起来, 从而保持了封装边界。

• 它简化了Originator
  
  – 在其他的保持封装性的设计中, Originator负责保持客户请求过的内部状态版本。这就把所有存储管理的重任交给了Originator。让客户管理它们请求的状态将会简化Originator, 并且使得客户工作结束时无需通知原发器。

• 使用备忘录可能代价很高
  
  – 如果原发器在生成备忘录时必须拷贝并存储大量的信息, 或者客户非常频繁地创建备忘录和恢复Originator状态，可能会导致非常大的开销。除非封装和恢复Originator状态的开销不大, 否则该模式可能并不合适。

• 定义窄接口和宽接口
  
  – 在一些语言中可能难以保证只有原发器可访问备忘录的状态。

• 维护备忘录的潜在代价
  
  – 管理器负责删除它所维护的备忘录。然而, 管理器不知道备忘录中有多少个状态。因此当存储备忘录时，一个本来很小的管理器，可能会产生大量的存储开销。