09 | 比较：Jetty架构特点之Connector组件

有两个问题请教老师： 问题一：根据文章看，Jetty中有多个Acceptor组件，请问这些Acceptor背后是共享同一个ServerSocketChannel？还是每个Acceptor有自己的ServerSocketChannel? 如果有多个ServerSocketChannel的话，这些ServerSocketChannel如何做到监听同一个端口？连接到来时如何决定分配到哪一个ServerSocketChannel? 问题二：Acceptor组件是直接使用ServerSocketChannel.accept()方法来接受连接的，为什么不使用向Selector注册OP_ACCEPT事件的方式来接受连接？直接调用.accept()方法有什么考虑？ 问题三：Jetty中有多个ManagedSelector，这些ManagedSelector背后是共享同一个Selector吗？还是每个ManagedSelector有自己的Selector？如果是多个Selector有什么好处，注册IO事件时如何选择合适的Selector？

- Jetty 也是 Http 服务器 + Servlet 容器, 更小巧, 更易于定制 - Jetty 架构: 多个 Connector + 多个 Handler + 一个全局线程池(Connector 和 Handler 共享) - 多个 Connector 在不同端口监听请求, 可以根据应用场景选择 Handler : ServletHandler 和 SessionHandler - Jetty 用 Server 启动和协调上述组件 - Jetty 与 Tomcat 的区别 - Jetty 没有 Service 的概念, Jetty 的 Connector 被 Handler 共享 - Tomcat 连接器有自己的线程池, Jetty Connector 使用全局线程池 - Connector 组件, 完成 I/O 模型 + 协议封装 - 只支持 NIO 模型, 通过 Connection 组件封装协议 - Java NIO 核心组件为: Channel, Buffer, Selector - Channel 即一个 socket 连接 - Channel 通过 Buffer 间接读写数据 - Selector 检测 Channel 的 I/O 事件, 可以处理多个 Channel, 减少线程切换开销 - NIO 完成三个功能: 监听连接, I/O 事件查询, 数据读写, 对应的 Jetty 封装为 Acceptor, SelectorManager, Connection - Acceptor 接受请求 - Jetty 有独立 Acceptor 线程组处理连接请求 - Connector 的实现类 ServerConnector 中有 _acceptors 数组, 保存固定数目的 Acceptor. - Acceptor 是 Connector 内部类, 是 Runnable 的. 通过 getExecutor 得到线程以执行 - Acceptor 通过阻塞接受连接, 接受连接后, 调用 accepted, 其将 SocketChannel 设为非阻塞, 交给 Selector 处理 - SelectorManager 管理 Selector - 被管理的 Selector 叫 ManagedSelector, 保存于 SelectorManager 的一个数组中 - SelectorManager 选择一个 Selector, 并创建一个任务 Accept 给 ManagedSelector, ManagerSelector 实现: - 调用 register 将 Channel 注册到 Selector, 拿到 SelectionKey - 创建 EndPoint 和 Connection, 并与 SelectionKey(Channel) 绑定 - 当有 I/O 事件时, ManagedSelector 调用 EndPoint 返回一个 Runnable 对象, 并扔给线程池执行 - Connection - 上述 Runnable 对象会调用 Connection 处理请求, 得到 Request 并调用 Handler 容器处理 - 具体实现类 HttpConnection - 请求处理: 在 EndPoint 中注册一系列回调函数, 数据到达时调用. ( 用回调函数模拟异步 I/O ). 在回调方法中读数据, 解析请求并存到 Request - 相应处理: Handler 返回 Response, HttpConnection 通过 EndPoint 写到 Channel - 留言 - 每次请求跟一个 Hanlder 线程是一对一的关系, 下一次再来请求，会分配一个新的 Hanlder 线程。 - 多个 Acceptor 共享同一个 ServerSocketChannel 。多个 Acceptor 线程调用同一个 ServerSocketChannel 的 accept 方法，由操作系统保证线程安全

使用不同的线程是为了合理的使用全局线程池。 我有两个问题请教老师： 问题一：负责读写的socket与handle线程是什么对应关系呢？多对1，还是1对1？ 问题二：如果有很多tcp建立连接后迟迟没有写入数据导致连接请求堵塞，或者如果有很多handle在处理耗时io操作时， 同样可能拖慢整个线程池，进而影响到accepters和selectors，那么可能会拖慢整个线程池，jetty是如何考虑的呢？

源码都是怎么导入，怎么编译，怎么看呢

老师好!在线程模型设计上 Tomcat 的 NioEndpoint 跟 Jetty 的 Connector 是相似的，都是用一个 Acceptor 数组监听连接，用一个 Selector 数组侦测 I/O 事件。这句话怎么理解啊? 问题1:Acceptor 数组监听连接,监听的是一次TCP链接么? 问题2:Selector 数组侦测 I/O 事件，具体监听的是啥? 问题3:长链接下，每次http请求会新打开一个channel的，还是复用原有的channel，channel是阻塞还是非阻塞的。 说的有点乱不晓得老师看的懂不😂。我就是想知道，一次TCP链接，多次http具体是和connector怎么绑定的。

请问注册一堆回调函数的用意是什么？

说了各自的特点。但是感觉缺少关键性的对比，以及背后设计的理念，建议再深入探讨各自的主要差异及场景

老师好，跑在不同的线程里是为了解耦么?实在想不出，告诉答案吧

分在不同的线程里我认为是这样分工明确好比工厂流水线最大化提升处理能力。 我有个疑问是用全局线程池真的好吗，不是应该根据任务类型分配线程池的吗？用全局的不会互相干扰吗？

感觉jetty就是一个netty模型