（一）为什么需要Netty？

最新推荐文章于 2024-03-18 10:50:48 发布

太阳不落山

最新推荐文章于 2024-03-18 10:50:48 发布

阅读量7.3k

点赞数 2

文章标签： java 网络开发语言 Netty

本文链接：https://blog.csdn.net/u011082453/article/details/125133496

版权

Netty是一款用于高效开发网络应用的NIO网络框架，在深入剖析Netty之前，我将从最早熟悉的IO说起。

一次完整的IO交互流程分为两个阶段：

首先，经过内核空间由操作系统处理；
其次，回到用户空间交由应用程序处理。

具体的交互流程如下：

IO交互流程

当使用网络IO读取数据时，线程切换上下文进入内核空间，内核通过DMA机制读盘，此时线程挂起，等待内核数据准备就绪。

当数据准备就绪时，将数据写入内核缓冲区（内核会为每个IO设备维护一个缓冲区），此时线程唤醒，然后线程切换上下文回到用户空间，同时将内核缓冲区的数据拷贝至用户空间的缓冲区，这就是一次网络IO读操作的交互流程，写操作也是一样。

IO分为三种：内存IO、网络IO、磁盘IO。
通常所说的IO指的是后两者（因为内存的高性能足以忽略IO带来的性能影响）。

IO有五种模型：阻塞IO模型、非阻塞IO模型、多路复用IO模型、信号驱动IO模型、异步IO模型。

我们经常会听到同步、异步、阻塞、非阻塞这些概念，但是这些概念到底是什么意思呢？

什么是同步呢？

同步还是异步其实是指CPU时间片的利用，主要看请求发起方对响应结果的获取是主动发起的还是被动通知的。

举个例子：在JAVA中遇到Future接口，可以通过Future的get方法拿到响应结果，那么它是异步还是同步呢？
毫无疑问，它是同步的，也就是说如果想要拿到响应结果，还是需要请求发起方线程主动去调用get()方法，我们不会被动的接收到Future的结果。

什么是异步呢？

如果大家做过支付就会知道，调用第三方支付下支付单后，如果支付单创建成功，第三方支付会回调支付结果接口，告知我们支付状态，这个回调就是异步的。因为"支付状态"这个响应结果并不是支付发起线程主动获取的。

什么是阻塞和非阻塞呢？

简单说就是我们调用了一个方法后，在等待这个方法返回结果之前，当前的线程是处于挂起状态还是运行状态。
如果是挂起状态，就意味着当前线程什么都不能干直到获取到结果，这就是同步阻塞，如果当前线程仍然可以运行做其他的事情，但要时不时的去查看一下方法是否有结果返回了，这就是同步非阻塞。
我们最熟悉的BIO采用的是阻塞IO模型，BIO提供的所有接口都是同步阻塞式的接口。

面向流和面向块

BIO是一种面向流的机制，面向流就意味着每次从流中读取字节的时候，这些字节并没有"容器"去存储它们，需要马上处理这个字节，这就决定了它的"阻塞"。

这其实很好理解，如果想非阻塞式的处理一批数据，我们可以先把数据存储到一个容器里，此时可以先去处理其他的事情，当别的事情干完了，再回来处理这个容器中的数据，这样线程就没必要阻塞，如果没有这个容器我们就得马上处理，不然这些数据就会丢失了。

在Java 1.4之前的IO系统中，提供的都是面向流的IO系统，系统一次一个字节地处理数据，一个输入流产生一个字节的数据，一个输出流消费一个字节的数据，面向流的IO速度非常慢；而在Java 1.4中推出了NIO，这是一个面向块的IO系统，系统以块的方式处理数据，每一个操作在一步中都产生或者消费一个数据块，按块处理数据要比按字节处理数据快得多。

传统的BIO模型有严重的弊端，那就是【阻塞】、【耗费线程资源】。

为什么这么说呢，我们先看一段代码：

@Slf4j
public class BIOServer {
    public static void main(String[] args) throws IOException {
        ServerSocket socket = new ServerSocket(8800);
        while (true) {
            try{
                System.out.println("服务器启动，等待连接, 第一次阻塞");
                Socket clientSocket = socket.accept();
                System.out.println("客户端连接成功：" + clientSocket);
                InputStream inputStream = clientSocket.getInputStream();
                byte[] bytes = new byte[1024];
                int length;
                System.out.println("连接成功，准备读数据, 第二次阻塞");
                while ((length = inputStream.read(bytes)) != -1) {
                    System.out.println(new String(bytes, 0, length));
                }
                System.out.println("数据读取成功，继续等待下一个客户端连接");
            } catch (IOException e) {
                log.error(e.getMessage(),e);
            } finally {
                // 关闭input流代码省略
            }
        }
    }
}

@Slf4j
public class BIOClient {
    public static void main(String[] args) {
        Scanner scanner = new Scanner(System.in);
        try (
                //连接服务端
                Socket socket = new Socket("127.0.0.1", 8800);
                //获取socket输出流，用于发数据
                OutputStream outputStream = socket.getOutputStream();
                //获取socket输入流，用于接收数据
                InputStream inputStream = socket.getInputStream()
        ) {
            System.out.println("连接服务端成功。。。。。");
            while (true) {
                //发数据
                outputStream.write(scanner.nextLine().getBytes());
                System.out.println("发送数据成功。。。。");
                byte[] bytes = new byte[128];
                //接收数据
                while (true) {
                    int read = inputStream.read(bytes);
                    if (read == -1) break;
                    System.out.println("接收数据成功");
                    System.out.println(new String(bytes, 0, read));
                }
            }
        } catch (IOException e) {
            log.error(e.getMessage(),e);
        } finally {
        }
    }
}

先启动服务端，同时再启动两个客户端，服务端的控制台打印如下：

服务器启动，等待连接, 第一次阻塞
客户端连接成功：Socket[addr=/127.0.0.1,port=64946,localport=8800]
连接成功，准备读数据, 第二次阻塞

两个客户端的控制台打印如下：

连接服务端成功。。。。。

然后在其中一个客户端控制台输入"哈哈，我是客户端1"，客户端打印如下：

连接服务端成功。。。。。
哈哈，我是客户端1
发送数据成功。。。。

在另一个客户端控制台输入"哈哈，我是客户端2"，客户端2的控制台打印如下：

连接服务端成功。。。。。
哈哈，我是客户端2
发送数据成功。。。。

服务端打印如下：

服务器启动，等待连接, 第一次阻塞
客户端连接成功：Socket[addr=/127.0.0.1,port=51360,localport=8800]
连接成功，准备读数据, 第二次阻塞
哈哈，我是客户端1

通过实验发现，服务端一直"卡"在客户端1的连接上，并没有处理客户端2的连接请求和读写请求。

根本原因就是，服务端已经卡在上一个客户端连接的inputStream.read(bytes))这行代码上了。

这行代码正在监听客户端1的读写请求，也就是当前服务端的线程资源已经完全被客户端1连接所占用，以至于客户端2将无法使用服务端的线程资源。这就是BIO最根本的缺陷，一个线程资源只能处理一个连接。

对于服务端来说，有两个阻塞点：

socket.accept()
inputStream.read(bytes)

前者socket.accept()监听连接事件，也就是当客户端发起连接请求的时候，这行代码就会停止线程阻塞向下执行，直到遇到第二个阻塞点inputStream.read(bytes)停止。

你会发现服务端整个的执行过程中，主线程一直在为一个客户端连接服务，大家仔细想想是不是这样。

说到这里我相信你也许还是对【一个线程只能处理一个客户端连接这个事儿】有很多疑问，你会想我可以在服务端使用线程池啊？接下来我们再做个实验，代码如下：

@Slf4j
public class BIOThreadPoolServer {

    public static void main(String[] args) throws IOException {
        ExecutorService threadPool = Executors.newFixedThreadPool(2);
        ServerSocket socket = new ServerSocket(8800);
        while (true) {
            try {
                System.out.println("服务器启动，等待连接, 第一次阻塞");
                Socket clientSocket = socket.accept();
                System.out.println("客户端连接成功：" + clientSocket);
                threadPool.execute(() -> {                                            // 1
                    InputStream inputStream;
                    try {
                        inputStream = clientSocket.getInputStream();
                        byte[] bytes = new byte[1024];
                        int length;
                        System.out.println("连接成功，准备读数据, 第二次阻塞");
                        while ((length = inputStream.read(bytes)) != -1) {
                            System.out.println(new String(bytes, 0, length));
                        }
                        System.out.println("数据读取成功，继续等待下一个客户端连接");
                    } catch (IOException e) {
                        log.error(e.getMessage(), e);
                    }
                });
            } catch (IOException e) {
                log.error(e.getMessage(), e);
            } finally {
                // 关闭input流代码省略
            }
        }
    }
}

@Slf4j
public class BIOClient {
    public static void main(String[] args) {
        Scanner scanner = new Scanner(System.in);
        try (
                //连接服务端
                Socket socket = new Socket("127.0.0.1", 8800);
                //获取socket输出流，用于发数据
                OutputStream outputStream = socket.getOutputStream();
                //获取socket输入流，用于接收数据
                InputStream inputStream = socket.getInputStream()
        ) {
            System.out.println("连接服务端成功。。。。。");
            while (true) {
                //发数据
                outputStream.write(scanner.nextLine().getBytes());
                System.out.println("发送数据成功。。。。");
                byte[] bytes = new byte[128];
                //接收数据
                while (true) {
                    int read = inputStream.read(bytes);
                    if (read == -1) break;
                    System.out.println("接收数据成功");
                    System.out.println(new String(bytes, 0, read));
                }
            }
        } catch (IOException e) {
            log.error(e.getMessage(),e);
        } finally {
        }
    }
}

启动服务端后，再启动三个客户端，服务端控制台打印如下：

服务器启动，等待连接, 第一次阻塞
客户端连接成功：Socket[addr=/127.0.0.1,port=53604,localport=8800]
服务器启动，等待连接, 第一次阻塞
连接成功，准备读数据, 第二次阻塞
客户端连接成功：Socket[addr=/127.0.0.1,port=53647,localport=8800]
服务器启动，等待连接, 第一次阻塞
连接成功，准备读数据, 第二次阻塞
客户端连接成功：Socket[addr=/127.0.0.1,port=53719,localport=8800]
服务器启动，等待连接, 第一次阻塞

客户端1，2，3打印如下：

连接服务端成功。。。。。

我们在客户端1，2，3的控制台中输入"哈喽，我是客户端1；哈喽，我是客户端2；哈喽，我是客户端3"，这个时候我们看下服务端的打印如下：

服务器启动，等待连接, 第一次阻塞
客户端连接成功：Socket[addr=/127.0.0.1,port=53604,localport=8800]
服务器启动，等待连接, 第一次阻塞
连接成功，准备读数据, 第二次阻塞
客户端连接成功：Socket[addr=/127.0.0.1,port=53647,localport=8800]
服务器启动，等待连接, 第一次阻塞
连接成功，准备读数据, 第二次阻塞
客户端连接成功：Socket[addr=/127.0.0.1,port=53719,localport=8800]
服务器启动，等待连接, 第一次阻塞
哈喽，我是客户端1
哈喽，我是客户端2

此时，你会发现，“哈喽，我是客户端3” 没有打印出来，这是为什么呢？
我们看下线程池，它的【nThreads = 2】，可以简单理解为会启动两个线程去处理任务。

到这里，我们应该有所感受，就是采用线程池更像是一种"权宜之计"，不能解决根本问题。

虽然相比于上一个实验，采用线程池的服务端能处理两个连接了，但是这取决于线程池的配置。

线程池总有用完的时候，也就是当第三个客户端连接发起的时候，服务端又回到了第一个实验所面临的窘境，也就是【一个线程只能处理一个连接】的弊端并没有被突破。

综上所述，由于BIO有两个阻塞点：连接和读写。

基于这种阻塞的特性，导致在BIO模型中一个线程只能处理一个连接，连接与线程高度绑定，这就是BIO的弊端。

基于这个弊端，我们迫切的需要非阻塞的IO模型，这个时候NIO就出现了。

NIO是一种非阻塞型IO，由于BIO是因为阻塞的原因，所以导致它存在线程绑定连接的弊端；而NIO是非阻塞的，那么它能打破这个限制吗？

我们再做个实验，代码如下：

@Slf4j
public class NIOServer {

    public static final int PORT = 8800;

    public static void main(String[] args) throws IOException{
        ByteBuffer buffer = ByteBuffer.allocate(200);
        SocketChannel ch = null;
        ServerSocketChannel ssc = ServerSocketChannel.open();
        try {
            ssc.configureBlocking(false);
            ssc.socket().bind(new InetSocketAddress(PORT));
            System.out.println("服务器启动，等待连接");
            while(true) {
                ch = ssc.accept();
                if(ch != null){
                    System.out.println("客户端连接成功：" + ch.socket());
                    ch.configureBlocking(false);
                    int read = ch.read(buffer);
                    System.out.println("服务端准备读数据");

                    if(read > 0){
                        CharBuffer cb = CharsetUtil.UTF_8.decode((ByteBuffer)buffer.flip());
                        String response = cb.toString();
                        System.out.println("response : " + response);
                        ch.write((ByteBuffer)buffer.rewind());
                        buffer.clear();
                    }else{
                        System.out.println("=======通道没有数据");
                    }
                }else{
                    try {
                        Thread.sleep(800);
                    } catch (InterruptedException e) {
                        log.error(e.getMessage(),e);
                    }
                }
            }
        } finally {
            if(ch != null)
                ch.close();
            ssc.close();
        }
    }
}

public class NIOClient {
    static final int clPot = 8894;

    public static void main(String[] args) throws IOException {
        SocketChannel sc = SocketChannel.open();
        try {
            sc.configureBlocking(false);
            sc.socket().bind(new InetSocketAddress(clPot));
            ByteBuffer buffer = ByteBuffer.allocate(16);
            while (true) {
                if (!sc.isConnected()) {
                    InetAddress addr = InetAddress.getByName(null);
                    boolean success = sc.connect(new InetSocketAddress(addr, PORT));
                    if (!success)
                        sc.finishConnect();

                    if (sc.read((ByteBuffer) buffer.clear()) > 0) {
                        String response = CharsetUtil.UTF_8.decode((ByteBuffer) buffer.flip()).toString();
                        System.out.println(response);
                    }
                    //发数据
                    sc.write(ByteBuffer.wrap(new String("hello,NIO,我是客户端3").getBytes()));
                    System.out.println("发送数据成功。。。。");
                }
            }
        } finally {
            sc.close();
        }
    }
}

启动服务端后，同时启动三个客户端，服务端控制台打印如下：

服务器启动，等待连接
客户端连接成功：Socket[addr=/127.0.0.1,port=8892,localport=8800]
服务端准备读数据
response : hello,NIO,我是客户端1
客户端连接成功：Socket[addr=/127.0.0.1,port=8893,localport=8800]
服务端准备读数据
response : hello,NIO,我是客户端2
客户端连接成功：Socket[addr=/127.0.0.1,port=8894,localport=8800]
服务端准备读数据
response : hello,NIO,我是客户端3

此时会发现，这个时候如果继续启动客户端4，5，6等等，服务端都能继续处理。此时，此时服务端的一个主线程似乎具备了处理"大量连接"的能力，这是为什么呢？

因为ch = ssc.accept();和ch.read(buffer);不再阻塞后，那么一个线程就可以避免阻塞在上一个连接的ch.read(buffer);处，似乎NIO给我们带来了曙光，然而我们还是天真了，其实NIO虽然是非阻塞IO，但其实依然存在阻塞！

当用户线程执行到ch.read(buffer);处时，如果能读取到数据，那么就会和BIO一样，一样是阻塞至read()处，直到读取完数据，用户线程才会唤醒，这样就依然存在一个线程绑定一个连接的问题！（我们可以看下一篇的IO模型有详细解释原因）如果读不到数据，那么用户线程将会一直空轮询，非常浪费CPU资源。因此，我们发现，NIO不仅没有解决一个线程绑定一个连接的问题，而且又带来了新的问题。

基于这个弊端，我们迫切的需要一种模型可以合理的使用CPU资源同时一个线程可以处理多个连接，这个时候IO多路复用模型就出现了！

IO多路复用的核心组件：selector选择器。

它可以注册多个通道，监听这些通道的事件。这里的通道你暂时可以理解成客户端与服务端的连接，同时selector绑定一个处理线程，这个线程专门处理通道的连接事件和读写事件。

多路是指多个连接，复用是指多个连接可以复用一个或多个线程资源，也就是说一个线程可以处理多个连接的连接事件和读写事件。

我们再做个实验，代码如下：

@Slf4j
public class Server {
    public static final int PORT = 8801;
    public static void main(String[] args) throws IOException{

        ByteBuffer buffer = ByteBuffer.allocate(200);
        SocketChannel ch = null;//Socket对应的channel
        ServerSocketChannel ssc = ServerSocketChannel.open();
        //2.创建选择器Selector
        Selector sel = Selector.open();
        try {
            ssc.configureBlocking(false);
            ssc.socket().bind(new InetSocketAddress(PORT));
            ssc.register(sel, SelectionKey.OP_ACCEPT);
            System.out.println("服务器启动，等待连接, 第一次阻塞");
            while(true) {
                sel.select();
                Iterator<SelectionKey> it = sel.selectedKeys().iterator();
                while(it.hasNext()) {
                    SelectionKey sKey = it.next();
                    it.remove();//防止重复处理
                    if(sKey.isAcceptable()) {
                        ch = ssc.accept();
                        System.out.println("客户端连接成功：" + ch.socket());
                        ch.configureBlocking(false);
                        ch.register(sel, SelectionKey.OP_READ);
                    }else {
                        ch = (SocketChannel)sKey.channel();
                        int read = ch.read(buffer);
                        if(read > 0){
                            CharBuffer cb = CharsetUtil.UTF_8.decode((ByteBuffer)buffer.flip());
                            String response = cb.toString();
                            System.out.println("response : " + response);
                            //ch.write((ByteBuffer)buffer.rewind());
                            buffer.clear();
                        }
                    }
                }
            }
        } finally {
            if(ch != null)
                ch.close();
            ssc.close();
            sel.close();
        }
    }
}

public class Client {
    static final int clPot = 8896;
    public static void main(String[] args) throws IOException {
        //1.创建SocketChannel
        SocketChannel sc = SocketChannel.open();
        //2.创建Selector
        Selector sel = Selector.open();
        Scanner scanner = new Scanner(System.in);
        try {
            sc.configureBlocking(false);
            //3.关联SocketChannel和Socket，socket绑定到本机端口
            sc.socket().bind(new InetSocketAddress(clPot));
            //4.注册到Selector，感兴趣的事件为OP_CONNECT
            sc.register(sel, SelectionKey.OP_CONNECT | SelectionKey.OP_READ);
            InetAddress addr = InetAddress.getByName(null);
            //连接addr和port对应的服务器
            boolean success = sc.connect(new InetSocketAddress(addr, PORT));
            if(!success)
                sc.finishConnect();

            while(true) {
                sc.write(ByteBuffer.wrap(scanner.nextLine().getBytes()));
                System.out.println("发送数据成功。。。。");
            }
        } finally {
            sc.close();
            sel.close();
        }
    }
}

启动服务端，同时启动三个客户端，在客户端控制台分别输入"哈哈，我是客户端1；哈哈，我是客户端2；哈哈，我是客户端3"，观察服务端的控制台打印如下：

服务器启动，等待连接, 第一次阻塞
客户端连接成功：Socket[addr=/127.0.0.1,port=8898,localport=8801]
response : 哈哈，我是客户端1
客户端连接成功：Socket[addr=/127.0.0.1,port=8897,localport=8801]
response : 哈哈，我是客户端2
客户端连接成功：Socket[addr=/127.0.0.1,port=8896,localport=8801]
response : 哈哈，我是客户端3

当继续在客户端2控制台继续输入"哈哈，我再发一次客户端2"，观察服务端控制台打印如下：

服务器启动，等待连接, 第一次阻塞
客户端连接成功：Socket[addr=/127.0.0.1,port=8898,localport=8801]
response : 哈哈，我是客户端1
客户端连接成功：Socket[addr=/127.0.0.1,port=8897,localport=8801]
response : 哈哈，我是客户端2
客户端连接成功：Socket[addr=/127.0.0.1,port=8896,localport=8801]
response : 哈哈，我是客户端3
response : 哈哈，我再发一次客户端2

也就是说，当客户端不发送消息的时候服务端线程在sel.select();处阻塞。

通过使用IO多路复用模型（非阻塞IO模型+Selector组件），我们可以发现，服务端主线程可以处理大量的客户端连接，同时服务端又不需要做无效的轮询。

这似乎解决了前边实验遇到的所有问题，也就是我开篇提到的BIO模型存在【阻塞】、【耗费线程资源】的问题，黎明的曙光就要来临。

然而，不知道大家发现了没有，原生的NIO编程相比于传统的BIO编程真的很复杂，它虽然可以实现一个线程处理多个连接的问题，但是一个连接的连接事件、读写事件都由一个与selector绑定的线程处理，在高并发场景中依然会遇到瓶颈，比如上一个连接处理的慢了，势必就会影响下一个连接的处理，而且原生NIO也存在一些尚未完全解决的bug（如select空转问题）。

于是，一套性能优异、使用简单、极致的内存管理技术、开源社区强大、适用于高并发场景的网络编程框架就呼之欲出了，它就是大名鼎鼎的Netty。

点击此处查看原文，扫码发现更多好文~

在这里插入图片描述