问题标签 [bytebuffer]

我正在开发一个程序，我正在压缩大量信息并将其以字节的形式存储在缓冲区中。我不能使用ByteBuffer，因为我不知道最终尺寸。

有什么更好的方法来实现这一点？

java.nio.ByteBuffer#duplicate()返回一个共享旧缓冲区内容的新字节缓冲区。对旧缓冲区内容的更改将在新缓冲区中可见，反之亦然。如果我想要字节缓冲区的深层副本怎么办？

我正在研究一些使用直接字节SocketChannel缓冲区SocketChannel效果最好的代码 - 寿命长且大（每个连接数十到数百兆字节。）在用FileChannels 散列确切的循环结构时，我运行了一些微 -ByteBuffer.allocate()与ByteBuffer.allocateDirect()性能的基准。

结果令人惊讶，我无法真正解释。在下图中，ByteBuffer.allocate()传输实现在 256KB 和 512KB 处有一个非常明显的悬崖——性能下降了约 50%！似乎还有一个较小的性能悬崖ByteBuffer.allocateDirect()。（%-gain 系列有助于可视化这些变化。）

缓冲区大小（字节）与时间 (MS)

ByteBuffer.allocate()为什么和之间出现奇数的性能曲线差异ByteBuffer.allocateDirect()？ 幕后究竟发生了什么？

它很可能依赖于硬件和操作系统，所以这里有这些细节：

• 配备双核 Core 2 CPU 的 MacBook Pro
• 英特尔 X25M SSD 驱动器
• OSX 10.6.4

源代码，按要求：

由于 29 位整数在 AMF 中很流行，我想结合已知的最快/最好的例程。我们的库中目前存在两个例程，可以在 ideone 上进行实时测试 http://ideone.com/KNmYT
这里是快速参考的来源

我有一些代码：

1. 从 a 读ReadableByteChannel入 a ByteBuffer，
2. 记下传输的字节，
3. 暂停几十到几百毫秒，
4. 传递ByteBuffer到 a 上WritableByteChannel。

一些细节：

• 两个通道都是 TCP/IP 套接字。
• 总连接读取大小为数十兆字节。
• 源套接字（从中ReadableByteChannel获取字节）在同一台机器上。
• HP DL380s 上的 Debian Lenny 64 位
• Sun Java 1.6.0 更新 20

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

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

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

我尝试设置套接字属性以支持带宽而不是延迟，但没有改变。

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

我真的很困惑这里有什么问题。理论上，AFAIK，这不应该发生。“降级”到基于流的解决方案是不可取的，尽管如果找不到解决方案，这就是我们接下来要去的地方。

我错过了什么？我能做些什么来纠正它？

Java 中比较两个 ByteBuffer 的内容以检查是否相等的最简单方法是什么？

我希望使用 RMI 通过网络发送 java.nio.ByteBuffer，但是 ByteBuffer 不可序列化。我尝试了以下自定义类无济于事：

}

客户端仍然得到一个不可序列化的异常。有任何想法吗？

谢谢

The libraries I founded so far only have methods to decode from a file or InputStream. I have a ByteBuffer with OGG vorbis data and I need it decoded to PCM without having to write it to a file first.

我正在开发一个 Android 应用程序（显然是在 Java 中），我最近更新了我的 UDP 阅读器代码。在这两个版本中，我都设置了一些缓冲区并接收 UDP 数据包：

在最初的版本中，我一次将数据放回一个字节（实际上是 16 个 PCM 音频数据）：

在更新的版本中，我使用了一些我开始时不知道的很酷的 Java 工具：

在这两种情况下，“计数”都被正确填充（我检查过）。但是，我的流式音频似乎出现了新问题——也许处理得不够快——这对我来说没有任何意义。显然，缓冲区代码被编译成超过三个 JVM 代码语句，但是当我开始这个时，它确实是一个合理的假设，即第二个版本会比第一个更快。

显然，我并没有坚持我的代码必须使用 Java NIO 缓冲区，但至少乍一看，这样做似乎有点像“斗鱼”。

有人对快速、简单的 Java UDP 阅读器有任何建议，是否有普遍接受的“最佳方式”？

谢谢，R。

我正在尝试下载一个启动时小于 22 mb 的 zip 文件。我在这些异常之后更改了默认的 BufferedInputStream，但仍然出现内存不足错误。

堆：

编辑：好的，我能够让这个例子工作，但即使有正确的权限，我也会收到一个权限被拒绝的错误：