Considérez une variable de type primitive avec de nombreux threads Lecture et quelques threads écrits, le code suivant fonctionnera-t-il correctement?
Si vous le ferez, fournit-il une meilleure performance que 1). déclarer synchronisé sur toutes les méthodes; 2). en utilisant une readwitelock explicite? p>
est-ce un modèle commun? Sinon, quel motif est habituellement utilisé dans cette situation? P>
Ceci fonctionne actuellement pour moi, mais je pense que c'est un peu redondant d'utiliser à la fois volatile et synchronisé. P>
private volatile int value = 1;
public void func1()
{
if (value == 1) {
// do something
}
}
public void func2()
{
if (value == 2) {
// do something
}
}
public void func3()
{
if (value == 3) {
// do something
}
}
public synchronized void increase()
{
if (value < 10) value++;
}
public synchronized void decrease()
{
if (value > 0) value--;
}
3 Réponses :
Je suis sûr qu'il offre de meilleures performances, car il n'y a pas de verrouillage, mais s'il est correct dépend de l'intention du code. Bien sûr, le comportement est différent du boîtier synchronisé. Si le comportement est similaire au cas de verrouillage dépend de l'endroit où vous vous verrez.
Considérez une variable de type primitive avec beaucoup de fils de lecture et quelques threads rédaction, le code suivant fonctionnera-t-il correctement?
Je pense que oui.
Si c'est le cas, cela offre-t-il une meilleure performance que 1). déclarer synchronisé sur toutes les méthodes; 2). en utilisant une readwitelock explicite?
Je pense que cela, à condition que les opérations de lecture sont supérieures à des demandes d'écriture. Cependant:
- Sauf si ce compteur est fortement soutenu, cela n'a probablement pas d'importance. Ne perdez pas votre temps à optimiser de manière micro-optimisant quelque chose à moins d'avoir une preuve que c'est (ou sera) un goulot d'étranglement.
- Si cela vous importe vraiment, reportez-vous.
- Ne soyez pas surpris si les performances relatives dépendent des versions / niveaux de correctifs JVM, des options JVM et du matériel; par exemple. Nombre de processeurs et d'architecture de mémoire.
Est-ce un modèle commun? Sinon, quel motif est généralement utilisé dans cette situation?
Je ne sais pas si cela est courant. Mais mon sentiment d'intestin est que l'approche la plus courante consiste à simplement utiliser une synchronisation régulière et ne pas s'inquiéter de cela. Sauf si vous avez affaire à une structure de données hautement opposée, la différence de performance entre les différentes approches sera insignifiante pour la performance globale des applications.
Oui, il est courant, du moins dans un certain degré :)
Le modèle que vous utilisez est décrit dans cet article IBM -> http://www.ibm.com/developerworks/java/library/j-JTP06197/index.html
(modèle n ° 5, astuce de verrouillage de lecture-écriture bon marché)
+1 Excellent article, un "DOIS LIRE" pour quiconque souhaite mieux comprendre les volatiles
La lecture sur les serrures volatiles et synchronisées me fait penser, pourquoi nous n'avons pas besoin des deux? Si je n'utilise que des ensemêtres synchronisés et des getters et ne définissez pas la variable comme volatilité, l'opération sera atomique, mais comment puis-je être sûr que le thread voit la valeur réelle et non de la valeur du cache de la CPU?