Какие реализации алгоритмов хэширования, таких как SHA-256 для Java, являются потокобезопасными?

Есть несколько способов настроить это:

Вы создаете тему для каждой имеющейся у вас работы.

Другими словами, вы создаете новый экземпляр java.lang.Thread (или экземпляр класса, который extends Thread), который, если вы его запустите, выполнит одну работу, а затем завершится.

Это плохая идея — по крайней мере, если важна скорость и вам предстоит выполнить массу работы. Фактическая стоимость создания этих потоков зависит от множества факторов, поистине комбинационного взрыва: версии JVM, поставщика, базовой ОС, базовой архитектуры. Вполне возможно, что это хороший способ сделать это с точки зрения скорости, но есть комбинации, в которых это намного медленнее, чем альтернатива, заключающаяся в ограниченном наборе потоков (примерно равном количеству ядер в вашем процессоре, возможно, примерно в 2 раза больше, но линейно зависит от количества ядер), и эти потоки извлекают задания из центральной очереди em до тех пор, пока все задания не будут выполнены.

Существуют различные фреймворки, которые делают это «хорошим» (например, fork/join, ExecutorPool и т. д.), и если вы каким-то образом хотите управлять всем этим, вы можете использовать типы коллекций в java.util.concurrent для «центральной очереди всех выполняемых заданий». из которого тянутся все нити».

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

У вас есть рабочие места и пул исполнителей, которые получают от них рабочие места.

... и количество исполнителей ограничено (того же порядка, что и количество ядер ЦП в машине).

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

Тогда решение состоит в том, чтобы просто создать 1 объект Mac для каждого потока. Это означает, что у вас есть 1 объект Mac на каждый процессор, что является тривиальной и игнорируемой стоимостью. Нет смысла пытаться использовать меньше объектов Mac; вы не получите измеримой производительности, даже если бы это было нормально (т. е. объекты Mac вообще не имеют контекста, что, очевидно, неверно), или даже потеряете производительность, если каким-то образом эти объекты Mac являются потокобезопасными, но имеют состояние (потому что JVM очень хорошо устраняет затраты на синхронизацию, если они не имеют значения, поскольку объект никогда не используется из нескольких потоков, даже если бы это сработало, если бы вы это сделали).

Одним из инструментов для достижения этой цели является наличие ThreadLocal:

private static final ThreadLocal<Mac> MACS = ThreadLocal.withInitial(
  () -> HmacUtils.getInitializedMac("algorithm", key));


public void codeThatIsRunInManyThreads() {
  Mac mac = MACS.get();
  mac.reset();
  // use mac here. Rest safely knowing it's all safe now.
}

Этот код гарантирует, что каждый поток создаст новый объект Mac, но сделает это один раз — этот созданный объект Mac будет повторно использоваться для каждого задания. Создается столько же объектов Mac, сколько потоков, в конечном итоге выполняющих хотя бы одно задание. 32 ядра процессора и 10 000 рабочих мест? Будет создано около 64 объектов Mac.

Каждый объект Mac изолирован в одном потоке. Если это не потокобезопасно, не проблема. Если это так, то synchronized или другие механизмы безопасности потоков, которые он использует, не требуют больших затрат, поскольку JVM сможет довольно легко определить, что они ничего не делают, и устранить их.

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

Большинство алгоритмов хеширования, которые мы используем сегодня, работают путем последовательной обработки фрагментов данных (обычно 512 или 1024 бита). Это справедливо для SHA-2, SHA-3 и непараллельных вариантов BLAKE2, которые являются наиболее распространенными безопасными алгоритмами хэширования, используемыми сегодня. То же самое относится и к конструкциям HMAC или встроенным конструкциям MAC, основанным на этих алгоритмах.

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

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

Существуют алгоритмы, такие как BLAKE3 и MD6, которые используют хеширование деревьев, и они часто могут выиграть от распараллеливания. Обычно у них есть документация, в которой рассказывается, как создаются и обрабатываются потоки (часто с использованием пула потоков), а также соответствующие требования к безопасности потоков. Эти алгоритмы часто имеют внутреннюю поточность, поэтому экземпляры можно безопасно использовать в разных потоках, если это указано в документации. Однако используемая вами библиотека не предлагает ничего из этого, так что вам не придется с этим сталкиваться.

Если вы планируете обрабатывать небольшие порции данных, вам почти наверняка захочется использовать пул потоков, поскольку накладные расходы на создание потока могут быть нетривиальными по сравнению с хешированием.