【发布时间】：2010-12-16 04:08:10
【问题描述】：
检查一下，
List<String> list = new ArrayList<String>();
for (int i = 0; i < 10000; i++) {
String value = (""+UUID.randomUUID().getLeastSignificantBits()).substring(3, 20);
assertFalse(list.contains(value));
assertTrue(value.length() < 18);
list.add(value);
}
这种方法就像魅力一样传递。我的印象是，取最低有效位比取最高有效位要好一些。因为在最高有效位中，您为某些信息固定了 6 位，而最低有效位并非如此。因此，平均而言，我们需要生成 2^29 个 UUID 才能与最高有效位发生冲突，但 2^32 个 UUID 与最低有效位发生冲突。参考：SO Thread。 我的假设正确吗？
现在，在这里，我将从该方法中获得的最低有效位中再砍掉 2 个最高有效位。我正在使用子字符串。请注意，我正在砍掉 2 个数字和一个符号位。 这不是说现在我们平均需要生成 2^31 个 UUID 才能发生碰撞吗？
确切地说，我正在尝试生成一个长度不应超过 17 位的唯一标识符。它必须是一个整数，而不是 Java 类型的意义。 我的方法有多可靠？
元信息：
实际上，我们正在与一些遗留系统集成，我们必须提供一些不超过 17 位的唯一编号。我假设他们将它作为数据库唯一键。在这种情况下，我们也可以使用序列，我首先提出了这一点。但是他们对我说，如果我能想出一个随机数就好了，这样消费者就猜不到了。
据我所知，关于 Java 中 UUID 的 type-4 实现，我们平均需要生成 2^61 个 UUID 才能发生冲突。这是否意味着我们需要生成 2^32 来获得最低有效位的冲突，以及 2^29 来获得最高有效位的冲突？如果是，那么假设我们需要平均生成 2^31 才能在切掉 2 个最左边的数字后在最低有效位上发生冲突，这是不正确的吗？
我也尝试使用 SecureRandom，但这也给了我 19 位数的长值。因此，我最终也先将其砍到数位。下面是它的代码。
List<String> list = new ArrayList();
Random random = new SecureRandom();
for (int i = 0; i < 10000; i++) {
String value = ""+random.nextLong().substring(2, 19);
assertFalse(list.contains(value));
assertTrue(value.length() < 18);
list.add(value);
}
我能想到的另一个选项是以“yyMMddHHmmssSSS+2-seq-digits”格式使用日期。但我想这将完全依赖于处理器，并且可以猜测。因为我不太确定在 99 轮之后我得到了毫秒的变化。也许我会，但这取决于处理器速度。不过，99 个同时请求是不太可能的。
【问题讨论】：
-
您的实际问题是什么？
-
好的，我要打问号了。对此感到抱歉。
标签： java uuid 64-bit unique-id