Pourquoi les JDK sourcecode est conçu comme ça ?

Question

J’ai lu le code source de la JDK sur ConcurrentHashMap.

Mais m’a confondu le code suivant :

Ma question est :

« this.segments » est déclarée :

Donc, ici, au début de la méthode, une référence de même type, a déclaré pointer vers la même mémoire.

Pourquoi l’auteur il écrit comme ça ? Pourquoi n’utilisent-ils pas this.segments directement ? Y a-t-il une raison ?

Answer 1

C'est une expression typique de code sans verrouillage impliquant volatile variables. À la première ligne que vous lisez l' volatile une fois et ensuite travailler avec elle. En attendant qu'un autre thread puisse mettre à jour l' volatile, mais vous êtes uniquement intéressé par la valeur que vous avez d'abord lire.

En outre, même lorsque la variable de membre en question n'est pas volatile mais au final, cet idiome a à faire avec des caches CPU que la lecture à partir d'un emplacement de pile est plus de cache-friendly que la lecture à partir d'un tas aléatoires emplacement. Il y a aussi plus de chance que le local var finirez lié à un PROCESSEUR inscrire.

Pour ce dernier cas, il existe effectivement une certaine controverse, puisque le compilateur JIT sera généralement prendre soin de ces préoccupations, mais Doug Lea est l'un des gars qui s'accroche sur le principe général.

Answer 2

Je suppose que c'est pour la performance de la considération, de sorte que nous avons seulement besoin de récupérer la valeur du champ une fois.

Vous pouvez vous référer à un singleton idiome de efficace java par Joshua Bloch

Son singleton est ici:

private volatile FieldType field;
FieldType getField() {
  FieldType result = field;
  if (result == null) { 
    synchronized(this) {
      result = field;
      if (result == null) 
        field = result = computeFieldValue();
    }
  }
  return result;
}

et il a écrit:

Ce code peut paraître un peu compliqué. En particulier, la nécessité pour l' variable locale résultat peut être incertaine. Ce que cette variable n'est à s'assurer que le champ est en lecture seule fois dans le cas courant où il est déjà initialisé. Bien que pas strictement nécessaire, ce qui peut améliorer la performance et est plus élégant par les normes appliquées à bas niveau la programmation simultanée. Sur ma machine, la méthode ci-dessus est d'environ 25 pour cent plus rapide que l'évidence de la version sans une variable locale.

Answer 3

Il peut réduire la taille du code octet - accéder à une variable locale est plus courte en byte-code que l’accès à une variable d’instance.

Frais généraux de la Runtime optimisation peut être réduit trop.

Mais aucun d'entre eux sont significatifs. C’est plus sur le style de code. Si vous vous sentez à l’aise avec les variables d’instance, par tous les moyens. Doug Lea probablement se sentir plus à l’aise traitant des variables locales.