Comment assurer la sécurité des threads d'une méthode statique utilitaire ?

Question

Existe-t-il un moyen général ou des règles permettant d'assurer la sécurité des méthodes statiques utilisées dans les différentes classes d'utilitaires de n'importe quelle application ? Je souhaite ici mettre l'accent sur la sécurité des threads dans les applications Web.

Il est bien connu que les méthodes statiques avec des objets immuables comme paramètres sont sûres pour les threads et que les objets mutables ne le sont pas.

Si j'ai une méthode utilitaire pour une manipulation de java.util.Date et cette méthode accepte une instance de java.util.Date cette méthode ne serait pas sûre pour les threads. Alors comment la rendre thread safe sans changer la façon de passer les paramètres ?

public class DateUtils {

    public static Date getNormalizeDate(Date date) {
        // some operations
    }   
}

Il y a aussi la classe javax.faces.context.FacesContext mutable ? Est-il possible de passer une instance de cette classe à une telle méthode utilitaire statique ?

La liste des classes dont les instances peuvent ou ne peuvent pas être transmises en tant que paramètres pourrait être longue ; quels sont donc les points à garder à l'esprit lors de l'écriture des codes de ces classes utilitaires ?

Answer 1

Il est bien connu que les méthodes statiques dont les paramètres sont des objets immuables sont sûres et que les objets mutables ne le sont pas.

Je conteste ce point. Les arguments transmis à une méthode sont stockés sur une pile, ce qui est un idiome propre à chaque thread.

Si votre paramètre est un objet mutable tel qu'un Date vous devez alors vous assurer que d'autres fils de discussion ne le modifient pas en même temps ailleurs. Mais c'est une autre question qui n'a rien à voir avec la sécurité de votre méthode.

La méthode que vous avez proposée est à l'épreuve des threads. Elle ne conserve aucun état et n'opère que sur ses arguments.

Je vous recommande vivement de lire Concurrence Java en pratique ou un ouvrage similaire consacré à la sécurité des threads en Java. Il s'agit d'un sujet complexe qui ne peut être abordé de manière appropriée par le biais de quelques réponses StackOverflow.

Answer 2

Comme votre classe ne contient aucune variable membre, votre méthode est sans état (elle n'utilise que des variables locales et l'argument) et est donc sans risque pour les threads.

Le code qui l'appelle peut ne pas être sécurisé, mais c'est une autre discussion. Par exemple, si le code appelant lit une date qui a été écrite par un autre thread, vous devez utiliser une synchronisation appropriée dans le code d'écriture et de lecture de la date.

Answer 3

Compte tenu de la structure de la JVM, les variables locales, les paramètres des méthodes et les valeurs de retour sont intrinsèquement "sûrs pour les threads". Mais les variables d'instance et les variables de classe ne seront sûres pour les threads que si vous concevez votre classe de manière appropriée. plus aquí

Answer 4

Je vois beaucoup de réponses, mais aucune n'indique vraiment la raison.

On peut donc envisager les choses de la manière suivante, Chaque fois qu'un thread est créé, il est créé avec sa propre pile (je suppose que la taille de la pile au moment de la création est de ~2MB). Ainsi, toute exécution se produit dans le contexte de cette pile de threads. Toute variable créée vit dans le tas mais sa référence vit dans la pile, à l'exception des variables statiques qui ne vivent pas dans la pile du thread.

Tout appel de fonction que vous faites est en fait poussé sur la pile de threads, qu'il soit statique ou non statique. Puisque la méthode complète a été poussée sur la pile, toute création de variable qui a lieu vit à l'intérieur de la pile (à l'exception des variables statiques) et n'est accessible qu'à un seul thread.

Toutes les méthodes sont donc sûres jusqu'à ce qu'elles modifient l'état d'une variable statique.

Answer 5

Je recommanderais de créer une copie de cet objet (mutable) dès que la méthode démarre et d'utiliser la copie au lieu du paramètre original.

Quelque chose comme ceci

public static Date getNormalizeDate(Date date) {
    Date input = new Date(date.getTime());
    // ...
}