为什么是垂直的。x为每个线程附加2个事件循环
在浏览vert.x Java devs guide时，我发现vert.x在每个CPU线程上附加了2个事件循环。与每个CPU线程1个事件循环相比，这对性能有何影响？
共有2个答案
这个概念被称为多反应器。事件循环是Reactor设计模式的一种实现。事件循环需要检查新事件并将它们分派给相应的处理程序。如果我们只使用一个线程来消耗所有事件，我们将不会最大限度地利用我们的硬件。在其他语言和框架中，多个线程/进程用于此。例如：节点。这就是为什么我们有多个Reactor。
在一个标准的reactor实现中，有一个事件循环线程，它在一个循环中运行，在所有事件到达时将它们传递给所有的处理程序。单线程的问题是它在任何时候都只能在单核上运行，因此如果您希望单线程reactor应用程序(例如Node.js应用程序)能够在多核服务器上扩展，您必须启动并管理许多不同的进程。Vert.x在这里的工作方式不同。每个Vertx实例维护几个事件循环，而不是单个事件循环。默认情况下，我们根据机器上可用内核的数量来选择数量，但这可以被覆盖。这意味着单个Vertx进程可以跨服务器扩展，这与Node.js不同。我们将这种模式称为多反应器模式，以区别于单线程反应器模式。
充分解释
在文档中，它说Vert.x每个核心CPU线程创建两个事件循环，即每个超线程1个事件循环。
-
我的vertx（4.0.2）应用程序是用Java（11）编写的，它使用了一些数据量大的垂直项，这些垂直项会导致延迟峰值，因为eventloop会被它们阻塞一段时间。出于这个原因，我想将这些垂直链接部署为工作垂直链接，这样eventloop和其他垂直链接就不再被阻塞。 不幸的是，我的应用程序现在崩溃了，因为顶点内的事件处理是由多个线程并发执行的；（ 如果我正确理解vertx文档，则不应发生这种情况：
-
我知道，在vert. x中，默认的版本将在每次我们不需要在处理程序中写入线程安全时运行在相同的事件循环中。 例如，如果我有一个运行HttpServer的版本- } 可以保证，在任何时候，我的请求处理程序都会在两个事件循环上被调用两次（针对2个不同的请求）。因此，我不必在请求处理程序中处理线程安全问题。 如果我运行多个HttpServer顶点实例- 我需要注意线程安全吗？多个请求处理程序（最大值=1
-
问题内容： 我正在尝试了解Redis的基础知识。Redis是无处不在的一种，它是使事情变得原子化的单线程，但是我无法想象这在内部是如何工作的。 如果它是IO绑定的应用程序（例如Node.js），则我们不设计服务器单线程，该线程在启动IO操作后释放了另一个请求的空间，并在IO操作完成后将数据返回给客户端（提供并发性）。但是在Redis的情况下所有数据都可以在主内存中使用，我们根本就不会做IO操作。那
-
我正在努力了解Redis的基础知识。其中一个不断出现的地方是，Redis是单线程的，使事物原子化。但我无法想象这是如何在内部工作的。我有以下疑问。 如果是IO绑定的应用程序（如node.js)，那么我们不是设计一个服务器单线程吗？线程在发起IO操作后为另一个请求提供空闲，并且在IO操作完成后将数据返回给客户机（提供并发）。但是在redis的情况下，所有的数据都在主存中可用，我们根本不做IO操作。那
-
我有一个非常简单的Vert。公开pingendpoint的x应用程序： 正如预期的那样，默认情况下为Vert。x创建了两个我可以通过VisualVM看到的事件循环线程： 当然，这个应用程序什么都不做，所以我知道你可以去给PingVerticle添加一个http服务器 现在，我在VisualVM中看到有两个新线程，一个接受线程，我可以或多或少理解，另一个事件循环线程： 为什么要创建第三个eventl
-
考虑这个简单的C++函数来计算数组的前缀和： 它是4个融合的UOP1，这个CPU可以支持4个融合的OPs/周期。 有通过和携带的依赖链，每个都是一个循环，但是这些UOP可以到4个ALU端口中的任何一个，所以似乎不太可能冲突。融合的需要转到p6，这是一个更令人担忧的问题，但我只测量到p6的1.1 UOPS/迭代。这将解释每次迭代1.1个循环，但不是1.4个循环。如果我将循环展开2倍，端口压力会低得多