Ne “rien”, alors que “condition”

ForkJoinPool fait un usage intensif de compareAndSwap... de sun.misc.Unsafe et la plupart des occurrences de do {} while (...) dans ForkJoinPool peut — comme mentionné par d'autres réponses — être expliqué par ce commentaire sous la rubrique Style notes:

* There are several occurrences of the unusual "do {} while
* (!cas...)"  which is the simplest way to force an update of a
* CAS'ed variable. 

Le choix de l'utilisation d'écrire un while-boucle dont le corps est vide comme do {} while (condition) semble cependant être un surtout stylistique choix. C'est peut-être plus clair dans HashMap, ce qui est arrivé à être mis à jour en Java 8.

Dans Java 7 HashMap vous pouvez trouver ceci:

while (index < t.length && (next = t[index++]) == null)
    ;

Bien que le code autour d'elle aussi a changé, il est clair que le remplacement, dans Java 8 est-ce:

do {} while (index < t.length && (next = t[index++]) == null);

La première version a la faiblesse que si le seul point-virgule qui est arrivé à être supprimé, il serait de changer le sens du programme en fonction sur la ligne suivante.

Comme on le voit ci-dessous, le bytecode généré par while (...) {} et do {} while (...); est légèrement différente, mais pas de la façon qu'devrait influer sur quoi que ce soit quand exécuter.

De code Java:

class WhileTest {
    boolean condition;

    void waitWhile() {
        while(!condition);
    }

    void waitDoWhile() {
        do {} while(!condition);
    }
}

Code généré:

class WhileTest {
  boolean condition;

  WhileTest();
    Code:
       0: aload_0       
       1: invokespecial #1                  //Method java/lang/Object."<init>":()V
       4: return        

  void waitWhile();
    Code:
       0: aload_0       
       1: getfield      #2                  //Field condition:Z
       4: ifne          10
       7: goto          0
      10: return        

  void waitDoWhile();
    Code:
       0: aload_0       
       1: getfield      #2                  //Field condition:Z
       4: ifeq          0
       7: return        
}

Si vous allez lire le commentaire ci-dessus le code, Il est mentionné que...

Si l'appelant n'est pas un ForkJoinTask, cette méthode est sur le plan comportemental équivalent à

while (!blocker.isReleasable())
   if (blocker.block())
      return;
}

C'est juste une autre forme pour mettre en œuvre le code ci-dessus dans le reste de la partie...!!

Dans Style notes il est mentionné que,

Il y a plusieurs occurrences de l'insolite "do {} while
(!sae...)", ce qui est la façon la plus simple de forcer une mise à jour d'un
SAE ed variable.

Et si vous allez voir la mise en œuvre de ManagedLocker#isReleasable, C'est la mise à jour de la serrure et retourne true si le blocage est inutile.

Interprétation :

Vide tandis que les boucles sont utilisées pour fournir une interruption jusqu'à ce qu'une certaine condition de réinitialisation de vrai/faux.

Ici, do { } while(!...) est un bloqueur/interruption jusqu'à ce blocker.block() sera true quand blocker.isReleasable() est false. Boucle continuera de l'exécution en blocker n'est pas libérable (!blocker.isReleasable()) et blocker n'est pas bloqué !! L'exécution de la boucle dès que blocker.block() sera définie sur true.

Noter que, do{ } while(...) n'est pas le CAS de la variable, mais il garantit que le programme va attendre jusqu'à ce que la variable est mise à jour (force d'attendre jusqu'à ce que la variable est mise à jour).