如果我的数百万个业务对象中的每一个都有多个引用，GC会慢很多吗？

Question

我有大约1000万个域对象，它们必须在内存中保留整个应用程序生命周期，但可以在任何时候逐个添加或删除。主存储为HashMap<Long, MyDO>

我的处理可以在基本的foreach循环中完成，但我可以通过映射一些对象字段(如HashMap<String, ArrayList<MyDO>> )来创建索引来优化一些操作，这将减少30-100倍的迭代次数，但总共处理2-5倍

所以问题是，如果我没有一个map，而是5个map，从而创建了对相同对象的5倍引用，那么对于大约1000万个长生命对象，GC会慢多少？

UPD简而言之:如果每秒有大约10M个对象添加/删除了大约1K个对象，使用带有盒键的通用java集合作为索引是可行的吗？

Answer 1

这可能没有什么不同。长寿的物体会被提升到很少被收集的永久区。这需要几代人才能升迁，在他们之前，他们必须从伊甸园复制到生存区。在这里，链接的数量并不重要。

所以问题是，如果我没有一个映射，而是5个映射，从而创建了对相同对象的5倍引用，那么对于大约1000万个长期存在的对象，GC的速度会慢多少？

。

我会说，引用的数量根本不算数。但是所有的映射条目实际上都是对象。然而，1000万听起来并不是一个大数字。

简而言之，

更新:如果每秒有大约10M个对象，大约1K个对象被添加/删除，使用带有盒键的通用java集合作为索引是可行的吗？

不知道，但您可以使用一些原始集合来避免它。你就不能简单地试一下吗？有三个有用的优化原则：

• 不要做！
• 如果你做了，现在就不要做！
• 如果你做了，没有measurement!

不要做

可能会发生GC开销可以忽略不计的情况，您会发现自己在浪费时间。

引用用于将对象标记为“正在使用”，但是一旦标记了对象，其他引用就什么也不做了。当然，他们必须接受检查，但这笔开销将计入裁判而不是裁判。因此，如果您创建了对单个对象的一百万个引用，那么耗费时间的是百万个对象，而不是单个对象。

Answer 2

我不确定这是否是一种情况，但如果你真的担心这种情况下的gc，你想更好地控制派生映射的行为，从而在我看来，他们对gc性能的影响，你应该看看不同类型的引用(强，弱，软，幻影)在java中的用法。

还要记住，预优化是一切邪恶的根源，尤其是在编程中。