Система переменных игрока

[SouthBridge]

FastList -> ArrayList
FastMap -> HashMap

Javolution это пережиток. Избавляйтесь от него.

+1
И ещё обязательно следует учитывать потоко-безопасные варианты коллекций.

Вот например в стандартных коллекциях, имплементации которых не предназначены для конкурентных операций бросают исключение ConcurrentModificationException. Этот же треклятый Javolution - нет.
В конкурентной среде, коллекции Javolution себя ведут неадекватно и неопределенно.
У FastMap есть возможность сделать его "потоко-безопасным", посредством вызова метода shared(), и это нам хорошо видно. Вместо такого следует ставить ConcurrentHashMap (или аналог).

У FastList конечно-же такого нет, по понятным причинам. На все сто я не уверен, есть ли в нём копирование при записи, но как-то ему удается иногда сохранять работоспособность в конкурентной среде. А порой он отмачивал ещё те приколы, выводя из строя полсервера.
Так вот, трудность в случае замены FastList (FastMap без shared туда же) заключается в необходимости дополнительного анализа кода. Как этот лист используется, кем и откуда. Необходимо установить факт конкурентного доступа и в этом случае предпринять меры (локи, синхронизация, CopyOnWriteArrayList или аналог).
Ну или забить на это и ожидать возбуждений CME. ;D

Ну в общих чертах примерно так. Работы не мало, но избавляться от этого экскремента нужно.

[n3k0nation]

+1
И ещё обязательно следует учитывать потоко-безопасные варианты коллекций.

Вот например в стандартных коллекциях, имплементации которых не предназначены для конкурентных операций бросают исключение ConcurrentModificationException. Этот же треклятый Javolution - нет.
В конкурентной среде, коллекции Javolution себя ведут неадекватно и неопределенно.
У FastMap есть возможность сделать его "потоко-безопасным", посредством вызова метода shared(), и это нам хорошо видно. Вместо такого следует ставить ConcurrentHashMap (или аналог).

У FastList конечно-же такого нет, по понятным причинам. На все сто я не уверен, есть ли в нём копирование при записи, но как-то ему удается иногда сохранять работоспособность в конкурентной среде. А порой он отмачивал ещё те приколы, выводя из строя полсервера.
Так вот, трудность в случае замены FastList (FastMap без shared туда же) заключается в необходимости дополнительного анализа кода. Как этот лист используется, кем и откуда. Необходимо установить факт конкурентного доступа и в этом случае предпринять меры (локи, синхронизация, CopyOnWriteArrayList или аналог).
Ну или забить на это и ожидать возбуждений CME. ;D

Ну в общих чертах примерно так. Работы не мало, но избавляться от этого экскремента нужно.

Полностью поддерживаю.
Так же добавлю (самому подсказали недавно), что лучше намного написать свою карту через массивы, если оно будет использоваться локально, что бы не напрягаться на счет CME и не переделывать тонны кода после этих FastMap.

[SouthBridge]

Так же добавлю (самому подсказали недавно), что лучше намного написать свою карту через массивы, если оно будет использоваться локально

Звучит весьма интересно, но кажется я не до конца уловил эту мысль.
Можно чуть подробнее?

[n3k0nation]

Звучит весьма интересно, но кажется я не до конца уловил эту мысль.
Можно чуть подробнее?

К примеру, у нас есть какой-то лоад. Мы пихаем ништяки в карту, затем начинаем итерировать ее и во время итерации удалять элементы из нее. С обычной картой мы получим CME, хотя никакими множественными тридами тут и не пахнет. Для этого дела можно написать отдельную коллекцию, которая нормально это все воспринимает, но только для работы в локальном потоке.

[Johnson]

что лучше намного написать свою карту через массивы

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

Добавлено через 58 секунд

К примеру, у нас есть какой-то лоад. Мы пихаем ништяки в карту, затем начинаем итерировать ее и во время итерации удалять элементы из нее.

Прекрасно делается через итератор с it.remove()

[n3k0nation]

Прекрасно делается через итератор с it.remove()

Тут задача в другом - не менять код х) Ибо менять его придется много где.

[Deazer]

Я от первых тридиков оттолкнусь ибо все не читал -
Перевести на атомар однозначно here/afk/unloaded
Кешировать.... ну сложновато , много все возвести на процедурах по типу here/afk/uloaded. Дампить состояние чара опять же в силу его активности - по алгоритму "кешеда" далеко не дураки его описывали.
Примерно ту же схему юзал на айтемах - получил профит не только по скорости , но и по защите в дополнительном размере довольно не плохо.
Имхо нужно идти от меньшего к большему - начните с макросов , потом выше и выше, а так бросаться глобально, ну почему нет. Только последствия не контролируемы.