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

    PandazNWafflez



    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

    iKeirNez

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

    sbeex

    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

    p000ison

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

    fireblast709

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

    bigteddy98

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

    Rocoty

    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

    iKeirNez

    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

    BungeeTheCookie

    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

    Dablakbandit

  11. Offline

    xTrollxDudex

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

    Cirno

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

    Ultimate_n00b

    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

    xTrollxDudex

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

    bob7

    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

    BungeeTheCookie

    How many kinds of hash maps exist?
     
  17. Offline

    Cirno

  18. Offline

    BungeeTheCookie

  19. Offline

    iKeirNez

    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