Les méthodes statiques non synchronisées sont-elles thread safe si elles ne modifient pas les variables statiques de la classe ?

Question

Je me demandais si vous avez une méthode statique qui n'est pas synchronisée, mais qui ne modifie pas de variables statiques, est-elle sûre pour les fils ? Et si la méthode crée des variables locales à l'intérieur ? Par exemple, le code suivant est-il thread-safe ?

public static String[] makeStringArray( String a, String b ){
    return new String[]{ a, b };
}

Donc, si j'ai deux threads qui appellent cette méthode de façon continue et simultanée, l'un avec des chiens (disons "dogue allemand" et "bull dog") et l'autre avec des chats (disons "persan" et "siamois"), est-ce que j'obtiendrai jamais des chats et des chiens dans le même tableau ? Ou bien les chats et les chiens ne seront-ils jamais dans la même invocation de la méthode au même moment ?

Answer 1

Cette méthode est 100% thread safe, elle le serait même si elle ne l'était pas. static . Le problème de la thread-safety se pose lorsque vous devez partager des données entre les threads - vous devez prendre soin de l'atomicité, de la visibilité, etc.

Cette méthode n'opère que sur les paramètres, qui résident sur la pile et les références aux objets immuables sur le tas. La pile est intrinsèquement locale au thread, donc aucun partage de données ne se produit, jamais.

Objets immuables ( String dans ce cas) sont également sûres pour les threads car une fois créées, elles ne peuvent pas être modifiées et tous les threads voient la même valeur. D'un autre côté, si la méthode acceptait (mutable) Date vous auriez pu avoir un problème. Deux threads peuvent modifier simultanément la même instance d'objet, provoquant des situations de concurrence et des problèmes de visibilité.

Answer 2

Une méthode ne peut être thread-unsafe que si elle modifie un état partagé. Qu'il soit statique ou non n'est pas pertinent.

Answer 3

Cette fonction est parfaitement sécurisée.

Si vous y pensez... imaginez ce qui se passerait si c'était différent. Chaque fonction habituelle aurait des problèmes de threading si elle n'était pas synchronisée, donc toutes les fonctions API du JDK devraient être synchronisées, car elles pourraient potentiellement être appelées par plusieurs threads. Et comme la plupart du temps l'application utilise une API, les applications multithreadées seraient effectivement impossibles.

C'est trop ridicule pour y penser, alors juste pour vous : Les méthodes ne sont pas threadsafe s'il y a une raison claire pour laquelle il pourrait y avoir des problèmes. Essayez de toujours penser à ce qui se passerait s'il y avait plusieurs threads dans ma fonction, et ce qui se passerait si vous aviez un step-debugger et que vous fassiez avancer, étape après étape, le premier... puis le deuxième thread... peut-être le deuxième encore... y aurait-il des problèmes ? Si vous en trouvez un, c'est qu'il n'est pas thread safe.

Sachez également que la plupart des classes de collection Java 1.5 ne sont pas threadsafe, sauf celles qui sont indiquées, comme ConcurrentHashMap.

Et si vous voulez vraiment vous plonger dans ce domaine, examinez de près le mot-clé volatile et TOUS ses effets secondaires. Jetez un coup d'œil aux classes Semaphore() et Lock(), ainsi qu'à leurs amis de java.util.Concurrent. Lisez toute la documentation API relative à ces classes. Cela vaut la peine d'apprendre et c'est aussi satisfaisant.

Désolé pour cette réponse trop élaborée.

Answer 4

Utilisez le static avec des méthodes statiques synchronisées pour modifier les données statiques partagées entre les threads. Avec le mot-clé static mot-clé tous les fils créés se disputeront une seule version de la méthode.

Utilisez le volatile ainsi que les méthodes d'instance synchronisées garantissent que chaque thread possède sa propre copie des données partagées et qu'aucune lecture/écriture ne fuit entre les threads.

Answer 5

L'immuabilité des objets de type chaîne est une autre raison pour laquelle le scénario ci-dessus est sûr pour les fils. Au contraire, si des objets mutables sont utilisés (par exemple, makeMutableArray ), la sécurité des processus sera certainement rompue.