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异步接口转同步接口