保定市网站设计,网站建设的方式有哪些内容,嵌入式硬件开发,软件公司网站设计总框架 一、Java自动内存管理基础
1、运行时数据区 运行时数据区可分为线程隔离和线程共享两个维度#xff0c;垃圾回收主要是针对堆内存进行回收
#xff08;1#xff09;线程隔离
程序计数器 虚拟机多线程是通过线程轮流切换、分配处理器执行时间来实现的。为了线程切换…总框架 一、Java自动内存管理基础
1、运行时数据区 运行时数据区可分为线程隔离和线程共享两个维度垃圾回收主要是针对堆内存进行回收
1线程隔离
程序计数器 虚拟机多线程是通过线程轮流切换、分配处理器执行时间来实现的。为了线程切换后能恢复到正确的执行位置每个线程需要有一个独立的程序计数器 虚拟机栈 每个方法被执行都会创建一个栈帧栈深度大于虚拟机所允许的最大深度抛出StackOverflowError异常 栈扩展时无法申请到足够的内存会抛出OutOfMemoryError异常 本地方法栈 与虚拟机栈的作用相似只是针对本地方法
2线程共享
堆 垃圾收集器管理的内存区域存放对象实例所有线程共享 方法区 用于存储已被虚拟机加载的类型信息、常量、静态变量、即时编译器编译后的代码缓存等数据如果方法区无法满足新的内存分配需求时将抛出OutOfMemoryError异常运行时常量池
2、对象的创建流程
检查对象所对应的类是否已经被加载过如果没有要先执行类加载过程为新生对象分配内存把一块确认大小的内存从Java堆中划分出来 划分可用的空间 堆是否规整由所采用的垃圾收集器是否带有空间压缩整理的能力决定指针碰撞简单高效规整内存使用过的放在一边没有使用过的放在另外一边空闲列表复杂不规整内存维护一个列表记录哪些内存块可用 线程安全问题的解决 时间维度对分配内存空间的动作进行同步处理实际上虚拟机采用了CAS配上失败重试方式保证更新操作的原子性空间维度把内存分配的动作按照线程划分在不同的空间中进行给线程预分配隔离的内存 将分配到的内存空间初始化为零值各个类型的默认值对对象进行必要的信息设置对象哈希码、GC分代信息等执行构造函数初始化对象属性
二、垃圾收集器与内存分配策略
1、如何判断对象已死
1引用计数法
给对象添加一个计数器每当一个地方引用这个对象时计数器1每当取消引用时计数器-1如果计数器为0就说明对象没有被引用
优点实现简单判断效率高
缺点没办法解决循环引用问题
循环引用典型例子
2可达性分析算法
基本思路就是通过一系列称为“GC Roots”的根对象作为起始节点集从这些节点开始根据引用关系向下搜索搜索过程所走过的路径称为“引用链”Reference Chain如果某个对象到GC Roots间没有任何引用链相连或者用图论的话来说就是从GC Roots到这个对象不可达时则证明此对象是不可能再被使用的。
在Java技术体系里面固定可作为GC Roots的对象包括以下几种
在虚拟机栈栈帧中的本地变量表中引用的对象譬如各个线程被调用的方法堆栈中使用到的参数、局部变量、临时变量等。在方法区中类静态属性引用的对象譬如Java类的引用类型静态变量。·在方法区中常量引用的对象譬如字符串常量池String Table里的引用。在本地方法栈中JNI即通常所说的Native方法引用的对象。Java虚拟机内部的引用如基本数据类型对应的Class对象一些常驻的异常对象比如NullPointExcepiton、OutOfMemoryError等还有系统类加载器。所有被同步锁synchronized关键字持有的对象。反映Java虚拟机内部情况的JMXBean、JVMTI中注册的回调、本地代码缓存等。
除了这些固定的GC Roots集合以外根据用户所选用的垃圾收集器以及当前回收的内存区域不同还可以有其他对象“临时性”地加入共同构成完整GC Roots集合。
可达性分析的扫描过程中如果用户线程是冻结的只有收集器线程在工作那不会有任何问题但如果是用户线程与收集器并发工作呢
可能会有两种后果
一种是把原本消亡的对象错误标记为存活这不是好事但其实是可以容忍的。只不过产生了一点逃过本次收集的浮动垃圾而已下次收集清理掉就好。另一种是把原本存活的对象错误标记为已消亡这就是非常致命的后果了程序肯定会因此发生错误。
触发第二种后果的两个必要条件
并发收集过程中插入了一条或多条从黑色对象到白色对象的新引用并发收集过程中删除了全部从灰色对象到该白色对象的直接或间接引用
什么是三色标记
白色表示对象未被垃圾收集器扫描过黑色表示该对象已被扫描且所有引用都扫描完毕结果是安全存活灰色表示该对象已被扫描但是至少存在一个引用还没被扫描过 三色标记案例
两种解决方案
增量更新 破坏的是第一个条件当黑色对象插入新的指向白色对象的引用关系时就将这个新插入的引用记录下来等并发扫描结束之后再将这些记录过的引用关系中的黑色对象为根重新扫描一次 原始快照 破坏的是第二个条件当灰色对象要删除指向白色对象的引用关系时就将这个要删除的引用记录下来在并发扫描结束之后再将这些记录过的引用关系中的灰色对象为根重新扫描一次
2、垃圾收集算法
从如何判定对象消亡的角度出发垃圾收集算法可以划分为“引用计数式垃圾收集”ReferenceCounting GC和“追踪式垃圾收集”Tracing GC两大类这两类也常被称作“直接垃圾收集”和“间接垃圾收集”。
主流垃圾收集器都是后者所以下面我们只针对后者展开分析。
1分代收集理论
弱分代假说绝大多数对象都是朝生夕灭的
强分代假说熬过越多次垃圾收集过程的对象就越难以消亡
这两个分代假说共同奠定了多款常用的垃圾收集器的一致的设计原则收集器应该将Java堆划分出不同的区域然后将回收对象依据其年龄年龄即对象熬过垃圾收集过程的次数分配到不同的区域之中存储如果一个区域中大多数对象都是朝生夕灭难以熬过垃圾收集过程的话那么把它们集中放在一起每次回收时只关注如何保留少量存活而不是去标记那些大量将要被回收的对象就能以较低代价回收到大量的空间如果剩下的都是难以消亡的对象那把它们集中放在一块虚拟机便可以使用较低的频率来回收这个区域这就同时兼顾了垃圾收集的时间开销和内存的空间有效利用
在Java堆划分出不同的区域之后垃圾收集器才可以每次只回收其中某一个或者某些部分的区域——因而才有了“Minor GC”“Major GC”“Full GC”这样的回收类型的划分
也才能够针对不同的区域安排与里面存储对象存亡特征相匹配的垃圾收集算法——因而发展出了“标记-复制算法”“标记-清除算法”“标记-整理算法”等针对性的垃圾收集算法
跨代引用假说跨代引用相对于同代引用来说仅占极少数
这其实是可根据前两条假说逻辑推理得出的隐含推论存在互相引用关系的两个对象是应该倾向于同时生存或者同时消亡的。举个例子如果某个新生代对象存在跨代引用由于老年代对象难以消亡该引用会使得新生代对象在收集时同样得以存活进而在年龄增长之后晋升到老年代中这时跨代引用也随即被消除了
依据这条假说我们就不应再为了少量的跨代引用去扫描整个老年代也不必浪费空间专门记录每一个对象是否存在及存在哪些跨代引用只需在新生代上建立一个全局的数据结构该结构被称为“记忆集”Remembered Set这个结构把老年代划分成若干小块标识出老年代的哪一块内存会存在跨代引用。
2标记-清除算法 两个阶段
标记阶段首先标记出所有需要回收的对象不需要回收清除阶段在标记完成后统一回收掉所有被标记的对象没有被标记 标记-清除算法是最基础的收集算法因为后续收集算法大多都是以它为基础对其缺点进行改进而得到的
缺点
第一是执行效率不稳定如果Java堆中包含大量对象而且其中大部分是需要被回收的这时必须进行大量标记和清除的动作导致标记和清除两个过程的执行效率都随对象数量增长而降低第二个是内存空间的碎片化问题标记、清除之后会产生大量不连续的内存碎片空间碎片太多可能会导致当以后在程序运行过程中需要分配较大对象时无法找到足够的连续内存而不得不提前触发另一次垃圾收集动作
3标记-复制算法半区复制 为了解决标记-清除算法面对大量可回收对象时执行效率低的问题1969年Fenichel提出了一种称为“半区复制”Semispace Copying的垃圾收集算法
原理
它将可用内存按容量划分为大小相等的两块每次只使用其中的一块。当这一块的内存用完了就将还存活着的对象复制到另外一块上面然后再把已使用过的内存空间一次清理掉
优点实现简单运行高效
对于多数对象都是可回收的情况算法需要复制的就是占少数的存活对象内存复制开销很小每次都是针对整个半区进行内存回收分配内存时也就不用考虑有空间碎片的复杂情况只要移动堆顶指针按顺序分配即可
缺点
如果内存中多数对象都是存活的这种算法将会产生大量的内存间复制的开销这种复制回收算法的代价是将可用内存缩小为了原来的一半空间浪费未免太多了一点
4标记-整理算法 标记-复制算法在对象存活率较高时就要进行较多的复制操作效率将会降低。
针对老年代对象的存亡特征1974年Edward Lueders提出了另外一种有针对性的“标记-整理”Mark-Compact算法
原理
其中的标记过程仍然与“标记-清除”算法一样后续步骤不是直接对可回收对象进行清理而是让所有存活的对象都向内存空间一端移动最后直接清理掉边界以外的内存
抉择
如果移动存活对象尤其是在老年代这种每次回收都有大量对象存活区域移动存活对象并更新所有引用这些对象的地方将会是一种极为负重的操作会Stop The World如果不移动对象会导致空间碎片化问题需要依赖更为复杂的内存分配器和内存访问器来解决。内存访问是非常频繁的如果增加额外负担会影响程序吞吐量
基于以上两点是否移动对象都存在弊端移动则内存回收时会更复杂不移动则内存分配时会更复杂
从垃圾收集的停顿时间来看不移动对象停顿时间会更短甚至可以不需要停顿关注延迟的CMS收集器就是基于标记-清除算法的
但是从整个程序的吞吐量来看移动对象会更划算因为内存分配和访问相比垃圾收集频率要高得多这部分的耗时增加总吞吐量仍然是下降关注吞吐量的Parallel Scavenge收集器是基于标记-整理算法的
3、经典垃圾收集器
1Serial收集器新生代收集器、标记复制算法
Serial收集器是最基础、历史最悠久的收集器曾经在JDK 1.3.1之前是HotSpot虚拟机新生代收集器的唯一选择
这个收集器是一个单线程工作的收集器但它的“单线程”的意义并不仅仅是说明它只会使用一个处理器或一条收集线程去完成垃圾收集工作更重要的是强调在它进行垃圾收集时必须暂停其他所有工作线程直到它收集结束
2ParNew收集器新生代收集器、标记复制算法
ParNew收集器实质上是Serial收集器的多线程并行版本除了同时使用多条线程进行垃圾收集之外其余的行为包括Serial收集器可用的所有控制参数、收集算法、Stop The World、对象分配规则、回收策略等都与Serial收集器完全一致
ParNew收集器除了支持多线程并行收集之外其他与Serial收集器相比并没有太多创新之处但它却是不少运行在服务端模式下的HotSpot虚拟机尤其是JDK 7之前的遗留系统中首选的新生代收集器
其中有一个与功能、性能无关但其实很重要的原因是除了Serial收集器外目前只有它能与CMS收集器配合工作
3Parallel Scavenge收集器新生代收集器、标记复制算法
Parallel Scavenge收集器的特点是它的关注点与其他收集器不同CMS等收集器的关注点是尽可能地缩短垃圾收集时用户线程的停顿时间而Parallel Scavenge收集器的目标则是达到一个可控制的吞吐量
吞吐量运行用户代码时间/运行用户代码时间运行垃圾收集时间。如果虚拟机完成某个任务用户代码加上垃圾收集总共耗费了100分钟其中垃圾收集花掉1分钟那吞吐量就是99%。
抉择
停顿时间越短就越适合需要与用户交互或需要保证服务响应质量的程序良好的响应速度能提升用户体验而高吞吐量则可以最高效率地利用处理器资源尽快完成程序的运算任务主要适合在后台运算而不需要太多交互的分析任务
参数
控制最大垃圾收集停顿时间-XXMaxGCPauseMillis参数默认值为空。收集器将尽力保证内存回收花费的时间不超过用户设定值但垃圾收集停顿时间缩短是以牺牲吞吐量和新生代空间为代价换取的系统把新生代调得小一些收集300MB新生代肯定比收集500MB快但这也直接导致垃圾收集发生得更频繁原来10秒收集一次、每次停顿100毫秒现在变成5秒收集一次、每次停顿70毫秒。停顿时间的确在下降但吞吐量也降下来了设置吞吐量大小-XXGCTimeRatio参数默认值为99。表示允许的最大垃圾收集时间占总时间的1/(1N)N为大于0小于100的整数。譬如把此参数设置为19那允许的最大垃圾收集时间就占总时间的5%即1/(119)。默认值为99即允许最大1%即1/(199)的垃圾收集时间开启自适应的调节策略-XXUseAdaptiveSizePolicy默认为开启。当这个参数被激活之后就不需要人工指定新生代的大小-Xmn、Eden与Survivor区的比例-XXSurvivorRatio、晋升老年代对象大小-XXPretenureSizeThreshold等细节参数了虚拟机会根据当前系统的运行情况收集性能监控信息动态调整这些参数以提供最合适的停顿时间或者最大的吞吐量
真实案例 生产上有服务出现频繁fullGC的告警 分析 我们生产上的Java版本是1.8默认采用Parallel Scavenge收集器且自适应调节策略是默认开启的这就导致了为了保障吞吐量JVM会自动把垃圾收集时间控制在1%以下压缩了新生代空间空间越小收集越快最后频繁发生GC频繁GC告警就是这么来的
4CMS收集器老年代收集器、标记清除算法
CMSConcurrent Mark Sweep收集器是一种以获取最短回收停顿时间为目标的收集器。
目前很大一部分的Java应用集中在互联网网站或者基于浏览器的B/S系统的服务端上这类应用通常都会较为关注服务的响应速度希望系统停顿时间尽可能短以给用户带来良好的交互体验。CMS收集器就非常符合这类应用的需求。
从名字包含“Mark Sweep”上就可以看出CMS收集器是基于标记-清除算法实现的它的过程分为四个步骤
初始标记标记GC Roots能直接关联到的对象需要Stop The World并发标记从GC Roots的直接关联对象开始遍历整个对象图的过程耗时长但是不需要停顿用户线程重新标记修正并发标记期间因用户程序继续运作而导致标记产生变动的那一部分对象的标记记录增量更新需要Stop The World并发清除清理删除掉标记阶段判断的已经死亡的对象由于不需要移动存活对象所以这个阶段也是可以与用户线程同时并发的 优点
并发收集效率高基于标记清除算法低停顿
缺点
CMS收集器对处理器资源非常敏感面向并发设计的程序都对处理器资源比较敏感。 在并发阶段它虽然不会导致用户线程停顿但是会因为占用了一部分线程而导致应用程序变慢降低应用总吞吐量。CMS默认启动的回收线程数是处理器核心数量3/4也就是说如果处理器核心数在四个或以上并发回收时垃圾收集线程只占用不超过25%的处理器运算资源但是当处理器核心数量不足四个时CMS对用户程序的影响就可能变得很大。如果应用本来的处理器负载就很高还要分出一半的运算能力去执行收集器线程就可能导致用户程序的执行速度忽然大幅降低 CMS收集器无法处理“浮动垃圾”Floating Garbage有可能出现“Con-current ModeFailure”失败进而导致另一次完全“Stop The World”的Full GC的产生 浮动垃圾在CMS的并发标记和并发清理阶段用户线程是还在继续运行的程序在运行自然就还会伴随有新的垃圾对象不断产生但这一部分垃圾对象是出现在标记过程结束以后CMS无法在当次收集中处理掉它们只好留待下一次垃圾收集时再清理掉由于在垃圾收集阶段用户线程还需要持续运行那就还需要预留足够内存空间提供给用户线程使用因此CMS收集器不能像其他收集器那样等待到老年代几乎完全被填满了再进行收集必须预留一部分空间供并发收集时的程序运作使用要是CMS运行期间预留的内存无法满足程序分配新对象的需要就会出现一次“并发失败”Concurrent Mode Failure这时候虚拟机将不得不启动后备预案冻结用户线程的执行临时启用Serial Old收集器来重新进行老年代的垃圾收集但这样停顿时间就很长了 CMS是一款基于“标记-清除”算法实现的收集器收集结束时会有大量空间碎片产生。空间碎片过多时将会给大对象分配带来很大麻烦往往会出现老年代还有很多剩余空间但就是无法找到足够大的连续空间来分配当前对象而不得不提前触发一次Full GC的情况
5G1收集器 Garbage First简称G1收集器是垃圾收集器技术发展历史上的里程碑式的成果它开创了收集器面向局部收集的设计思路和基于Region的内存布局形式。
目标
作为CMS收集器的替代者和继承人设计者们希望做出一款能够建立起**“停顿时间模型”**PausePrediction Model的收集器停顿时间模型的意思是能够支持指定在一个长度为M毫秒的时间片段内消耗在垃圾收集上的时间大概率不超过N毫秒这样的目标。翻译一下就是保证延迟可控且获得尽可能高的吞吐量。
原理
跟之前的收集器只能面向某个区域进行垃圾回收不一样G1可以面向堆内存任何部分来组成回收集Collection Set一般简称CSet进行回收衡量标准不再是它属于哪个分代而是哪块内存中存放的垃圾数量最多回收收益最大G1把连续的Java堆划分为多个大小相等的独立区域Region每一个Region都可以根据需要扮演新生代的Eden空间、Survivor空间或者老年代空间。对扮演不同角色的 Region采用不同的策略去处理这样无论是新创建的对象还是已经存活了一段时间、熬过多次收集的旧对象都能获取很好的收集效果。之所以能建立可预测的停顿时间模型是因为G1将Region作为单次回收的最小单元即每次收集到的内存空间都是Region大小的整数倍这样可以有计划地避免在整个Java堆中进行全区域的垃圾收集更具体的处理思路是让G1收集器去跟踪各个Region里面的垃圾堆积的“价值”大小价值即回收所获得的空间大小以及回收所需时间的经验值然后在后台维护一个优先级列表每次根据用户设定允许的收集停顿时间使用参数-XXMaxGCPauseMillis指定默认值是200毫秒优先处理回收价值收益最大的那些Region这也就是“Garbage First”名字的由来
细节问题
将Java堆分成多个独立Region后Region里面存在的跨Region引用对象如何解决 使用记忆集避免全堆作为GC Roots扫描每个Region都维护有自己的记忆集这些记忆集会记录下别的Region指向自己的指针并标记这些指针分别在哪些卡页的范围之内G1收集器要比其他的传统垃圾收集器有着更高的内存占用负担至少要耗费大约相当于Java堆容量10%至20%的额外内存 并发标记阶段如何保证收集线程与用户线程互不干扰地运行 通过原始快照SATB算法来实现的与CMS中的“Concurrent Mode Failure”失败会导致Full GC类似如果内存回收的速度赶不上内存分配的速度G1收集器也要被迫冻结用户线程执行导致Full GC而产生长时间“Stop The World”
步骤
初始标记仅仅只是标记一下GC Roots能直接关联到的对象并且修改TAMS指针的值让下一阶段用户线程并发运行时能正确地在可用的Region中分配新对象需要短暂Stop The World并发标记从GC Root开始对堆中对象进行可达性分析递归扫描整个堆里的对象图找出要回收的对象这阶段耗时较长但可与用户程序并发执行耗时长但是不需要停顿用户线程最终标记对用户线程做另一个短暂的暂停用于处理并发阶段结束后仍遗留下来的最后那少量的SATB记录需要短暂Stop The World筛选回收负责更新Region的统计数据对各个Region的回收价值和成本进行排序根据用户所期望的停顿时间来制定回收计划可以自由选择任意多个Region构成回收集然后把决定回收的那一部分Region的存活对象复制到空的Region中再清理掉整个旧Region的全部空间需要Stop The World
优点
创新性设计带来技术红利 可以指定最大停顿时间分Region的内存布局按收益动态确定回收集 与CMS的“标记-清除”算法不同G1从整体来看是基于“标记-整理”算法实现的收集器但从局部两个Region之间上看又是基于“标记-复制”算法实现。无论如何G1运作期间不会产生内存空间碎片垃圾收集完成之后能提供规整的可用内存。这种特性有利于程序长时间运行在程序为大对象分配内存时不容易因无法找到连续内存空间而提前触发下一次收集 缺点
G1无论是为了垃圾收集产生的内存占用Footprint还是程序运行时的额外执行负载Overload都要比CMS要高
经验参考
目前在小内存应用上CMS的表现大概率仍然要会优于G1而在大内存应用上G1则大多能发挥其优势这个优劣势的Java堆容量平衡点通常在6GB至8GB之间随着HotSpot的开发者对G1的不断优化也会让对比结果继续向G1倾斜
