11、其他
其他
finalize()方法最终判断对象是否存活
即使在可达性分析算法中不可达的对象,也并非是“非死不可"的,这时候它们暂时处于缓刑阶段,要真正宣告一个对象死亡,至少要经历再次标记过程。
标记的前提是对象在进行可达性分析后发现没有与 GC Roots相连接的引用链。
1、第一次标记并进行一次筛选
筛选的条件时此对象是否有必要执行finalize()方法
当对象没有覆盖finalize方法，对象将直接被回收
2、第二次标记
如果这个对象覆盖了finalize方法，fianlize方法是对象逃脱死亡命运的最后一次机会，如果对象要在finalize()中成功拯救自己，只要重新与引用链上的任何一个对象建立关联即可，譬如把自己赋值给某个类变量或对象的成员变量，那在第二次标记时它将移除“即将回收”的集合。如果对象这时候还没逃脱，拿基本上他就真的被回收了。
注意：一个对象的finalize()方法只会被执行一次，也就是说通过调用finalize方法自我救命的机会就一次。
如何判断一个类是无用的类
方法区主要回收的就是无用的类，那么如何判断一个类是无用的类呢？
类需要同时满足下面3个条件才算“无用的类”：
- 该类的对象实例都被回收，也就是Java堆中不存在该类的任何实例
- 加载该类的ClassLoader已经被回收
- 该类对应的java.lang.Class对象没有在任何地方被引用，无法在任何地方通过反射访问该类的方法。
每秒几十万并发的系统如何优化JVM
Kafka类似的支撑高并发消息系统大家肯定不陌生,对于 kafka来说,每秒处理几万甚至几十万消息时很正常的,一般来说部署kaKa需要用大內存机器(比如64G,也就是说可以给年轻代分配个三四十G的内存用来支撑高并发处理,这里就涉及到一个问题了,我们以前常说的对于eden区的 young gc是很快的,这种情况下它的执行还会很快吗?很显然,不可能,因为内存太大,处理还是要花不少时间的,假设三四十G内存回收可能最快也要几秒钟,按kaka这个并发量放满三四十G的eden区可能也就一两分钟吧,那么意味着整个系统每运行一两分钟就会因为 young go卡顿几秒钟没法处理新消息,显然是不行的。那么对于这种情况如何优化了,我们可以使用G1收集器,设置-XX: MaxGCPauseMills为50ms,假设50ms能够回收三到四个G内存,然后50ms的卡顿其实完全能够接受,用户几乎无感知,那么整个系统就可以在卡顿几乎无感知的情况下一边处理业务一边收集垃圾。
G1天生就适合这种大内存机器的JMM运行,可以比较完美的解决大内存垃圾回收时间过长的问题。
