Wie behandeln :java.util.gleichzeitige.TimeoutException: android.os.BinderProxy.finalize() timed out nach 10 Sekunden-Fehler?

Vollständige Offenlegung - ich bin der Autor des zuvor erwähnten Rede in TLV DroidCon.

Hatte ich die chance mit diesem Thema zu befassen, das über viele Android-Anwendungen, und diskutieren Sie mit anderen Entwicklern, traf Sie - und wir alle haben uns an den gleichen Punkt: dieses Problem kann nicht vermieden werden, nur minimiert.

Nahm ich einen genaueren Blick auf die default-Implementierung der Android-Garbage collector-code, um besser zu verstehen, warum diese Ausnahme wird Ausgelöst, und auf was könnten die möglichen Ursachen. Ich fand sogar eine mögliche Ursache während der versuchsdurchführung.

Die Wurzel des Problems ist an der Stelle ein Gerät "Schlafen Geht" für eine Weile - das bedeutet, dass das OS entschieden hat, senken Sie den Verbrauch der Batterie durch beenden die meisten Nutzer Land-Prozesse für eine Weile, und drehen Bildschirm aus, die Verringerung der CPU-Zyklen, etc .. Die Art und Weise dies erfolgt ist - ist auf einem Linux-system-Ebene, wo die Prozesse werden Angehalten Mitte laufen. Dies kann passieren, zu jeder Zeit während der normalen Ausführung der Anwendung, aber es wird aufhören, an einem Nativen system nennen, da die Kontext-Umschaltung erfolgt auf der kernel-Ebene. So - dies ist, wo der Dalvik GC tritt in die Geschichte.
Die Dalvik GC-code (umgesetzt in der Dalvik-Projekt in den AOSP-Website) ist nicht ein komplizierter code. Der einfachste Weg ist es Arbeit ist abgedeckt in meiner DroidCon Folien. was ich nicht abdecken, ist die grundlegende GC Schleife an dem Punkt, wo der Sammler hat eine Liste der Objekte zu beenden (und zu zerstören). der loop-Logik auf der Basis vereinfacht werden können, wie diese:

1. nehmen starting_timestamp,
2. entfernen-Objekt für eine Liste von Objekten zu befreien,
3. release-Objekt - finalize() - und call-native destroy() wenn erforderlich,
4. nehmen end_timestamp,
5. berechnen (end_timestamp - starting_timestamp) und vergleichen Sie gegen einen hart codierten Wert für den timeout von 10 Sekunden,
6. wenn timeout erreicht hat - werfen Sie den concurrent.TimeoutException und kill den Prozess.

Jetzt betrachten Sie das folgende Szenario:

Anwendung entlang läuft, tut seine Sache. dies ist nicht ein Benutzer-orientierte Anwendung, die im hintergrund läuft. Während dieses hintergrund-Betrieb werden die Objekte erstellt, verwendet und gesammelt werden müssen, um Speicher freizugeben. Anwendung nicht die Mühe mit einer Wakelock - wie wird sich dies auf die Batterie negativ, und scheint unnötig. dies bedeutet, dass die Anwendung ruft die GC von Zeit zu Zeit. Normalerweise wird der GC-Läufe abgeschlossen ist, ohne eine Anhängevorrichtung. Manchmal (sehr selten) das System wird entscheiden, Schlafen in der Mitte der GC laufen. Das wird passieren, wenn Sie Ihre Anwendung ausführen, die lange genug, und überwachen Sie den Dalvik-Speicher Protokolle genau. Nun - betrachten Sie die timestamp-Logik des basic-GC - Schleife, ist es möglich, das Gerät zu starten, die laufen, nehmen Sie eine start_stamp, und gehen Sie zu schlafen, die destroy() native Anruf auf ein system-Objekt. wenn es aufwacht und wieder den Lauf, der destroy() beendet, und die nächste end_stamp wird die Zeit, die die destroy() rufen Sie+die Zeit schlafen. Wenn der sleep-Zeit war lange, über 10 Sekunden, die gleichzeitige.timeout exception geworfen wird.

Habe ich gesehen, das in der generierten Diagramme aus der Analyse python-script - für-Android-System-Anwendungen, nicht nur meine eigenen überwachten apps. sammeln Sie genug Protokolle, Sie werden schließlich sehen.

Bottom line:

Das Problem nicht vermieden werden kann - Sie werden es feststellen, wenn die app im hintergrund läuft. Können Sie mildern, indem Sie eine wakelock, und verhindern, dass das Gerät vom schlafen, aber das ist eine andere Geschichte insgesamt, und eine neue Form von Kopfschmerzen, und vielleicht noch einen anderen Vortrag in einem anderen con.

Können Sie minimieren das problem durch Verringerung der GC-Anrufe - damit ist das Szenario weniger wahrscheinlich. Tipps sind in den Folien.

Habe ich noch nicht die chance hatte, zu gehen über die Dalvik 2 (ein.k.eine KUNST) GC-code - das bietet eine neue Generationen-Komprimieren-Funktion oder durchgeführt keine Experimente auf einem Android-Lollipop.

Hinzugefügt 7/5/2015:

Nach der überprüfung der Crash-Berichte aggregation für diesen Absturz geben, es sieht aus wie diese Abstürze von version 5.0+ Android-Betriebssystem (Lollipop mit KUNST) nur .5% dieser crash geben. Dies bedeutet, dass die KUNST-GC verpasst hat, reduziert sich die Häufigkeit dieser Abstürze.

Hinzugefügt 6/1/2016:

Sieht aus wie das Android-Projekt hat eine Menge von Informationen auf, wie der GC arbeitet in Dalvik 2.0 (ein.k.eine KUNST). Sie können darüber Lesen Sie hier - Debugging ART Garbage Collection
. Es beschreibt außerdem einige Werkzeuge, um Informationen auf der GC Verhalten für Ihre app. Senden Sie eine SIGQUIT, um Ihre app Prozess im wesentlichen wird eine ANR und dump, die den Zustand der Anwendung in einer log-Datei für die Analyse.

InformationsquelleAutor oba

Fand ich einige Folien zu diesem Thema.

http://de.slideshare.net/DroidConTLV/android-crash-analysis-and-the-dalvik-garbage-collector-tools-and-tips

In diesem gleitet der Autor sagt, dass es scheint ein problem mit der GC, wenn es eine Menge von Objekten oder riesige Objekte im heap. Die Folie umfassen auch einen Verweis auf eine Beispiel-app und einem python-Skript zu analysieren, dieses Problem.

https://github.com/oba2cat3/GCTest

https://github.com/oba2cat3/logcat2memorygraph

Außerdem fand ich einen Hinweis in Kommentar #3 auf dieser Seite: https://code.google.com/p/android/issues/detail?id=53418#c3

InformationsquelleAutor Christopher

Lösten wir das problem durch beenden der FinalizerWatchdogDaemon.

public static void fix() {
    try {
        Class clazz = Class.forName("java.lang.Daemons$FinalizerWatchdogDaemon");

        Method method = clazz.getSuperclass().getDeclaredMethod("stop");
        method.setAccessible(true);

        Field field = clazz.getDeclaredField("INSTANCE");
        field.setAccessible(true);

        method.invoke(field.get(null));

    }
    catch (Throwable e) {
        e.printStackTrace();
    }
}

Können Sie die Methode aufrufen, die in Anwendung des Lebenszyklus, wie attachBaseContext().
Aus dem gleichen Grund können Sie auch das Telefon herstellen, um das problem zu beheben, es ist bis zu Ihnen.

InformationsquelleAutor Enaoi

try {
    Class<?> c = Class.forName("java.lang.Daemons");
    Field maxField = c.getDeclaredField("MAX_FINALIZE_NANOS");
    maxField.setAccessible(true);
    maxField.set(null, Long.MAX_VALUE);
} catch (ClassNotFoundException e) {
    e.printStackTrace();
} catch (NoSuchFieldException e) {
    e.printStackTrace();
} catch (IllegalAccessException e) {
    e.printStackTrace();
}

InformationsquelleAutor kot32

Für Klassen, die Sie erstellen (dh. sind nicht Teil von Android) es ist möglich, zu vermeiden Absturz komplett.

Jede Klasse, die finalize() hat einige unvermeidliche Wahrscheinlichkeit, abzustürzen, wie beschrieben von @oba. Anstatt also mit Finalizer, um die Bereinigung durchführen, verwenden Sie eine PhantomReferenceQueue.

Für ein Beispiel schauen Sie sich die Umsetzung in Reagieren Native: https://github.com/facebook/react-native/blob/master/ReactAndroid/src/main/java/com/facebook/jni/DestructorThread.java

InformationsquelleAutor Ben