BIO和NIO

介绍

IO是指系统和外围设备进行数据交换。主要包括磁盘IO、网络IO以及一些其它的如鼠标、显示器等外网设备IO。本文中讨论的BIO和NIO特指网络IO,其它的IO暂时先不聊。

BIO

BIO 顾名思义就是 Blocking IO, 翻译过来就是阻塞型IO。到底什么是BIO就看一段代码吧:

import java.io.IOException;
import java.net.InetSocketAddress;
import java.nio.ByteBuffer;
import java.nio.channels.ServerSocketChannel;
import java.nio.channels.SocketChannel;

/**
 * Function: BIO 示例代码
 */
public class SocketBio {
    private static final int PORT = 9090;

    private static final int BUFFER_SIZE = 4096;

    public static void main(String[] args) throws Exception {

        ServerSocketChannel serverSocketChannel = ServerSocketChannel.open();
        serverSocketChannel.bind(new InetSocketAddress(PORT));

        // 死循环 监听是否有新的连接
        while (true) {
            System.out.println("wait to be connected.");
            // 会阻塞
            SocketChannel client = serverSocketChannel.accept();
            System.out.println("Accept a client: " + client.socket().getPort());
            // 每次有新的连接来就需要new一个线程去处理请求
            Thread clientHandler = new Thread(() -> handleConnect(client));
            clientHandler.start();
        }
    }

    private static void handleConnect(SocketChannel client) {
        ByteBuffer byteBuffer = ByteBuffer.allocateDirect(BUFFER_SIZE);
        System.out.println("handle client message.");
        try {
            // 会阻塞
            client.read(byteBuffer);
            System.out.println("read something.");
            // do something.
            client.close();
        } catch (IOException ignore) {

        }
        System.out.println("handle client message finished.");
    }
}

NIO

那相对的NIO意思就是 Non-blocking IO, 让我们也直接看一段示例代码吧

import java.io.IOException;
import java.net.InetSocketAddress;
import java.nio.ByteBuffer;
import java.nio.channels.ServerSocketChannel;
import java.nio.channels.SocketChannel;
import java.util.Iterator;
import java.util.LinkedList;
import java.util.List;

/**
 * Function: 初学NIO示例
 */
public class SocketNio {
    private static final int PORT = 9090;

    private static final int BUFFER_SIZE = 64 * 4096;

    public static void main(String[] args) throws Exception {
        List<SocketChannel> clientList = new LinkedList<>();

        ServerSocketChannel serverSocketChannel = ServerSocketChannel.open();
        serverSocketChannel.bind(new InetSocketAddress(PORT));
        // 设置为非阻塞
        serverSocketChannel.configureBlocking(false);

        while (true) {
            System.out.println("wait to be connected.");
            SocketChannel client = serverSocketChannel.accept();
            if (null != client) {
                // 对应的连接也设置为非阻塞
                client.configureBlocking(false);
                clientList.add(client);
                System.out.println("Accept a client: " + client.socket().getPort());
            }
            Iterator<SocketChannel> iterator = clientList.iterator();
            while (iterator.hasNext()) {
                SocketChannel socketChannel = iterator.next();
                boolean res = handleConnect(socketChannel);
                if (res) {
                    iterator.remove();
                }
            }
            Thread.sleep(5000);
        }
    }

    private static boolean handleConnect(SocketChannel client) {
        ByteBuffer byteBuffer = ByteBuffer.allocateDirect(BUFFER_SIZE);
        System.out.println("handle client message.");
        try {
            // 不会阻塞
            int res = client.read(byteBuffer);
            if (res > 0) {
                // do something.
                System.out.println("read something.");
                client.close();
                return true;
            }
        } catch (IOException ignore) {
            return true;
        }
        return false;
    }
}

NIO和BIO的区别

从上面的例子可以看到两者的区别。对于BIO由于每一个连接的内容读取(read),以及建立连接的监听(accept),都会阻塞住当前的线程,所以我们不得不去创建更多的线程来处理每一个连接。随着连接增多,线程就越来越多。就会带来两个主要问题:

  • 大量的线程就会占用一部分内存作为内存栈。
  • 并且线程的增加也会导致线程间切换浪费了大量CPU资源。

而NIO不会阻塞线程,如果调用(accept read)时没有连接或者数据,会直接返回(-1 或者 0) 。这样我们就可以通过一个线程来做更多的事情,解决了BIO带来的问题。但同时,NIO也存在着新的问题:

  • 如果服务端建立了大量的连接。每个连接去读取数据时都需要调用read系统调用(需要用户态、内核态的切换)。而大多数的连接可能并没有数据写入,这时候就会造成大量CPU资源的浪费。

所以,IO多路复用就应运而生了。

IO多路复用

多路复用复用的是啥?

select

如上文说到的,NIO中会出现一个问题。就是当连接数多的时候,针对每一个连接都需要调用read来读取当前连接是否有新的数据包。举个比较极端的例子,当前服务端有1000个连接,其中只有5个连接有新的数据包。此时,NIO进行了1000次read系统调用,只有5次是真正的有效读。
所以,为了解决这个问题,内核提供了select系统调用。 `select``的函数签名如下:

int select(int nfds, fd_set *readfds, fd_set *writefds,fd_set *exceptfds, struct timeval *timeout);

其中,可以看到它提供了三个文件描述符的集合。分别监听读取,写入和异常事件。nfds是表示传入的三个文件描述符列表中最大的文件描述符编号+1(主要是用来提前结束内核循环的,不重要,忽略吧)。然后,最后一个是阻塞时间。调用select以后,程序会阻塞,直到监听的文件描述符中有对应的IO事件到达,或者达到了参数中给定的最大阻塞时间(也可以通过设置,表示一直阻塞,直到有对应的IO事件就绪)。如果有对应的IO事件就绪了,select会更新对应的文件描述符。告知当前这个文件描述符是否是IO ready状态的。如果是ready状态的话,就需要通过read调用对对应的连接进行数据的读取。那么在上面那个极端的例子中,这里一共经历了1次select和5次read【简化模型,不要较真!我也不清楚中间是否还有其它操作。TT】
select存在几个明显的缺点:

  • 文件描述符列表存在长度限制(32位系统为1024,64位操作系统位2048)
  • 对于文件描述符的监听,分成了三个列表。且每一次调用select时,都需要重新构建这三个列表(select过程中会改变数组的内容)。每次调用select都需要将这三个数组从用户态复制一份到内核态。
  • 事件到达后,需要遍历文件描述符数组。通过FD_ISSET()判断是否有监听的事件到达。
  • 每次调用select,内核也需要通过遍历,来获取对应的文件描述符中是否有事件到达,感觉效率比较低。

poll

poll其实和select差不多,参考poll。函数签名如下:

int poll(struct pollfd *fds, nfds_t nfds, int timeout);

poll相对于select主要优化了几个点

  • 没有了文件描述符列表长度限制(1024)
  • 将三个文件描述符数组改成了一个pollfd结构的数组,构建起来相对比较方便。

但是,select遗留的其它问题依旧没有得到解决。

epoll

epoll就比较牛逼了,也被称为事件驱动
使用epoll也就是对应这三个系统调用:
epoll包含了三个系统调用 epoll_create, epoll_ctl, epoll_wait

int epoll_create(int size);
int epoll_ctl(int epfd, int op, int fd, struct epoll_event *event);
int epoll_wait(int epfd, struct epoll_event * events, int maxevents, int timeout);

epoll_create 函数创建一个epoll文件描述符,参数size表明内核要监听的描述符数量(使用过程中会根据使用情况动态调整,不用太在意)。返回一个epoll文件描述符。
epoll_ctl 函数注册要监听的事件类型。四个参数解释如下:

epfd 是epoll_create 返回的文件描述符
op 表示fd操作类型,有如下3种

  1. EPOLL_CTL_ADD 注册新的fd到epfd中
  2. EPOLL_CTL_MOD 修改已注册的fd的监听事件
  3. EPOLL_CTL_DEL 从epfd中删除一个fd

fd 是要监听的描述符
event 表示要监听的事件
epoll_wait 函数等待事件的就绪,成功时返回就绪的事件数目,等待超时返回 0。

epfd 对应epoll_create 返回的文件描述符
events 表示从内核得到的就绪事件集合
maxevents 告诉内核events的大小
timeout 表示等待的超时事件
epoll比select和poll强在哪呢? select和poll每次都需要把需要监听的文件描述符列表传入到内核,内核每次都需要遍历获取对应连接的状态。而epoll完全是反过来的。epoll在内核的数据被建立好了之后,每次某个被监听的文件描述符一旦有事件发生,内核就会做个标记表示有事件到达。epoll_wait调用时,会尝试直接读取到当时已经标记好的fd列表,如果没有就会进入等待状态。所以epll_wati的时间复杂度可以看作是O(1), 而Select和Poll的时间复杂度都是O(n)

同时,epoll_wait直接只返回了有事件到达的文件描述符列表。这样上层应用处理起来也轻松愉快,不需要从大量注册的文件描述符中筛选出有事件到达的文件描述符。

技术选型 【后端】:Java 【框架】:springboot 【前端】:vue 【JDK版本】:JDK1.8 【服务器】:tomcat7+ 【数据库】:mysql 5.7+ 项目包含前后台完整源码。 项目都经过严格调试,确保可以运行! 具体项目介绍可查看博主文章或私聊获取 助力学习实践,提升编程技能,快来获取这份宝贵的资源吧! 在当今快速发展的信息技术领域,技术选型是决定一个项目成功与否的重要因素之一。基于以下的技术栈,我们为您带来了一份完善且经过实践验证的项目资源,让您在学习和提升编程技能的道路上事半功倍。以下是该项目的技术选型和其组件的详细介绍。 在后端技术方面,我们选择了Java作为编程语言。Java以其稳健性、跨平台性和丰富的库支持,在企业级应用中处于领导地位。项目采用了流行的Spring Boot框架,这个框架以简化Java企业级开发而闻名。Spring Boot提供了简洁的配置方式、内置的嵌入式服务器支持以及强大的生态系统,使开发者能够更高效地构建和部署应用。 前端技术方面,我们使用了Vue.js,这是一个用于构建用户界面的渐进式JavaScript框架。Vue以其易上手、灵活和性能出色而受到开发者的青睐,它的组件化开发思想也有助于提高代码的复用性和可维护性。 项目的编译和运行环境选择了JDK 1.8。尽管Java已经推出了更新的版本,但JDK 1.8依旧是一种成熟且稳定的选择,广泛应用于各类项目中,确保了兼容性和稳定性。 在服务器方面,本项目部署在Tomcat 7+之上。Tomcat是Apache软件基金会下的一个开源Servlet容器,也是应用最为广泛的Java Web服务器之一。其稳定性和可靠的性能表现为Java Web应用提供了坚实的支持。 数据库方面,我们采用了MySQL 5.7+。MySQL是一种高效、可靠且使用广泛的关系型数据库管理系统,5.7版本在性能和功能上都有显著的提升。 值得一提的是,该项目包含了前后台的完整源码,并经过严格调试,确保可以顺利运行。通过项目的学习和实践,您将能更好地掌握从后端到前端的完整开发流程,提升自己的编程技能。欢迎参考博主的详细文章或私信获取更多信息,利用这一宝贵资源来推进您的技术成长之路!
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值