我组织的一个 Android 应用程序需要在每个用户首次启动该应用程序时为其分配一个 UUID（版本 4），目前我们使用 Boost 库 1.58.0 用于此目的，我们的 Android 应用程序将使用 JNI 运行以下代码生成 UUIDv4：
boost::uuids::basic_random_generator<boost::random::lagged_fibonacci44497> generator;
generator(); //generating UUIDv4
该代码多年来一直运行良好，现在我们决定将其替换为 Java 中的 API（UUID.randomUUID()）。但我们认为如果在做出改变之前能够了解这两种方式的独特性会更好。
我的问题：
- 是否使用升压::随机::lagged_fibonacci44497减少使用我们的应用程序的两个设备具有相同 UUID（冲突）的机会？
- 如果是的话，我们能知道碰撞的概率吗？
- 该代码比UUID.randomUUID()就独特性而言？
的文档java.util.randomUUID()说它返回的 UUID 是“使用加密的强伪随机数生成器生成的”。因此，对于大多数用途来说，每个这样的 UUID 几乎肯定是“唯一的”（至少在 4.3 之后的 Android 版本中；参见这个问题).
版本 4 UUID 由 122 个随机选择的位组成，因此最多有 2^122 个此类 UUID。然而，随机选择的有限长度值不能保证其本身是唯一的。
粗略地说，当随机生成版本4的UUID时，只有在生成大约2^61个UUID之后，意外碰撞的机会才变得不可忽略，大约是27亿个（参见“生日问题”以获得精确的陈述和公式）。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
