以下内容为随手记的，若看客不知鄙人所云，还请原谅则个..............
公司用的vertx，在国内，这还是款比较年轻的框架，你也可以把他当做一个工具，官网上的说法是：
Vert.x is a tool-kit for building reactiveapplications on the JVM.
公司一直用的标准的verticle，因为并没有什么长任务或阻塞任务的接口，所以一直没有使用worker verticle的强烈需求，即使后来简单重构，也只是用注解和反射外加封装，精简了项目的代码量，私以为，没有worker verticle的vertx能称为vertx吗·········
今天试了试worker verticle，遇见了一些小坑，来篇随笔，纪念一下：
我在老大给的demo里面将所有的标准的verticle替换成 worker verticle，然后故意阻塞一个verticle1里的方法，调用另一个verticle2的某个方法，或者调用阻塞的verticle1的某个方法，总是阻塞，无法成功调用，找了半天才发现，老大给的demo的里的数据库连接数就给了如下：
<property name="initialSize" value="1"/>
<property name="minIdle" value="1"/>
<property name="maxActive" value="2"/>
我不停的调用接口，所以连接数不够，发现原因的我眼泪留下来，我擦泪·············
增加连接数后，果然接口能调通了，瞬间喜大普奔，
but！！！！！！！！！！
当被阻塞的方法处于阻塞状态时，此时再次调用该方法，也是处于阻塞等待状态，必须等待前一次调用的阻塞的方法结束后才能执行，
有点绕口，容我重新组织一下语言，
该方法中有如下判断：
if（i==1）{
Thread.sleep（100000）；
}
第一次调该方法时，i=1；第二次调用该方法时，i=2；所以第一次被阻塞，第二次不阻塞；
第二次调用 仍然 会等待 第一次 执行完成后，才会执行第二次调用。
查看文档，研究半天，发现：
worker verticles不会并行的执行Handler.而是阻塞式的,等待上一个Handler处理完了,才会再执行后面的请求！
这怎么可以，我可是一个想让所有verticle的每个方法都可以并行执行的伟大的man，
so！
我发现了个神奇的api：
<T> void executeBlocking(Handler<Future<T>> blockingCodeHandler, boolean ordered, Handler<AsyncResult<T>> resultHandler);
这个api的参数：ordered可以指定worker verticles是顺序执行还是并发执行。
使用之后发现，
改方法第一次被阻塞，第二次调用没有被阻塞（在第一次调用仍处于阻塞状态时）；
终于，问题解决了，瞬间神清气爽，
啦啦德玛西亚！
以上
（公司产品代码，不好公开，看客见谅）