镇安县住房和城乡建设部网站,优化营商环境条例全文,建立网站预算,湖南响应式网站哪里有目录
BIO
BIO单线程模式
BIO多线程模型
NIO
IO multiplexing
select函数#xff1a;
poll函数#xff1a;
epoll函数#xff1a; 首先了解同步和异步#xff0c;阻塞和非阻塞的概念#xff1a;
同步#xff1a;发起请求的一方需要等待操作完成并获得结果后才能继… 目录
BIO
BIO单线程模式
BIO多线程模型
NIO
IO multiplexing
select函数
poll函数
epoll函数 首先了解同步和异步阻塞和非阻塞的概念
同步发起请求的一方需要等待操作完成并获得结果后才能继续执行后续的操作换句话说同步操作会阻塞当前线程或进程直到操作完成。
异步发起请求的一方可以继续执行后续的操作而不必等待操作完成。异步操作通常会使用回调函数、事件处理器或者轮询的方式来处理结果。在异步模式下不同的参与方可以独立地进行操作无需等待其他操作的完成。
阻塞在阻塞模式下当一个I/O操作被调用时程序会一直等待直到操作完成或者发生错误才会返回结果。在阻塞状态下调用线程或进程会被挂起无法进行其他任务直到I/O操作完成或者超时。
非阻塞在非阻塞模式下当一个I/O操作被调用时程序会立即返回而不会等待操作完成。如果操作不能立即完成会返回一个错误或标记来指示当前操作无法立即完成而不会阻塞调用线程或进程。
阻塞和非阻塞他们描述的是操作等待的状态同步和异步描述的是操作执行的顺序。 BIO
在没有IO多路复用之前遇到并发多客户端连接通常采用 BIO 模型来处理并发多连接问题。
BIO单线程模式
最开始的BIO单线程同步模式
code案例
public class redisServerBIO {public static void main(String[] args) throws IOException {ServerSocket serverSocket new ServerSocket(6379);while (true) {System.out.println(模拟RedisServer启动------111等待连接);Socket accept serverSocket.accept();System.out.println(--------222 成功连接: IdUtil.simpleUUID());InputStream inputStream accept.getInputStream();int length -1;byte[] bytes new byte[1024];System.out.println(-------333等待读取);while ((length inputStream.read(bytes)) ! -1) {System.out.println(------444 成功读取 new String(bytes,0,length));System.out.println( \t IdUtil.simpleUUID());System.out.println();}inputStream.close();accept.close();}}
}
存在的问题如果客户端与服务端建立了连接但连接的客户端迟迟不发数据线程就会一直阻塞在read()方法上这样其让客户旧不能进行连接。
BIO多线程模型
进一步改进BIO单线程模型采用BIO多线程模型为每一个客户端连接分配一个线程处理请求这样read()方法旧阻塞在每一个具体的线程上而不会阻塞主线程。
code案例
public class redisServerBIOMultiThread {public static void main(String[] args) throws IOException {ServerSocket serverSocket new ServerSocket(6379);while (true) {System.out.println(------111等待连接);Socket accept serverSocket.accept();System.out.println(--------222 成功连接: IdUtil.simpleUUID());new Thread(new Runnable() {SneakyThrowsOverridepublic void run() {InputStream inputStream accept.getInputStream();int length -1;byte[] bytes new byte[1024];System.out.println(-------333等待读取);while ((length inputStream.read(bytes)) ! -1) {System.out.println(------444 成功读取 new String(bytes,0,length));System.out.println( \t IdUtil.simpleUUID());System.out.println();}inputStream.close();accept.close();}}).start();}}
}存在的问题为每一个客户端都开辟一个线程的话并发量大的话那么开辟的线程也将及其庞大而在操作系统中用户态不能直接开辟线程需要调用内核态来创建线程其中会涉及到上下文的切换十分耗资源。
改进BIO多线程模型
方式一使用线程池
在客户端连接少的情况下可以使用但是用户量大的情况下不知道线程池要多大太大了内存可能不够太小了也不行。
方式二采用NIO非阻塞式IO方式
因为read方法阻塞了所以要开辟多个线程如果有什么方法能使read()方法不阻塞这样就不用开辟多个线程了——NIO NIO
在NIO模式中一切都是非阻塞的accept()方法式非阻塞的如果没有客户端连接就返回无连接标识read()方法是非阻塞的如果read()方法读取不到数据就返回空闲中标识如果读取到数据那么只阻塞read()方法读数据的时间。
在NIO模式中只有一个线程当一个客户端与服务端进行连接这个socket就会加入到一个数组中隔一段时间就会遍历一次看当前socket的read()方法能否读取到数据这样一个线程就能处理多个客户端的连接和读取了。
code案例
public class redisServerNIO {static ArrayListSocketChannel socketList new ArrayListSocketChannel();static ByteBuffer byteBuffer ByteBuffer.allocate(1024);public static void main(String[] args) throws IOException {System.out.println(--------RedisServerNIO 启动等待中........);ServerSocketChannel serverSocket ServerSocketChannel.open();serverSocket.bind(new InetSocketAddress(127.0.0.1,6379));serverSocket.configureBlocking(false);//设置为非阻塞模式while (true) {for (SocketChannel element : socketList) {int read element.read(byteBuffer);if(read 0){System.out.println(------读取数据: read);byteBuffer.flip();byte[] bytes new byte[read];byteBuffer.get(bytes);System.out.println(new String(bytes));byteBuffer.clear();}}SocketChannel socketChannel serverSocket.accept();if (socketChannel ! null){System.out.println(-------成功连接:);socketChannel.configureBlocking(false);//设置为非阻塞模式socketList.add(socketChannel);System.out.println(------socketList size: socketList.size());}}}}NIO模式依然存在问题
问题一有一万个客户端进行连接那么每次就要遍历一万个socket如果一万个socket中只有10个socket有数据就会做很多的无用功每次遍历read()返回-1 时仍然时一次浪费资源的系统调用。
问题二遍历socket的过程是在用户态用户态哦按段socket是否有数据还是在内核态调用read()方法来实现的还是会涉及到用户态和内核态的切换开销依然很大。
抛开NIO存在的问题其实上述的 NIO 模型的实现思路就是我们要讨论的IO多路复用IO multiplexing的思想。 IO multiplexing
IO multiplexing就是通过一种机制一个进程可以监视多个描述符一旦某个描述符就绪一般是读就绪或者写就绪能够通知程序进行相应的读写操作。可以基于一个阻塞对象并同时在多个描述符上等待就绪而不是使用多个线程(每个文件描述符一个线程每次new一个线程)这样可以大大节省系统资源。所以I/O 多路复用的特点是通过一种机制一个进程能同时等待多个文件描述符而这些文件描述符套接字描述符其中的任意一个进入读就绪状态。
对于NIO存在的问题二我们只需要在操作系统内核中提供类似NIO模型的函数就避免了用户态和内核态之间的切换所以在操作系统内核就有了select、poll、epoll函数来实现IOmultiplexing。
select函数
其实类似于上述的NIO模型的代码逻辑。只不过把NIO中用户态要遍历的fd数组socket连接数组拷贝到了内核态让内核态来遍历这样就不用在判断每个socket中是否有数据的时候切换用户态和内核态了问题二解决。
select函数是一个阻塞函数当没有数据时会一直阻塞在select那一行。select函数使用bitmap来代替我们上述代码中的Arraylist当有数据时会将bitmap中对应的位置置为1但并不会返回哪一个socket有数据。用户态只需要遍历bitmap看bitmap哪一位为1就read哪一个socket不在遍历每一个socket了问题一解决。 select函数存在的问题
1、每次的bitmap不可重用只能置1不能恢复
2、bitmap默认大小为1024虽可调整但还是有限度
3、需要将fd数组从用户态拷贝到内核态由内核态调用read()但还是由拷贝的开销
4、select并没有通知用户态哪一个socket有数据仍然要O(N)的遍历。 poll函数
阻塞函数没有数据时会阻塞在poll那一行。用数组代替了bitmap哪个socket有数据就将对应的位置置为POLLIN置1遍历数组找到置1的socket后再置0恢复数组便于重用。解决了select的问题1、2。 epoll函数
非阻塞函数。当有数据的时候会把相应的文件描述符可以理解为socket“置位”但是epoll并不是真正的置位这时候会把有数据的文件描述符放到队首epoll会返回有数据的文件描述符socket的个数N根据返回的个数只需要遍历钱N个文件描述符即可。解决了select的问题4
epoll函数对select的问题3的解决的处理看了大牛的帖子是这样解决的但还不是很理解记录一下 epoll函数之所以不需要用户态将文件描述符fd数组拷贝到内核态是因为它利用了操作系统内核的事件表机制可以直接操作内核态中的数据结构。 当使用epoll机制时首先通过epoll_create函数创建一个epoll实例该实例会在内核态中创建一个事件表。然后使用epoll_ctl函数向事件表中添加感兴趣的文件描述符和关注的事件类型。 在添加文件描述符到事件表时内核会直接引用用户程序传递的文件描述符而不是将文件描述符数组从用户态拷贝到内核态。这样可以避免不必要的内存拷贝开销。 当调用epoll_wait函数等待事件发生时内核会阻塞等待直到有事件发生或超时。一旦有事件就绪内核会将就绪的事件信息直接填充到用户程序提供的事件数组中而不需要再次进行内存拷贝。这样用户程序可以直接访问内核态中的事件信息。 通过避免文件描述符数组的用户态到内核态的拷贝epoll能够提高效率并减少系统调用的开销特别是在大规模的并发连接处理中。这是epoll相比于传统的select和poll机制更高效的一个重要原因。 redis是单线程模型之所以这么快的根本原因也是因为底层使用epoll函数实现了IO多路复用将连接信息和事件放到队列中通过IO多路复用一次放到事件分配器事件分配器将事件分发给事件处理器。 文件事件分配器
文件事件分派器是Redis事件驱动模型的核心组件。它使用I/O多路复用机制如select、poll、epoll等来监视文件描述符包括网络套接字和文件描述符的就绪状态。当一个文件描述符就绪时如可读或可写文件事件分派器会将就绪事件分派给相应的事件处理器进行处理。
事件处理器
事件处理器是一组处理不同类型事件的回调函数。每种事件类型都有对应的事件处理器。当文件事件分派器将一个就绪事件分派给事件处理器时相应的事件处理器会被调用来处理事件。事件处理器根据事件类型执行相应的逻辑如处理客户端请求、读取或写入数据等。
