Quelle est la raison pour laquelle «synchronisé» n'est pas autorisé dans les méthodes d'interface Java 8?

En Java 8, je peux facilement écrire:

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

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

J'obtiendrai la sémantique de synchronisation complète que je pourrai également utiliser en classe. Je ne peux cependant pas utiliser le synchronizedmodificateur sur les déclarations de méthode:

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

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

Maintenant, on peut dire que les deux interfaces se comportent de la même manière , sauf que Interface2établit un contrat sur method1()et method2(), ce qui est un peu plus fort que ce qui le Interface1fait. Bien sûr, nous pourrions également affirmer que les defaultimplémentations ne devraient pas faire d'hypothèses sur l'état d'implémentation concret, ou qu'un tel mot clé ne pourrait tout simplement pas peser.

Question:

Quelle est la raison pour laquelle le groupe d'experts JSR-335 a décidé de ne pas prendre en charge synchronizedles méthodes d'interface?

Alors qu'au début, il peut sembler évident que l'on voudrait prendre en charge le synchronizedmodificateur sur les méthodes par défaut, il s'avère que cela serait dangereux et donc interdit.

Les méthodes synchronisées sont un raccourci pour une méthode qui se comporte comme si le corps entier était enfermé dans un synchronizedbloc dont l'objet de verrouillage est le récepteur. Il peut sembler judicieux d'étendre également cette sémantique aux méthodes par défaut; après tout, ce sont aussi des méthodes d'instance avec un récepteur. (Notez que les synchronizedméthodes sont entièrement une optimisation syntaxique; elles ne sont pas nécessaires, elles sont juste plus compactes que le synchronizedbloc correspondant . causer plus de problèmes qu'ils n'en résolvent, mais ce navire a navigué il y a longtemps.)

Alors, pourquoi sont-ils dangereux? La synchronisation concerne le verrouillage. Le verrouillage consiste à coordonner l'accès partagé à un état mutable. Chaque objet doit avoir une politique de synchronisation qui détermine quels verrous gardent quelles variables d'état. (Voir Java Concurrency en pratique , section 2.4.)

De nombreux objets utilisent comme politique de synchronisation le modèle de moniteur Java (JCiP 4.1), dans lequel l'état d'un objet est protégé par son verrou intrinsèque. Il n'y a rien de magique ou de spécial dans ce modèle, mais c'est pratique, et l'utilisation du synchronizedmot - clé sur les méthodes suppose implicitement ce modèle.

C'est la classe qui possède l'état qui détermine la politique de synchronisation de cet objet. Mais les interfaces ne possèdent pas l'état des objets dans lesquels elles sont mélangées. Donc, l'utilisation d'une méthode synchronisée dans une interface suppose une politique de synchronisation particulière, mais que vous n'avez aucune base raisonnable pour supposer, il pourrait donc bien être le cas que l'utilisation de la synchronisation n'offre aucune sécurité supplémentaire sur les threads (vous synchronisez peut-être sur le mauvais verrou). Cela vous donnerait le faux sentiment de confiance que vous avez fait quelque chose à propos de la sécurité des threads, et aucun message d'erreur ne vous indique que vous supposez la mauvaise politique de synchronisation.

Il est déjà assez difficile de maintenir de manière cohérente une politique de synchronisation pour un seul fichier source; il est encore plus difficile de s'assurer qu'une sous-classe adhère correctement à la politique de synchronisation définie par sa super-classe. Essayer de le faire entre de telles classes à couplage lâche (une interface et les nombreuses classes qui l'implémentent) serait presque impossible et très sujet aux erreurs.

Compte tenu de tous ces arguments contre, quel serait l'argument? Il semble qu'ils visent principalement à faire en sorte que les interfaces se comportent davantage comme des traits. Bien que ce soit un désir compréhensible, le centre de conception pour les méthodes par défaut est l'évolution de l'interface, pas "Traits--". Là où les deux pouvaient être atteints de manière cohérente, nous nous sommes efforcés de le faire, mais là où l'un est en conflit avec l'autre, nous avons dû choisir en faveur de l'objectif de conception principal.

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();
}
}

résultat:

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

(désolé d'avoir utilisé la classe parent comme exemple)

d'après le résultat, nous pourrions savoir que le verrou de classe parent appartient à chaque sous-classe, les objets SonSync1 et SonSync2 ont un verrou d'objet différent. chaque serrure est indépendante. donc dans ce cas, je pense qu'il n'est pas dangereux d'utiliser un synchronisé dans une classe parent ou une interface commune. quelqu'un pourrait-il expliquer plus à ce sujet?