烟台网站建设多少钱,咋样建设网站,网站建设公司发展规划,网站建设费放什么科目文章目录 垃圾回收机制Stop-the-World垃圾收集器垃圾收集器分类Serial 收集器Serial Old 收集器ParNew 收集器Parallel Scavenge 收集器Parallel Old 收集器CMS 收集器CMS 收集器缺点 G1 收集器G1 收集器特点G1 收集器的分代理念G1 收集器运作过程 垃圾回收机制
垃圾回收… 文章目录 垃圾回收机制Stop-the-World垃圾收集器垃圾收集器分类Serial 收集器Serial Old 收集器ParNew 收集器Parallel Scavenge 收集器Parallel Old 收集器CMS 收集器CMS 收集器缺点 G1 收集器G1 收集器特点G1 收集器的分代理念G1 收集器运作过程 垃圾回收机制
垃圾回收Garbage CollectionGC顾名思义就是释放垃圾占用的空间当需要排查各种内存溢出问题、当垃圾收集成为系统达到更高并发的瓶颈时我们就需要对这些“自动化”的技术实施必要的监控和调节。有效的使用可以使用的内存对内存堆中已经死亡的或者长时间没有使用的对象进行清除和回收。
Stop-the-World
Stop The World是 Java 垃圾收集中的一个重要概念。在垃圾收集过程中JVM 会暂停所有的用户线程这种暂停被称为Stop The World事件。这么做的主要原因是为了防止在垃圾收集过程中用户线程修改了堆中的对象导致垃圾收集器无法准确地收集垃圾。
Stop The World事件会对 Java 应用的性能产生影响。如果停顿时间过长就会导致应用的响应时间变长对于对实时性要求较高的应用如交易系统、游戏服务器等这种情况是不能接受的。
因此在选择和调优垃圾收集器时需要考虑其停顿时间。Java 中的一些垃圾收集器如 G1 和 ZGC下文有详细讲解都会尽可能地减少了Stop The World的时间通过并发的垃圾收集提高应用的响应性能。
垃圾收集器
如果说收集算法是内存回收的方法论那么垃圾收集器就是内存回收的具体实现。Java 垃圾收集器Garbage Collector, GC是 Java 虚拟机JVM的一部分它自动管理内存回收不再使用的对象所占用的内存空间。这有助于防止内存泄漏并且使得开发人员可以更专注于业务逻辑的编写而不是内存管理。
没有万能的垃圾收集器只有根据具体应用场景选择适合自己的垃圾收集器。垃圾收集器是垃圾回收算法如引用计数法、标记清除法、标记整理法、复制算法等的具体实现。它的主要任务是识别并回收那些不再被程序使用的对象所占用的内存空间从而避免内存泄漏和内存溢出的问题。
垃圾收集器分类
就目前来说JVM 的垃圾收集器主要分为两大类分代收集器和分区收集器分代收集器的代表是 CMS分区收集器的代表是 G1 和 ZGC
JDK 默认垃圾收集器使用 java -XX:PrintCommandLineFlags -version 命令查看
JDK 8Parallel Scavenge新生代 Parallel Old老年代JDK 9 ~ JDK20: G1 Serial 收集器
Serial串行收集器是最基本、历史最悠久的垃圾收集器。此收集器是一个单线程收集器了。
它的 “单线程” 的意义不仅仅意味着它只会使用一条垃圾收集线程去完成垃圾收集工作更重要的是它在进行垃圾收集工作的时候必须暂停其他所有的工作线程 “STW Stop The World” 直到它收集结束。
新生代采用标记-复制算法老年代采用标记-整理算法。 Serial 收集器简单而高效与其他收集器的单线程相比。由于没有线程交互的开销自然可以获得很高的单线程收集效率对于运行在 Client 模式下的虚拟机来说是个不错的选择
Serial Old 收集器
Serial 收集器的老年代版本它同样是一个单线程收集器。它主要有两大用途一种用途是在 JDK1.5 以及以前的版本中与 Parallel Scavenge 收集器搭配使用另一种用途是作为 CMS 收集器的后备方案。 ParNew 收集器
ParNew 收集器是 Serial 收集器的多线程版本除了使用多线程进行垃圾收集外其余行为控制参数、收集算法、回收策略等等和 Serial 收集器完全一样。
新生代采用标记-复制算法老年代采用标记-整理算法。 并行和并发概念补充 并行Parallel指多条垃圾收集线程并行工作但此时用户线程仍然处于等待状态。 并发Concurrent指用户线程与垃圾收集线程同时执行但不一定是并行可能会交替执行用户程序在继续运行而垃圾收集器运行在另一个 CPU 上。
Parallel Scavenge 收集器
Parallel Scavenge 收集器也是多线程收集器 其关注点是吞吐量高效率的利用 CPU。 是 JDK1.8 的默认收集器可以使用 java -XX:PrintCommandLineFlags -version 命令查看 吞吐量Throughput就是 CPU 中用于运行用户代码的时间与 CPU 总消耗时间的比值。
Parallel Scavenge 收集器提供了很多参数供用户找到最合适的停顿时间或最大吞吐量如果对于收集器运作不太了解手工优化存在困难的时候使用 此收集器配合自适应调节策略把内存管理优化交给虚拟机去完成也是一个不错的选择。
新生代采用标记-复制算法老年代采用标记-整理算法。 Parallel Old 收集器
Parallel Scavenge 收集器的老年代版本。使用多线程和“标记-整理”算法。在注重吞吐量以及 CPU 资源的场合都可以优先考虑 Parallel Scavenge 收集器和 Parallel Old 收集器 CMS 收集器
CMSConcurrent Mark Sweep收集器 是一种以获取最短回收停顿时间为目标的收集器。它非常符合在注重用户体验的应用上使用。
CMSConcurrent Mark Sweep收集器是 HotSpot 虚拟机第一款真正意义上的并发收集器它第一次实现了让垃圾收集线程与用户线程基本上同时工作。
从名字中的 Mark Sweep 这两个词可以看出CMS 收集器是由 标记-清除 算法实现的。它的运作过程相比于前面几种垃圾收集器来说更加复杂一些。整个过程分为四个步骤 初始标记: 暂停所有的其他线程并记录下直接与 root 相连的对象速度很快 并发标记: 同时开启 GC 和用户线程用一个闭包结构去记录可达对象。但在这个阶段结束这个闭包结构并不能保证包含当前所有的可达对象。 因为用户线程可能会不断的更新引用域所以 GC 线程无法保证可达性分析的实时性。所以这个算法里会跟踪记录这些发生引用更新的地方。 重新标记: 重新标记阶段就是为了修正并发标记期间因为用户程序继续运行而导致标记产生变动的那一部分对象的标记记录这个阶段的停顿时间一般会比初始标记阶段的时间稍长远远比并发标记阶段时间短 并发清除: 开启用户线程同时 GC 线程开始对未标记的区域做清扫。 这是一款优秀的垃圾收集器并发收集、低停顿。但是它有下面三个明显的缺点
CMS 收集器缺点 对 CPU 资源非常敏感因此在 CPU 资源紧张的情况下CMS 的性能会大打折扣。默认情况下CMS 启用的垃圾回收线程数是CPU数量 3)/4当 CPU 数量很大时启用的垃圾回收线程数占比就越小。但如果 CPU 数量很小例如只有 2 个 CPU垃圾回收线程占用就达到了 50%这极大地降低系统的吞吐量无法接受。 CMS 采用的是「标记-清除」算法会产生大量的内存碎片导致空间不连续当出现大对象无法找到连续的内存空间时就会触发一次 Full GC这会导致系统的停顿时间变长。 CMS 无法处理浮动垃圾当 CMS 在进行垃圾回收的时候应用程序还在不断地产生垃圾这些垃圾会在 CMS 垃圾回收结束之后产生这些垃圾就是浮动垃圾CMS 无法处理这些浮动垃圾只能在下一次 GC 时清理掉。
G1 收集器
G1 (Garbage-First) 是一款面向服务器的垃圾收集器,主要针对配备多颗处理器及大容量内存的机器以极高概率满足 GC 停顿时间要求的同时还具备高吞吐量性能特征。引入了基于区域Region的垃圾回收策略。它是从 JDK 1.7 版本开始引入的。
G1垃圾收集器的主要目标是实现更短的停顿时间和更高的吞吐量。
G1 收集器特点
被视为 JDK1.7 中 HotSpot 虚拟机的一个重要进化特征在 JDK 9 时取代 CMS 成为了默认的垃圾收集器。它具备以下特点 增量G1 可以以增量方式执行垃圾回收这意味着它不需要一次性回收整个堆空间而是可以逐步、增量地清理。有助于控制停顿时间尤其是在处理大型堆时。 并行与并发G1 能充分利用 CPU、多核环境下的硬件优势使用多个 CPUCPU 或者 CPU 核心来缩短 Stop-The-World 停顿时间。部分其他收集器原本需要停顿 Java 线程执行的 GC 动作G1 收集器仍然可以通过并发的方式让 java 程序继续执行。 分代收集虽然 G1 可以不需要其他收集器配合就能独立管理整个 GC 堆但是还是保留了分代的概念。 空间整合与 CMS 的“标记-清除”算法不同G1 从整体来看是基于“标记-整理”算法实现的收集器从局部上来看是基于“标记-复制”算法实现的。 可预测的停顿这是 G1 相对于 CMS 的另一个大优势降低停顿时间是 G1 和 CMS 共同的关注点但 G1 除了追求低停顿外还能建立可预测的停顿时间模型能让使用者明确指定在一个长度为 M 毫秒的时间片段内消耗在垃圾收集上的时间不得超过 N 毫秒。
G1 收集器的分代理念
G1 是基于分代的思想进行设计的。它将堆内存分为多个大小相等的区域Region每个区域都可以是 Eden 区、Survivor 区或者 Old 区。 可以通过 -XX:G1HeapRegionSizen 来设置 Region 的大小可以设定为 1M、2M、4M、8M、16M、32M不能超过。
G1 有专门分配大对象的 Region 叫 Humongous 区而不是让大对象直接进入老年代的 Region 中。在 G1 中大对象的判定规则就是一个大对象超过了一个 Region 大小的 50%比如每个 Region 是 2M只要一个对象超过了 1M就会被放入 Humongous 中而且一个大对象如果太大可能会横跨多个 Region 来存放。
G1 收集器运作过程
它的设计思想是将堆内存划分为多个大小相等的区域Region每个区域都可以是Eden、Survivor 或 Old 区域。G1垃圾收集器通过并发、增量和并行的方式以区域为粒度进行垃圾回收其工作过程如下 初始标记Initial MarkG1垃圾收集器会首先标记出GC Roots能直接关联到的对象并记录下这些对象的存活状态。在此阶段应用程序的执行会停顿下来。 并发标记Concurrent MarkingG1垃圾收集器并发进行标记工作在应用程序运行的同时标记剩余的存活对象。在这个阶段G1会进行跨区域的引用扫描标记存活对象。 最终标记Final Mark在并发标记阶段结束后G1会做一次最终标记来修正并发标记期间有可能发生的引用变化。该阶段的停顿时间会较短。 筛选回收Live Data CountingG1根据各个区域内的垃圾量和存活对象数量等信息选择最有价值的区域进行垃圾收集。这个阶段被称为G1的Garbage-First策略。 G1 收集器在后台维护了一个优先列表每次根据允许的收集时间优先选择回收价值最大的 Region (Garbage-First) 这种使用 Region 划分内存空间以及有优先级的区域回收方式保证了 G1 收集器在有限时间内可以尽可能高的收集效率把内存化整为零 并发清理Concurrent CleanupG1进行并发的垃圾清理工作在应用程序运行的同时回收垃圾区域中的无用对象。 G1垃圾收集器在整个垃圾回收过程中会控制垃圾回收的停顿时间尽量减少对应用程序的影响。它可以根据应用程序的需要动态调整各个阶段的时间比例以达到更好的性能和吞吐量
