java - Java での UUID の最上位ビットを使用した衝突の可能性

Question

Long uuid = UUID.randomUUID().getMostSignificantBits()衝突の可能性を使用している場合。最下位ビットを切り捨てるので、衝突する可能性がありますよね？

Answer 1

ドキュメントによると、静的メソッドUUID.randomUUID()はタイプ 4 UUID を生成します。

これは、一部のタイプ情報に 6 ビットが使用され、残りの 122 ビットがランダムに割り当てられることを意味します。

6 つの非ランダム ビットは、UUID の最上位半分に 4 つ、最下位半分に 2 つ分散されます。したがって、UUID の最上位半分には 60 ビットのランダム性が含まれます。つまり、衝突を起こすには平均で 2^30 個の UUID を生成する必要があります (完全な UUID の 2^61 と比較して)。

だから、あなたはかなり安全だと思います。ただし、Carl Seleborg が言及しているように、これは他のタイプの UUID にはまったく当てはまらないことに注意してください。

ちなみに、UUID の最下位半分を使用する (または SecureRandom を使用してランダムな long を生成する) ことで、わずかに良い結果が得られます。

Answer 2

Raymond Chen は、これについて非常に優れたブログ記事を書いています。

GUID はグローバルに一意ですが、GUID の部分文字列はそうではありません

Answer 3

I thinks this is the best example for using randomUUID :

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

Answer 4

ランダムな long 値を生成するだけで、すべてのビットがランダムになります。Java 6 では、new Random() は System.nanoTime() とカウンターをシードとして使用します。

独自性にはさまざまなレベルがあります。

多くのマシン間で一意性が必要な場合は、一意の ID または一意の ID のバッチを割り当てるための中央データベース テーブルを用意できます。

1 つのアプリで一意性が必要な場合は、カウンター (または、要件に応じて currentTimeMillis()*1000 または nanoTime() から始まるカウンター) を持つことができます。

Answer 5

プレフィックスとして時間YYYYDDDD(年 + 日) を使用します。これにより、テーブルとインデックスでのデータベースの断片化が減少します。このメソッドは を返しますbyte[40]。Active Directory SID ( varbinary(85)) が LDAP ユーザーのキーであり、アプリケーション自動生成 ID が非 LDAP ユーザーに使用されるハイブリッド環境で使用しました。また、トランザクション テーブル (銀行業界) の 1 日あたりのトランザクション数が多い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();
}