Java on 小蜜蜂

Synchronized

Wed, 22 Jan 2025 13:16:53 +0800

JMM

Fri, 09 Jul 2021 23:36:22 +0800

Java Memory Model（JMM）是 Java 虚拟机规范中定义的一组规则，用于屏蔽不同硬件和操作系统的内存访问差异，保证 Java 程序在多线程环境下的原子性、可见性、有序性。

一、为什么需要 JMM？

多线程环境下，每个 CPU 核心都有自己的缓存（L1/L2/L3），主内存中的数据被多个核心同时读写时会出现三个问题：

可见性：一个线程修改变量，另一个线程可能看不到
原子性：多个操作组合在一起可能被其他线程干扰
有序性：编译器和处理器可能对指令重排序，导致执行顺序与代码顺序不一致

JMM 定义了主内存和工作内存的交互规范，以及 happens-before 规则来约束重排序。

二、JMM 的内存操作

JMM 定义了 8 种内存操作来完成变量在主内存和工作内存之间的同步：

lock：作用于主内存，将变量锁定为当前线程独享
unlock：作用于主内存，释放锁定
read：作用于主内存，将变量值从主内存传输到工作内存
load：作用于工作内存，将 read 操作传输来的值放入工作内存副本
use：作用于工作内存，将工作内存中的变量值传递给执行引擎
assign：作用于工作内存，将执行引擎计算的值赋给工作内存副本
store：作用于工作内存，将工作内存中的变量值传送到主内存
write：作用于主内存，将 store 操作传来的值写入主内存

这 8 个操作必须满足以下规则：

read 和 load、store 和 write 必须成对出现
assign 不能单独发生（必须有 use 先获取值才能 assign）
变量在工作内存中改变后必须同步回主内存

单线程下的基本流程

sequenceDiagram
    participant 主内存
    participant 工作内存
    participant 线程

    Note over 主内存,工作内存: 读取变量（主内存 → 工作内存）
    线程 ->> 主内存: read(var)
    主内存 -->> 工作内存: 传输变量值
    线程 ->> 工作内存: load(var)

    Note over 工作内存: 修改变量（工作内存内操作）
    线程 ->> 工作内存: assign(var, newValue)

    Note over 工作内存,主内存: 写回变量（工作内存 → 主内存）
    线程 ->> 工作内存: store(var)
    工作内存 -->> 主内存: 传输变量值
    线程 ->> 主内存: write(var)

三、三大特性详解

原子性问题

多个独立操作组合在一起不是原子的。典型场景：count++ 实际上是 read→load→use→assign→store→write 六个步骤，线程 A 和线程 B 可能同时执行到中间的 use 步骤。

sequenceDiagram
    participant 主内存
    participant 工作内存A
    participant 线程A
    participant 工作内存B
    participant 线程B

    rect rgba(255, 0, 0, 0.1)
        Note left of 线程A: 线程A操作
        线程A ->> 主内存: read(var)
        主内存 -->> 工作内存A: var=0
        线程A ->> 工作内存A: load(var)
        线程A ->> 工作内存A: assign(var, 1)
        线程A ->> 工作内存A: store(var)
        工作内存A -->> 主内存: 准备写入var=1
    end

    rect rgba(0, 255, 0, 0.1)
        Note right of 线程B: 线程B操作（插入A的store→write之间）
        线程B ->> 主内存: read(var)（主内存仍为0）
        主内存 -->> 工作内存B: var=0
        线程B ->> 工作内存B: load(var)
        线程B ->> 工作内存B: assign(var, 1)
        线程B ->> 工作内存B: store(var)
        工作内存B -->> 主内存: 写入var=1
        主内存 -->> 线程B: write(var)完成
    end

    rect rgba(255, 0, 0, 0.1)
        Note left of 线程A: 线程A完成写入（被覆盖）
        主内存 -->> 线程A: write(var)（最终var=1，预期为2）
    end

解决方式：使用 synchronized 或 Lock 保证原子性，或使用 AtomicInteger 等 CAS 操作。

可见性问题

线程 B 修改了变量，线程 A 可能仍然使用自己工作内存中的旧副本。原因：A 没有及时从主内存重新 read→load。

volatile 解决可见性：对 volatile 变量的写操作会立即执行 store→write 刷新到主内存，读操作会强制从主内存 read→load，而不是使用工作内存缓存的旧值。

sequenceDiagram
    participant 主内存
    participant 工作内存A
    participant 线程A
    participant 工作内存B
    participant 线程B

    rect rgba(0, 255, 0, 0.1)
        Note left of 线程A: 线程A操作（volatile变量）
        线程A ->> 主内存: read(var)
        主内存 -->> 工作内存A: var=0
        线程A ->> 工作内存A: load(var)
        线程A ->> 工作内存A: assign(var, 1)
        线程A ->> 工作内存A: store(var)
        工作内存A -->> 主内存: 立即写入var=1
        主内存 -->> 线程A: write(var)完成
    end

    rect rgba(0, 0, 255, 0.1)
        Note right of 线程B: 线程B操作（强制读取最新值）
        线程B ->> 主内存: read(var)（必须读取var=1）
        主内存 -->> 工作内存B: var=1
        线程B ->> 工作内存B: load(var)
    end

有序性问题

编译器和处理器为了优化性能会对指令重排序，但在多线程下可能导致意外的执行顺序。例如经典的双重检查锁单例：

// 未正确使用 volatile 的版本
private static Singleton instance;
public static Singleton getInstance() {
    if (instance == null) {           // 第一次检查
        synchronized (this) {
            if (instance == null) {   // 第二次检查
                instance = new Singleton();  // 可能被重排序
            }
        }
    }
    return instance;
}

instance = new Singleton() 实际为三步操作：

分配内存空间
初始化对象
将引用指向内存地址

步骤 2 和 3 可能被重排序，导致另一个线程获得一个未初始化完成的对象。volatile 通过禁止指令重排序解决了这个问题。

四、happens-before 规则

happens-before 是 JMM 的核心规则，用于判断两个操作之间是否存在数据竞争：

程序顺序规则：一个线程中的每个操作 happens-before 该线程的后续操作
volatile 变量规则：对 volatile 变量的写 happens-before 后续对该变量的读
锁规则：解锁 happens-before 后续对同一把锁的加锁
传递性：A happens-before B 且 B happens-before C → A happens-before C
线程启动规则：Thread.start() happens-before 被启动线程中的任何操作
线程 join 规则：线程中所有操作 happens-before 其他线程对该线程的 Thread.join() 成功返回

五、volatile vs synchronized 对比

特性	volatile	synchronized
可见性	即时可见	通过解锁刷新到主内存实现
原子性	不保证	保证
有序性	禁止指令重排序	通过加解锁保证有序
性能	无锁，开销小	有锁，涉及线程挂起和唤醒
使用场景	状态标记、单次写入	复合操作、需要原子性的场景

常见误区

volatile 不能替代 synchronized：volatile 仅保证可见性和有序性，不保证原子性（如 count++ 仍然有并发问题）
final 也有可见性保证：JMM 保证构造函数结束后，final 字段对其他线程可见（除非发生 this 引用逸出）
happens-before 规则不是时间顺序：它不要求物理时间上 A 先于 B 执行，只要求在语义上 A 的结果对 B 可见

JVM 问题排查

Sun, 12 Jul 2020 13:16:53 +0800

可正常运行系统：

通过jmap来查看JVM中各个区域的使用情况
通过jstack来查看线程的运行情况，比如哪些线程阻塞、是否出现死锁
通过jstat来查看垃圾回收情况，特别是fullgc，如果发现fullgc比较频繁，那么就得进行调优
通过各个命令的结果或者jvisualvm等工具来进行分析
首先：初步猜测频发发送fullgc的原因，如果频繁发生fullgc，但是又一直没有出现内存溢出，那么表示fullgc实际上回收了很多对象，所以这些对象最好能在younggc过程中直接回收掉，避免这些对象进入到老年代，对于这种情况，就要考虑这些存活时间不长的对象是不是比较大，导致年轻代放不下，直接进入到老年代，尝试加大年轻代的大小，如果改完之后，fullgc减少，则证明修改有效
同时，还可以找到占用CPU最多的线程，定位到具体的方法，优化这个方法的执行，看是否能避免某些对象的创建，从而节省内存

运行中发生OOM的系统：

一般生产系统中都会设置当前系统发生了OOM时，生成当时的dump文件（-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/usr/local/base）
我们可以利用jvisualvm等工具来分析dump文件
根据dump文件找到异常的实例对象和异常的线程（占用CPU高），定位到具体代码
然后再进行详细的分析和调试

垃圾回收器

Wed, 18 Jul 2018 15:43:54 +0800

一、JVM 垃圾回收器概述

常见的垃圾回收器：

Serial GC
Parallel GC（Throughput GC）
CMS GC（Concurrent Mark Sweep）
G1 GC（Garbage First）
ZGC（Z Garbage Collector）
Shenandoah GC

二、垃圾回收器的特点与回收流程

衡量 GC 优劣的三个核心指标

吞吐量（Throughput）：用户代码运行时间 /（用户代码运行时间 + GC 时间）。越高越好。
暂停时间（Pause Time / Latency）：GC 时应用线程暂停的时间。越短越好。
内存占用（Footprint）：GC 额外消耗的内存（如 G1 的 RSet、ZGC 的染色指针）。越少越好。

这三者不可能同时优化——任何 GC 都在三者间做取舍。

1. Serial GC

特点：单线程，回收时全部 STW
为什么存在：单核 CPU 或小型应用场景，多线程反而有额外开销
回收流程：
- 新生代：复制算法（Copying）
- 老年代：标记-整理算法（Mark-Compact）
适用场景：客户端应用、小型服务端、单核环境
参数：-XX:+UseSerialGC
何时选它：堆小于 100MB、单核 CPU。其他情况不推荐。

2. Parallel GC（Throughput GC）

特点：多线程，目标是最大化吞吐量，但 STW 时间较长
设计目标：“只要暂停时间在可接受范围内，吞吐量越高越好”
回收流程：
- 新生代：复制算法（多线程）
- 老年代：标记-整理算法（多线程）
适用场景：多核 CPU、对延迟要求不高的批处理/数据分析任务
重要参数：
- -XX:+UseParallelGC：启用
- -XX:ParallelGCThreads：并行 GC 线程数（默认 = CPU 核心数）
- -XX:MaxGCPauseMillis：期望最大暂停时间（不是硬保证，默认无）
- -XX:GCTimeRatio：吞吐量目标（默认 99，即允许 1% 时间花在 GC 上）

3. CMS GC（Concurrent Mark Sweep）

特点：并发收集老年代，尽量减少 STW 时间
为什么选 CMS：对于 Web 服务等延迟敏感应用，每次 Full GC 暂停几秒钟不可接受。CMS 让大部分 GC 工作与应用线程并发。
回收流程：
1. 初始标记（STW）：标记 GC Roots 直接关联的对象——快速
2. 并发标记：从 GC Roots 开始遍历所有引用——与应用并发
3. 重新标记（STW）：修正并发标记期间引用变化导致的漏标——较快
4. 并发清除：清除不可达对象——与应用并发
核心问题：
- 内存碎片：使用标记-清除算法，老年代越来越碎片化 → 最终触发 Full GC 且无法避免长时间 STW
- CPU 敏感：并发阶段抢占 CPU，应用吞吐量下降
- 浮动垃圾：并发标记期间新产生的垃圾本次无法回收
- Promotion Failed：新生代对象晋升老年代时无连续空间 → Full GC
重要参数：
- -XX:+UseConcMarkSweepGC：启用（JDK 9 后已废弃，JDK 14 移除）
- -XX:CMSInitiatingOccupancyFraction：触发 CMS 的老年代使用率阈值（默认 68%）
- -XX:+UseCMSCompactAtFullCollection：Full GC 时整理内存
- -XX:CMSFullGCsBeforeCompaction：多少次 Full GC 后进行一次整理
为什么被废弃：G1 在延迟和吞吐量之间的平衡表现更好，且 CMS 无法解决碎片化和浮动垃圾问题。

4. G1 GC（Garbage First）

特点：面向大堆、多核的服务端 GC。将堆划分为多个 Region，优先回收垃圾最多的 Region（“Garbage First” 名字的由来）
设计思路：不要求一次回收整个堆，而是分批次回收每个 Region，通过可预测的 pause time 模型控制停顿
回收流程：

初始标记(STW) → 并发标记 → 最终标记(STW) → 筛选回收(STW)

初始标记：标记 GC Roots + 修改 TAMS（Next Top at Mark Start）指针
并发标记：从 GC Roots 遍历所有对象，记录引用变更到 SATB（Snapshot At The Beginning）队列
最终标记：处理 SATB 队列中的漏标对象
筛选回收：计算每个 Region 的回收价值（回收能释放多少空间 × 回收耗时），优先回收"垃圾最多、回收最快"的 Region
关键内部机制：

机制	作用
Region	堆划分为 1MB~32MB 的 Region，每个 Region 可扮演 Eden/Survivor/Old/Humongous
RSet（Remembered Set）	记录其他 Region 对本 Region 的引用——避免全堆扫描
SATB（Snapshot At The Beginning）	并发标记开始时拍堆快照，所有在标记期间变更的引用都记录到 SATB 队列
写屏障	对象引用变更时触发，更新 RSet + 记录 SATB

适用场景：堆大小 4GB+，多核 CPU，延迟要求 100-300ms
重要参数：
- -XX:+UseG1GC：启用（JDK 9+ 默认）
- -XX:MaxGCPauseMillis：期望暂停时间目标（默认 200ms，G1 会努力但无法硬保证）
- -XX:G1HeapRegionSize：Region 大小（默认堆/2048，1~32MB）
- -XX:InitiatingHeapOccupancyPercent：触发并发标记的堆使用率（默认 45%）
- -XX:G1NewSizePercent：新生代最小占比（默认 5%）
- -XX:G1MaxNewSizePercent：新生代最大占比（默认 60%）
何时选 G1：JDK 11+、堆 4GB+、延迟要求几百毫秒，G1 是默认选择。

5. ZGC（Z Garbage Collector）

特点：极低延迟（STW < 10ms），与堆大小基本无关（即使是 TB 级堆）
为什么能这么低延迟：几乎所有阶段都并发，只在极少数点 STW（且 STW 阶段不随堆大小增长）
关键技术：

技术	作用
染色指针（Colored Pointers）	在 64 位指针的高位（42 位之后）存储 GC 状态信息（Finalizable/Remapped/Mark1/Mark0），无需额外内存
读屏障（Load Barrier）	每次从堆读取引用时检查指针颜色，如果对象被移动，读屏障在返回前修正引用
并发迁移（Relocation）	存活对象在应用运行时被迁移到新区域，旧区域清空后回收

回收流程：
1. 并发标记（Concurrent Mark）：遍历对象图，标记存活对象。与 G1 不同，ZGC 的标记完全并发（初始标记的 STW 极短）。
2. 并发迁移预备（Concurrent Prepare for Relocation）：确定需要清理的 Region。
3. 并发迁移（Concurrent Relocate）：将存活对象复制到新 Region，更新引用。读屏障确保应用线程始终访问到正确地址。
4. 并发重映射（Concurrent Remap）：修正所有指向旧位置的引用。
适用场景：TB 级堆、延迟要求 < 10ms 的金融交易/实时系统
重要参数：
- -XX:+UseZGC：启用（JDK 11 实验性，JDK 15 正式，JDK 18+ 默认）
- -XX:ZAllocationSpikeTolerance：分配尖峰容忍度（默认 2.0）
- -XX:ZCollectionInterval：最大回收间隔（秒）
注意事项：ZGC 的吞吐量略低于 G1（因为读屏障开销），内存占用也更高。选 ZGC 时确认你能接受这些 Trade-off。

6. Shenandoah GC

特点：与 ZGC 类似，目标是极低延迟。与 ZGC 的区别在于实现方式：
- ZGC 使用染色指针（需要 64 位系统 + 特定 CPU 特性）
- Shenandoah 使用 Brooks 指针（对象头中加一个转发指针），不依赖硬件
回收流程：并发标记 → 并发转移 → 并发更新引用（比 ZGC 多一个并发更新引用阶段）
适用场景：与 ZGC 类似，但不要求特定硬件
重要参数：
- -XX:+UseShenandoahGC：启用（JDK 12+，OpenJDK 发行版不默认包含——需要 Build 时开启）
- -XX:ShenandoahGCHeuristics：启发式策略（adaptive/static/compact/aggressive）

三、GC 选择决策树

应用需要什么？
├─ 批处理/数据分析 → Parallel（要吞吐量）
├─ Web 服务/微服务
│  ├─ 堆 < 4GB → G1 或 Parallel
│  ├─ 堆 4~16GB → G1（JDK 11+ 默认）
│  ├─ 堆 > 16GB + 延迟敏感 → G1（延迟要求 < 100ms？）
│  │  └─ 是 → ZGC（JDK 17+）
│  └─ 堆 > 100GB + 极致低延迟 → ZGC
└─ 客户端/小型应用 → Serial

四、GC 优化实践

基础三步

确定目标：是提高吞吐量还是降低延迟？
收集数据：PrintGCDetails + GCViewer/GCEasy 分析 GC 日志
调整参数：一次只改一个参数，观察效果

常用 JVM 参数组合

# 打印 GC 日志（JDK 9+）
-Xlog:gc*
-Xlog:gc:gc.log

# 打印 GC 日志（JDK 8）
-XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:gc.log

# G1 生产环境常用参数
-XX:+UseG1GC -XX:MaxGCPauseMillis=200 -XX:+PrintGCDetails

# 大堆 ZGC 常用参数
-XX:+UseZGC -Xms64G -Xmx64G -XX:ZAllocationSpikeTolerance=2.0

内存泄漏排查思路

Heap Dump + MAT（Memory Analyzer Tool）分析大对象
GC 日志中 Full GC 频率异常 → 确认是否为晋升失败或 MetaSpace 泄漏
Native Memory Tracking（NMT）检查 off-heap 内存

五、跨代引用与 RSet 详解

G1 的 RSet（Remembered Set）

每个 Region 维护一个 RSet，记录其他 Region 对它的引用。为什么需要 RSet？Young GC 时只扫描新生代 Region，但老年代可能有对象引用新生代对象——有了 RSet 就不必全堆扫描。

RSet 的结构：哈希表，key 是来源 Region 地址，value 是来源 Region 中的卡页索引（Card Index）。卡页默认 512 字节。

写屏障维护 RSet：

void writeBarrier(Field field, Object newObj) {
    Object oldObj = field.get();
    if (oldObj != null && isCrossRegionRef(oldObj, newObj)) {
        addToRSet(oldObj.region(), newObj.region(), getCardIndex(oldObj));
    }
    field.set(newObj);
}

G1 vs CMS 跨代引用处理对比

机制	G1	CMS
跨代引用处理	每个 Region 维护 RSet	全局卡表（Card Table）
精度	精确到 Region + 卡页	粗粒度（卡表页）
内存开销	较高（每个 Region 一个 RSet）	较低（全局卡表）
扫描效率	仅扫描相关 Region	需扫描整个老年代脏卡页