Skip to main content

JEP 537：Vector API（第十二次孵化）

引言​

现代 CPU 里藏着一种被 Java 开发者长期"看得见、摸不着"的能力：向量运算。硬件明明能一条指令处理一整批数据，可 Java 却一直只能祈祷 JIT 编译器帮你用上它。JEP 537 的 Vector API，把这份控制权第一次交到了开发者手里——让你可以显式、可移植地写出 SIMD 代码。

为什么需要向量 API​

现代 CPU 都配备了宽向量寄存器（wide vector registers），可以在一条指令里同时处理好几个数据——这就是所谓的 SIMD（单指令多数据）。它是数值密集型代码性能的关键。

但对 Java 开发者来说，这份能力一直是间接的、难以掌控的：

  • 现代 CPU 用宽寄存器计算，一条指令处理多个"通道"（lane）。
  • HotSpot 有自动向量化（auto-vectorisation）——它会尝试自动识别你的循环，把它编译成向量指令。这确实有用，但前提是它认得出这个循环。
  • 问题在于自动向量化非常脆弱。循环里一点看似无关的小改动——多加一个条件、换一种写法——都可能让向量化悄无声息地失效，性能瞬间掉一半，而编译器不会给你任何警告。你甚至不知道自己丢了性能。
  • 归根结底，**数值代码此前没有任何办法，显式地、可移植地要求"我就是要用 SIMD"。**你只能被动依赖 JIT 的心情。

编程模型​

Vector API 的核心设计目标之一，是可移植性——你写的代码不需要知道底层硬件的向量宽度到底是多少。

  • **Vector<E> 的值按 species 分组。**所谓 species，就是"元素类型 + 向量形状"的组合。通过这个抽象，同一段代码可以在 128 位的 ARM NEON 和 512 位的 AVX-512 上都跑出最佳性能——它会自动适配当前硬件的向量宽度。
  • API 提供了完整的按通道（lane-wise）操作：算术、比较、shuffle（重排）、归约（reduction）以及掩码（mask）操作。
  • **掩码机制让"不足一整个向量"和"循环尾部"成为一等公民。**当数组长度不是向量宽度的整数倍时，掩码优雅地处理了那些剩余的、凑不满一个向量的元素——这类边界情况过去总是让手写 SIMD 变得棘手。
  • 最终，这套代码在支持的平台上会被编译成对应的硬件向量指令，拿到真正的原生性能。

代码示例：向量化数组相加​

static final VectorSpecies<Float> SPECIES =
    FloatVector.SPECIES_PREFERRED;

void addArrays(float[] a, float[] b, float[] c) {
    int i = 0;
    for (; i < SPECIES.loopBound(a.length);
         i += SPECIES.length()) {
        var va = FloatVector.fromArray(SPECIES, a, i);
        var vb = FloatVector.fromArray(SPECIES, b, i);
        va.add(vb).intoArray(c, i);
    }
    // scalar tail
    for (; i < a.length; i++) c[i] = a[i] + b[i];
}

这个例子把两个数组逐元素相加。注意主循环里的每一步，处理的是一整个向量的数据（SPECIES.length() 个元素），而不是单个浮点数。SPECIES.loopBound() 算出能被向量宽度整除的边界，主循环处理到这里为止；剩下凑不满一整个向量的元素，由后面的**标量尾循环（scalar tail）**兜底，保证一个都不遗漏。

这段代码在任何支持的平台上，都会被编译成原生的向量指令——SPECIES_PREFERRED 保证它总是选用当前硬件最合适的向量宽度。

前后对比​

标量循环（scalar loop）：

  • 源码里每次迭代只处理一个元素。
  • 性能完全取决于 JIT 能否识别出这个循环的形状。
  • 一次无关的重构，就可能让性能悄悄变样。

Vector API：

  • **向量化的意图，直接写在代码里。**你不是在祈祷 JIT 领会你的意思，而是明确告诉它"这里要向量化"。
  • 同一套代码可以适配不同硬件的向量形状。
  • **跨硬件的表现更可预期。**性能不再是碰运气。

一句话：标量循环把向量化的决定权交给了 JIT，而 Vector API 把意图写进了源码。你不会因为一次看似无关的重构，就莫名其妙地丢掉 SIMD 加速。

什么场景最划算​

Vector API 的"甜区"，在于那些密集处理大量原始类型数据的场景：

  • 线性代数、信号处理与图像流水线。
  • 机器学习推理内核与向量嵌入（embedding）计算。
  • 密码学、压缩与校验和（checksum）。
  • 扫描大型原始类型数组的列式（columnar）分析。

这些领域有一个共同点：热循环里跑的是海量数值计算。Vector API 让你可以直接用 Java 表达这类计算，再由运行时映射到受支持的硬件指令。

仍在孵化中​

你可能会疑惑：都第十二次孵化了，为什么还不"转正"？

答案是 Project Valhalla。

  • 这是第十二次孵化——注意，它是一个孵化（incubator）API，而非预览（preview）API。使用时需要 --add-modules jdk.incubator.vector。
  • 团队刻意让它一直等着 Project Valhalla 的值类型（value types）落地。当前的 Vector API 为了绕开装箱（boxing）和对象分配，做了一系列妥协；而值类型有望让这套 API 彻底摆脱这些妥协，获得干净、零开销的抽象。
  • 团队宁可等到能把它做对，也不愿意仓促定型一个带着先天缺陷的 API。这份耐心，正是它迟迟不转正的原因。

结论​

Vector API 让 Java 开发者第一次可以显式、可移植地控制 SIMD——写出向量代码，而不是祈祷 JIT 看得懂。虽然它还在孵化中，静静等着 Valhalla 的值类型，但它的编程模型今天就已经可以用了。对那些真正吃性能的数值负载来说，这是一个值得现在就去了解和尝试的工具。