4g内存堆内存分配多少_我需要多少内存

4g内存堆内存分配多少

什么是保留堆？

我需要多少内存？在构建解决方案，创建数据结构或选择算法时，您可能会问自己（或其他人）这个问题。如果此图包含1,000,000条边并且我使用HashMap进行存储，此图是否适合我的3G堆？构建我的自定义缓存解决方案时，我可以使用标准的Collections API还是它们带来的开销过多？

显然，简单问题的答案要复杂一些。在这篇文章中，我们将对此做一个初步的了解，看看实际上兔子洞有多深。

标题中问题的答案分为几个部分。首先，我们需要了解您是对浅堆大小还是保留堆大小感兴趣。

浅堆很容易–它仅由对象本身占用的堆组成。在计算方法上有一些细微差别，但是对于本文的范围，我们将其保留不变。请继续关注同一主题的未来帖子。

保留的堆在许多方面都更加有趣。很少有人对浅堆感兴趣，在大多数情况下，您的实际问题可以转换为“如果我从内存中删除此对象，那么垃圾收集器现在可以释放多少内存”。

现在，众所周知，所有Java垃圾回收（GC）算法都遵循以下逻辑：

GC将某些对象视为“重要”对象。这些被称为GC根，并且（几乎）从不丢弃。例如，它们是当前正在执行的方法的局部变量和输入参数，应用程序线程，来自本机代码的引用以及类似的“全局”对象。
从那些GC根目录引用的任何对象均假定为正在使用，因此未被GC丢弃。一个对象可以用Java中的不同方式引用另一个对象，在最常见的情况下，对象A存储在对象B的字段中。在这种情况下，我们说“ B引用A”。
重复该过程，直到访问了可以从GC根过渡获取的所有对象并将其标记为“使用中”为止。
其他所有东西都没有使用，可以扔掉。

现在，为了说明如何计算保留的堆，让我们通过以下示例对象遵循上述算法：

为了简化示例，让我们估计所有对象O1-O4的浅堆为1024B = 1kB。让我们开始计算这些对象的保留大小。

O4没有引用其他对象，因此它的保留大小等于其1kB的浅大小。
O3引用了O4。因此，垃圾收集O3意味着O4也有资格进行垃圾收集，因此我们可以说O3保留的堆为 2kB 。
O2引用了O3。但是现在需要注意的是，从O2删除指向O3的指针并不能使O3符合GC的条件，因为O1仍然有指向它的指针。因此， O2保留的堆只有1kB 。
另一方面，O1是在此小图中保留所有引用的对象，因此，如果我们删除O1，则该图上的所有内容都将被垃圾回收。因此， O1保留的堆为4kB 。

实际上有什么影响？实际上，了解浅堆大小和保留堆大小之间的差异使使用内存分析器和堆转储分析器之类的工具成为可能–例如，如果您不知道如何区分这两种方法，那么挖掘Eclipse MAT可能被证明是不可能的。堆大小测量的类型。

什么是浅堆？

本文是本系列的第二篇文章，我们将尝试回答这些问题。最后一篇文章解释了对象的保留大小和浅大小之间的区别。在本文中，我们还提供了一个如何计算数据结构的保留堆大小的示例。在今天的文章中，我们将扩展上一篇文章中所谓的“简单”。即– 什么是以及如何测量对象使用的浅堆。

在第一篇文章中，我们指出计算浅堆大小很容易–从而仅由对象本身占用的堆组成，从而大大降低了复杂性。但是，如何计算对象“自身”需要多少内存呢？显然有一个公式：

Shallow Heap Size = [reference to the class definition] + space for superclass fields + space for instance fields + [alignment]

似乎不太有用，是吗？让我们尝试使用以下示例代码来应用公式：

class X {int a;byte b;java.lang.Integer c = new java.lang.Integer();
}

class Y extends X {java.util.List d;java.util.Date e;
}

现在，我们努力回答的问题是– 一个Y实例需要多少浅堆大小？ 让我们开始计算它，假设我们使用的是32位x86体系结构：

作为起点– Y是X的子类，因此它的大小包括超类中的“某物”。因此，在计算Y的大小之前，我们先考虑计算X的浅大小。

跳到X上的计算中，前8个字节用于引用其类定义。该引用始终存在于所有Java对象中，并且被JVM用来定义以下状态的内存布局。它还具有三个实例变量–一个int，一个Integer和一个字节。这些实例变量需要堆，如下所示：

一个字节就是应该的。内存中有1个字节。
我们的32位架构中的int需要4个字节。
对整数的引用也需要4个字节。请注意，在计算保留堆时，我们还应考虑包装到Integer对象中的原语的大小，但是在此处计算浅堆时，我们在计算中仅使用4个字节的参考大小。

那么-是吗？ X的浅堆=从引用到类定义的8个字节+ 1个字节（该字节）+ 4个字节（int）+ 4个字节（对Integer的引用）= 17个字节？ 实际上–不 。现在起作用的是对齐（也称为填充）。这意味着JVM以8字节的倍数分配内存，因此如果我们创建X的实例，我们将分配24字节而不是17字节。

如果您可以在这里关注我们，那很好，但是现在我们尝试使事情变得更加复杂。我们不是在创建X的实例，而是在创建Y的实例。这意味着–我们可以从引用中减去8个字节到类定义和对齐方式。乍一看可能不太明显，但是–您是否注意到，在计算X的浅小尺寸时，我们没有考虑到它也扩展了java.lang.Object，因为所有类都这样做，即使您未在其中明确声明它也是如此。您的源代码？我们不必考虑超类的标头大小，因为JVM足够聪明，可以从类定义本身进行检查，而不必一直将其复制到对象标头中。

对齐也是如此–创建对象时，您只能对齐一次，而不是在超类/子类定义的边界。因此，可以肯定地说，当创建X的子类时，您只会从实例变量继承9个字节。

最后，我们可以跳到初始任务并开始计算Y的大小。正如我们所看到的，我们已经在超类字段中丢失了9个字节。让我们看看实际构造Y的实例时会添加什么。

Y的标头引用其类定义占用8个字节。与以前的相同。
日期是对对象的引用。 4字节。简单。
该列表是对集合的引用。同样是4个字节。不重要的。

因此，除了超类中的9个字节外，我们还有8个字节的头空间，2×4个字节的数据来自两个引用（列表和日期）。 Y实例的总浅层大小为25个字节，对齐为32个字节。

为了使计算更易于遵循，我们将其汇总在下图中：

	1个	2	3	4	5	6	7	8	9	10	11	12	13	14	15	16	17	18	19	20	21	22	23	24	25	26	27	28	29	30	31	32
	对齐	对齐	对齐	对齐
X	目的	一个	b	C
ÿ	目的	一个	b	C	d	Ë

您可以用这些知识做什么？加上计算保留堆大小的技巧（在我的最新文章中已经介绍过），您现在拥有了计算数据结构实际需要多少内存的最终能力。

为了使事情变得更加有趣，我们创建了一个实用程序，该实用程序可以测量对象的浅堆和保留堆的大小。在不久的将来，我们将免费提供该工具。订阅我们的Twitter feed，敬请关注！

测量，不要猜测

看起来很简单的任务实际上可能变得有些复杂。在计算对象的内存占用量时，您需要牢记很多不同方面：

我是否需要测量浅堆或保留堆大小？
我是否要针对32位或64位架构进行计算？
我是在x86，SPARC，POWER还是其他无法想象的东西上运行？
是否使用压缩或未压缩的普通对象指针？
[在此处输入您担心或不完全理解的其他内容]

当试图满足另一个截止日期时，在尝试估计数据结构的大小时牢记所有这些方面是完全不合理的。因此，我们继续将Java Champion Heinz Kabutz发布的代码打包为Java代理，并提供了一种轻松的方法将其添加到您的应用程序中。

添加代理为您提供了一种简便的方法来跟踪实际环境中数据结构占用的内存量。并做到了没有其他选择所带来的复杂性。在以下四个简单的步骤中，您正在运行并最终了解宝贵的缓存实际消耗了多少内存：

步骤1： 下载代理。不用担心，它只有几千字节。

步骤2：解压缩下载的代理。您会看到它与源代码打包在一起，并附带了有关如何使用它的示例。随意使用代码。

nikita-mb:sizeof nikita$ ls -l
total 16
-rw-r--r-- 1 nikita  staff  1696 Aug 28 22:12 build.xml
-rw-r--r--  1 nikita  staff  3938 Aug 28 22:33 sizeofagent.jar
drwxr-xr-x 5 nikita  staff    170 Aug 28 10:44 src

步骤3：尝试捆绑的测试用例。捆绑的测试用例测量的数据结构与我们在博客文章中描述的有关浅堆大小测量的数据结构相同。对于那些不愿意来回点击的人，这里再次是代码：

class X {int a;byte b;java.lang.Integer c = new java.lang.Integer();
}

class Y extends X {java.util.List d;java.util.Date e;
}

该测试用例随Ant测试一起提供，以编译和运行示例。如果您使用的是32位体系结构，请运行ant test或ant test-32 。使用ant test运行所有测试时，应该看到以下输出：

nikita-mb:sizeof nikita$ ant testBuildfile: /Users/nikita/workspace/sizeof/build.xmlinit:compile:test32:[java] java.lang.Object: shallow size=8 bytes, retained=8 bytes[java] eu.plumbr.sizeof.test.X: shallow size=24 bytes, retained=40 bytes[java] eu.plumbr.sizeof.test.Y: shallow size=32 bytes, retained=48 bytestest64+UseCompressedOops:[java] java.lang.Object: shallow size=16 bytes, retained=16 bytes[java] eu.plumbr.sizeof.test.X: shallow size=24 bytes, retained=40 bytes[java] eu.plumbr.sizeof.test.Y: shallow size=32 bytes, retained=48 bytestest64-UseCompressedOops:[java] java.lang.Object: shallow size=16 bytes, retained=16 bytes[java] eu.plumbr.sizeof.test.X: shallow size=32 bytes, retained=56 bytes[java] eu.plumbr.sizeof.test.Y: shallow size=48 bytes, retained=72 bytestest:BUILD SUCCESSFUL
Total time: 2 seconds

从上面的测试中，您可以看到例如在32位体系结构上，Y的浅堆消耗32个字节，而保留堆则占用48个字节。在带有-XX:-UseCompressedOops的64位体系结构上，浅层大小增加到48个字节，保留堆大小增加到72个字节。如果您对我们如何计算这些数字感到困惑，那么请从本系列的先前文章中了解什么是以及如何计算浅层和保留堆大小。

步骤4：将代理附加到您自己的Java应用程序。为此，将-javaagent:path-to/sizeofagent.jar到JVM启动脚本中。现在，您可以通过在代码中直接调用MemoryCounterAgent.deepSizeOf(yourObject)来测量浅堆消耗，或通过直接调用MemoryCounterAgent.sizeOf(yourObject)测量保留的堆消耗。另请参阅捆绑的ant脚本和eu.plumbr.sizeof.test.SizeOfSample类，以防在执行过程中感到困惑。

当然，您有许多选择，尤其是以内存分析器和APM解决方案的形式。但是，这个小型代理将快速完成其任务，几乎不需要设置或学习。好吧，至少我们玩得很开心。而不是处理我们的产品积压。

PS。在撰写本文时，以下在线资源被用作灵感来源：

http://memoryanalyzer.blogspot.com/2010/02/heap-dump-analysis-with-memory-analyzer.html
http://www.javamex.com/tutorials/memory/object_memory_usage.shtml
http://www.javamex.com/tutorials/memory/instrumentation.shtml
http://kohlerm.blogspot.com/2008/12/how-much-memory-is-used-by-my-java.html
http://www.javaspecialists.eu/archive/Issue142.html

而且-不要忘了将此代码祝贺您发送给Heinz Kabutz，后者最初于2007年3月在Java专家通讯中发布了该代码。

参考： 我需要多少内存（第1部分）–保留的堆是什么？，我需要多少内存（第2部分）–什么是浅堆？，我需要多少内存（第3部分）–衡量一下，不要从我们的JCG合作伙伴 Nikita Salnikov Tarnovski （在Plumbr Blog博客上）猜到。