如果今天设计了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语言一直在使用互斥锁。他们是很特别的事情。不常见。