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

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

本次心得

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

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

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

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

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

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

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