JAVA on 方糖猫Blog

Netflix 用 JDK Vector API 优化推荐系统：一次教科书级的性能工程实录

Tue, 03 Mar 2026 10:00:00 +0800

Netflix 用 JDK Vector API 优化推荐系统：一次教科书级的性能工程实录

原文：Optimizing Recommendation Systems with JDK’s Vector API 目标读者：写 Java 后端、关心 JVM 性能工程的工程师；也适合任何在“要不要引入原生库/SIMD”上纠结过的人。阅读目标：看清一次完整性能优化的正确顺序——先改计算形状，再改数据布局，最后才轮到换计算内核。以及理解为什么 BLAS 这种“标准答案”在真实生产路径里会失效。

一、背景：Ranker 里的 7.5% 热点

Ranker 是 Netflix 最大、最复杂的服务之一，首页那些个性化推荐行就是它算出来的。看 CPU profile 时有一个特征始终扎眼：视频惊喜度打分（video serendipity scoring）——回答一个简单问题：“这部新片和你最近看的东西有多不一样？”这个特征吃掉每个节点约 7.5% 的总 CPU。

算法本身不复杂：候选视频和用户历史里的每个视频都表示成 embedding 向量；对每个候选，算出它与所有历史向量的余弦相似度，取最大值，用 1 减去它得到“新颖度”分数，作为下游推荐逻辑的输入特征。原始实现非常直白：对每个候选取 embedding，遍历历史逐对算余弦，维护最大值。容易理解，但在 Ranker 的规模下意味着大量串行工作、重复查找、分散的内存访问和糟糕的缓存局部性。火焰图确认了这一点：服务里最热的热点之一就是惊喜度编码器里的 Java 点积。算法层面，这是一个 M 个候选 × N 个历史的嵌套循环，产生 O(M×N) 次独立点积。

一个容易被忽略但决定了整个优化方向的数据：他们埋点统计了流量形状，发现约 98% 的请求是单视频请求，剩下 2% 是大批量请求——但那 2% 的批次实在太大，最终处理的视频总量在单视频和批处理之间大约是 50:50。所以批处理值得做，即使它对中位数请求毫无帮助。

二、第一步：把嵌套循环看成矩阵乘

第一个想法是换“计算形状”：不再想成“很多次小点积”，而是当成一次矩阵运算。设 embedding 维度为 D：

把所有候选 embedding 装进矩阵 A（形状 M×D）；
把所有历史 embedding 装进矩阵 B（形状 N×D）；
所有行归一化成单位向量；
计算 C = A × Bᵀ，C 就是 M×N 的余弦相似度矩阵。

这样 M×N 次独立点积变成一次矩阵乘——而这正是 CPU 和优化过的计算内核最擅长的东西。工程上通过同时支持 encode()（单视频）和 batchEncode()（批量）接入现有框架，保持向后兼容。到这里看起来像“做完了”。但并没有。

三、第二步：批处理反而慢了 5%

上了批处理版本跑金丝雀，结果出人意料：性能回退约 5%。算法没问题——把点积归并成矩阵乘在数学上是等价的。问题出在第一版实现自己引入的开销：

每个批次都新建 double[][] 矩阵装候选、历史和结果。这些又大又短命的对象制造了 GC 压力；而且 double[][] 在内存里本身就不连续，多一层指针跳转，缓存行为更差。
第一版 Java 矩阵乘是朴素的标量实现，用不上 SIMD。换句话说，付了批处理的成本，却没拿到批处理该有的计算效率。

教训来得很快：算法层面的改进，如果实现细节——内存布局、分配策略、计算内核——跟你作对，就一文不值。这一步定下了后面的路线：先把数据布局改成缓存友好的，消灭每批次分配，然后再回头解决矩阵乘内核。

四、第三步：扁平 buffer 加 ThreadLocal 复用

重做数据布局。double[m][n] 换成行主序的扁平 double[]：内存连续，访问模式可预测。然后引入 ThreadLocal<BufferHolder>，持有候选、历史等可复用 buffer——buffer 只增长不收缩，避免每请求分配，同时每个线程持有自己的一份，无锁无争用。核心逻辑就几行：

class BufferHolder {
  double[] candidatesFlat = new double[0];
  double[] getCandidatesFlat(int required) {
    if (candidatesFlat.length < required) {
      candidatesFlat = new double[required];
    }
    return candidatesFlat;
  }
  // historyFlat 同理
}

光是这一步，批处理路径就变得可预测多了：分配少了，GC 压力小了，缓存局部性好了。剩下的问题回到最初的那个：矩阵乘到底用什么算？

五、第四步：BLAS——测试里很好，生产里不行

显而易见的下一步是 BLAS（Basic Linear Algebra Subprograms）。隔离的微基准看起来很有希望，但一旦接进真实的批量打分路径，收益就没兑现。几个因素在作对：

默认的 netlib-java 路径走的是 F2J（Fortran 转 Java）的 BLAS，不是真正的原生实现；
就算用原生 BLAS，也要付 setup 和 JNI 边界切换的开销；
Java 的行主序和很多 BLAS 例程期望的列主序对不上，会引入转换和临时 buffer；
这些额外的分配和拷贝在完整流水线里很扎眼，尤其是旁边还有 TensorFlow 的 embedding 计算。

BLAS 不是白试——它帮忙看清了时间到底花在哪。但它不是那种即插即用的胜利。他们需要的是：纯 Java、贴合扁平 buffer 架构、还能用上 SIMD 的东西。

六、第五步：JDK Vector API

先补一课：JDK Vector API 到底是什么

起点是 SIMD。 现代 x86 CPU 都有向量寄存器，一条指令可以同时算多个数：AVX2 的 256 位寄存器一次装 4 个 double，AVX-512 的 512 位一次装 8 个。一条向量乘加指令顶 4-8 条标量指令——这就是 SIMD（Single Instruction, Multiple Data，单指令多数据），点积、矩阵乘这类规则的数值计算是它的主场。

Java 的痛点是：这些指令一直在硬件里，Java 程序员却够不着。 JIT 有自动向量化，但只对形状简单、能被它证明安全的循环生效，代码稍微复杂一点就悄悄退回标量，而且没有任何方式强制它发生；想要确定性的 SIMD，只能走 JNI 调原生库——代价就是上一步 BLAS 踩过的那些坑。

Vector API 是 Project Panama 的一部分，从 JDK 16 起以孵化模块 jdk.incubator.vector 的形式提供，到原文写作时仍在孵化（所以运行时要显式 --add-modules）。它把 SIMD 变成了普通 Java 代码：

VectorSpecies 描述「一次算几个 lane」（lane 就是向量寄存器里的一个槽位），SPECIES_PREFERRED 让运行时按当前 CPU 挑最优宽度；
DoubleVector.fromArray(...) 从数组加载一组 lane，fma(b, acc) 做向量融合乘加，reduceLanes(ADD) 把各 lane 归约成一个标量；
同一份代码的可移植性由 JIT 兜底：编译时映射到宿主机器最好的指令集，AVX-512 机器跑 8 lane，AVX2 机器跑 4 lane，都不支持就退回标量。

flowchart LR
    subgraph S["标量路径 一条指令算一个数"]
        A1["a0 乘 b0"] --> R1["acc 逐个累加"]
        A2["a1 乘 b1"] --> R1
        A3["a2 乘 b2"] --> R1
        A4["a3 乘 b3"] --> R1
    end
    subgraph V["SIMD 路径 AVX2 一条指令算四个数"]
        B1["向量寄存器加载<br/>a0 a1 a2 a3"] --> F["一条 fma 指令"]
        B2["向量寄存器加载<br/>b0 b1 b2 b3"] --> F
        F --> R2["acc 四个 lane 同时累加"]
    end
    style F fill:#e8f5e9

一句话总结：它把「手写 intrinsics 的活」变成了「写普通循环的活」——你不用知道目标机器是 SSE 还是 AVX-512，JIT 替你选。对他们来说更关键的是：纯 Java，没有原生依赖，没有 JNI 切换，写起来就是普通 Java 代码。

跟他们的负载是绝配：embedding 已经搬进了扁平连续的 double[] buffer，热循环被海量点积占满。最后一步就是用基于 Vector API 的纯 Java SIMD 实现换掉 BLAS——藏在一个小工厂后面，类加载时由 MatMulFactory 选最优实现：jdk.incubator.vector 可用就用 Vector API，否则退回一个高度优化的标量实现——循环展开的点积（同事 Patrick Strawderman 实现，灵感来自 Lucene 里的模式）。

Vector API 版本的内层循环：用 fma()（fused multiply-add）把 a * b 累加进向量累加器；DoubleVector.SPECIES_PREFERRED 让运行时自己挑适合机器的 lane 宽度（AVX2 上通常 4 个 double，AVX-512 上 8 个）。简化版：

for (int i = 0; i < M; i++) {
  for (int j = 0; j < N; j++) {
    DoubleVector acc = DoubleVector.zero(SPECIES);
    int k = 0;
    for (; k + SPECIES.length() <= D; k += SPECIES.length()) {
      DoubleVector a = DoubleVector.fromArray(SPECIES, candidatesFlat, i*D + k);
      DoubleVector b = DoubleVector.fromArray(SPECIES, historyFlat, j*D + k);
      acc = a.fma(b, acc);  // 融合乘加
    }
    double dot = acc.reduceLanes(VectorOperators.ADD);
    // 处理 k..D-1 的尾部
    similaritiesFlat[i*N + j] = dot;
  }
}

原来的一长串标量乘加，变成少量向量 fma() 加一次归约——算法没变，CPU 向量单元的利用率完全不同。

flowchart TD
    subgraph OLD["原始路径 标量"]
        O1["候选 embedding"] --> O3["逐个算余弦相似度"]
        O2["历史 embedding 逐个取"] --> O3
        O3 --> O4["M 乘 N 次独立点积<br/>分散内存访问 缓存不友好"]
    end
    subgraph NEW["优化后路径 SIMD"]
        N1["候选装入扁平 buffer A<br/>M×D 行主序"] --> N3["归一化为单位向量"]
        N2["历史装入扁平 buffer B<br/>N×D 行主序"] --> N3
        N3 --> N4["一次矩阵乘 C = A × Bᵀ<br/>Vector API fma 累加"]
        N4 --> N5["每行取最大值<br/>novelty = 1 - maxSim"]
    end
    O4 -.->|"重构计算形状"| N1
    style O4 fill:#ffcccc
    style N4 fill:#e8f5e9

七、回退与安全：孵化特性的生产姿势

Vector API 还在孵化，运行时要加 --add-modules=jdk.incubator.vector 才能用。他们不想让正确性和可用性绑在这个 flag 上，所以把回退行为显式设计出来：启动时探测 Vector API 支持，有就走 SIMD 批量矩阵乘，没有就走优化过的标量路径，单视频请求继续用逐条实现。运营故事很干净：服务可以选择启用 Vector API 拿满性能，不启用系统也照样安全可预测。

八、生产结果

完整方案（批处理 + 扁平 buffer + ThreadLocal 复用 + Vector API）在跑生产流量的金丝雀上测得：CPU 利用率下降约 7%，平均延迟下降约 12%；为了归一化吞吐差异还跟踪了 CPU/RPS（每 RPS 消耗的 CPU），改善约 10%——同样的流量可以少用约 10% 的 CPU，全量上线后数据保持住了。在函数级别，这个特征占的 CPU 从最初的 7.5% 降到约 1%。汇编层面的变化也很直白：从循环展开的标量点积，变成 AVX-512 硬件上的向量化矩阵乘。

工程实践联想

这篇文章值得读两遍：第一遍看技术，第二遍看顺序。沉淀下来的启示：

优化顺序是：计算形状 → 数据布局 → 分配策略 → 计算内核。 他们最后换的才是内核（Vector API），但前面三步缺任何一步，换内核都拿不到收益。那个 5% 的回退也说明：跳过布局直接批处理，等于同时引入新开销和新瓶颈。做性能优化先问“形状对不对”，再问“数据在内存里躺得对不对”，最后才轮到“用什么算”。
微基准通过不等于生产有效。 BLAS 在隔离测试里很有希望，一进真实路径就被 JNI、布局转换、临时分配吃光收益。任何库的 benchmark 都只对它自己的测试负责；决策必须在真实流量路径里做，最好带着上下游（他们旁边还跑着 TensorFlow 的 embedding 计算）一起测。
double[][] 到扁平 double[] 是 Java 性能工程的经典动作。 二维数组是“数组的数组”，行指针分散，缓存局部性差；扁平数组行主序连续、访问可预测，配合 ThreadLocal buffer 只增不缩，每请求分配降成零——这套组合在 Lucene、Netty 里到处都是，值得变成肌肉记忆。
流量形状决定优化对象。 98% 的请求是单视频，只看中位数的话批处理毫无价值；但那 2% 的大批量扛了一半总计算量。看 p50 优化和看总量优化是两个问题，先埋点搞清楚自己的流量长什么样。
孵化/预览特性的正确姿势：工厂加探测加回退。 不赌 --add-modules 一定加得上，启动时探测、随时退回标量实现，“试用新 JDK 特性”就从一次豪赌变成一个配置项。这个模式可以复用到任何“新能力可用性不确定”的场景。

顺带一个私货：这篇文章最好的地方是诚实——它把“我们以为做完了结果慢了 5%”和“BLAS 没成”都写了出来。性能工程的真实过程就是这样：每一步的正确性都要靠金丝雀和生产数据确认，不存在一步到位。那些只写成功结果的优化文章，参考价值反而低。

本篇小结

问题：Netflix Ranker 的视频惊喜度打分（候选与历史 embedding 的余弦相似度取 max）占单节点 CPU 约 7.5%，热点是 O(M×N) 的逐对点积；流量形状 98% 单视频、2% 大批量，但计算总量 50:50。
路径：M×N 次点积重构成矩阵乘 C = A × Bᵀ（行归一化后即余弦相似度矩阵）→ 金丝雀回退约 5%（double[][] 分配与 GC、非连续布局、标量内核）→ 扁平 double[] 行主序加 ThreadLocal<BufferHolder> 复用（buffer 只增不缩）→ BLAS 因 F2J 非原生、JNI 开销、行列主序不匹配而放弃 → 终解 JDK Vector API（fma() 累加、SPECIES_PREFERRED 自适应 lane 宽度、JIT 映射 SSE/AVX2/AVX-512）。
安全姿势：MatMulFactory 启动时探测，不可用则回退到 Lucene 风格的循环展开标量实现，不依赖 --add-modules 一定在场。
生产结果：CPU 降约 7%、平均延迟降约 12%、CPU/RPS 改善约 10%、该特征的函数级 CPU 占比从 7.5% 降到约 1%；汇编从标量循环展开点积变成 AVX-512 向量化矩阵乘。
核心结论：优化拼的不是“最快的库”，而是把计算形状、内存布局、分配策略这些基本功做对——这些就位之后，Vector API 才成为那个“顺其自然的选择”。

参考资料

Optimizing Recommendation Systems with JDK’s Vector API — Netflix Technology Blog（原文，作者 Harshad Sane，2026-03-03）
JEP 338: Vector API (Incubator) — OpenJDK（Vector API 的 JEP 入口，含 SPECIES、fma、lane 等概念定义；后续孵化迭代见 JEP 417/426/448/460）
netlib-java — GitHub（文中提到的 Java BLAS 库，默认 F2J 路径的出处）
Apache Lucene（回退路径标量点积实现的灵感来源，Lucene 在向量检索里大量使用循环展开和 Panama Vector API）

我开发的keCache：面向 Spring Boot 3 的 L1 + L2 两级缓存框架

Thu, 04 Sep 2025 14:16:44 +0800

在高并发 Java 业务里，缓存几乎是标配。但“用缓存”这件事从来不是只有“加 Redis”一种答案：本地缓存快却解决不了多机一致，Redis 能共享却多了网络与序列化开销。我最近实现一个把两者结合起来、并针对集群一致性做了不少细节处理的小而美框架 —— keCache，现在做一次系统梳理。

一、keCache 是什么

keCache 是一个基于 Java 17 + Spring Boot 3.x + Caffeine + Redisson 的本地缓存框架，采用 L1（Caffeine 本地缓存）+ L2（Redis 分布式缓存） 两级架构，同时提供：

声明式注解（@LocalCacheable、@LocalCacheEvict、@LocalCacheClear）
编程式 API（CacheTemplate）
集群失效广播（Redisson Pub/Sub）
空值保护（防止缓存穿透）
数据一致性校准 SPI

它的定位不是“又一个 Redis 客户端”，而是“让本地缓存能在集群环境下安全使用”的胶水层。

1.1 整体架构

graph TD
    App[业务 Service] -->|注解或 API| Facade["CacheTemplate / AOP 切面"]
    Facade --> L1{L1 Caffeine}
    L1 -->|命中| Return[返回数据]
    L1 -->|未命中| L2{L2 Redis}
    L2 -->|命中| Deserialize[Jackson 反序列化]
    Deserialize --> Backfill[回填 L1]
    Backfill --> Return
    L2 -->|未命中| Load["执行方法 / 加载数据"]
    Load --> Write["写入 L1 & L2"]
    Write --> Return
    PubSub["Redisson Pub/Sub"] -->|失效事件| L1
    Calibration[CalibrationProvider SPI] -->|定时校准| L2

二、开源地址

Gitee：https://gitee.com/soulnew/ke-cache

三、为什么需要 keCache？与纯 Redis / 纯 Caffeine 的对比

很多团队在选择缓存方案时，常常在“纯 Redis”和“纯 Caffeine”之间摇摆。keCache 试图在二者之间取得平衡。

维度	纯 Caffeine	纯 Redis	keCache（L1 + L2）
读取延迟	极低（内存内）	较高（网络 + 序列化）	热数据近似 Caffeine，冷数据走 Redis
单机内存压力	大（全部数据在本 JVM）	小（Redis 承担）	小（只有热数据在本地）
集群一致性	无，各节点独立加载	强一致	最终一致，写操作广播失效
缓存穿透保护	需自行实现	需自行实现	内置 NullValue 短 TTL 保护
多机共享	不支持	支持	支持（L2 Redis）
适用场景	只读/准静态数据、单节点	写多读少、需要强一致	读多写少、可接受最终一致

3.1 相比纯 Caffeine 的好处

Caffeine 是 JVM 内缓存的佼佼者，但它天然只服务于当前进程。在集群部署时：

每台机器都要独立加载数据，导致数据库在启动/预热时被打 N 次。
数据更新后其他节点无法感知，容易出现 A 节点已更新、B 节点仍读旧值的“ stale data ”问题。
内存占用随节点数线性增长，同样一份热数据在每个 JVM 都存一份。

keCache 用 L2 Redis 作为共享底座：首次加载从 Redis 取，后续读请求命中本地 Caffeine；写操作时通过 Redis Pub/Sub 通知其他节点清除本地缓存。这样既保留了 Caffeine 的本地速度，又解决了多机一致性难题。

3.2 相比纯 Redis 的好处

Redis 虽然性能好，但毕竟跨进程：

网络 RTT 不可忽视：高频读取时，哪怕 1ms 也会累积成可观的延迟。
序列化/反序列化开销：Java 对象要先转成 JSON/二进制，再还原，CPU 和 GC 都有压力。
热点 Key 风险：大促期间某些热 Key 会被反复打到同一个 Redis 节点。

keCache 把最热的数据放在本地 JVM 里，只有本地未命中或更新时才访问 Redis，显著降低网络和序列化开销，也分散了 Redis 热点压力。

3.3 方案选型速查

flowchart TD
    Start([开始选缓存方案]) --> Q1{是否需要多机共享?}
    Q1 -->|否| Q2{数据是否只读 /<br/>准静态?}
    Q2 -->|是| Caffeine[纯 Caffeine<br/>简单高效]
    Q2 -->|否| Q3{能否接受最终一致?}
    Q3 -->|能| KeCache[keCache<br/>L1 + L2 加速]
    Q3 -->|否| RedisOnly[纯 Redis /<br/>DB 强一致]
    Q1 -->|是| Q4{写多读少 /<br/>强一致?}
    Q4 -->|是| RedisOnly
    Q4 -->|否| KeCache

3.4 一句话总结

keCache 适合“读多写少、能接受最终一致、希望兼顾本地速度与集群共享”的业务场景；如果你的业务对实时一致性要求极高（如库存扣减、金融记账），建议直接走 Redis 或数据库方案。

四、核心能力速览

能力	说明
声明式缓存	`@LocalCacheable` / `@LocalCacheEvict` / `@LocalCacheClear`，支持 SpEL
多键映射	`@LocalCacheable.Multi` 一次方法返回构建多个索引 key
编程式 API	`CacheTemplate.get/put/evict/clear`，类型安全
二级缓存	L1 Caffeine + L2 Redis，读时先 L1 再 L2，未命中回调加载
空值保护	DB 不存在的 key 缓存短 TTL 的 NullValue，防止缓存穿透
集群一致性	Redisson Pub/Sub 广播失效事件，其他 JVM 清除本地 L1
自失效屏蔽	事件携带 `sourceId`，本机忽略自己发出的事件，避免误清本地缓存
广播风暴防护	远程失效事件只清 L1，不再次广播
数据校准	`CalibrationProvider` SPI，支持时间戳扫描或 CDC 扩展

4.1 读取流程

flowchart TD
    Start([读请求]) --> L1[查 L1 Caffeine]
    L1 -->|命中| A[直接返回]
    L1 -->|未命中| L2[查 L2 Redis]
    L2 -->|命中| Deserialize[Jackson 反序列化]
    Deserialize --> Backfill[回填 L1]
    Backfill --> Return[返回数据]
    L2 -->|未命中| Method[执行真实方法]
    Method --> NullCheck{结果是否为 null?}
    NullCheck -->|是| NullVal[写入 NullValue 到 L1/L2<br/>TTL: null-value-ttl]
    NullCheck -->|否| RealVal[写入真实值到 L1/L2]
    NullVal --> ReturnNull[返回 null]
    RealVal --> Return

4.2 写入与集群失效广播流程

sequenceDiagram
    participant A as 节点 A（写请求）
    participant DB as 数据库
    participant R as Redis（L2）
    participant P as Redis Pub/Sub
    participant B as 节点 B
    participant C as 节点 C

    A->>DB: 更新数据
    A->>R: 删除/覆盖 L2 Key
    A->>P: 发布 EvictEvent（携带 sourceId）
    A->>A: 清除本机 L1

    P->>B: 接收 EvictEvent
    B->>B: sourceId ≠ 本机？
    B->>B: 清除本地 L1
    Note over B: 只清 L1，不再次广播

    P->>C: 接收 EvictEvent
    C->>C: sourceId ≠ 本机？
    C->>C: 清除本地 L1

五、快速开始

5.1 引入 Starter

<dependency>
    <groupId>com.keke</groupId>
    <artifactId>kecache-spring-boot-starter</artifactId>
    <version>1.0.0-SNAPSHOT</version>
</dependency>

5.2 启用缓存

import com.keke.kecache.starter.annotation.EnableKeCache;
import org.springframework.boot.autoconfigure.SpringBootApplication;

@SpringBootApplication
@EnableKeCache
public class Application {
    public static void main(String[] args) {
        SpringApplication.run(Application.class, args);
    }
}

5.3 基础配置

local-cache:
  enabled: true
  namespace: kecache.sample
  default-ttl: 30m
  null-value-ttl: 5m

  caffeine:
    default:
      maximum-size: 1000
      expire-after-write: 10m
      record-stats: true

  redis:
    address: redis://127.0.0.1:6379
    broadcast-channel: kecache:evict
    default-ttl: 30m

  calibration:
    enabled: false

5.4 声明式使用示例

@Service
public class AccountService {

    @LocalCacheable(
        cacheNames = "tve_account_info",
        key = "'id_' + #accountId",
        unless = "#result == null"
    )
    public AccountInfo getById(long accountId) {
        return accountDao.loadById(accountId);
    }

    // 一次查询构建多个索引 key
    @LocalCacheable.Multi({
        @LocalCacheable(cacheNames = "tve_account_info", key = "'id_' + #accountId"),
        @LocalCacheable(cacheNames = "tve_account_info", key = "'nm_' + #result.accountName", unless = "#result == null")
    })
    public AccountInfo getByIdMultiIndex(long accountId) {
        return accountDao.loadById(accountId);
    }

    @LocalCacheEvict(cacheNames = "tve_account_info", key = "'id_' + #accountId")
    public void updateById(long accountId, AccountInfo info) {
        accountDao.update(accountId, info);
    }

    @LocalCacheClear(cacheNames = "tve_account_info")
    public void clearAll() {
        accountDao.clear();
    }
}

5.5 编程式使用

@Service
public class AccountService {

    @Autowired
    private CacheTemplate cacheTemplate;

    public AccountInfo getById(long accountId) {
        return cacheTemplate.get("tve_account_info", "id_" + accountId, key -> {
            return accountDao.loadById(accountId);
        });
    }
}

六、模块结构

graph TD
    Parent[kecache-parent] --> API[kecache-api<br/>注解 / SPI / 配置模型 / 事件]
    Parent --> Core[kecache-core<br/>统一门面 / Key策略 / 空值保护]
    Parent --> Caffeine[kecache-provider-caffeine<br/>L1 Caffeine 实现]
    Parent --> Redisson[kecache-provider-redisson<br/>L2 Redis + 失效广播]
    Parent --> Calibration[kecache-calibration<br/>数据一致性校准]
    Parent --> Starter[kecache-spring-boot-starter<br/>自动配置 + AOP]
    Parent --> Sample[kecache-spring-boot-sample<br/>示例应用 + 测试]

    Starter --> API
    Starter --> Core
    Core --> Caffeine
    Core --> Redisson
    Core --> Calibration

七、关键约定（写代码前必读）

L1 key：cacheName#dataKey
L2 key：{namespace|cacheName}:dataKey（使用 hash tag 避免集群模式下 slot 分散）
默认读写策略：Cache-Aside
失效广播频道：默认 kecache:evict
序列化：Jackson 启用 default typing，保留类型信息

八、使用注意点与避坑指南

8.1 Redis 是硬性依赖

L2 缓存和失效广播都依赖 Redis，测试与运行前请确保 Redis 可达。运行全部测试需要本地启动 Redis：

mvn clean test

8.2 集群一致性是“最终一致”，不是实时一致

本地缓存存在一致窗口：A 节点写入并广播，B 节点收到消息前仍可能读到旧值。对于库存、余额、订单状态等强一致场景，建议绕过本地缓存，直接走 Redis 或数据库。

8.3 空值保护是把双刃剑

默认对 null 结果缓存 5 分钟，可防止缓存穿透。但如果业务刚刚从 DB 写入了一条新记录，而之前查询时正好命中了 NullValue，就会出现“写入后 5 分钟内查不到”的延迟。需要时可：

缩短 null-value-ttl
在写入后主动 @LocalCacheEvict
对新增数据敏感的 cacheName 关闭空值保护

8.4 序列化类型变更要兼容

Redis 层使用 Jackson 并保留类型信息。如果缓存对象发生不兼容的类结构变更（如字段类型改变、删除字段、包名调整），旧数据反序列化可能失败。建议：

对缓存 DTO 做版本控制
重大变更时清空 Redis 对应 key 或切换 cacheName
避免把接口、匿名类、动态代理对象放入缓存

8.5 注意 Key 的命名空间隔离

L2 key 格式为 {namespace|cacheName}:dataKey。如果多个业务共用同一个 Redis 实例，务必设置不同的 namespace，否则可能出现 Key 冲突。

8.6 `@LocalCacheable.Multi` 的 `result` 引用要判空

多索引注解里如果通过 #result.xxx 取字段，必须配合 unless = "#result == null"，否则方法返回 null 时会触发 SpEL 计算异常。

8.7 AOP 自调用不会生效

和 Spring Cache 一样，keCache 的注解基于 AOP。同类方法内部调用（this.method()）不会走代理，缓存注解不会生效。需要时注入自身代理或改用编程式 CacheTemplate。

8.8 谨慎使用 `@LocalCacheClear`

@LocalCacheClear 会清空整个 cacheName 的本地缓存并广播。在高并发场景下，频繁全量清除会：

导致本地缓存命中率骤降
引发集体回源，DB 压力陡增
产生大量广播消息

建议优先使用 @LocalCacheEvict 精确驱逐。

8.9 校准任务不是开箱即用的

CalibrationProvider 目前只是 SPI 骨架，需要业务方自己实现 fetchChanges(Instant start, Instant end) 逻辑（如查变更表、CDC 日志）。开启 local-cache.calibration.enabled=true 后才会按 Cron 触发。

8.10 当前 Redis 部署模式限制

自动配置里的 RedissonClient 目前只实现了 single 单节点模式。如果生产环境使用 Redis Cluster、Sentinel 或主从，需要自行扩展配置。

8.11 关注 Caffeine 内存与统计

默认开启 record-stats: true，本地缓存命中率、加载次数等都会被记录。建议配合 actuator / Micrometer（后续可扩展）监控：

maximum-size 是否设置合理
本地缓存命中率
加载耗时与异常率

九、许可证

keCache 采用 MIT 协议开源。

十、总结

keCache 是一个目标聚焦、实现克制的两级缓存框架：

如果你想要 Caffeine 的速度 + Redis 的共享能力，它值得尝试。
如果你希望 声明式注解即可解决集群本地缓存一致性问题，它提供了失效广播与自失效屏蔽。
如果你的业务对 实时一致性零容忍，请把它当作“加速层”而非“唯一数据源”。

有兴趣可以直接到 Gitee 查看源码与示例：https://gitee.com/soulnew/ke-cache。

我开发的KE Reliable Executor：基于 Redis/MySQL 的 Spring Boot 可靠任务执行框架

Mon, 04 Aug 2025 17:10:00 +0800

我开发的KE Reliable Executor：基于 Redis/MySQL 的 Spring Boot 可靠任务执行框架

在微服务里，异步任务随处可见：支付后通知第三方、订单超时取消、批量对账、报表生成……这些任务有一个共同诉求——不能丢、不能重复执行、失败能重试、状态要能查。

传统做法是直接引入 Kafka、RocketMQ 这类重型消息中间件。但对于很多中小型业务来说，这未免太重：

需要额外维护 Broker、Topic、消费组；
团队要熟悉一套新的运维和监控体系；
为了“可靠”还要配置死信队列、事务消息等高级特性。

如果你的系统里已经有 Redis（或 MySQL），并且任务量级尚未达到 MQ 的吞吐上限，那么完全可以基于 Redis 搭一个轻量且可靠的异步任务执行框架。

我开发是这样一个框架：KE Reliable Executor。

开源地址：https://gitee.com/soulnew/reliableexecutor

一、为什么需要这个工具？

先回顾一下常见异步任务场景里的痛点：

痛点	说明
任务丢失	服务重启或执行线程异常退出后，未执行的任务找不到了
重复执行	多实例部署时，同一个任务被多个节点同时消费
失败即结束	业务异常或网络抖动后，没有自动重试机制
状态黑盒	无法查询任务当前是成功、失败、执行中还是已取消
接入成本高	引入 MQ 需要改代码、加依赖、搭集群

KE Reliable Executor 要解决的就是这些问题。它把“可靠任务执行”抽象成一个 Spring Boot Starter：

业务方只负责定义任务处理器和提交任务；
框架负责存储、调度、加锁、重试、状态流转、清理；
所有状态都可通过 API 查询，也可通过 Micrometer 指标监控。

适合什么场景？

已有 Redis/MySQL，不想额外维护 MQ；
任务量中等，对可靠性和重试有要求；
需要任务状态可查询、可人工介入；
团队希望以最小成本获得“类 MQ”的可靠执行能力。

不适合什么场景？

海量消息、高吞吐（Kafka/RocketMQ 更合适）；
严格顺序消费（ZSET 按时间排序，不保证业务绝对顺序）；
需要复杂路由、死信队列、事务消息等高级 MQ 特性。

二、与竞品的对比

2.1 与 Kafka / RocketMQ 对比

维度	Kafka / RocketMQ	KE Reliable Executor
基础设施	需要独立 Broker 集群	复用 Redis 或 MySQL
运维成本	高（Topic、消费组、监控）	低（Spring Boot Starter）
接入成本	需要学习 SDK 与语义	注解 + 注入接口即可
吞吐量	极高	中等
状态查询	需自建审计表	内置状态查询
重试机制	需配置消费重试	内置可配置重试
适用阶段	大型业务、高并发	中小型业务、快速落地

结论：KE Reliable Executor 不是取代 MQ，而是在“已有 Redis/MySQL、任务量可控”的场景下，提供一个更轻量的选择。

2.2 与 Spring `@Scheduled` + 数据库轮询对比

很多团队最早会用数据库表 + @Scheduled 轮询来实现异步任务。这种做法的问题：

无分布式锁：多实例同时轮询会重复执行；
无状态机：任务状态全靠字段控制，容易混乱；
无统一重试策略：重试间隔、重试次数需要手写；
无优雅关闭：应用关闭时可能丢失正在执行的任务。

KE Reliable Executor 把这些都封装好了：

Master 选举 + 任务级锁保证不重复；
明确的状态机（CREATED → RUNNING → PENDING/COMPLETED/FAILED）；
可配置的重试间隔与次数；
优雅释放锁与线程池关闭。

2.3 与 XXL-JOB / PowerJob 对比

XXL-JOB 和 PowerJob 是优秀的分布式任务调度平台，但它们更适合定时任务和调度中心模式：

需要单独部署调度中心；
适合 Cron 表达式触发的批处理任务；
任务由业务主动提交的场景下，接入不够自然。

KE Reliable Executor 更像一个嵌入式任务队列：

无额外服务，随业务应用启动；
任务由业务代码主动提交；
强调“提交即可靠执行”，而非定时触发。

三、整体架构

3.1 模块解构图

graph TD
    A[业务服务] -->|submitTask| B(ReliableExecutor API)
    B --> C[TaskScheduler]
    C --> D{Master 锁}
    D -->|持有锁| E[扫描 ZSET 任务]
    E --> F[任务级锁]
    F -->|获取成功| G[提交线程池]
    G --> H[TaskExecutor]
    H --> I["任务处理器 @ReliableTaskHandler"]
    I -->|成功| J[移入 FINISHED]
    I -->|失败| K[更新为 PENDING 等待重试]
    C --> L[TaskStorage]
    L --> M[RedisTaskStorage]
    L --> N[JdbcTaskStorage]
    H --> O[ReliableTaskListener]
    C --> P[ReliableExecutorMetrics]

3.2 两层锁模型

graph TB
    subgraph 全局层
        A[Master 锁] -->|仅一个实例| B[负责调度扫描]
    end
    subgraph 任务层
        C["任务级锁 task-lock:{taskId}"] -->|仅一个线程| D[执行任务]
    end
    B --> C

Master 锁：同一时刻只有一个实例负责扫描任务，避免多节点拉取同一批任务。
任务级锁：针对每个 CREATED 任务，提交执行前再抢一次锁，保证同一任务不会被并发执行。

3.3 队列设计

graph LR
    A[提交任务] -->|add| B[Redis ZSET running-task-zset]
    B -->|ZRANGE 按 score| C[调度器]
    C -->|执行成功/失败/超时| D[Lua 原子转移]
    D -->|RPUSH + ZREM| E[Redis List finished-task-list]

使用 ZSET 而非 List 的核心原因：

天然支持时间调度：score 编码创建时间或下次重试时间；
任务唯一：同一个 member 在队列中只有一份；
状态分区：CREATED 与 PENDING 使用不同 score 基数，一次范围查询即可区分。

Score 编码规则：

score = BASE + epochMillis * 100 + retryCount

CREATED 基数：1_000_000_000_000_000
PENDING 基数：2_000_000_000_000_000

3.4 任务状态机

stateDiagram-v2
    [*] --> CREATED: submitTask
    CREATED --> RUNNING: 调度/立即执行
    RUNNING --> COMPLETED: 执行成功
    RUNNING --> PENDING: 执行失败，未超重试
    PENDING --> RUNNING: 到达重试时间
    RUNNING --> FAILED: 超过重试次数
    RUNNING --> TIMEOUT: 超过最大时长
    CREATED --> CANCELLED: 取消任务
    PENDING --> CANCELLED: 取消任务
    RUNNING --> ERROR: 无处理器/参数错误

四、核心设计要点

4.1 Lua 原子转移

任务进入终态时，必须保证“写入 finished list”和“从 ZSET 移除”是原子的，否则可能出现：

任务已判定成功但还在 ZSET 里，被下一次调度捞出来；
任务已从 ZSET 移除但 finished list 没写入，查询不到结果。

框架使用 Lua 脚本完成这一转移：

local score = redis.call('ZSCORE', KEYS[1], ARGV[1]);
redis.call('RPUSH', KEYS[2], ARGV[2]);
if score then
    redis.call('ZREM', KEYS[1], ARGV[1]);
    return 1;
else
    return 0;
end

逻辑：先查 ZSET，无论是否存在都把终态信息写入 finished list，如果存在再删除。整个脚本在 Redis 单线程执行，天然原子。

4.2 Double-Check

调度器拿到任务级锁后、提交线程池前，会再次回查 Redis：

任务是否仍在 running ZSET 中？
任务状态是否仍是 CREATED？

任一条件不满足，立即释放锁并跳过。这是经典的双重检查模式，把“检查-执行”串在锁保护的临界区内。

4.3 双存储后端

graph TD
    A[TaskStorage 接口] --> B[RedisTaskStorage]
    A --> C[JdbcTaskStorage]
    B --> D[Redisson ZSET + List]
    C --> E[reliable_executor_task 表]
    F[配置 reliable-executor.task-storage] -->|redis/mysql| A

redis：默认，适合已有 Redis 的场景；
mysql：适合不希望引入 Redis 或需要更强持久化的场景。

两种后端通过 Spring 条件装配切换，业务代码无感知。

五、快速开始

5.1 引入依赖

dependencies {
    implementation 'com.ftmao:ke-reliable-executor:1.0.0-SNAPSHOT'
    implementation 'org.redisson:redisson-spring-boot-starter:3.27.2'
}

5.2 配置

spring:
  application:
    name: my-app
  redis:
    redisson:
      config: |
        singleServerConfig:
          address: "redis://127.0.0.1:6379"

reliable-executor:
  task-storage: redis
  core-pool-size: 5
  max-pool-size: 10
  queue-capacity: 100

5.3 定义处理器

@Component
public class OrderTaskHandler {

    @ReliableTaskHandler(name = "process_order", paramType = OrderParam.class)
    public void processOrder(OrderParam param) {
        // 业务逻辑
    }

    @ReliableTaskHandler(name = "send_notify")
    public void sendNotify() {
        // 无参任务
    }
}

5.4 提交任务

@Service
@RequiredArgsConstructor
public class OrderService {

    private final ReliableExecutor reliableExecutor;

    public void submitOrder(OrderParam param) {
        TaskSubmitRequest request = TaskSubmitRequest.builder()
                .taskId(UUID.randomUUID().toString())
                .taskName("process_order")
                .taskParameter(param)
                .retryLimit(3)
                .retryInterval(2000)
                .maxDurationMillis(60000)
                .build();
        reliableExecutor.submitTask(request);
    }
}

5.5 监听生命周期

@Component
public class MyTaskListener implements ReliableTaskListener {

    @Override
    public void onTaskCompleted(String taskId, String taskName) {
        // 任务成功
    }

    @Override
    public void onTaskFailed(String taskId, String taskName, String status) {
        // 任务最终失败
    }
}

六、使用注意点与避坑指南

6.1 业务幂等仍然是最后一道防线

框架通过两层锁、double-check、Lua 原子转移把重复执行的概率降到极低，但任何分布式系统都无法 100% 保证幂等。业务 Handler 仍然应该保证幂等，尤其是涉及写数据库、调用外部接口的场景。

6.2 taskId 需要业务保证唯一

框架使用业务传入的 taskId 作为任务唯一标识。如果同一业务单据重复提交相同 taskId，第二次提交会生成新的 ZSET member（如果业务字段不同）或覆盖（如果完全相同）。建议用业务主键 + 操作类型组合生成 taskId，例如 order_12345_pay。

6.3 重试间隔与最大时长的权衡

reliable-executor:
  retryInterval: 2000      # 失败后 2s 再试
  maxDurationMillis: 60000 # 任务最长存活 60s

retryInterval 过小会导致失败任务快速反复执行，放大下游压力；
maxDurationMillis 是从任务创建时间算起，不是单次执行时间；
建议失败任务采用指数退避（当前版本为固定间隔，后续可扩展）。

6.4 MySQL 分支需要自行引入 JPA

框架中 spring-boot-starter-data-jpa 是 compileOnly，使用 MySQL 存储时需要在业务应用里显式引入：

implementation 'org.springframework.boot:spring-boot-starter-data-jpa'
runtimeOnly 'com.mysql:mysql-connector-j'

并执行建表脚本 db/migration/V1__create_reliable_executor_tables.sql。

6.5 Redis 集群环境注意 Key 前缀

框架默认使用 spring.application.name 作为 Redis Key 前缀。如果多个应用共用同一个 Redis 实例，务必设置不同的 spring.application.name，否则任务会互相串扰。

6.6 线程池队列满载时会跳过调度

当线程池队列达到 queueCapacity 时，调度器会跳过本次周期，避免无限制堆积。如果业务出现持续高峰，建议：

调大 maxPoolSize 和 queueCapacity；
监控 reliable_executor_threadpool_queue_size 指标；
必要时配合业务限流。

6.7 不要忽略超时任务

maxDurationMillis 是从创建时间算起的总时长。如果一个任务在队列里排队太久，可能还没执行就触发 TIMEOUT。对于允许较长延迟的任务，要把这个值设大；对于实时性任务，要把重试间隔和排队容量一起考虑。

6.8 本地开发无 Redis 怎么办？

使用 MySQL 分支（H2 也可以跑测试）；
或者本地启动一个 Redis Docker 容器；
框架的 Redis 集成测试会在无 Redis 时自动跳过，不影响 CI。

七、监控指标

框架内置 Micrometer 指标，可接入 Prometheus/Actuator：

指标名	含义
`reliable_executor_is_master`	当前节点是否为 Master
`reliable_executor_tasks_scheduled_total`	累计调度任务数
`reliable_executor_tasks_executed_total`	累计执行任务数
`reliable_executor_tasks_completed_total`	累计成功任务数
`reliable_executor_tasks_failed_total`	累计失败任务数
`reliable_executor_tasks_timeout_total`	累计超时任务数
`reliable_executor_tasks_retried_total`	累计重试次数
`reliable_executor_threadpool_queue_size`	线程池队列大小
`reliable_executor_task_execution_seconds`	任务执行耗时

八、开源与示例

开源地址：https://gitee.com/soulnew/reliableexecutor
示例模块：example/ 子项目包含可运行的 Spring Boot 应用和 REST 接口示例，可直接启动体验任务提交与执行。

九、总结

KE Reliable Executor 是一个轻量、可靠、易接入的异步任务执行框架。它用 Redis ZSET + 两层锁 + Lua 原子转移，在“不引入重型 MQ”的前提下，提供了任务提交、调度、重试、状态查询、监控等完整能力；同时通过 MySQL 分支提供了另一种存储选择。

如果你的业务符合以下特征，不妨试试它：

已有 Redis/MySQL；
任务量中等，重视可靠性；
希望快速落地，不想为 MQ 付出额外运维成本；
需要任务状态可观测、可人工介入。

记住：框架层负责把重复消费的概率降到极低，业务层仍应保证 Handler 幂等，这才是工程上的稳妥做法。

jphotoshop：用 Java Swing 手写一个 Photoshop——架构与算法全解析

Fri, 18 May 2018 10:00:00 +0800

jphotoshop：用 Java Swing 手写一个 Photoshop——架构与算法全解析

把多年前的一个练手项目整理开源了：jphotoshop，一个用纯 Java Swing 手写的 Photoshop 模拟器。不写不知道，写一个"简化版 PS"几乎把计算机图形学、数据结构和设计模式都过了一遍，这篇文章既是功能介绍，也是一次技术复盘。

开源地址：https://gitee.com/soulnew/jphotoshop
技术栈：Java + Swing（Swing Application Framework / JSR-296），NetBeans Ant 工程
规模：197 个 Java 文件，约 1.8 万行（自研约 1.4 万行），开发周期约半年

一、功能概览：一个"简化版 PS"能做什么

UI 形态上和老版 PS 一致：MDI 多文档界面——每张图片一个内部编辑窗口，图层面板、导航缩放面板都是可拖动的浮动内窗。

1.1 图层系统

多图层编辑：图像图层、文字图层、浮动选区层（拖动选区内容时的临时层）；
图层面板带 40×30 实时缩略图，支持拖拽换序（基于 Swing TransferHandler 的 DnD）、复制粘贴为新图层；
透明区域用经典的灰白棋盘格打底。

1.2 选区工具（7 个）

工具	说明
魔棒	容差可调（默认 23），支持多连通区域一次选中
色彩范围	全图相似色选取
多边形套索	逐点勾勒
自由套索	鼠标轨迹勾勒
磁性套索	局部窗口内吸附边缘（完成度不高）
贝塞尔选区	双击闭合时自动做曲线拟合，生成平滑选区
移动工具	把选区内容提成浮动层，拖动实时合成，松手落回底层

选区还支持：羽化（可调半径）、反选、平移/缩放（AffineTransform）、以及标志性的蚂蚁线动画。

1.3 滤镜（24 个，分 5 大类）

模糊：均值平滑、高斯模糊（3×3 高斯核 {1,2,1;2,4,2;1,2,1}/16）、中值滤波；
锐化：Sharpen / SharpenMore（拉普拉斯卷积核 {0,-1,0;-1,5,-1;0,-1,0}）；
艺术：曝光过度、冰晶、熔岩、暗调（平方衰减）、漫画等 8 种风格化效果；
简单：反色、怀旧（sepia 矩阵 0.393/0.769/0.189...）、灰度；
扭曲：挤压、球面化、正/反旋转、正弦波浪、摩尔纹——扭曲类全部带多段滑块实时预览，取消可还原。

1.4 图像调整与文字

HSB 调整：先把整图 RGB 转成 HSB 三维 float 数组，色相/饱和度/亮度三个滑块实时调节再转回 RGB；
对比度调整；
文字工具：点击图片任意位置就地出现透明输入框 + 字体选择面板，完成后生成为独立的文字图层。

1.5 文件与工程

打开 jpg / png / gif / bmp；
自定义 .jps 工程格式（类似 PSD）：整个图层模型实现 Serializable，用 ObjectOutputStream 套 GZIPOutputStream 序列化保存，可以随时回来继续编辑；
复制 / 剪切 / 粘贴、导航缩放窗口、中文界面。

二、架构总览

graph TD
    A["JPhotoShop 入口<br/>EDT 中构建主窗口"] --> B["JDesktopPane MDI 主框架"]
    B --> C["EditFrame 编辑窗口<br/>每张图一个"]
    B --> D["LayerControl 图层面板"]
    B --> E["ViewSizeFrame 导航/缩放"]
    C --> F["EditModel<br/>像素模型 + MemoryImageSource 渲染"]
    F --> G["ImageModel<br/>LinkedList 图层栈"]
    G --> H["ImagePaintLayer / TextPaintLayer / TempImageLayer"]
    H --> I["LayerPlug 混合样式<br/>Alpha 合成"]
    C --> J["ToolManager<br/>工具代理/状态切换"]
    J --> K["Tool 抽象类<br/>魔棒/套索/贝塞尔/移动/文字..."]
    C --> L["FilterManager<br/>properties + 反射装配"]
    L --> M["PicFilter 滤镜即 Action"]
    M --> N["Math 包<br/>CoverOp 卷积 / FeatherSide 羽化<br/>FindSide 轮廓追踪 / PointConnection 并查集"]

整体分四层：UI 层（MDI 窗口与面板）、模型层（图层栈与像素数据）、工具/滤镜层（操作入口）、算法层（jphotoshop.Math 包）。工具和滤镜都通过 properties 配置 + 反射装配，下面详细说。

三、技术亮点

3.1 自绘像素管线：int[][] + MemoryImageSource

核心存储没有用 BufferedImage，而是直接操作 int[][] ARGB 二维数组——所有算法（卷积、混合、羽化）都在裸数组上做，直观且没有额外封装开销。

显示侧用了一个当年很典型的 Swing 高性能技巧：MemoryImageSource + setAnimated(true)，像素变化后调 newPixels() 增量刷新屏幕图像，避免每次重绘都重建整个 Image 对象。编辑、拖选区、调滤镜滑块时的实时反馈都靠它撑着。

3.2 链式图层合成缓存

多图层合成是最频繁的操作，朴素实现是每次重绘把所有层从头合一遍。这里的做法是给每个图层挂一个"本层与下面所有层合成结果的缓存 cacheData"，层与层之间用 backLayer 引用连成链：

graph LR
    BG["背景层<br/>棋盘格"] -->|"合成"| L1["图层1<br/>cacheData"]
    L1 -->|"合成"| L2["图层2<br/>cacheData"]
    L2 -->|"合成"| L3["图层3<br/>cacheData"]
    L3 --> OUT["最终显示图像"]
    style L2 fill:#f96
    L2 -. "仅从此层向上重建" .-> L3

某一层像素变化时，只从该层向上依次 reBuild，下面的层缓存不动。层数多、图大时，这个收益非常明显。

3.3 手写 Alpha 混合

AlphaLayerStyle 实现了逐像素的经典混合公式 C = α·Cf + (1-α)·Cb，并且处理了任意偏移（含负坐标裁剪）——浮动选区拖到画布边缘外也能正确合成。羽化后的选区掩码是 short 型 alpha 权重，抠图粘贴时按权重衰减，边缘不会出现生硬的锯齿。

3.4 魔棒：一条完整的算法链

魔棒是整个项目里算法含量最高的功能，完整链路分三步：

graph TD
    A["用户点击图片某点"] --> B["Flood Fill 泛洪填充<br/>8邻域 + 容差判断<br/>ΔR+ΔG+ΔB ＜ range"]
    B --> C["PointConnection 并查集<br/>id 数组 + sz 数组按秩合并<br/>分离多个互不连通的区域"]
    C --> D["FindSide 8方向轮廓追踪<br/>沿区域边界走一圈<br/>每3步抽稀路径点"]
    D --> E["GeneralPath 选区路径"]
    E --> F["蚂蚁线动画<br/>Timer 500ms 切换两条相位差3的虚线"]

几个细节：

泛洪填充用 LinkedList 当队列，容差判断用曼哈顿距离（|ΔR|+|ΔG|+|ΔB|），比欧氏距离省开方；
一次点击可能选中多个互不连通的区域（比如图片里分散的几块蓝天），用并查集把连通域分组，每个域独立生成轮廓；
轮廓追踪把面状的 boolean 掩码转成线状的路径点列，这一步直接决定蚂蚁线的平滑程度；
蚂蚁线动画是两条相位差为 3 的虚线 BasicStroke 用 500ms 的 Timer 交替绘制——朴素但效果完全对味。

3.5 通用卷积引擎 CoverOp

所有卷积类滤镜（模糊、锐化背后是同一个引擎 CoverOp，提供三种重载：

全图卷积；
掩码限定区域卷积——滤镜只在选区内生效，这是 PS 的基本体验；
short alpha 掩码卷积——配合羽化选区做渐变处理。

RGB 三通道分离卷积 + 边界 clamp，滤镜类只需要给一个卷积核就完事。新增一个模糊变体的成本是十几行代码。

3.6 贝塞尔选区：Schneider 曲线拟合

自由手绘的选区轨迹是抖动的折线，直接当选区很难看。贝塞尔选区工具在双击闭合时调用 JHotDraw 的 Bezier.fitCurve（Schneider 的经典拟合算法），把鼠标点列拟合成平滑的三次贝塞尔曲线段——这就是 PS 里"钢笔工具"的底层原理。

3.7 声明式装配：properties + 反射的原始"插件化"

工具和滤镜都不写死在代码里，而是从 properties 读类名、Class.forName 反射实例化：

# resource/filters.properties
filters.Kinds=模糊,锐化,艺术效果,简单,扭曲
模糊=Smooth,GaussBlur,Median

加一个新滤镜 = 写一个类 + 改一行配置，菜单自动按分类分组生成。工具栏同理（ToolManager.initTool）。项目里还专门有一个 plug 包在探索真正的外部插件机制（虽然只是个雏形）。在 2007 年没有 OSGi、没有 IoC 框架依赖的纯 Swing 工程里，这是最务实的可扩展方案。

3.8 工具架构：Proxy + State 的混合

Tool 抽象类把底层 MouseEvent 翻译成语义化回调（click / pressed / dragged / release / rightClick / clickDouble / move），子类只关心语义。ToolManager 本身也是 Tool 的子类，作为代理把事件转发给当前激活的工具——选中哪个工具，事件流就切到哪个状态机上。每个工具还可以自带 getPlugPanel() 参数面板，选中时挂到选项栏上，和 PS 的交互完全一致。

3.9 扭曲滤镜的"预览-取消"模式

扭曲类滤镜（球面、旋转、波浪……）都是坐标重映射：对每个目标像素做逆极坐标变换，找它在原图的取样点。为了支持滑块实时预览又能取消还原，ContortFilter 在打开对话框时先备份 tempData，滑块每次变化都在备份基础上重算，点取消直接把备份拷回——一个廉价的 Memento 模式。配套的 MultiSlider 多段滑块控件也是自绘的。

3.10 滤镜即 Action

PicFilter extends AbstractAction，滤镜本身就是可以挂进菜单/工具栏的 Action：actionPerformed 里自动取当前窗口、当前图层、当前选区掩码，还处理了选区坐标系到图层坐标系的换算（start -= layerStart），执行完触发 rePaintEdit 刷新。框架把脏活都干了，滤镜作者只需要关注像素算法。

四、诚实的复盘：留下了什么遗憾

开源的代码就是当年的样子，包括未完成的部分，如实列出：

撤销/重做是空架子：UndoRedoManager 的骨架搭好了，但 propertyChange 三个分支全是空的——这是当时没啃下来的硬骨头，现在看应该用 Command 模式重做，而不是当初设想的 property 监听方案；
历史面板、通道面板、外部插件机制都只有雏形；
磁性套索完成度不高；
若干小 bug，比如 FindSide 里找最近点写成了找最远点（if (temp > MinLength) 应为 <）、"undo".endsWith(...) 应为 startsWith、几处类名 typo（WaveFiler、getSize 拼写）——权当留给读者的"考古彩蛋"。

五、写在最后

写 jphotoshop 的半年收获远超预期：并查集、轮廓追踪、卷积、贝塞尔拟合这些算法不再是教科书上的名词，而是要亲手调到能跑的东西；合成缓存、声明式装配、Action 抽象这些设计，也都是被真实需求逼出来的。如果你也想扎实练一次"算法 + 工程"的综合功，手写一个图像编辑器是我能想到的最好题目之一。

源码在 https://gitee.com/soulnew/jphotoshop，欢迎 Star、Fork，更欢迎把那个空着的 UndoRedoManager 补上。

Java 高并发编程实战：同步工具、锁与线程池

Wed, 28 Mar 2018 14:00:00 +0800

Java 高并发编程实战：同步工具、锁与线程池

高并发程序的核心不是“让线程跑得多快”，而是让多个线程在共享可变状态下安全、可预期地协作。JDK 的 java.util.concurrent（JUC）包已经为我们提供了大量经过打磨的同步工具，善用它们比手写 wait/notify 要可靠得多。

一、高层次思想：并发编程在解决什么问题？

并发编程的本质是约束：当多个线程访问同一组可变资源时，通过某种机制保证以下三件事至少满足其一：

互斥：同一时刻只有一个线程能访问临界区。
可见性：一个线程修改的状态，其他线程能正确看到。
有序性：指令不会被编译器或 CPU 乱序到破坏程序语义。

graph TD
    A[共享可变状态] -->|互斥| B[锁 / 信号量]
    A -->|可见性| C[volatile / happens-before]
    A -->|有序性| D[内存屏障 / 同步原语]
    B --> E[正确的并发程序]
    C --> E
    D --> E

首选策略金字塔（从推荐到不推荐）：

graph LR
    A[不可变对象 & 线程封闭] --> B[JUC 并发集合 / 线程池]
    B --> C[高级同步工具 CountDownLatch Semaphore 等]
    C --> D[ReentrantLock & Condition]
    D --> E[synchronized]
    E --> F[手写 wait/notify]

避坑指南 #1：不到万不得已不要手写 wait/notify，极容易写出遗漏 notify、虚假唤醒、持锁休眠等问题。JUC 工具类已经帮你封装好了。

二、线程状态与原语对照

方法	调用者	是否释放锁	进入状态	唤醒条件
`Thread.sleep(ms)`	当前线程	否	`TIMED_WAITING`	时间到
`Thread.yield()`	当前线程	否	`RUNNABLE`（让出 CPU）	OS 调度
`t.join()` / `t.join(ms)`	当前线程等 t	否	`WAITING` / `TIMED_WAITING`	t 结束或超时
`obj.wait()`	当前线程	是	`WAITING`	`notify/notifyAll` 或超时
`obj.notify()`	当前线程	否	—	唤醒一个等待线程

stateDiagram-v2
    [*] --> 新建: new Thread()
    新建 --> 就绪: start()
    就绪 --> 运行: 调度
    运行 --> 就绪: yield / 时间片到
    运行 --> 阻塞: 等待锁
    阻塞 --> 就绪: 获得锁
    运行 --> 等待: wait / join / await
    等待 --> 就绪: notify / 超时 / 被等待线程结束
    运行 --> 超时等待: sleep / wait(timeout)
    超时等待 --> 就绪: 时间到
    运行 --> 终止: 执行完毕

避坑指南 #2：sleep 不释放锁，若在 synchronized 块内 sleep，其他线程会被长时间阻塞。需要“让出锁去等”时，用 wait/Condition.await。

三、多用 JUC 同步类，少用 wait/notify

3.1 Semaphore（信号量）

信号量维护一组“许可”，控制同时访问某资源的线程数量。

Semaphore semaphore = new Semaphore(3); // 最多 3 个线程并发

try {
    semaphore.acquire();
    // 访问受限资源
} finally {
    semaphore.release();
}

graph LR
    A[线程1] -->|acquire| S[许可池 3]
    B[线程2] -->|acquire| S
    C[线程3] -->|acquire| S
    D[线程4] -->|acquire 阻塞| S
    S -->|release| S

避坑指南 #3：release() 一定要放在 finally 里，否则异常会导致许可泄漏，最终所有线程都拿不到许可。

3.2 CountDownLatch 与 CyclicBarrier

特性	CountDownLatch	CyclicBarrier
方向	一个线程等待其他线程	多个线程互相等待
可复用	否（一次性）	是（可 reset）
计数归零后	门闩打开，直接退出	所有线程同时继续

graph LR
    subgraph CountDownLatch
        M[主线程 await] -.->|计数=0| M2[继续执行]
        W1[工作线程1] -->|countDown| C[计数器]
        W2[工作线程2] -->|countDown| C
    end

    subgraph CyclicBarrier
        T1[线程A await] --> B[屏障]
        T2[线程B await] --> B
        T3[线程C await] --> B
        B -->|全部到达| Go[一起继续]
    end

避坑指南 #4：不要把 CountDownLatch 当循环栅栏用，计数到 0 后无法重置；需要循环同步用 CyclicBarrier。

3.3 Exchanger

Exchanger 让两个线程在某个同步点交换数据，适合生产者-消费者配对场景，但使用频率较低。

四、volatile：可见性与有序性，但不保证原子性

volatile 的三条语义：

可见性：写操作会刷入主内存，读操作会从主内存刷新。
有序性：禁止指令重排序（happens-before）。
不保证原子性：复合操作（如 i++）仍需要锁或原子类。

graph LR
    A[线程A 写 volatile flag=true] -->| happens-before | B[线程B 读 flag]
    B --> C[线程B 看到 flag 之前所有写入]

// 错误示例：volatile 不能保证 i++ 原子
private volatile int count = 0;
public void increment() {
    count++; // 读-改-写，非原子
}

// 正确做法
private final AtomicInteger count = new AtomicInteger(0);
public void increment() {
    count.incrementAndGet();
}

避坑指南 #5：只有在单次写、多次读、且不依赖前值的场景下才用 volatile（如状态标志 volatile boolean running = true）。

五、死锁：原因与破解

5.1 典型死锁

graph LR
    T1[线程1] -->|持有 A 锁| B[等待 B 锁]
    T2[线程2] -->|持有 B 锁| A[等待 A 锁]
    B --> T2
    A --> T1

// 错误：锁顺序不一致
devoid transfer(Account a, Account b, int amount) {
    synchronized(a) {
        synchronized(b) { ... }
    }
}

5.2 常见诱因

不一致的加锁顺序：两个线程以不同顺序获取多把锁。
在同步块内调用外部同步方法：引入了不可控的锁依赖。
持锁等待 I/O / 网络 / 用户输入：放大了死锁窗口。

5.3 破解方案

全局统一锁顺序：先按对象哈希值排序再加锁。
使用 tryLock 超时获取锁，失败则回退并重试。
减少锁粒度，避免在同步块内调用外部方法（Open Call）。

// 使用 ReentrantLock 的 tryLock 避免死锁
if (lockA.tryLock(1, TimeUnit.SECONDS)) {
    try {
        if (lockB.tryLock(1, TimeUnit.SECONDS)) {
            try {
                // 执行业务
            } finally { lockB.unlock(); }
        }
    } finally { lockA.unlock(); }
}

避坑指南 #6：死锁往往不是锁本身的问题，而是锁的顺序和依赖关系的问题。设计阶段先画锁依赖图，能发现大部分隐患。

六、公平锁 vs 非公平锁

ReentrantLock fairLock = new ReentrantLock(true);   // 公平
ReentrantLock unfairLock = new ReentrantLock(false); // 非公平（默认）

graph LR
    subgraph 公平锁
        Q[等待队列 T1→T2→T3] -->|按顺序| L[锁]
    end
    subgraph 非公平锁
        N[新线程] -->|插队尝试| L2[锁]
        Q2[队列 T1→T2] -.->|可能继续等待| L2
    end

公平锁：按请求顺序分配锁，减少饥饿，但上下文切换多、吞吐低。
非公平锁：允许“插队”，若锁恰好可用，新线程可直接获取，减少唤醒延迟；但老线程可能长时间等待。

避坑指南 #7：默认选非公平锁即可，性能更好。除非业务明确要求严格的调度公平性（如资源分配器），否则不必打开公平模式。

七、Condition：比 wait/notify 更精确的线程协作

一个 ReentrantLock 可以创建多个 Condition，分别管理不同的等待队列。

graph TD
    L[ReentrantLock] --> C1[Condition A 队列]
    L --> C2[Condition B 队列]
    L --> C3[Condition C 队列]
    C1 -->|signal| W1[唤醒指定线程]

public class PrintABC {
    private final Lock lock = new ReentrantLock();
    private final Condition a = lock.newCondition();
    private final Condition b = lock.newCondition();
    private final Condition c = lock.newCondition();
    private volatile int index = 0;

    private void print(String name, int expect, Condition wait, Condition next) {
        new Thread(() -> {
            lock.lock();
            try {
                while (index != expect) {
                    wait.await();
                }
                System.out.print(name);
                index = (expect + 1) % 3;
                next.signal();
            } catch (InterruptedException e) {
                Thread.currentThread().interrupt();
            } finally {
                lock.unlock();
            }
        }).start();
    }

    public static void main(String[] args) {
        PrintABC p = new PrintABC();
        p.print("A", 0, p.a, p.b);
        p.print("B", 1, p.b, p.c);
        p.print("C", 2, p.c, p.a);
    }
}

避坑指南 #8：Condition.await/signal 与 wait/notify 一样，必须在持有锁的线程中调用，且 await 要用 while 循环而不是 if，防止虚假唤醒。

八、线程池：不要裸开线程

8.1 常见工厂方法

方法	特点	隐患
`newSingleThreadExecutor`	单线程，按提交顺序执行	无界队列，任务堆积会 OOM
`newFixedThreadPool(n)`	固定线程数	同样使用无界队列
`newCachedThreadPool`	线程可复用、可无限创建	高并发下线程数爆炸
`newScheduledThreadPool`	支持定时/周期任务	注意任务异常终止

8.2 ThreadPoolExecutor 核心参数

graph LR
    T[提交任务] -->|核心线程数未满| C[创建核心线程]
    T -->|队列未满| Q[进入阻塞队列]
    T -->|队列满且线程数<max| M[创建非核心线程]
    T -->|队列满且线程数=max| R[拒绝策略]
    C --> E[执行]
    Q --> E
    M --> E

ThreadPoolExecutor executor = new ThreadPoolExecutor(
    4,                      // 核心线程数
    8,                      // 最大线程数
    60L, TimeUnit.SECONDS,  // 非核心线程空闲存活时间
    new ArrayBlockingQueue<>(100), // 有界队列
    new ThreadFactoryBuilder().setNameFormat("biz-pool-%d").build(),
    new ThreadPoolExecutor.CallerRunsPolicy() // 拒绝策略
);

避坑指南 #9：

生产环境尽量直接创建 ThreadPoolExecutor，不要用 Executors 的便捷工厂（无界队列/无限线程是 OOM 元凶）。

任务抛异常会导致线程被回收重建，建议任务内部 try/catch 并记录。

应用关闭前调用 shutdown() 或 shutdownNow()，否则 JVM 可能不会退出。

九、阻塞队列

队列	有界性	实现	特点
`ArrayBlockingQueue`	有界	数组 + ReentrantLock	高吞吐、需要指定容量
`LinkedBlockingQueue`	可选有界	链表 + 两把锁（take/put）	默认无界，小心 OOM
`PriorityBlockingQueue`	无界	堆	按优先级出队
`DelayQueue`	无界	堆	元素到延迟时间才能出队
`SynchronousQueue`	零容量	无缓冲区	一手交钱一手交货
`LinkedTransferQueue`	无界	无锁 CAS	支持 transfer 直接传递
`LinkedBlockingDeque`	无界	双向链表	支持两端操作

graph LR
    P[生产者 put] --> Q[阻塞队列]
    Q --> C[消费者 take]
    P -.->|队列满| W1[阻塞]
    C -.->|队列空| W2[阻塞]

避坑指南 #10：无界阻塞队列在生产者快、消费者慢时会把内存撑爆。优先使用 ArrayBlockingQueue 或指定容量的 LinkedBlockingQueue。

十、自旋锁、ReentrantLock 与 synchronized

10.1 自旋锁

public class SpinLock {
    private final AtomicReference<Thread> owner = new AtomicReference<>();

    public void lock() {
        Thread t = Thread.currentThread();
        while (!owner.compareAndSet(null, t)) {
            // 自旋等待，不进入内核态
        }
    }

    public void unlock() {
        Thread t = Thread.currentThread();
        owner.compareAndSet(t, null);
    }
}

graph LR
    A[互斥锁 sleep] -->|上下文切换| B[内核阻塞]
    C[自旋锁 CAS] -->|用户态循环| D[CPU 忙等]

优点：没有线程上下文切换开销。
缺点：持锁时间长会浪费 CPU；同一线程不可重入，递归调用会死锁。

10.2 ReentrantLock 与 synchronized 对比

能力	synchronized	ReentrantLock
可重入	是	是
可中断	否	`lockInterruptibly()`
超时获取	否	`tryLock(timeout)`
公平锁	否	可选
多条件队列	一个 wait set	多个 Condition
性能	JDK6+ 优化后接近	接近

避坑指南 #11：ReentrantLock 必须显式 unlock()，否则即使异常也会死锁；务必放在 finally 中。synchronized 则由 JVM 保证自动释放。

10.3 偏向锁

偏向锁是 JVM 对无竞争同步的优化：第一次获取锁时把线程 ID 记录到对象头，之后同一线程再进入无需 CAS。

注意：JDK 15 开始偏向锁默认禁用（-XX:+UseBiasedLocking 已废弃），因为现代应用中锁竞争更频繁，撤销偏向锁的开销反而可能大于收益。

十一、线程安全的 Singleton

11.1 饿汉式（类加载时初始化）

public class Singleton {
    private static final Singleton INSTANCE = new Singleton();
    private Singleton() {}
    public static Singleton getInstance() { return INSTANCE; }
}

借助类加载机制保证线程安全，简单可靠；若实例创建开销大且未必使用，则浪费资源。

11.2 静态内部类（推荐）

public class Singleton {
    private Singleton() {}
    private static class Holder {
        private static final Singleton INSTANCE = new Singleton();
    }
    public static Singleton getInstance() {
        return Holder.INSTANCE;
    }
}

graph LR
    A[调用 getInstance] -->|首次触发| B[加载 Holder 类]
    B --> C[初始化 INSTANCE]
    C --> D[返回唯一实例]

延迟加载 + 类加载保证线程安全，是大多数场景下的最佳实践。

11.3 双重检查锁（DCL）+ volatile

public class Singleton {
    private Singleton() {}
    private static volatile Singleton instance;

    public static Singleton getInstance() {
        if (instance == null) {
            synchronized (Singleton.class) {
                if (instance == null) {
                    instance = new Singleton(); // 禁止指令重排
                }
            }
        }
        return instance;
    }
}

避坑指南 #12：DCL 必须加 volatile，否则 new Singleton() 的指令重排会导致其他线程读到未构造完成的对象。

十二、synchronized 的底层行为

synchronized 可以修饰方法或代码块，锁对象分别是：

实例方法：当前实例 this。
静态方法：类的 Class 对象。
代码块：括号里指定的对象。

graph TD
    O[对象头 Mark Word] -->|无锁| A[无锁状态]
    A -->|第一个线程获取| B[偏向锁]
    B -->|出现竞争| C[轻量级锁 CAS]
    C -->|竞争加剧| D[重量级锁 操作系统 Mutex]

避坑指南 #13：不要把 synchronized 当成“只要包住就安全”的万金油。锁的对象要选对，锁的粒度要尽量小，避免锁住整个方法或无关代码。

十三、避坑速查表

不要这样做	推荐做法
手写 `wait/notify` 做复杂协调	用 `CountDownLatch`、`CyclicBarrier`、`Semaphore`
用 `volatile` 做 `i++`	用 `AtomicInteger` 或 `LongAdder`
裸 `new Thread()`	用 `ThreadPoolExecutor`
`Executors.newFixedThreadPool` 无脑用	自定义有界队列 + 拒绝策略
在锁里调外部同步方法 / 阻塞 I/O	缩小锁范围，使用 Open Call
不一致的加锁顺序	全局排序或使用 `tryLock`
DCL 不加 `volatile`	必须加 `volatile`，或改用静态内部类
自旋锁里递归加锁	使用可重入锁 `ReentrantLock`
忽略 `InterruptedException`	恢复中断标志 `Thread.currentThread().interrupt()`
线程池任务吞掉异常	任务内部 `try/catch` 或使用 `Future.get()`

十四、总结

Java 高并发编程的演进路径，其实是从“手动管理线程和锁”走向“使用高层抽象”。牢记下面三句话：

能不变就不变：优先使用不可变对象、线程封闭和 JUC 并发集合。
能用高层就不用底层：用 Semaphore、CountDownLatch、Executor 替代 wait/notify。
锁是最后手段：如果必须用锁，确保加锁顺序一致、粒度最小、持有时间最短。

把这三点落地到代码里，配合上面的图例和示例，就能避开大多数并发陷阱。

参考与延伸阅读

《Java 并发编程实战》（Java Concurrency in Practice）
《Java 并发编程的艺术》
JDK 文档：java.util.concurrent

JVM 内功修炼：运行时数据区、GC 演进与现代调优实践

Wed, 28 Mar 2018 14:00:00 +0800

JVM 内功修炼：运行时数据区、GC 演进与现代调优实践

JVM 是 Java 程序员逃不掉的「操作系统」。懂它不是为了背八股，而是为了在 OOM、Full GC、CPU 飙升时，能一眼定位根因并给出调优方案。

一、高层次思想：JVM 在帮你解决什么问题？

JVM 的核心职责可以抽象成三件事：

一次编译，到处运行：通过字节码 + 解释/编译执行，屏蔽底层 OS 与硬件差异。
自动内存管理：让开发者专注于业务，而不是像 C/C++ 那样手动 malloc/free。
运行时优化：JIT 编译、逃逸分析、内联、锁消除等，把「解释执行」慢慢优化成「本地机器码执行」。

graph LR
    A[.java 源码] -->|javac| B[字节码 .class]
    B -->|类加载子系统| C[方法区/Metaspace]
    C -->|解释器| D[逐行解释执行]
    C -->|JIT 编译器| E[本地机器码]
    D --> F[执行引擎]
    E --> F
    F --> G[操作系统]

避坑指南 #1：不要只把 JVM 当「黑盒」。线上 90% 的 Java 性能问题，根源都在堆外内存泄漏、GC 停顿过长、Metaspace 膨胀、线程栈溢出这四类。

二、运行时数据区：新版 JDK 的版图

不同虚拟机的运行时数据区实现略有差异，但都遵循《Java 虚拟机规范》。现代视角下，区域可划分为「线程私有」和「线程共享」两类：

graph TD
    subgraph 线程私有
        A[程序计数器 PC Register]
        B[虚拟机栈 JVM Stack]
        C[本地方法栈 Native Method Stack]
    end
    subgraph 线程共享
        D[堆 Heap]
        E[方法区 Method Area / Metaspace]
        F[直接内存 Direct Memory]
    end
    A --> G[线程执行上下文]
    B --> G
    C --> G
    D --> H[几乎所有对象实例]
    E --> I[类元数据/常量/静态变量]
    F --> J[NIO / 堆外内存]

2.1 程序计数器（Program Counter Register）

当前线程执行字节码的行号指示器。
分支、循环、跳转、异常处理、线程恢复都依赖它。
线程私有，生命周期与线程一致。
唯一一个在《Java 虚拟机规范》中没有规定 OOM 的区域。

2.2 Java 虚拟机栈（JVM Stack）

每个方法执行时创建一个栈帧（Stack Frame）。
栈帧里包含：局部变量表、操作数栈、动态链接、方法返回地址。
局部变量表中的基本数据类型和对象引用在编译期大小就确定。

graph TD
    A[JVM Stack] --> B[栈帧 Frame 1]
    A --> C[栈帧 Frame 2]
    A --> D[栈帧 Frame 3]
    B --> B1[局部变量表]
    B --> B2[操作数栈]
    B --> B3[动态链接]
    B --> B4[方法返回地址]

避坑指南 #2：-Xss 设置线程栈大小。递归过深、方法调用链过长会抛出 StackOverflowError；如果线程创建太多，总栈空间超过限制，会抛出 OutOfMemoryError: unable to create new native thread。

2.3 本地方法栈（Native Method Stack）

与虚拟机栈作用相同，只是为 Native 方法服务。
HotSpot 中把虚拟机栈和本地方法栈合二为一了。

2.4 Java 堆（Java Heap）

JVM 管理的最大一块内存，被所有线程共享。
几乎所有对象实例和数组都在这里分配。
现代 GC 基本都采用分代收集，逻辑上分为新生代、老年代。

graph LR
    A[Java Heap] --> B[Young Generation 新生代]
    A --> C[Old Generation 老年代]
    B --> D[Eden 区]
    B --> E[Survivor From]
    B --> F[Survivor To]

避坑指南 #3：不要把「堆」和「栈」对立记忆。对象在堆里，引用在栈里；但 HotSpot 的逃逸分析 + 标量替换会把未逃逸的小对象直接分配在栈上，减轻 GC 压力。

2.5 方法区（Method Area）与 Metaspace

存储类信息、常量、静态变量、JIT 编译后的代码缓存。
JDK 7 之前：方法区在 PermGen（永久代）中，大小固定，-XX:MaxPermSize。
JDK 8 及以后：PermGen 被移除，方法区使用本地内存中的 Metaspace，默认只受限于系统内存，用 -XX:MaxMetaspaceSize 控制。

版本	实现	配置参数	常见问题
JDK 7-	PermGen	`-XX:PermSize` / `-XX:MaxPermSize`	动态生成类过多导致 `OutOfMemoryError: PermGen space`
JDK 8+	Metaspace	`-XX:MetaspaceSize` / `-XX:MaxMetaspaceSize`	类加载器泄漏导致 Metaspace 持续增长

避坑指南 #4：Metaspace 默认无上限，服务运行久了可能把容器内存撑爆。线上建议显式设置 -XX:MaxMetaspaceSize，配合监控告警。

2.6 直接内存（Direct Memory）

不属于 JVM 堆，但会被 JVM 直接使用，常见于 NIO 的 DirectByteBuffer。
分配和回收成本较高，但读写 I/O 时避免了堆内外内存拷贝（Zero Copy）。
默认大小约等于 -Xmx，可用 -XX:MaxDirectMemorySize 控制。

避坑指南 #5：Netty、RocketMQ、Elasticsearch 等中间件大量使用堆外内存。出现 OutOfMemoryError: Direct buffer memory 时，先检查是否有 ByteBuf / DirectByteBuffer 未释放，而不是盲目加堆内存。

三、垃圾回收：从算法到收集器演进

3.1 判断对象是否存活

引用计数法：Python 用，但 Java 不用，因为解决不了循环引用。
可达性分析（Reachability Analysis）：从 GC Roots 出发，不可达则回收。

常见 GC Roots：

虚拟机栈中局部变量表引用的对象。
方法区中类静态属性、常量引用的对象。
本地方法栈中 JNI 引用的对象。
被同步锁持有的对象。

graph TD
    A[GC Roots] --> B[栈帧局部变量]
    A --> C[静态变量]
    A --> D[常量]
    A --> E[JNI 引用]
    A --> F[锁持有对象]
    B --> G[可达对象]
    C --> G
    D --> H[不可达对象<br/>等待回收]

3.2 四种基础 GC 算法

算法	思想	优点	缺点
标记-清除	标记无用对象，然后清除	简单，不需要移动对象	效率低，产生内存碎片
复制	内存分两块，活着的对象复制到另一块	无碎片，回收效率高	内存利用率只有一半
标记-整理	标记后把存活对象移到一端，清理边界外	无碎片，内存利用率高	移动对象开销大
分代收集	按对象存活周期分代，不同代用不同算法	兼顾吞吐与停顿	需要维护复杂的跨代引用

3.3 经典垃圾收集器

收集器	工作区域	算法	特点	适用场景	状态
Serial	新生代	复制	单线程，简单高效	客户端模式 / 单核	可用
ParNew	新生代	复制	Serial 的多线程版	配合 CMS	随 CMS 移除
Parallel Scavenge	新生代	复制	吞吐量优先	后台计算	可用
Serial Old	老年代	标记-整理	单线程	客户端模式	可用
Parallel Old	老年代	标记-整理	多线程吞吐量优先	后台计算	可用
CMS	老年代	标记-清除	低停顿，并发收集	互联网低延迟服务	JDK 14 已移除
G1	整堆	标记-整理 + 复制	可控停顿， region 化	大堆、低延迟	JDK 9-22 默认
ZGC	整堆	标记-复制/整理	亚毫秒停顿，TB 级堆	极低延迟	JDK 23+ 默认（分代）
Shenandoah	整堆	标记-复制/整理	低停顿，独立于分代	低延迟	可用，JDK 24 实验分代

graph LR
    A[Serial] --> B[ParNew]
    B --> C[Parallel Scavenge]
    C --> D[G1]
    D --> E[ZGC / Shenandoah]
    style E fill:#f9f,stroke:#333

3.4 分代模型的工作流程

新生代默认占堆的 1/3，老年代占 2/3。新生代内部 Eden:From Survivor:To Survivor 默认约为 8:1:1。

sequenceDiagram
    participant Eden
    participant From as Survivor From
    participant To as Survivor To
    participant Old as Old Generation
    Note over Eden,Old: Minor GC 触发
    Eden->>To: 存活对象复制到 To
    From->>To: 存活对象复制到 To
    From->>Old: 年龄超过阈值的对象晋升
    Note over Eden,From: 清空 Eden 和 From
    To->>From: To 变 From，From 变 To

避坑指南 #6：不要把 Survivor 区看作「两个对称缓存区」。它们在一次 Minor GC 后会交换身份，始终有一个是空的，用于下一次复制目标。

3.5 G1 收集器：里程碑式的设计

G1（Garbage First）把堆划分为多个大小相等的 Region，每个 Region 动态扮演 Eden、Survivor 或 Old 角色。

graph TD
    A[G1 Heap Regions] --> B[Eden Region]
    A --> C[Survivor Region]
    A --> D[Old Region]
    A --> E[Humongous Region<br/>大对象]
    A --> F[Free Region]

G1 的核心优势：

可预测的停顿时间模型：通过 -XX:MaxGCPauseMillis 设定目标停顿。
整体基于标记-整理，局部基于复制：不会产生大面积内存碎片。
回收优先级按垃圾最多的 Region 来：Garbage First 名字来源。

避坑指南 #7：G1 的 -XX:MaxGCPauseMillis 不是越小越好。设得太低（如 50ms）会导致回收 Region 太少、GC 频率飙升，反而降低吞吐。通常建议 100-200ms。

3.6 现代低延迟 GC：ZGC 与 Shenandoah

特性	ZGC	Shenandoah
设计目标	亚毫秒级停顿，支持 TB 级堆	低停顿，独立于分代
并发能力	标记、转移、重定位几乎都并发	并发标记、并发压缩
着色指针	使用	不使用
分代	JDK 21 引入分代 ZGC，JDK 23 起为默认	JDK 24 引入实验性分代 Shenandoah
适用版本	JDK 11+（生产推荐 JDK 17+）	OpenJDK 12+

graph LR
    A[传统 GC<br/>Serial/Parallel/CMS/G1] -->|停顿目标 ms~百 ms 级| B[G1]
    B -->|停顿目标 < 10ms| C[ZGC / Shenandoah]
    C -->|JDK 21+| D[分代 ZGC]
    D -->|JDK 23+| E[分代 ZGC 默认]
    C -->|JDK 24+| F[分代 Shenandoah 实验]

高性能建议 #1：如果应用对延迟敏感（如金融交易、在线游戏、实时推荐），JDK 17 下优先考虑 G1；JDK 21+ 可直接启用 分代 ZGC（-XX:+UseZGC -XX:+ZGenerational），在吞吐和延迟之间取得更好平衡；升级到 JDK 23+ 后分代 ZGC 已是默认，无需额外参数。

3.7 JDK 21/22/23/24 的 GC 演进大事记

JDK 版本	GC 相关变化	影响
JDK 21	JEP 439 正式发布分代 ZGC	默认仍是 G1，但可显式启用 `-XX:+ZGenerational` 获得更低延迟
JDK 22	JEP 423 G1 Region Pinning	G1 在 JNI 临界区内无需禁用 GC，降低延迟毛刺
JDK 23	JEP 474 分代 ZGC 成为默认；非分代 ZGC 废弃	新默认 GC 从 G1 切换到分代 ZGC，亚毫秒级停顿更易获得
JDK 23	JDK-8322630 ZGC 延迟优化	减少 GC 根节点扫描抖动
JDK 24	JEP 490 移除非分代 ZGC	简化 ZGC 维护，统一使用分代模式
JDK 24	JEP 404 分代 Shenandoah（实验性）	Shenandoah 也走向分代，未来低延迟 GC 竞争更激烈
JDK 24	JEP 475 G1 Late Barrier Expansion	优化 G1 写屏障，提升编译和运行时性能

timeline
    title GC 默认与里程碑
    section JDK 8
        默认 : Parallel Scavenge + Parallel Old
    section JDK 9
        默认 : G1
    section JDK 11
        ZGC 实验性
    section JDK 15
        ZGC 生产可用
    section JDK 17
        G1 默认，ZGC/Shenandoah 成熟
    section JDK 21
        分代 ZGC 正式发布（仍非默认）
    section JDK 23
        分代 ZGC 成为默认 GC
    section JDK 24
        非分代 ZGC 移除；分代 Shenandoah 实验

避坑指南 #7.5：网上有说法称 “JDK 21 默认 GC 是 ZGC”，这是错误的。JDK 21 默认仍是 G1；分代 ZGC 只是正式发布，需要显式开启。真正的默认切换发生在 JDK 23。

四、引用类型：不只是强引用

引用类型	回收时机	使用场景
强引用	永不回收，即使 OOM	普通对象
软引用 SoftReference	内存不足前回收	缓存，如图片缓存
弱引用 WeakReference	下一次 GC 时回收	防止内存泄漏，如 `WeakHashMap`
虚引用 PhantomReference	随时可能被回收，必须配合 ReferenceQueue	跟踪对象被回收的事件，做资源后置清理

graph LR
    A[强引用] -->|最强| B[不会被回收]
    C[软引用] -->|内存紧张| D[回收]
    E[弱引用] -->|下次 GC| F[回收]
    G[虚引用] -->|无法获取对象| H[仅回收通知]

避坑指南 #8：不要把软引用当「万能缓存」。在内存紧张时软引用会被批量回收，导致缓存命中率骤降。高并发缓存建议用 Caffeine 等带 TTL 和淘汰策略的专业缓存框架。

五、类加载机制：双亲委派与破坏

5.1 类加载器层次

graph TD
    A[自定义类加载器] -->|委托| B[应用程序类加载器 AppClassLoader]
    B -->|委托| C[平台类加载器 PlatformClassLoader]
    C -->|委托| D[启动类加载器 BootstrapClassLoader]

注意：JDK 9 引入模块化系统后，原来的 Extension ClassLoader 被改名为 Platform ClassLoader，负责加载平台模块（如 java.sql、java.xml 等）。

5.2 双亲委派模型

类加载器收到加载请求，先不自己加载。
向上委托给父加载器。
父加载器无法加载时，子加载器才尝试加载。

避坑指南 #9：Tomcat、SPI、OSGi 都破坏了双亲委派。如果你的项目出现 NoSuchMethodError / ClassCastException: cannot cast to the same class，很可能是同一个类被不同类加载器加载了两次。

六、JIT 编译与执行优化

Java 代码先被解释器执行，热点代码会被 JIT 编译成本地机器码。

6.1 HotSpot 的两层编译器

编译器	别称	特点
C1	Client Compiler	编译快，优化简单，适合启动速度和 GUI
C2	Server Compiler	编译慢，激进优化，适合长期运行的服务端

JDK 7 引入分层编译（Tiered Compilation），JDK 8 默认开启：

0: 解释执行
1~3: C1 编译，带简单/复杂优化
4: C2 编译，激进优化

6.2 常见 JIT 优化

优化	说明
方法内联	把短方法体直接嵌入调用处，减少栈帧开销
逃逸分析	判断对象是否逃出方法/线程作用域
标量替换	把对象拆成基本类型分配在栈上
锁消除	确认对象只被单线程访问时去掉同步锁
锁粗化	把相邻的同步块合并，减少加解锁次数

高性能建议 #2：不要过度纠结「每个对象都在堆上分配」。现代 JVM 的逃逸分析已经很强，写代码时优先保证对象作用域最小化、避免无意义的全局引用，让 JIT 有优化空间。

七、现代 JVM 前沿特性（JDK 21+）

除了 GC，JDK 21 及之后版本还在内存模型、执行模型和 Native 互操作上做了大量演进，这些也会间接影响 JVM 调优思路。

7.1 虚拟线程（Virtual Threads，JEP 444 / JDK 21）

虚拟线程是 JVM 管理的轻量级线程，由 JVM 调度到少量平台线程（Carrier Thread）上运行。
创建成本极低（KB 级栈），适合高并发 I/O 密集型应用。
对 JVM 数据区的影响：虚拟线程的栈帧仍存在于 Java 堆中（作为 Continuation 对象），而不是传统的线程栈。

graph LR
    A[平台线程 Platform Thread] -->|1:N 映射| B[虚拟线程 Virtual Thread]
    B -->|挂载| C[Carrier Thread]
    C -->|运行在| D[OS 线程]

避坑指南 #9.5：虚拟线程虽好，但不要和 synchronized 块、本地方法、文件 I/O 混用导致 “Pinning”，会让载体线程被卡住，降低并发收益。优先使用 ReentrantLock 和异步 I/O。

7.2 Foreign Function & Memory API（JEP 454 / JDK 22）

正式替代 sun.misc.Unsafe 进行堆外内存操作。
通过 Arena 管理堆外内存生命周期，更安全、更可移植。
对直接内存调优的影响：未来 DirectByteBuffer 的底层实现会逐步迁移到 FFM API。

7.3 Project Lilliput：压缩对象头

目标是把 HotSpot 的对象头从 96/128 bit 压缩到 64 bit。
可以显著降低内存占用，提升缓存命中率。
JDK 24 起部分功能已集成（如 64-bit object headers）。

7.4 Project Valhalla：值类型（Value Classes / Primitive Classes）

引入 “值对象”，避免对象头和引用开销。
未来 int[] 和 Integer[] 之间的性能鸿沟会缩小。
目前处于预览阶段，持续关注即可。

7.5 Project Leyden：Java 静态镜像

目标是通过 “静态图像” 加速 Java 启动时间。
类似 GraalVM Native Image，但保持完整 Java 语义和 JVM 运行时能力。
对 Serverless、CLI 工具、云原生场景意义重大。

八、避坑指南：线上常见问题

8.1 慎用 `System.gc()`

只是「建议」JVM 进行 Full GC，不保证执行。
很多框架（如某些老版本 JDBC）会调用它，导致不可控停顿。
线上建议关闭：-XX:+DisableExplicitGC。

8.2 finalize() 已过时

JDK 9 起标记为 @Deprecated。
对象回收前不保证一定执行 finalize()，且执行顺序不确定。
资源清理用 try-with-resources 或 Cleaner。

8.3 大对象与 Humongous

G1 中超过 Region 大小一半的对象叫 Humongous Object，直接进老年代，增加 GC 负担。
避免一次性创建超大数组或字符串。

8.4 动态代理与 CGLIB 的 Metaspace 泄漏

Spring AOP、MyBatis、Dubbo 大量生成代理类。
如果 ClassLoader 没释放，代理类元数据会持续占用 Metaspace。
常见于热部署、OSGi、动态脚本场景。

8.5 大堆 + Full GC 的雪崩

堆内存越大，G1 的 Mixed GC、CMS 的 Full GC 停顿越长。
超过 32GB 时，指针压缩会失效，对象头变大，反而浪费内存。
建议堆大小控制在 16GB-32GB 之间，再大的堆考虑横向拆分服务或换 ZGC。

九、高性能调优建议

9.1 选择 GC 与 JDK 版本

场景	推荐配置
通用 Web 服务，JDK 17-22	`-XX:+UseG1GC -XX:MaxGCPauseMillis=200`
通用 Web 服务，JDK 23+	默认已是分代 ZGC，一般无需改动
延迟敏感，JDK 21-22	`-XX:+UseZGC -XX:+ZGenerational`
延迟敏感，JDK 23+	默认分代 ZGC，无需显式开启
批处理/大数据，吞吐优先	`-XX:+UseParallelGC` 或 G1
容器环境	显式设置 `-Xmx`、`-Xms`、`-XX:MaxMetaspaceSize`，并开启 `-XX:+UseContainerSupport`

9.2 参数模板

JDK 17-22 通用 Web 服务（G1）

java \
  -Xms4g -Xmx4g \
  -XX:MetaspaceSize=256m \
  -XX:MaxMetaspaceSize=512m \
  -XX:+UseG1GC \
  -XX:MaxGCPauseMillis=200 \
  -XX:+AlwaysPreTouch \
  -XX:+DisableExplicitGC \
  -XX:+HeapDumpOnOutOfMemoryError \
  -XX:HeapDumpPath=/var/log/app/heapdump.hprof \
  -jar app.jar

JDK 23+ 通用 Web 服务（默认分代 ZGC）

java \
  -Xms4g -Xmx4g \
  -XX:MetaspaceSize=256m \
  -XX:MaxMetaspaceSize=512m \
  -XX:+AlwaysPreTouch \
  -XX:+DisableExplicitGC \
  -XX:+HeapDumpOnOutOfMemoryError \
  -XX:HeapDumpPath=/var/log/app/heapdump.hprof \
  -Xlog:gc*:file=/var/log/app/gc.log:time,uptime,level,tags:filecount=10,filesize=100m \
  -jar app.jar

说明：JDK 23 起默认就是分代 ZGC，不需要 -XX:+UseZGC。如果仍想显式启用，可保留；如果想用回 G1，使用 -XX:+UseG1GC。

9.3 监控与诊断三板斧

工具	用途
`jstat -gcutil <pid> 1000`	实时查看 GC 频率与内存占比
`jmap -dump:format=b,file=... <pid>`	生成堆快照，MAT 分析内存泄漏
`jstack <pid>`	打印线程栈，排查死锁与 CPU 热点
GC 日志 / `-Xlog:gc*`	分析 GC 原因与停顿时间
`async-profiler`	低开销 CPU/内存/锁分析

高性能建议 #3：调优前一定先定目标——是降低停顿？提高吞吐？还是减少内存？没有目标的调优就是瞎调。先用 GC 日志和监控找到瓶颈，再改参数，而不是反向操作。

十、JVM 问题排查实战：发现 → 定位 → 修复

线上 JVM 问题通常表现为：服务卡顿、响应 P99 飙高、CPU 打满、内存持续增长、频繁 OOM。解决它们的核心思路是：先量化，再猜测。

10.1 问题发现的四层入口

graph TD
    A[业务层] -->|接口超时/P99 飙升| B[应用层]
    B -->|Full GC 频繁/GC 时间长| C[JVM 层]
    C -->|堆/栈/Metaspace 异常| D[系统层]
    D -->|容器 OOMKilled/CPU 限流| E[基础设施层]

入口	典型现象	常见根因
业务监控	接口 RT 上涨、错误率增加	GC 停顿、线程阻塞、锁竞争
APM / Trace	某段链路偶发耗时几百 ms	Full GC、Metaspace 扩容、类加载
容器监控	Pod 内存触顶被 OOMKilled	堆外内存泄漏、堆太大、Metaspace 无上限
GC 日志	GC 频率异常、停顿时间超标	收集器选择不当、堆大小不合理、大对象过多
JVM 告警	Heap 使用率 > 85%、FGC 次数突增	内存泄漏、流量突增、缓存失控

10.2 排查工具箱

10.2.1 命令行工具（适合快速止血）

命令	场景	输出重点
`jps -lvm`	找到 Java 进程 PID	主类名、启动参数
`jstat -gcutil <pid> 1000`	实时监控 GC 与内存	S0/S1/E/O/M 各区使用率、YGC/FGC 次数
`jmap -heap <pid>`	查看堆配置与概览	新生代/老年代大小、收集器
`jmap -histo <pid>`	查看对象直方图	哪个类实例数/占用最多
`jmap -dump:format=b,file=... <pid>`	生成堆 dump	配合 MAT / JProfiler 分析
`jstack <pid>`	打印线程栈	死锁、CPU 热点线程、Blocked 线程
`jcmd <pid> VM.native_memory summary`	查看 Native Memory Tracking	堆外内存、Metaspace、Symbol 区占用

10.2.2 可视化 / 专业工具

工具	适用场景	特点
MAT (Eclipse Memory Analyzer)	分析堆 dump	大对象、内存泄漏、支配树、Leak Suspects
JProfiler / YourKit	全链路 JVM 分析	CPU、内存、线程、GC 一体化
async-profiler	生产环境火焰图	低开销，适合线上持续采样
GCViewer / GCEasy	解析 GC 日志	可视化 GC 事件、停顿分布
Prometheus + Grafana	长期监控与告警	自定义 JVM 指标大盘
Arthas	线上实时诊断	无需重启，支持 trace、watch、thread、heapdump

10.3 典型问题排查流程

场景 1：CPU 飙升

# 1. 找到 CPU 占用最高的线程
ps -mp <pid> -o THREAD,tid,time | sort -rn

# 2. 把 tid 转成十六进制
printf "%x\n" <tid>

# 3. 用 jstack 查看对应线程栈
jstack <pid> | grep -A 30 <hex_tid>

常见根因：

死循环或复杂正则
Young GC 过于频繁
JIT 编译器 C2 线程忙碌（启动期正常）
大量 ThreadLocal 未清理

场景 2：内存持续增长 / OOM

# 1. 确认哪个区域增长
jstat -gcutil <pid> 1000

# 2. 开启 Native Memory Tracking
jcmd <pid> VM.native_memory baseline
jcmd <pid> VM.native_memory summary.diff

# 3. 触发堆 dump（若还能响应）
jmap -dump:live,format=b,file=/tmp/heap.hprof <pid>

常见根因：

堆：缓存无淘汰、大对象、集合只增不减
Metaspace：动态代理/CGLIB 类加载器泄漏
堆外：Netty ByteBuf 未释放、NIO DirectBuffer 堆积

场景 3：接口偶发卡顿 / P99 高

打开 GC 日志，看是否有 长停顿。
用 jstack 抓取卡顿时刻线程栈，看是否有大量 BLOCKED。
用 async-profiler 采集 CPU 火焰图，定位热点方法。
检查是否有 System.gc()、Metaspace 扩容、类加载抖动。

10.4 JVM 监控告警建议

建议把以下指标接入 Prometheus + Grafana，并设置合理阈值：

指标	告警阈值建议	说明
`jvm_memory_used_bytes / jvm_memory_max_bytes`	> 85%	堆/非堆内存使用率
`jvm_gc_pause_seconds_sum`	P99 > 200ms	GC 停顿时间
`jvm_gc_memory_allocated_bytes_total` 增长率	突增 2 倍以上	对象分配速率异常
`jvm_classes_loaded_total`	持续增长	类泄漏嫌疑
`process_cpu_usage`	> 80% 持续 5min	CPU 压力
`jvm_threads_live`	突增或接近上限	线程泄漏
容器维度 `container_memory_working_set_bytes`	> 90% limit	容器 OOMKilled 预警

graph LR
    A[应用埋点] -->|Micrometer| B[Prometheus]
    C[GC 日志] -->|Loki / Filebeat| D[日志平台]
    B --> E[Grafana 大盘]
    D --> E
    E -->|阈值触发| F[AlertManager]
    F -->|通知| G[钉钉/企业微信/Slack]

十一、不同场景的 JVM 配置策略

11.1 配置前的通用原则

先压测，再调优：没有真实流量数据，调参都是拍脑袋。
Xms = Xmx：避免运行时堆扩容带来的 GC 抖动。
Metaspace 必须设上限：容器环境下尤其重要。
GC 日志一定要开：-Xlog:gc*（JDK 9+）成本很低，信息无价。
容器环境开启 Container Support：-XX:+UseContainerSupport（JDK 8u191+/10+ 默认开启）。
不要堆内存无限大：超过 32GB 指针压缩失效，性价比骤降。

11.2 场景一：高并发 Web / API 服务

特征：QPS 高、对象生命周期短、响应延迟敏感。

目标：降低 GC 停顿、控制 P99。

推荐配置（JDK 17-22，G1）：

java \
  -Xms4g -Xmx4g \
  -XX:MetaspaceSize=256m \
  -XX:MaxMetaspaceSize=512m \
  -XX:+UseG1GC \
  -XX:MaxGCPauseMillis=100 \
  -XX:InitiatingHeapOccupancyPercent=35 \
  -XX:+AlwaysPreTouch \
  -XX:+DisableExplicitGC \
  -XX:+HeapDumpOnOutOfMemoryError \
  -XX:HeapDumpPath=/var/log/app/heapdump.hprof \
  -Xlog:gc*:file=/var/log/app/gc.log:time,uptime,level,tags:filecount=10,filesize=100m \
  -jar app.jar

推荐配置（JDK 23+，默认分代 ZGC）：

java \
  -Xms4g -Xmx4g \
  -XX:MetaspaceSize=256m \
  -XX:MaxMetaspaceSize=512m \
  -XX:+AlwaysPreTouch \
  -XX:+DisableExplicitGC \
  -XX:+HeapDumpOnOutOfMemoryError \
  -XX:HeapDumpPath=/var/log/app/heapdump.hprof \
  -Xlog:gc*:file=/var/log/app/gc.log:time,uptime,level,tags:filecount=10,filesize=100m \
  -jar app.jar

调优要点：

新生代尽量大，让短生命周期对象在 Young GC 回收。
-XX:MaxGCPauseMillis 根据业务容忍度设置，100-200ms 常见。
监控 jvm_gc_pause_seconds_sum，若频繁触发 Mixed GC，考虑增大 -XX:InitiatingHeapOccupancyPercent。

11.3 场景二：高流量 / 削峰填谷（消息队列消费者）

特征：突发流量、消息处理批量化、吞吐优先、允许一定延迟。

目标：提高吞吐，避免 OOM 和 Full GC。

推荐配置：

java \
  -Xms8g -Xmx8g \
  -XX:MetaspaceSize=256m \
  -XX:MaxMetaspaceSize=512m \
  -XX:+UseG1GC \
  -XX:MaxGCPauseMillis=300 \
  -XX:G1HeapRegionSize=16m \
  -XX:InitiatingHeapOccupancyPercent=40 \
  -XX:+AlwaysPreTouch \
  -XX:+DisableExplicitGC \
  -XX:+HeapDumpOnOutOfMemoryError \
  -XX:HeapDumpPath=/var/log/app/heapdump.hprof \
  -Xlog:gc*:file=/var/log/app/gc.log:time,uptime,level,tags:filecount=10,filesize=100m \
  -jar consumer.jar

调优要点：

堆可以比 Web 服务稍大，因为要缓冲突发消息。
批量消费时注意控制单次拉取消息数，避免一次创建过多对象。
如果业务允许更高延迟，可考虑 -XX:+UseParallelGC 追求极致吞吐。

11.4 场景三：低延迟金融 / 交易 / 实时推荐

特征：P99 要求 < 10ms，任何 GC 停顿都可能导致业务损失。

目标：亚毫秒级 GC 停顿。

推荐配置（JDK 21+）：

java \
  -Xms16g -Xmx16g \
  -XX:MetaspaceSize=256m \
  -XX:MaxMetaspaceSize=512m \
  -XX:+UseZGC \
  -XX:+ZGenerational \
  -XX:+AlwaysPreTouch \
  -XX:+DisableExplicitGC \
  -XX:+HeapDumpOnOutOfMemoryError \
  -XX:HeapDumpPath=/var/log/app/heapdump.hprof \
  -Xlog:gc*:file=/var/log/app/gc.log:time,uptime,level,tags:filecount=10,filesize=100m \
  -jar trading.jar

JDK 23+ 可简化为（默认就是分代 ZGC）：

java \
  -Xms16g -Xmx16g \
  -XX:MetaspaceSize=256m \
  -XX:MaxMetaspaceSize=512m \
  -XX:+AlwaysPreTouch \
  -XX:+DisableExplicitGC \
  -XX:+HeapDumpOnOutOfMemoryError \
  -XX:HeapDumpPath=/var/log/app/heapdump.hprof \
  -Xlog:gc*:file=/var/log/app/gc.log:time,uptime,level,tags:filecount=10,filesize=100m \
  -jar trading.jar

调优要点：

堆 > 16GB 时 ZGC 优势更明显。
避免大对象（Humongous），ZGC 对大对象分配路径不如小对象高效。
监控 jvm_gc_pause_seconds_max，正常应在 1ms 以内。

11.5 场景四：大数据 / 批处理 / ETL

特征：长时间运行、对象存活久、吞吐优先、延迟不敏感。

目标：最大化吞吐，减少总 GC 时间。

推荐配置：

java \
  -Xms16g -Xmx16g \
  -XX:MetaspaceSize=512m \
  -XX:MaxMetaspaceSize=1g \
  -XX:+UseParallelGC \
  -XX:ParallelGCThreads=8 \
  -XX:+UseLargePages \
  -XX:+AlwaysPreTouch \
  -XX:+DisableExplicitGC \
  -XX:+HeapDumpOnOutOfMemoryError \
  -XX:HeapDumpPath=/var/log/app/heapdump.hprof \
  -Xlog:gc*:file=/var/log/app/gc.log:time,uptime,level,tags:filecount=10,filesize=100m \
  -jar etl.jar

调优要点：

Parallel GC 在纯吞吐场景下通常优于 G1。
大堆 + 大页（LargePages）减少 TLB miss。
如果批处理任务会频繁 Full GC，考虑分阶段释放引用或使用堆外缓存。

11.6 场景五：容器 / K8s 微服务

特征：资源受限、弹性伸缩、多实例共享节点。

目标：稳定、不 OOMKilled、启动快。

推荐配置：

java \
  -XX:+UseContainerSupport \
  -XX:InitialRAMPercentage=70.0 \
  -XX:MaxRAMPercentage=70.0 \
  -XX:MetaspaceSize=128m \
  -XX:MaxMetaspaceSize=256m \
  -XX:+UseG1GC \
  -XX:MaxGCPauseMillis=200 \
  -XX:+AlwaysPreTouch \
  -XX:+DisableExplicitGC \
  -XX:+HeapDumpOnOutOfMemoryError \
  -XX:HeapDumpPath=/var/log/app/heapdump.hprof \
  -Xlog:gc*:file=/var/log/app/gc.log:time,uptime,level,tags:filecount=5,filesize=50m \
  -jar service.jar

调优要点：

用 -XX:MaxRAMPercentage 替代固定 -Xmx，适配不同 Limit。
容器 memory limit 要预留 10%-20% 给堆外内存、Metaspace、线程栈、JVM 自身。
不要把 -Xmx 设成容器 limit 的 100%，否则容易被 OOMKilled。
JDK 23+ 在容器里可直接用默认分代 ZGC。

11.7 场景六：Spring Boot / 微服务网关

特征：启动时大量类加载、反射多、动态代理多。

目标：启动快 + 运行稳。

推荐配置：

java \
  -Xms2g -Xmx2g \
  -XX:MetaspaceSize=256m \
  -XX:MaxMetaspaceSize=512m \
  -XX:+UseG1GC \
  -XX:MaxGCPauseMillis=150 \
  -XX:+AlwaysPreTouch \
  -XX:+DisableExplicitGC \
  -XX:+HeapDumpOnOutOfMemoryError \
  -XX:HeapDumpPath=/var/log/app/heapdump.hprof \
  -Dspring.backgroundpreinitializer.ignore=true \
  -jar gateway.jar

调优要点：

Spring Boot 启动时 Metaspace 会快速上涨，初始值不要设太小。
如果启动慢，可用 -XX:+TieredCompilation 配合 -XX:TieredStopAtLevel=1 加速启动（牺牲峰值性能）。
网关避免在请求路径创建大对象，优先复用对象和缓冲区。

十二、一句话总结

内存：堆内分代、堆外 Direct、Metaspace 存类元数据；虚拟线程栈帧在堆中。
GC：Serial → Parallel → CMS → G1 → 分代 ZGC；JDK 21 分代 ZGC 正式发布，JDK 23 起成为默认 GC。
引用：强 > 软 > 弱 > 虚，缓存别滥用软引用。
性能：JDK 17-22 优先 G1；JDK 23+ 默认分代 ZGC；延迟极致用 ZGC，吞吐优先用 Parallel。
排查：监控先行 → 日志定位 → 工具分析 → 压测验证 → 持续观察。
场景：Web 服务控延迟、消息队列保吞吐、金融交易用 ZGC、批处理用 Parallel、容器环境留余量。

JVM 调优没有银弹，但有方法论：理解数据区 → 选对收集器 → 设定合理目标 → 用日志验证 → 持续监控。把这套流程跑熟，面试八股和线上救火就都不慌了。

参考

《深入理解 Java 虚拟机》（第三版）周志明
OpenJDK HotSpot Virtual Machine Garbage Collection Tuning Guide
JEP 333: ZGC
JEP 439: Generational ZGC
JEP 474: ZGC Generational Mode by Default
JEP 490: Remove the Non-Generational ZGC Mode
JEP 404: Generational Shenandoah (Experimental)
JEP 444: Virtual Threads
JEP 454: Foreign Function & Memory API
Project Lilliput

JAVA on 方糖猫Blog

Netflix 用 JDK Vector API 优化推荐系统：一次教科书级的性能工程实录

Netflix 用 JDK Vector API 优化推荐系统：一次教科书级的性能工程实录

一、背景：Ranker 里的 7.5% 热点

二、第一步：把嵌套循环看成矩阵乘

三、第二步：批处理反而慢了 5%

四、第三步：扁平 buffer 加 ThreadLocal 复用

五、第四步：BLAS——测试里很好，生产里不行

六、第五步：JDK Vector API

先补一课：JDK Vector API 到底是什么

七、回退与安全：孵化特性的生产姿势

八、生产结果

工程实践联想

本篇小结

参考资料

我开发的keCache：面向 Spring Boot 3 的 L1 + L2 两级缓存框架

一、keCache 是什么

1.1 整体架构

二、开源地址

三、为什么需要 keCache？与纯 Redis / 纯 Caffeine 的对比

3.1 相比纯 Caffeine 的好处

3.2 相比纯 Redis 的好处

3.3 方案选型速查

3.4 一句话总结

四、核心能力速览

4.1 读取流程

4.2 写入与集群失效广播流程

五、快速开始

5.1 引入 Starter

5.2 启用缓存

5.3 基础配置

5.4 声明式使用示例

5.5 编程式使用

六、模块结构

七、关键约定（写代码前必读）

八、使用注意点与避坑指南

8.1 Redis 是硬性依赖

8.2 集群一致性是“最终一致”，不是实时一致

8.3 空值保护是把双刃剑

8.4 序列化类型变更要兼容

8.5 注意 Key 的命名空间隔离

8.6 @LocalCacheable.Multi 的 result 引用要判空

8.7 AOP 自调用不会生效

8.8 谨慎使用 @LocalCacheClear

8.9 校准任务不是开箱即用的

8.10 当前 Redis 部署模式限制

8.11 关注 Caffeine 内存与统计

九、许可证

十、总结

我开发的KE Reliable Executor：基于 Redis/MySQL 的 Spring Boot 可靠任务执行框架

我开发的KE Reliable Executor：基于 Redis/MySQL 的 Spring Boot 可靠任务执行框架

一、为什么需要这个工具？

适合什么场景？

不适合什么场景？

二、与竞品的对比

2.1 与 Kafka / RocketMQ 对比

2.2 与 Spring @Scheduled + 数据库轮询对比

2.3 与 XXL-JOB / PowerJob 对比

三、整体架构

3.1 模块解构图

3.2 两层锁模型

3.3 队列设计

3.4 任务状态机

四、核心设计要点

4.1 Lua 原子转移

4.2 Double-Check

4.3 双存储后端

五、快速开始

5.1 引入依赖

5.2 配置

5.3 定义处理器

5.4 提交任务

5.5 监听生命周期

六、使用注意点与避坑指南

6.1 业务幂等仍然是最后一道防线

6.2 taskId 需要业务保证唯一

6.3 重试间隔与最大时长的权衡

6.4 MySQL 分支需要自行引入 JPA

6.5 Redis 集群环境注意 Key 前缀

6.6 线程池队列满载时会跳过调度

8.6 `@LocalCacheable.Multi` 的 `result` 引用要判空

8.8 谨慎使用 `@LocalCacheClear`

2.2 与 Spring `@Scheduled` + 数据库轮询对比