java - 为什么不锁定一个基于值(value)的类

Question

The docs假设您不应该锁定基于值的 Java 类的实例，例如 Optional 因为代码

may produce unpredictable results if it attempts to distinguish two references to equal values of a value-based class ... indirectly via an appeal to synchronization...

Why should Java's value-based classes not be serialized?断言

Because future JVM implementations might not use object headers and reference pointers for value-based classes, some of the limitations are clear. (E.g. not locking on an identity which the JVM must not uphold. A reference on which is locked could be removed and replaced by another later, which makes releasing the lock pointless and will cause deadlocks).

即该禁令是面向 future 的。但该断言没有引用资料。

如果面向 future 是基础，我想要一个引用。如果不是，我想了解基础是什么，因为基于值的对象是 Object。

编辑

顺便说一句，我理解不锁定整数和其他原始包装类的原因；它们可能被缓存。但是我找不到任何文档说基于值的类也是如此，而 Integer 等。基于值(value)观，他们are not value-based classes . IE。 JavaDocs of Optional ＆ETC。明确地说

This is a value-based class

Integer 则不同。 , &等等

Answer 1

这是 Nicolai Parlog 的博文关于基于值的类:

In Java 8 value types are preceded by value-based classes. Their precise relation in the future is unclear but it could be similar to that of boxed and unboxed primitives (e.g. Integer and int). Additionally, the compiler will likely be free to silently switch between the two to improve performance. Exactly that switching back and forth, i.e. removing and later recreating a reference, also forbids identity-based mechanisms to be applied to value-based classes.

Nicolai 的意思是这样的:

• 在未来，编译器可能以不保留对象身份的方式在值和基于值的类之间透明地转换。

• 某些事物(“基于身份的机制”)取决于对象身份。示例包括用于引用的 == 语义、身份哈希码、原始锁定和对象序列化。

• 对于那些事情，透明翻译有可能不透明。

在原始锁定的情况下，担心的是可能会发生类似以下序列的事情。

1. 创建了一个基于值的类的实例。
2. 实例在幕后转换为值。
3. 然后将值转换回来，得到一个不同对象。

如果两个线程然后使用“实例”作为原始锁，它们可能不知道实际上实际上有两个对象(现在)。如果他们随后尝试同步，他们将(可能)锁定不同的对象。这意味着无论锁定旨在保护的状态是什么，都不存在互斥。

如果您不锁定基于值的类，您将不必担心这种潜在的危险......在未来。

但请注意，Nicolai 的博文是一个人对 Java 10 或更高版本中可能发生的事情的猜测。

---

BTW, I understand the reasons not to lock on Integers and other primitive-wrapper classes; they may be cached.

缓存本身不是问题，而是导致问题的机制。真正的问题是很难推断锁定对象的对象标识，因此锁定机制是否合理。

对于原始包装器，装箱和拆箱的语义导致了对象身份的不确定性。展望 future ，提出的值类型 <-> 对象转换将是这种不确定性的另一个来源。

---

以上博客基于"State of the Values" April 2014. John Rose, Brian Goetz, and Guy Steele其中讨论了将值类型添加到 Java 的 future 版本中。本说明是一个立场声明，而不是一个完全规范(和采纳)的提案。然而，该注释确实给了我们这个提示:

"Many of the above restrictions correspond to the restrictions on so-called value-based classes. In fact, it seems likely that the boxed form of every value type will be a value-based class."

这可以理解为暗示值类型和现有的基于值的类之间存在关系。 (特别是如果您阅读了 value-based classes 的 Java 8 描述的字里行间。)

---

更新 - 2019/05/18

值类型没有进入 Java 12，它们(还)不在 Java 13 的列表中。

但是，已经可以证明与博文所讨论的问题相关的问题:

    public class BrokenSync {
        private final Integer lock = 1;

        public void someMethod() {
            synchronized (lock) {
                // do something
            }
        }
    }

问题是 BrokenSync 的每个实例都会通过自动装箱 1 创建一个 Integer 实例。但是 JLS 表示，自动装箱生成的 Integer 对象不一定是不同的对象。因此，您可以使用相同的 Integer 对象作为锁，从而得到 BrokenSync 的所有实例。