如果今天设计了Java：同步接口

Java已经走了很长一段路。 很长的路要走。 它带有早期设计决策中的所有“垃圾”。

一遍又一遍后悔的一件事是， 每个对象（可能）都包含一个监视器 。 几乎没有必要这样做，并且最终在Java 5中纠正了该缺陷，当时引入了新的并发API，例如java.util.concurrent.locks.Lock及其子类型。 从那时起，编写同步的并发代码变得比以前容易得多，那时我们只有synchronized关键字以及难以理解的wait()和notify()机制：

同步修饰符几乎不再使用

为这些方法上的“便捷”修饰符指定的原始语言设计：

// These are the same:
public synchronized void method() {
    ...
}

public void method() {
    synchronized (this) {
        ...
    }
}

// So are these:
public static synchronized void method() {
    ...
}

public static void method() {
    synchronized (ClassOfMethod.class) {
        ...
    }
}

您几乎不想在整个方法范围上进行同步，以将同步时间保持在最短，并且每次需要同步时都将方法分解出来很乏味。

此外，监视器破坏了封装。 如果您在this class上或整个class上进行同步，则每个人都可以在您的监视器上进行同步。 您可能不希望这样做，这就是为什么大多数仍然使用synchronized关键字工作的人只会创建一个显式的私有锁对象，例如：

class SomeClass {
    private Object LOCK = new Object();

    public void method() {
        ...

        synchronized (LOCK) {
            ...
        }

        ...
    }
}

如果这是经典synchronized块的标准用例，那么我们还需要每个对象上都有一个监视器吗？

在更现代的Java版本中同步

如果Java的设计与当今的有关Java语言的知识，我们不会允许使用synchronized任何随机对象（包括字符串或阵列）上：

// Wouldn't work
synchronized ("abc") {
    ...
}

我们将引入一个特殊的Synchronizable marker接口，以确保实现者将拥有一个监视器。 并且synchronized块将仅接受Synchronizable参数：

Synchronizable lock = ...

synchronized (lock) {
    ...
}

这将与foreach或try-with-resources完全相同：

Iterable<Object> iterable = ...

// The type to the right of ":" must be Iterable
for (Object o : iterable) {
    ...
}

// The assignment type must be AutoCloseable
try (AutoCloseable closeable = ...) {
    ...
}

// The assignment type must be a functional interface
Runnable runnable = () -> {};

因此，为了使给定的语言功能正常工作，Java语言对在该上下文中使用的类型施加了约束。 对于foreach或try-with-resources，需要一个具体的JDK类型。 在使用lambda表达式的情况下，需要匹配的结构类型（对于Java来说，这是很深奥的，但是很聪明）。

不幸的是，出于向后兼容的原因，将不会为synchronized块添加任何新的限制。 还是会吗？ 很好，如果类型不是Synchronizable则可能会发出可选警告。 在未来的几个主要版本中，这可能允许从实际上不需要进行同步的对象中删除监视器。

从本质上讲，C语言一直在使用互斥锁。 他们是很特别的事情。 不常见。

翻译自: https://www.javacodegeeks.com/2016/01/java-designed-today-synchronizable-interface.html