IMPORTANT EDIT je sais à propos de la "passe avant" dans le thread où les deux missions sont passe ma question est: serait-il possible pour un autre thread à la lecture de "b" non-nulle, tandis que "a" est toujours null. Donc, je sais que si vous êtes d'appel doIt() de la même fil que celui où vous l'aviez appelé setBothNonNull(...) alors il ne peut pas jeter une NullPointerException. Mais que faire si on est en appelant doIt()à partir d'un autre thread que celui de l'appel de setBothNonNull(...) ?
Notez que cette question est uniquement à propos de l' volatile mot-clé et l' volatile garanties: il est pas à propos de l' synchronized mot-clé (donc merci de ne pas répondre "vous devez utiliser synchroniser" pour que je n'ai pas de problème à résoudre: je veux simplement comprendre l' volatile garanties (ou de l'absence de garanties) au sujet de l'exécution).
Dire que nous avons un objet contenant deux volatile Chaîne de références qui sont initialisées à null par le constructeur et que nous n'avons qu'un moyen de modifier les deux chaînes de caractères: en appelant setBoth(...) et que nous ne pouvons définir leurs références par la suite, de non-référence null (seul le constructeur est autorisé à mettre à null).
Par exemple (c'est juste un exemple, il n'y a pas encore question):
public class SO {
private volatile String a;
private volatile String b;
public SO() {
a = null;
b = null;
}
public void setBothNonNull( @NotNull final String one, @NotNull final String two ) {
a = one;
b = two;
}
public String getA() {
return a;
}
public String getB() {
return b;
}
}
Dans setBothNoNull(...), la ligne de l'affectation de la non-nulle du paramètre "a" s'affiche avant la ligne de l'affectation de la non-nulle du paramètre "b".
Alors si je fais cela (encore une fois, il n'y a pas de question, la question est venue prochaine):
doIt() {
if ( so.getB() != null ) {
System.out.println( so.getA().length );
}
}
Ai-je raison de ma compréhension que, en raison de l'exécution que je peux obtenir un NullPointerException?
En d'autres termes: il n'y a aucune garantie que parce que j'ai lu un non-null "b" je vais vous lire une valeur non null "un"?
Parce qu'en raison de out-of-order (multi)du processeur et de la façon dont volatile travaux "b" peut être attribué avant "une"?
volatile garanties qui lit à la suite d'une écriture doit toujours se référer à la dernière valeur écrite, mais ici il y a un out-of-order "de l'émission" droit? (encore une fois, le "problème" est fait exprès pour essayer de comprendre la sémantique de l' volatile mot-clé et la Java du Modèle de Mémoire, non pas pour résoudre un problème).
