解道Vert.x线程模型

解道Vert.x线程模型
1.线程模型概述
Vert.x的线程模型设计的非常巧妙。

总的来说，Vert.x中主要有两种线程：Event Loop线程和Worker线程。

其中，Event Loop 线程结合了Netty的EventLoop，用于处理事件。

每一个EventLoop都与唯一的线程相绑定，这个线程就叫Event Loop线程。

Event Loop线程不能被阻塞，否则事件将无法被处理。

Worker线程用于执行阻塞任务，这样既可以执行阻塞任务而又不阻塞Event Loop线程。

如果像Node.js一样只有单个Event Loop的话就不能充分利用多核CPU的性能了。

为了充分利用多核CPU的性能，Vert.x中提供了一组Event Loop线程。

每个Event Loop线程都可以处理事件。

为了保证线程安全，防止资源争用，Vert.x保证了某一个Handler 总是被同一个Event Loop线程执行，这样不仅可以保证线程安全，而且还可以在底层对锁进行优化提升性能。

所以，只要开发者遵循Vert.x的线程模型，开发者就不需要再担心线程安全的问题，这是非常方便的。

本篇文章将底层的角度来解析Vert.x的线程模型。

对应的Vert.x版本为3.3.3。

2.Event Loop线程
首先回顾一下Event Loop线程，它会不断地轮询获取事件，并将获取到的事件分发到对应的事件处理器中进行处理：
Vert.x线程模型中最重要的一点就是：永远不要阻塞Event Loop线程。

因为一旦处理事件的线程被阻塞了，事件就会一直积压着不能被处理，整个应用也就不能正常工作了。

Vert.x中内置一种用于检测Event Loop是否阻塞的线程：vertx-blocked-thread-checker。

一旦Event Loop处理某个事件的时间超过一定阈值（默认为2000ms）就会警告，如果阻塞的时间过长就会抛出异常。

Block Checker的实现原理比较简单，底层借助了JUC的TimerTask，定时计算每个Event Loop线程的处理事件消耗的时间，如果超时就进行相应的警告。

3.Vert.x Thread
Vert.x中的Event Loop线程及Worker线程都用VertxThread类表示，并通过VertxThreadFactory线程工厂来创建。

除了创建VertxThread线程之外，VertxThreadFactory还会将此线程注册至Block Checker线程中以监视线程的阻塞情况，并且将此线程添加至内部的weakMap中。

这个weakMap作用只有一个，就是在注销对应的Verticle的时候可以将每个VertxThread中的Context实例清除(unset)。

为了保证资源不被一直占用，这里使用了WeakHashMap来存储每一个VertxThread。

当里面的VertxThread的引用不被其他实例持有的时候，它就会被标记为可清除的对象，等待GC。

至于VertxThread，它其实就是在普通线程的基础上存储了额外的数据（如对应的Vert.x Context，最大执行时长，当前执行时间，是否为Worker线程等），这里就不多讲了。

4.Vert.x Context
Vert.x底层中一个重要的概念就是Context，每个Context都会绑定着一个Event Loop线程（而一个Event Loop线程可以对应多个Context）。

我们可以把Context看作是控制一系列的Handler的执行作用域及顺序的上下文对象。

每当Vert.x底层将事件分发至Handler的时候，Vert.x都会给此Handler钦点一个Context用于处理任务：
∙如果当前线程是Vert.x线程(VertxThread)，那么Vert.x就会复用此线程上绑定的Context；如果没有对应的Context就创建新的
∙如果当前线程是普通线程，就创建新的Context
Vert.x中存在三种Context，与之前的线程种类相对应：
∙EventLoopContext
∙WorkerContext
MultiThreadedWorkerContext
4.1 Event loop context
每个Event Loop Context都会对应着唯一的一个EventLoop，即一个Event Loop Context只会在同一个Event Loop线程上执
在Netty中，EventLoopGroup代表一组EventLoop，而从中获取EventLoop的方法则是next方法。

EventLoopGroup中EventLoop
对应的轮询算法：
可以看到尽管每个Context对应唯一的Event Loop线程，而每个Event Loop线程却可能对应多个Context。

Event Loop Context会在对应的EventLoop中执行Handler进行事件的处理（IO事件，非阻塞）。

Vert.x会保证同一个Handler 会一直在同一个Event Loop线程中执行，这样可以简化线程模型，让开发者在写Handler的时候不需要考虑并发的问题，非常方便。

我们来粗略地看一下Handler是如何在EventLoop上执行的。

EventLoopContext中实现了executeAsync方法用于包装Handler
这里Vert.x使用了wrapTask方法将Handler封装成了一个Runnable用于向EventLoop中提交。

代码比较直观，大致就是检查当前线程是否为Vert.x线程，然后记录事件处理开始的时间，给当前的Vert.x线程设置Context，并且调用Handler里面的事件处理方法。

具体请参考源码，这里就不贴出来了。

那么把封装好的task提交到EventLoop以后，EventLoop是怎么处理的呢？这就需要更多的Netty相关的知识了。

根据Netty的模型，Event Loop线程需要处理IO事件，普通事件（即我们的Handler）以及定时事件（比如Vert.x的setTimer）。

Vert.x会
提供一个NETTY_IO_RATIO给Netty代表EventLoop处理IO事件时间占用的百分比（默认为50，即IO事件时间占用:非IO事件
这里面Netty会调用processSelectedKeys方法进行IO事件的处理，并且会计算出处理IO时间所用的事件然后计算出给非IO事件处理分配的时间，然后调用runAllTasks方法执行所有的非IO任务（这里面就有我们的各个Handler）。

runAllTasks会按顺序从内部的任务队列中取出任务(Runnable)然后进行安全执行。

而我们刚才调用的NioEventLoop的execute 方法其实就是将包装好的Handler置入NioEventLoop内部的任务队列中等待执行。

4.2 Worker context
顾名思义，Worker Context用于跑阻塞任务。

与Event Loop Context相似，每一个Handler都只会跑在固定的Worker线程下。

Vert.x还提供一种Multi-threaded worker context可以在多个Worker线程下并发执行任务，这样就会出现并发问题，需要开发者自行解决并发问题。

因此一般情况下我们用不到Multi-threaded worker context。

4.3 Verticle
我们再来讨论一下Verticle中的Context。

在部署Verticle的时候，Vert.x会根据配置来创建Context并绑定到Verticle上，
通过这样一种方式，Vert.x保证了Verticle的线程安全——即某个Verticle上的所有Handler都会在同一个Vert.x线程上执行，这样也保证了Verticle内部成员的安全（没有race condition问题）。

比如下面Verticle中处理IO及事件的处理都一直是在
5.线程池
5.1 Event Loop线程池
之前我们已经提到过，Event Loop线程池的类型为Netty中的NioEventLoopGroup，里面的线程通过Vert.x自己的线程工厂
其中Event Loop线程的数目可以在配置中指定。

5.2 Worker线程池
Worker线程同样由VertxThreadFactory构造，类型为VertxThread，用于执行阻塞任务。

我们同样可以在配置中指定其数目。

5.3 内部阻塞线程池
Internal Blocking Pool可能设计用于内部使用，在executeBlocking(Action<T> action,
Handler<AsyncResult<T>>resultHandler)这个版本的方法中就使用了它。

5.4 Acceptor Event Loop线程池
大家可能会发现VertxImpl类中还有一个acceptorEventLoopGroup。

顾名思义，它是Netty中的Acceptor线程池，负责处理客
由于系统只有一个服务端端口需要监听，因此这里只需要一个线程。

Vert.x中的HttpServer就利用了acceptorEventLoopGroup处理客户端的连接请求，具体的实现后边会另起一篇介绍。