问题
I get an ANR-error in my Android app. The trace shows only one thread in blocked state (all the others are in state waiting, sleeping, native,..), so it doesn't seem to be in deadlock. There are two threads which I start (directly) manually, so I roughly know in which part of my app the ANR occurs. Unfortunately, I can't make any sense of the trace of the blocked thread. Maybe anyone has an idea?
Blocked thread:
"HeapTaskDaemon" daemon prio=5 tid=6 Blocked
| group="system" sCount=1 dsCount=0 obj=0x12cfc8e0 self=0xab4b2bf0
| sysTid=10048 nice=0 cgrp=default sched=0/0 handle=0xf4815930
| state=S schedstat=( 113876044 26950467 98 ) utm=9 stm=2 core=5 HZ=100
| stack=0xf4713000-0xf4715000 stackSize=1038KB
| held mutexes=
native: pc 0000000000016908 /system/lib/libc.so (syscall+28)
native: pc 00000000000f604b /system/lib/libart.so (_ZN3art17ConditionVariable4WaitEPNS_6ThreadE+82)
native: pc 00000000001cddb1 /system/lib/libart.so (_ZN3art2gc13TaskProcessor7GetTaskEPNS_6ThreadE+92)
native: pc 00000000001ce2c5 /system/lib/libart.so (_ZN3art2gc13TaskProcessor11RunAllTasksEPNS_6ThreadE+60)
native: pc 000000000000036f /data/dalvik-cache/arm/system@framework@boot.oat (Java_dalvik_system_VMRuntime_runHeapTasks__+74)
at dalvik.system.VMRuntime.runHeapTasks (Native method)
- waiting to lock an unknown object
at java.lang.Daemons$HeapTaskDaemon.run (Daemons.java:355)
at java.lang.Thread.run (Thread.java:818)
This is the main thread:
"main" prio=5 tid=1 Waiting
| group="main" sCount=1 dsCount=0 obj=0x74da03b0 self=0xab36bea8
| sysTid=10039 nice=13 cgrp=bg_non_interactive sched=0/0 handle=0xf77a2b34
| state=S schedstat=( 2234944203 2215960664 6968 ) utm=163 stm=60 core=6 HZ=100
| stack=0xff794000-0xff796000 stackSize=8MB
| held mutexes=
at java.lang.Object.wait! (Native method)
- waiting on <0x07456fa0> (a java.lang.Object)
at java.lang.Thread.parkFor$ (Thread.java:1220)
- locked <0x07456fa0> (a java.lang.Object)
at sun.misc.Unsafe.park (Unsafe.java:299)
at java.util.concurrent.locks.LockSupport.park (LockSupport.java:158)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt (AbstractQueuedSynchronizer.java:810)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued (AbstractQueuedSynchronizer.java:843)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire (AbstractQueuedSynchronizer.java:1172)
at java.util.concurrent.locks.ReentrantLock$NonfairSync.lock (ReentrantLock.java:181)
at java.util.concurrent.locks.ReentrantLock.lock (ReentrantLock.java:257)
at android.view.SurfaceView.updateWindow (SurfaceView.java:524)
at android.view.SurfaceView$3.onPreDraw (SurfaceView.java:179)
at android.view.ViewTreeObserver.dispatchOnPreDraw (ViewTreeObserver.java:944)
at android.view.ViewRootImpl.performTraversals (ViewRootImpl.java:2082)
at android.view.ViewRootImpl.doTraversal (ViewRootImpl.java:1134)
at android.view.ViewRootImpl$TraversalRunnable.run (ViewRootImpl.java:6050)
at android.view.Choreographer$CallbackRecord.run (Choreographer.java:860)
at android.view.Choreographer.doCallbacks (Choreographer.java:672)
at android.view.Choreographer.doFrame (Choreographer.java:608)
at android.view.Choreographer$FrameDisplayEventReceiver.run (Choreographer.java:846)
at android.os.Handler.handleCallback (Handler.java:739)
at android.os.Handler.dispatchMessage (Handler.java:95)
at android.os.Looper.loop (Looper.java:148)
at android.app.ActivityThread.main (ActivityThread.java:5441)
at java.lang.reflect.Method.invoke! (Native method)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run (ZygoteInit.java:738)
at com.android.internal.os.ZygoteInit.main (ZygoteInit.java:628)
回答1:
Trying to put more information on this issue. So that it can help future user's.
As you said only one thread in Blocked state, it's clear that it is not a Deadlock. Threads marked as blocked will generally tell you what mutex (lock) they are trying to acquire and the thread ID (tid) of the thread holding that lock.
In this particular case
- waiting to lock an unknown object
Above line tell neither what mutex(lock) it trying to acquire or thread ID holding that lock. (Maybe HeapTaskDaemon thread trying to lock some native object and in that attempt block due to some race condition). So just check with below information and identify the issue in your case and/or put forward an educated guess to prevent it.
On recent versions of Android, garbage collection(GC) generally runs on a background thread named HeapTaskDaemon. Note that significant amounts of allocation can mean more CPU resources spent on GC.
Systrace will show you if GC is running frequently, and the Android Memory Profiler can show you where allocations are coming from. If you avoid allocations when you can, especially in tight loops, you shouldn't have a problem.
check this for more information.
For more information on ANR and Deadlock's in Android check this link.
Hope this will help.
回答2:
Seems like your SurfaceView is locking thread with ReentrantLock, but possibly having a problem initialising after setting WaitLock, and the ReentrantLock stays locked by SurfaceView, this is causing your Thread blocked usually know as Jank.
You sholud try debugging issue yourself, use Systrace to find what is causing Jank, also enable GPU rendering and Paste Systrace data here so that i can review, and provide any solution if possible.
回答3:
Have you tried to set android:largeHeap="true" in application Manifest?
`
来源：https://stackoverflow.com/questions/44475110/anr-with-blocked-heaptaskdaemon-thread