或者我可能会问较新的 GC 是否重要？
如果确实如此，那么是否希望通过查找表或使用弱引用（还有更多内存）来管理节点之间的链接，或者只是让所有节点相互指向就可以了。这是假设我有一个“处理”方法，其中节点或链接删除将所有对它的引用设置为空。
问题是如果 ram 中有一个大型数据库，如果它必须在图中评估很多长的随机循环，是否会对 GC 性能产生巨大影响？或不？
问问题
382 次
3 回答
7
垃圾收集的标记和清除方法对对象图的拓扑完全不敏感。一旦它到达一个已经被标记的对象，它就假定它的所有引用都被标记了，所以无论你如何设计你的结构都不会造成太大的伤害。
我的建议是让你的代码尽可能自然地适应问题，而对任何其他问题都非常松懈。当您遇到真正的性能/内存问题时，您才会停下来考虑优化。
于 2012-12-08T16:46:50.250 回答
0
HotSpot VM 的垃圾收集器不使用引用计数。有mark/sweep/compact收集器或复制收集器，它们都从其根（所有活动线程的调用堆栈上的局部变量，静态字段等）。
基本上，只要一个对象不能从任何根到达，那么它就是dead，无论有多少其他死对象引用它。在这种情况下，dead 实际上并不意味着对象的内存已经被释放，它只是说对象将在下次运行期间被 GC 回收（删除）。
简单来说，图遍历过程中 GC 访问的对象都是活着的，其他的都是死的。
因此，每当您对图形结构的所有外部引用都清空时，无论它保留多少内部引用，整个图形结构都将被垃圾收集。
这是Bob Lee对标记和扫描算法的一个很好的解释：
http://www.youtube.com/watch?v=KTC0g14ImPc#t=177s 及稍后在同一视频中： http ://www.youtube.com/watch?v=KTC0g14ImPc#t=2917s
于 2012-12-08T16:59:21.360 回答
0
如果 Java 的 GC 被循环引用破坏，那将是相当令人失望的。幸运的是，事实并非如此。不过，我不明白您问题的数据库部分。我认为，如果您能更具体地了解您实际尝试做的事情，那将会有很大帮助。
于 2012-12-08T16:17:21.713 回答