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