Dans ArrayBlockingQueue, pourquoi copier le champ du membre final dans la variable finale locale?

Question

Dans ArrayBlockingQueue, toutes les méthodes nécessitant le verrouillage le copient dans une variable locale final avant d'appeler lock().

public boolean offer(E e) { 
    if (e == null) throw new NullPointerException(); 
    final ReentrantLock lock = this.lock; 
    lock.lock(); 
    try { 
     if (count == items.length) 
      return false; 
     else { 
      insert(e); 
      return true; 
     } 
    } finally { 
     lock.unlock(); 
    } 
} 

Y at-il raison de copier this.lock à une variable locale lock lorsque le champ this.lock est final?

De plus, il utilise également une copie locale de E[] avant d'agir sur elle:

private E extract() { 
    final E[] items = this.items; 
    E x = items[takeIndex]; 
    items[takeIndex] = null; 
    takeIndex = inc(takeIndex); 
    --count; 
    notFull.signal(); 
    return x; 
} 

Y at-il raison de la copie d'un champ final à une variable finale locale?

Answer 1

C'est une optimisation extrême que Doug Lea, l'auteur de la classe, aime utiliser. Voici un post sur a recent thread sur la liste de diffusion core-libs-dev à propos de ce sujet précis qui répond assez bien à votre question.

du poste:

... La copie à la population locale produit le plus petit bytecode, et pour le code de bas niveau, il est agréable d'écrire du code qui est un peu plus proche de la machine

Answer 2

This thread donne quelques réponses. En substance:

• le compilateur ne peut pas prouver facilement qu'un champ final ne change pas dans une méthode (en raison de la réflexion, etc./sérialisation)
• la plupart des compilateurs actuels n'essayez pas réellement et aurait donc pour recharger le dernier champ à chaque fois qu'il est utilisé qui pourrait conduire à un manque de cache ou d'un défaut de la page
• stocker dans une variable locale oblige la machine virtuelle Java pour effectuer une seule charge