L'avenir.get() est interrompu toujours avec une InterruptedException
J'ai un problème BIZARRE avec l'Avenir.get() en Java. Il retourne toujours avec une InterruptedException, cependant la chose étrange est que la cause de l'Exception est nulle, donc je ne peux pas dire qui m'a interrompu..
C'est même encore pire car je vérifier avant l'appel de get(), et l'emploi d'Avenir a à faire est déjà fait.
Voici le code responsable de la sortie ci-dessous. f est l'Avenir, et le callable retourne une table de hachage où l'Agent n'est pas vraiment pertinent. Désolé si il y a trop d'printlines, j'essaie juste de donner de la bouillie d'info que je peux. L'appel de méthode à partir de appelable est pour l'instant un simple System.out.println("Hola soy agente")
qui comme vous le verrez, est imprimé, ce qui signifie que le callable ne suis pas la cause de l'exception, soit
Voici le code:
try
{
System.out.println(f.isDone()); //true
System.out.println(f.isCancelled()); //false
System.out.println(f.toString()); //FutureTask
newModdedAgents.putAll(f.get());
}catch(InterruptedException e)
{
System.out.println(f.isDone()); //true
System.out.println(f.isCancelled()); //false
System.err.println(e); //It is an interruptedException
System.err.println(e.getCause()); //???? null?
e.printStackTrace();
}
Et la sortie
Hola soy agente
true
false
java.util.concurrent.FutureTask@1c4c94e5
true
false
java.lang.InterruptedException
null
java.lang.InterruptedException
at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1302)
at java.util.concurrent.FutureTask$Sync.innerGet(FutureTask.java:248)
at java.util.concurrent.FutureTask.get(FutureTask.java:111)
at com.pf.simulator.Simulation.simulateStep(Simulation.java:217)
at com.pf.gui.ButtonPanel.doWork(ButtonPanel.java:141)
at com.pf.gui.ButtonPanel$1$1.construct(ButtonPanel.java:198)
at com.pf.gui.SwingWorker$2.run(SwingWorker.java:117)
at java.lang.Thread.run(Thread.java:636)
Dans le cas où vous souhaitez voir où j'en faites la appelable pour le pool de threads... alors ce serait le code pour qu'il
for(Callable<HashMap<Integer, Agent>> c : agentCallables)
{
Future<HashMap<Integer,Agent>> future = pool.submit(c);
agentFutureSet.add(future);
}
et ensuite j'ai effectuer une itération sur ce Jeu avec
for(Future<HashMap<Integer, Agent>> f : agentFutureSet)
try
{
//Here goes the code at the beginning
OriginalL'auteur dgrandes | 2010-11-24
Vous devez vous connecter pour publier un commentaire.
Avez-vous vérifié le fil d'interruption du drapeau avant d'appeler
get()
? Vous pouvez faire cela avecThread.currentThread().isInterrupted()
.Pour plus d'info regardez la javadoc de L'avenir.get() de voir pourquoi il lancerait une InterruptedException.
Vous pouvez voir pourquoi en regardant la javadoc pour l'Avenir, ici: download.oracle.com/javase/1.5.0/docs/api/java/util/concurrent/... obtenir jette un
InterruptedException
"si le thread courant a été interrompu lors de l'attente"Fait assez incroyable, je suis allé à cette page de nombreuses fois avant de poster ici, et en quelque sorte mon cerveau juste n'a pas connecter que le thread en attente a été! Drôle parce que quelqu'un d'autre a eu la même idée fausse et je leur ai expliqué la même chose après la lecture de la documentation SOIGNEUSEMENT ce moment. Il a été un plaisir de le premier affichage de l'expérience à stackoverflow!
OriginalL'auteur daveb
Un nu -
InterruptedException
être levée à partir de.get()
indique que le thread en cours d'exécution (le thread appelant.get()
) a été interrompu avant d'appelerget()
, ou alors bloqué dans.get()
. C'est pas la même chose que l'exécuteur testamentaire de fil ou de l'une de ses tâches d'être interrompu. Quelqu'un ou quelque chose est interrompre votre "main" thread -- ou au moins le thread appelant.get()
.Interruptions ne se produisent pas au hasard -- une partie du code a intentionnellement causer l'interruption. Une interruption peut seulement être initiée par un appel à
Thread.interrupt()
, mais il y a un peu de Java standard utilitaires qui font appel de cette derrière la scène, commeAvenir.annuler(true)
etExecutorService.shutdownNow()
.Autant que je sache, il n'y a pas de façon de extérieur de suivi de la "cause de la chaîne" ou "trace de la pile" de la cause de l'interruption. Vous devez regarder le code source pour déterminer où les interruptions peuvent être lancées, et donc en déduire ce que l'appel de méthode(s) sont à l'origine de l'interruption dans votre cas.
assez juste, je pense que vous comprenez totalement ce qui se passe maintenant. Bonne chance à vous, le multithreading, peut être affaire délicate! 🙂
OriginalL'auteur Mike Clark
La cause d'une Exception est un Throwable (un appel de méthode n'est pas une exception)
Le fil ne seront intrrupted si vous provoquer, il ne sera pas le fruit du hasard.
Si vous n'avez vraiment aucune idée de l'endroit où l'interruption est en provenance et à vouloir l'ignorer, vous pouvez l'effacer en premier. appel
Thread.interrupted()
De toute façon, vous avez raison!
OriginalL'auteur Peter Lawrey
Cela est révélateur de la thread exécutant le soumis devient Exigible interrompu. Cela pourrait être un legimate interruption (par exemple si le
Callable
effectue une opération de blocage tels que le Thread.le sommeil et est interrompu explicitement viaThread.interrupt()
), ou il pourrait être que leExecutorService
(en supposant que vous êtes en utilisant ce) est en cours de fermeture par l'intermédiaire d'un appel àshutDownNow()
.Pouvez-vous s'il vous plaît poster le code utilisé pour créer votre pool de threads avec votre
Callable
mise en œuvre?Pressé d'entrer accidentellement, désolé, le service est assez simple privés ExecutorService piscine = Exécuteurs testamentaires.newCachedThreadPool(); Comme répondu avant, le problème était que la currentThread, la soumission de la callables, a été interrompu. À la lecture de la documentation soigneusement, il est dit: "InterruptedException - si le thread courant a été interrompu lors de l'attente". Ce qui fait sens avec ce qui s'est passé, parce que le thread courant est en une interruption de l'état avant de commencer et que le thread est celui qui est en attente pour la réponse, et pas le subitted appelable fil...je pense.
OriginalL'auteur Adamski