我在SO和其他地方看到过的每个Java循环字节缓冲区实现都没有扩展java.nio.ByteBuffer，对我来说这是与SocketChannel一起使用所必需的。有没有人知道扩展ByteBuffer的开源实现。我试着写下我自己的路，但是当我意识到位置和剩余的功能是最终的时候我被卡住了，我将覆盖那些以调整头部并防止缓冲区溢出异常。在通过套接字通道发送5000条消息时，每个人都需要我将东西复制到线性缓冲区的头部，这会增加大约450毫秒或90us的每条消息（其中包含10个数据包，因此每个数据包为9us）。现在，我能想到的唯一方法是覆盖每一个方法并重写所有方法。有什么想法吗？
答案 0 :(得分：6)
您可以使缓冲区比一条消息大得多，而不是创建循环缓冲区。假设最大消息大小为N个字节。创建一个100 * N字节的缓冲区只有compact（）ByteBuffer，当剩下少于N个字节时。这样可以将复制量减少100倍。
另一个优化是在没有剩余数据的情况下压缩（）ByteBuffer，因为这非常快。
答案 1 :(得分：5)
你不能扩展java.nio.ByteBuffer ，就这么简单。 c-tor是包私有的。 它不起作用，b / c的主要思想是将地址传递给某些C代码。此外，您无法覆盖任何内容，因为许多方法都是最终的。 ByteBuffers已经设计了速度，一些决定可能看起来很奇怪，但它们还可以。
java.nio.channels.GatheringByteChannel和java.nio.channels.ScatteringByteChannel值得一试，虽然有很多依赖于实现的（本机C）可以使它们有用。
答案 2 :(得分：1)
我们可能会尝试这个，因为它是apache许可证
答案 3 :(得分：0)
我会利用方法ByteBuffer.wrap（）。快速了解一下先前Dean Hiller先生发布的思科实施情况，您可以用getWriteBuffer（）替换put（），它会返回一个ByteBuffer，它将该部分包装在它可以写入的缓冲区中。
相同的逻辑可以应用于阅读部分。
它具有不必压缩的优点，这可能是昂贵的，这取决于ByteBuffer中的字节数，代价是复杂解析逻辑：你可能得到你的消息的第一部分为ByteBuffer包装底层循环缓冲区的最后一个区域。要获取消息的第二部分，需要另一次读取以将循环缓冲区开头的字节数组包装到另一个ByteBuffer中。