我是MicroStream的首席开发人员。 （这不是别名帐户。我真的只是创建它。我在StackOverflow上阅读了10年左右，但从未有过创建帐户的理由。直到现在。）

在每次初始化时，MicroStream都会分析所有必需的实体和值类型类的当前运行时版本，并从中获取优化的元数据。 在运行时遇到迄今为止未知的类时，将执行相同的操作。 该分析是针对每个反射进行的，但是由于对于每个处理的类仅进行一次分析，因此反射性能成本可以忽略不计。 实际的存储和加载或序列化和反序列化是基于创建的元数据通过优化的框架代码完成的。

如果类布局发生变化，则类型分析将创建一个从存储该类实例的字段布局到当前类实例的映射。 如有可能，自动进行（明确的更改或通过一些可配置的启发式方法），否则通过用户提供的映射。性能保持不变，因为JVM不在乎它（简而言之）是否将加载的值＃3复制到位置＃3或位置＃5。全部在元数据中。

使用了ByteBuffer，更精确地说是直接使用ByteBuffer，但仅用作堆外内存的锚点，以便通过直接的“不安全”低级操作进行处理。如果您不熟悉“不安全”操作，则一个简短而简单的概念是：“它与C ++代码一样直接和快速。”您可以非常快地完成几乎所有需要的操作，但是您也要对所有事情负责。有关更多详细信息，请访问Google“ sun.misc.Unsafe”。

不生成任何代码。没有使用字节码黑客攻击，通过代理或类似的猴子业务默认替换实例。从技术上讲，它只是一个Java库（包括“不安全”用法），但具有许多经过适当设计的逻辑。

作为旁注：反射速度不像通常认为的那样慢。不再。确实如此，但是在过去的Java版本中已经对其进行了很多优化。 只有每项操作都必须重新进行所有的类分析，字段查找等操作时，它才很慢（很多框架似乎都做得不好，因为它们写得不好）。如果一次收集（设置可访问性等）字段，然后将其缓存，则反射实际上出奇地快。

关于与Protobuf串行化的比较：

由于我没有使用协议缓冲区，而且我不知道它在内部如何工作，因此我无法透露任何具体信息。 与通常的复杂技术一样，要进行真正有意义的比较可能会非常困难，因为不同的技术具有不同的优化优先级和限制。

大多数序列化方法都放弃了引用一致性，但只存储“数据”（即，如果两个对象引用了第三个对象，则反序列化将创建该第三个对象的两个实例。 这样：A-> C A-> C1 B-> C2。 基本上，这会破坏/破坏/破坏对象图，并使循环图的序列化成为不可能，因为它会创建并无限级联复制。例如，请参阅JSON序列化。有趣的事。） 甚至Brian Goetz的Java“ Serialization 2.0”草案也包含该限制（请参阅http://cr.openjdk.java.net/~briangoetz/amber/serialization.html的“限制”）（以及另一个打破关注点分离的限制）。

MicroStream没有该限制。它可以正确处理任意对象图，而不会破坏它们的引用。 他写道，到目前为止，保持参照一致性不变并不是“尝试做太多事情”。这是“做得正确”。一个人只需要知道如何正确地做。如果正确完成，它甚至是微不足道的。 因此，根据Protobuf-Serialization的局限性（“恶魔般的脚步”），一般来说，它几乎无法甚至根本无法与MicroStream相提并论。

当然，您始终可以根据自己的特定需求创建一些性能比较测试，并查看哪种技术最适合您。只要确保您了解某种技术对您的限制（破坏的参照一致性，禁止的类型，必需的注释，必需的默认构造函数/ getter / setter等）。 MicroStream没有任何*。

（*）原因：在技术上可能的情况下，有意排除了对系统内部（例如线程）或非实体（例如lambda或代理实例）的序列化/存储。