Помогите Выбираем класс для отслеживания сессии

[Deawilld]

Надо некоторые данные онлайн игрока сохранять для использования, скажем, в следующей команде от этого же игрока. Полагаю, что для этого проще всего использовать HashMap, но какой тип лучше всего использовать для ключа? Вариантов несколько: Player, OfflinePlayer, CommandSender, String, UUID. Видел на форуме, что не рекомендуют использовать Player для хранения информации, т.к. он нестабилен. Так вот что будет самым оптимальным и простым вариантом? Может вообще получать игрока по имени или UUID? Так же необходимо учесть, что при выходе игрока эти данные желательно очистить, чтобы не занимать память. Как это обычно делается?

 

[Nikolai_Faint]

Player и ссылка на него будет храниться в любом случае на сервере независимо от того, используешь ты её или нет. А чтобы память не тратить зря, нужно всего лишь удалять ссылку из своих структур данных при выходе игрока. Тут я бы сказал вообще нет разницы в плане памяти, какую ссылку хранить. Ибо ссылка на строку с именем игрока будет указывать на тот же объект, на который она указывает в объекте класса Player, OfflinePlayer и других.

Что ты несешь? Рофл. Конечно он будет хранится, более того, он инициализируется при старте сервера. Ты удалишь ссылку, а объект освобождать кто будет? Или же когда удаляешь ссылку объект сам по себе исчезает? Разница в весе экземпляра. Про ссылку с именем вообще не понял. Инициализируется весь экземпляр, а не только на метод getDisplayName.

 

[MurlikMurlik]

В том что по новой ссылке будет хранится лишь строка, а не билд огромного экземпляра.

Дак а разница?
В твоем случае как раз экономнее будет использовать Player так как он уже в памяти. А создавая строку, ты никак не экономишь память. К тому же, смысл был изначально в том, что бы каждый раз не гетать игрока по нику (что затратно, ведь там используется итерация на поиск объекта по нику), а сразу иметь прямой доступ к игроку когда надо.

 

[Nikolai_Faint]

Дак а разница?
В твоем случае как раз экономнее будет использовать Player так как он уже в памяти. А создавая строку, ты никак не экономишь память. К тому же, смысл был изначально в том, что бы каждый раз не гетать игрока по нику (что затратно, ведь там используется итерация на поиск объекта по нику), а сразу иметь прямой доступ к игроку когда надо.

ЭКЗЕМПЛЯР СОЗДАЕТСЯ ЗАНОВО АУ. СТРОКА ВЕСИТ НАМНОГО МЕНЬШЕ ЧЕМ ЭКЗЕМПЛЯР ИГРОКА.

 

[imDaniX]

ЭКЗЕМПЛЯР СОЗДАЕТСЯ ЗАНОВО АУ. СТРОКА ВЕСИТ НАМНОГО МЕНЬШЕ ЧЕМ ЭКЗЕМПЛЯР ИГРОКА.

Игрок заходит - храним ссылку на его текущий Player как ключ в мапе. Никаких экземпляров сами не создаем, и берем лишь то, что уже сгенерировано баккитом. Игрок выходит - убираем его из мапы. Профит. Не?

 

[Nikolai_Faint]

Игрок заходит - храним ссылку на его текущий Player как ключ в мапе. Никаких экземпляров сами не создаем, и берем лишь то, что уже сгенерировано баккитом. Игрок выходит - убираем его из мапы. Профит. Не?

Нет. Мы не храним, мы создаём и храним ссылку на то что создали, разница огромная. Посчитай нагрузку при сотке онлайна. И сравни строку и экземпляр Player.

 

[Deawilld]

Что ты несешь? Рофл. Конечно он будет хранится, более того, он инициализируется при старте сервера. Ты удалишь ссылку, а объект освобождать кто будет? Или же когда удаляешь ссылку объект сам по себе исчезает? Разница в весе экземпляра. Про ссылку с именем вообще не понял. Инициализируется весь экземпляр, а не только на метод getDisplayName.

Рофл это про экономию памяти Вы рофлите? Ты видимо не знаешь Java, если не понимаешь, как здесь работает "сборка мусора". Объекты, на которые не указывает ни одной ссылки удаляются JVM автоматически. Таким образом, если есдинственная ссылка на объект хранится в переменной, достаточно задать этой переменной значение null, чтобы удалить объект. Объект же Player используется только когда игрок онлай и уж никак не инициализируется при старте. А строки вообще если равны, автоматически используют одну и ту же ссылку из пула строк, чтобы не плодить одинаковые объекты String. И это даже не важно, если ты берёшь эту ссылку у объекта, который всё равно её хранит.

 

[Nikolai_Faint]

Рофл это про экономию памяти Вы рофлите? Ты видимо не знаешь Java, если не понимаешь, как здесь работает "сборка мусора". Объекты, на которые не указывает ни одной ссылки удаляются JVM автоматически. Таким образом, если есдинственная ссылка на объект хранится в переменной, достаточно задать этой переменной значение null, чтобы удалить объект. Объект же Player используется только когда игрок онлай и уж никак не инициализируется при старте. А строки вообще если равны, автоматически используют одну и ту же ссылку из пула строк, чтобы не плодить одинаковые объекты String. И это даже не важно, если ты берёшь эту ссылку у объекта, который всё равно её хранит.

Они не удаляются автоматически, они удаляются когда вызывается Garbage Collector, хотя у вас всё возможно. Я просто пожелаю вам удачи каждый раз очищать хеш с вызовом GC не глядя на его задержку. У вас быстро накопится heap мусор в памяти и теперь стоп поинт для GC будет намного дальше чем при обычной сборки мусора.

 

[MurlikMurlik]

ЭКЗЕМПЛЯР СОЗДАЕТСЯ ЗАНОВО АУ. СТРОКА ВЕСИТ НАМНОГО МЕНЬШЕ ЧЕМ ЭКЗЕМПЛЯР ИГРОКА.

Слушай. Вот иди сейчас и докажи нам это.
Я только что провел собственное исследование, в своей команде. При вводе, скастил сендера до игрока, записал ссылку игрока в одну переменную.
Далее снова при вводе команде я уже сравниваю ссылки, и о, оказывается они одинаковые. Тоже самое с ивентами.
Это значит никакой экземпляр новый не создается, он создается при входе и на протяжении всей игры игрока храниться в памяти и в коллекции баккита.

 

[alexandrage]

Они не удаляются автоматически, они удаляются когда вызывается Garbage Collector, хотя у вас всё возможно. Я просто пожелаю вам удачи каждый раз очищать хеш с вызовом GC не глядя на его задержку. У вас быстро накопится heap мусор в памяти и теперь стоп поинт для GC будет намного дальше чем при обычной сборки мусора.

Реально рофлишь или серьезно дурачек? Игрок и так удалиться при его выходе.

 

[Nikolai_Faint]

Слушай. Вот иди сейчас и докажи нам это.
Я только что провел собственное исследование, в своей команде. При вводе, скастил сендера до игрока, записал ссылку игрока в одну переменную.
Далее снова при вводе команде я уже сравниваю ссылки, и о, оказывается они одинаковые. Тоже самое с ивентами.
Это значит никакой экземпляр новый не создается, он создается при входе и на протяжении всей игры игрока храниться в памяти и в коллекции баккита.

Ок. Немного позже напишу код и пришлю видос.

Реально рофлишь или серьезно дурачек? Игрок и так удалиться при его выходе.

Т.е сама JVM удалит его, а на GC и NPE вообще все равно, верно?

 

[alexandrage]

Ок. Немного позже напишу код и пришлю видос.

Т.е сама JVM удалит его, а на GC и NPE вообще все равно, верно?

Не понял о чем ты. В мапе игрок удаляется на quit ивенте. Где ты там собрался ловить свои нпе?

 

[Deawilld]

Т.е сама JVM удалит его, а на GC и NPE вообще все равно, верно?

GC вызывается автоматически, какая тут вообще разница. Если ты считаешь, что тут что-то не правильно, то это уже проблемы Баккита. И вообще ты типа его исходники чекал, что у тебя такая уверенность насчёт Player?

 

[Nikolai_Faint]

Не понял о чем ты. В мапе игрок удаляется на quit ивенте. Где ты там собрался ловить свои нпе?

Он собрался хранить данные в отдельной мапе. Она не очиститься. А ловить NPE будешь когда игрок выйдет.

GC вызывается автоматически, какая тут вообще разница. Если ты считаешь, что тут что-то не правильно, то это уже проблемы Баккита. И вообще ты типа его исходники чекал, что у тебя такая уверенность насчёт Player?

GC вызывается при достижении определенного уровня загрузки памяти. В гугел: how get object size in memory java

 

[alexandrage]

Он собрался хранить данные в отдельной мапе. Она не очиститься. А ловить NPE будешь когда игрок выйдет.

Ты это сам только что придумал? Телепат 80лвл.

 

[Nikolai_Faint]

Ты это сам только что придумал? Телепат 80лвл.

Полагаю, что для этого проще всего использовать HashMap, но какой тип лучше всего использовать для ключа?

Только что сам придумал.

 

[CraftCoder]

Только что сам придумал.

Кстати, если ты все же разберешься как работает память Java, то поймешь, что вариант со строкой в определенных условиях (настройки jvm) будет даже хуже, чем использовать Player в качестве ключа мапы.

 

[Nikolai_Faint]

Кстати, если ты все же разберешься как работает память Java, то поймешь, что вариант со строкой в определенных условиях (настройки jvm) будет даже хуже, чем использовать Player в качестве ключа мапы.

Это в каких еще условиях? На уме только пара вариантов, но это маловероятно.

 

[CoolBoy]

Они не удаляются автоматически, они удаляются когда вызывается Garbage Collector, хотя у вас всё возможно. Я просто пожелаю вам удачи каждый раз очищать хеш с вызовом GC не глядя на его задержку. У вас быстро накопится heap мусор в памяти и теперь стоп поинт для GC будет намного дальше чем при обычной сборки мусора.

Проиграл с твоих сообщений оч дико. Даже если учесть всю дичь что ты тут высрал - hashmap в качестве ключа всегда использует хеш объекта, а не сам объект или о чем там твоё воспалённое воображение думает.

 

[Nikolai_Faint]

Проиграл с твоих сообщений оч дико. Даже если учесть всю дичь что ты тут высрал - hashmap в качестве ключа всегда использует хеш объекта, а не сам объект или о чем там твоё воспалённое воображение думает.

Мое воображение думает о ссылке на объект о котором я не раз упоминал. Так с чего ты проорал?

 

[MurlikMurlik]

Мое воображение думает о ссылке на объект о котором я не раз упоминал. Так с чего ты проорал?

Расскажи что такое ссылка.