网站建设中的多语言翻译如何实现,微信支付公司网站,昆山建设投标网站,上海待遇好的公司排名如果有兴趣了解更多相关内容的话#xff0c;可以看看我的个人网站#xff1a;耶瞳空间
GC#xff1a;垃圾收集(Gabage Collection)#xff0c;内存处理是编程人员容易出现问题的地方#xff0c;忘记或者错误的内存。不当的回收可能会导致程序或系统的不稳定甚至崩溃…如果有兴趣了解更多相关内容的话可以看看我的个人网站耶瞳空间
GC垃圾收集(Gabage Collection)内存处理是编程人员容易出现问题的地方忘记或者错误的内存。不当的回收可能会导致程序或系统的不稳定甚至崩溃Java提供的GC功能可以自动监测对象是否超过作用域从而达到自动回收内存的目的Java语言没有提供释放已分配内存的显示操作方法。
对于GC来说当程序员创建对象时GC就开始监控这个对象的地址、大小以及使用情况。通常GC采用有向图的方式记录和管理堆(heap)中的所有对象。通过这种方式确定哪些对象是可达的哪些对象是不可达的。当GC确定一些对象为不可达时GC就有责任回收这些内存空间。这个部分会在下面可达性分析算法中详细介绍。
程序员是不需要显示的去释放一个对象的内存的而是由虚拟机自行执行。在JVM中有一个垃圾回收线程它是低优先级的在正常情况下是不会执行的只有在虚拟机空闲或者当前堆内存不足时才会触发执行扫描那些没有被任何引用的对象并将它们添加到要回收的集合中进行回收。另外程序员可以手动执行System.gc()通知GC运行但是Java语言规范并不保证GC一定会执行。
一判断对象可以被回收
垃圾收集器在做垃圾回收的时候首先需要判定的就是哪些内存是需要被回收的哪些对象是存活的是不可以被回收的哪些对象已经死亡了需要被回收。
1.1引用计数法
引用计数法是历史最悠久的一种算法最早George E.Collins 在1960的时候首次提出50年后的今天该算法依然被很多编程语言使用比如python。但需要注意的是Java并不是使用的这个算法Java使用的是可达性分析算法避免误解所以先说一下。
引用计数法假设有一个对象A任何一个对象对A的引用那么对象A的引用计数器1当引用失效时对象A的引用计数器就-1如果对象A的计数器的值为0那说明对象A没有引用了可以被回收。
优点
实时性较高无需等到内存不够的时候才开始回收运行是根据对象的计数器是否为0就可以直接回收。在垃圾回收过程中应用无需挂起如果申请内存时内存不足立刻报OutOfMemory错误区域性更新对象的计数器时只是影响到该对象不对扫描全部对象。
缺点
每次对象被引用时都需要去更新计数器有一点时间开销。浪费CPU资源即使内存够用仍然在运行时进行计数器的统计。无法解决循环引用的问题(最大的缺点)。比如说A引用了BB引用了A这时候会进入死循环从而导致A和B无法被回收。
1.2可达性分析算法
可达性分析算法也可以称为根搜索算法、追踪性垃圾收集。算法的核心思想是通过一系列称为“GC Roots”的对象作为起始点从这些节点开始向下搜索搜索走过的路径称为“引用链”当一个对象到GC Roots没有任何的引用链相连时(从GC Roots到这个对象不可达)时证明此对象不可用。
相对于引用计数算法而言可达性分析算法不仅同样具备实现简单和执行高效等特点更重要的是该算法可以有效地解决在引用计数算法中循环引用的问题防止内存泄漏的发生。而Java也正是使用了这种算法。 上图中Object1~Object4都可以被GC Root访问到而Object5~Object7都不可以被访问到这也就是说。也就是说Object5、6、7这三个对象就是不可达的下次垃圾回收的时候可能就会被回收掉注意是可能被判定为不可达的对象不一定就会成为可回收对象。被判定为不可达的对象要成为可回收对象必须至少经历两次标记过程如果在这两次标记过程中仍然没有逃脱成为可回收对象的可能性才会成为可回收对象。
两次标记过程
第一次标记如果对象在进行可达性分析后发现没有 GCRoots 相连接的引用链那么它将会被第一次标记并且进行一次筛选筛选的条件是此对象是否有必要执行finalize()方法。当对象没有重写finalize()方法或者finalize()方法已经被虚拟机调用过虚拟机将这两种情况都视为没有必要执行。如果对象被判定为有必要执行则会被放到一个F-Queue队列。第二次标记finalize()方法是对象跳脱死亡命运的最后一次机会稍后GC将对F-Queue中对象进行第二次小规模标记如果对象要在finalize()中重新拯救自己只要重新与引用链上的任何一个对象建立关联即可譬如把自己(this关键字)赋值给某个类变量或者对象的成员变量那在第二次标记时她将被移出即将回收的集合。
需要注意的是并不是所有的对象都可以作为GC Roots的对象只有下列的对象可以作为GC Roots的对象
虚拟机栈(栈帧中的本地变量表)中引用的对象线程在执行方法时会将方法打包成一个栈帧入栈执行方法里用到的局部变量会存放到栈帧的本地变量表中。只要方法还在运行还没出栈就意味这本地变量表的对象还会被访问GC就不应该回收所以这一类对象也可作为GC Roots。方法区中类静态属性引用的对象全局对象的一种Class对象本身很难被回收回收的条件非常苛刻只要Class对象不被回收静态成员就不能被回收。方法区中常量引用的对象属于全局对象例如字符串常量池常量本身初始化后不会再改变因此作为GC Roots也是合理的。本地方法栈中JNI(即一般说的Native方法)引用的对象与第一条相同无非是一个是Java方法栈中的变量引用一个是native方法(C、C)方法栈中的变量引用。被同步锁持有的对象假设当前有线程持有对象锁GC如果回收了对象锁就会失效
注意如果要使用可达性分析算法来判断内存是否可回收那么分析工作必须在一个能保障一致性的快照中进行。这点不满足的话分析结果的准确性就无法保证。这点也是导致 GC进行时必须“stop The World”的一个重要原因。即使是号称几乎不会发生停顿的 CMS 收集器中枚举根节点时也是必须要停顿的。
1.3五种引用
在JDK1.2以前Java中引用的定义很传统如果引用类型的数据中存储的数值代表的是另一块内存的起始地址就称这块内存代表着一个引用。这种定义有些狭隘一个对象在这种定义下只有被引用或者没有被引用两种状态。 我们希望能描述这一类对象: 当内存空间还足够时则能保存在内存中如果内存空间在进行垃圾回收后还是非常紧张则可以抛弃这些对象。很多系统中的缓存对象都符合这样的场景。
在JDK1.2之后Java对引用的概念做了扩充将引用分为强引用(Strong Reference)、软引用(Soft Reference)、弱引用(Weak Reference)和虚引用(Phantom Reference)四种这四种引用的强度依次递减。
强引用(StrongReference)强引用是使用最普遍的引用。如果一个对象具有强引用那垃圾回收器绝不会回收它。当内存空间不足Java虚拟机宁愿抛出OutOfMemoryError错误使程序异常终止也不会靠随意回收具有强引用的对象来解决内存不足的问题。 ps强引用其实也就是我们平时A a new A()这个意思。软引用(SoftReference)如果一个对象只具有软引用则内存空间足够垃圾回收器就不会回收它如果内存空间不足了就会回收这些对象的内存。只要垃圾回收器没有回收它该对象就可以被程序使用。软引用可用来实现内存敏感的高速缓存。软引用可以和一个引用队列ReferenceQueue联合使用如果软引用所引用的对象被垃圾回收器回收Java虚拟机就会把这个软引用加入到与之关联的引用队列中。弱引用(WeakReference)弱引用与软引用的区别在于只具有弱引用的对象拥有更短暂的生命周期。在垃圾回收器线程扫描它所管辖的内存区域的过程中一旦发现了只具有弱引用的对象不管当前内存空间足够与否都会回收它的内存。不过由于垃圾回收器是一个优先级很低的线程因此不一定会很快发现那些只具有弱引用的对象。弱引用可以和一个引用队列ReferenceQueue联合使用如果弱引用所引用的对象被垃圾回收Java虚拟机就会把这个弱引用加入到与之关联的引用队列中。虚引用(PhantomReference)“虚引用”顾名思义就是形同虚设与其他几种引用都不同虚引用并不会决定对象的生命周期。如果一个对象仅持有虚引用那么它就和没有任何引用一样在任何时候都可能被垃圾回收器回收。虚引用主要用来跟踪对象被垃圾回收器回收的活动。虚引用与软引用和弱引用的一个区别在于虚引用必须和引用队列 ReferenceQueue联合使用。当垃圾回收器准备回收一个对象时如果发现它还有虚引用就会在回收对象的内存之前把这个虚引用加入到与之关联的引用队列中。
二垃圾回收算法
当成功区分出内存中存活对象和死亡对象后GC 接下来的任务就是执行垃圾回收释放掉无用对象所占用的内存空间以便有足够的可用内存空间为新对象分配内存。
目前在JVM中比较常见的三种垃圾收集算法
标记-清除算法(Mark-Sweep)复制算法(Copying)标记-整理算法(Mark-Compact)
2.1标记清除算法
算法思路执行分为两个阶段标记和清除。标记阶段标记所有需要回收的对象清除阶段回收被标记的对象所占用的空间。
缺点
效率不高内存碎片严重化后续可能发生对象不能找到利用空间的问题。 2.2复制算法
算法思路按照容量划分两个大小相等的内存区域当一块用完的时候将活着的对象复制到另一块上然后再把已使用的内存空间一次清理掉。
优点算法执行效率高适用于存活对象占少数的情况。 缺点内存使用率不高只有原来的一半。 2.3标记整理算法
算法思路标记无用对象让所有存活的对象都向一端移动然后直接清除掉端边界以外的内存。
优点有效地避免了内存碎片的产生 三分代垃圾回收
当前大多数垃圾收集都采用的分代收集算法这种算法会根据对象存活周期的不同将内存划分为几块每一块使用不同的上述算法去收集。在jdk8以前分为三代年轻代、老年代、永久代。在jdk8以后取消了永久代的说法而是元空间取而代之。一般年轻代使用复制算法(对象存活率低)老年代使用标记整理算法(对象存活率高)。
年轻代(复制算法为主)尽可能快的收集掉声明周期短的对象。整个年轻代占1/3的堆空间年轻代分为三个区Eden、Survivor-from、Survivor-to其内存大小默认比例为8:1:1(可调整)大部分新创建的对象都是在Eden区创建。当回收时先将Eden区存活对象复制到一个Survivor-from区然后清空Eden区存活的对象年龄1当这个Survivor-from区也存放满了时则将Eden区和Survivor-from区存活对象复制到另一个Survivor-to区然后清空Eden和这个Survivor-from区存活的对象年龄1此时Survivor-from区是空的然后将Survivor-from区和Survivor-to区交换即保持Survivor-from区为空此时的Survivor-from是原来的Survivor-to区 如此往复。年轻代执行的GC是Minor GC。年轻代的迭代更新很快大多数对象的存活时间都比较短所以对GC的效率和性能要求较高因此使用复制算法同时这样划分为三个区域保证了每次GC仅浪费10%的内存内存利用率也有所提高。老年代(标记-整理算法为主)在年轻代经过很多次垃圾回收之后仍然存活的对象(默认15岁)就会被放入老年代中因为老年代中的对象大多数是存活的所以使用算法是标记-整理算法。老年代执行的GC是Full GC。
上面多次提到Minor GC和Full GC那么它们有什么区别呢
Minor GC即新生代GC发生在新生代的垃圾收集动作因为Java有朝生夕灭的特性所以Minor GC相对频繁一般回收速度也比较快。Major GC / Full GC发生在老年代经常会伴随至少一次Minor GC。Major GC的速度一般会比Minor GC慢。 Minor GC发生条件当新对象生成并且在Eden申请空间失败时Full GC发生条件 老年代空间不足永久代空间不足(jdk8以前)System.gc()被显示调用Minor GC晋升到老年代的平均大小大于老年代的剩余空间使用RMI来进行RPC或管理的JDK应用每小时执行1次Full GC
四垃圾回收器
垃圾回收器的主要作用是用来回收内存中已被判定无用的垃圾对象。但是垃圾回收器在扫描过程中寻找并标记的其实是还在存活的对象。当查找完全部存活对象后将未标记的对象进行统一的回收。
jvm的垃圾回收器大体上的分类主要包括四种串行、并行、并发(CMS)和G1。
串行垃圾回收器(Serial)它为单线程环境设计并且只使用一个线程进行垃圾回收会暂停所有的用户线程。所以不适合服务器环境。并行垃圾回收器(Parallel)多个垃圾回收线程并行工作此时用户线程是暂停的适用于科学计算/大数据处理等弱交互场景。并发垃圾回收器(CMS)用户线程和垃圾收集线程同时执行(不一定是并行可能交替执行)不需要停顿用户线程。互联网公司多用它适用于对响应时间有要求的场景。G1垃圾回收器G1垃圾回收器将堆内存分割成不同的区域然后并发的对其进行垃圾回收。
目前主流的垃圾回收器有如下8个其中有连线的代表是可以相互配合使用的。G1和ZGC在中间代表新生代和老年代混合回收 每一款不同的垃圾收集器都有不同的特点在具体使用的时候需要根据具体的情况选用不同的垃圾收集器。
4.1Serial
Serial(串行收集器)只会使用一个CPU或者一条GC线程进行垃圾回收并且在垃圾回收过程中暂停其他工作线程。
特点
Client模式下新生代默认使用的垃圾收集器采用复制算法串行回收进行垃圾收集时必须暂停所有工作线程直到完成。即会Stop The World
应用场景适合单个CPU的环境来说因为Serial收集器没有线程交互(切换)开销可以获得最高的单线程收集效率。
对应JVM参数-XX:UseSerialGC
4.2ParNew
ParNew就是Serial的多线程版本ParNew由多条GC线程并行的进行垃圾清理工作清理过程中需要停掉所有的业务线程但由于是多线程运作其效率要高于serial。它是很多java虚拟机运行在Server模式下新生代的默认垃圾收集器。
特点
除了多线程外其余的行为、特点和Serial收集器基本一样采用复制算法除Serial外目前只有它能与CMS收集器配合工作可控JVM参数非常多适用于Server模式下即减少系统停顿提高系统响应速度
参数设置
-XX:UseParNewGC使用ParNew收集器-XX:ParallelGCThreads指定垃圾收集的线程数量ParNew默认开启的收集线程与CPU的数量相同
4.3Parallel Scavenge
Parallel Scavenge是并行多线程回收器常用于新生代追求CPU吞吐量的优化能在较短的时间内完成指定的任务因此适合不需要太多交互的后台运算。正因为其与吞吐量关系密切也称为吞吐量收集器
吞吐量是指用户线程运行时间占CPU总时间的比例其计算公式为
吞吐量运行用户代码时间/运行用户代码时间GC的时间)
吞吐量越高表示GC时间占比越低用户体验越好特点
采用复制算法JDK1.8的默认垃圾收集器与ParNew收集器相似采用复制算法多线程收集主要目标是达到一个可控制的吞吐量
应用场景适用于应用程序运行在具有多个CPU上对暂停时间没有特别高的要求时即程序主要在后台进行计算而不需要与用户进行太多交互。例如那些执行批量处理、订单处理、工资支付、科学计算的应用程序
参数设置
-XX:MaxGCPauseMillis 控制最大垃圾收集停顿时间大于0的毫秒数。如果设置得稍小停顿时间可能会缩短但也可能会使得吞吐量下降因为可能导致垃圾收集发生得更频繁-XX:GCTimeRatio 设置垃圾收集时间占总时间的比率0n100的整数,GCTimeRatio相当于设置吞吐量大小-XX:UseAdptiveSizePolicy 动态调整这些参数以提供最合适的停顿时间或最大的吞吐量
降低停顿时间的两种方式
在多CPU环境中使用多条GC线程从而垃圾回收的时间减小从而使用户线程STW的时间减小。实现GC线程与用户线程并发运行其所谓的并发指的其实是用户线程与GC线程交替运行从而达到每次的停顿时间减小用户的停顿感降低单线程之间的不断切换也意味着需要额外的开销从而垃圾回收和用户线程的总时间将会延长。
4.4Serial Old
Serial Old是Serial的老年代版本他们都是单线程收集器也就是垃圾收集时只启动一条GC线程因此都适合客户端的应用他们之间的主要区别其实就是Serial old常被用于老年代。
特点
使用标记-整理算法是Client模式下默认的老年代垃圾收集器
在Server模式下主要有两个用途
在JDK1.5之前版本中与新生代的Parallel Scavenge收集器搭配使用作为老年代中使用CMS收集器的后备垃圾收集方案
4.5Parallel Old
Parallel Old是Parallel Scavenge的老年代版木使用多线程的标记-整理算法。
在jdk1.6之前新生代使用Parallel Scavenge收集器只能搭配年老代的Serial Old收集器只能保证新生代的吞吐量优先无法保证整体的吞吐量。Parallel Old在jdk1.6之后才开始提供正是为了在年老代同样提供吞吐量优先的垃圾收集器。如果系统对吞吐量要求比较高jdk1.8后可以优先考虑新生代Parallel Scavenge和年老代Parallel Old收集器的搭配策略。
4.6CMS
CMS作用于老年代是一种以获取最短停顿时间为目标的收集器。给予标记-清除算法实现。整个过程分为四步
初始标记停止一切用户线程因使用一条初始标记线程对所有与GC Roots关联的对象进行标记并发标记使用多条并发标记线程并行执行并与用户线程并发执行。此过程进行可达性分析标记出所有废弃的对象速度很慢重新标记使用多条线程并行执行将刚才并发过程中新出现的废弃对象标出来并发清除使用一条并发清除线程和业务线程并发执行清除无用对象这个过程非常耗时
CMS的特点
吞吐量低由于CMS在垃圾收集过程使用用户线程和GC线程并发执行从而线程之间切换会有额外的开销因此CPU吞吐量就不如在业务线程全部通知的情况下高无法处理浮动垃圾由于垃圾清理过程中可能会产生浮动垃圾当浮动垃圾过多时可能会导致频繁的GC
优点
并发收集低停顿
缺点
浮动垃圾由于CMS并发清理阶段用户线程还在运行着伴随程序运行自然会有新垃圾产生这部分垃圾出现在标记过程之后所以CMS无法在当次收集中处理掉他们只好留待下一次GC清理掉这一部分垃圾称为浮动垃圾。在jdk1.5默认设置下CMS收集器当老年代使用了68%的空间就会被激活可以通过-XX:CMSInitialOccupancyFraction的值来提高触发百分比在jdk1.6中CMS启动阈值提升到了92%要是CMS运行期间预留的内存无法满足程序的需要就会出现”Concurrent Mode Failure“然后降级临时启用Serial Old收集器进行老年代的垃圾收集这样停顿时间就很长了。所以-XX:CMSInitialOccupancyFraction设置太高容易导致大量”Concurrent Mode Failure“。有空间碎片CMS是一款基于“标记-清除”算法实现的所以会产生空间碎片。为了解决这个问题CMS提供了-XX:UseCMSCompactAtFullCollectionJVM参数用于开启内存碎片的合并整理由于内存整理是无法并行的所以停顿时间会变长。还有-XX:CMSFullGCBeforeCompaction这个参数用于设置多少次不压缩Full GC后跟着来一次带压缩的(默认为0)。对CPU资源敏感。在并发标记和并发清除阶段虽然不会停止用户线程但是会因为占用一部分cpu资源进行垃圾回收导致用户程序变慢。CMS默认启动的回收线程数是(cpu数量3)/4。所以CPU数量少会导致用户程序执行速度降低较多。
应用场景适合应用在互联网站或者B/S系统的服务器上这类应用尤其重视服务器的响应速度希望系统停顿时间最短。非常适合堆内存大、CPU核数多的服务器端应用也是G1出现之前大型应用的首选垃圾回收器。
4.7G1
G1(Garbage-First)垃圾回收器是在Java7 update 4之后引入的一个新的垃圾回收器Java 9以后代替CMS成为默认垃圾收集器。G1是一个分代的增量的并行与并发的垃圾回收器。它是一款面向服务端的垃圾回收器主要针对配备多核CPU及大容量内存的机器。它的设计目标是为了适应现在不断扩大的内存和不断增加的处理器数量进一步降低停顿时间同时兼顾良好的吞吐量。
G1回收器的特点
具有并行性。在回收期间可以有多个GC线程同时工作有效利用多核计算能力。此时用户线程STW具有并发性。G1拥有与应用程序交替执行的能力部分工作可以和应用程序同时执行因此一般来说不会在整个回收阶段发生完全阻塞应用程序的情况整体上使用的是标记-整理算法(region之间是复制算法)因此其回收得到的空间是连续的。这避免了CMS回收器那样因为不连续空间所造成的问题比如分配大对象时会因为无法找到连续内存空间而提前触发下一次GC。尤其是当Java堆非常大的时候G1的优势更加明显这种特性非常有利于程序长时间运行。连续空间也意味着G1垃圾回收器可以不必采用空闲链表的内存分配方式而可以直接采用bump-the-pointer的方式将内存划分一个个固定大小的region每个region可以是年轻代、老年代的一个。内存的回收是以region作为基本单位的。但从堆的结构上看它不要求整个Eden区、年轻代或者老年代都是连续的也不再坚持固定大小和固定数量。具有可预测的停顿时间模型即软实时(soft real-time)性。所谓的实时垃圾回收是指在要求的时间内完成垃圾回收。“软实时”则是指用户可以指定垃圾回收时间的限时G1会努力在这个时限内完成垃圾回收但是G1并不担保每次都能在这个时限内完成垃圾回收。通过设定一个合理的目标可以让达到90%以上垃圾的回收时间都在这个时限内会有计划地避免在整个Java堆中进行全区域的垃圾收集。G1跟踪各个Region里面的垃圾堆积的价值大小(回收所获得的空间大小以及回收所需时间的经验值)在后台维护一个优先列表每次根据允许的收集时间优先回收价值最大的Region。由于这种方式的侧重点在于回收垃圾最大量的区间(Region)所以才起名Garbage First(垃圾优先) 。
G1的缺点相较于CMSG1还不具备全方位、压倒性优势。比如在用户程序运行过程中G1无论是为了垃圾收集产生的内存占用(Footprint)还是程序运行时的额外执行负载(overload)都要比CMS要高。从经验上来说在小内存应用上CMS的表现大概率会优于G1而G1在大内存应用上则发挥其优势。平衡点在6-8GB之间。
G1参数
-XX:MaxGCPauseMillis暂停时间默认值200ms。这是一个软性目标G1会尽量达成如果达不成会逐渐做自我调整。对于Young GC来说会逐渐减少Eden区个数减少Eden空间那么Young GC的处理时间就会相应减少对于Mixed GCG1会调整每次Choose Cset的比例默认最大值是10%当然每次选择的Cset少了所要经历的Mixed GC的次数会相应增加。同时减少Eden的总空间时就会更加频繁的触发Young GC也就是会加快Mixed GC的执行频率因为Mixed GC是由Young GC触发的或者说借机同时执行的。频繁GC会对对应用的吞吐量造成影响每次Mixed GC回收时间太短回收的垃圾量太少可能最后GC的垃圾清理速度赶不上应用产生的速度那么可能会造成串行的Full GC这是要极力避免的。所以暂停时间肯定不是设置的越小越好当然也不能设置的偏大转而指望G1自己会尽快的处理这样可能会导致一次全部并发标记后触发的Mixed GC次数变少但每次的时间变长STW时间变长对应用的影响更加明显。-XX:G1HeapRegionSizeRegion大小若未指定则默认最多生成2048块每块的大小需要为2的幂次方如1,2,4,8,16,32最大值为32M。Region的大小主要是关系到Humongous Object的判定当一个对象超过Region大小的一半时则为巨型对象那么其会至少独占一个Region如果一个放不下会占用连续的多个Region。当一个Humongous Region放入了一个巨型对象可能还有不少剩余空间但是不能用于存放其他对象这些空间就浪费了。所以如果应用里有很多大小差不多的巨型对象可以适当调整Region的大小尽量让他们以普通对象的形式分配合理利用Region空间。新生代比例新生代比例有两个数值指定下限-XX:G1NewSizePercent默认值5%上限-XX:G1MaxNewSizePercent默认值60%。G1会根据实际的GC情况(主要是暂停时间)来动态的调整新生代的大小主要是Eden Region的个数。最好是Eden的空间大一点毕竟Young GC的频率更大大的Eden空间能够降低Young GC的发生次数。但是Mixed GC是伴随着Young GC一起的如果暂停时间短那么需要更加频繁的Young GC同时也需要平衡好Mixed GC中新生代和老年代的Region因为新生代的所有Region都会被回收如果Eden很大那么留给老年代回收空间就不多了最后可能会导致Full GC。-XX:ConcGCThreads并发GC线程数默认是-XX:ParallelGCThreads/4也就是在非STW期间的GC工作线程数当然其他的线程很多工作在应用上。当并发周期时间过长时可以尝试调大GC工作线程数但是这也意味着此期间应用所占的线程数减少会对吞吐量有一定影响。-XX:ParallelGCThreads并行GC线程数也就是在STW阶段工作的GC线程数其值遵循以下原则 如果用户显示指定了ParallelGCThreads则使用用户指定的值。否则需要根据实际的CPU所能够支持的线程数来计算ParallelGCThreads的值计算方法如下 如果物理CPU所能够支持线程数小于8则ParallelGCThreads的值为CPU所支持的线程数。这里的阀值为8是因为JVM中调用nof_parallel_worker_threads接口所传入的switch_pt的值均为8。如果物理CPU所能够支持线程数大于8则ParallelGCThreads的值为8加上一个调整值调整值的计算方式为物理CPU所支持的线程数减去8所得值的5/8或者5/16JVM会根据实际的情况来选择具体是乘以5/8还是5/16。比如在64线程的x86 CPU上如果用户未指定ParallelGCThreads的值则默认的计算方式为ParallelGCThreads 8 (64 - 8) * (5/8) 8 35 43。 -XX:G1MixedGCLiveThresholdPercent被纳入Cset的Region的存活空间占比阈值不同版本默认值不同有65%和85%。在全局并发标记阶段如果一个Region的存活对象的空间占比低于此值则会被纳入Cset。此值直接影响到Mixed GC选择回收的区域当发现GC时间较长时可以尝试调低此阈值尽量优先选择回收垃圾占比高的Region但此举也可能导致垃圾回收的不够彻底最终触发Full GC。-XX:InitiatingHeapOccupancyPercent触发全局并发标记的老年代使用占比默认值45%也就是老年代占堆的比例超过45%。如果Mixed GC周期结束后老年代使用率还是超过45%那么会再次触发全局并发标记过程这样就会导致频繁的老年代GC影响应用吞吐量。同时老年代空间不大Mixed GC回收的空间肯定是偏少的。可以适当调高IHOP的值当然如果此值太高很容易导致年轻代晋升失败而出发Full GC所以需要多次调整测试。-XX:G1HeapWastePercent触发Mixed GC的堆垃圾占比默认值5%也就是在全局标记结束后能够统计出所有Cset内可被回收的垃圾占整对的比例值如果超过5%那么就会触发之后的多轮Mixed GC如果不超过那么会在之后的某次Young GC中重新执行全局并发标记。可以尝试适当的调高此阈值能够适当的降低Mixed GC的频率。-XX:G1OldCSetRegionThresholdPercent每轮Mixed GC回收的Region最大比例默认10%也就是每轮Mixed GC附加的Cset的Region不超过全部Region的10%最多10%如果暂停时间短那么可能会少于10%。一般这个值不需要额外调整。-XX:G1MixedGCCountTarget一个周期内触发Mixed GC最大次数默认值8。也就是在一次全局并发标记后最多接着8次Mixed GC也就是会把全局并发标记阶段生成的Cset里的Region拆分为最多8部分然后在每轮Mixed GC里收集一部分。这个值要和上一个参数配合使用8*10%80%应该来说会大于每次标记阶段的Cset集合了。一般此参数也不需额外调整。-XX:G1ReservePercentG1为分配担保预留的空间比例默认10%。也就是老年代会预留10%的空间来给新生代的对象晋升如果经常发生新生代晋升失败而导致Full GC那么可以适当调高此阈值。但是调高此值同时也意味着降低了老年代的实际可用空间。-XX:SoftRefLRUPolicyMSPerMB每兆堆空闲空间的软引用的存活时间默认值是1000也就是1秒。可以调低这个参数来触发更早的回收软引用。如果调高的话会有更多的存活数据可能在GC后堆占用空间比会增加。 对于软引用还是建议尽量少用会增加存活数据量导致频繁的老年代收集增加GC的处理时间。-XX:MaxTenuringThreshold晋升年龄阈值默认值15。一般新生对象经过15次Young GC会晋升到老年代巨型对象会直接分配在老年代同时在Young GC时如果相同age的对象占Survivors空间的比例超过-XX:TargetSurvivorRatio的值(默认50%)则会自动将此次晋升年龄阈值设置为此age的值所有年龄超过此值的对象都会被晋升到老年代此举可能会导致老年代需要不少空间应对此种晋升。一般这个值不需要额外调整。
