java nio SocketChannel 底层编程踩坑(适用于高级程序员)

闲着想做一个服务器之间的高速文件传输工具
突然发现了一些关于NIO的新坑,顺带把NIO这块会遇到的问题都整理一下

本次心得

1. NIO 其实不适合做 长连接通信,BIO更适合

因为NIO 的原理:由调度员(Selector) 把来客户端上送的数据缓冲到 SocketChannel通道中, 等待用户处理,处理好后,关闭来客连接,等待其他人上送数据
而BIO 更容易为每个客户保持一个长连接通道. 虽然NIO也可以做到,但是非常不方便.

2. 现在我非要用NIO做长连接,并上传大数据,就会遇到一系列问题

  • 避免重复实例化ByteBuffer
    NIO的数据是放在HeapByteBuffer 堆缓存中然后过渡给你自己定义的ByteBuffer ,这类对象不要重复实例化,因为没有必要 ,只要两个足矣,一个是读,一个是写, 我为了研究 故意用队列 插入了一堆接收到的Buf缓存,结果反而因为实例化更慢.

  • ByteBuffer 会被覆盖吗?
    如果读缓存只有一个,那接收数据时会不会被后续的新数据覆盖呢?
    答: 如果你没有及时处理堆缓存, 堆缓存是会被新数据覆盖, 我称为数据洪峰的影响,就像城市下暴雨,下水道来不及排水, 发生水涝一样.

  • 如何解决数据洪峰问题?
    在高速且连续发送大数据块的情况下,客户端是无法不丢失数据
    只有改进通信机制才可以解决, 有两种简单方案可以解决:
    1 每发送一批次 就 让对方应答,对方应答后,再发送下一批次
    2 每发送一批次 等待一段时间再发送第二批次

  • 通过延时发送的时间解决数据洪峰时,应该延时多久?
    其实我不建议用这种方法,
    因为如果你的缓冲区大,延时时间就要久一些,

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值