Est String get/set des threads?

Disons que j'ai la suite,

public class Foo{
    private String bar;

    public String getBar(){
        return bar;
    }

    public void setBar(String bar){
        this.bar = bar;
    }
}

Ces méthodes sont-elles automatiquement des threads en raison de l'immuable nature de la String classe, ou un certain mécanisme de verrouillage nécessaire?

Je suppose que tu veux dire String dans l'incubateur.
Oui, mon erreur! Fixe.
Connexes c# question: stackoverflow.com/questions/3595114/...
Un objet de type String est un non définitif de référence pour qu'il ne l'est pas. Voir stackoverflow.com/a/6060405/1812922 pour plus de détails

OriginalL'auteur mre | 2013-02-25

  1. 19

    Non, ce n'est pas thread-safe. Foo est mutable, donc si vous voulez vous assurer que les différents fils voir la même valeur de bar – qui est, cohérence – soit:

    • Faire bar volatile, ou
    • Rendre les méthodes synchronized, ou
    • Utiliser un AtomicReference<String>.

    Le lit et écrit de bar sont eux-mêmes atomique, mais l'atomicité n'est pas la sécurité des threads.

    http://docs.oracle.com/javase/tutorial/essential/concurrency/atomic.html

    Pour une couverture en profondeur, de Java, de simultanéité, de récupérer une copie de Java de la Simultanéité dans la Pratique (aka JCIP).

    +1 Ou tout simplement déclarer bar comme final, de sorte que la référence ne peut pas être attribué à une autre valeur. Bien sûr, il n'y aura pas de setter alors 🙂
    C'est immuable. Pas besoin d'un chien d'arrêt dans cette affaire. Et vous devez vous assurer de fournir un constructeur pour initialiser la valeur, parce que vous ne pouvez pas la changer une fois que vous quittez le constructeur dans ce cas.
    ... De la curiosité, ne soit de ceux qui ont vraiment de l'importance? Je veux dire, si votre problème est une condition de course, qui peut encore se produire, en dépit de la volatile ou synchronized - il diminue la "fenêtre", dans lequel il peut arriver, non? Ou ai-je raté quelque chose ici?
    et quelle race condition que ce serait? TBH, ces questions sont pourquoi j'ai éviter de partager des mutable (non-concurrent-bibliothèque) objets dans les threads autant que possible.
    Enfiler une mise à jour est bar en permanence. Enfiler deux est en attente pour bar pour lire comme une certaine valeur (la filature avec un while(...) boucle, par exemple). La condition de la course est pour enfiler deux à la lecture de la valeur de bar avant d'enfiler une des mises à jour à nouveau. Si l'une de ces options, et de faire en sorte que tous les fils sont la garantie d'avoir la même référence interne (même si les références sont atomiques peu importe), ce n'est pas grave si ils travaillent sur l'objet à différents temps tranches. Et oui, ce genre de choses c'est pourquoi je préfère des objets immuables.

    OriginalL'auteur Matt Ball

  2. 7

    Vous êtes à la définition de références, et en tant que tel String'immutabilité ne vient pas en jeu. Vous n'êtes pas affecter le contenu de String.

    OriginalL'auteur Brian Agnew

  3. 5

    Non, pas sûr.

    C'est Foo mutable comportement; la Chaîne de l'immutabilité ne reviennent pas à Toto.

    public class Foo{
    private String bar;

    public synchronized String getBar(){
        return bar;
    }

    public synchronized void setBar(String bar){
        this.bar = bar;
    }
}
    +1 Que sur la synchronisation des getBar()? Peut-être que certains filetage de la fixation d'une nouvelle valeur à bar, tandis que les autres threads de lecture bar.
    Désolé, vous vous êtes fait pas de sens pour moi. Je pense que vos commentaires ne sont que le fait de confondre la question.
    un non-synchronisé de lecture avec en parallèle, un poseur de garantir la cohérence dans les threads?
    -1 C'est juste étrange.
    comme vous l'avez maintenant, la lecture doit être synchronisé pour s'assurer que bar'état actuel est visible à tous les threads

    OriginalL'auteur duffymo

  4. 3

    Non, il n'est pas thread-safe.

    Tout String est immuable, le problème provient du domaine de la Foo. Pour rendre cela plus évident, considérons par exemple une méthode dont la tâche serait de ajouter (plutôt que de le remplacer) la valeur de bar. Lorsqu'elle est appelée à partir de plusieurs threads, certaines écrit pourrait être perdu. La même (perte de l'écrit) peut se produire avec votre simple poseur de trop, même si ce n'est pas évident au départ dans ce cas.

    OriginalL'auteur Theodoros Chatzigiannakis