Java 如何判断Android内存何时过于碎片化

我知道我的问题太模糊了，但问题是。我解析一个非常大的文件，创建一个对象的链接列表（顺便说一句，它们与位图无关）。有时我会犯下臭名昭著的“OutOfMemoryError”。在此之前，我看到了我自己的：

available 478.0M, 47.5%, low=false
message in logcat that I create with:
        ActivityManager.MemoryInfo mi = new ActivityManager.MemoryInfo();
        ActivityManager activityManager = (ActivityManager)getSystemService(ACTIVITY_SERVICE);
        activityManager.getMemoryInfo(mi);
        double availableMegs = mi.availMem / 0x100000L;
        double percentAvail = mi.availMem / (double)mi.totalMem * 100.0;

请注意大量的可用内存

之后，我看到一堆GC消息，最后一条是：

I/art: Forcing collection of SoftReferences for 184B allocation
I/art: Clamp target GC heap from 256MB to 256MB
I/art: Alloc concurrent mark sweep GC freed 3(96B) AllocSpace objects, 0(0B) LOS objects, 1% free, 252MB/256MB, paused 539us total 41.854ms
I/System.out: java.lang.OutOfMemoryError: Failed to allocate a 184 byte allocation with 3403124 free bytes and 3MB until OOM; failed due to fragmentation (required continguous free 16384 bytes for a new buffer where largest contiguous free 4096 bytes)

很明显，我抓住了这个错误，即使我从来没有能够打破它。GC和ActivityManager之间的差异也是惊人的。问题是，在这之后我无法继续，因为GUI无法为其数据分配内存。换句话说，抓住这个错误已经太晚了。因此，我需要一些建议，如何确定何时停止，以便程序仍然可以继续。

---

请注意，我不需要关于如何优化数据的建议，因为无论数据有多好，我总是可以用一个更大的文件使程序崩溃。

“我不需要关于如何优化数据的建议，因为无论数据有多好，我总是可以用一个更大的文件使程序崩溃。”然后，也许您应该询问关于更好算法的建议，而不是更好的数据优化，这样您就不需要将整个文件加载到内存中，从而耗尽内存。类似于XML流解析可以解析无限的XML，而将XML解析到DOM将耗尽内存。

availMem

指的是系统范围的内存。它并不表示应用程序可用的可用Java堆空间量。另外，JVM使用压缩堆；可能会出现碎片，但必要时会消除碎片。想想如果你不能分配184字节的话，你的碎片化将是多么的美好。您的应用程序正在耗尽Java堆空间。请参阅。@greeble31关于availMem的好观点，将使用JVMAPI代替。我想我没有说清楚。目前我解析35MB的文件，创建155K对象，经过一些修改后，我的程序没有崩溃。问题仍然存在。我可以有70MB长的文件，100MB，等等。无论算法和数据有多好，在某个时刻我都会从内存错误中解脱出来。我想，正确的问题是：假设有最小内存大小的限制，我想知道这段内存何时变得不可用。然后我可以中止处理文件，仍然让程序继续运行。典型的方法是计算出您必须使用的内存量，然后只承担您可以完成的工作量而不超过该量。需要进行一些估计，b/c任何特定Java对象占用的内存量通常是不可精确知道的。您可以随时使用链接问题测量剩余堆的数量，但请记住，这是一个快速测量，它排除了将在下一次GC期间收集的对象。最好保守一点。