HotSpot VM的垃圾收集器不使用引用计数。有标记/扫描/压缩收集器或复制收集器，这两个收集器都从其根(所有活动线程的调用堆栈上的本地变量、静态字段等)遍历对象图(这里指JVM中所有Java对象的图)
或者我可能会问，对于较新的GC，这有关系吗？
如果是这样的话，那么希望通过查找表或使用弱引用(更多的内存)来管理节点之间的链接，或者只让所有节点指向彼此就可以了。这是假设我有一个"dispose"方法，其中节点或链接删除将对它的所有引用设置为null。
问题是，如果ram中有一个大型数据库，如果它必须评估图中的许多长随机周期，这会对GC性能造成严重影响吗？还是不？
垃圾收集的标记和清除方法对对象图的拓扑结构完全不敏感。一旦它到达一个已经标记的对象，它就会假设它的所有引用也都被标记了，所以无论你如何设计你的结构，都不会造成太大的伤害。
我的建议是，要坚持让你的代码尽可能自然地适应问题，对任何其他问题都要松懈。当你遇到真正的性能/内存问题时，只有到那时你才会停下来考虑优化。
如果Java的GC被循环引用破坏，那将非常令人失望。幸运的是，事实并非如此。不过，我不理解你问题的数据库部分。我认为如果你能更具体地了解你真正想做的事情，那会有很大帮助
基本上，每当一个对象不能从任何根访问时，无论有多少其他死对象引用它，它都只是死。在这种情况下，死并不意味着对象的内存已经释放，它只是说GC将在下一次运行时回收(删除)该对象。
简单地说，GC在图遍历过程中访问的所有对象都是活着的，其他所有对象都已经死了。
因此，每当您将图结构的所有外部引用置空时，无论保留多少内部引用，整个图结构都将被垃圾收集。
以下是对mark&Bob Lee的sweep算法：
http://www.youtube.com/watch?v=KTC0g14ImPc#t=177s稍后在同一视频中：http://www.youtube.com/watch?v=KTC0g14ImPc#t=2917s