5

heap data

My application cant't run on android 4.x friendly,so I'm just analyzing my app's heap data,and I found that java.lang.FinalizerReference retained so much memory.Could any body can explain it?Any idea will be appreciated.

Phantômaxx
  • 37,901
  • 21
  • 84
  • 115
aolphn
  • 2,950
  • 2
  • 21
  • 30
  • A `FinalizerReference` is created for every object which has a “non-trivial” `finalize()` method. You can check the referent of the `FinalizerReference` instance to find out which object (and in turn, which class) is responsible. Then, you may rethink whether it actually needs a custom `finalize()` method. – Holger Oct 09 '18 at 11:16
  • @ Holger yeah,I've checked it,it is all framework's classes,like android.os.Parcel,My classes which are self defined are not override finalize() method. – aolphn Oct 11 '18 at 05:44
  • Then, there is not much you can change about it. But note that the `FinalizerReference` instances do not consumer that much memory (48kB); the “Retained Size” includes the referent’s memory and potentially even more objects reachable through that object. When these objects are only reachable through these reference objects, it’s an indicator that a subsequent garbage collection/finalization cycle could remove them. – Holger Oct 11 '18 at 05:58
  • I watch my application for 30 minutes,FinalizerReference retained memory is increasing aways and it do not decrease.⊙﹏⊙‖∣ – aolphn Oct 11 '18 at 06:21
  • Well, an application can run for 30 minutes or even days without any garbage collection. It might be counter-intuitive, but allocated memory doesn’t hurt, as long as it isn’t actually needed for some other purposes. So they question is, whether the memory keeps being in use by these objects, when you do either, force a garbage collection or let the memory run full completely. – Holger Oct 11 '18 at 06:26

1 Answers1

2

It doesn't, really.

I also encountered this problem, and I created a separate question and answer before finding yours. I think I actually got to the root of it.

tldr: Treating FinalizerReference like any other class when profiling (as Memory Profiler does), leads to repeated counting of the same memory when calculating Retained Size. So currently you can (almost always) regard the Retained Size of the FinalizerReference class reported by Memory Profiler as meaningless.

As Holger noted in the comments, only the 48 kB Shallow Size of the class (in your case) is usually important. However, the reported Retained Size of about 63 MB does not even include the referents' memory, only the recursively counted other instances of FinalizerReference. (unconvinced? read more)

But those referents are really important, especially any of them that are merely waiting to be finalize()'d before being garbage collected. So Memory Profiler should show them, as Holger assumed, because a large number of them would indicate a looming problem.

I view this as a bug in Android Studio's Memory Profiler, and have filed this issue.

HendrikFrans
  • 193
  • 9