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

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

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

 

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

 

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

 

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

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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