Vector API 能显著加速矩阵运算，但需启用孵化器模块、确保 JVM 加载并生成 SIMD 指令，使用 SPECIES_PREFERRED 动态适配硬件宽度，配合一维连续内存、分块点积与边界处理，否则易退化为标量循环。
Vector API 能显著加速大规模矩阵运算，但前提是代码写法匹配硬件向量化能力，且 JVM 运行时能真正生成 SIMD 指令——不是所有 FloatVector 调用都会被向量化，很多情况会退化为标量循环。
必须启用孵化器模块并确认 JVM 实际加载
Vector API 仍在孵化阶段（JDK 16+），不加参数就 import 会编译失败，运行时没加载模块则抛 NoClassDefFoundError 或静默退化为标量执行。
- 编译时加：
javac --add-modules jdk.incubator.vector YourClass.java - 运行时加：
java --add-modules jdk.incubator.vector YourClass - 验证是否生效：在代码中打印
FloatVector.SPECIES_PREFERRED，若输出类似FloatVector@256（而非@1）说明已识别 AVX/SSE 宽度；若为@1，代表未启用或 CPU 不支持，此时所有操作都是伪向量、无加速
矩阵乘法不能直接用 mul() 替换三重循环
FloatVector.mul() 是逐元素相乘，而矩阵乘法 C[i][j] = Σ A[i][k] × B[k][j] 需要的是行×列的点积（dot product），必须手动组织数据布局和累加逻辑。
- 一维数组存储更利于向量化：避免二维数组
A[i][k]的指针跳转，改用A[i * n + k]连续内存访问 - 关键操作是分块点积：对每组长度为
SPECIES.length()的 A 行片段和 B 列片段，调用va.mul(vb).reduceLanes(VectorOperators.ADD)得到部分和 - 必须显式处理边界：若矩阵维度不能被
SPECIES.length()整除，尾部要用标量循环补全，否则越界或漏算
SPECIES_PREFERRED 不等于固定宽度，不同 CPU 返回值差异极大
同一段代码在不同机器上可能走完全不同路径：Intel Xeon 支持 AVX-512 时返回 @512（16 个 float），而旧款 i5 可能只返回 @128（4 个 float），甚至 ARM64 设备返回 @128 或 @256。这直接影响循环步长和性能拐点。
- 不要硬编码
FloatVector.SPECIES_256：它在不支持 AVX2 的机器上会抛UnsupportedOperationException - 用
SPECIES_PREFERRED并适配循环逻辑：步长必须是SPECIES.length()，不能假设为 8 或 16 - 性能敏感场景建议预热+探测：启动时跑一次小规模测试，记录实际生效的
SPECIES宽度，后续按此分块
内存对齐与缓存局部性比向量化本身更容易成为瓶颈
即使 mul() 和 reduceLanes() 全部编译为 AVX 指令，若数据跨 cache line 分布、或 A/B 矩阵访问模式导致 TLB miss 频繁，速度可能反不如优化过的标量循环。
- 优先使用堆外内存或
ByteBuffer.allocateDirect()：减少 GC 干扰，提升地址连续性 - 避免随机访存：B 矩阵应按列优先（column-major）存储，或提前转置为行优先再参与计算，否则每次取 B[k][j] 都是跨步访问
- 分块（tiling）仍是刚需：单纯靠 Vector API 不解决 L2/L3 缓存复用问题，需配合 16×16 或 32×32 的分块策略，让子矩阵尽可能驻留 cache
真正决定加速比的，从来不是“用了 Vector API”，而是你是否让数据流动路径匹配了 SIMD 寄存器宽度、CPU cache 层级和内存控制器带宽——这些细节一旦错位，向量化反而增加指令开销。
