Nasıl işlenir: java.util.concurrent.TimeoutException: android.os.BinderProxy.finalize () 10 saniye hatadan sonra zaman aşımına uğradı mı?

Biz bir takım görüyoruz TimeoutExceptionsiçinde GcWatcher.finalize, BinderProxy.finalizeve PlainSocketImpl.finalize. Bunların% 90'ı Android 4.3'te gerçekleşiyor. Bu konuda sahadaki kullanıcılardan Crittercism'den raporlar alıyoruz.

Hata şunun bir varyasyonudur: " com.android.internal.BinderInternal$GcWatcher.finalize() timed out after 10 seconds"

java.util.concurrent.TimeoutException: android.os.BinderProxy.finalize() timed out after 10 seconds
at android.os.BinderProxy.destroy(Native Method)
at android.os.BinderProxy.finalize(Binder.java:459)
at java.lang.Daemons$FinalizerDaemon.doFinalize(Daemons.java:187)
at java.lang.Daemons$FinalizerDaemon.run(Daemons.java:170)
at java.lang.Thread.run(Thread.java:841)

Şimdiye kadar, sorunu evde yeniden üretme veya neye yol açmış olabileceğini çözme şansımız olmadı.

Buna neden olabilecek herhangi bir fikir var mı? Bu hata ayıklama ve uygulamanın hangi kısmının buna neden olduğunu bulmak için herhangi bir fikir? Konuya ışık tutan her şey yardımcı olur.

Daha fazla Stacktraces:

1   android.os.BinderProxy.destroy  
2   android.os.BinderProxy.finalize Binder.java, line 482
3   java.lang.Daemons$FinalizerDaemon.doFinalize    Daemons.java, line 187
4   java.lang.Daemons$FinalizerDaemon.run   Daemons.java, line 170
5   java.lang.Thread.run    Thread.java, line 841  

2

1   java.lang.Object.wait   
2   java.lang.Object.wait   Object.java, line 401
3   java.lang.ref.ReferenceQueue.remove ReferenceQueue.java, line 102
4   java.lang.ref.ReferenceQueue.remove ReferenceQueue.java, line 73
5   java.lang.Daemons$FinalizerDaemon.run   Daemons.java, line 170
6   java.lang.Thread.run

3

1   java.util.HashMap.newKeyIterator    HashMap.java, line 907
2   java.util.HashMap$KeySet.iterator   HashMap.java, line 913
3   java.util.HashSet.iterator  HashSet.java, line 161
4   java.util.concurrent.ThreadPoolExecutor.interruptIdleWorkers    ThreadPoolExecutor.java, line 755
5   java.util.concurrent.ThreadPoolExecutor.interruptIdleWorkers    ThreadPoolExecutor.java, line 778
6   java.util.concurrent.ThreadPoolExecutor.shutdown    ThreadPoolExecutor.java, line 1357
7   java.util.concurrent.ThreadPoolExecutor.finalize    ThreadPoolExecutor.java, line 1443
8   java.lang.Daemons$FinalizerDaemon.doFinalize    Daemons.java, line 187
9   java.lang.Daemons$FinalizerDaemon.run   Daemons.java, line 170
10  java.lang.Thread.run

4

1   com.android.internal.os.BinderInternal$GcWatcher.finalize   BinderInternal.java, line 47
2   java.lang.Daemons$FinalizerDaemon.doFinalize    Daemons.java, line 187
3   java.lang.Daemons$FinalizerDaemon.run   Daemons.java, line 170
4   java.lang.Thread.run

Tam açıklama - TLV DroidCon'da daha önce bahsedilen konuşmanın yazarıyım.

Bu sorunu birçok Android uygulamasında inceleme şansı buldum ve karşılaşan diğer geliştiricilerle tartıştım - ve hepimiz aynı noktaya geldik: bu sorun önlenemez, sadece en aza indirilir.

Bu istisnanın neden atıldığını ve olası nedenlerin ne olabileceğini daha iyi anlamak için Android Çöp toplayıcı kodunun varsayılan uygulamasına daha yakından baktım. Deneme sırasında olası bir kök neden bile buldum.

Sorunun kökü, bir süre bir cihazın "Uyumaya Gittiği" noktadadır - bu, işletim sisteminin, çoğu Kullanıcı Land işlemini bir süre durdurarak ve Ekranı kapatarak, CPU döngülerini azaltarak pil tüketimini azaltmaya karar verdiği anlamına gelir. Bunun yapılması - işlemlerin orta çalıştırmada Duraklatıldığı bir Linux sistem düzeyindedir. Bu, normal Uygulama yürütme sırasında herhangi bir zamanda olabilir, ancak bağlam değiştirme çekirdek seviyesinde yapıldığından, Yerel sistem çağrısında duracaktır. Yani - bu Dalvik GC'nin hikayeye katıldığı yerdir.

Dalvik GC kodu (AOSP sitesindeki Dalvik projesinde uygulandığı gibi) karmaşık bir kod parçası değildir. Temel çalışma şekli DroidCon slaytlarımda ele alınmıştır. Kapsadığım temel GC döngüsü - toplayıcının sonuçlandırmak (ve yok etmek) için bir Obje listesi olduğu noktada. Tabandaki döngü mantığı şu şekilde basitleştirilebilir:

1. almak starting_timestamp,
2. serbest bırakılacak nesnelerin listesi için nesneyi kaldırın,
3. serbest bırakma nesnesi - finalize()ve destroy()gerekirse yerel çağrı ,
4. almak end_timestamp,
5. hesaplayın ( end_timestamp - starting_timestamp) ve 10 saniyelik sabit kodlanmış bir zaman aşımı değeriyle karşılaştırın,
6. zaman aşımı süresi dolduysa - işlemi atın java.util.concurrent.TimeoutExceptionve öldürün.

Şimdi aşağıdaki senaryoyu düşünün:

Uygulama işini yapıyor.

Bu kullanıcıya bakan bir uygulama değildir, arka planda çalışır.

Bu arka plan işlemi sırasında nesneler oluşturulur, kullanılır ve belleği serbest bırakmak için toplanması gerekir.

Uygulama bir WakeLock ile uğraşmaz - bu pili olumsuz etkileyeceğinden ve gereksiz göründüğü için.

Bu, Uygulamanın GC'yi zaman zaman çağıracağı anlamına gelir.

Normalde GC çalışır bir aksama olmadan tamamlanır.

Bazen (çok nadiren) sistem GC çalışmasının ortasında uyumaya karar verir.

Bu, uygulamanızı yeterince uzun çalıştırırsanız ve Dalvik bellek günlüklerini yakından izlerseniz gerçekleşir.

Şimdi - temel GC döngüsünün zaman damgası mantığını düşünün - cihazın çalışması başlatmak, bir sistem nesnesi üzerinde yerel çağrıda start_stampuykuya dalmak ve uyumak mümkündür destroy().

O uyanır ve koşmak devam ettiğinde, destroy()bitirir ve bir sonraki end_stampeylemin ne kadar zaman olacak destroy()çağrıyı + uyku süresini.

Uyku süresi uzunsa (10 saniyeden fazla), java.util.concurrent.TimeoutExceptionatılır.

Bunu sadece kendi izlenen uygulamalarım değil, Android Sistem Uygulamaları için analiz python betiğinden oluşturulan grafiklerde gördüm.

Yeterli kütük topla ve sonunda göreceksin.

Sonuç olarak:

Sorun önlenemez - uygulamanız arka planda çalışırsa bu sorunla karşılaşırsınız.

Bir WakeLock alarak hafifletebilir ve cihazın uyumasını engelleyebilirsiniz, ancak bu tamamen farklı bir hikaye ve yeni bir baş ağrısı ve belki de başka bir konuyla başka bir konuşma.

GC çağrılarını azaltarak - senaryoyu daha az olası hale getirerek (ipuçları slaytlarda bulunur) sorunu en aza indirebilirsiniz.

Henüz yeni bir Nesil Sıkıştırma özelliğine sahip olan veya Android Lollipop'ta herhangi bir deney gerçekleştiren Dalvik 2 (aka ART) GC kodunu gözden geçirme şansım olmadı.

7/5/2015 eklendi:

Bu kilitlenme türü için Crash raporlarının toplanmasını inceledikten sonra, Android OS'nin 5.0+ sürümündeki (ART ile Lollipop) bu kilitlenmelerin bu kilitlenme türünün yalnızca% 0,5'ini oluşturduğu görülüyor. Bu, ART GC değişikliklerinin bu çökmelerin sıklığını azalttığı anlamına gelir.

Eklendi 6/1/2016:

Android projesi, GC'nin Dalvik 2.0'da (aka ART) nasıl çalıştığı hakkında çok fazla bilgi ekledi.

Buradan okuyabilirsiniz - ART Çöp Toplama Hata Ayıklama .

Ayrıca uygulamanızın GC davranışı hakkında bilgi almak için bazı araçları da tartışır.

Uygulama işleminize bir SIGQUIT göndermek, esas olarak bir ANR'ye neden olur ve uygulama durumunu analiz için bir günlük dosyasına döker.

Biz Crashlytics kullanarak, bizim app, sürekli görmek. Kaza genellikle platform kodunda aşağı doğru gerçekleşir. Küçük bir örnekleme:

android.database.CursorWindow.finalize () 10 saniye sonra zaman aşımına uğradı

java.util.regex.Matcher.finalize () 10 saniye sonra zaman aşımına uğradı

android.graphics.Bitmap $ BitmapFinalizer.finalize () 10 saniye sonra zaman aşımına uğradı

org.apache.http.impl.conn.SingleClientConnManager.finalize () 10 saniye sonra zaman aşımına uğradı

java.util.concurrent.ThreadPoolExecutor.finalize () 10 saniye sonra zaman aşımına uğradı

android.os.BinderProxy.finalize () 10 saniye sonra zaman aşımına uğradı

android.graphics.Path.finalize () 10 saniye sonra zaman aşımına uğradı

Bunun gerçekleştiği cihazlar, Samsung tarafından üretilen ezici (ancak sadece değil) cihazlardır. Bu, kullanıcılarımızın çoğunun Samsung cihazlarını kullandığı anlamına gelebilir; alternatif olarak Samsung cihazlarında bir sorun olduğunu gösterebilir. Gerçekten emin değilim.

Bunun sorularınızı gerçekten cevaplamadığını düşünüyorum, ancak bunun oldukça yaygın göründüğünü ve uygulamanıza özgü olmadığını güçlendirmek istedim.

Bu konuda bazı slaytlar buldum.

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

Bu slaytlarda yazar, yığında çok fazla nesne veya büyük nesne varsa, GC ile ilgili bir sorun olduğunu söylüyor. Slayt ayrıca bu sorunu analiz etmek için örnek bir uygulamaya ve bir python komut dosyasına başvuru içerir.

https://github.com/oba2cat3/GCTest

https://github.com/oba2cat3/logcat2memorygraph

Ayrıca bu tarafta # 3 numaralı yorumda bir ipucu buldum: https://code.google.com/p/android/issues/detail?id=53418#c3

Sorunu durdurarak çözdük 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();
    }
}

Yöntemi, uygulamanın yaşam döngüsünde çağırabilirsiniz attachBaseContext(). Aynı nedenle, sorunu çözmek için telefonun üretimini de belirtebilirsiniz, bu size bağlıdır.

Yayın Alıcıların zaman aşımı süresi 10 saniye sonra. Muhtemelen bir yayın alıcısından senkronize olmayan bir çağrı yaptığınızda (yanlış) ve 4.3 bunu algılar.

İşte bu sorunu çözmek için didi'den etkili bir çözüm, Bu hata çok yaygın ve nedeni bulmak zor olduğu için, bir sistem problemine daha çok benziyor, Neden doğrudan görmezden gelemiyoruz？ Elbette görmezden gelebiliriz, Burada örnek kod:

final Thread.UncaughtExceptionHandler defaultUncaughtExceptionHandler = 
        Thread.getDefaultUncaughtExceptionHandler();
Thread.setDefaultUncaughtExceptionHandler(new Thread.UncaughtExceptionHandler() {
    @Override
    public void uncaughtException(Thread t, Throwable e) {
        if (t.getName().equals("FinalizerWatchdogDaemon") && e instanceof TimeoutException) {
        } else {
            defaultUncaughtExceptionHandler.uncaughtException(t, e);
        }
    }
});

Özel bir varsayılan yakalanmayan özel durum işleyicisi ayarlayarak, uygulama, sistemin sağladığı varsayılan davranışı kabul eden iş parçacıkları için yakalanmayan özel durumların işlenme biçimini değiştirebilir. Yakalanan TimeoutExceptionadlı bir iş parçacığından yakalanmamış atılırsa FinalizerWatchdogDaemon, bu özel işleyici işleyici zincirini bloke eder, sistem işleyicisi çağrılmaz, böylece kilitlenme önlenir.

Uygulama ile başka hiçbir kötü etki bulunmadı. GC sistemi hala çalışıyor, CPU kullanımı azaldıkça zaman aşımları azalıyor.

Daha fazla ayrıntı için bkz. Https://mp.weixin.qq.com/s/uFcFYO2GtWWiblotem2bGg

Her zaman doğru olan bir şey, cihazın şu anda bir miktar bellek için boğulmasıdır (genellikle GC'nin büyük olasılıkla tetiklenmesinin nedeni budur).

Daha önce neredeyse tüm yazarlar tarafından belirtildiği gibi, bu sorun, uygulama arka planda iken Android GC'yi çalıştırmaya çalıştığında ortaya çıkar. Gözlemlediğimiz çoğu durumda, kullanıcı ekranını kilitleyerek uygulamayı duraklattı. Bu aynı zamanda uygulamada bir yerde bellek sızıntısı olduğunu veya cihazın zaten yüklü olduğunu gösterebilir. Yani bunu en aza indirmenin tek meşru yolu:

• bellek sızıntısı olmadığından emin olmak ve
• genel olarak uygulamanın bellek ayak izini azaltmak için.

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();
}

FinalizeQueue çok uzun olabilir

java kullanıcı kesin finalQueue uzunluğunu azaltmak için GC.SuppressFinalize () & GC.ReRegisterForFinalize () gerektirebilir düşünüyorum

JVM kaynak kodu mevcutsa, android ROM yapımcısı gibi bu yöntemi kendimiz uygulayabiliriz

Bir Android Çalışma Zamanı hatası gibi görünüyor. Ayrı iş parçacığında çalışan ve yığın izinin geçerli çerçevesinde değilse nesneler üzerinde finalize () yöntemini çağıran sonlandırıcı var gibi görünüyor. Örneğin aşağıdaki kod (bu sorunu doğrulamak için oluşturuldu) kilitlenme ile sona erdi.

Sonlandırma yönteminde bir şey yapan bazı imleç (örneğin, şu anda kullanımda olan veritabanına kilitlenen SqlCipher olanlar, close ())

private static class MyCur extends MatrixCursor {


    public MyCur(String[] columnNames) {
        super(columnNames);
    }

    @Override
    protected void finalize() {
        super.finalize();

        try {
            for (int i = 0; i < 1000; i++)
                Thread.sleep(30);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
    }
}

Ve imleci açarak uzun süren bazı şeyler yapıyoruz:

for (int i = 0; i < 7; i++) {
        new Thread(new Runnable() {
            @Override
            public void run() {
                MyCur cur = null;
                try {
                    cur = new MyCur(new String[]{});
                    longRun();
                } finally {
                    cur.close();
                }
            }

            private void longRun() {
                try {
                    for (int i = 0; i < 1000; i++)
                        Thread.sleep(30);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
            }
        }).start();
    }

Bu, aşağıdaki hataya neden olur:

FATAL EXCEPTION: FinalizerWatchdogDaemon
                                                                        Process: la.la.land, PID: 29206
                                                                        java.util.concurrent.TimeoutException: MyCur.finalize() timed out after 10 seconds
                                                                            at java.lang.Thread.sleep(Native Method)
                                                                            at java.lang.Thread.sleep(Thread.java:371)
                                                                            at java.lang.Thread.sleep(Thread.java:313)
                                                                            at MyCur.finalize(MessageList.java:1791)
                                                                            at java.lang.Daemons$FinalizerDaemon.doFinalize(Daemons.java:222)
                                                                            at java.lang.Daemons$FinalizerDaemon.run(Daemons.java:209)
                                                                            at java.lang.Thread.run(Thread.java:762)

SqlCipher ile üretim varyantı çok benzer:

12-21 15:40:31.668: E/EH(32131): android.content.ContentResolver$CursorWrapperInner.finalize() timed out after 10 seconds
12-21 15:40:31.668: E/EH(32131): java.util.concurrent.TimeoutException: android.content.ContentResolver$CursorWrapperInner.finalize() timed out after 10 seconds
12-21 15:40:31.668: E/EH(32131): 	at java.lang.Object.wait(Native Method)
12-21 15:40:31.668: E/EH(32131): 	at java.lang.Thread.parkFor$(Thread.java:2128)
12-21 15:40:31.668: E/EH(32131): 	at sun.misc.Unsafe.park(Unsafe.java:325)
12-21 15:40:31.668: E/EH(32131): 	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:161)
12-21 15:40:31.668: E/EH(32131): 	at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:840)
12-21 15:40:31.668: E/EH(32131): 	at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:873)
12-21 15:40:31.668: E/EH(32131): 	at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1197)
12-21 15:40:31.668: E/EH(32131): 	at java.util.concurrent.locks.ReentrantLock$FairSync.lock(ReentrantLock.java:200)
12-21 15:40:31.668: E/EH(32131): 	at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:262)
12-21 15:40:31.668: E/EH(32131): 	at net.sqlcipher.database.SQLiteDatabase.lock(SourceFile:518)
12-21 15:40:31.668: E/EH(32131): 	at net.sqlcipher.database.SQLiteProgram.close(SourceFile:294)
12-21 15:40:31.668: E/EH(32131): 	at net.sqlcipher.database.SQLiteQuery.close(SourceFile:136)
12-21 15:40:31.668: E/EH(32131): 	at net.sqlcipher.database.SQLiteCursor.close(SourceFile:510)
12-21 15:40:31.668: E/EH(32131): 	at android.database.CursorWrapper.close(CursorWrapper.java:50)
12-21 15:40:31.668: E/EH(32131): 	at android.database.CursorWrapper.close(CursorWrapper.java:50)
12-21 15:40:31.668: E/EH(32131): 	at android.content.ContentResolver$CursorWrapperInner.close(ContentResolver.java:2746)
12-21 15:40:31.668: E/EH(32131): 	at android.content.ContentResolver$CursorWrapperInner.finalize(ContentResolver.java:2757)
12-21 15:40:31.668: E/EH(32131): 	at java.lang.Daemons$FinalizerDaemon.doFinalize(Daemons.java:222)
12-21 15:40:31.668: E/EH(32131): 	at java.lang.Daemons$FinalizerDaemon.run(Daemons.java:209)
12-21 15:40:31.668: E/EH(32131): 	at java.lang.Thread.run(Thread.java:762)

Devam: İmleçleri en kısa sürede kapatın. En azından sorunun görüldüğü Android 7'li Samsung S8'de.

Oluşturduğunuz sınıflar için (yani Android'in bir parçası değildir) çökmeyi tamamen önlemek mümkündür.

finalize()@Oba tarafından açıklandığı gibi , uygulayan herhangi bir sınıfın kaçınılmaz olarak çökme olasılığı vardır. Bu nedenle, temizleme işlemi yapmak için sonlandırıcıları kullanmak yerine a PhantomReferenceQueue.

Örnek için React Native'deki uygulamaya bakın: https://github.com/facebook/react-native/blob/master/ReactAndroid/src/main/java/com/facebook/jni/DestructorThread.java