【崩溃】扫描未加载维度时 HTTP 线程热加载维度，与服务器线程竞争导致崩溃（NPE）

[mnaccccs]

【崩溃】扫描未加载维度时 HTTP 线程热加载维度，与服务器线程竞争导致崩溃（NPE）

环境

• GTNH: 2.9.0-beta-1（mod 为 beta-2 构建，如与本问题相关请告知）
• webapi: 2.9.0-beta2-0.7-pre
• Minecraft 1.7.10 / Forge 10.13.4.1614 / Java 25.0.2（Oracle）
• 服务端专用部署（无客户端）

崩溃现象

服务器运行中（已完全启动），通过 Web 界面提交扫描请求后服务器崩溃：

java.lang.NullPointerException: Cannot invoke "it.unimi.dsi.fastutil.longs.LongArrayList.getLong(int)" because "this.wrapped" is null
	at it.unimi.dsi.fastutil.longs.LongOpenHashSet$SetIterator.nextLong(LongOpenHashSet.java:551)
	at net.minecraft.world.gen.ChunkProviderServer.func_73156_b(ChunkProviderServer.java:2589)
	at net.minecraft.world.WorldServer.func_72835_b(WorldServer.java:165)
	at net.minecraft.server.MinecraftServer.func_71190_q(MinecraftServer.java:625)

crash report 描述为 Exception ticking world，崩溃线程为 Server thread。

日志证据（崩溃前最后一条请求）

[ERROR] [webapi]: [POST]	/gt5/scan?chunkX=-4&chunkZ=-3&dim=180 - Error after 0.122ms
java.lang.RuntimeException: Cannot Hotload Dim: Overworld is not Loaded!
	at net.minecraftforge.common.DimensionManager.initDimension(DimensionManager.java:230)
	at net.minecraft.server.MinecraftServer.func_71218_a(MinecraftServer.java:705)
	at love.shirokasoke.webapi.webserver.handlers.gt5.GT5ChunkScanHandler.handleSubmit(GT5ChunkScanHandler.java:115)

注意这条请求运行在 HTTP 线程池（pool-9-thread-5），而非 Minecraft Server thread。

复现步骤

1. 服务端完全启动后，先提交一个已加载维度（如主世界 dim=0）的扫描任务（POST /gt5/scan），256 个子任务异步进行中
2. 扫描未完成时，提交一个当前未加载维度（如 GTNH Personal World dim=180）的扫描请求
3. 服务器崩溃

原因分析

GT5ChunkScanHandler.handleSubmit 中：

MinecraftServer server = getServer();
WorldServer world = server.worldServerForDimension(dim);   // 在 HTTP 线程执行

这段代码运行在 HTTP 线程上。当 dim 对应的维度未加载时，Forge/GTNH 的 worldServerForDimension 会触发 DimensionManager.initDimension 进行维度热加载，即在非 Server thread 上修改 Minecraft 世界状态（维度表、chunk provider 的 chunk 集合等）。

与此同时 Server thread 正在正常 tick 世界（并且之前提交的扫描任务的 256 个子任务也在 Server thread 队列中执行），两个线程并发操作同一组集合（fastutil LongOpenHashSet），导致 Server thread 在 ChunkProviderServer 迭代 chunk 集合时命中 fastutil 迭代器的 wrapped == null NPE——这是典型的跨线程并发修改特征。

顺带一提：日志中的 Cannot Hotload Dim: Overworld is not Loaded! 并非主世界真的未加载，而是 HTTP 线程跨线程读取世界引用时的可见性问题（读到过期/未同步的引用），同一现象的另一面。

建议修复方向

将维度获取/热加载逻辑放进服务器线程执行，例如把 handleSubmit 中的维度解析与 worldServerForDimension 调用包进 ServerThreadDispatcher.scheduleOnServerThread，或在提交前先在校验阶段用 scheduleOnServerThread 确认维度已加载（未加载则直接返回 4xx，而不是隐式热加载）。扫描任务本身已经是异步投递到 Server thread 的，只是提交阶段的维度解析漏了。

附

完整 crash report 与日志可提供，如有需要请告知。

[mnaccccs]

补充：扫描 GT 机器同样会崩溃（已复现 3 次，根因扩大）

后续又崩溃了两次，均为扫描 GT 机器场景，且都在主世界（dim=0），并未切换维度：

时间	异常	崩溃点
14:24:38	NPE LongOpenHashSet$SetIterator.nextLong (551)	ChunkProviderServer.func_73156_b (2589)
14:31:05	AIOOBE LongOpenHashSet.rehash (828) Index -1, length 513	ChunkProviderServer.func_73156_b (2575)
14:38:26	NPE LongOpenHashSet$SetIterator.nextLong (551)	ChunkProviderServer.func_73156_b (2589)

三次全部命中同一个函数（Server thread 每 tick 的 unloadQueuedChunks，即 vanilla 的 func_73156_b），全部是 fastutil LongOpenHashSet 被并发修改的典型症状（迭代器 wrapped == null / rehash 越界）。

根因修正：不止 GT5ChunkScanHandler，多个 handler 都在 HTTP 线程直接操作 Minecraft 世界状态

scanCell 本身是安全的（经 ServerThreadDispatcher 慢队列在 Server thread tick 事件中执行）。真正的问题在提交阶段和查询类 handler——它们运行在 com.sun.net.httpserver 的 HTTP 线程池（pool-9-*），却直接调用会修改/遍历 chunk 集合的 Minecraft API：

• GT5ChunkScanHandler.handleSubmit：worldServerForDimension(dim)（未加载维度触发 initDimension 热加载）+ chunkExists + loadChunk
• ChunkHandler：chunkExists + loadChunk（同样在 HTTP 线程）
• BlockHandler：world.getTileEntity(...)（HTTP 线程直接读世界）

loadChunk 内部会操作 ChunkProviderServer.chunksToUnload（LongOpenHashSet，fastutil，无任何并发保护），与 Server thread 每 tick 的 unloadQueuedChunks 形成竞争。时机撞上即崩——所以即使只扫主世界已加载区块也会随机崩溃（#2/#3），扫未加载维度（热加载）则是必崩路径（#1）。

修复方向（更新）

项目里已有 ServerThreadDispatcher.runOnServerThread / callOnServerThread（带阻塞等待、已在 Server thread 时直接执行），但只有 scanCell 的投递用了慢队列，所有 handler 对世界对象的直接访问都没有经过它。建议：

1. handleSubmit / ChunkHandler 中的 worldServerForDimension、chunkExists、loadChunk 全部包进 runOnServerThread / callOnServerThread
2. 全仓库排查：凡是在 HTTP 线程调用任何 World / WorldServer / ChunkProviderServer / TileEntity API 的地方，统一走 ServerThreadDispatcher
3. 未加载维度不要隐式热加载，直接返回 4xx（或走 Server thread 显式加载）

这是服务器稳定性问题（可随机崩溃整服），建议优先修复。

[Rcrwrate]

2.9.0-beta2没法复现，完全的新服务器存档，在启动的一瞬间访问，没问题，向下兼容无法保证，正在研究，可能需要一段时间

[10:50:19] [Server thread/INFO] [vendingmachine]: Loaded 176 trade groups containing 211 trades.
[10:50:19] [Server thread/INFO] [webapi]: Server Starting
[10:50:19] [Server thread/INFO] [webapi]: [WebServer] Starting HTTP server on port 40002...
[10:50:19] [Server thread/INFO] [webapi]: Chunk loading callback registered successfully
[10:50:19] [Server thread/INFO] [webapi]: [WebServer] Access at: http://localhost:40002/
[10:50:19] [Server thread/INFO] [webapi]: 压缩算法可用性:       br false zstd false
[10:50:19] [Server thread/INFO] [webapi]: [WebServer] Removing route '/test'...
[10:50:19] [Server thread/INFO] [webapi]: [CloudFlared] server.cf.path is empty, tunnel disabled
[10:50:19] [Server thread/INFO] [Hodgepodge]: [TG Recovery] No TG-SaveData.dat file found.
[10:50:19] [CoreTweaks TransformerCache save thread/INFO] [coretweaks]: Saving transformer cache
[10:50:19] [pool-9-thread-1/INFO] [ServerThreadLongHashMap]: Off-thread chunk read from WebAPI thread 'pool-9-thread-1', serving from snapshot
[10:50:19] [pool-9-thread-1/INFO] [webapi]: [POST]      /gt5/scan?chunkX=0&chunkZ=0 - 29.160ms

具体的报错Mixin位置：
GTNewHorizons/Hodgepodge@2.7.160...2.7.170#diff-c941c90337fd59d025545e13c9dbc2f7bb30af8c7140512bcdb370cbbdcd84ecL72

[Rcrwrate]

问题已确认

2.9.0beta2 fastutil 换成独立的 8.5.18，迭代器内部实现没变（还是同样的 wrapped NPE 分支），但 rehash/扩容参数细节略有差别，触发的临界时序窗口变小了，所以开发过程一直没遇到过

修复可能需要较长的一段时间

[mnaccccs]

目前 290 大部分玩家还是在玩 beta1 的，beta2 的改动评价很差 在 2026年8月6日，13:41，琪露诺酱 ***@***.***> 写道：  [https://avatars.githubusercontent.com/u/46920034?s=20&v=4]Rcrwrate left a comment (Rcrwrate/McWebAPI#1)<#1 (comment)> 问题已确认 2.9.0beta2 fastutil 换成独立的 8.5.18，迭代器内部实现没变（还是同样的 wrapped NPE 分支），但 rehash/扩容参数细节略有差别，触发的临界时序窗口变小了，所以开发过程一直没遇到过 修复可能需要较长的一段时间

[Rcrwrate]

改动都是数值上的变动吧，这不在考虑范畴之内，同大版本号尽可能兼容。

目前已经修复的差不多了