Apache HTTP Server 用 C 编写，不涉及 Java；文中所述“Event 架构”实指 Tomcat 的 NIO/NIO2 事件驱动模型，其通过 Acceptor、Poller 和 Executor 线程分工实现非阻塞 I/O 与业务逻辑解耦。
apache http server 本身是用 c 编写的，不直接使用 java 或 jvm；你提到的“java 中 apache 在 event 架构下监听线程与工作线程协作”，实际指向的很可能是 apache tomcat（java web 容器），尤其是其基于 nio/nio2 的 apr/native 或 nio2 connector 配置下的事件驱动模型（即 “event” protocol，已从 tomcat 8.5+ 起逐步被 nio2 取代，但概念仍适用）。
Tomcat 的 event 协议本质是 Reactor 模式
在旧版 Tomcat（如 7.x）中启用 protocol="org.apache.coyote.http11.Http11Protocol" 并配合 executor 时，默认是阻塞 I/O（BIO）；而启用 protocol="org.apache.coyote.http11.Http11NioProtocol"（或更早的 Http11NioProtocol + useSendfile="false"）并设置 maxThreads 和 acceptorThreadCount，就进入了典型的“监听-事件分发-工作执行”协作模型：
-
监听线程（Acceptor）：由
acceptorThreadCount控制（默认 1），只负责调用ServerSocketChannel.accept()，获取新连接的SocketChannel，然后立即注册到共享的Selector上，不处理请求内容。 -
事件轮询线程（Poller）：每个 Poller 是一个独立线程，持有专属
Selector，持续调用select()检测就绪事件（如 OP_READ、OP_WRITE）。一旦发现某 channel 可读，就将该 channel 封装为SocketProcessor任务，提交给共享线程池。 -
工作线程（Executor Thread）：来自配置的
Executor（如org.apache.catalina.core.StandardThreadExecutor），真正解析 HTTP 请求、调用 Servlet、生成响应。它不参与 I/O 等待，纯 CPU/业务逻辑处理。
关键协作机制：避免阻塞，解耦 I/O 与业务
这种分工的核心目标是防止慢请求（如数据库查询、远程调用）阻塞 I/O 处理能力：
- Acceptor 不做 read/write，不解析协议，秒级完成 accept 后交出 channel。
- Poller 不做业务处理，只做轻量事件识别和任务投递；即使某个请求 body 很大，也只在 channel 可读时触发一次投递，后续由工作线程循环 read（或借助
ReadListener异步流式读取）。 - 工作线程若需异步响应（如长轮询、SSE），可调用
request.startAsync()，释放当前线程，后续通过 AsyncContext 派发回调，避免线程长期占用。
配置示例（server.xml 中 Connector）
以下是一个典型 NIO2（推荐替代旧 event）的配置，体现监听与工作分离：
maxThreads="200"
minSpareThreads="10"
acceptorThreadCount="2"
pollerThreadCount="4"
connectionTimeout="20000"
redirectPort="8443" />
其中：
– acceptorThreadCount="2"：2 个线程争抢 accept 权限（适合高并发端口复用场景）；
– pollerThreadCount="4"：4 个 Selector 轮询线程，分摊事件检测压力；
– maxThreads="200"：最多 200 个工作线程处理请求逻辑。
注意：Tomcat 9+ 已弃用独立 event 协议
早期 Tomcat 7 的 Http11AprProtocol（基于 APR/native 库）曾提供真正的 event 模型（epoll/kqueue），但 Java 层统一抽象后，NIO2 Connector 已成为标准。所谓“event 架构”现在更多指代这种非阻塞、多线程协作的 I/O 处理范式，而非某个特定 protocol 名称。开发中应优先使用 Http11Nio2Protocol 并合理调优线程数，而非寻找已移除的 event 配置。
立即学习“Java免费学习笔记（深入）”；
