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

java异步接口转同步接口