Java 8接口方法中不允许“同步”的原因是什么？

Question

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

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

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

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

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

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

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

题：

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

Answer 1

虽然乍一看似乎很想synchronized在默认方法上支持修饰符，但事实证明这样做很危险，因此被禁止。

同步方法是一种方法的简写，该方法的行为就像将整个主体包围在一个synchronized块中，该块的锁定对象是接收者。将这种语义扩展到默认方法似乎也很明智。毕竟，它们也是带有接收器的实例方法。（请注意，synchronized方法完全是语法优化；不需要它们，它们比相应的synchronized块更紧凑。有一个合理的论点是，这首先是一个过早的语法优化，并且同步方法造成的问题比他们解决的问题还多，但那艘船航行了很久。）

那么，为什么会有危险呢？同步与锁定有关。锁定是关于协调对可变状态的共享访问。每个对象都应具有一个同步策略，该策略可以确定哪些锁可以保护哪些状态变量。（请参阅《Java并发实践》第2.4节。）

许多对象将 Java监视器模式 （JCiP
4.1）用作其同步策略，其中对象的状态由其内部锁定来保护。这种模式没有什么魔术或特殊之处，但是它很方便，并且synchronized在方法上使用关键字隐式地采用了这种模式。

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

很难始终如一地维护单个源文件的同步策略。确保子类正确遵守其父类定义的同步策略甚至更加困难。在这样的松散耦合的类（一个接口以及可能实现它的许多类）之间尝试这样做几乎是不可能的，而且容易出错。

考虑到所有这些反对意见，那将是什么理由呢？似乎它们主要是关于使接口的行为更像特征。尽管这是可以理解的愿望，但是默认方法的设计中心是接口演变，而不是“特质”。我们力求做到这两个方面能够始终如一地实现，但是当一个与另一个发生冲突时，我们必须选择支持主要的设计目标。