java - ReadableByteChannel.read(ByteBuffer dest) 读取上限为 8KB。为什么？

Question

我有一些代码:

1. 从 ReadableByteChannel 读取到 ByteBuffer，
2. 记录传输的字节，
3. 暂停几十到几百毫秒，
4. 将ByteBuffer传递到WritableByteChannel。

一些细节:

• 两个 channel 都是 TCP/IP 套接字。
• 总连接读取大小为数十兆字节。
• 源套接字(ReadableByteChannel 从中获取字节)位于同一台计算机上。
• HP DL380s 上的 Debian Lenny 64 位
• Sun Java 1.6.0 更新 20

问题是，无论使用 .allocate() 或 .allocateDirect() 分配多大的 ByteBuffer，读入 ByteBuffer 的字节数最大为 8KB。我的目标 ByteBuffer 大小是 256KB，这只是使用的一小部分(1/32)。大约 10% 的时间只读入 2896 字节。

我检查了操作系统 TCP 缓冲区设置，它们看起来很好。通过观察 netstat 关于缓冲区中有多少字节的报告可以证实这一点——套接字缓冲区中的数据都超过 8KB。

tcp        0 192384 1.2.3.4:8088     1.2.3.4:53404    ESTABLISHED
tcp6  110144      0 1.2.3.4:53404    1.2.3.4:8088     ESTABLISHED

这里突出的一件事是 TCP 和 TCP6 的混合，但我认为这应该不是问题。在上面的输出中，我的 Java 客户端位于端口 53404 上。

我尝试将套接字属性设置为有利于带宽而不是延迟，但没有改变。

Socket socket = new Socket(host.getHostName(), host.getPort());
socket.setPerformancePreferences(1, 0, 2);  //bw > connection time > latency

当我记录 socket.getReceiveBufferSize() 的值时，它始终报告仅为 43856 字节。虽然它比我想要的要小，但仍然超过 8KB。 (这也不是一个非常整数的数字，这是我所期望的。)

我真的很困惑这里的问题是什么。理论上，据我所知，这不应该发生。 “降级”到基于流的解决方案是不可取的，尽管如果找不到解决方案，这就是我们下一步要做的。

我错过了什么？我可以做什么来纠正它？

Answer 1

好的，我找到问题了! (如果有人遇到同样的问题，我会回答我自己的问题。)

我不是直接从 Socket 实例实例化 ReadableByteChannel ，而是从 HttpEntity.getContent() 实例化。 ( Apache HTTP Commons Client ) 方法返回 InputStream。 HTTP Commons 客户端很早就通过 DefaultHttpClientConnection.bind() 方法传递了套接字。我不明白的是，我认为该 channel 是 BufferedInputStream实例埋藏在 HTTP Commons Client 实现中。 (8KB 恰好是 Java 6 的默认值。)

因此，我的解决方案是从原始 Socket 实例中获取 ReadableByteChannel。