Вероятность коллизии при использовании наиболее значимых битов UUID в Java

Если я использую, Long uuid = UUID.randomUUID().getMostSignificantBits()насколько вероятно получить столкновение. Он отрезает наименее значимые биты, так что есть вероятность, что вы столкнетесь с столкновением, верно?

Согласно документации , статический метод UUID.randomUUID()генерирует UUID типа 4.

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

Шесть неслучайных битов распределяются с четырьмя в наиболее значимой половине UUID и двумя в наименее значимой половине. Таким образом, самая значительная половина вашего UUID содержит 60 бит случайности, что означает, что вам в среднем нужно сгенерировать 2 ^ 30 UUID для получения коллизии (по сравнению с 2 ^ 61 для полного UUID).

Поэтому я бы сказал, что вы в безопасности. Обратите внимание, однако, что это совершенно не так для других типов UUID, как упоминает Карл Селеборг.

Кстати, вам было бы немного лучше, если бы вы использовали наименее значимую половину UUID (или просто генерировали случайный длинный с использованием SecureRandom).

У Раймонда Чена есть действительно превосходное сообщение в блоге об этом:

GUID являются глобально уникальными, но подстроки GUID не являются

Я думаю, что это лучший пример для использования randomUUID:

http://www.javapractices.com/topic/TopicAction.do?Id=56

Вам лучше просто генерировать случайное длинное значение, тогда все биты являются случайными. В Java 6 новый Random () использует System.nanoTime () плюс счетчик в качестве начального числа.

Существуют разные уровни уникальности.

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

Если вам просто нужно иметь уникальность в одном приложении, вы можете просто иметь счетчик (или счетчик, который начинается с currentTimeMillis () * 1000 или nanoTime () в зависимости от ваших требований)

Используйте время YYYYDDDD(год + день года) в качестве префикса. Это уменьшает фрагментацию базы данных в таблицах и индексах. Этот метод возвращает byte[40]. Я использовал его в гибридной среде, где SID Active Directory ( varbinary(85)) является ключом для пользователей LDAP, а автоматически созданный идентификатор приложения используется для пользователей, не являющихся LDAP. Также большое количество транзакций в день в таблицах транзакций (Банковская индустрия) не может использовать стандартные Intтипы ключей

private static final DecimalFormat timeFormat4 = new DecimalFormat("0000;0000");

public static byte[] getSidWithCalendar() {
    Calendar cal = Calendar.getInstance();
    String val = String.valueOf(cal.get(Calendar.YEAR));
    val += timeFormat4.format(cal.get(Calendar.DAY_OF_YEAR));
    val += UUID.randomUUID().toString().replaceAll("-", "");
    return val.getBytes();
}