本地搭建网站,wordpress添加文章副标题,个人网站制作设计,网站制作的销售对象第3章 垃圾收集器与内存分配策略
3.2 对象已死
Java世界中的所有对象实例#xff0c;垃圾收集器进行回收前就是确定对象哪些是活着的#xff0c;哪些已经死去。
3.2.1 引用计数算法
常见的回答是#xff1a;给对象中添加一个引用计数器#xff0c;有地方引用#xff0…第3章 垃圾收集器与内存分配策略
3.2 对象已死
Java世界中的所有对象实例垃圾收集器进行回收前就是确定对象哪些是活着的哪些已经死去。
3.2.1 引用计数算法
常见的回答是给对象中添加一个引用计数器有地方引用计数器1引用失效计数器-1任何时刻计数器为零的对象就是不可能再被使用了。
引用计数算法(Reference Counting)占了一些额外内存空间来计数但原理简单判定效率高大多数下也是一个好的算法。
Java领域主流虚拟机都没用引用计数算法原因为看似简单很多例外情况要考虑要配合大量额外处理才能保证正确地的工作例如很难解决对象之间相互循环引用的问题。
引用计数算法陷阱
package a.b.c;/*** */
public class ReferenceCountingGC {public Object instance null;private static final int _1MB 1024 * 1024;/*** 意义就是占点内存以便能在GC日志中清楚是否有回收过*/private byte[] bigSize new byte[2 * _1MB];public static void testGC() {ReferenceCountingGC objA new ReferenceCountingGC();ReferenceCountingGC objB new ReferenceCountingGC();objA.instance objB;objB.instance objA;objA null;objB null;System.out.println(---------进行GC!---------);//假设在这行发生GCobjA和objB是否能被回收System.gc();}public static void main(String[] args) {testGC();}} 证明虚拟机没有因为两个对象互相引用就放弃回收它们。
所以Java虚拟机不是通过引用计数算法判断对象是否存活的。
3.2.2 可达性分析算法
Java通过可达性分析(Reachability Analysis)算法来判定对象是否存活。
基本思路通过一些列GC Roots的根对象作为起始节点集根据引用关系向下搜索搜索过程所走过的路径称为引用链(Reference Chain)如果某对象到GC Roots间没有任何引用链相连说明这个对象不可达证明此对象不可能再被使用。 Java技术体系里固定可作为GC Roots的对象包括以下几种
虚拟机栈(栈帧中的本地变量表)中引用的对象各个线程被调用的方法堆栈中使用到的参数、局部变量、临时变量等。方法区中类静态属性引用的对象。方法区中常量引用的对象字符串常量池(String Table)里的引用。本地方法栈中JNI(Native方法)引用的对象。Java虚拟机内部的引用如基本数据类型对应的Class对象常驻的异常对象NullPointExceptionOutOfMemoryError等系统类加载器。被同步锁(synchronized关键字)持有的对象。反映Java虚拟机内部情况的JMXBeanJVMTI中注册的回调、本地代码缓存等。
3.2.3 再谈引用
Java引用的传统定义如果reference类型的数据中存储的数值代表的是另一块内存的起始地址就称该reference数据是代表某块内存某个对象的引用。
更广义的讲Java对引用的概念进行了扩充将引用分为**强引用(Strongly Reference)、软引用(Soft Reference)、弱引用(Weak Reference)和虚引用(Phantom Reference)**4种引用强度依次减弱。
强引用是最传统的引用指在程序代码中普遍存在的引用赋值类似Object obj new Object()这种引用关系无论任何情况下只要强引用关系还存在垃圾收集器就永远不会回收掉被引用的对象。软引用用来描述一些还有用但非必须得对象只被软引用关联着的对象在系统发生内存溢出异常前会把这些对象列进回收范围之中进行第二次回收如果这次回收如果这次回收还没有足够内存会抛出内存溢出异常JDK1.2之后提供SoftReference类来实现软引用。弱引用也是用来描述非必须对象强度比软引用更弱被弱引用关联的对象只能生存到下一次垃圾收集发生为止当垃圾收集器开始工作无论当前内存是否足够都会回收弱引用关联的对象提供WeakReference类来实现。虚引用也称为幽灵引用或幻影引用最弱的引用关系一个对象是否有虚引用存在不会对其生成时间构成影响也无法通过虚引用获取对象实例唯一目的是为了能在这个对象被收集器回收时收到一个系统通知PhantomReference类实现。
3.2.4 生存还是死亡
可达性分析算法判定为不可达对象也不似非死不可这时候处于缓刑宣告对象死亡要经历两次标记过程对象可达性分析后没有与GC Roots相连接的引用链第一次标记对象没有覆盖finalize()方法或此方法已经被虚拟机调用过虚拟机将这两种情况视为没有必要执行。
对象被判定为执行finalize()方法会被放到F-Queue队列中由虚拟机自动建立低调度优先级的Finalizer线程去执行它们的finalize()方法。
最后一次逃脱机会是在F-Queue队列的对象被收集器第二次小规模标记若对象重新与引用链连接上第二次标记会溢出即将回收的集合若没有逃脱那么就要回收了。
一次对象的自我拯救演示
package a.b.c;public class FinalizeEscapeGC {public static FinalizeEscapeGC SAVE_HOOK null;public void isAlive() {System.out.println(yes,i am still alive 0.0);}Overrideprotected void finalize() throws Throwable {super.finalize();System.out.println(finalize method executed!);FinalizeEscapeGC.SAVE_HOOK this;}public static void main(String[] args) throws InterruptedException {SAVE_HOOK new FinalizeEscapeGC();//对象第一次成功拯救自己SAVE_HOOK null;System.gc();//因为Finalizer方法优先级很低暂停0.5秒等待它Thread.sleep(500);if(SAVE_HOOK!null) {SAVE_HOOK.isAlive();} else {System.out.println(no,i am dead *.*);}//下面这段代码与上面完全相同但这次自救却失败了SAVE_HOOK null;System.gc();//因为Finalizer方法优先级很低暂停0.5秒等待它Thread.sleep(500);if(SAVE_HOOK!null) {SAVE_HOOK.isAlive();} else {System.out.println(no,i am dead *.*);}}}两段完全一样的代码执行结果一次逃脱成功一次失败因为finalize()方法只会被系统自动调用一次第二次不执行了第二段代码自救失败了。
finalize()方法不推荐使用把它忘了吧。
3.2.5 回收方法区
方法区垃圾收集性价比低主要回收废弃的常量和不再使用的类型如没有任何一个字符串对象引用常量池中的java常量虚拟机中其他地方也没引用则它会被系统清理出常量池。
不是使用的类判定起来比较苛刻
该类以及子类所有实例已经被回收。加载该类的类加载器已经被回收。该类对应的java.lang.Class对象没有在任何地方被引用无法在任何地方通过反射访问该类的方法。
也仅仅是被允许提供了一系列参数控制类的卸载自己查吧。
大量使用反射动态代理CGLib等字节码框架动态生成JSP以及OSGi这类频繁自定义类加载器的场景通常都需要具备Java虚拟机类型卸载的能力保证不会对方法区造成过大的内存压力。
3.3 垃圾回收算法
理论细节参考《垃圾回收算法手册》2~4章内容。
垃圾回收算法可划分为**引用计数式垃圾收集(Reference Counting GC)和追踪式垃圾收集(Tracing GC)**两大类。
主流Java虚拟机都采用的是追踪式垃圾收集。
3.3.1 分代收集理论
当前商业虚拟机的垃圾收集器大多数遵循分代收集(Generational Collection)的理论进行设计。是程序的经验法则建立在两个分代假说之上
1.弱分代假说(Weak Generational Hypothesis)绝大多数对象都是朝生夕死。
2.强分代假说(Strong Generational Hypothesis)熬过越多次垃圾收集过程的对象就越难消亡。
这两个假说奠定了垃圾收集器的一致设计原则
收集器将Java堆划分出不同的区域将回收对象依据年龄(熬过垃圾收集的次数)分配到不同的区域之中存储。大多数朝生夕死的对象放在一起每次回收只关注少量存活的对象而不去标记大量要被回收的对象以低频率来回收这个区域同时兼顾了垃圾收集的时间开销和内存空间的有效利用。
Java堆划分区域后每次只回收某一个或某部分区域也就有了**“Minor GC新生代垃圾回收”,“Major GC老年代垃圾回收”,“Full GC”**这些回收类型的划分也就有了针对不同区域与存储对象存亡特征相匹配的垃圾收集算法“标记-清除算法”,“标记-整理算法”,“标记清除算法”。Minor:/ˈmaɪnər/未成年少数的次要的Major/ˈmeɪdʒər/主要的大的。
一般至少会把堆分为新生代(Young Generation)和**老年代(Old Generation)**两个区域。
新生代中每次垃圾收集都发现大批对象死去每次回收后存活的少量对象都会逐步晋升到老年代中存放。分代收集并非简单划分内存区域那么简单至少有1条对象不是孤立的对象之间会存在跨代引用。
假设进行新生代区域的收集(Minor GC)新生代对象可能被老年代所引用为找出新生代中的存活对象不得不在固定的GC Roots之外再额外遍历整个老年代中所有对象来确保可达性分析结果的正确性反过来也一样。遍历老年代所有对象可行但为内存回收带来很大的性能负担为解决这个问题添加第三条经验法则
3.跨代引用假说(Intergenerational Reference Hypothesis)跨代引用相对于同代引用来说仅占极少数。
隐含推论存在互相引用关系的两个对象应该倾向于同时生存或者同时消亡的。
如某新生代对象引用老年代对象老年代对象难以消亡新生代对象得以存活进而年龄增长后晋升到老年代中这时跨代引用也随之消除了。
根据第3假说不应该为少量跨代引用去扫描整个老年代也不必浪费空间记录每个对象是否存在跨代引用只需再新生代上建立全局的数据结构(记忆集Remembered Set)此结构把老年代划分若干小块标识老年代哪块内存存在跨代引用发生MinorGC时跨代引用小块的对象才会被加入到GC Roots进行扫描。改变引用关系维护记录数据的正确性会增加一点开销但是比起扫描整个老年代来说还是划算的。
收集分类
部分收集(Partial GC)指目标不是完整收集整个Java堆而是收集部分又分为 新生代收集(Minor GC/Young GC)只收集新生代的垃圾收集。老年代收集(Major GC/Old GC)只是老年代的垃圾收集。目前只有CMS会单独收集老年代的行为另外注意Major GC说法有混淆根据上下文看到底是指老年代收集还是整堆收集。混合收集(Mixed GC) 整堆收集(Full GC)收集整个Java堆的方法区的垃圾收集。
3.3.2 标记-清除算法
最基础的垃圾收集算法**标记-清除(Mark-Sweep)**算法。
算法分为两阶段
标记阶段标记所有需要回收的对象。清除阶段标记完成后回收掉所有被标记的对象。
缺点有两个
执行效率不稳定堆中包含大量对象大部分需要被回收要进行大量标记和清除动作两个动作的执行效率随对象数量增长而降低。内存碎片化问题清除后产生大量不连续的内存碎片碎片太多当程序需要分配大对象时无法找到连续的内存而不得不提前触发一次垃圾收集动作。 3.3.3 标记-复制算法
简称为复制算法解决了大量可回收对象执行效率低的问题。
最早提出的了半区复制(Semispace Copying)将可用内存按容量划分为大小相等的两块每次只使用其中的一块一块用完将存活的对象复制到另外一块上面把已使用过的内存空间一次清理掉。
优点不用考虑内存碎片,分配内存时移动堆顶的指针按顺序分配即可实现简单运行高效。
缺点可用内存缩小为原来的一半空间浪费太多。 现在的Java虚拟机优化了这种收集算法。
新生代中的对象98%熬不过第一轮收集因此不需要1:1的比例来划分新生代的内存空间。
更优化的半区复制分代策略称为Appel式回收。 HotSpot虚拟机的Serial、ParNew等新生代收集器采用这种策略。
新生代内存区域每次使用Eden其中1个Survivor共计90%内存区域。
Eden80%Survivor0,10%Survivor1,10%
老年代内存区域
若上面Minor GC垃圾回收后复制到Survivor中的对象超过10%触发了分配担保(Handle Promotion)将这些对象直接进入到老年代这是安全的。
3.3.4 标记-整理算法
复制算法中对象存活率高的极端情况复制操作多效率低而且不想浪费50%内存就要进行分配担保用来应对100%对象存活的极端情况所有老年代一般不能直接选用这种算法。
根据老年代对象活的久的特点提出了标记-整理算法(Mark-Compact).
标记过程还是标记-清除算法。
整理过程将所有存活的对象向内存空间一端移动然后直接清理边界以外的内存。 移动存活的对象是极重的负担 操作过程要暂停用户应用程序才能进行。
Stop The World全局停止世界停止这个系统开销也了不得。
如果不考虑移动和整理的话空间碎片化问题就要用分区空闲分配链表来解决增加额外负担影响程序的吞吐量。
基于以上了两点是否移动对象都有弊端移动则内存回收复杂不移动则内存分配复杂。
有一种折中的方法虚拟机平时多数时间采用标记-清除算法暂时容忍碎片知道内存碎片大到影响对象分配时再采用标记整理算法收集一次以获得规整的内存空间基于标记-清除算法CMS收集器面临的空间碎片过多时就采用这种办法。
3.4 HotSpot的算法细节实现
较枯燥可先看垃圾收集器。
3.5 经典垃圾收集器
如果说收集算法是内存回收的方法论那垃圾收集器就是内存回收的实践者。
规范没有对垃圾回收器的实现做规定。
各款经典收集器之间的关系图 展示了7种作用于不同分代的收集器两个收集器之间存在连线就说明它们可以搭配使用。
收集器所处的区域标识它们属于新生代收集器或是老年代收集器(Tenured,终身的长期保有的)。
明确一个观点各个收集器的比较不是挑选最好的收集器出来没出现最好的收集器更不存在万能收集器只是选择最合适的收集器。
新生代垃圾回收器SerialParNewParallelScavenge
老年代垃圾回收器CMS,Serial Old(MSC),Parallel Old
3.5.1 Serial收集器
Serial/ˈsɪəriəl/连续的排成顺序的。
最基础历史最悠久JDK1.3.1之前是新生代收集器的唯一选择。
单线程工作的收集器。
不仅仅使用一个处理器或一条收集线程去完成垃圾收集工作进行垃圾收集时必须暂停其他所有工作线程直到它收集结束。
会Stop The World在用户不可知的情况下把正常工作的线程全部停掉这无法接受。
下图Serial/Serial Old收集器的运行过程。 给用户带来恶劣体验早起设计者们完全理解但也很委屈你妈妈给你打扫房间的时候肯定会让你老老实实的在椅子上或者房间外待着如果她一边打扫一边扔纸屑这房间还能打扫完这也合情合理。
看似老而无用实则依然是HotSpot运行在客户端模式下默认的新生代收集器。
优点简单而高效内存受限的情况下内存额外消耗最小对于单核或处理器核心少的环境来说没有线程交互的开销尤其微服务应用中分配内存小收集几十到一两百兆新生代垃圾回收停顿时间可以控制在十几、几十毫秒最多100毫秒以内只要不频繁发生这些停顿时间可以接受。
缺点单线程暂停世界导致全部工作线程频繁停顿不适合在大内存虚拟机中使用。
3.5.2 ParNew收集器
ParNew是Serial收集器的多线程并行版本。
除了使用多条线程进行垃圾收集之外其余包括Serial可用的所有控制参数
-XX:SurvivorRatio,ratio(比例)SurvivorRatio 指的是幸存区比例。在垃圾回收机制中通常会有新生代和老年代等不同的内存区域划分而新生代中又有 Eden 区和两个 Survivor 区。SurvivorRatio 这个参数用于设置 Eden 区和 Survivor 区的大小比例关系。例如如果设置为 8则表示 Eden 区和 Survivor 区的大小比例为 8:1:1。
-XX:PretenureSizeThreshold中文意思是 “晋升到老年代的大小阈值”。在 Java 虚拟机中这个参数用于设置对象从新生代晋升到老年代之前的大小阈值。如果对象的大小超过这个阈值就会直接晋升到老年代而不是在新生代中经历多次垃圾回收。这个参数可以帮助优化垃圾回收的性能根据不同的应用场景进行调整。例如对于创建大型对象较多的应用可以适当调大这个阈值以减少新生代的垃圾回收次数。一般来说大对象是32K也有1M或2M。
-XX:HandlerPromotionFailure垃圾回收GC过程中的对象晋升失败相关,原因有老年代空间不足老年代内存碎片放不下晋升的对象大对象直接分配给老年代导致老年代空间不足。老年代还未充分整理新生代对象就晋升为老年代导致空间不足JVM设置的老年代太小导致无法满足晋升的需求。
收集算法暂停世界对象分配规则等与Serial收集器完全一致共用很多代码。
ParNew收集器工作过程 是JDK7之前遗留系统中首选的新生代收集器。
有一个重要原因除Serial收集器外只有它能与CMS收集器配合工作。
ParNew是激活CMS后的默认新生代收集器也只能相互搭配使用不能和其他收集器配合了。
并行(Parallel):并行描述的是多条垃圾收集器线程之间的关系说明同一时间有多条线程在协同工作通常默认此时用户线程是出于等待状态。并发(Concurrent)并发描述的垃圾收集器线程和用户线程之间的关系说明同一时间垃圾收集器线程与用户线程都在运行。
3.5.3 Parallel Scavenge(清理)收集器
也是新生代收集器基于标记复制算法能够并行收集的多线程收集器。
特点与其他不同CMS等关注点是缩短用户线程的停顿时间。
而它则是达到一个可控制的吞吐量(Throughput)。
$ 吞吐量\frac{运行用户代码时间}{运行用户代码时间运行垃圾收集时间} $
如果虚拟机完成某个任务总共耗费100分钟垃圾收集花费1分钟吞吐量就是99%。
Parallel Scavenge收集器提供两个参数用于精确控制吞吐量
最大垃圾收集停顿时间-XX:MaxGCPauseMillis大于0的毫秒数越小频率越高
直接设置吞吐量大小-XX:GCTimeRatio0整数100默认99则允许1%19则是5%。
也经常被称为吞吐量优先收集器
自适应调节策略(GC Ergonomics)也是Parallel Scavenge收集器区别于ParNew收集器的重要特征,把内存管理的调优任务交给虚拟机完成把内存数据设置好-Xmx。
3.5.4 Serial Old收集器
是Serial收集器的老年代版本同样是一个单线程收集器使用标记复制算法。
JDK5之前与Parallel Scavenge收集器搭配使用。
作为CMS收集器发生失败时的后备预案。 3.5.5 Parallel Old收集器
Parallel Old是Parallel Scavenge收集器的老年代版本支持多线程并发收集标记-整理算法。 3.5.6 CMS收集器
CMS(Concurrent Mark Sweep)是以获取最短回收停顿时间为目标的收集器。
B/S架构更关注服务的响应速度希望系统停顿时间更短CMS更符合要求。
基于标记-清除算法实现的
初始标记(CMS initial mark),标记GC Roots关联到的对象速度很快会Stop The World。并发标记(CMS concurrent mark)通过GC Roots的直接关联对象遍历整个对象图的过程可与用户线程并发。重新标记(CMS remark)修正并发标记期间用户继续运行导致的标记产生变动的对象会STW并发清除(CMS concurrent sweep)并发删除掉已经判断死亡的对象可与用户线程并发。 优点并发收集、低停顿。
缺点1.对处理器资源敏感核心4个以上并发回收线程不超过25%2.无法处理浮动垃圾(新产生的垃圾)3.空间碎片多空间不够分配对象会Full GC。
3.5.7 Garbage First收集器
G1全功能垃圾回收器服务端默认回收器。
开创Region布局遵循分代理论但是堆内存划分为大小相等的独立区域(Region)每个区域可以根据需要扮演新生代Eden,Survivor,老年代。
Region中超过容量(1-32MB,为2的幂,通常2MB)的一半判定为大对象存放在多个Humongous Region块中把它看成老年代。 6-8GB内存以上G1表现更好否则CMS。
3.6 低延迟垃圾收集器
垃圾收集器三项最重要指标内存占用(Footprint)、吞吐量(Throughtput)、延迟(Latency)。
不可能三角最多占两个。延迟是最重要的指标。 3.6.1 Shenandoah收集器(谢南多厄
同G1相似基于Region堆放大对象Humongous Region优先处理回收价值最大的Region。
不同点支持并发整理算法回收阶段以多线程并行却不能与用户线程并发。不分代。
工作过程分为9个阶段
等待。。。 3.6.2 ZGC收集器
JDK11加入低延迟垃圾收集器。垃圾收集停顿时间限制在10毫秒。
也采用Region堆内存布局 待定。。。
3.7 选择合适的垃圾收集器
3.8 实战内存分配与回收策略
3.8.1 对象优先在Eden分配
3.8.2 大对象直接进入老年代
3.8.3 长期存活的对象将进入老年代
3.8.4 动态对象年龄判定
