JDK1.8中Class.getDeclaredFields()字段排序异常原因及序列化方案咨询

首先明确一个前提：Java官方规范从未对Class.getDeclaredFields()返回的字段数组顺序做任何保证，你在JDK1.8环境下观测到的字母序结果，只是特定VM实现带来的偶然现象，不具备任何可移植性：

• OpenJDK 8版本的HotSpot虚拟机在类加载阶段，会对类的字段做内存布局重排，目的是减少字段对齐带来的内存空间浪费，重排过程中同宽度类型的字段会按字段名字典序做排序存储。getDeclaredFields()方法本身没有做额外排序逻辑，只是直接遍历VM内部存储的字段元数据列表返回，因此你会看到完全按字母序排列的结果。
• 这个表现是强绑定实现版本的：升级到JDK9及以上版本的HotSpot，内部字段存储和遍历逻辑调整后，部分场景会返回接近源码声明顺序的结果；换用J9、GraalVM Native Image、Android ART等其他运行时，返回顺序又会发生变化；即使是同版本HotSpot，类经过字节码增强、混淆处理、不同类加载器加载时，返回顺序也可能出现差异。
• 所有依赖该方法返回顺序的业务逻辑，在运行环境发生变化时必然出现兼容性问题，没有任何例外。

你原本计划依赖字段声明顺序的方案从根上就不可靠，不管怎么调整反射调用逻辑，都绕不开规范不做承诺、不同环境行为不一致的问题，更稳妥的实现方向有几个：

• 优先选择显式绑定固定序列化标识的方案：给需要序列化的字段增加自定义运行时注解，在注解里显式指定固定的序列化顺序、序列化别名，混淆只会修改字段名、调整字段在字节码里的排布顺序，不会修改注解里的常量值。序列化/反序列化时，先扫描类中所有带注解的字段，按照注解里声明的固定顺序处理即可，完全不受混淆、JVM版本、字段书写顺序的影响。
  注解定义参考：

  @Retention(RetentionPolicy.RUNTIME)
  @Target(ElementType.FIELD)
  public @interface StableSerialField {
      // 固定序列化顺序，业务定义后不再修改
      int order();
      // 序列化后的固定字段名，避免混淆改名字段导致不兼容
      String serializedName();
  }
  

• 如果不想在业务代码里加大量注解，可以在编译期做字节码增强：编译阶段通过APT、字节码插桩的方式，自动收集每个类的字段信息，生成一份和类绑定的固定序列化元数据（存在独立的资源文件中，或者直接生成到类的静态常量里），运行时直接读取这份预生成的元数据做序列化，混淆时只要配置保留这份元数据即可，可靠性远高于运行时反射读取。
• 可以直接参考成熟跨语言序列化框架的设计思路：比如Protobuf、FlatBuffers都是通过给每个字段分配全局唯一的固定编号实现序列化兼容，天然抗混淆、跨版本、跨运行时，没有特殊定制需求的话直接基于这类框架做业务封装，比从零实现踩坑成本低很多。

注意：不要尝试通过修改JVM参数、反射访问VM内部类的方式强行拿到源码声明顺序，这类逻辑不仅兼容性极差，在高版本JDK加了模块化访问限制之后根本无法运行。

内容的提问来源于stack exchange，提问作者xjunz