关于内存：在Java中，确定对象大小的最佳方法是什么？

例如，假设我有一个应用程序，可以用成堆的数据行读取csv文件。我根据数据类型给用户一个行数的摘要，但是我要确保我不读取太多的数据行并导致OutOfMemoryErrors。每一行转换为一个对象。有没有一种简单的方法可以通过编程的方式找出那个对象的大小？是否有一个引用定义了VM的基本类型和对象引用的大小？

现在，我有代码说可以读取多达32000行，但我也希望代码说可以读取尽可能多的行，直到我使用32MB的内存。也许这是一个不同的问题，但我还是想知道。

您可以使用java.lang.instrument包

编译该类并将其放入jar中：

在您的MANIFEST.MF中添加以下内容：

使用GetObjectSize:

调用：

您应该使用jol，它是作为OpenJDK项目的一部分开发的工具。

JOL (Java Object Layout) is the tiny toolbox to analyze object layout schemes in JVMs. These tools are using Unsafe, JVMTI, and Serviceability Agent (SA) heavily to decoder the actual object layout, footprint, and references. This makes JOL much more accurate than other tools relying on heap dumps, specification assumptions, etc.

要获得原语、引用和数组元素的大小，请使用VMSupport.vmDetails()。在64位Windows上运行的Oracle JDK 1.8.0_(用于以下所有示例)上，此方法返回

您可以使用ClassLayout.parseClass(Foo.class).toPrintable()获得对象实例的浅层大小(可选地将实例传递给toPrintable)。这只是该类的单个实例所占用的空间；它不包括该类引用的任何其他对象。它包括对象头、字段对齐和填充的VM开销。对于java.util.regex.Pattern：

您可以使用GraphLayout.parseInstance(obj).toFootprint()获得对象实例的深度视图。当然，封装外形中的某些对象可能是共享的(也可以从其他对象引用)，因此当该对象被垃圾收集时，它对可回收空间的过度估计。对于Pattern.compile("^[a-zA-Z0-9_.+-]+@[a-zA-Z0-9-]+\\.[a-zA-Z0-9-.]+$")的结果(取自此答案)，jol报告的总占用空间为1840字节，其中只有72个是模式实例本身。

如果您使用GraphLayout.parseInstance(obj).toPrintable()，jol将告诉您每个被引用对象的字段取消引用的地址、大小、类型、值和路径，尽管这通常太详细而不实用。对于正在进行的模式示例，您可能会得到以下内容。(两次运行之间地址可能会发生变化。)

"(something else)"条目描述堆中不属于此对象图的其他对象。

最好的jol文档是jol存储库中的jol示例。这些示例演示了常见的jol操作，并展示了如何使用jol分析VM和垃圾收集器内部。

几年前，JavaWork发表了一篇文章，讨论了复合和潜在嵌套Java对象的大小，它们基本上是通过在爪哇中创建一个siZeFor()实现的。该方法基本上建立在其他实验中，人们在实验中识别原语和典型Java对象的大小，然后将该知识应用于递归地遍历对象图以统计总大小的方法。

它总是比本机C实现稍差一些，这仅仅是因为类背后发生了一些事情，但它应该是一个很好的指示器。

或者，一个名为sizeof的sourceforge项目，它提供了一个带有sizeof()实现的java5库。

P.S.不要使用序列化方法，序列化对象的大小和它在活动时消耗的内存量之间没有相关性。

首先，"对象的大小"在Java中不是一个定义良好的概念。你可以指的是对象本身，只有它的成员，对象和它所指的所有对象(参考图)。您可以是指内存大小或磁盘大小。并且允许JVM优化字符串之类的东西。

因此，唯一正确的方法是使用一个好的探查器(我使用yourkit)询问JVM，这可能不是您想要的。

但是，从上面的描述来看，似乎每一行都是自包含的，并且没有大的依赖树，因此序列化方法可能是大多数JVM的一个很好的近似方法。最简单的方法如下：

请记住，如果有具有公共引用的对象，这将不会给出正确的结果，而且序列化的大小并不总是与内存中的大小匹配，但这是一个很好的近似值。如果您将bytearrayOutputstream大小初始化为一个合理的值，代码将更高效。

我偶然发现了一个Java类"jdk.nashorn.internal.ir.debug.objectsizecalculator"，已经在jdk中，它很容易使用，而且对于确定一个物体的大小很有用。

结果：

如果您只想知道在您的JVM中使用了多少内存，有多少是空闲的，您可以尝试这样做：

编辑：我认为这可能会有帮助，因为问题的作者还说，他希望有处理"在我使用32MB内存之前，尽可能多地读取行"的逻辑。

当我在Twitter工作时，我写了一个实用程序来计算深度对象的大小。它考虑了不同的内存模型(32位，压缩OOP，64位)，填充，子类填充，在循环数据结构和数组上正确工作。你可以编译这个.java文件，它没有外部依赖关系：

https://github.com/twitter/commons/blob/master/src/java/com/twitter/common/objectsize/objectsizecalculator.java

许多其他答案都提供了较浅的大小——例如，没有任何键或值的哈希图的大小，这不太可能是您想要的。

jamm项目使用上面的java.lang.instrumentation包，但会遍历树，因此可以给您提供深层内存使用。

https://github.com/jbelis/jamm

你必须使用反射来移动物体。像你这样小心：

• 仅仅分配一个对象在JVM中有一些开销。数量因JVM而异，因此您可以将该值作为参数。至少使它成为一个常量(8字节？)并适用于任何分配。
• 仅仅因为byte理论上是1字节，并不意味着它只需要一个内存。
• 对象引用中会有循环，因此需要保留一个HashMap或一些使用object equals作为比较器来消除无限循环的方法。

@Jodonnell:我喜欢您的解决方案的简单性，但是许多对象是不可序列化的(因此这会引发异常)，字段可以是临时的，对象可以覆盖标准方法。

您必须使用一个工具来测量它，或者手工估计它，这取决于您使用的JVM。

每个对象都有一些固定的开销。它是特定于JVM的，但我通常估计有40个字节。然后你必须看看班上的成员。对象引用是32位(64位)JVM中的4(8)个字节。基本类型包括：

• 布尔值和字节：1字节
• 字符和短：2字节
• int和float:4字节
• 长和双字节：8字节

数组遵循相同的规则；也就是说，它是一个对象引用，因此在对象中需要4(或8)个字节，然后它的长度乘以它的元素的大小。

尝试通过对Runtime.freeMemory()的调用以编程的方式来实现这一点并不能给您带来太多的准确性，因为对垃圾收集器的异步调用等。使用-xrunhprof或其他工具对堆进行分析会给您带来最准确的结果。

还有内存测量工具(以前在Google代码，现在在Github上)，它很简单，并在商业友好的Apache2.0许可证下发布，在类似的问题中讨论过。

如果你想测量内存字节消耗，它也需要命令行参数到Java解释器，但是在我使用它的场景中，它看起来很好。

EDCOX1的1个类提供了一个获得Java对象大小的好方法，但是它要求您定义一个EDCOX1，2个，并用Java代理运行程序。当您不需要任何代理，然后必须为应用程序提供一个虚拟的JAR代理时，这是非常无聊的。

所以我从sun.misc得到了一个使用Unsafe类的替代解决方案。因此，考虑对象根据处理器体系结构的堆对齐和计算最大字段偏移量，可以测量Java对象的大小。在下面的示例中，我使用辅助类UtilUnsafe来获取对sun.misc.Unsafe对象的引用。

不必处理插入等问题，如果不需要知道对象的字节大小，可以使用以下方法：

通过这种方式，您可以前后读取使用过的内存，并在获取使用过的内存之前调用GC，您可以将"噪声"降低到几乎为0。

为了获得更可靠的结果，您可以运行作业n次，然后将使用的内存除以n，得到一次运行需要多少内存。更重要的是，你可以把整件事做更多次，并得出平均值。

这里有一个实用程序，我使用一些链接的例子来处理32位、64位和64位的压缩OOP。它使用sun.misc.Unsafe。

它使用EDCOX1×1来获得一个本地指针的大小和EDCOX1(2)对Java引用的大小的影响。

它使用已知类的字段偏移量计算对象的基本大小。

如果你要求的是方法调用，那么就没有方法调用。通过一点研究，我想你可以自己写。一个特定的实例有一个固定的大小，这个大小是由引用的数量和原语值加上实例簿记数据得出的。您只需浏览对象图。行类型的变化越小，就越容易。

如果这太慢或只是比它的价值更多的麻烦，总是有很好的老式的排数规则的拇指。

我曾经写过一个快速测试来评估：

一般的概念是分配对象和测量空闲堆空间中的变化。密钥是getFreeMemory()，它请求GC运行并等待报告的空闲堆大小稳定下来。以上输出为：

这就是我们所期望的，给定对齐行为和可能的堆块头开销。

这里的仪器方法在公认的答案中是最准确的。我描述的方法是准确的，但仅在没有其他线程创建/丢弃对象的受控条件下。

只需使用Java Visual VM即可。

它拥有分析和调试内存问题所需的一切。

它还有一个OQL(对象查询语言)控制台，允许您做许多有用的事情，其中一个是sizeof(o)。

我的答案是基于尼克提供的代码。该代码测量被序列化对象占用的总字节数。所以这实际上是测量序列化的东西+普通的对象内存占用(只是序列化，例如int，您将看到序列化的字节总数不是4)。所以，如果你想得到完全用于你的对象的原始字节数，你需要稍微修改一下代码。像这样：

我已经用基本类型、字符串和一些普通类测试了这个解决方案。也可能没有涵盖的案例。

更新：修改示例以支持数组对象的内存足迹计算。

您可以生成一个堆转储(例如，使用JMAP)，然后分析输出以查找对象大小。这是一个离线解决方案，但您可以检查浅尺寸和深尺寸等。

假设我声明一个名为Complex的类，比如：

为了查看分配给此类活动实例的内存量：

这个答案与对象大小无关，但当您使用数组来容纳对象时，它将为对象分配多少内存大小。

因此，数组、列表或映射所有这些集合将不会真正存储对象(仅在基元时需要实际的对象内存大小)，它将只存储这些对象的引用。

现在是江户十一〔五〕。

• (4/8字节)取决于(32/64位)操作系统

基元

物体

我的意思是说所有的对象引用只需要4个字节的内存。它可以是字符串引用或双对象引用，但取决于对象创建，所需的内存将有所不同。

例如，如果我为下面的类ReferenceMemoryTest创建对象，那么将创建4+4+4=12字节的内存。当您试图初始化引用时，内存可能会有所不同。

因此，在创建对象/引用数组时，它的所有内容都将被空引用占据。我们知道每个引用需要4个字节。

最后，下面代码的内存分配是20字节。

referenceMemoryTest ref1=new referenceMemoryTest()；(4(ref1)+12=16字节)referenceMemoryTest ref2=ref1；(4(ref2)+16=20字节)

由于对象的创建，大小会增加JVM的内存使用量，这通常是对象的大小。

对于jsonObject，下面的代码可以帮助您。

返回字节大小

我用jsonarray对象检查了它，将它写到一个文件中。它给出了物体的大小。

我怀疑你是否想通过编程来实现它，除非你只想实现一次，并将其存储起来以备将来使用。这是一件昂贵的事情。在Java中没有siZOFF()运算符，即使存在，也只计算引用到其他对象的成本和基元的大小。

一种方法是将其序列化为文件，并查看文件的大小，如下所示：

当然，这假定每个对象都是不同的，并且不包含对其他任何对象的非瞬时引用。

另一种策略是对每个对象进行反射并检查其成员，然后将大小相加(布尔值字节=1字节，短字符=2字节等)，沿着成员层次结构向下工作。但是，这是乏味和昂贵的，并且最终做的和序列化策略一样。