Forsaiken

Yeah pls lock it :)

.

.

setShared() only put itself in an synchronized (this) block and then recall the put/remove and keep references in the linked entrys. the same for lists. an Collections.synchronizedMap(m) or Collections.synchronizedList(list) does the same except for the entrys. But as i told u, we are using javolution/trove for maps. And as u can imagine...an thread monitor cost fucking much performance! Simple calls such as list.get(index) drop in speed by like 100 times or more. But i guess smth like that is never teached in school :P

No. We use Trove and Javolution maps. But i made some custom array/linked list/queue implementations, StringBuffer, NIO networking and file handling, non blocking random, "ordered sequential" thread executors, blocking multi task executors, xml reader, Math utils, Array utils, date generators, byte array reader/writer, GUI utils, default Swing classes, custom buffer and binary sorted array queues with shift insert/move functions for updated pathfinding nodes (Pathfinding: ToI floor 1, 500 worlds units from one room to another, 4 edges: 1.4ms including path optimize from each node to destination to make paths nearly retail like) The only thing that is really speeding up is wisely used code such as: private final L2Effect getFirstEffectInternal(final IncArrayList<L2Effect> effects, final L2EffectType effectType) { if (effects == null) return null; for (int i = effects.size(); i-- > 0;) { final L2Effect effect = effects.getUnsafe(i); if (effect != null && effect.getEffectType() == effectType) return effect; } return null; } Stuff like this makes iterations and other operations concurrent save without a thread monitor (synced block) or atomic locks, and in this case it does speed up a lot! We are not using any shits to make it work! We try to make it as fast and readable as possible, because better code = better server.