2011-12-25 4 views
0

C'est une question vraiment étrange, et je ne peux pas pour la vie de moi comprendre ce qui ne va pas.La variable agit différemment selon la position du point d'arrêt

j'ai deux tableaux de chaînes, déclarées dans la partie supérieure de la classe:

String[] artistsURLIndexArray; 
String[] artistsOnlyArray; 

Ils sont tous les deux mis à jour dans un fil séparé (travailleur d'arrière-plan) qui est exécuté dans le procédé onCreate. Je vois dans le débogage que tout fonctionne, et les tableaux sont correctement mis à jour.

Après le fil de fond, j'ai le code suivant (toujours dans la méthode onCreate):

String[] test; 

if(artistsOnlyArray == null) // point A 
{ 
    test = new String[] { "empty...", "asd" }; // point B 
} 
else 
{   
    test = new String[] { "not empty!", "asd" }; // point C 
} 

Maintenant, quand je viens 'run' l'application (pas debug), test[0] est « vide ... ". Autrement dit, le artistsOnlyArray est nul! Cela ne devrait pas être le cas. (Btw, je teste le tableau test visuellement avec un listview.)

Si je vais de l'avant et placez un point d'arrêt au point B et je débogue l'application, l'application s'arrête ici. Ceci est attendu bien sûr, vu qu'il prétend que le artistsOnlyArray est nul.

Si je place un point d'arrêt au point C à la place, le point d'arrêt n'est pas atteint. Correcte aussi'.

Si je place un point d'arrêt au point A, cependant, tout change. Le point d'arrêt est atteint bien sûr, et maintenant il doit vérifier si le tableau est nul. Je presse F8 pour reprendre (j'utilise Eclipse), et soudain, test[0] est "pas vide!". Je peux également voir que le artistsOnlyArray est correct (pas nul).

Pourquoi l'apparence (et la position) d'un point d'arrêt est-elle à l'origine de ce comportement?

+0

Il semble que votre thread d'arrière-plan soit en cours d'exécution avant ou après le code oncreate en fonction du point d'arrêt. Normalement, le nouveau thread ne démarrera pas tant que votre thread ne produira pas. Le débogueur provoque le rendement de votre thread principal et donne donc au thread une chance de s'exécuter. – BitBank

Répondre

1

Je peux seulement supposer cela est à cause de la « temps supplémentaire » le thread de travail a lorsque vous placez un point d'arrêt au point A.

Lorsque vous ne placez aucun point d'arrêt, l'exécution de l'instruction if passe avant n'importe quel thread de travail remplit le tableau, et il entre ainsi sur le if. Par contre, lorsque vous placez un point d'arrêt au point A, vous donnez le temps au thread de travail de remplir le tableau. Ainsi, au moment où vous continuez le tableau est déjà rempli et il entre dans le else.

+0

Est-il possible de vérifier quand le thread d'arrière-plan est fait, puis faire la phrase if (et autre) après? – eightx2

+0

Si vous utilisez la classe 'Thread', vous pouvez utiliser' join() '. Docs: http://docs.oracle.com/javase/1.5.0/docs/api/java/lang/Thread.html # rejoindre% 28% 29 –

+0

Merci, ça marche! – eightx2

0

Vous avez répondu vous-même: "Ils sont mis à jour dans un thread séparé".

Le point d'arrêt peut provoquer une condition de "course", dans laquelle la synchronisation relative des threads est perturbée. Plus précisément, le thread de mise à jour peut ou ne peut pas être bloqué avant que le point d'arrêt se produise.

Questions connexes