Java finalize方法中的位图循环无法正常工作

当我尝试加载一个大小接近应用程序堆最大大小的映像时，我的应用程序发生崩溃。第一次加载图像很好，然后删除对位图对象及其finalize的引用，在这里我调用mBitmap.recycle（）//nativeRecycle。显然，内存使用减少了，但当我再次尝试加载图像时，我的OutOfMemory崩溃了。

---

有趣的是，如果我在删除引用的同一个类中调用循环，似乎内存被释放了，我可以再次加载图像。因此，基本上，如果直接调用mBitmap.recycle（），得到的结果与将mBitmap.recycle（）放入引用位图的对象的最终确定中得到的结果不同。知道为什么会发生这种情况吗？

如果您接近使用堆的最大大小，那么您可能只是运气好（或者运气不好）。直接调用recycle（）与从终结器调用recycle（）可能会改变GC的时间和行为，从而使您看到不同之处

在尝试重新分配位图之前，是否确定正在调用终结器（和recycle（）？终结器不可靠，可以无限期推迟。即使您当前看到在测试期间重新分配之前调用终结器，也不能保证总是会发生这种情况（特别是对于不同的堆状态或Dalvik的未来/不同版本）

如果可以，请尽可能从终结器外部调用recycle（）。如果您知道什么时候完成，只需调用该方法；否则考虑使用RealCueQueU.（）.< 我已经有一段时间没有看过Dalvik了，但我似乎记得位图缓冲区可能需要几个GC周期才能清理，因为VM需要确保本机代码中没有剩余的指针。因此，缓冲区可能无法在您预期的时间完全释放

---

堆碎片也有可能会导致问题，尽管使用mmap（）分配大的缓冲区很有可能不会导致碎片（同样，这取决于Dalvik的当前版本）。

我只是使用一个带有3个按钮的简单测试：Load+Delete reference+call GC。因此，是的，我确信在再次按下加载按钮之前，finalize已被调用（我在finalize方法中跟踪该调用）。我使用的是HTC desire HD。无论我调用GC多少次，也不管我在加载图像之前等待了多长时间。不过，我会看一看片段部分。您可能还想尝试从正在完成的类中清除指向位图或任何引用位图的指针。但是，正如一位非常聪明的Java程序员所说：“不要重写finalize（）。不要这样做。如果您确实必须这样做，请首先非常仔细地阅读并理解有效的Java项目6，‘避免终结器’，然后不要这样做。”；）通过引用队列，您应该能够更可靠地处理这种情况。finalize的好处是，是的，我在Joshua的书中也知道这个提示。我曾尝试使用PhantomReferences和ReferenceQueue来调用recycle（基于此），问题是您需要调用GC以使PhantomReferences排队，并且每次我要删除图像时，GC都会对性能产生很大影响。