78 votes

Dans ArrayBlockingQueue, pourquoi copier dernier membre de champ dans la dernière variable?

En ArrayBlockingQueue, toutes les méthodes qui nécessitent la serrure de le copier à un local final variable avant de l'appelant 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();
    }
}

Est-il une raison pour copier this.lock d'une variable locale lock lorsque le champ this.lock est final?

En outre, il utilise également une copie locale de l' 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;
}

Est-il une raison pour la copie d'un champ final d'un local définitif variable?

64voto

ColinD Points 48573

C'est à l'extrême, une optimisation de Doug Lea, l'auteur de la classe, aime à utiliser. Voici un post sur un récent fil sur le core-libs-dev mailing list sur ce sujet précis qui répond à votre question plutôt bien.

du poste:

...de la copie pour les habitants qui génère la plus petite bytecode, et pour les bas-niveau code c'est agréable d'écrire le code c'est un peu plus proche de la machine

11voto

assylias Points 102015

Ce fil donne quelques réponses. En substance:

  • le compilateur ne peut pas prouver facilement qu'un champ final ne change pas à l'intérieur d'une méthode (en raison de réflexion / de sérialisation etc.)
  • la plupart des compilateurs gcc fait de ne pas essayer et aurait donc pour recharger le dernier champ, chaque fois qu'il est utilisé, ce qui pourrait conduire à une cache ou un défaut de page
  • de le stocker dans une variable locale des forces de la JVM pour effectuer une seule charge

9voto

James Kingsbery Points 3460

C'est une excellente question, je la regardais ArrayBlockingQueue et je me demandais la même chose moi-même. J'ai un plus en profondeur sur la réponse pourquoi le byte-code est plus compact ici pour quiconque est curieux:

http://kingsbery.net/2010/06/02/bytecode-analysis-of-arrayblockingqueue/

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X