Why Not To Save Players to Lists / Sets / Whatever

Discussion in 'Resources' started by PandazNWafflez, Jul 1, 2012.

Thread Status:
Not open for further replies.
  1. Offline


    Memory leaks:
    - Player logs off: Javas GC can't remove it cause your list/set/whatever still contains it. So you still have the whole instance of the player (with the IP, the real name, the display name, the list name, the health, the potion effects, ...) even if minecraft tries to save it to disc and unloads it from ram.
    But it can go more worse:
    - Multiverse (or some other multi world plugin) unloads the world the (maybe since two or more days... but still in your list...) logged off player was in. The GC can't remove it cause there's still that player instance in your map, which is holding chunks loaded, which prevents the world from unloading...

    This taken from a post by V10lator somewhere, but I figured I'd post it here.
    WarmakerT likes this.
  2. Offline


    Yeah, thats why we store player names instead of player objects.
  3. Offline


    I learned something but I really do not see how to solve the problem...

    I did a plugin that add some properties to my players so how can I do it ? I send my plugin in constructor of my "CustomPlayer" like that ? new CustomPlayer(myplugin.getServer(), player.getName());


    I can't reach servers player without having access to getServer().getPlayer() isn't it ? So how should I do ? Any ideas ? Thanks in advance !
  4. Offline


    Yeah you have to get the player then with getServer().getPlayerExact(). :p
  5. Offline


    WeakReferences don't block the GC from cleaning up the reference.
    CaptainBern and iKeirNez like this.
  6. Offline


    Just a little question, but is it better to store are the UUID or the name?
  7. Offline


    Why not just remove the Player reference when they log out? Problem solved, and better performance since you don't have to loop through all online players every time you need the Player object.

    IMO this is what we should be teaching newcomers, not the "never ever store a player in memory" propaganda that everybody seems to be taking as gospel.
    Zupsub and jjssman like this.
  8. Offline


    Depends on your uses, usually UUID would be a good idea though.

    Yeah, its safe to store player instances as long as you null them when they log off and just to be safe, use fireblast709 's suggestion.

  9. Offline


    It doesn't really matter if you store a player object in a list if you take the right precautions.

    1. PlayerQuitEvent, remove player from the list that store the player object. If you have to p, make it static?
    2. WorldUnloadEvent, remove all players from the list, then unload the world.

    Anything else? Call an event, remove the player. Done.
    Skyost likes this.
  10. Offline


  11. Offline


    This was written quite a while ago, so go with UUID unless you are worried about memory.
  12. Offline


    Or simply use a WeakHashMap<?, Player> or a List<WeakReference<Player>>.
    Skyost, Garris0n and Ultimate_n00b like this.
  13. Offline


    If you look here, you can see that all the UUID does is contain two long values. Unless you're storing several thousand UUIDs, you're not going to see any memory increase.
  14. Offline


    I already release what it has in the class. I meant if you needed to squeeze out every last bit of speed,
  15. Offline


    As long as your careful, storing the Players object will help you gain much better performance and avoid constant getPlayer usage.

    Take a look for yourself. This is bukkit's getPlayer() HERE. You could say getting the player from the UUID is much faster, or getting the player from the exact username is better but nothing can compete with a direct reference.
  16. Offline


    How many kinds of hash maps exist?
  17. Offline


  18. Offline


  19. Offline


    It won't affect memory, since the UUID object exists anyway when the player joins until they leave and GC gets the instance, you're just "linking" to it. That's probably the best way to explain it.
    Zupsub and xTrollxDudex like this.
Thread Status:
Not open for further replies.

Share This Page