Apa alasan mengapa “sinkronisasi” tidak diizinkan dalam metode antarmuka Java 8?

Di Java 8, saya dapat dengan mudah menulis:

interface Interface1 {
    default void method1() {
        synchronized (this) {
            // Something
        }
    }

    static void method2() {
        synchronized (Interface1.class) {
            // Something
        }
    }
}

Saya akan mendapatkan semantik sinkronisasi penuh yang dapat saya gunakan juga di kelas. Namun saya tidak bisa menggunakan synchronizedpengubah pada deklarasi metode:

interface Interface2 {
    default synchronized void method1() {
        //  ^^^^^^^^^^^^ Modifier 'synchronized' not allowed here
    }

    static synchronized void method2() {
        // ^^^^^^^^^^^^ Modifier 'synchronized' not allowed here
    }
}

Sekarang, orang dapat berargumen bahwa kedua antarmuka berperilaku dengan cara yang sama kecuali yang Interface2membuat kontrak terus method1()-menerus method2(), yang sedikit lebih kuat daripada apa yang Interface1dilakukan. Tentu saja, kami mungkin juga berpendapat bahwa defaultimplementasi tidak boleh membuat asumsi tentang keadaan implementasi konkret, atau bahwa kata kunci seperti itu tidak akan menarik.

Pertanyaan:

Apa alasan mengapa kelompok ahli JSR-335 memutuskan untuk tidak mendukung synchronizedmetode antarmuka?

Meskipun pada awalnya mungkin tampak jelas bahwa seseorang ingin mendukung synchronizedpengubah pada metode default, ternyata hal itu akan berbahaya, dan itu dilarang.

Metode yang disinkronkan adalah singkatan untuk metode yang berperilaku seolah-olah seluruh tubuh tertutup dalam synchronizedblok yang objek kuncinya adalah penerima. Tampaknya masuk akal untuk memperluas semantik ini ke metode standar juga; setelah semua, mereka adalah metode instan dengan penerima juga. (Perhatikan bahwa synchronizedmetode sepenuhnya merupakan optimasi sintaksis; mereka tidak diperlukan, mereka hanya lebih kompak daripada synchronizedblok yang sesuai . Ada argumen yang masuk akal untuk dibuat bahwa ini adalah optimasi sintaksis prematur di tempat pertama, dan metode yang disinkronkan menyebabkan lebih banyak masalah daripada yang mereka pecahkan, tetapi kapal itu berlayar sejak lama.)

Jadi, mengapa mereka berbahaya? Sinkronisasi adalah tentang penguncian. Mengunci adalah tentang mengoordinasikan akses bersama untuk keadaan yang bisa berubah. Setiap objek harus memiliki kebijakan sinkronisasi yang menentukan kunci mana yang melindungi variabel keadaan. (Lihat Java Concurrency in Practice , bagian 2.4.)

Banyak objek yang digunakan sebagai kebijakan sinkronisasi Java Monitor Pattern (JCiP 4.1), di mana keadaan objek dijaga oleh kunci intrinsiknya. Tidak ada yang ajaib atau istimewa tentang pola ini, tetapi itu nyaman, dan penggunaan synchronizedkata kunci pada metode secara implisit mengasumsikan pola ini.

Kelaslah yang memiliki status yang dapat menentukan kebijakan sinkronisasi objek itu. Tetapi antarmuka tidak memiliki keadaan objek yang dicampur. Jadi, menggunakan metode yang disinkronkan dalam antarmuka mengasumsikan kebijakan sinkronisasi tertentu, tetapi yang Anda tidak memiliki dasar yang masuk akal untuk mengasumsikan, sehingga mungkin terjadi bahwa penggunaan sinkronisasi tidak memberikan keselamatan benang tambahan apa pun (Anda mungkin menyinkronkan kunci yang salah). Ini akan memberi Anda kepercayaan diri yang salah bahwa Anda telah melakukan sesuatu tentang keamanan utas, dan tidak ada pesan kesalahan yang memberi tahu Anda bahwa Anda menganggap kebijakan sinkronisasi salah.

Sudah cukup sulit untuk secara konsisten mempertahankan kebijakan sinkronisasi untuk satu file sumber; bahkan lebih sulit untuk memastikan bahwa subkelas dengan benar mematuhi kebijakan sinkronisasi yang ditentukan oleh superclass-nya. Mencoba melakukannya antara kelas-kelas yang digabungkan secara longgar (sebuah antarmuka dan kemungkinan banyak kelas yang mengimplementasikannya) akan hampir mustahil dan sangat rawan kesalahan.

Mengingat semua argumen itu bertentangan, untuk apa argumen itu? Sepertinya mereka kebanyakan tentang membuat antarmuka berperilaku lebih seperti ciri-ciri. Meskipun ini adalah keinginan yang dapat dimengerti, pusat desain untuk metode standar adalah evolusi antarmuka, bukan "Ciri -". Di mana keduanya dapat dicapai secara konsisten, kami berusaha untuk melakukannya, tetapi di mana satu bertentangan dengan yang lain, kami harus memilih yang mendukung tujuan desain utama.

public class ParentSync {

public synchronized void parentStart() {
    System.out.println("I am " + this.getClass() + " . parentStarting. now:" + nowStr());
    try {
        Thread.sleep(30000);
    } catch (InterruptedException e) {
        e.printStackTrace();
    }
    System.out.println("I am " + this.getClass() + " . parentFinished. now" + nowStr());
}

private String nowStr() {
    return new SimpleDateFormat("yyyy-MM-dd HH:mm:ss").format(new Date());
}
}


public class SonSync1 extends ParentSync {
public void sonStart() {
    System.out.println("I am " + this.getClass() + ". sonStarting,calling parent now ... ");
    super.parentStart();
    System.out.println("I am " + this.getClass() + ". sonFinished");
}
}



public class SonSync2 extends ParentSync {

public void sonStart() {
    System.out.println("I am " + this.getClass() + ". sonStarting,calling parent now ... ");
    super.parentStart();
    System.out.println("I am " + this.getClass() + ". sonFinished");
}
}



public class SyncTest {
public static void main(String[] args) throws Exception {

    new Thread(() -> {
        new SonSync1().sonStart();
    }).start();

    new Thread(() -> {
        new SonSync2().sonStart();
    }).start();

    System.in.read();
}
}

hasil:

I am class com.common.interface18_design.whynotsync_onmethod.SonSync1. sonStarting,calling parent now ... 
I am class com.common.interface18_design.whynotsync_onmethod.SonSync2. sonStarting,calling parent now ... 
I am class com.common.interface18_design.whynotsync_onmethod.SonSync2 . parentStarting. now:2019-04-18 09:50:08
I am class com.common.interface18_design.whynotsync_onmethod.SonSync1 . parentStarting. now:2019-04-18 09:50:08
I am class com.common.interface18_design.whynotsync_onmethod.SonSync1 . parentFinished. now2019-04-18 09:50:38
I am class com.common.interface18_design.whynotsync_onmethod.SonSync1. sonFinished
I am class com.common.interface18_design.whynotsync_onmethod.SonSync2 . parentFinished. now2019-04-18 09:50:38
I am class com.common.interface18_design.whynotsync_onmethod.SonSync2. sonFinished

(maaf karena menggunakan kelas induk sebagai contoh)

dari hasilnya, kita bisa tahu bahwa kunci kelas induk dimiliki oleh setiap sub kelas, objek SonSync1 dan SonSync2 memiliki kunci objek yang berbeda. setiap kunci adalah independensi. jadi dalam hal ini, saya pikir itu tidak berbahaya menggunakan disinkronkan di kelas induk atau antarmuka umum. adakah yang bisa menjelaskan lebih lanjut tentang ini?