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：同步接口的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。