BIO、NIO及多路复用

BIO通讯模式模拟

/***
 * BIO通讯模式模拟
 */
public class BIOSocket{

    static byte[] bs = new byte[1024];
    static ArrayList<Socket> socketList = null;

    public static void main(String[] args) throws IOException {
        ServerSocket serverSocket = new ServerSocket(6379);
        while (true){
            //同步阻塞
            Socket clientSocket = serverSocket.accept();

            new Thread(()->{
                try {
                    //同步阻塞
                    clientSocket.getInputStream().read(bs);
                } catch (IOException e) {
                    e.printStackTrace();
                }
            }).start();
        }
    }
}

BIO的缺点在于对资源的浪费，因为Socket clientSocket = serverSocket.accept();是阻塞的，所以会一直等待clientSocket的连接，将死循环卡在这里。
有clientSocket连接后，BIO的做法是开辟一个子线程Thread，让子线程来完成接下来的行为，不过因为clientSocket.getInputStream().read(bs);也是同步阻塞的，所以就导致了资源浪费。
具体举例：
有1w个clientSocket连接，但是只有1000个有数据在传输，那么空闲的9000个就是浪费的资源。

NIO通讯模式模拟

/***
 * NIO通讯模式简单模拟
 */
public class NIOSocket {

    static byte[] bs = new byte[1024];
    static ArrayList<Socket> socketList = null;

    public static void main(String[] args) throws IOException {
        ServerSocket serverSocket = new ServerSocket(6379);
        serverSocket.setBlocking(false);//利用方法去阻塞
        while (true){
            for (Socket socket:socketList){
                int read = socket.getInputStream().read(bs);
                if (read > 0){
                    System.out.println(new String(bs));
                }

                Socket clientSocket = serverSocket.accept();
                if (clientSocket != null){
                    clientSocket.setBlocking(false);//利用方法去阻塞
                    socketList.add(clientSocket);
                }
            }
        }
    }
}

/***
 * NIO通讯模式
 */
public class NIOSocket {

    static ByteBuffer byteBuffer = ByteBuffer.allocate(512);
    static ArrayList<SocketChannel> socketList = new ArrayList<>();

    public static void main(String[] args) throws IOException {
        ServerSocketChannel serverSocket = ServerSocketChannel.open();
        SocketAddress socketAddress = new InetSocketAddress("127.0.0.1",6379);
        serverSocket.bind(socketAddress);
        //去阻塞
        serverSocket.configureBlocking(false);
        while (true){
            for (SocketChannel socketChannel:socketList){
                int read = socketChannel.read(byteBuffer);
                if (read > 0){
                    byteBuffer.flip();
                    byte[] bytes = new byte[read];
                    byteBuffer.get(bytes);
                    String content = new String(bytes);
                    System.out.println(content);
                    byteBuffer.flip();
                }

                SocketChannel clientSocket = serverSocket.accept();
                if (clientSocket != null){
                    //去阻塞
                    clientSocket.configureBlocking(false);
                    socketList.add(clientSocket);
                }
            }
        }
    }
}

上面是简单修改，不过路子是通的 大概那个意思，下面的是用sun提供的ServerSocketChannel给出的解决方案。
在NIO模式下 仅仅看代码可以发现 解决了Thread空闲的问题，但是依然会有性能损耗，因为for的遍历同样会遍历没有数据的Socket，导致时间复杂度过大。

Redis多路复用，Epoll还是Select？

简单科普：Java程序访问Redis数据库需要经过系统内核，系统内核有3种实现Redis多路复用的方法，分别为：Select、Poll、Epoll
Select和Poll基本没有区别，唯一的区别是
int select(int nfds, fd_set *readfds, fd_set *writefds, fd_set *exceptfds, struct timeval *timeout);
select的fd_set是一个有大小的数据结构，所能控制的I/O数有限，同时每次都需要重新设置
Poll因为是类似链表的原因，所以对控制的I/O数没有限制
select的参数nfds在没有任何连接进来的情况下，为6 从linux查看可以看出 前三个是查询 修改 删除 第四个是Java运行需要的 后面2个完成监听端口的动作。
Epoll的不同之处首先在于它是不用轮询的，他是通过回调的方式来判断哪个文件描述符有传输内容。
简单对比：
Select需要一直轮询所有连接的Socket，而Epoll则是对所有连接的Socket新增一个回调函数，如果有数据过来了，回调函数就会被触发，从此处可以看出大部分情况下Epoll的性能都要较Select相比更好。
但是也有另外一种情况，举例10000个Socket连接进来，同时10000个Socket都有数据传输，此时Select轮询的性能肯定会更好一些，因为Epoll的回调函数被调用的过于频繁了。
当然Epoll也有一些办法降低此种情况的影响，比如ET模式、Epolloneshot事件等，所以具体使用哪种方式还是需要根据具体的业务来进行不同的选择。

最后更新于2020年12月31日晚上23点
原创不易，如果该文章对你有所帮助，望左上角点击关注~如有任何技术相关问题，可通过评论联系我讨论,我会在力所能及之内进行相应回复以及开单章解决该问题.

该文章如有任何错误请在评论中指出，感激不尽，转载请附出处！
个人博客首页：https://blog.csdn.net/yjrguxing ——您的每个关注和评论都对我意义重大