Multiples threads appelant la méthode de l'assistance statique

Si vous êtes inquiet de la synchronisation et de la sécurité du thread, n'utilisez pas d'aides statiques. Créez une classe normale avec vos méthodes d'assistance et créez une instance sur demande de servlet. Gardez-le simple: -)

Si vous n'avez pas à partager, vous pouvez le faire filer local, alors il ne doit pas nécessairement être le fil en sécurité.

public class Helper {

private static final ThreadLocal<SomeObject> obj = new ThreadLocal<SomeObject>() {
    public SomeObject initialValue() {
        return enw SomeObject();
    }
}

public static void changeMember() {
    Helper.obj.get().changeValue();
}

public static String readMember() {
    Helper.obj.get().readValue();
}

}

Dans le premier cas, vous n'avez pas à vous soucier des problèmes de threading, car les variables sont locales à chaque fil. Vous identifiez correctement le problème dans le second cas, car plusieurs threads seront en train de lire / écrire le même objet. La synchronisation sur les méthodes fonctionnera, de même que les blocs synchronisés.

pour la première partie: Oui, ces appels sont indépendants et fonctionnent en parallèle lorsqu'ils sont appelés par différents threads.

Pour la dernière partie: Utilisez des blocs de synchronisation sur l'objet simultané, un objet factice ou un objet de classe. Soyez conscient des blocs de synchronisation en cascade. Ils peuvent conduire en verrouillons morts lorsqu'ils sont acquis dans un ordre différent.

Je vais résumer ici ce qui a été dit dans les commentaires à la réponse de la balle Matt, car il est assez long à la fin et que le message est perdu: et le message était

Dans un environnement partagé, comme un serveur Web / applications, vous devez essayer de trouver une solution sans synchronisation. L'utilisation d'aides statiques synchronisées sur un objet statique peut fonctionner suffisamment bien pour que l'application autonome avec un seul utilisateur devant l'écran, dans un scénario multi-utilisateurs / multipiapplications, cela se termine très probablement dans une très mauvaise performance - cela signifie effectivement sérialisé l'accès à Votre candidature, tous les utilisateurs devraient attendre sur le même verrou. Vous ne remarquerez peut-être pas le problème pendant une longue période: si le calcul est suffisamment rapide et que la charge est distribuée de manière uniforme.

Mais tout d'un coup, tous vos utilisateurs peuvent essayer de passer par le calcul à 9h du matin et que votre application s'arrêtera pour fonctionner! Je veux dire pas vraiment arrêter, mais ils bloqueraient tous sur la serrure et faire une énorme file d'attente.

Maintenant, quelle que soit la nécessité d'un État partagé, puisque vous avez initialement nommé des calculs à l'origine de la synchronisation: les résultats doivent être partagés? Ou sont ces calculs spécifiques à un utilisateur / session? Dans ce dernier cas, un threadlocal selon Peter Lawrey serait suffisant. Sinon, je dirais pour la performance globale Il serait préférable de faire dupliquer les calculs de tout le monde qui les ait besoin pour ne pas synchroniser (dépend du coût).

La direction de la session doit également être mieux à gauche au conteneur: il a été optimisé pour les gérer efficacement, si nécessaire, y compris la clustering, etc. Je doute que l'on puisse faire une meilleure solution sans investir beaucoup de travail et gagner beaucoup de bugs sur le chemin . Mais comme la balle mat déclarée devrait être mieux demandée séparément.