Solutions aux problèmes de sécurité des threads en mode singleton en Java

Cet article présente principalement des informations pertinentes sur les problèmes de sécurité des threads en mode singleton Java. J'espère que grâce à cet article, tout le monde pourra comprendre et maîtriser l'utilisation de la sécurité des threads en mode singleton. Les amis dans le besoin pourront se référer à

Problèmes de sécurité des threads en mode Java singleton

La portée d'accès par défaut du bean fournie par le conteneur Spring IOC est le mode singleton. Autrement dit, il n’existe qu’une seule instance dans tout le cycle de vie de l’application. Par conséquent, dans le cadre d’une concurrence multithread, il y aura des risques pour la sécurité des threads. Nos servlets sous le framework MVC sont thread-safe. Étant donné que le servlet est côté client, il y a relativement peu de concurrence, mais du côté du service Web, cela doit être pris en compte.

Classe ThreadLocal : fournit une copie indépendante de la variable (instance) pour chaque thread et accède à l'isolation de chaque instance différente.

Dans le mécanisme de verrouillage de synchronisation, le thread retardataire attend la fin du thread précédent avant de pouvoir accéder à la variable membre. ThreadLocal implémente la réplication d'instance et isole les conflits de données d'accès aux objets. Dans le même temps, cela peut également résoudre une petite partie de la consommation et du fardeau de la gestion du cycle de vie d'un grand nombre d'instances en mode d'accès prototype. Ce sont deux réalisations de « l'échange de temps contre de l'espace » et de « l'échange d'espace contre du temps ». Le premier fournit uniquement une variable unique permettant aux différents threads de faire la queue pour y accéder, tandis que le second fournit une copie pour chaque thread, de sorte qu'il soit possible d'y accéder en même temps sans s'affecter mutuellement. En même temps, la copie est stockée dans le fichier. mémoire et ne sera plus accessible la prochaine fois. Régénérez l'instance pour réduire la consommation des ressources du serveur.

Nous savons qu'en général, seuls les beans apatrides peuvent être partagés dans un environnement multithread. Au Spring, la plupart des beans peuvent être déclarés comme étant à portée singleton. En effet, Spring utilise ThreadLocal pour traiter les états non thread-safe dans certains beans (tels que RequestContextHolder, TransactionSynchronizationManager, LocaleContextHolder, etc.), ce qui les rend thread-safe, car les beans avec état peuvent être partagés entre plusieurs threads.

Problèmes de sécurité des threads : causés par les variables globales et les variables statiques. Si chaque thread n'a que des opérations de lecture sur les variables globales et les variables statiques, mais aucune opération d'écriture, d'une manière générale, cette variable globale est thread-safe si elle est multiple ; les threads effectuent des opérations d'écriture en même temps, la synchronisation des threads doit généralement être prise en compte, sinon la sécurité des threads peut être affectée.

1) Les constantes sont toujours thread-safe (valeur constante)

2) La création d'une nouvelle instance avant chaque appel de méthode est thread-safe. (Différentes instances sont isolées les unes des autres)
3) Les variables locales sont thread-safe (isolées)

Parce qu'à chaque fois qu'une méthode est exécutée, des variables locales seront créées dans un espace indépendant, et ce n'est pas une ressource partagée. Les variables locales incluent les variables de paramètres de méthode et les variables internes à la méthode.

Statut : Possède des fonctions de stockage et de modification des données. Stateful Bean, un objet avec des variables d'instance, peut enregistrer des données et n'est pas thread-safe.

Apatride : Il s'agit d'une opération unique et ne peut pas modifier les données. L'objet sans état (Stateless Bean), un objet sans variables d'instance, ne peut pas enregistrer de données, est une classe immuable et est thread-safe. Au printemps, le mode singleton est une instance partagée pour améliorer les performances. Les beans avec état ne sont pas sûrs dans un environnement multithread, le mode prototype Prototype est donc adapté. Prototype : Chaque demande de bean crée une nouvelle instance de bean.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!