Java on Evorsio

Z 垃圾收集器 (ZGC)

Tue, 28 Apr 2026 19:24:00 +1200

Z 垃圾收集器 (ZGC)

动机

ZGC（JEP 333）被设计用于低延迟和高可扩展性，并自 JDK 15（JEP 377）起已可用于生产环境。

ZGC 的大部分工作是在应用线程运行时完成的，只会短暂地暂停这些线程。ZGC 的停顿时间通常以微秒计；相比之下，默认垃圾收集器 G1 的停顿时间范围从毫秒到秒级不等。ZGC 的低停顿时间与堆大小无关：工作负载可以使用从几百 MB 到数 TB 的堆大小，并仍然保持低停顿时间。

对于许多工作负载而言，仅使用 ZGC 就足以解决所有与垃圾回收相关的延迟问题。这在具备足够资源（即内存和 CPU），以确保 ZGC 回收内存的速度快于并发运行的应用线程消耗内存的速度时效果良好。然而，ZGC 当前会将所有对象统一存储，不区分年龄，因此每次运行时都必须对所有对象进行回收。

弱分代假说（weak generational hypothesis）指出：年轻对象往往很快死亡，而老对象则会长期存活。因此，回收年轻对象所需资源更少且能回收更多内存，而回收老对象则需要更多资源且回收的内存较少。因此，通过更频繁地回收年轻对象，可以提升使用 ZGC 的应用性能。

描述

启用分代 ZGC

为了确保平稳过渡，我们最初将使分代 ZGC 与非分代 ZGC 并存。命令行选项 -XX:+UseZGC 将选择非分代 ZGC；要选择分代 ZGC，需要额外添加 -XX:+ZGenerational 选项：

1

$ java -XX:+UseZGC -XX:+ZGenerational ...

在未来的某个版本中，我们计划将分代 ZGC 设为默认值，此时 -XX:-ZGenerational 将用于选择非分代 ZGC。在更晚的版本中，我们计划移除非分代 ZGC，此时 ZGenerational 选项将被废弃。

设计

分代 ZGC 将堆划分为两个逻辑分代：年轻代用于存放新分配的对象，而老年代用于存放长期存活的对象。每个分代都独立于另一个分代进行回收，因此 ZGC 可以专注于回收更“高收益”的年轻对象。

与非分代 ZGC 一样，所有垃圾回收都在应用程序运行的同时并发执行，并且应用程序的停顿时间通常小于一毫秒。由于 ZGC 在应用运行的同时读取和修改对象图，因此必须确保应用程序始终看到一致的对象图视图。ZGC 通过染色指针（colored pointers）、读屏障（load barriers）和写屏障（store barriers）来实现这一点。

染色指针（colored pointer） 是一种指向堆中对象的指针，它在包含对象内存地址的同时，还携带用于编码对象已知状态的元数据。这些元数据描述了对象是否已知存活、地址是否正确等信息。ZGC 始终使用 64 位对象指针，因此可以为多 TB 的堆提供足够的元数据位和地址空间。当对象字段引用另一个对象时，ZGC 使用染色指针来实现该引用。
读屏障（load barrier） 是 ZGC 注入到应用程序中的一段代码，用于在应用读取对象字段（该字段引用另一个对象）时执行。读屏障会解析存储在染色指针中的元数据，并在应用使用该引用对象之前可能执行一些操作。

非分代 ZGC 同时使用染色指针和读屏障。分代 ZGC 还额外使用写屏障，以高效地跟踪不同分代之间的引用。

写屏障（store barrier） 是 ZGC 注入到应用程序中的一段代码，用于在应用向对象字段写入引用时执行。分代 ZGC 在染色指针中增加了新的元数据位，使写屏障能够判断该字段是否已经被记录为可能包含跨分代引用。染色指针使得分代 ZGC 的写屏障比传统分代写屏障更高效。

写屏障的引入，使分代 ZGC 可以将“可达对象标记”的工作从读屏障转移到写屏障中。也就是说，写屏障可以利用染色指针中的元数据位，高效判断在写入前该字段所引用的对象是否需要被标记。

将标记（marking）从读屏障中移出，使得对其进行优化变得更容易，这一点非常重要，因为读屏障通常比写屏障执行得更频繁。现在，当读屏障解释一个染色指针时，如果对象已被搬迁，它只需要更新对象地址，并更新元数据以表示该地址已被确认正确。后续的读屏障会根据这些元数据进行判断，不再重复检查该对象是否已被搬迁。

分代 ZGC 在染色指针中使用不同的标记与搬迁（relocation）元数据位集合，从而使各个分代可以独立进行回收。

接下来的章节描述了区分分代 ZGC 与非分代 ZGC，以及与其他垃圾收集器的关键设计概念：

无多重内存映射（No multi-mapped memory）
优化的屏障（Optimized barriers）
双缓冲记忆集（Double-buffered remembered sets）
无需额外堆内存的对象搬迁（Relocations without additional heap memory）
紧凑堆区域（Dense heap regions）
大对象（Large objects）
完整垃圾回收（Full garbage collections）

多重映射内存（multi-mapped memory）

非分代 ZGC 使用多重映射内存（multi-mapped memory）来降低读屏障的开销。而分代 ZGC 则改为在读屏障和写屏障中使用显式代码实现。

对于用户而言，这一变化的主要优势在于：更容易衡量堆所使用的内存量。在多重映射情况下，同一段堆内存会被映射到三个独立的虚拟地址范围中，因此像 ps 这样的工具报告的堆内存使用量大约是实际使用量的三倍。

对于 GC 本身而言，这一变化意味着染色指针中的元数据位不再需要位于与堆可访问地址范围对应的指针部分。这使得可以增加更多元数据位，并且也为将最大堆大小从非分代 ZGC 的 16TB 限制进一步提升提供了可能性。

在分代 ZGC 中，存储在对象字段中的对象引用以染色指针形式实现。而存储在 JVM 栈中的对象引用则以“无色指针”（colorless pointers）形式实现，即不包含元数据位，存在于硬件栈或 CPU 寄存器中。读屏障和写屏障负责在染色指针与无色指针之间进行相互转换。

由于在硬件栈或 CPU 寄存器中不会出现染色指针，因此可以采用更特殊的染色指针布局，只要染色指针与无色指针之间的转换足够高效即可。分代 ZGC 使用的染色指针布局将元数据放在指针的低位，而对象地址放在高位。这样可以最大程度减少读屏障中的机器指令数量。在 x64 架构上，通过精心设计的编码方式，一个移位指令即可同时完成“判断是否需要处理该指针”以及“移除元数据位”的操作。

优化屏障（Optimized barriers）

随着写屏障（store barriers）的引入，以及读屏障（load barriers）新增的职责，更多 GC 代码将与编译后的应用代码交织在一起。为了最大化吞吐量，这些屏障需要被高度优化。分代 ZGC 的许多关键设计决策都涉及染色指针（colored pointer）方案和屏障机制。

用于优化屏障的一些技术包括：

快速路径与慢速路径
最小化读屏障职责
记忆集屏障（remembered-set barriers）
SATB 标记屏障（SATB marking barriers）
融合写屏障检查（fused store barrier checks）
写屏障缓冲区（store barrier buffers）
屏障补丁（barrier patching）

快速路径与慢速路径

ZGC 将屏障拆分为两部分。快速路径检查在应用程序使用引用对象之前是否需要执行额外的 GC 工作。慢速路径执行这些额外工作。所有对象访问都会执行快速路径检查。由于必须非常快，这部分代码会直接插入到即时编译（JIT）后的应用程序代码中。慢速路径只在少数情况下执行。当进入慢速路径时，被访问对象指针的颜色会被修改，使得后续对同一指针的访问在一段时间内不会再次触发慢速路径。因此，慢速路径不需要高度优化，为了可维护性，它们以 JVM 中的 C++ 函数形式实现。

在非分代 ZGC 中，这是读屏障（load barriers）的拆分方式。在分代 ZGC 中，同样的机制也应用于写屏障（store barriers）及其相关的 GC 工作。

最小化读屏障（load barrier）职责

在非分代 ZGC 中，读屏障负责：

更新 GC 已搬迁对象的过期引用
将加载的对象标记为存活（因为应用正在访问该对象，因此认为其存活）

在分代 ZGC 中，需要同时跟踪两个分代，并在染色指针（colored pointer）与无色指针之间进行转换。为了降低复杂度，并优化读屏障的快速路径，将标记职责从读屏障转移到写屏障。

在分代 ZGC 中，读屏障负责：

移除染色指针（colored pointer）中的元数据位
更新 GC 已搬迁对象的过期引用

写屏障（store barrier）负责：

向指针添加元数据位以生成染色指针（colored pointer）
维护记忆集（remembered set），用于跟踪老年代到年轻代的引用
将对象标记为存活

记忆集屏障（remembered-set barriers）

当分代 ZGC 回收年轻代时，只会访问年轻代中的对象。但老年代中的对象可能包含指向年轻代对象的引用，这些引用在回收过程中必须被处理，原因有两个：

GC 标记根（GC marking roots）：这些引用可能是使年轻代对象仍然可达的唯一路径，因此必须作为对象图的根来处理，以确保所有存活对象都能被标记
过期引用：在回收年轻代时，对象会被移动，但老年代中的引用不会立即更新，而是在应用访问时由读屏障惰性更新。如果应用未访问这些引用，GC 需要在后续阶段统一修复这些过期引用

老年代到年轻代的引用集合称为记忆集（remembered set）。记忆集包含所有位于老年代中的内存地址，这些地址可能包含指向年轻代对象的引用。写屏障（store barrier）会向记忆集添加条目。当一个引用被写入对象字段时，该字段被认为可能包含老年代到年轻代的引用。写屏障的慢速路径会过滤掉对年轻代字段的写入，因为只有老年代中的地址是需要关注的。慢速路径不会根据写入的值进行过滤，该值可能指向年轻代或老年代对象。垃圾收集器在使用记忆集时，会检查对象字段的当前值。

这一切保证了写屏障（store barrier）在维护记忆集时具有“只执行一次”的特性。这意味着，在两个连续的年轻代标记阶段之间，每个被写入的对象字段，写屏障慢速路径只会执行一次。当某个字段第一次被写入时，会发生以下步骤：

快速路径检查即将被覆盖的字段原值
颜色信息表明该字段在上一次年轻代标记阶段之后未被写入
进入慢速路径
将该字段地址加入记忆集（remembered set）
将新的指针值染色后写入字段

新的指针值会被染色，使后续快速路径检查能够识别该字段已经执行过慢速路径处理。

SATB 标记屏障（SATB marking barriers）

与非分代 ZGC 不同，分代 ZGC 使用起始快照（SATB，snapshot-at-the-beginning）标记算法。在标记阶段开始时，垃圾收集器会对 GC 根（GC roots）进行快照；在标记阶段结束时，所有在标记开始时从这些根可达的对象都能被保证找到并标记为存活。

为实现这一点，当对象图中的引用关系被破坏时，垃圾收集器必须能够获知。因此，写屏障（store barrier）会将即将被覆盖的字段值上报给垃圾收集器；垃圾收集器随后会标记该引用对象，并继续访问并标记从该对象可达的其他对象。

在一次标记周期内，写屏障只需要在某个字段第一次被写入时，上报该字段即将被覆盖的值。对同一字段的后续写入，只是替换一个垃圾收集器已经保证能够找到的值，因为 SATB 特性保证了这些对象在本次标记中已经被处理或会被处理。SATB 特性进一步支持了写屏障在标记语义上的“只执行一次”性质。

融合写屏障检查（fused store barrier checks）

写屏障的记忆集维护和标记功能存在很多相似之处，它们都使用染色指针（colored pointer）的快速路径检查，并且都具有各自的“只执行一次”特性。因此，不再为每种条件设置独立的快速路径检查，而是将它们融合为一个统一的快速路径检查。如果任意一个条件不满足，就会进入慢速路径，并执行所需的 GC 工作。

写屏障缓冲区（store barrier buffers）

将屏障拆分为快速路径与慢速路径，并结合指针染色，可以减少对 C++ 慢速路径函数的调用次数。分代 ZGC 通过在快速路径与慢速路径之间引入一个由 JIT 编译的中间路径来进一步降低开销。该中间路径会将即将被覆盖的字段值以及对象字段地址存入写屏障缓冲区，然后直接返回到应用代码，而不会进入代价较高的慢速路径。只有当写屏障缓冲区被填满时，才会触发慢速路径。这种方式将从编译代码切换到 C++ 慢速路径的开销进行了摊销。

屏障补丁（barrier patching）

读屏障（load barrier）和写屏障（store barrier）在执行检查时，会访问垃圾收集器在不同阶段切换时更新的全局变量或线程本地变量。不同 CPU 架构在访问这些变量时的开销不同。

在分代 ZGC 中，通过在可能的情况下对屏障代码进行补丁优化来降低这部分开销。全局状态值会被编码到屏障的机器指令中作为立即数，而不再需要通过访问全局变量或线程本地变量来获取当前状态。当垃圾收集器切换阶段时（例如开始年轻代标记阶段），相关方法首次执行时会对这些立即数进行更新。这进一步降低了屏障的运行开销。

双缓冲记忆集（double-buffered remembered sets）

许多垃圾收集器使用一种称为卡表标记（card table marking）的记忆集技术来跟踪分代间引用。当应用线程写入对象字段时，也会同时将卡表（card table）中的某个字节标记为“脏”（dirty）。通常，卡表中一个字节对应堆中约 512 字节的地址范围。为了找到所有老年代到年轻代的引用，垃圾收集器必须定位并访问所有属于这些“脏字节”对应地址范围内的对象字段。

相比之下，分代 ZGC 使用位图（bitmap）来精确记录对象字段位置，其中每一位表示一个可能的对象字段地址。每个老年代区域都有一对记忆集位图（remembered-set bitmaps）。其中一个位图由应用线程通过写屏障（store barrier）进行写入并保持活跃，另一个位图则作为垃圾收集器的只读副本，保存当前所有可能指向年轻代的老年代引用。这两个位图会在每次年轻代收集开始时进行原子交换。该机制的一个好处是应用线程不需要等待位图被清空。垃圾收集器可以在处理并清空一个位图的同时，另一个位图继续被应用线程并发写入。另一个好处是由于应用线程和 GC 线程操作不同位图，因此减少了它们之间对额外内存屏障（memory barrier）的需求。其他使用卡表标记的分代收集器（如 G1）在标记卡表时需要执行内存屏障，这可能导致写屏障性能更差。

无需额外堆内存的对象迁移（relocations without additional heap memory）

其他 HotSpot 垃圾收集器中的年轻代收集通常使用“转移式回收（scavenging）”模型：在一次遍历中找到并移动存活对象。在垃圾收集器完全知道哪些对象存活之前，年轻代中的所有对象都必须被处理完成。这类收集器只能在所有对象迁移完成后才能回收内存。因此，它们需要预估存活对象所需的内存量，并确保在 GC 开始时有足够空间。如果估算错误，就需要更昂贵的回收方式，例如对未迁移对象进行原地固定（pinning）导致碎片化，或暂停所有应用线程执行全堆 Full GC。

分代 ZGC 使用两次遍历：第一次遍历用于访问并标记所有可达对象，第二次遍历用于迁移已标记对象。由于在迁移阶段开始之前 GC 已经拥有完整的存活信息，它可以按区域（region）粒度分配迁移工作。一旦某个区域内的所有存活对象都被迁移出去，该区域就被认为已完成回收，可以重新作为迁移目标区域或用于应用线程分配内存。即使没有新的空闲区域可用，ZGC 仍然可以通过将对象压缩到正在迁移的区域中继续执行。这使得分代 ZGC 可以在不依赖额外堆内存的情况下完成年轻代的迁移和压缩。

密集堆区域（dense heap regions）

当从年轻代迁移对象时，不同区域中的存活对象数量及其占用内存会存在差异。例如，最近分配的区域通常包含更多存活对象。

ZGC 会分析年轻代区域的密度（density），以决定哪些区域值得回收，哪些区域过于“满”或回收成本过高。未被选择回收的区域会被原地晋升：其中的对象保持在原位置不移动，这些区域要么继续保留在年轻代作为幸存者区域（survivor regions），要么被晋升到老年代。这些幸存区域中的对象会获得“第二次死亡机会”，希望在下一次年轻代回收开始时，其中更多对象已经死亡，从而使更多区域可以被回收。

这种对高密度区域进行原地老化（aging）的方式，可以降低年轻代回收的整体开销。

大对象（large objects）

ZGC 已经能够很好地处理大对象。通过将虚拟内存与物理内存解耦，并预留大量虚拟地址空间，ZGC 通常可以避免 G1 中可能导致大对象分配困难的碎片问题。

在分代 ZGC 中，这一点进一步增强：允许大对象直接在年轻代中分配。由于区域可以在不移动对象的情况下被老化，因此没有必要为了避免昂贵的迁移而将大对象强制分配到老年代。相反，如果大对象生命周期较短，可以在年轻代中直接回收；如果生命周期较长，也可以低成本地晋升到老年代。

全垃圾收集（full garbage collections）

当回收老年代时，年轻代中的对象可能会引用老年代中的对象，这些引用被视为老年代对象图的根。由于年轻代对象变化频繁，不对年轻代到老年代的引用进行持续跟踪。相反，这些引用通过在老年代标记阶段同时执行一次年轻代回收来发现。当年轻代回收发现指向老年代的引用时，会将其传递给老年代标记过程。

这次额外的年轻代回收仍然作为一次正常的年轻代回收执行，并会将存活对象保留在幸存区域中。这会带来一个影响：年轻代中的幸存对象不会参与老年代回收阶段中的引用处理和类卸载。因此，可能会出现这样的情况：应用释放了对象图的最后引用，调用系统级垃圾回收，然后期望某些弱引用被清除或入队，或者某些类被卸载，但实际上并没有立即发生。

为了缓解这个问题，当应用显式触发垃圾回收时，会在老年代回收开始之前先执行一次额外的年轻代回收，将所有存活对象提前晋升到老年代。

替代方案

更简单的屏障与指针染色方案

当前的读屏障（load barrier）和写屏障（store barrier）实现并不容易理解。一个更简单的版本可能更易维护，但代价是更高的读写屏障开销。我们评估了大约十种不同的屏障实现方式，但没有一种在性能上优于当前基于移位操作的读屏障设计。未来仍然值得继续研究并分析这种“性能与复杂度”之间的权衡。

继续使用多重映射内存（multi-mapped memory）

可以通过继续使用多重映射内存（multi-mapped memory）来避免颜色指针中“无色根”的设计，从而采用更简单的实现方案。如果相比非分代 ZGC 需要更多的指针元数据位，那么最大堆大小将受到限制。另一种方式是采用混合方案：部分元数据位通过多重映射内存实现，另一部分则由读写屏障进行移除和添加。

测试

ZGC 实现中为无色指针（colorless pointer）和染色指针（colored pointer）使用了不同的 C++ 类型，从而保证两者之间不会发生隐式转换。染色指针仅限于 GC 代码和屏障使用。只要运行时系统通过 HotSpot 的访问接口和屏障来访问对象指针，它就只会看到可解引用的无色指针。运行时可见的对象指针类型始终是无色指针。我们在不同的对象指针类型中注入了大量验证代码，以便快速发现指针损坏或屏障缺失的问题。

标准垃圾收集算法测试集将用于验证正确性。

风险与假设

实现复杂度

分代 ZGC（Generational ZGC）中的屏障和染色指针（colored pointer）比非分代 ZGC 更复杂。分代 ZGC 还会并发运行两个垃圾收集器；这两个收集器相对独立，但在一些复杂机制上仍然会相互交互，从而增加实现复杂度。

由于额外的复杂性，从长期来看，我们计划通过完全用分代 ZGC 替代原有的非分代 ZGC，从而降低维护成本。

分代 ZGC 与非分代 ZGC 的性能差异

我们认为分代 ZGC（Generational ZGC）比其前身更适合大多数使用场景。一些工作负载甚至可能由于资源使用更低而获得吞吐量提升。例如，在 Apache Cassandra 基准测试中，分代 ZGC 只需要四分之一的堆大小，却能达到四倍吞吐量，同时仍将停顿时间控制在 1 毫秒以内。

某些本质上是非分代特性的工作负载可能会出现轻微性能下降。我们认为这类工作负载的比例足够小，不足以支撑长期维护两套独立 ZGC 实现的成本。

另一个潜在开销来源是更复杂的 GC 屏障（GC barriers）。我们预计这部分开销大多会被避免频繁回收老年代对象所带来的收益抵消。

另一个开销来源是同时运行两个垃圾收集器。需要合理平衡它们的触发频率和 CPU 使用，以避免对应用造成过度影响。

与 GC 开发的常规情况一样，未来的改进和优化将由基准测试和用户反馈驱动。我们计划在首次发布之后仍持续改进分代 ZGC。

Garbage-First（G1）垃圾收集器

Tue, 28 Apr 2026 18:24:00 +1200

Garbage-First（G1）垃圾收集器

简介

Garbage-First（G1）垃圾收集器面向多处理器机器设计，可扩展到大容量内存。它力图在高概率下满足垃圾回收的停顿时间目标，同时在几乎无需配置的情况下实现高吞吐量。G1 旨在在当前目标应用和环境中，在延迟与吞吐量之间提供最佳平衡，这些应用和环境具有以下特征：

堆大小可达数十 GB 或更大，且 Java 堆中超过 50% 被存活数据占用。
对象分配和晋升（promotion）的速率会随时间显著变化。
堆中存在大量内存碎片。
需要可预测的停顿时间目标，且停顿时间不超过几百毫秒，从而避免长时间的垃圾回收暂停。

G1 在应用程序运行的同时执行部分工作。它通过占用本可供应用程序使用的处理器资源，来换取更短的回收停顿时间。

这一点最明显地体现在：当应用程序运行时，会有一个或多个垃圾回收线程同时处于活跃状态。因此，与以吞吐量为优先的收集器相比，虽然 G1 的垃圾回收停顿通常更短，但应用程序的整体吞吐量也往往会略有降低。

G1 是默认的垃圾收集器。

G1 收集器通过多种方式实现高性能，并尝试满足停顿时间目标，这些方式将在后续章节中进行说明。

启用 G1

Garbage-First 垃圾收集器是默认收集器，因此通常不需要进行任何额外操作。你可以通过在命令行中添加 -XX:+UseG1GC 来显式启用它。

基本概念

G1 是一种分代的、增量式的、并行的、主要是并发的、会产生 Stop-The-World（STW）暂停的、并通过回收（evacuating）方式工作的垃圾收集器，它会在每次 STW 暂停中监控暂停时间目标。与其他收集器类似，G1 将堆划分为（虚拟的）新生代和老年代。空间回收主要集中在新生代，因为在该区域进行回收效率最高，同时也会偶尔在老年代进行空间回收。

某些操作始终在 Stop-The-World 暂停中执行，以提升吞吐量。而一些在应用程序停止时会耗时较长的操作，例如整个堆级别的操作（如全局标记），则会与应用程序并行、并发执行。为了在空间回收过程中保持较短的 STW 暂停，G1 以增量方式、分步骤并行地执行空间回收。G1 通过跟踪之前应用行为和垃圾回收暂停的信息来建立成本模型，从而实现可预测性，并使用这些信息来决定每次暂停中执行的工作量。例如，G1 会优先回收最有效率的区域（即主要充满垃圾的区域，因此得名 Garbage-First）。

G1 主要通过“疏散（evacuation）”来回收空间：将选定内存区域中的存活对象复制到新的内存区域中，并在此过程中对其进行压缩。在疏散完成后，原先被存活对象占用的空间会被应用程序重新用于分配。

Garbage-First 收集器不是实时收集器。它试图在较长时间范围内以较高概率满足设定的暂停时间目标，但对于单次暂停来说，并不能保证绝对确定地满足该目标。

堆布局

G1 将堆划分为一组大小相等的堆区域（heap regions），每个区域都是一段连续的虚拟内存范围，如图 7-1 所示。区域是内存分配和内存回收的基本单位。在任何给定时刻，这些区域可以是空的（浅灰色），或者被分配给某个特定的分代：新生代或老年代。当有内存请求到来时，内存管理器会分配空闲区域，并将其分配给某个分代，然后将其作为可用空间返回给应用程序，供其进行分配。

新生代包含 Eden 区域（红色）和 Survivor 区域（带 “S” 的红色）。这些区域的功能与其他收集器中的对应连续空间相同，但不同之处在于，在 G1 中这些区域在内存中通常以非连续的方式分布。老年代区域（浅蓝色）构成老年代。对于跨越多个区域的对象，老年代区域可能是巨型对象（humongous）（带 “H”的浅蓝色）。

应用程序始终在新生代中进行分配，也就是 Eden 区域中进行分配，但“巨型对象”除外，这类对象会直接在老年代中分配。

垃圾收集周期

从高层次来看，G1 收集器在两个阶段之间交替运行。仅年轻代阶段（young-only phase）包含垃圾回收操作，这些操作会逐步将当前可用内存填充为老年代中的对象。空间回收阶段（space-reclamation phase）则是在处理年轻代的同时，逐步回收老年代中的空间。随后，该周期会再次从仅年轻代阶段开始。

以下列表详细描述了 G1 垃圾收集周期的各个阶段、它们的停顿以及阶段之间的转换过程：

仅年轻代阶段（Young-only phase）

该阶段从若干次“普通年轻代收集（Normal young collections）”开始，这些收集会将对象逐步晋升到老年代。当老年代的占用率达到某个阈值（即“堆占用触发阈值 / Initiating Heap Occupancy threshold”）时，系统会从该阶段过渡到空间回收阶段（space-reclamation phase）。此时，G1 会调度一次“并发开始收集（Concurrent Start young collection）”，而不是普通的年轻代收集。

Concurrent Start（并发开始）：这种收集在执行普通年轻代收集的同时，还会启动标记（marking）过程。并发标记用于确定老年代区域中当前所有可达（存活）的对象，这些对象将在后续的空间回收阶段中被保留。在标记尚未完全结束时，仍然可能发生普通的年轻代收集。标记最终通过两个特殊的 Stop-The-World（STW）停顿完成：Remark 和 Cleanup。

Concurrent Start 停顿也可能判断不需要继续进行标记：在这种情况下，会发生一个简短的并发标记撤销（undo）阶段，然后继续仅年轻代阶段。在这种情况下，不会发生 Remark 和 Cleanup 停顿。
Remark（重新标记）：该停顿用于最终完成标记本身，并执行引用处理和类卸载，回收完全空的区域，并清理内部数据结构。在 Remark 和 Cleanup 之间，G1 会计算后续在并发过程中回收选定老年代区域空间所需的信息，这些工作将在 Cleanup 阶段最终完成。
Cleanup（清理）：该停顿用于判断是否真的进入空间回收阶段。如果进入空间回收阶段，则仅年轻代阶段会以一次“准备混合收集（Prepare Mixed young collection）”结束。

空间回收阶段（Space-reclamation phase）

该阶段由多次年轻代收集组成，这些收集除了处理年轻代区域外，还会回收部分老年代区域中的存活对象。这些收集也称为“混合收集（Mixed collections）”。当 G1 判断继续回收更多老年代区域所带来的收益不足以抵消成本时，空间回收阶段结束。

在空间回收结束后，整个收集周期会重新回到新的仅年轻代阶段作为开始。

作为备用机制，如果在收集存活信息的过程中应用程序耗尽内存，G1 会像其他收集器一样执行一次原地的 Stop-The-World 全堆压缩（Full GC）。

垃圾收集停顿与收集集合（Collection Set）

G1 在 Stop-The-World（STW）停顿中执行垃圾收集和空间回收操作。存活对象通常会从源区域复制到堆中的一个或多个目标区域，同时对这些被移动对象的引用进行调整。

对于非巨型（non-humongous）区域，一个对象的目标区域是根据该对象所在的源区域来确定的：

新生代（年轻代）的对象（eden 和 survivor 区域中的对象）会根据其年龄被复制到 survivor 区域或老年代区域。
来自老年代区域的对象会被复制到其他老年代区域。

位于巨型（humongous）区域中的对象则以不同方式处理。G1 只会判断这些对象是否存活，如果不存活，则回收其占用的空间。G1 只有在非常慢的“最后手段”收集过程中才会移动巨型对象。

Remembered Set（记忆集）

为了对收集集合（collection set）中的区域进行疏散（evacuation），G1 维护了一个记忆集（remembered set）：它记录了堆中位于收集集合之外、但包含指向收集集合内部引用的位置集合。当垃圾回收期间收集集合中的对象被移动时，所有来自收集集合外部、指向该对象的引用都必须被更新为指向对象的新位置。

记忆集条目使用近似位置来节省内存：通常来说，彼此接近的引用往往指向彼此接近的对象。G1 在逻辑上将堆划分为卡片（card），默认大小为 512 字节。记忆集条目是这些卡片索引的压缩表示。

G1 最初以“按区域（per-region）”的方式管理记忆集：每个区域都包含一个本地区域的记忆集，即可能包含指向该区域引用的位置集合。在垃圾回收期间，会基于这些区域记忆集生成整个收集集合的记忆集。

记忆集主要是延迟创建的：在 Remark 与 Cleanup 停顿之间，G1 会为所有收集集合候选区域重建其记忆集。除此之外，G1 始终维护年轻代区域的记忆集，因为它们在每次回收中都会被处理，并且默认情况下也会对部分巨型对象进行维护，以便进行主动回收。

Collection Set（收集集合）

收集集合是指用于回收空间的源区域集合。根据垃圾收集类型的不同，收集集合由不同类型的区域组成：

在仅年轻代阶段（Young-Only phase）中，收集集合仅包含年轻代区域，以及可能可以回收的巨型对象所在区域。
在空间回收阶段（Space-Reclamation phase）中，收集集合包含年轻代区域、可能可回收的巨型对象区域，以及来自候选集合中的部分老年代区域。

收集集合候选区域（collection set candidate regions）是那些在空间回收阶段中高度可能被回收的区域。G1 会在 Remark 停顿期间根据它们包含的存活数据量以及与其他区域的连接关系来选择这些区域。

存活数据少（即空闲空间多）的区域优先于大部分数据存活的区域
连接性低的区域优先于连接性高的区域

因为回收这些“更高效”的区域所需的工作量更小。G1 会从候选区域中剔除那些对可回收空间贡献不大的区域，例如那些可回收空间少于 -XX:G1HeapWastePercent 指定比例的区域。这些区域在本次空间回收阶段中将不会被回收。

在 Remark 与 Cleanup 停顿之间，G1 会开始为后续回收做准备，而 Cleanup 停顿则完成这些工作，并根据效率对区域进行排序。那些回收成本更低、同时可释放空间更多的区域，会在后续的 Mixed 收集中被优先回收。

垃圾收集过程（Garbage Collection Process）

一次垃圾收集由四个阶段组成：

Pre Evacuate Collection Set（疏散前准备阶段）该阶段执行垃圾收集的一些准备工作：将 TLAB（线程本地分配缓冲区）从 mutator 线程中分离、根据《Java 堆大小调整》中描述的方式选择本次收集集合（collection set），以及其他一些较小的准备操作。
Merge Heap Roots（合并堆根）在该阶段，G1 会从收集集合区域中创建一个统一的记忆集（remembered set），以便后续进行更容易的并行处理。这一步会去除各个独立记忆集中大量重复项，否则这些重复项需要在之后以更高成本进行过滤处理。
Evacuate Collection Set（疏散收集集合）这是主要的工作阶段：G1 从根（roots）开始移动对象。根引用是指来自收集集合之外的引用，包括：

JVM 内部数据结构中的引用（外部根 external roots）
代码中的引用（代码根 code roots）
Java 堆其余部分中的引用（堆根 heap roots）

对于所有根引用，G1 会将收集集合中被引用的对象复制到其目标区域，并递归处理其引用，将指向收集集合内对象的引用作为新的根继续处理，直到不再存在新的根为止。

各个子阶段的执行时间可以通过 -Xlog:gc+phases=debug 日志观察，包括：Ext Root Scanning、Code Root Scan、Scan Heap Roots 和 Object Copy 等子阶段。

G1 还可能会为可选的收集集合重复执行主要的疏散阶段。

Post Evacuate Collection Set（疏散后处理阶段）该阶段包含清理工作，包括引用处理，以及为后续 mutator（应用线程）阶段做准备。

这些阶段对应于使用 -Xlog:gc+phases=info 时所打印的各个阶段。

Garbage-First 内部机制（Garbage-First Internals）

本节描述 Garbage-First（G1）垃圾收集器的一些重要细节。

Java 堆大小调整（Java Heap Sizing）

G1 在调整 Java 堆大小时遵循标准规则，使用以下参数：

-XX:InitialHeapSize：Java 堆初始大小
-XX:MaxHeapSize：Java 堆最大大小
-XX:MinHeapFreeRatio：用于确定最小空闲内存百分比
-XX:MaxHeapFreeRatio：用于确定调整后最大空闲内存百分比

G1 垃圾收集器仅在 Remark（重新标记）停顿 和 Full GC（完整垃圾回收）停顿期间考虑根据这些选项调整 Java 堆大小。该过程可能会向操作系统释放内存，或从操作系统申请内存。

堆扩展发生在垃圾收集停顿期间，而内存释放则发生在停顿之后，并与应用程序并发执行。

仅年轻代阶段的分代大小调整（Young-Only Phase Generation Sizing）

G1 总是在一次普通的年轻代收集结束时，为下一个 mutator（应用线程）阶段确定年轻代的大小。通过这种方式，G1 可以基于对实际停顿时间的长期观察，满足使用 -XX:MaxGCPauseTimeMillis 和 -XX:GCPauseIntervalMillis 设置的停顿时间目标。

该计算会考虑相似大小的年轻代在以往回收中所花费的时间，例如包括以下信息：

在垃圾收集期间需要复制的对象数量
这些对象之间的相互关联程度

-XX:GCPauseIntervalMillis 和 -XX:MaxGCPauseTimeMillis 选项共同定义了最小应用程序利用率（Minimum Mutator Utilization, MMU）。G1 会尝试在每一个长度为 -XX:GCPauseIntervalMillis 的时间窗口内，使垃圾收集停顿时间最多占用 -XX:MaxGCPauseTimeMillis 毫秒。

如果没有其他约束，G1 会在 -XX:G1NewSizePercent 和 -XX:G1MaxNewSizePercent 所定义的范围之间自适应地调整年轻代大小，以满足停顿时间目标。有关如何修复长时间停顿的更多信息，请参见《Garbage-First 垃圾收集器调优》。

另外，也可以使用 -XX:NewSize 与 -XX:MaxNewSize 分别设置年轻代的最小和最大大小。

📝 备注

只指定其中一个后续选项（-XX:NewSize 或 -XX:MaxNewSize）会将年轻代大小固定为通过该参数传入的精确值。

这会禁用停顿时间控制（pause time control）。

空间回收阶段的分代大小调整（Space-Reclamation Phase Generation Sizing）

在空间回收阶段（space-reclamation phase）中，G1 会尝试在单次垃圾收集停顿中，最大化老年代空间的回收量。年轻代的大小通常会被设置为允许的最小值，一般由 -XX:G1NewSizePercent 决定，同时也会考虑 MMU（最小应用程序利用率）规范。

在该阶段的每一次 mixed 收集开始时，G1 会从收集集合候选区域中选择一部分区域加入到收集集合中。这些额外加入的老年代区域由三部分组成：

最小老年代区域集合用于确保疏散（evacuation）进度的基本集合。该集合的大小由“收集集合候选区域数量 ÷ 空间回收阶段长度（由 -XX:G1MixedGCCountTarget 决定）”来计算。
额外老年代区域集合如果 G1 预测在完成最小集合回收后仍然有剩余时间，则会从候选区域中继续加入老年代区域，直到预测使用约 80% 的剩余停顿时间为止。
可选收集集合（Optional collection set）在完成前两部分之后，如果本次停顿仍然有时间，G1 会逐步疏散这部分可选区域。

前两个集合会在一次初始收集过程中完成，而可选集合则会在剩余时间内逐步处理。这种方式既保证了空间回收的进度，又提高了停顿时间控制的成功率，同时降低了可选集合管理带来的额外开销。

当收集集合候选区域不再有可用区域时，空间回收阶段结束。

更多关于 G1 使用多少老年代区域以及如何避免较长 mixed 收集停顿的信息，请参见《Garbage-First 垃圾收集器调优》。

周期性垃圾回收（Periodic Garbage Collections）

如果由于应用程序处于空闲状态而长时间没有发生垃圾回收，虚拟机可能会长时间持有大量未使用的内存，而这些内存本可以被其他用途使用。为了避免这种情况，G1 可以通过 -XX:G1PeriodicGCInterval 参数强制定期执行垃圾回收。

该参数用于指定 G1 进行垃圾回收的最小时间间隔（单位为毫秒）。如果自上一次垃圾回收停顿以来已经超过该时间，且当前没有并发回收周期正在进行，则 G1 会触发额外的垃圾回收，其可能行为如下：

在仅年轻代阶段（Young-Only phase）期间： G1 会通过一次 Concurrent Start 停顿启动并发标记（concurrent marking）；如果指定了 -XX:-G1PeriodicGCInvokesConcurrent，则会触发一次 Full GC。
在空间回收阶段（Space Reclamation phase）期间： G1 会继续空间回收阶段，并触发与当前进度相匹配的垃圾回收停顿类型。

-XX:G1PeriodicGCSystemLoadThreshold 参数可以用于进一步限制是否触发周期性垃圾回收：如果 JVM 所在系统（例如容器）通过 getloadavg() 返回的一分钟平均系统负载高于该阈值，则不会执行周期性垃圾回收。

更多关于周期性垃圾回收的信息，请参见JEP 346：《Promptly Return Unused Committed Memory from G1》。

确定初始堆占用率（Determining Initiating Heap Occupancy）

初始堆占用率百分比（Initiating Heap Occupancy Percent，IHOP）是触发一次 Concurrent Start 收集的阈值，它被定义为老年代大小的一个百分比。

G1 默认会通过观察标记（marking）所花费的时间，以及在标记周期中老年代通常的内存分配情况，自动计算一个最优的 IHOP。这一特性称为 自适应 IHOP（Adaptive IHOP）。如果该功能处于启用状态，那么 -XX:InitiatingHeapOccupancyPercent 选项仅在系统还没有足够观测数据以准确预测 IHOP 阈值时，作为初始值使用，其含义是当前老年代大小的一个百分比。可以通过 -XX:-G1UseAdaptiveIHOP 关闭这一行为。在这种情况下，-XX:InitiatingHeapOccupancyPercent 的值将始终决定该触发阈值。

在内部实现中，自适应 IHOP 的目标是将“初始堆占用率”设置为：当老年代占用达到一个值时，空间回收阶段的第一次 mixed 垃圾回收刚好开始。这个目标值通常等于当前最大老年代容量减去 -XX:G1HeapReservePercent 所预留的额外缓冲空间。

标记（Marking）

G1 的标记使用一种称为 “起始快照（Snapshot-At-The-Beginning，SATB）” 的算法。它会在初始标记（Initial Mark）停顿时对堆创建一个虚拟快照，在标记开始时处于存活状态的所有对象，在整个标记过程中都被认为是存活的。这意味着，在标记过程中变为死亡（不可达）的对象，在空间回收时仍然会被当作存活对象处理（某些情况除外）。与其他收集器相比，这可能会导致一些额外的内存被“错误保留”。然而，SATB 可以在一定程度上提供更好的延迟表现，尤其是在 Remark 停顿期间。那些在标记期间被过于保守地认为存活的对象，会在下一次标记过程中被回收。

关于标记相关问题的更多信息，请参见《Garbage-First 垃圾收集器调优》。

极度紧张堆空间情况下的行为（Behavior in Very Tight Heap Situations）

当应用程序长期保持大量对象存活，以至于疏散（evacuation）无法找到足够空间进行对象复制时，就会发生 疏散失败（Evacuation Failure）。疏散失败意味着 G1 会尝试完成当前垃圾收集：已经成功移动的对象保持在新位置，而尚未移动的对象不会再被复制，只是对对象之间的引用进行调整。疏散失败可能会带来一定额外开销，但通常其速度仍接近一次普通的年轻代收集。在发生该失败的垃圾收集完成后，G1 会正常恢复应用程序执行，而不会立即采取其他措施。G1 会假设疏散失败发生在垃圾收集接近尾声时，即大部分对象已经被移动，并且剩余空间足够支撑应用继续运行，直到标记完成并进入空间回收阶段。

如果这一假设不成立，那么 G1 最终会触发一次 Full GC。这种收集会对整个堆进行原地压缩，可能非常缓慢。

关于分配失败或 Full GC 早于 OOM 发生的问题，请参见《Garbage-First 垃圾收集器调优》。

巨型对象（Humongous Objects）

巨型对象是指大小大于或等于一个 Region（区域）一半的对象。当前 Region 的大小会根据 G1 的“自动调优默认值（Ergonomic Defaults for G1 GC）”来确定，除非通过 -XX:G1HeapRegionSize 参数显式设置。

这些巨型对象在某些情况下会被特殊处理：

分配方式 每个巨型对象都会被分配到老年代中一段连续的 Region 序列中。对象本身的起始位置总是位于该序列中第一个 Region 的开头。该序列中最后一个 Region 可能存在剩余空间，但这部分空间在整个对象被回收之前无法用于其他分配。
回收方式 通常情况下，巨型对象只能在标记结束后的 Cleanup 停顿中被回收，或者在 Full GC 中如果它们已不可达时被回收。但对于某些特殊情况（例如 primitive 类型数组，如 bool、各种整数类型以及浮点数数组），G1 有一个特殊优化：在任何垃圾回收停顿中，如果这些巨型对象没有被大量对象引用，G1 会尝试主动回收它们。该行为默认开启，可以通过 -XX:G1EagerReclaimHumongousObjects 关闭。
分配对 GC 的影响 巨型对象的分配可能会导致垃圾回收提前发生。G1 在每次巨型对象分配时都会检查 IHOP（Initiating Heap Occupancy）阈值，如果当前堆占用超过该阈值，则可能立即触发一次 Initial Mark young collection。
移动行为（非常重要） 巨型对象只有在极端情况下才会被移动：当第一次 Full GC 仍无法为巨型对象分配足够的连续空间时，G1 会在同一次停顿中触发第二次 Full GC 进行“最后手段”的回收尝试。这个过程非常慢。由于包含巨型对象尾部的 Region 可能存在不可用空间，即使经过这些处理，仍然可能导致 JVM 因为内存不足而退出（OutOfMemoryError）。

G1 GC 的自适应默认值（Ergonomic Defaults for G1 GC）

本主题概述了 G1 中最重要的一些默认配置及其默认取值。这些默认值在不使用任何额外参数的情况下，提供了对 G1 行为和资源使用情况的基本预期。

选项与默认值	说明
`-XX:MaxGCPauseMillis=200`	最大停顿时间目标。
`-XX:GCPauseTimeInterval=<ergo>`	最大停顿时间间隔目标。默认情况下 G1 不设置该目标，允许在极端情况下连续执行垃圾回收（back-to-back）。
`-XX:ParallelGCThreads=<ergo>`	垃圾回收停顿期间用于并行工作的最大线程数。该值由 JVM 运行所在机器的可用线程数推导而来：如果可用 CPU 线程数小于等于 8，则直接使用该值；否则使用“超过 8 的线程数的五分之八”加上 8 作为最终线程数。在每次停顿开始时，该线程数还会受到最大堆大小限制：G1 不会为每 `-XX:HeapSizePerGCThread` 大小的 Java 堆容量分配超过一个线程。
`-XX:ConcGCThreads=<ergo>`	并发标记阶段使用的最大线程数。默认值为 `-XX:ParallelGCThreads / 4`。
`-XX:+G1UseAdaptiveIHOP` `-XX:InitiatingHeapOccupancyPercent=45`	控制初始堆占用率（IHOP）的默认设置：启用自适应 IHOP；在最初几个收集周期中，G1 会使用老年代 45% 的占用率作为标记起始阈值。
`-XX:G1HeapRegionSize=<ergo>`	堆区域（Region）的大小。默认值基于最大堆大小计算，目标是生成约 2048 个区域，最大值经过调优不超过 32 MB。用户指定值必须是 2 的幂，合法范围为 1 MB 到 512 MB。
`-XX:G1NewSizePercent=5` `-XX:G1MaxNewSizePercent=60`	年轻代大小的范围，占当前 Java 堆的百分比，在这两个值之间动态变化。
`-XX:G1HeapWastePercent=5`	收集集合候选区域中允许未回收空间的比例（百分比）。当候选区域中的可回收空间低于该值时，G1 会停止空间回收阶段。
`-XX:G1MixedGCCountTarget=8`	空间回收阶段的期望长度，以垃圾收集次数（collections）为单位。
`-XX:G1MixedGCLiveThresholdPercent=85`	老年代区域中存活对象比例超过该百分比的区域，不会在本次空间回收阶段被收集。

📝 备注

<ergo> 表示该实际取值是根据运行环境通过“自适应调优（ergonomics）”自动决定的。

与其他收集器的比较（Comparison to Other Collectors）

这是 G1 与其他垃圾收集器之间主要差异的总结：

**Parallel GC（并行收集器）**只能在一次整体操作中压缩并回收老年代空间。相比之下，G1 将这项工作分摊到多次更短的收集过程中逐步完成。这显著缩短了停顿时间，但可能会以吞吐量下降为代价。
G1 会在并发过程中执行部分老年代空间回收工作。
由于其并发特性，G1 可能比上述收集器具有更高的开销，从而影响整体吞吐量。
ZGC 的目标是提供更小的停顿时间，但代价是进一步降低吞吐量。

由于其工作方式，G1 具有一些机制来提升垃圾回收效率：

G1 可以在任意一次垃圾回收中回收老年代中一些完全空的大区域。这可以避免许多不必要的垃圾回收，在较低开销下释放大量空间。
G1 可以选择性地在 Java 堆中并发去重重复字符串。

回收老年代中完全空的大对象（humongous objects）的机制始终是启用的。可以通过 -XX:-G1EagerReclaimHumongousObjects 禁用该功能。

字符串去重默认是关闭的，可以通过 -XX:+UseStringDeduplication 启用。

Java 八股

Sun, 19 Apr 2026 23:00:00 +1200

Java 后端开发八股

基础语法

基本类型

8 种基本类型，分为四类

类型类别	数据类型	占用字节	默认值	说明
整数	byte	1	0	最小整数类型
整数	short	2	0	短整型
整数	int	4	0	常用整数类型
整数	long	8	0L	长整数类型
浮点	float	4	0.0f	单精度浮点
浮点	double	8	0.0d	双精度浮点（默认）
字符	char	2	‘\u0000’	Unicode 字符
布尔	boolean	1（JVM 依实现）	false	逻辑值 true/false

Object 类有哪些方法？

共 1 1 个，去掉重载一共有 9 种方法

方法	返回类型	作用
getClass()	Class	获取运行时类信息
hashCode()	int	返回对象哈希值
equals(Object obj)	boolean	判断对象是否相等
toString()	String	返回对象字符串表示
clone()	Object	克隆对象（需实现 Cloneable）
finalize()	void	GC 回收前调用（已过时）
wait()	void	线程等待（需在同步块中）
wait(long timeout)	void	带超时等待
wait(long timeout, int nanos)	void	更精细等待
notify()	void	唤醒一个等待线程
notifyAll()	void	唤醒所有等待线程

`String s = new String("hello");`会创建几个对象?

1 个或 2 个对象

分情况讨论:

常量池没有 “hello”：创建 2 个对象：常量池 “hello” 和堆中 new String(“hello”)
常量池已有 “hello”：创建 1 个对象：堆中 new String(“hello”)

创建对象实例的方式有几种？

4 种

方式	示例	说明
1. new 关键字	User u = new User();	最常用，直接调用构造方法
2. 反射机制	User u = (User) Class.forName(“User”).newInstance();	运行时创建对象
3. Clone 克隆	User u2 = (User) u1.clone();	通过对象复制创建（浅拷贝）
4. 反序列化	User u = (User) ObjectInputStream.readObject();	从文件/网络恢复对象

为什么 equals() 和 hashcode() 要同时重写？

JDK 规范中，如果两个对象 equals() 返回 true（逻辑相等），那么它们的 hashCode 必须相同；反之不成立，因为可能发生哈希冲突。

在 HashSet / HashMap 中，hashCode 决定“存放位置”，equals 决定“是否重复”，如果只重写一个，会导致逻辑不一致，出现重复数据或查找失败。

== 和 equals() 的区别

== 比较的是引用地址（或基本类型值），equals() 在 Object 类中默认比较地址，但在包装类中可以重写为比较内容，因此一般用于对象逻辑相等判断。

抽象类和接口的区别

对比项	抽象类（abstract class）	接口（interface）
是否可以实例化	❌ 不可以	❌ 不可以
方法	可以有抽象方法 + 具体方法	抽象方法 + default/static 方法（JDK8+）
变量	可以有普通成员变量	只能是常量（public static final）
构造方法	✔ 有	❌ 没有
继承方式	单继承	多实现
访问修饰符	可以任意	方法默认 public

为什么在 Java 8 之后接口中可以有 default/static 方法呢？

Java 8 之后接口引入 default 和 static 方法，是为了在不破坏已有实现类的情况下扩展接口能力，同时支持函数式编程和工具方法集中管理。default 方法属于给实现类用的或重写的“默认行为”，static 方法属于属于接口本身的工具方法。

类是什么？

类（Class）是面向对象编程（OOP）中用来描述对象的结构和行为的基本构造单元。

接口是什么？

接口（Interface）是面向对象编程（OOP）中用于定义行为规范的一种抽象机制。

抽象类是什么？

抽象类（Abstract Class）是面向对象编程（OOP）中用于描述“部分抽象对象”的一种类类型。

谈谈你对面向对象的理解

与面向过程相比，面向对象是一种以“对象”为中心来组织软件设计的编程思想，将数据与行为封装在一起，通过封装、继承和多态来模拟现实世界，从而降低系统复杂度并提升可扩展性。

OOP 的核心是什么？

一切皆“对象”

现实世界 → 抽象 → 对象 → 程序模型 ==> 人、车、订单、商品 → 都可以抽象成对象

OOP 三大核心特性

封装（Encapsulation）：把数据和行为封装在一起，对外隐藏内部实现
继承（Inheritance）：子类复用父类的属性和方法，实现代码复用
多态（Polymorphism）：同一行为，不同实现，子类可以重写父类方法

StringBuilder 和 StringBuffer 的区别

StringBuffer 线程安全（方法使用 synchronized 修饰），StringBuilder 非线程安全

Error 和 Exception 的区别

Error 是 JVM 层面的严重错误，通常表示系统级问题，程序一般无法处理；Exception 是程序运行过程中可能出现的异常情况，程序可以捕获并处理。

Exception 又分为：

受检异常（Checked Exception）：编译期必须处理（try-catch 或 throws），否则无法通过编译
运行时异常（RuntimeException）：编译期不强制处理，运行时抛出，通常由程序逻辑错误引起，但也可以捕获处理

graph TD
 A[Throwable] --> B[Error]
 A --> C[Exception]

 B --> B1[OutOfMemoryError]
 B --> B2[StackOverflowError]
 B --> B3[NoClassDefFoundError]

 C --> D[Checked Exception]
 C --> E[RuntimeException]

 D --> D1[IOException]
 D --> D2[SQLException]
 D --> D3[FileNotFoundException]

 E --> E1[NullPointerException]
 E --> E2[ArrayIndexOutOfBoundsException]
 E --> E3[ClassCastException]
 E --> E4[ArithmeticException]

对象的组成

由三大部分组成，对象头（Object Header），实例数据（Instance Data），对齐填充（Padding）

对象头

Mark Word （8 个字节）
Klass Pointer （ 8 个字节，如果开启了指针压缩（默认）是 4 个字节）
数组长度（length，如果是数组对象）

实例数据

class User { int id; // 4 字节 long age; // 8 字节 Object obj; // 4 字节（引用） }

对齐填充

保证对象总大小是 8 字节的整数倍，因为 JVM 内存分配是按 8 字节对齐的

在 64 位 JVM（开启指针压缩）下，User 对象包含

12 字节对象头（Mark Word + Klass Pointer）
16 字节实例数据（long 8B + int 4B + obj 引用 4B，JVM 会重排对齐）
对齐填充 4 字节

最终大小为 32 字节。

反射的原理

在运行时通过 Class 元信息 + 方法表 + 常量池解析，动态调用方法或访问字段的一套机制。

多线程

进程和线程的区别

对比维度	进程	线程
定义	程序的一次执行实例，是资源分配的基本单位	进程中的执行单元，是 CPU 调度的基本单位
资源	拥有独立的内存空间和系统资源	共享所属进程的内存和资源
调度	由操作系统进行调度	由 CPU 进行调度
开销	创建和切换开销大	创建和切换开销小
独立性	进程之间相互独立	线程之间共享资源
稳定性	一个进程崩溃一般不影响其他进程	一个线程崩溃可能导致整个进程崩溃
通信方式	进程间通信（IPC），较复杂	线程间可直接共享内存，通信简单

线程的分类

用户线程（User Thread）由用户程序创建和管理，JVM 主要执行的线程
守护线程（Daemon Thread）为用户线程提供服务的后台线程，如 GC 线程

线程的创建方式

继承 Thread 类，重写 run() 方法
实现 Runnable 接口，重写 run() 方法
实现 Callable 接口 + FutureTask，重写 call() 方法（可返回结果）
通过线程池创建线程（ExecutorService）

线程的生命周期

通过java.lang.Thread.State枚举定义的

新建 -> 可运行：调用 Thread 对象的 start()方法。
可运行 -> 运行：被系统选中，获取 CPU 执行权。
运行 -> 阻塞：请求获取无法马上获取的资源。
运行 -> 等待：调用 Object 类的 wait()方法。
运行 -> 超时等待：调用 Thread.sleep(long)或 Object.wait(long)方法，或者期待 join(long)的结束，或者锁定某个对象的 LockSupport.parkNanos()或 LockSupport.parkUntil()方法。
运行 -> 终止：线程终止。

`start()`和`run()`方法有什么区别

start() 是启动一个新线程，JVM 会为该线程分配独立的执行栈并调用 run() 方法
run() 只是普通方法调用，不会创建线程，直接在当前线程中执行。

多线程安全问题和产生原因

存在多个线程同时操作共享资源
对共享资源的操作不是原子的
线程执行由于 CPU 调度具有不确定性

解决方案：加锁（synchronized / Lock）保证同一时刻只有一个线程访问临界区

Synchronized 的底层原理

称呼层面

隐式锁：由 JVM 自动加锁与释放，无需手动控制
悲观锁：默认认为会发生竞争，访问前先加锁
非公平锁：不保证先来先得，线程获取锁具有随机性
可重入锁：同一线程可以重复获取同一把锁

状态层面

无锁（001）: 对象初始状态，没有线程竞争
偏向锁（101）：无竞争时偏向第一个线程，减少 CAS 开销（在 JDK 16 被彻底移除）
轻量级锁（00）：有少量竞争，通过 CAS 自旋获取锁
重量级锁（10）：竞争激烈时升级为 Monitor 阻塞队列

语法层面

作用于代码块（编译后）

monitorenter：进入同步块获取 Monitor

monitorexit：退出同步块释放 Monitor

作用于方法（编译后）

方法的方法表中有 flags: ACC_SYNCHRONIZED

JVM 层面

synchronized 底层依赖 Mark Word 与 Monitor 实现
对象头的 Mark Word 中存储锁状态标志

倒数 2 位：锁标志位（lock flag）

第 3 位：偏向锁标志位（biased_lock）

在多线程竞争下，锁会发生升级（锁膨胀）以优化性能

先尝试偏向锁 (MarkWord 标记线程 ID)

有竞争时升级为轻量级锁(CAS+自旋+线程栈中 Lock Record)

多线程竞争时升级为重量级锁(ObjectMonitor（操作系统互斥量），线程进入阻塞状态（BLOCKED）)

ThreadLocalMap 的底层原理

对象的四种引用方式

强引用：永不回收
软引用：内存不够才回收
弱引用：发现即回收
虚引用：不影响对象生命周期，用于回收通知

ThreadLocalMap 结构

Entry: key → WeakReference value → 强引用

ThreadLocal 的 key 为什么是弱引用

如果 key 是强引用，Thread → ThreadLocalMap → Entry → ThreadLocal，即使 tl = null，ThreadLocal 仍然被 Map 强引用， 永远无法回收 → 内存泄漏
用弱引用之后 WeakReference(ThreadLocal)，下一次 GC：key → null， ThreadLocal 对象可以被回收。

ThreadLocal 的 value 为什么是强引用

ThreadLocal 的 value 使用强引用，是因为它存储的是线程实际使用的数据，必须在使用期间保持稳定，不能被 GC 随意回收。
因此设计上采用 key 使用弱引用避免 ThreadLocal 泄漏，而 value 使用强引用保证数据的正确性，并通过惰性清理机制处理 key 为 null 时的内存泄漏问题。

ThreadLocal 的设计本质是一种基于 GC 约束的工程权衡。它通过弱引用 key 来解决 ThreadLocal 被 ThreadLocalMap 强引用导致的无意识内存泄漏问题，使 ThreadLocal 对象在外部失去引用后可以正常被 GC 回收。但 value 仍然使用强引用，以保证线程在执行期间数据的稳定性，避免业务数据被 GC 意外回收。这种设计的副作用是 key 被回收后 value 仍然残留在线程中，因此 ThreadLocal 将清理责任部分转移给开发者，通过在合适时机显式调用 remove() 来避免 value 泄漏。

Java 集合框架

Java 集合主要分为三大类接口体系：

Collection（单列集合）：用于存储 单个元素的集合
- List（有序、可重复）：ArrayList，LinkedList
- Set（无序、不可重复）：HashSet，LinkedHashSet
- Queue（先进先出）：PriorityQueue
Map（双列集合）：用于存储键值对（key-value）结构。
- HashMap
- LinkedHashMap

ArrayList 扩容机制和底层原理

ArrayList 底层基于 Object[] 动态数组实现，默认是空数组。
第一次添加元素时才初始化容量，一般会变为 10。
当数组容量不足时（即 size 超过当前数组长度），会触发扩容机制，扩容规则是原容量的 1.5 倍。扩容过程包括创建一个更大的新数组，将旧数组中的元素通过数组拷贝方式（System.arraycopy）复制到新数组中，最后用新数组替换旧数组引用。
由于底层是数组结构，所以 ArrayList 查询效率较高，但插入和删除需要移动元素，性能较低，同时扩容时会有额外的拷贝开销。

ArrayList 和 LinkedList 的区别

ArrayList 底层是基于动态数组实现的，支持通过下标快速访问元素，因此查询效率为 O(1)，但在插入和删除时需要移动元素，效率较低。
LinkedList 底层是双向链表结构，查询需要从头遍历，因此效率为 O(n)，但在插入和删除时只需要修改节点指针，因此效率较高。
同时 ArrayList 内存占用较小，而 LinkedList 因为每个节点需要保存前后指针，内存开销更大。总体来说 ArrayList 适合查询多的场景，LinkedList 适合插入删除多的场景。

ArrayList 线程不安全体现和解决方案

ArrayList 线程不安全的原因在于其 add 操作中的 size++ 不是原子操作，多线程同时修改会导致数据丢失或覆盖，同时扩容过程中也可能发生并发冲突。
此外，在遍历过程中如果发生结构修改，还会触发 fail-fast 机制，抛出 ConcurrentModificationException。解决方案包括使用 Vector（方法级加锁，性能较差）、Collections.synchronizedList（对 ArrayList 进行同步包装，但迭代需手动加锁），以及 CopyOnWriteArrayList（写时复制，读不加锁，适合读多写少场景，是推荐方案）。
ArrayList 有自己的内部迭代器实现（ListIterator），属于 fail-fast 机制。在使用普通迭代器（Iterator）遍历集合时，如果对集合结构进行修改（如 add 或 remove），会导致 modCount 和 expectedModCount 不一致，从而触发 ConcurrentModificationException。

CopyOnWriteArrayList 底层实现和原理

CopyOnWriteArrayList 底层只有一个核心字段：volatile Object[] array
核心思想: 写时复制（Copy On Write）,读：直接用旧数组（不加锁）, 写：复制新数组，在新数组上修改，再替换引用。
写操作加锁，在 JDK 6 以前用的 ReentrantLock，JDK 7 及以后改为 synchronized，写操作很简单，不需要 ReentrantLock 的复杂能力，synchronized 已经优化得很好了，性能已经不差 ReentrantLock。

HashMap 底层原理和实现

HashMap 的底层结构是 数组 + 链表 + 红黑树

扩容机制

HashMap 的扩容本质就是 数组扩容 + 重新分布（rehash）。
默认初始容量是 16，负载因子是 0.75，当元素数量超过 容量 × 负载因子 时就会触发扩容。扩容后容量变为原来的 2 倍，然后把原来所有元素重新计算位置（Java 8 之后做了优化，不是完全重新 hash，而是根据原 index + oldCap 判断去留，减少计算成本）。

两个参数

初始容量（capacity）：默认 16，决定桶数组大小

📝 备注

HashMap 的初始容量默认是 16，但如果初始化时传入的不是 2 的幂，底层会通过 tableSizeFor() 方法调整为大于等于该值的最小 2 的幂。这样做的目的是为了让 (n - 1) & hash 的位运算更高效且分布更均匀。
负载因子（load factor）：默认 0.75，决定扩容阈值

📝 备注

0.75 是在空间利用率和查询/插入性能之间的经验折中值。负载因子越大，HashMap 扩容越晚，桶内冲突概率越高（链表或红黑树变长），从而可能降低 get() 和 put() 的性能；但同时可以减少扩容次数，降低 rehash 的开销。

扩容阈值 = capacity × loadFactor

两个算法

计算元素脚标的算法：数组长度 -1 与 hashcode 值做与运算 (index) = (n - 1) & hash
计算 hash 值的算法：Key 的 hashcode 值无符号右移十六位做异或运算 hash = h ^ (h >>> 16)

成员方法

put()：插入 key-value
get()：根据 key 查 value
remove()：删除元素
resize()：扩容方法
hash()：计算 key 的 hash 值（扰动函数，减少冲突）

HashMap 和 HashTable 的区别

HashMap 是线程不安全的，多线程环境下同时 put 可能导致数据覆盖、死循环（早期扩容链表反转问题）。 Hashtable 是线程安全的，它的方法基本都加了 synchronized 锁，但代价是性能较低。现在一般不推荐使用 Hashtable，多线程场景通常用 ConcurrentHashMap。
HashMap 允许一个 null key 和多个 null value，因为它对 null key 做了特殊处理，不走 hash 计算，而是固定放在 0 号桶。 Hashtable 不允许任何 null key 或 null value，因为它在调用 hash 方法时直接做了 null 检查，避免空指针异常。

HashMap 中 put 方法的执行流程

对 key 进行 hash 计算
根据 hash 定位数组下标
如果该位置为空 → 直接插入
如果不为空 → 发生冲突：
- key 相同 → 直接覆盖 value
- key 不同 → 挂到链表后面
链表长度 ≥ 8 且数组长度 ≥ 64 → 转红黑树
插入完成后判断是否需要扩容

HashMap 线程不安全的体现和解决方案

体现

并发 put 导致数据覆盖

两个线程同时操作同一个桶

扩容时结构可能异常（JDK7 更严重）

多线程 resize 可能导致链表形成环（死循环）

size 统计不准确

多线程同时修改 size 导致计数错误

解决方案

使用 ConcurrentHashMap（推荐）

JDK8：CAS + synchronized（锁粒度更细）
高并发性能好

使用 Collections.synchronizedMap()

给整个 Map 加一把大锁
简单但性能差

ConcurrentHashMap 底层实现和原理

put() 桶空 CAS + 桶非空 Synchronized
JDK 7 分段锁（segment），JDK 8 锁链表头节点 + 红黑树树根节点

ConcurrentHashMap 是如何保证线程安全的？

JDK 7：底层通过 Segment，继承自 ReentrantLock，初始化时有 16 个 Segment，每个 Segment 内部维护 HashEntry 数组（初始容量一般为 2），整体并不是只能存 32 个元素，而是每个 Segment 都可以扩容并存储大量元素，16 个 Segment 只是默认并发度配置。并发控制通过对 Segment 加锁实现，但锁的粒度较大（Segment 级别），在高并发下容易产生竞争，从而影响性能。
JDK 8：底层采用数组+链表+红黑树结构，通过 CAS + Synchronized 保证线程安全。空桶情况下使用 CAS 进行无锁插入，发生哈希冲突时对桶进行加锁，锁的对象是链表的头节点或红黑树对应的 TreeBin 节点，锁粒度从 Segment 级别细化为桶级别，从而提升并发性能。

ConcurrentHashMap 是为何不允许键值为 null？

无法区分“key 不存在”和“value 为 null”：

在 ConcurrentHashMap 中，get(key) 返回 null 在语义上是模糊的，它既可能表示 key 不存在，也可能表示 key 存在但 value 为 null。在单线程结构里可以通过额外判断来区分，但在并发环境下，这种状态可能在不同线程之间瞬间变化，导致判断结果不可靠，从而引发语义混乱。
并发操作下 null 无法保证一致性

ConcurrentHashMap 的 put、remove、resize 都是并发执行的，如果允许 value 为 null，那么一个线程写入 null 的过程中，另一个线程可能同时读取或修改该桶状态，导致无法判断当前看到的 null 是“真实值”、“未完成写入”还是“被删除后的状态”，从而破坏并发读写的一致性语义。
简化底层实现（CAS + volatile + 红黑树结构）

ConcurrentHashMap 的核心机制依赖 CAS、volatile 和桶级锁来实现高并发，如果允许 null，会导致 CAS 无法区分“空桶”和“值为 null”的状态，volatile 读到 null 时也无法判断语义，红黑树与链表结构中还需要额外处理 null 节点情况，因此设计上直接禁止 null，从而简化并发控制逻辑并避免边界复杂性。

JVM

User.java →（编译）→ User.class → 类加载子系统(加载,验证,准备,解析,初始化) → 运行时数据区子系统(程序计数器，方法区，Java 堆，虚拟机栈，本地方法栈) ← 执行引擎子系统（方法启动执行和垃圾回收）

类加载器子系统

负责把 .class 文件加载进 JVM。

流程包括：

加载（Loading）：读取 class 文件，生成 Class 对象
验证（Verification）：检查字节码是否合法、安全
准备（Preparation）：为 static 变量分配内存并赋默认值
解析（Resolution）：符号引用转为直接引用
初始化（Initialization）：执行 <clinit>，初始化 static 变量

双亲委派

流程

当一个类加载器收到类加载请求时，不会自己先加载，而是先委托给父加载器处理，逐层向上递归，直到启动类加载器（Bootstrap ClassLoader）。如果父加载器无法完成加载，子加载器才会尝试自己加载该类。

好处

避免类的重复加载 同一个类不会被不同类加载器重复加载，保证 JVM 中 Class 的唯一性（同一个类在不同加载器下会被认为是不同类）。
保证核心类安全性 防止用户自定义类覆盖 Java 核心类，例如 java.lang.String，因为核心类优先由 Bootstrap ClassLoader 加载。
保证类加载的层次结构稳定 加载顺序具有严格的父子关系，结构清晰，避免混乱的类依赖加载问题。

为什么 tomcat 和 jdbc 打破了双亲委派？

tomcat:

Tomcat 是 Web 容器，一个核心需求是：不同 Web 应用之间必须隔离，且允许同名类版本不同，如果遵循双亲委派会导致所有类都会先交给父加载器（AppClassLoader / ExtClassLoader），所有应用共享同一份类 -> 无法隔离版本
Tomcat 的解决方案：自定义类加载器 + “反向委派”, Tomcat 设计了 WebAppClassLoader：加载顺序变成先自己找 → 找不到再委派父类
目的: 实现 Web 应用隔离（不同 war 包互不影响）,支持同名类不同版本共存, 避免全局污染（尤其是 lib 冲突）。

jdbc:

JDBC 的核心问题是：接口在 JDK 中，但实现类在第三方驱动中。如果严格双亲委派：DriverManager 在 Bootstrap ClassLoader，MySQL Driver 在 AppClassLoader，Bootstrap 不认识 AppClassLoader 加载的类。
解决方式：SPI（服务发现机制），JDBC 使用：ServiceLoader + Thread Context ClassLoader, DriverManager 在启动时不会自己加载具体 Driver, 而是通过：Thread.currentThread().getContextClassLoader()去加载第三方驱动。
本质：JDBC 并不是直接破坏双亲委派，而是绕过默认委派路径，改用线程上下文类加载器主动加载 SPI 实现类，从而实现“接口在上层，实现在下层”的解耦结构。

运行时数据区（Runtime Data Area）

JVM 的内存结构，用来存放运行时数据：

堆（Heap）：存对象实例（new 出来的东西）
方法区（Method Area / MetaSpace）：类信息、常量池、static 变量
虚拟机栈（Stack）：方法调用栈帧（局部变量、方法调用）
程序计数器（PC Register）：记录当前线程执行到哪一行
本地方法栈（Native Stack）：JNI 调用

执行引擎子系统（Execution Engine）

负责真正“执行代码”。

包含：

解释器（Interpreter）：逐行解释执行 bytecode
JIT 编译器（Just-In-Time Compiler）：热点代码编译成本地机器码
GC（垃圾回收器）：回收堆内存对象

如何判断一个对象为垃圾对象？

没有任何“GC Roots”可达的对象，就是垃圾对象。
GC Roots 常见来源：
- 虚拟机栈中的局部变量引用（方法里的对象）
- 方法区中的静态变量（static）
- 方法区中的常量
- JNI（Native 方法）引用
- 正在运行的线程对象

内存泄漏和内存溢出有什么区别？

内存泄漏：对象不再使用，但仍然被引用，GC 回收不了，导致内存占用越来越高，最终可能导致 OOM。
- static 集合一直存对象
- ThreadLocal 没 remove
- 缓存无限增长
内存溢出（OutOfMemoryError）：JVM 申请不到更多内存了
- 内存泄漏积累
- 加载超大对象

垃圾回收算法有哪些？

标记清除：标记所有可达对象，清除未标记对象。
- 优点：简单
- 缺点：1. 内存碎片严重 2.清理效率不稳定
标记复制（新生代常用 s0 s1）：内存分两块，一边用，一边空，存活对象复制到另一块。
- 优点：没有碎片，分配快
- 缺点：内存浪费一半
标记整理（老年代常用）：标记存活对象, 向一端移动，清理边界外内存。
- 优点：没有碎片，利用率高。
- 缺点：移动对象成本高
分代收集

垃圾回收器有哪些？

串行垃圾回收器：
- Serial 新生代 + Serial Old 老年代
并行垃圾回收器:
- Parallel Scavenge 新生代 + Parallel Old 老年代（JDK 8 默认）
并发垃圾回收器:
- ParNew 新生代 + CMS 老年代
- G1 （JDK 9 之后默认）
- ZGC

G1 特点和实现：

堆被划分为多个 Region
不再严格分代
优先回收垃圾最多的区域
可预测停顿时间（比如 -XX:MaxGCPauseMillis）

卡表和记忆集，三色标记法，SATB（Snapshot At The Beginning 解决漏标问题）

ZGC 特点和实现：

GC 停顿时间：通常 < 10ms
大部分工作都放到与用户线程并发执行，只有极少阶段需要 STW
支持 TB 级堆内存

内存多重映射，染色指针技术，读屏障

JVM 常用参数

-Xmx1024M 最大堆内存 -Xms1024M 初始化堆内存,正常和最大堆内存相同,减少动态改变的内存损 -Xmn384M 年轻代内存
-XX:+PrintGCDetails 打印 gc 信息,可参考 gc 的比例进行调优 -XX:+UseConcMarkSweepGC 老年代使用 cms,标记-清除算法会产生碎片 -XX:+UseParNewGC 年轻代使用并行收集器 -XX:SurvivorRatio=6

JVM 调优

哪些情况会导致 Full GC

晋升失败（Survivor 区对象无法进入老年代）
大对象直接进入老年代（Eden 无法容纳）
空间分配担保失败（Minor GC 前老年代预估空间不足）

项目中哪些情况会导致 OOM

静态对象未释放，比如 ThreadLocal 未调用 remove
资源未关闭：数据库连接、网络连接、文件流未使用 try-with-resources
一次性加载大量数据：如一次查出百万数据到 List，或大文件全部加载到内存
堆内存设置过小：-Xmx 配置不合理，无法支撑运行负载
线程池或线程使用不合理：无限制创建线程或队列无界，导致线程数暴涨

Java Web

过滤器(Filter)和拦截器(Interceptor)的区别

执行时机

Filter 是 Servlet 规范提供的，作用于 Servlet 容器层面，在DispatcherServlet执行前就会执行

Interceptor 是 Spring 框架提供的，作用于 Spring MVC 层，在HandlerMapping匹配之后，Controller 执行前调用

实现方式

Filter 实现javax.servlet.Filter接口，依赖web.xml或注解进行注册

Interceptor 实现HandlerInterceptor接口，通过实现WebMvcConfigurer的addInterceptors()方法注册

总结：过滤器是 Servlet 规范定义的，依赖 Web 容器（如 Tomcat），在请求进入 Servlet 之前和响应发出之后工作，更底层; 拦截器是 Spring MVC 框架提供的，在请求进入 Controller 之前和视图渲染之后工作，更贴近业务

常用框架

谈谈你对 Spring 的理解

广义上

Spring 指的是 Spring 全家桶生态（Spring Ecosystem），不仅仅是一个框架，而是一整套企业级开发解决方案。

Spring Framework（核心基础）
Spring Boot（快速开发、自动配置）
Spring MVC（Web 框架）
Spring Data（数据访问统一封装）
Spring Cloud（微服务治理）
Spring Security（安全认证授权）

狭义上

Spring 指的是 Spring Framework 核心容器，主要解决的是对象如何创建、如何管理、如何协作的问题。

IoC（控制反转）：对象的创建和管理交给 Spring 容器，通过 DI（依赖注入） 完成对象装配，解耦对象之间的依赖关系。
AOP（面向切面编程）：在不修改业务代码的情况下增强功能，如日志、事务、权限、监控，解耦横切逻辑。
Bean 生命周期管理：Bean 的创建 → 初始化 → 使用 → 销毁，统一由容器管理。
事件机制 & 扩展机制：支持事件发布监听模式（ApplicationEvent），提供强扩展能力（BeanPostProcessor）

谈谈你对 AOP 的理解

AOP（面向切面编程）是一种在不修改业务代码的情况下，对日志、事务、权限等横切逻辑进行统一增强的编程思想，本质是通过切面和切点定义增强范围，并借助动态代理将增强逻辑织入目标方法中，实现解耦与复用。

JDK 动态代理

基于 Java 反射机制实现，要求目标类必须实现接口。通过 InvocationHandler 对方法调用进行拦截，在方法执行前后织入增强逻辑。

CGLib 动态代理

基于继承实现代理，通过生成目标类的子类实现方法拦截，使用 MethodInterceptor 进行增强处理。

Spring AOP 默认优先使用 JDK 动态代理，只有在没有接口时才使用 CGLIB。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41


package com.evorsio;

import java.lang.reflect.Proxy;

/**
 * @author Evorsio
 * @since 2026/4/18
 */
public class JdkProxy {
 public interface Student {
 void study();
 }
 public static class Zhangsan implements Student {
 @Override
 public void study() {
 System.out.println("张三正在学习");
 }
 }
 public static void main(String[] args) {
 Zhangsan zhangsan = new Zhangsan();
 ClassLoader classLoader = zhangsan.getClass()
 .getClassLoader();
 Class<?>[] interfaces = zhangsan.getClass()
 .getInterfaces();

 Student proxy = (Student) Proxy.newProxyInstance(
 classLoader,
 interfaces,
 (p, method, args1) -> {
 System.out.println("准备开始学习");

 Object result = method.invoke(zhangsan, args1);

 System.out.println("学习完成");
 return result;
 }
 );

 proxy.study();
 }
}

控制台输出

1
2
3
4
5
6


C:\Users\Admin\.jdks\ms-17.0.18\bin\java.exe "-javaagent:D:\JetBrains\IntelliJ IDEA\lib\idea_rt.jar=60217" -Dfile.encoding=UTF-8 -classpath D:\JetBrainsProjects\IdeaProjects\java-demo\target\classes com.evorsio.JdkProxy
准备开始学习
张三正在学习
学习完成

Process finished with exit code 0

谈谈你对 IoC（控制反转）的理解

IoC（控制反转）是一种设计思想，将对象的创建和依赖关系的控制权交给容器管理，在 Spring 中通过依赖注入(DI)实现，从而实现对象之间的解耦和统一管理。

依赖注入方式

字段注入：（@AutowiredSpring 提供的按类型注入，@ResourceJDK 提供的按名称优先注入。）
构造器注入：（推荐）
Setter 方法注入

循环依赖问题和解决办法

1
2
3
4
5
6
7
8
9


class A {
 @Autowired
 private B b;
}

class B {
 @Autowired
 private A a;
}

三个缓存

Spring 通过三级缓存机制解决单例 Bean 的循环依赖：

一级缓存（singletonObjects = new ConcurrentHashMap(256)）：已初始化完成的 Bean
二级缓存（earlySingletonObjects = new ConcurrentHashMap(16)）：提前暴露的半成品 Bean 引用（可能是原始对象或代理对象）
三级缓存（singletonFactories = new HashMap(16)）：用于生成早期 Bean 的工厂对象（支持 AOP 代理提前暴露）

流程

Spring 创建 A 时，先从一级缓存 singletonObjects 获取 A，未命中，则标记 A 为“正在创建”，进入创建流程。
A 实例化（构造方法执行）后，Spring 不会直接暴露对象，而是将 ObjectFactory(A) 放入三级缓存 singletonFactories，用于后续生成 A 的早期引用。
A 执行 populateBean 进行属性填充时，发现依赖 B，触发 getBean(B)，开始创建 B。
B 创建流程与 A 一致：实例化后将 ObjectFactory(B) 放入三级缓存，并开始属性填充。
B 在 populateBean 时发现依赖 A，此时触发获取 A：

一级缓存无
二级缓存无
三级缓存存在 A 的 ObjectFactory Spring 调用 getObject() 得到 A 的早期引用（可能是代理对象），并放入二级缓存 earlySingletonObjects。

B 完成初始化后进入一级缓存；A 随后完成属性填充与初始化，最终进入一级缓存，同时清理二级、三级缓存中的 A，循环依赖解决完成。

四个方法

getBean() -> doGetBean() -> getSingleton() 从缓存中获取 Bean 对象。
createBean() -> doGetBean() -> createBeanInstance() 创建 Bean 对象。
populateBean()初始化 Bean 对象
addSingleton() 将 Bean 对象保存到缓存中

如果需要循环依赖，可以手动开启 spring.main.allow-circular-references=true，

默认在 Spring Boot 2.6 之后是关闭的

Spring 常用注解

IoC 相关注解: @Component @Autowired @Configuration @Bean @Value
AOP 相关注解: @Transactional @Aspect @Before @After @AfterReturning @AfterThrowing @Around @Pointcut

Spring Bean 的作用域有哪些？

singleton（单例，默认）
prototype（原型）：每次获取都会创建一个新对象，不由容器统一管理完整生命周期。
request（Web 环境）：每个 HTTP 请求创建一个 Bean，请求结束后销毁。
session（Web 环境）：每个 HTTP Session 创建一个 Bean，Session 结束后销毁。
application：整个 Web 应用生命周期内只有一个 Bean，类似 ServletContext 级别。
websocket：每个 WebSocket 会话对应一个 Bean。

Spring Bean 的生命周期有哪些？

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38


package com.evorsio.springdemo;

/**
 * @author Evorsio
 * @since 2026/4/18
 */
public class User {
 private String username;

 @Override
 public String toString() {
 return "userA: 使用userA对象: User{" +
 "username='" + username + '\'' +
 '}';
 }

 public void setUsername(String username) {
 System.out.println("userA: 调用setter方法,对username属性进行赋值");
 this.username = username;
 }

 public User() {
 System.out.println("userA: 调用无参构造");
 }

 public User(String username) {
 System.out.println("userA: 调用有参构造");
 this.username = username;
 }

 public void init(){
 System.out.println("userA: 调用初始化方法,对userA对象进行初始化");
 }

 public void destroy(){
 System.out.println("userA: 调用销毁方法");
 }
}

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23


package com.evorsio.springdemo;

import org.jspecify.annotations.Nullable;
import org.springframework.beans.BeansException;
import org.springframework.beans.factory.config.BeanPostProcessor;

/**
 * @author Evorsio
 * @since 2026/4/18
 */
public class MyBeanPostProcessor implements BeanPostProcessor {
 @Override
 public @Nullable Object postProcessBeforeInitialization(Object bean, String beanName) throws BeansException {
 System.out.println("myBeanPostProcessor: 对" + beanName+"对象初始化前执行的操作");
 return BeanPostProcessor.super.postProcessBeforeInitialization(bean, beanName);
 }

 @Override
 public @Nullable Object postProcessAfterInitialization(Object bean, String beanName) throws BeansException {
 System.out.println("myBeanPostProcessor: 对" + beanName+"对象初始化后执行的操作");
 return BeanPostProcessor.super.postProcessAfterInitialization(bean, beanName);
 }
}

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd">

 <bean id="userA" class="com.evorsio.springdemo.User" init-method="init" destroy-method="destroy">
 <property name="username" value="zhangsan"/>
 </bean>

 <bean id="myBeanPostProcessor" class="com.evorsio.springdemo.MyBeanPostProcessor"/>
</beans>

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


package com.evorsio.springdemo;

import org.springframework.context.support.ClassPathXmlApplicationContext;

public class SpringDemoApplication {
 public static void main(String[] args) {

 ClassPathXmlApplicationContext context = new ClassPathXmlApplicationContext("spring.xml");
 User userA = context.getBean("userA", User.class);
 System.out.println(userA);
 context.close();
 }
}

流程

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


C:\Users\Admin\.jdks\ms-17.0.18\bin\java.exe ...
com.evorsio.springdemo.SpringDemoApplication
1. userA: 调用无参构造
2. userA: 调用setter方法,对username属性进行赋值
3. myBeanPostProcessor: 对userA对象初始化前执行的操作
4. userA: 调用初始化方法,对userA对象进行初始化
5. myBeanPostProcessor: 对userA对象初始化后执行的操作
6. userA: 使用userA对象: User{username='zhangsan'}
7. userA: 调用销毁方法

Process finished with exit code 0

Spring Cloud

项目中使用了哪些 Spring Cloud 组件？

Nacos 注册中心 + 配置中心
OpenFeign 声明式远程调用
Spring Cloud Gateway 全局网关
Sentinel 限流熔断降级
LoadBalancer 负载均衡
Sleuth 链路追踪( Spring Boot 3 中被移除，改用 Micrometer Tracing + OpenTelemtry ) + Zipkin 进行链路可视化。

Open Feign 和 Feign 的区别

Feign 是 Netflix 早期的声明式 HTTP 客户端，不支持 Spring MVC 注解，不再维护。
OpenFeign 是 Spring Cloud 对 Feign 的增强版本，深度集成了 Spring 生态，支持 Spring MVC 注解、服务发现、负载均衡和熔断机制，是目前微服务中主流的远程调用方式，社区依然活跃。

实际开发过程中 OpenFeign 请求头丢失的问题

消费方通过 OpenFeign 调用生产方接口时，Feign 底层会重新发起一个新的 HTTP 请求，而不是在原请求基础上进行转发，原始请求中的 Header（如 Token、用户信息、TraceId 等）不会自动携带到新的 Feign 请求中，导致请求头信息丢失或不一致。

Spring 中的请求上下文是通过 RequestContextHolder（基于 ThreadLocal）存储的，在 Feign 调用过程中不会自动传播，因此需要通过 RequestInterceptor 手动从 RequestContextHolder 获取原始请求 Header 并进行透传。

基本用法：

导入依赖: spring-cloud-starter-alibaba-nacos-discovery
配置 Nacos 地址: spring.cloud.nacos.discovery.server-addr = localhost:8848

1
2
3
4
5


@EnableFeignClients
@SpringBootApplication
public class OrderApplication {
 //...
}

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


@FeignClient(
 value = "stock-nacos",
 fallback = StockFeignFallback.class
)
public interface StockFeignClient {

 @GetMapping("/stock/reduce")
 String reduceStock();
}

@Component
public class StockFeignFallback implements StockFeignClient {

 @Override
 public String reduceStock() {
 return "库存服务降级，当前不可用";
 }
}

项目中哪些场景使用到了 Spring Cloud Gateway 的功能？

项目中将网关作为一个独立的功能进行部署，基于路径断言将请求通过负载均衡的方式进行分发。
全局的跨域问题处理（由于浏览器的同源策略导致），使用 spring.cloud.gateway.globalcors.cors-configurations.[/**].allowed-origins=*
通过实现网关的全局过滤进行身份验证
配置限流

组成：

Route（路由）: 定义请求转发规则
Predicate（断言）: 判断请求是否匹配（路径、Header、参数）
Filter（过滤器）: 请求前后处理逻辑（鉴权、日志、限流）

有了 Nginx 为什么还需要网关呢？

Nginx 主要负责：反向代理，静态资源托管，负载均衡，SSL/TLS 等，只管“流量怎么走”，不关心“业务是什么”。
Spring Cloud Gateway 负责：统一 API 入口，路由转发，JWT 鉴权 / 登录校验等，关注“业务请求如何被处理”，服务于微服务。

请求过来之后如何进行流量控制？

客户端削峰填谷：前端限流（按钮置灰），请求缓存

网关层限流：RequestRateLimiter

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


spring:
 cloud:
 gateway:
 routes:
 - id: order-service
 uri: lb://order-service
 predicates:
 - Path=/order/**

 filters:
 # =========================
 # 限流 RequestRateLimiter
 # =========================
 - name: RequestRateLimiter
 args:
 redis-rate-limiter.replenishRate: 10 # 每秒放入令牌数（QPS）
 redis-rate-limiter.burstCapacity: 20 # 最大突发流量
 key-resolver: "#{@ipKeyResolver}"

应用层限流： Sentinel（限制 QPS 或者线程数）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


@SentinelResource(
 value = "getOrder",
 blockHandler = "blockHandlerMethod",
 fallback = "fallbackMethod"
)
public String getOrder(Long id) {
 return "正常业务逻辑";
}

public String blockHandlerMethod(Long id, BlockException ex) {
 return "请求过多，请稍后重试";
}
public String fallbackMethod(Long id) {
 return "系统异常，已降级处理";
}

服务熔断与降级：Open Feign 熔断降级

Nacos 作为服务注册和配置中心的原理

启动参数

-Dnacos.standalone=true

服务注册

客户端（服务提供者）启动后：

向 Nacos Server 发送注册请求
请求内容包含：serviceName、ip、port、metadata
数据通过 HTTP REST 接口发送
Server 使用 request 对象接收参数

注册完成后：

服务实例被存入 Nacos 内存注册表

服务健康检测

Nacos Server 会定时执行健康检查任务：

检查所有注册实例的心跳时间
判断实例是否存活

判断规则：

当前时间 - 最后心跳时间 > 15 秒 → 标记为不健康
当前时间 - 最后心跳时间 > 30 秒 → 从注册表移除实例

服务心跳任务（Client）

客户端在服务注册后会启动心跳任务：

每 5 秒发送一次心跳请求
请求接口：beat（REST）
通过定时 + 延迟任务实现
作用：告诉 Server 当前服务仍然存活

客户端服务发现

服务消费者（Nacos Client）调用服务时：

向 Nacos Server 发送 REST 请求
获取服务实例列表
将结果缓存到本地（serviceInfoMap）

同时：

在本地启动定时任务
周期性拉取服务端最新注册表
更新本地缓存

Nacos 1.x 和 2.x 的区别

1.x 基于 HTTP + 定时任务（心跳、轮询）；2.x 引入 gRPC 长连接 + 事件驱动模型，支持服务变更实时推送。

除了 Nacos 还有那些注册中心

Eureka（Netflix）：AP（高可用），去中心化设计（Peer-to-Peer，无主节点，节点对等，数据通过复制实现同步）。
Zookeeper（Apache）：CP（强一致），Leader 选举机制（集群选举主节点负责协调，保证一致性）。
Nacos：AP/CP 可切换，默认 AP；同时支持注册中心 + 配置中心，采用临时实例（心跳）+ 长轮询/推送机制实现服务发现。

MySQL

如何进行 SQL 优化

慢查询定位：开启慢查询日志定位慢 SQL，通常 0.5 秒（默认 10 秒）开始，但应该根据业务类型和性能要求调整。
explain 指令查看执行计划：
- id: SQL 执行的顺序与层级, id 相同：从上到下执行, id 不同：数字大的先执行（子查询）。
- type: 查询类型一旦为 ALL（全表扫描）则必须优化，合理取值 ref（普通索引查询）,eq_ref（唯一索引 join）,range（范围查询）,index（对整个索引进行扫描）。
- key：真正使用到的索引
- key_len：索引使用的长度
- rows：为了获取结果所需要扫描的行数
- extra：主要用于分析分组和排序操作，using index（使用覆盖索引，不需要回表查询数据行，性能好），using where（where 的条件没有用到索引），using filesort（使用磁盘排序），using index condition（使用索引下推优化，在存储引擎层提前过滤数据，减少回表次数）。

可以通过 key 和 key_len 判断是否命中了索引以及索引是否被完整使用，从而发现索引是否失效；通过 type 判断 SQL 的访问方式和扫描类型，评估是否存在全表扫描或全索引扫描等优化空间；再结合 extra 字段判断执行细节，例如 Using index 表示覆盖索引无需回表，Using where 表示条件可能未充分利用索引，Using filesort 表示排序或分组未走索引需要优化，整体通过这些字段综合判断 SQL 是否需要优化以及优化方向。

合理创建索引

表数据量达到一定规模（ 15 万以上），才具备明显优化意义
考虑性价比更高的复合索引设计
尽量让查询走覆盖索引以减少回表
需要重点关注索引失效的场景：
- 未遵循最左匹配原则
- 模糊查询中 % 在左边
- 对索引字段使用函数或发生类型转换
- 范围查询导致右边索引失效
- 以及 is not null 等导致扫描范围过大的情况
在关联查询中，应尽量选择小表作为驱动表，并为关联字段创建索引以提升 join 查询效率。
编写 SQL 语句时避免使用 select *，防止全表扫描或多余回表查询。
表关联查询优先使用 inner join，避免不必要的 left/right join，如需使用也应以小表为驱动表。
排序字段尽量保持一致的排序规则（避免一列升序一列降序），以便索引生效。
建表时结合字段内容选择合适类型
- 数值：TINYINT：很小的整数（状态位、标志位），INT：常用整数（默认选择），BIGINT：大数据量 ID（如雪花 ID）
- 字符串：CHAR(n)：长度固定（如手机号、身份证），VARCHAR(n)：长度可变（最常用），TEXT：大文本（不建议频繁索引）
- 价格：不要用 FLOAT / DOUBLE（会有精度问题）推荐：DECIMAL(m,n)，m：总位数 n：小数位数
- 时间：用于时间记录（创建时间、更新时间等）DATE：日期（2026-04-19），DATETIME：日期+时间（推荐），TIMESTAMP：时间戳（带时区转换）

B-Tree 和 B+Tree 的区别

B-Tree：所有节点（非叶子 + 叶子）都存储数据，每个节点既存 key 也存 data。
B+Tree: 只有叶子节点存数据，非叶子节点只存索引（key）。

B+Tree 的优点

B+Tree 数据全部存储在叶子节点，非叶子节点只存索引，因此单个节点可以容纳更多的索引项，从而降低树的高度，减少磁盘 IO 次数，提升查询效率。
B+Tree 叶子节点之间通过双向指针相连，可以非常高效地进行范围查询和顺序遍历，可以直接在叶子层顺序向前或向后扫描，从而显著减少磁盘 IO，提高查询性能。同时双向结构还支持反向遍历，进一步增强查询灵活性。
B+Tree 查询路径固定，每次查询都必须从根节点一路访问到叶子节点，每一层只进行一次节点匹配，因此整体查询次数是稳定且可预测的。
B+Tree 通常在 3 层结构下就可以存储约 2000 万级别的数据。

📝 备注

InnoDB 一个页（page）默认大小：16KB = 16384 bytes

非叶子节点存只存索引 key（BIGINT = 8 bytes）和指针（通常 6-8 bytes）

每个节点能存多少“分支”：16384 / 16 ≈ 1000 个指针

三层 B+Tree 推导：1000 × 1000 × 16（一行 ≈ 1KB）≈ 2000 万

什么是回表

通过二级索引（非聚簇索引）找到主键后，还需要再回到主键索引（聚簇索引）中查询完整数据行的过程。

Select * 查询一定会回表吗？

不一定会回表，如果查询条件是主键索引（聚簇索引），例如 where id = ?，MySQL 会直接在聚簇索引中找到整行数据，因此不会发生回表；只有在使用二级索引查询且无法覆盖所有字段时，才会发生回表。

MySQL 深分页（超大分页）问题如何优化？

游标分页：
1 2 3 4

SELECT * FROM user WHERE id > last_id ORDER BY id LIMIT 10;
通过记录上一页最后一条数据的主键（如 last_id），作为下一页查询的起点，利用索引有序性进行范围查询。
延迟关联（子查询优化）

1
2
3
4


SELECT * FROM user u
JOIN (
 SELECT id FROM user ORDER BY id LIMIT 1000000, 10
) t ON u.id = t.id;

先通过子查询在索引中只查询主键（小结果集），再通过主键与原表关联回表获取完整数据，从而减少大范围扫描带来的性能损耗。

什么是索引下推，原理？

索引下推是 MySQL（InnoDB）的一种优化机制，核心思想是：在存储引擎层就先用索引过滤数据，减少回表次数。

1
2


SELECT * FROM user
WHERE name LIKE 'A%' AND age = 20;

先用索引（如 name）定位数据范围
在索引层同时判断 age = 20
只把满足条件的记录回表查询完整数据
减少无效回表次数，提高性能

InnoDB 和 MyISAM 的区别

对比项	InnoDB	MyISAM
事务	✔ 支持（ACID）	❌ 不支持
锁机制	行级锁	表级锁
外键	✔ 支持	❌ 不支持
崩溃恢复	✔ 支持（redo log）	❌ 不支持
索引结构	聚簇索引	非聚簇索引
查询性能	稍慢（但稳定）	快（读多场景）

数据库三大范式

第一范式（1NF）：字段必须是不可再分的原子值
第二范式（2NF）：每个非主键字段必须完全依赖主键
第三范式（3NF）：非主键字段之间不能传递依赖

事务特性（ACID）

A - Atomicity（原子性）：事务中的操作要么全部执行成功，要么全部失败回滚，通过 undo log 保证回滚能力。
C - Consistency（一致性）：事务执行前后，数据必须从一个合法状态转换到另一个合法状态，保证数据符合业务规则。
I - Isolation（隔离性）：多个事务并发执行时互不干扰，通过 锁机制（排他锁等） 和 MVCC 保证并发隔离。
D - Durability（持久性）：事务一旦提交，数据就会永久保存，即使系统崩溃也不会丢失，通过 redo log 保证。

事务隔离级别和解决的问题

读未提交（Read Uncommitted）：不解决任何并发问题，可能出现脏读、不可重复读、幻读。
读已提交（Read Committed）：（Oracle 默认）解决脏读，但仍可能出现不可重复读和幻读，适合银行业务对资金实时业务的要求。
可重复读（Repeatable Read）（MySQL 默认）：解决脏读和不可重复读，通过 MVCC + 间隙锁在一定程度上避免幻读，适合互联网电商业务“强一致读场景”。
串行化（Serializable）：完全解决脏读、不可重复读和幻读，通过强制事务串行执行实现最高隔离级别，但并发性能最差。

分布式事务

分布式事务是指跨多个服务或数据库的事务一致性问题，无法依赖本地事务实现，常见解决方案是基于最终一致性的方案，如消息队列和 Seata。

长事务问题

事务执行时间过长，持有锁或版本过久未释放的情况

占用数据库连接资源
锁持有时间长，导致阻塞和死锁概率增加
undo log / MVCC 版本堆积，影响性能
可能导致数据库性能整体下降

优化思路：

拆分大事务（拆成多个小事务）
避免事务中包含远程调用
减少锁持有时间
异步化处理非核心逻辑

MySQL 的 MVCC 会导致表膨胀吗？

MySQL 的 MVCC 通过 undo log 记录数据的历史版本，并结合 Read View 判断可见性，同时依赖 purge 线程在没有活跃事务引用旧版本时清理 undo log，从而避免历史版本无限增长导致的空间膨胀。

此外，对于删除操作，InnoDB 并不会立即物理删除数据，而是先做“标记删除”，旧版本仍通过 undo log 保留；当 purge 线程确认没有事务再引用该版本后，才会真正物理删除该记录，并将这块空间标记为可复用（供后续插入使用），从而避免空间浪费。

但如果存在长事务，会导致旧版本无法被清理，进而造成 undo log 堆积和空间占用增加。

MySQL 中的锁

锁性质

悲观锁：假设会发生冲突，先加锁再操作，通过数据库锁机制实现（如 SELECT ... FOR UPDATE），适用于写多、冲突概率高的场景。
乐观锁：假设不会冲突，提交时再检查，通常通过版本号（version）或 CAS 实现，适用于读多写少的场景。

锁粒度
- 表级锁：锁整张表，开销小，实现简单，但并发性能低，常见于 MyISAM 引擎。
- 行级锁：锁具体某一行数据，并发能力强，粒度最小，InnoDB 默认使用（提升并发性能）。
- 意向锁（InnoDB 特有）：是一种“表级的标记锁”，用于表示某个事务即将对某些行加锁，不直接锁数据，只是“声明意图”，避免表锁与行锁冲突，提高加锁效率。
  1. 意向共享锁（IS）：表示“事务准备在某些行上加共享锁”，读操作前会加。
  2. 意向排他锁（IX）：表示“事务准备在某些行上加排他锁”，写操作前会加。
锁类型
- 共享锁（S 锁）：读锁，多个事务可以同时持有，读读不冲突，但读写冲突。
- 排他锁（X 锁）：写锁，同一时间只能一个事务持有，写写、读写都会冲突。

如何进行数据库数据迁移？

迁移方案

停机一次性迁移：停止业务写入，进行全量数据导出（mysqldump / pg_dump），导入新库后切换应用连接，适用于小数据量或可接受停机的场景。
在线分批次迁移：采用“全量 + 增量”方式，先迁移历史数据，再通过 binlog/CDC（如 Canal）同步增量数据，最后灰度切换流量，适用于大规模或不能停机的系统。

迁移过程可能导致的问题

数据一致性问题：迁移期间仍有写入，导致新旧库数据不一致或延迟同步问题。
应用兼容性问题：新旧库表结构或 SQL 语法不一致，导致接口报错或查询异常。
性能抖动问题：全量导入或 binlog 同步造成数据库 IO 和网络压力上升，影响线上业务。
回滚困难问题：若未保留旧库或未做双写，切换后出现问题难以快速回退。

如何减少迁移过程对用户体验的影响

兼容性测试：在迁移前进行 SQL 兼容性、表结构、接口回归测试，确保新旧库在读写行为上一致。
采用“全量+增量“的同步方案：先进行历史数据全量迁移，再通过 binlog / CDC（如 Canal）同步增量数据，保证业务不中断。
设计灰度切换：通过按用户比例或业务模块逐步切换流量到新库，降低整体切换风险。
监控与回滚预案：全程监控延迟、错误率、数据一致性等指标，一旦异常可快速切回旧库，保证业务可恢复性。

一般会做全量迁移，再做增量同步，分阶段灰度切换流量，监控数据一致性和业务指标，遇到异常可快速回滚，尽量把对用户的影响降至最低。

业务每天新增 1000 万笔订单，某天需要导出应该如何做？

按条件分批导出：按 时间 / ID / 分片键 将数据拆分成多个区间分批查询导出，避免一次性全表扫描导致数据库压力过大。
分布式并行导出：将导出任务拆分为多个子任务，通过多线程或分布式任务执行（按 ID hash / 时间分片），提升导出效率。
异步任务执行：将导出操作放入后台任务系统（如 MQ / XXL-Job），避免阻塞请求线程，提升系统可用性。
分页批量拉取数据：采用 limit + 游标（last_id） 或按范围分页方式逐批查询数据，避免 OFFSET 深分页性能问题。
流式写文件：使用流式读取 + 流式写出（如 BufferedWriter / JDBC fetch size），边查询边写入文件，避免内存占用过高。
上传 S3 对象存储：导出完成后将文件上传到对象存储（如 S3 / OSS），提供下载链接，避免本地磁盘压力并支持高并发下载。

对于大订单导出，通常采用异步任务+分页批处理+流式写出+对象存储的组合，用户点击导出，只是在后端提交异步任务，后台消息队列异步消费，数据库分批拉取避免全表扫描，使用游标或 id 分页，分批流式写出文件，不放在内存中而是写到对象存储服务（OSS）中供用户下载。

导入具体步骤：

将业务数据预处理为 CSV / TSV 等标准格式文件，保证字段顺序与目标表结构一致。
通过 SCP / FTP / OSS 下载等方式，将数据文件传输到数据库所在机器本地磁盘，提高导入性能。

在导入前暂时禁用二级索引或约束，减少索引维护开销，提高导入速度。

1
2
3
4
5


ALTER TABLE orders DISABLE KEYS;

#导入完成后再恢复：

ALTER TABLE orders ENABLE KEYS;

使用 MySQL 高效导入命令进行快速加载：

1
2
3
4


LOAD DATA INFILE '/path/file.csv'
INTO TABLE orders
FIELDS TERMINATED BY ','
LINES TERMINATED BY '\n';

导入完成后重新创建索引（或恢复索引），并进行数据校验（行数对比 / checksum）确保数据一致性。

Redis

Redis 中的基本类型及应用场景

数据类型	底层数据结构	特点	常见应用场景	示例
String	SDS（简单动态字符串）	O(1) 访问、可扩展、支持二进制安全	缓存、计数器、分布式锁、Token	`SET user:1 "json"` / `INCR pv`
Hash	ziplist / hashtable（小对象 ziplist，大对象 hashtable）	适合存对象，节省内存	用户信息、订单对象	`HSET user:1 name Tom`
List	quicklist（ziplist + linkedlist（双向链表））	双端队列结构，支持阻塞	消息队列、最新列表	`LPUSH queue order1`
Set	hashtable（整数集合 intset / hashtable）	无序唯一、支持集合运算	去重、共同好友	`SADD tags java redis`
ZSet	skiplist（跳表） + hashtable	有序、支持范围查询和排序	排行榜、热度排序	`ZADD rank 100 user1`
BitMap	String（位操作，本质是 bit 数组）	极省内存，高效状态标记	签到、活跃用户统计	`SETBIT sign 1 1`
Pub/Sub	事件驱动（channel + dict 结构）	消息广播，实时通知	聊天室、系统通知	`PUBLISH msg "hi"`

跳表（SkipList）的说明

跳表（SkipList）是一种基于有序链表 + 多级索引的数据结构，通过“空间换时间”来实现类似二分查找的效率。

为什么不用红黑树？

红黑树：中序遍历较复杂，跳表：链表天然顺序结构，范围查询非常快。
不需要复杂旋转（红黑树需要旋转维护平衡），更容易维护和调试。
局部修改，不需要大范围结构调整。

Redis 是单线程为什么会快呢？

Redis 只是命令处理模型是单线程的，避免了锁竞争和线程切换开销，同时基于 I/O 多路复用（epoll）实现高并发连接处理，所有数据在内存中操作，并配合高度优化的数据结构，使得单线程也能实现极高吞吐；在 Redis 6 之后引入 I/O 多线程用于提升网络读写性能，但核心命令执行仍然是单线程。

谈谈你对 I/O 多路复用的理解

I/O 多路复用是一种通过一个线程监听多个 socket 的机制，利用 epoll 等系统调用在内核层管理连接状态，只处理就绪的 I/O 事件，从而避免线程阻塞和频繁创建线程的问题，提高系统并发能力。

I/O 多路复用实现的三种方式

select：最早的 I/O 多路复用实现，通过轮询所有 fd检查状态（fd 数量有限（默认 1024））。
- 轮询
- 有 fd（文件描述符）大小限制
poll：是 select 的改进版，去掉了 fd 数量限制，同样需要遍历所有 fd（仍然是 O(n) 轮询）。
- 仍是轮询
- 没有 fd 限制
epoll：事件驱动模型，注册 fd 到内核，等待事件发生，返回“就绪 fd 列表”。
- 事件驱动
- 高性能

操作系统用户态和内核态以及它们之间的切换

用户态：调用系统 API（间接操作文件、网络等），运行普通应用程序，权限较低，不能直接访问硬件。
内核态：操作系统内核运行状态，拥有最高权限，可以直接访问 CPU，内存，硬盘，网络设备等。

用户态和内核态切换

用户程序通过系统调用进入内核执行，再返回用户态的过程

flowchart TD
 A["用户程序调用 read()"] --> B[触发系统调用 syscall]
 B --> C[CPU 切换到内核态 Kernel Mode]
 C --> D[执行内核逻辑\n读取磁盘 / 网络 I/O]
 D --> E[内核准备返回数据]
 E --> F[CPU 切换回用户态 User Mode]
 F --> G[用户程序获得返回结果]

Redis

Redis 大 Key 解决方案

定期使用 redis-cli --bigkeys 命令进行扫描，快速定位可能的大 Key（注意：该命令为抽样统计，不保证全量精确）
对于 Big List 一般采用拆分策略，比如按 1000 个元素一组进行分片存储；如果只关心最新数据，可以结合 LTRIM 定期修剪，避免 List 无限增长导致阻塞操作（如 LRANGE / LLEN 变慢）
对于 Big Hash，同样需要拆分，可以根据字段名做 hash 取模，将数据分散到多个小 Hash 中；并且在所有代码中，避免对大 Hash 使用 HGETALL，应强制使用 HSCAN 进行增量遍历，避免一次性全量拉取导致阻塞 Redis 单线程

`SCAN` 命令

分批次增量遍历整个 Redis，每次只返回一小部分 key（避免 KEYS 命令造成阻塞）
基于游标（cursor）的遍历方式，非阻塞性操作，每次 SCAN 只消耗很短时间，不影响主线程正常执行其他命令
牺牲强一致性（可能出现重复或遗漏），换取高可用性与低阻塞性，适用于在线环境的渐进式遍历
通常需要配合 MATCH（模式匹配）和 COUNT（控制每次扫描数量）使用，以提高扫描效率
SCAN 不保证一次遍历完整数据集，必须循环直到 cursor 回到 0 才算完成一次完整遍历

Redis 内存淘汰策略

noeviction（默认）
- 不删除任何数据
- 内存满后写入直接报错（OOM）
- 适合：严格不能丢数据的场景
allkeys-lru
- 在所有 key 中，删除“最近最少使用”的 key
- 最常用的缓存策略（推荐）
volatile-lru
- 只在设置了 TTL 的 key 中做 LRU 淘汰
- 永不过期的 key 不参与
allkeys-lfu
- 在所有 key 中删除“访问频率最低”的 key
- 比 LRU 更智能（更适合热点数据）
volatile-lfu
- 只在带 TTL 的 key 中按访问频率淘汰
allkeys-random
- 随机删除 key（不看冷热）
volatile-random
- 在设置 TTL 的 key 中随机删除

Redis 过期删除策略

惰性删除（Lazy Deletion）
- 访问 key 时才检查是否过期
- 如果过期才删除
- 优点：不耗 CPU
- 缺点：过期 key 可能长期占内存
定期删除（Periodic Deletion）
- Redis 每隔一段时间随机抽查一批 key
- 删除其中已过期的 key
- 优点：平衡 CPU 和内存
- 缺点：不是全量扫描
定期 + 惰性混合

Redis 持久化策略

RDB（数据快照）
- 优点： 恢复速度快、对性能影响小、文件体积小。
- 缺点： 可能丢失最近一次快照之后的数据。
AOF（追加日志）
- 优点： 数据安全性高，最多只丢最后一小段写入数据。
- 缺点： 文件体积大，恢复速度较慢。
RDB + AOF（混合模式）
- 优点： 兼顾恢复速度快和数据安全性高。
- 缺点： 实现更复杂，占用资源略高。

Redis 集群模式

主从复制：一主多从结构，主负责写、从负责读，用于数据备份和读扩展，但不支持自动分片，主节点宕机需要手动处理或配合其他机制。
哨兵模式：在主从基础上增加监控和自动故障转移，主节点挂了可以自动选新主，但仍然是单主架构，容量扩展能力有限。
Cluster 集群模式：官方分布式方案，通过分片（slot）把数据分散到多个主节点，实现水平扩展和自动故障转移，是生产环境大规模使用的方案，但配置和使用复杂度更高。

在 Spring Boot 中配置 ShardingSphere 实现分库分表与读写分离

Sat, 18 Apr 2026 01:24:00 +1200

在 Spring Boot 中配置 ShardingSphere 实现分库分表与读写分离

随着业务数据量和访问压力的增长，单体数据库架构逐渐面临性能瓶颈与扩展性问题。为了应对这一挑战，常见的解决方案包括读写分离与分库分表：前者用于缓解读写压力不均，后者用于降低单表数据规模，提高整体查询与写入性能。

在实际开发中，如果直接在业务代码中实现路由逻辑，会显著增加系统复杂度。因此，通常会引入 ShardingSphere 这类数据库中间件，在不改动业务代码的前提下完成 SQL 路由与数据拆分。

本文将基于 Spring Boot，逐步实现 ShardingSphere 的读写分离与分库分表配置，并通过示例验证其运行效果。

先决条件

配置好 MySQL 主从，参考 MySQL 主从复制一文中配置 MySQL 主从复制，主机用来写，从机用来读。

数据库中有测试用表:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


create table users
(
 id bigint auto_increment comment '用户ID'
 primary key,
 email varchar(255) not null comment '用户邮箱',
 nickname varchar(50) not null comment '用户昵称',
 password_hash varchar(255) not null comment '用户密码',
 constraint uk_email
 unique (email)
)
 comment '用户表';

使用 MybatisPlus 3 操作数据库 (可以通过插件例如 MybatisX 一键生成 mapper 和 domain 等)

读写分离

在 Spring Boot 项目中的 application.yaml 中配置数据库驱动和 jdbc url

1
2
3
4


spring:
 datasource:
 driver-class-name: org.apache.shardingsphere.driver.ShardingSphereDriver
 url: jdbc:shardingsphere:classpath:sharding.yaml

在与 application.yaml 同目录下创建 sharding.yaml 文件写入如下:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34


dataSources:
 master:
 dataSourceClassName: com.zaxxer.hikari.HikariDataSource
 driverClassName: com.mysql.cj.jdbc.Driver
 jdbcUrl: jdbc:mysql://localhost:3306/db?useSSL=false&serverTimezone=UTC&allowPublicKeyRetrieval=true
 username: user
 password: pass

 slave:
 dataSourceClassName: com.zaxxer.hikari.HikariDataSource
 driverClassName: com.mysql.cj.jdbc.Driver
 jdbcUrl: jdbc:mysql://localhost:3307/db?useSSL=false&serverTimezone=UTC&allowPublicKeyRetrieval=true
 username: user
 password: pass

rules:
 - !SINGLE
 tables:
 - "*.*" # ← 加载所有库的所有表，不分片的表都走这里

 - !READWRITE_SPLITTING
 dataSourceGroups:
 readwrite_ds:
 writeDataSourceName: master
 readDataSourceNames:
 - slave
 transactionalReadQueryStrategy: PRIMARY
 loadBalancerName: random
 loadBalancers:
 random:
 type: RANDOM

props:
 sql-show: true

配置成功后启动 Spring Boot 项目检查无误后进行测试 Sharding jdbc 读写分离是否正常运行，创建 Spring Boot 测试类：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79


package com.example.demo;

import com.example.demo.domain.User;
import com.example.demo.mapper.UserMapper;
import lombok.extern.slf4j.Slf4j;
import org.apache.shardingsphere.infra.hint.HintManager;
import org.junit.jupiter.api.Test;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.test.context.SpringBootTest;
import org.springframework.transaction.annotation.Transactional;

import java.util.List;

/**
 * @author Evorsio
 * @since 2026/4/17
 */
@Slf4j
@SpringBootTest
public class ShardingTests {

 @Autowired
 private UserMapper userMapper;

 /**
 * 测试写操作 → 路由到 master
 */
 @Test
 void testInsert() {
 User user = new User();
 user.setEmail("test@example.com");
 user.setNickname("测试用户");
 user.setPasswordHash("123456");
 userMapper.insert(user);
 log.info("插入成功，id={}", user.getId());
 // 观察日志：Actual SQL: master ::: INSERT ...
 }

 /**
 * 测试读操作 → 路由到 slave
 */
 @Test
 void testSelect() {
 List<User> users = userMapper.selectList(null);
 log.info("查询到 {} 条记录", users.size());
 // 观察日志：Actual SQL: slave ::: SELECT ...
 }

 /**
 * 测试事务内读 → 走 master（避免主从延迟）
 */
 @Test
 @Transactional
 void testTransactionalRead() {
 User user = new User();
 user.setEmail("transaction@example.com");
 user.setNickname("事务用户");
 user.setPasswordHash("123456");
 userMapper.insert(user);

 // 事务内立即读 → 走 master，能读到刚写入的数据
 User result = userMapper.selectById(user.getId());
 log.info("事务内查询结果：{}", result);
 // 观察日志：Actual SQL: master ::: SELECT ...（不走 slave）
 }

 /**
 * 测试 HintManager 强制走 master
 */
 @Test
 void testForceMaster() {
 try (HintManager hintManager = HintManager.getInstance()) {
 hintManager.setWriteRouteOnly(); // 强制走主库
 List<User> users = userMapper.selectList(null);
 log.info("强制主库查询到 {} 条记录", users.size());
 // 观察日志：Actual SQL: master ::: SELECT ...
 }
 }
}

分别测试每个方法，正确输出如下:

testInsert()

1
2
3


2026-04-17T21:32:06.277+12:00 INFO 27064 --- [demo] [ main] ShardingSphere-SQL : Logic SQL: INSERT INTO users ( email, nickname, password_hash ) VALUES ( ?, ?, ? )
2026-04-17T21:32:06.277+12:00 INFO 27064 --- [demo] [ main] ShardingSphere-SQL : Actual SQL: master ::: INSERT INTO users ( email, nickname, password_hash ) VALUES ( ?, ?, ? ) ::: [test@example.com, 测试用户, 123456]
2026-04-17T21:32:06.330+12:00 INFO 27064 --- [demo] [ main] com.example.demo.ShardingTests : 插入成功，id=2

testSelect()

1
2
3


2026-04-17T21:34:34.371+12:00 INFO 27216 --- [demo] [ main] ShardingSphere-SQL : Logic SQL: SELECT id,email,nickname,password_hash FROM users
2026-04-17T21:34:34.371+12:00 INFO 27216 --- [demo] [ main] ShardingSphere-SQL : Actual SQL: slave ::: SELECT id,email,nickname,password_hash FROM users
2026-04-17T21:34:34.428+12:00 INFO 27216 --- [demo] [ main] com.example.demo.ShardingTests : 查询到 2 条记录

testTransactionalRead()

1
2
3
4
5


2026-04-17T21:35:06.995+12:00 INFO 4324 --- [demo] [ main] ShardingSphere-SQL : Logic SQL: INSERT INTO users ( email, nickname, password_hash ) VALUES ( ?, ?, ? )
2026-04-17T21:35:06.995+12:00 INFO 4324 --- [demo] [ main] ShardingSphere-SQL : Actual SQL: master ::: INSERT INTO users ( email, nickname, password_hash ) VALUES ( ?, ?, ? ) ::: [transaction@example.com, 事务用户, 123456]
2026-04-17T21:35:07.167+12:00 INFO 4324 --- [demo] [ main] ShardingSphere-SQL : Logic SQL: SELECT id,email,nickname,password_hash FROM users WHERE id=?
2026-04-17T21:35:07.168+12:00 INFO 4324 --- [demo] [ main] ShardingSphere-SQL : Actual SQL: master ::: SELECT id,email,nickname,password_hash FROM users WHERE id=? ::: [3]
2026-04-17T21:35:07.211+12:00 INFO 4324 --- [demo] [ main] com.example.demo.ShardingTests : 事务内查询结果：User(id=3, email=transaction@example.com, nickname=事务用户, passwordHash=123456)

testForceMaster()

1
2
3


2026-04-17T21:35:33.391+12:00 INFO 10264 --- [demo] [ main] ShardingSphere-SQL : Logic SQL: SELECT id,email,nickname,password_hash FROM users
2026-04-17T21:35:33.392+12:00 INFO 10264 --- [demo] [ main] ShardingSphere-SQL : Actual SQL: master ::: SELECT id,email,nickname,password_hash FROM users
2026-04-17T21:35:33.451+12:00 INFO 10264 --- [demo] [ main] com.example.demo.ShardingTests : 强制主库查询到 2 条记录

全部测试通过，读写分离配置完成

分库分表

首先配置 mysql 主从复制和测试用数据库

创建三个文件

master-init.sql

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66


-- ===== 建库授权 =====
CREATE DATABASE IF NOT EXISTS db_0;
CREATE DATABASE IF NOT EXISTS db_1;

GRANT ALL PRIVILEGES ON db.* TO 'user'@'%';
GRANT ALL PRIVILEGES ON db_0.* TO 'user'@'%';
GRANT ALL PRIVILEGES ON db_1.* TO 'user'@'%';

-- 创建主从复制专用账号
CREATE USER IF NOT EXISTS 'replicator'@'%' IDENTIFIED BY 'replicator123';
GRANT REPLICATION SLAVE ON *.* TO 'replicator'@'%';

FLUSH PRIVILEGES;

-- ===== db：非分片表 =====
USE db;

CREATE TABLE roles (
 id bigint PRIMARY KEY,
 type varchar(50) NOT NULL
);

CREATE TABLE user_profile (
 user_id bigint PRIMARY KEY,
 avatar varchar(255),
 bio varchar(500),
 gender tinyint DEFAULT 0,
 birthday date,
 location varchar(100)
);

CREATE TABLE user_role (
 user_id bigint NOT NULL,
 role_id bigint NOT NULL,
 PRIMARY KEY (user_id, role_id)
);

CREATE TABLE outbox (
 id bigint PRIMARY KEY,
 topic varchar(100) NOT NULL,
 payload text NOT NULL,
 sent tinyint DEFAULT 0 NOT NULL,
 created_at datetime NOT NULL
);

INSERT INTO roles (id, type) VALUES (1, 'admin'), (2, 'user');

-- ===== db_0：users 分片表 =====
USE db_0;
CREATE TABLE users_0 (
 id bigint PRIMARY KEY,
 email varchar(255) NOT NULL UNIQUE,
 nickname varchar(50) NOT NULL,
 password_hash varchar(255) NOT NULL
);
CREATE TABLE users_1 LIKE users_0;

-- ===== db_1：users 分片表 =====
USE db_1;
CREATE TABLE users_0 (
 id bigint PRIMARY KEY,
 email varchar(255) NOT NULL UNIQUE,
 nickname varchar(50) NOT NULL,
 password_hash varchar(255) NOT NULL
);
CREATE TABLE users_1 LIKE users_0;

slave-init.sh

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21


#!/bin/bash

echo "等待 master 就绪..."
until mysql -h mysql-master -P 3306 -u replicator -preplicator123 -e "SELECT 1" &>/dev/null; do
 echo "重试中..."
 sleep 3
done

mysql -uroot -p"$MYSQL_ROOT_PASSWORD" <<EOF
STOP REPLICA;
CHANGE REPLICATION SOURCE TO
 SOURCE_HOST='mysql-master',
 SOURCE_PORT=3306,
 SOURCE_USER='replicator',
 SOURCE_PASSWORD='replicator123',
 SOURCE_AUTO_POSITION=1,
 GET_SOURCE_PUBLIC_KEY=1;
START REPLICA;
EOF

echo "主从复制配置完成"

docker-compose.yaml

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44


services:
 mysql-master:
 image: mysql:8.0
 container_name: mysql-master
 environment:
 MYSQL_DATABASE: db
 MYSQL_USER: user
 MYSQL_PASSWORD: pass
 MYSQL_ROOT_PASSWORD: root
 command: >
 --server-id=1
 --log-bin=mysql-bin
 --binlog-format=ROW
 --gtid-mode=ON
 --enforce-gtid-consistency=ON
 --log-slave-updates=ON
 ports:
 - "3306:3306"
 volumes:
 - mysql_master_data:/var/lib/mysql
 - ./master-init.sql:/docker-entrypoint-initdb.d/init.sql # ← 新增

 mysql-slave:
 image: mysql:8.0
 container_name: mysql-slave
 restart: always
 ports:
 - "3307:3306"
 environment:
 MYSQL_ROOT_PASSWORD: root
 command: >
 --server-id=2
 --relay-log=mysql-relay-bin
 --gtid-mode=ON
 --enforce-gtid-consistency=ON
 --log-slave-updates=ON
 --read-only=ON
 volumes:
 - mysql_slave_data:/var/lib/mysql
 - ./slave-init.sh:/docker-entrypoint-initdb.d/init.sh # ← 新增

volumes:
 mysql_master_data:
 mysql_slave_data:

使用 docker compose up -d 启动，并进入 mysql-slave 从机中查看状态 docker exec -it mysql-slave mysql -uroot -proot，

1

show replica status\G;

输出:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67


mysql> show replica status\G;
*************************** 1. row ***************************
 Replica_IO_State: Waiting for source to send event
 Source_Host: mysql-master
 Source_User: replicator
 Source_Port: 3306
 Connect_Retry: 60
 Source_Log_File: mysql-bin.000003
 Read_Source_Log_Pos: 197
 Relay_Log_File: mysql-relay-bin.000005
 Relay_Log_Pos: 413
 Relay_Source_Log_File: mysql-bin.000003
 Replica_IO_Running: Yes
 Replica_SQL_Running: Yes
 Replicate_Do_DB:
 Replicate_Ignore_DB:
 Replicate_Do_Table:
 Replicate_Ignore_Table:
 Replicate_Wild_Do_Table:
 Replicate_Wild_Ignore_Table:
 Last_Errno: 0
 Last_Error:
 Skip_Counter: 0
 Exec_Source_Log_Pos: 197
 Relay_Log_Space: 3004361
 Until_Condition: None
 Until_Log_File:
 Until_Log_Pos: 0
 Source_SSL_Allowed: No
 Source_SSL_CA_File:
 Source_SSL_CA_Path:
 Source_SSL_Cert:
 Source_SSL_Cipher:
 Source_SSL_Key:
 Seconds_Behind_Source: 0
Source_SSL_Verify_Server_Cert: No
 Last_IO_Errno: 0
 Last_IO_Error:
 Last_SQL_Errno: 0
 Last_SQL_Error:
 Replicate_Ignore_Server_Ids:
 Source_Server_Id: 1
 Source_UUID: 3b2fadb5-3a53-11f1-999c-b2404a28de3c
 Source_Info_File: mysql.slave_master_info
 SQL_Delay: 0
 SQL_Remaining_Delay: NULL
 Replica_SQL_Running_State: Replica has read all relay log; waiting for more updates
 Source_Retry_Count: 86400
 Source_Bind:
 Last_IO_Error_Timestamp:
 Last_SQL_Error_Timestamp:
 Source_SSL_Crl:
 Source_SSL_Crlpath:
 Retrieved_Gtid_Set: 3b2fadb5-3a53-11f1-999c-b2404a28de3c:1-25
 Executed_Gtid_Set: 3b1bf78c-3a53-11f1-923f-e21ea55938fa:1-5,
3b2fadb5-3a53-11f1-999c-b2404a28de3c:1-25
 Auto_Position: 1
 Replicate_Rewrite_DB:
 Channel_Name:
 Source_TLS_Version:
 Source_public_key_path:
 Get_Source_public_key: 1
 Network_Namespace:
1 row in set (0.00 sec)

ERROR:
No query specified

状态正常，可以进行 sharding sphere 分库分表配置，修改 sharding.yaml,

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98


dataSources:
 master: # db 库（非分片表）
 dataSourceClassName: com.zaxxer.hikari.HikariDataSource
 driverClassName: com.mysql.cj.jdbc.Driver
 jdbcUrl: jdbc:mysql://localhost:3306/db?useSSL=false&serverTimezone=UTC&allowPublicKeyRetrieval=true
 username: user
 password: pass

 master_0: # db_0 库
 dataSourceClassName: com.zaxxer.hikari.HikariDataSource
 driverClassName: com.mysql.cj.jdbc.Driver
 jdbcUrl: jdbc:mysql://localhost:3306/db_0?useSSL=false&serverTimezone=UTC&allowPublicKeyRetrieval=true
 username: user
 password: pass

 master_1: # db_1 库
 dataSourceClassName: com.zaxxer.hikari.HikariDataSource
 driverClassName: com.mysql.cj.jdbc.Driver
 jdbcUrl: jdbc:mysql://localhost:3306/db_1?useSSL=false&serverTimezone=UTC&allowPublicKeyRetrieval=true
 username: user
 password: pass

 slave: # slave db 库
 dataSourceClassName: com.zaxxer.hikari.HikariDataSource
 driverClassName: com.mysql.cj.jdbc.Driver
 jdbcUrl: jdbc:mysql://localhost:3307/db?useSSL=false&serverTimezone=UTC&allowPublicKeyRetrieval=true
 username: user
 password: pass

 slave_0:
 dataSourceClassName: com.zaxxer.hikari.HikariDataSource
 driverClassName: com.mysql.cj.jdbc.Driver
 jdbcUrl: jdbc:mysql://localhost:3307/db_0?useSSL=false&serverTimezone=UTC&allowPublicKeyRetrieval=true
 username: user
 password: pass

 slave_1:
 dataSourceClassName: com.zaxxer.hikari.HikariDataSource
 driverClassName: com.mysql.cj.jdbc.Driver
 jdbcUrl: jdbc:mysql://localhost:3307/db_1?useSSL=false&serverTimezone=UTC&allowPublicKeyRetrieval=true
 username: user
 password: pass

rules:
 - !READWRITE_SPLITTING
 dataSourceGroups:
 rw_ds: # 非分片表用这个
 writeDataSourceName: master
 readDataSourceNames:
 - slave
 transactionalReadQueryStrategy: PRIMARY
 loadBalancerName: random
 rw_ds_0:
 writeDataSourceName: master_0
 readDataSourceNames:
 - slave_0
 transactionalReadQueryStrategy: PRIMARY
 loadBalancerName: random
 rw_ds_1:
 writeDataSourceName: master_1
 readDataSourceNames:
 - slave_1
 transactionalReadQueryStrategy: PRIMARY
 loadBalancerName: random
 loadBalancers:
 random:
 type: RANDOM

 - !SHARDING
 tables:
 users:
 actualDataNodes: rw_ds_${0..1}.users_${0..1}
 databaseStrategy:
 standard:
 shardingColumn: id
 shardingAlgorithmName: db_inline
 tableStrategy:
 standard:
 shardingColumn: id
 shardingAlgorithmName: tbl_inline

 shardingAlgorithms:
 db_inline:
 type: INLINE
 props:
 algorithm-expression: rw_ds_${id % 2}
 tbl_inline:
 type: INLINE
 props:
 algorithm-expression: users_${(id.intdiv(2)) % 2}

 - !SINGLE
 tables:
 - "*.*"
 defaultDataSource: rw_ds # 非分片表走 db 库

props:
 sql-show: true

配置完后运行测试，

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


 /**
 * 测试批量写操作 → 分库分表
 */
 @Test
 void testBatchInsertSharding() {
 for (int i = 0; i < 20; i++) {
 User user = new User();
 user.setId(i+1L);
 user.setEmail("user_" + i + "@test.com");
 user.setNickname("user" + i);
 user.setPasswordHash("pwd_" + i);

 userMapper.insert(user);
 }
 }

控制台输出：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40


2026-04-18T01:12:41.626+12:00 INFO 16080 --- [demo] [ main] ShardingSphere-SQL : Logic SQL: INSERT INTO users ( id, email, nickname, password_hash ) VALUES ( ?, ?, ?, ? )
2026-04-18T01:12:41.626+12:00 INFO 16080 --- [demo] [ main] ShardingSphere-SQL : Actual SQL: master_1 ::: INSERT INTO users_0 ( id, email, nickname, password_hash ) VALUES (?, ?, ?, ?) ::: [1, user_0@test.com, user0, pwd_0]
2026-04-18T01:12:41.653+12:00 INFO 16080 --- [demo] [ main] ShardingSphere-SQL : Logic SQL: INSERT INTO users ( id, email, nickname, password_hash ) VALUES ( ?, ?, ?, ? )
2026-04-18T01:12:41.653+12:00 INFO 16080 --- [demo] [ main] ShardingSphere-SQL : Actual SQL: master_0 ::: INSERT INTO users_1 ( id, email, nickname, password_hash ) VALUES (?, ?, ?, ?) ::: [2, user_1@test.com, user1, pwd_1]
2026-04-18T01:12:41.666+12:00 INFO 16080 --- [demo] [ main] ShardingSphere-SQL : Logic SQL: INSERT INTO users ( id, email, nickname, password_hash ) VALUES ( ?, ?, ?, ? )
2026-04-18T01:12:41.666+12:00 INFO 16080 --- [demo] [ main] ShardingSphere-SQL : Actual SQL: master_1 ::: INSERT INTO users_1 ( id, email, nickname, password_hash ) VALUES (?, ?, ?, ?) ::: [3, user_2@test.com, user2, pwd_2]
2026-04-18T01:12:41.676+12:00 INFO 16080 --- [demo] [ main] ShardingSphere-SQL : Logic SQL: INSERT INTO users ( id, email, nickname, password_hash ) VALUES ( ?, ?, ?, ? )
2026-04-18T01:12:41.676+12:00 INFO 16080 --- [demo] [ main] ShardingSphere-SQL : Actual SQL: master_0 ::: INSERT INTO users_0 ( id, email, nickname, password_hash ) VALUES (?, ?, ?, ?) ::: [4, user_3@test.com, user3, pwd_3]
2026-04-18T01:12:41.685+12:00 INFO 16080 --- [demo] [ main] ShardingSphere-SQL : Logic SQL: INSERT INTO users ( id, email, nickname, password_hash ) VALUES ( ?, ?, ?, ? )
2026-04-18T01:12:41.685+12:00 INFO 16080 --- [demo] [ main] ShardingSphere-SQL : Actual SQL: master_1 ::: INSERT INTO users_0 ( id, email, nickname, password_hash ) VALUES (?, ?, ?, ?) ::: [5, user_4@test.com, user4, pwd_4]
2026-04-18T01:12:41.692+12:00 INFO 16080 --- [demo] [ main] ShardingSphere-SQL : Logic SQL: INSERT INTO users ( id, email, nickname, password_hash ) VALUES ( ?, ?, ?, ? )
2026-04-18T01:12:41.692+12:00 INFO 16080 --- [demo] [ main] ShardingSphere-SQL : Actual SQL: master_0 ::: INSERT INTO users_1 ( id, email, nickname, password_hash ) VALUES (?, ?, ?, ?) ::: [6, user_5@test.com, user5, pwd_5]
2026-04-18T01:12:41.702+12:00 INFO 16080 --- [demo] [ main] ShardingSphere-SQL : Logic SQL: INSERT INTO users ( id, email, nickname, password_hash ) VALUES ( ?, ?, ?, ? )
2026-04-18T01:12:41.702+12:00 INFO 16080 --- [demo] [ main] ShardingSphere-SQL : Actual SQL: master_1 ::: INSERT INTO users_1 ( id, email, nickname, password_hash ) VALUES (?, ?, ?, ?) ::: [7, user_6@test.com, user6, pwd_6]
2026-04-18T01:12:41.709+12:00 INFO 16080 --- [demo] [ main] ShardingSphere-SQL : Logic SQL: INSERT INTO users ( id, email, nickname, password_hash ) VALUES ( ?, ?, ?, ? )
2026-04-18T01:12:41.709+12:00 INFO 16080 --- [demo] [ main] ShardingSphere-SQL : Actual SQL: master_0 ::: INSERT INTO users_0 ( id, email, nickname, password_hash ) VALUES (?, ?, ?, ?) ::: [8, user_7@test.com, user7, pwd_7]
2026-04-18T01:12:41.716+12:00 INFO 16080 --- [demo] [ main] ShardingSphere-SQL : Logic SQL: INSERT INTO users ( id, email, nickname, password_hash ) VALUES ( ?, ?, ?, ? )
2026-04-18T01:12:41.716+12:00 INFO 16080 --- [demo] [ main] ShardingSphere-SQL : Actual SQL: master_1 ::: INSERT INTO users_0 ( id, email, nickname, password_hash ) VALUES (?, ?, ?, ?) ::: [9, user_8@test.com, user8, pwd_8]
2026-04-18T01:12:41.724+12:00 INFO 16080 --- [demo] [ main] ShardingSphere-SQL : Logic SQL: INSERT INTO users ( id, email, nickname, password_hash ) VALUES ( ?, ?, ?, ? )
2026-04-18T01:12:41.724+12:00 INFO 16080 --- [demo] [ main] ShardingSphere-SQL : Actual SQL: master_0 ::: INSERT INTO users_1 ( id, email, nickname, password_hash ) VALUES (?, ?, ?, ?) ::: [10, user_9@test.com, user9, pwd_9]
2026-04-18T01:12:41.731+12:00 INFO 16080 --- [demo] [ main] ShardingSphere-SQL : Logic SQL: INSERT INTO users ( id, email, nickname, password_hash ) VALUES ( ?, ?, ?, ? )
2026-04-18T01:12:41.731+12:00 INFO 16080 --- [demo] [ main] ShardingSphere-SQL : Actual SQL: master_1 ::: INSERT INTO users_1 ( id, email, nickname, password_hash ) VALUES (?, ?, ?, ?) ::: [11, user_10@test.com, user10, pwd_10]
2026-04-18T01:12:41.739+12:00 INFO 16080 --- [demo] [ main] ShardingSphere-SQL : Logic SQL: INSERT INTO users ( id, email, nickname, password_hash ) VALUES ( ?, ?, ?, ? )
2026-04-18T01:12:41.740+12:00 INFO 16080 --- [demo] [ main] ShardingSphere-SQL : Actual SQL: master_0 ::: INSERT INTO users_0 ( id, email, nickname, password_hash ) VALUES (?, ?, ?, ?) ::: [12, user_11@test.com, user11, pwd_11]
2026-04-18T01:12:41.746+12:00 INFO 16080 --- [demo] [ main] ShardingSphere-SQL : Logic SQL: INSERT INTO users ( id, email, nickname, password_hash ) VALUES ( ?, ?, ?, ? )
2026-04-18T01:12:41.746+12:00 INFO 16080 --- [demo] [ main] ShardingSphere-SQL : Actual SQL: master_1 ::: INSERT INTO users_0 ( id, email, nickname, password_hash ) VALUES (?, ?, ?, ?) ::: [13, user_12@test.com, user12, pwd_12]
2026-04-18T01:12:41.751+12:00 INFO 16080 --- [demo] [ main] ShardingSphere-SQL : Logic SQL: INSERT INTO users ( id, email, nickname, password_hash ) VALUES ( ?, ?, ?, ? )
2026-04-18T01:12:41.752+12:00 INFO 16080 --- [demo] [ main] ShardingSphere-SQL : Actual SQL: master_0 ::: INSERT INTO users_1 ( id, email, nickname, password_hash ) VALUES (?, ?, ?, ?) ::: [14, user_13@test.com, user13, pwd_13]
2026-04-18T01:12:41.759+12:00 INFO 16080 --- [demo] [ main] ShardingSphere-SQL : Logic SQL: INSERT INTO users ( id, email, nickname, password_hash ) VALUES ( ?, ?, ?, ? )
2026-04-18T01:12:41.759+12:00 INFO 16080 --- [demo] [ main] ShardingSphere-SQL : Actual SQL: master_1 ::: INSERT INTO users_1 ( id, email, nickname, password_hash ) VALUES (?, ?, ?, ?) ::: [15, user_14@test.com, user14, pwd_14]
2026-04-18T01:12:41.766+12:00 INFO 16080 --- [demo] [ main] ShardingSphere-SQL : Logic SQL: INSERT INTO users ( id, email, nickname, password_hash ) VALUES ( ?, ?, ?, ? )
2026-04-18T01:12:41.766+12:00 INFO 16080 --- [demo] [ main] ShardingSphere-SQL : Actual SQL: master_0 ::: INSERT INTO users_0 ( id, email, nickname, password_hash ) VALUES (?, ?, ?, ?) ::: [16, user_15@test.com, user15, pwd_15]
2026-04-18T01:12:41.772+12:00 INFO 16080 --- [demo] [ main] ShardingSphere-SQL : Logic SQL: INSERT INTO users ( id, email, nickname, password_hash ) VALUES ( ?, ?, ?, ? )
2026-04-18T01:12:41.772+12:00 INFO 16080 --- [demo] [ main] ShardingSphere-SQL : Actual SQL: master_1 ::: INSERT INTO users_0 ( id, email, nickname, password_hash ) VALUES (?, ?, ?, ?) ::: [17, user_16@test.com, user16, pwd_16]
2026-04-18T01:12:41.777+12:00 INFO 16080 --- [demo] [ main] ShardingSphere-SQL : Logic SQL: INSERT INTO users ( id, email, nickname, password_hash ) VALUES ( ?, ?, ?, ? )
2026-04-18T01:12:41.777+12:00 INFO 16080 --- [demo] [ main] ShardingSphere-SQL : Actual SQL: master_0 ::: INSERT INTO users_1 ( id, email, nickname, password_hash ) VALUES (?, ?, ?, ?) ::: [18, user_17@test.com, user17, pwd_17]
2026-04-18T01:12:41.781+12:00 INFO 16080 --- [demo] [ main] ShardingSphere-SQL : Logic SQL: INSERT INTO users ( id, email, nickname, password_hash ) VALUES ( ?, ?, ?, ? )
2026-04-18T01:12:41.781+12:00 INFO 16080 --- [demo] [ main] ShardingSphere-SQL : Actual SQL: master_1 ::: INSERT INTO users_1 ( id, email, nickname, password_hash ) VALUES (?, ?, ?, ?) ::: [19, user_18@test.com, user18, pwd_18]
2026-04-18T01:12:41.785+12:00 INFO 16080 --- [demo] [ main] ShardingSphere-SQL : Logic SQL: INSERT INTO users ( id, email, nickname, password_hash ) VALUES ( ?, ?, ?, ? )
2026-04-18T01:12:41.786+12:00 INFO 16080 --- [demo] [ main] ShardingSphere-SQL : Actual SQL: master_0 ::: INSERT INTO users_0 ( id, email, nickname, password_hash ) VALUES (?, ?, ?, ?) ::: [20, user_19@test.com, user19, pwd_19]

20 条测试数据全部插入数据库成功，进入数据库查看

db_0.users_0

id	email	nickname	password
4	user_3@test.com	user3	pwd_3
8	user_7@test.com	user7	pwd_7
12	user_11@test.com	user11	pwd_11
16	user_15@test.com	user15	pwd_15
20	user_19@test.com	user19	pwd_19

db_0.users_1

id	email	nickname	password
2	user_1@test.com	user1	pwd_1
6	user_5@test.com	user5	pwd_5
10	user_9@test.com	user9	pwd_9
14	user_13@test.com	user13	pwd_13
18	user_17@test.com	user17	pwd_17

db_1.users_0

id	email	nickname	password
1	user_0@test.com	user0	pwd_0
5	user_4@test.com	user4	pwd_4
9	user_8@test.com	user8	pwd_8
13	user_12@test.com	user12	pwd_12
17	user_16@test.com	user16	pwd_16

db_1.users_1

id	email	nickname	password
3	user_2@test.com	user2	pwd_2
7	user_6@test.com	user6	pwd_6
11	user_10@test.com	user10	pwd_10
15	user_14@test.com	user14	pwd_14
19	user_18@test.com	user18	pwd_18

如上可见 20 条 user 数据被正确分到了四张表中，分库分表配置成功。

通过上述示例可以看到，数据在插入时已经按照分片规则被自动路由到不同的库和表中，实现了基础的分库分表效果。

但需要注意的是，本文中的分片规则属于人为构造的简化模型，更多用于帮助理解数据路由过程。在真实生产环境中，ShardingSphere 还支持更复杂的分片策略（如哈希分片、范围分片、自定义算法等），同时也可以配合雪花算法等分布式 ID 生成方案，从而避免手动维护 ID 和路由规则的问题。

Java on Evorsio

Z 垃圾收集器 (ZGC)

Z 垃圾收集器 (ZGC)

动机

描述

启用分代 ZGC

设计

多重映射内存（multi-mapped memory）

优化屏障（Optimized barriers）

快速路径与慢速路径

最小化读屏障（load barrier）职责

记忆集屏障（remembered-set barriers）

SATB 标记屏障（SATB marking barriers）

融合写屏障检查（fused store barrier checks）

写屏障缓冲区（store barrier buffers）

屏障补丁（barrier patching）

双缓冲记忆集（double-buffered remembered sets）

无需额外堆内存的对象迁移（relocations without additional heap memory）

密集堆区域（dense heap regions）

大对象（large objects）

全垃圾收集（full garbage collections）

替代方案

更简单的屏障与指针染色方案

继续使用多重映射内存（multi-mapped memory）

测试

风险与假设

实现复杂度

分代 ZGC 与非分代 ZGC 的性能差异

Garbage-First（G1）垃圾收集器

Garbage-First（G1）垃圾收集器

简介

启用 G1

基本概念

堆布局

垃圾收集周期

仅年轻代阶段（Young-only phase）

空间回收阶段（Space-reclamation phase）

垃圾收集停顿与收集集合（Collection Set）

Garbage-First 内部机制（Garbage-First Internals）

Java 堆大小调整（Java Heap Sizing）

周期性垃圾回收（Periodic Garbage Collections）

确定初始堆占用率（Determining Initiating Heap Occupancy）

标记（Marking）

极度紧张堆空间情况下的行为（Behavior in Very Tight Heap Situations）

G1 GC 的自适应默认值（Ergonomic Defaults for G1 GC）

与其他收集器的比较（Comparison to Other Collectors）

Java 八股

Java 后端开发八股

基础语法

基本类型

Object 类有哪些方法？

String s = new String("hello");会创建几个对象?

创建对象实例的方式有几种？

为什么 equals() 和 hashcode() 要同时重写？

== 和 equals() 的区别

抽象类和接口的区别

为什么在 Java 8 之后接口中可以有 default/static 方法呢？

类是什么？

接口是什么？

抽象类是什么？

谈谈你对面向对象的理解

OOP 的核心是什么？

OOP 三大核心特性

StringBuilder 和 StringBuffer 的区别

Error 和 Exception 的区别

对象的组成

对象头

实例数据

对齐填充

反射的原理

多线程

进程和线程的区别

线程的分类

线程的创建方式

线程的生命周期

start()和run()方法有什么区别

多线程安全问题和产生原因

Synchronized 的底层原理

称呼层面

状态层面

`String s = new String("hello");`会创建几个对象?

`start()`和`run()`方法有什么区别