最近参与到android的项目开发,对java的内存的管理有了一个初步的了解,很容易想到了循环引用的问题。好比下面这个例子:html
public void buidDog()java
{android
Dog newDog = new Dog();函数
Tail newTail = new Tail();ui
newDog.tail = newTail;编码
newTail.dog = newDog;线程
}指针
在这里,newTail中拿着对newDog的引用,newDog中拿着对newTail的引用。若是newDog要被回收,前提是newTail被先回收,这样才能释放对newDog的引用。可是反回过来,newTail要被回收的前提是newDog要被先回收。当buildDog函数退出后,看起来垃圾回收管理彷佛就始终没法回收这两个实际已经再也不须要的对象。code
垃圾回收机制究竟可否解决循环引用这一困境,带着这个疑问找了一些资料,找到了一个比较满意的解释。在《Java Platform Performance: Strategies and Tactics》这本书的附录A中有一处说明,这本书出自sun公司java团队员工,应该算比较权威的。其中有这样一段(http://java.sun.com/docs/books/performance/1st_edition/html/JPAppGC.fm.html#997428):orm
“It's important to note that not just any strong reference will hold an object in memory. These must be references that chain from a garbage collection root. GC roots are a special class of variable that includes
Temporary variables on the stack (of any thread)
Static variables (from any class)
Special references from JNI native code”。
这段话能够简单的理解就是强引用并不能保证对象不被回收。垃圾回收机制除了检查对象是否被引用外,还要看对象是否被至少一个GC roots对象直接或者间接引用。GC roots对象包括如下一些类容:
1 每一个线程当前的函数调用栈,从栈顶到栈底的每一个函数里的局部变量。
2 静态的变量
3 被jni中引用到的变量。
因此,上面例子中两个循环引用的对象,虽然都存在一个强引用,可是不被任何GC root对象直接或者间接引用到,垃圾回收机制可以发现这个问题。
另外,为了验证这一点,特地翻看了一下android源码中GC管理这一块的代码。在MarkSweep.c这文件中,有一个void dvmHeapMarkRootSet()函数,这个函数对于GC root对象,有一些详细的说明,有兴趣的能够细看一下。
因此,java对于循环引用有一套本身的解决方案。可是话又说回来,通常实际编码中出现的循环引用不会是上面那个例子那样明显,通常都是多个对象复杂的引用致使的循环,这个时候,若是一个对象的生命周期很长,就会致使多个对象都释放不了,因此仍是要特别留意对象之间的引用关系。