最终字段语义&使用 setAccessible(true) 进行反序列化

Question

根据 Java 内存模型，在对象的构造函数中初始化且不受进一步修改的 final 字段保证其值能够被每个读取它的线程正确地看到，即使该对象本身已通过以下方式发布：数据竞赛。

JLS 讨论 17.5.3 Final 的后续修改字段，并含糊地指出

实现可以提供一种在最终字段安全上下文中执行代码块的方法。

它似乎并没有真正定义此类修改的语义，也没有确切地定义这个最终字段安全上下文事物必须存在的位置或如何定义它（即，JLS似乎没有给出任何保证最终字段的后续修改）。

我必须说，我没有完全理解偏序 dereferences() 和 mc()，也没有完全理解采取的 freeze 操作的行为放置在对最终字段进行任何修改（归因于其的初始值或后续修改）之后。

在这种情况下，我想知道的是：（反）序列化框架（例如 Gson）如何保证包含在构造函数中正确初始化的最终字段的反序列化对象不会造成线程可见性问题？

例如，考虑这个类：

class X {
  private final String s;
  public X(final String s) { this.s = s; }
  @Override public String toString() { return s; }
}

以及以下代码：

final Gson gson = new Gson();
X x = gson.fromJson(gson.toJson(new X("abc")), X.class);
System.out.println(x);
// prints abc

使用调试器进入方法 fromJson ，我看到 sun.misc.Unsafe 用于分配一个实例X 没有调用其构造函数，并且字段是 setAccessible(true)，最后它们被设置。

这仅适用于 Sun 的（或兼容的）JVM！看起来 Gson 也有针对多个 Android 版本的代码。

那么，是否存在与这些反序列化的最终字段相关的任何线程安全保证，就像我对使用 new X("abc “）？如果是这样，这个保证从何而来？

谢谢！

Answer 1

线程安全

正如我所读到的，线程安全保证来自于给定属性被声明为final的事实。它不是线程安全的点是：

• 在反序列化期间，当分配对象内存空间时，但在 final 属性分配值之前
• 通过 Reflection API 修改 final 字段期间（即，当值正在被修改的过程中，并且在此过程完成之前）

这里需要注意的是，引用你链接到允许某事理论上的可能性存在除 Reflection API 之外的其他（但具有相同的 final 字段修改能力）。

冻结

最终字段的冻结发生在构造函数的末尾
最终字段被设置，并在每次修改后立即设置
通过反射或其他特殊机制的最终字段。

至于冻结调用，基本上是说 freeze 用于将属性标记为“无法更改”，它是这样做的：

• 在构造函数执行结束时，其中未定义的 final 字段实际上被分配了一个值
• 在 final 字段值更改后，通过诸如 Reflection API 之类的方式

线程安全问题仅适用到正在修改/反序列化的对象。

所以：

(...code that comes before...)
END final field safe context - entering non-threadsafe area

  final fields are not frozen
    code that deserializes an object OR modifies a final field via reflection
  final fields are re-frozen

RESUME final field safe context - re-entering threadsafe area
(...code that comes after...)

因此...

构造函数运行后（即您已经获得了分配了值的实例化对象），最终字段无法更改，因为它已被冻结，除非使用 Reflection API 直接更改该值 - 此后它会再次冻结，因为毕竟该字段被声明为最终的。

如果您正在寻找特定于 Android 的答案（以确保其 JVM 行为与 Sun/Oracle 的 JVM 一致），则需要找到该 JVM 的等效文档。

Answer 2

解冻伴随着 (java.reflect.)Field.setAccessible(true) 调用。大多数定期使用反射来设置最终字段的框架通常在成功修改后永远不会调用 field.setAccessible(false) ，因此使该字段保持“未冻结”状态。

因此，任何其他负责的反射框架都会看到该字段是可访问的，并且可能会这样做。这是理论上的机会，但它可能会发生。序列化机制内部的此类操作使用Unsafe类（sun实现包）的方法是有原因的。

因此，当使用任何类型的反射 API 时，您确实可能会弄乱 JVM 并导致任何类型的不可预测的行为。唯一保存默认反序列化机制的是它是在实例创建时完成的，此时不可能发生任何并发访问。

这就是为什么安全管理器可以限制甚至禁止此类访问。

Answer 3

来自JLS

最终字段的冻结发生在设置最终字段的构造函数的末尾，以及每次通过反射或其他特殊机制修改最终字段之后。

由于记忆效应仅根据 freeze 操作来定义，这意味着如果在构造函数之后修改 final 字段，语义也适用 - 只要对象引用不存在在此之前泄露。这被认为是合法的用例。

一旦对象引用被发布，进一步修改 Final 字段就不是一个好主意。