JAVA NIO ByteBuffer 分配以适应最大的数据集？答案

【问题标题】：JAVA NIO ByteBuffer allocatation to fit largest dataset?JAVA NIO ByteBuffer 分配以适应最大的数据集？
【发布时间】：2010-11-06 01:01:16
【问题描述】：

我正在开发一款在线游戏，但在服务器端工作时遇到了一些问题。

在 Java 中使用非阻塞套接字时，处理在所有数据可用之前无法处理的完整数据包数据集的最佳操作方案是什么？例如，通过套接字发送大型 2D 平铺地图。

我可以想到两种处理方式：

分配足够大的 ByteBuffer 以处理处理我的示例中的大型 2D 平铺地图所需的完整数据集。继续将读取数据添加到缓冲区，直到所有数据都被接收并从那里处理。
如果 ByteBuffer 的大小较小（可能为 1500），则可以完成后续读取并将其输出到文件中，直到可以从文件中完全处理。这将避免必须拥有大的 ByteBuffer，但会因为磁盘 I/O 而降低性能。

我为每个 SocketChannel 使用了一个专用的 ByteBuffer，这样我就可以继续读取数据，直到它完成处理。问题是，如果我的 2D Tiled Map 大小达到 2MB，那么使用 1000 个 2MB ByteBuffers 真的明智吗（假设 1000 是客户端连接限制并且它们都在使用中）？一定有更好的方法，我没有想到。

我更愿意让事情保持简单，但我愿意接受任何建议并感谢您的帮助。谢谢！

【问题讨论】：

标签： java sockets nio buffering bytebuffer

【解决方案1】：

目前最好的解决方案可能是使用完整的 2MB ByteBuffer，并在必要时让操作系统负责分页到磁盘（虚拟内存）。您可能不会立即拥有 1000 个并发用户，当您这样做时，您可以进行优化。您可能会对真正的性能问题感到惊讶。

【讨论】：

将Java堆大小调整到这么大可以接受吗？即使 100 个连接也很容易打破它的默认限制，并且我的服务器将因 OutOfMemory 异常而崩溃。
你真的有 100 个并发连接吗？如果是这样，也许更好的解决方案是优化您的瓦片地图格式/协议，使其更简洁。否则，为什么不尝试增加堆大小呢？

【解决方案2】：

我认为最好的做法是简单地减小我的海量数据集的大小并发送图块更新而不是整个地图更新。这样我就可以简单地发送地图上已更改的图块列表，而不是重新发送整个地图。这减少了对如此大缓冲区的需求，我又回到了正轨。谢谢。

【讨论】：