Tomcat中BIO和NIO的区别(Tomcat)
BIO
Tomcat中BIO的模型和理论很简单,例图如下
1.Acceptor线程死循环阻塞接收客户端的打过来的socket请求
2.接收到请求之后打包成一个SocketProcessor(Runnable),扔到线程池中读取/写入数据
参数配置
1.Acceptor默认线程是1,可以设置参数自己去改
2.Executor的线程池,一个Connector对应一个线程池,一个线程池可以被多个Connector公用,最小线程数是10,最大线程数是200
BIO总结
1.如果请求量很大,那么可以适当提高Acceptor线程池的线程数量
2.如果是那种处理起来效率不高的请求,那么可以适当提高Executor中的线程数
3.线程池中的线程还是要根据线上实际情况设置的,并不是越多越好,自己去压测看一下,找一个适当的值
NIO
Tomcat7中的NIO其实只有在读取请求头和请求行下才是非阻塞的,Servlet读取请求体的时候依旧还是阻塞的。执行流程如下
1.Acceptor接收客户端连接,接收到之后将socketChannel推到一个Poller(本质上也是一个Runnable)的events队列中,客户端和服务端的交互就此结束
2.推入到events队列中的是一个注册事件(要将其绑定到对应Poller中的Selector中)
3.对应Poller中的线程会去循环查询Selector中是否有事件发生,在查询之前会现将Events中的注册事件执行了,所以在执行events队列中的事件时,就相当于将socketChannel注册到Selector中。
4.socketChannel中的读写事件被Poller轮询到,就会socketChannel和读写事件打包成一个SocketProcessor,然后扔到Executor中执行读写逻辑
5.当SocketProcessor中的线程运行时,就会从socketChannel中读取/写入数据时(非阻塞),如果发现请求行和请求头已经读写并且解析完了,那么就会将剩下的交给Servlet处理,Servlet中可能会读写数据,或者发起响应,Servlet的这两个操作都是阻塞的。如果SocketProcessor线程读取到了数据,但是发现请求行和请求头的数据还没有读完,那么本次请求直接结束,要处理的话只能等下一次就绪事件
6.tomcat7中读取请求体的时候其实依旧是阻塞的,因为tomcat7本身并没有非阻塞这个概念,servlet读取请求体时底层依旧是用inputStream.read()方法读取,并且是阻塞的
7.Servlet读取请求体inputStream.read()方法底层调用的是InternalNioInputBuffer.SocketInputBuffer.doRead(),在这个方法中会调用fill(param1,param2)方法从操作系统读取数据
8.阻塞读取数据流的时候,还是得利用Selector,因为刚开始的时候socketChannel会被设置成非阻塞,然后socketChannel会被注册到一个Selector(称为主Selector),然后你如果再想把他改成阻塞,是会报错的(NIO中的限制),tomcat中为了实现这个阻塞,又构造了一个辅助Selector,将socketChannel重新注册到辅助Selector上,并设置成阻塞(在此之前已经取消了对主Selector的绑定)
9.首先先InputStream.read(),然后加锁(为了实现阻塞),辅助Selector也有与之对应的Poller线程,也会去轮询辅助Selector上发生的就绪事件。一旦轮询到对应的事件,就会解锁,解阻塞
10.从socketChannel中读取数据,结束
NIO总结
Tomcat7中的NIO其实相对于BIO并没有太多的性能提升,只是可以接收更多的客户端请求(NIO直接推到Events队列中就直接返回了),真正的在处理请求的时候并没有体现出太大的优势,如果是那种不用处理请求数据,并且不用响应什么数据的那种请求,那么NIO会有非常好的吞吐量
原文地址:https://blog.csdn.net/qq_43253125/article/details/142388078
免责声明:本站文章内容转载自网络资源,如本站内容侵犯了原著者的合法权益,可联系本站删除。更多内容请关注自学内容网(zxcms.com)!