写一点java虚拟机中垃圾回收的小知识
前几年的时候如果是去面试java后端开发，其实这个说法有点不对啊。原因其实是早几年的时候前后端分离这种提法还没有那么流行，一个java开发一般情况来说前后端都是会的，springmvc那一套东西很强啊。jquery,js,css,html等等都会，所以啊那时候的java真就像全栈。现在嘛，前后端分离，更加的专业化了，个人觉得这挺好的，人嘛精力是有限的，不可能什么都懂，什么都会，什么都精，那应该是不可能的，至少目前还没有见得过这样的人，也许是我的见识太少了。老话不是说一心不能二用嘛。
大项目用springmvc还是比springboot好，不过又搞出了一个微服务，这个东西就很厉害了。现在都在用springboot这套技术了，当然那些什么祖传的项目另说。
谈回面试，面试的时候早几年如果懂java虚拟机，那是一个面试的亮点啊，面试官会对你另眼相看，现在嘛，如果虚拟机都不懂还去面试啥java啊，这都算是必备的技能了（这里插一句：现在微服务也成为了必备技能，很多公司就算现在没有用微服务，进去面试的时候也会问相关的问题）
说回垃圾回收，这里就不完整的讲了，就讲其中的一个点，对象的回收判断。面试官一般都会问垃圾回收的时候怎么判断这个对象已经死亡。
这时候一般回答就是两种判断算法：
引用计数法：给每个对象一个计数器，有引用的时候就加一，引用失效的时候就减一，当其引用为0时对象判断完死亡。缺点就是当以对象出现相互引用的时候没有办法回收，造成内存泄漏。
可达分析法: 由根结点(GCRoot)出发向下搜索，所走过的路径称为引入链，当一个对象GCRoot不能到达的时候，就判断这个对象死亡。解决了前面引用计数法中两个对象相互调用的问题。
这样回答挺可以了。那如果再问你一个问题，哪些对象做GCRoot？
一下脑子里一想没有答案了。
这里说一下可作为GCRoot对象的有以下四种：
1.虚拟机栈中的引入对象。
2.方法区中类静态属性引用的对象。
3.方法区中常量引用的对象。
4.本地方法栈中JNI(Native方法）引用对象。
另一个问题，那就是前面的方法判断对象死亡后是不是就非死不可呢？其实前面的判刑之后，还没有死，只是给了一个判断，并没有执行，还有自我救赎的机会。
判断后，会对其执行finalize()方法。
有没有必要执行另说。两种情况判断为没有必要执行：
- 对象没有覆盖finalize()方法
- finalize()方法已经被虚拟机调用过。
如果被判断为有必面执行，会先放在一个F-Queue的队列中，并由虚拟机自动建立、低优先级的Finalizer线程去执行。finalize()方法是对象最后的机会，稍后GC对F-Queue进行小规模标记，如果这时候对象重新建立链接引用，就自救成功，否则就被回收了。
