Java负责写业务逻辑，Go负责跑性能关键路径，FFM负责当“婚姻介绍所”
2015年，Backblaze公司高调开源了他们的 JavaReedSolomon库，宣称这是“第一个可用于生产的Java实现”。这话听起来像极了某位程序员在相亲时说：“我虽然工资不高，但至少稳定。”——稳定是稳定，可速度？那真是一言难尽。
他们用Reed-Solomon算法来对抗数据丢失，原理嘛，简单粗暴：把一段数据切成若干“数据块”，再算出几个“校验块”。万一硬盘坏了几个块，只要剩下的够多，就能像拼图一样复原。听起来很聪明，对吧？毕竟比起直接三副本复制，这能省下不少硬盘钱——Backblaze省下的可都是真金白银。
但问题是，他们的Java实现，跑在一台M1 Max的MacBook Pro上，速度只有1000 MB/s。什么概念？这速度还不如我老家那台十年前的机械硬盘在梦里跑得快。而与此同时，SSD已经飙到了15,000 MB/s，现代哈希函数更是轻松突破40,000 MB/s。相比之下，JavaReedSolomon就像个穿着拖鞋参加百米赛跑的选手，还在认真系鞋带。
你说Java不行？不，问题不在语言本身，而在——它太“文明”了。它讲究GC、讲究内存安全、讲究优雅抽象，却忘了在高性能计算的世界里，谁不玩SIMD，谁就是原始人。
就在这时，一个叫Klaus Post的丹麦程序员，默默用Go语言重写了Reed-Solomon（ Go reimplementation!）。他没搞什么花里胡哨的设计模式，也没写一堆单元测试文档，而是直接掏出NEON、AVX、AVX512、SVE这些现代CPU的“核武器”，用汇编级别的优化，把算法塞进了向量寄存器里。
结果呢？
12,222 MB/s，12倍于Java！
10MB大块数据下更是飙到47,178 MB/s，47倍！
这哪是优化，这简直是拿火箭推进器改装自行车。
你可能会问：Go真的比Java快这么多？不，真相更讽刺——Go本身并不快，是Klaus Post的汇编代码快。他写的Go代码里，核心部分全是手写的SIMD汇编，专为现代CPU设计。而Java这边，还在用“for循环”一步步算伽罗瓦域乘法，仿佛在用算盘挑战超级计算机。
更讽刺的是，当你把Go的汇编优化关掉（-tags noasm），让它老老实实跑纯Go代码，速度立刻跌回680 MB/s，甚至比Java还慢。而JavaReedSolomon在多线程下，居然反超了“无汇编Go”——这简直是编程界的“龟兔赛跑”现实版：Go这只兔子一觉醒来，发现乌龟已经冲过终点，还顺便发了个朋友圈。
作为一个Java程序员，看到这一幕，内心是崩溃的。你想优化？可你不懂SIMD。你想学AVX-512？可你连伽罗瓦域是啥都解释不清。你甚至不知道_mm256_mullo_epi32是干嘛的，只知道它看起来像某种神秘咒语。
于是，你只能低头，向Go求援。不是“学习”，而是“乞讨”——能不能让我用你的汇编快车道，但继续写Java？
答案是：能，但方式极其荒诞。
你得把Go代码编译成一个动态库（.so / .dylib），然后通过JNI或更现代的Foreign Function & Memory API（FFM），从Java里调用它。这就像你不会做饭，但你家隔壁有个米其林大厨，于是你每天端着锅去他家灶上炒两下，再端回自己家吃。
更荒诞的是，Go默认不支持C风格的动态库导出，你得加个import "C"，再用//export注解标记函数，还得写一堆“胶水代码”把Go的切片转成C的指针数组。整个过程就像在用乐高积木拼一台F1赛车——理论上可行，但每一步都让你怀疑人生。
FFM登场，Java终于“现代化”了一回
好在，2025年的Java 24终于把FFM从“预览功能”转正了。这意味着你不用再写恶心的JNI胶水代码，而是可以用jextract工具，自动生成Java端的绑定类。这就像终于有了个翻译器，不用再用手比划着点菜。
你只需要一个头文件（Go生成的libjagors.h），jextract就能给你生成MemorySegment版的接口。然后你就可以在Java里像调用普通方法一样，传一个MemorySegment进去，Go那边自动转成unsafe.Pointer，再用指针算术切成一个个数据块。
整个过程行云流水，仿佛语言之间的高墙终于被推倒。但实际上，你只是把“语言互操作”的复杂性，从程序员的脑子里，转移到了JVM和Go运行时的底层调度中。而这两者，一个用GC管理内存，一个用Goroutine调度线程——它们能和平共处，纯属奇迹。
性能测试——Java的“虚假胜利”与Go的“调度暴政”
你以为调用Go代码就万事大吉？不，更大的坑在等着你。
你跑基准测试，发现单线程Java调用Go，速度居然达到了26,867 MB/s，比原生Go还快！你正准备发朋友圈炫耀，结果一查CPU，发现Go调度器偷偷开了10个核心并行跑！而你的Java代码明明只用了一个线程。
这就像你雇了个工人搬砖，结果他私自找了9个兄弟一起干，工程提前完工，但工资还是只付一份。Go的runtime.GOMAXPROCS默认启用所有核心，根本不管你Java这边是不是单线程调用。
于是你只能加个jagors_set_maxprocs(1)，手动把Go调度器锁死在单核。这下公平了，速度也降回合理范围：200KB数据下11532 MB/s，10MB下8959 MB/s——依然是Java的10倍以上。
但更离谱的是，当你把Java线程开到100，Go调度器放开，速度居然冲到59,920 MB/s！这说明：Java的瓶颈从来不是语言，而是它不敢“野蛮”。而Go，只要你不拦它，它就能榨干每一颗CPU核心。
最终数据出炉：
- 单线程Java调用Go汇编：比原生Java快11倍（200KB），9倍（10MB）
- 全核并行：快7.6倍和6.9倍
- Java单线程 + Go多线程：快26倍和53倍
最高速度甚至达到95,000 MB/s，接近内存带宽极限。
所以，我们成功了？
是的。但我们成功的是什么？是Java的胜利吗？不，是Go的胜利？
是汇编的胜利。
是放弃抽象、拥抱硬件的胜利。
Java程序员终于可以自豪地说：“我们的Reed-Solomon现在很快！”——前提是，我们偷偷用了Go写的汇编代码，并通过FFM“借壳上市”。
这就像一个素食主义者，为了补充蛋白质，开始偷偷吃牛肉，还对外宣称：“我这是植物基蛋白提取物。”
尾声：未来的希望？Java Vector API 能救场吗？
文章最后提到了Java Vector API，说它未来可能摆脱“孵化”状态，提供可移植的SIMD支持。这听起来很美好，但现实很骨感——目前的Vector API连Klaus Post的手写汇编的零头都追不上。
而且，谁能保证JVM的自动向量化，能比得上人类高手的手动调优？就像自动驾驶再厉害，也未必敢在F1赛道上和舒马赫比弯道。
所以，这场“语言战争”的结局或许是：
Java负责写业务逻辑，Go负责跑性能关键路径，FFM负责当“婚姻介绍所”。
代码都在：in this repository.