2

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

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

Я хотел бы знать следующее:

  1. В этом случае было бы необходимо синхронизировать метод записи?
  2. Выполняет ли ConcurrentHashMap мои потребности?
  3. Если нет, то какова была бы правильная реализация Карты для использования в этом случае?
+2

_ "Данные на карте не будут считаться ни в какой точке приложения" _, а затем _ "Время от времени содержимое будет сбрасываться в файл" _ - так как вы дампируете файл без чтение карты? –

+1

Эти две точки несовместимы: «Данные на карте не будут читаться в любой момент приложения» и «Время от времени содержимое будет сбрасываться в файл». Содержимое не может быть сбрасыто в файл, не считывая полного содержимого карты. –

+1

Возможно, вы также захотите рассмотреть одну карту на поток и затем слить их, когда вы дамп в файл. Затем доступ к картам будет блокироваться только тогда, когда вы дамп в файл вместо блокировки для каждой записи. – xp500

ответ

7

Сосредоточение на этих точках:

  • Данные, которые подают на карте есть другой ключ во время каждой записи

  • Данные карты не будут считаны в любой точке в приложении

Вам не нужно Map. Я предполагаю, что когда вы укажете, что данные на карте не будут прочитаны, вы имеете в виду, что вы не делаете map.get(someKey), но вместо этого вы пройдете всю карту, чтобы сохранить данные в файле (или какой-либо источник данных, который вы использования).

Эта точка:

  • Однажды в то время как содержание будет сбрасываться в файл

Арматурные рекомендацию выше.

Сосредоточение на этой точке:

  • Несколько потоков будут записывать данные в этот map.The операции записи слишком много.

Самая лучшая рекомендация заключается в использовании BlockingQueue. В качестве реализации вы можете использовать LinkedBlockingQueue.

В случае сброса данных из Map с использованием синхронизации Java и необходимости/необходимости восстановления этих данных в форме Map, затем используйте ConcurrentHashMap. Если это не является частью вашего прецедента, потому что вы будете читать данные из файла другими способами, тогда не используйте Map и используйте BlockingQueue.

+0

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

+0

@ user3360241, поскольку ключи не имеют никакой цели, поскольку они всегда уникальны, тогда эта часть действительно бессмысленна. Если ключ не является релевантным для данных, которые не могут быть найдены внутри значения «Карта» (которое никто не знает, кроме OP), это не кажется хорошим. Или, с другой стороны, если у него есть значение, сохраните этот * ключ * в поле в значении и сохраните его. Опять же, опция «Карта» бесполезна для этого варианта использования. –

+0

Что делать, если операционная система захотела перестроить карту из файла в другом приложении? Но, как вы говорите, ключ может быть встроен в ценность для большинства случаев, но не для этого. – John

-1

Если вам действительно нужен Map, то ConcurrentHashMap - это то, что вам нужно. Узнайте больше об этом here.

-1

Как вы уже сказали, ConcurrentHashMap соответствует вашим требованиям. Это потоковая безопасность без синхронизации всей карты. Считывание может происходить очень быстро, в то время как запись выполняется с помощью блокировки.

-3

Все ваши ключи уникальны, поэтому вам не требуется синхронизация для обеспечения целостности карты, но вам это нужно, когда вы действительно будете писать в файл. Используйте ConccurentHashMap или обычную синхронизированную карту, которые вам подходят. Вы можете обойтись без карты, просто просто сохраните ключ/значение в каком-либо объекте и сохраните объект в синхронизированном списке.

+1

Наличие отдельных ключей никак не означает, что запись на карту не требует синхронизации. –

+0

Цитата из, например. [«Javadoc» TreeMap] (https://docs.oracle.com/javase/8/docs/api/java/util/TreeMap.html): * Если несколько потоков обращаются к карте одновременно и, по крайней мере, один из потоки изменяют структуру структурно, она должна быть синхронизирована снаружи *. – Turing85

+0

@JohnBollinger и Turing: Да, я это понимаю. Мой вопрос в том, что если все ключи, которые когда-либо будут вставлены и уникальны, а Карта используется только для записи, какой может быть возможный вред? Например, запись из одного потока может быть недоступна для другого потока .. достаточно справедливо .. Единственный вред будет, когда вы пишете файл, поскольку вы можете не видеть все обновления .. правильно? Я что-то пропустил ? Я согласен, что это не идеальный комментарий. – Geek

0
  1. Нет
  2. Да

Однако я считаю, что это противоречие:

  • Данные карты не будут считаны в любой момент в приложении
  • После через некоторое время содержимое будет сбрасываться в файл.

Как вы можете сбросить файл, не прочитав его?

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

+0

Некоторые объяснения были бы приятными, а не просто «да» или «нет». – Turing85

1

К 1: Интерфейс Map не гарантирует синхронизацию, особенно при записи. Глядя на неконкурирующих реализациях (HashMap, HashTable, IdentityHashMap, LinkedHashMap, TreeMap и WeakHashMap), то все утверждают, что

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

К 2 и 3: Если вы используете ConcurrentHashMap, вам не придется беспокоиться о синхронизации. Но я согласен с Luiggi Mendoza's answer: не используйте Map.