问题标签 [fragmentation]

假设我有一个带有构造函数的内存池对象，该构造函数采用指向一大块内存 ptr 和大小 N 的指针。如果我执行许多不同大小的随机分配和释放，我可以让内存处于无法分配的状态M 字节对象连续在内存中，即使可能有很多空闲！同时，我无法压缩内存，因为这会导致消费者指针悬空。在这种情况下如何解决碎片？

我有一个正在写入网络的 Java 应用程序。它正在 764b +/- 5b 的区域内写入消息。pcap 显示流正在被 IP 分段，我们无法解释这一点。

Linux 2.6.18-238.1.1.el5

一个 strace 显示：

( strace -vvvv -f -tt -o strace.out -e trace=network -p $PID )

我在捕获网络时看到大于 MTU 的数据包，这导致了碎片。

问题：

1) 似乎服务器试图将两个 sendto() 批处理到一个 IP 数据包中，该数据包大于 MTU，因此变得碎片化。为什么？

2) 查看 PID 2046 的 strace 输出，等号 <... sendto resumed> 行之后的数字是发送的总数吗？即第 3 行和第 5 行总共发送了 764b？还是每行发送 764 个字节？

3) 是否有任何选项可以传递给 strace 以记录所有sendto() 输出？好像什么都找不到。。

当您将 c++ new 用于 iPhone 应用程序时，它是否会优化调用以最大限度地减少碎片（不实现任何手动内存管理）？例如，我听说 iPhone 支持一种特殊类型的虚拟内存。

我们有一个在内存中有很多位图的应用程序。它一直失败

错误。我们可能真的使用了太多的内存；我们可能正在泄漏内存；也有可能我们没有做错任何事情，而堆碎片正在杀死我们。（由于 Android 的垃圾收集器不会重新定位活动块，我们可能有兆字节的空闲空间，但无法分配 50K。）

有什么办法可以排除碎片吗？我一直在寻找类似 maxAvail/memAvail 的东西，但没有发现任何合适的东西。

在我的应用程序中，我使用一些对话框来显示信息。我的应用程序的主题是 Theme.Light 自 2 年以来，这些对话框从一开始就一直是黑色的。

现在有了 ICS，谷歌似乎改变了主意，把这些对话框变成了白色：

查看我的 Moto Xoom 和 Galaxy Nexus 的屏幕截图：

处理真正的碎片化的最佳实践是什么？

我一直在考虑创建不同的布局：layout-v14 但我很快就会发疯，如果我必须为未来创建 layout-v15、v-16 等？

或者有没有办法区分“低于 v14”和“高于 v14”？

我有一个表，其主键作为聚集的 GUID 字段；我正在使用 NEWSEQUENTIALID()而不是生成 GUID NEWID。不幸的是，因为这个表每天看到大约 25k-100k 的插入，在几个小时内（默认：聚集）主键索引变成了 99% 的碎片。

我最初使用NEWID而不是生成顺序 ID，但即使我重新创建表并使用重新插入所有行NEWSEQUENTIALID（并将其指定为主键列的默认值），我仍然在几个小时。（该表目前有大约 130 万条记录。

我曾考虑用整数主键替换 GUID，但我不确定这是否可行；另外，由于我们的团队使用 GUID 作为主键而不是整数，所以我认为我没有足够的支持来做这件事。

我有什么办法可以让这个东西进行碎片整理？我使用的是 SQL Server Express，因此我无法访问 SQL 代理（因此无法定期运行维护计划来重建索引）。

我也很可能在将来的某个时候拆分这个数据库/表（因为数据量大），所以我可能需要 GUID 来合并表。

另外：我不能使用索引视图，因为我有一个内部选择，这对我来说很难展开到一个连接中。

我有一个 Android 应用程序（活动），它也有相应的服务。该服务由活动启动，即使活动停止也应该持续运行。当活动再次启动时，它可以绑定到服务并查询它。

有时活动会被操作系统破坏和创建。这不应该影响事情，应该只是重新创建活动并能够再次绑定到服务。这基本上有效。

然而...

我发现 Dalvik VM 堆和本机堆都是非压缩的，因此大小会不断增加，直到活动用完内存并崩溃（即使总内存使用量实际上是恒定的并且没有泄漏）。由于在创建过程中完成了大量分配，因此销毁和重新创建活动会加剧这种情况。

这几乎保证了该活动将在多次重新启动后崩溃。这并没有让我很困扰，但是随后发生的事情是该服务也崩溃了，因为它是同一个应用程序的一部分。该服务包含一些重要数据，然后在崩溃期间丢失。

我对如何解决这个问题的任何建议感兴趣？

有没有办法将服务与活动分开（这样当活动崩溃时它也不会使服务崩溃），但仍然在同一个应用程序中拥有服务和活动？

我可以保留服务数据，但这需要对数据库进行多次访问，并且不利于节省电池。

我有一个 OpenGL Android 应用程序，它使用大量内存来设置复杂的场景，这显然会导致大量的堆碎片。即使没有内存泄漏，也无法在不因碎片而耗尽内存的情况下销毁和创建应用程序。（碎片肯定是问题，而不是泄漏）

这会导致一个主要问题，因为 Android 有在同一个 VM/堆上销毁和创建活动的习惯，这显然会导致活动崩溃。作为解决此问题的策略，我使用了以下技术：

这确保了当活动完成时，它会导致虚拟机完全关闭，因此下次启动活动时，它会获得一个新的未碎片化堆。

注意：我意识到这不是“Android 方式”，但鉴于垃圾收集器是非压缩的，因此不可能连续重用堆。

这种技术实际上确实可以正常工作，但是当活动在非完成模式下被销毁然后重新创建时，它就不起作用了。

有没有人对如何处理堆的退化有任何好的建议？

进一步说明：减少内存消耗也不是一个真正的选择。该活动实际上并没有使用那么多内存，但堆（和本机堆）似乎很容易碎片化，可能是由于一些大的内存块

sk_buff有两个地方可以存储下一个分片数据：

这两种处理碎片的方法有什么区别？

假设我有以下内容：

上述在堆上分配内存的向量会成为内存碎片的原因吗？我对碎片的理解是，只有在更大、更短的分配之间有小的、长期的分配（反之亦然）时才会真正发生。

我不想过早地优化这种情况，所以我想听听对这样的代码的一般看法。我知道各种专家不建议将大缓冲区放在堆栈上（毕竟这就是堆的用途），所以当我编写这样的代码时，这通常是我首先想到的。碎片化通常是需要分析的东西。我的心态应该是什么？