select最大的缺陷就是单个进程所打开的FD是有一定限制的,它由FD_ SETSIZE
设置,默认值是1024。 对于那些需要支持上万个TCP连接的大型服务器来说显然太少了。可以选择修改这个宏然后重新编译内核,不过这会带来网络效率的下降。我们也可以通过选择多进程的方案(传统的Apache方案)解决这个问题,不过虽然在Linux上创建进程的代价比较小,但仍旧是不可忽视的。另外,进程间的数据交换非常麻烦,对于Java 来说,由于没有共享内存,需要通过Socket通信
或者其他方式进行数据同步,这带来了额外的性能损耗,增加了程序复杂度,所以也不是一种完美的解决方案。值得庆幸的是,epoll
并没有这个限制,它所支持的FD
上限是操作系统的最大文件句柄数,这个数字远远大于 1024。例如,在1GB内存的机器,上大约是10万个句柄左右,具体的值可以通过cat./proc/sys/fs/file-max
察看,通常情况下这个值跟系统的内存关系比较大。
2.I/O效率不会随着FD数目的增加而线性下降。
传统select/poll
的另一个致命弱点,就是当你拥有一个很大的socket
集合时,由于网络延时或者链路空闲,任一时刻只有少部分的socket
是“活跃”的,但是select/poll
每次调用都会线性扫描全部的集合,导致效率呈现线性下降。epoll
不存在这个问题,它只会对“活跃”的socket
进行操作一这是因为在内核实现中,epoll
是根据每个fd上面的callback
函数实现的。那么,只有“活跃”的socket
才会去主动调用callback
函数,其他idle 状态的socket
则不会。在这点上,epoll
实现了一个伪AIO。针对epoll
和select
性能对比的benchmark
测试表明:如果所有的socket
都处于活跃态一例如一一个高速LAN环境,epoll
并不比select/poll
效率高太多;相反,如果过多使用epoll_ctl
,效率相比还有稍微地降低。但是一旦使用idleconnections
模拟WAN环境,epoll的效率就远在select/poll
之上了。
3.使用mmap加速内核与用户空间的消息传递。
无论是select
、poll
还是epoll
都需要内核把FD消息通知给用户空间,如何避免不必要的内存复制就显得非常重要,epoll
是通过内核和用户空间mmap
同一块内存来实现的。
4.epoll 的API更加简单。
包括创建一个epoll描述符
、添加监听事件
、阻塞等待所监听的事件发生
、关闭epoll描述符
等。
值得说明的是,用来克服
select/poll
缺点的方法不只有epoll, epoll 只是一种Linux的实现方案。在freeBSD
下有kqueue
,而dev/poll
是最古老的Solaris的方案,使用难度依次递增。kqueue 是freebsd的宠儿,它实际上是一个功能相当丰富的kernel事件队列,它不仅仅是select/poll
的升级,而且可以处理signal、目录结构变化、进程等多种事件。kqueue是边缘触发的。/dev/poll
是Solaris的产物,是这一系列高性能API中最早出现的。Kernel提供了一个特殊的设备文件/dev/poll
,应用程序打开这个文件得到操作fd_ set
的句柄,通过写入pollfd
来修改它,一个特殊的ioctl
调用用来替换select。不过由于出现的年代比较早,所以/dev/poll
的接口实现比较原始。
最后
一次偶然,从朋友那里得到一份“java高分面试指南”,里面涵盖了25个分类的面试题以及详细的解析:JavaOOP、Java集合/泛型、Java中的IO与NIO、Java反射、Java序列化、Java注解、多线程&并发、JVM、Mysql、Redis、Memcached、MongoDB、Spring、Spring Boot、Spring Cloud、RabbitMQ、Dubbo 、MyBatis 、ZooKeeper 、数据结构、算法、Elasticsearch 、Kafka 、微服务、Linux。
这不,马上就要到招聘季了,很多朋友又开始准备“金三银四”的春招啦,那我想这份“java高分面试指南”应该起到不小的作用,所以今天想给大家分享一下。
请注意:关于这份“java高分面试指南”,每一个方向专题(25个)的题目这里几乎都会列举,在不看答案的情况下,大家可以自行测试一下水平 且由于篇幅原因,这边无法展示所有完整的答案解析
下水平 且由于篇幅原因,这边无法展示所有完整的答案解析