Java.lang.IllegalMonitorStateException: Objekt nicht durch Thread gesperrt vor warten ()?

Ich benutze Fortschrittsdialog. Ich muss den Thread stoppen, wenn der Benutzer den Fortschrittsdialog schließt. Leider gibt es Ausnahme pls mir helfen ..

In der inneren Klasse

  • ClassNotFoundException bei Verwendung von benutzerdefiniertem Parcelable
  • Ist es möglich, eine Zeichnung in der XML-Beschreibung zu drehen?
  • Hinzufügen von Icons zu PreferenceScreen-Einträgen
  • PointerIndex out of range Android Multitouch
  • Implementierung von IntentService mit LinkedBlockingQueue?
  • Android NDK - schreiben Sie nur in C / C ++
  • class UpdateThread extends Thread{ public void run() { while (true){ count=adapter.getCount(); try { mHandler.post( new Runnable() { public void run() { Log.i(TAG,count+"count"); progressDialog.setMessage(count + "Device found"); } }); Thread.sleep(300); } catch (InterruptedException e) { e.printStackTrace(); } } } } 

    Ankreuzen

      updateThread=new UpdateThread(); progressDialog= new ProgressDialog(GroupListActivity.this); synchronized (this) { updateThread.start(); } 

    Ondismissal

      progressDialog.setOnDismissListener(new DialogInterface.OnDismissListener() { @Override public void onDismiss(DialogInterface dialog) { try { synchronized (this) { updateThread.wait(300); } } catch (InterruptedException e) { e.printStackTrace(); } Log.i(TAG,"Thread is stopped"); } }); 

  • Android: Intent.ACTION_SEND mit EXTRA_STREAM fügt kein Bild bei der Auswahl von Gmail App auf htc Hero
  • Wie benutzt man Traceview in Eclipse für Android-Entwicklung?
  • Android: Wie benutzt man AlarmManager?
  • Android Change Navigation Ansicht Menü Hintergrund
  • Erklären Sie die Bedeutung von Span-Flags wie SPAN_EXCLUSIVE_EXCLUSIVE
  • Ist das möglich zu überprüfen war onCreate genannt wegen der Orientierung ändern?
  • 3 Solutions collect form web for “Java.lang.IllegalMonitorStateException: Objekt nicht durch Thread gesperrt vor warten ()?”

    Das ist falsch:

     synchronized(foo) { foo.wait(); } 

    Das Problem ist, was wird diesen Thread aufwachen? Das heißt, wie garantieren Sie , dass der andere Thread nicht foo.notify() bevor der erste Thread ruft foo.wait() ? Das ist wichtig, weil das foo-Objekt sich nicht erinnern wird, dass es benachrichtigt wurde, wenn der Benachrichtigungsaufruf zuerst geschieht. Wenn es nur eine Benachrichtigung () gibt und wenn es vor dem Warten () passiert, dann wird das Warten () niemals zurückkehren.

    Hier ist, wie Wartezeit und Benachrichtigung verwendet werden sollen:

     private Queue<Product> q = ...; private Object lock = new Object(); void produceSomething(...) { Product p = reallyProduceSomething(); synchronized(lock) { q.add(p); lock.notify(); } } void consumeSomething(...) { Product p = null; synchronized(lock) { while (q.peek() == null) { lock.wait(); } p = q.remove(); } reallyConsume(p); } 

    Die wichtigsten Dinge, die in diesem Beispiel zu beachten sind, sind, dass es einen expliziten Test für die Bedingung gibt (dh q.peek ()! = Null), und dass niemand den Zustand ändert, ohne das Schloss zu sperren.

    Wenn der Verbraucher zuerst angerufen wird, dann wird er die Warteschlange leer finden, und es wird warten. Es gibt keinen Moment, in dem der Produzent einrutschen kann, füge ein Produkt in die Warteschlange ein und benachrichtige das Schloss, bis der Verbraucher bereit ist, diese Benachrichtigung zu erhalten.

    Auf der anderen Seite, wenn der Produzent angerufen wird, dann ist der Verbraucher garantiert nicht anrufen warten ().

    Die Schleife im Verbraucher ist aus zwei Gründen wichtig: Eines davon ist, wenn es mehr als einen Verbraucherfaden gibt, dann ist es möglich, dass ein Verbraucher eine Benachrichtigung erhält, aber dann schleicht sich ein anderer Verbraucher ein und stiehlt das Produkt aus der Warteschlange. Die einzige vernünftige Sache für die Faust Verbraucher in diesem Fall zu tun ist wieder für das nächste Produkt warten. Der andere Grund, dass die Schleife wichtig ist, ist, dass der Javadoc sagt, dass Object.wait () zurückgegeben werden darf, auch wenn das Objekt nicht benachrichtigt wurde. Das heißt ein "falscher Wakeup", und der richtige Weg, um damit umzugehen ist, zurückzukehren und wieder zu warten.

    Beachten Sie auch: Das Schloss ist private und die Warteschlange ist private . Das garantiert, dass keine andere Kompilierungseinheit die Synchronisation in dieser Kompilierungseinheit stören wird.

    Und beachten: Das Schloss ist ein anderes Objekt aus der Warteschlange selbst. Das garantiert, dass die Synchronisation in dieser Zusammenstellungseinheit nicht mit der Synchronisation interferieren wird, die die Warteschlangenimplementierung (falls vorhanden) ausführt.


    HINWEIS: Mein Beispiel erfindet ein Rad, um einen Punkt zu beweisen. In echten Code, würden Sie die put () und take () Methoden einer ArrayBlockingQueue verwenden, die sich um all das Warten und Benachrichtigen für Sie kümmern würde.

    Sie können nur auf ein Objekt warten, wenn Sie bereits die Sperre daran haben, könnten Sie versuchen:

     synchronized (updateThread) { updateThread.wait(300); } 

    … aber ich bin nicht wirklich sicher, was du mit den Schlössern zu erreichen versuchst.

    Es sieht wirklich so aus, als würdest du versuchen, synchronized zu benutzen und zu wait wo du nicht sein solltest.

    Wenn du wirklich auf den Faden warten willst, solltest du so etwas machen

    In deinem UpdateThread :

     class UpdateThread extends Thread{ public AtomicBoolean stopped = new AtomicBoolean(false); public void run() { while (!stopped.get()){ ..... 

    In deiner Schöpfung:

     updateThread = new UpdateThread(); progressDialog = new ProgressDialog(GroupListActivity.this); updateThread.start(); // no synchronization necessary 

    In deiner Entlassung:

     progressDialog.setOnDismissListener(new DialogInterface.OnDismissListener() { @Override public void onDismiss(DialogInterface dialog) { try { updateThread.stopped.set(true); updateThread.join(300); } catch (InterruptedException e) { e.printStackTrace(); } Log.i(TAG,"Thread is stopped"); } }); 

    Beachten Sie, ich habe eine Exit-Bedingung zu Ihrem Thread, so dass es tatsächlich aufhören (wie ist, wird Ihr Thread weiter gehen). Du hättest wahrscheinlich den Ausstiegszustand privat machen und einen Setter für Sauberkeit hinzufügen. Auch bin ich mit join um richtig warten auf Ihren Thread zu vervollständigen.

    Das Android ist ein Google Android Fan-Website, Alles ├╝ber Android Phones, Android Wear, Android Dev und Android Spiele Apps und so weiter.