首页 文章

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

提问于
浏览 次
199

在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
    }
}

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

问题：

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

java java-8 synchronized default-method jsr335

1 回答

  • 247

    这是一个深思熟虑的决定，而不是一个遗漏（正如其他地方所建议的那样） . 虽然起初看起来很明显人们会想要支持默认方法的 synchronized 修饰符，但事实证明这样做会很危险，所以被禁止了 .

    同步方法是一种方法的简写，其行为就像整个主体被包含在其锁定对象是接收器的 synchronized 块中一样 . 将此语义扩展到默认方法似乎也是明智的;毕竟，它们也是带接收器的实例方法 . （请注意， synchronized 方法完全是一种语法优化;它们比相应的 synchronized 块更紧凑 . 有一个合理的论据可以说这是一个过早的语法优化，并且同步方法引起的问题比他们解决了，但很久以前那艘船就航行了 . ）

    那么，他们为什么危险？同步是关于锁定 . 锁定是关于协调对可变状态的共享访问 . 每个对象都应该有一个同步策略，用于确定哪些锁保护哪些状态变量 . （见Java Concurrency in Practice，第2.4节 . ）

    许多对象使用Java Monitor Pattern（JCiP 4.1）作为其同步策略，其中对象的状态由其内部锁保护 . 这个模式没有任何魔力或特殊之处，但它很方便，并且在方法上使用 synchronized 关键字隐含地假设了这种模式 .

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

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

    鉴于所有这些论点反对，会有什么争论？看起来他们主要是让界面表现得更像特质 . 虽然这是一个可以理解的愿望，但默认方法的设计中心是界面演化，而不是“Traits--” . 在两者可以持续实现的情况下，我们努力做到这一点，但如果一方与另一方发生冲突，我们必须选择支持主要的设计目标 .

    回复于

相关问题