Java 8 接口方法中不允许“同步"的原因是什么? [英] What is the reason why “synchronized” is not allowed in Java 8 interface methods?

问题描述

在 Java 8 中，我可以轻松地编写:

In Java 8, I can easily write:

interface Interface1 {
    default void method1() {
        synchronized (this) {
            // Something
        }
    }

    static void method2() {
        synchronized (Interface1.class) {
            // Something
        }
    }
}

我将获得我也可以在类中使用的完整同步语义.但是，我不能在方法声明中使用 synchronized 修饰符:

I will get the full synchronisation semantics that I can use also in classes. I cannot, however, use the synchronized modifier on method declarations:

interface Interface2 {
    default synchronized void method1() {
        //  ^^^^^^^^^^^^ Modifier 'synchronized' not allowed here
    }

    static synchronized void method2() {
        // ^^^^^^^^^^^^ Modifier 'synchronized' not allowed here
    }
}

现在，人们可以争辩说这两个接口的行为方式相同，只是Interface2 在method1() 和method2()，比 Interface1 做的强一点.当然，我们也可能会争辩说 default 实现不应该对具体的实现状态做出任何假设，或者这样的关键字根本不会发挥作用.

Now, one can argue that the two interfaces behave the same way except that Interface2 establishes a contract on method1() and on method2(), which is a bit stronger than what Interface1 does. Of course, we might also argue that default implementations should not make any assumptions about concrete implementation state, or that such a keyword simply wouldn't pull its weight.

JSR-335 专家组决定不支持synchronized 接口方法的原因是什么?

What is the reason why the JSR-335 expert group decided not to support synchronized on interface methods?

推荐答案

虽然乍一看似乎很明显人们希望在默认方法上支持 synchronized 修饰符，但事实证明这样做会很危险，所以被禁止了.

While at first it might seem obvious that one would want to support the synchronized modifier on default methods, it turns out that doing so would be dangerous, and so was prohibited.

同步方法是一种方法的简写，它的行为就好像整个主体都包含在一个 synchronized 块中，其锁定对象是接收者.将此语义扩展到默认方法似乎是明智的；毕竟，它们也是带有接收器的实例方法.(请注意，synchronized 方法完全是一种语法优化；它们不是必需的，它们只是比相应的 synchronized 块更紧凑.有一个合理的论点首先，这是一个过早的句法优化，同步方法引起的问题比解决的问题还多，但那艘船很久以前就航行了.)

Synchronized methods are a shorthand for a method which behaves as if the entire body is enclosed in a synchronized block whose lock object is the receiver. It might seem sensible to extend this semantics to default methods as well; after all, they are instance methods with a receiver too. (Note that synchronized methods are entirely a syntactic optimization; they're not needed, they're just more compact than the corresponding synchronized block. There's a reasonable argument to be made that this was a premature syntactic optimization in the first place, and that synchronized methods cause more problems than they solve, but that ship sailed a long time ago.)

那么，为什么它们是危险的?同步与锁定有关.锁定是关于协调对可变状态的共享访问.每个对象都应该有一个同步策略来确定哪些锁保护哪些状态变量.(请参阅 Java 并发实践，第 2.4 节.)

So, why are they dangerous? Synchronization is about locking. Locking is about coordinating shared access to mutable state. Each object should have a synchronization policy that determines which locks guard which state variables. (See Java Concurrency in Practice, section 2.4.)

许多对象使用Java 监视器模式 (JCiP 4.1) 作为它们的同步策略，其中对象的状态由其内在锁保护.这种模式没有什么神奇或特别之处，但它很方便，并且在方法上使用 synchronized 关键字隐含地假定了这种模式.

Many objects use as their synchronization policy the Java Monitor Pattern (JCiP 4.1), in which an object's state is guarded by its intrinsic lock. There is nothing magic or special about this pattern, but it is convenient, and the use of the synchronized keyword on methods implicitly assumes this pattern.

拥有状态的类可以确定该对象的同步策略.但是接口不拥有它们混入的对象的状态.因此，在接口中使用同步方法会假定特定的同步策略，但您没有合理的假设基础，因此很可能是这种情况同步的使用不提供任何额外的线程安全(您可能在错误的锁上进行同步).这会给您一种错误的信心，认为您已经对线程安全做了一些事情，并且没有错误消息告诉您您假设了错误的同步策略.

It is the class that owns the state that gets to determine that object's synchronization policy. But interfaces do not own the state of the objects into which they are mixed in. So using a synchronized method in an interface assumes a particular synchronization policy, but one which you have no reasonable basis for assuming, so it might well be the case that the use of synchronization provides no additional thread safety whatsoever (you might be synchronizing on the wrong lock). This would give you the false sense of confidence that you have done something about thread safety, and no error message tells you that you're assuming the wrong synchronization policy.

为单个源文件持续维护同步策略已经够难了；更难确保子类正确遵守其超类定义的同步策略.试图在这种松散耦合的类(一个接口和可能实现它的许多类)之间这样做几乎是不可能的，而且很容易出错.

It is already hard enough to consistently maintain a synchronization policy for a single source file; it is even harder to ensure that a subclass correctly adhere to the synchronization policy defined by its superclass. Trying to do so between such loosely coupled classes (an interface and the possibly many classes which implement it) would be nearly impossible and highly error-prone.

考虑到所有反对的论点，论据是什么?似乎他们主要是为了让界面表现得更像特征.虽然这是一个可以理解的愿望，但默认方法的设计中心是界面演变，而不是特性--".在两者可以一致实现的地方，我们努力做到这一点，但在一个与另一个冲突的地方，我们不得不选择支持主要设计目标.

Given all those arguments against, what would be the argument for? It seems they're mostly about making interfaces behave more like traits. While this is an understandable desire, the design center for default methods is interface evolution, not "Traits--". Where the two could be consistently achieved, we strove to do so, but where one is in conflict with the other, we had to choose in favor of the primary design goal.

这篇关于Java 8 接口方法中不允许“同步"的原因是什么?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！