Netty第一章 1-2 Netty权威指南读书笔记(二)

1.CS模型


两个进程间的交互。

服务端:提供位置信息(绑定的IP地址+监听端口)。

客户端:通过连接操作像服务端监听的地址发起请求。通过三次握手建立连接,成功后就可以通过socket进行通信了。

2.同步阻塞模型


ServerSocket:负责绑定IP

Socket:发起连接操作

连接成功后,双方通过输入输出流进行同步阻塞式通信。

3.BIO通信模型(一请求一应答模型)


服务端:一个独立的acceptor线程负责监听客户端的连接。每接收到一个客户端的连接请求,就为其创建一个新的线程进行链路处理,处理完毕通过输出流返回应答给客户端,线程销毁。

缺点:缺乏弹性伸缩能力。当客户端并发量大的时候,服务端线程数和客户端并发访问数1:1。(一个线程只能处理一个客户端连接)

线程是java虚拟机的宝贵资源,线程数膨胀后,系统性能下降,继而会发生线程堆栈溢出,创建新线程失败,最终宕机,不能提供服务。

4.线程池调优


有新的客户端接入时,将客户端socket封装位task(实现Runnable),扔到后端的线程池中进行处理。线程池中设置消息队列进行缓冲,避免了每个请求接入都创建一个新的线程,资源可控。

优点:线程池和消息队列都是有界的,无论多大并发,都不会导致线程个数膨胀或者队列过长内存溢出。

5.本质问题


read方法:对socket输入流进行读取时,会一直阻塞直到“有数据可读”,“可用数据已读取完”,“空指针或者IO一场”。当对方“发送请求或者应答消息比较缓慢”,或者“网络传输较慢”,读取输入流的一方的通信线程将被长时间阻塞(发送方发送需要60s,读取方读取的IO线程会同步阻塞60s,此间其他介入消息只能在消息队列中排队)。

write方法:OutputStream的write方法调用来写输出流时,也会阻塞,直到所有要发送的字节全部写入完毕,或发生异常。当消息接收方处理缓慢时,将不能及时从TCP缓冲区读取数据,会导致发送方的TCP window size不断减小,直到为0,双方处于keep Alive状态,消息发送方将不能再向TCP缓冲区写入消息,write操作会被阻塞直到window size大于0或者IO异常。

线程池问题:如果所有可用的线程都被阻塞了,后续的IO消息都将进入阻塞队列。队列满了以后,后续入队列的操作将被阻塞。因为前端只有一个Acceptor线程接收客户端接入,它被阻塞在线程池的同步阻塞队列之后,新的客户端请求消息会被拒绝,客户端会发生大量的连接超时。当所有的连接都超时,调用者会认为系统已经崩溃,无法接收新的请求消息。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值