Java HotSpot虚拟机中的内存管理手册阅读笔记

显示与自动内存管理

内存管理是计算机编程中的一个重要概念，它涉及到跟踪和控制程序使用内存的方式。内存管理可以分为两种主要类型：显式内存管理和自动内存管理。

显式内存管理

在显式内存管理系统中，程序员必须手动分配和释放内存。这通常涉及到使用诸如malloc、free（在C语言中）或new、delete（在C++和Java中）之类的函数。

优点

性能优化：程序员可以精确控制内存的分配和释放，这可能在性能关键型应用中提供优势。
细粒度控制：允许程序员根据需要定制内存使用策略。

缺点

悬挂引用：如果一个对象被释放，但其他部分的代码仍然持有对该对象的引用（指针），则这些引用变为悬挂引用，可能导致未定义行为。
空间泄漏：如果内存被分配但没有正确释放，尤其是在长时间运行的程序中，可能会导致内存泄漏，最终耗尽系统资源。

自动内存管理

自动内存管理通常通过垃圾收集器实现，它自动检测并回收不再使用的内存块。

优点

安全性：减少了因手动内存管理错误导致的程序崩溃和安全漏洞。
简化编程：开发人员不需要担心内存分配和释放，可以减少代码复杂性和开发时间。

缺点

性能开销：垃圾收集可能会引入暂停，尤其是在需要进行大规模内存清理时。
资源使用：自动内存管理可能会使得程序的总体内存使用量略高，因为它需要维护额外的数据结构来跟踪内存使用情况。

垃圾收集器概念

垃圾收集器是现代编程语言中用于自动内存管理的一种机制，它的主要职责包括：

分配内存：当程序需要新的内存空间时，垃圾收集器负责在堆（heap）中寻找足够大小的未使用内存块并分配给请求的对象。
保持活动对象：确保所有仍在被程序使用的对象（即活动对象或被引用的对象）保留在内存中，防止它们被错误地回收。
回收内存：识别并回收那些不再被程序引用的死对象（即垃圾），释放它们所占用的内存空间供后续分配使用。

垃圾收集的目标和挑战

垃圾收集旨在解决显式内存管理中的一些常见问题，如悬挂引用和内存泄漏。然而，它并非完美无缺，例如，如果程序员持续创建并保持对对象的引用，那么内存仍然会被耗尽。此外，垃圾收集是一个资源密集型的过程，需要在运行时消耗CPU资源，有时还会导致程序暂停（尤其是在进行“停止世界”式的垃圾收集时）。

理想的垃圾收集特性

理想情况下，垃圾收集器应该具备以下特点：

安全性：不应错误地回收任何活动的（即仍在使用的）数据。
全面性：能够回收所有真正的垃圾对象，避免内存泄漏。
效率：具有低开销，不会显著影响程序性能。
低延迟：减少应用程序暂停的时间，特别是在交互式或实时系统中尤为重要。
减少碎片化：有效管理内存空间，避免因碎片化导致无法分配大块连续内存的问题。
可扩展性：能够适应从小型应用到大型系统的需要，同时支持多核处理器和大规模并行处理。

设计选择

在选择或设计垃圾收集算法时，需要考虑多种因素：

串行与并行：串行垃圾收集器一次只在一个线程上执行，而并行版本则可以利用多个CPU核心同时进行垃圾收集。
并发与停止世界：停止世界的收集器在收集期间完全暂停应用程序，而并发收集器则允许垃圾收集和应用程序同时运行，通常通过短暂的暂停来实现。
压缩与非压缩与复制：不同的策略决定了收集器如何处理回收的内存和活动对象。压缩将活动对象移动到一起以消除碎片，而非压缩仅标记空间为可用但不合并，复制则是将活动对象迁移到另一区域，源区域随后可以整块回收。

性能指标

评估垃圾收集器的性能通常考虑以下几个指标：

垃圾收集开销：垃圾收集所花费的总时间的百分比。
暂停时间：垃圾回收过程中应用程序执行停止的时间长度。
收集频率：相对于应用程序执行，收集发生的频率。
足迹：度量如堆大小等内存占用情况。
及时性：从对象变成垃圾到其内存变为可用的时间间隔。
垃圾收集器在不同类型的应用程序中有不同的需求和优化重点。以下是一些特定类型的应用程序及其对垃圾收集的需求：

交互式应用程序

交互式应用程序，如图形用户界面（GUI）程序或网络应用，需要快速响应用户操作，因此对垃圾收集的暂停时间非常敏感。在这种情况下，垃圾收集器需要能够快速完成收集工作，以最小化应用程序的暂停时间。

非交互式应用程序

对于非交互式应用程序，如批处理作业或数据分析任务，总体执行时间可能比单个操作的响应时间更重要。在这种场景下，垃圾收集器可以在后台进行更长时间的收集工作，而不会显著影响用户体验。

实时应用程序

实时应用程序，如控制系统或金融交易系统，对性能要求极高，需要预测性和低延迟。这种应用不仅要求垃圾收集的暂停时间短，还要求整个垃圾收集过程的时间消耗非常稳定和可预测。

嵌入式系统或个人计算机

在资源受限的环境，如嵌入式系统或个人计算机，内存占用成为一个关键问题。垃圾收集器需要有较低的内存足迹，并且能够有效地管理有限的资源。

代际垃圾收集

代际垃圾收集是一种优化内存回收的技术，它将内存分为不同的“代”，每一代存放不同生命周期的对象。最常见的是分两代：

年轻代（Young Generation）：新创建的对象通常分配在年轻代。由于大部分对象的生命周期很短，年轻代的垃圾收集（Minor GC）频繁发生，但回收速度快，因为很多对象很快就不再被引用。
老年代（Old Generation）：存活一段时间的对象会被移动到老年代。老年代的垃圾收集（Major GC或Full GC）发生的频率较低，但每次回收所需的时间较长，因为存活对象较多，且空间较大。

代际垃圾收集的优势

效率提升：根据对象的生存周期进行分区，使得可以针对不同的代使用不同的垃圾收集策略，从而提高整体效率。
减少暂停时间：年轻代的快速收集减少了应用程序的暂停时间，特别适合交互式应用。
空间优化：老年代使用的空间节省算法可以减少内存碎片，提高内存利用率。

代际垃圾收集利用了弱代际假设，即大部分对象很快就会死亡，只有少数对象会存活较长时间。这种假设使得针对年轻代的垃圾收集可以更加高效，而对于老年代则可以使用更节省空间的算法。通过这种方式，垃圾收集器可以在不同的应用场景下提供更好的性能和更低的延迟。

J2SE JVM中的4个垃圾收集器

从Java SE 5.0更新6开始，Java HotSpot虚拟机引入了四种不同的垃圾收集器，它们都属于世代垃圾收集器的类型。这些垃圾收集器分别针对不同的应用场景和性能需求进行了优化。以下是这四种垃圾收集器的简要介绍：

Serial收集器：这是一个单线程的收集器，适用于单核处理器的系统。它进行垃圾收集时会暂停所有应用线程，因此称为“停止世界”的收集器。Serial收集器主要针对年轻代进行收集，但也可以用于老年代，尤其是在堆空间较小的情况下。
Parallel收集器：Parallel收集器是一个并行的、“停止世界”的收集器，使用多个线程来加速垃圾收集过程。它可以用于年轻代和老年代，特别适用于多核处理器的服务器应用程序。Parallel收集器在年轻代中使用复制算法，在老年代中使用标记-整理算法。
Concurrent Mark Sweep (CMS)收集器：CMS收集器是一种并发的、主要针对老年代设计的收集器。它能够在应用程序运行的同时进行大部分垃圾收集工作，从而减少停顿时间。CMS收集器使用标记-清除算法，并且能够更好地处理与应用程序线程的并发执行。然而，CMS收集器在收集过程中可能会产生内存碎片。
G1收集器：G1（Garbage-First）收集器是一种面向堆内存管理和回收的收集器，它将堆划分为多个区域，可以并发地进行部分区域的垃圾收集，以实现更可预测的停顿时间。G1收集器旨在替换CMS收集器，提供更好的吞吐量和更低的延迟，适用于大堆和高并发的场景。

快速分配机制

在Java HotSpot JVM中，对象分配通常能够高效地完成，原因如下：

连续内存块：大多数情况下，JVM维护着连续的内存块用于对象的分配。这使得通过简单的指针操作即可快速分配内存。
线程本地分配缓冲区（TLAB）：为了提高多线程环境下的分配效率，HotSpot JVM使用线程本地分配缓冲区（TLAB）。每个线程都有自己的小块内存用于对象分配，这样可以减少同步开销。当一个线程的TLAB用尽时，它会请求一个新的TLAB，这时才需要进行同步操作。

这些优化措施确保了即使在高并发的环境下，对象的分配也能保持高效率，这对于性能要求高的应用尤其重要。

串行垃圾收集器（Serial Collector）

在Java HotSpot虚拟机中，串行收集器（Serial Collector）是一种基本的垃圾收集器，它使用单线程执行垃圾回收，适用于单核处理器系统。由于它在一个单独的线程中操作，它会暂停所有应用线程来进行垃圾回收，这被称为“停止世界”（Stop-The-World）的收集方式。这意味着在垃圾收集过程中，应用程序会暂时停止响应，直到收集过程完成。
在这里插入图片描述

年轻代的串行收集

当使用串行收集器进行年轻代回收时，整个过程如下：

复制活动对象：Eden区中的活动对象（即仍在使用的对象）会被复制到幸存者空间（Survivor Space）中的一个，这个空间之前是空的，标记为“To”区域。那些太大无法放入“To”空间的对象会直接被复制到老年代。
清空Eden区和From区：一旦活动对象被复制，Eden区和原本被占用的幸存者空间（标记为“From”区域）中剩下的对象都会被丢弃，因为这些区域中剩余的对象都是不再使用的。
交换幸存者空间角色：在下一次垃圾收集时，原本为空的幸存者空间（“To”空间）将变为新的“From”空间，原来的“From”空间则变为新的“To”空间。

老年代的串行收集

对于老年代和永久代的收集，串行收集器使用标记-压缩算法，过程如下：

标记阶段：首先，收集器会标记出仍然活跃的对象。
清除阶段：接着，收集器会清除标记过的对象，释放空间。
压缩阶段：最后，为了减少内存碎片，提高内存使用效率，收集器会将活跃对象移动到空间的一端，从而整合可用空间。

何时使用串行收集器

串行收集器通常适用于客户端类型的机器，特别是那些不需要非常低暂停时间的应用程序。它可以有效地管理中等大小的堆（如64MB），并且即使在最坏的情况下也能保持较短的暂停时间（例如，完全收集的时间不超过半秒）。

选择串行收集器

在J2SE 5.0版本中，串行收集器默认用于非服务器级别的机器。在其他类型的机器上，可以通过使用命令行选项 -XX:+UseSerialGC 来显式选择串行收集器。

总的来说，串行收集器是一个简单而有效的收集器，适合资源有限或单核处理器的环境。尽管它在收集过程中会暂停应用程序，但对于许多场景来说，它的性能和资源占用是可接受的。

并行垃圾收集器（Parallel Collector）

在当今的计算环境中，许多Java应用程序运行在配备大量物理内存和多核CPU的服务器上。为了充分利用这些硬件资源，并行收集器（也称为吞吐量收集器）被设计用来同时利用多个CPU核心进行垃圾回收，从而提高应用程序的整体吞吐量。

使用并行收集器收集年轻一代

并行收集器采用与串行收集器相同的复制算法来收集年轻一代，但不同的是，它使用多个CPU核心并行地进行收集工作。这样，它可以在较短的时间内完成垃圾收集，减少垃圾收集的开销，提高应用程序的运行效率。尽管它仍然是一个“停止世界”的收集器，通过并行化收集过程，它可以显著减少垃圾收集的暂停时间。

使用并行收集器收集老年代

对于老年代的垃圾收集，并行收集器使用与串行收集器相同的标记-压缩算法。这个过程也是单线程的，但它发生在并行收集器的年轻代垃圾回收之后，因此，应用程序在老年代收集期间仍会经历较长的暂停。

何时使用并行收集器

并行收集器特别适用于那些运行在多核CPU机器上且没有严格暂停时间要求的应用程序。这包括执行批量处理、计费、工资单处理、科学计算等任务的应用程序。这些应用通常可以容忍较长的垃圾收集暂停，以换取更高的总体吞吐量。

选择并行收集器

在J2SE 5.0版本中，并行收集器自动被选为服务器类机器上的默认垃圾收集器。在其他类型的机器上，可以通过使用命令行选项 -XX:+UseParallelGC 显式选择并行收集器。

总结

并行收集器是为充分利用多核CPU服务器而设计的，它通过并行执行垃圾收集任务来提高应用程序的吞吐量。尽管它可以减少年轻代收集的暂停时间，但在老年代收集时仍可能面临较长的暂停。因此，它适合那些可以容忍暂停的批量处理型应用程序。在选择垃圾收集器时，应根据应用程序的具体需求和运行环境来决定是否使用并行收集器。

并行压缩垃圾收集器（Parallel Compacting Collector）

在Java SE 5.0更新6中，引入了一种新的垃圾收集器，称为并行压缩收集器（Parallel Compacting Collector）。这种收集器采用了一种新的算法来处理老年代的垃圾收集，与之前的并行收集器有所区别，并预计将取代它。

使用并行压缩收集器的年轻代收集

并行压缩收集器在年轻代的收集上使用与并行收集器相同的算法。这意味着它也是一个多线程的“停止世界”收集器，利用多个CPU核心并行地进行年轻代的垃圾收集，以减少垃圾收集的暂停时间。

使用并行压缩收集器的老年代收集

并行压缩收集器在进行老年代垃圾收集时采用了三阶段的过程：

标记阶段：首先，将每一代划分为固定大小的区域。在这个阶段，初始活动对象集被垃圾收集线程划分，并并行地标记所有活动对象。
摘要阶段：这一阶段对区域而非单个对象进行操作。它首先检查区域的密度，确定哪些区域值得压缩。摘要阶段的结果是确定了一组“密集前缀”区域，这些区域中的对象不会被移动，而右侧的区域将被压缩以消除碎片。
压缩阶段：在这个阶段，将执行实际的对象移动和空间压缩，以整理和优化内存使用。这减少了碎片化，提高了内存的使用效率。

何时使用并行压缩收集器

并行压缩收集器适用于多CPU的机器，并且其老年代的并行操作能够减少垃圾收集的暂停时间，使其比并行收集器更适用于有暂停时间限制的应用程序。然而，它可能不适合在大型共享机器上运行的应用程序，如SunRays，因为这些环境不适宜让单个应用程序长时间占用多个CPU。

选择并行压缩收集器

要使用并行压缩收集器，必须通过指定命令行选项 -XX:+UseParallelOldGC 来选择它。这允许明确地选择这种收集器，以便根据应用程序的具体需求和运行环境来优化性能。

总之，并行压缩收集器是为充分利用多核CPU服务器而设计的，它通过并行执行垃圾收集任务来提高应用程序的吞吐量和响应性。它的设计旨在减少垃圾收集的暂停时间，同时提高内存的使用效率，是适合现代高性能计算需求的一种垃圾收集器。

CMS垃圾收集器（Concurrent Mark-Sweep (CMS) Collector)

对于需要快速响应时间的应用程序，端到端吞吐量虽重要，但更关键的是减少垃圾收集导致的长时间停顿。这种情况下，HotSpot JVM提供的并发标记扫描（CMS）收集器就显得特别合适。

使用CMS收集器收集年轻一代

CMS收集器在收集年轻代时，采用的方式与并行收集器相同。这意味着它也是一个多线程的“停止世界”收集器，利用多个CPU核心来并行处理年轻代的垃圾收集工作。

使用CMS收集器的老年代收集

CMS收集器在处理老年代垃圾收集时，大部分工作是与应用程序的执行同时进行的，从而减少了长时间的停顿。其工作周期开始于一个短暂的暂停，称为初始标记，这一步是为了标识可以直接从应用程序代码访问的活动对象集合。接下来，在并发标记阶段，收集器会标记所有可以从这个集合访问到的活动对象。由于应用程序在这个过程中仍在运行并可能更新引用字段，CMS收集器需要在第二个暂停阶段，即remark阶段，重新访问在并发标记阶段被修改的对象以确保所有活动对象都被正确标记。

CMS收集器不进行内存压缩，而是使用自由列表来管理内存。这种方式可能导致内存碎片和较高的分配成本。此外，CMS收集器通常需要更大的堆空间，并且在并发标记阶段可能无法回收所有的浮动垃圾。