IO 线程池，主要调用Selector.start()处理对应事件的各种回调，原则上不能处理任何阻塞的任务，因为这样会导致其他连接无法处理。IO 线程池包括两种线程（在 XNIO 框架中，通过设置 WORKER_IO_THREADS 来设置这个线程池大小，默认是一个 CPU 一个 IO 线程）：
读线程：处理读事件的回调
写线程：处理写事件的回调
Worker 线程池，处理阻塞的任务，在 Web 服务器的设计中，一般将调用 servlet 任务放到这个线程池执行（在 XNIO 框架中，通过设置 WORKER_TASK_CORE_THREADS 来设置这个线程池大小）
XNIO ChannelListener：ChannelListener 是用来监听处理 Channel 事件的抽象，包括：channel readable, channel writable, channel opened, channel closed, channel bound, channel unbound
Undertow 是基于 XNIO 的 Web 服务容器。在 XNIO 的基础上，增加：
Undertow BufferPool: 如果每次需要 ByteBuffer 的时候都去申请，对于堆内存的 ByteBuffer 需要走 JVM 内存分配流程（TLAB -> 堆），对于直接内存则需要走系统调用，这样效率是很低下的。所以，一般都会引入内存池。在这里就是 BufferPool。目前，UnderTow 中只有一种 DefaultByteBufferPool，其他的实现目前没有用。这个 DefaultByteBufferPool 相对于 netty 的 ByteBufArena 来说，非常简单，类似于 JVM TLAB 的机制（可以参考我的另一系列：全网最硬核 JVM TLAB 分析），但是简化了很多。我们只需要配置 buffer size ，并开启使用直接内存即可。
Undertow Listener: 默认内置有 3 种 Listener ，分别是 HTTP/1.1、AJP 和 HTTP/2 分别对应的 Listener（HTTPS 通过对应的 HTTP Listner 开启 SSL 实现），负责所有请求的解析，将请求解析后包装成为 HttpServerExchange 并交给后续的 Handler 处理。
Undertow Handler: 通过 Handler 处理响应的业务，这样组成一个完整的 Web 服务器。
Undertow 的一些默认配置Undertow 的 Builder 设置了一些默认的参数，参考源码：
Undertow
private Builder() { ioThreads = Math.max(Runtime.getRuntime().availableProcessors(), 2); workerThreads = ioThreads * 8; long maxMemory = Runtime.getRuntime().maxMemory(); //smaller than 64mb of ram we use 512b buffers if (maxMemory < 64 * 1024 * 1024) { //use 512b buffers directBuffers = false; bufferSize = 512; } else if (maxMemory < 128 * 1024 * 1024) { //use 1k buffers directBuffers = true; bufferSize = 1024; } else { //use 16k buffers for best performance //as 16k is generally the max amount of data that can be sent in a single write() call directBuffers = true; bufferSize = 1024 * 16 - 20; //the 20 is to allow some space for protocol headers, see UNDERTOW-1209 } }ioThreads 大小为可用 CPU 数量 * 2，即 Undertow 的 XNIO 的读线程个数为可用 CPU 数量，写线程个数也为可用 CPU 数量。
workerThreads 大小为 ioThreads 数量 * 8.
如果内存大小小于 64 MB，则不使用直接内存，bufferSize 为 512 字节
如果内存大小大于 64 MB 小于 128 MB，则使用直接内存，bufferSize 为 1024 字节
如果内存大小大于 128 MB，则使用直接内存，bufferSize 为 16 KB 减去 20 字节，这 20 字节用于协议头。
Undertow Buffer Pool 配置DefaultByteBufferPool 构造器：
public DefaultByteBufferPool(boolean direct, int bufferSize, int maximumPoolSize, int threadLocalCacheSize, int leakDecetionPercent) { this.direct = direct; this.bufferSize = bufferSize; this.maximumPoolSize = maximumPoolSize; this.threadLocalCacheSize = threadLocalCacheSize; this.leakDectionPercent = leakDecetionPercent; if(direct) { arrayBackedPool = new DefaultByteBufferPool(false, bufferSize, maximumPoolSize, 0, leakDecetionPercent); } else { arrayBackedPool = this; } }其中：
direct：是否使用直接内存，我们需要设置为 true，来使用直接内存。
bufferSize：每次申请的 buffer 大小，我们主要要考虑这个大小
maximumPoolSize：buffer 池最大大小，一般不用修改
threadLocalCacheSize：线程本地 buffer 池大小，一般不用修改
leakDecetionPercent：内存泄漏检查百分比，目前没啥卵用
对于 bufferSize，最好和你系统的 TCP Socket Buffer 配置一样。在我们的容器中，我们将微服务实例的容器内的 TCP Socket Buffer 的读写 buffer 大小成一模一样的配置（因为微服务之间调用，发送的请求也是另一个微服务接受，所以调整所有微服务容器的读写 buffer 大小一致，来优化性能，默认是根据系统内存来自动计算出来的）。
查看 Linux 系统 TCP Socket Buffer 的大小：
/proc/sys/net/ipv4/tcp_rmem (对于读取)
/proc/sys/net/ipv4/tcp_wmem (对于写入)
在我们的容器中，分别是：
bash-4.2# cat /proc/sys/net/ipv4/tcp_rmem 4096 16384 4194304 bash-4.2# cat /proc/sys/net/ipv4/tcp_wmem 4096 16384 4194304从左到右三个值分别为：每个 TCP Socket 的读 Buffer 与写 Buffer 的大小的 最小值，默认值和最大值，单位是字节。