BIO
从发起到结束都是阻塞的,比如到accept 和 read读都是阻塞的。
在这个期间用户可以使用多线程解决问题: accept 之后new 多个线程用来接收请求,BIO容易出现的问题就是 阻塞,并且每次new 线程极大浪费资源。
NIO
用户发起不会在阻塞到 accept 和 read 函数调用上,会返回一个空的链接或者空数据用来记录没有数据到达请求,只有在read读数据期间会阻塞.用户到来一个链接会加入到一个 容器(比如数组),遍历容器里面的链接是否有数据可读,相比BIO不会在阻塞,也不会new 大量的线程。缺点呦两个问题是,
- 需要不断遍历有没有事件到来(比如10000个链接只有一个有数据,浪费系统的资源),
- 还有就是read是内核态执行的程序,用户遍历fd链接和read读 需要内核和用户态不断地切换.
select
把NIO中用户遍历的数组放到了内核层这样遍历数据就不需要用户层和内核层频繁地进行切换.select 解决了 BIO上面所说的第二点。缺点:
- 一个进程最后只能有1024个客户端
- 用户态拷贝Fd到内核态浪费资源
- select没有通知哪个socket有数据仍然需要自己遍历哪个socket有数据
poll
想比select poll没有了1024的限制,事件位可以重置。
epoll
直接在内核开辟空间,只返回就绪好的FD