从零手写多线程HTTP服务器：Socket与线程池实战解析

Socket、HTTP、多线程，这三个词几乎出现在每一份Java工程师的面试题里，但大部分人对它们的理解停留在背概念。平时用Spring Boot写接口，网络层全被Tomcat和框架包住了，一旦线上出现连接被重置、连接数暴涨、请求卡死这种问题，你会发现自己连排查入口都找不到。

这篇文章我不打算讲框架封装好的那套，而是从零开始，用纯Java实现一个多线程HTTP服务器。Socket负责建立连接，HTTP负责定义消息格式，多线程负责并发处理，三件事串起来，你就能真正理解"一个Web服务器到底是怎么工作的"。源码层面的东西我会贴完整实现，也会把我在实际调试中踩过的坑一并写出来。适合正在学Java网络编程或者准备面试的人，也适合在业务代码里被连接问题折磨过的同学。

1. 从"天天调接口"到"自己写服务器"：网络编程到底在学什么

1.1 你调用的每个REST接口，底层都是同样的四个动作

很多人以为HTTP接口和Socket是两套完全不相干的网络技术，这是个误解。用HttpClient、RestTemplate、OkHttp发的每一个HTTP请求，底层都是先创建一个Socket，再往Socket的输出流里写HTTP请求文本，最后从输入流里读HTTP响应文本。框架只是把这些动作封装成了好用的API，让你看不到字节流的搬运过程。

Socket的本质是操作系统提供的一个网络通信端点，由IP地址和端口号唯一标识。一次TCP连接由四元组确定：源IP、源端口、目标IP、目标端口。服务端要做的事情很固定：创建一个ServerSocket绑定端口，然后循环等待客户端连接进来，每个连接拿到一个Socket，从里面读数据、写数据，最后关闭。这四个动作对应操作系统层面的bind、listen、accept、connect，Java把这几个系统调用封装成了ServerSocket和Socket两个类。

不理解这一层，你就很难解释一些线上现象：为什么端口被占用起不了服务？为什么连接数突然到了几万？为什么客户端明明断开服务端还显示ESTABLISHED？这些问题全都在Socket层，框架不会帮你回答。

1.2 一个手写HTTP服务器的学习价值在哪里

Tomcat、Jetty、Netty这些成熟产品把网络编程的复杂度全部接管了，日常工作确实不需要重复造轮子。但学习阶段自己写一个，价值非常大。

一是能把协议从"看起来是字符串"变成"可解析的数据结构"。HTTP请求本质就是一段有固定格式的文本，手写解析器能让你彻底看清请求行、请求头、请求体的边界在哪里。

二是能把并发模型从"大概知道"变成"亲手验证"。单线程为什么慢、多线程为什么有线程安全问题、线程池参数怎么定，这些只有跑起来才能形成直觉。

三是面试的时候能讲出实质内容。面试官问Tomcat为什么能同时处理那么多请求，你如果能从ServerSocket accept后丢给线程池处理这个角度回答，比背"Tomcat使用线程池处理请求"有说服力得多。

后面几节我会按照这个路线走：先写一个只能收发字节的Socket服务器，再给它加上HTTP解析能力，最后用线程池改造并发模型。

2. Socket到底在做什么：从ServerSocket到TCP连接建立

2.1 三次握手藏在哪一行代码里

先看最基础的服务端代码，这是所有Socket服务器的起点。

java复制public class SingleThreadServer {
    public static void main(String[] args) throws IOException {
        // 第二个参数是backlog，表示操作系统层面允许排队的连接数量
        ServerSocket serverSocket = new ServerSocket(8080, 128);
        System.out.println("server listening on port 8080");

        while (true) {
            Socket clientSocket = serverSocket.accept();
            System.out.println("client connected: " + clientSocket.getRemoteSocketAddress());

            InputStream in = clientSocket.getInputStream();
            OutputStream out = clientSocket.getOutputStream();

            byte[] buffer = new byte[1024];
            int read = in.read(buffer);
            if (read > 0) {
                String message = new String(buffer, 0, read, StandardCharsets.UTF_8);
                System.out.println("received: " + message);
                out.write(("echo: " + message).getBytes(StandardCharsets.UTF_8));
                out.flush();
            }
            clientSocket.close();
        }
    }
}

很多初学者以为三次握手发生在accept()这一行，这是个常见的误解。实际上，客户端调用new Socket(host, port)的那一刻，操作系统内核就开始进行三次握手了。SYN、SYN-ACK、ACK这三个包的交换完全在内核协议栈里完成，Java代码感知不到。

accept()做的事是：从内核维护的已完成连接队列里取一个连接出来，返回一个Socket对象。如果队列为空，accept()就会阻塞，直到有新的连接完成握手。这个队列的大小就是ServerSocket构造函数的backlog参数，默认值是50。队列满了之后，内核会直接把新的SYN丢弃或者回复RST，客户端表现就是"连接超时"或者"Connection refused"。

这在排查问题的时候很有用。如果你发现服务端accept()逻辑很慢或者被卡住，客户端连接就会在队列里堆积，超过backlog之后新连接连不进来，但已经建立的连接不受影响。很多人遇到"部分客户端连不上"的情况，第一反应是看防火墙，其实先看一眼accept循环是否健康更靠谱。

2.2 InputStream和OutputStream：TCP是字节流，不是消息流

拿到了Socket之后，通信就变成了两个方向的字节流。Socket.getInputStream()用来读对端发来的数据，Socket.getOutputStream()用来向对端写数据。听起来很简单，但这里藏着一个网络编程最核心的概念：TCP是流协议，没有消息边界。

什么意思？你把一个字符串"hello"通过write()写出去，对端read()不一定会一次性拿到完整的5个字节，可能拿到3个字节，剩下的2个字节在下一个read()里。反过来，如果你连续写了两次，对端一次read()也可能把两批数据全部读完。TCP只保证字节的顺序，不保证字节的分组。

这就意味着，应用层协议必须自己定义"一条消息从哪里开始、到哪里结束"。HTTP的做法是用空行分割请求头和请求体，再用Content-Length字段告诉对端请求体有多少字节。自定义二进制协议通常会在包头放一个固定长度的字段记录报文长度。没有这个边界定义，双方就会因为"读多读少"而解析错乱，这就是后面要讲的粘包问题的根源。

理解了"TCP是字节流"这个本质，你再看网上那些"解决粘包"的代码，思路就会非常清晰：不是TCP本身需要解决什么，而是应用层必须按协议边界去切分数据。

3. 手写HTTP协议解析：请求的每一个字节都是什么意思

3.1 把一次浏览器请求"打印"出来看看

HTTP协议是文本协议，把字节翻译成字符看，就是几行有固定格式的文本。一个最简单的GET请求长这样：

code复制GET /index.html HTTP/1.1\r\n
Host: localhost:8080\r\n
User-Agent: Mozilla/5.0\r\n
Accept: */*\r\n
\r\n

第一行叫请求行，由方法、URI、协议版本三部分组成，用空格分隔，最后以\r\n结束。中间若干行叫请求头，每一行是"键: 值"格式，同样以\r\n结束。请求头之后有一个空行，也就是\r\n\r\n，表示请求头结束。如果还有请求体（比如POST提交的表单），空行后面就是请求体字节。

POST请求多了一个请求体，但请求体不一定是文本，可能是文件二进制数据，所以解析的时候绝对不能按字符串处理。正确做法是：先按字节读到\r\n\r\n，解析出请求头，再从请求头的Content-Length字段拿到请求体长度，然后精确读这么多字节。

这里有个小知识点：为什么行结束符是\r\n而不是\n？因为HTTP协议最早的实现是在Unix和Windows之间通信，CRLF是当时各种系统的最大公约数。后来JSON、HTTP/2这些新协议用\n简化，但HTTP/1.1依然保持CRLF，你自己写协议解析器的时候千万别用错。

3.2 服务端如何用纯Java逐字节读取请求头

解析HTTP请求头的核心，是把输入流读到连续出现\r\n\r\n为止。我下面这个实现是逐字节读取并滚动匹配末尾四字节，逻辑清晰，也不容易读超。

java复制public class HttpRequestParser {

    public static String readHead(InputStream in) throws IOException {
        ByteArrayOutputStream buffer = new ByteArrayOutputStream();
        byte[] tail = new byte[4];
        int pos = 0;
        boolean found = false;

        while (!found) {
            int b = in.read();
            if (b == -1) {
                throw new IOException("stream closed before HTTP head end");
            }
            buffer.write(b);

            if (pos < 4) {
                tail[pos] = (byte) b;
            } else {
                System.arraycopy(tail, 1, tail, 0, 3);
                tail[3] = (byte) b;
            }
            pos++;

            if (pos >= 4
                    && tail[0] == '\r' && tail[1] == '\n'
                    && tail[2] == '\r' && tail[3] == '\n') {
                found = true;
            }
        }
        return buffer.toString(StandardCharsets.ISO_8859_1);
    }

    public static Map<String, String> parseHead(String head) {
        String[] lines = head.split("\r\n");
        Map<String, String> headers = new HashMap<>();
        // 第一行是请求行，从第二行开始是请求头
        for (int i = 1; i < lines.length; i++) {
            int idx = lines[i].indexOf(':');
            if (idx > 0) {
                String key = lines[i].substring(0, idx).trim();
                String value = lines[i].substring(idx + 1).trim();
                headers.put(key.toLowerCase(), value);
            }
        }
        return headers;
    }

    public static String readLine(InputStream in) throws IOException {
        // 单独实现一个按\r\n切分的读行方法
        ByteArrayOutputStream buffer = new ByteArrayOutputStream();
        int prev = -1;
        while (true) {
            int b = in.read();
            if (b == -1) {
                break;
            }
            if (prev == '\r' && b == '\n') {
                byte[] data = buffer.toByteArray();
                return new String(data, 0, data.length - 1, StandardCharsets.UTF_8);
            }
            buffer.write(b);
            prev = b;
        }
        if (buffer.size() == 0) {
            return null;
        }
        byte[] data = buffer.toByteArray();
        return new String(data, 0, data.length, StandardCharsets.UTF_8);
    }
}

写这块的时候有一个特别值得注意的坑：解析请求头阶段，千万不要把Socket的InputStream包装成BufferedReader再调用readLine()。为什么？因为BufferedReader内部有缓冲区，一次readLine()可能从底层一次性读入好几KB数据，多读的部分会留在BufferedReader自己的缓冲区里。等你解析完请求头，再想从原来的InputStream读取请求体，那些被BufferedReader吞掉的字节就再也拿不到了。这个Bug非常隐蔽，表现出来就是"请求体丢字节"或者"解析出来的内容莫名其妙地错位"。

所以我坚持用InputStream逐字节读。HTTP请求头通常只有几百字节到几KB，逐字节读的性能损失可以忽略，但正确性有保证。

3.3 有了Content-Length，才能知道响应在哪里结束

请求解析完，接下来就是拼响应。服务端响应的格式和请求类似：状态行、响应头、空行、响应体。我最初写响应的时候犯过一个错误：响应用完就把Socket关掉，不写Content-Length，浏览器居然也能正常显示。原因在于，连接关闭本身就是一个"消息结束"的信号。

但一旦开启keep-alive，也就是连接复用、一个TCP连接上连续处理多个请求，就必须用Content-Length告诉客户端"当前这个响应体就这么多字节"。否则客户端不知道哪里算完，会一直等下去直到超时。

java复制public static void writeResponse(OutputStream out, String status, String contentType,
                                 byte[] body) throws IOException {
    StringBuilder head = new StringBuilder();
    head.append("HTTP/1.1 ").append(status).append("\r\n");
    head.append("Content-Type: ").append(contentType).append("\r\n");
    head.append("Content-Length: ").append(body.length).append("\r\n");
    head.append("Connection: keep-alive\r\n");
    head.append("\r\n");

    out.write(head.toString().getBytes(StandardCharsets.ISO_8859_1));
    out.write(body);
    out.flush();
}

Content-Length的单位是字节数，不是字符数。用UTF-8编码的中文，一个汉字占3个字节，千万别直接拿字符串的length()去填，必须用getBytes(StandardCharsets.UTF_8)之后的数组长度。这个坑在返回中文页面时必踩，服务端自己填错了长度，客户端就会把下一个响应的一部分内容拼到当前响应里，页面显示会非常诡异。

4. 多线程设计：从请求排队到线程池

4.1 单线程服务器的问题：一个慢请求卡住所有人

把前面两节的代码合在一起，一个单线程HTTP服务器就能跑起来了：accept一个连接，处理完，关闭，再accept下一个。在小流量下它完全够用，但只要你模拟一个慢请求，立刻露出原形。

我在handle逻辑里加了一行Thread.sleep(5000)模拟慢接口，然后开两个浏览器窗口同时发起请求。第二个请求会整整等5秒才返回。为什么会这样？因为处理完第一个请求之前，主线程根本没有回到accept()那一行，后续连接只能在内核队列里排队等。

单线程模型的核心瓶颈在于：CPU在等待I/O的时候，线程被白白挂起。网络请求的大部分时间都花在网络传输上，真正的计算量可能只有几毫秒，一个线程被一个慢请求占住，所有人跟着遭殃。这个道理想通了，多线程服务器改造就是必然选择。

4.2 每个连接一个线程：能跑，但撑不住

最朴素的多线程改造是"每个连接new一个Thread"。accept()拿到Socket之后，直接丢给一个子线程去处理，主线程立刻回到accept()继续接下一个连接。

java复制while (true) {
    Socket clientSocket = serverSocket.accept();
    new Thread(() -> handle(clientSocket)).start();
}

这种"一连接一线程"模型在连接数几十上百的时候没问题，一旦连接数上千，灾难就来了。

第一是线程本身的成本。Java线程默认栈大小是1MB（虚拟内存），1000个线程就是1GB虚拟内存的消耗。线程的创建和销毁涉及系统调用，频繁创建销毁的开销也非常可观。

第二是上下文切换。线程数超过CPU核心数之后，操作系统要不断切换线程，每次切换都要保存和恢复寄存器、程序计数器等状态。1000个线程大部分时间阻塞在read()上，但一旦数据到达，调度器就要忙着切换，吞吐量不升反降。

第三是失控。如果客户端恶意建立大量连接但不发数据，每个连接占一个线程，线程数无限增长，最终直接OutOfMemory。线上服务被搞挂往往就是这种原因。

4.3 线程池的正确打开方式：参数含义和设置思路

线程池的本质是"用有限数量的线程复用处理大量任务"。改造成ThreadPoolExecutor之后，效果立竿见影。

java复制public class ThreadPoolHttpServer {
    private final ServerSocket serverSocket;
    private final ExecutorService pool;

    public ThreadPoolHttpServer(int port) throws IOException {
        serverSocket = new ServerSocket(port, 128);
        pool = new ThreadPoolExecutor(
                4,                          // 核心线程数
                16,                         // 最大线程数
                60L, TimeUnit.SECONDS,      // 空闲线程存活时间
                new ArrayBlockingQueue<>(200), // 有界任务队列
                new ThreadPoolExecutor.CallerRunsPolicy() // 拒绝策略
        );
    }

    public void start() {
        System.out.println("server started");
        while (!serverSocket.isClosed()) {
            try {
                Socket socket = serverSocket.accept();
                pool.execute(() -> handle(socket));
            } catch (IOException e) {
                if (!serverSocket.isClosed()) {
                    e.printStackTrace();
                }
            }
        }
    }

    private void handle(Socket socket) {
        try (Socket s = socket;
             InputStream in = s.getInputStream();
             OutputStream out = s.getOutputStream()) {
            // 解析请求头
            String head = HttpRequestParser.readHead(in);
            Map<String, String> headers = HttpRequestParser.parseHead(head);
            // 读取请求体
            int contentLength = Integer.parseInt(headers.getOrDefault("content-length", "0"));
            byte[] body = new byte[contentLength];
            int read = 0;
            while (read < contentLength) {
                int r = in.read(body, read, contentLength - read);
                if (r == -1) break;
                read += r;
            }
            // 拼响应
            byte[] responseBody = "<html><body><h1>Hello Netty-less Server</h1></body></html>"
                    .getBytes(StandardCharsets.UTF_8);
            writeResponse(out, "200 OK", "text/html; charset=utf-8", responseBody);
        } catch (IOException e) {
            System.err.println("handle connection failed: " + e.getMessage());
        }
    }
}

线程池的参数不是随便填的，理解执行顺序比记住参数值更重要。ThreadPoolExecutor处理新任务的流程是：先看核心线程是否都在忙，如果有空闲就用核心线程；核心线程满了，新任务进队列排队；队列满了，再尝试创建新线程直到最大线程数；如果达到最大线程数且队列也满了，触发拒绝策略。

这里很多人会有一个误区：以为核心线程、队列、最大线程是"三层资源池"。实际上它们是按优先级递进的关系，核心线程是最先使用的，队列是缓冲，最大线程是最后的手段。

线程数怎么定？有个经验公式是N = CPU核数 * (1 + 等待时间/计算时间)。如果是CPU密集型任务，直接把线程数设为核数加一；如果是I/O密集型任务，等待时间占比高，线程数可以多一些。对于HTTP服务器这种典型的I/O密集型场景，核心线程数设4到8通常够用，最大线程数16到32已经比较激进。别盲目把maxPoolSize设成几百几千，线程多了上下文切换会把性能拉回去。

拒绝策略我选了CallerRunsPolicy，核心思路是"不让任务丢弃，而是让提交任务的线程自己执行"。对服务器来说，accept()主线程被占住去处理任务，新的连接就暂时进不了accept，相当于给客户端一个自然的背压，比直接抛RejectedExecutionException要平稳得多。

4.4 共享状态和线程安全：一个计数器都能翻车

多线程改造完之后，如果你在处理逻辑里加了共享状态，比如统计请求次数的计数器，你会亲眼看到并发问题。最简单的int count++，在并发下结果会小于实际请求数。

原因不复杂：count++在字节码层面是"读取、加1、写回"三步，两个线程同时读到同一个值，各自加1再写回，就丢了一次更新。对需要简单计数的场景，用AtomicInteger：

java复制private final AtomicInteger requestCount = new AtomicInteger(0);

// 处理请求时
int current = requestCount.incrementAndGet();

另外一个高频翻车点是日期格式化。SimpleDateFormat有内部状态，不是线程安全的，多个线程同时调用format()会得到错乱的结果甚至抛异常。正确做法是用ThreadLocal包一层，或者直接改用java.time包下的DateTimeFormatter，后者是线程安全的。

线程安全问题有很强的复现不确定性，很多Bug在测试环境永远不出现，一上线就在高并发下暴雷。最稳妥的思路是：能无状态就无状态，必须共享状态的，优先用原子类或者不可变对象，真要用锁也别图省事一把大锁锁住整个处理方法。

5. 调试实录：粘包、半关闭和连接泄漏是怎么一步步定位的

5.1 客户端一次write两个请求，服务端到底收到了什么

TCP粘包问题，我在刚把HTTP服务器跑起来的时候就遇上了。当时我用一个测试客户端连续往服务端发送两个HTTP请求，一次write全部写出去。服务端的解析结果完全错乱，第二个请求的头几行被拼在第一个请求的尾部。

复现场景很简单：

java复制Socket socket = new Socket("localhost", 8080);
OutputStream out = socket.getOutputStream();
String request = "GET / HTTP/1.1\r\nHost: localhost\r\n\r\n";
byte[] data = request.getBytes(StandardCharsets.ISO_8859_1);
out.write(data);
out.write(data); // 两个请求一次发出

服务端如果用的是"一次性read到缓冲区再解析"的写法，肯定翻车。因为read()可能把两个请求的字节一次全部读进来，而你的解析逻辑是按"一个请求一段"写的。

但如果你严格按照第3节的逐字节解析法，在第一个\r\n\r\n处就停下，第二个请求的字节会继续留在输入流里，等第一个请求处理完、循环回来时，正好把它作为下一个请求解析。这其实就是keep-alive连接上连续处理多个请求的正确方式。所以粘包问题的根本解法是：按协议边界切分，而不是按read()次数切分。

提示：自定义协议时，要么像HTTP这样用\r\n\r\n做头尾分隔，要么在固定位置放长度字段。固定长度消息最简单，但扩展性差；长度字段+变长体是最常用的二进制协议结构。

5.2 响应完立刻close，为什么客户端会报connection reset

有一次我写了一个文件下载接口，服务端发完响应就直接close。客户端下载大文件时偶发报"Connection reset by peer"，我一开始以为是网络问题，后来抓包才明白。

问题出在TCP关闭的两种方式上。close()会把两个方向的通道全关掉；如果此时服务端的接收缓冲区里还有客户端发来但没读的数据，TCP栈会认为"连接异常终止"，直接发RST而不是FIN。客户端收到RST之后，再想读取服务端响应就会看到Connection reset。

这解释了为什么总是"偶发"：只有客户端发来的数据字节还滞留在服务端接收缓冲区时，close()才会触发RST。高频发送的大请求最容易踩中。

正确的处理顺序是：先完整读完请求（包括请求体），再写响应，最后才close。如果协议允许客户端以EOF作为请求结束标志，客户端发送完请求体后调用shutdownOutput()，也就是半关闭，告诉服务端"我这边数据发完了"。服务端read()返回-1就知道请求结束，处理完写响应，然后close。这个过程中，shutdownOutput()只关发送方向，接收方向依然开着，服务端依然能把响应正常传回去。

java复制// 客户端：发送完请求体后，通知对端数据结束
socket.shutdownOutput();

// 服务端：read()返回-1即表示对端已关闭发送方向
int b;
while ((b = in.read()) != -1) {
    // 处理请求数据
}
// 此时可以安全地写响应
writeResponse(out, "200 OK", "text/plain", "done".getBytes(StandardCharsets.UTF_8));
socket.close();

理解了半关闭，再看很多网络库的"优雅关闭"选项，就明白它们到底在做什么了。

5.3 连接数只增不减：一次线上排查的完整链路

还有一次我负责的服务跑了两周之后突然大量请求超时。上去看系统状态，进程还活着，CPU不高，但在客户端看到的却是连接建立不了。用netstat看了下端口状态，几千个ESTABLISHED连接挂在那里，服务端线程全部卡在read()上。

排查思路是这样的。第一步，确认连接卡在哪：netstat -anp | grep 8080 | head。看到大量ESTABLISHED连接，说明TCP连接本身是正常的，问题在服务端应用没有及时处理。

第二步，看服务端线程状态。用jstack把线程栈打出来，发现大量业务线程阻塞在java.net.SocketInputStream.socketRead0这个原生方法上，等数据超时。这说明有连接建立了，但客户端不发数据也不断开——典型的连接泄漏，要么是客户端没释放，要么是服务端没处理好。

第三步，追根因。最后定位到是服务端代码里有一处异常分支没有关闭Socket：

java复制private void handle(Socket socket) {
    try {
        String head = HttpRequestParser.readHead(socket.getInputStream());
        // 业务处理抛了异常，直接跳出
        handleBusiness(head);
        // 这里本来应该写响应然后close
    } catch (Exception e) {
        // 异常被捕获，但socket没关
        System.err.println(e.getMessage());
    }
}

这一段代码的问题在于，业务异常时Socket没有被关闭，输入流的连接还挂着，客户端以为连接还在，于是把它放回连接池复用，结果连接池里全是"僵尸连接"，慢慢把服务端的线程和文件描述符都耗尽了。

修复方式很简单，用try-with-resources保证任何情况下Socket都关闭：

java复制try (Socket s = socket;
     InputStream in = s.getInputStream();
     OutputStream out = s.getOutputStream()) {
    // 正常的读写逻辑
}

这个案例给到我的经验是：在网络编程里，资源释放必须做在finally或者try-with-resources里，漏掉任何一个异常分支都会变成日后的线上事故。很多时候不是代码跑错了，而是"没跑的那一半代码"出了问题。

6. 从BIO到NIO再到Netty：什么时候不该自己造轮子

6.1 自己写Socket的适用场景到底有哪些

手写Socket服务器能让你学到很多，但生产环境要不要自己写，得看场景。

需要自己写Socket的典型场景包括：私有协议通信，比如物联网设备上报数据、游戏服务器帧同步、文件传输工具，这些场景没有现成的HTTP语义可以套，必须自定义报文格式和解析逻辑；还有对性能要求和资源占用极其敏感的场景，需要精确控制每个连接的处理方式。

普通Web API则完全没必要自己写Socket。Spring Boot内嵌的Tomcat已经把HTTP解析、keep-alive、并发控制、安全过滤全部处理好了，你只需要写业务逻辑。自己写HTTP服务器去处理业务接口，等于重新发明一遍轮子，而且大概率没有Tomcat考虑得周全。

我在实战中的原则是：协议层如果有标准可用，就用标准；没有标准才自己定义。定义协议时反复问自己，这个自定义值不值得后续的维护成本。

6.2 BIO的瓶颈到底在哪，NIO解决的是什么

前面实现的多线程服务器，属于BIO模型，Blocking I/O。每个线程处理一个连接，线程在read()的时候被阻塞，等待数据到来。这种模型最大的问题是：线程数和连接数强绑定，连接数上来，线程数跟着上来，最终被资源拖垮。

NIO（Non-blocking I/O）的思路完全不同。一个线程通过Selector同时监管成千上万个Channel，只有当某个Channel有数据可读或可写时，线程才去处理它，其余时间线程空闲复用。连接数和线程数解耦，一个线程就能扛住大量连接。

Netty就是把NIO的复杂性封装好的框架。对大部分工程师来说，业务代码里直接用Netty是更务实的选择，但直接用和学习原理是两回事。如果你没经历过BIO模型的瓶颈，你是理解不了Netty的EventLoop为什么是那个设计——它本质上就是在解决"一个线程怎么高效地服务大量连接"这个问题。

我自己学的时候顺序是这样的：先写BIO服务器，制造出并发瓶颈；再看NIO的Selector模型，搞清楚为什么能省线程；最后用Netty重写一遍，这时候Netty的Channel、EventLoop、ByteBuf这些概念才真正落地。

6.3 面试和实战里能直接用的几个结论

最后整理几个我在工作和面试里反复用到的结论，都是前面内容的浓缩。

Tomcat默认已经不是传统的BIO模型了，现代版本默认使用NIO，但理解BIO仍然是理解Tomcat线程模型的第一步。连接和请求是两个概念，连接上可以复用多次请求，这也是为什么HTTP keep-alive和Content-Length如此重要。

线程池不是越大越好。我在4.3节给过公式，实际项目里还要结合业务的下游耗时做压测。你可以在几百并发下测出最优线程数，但别在压测前拍脑袋设一个上万的值。

线上排查连接异常，不要一上来怀疑框架。先看TCP层：连接建立没有、状态是什么、数据有没有到。很多"框架问题"，用netstat和jstack一查，根因都在自己写的代码里。

我自己至今保留的一个习惯是，每接手一个新服务，先看它的网络通信层是怎么管理连接和线程的。这个习惯帮我避过很多"看起来是业务问题，实际是连接泄漏"的坑。网络编程真正难的不是API怎么调用，而是出了问题的时候，你能不能在正确的层级找到正确的线索。