记忆冻结修复

MemoryFreeze 修复

一个适用于 Minecraft 1.21.11 的 Fabric 模组，用于监控 JVM 堆内存，并在其演变为卡顿或永久冻结循环之前介入处理。

作者：zSouul

它实际做什么

1. 在约 100% 时出现明显卡顿——一旦使用率超过阈值（默认为 95%），它会强制进行一次 GC（“紧急裁剪”），抢在游戏自身被迫进行紧急回收之前。
2. 高占用率下卡住且无法恢复（“卡死检测”）——如果使用率持续（默认 60 秒）处于或高于阈值（默认为 85%），它会运行一次多阶段深度清理。
3. 长时间游戏中内存底线自身不断攀升（例如，第一个小时内从未超过 40%，但之后卡在 60% 到 95% 的循环中）——这不是垃圾，而是游戏正常引用的数据（区块/实体/渲染缓存）随着游戏时间增加而累积，GC 永远无法回收这些数据。针对这种情况，请使用完全重置。

其诚实的能力限制（请阅读）

一个与游戏运行在同一个 JVM 中的模组，无法做到任何仅通过 System.gc() 就能实现的重启所能做的额外事情——GC 只能回收不再被任何对象引用的内存，它无法触碰 Minecraft 仍在合法持有的数据。因此：

• 如果深度清理运行后使用率几乎没有变化，模组会直接告诉你，而不是假装它起作用了。这个结果意味着内存确实被使用着，而不是等待回收的垃圾。
• 完全重置（/memoryfreeze reset，仅客户端，或“完全重置”键位绑定）才是针对上述问题的真正方案：它会断开与当前世界/服务器的连接，并在同一运行中的游戏内立即重新加入。这与众所周知的“返回标题画面再重新进入”技巧效果相同——它实际上会拆除关卡（区块追踪器、实体数据、渲染缓存），从而打破 GC 无法触及的引用，而不仅仅是要求 GC 更努力。它比紧急裁剪或深度清理更具破坏性（你会看到一个短暂的加载画面），因此它是纯手动的，绝不会自动触发。如果在完全重置后使用率立即回升到相同的卡死水平，那强烈暗示是另一个模组（与世界生命周期无关）存在真正的内存泄漏——游戏内的任何技巧都无法修复，只能移除/更新该模组或真正地重启游戏。
• 针对问题 1/2（使用率攀升但在普通 GC 后无法回落）的最大杠杆实际上是你的 JVM 启动参数——特别是你所使用的垃圾收集器以及它是否配置为将内存交还给操作系统。任何模组都无法在运行时更改这一点。因此，在启动时，此模组会读取你当前的 -Xmx 和活动的 GC 算法——仅当它们看起来次优时——记录（并在聊天中显示一次）一条具体的 JVM 参数建议。那才是根治问题的修复方法；游戏内的裁剪/深度清理/重置只是在其之上的安全网。

前置要求

• Fabric API 0.141.1+1.21.11 或兼容版本
• Cloth Config API 21.11.150+（必需：为配置界面提供支持）

命令

既可以作为服务端命令（/memoryfreeze …，其中 trim、deepclean、reload、hud 需要操作员权限等级 2），也可以作为同名的客户端命令使用，因此在单人游戏和连接到任何服务器时都能以相同方式工作——客户端版本只会影响你自己的客户端内存。

命令	效果
/memoryfreeze status	显示当前堆使用率百分比、已用/已提交/最大内存、活动 GC、上次裁剪/深度清理的时间
/memoryfreeze trim	立即手动运行一次紧急裁剪（单次 GC）
/memoryfreeze deepclean	手动运行一次深度清理（多阶段，并提供诚实的报告）
/memoryfreeze reset	仅客户端。 离开并立即重新加入当前世界/服务器——真正的“重置”按钮，用于深度清理不够的情况
/memoryfreeze reload	在不重启的情况下重新加载配置文件
/memoryfreeze hud	切换屏幕上的堆内存仪表显示

在“选项 → 控制 → MemoryFreeze 修复”下还有两个默认未绑定按键的键位——如果你不想输入命令，可以将它们绑定到方便的位置：

• “立即深度清理内存”
• “完全重置（离开并重新加入世界）”

配置 可以通过游戏内 ModMenu → MemoryFreeze 修复 → 配置（如果安装了 ModMenu）进行编辑，或直接编辑：首次运行时会自动在 .minecraft/config/memoryfreeze-fix.json 创建。所有数值均可实时编辑，并通过 /memoryfreeze reload 生效：

键名	默认值	含义
panicTrimThresholdPercent	95	触发紧急裁剪的堆使用率百分比
panicTrimCooldownSeconds	20	两次紧急裁剪之间的最小间隔（秒）
stuckThresholdPercent	85	被视为“卡死”的持续堆使用率百分比
stuckDurationSeconds	60	在自动深度清理触发前，需要保持在卡死状态的时间（秒）
reliefMinDropPercent	4	被计为“缓解”所需的最小下降百分比
autoDeepCleanEnabled	true	卡死检测是否自动触发深度清理
deepCleanCooldownSeconds	60	两次深度清理之间的最小间隔（秒）
deepCleanMaxPasses	3	每次深度清理的最大 GC 次数
pollIntervalMillis	750	看门狗检查堆使用率的频率（毫秒）
hudEnabled	true	显示屏幕上的堆内存仪表
chatNotifications	true	当裁剪/深度清理发生时显示聊天消息
logJvmAdviceOnStartup	true	如果你的设置看起来次优，记录/宣布一个 JVM 参数建议