我正在为加密的 P2P 架构开发一个低级 UDP 消息传递层，如果有兴趣，您可以在其 github 页面上阅读更多信息。
我已经构建了一个简洁的序列化框架，可以将 POJO 转换为紧凑的 ByteBuffer，还构建了使使用对称和非对称加密相当轻松的各种库。
我现在正在研究消息传递框架，它利用动态代理来实现与 GWT 的 RPC 机制类似的功能。
我的问题是，我很早就决定让序列化机制从 ByteBuffers 读取和写入。我现在发现这有几个问题：
谁能建议在这个框架中实现序列化的替代方法？
可能值得一看KryoNet - 它可能适合您的需求，或者您可以看看他们如何在幕后做事。
顺便说一句，他们确实将 ByteBuffers 用于 TCP 和 UDP 连接。我认为诀窍是从 ByteBuffers 中抽象出来，以便任何客户端代码都可以使用 POJO。要做到这一点，您显然需要在某个地方拥有可以将大对象分解为多个缓冲写入的逻辑。
我认为您实际上仍然需要 ByteBuffers，因为它们非常快，支持各种本机加速技巧，并且因为喜欢与否，最终您需要在高吞吐量 IO 环境中处理缓冲......
谁能建议在这个框架中实现序列化的替代方法？
为什么选择，在这里我解决您的主要问题：
- 您需要在序列化对象之前知道最大字节缓冲区大小
为什么字节缓冲区的最大大小？您可以使用缓冲区池。您应该准备将对象拆分为多个数据包。一包 - 一个对象不适用于较大的对象。序列化是一个有趣的观点：通常这就是它变得混乱的地方。您将需要一些不错的协议层（+-重新发送数据包等）
- 它们是可变的，这使得它们容易出错
出于性能原因，您确实希望它们是可变的。我从来没有遇到过它们是可变的问题。您可能还需要直接缓冲区。谢天谢地，它们变异了，因为它们不便宜（取消）分配。直接缓冲区直接映射到操作系统代码（查看 sun.nio.ch.DatagramDispatcher ）
- 它们与 DatagramPacket 不是特别兼容，并且 DatagramChannel 令人困惑。
它们没问题，您只需要将对象拆分为多个数据包。如果您使用缓冲区，请坚持使用缓冲区，它应该没问题。