답변:
documentation 에 따르면 정적 메소드 UUID.randomUUID()는 유형 4 UUID를 생성합니다.
즉, 일부 유형 정보에는 6 비트가 사용되고 나머지 122 비트는 임의로 할당됩니다.
6 개의 비 랜덤 비트는 UUID의 최상위 절반에 4 개, 최하위 절반에 2 개가 분배됩니다. 따라서 UUID의 최상위 절반에는 60 비트의 임의성이 포함되므로 충돌을 발생시키기 위해 평균적으로 2 ^ 30 UUID를 생성해야합니다 (전체 UUID의 경우 2 ^ 61과 비교).
그래서 나는 당신이 오히려 안전하다고 말할 것입니다. 그러나 Carl Seleborg가 언급했듯이 다른 유형의 UUID에는 이것이 사실이 아닙니다.
또한 UUID의 최소 절반을 사용하거나 SecureRandom을 사용하여 임의의 긴 길이를 생성하면 약간 나아질 것입니다.
Raymond Chen은 이것에 대해 정말 훌륭한 블로그 게시물을 가지고 있습니다.
이것이 randomUUID를 사용하는 가장 좋은 예라고 생각합니다.
임의의 긴 값을 생성하는 것이 좋으며 모든 비트는 임의입니다. Java 6에서 new Random ()은 System.nanoTime ()과 카운터를 시드로 사용합니다.
다른 수준의 고유성이 있습니다.
여러 시스템에서 고유성이 필요한 경우 고유 ID 또는 고유 ID 배치를 할당하기위한 중앙 데이터베이스 테이블이있을 수 있습니다.
하나의 앱에서 고유성을 필요로하는 경우 카운터 (또는 요구 사항에 따라 currentTimeMillis () * 1000 또는 nanoTime ()에서 시작하는 카운터) 만 있으면됩니다.
YYYYDDDD접두사로 시간 (년 + 년)을 사용하십시오. 이는 테이블 및 인덱스에서 데이터베이스 조각화를 줄입니다. 이 메소드는를 반환합니다 byte[40]. Active Directory SID ( varbinary(85))가 LDAP 사용자의 핵심이고 응용 프로그램 자동 생성 ID가 비 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();
}