死磕 NIO— ServerSocketChannel 的应用实例

Posted 2022-10-23 chenssy

大家好，我是大明哥，一个专注于【死磕 Java】的程序员。
【死磕 Java 】系列为作者「chenssy」 倾情打造的 Java 系列文章，深入分析 Java 相关技术核心原理及源码。
死磕 Java ：https://www.cmsblogs.com/group/1420041599311810560

上篇文章大明哥介绍了 SocketChannel 的核心原理及其源码，这篇文章就来介绍如何使用 ServerSocketChannel，分析单独使用 ServerSocketChannel 存在哪些问题。

阻塞模式

我们先看服务端方法：

    public static void main(String[] args) throws Exception 
        ByteBuffer buffer = ByteBuffer.allocate(100);
        ServerSocketChannel serverSocket = ServerSocketChannel.open()
        serverSocket.bind(new InetSocketAddress(8080));
        List<SocketChannel> channels = new ArrayList<>();
        while(true) 
            SocketChannel sc = serverSocket.accept();
            channels.add(sc);

            for (SocketChannel asc :channels) 
                asc.read(buffer);
                buffer.flip();
                ByteBufferUtil.debugAll(buffer);
                buffer.clear();
            
        
    

• 首先新建一个 ServerSocketChannel 类，同时绑定 8080 端口
• 然后 while(true)循环调用 accept()来建立连接，同时将该 SocketChannel 加入到 List 集合中，该集合用来装所有与服务端建立连接的 SocketChannel
• 最后接受客户端发送来的数据，打印出来

现在我们来运行下（这里就不写客户端程序了，就用 MAC 的 iTerm 来模拟即可）。需要开 2 个客户端。

我们先打开 client-01，然后发送一条 “hi,i am client-01”

服务器运行结果：

服务端准确无误打印出 client-01 发送过来的消息（hi,i am client-01）。这个时候你再发一条消息：“hi,i am client-11”，你会惊奇地发现，服务端竟然不输出客户端发来的消息。这个时候你再启动 client-02，神奇的事情发生了，服务端把 client-01 发送的消息（hi,i am client-11）给打印出来了：

为什么会出现这种神奇的现象？主要原因就是该 ServerSocketChannel 是阻塞模式，相关方法都会导致线程的阻塞，当 client-01 建立连接，第一次发送消息时，服务端正常打印消息（hi,i am client-01），这时服务端又运行到 accept()，注意这个方法是阻塞方法，如果没有客户端来建立连接，它会一直阻塞在这里，哪怕 client-01 再次发送消息（hi,i am client-11），服务端也不会打印。这时 client-02 与服务端建立连接，服务端就不会阻塞，打印 client-01 第二次发来的消息（hi,i am client-11）。

所以，阻塞模式存在如下缺陷

• 单线程情况下，阻塞方法都会导致线程暂停
  • ServerSocketChannel.accept() 会在没有连接建立时让线程暂停，即使有客户端向服务端发送消息，服务单也接收不到直到有新客户端连接服务端，不再阻塞在accept()方法上。
  • SocketChannel.read() 会在通道中没有数据可读时让线程暂停，即使之后有新客户端向服务端发起连接请求也接受不了，直到读取完毕，不再阻塞在read()方法上

所以在单线程情况，服务端几乎不可能正常工作。那多线程呢？多线程情况下，如果连接数过多，必然会导致 OOM，然后线程的上下文切换也会导致性能低下。

非阻塞模式

上面的阻塞模式几乎导致整个服务端是可能使用的，我们是可以使用非阻塞模式来避免的。如下

    public static void main(String[] args) throws Exception 
        ByteBuffer buffer = ByteBuffer.allocate(100);
        ServerSocketChannel serverSocket = ServerSocketChannel.open();

        serverSocket.bind(new InetSocketAddress(8080));
        List<SocketChannel> channels = new ArrayList<>();
        while(true) 
            // 非阻塞模式
            serverSocket.configureBlocking(false);

            SocketChannel sc = serverSocket.accept();
            if (sc != null)
              channels.add(sc);
            

            for (SocketChannel asc :channels) 
                asc.configureBlocking(false);

                int size = asc.read(buffer);
                if (size > 0) 
                    buffer.flip();
                    ByteBufferUtil.debugAll(buffer);
                    buffer.clear();
                
            
        
    

• 通过 ServerSocketChannel.configureBlocking(false) 将 serverSocket 设置为非阻塞模式，这样 serverSocket 在调用 accept()方法时就不会阻塞了，如果没有连接，则会返回 null
• 通过 SocketChannel..configureBlocking(false) 将 asc 设置为非阻塞模式，这 asc 在调用 read() 方法就不会阻塞了，如果没有可读数据，它则会返回 -1。

非阻塞模式虽然不会影响业务的使用，但由于在 while(true) 循环里面，CPU 会一直处理运行状态，占用和浪费 CPU 资源。

所以，采用这种 while(true) 循环的暴力方式根本就不适合业务使用，对于 SocketChannel 而言，我们希望他只担任一个通道，传传数据的角色即可，不需再有额外的角色了，故而我们不能放任他们，需要对其进行统一管理，既要有管理器，有连接来了，我就告诉你该建立连接了，有要读的数据，我就告诉你可以读数据了，这样 SocketChannel 是不是就很爽了。在 NIO 中，这个管理器称之为 Selector。