【发布时间】：2016-08-02 10:59:56
【问题描述】：
我在 patricia trie (https://commons.apache.org/proper/commons-collections/apidocs/org/apache/commons/collections4/trie/PatriciaTrie.html) 的磁盘上有一个序列化对象。在磁盘上，它大约占用 7.4 GB。我正在使用 64 GB RAM 服务器。反序列化时，相应进程的内存消耗会上升到 40 GB。这是明智的吗，因为Serialized object size vs in memory object size in Java 的最高投票回答说“内存中的大小通常在可序列化大小的一半到两倍之间！”我预计内存大小不会超过 15 GB，但 40 GB 太大了，因为其他进程也会被加载。
我曾想过使用http://docs.oracle.com/javase/7/docs/api/java/lang/instrument/Instrumentation.html 来测量内存中的大小，但Calculate size of Object in Java 说它“可用于获取特定于实现的对象大小的近似值”。因此，这将再次只是近似测量。
这里有什么我想念的吗。我也在关闭文件和缓冲阅读器。什么会占用所有内存？出于公司政策的原因，我无法分享代码 - 任何帮助或指示将不胜感激。谢谢
【问题讨论】：
-
你的 XMX 设置是什么？
-
大小通常取决于它是什么类型的对象。内存对象包括从基类继承的属性/字段，它们没有被序列化。
-
@JoeriHendrickx Xmx 设置为 60G。运行命令以 java -Xmx60g -d64 ...开头
-
这毫无意义。您说 40gb 太多了，因为其他进程将运行，但是您将 xx 设置为 60gb。将其降低到合理的数量，然后看看会发生什么。我的猜测是你的反序列化过程（和其他东西）产生了很多垃圾，GC 没有理由运行，因为你甚至没有接近你的 xmx 限制。
-
@JoeriHendrickx 40 GB 太多了，因为我们需要内存空间来加载其他进程，而对于这个特定的内存分析场景，这些进程没有加载。对于 7.4 GB 的磁盘序列化对象来说，40 GB 的内存空间太大了。我可能通过说将加载其他进程而引入了一些歧义。我的意思是，由于稍后会加载其他进程，所以我们不能承受仅仅因为 trie 对象而丢失这么多内存（40 GB）。在这个对象被序列化之前，内存消耗是相同的顺序，所以它可能不是反序列化垃圾，thanx
标签： java serialization memory-management deserialization trie