Какую HashMap-подобную коллекцию я должен использовать для этого случая?

Question

У меня есть число координатных пространств, составляющих 65 536 на 65 536 и заполненных многими объектами, где ни один из них не может использовать одни и те же координаты. Учитывая это, я могу гарантировать уникальный хеш для каждого объекта, объединив два шорта, которые делают координаты в int, что делает хеш.

Чтобы сохранить ссылки на эти объекты, я в настоящее время использую HashMap с настраиваемым неизменным классом Point в качестве ключа. Однако, так как я начинаю использовать множество этих координатных пространств сразу, я начал искать способы обрезать использование памяти.

Мое понимание того, как работает HashMap в Java является основным, но учитывая, что я могу гарантировать, уникальный хэш для каждого объекта, кажется, я мог бы использовать гораздо более памяти эффективную версию, которая:

• Безразлично» т использование ведер, которые могут содержать несколько объектов
• можно ставить и получить объекты, используя хэш вместо того, чтобы использовать ключ

существует ли такая HashMap, как коллекция?

Редактировать: Координатные пространства разрежены, работают примерно с 2000-3000 объектов на.

Answer 1

Вы можете использовать TIntObjectHashMap или TIntXxxxHashMap из trove4j:

private final TIntIntHashMap map = ... 

public void putInt(int x, int y, int value) { 
    int index = (x << 16) + y; 
    map.put(index, value); // only uses primitives. 
} 

public int getInt(int x, int y) { 
    int index = (x << 16) + y; 
    return map.get(index); 
} 

Answer 2

Ваше заявление о ведрах противоречит недоразумениям. Хэш-ковши не содержат все элементы с заданным хэш-кодом; они содержат все элементы с некоторые функции hashcode. Например, простой пример такой функции может быть просто модульным оператором. У вас есть 2^32 разных возможных кода, но у HashMap, вероятно, будет только (например) 100 ковшей или около того. Использование однопоточных ведер будет означать, что вы эффективно помещаете свои объекты в массив с хэш-кодом в качестве индекса!

Теперь другая идея специализированной карты, которая просто использовала 32-разрядное целое как ключ, действительно работала бы и немного уменьшала бы использование памяти. У Питера Лори есть отличное предложение в его ответе.