Memory leaks occur every time a player logs in or logs out.

1. To facilitate testing, use Carpet's /player command to control player logins.
2. Place two command blocks, one to control player logins and the other to control logouts.
3. Enable the command blocks to run in a loop.
4. Open the Task Manager, and you can observe that the process memory keeps growing.
5. Although Carpet is used to assist in testing, after testing, it is found that memory leaks do not occur when fabric api is not installed.

每次玩家上线或下线时都会发生内存泄漏

1. 为了方便测试，使用Carpet的/player命令来控制玩家上线
2. 放置两个命令方块，一个控制玩家上线，一个控制下线
3. 将命令方块循环开启
4. 打开任务管理器，可以看到进程内存一直在增长
5. 虽然使用了Carpet来辅助测试，但经过测试，未安装fabric api时并没有发生内存泄漏
   
   
   
   

@cdqtzrc could you check what is leaking the memory, via VisualVM? If that is not possible, try installing individual modules of Fabric API and see what is causing this.

I first recommend removing Networking (and its dependents like Registry Sync, Screen Handler, etc).

Through further testing, I found that this is a compatibility issue between the fabric api and Carpet, and memory leaks only occur when fake players join the game.

通过进一步测试，我发现这是fabric api和Carpet的兼容性问题，只有假玩家加入游戏才会发生内存泄漏。

Although there seems to be no problem with the fabric api itself, I would like to point out that the memory leak occurs in the "trackedAddons" field of the "net.fabricmc.fabric.impl.networking.GlobalReceiverRegistry" class.

虽然fabric api并没有什么问题，但我还是想说一句，内存泄漏发生在“net.fabricmc.fabric.impl.networking.GlobalReceiverRegistry”类的trackedAddons字段

Re-opening as the Fake Player API appears to be susceptible to this issue + proper resolution of this bug on Carpet requires Fabric API changes. Question @modmuss How should we fix this? carpet probably won't like being dependent on FAPI (e.g. interface injection to SPE on whether it supports the stuff). Should we just abuse Weaks?

the Fake Player API appears to be susceptible to this issue

Can you explain how, extra special care was taken to ensure that this isnt the case. It already uses weak values.

See: https://github.com/FabricMC/fabric/blob/1.21/fabric-events-interaction-v0/src/main/java/net/fabricmc/fabric/api/entity/FakePlayer.java#L102

A fake player from our API should not have a network addon. I dont know what carpet does, I am 98% sure its fake players are not our fake players.

@modmuss50 The leak comes from a different place; GlobalReceiverRegistry is both static, and tracks addons (which keep reference to player). Since fake player connections are never properly disconnected, it will pile up.

I don't see where we are preventing fake players from having an addon. I am pretty sure the SPNH mixin at <init> applies when the class is inherited from.

@modmuss50 The leak comes from a different place; GlobalReceiverRegistry is both static, and tracks addons (which keep reference to player). Since fake player connections are never properly disconnected, it will pile up.

I don't see where we are preventing fake players from having an addon. I am pretty sure the SPNH mixin at <init> applies when the class is inherited from.

Ah yes, that seems valid. I will look into this. There should be no need for an addon.