Je travaille sur une application pour le J2ME et parfois il gèle complètement et il faut assez de temps pour le SMS pour le fermer . Il me semble qu'un problème de verrouillage mort.
Pourriez-vous me conseiller sur ce qui pourrait causer des verrous morts? Serait, par exemple, appeler une méthode synchronisée d'un objet causer une serrure morte si elle appelle une autre méthode synchronisée à sa propre?
merci!
Ai-je raison de dire qu'une impasse est censée se produire dans le cas suivant:
objet Désolé si ça a l'air stupide de moi, probablement c'est. Mais c'est pourquoi je demande. Merci!
4 Réponses :
serait, par exemple, appeler une méthode synchronisée d'un objet entraîne une serrure morte si elle appelle une autre méthode synchronisée à sa propre? p>
Non, car
Synchronisé code> Les serrures en Java sont réentrant em>: vous pouvez acquérir le même verrou de la même thread plusieurs fois sans problème. P>Une impasse se produit par exemple Lorsque le thread a tient la serrure L et tente d'acquérir le verrouillage M, tandis que le fil b contient le verrouillage M et tente d'acquérir la serrure L. Ainsi, les deux threads attendent une serrure détenue par l'autre et ne peuvent pas progresser pour libérer leur propre verrou. Cela provoque des deux threads d'attendre pour toujours. La situation peut également impliquer plus de 2 threads. P>
Deadlocks peut être très difficile à détecter, de sorte que la manière typique est d'essayer de éviter em> eux par une conception minutieuse. Le moyen le plus simple d'y parvenir est de garantir que tout fil qui doit acquérir plusieurs serrures, les acquiert toujours dans le même ordre mondial prédéfini. Par exemple. Si dans l'exemple ci-dessus, les threads A et B tentent d'acquérir la serrure L d'abord, puis verrouillez-la, il n'y aura pas d'impasse. P>
Votre problème peut également être causé par d'autres choses que celles-ci. Un Livelock em> (lorsqu'un thread, sans bloqué, ne peut toujours pas progresser car il continue de réessayer une opération qui échoue toujours). P>
Mise à jour: accéder au verrou de l'extérieur de l'objet h3>
avec des serrures intrinsèques Java (c.-à-d.
Synchronisée des blocs code> Synchronisés), l'objet sous-jacentLock code> n'est pas visible dans le code, seul l'objet que nous verrouillons . Considérez P>class MyClass { private Object object = new Object(); public synchronized void synchronizedOnThis1() { ... } public void synchronizedOnThis2() { synchronized(this) { ... } } public void synchronizedOnPrivateObject() { synchronized(object) { ... } } } class ExternalParty { public void messUpLocks() { final MyClass myObject = new MyClass(); synchronized(myObject) { Thread otherThread = new Thread() { public void run() { myObject.synchronizedOnThis1(); } }; otherThread.start(); // do a lengthy calculation - this will block the other thread } } }
Voulez-vous dire que toutes les méthodes synchronisées d'un objet utiliseraient la même serrure afin qu'aucun verrou de mort ne soit possible pour survenir?
@Albus, déclarant une méthode synchronisée équivaut à joindre le contenu de la méthode dans un synchronisé (this) bloc. C'est à dire. Toutes les méthodes d'instance Synchronisées sont synchronisées sur la même instance de classe, aucune impasse n'est possible. À moins que, bien sûr, une autre personne en dehors de l'objet se verrouille sur le même objet.
"Sauf si, bien sûr, une autre personne en dehors de l'objet se verrouille sur le même objet." Eh bien, on ne peut pas faire cela si l'objet verrouillé n'est pas exposé manuellement par moi, peut-on un ?! C'est-à-dire que si toute la synchronisation est faite par des méthodes synchronisées, il n'y a pas de danger ce type?
@Albus: Non, ce n'est pas le cas - "Quelqu'un d'autre en dehors de l'objet verrouille sur le même objet" signifie une personne en dehors d'un myClass MODY appels myClass FOO = nouveau myClass (); ... synchronisé (foo) {...}
Merci beaucoup! Donc, diriez-vous que l'utilisation d'objets privés comme une serrure serait une approche plus sûre que le synchronisé (this) un? Si oui, serait-ce une préoccupation de conception, si je synchrais toujours toute la source de la méthode car il y a beaucoup de choses à mettre à jour?
@Albus, il est théoriquement plus sûr, bien que cela rend le code un peu plus compliqué. Le code bien écrit ne devrait pas contenir de tels serrures problématiques, c'est donc plus une question de style (ou paranoïa :-) le seul cas où j'utiliserais certainement cet idiome est une bibliothèque publique où je n'ai aucun contrôle sur le code client.
@Albus, lors de la synchronisation de l'ensemble du corps de la méthode, la plus grande préoccupation est de la durée de l'exécution. Les serrures de longue date augmentent les chances de filtrait de fil et peuvent donc ralentir l'exécution de manière significative, pour le moins. S'il faut utiliser un synchronisé (someObject) bloc ou un Synchronisé est une préoccupation mineure pour moi dans ce contexte.
Eh bien, les deux dernières réponses sont en fait assez évidentes, quand je viendrai penser, mais pour eux, je me sens plus confiant dans ma pensée. Merci! Même si je ne peux toujours pas signaler le problème: j'ai un Canvas et les événements externes l'accédent via des méthodes synchronisées de cette toile. Donc, après tout dit, il ne peut pas être éventuellement une impasse, non?
@Albus, si vous n'avez qu'une seule serrure dans le jeu, il ne peut pas y avoir de blocage. Notez toutefois que des serrures cachées peuvent être impliquées dans les appels de bibliothèque, en particulier lorsque l'interface graphique est impliquée. Je ne sais pas J2ME donc je ne peux rien dire de rien spécifique à ce sujet. Je vous suggère d'ouvrir une nouvelle question et de montrer la partie pertinente de votre code - il y a sûrement des experts J2ME ici :-)
La raison la plus probable serait deux threads essayant d'obtenir des serrures à deux objets. Le fil 1 verrouille A et attend que B, mais filetez 2 verrouillons B et attendez A. Les deux threads finissent par attendre pour toujours pour des objets qui ne seront jamais libérés.
Il n'y a pas de solution rapide, sauf que votre code fait des choses dans un ordre très bien défini. En règle générale, le bloc synchronisé doit être aussi petit que possible, généralement sur un objet spécifique que sur une méthode. Mettez beaucoup de journalisation et voyez si vous pouvez déterminer si quelque chose comme ça se passe.
Java 5 a des objets de verrouillage explicites qui permettent un contrôle grain fini comprenant des délais d'attente sur des blocs synchronisés simples, mais je ne sais pas s'ils seraient utiles pour J2ME. Il existe une backport des libs de la concurrence Java 5 qu'il peut être possible de travailler avec J2ME - http: // Backport-jsr166.sourceforge.net/ Si ce problème est suffisamment important pour le mériter.
Oui merci! J'espère que ça ne va pas arriver à cela. Après tout, le bon et le code simple est toujours la meilleure solution.