搜索客，搜索人自己的社区

Easysearch BKD Merge 异常排查实录：最终定位到旧版 GraalVM JIT 运行时

Easysearch • INFINI Labs 小助手发表了文章 • 0 个评论 • 10 次浏览 • 27 分钟前 • 来自相关话题

最近一次高并发写入压测中，我们遇到了一个非常诡异的 BKD merge 崩溃。从报错看，很像 Easysearch 2.1.2 在 merge 阶段把 segment 读成了错误状态。典型错误是这样的：

text java.lang.ArrayIndexOutOfBoundsException: Index -3 out of bounds for length 8 java.lang.ArrayIndexOutOfBoundsException: Index -4 out of bounds for length 8 

异常栈最终落在 Lucene BKD 相关路径上：

BKDReader.readNodeData()
BKDWriter.merge()
Lucene90PointsWriter.merge()

如果只看栈，很容易把问题归到 Easysearch 的 BKD merge 逻辑。但排查到最后，结论恰恰相反。

问题不在 Easysearch 的代码，而在 JDK 运行时。 更精确地说，是某个特定 Oracle GraalVM 21 构建中的 JVMCI/Graal JIT 路径，把 Lucene BKD 的热点代码执行错了。

1、为什么这个问题难查

它有几个特别迷惑人的特征：
只在高并发写入压测下触发
服务重启后的前几轮最容易复现
同一进程里，删了索引重新压，后面复现率反而下降
不是固定字段，多个数字类型字段都中过招
ZSTD 和 best_compression 两种 codec 下都能复现

实际命中过的字段包括 @timestamp、size、status、_seq_no。所以这不是某个字段、某种 codec 或某个 mapping 的偶发问题。

2、第一层排除：merge reader 不是第一现场

一开始我们确实怀疑 merge reader，毕竟异常直接出现在 merge 路径上。但日志顺序很快给出了相反的证据。在 merge 真正崩溃之前，source segment 已经先出现了这些异常信号：
1. point-sort-restore-multiple-zero-ords
2. source-write-point-doc-mismatch
3. pointCount > docCount
4. pack-index-negative-code
5. reader-invalid-start-pos
6. 最后才是 ArrayIndexOutOfBoundsException
  
  这意味着两件事：merge reader 不是第一现场，source segment 在写出阶段就已经坏了。merge reader 只是读到了已经损坏的 BKD index，并在那个阶段暴露了异常。
  
  3、第二层排除：Easysearch 自己的 BKD 写入逻辑也没有先出错
  
  继续往前追溯，我们发现问题比 OneDimensionBKDWriter.add() 还要早。真正的异常出现在排序/回填链路上：
PointValuesWriter
MutablePointTreeReaderUtils.sort()
StableMSBRadixSorter

关键证据来自两个探针：
point-sort-restore-multiple-zero-ords
unwrittenSlotCount == source-write-point-doc-mismatch delta

这说明在某次排序/回填过程中，有一部分槽位根本没有被写入，默认值 0 被 restore 回填到 ords[]，再通过 docIDs[0] 放大成大量 docID=0，最终导致 pointCount > docCount，source segment 进入错误状态。

到这一步，排查重点已经不是“Easysearch 的 BKD merge 逻辑存在缺陷”，而是 Lucene points 排序链路的执行结果和源码语义不一致。

4、真正的转折点：抓到了 reorder() 自身的 coverage 异常

真正把方向扭转过来的，不是又一次复现，而是一个更早的探针：
point-sort-reorder-coverage-mismatch

这个探针验证的是：StableMSBRadixSorter.reorder() 是否真的按源码应有的次数完整执行。

我们抓到的典型样本之一如下：
targetSegment=_x
field=status
k=7
expectedLoopCount=9800
actualIterationCount=8204
firstCoverageMismatchBucket=201
firstCoverageExpected=9788
firstCoverageActual=8192

更关键的是，同一条日志里还带出了这个信息：

text skippedSourceSamples=[201:[{ord=8192,bucket=201,docID=9090,byteAtK=200}, ...]] 

这条信息非常重要，因为它说明：bucket 201 理论上应该处理 9788 条，实际只处理了前 8192 条，但从 ord=8192 往后的样本，读出来仍然还是 bucket=201。这直接推翻了“后半段数据被污染后改桶”的旧解释，指向了一个更直接的结论：reorder() 自己的 coverage 被截断了。

另一个样本中出现了同类边界：firstCoverageExpected=31822，firstCoverageActual=16384。

到这里，一个很不自然的特征浮现出来：8192、16384——这些明显的 2 的幂边界，更像是运行时或 JIT 执行异常，而不是普通业务逻辑 bug。

5、哪段代码最可疑

此时怀疑对象已经不是泛泛的“BKD 整体有问题”，而是 Lucene 中的这段热点循环：

java for (int i = 0; i < HISTOGRAM_SIZE; ++i) { final int limit = endOffsets[i]; for (int h1 = fixedStartOffsets[i]; h1 < limit; h1++) { final int b = getBucket(from + h1, k); final int h2 = startOffsets[b]++; save(from + h1, from + h2); } } restore(from, to); 

代码位于 org.apache.lucene.util.StableMSBRadixSorter#reorder(...)。

按源码语义，这段代码应该完整扫描每个 bucket 的范围，并最终把全部结果 restore 回去。但我们抓到的事实是：expectedLoopCount != actualIterationCount，某些 bucket 只跑到 8192 / 16384 就停了，随后出现未写槽位，restore 把默认 0 回填，最终 source segment 进入错误状态。

如果这是 Java 源码本身的稳定逻辑 bug，它在解释执行时也应该稳定触发，而不应该强烈依赖某个 JDK/JIT 组合。后面的 JVM 对照实验基本排除了这个可能性。

6、最强证据：只换 JDK / JIT 路径，结果就变了

这次排查中最有说服力的，不是某一条日志，而是对照实验。

基线组：旧版 Oracle GraalVM 21，默认 JVMCI/Graal JIT

环境：
Oracle GraalVM 21+35.1
21+35-jvmci-23.1-b15
Linux aarch64 / ARM64
UseJVMCICompiler = true

结果：很快复现，命中了 point-sort-reorder-coverage-mismatch、point-sort-reorder-underfilled、point-sort-restore-multiple-zero-ords，随后 merge 报 ArrayIndexOutOfBoundsException: Index -4 out of bounds for length 8。

对照组：关闭 JVMCI/Graal JIT 或纯解释执行

只改 JVM 参数，不改代码和压测口径：
-XX:-UseJVMCICompiler
-Xint

结果一致：都没有再出现上述探针和异常。

这三组对照的意义很直接：如果这是 Easysearch 或 Lucene 的纯 Java 逻辑 bug，解释执行也应该能稳定复现。但现实是基线组复现，关闭 JVMCI 和纯解释执行都不复现。问题显然高度依赖 JIT 路径。

版本对照：较新的 GraalVM 21 构建在当前测试中未复现

这里需要补充一条重要的边界条件。我们后来又测试了一个较新的 GraalVM 版本：

text java version "21.0.9" 2025-10-21 LTS Java(TM) SE Runtime Environment Oracle GraalVM 21.0.9+7.1 (build 21.0.9+7-LTS-jvmci-23.1-b79) 

在当前压测中，这个版本没有再出现 merge 错误。

因此结论必须写得更精确：已知会复现的是较早的 21+35-jvmci-23.1-b15，已知在当前测试中未复现的是较新的 21.0.9+7-LTS-jvmci-23.1-b79。更准确的工程判断不是“GraalVM 21 整体都有问题”，而是某个特定 GraalVM 21 构建有问题，较新的构建很可能已经修复或规避了该问题。这里仍需保持严谨：只能说“在当前压测中未复现”，还不能直接说“已经被完整证明没有问题”。

平台边界：不能写成 ARM 专属

除了前面详细展开的 Linux aarch64 / ARM64 主要实验环境外，有用户反馈在以下环境中也出现过同类问题：
操作系统：openEuler
内核：4.19.90-2112.8.0.0131.oe1.x86_64
架构：x86_64

这是用户的测试环境，不是我们能够独立完整复现并逐项展开的。但这条信息已经足够说明：当前不能把问题简单写成“ARM 平台专属”。更准确的说法是：我们在 ARM64 上系统性复现并完成了主要对照实验，另外也有 openEuler x86_64 测试环境的同类现象反馈，因此平台边界目前还没有被完全钉死。

7、更强的同机对照：换成 Oracle HotSpot 21.0.10 后，全量写入跑完也没有问题

为了进一步排除“是不是所有 Java 21 都会这样”，我们在同一台服务器上把 /infini/easysearch/jdk 从 Oracle GraalVM 21 换成普通 Oracle HotSpot 21.0.10，恢复默认 JVM 参数，用同样的写入压测继续验证。

其中一轮的结果很有说服力：
索引：nginx_zstd3_40mt4
codec：ZSTD
threads=16
bulk_size=1000
target_docs=181463624

最终 after_count=181463624，delta_written=181463624，全量文档写入完成，服务端没有出现任何 BKD merge 错误。

这条结果至少说明：同一台机器、同一套 Easysearch、同样的数据规模和写入模型，只要把 JDK 从 Oracle GraalVM 21 换成 Oracle HotSpot 21.0.10，问题就不再出现。

到这一步，工程判断已经比较清晰了：不是 Easysearch 自身逻辑导致，也不是所有 Oracle JDK 21 都会出错，更像是特定 Oracle GraalVM 21 构建相关的 JVMCI/Graal JIT 路径问题。

8、最关键的外部对照：Elasticsearch 8.19.5 也复现了

如果说前面的结论还能被质疑为“Easysearch 某些实现差异触发的”，那么后面的外部对照基本排除了这个方向。

我们在同一台服务器上部署了 Elasticsearch 8.19.5（Lucene 9.12.2），JDK 也切到相同的 Oracle GraalVM 21，执行同类写入压测。结果 Elasticsearch 也复现了同样的 BKD merge 崩溃。

关键异常完全一致：

text java.lang.ArrayIndexOutOfBoundsException: Index -4 out of bounds for length 8 

栈也一样落在 BKDReader.readNodeData、BKDWriter$MergeReader.collectNextLeaf、BKDWriter$MergeReader.next。

这条证据的力度很强：不是 Easysearch 独有的问题，不是当前这套 Lucene 代码路径独有的问题，Elasticsearch 8.19.5 + Lucene 9.12.2 在同类 GraalVM 21 环境下也会出现同类异常。到这一步，再把问题归因于 Easysearch 本身的代码逻辑，已经缺乏依据了。

9、这次排查最终说明了什么

把整条证据链串起来，当前阶段的结论已经比较清楚。

已验证的事实：
问题不是 merge reader 先制造坏数据，source segment 在更早阶段就已经进入错误状态
不是单字段问题，也不是 ZSTD 或 best_compression 专属
已抓到 StableMSBRadixSorter.reorder() 自身的 coverage 异常
关闭 UseJVMCICompiler 后问题不复现，-Xint 下也不复现
同机切到 Oracle HotSpot 21.0.10 后，Easysearch 全量写入跑完未见 BKD merge 异常
Elasticsearch 8.19.5 + Lucene 9.12.2 在同类 GraalVM 21 环境下也复现
较新的 21.0.9+7-LTS-jvmci-23.1-b79 在当前压测中未复现
某用户的 openEuler x86_64 测试环境中也出现过同类错误，因此不能写成 ARM 专属

工程结论：

从工程证据来看，Easysearch 本身的代码逻辑没有问题。

当前最符合事实的结论是：问题高度相关于特定 Oracle GraalVM 21 构建，更具体地，是该构建相关的 JVMCI/Graal JIT 路径。它把 Lucene BKD 相关热点代码执行到了错误状态。已知较早构建 21+35-jvmci-23.1-b15 可复现，已知较新的 21.0.9+7-LTS-jvmci-23.1-b79 在当前测试中未复现。平台边界目前尚未完全钉死，不能再简单写成仅限 ARM64。

换句话说，这不是“Easysearch 的 BKD merge 实现有 bug”，而是特定 JDK/JIT 运行时把本来正确的 Lucene BKD 代码执行错了。

10、建议版本与规避方案

如果你在生产或测试环境中运行 Easysearch 或 Elasticsearch，并且使用的是某些 Oracle GraalVM 21 构建，且启用了默认的 JVMCI/Graal JIT，那么在高并发写入、频繁 merge、BKD 热点路径被充分打热的场景下，需要特别警惕这类问题。

现阶段比较明确的建议是：
1. 避免继续使用已经验证可复现的旧版构建：Oracle GraalVM 21+35.1 或 21+35-jvmci-23.1-b15
2. 优先升级到当前测试中未复现的版本：Oracle GraalVM 21.0.9+7.1（即 21.0.9+7-LTS-jvmci-23.1-b79）
3. 如果短期内不方便升级 GraalVM，直接切换到普通 Oracle HotSpot 21.0.10
  
  直接落到版本号上会更清晰：
已确认应避开：21+35-jvmci-23.1-b15
当前更推荐：21.0.9+7-LTS-jvmci-23.1-b79

原因很简单：前者我们已经复现了，后者在当前压测中没有复现。当然，这里的“推荐”是基于当前测试结果，不代表上游已经正式确认该问题已被修复。

11、最后

这次排查最大的价值，不是“又复现了一次 BKD merge 崩溃”，而是把一个看起来像 Easysearch 代码 bug 的现象，收敛成了一个有明确边界的运行时问题。

它至少说明两件事：
栈顶报错的位置不一定是真正的第一现场
真正有说服力的不是猜测，而是对照实验

这次结论之所以成立，不是因为主观判断，而是因为我们已经拿到了足够强的工程证据：同机 HotSpot 不复现，关闭 JVMCI 不复现，解释执行不复现，Elasticsearch 也复现，较新的 GraalVM 21.0.9+7.1 在当前测试中未复现，且某用户的 openEuler x86_64 测试环境也出现过同类错误。

所以，这一次，问题确实不在 Easysearch，而在特定版本的 JDK/JIT 运行时。

---

关于 Easysearch

![](https://infinilabs.cn/img/blog ... er.png)

INFINI Easysearch 是一个分布式的搜索型数据库，实现非结构化数据检索、全文检索、向量检索、地理位置信息查询、组合索引查询、多语种支持、聚合分析等。Easysearch 可以完美替代 Elasticsearch，同时添加和完善多项企业级功能。Easysearch 助您拥有简洁、高效、易用的搜索体验。

官网文档：<https://docs.infinilabs.com/easysearch>;

作者：张磊，极限科技（INFINI Labs）搜索引擎研发负责人，对 Elasticsearch 和 Lucene 源码比较熟悉，目前主要负责公司的 Easysearch 产品的研发以及客户服务工作。

---

相关文章：
[Easysearch 国产替代 Elasticsearch：8 大核心问题解读](https://infinilabs.cn/blog/202 ... -8-qa/)
[Elasticsearch VS Easysearch 性能测试](https://infinilabs.cn/blog/202 ... sting/)
[从 Elastic 迁移到 Easysearch 指引](https://infinilabs.cn/blog/202 ... earch/)
[Elasticsearch 磁盘空间异常：一次成功的故障排除案例分享](https://infinilabs.cn/blog/202 ... ormal/)
[Easysearch、Elasticsearch、Amazon OpenSearch 快照兼容对比](https://infinilabs.cn/blog/202 ... earch/)

【搜索客社区日报】第2214期 (2025-04-10）

社区日报 • Fred2000 发表了文章 • 0 个评论 • 253 次浏览 • 7 小时前 • 来自相关话题

【搜索客社区日报】第2213期 (2025-04-09）

社区日报 • Se7en 发表了文章 • 0 个评论 • 546 次浏览 • 19 小时前 • 来自相关话题

【搜索客社区日报】第2212期 (2025-04-08）

社区日报 • kin122 发表了文章 • 0 个评论 • 1249 次浏览 • 2 天前 • 来自相关话题

【搜索客社区日报】第2199期 (2025-03-18）

社区日报 • kin122 发表了文章 • 0 个评论 • 1749 次浏览 • 2 天前 • 来自相关话题

【搜索客社区日报】第 2211 期 (2026-04-07)

社区日报 • God_lockin 发表了文章 • 0 个评论 • 1751 次浏览 • 2 天前 • 来自相关话题

【搜索客社区日报】第2210期 (2026-04-06）

社区日报 • Muses 发表了文章 • 0 个评论 • 2404 次浏览 • 4 天前 • 来自相关话题

【搜索客社区日报】第2209期 (2025-04-01）

社区日报 • kin122 发表了文章 • 0 个评论 • 4720 次浏览 • 2026-04-02 14:36 • 来自相关话题

【搜索客社区日报】第2208期 (2026-03-31）

社区日报 • God_lockin 发表了文章 • 0 个评论 • 6209 次浏览 • 2026-03-31 09:00 • 来自相关话题

【搜索客社区日报】第2207期 (2026-03-30）

社区日报 • Muses 发表了文章 • 0 个评论 • 6689 次浏览 • 2026-03-30 09:42 • 来自相关话题

【搜索客社区日报】第2206期 (2025-03-27）

社区日报 • Fred2000 发表了文章 • 0 个评论 • 8241 次浏览 • 2026-03-27 10:12 • 来自相关话题

【搜索客社区日报】第2205期 (2025-03-26）

社区日报 • Se7en 发表了文章 • 0 个评论 • 8478 次浏览 • 2026-03-26 17:29 • 来自相关话题

【搜索客社区日报】第2204期 (2025-03-25）

社区日报 • kin122 发表了文章 • 0 个评论 • 9031 次浏览 • 2026-03-25 15:30 • 来自相关话题

【搜索客社区日报】第2202期 (2026-03-23）

社区日报 • Muses 发表了文章 • 0 个评论 • 10503 次浏览 • 2026-03-23 09:35 • 来自相关话题

8.1万人告诉我们：人们到底想要什么样的 AI？

AI 搜索 • ai_insider 发表了文章 • 0 个评论 • 12198 次浏览 • 2026-03-20 08:43 • 来自相关话题

来源：Anthropic 官方调研报告《What 81,000 people want from AI》
调研时间：2025年12月
覆盖范围：159个国家、70种语言、80,508名受访者

一、调研背景：为什么做这件事？

关于 AI 的公共讨论往往集中在抽象的风险与收益预测上。但一个关键问题被忽视了：当 AI "发展顺利"时，对普通人来说意味着什么？

Anthropic 在 2025 年 12 月开展了一项大规模定性研究——邀请所有 Claude.ai 用户与 AI 进行深度访谈，谈谈他们对 AI 的期望与担忧。最终有 80,508 人 参与，覆盖 159 个国家、70 种语言。这可能是迄今为止规模最大、语言覆盖最广的 AI 用户研究。

二、人们最想要 AI 做什么？

调研将用户需求归纳为五大类：

| 排名 | 需求类别 | 占比 | 核心诉求 |
|------|---------|------|---------|
| 1 | 职业卓越 | 18.8% | 让 AI 处理日常琐事，自己专注高价值工作 |
| 2 | 个人成长 | 13.7% | 情感支持、自我认知、行为改变、心理健康 |
| 3 | 知识获取 | 12.8% | 快速学习新领域、获取专业信息 |
| 4 | 效率提升 | 11.5% | 自动化重复任务、节省时间 |
| 5 | 创意表达 | 9.3% | 辅助创作、激发灵感 |

典型用户声音

关于职业卓越：
"我每天收到 100-150 条医生和护士的短信。过去大量认知劳动都花在记录上……引入 AI 后，文档压力减轻了。我对护士更有耐心，也有更多时间向家属解释病情。"
—— 美国医疗工作者

关于个人成长：
"AI 为我示范了情商的表现……我可以把这些行为模式用在人际交往中，成为一个更好的人。"
—— 匈牙利用户

三、人们在担心什么？

与期望并存的，是普遍的担忧。调研发现用户最担心的几类风险：

隐私与数据安全 —— 个人信息被滥用或泄露

过度依赖 AI —— 丧失独立思考能力

就业冲击 —— AI 取代人类工作

虚假信息 —— AI 生成内容的可靠性问题

社会不平等 —— AI 红利分配不均

值得注意的是，不同地区、不同职业的用户，担忧的重点差异很大。例如，发展中国家的用户更关注教育和经济机会，而发达国家的用户更关注伦理和监管。

四、一个有趣的发现：期望与现实的差距

调研还对比了"用户想要什么"和"他们是否已经在 AI 上获得这些"。

效率提升类需求：满意度较高，AI 已经在帮助用户自动化日常任务

个人成长类需求：满意度较低，用户对 AI 在情感支持、心理健康方面的表现仍有期待空间

职业卓越类需求：两极分化，部分用户表示 AI 极大提升了工作质量，另一部分则认为 AI 输出还不够专业

五、对 AI 产品设计的启示

这项大规模调研为 AI 产品团队提供了几个关键洞察：

不要只关注"效率" —— 近 1/3 的用户需求与情感、成长、创造力相关，而非纯粹的生产力

个性化是关键 —— 不同地区、职业、文化背景的用户需求差异显著

信任建设需要时间 —— 隐私、安全、可靠性仍是普遍担忧，需要透明度和用户教育

AI 作为"伙伴"而非"工具" —— 越来越多的用户期待与 AI 建立长期、深度的互动关系

六、写在最后

8.1 万人的声音描绘了一幅复杂的图景：人们既渴望 AI 带来的便利与赋能，又对未知风险保持警惕。这种矛盾心态或许正是技术快速发展期的常态。

对于 AI 从业者来说，这份调研最大的价值在于把"用户"从抽象概念还原为具体的人——他们有各自的职业、文化背景、生活困境和成长渴望。技术最终服务的，是这些真实的人类需求。

---

延伸阅读：

原文报告：[What 81,000 people want from AI](https://www.anthropic.com/features/81k-interviews)

Anthropic 研究方法附录（PDF）

通知设置 新通知

发现

1、为什么这个问题难查

2、第一层排除：merge reader 不是第一现场

3、第二层排除：Easysearch 自己的 BKD 写入逻辑也没有先出错

4、真正的转折点：抓到了 reorder() 自身的 coverage 异常

5、哪段代码最可疑

6、最强证据：只换 JDK / JIT 路径，结果就变了

基线组：旧版 Oracle GraalVM 21，默认 JVMCI/Graal JIT

对照组：关闭 JVMCI/Graal JIT 或纯解释执行

版本对照：较新的 GraalVM 21 构建在当前测试中未复现

平台边界：不能写成 ARM 专属

7、更强的同机对照：换成 Oracle HotSpot 21.0.10 后，全量写入跑完也没有问题

8、最关键的外部对照：Elasticsearch 8.19.5 也复现了

9、这次排查最终说明了什么

10、建议版本与规避方案

11、最后

关于 Easysearch

一、调研背景：为什么做这件事？

二、人们最想要 AI 做什么？

典型用户声音

三、人们在担心什么？

四、一个有趣的发现：期望与现实的差距

五、对 AI 产品设计的启示

六、写在最后

活动推荐

热门话题

通知设置新通知

4、真正的转折点：抓到了 `reorder()` 自身的 coverage 异常