Вероятность коллизии с помощью старших значащих битов UUID в Java
3 ответа
Согласно документация , статический метод UUID.randomUUID() генерирует UUID типа 4.
Это означает, что шесть битов используются для некоторой информации о типе, и остающиеся 122 бита присвоены случайным образом.
шесть неслучайных битов распределяются с четыре в старшей значащей половине UUID и два в младшей значащей половине. Таким образом, старшая значащая половина Вашего UUID содержит 60 битов случайности, что означает Вас на средней потребности генерировать 2^30 UUID для получения коллизии (по сравнению с 2^61 для полного UUID).
, Таким образом, я сказал бы, что Вы довольно в безопасности. Отметьте, однако что это абсолютно не верно для других типов UUID, как Carl Seleborg упоминает.
Кстати, Вы были бы немного более обеспечены при помощи младшей значащей половины UUID (или просто генерация случайного долгого использования SecureRandom).
У Raymond Chen есть действительно превосходное сообщение в блоге на этом:
Вы более обеспечены просто генерация случайного длинного значения, тогда все биты случайны. В Java 6, новом Случайный (), использует System.nanoTime () плюс счетчик как семя.
существуют разные уровни уникальности.
при необходимости в уникальности через многие машины у Вас могла бы быть центральная таблица базы данных для выделения уникальных идентификаторов или даже пакетов уникальных идентификаторов.
, Если у Вас просто должна быть уникальность в одном приложении, у Вас может просто быть счетчик (или счетчик, который начинает с currentTimeMillis () *1000 или нановремя () в зависимости от Ваших требований)