补充知识：沙箱安全机制+老年代的空间分配担保+对象回收过程

《深入理解java虚拟机》

一、沙箱安全机制

1.什么是沙箱？

沙箱是一个限制程序运行的环境。沙箱机制就是将Java代码限定在虚拟机(JVM)特定的运行范围中，并且严格限制代码对本地系统资源访问，通过这样的措施来保证对代码的有效隔离，防止对本地系统造成破坏。Java安全模型的核心就是Java沙箱（sandbox）。

沙箱主要限制系统资源访问，那系统资源包括什么？——CPU、内存、文件系统、网络。不同级别的沙箱对这些资源访问的限制也可以不一样。

所有的Java程序运行都可以指定沙箱，可以定制安全策略。

推荐阅读传送门：

 java中的安全模型(沙箱机制)_改变ing的博客-CSDN博客_沙箱安全机制

二、老年代的空间分配担保

1.什么是空间分配担保？

在发生Minor GC之前，虚拟机必须先检查老年代最大可用的连续空间是否大于新生代所有对象总 空间，如果这个条件成立，那这一次Minor GC可以确保是安全的。如果不成立，则虚拟机会先查看-XX：HandlePromotionFailure参数的设置值是否允许担保失败（Handle Promotion Failure）；如果允 许，那会继续检查老年代最大可用的连续空间是否大于历次晋升到老年代对象的平均大小，如果大 于，将尝试进行一次Minor GC，尽管这次Minor GC是有风险的；如果小于，或者-XX： HandlePromotionFailure设置不允许冒险，那这时就要改为进行一次Full GC。

2.为什么说尝试的Minor GC是“有风险的”？

前面提到过，新生代使用复制收集算法，但为了内存利用率， 只使用其中一个Survivor空间来作为轮换备份，因此当出现大量对象在Minor GC后仍然存活的情况 ——最极端的情况就是内存回收后新生代中所有对象都存活，需要老年代进行分配担保，把Survivor无 法容纳的对象直接送入老年代，这与生活中贷款担保类似。老年代要进行这样的担保，前提是老年代 本身还有容纳这些对象的剩余空间，但一共有多少对象会在这次回收中活下来在实际完成内存回收之 前是无法明确知道的，所以只能取之前每一次回收晋升到老年代对象容量的平均大小作为经验值，与 老年代的剩余空间进行比较，决定是否进行Full GC来让老年代腾出更多空间。

取历史平均值来比较其实仍然是一种赌概率的解决办法，也就是说假如某次Minor GC存活后的对 象突增，远远高于历史平均值的话，依然会导致担保失败。如果出现了担保失败，那就只好老老实实 地重新发起一次Full GC，这样停顿时间就很长了。虽然担保失败时绕的圈子是最大的，但通常情况下 都还是会将-XX：HandlePromotionFailure开关打开，避免Full GC过于频繁。

在JDK 6 Update 24之后，-XX：HandlePromotionFailure参数不会再影 响到虚拟机的空间分配担保策略，观察OpenJDK中的源码变化（见代码清单3-12），虽然源码中还定 义了-XX：HandlePromotionFailure参数，但是在实际虚拟机中已经不会再使用它。JDK 6 Update 24之 后的规则变为只要老年代的连续空间大于新生代对象总大小或者历次晋升的平均大小，就会进行 Minor GC，否则将进行Full GC。

三、对象的回收过程？

JVM 在对 Java 对象回收阶段进行两次标记，一次筛选。

1.如果对象在进行可达性分析后发现没 有与GC Roots相连接的引用链，那它将会被第一次标记

2.随后进行一次筛选，筛选的条件是此对象是 否有必要执行finalize()方法。也就是被回收对象是否重写过 finalize() 方法，且该重写方法并未被虚拟机调用过，不满足直接进行回收。

3.如果满足，那么该对象将会被放置在一个名为F-Queue的 队列之中，并在稍后由一条由虚拟机自动建立的、低调度优先级的Finalizer线程去执行它们的finalize() 方法。这个线程只是会触发这个方法开始运行，但并不一定会等待它运行结束。因为如果某个对象的finalize()方法执行缓慢，或者更极端地发生了死循环，将很可能导 致F-Queue队列中的其他对象永久处于等待，甚至导致整个内存回收子系统的崩溃。

4.稍后收集器将对F-Queue中的对象进行第二次小规模的标记，如果对 象在finalize()中重新与引用链上的任何一个对象建立了关联，比如：如把自己 （this关键字）赋值给某个类变量或者对象的成员变量，那在第二次标记时它将被移出“即将回收”的集 合；如果对象这时候还没有逃脱，那基本上它就真的要被回收了。

所以说：finalize()方法是对 象逃脱死亡命运的最后一次机会。

注意：为任何一个对象的finalize()方法都只会被系统自动调用一次，如果对象面临 下一次回收，它的finalize()方法不会被再次执行。

它的运行代价高昂，不确定性大，无法保证各个对象的调用顺序，如今已被官方明确声明为 不推荐使用的语法。