FabricMC项目中假玩家连接导致的内存泄漏问题分析

问题背景

在FabricMC项目的实际应用中发现，当使用Carpet模组创建假玩家(Fake Player)进行频繁登录/登出操作时，服务器进程会出现持续的内存增长现象。经过深入排查，发现该问题与Fabric API的网络模块实现机制有关。

技术原理分析

问题的核心在于GlobalReceiverRegistry类的设计实现。该类作为静态全局注册表，负责管理玩家网络附加组件(Network Addon)，其内部通过trackedAddons字段持有所有已注册的附加组件引用。

当普通玩家正常连接时，Minecraft服务端会完整执行连接生命周期管理，包括网络组件的注册和注销。但对于假玩家而言，特别是通过Carpet模组创建的假玩家，其连接往往不会执行完整的注销流程。

问题根源

1. 静态注册表长期持有引用：GlobalReceiverRegistry作为静态实例，其生命周期与JVM进程绑定
2. 假玩家连接的特殊性：假玩家连接通常不会触发标准的断开连接事件
3. 缺少引用清理机制：网络附加组件会保持对玩家对象的强引用，导致玩家对象无法被GC回收

解决方案建议

从技术实现角度，可以考虑以下改进方向：

1. 弱引用改造：将trackedAddons中的强引用改为弱引用或软引用，允许GC在必要时回收资源
2. 生命周期钩子：为假玩家实现特定的网络组件注销接口
3. 类型检测机制：在注册网络组件时识别假玩家类型，避免为其创建持久化组件

影响范围评估

该问题主要影响以下场景：

• 大量使用假玩家进行自动化测试的服务器环境
• 长期运行的生存服务器中使用假玩家执行自动化任务
• 任何频繁创建/销毁假玩家的模组组合

最佳实践建议

对于服务器管理员和模组开发者，在问题修复前可采取以下临时措施：

1. 限制假玩家的创建频率
2. 定期重启服务器释放内存
3. 避免在假玩家上使用需要网络通信的功能

该问题的本质反映了在模组化环境中资源生命周期管理的重要性，特别是在处理非标准玩家实体时需要特殊的资源回收机制。