关于epoll与java NIO中select的思考

关于NIO编程与epoll、IOCP大家应该耳熟能详了,先简单回顾一下常见的结论:

  • NIO是非阻塞IO
  • epoll和IOCP分别是linux上和windows上对NIO操作系统级别的实现。
  • NIO单机支持的连接数比BIO要高很多,解决了C10K问题。

在获取通信数据时,NIO使用轮询的方式代替了阻塞的方式。但这样做是否效率更高呢?如果提高了,那原因是什么呢?在看了很多的资料后我对以上问题依然不是特别清晰。不过最近通过研究epoll与java selector的实现,有了一些新的理解。

java中selector的select方法依然是阻塞的,其内部调用的是不同操作系统中的实现,windows下是IOCP的poll0(...)方法,这是一个native方法,如下。

private native int poll0(long pollAddress, int numfds,
             int[] readFds, int[] writeFds, int[] exceptFds, long timeout);
// These arrays will hold result of native select().
            // The first element of each array is the number of selected sockets.
        // Other elements are file descriptors of selected sockets.
        private final int[] readFds = new int [MAX_SELECTABLE_FDS + 1];//保存发生read的FD
        private final int[] writeFds = new int [MAX_SELECTABLE_FDS + 1]; //保存发生write的FD
        private final int[] exceptFds = new int [MAX_SELECTABLE_FDS + 1]; //保存发生except的FD

这个poll0()会监听pollWrapper中的FD有没有数据进出,这会造成IO阻塞,直到有数据读写事件发生。比如,由于pollWrapper中保存的也有ServerSocketChannel的FD,所以只要ClientSocket发一份数据到ServerSocket,那么poll0()就会返回;又由于pollWrapper中保存的也有pipe的write端的FD,所以只要pipe的write端向FD发一份数据,也会造成poll0()返回;如果这两种情况都没有发生,那么poll0()就一直阻塞,也就是selector.select()会一直阻塞;如果有任何一种情况发生,那么selector.select()就会返回,所有在OperationServer的run()里要用while (true) {},这样就可以保证在selector接收到数据并处理完后继续监听poll();

所以可以看出,NIO依然是阻塞式的IO,那么它和BIO的区别究竟在哪呢。
其实它的区别在于阻塞的位置不同,BIO是阻塞在read方法(recvfrom),而NIO阻塞在select方法。那么这样做有什么好处呢。如果单纯的改变阻塞的位置,自然是没有什么变化的,但epoll等的实现的巧妙之处就在于,它利用回调机制,让监听能够只需要知晓哪些socket上的数据已经准备好了,只需要处理这些线程上面的数据就行了。采用BIO,假设有1000个连接,需要开1000个线程,然后有1000个read的位置在阻塞,采用NIO编程,只需要1个线程,它利用select的轮询方法配合epoll的事件机制及红黑树数据结构,降低了其内部轮询的开销,同时极大的减小了线程上下文切换的开销。

那么在一秒钟内,epoll的epoll.wait方法究竟会轮询多少次呢。这个问题我目前没有得到直接的答案。我调用java的NIO库的selector的selectNow()方法,然后不做任何业务处理,只增加了一个index++的操作,计算得到的结果大致是1秒钟index增加40w,这说明了epoll.wait是一个很快的的操作(有资料也表明了O(1)时间复杂度),看来NIO确实很适合处理大量并发连接的情况。

参考文章

  1. 了解Unix网络编程5种I/O模型
  2. tomcat 线程池介绍 BIO/NIO有何不同
  3. 为什么NIO比BIO效率高

你可能感兴趣的:(关于epoll与java NIO中select的思考)