9
votes

Veuillez expliquer la sortie des méthodes d'exécution du thread () et de démarrage ()

Veuillez expliquer la sortie du code ci-dessous:

si j'appelle th1.run () code>, la sortie est: p> xxx pré>

Si j'appelle th1.start () code>, la sortie est la suivante: p> xxx pré>

pourquoi cette incohérence? S'il vous plaît expliquer. P>

class ThreadExample extends Thread{
    public void run() {
        System.out.println("EXTENDS RUN>>");
    }
}

class ThreadExampleRunnable implements Runnable {
    public void run() {
        System.out.println("RUNNABLE RUN>>");
    }
}

class ThreadExampleMain{
    public static void main(String[] args) {
        ThreadExample th1 = new ThreadExample();
        //th1.start(); 
        th1.run();

        ThreadExampleRunnable th2 = new ThreadExampleRunnable();
        th2.run();
    }
}


0 commentaires

4 Réponses :


8
votes

the thread.start () code> La méthode démarre un nouveau thread, le point d'entrée de ce thread est la méthode Exécuter () code>. Si vous appelez directement (), il s'exécutera dans le même fil. Étant donné que l'appelant thread.start () code> démarrera un nouveau thread d'exécution, la méthode exécutée () code> peut être appelée après (comme dans vous exemple) le reste de la principale Méthode exécute.

Changez votre méthode principale pour appeler th1.start () code> et exécuté à plusieurs reprises, vous verrez que parfois il sortira: p>

RUNNABLE RUN >>
EXTENDS RUN>>


1 commentaires

J'essayais de comprendre pourquoi mon multithreading à Android n'a pas fonctionné. S'avère que j'ai toujours appelé exécuté () au lieu de start () .



0
votes

Lorsque vous appelez .Run () , la méthode est appelée et le code dans l'exécution de la même manière que toute autre méthode. Si vous appelez .start () sur un thread, cependant, la méthode exécutée () sera exécutée dans ce fil et non séquentiellement dans le fil principal.

Alors, lorsque vous appelez th1.start () , vous avez l'exécution de code dans deux threads à la fois: le fil principal passera à la création de TH2, puis appelle son exécuter Méthode, tandis que le thread th1 appellera sa propre méthode exécuter . Il n'y a aucune garantie sur la commande de ceux-ci, car ils s'exécutent en parallèle.


0 commentaires

3
votes

Lorsque vous appelez th1.run () Vous exécutez la méthode exécuter dans le thread actuel, il doit donc arriver avant d'appeler sur th2.run ( ) .

Lorsque vous appelez th1.start () vous la méthode exécuter est appelée sur un nouveau fil. Dans ce cas, il se passe après l'appel à th2.run () . (En fait, il est théoriquement possible que cela puisse arriver avant le th2.run () ... mais des implémentations de soleil actuelles et précédentes de thread.start () ne pas provoquer le thread actuel immédiatement "céder" au nouveau fil.)

Cela illustre une erreur commune avec les fils Java. Si vous souhaitez exécuter des trucs sur un nouveau fil, vous devez appeler thread.start () . Appeler directement thread.run () est presque toujours une erreur.


0 commentaires

0
votes

exécution exécution () est synchrone - exécution start () est asynchrone.

Les appels vers Exécuter () sont juste un appel de méthode synchrone régulier, et ils se produisent dans cet ordre. Utilisation de TH1.START () , un nouveau thread est démarré - il est maintenant un rase à deux chevaux - les deux méthodes d'exécution exécutant actuellement de manière indépendante - première à la finition gagne et il n'y a aucune garantie à propos de la commande .

Mais si la commande n'est pas garantie, pourquoi le nouveau thread imprimait-il plus tard la plupart du temps? En pratique, il faut du temps pour démarrer un nouveau fil, alors au moment de son démarrage, l'autre exécuté () a déjà couru. Même sur une machine multi-noyau, où les deux threads peuvent exécuter simultanément, le nouveau thread sera généralement venu en dernier, car le démarrage du fil implique plus de travail.


0 commentaires