目前内存分配和垃圾回收已经实现了“自动化”，为什么我们还要关注它们呢？当排查各种内存溢出、内存泄露问题时，当垃圾回收成为提高系统并发量的瓶颈时，有必要对内存的动态分配和垃圾回收进行监控和调节。GC需要考虑三个问题：哪些内存需要回收？什么时候回收？如何回收？
在Java虚拟机札记-Java内存区域划分一文中，我们已经学习了Java运行时内存区域的各个部分。其中，程序计数器、Java虚拟机栈和本地方法栈是“线程私有”的，这类内存区域会随着用户线程的启动和结束而建立和销毁，因此这些区域不需要过多考虑内存分配和回收的问题。 Java堆和方法区是“线程共享”的，随着虚拟机的启动而存在，这部分内存的分配和回收是动态的，我们只有在程序运行时才知道创建了哪些对象，需要多少内存，GC针对的就是这部分内存。
垃圾回收器对堆内存进行回收之前，需要判断堆中对象是“活着”还是“死去”。有两种方法可以实现这个功能：引用计数法和可达性分析算法。
定义：给对象添加一个引用计数器，每当有一个地方引用它，计数器就+1,；当引用失效时，计数器就-1；任何时刻计数器都为0的对象就是不能再被使用的。
优点：实现简单，效率很高
缺点：很难解决对象之间循环引用的问题。
由于它的缺点很严重，主流的程序语言都没有使用它判定该对象是否死亡。
定义：通过一系列的名为“GC Roots”的对象作为起始点，从这些节点开始向下搜索，搜索所走过的路径称为引用链（Reference Chain），当一个对象到 GC Roots 没有任何引用链相连时，则证明此对象是不可用的。
优点：准确高效
缺点：实现较麻烦
在java中可以作为GC Roots的对象有以下几种：
无论是引用计数法还是可达性分析算法，判断是否存活都与“引用”有关。在JDK1.2以前，一个对象只有“被引用”或者“没有被引用”两种状态。它无法描述这样一类对象：当内存空间充足时，可以保存在内存中；如果内存空间在垃圾回收后依然很紧张，则可以抛弃这些对象。所以在 JDK 1.2 之后，Java 对引用的概念进行了扩充，将引用分为以下四种引用。强度大小为强引用>软引用>弱引用>虚引用。
Object obj = new Object();上述的引用就是强引用。只要强引用还在，垃圾收集器永远不会回收掉被引用的对象。
用来描述一些还有用但并非必须的对象。软引用所关联的对象，在系统将要发生内存溢出异常之前，将会把这些对象列进回收范围并进行第二次回收。如果这次回收还是没有足够的内存，才会抛出内存异常。JDK 1.2 之后，提供了 SoftReference 类实现软引用。
描述非必须的对象，强度比软引用更弱一些，被弱引用关联的对象，只能生存到下一次垃圾收集发生前。当垃圾收集器工作时，无论当前内存是否足够，都会回收掉只被弱引用关联的对象。JDK 1.2 之后，提供了 WeakReference 类来实现弱引用。
也称幽灵引用或者幻影引用，是最弱的一种引用。一个对象是否有虚引用，完全不会对其生存时间够成影响，也无法通过虚引用来取得一个对象实例。为一个对象关联虚引用的唯一目的就是希望在这个对象被收集器回收时，收到一个系统通知。JDK 1.2 之后，提供了 PhantomReference 类来实现虚引用。
定义：分为标记和清除两个阶段。首先标记出所有需要回收的对象，在标记完成后统一回收被标记的对象。
地位：是最基础的垃圾回收算法，后面的几种垃圾回收算法都是基于这种思路并对其不足进行改进而得到的。
缺点：
- 效率问题。标记和清除过程的效率都不高。
- 空间问题。标记清除之后会产生大量不连续的内存碎片，空间碎片太多可能导致，程序分配较大对象时无法找到足够的连续内存，不得不提前出发另一次垃圾收集动作。 
定义：将可用内存按容量划分为大小相等的两块，每次只使用其中一块。当这一块的内存用完了，就将存活着的对象复制到另一块上面，然后再把已经使用过的内存空间一次清理掉。
优点：解决了标记-清除算法的效率问题。复制算法使得每次都是针对其中的可用内存的半区进行内存回收，内存分配时也不用考虑内存碎片等复杂情况，只要移动堆顶指针，按顺序分配内存即可，实现简单，运行高效。
缺点：
- 浪费空间。将内存缩小为原来的一半，代价太高昂。
- 效率问题。在对象存活率较高时，需要执行较多的复制操作，效率会变低。
现在的商用虚拟机都采用这种算法来回收新生代。因为新生代中的对象大部分很快就死亡，所以并不需要按照1:1的比例划分内存空间，而是将内存分为一块较大的 Eden 空间和两块较小的 Survivor 空间。每次使用 Eden 和其中的一块 Survivor。当回收时，将 Eden 和 Survivor 中还存活的对象一次性拷贝到另外一块 Survivor 空间上，最后清理掉 Eden 和刚才用过的 Survivor 空间。Hotspot 虚拟机默认 Eden 和 Survivor 的大小比例是8:1，也就是每次新生代中可用内存空间为整个新生代容量的90%（80% + 10%），只有10%的内存是会被“浪费”的。当然，无法保证每次回收都只有不多于10%的对象存活，如果10%的Survivor 空间不够用，可以临时使用老年代的内存。 
定义：标记过程仍然与“标记-清除”算法一样，但后续步骤不是直接对可回收对象进行清理，而是让所有存活的对象向一端移动，然后直接清理掉边界以外的内存。
优点：解决了复制算法的空间和效率问题。
应用：现在的商用虚拟机都采用这种算法来回收老年代。 
定义：根据对象的存活周期的不同将内存划分为几块。一般是把 Java 堆分为新生代和老年代，这样就可以根据各个年代的特点，采用最适当的收集算法。对于新生代，每次垃圾收集时会有大批对象死去，只有少量存活，所以选择复制算法，只需要少量存活对象的复制成本就可以完成收集。对于老年代，对象存活率高、没有额外空间对它进行分配担保，必须使用“标记-清理”或“标记-整理”算法进行回收。
优点：可以根据实际情况选择具体的算法
应用：现在的商用虚拟机的垃圾回收都采用这种算法。
下面来详细介绍下堆内存的垃圾回收。
为什么要将堆内存分区？
分区是为了对堆中对象进行模块化，以提高 JVM 的执行效率。
堆内存分为哪几块？
在Java8中，HotSpot中的永久代（Permanent Space）被元空间（Metaspace）取代。
主要用来存储新创建的对象，内存较小，MinorGC频繁。新生代又分为三个区域：Eden、ServivorFrom、ServivorTo。
Eden：当对象在堆创建时，一般进入Eden。如果新创建的对象占用内存很大，则直接分配到老年代。当Eden区内存不够时会触发MinorGC，对新生代区进行一次垃圾回收。
ServivorFrom：上一次GC的幸存者，作为这一次MinorGC的被扫描者。
ServivorTo：保留了这一次MinorGC后的幸存者。
MinorGC：采用复制算法。
1. 扫描Eden和ServivorFrom，将存活的对象复制到ServivorTo，并将这些对象的年龄+1。（如果ServivorTo已经满，则复制到老年代。）
2. 扫描ServivorFrom时，如果对象已经经过了几次的扫描仍然存活，达到了老年代的标准，JVM会将其移到老年代。
3. 扫描完毕后，清空Eden和ServivorFrom，然后交换ServivorFrom和ServivorTo，即ServicorTo成为下一次GC时的ServicorFrom区。
主要用来存储长时间被引用的对象。它里面存放的是经过几次在新生代进行扫描仍存活的对象。因为老年代对象比较稳定，所以MajorGC频率较小。
MajorGC：采用标记-整理算法。
主要用来存储类元数据信息，如类定义、字节码和常量等。GC不会在主程序运行期对永久代进行清理。所以这也导致了永久代会随着加载的Class的增多而胀满，最终抛出OOM异常。在Java8中，永久代已被元空间取代。再启动JVM时，如果JVM设置了PermSize 和 MaxPermSize 两个参数，参数会被忽略并给出警告。
元空间并不在虚拟机中，而是使用本地内存来存储类元数据信息。下面是两个与元空间相关的参数
- XX:MetaspaceSize，初始空间大小，达到该值就会触发垃圾收集进行类型卸载，同时GC会对该值进行调整：如果释放了大量的空间，就适当降低该值；如果释放了很少的空间，那么在不超过MaxMetaspaceSize时，适当提高该值。
- XX:MaxMetaspaceSize，最大空间，默认是没有限制的。
如果说收集算法是内存回收的方法论，那么垃圾收集器就是内存回收的具体实现。Java虚拟机规范中对垃圾收集器应该如何实现并没有任何规定，因此不同的厂商、不同版本的虚拟机所提供的垃圾收集器都可能会有很大差别，并且一般都会提供参数供用户根据自己的应用特点和要求组合出各个年代所使用的收集器。 
图中展示了7种作用于不同分代的收集器，如果两个收集器之间存在连线，就说明它们可以搭配使用。虚拟机所处的区域，则表示它是属于新生代收集器还是老年代收集器。接下来介绍这些收集器的特性、基本原理和使用场景，并重点分析CMS和G1这两种收集器。还有一点要强调，没有最好的收集器，只有对具体场景最合适的收集器。
Serial收集器是最基本、发展历史最悠久的收集器，曾经（在JDK 1.3.1之前）是虚拟机新生代收集的唯一选择。 
特性
应用场景
Serial收集器是虚拟机运行在Client模式下的默认新生代收集器。
优势
简单而高效（与其他收集器的单线程比），对于限定单个CPU的环境来说，Serial收集器由于没有线程交互的开销，专心做垃圾收集自然可以获得最高的单线程收集效率。
参数
-XX:+UseSerialGC。Jvm运行在Client模式下的默认值，打开此开关后，使用Serial + Serial Old的收集器组合进行内存回收。
ParNew垃圾收集器是Serial收集器的多线程版本。 
特性
ParNew收集器其实就是Serial收集器的多线程版本，除了使用多条线程进行垃圾收集之外，其余行为包括Serial收集器可用的所有控制参数、收集算法、Stop The World、对象分配规则、回收策略等都与Serial收集器完全一样，在实现上，这两种收集器也共用了相当多的代码。
应用场景
1.ParNew收集器是许多运行在Server模式下的虚拟机中首选的新生代收集器。
除了Serial收集器外，目前只有它能与CMS收集器配合工作。
在JDK 1.5时期，HotSpot推出了一款在强交互应用中几乎可认为有划时代意义的垃圾收集器——CMS收集器，这款收集器是HotSpot虚拟机中第一款真正意义上的并发收集器，它第一次实现了让垃圾收集线程与用户线程同时工作。
不幸的是，CMS作为老年代的收集器，却无法与JDK 1.4.0中已经存在的新生代收集器Parallel Scavenge配合工作，所以在JDK 1.5中使用CMS来收集老年代的时候，新生代只能选择ParNew或者Serial收集器中的一个。
优势
参数
Serial收集器与ParNew收集器
ParNew收集器在单CPU的环境中绝对不会有比Serial收集器更好的效果，甚至由于存在线程交互的开销，该收集器在通过超线程技术实现的两个CPU的环境中都不能百分之百地保证可以超越Serial收集器。然而，随着可以使用的CPU的数量的增加，它对于GC时系统资源的有效利用还是很有好处的。
Parallel Scavenge垃圾收集器因为与吞吐量关系密切，也称为吞吐量收集器（Throughput Collector）。 
特性
看上去和ParNew收集器一样，它有什么特别之处呢？
Parallel Scavenge收集器的特点是它的关注点与其他收集器不同，CMS等收集器的关注点是尽可能地缩短垃圾收集时用户线程的停顿时间，而Parallel Scavenge收集器的目标则是达到一个可控制的吞吐量（Throughput）。
吞吐量就是CPU用于运行用户代码的时间与CPU总消耗时间的比值，即吞吐量 = 运行用户代码时间 /（运行用户代码时间 + 垃圾收集时间）。
虚拟机总共运行了100分钟，其中垃圾收集花掉1分钟，那吞吐量就是99%。
应用场景
高吞吐量则可以高效率地利用CPU时间，尽快完成程序的运算任务，主要适合在后台运算而不需要太多交互的任务。
优势
参考特性和应用场景。
参数
Parallel Scavenge收集器提供两个参数用于精确控制吞吐量：
GC自适应的调节策略
Parallel Scavenge收集器有一个参数-XX:+UseAdaptiveSizePolicy。当这个参数打开之后，就不需要手工指定新生代的大小（-Xmn）、Eden与Survivor区的比例（-XX：SurvivorRatio）、晋升老年代对象年龄（-XX：PretenureSizeThreshold）等细节参数了，虚拟机会根据当前系统的运行情况收集性能监控信息，动态调整这些参数以提供最合适的停顿时间或者最大的吞吐量，这种调节方式称为GC自适应的调节策略（GC Ergonomics）。
如果对垃圾收集器不太了解，手动优化困难，这是一种值得推荐的方式。
那些具体细节参数的调节就由JVM自适应完成。
Parallel Scavenge收集器与CMS等收集器：
CMS等收集器的关注点是尽可能地缩短垃圾收集时用户线程的停顿时间，而Parallel Scavenge收集器的目标则是达到一个可控制的吞吐量（Throughput）。
Parallel Scavenge收集器与ParNew收集器
Parallel Scavenge收集器与ParNew收集器的一个重要区别是它具有自适应调节策略。
Serial Old是 Serial收集器的老年代版本。
特性
应用场景
优势
嗯。。。待补充
参数
-XX:+UseSerialGC。Jvm运行在Client模式下的默认值，打开此开关后，使用Serial + Serial Old的收集器组合进行内存回收。
Parallel Old垃圾收集器是Parallel Scavenge收集器的老年代版本，JDK1.6中才开始提供。
特性
应用场景
注重吞吐量以及CPU资源敏感的场景，可以使用Parallel Scavenge加Parallel Old收集器的组合。
优势
参考应用场景。
参数
-XX:+UseParallelOldGC。使用Parallel Scavenge + Parallel Old的收集器组合进行回收
JDK1.6之前Parallel Scavenge的尴尬
JDK1.6之前，新生代的Parallel Scavenge收集器一直处于比较尴尬的状态。原因是，如果新生代选择了Parallel Scavenge收集器，老年代除了Serial Old收集器外别无选择（Parallel Scavenge收集器无法与CMS收集器配合工作）。由于老年代Serial Old收集器在服务端应用性能上的“拖累”，使用了Parallel Scavenge收集器也未必能在整体应用上获得吞吐量最大化的效果，由于单线程的老年代收集中无法充分利用服务器多CPU的处理能力，在老年代很大而且硬件比较高级的环境中，这种组合的吞吐量甚至还不一定有ParNew加CMS的组合“给力”。直到Parallel Old收集器出现后，“吞吐量优先”收集器终于有了比较名副其实的应用组合。
CMS（Concurrent Mark Sweep）收集器是一种以获取最短回收停顿时间为目标的收集器。目前很大一部分的Java应用集中在互联网站或者B/S系统的服务端上，这类应用尤其重视服务的响应速度，希望系统停顿时间最短，以给用户带来较好的体验。CMS收集器就非常符合这类应用的需求。
并发标记清理（Concurrent Mark Sweep，CMS）收集器也称为并发低停顿收集器（Concurrent Low Pause Collector）或低延迟（low-latency）垃圾收集器。
运作过程
并发清除（CMS concurrent sweep）
整个过程中耗时最长的并发标记和并发清除都可以与用户线程一起工作，所以总体上说，CMS收集器的内存回收过程与用户线程一起并发执行。
特性
应用场景
尤其重视服务的响应速度，希望系统停顿时间最短，以给用户带来较好的体验的服务端应用
优势
劣势
CMS收集器对CPU资源非常敏感
其实，面向并发设计的程序都对CPU资源比较敏感。在并发阶段，它虽然不会导致用户线程停顿，但是会因为占用了一部分线程（或者说CPU资源）而导致应用程序变慢，总吞吐量会降低。
CMS默认启动的回收线程数是（CPU数量+3）/ 4，也就是当CPU在4个以上时，并发回收时垃圾收集线程不少于25%的CPU资源，并且随着CPU数量的增加而下降。但是当CPU不足4个（譬如2个）时，CMS对用户程序的影响就可能变得很大。
针对这种情况，曾出现了”增量式并发收集器“（Incremental Concurrent Mark Sweep/i-CMS）。类似使用抢占式来模拟多任务机制的思想，让收集线程和用户线程交替运行，减少收集线程运行时间。但效果并不理想，JDK1.6后就官方不再提倡用户使用。
CMS收集器无法处理浮动垃圾
CMS收集器无法处理浮动垃圾，可能出现“Concurrent Mode Failure”失败而导致另一次Full GC的产生。
浮动垃圾：由于CMS并发清理阶段用户线程还在运行着，伴随程序运行自然就还会有新的垃圾不断产生，这一部分垃圾出现在标记过程之后，CMS无法在当次收集中处理掉它们，只好留待下一次GC时再清理掉。这一部分垃圾就称为“浮动垃圾”。
CMS需要更多的内存：也是由于在垃圾收集阶段用户线程还需要运行，那也就还需要预留有足够的内存空间给用户线程使用，因此CMS收集器不能像其他收集器那样等到老年代几乎完全被填满了再进行收集，需要预留一部分空间提供并发收集时的程序运作使用。要是CMS运行期间预留的内存无法满足程序需要，就会出现一次“Concurrent Mode Failure”失败。
Concurrent Mode Failure解决方案：出现“Concurrent Mode Failure”后，虚拟机将启动后备预案：临时启用Serial Old收集器来重新进行老年代的垃圾收集，这样停顿时间就很长了。
CMS收集器会产生大量空间碎片
问题原因：CMS是一款基于“标记—清除”算法实现的收集器，这意味着收集结束时会有大量空间碎片产生。空间碎片过多时，将会给大对象分配带来很大麻烦，往往会出现老年代还有很大空间剩余，但是无法找到足够大的连续空间来分配当前对象，不得不提前触发一次Full GC。
解决方法：
1.”-XX:+UseCMSCompactAtFullCollection”，默认开启，使得CMS出现上面这种情况时不进行Full GC，而开启内存碎片的合并整理过程。但合并整理过程无法并发，停顿时间会变长。
2.”-XX:+CMSFullGCsBeforeCompaction”设置执行多少次不压缩的Full GC后，来一次压缩整理， 为减少合并整理过程的停顿时间。默认为0，也就是说每次执行Full GC都会进行压缩整理。
参数
G1（Garbage-First）是一款面向服务端应用的垃圾收集器。HotSpot开发团队赋予它的使命是未来可以替换掉JDK 1.5中发布的CMS收集器。
与其他GC收集器相比，G1具备如下特点。
特性
Java堆内存布局的改变
在G1之前的其他收集器进行收集的范围都是整个新生代或者老年代，而G1不再是这样。使用G1收集器时，Java堆的内存布局就与其他收集器有很大差别，它将整个Java堆划分为多个大小相等的独立区域（Region），虽然还保留有新生代和老年代的概念，但新生代和老年代不再是物理隔离的了，它们都是一部分Region（不需要连续）的集合。
G1可预测的停顿的实现原理
G1收集器之所以能建立可预测的停顿时间模型，是因为它可以有计划地避免在整个Java堆中进行全区域的垃圾收集。G1跟踪各个Region里面的垃圾堆积的价值大小（回收所获得的空间大小以及回收所需时间的经验值），在后台维护一个优先列表，每次根据允许的收集时间，优先回收价值最大的Region（这也就是Garbage-First名称的来由）。这种使用Region划分内存空间以及有优先级的区域回收方式，保证了G1收集器在有限的时间内可以获取尽可能高的收集效率。
运作过程
不计算维护Remembered Set的操作，可以分为4个步骤（与CMS较为相似）。
G1收集器运行示意图如下：
应用场景
和CMS相同。尤其重视服务的响应速度，希望系统停顿时间最短，以给用户带来较好的体验的服务端应用
CMS和G1该如何选择呢？
如果现在采用的收集器没有出现问题，不用急着去选择G1。如果应用程序追求低停顿，可以尝试选择G1。
优势
参数
| 垃圾收集器 | 类型 | 算法 | 优点 | 缺点 | 使用场景 | 参数 |
|---|---|---|---|---|---|---|
| Serial | 新生代 | 复制算法 | 没有线程交互（切换）开销 | Stop The World | HotSpot在Client模式下默认的新生代收集器 | -XX:+UseSerialGC |
| ParNew | 新生代、并行 | 同上 | 多线程+使用场景 | 有线程交互（切换）开销 | 除Serial外，目前只有它能与CMS收集器配合工作 | -XX:+UseConcMarkSweepGC、-XX:+UseParNewGC |
| Parallel Scavenge | 新生代、并行 | 同上 | 参考使用场景 | ？ | 主要适合在后台运算而不需要太多交互的任务。 |
|
| Serial Old | 老年代 | 标记-整理算法 | ？ | ？ | **主要用于Client模式。 **Server模式有两大用途：在JDK1.5及之前的版本中与Parallel Scavenge收集器搭配使用；作为CMS收集器的后备预案，在并发收集发生Concurrent Mode Failure时使用。 | -XX:+UseSerialGC |
| Parallel Old | 老年代、并行 | 标记-整理算法 | ？ | ？ | 注重吞吐量以及CPU资源敏感的场景，可以使用Parallel Scavenge加Parallel Old收集器的组合。 | -XX:+UseParallelOldGC |
| CMS | 老年代、并发 | 标记-清除算法 | 并发收集、低停顿 | 1.对CPU资源非常敏感；2.无法处理浮动垃圾；3.会产生大量空间碎片 | 尤其重视服务的响应速度，希望系统停顿时间最短，以给用户带来较好的体验的服务端应用 | -XX:+UseConcMarkSweepGC |
| G1 | 整堆收集器、并发 | 从整体看，是基于标记-整理算法；从局部（两个Region间）看，是基于复制算法； | 并发收集；低停顿；分代收集;空间整合; 除了追求低停顿外，还能建立可预测的停顿时间模型 | ? | 和CMS相同。 | -XX:+UseG1GC |
| 参数 | 描述 |
|---|---|
| -XX:+UseSerialGC | Jvm运行在Client模式下的默认值，打开此开关后，使用Serial + Serial Old的收集器组合进行内存回收 |
| -XX:+UseParNewGC | 打开此开关后，使用ParNew + Serial Old的收集器进行垃圾回收 |
| -XX:+UseConcMarkSweepGC | 使用ParNew + CMS + Serial Old的收集器组合进行内存回收，Serial Old作为CMS出现“Concurrent Mode Failure”失败后的后备收集器使用。 |
| -XX:+UseParallelGC | Jvm运行在Server模式下的默认值，打开此开关后，使用Parallel Scavenge + Serial Old的收集器组合进行回收 |
| -XX:+UseParallelOldGC | 使用Parallel Scavenge + Parallel Old的收集器组合进行回收 |
| -XX:SurvivorRatio | 新生代中Eden区域与Survivor区域的容量比值，默认为8，代表Eden:Subrvivor = 8:1 |
| -XX:PretenureSizeThreshold | 直接晋升到老年代对象的大小，设置这个参数后，大于这个参数的对象将直接在老年代分配 |
| -XX:MaxTenuringThreshold | 晋升到老年代的对象年龄，每次Minor GC之后，年龄就加1，当超过这个参数的值时进入老年代 |
| -XX:UseAdaptiveSizePolicy | 动态调整java堆中各个区域的大小以及进入老年代的年龄 |
| -XX:+HandlePromotionFailure | 是否允许新生代收集担保，进行一次minor gc后, 另一块Survivor空间不足时，将直接会在老年代中保留 |
| -XX:ParallelGCThreads | 设置并行GC进行内存回收的线程数 |
| -XX:GCTimeRatio | GC时间占总时间的比列，默认值为99，即允许1%的GC时间，仅在使用Parallel Scavenge 收集器时有效 |
| -XX:MaxGCPauseMillis | 设置GC的最大停顿时间，在Parallel Scavenge 收集器下有效 |
| -XX:CMSInitiatingOccupancyFraction | 设置CMS收集器在老年代空间被使用多少后出发垃圾收集，默认值为68%，仅在CMS收集器时有效，-XX:CMSInitiatingOccupancyFraction=70 |
| -XX:+UseCMSCompactAtFullCollection | 由于CMS收集器会产生碎片，此参数设置在垃圾收集器后是否需要一次内存碎片整理过程，仅在CMS收集器时有效 |
| -XX:+CMSFullGCBeforeCompaction | 设置CMS收集器在进行若干次垃圾收集后再进行一次内存碎片整理过程，通常与UseCMSCompactAtFullCollection参数一起使用 |
| -XX:+UseG1GC | 指定使用G1收集器 |
| -XX:InitiatingHeapOccupancyPercent | 当整个Java堆的占用率达到参数值时，开始并发标记阶段；默认为45 |
| -XX:MaxGCPauseMillis | 为G1设置暂停时间目标，默认值为200毫秒 |
| -XX:G1HeapRegionSize | 设置每个Region大小，范围1MB到32MB；目标是在最小Java堆时可以拥有约2048个 |
前面已经介绍了垃圾回收，了解了内存回收策略，接下来介绍下内存分配的策略。
内存分配有哪些原则？
本文已收录于Java并发编程札记专栏。
本文内容摘录或总结自《深入理解Java虚拟机 JVM高级特性与最佳实践》。
京公网安备 11010802041100号 | 京ICP备19059560号-4 | PHP1.CN 第一PHP社区 版权所有