Повторное использование хеш-карт в массиве

Question

Я держу массив хеш-карт, я хочу получить максимальную производительность и использование памяти, поэтому я хотел бы возобновить хеш-карты внутри массива.

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

Мне также нужно копировать обратно значения при удалении хеш-карты из массива.

Я не уверен, что это лучше, чем создавать new HashMap() каждый раз.Что лучше?

UPDATE

необходимо циклически обработать около 50 миллионов хеш-карт, каждая хэш-карта имеет около 10 пар ключ-значение.Если размер массива 20 000, мне нужно всего 20 000 хеш-карт вместо 50 миллионов новых хеш-карт ()

Answer 1

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

public class A {
    public int counter = 0;

    public static void main(String[] args) {

         A a = new A();
         a.counter = 5;
         A b = a; // I want to save a into b and then recycle a for other purposes
         a.counter = 10; // now b.counter is also 10
    }
}

Я уверен, что вы поняли, но если вы не копируете ссылки на HashMaps из массива, тогда все должно быть в порядке.

Answer 2

Есть несколько проблем с повторным использованием HashMap с.

• Даже если данные ключа и значения не занимают память (совместно используемую из других мест), объекты Map.Entry будут доминировать в использовании памяти, но не будут использоваться повторно (если вы не сделали что-то особенное).
• Из-за GC поколений, как правило, наличие старых объектов, указывающих на новые, является дорогостоящим (и относительно трудно понять, что происходит). Может не быть проблемой, если вы храните миллионы из них.
• Более сложный код сложнее оптимизировать. Так что будьте проще, а затем проведите большую оптимизацию, которая, вероятно, потребует изменения структур данных.

Answer 3

Проблема в том, что большинство объектов являются объектами Map.Entry в HashMap.Хотя вы можете перерабатывать сам HashMap (и его массив), это лишь небольшая часть объектов.Одним из способов решения этой проблемы является использование FastMap из javolution, который перерабатывает все и поддерживает управление жизненным циклом (он предназначен для минимизации мусора таким образом)

Я подозреваю, что наиболее эффективный способ - это использование EnumMap (есливам известны ключевые атрибуты) или POJO, даже если большинство полей не используются.

Answer 4

Я думаю, что вы хотите что-то вроде пула объектов, где вы получаете объект (в вашем случае его HashMap) из пула объектов, выполняете свои операции, и если этот объект больше не нужен, вы кладете его обратнов пуле.

проверьте шаблон проектирования пула объектов, для дальнейшей ссылки проверьте эту ссылку:

http://sourcemaking.com/design_patterns/object_pool

Answer 5

В большинстве случаев вы не почувствуете никакой разницы.

Обычно количество записей на карте НАМНОГО больше, чем количество объектов на карте.Когда вы заполняете карту, вы создаете экземпляр Map.Entry для каждой записи.Это относительно легкий объект, но в любом случае вы вызываете new.Сама карта без данных также легкая, поэтому вы не получите никаких преимуществ с этими приемами, если на вашей карте не будет 1-2 записи.

Итог.Забудьте о преждевременной оптимизации.Реализуйте свое приложение.Если у вас есть проблемы с производительностью профилировать приложение, найдите узкие места и исправьте их.Я могу на 99% гарантировать вам, что узкое место никогда не будет в new HashMap() звонке.

Answer 6

Совершенно неясно, почему повторное использование карт таким образом улучшило бы производительность и / или использование памяти. Насколько нам известно, это может не иметь значения или может иметь обратный эффект.

Вы должны сделать любые результаты, чтобы получить наиболее читаемый код, затем профилировать и, наконец, оптимизировать части кода, которые профилировщик выделяет как узкие места.

Answer 7

Не имеет значения.Преждевременная оптимизация.Возвращайтесь, когда получите результаты профилировщика, говорящие вам, где вы фактически тратите большую часть памяти или циклов ЦП