Jetty可以设置acceptors的线程数默认是1个。详细实现如下:

“~~”删除线包裹的地方就是启动所有的acceptors线程，以下是线程详细执行过程。

可以看到通过while循环监听所有建立的连接通道，然后在将通道submit到SelectorManager中。
Undertow就没有这方面的处理，通过向通道中注册Selector，使用ChannelListener API进行事件通知。在创建Channel时，就赋予I/O线程，用于执行所有的ChannelListener回调方法。

所以：无论设计架构如何可以看出两个服务器都是基于NIO实现的，而且都有通过selector来执行所有的I/O操作，通过IP的hash来将channel放入不同的work Tread或者selector Manager中，然后具体的处理工作线程池来完成。所以，我认为jetty的selectors数和undertow的IOThreads数都是用于selector或说是做I/O操作的线程数。不同的是jetty全局线程池。而对于两个服务器的承载能力以及读写效率，包括，lifeCycle过程管理等，决定了两个服务器性能的好坏。毕竟用于工作的县城所有的开销在于业务，所有个人觉得：I/O操作，管理与舰艇，决定了两个服务器的优劣。

Jetty和Undertow压测分析
准备工具：

siege用于压测
VisualVm用于监测
项目准备：
Jetty：acceptors=1，selectors=2, min and max threads=200

Undertow: work_threads=200,io_threads=2

压测梯度：
siege -c 50 -r 2000 -t 2 --log=/Users/maybo/joinit_200.log http://127.0.0.1:8080/test

siege -c 80 -r 2000 -t 2 --log=/Users/maybo/joinit_200.log http://127.0.0.1:8080/test

siege -c 100 -r 2000 -t 2 --log=/Users/maybo/joinit_200.log http://127.0.0.1:8080/test

测试结果：

从中可以看出在高负载下Undertow的吞吐量高于Jetty而且随着压力增大Jetty和Undertow成功率差距会拉大。而在负载不是太大情况下服务器处理能力差不多，jetty还略微高于Undertow。而tomcat的负载能力似乎和Undertow很接近。
对比三个服务器发现在Undertow在负载过重情况下比Jetty和Tocmat更加顽强，实践证明在负载继续加大情况下Undertow的成功率高于其它两者，但是在并发不是太大情况下三款服务器整体来看差别不大。此次测试网络传输数据量太小，所以没有通过不断加大数据传输量来观察负载情况，个人决定测试一款服务器的I/O情况，还要通过改变数据传输量来看看在大数据文本高负载下三款服务器的性能。

大数据量测试
使用1892byte回复数据测试三款服务器性能，下面是开启线程执行情况图。
Undertow:

  Jetty:

Tomcat:

实验过程发现Undertow和Tomcat的负载能力很接近但是Undertow比较好点，而Jetty远远不足。通过观察以上三张图不难发现，Undertow的I/O线程执行100% , Tomcat的执行也是100%两者不同的是Undertow用于I/O的线程数是可以调整的，而Tomcat不可以，起码通过spring boot 无法调整，这样就制约了它的负载能力。而Jetty由于全局共享线程池所以，会存在Selector和Acceptor阻塞情况，这样就制约了I/O操作。但是有个好处就是在负载不是太重的情况下可以使工作线程有更多占用资源来处理程序，提高了吞吐量。但是，总体而言这种差距是很小的。

结论：
  任何一个服务器都有其自己的优势。对于一个开发人员来说，选择一个什么样子的技术点能够帮助我们最有的解决问题才是目的。
————————————————
版权声明：本文为CSDN博主「hp碰碰」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/qq_39865635/article/details/90375762